Every preview the forge deploys starts with an empty database, so a pull that adds vote buttons, a roster page or a state filter deploys to No proposals yet. and whoever reviews it has to hand-build a group first — sign in as an admin, add themselves to the roster, open a proposal, add options — before they can see the thing the pull changed. Production is empty for the same reason. Give a non-production database one example group that explains itself.
What done looks like
[ ] src/seed.ts, one module, one exported seed(db, {now}) that writes an example group through the existing actions — never raw SQL — and returns what it made. It is pure of HTTP and identity: the caller hands it the database.
[ ] It runs at boot from src/server.ts only when all of these hold: env from src/env.ts is not production, the proposal table is empty and the member table is empty. Any one of them false and it does nothing and says nothing. There is no flag, no environment variable and no route that can make it run in production.
[ ] What it seeds: three members with obviously fictional ids, and three proposals — one open under majority with a few ballots and a remark thread, one open under all waiting on one person, and one already decided — so a reviewer can see a tally in progress, a rule that is not the default, and a finished decision without touching anything.
[ ] The example data says what it is: every seeded proposal's paragraph opens with a sentence naming it as an example on a preview, and the boot line says seeded 3 proposals (preview) so an operator reading the log is never confused about where the rows came from.
[ ] The terminal gets s to seed an empty non-production database on demand and says plainly why it refused when the database is not empty or the environment is production. No page and no API route seeds anything.
[ ] Tests in a new src/seed.test.ts: seeding an empty database makes a group whose decided proposal really is decided by its own rule (assert through getProposal, not by reading the rows it wrote); seeding twice makes nothing the second time; env: "production" makes nothing; a database with one proposal and no members makes nothing.
[ ] README.md says in three lines what a preview contains and that production is never seeded. bun test is green.
Files I expect to change:src/seed.ts (new), src/seed.test.ts (new), src/server.ts, src/tty.ts, README.md.
Risks: the guard is the whole issue — write it as one function with the three conditions in one place and test the refusals before the happy path. Seeding through the actions means the seed cannot drift from the rules; seeding through SQL means the first schema change makes an example group that could never have existed. This needs ballots (#5) for the decided proposal: land it after, or seed no ballots and no decided proposal and say so in the pull rather than reaching into the tables.
Fit: Hearth — what the room looks like when somebody opens the door. A person assigns; I do not.
Every preview the forge deploys starts with an empty database, so a pull that adds vote buttons, a roster page or a state filter deploys to
No proposals yet.and whoever reviews it has to hand-build a group first — sign in as an admin, add themselves to the roster, open a proposal, add options — before they can see the thing the pull changed. Production is empty for the same reason. Give a non-production database one example group that explains itself.What done looks like
src/seed.ts, one module, one exportedseed(db, {now})that writes an example group through the existing actions — never raw SQL — and returns what it made. It is pure of HTTP and identity: the caller hands it the database.src/server.tsonly when all of these hold:envfromsrc/env.tsis notproduction, theproposaltable is empty and themembertable is empty. Any one of them false and it does nothing and says nothing. There is no flag, no environment variable and no route that can make it run in production.majoritywith a few ballots and a remark thread, one open underallwaiting on one person, and one alreadydecided— so a reviewer can see a tally in progress, a rule that is not the default, and a finished decision without touching anything.seeded 3 proposals (preview)so an operator reading the log is never confused about where the rows came from.sto seed an empty non-production database on demand and says plainly why it refused when the database is not empty or the environment is production. No page and no API route seeds anything.src/seed.test.ts: seeding an empty database makes a group whose decided proposal really is decided by its own rule (assert throughgetProposal, not by reading the rows it wrote); seeding twice makes nothing the second time;env: "production"makes nothing; a database with one proposal and no members makes nothing.README.mdsays in three lines what a preview contains and that production is never seeded.bun testis green.Files I expect to change:
src/seed.ts(new),src/seed.test.ts(new),src/server.ts,src/tty.ts,README.md.Risks: the guard is the whole issue — write it as one function with the three conditions in one place and test the refusals before the happy path. Seeding through the actions means the seed cannot drift from the rules; seeding through SQL means the first schema change makes an example group that could never have existed. This needs ballots (#5) for the decided proposal: land it after, or seed no ballots and no decided proposal and say so in the pull rather than reaching into the tables.
Fit: Hearth — what the room looks like when somebody opens the door. A person assigns; I do not.