Phase 2 PR 1 of the module system (docs/website/MODULE_SYSTEM.md 2.7). The
table and the state machine only: no loader, no routes, no boot wiring, so
nothing an operator or a client can see changes and the route manifest diff
is zero lines.
The five states of 2.4 live in one `state` column: installed -> enabled ->
started, with disabled and startup_failed as the recoverable ones. The row is
a record of what happened, never the source of truth for what is mounted --
the loader scans the filesystem at require time, before the database is
reachable (MODULE_API.md 4.1), which is what keeps routes.manifest.json
generatable against a dead database.
Two rules the model owns and the boot path will lean on:
- Every boot resets each non-disabled row to `enabled` and clears its
recorded failure, so a startup_failed module is retried on the next restart
and a fixed one recovers with no admin-panel visit. `disabled` is the one
operator decision rather than outcome, so it survives untouched -- and a
disabled module's failure is a no-op, never a re-enable.
- A failure carries the stage it happened at, and every non-failing
transition clears it, so a running module can never show a stale reason.
An illegal move throws instead of writing a row that misrepresents the state,
except on the two boot-path softenings noted above, because one module's
failure must never become everybody's.
22 model tests over an in-memory fake; the SQL and the DDL were round-tripped
against a real MariaDB separately.
Co-Authored-By: Claude <noreply@anthropic.com>
wtclaude
3add0063bf