QA run · access-security.record-share-grant-revoke · 1/1 · 4a7b3604 · 2026-08-20 #10085

Dedicated follow-up run owed by #9702. The item became executable for the first time when PR #9697 (#9237) retargeted its evaluate clause; per #9308's sequencing ruling this is a run at a NEW sha on main, deliberately not attached to wave #9296's pinned e4e5c6e3 baseline.

Item verdict: pass — 7 of 7 acceptance clauses passed, reproduced on two independent fresh boots.

Environment fingerprint

Scope

Selector access-security.record-share-grant-revoke — resolved by node scripts/checklist-select.mjs to exactly 1 runnable item, P1, surface api, revision 3.

⛔ Deliberately not widened to #9308's newly unblocked items (approvals.per-group-signoff, approvals.viewer-gating-submitter-side, approvals.ooo-delegation-reroute, access-security.share-link-capability-tokens, access-security.fls-mask-and-strip). #9702 reserves the combine-or-not decision for the wave PM in its own words; taking it here would be a decision this seat does not hold. See "Open for the wave PM" below.

Per-clause verdicts (revision 3)

Oracle for every clause is api — live server traces against a real boot. No screenshot or DOM was consulted; none was needed.

Supplementary, beyond the clauses: persona B, once holding manager, reads the matched contact GET /api/v1/data/showcase_contact/WJ5Cot2OydOKqqYu → 200, where the same read answered 403 before the assignment+evaluate. The rule-materialised grant is one the read gate actually consults end to end — not merely a row in a table.

Reproduction

No fail, so no reproduction rule is owed. Both boots ran the identical sequence and agreed clause for clause:

• boot A (3702): note Nlji2uPrSLttIcwJ, second note gDsNat3RCg1Ilp1T, share shr_2bdd3fd4-f00d-4cc2-8b45-ecde7fde39ff, rule row srule_bae1c31a-730e-4114-b945-e0747a7427c9
• boot B (3703): note YU4FbwJcDP61GmvX, second note Wmy4HDQnMbivIls_, share shr_6115174c-faa0-4b22-bdd0-371b25953c6d, rule row srule_ee5195ce-7914-4693-8677-41a6f36c6cdf; evaluate → {matchedRecords: 1, expandedUsers: 2, grantsCreated: 1}, same shape.

Checklist-accuracy findings → item revised to 4 (PR #10083)

Neither is a product defect; both are the checklist being wrong about itself, found the only way they could be — by executing the item.

1. Clause 6's evidence requirement was unsatisfiable in the steps' own order. The steps put the revoke-scope probe after the real revoke, but the clause asks for the mis-scoped DELETE to be refused and the share to still exist (re-read). Once the share is revoked the shareId is gone, so the refusal a literal runner observes is the ordinary missing-share 404 — indistinguishable from a correct record-scope refusal, and proving nothing. This run reordered the probe ahead of the revoke, which is what made clause 6 measurable at all; revision 4 writes that ordering into the steps and adds the second note the probe needs.

2. The manager-position fixture note now mis-teaches. It says a grantsCreated 0 reconcile means an empty recipient expansion, i.e. a fixture gap. Measured on a stock boot at this sha, that reading is wrong: the seeded dev admin already holds manager (sys_user_position row usp_showcase_admin_manager) and the boot backfill already materialises the grant, so a bare evaluate answers grantsCreated 0 out of idempotence. Confirmed directly — an evaluate run before assigning any extra persona returned {matchedRecords: 1, expandedUsers: 1, grantsCreated: 0} with the rule-sourced row already present from boot. Revision 4 says so and points the runner at expandedUsers/matchedRecords instead.

Neighbouring ground — observed, not chased

#9702 is explicit that these are "nobody has looked since the fixtures moved", not assertions that anything is wrong. Recorded and left alone:

• sys_sharing_rule seeds 2 rows at this sha (share_new_inquiries_with_field_ops, share_key_account_qualified_contacts_with_managers), and a stock boot materialises 1 rule-sourced sys_record_share — on showcase_contact (Nora West) to the seeded admin. Matches what Follow-up run: access-security.record-share-grant-revoke becomes runnable for the first time when #9237 lands — it needs a dedicated run at a new sha #9702 and the PM's comment describe; no anomaly.
• The SHARING_NOT_ENABLED boot-backfill warning is gone. No boot in this run logged a "boot rule backfill failed" line for any rule — consistent with the two inert rules having been retired by fix(app-showcase): retire the sharing rules no gate can consult, keep the demo where it enforces #9697.
• The only boot warning at this sha is the pre-existing showcase_field_zoo.f_autonumber tenancy-split diagnostic, which names its own tracking id (Seed loader writes untenanted rows while the REST path stamps an organization — one single-tenant install runs two autonumber scopes and mints duplicate business identifiers, silently (17.0.0 GA) #8686) in the message. Unrelated to sharing; not new; nothing extracted.

Environment notes (cost this run a cycle each; no card owed)

• os dev has no --no-ui flag. objectstack dev --no-ui exits with Error: Nonexistent flag: --no-ui and prints usage — which, backgrounded, looks exactly like a server that booted and then died silently. RUNNER.md's absence-inference row documents --no-ui for serve, and the distinction is easy to carry across. Omit it on dev.
• The CLI entry point is packages/cli/bin/run.js, not packages/cli/dist/index.js. Invoking the dist entry directly exits 0 with zero output — a silent no-op that reads like a crashed boot. Use node_modules/.bin/objectstack (or pnpm exec).
• $select on the data API takes a comma-separated field list; a JSON array is rejected with INVALID_FIELD. $filter, by contrast, must be JSON.

Close-out

No product defect was observed, so nothing is extracted. The two checklist-accuracy findings are closed by PR #10083 (revision 4) rather than parked, since they are edits to this very item and §3 of the runner playbook puts that on the runner.

Parked-on: #9296 · the #9237/#9308 seed moves leave neighbouring items unlooked-at; the widen-or-combine call is the wave PM's

Open for the wave PM

Both #9237 and #9308 have landed, and #9308 revised five further items whose fixtures moved on the same tree. #9702 reserves the combine decision explicitly ("that is the wave PM's call, not this seat's"), so this run stayed at the stated minimum of one item. If a combined round is wanted, those five plus this one are one tree at one post-#9789 sha — this run's environment recipe above is reusable as-is.

Refs: #9702 (the card) · PR #10083 (revision 4) · #9697 / #9237 · #9308 · #9296

Generated by Claude Code