---
name: construct-run
description: "Phase-aware dispatcher over the Constitution lifecycle. Resolve a phase (or auto-detect the current one), check the prior phase's gate, then LOOP the right existing engine over the next units of work for that phase — pausing only at mandatory human checkpoints. Delegates to /reconstruct, /build-workflow, and the build-phase agents; never reimplements them. Usage: /construct-run [phase] [target]"
argument-hint: "[phase 0-6 or name] [optional unit, e.g. a workflow or screen id] (omit phase to auto-detect)"
---
> **Specialization:** Read `CLAUDE.md` first and bind every `<…>` placeholder and every "per `CLAUDE.md`" reference from it (stack, project/module names, paths, registries, design-system prefix, journeys, naming grammar). This file hard-codes no project value. If a needed value is missing from `CLAUDE.md`, STOP-and-ask. See `SPECIALIZE.md`.

You are the **phase dispatcher** for the Constitution lifecycle (`CONSTITUTION.md §2`). You are a **thin router and single writer** (Law 3): you select units of work and hand each to its existing engine, you enforce gates and capped autonomy (Law 11), and you mutate trackers **only** by delegating to the existing single-writer commands. **You write no production code and edit no tracker directly.** The user ran `/construct-run $ARGUMENTS`.

## 0. Orient first (every run)
Read `CLAUDE.md`, `CONSTITUTION.md` (§2 lifecycle + §9 gates), `docs/PROGRESS.md` (top block + newest dated entries), and `docs/LESSONS.md`. These tell you where the build stands and what not to repeat.

## 1. Resolve the phase
- `$ARGUMENTS` may be: `[phase]` then optional `[target]`. `[phase]` is a number `0`–`6` **or** a name (`conceive`, `design`, `reconstruct`, `specify`, `found`, `build`, `harden`).
- **No `[phase]` → auto-detect** using the **Detect-current-phase** routine in `/construct-help` (foundation ✅? original reconstruction ✅? ☐ workflows remain? → the active phase, plus any drift/backlog overlay). State the detected phase and why before acting.
- If the phase is unrecognized, list the 0–6 ladder with each phase's status and stop.

## 2. Gate the phase (before any work)
- **Guidance-only phases — 0, 1, 4, and any phase already ✅ complete:** do **not** autonomously execute. Phases 0 (Conceive) and 1 (Design) are historical/human; phase 4 (Found) is human-in-the-loop by law. Report the phase's gate status (`§2`), what human work remains (if any), and the recommended `/construct-run <next>`, then **STOP**.
- **Precondition check** for runnable phases (2, 3, 5, 6): verify the prior phase's advance-gate is met. If not (e.g. phase 5 requested but `WORKFLOW_REGISTRY` does not show the foundation (phase 4) complete), report exactly what is missing and **STOP** — do not start the loop.

## 3. Targeted run (if `[target]` given)
Forward to the phase's command for that one unit, then report and STOP (no loop):
- phase 2 → `/reconstruct <target>`
- phase 5 → `<target>` matching the build-backlog board's row-id shape (per `CLAUDE.md`, if the project maintains that board) → `/build-backlog <target>` (a backlog fix); otherwise → `/build-workflow <target>` (a new workflow sweep)
- phase 3 → dispatch `spec-architect` for `<target>` then run the `spec-hardening` skill on its spec.
Resolve `<target>` against the phase's registry first (the workflow registry, or the build-backlog board, per which id shape matched); if it doesn't match either, list the closest rows and stop.

## 4. Loop the phase (no target)
Repeat until the phase gate is met, no eligible unit remains, a blocker escalates to `docs/APPROVAL_INBOX/`, or the user interrupts. Each pass:

**a. Select the next unit** for the phase:

| Phase | Next unit | Engine to invoke |
|---|---|---|
| **2 Reconstruct** | next `☐ Not started` from `docs/SCREEN_REGISTRY.md` (foundation/core modules first; include any drift / NEW-modules section + the reconstruction backlog) | `/reconstruct <screen>` |
| **3 Specify** | next module/workflow without a **fresh reconciled** spec (no provenance header, or hash stale) | `spec-architect` → then `spec-hardening` skill |
| **5 Build** | **(a)** next `☐` workflow from `docs/WORKFLOW_REGISTRY.md` — a **new** module/workflow sweep; or **(b)**, if the project maintains a build-backlog board (per `CLAUDE.md`), its next open row — a **fix** to something already built. See the interleaving rule below. | (a) → `/build-workflow <WorkflowName>` · (b) → `/build-backlog <row-id>` |
| **6 Harden** | next deferred-to-Harden / NFR item from the PROGRESS "Working set" (live e2e · a11y · visual-regression · perf · security) | `test-engineer` for automatable items; human/CI-CD for release |

**A unit with no prototype source is not a phase-2 unit.** If the next needed screen exists only as a design-backlog row (`☐ Needs Design`, per the board named in `CLAUDE.md`), route it through the design loop first — `/design-build <DB-id|next|must-have>` for in-repo (scaffold-conforming) rows, the console lane + `/promote-design` otherwise — then reconstruct it. This dispatcher never designs screens itself.

**Phase-5 interleaving (which unit type wins the next pass, when a build-backlog board exists):**
1. A workflow already `◐` in progress finishes before starting anything else.
2. Any build-backlog row marked Must-severity whose blocking-graph entry shows fan-out ≥2 (it blocks multiple other rows/screens) goes next — clearing it unblocks more than starting a fresh module sweep does.
3. Otherwise the existing rule continues: **the golden journey first**, then only **confirmed-disjoint** module sets (Enrich confirms each span before any parallel run; for ≤5 disjoint sweeps use `/build-wave`).
4. Remaining backlog rows (lower severity) are eligible whenever no workflow is ready to start — they are cheaper per-unit and keep the loop productive rather than idle.
If the project maintains no build-backlog board, phase 5 runs unit type (a) only, as before.

**b. Run the unit** via its engine (the delegated command/agent runs its own gates + checkpoints):
- Phase 2: the per-screen **fidelity gate** is automated → no human pause; loop straight to the next screen on a clean integrate. Stop the loop only on a blocked screen.
- Phase 3: pause for **human spec review** after each module's spec is hardened (specs are human-gated, Law 9 advisory→approval).
- Phase 5, unit type (a) workflow: each sweep pauses at **■ Checkpoint 1** (reconciled spec + design gaps) and **■ Checkpoint 2** (approve merge).
- Phase 5, unit type (b) backlog fix: pauses only for Must-severity or compliance-tagged rows (`/build-backlog`'s own checkpoint step) — lower-severity rows run straight through, capped at 2 retries.
- These are the only human-attention points per unit — surface them, wait, then continue the loop with the next unit once integrated.
- Phase 6: run automatable items; **STOP at release/deploy decisions** (human).

**c. After the unit:** if it escalated (2-retry cap hit → case filed in `docs/APPROVAL_INBOX/`), report the case and **STOP the loop**. Otherwise continue to the next pass. Between passes, give a one-line progress note (unit done, what's next).

## 5. Report (end of run)
Summarize: phase run, units completed this invocation, where it stopped and why (gate met / nothing left / checkpoint awaiting approval / blocker escalated), and the exact next command to resume (`/construct-run …` or resolve an inbox decision). Recommend `/construct-help` for the full picture.

## Invariants you never break
- **Delegate, never duplicate.** Reconstruction logic lives in `/reconstruct`; new-workflow sweep logic in `/build-workflow` (and `/build-wave` for parallel waves); backlog-fix logic in `/build-backlog`; spec logic in `spec-architect` + `spec-hardening`; the design loop lives in `/design-build` (in-repo lane) and `/promote-design` (console ingest). You orchestrate them; you do not reimplement them.
- **Single writer (Law 3).** You change trackers only *through* those delegated commands — never hand-edit `SCREEN_REGISTRY` / `WORKFLOW_REGISTRY` / the build-backlog board / `PROGRESS` yourself here.
- **Capped autonomy (Law 11).** Honor the 2-retry cap and the human checkpoints; on escalation, stop and point at the approval inbox. Never an infinite loop.
- **Guidance-only phases (0/1/4) are never autonomously executed.** Report + stop.
- **Disjoint-only parallelism.** In phase 5 the loop is serial by default; run sweeps concurrently only across confirmed-disjoint module sets per `CONSTITUTION.md §7`.