# Workflow registry — the sweep board (phase 5)

> **This is a generic template.** It hard-codes no project values. Claude populates every section by following the project `CLAUDE.md` and the project's `<X>_WORKFLOW` specs (see the generation contract below). Rebind all `<…>` placeholders per project.
>
> The board for **workflow sweeps** (`/build-workflow`). Where `SCREEN_REGISTRY.md` tracks a *screen* through its lifecycle, this tracks a *workflow* through its sweep — the phase-5 unit of delivery.
>
> **Companions:** `SCREEN_REGISTRY.md` (per-screen lifecycle; its `Workflows` column cross-links here) · `PROGRESS.md` (dated log) · `docs/APPROVAL_INBOX/` (parked decisions). Governing law: `CONSTITUTION.md`.

## Generation contract — how Claude fills this in

- **Single-writer rule (Law 3):** ONLY the orchestrator edits this file, at `/build-workflow` integration time. Subagents return structured reports.
- **Workflow rows:** create one row per workflow in the project's **`<X>_WORKFLOW` specs**, plus the **priority journeys named in `CLAUDE.md`** (build those first). On first population, each row is `☐ ☐ ☐ ☐ ☐`.
- **Modules touched / Screens:** fill from each `<X>_WORKFLOW` spec (the modules it spans) and cross-link the screen ids to their rows in `SCREEN_REGISTRY.md`.
- **Golden workflow:** mark the one workflow chosen to run first end-to-end — pick one that exercises the full stack per `CLAUDE.md` (e.g. a relational write + a document store + a realtime update + an audited sensitive write).
- **Naming grammar, module codes, journey ids:** all per `CLAUDE.md` — this template names none.
- **Roll-up & working set:** compute from the rows; refresh at every integration.

## Sweep bar — `E B G R I` (read left→right)

| Pos | Stage | What it means |
|---|---|---|
| **E** | Enrich | `spec-architect` reconciled the workflow + touched-module specs to current design (provenance fresh); `spec-researcher` parity done |
| **B** | Build | `backend-builder` → `migration-engineer` → `seed-builder` → `crosscutting-weaver` → `module-wirer` landed the slices |
| **G** | Gates | `test-engineer`: unit + integration + contract + e2e + a11y + visual-regression green |
| **R** | reView | `reviewer` → PASS |
| **I** | Integrated | single-writer closed seams, deduped/graduated shared design-system classes, updated registries + `PROGRESS.md` |

**Glyphs:** ☐ not started · ◐ in progress · ✅ done · ⚠ blocked (see approval inbox).
**Checkpoints:** `C1` = human approved the reconciled spec + design gaps · `C2` = human approved merge.

---

## Roll-up

| | Count |
|---|---|
| Workflows total | `<n>` |
| Sweeps complete (I ✅) | `<n>` |
| In progress | `<n>` |
| Blocked / inbox | `<n>` |

## Working set

- **In progress ◐:** `<workflow currently sweeping>`
- **Next ☐:** `<next workflow — pick one touching a DISJOINT module set from any in-progress sweep to run in parallel; else serialise>`
- **Blocked ⚠:** `<workflows parked after 2 failed reviewer retries — docs/APPROVAL_INBOX/>`

---

## Priority journeys (build first — the continuity proof)

| Workflow | Modules touched | Screens (→ `SCREEN_REGISTRY`) | E B G R I | C1 | C2 | Last sweep | Notes |
|---|---|---|---|---|---|---|---|
| `<J-id>` | `<modules per CLAUDE.md journey>` | `<route-ids>` | ☐ ☐ ☐ ☐ ☐ | ☐ | ☐ | `<date>` | `<mark the golden workflow here>` |
| _… one row per priority journey named in `CLAUDE.md` …_ | | | | | | | |

## Module workflows

| Workflow | Modules touched | Screens | E B G R I | C1 | C2 | Last sweep | Notes |
|---|---|---|---|---|---|---|---|
| `<WF-id>` | `<MODULE_CODE> · …>` | `<route-ids>` | ☐ ☐ ☐ ☐ ☐ | ☐ | ☐ | `<date>` | `<one-line status>` |
| _… one row per workflow in the project's `<X>_WORKFLOW` specs …_ | | | | | | | |

---

## Parallelism rule (the orchestrator checks before fanning out)

Two sweeps may run concurrently (separate git worktrees / sessions) **only if their `Modules touched` sets are disjoint** and neither modifies a shared kernel / contracts type. If they share a module or a contract, serialise. The `Modules touched` column is the conflict check; the dependency graph in `CLAUDE.md` / the specs is the tie-breaker. The foundation and the golden workflow run **before** any fan-out.