docs(website): where the module state machine lives, and how boot treats it #125

Merged
whitlocktech merged 1 commits from docs/module-state-machine into main 2026-08-10 19:02:50 +00:00

1 Commits

Author SHA1 Message Date
3510c2ecf1 docs(website): settle where the module state machine lives and how boot treats it
Phase 2 PR 1 of the module system records two things 2.4 left open: the
states are stored in one `state` column rather than a policy flag beside a
runtime one, and every boot recomputes the outcome states while leaving
`disabled` alone.

That second rule is the one with consequences worth writing down -- a
startup_failed module is retried on every restart, so an operator who fixes
the cause needs no admin-panel visit; a running module can never display a
stale failure reason; and disabling, the one operator decision rather than
outcome, survives restarts. Also states what the row does NOT decide: the
loader scans the filesystem before the database is reachable, so the URL
surface is a property of the volume, which is what keeps
routes.manifest.json generatable against a dead database.

BACKEND_DESIGN.md 3 gains the installed_modules columns alongside the other
tables.

Co-Authored-By: Claude <noreply@anthropic.com>
2026-08-10 06:35:37 -05:00