process/runbooks/

Purpose

The repeatable checklists run during the module pipeline. The same runbooks apply to every module — they are the fixed process; modules flow through them. Each runbook has a distinct trigger (when it runs) and distinct checks (what it verifies).

Runbooks

Runbook	When it runs	Gate it serves
module-design.md	During a module's design pass	Design-lock (its final part)
smoke-test.md	Repeatedly during build + before ship	—
ship.md	At module delivery	Ship gate

The Module Design Runbook — four parts, run in order

• Part A — Features + gaps. What this module must do: its feature list and the accepted gaps it owns (from business-requirements/ and the gaps registry). Committed, but revisable if a later part surfaces a real conflict.
• Part B — AI-plane application. Which AI Capability Plane capabilities apply, their authority level, ON/OFF behavior, and any persistent AI state they require. Done before schema, because AI state requirements drive table design. Committed, but revisable.
• Part C — Schema design + audit. Design tables to support BOTH the features (A) and the AI state (B). Run the full schema audit (column standards, RLS, constraints, recurring bug classes). Committed, but revisable.
• Part D — Lock gate. The single irreversible checkpoint. Verify functional completeness (every feature + gap from A and every AI need from B is in the schema from C — no orphan requirements, no orphan tables), all docs updated, cross-module seams hold, counts reconcile against DOCS_INDEX.md. → DESIGN-LOCK.

Locking model

One hard lock per module: Part D. Parts A–C are committed checkpoints — revised only if a later part surfaces a genuine conflict. Features, AI plane, and schema freeze together at Part D.

Source of truth

Live status/counts → DOCS_INDEX.md.