Seeding
The seed is bootstrap classification data. It is not a migration, and the two are kept separate on purpose: a migration changes shape, a seed changes rows, and only one of them is safe to re-run.
npm run seed # apply
npm run seed -- --dry-run # validate the files, touch nothing
Three properties
Idempotent. Every write is an upsert keyed on the slug. Running the same version twice changes
nothing — verified against the live database: the second run reports 0 created, 444 unchanged.
Non-destructive. A name an administrator reclassified is left alone. The seed records the classification it last wrote, and if the live value differs, someone changed it deliberately: it reports and moves on. A seed file silently undoing an administrator's decision on the next deploy is the failure this exists to prevent.
Validated by the rules user input uses. Slugs go through the same normalizer the purchase path uses, so the seed cannot introduce a name nobody could type — or, worse, a second row that normalizes onto an existing one.
The files
prisma/seeds/
reserved-system.json 246 routing and security identifiers
premium-generic.json 198 generic commercial terms
pricing.json opening prices per classification and currency
A name claimed by two files is a curation error, and the seed refuses to run rather than letting
file order decide. That check earned itself immediately: thirteen terms collided, and seven turned
out to be mistakes in the system list — news, jobs, media and others are commercial terms that
had been made unsellable by being reserved.
What is not in the files
No brand, company or personal name. Those need a judgement a seed file is not the place to make, and the operator curates them separately. Inclusion in any list is not a determination that anyone owns a mark.
A gap
Migrations run automatically before the application starts. The seed does not — it is applied by hand. Until that changes, seeding is knowledge someone has to remember rather than something the deployment does.