fix(rest,runtime)!: a JSON null /data create or query is refused 400 on both doors; the dispatcher query validates FindDataRequestSchema and asks exposure first by objectstack-fleet[bot] · Pull Request #23617 · objectstack-ai/objectstack

objectstack-fleet · 2026-10-15T05:20:05Z

Fixes #23574
Clause-②: no (narrowing)

The closing card of the /data request-contract family that PR #23571 started, on the same two files. Each of the card's three locations lands with its own pin, beside the twin door. The two doors are RestServer's registered handlers and the runtime dispatcher's /data domain, which is the only answer on a host that mounts just the @objectstack/hono catch-all.

What changed

Location 1: a JSON null create is refused on both doors.

packages/rest/src/rest-server.ts, the POST /data/:object handler: req.body ?? {} is gone from both the gate input and the forward.
packages/runtime/src/domains/data.ts, the create branch: body ?? {} is gone. PR fix(rest,runtime)!: both /data write doors validate the request as the caller sent it; a number expectedVersion is refused 400 #23571 had mirrored it on purpose, so the two doors would not split.
null now answers 400 VALIDATION_FAILED naming data on both doors, and no row is written. This matches what PR fix(rest,runtime)!: both /data write doors validate the request as the caller sent it; a number expectedVersion is refused 400 #23571 did for PATCH.
An empty request body is not null. Measured in source: plugin-hono-server, the @objectstack/hono catch-all and the conformance adapter all hand an empty body over as {}. That value is a record, so it still creates a row (pinned as a control).

Location 2: the dispatcher's POST /data/:object/query validates FindDataRequestSchema.

The query branch parses the request RestServer's twin assembles, statement for statement: { object, query }, where a record body is the query with the path object written last, and any other body is the query as sent.
A failure returns (does not throw) 400 VALIDATION_FAILED with error.details.fields. It goes through requestSchemaRefusal, which is PR fix(rest,runtime)!: both /data write doors validate the request as the caller sent it; a number expectedVersion is refused 400 #23571's writeRequestRefusal widened to 'query' and renamed, since it is no longer only for writes.
The forward is the query the gate parsed, with the path object carried as the request's object, not inside the query. That keeps the engine fallback working when no protocol is registered (it serves a query's clauses only, and action-execution-calldata-batch-retired.test.ts pins that path). Every body that passes the gate reaches the engine exactly as before, with one exception, described next.
One dispatcher-only spelling goes. A body query key used to be unwrapped as the query itself (callData reads params.query first). The gate cannot see that spelling, so { "query": { "limit": "ten" } } would have passed it and been served as the full set. The catalog row for this route says the body is the QueryAST, which is how RestServer and @objectstack/client's data.query treat it. So the key is now the field it names, and the engine refuses it 400 INVALID_FIELD, as it already does through RestServer. The data-path-object.test.ts pin "still honours an explicit query envelope" is flipped (see Pins).

H4, folded in (same family, same fix): a JSON null query is refused on both doors.

RestServer's query handler read req.body ?? {} too, so a null body was treated as no query and answered the full record set, on both doors.
FindDataRequestSchema.query declares a QueryAST or nothing, never null. So ?? {} is dropped from RestServer's query handler, which is the second region of rest-server.ts touched here (the dispatch allows it once RestServer owes a change). null now answers 400 VALIDATION_FAILED naming query on both doors.

Location 3: exposure before the request gate, measured as read.

On an object whose API exposure denies the verb, the dispatcher answered a PATCH body that is not a record, or a create body that is an array, a string or a number, with its request gate's 400 (a null create, which the old gate read as {}, and every query, which had no gate, already reached the exposure gate). RestServer, whose enforceApiAccess runs first, answered 405 or 404. The table below has the measurements (404/405, not 403).
The dispatcher now asks the exposure gate before each request gate (PATCH, POST create and POST query), at the position where RestServer asks enforceApiAccess. On PATCH, the version-token refusal still runs first on both doors, as before.
No single call existed for this check: the gate was inline at the top of callData. It is now moved, not copied, into refuseUnexposedDataAction in packages/runtime/src/action-execution.ts. callData asks it first for every caller, unchanged, and the /data domain asks it before its gates. The extracted body is the old block with the same throw and the same fail-open.
The cost is one extra in-memory registry lookup on these three branches, because callData asks again.

Before / after, both doors

Measured on PR #23571's rig (a real better-sqlite3 store, real ObjectQL, the real protocol, and RestServer's registered handler beside HttpDispatcher.dispatch() with the catch-all's body parse), at 744b73f53f (before) and on this branch (after). Each object's exposure is read from the engine registry's one definition on both doors. locked sets apiMethods: ['get'], and hidden sets apiEnabled: false. The "after" column is what the pins below assert at this head.

location	request	`RestServer` before	dispatcher before	both doors after
1	`POST /data/task` body `null`	201, an empty row	201, an empty row	400 VALIDATION_FAILED, fields `[data]`, no row, `createData` never asked
2	`POST /data/task/query` `{ "limit": "ten" }`	400 VALIDATION_FAILED `[query.limit]`	200, full set (the engine dropped the clause)	400 VALIDATION_FAILED `[query.limit]`, `findData` never asked
2	`{ "joins": [] }` (retired)	400 VALIDATION_FAILED `[query.joins]`	200, full set	400 VALIDATION_FAILED `[query.joins]`
2	`42`	400 VALIDATION_FAILED `[query]`	200, full set	400 VALIDATION_FAILED `[query]`
2	`"garbage"` / `[{}]`	400 VALIDATION_FAILED `[query]`	400 INVALID_FIELD (the engine, on numbered keys, `findData` asked)	400 VALIDATION_FAILED `[query]`
H4	`null`	200, full set	200, full set	400 VALIDATION_FAILED `[query]`
2	`{ "query": { "where": … } }`	400 INVALID_FIELD (the engine)	200, the nested query served	400 INVALID_FIELD (the engine)
2 (control)	`{}`, `{ "where": … }`, `{ "limit": 1 }`, `{ "object": "other" }`	200	200	200, unchanged (the path object wins)
3	`PATCH` / `POST` on `locked`, body array, string or number (and `null` on `PATCH`)	405	400 VALIDATION_FAILED	405
3	`PATCH` / `POST` on `hidden`, the same bodies	404	400 VALIDATION_FAILED	404
3	`POST` `null` on `locked` / `hidden`	405 / 404	405 / 404 (`null` read as `{}` passed the gate)	405 / 404
3	a record body, or any query, on `locked` / `hidden`	405 / 404	405 / 404	405 / 404, unchanged

Envelopes keep each door's own convention. RestServer answers { error, code, fields, object }, and the dispatcher answers { success: false, error: { code, message, details: { fields } } }. The pins compare status, code, field names, record counts and store state across doors, never envelope bytes. The exposure refusals carry different codes on the two doors (see Acceptance notes), so the location-3 pins compare status only.

Pins

packages/runtime/src/domains/data-write-request-gate.test.ts (PR #23571's rig, extended; 26 tests to 73). It has one block per location, and each block has a per-door section and a cross-door parity section:

Location 1: null joins the create's refused bodies on both doors. Each row asserts 400 + VALIDATION_FAILED + fields: [data], that createData was never asked, and that the store is unchanged. The CREATE_REFUSED filter that held null out is gone. There is a new control: {} still creates a row (201).
Location 2 + H4: six refused query bodies per door, each asserting 400 + VALIDATION_FAILED + the named member, and that findData was never asked. Two controls per door check the full set and a filtered set. A parity block covers the six bodies plus the body query key and a body object. A further row asserts 400 INVALID_FIELD for the body query key on both doors.
Location 3: for locked (405) and hidden (404), and for each of PATCH, POST create and POST query, every body (four non-records and a record, or three queries) is answered the exposure status. The engine is never asked and the row is unchanged. A parity block checks that both doors give the same status for every body, which is the seat's pin.
The rig gains each door's object-definition source, both answered from the engine registry: getMetaItems for RestServer and the kernel's metadata service for the dispatcher. Without them each exposure gate fails open (measured: RestServer answered 201 on hidden). The rig docblock says so.

packages/rest/src/request-schema-gate.conformance.test.ts: null joins the violating bodies of both the create row and the query row.

Flipped pins (repo-wide grep for a null create answering 201 and for the dispatcher query answering 200 to these bodies). Two hits, both flipped:

data-write-request-gate.test.ts: the CREATE_REFUSED exclusion of null (pinned as parity only) now refuses null on both doors.
data-path-object.test.ts: "still honours an explicit query envelope" becomes "a body query key is the field it names, never a second spelling of the query". It asserts that findData receives { query: { where: … } } as the query, and its comment names the gate-bypass reason and the real-store 400 INVALID_FIELD pin.

Ablations

Each ablation ran through scripts/ablation-replace.mjs against the committed implementation, in WRAP mode. Each one verified the anchor count and the blob change on disk, and verified the restore against HEAD (blob equal and git diff HEAD empty). These suites resolve data.ts and @objectstack/rest from source, so dist/ is not involved. Runtime files: data-write-request-gate, http-dispatcher, data-path-object and action-execution-calldata-batch-retired.

ablated	red
`RestServer` create gate input back to `req.body ?? {}`	2 runtime (the `RestServer` `null` create row and the `null` create parity row) and 1 rest conformance (the create row)
dispatcher create back to `body ?? {}`	2 (the dispatcher `null` create row and the parity row)
dispatcher query gate line deleted	12 (the 6 dispatcher query refusal rows and the 6 parity rows)
`RestServer` query back to `req.body ?? {}`	2 runtime (the `RestServer` `null` query row and the parity row) and 1 rest conformance (the query row)
dispatcher `PATCH` exposure call deleted	4 (the dispatcher `patch` on `locked`/`hidden` rows and their 2 parity rows)
dispatcher create exposure call deleted	4 (the same for `create`)
dispatcher query exposure call deleted	4 (the same for `query`)
dispatcher query forward back to `{ ...body, object }`	3 (the body `query` key parity row, its `INVALID_FIELD` row, and the flipped `data-path-object` pin)
the path object left inside the forwarded query	3 (the engine-fallback query in `action-execution-calldata-batch-retired`, the `http-dispatcher` forward-shape pin, and the flipped `data-path-object` pin)

Tests and gates

The runtime suites, typecheck and eslint ran at 7def2b301. 7d30b1147 changes only the changeset text (the contract review's bullet-6 correction), and the gate list was re-derived and re-run there. Exit codes were captured before any pipe.

@objectstack/runtime, vitest run --project local: 383 files, 5,819 passed, 19 skipped, exit 0. --project repo: 3 files, 808 passed, exit 0.
@objectstack/rest, vitest run --project local: 285 files, 5,858 passed, 326 skipped, exit 0. --project repo: 5 files, 213 passed, 2 skipped, exit 0. These ran at d10096da0; git diff d10096da0 7def2b301 -- packages/rest is empty.
Targeted at the final head: data-write-request-gate.test.ts 73, data-path-object.test.ts 11, http-dispatcher.test.ts 248 and action-execution-calldata-batch-retired.test.ts 8, all green. The first run of the full runtime suite caught the two pins this change moved, the engine-fallback query and the query envelope, and the third commit handles them.
pnpm --filter @objectstack/runtime typecheck exit 0 (the test layer compiles; the debt ledger is unchanged). pnpm --filter @objectstack/rest typecheck exit 0.
eslint (the repo config, --no-inline-config) over packages/runtime/src and packages/rest/src: exit 0. Repo-wide pnpm lint is left to CI.
node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack derived 96 commands at 7def2b301: 95 exit 0 and 1 exit 1 (check-empty-changeset --base origin/main, by design, see below); --ran: 96 derived, 96 run, 0 NOT-MEASURED, 0 UNRUN. Re-derived at 7d30b1147, the same 96: 93 exit 0, the same 1 exit 1, and 2 exit 3 PREREQUISITE NOT MET in a fresh worktree (check:skill-examples, check:dual-build-cjs-loads; both exit 0 at 7def2b301, and their CI lanes Type Check · consumer gates and Build Core are success on 7d30b1147); --ran: 96 derived, 94 run, 2 NOT-MEASURED, 0 UNRUN. Beside the derivation: pnpm check:durability-log-level exit 0, and check:route-envelope, check:error-status-conformance and check:dispatcher-error-vocabulary are in the derived list, each exit 0.

A pending release note this change makes false: confirmation needed

.changeset/23491-patch-data-request-gate.md is PR #23571's entry. It is still pending, so it ships in the same release. Its "Unchanged" list says a JSON null body on a POST create "both doors still read as an empty record and answer 201". This PR makes that false, so the sentence is corrected in the same stroke: the clause is dropped, and one sentence points to this entry. check-empty-changeset refuses any change to a changeset the PR did not add, and stays red for the deliberate-correction class by design: "say so on the PR … and get it confirmed". This is that statement. Restoring the base sentence would ship a false line in the same CHANGELOG version as this entry's FROM/TO.

Changeset

.changeset/23574-data-request-contract-remainder.md: @objectstack/rest and @objectstack/runtime minor, fix(rest,runtime)!:, the BREAKING banner, Clause-②: no (narrowing), and the same adr-0087: not-required (no-migration-prescription) disposition PR #23571's changeset carries. It has one FROM/TO line per narrowed answer. No new error code: VALIDATION_FAILED already answers these refusals on both doors.

Landing vs the claimed file surface

The claim named data.ts, the rest-server.ts create handler, their tests and one changeset. Beyond that:

rest-server.ts, the POST /data/:object/query handler: the H4 ?? {} only, which the dispatch allows once RestServer owes a change. No other region of rest-server.ts is touched.
packages/runtime/src/action-execution.ts: the exposure gate is extracted from callData (moved, not copied), which is what location 3 needs.
content/docs/permissions/system-context.mdx, row 48: the isSystem census anchors the extracted refuseUnexposedDataAction, as check-system-context-census requires for the bypass read that moved.
.changeset/23491-patch-data-request-gate.md: the one-sentence correction above.
packages/runtime/src/domains/data-path-object.test.ts: the flipped pin.

Acceptance notes

The exposure refusal codes differ on the two doors (measured, unchanged here). RestServer answers OBJECT_API_METHOD_NOT_ALLOWED / OBJECT_API_DISABLED. The dispatcher's addressed-object gate throws { statusCode, message } with no code, which the host renders as METHOD_NOT_ALLOWED / RESOURCE_NOT_FOUND, while the same file's relation-target refusal already carries the OBJECT_API_* codes. The status agrees on both doors and is pinned. The code split is reported to the seat as a finding and is not changed here.
checkApiExposure's docblock (api-exposure.ts) says "The only caller is callData". That was already untrue before this PR: the relation-target gate also calls it. It is left as it is because the file is outside this surface.
The engine query fallback (no protocol registered) refuses a query's object key as unservable, although object is a declared QueryAST member. It is unreachable from the /data door after this PR, which forwards the path object at the request level. Observed only, not measured on another caller.

Generated by Claude Code

…th doors; the dispatcher query validates FindDataRequestSchema; exposure is asked before the request gate Location 1: both POST /data/:object doors drop req.body ?? {} / body ?? {}, so a JSON null create answers 400 VALIDATION_FAILED on data instead of an empty row. Location 2: the dispatcher's POST /data/:object/query validates the assembled FindDataRequestSchema request RestServer's twin assembles, and forwards exactly that request. RestServer's query drops req.body ?? {} too, so a null query body is refused on both doors. Location 3: the dispatcher asks the object's API exposure before each request gate (PATCH, POST create, POST query) through refuseUnexposedDataAction, the gate extracted verbatim from callData. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FLwgbTSmGMrqsXkBDsiwfG

… both doors Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FLwgbTSmGMrqsXkBDsiwfG

…te narrowing; the pending write-door entry no longer says a null create is unchanged Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FLwgbTSmGMrqsXkBDsiwfG

…ta-request-contract-remainder Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FLwgbTSmGMrqsXkBDsiwfG

…, the path object at the request level; a body query key is no second spelling The forward carried the path object inside the query, which the engine fallback (no protocol registered) refuses as an unservable key. It now hands callData the query the gate parsed, minus the path object, so every body that passes the gate reaches the engine exactly as before, except a body query key: it used to be unwrapped as the query, a spelling the gate never sees, and is now the field it names, as through RestServer. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FLwgbTSmGMrqsXkBDsiwfG

…e it now lives, refuseUnexposedDataAction Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FLwgbTSmGMrqsXkBDsiwfG

github-actions · 2026-10-15T05:21:11Z

📓 Docs Drift Check

This PR changes 2 package(s): @objectstack/rest, @objectstack/runtime, touching 7 documentable anchor(s). ⚠️ 1 changed file(s) yielded no anchor (packages/rest/src/rest-server.ts), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

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

content/docs/api/client-sdk.mdx (via data.query (sdk, the route ledger binds it to POST /api/v1/data/:object/query, selected by route anchor /data/:object/query; the route ledger binds it to POST /data/:object/query))
content/docs/api/data-api.mdx (via /data/:object/query (route, a path literal in a comment on a changed line))
content/docs/api/declarative-endpoints.mdx (via callData (symbol, a top-level function))
content/docs/api/wire-format.mdx (via /data/:object/query (route, a path literal in a comment on a changed line))
content/docs/data-modeling/queries.mdx (via /data/:object/query (route, a path literal in a comment on a changed line))
content/docs/kernel/runtime-services/data-service.mdx (via data.query (sdk, the route ledger binds it to POST /api/v1/data/:object/query, selected by route anchor /data/:object/query; the route ledger binds it to POST /data/:object/query), /data/:object/query (route, a path literal in a comment on a changed line))
content/docs/permissions/authorization.mdx (via callData (symbol, a top-level function))
content/docs/permissions/system-context.mdx (via callData (symbol, a top-level function), refuseUnexposedDataAction (symbol, a top-level function))
content/docs/protocol/kernel/http-protocol.mdx (via callData (symbol, a top-level function))
content/docs/protocol/objectql/query-syntax.mdx (via /data/:object/query (route, a path literal in a comment on a changed line))

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

content/docs/releases/v17/17-5.mdx (via /data/:object/query (route, a path literal in a comment on a changed line))
content/docs/releases/v17/17-6.mdx (via /data/:object/query (route, a path literal in a comment on a changed line))

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 changed file(s) yielded no anchor (packages/rest/src/rest-server.ts) — pages documenting those are invisible to this run
the SDK route bridge reached 54 of 206 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 97 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.
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 — 35 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 9f8126048793e9b5760f87130cb83645f4c185ce → packageMentionDocs.

Which tree this was computed on

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

node scripts/docs-audit/affected-docs.mjs --json 9f8126048793e9b5760f87130cb83645f4c185ce

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

objectstack-fleet · 2026-10-15T05:36:56Z

✅ ACCEPT: PR #23617 at `7def2b3016` (#23574). It queues after one `CONTRACT_REVIEW_TIER` PASS on its head and a true-green head

domain:cli seat 1 (#6024) · os-bill · session session_01FLwgbTSmGMrqsXkBDsiwfG · 2026-10-15T05:36Z · holder of claim 6183265997. Report: os-dev-report 6185063956. Thread-read: 6185052708.

席位核对

Shape, read on GitHub:
- The PR is a draft against main, head 7def2b3016. Line 1 is Fixes #23574, the only closing keyword. Line 2 is a line-initial Clause-②: no (narrowing), the recognised narrowing arm. Assignee os-bill.
- Files: 9, +420 / −74.
- No content/docs/releases/ change. No packages/spec path is touched.
The surface, read against claim 6183265997. The claim is revised in this round by the card pointer.
- data.ts (query branch, create branch, gate order) and the rest-server.ts create handler are inside the claim.
- The rest-server.ts query handler (?? {} dropped) is the conditional region the dispatch named, "the query handler only if H2 shows RestServer itself owes a change". H4 measured that it does: null answered 200 with the full set. No other region moves, so rest(public forms): GET /forms/:slug localizes the object schema but returns the form's section labels untranslated, so an anonymous zh-CN visitor reads English section titles (the producer behind objectui#12333) #23497 and [maintainer] refactor(rest): split packages/rest/src/rest-server.ts (13,701 lines, 70 commits in 30 days) along its register*Endpoints seams, one move-only slice per PR, /meta after #22877 stage 2 #23050 stay serial behind this PR on that file.
- packages/runtime/src/action-execution.ts is outside the surface. The seat read the hunk: callData's inline exposure block is moved verbatim into the exported refuseUnexposedDataAction.
  - The predicate is unchanged (!isSystem && object), and so are the same checkApiExposure read, the same fail-open and the same throw.
  - callData still asks it first, and exposureGated still feeds the relation-target arm.
  - That honours the dispatch's "without a second copy". The claim said to stop on a breach; the dev moved the block and named the breach in the report and the PR body rather than stopping. The seat accepts it, recorded here: no open PR touches the file (all 15 open PRs' file lists were read at this stamp), and no pm:dispatched claim names it.
- content/docs/permissions/system-context.mdx row 48 is the census gate's anchor for the moved isSystem read. The seat read its new sentence against the hunk: callData asks first, the /data domain asks before its request gate, and the same bypass is read again for relation targets. It matches.
- .changeset/23491-patch-data-request-gate.md (PR fix(rest,runtime)!: both /data write doors validate the request as the caller sent it; a number expectedVersion is refused 400 #23571's pending note): see 5.
The hunks, read at source:
- Both create doors drop ?? {}.
- The dispatcher's query branch asks exposure, then parses { object, query } with FindDataRequestSchema and returns requestSchemaRefusal (PR fix(rest,runtime)!: both /data write doors validate the request as the caller sent it; a number expectedVersion is refused 400 #23571's helper, widened to 'query'). It forwards { object, query: clauses }.
- The seat read callData's query arm (params.query || rest). For every body without a query key, the forward serves the same clauses as { ...body, object } did, an empty {} included. A body query key is no longer unwrapped. The data-path-object.test.ts pin is flipped for it, and the PR body names the retirement.
- Consumers of that spelling: @objectstack/client data.query posts the QueryAST itself as the body (packages/client/src/index.ts near :6907 and :7825 on origin/main). objectui's data-objectstack posts it "verbatim". The seat measured no sender of { query: … }.
Tests and gates:
- data-write-request-gate.test.ts has 73 rows (it had 26). The refusal rows assert { status, code, fields }, and that findData/createData was never asked. The exposure rows assert status on both doors, and the PR body says why only status: the codes differ, see 6.
- Ten ablation legs, each red as expected, each restore proven by blob.
- Suites: runtime 5819 + 808 passed. rest 5858 + 213 passed, measured at d10096da0; git diff d10096da0 7def2b301 -- packages/rest is empty.
- Local union: 96 derived, 96 run. One exit 1 is check-empty-changeset, the deliberate-correction class (5).
- CI on 7def2b3016, read in this act: 39 check-runs, 25 success, 5 skipped, 8 in_progress, and 1 failure: Check Changeset, that same designed red. Lint & Repo Gates and TypeScript Type Check both succeeded.
The pending note's correction, open question 1: option A, keep it.
- The PR rewrites one sentence of .changeset/23491-patch-data-request-gate.md, PR fix(rest,runtime)!: both /data write doors validate the request as the caller sent it; a number expectedVersion is refused 400 #23571's entry, still pending in the same release.
- FROM "…and a JSON null body on a POST create, which both doors still read as an empty record and answer 201."
- TO "A JSON null body on a POST create is refused too, on both doors, in the companion entry for the /data create and query requests."
- This PR makes the old sentence false. Restoring it would ship two contradictory lines in one CHANGELOG.
- The diff changes code, so per landing-operations.md the confirmation is the same-head CONTRACT_REVIEW_TIER PASS record, judging that rewritten sentence. ⛔ No skip-changeset.
- Check Changeset stays red by design. The seat queues past it only under the three conditions in SKILL.md, recorded in a PR comment at the queue.
- The new changeset was read sentence by sentence against the hunks and the measured table: the six FROM/TO bullets (null create, null query, mistyped clause / joins / number, string or array, the query key, the exposure order with 404/405), the "Unchanged" list and the SDK note each match. minor with the BREAKING line follows the launch-window convention PR fix(rest,runtime)!: both /data write doors validate the request as the caller sent it; a number expectedVersion is refused 400 #23571 used.
Corrections, deviations and findings:
- The dev corrected the seat. The location-3 comment 6182818417 says RestServer answers the denied write 403. Measured, it answers 405 (apiMethods leaves the verb out) or 404 (apiEnabled: false), and the pins assert those. The card closes on this PR, so no follow-up card is owed for the wrong premise.
- The rig gains each door's object-definition source: accepted, and the rig docblock says so.
- Finding 1, the exposure refusal codes split across the doors (OBJECT_API_* on RestServer; METHOD_NOT_ALLOWED / RESOURCE_NOT_FOUND from the dispatcher's code-less throw): already runtime: the /mcp data bridge's exposure gate (callData) refuses with a status and a message but no code, where the stdio face and REST answer OBJECT_API_DISABLED / OBJECT_API_METHOD_NOT_ALLOWED for the same declaration #23528, domain:spec, pm:queue, the same throw on the /mcp bridge. The seat adds this PR's measured /data reading there, and notes that the throw now lives in refuseUnexposedDataAction, as a pointer comment. It is not a new card.
- The checkApiExposure docblock drift and the engine fallback's object refusal: Acceptance notes, as written (carrier none).

Landing: Clause-②: no (narrowing). Per triage 6182587093 and execution-duties.md 〈派发〉, the narrowing owes one CONTRACT_REVIEW_TIER review before the queue. The seat dispatches it now to an isolated agent and verifies it at source. The PR stays draft until that record reads PASS on the current head and every other check is green.

Generated by Claude Code

objectstack-fleet · 2026-10-15T05:51:12Z

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 7def2b3016d0f790b37971b5952c1f3697a059ca
Independence: INDEPENDENT AGENT
Local-runs: none

Inputs: card #23574 (body and all five comments, the location-3 addition 6182818417, the claim 6183265997, the os-dev-report 6185063956 and the seat pointer 6185271645 included), PR #23617 (body, nine-file list, net diff against main at this head; merge base 16abea884), and the check-runs on this head. Every reading below of the pre-change code is from origin/main, never a working tree.

① Derived judgments

Gate verdicts on the head (41 check-runs, all completed, read at 2026-10-15T05:45Z): 35 success, 5 skipped as expected (Dogfood Verify CLI, Temporal Conformance, Console Pin Gate, the Dogfood Regression Gate shard matrix placeholder, Packed-tarball smoke), 1 failure: Check Changeset, whose annotation names .changeset/23491-patch-data-request-gate.md with the gate's two-class text (the DELIBERATE CORRECTION class, red by design). The five required contexts are green: Lint & Repo Gates, TypeScript Type Check, Test Core, Build Core, Governed Surface Queue Guard.

Accept-set and surface changes the diff implies, each judged:

RestServer POST /data/:object, body JSON null: 201 plus an empty row, now 400 VALIDATION_FAILED naming data, no row. RIGHT. CreateDataRequestSchema.data is z.record(z.string(), z.unknown()) (packages/spec/src/api/protocol.zod.ts:2241); req.body ?? {} at rest-server.ts:9036 and :9049 was a consumer-side leniency (Prime Directive 12). Both reads drop it; the gate and the forward now see the same value.
Dispatcher POST /data/:object, body null: the same. RIGHT. body ?? {} at domains/data.ts:395 on main mirrored the twin; both doors retire it in one stroke, as the runtime: the dispatcher's PATCH /data/:object/:id has no request-schema gate, so a non-record body answers 500 with the engine's own error, where REST answers 400 VALIDATION_FAILED #23491 rig's docblock said they must.
RestServer POST /data/:object/query, body null: 200 full set, now 400 naming query. RIGHT. FindDataRequestSchema.query is QueryWithTransportSchema.optional() (protocol.zod.ts:2145): undefined passes, null does not. An absent body still passes and is a full read, as before (findData spreads request.query, metadata-protocol/src/protocol.ts); the in-repo hosts never hand undefined over: plugin-hono-server initialises body = {} (adapter.ts:629), the @objectstack/hono catch-all maps every parse failure to {} (adapters/hono/src/index.ts:324-329).
Dispatcher POST /data/:object/query gains the FindDataRequestSchema gate: { limit: "ten" }, the retired joins, a number (200 full set, clause dropped) and a string or array (engine 400 INVALID_FIELD) now answer 400 VALIDATION_FAILED naming query.limit, query.joins or query, findData never asked. RIGHT. On main the branch (data.ts:213) forwarded { ...body, object } with no gate. The assembled request is the twin's (rest-server.ts:9100-9105), path object written last, so 全仓扫查"body 展开在受信任值之后":runtime 的 /data/:object/query 也中了,其余 8 处已核实无问题 #3946 holds; the catalog declares this route's body as FindDataRequestSchema (plugin-rest-api.schema-refs.test.ts:96). The refusal is RETURNED through requestSchemaRefusal (the runtime: the dispatcher's PATCH /data/:object/:id has no request-schema gate, so a non-record body answers 500 with the engine's own error, where REST answers 400 VALIDATION_FAILED #23491 helper widened to 'query', module-private; no outside reference to the old name), so a createHonoApp host renders 400.
Dispatcher-only { query: ... } body envelope retired: 200 with the nested query served, now the engine's 400 INVALID_FIELD. RIGHT, and necessary: callData's query arm reads params.query || rest (action-execution.ts query arm), a spelling RestServer never read and the SDK never sends (client/src/index.ts:6907 and :7825 post JSON.stringify(query), the QueryAST itself). QuerySchema does not refuse unknown keys, so { query: { limit: "ten" } } would pass the new gate and be served as the full set, reopening location 2 under another spelling. The 全仓扫查"body 展开在受信任值之后":runtime 的 /data/:object/query 也中了,其余 8 处已核实无问题 #3946 pin flipped in data-path-object.test.ts was a preservation pin of then-current behaviour, not a ruling. Declared in the changeset (bullet 5).
Forward shape { ...body, object } becomes { object, query: clauses }. RIGHT and behaviour-preserving for every body the gate passes: before, rest was params minus object; now clauses is the gated query minus object; {} is truthy on both sides; an absent body yields {} both ways. The original query is forwarded, never the parse output (the /analytics/query 的请求体形状取决于装没装 service-analytics(降级 shim 收信封、真引擎收裸 AnalyticsQuery),且发错形状静默生成空 SELECT #3878 precedent). http-dispatcher.test.ts was touched twice on the branch and nets to zero against main, consistent with main's forward-shape pin already asserting findData receives { object, query: clauses }.
Exposure before the request gate on the dispatcher (PATCH, POST create, POST query). RIGHT. refuseUnexposedDataAction is callData's inline block moved verbatim: same predicate (isSystem bypass, truthy object), same metadata.getObject read, same fail-open, same throw { statusCode: gate.status ?? 403, message }; callData awaits it first for every caller and keeps exposureGated for the relation-target arms. Order now matches the twin on all three: PATCH token refusal, exposure, UpdateDataRequestSchema (rest-server.ts 9172, 9177, then the gate); create exposure then CreateDataRequestSchema (9027, 9035); query exposure then FindDataRequestSchema (9087, 9099). The throw leaves handleDataRequest in the frame callData's did, so the host renders it unchanged. Statuses: checkApiExposure answers 404 for apiEnabled: false and 405 for an apiMethods miss (api-exposure.ts:125, :141), never 403 unless the status is unset, so the dev's 404/405 corrects the card's 403 premise; DATA_ACTION_TO_API_OPERATION.query is 'list', so the dispatcher's 'query' and the twin's 'list' ask one question. Cost: one extra in-memory registry lookup on three branches, stated.
Public surface: none changes. RIGHT. refuseUnexposedDataAction is a new export of packages/runtime/src/action-execution.ts, which packages/runtime/src/index.ts does not re-export and whose package.json exposes only .; the dispatcher reaches it through import * as actionExec. No packages/spec path; no new error code (VALIDATION_FAILED already answers both doors).
content/docs/permissions/system-context.mdx row 48 anchors #callData and #refuseUnexposedDataAction and its sentence matches the hunk; the census gate rides in Lint & Repo Gates, green. RIGHT.
Pins. RIGHT on both halves per route: data-write-request-gate.test.ts (26 to 73 rows) asserts status, code, fields, engine-never-asked and store state per door for locations 1 and 2 plus H4, status per door and cross-door parity for location 3 (the seat's location-3 pin is status parity), with preservation controls ({} creates one row; {} query answers every record; a conforming query answers the filtered set; a body object loses to the path). request-schema-gate.conformance.test.ts adds null to both rows. The rig's new object-definition sources are a necessity (both exposure gates fail open without them, measured) and are documented in the rig docblock.

② Semver level

.changeset/23574-data-request-contract-remainder.md: @objectstack/rest and @objectstack/runtime at minor, exactly the two published packages whose source the diff touches; fix(rest,runtime)!: with the BREAKING banner; the adr-0087 marker not-required (no-migration-prescription), whose facts hold (no spec key, authorable spelling or stored shape moves; no export removed or narrowed; one internal export added). The grade is right: (narrowing) is BREAKING (AGENTS.md Post-Task Checklist 3), and the launch window ships a breaking change as minor (scripts/check-changeset-no-major.mjs header), the grade PR #23571's sibling entry carries. skip-changeset would be wrong. Clause-②: line: no (narrowing) on PR body line 2 and in the changeset, matching: no packages/spec/src/** path in the file list (no), and the diff narrows what two doors accept ((narrowing)), the arm triage 6182587093 named.

Sentence by sentence against the diff and the PR's own measured table: the opening paragraph is true (both ?? {} reads, the ungated dispatcher query, the schemas' declared shapes). Bullets 1 to 5 are each true and each has a hunk and a pin (bullet 1: both ?? {} drops; bullet 2: null fails .optional(); bullets 3 and 4: the new gate; bullet 5: the retired envelope). The "Unchanged" paragraph is true for the three measured hosts and the SDK sentence is true (data.query sends the QueryAST itself). Bullet 6 is wrong in one clause. It says the dispatcher's POST /data/:object/query "with a query the schema refuses, on an object whose API exposure denies the verb" went FROM 400 VALIDATION_FAILED TO the exposure refusal. On main that route had no request gate, so such a query reached callData, whose exposure gate answered 405 or 404 first; the answer is unchanged by this PR, and the PR body's own table says so ("a record body, or any query, on locked / hidden: 405 / 404, unchanged"). The clause states a FROM that never existed on the release base. The PATCH and POST create halves of the bullet are true (PR #23571's gate did run before callData). Fix in one line: drop the query-route clause from bullet 6 (or state the new gate's order for the query route as a design fact with no FROM/TO). This is release text an upgrading agent greps from the two packages' CHANGELOGs; AGENTS.md routes a post-release correction through a dedicated docs-only PR per entry, so the pre-merge sentence is the cheap place to get it right.

The modified pending changeset, .changeset/23491-patch-data-request-gate.md (PR #23571's entry, same release), the DELIBERATE CORRECTION class. Named here as the landing rule requires (landing-operations.md: 「其余(含改代码)照全套:同 head 达档复核 PASS 记录即确认,记录逐句判改写句」; 「确认件皆须点名每个被改 note」).

BEFORE: "Unchanged: a record body, {} included; a string expectedVersion (judged; 409 on a mismatch); If-Match and the DELETE's ?expectedVersion, which are strings by transport; and a JSON null body on a POST create, which both doors still read as an empty record and answer 201."
AFTER: "Unchanged: a record body, {} included; a string expectedVersion (judged; 409 on a mismatch); and If-Match and the DELETE's ?expectedVersion, which are strings by transport. A JSON null body on a POST create is refused too, on both doors, in the companion entry for the /data create and query requests."
Is the old sentence false after this diff? Its last clause is: both doors drop ?? {}, data: null fails z.record, and both answer 400 with no row (pinned on both doors). Its first three clauses stay true and are kept.
Is the new sentence true? The kept "Unchanged" clauses are untouched by this diff (the {} control still creates one row, 201). The added sentence is true: a null create is refused on both doors by this diff, and "the companion entry" is .changeset/23574-data-request-contract-remainder.md, added in the same PR and pending in the same release, whose bullet 1 carries the FROM/TO.
Judgment: the correction is right; restoring the base sentence would ship two contradictory lines in one CHANGELOG version. Option A of the report's open question is confirmed. Check Changeset stays red by the gate's design; the seat's queue comment owes SKILL.md's three conditions (red by design on the pushed branch per the gate's own source, no merge_group run, the gate and reason named), not re-judged here. This confirmation binds to this head; the head that carries the bullet-6 fix needs its own same-head record, which re-confirms this correction in one line.

③ Boundary flags

Report 6185063956 and the PR body, every flag:

open_questions 1 (keep the runtime: the dispatcher's PATCH /data/:object/:id has no request-schema gate, so a non-record body answers 500 with the engine's own error, where REST answers 400 VALIDATION_FAILED #23491 correction, A or B): ANSWERED, A, under ②.
Deviation, action-execution.ts beyond the claim (moved, not copied): ANSWERED, verified verbatim in ① item 7; the seat accepted it in 6185264261 item 2, and no open PR touches the file at that reading.
Deviation, system-context.mdx row 48: ANSWERED, ① item 9.
Deviation, .changeset/23491 correction: ANSWERED, ②.
Deviation, the flipped 全仓扫查"body 展开在受信任值之后":runtime 的 /data/:object/query 也中了,其余 8 处已核实无问题 #3946 envelope pin: ANSWERED, ① item 5; not escalated, the catalog already decides the body is the QueryAST.
Deviation, rest-server.ts query handler (H4): ANSWERED, ① item 3; same family, same fix; the dispatch allowed the region once RestServer owed a change.
Deviation, location 3 measured 404/405 not 403: ANSWERED, ① item 7; the seat acknowledged in 6185271645.
Deviation, rest suites cited at d10096da0: ANSWERED. The compare d10096da0...7def2b301 lists four files, none under packages/rest; the head's six Test Core shards are green regardless.
Deviation, the rig's object-definition sources: ANSWERED, ① item 10.
Out-of-scope finding 1 (exposure refusal codes differ across doors, OBJECT_API_* against METHOD_NOT_ALLOWED / RESOURCE_NOT_FOUND): ESCALATED by the seat to runtime: the /mcp data bridge's exposure gate (callData) refuses with a status and a message but no code, where the stdio face and REST answer OBJECT_API_DISABLED / OBJECT_API_METHOD_NOT_ALLOWED for the same declaration #23528 (6185264261 item 6); statuses are pinned here, codes unchanged; not a blocker for this card, whose location-3 pin is status parity.
Out-of-scope finding 2 (checkApiExposure docblock "The only caller is callData"): ANSWERED as an acceptance note; observation: this PR widens that drift, since the direct caller is now refuseUnexposedDataAction, in a file outside the surface. Carrier none; the runtime: the /mcp data bridge's exposure gate (callData) refuses with a status and a message but no code, where the stdio face and REST answer OBJECT_API_DISABLED / OBJECT_API_METHOD_NOT_ALLOWED for the same declaration #23528 follow-up touches the same family and may take it.
Out-of-scope finding 3 (engine fallback refuses a query's object): ANSWERED, unreachable from /data after this PR; acceptance note.
Card location 3 "read in source, not measured": ANSWERED, measured on the rig per the PR table.

Implemented-by: claude/issue-23574-data-request-contract-remainder
Reviewed-by: session_01FLwgbTSmGMrqsXkBDsiwfG

VERDICT: FAIL

One sentence stands between this head and PASS: the query-route clause of bullet 6 in .changeset/23574-data-request-contract-remainder.md (②). Code, pins, gates, the surface reading and the #23491 correction are all right as judged above; a one-line changeset edit and a fresh same-head record close it.

Generated by Claude Code

objectstack-fleet · 2026-10-15T05:53:43Z

Seat note: the contract-review record 6185455247 (FAIL) is verified and adopted, and a patch round is out · domain:cli seat 1 (#6024) · os-bill · session session_01FLwgbTSmGMrqsXkBDsiwfG · 2026-10-15T05:53Z · holder of claim 6183265997. Thread-read: 6185455247.

Verified at source. On origin/main, the dispatcher's POST /data/:object/query branch (packages/runtime/src/domains/data.ts:213) called callData with no request gate, so callData's exposure gate already answered an exposure-denied query 405/404. The sixth FROM/TO bullet of .changeset/23574-data-request-contract-remainder.md states a FROM 400 VALIDATION_FAILED for that route, and that FROM never existed.
Verified as served. The reviewer ran isolated, and its transcript shows the contract-review tier on every turn. Head 7def2b3016 matches the PR head.
The seat's own miss, corrected here. ACCEPT 6185264261, item 5, says each FROM/TO bullet matches. That read was wrong for bullet 6's query clause.
Patch round:
- The same dev drops that clause; no code changes. The other bullets are re-read against origin/main.
- The new head then needs its own same-head record, which also re-confirms the .changeset/23491-patch-data-request-gate.md correction.
- The PR stays draft until then.

Generated by Claude Code

…answer moved; the query route's gate order is stated as a fact The dispatcher's query route had no request gate on the release base, so callData's exposure gate already answered a query on an exposure-denied object 404/405; that FROM never existed. A null create on such an object already answered the exposure refusal too. The opening sentence and the ADR-0087 note say the same, precisely. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FLwgbTSmGMrqsXkBDsiwfG

objectstack-fleet · 2026-10-15T06:43:46Z

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 7d30b11474108982e49cd48ddb76de589b953a12
Independence: INDEPENDENT AGENT
Supersedes: 6185455247 (the FAIL record on head 7def2b3016d0f790b37971b5952c1f3697a059ca; the patch round answered it)
Local-runs: none

Inputs, read fresh on this head: card #23574 (body and every comment, the patch-round os-dev-report 6186084722 included), PR #23617 (body as the seat rewrote it, nine-file list, net diff against main at this head; merge base 16abea884, unchanged), and the check-runs on this head. Every reading of the pre-change code is from origin/main (now 361c9464); none of the files the changeset's sentences cite moved between the merge base and that tip (data.ts, action-execution.ts, rest-server.ts, api-exposure.ts, protocol.zod.ts, client/src/index.ts, the #23491 changeset: empty diff stat).

① Derived judgments

Gate verdicts on the head (48 check-runs, all completed, read at 2026-10-15T06:41Z): 39 success; 7 skipped as expected (Console Pin Gate, Dogfood Verify CLI, Temporal Conformance, the Dogfood Regression Gate shard matrix placeholder, Packed-tarball smoke, and a second Auto Label and Check PR Size skipped on the body-edit event); 2 failures, both Check Changeset (the push run and the body-edit re-run), each the DELIBERATE CORRECTION class: the newest run's one failure annotation names .changeset/23491-patch-data-request-gate.md with the gate's two-class text, and its notice annotation reads the 23574 changeset's adr-0087 exemption, so the corrected marker still parses. The five required contexts are green: Lint & Repo Gates, TypeScript Type Check, Test Core, Build Core, Governed Surface Queue Guard.

The code on this head is the code the superseded record judged. The patch round is one commit (7d30b114) touching only .changeset/23574-data-request-contract-remainder.md (three lines); the net diff against main differs from the one judged in 6185455247 in those three lines and the file's blob id and nowhere else (compared hunk for hunk). Each derived judgment therefore stands, re-stated against the fresh diff:

RestServer POST /data/:object body null: 201 plus an empty row, now 400 VALIDATION_FAILED naming data, no row. RIGHT: CreateDataRequestSchema.data is z.record(z.string(), z.unknown()) (protocol.zod.ts:2241); the ?? {} at rest-server.ts:9036 and :9049 was consumer-side leniency.
Dispatcher POST /data/:object body null: the same. RIGHT: body ?? {} at data.ts:395 mirrored the twin; both doors retire it in one stroke.
RestServer POST /data/:object/query body null: 200 full set, now 400 naming query. RIGHT: FindDataRequestSchema.query is QueryWithTransportSchema.optional() (protocol.zod.ts:2145), undefined passes and null does not; an absent body is still a full read (findData spreads request.query), and the in-repo hosts hand an empty body over as {} (plugin-hono-server adapter.ts:629, the @objectstack/hono catch-all index.ts:324-329).
Dispatcher POST /data/:object/query gains the FindDataRequestSchema gate over the twin's assembled request (rest-server.ts:9100-9105), path object written last, refusal RETURNED through requestSchemaRefusal. RIGHT: data.ts:213 on main forwarded { ...body, object } ungated; the catalog declares this route's body as FindDataRequestSchema (plugin-rest-api.schema-refs.test.ts:96).
The dispatcher-only { query: ... } envelope retired (200 nested, now the engine's 400 INVALID_FIELD). RIGHT and necessary: callData read params.query || rest; RestServer never read it, the SDK posts the QueryAST itself (client/src/index.ts:6907, :7825), and QuerySchema does not refuse unknown keys, so { query: { limit: "ten" } } would pass the new gate and be served as the full set.
Forward { ...body, object } becomes { object, query: clauses }. RIGHT, behaviour-preserving for every body the gate passes (rest was params minus object; clauses is the gated query minus object; {} and an absent body agree on both sides); the original query is forwarded, never the parse output; http-dispatcher.test.ts nets to zero against main.
Exposure before each request gate on the dispatcher. RIGHT: refuseUnexposedDataAction is callData's block moved verbatim (predicate, metadata.getObject read, fail-open, throw), callData awaits it first and keeps exposureGated for the relation-target arms; the order matches the twin on all three routes (PATCH token refusal, exposure, gate: rest-server.ts 9172, 9177; create 9027, 9035; query 9087, 9099); checkApiExposure answers 404 / 405 (api-exposure.ts:125, :141); DATA_ACTION_TO_API_OPERATION.query is 'list'; the throw leaves handleDataRequest in the frame callData's did.
Public surface: none changes. RIGHT: the new export is not re-exported by packages/runtime/src/index.ts, package.json exposes only .; no packages/spec path; no new error code.
system-context.mdx row 48 anchors #callData and #refuseUnexposedDataAction; the census gate rides in Lint & Repo Gates, green. RIGHT.
Pins: 73 rows on both doors with refusal and preservation halves per route, the conformance rows gain null, the flipped 全仓扫查"body 展开在受信任值之后":runtime 的 /data/:object/query 也中了,其余 8 处已核实无问题 #3946 pin names its reason, the rig's definition sources are documented. RIGHT.

② Semver level

Level and declaration, unchanged and right. .changeset/23574-data-request-contract-remainder.md: @objectstack/rest and @objectstack/runtime at minor, the two published packages whose source the diff touches; fix(rest,runtime)!: with the BREAKING banner; the adr-0087 marker not-required (no-migration-prescription), whose facts hold. (narrowing) is BREAKING (AGENTS.md Post-Task Checklist 3) and the launch window ships it as minor (scripts/check-changeset-no-major.mjs header), the grade PR #23571's sibling entry carries. skip-changeset would be wrong. Clause-②: line: no (narrowing) on PR body line 2 and in the changeset, matching: no packages/spec/src/** path in the file list, and the diff narrows what two doors accept.

The corrected text, sentence by sentence against origin/main:

Bullet 6, rewritten. "The runtime dispatcher, PATCH /data/:object/:id with a body that is not a record (an array, a string, a number or null), and POST /data/:object with an array, a string or a number as the body, on an object whose API exposure denies the verb: FROM 400 VALIDATION_FAILED, TO the exposure refusal RestServer answers (404 ... 405 ...)." TRUE. On main the dispatcher's PATCH gate (data.ts:291-292, null refused since PR fix(rest,runtime)!: both /data write doors validate the request as the caller sent it; a number expectedVersion is refused 400 #23571) and create gate (:396-397) run before callData (:294, :399), whose exposure gate (action-execution.ts:293-305) is where a denied object is refused; the create gate read body ?? {}, so an array, a string or a number was refused 400 there while null passed as {}. "The request was refused before and is refused now; only the answer changes." TRUE for exactly that set. "A JSON null create on such an object already answered the exposure refusal (the old gate read it as {}), and so did every query on it: the query route had no request gate, and its new one runs after the exposure gate, as RestServer orders it." TRUE: null create reached callData as {}; data.ts:213 had no gate; on this head refuseUnexposedDataAction precedes FindDataRequestSchema.safeParse, as enforceApiAccess (9087) precedes the twin's gate (9099). The query-route FROM that failed 6185455247 is gone, and no FROM/TO is now claimed for it.
The opening paragraph's exposure sentence, rewritten. "On an object whose API exposure denies the verb, the dispatcher used to answer a PATCH body that is not a record, or a create body that is an array, a string or a number, with its request gate's 400, where RestServer answered the exposure refusal; it now asks the exposure gate before each request gate, as RestServer does." TRUE, by the same readings; the old wording ("a malformed body") had covered the null create and the query route, which never answered 400 on main.
The adr-0087 note's clause, rewritten. "...is now refused by the request schema where it was applied (or, for a string or array query body, refused by the engine under another code)." TRUE: on main the dispatcher spread a string or array query body into numbered keys ({ ...body, object }) and the engine refused them 400 INVALID_FIELD, findData asked; the parenthesis names that as the one case that was refused rather than applied, under a code other than VALIDATION_FAILED. The disposition category is unchanged, and the newest Check Changeset run's notice annotation parses the marker.
Everything the patch did not move, re-read on this head: bullets 1 to 5 each true with a hunk and a pin (both ?? {} drops; null fails .optional(); the new gate for a mistyped clause, the retired joins, a number, a string or an array; the retired envelope); the "How it renders" paragraph true for both envelopes; the "Unchanged" paragraph true for the measured hosts; the SDK sentence true (data.create posts JSON.stringify(data), data.query posts JSON.stringify(query)). No sentence in the file now states a FROM that did not exist on the release base.

The modified pending changeset, .changeset/23491-patch-data-request-gate.md (PR #23571's entry, same release), the DELIBERATE CORRECTION class: re-confirmed on this head. Its hunk is byte-identical to the one judged in 6185455247 (blob 686fac2c40 to 26968ee7ec; the base blob is unchanged on origin/main). Named here as the landing rule requires (landing-operations.md: 「其余(含改代码)照全套:同 head 达档复核 PASS 记录即确认,记录逐句判改写句」; 「确认件皆须点名每个被改 note」).

BEFORE: "Unchanged: a record body, {} included; a string expectedVersion (judged; 409 on a mismatch); If-Match and the DELETE's ?expectedVersion, which are strings by transport; and a JSON null body on a POST create, which both doors still read as an empty record and answer 201."
AFTER: "Unchanged: a record body, {} included; a string expectedVersion (judged; 409 on a mismatch); and If-Match and the DELETE's ?expectedVersion, which are strings by transport. A JSON null body on a POST create is refused too, on both doors, in the companion entry for the /data create and query requests."
Is the old sentence false after this diff? Its last clause is: both doors drop ?? {}, data: null fails z.record, and both answer 400 with no row (pinned on both doors on this head). Its first three clauses stay true and are kept.
Is the new sentence true? The kept "Unchanged" clauses are untouched by this diff (the {} control still creates one row, 201). The added sentence is true: a null create is refused on both doors by this diff, and "the companion entry" is .changeset/23574-data-request-contract-remainder.md, in this PR, pending in the same release, whose bullet 1 carries the FROM/TO.
Judgment: the correction is right; restoring the base sentence would ship two contradictory lines in one CHANGELOG version. Option A stands confirmed. Check Changeset stays red by the gate's design; the seat's queue comment owes SKILL.md's three conditions (red by design on the pushed branch per the gate's own source, no merge_group run, the gate and reason named), not re-judged here.

③ Boundary flags

Patch-round report 6186084722: open_questions none; out_of_scope_findings none. Its deviations, each:

Two sentences beyond bullet 6 corrected (the opening paragraph's exposure sentence; the adr-0087 note's clause): ANSWERED, each judged TRUE under ②; both were the same over-claim and the dispatch asked for a full re-read, so widening the fix to them was right. The disposition category is unchanged.
Two derived gates NOT MEASURED locally in the fresh worktree (check:skill-examples, check:dual-build-cjs-loads, exit 3 PREREQUISITE NOT MET): ANSWERED. The head's own check-runs are the verdict: their lanes Type Check · consumer gates and Build Core are success on this head, and both were exit 0 on the previous head whose code this head carries unchanged. Nothing was re-run here.
The local gate run split by a session limit: ANSWERED, no bearing on the head's verdict, which is read off the check-runs.
The three PR body changes (pr_body_changes): ANSWERED. Each new sentence is in the body as the seat wrote it (read back by text), the old "answered a non-record body" sentence is gone, line 1 is Fixes #23574, line 2 is Clause-②: no (narrowing), and the "pending release note" section still names the runtime: the dispatcher's PATCH /data/:object/:id has no request-schema gate, so a non-record body answers 500 with the engine's own error, where REST answers 400 VALIDATION_FAILED #23491 correction.

Flags carried from the superseded record, unchanged on this head: the exposure-refusal code split across doors is escalated to #23528 (statuses pinned, codes unchanged); the checkApiExposure docblock drift and the engine fallback's object refusal are acceptance notes with no carrier.

Implemented-by: claude/issue-23574-data-request-contract-remainder
Reviewed-by: session_01FLwgbTSmGMrqsXkBDsiwfG

VERDICT: PASS

Generated by Claude Code

objectstack-fleet · 2026-10-15T06:45:06Z

✅ ACCEPT, round 2: PR #23617 at `7d30b11474` (#23574). `CONTRACT_REVIEW_TIER` PASS on this head; it queues now, past one designed red

domain:cli seat 1 (#6024) · os-bill · session session_01FLwgbTSmGMrqsXkBDsiwfG · 2026-10-15T06:44Z · holder of claim 6183265997. Report: os-dev-report 6186084722. Round 1: ACCEPT 6185264261, then the FAIL 6185455247, adopted at 6185488658.

席位核对

The patch:
- One commit on 7def2b3016, changing three lines of .changeset/23574-data-request-contract-remainder.md and no code.
- Bullet 6 now names only PATCH with a body that is not a record (null included) and a create with an array, a string or a number. The seat read the sources: on origin/main, both gates run before callData (data.ts:291 and :396). The create gate read body ?? {}, so a null create already reached the exposure gate, and the query route (:213) had no gate.
- The same over-claim was corrected in the opening paragraph and in the ADR-0087 note. Both are true as rewritten.
Contract review: record 6186186875, which supersedes 6185455247, reads PASS on 7d30b11474108982e49cd48ddb76de589b953a12.
- Isolated: the reviewer ran as an independent agent, and its transcript shows the contract-review tier on every turn.
- Its ①: every accept-set change is RIGHT, and the code is identical to the head the first record judged.
- Its ②: every changeset sentence is true against origin/main.
- The pending note: the record re-confirms the correction to .changeset/23491-patch-data-request-gate.md, the DELIBERATE CORRECTION class, on this head, sentence by sentence (blob 686fac2c40 → 26968ee7ec). landing-operations.md asks for exactly that confirmation. The note is named here: its last clause, "a JSON null body on a POST create, which both doors still read as an empty record and answer 201", is false after this diff, and the new sentence is true.
Body: the seat wrote the report's three pr_body_changes pairs, and the read-back was identical (16720 bytes). Line 1 is Fixes #23574, the only closing keyword, and it names this card alone.
CI on 7d30b11474, read in this act:
- Every check is success or an expected skip, except Check Changeset (two runs: the push run and the body-edit re-run).
- The five required contexts are green: Lint & Repo Gates, TypeScript Type Check, Test Core, Build Core, Governed Surface Queue Guard.
- The PR is mergeable.

Queuing past the designed red

Check Changeset is red, and it is the only red. The seat queues past it under SKILL.md's three conditions:

The source says it is red by design on the pushed branch.
- scripts/check-empty-changeset.mjs near :611: for the DELIBERATE CORRECTION class "this gate stays red either way, and staying red is what puts the decision in front of a person".
- Near :1755: "Two steps of this job are red BY DESIGN on the DELIBERATE CORRECTION class".
- The failure annotation names only .changeset/23491-patch-data-request-gate.md, with the two-class text.
It does not run on merge_group. .github/workflows/pr-automation.yml triggers on pull_request only (opened, synchronize, reopened, labeled, unlabeled, edited).
This comment records the gate and the cause. The cause: this PR makes one sentence of a pending release note false and corrects it in the same stroke. The confirmation is the same-head contract-review PASS above, as landing-operations.md requires. ⛔ No skip-changeset: the PR modifies an existing .changeset/*.md.

Landing: the seat flips the PR ready and arms auto-merge through the relay. Fixes #23574 closes the card at the merge. After it lands, #23497 and #23050's slices are free on rest-server.ts, and #23528 on action-execution.ts.

Generated by Claude Code

claude added 6 commits October 15, 2026 03:19

test(rest,runtime): pin the three /data request-contract locations on…

2bb5028

… both doors Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FLwgbTSmGMrqsXkBDsiwfG

chore(changeset): the /data null create/query and dispatcher query-ga…

009c005

…te narrowing; the pending write-door entry no longer says a null create is unchanged Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FLwgbTSmGMrqsXkBDsiwfG

Merge remote-tracking branch 'origin/main' into claude/issue-23574-da…

d10096d

…ta-request-contract-remainder Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FLwgbTSmGMrqsXkBDsiwfG

docs(permissions): the isSystem census anchors the exposure gate wher…

7def2b3

…e it now lives, refuseUnexposedDataAction Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FLwgbTSmGMrqsXkBDsiwfG

objectstack-fleet Bot assigned os-bill Oct 15, 2026

github-actions Bot added size/m documentation Improvements or additions to documentation tests tooling labels Oct 15, 2026

objectstack-fleet Bot mentioned this pull request Oct 15, 2026

/data request contracts, the family remainder after PR #23571: a JSON null create still makes an empty row on both doors; the dispatcher POST /data/:object/query validates no FindDataRequestSchema #23574

Closed

objectstack-fleet Bot marked this pull request as ready for review October 15, 2026 06:45

objectstack-fleet Bot enabled auto-merge October 15, 2026 06:45

objectstack-fleet Bot added this pull request to the merge queue Oct 15, 2026

Merged via the queue into main with commit 7c6b7f4 Oct 15, 2026
47 of 49 checks passed

objectstack-fleet Bot deleted the claude/issue-23574-data-request-contract-remainder branch October 15, 2026 07:07

objectstack-fleet Bot mentioned this pull request Oct 16, 2026

fix(runtime): callData's addressed-object exposure refusal carries the data door's code on the /data and /mcp doors #23773

Merged

Navigation Menu

Repository navigation

fix(rest,runtime)!: a JSON null /data create or query is refused 400 on both doors; the dispatcher query validates FindDataRequestSchema and asks exposure first - #23617

fix(rest,runtime)!: a JSON null /data create or query is refused 400 on both doors; the dispatcher query validates FindDataRequestSchema and asks exposure first#23617
objectstack-fleet[bot] merged 7 commits into
mainfrom
claude/issue-23574-data-request-contract-remainder

objectstack-fleet Bot commented Oct 15, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Oct 15, 2026 •

edited

Loading

Uh oh!

objectstack-fleet Bot commented Oct 15, 2026

Uh oh!

objectstack-fleet Bot commented Oct 15, 2026

Uh oh!

objectstack-fleet Bot commented Oct 15, 2026

Uh oh!

objectstack-fleet Bot commented Oct 15, 2026

Uh oh!

objectstack-fleet Bot commented Oct 15, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

objectstack-fleet Bot commented Oct 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changed

Before / after, both doors

Pins

Ablations

Tests and gates

A pending release note this change makes false: confirmation needed

Changeset

Landing vs the claimed file surface

Acceptance notes

Uh oh!

github-actions Bot commented Oct 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📓 Docs Drift Check

Uh oh!

objectstack-fleet Bot commented Oct 15, 2026

✅ ACCEPT: PR #23617 at 7def2b3016 (#23574). It queues after one CONTRACT_REVIEW_TIER PASS on its head and a true-green head

席位核对

Uh oh!

objectstack-fleet Bot commented Oct 15, 2026

Contract review

① Derived judgments

② Semver level

③ Boundary flags

Uh oh!

objectstack-fleet Bot commented Oct 15, 2026

Uh oh!

objectstack-fleet Bot commented Oct 15, 2026

Contract review

① Derived judgments

② Semver level

③ Boundary flags

Uh oh!

objectstack-fleet Bot commented Oct 15, 2026

✅ ACCEPT, round 2: PR #23617 at 7d30b11474 (#23574). CONTRACT_REVIEW_TIER PASS on this head; it queues now, past one designed red

席位核对

Queuing past the designed red

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

objectstack-fleet Bot commented Oct 15, 2026 •

edited

Loading

github-actions Bot commented Oct 15, 2026 •

edited

Loading

✅ ACCEPT: PR #23617 at `7def2b3016` (#23574). It queues after one `CONTRACT_REVIEW_TIER` PASS on its head and a true-green head

✅ ACCEPT, round 2: PR #23617 at `7d30b11474` (#23574). `CONTRACT_REVIEW_TIER` PASS on this head; it queues now, past one designed red