process/

Purpose

How we work: the repeatable module pipeline, the gates, and the runbooks. This folder defines the method that every module follows identically — the runbooks are the fixed process; modules flow through them.

What belongs here

• The module pipeline (PIPELINE.md — the ordered flow from design to ship, and where the two gates sit).
• The runbooks (runbooks/): the repeatable checklists.
  • module-design.md — four parts, run in order: Part A Features + gaps → Part B AI-plane application → Part C Schema design + audit → Part D Lock gate (the single DESIGN-LOCK; verifies functional completeness, docs, seams, counts).
  • smoke-test.md — E2E, AI-OFF acceptance, RLS cross-tenant leak; run repeatedly during build and before ship.
  • ship.md — the ship gate: UI live, smoke green, cross-module regression.

The two gates

• Design-lock — Part D of the Module Design Runbook. Features, AI plane, and schema freeze together as a consistent whole. The single hard lock; Parts A–C are committed-but-revisable checkpoints before it.
• Ship — the Ship Runbook. Module is built, tested, and live.

What does NOT belong here

• Any specific module's filled-in artifacts → modules//.
• System architecture → architecture/.

Source of truth

Live status/counts → /index. This folder defines the process, not the project state.