# Phase 4: Execution

**Role**: Orchestrator
**Goal**: Execute all refactoring tasks by delegating to the implement skill
**Constraints**: No inline code changes — all implementation goes through the implement skill's batching and review pipeline

## 4a. Pre-Flight Checks

1. Verify refactoring task files exist in TASKS_DIR (created during Phase 2d):
   - All `[TRACKER-ID]_refactor_*.md` files are present
   - Each task file has valid header fields (Task, Name, Description, Complexity, Dependencies)
2. Verify `TASKS_DIR/_dependencies_table.md` includes the refactoring tasks
3. Verify all tests pass (safety net from Phase 3 is green), unless this is a testability run where Phase 3 was intentionally skipped
4. If any check fails, go back to the relevant phase to fix

## 4b. Delegate to Implement Skill

Read and execute `.cursor/skills/implement/SKILL.md`.

The implement skill will:
1. Parse task files and dependency graph from TASKS_DIR
2. Detect already-completed tasks (skip non-refactoring tasks from prior workflow steps)
3. Compute execution batches for the refactoring tasks
4. Implement tasks sequentially in topological order (no subagents, no parallelism)
5. Run code review after each batch
6. Commit per batch and push only when the user approved pushing
7. Update work item ticket status

Do NOT modify, skip, or abbreviate any part of the implement skill's workflow. The refactor skill is delegating execution, not optimizing it.

## 4c. Capture Results

After the implement skill completes:

1. Read batch reports from `_docs/03_implementation/batch_*_report.md`
2. Read the latest `_docs/03_implementation/implementation_report_*.md` file
3. Write `RUN_DIR/execution_log.md` summarizing:
   - Total tasks executed
   - Batches completed
   - Code review verdicts per batch
   - Files modified (aggregate list)
   - Any blocked or failed tasks
   - Links to batch reports

## 4d. Update Task Statuses

For each successfully completed refactoring task:

1. Transition the work item ticket status to **Done** via the configured tracker MCP
2. If tracker is unavailable, follow `.cursor/rules/tracker.mdc`; if the user explicitly chose `tracker: local`, note the pending status transitions in `RUN_DIR/execution_log.md`

For any failed or blocked tasks, leave their status as-is (the implement skill already set them to In Testing or blocked).

**Self-verification**:
- [ ] All refactoring tasks show as completed in batch reports
- [ ] All completed tasks have work item tracker status set to Done
- [ ] All tests still pass after execution
- [ ] No tasks remain in blocked or failed state (or user has acknowledged them)
- [ ] `RUN_DIR/execution_log.md` written with links to batch reports

**Save action**: Write `RUN_DIR/execution_log.md`

**GATE**: All refactoring tasks must be implemented. If any tasks failed, present the failures to the user and ask for guidance before proceeding to Phase 5.
