Il 2 Implement

# /il_2_implement - Execute Task Loop (Ralph Pattern)

## Description
Executes the implementation loop following the Ralph pattern. **By default, launches a background loop** that autonomously executes all tasks until complete or blocked. This is Step 2 of the core workflow.

The loop script (`.claude/scripts/implement-loop.sh`) provides:
- Fresh context per task (calls Claude CLI for each)
- Automatic retries (up to 3 attempts per task)
- Task logs posted to GitHub issue (with structured JSON event blocks)
- Discovered-task auto-enqueue from task output
- Parallel findings-only code review lane with structured `review_log` events
- Compaction summaries every N task logs
- Wisp collection for ephemeral context hints
- Stops on completion or blocker
- Final review gate before testing checkpoint

For each task, the loop:
1. Reads `prd.json` for task status
2. Picks the next task where `passes: false`
3. Implements the task
4. Runs authoritative verification commands
5. Updates `passes`/`attempts` status in orchestrator
6. Logs learnings to GitHub issue

## Authoritative Execution Gates

The loop now computes canonical outcome in the orchestrator:

1. `verifyCommands` are executed by the loop runner (not trusted from model self-report).
2. `maxTaskAttempts` is enforced when selecting executable tasks.
3. Task sizing is validated before execution (`execution.taskSizing` limits).
4. Event JSON search evidence is validated (`search.queries`, configurable minimum).
5. Context-manifest hash can be validated (`execution.contextManifest`).
6. Added lines are scanned for placeholder patterns (regex + semantic checks).
7. Test intent can be required when tests change (`execution.testIntent`).
8. `execution.gateMode` controls guard behavior:
   - `warn` (default): guard violations are logged, task can still pass if verify passes.
   - `enforce`: guard violations fail the task.
9. Repeated retries trigger a stale-plan checkpoint (`debugState.status = "replan_required"`), with optional auto-replan proposals.

### Two-Tier Verification

- **Fast tier (every task):** task `verifyCommands` + `execution.verify.fastGlobalVerifyCommands`.
- **Full tier (cadence):** `execution.verify.fullGlobalVerifyCommands` every `fullRunEveryNPassedTasks`.
- **Checkpoint gate:** full tier runs before testing checkpoint when `runFullVerifyBeforeTestingCheckpoint=true`.
- Loop state persists counters in `prd.json.quality.execution`:
  - `tasksSinceFullVerify`
  - `lastFullVerifyCommit`
  - `lastFullVerifyAt`

## Hybrid Review Lane (Findings-Only)

The implementation lane and review lane run in parallel:
- After each verified PASS task log, a **code-review agent** is spawned asynchronously.
- The reviewer is **read-only**: no edits, commits, pushes, or `prd.json` mutation.
- Review results are posted as `## 🔎 Code Review: ...` with `### Review Event JSON`.
- The orchestrator is the only writer that can enqueue follow-up tasks.

### Severity Routing
- `critical` findings above confidence threshold auto-enqueue tasks.
- `high` findings remain open for explicit approval.
- Findings are deduplicated by stable key: `reviewId:findingId`.

### Final Gate
- When all implementation tasks pass, a consolidated `FINAL` review runs on `main..HEAD`.
- The loop does not enter testing checkpoint while blocking findings remain open.
- If blocked, label `AI: Review` is applied and follow-up tasks are enqueued.

## Usage

/il_2_implement # Create branch if needed + print terminal launch command /il_2_implement verify # Re-run verification for current task /il_2_implement review-status # Show review lane summary (findings by severity/status) /il_2_implement review-approve <findingId|all> # Approve high findings for enqueue

**Default execution mode is Loop Mode.** This command:
1. Creates the branch from `prd.json` if it doesn't exist
2. Prompts the user to run `.claude/scripts/implement-loop.sh` in a separate terminal for fresh context per task

### ⚠️ Escape Hatch (Breaks Fresh Context)

/implement interactive-mode # ESCAPE HATCH - executes in conversation

**WARNING:** Interactive mode breaks the Ralph pattern's fresh context principle. You will have memory of previous tasks, which defeats the purpose of the memory system. Only use this for debugging when the loop is failing and you need to step through manually.

## Prerequisites
- Issue loaded (`/issue {number}`)
- Plan approved (`/plan approve`)
- `prd.json` exists in repo root

---

## 🚨 CRITICAL REQUIREMENTS - NON-NEGOTIABLE

**These actions are REQUIRED for every task. Do NOT skip any item.**

### After EVERY Task (Pass or Fail), You MUST:

- [ ] **Run local checks when useful** - Orchestrator still runs authoritative verify suite
- [ ] **Do NOT mutate pass/fail in prd.json manually** - Loop updates `passes/attempts/lastAttempt` authoritatively
- [ ] **Commit changes** - Implementation commit (if passed) + prd.json commit
- [ ] **Push to remote** - `git push` after commits
- [ ] **MUST post task log to GitHub** - Use `gh issue comment` with the `## 📝 Task Log: US-XXX` format
- [ ] **MUST post discovery note if patterns found** - If you learn something future tasks need, post `## 🔍 Discovery Note`

### GitHub Posting is MANDATORY

**Task logs MUST be posted to the GitHub issue** after every task attempt. This is not optional.

Format: `gh issue comment $ISSUE_NUMBER --body "## 📝 Task Log: US-XXX ..."`

**Discovery notes MUST be posted** when you discover patterns, gotchas, or learnings that future tasks should know about. This is how the Ralph pattern maintains memory across sessions.

Format: `gh issue comment $ISSUE_NUMBER --body "## 🔍 Discovery Note ..."`

### JSON Event Block (Required in Every Task Log)

Every task log comment **must** include an `### Event JSON` section containing a fenced json code block with a compact JSON event object. This enables structured parsing by the loop.

**Format:**
```markdown
### Event JSON
```json