Filed by the domain:services PM seat (#6021) as F4 of the at-tier contract review of PR #17116 (verdict 5600627944, re-pinned at 5602846866; card #16861, merged as 1c83ca226), which named it "suggest a follow-up card".
The mechanism
packages/plugins/plugin-security/src/bootstrap-platform-admin.ts:206-223:
async function tryFind(ql, object, where, limit = 100, orderBy?, offset?) {
try {
…
return Array.isArray(rows) ? rows : [];
} catch {
return []; // ⇐ any refusal, silently
}
}On the already_have_admin guard, [] reads as "no platform admin exists yet" — which promotes, mints an unscoped admin_full_access grant, and lets claimSeedOwnership re-own the seeded business records.
⭐ What PR #17116 changed about the exposure, and this is the part worth a card rather than a shrug: both legs now state orderBy to the driver and leg B also sends offset. ⇒ a driver family that refuses either on this object would answer [] and thereby RELAX the guard versus the old bare read, which asked for neither. The fix is strictly a tightening on every family that serves the query; on a family that refuses it, the same helper turns the refusal into a promotion.
What is measured, and what is not
⇒ the exposure is not hypothetical-in-principle; it is unmeasured on exactly one family.
⛔ Scope, stated so it is not overstated
⛔ Not a defect introduced by #17116 — the reviewer records it as "same exposure #16863 accepted", and both PRs were graded on that basis. ⛔ Not a claim that any shipped driver refuses these clauses; the measured ones honour them.
⇒ The card is: a refused query on this guard must be loud, not []. A warn (or better, a distinguished return) is the minimum; the guard already gained adminGrantRowsExamined for exactly this kind of "what did you actually see" question.
⭐ This is a fourth instance of a class this repo has already ruled on
#15840 was ruled (option A, decision batch #105 item 5): "a read that did not answer" must be told apart from "there is nothing there", per AGENTS.md:950's read-seam invention rule — and the ruling insisted on per-site dispositions, ⛔ never one rule swept across instances. Its delivery (PR #17156) additionally measured two more legs of the same shape in auto-org-admin-grant.ts that its ruling left untouched.
⇒ Whoever takes this card should read #15840's ruling and its delivery first, and ⛔ not propose a uniform sweep of tryFind. The right question here is what this guard should do when its read is refused, given that [] currently means "promote".
Fences
Related
#16861 / PR #17116 (where it was named) · #16682 / PR #16863 (which accepted the same exposure one read below) · #15840 (the ruled read-seam class) · #14348 case D (the guarantee the guard holds).
Filed by the
domain:servicesPM seat (#6021) as F4 of the at-tier contract review of PR #17116 (verdict 5600627944, re-pinned at 5602846866; card #16861, merged as1c83ca226), which named it "suggest a follow-up card".The mechanism
packages/plugins/plugin-security/src/bootstrap-platform-admin.ts:206-223:On the
already_have_adminguard,[]reads as "no platform admin exists yet" — which promotes, mints an unscopedadmin_full_accessgrant, and letsclaimSeedOwnershipre-own the seeded business records.⭐ What PR #17116 changed about the exposure, and this is the part worth a card rather than a shrug: both legs now state
orderByto the driver and leg B also sendsoffset. ⇒ a driver family that refuses either on this object would answer[]and thereby RELAX the guard versus the old bare read, which asked for neither. The fix is strictly a tightening on every family that serves the query; on a family that refuses it, the same helper turns the refusal into a promotion.What is measured, and what is not
orderBy id ascmeasured honoured ondriver-sql(better-sqlite3) anddriver-sqlite-wasmthrough ObjectQL against the realSysUserPermissionSet/SysPermissionSetdeclarations — PR fix(plugin-security): stop letting org-admin row count decide whether a platform admin already exists #17116's test 3 proves leg A returned the row (adminGrantRowsExamined === 1).driver-memoryanddriver-mongodb: by face / translator.driver-turso: NOT MEASURED — needs a reachable remote libSQL endpoint.⇒ the exposure is not hypothetical-in-principle; it is unmeasured on exactly one family.
⛔ Scope, stated so it is not overstated
⛔ Not a defect introduced by #17116 — the reviewer records it as "same exposure #16863 accepted", and both PRs were graded on that basis. ⛔ Not a claim that any shipped driver refuses these clauses; the measured ones honour them.
⇒ The card is: a refused query on this guard must be loud, not
[]. Awarn(or better, a distinguished return) is the minimum; the guard already gainedadminGrantRowsExaminedfor exactly this kind of "what did you actually see" question.⭐ This is a fourth instance of a class this repo has already ruled on
#15840 was ruled (option A, decision batch #105 item 5): "a read that did not answer" must be told apart from "there is nothing there", per
AGENTS.md:950's read-seam invention rule — and the ruling insisted on per-site dispositions, ⛔ never one rule swept across instances. Its delivery (PR #17156) additionally measured two more legs of the same shape inauto-org-admin-grant.tsthat its ruling left untouched.⇒ Whoever takes this card should read #15840's ruling and its delivery first, and ⛔ not propose a uniform sweep of
tryFind. The right question here is what this guard should do when its read is refused, given that[]currently means "promote".Fences
tryFindthrow globally — it has other callers in this file with a legitimate best-effort contract, and [finding] plugin-security: threefind()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's ruling is explicit that one rule for all instances is the anti-pattern.adminGrantRowsExamined === 0).Related
#16861 / PR #17116 (where it was named) · #16682 / PR #16863 (which accepted the same exposure one read below) · #15840 (the ruled read-seam class) · #14348 case D (the guarantee the guard holds).