I'll present the comprehensive implementation plan for issue #232. Let me create this as a detailed output:

pipeline-tasks.md tasks from previous issues leak into new pipeline runs, causing stale completed tasks to be injected into the build stage. This happened with issue #207 loading tasks from #154.

The fixes have been implemented across recent commits:

• 1a64c9d0: Clear stale pipeline-tasks.md on initialize/resume
• 4a2f315d: Require positive issue match before injecting
• a730e469: Delete stale file on injection mismatch

This pipeline validates those fixes through comprehensive testing.

Layer 1: Initialize (pipeline-state.sh:462-463)

[[ -n "${TASKS_FILE:-}" ]] && rm -f "$TASKS_FILE"

Clears tasks file on every new pipeline start.

Layer 2: Resume (pipeline-state.sh:607-620)
Validates task metadata matches current issue; deletes if stale/malformed using extract_issue_from_tasks_file().

Layer 3: Build (pipeline-stages-build.sh:172-189)
Triple-checks before injection: valid format, matching issue, deletes on mismatch.

Phase 1: Code Verification

• 1.1 Verify TASKS_FILE initialization across all entry points
• 1.2 Test extract_issue_from_tasks_file() with 5+ metadata formats
• 1.3 Trace issue number normalization (initialize → resume → build)
• 1.4 Check for concurrent pipeline race conditions

Phase 2: Test Coverage

• 2.1 Unit test: extract_issue_from_tasks_file() edge cases
• 2.2 Integration test: stale tasks from issue #X don't inject into #Y
• 2.3 Regression test: exact scenario from #207 (issue #154→#232)
• 2.4 Edge case: resume after partial file deletion
• 2.5 Edge case: file exists but TASKS_FILE variable unset

Phase 3: Implementation Verification

• 3.1 Verify all three deletion paths in production code
• 3.2 Verify extract_issue_from_tasks_file() is sourced
• 3.3 Check no remnants of old "warn + continue" paths

Phase 4: Documentation

• 4.1 Document task file metadata format requirements
• 4.2 Add ADR explaining three-layer validation
• 4.3 Verify warnings logged with debugging context

Decision 1: Clear on both initialize + resume (not just one)

• Redundant but defensive against incomplete state cleanup

Decision 2: Warn + delete + continue (don't fail)

• Graceful degradation; pipeline continues safely

Decision 3: Normalize issue numbers (strip #, whitespace)

• Robust against format variations (#232 == 232 == 232)

When this bug is fixed and validated:

1. ✅ Two sequential pipelines for different issues don't cross-contaminate tasks
2. ✅ Malformed metadata is handled gracefully (warn + delete + continue)
3. ✅ Issue format #232, 232, 232 all normalize correctly
4. ✅ New unit + integration tests cover all three validation layers
5. ✅ Existing tests still pass (no regressions)
6. ✅ Issue #207 scenario (stale #154→#232) is prevented
7. ✅ Documentation explains the three-layer approach

Design Stage: Formalize architecture decisions and test strategy
Build Stage: Write test cases, verify code paths are reachable
Test Stage: Run tests, validate scenario #207 is fixed
Review: Code review of tests
PR: Merge with validation

The plan is ready for the Design stage. The codebase is already modified; now we need comprehensive testing and validation.