hyperbuild-14-implementlisted

# Step 14 — Implement (THE WAVE LOOP) **⚠ CRITICAL ANTI-PATTERN: writing app code in the orchestrator context is a PIPELINE VIOLATION.** Long-running orchestrators drift into "I'll just implement this one myself" — and produce code that read none of the generated skills, mockups, or feature specs. If you find yourself about to Edit a file under `app/` to implement a task or apply a critic finding, STOP. Spawn `hb-implementer` / `hb-patcher`. Your Edit calls in this step are for frontmatter status flips, manifest updates, patch-log stubs, and new task files — NEVER for code under `app/` (sole carve-out: the hunk-revert recovery in 14.4.6). You are executing step 14 (implement) of the hyperbuild pipeline. Step 13 scaffolded a green, themed, tool-wired app in `app/`; step 15 runs the whole-app adversarial review after every epic here is done. **Stage gate:** Stage B ONLY. Requires manifest `stage: "BUILD"`, `design_choice` set, and `steps."13" = "done"`. Anything missing → STOP, return to the router. **Goal:** every task `done`, every epic reviewed and patched, full test suite green. Why this shape: waves parallelize across the WHOLE task DAG — small tasks with explicit `depends_on` + `files:` make that safe (Implementation granularity rule 4) — while sync points keep every gate honest; a fresh implementer per task survives context rot; a separate test engineer breaks author bias (whoever wrote the code is the wrong one to declare it works); critic + patcher at each epic's c