@projectpac/lib

The mechanics the core plugins and both processes share, and nothing a plugin owns. One package, two entries: the kernel machinery at ., and the SQLite conventions at ./store -- apart so that importing the entry files does not load a native binding.

The kernel machinery

• The app (createApp): the sequence the daemon and the worker both boot through -- a context over the data directory, the fail-loud guards, the loader, and the include that turns an entry file into a mounted tree. What each process does with that tree stays with the process: which files it mounts, what it refuses when a row fails, what it mounts beside the loader.
• Settle audit (auditEntries, formatAudit): the legible report the daemon prints once the plugin tree settles -- a failed entry with its error, a pending entry with the services it is waiting for.
• Canonical bytes (canonicalJson, lengthPrefixed): the one form the bytes a core plugin signs or hashes are built in. Here rather than in either of the two that need it, because two implementations of the same form are two things that agree until one of them is edited.
• The include (pacInclude), the entry files, the pump, and the module-directory resolve both processes read.

Caller derivation is the sdk's (callingEntry), not this package's. Its suite lives here because proving what a nested call attributes to needs the loader and the include to build a tree with.

The store (@projectpac/lib/store)

The SQLite conventions every plugin 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 plugin 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 plugin 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.