fix(metadata-protocol): the three recovery doors announce their writes on the mutation choke point

[os-musk]

Fixes#14179

emitMetadataMutation documents itself as "the ONE choke point every authoring surface funnels through", and since the #13331 fan-out landed it is also the metadata.mutated cluster publish point. Three live write paths never reached it. Each now emits after its write, with the same org scope the write received and the same singular type key the registry was written under — mirroring the emitting siblings rather than inventing an event shape.

Verified at e60660c3a (the branch head this description describes; the gate union below was run on that same commit).

The three doors

door	reached by	before	after	pinned by
rollbackMetaItem, after its registry write-through	POST /api/v1/meta/:type/:name/rollback	write-through, no emit	emitMetadataMutation({ type: singularType, name, state: 'active', organizationId: orgId })	new file, §2 "announces the restored body on the mutation choke point" + "folds a PLURAL request type…"
revertCommit — RESTORE limb, after the per-item write-through	POST /packages/:id/commits/:commitId/revert	write-through, no emit	same event with PLURAL_TO_SINGULAR[it.type] ?? it.type, state: 'active', per-item itemOrgId	new file, §2 "RESTORE limb announces the pre-commit body it wrote back" + the mixed-batch case
revertCommit — SOFT-REMOVE limb, after repo.delete + restoreArtifactRegistryView	same door, items the commit created	delete + heal, no emit	same key/scope, state: 'deleted', gated on a row actually having been removed	new file, §2 "SOFT-REMOVE limb announces a deleted…" + §4's already-absent negative control
deleteMetaItem legacy raw-engine exit (the non-useRepoPath side)	DELETE /api/v1/meta/:type/:name on a control-plane bootstrap kernel	engine.delete + optional storage drop + heal, no emit	mirrors the repository twin exactly: state: 'deleted', singularTypeForRepo, request.organizationId ?? null	new file, §2 "announces the deletion it really performs" + "carries the org scope the delete predicate used"

Four call sites, three doors — revertCommit's two limbs are one door with two exits, exactly as the card's inventory counts it. this.emitMetadataMutation( call sites go 3 to 7; applyRegistryWriteThrough call sites stay at 5, so protocol.object-registry-write-through-spelling.test.ts's closed-caller-set pin is untouched and green.

Premise, re-measured

At the branch base 5c9e40ad9: git grep -n "applyRegistryWriteThrough(" -- packages/metadata-protocol/src/protocol.ts returns 6 hits, one of them the declaration at :13660 — FIVE call sites; the same grep for emitMetadataMutation( returns 4, one of them the declaration at :4962 — THREE call sites. The card's count holds.

One correction to the card's attribution of the fifth write-through: it sits inside applyRemoteMetadataMutation (the #13331 RECEIVE-side applier), not inside publishMetadataMutation (the publisher, which makes no write-through call at all). The substance is unchanged — it is the receive side, and it is deliberately not a door.

Reachability of the legacy delete exit — the NOT MEASURED item, now measured

The unblock comment recorded that it had not verified the branch's own docblock claim ("only reachable in control-plane bootstrap mode where environmentId is undefined"), noting correctly that useRepoPath does not itself test environmentId.

Measured: the claim holds, by a mechanism the docblock does not name. What confines the branch is the two-tier delete authorization above it, which runs only when environmentId !== undefined and refuses both limbs for exactly the types that would reach the legacy path:

• artifact-backed: artifactBacked AND NOT overlayAllowed AND NOT legacyOverlayRemoval produces NOT_OVERRIDABLE 403
• not artifact-backed: NOT artifactBacked AND NOT overlayAllowed AND NOT runtimeCreateAllowed produces NOT_CREATABLE 403

The #6960 carve-out is the only way past the first limb and it cannot apply: it reads supportsOverlay, and the useRepoPath === false set is exactly agent, api, capability, field, job — five of the registry's 27 entries, none of which carries supportsOverlay: true. Both 403s are driven end to end in §3, and the registry property itself is pinned there too, so a registry edit that opens the door has to come past this file.

So door 4's exposure is narrower than the comment feared: unreachable through the public deleteMetaItem on a normal boot. That is why its repair is pinned under bootstrap mode — which is where the defect is real, and where the registry every organization shares is the one being healed. The OS_METADATA_WRITABLE escape hatch only moves a type ONTO the repository (emitting) path, never onto this one; the harness clears its memoised cache so that cannot silently change what is measured.

The receive path stays silent — cited, not duplicated

Adding an emit inside applyRemoteMetadataMutation would re-broadcast every received event and ping-pong across replicas, which the loopback guard (own-messages only) cannot stop. That negative is already pinned in protocol.cluster-mutation-fanout.test.ts, in "the peer's onMetadataMutation listeners receive the remote event, once, after convergence": expect(writerSeen).toHaveLength(1), commented "the remote replay stays local to the receiving node (no echo)". A peer that re-emitted would re-publish, the writer would apply that peer-origin message past its own loopback guard, and that assertion would read 2. It is cited rather than re-built.

Alongside it, §5 of the new file carries three structural pins that make the same claim locally and cheaply: the emitMetadataMutation call-site count is 7, notifyMutationListenersLocal keeps exactly its two declared callers (the choke point and the receive path), and applyRemoteMetadataMutation's body contains notifyMutationListenersLocal and does not contain emitMetadataMutation.

The cluster half is inherited, not re-measured

emitMetadataMutation is two lines — the local fan-out, then publishMetadataMutation — so a door that reaches the choke point reaches the publisher. protocol.cluster-mutation-fanout.test.ts already proves that end to end over a two-replica pub/sub double (Arm B, "a runtime-authored object registers on the PEER after the writer's save", with Arm A as the no-bridge control). Combined with §5's call-site count, the new doors inherit the cluster leg structurally. Building a second cluster harness here would re-measure that file's subject rather than this card's, so it is not built.

Ablation — direction declared before the run, in the committed test header

Declared (commit 43640d6c6, before running): removing door 1's emit from protocol.ts turns RED both of §2's rollback cases and §5's call-site count, and leaves everything else GREEN — 3 RED / 15 GREEN of 18.

Measured, exactly that:

BEFORE: anchor=1 emit-call-sites=7
AFTER: anchor=0 emit-call-sites=6 blob=ba5fa53549caa6a282bb325a2ae93f62a47fcdc6
MUTATION CONFIRMED ON DISK (anchor 1->0, emit sites 7->6, blob differs from HEAD)
x announces the restored body on the mutation choke point
x folds a PLURAL request type to the singular the write-through registered under
x has exactly seven `emitMetadataMutation` call sites
Tests 3 failed | 15 passed (18)
RESTORE: blob=fa53e5ac6b7ab5ff6d47aaf4e86ba7ba89352270 head=fa53e5ac6b7ab5ff6d47aaf4e86ba7ba89352270 anchor=1 emits=7 diff-bytes=0
RESTORE CONFIRMED BYTE-EXACT (blob == HEAD blob, git diff HEAD empty, anchor 1, emits 7)

Mechanics: the fix was committed first, so the restore leg had a real restore point; the mutation ran under an EXIT INT TERM trap whose paths are absolute (seeded from git rev-parse --show-toplevel, not from a cwd); the mutation is proved by anchored counts of the removed text and a blob hash that differs from HEAD's, never by perl -i's exit code; the restore is proved by git checkout HEAD -- path followed by a blob-hash match against the HEAD blob AND an empty git diff HEAD, never by an exit code. The first attempt of this script refused to run — its precondition read anchor=0 because the bracketed issue tag was being read as a regex character class — and that refusal is the design working: a zero-match mutation would otherwise have produced a fully green "ablation".

No rebuild is involved and that is itself a measurement: the pin file imports the same-package relative ./protocol.js, so vitest compiles src/protocol.ts. An ablation that goes red with no build is what proves it; a dist-resolved one would have stayed green.

Deliberately unchanged

• The row-absent exits stay silent. The repository path's miss, the legacy path's miss, and revertCommit's soft-remove limb over an already-gone row: nothing mutated, so nothing is announced. The soft-remove gate is if (current), mirroring the repository delete twin, whose row-absent exit has always been silent even though it still runs the self-heal. A deleted signal there would wake every peer to converge on a no-op. All three are pinned in §4.
• A draft save still announces draft.publishMetadataMutation owns the draft filter, not the doors; §4 pins that this change did not move that boundary.
• packages/spec and packages/metadata are untouched — the event shape needed no change. So is the runtime: TS-config boot registers a 'metadata' service without attachClusterPubSub — cross-node invalidation disabled; new object gives OBJECT_NOT_FOUND on non-writing replicas, never heals #13331 publish/subscribe seam, which was read and not edited.

Files, and one beyond the dispatched surface

• packages/metadata-protocol/src/protocol.ts — the three doors (four call sites), +60 lines, comments included.
• packages/metadata-protocol/src/protocol.recovery-doors-emit-mutation.test.ts — new, 18 cases.
• .changeset/recovery-doors-emit-metadata-mutation.md — @objectstack/metadata-protocol: patch.
• scripts/engine-double-contract.pinned.json — not on the dispatched file surface, declared here.check:engine-double-contract reds on a new pin file until the RETAINED ledger records it ("New pinned coverage is GOOD and nothing is wrong with your change — the ledger just has to learn about it, or it never protects this file"). Regenerated with that gate's own --write: 3 rows added, all naming the new test file, 0 lost, no other row touched. Reusing an existing double instead was not available — the file is new, so it has no double to override.

No existing sibling pin needed updating: the whole @objectstack/metadata-protocol suite is green unchanged (2125 passed), including the write-through-spelling call-site count, the cluster fan-out arms and the delete-rewrap envelope pins.

Gate union, run on e60660c3a

Derived on the real change set with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands after the last commit — 44 commands, 7 more than the dispatch's list because the ledger file above joined the diff (agent-test-spelling, bash32-floor, cli-command-ids, entry-guard, parse-guard, pnpm-filter-targets, watch-hint-literal; all seven PASS). Exit codes captured after a redirect, never through a pipe.

• pnpm --filter @objectstack/metadata-protocol test — PASS, 154 files passed / 2 skipped, 2125 tests passed / 10 skipped.
• pnpm --filter @objectstack/metadata-protocol typecheck — PASS (tsc --noEmit). The new pin file is inside that program: tsc --listFilesOnly lists it, 1 hit among 699 files.
• pnpm lint — PASS over the whole repo in 68s (eslint . --no-inline-config), so no narrowing was needed and none is claimed.
• pnpm check:nul-bytes — PASS (7859 files scanned), plus a manual control-character scan over the four changed paths: zero hits.
• The 44-command union: 40 PASS, 4 NOT MEASURED, 0 findings.

The four NOT MEASURED are exit-3 PREREQUISITE-NOT-MET, recorded with the gates' own words and read as neither pass nor finding — every one needs an input a per-package local run does not have, and CI supplies all four:

gate	its own verdict
check-test-completeness.mjs	"pass a saved turbo run test log — or, running the family locally, record this gate as NOT MEASURED"
pm/check-half-states.mjs	exit 3, an unread instrument (needs the GitHub board) — "never as a quiet board"
check:dual-build-cjs-loads	"PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/… Run pnpm build first. This is NOT a pass"
check:type-check-debt	"Build the closure first, exactly as lint.yml does… This is NOT a pass and NOT a finding"

Merge state

main landed 5 commits since this branch's base (5c9e40ad9 to 4485f7dad): CLI, lint, docs and three merge-driver scripts. None touches packages/metadata-protocol or packages/spec, so the AGENTS.md §10 re-check is scoped out rather than skipped, and the merge queue validates the merge commit itself. No other in-flight claude/issue-14* branch on origin touches protocol.ts (24 branches fetched and diffed against their merge-base at PR time), so the serial lane the dispatch declared is still clear.

Not this card

#13609 (a deleted datasource prolonging cluster-wide) is a different defect and is not addressed here: datasource carries allowOrgOverride: false, allowRuntimeCreate: true, so useRepoPath is true and it takes the repository exit, which has emitted since #2588. This branch changes nothing about it, and that card stays open on its own premise.

🤖 Generated with Claude Code

https://claude.ai/code/session_0112hMx9hjJ9BgB28X97DS68

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/metadata-protocol, touching 7 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/client-sdk.mdx(via meta.rollbackItem (sdk, the route ledger binds it to POST /api/v1/meta/:type/:name/rollback, selected by route anchor /:type/:name/rollback), rollbackItem (sdk, the bare tail of client method meta.rollbackItem, bound to POST /api/v1/meta/:type/:name/rollback))
• content/docs/kernel/contracts/metadata-service.mdx(via /:type/:name/rollback (route, bridged from symbol rollbackMetaItem — its registrar handler names it))
• content/docs/kernel/services-checklist.mdx(via deleteMetaItem (symbol, a method of class ObjectStackProtocolImplementation))

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 8 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from b2431d3164baf7f9401f96757f5f0beb6e663570 — the merge of head e60660c3a62281b5ef3edf397f1b2f50d4d3ec44 into base 41aa979295be112cc6c27fcd6cc6c5ac20c519d5, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin b2431d3164baf7f9401f96757f5f0beb6e663570 && git checkout b2431d3164baf7f9401f96757f5f0beb6e663570
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 e60660c3a62281b5ef3edf397f1b2f50d4d3ec44 && git checkout -B drift-repro 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 && git merge --no-ff e60660c3a62281b5ef3edf397f1b2f50d4d3ec44
node scripts/docs-audit/affected-docs.mjs --json 41aa979295be112cc6c27fcd6cc6c5ac20c519d5

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-musk]

Enqueue provenance (domain:engine execution seat, session_0112hMx9hjJ9BgB28X97DS68): ACCEPT on #14179 (comment 5504761434) → at 05:32Z every check run on head e60660c3a was completed with success or skipped (33 runs; Lint & Repo Gates finished 05:31Z), governed-surface test on the four changed paths: NOT governed, mergeable_state not dirty → marked ready and auto-merge (squash) enabled. Landing is by the merge queue; the engine seat follows it to MERGED.

---

Generated by Claude Code

[os-musk]

Fixes#14179

emitMetadataMutation documents itself as "the ONE choke point every authoring surface funnels through", and since the #13331 fan-out landed it is also the metadata.mutated cluster publish point. Three live write paths never reached it. Each now emits after its write, with the same org scope the write received and the same singular type key the registry was written under — mirroring the emitting siblings rather than inventing an event shape.

Verified at e60660c3a (the branch head this description describes; the gate union below was run on that same commit).

The three doors

door	reached by	before	after	pinned by
rollbackMetaItem, after its registry write-through	POST /api/v1/meta/:type/:name/rollback	write-through, no emit	emitMetadataMutation({ type: singularType, name, state: 'active', organizationId: orgId })	new file, §2 "announces the restored body on the mutation choke point" + "folds a PLURAL request type…"
revertCommit — RESTORE limb, after the per-item write-through	POST /packages/:id/commits/:commitId/revert	write-through, no emit	same event with PLURAL_TO_SINGULAR[it.type] ?? it.type, state: 'active', per-item itemOrgId	new file, §2 "RESTORE limb announces the pre-commit body it wrote back" + the mixed-batch case
revertCommit — SOFT-REMOVE limb, after repo.delete + restoreArtifactRegistryView	same door, items the commit created	delete + heal, no emit	same key/scope, state: 'deleted', gated on a row actually having been removed	new file, §2 "SOFT-REMOVE limb announces a deleted…" + §4's already-absent negative control
deleteMetaItem legacy raw-engine exit (the non-useRepoPath side)	DELETE /api/v1/meta/:type/:name on a control-plane bootstrap kernel	engine.delete + optional storage drop + heal, no emit	mirrors the repository twin exactly: state: 'deleted', singularTypeForRepo, request.organizationId ?? null	new file, §2 "announces the deletion it really performs" + "carries the org scope the delete predicate used"

Four call sites, three doors — revertCommit's two limbs are one door with two exits, exactly as the card's inventory counts it. this.emitMetadataMutation( call sites go 3 to 7; applyRegistryWriteThrough call sites stay at 5, so protocol.object-registry-write-through-spelling.test.ts's closed-caller-set pin is untouched and green.

Premise, re-measured

At the branch base 5c9e40ad9: git grep -n "applyRegistryWriteThrough(" -- packages/metadata-protocol/src/protocol.ts returns 6 hits, one of them the declaration at :13660 — FIVE call sites; the same grep for emitMetadataMutation( returns 4, one of them the declaration at :4962 — THREE call sites. The card's count holds.

One correction to the card's attribution of the fifth write-through: it sits inside applyRemoteMetadataMutation (the #13331 RECEIVE-side applier), not inside publishMetadataMutation (the publisher, which makes no write-through call at all). The substance is unchanged — it is the receive side, and it is deliberately not a door.

Reachability of the legacy delete exit — the NOT MEASURED item, now measured

The unblock comment recorded that it had not verified the branch's own docblock claim ("only reachable in control-plane bootstrap mode where environmentId is undefined"), noting correctly that useRepoPath does not itself test environmentId.

Measured: the claim holds, by a mechanism the docblock does not name. What confines the branch is the two-tier delete authorization above it, which runs only when environmentId !== undefined and refuses both limbs for exactly the types that would reach the legacy path:

• artifact-backed: artifactBacked AND NOT overlayAllowed AND NOT legacyOverlayRemoval produces NOT_OVERRIDABLE 403
• not artifact-backed: NOT artifactBacked AND NOT overlayAllowed AND NOT runtimeCreateAllowed produces NOT_CREATABLE 403

The #6960 carve-out is the only way past the first limb and it cannot apply: it reads supportsOverlay, and the useRepoPath === false set is exactly agent, api, capability, field, job — five of the registry's 27 entries, none of which carries supportsOverlay: true. Both 403s are driven end to end in §3, and the registry property itself is pinned there too, so a registry edit that opens the door has to come past this file.

So door 4's exposure is narrower than the comment feared: unreachable through the public deleteMetaItem on a normal boot. That is why its repair is pinned under bootstrap mode — which is where the defect is real, and where the registry every organization shares is the one being healed. The OS_METADATA_WRITABLE escape hatch only moves a type ONTO the repository (emitting) path, never onto this one; the harness clears its memoised cache so that cannot silently change what is measured.

The receive path stays silent — cited, not duplicated

Adding an emit inside applyRemoteMetadataMutation would re-broadcast every received event and ping-pong across replicas, which the loopback guard (own-messages only) cannot stop. That negative is already pinned in protocol.cluster-mutation-fanout.test.ts, in "the peer's onMetadataMutation listeners receive the remote event, once, after convergence": expect(writerSeen).toHaveLength(1), commented "the remote replay stays local to the receiving node (no echo)". A peer that re-emitted would re-publish, the writer would apply that peer-origin message past its own loopback guard, and that assertion would read 2. It is cited rather than re-built.

Alongside it, §5 of the new file carries three structural pins that make the same claim locally and cheaply: the emitMetadataMutation call-site count is 7, notifyMutationListenersLocal keeps exactly its two declared callers (the choke point and the receive path), and applyRemoteMetadataMutation's body contains notifyMutationListenersLocal and does not contain emitMetadataMutation.

The cluster half is inherited, not re-measured

emitMetadataMutation is two lines — the local fan-out, then publishMetadataMutation — so a door that reaches the choke point reaches the publisher. protocol.cluster-mutation-fanout.test.ts already proves that end to end over a two-replica pub/sub double (Arm B, "a runtime-authored object registers on the PEER after the writer's save", with Arm A as the no-bridge control). Combined with §5's call-site count, the new doors inherit the cluster leg structurally. Building a second cluster harness here would re-measure that file's subject rather than this card's, so it is not built.

Ablation — direction declared before the run, in the committed test header

Declared (commit 43640d6c6, before running): removing door 1's emit from protocol.ts turns RED both of §2's rollback cases and §5's call-site count, and leaves everything else GREEN — 3 RED / 15 GREEN of 18.

Measured, exactly that:

BEFORE: anchor=1 emit-call-sites=7
AFTER: anchor=0 emit-call-sites=6 blob=ba5fa53549caa6a282bb325a2ae93f62a47fcdc6
MUTATION CONFIRMED ON DISK (anchor 1->0, emit sites 7->6, blob differs from HEAD)
x announces the restored body on the mutation choke point
x folds a PLURAL request type to the singular the write-through registered under
x has exactly seven `emitMetadataMutation` call sites
Tests 3 failed | 15 passed (18)
RESTORE: blob=fa53e5ac6b7ab5ff6d47aaf4e86ba7ba89352270 head=fa53e5ac6b7ab5ff6d47aaf4e86ba7ba89352270 anchor=1 emits=7 diff-bytes=0
RESTORE CONFIRMED BYTE-EXACT (blob == HEAD blob, git diff HEAD empty, anchor 1, emits 7)

Mechanics: the fix was committed first, so the restore leg had a real restore point; the mutation ran under an EXIT INT TERM trap whose paths are absolute (seeded from git rev-parse --show-toplevel, not from a cwd); the mutation is proved by anchored counts of the removed text and a blob hash that differs from HEAD's, never by perl -i's exit code; the restore is proved by git checkout HEAD -- path followed by a blob-hash match against the HEAD blob AND an empty git diff HEAD, never by an exit code. The first attempt of this script refused to run — its precondition read anchor=0 because the bracketed issue tag was being read as a regex character class — and that refusal is the design working: a zero-match mutation would otherwise have produced a fully green "ablation".

No rebuild is involved and that is itself a measurement: the pin file imports the same-package relative ./protocol.js, so vitest compiles src/protocol.ts. An ablation that goes red with no build is what proves it; a dist-resolved one would have stayed green.

Deliberately unchanged

• The row-absent exits stay silent. The repository path's miss, the legacy path's miss, and revertCommit's soft-remove limb over an already-gone row: nothing mutated, so nothing is announced. The soft-remove gate is if (current), mirroring the repository delete twin, whose row-absent exit has always been silent even though it still runs the self-heal. A deleted signal there would wake every peer to converge on a no-op. All three are pinned in §4.
• A draft save still announces draft.publishMetadataMutation owns the draft filter, not the doors; §4 pins that this change did not move that boundary.
• packages/spec and packages/metadata are untouched — the event shape needed no change. So is the runtime: TS-config boot registers a 'metadata' service without attachClusterPubSub — cross-node invalidation disabled; new object gives OBJECT_NOT_FOUND on non-writing replicas, never heals #13331 publish/subscribe seam, which was read and not edited.

Files, and one beyond the dispatched surface

• packages/metadata-protocol/src/protocol.ts — the three doors (four call sites), +60 lines, comments included.
• packages/metadata-protocol/src/protocol.recovery-doors-emit-mutation.test.ts — new, 18 cases.
• .changeset/recovery-doors-emit-metadata-mutation.md — @objectstack/metadata-protocol: patch.
• scripts/engine-double-contract.pinned.json — not on the dispatched file surface, declared here.check:engine-double-contract reds on a new pin file until the RETAINED ledger records it ("New pinned coverage is GOOD and nothing is wrong with your change — the ledger just has to learn about it, or it never protects this file"). Regenerated with that gate's own --write: 3 rows added, all naming the new test file, 0 lost, no other row touched. Reusing an existing double instead was not available — the file is new, so it has no double to override.

No existing sibling pin needed updating: the whole @objectstack/metadata-protocol suite is green unchanged (2125 passed), including the write-through-spelling call-site count, the cluster fan-out arms and the delete-rewrap envelope pins.

Gate union, run on e60660c3a

Derived on the real change set with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands after the last commit — 44 commands, 7 more than the dispatch's list because the ledger file above joined the diff (agent-test-spelling, bash32-floor, cli-command-ids, entry-guard, parse-guard, pnpm-filter-targets, watch-hint-literal; all seven PASS). Exit codes captured after a redirect, never through a pipe.

• pnpm --filter @objectstack/metadata-protocol test — PASS, 154 files passed / 2 skipped, 2125 tests passed / 10 skipped.
• pnpm --filter @objectstack/metadata-protocol typecheck — PASS (tsc --noEmit). The new pin file is inside that program: tsc --listFilesOnly lists it, 1 hit among 699 files.
• pnpm lint — PASS over the whole repo in 68s (eslint . --no-inline-config), so no narrowing was needed and none is claimed.
• pnpm check:nul-bytes — PASS (7859 files scanned), plus a manual control-character scan over the four changed paths: zero hits.
• The 44-command union: 40 PASS, 4 NOT MEASURED, 0 findings.

The four NOT MEASURED are exit-3 PREREQUISITE-NOT-MET, recorded with the gates' own words and read as neither pass nor finding — every one needs an input a per-package local run does not have, and CI supplies all four:

gate	its own verdict
check-test-completeness.mjs	"pass a saved turbo run test log — or, running the family locally, record this gate as NOT MEASURED"
pm/check-half-states.mjs	exit 3, an unread instrument (needs the GitHub board) — "never as a quiet board"
check:dual-build-cjs-loads	"PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/… Run pnpm build first. This is NOT a pass"
check:type-check-debt	"Build the closure first, exactly as lint.yml does… This is NOT a pass and NOT a finding"

Merge state

main landed 5 commits since this branch's base (5c9e40ad9 to 4485f7dad): CLI, lint, docs and three merge-driver scripts. None touches packages/metadata-protocol or packages/spec, so the AGENTS.md §10 re-check is scoped out rather than skipped, and the merge queue validates the merge commit itself. No other in-flight claude/issue-14* branch on origin touches protocol.ts (24 branches fetched and diffed against their merge-base at PR time), so the serial lane the dispatch declared is still clear.

Not this card

#13609 (a deleted datasource prolonging cluster-wide) is a different defect and is not addressed here: datasource carries allowOrgOverride: false, allowRuntimeCreate: true, so useRepoPath is true and it takes the repository exit, which has emitted since #2588. This branch changes nothing about it, and that card stays open on its own premise.

🤖 Generated with Claude Code

https://claude.ai/code/session_0112hMx9hjJ9BgB28X97DS68

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/metadata-protocol, touching 7 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/client-sdk.mdx(via meta.rollbackItem (sdk, the route ledger binds it to POST /api/v1/meta/:type/:name/rollback, selected by route anchor /:type/:name/rollback), rollbackItem (sdk, the bare tail of client method meta.rollbackItem, bound to POST /api/v1/meta/:type/:name/rollback))
• content/docs/kernel/contracts/metadata-service.mdx(via /:type/:name/rollback (route, bridged from symbol rollbackMetaItem — its registrar handler names it))
• content/docs/kernel/services-checklist.mdx(via deleteMetaItem (symbol, a method of class ObjectStackProtocolImplementation))

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 8 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from b2431d3164baf7f9401f96757f5f0beb6e663570 — the merge of head e60660c3a62281b5ef3edf397f1b2f50d4d3ec44 into base 41aa979295be112cc6c27fcd6cc6c5ac20c519d5, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin b2431d3164baf7f9401f96757f5f0beb6e663570 && git checkout b2431d3164baf7f9401f96757f5f0beb6e663570
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 e60660c3a62281b5ef3edf397f1b2f50d4d3ec44 && git checkout -B drift-repro 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 && git merge --no-ff e60660c3a62281b5ef3edf397f1b2f50d4d3ec44
node scripts/docs-audit/affected-docs.mjs --json 41aa979295be112cc6c27fcd6cc6c5ac20c519d5

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-musk]

Enqueue provenance (domain:engine execution seat, session_0112hMx9hjJ9BgB28X97DS68): ACCEPT on #14179 (comment 5504761434) → at 05:32Z every check run on head e60660c3a was completed with success or skipped (33 runs; Lint & Repo Gates finished 05:31Z), governed-surface test on the four changed paths: NOT governed, mergeable_state not dirty → marked ready and auto-merge (squash) enabled. Landing is by the merge queue; the engine seat follows it to MERGED.

---

Generated by Claude Code

[os-musk]

Fixes#14179

emitMetadataMutation documents itself as "the ONE choke point every authoring surface funnels through", and since the #13331 fan-out landed it is also the metadata.mutated cluster publish point. Three live write paths never reached it. Each now emits after its write, with the same org scope the write received and the same singular type key the registry was written under — mirroring the emitting siblings rather than inventing an event shape.

Verified at e60660c3a (the branch head this description describes; the gate union below was run on that same commit).

The three doors

door	reached by	before	after	pinned by
rollbackMetaItem, after its registry write-through	POST /api/v1/meta/:type/:name/rollback	write-through, no emit	emitMetadataMutation({ type: singularType, name, state: 'active', organizationId: orgId })	new file, §2 "announces the restored body on the mutation choke point" + "folds a PLURAL request type…"
revertCommit — RESTORE limb, after the per-item write-through	POST /packages/:id/commits/:commitId/revert	write-through, no emit	same event with PLURAL_TO_SINGULAR[it.type] ?? it.type, state: 'active', per-item itemOrgId	new file, §2 "RESTORE limb announces the pre-commit body it wrote back" + the mixed-batch case
revertCommit — SOFT-REMOVE limb, after repo.delete + restoreArtifactRegistryView	same door, items the commit created	delete + heal, no emit	same key/scope, state: 'deleted', gated on a row actually having been removed	new file, §2 "SOFT-REMOVE limb announces a deleted…" + §4's already-absent negative control
deleteMetaItem legacy raw-engine exit (the non-useRepoPath side)	DELETE /api/v1/meta/:type/:name on a control-plane bootstrap kernel	engine.delete + optional storage drop + heal, no emit	mirrors the repository twin exactly: state: 'deleted', singularTypeForRepo, request.organizationId ?? null	new file, §2 "announces the deletion it really performs" + "carries the org scope the delete predicate used"

Four call sites, three doors — revertCommit's two limbs are one door with two exits, exactly as the card's inventory counts it. this.emitMetadataMutation( call sites go 3 to 7; applyRegistryWriteThrough call sites stay at 5, so protocol.object-registry-write-through-spelling.test.ts's closed-caller-set pin is untouched and green.

Premise, re-measured

At the branch base 5c9e40ad9: git grep -n "applyRegistryWriteThrough(" -- packages/metadata-protocol/src/protocol.ts returns 6 hits, one of them the declaration at :13660 — FIVE call sites; the same grep for emitMetadataMutation( returns 4, one of them the declaration at :4962 — THREE call sites. The card's count holds.

One correction to the card's attribution of the fifth write-through: it sits inside applyRemoteMetadataMutation (the #13331 RECEIVE-side applier), not inside publishMetadataMutation (the publisher, which makes no write-through call at all). The substance is unchanged — it is the receive side, and it is deliberately not a door.

Reachability of the legacy delete exit — the NOT MEASURED item, now measured

The unblock comment recorded that it had not verified the branch's own docblock claim ("only reachable in control-plane bootstrap mode where environmentId is undefined"), noting correctly that useRepoPath does not itself test environmentId.

Measured: the claim holds, by a mechanism the docblock does not name. What confines the branch is the two-tier delete authorization above it, which runs only when environmentId !== undefined and refuses both limbs for exactly the types that would reach the legacy path:

• artifact-backed: artifactBacked AND NOT overlayAllowed AND NOT legacyOverlayRemoval produces NOT_OVERRIDABLE 403
• not artifact-backed: NOT artifactBacked AND NOT overlayAllowed AND NOT runtimeCreateAllowed produces NOT_CREATABLE 403

The #6960 carve-out is the only way past the first limb and it cannot apply: it reads supportsOverlay, and the useRepoPath === false set is exactly agent, api, capability, field, job — five of the registry's 27 entries, none of which carries supportsOverlay: true. Both 403s are driven end to end in §3, and the registry property itself is pinned there too, so a registry edit that opens the door has to come past this file.

So door 4's exposure is narrower than the comment feared: unreachable through the public deleteMetaItem on a normal boot. That is why its repair is pinned under bootstrap mode — which is where the defect is real, and where the registry every organization shares is the one being healed. The OS_METADATA_WRITABLE escape hatch only moves a type ONTO the repository (emitting) path, never onto this one; the harness clears its memoised cache so that cannot silently change what is measured.

The receive path stays silent — cited, not duplicated

Adding an emit inside applyRemoteMetadataMutation would re-broadcast every received event and ping-pong across replicas, which the loopback guard (own-messages only) cannot stop. That negative is already pinned in protocol.cluster-mutation-fanout.test.ts, in "the peer's onMetadataMutation listeners receive the remote event, once, after convergence": expect(writerSeen).toHaveLength(1), commented "the remote replay stays local to the receiving node (no echo)". A peer that re-emitted would re-publish, the writer would apply that peer-origin message past its own loopback guard, and that assertion would read 2. It is cited rather than re-built.

Alongside it, §5 of the new file carries three structural pins that make the same claim locally and cheaply: the emitMetadataMutation call-site count is 7, notifyMutationListenersLocal keeps exactly its two declared callers (the choke point and the receive path), and applyRemoteMetadataMutation's body contains notifyMutationListenersLocal and does not contain emitMetadataMutation.

The cluster half is inherited, not re-measured

emitMetadataMutation is two lines — the local fan-out, then publishMetadataMutation — so a door that reaches the choke point reaches the publisher. protocol.cluster-mutation-fanout.test.ts already proves that end to end over a two-replica pub/sub double (Arm B, "a runtime-authored object registers on the PEER after the writer's save", with Arm A as the no-bridge control). Combined with §5's call-site count, the new doors inherit the cluster leg structurally. Building a second cluster harness here would re-measure that file's subject rather than this card's, so it is not built.

Ablation — direction declared before the run, in the committed test header

Declared (commit 43640d6c6, before running): removing door 1's emit from protocol.ts turns RED both of §2's rollback cases and §5's call-site count, and leaves everything else GREEN — 3 RED / 15 GREEN of 18.

Measured, exactly that:

BEFORE: anchor=1 emit-call-sites=7
AFTER: anchor=0 emit-call-sites=6 blob=ba5fa53549caa6a282bb325a2ae93f62a47fcdc6
MUTATION CONFIRMED ON DISK (anchor 1->0, emit sites 7->6, blob differs from HEAD)
x announces the restored body on the mutation choke point
x folds a PLURAL request type to the singular the write-through registered under
x has exactly seven `emitMetadataMutation` call sites
Tests 3 failed | 15 passed (18)
RESTORE: blob=fa53e5ac6b7ab5ff6d47aaf4e86ba7ba89352270 head=fa53e5ac6b7ab5ff6d47aaf4e86ba7ba89352270 anchor=1 emits=7 diff-bytes=0
RESTORE CONFIRMED BYTE-EXACT (blob == HEAD blob, git diff HEAD empty, anchor 1, emits 7)

Mechanics: the fix was committed first, so the restore leg had a real restore point; the mutation ran under an EXIT INT TERM trap whose paths are absolute (seeded from git rev-parse --show-toplevel, not from a cwd); the mutation is proved by anchored counts of the removed text and a blob hash that differs from HEAD's, never by perl -i's exit code; the restore is proved by git checkout HEAD -- path followed by a blob-hash match against the HEAD blob AND an empty git diff HEAD, never by an exit code. The first attempt of this script refused to run — its precondition read anchor=0 because the bracketed issue tag was being read as a regex character class — and that refusal is the design working: a zero-match mutation would otherwise have produced a fully green "ablation".

No rebuild is involved and that is itself a measurement: the pin file imports the same-package relative ./protocol.js, so vitest compiles src/protocol.ts. An ablation that goes red with no build is what proves it; a dist-resolved one would have stayed green.

Deliberately unchanged

• The row-absent exits stay silent. The repository path's miss, the legacy path's miss, and revertCommit's soft-remove limb over an already-gone row: nothing mutated, so nothing is announced. The soft-remove gate is if (current), mirroring the repository delete twin, whose row-absent exit has always been silent even though it still runs the self-heal. A deleted signal there would wake every peer to converge on a no-op. All three are pinned in §4.
• A draft save still announces draft.publishMetadataMutation owns the draft filter, not the doors; §4 pins that this change did not move that boundary.
• packages/spec and packages/metadata are untouched — the event shape needed no change. So is the runtime: TS-config boot registers a 'metadata' service without attachClusterPubSub — cross-node invalidation disabled; new object gives OBJECT_NOT_FOUND on non-writing replicas, never heals #13331 publish/subscribe seam, which was read and not edited.

Files, and one beyond the dispatched surface

• packages/metadata-protocol/src/protocol.ts — the three doors (four call sites), +60 lines, comments included.
• packages/metadata-protocol/src/protocol.recovery-doors-emit-mutation.test.ts — new, 18 cases.
• .changeset/recovery-doors-emit-metadata-mutation.md — @objectstack/metadata-protocol: patch.
• scripts/engine-double-contract.pinned.json — not on the dispatched file surface, declared here.check:engine-double-contract reds on a new pin file until the RETAINED ledger records it ("New pinned coverage is GOOD and nothing is wrong with your change — the ledger just has to learn about it, or it never protects this file"). Regenerated with that gate's own --write: 3 rows added, all naming the new test file, 0 lost, no other row touched. Reusing an existing double instead was not available — the file is new, so it has no double to override.

No existing sibling pin needed updating: the whole @objectstack/metadata-protocol suite is green unchanged (2125 passed), including the write-through-spelling call-site count, the cluster fan-out arms and the delete-rewrap envelope pins.

Gate union, run on e60660c3a

Derived on the real change set with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands after the last commit — 44 commands, 7 more than the dispatch's list because the ledger file above joined the diff (agent-test-spelling, bash32-floor, cli-command-ids, entry-guard, parse-guard, pnpm-filter-targets, watch-hint-literal; all seven PASS). Exit codes captured after a redirect, never through a pipe.

• pnpm --filter @objectstack/metadata-protocol test — PASS, 154 files passed / 2 skipped, 2125 tests passed / 10 skipped.
• pnpm --filter @objectstack/metadata-protocol typecheck — PASS (tsc --noEmit). The new pin file is inside that program: tsc --listFilesOnly lists it, 1 hit among 699 files.
• pnpm lint — PASS over the whole repo in 68s (eslint . --no-inline-config), so no narrowing was needed and none is claimed.
• pnpm check:nul-bytes — PASS (7859 files scanned), plus a manual control-character scan over the four changed paths: zero hits.
• The 44-command union: 40 PASS, 4 NOT MEASURED, 0 findings.

The four NOT MEASURED are exit-3 PREREQUISITE-NOT-MET, recorded with the gates' own words and read as neither pass nor finding — every one needs an input a per-package local run does not have, and CI supplies all four:

gate	its own verdict
check-test-completeness.mjs	"pass a saved turbo run test log — or, running the family locally, record this gate as NOT MEASURED"
pm/check-half-states.mjs	exit 3, an unread instrument (needs the GitHub board) — "never as a quiet board"
check:dual-build-cjs-loads	"PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/… Run pnpm build first. This is NOT a pass"
check:type-check-debt	"Build the closure first, exactly as lint.yml does… This is NOT a pass and NOT a finding"

Merge state

main landed 5 commits since this branch's base (5c9e40ad9 to 4485f7dad): CLI, lint, docs and three merge-driver scripts. None touches packages/metadata-protocol or packages/spec, so the AGENTS.md §10 re-check is scoped out rather than skipped, and the merge queue validates the merge commit itself. No other in-flight claude/issue-14* branch on origin touches protocol.ts (24 branches fetched and diffed against their merge-base at PR time), so the serial lane the dispatch declared is still clear.

Not this card

#13609 (a deleted datasource prolonging cluster-wide) is a different defect and is not addressed here: datasource carries allowOrgOverride: false, allowRuntimeCreate: true, so useRepoPath is true and it takes the repository exit, which has emitted since #2588. This branch changes nothing about it, and that card stays open on its own premise.

🤖 Generated with Claude Code

https://claude.ai/code/session_0112hMx9hjJ9BgB28X97DS68

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/metadata-protocol, touching 7 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/client-sdk.mdx(via meta.rollbackItem (sdk, the route ledger binds it to POST /api/v1/meta/:type/:name/rollback, selected by route anchor /:type/:name/rollback), rollbackItem (sdk, the bare tail of client method meta.rollbackItem, bound to POST /api/v1/meta/:type/:name/rollback))
• content/docs/kernel/contracts/metadata-service.mdx(via /:type/:name/rollback (route, bridged from symbol rollbackMetaItem — its registrar handler names it))
• content/docs/kernel/services-checklist.mdx(via deleteMetaItem (symbol, a method of class ObjectStackProtocolImplementation))

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 8 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from b2431d3164baf7f9401f96757f5f0beb6e663570 — the merge of head e60660c3a62281b5ef3edf397f1b2f50d4d3ec44 into base 41aa979295be112cc6c27fcd6cc6c5ac20c519d5, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin b2431d3164baf7f9401f96757f5f0beb6e663570 && git checkout b2431d3164baf7f9401f96757f5f0beb6e663570
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 e60660c3a62281b5ef3edf397f1b2f50d4d3ec44 && git checkout -B drift-repro 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 && git merge --no-ff e60660c3a62281b5ef3edf397f1b2f50d4d3ec44
node scripts/docs-audit/affected-docs.mjs --json 41aa979295be112cc6c27fcd6cc6c5ac20c519d5

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-musk]

Enqueue provenance (domain:engine execution seat, session_0112hMx9hjJ9BgB28X97DS68): ACCEPT on #14179 (comment 5504761434) → at 05:32Z every check run on head e60660c3a was completed with success or skipped (33 runs; Lint & Repo Gates finished 05:31Z), governed-surface test on the four changed paths: NOT governed, mergeable_state not dirty → marked ready and auto-merge (squash) enabled. Landing is by the merge queue; the engine seat follows it to MERGED.

---

Generated by Claude Code

[os-musk]

Fixes#14179

emitMetadataMutation documents itself as "the ONE choke point every authoring surface funnels through", and since the #13331 fan-out landed it is also the metadata.mutated cluster publish point. Three live write paths never reached it. Each now emits after its write, with the same org scope the write received and the same singular type key the registry was written under — mirroring the emitting siblings rather than inventing an event shape.

Verified at e60660c3a (the branch head this description describes; the gate union below was run on that same commit).

The three doors

door	reached by	before	after	pinned by
rollbackMetaItem, after its registry write-through	POST /api/v1/meta/:type/:name/rollback	write-through, no emit	emitMetadataMutation({ type: singularType, name, state: 'active', organizationId: orgId })	new file, §2 "announces the restored body on the mutation choke point" + "folds a PLURAL request type…"
revertCommit — RESTORE limb, after the per-item write-through	POST /packages/:id/commits/:commitId/revert	write-through, no emit	same event with PLURAL_TO_SINGULAR[it.type] ?? it.type, state: 'active', per-item itemOrgId	new file, §2 "RESTORE limb announces the pre-commit body it wrote back" + the mixed-batch case
revertCommit — SOFT-REMOVE limb, after repo.delete + restoreArtifactRegistryView	same door, items the commit created	delete + heal, no emit	same key/scope, state: 'deleted', gated on a row actually having been removed	new file, §2 "SOFT-REMOVE limb announces a deleted…" + §4's already-absent negative control
deleteMetaItem legacy raw-engine exit (the non-useRepoPath side)	DELETE /api/v1/meta/:type/:name on a control-plane bootstrap kernel	engine.delete + optional storage drop + heal, no emit	mirrors the repository twin exactly: state: 'deleted', singularTypeForRepo, request.organizationId ?? null	new file, §2 "announces the deletion it really performs" + "carries the org scope the delete predicate used"

Four call sites, three doors — revertCommit's two limbs are one door with two exits, exactly as the card's inventory counts it. this.emitMetadataMutation( call sites go 3 to 7; applyRegistryWriteThrough call sites stay at 5, so protocol.object-registry-write-through-spelling.test.ts's closed-caller-set pin is untouched and green.

Premise, re-measured

At the branch base 5c9e40ad9: git grep -n "applyRegistryWriteThrough(" -- packages/metadata-protocol/src/protocol.ts returns 6 hits, one of them the declaration at :13660 — FIVE call sites; the same grep for emitMetadataMutation( returns 4, one of them the declaration at :4962 — THREE call sites. The card's count holds.

One correction to the card's attribution of the fifth write-through: it sits inside applyRemoteMetadataMutation (the #13331 RECEIVE-side applier), not inside publishMetadataMutation (the publisher, which makes no write-through call at all). The substance is unchanged — it is the receive side, and it is deliberately not a door.

Reachability of the legacy delete exit — the NOT MEASURED item, now measured

The unblock comment recorded that it had not verified the branch's own docblock claim ("only reachable in control-plane bootstrap mode where environmentId is undefined"), noting correctly that useRepoPath does not itself test environmentId.

Measured: the claim holds, by a mechanism the docblock does not name. What confines the branch is the two-tier delete authorization above it, which runs only when environmentId !== undefined and refuses both limbs for exactly the types that would reach the legacy path:

• artifact-backed: artifactBacked AND NOT overlayAllowed AND NOT legacyOverlayRemoval produces NOT_OVERRIDABLE 403
• not artifact-backed: NOT artifactBacked AND NOT overlayAllowed AND NOT runtimeCreateAllowed produces NOT_CREATABLE 403

The #6960 carve-out is the only way past the first limb and it cannot apply: it reads supportsOverlay, and the useRepoPath === false set is exactly agent, api, capability, field, job — five of the registry's 27 entries, none of which carries supportsOverlay: true. Both 403s are driven end to end in §3, and the registry property itself is pinned there too, so a registry edit that opens the door has to come past this file.

So door 4's exposure is narrower than the comment feared: unreachable through the public deleteMetaItem on a normal boot. That is why its repair is pinned under bootstrap mode — which is where the defect is real, and where the registry every organization shares is the one being healed. The OS_METADATA_WRITABLE escape hatch only moves a type ONTO the repository (emitting) path, never onto this one; the harness clears its memoised cache so that cannot silently change what is measured.

The receive path stays silent — cited, not duplicated

Adding an emit inside applyRemoteMetadataMutation would re-broadcast every received event and ping-pong across replicas, which the loopback guard (own-messages only) cannot stop. That negative is already pinned in protocol.cluster-mutation-fanout.test.ts, in "the peer's onMetadataMutation listeners receive the remote event, once, after convergence": expect(writerSeen).toHaveLength(1), commented "the remote replay stays local to the receiving node (no echo)". A peer that re-emitted would re-publish, the writer would apply that peer-origin message past its own loopback guard, and that assertion would read 2. It is cited rather than re-built.

Alongside it, §5 of the new file carries three structural pins that make the same claim locally and cheaply: the emitMetadataMutation call-site count is 7, notifyMutationListenersLocal keeps exactly its two declared callers (the choke point and the receive path), and applyRemoteMetadataMutation's body contains notifyMutationListenersLocal and does not contain emitMetadataMutation.

The cluster half is inherited, not re-measured

emitMetadataMutation is two lines — the local fan-out, then publishMetadataMutation — so a door that reaches the choke point reaches the publisher. protocol.cluster-mutation-fanout.test.ts already proves that end to end over a two-replica pub/sub double (Arm B, "a runtime-authored object registers on the PEER after the writer's save", with Arm A as the no-bridge control). Combined with §5's call-site count, the new doors inherit the cluster leg structurally. Building a second cluster harness here would re-measure that file's subject rather than this card's, so it is not built.

Ablation — direction declared before the run, in the committed test header

Declared (commit 43640d6c6, before running): removing door 1's emit from protocol.ts turns RED both of §2's rollback cases and §5's call-site count, and leaves everything else GREEN — 3 RED / 15 GREEN of 18.

Measured, exactly that:

BEFORE: anchor=1 emit-call-sites=7
AFTER: anchor=0 emit-call-sites=6 blob=ba5fa53549caa6a282bb325a2ae93f62a47fcdc6
MUTATION CONFIRMED ON DISK (anchor 1->0, emit sites 7->6, blob differs from HEAD)
x announces the restored body on the mutation choke point
x folds a PLURAL request type to the singular the write-through registered under
x has exactly seven `emitMetadataMutation` call sites
Tests 3 failed | 15 passed (18)
RESTORE: blob=fa53e5ac6b7ab5ff6d47aaf4e86ba7ba89352270 head=fa53e5ac6b7ab5ff6d47aaf4e86ba7ba89352270 anchor=1 emits=7 diff-bytes=0
RESTORE CONFIRMED BYTE-EXACT (blob == HEAD blob, git diff HEAD empty, anchor 1, emits 7)

Mechanics: the fix was committed first, so the restore leg had a real restore point; the mutation ran under an EXIT INT TERM trap whose paths are absolute (seeded from git rev-parse --show-toplevel, not from a cwd); the mutation is proved by anchored counts of the removed text and a blob hash that differs from HEAD's, never by perl -i's exit code; the restore is proved by git checkout HEAD -- path followed by a blob-hash match against the HEAD blob AND an empty git diff HEAD, never by an exit code. The first attempt of this script refused to run — its precondition read anchor=0 because the bracketed issue tag was being read as a regex character class — and that refusal is the design working: a zero-match mutation would otherwise have produced a fully green "ablation".

No rebuild is involved and that is itself a measurement: the pin file imports the same-package relative ./protocol.js, so vitest compiles src/protocol.ts. An ablation that goes red with no build is what proves it; a dist-resolved one would have stayed green.

Deliberately unchanged

• The row-absent exits stay silent. The repository path's miss, the legacy path's miss, and revertCommit's soft-remove limb over an already-gone row: nothing mutated, so nothing is announced. The soft-remove gate is if (current), mirroring the repository delete twin, whose row-absent exit has always been silent even though it still runs the self-heal. A deleted signal there would wake every peer to converge on a no-op. All three are pinned in §4.
• A draft save still announces draft.publishMetadataMutation owns the draft filter, not the doors; §4 pins that this change did not move that boundary.
• packages/spec and packages/metadata are untouched — the event shape needed no change. So is the runtime: TS-config boot registers a 'metadata' service without attachClusterPubSub — cross-node invalidation disabled; new object gives OBJECT_NOT_FOUND on non-writing replicas, never heals #13331 publish/subscribe seam, which was read and not edited.

Files, and one beyond the dispatched surface

• packages/metadata-protocol/src/protocol.ts — the three doors (four call sites), +60 lines, comments included.
• packages/metadata-protocol/src/protocol.recovery-doors-emit-mutation.test.ts — new, 18 cases.
• .changeset/recovery-doors-emit-metadata-mutation.md — @objectstack/metadata-protocol: patch.
• scripts/engine-double-contract.pinned.json — not on the dispatched file surface, declared here.check:engine-double-contract reds on a new pin file until the RETAINED ledger records it ("New pinned coverage is GOOD and nothing is wrong with your change — the ledger just has to learn about it, or it never protects this file"). Regenerated with that gate's own --write: 3 rows added, all naming the new test file, 0 lost, no other row touched. Reusing an existing double instead was not available — the file is new, so it has no double to override.

No existing sibling pin needed updating: the whole @objectstack/metadata-protocol suite is green unchanged (2125 passed), including the write-through-spelling call-site count, the cluster fan-out arms and the delete-rewrap envelope pins.

Gate union, run on e60660c3a

Derived on the real change set with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands after the last commit — 44 commands, 7 more than the dispatch's list because the ledger file above joined the diff (agent-test-spelling, bash32-floor, cli-command-ids, entry-guard, parse-guard, pnpm-filter-targets, watch-hint-literal; all seven PASS). Exit codes captured after a redirect, never through a pipe.

• pnpm --filter @objectstack/metadata-protocol test — PASS, 154 files passed / 2 skipped, 2125 tests passed / 10 skipped.
• pnpm --filter @objectstack/metadata-protocol typecheck — PASS (tsc --noEmit). The new pin file is inside that program: tsc --listFilesOnly lists it, 1 hit among 699 files.
• pnpm lint — PASS over the whole repo in 68s (eslint . --no-inline-config), so no narrowing was needed and none is claimed.
• pnpm check:nul-bytes — PASS (7859 files scanned), plus a manual control-character scan over the four changed paths: zero hits.
• The 44-command union: 40 PASS, 4 NOT MEASURED, 0 findings.

The four NOT MEASURED are exit-3 PREREQUISITE-NOT-MET, recorded with the gates' own words and read as neither pass nor finding — every one needs an input a per-package local run does not have, and CI supplies all four:

gate	its own verdict
check-test-completeness.mjs	"pass a saved turbo run test log — or, running the family locally, record this gate as NOT MEASURED"
pm/check-half-states.mjs	exit 3, an unread instrument (needs the GitHub board) — "never as a quiet board"
check:dual-build-cjs-loads	"PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/… Run pnpm build first. This is NOT a pass"
check:type-check-debt	"Build the closure first, exactly as lint.yml does… This is NOT a pass and NOT a finding"

Merge state

main landed 5 commits since this branch's base (5c9e40ad9 to 4485f7dad): CLI, lint, docs and three merge-driver scripts. None touches packages/metadata-protocol or packages/spec, so the AGENTS.md §10 re-check is scoped out rather than skipped, and the merge queue validates the merge commit itself. No other in-flight claude/issue-14* branch on origin touches protocol.ts (24 branches fetched and diffed against their merge-base at PR time), so the serial lane the dispatch declared is still clear.

Not this card

#13609 (a deleted datasource prolonging cluster-wide) is a different defect and is not addressed here: datasource carries allowOrgOverride: false, allowRuntimeCreate: true, so useRepoPath is true and it takes the repository exit, which has emitted since #2588. This branch changes nothing about it, and that card stays open on its own premise.

🤖 Generated with Claude Code

https://claude.ai/code/session_0112hMx9hjJ9BgB28X97DS68

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/metadata-protocol, touching 7 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/client-sdk.mdx(via meta.rollbackItem (sdk, the route ledger binds it to POST /api/v1/meta/:type/:name/rollback, selected by route anchor /:type/:name/rollback), rollbackItem (sdk, the bare tail of client method meta.rollbackItem, bound to POST /api/v1/meta/:type/:name/rollback))
• content/docs/kernel/contracts/metadata-service.mdx(via /:type/:name/rollback (route, bridged from symbol rollbackMetaItem — its registrar handler names it))
• content/docs/kernel/services-checklist.mdx(via deleteMetaItem (symbol, a method of class ObjectStackProtocolImplementation))

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 8 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from b2431d3164baf7f9401f96757f5f0beb6e663570 — the merge of head e60660c3a62281b5ef3edf397f1b2f50d4d3ec44 into base 41aa979295be112cc6c27fcd6cc6c5ac20c519d5, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin b2431d3164baf7f9401f96757f5f0beb6e663570 && git checkout b2431d3164baf7f9401f96757f5f0beb6e663570
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 e60660c3a62281b5ef3edf397f1b2f50d4d3ec44 && git checkout -B drift-repro 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 && git merge --no-ff e60660c3a62281b5ef3edf397f1b2f50d4d3ec44
node scripts/docs-audit/affected-docs.mjs --json 41aa979295be112cc6c27fcd6cc6c5ac20c519d5

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-musk]

Enqueue provenance (domain:engine execution seat, session_0112hMx9hjJ9BgB28X97DS68): ACCEPT on #14179 (comment 5504761434) → at 05:32Z every check run on head e60660c3a was completed with success or skipped (33 runs; Lint & Repo Gates finished 05:31Z), governed-surface test on the four changed paths: NOT governed, mergeable_state not dirty → marked ready and auto-merge (squash) enabled. Landing is by the merge queue; the engine seat follows it to MERGED.

---

Generated by Claude Code

[os-musk]

Fixes#14179

emitMetadataMutation documents itself as "the ONE choke point every authoring surface funnels through", and since the #13331 fan-out landed it is also the metadata.mutated cluster publish point. Three live write paths never reached it. Each now emits after its write, with the same org scope the write received and the same singular type key the registry was written under — mirroring the emitting siblings rather than inventing an event shape.

Verified at e60660c3a (the branch head this description describes; the gate union below was run on that same commit).

The three doors

door	reached by	before	after	pinned by
rollbackMetaItem, after its registry write-through	POST /api/v1/meta/:type/:name/rollback	write-through, no emit	emitMetadataMutation({ type: singularType, name, state: 'active', organizationId: orgId })	new file, §2 "announces the restored body on the mutation choke point" + "folds a PLURAL request type…"
revertCommit — RESTORE limb, after the per-item write-through	POST /packages/:id/commits/:commitId/revert	write-through, no emit	same event with PLURAL_TO_SINGULAR[it.type] ?? it.type, state: 'active', per-item itemOrgId	new file, §2 "RESTORE limb announces the pre-commit body it wrote back" + the mixed-batch case
revertCommit — SOFT-REMOVE limb, after repo.delete + restoreArtifactRegistryView	same door, items the commit created	delete + heal, no emit	same key/scope, state: 'deleted', gated on a row actually having been removed	new file, §2 "SOFT-REMOVE limb announces a deleted…" + §4's already-absent negative control
deleteMetaItem legacy raw-engine exit (the non-useRepoPath side)	DELETE /api/v1/meta/:type/:name on a control-plane bootstrap kernel	engine.delete + optional storage drop + heal, no emit	mirrors the repository twin exactly: state: 'deleted', singularTypeForRepo, request.organizationId ?? null	new file, §2 "announces the deletion it really performs" + "carries the org scope the delete predicate used"

Four call sites, three doors — revertCommit's two limbs are one door with two exits, exactly as the card's inventory counts it. this.emitMetadataMutation( call sites go 3 to 7; applyRegistryWriteThrough call sites stay at 5, so protocol.object-registry-write-through-spelling.test.ts's closed-caller-set pin is untouched and green.

Premise, re-measured

At the branch base 5c9e40ad9: git grep -n "applyRegistryWriteThrough(" -- packages/metadata-protocol/src/protocol.ts returns 6 hits, one of them the declaration at :13660 — FIVE call sites; the same grep for emitMetadataMutation( returns 4, one of them the declaration at :4962 — THREE call sites. The card's count holds.

One correction to the card's attribution of the fifth write-through: it sits inside applyRemoteMetadataMutation (the #13331 RECEIVE-side applier), not inside publishMetadataMutation (the publisher, which makes no write-through call at all). The substance is unchanged — it is the receive side, and it is deliberately not a door.

Reachability of the legacy delete exit — the NOT MEASURED item, now measured

The unblock comment recorded that it had not verified the branch's own docblock claim ("only reachable in control-plane bootstrap mode where environmentId is undefined"), noting correctly that useRepoPath does not itself test environmentId.

Measured: the claim holds, by a mechanism the docblock does not name. What confines the branch is the two-tier delete authorization above it, which runs only when environmentId !== undefined and refuses both limbs for exactly the types that would reach the legacy path:

• artifact-backed: artifactBacked AND NOT overlayAllowed AND NOT legacyOverlayRemoval produces NOT_OVERRIDABLE 403
• not artifact-backed: NOT artifactBacked AND NOT overlayAllowed AND NOT runtimeCreateAllowed produces NOT_CREATABLE 403

The #6960 carve-out is the only way past the first limb and it cannot apply: it reads supportsOverlay, and the useRepoPath === false set is exactly agent, api, capability, field, job — five of the registry's 27 entries, none of which carries supportsOverlay: true. Both 403s are driven end to end in §3, and the registry property itself is pinned there too, so a registry edit that opens the door has to come past this file.

So door 4's exposure is narrower than the comment feared: unreachable through the public deleteMetaItem on a normal boot. That is why its repair is pinned under bootstrap mode — which is where the defect is real, and where the registry every organization shares is the one being healed. The OS_METADATA_WRITABLE escape hatch only moves a type ONTO the repository (emitting) path, never onto this one; the harness clears its memoised cache so that cannot silently change what is measured.

The receive path stays silent — cited, not duplicated

Adding an emit inside applyRemoteMetadataMutation would re-broadcast every received event and ping-pong across replicas, which the loopback guard (own-messages only) cannot stop. That negative is already pinned in protocol.cluster-mutation-fanout.test.ts, in "the peer's onMetadataMutation listeners receive the remote event, once, after convergence": expect(writerSeen).toHaveLength(1), commented "the remote replay stays local to the receiving node (no echo)". A peer that re-emitted would re-publish, the writer would apply that peer-origin message past its own loopback guard, and that assertion would read 2. It is cited rather than re-built.

Alongside it, §5 of the new file carries three structural pins that make the same claim locally and cheaply: the emitMetadataMutation call-site count is 7, notifyMutationListenersLocal keeps exactly its two declared callers (the choke point and the receive path), and applyRemoteMetadataMutation's body contains notifyMutationListenersLocal and does not contain emitMetadataMutation.

The cluster half is inherited, not re-measured

emitMetadataMutation is two lines — the local fan-out, then publishMetadataMutation — so a door that reaches the choke point reaches the publisher. protocol.cluster-mutation-fanout.test.ts already proves that end to end over a two-replica pub/sub double (Arm B, "a runtime-authored object registers on the PEER after the writer's save", with Arm A as the no-bridge control). Combined with §5's call-site count, the new doors inherit the cluster leg structurally. Building a second cluster harness here would re-measure that file's subject rather than this card's, so it is not built.

Ablation — direction declared before the run, in the committed test header

Declared (commit 43640d6c6, before running): removing door 1's emit from protocol.ts turns RED both of §2's rollback cases and §5's call-site count, and leaves everything else GREEN — 3 RED / 15 GREEN of 18.

Measured, exactly that:

BEFORE: anchor=1 emit-call-sites=7
AFTER: anchor=0 emit-call-sites=6 blob=ba5fa53549caa6a282bb325a2ae93f62a47fcdc6
MUTATION CONFIRMED ON DISK (anchor 1->0, emit sites 7->6, blob differs from HEAD)
x announces the restored body on the mutation choke point
x folds a PLURAL request type to the singular the write-through registered under
x has exactly seven `emitMetadataMutation` call sites
Tests 3 failed | 15 passed (18)
RESTORE: blob=fa53e5ac6b7ab5ff6d47aaf4e86ba7ba89352270 head=fa53e5ac6b7ab5ff6d47aaf4e86ba7ba89352270 anchor=1 emits=7 diff-bytes=0
RESTORE CONFIRMED BYTE-EXACT (blob == HEAD blob, git diff HEAD empty, anchor 1, emits 7)

Mechanics: the fix was committed first, so the restore leg had a real restore point; the mutation ran under an EXIT INT TERM trap whose paths are absolute (seeded from git rev-parse --show-toplevel, not from a cwd); the mutation is proved by anchored counts of the removed text and a blob hash that differs from HEAD's, never by perl -i's exit code; the restore is proved by git checkout HEAD -- path followed by a blob-hash match against the HEAD blob AND an empty git diff HEAD, never by an exit code. The first attempt of this script refused to run — its precondition read anchor=0 because the bracketed issue tag was being read as a regex character class — and that refusal is the design working: a zero-match mutation would otherwise have produced a fully green "ablation".

No rebuild is involved and that is itself a measurement: the pin file imports the same-package relative ./protocol.js, so vitest compiles src/protocol.ts. An ablation that goes red with no build is what proves it; a dist-resolved one would have stayed green.

Deliberately unchanged

• The row-absent exits stay silent. The repository path's miss, the legacy path's miss, and revertCommit's soft-remove limb over an already-gone row: nothing mutated, so nothing is announced. The soft-remove gate is if (current), mirroring the repository delete twin, whose row-absent exit has always been silent even though it still runs the self-heal. A deleted signal there would wake every peer to converge on a no-op. All three are pinned in §4.
• A draft save still announces draft.publishMetadataMutation owns the draft filter, not the doors; §4 pins that this change did not move that boundary.
• packages/spec and packages/metadata are untouched — the event shape needed no change. So is the runtime: TS-config boot registers a 'metadata' service without attachClusterPubSub — cross-node invalidation disabled; new object gives OBJECT_NOT_FOUND on non-writing replicas, never heals #13331 publish/subscribe seam, which was read and not edited.

Files, and one beyond the dispatched surface

• packages/metadata-protocol/src/protocol.ts — the three doors (four call sites), +60 lines, comments included.
• packages/metadata-protocol/src/protocol.recovery-doors-emit-mutation.test.ts — new, 18 cases.
• .changeset/recovery-doors-emit-metadata-mutation.md — @objectstack/metadata-protocol: patch.
• scripts/engine-double-contract.pinned.json — not on the dispatched file surface, declared here.check:engine-double-contract reds on a new pin file until the RETAINED ledger records it ("New pinned coverage is GOOD and nothing is wrong with your change — the ledger just has to learn about it, or it never protects this file"). Regenerated with that gate's own --write: 3 rows added, all naming the new test file, 0 lost, no other row touched. Reusing an existing double instead was not available — the file is new, so it has no double to override.

No existing sibling pin needed updating: the whole @objectstack/metadata-protocol suite is green unchanged (2125 passed), including the write-through-spelling call-site count, the cluster fan-out arms and the delete-rewrap envelope pins.

Gate union, run on e60660c3a

Derived on the real change set with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands after the last commit — 44 commands, 7 more than the dispatch's list because the ledger file above joined the diff (agent-test-spelling, bash32-floor, cli-command-ids, entry-guard, parse-guard, pnpm-filter-targets, watch-hint-literal; all seven PASS). Exit codes captured after a redirect, never through a pipe.

• pnpm --filter @objectstack/metadata-protocol test — PASS, 154 files passed / 2 skipped, 2125 tests passed / 10 skipped.
• pnpm --filter @objectstack/metadata-protocol typecheck — PASS (tsc --noEmit). The new pin file is inside that program: tsc --listFilesOnly lists it, 1 hit among 699 files.
• pnpm lint — PASS over the whole repo in 68s (eslint . --no-inline-config), so no narrowing was needed and none is claimed.
• pnpm check:nul-bytes — PASS (7859 files scanned), plus a manual control-character scan over the four changed paths: zero hits.
• The 44-command union: 40 PASS, 4 NOT MEASURED, 0 findings.

The four NOT MEASURED are exit-3 PREREQUISITE-NOT-MET, recorded with the gates' own words and read as neither pass nor finding — every one needs an input a per-package local run does not have, and CI supplies all four:

gate	its own verdict
check-test-completeness.mjs	"pass a saved turbo run test log — or, running the family locally, record this gate as NOT MEASURED"
pm/check-half-states.mjs	exit 3, an unread instrument (needs the GitHub board) — "never as a quiet board"
check:dual-build-cjs-loads	"PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/… Run pnpm build first. This is NOT a pass"
check:type-check-debt	"Build the closure first, exactly as lint.yml does… This is NOT a pass and NOT a finding"

Merge state

main landed 5 commits since this branch's base (5c9e40ad9 to 4485f7dad): CLI, lint, docs and three merge-driver scripts. None touches packages/metadata-protocol or packages/spec, so the AGENTS.md §10 re-check is scoped out rather than skipped, and the merge queue validates the merge commit itself. No other in-flight claude/issue-14* branch on origin touches protocol.ts (24 branches fetched and diffed against their merge-base at PR time), so the serial lane the dispatch declared is still clear.

Not this card

#13609 (a deleted datasource prolonging cluster-wide) is a different defect and is not addressed here: datasource carries allowOrgOverride: false, allowRuntimeCreate: true, so useRepoPath is true and it takes the repository exit, which has emitted since #2588. This branch changes nothing about it, and that card stays open on its own premise.

🤖 Generated with Claude Code

https://claude.ai/code/session_0112hMx9hjJ9BgB28X97DS68

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/metadata-protocol, touching 7 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/client-sdk.mdx(via meta.rollbackItem (sdk, the route ledger binds it to POST /api/v1/meta/:type/:name/rollback, selected by route anchor /:type/:name/rollback), rollbackItem (sdk, the bare tail of client method meta.rollbackItem, bound to POST /api/v1/meta/:type/:name/rollback))
• content/docs/kernel/contracts/metadata-service.mdx(via /:type/:name/rollback (route, bridged from symbol rollbackMetaItem — its registrar handler names it))
• content/docs/kernel/services-checklist.mdx(via deleteMetaItem (symbol, a method of class ObjectStackProtocolImplementation))

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 8 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from b2431d3164baf7f9401f96757f5f0beb6e663570 — the merge of head e60660c3a62281b5ef3edf397f1b2f50d4d3ec44 into base 41aa979295be112cc6c27fcd6cc6c5ac20c519d5, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin b2431d3164baf7f9401f96757f5f0beb6e663570 && git checkout b2431d3164baf7f9401f96757f5f0beb6e663570
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 e60660c3a62281b5ef3edf397f1b2f50d4d3ec44 && git checkout -B drift-repro 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 && git merge --no-ff e60660c3a62281b5ef3edf397f1b2f50d4d3ec44
node scripts/docs-audit/affected-docs.mjs --json 41aa979295be112cc6c27fcd6cc6c5ac20c519d5

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-musk]

Enqueue provenance (domain:engine execution seat, session_0112hMx9hjJ9BgB28X97DS68): ACCEPT on #14179 (comment 5504761434) → at 05:32Z every check run on head e60660c3a was completed with success or skipped (33 runs; Lint & Repo Gates finished 05:31Z), governed-surface test on the four changed paths: NOT governed, mergeable_state not dirty → marked ready and auto-merge (squash) enabled. Landing is by the merge queue; the engine seat follows it to MERGED.

---

Generated by Claude Code

[os-musk]

Fixes#14179

emitMetadataMutation documents itself as "the ONE choke point every authoring surface funnels through", and since the #13331 fan-out landed it is also the metadata.mutated cluster publish point. Three live write paths never reached it. Each now emits after its write, with the same org scope the write received and the same singular type key the registry was written under — mirroring the emitting siblings rather than inventing an event shape.

Verified at e60660c3a (the branch head this description describes; the gate union below was run on that same commit).

The three doors

door	reached by	before	after	pinned by
rollbackMetaItem, after its registry write-through	POST /api/v1/meta/:type/:name/rollback	write-through, no emit	emitMetadataMutation({ type: singularType, name, state: 'active', organizationId: orgId })	new file, §2 "announces the restored body on the mutation choke point" + "folds a PLURAL request type…"
revertCommit — RESTORE limb, after the per-item write-through	POST /packages/:id/commits/:commitId/revert	write-through, no emit	same event with PLURAL_TO_SINGULAR[it.type] ?? it.type, state: 'active', per-item itemOrgId	new file, §2 "RESTORE limb announces the pre-commit body it wrote back" + the mixed-batch case
revertCommit — SOFT-REMOVE limb, after repo.delete + restoreArtifactRegistryView	same door, items the commit created	delete + heal, no emit	same key/scope, state: 'deleted', gated on a row actually having been removed	new file, §2 "SOFT-REMOVE limb announces a deleted…" + §4's already-absent negative control
deleteMetaItem legacy raw-engine exit (the non-useRepoPath side)	DELETE /api/v1/meta/:type/:name on a control-plane bootstrap kernel	engine.delete + optional storage drop + heal, no emit	mirrors the repository twin exactly: state: 'deleted', singularTypeForRepo, request.organizationId ?? null	new file, §2 "announces the deletion it really performs" + "carries the org scope the delete predicate used"

Four call sites, three doors — revertCommit's two limbs are one door with two exits, exactly as the card's inventory counts it. this.emitMetadataMutation( call sites go 3 to 7; applyRegistryWriteThrough call sites stay at 5, so protocol.object-registry-write-through-spelling.test.ts's closed-caller-set pin is untouched and green.

Premise, re-measured

At the branch base 5c9e40ad9: git grep -n "applyRegistryWriteThrough(" -- packages/metadata-protocol/src/protocol.ts returns 6 hits, one of them the declaration at :13660 — FIVE call sites; the same grep for emitMetadataMutation( returns 4, one of them the declaration at :4962 — THREE call sites. The card's count holds.

One correction to the card's attribution of the fifth write-through: it sits inside applyRemoteMetadataMutation (the #13331 RECEIVE-side applier), not inside publishMetadataMutation (the publisher, which makes no write-through call at all). The substance is unchanged — it is the receive side, and it is deliberately not a door.

Reachability of the legacy delete exit — the NOT MEASURED item, now measured

The unblock comment recorded that it had not verified the branch's own docblock claim ("only reachable in control-plane bootstrap mode where environmentId is undefined"), noting correctly that useRepoPath does not itself test environmentId.

Measured: the claim holds, by a mechanism the docblock does not name. What confines the branch is the two-tier delete authorization above it, which runs only when environmentId !== undefined and refuses both limbs for exactly the types that would reach the legacy path:

• artifact-backed: artifactBacked AND NOT overlayAllowed AND NOT legacyOverlayRemoval produces NOT_OVERRIDABLE 403
• not artifact-backed: NOT artifactBacked AND NOT overlayAllowed AND NOT runtimeCreateAllowed produces NOT_CREATABLE 403

The #6960 carve-out is the only way past the first limb and it cannot apply: it reads supportsOverlay, and the useRepoPath === false set is exactly agent, api, capability, field, job — five of the registry's 27 entries, none of which carries supportsOverlay: true. Both 403s are driven end to end in §3, and the registry property itself is pinned there too, so a registry edit that opens the door has to come past this file.

So door 4's exposure is narrower than the comment feared: unreachable through the public deleteMetaItem on a normal boot. That is why its repair is pinned under bootstrap mode — which is where the defect is real, and where the registry every organization shares is the one being healed. The OS_METADATA_WRITABLE escape hatch only moves a type ONTO the repository (emitting) path, never onto this one; the harness clears its memoised cache so that cannot silently change what is measured.

The receive path stays silent — cited, not duplicated

Adding an emit inside applyRemoteMetadataMutation would re-broadcast every received event and ping-pong across replicas, which the loopback guard (own-messages only) cannot stop. That negative is already pinned in protocol.cluster-mutation-fanout.test.ts, in "the peer's onMetadataMutation listeners receive the remote event, once, after convergence": expect(writerSeen).toHaveLength(1), commented "the remote replay stays local to the receiving node (no echo)". A peer that re-emitted would re-publish, the writer would apply that peer-origin message past its own loopback guard, and that assertion would read 2. It is cited rather than re-built.

Alongside it, §5 of the new file carries three structural pins that make the same claim locally and cheaply: the emitMetadataMutation call-site count is 7, notifyMutationListenersLocal keeps exactly its two declared callers (the choke point and the receive path), and applyRemoteMetadataMutation's body contains notifyMutationListenersLocal and does not contain emitMetadataMutation.

The cluster half is inherited, not re-measured

emitMetadataMutation is two lines — the local fan-out, then publishMetadataMutation — so a door that reaches the choke point reaches the publisher. protocol.cluster-mutation-fanout.test.ts already proves that end to end over a two-replica pub/sub double (Arm B, "a runtime-authored object registers on the PEER after the writer's save", with Arm A as the no-bridge control). Combined with §5's call-site count, the new doors inherit the cluster leg structurally. Building a second cluster harness here would re-measure that file's subject rather than this card's, so it is not built.

Ablation — direction declared before the run, in the committed test header

Declared (commit 43640d6c6, before running): removing door 1's emit from protocol.ts turns RED both of §2's rollback cases and §5's call-site count, and leaves everything else GREEN — 3 RED / 15 GREEN of 18.

Measured, exactly that:

BEFORE: anchor=1 emit-call-sites=7
AFTER: anchor=0 emit-call-sites=6 blob=ba5fa53549caa6a282bb325a2ae93f62a47fcdc6
MUTATION CONFIRMED ON DISK (anchor 1->0, emit sites 7->6, blob differs from HEAD)
x announces the restored body on the mutation choke point
x folds a PLURAL request type to the singular the write-through registered under
x has exactly seven `emitMetadataMutation` call sites
Tests 3 failed | 15 passed (18)
RESTORE: blob=fa53e5ac6b7ab5ff6d47aaf4e86ba7ba89352270 head=fa53e5ac6b7ab5ff6d47aaf4e86ba7ba89352270 anchor=1 emits=7 diff-bytes=0
RESTORE CONFIRMED BYTE-EXACT (blob == HEAD blob, git diff HEAD empty, anchor 1, emits 7)

Mechanics: the fix was committed first, so the restore leg had a real restore point; the mutation ran under an EXIT INT TERM trap whose paths are absolute (seeded from git rev-parse --show-toplevel, not from a cwd); the mutation is proved by anchored counts of the removed text and a blob hash that differs from HEAD's, never by perl -i's exit code; the restore is proved by git checkout HEAD -- path followed by a blob-hash match against the HEAD blob AND an empty git diff HEAD, never by an exit code. The first attempt of this script refused to run — its precondition read anchor=0 because the bracketed issue tag was being read as a regex character class — and that refusal is the design working: a zero-match mutation would otherwise have produced a fully green "ablation".

No rebuild is involved and that is itself a measurement: the pin file imports the same-package relative ./protocol.js, so vitest compiles src/protocol.ts. An ablation that goes red with no build is what proves it; a dist-resolved one would have stayed green.

Deliberately unchanged

• The row-absent exits stay silent. The repository path's miss, the legacy path's miss, and revertCommit's soft-remove limb over an already-gone row: nothing mutated, so nothing is announced. The soft-remove gate is if (current), mirroring the repository delete twin, whose row-absent exit has always been silent even though it still runs the self-heal. A deleted signal there would wake every peer to converge on a no-op. All three are pinned in §4.
• A draft save still announces draft.publishMetadataMutation owns the draft filter, not the doors; §4 pins that this change did not move that boundary.
• packages/spec and packages/metadata are untouched — the event shape needed no change. So is the runtime: TS-config boot registers a 'metadata' service without attachClusterPubSub — cross-node invalidation disabled; new object gives OBJECT_NOT_FOUND on non-writing replicas, never heals #13331 publish/subscribe seam, which was read and not edited.

Files, and one beyond the dispatched surface

• packages/metadata-protocol/src/protocol.ts — the three doors (four call sites), +60 lines, comments included.
• packages/metadata-protocol/src/protocol.recovery-doors-emit-mutation.test.ts — new, 18 cases.
• .changeset/recovery-doors-emit-metadata-mutation.md — @objectstack/metadata-protocol: patch.
• scripts/engine-double-contract.pinned.json — not on the dispatched file surface, declared here.check:engine-double-contract reds on a new pin file until the RETAINED ledger records it ("New pinned coverage is GOOD and nothing is wrong with your change — the ledger just has to learn about it, or it never protects this file"). Regenerated with that gate's own --write: 3 rows added, all naming the new test file, 0 lost, no other row touched. Reusing an existing double instead was not available — the file is new, so it has no double to override.

No existing sibling pin needed updating: the whole @objectstack/metadata-protocol suite is green unchanged (2125 passed), including the write-through-spelling call-site count, the cluster fan-out arms and the delete-rewrap envelope pins.

Gate union, run on e60660c3a

Derived on the real change set with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands after the last commit — 44 commands, 7 more than the dispatch's list because the ledger file above joined the diff (agent-test-spelling, bash32-floor, cli-command-ids, entry-guard, parse-guard, pnpm-filter-targets, watch-hint-literal; all seven PASS). Exit codes captured after a redirect, never through a pipe.

• pnpm --filter @objectstack/metadata-protocol test — PASS, 154 files passed / 2 skipped, 2125 tests passed / 10 skipped.
• pnpm --filter @objectstack/metadata-protocol typecheck — PASS (tsc --noEmit). The new pin file is inside that program: tsc --listFilesOnly lists it, 1 hit among 699 files.
• pnpm lint — PASS over the whole repo in 68s (eslint . --no-inline-config), so no narrowing was needed and none is claimed.
• pnpm check:nul-bytes — PASS (7859 files scanned), plus a manual control-character scan over the four changed paths: zero hits.
• The 44-command union: 40 PASS, 4 NOT MEASURED, 0 findings.

The four NOT MEASURED are exit-3 PREREQUISITE-NOT-MET, recorded with the gates' own words and read as neither pass nor finding — every one needs an input a per-package local run does not have, and CI supplies all four:

gate	its own verdict
check-test-completeness.mjs	"pass a saved turbo run test log — or, running the family locally, record this gate as NOT MEASURED"
pm/check-half-states.mjs	exit 3, an unread instrument (needs the GitHub board) — "never as a quiet board"
check:dual-build-cjs-loads	"PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/… Run pnpm build first. This is NOT a pass"
check:type-check-debt	"Build the closure first, exactly as lint.yml does… This is NOT a pass and NOT a finding"

Merge state

main landed 5 commits since this branch's base (5c9e40ad9 to 4485f7dad): CLI, lint, docs and three merge-driver scripts. None touches packages/metadata-protocol or packages/spec, so the AGENTS.md §10 re-check is scoped out rather than skipped, and the merge queue validates the merge commit itself. No other in-flight claude/issue-14* branch on origin touches protocol.ts (24 branches fetched and diffed against their merge-base at PR time), so the serial lane the dispatch declared is still clear.

Not this card

#13609 (a deleted datasource prolonging cluster-wide) is a different defect and is not addressed here: datasource carries allowOrgOverride: false, allowRuntimeCreate: true, so useRepoPath is true and it takes the repository exit, which has emitted since #2588. This branch changes nothing about it, and that card stays open on its own premise.

🤖 Generated with Claude Code

https://claude.ai/code/session_0112hMx9hjJ9BgB28X97DS68

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/metadata-protocol, touching 7 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/client-sdk.mdx(via meta.rollbackItem (sdk, the route ledger binds it to POST /api/v1/meta/:type/:name/rollback, selected by route anchor /:type/:name/rollback), rollbackItem (sdk, the bare tail of client method meta.rollbackItem, bound to POST /api/v1/meta/:type/:name/rollback))
• content/docs/kernel/contracts/metadata-service.mdx(via /:type/:name/rollback (route, bridged from symbol rollbackMetaItem — its registrar handler names it))
• content/docs/kernel/services-checklist.mdx(via deleteMetaItem (symbol, a method of class ObjectStackProtocolImplementation))

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 8 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from b2431d3164baf7f9401f96757f5f0beb6e663570 — the merge of head e60660c3a62281b5ef3edf397f1b2f50d4d3ec44 into base 41aa979295be112cc6c27fcd6cc6c5ac20c519d5, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin b2431d3164baf7f9401f96757f5f0beb6e663570 && git checkout b2431d3164baf7f9401f96757f5f0beb6e663570
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 e60660c3a62281b5ef3edf397f1b2f50d4d3ec44 && git checkout -B drift-repro 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 && git merge --no-ff e60660c3a62281b5ef3edf397f1b2f50d4d3ec44
node scripts/docs-audit/affected-docs.mjs --json 41aa979295be112cc6c27fcd6cc6c5ac20c519d5

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-musk]

Enqueue provenance (domain:engine execution seat, session_0112hMx9hjJ9BgB28X97DS68): ACCEPT on #14179 (comment 5504761434) → at 05:32Z every check run on head e60660c3a was completed with success or skipped (33 runs; Lint & Repo Gates finished 05:31Z), governed-surface test on the four changed paths: NOT governed, mergeable_state not dirty → marked ready and auto-merge (squash) enabled. Landing is by the merge queue; the engine seat follows it to MERGED.

---

Generated by Claude Code

[os-musk]

Fixes#14179

emitMetadataMutation documents itself as "the ONE choke point every authoring surface funnels through", and since the #13331 fan-out landed it is also the metadata.mutated cluster publish point. Three live write paths never reached it. Each now emits after its write, with the same org scope the write received and the same singular type key the registry was written under — mirroring the emitting siblings rather than inventing an event shape.

Verified at e60660c3a (the branch head this description describes; the gate union below was run on that same commit).

The three doors

door	reached by	before	after	pinned by
rollbackMetaItem, after its registry write-through	POST /api/v1/meta/:type/:name/rollback	write-through, no emit	emitMetadataMutation({ type: singularType, name, state: 'active', organizationId: orgId })	new file, §2 "announces the restored body on the mutation choke point" + "folds a PLURAL request type…"
revertCommit — RESTORE limb, after the per-item write-through	POST /packages/:id/commits/:commitId/revert	write-through, no emit	same event with PLURAL_TO_SINGULAR[it.type] ?? it.type, state: 'active', per-item itemOrgId	new file, §2 "RESTORE limb announces the pre-commit body it wrote back" + the mixed-batch case
revertCommit — SOFT-REMOVE limb, after repo.delete + restoreArtifactRegistryView	same door, items the commit created	delete + heal, no emit	same key/scope, state: 'deleted', gated on a row actually having been removed	new file, §2 "SOFT-REMOVE limb announces a deleted…" + §4's already-absent negative control
deleteMetaItem legacy raw-engine exit (the non-useRepoPath side)	DELETE /api/v1/meta/:type/:name on a control-plane bootstrap kernel	engine.delete + optional storage drop + heal, no emit	mirrors the repository twin exactly: state: 'deleted', singularTypeForRepo, request.organizationId ?? null	new file, §2 "announces the deletion it really performs" + "carries the org scope the delete predicate used"

Four call sites, three doors — revertCommit's two limbs are one door with two exits, exactly as the card's inventory counts it. this.emitMetadataMutation( call sites go 3 to 7; applyRegistryWriteThrough call sites stay at 5, so protocol.object-registry-write-through-spelling.test.ts's closed-caller-set pin is untouched and green.

Premise, re-measured

At the branch base 5c9e40ad9: git grep -n "applyRegistryWriteThrough(" -- packages/metadata-protocol/src/protocol.ts returns 6 hits, one of them the declaration at :13660 — FIVE call sites; the same grep for emitMetadataMutation( returns 4, one of them the declaration at :4962 — THREE call sites. The card's count holds.

One correction to the card's attribution of the fifth write-through: it sits inside applyRemoteMetadataMutation (the #13331 RECEIVE-side applier), not inside publishMetadataMutation (the publisher, which makes no write-through call at all). The substance is unchanged — it is the receive side, and it is deliberately not a door.

Reachability of the legacy delete exit — the NOT MEASURED item, now measured

The unblock comment recorded that it had not verified the branch's own docblock claim ("only reachable in control-plane bootstrap mode where environmentId is undefined"), noting correctly that useRepoPath does not itself test environmentId.

Measured: the claim holds, by a mechanism the docblock does not name. What confines the branch is the two-tier delete authorization above it, which runs only when environmentId !== undefined and refuses both limbs for exactly the types that would reach the legacy path:

• artifact-backed: artifactBacked AND NOT overlayAllowed AND NOT legacyOverlayRemoval produces NOT_OVERRIDABLE 403
• not artifact-backed: NOT artifactBacked AND NOT overlayAllowed AND NOT runtimeCreateAllowed produces NOT_CREATABLE 403

The #6960 carve-out is the only way past the first limb and it cannot apply: it reads supportsOverlay, and the useRepoPath === false set is exactly agent, api, capability, field, job — five of the registry's 27 entries, none of which carries supportsOverlay: true. Both 403s are driven end to end in §3, and the registry property itself is pinned there too, so a registry edit that opens the door has to come past this file.

So door 4's exposure is narrower than the comment feared: unreachable through the public deleteMetaItem on a normal boot. That is why its repair is pinned under bootstrap mode — which is where the defect is real, and where the registry every organization shares is the one being healed. The OS_METADATA_WRITABLE escape hatch only moves a type ONTO the repository (emitting) path, never onto this one; the harness clears its memoised cache so that cannot silently change what is measured.

The receive path stays silent — cited, not duplicated

Adding an emit inside applyRemoteMetadataMutation would re-broadcast every received event and ping-pong across replicas, which the loopback guard (own-messages only) cannot stop. That negative is already pinned in protocol.cluster-mutation-fanout.test.ts, in "the peer's onMetadataMutation listeners receive the remote event, once, after convergence": expect(writerSeen).toHaveLength(1), commented "the remote replay stays local to the receiving node (no echo)". A peer that re-emitted would re-publish, the writer would apply that peer-origin message past its own loopback guard, and that assertion would read 2. It is cited rather than re-built.

Alongside it, §5 of the new file carries three structural pins that make the same claim locally and cheaply: the emitMetadataMutation call-site count is 7, notifyMutationListenersLocal keeps exactly its two declared callers (the choke point and the receive path), and applyRemoteMetadataMutation's body contains notifyMutationListenersLocal and does not contain emitMetadataMutation.

The cluster half is inherited, not re-measured

emitMetadataMutation is two lines — the local fan-out, then publishMetadataMutation — so a door that reaches the choke point reaches the publisher. protocol.cluster-mutation-fanout.test.ts already proves that end to end over a two-replica pub/sub double (Arm B, "a runtime-authored object registers on the PEER after the writer's save", with Arm A as the no-bridge control). Combined with §5's call-site count, the new doors inherit the cluster leg structurally. Building a second cluster harness here would re-measure that file's subject rather than this card's, so it is not built.

Ablation — direction declared before the run, in the committed test header

Declared (commit 43640d6c6, before running): removing door 1's emit from protocol.ts turns RED both of §2's rollback cases and §5's call-site count, and leaves everything else GREEN — 3 RED / 15 GREEN of 18.

Measured, exactly that:

BEFORE: anchor=1 emit-call-sites=7
AFTER: anchor=0 emit-call-sites=6 blob=ba5fa53549caa6a282bb325a2ae93f62a47fcdc6
MUTATION CONFIRMED ON DISK (anchor 1->0, emit sites 7->6, blob differs from HEAD)
x announces the restored body on the mutation choke point
x folds a PLURAL request type to the singular the write-through registered under
x has exactly seven `emitMetadataMutation` call sites
Tests 3 failed | 15 passed (18)
RESTORE: blob=fa53e5ac6b7ab5ff6d47aaf4e86ba7ba89352270 head=fa53e5ac6b7ab5ff6d47aaf4e86ba7ba89352270 anchor=1 emits=7 diff-bytes=0
RESTORE CONFIRMED BYTE-EXACT (blob == HEAD blob, git diff HEAD empty, anchor 1, emits 7)

Mechanics: the fix was committed first, so the restore leg had a real restore point; the mutation ran under an EXIT INT TERM trap whose paths are absolute (seeded from git rev-parse --show-toplevel, not from a cwd); the mutation is proved by anchored counts of the removed text and a blob hash that differs from HEAD's, never by perl -i's exit code; the restore is proved by git checkout HEAD -- path followed by a blob-hash match against the HEAD blob AND an empty git diff HEAD, never by an exit code. The first attempt of this script refused to run — its precondition read anchor=0 because the bracketed issue tag was being read as a regex character class — and that refusal is the design working: a zero-match mutation would otherwise have produced a fully green "ablation".

No rebuild is involved and that is itself a measurement: the pin file imports the same-package relative ./protocol.js, so vitest compiles src/protocol.ts. An ablation that goes red with no build is what proves it; a dist-resolved one would have stayed green.

Deliberately unchanged

• The row-absent exits stay silent. The repository path's miss, the legacy path's miss, and revertCommit's soft-remove limb over an already-gone row: nothing mutated, so nothing is announced. The soft-remove gate is if (current), mirroring the repository delete twin, whose row-absent exit has always been silent even though it still runs the self-heal. A deleted signal there would wake every peer to converge on a no-op. All three are pinned in §4.
• A draft save still announces draft.publishMetadataMutation owns the draft filter, not the doors; §4 pins that this change did not move that boundary.
• packages/spec and packages/metadata are untouched — the event shape needed no change. So is the runtime: TS-config boot registers a 'metadata' service without attachClusterPubSub — cross-node invalidation disabled; new object gives OBJECT_NOT_FOUND on non-writing replicas, never heals #13331 publish/subscribe seam, which was read and not edited.

Files, and one beyond the dispatched surface

• packages/metadata-protocol/src/protocol.ts — the three doors (four call sites), +60 lines, comments included.
• packages/metadata-protocol/src/protocol.recovery-doors-emit-mutation.test.ts — new, 18 cases.
• .changeset/recovery-doors-emit-metadata-mutation.md — @objectstack/metadata-protocol: patch.
• scripts/engine-double-contract.pinned.json — not on the dispatched file surface, declared here.check:engine-double-contract reds on a new pin file until the RETAINED ledger records it ("New pinned coverage is GOOD and nothing is wrong with your change — the ledger just has to learn about it, or it never protects this file"). Regenerated with that gate's own --write: 3 rows added, all naming the new test file, 0 lost, no other row touched. Reusing an existing double instead was not available — the file is new, so it has no double to override.

No existing sibling pin needed updating: the whole @objectstack/metadata-protocol suite is green unchanged (2125 passed), including the write-through-spelling call-site count, the cluster fan-out arms and the delete-rewrap envelope pins.

Gate union, run on e60660c3a

Derived on the real change set with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands after the last commit — 44 commands, 7 more than the dispatch's list because the ledger file above joined the diff (agent-test-spelling, bash32-floor, cli-command-ids, entry-guard, parse-guard, pnpm-filter-targets, watch-hint-literal; all seven PASS). Exit codes captured after a redirect, never through a pipe.

• pnpm --filter @objectstack/metadata-protocol test — PASS, 154 files passed / 2 skipped, 2125 tests passed / 10 skipped.
• pnpm --filter @objectstack/metadata-protocol typecheck — PASS (tsc --noEmit). The new pin file is inside that program: tsc --listFilesOnly lists it, 1 hit among 699 files.
• pnpm lint — PASS over the whole repo in 68s (eslint . --no-inline-config), so no narrowing was needed and none is claimed.
• pnpm check:nul-bytes — PASS (7859 files scanned), plus a manual control-character scan over the four changed paths: zero hits.
• The 44-command union: 40 PASS, 4 NOT MEASURED, 0 findings.

The four NOT MEASURED are exit-3 PREREQUISITE-NOT-MET, recorded with the gates' own words and read as neither pass nor finding — every one needs an input a per-package local run does not have, and CI supplies all four:

gate	its own verdict
check-test-completeness.mjs	"pass a saved turbo run test log — or, running the family locally, record this gate as NOT MEASURED"
pm/check-half-states.mjs	exit 3, an unread instrument (needs the GitHub board) — "never as a quiet board"
check:dual-build-cjs-loads	"PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/… Run pnpm build first. This is NOT a pass"
check:type-check-debt	"Build the closure first, exactly as lint.yml does… This is NOT a pass and NOT a finding"

Merge state

main landed 5 commits since this branch's base (5c9e40ad9 to 4485f7dad): CLI, lint, docs and three merge-driver scripts. None touches packages/metadata-protocol or packages/spec, so the AGENTS.md §10 re-check is scoped out rather than skipped, and the merge queue validates the merge commit itself. No other in-flight claude/issue-14* branch on origin touches protocol.ts (24 branches fetched and diffed against their merge-base at PR time), so the serial lane the dispatch declared is still clear.

Not this card

#13609 (a deleted datasource prolonging cluster-wide) is a different defect and is not addressed here: datasource carries allowOrgOverride: false, allowRuntimeCreate: true, so useRepoPath is true and it takes the repository exit, which has emitted since #2588. This branch changes nothing about it, and that card stays open on its own premise.

🤖 Generated with Claude Code

https://claude.ai/code/session_0112hMx9hjJ9BgB28X97DS68

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/metadata-protocol, touching 7 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/client-sdk.mdx(via meta.rollbackItem (sdk, the route ledger binds it to POST /api/v1/meta/:type/:name/rollback, selected by route anchor /:type/:name/rollback), rollbackItem (sdk, the bare tail of client method meta.rollbackItem, bound to POST /api/v1/meta/:type/:name/rollback))
• content/docs/kernel/contracts/metadata-service.mdx(via /:type/:name/rollback (route, bridged from symbol rollbackMetaItem — its registrar handler names it))
• content/docs/kernel/services-checklist.mdx(via deleteMetaItem (symbol, a method of class ObjectStackProtocolImplementation))

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 8 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from b2431d3164baf7f9401f96757f5f0beb6e663570 — the merge of head e60660c3a62281b5ef3edf397f1b2f50d4d3ec44 into base 41aa979295be112cc6c27fcd6cc6c5ac20c519d5, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin b2431d3164baf7f9401f96757f5f0beb6e663570 && git checkout b2431d3164baf7f9401f96757f5f0beb6e663570
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 e60660c3a62281b5ef3edf397f1b2f50d4d3ec44 && git checkout -B drift-repro 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 && git merge --no-ff e60660c3a62281b5ef3edf397f1b2f50d4d3ec44
node scripts/docs-audit/affected-docs.mjs --json 41aa979295be112cc6c27fcd6cc6c5ac20c519d5

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-musk]

Enqueue provenance (domain:engine execution seat, session_0112hMx9hjJ9BgB28X97DS68): ACCEPT on #14179 (comment 5504761434) → at 05:32Z every check run on head e60660c3a was completed with success or skipped (33 runs; Lint & Repo Gates finished 05:31Z), governed-surface test on the four changed paths: NOT governed, mergeable_state not dirty → marked ready and auto-merge (squash) enabled. Landing is by the merge queue; the engine seat follows it to MERGED.

---

Generated by Claude Code

[os-musk]

Fixes#14179

emitMetadataMutation documents itself as "the ONE choke point every authoring surface funnels through", and since the #13331 fan-out landed it is also the metadata.mutated cluster publish point. Three live write paths never reached it. Each now emits after its write, with the same org scope the write received and the same singular type key the registry was written under — mirroring the emitting siblings rather than inventing an event shape.

Verified at e60660c3a (the branch head this description describes; the gate union below was run on that same commit).

The three doors

door	reached by	before	after	pinned by
rollbackMetaItem, after its registry write-through	POST /api/v1/meta/:type/:name/rollback	write-through, no emit	emitMetadataMutation({ type: singularType, name, state: 'active', organizationId: orgId })	new file, §2 "announces the restored body on the mutation choke point" + "folds a PLURAL request type…"
revertCommit — RESTORE limb, after the per-item write-through	POST /packages/:id/commits/:commitId/revert	write-through, no emit	same event with PLURAL_TO_SINGULAR[it.type] ?? it.type, state: 'active', per-item itemOrgId	new file, §2 "RESTORE limb announces the pre-commit body it wrote back" + the mixed-batch case
revertCommit — SOFT-REMOVE limb, after repo.delete + restoreArtifactRegistryView	same door, items the commit created	delete + heal, no emit	same key/scope, state: 'deleted', gated on a row actually having been removed	new file, §2 "SOFT-REMOVE limb announces a deleted…" + §4's already-absent negative control
deleteMetaItem legacy raw-engine exit (the non-useRepoPath side)	DELETE /api/v1/meta/:type/:name on a control-plane bootstrap kernel	engine.delete + optional storage drop + heal, no emit	mirrors the repository twin exactly: state: 'deleted', singularTypeForRepo, request.organizationId ?? null	new file, §2 "announces the deletion it really performs" + "carries the org scope the delete predicate used"

Four call sites, three doors — revertCommit's two limbs are one door with two exits, exactly as the card's inventory counts it. this.emitMetadataMutation( call sites go 3 to 7; applyRegistryWriteThrough call sites stay at 5, so protocol.object-registry-write-through-spelling.test.ts's closed-caller-set pin is untouched and green.

Premise, re-measured

At the branch base 5c9e40ad9: git grep -n "applyRegistryWriteThrough(" -- packages/metadata-protocol/src/protocol.ts returns 6 hits, one of them the declaration at :13660 — FIVE call sites; the same grep for emitMetadataMutation( returns 4, one of them the declaration at :4962 — THREE call sites. The card's count holds.

One correction to the card's attribution of the fifth write-through: it sits inside applyRemoteMetadataMutation (the #13331 RECEIVE-side applier), not inside publishMetadataMutation (the publisher, which makes no write-through call at all). The substance is unchanged — it is the receive side, and it is deliberately not a door.

Reachability of the legacy delete exit — the NOT MEASURED item, now measured

The unblock comment recorded that it had not verified the branch's own docblock claim ("only reachable in control-plane bootstrap mode where environmentId is undefined"), noting correctly that useRepoPath does not itself test environmentId.

Measured: the claim holds, by a mechanism the docblock does not name. What confines the branch is the two-tier delete authorization above it, which runs only when environmentId !== undefined and refuses both limbs for exactly the types that would reach the legacy path:

• artifact-backed: artifactBacked AND NOT overlayAllowed AND NOT legacyOverlayRemoval produces NOT_OVERRIDABLE 403
• not artifact-backed: NOT artifactBacked AND NOT overlayAllowed AND NOT runtimeCreateAllowed produces NOT_CREATABLE 403

The #6960 carve-out is the only way past the first limb and it cannot apply: it reads supportsOverlay, and the useRepoPath === false set is exactly agent, api, capability, field, job — five of the registry's 27 entries, none of which carries supportsOverlay: true. Both 403s are driven end to end in §3, and the registry property itself is pinned there too, so a registry edit that opens the door has to come past this file.

So door 4's exposure is narrower than the comment feared: unreachable through the public deleteMetaItem on a normal boot. That is why its repair is pinned under bootstrap mode — which is where the defect is real, and where the registry every organization shares is the one being healed. The OS_METADATA_WRITABLE escape hatch only moves a type ONTO the repository (emitting) path, never onto this one; the harness clears its memoised cache so that cannot silently change what is measured.

The receive path stays silent — cited, not duplicated

Adding an emit inside applyRemoteMetadataMutation would re-broadcast every received event and ping-pong across replicas, which the loopback guard (own-messages only) cannot stop. That negative is already pinned in protocol.cluster-mutation-fanout.test.ts, in "the peer's onMetadataMutation listeners receive the remote event, once, after convergence": expect(writerSeen).toHaveLength(1), commented "the remote replay stays local to the receiving node (no echo)". A peer that re-emitted would re-publish, the writer would apply that peer-origin message past its own loopback guard, and that assertion would read 2. It is cited rather than re-built.

Alongside it, §5 of the new file carries three structural pins that make the same claim locally and cheaply: the emitMetadataMutation call-site count is 7, notifyMutationListenersLocal keeps exactly its two declared callers (the choke point and the receive path), and applyRemoteMetadataMutation's body contains notifyMutationListenersLocal and does not contain emitMetadataMutation.

The cluster half is inherited, not re-measured

emitMetadataMutation is two lines — the local fan-out, then publishMetadataMutation — so a door that reaches the choke point reaches the publisher. protocol.cluster-mutation-fanout.test.ts already proves that end to end over a two-replica pub/sub double (Arm B, "a runtime-authored object registers on the PEER after the writer's save", with Arm A as the no-bridge control). Combined with §5's call-site count, the new doors inherit the cluster leg structurally. Building a second cluster harness here would re-measure that file's subject rather than this card's, so it is not built.

Ablation — direction declared before the run, in the committed test header

Declared (commit 43640d6c6, before running): removing door 1's emit from protocol.ts turns RED both of §2's rollback cases and §5's call-site count, and leaves everything else GREEN — 3 RED / 15 GREEN of 18.

Measured, exactly that:

BEFORE: anchor=1 emit-call-sites=7
AFTER: anchor=0 emit-call-sites=6 blob=ba5fa53549caa6a282bb325a2ae93f62a47fcdc6
MUTATION CONFIRMED ON DISK (anchor 1->0, emit sites 7->6, blob differs from HEAD)
x announces the restored body on the mutation choke point
x folds a PLURAL request type to the singular the write-through registered under
x has exactly seven `emitMetadataMutation` call sites
Tests 3 failed | 15 passed (18)
RESTORE: blob=fa53e5ac6b7ab5ff6d47aaf4e86ba7ba89352270 head=fa53e5ac6b7ab5ff6d47aaf4e86ba7ba89352270 anchor=1 emits=7 diff-bytes=0
RESTORE CONFIRMED BYTE-EXACT (blob == HEAD blob, git diff HEAD empty, anchor 1, emits 7)

Mechanics: the fix was committed first, so the restore leg had a real restore point; the mutation ran under an EXIT INT TERM trap whose paths are absolute (seeded from git rev-parse --show-toplevel, not from a cwd); the mutation is proved by anchored counts of the removed text and a blob hash that differs from HEAD's, never by perl -i's exit code; the restore is proved by git checkout HEAD -- path followed by a blob-hash match against the HEAD blob AND an empty git diff HEAD, never by an exit code. The first attempt of this script refused to run — its precondition read anchor=0 because the bracketed issue tag was being read as a regex character class — and that refusal is the design working: a zero-match mutation would otherwise have produced a fully green "ablation".

No rebuild is involved and that is itself a measurement: the pin file imports the same-package relative ./protocol.js, so vitest compiles src/protocol.ts. An ablation that goes red with no build is what proves it; a dist-resolved one would have stayed green.

Deliberately unchanged

• The row-absent exits stay silent. The repository path's miss, the legacy path's miss, and revertCommit's soft-remove limb over an already-gone row: nothing mutated, so nothing is announced. The soft-remove gate is if (current), mirroring the repository delete twin, whose row-absent exit has always been silent even though it still runs the self-heal. A deleted signal there would wake every peer to converge on a no-op. All three are pinned in §4.
• A draft save still announces draft.publishMetadataMutation owns the draft filter, not the doors; §4 pins that this change did not move that boundary.
• packages/spec and packages/metadata are untouched — the event shape needed no change. So is the runtime: TS-config boot registers a 'metadata' service without attachClusterPubSub — cross-node invalidation disabled; new object gives OBJECT_NOT_FOUND on non-writing replicas, never heals #13331 publish/subscribe seam, which was read and not edited.

Files, and one beyond the dispatched surface

• packages/metadata-protocol/src/protocol.ts — the three doors (four call sites), +60 lines, comments included.
• packages/metadata-protocol/src/protocol.recovery-doors-emit-mutation.test.ts — new, 18 cases.
• .changeset/recovery-doors-emit-metadata-mutation.md — @objectstack/metadata-protocol: patch.
• scripts/engine-double-contract.pinned.json — not on the dispatched file surface, declared here.check:engine-double-contract reds on a new pin file until the RETAINED ledger records it ("New pinned coverage is GOOD and nothing is wrong with your change — the ledger just has to learn about it, or it never protects this file"). Regenerated with that gate's own --write: 3 rows added, all naming the new test file, 0 lost, no other row touched. Reusing an existing double instead was not available — the file is new, so it has no double to override.

No existing sibling pin needed updating: the whole @objectstack/metadata-protocol suite is green unchanged (2125 passed), including the write-through-spelling call-site count, the cluster fan-out arms and the delete-rewrap envelope pins.

Gate union, run on e60660c3a

Derived on the real change set with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands after the last commit — 44 commands, 7 more than the dispatch's list because the ledger file above joined the diff (agent-test-spelling, bash32-floor, cli-command-ids, entry-guard, parse-guard, pnpm-filter-targets, watch-hint-literal; all seven PASS). Exit codes captured after a redirect, never through a pipe.

• pnpm --filter @objectstack/metadata-protocol test — PASS, 154 files passed / 2 skipped, 2125 tests passed / 10 skipped.
• pnpm --filter @objectstack/metadata-protocol typecheck — PASS (tsc --noEmit). The new pin file is inside that program: tsc --listFilesOnly lists it, 1 hit among 699 files.
• pnpm lint — PASS over the whole repo in 68s (eslint . --no-inline-config), so no narrowing was needed and none is claimed.
• pnpm check:nul-bytes — PASS (7859 files scanned), plus a manual control-character scan over the four changed paths: zero hits.
• The 44-command union: 40 PASS, 4 NOT MEASURED, 0 findings.

The four NOT MEASURED are exit-3 PREREQUISITE-NOT-MET, recorded with the gates' own words and read as neither pass nor finding — every one needs an input a per-package local run does not have, and CI supplies all four:

gate	its own verdict
check-test-completeness.mjs	"pass a saved turbo run test log — or, running the family locally, record this gate as NOT MEASURED"
pm/check-half-states.mjs	exit 3, an unread instrument (needs the GitHub board) — "never as a quiet board"
check:dual-build-cjs-loads	"PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/… Run pnpm build first. This is NOT a pass"
check:type-check-debt	"Build the closure first, exactly as lint.yml does… This is NOT a pass and NOT a finding"

Merge state

main landed 5 commits since this branch's base (5c9e40ad9 to 4485f7dad): CLI, lint, docs and three merge-driver scripts. None touches packages/metadata-protocol or packages/spec, so the AGENTS.md §10 re-check is scoped out rather than skipped, and the merge queue validates the merge commit itself. No other in-flight claude/issue-14* branch on origin touches protocol.ts (24 branches fetched and diffed against their merge-base at PR time), so the serial lane the dispatch declared is still clear.

Not this card

#13609 (a deleted datasource prolonging cluster-wide) is a different defect and is not addressed here: datasource carries allowOrgOverride: false, allowRuntimeCreate: true, so useRepoPath is true and it takes the repository exit, which has emitted since #2588. This branch changes nothing about it, and that card stays open on its own premise.

🤖 Generated with Claude Code

https://claude.ai/code/session_0112hMx9hjJ9BgB28X97DS68

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/metadata-protocol, touching 7 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/client-sdk.mdx(via meta.rollbackItem (sdk, the route ledger binds it to POST /api/v1/meta/:type/:name/rollback, selected by route anchor /:type/:name/rollback), rollbackItem (sdk, the bare tail of client method meta.rollbackItem, bound to POST /api/v1/meta/:type/:name/rollback))
• content/docs/kernel/contracts/metadata-service.mdx(via /:type/:name/rollback (route, bridged from symbol rollbackMetaItem — its registrar handler names it))
• content/docs/kernel/services-checklist.mdx(via deleteMetaItem (symbol, a method of class ObjectStackProtocolImplementation))

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 8 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from b2431d3164baf7f9401f96757f5f0beb6e663570 — the merge of head e60660c3a62281b5ef3edf397f1b2f50d4d3ec44 into base 41aa979295be112cc6c27fcd6cc6c5ac20c519d5, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin b2431d3164baf7f9401f96757f5f0beb6e663570 && git checkout b2431d3164baf7f9401f96757f5f0beb6e663570
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 e60660c3a62281b5ef3edf397f1b2f50d4d3ec44 && git checkout -B drift-repro 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 && git merge --no-ff e60660c3a62281b5ef3edf397f1b2f50d4d3ec44
node scripts/docs-audit/affected-docs.mjs --json 41aa979295be112cc6c27fcd6cc6c5ac20c519d5

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 41aa979295be112cc6c27fcd6cc6c5ac20c519d5 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-musk]

Enqueue provenance (domain:engine execution seat, session_0112hMx9hjJ9BgB28X97DS68): ACCEPT on #14179 (comment 5504761434) → at 05:32Z every check run on head e60660c3a was completed with success or skipped (33 runs; Lint & Repo Gates finished 05:31Z), governed-surface test on the four changed paths: NOT governed, mergeable_state not dirty → marked ready and auto-merge (squash) enabled. Landing is by the merge queue; the engine seat follows it to MERGED.

---

Generated by Claude Code