qa(checklist): api-backend — 28 ledger edits from the 18.2.0 release sweep (#25807) #25837

Filing gate: maintainer-directed task. Filed by the 18.2.0 release-assessment thread · session_01G3h9iZTpL8aCiXbfsp8H5u. ⛔ Not a claim, ⛔ not dispatched.

Maintainer's words (project thread, 2026-10-25, verbatim): 22:54Z 「约 300 条清单准确性问题：是不是应该开卡？」, then 22:55Z 「写issue，不派发」.

Parent: wave anchor #25807 (18.2.0 release test sweep). RUNNER's extraction obligation parks checklist-accuracy findings on the anchor; the maintainer asked for them as issues, so the wave's findings are split into one card per ledger file and the anchor links each card. This is not a release blocker, so it carries no target:v18.

Reader who acts: the lane owning docs/qa/platform-checklist/** (domain:devx). Dedupe (open and closed): no card holds these lines; the 18.0 precedent closed its accuracy rows on its anchor #24579.

Wanted

For each line below, edit docs/qa/platform-checklist/areas/api-backend.json: revise the item's text, bump its revision, and append a history entry citing the run record the line comes from. Keep pnpm check:platform-checklist green. A line that turns out to describe a product defect rather than stale text gets its own card instead of a ledger edit.

Findings (28)

From #25815 — release-18.2.0-tier1, 156 items, at 6679644a, pin b41ed7f68956 (clause labels: aK = acceptance[K], nK = negative[K])

• api-backend.action-activation-door-contract a6: ref/verify says 'both owners named'; the ambiguity case asserts only messageOf(res) toContain('crm_account')
• api-backend.action-activation-door-contract a5: ledger-reach asserts the key set via rows.find, never that exactly one row exists, and does not read the 200 body {name, objectName, enabled}
• api-backend.action-activation-door-contract a2: ref claims 'unknown-key/non-boolean 400s' — pin asserts code VALIDATION_FAILED only, not fields[0] unknown_field/invalid_type or the non-object-body arm
• api-backend.bulk-write-contract ref '(bulk halves)' overclaims: the pin's bulk cases call ql.update/ql.delete({multi:true}) on the engine with a resolved authz context; none of the createMany/updateMany/deleteMany HTTP doors the clauses name is driven, so no clause a0-a5/n0 is asserted
• api-backend.bulk-write-contract a3: packages/rest/src/rest-batch-size-cap.test.ts pins BATCH_TOO_LARGE at the unit layer (mock protocol) and is not in this item's ref; it still would not score an api oracle
• api-backend.data-request-shape-and-query-arity a1-a4: every pin invokes RestServer route handlers / HttpDispatcher.dispatch directly (real ObjectQL+SqlDriver for data-write-request-gate, data-delete-expected-version, data-conflict-caller-visibility; stubs for the arity files) — none boots the Hono adapter, so the api-oracle clauses stay a live leg
• api-backend.data-request-shape-and-query-arity a1: the empty-version-token leg is in data-delete-expected-version.test.ts (DELETE), while the clause speaks of PATCH bodies + an empty version token — check the clause intends DELETE for the token
• api-backend.declarative-endpoint-execution a1: no pin asserts the 401 body's code (UNAUTHENTICATED); showcase case checks success:false only, policy case status only
• api-backend.declarative-endpoint-execution a2: spec gate (a) asserts the fix sentence but not that the message names the endpoint; the api 注册表条目声明 allowRuntimeCreate: true,但运行时创建的端点匹配器永远看不见 —— 声明的能力运行时不兑现(真实 boot 实测) #5488 runtime-authoring withdrawal is unasserted; the build oracle's os validate/os build run is not a pin
• api-backend.error-sentences-and-unique-violation-wire-code a1: the verify names rest-hook-script-fault-envelope.test.ts for the 'live /data door' — that file imports mapDataError only, so the live leg is unit, not the door
• api-backend.error-sentences-and-unique-violation-wire-code a2: dispatcher-unique-violation-wire-code.test.ts uses a real engine + SqlDriver behind HttpDispatcher; no Hono adapter, so the wire body is the dispatcher's result, not an HTTP answer
• api-backend.meta-read-doors-v18 a4: no ref pin asserts the data-sort 403 on F (the 'two agree' half); showcase-fls-read-mask-strip.dogfood.test.ts has a sort-403 case but is not in this ref
• api-backend.meta-read-doors-v18 a1-a3: precedent QA run · tier1:24681-touched (63/82) · 307ce4c4 · 2026-10-20 · 10 PASS / 53 PARTIAL / 0 FAIL / 0 BLOCKED / 19 NOT-RUN #24840 carried these as pass from QA run · surface:api (116/130) · 580fd4ed · 2026-10-20 · 62 PASS / 54 PARTIAL / 0 FAIL / 0 BLOCKED / 14 NOT-RUN #24779; on this tree every ref pin drives route handlers with a stub server/response (no Hono adapter), so they score a0 only
• api-backend.packaged-action-disabled-dispatch a0: dogfood asserts status 409 and text toMatch(/ACTION_DISABLED|is disabled/) — neither the exact code nor the describeDisabledAction sentence, and no task re-read for side effects; the exact sentence is unit-only (action-activation-dispatch.test.ts › the shared guard itself › answers 409 ACTION_DISABLED with the ENGINE's own sentence)
• api-backend.packaged-action-disabled-dispatch a3/a6/n1: ref credits action-activation-dispatch.test.ts for the 403-not-an-oracle, flow-type and absence-means-active legs, but it is a unit HttpDispatcher over fakes — it stops above the HTTP layer the api oracle needs
• api-backend.packaged-action-disabled-dispatch a5: ref correctly says the restart leg stays manual
• api-backend.query-contract-matrix a4: engine.test.ts '[Security: $expand bypasses RLS/FLS on the referenced object (data leak on lookups) #2850] routes the expand sub-read through the middleware … tagged __expandRead' proves the sub-read is routed through middleware on a mock driver — not that a contributor's expand withholds the contact over HTTP; under rule 6 it cannot score a4 (round 4 QA run · tier1:24681-touched (63/82) · 307ce4c4 · 2026-10-20 · 10 PASS / 53 PARTIAL / 0 FAIL / 0 BLOCKED / 19 NOT-RUN #24840 scored it pass)
• api-backend.query-contract-matrix n0: request-schema-gate.conformance.test.ts drives RestServer with a mocked protocol — the ref says so itself
• api-backend.query-contract-matrix whole item: Tier 1 in name only — no clause has a pin at its oracle's layer
• api-backend.rest-batch-config-contract a5: rest-sub-config-parse-not-cast.test.ts §E › 'refuses batch.operations.upsertMany and batch.defaultAtomic' asserts the key and /never built/ resp. /options.atomic/; it does not assert that the messages name BatchEndpointsConfigSchema, nor the upsert replacement (an operation type of the generic batch door)
• api-backend.rest-crud-config-contract a3: packages/rest/src/discovery-services-route-follows-mount.test.ts ('[finding] discovery contradicts itself under a non-default crud.dataPrefix: routes.data follows the key, services.data.route stays hard-coded at /api/v1/data #16674 — a moved crud.dataPrefix moves BOTH halves of the document') pins the discovery-advertisement half at a non-default prefix and is not in the ref; the moved-route-table half has no pin.
• api-backend.rest-crud-config-contract a4: ref says §E pins acceptance[4]; the case asserts 'crud.patterns' + 'CrudEndpointsConfigSchema' + /was removed in @objectstack/spec 17/ only — the declarative-api-endpoint prescription is never matched, and the objectParamStyle refusal is checked for its key and /was removed/ only.
• api-backend.rest-metadata-config-contract a1: ref says §D 'pins prefix … survival' — true, but no pin mounts at prefix '/metadata' or reads the discovery body's routes.metadata; the clause's move-together claim is unpinned
• api-backend.rest-metadata-config-contract a5: §E's cacheTtl case asserts the key, MetadataEndpointsConfigSchema and /was removed/; the endpoints.schema case asserts the key and /does not exist/ only — neither asserts the replacement named in the verify
• api-backend.rest-metadata-config-contract a3: only the normalizeConfig half is pinned; ref concedes the masking-effect half has no pin
• api-backend.rest-route-generation-tombstones a0: §E › 'refuses every routes.* key' asserts routes.<key>, RouteGenerationConfigSchema and /was removed/ — not the clause's 'was removed in @objectstack/spec 17'; nameTransform driven with 'none' only (ref concedes)

From #25817 — release-18.2.0-manual-set, 29 items, at 6679644a, pin b41ed7f68956

• api-backend.aggregate-contract-matrix: The analytics: the in-memory date bucket shifts a timezone-naive Field.date one day EARLIER under any negative-offset timezone (America/New_York → 2026-10-01 buckets as 2026-09-30), so it disagrees with the SQL pushdown path #24618 negative-offset shift no longer reproduces; the item text can say it is fixed.
• api-backend.formula-stdlib-matrix steps[5] / requires[1]: a scratch object without sharingModel gets 422 security-owd-unset. The step should say to declare one.

Acceptance

• Every line above is either applied (item revised, revision bumped, history cites the record) or answered on this card with the reason it was not.
• pnpm check:platform-checklist is green.
• The PR links this card and [sweep] v18.2.0 release test sweep #25807.

Generated by Claude Code