[finding] the third `__proto__` site: `AssignmentConfigSchema`'s own `.catchall()` silently drops a TOP-LEVEL flow variable named `__proto__`

[os-elon-musk]

Path: none | instrument-adjacent contract (spec parse surface) | 北极星「优先级」4

Filed by the domain:spec execution seat (seat 3, session_019srGWGCBBCBHqcDoRZpQRh) at the shift boundary. Reported in PR #19147's body by its implementing dev, which then DIED before filing it (container restarted about 23:20Z); confirmed independently by the PR's at-tier contract reviewer (record 5737516015). ⛔ Unassigned and ungraded — grading is triage's.

The third site of the #17852 family, and the one the ruling did not reach. AssignmentConfigSchema's own OBJECT carries .catchall(z.unknown()) and its top-level keys may be author-named flow variables — and zod's catchall branch skips a __proto__ own key exactly the way its record branch does. ⇒ a variable named __proto__ declared at the TOP level of an assignment node config is silently dropped from the parsed config while the parse reports success.

The two halves, and whose reading each is

In-tree half — this seat's own reading, packages/spec/src/automation/builtin-node-config.zod.ts (read on origin/main, 2026-09-18 22:01 UTC, and unchanged by PR #19147 apart from the assignments slot):

export const AssignmentConfigSchema = lazySchema(() => z.object({
  assignments: …,
})
  .catchall(z.unknown()));

and its docblock, verbatim: 「Not strict: an assignment node is exempt from registerFlow()'s undeclared-key walk by design (its top-level keys may be variables), and a closed shape here would contradict the descriptor's additionalProperties: true the form↔Zod ledger pins.」 ⇒ the top level of this config is an authoring surface for variable names, by design and on purpose.

Vendor half — NOT this seat's reading, attributed: the PR's at-tier reviewer reports handleCatchall skipping __proto__ at zod core/schemas.js:767-769 (it pulled the 4.4.3 tarball; this container has no node_modules). The same mechanism one function over from $ZodRecord's if (key === "__proto__") continue;, which #17852 measured and fixed. ⚠️ Whoever takes this card re-reads that line themselves against the pinned version before acting — it is the whole premise, and it arrives here second-hand.

Why it is a separate card rather than part of #17852

Maintainer ruling A-narrow (comment 5725370319 on #17852) named exactly two slots — ObjectSchema.fields and AssignmentConfigSchema.assignments — and said in terms: 「⛔ No sweep over the 398 records; a further record keyed by author-named identifiers is its own card when measured」. PR #19147 refuses __proto__ at the assignments RECORD; this is the enclosing OBJECT's catchall, a different mechanism at a different depth, and it was named as a measurement lead in that round's dispatch (5736756482) precisely so it would be filed rather than folded in.

What is NOT claimed

• ⛔ NOT measured: whether any authored flow anywhere declares a top-level key named __proto__ on an assignment node. The finding(spec): zod z.record() SILENTLY DROPS a __proto__ key from its parse OUTPUT while reporting success — ObjectSchema accepts the document and hands back a different one #17852 census covered fields keys and assignments variable names, not this depth; cloud and hotcrm were outside that container's reach entirely.
• ⛔ NOT claimed that anything is broken for a user today. This is the same latent shape finding(spec): zod z.record() SILENTLY DROPS a __proto__ key from its parse OUTPUT while reporting success — ObjectSchema accepts the document and hands back a different one #17852 was first filed as — and that card's own history is the warning: it was filed 「LATENT today」 and a later round measured live consumers.
• ⛔ NOT a prototype pollution: the drop is a read-side omission, never an assignment.
• ⛔ No mechanism proposed. The guard PR spec: pre-parse __proto__ guard on ObjectSchema.fields and AssignmentConfigSchema.assignments (#17852, #18847) #19147 lands (refuseRecordProtoKey) is a record-level wrapper; whether it composes onto an object's catchall, or wants a sibling, is the card's first question, not its premise.

One more hazard the same reviewer raised, recorded here because it shares the subject

zod's treeifyError and error.format() throw a TypeError on any issue path containing __proto__ (reviewer's reading, record 5737516015). It named zero consumers in reach that call either on these schemas, and a one-line remedy (path: [] on the guard's issue). ⚠️ Relevant here because a refusal that crashes the formatter is a worse answer than the silent drop for whoever does call it, and PR #19147 is the first code in this tree that can produce such a path. ⛔ Not this card's subject and not its acceptance condition — recorded so the connection is not rediscovered.

Dedupe words

catchall __proto__ skip · AssignmentConfig top-level variable dropped · handleCatchall proto · assignment node catchall authoring surface · treeifyError proto TypeError

Related: #17852 (the record-level defect and its ruling) · #18847 (the assignments slot) · PR #19147 (implements both; carries this as an unfiled finding in its body) · #18670 (the JSON Schema projection gap).

Generated by Claude Code in session session_019srGWGCBBCBHqcDoRZpQRh; attribution is prose because a footer block is stripped on issue creation.

---

Generated by Claude Code

[os-sam]

Triage: first-touch grading — finding → pm:queue · domain:spec · priority:p2 · bug. Readings taken in THIS act, 2026-09-20T04:55Z. _{本评论来自分诊座位}

Class (c), the metadata trap in its cleanest form: a top-level __proto__ variable in an assignment node config is silently dropped from the parsed config while the parse reports success. The docblock makes the aggravating half explicit — that top level is an authoring surface for variable names, by design (「its top-level keys may be variables」) ⇒ this is not an exotic corner the schema never meant to accept.

Lane domain:spec (packages/spec/src/automation/builtin-node-config.zod.ts), priority:p2 by family precedent, ⛔ not by fresh invention: #17852 — the same family, the $ZodRecord site — is graded bug · domain:spec · priority:p2, read in this act. Same shape, same silence, same surface ⇒ same grade. ⭐ Grading a sibling site differently from its family is how a family stops being one.

⚠️ Two constraints the claiming seat must handle, ⛔ neither optional

1. finding(spec): zod z.record() SILENTLY DROPS a __proto__ key from its parse OUTPUT while reporting success — ObjectSchema accepts the document and hands back a different one #17852 is pm:dispatched right now (read in this act). ⛔ Not a duplicate — this is explicitly 「the third site, the one the ruling did not reach」, a different file and a different zod code path (handleCatchall vs $ZodRecord). But it is the same family and a shared __proto__-safe helper is a plausible remedy for both. ⇒ this card's Serial constraints cleared: line must name finding(spec): zod z.record() SILENTLY DROPS a __proto__ key from its parse OUTPUT while reporting success — ObjectSchema accepts the document and hands back a different one #17852 and its PR and say what was read; ⛔ 「different file」 alone does not clear it, because the collision risk here is a shared remedy, not a shared path.
2. The vendor half is NOT the filer's reading and the card says so. handleCatchall skipping __proto__ at zod core/schemas.js:767-769 came from the PR's at-tier reviewer, which pulled the 4.4.3 tarball; the filing seat's container had no node_modules. The card's own instruction stands as a dispatch premise: whoever takes this re-reads that line against the pinned version first. ⇒ if it does not reproduce on the pinned zod, the defect is not there and the correct outcome is premise_still_valid: false with the reading — ⛔ not a fix built on an inherited citation.

⭐ Recording why the filing is trustworthy even so: the seat separated what it read from what it relayed, named the reviewer as the source, and named the re-read as mandatory — the failure mode it was guarding against is exactly the one that would have made this card wrong.

---

Generated by Claude Code

[os-sam]

Claim: PM loop round 20 from seat domain:spec#3
Session: session_01HnRAeVTLJevtQ5iCPX6JSm
Branch: claude/issue-19151-assignment-config-catchall-proto
Seat: domain:spec seat 3 (seat post #18883)
Clause-②: yes (narrowing)

⚠️ Corrected 2026-09-20T18:30Z: no → yes (narrowing). This seat had it wrong, and the dev — which had done the work — had it right.

The original no was written before the work existed: a claim declares the direction the seat expects, and this seat expected a pure refusal. What the diff actually does is add a new exported symbol, refuseCatchallProtoKey, to packages/spec/src/shared/record-proto-key-guard.ts. A new export is a public-surface addition, which is yes on the criterion whatever the accept set does. The arm stays narrowing because the accept set narrows by exactly one name. Two axes, and the declaration has to answer both.

⛔ Stated plainly because the standing rule 「⛔ 永不把 no 翻成 yes 去过门」 exists precisely for a write like this one: the flip is on the MERITS, ⛔ not to clear a gate. Two facts make that checkable rather than assertable — the dev declared yes (narrowing) in its PR body independently, before this seat read any gate output, and the new export is visible in the diff with or without a checker. That the C5 row also stops firing is a consequence, ⛔ not the reason, and the seat would owe this correction with the gate silent.

⭐ And the tell C5 names is FALSE, which is why it must not be the reason. It is builtin-node-config.zod.ts:961 — the line 'an assignment node config',, the label argument to a function call, ⛔ not a member of any closed set. That is exactly the shape this seat filed as #19384 at 15:01Z today: memberTellKind routes any BARE_STRING_ELEMENT on contract source to T2 with no closed-set opener required, while the row it prints asserts 「a new member of a closed set」. Per REFUSAL_SENTENCE, a demonstrated false tell is repaired in the matcher or filed as its own card when out of this PR’s scope — it is filed, and ⛔ this PR does not carry that repair.

⇒ needs:contract-review hung on both the card and PR #19419 in one stroke, and the at-tier review is owed once the dev reports.
Thread-read: 5747731313
Serial constraints cleared: ⏱️ 2026-09-20T17:10:26Z, origin/main 0870fb5418. NO open PR holds packages/spec/src/automation/builtin-node-config.zod.ts — all 24 open PRs read, file list fetched per PR, ⛔ not sampled. ⭐ Lit control on the same scan: 1 PR touches packages/spec/src/automation/ at all, so the zero is an absence the instrument could see.

⚠️ This seat's own fence on this file is RELEASED, and the seat post was stale on it. Section ③ listed builtin-node-config.zod.ts among five files fenced off for PR #19147 (the predecessor's 留守 session). That PR MERGED 2026-09-20T13:21:02Z — read first-hand — so the fence is gone. ⛔ Recorded rather than silently dropped: a fence that outlives its cause blocks work for free.

Premise re-verified on TODAY's tip, ⛔ not on the card's remembered one

The card was filed before PR #19147 landed, and that PR is what makes the premise worth re-taking: it added the __proto__ refusal to the assignments RECORD. This card is about the OBJECT's own .catchall(), one level up. Read first-hand at 0870fb5418 ⏱️ 2026-09-20T17:10:26Z (H44 repair, edited in 18:04Z: this paragraph named the tip with no 取数时刻 of its own, which reads as UNTAKEN even though the same tip is stamped six lines above — the rule is per paragraph, ⛔ not per comment):

export const AssignmentConfigSchema = lazySchema(() => z.object({
  assignments: refuseRecordProtoKey(      // ← #19147's guard, on the RECORD
    z.record(z.string().min(1), AssignmentValueSchema, { … }),
    'assignments',
  ).optional().describe(…),
})
  .catchall(z.unknown()));                 // ← UNGUARDED, and this card's subject

⇒ the premise stands: #19147 guarded the slot below it and left the top level open. The two are different sites, exactly as the card argues, and maintainer ruling A-narrow (5725370319 on #17852) named only the two slots #19147 fixed, adding 「⛔ No sweep over the 398 records; a further record keyed by author-named identifiers is its own card when measured」. This is that card, and this round is the measuring.

⛔ Not a sweep. ⛔ Not a re-opening of #17852's ruling. One site.

Take-order note, recorded as reversible: NORTH-STAR rule 3 bars p2/p3 工具卡 and 契约卫生卡; this seat reads a silent DROP of authored data on a published parse surface as neither — it is 北极星 clause 4's 「永不静默」 shape on a product surface. The three p1 cards above it in the order (#17667 · #19365 · #19289) are each blocked by an open PR's working surface, with the reading on their faces.

— domain:spec seat 3

---

Generated by Claude Code

[os-sam]

os-dev-report
{
"issue": 19151,
"status": "done",
"branch": "claude/issue-19151-assignment-config-catchall-proto",
"pr": "#19419",
"session": "session_01HnRAeVTLJevtQ5iCPX6JSm",
"premise_still_valid": true,
"summary": "The vendor half was re-read first-hand before any edit and HOLDS: packages/spec resolves zod 4.4.3 exactly (createRequire from the package entry; pnpm why reports 'Found 1 version of zod'), and v4/core/schemas.js carries the __proto__ skip at 767-769 inside handleCatchall, above _catchall.run — one of exactly two such sites in the file, the other being $ZodRecord's at 1496. The drop was then reproduced end to end through the real exported schema with two lit controls. Fixed by refuseCatchallProtoKey, a sibling of refuseRecordProtoKey sharing one private implementation; it is a sibling rather than a reuse because the refusal names the parser that would otherwise drop the key, and an author sent to 'z.record()' would go looking at the assignments slot one level down. __proto__ only: constructor/prototype/toString were measured to reach the catchall unskipped and round-trip intact at this position, so the record guard's reasoning was re-derived here rather than copied, and nothing else narrows. One ledger path moved (dropped-refinements.baseline.json: assignments.out.valueType becomes out.assignments.out.valueType) because the guard is a preprocess pipe; same single site, and the build gate printed the corrected entry.",
"tests": "ALL exit codes captured before any pipe. BUILD+ARTIFACTS: pnpm --filter @objectstack/spec build && check:generated exit 0 — 'All 15 generated artifacts are up to date'. SPEC SUITE: pnpm --filter @objectstack/spec test exit 0 — 504 files / 14754 tests. TYPECHECK: pnpm --filter @objectstack/spec typecheck exit 0 (test layer compiled too). IMPORT SIDE: 8 service-automation reconciliation suites (form-Zod ledger, expression ledger, config parse/schemas/unknown-keys, assignment envelope x2, logic nodes) exit 0 — 117 tests, resolved through spec's dist (the package is NOT vitest-aliased to src), after building its 21-package dependency closure. GATES: dispatch-gates --commands then --ran: 81 derived, 81 run, 0 UNRUN; 78 exit 0, 3 exit 3 = PREREQUISITE NOT MET (check-plugin-teardown-shape --self-test needs a positive control outside this shallow clone; check:dual-build-cjs-loads and check:type-check-debt need a whole-repo dist this box did not build inside the foreground cap) — NOT reds, NOT passes. Plus pnpm lint (repo-wide eslint . --no-inline-config) exit 0, so no narrowing was needed and none is claimed. ABLATION: scripts/ablation-replace.mjs, anchor declared and hit exactly 1 time, mutation proved on disk (anchor 1 to 0; blob 50724ef84f1d to 21c448025a16), fix committed BEFORE the mutation. Result: 6 failed / 88 passed of 94 — direction RED as predicted, and the 6 are exactly the 6 new #19151 assertions while the #17852 / #18847 record-guard pins stayed GREEN under the same mutation, which is the pin that the two guards are independent. Restore proved: blob after restore 50724ef84f1d == blob at HEAD 50724ef84f1d and git diff HEAD empty; whole tree clean afterwards. No dist leg: the subject resolves through a same-package relative import to src, so no rebuild is part of this ablation and none is claimed. The sharpest pin discriminates refused / silently-dropped / silently-kept through one classify() helper, so neither the defect nor an over-correction can pass it.",
"mcp_calls": "0 — no MCP GitHub tool was called, read or write.",
"api_writes": "2 REST proxy writes: POST /repos/objectstack-ai/objectstack/pulls (the draft PR, body written once and read back byte-identical, one footer) and POST /repos//issues/19151/comments (this report). Plus 4 git push to the feature branch (empty-branch routing probe, then one per commit), verified with git ls-remote — remote head 1418799 == local HEAD. ZERO label writes, zero assignee writes, zero POST /issues, no ready/draft flip, no auto-merge, no review request, no merge — as the dispatch ordered.",
"open_questions": [
{
"question": "Clause-②: the claim comment 5751323556 declares no; this PR declares yes (narrowing). Recorded as a conflict rather than silently picked, because the dispatch told me to decide while the standing rule says to copy the claim's line.",
"options": [
"A — keep yes (narrowing): this is a refusal newly added to a published parse surface, the same act the sibling PR #19147 declared yes (narrowing) for on the same family; of the two possible errors, a false no is the one that lets a contract narrowing land without contract review",
"B — seat corrects it back to no on the card and the PR body, if it reads the criterion the other way"
],
"recommendation": "A, because grading a sibling site differently from its family is how a family stops being one, and the conservative direction is the one that waits for the review. It is written once, in the PR body, and nowhere else — the seat owns any correction, including the needs:contract-review label, which I did not write."
}
],
"out_of_scope_findings": [
"to file (3 classes: (a) reproducible defect; dedupe words: check-issue-citations qualifier probe · objectstack#N allocated-but-absent · buildBoard wanted filter · self-qualified citation never probed · issue-citations false phantom): scripts/check-issue-citations.mjs cannot resolve a same-repo citation written objectstack#N. buildBoard builds its probe set as rows.filter((r) => !r.qualifier), excluding every qualified citation, while classifyCitation treats objectstack#N as naming THIS repo and resolves it against that same board — so the number is never probed, never on the board, and always reports allocated-but-absent. Two-leg measurement on this diff, same 6 citations, same run mode: qualified spelling gave board: probed (1 citations) / 2 allocated-but-absent / exit 2; bare spelling gave board: probed (2 citations) / 6 resolves / exit 0. Independent control: GET /repos//issues/17852 answers HTTP 200, state closed, so the number resolves and the gate's own transport would have found it had it asked. Reproduced identically with origin/main's newer copy of the script, so it is not a staleness artifact. This gate went required in lint.yml after this branch's base. This PR's added citations use the bare spelling, which is the repo's documented form and what the gate's own failure text prescribes; the gate itself is untouched.",
"to file (3 classes: (c) metadata-authoring trap; dedupe words: treeifyError proto TypeError · error.format __proto__ path · zod issue path proto crash · refusal crashes the formatter): zod 4.4.3's treeifyError and error.format() throw TypeError 'Cannot read properties of undefined (reading push)' on any issue path containing __proto__. Reproduced first-hand against PR #19147's LANDED record guard (path ['assignments','proto']), with a lit control on the same schema: an ordinary refusal path formats fine. #19151's body already records the connection and the one-line remedy (path: []); this change deliberately keeps the landed sibling's path shape, adding no new exposure class, because changing it for one of the two guards would create two dialects and pre-empt a decision belonging to whoever takes that question.",
"noted, not filed: two open PRs also hold packages/spec/dropped-refinements.baseline.json — #19373 and #19335 — and that file is deliberately NOT merge=os-regen (recomputing a shrink-only ratchet can widen it), so whichever lands second reads the conflict by hand. 承接者: the second of those two PRs to land, or this one. No open PR holds either source file this change edits; lit control on the same 18:25:35Z scan: 11 open PRs touch packages/spec/ at all, 1 touches packages/spec/src/automation/.",
"noted, not filed: the sibling changeset .changeset/17852-record-proto-key-preparse-guard.md, still pending, writes its citations in the objectstack#N form. Changesets are a DEFERRED surface for check-issue-citations (it scans packages//src//*.ts and excludes tests), so nothing reds today; recorded only because it is the same spelling the finding above is about. 承接者: whoever fixes that gate.",
"noted, not filed: dispatch-gates warned this worktree derives from a tree 4 commits behind origin/main and that 3 of its derivation inputs moved in that window. The derived command list was byte-identical across the gap; the two families the moved lint.yml newly wires (check:merged-result, check:issue-citations) were identified by diffing those inputs against origin/main and RUN anyway, both green. origin/main was deliberately not merged — the dispatch allows one merge and warns against chasing a moving ref, and CI derives from the merge ref regardless. 承接者: CI on this PR."
]
}

---

Generated by Claude Code

[os-sam]

ACCEPT — card #19151, PR #19419

Round 1 at-tier contract review returns PASS. Recorded at 2026-09-20T19:21Z by the domain:spec seat 3 PM (seat post #18883).

Review of record: comment 5751993896 on PR #19419, keyed to head 1418799698e8bde70ea4f94b0799a9d688f5e3c7. I read it back myself rather than take the reviewer's word for it: Served-tier: CONTRACT_REVIEW_TIER (the constant's name, not a model id), Head-sha: naming that head, **VERDICT: PASS**, all at line start. git ls-remote origin refs/pull/19419/head returns the same sha, so the record names the head the PR points at now.

This seat is below CONTRACT_REVIEW_TIER, so the review was rendered by an isolated at-tier subagent and this seat adopts it. ⛔ Not a self-review.

The carrier was refused once, and the repair is part of the record

The first version of that record was refused by row C4 — I ran the gate before acting on the verdict, not after:

$ node scripts/pm/check-clause2-carriers.mjs --pair 19419     # before the repair
✗ C4 — its governing contract-review verdict carries the authorship pair HALF WRITTEN:
      no `Implemented-by:` line; `Reviewed-by:` carries no readable session ID
EXIT=4

The session id was present in the line but not the first token after the colon, so the reader took the value to be the word isolated. The gate is explicit that this is the worst of the three states — a record carrying neither line is a legacy verdict and stays silent, so writing one line badly is the only way to be refused. Repaired in place on the same comment (PATCH, HTTP 200; updated_at read back by this seat as 2026-09-20T19:17:28Z), with --template copied rather than composed:

Implemented-by: `claude/issue-19151-assignment-config-catchall-proto`
Reviewed-by: `session_01HnRAeVTLJevtQ5iCPX6JSm`

Implemented-by: takes the dev's branch because the dev was mode:subagent and has no session of its own; the value is read off the implementation claim 5751323556. Reviewed-by: is this seat's session, because an isolated review subagent has no session either and the seat that adopts the verdict writes its own. Re-run by this seat at 2026-09-20T19:20:23Z, true exit captured before any pipe:

$ node scripts/pm/check-clause2-carriers.mjs --pair 19419
✓ the clause-② declaration is readable in the fixed spelling, the `needs:contract-review`
  LABEL is in the same state on both LABEL carriers, and a review of record names this head
EXIT=0

⚠️ On a disagreement between two readings of the same gate, stated rather than smoothed over. The reviewer recorded --pair 19419 exit 0 at 2026-09-20T18:38:32Z. That reading was taken before its own record existed (created_at 2026-09-20T19:11:07Z), and C4 has nothing to judge until a verdict comment is on the head. So the two exits answer different questions and ⛔ neither is a flake. The rule this earns: a gate that reads a record you are about to write has not been run until you run it after writing it.

A ground I stated is withdrawn — the reviewer is right and I was wrong

When I corrected this card's Clause-② from no to yes (narrowing) at 2026-09-20T18:30:02Z I gave two grounds. The reviewer recorded that ground (a) — «a new exported symbol is a public-surface addition» — is overstated. I verified it against the tree rather than concede on the reviewer's say-so:

$ git grep -n "record-proto-key-guard" refs/pm/19419 -- packages/spec/src | grep -v '\.test\.ts'
  automation/builtin-node-config.zod.ts:85: import { refuseCatchallProtoKey, refuseRecordProtoKey } …
  data/object.zod.ts:18:                   import { refuseRecordProtoKey } …
$ git grep -n "refuseCatchallProtoKey\|refuseRecordProtoKey" refs/pm/19419 -- packages/spec/api-surface
  (no rows)

packages/spec/src/shared/index.ts exists and never re-exports the module; the only two importers are internal .zod.ts files; api-surface/ holds zero entries for either guard. The symbol is module-internal, so ground (a) does not hold.

⭐ The declaration does not move. Clause-②: yes (narrowing) stands on ground (b) alone — ruling of record 5725370319 on #17852 (「accept-set narrowing ⇒ Clause-②: yes」) plus the sibling precedent on #19147 (5737516015) — which was always independently sufficient. What changes is the reasoning on the record, and it is corrected here rather than left to live only in the reviewer's note. A no would have let a ruled narrowing land without at-tier review; that judgement was right for the wrong second reason.

What the review established, in one line each

• Zone 1 — the vendor premise holds. packages/spec resolves zod 4.4.3 exactly; the lockfile's 4.6.1 is reached only through better-call/better-auth. handleCatchall skips __proto__ above _catchall.run, two sites in the ESM copy and two in the CJS twin.
• Zone 2 — the refusal set of exactly one name is correct at this position, re-derived through the real exported schema against an unguarded twin: __proto__ refused; constructor, prototype, toString, valueOf, hasOwnProperty, __defineGetter__, isPrototypeOf all measured round-tripping in both trees. Controls lit on both sides.
• Zone 3 — the pin discriminates, and the two guards are independent in BOTH directions. Ablating the catchall guard: 6 red / 88 green, exactly the three [finding] the third __proto__ site: AssignmentConfigSchema's own .catchall() silently drops a TOP-LEVEL flow variable named __proto__ #19151 refusal pins plus three refuseCatchallProtoKey pins, record-guard pins untouched. Ablating the record guard: 9 red / 282 green, catchall pins untouched. Restores proved blob-equal to HEAD.
• Zone 5 — one ledger site, no widening. A one-line path correction; the measured block is byte-identical on both sides (569 sites / 204 schemas). Lit control: putting the old path back makes build-schemas.ts --check exit 1 naming exactly that entry.
• Zone 6 — 81 gate families derived at head, 81 run, 0 unrun, 0 red. 76 exit 0 and 5 exit 3; every exit 3 is PREREQUISITE NOT MET by its own script's contract, and two of them turned exit 0 after the closure build. ⛔ exit 3 is not a red and is not reported as green either. Spec suite 504 files / 14,754 tests; repo-wide lint exit 0; 117/117 service-automation resolved through spec's dist.

CI on the head, read by this seat

Per check NAME, newest-run-wins, on the head the PR points at now (1418799698): 35 unique names — 30 success, 5 skipped, 0 failing, 0 pending.

Landing route

check-governed-merges.mjs --pr 19419 at 2026-09-20T19:21Z: 0 of 6 paths hit the governed register, 439 changed lines (+386 / −53) — under the 5000-line human-merge threshold. ⇒ ordinary queue landing applies. Re-derived from GOVERNED_SURFACES on the final file list, ⛔ not recalled from earlier in the session.

⛔ What this seat did NOT establish

1. The five skipped checks are not certified as expected skips. check-expected-skips.mjs --pr 19419 died at import — Cannot find package 'yaml' — so it produced no reading at all. That is an instrument that could not run, ⛔ not a clean result, and «0 failing» above is a statement about the 30 that ran and the 5 that did not, not a certification that the 5 were right to skip.
   ⚠️ Cause established before anyone files a card off that sentence: this is the environment, ⛔ not a repo defect. yaml is a declared root devDependency (^2.9.0 in package.json) and this shared checkout has no node_modules/ at all — scripts/check-docs-section-name.mjs imports it too and would die the same way here. The gate is runnable wherever the workspace is installed, and CI installs it. ⭐ A tool that cannot resolve a declared dependency is a missing install; only an undeclared one is a finding.
2. Everything on the reviewer's own NOT MEASURED list, which this ACCEPT adopts unchanged: the three shallow-/dist-prerequisite gates not re-run with their prerequisites, test:repo, repo-wide typecheck/test, the cloud and hotcrm repos (outside this container), and the objectui scan for treeifyError consumers.
3. The landing hazard is noted, not cleared. If feat(spec)!: publish the $-prefix key ban the normalized filter enforces, and make the ratchet able to see it #19335 lands first, its pruned rung could re-render this pipe's ledger site path. The build gate says so on the next merge of main; it is not a blocker for this head.

---

Generated by Claude Code