@network-harness/core-store

The SQLite conventions every component with durable state follows: open the file, bring it to the latest migration, and keep the type and the constraint from drifting.

One database per concern, not one shared file. A component owns its tables, and the worker process opens only the store it needs. WAL, so a reader and a writer do not block each other, and a busy timeout so the loser of a write race waits rather than failing the operation it was in the middle of.

Migrations are applied on every open, which drizzle's own ledger makes idempotent. A component never runs against a database older than the schema its queries were written for.

enumCheck and pathSegmentCheck are not optional. text(name, { enum }) is a TypeScript-only refinement that emits no SQL, so a schema relying on it alone generates a column that accepts any string. Both helpers build the constraint from the same const array the column reads, which is what lets code trust an id it read back out of the database without revalidating it.

Before the first release, migrations are rebased rather than appended. Until a node exists whose database matters, a schema change that drizzle-kit expresses as a table rebuild is regenerated into the first migration instead of stacking a second one -- SQLite table recreation cannot add a column and copy it in the same step. After the first release this stops: a migration that has run somewhere is history.