module-gate-batterylisted

# Module: Running the Gates, and Not Believing Them **Loaded by:** `implementing-architect` · `testing-architect` · `code-review-architect` · `deployment-architect` · `maintenance-architect` · `debugging-architect`. Read it when a run reaches the gates; do not restate its content in a skill file. **What this module is not:** it does not resolve the commands. Which command each role maps to comes from the Project Profile (Guidelines §5) and is injected by the plugin's preamble hook. This module holds the *procedure* — order, batching, reporting, and the specific ways a green run can be wrong. --- ## 1. The Order, and the One-Batch Rule Run the gates in the profile's order. Where the profile states none, this is the order, cheapest signal first: `<lint>` → `<typecheck>` → `<test>` (capture coverage) → `<build>` → `<e2e>` → `<visual>` → `<a11y>` → `<audit>` **Run them as one batch and record every result. Do not abort at the first failure** unless that failure genuinely blocks the gates after it (a broken build makes `<e2e>` meaningless; a lint error does not). Stopping at the first red line turns one round of fixes into four, which is the open loop Guidelines §16 forbids. - A role with no command in the profile is **`n-a`** — say so and move on. Never invent a script name to fill a row (Guidelines §15). - A gate that fails is **reported with its output**, never skipped and never summarised into optimism. - One batch → one fix batch → at most one confirming re-run → stop