QA run · 17.1.0-touched × unadjudicated × P0/P1 · 3/70 · 19f98fa1 · 2026-08-20

[os-elon]

Sixth run of the 17.1.0 post-release sweep, and the first driven by a computed target list rather than a checklist selector: items whose source[] the 17.0.0 → 17.1.0 diff touched, and that no earlier run adjudicated, and P0/P1, and not standing-blocked. That intersection is 70 items (browser 17 · api 16 · mixed 35 · build 1 · cli 1).

Companions: #10224 · #10225 · #10233 · #10245 · #10248. Anchor: #10236.

Prior art: #10085 ran access-security.record-share-grant-revoke on 4a7b3604 earlier today — before the 17.1.0 tag. This run re-drives it on 19f98fa1 (the released build), so the two are different subjects rather than duplicated work. Both green.

Environment: framework 19f98fa1fffbeb305bdcb6af64bc826fb25a46b1, objectui pin 9a3daf8d37ad, showcase on 3456 against a file DB. Execution mode: SEQUENTIAL, declared.

The headline is a fixture unblock, not a verdict

POST /api/v1/auth/sign-up/email works on the stock dev boot. Three fresh identities, one call each, immediately usable:

qa-share-A-…@example.com → G3rH3mNVJXNtIYYZqvAjqRHjcN59tuUb
qa-share-B-…@example.com → 2Ror8jBHG45h0AbGjmfpqgJ7eyGHgKvB
qa-share-C-…@example.com → 4IT86srdzsUnW0FIRWmQrimIiz4eIVA3

This retires the "no suitable persona" gap recorded on #10236 (already corrected once there). A runner does not need a seeded persona with the right bindings — it can mint identities per run. Every clause blocked on "needs a second or third identity" is reachable this way, which covers a large share of the both-sides clauses across access-security, approvals and identity-auth.

The two seeded demo personas are still what they are, now measured on both:

identity	showcase_invoice visibility
Mei (phone.demo@)	PERMISSION_DENIED — refused at RBAC, no rows at all
Ada (auditor.demo@)	all 12 rows — fully entitled
dev admin	all 12 rows

So search.rls-both-personas (rev 3) stays blocked(fixture): it needs a contributor-bound member seeing a strict subset, and neither seeded persona is that (one refused outright, one fully entitled). Its fixtures.requires describes that binding; nothing provisions it. A fresh sign-up plus a scoped permission-set grant is the likely recipe — worth authoring as an area-level provisioning block in the qa-scratch-authz style rather than rediscovering it next sweep.

Per-item verdicts

item	rev	verdict
access-security.record-share-grant-revoke	4	pass 6/7
platform-core.builtin-apps-nav-render	2	partial 2/7
search.rls-both-personas	3	blocked(fixture)

access-security.record-share-grant-revoke — full share lifecycle, green

Three minted identities on showcase_private_note (private OWD).

clause	verdict	measured
[0] pre-grant isolation	pass	B's by-id GET of A's note → 404 RECORD_NOT_FOUND — not-found rather than 403, so the gate does not leak the row's existence
[1] grant lands as a share row	pass	POST .../shares → 201, shr_6272a4a8-ce7a-47df-8976-9f3d518eec27
[2] grant widens both ways, stays scoped	pass	B by-id 200 and the row appears in B's list; ungranted C still 404
[3] shares list is management-gated	pass	A lists the shares, B is in them; B POSTing a share for C → 403 PERMISSION_DENIED — a reader cannot re-grant
[4] revoke retracts access	pass	DELETE → 204, B's next by-id → 404 again
[5] revoke is record-scoped	pass	deleting that shareId through the second note's path → 404 NOT_FOUND
[6] sharing-rule evaluate reconciles the audience	not-run	needs the manager position assigned first

Access appears exactly when the share exists, only for the named recipient, and only through the owning record's path.

platform-core.builtin-apps-nav-render — api half

clause	verdict	measured
[1] served merged nav matches the authored shell	pass	setup → 43 nav entries, account → 7, studio → items: [] (not installed on showcase — consistent with RUNNER's standing fact)
[3] the app-level gate is server-side	pass	member GET /meta/app?id=setup and ?id=studio both answer 200 with items: [] — the server empties it, not the client
[4] gated entries absent from the member's nav	not-run — the clause's premise does not hold	it wants gated entries missing from the member's merged nav for that app, but the member cannot obtain the setup app at all (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. The clause needs rewording for the case where the whole app is refused one level up
[0] [2] [6]	not-run	screenshot oracles — browser walk not driven this round
[5] service/object-gated entries resolve to absence	not-run

Gaps for the anchor

Parked-on: #10236 · sign-up works — the "no baseline-member persona" gap is retired (second correction on that card)
Parked-on: #10236 · search.rls-both-personas — needs a contributor-bound member; neither seeded persona qualifies
Parked-on: #10236 · platform-core.builtin-apps-nav-render clause 4 — premise fails when the app itself is refused; clause needs rewording

No fail in this run either. 67 of the 70 computed targets remain.

[os-elon]

Round continued — 5/70 now adjudicated. Two more items driven, both api-surface, both using the minted identities.

platform-core.docs-audience-gate (rev 1) — partial 3/7

The installed corpus is one book: showcase_manual, audience: "public". That thinness caps what the item can reach here, but a clean three-way control was still possible because the implicit book is a non-public book:

request	anonymous	admin
/meta/book/showcase_manual/tree (declared public)	200	200
/meta/book/com.example.showcase/tree (implicit per-package)	401	200
/meta/book/definitely_not_a_book_xyz/tree (unknown name)	401	200

• [0] pass — anonymous against a non-public book is refused, and the public book answering 200 anonymously is the control proving the 401 is audience-driven, not a blanket anonymous deny
• [1] partial — the public and org/unset branches both hold; the { permissionSet } branch has no fixture in this corpus
• [5] pass — an unknown book name resolves as the implicit per-package book (200 for admin, not 404) and that implicit book behaves as audience: org (401 anonymous), which is the clause's full second half
• [2] [3] [4] [6] not-run — one public book cannot exercise per-entry filtering, orphan exposure, permissionSet fail-closed, or locale resolution

Fixture note for the anchor: this item needs a corpus with at least one org book, one {permissionSet} book, and a doc carrying translations. Stock showcase has none of those.

identity-auth.self-service-password-reset (rev 1) — partial 2/5

Driven against a minted identity (qa-share-C-…@example.com).

clause	verdict	measured
[4] request does not leak account existence	pass	the known-account and unknown-account requests are byte-identical: 200 {"status":true,"message":"If this email exists in our system, check your email for the reset…"}. Anti-enumeration holds
[3] a tampered token is refused loudly	pass	garbage token → 400 INVALID_TOKEN, and the old password still signs in afterwards — the refusal did not half-apply a reset
[0] the request produces a real reset artifact	partial	the endpoint answers with the non-committal shape, but no token is observable from this runner
[1] the token completes the reset	blocked(environment)
[2] a consumed token cannot be reused	blocked(environment)

The blocker is concrete and worth recording on the item: the dev boot registers no email transport (Auth: no email service registered — transactional mail disabled, observed in the boot banner), and the server log carries zero reset-password/<token> links. Step 1 of the item says to "capture the reset email at the dev mail transport (LogTransport)" — that transport is not wired on a stock objectstack dev boot, so the step cannot be followed as written. Either the item declares the env needed to enable it, or clauses [1] [2] are marked door-specific.

Parked-on: #10236 · platform-core.docs-audience-gate — corpus has one public book; org / permissionSet / translations branches unfixtured
Parked-on: #10236 · identity-auth.self-service-password-reset — step 1 assumes a dev mail transport that a stock boot does not register

Still zero fail across all six runs.

---

Generated by Claude Code