test(qa-checklist): record-share-grant-revoke r4 from its first-ever run at 4a7b3604c

[os-warren]

Fixes#9702

The owed follow-up run for access-security.record-share-grant-revoke is done. Run record: #10085 (qa-run). This PR carries only what the run changed in the tree: the item's revision 4. Nothing else from a run lands in the repo, per RUNNER.md.

What the run was

access-security.record-share-grant-revoke was executable for the first time: PR #9697 (#9237) retargeted its evaluate clause off share_red_projects_with_execs, whose evaluate was refused SHARING_NOT_ENABLED because showcase_project is public_read_write. Per #9308's sequencing ruling this is a dedicated run at a new sha on main — it is deliberately not attached to wave #9296's pinned e4e5c6e3 baseline.

• Framework sha run at: 4a7b3604c (both 4012a70cd and 06f9848f9 verified as ancestors)
• Item revision executed: 3 (the revision the resolver reported at run time)
• Verdict: pass — all 7 acceptance clauses passed, reproduced on two independent fresh boots
• Scope: exactly this one item. Widening to 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's newly unblocked items is the wave PM's call, reserved by 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 itself, and was not taken here.

Why revision 4

Two things the first execution paid for, both prose, no acceptance clause changed:

1. The revoke-scope probe was ordered after the real revoke. Clause 6 asks for DELETE through a different record's path to be refused and the share to still exist (re-read). Following the steps literally, the shareId is already gone by then, so the refusal observed is the ordinary missing-share 404 and proves nothing about record scoping — the clause's own evidence requirement is unsatisfiable. The probe now runs while the share still exists, and the note-creation step creates the second record it needs. Run that way the probe is meaningful: 404 NOT_FOUND naming both the share and the wrong record, with the share surviving and still readable by the grantee.

2. The manager-position fixture note now reads correctly against the post-app-showcase: two sharing rules declared on objects without record sharing enabled — boot backfill fails, rules never take effect #9237 seeds. The old text told a runner that grantsCreated 0 means an empty recipient expansion, i.e. a fixture gap. Measured on a stock boot: the seeded dev admin already holds manager (sys_user_positionusp_showcase_admin_manager) and the boot backfill already materialises the grant, so a bare evaluate answers grantsCreated 0 out of idempotence — confirmed directly ({matchedRecords: 1, expandedUsers: 1, grantsCreated: 0} with the row already present). Assigning the position to one more persona is what makes a created grant observable (expandedUsers 2, grantsCreated 1).

Verification

• node scripts/check-platform-checklist.mjs — OK -- 15 areas, 190 items (190 active); coverage: 30 kinds mapped, 0 waived.
• node scripts/check-nul-bytes.mjs — OK (scanned 6367 text file(s) ... no raw ASCII control bytes).
• node scripts/pm/dispatch-gates.mjs — derived from the merge base, this change set matches no path-scheduled check family.
• node scripts/checklist-select.mjs access-security.record-share-grant-revoke --json — resolves at revision 4.

All run at 6a22731ab, the branch head.

No changeset: QA checklist steps are internal test material, nothing user-visible ships from this. Labeled skip-changeset (read back after writing).

Refs: #10085 (the run record) · #9697 / #9237 (made the item runnable) · #9308 (the sequencing ruling) · #9296 (the wave)

---

Generated by Claude Code