plan-6-v2-implement-phase

Please deep think / ultrathink as this is a complex task.

Implement exactly one approved phase or subtask using the testing approach from the plan. Apply domain placement rules. Update domain.md files after implementation.

📝 LOG DISCOVERIES AS YOU GO

Throughout implementation, capture discoveries in:

Execution Log (execution.log.md) — detailed narrative
Discoveries Table (## Discoveries & Learnings in tasks.md or plan) — structured record

Log when you encounter: something unexpected, needed research, hit a trouble spot, found a gotcha, made a decision, introduced debt, or gained an insight.

🛑 MANDATORY: UPDATE PROGRESS AFTER EVERY TASK — NO EXCEPTIONS

The user watches the task table and execution log for live progress. Keeping them current is highest priority.

After EACH task you MUST update these locations before proceeding to the next task:

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ Per-Task Progress Checklist — use this EVERY time, NO EXCEPTIONS ┃ ┃ ┃ ┃ STARTING T00X: ┃ ┃ [ ] Tasks Table: [ ] → [] ┃ ┃ [ ] Architecture Map: T00X node → :::inprogress (orange) ┃ ┃ ┃ ┃ COMPLETING T00X: ┃ ┃ [ ] Tasks Table: [] → [x] ┃ ┃ [ ] Architecture Map: T00X node → :::completed (green) ┃ ┃ [ ] Architecture Map: File nodes touched → :::completed ┃ ┃ [ ] Execution Log: append task entry with evidence ┃ ┃ [ ] Discoveries table: add any gotchas/insights found ┃ ┃ ┃ ┃ IF BLOCKED: ┃ ┃ [ ] Tasks Table: mark task [!]; note the reason in the Execution Log┃ ┃ [ ] (When unblocked: change back to [~] and continue) ┃ ┃ ┃ ┃ ALL TASKS COMPLETE: ┃ ┃ [ ] Tasks Table: confirm every phase task is [x] ┃ ┃ [ ] Execution Log: append a phase-complete summary ┃ ┃ [ ] PLAN progress section (if present): mark the phase complete ┃ ┃ ┃ ┃ ✓ ALL UPDATES DONE → Proceed to next task ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

Progress lives in the task table (in tasks.md, or inline in the plan for Simple Mode) and the execution log — there is no separate flight-plan file. The journey-level view (the-flow.md) is regenerated by /the-flow itself; this skill never writes it.

DO NOT start the next task until ALL updates above are done.

User input:

$ARGUMENTS
# Expected flags:
# --phase "<Phase N: Title>" (Full Mode) or omitted (Simple Mode)
# --plan "<abs path to plan.md>"
# --subtask "<ORD-subtask-slug>" (optional)

1) Resolve paths:
   PLAN = provided --plan
   PLAN_DIR = dirname(PLAN)

   **Mode Detection**: Read PLAN for `**Mode**: Simple` or `**Mode**: Full`

   **Full Mode**:
   - PHASE_DIR = PLAN_DIR/tasks/${PHASE_SLUG}
   - PHASE_DOC = ${PHASE_DIR}/tasks.md
   - EXEC_LOG = ${PHASE_DIR}/execution.log.md
   - If --subtask: PHASE_DOC = ${PHASE_DIR}/${SUBTASK_KEY}.md

   **Simple Mode**:
   - Check for optional dossier: ${PLAN_DIR}/tasks/implementation/tasks.md
   - If exists → PHASE_DOC = that file
   - If not → PHASE_DOC = PLAN itself (inline tasks from § Implementation)
   - EXEC_LOG = ${PLAN_DIR}/execution.log.md

2) Load context:
   - Read Testing Strategy from plan (approach + mock usage)
   - Read task table from PHASE_DOC
   - Read Context Brief / Key Findings for hazards to watch for
   - **Load domain context**:
     * Read `## Target Domains` from spec
     * Read `## Domain Manifest` from plan
     * For each domain being modified, read `docs/domains/<slug>/domain.md`
   - **Harness availability** (router-only): probe `test -f ~/.agents/skills/eng-harness-flow/SKILL.md` (fallback `~/.claude/skills/eng-harness-flow/SKILL.md`) — the harness is reached exclusively through the `/eng-harness-flow` router; never read governance docs or run health checks yourself

2a) **Pre-Phase Harness Seam — `--event pre-implement`** (router-only):

   **Router not installed** (probe above misses) → if the flow already warned, proceed silently with standard testing; otherwise print exactly once, verbatim:

   > ⚠️ No engineering harness detected — the eng-harness skills aren't installed. Continuing without one: standard testing applies, nothing else changes. (To add the harness loop: `npx skills@latest add AI-Substrate/harness-engineering -a claude-code -g -y`.)

   …then silently omit every harness touchpoint for the rest of the phase (record the outcome once in EXEC_LOG; never re-warn).

   **Router installed** → before starting ANY task, fire the seam:

   `/eng-harness-flow --event pre-implement --phase "<Phase N: Title>" --plan-dir "<PLAN_DIR>" --json`

   Act on the envelope (`decision: route|redirect|noop|ambiguous`): `route` → print-then-offer the returned command (typically the boot validation the router owns); setup-routing/`noop` → one calm line the first time (*"No engineering harness in this repo — proceeding without one; say 'set up a harness' anytime."*), then pass `--prompt-optional=false` on later seam calls. Boot verdicts are narrated **verbatim from the envelope** — vocabulary: `healthy / SLOW / UNHEALTHY / UNAVAILABLE`:
   - `healthy` → proceed to tasks
   - `SLOW` → proceed with note
   - `UNHEALTHY` → **stop and ask human**: "Retry" / "Continue without harness" / "Abort"
   - `UNAVAILABLE` → note and proceed with standard testing

   Log the seam outcome (envelope decision + verdict) to EXEC_LOG. If the human overrides an unhealthy harness, log the override reason. **Never copy the router's internal signals into this skill — delegate, don't reimplement.** Never call the router's child skills directly — children are private and may move.

3) Execute tasks:
   Follow task order. Apply testing approach from plan:

   ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
   ┃ 🛑 STOP! RE-READ "MANDATORY: UPDATE PROGRESS" SECTION ABOVE 🛑       ┃
   ┃                                                                    ┃
   ┃ After EACH task you MUST update ALL locations before proceeding:   ┃
   ┃   1. Tasks Table checkbox                                          ┃
   ┃   2. Architecture Map diagram nodes                                ┃
   ┃   3. Execution log entry                                           ┃
   ┃                                                                    ┃
   ┃ The user is watching the task table + log — update them FIRST.     ┃
   ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

   **Full TDD**: RED-GREEN-REFACTOR loop per task
   **Lightweight**: Minimal validation tests for core functionality
   **Manual**: Document verification steps, execute manually
   **Hybrid**: Apply approach per task annotation

   ### Domain Placement Rules

   1. Every new file MUST go under its declared domain's source directory
   2. Contract files (public interfaces) go in the domain's contracts/ directory
   3. Cross-domain imports MUST use the target domain's public contracts only
      (never import from another domain's internals)
   4. Dependency direction:
      - business → infrastructure: ✅ allowed
      - infrastructure → business: ❌ never
      - business → business: ⚠️ contracts only
   5. When creating a NEW domain (domain setup task):
      - Create `docs/domains/<slug>/domain.md` using format from /extract-domain
      - Create source directory structure
      - Update `docs/domains/registry.md`

4) After ALL tasks complete — update domain files:

   For each domain touched by this phase:

   a) **Update domain.md § History**:
      ```markdown
      | [plan-ordinal-slug] | [What changed — 1 line summary] | [today] |
      ```

   b) **Update domain.md § Composition** (if new services/adapters/repos created):
      Add new rows to the composition table.

   c) **Update domain.md § Contracts** (if public interface changed):
      Add/modify contract entries.

   d) **Update domain.md § Dependencies** (if new domain relationships formed):
      Add to "This Domain Depends On" or "Domains That Depend On This".

   e) **Update domain.md § Source Location** (if new files added):
      Add file paths to source location listing.

   f) **Update docs/domains/registry.md** if domain status changed.

   g) **Update docs/domains/domain-map.md** if:
      - New domain was created → add node with exposed contracts
      - New contracts were added to existing domain → update node label
      - New cross-domain dependency formed → add labeled edge
      - Domain contracts changed → update the Health Summary table

   h) **Update domain.md § Concepts** (if contracts changed or new domain):

      For NEW domains:
        - Create Concepts table from implemented contracts
        - Group related contracts into named concepts (verb phrases)
        - Add narrative + code example per concept (base on actual implemented code)

      For CHANGED contracts:
        - Add new concepts to table if new capabilities introduced
        - Update existing concept narratives if entry points changed
        - Update code examples to match new signatures

      For UNCHANGED contracts: no Concepts updates needed.

5) Output:
   - Execution Log with per-task entries (write incrementally)
   - Unified diffs for all touched files
   - Evidence (test output, verification results)
   - Domain files updated (domain.md changes listed)
   - Final status mapped to acceptance criteria
   - Suggested commit message

6) Auto-run plan-6a-v2-update-progress for each completed task.

   For the **final task of the phase**:
   ```bash
   /plan-6a-v2-update-progress \
     --plan "<PLAN_PATH>" \
     --phase "<Phase N: Title>" \
     --task "<final-task-id>" \
     --status completed

Phase-end harness seam (router-only; skip silently if the router isn't installed — the one-time warning already fired at § 2a):

/eng-harness-flow --event phase-end --plan-dir "<PLAN_DIR>" --json

Act on the envelope; the router owns what happens at the seam (drain-vs-harvest is its decision, never this skill's). Best-effort, never blocks.

STOP: Report phase complete. Suggest next step.


**Next step (Full Mode)**: Run **/plan-7-v2-code-review --phase "<Phase N: Title>" --plan "<PLAN_PATH>"**
**Next step (Simple Mode)**: Run **/plan-7-v2-code-review --plan "<PLAN_PATH>"**
---

## Harness seams (router-only)

This skill fires exactly two harness seams, both through the single entry point `/eng-harness-flow` (children never called directly — they are private and may move):

- **Phase start** — § 2a fires `--event pre-implement --phase --plan-dir` before any task.
- **Phase end** — step 7 fires `--event phase-end --plan-dir` after all tasks and outputs.

The router owns everything behind the door: harness state, boot verdicts, friction capture, retros, drain-vs-harvest. This skill only narrates envelopes verbatim. Best-effort throughout — no router installed means standard testing, one calm warning, and silence.

About this skill

📝 LOG DISCOVERIES AS YOU GO

🛑 MANDATORY: UPDATE PROGRESS AFTER EVERY TASK — NO EXCEPTIONS