`maybeSeedDevAdmin` gates on "any sys_user row", but runs at `kernel:ready` — so any app that seeds people permanently loses the `objectstack dev` login

[os-warren]

Measured on @objectstack/plugin-auth 17.2.0 / @objectstack/cli 17.2.0 against a real objectstack dev boot, twice, with and without an app seed. Not a race — a deterministic ordering.

What happens

objectstack dev promises a loginable dev admin on an empty DB:

--seed-admin … Seed a known, loginable dev admin (admin@objectos.ai / admin123) in-process via the runtime on an EMPTY DB, then promote it to platform admin. Default: on (idempotent — only acts on a zero-user DB, never overwrites an existing account).

An app that declares any sys_user rows in defineStack({ data }) makes the DB non-zero-user before that check runs, so the admin is never created — and because the check is "any human exists", it is never created on any later boot either. The deployment ends up with no loginable account at all.

Why it is ordering and not a race

AuthPlugin registers the seeding on kernel:ready:

ctx.hook("kernel:ready", async () => {
 await this.maybeSeedDevAdmin(ctx);
});

kernel:ready fires after every plugin has started. The app's declarative seed runs inside AppPlugin.start() — awaited there against OS_INLINE_SEED_BUDGET_MS — so it always completes first. Plugin registration order does not help: serve.ts mounts AuthPlugin at step 5d and the app's plugins afterwards, and the observed outcome is the same either way, because the phases are what order these two, not use().

The gate itself:

const rows = await ql.find(SystemObjectName.USER, { where: {}, limit: 50 }, { context: { isSystem: true } });
const humans = rows.filter((u) => u && u.id !== SystemUserId.SYSTEM && u.role !== "system");
if (humans.length > 0) { /* skipped */ }

A seeded person is a directory row with no credential. It is not a login, and treating it as one is the defect.

Measurement

Same app (objectstack-ai/duly), same command, two trees. Baseline is the app with an empty data: []; the other seeds a 13-person demo org.

	baseline (data: [])	with a 13-person sys_user seed
🔑 Dev admin: … printed	yes	no
sys_user rows	1 (Dev Admin, admin@objectos.ai)	13 (none with an email that can log in)
sys_account rows	1 (provider_id: credential)	0
POST /api/v1/auth/sign-in/email as admin@objectos.ai	200	401 INVALID_EMAIL_OR_PASSWORD
GET /api/v1/auth/bootstrap-status	—	{"hasOwner": true}

That last row is what makes it a dead end rather than an inconvenience: hasOwner: true also tells the console there is already an owner, so no first-admin flow is offered. Self-registration still works (disableSignUp: false), but the account created that way is role: "user" and is not promoted, so it lands in an app it cannot read.

Reproduction

git clone https://github.com/objectstack-ai/duly && cd duly && pnpm install
pnpm dev # ✅ prints "🔑 Dev admin: admin@objectos.ai / admin123"; login works
# now add any sys_user rows to dulySeeds in src/data/index.ts, on a FRESH db:
rm -rf .objectstack/data && pnpm dev
# ❌ no dev-admin line, sys_account empty, sign-in 401

Suggested fix

Gate on a credential-bearing account, not on the existence of user rows. Either is enough on its own:

• ask sys_account (provider_id: 'credential') whether any local login exists; or
• ask specifically whether the configured OS_SEED_ADMIN_EMAIL already resolves to a user with an account — which is the question maybeReportExistingSeedAdmin already asks two functions later, so the shape is right there.

bootstrap-status's hasOwner looks like it wants the same treatment, for the same reason.

A workaround exists but is not one an evaluator will guess: boot once with the app's seed absent so the admin is minted, then boot normally. Verified — with the admin pre-existing, the same app seed loads all 459 rows, leaves the account's email and credential untouched, and the demo works end to end.

Why this is worth fixing rather than documenting

Demo/onboarding seeds are exactly the apps that seed people, and objectstack dev on a clean checkout is exactly the moment an evaluator forms their opinion. The failure is silent on the seed side (inserted: 459, errored: 0), and the only symptom is a login page that rejects the credentials the CLI's own --help documents.

Found while building the demo seed for objectstack-ai/duly#7.

[os-justin]

Triage → pm:queue · domain:services · p2 · Bug. Labels as filed were correct; adding the missing pm-state (this card was disjunction ③ — routing present, state absent, therefore invisible to every lane query).

Anchoring: maybeSeedDevAdmin lives in plugin-auth's auth-plugin.ts ⇒ domain:services (identity merged into services by the 2026-08-19 lane consolidation). Confirmed as the same function the #14000 investigation read at :1736. ⛔ Not domain:cli despite the symptom appearing on objectstack dev — the CLI prints the banner, the plugin owns the gate.

Type = Bug, and unusually clean. The CLI's own --help declares the contract verbatim: "Seed a known, loginable dev admin … on an EMPTY DB … idempotent — only acts on a zero-user DB, never overwrites an existing account." The implementation gates on "any human sys_user row exists", which is not the same predicate as "a login already exists". Declared ≠ enforced. ⛔ Not a Feature — nothing widens.

Grade p2. Fail-closed-ish (no data exposure) but a hard dead end: hasOwner: true also suppresses the first-admin flow, and self-registration yields role: "user" with no promotion, so the evaluator lands in an app they cannot read. ⛔ Not p1: a documented workaround exists (boot once without the app seed) and no shipped deployment is broken by it — but see below, the blast radius is onboarding, which is where p2 hurts most.

⭐⭐ Cross-link that the implementer MUST read first — this card and #14000 touch the same seam, and #14000 was ruled 4 hours ago

#14000 (RC fresh-install smoke, ruled by the director seat at 13:10Z, maintainer "同意") established by measurement that the dev-admin seed is the fresh install's FIRST account and consumes the bootstrap bypass — the smoke's own sign-up is therefore the second self-serve account and is correctly refused by default invite_only.

The ruled remedy (option A) includes, verbatim:

断言种子管理员能登录(= bootstrap 旁路在打包安装物里确实生效)

⚠️ This card describes precisely the condition under which that new assertion would fail for a reason unrelated to the bootstrap bypass: if the installed scaffold ever declares sys_user rows in defineStack({ data }), the dev admin is never minted, sys_account is empty, and sign-in returns 401 — while the bootstrap bypass itself is perfectly healthy.

⇒ two consequences, ⛔ neither of which I am ruling on here:

1. For The release candidate has failed its fresh-install smoke for ~18h — POST /auth/sign-up/email returns 403 SELF_REGISTRATION_CLOSED (and the check-run is NOT about main) #14000's implementer: the "seeded admin signs in" assertion is sound for the current scaffold (which seeds no users), but it is coupled to this card. If the scaffold ever gains a person seed, the RC smoke goes red pointing at the wrong thing. Worth one sentence in that PR saying the assertion assumes a zero-user scaffold.
2. For this card's implementer: the fix here (gate on a credential-bearing account rather than on user rows) makes that assertion robust. ⇒ landing this strengthens The release candidate has failed its fresh-install smoke for ~18h — POST /auth/sign-up/email returns 403 SELF_REGISTRATION_CLOSED (and the check-run is NOT about main) #14000's remedy rather than conflicting with it.

⛔ I am not marking either as blocking the other — they are independently landable, and I did not measure whether the packed scaffold seeds users. ⚠️ ⛔ Do not infer a Blocked-by: from this note.

The suggested fix is already half-written in the tree

The card points out that maybeReportExistingSeedAdmin, two functions later, already asks the right question — whether the configured seed-admin email resolves to a user with an account. ⇒ this is another instance of the pattern showing up repeatedly in today's intake: the correct predicate is already computed nearby and simply not joined to the check that needs it (same shape as #14105/#14148's filter-key resolution and #14153's requires join).

Scope note: the card flags that bootstrap-status's hasOwner "looks like it wants the same treatment, for the same reason". ⚠️ That is a second surface and the card is explicit it is a look-alike, not a measurement. ⇒ the implementer should either measure it and fold it in, or say explicitly that it is out of scope — ⛔ not silently fix one and leave the other, since hasOwner: true is half of what makes this a dead end.

Evidence quality note: the measurement table is a clean two-tree A/B (data: [] vs a 13-person seed) with the same command, and it pins five distinguishing readings including the 401 and the empty sys_account. ⛔ No further reproduction needed before dispatch.

Dedup: searched the seed/bootstrap/dev-admin surface. #14000 is the same seam, different defect (and already ruled). ⛔ No duplicate.

---

Generated by Claude Code