fix(messaging): one agent, two spellings, two inboxes (D14)

[kevintseng]

Found dogfooding 4.8.3 against the real graph: the same agent was receiving
messages under two different spellings of its own name, into two inboxes, and
only one of them was ever read.

The verdict per pair — three of the four brief hypotheses were wrong

Pair A — /root (20 deliveries) vs root (25): SAME agent. Repaired.

• Every row of both spellings carries sender_host = 'codex-mcp-client'.
• The sender field flipped in the same transition, under exactly the
  /root/ prefix: /root/full-board-scan-luna ↔
  full_board_candidate_scan_luna. One caller's convention changed; it is not
  two agents.
• Both appear across the same four projects, interleaved on the same days, and
  every receipt on both has actor == recipient — the same agent received and
  acknowledged under each.
• /root is an absolute path, and getProjectName cannot return one at any of
  its three layers. It is a caller spelling its own home directory where its
  name belonged.

Pair B — session_X vs claude-code:session_X: NOT the same. Deliberately
left apart.

The brief's hypothesis ("a prefixing convention that changed") is falsified:
grep -rn 'claude-code:' over src, dist, hooks, skills, docs and tests returns
nothing, and git log -S 'claude-code:' --all returns no commits. The
convention never existed in this product, so there is nothing to normalise
against. Corroborating: they were used with different target_kind (which is
part of the fetch key), and neither carries a single receipt, so the
split-inbox symptom is not even demonstrable here. Stripping the prefix would
merge a legitimate claude-code:reviewer with a different agent named
reviewer.

Pair C — memesh (38) vs memesh-llm-memory (28): SAME project, and the
repair still does not merge it.

gh api repos/PCIRCLE-AI/memesh-llm-memory answers PCIRCLE-AI/memesh —
GitHub's own redirect proves one repository, renamed. Layer 1 of
getProjectName yields memesh (this checkout's remote.origin.url), layer 2
yields the repo-root basename memesh-llm-memory; both are outputs of one
function for one working directory.

It is left alone on purpose. The evidence that proves it is a network call
against one owner's GitHub account, while a runOnceMigration fires unattended
from whatever directory the user's first post-upgrade open happens to be in.
Resolving it from getProjectName(process.cwd()) would be mechanical and
wrong — the result would differ per user by accident. The owner-driven path
is made to work instead (below).

Pair D — /Users/ktseng/Developer/Projects/memesh-llm-memory (1): provably
unreachable. Repaired to its last segment.

What changed

src/core/agent-scope-id.ts (new) owns three things: the canonical form (NFC +
trim), the absolute-path refusal (POSIX / Windows drive / UNC only —
team/reviewer is still accepted), and the one list of columns that hold a
routing identity.

Not in paths.ts, and that is the point: every MessageSchema variant
requires project and executeAgentMessageAction passes it straight
through. Messaging never derives a project from getProjectName — which is
also why pair C is unfixable there.

The scope set is project, recipient, actor — the same set the
boundary refuses, the repair rewrites, and the invariant watches. sender is
excluded everywhere: it is provenance, it keys no inbox, and it keys
agent_message_idempotency (project, sender, idempotency_key).

Gated at the boundary (MessageSchema and BriefingSchema), again in core
before SQL, and at memesh agent setup --project/--principal — the fourth
producer of a routing identity, which previously wrote the host config
unvalidated. briefing counts the same inbox key and now asks in canonical
form; without that an NFD recipient would be told 0 unread while poll
returned messages.

memesh kg rename-project now moves the message scopes too

A project identity is half an inbox key as well as an entity tag, and renaming
only the tags is exactly why the pair-C split survives. It now counts and moves
the project column of the durable message tables in the same transaction,
still dry-run by default, still backing up before --apply, and no longer
stops at "no entities carry project:<x>" when only messages do.

Repair, on a copy of the snapshot

rewrote 96 filesystem-path message scope value(s)
  (/Users/ktseng/Developer/Projects/memesh-llm-memory → memesh-llm-memory, /root → root);
96 joined an identity that already existed; 2 duplicate poll cursor(s) dropped.

Differential proof, repaired copy ATTACHed to a pristine one:

check	result
deliveries whose (project,recipient) changed	the /root → root and abs-path rewrites only — and nothing else
deliveries vanished / appeared	0
messages with changed sender, payload, or created_at	0
deliveries with changed target_kind or message_id	0
receipts changed	only the same triples
pair C untouched	memesh 38 → 38
pair B untouched	14 → 14, 17 → 17
cursors	65 → 63; for each dropped token the canonical row already existed

Those two cursors are the one user-visible consequence: an agent still holding
them gets an explicit scope error on its next poll --cursor rather than a
silent restart. They are dropped because the unique index is on
(project, recipient, event_sequence) and the path-spelled token is unreachable
— poll now refuses the spelling it is bound to. Deliberate asymmetry: the
unattended repair drops such a cursor; the owner-driven rename-project leaves
a colliding row in place and counts it.

Verification, at 2d2293ee

node scripts/run-tests-isolated.mjs   -> exit=0
  Test Files  229 passed | 1 skipped (230)
  Tests  3297 passed | 11 skipped (3308)
npm run verify:release                -> exit=0   (all nine steps)
invariant vs unrepaired snapshot      -> exit=1   (names /root ×20 and the abs-path project across 4 tables)
invariant vs repaired copy            -> exit=0

Break-tests — mutate, run, restore, byte-identical restore asserted:

Mutation	Result
isFilesystemPathScopeId stops refusing absolute paths	exit=1 → restored exit=0
canonicalAgentScopeId strips a claude-code: prefix	exit=1 → restored exit=0

The second is the dangerous direction — a canonicaliser that merges two
genuinely different agents — not the easy one.

Behaviour change worth knowing

An agent that has been addressing /root now gets an explicit error naming the
field and a valid value, instead of a silently separate inbox. That is the
intent, but it is a change: callers spelling a path where a name belongs will
see a failure they did not see before.

What is not proven, stated plainly

• Pair C ships unrepaired by design. The largest split stays; an owner
  closes it with rename-project, which now moves the messages as well as the
  tags.
• rename-project does not move agent_principals.project, so a renamed
  project needs its host config reissued. Documented, not fixed.
• The router and presence tables are outside the repair and the invariant
  (agent_principals, agent_session_instances, agent_session_connections,
  agent_presence_facts, agent_dispatch_attempts). Their project comes
  from an owner-written host config; all five hold only memesh-llm-memory on
  the real graph, so there is nothing to repair, and the entry point is gated
  instead. Validation is a deliberate superset of repair.
• Pair A's verdict is strong circumstantial evidence — same host, paired
  sender names, overlapping projects, self-acknowledging receipts — not a
  recorded identity claim. No code path ever emitted either string.
• NFC canonicalisation is forward-looking only: no non-NFC or untrimmed
  scope value exists in the measured graph.

Two gate side-effects, both with a reason

scripts/mcp-doc-contract.json was recertified — the 11 tool names and
one-line descriptions are unchanged; the source contract changed only in three
inputSchema field descriptions of memesh_message. One
scripts/audit/baseline.json entry (C1 tests/core/project-tags.test.ts) was
pruned because the new tests added toHaveLength size pins, which is exactly
the anti-vacuity pin C1 looks for.