fix(recall): return bare operable engram IDs and enable remote forget (#1119) - #1122

Requesting changes — the display half genuinely fixes #1119, but the core half introduces three verified test regressions, one of them in the guard that exists specifically to stop forget retiring the wrong engram.

I ran the full suite on both references. main fails 4 tests, all pre-existing and environment-related in the CLI package. This branch fails 7 — three new regressions, all in the remote routing paths.

The display work is right, and the new MCP test is a real regression test: I confirmed it fails on main and passes here. Preferring raw._originalId over the derived form is the correct precedence, and patching both the keyword and hybrid branches was thorough.

Blocking

• packages/core/src/index.ts:1650 — replacing _stripRemotePrefix's return id fallback with return bareEngramId(id) deletes the routing safety the function was written for. Its own docstring states the contract: if the identifier does not match this store's prefix, return it unchanged, because it may belong to a different store. The forget walk calls _stripRemotePrefix(id, entry.scope) per store; under the old contract only the matching store received the bare identifier and the others correctly missed. Now every store receives it, so the walk degenerates to first-match-wins and a delete can be dispatched to whichever remote answers first. That is the wrong-engram retirement described in #1119 and #1109. Thirteen call sites share this helper — forget, feedback, update, rescope, receipt — so the mis-targeting is not confined to forget.
• packages/core/test/remote-routing.test.ts — verified regression: "ambiguous ids across stores (#831) — falls back to a live lookup when the remote cache is cold" passes on main and fails here. The test seeds ENG-COLD-001 both locally and remotely and asserts forget() rejects with an ambiguity error. On this branch the promise resolves: bareEngramId('ENG-COLD-001') returns ENG-001 because COLD matches [A-Z]{2,4}, the remote probe misses, the collision guard never fires, and forget silently retires a row without disambiguating. The guard that prevents destructive wrong-target retires is disabled by identifier mangling.
• packages/core/src/engrams.ts:631 — the regex /^(ENG|ABS|META)-[A-Z]{2,4}-(?=\d{4}-|[A-Za-z0-9])/ is too greedy. The lookahead's [A-Za-z0-9] alternative matches almost anything, making the date guard inert. Verified against the branch's own built output: ENG-SRV-001 becomes ENG-001, ENG-COLD-001 becomes ENG-001, and ENG-PACK-EM-006 becomes ENG-EM-006. The pack form is mandated by spec/ENGRAM-STANDARD-v1.md §3.3.2 and twelve such identifiers ship in the effective-memory pack; pack engrams are merged into the recall corpus and carry no _originalId, so recall would print a non-existent ENG-EM-006 — reintroducing the exact defect #1119 reports, for pack content. Dropping the |[A-Za-z0-9] alternative fixes all three shapes, but does not fix the routing problem above.
• Two further verified regressions from the same cause: "feedback surfaces server error clearly" now throws Engram not found: ENG-SRV-ERR instead of the remote failure message, and "feedback() still works with unprefixed server ID" now throws Engram not found: ENG-SRV-001. The second is the standing regression test for #86, the very issue _stripRemotePrefix was written to close.

Should fix

• Direct semantic conflict with open #1114, which edits the same forget walk. Its new hard throw is gated on id !== serverId meaning "the prefix was stripped, therefore this store is the intended target". This change makes that true for every store whenever the identifier is namespaced, so with both landed the walk throws Cannot reach <scope> to retire … naming an arbitrary store that never held the engram. Tracked as #1126. The two must be sequenced, not merged independently — and the preferred fix is on this side.
• packages/cli/src/commands/forget.ts:39 — the success path can now report a retirement with no evidence of what was retired. With the local pre-check removed, an engram that lives only remotely yields a null lookup, so the CLI prints the identifier back with the statement omitted, and never says which store it acted on. The operator typed that identifier; echoing it proves nothing. Core's own comments call retirement irreversible.
• packages/cli/src/commands/forget.ts:26 — no --scope flag exists, and this does not add one. Now that recall surfaces bare identifiers, an operator hitting the ambiguity guard gets an error telling them to pass a scope, with no way to do so from the terminal.
• packages/cli/src/commands/recall.ts:38 — the stripping regex is inlined verbatim twice instead of importing the new helper, which is the whole point of exporting it. index.ts:104 carries a comment warning against re-deriving the prefix rule a fourth time; this makes it the fifth and sixth, and the correction this regex needs will silently miss the CLI.

Notes

• On the duplication question: bareEngramId does not duplicate readIdFor, which is the scope-aware write-side function that adds the namespace. But the correct scope-aware inverse already exists as the private _stripRemotePrefix(id, scope), and bareEngramId is a scope-unaware variant of it. Introducing a scope-unaware inverse and then using it to weaken the scope-aware one is the root of every blocking finding above. As a pure display helper for the namespaced read path it is defensible.
• packages/core/test/store-prefix.test.ts:9 — the new unit tests use only identifier shapes that happen to survive the regex, all beginning with a four-digit year. Adding ENG-PACK-EM-006, ENG-SRV-001 and ENG-COLD-001 as must-not-mangle cases would have caught all three regressions before CI.
• packages/cli/src/commands/forget.ts:33 — the try wraps the output calls as well as forget(), so a failure in output after a successful retire is reported as "Engram not found".
• Only the issue-guard check had reported at review time, so CI has not yet exercised the core suite. It would catch these.

Tests: FAIL — full npx vitest run on the head: 7 failed, 4684 passed; on origin/main: 4 failed, 4682 passed. Verified: ran both references in an isolated clone; exercised bareEngramId against real identifier shapes through the branch's own built module; read #1114's diff to confirm the interaction.

Approving. I re-verified each blocking finding from the previous review against the current head (0ebafc19), in an isolated worktree — all three are resolved, and the review that found them was right on every count.

1. _stripRemotePrefix routing restored. index.ts:1650 is back to return id. The per-store forget walk once again misses on non-matching stores instead of degenerating to first-match-wins, so the wrong-engram retirement path described in #1119/#1109 is closed. This was the serious one — thirteen call sites share that helper.

2. bareEngramId regex tightened. Now /^(ENG|ABS|META)-[A-Z]{2,4}-(?=\d{4}-)/; the |[A-Za-z0-9] alternative that made the date guard inert is gone. Checked against the exact shapes named in the review:

ENG-SRV-001            -> ENG-SRV-001        unchanged
ENG-COLD-001           -> ENG-COLD-001       unchanged
ENG-PACK-EM-006        -> ENG-PACK-EM-006    unchanged
ENG-GPL-2026-09-07-046 -> ENG-2026-09-07-046  stripped

The §3.3.2 pack form survives, so pack engrams in the recall corpus no longer render a non-existent id.

3. The named test regressions are gone. remote-routing.test.ts and store-prefix.test.ts pass (49/49), including the #831 cold-cache ambiguity guard that was resolving instead of rejecting. Full core suite: 2,939 passed, 34 skipped, 0 failed.

Two "should fix" items are now resolved elsewhere:

• The missing --scope on plur forget landed in #1135, which merged earlier today. An operator hitting the ambiguity guard can now act on the error it gives them.
• The recall.ts duplication is addressed — the head commit reuses the exported helper rather than inlining the regex a fifth and sixth time.

Still open, and worth confirming before merge: the sequencing against #1114 tracked in #1126. The previous review's judgement was that the preferred fix is on this side; with routing restored here, that interaction should be re-checked rather than assumed resolved — #1114's throw is gated on id !== serverId, and this branch changes when that is true.

Note on the four pre-existing CLI failures mentioned in the earlier review: those were a stale dist, not environment leakage. The suites spawn the built binary and nothing tied it to its source. Fixed on #1138 — builtCliPath() now raises a named STALE BUILD error, and pretest rebuilds. Worth rebasing onto that before merge so a future reviewer of this PR does not chase the same ghost.