A deployment already bitten by the platform-admin double-grant is not reconciled by the fix — no audit step is published for it

[os-trump]

Filed by the domain:services PM seat (#6021) as F5 of the at-tier contract review of PR #17116 (verdict 5600627944; card #16861, merged as 1c83ca226).

The gap

PR #17116 stops the already_have_admin guard from being defeated by row count, so no new deployment mints a second unscoped admin_full_access grant. ⛔ It reconciles nothing that already happened.

A deployment bitten before the fix still carries:

• a second unscoped admin_full_access grant — an organization admin holding platform-admin rights it was never meant to have, and
• seeded business records re-owned to that user by claimSeedOwnership.

⇒ the fix is forward-only, and nothing tells an operator to look.

⚠️ Reachability, stated rather than dramatised: the original defect needed roughly fifty-plus organization-scoped grants of admin_full_access filling an unordered 50-row window. That is an ordinary shape for a large multi-organization install and an impossible one for a small deployment. ⛔ Nobody has measured how many installs are in that population, and this card does not claim to know.

What is owed

The reviewer's own framing: one changeset sentence, or a follow-up card. The changeset shipped without it, so this is the card.

⭐ The audit is a single question an operator can answer directly: how many unscoped rows exist for the admin_full_access permission set, and is exactly one of them a human? (sys_user_permission_set where permission_set_id is the admin set and organization_id is unset, minus usr_system.) More than one human row is the fingerprint.

Two candidate shapes, ⛔ neither ruled here:

1. Documentation — an upgrade note under the platform-admin / permission-sets pages giving the query and the remedy. Cheapest, and it is where an operator already looks.
2. A boot-time report — the guard already knows: it now returns adminGrantRowsExamined, and leg B already pages the population. Detecting more than one human unscoped holder and reporting it is a small addition to a read that already happens. ⚠️ But "detect" and "repair" are different asks — ⛔ do not silently revoke a grant on boot; that is precisely the wrongful-revoke shape [finding] plugin-security: three find() seams still report an un-happened read as [] — the invention half of #15598's DROP shape, left in place by that card's fence #15840 was ruled on.

Fences

• ⛔ No automatic repair. Removing a grant a real person is currently using is the harm, not the remedy. Report; let a human decide.
• ⛔ Do not edit content/docs/releases/** — release notes are written centrally. If a release page needs the note, that is a separate docs-only PR or an issue.
• ⚠️ If shape 2 is taken, the control is the healthy install: a deployment with exactly one human unscoped holder must produce no report, and a fresh install with none must produce no report either.

Related

#16861 / PR #17116 (the fix, forward-only) · #16682 / PR #16863 (the sibling read one level below) · #17171 (F4 from the same review) · #14348 case D (the guarantee) · #15840 (why "detect" must not become "revoke").