QA run · area:api-backend · 5/14 · 19f98fa1 · 2026-08-20

[os-elon]

Post-release sweep for 17.1.0, api-backend lane. Selected because 17.1.0 narrows error.code to a closed vocabulary at every door and adds declaredCode (#9106) — a change that rewrites the expected shape of every refusal assertion in the ledger.

Environment

Identical to companions #10224 (priority:P0) and #10225 (area:automation): framework 19f98fa1fffbeb305bdcb6af64bc826fb25a46b1, .objectui-sha / console dist stamp both 9a3daf8d37ad973a621e5edd276fe32467f90684, showcase on port 3456 against a file DB, 2026-08-20.

Execution mode: SEQUENTIAL, declared. No subagent fan-out.

Scope

Selector area:api-backend → 14 runnable items. 5 adjudicated, 9 not reached — this run was scoped to the release's highest-risk surface rather than the full area.

Per-item verdicts

item	rev	verdict	evidence
api-backend.query-contract-matrix	2	pass	pin objectql/src/engine.test.ts, 135 assertions
api-backend.bulk-write-contract	1	pass	pin owner-anchor-and-bulk-writes.dogfood.test.ts
api-backend.declarative-endpoint-execution	1	pass	pin showcase-declarative-endpoints.dogfood.test.ts, 17 assertions
api-backend.error-envelope-ledger	2	partial 5/6	hand-driven, detail below
api-backend.filter-comparand-conformance	1	partial 4/5	hand-driven, detail below
9 others	—	not-run	listed under handoff

No fail recorded, so no reproduction rules are owed.

api-backend.error-envelope-ledger (rev 2)

Ledger membership was checked against the real union — StandardErrorCode (errors.zod.ts, 50 members) ∪ the registered codes in error-code-ledger.zod.ts (245) = 290 codes.

family	status	code	ledgered
validation	400	VALIDATION_FAILED	✅
auth (anonymous)	401	UNAUTHENTICATED	✅
not-found OBJECT	404	OBJECT_NOT_FOUND	✅
not-found RECORD	404	RECORD_NOT_FOUND	✅
batch	400	VALIDATION_FAILED	✅
query-param rejection	400	UNSUPPORTED_QUERY_PARAM	✅

• [0] every sampled code is ledgered — pass
• [1] field-level shape — pass: top-level VALIDATION_FAILED, fields[0] = {field:"name", code:"required", message:"Invoice Number is required", label:"Invoice Number"} (lowercase-snake field code, ADR-0114 D2)
• [2] retired fieldErrors key — pass, absent from all six bodies (ADR-0114 D4 tombstone holds)
• [3] status↔code mapping — pass, table above; no 5xx for caller-fixable input, so the 数据 API:集合算子 not_in/in 的比较值是标量(非数组)时答 500 DATABASE_ERROR,而不是带信封的 400 —— 而这个形状是 spec 合法的 ViewFilterRule #5869 NEGATIVE is excluded
• [4] the two 404 flavors are distinguishable — pass: OBJECT_NOT_FOUND "Object 'not_a_real_object' is not registered" vs RECORD_NOT_FOUND "Record nonexistent-id-0000 not found in showcase_task". A client can tell schema drift from data absence
• [5] one sample per family — partial: the 403 authorization family was not sampled (needs a baseline-member persona). Five of six families captured, which per the clause's own wording leaves the item partial

api-backend.filter-comparand-conformance (rev 1)

Accepted set read from the pinned export: string · number · bigint · boolean · null · Date. Baseline showcase_account total = 14 (the control every leak assertion is measured against).

• [0] accepted members — pass: string → 1 row, number → 14, null → 0, Date-ish → 6; each returns a distinct, non-degenerate answer set
• [1] non-accepted types are REFUSED — pass, and the load-bearing NEGATIVE is positively excluded:

comparand	answer
plain object	400 INVALID_FILTER — "requires a single comparable value, but received an object ({"a":1})"
nested array	400 INVALID_FILTER — "received an array, which cannot be bound"
function-shaped $fn	400 INVALID_FILTER — "Unsupported filter operator "$fn" … Supported operators: $eq, $ne, $gt, …"

None answered 200 over the unfiltered 14-row set — i.e. no predicate was silently dropped, which is the row-leak failure this item exists for.

• [2] bigint exact-integer boundary — not-run, and the clause is not testable through this door: a comparand past 2**53 cannot survive JSON parsing on the REST path (it is rounded before the platform ever sees it), so a 200 here says nothing about platform precision handling. Verifying it needs the engine/objectql door. Worth recording on the item so the next runner does not repeat the attempt.
• [3] dotted head classification — pass, all three classes refused with a located message and none returning the unfiltered set:

head	answer
relation (owner_id.name)	400 INVALID_FIELD — "follows the relationship 'owner_id' into another object"
scalar (name.length)	400 INVALID_FIELD — "a dotted path into 'name', a 'text' field on object 'showcase_account'"
unknown (nope.deep)	400 INVALID_FIELD — "is not a field on object 'showcase_account'"

• [4] second-door parity — not-run (only the REST door was exercised)

Adjacent pins executed in this session

Belonging to the since:v17 sweep rather than this area, recorded here so the evidence is not lost — they should be carried forward when that round is run properly:

item	rev	result
ai.skill-instructions-mcp-prompts	1	pin mcp/src/skill-prompts.test.ts — 12 assertions green
identity-auth.invitation-scope-gates	1	pin delegated-admin-invite.dogfood.test.ts — 4 assertions green
access-security.no-active-org-session-semantics (blocked item's pin)	—	plugin-security/src/no-active-organization-write-refusal.test.ts — 19 assertions green
records-forms.* array-lowering	—	objectql/src/engine-filter-array-lowering.test.ts — 46 assertions green

Checklist gaps (for the wave anchor card — NOT extracted)

• api-backend.filter-comparand-conformance clause [2] pins a bigint boundary that cannot be exercised through the REST door at all (JSON number precision). The clause should either name the engine door explicitly or be marked door-specific.
• The 403 family in error-envelope-ledger needs a named baseline-member persona in fixtures.requires; without one, clause [5] cannot reach pass on stock showcase.

Not reached — handoff

batch-transactional-discovery (rev 3) · formula-gates (rev 2) · enforce-or-remove-authoring-gates (rev 2) · server-timing-admin-gated (rev 2) · route-ledger-live-parity (rev 2) · package-rest-lifecycle (rev 1) · api-console-discovery-execute (rev 1) · date-range-preset-matrix (rev 1) · retired-def-refusal (rev 1).

Three of these (formula-gates, enforce-or-remove-authoring-gates, retired-def-refusal) are build-oracle items and are the cheapest next batch — they need no browser and no persona.

[os-elon]

Close-out. Zero fail in this run, so nothing is extracted.

Both partial verdicts are fixture/clause problems rather than product problems, parked on the wave anchor:

Parked-on: #10236 · api-backend.error-envelope-ledger · clause 5 — 403 family needs a baseline-member persona
Parked-on: #10236 · api-backend.filter-comparand-conformance · clause 2 — bigint boundary untestable through the REST door (JSON precision)

Carried forward for whoever runs the since:v17 round properly — these pins were executed here but belong to that selector:

Carried-forward: #10233 · ai.skill-instructions-mcp-prompts · pin green (12 assertions)
Carried-forward: #10233 · identity-auth.invitation-scope-gates · pin green (4 assertions)

---

Generated by Claude Code

[os-elon]

Round continued — this area is now 8/14, and one verdict in the body is superseded.

Superseded

api-backend.error-envelope-ledger (rev 2) — partial 5/6 → pass 6/6. The missing 403 authorization family was reachable all along: the showcase declares loginable non-admin personas (phone.demo@example.com / auditor.demo@example.com, DEMO_PERSONA_PASSWORD = 'showcase123', src/security/demo-personas.ts). Driven as Mei: POST /api/v1/data/showcase_announcement → 403 PERMISSION_DENIED, a ledgered code. The body's claim that stock fixtures cannot reach pass was my error; corrected on #10236.

Newly adjudicated

item	rev	verdict	evidence
api-backend.batch-transactional-discovery	3	partial 4/5	below
api-backend.enforce-or-remove-authoring-gates	2	partial 3/4	below
api-backend.date-range-preset-matrix	1	partial 2/4	below

batch-transactional-discovery — operation shape is {object, operation, data}:

• [0] pass — discovery.capabilities.transactionalBatch.enabled = true and a well-formed batch answers 200
• [1] pass — top-level atomic:false → 400 BATCH_NOT_ATOMIC, message names the way out: "Cross-object batch is always atomic; use POST /data/:object/batch for non-atomic per-object batches"
• [2] pass — a failing middle member rolls the batch back: showcase_private_note stays at 2 rows across the attempt. Load-bearing because [0] proved a well-formed batch does write
• [3] pass — 201 operations → 400 BATCH_TOO_LARGE, row count unchanged (refused up front, not partially executed)
• [4] not-run — the per-object door's operation schema differs from the cross-object one and I did not establish it. My first pass scored this ✓ on a status < 500 assertion, which is too wide to prove "defaults to non-atomic per-row outcomes". Recording it as unverified rather than keeping a green that proves nothing.

enforce-or-remove-authoring-gates — six tombstones sampled across three surfaces:

key	surface	result
query.cursor / query.joins / query.windowFunctions / query.distinct	query schema	rejected, each quoting the removal ADR + issue and the replacement
query.aggregations[].distinct	aggregation surface	rejected with the count_distinct prescription
EnhancedApiError.fieldErrors	error envelope	rejected — "renamed to fields in @objectstack/spec 17 (ADR-0114 D4, #3977) — the array is unchanged, only the property name"

• [0] pass · [1] pass · [3] pass (3 surfaces ≥ the required 3) · [2] not-run (no silently-stripped-by-design key sampled)

Worth recording: a positive control decided the last row. A random unknown key (zzz_not_real) passes EnhancedApiErrorSchema while fieldErrors is rejected — so the refusal is the retiredKey mechanism firing deliberately, not a .strict() side effect. Tested against the non-strict ApiErrorSchema first, where the retired key passes exactly like any unknown key; without the control that reads as "tombstone silently accepted", which would have been a false finding.

date-range-preset-matrix — 13 presets in DATE_RANGE_PRESETS:

• [2] pass — a bare preset name as a raw comparand (issued_on = "today", = "this_year") → INVALID_FILTER, refused rather than coerced
• [3] pass — an unknown preset name (not_a_preset_xyz) → INVALID_FILTER, not resolved into an empty or unbounded window
• Control: issued_on > 2026-01-01 → 200 / 10 rows, so the refusals are not the field being broken
• [0] [1] not-run — the item never states how a preset is actually invoked. Step 2 says "issue a data-API read filtered by that preset" without a spelling; $preset is not a recognised operator. That is a gap in the clause, not a platform behaviour, and it blocks the exhaustive matrix.

Area standing after this round

pass: query-contract-matrix · bulk-write-contract · declarative-endpoint-execution · error-envelope-ledger
partial: filter-comparand-conformance · batch-transactional-discovery · enforce-or-remove-authoring-gates · date-range-preset-matrix
not-run: formula-gates · retired-def-refusal · server-timing-admin-gated · route-ledger-live-parity · package-rest-lifecycle · api-console-discovery-execute

Parked-on: #10236 · api-backend.date-range-preset-matrix — clause never states the preset invocation spelling
Parked-on: #10236 · api-backend.batch-transactional-discovery · clause 4 — per-object batch door schema unestablished

Still zero fail across the area.

---

Generated by Claude Code

[os-elon]

Correction — the blocked(fixture) verdict on integration-system.datasource-credential-refusal-matrix's redaction half is withdrawn.

This record concluded that clauses [2] [3] [4] could not be evidenced because both read doors serve only credential-free sqlite datasources, leaving no positive control. #9467 (2026-08-18, subject e4e5c6e3) had already driven those clauses to pass by planting 10 cleartext values across both doors and grepping every response body for them — 0 hits, with hasSecret / redactedConfigKeys distinguishing set from unset. The control is planted, not found; my method was wrong, the fixtures were not missing.

The refusal half recorded here stands (six doors, each naming the offending position).

Its clause c7 — the one this record never reached — was the P0 authentication hole #9391, fixed by PR #9695 and re-verified as fixed on 17.1.0 in #10454.

Superseded-by: #10454 · integration-system.datasource-credential-refusal-matrix · redaction half + c7

---

Generated by Claude Code