QA run · api-backend (8 of 14 items) · e4e5c6e3 · 2026-08-17 · 4 PASS / 4 PARTIAL / 0 FAIL #9333

R3-C round of the #9296 wave. Scope is 8 of the area's 14 items — this is NOT a full-area run; the 6 unreached items are listed as not-run at the bottom rather than quietly omitted.

Headline: zero product defects found. Two would-be failures were disproven before being written down (both are recorded below as checklist-accuracy findings, which is where the real value of this round sits), and two fixture gaps are recorded as blocked rather than scored.

Environment fingerprint

Subject pin vs spec: the checklist was taken forward with git checkout origin/main -- docs/qa/platform-checklist/ only. git status showed only docs/qa/ paths modified and HEAD remained e4e5c6e3…. Nothing committed.

Setup correction (affects the other R3 sessions)

The dispatched setup recipe is incomplete. pnpm exec turbo run build --filter=@objectstack/client... + pnpm objectui:build do not build @objectstack/cli, so packages/cli/dist stays empty and the boot smoke dies with Error: command dev not found. R0 never hit this because turbo run test builds the whole graph incidentally. Fix: a full pnpm exec turbo run build (3m12s warm here) before the first boot. The #9307 workaround itself behaved exactly as documented — stage 1 then objectui:build, both green, stamp matching.

Scope — selector and per-item revision

node scripts/checklist-select.mjs area:api-backend --json → 14 runnable, 0 blocked.

Per-clause verdicts

1. filter-comparand-conformance (rev 1) — pass · 5/5

Matrix pinned to ACCEPTED_FILTER_COMPARAND_TYPES, 6 members, all exercised (not sampled).

Fixture note: the item's declared knownGap (virtual head blocked if no formula field exists) does not apply — showcase_field_zoo carries f_formula (virtual), f_master_detail (relation) and plain scalars, so all three classes were reachable.

Hypothesis raised and disproven (RUNNER rule 5): all 7 structured-JSON dotted heads (f_json.foo, f_location.lat, f_address.city, f_composite.a, f_repeater.a, f_vector.a, showcase_account.hq.lat) are refused 400, even though classifyDottedFilterHead deliberately returns null (unjudged) for them "so refusing it for symmetry would [not] delete a working capability on two of three backends". This looked like the classifier's abstention being defeated. It is not a defect: the refusal comes from a different, separately declared gate — semantic migration driver-sql-unresolvable-where-column-refused (#8790, ruled 2026-08-15), which refuses an unresolvable where-column with INVALID_FILTER/400 on driver-sql specifically. Both contracts hold at once; the capability survives on memory/mongodb. Recorded so the next sweep does not re-derive it.

2. date-range-preset-matrix (rev 1) — pass · 4/4

Matrix pinned to DATE_RANGE_PRESETS, 13 members, all exercised on two objects (26 rows). Literal windows were resolved with the platform's own resolveFilterToken, never a hand-guessed week/quarter convention.

Discrimination honesty (the item's own knownGap): across both objects every preset was answer-discriminating on at least one, except yesterday, which was empty on both — it proved only that the window resolved, not that it selected. Windows are genuinely computed, not aliased: this_quarter/this_year/last_90_days return the whole showcase_task table but differ sharply on showcase_account (1 / 6 / 3).

Checklist note (clause 2's verify names an unobservable oracle): the clause says the message "matches bareDateRangePresetComparandMessage". At the api oracle it cannot — that function serves the authoring doors (data/filter.zod.ts schema door and the @objectstack/lint rule). The live data-API refusal is the engine-door wording (#8690/#8808). The clause's intent is fully met; its stated verify is unreachable from the oracle it declares.

3. retired-def-refusal (rev 1) — partial · 3 pass, 1 blocked

Registry: 54 entries, prefixes 17 and 18. Sampled 5 spanning both prefixes and 4 domains — 18.identity__ApiKey, 17.data__ExternalDataSource, 17.data__ExternalLookup, 17.system__MessageQueueConfig, 17.automation__ETLPipeline (+ the ui/ widget+i18n family via its gate test).

Build-tier evidence for the retirement mechanism: the four dedicated gate tests pass 16/16 (api-key-retirement, external-lookup-retirement, message-queue-retirement, widget-i18n-retirement) — "every retired name has ZERO holders on any public entry", "runtime namespace agrees with the compiler view", "the module is gone from disk".

Why clause 0 is blocked, not failed: the step says "author a stack that declares metadata of each sampled retired type and run os build". Retired defs are schema-definition names (identity/ApiKey, data/ExternalDataSource), not authorable metadata types. GET /api/v1/meta/types returns 34 live types and the overlap with the sampled retired defs is zero, so there is no expressible stack that declares one. The step needs rewriting against the real mechanism (the #4725 manifest-deletion gate over RETIRED_DEFS_BY_MAJOR).

4. query-contract-matrix (rev 1, P0) — partial · 8 pass, 1 blocked

Load-bearing negative (#3899 silent widening) — did NOT reproduce. Four malformed bodies probed; the catastrophic direction (degrading to an unfiltered 200 full read) never occurred: {wibble:{…}} → 400 INVALID_FIELD; {where:"a string"} → 400 VALIDATION_FAILED; bare {where:{status:'active'}} → 200 with 9 correctly filtered rows; {filter:{status:'active'}} → 200 with 9 rows (baseline 14) — i.e. correctly filtered, because filter IS an accepted alias for where in this build. The clause's chosen example key is stale (see findings).

5. bulk-write-contract (rev 1) — pass (automated pin, RUNNER rule 6)

packages/qa/dogfood/test/owner-anchor-and-bulk-writes.dogfood.test.ts → 9/9 passed: member cannot forge another owner on INSERT; may INSERT with self-owner; cannot TRANSFER; cannot DISOWN (owner_id:null); unchanged no-op form echo tolerated; privileged caller with modifyAllRecords CAN reassign; a bulk update whose change-set carries owner_id fails closed for a member; member bulk UPDATE and bulk DELETE each touch only their own rows, never a peer's. Both sides of the gate are covered by the pin itself.

6. declarative-endpoint-execution (rev 1) — pass (automated pin, RUNNER rule 6)

showcase-declarative-endpoints.dogfood.test.ts + declarative-endpoint-policy.dogfood.test.ts → 25/25 passed. Covers both gate sides: omitted authRequired denies anonymous (schema default true) while serving an authenticated caller; explicit authRequired:false serves anonymous and is metered (429 with Retry-After, never a cache directive on the 429, budget per-endpoint not global); object_operation endpoint answers byte-identically to the built-in /data route and 401s anonymous; flow endpoint invokes the real flow over HTTP and 404s on the wrong method; undeclared paths keep the transport's bare 404; /openapi.json documents both declared endpoints and does not document one the runtime would not serve; an ungated direct write never becomes a live route.

7. batch-transactional-discovery (rev 2) — partial · 4 pass, 1 partial

8. error-envelope-ledger (rev 1) — partial · 3 pass, 3 partial

Findings — two checklist-accuracy defects, no product defects

Both of these would have produced a false P1 fail for a runner following the steps literally. Neither is a product bug; both need a checklist edit (revise + bump revision + append history), which this run does not make because nothing from it lands in the repo.

F1 — batch-transactional-discovery steps 2 and 3 prescribe the wrong request shape. The steps say options {"atomic": true} / options {"atomic": false}. The guard reads top-level atomic (packages/rest/src/rest-server.ts:9869: if (parsed.data.atomic === false)). Reproduction of the divergence, on a fresh boot:

• POST /api/v1/batch body {"operations":[{"operation":"create","object":"showcase_task","data":{"title":"x","project":"<id>","status":"todo"}}],"atomic":false} → 400 BATCH_NOT_ATOMIC, writes nothing. (correct)
• Same body with "options":{"atomic":false} instead → 200, and the row is created. (the checklist's spelling; the flag is silently ignored by CrossObjectBatchRequestSchema)

Expected-vs-actual for the item as written: expected 400 BATCH_NOT_ATOMIC, actual 200 + write. Following the step literally reports a P1 contract violation that does not exist. Secondary, milder observation for maintainers: an unrecognised options.atomic is dropped rather than refused, so an author who writes the nested spelling gets atomic semantics silently instead of being told the key is wrong — safe in outcome (the endpoint is always atomic) but it is how the wrong spelling survives in docs.

F2 — query-contract-matrix's load-bearing negative uses a key that is not unrecognised. The negative says a malformed body "(e.g. {"filter": {…}} — not a QueryAST key) must answer 400 VALIDATION_FAILED". Observed: POST /api/v1/data/showcase_account/query with {"filter":{"status":"active"},"top":500} → 200 with 9 rows against a 14-row baseline — i.e. filter is an accepted alias for where and was honoured correctly. The negative's premise is stale. The property it exists to protect is intact and was verified with a genuinely unrecognised key: {"wibble":{"status":"active"}} → 400 INVALID_FIELD. Suggested edit: swap the example key, or assert that filter is a documented alias.

F3 (minor, provenance) — date-range-preset-matrix cites a source path that does not exist. packages/spec/src/data/temporal-comparand.ts is absent at the subject pin and on current main. The real modules are packages/core/src/utils/temporal-comparand.ts (also cited, correctly) and packages/spec/src/data/temporal-conformance.ts. Provenance only — it does not block the item.

Fixture gaps

1. No credentialed non-admin persona in stock showcase seeds. sys_user holds exactly admin@objectos.ai, auditor.demo@example.com, phone.demo@example.com. The seed comments reference ada@example.com under the showcase_contributor permission set, but no such user exists with a usable password (4 candidate passwords all 401). This blocks query-contract-matrix clause 4 (contributor expand RLS/FLS) and error-envelope-ledger's 403 family, and will block every "both sides of the gate" clause in this area that needs an unentitled caller. Worth folding into Land the showcase seed fixtures that unblock the checklist's stock-fixture gaps (loginable 2nd member, publicSharing object, writable summary field, readable:false FLS grant) #9308.
2. showcase_private_note returns 0 rows to the seeded admin, so it is not usable as a batch fixture target.
3. yesterday has no seeded row in any probed object — that preset proved resolution only, not selection.

Not run — 6 of 14 items

Recorded rather than omitted, per the guardrail against faking coverage. None of these were started, so none carries a verdict:

Reproduction rules

No fail verdicts were recorded, so no defect reproduction rule is owed. The two checklist divergences (F1, F2) carry their exact request/response pairs inline above so either can be re-hit on a fresh boot without this run's artifacts.

Parent: #9296.