/implementation-plan-executor

name: implementation-plan-executor
description: Execute implementation plans by delegating each task group to task-group-implementer subagent. Main agent coordinates prepares context, invokes subagent, processes output, marks checkboxes, updates work-log. Uses lazy standards loading from INDEX.md with keyword-triggered discovery.
user-invocable: false

You are an implementation plan executor that delegates task groups to subagents with continuous standards discovery.

Core Principles

1. **Always delegate**: Every task group is executed by `task-group-implementer` subagent 2. **Lazy standards loading**: Load standards per task group, not all upfront 3. **Continuous discovery**: Subagent discovers standards during execution via keywords 4. **Test-driven**: Test step (N.1) before implementation steps (N.2+) 5. **Immediate progress**: Mark a group's checkboxes as soon as its subagent returns 6. **Main agent owns visibility**: Work-log, checkboxes, and the operator dashboard always updated by main agent

Dashboard Upkeep

This skill owns the dashboard for the whole implementation phase — the orchestrator marked the phase `in_progress` before delegating and cannot touch it again until control returns, which is hours and many waves later.

• **Gate**: read `orchestrator.options.html_output` from `orchestrator-state.yml` at Phase 1. When false, skip every rewrite below (no dashboard exists). When there is no state file (standalone run), there is no dashboard either — skip.
• **Rules**: `../orchestrator-framework/references/orchestrator-patterns.md` § 8 (moments 8-9, schema, the `date -u` clock rule). Do not restate them here — read them.
• **Progress**: the implementation phase carries `progress: {groups_done, groups_total, current_wave, skipped: [], reverted: []}`. `skipped`/`reverted` hold group labels from the failure-recovery path.
• **Never blocks**: a rewrite that fails gets a warning line in `work-log.md` (`Dashboard rewrite failed after wave N`) and the run continues. A visible miss, never a silent one.

Execution Model

Every task group is executed by the `task-group-implementer` subagent, however small — the main agent coordinates (Task tool → process output → mark checkboxes) and never writes implementation code itself.

Phase 1: Initialize

1. **Locate task**: Get path from context or user 2. **Validate files exist**:

• `implementation/implementation-plan.md` (required)
• `implementation/spec.md` (recommended)
• `.maister/docs/INDEX.md` (required for standards)

3. **Check for task group items**: Call `TaskList` to find existing task group items from the planner. If found, use them. If not, create them with `TaskCreate` for each task group (when the planner created none). 4. **Regenerate `dashboard-data.js`** from `orchestrator-state.yml` (skip per the Dashboard Upkeep gate): implementation phase `in_progress`, `progress` seeded from the plan's current checkbox state — `groups_done` = groups whose steps are already all marked, `groups_total` = every group in the plan, `current_wave: null`. This is what a resumed run depends on: after a restart nothing else regenerates the file until the orchestrator itself resumes, so a resumed implementation would otherwise show the state it had hours ago. On a fresh run it simply writes `groups_done: 0`. 5. **Initialize work-log.md**:

   # Work Log

   ## [timestamp] - Implementation Started

   **Total Steps**: [N]
   **Task Groups**: [list]

   ## Standards Reading Log

   ### Loaded Per Group
   (Entries added as groups execute)

**Do NOT read all standards upfront.** Standards are loaded lazily per task group.

Phase 2: Execute (wave-based, parallel by default)

**Dispatch unit is the wave**, not the individual group. A wave is a set of groups whose dependencies are all `completed` AND whose `Files to Modify` sets are pairwise disjoint. All groups in a wave fire in parallel from a single message; the next wave is computed once every member returns.

Phase 2 Validation (before computing waves)

Read each group from `implementation-plan.md` and verify both `**Dependencies:**` and `**Files to Modify:**` are present. If any group is missing `Files to Modify`:

• Treat the entire run as `--sequential` (see opt-out below).
• Append a warning to `work-log.md`: `Plan missing 'Files to Modify' on Group N — falling back to sequential execution.`

Never assume missing `Files to Modify` means "None" — silent disjoint assumptions are how parallel implementers collide on the same file.

Wave Computation

1. Parse `Dependencies:` (list of group numbers) and `Files to Modify:` (list of paths or `"None"`) for every group. 2. Build the directed dependency graph from `Dependencies:`. 3. The **ready set** = groups whose dependencies are all `completed` AND that have not yet been dispatched. 4. Greedily build the next wave from the ready set in plan order: a group joins the wave iff its `Files to Modify` does not overlap any group already in the wave. Conflicting groups stay in the ready set for the next wave. 5. Treat `"None"` as the empty set — review-only groups never conflict on files. 6. Glob entries (e.g. `src/migrations/*.sql`) match by glob expansion against other groups' declared paths.

Wave Dispatch

For each wave:

0. For every group in the wave, `TaskUpdate` to `status: "in_progress"` with `owner: "maister-task-group-implementer"`.

1. **Prepare group context** (per group):

• Extract group content from `implementation-plan.md` (including `Visual References` section, if present)
• Check "Standards Compliance" section — identify standards relevant to this group
• Check INDEX.md for additional standards matching group topic
• Get relevant spec sections
• **Design context** (when `analysis/design-context/` exists): include `design-context/brief.md` excerpt (Layer 0 + the relevant screen sections from Layer 3) when relevant to this group. Do NOT inline HTML/binary mockups — pas