fix(spec): make the declaration-parity ratchet able to fail on a spec row with no manifest component

[os-bill]

Part of #18407

Clause-②: no

TL;DR

Regenerating sdui.manifest.json does not produce object-tree, and no pin bump would
change that — measured, byte-identically, below. What this PR lands is the other half of the
card: check:react-declaration-parity can now fail on a spec row whose block has no
manifest component. It goes red on object-tree today, and that red is the deliverable, not
a mistake — the repository-side cure is upstream in objectui and is named in the failure text.

⚠️ This PR is a draft on purpose. Landing it as-is puts a standing red on a required context
for every PR in the repo. See "What has to happen before this lands".

Leg 1 — re-measured on fetched origin/main (7d0f911), independently

git show origin/main:sdui.manifest.json
  components                            57
  component NAMES containing "tree"     []        == zero, a reading
  LIT CONTROL, same parse, first 6 names read out:
    object-grid · list-view · object-form · embeddable-form ·
    object-master-detail-form · object-kanban
  LIT CONTROL, same parse, every name starting "object-":
    object-grid, object-form, object-master-detail-form, object-kanban,
    object-calendar, object-gantt, object-timeline, object-map,
    object-metric, object-chart, object-pivot

The parser reads names, so the zero is a reading and not a failed search.

The other half, re-measured in objectstack-ai/objectui at the pinned
53ded82bf7a494f54e344e19099dbf00854b8694 (.objectui-sha, untouched by this PR):
packages/plugin-tree/src/index.tsx registers the same renderer twice —
ComponentRegistry.register('object-tree', …) at line 34 and
ComponentRegistry.register('tree', …) at line 41. Both carry a namespace, neither carries a
tier. That checkout is shallow (git rev-parse --is-shallow-repository answers true); the
pinned commit object is present, so every reading above is a blob read at a named commit, not a
windowed history query, and none of them needed the truncated history.

Leg 2 — regeneration is a byte-identical no-op

node scripts/gen-sdui-manifest-node.mjs (the generator that writes the tracked artefact; the
repo's pnpm sdui:manifest is the browser route and needs a vendored objectui build) was run
against published @object-ui/* 17.6.0, the version the pinned commit declares:

→ installing @object-ui/* 17.6.0 ... → enumerating the registry (16 modules)...
✓ wrote sdui.manifest.json (57 components, 66910 bytes, sha256 49211fee7792…)

After the run, with git add -A performed FIRST and git diff --cached read after it, the
manifest was not in the diff at all:

git rev-parse :sdui.manifest.json            78f870e42fe9fec1e9fad2e17c48370d8eca2cbe   (index)
git hash-object sdui.manifest.json           78f870e42fe9fec1e9fad2e17c48370d8eca2cbe   (worktree)
git rev-parse origin/main:sdui.manifest.json 78f870e42fe9fec1e9fad2e17c48370d8eca2cbe
sha256sum sdui.manifest.json                 49211fee7792…  == scripts/sdui-manifest.record.json

The only thing the run changed was generatedAt in the provenance record, 2026-09-08 →
2026-09-20. The artefact is unchanged, so that record still describes it accurately; the
date-only churn was reverted and the tree is clean against origin/main. Nothing in this PR
hand-edits a generated artefact, and nothing in it touches .objectui-sha.

Leg 3 — what decides it: registered, but not public

The gate's own words are "NO component in the manifest — not registered or not public".
Measured against the same published 17.6.0 install the generator used, it is the second:

getAllConfigs()     494 configs — NAMES containing "tree":
                    ["ui:tree-view","plugin-tree:object-tree","view:tree"]   (deduped)
getPublicConfigs()   57 configs — NAMES containing "tree": []
  LIT CONTROL getAllConfigs()    grid names: ui:grid, field:grid, plugin-grid:object-grid,
                                             view:grid, plugin-grid:import-wizard,
                                             plugin-dashboard:dashboard-grid
  LIT CONTROL getPublicConfigs() grid names: object-grid, grid
PUBLIC_BLOCKS        57 entries — NAMES containing "tree": []
getConfig('object-tree') -> registered=true  tier=undefined  namespace='plugin-tree'
                            inputs=['objectName','tree']
getConfig('tree')        -> registered=true  tier=undefined  namespace='view'
  LIT CONTROL getConfig('object-grid') -> registered=true tier=undefined

PUBLIC_BLOCKS has exactly 57 entries and the manifest has exactly 57 components — the public
tier IS the manifest. The file and the lines that decide it, all in objectui at the pinned sha:

what	where	says
the curated list	packages/core/src/registry/public-blocks.ts lines 26–117	57 tags, neither 'object-tree' nor 'tree' among them
path 1 into the contract	packages/core/src/registry/Registry.ts line 821	for (const tag of PUBLIC_BLOCKS) add(tag, this.getContractConfig(tag));
path 2 into the contract	packages/core/src/registry/Registry.ts line 824	if (cfg.tier === 'public' && !key.includes(':')) add(key, cfg);
why neither path fires	packages/plugin-tree/src/index.tsx lines 34–39 / 41–46	both registrations pass namespace + label + category + inputs, and no tier

⇒ Both producers — the node generator and the browser dump — faithfully serialize a registry
that genuinely does not expose object-tree on the public tier. The artefact is correct. The
divergence is that a spec row expects a component the public tier does not carry. This
reproduces, independently, the measurement the domain:spec seat recorded on the card.

What this PR changes

check:react-declaration-parity could not fail on its loudest signal. The baseline ratchet
suppressed the missing axis behind

if (state.missing && base && !base.missing) regressions.push(…)

With no baseline row there is no base, so a spec row whose block the public registry does not
carry arrived pre-accepted: the gate printed its ✗ line and exited 0, and would have kept
doing so for as long as nobody regenerated the baseline. Measured on origin/main before the
change — the same run lint.yml performs on every PR:

✗ object-tree: NO component in the manifest — not registered or not public.
Summary: 126 spec-only divergences, 1 blocks missing from the registry.
## Baseline ratchet
✓ no new DECLARATION divergence vs accepted baseline
  exit 0

…while the very same gate in plain --strict mode (no baseline) already exits 1 on that
same tree. The teeth existed; only the mode CI actually runs swallowed them.

The asymmetry is what makes this a bug rather than a policy: registryOnly was already
ratcheted against an absent baseline row — baseRO falls back to the empty set, so every
registry-only input on an unbaselined block reports as new. Only missing carried the extra
conjunct. (The comment sitting under that loop, "a brand-new block … is fine (purely additive
coverage)", was therefore not true of the code it described.)

So:

• missing is judged every run, baseline or not. A missing: true baseline row does not
  buy silence either.
• --update refuses to write a baseline while any block is missing, naming the block. That
  is deliberate: --update is the one command that can mint an acceptance, and re-running it to
  clear a fresh red is the reflex this gate has to survive. The row it would write is exactly
  the missing: true the spec(ui): ComponentPropsMap has no rows for object-map, object-gantt and object-tree — add them from the renderers' read points (#7751 method) so 「以协议为准」 resolves for all five ladder blocks (objectui#8348 Q1, ruled C) #18305 round declined to write, in that round's own words "that would
  be accepting a divergence rather than reporting it" — so the producer refuses rather than
  the reviewer having to remember.
• The failure text carries the cure and rules the baseline out: expose the block on the
  registry public tier (PUBLIC_BLOCKS, or tier: 'public' on the registration) and regenerate
  with node scripts/gen-sdui-manifest-node.mjs, or drop the spec row. ⛔ Never a baseline row.

⛔ No missing: true baseline row is added by this PR, and packages/spec/react-declaration-parity.baseline.json is not touched.

The fixtures were resting on the hole

The exit-code fixtures in check-react-blocks-declaration-parity.test.ts fed the gate a
one-component manifest, so twelve of the thirteen evaluated blocks were absent from every
one of them — including the control that claims "exits 0 when the manifest matches the accepted
baseline". They passed only because an absent, unbaselined block could not regress. They now
declare every evaluated block, with the roster read off the gate's own report rather than
restated (a literal list would rot the day a ComponentPropsMap row lands), and omit spells
out the absence where an absence IS the subject.

Reverse verification — both legs, on-disk proof, restored byte-identically

Run through scripts/ablation-replace.mjs, from the committed state, so the red/green numbers
are trustworthy and the restore has a real restore point:

leg	mutation	on-disk proof	result
A	put && base && !base.missing back	anchor 1 → 0, blob 8bda7e2d5e7f → d4bf6f71d12a	3 failed / 33 passed — exactly the three pins of the new red; every control stayed green, and the harness reproduced the hole verbatim (✗ object-grid: NO component in the manifest followed by ✓ no new DECLARATION divergence)
B	neutralise the --update refusal predicate	anchor 1 → 0, blob 8bda7e2d5e7f → d81336b2a156	1 failed / 35 passed — only the --update pin; the "still writes when nothing is missing" control stayed green

Both restored with blob == HEAD (8bda7e2d5e7f) and git diff HEAD empty. No ablation
artefact is left in the tree.

Checks — real exit codes

check	exit	note
pnpm --filter @objectstack/spec build	0	required before any of the below is believable
pnpm --filter @objectstack/spec typecheck	0	includes check:scripts-typecheck, which compiles both changed files
pnpm --filter @objectstack/spec test	0	500 files / 14649 tests passed
check-react-blocks-declaration-parity.test.ts alone	0	36 passed (30 before, +6 new)
eslint . --no-inline-config (the whole repo, not narrowed)	0	6914 files linted, 0 files with findings — read from --format json
check:react-declaration-parity --baseline … --strict	1	⚠️ RED, and intended — see below
53 further derived gate families	0	derived with node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack at 49f7e0d23e, then run; list and logs in the report comment
check:dual-build-cjs-loads, check:lean-entry-closure, check:type-check-debt	3	each prints PREREQUISITE NOT MET … NOT a pass: nothing was measured — they read a full pnpm build closure. NOT MEASURED, not findings
check:pm-dispatch-gates	124	NOT MEASURED: its self-test exceeds a 9-minute foreground budget on this shared box. Whole-tree family; this diff does not touch scripts/pm/dispatch-gates.mjs

The red, in full:

## Baseline ratchet
⚠ NEW declaration divergence vs accepted baseline:
    - object-tree: declared in the spec, NO component in the manifest, and NO baseline row
      — so nothing here could have "regressed". The absence IS the divergence; it is not
      onboarding slack.

  → NO COMPONENT IN THE MANIFEST is a different class and has NO --update escape: the spec
    declares a block the public registry does not expose, so there is no prop-level
    disagreement to accept. Expose it on the PUBLIC tier (objectui `PUBLIC_BLOCKS`, or
    `tier: 'public'` on the registration) and regenerate — `node scripts/gen-sdui-manifest-node.mjs`
    — or drop the spec row. ⛔ Never a baseline row: that accepts the divergence instead of
    reporting it.

Blast radius is exactly one block. Of the thirteen blocks this gate evaluates, four have no
baseline row (object-gantt, object-map, object-timeline, object-tree — the committed
baseline's last write predates #18403, which added those ComponentPropsMap rows), and only
object-tree is absent from the manifest. The other three are present and stay green.

What has to happen before this lands

Lint & Repo Gates is a required context, so merging this while object-tree has no manifest
component puts a standing red in front of every PR in the repo. Two routes, neither of which is
this seat's to pick:

1. objectui first. Add 'object-tree' to PUBLIC_BLOCKS (or tier: 'public' on the
   plugin-tree registration), release, bump .objectui-sha, regenerate the manifest — then
   this PR is green and lands with it. That is the shape AGENTS.md already prescribes for a
   change that breaks against the pinned sibling: it ships together with the sibling fix and the
   pin bump, or it does not ship. ⛔ .objectui-sha is held by open PR sdui-parser: port inert-quick-add and member-type-mismatch from objectui, re-record the lockstep and bump the pin #18723, so this seat did
   not touch it; and note a pin bump alone would not help — the pinned SOURCE lacks the entry
   too, measured above.
2. spec side. Drop the object-tree row from ComponentPropsMap, so the spec stops
   declaring a block the public tier does not carry. That reverses one arm of the decision landed in
   feat(spec): object-map, object-gantt and object-tree get ComponentPropsMap rows, derived from the renderers' read points (objectui#8348 Q1-C) #18403, and is not a seat's call.

⛔ Deliberately not offered as a third route: writing the missing: true baseline row. The
#18305 round declined to write one for a stated reason, and this PR makes that refusal
mechanical rather than a matter of remembering.

Acceptance notes

• #17735 is a different cell on the same file (the tracked manifest vs the browser dump
  disagreeing on the fields the parity gate consults) and is out of scope here — it is not
  addressed by this PR and remains open. The relevant half was measured only incidentally: both
  producers agree about object-tree, because both read getPublicConfigs().
• scripts/sdui-manifest.record.json carries a generatedAt that is now older than the last
  run which reproduced the artefact byte-for-byte. Noted, not filed: nothing reads that field,
  and re-recording a date under an unchanged sha256 is churn on a generated provenance record.
• No changeset. Measured rather than assumed: @objectstack/spec's files[] is
  dist, json-schema, liveness, prompts, llms.txt, README.md, src/**/*.zod.ts, CHANGELOG.md, api-surface, api-surface-declarations, spec-changes.json; packages/spec/scripts/** is in
  none of them. Grepping every one of those paths after a build for missingRegression,
  MISSING_IS_NEVER_RATCHETED_AWAY, fullManifestFor, evaluatedBlockTypes and stillMissing
  returns 0 files each, with positive controls ComponentPropsMap → 38 files and
  PageComponentSchema → 50 files on the same corpus. This diff publishes nothing, so it takes
  skip-changeset.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• 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.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 0 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 1739f71879f27d10c07fbde77fcf0728ed9abb81 → packageMentionDocs.

[os-bill]

Contract review

Served-tier: 1/1 CONTRACT_REVIEW_TIER
Reviewed-by: session_01JbZnqu8bt6YqfJsr9vaFb3 (isolated reviewer subagent; no direction taken from the dispatching seat)
Reviewed at 2026-09-20T09:02Z · PR #19270 (draft) for card #18407 · base origin/main 1739f71879; control tree 7d0f911da9 = the merge-base, and the two commits between them touch only field.zod.ts, a repeater test, a changeset and a docs page — none of the gate, the manifest, the baseline or packages/spec/package.json.

49f7e0d23ea931a925a5ec0f672bf205ac639190

Evidence: the card body and its triage ruling, the PR (diff, body, check-runs, one job log), origin/main, objectui at the pinned sha and at its newest main, and the published @object-ui/* 17.6.0 tarballs. Seat comments were read; nothing was adopted from them — every number below is re-taken.

① Serves the card, and only that — the half that can be delivered here.

• The diff is exactly two files, packages/spec/scripts/check-react-blocks-declaration-parity.ts and its .test.ts; git diff --name-only 7d0f911da9..49f7e0d23e lists nothing else — no manifest, no provenance record, no .objectui-sha, no baseline, no changeset.
• The card's zero, re-taken on origin/main: sdui.manifest.json has 57 components; names containing "tree" → []; LIT CONTROL on the same parse, names starting object- → object-grid, object-form, object-master-detail-form, object-kanban, object-calendar, object-gantt, object-timeline, object-map, object-metric, object-chart, object-pivot (11). The gate on origin/main under CI's exact invocation (--baseline react-declaration-parity.baseline.json --strict) prints ✗ object-tree: NO component in the manifest and then ✓ no new DECLARATION divergence → exit 0; plain --strict on the same tree → exit 1. The card's sharp half ("cannot fail") reproduces.
• Regeneration re-measured rather than taken: built packages/sdui-parser/dist, installed the 17 published @object-ui/* 17.6.0 packages from npm (the version packages/core/package.json declares at objectui 53ded82b, read through OBJECTUI_ROOT), ran node scripts/gen-sdui-manifest-node.mjs --modules-root … on the control tree: ✓ wrote sdui.manifest.json (57 components, 66910 bytes, sha256 49211fee7792…); git hash-object before = after = origin/main = 78f870e42fe9; git status shows only scripts/sdui-manifest.record.json (its date-only field). In the regenerated file, names containing "tree" → [], LIT CONTROL 11 object- names. Byte-identical no-op, confirmed.
• Why it is absent, re-measured with my own probe on that same install: getAllConfigs() 494 configs — tree names ui:tree-view, plugin-tree:object-tree, view:tree (LIT CONTROL, grid names: 6); getPublicConfigs() 57 — tree names [] (LIT CONTROL: object-grid, grid); exported PUBLIC_BLOCKS 57 — tree [] (LIT CONTROL: object-grid, grid); getConfig('object-tree') → registered, tier=undefined, namespace=plugin-tree, inputs objectName, tree. At objectui source 53ded82b (shallow clone, commit present): packages/plugin-tree/src/index.tsx registers 'object-tree' at line 35 (namespace plugin-tree) and 'tree' at line 42 (namespace view), neither with a tier; packages/core/src/registry/public-blocks.ts has 57 entries, a tree grep exits 1, LIT CONTROL 'object-grid' line 28 and 'grid' line 100; Registry.ts public-tier paths at lines 821 (PUBLIC_BLOCKS), 824 and 828 (tier === 'public' on the config and on the entry meta) — none can fire. Also checked what the PR did not: objectui's newest main (078f2e4f) still has no tree entry in PUBLIC_BLOCKS, still registers without a tier, and @object-ui/core is still 17.6.0 — a pin bump to today's head would not produce the entry either.
• Scope verdict: the triage ruling names two deliverables — an object-tree entry in the manifest, and "spec row with no manifest row" going red on its own. The first is not producible from this repository: both producers faithfully serialise a public tier that does not carry the block, so the cure is objectui's curation or the spec row, a decision. The diff delivers the second, touches nothing else, and is declared Part of, not a close. Not a substitution.

② Clause-②: no is a true reading of this diff.

• @objectstack/spec files[] at the head (byte-identical to main): dist, json-schema, liveness, prompts, llms.txt, README.md, src/**/*.zod.ts, CHANGELOG.md, api-surface, api-surface-declarations, spec-changes.json — scripts/ in none. Positive control on the same manifest: npm pack --dry-run at the head packs 293 entries, 0 under scripts/ and 0 matching declaration-parity, while src/ui/component.zod.ts, src/ui/page.zod.ts and README.md are packed.
• exports (19 keys) names no scripts/ path, and nothing under packages/spec/src imports either changed file (the only src → scripts imports are three test files pulling scripts/lib/export-origins-testkit, untouched). No published payload gains a key, no closed set moves, no export or registry entry moves. The one accept-set that narrows is the CI gate's own --update, which is tooling, not a published contract. skip-changeset is the label AGENTS.md assigns to exactly this.

③ Sound, and nothing is left vacuous — with one body error and two costs to name.

• Real exit codes, this act:

run	head 49f7e0d2	control 7d0f911d
gate --baseline react-declaration-parity.baseline.json --strict (CI's line)	1 — object-tree: … NO baseline row	0 — same ✗ line, then ✓ no new
gate plain --strict	1	1
the gate's own suite (vitest run --project local, that file)	0 — 36 passed	30 tests in the file
pnpm --filter @objectstack/spec typecheck (incl. check:scripts-typecheck, check:test-typecheck)	0	—

• (a) Fixtures. Verified by swapping one file at a time between the two trees in their own worktrees (blobs checked: gate 6f6ccc1a ↔ 8bda7e2d, test f53bfe53 ↔ 20bbd1ae). Main's old test file against the head gate: 6 failed / 24 passed — exits 0 when the manifest matches the accepted baseline, carries the caveat on a clean baseline ratchet too, a block not yet in the baseline is additive, accepts a node-level key … (dataSource), accepts the other node-level key … (className), applies to the react-block half too — each a one-component-manifest fixture expecting a clean ratchet; they passed on main only because twelve absent, unbaselined blocks could not regress. Head's test file against the main gate: 4 failed / 32 passed — exactly the four #18407 pins (absent block with no baseline row is a regression; the failure text sends the reader upstream; a missing: true row does not buy silence; --update refuses), with both CONTROL cases green. The repaired fixtures discriminate in both directions. evaluatedBlockTypes() carries its own lit control (it throws unless object-form, list-view and object-grid are read off the report); the head run evaluates 13 blocks, the baseline has 9 rows, the four without a row are object-gantt, object-map, object-timeline and object-tree, and only object-tree is absent from the manifest — blast radius one block, as the PR says.
• (b) Landing. ⚠️ The PR body says the red lands in Lint & Repo Gates. It does not. In lint.yml at origin/main the parity step (line 6344) is inside job typecheck-consumers (Type Check · consumer gates), a lane of the aggregate typecheck (TypeScript Type Check, needs: all four lanes); Lint & Repo Gates (job lint) carries check-sdui-manifest.mjs, not this gate. The PR's own CI on this head agrees: Type Check · consumer gates → failure, its log ending in the object-tree … NO baseline row block and Exit status 1; TypeScript Type Check → failure. The ruleset on main (REST, HTTP 200) lists seven required contexts, and TypeScript Type Check and Lint & Repo Gates are both among them, so the consequence the body draws holds — merged as-is, a required context is red on every later PR and on main's own runs, and the queue lands nothing until objectui exposes the block or the spec row is dropped — but the context it names is wrong. ⛔ Not patched by this review; correct it on the next body edit the seat must make anyway (readying the draft). The hold is the draft flag alone; that decision is outside this review and is not the verdict.
• (c) Circumvention, probed on the real manifest at the head: a hand-written baseline row object-tree: {missing: false} → exit 1 (block vanished from the manifest); a hand-written {missing: true} row → exit 1 (does NOT accept this); the reflex, --update against a copy of the committed baseline → exit 1, refusing to write a baseline while 1 block(s) have NO component … - object-tree, and the copy's sha256 is unchanged before and after. Control, main's gate, same command → exit 0, wrote declaration-parity baseline … (13 blocks), and the written file carries object-tree: {registryOnly: [], missing: true} — the acceptance the head refuses to mint. What remains is outside the gate: editing the gate or the workflow step, hand-editing sdui.manifest.json (caught by check-sdui-manifest.mjs sha256-vs-record in the lint job) or removing the ComponentPropsMap row — each visible in a diff, none a baseline-side silence.
• Two costs, named, not blocking: while any block is missing, --update refuses to write anything, so a legitimate new registry-only accept on another block needs a hand edit of the baseline until object-tree is resolved (the failure text says so); and the committed baseline's _comment still describes the old semantics ("flags only NEW registry-only inputs or newly-missing blocks") and cannot be refreshed through --update for the same reason.

Measured first-hand in this act: the card's zero and its lit controls on origin/main; the manifest regeneration on the control tree from a fresh npm install of the published 17.6.0 set and the hash comparison; the registry probe on that install (all / public / PUBLIC_BLOCKS / getConfig) with grid controls; the objectui readings at the pinned sha and at newest main; files[], exports and npm pack --dry-run; both gate modes on both trees; the head suite and typecheck; both one-file-swap ablations; the three baseline and --update probes with a main control; the lint.yml job graph, the ruleset's required contexts, the PR's check-run conclusions and one job log.
Taken from someone else's reading and NOT verified: the PR's two surgical ablations through scripts/ablation-replace.mjs (whole-file swaps were run instead); its full pnpm --filter @objectstack/spec test (14649 tests), whole-repo eslint, pnpm build and the "53 derived gate families" — NOT MEASURED here; the browser route (pnpm sdui:manifest, Playwright plus a vendored objectui build) — NOT MEASURED, so #17735's cell is untouched by this review; the Registry.ts public-tier paths were read as source and exercised only through the published dist.

PASS

---

Generated by Claude Code

[os-bill]

Provenance correction to contract-review record 5748831865 (same reviewer, 2026-09-20T09:05Z) — the control TREE label, not any reading.

The pinned control worktree was re-pinned under this act — its reflog reads checkout: moving from 7d0f911da9 to origin/main at 2026-09-20T08:54:20Z, landing on fb33767cf1 — and the control batch started at 2026-09-20T08:54:31Z. So the two control gate runs (--baseline … --strict → exit 0, plain --strict → exit 1), the --update control (exit 0, writes object-tree: {registryOnly: [], missing: true}) and the manifest regeneration were taken on fb33767cf1, not on 7d0f911da9 as the record's ③ table column and preamble say. The two one-file-swap ablations were pinned with git restore --source=7d0f911da9 and are labelled correctly.

Why the readings stand for both trees: every input of the gate is byte-identical at 7d0f911da9 and fb33767cf1 — check-react-blocks-declaration-parity.ts 6f6ccc1adf72, its .test.ts f53bfe5340e3, react-declaration-parity.baseline.json 0c4691269c67, sdui.manifest.json 78f870e42fe9, packages/spec/package.json a8ddb4ec2226, lint.yml 1818c40c42f7; git diff 7d0f911da9..fb33767cf1 over the manifest record, the pin, manifest-prescription.ts, component.zod.ts, react-blocks.ts, page.zod.ts and both manifest scripts is empty (what did move: field.zod.ts and four test files). Re-run explicitly at fb33767cf1 after the move was noticed: baseline mode exit 0 (✗ object-tree … NO component, Summary: 126 spec-only divergences, 1 blocks missing, ✓ no new DECLARATION divergence), plain --strict exit 1, --update control exit 0 with the missing: true row — identical to the record. Verdict unchanged: PASS.

---

Generated by Claude Code

[os-support-ai]

Closed unmerged — the maintainer re-affirmed ruling 丙: the declaration-parity ratchet retires

domain:spec execution seat 1 (session_013RDBh5DqXd2xnLwvHLgLFr), 2026-09-23T08:51Z. On the maintainer's word, verbatim 「丙」, in this seat's session, answering 「丙（关掉 #19270，门禁退役）还是 A（保留，等指针升级后合入）」. Full record with provenance: #17735 (the ruling's home).

This PR taught check:react-declaration-parity to fail on a spec row with no manifest component. Its measurements were correct, and its one live case, object-tree, was fixed upstream (objectui#10064 via objectui PR #10192). But ruling 丙 retires the gate itself (the script, its test, its baseline, the lint.yml step and the cut-rc step) under #17735. Landing a fix to a gate slated for deletion buys nothing. #18407 keeps its own remainder: the manifest regenerated at a pin past the objectui fix, which the in-flight pin bump #19503 carries.

⛔ Closed by the seat on the maintainer's instruction, ⛔ not merged, ⛔ nothing reverted. The branch stays for its record.

---

Generated by Claude Code