A deployment with human rows and zero `sys_account` rows boots silently into an unrecoverable state — say so loudly at `kernel:ready`

[huangyiirene]

Filed by the triage seat (session session_019kDRpB7D2XzVzkaLp57T5D, R+90) as the half of #14349 that needs no ruling. #14349 asks a posture question (should the bootstrap carve-out count humans or logins) and stays in the decision inbox; this card is its option C, which the filer states "moves nothing and composes with either of the others".

The measured state (from #14349, on a real ObjectQL over better-sqlite3)

13 seeded sys_user rows, zero sys_account rows, default audience posture:

• api.signUpEmail(...) → SELF_REGISTRATION_CLOSED (isBootstrapCreation() counts 13 humans, so the carve-out does not fire);
• nobody can sign in — there is no sys_account row at all;
• self-registration is refused by the default invite_only posture;
• no administrator exists to issue an invitation.

⇒ Outside development (where the dev-admin seed is hard-gated off by NODE_ENV) the deployment cannot be recovered from inside, and its only symptom is a 401 on credentials nobody has.

What this card asks for, and what it does not

Asks: at kernel:ready, when human sys_user rows exist and no sys_account row does, report it at error level, naming the consequence ("no one can sign in and self-registration is closed — this deployment cannot be recovered from inside") and the remedy (provision an account out of band, or open the audience posture). Route & surface ownership §3: absence must be loud.

⛔ Does not ask for any change to admission semantics, to isBootstrapCreation's population, or to bootstrap-status — those are #14349's question and are ruled by the maintainer, not here. This diagnostic is correct under every one of that card's three options, which is why it is separable.

Grade

pm:queue · priority:p2 · domain:services (packages/plugins/plugin-auth) · type Bug. p2: the state is unrecoverable and today entirely silent; the fix is one boot-time check.

Size/model suggestion: S, opus; the pin is a boot fixture with human rows and no accounts asserting the error line, plus the negative control (an account exists ⇒ silent).

Refs: #14349 (the posture question) · #14157 (the development-lane half, which fixes this for objectstack dev) · #14348 (the promotion-target half).

[huangyiirene]

Triage addendum — read this before writing a new boot check. Found while grading the parent (#14349) against origin/main @ 72adb7f.

A kernel:ready reporter for this neighbourhood already exists. packages/plugins/plugin-auth/src/auth-plugin.ts:945-969 registers a hook that probes probeWalledOwnerAccountState(ql) and calls warnIfWalledOwnerCannotVerify(...); the message builder is resolveWalledOwnerVerificationPathWarning in packages/plugins/plugin-auth/src/walled-owner-verification-path.ts:309, and it already enumerates named situations — including owner-absent ("Human users already exist but none holds a declared address"), which is adjacent to, but not, the state this card is about.

It does not subsume this card, on three counts, each of which is a reason the dead end stays silent today:

1. Its predicate is strictly narrower. The probe only runs when all four hold: no email transport, no federated sign-in, postureEnforcesWall(resolveTenancyPosture()), and a declared platform-owner address. This card's scenario needs none of those — it is about the audience posture (invite_only, the default), which is a different axis from the tenancy posture. A directory-seeded deployment that is unwalled, or declares no owner, or wires an email transport, gets no report at all and still cannot be recovered from inside.
2. It asks a different question. Every WalledOwnerAccountState is about the declared owner's verification standing. This card is about the absence of any login whatsoever — no sys_account row exists for anyone. owner-absent is reachable with a perfectly healthy set of accounts.
3. It is a warning. This card asks for error level, because the consequence is an unrecoverable deployment rather than a degraded path.

So the instruction to whoever takes this: extend this family rather than open a parallel one — same hook site, same message-builder discipline (one named situation per shape, consequence and remedy in the line), and reuse isHumanUserRow for the human half. ⛔ Do not add a second independent kernel:ready prober that duplicates the page read; a deployment matching both shapes must not get two overlapping reports.

One coupling to #14349, recorded so it is not a surprise. This diagnostic is correct under every limb of that card, which is why it was split out and is queued now. But if the maintainer rules B (count logins), the state this check fires on becomes the state where the bootstrap carve-out opens — so the line's remedy clause would change from "provision an account out of band, or open the audience posture" to something naming that the next visitor to /sign-up/email will be admitted as the bootstrap account. The check, its predicate, and its test all survive; only the sentence moves. Not a Blocked-by: — do not wait on the ruling — but re-read #14349's state before finalising the wording.

---

Generated by Claude Code