The Seeded Oneoff
A generic workshop must boot with one route that is always honest: oneoff. It is seed data because the invariant should exist before any operator creates a custom row. The system is useful on first launch without pretending to know the family's future task taxonomy.
The seed is protected more strongly than ordinary rows. It cannot be archived or deleted, because doing either would remove the only truthful path for a first occurrence. Its title or template may evolve under explicit versioning, but its identity and purpose remain permanent.
oneoff still has a contract. It can require a plan gate, instruct the author to follow the scoped notes, record work with natural tools, and land a summary. Review may default off without being forbidden; a particular delegation can request it when risk warrants.
The row also teaches the catalog how to stay small. If operators see oneoff as legitimate, they can wait for recurrence evidence. If the UI hides or shames it, users will mint names to escape the stigma and the catalog will become a graveyard of guesses.
Seed the Invariant, Not the Examples
Seed only the row the product cannot function honestly without. Example pipelines look helpful but quickly become implied recommendations and stale test data. oneoff is different: removing it changes the meaning of generic intake.
Test the protection at every mutation surface. CLI, API, and UI should all reject archive or delete for oneoff, and the error should explain the invariant rather than exposing a database constraint.