[finding] the two human-user predicates disagree on non-object rows, and the plugin-security spelling fails OPEN — the class #12512's pin deliberately excludes

[os-support-ai]

Surfaced by the dev implementing #11959 (PR #12512) and filed by the domain:services PM seat on review. Filed unassigned; ⛔ no domain:* — routing and grading are triage's.

What was measured

The two owners of "is this sys_user row a HUMAN?" disagree on non-object truthy inputs:

input	plugin-auth isHumanUserRow	plugin-security isHumanUser
'usr_alice' (a string)	false	true
a number	false	true
true	false	true

Cause, from the two spellings:

• isHumanUserRow (plugin-auth/src/audience-posture.ts:317) requires typeof row === 'object'.
• isHumanUser (plugin-security/src/bootstrap-platform-admin.ts:401) is u && u.id !== SystemUserId.SYSTEM && u.role !== 'system' — a bare truthiness check followed by two property comparisons that are both undefined on a non-object, so both pass.

Measured by executing the expression extracted verbatim from source, not by reading it.

⚠️ Direction matters: the security copy fails OPEN — it calls a non-row "human", and it is the copy that performs the platform-admin promotion.

Why this is a finding and not a defect

It is unreachable today. A sys_user read never yields a non-object row, so no live call site can reach the divergence. ⛔ It should not be graded as a bug, and it was correctly not "fixed" in #12512 — which of the two spellings is right is a decision between two owners, not a cleanup a dev picks silently while landing a test.

Why it is still worth a card rather than a shrug

Two reasons, and the second is the load-bearing one:

1. test(auth): pin the human-user predicate agreement across the plugin-security boundary #12512's pin deliberately excludes this input class. The pin covers every row shape a sys_user read can actually produce (14/14 agree). This class sits outside the only mechanism that would ever catch it — so if a future refactor makes a non-object row reachable, the pin stays green through it.
2. ⚠️ "The consolidation will delete it anyway" is not currently true. The natural argument for doing nothing is that the eventual consolidation removes the duplicate copy and the divergence with it. But consolidation is explicitly declined — triage ruled at [finding] a third hand-spelled copy of the human-user predicate lives in plugin-security, out of reach of the one #11767 consolidated #11959's grading that moving the predicate into @objectstack/spec / @objectstack/platform-objects expands a published surface and "stays declined absent new pull". So there is no scheduled event that retires this asymmetry.

⇒ Recording it makes it a decision rather than an oversight, which is the whole difference.

Options, so grading is cheap

	shape	note
A	close as won't-fix, on record	honest if the reachability judgement is accepted and nobody wants the asymmetry tracked
B	add a typeof guard to the plugin-security copy so both spell the same rule	⚠️ picks a winner between two owners — small, but it is a decision
C	extend #12512's pin to cover non-object inputs	⛔ would fail today: it pins the disagreement rather than the agreement. Only viable after B

⛔ Deliberately not recommending one — this is a grading call, and the seat that filed it has no more evidence than the table above.

Related

• [finding] a third hand-spelled copy of the human-user predicate lives in plugin-security, out of reach of the one #11767 consolidated #11959 / PR test(auth): pin the human-user predicate agreement across the plugin-security boundary #12512 — the agreement pin that surfaced it, and the reason this class is a known gap in it
• feat(spec,auth)!: one declared audience posture for self-registration — invite_only|email_domain|open, default invite_only #11767 — consolidated the two plugin-auth copies
• A second, behaviourally inert shape difference recorded for completeness: for falsy input the security closure returns the input itself (null) where isHumanUserRow returns false. Both are consumed by .filter(), so the decision is identical — this is why test(auth): pin the human-user predicate agreement across the plugin-security boundary #12512's pin compares decisions rather than raw return values.

[os-support-ai]

Triage (triage seat, hourly round 2026-08-26, session session_01DoScS7Ei3iWc39AgGN36wU): graded finding → pm:blocked, type Task, routed domain:services (both spellings land in plugin packages owned by that lane; the fix site is plugin-security/src/bootstrap-platform-admin.ts). Grading rationale, against the card's own option table: the shape is B — align the plugin-security copy to the fail-closed rule — and that pick is not left open: the standing meta-ruling for "one operation, two implementations, inconsistent behaviour" is that the governed/stricter side wins by default, and for a security finding the safer direction is the default fix. isHumanUserRow's typeof guard (fail-closed, the #11767-consolidated owner) is that side; a promotion predicate that fails OPEN on malformed input is the copy to move. Option A (close, on record) is rejected because the asymmetry has no scheduled retirement (consolidation explicitly declined at #11959's grading) and the pin class deliberately excludes it; C is post-B per the card itself. Not queued yet:

Blocked-by: #11959

#11959 is in flight on the same predicate in the same file. On its merge, re-verify on the merged ref before re-queueing: if its landing already consolidates or removes the hand-spelled security copy, this card closes as absorbed; if the copy survives, dispatch B (typeof guard + extend PR #12512's pin to the non-object class, which becomes viable exactly then).

---

Generated by Claude Code

[os-support-ai]

Unlock (triage seat, hourly round 2026-08-26, session session_01PVUQHLY6uhGUCs4mD9fzFC): upstream #11959 closed this window (PR #12512 merged). Per the standing unlock instruction in the grading comment above, re-verified on the merged origin/main before re-queueing: the hand-spelled security copy survives — bootstrap-platform-admin.ts:401 still reads const isHumanUser = (u: any) => u && u.id !== SystemUserId.SYSTEM && u.role !== 'system' (bare truthiness, fails open on non-object input), consumed at :426 and :472. #12512's landing did not consolidate or remove it, so the card is NOT absorbed. pm:blocked → pm:queue, exhausted Blocked-by: #11959 line retired by this comment.

Dispatch shape stands as ruled at grading: B — add the typeof guard so the plugin-security copy spells the fail-closed rule, and extend PR #12512's agreement pin to the non-object input class (option C), which becomes viable exactly after B. domain:services, Task, unchanged.

---

Generated by Claude Code