[mforce]

Closes #58. After a dev-DB wipe, Seed__Demo=true boots a fully populated app instead of empty screens.

What

DemoDataSeeder — own startup scope, resolves the TenantContext to the seeded account, and drives the real handlers (record → submit → lots/movements, customer → order → items → FIFO confirm), so every downstream fact exists exactly as if a user clicked it in. Deterministic quantities — reproducible demos, no Random.

Seeds: two active flocks (45wk/20wk) + a depleted 2025 batch with a backdated 430-bird end-of-lay cull; a week of submitted graded entries per active flock with losses and sprinkled mortality (today = Draft for one flock, unrecorded for the other, so the dashboard shows both states and the "no entry" flag); three customers; one confirmed order + one open draft.

Safety

• Default false — the flag must be explicitly set (Seed__Demo=true in deploy/.env or user-secrets); prod can't accidentally get fake data.
• Gated on an empty flock catalog: runs once on a fresh DB, no-op afterwards, never resurrects deleted data.
• Best-effort: failure logs and continues; the app starts regardless.

Tests (+1 → 124)

Derived test host (runtime-generated credentials) on a fresh catalog: 3 flocks incl. depleted with ledger-reduced count (450−430=20), stock > 0, confirmed + draft orders, 14+ entries; second startup no-op. Guard also verified live against the populated dev DB ("Demo seed skipped: flocks already exist").

[mforce]

Review round: codex + pi

#	Source	Severity	Finding	Action
1	codex	P2	Seed:Enabled=false + Seed:Demo=true still seeded fake data — Enabled is documented as disabling all startup seeding	Fixed — demo requires both flags (3cc0b86)
2	codex	P2	A mid-seed failure left committed rows (handlers commit stepwise) that trip the empty-catalog guard forever — permanently half-seeded	Fixed — failure cleanup deletes the account's rows in demo-touched tables; safe because the guard guarantees everything there came from the failed run. One outer transaction wasn't possible: ConfirmSale opens its own (3cc0b86)
3	pi	Low	Test residue on the shared default account in the collection DB	Deferred — tenant filters isolate every current test; revisit if any test asserts on the default account
4	pi	Med (truncated)	Deleting all flocks later re-triggers the demo seed on restart	Accepted — dev-only flag; a wipe is the intended reseed path, and there is no flock delete in the app
5	pi	—	Scope isolation, prod-safe default, guard's IgnoreQueryFilters scoping, runtime credentials	Verified clean by pi

124 tests green after fixes.

[mforce]

Second review round (fix-commit delta, pi)

The 3cc0b86 fix commit itself got a follow-up pi review:

Finding	Verdict	Action
FK delete ordering	✅ verified correct against the EF configs	—
Table coverage	✅ all 8 demo-written tables purged; EggGrades correctly excluded	—
Cleanup not atomic — 8 separate autocommits could half-purge	Low	Fixed — one transaction wraps the deletes (5c6ee56)
Safety comment overstated the flock guard's proof (customers/orders aren't flock-rooted)	Low	Fixed — comment now states the real reason they're safe: DatabaseSeeder never writes them (5c6ee56)
Cleanup failure swallowed (log only)	Low	Accepted — matches the best-effort demo stance; operator wipes manually in that corner