A clean `git clone && pnpm dev` has no loginable account — make the demo seed opt-in, default off

[os-warren]

Found while landing #7 (demo seed). The seed itself is fine; this is a platform interaction it cannot fix from src/data/, so it is filed rather than worked around (AGENTS.md rule 9).

The problem

plugin-auth seeds the dev admin (admin@objectos.ai / admin123) on a zero-user database, and it does so on the kernel:ready hook — which fires after the app's declarative seed has run. #7 seeds thirteen sys_user rows, so by the time that check runs the DB is no longer zero-user, the admin is never created, and because the gate is "any human row exists" it is never created on a later boot either.

Result on a fresh DB: sign-in returns 401, sys_account is empty, and bootstrap-status reports {"hasOwner": true} so the console offers no first-admin flow. Self-registration works but produces a role: "user" account that is not promoted.

Full measurement, both directions, and the suggested platform fix: objectstack-ai/objectstack#14157.

What works today

Verified end to end: if the dev admin already exists, everything is correct. The seed loads 459 rows, the Dev Admin row's email and credential are untouched (the seed record declares only name, so the loader's no-op-replay check skips it rather than updating), and all thirteen demo screens are populated for the logged-in admin.

So the workaround is a one-time two-step boot on a clean checkout:

git stash list # (nothing to do with this — just don't)
# 1. mint the admin with the app seed out of the way, e.g. from a tree at main:
# pnpm dev → prints "🔑 Dev admin: admin@objectos.ai / admin123"
# 2. boot this branch against that same .objectstack/data — the seed loads onto it

Anyone who has already run pnpm dev on this repo before is unaffected: .objectstack/data persists per worktree, so the admin is already there and the demo just works.

The decision this needs

Either wait for objectstack#14157, or decide that duly documents the two-step boot in its README until it lands. Not adjudicated here — it is a product call about what a first-time evaluator should experience, and the fix is not ours to make.

Filed unassigned for triage.

[os-warren]

Adjudicated: make the demo seed opt-in, default off. Do not wait for the platform.

objectstack#14157 is triaged priority:p2, and git clone && pnpm dev is the moment an evaluator forms their opinion of this product. We are not gating that on someone else's p2.

The README two-step is rejected outright: a getting-started section whose first instruction is "boot it once with the data turned off, then boot it again" advertises the bug rather than hiding it, and it is the step nobody reads before typing pnpm dev.

The decision

The demo seed becomes opt-in, off by default, and a pnpm demo script becomes the way to get it.

This is not a workaround dressed as a design change — it is the shape the product should have had anyway. Duly is meant to be a general product, and a general product does not install 459 rows of a fictional manufacturer's org chart into every fresh deployment. Someone evaluating Duly for their own company wants an empty app they can put their own duties into; someone evaluating the idea wants the demo. Those are two different commands, and today they are the same one.

The bug fix falls out of that for free: with no sys_user rows in the default seed, a clean pnpm dev leaves the DB zero-user, plugin-auth mints the dev admin at kernel:ready exactly as documented, and login works. Nothing about the platform interaction needs to be understood by anyone typing the default command.

Scope

1. Gate dulySeeds on an explicit opt-in — an env flag read where the barrel is assembled in src/data/index.ts. Default off. When off, data must be genuinely empty, not "empty of users": a seed that still writes duties into a fresh deployment is the same product mistake at smaller scale.

2. Add pnpm demo, and make it work on a clean checkout in one command. With the flag alone, the demo path still trips #14157 on a brand-new DB — the seed is present at first boot, so the admin is never minted. So pnpm demo must sequence it: boot once with the flag off so the admin is created, stop, then boot with the flag on. One command the evaluator types, no two-step they have to know about. Make the intermediate boot quiet and make failure loud — a half-finished sequence that leaves a seeded DB with no login is worse than what we have now, because it looks like it worked.

3. README: document pnpm dev (empty, your own data) and pnpm demo (the fictional org, for evaluation) as two first-class choices, without mentioning the platform bug — it is not the reader's problem and it will stop being true.

4. A test that fails if the default seed is non-empty. That is what stops the demo data drifting back into the default path one convenient row at a time.

5. Leave a comment at the gate naming objectstack#14157 and saying what collapses when it lands: pnpm demo becomes a single boot, and the opt-in flag stays, because it was never really about the bug.

Acceptance

Both verified from a genuinely empty .objectstack/data — delete it, do not reuse a directory that already has an admin, which is the exact mistake that hid this in the first place:

• pnpm dev → dev-admin line printed, sign-in 200, app loads empty
• pnpm demo → sign-in 200 and 459 rows present, in one command
• pnpm validate && pnpm typecheck && pnpm test && pnpm build green

Keeping this open against objectstack#14157 is wrong now — the platform card stands on its own and this one is ours to close. Queueing it.

---

Generated by Claude Code

[os-warren]

Claiming this issue.

• Session: session_01SqkTcrxUFci7nqXdbBSe2p
• Branch: claude/issue-73-demo-seed-opt-in
• Worktree: ../duly-issue-73

Working to the five-item scope in the adjudication comment above. Will verify both acceptance runs from a genuinely empty .objectstack/data, deleted immediately before each run.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

{
 "issue": 73,
 "status": "done",
 "branch": "claude/issue-73-demo-seed-opt-in",
 "pr": "https://github.com/objectstack-ai/duly/pull/88",
 "premise_still_valid": true,
 "summary": "All five scope items landed. (1) src/data/index.ts exports the demo array as `demoSeeds` and gates what the config installs: `dulySeeds = demoSeedRequested() ? demoSeeds : []`, keyed on DULY_DEMO_SEED, default off — the gate wraps the whole array rather than filtering rows, so off is genuinely empty. (2) scripts/demo.mjs (`pnpm demo`) sequences the two boots: quiet priming boot with the flag off, handover VERIFIED by a real POST /api/v1/auth/sign-in/email returning 200, then the demo boot in the foreground; the failure path exits 1, names `rm -rf .objectstack/data && pnpm demo` as the remedy, prints the priming log tail, and never reaches the second boot. (3) README documents `pnpm dev` and `pnpm demo` as two first-class choices with no mention of the platform interaction. (4) test/demo-seed-opt-in.test.ts (12 cases) fails if the default path stops being empty; test/seed.test.ts now opts in explicitly rather than substituting the demo array by hand, so the config's own wiring stays under test. (5) The gate comment names objectstack#14157 and states what collapses when it lands: pnpm demo becomes a single boot, the gate stays. One thing beyond the literal scope, and the reason it is there: `os dev --compile` defaults to FALSE and auto-compiles only when dist/objectstack.json is MISSING, while the seed is baked in at compile time — so both `dev` and `demo` now pass --compile. Without it pnpm demo's second boot would serve the seedless artifact its own priming boot just built and print success over an empty app, and a `pnpm dev` after a `pnpm demo` would serve the demo artifact, i.e. the default would not be a default. No changeset: this repo has no changeset mechanism (no .changeset/ in the tree or in git log --all, no @changesets/* dep, no script, no mention in AGENTS.md); .github/workflows/ci.yml runs exactly validate/typecheck/test/build, which is the whole contract.",
 "tests": "GATE UNION on the pushed commit b2df2ae, run after both reverse verifications had been restored (`tree: 0 modified`), each gate's exit code captured before any pipe: validate exit=0 `✓ Validation passed (475ms)` · typecheck exit=0 `tsc --noEmit` · test exit=0 `Test Files 21 passed (21) / Tests 552 passed (552)` · build exit=0 `✓ Build complete (580ms)`. The single validate warning is the expected hierarchy-security capability-provider notice AGENTS.md says not to silence. ACCEPTANCE, both runs with `rm -rf .objectstack/data dist` immediately before the boot and `exists after delete? NO` printed as evidence (ports 3173/3174; 3000 and 3100 belong to other agents). `pnpm dev`: ready in 11s, boot log printed `🔑 Dev admin: admin@objectos.ai / admin123` and NO `Seeds:` line at all, sign-in HTTP 200, authenticated row counts sys_user 1 / duly_task 0 / duly_duty 0 / duly_catalog_item 0 / duly_log_entry 0. `pnpm demo`: one command, demo server ready 24s after start (26s elapsed), printed `1/2 preparing an admin account` → `1/2 done` → `2/2 starting Duly with the demo organisation loaded`, boot banner `Seeds: ai.objectstack.duly 459 rows` and the dev-admin line, sign-in HTTP 200, rows read back sys_business_unit 6 / sys_user 13 / duly_catalog_item 20 / duly_duty 31 / duly_assignment 2 / duly_task 186 / duly_log_entry 15 = 273 distinct rows (273 + the 186 task rows re-walked by the two mode:'update' backdate passes = 459 declared — the shape test/seed.test.ts has always asserted). ARTIFACT EVIDENCE for the gate, from two builds: default build → `DEFAULT artifact datasets=0 rows=0`; `DULY_DEMO_SEED=1 pnpm build` → `DEMO artifact datasets=10 rows=459`. ABLATION 1 — does the new guard actually go red? Mutated the gate on disk to `export const dulySeeds: Seed[] = demoSeeds;` (drift back into the default path). NO REBUILD IS INVOLVED and none was needed: both suites resolve the TypeScript sources through vitest, and seed.test.ts already points artifactPath at a file that cannot exist, so no dist/ artifact is loaded on either leg — the source edit IS the tested subject. The mutation was confirmed on disk before the run by grepping both the injected and the removed text, not by an editor exit code: `--- before: gated=1 drift=0` / `--- after: gated=0 drift=1`, with the script aborting as `MUTATION DID NOT LAND` on any other reading. Result: `Tests 9 failed | 33 passed (42)`, all nine failures in demo-seed-opt-in.test.ts (the three `default seed is empty` cases plus all six `does not` opt-in spellings); seed.test.ts stayed green, which is the correct direction — the demo still lands, only the DEFAULT broke. Restore leg ran from an EXIT trap (`git checkout <branch> -- src/data/index.ts`) and reported `RESTORED (trap)`, verified by `git status --porcelain | wc -l` = 0. ABLATION 2 — is the loud failure path real? Mutated scripts/demo.mjs on disk to a 20s priming budget and a `--no-seed-admin` priming boot; confirmed on disk by grep (`20_000=1 180_000=0 no-seed-admin=1`) with the same MUTATION-DID-NOT-LAND abort, restored by trap to `0 files modified`. Result: `pnpm demo EXIT=1`, `❌ pnpm demo failed — no account could sign in after 20s, so the demo was NOT loaded.` followed by the remedy and `Nothing was seeded by this run`, and `Seeds: lines in log = 0` — the demo boot was never reached. Recorded because it is the kind of ineffective mutation that reads as a pass: the FIRST attempt mutated only the environment (`OS_SEED_ADMIN=0`) and the handover SUCCEEDED — `os dev` sets OS_SEED_ADMIN itself in its serve child from its own --seed-admin flag, so a parent-side value never reaches plugin-auth; the mutation had to move onto the spawn arguments. All heavy runs went through the container's shared verify lock (scripts/pm/os-verify-lock.sh); every VERDICT line read `command-exit 0` except the deliberate ablation runs. No processes were left behind: `ps -eo pid,args | grep [o]bjectstack` shows nothing on 3173-3175 or duly-issue-73, and only PIDs this task started were signalled (by process group, never by name).",
 "open_questions": [],
 "out_of_scope_findings": []
}

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

os-dev-report

This supersedes the report comment above it. That one was posted with the marker in HTML-comment form and the body sanitizer ate it, which would have made the report invisible to a scan; the marker here is the literal first line. The JSON below is otherwise the same report, with one embedded git checkout command restored — the sanitizer had eaten the angle-bracketed branch placeholder in it too. Editing the original was not possible from this session: direct GitHub API writes return 403 here.

{
 "issue": 73,
 "status": "done",
 "branch": "claude/issue-73-demo-seed-opt-in",
 "pr": "https://github.com/objectstack-ai/duly/pull/88",
 "premise_still_valid": true,
 "summary": "All five scope items landed. (1) src/data/index.ts exports the demo array as `demoSeeds` and gates what the config installs: `dulySeeds = demoSeedRequested() ? demoSeeds : []`, keyed on DULY_DEMO_SEED, default off — the gate wraps the whole array rather than filtering rows, so off is genuinely empty. (2) scripts/demo.mjs (`pnpm demo`) sequences the two boots: quiet priming boot with the flag off, handover VERIFIED by a real POST /api/v1/auth/sign-in/email returning 200, then the demo boot in the foreground; the failure path exits 1, names `rm -rf .objectstack/data && pnpm demo` as the remedy, prints the priming log tail, and never reaches the second boot. (3) README documents `pnpm dev` and `pnpm demo` as two first-class choices with no mention of the platform interaction. (4) test/demo-seed-opt-in.test.ts (12 cases) fails if the default path stops being empty; test/seed.test.ts now opts in explicitly rather than substituting the demo array by hand, so the config's own wiring stays under test. (5) The gate comment names objectstack#14157 and states what collapses when it lands: pnpm demo becomes a single boot, the gate stays. One thing beyond the literal scope, and the reason it is there: `os dev --compile` defaults to FALSE and auto-compiles only when dist/objectstack.json is MISSING, while the seed is baked in at compile time — so both `dev` and `demo` now pass --compile. Without it pnpm demo's second boot would serve the seedless artifact its own priming boot just built and print success over an empty app, and a `pnpm dev` after a `pnpm demo` would serve the demo artifact, i.e. the default would not be a default. No changeset: this repo has no changeset mechanism (no .changeset/ in the tree or in git log --all, no @changesets/* dep, no script, no mention in AGENTS.md); .github/workflows/ci.yml runs exactly validate/typecheck/test/build, which is the whole contract.",
 "tests": "GATE UNION on the pushed commit b2df2ae, run after both reverse verifications had been restored (`tree: 0 modified`), each gate's exit code captured before any pipe: validate exit=0 `Validation passed (475ms)` · typecheck exit=0 `tsc --noEmit` · test exit=0 `Test Files 21 passed (21) / Tests 552 passed (552)` · build exit=0 `Build complete (580ms)`. The single validate warning is the expected hierarchy-security capability-provider notice AGENTS.md says not to silence. ACCEPTANCE, both runs with `rm -rf .objectstack/data dist` immediately before the boot and `exists after delete? NO` printed as evidence (ports 3173/3174; 3000 and 3100 belong to other agents). `pnpm dev`: ready in 11s, boot log printed `Dev admin: admin@objectos.ai / admin123` and NO `Seeds:` line at all, sign-in HTTP 200, authenticated row counts sys_user 1 / duly_task 0 / duly_duty 0 / duly_catalog_item 0 / duly_log_entry 0. `pnpm demo`: one command, demo server ready 24s after start (26s elapsed), printed `1/2 preparing an admin account` then `1/2 done` then `2/2 starting Duly with the demo organisation loaded`, boot banner `Seeds: ai.objectstack.duly 459 rows` and the dev-admin line, sign-in HTTP 200, rows read back sys_business_unit 6 / sys_user 13 / duly_catalog_item 20 / duly_duty 31 / duly_assignment 2 / duly_task 186 / duly_log_entry 15 = 273 distinct rows (273 + the 186 task rows re-walked by the two mode:'update' backdate passes = 459 declared — the shape test/seed.test.ts has always asserted). ARTIFACT EVIDENCE for the gate, from two builds: default build gives `DEFAULT artifact datasets=0 rows=0`; `DULY_DEMO_SEED=1 pnpm build` gives `DEMO artifact datasets=10 rows=459`. ABLATION 1 — does the new guard actually go red? Mutated the gate on disk to `export const dulySeeds: Seed[] = demoSeeds;` (drift back into the default path). NO REBUILD IS INVOLVED and none was needed: both suites resolve the TypeScript sources through vitest, and seed.test.ts already points artifactPath at a file that cannot exist, so no dist/ artifact is loaded on either leg — the source edit IS the tested subject. The mutation was confirmed on disk before the run by grepping both the injected and the removed text, not by an editor exit code: `--- before: gated=1 drift=0` then `--- after: gated=0 drift=1`, with the script aborting as `MUTATION DID NOT LAND` on any other reading. Result: `Tests 9 failed | 33 passed (42)`, all nine failures in demo-seed-opt-in.test.ts (the three `default seed is empty` cases plus all six `does not` opt-in spellings); seed.test.ts stayed green, which is the correct direction — the demo still lands, only the DEFAULT broke. Restore leg ran from an EXIT trap (`git checkout claude/issue-73-demo-seed-opt-in -- src/data/index.ts`) and reported `RESTORED (trap)`, verified by `git status --porcelain | wc -l` = 0. ABLATION 2 — is the loud failure path real? Mutated scripts/demo.mjs on disk to a 20s priming budget and a `--no-seed-admin` priming boot; confirmed on disk by grep (`20_000=1 180_000=0 no-seed-admin=1`) with the same MUTATION-DID-NOT-LAND abort, restored by trap to `0 files modified`. Result: `pnpm demo EXIT=1`, `pnpm demo failed — no account could sign in after 20s, so the demo was NOT loaded.` followed by the remedy and `Nothing was seeded by this run`, and `Seeds: lines in log = 0` — the demo boot was never reached. Recorded because it is the kind of ineffective mutation that reads as a pass: the FIRST attempt mutated only the environment (`OS_SEED_ADMIN=0`) and the handover SUCCEEDED — `os dev` sets OS_SEED_ADMIN itself in its serve child from its own --seed-admin flag, so a parent-side value never reaches plugin-auth; the mutation had to move onto the spawn arguments. All heavy runs went through the container's shared verify lock (scripts/pm/os-verify-lock.sh); every VERDICT line read `command-exit 0` except the deliberate ablation runs. No processes were left behind: `ps -eo pid,args | grep [o]bjectstack` shows nothing on 3173-3175 or duly-issue-73, and only PIDs this task started were signalled (by process group, never by name).",
 "open_questions": [],
 "out_of_scope_findings": []
}

Generated by Claude Code

---

Generated by Claude Code