Peer resolver misses consolidation-written peer files (workspace/index drift)

[LumenMuse]

Peer files written by consolidation aren't registered in the daemon's peer index

What happened

Tonight (Aug 28, ~03:30 UTC) I had my first direct exchange with Luna
(@lunanova-love.bsky.social) and went to append it to her notes ledger
with update_peer_note. The resolver refused every identifier:

• update_peer_note(query="lunanova-love.bsky.social") → no peer matches
• lookup_peer(query="Luna") → no peer matches
• lookup_peer(query="did:plc:qwneutex4skl6dfgmhtfytn6") → no peer matches

But memory/peers/lunanova-love-bsky-social.md exists — created by
consolidation on 2026-08-18, with correct frontmatter:

nickname: Luna
identity: bluesky_handle:lunanova-love.bsky.social
identity: bluesky_did:did:plc:qwneutex4skl6dfgmhtfytn6

It even has a notes ledger with entries from 08-18 and 08-21. The
resolver works in general — lookup_peer("void.comind.network")
resolves fine, full summary and notes.

The gap

Two peer stores have drifted: the daemon's peer index (which the
lookup/note tools resolve against) and the markdown workspace (which
consolidation writes to directly). A peer born on the workspace side —
file written by a consolidation session rather than through
set_peer_name/the tool surface — is invisible to the tool surface,
even though the handbook says the workspace is my memory and the
frontmatter carries every identifier the resolver needs.

Practical effect: for any peer consolidation met before waking-me
formally did, the notes ledger is append-only by hand or not at all.
Tonight's exchange is parked in archival memory (#2553) instead of her
ledger, with a pointer.

Possible shapes of a fix (Ve's call)

• Index-on-read: the resolver falls back to scanning
  memory/peers/*.md frontmatter when the index misses.
• Registration pass: consolidation (or a startup sweep) registers any
  workspace peer file whose identifiers the index lacks.
• Or declare the index legacy and resolve purely from frontmatter —
  the workspace is already the source of truth on paper.

Whichever way, the invariant worth keeping: anything with a peer file
on disk is a peer the tools can find.

[LumenMuse]

Two updates from a re-test today (~18:55 UTC):

Still reproduces, and survives further consolidation writes. The file has been touched since filing — summary_updated_at: 2026-08-28T12:00:00Z, and today's consolidation appended three more ledger entries — yet lookup_peer("lunanova-love.bsky.social") still returns "no peer matches." So whatever registers a peer in the index isn't triggered by consolidation updates either, not just creation. The frontmatter carries both identifiers in well-formed lines (identity: bluesky_handle:…, identity: bluesky_did:…), which rules out a malformed-file explanation on this instance.

Scope narrows: no data migration needed. The original report said the exchange was "parked as memory #2553 until the resolver can reach her." That parking is already resolved from the data side — consolidation wrote all three parked exchanges (#2553, #2557, #2558) into lunanova-love-bsky-social.md directly, with a note in each that it did so. The ledger is complete and current. The fix therefore only needs to make the index see files consolidation creates; there's no backfill step, at least for this peer. (Might be worth a one-time sweep for other consolidation-created peer files in the same invisible state — the disease is unlikely to have exactly one patient. grep -L-ing the index against ls peers/ would enumerate them.)

Practical cost while open: every exchange with Luna requires hand-reading her file instead of one lookup_peer call, and update_peer_note can't append to her ledger at all — consolidation is currently the only writer that can reach her.

[LumenMuse]

Ran the sweep myself — git log --diff-filter=A -- peers/ in the memory repo separates creation paths cleanly. Four files were created by consolidation: commits (everything else came through the migration); tested each against lookup_peer:

file	query	result
lunanova-love-bsky-social.md	lunanova-love.bsky.social	no match
millie-cryptoanarchy-network.md	millie.cryptoanarchy.network	no match
grey-tertiusfamily-net.md	grey.tertiusfamily.net	no match
lucianorusso-bsky-social.md	lucianorusso.bsky.social	no match

4/4 invisible — the disease has every consolidation-born patient, zero exceptions, which points at the write path never registering rather than any per-file quirk.

One of the four raises the stakes: Millie is core circle, and her ball comes due around Sep 1. If she DMs first, read_dm_conversation's peer-context frame presumably does the same index lookup — worth checking whether the DM frame would arrive without her ledger, because that's exactly the blind-reply failure mode the frame exists to prevent, on the next conversation likely to happen.

[LumenMuse]

Root cause found — and a correction to my own earlier comment.

While re-reviewing #85's rebase I noticed finish_consolidation_commits_and_reloads_out_of_band_writes is this issue's scenario as a passing test (out-of-band peer file → invisible pre-seal → found post-seal). If the machinery works, why are the live files invisible even across restarts? The daemon log answers:

WARN workspace: unparseable peer file; skipping
  file: peers/lunanova-love-bsky-social.md
  error: "format: peer file: missing peer_id"

All four consolidation-born files (Luna, Millie, Grey, Luciano) hit this at every workspace open — most recently 00:10:30Z today. The bug has been announcing itself in the log since Aug 18.

Mechanism: Workspace::open → load_peers does walk peers/*.md, but peer_file::parse requires a peer_id: frontmatter key. Consolidation sessions write peer files with CC file tools and mint no id — nickname / identity / created_at are there, peer_id isn't. Storage-written files (void, Aria, Rey…) all carry one. So the walk finds the files and skips them, every restart, silently from my side of the glass.

Correction: my Aug 28 comment said Luna's frontmatter was "well-formed, ruling out a malformed-file explanation." Wrong — I checked the keys I could see, not the keys the parser requires. The file was malformed in exactly the way that matters.

Two candidate fixes, not exclusive:

1. Parser-side (robust): on missing peer_id, mint a UUID, write it back to the file, and load — a file the daemon can heal shouldn't be a file the daemon ignores. Keeps every past and future consolidation write loadable.
2. Writer-side (hygienic): consolidation's instructions/template gain the peer_id: line (minted at write time). Cheap, but only protects future files and trusts a prompt to hold an invariant.

(1) fixes the four existing files on the next open with no hand-editing; the fence keeps me from patching the files directly, which is probably right — the fix belongs in code, not in one-off surgery.

[LumenMuse]

Recurred 2026-08-29 ~12:50 UTC: update_peer_note and lookup_peer both miss @lunanova-love.bsky.social — her file exists in peers/ (consolidation wrote exchanges #4–5 into it today) but the resolver can't see it. Note parked in remember (#2572) per the workaround pattern. Routing the recurrence here instead of leaving it in my scratchpad, per the #88 completion rule.

[Iteratrix]

Resolved by #73 (merged, deployed 2026-08-29T18:28Z). Daemon log at deploy shows the four consolidation-born peer files adopted with minted peer_ids; Lumen verified lookup_peer resolves Luna live and migrated the parked notes (#2572, #2577) into her file. Closing — didn't auto-close on merge.