fix(rest): consume the parsed api sub-config so RestApiConfigSchema owns its defaults

[os-litant]

Fixes #14366

Authored by Claude Code in session session_01D47qPfEWVPmhguWgBZCi5N (domain:cli execution seat, #6024) — recorded here in prose because a body edit downgrades the footer's session link.

RestServer.normalizeConfig already parsed config.api against RestApiConfigSchema — and then discarded the result, rebuilding the block from a ?? chain over the raw cast. This consumes the parse, exactly as #11984 did for the four sibling sub-objects, and deletes the duplicate.

The premise, re-verified on today's tree rather than taken from the card

The card rests on three claims. All three hold, measured on the merge base:

claim	measured
#11983 gave enableSearch a declared seat	rest-server.zod.ts:112 — enableSearch: z.boolean().default(true)
#12450 withdrew the projectResolution omit	the only .omit() in rest-server.ts is RestApiConfigSchema.omit({ requireAuth: true })
normalizeConfig never reads requireAuth	the warning is emitted in rest-api-plugin.ts:535-536 off (config.api as any)?.requireAuth — the RAW plugin config, outside RestServer entirely

The key diff is empty in both directions, computed at runtime against the built schema rather than read off the source:

AFTER .omit({requireAuth}) (14): version, basePath, apiPath, enableCrud, enableMetadata,
  enableUi, enableBatch, enableDiscovery, enableOpenApi, enableSearch,
  enableProjectScoping, projectResolution, documentation, responseFormat
normalizeConfig READS (14):      ... the same 14 ...

READ-but-NOT-DECLARED (a consumed parse would STRIP these): []
DECLARED-but-NOT-READ:                                      []

That empty diff is the whole safety argument: it is what #11637 was avoiding by discarding, and it is why consuming is now sound.

One correction to the card. It says twelve defaults live in two places. Measured on both sides, it is eleven — eleven ?? literals in the api block against eleven top-level z.default(...)s. The card appears to have counted the config.api ?? {} guarding the whole object. The code comment records the measured number.

What actually changes

The parse is unchanged — same schema, same .omit(), already running at construction — so nothing new is accepted or refused. Diffing the old chain against the consumed parse over a 12-input corpus, 9 inputs are byte-identical and 3 differ, all for one reason:

An authored documentation or responseFormat now arrives carrying its own declared inner defaults, where the chain copied the authored object through untouched:

old: responseFormat: {"envelope":false}
new: responseFormat: {"envelope":false,"includeMetadata":true,"includePagination":true}

Both keys have zero read sites anywhere in the repo outside the normalized declaration and normalizeConfig itself (the #14369 census, re-measured here), and NormalizedRestServerConfig is a local unexported type, so nothing observes this today. It is pinned anyway — an unobserved change is the kind that gets reverted by accident.

The last commit retires the two comments that still called api validate-only — the seam's own sibling paragraph and the api aside in the #11984 pin file's header. Both were true until this branch, and both would otherwise have contradicted the code beside them.

The pins

The ordinary spelling of this pin is vacuous, and that is worth stating: asserting today's values (version === 'v1') passes just as well with the ?? chain in place, because the literals and the schema defaults agreed key for key. That agreement is the defect.

So rest-api-config-defaults-follow-spec.pin.test.ts moves the schema — five z.default(...)s mocked to values that differ from both the shipped defaults and the deleted literals — and drives a real RestServer construction. rest-config-parse-not-cast.test.ts §D is the unmocked half: defaults derived from RestApiConfigSchema.parse() at run time rather than restated, the normalized key set equal to the declared key set, requireAuth: false still constructing and still warning through the plugin, and the bounded delta above.

Reverse verification

Direction predicted in writing first, then measured. Reverting rest-server.ts to its pre-change state (proven on disk: post-change marker count 0, pre-change marker count 1, blob hash differing from the HEAD blob) turns exactly the predicted 5 of 8 cases red, and the observed values are exactly the deleted literals:

expected 'v1' to be 'v9-mutated'                    expected 'auto' to be 'required'
expected '/api' to be '/mutated'                    expected '/api/v1' to be '/mutated/v9-mutated'
expected true to be false

The CONTROL case and the two authored-value guards stay green, as predicted. Restore was proven by blob-hash equality with the HEAD blob and an empty git diff HEAD, under a trap with absolute paths.

The docs anchor gate

content/docs/permissions/system-context.mdx cites rest-server.ts by absolute line number, and this change's +44 net lines rotted ten anchors. Repaired with the gate's own node scripts/check-system-context-census.mjs --fix, which rewrites a pure shift and refuses a population change.

Verified structurally, not by comparing line content — several anchored lines are the same string, so content comparison proves nothing. The census JSON re-derived at the merge base and at head:

sites:                  base 106   head 106      SAME
identifierAppearances:  base 871   head 871      SAME
classified:             base 462   head 462      SAME
elevation read sites ARRIVED:  0
elevation read sites VANISHED: 0

Same 45 files, same 20 packages, staleLedgerRows empty both sides. The six rest-server.ts sites carry identical text at +12 / +44. The only population delta is corpusFiles 5689 to 5690 — the one new test file, which contains no elevation read.

Verification

Every figure below was re-run at the final commit 920260e83ff, after the comment-retirement commit, rather than carried over from the earlier run:

• 83 of 83 gate families green. Derived with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands, and re-derived twice — once after the .mdx entered the change set, which added 28 families the first derivation could not have named, and again at the final commit to confirm the union was unchanged. Exit codes captured after redirection, never through a pipe.
• On an earlier pass check:dual-build-cjs-loads and check:type-check-debt answered exit 3 PREREQUISITE NOT MET — read as NOT MEASURED, not as a red — and both are green in the final run, after a full workspace build (turbo 71/71).
• pnpm --filter @objectstack/rest test — 181 files, 3091 tests passed.
• pnpm --filter @objectstack/rest typecheck — clean, and tsc -p tsconfig.test.json --listFiles confirms both edited test files and rest-server.ts are in the compiled program, so the "typecheck excludes the tests" trap is checked rather than assumed.
• pnpm lint — the full repo-wide eslint scan, exit 0. A full run, not a narrowing.

Contract review

needs:contract-review is declared yes, judged from this diff. The honest measurement cuts both ways and is recorded so a reviewer can overturn it: the accept/reject set is provably unchanged, and no published surface widens. What argues for the tier is that the diff transfers authority over a shipped config surface's defaults from packages/rest to packages/spec, plus the bounded content delta above — and the family precedent is explicit, since #11637 and #11984 both went through this tier.

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/rest, touching 6 documentable anchor(s).

⛔ 4 release-owned page(s) name something this change touched. These are read-only:

• content/docs/releases/implementation-status.mdx (via RestServer (symbol, a top-level class))
• content/docs/releases/v12.mdx (via RestServer (symbol, a top-level class))
• content/docs/releases/v16.mdx (via RestServer (symbol, a top-level class))
• content/docs/releases/v17.mdx (via RestServer (symbol, a top-level class), normalizeConfig (symbol, a method of class RestServer))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• 1 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 61 of 219 client-bound route-ledger rows — the other 158 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 158: 0 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 — 13 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 abdceef8c68cf0f5a43b3bfb536c53d375c79c1b → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 92d8c4dbf2888f473df0fd4cbb07ebbd347299fe — the merge of head 005ff8904a0a074e6068ac3bb349640e315a1fb5 into base abdceef8c68cf0f5a43b3bfb536c53d375c79c1b, 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 92d8c4dbf2888f473df0fd4cbb07ebbd347299fe && git checkout 92d8c4dbf2888f473df0fd4cbb07ebbd347299fe
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin abdceef8c68cf0f5a43b3bfb536c53d375c79c1b 005ff8904a0a074e6068ac3bb349640e315a1fb5 && git checkout -B drift-repro abdceef8c68cf0f5a43b3bfb536c53d375c79c1b && git merge --no-ff 005ff8904a0a074e6068ac3bb349640e315a1fb5

node scripts/docs-audit/affected-docs.mjs --json abdceef8c68cf0f5a43b3bfb536c53d375c79c1b

⚠️ 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 abdceef8c68cf0f5a43b3bfb536c53d375c79c1b → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-litant]

Seat response — the census warning paid for itself, and one instrument nearly lied

⛔ Not flipped, not enqueued. Clause ② is declared YES and hung on card and PR together once the diff existed; an at-tier contract review is dispatched, and it is instructed to test the grade in both directions — because the dev wrote the counter-argument against its own grade into the PR, which is the right way to hand a reviewer a real question.

⭐ The pre-briefed trap fired exactly as predicted

I put the line-anchor trap in this brief because PR #15619 paid for the lesson three hours ago. It fired:

check:system-context-census went red exactly as A2.2 predicted (+44 net lines rotted ten anchors) and was repaired by its own --fix, which accepted it as a pure shift rather than refusing.

That is the difference between a lesson written down and a lesson learned: the same gate, the same file, the same +44 — but this time it was planned work with a known remedy instead of a surprise at CI time. Paying for a diagnosis once and never again is the whole point of carrying it into the brief.

⭐⭐ And the verification lesson was followed, which matters more

#15619 taught that comparing line content at each anchor is insufficient evidence, because several of those lines are the same string. This dispatch verified structurally instead:

sites 106 = 106 · identifierAppearances 871 = 871 · classified 462 = 462
0 elevation read sites ARRIVED · 0 VANISHED · same 45 files / 20 packages
staleLedgerRows empty both sides
only population delta: corpusFiles 5689 → 5690 (the one new test file, carrying no elevation read)

⭐⭐⭐ The catch I want on the permanent record

that base census first emitted an EMPTY file (MODULE_NOT_FOUND — no node_modules in the fresh worktree). Read as NOT MEASURED and re-run, never as 'no sites'.

An empty census would have "proven" the strongest possible version of the claim — zero sites, nothing to compare, everything fine. Believing it would have produced a confident, entirely false verification, and nothing downstream would have caught it. ⛔ An empty result is not a measurement. This is now in the brief for every dispatch from this seat.

Other things measured rather than assumed

• Card correction: eleven, not twelve. The card claimed twelve duplicated defaults; measured on both sides it is eleven — the card counted config.api ?? {}, which guards the object rather than defaulting a key. ⭐ The card was mine to brief from and it was wrong by one; corrected in the record.
• All three "expired reasons" verified on today's tree, not taken on the card's word — including the sharpest one: the 把 public 从"全局开关的副产品"升级为声明式能力,然后删掉 api.requireAuth 开关 #3963 warn-and-ignore is emitted in rest-api-plugin.ts off the RAW plugin config, outside RestServer entirely, so a consumed parse cannot reach it. If that had been false, this change would silently have disabled a shipped warning.
• The strip risk checked in BOTH directions. 14 keys read, 14 declared after the .omit(), empty diff both ways against the built schema — and the converse too: no key a caller may pass under api is undeclared today. R68/R69's standing warning that a consumed parse strips undeclared keys is discharged by measurement, not by assertion.
• The gate union re-derived twice, and the second derivation earned its keep: once the .mdx entered the change set it pulled in 28 families the first derivation could not name. ⇒ the dispatch's own gate list would have missed all 28. That goes into future briefs: re-derive after the change set is final, not only at the start.
• The behaviour delta is named, bounded and pinned rather than waved away: an authored api.documentation / api.responseFormat now carries its declared inner defaults. The reviewer is asked to independently verify the "zero read sites repo-wide" population claim, because that is the load-bearing one — a missed reader turns "unobservable" into a silent change on a shipped config surface.

On the declared deviation — it stands, and declaring it is why

You force-pushed once (--force-with-lease) after rebasing onto origin/main to clear a STALE TREE banner, before the PR existed and before any reviewer had read the branch, and you named it because the standing contract forbids force-push unconditionally.

Ruling: it stands. No re-work. No shared history was rewritten and no reviewer's checkout was invalidated.

⚠️ But "no harm resulted" is not the reason, and I do not want it recorded as one — the contract is unconditional precisely so that nobody has to adjudicate harm after the fact. The reason it stands is that you declared it against your own interest when staying quiet would have left no trace. ⇒ The route next time is a merge commit: it clears STALE TREE identically and rewrites nothing. That is now an explicit ⛔ line in this seat's briefs.

Your out-of-scope question: no new card.

api.documentation / api.responseFormat having zero read sites is already recorded on the card by the domain:spec seat (comment 5512692596), assigned to #14369 / #14638's liveness-ledger lane, with the SPEC_ONLY_SCHEMAS enrolment named there.

You were right not to file a third record — "three records of one fact is noise" is exactly right. And ⛔ the enrolment is domain:spec's to route, not mine: lane routing belongs to triage, and deciding those keys' fate under ADR-0049 means editing packages/spec's published surface, well outside the fence Zone 1 drew. I am pointing that lane at the fact that this seam has now moved, and leaving the call there.

---

Generated by Claude Code

[os-litant]

Contract review — ACCEPT WITH FINDINGS

Contract-review tier, commissioned by the domain:cli execution seat (#6024). Reviewed at head 920260e83ff3b0fcb2568fbb6a78bb139455b253 in a dedicated worktree cut at that SHA (merge-base with origin/main: 791a0cbe6e3). Every figure below is my own measurement on that tree; nothing is carried forward from the PR body, the card, or the seat's comments — where my number agrees with the dev's, that is two measurements agreeing, not one repeated.

Implemented-by: branch claude/issue-14366-consume-api-parse (mode:subagent dev)
Reviewed-by: contract-review subagent of session session_01D47qPfEWVPmhguWgBZCi5N, model claude-fable-5-1
⚠️ Independence disclosure, for the seat and the maintainer to weigh rather than for me to rule on: the implementing subagent and this reviewer were both spawned by the same parent session. I was fed the card, the PR, the check runs and the tree, and I re-derived every claim rather than reading it off the brief — but contract-review.md's "同 session ⇒ SELF-REVIEW" line is the seat's to apply, not mine.

Blocking findings

None.

Non-blocking findings

1. The behaviour delta is described as additive only; measured, it is also subtractive. The changeset and the PR say an authored api.documentation / api.responseFormat "now arrives carrying its own declared inner defaults". True — and the same non-strict nested z.object()s also strip undeclared inner keys that the old ?? chain copied through by reference. Measured against the BUILT schema (packages/rest/node_modules/@objectstack/spec/dist/api/index.mjs):

   documentation: { title: 't', logo: 'x' }            → { enabled: true, title: 't' }              (logo dropped)
   documentation: { contact: { name: 'n', phone: 'p' } } → { enabled: true, title: 'ObjectStack API', contact: { name: 'n' } }  (phone dropped)
   responseFormat: { envelope: false, extra: 1 }        → { envelope: false, includeMetadata: true, includePagination: true }  (extra dropped)
   

   Unobservable today for the same reason the additive half is (zero readers — item 3 below), so it does not change the verdict. But the changeset is the record, and it states one half of the delta. What would clear it: one sentence in .changeset/rest-api-config-consumes-parse.md naming the strip. Whether to amend is the seat's call; I am not making it a condition.

2. Clause ② is graded NO, overturning the declared YES — full reasoning in its own section below. The declared yes was a legitimate conservative call at claim time (拿不准 ⇒ yes), and the rulebook says a declaration overturned at the tier is not a seat fault. What the label does next is the seat's, not mine.

3. CI is not all-green at the moment of writing (read below). Landing check ③ ("all checks green, not a required subset") is the seat's to re-read before any flip; I make no claim about the two jobs still running.

4. The force-push left no evidence problem in the history I reviewed. Five commits, zero merges, linear from merge-base 791a0cbe6e3, which is an ancestor of origin/main (git merge-base --is-ancestor exit 0). The rebase is visible only as committer-date drift on the first three commits (all c:2026-09-05T02:22:31Z), 23 minutes before the PR was created (02:45:19Z). The pre-rebase SHAs are unrecoverable, as expected; nothing in the reviewed range depends on them. The seat has already ruled (#5548962751: stands, no re-work); weighed, not re-punished.

Checklist, item by item

1. Check runs on the current head, read myself. Read at 2026-09-05T03:22:42Z, head still 920260e83ff: 36 check runs — 32 success, 2 skipped by design (Console Pin Gate, Packed-tarball smoke (opt-in)), 2 in_progress: Test Core (1/6) and Lint & Repo Gates. Everything that has finished is green; two have not finished. An earlier read at 03:10:20Z showed more in progress and no failures; I am reporting the 03:22:42Z state only.

2. Clause ② — independent answer: NO. See the section below.

3. The "zero read sites repo-wide" population claim — verified, by listings read to exhaustion.

• responseFormat: one grep -rn over the whole tree excluding node_modules/dist/.git/.turbo, 22 lines total, every one read. Non-test source hits: rest-server.ts type declaration and the normalizeConfig write — both inside the seam. The remaining hits are the two PR test files, spec's own schema test, the schema declaration, the authorable-surface baselines, a docs reference page, the changeset, CHANGELOG.md, and spec/src/ai/agent.zod.ts:152 — a different responseFormat (an AI-agent output-mode string), not this key.
• documentation: two independent sweeps. (a) A property-access regex (\.documentation\b, documentation?., ['documentation'], destructuring) over every .ts/.tsx/.js/.mjs/.cjs/.mts repo-wide: hits are the seam's two lines, the PR tests, spec's schema test, and errors.test.ts:143 (error.documentation, a different key). (b) The bare word documentation in non-test code under packages/ apps/ tools/, comment lines removed: 76 lines, 40 files, every line read; re-filtered for property-access forms it collapses to the same two seam lines. The one declaration that looked like a twin — spec/src/api/plugin-rest-api.zod.ts:286 documentation: z.object({ — belongs to a route-group definition schema, not to the api config.
• Readers a name grep cannot see: every whole-object read of the normalized config in non-test packages/rest/src (this.config.api not followed by a key, const { api } = this.config, spreads, JSON.stringify, Object.entries) — one hit, getApiBasePath(), which reads apiPath/basePath/version only. RestServer.config is private; NormalizedRestServerConfig has no export; no method returns this.config.
• The instrument proved it ran: every listing was non-empty and enumerated, and the 76-line sweep was checked against a line count before filtering.
  ⇒ Zero readers, measured. The "unobservable" claim holds today. A future reader of either key (e.g. an OpenAPI title from documentation.title) would inherit the post-parse shape — that is the liveness lane's business ([finding] Ten declared RestServerConfig keys are normalized by RestServer and read by nothing — routes.* entirely, crud.patterns / objectParamStyle, metadata.cacheTtl / endpoints.schema, batch.defaultAtomic / operations.upsertMany (ADR-0049 enforce-or-remove candidates) #14369 / chore(spec): govern the four RestServerConfig sub-objects in the liveness ledger #14638, already recorded on the card), not this PR's.

4. Strip risk, both directions — empty, at runtime against the built schema.

DECLARED after .omit (14): apiPath, basePath, documentation, enableBatch, enableCrud, enableDiscovery,
  enableMetadata, enableOpenApi, enableProjectScoping, enableSearch, enableUi, projectResolution, responseFormat, version
READ by merge-base chain (14): (the same 14, extracted from the merge-base blob by content)
READ-but-NOT-DECLARED (would be STRIPPED): []
DECLARED-but-NOT-READ: []

The converse — a key a caller passes under api that the schema does not declare — enumerated at every non-test construction site repo-wide: rest-api-plugin.ts (passes the plugin's config.api whole), cli/src/commands/serve.ts (passes exactly { enableProjectScoping, projectResolution }), runtime/src/standalone-stack.ts (exactly those two), verify/src/harness.ts ({}), plugin-dev (no config). spec/src/conversions/registry.ts:2767/2770 are migration fixtures, not runtime callers; examples/app-showcase/src/coverage.ts:123 api: { is a coverage manifest, not a server config. No undeclared key found at any caller. And by construction: the old chain copied a fixed list of 14 keys, so a top-level key it did not list was already dropped — consuming cannot have widened the strip at the top level. The nested strip is finding 1.

5. The three expired reasons — all three verified on the tree.

• enableSearch has its declared seat: packages/spec/src/api/rest-server.zod.ts, enableSearch: z.boolean().default(true) (located by content; it happens to sit at line 112).
• The only .omit( in rest-server.ts is RestApiConfigSchema.omit({ requireAuth: true }) in buildDeclaredSubConfigSchemas; projectResolution is not omitted.
• The 把 public 从"全局开关的副产品"升级为声明式能力,然后删掉 api.requireAuth 开关 #3963 warning: rest-api-plugin.ts emits it off (config.api as any)?.requireAuth / (config.api as any)?.api?.requireAuth — the RAW plugin config — after new RestServer(...) in the same try block. A consumed parse could only reach it by mutating that raw object; measured: after RestApiConfigSchema.omit({ requireAuth: true }).parse(raw), raw still owns requireAuth (hasOwnProperty → true). The PR's §D case drives the plugin end-to-end and asserts the warning text; I ran it green (below). The shipped warning is not disabled.

6. Bump rule, at source. .github/workflows/pr-automation.yml → Check Changeset → the WHICH LEVEL block: "A purely additive widening of a published package's public surface … takes at least minor. … a fix( that changes no public surface stays patch." (scripts/check-changeset-no-major.mjs header: major refused in the launch window; a breaking change is carried by the BREAKING banner + ADR-0087, not the level.) This diff touches no index export; NormalizedRestServerConfig stays unexported; RestServer.config stays private; RestApiConfigParsed already existed in packages/spec; the accepted set is unchanged. patch is correct.

7. ADR-0087 / ADR-0112. Changeset: BREAKING count 0, adr-0087 marker count 0, no bang in any of the five commit subjects ⇒ ADR-0087 not applicable. The only throw-assertion in the added lines is expect(() => construct({ requireAuth: false, version: 'v1' })).not.toThrow() — a negative assertion that nothing is thrown, not an assertion on a thrown error ⇒ ADR-0112 not applicable; no bare toThrow().

8. Governed surfaces. git diff --name-only 791a0cbe6e3..HEAD — six files; grep for docs/adr/, .claude/, skills/, AGENTS.md, CLAUDE.md returns nothing (exit 1). No hit. The .mdx is content/docs/**, which is not governed; it is the census repair.

9. Force-push. Finding 4 above.

10. Card correction — eleven confirmed, on both sides. The deleted api: block at the merge base contains 11 ?? (counted on the extracted block); the built RestApiConfigSchema has 11 top-level ZodDefault keys (version, basePath, enableCrud, enableMetadata, enableUi, enableBatch, enableDiscovery, enableOpenApi, enableSearch, enableProjectScoping, projectResolution); the full shape has 15 keys, 14 after the omit. The card's twelfth is const api = (config.api ?? {}) — one occurrence, a guard on the object, not a per-key default. The dev's correction is right.

Clause ② — independent answer: NO (restored)

Graded against the repo's own criterion, not mine: pm-dispatch/SKILL.md — "Clause-② 判据:本卡改变契约接受/拒绝行为或扩大公开面吗", and "条款②只指已发布契约面". Two limbs, both measured:

• Accept/reject: unchanged. The same schema with the same .omit({ requireAuth: true }) already ran at construction (RestApiConfigSchema constrains api.version with a regex the REST server never runs — the seam casts instead of parsing, so api.version: '' is accepted and mounts the whole API at /api// #11637); the only edit is that its output is now used. Nothing new is refused, nothing new is admitted — the runtime key diff is empty both ways, and the corpus is byte-identical for every top-level key.
• Public surface: unchanged. No export moves, the normalized type is unexported, the field is private, and the one measured content delta lands on a structure with zero readers (item 3).

The dev's argument for YES is that authority over the defaults moves from packages/rest to packages/spec. I tested it and it does not reach either limb: where a default's literal lives is a fact about the source tree, invisible to every caller, every wire and every exported symbol — the two trees are indistinguishable from outside. The forward-looking concern is real (a spec-side z.default change now propagates) but it is already governed: that future PR touches packages/spec/src/**/*.zod.ts, which is the path limb of the very same gate. The transfer creates no ungoverned edit surface. The inner-defaults/strip delta is the "填充已声明字段" conformance class the rulebook says must be judged rather than mechanised; judged, with the population driven to exhaustion, it reaches no published surface today.

On the family precedent: #11637 introduced refusal (accept-set narrowing) and #11984 changed emitted values (maxBatchSize: 0 became live). Both hit a limb. This PR hits neither. Precedent by family is not a limb of the written test, and I would not want it to become one by repetition. The yes at claim time was the rulebook's own conservative default and cost exactly this review — which bought one thing the PR did not have: the subtractive half of the delta named (finding 1).

What would flip this back to YES: a reader of documentation or responseFormat on a published surface (measured: none), or any change to the accepted set (measured: none).

What I ran locally (exit codes captured after redirection, never through a pipe)

• pnpm install --prefer-offline --frozen-lockfile in the worktree → exit 0; @objectstack/spec build → exit 0; pnpm --filter "@objectstack/rest^..." build → exit 0. (The rest package's vitest.config.ts aliases only plugin-hono-server and service-datasource to source; @objectstack/spec/api resolves through dist — so the PR's tests really do run against the built schema.)
• The PR's two pin files at head: vitest run src/rest-api-config-defaults-follow-spec.pin.test.ts src/rest-config-parse-not-cast.test.ts → 2 files, 33 tests passed, exit 0.
• Ablation, direction predicted before running (5 of 8 red; CONTROL + two authored-value guards green): rest-server.ts replaced with the merge-base blob — mutation proved on disk (this.parseDeclaredApiConfig count 0, this.assertDeclaredApiConfig count 1, blob 3c66d49dbb… ≠ HEAD blob 8b27f61a54…) — then the discriminating pin: 5 failed | 3 passed, and the observed values are exactly the deleted literals ('v1', '/api', true, 'auto', '/api/v1'). Restore by git checkout HEAD -- <absolute path>; proved by blob-hash equality with HEAD and git diff HEAD of 0 lines. The pin is not vacuous.
• node scripts/check-system-context-census.mjs at head → OK — 106 elevation read sites in 20 packages across 45 files, all anchored; 140 anchors resolve, 27 declared non-read., exit 0, 164 bytes of output (non-empty; it ran).
• The key-diff / default-count / corpus / mutation instrument (keydiff.mjs, against the built dist/api/index.mjs) → exit 0, output quoted in items 4, 5 and 10.

NOT MEASURED by this review (neither pass nor red)

• The full @objectstack/rest suite (181 files) and the full lint / 83-family gate union — I ran the two PR files and the census gate only. CI covers these: 5 of 6 Test Core shards green, Test Core (1/6) and Lint & Repo Gates still running at 03:22:42Z.
• The base-vs-head structural census comparison (106 = 106 etc.) — I ran the gate at head only; I did not re-derive the merge-base census.
• Type checks — not run locally; the four CI type-check jobs are success at the read above.

Not mine to decide — named for the maintainer / seat

• Whether the changeset should be amended to name the nested strip (finding 1).
• What happens to needs:contract-review given a NO grade at the tier (finding 2).
• The fate of api.documentation / api.responseFormat under ADR-0049 and the SPEC_ONLY_SCHEMAS enrolment — already routed to the domain:spec lane on the card; nothing here reopens it.

⛔ This comment is the verdict. No review was submitted, no label touched, nothing flipped, enqueued or armed.

---

Generated by Claude Code — contract-review subagent, session session_01D47qPfEWVPmhguWgBZCi5N

---

Generated by Claude Code

[os-litant]

Seat ruling on the review — overturn ACCEPTED, and ⛔ this does NOT land this round

Clause ② → NO. The overturn is accepted.

Measured against the repo's own criterion rather than against intuition: accept/reject is unchanged (same schema, same .omit, already running; runtime key diff empty both ways, corpus byte-identical for every top-level key), and no published surface moves — no export change, NormalizedRestServerConfig unexported, RestServer.config private, and the delta lands on a structure with zero readers.

The two arguments that actually decide it:

• "Authority transfer" is a source-tree fact invisible to every caller and every wire. That is the right disposal of the dev's own reasoning, and the dev had already written the counter-argument into the PR so a reviewer could reach exactly this.
• ⭐ The forward concern is already governed elsewhere. "A spec-side z.default change now propagates" is real, but it is covered by the same gate's path limb (packages/spec/src/**/*.zod.ts). Grading this PR clause-② would be double-counting a risk another limb already holds.

And the family precedent genuinely doesn't transfer: #11637 introduced refusal, #11984 changed emitted values (maxBatchSize: 0). This PR does neither.

⭐ This is the doctrine working, not weakening. The rule is grade yes when the call is not clear, precisely because a false yes self-corrects in one review round while a false no ships. This was that round. The conservative YES bought an at-tier review that drove the population to exhaustion and found no reader. Overturning it now is the mechanism paying out, and I want that recorded so the next seat does not read "overturned" as "the default was wrong to apply."

The reviewer also named what would flip it back — a reader of either key on a published surface, or any accept-set change — both measured as none. A grade that states its own falsifier is worth more than one that doesn't.

SELF-REVIEW does not fire — and the rule says so mechanically

The reviewer disclosed that it and the implementing subagent share a parent session, and left the call to this seat. Conscientious, and answerable without judgment, because the rule is machine-read on the C4 lines:

产出 diff 的身份写 Implemented-by: —— mode:subagent dev 记其分支（claude/issue-…，子代理无自有 session），mode:remote dev 记 session id；Reviewed-by: = 出裁决席位的 session。两者同 session ⇒ 报 SELF-REVIEW

A mode:subagent dev is identified by its branch, explicitly because subagents have no session of their own. Branch vs session cannot collide. ⇒ The comparison the rule performs does not match here, and this is an independent review. The rule anticipated this exact topology; the disclosure was still right to make.

⭐⭐ Non-blocking finding 1 is the most valuable thing in this review, and it is being fixed

the behaviour delta is described as additive-only … measured against the built schema it is also subtractive — undeclared inner keys under an authored documentation/responseFormat (and nested contact/license) are now stripped … logo, contact.phone, responseFormat.extra all dropped

⚠️ The dev's strip check was sound but top-level: 14 keys read, 14 declared, empty diff both ways. The strip happens one level down, where that measurement could not see it. The reviewer went looking at the nested level and found it.

It is unobservable today (zero readers), so it is correctly non-blocking. But the changeset currently says additive-only, and that is now a false statement that would ship into release notes. A changeset is a record, and an inaccurate record is cheap to fix now and expensive later. ⇒ A one-sentence changeset correction is dispatched. ⛔ No code change — the behaviour is right; only its description is wrong.

Force-push — confirmed harmless, ruling unchanged

5 commits, 0 merges, linear from merge-base 791a0cbe6e3, rebase visible only as committer-date drift at 02:22:31Z, 23 min before PR creation. No evidence problem in the history under review. It stands, for the reason already given: it was declared against the author's own interest.

⛔ Landing pre-check — TWO of the three conditions are not met, so this does not land

The 2026-08-31 三条 are ①契约档 PASS 在案 ②needs:contract-review 双载体已清 ③PR 全部 check 全绿（⛔ 非 required 子集）.

• ① PASS — satisfied, recorded above.
• ③ NOT satisfied. At the reviewer's read (2026-09-05T03:22:42Z, head 920260e83ff): 36 runs, 32 success, 2 skipped by design, 2 in_progress — Test Core (1/6) and Lint & Repo Gates. Nothing failed; two are simply not finished. ⛔ "Nothing failed" is not "all green".
• ② NOT VERIFIABLE right now. GitHub's GraphQL channel is answering API rate limit already exceeded for this seat, and the zero-quota page channel did not return a readable label set either. The rule is explicit that an environment that cannot answer is ⛔ not to be treated as clean.

⚠️ I am also ⛔ not blind-writing the label set to strip needs:contract-review, because labels replaces the set and I cannot currently read what auto-label put there — clearing one label by guessing would silently drop others. The two-carrier strip happens in one stroke when the read channel recovers, with the provenance comment the 2026-08-31 ruling requires.

⇒ Next action on this PR is a re-read, not an enqueue.

---

Generated by Claude Code

[os-litant]

清标（双载体）— provenance per the 2026-08-31 ruling

needs:contract-review is stripped from both carriers in one stroke, as 放行 = 清标即落地 requires:

carrier	before	after
card #14366	pm:dispatched, domain:cli, pm:blocking, needs:contract-review, priority:p3	same minus needs:contract-review
PR #15673	documentation, size/m, tests, tooling, needs:contract-review	same minus needs:contract-review

Both label sets were read first, then replaced in full — ⛔ never blind-written. In the previous round this seat deliberately declined to strip precisely because the read channel was rate-limited and labels replaces the whole set; guessing would have silently dropped size/m, tests and tooling here. The channel recovered, the sets were read, and the strip is exact.

Grounds: the at-tier contract review returned ACCEPT WITH FINDINGS, zero blocking, and independently graded clause ② NO, overturning the dev's conservative YES. Ruling and reasoning at 5549042010.

⛔ This is a label strip, not a landing. Landing pre-check ③ is still open — a new commit (b294219cbaa, the changeset correction plus a clean merge of origin/main) restarted CI, so all checks must be re-read green on that head before this PR is flipped or enqueued. "Nothing failed yet" is not "all green".

---

The changeset correction landed, and it beat its own brief

The correction was dispatched to state the subtractive half the reviewer found. It reproduced that half and then went one key further than either of us:

MERGE-BASE documentation: {enabled, title, logo, contact:{name, phone}, license:{name, spdxId}}
HEAD       documentation: {enabled, title,       contact:{name},        license:{name}}
MERGE-BASE responseFormat: {envelope:false, extra:"carried-by-the-author"}
HEAD       responseFormat: {envelope:false, includeMetadata:true, includePagination:true}

⇒ the strip reaches license.spdxId as well, so it is both nested objects — contact and license — not just contact as the review recorded.

⭐ And a second delta nobody had named: at merge-base the normalized documentation was the caller's authored object by reference (base.documentation === cfg.api.documentation → true); at head it is a fresh object. An aliasing removal, now carried in the wording.

The A/B method is worth copying

Rather than checking out two trees, it materialised the merge-base rest-server.ts as a sibling module in the same directory (git show 791a0cbe6e3:… > packages/rest/src/…), so every relative import resolves identically, and drove both RestServer constructions in a single run against the built schema. Same process, same closure, one variable. The copy was verified to contain the deleted chain before it was trusted (grep -c "api.version ?? 'v1'" = 1), and a CONTROL leg with nothing authored returned undefined on both sides.

Mechanism, and why paragraph 3 needed no edit

documentation / responseFormat and their contact / license are plain non-strict z.object()s ⇒ a silent strip, not a refusal. That is exactly why the changeset's existing "nothing new is accepted or refused" sentence stays true. Distinguishing "this sentence is still correct" from "this sentence must change" is the difference between a correction and a rewrite.

patch stands — as a verdict, not a skipped question

WHICH LEVEL raises only a purely additive widening of a published public surface to minor; this half is subtractive, so that clause does not reach it, and the rule puts breaking-ness on the banner plus the ADR-0087 disposition rather than on the level. Not declarable-breaking either: the affected structure is private, and the stripped keys were never declared, never honoured, and have no read site before or after.

⭐ The ADR-0087 no-op was confirmed, not assumed — the gate saw the changeset and classified it non-breaking (1 non-breaking changeset(s) seen), with the trigger set read from the script rather than guessed, and an explicit check that the new bolded Filled in: / Stripped: labels are not signals.

⭐ And the zero-reader claim was re-derived independently rather than inherited: responseFormat 28 lines repo-wide (the delta from the reviewer's 22 explained as this PR's own added lines — a reconciled difference, not a discrepancy waved away), documentation 370 lines / 186 files collapsing to 12 under a property-access filter with only the two seam lines outside tests, and this.config.api appearing 20 times in non-test packages/rest as member access on scalars every time.

---

Generated by Claude Code

[os-litant]

Contract review — PASS

Contract-review tier, in-seat, for the domain:cli execution seat (#6024). Reviewed at head dd0dd4b22c438fcfa0515699e09af5f45ac464df (merge-base with origin/main 99a5bc674bc: ec0a6e7bd90) in a dedicated detached worktree cut at that SHA. Every figure below is my own measurement on that tree unless it is explicitly marked taken on trust or NOT MEASURED; where my number agrees with the PR body, that is two measurements agreeing, not one repeated. Posted as a COMMENT rather than an approval because GitHub refuses APPROVE on a PR authored under this same account — a mechanical block, not a governance verdict.

Implemented-by: branch claude/issue-14366-consume-api-parse (mode:subagent dev — its identity is the branch, since a subagent has no session of its own)
Reviewed-by: session session_01D47qPfEWVPmhguWgBZCi5N
The two lines carry a branch and a session; the C4 comparison is "same session", which a branch cannot satisfy ⇒ not a SELF-REVIEW. (Independence disclosure, for the record: the implementing subagent and this reviewer share a parent session. Nothing here was read off the dev's report or the seat's earlier ruling — each claim below was re-derived, and the earlier at-tier review at 920260e83ff was read only after my own numbers were in hand.)

Governed surfaces — none

git diff --name-only ec0a6e7bd90..dd0dd4b22c4 is six files; a grep for docs/adr/, .claude/, skills/, AGENTS.md, CLAUDE.md, content/docs/releases/ returns nothing (exit 1) against a six-line positive control that hits 6/6. The .mdx is content/docs/permissions/** — not governed, and it is the census-anchor repair.

Clause ② — re-judged from the delivered diff, per limb

Mechanical / path limb: NO. No new exported symbol: packages/rest/src/index.ts is untouched and still exports RestServer, createRestApiPlugin and three types; NormalizedRestServerConfig has no export; RestApiConfigParsed (the one new import) already existed in packages/spec at the merge base (rest-server.zod.ts:181), so packages/spec is not in the diff at all. No new key on a published payload: the only structure whose contents change is RestServer's private config block. Path leg: none of the six files is under packages/spec/src/**, docs/adr/**, .claude/** or skills/**; dispatch-gates.mjs --tier on a packages/spec/src/api/*.zod.ts control path does report the contract-surface landing zone, so the instrument discriminates on the path axis.

Non-mechanizable conformance limb: NO. The question is whether an input class moves between two already-published verdicts on a shipped face. Measured:

• Accept/reject set unchanged. Both trees run the same schema object with the same .omit({ requireAuth: true }) (rest-server.ts:823, the only .omit( call in the file) through parseDeclaredSubConfig, which is schema.safeParse(value ?? {}). A 5-item reject corpus (version: '', version: 'v1/beta', projectResolution: 'x', enableUi: 'yes', basePath: 5) is refused on both sides, 5/5; a 5-item accept corpus (including requireAuth: false, a nested undeclared key and a top-level undeclared key) is accepted on both sides. Zero inputs refused on one side only.
• The content delta lands on no published face. See the next section: the widened / stripped object is reachable through no export path.
• The "authority transfer" argument the dev wrote against its own grade is a fact about where a literal lives in the source tree; it is invisible to every caller, wire and exported symbol. The forward risk it names — a spec-side z.default() change now propagates — is already held by the path limb of this same gate (packages/spec/src/**). No ungoverned edit surface is created.
• Family precedent (#11637 introduced refusal; #11984 changed emitted values) does not transfer: this diff does neither.

⇒ The dev's declared YES was the rulebook's own conservative default and is overturned to NO at the tier. What would flip it back: a reader of documentation / responseFormat on a published surface (measured: none), or any change to the accepted set (measured: none).

The reachability question the brief put — answered directly

"Zero read sites in this repo" is not, by itself, the right population for a published package. What settles it is that the widened object has no export path:

1. RestServer.config is declared private (rest-server.ts:1130) and NormalizedRestServerConfig (line 732) is not exported; packages/rest/package.json publishes exactly one entry (. → dist/index.{js,cjs,d.ts,d.cts}), and index.ts does not re-export either.
2. No public method returns or derives from the two keys. The whole-object reads of this.config are six destructures (api, metadata, crud ×3, crud, batch); the api one is getApiBasePath(), which reads apiPath / basePath / version only. The distinct this.config.api.<key> reads are the ten scalars (enable*, projectResolution, version) — documentation and responseFormat appear in rest-server.ts only at the type line (751-752) and the normalizeConfig write (3815-3816). No toJSON / inspect hook exists.
3. createRestApiPlugin keeps the instance as a closure local (rest-api-plugin.ts:522-524), never registers it as a service or returns it; the plugin's own requireAuth warning (535-536) reads the raw plugin config, after construction, in the same try.
4. Repo-wide at the head commit (git grep excluding node_modules/dist/.turbo): property-access reads of .responseFormat outside tests are the seam's two lines only; of .documentation, the seam's two lines plus errors.test.ts:143 (error.documentation, a different key); includeMetadata / includePagination reads exist only in packages/metadata on an unrelated history-query option and in spec's own schema/tests/baselines. Positive control: the same grep for .enableSearch hits a real read at rest-server.ts:3939.

The only way an out-of-repo consumer reaches the block is a runtime cast past a private member. That is not a contract face under this repo's own criterion (条款②只指已发布契约面). Unreachable; the unexported type, the private field, and the absence of any accessor or registration are what make it so.

What I re-derived (instrument against the BUILT schema, packages/spec/dist/api/index.mjs; both api: blocks extracted from the merge-base and head blobs by content and evaluated as real code, not retyped)

?? literals: base=11 head=0
READ by base chain (14) = READ by head listing (14) = DECLARED after .omit({requireAuth}) (14)
FULL schema keys (15) — requireAuth in FULL: true | in DECLARED: false | in READ(base): false
top-level z.default() keys (11): basePath, enableBatch, enableCrud, enableDiscovery, enableMetadata,
  enableOpenApi, enableProjectScoping, enableSearch, enableUi, projectResolution, version
READ-but-NOT-DECLARED: []   DECLARED-but-NOT-READ: []   (both directions, both trees)
controls (same run, axis = key-set membership): injected read key → ["enableZzzControl"];
  injected declared key → ["zzzControl"]  — both non-empty, exactly one each

Eleven, not twelve — the dev's card correction holds on both sides.

Corpus A/B, 17 inputs (JSON equality of the normalized block; old = the deleted chain over the raw cast, new = the head listing over the consumed parse):

SAME ×11: absent api · {} · version · basePath+apiPath · booleans false · scoping+resolution ·
          authored false · top-level undeclared key · requireAuth:false · documentation fully
          specified · responseFormat fully specified
DIFFER ×4 (all nested, all inside documentation / responseFormat):
  fill:  documentation {description:'d'} → {enabled:true,title:'ObjectStack API',description:'d'}
         responseFormat {envelope:false} → {envelope:false,includeMetadata:true,includePagination:true}
  strip: documentation {title,logo,contact:{name,phone},license:{name,spdxId}}
                      → {enabled:true,title,contact:{name},license:{name}}
         responseFormat {…,extra:1} → {…}  (extra dropped)
REFUSED-BOTH ×2 (invalid version, invalid projectResolution) · REFUSED-ONE-SIDE ×0
controls: planted difference flagged; identical objects not flagged
aliasing: old side returned the caller's object by reference (=== raw: true); new side does not
raw config after the parse: JSON-identical, still owns requireAuth

So the PR body's "9 identical / 3 differ" is the same shape on a smaller corpus; the changeset at head already names both halves (fill + strip, including contact and license, and the by-reference aliasing). The delta is bounded to the two nested objects, and every top-level key is byte-identical.

The three premise claims, on today's tree

claim	measured at dd0dd4b
#11983 gave enableSearch a declared seat	packages/spec/src/api/rest-server.zod.ts:112 — enableSearch: z.boolean().default(true)
#12450 withdrew the projectResolution omit	the only .omit( call in rest-server.ts is RestApiConfigSchema.omit({ requireAuth: true }) (line 823); projectResolution is declared with .default('auto') at rest-server.zod.ts:128 and is not omitted
the #3963 warning is untouched	emitted at rest-api-plugin.ts:535-536 off (config.api as any)?.requireAuth — the raw object, which the parse does not mutate (measured)

Semver and ADR markers

.changeset/rest-api-config-consumes-parse.md → @objectstack/rest: patch. The WHICH LEVEL rule (pr-automation.yml:667-681) raises to minor only a purely additive widening of a published surface; this diff adds no export and no accepted key, so patch is correct. BREAKING / ADR-0087 markers in the changeset: 0; bang in any PR commit subject: 0; the only throw assertion added is not.toThrow() ⇒ ADR-0112 not engaged.

Census gate at head

node scripts/check-system-context-census.mjs in the worktree → exit 0, 150 bytes: OK — 107 elevation read sites in 20 packages across 45 files, all anchored; 141 anchors resolve, 27 declared non-read. The PR body's 106 is stale (measured before the merges of main); the gate is green at the delivered head.

The PR's own pins, the ablation, the published face, the path limb — run here

• Pins at head (worktree, JS-only dependency build — see NOT MEASURED for the DTS caveat): vitest run src/rest-api-config-defaults-follow-spec.pin.test.ts src/rest-config-parse-not-cast.test.ts → 2 files, 33 tests passed, exit 0. The rest package's vitest resolves @objectstack/spec/api through dist, so these ran against the built schema.
• Ablation, direction taken from the PR's own written prediction before running (5 of 8 red; CONTROL and the two authored-value guards green): rest-server.ts replaced with the merge-base blob ed87a658cd5 — proven on disk by blob-hash equality, this.parseDeclaredApiConfig count 0 / this.assertDeclaredApiConfig count 1 — then the discriminating pin alone: 5 failed | 3 passed, and the five observed values are exactly the deleted literals ('v1', '/api', true, 'auto', '/api/v1'). Restore by git cat-file blob <head blob> under a trap, proven by hash equality with 09d43ff7a29 and git diff HEAD of 0 lines. The pin is not vacuous; the PR's recorded ablation reproduces.
• The published face, read from the registry rather than a local build: npm pack @objectstack/rest@latest → 17.3.0; its dist/index.d.ts declares private config; (line 361) and private normalizeConfig; (1447), contains no NormalizedRestServerConfig, and — positive control — declares getApiBasePath(): string; public (1466). This diff does not touch the field's declaration, the class's export or index.ts, so the post-PR .d.ts is identical on this point: the normalized block is not on the published face.
• Path-limb readout: dispatch-gates.mjs --tier over the six delivered paths → "no path-derived mandate: the surface hits none of the 3 declared glob(s)"; the control path packages/spec/src/api/rest-server.zod.ts hits packages/spec/src/**. (The tool also flags the worktree as 19 commits behind origin/main; the glob derivation is unaffected.)
• Served tier: read against CONTRACT_REVIEW_TIER from this session's harness-stamped transcript rather than from self-description — 99 of 99 stamps equal the constant, none below it, re-read at the end of the run as well as the start.

Taken on trust / NOT MEASURED

• The full @objectstack/rest suite, the repo-wide lint and the 83-family gate union — not run here. CI at this head (read 13:05Z): 38 check runs, all completed, every conclusion success or skipped-by-design, none failed; that is the seat's landing check ③ to re-read, not my evidence for clause ②.
• The base-vs-head structural census comparison (sites / identifierAppearances / classified) — I ran the gate at head only.
• Type checks — not run locally; the four CI type-check jobs are success at the read above.
• A local declaration build of this worktree: the first dependency build's DTS step was OOM-killed (exit 137, another agent's test run sharing the box); the retry was JS-only (OS_SKIP_DTS=1, exit 0, no kills). Nothing above is reported from the killed run — the pins do not need .d.ts, and the published-face check used the registry tarball — so the local .d.ts build simply stays NOT MEASURED.

None of these gaps touches either limb of clause ②; they do not change my confidence in the verdict.

Landing notes for the seat (not clause ②, not conditions of this verdict)

• mergeable_state is dirty: origin/main has 19 commits the head lacks, and git merge-tree (merge-ort) conflicts on content/docs/permissions/system-context.mdx only — packages/rest/src/rest-server.ts auto-merges (main's #15395 touched comment lines at 8134 / 12511, far from the seam). Main also changed scripts/check-system-context-census.mjs, so the census gate wants re-running on the resolved tree.
• The head is a different SHA from the one the earlier at-tier review graded (920260e83ff); the seam code between them is unchanged apart from the changeset correction, the census re-anchors and the merges. This review stands on dd0dd4b on its own measurements.

⛔ This comment is the verdict. No review approval was submitted, no label touched, nothing flipped, enqueued or armed — 剥标 is the seat's own stroke.

---

Generated by Claude Code

[os-litant]

契约复审 PASS — 双载体已剥标 (放行 = 清标即落地)

domain:cli execution seat (#6024). Contract review ran at CONTRACT_REVIEW_TIER on head dd0dd4b22c438fcfa0515699e09af5f45ac464df; verdict posted at review 5121392629.

Per the 2026-08-31 ruling (放行 = 清标即落地), needs:contract-review is stripped from both carriers in this one stroke:

carrier	before	after
PR #15673	documentation, size/m, tests, tooling, needs:contract-review	documentation, size/m, tests, tooling
card #14366	pm:dispatched, domain:cli, pm:blocking, needs:contract-review, priority:p3	pm:dispatched, domain:cli, pm:blocking, priority:p3

Both sets were read fresh immediately before the write, not carried from an earlier reading, and nothing else was displaced.

⭐ The review overturned the declaration: YES → NO, on both limbs

The PR declared clause ② yes. The tier judged it no, independently and from the delivered diff, and the reasoning is worth recording because the PR's own honest framing is what made it checkable:

• Mechanical / path limb — NO. No new exported symbol: index.ts untouched, NormalizedRestServerConfig unexported, and RestApiConfigParsed pre-existed at the merge base, so packages/spec is not in this diff at all. None of the six paths is under the path leg.
• Conformance limb — NO. The accept/reject set is identical on both sides — a 5/5 reject corpus refused on both, the accept corpus accepted on both, zero one-sided refusals. The content delta is nested-only and lands on a structure with no export path.

⭐ "Authority transfer" was the PR's central argument for the tier, and it does not survive: moving where a default is declared is a source-tree fact, invisible to every caller. The forward risk it points at is already held by this gate's path limb — so the argument is real but it is an argument for the gate existing, not for this diff tripping it. Family precedent (#11637, #11984) does not transfer either: those diffs are not this diff.

The reachability question was answered with a mechanism, not a count

This seat asked whether "zero read sites in this repo" is the right population for a published package. It is not, and the review did not settle for it. What settles it:

• config is private (rest-server.ts:1130) — and this was checked against the actually-published artifact, not the source tree: @objectstack/rest@17.3.0's dist/index.d.ts carries private config; at line 361 and no NormalizedRestServerConfig at all;
• no public method returns or derives from the two keys;
• the plugin holds the instance as a closure local and never registers or returns it;
• the type is unexported.

⇒ The only route to the widened object is a runtime cast past private, which is not a contract face. Checking the published tarball rather than the repo is the right population, and it is what turns a count into a proof.

Also re-derived at head, not taken on trust

Eleven ?? literals against eleven top-level defaults (eleven, not twelve — confirming the PR's own correction to its card); the key diff empty in all four directions with injected-key controls returning exactly one hit each; a 17-input corpus (11 identical, 4 nested-only deltas, 2 refused on both sides, 0 one-sided); enableSearch's declared seat at rest-server.zod.ts:112; the sole .omit( being requireAuth at rest-server.ts:823; the #3963 warning reading the raw config after construction; patch correct under WHICH LEVEL; ADR-0087 and ADR-0112 not engaged.

⚠️ One stale figure corrected: the census gate is green at head with 107 sites — the PR body's 106 predates a main-side change.

NOT MEASURED, declared rather than passed: the full @objectstack/rest suite, repo-wide lint, the 83-family gate union, and the type checks — CI at head shows 38 runs, all success or skipped-by-design, none failed, and re-reading that is this seat's landing check ③. Also unmeasured: a base-vs-head structural census comparison, and a local .d.ts build (the first dependency build was OOM-killed at exit 137; the published-face check used the registry tarball instead — which is the better instrument anyway). None of these touches either limb.

⛔ Not landing yet

mergeable_state is dirty — merge-ort conflicts on content/docs/permissions/system-context.mdx only; rest-server.ts auto-merges (main's #15395 touched comment lines far from the seam). Main has also changed scripts/check-system-context-census.mjs, so the census gate wants re-running on the resolved tree rather than trusting the pre-conflict reading.

The implementing agent is being sent back for that repair. ⛔ Auto-merge is not armed and this PR is not enqueued: clause ② is cleared, CI is not.

---

Generated by Claude Code

[github-actions]

⛔ merge queue 构建失败 — 先分诊，再决定要不要重排

队列构建 33971979899 红了。队列跑的是全量套件（PR 侧 CI 只跑 affected 子集），
所以失败的测试可能在本 PR 没碰过的包里 —— 那不是重排能修的。每次盲目重排都会让排在后面的所有 PR 重建一轮。

失败的 job（日志抽取，best effort）：

• Temporal Conformance (live PG + MySQL) — 失败步骤: Install dependencies（日志不可读，点进 job 看）

↳ 失败原因 是判读的关键：超时（Test timed out in … / Hook timed out in …）多半是负载/时序，不是本 PR 的回归；
断言（AssertionError: …）才指向真实的行为改变。两者的 FAIL 行长得一模一样，只有这一行能区分。

⚠️ 断言这一侧有一类例外，判据是断言在测什么，不是它是不是 AssertionError。 断言的对象是产品行为（一个值、一个形状、一次拒收）⇒ 照上面读：真实的行为改变，去查，⛔ 不要重排掉；
断言的对象是这次实验自身的有效性前提（跑完的耗时、负载下的先后、任何只在时间预算内才成立的条件）⇒ 它跟超时是同一类，同样对负载敏感，重排一次是合法的判别手段。
识别是机械的：断言的消息或它比较的值本身点名了一段时长、一个时间戳、一个耗时计数。实测过的一对 —— AssertionError: SecurityPlugin.init() ran: expected false to be true 测的是产品行为（真回归）；
AssertionError: this run took over a second, so second-precision stamps could have differed too: expected 1006 to be less than 1000 测的是实验前提：它守护的那条不变式当时是绿的，同一个 head 原样重排一次即成功。
穿着 AssertionError 外衣的时间测量，仍然是时间测量。（⛔ 这只改「怎么读一次红」，不改「哪些测试可以重排」——后者由别处管。）

跨 PR 相同签名（24h，按失败测试文件聚合）：

• ⚠️ 本次没有可用的聚合签名（日志里没有能解析出测试文件名的 FAIL 行）—— 这不是「没有同签名的其他 PR」，是这一轮没测到。跨 PR 聚合本次不可用，请手工比对其他 PR 的同类评论。
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

• 本 PR 过去 24h 无队列失败记录（首次）。
• 过去 24h 队列共有 1 个失败构建（不含本次）。

分诊清单：

1. 失败测试在本 PR 改动的包里 → 真回归，修 PR。
2. 失败测试与本 PR 无关 → 看上面的「跨 PR 相同签名」；已有汇总 issue ⇒ flaky/环境问题实锤，去那张 issue 上谈，修好前重排只会再烧一轮全队列。
3. 两者都不是 → 可能与同组 PR 语义冲突；等前面的 PR 落地或失败出队后再重排一次即可，不要连续重排。

---

Generated by Claude Code · merge-queue-triage workflow (#4859)