Checklist accuracy + fixture gaps found by the 17.1.0 post-release sweep (wave anchor)

[os-elon]

Wave anchor for the 17.1.0 post-release QA sweep. Run records are protocol carriers excluded from triage, so the checklist-accuracy findings and fixture gaps they surface would otherwise have no reader. This card is that reader.

Body reconciled 2026-08-20 21:50 before dispatch. The original body carried three claims that the filer later withdrew in comments below (a "missing baseline-member persona", a datasource-credential fixture gap, and an error-envelope-ledger blocker). Reading body-plus-comments was the only way to get the real scope, so the withdrawn items have been removed from the worklist and are summarized under Withdrawn at the bottom for audit. This body is now the spec — the comments are history.

Runs: #10224 · #10225 · #10233 · #10245 · #10248 · #10257 · #10342 · #10454 · #10560.
Subject: framework 19f98fa1, release 17.1.0, showcase, objectui pin 9a3daf8d37ad.
Prior wave (subject e4e5c6e3, 2026-08-18): #9453 · #9467 — their FG-1…FG-7 are the same class of finding and are cross-referenced below.

No product defect was found across any of these runs — zero fail. Everything here is about the checklist and its fixtures, not the platform.

---

A · Checklist edits (checklist-author pass)

Each is a revise + revision bump + history entry, keeping pnpm check:platform-checklist green.

A1 — area:automation has no clause for the trigger/resume HTTP status contract

The lane asserts flow behaviour but never the status a caller observes. 17.1.0 shipped three BREAKING changes on exactly that surface (disabled ⇒ 409 FLOW_DISABLED, no start node ⇒ 422, ran-and-failed ⇒ 400 FLOW_FAILED, each replacing 200 wrapping an inner {success:false}). All three were verified by hand in #10225 and hold — but a regression reverting any of them leaves this area fully green.

Suggested shape: a new item (automation.trigger-status-contract-ish) whose variants matrix derives from the changeset's own status table, covering both trigger routes (POST /automation/:name/trigger and legacy POST /automation/trigger/:name) plus the resume arms (FLOW_FAILED 400, RESUME_IN_PROGRESS 409, INVALID_SCREEN_INPUT 400, STORE_UNAVAILABLE 503).
Known limit: the 422 arm needs a no-start-node flow fixture, which showcase does not have — declare it in fixtures.knownGaps rather than leaving it silently unreachable.

A2 — two RUNNER.md environment facts have drifted

Both still confirm the substantive claim; only the pinned numbers are stale. RUNNER's own instruction is to correct an entry when a run contradicts it.

recorded in RUNNER.md	measured on 17.1.0
bare verify ends ── 15 verified, 0 gaps, 0 FAILED, 1 needs-fixture, 7 skipped	16 verified, same 0 / 0 / 1 / 7 tail (one more object in 17.1.0)
--rls appends 20 PROVEN (20 consistent, 0 HOLES) over 23 objects + 9 of 9 declared position(s) probed	all personas: 38 PROVEN (38 consistent, 0 HOLES) · 226 NOT PROVEN — the counting unit is now one object × persona probe, so the old figure is not comparable rather than merely stale

A3 — api-backend.filter-comparand-conformance clause [2] is untestable through the door it implies

The clause wants a bigint comparand past FILTER_COMPARAND_BIGINT_EXACT_LIMIT (2**53) refused rather than silently losing precision. Through the REST door that is unreachable: the value is rounded during JSON parsing, before the platform sees it, so a 200 there proves nothing. The clause needs an explicit engine/objectql door in its verify, or a door-specific marker.

A4 — platform-core.builtin-apps-nav-render clause [4] has a premise that fails one level up

The clause wants permission-gated entries absent from the member's merged nav. But the member cannot obtain the setup app at all (GET /meta/app?id=setup → 200 {"items":[]}), so there is no member-side Setup nav to inspect. Admin and member account navs are identical (7 vs 7), which proves nothing about gating. Reword for the whole-app-refusal case. Measured in #10257; the prior wave recorded the same shape as a "named limitation" on its own c4 (#9453).

A5 — per-item notes that stop the next runner re-deriving known facts

• chart-type-matrix: record that the four single-value synonyms (kpi/gauge/solid-gauge/bullet) share one renderer, so visually identical tiles are expected, not a defect (QA run · items unblocked by the R-1/R-2 fixes · 4/4 now pass · 19f98fa1 · 2026-08-20 #10560).
• automation.connector-dispatch-matrix: showcase_declarative_connector_ping fails on every record-change firing in a network-restricted runner (connector_action(showcase_status_api.request) failed: fetch failed). Needs a declared stub or a blocked(environment) note.
• platform-core.boot-health [2]: a caller-error refusal logs at ERROR level with a full stack before answering 4xx (measured: a $fn probe → 400 INVALID_FILTER). Any clause grepping the log for ERROR lines must scope to the boot window, or ordinary 4xx traffic reads as a boot failure.
• The 15 items whose automation is pinned in objectui (e2e/live/*.spec.ts, plugin-gantt / plugin-calendar / plugin-grid unit tests): say so on the items. From this repo they are neither pin-evidenced nor drivable, and each runner currently rediscovers that.

---

B · Fixture work

B1 — a contributor-bound member (the one persona gap that is real) — cross-ref FG-4 in #9453

An identity that reads a strict subset of an object's rows. Measured: Mei (phone.demo@) is PERMISSION_DENIED on showcase_invoice (no rows at all); Ada (auditor.demo@) sees all 12. Neither is a subset. The prior wave hit the same wall from a different angle — showcase_account is public_read_write, so no bound persona can fail to read a source row (FG-4).

Blocks: search.rls-both-personas (blocked(fixture), #10257) and records-forms.crud-roundtrip [7] (clone must be refused 404 RECORD_NOT_FOUND for a caller who cannot see the source).

Likely recipe: a fresh sign-up plus a scoped permission-set grant, authored as an area-level provisioning block in the qa-scratch-authz style (see areas/attachments-storage.json) rather than a seed change. POST /api/v1/auth/sign-up/email works on a stock dev boot, so minting the identity is already solved — what is missing is the scoped grant that makes it see a subset.

B2 — Studio is not installed on stock showcase — cross-ref FG-1 in #9453

GET /api/v1/meta/app returns exactly showcase_app, setup, account. platform-core.builtin-apps-nav-render (rev 2) names three built-in apps, so on stock fixtures it can never exceed partial — its c0/c1/c2 are blocked(fixture) for this one reason. The prior wave already walked everything reachable: Setup 43/43 and Account 7/7 destinations, 50/50 ok, zero pageerror (#9453). There is nothing left to test here; there is a decision to make.

PM ruling (falsifiable premise — report a fork rather than forcing it): reword the item to the apps a stock boot actually registers, and record the Studio carve-out in fixtures.knownGaps. Premise: Studio is deliberately not installed by the showcase, i.e. its absence is a product choice about what the demo app demonstrates, not an oversight. Verify that premise first (packages/platform-objects/src/apps/studio.app.ts exists and is registered as a one-app package, but examples/app-showcase does not install it — confirm this is intentional). If the absence turns out to be an oversight, do not silently reword: stop and report the fork, because installing Studio changes what the showcase demonstrates and that is the maintainer's call, not this card's.

B3 — automation.connector-dispatch-matrix network dependency

Covered as a per-item note in A5; listed here too because the durable fix may be a fixture (a declared stub) rather than a note.

---

Withdrawn (audit trail — do NOT work these)

Struck by the filer's own corrections, in comments below. Listed so nobody re-derives them from an older revision of this body.

1. "A baseline-member persona is the single highest-leverage missing fixture" — wrong twice. examples/app-showcase/src/security/demo-personas.ts declares two loginable non-admin personas (Mei, Ada; password showcase123, DEMO_PERSONA_PASSWORD), and beyond them POST /api/v1/auth/sign-up/email mints identities per run. What survives is narrower: B1 above.
2. "error-envelope-ledger clause [5] cannot reach pass on stock fixtures" — the 403 family is reachable: driven as Mei, POST /api/v1/data/showcase_announcement → 403 PERMISSION_DENIED, a ledgered code. That item is pass (6/6 families). Its fixtures.requires should name the demo personas so the next runner does not repeat the mistake — that line is the only surviving work, folded into A5.
3. "datasource-credential-refusal-matrix cannot prove its redaction half on stock showcase" — method error, not a fixture gap. QA run · tier2c:browser-2 (18/18) · e4e5c6e3 · 2026-08-18 · 10 PASS / 4 PARTIAL / 4 FAIL #9467 drove those clauses to pass by planting 10 cleartext values across both read doors and grepping every response body (0 hits). The control is planted, not found.

Also for the wave, not a work item: Playwright still needs an explicit executablePath on these containers (playwright-core 1.62.1 resolves chromium 1234, only 1194 installed; examples/app-showcase/playwright.config.ts sets none). RUNNER already records this — noted only to confirm the entry held on 17.1.0 and should not be pruned as stale.

Process finding (for whoever maintains the QA protocol)

Duplicate-check before filing must include CLOSED qa-run records. Six of the 2026-08-20 records were filed without consulting the 24 pre-existing ones, because the check listed qa-run issues with state:OPEN and the 2026-08-18 wave records were closed. Reading them first would have retired a planned target list, supplied six higher-value targets, and caught withdrawn-item 3 above before it was filed.

[os-elon]

Correction — the "no baseline-member persona" gap in this card is wrong. Withdrawing it.

The body claims stock showcase gives a runner only the seeded dev admin. That is false. examples/app-showcase/src/security/demo-personas.ts declares two loginable non-admin personas, provisioned by seed-approval-demo.ts on every dev boot:

persona	email	password
Mei Phone (demo)	phone.demo@example.com	showcase123 (DEMO_PERSONA_PASSWORD)
Ada Auditor (demo) — holds only the auditor position	auditor.demo@example.com	same

All three identities were verified to sign in against POST /api/v1/auth/sign-in/email on this boot. The password is well-known on purpose and documented as such in that file.

What that changes:

• The 403 authorization family in api-backend.error-envelope-ledger clause [5] is reachable after all. Driven as Mei: POST /api/v1/data/showcase_announcement → 403 PERMISSION_DENIED, a ledgered code. That item is now pass (6/6 families), not partial — QA run · area:api-backend · 5/14 · 19f98fa1 · 2026-08-20 #10233's verdict is superseded on that point.
• Section 4 of this card ("clause [5] cannot reach pass on stock fixtures") is withdrawn. What the item does need is a line in fixtures.requires naming these personas, so the next runner does not repeat my mistake of assuming they are absent.

What it does NOT change — records-forms.crud-roundtrip clause [7] is still unverified, for a different reason than I first recorded. That clause needs a persona that cannot read the source row (expecting 404 RECORD_NOT_FOUND from the null findOne). Mei can read showcase_account (measured: 200), so her clone attempt is refused 403 PERMISSION_DENIED for a missing create grant — a different gate. Verifying clause [7] needs a permission-zoo persona without read on the row, or an owner-RLS object with a non-owner caller. The gap is real; my description of it was not.

Also measured while establishing this: showcase_account reads identically (15 rows) for admin, Mei and Ada — it is public_read OWD — and showcase_private_note is an empty table for everyone. Neither is usable as a both-sides RLS control, which is worth knowing before someone reaches for them.

---

Generated by Claude Code

[os-elon]

Second correction to the fixture section — the persona gap is retired entirely.

POST /api/v1/auth/sign-up/email works on the stock dev boot. Three usable identities were minted in one call each (#10257). So the bullet in the body calling a baseline-member persona "the single highest-leverage missing fixture" is wrong twice over: the seeded personas exist (first correction, above), and where they do not fit, a runner can mint identities per run rather than waiting for a seed change.

Concretely unblocked: every both-sides clause that was waiting on a second or third identity. access-security.record-share-grant-revoke was driven end to end on minted A/B/C and passed 6/7 (#10257).

What remains genuinely missing is narrower and should replace the old bullet:

A contributor-bound member — an identity that reads a strict subset of an object's rows. Measured: Mei is PERMISSION_DENIED on showcase_invoice (no rows), Ada sees all 12. Neither is a subset. search.rls-both-personas needs this and stays blocked(fixture). The recipe is likely a fresh sign-up plus a scoped permission-set grant, authored as an area-level provisioning block in the qa-scratch-authz style.

Also for this card, from the same run:

platform-core.builtin-apps-nav-render clause 4 — the clause asks for gated entries to be absent
from the member's merged nav, but the member cannot obtain the setup app at all (200 items:[]).
The premise fails one level up; the clause needs rewording for whole-app refusal.

---

Generated by Claude Code

[os-elon]

Third correction — strike the datasource-credential fixture gap. It was my error, and this card is now queued, so it would otherwise become someone's build task.

The body's Fixture-gaps section says integration-system.datasource-credential-refusal-matrix "cannot prove its redaction half on stock showcase" and asks for a credential-bearing datasource to be provisioned. Withdrawn.

#9467 (2026-08-18, subject e4e5c6e3) drove those exact clauses to pass — c2, c3, c4, c5, c6 all green — by planting 10 cleartext values across both read doors (config-key, URL userinfo, URL query-param, mongo driver-options, placeholder, connector inline auth; plus legacy aliases passwd/pwd/authtoken and an unknown-driver cockroachdb key) and grepping the full response bodies for every planted value: 0 hits on both doors.

My reasoning was that stock showcase carries only credential-free sqlite datasources, so there is no positive control. That is true and irrelevant — the control is planted, not found. The three inline-credential doors refusing my probes is what the item is about; the credentialsRef path and the metadata door are how a value gets planted anyway. This was a failure of method on my side, not a gap in the fixtures.

Net effect on this card's scope: the "credential-bearing datasource" item in the fixture half should be dropped. What survives from that section is unchanged — the contributor-bound member recipe, the Studio carve-out decision, and the per-item objectui-pin notes.

Also for this card, a process finding from the same round:

Prior-run duplicate check must include CLOSED qa-run records. Six of my seven records on
2026-08-20 were filed without consulting the 24 pre-existing ones, because I listed
qa-run issues with state:OPEN and the 2026-08-18 wave records (#9453, #9467) were closed.
Reading them first would have retired my planned target list, supplied six higher-value
targets, and caught the wrong verdict above before it was filed.

Full re-verification and evidence: #10454 — all six failures from that wave are fixed on 17.1.0.

---

Generated by Claude Code

[os-elon]

Claim: PM loop — maintainer direct-dispatch channel
Session: session_01HFdDHyLhGfbBnWpgdxu6Rq
Branch: claude/issue-10236-qa-anchor-checklist-edits
Worktree: objectstack-issue-10236
Domain: domain:devx
File surface: docs/qa/platform-checklist/** (areas/*.json · RUNNER.md · coverage.json) — stop on breach; explain in the report
Container & model: M, mode:subagent, model: opus
Clause-②: no — this card edits the QA ledger and its runner protocol only. It does not touch packages/spec/src/**, does not change any contract's accept/reject behaviour, and does not widen a public surface.
Serial constraints cleared: none blocking. Checked without the GitHub API (see note): the only remote claude/* branch whose history touches docs/qa/platform-checklist is claude/issue-9863-audit-plugin-boot-options, and its single touching commit is a6ae14b64 Merge branch 'main' into … — a merge bringing main's changes along, not an edit of this surface. No in-flight branch is authoring here. origin/main is active on this path (#10412, #10346, #10147 most recent), so the dev must rebase/merge main before opening the PR and re-check pnpm check:platform-checklist after.

Authorization. Dispatched under the maintainer direct-dispatch channel, on this instruction verbatim:

10236 你直接接手派发。

Scope is exactly this card; no other card is routed on this authorization.

Note on this claim's own hygiene. The assign + label flip landed first, then the GitHub API returned rate limit already exceeded before this comment could post, leaving the atomic pair half-written for a few minutes. It is closed now by this comment. The serial-constraint reading above was taken from local git rather than the API for the same reason — it is a stronger reading than the API would have given anyway, since it inspects actual commits on the branches rather than issue labels.

Body reconciled before dispatch. Three claims in the original body were withdrawn by later comments; a dev reading only the body would have built two things that are not needed. The body has been rewritten so it is the spec on its own, with the withdrawn items kept at the bottom as an audit trail. The comments above are history, not instructions.

---

Generated by Claude Code