[finding] Walled boot requires OS_PLATFORM_OWNER_EMAIL but not a verification path — with #11343 landed, an owner with no way to verify is never elevated

[os-sam]

Filed unassigned by the domain:services dev seat working #11343 (PR #11639), as an out-of-scope observation for triage. ⛔ Not claimed; no severity judgment offered.

Observation

#11343's ruled fix makes walled platform-admin elevation require a verified owner-email match, refusing loudly (walled_owner_not_verified) and never falling back — the same fail-closed direction as the existing walled_owner_email_undeclared refusal. That refusal is transient only when the deployment has some path to verification:

• an email transport, so the verification link can be sent (auth-manager.ts wires better-auth's emailVerification block only when emailVerification or emailService config is present), or
• a trusted SSO provider, which marks the account verified at insert.

A walled deployment with neither now has a declared owner who registers, is refused (correctly — the string alone proves nothing), and has no in-product way to ever satisfy the condition. The warn line the refusal prints names this remedy, but nothing checks it at boot.

The question for triage

Walled boot already refuses to start when OS_PLATFORM_OWNER_EMAIL is undeclared (plugin-auth init()), on the reasoning that a walled posture without an identifiable owner is a misconfiguration. Should the same boot-time check (refuse, or at least a loud named warning) cover "walled posture with no verification path configured"? The alternative is the status quo: the gap only surfaces as the elevation-time warn after the owner has already registered and cannot proceed.

No direction is proposed here — whether this is a boot refusal, a boot warning, or accepted operator responsibility changes walled deployment requirements, which is not a dev-seat call.

Refs: #11343 · PR #11639 (the elevation fix whose fail-closed refusal makes this gap visible)

---

Generated by Claude Code

[os-sam]

A second route to the same failure mode — recording it here rather than as its own card

This card names one way a walled deployment ends up with a declared owner who never elevates: no email transport and no trusted SSO, so the owner can register but never verify.

There is a second route to the identical end state, and it belongs with this one rather than in a card of its own:

The declared owner's address can be occupied by another account. #11343's fix means occupancy no longer elevates the occupant — that hole is closed. But occupancy itself is untouched, so the address is taken and the genuine owner cannot self-register onto it until the row is removed. Same outcome as this card's: a declared owner who cannot become one.

Why it is recorded here and not filed separately

The #11343 dev found this and deliberately did not file it publicly, on the grounds that a standalone card would state more than #11343 already does about the setup. That judgement was right, and I am not overriding it — I am placing the consequence where someone acting on this card will see it, without restating the setup.

Framed accurately, this is an onboarding/availability problem, not a privilege one: after #11343 the occupant gains nothing. What is lost is the owner's ability to complete onboarding unaided.

Why the pairing matters for whoever scopes this

Both routes have the same shape — the elevation predicate is satisfiable in principle but unreachable in practice for this deployment — and a fix for one may or may not cover the other:

• a boot-time refusal/warning (the shape this card suggests, mirroring the existing undeclared-owner check) would catch the no-transport case at boot, but not occupancy, which is a runtime state
• an operator path to clear or reassign the declared owner's address would cover occupancy, and does nothing for the no-transport case

⇒ Scoping either one alone leaves a live way to end up with an un-administrable walled deployment. Worth deciding them together, or at least deciding deliberately to cover only one.

⛔ Not ruling on any of it — this is a finding and both routes need triage grading and, for the operator path, a maintainer call on what an operator may do to a declared owner's identity.

Refs: #11343 (the elevation fix that makes both routes reachable as failures rather than as escalation) · PR #11639

---

Generated by Claude Code