Workflow Test Fix

<purpose> Unified test-fix orchestrator that combines test planning generation (Phase 1-4) with iterative test-cycle execution (Phase 5) into a single end-to-end pipeline. Creates test sessions with progressive L0-L3 test layers, generates test tasks, then executes them with adaptive fix cycles until pass rate >= 95% or max iterations reached. Triggered via skill name routing for full pipeline or execute-only modes. </purpose>

<process>

1. Architecture Overview

┌───────────────────────────────────────────────────────────────────────────┐
│  Workflow Test Fix Orchestrator (SKILL.md)                                │
│  → Pure coordinator: Route entry point, track progress, pass context      │
│  → Five phases: Session → Context → Analysis → TaskGen → Execution       │
└──────────────────────────────────┬────────────────────────────────────────┘
                                   │
  ┌────────────┬────────────┬──────┴──────┬────────────┬────────────┐
  ↓            ↓            ↓             ↓            ↓
┌──────────┐┌──────────┐┌──────────┐┌──────────┐    ┌──────────────┐
│ Phase 1  ││ Phase 2  ││ Phase 3  ││ Phase 4  │    │  Phase 5     │
│ Session  ││ Context  ││ Analysis ││ Task Gen │    │  Test Cycle  │
│ Start    ││ Gather   ││ Enhanced ││ Generate │    │  Execute     │
│          ││          ││          ││          │    │              │
│ Input    ││ Coverage ││ Gemini   ││ IMPL_PLAN│    │  1. Discovery│
│ Detect + ││ or Code  ││ L0-L3   ││ IMPL-*   │    │  2. Execute  │
│ Session  ││ Scan     ││ AI Issue ││ TODO_LIST│    │  3. Fix Loop │
│ Create   ││          ││          ││          │    │  4. Complete │
└────┬─────┘└────┬─────┘└────┬─────┘└────┬─────┘    └──────────────┘
     │           │           │           │                  ↑
     │testSessionId          │           │                  │
     └──→────────┘contextPath│           │                  │
                  └──→───────┘AnalysisRes│                  │
                               └──→──────┘ testSessionId    │
                                          └──→──(Summary)──→┘

Task Pipeline (generated in Phase 4, executed in Phase 5):
┌──────────────┐   ┌─────────────────┐   ┌─────────────────┐   ┌──────────────┐
│  IMPL-001    │──→│  IMPL-001.3     │──→│  IMPL-001.5     │──→│  IMPL-002    │
│  Test Gen    │   │  Code Validate  │   │  Quality Gate   │   │  Test & Fix  │
│  L1-L3       │   │  L0 + AI Issues │   │  Coverage 80%+  │   │  Max N iter  │
│@code-developer│  │ @test-fix-agent │   │ @test-fix-agent │   │@test-fix-agent│
└──────────────┘   └─────────────────┘   └─────────────────┘   └──────────────┘

2. Key Design Principles

1. Unified Pipeline: Generation and execution are one continuous workflow - no manual handoff 2. Pure Orchestrator: SKILL.md coordinates only - delegates all execution detail to phase files 3. Auto-Continue: Phase 1→2→3→4→(Summary)→5 automatically 4. Task Attachment/Collapse: Sub-tasks attached during phase execution, collapsed after completion 5. Progressive Phase Loading: Phase docs read only when that phase executes, not upfront 6. Adaptive Strategy: Fix loop auto-selects strategy (conservative/aggressive/surgical) based on iteration context 7. Quality Gate: Pass rate >= 95% (criticality-aware) terminates the fix loop 8. Phase File Hygiene: Phase files reference workflowPreferences.* for preferences, no CLI flag parsing

3. Usage

Full pipeline and execute-only modes are triggered by skill name routing (see Mode Detection). Workflow preferences (auto mode) are collected interactively via AskUserQuestion before dispatching to phases.

Full pipeline (workflow-test-fix): Task description or session ID as arguments → interactive preference collection → generate + execute pipeline Execute only (workflow-test-fix): Auto-discovers active session → interactive preference collection → execution loop

4. Interactive Preference Collection

Before dispatching to phase execution, collect workflow preferences via AskUserQuestion:

// ★ 统一 auto mode 检测：-y/--yes 从 $ARGUMENTS 或 ccw 传播
const autoYes = /\b(-y|--yes)\b/.test($ARGUMENTS)

if (autoYes) {
  // 自动模式：跳过所有询问，使用默认值
  workflowPreferences = { autoYes: true }
} else {
  const prefResponse = AskUserQuestion({
    questions: [
      {
        question: "是否跳过所有确认步骤（自动模式）？",
        header: "Auto Mode",
        multiSelect: false,
        options: [
          { label: "Interactive (Recommended)", description: "交互模式，包含确认步骤" },
          { label: "Auto", description: "跳过所有确认，自动执行" }
        ]
      }
    ]
  })

  workflowPreferences = {
    autoYes: prefResponse.autoMode === 'Auto'
  }
}

workflowPreferences is passed to phase execution as context variable, referenced as workflowPreferences.autoYes within phases.

5. Compact Recovery (Phase Persistence)

Multi-phase test-fix pipeline (Phase 1-5) spans long conversations, especially Phase 5 fix loops. Uses 双重保险: TodoWrite 跟踪 active phase 保护其不被压缩，sentinel 作为兜底。

⚠️ COMPACT DIRECTIVE: Context compression MUST check TodoWrite phase status.

The phase currently marked in_progress is the active execution phase — preserve its FULL content.

Only compress phases marked completed or pending.

6. Execution Flow

Entry Point Detection:
   ├─ /workflow-test-fix → Full Pipeline (Phase 1→2→3→4→Summary→5)
   └─ /workflow-test-fix → Execution Only (Phase 5)

Phase 1: Session Start (session-start)
   └─ Read("phases/01-session-start.md")
      ├─ Step 1.0: Detect input mode (session | prompt)
      ├─ Step 1.1: Create test session → testSessionId
      └─ Output: testSessionId, MODE

Phase 2: Test Context Gather (test-context-gather)
   └─ Read("phases/02-test-context-gather.md")
      ├─ Step 1.2: Gather test context → contextPath
      └─ Output: contextPath

Phase 3: Test Concept Enhanced (test-concept-enhanced)
   └─ Read("phases/03-test-concept-enhanced.md")
      ├─ Step 1.3: Test analysis (Gemini) → TEST_ANALYSIS_RESULTS.md
      └─ Output: TEST_ANALYSIS_RESULTS.md

Phase 4: Test Task Generate (test-task-generate)
   └─ Read("phases/04-test-task-generate.md")
      ├─ Step 1.4: Generate test tasks → IMPL_PLAN.md, IMPL-*.json, TODO_LIST.md
      └─ Output: testSessionId, 4+ task JSONs

Summary Output (inline after Phase 4):
   └─ Display summary, auto-continue to Phase 5

Phase 5: Test Cycle Execution (test-cycle-execute)
   └─ Read("phases/05-test-cycle-execute.md")
      ├─ Step 2.1: Discovery (load session, tasks, iteration state)
      ├─ Step 2.2: Execute initial tasks (IMPL-001 → 001.3 → 001.5 → 002)
      ├─ Step 2.3: Fix loop (if pass_rate < 95%)
      │   ├─ Select strategy: conservative/aggressive/surgical
      │   ├─ Generate fix task via @cli-planning-agent
      │   ├─ Execute fix via @test-fix-agent
      │   └─ Re-test → loop or exit
      └─ Step 2.4: Completion (summary, session archive)
         └─ Output: final pass_rate, summary

Phase Reference Documents (read on-demand when phase executes):

Compact Rules: 1. TodoWrite `in_progress` → 保留完整内容，禁止压缩 2. TodoWrite `completed` → 可压缩为摘要 3. 🔄 sentinel fallback → Phase 5 包含 compact sentinel；若 compact 后仅存 sentinel 而无完整 Step 协议，必须立即 Read("phases/05-test-cycle-execute.md") 恢复

7. Core Rules

1. Start Immediately: First action is TaskCreate initialization, second action is Phase 1 (or Phase 5 for execute-only entry) 2. No Preliminary Analysis: Do not read files or gather context before starting the phase 3. Parse Every Output: Extract required data from each step output for next step 4. Auto-Continue: Phase 1→2→3→4→(Summary)→5 automatically (for full pipeline entry) 5. Track Progress: Update TaskCreate/TaskUpdate dynamically with task attachment/collapse pattern 6. Task Attachment Model: Sub-tasks attached during phase, collapsed after completion 7. DO NOT STOP: Continuous workflow until quality gate met or max iterations reached 8. Progressive Loading: Read phase doc ONLY when that phase is about to execute 9. Entry Point Routing: workflow-test-fix skill → Phase 1-5; workflow-test-fix skill → Phase 5 only

8. Input Processing

test-fix-gen Entry (Full Pipeline)

User input → Detect type:
  ├─ Starts with "WFS-" → MODE=session, sourceSessionId=input
  ├─ Ends with ".md"    → MODE=prompt, description=Read(input)
  └─ Otherwise          → MODE=prompt, description=input

test-cycle-execute Entry (Phase 5 Only)

Arguments → Parse flags:
  ├─ --resume-session="WFS-xxx" → sessionId=WFS-xxx
  ├─ --max-iterations=N         → maxIterations=N (default: 10)
  └─ (no args)                  → auto-discover active test session

9. Data Flow

User Input (session ID | description | file path)
    ↓
[Detect Mode: session | prompt]
    ↓
Phase 1: Session Start ─────────────────────────────────────────
    ↓ 1.0+1.1: session:start → testSessionId, MODE
    ↓
Phase 2: Test Context Gather ────────────────────────────────────
    ↓ 1.2: test-context-gather/context-gather → contextPath
    ↓
Phase 3: Test Concept Enhanced ──────────────────────────────────
    ↓ 1.3: test-concept-enhanced → TEST_ANALYSIS_RESULTS.md
    ↓
Phase 4: Test Task Generate ─────────────────────────────────────
    ↓ 1.4: test-task-generate → IMPL_PLAN.md, IMPL-*.json, TODO_LIST.md
    ↓
Summary Output (inline) ─────────────────────────────────────────
    ↓ Display summary with next step
    ↓
Phase 5: Test Cycle Execution ───────────────────────────────────
    ↓ 2.1: Load session + tasks + iteration state
    ↓ 2.2: Execute IMPL-001 → 001.3 → 001.5 → 002
    ↓ 2.3: Fix loop (analyze → fix → retest) until pass_rate >= 95%
    ↓ 2.4: Completion → summary → session archive

10. Summary Output (after Phase 4)

After Phase 4 completes, display the following summary before auto-continuing to Phase 5:

Test-fix workflow created successfully!

Input: [original input]
Mode: [Session|Prompt]
Test Session: [testSessionId]

Tasks Created:
- IMPL-001: Test Understanding & Generation (@code-developer)
- IMPL-001.3: Code Validation Gate - AI Error Detection (@test-fix-agent)
- IMPL-001.5: Test Quality Gate - Static Analysis & Coverage (@test-fix-agent)
- IMPL-002: Test Execution & Fix Cycle (@test-fix-agent)

Quality Thresholds:
- Code Validation: Zero CRITICAL issues, zero compilation errors
- Minimum Coverage: 80% line, 70% branch
- Static Analysis: Zero critical anti-patterns
- Max Fix Iterations: 5

Review artifacts:
- Test plan: .workflow/[testSessionId]/IMPL_PLAN.md
- Task list: .workflow/[testSessionId]/TODO_LIST.md
- Analysis: .workflow/[testSessionId]/.process/TEST_ANALYSIS_RESULTS.md

CRITICAL - Next Step: Auto-continue to Phase 5: Test Cycle Execution. Pass testSessionId to Phase 5 for test execution pipeline. Do NOT wait for user confirmation — the unified pipeline continues automatically.

11. Test Strategy Overview

Progressive Test Layers (L0-L3):

Quality Thresholds:

• Code Validation (IMPL-001.3): Zero CRITICAL issues, zero compilation errors
• Minimum Coverage: 80% line, 70% branch
• Static Analysis (IMPL-001.5): Zero critical anti-patterns
• Pass Rate Gate: >= 95% (criticality-aware) or 100%
• Max Fix Iterations: 10 (default, adjustable)

12. Strategy Engine (Phase 5)

Selection logic and CLI fallback chain (Gemini → Qwen → Codex) are detailed in Phase 5.

13. Agent Roles

14. TodoWrite Pattern

Core Concept: Dynamic task tracking with attachment/collapse for real-time visibility.

Implementation Note: Phase files use TodoWrite syntax to describe the conceptual tracking pattern. At runtime, these are implemented via TaskCreate/TaskUpdate/TaskList tools from the allowed-tools list. Map TodoWrite examples as follows:

- Initial list creation → TaskCreate for each item

- Status changes → TaskUpdate({ taskId, status })

- Sub-task attachment → TaskCreate + TaskUpdate({ addBlockedBy })

- Sub-task collapse → TaskUpdate({ status: "completed" }) + TaskUpdate({ status: "deleted" }) for collapsed sub-items

Full Pipeline (Phase 1-5)

[
  {"content": "Phase 1: Session Start", "status": "in_progress"},
  {"content": "Phase 2: Test Context Gather", "status": "pending"},
  {"content": "Phase 3: Test Analysis (Gemini)", "status": "pending"},
  {"content": "Phase 4: Test Task Generate", "status": "pending"},
  {"content": "Phase 5: Test Cycle Execution", "status": "pending"}
]

Phase 1-4 Collapsed → Phase 5 Active

[
  {"content": "Phase 1: Session Start", "status": "completed"},
  {"content": "Phase 2: Test Context Gather", "status": "completed"},
  {"content": "Phase 3: Test Analysis (Gemini)", "status": "completed"},
  {"content": "Phase 4: Test Task Generate", "status": "completed"},
  {"content": "Phase 5: Test Cycle Execution", "status": "in_progress"},
  {"content": "  → Execute IMPL-001 [code-developer]", "status": "in_progress"},
  {"content": "  → Execute IMPL-001.3 [test-fix-agent]", "status": "pending"},
  {"content": "  → Execute IMPL-001.5 [test-fix-agent]", "status": "pending"},
  {"content": "  → Execute IMPL-002 [test-fix-agent]", "status": "pending"},
  {"content": "  → Fix Loop", "status": "pending"}
]

Fix Loop Iterations

[
  {"content": "Phase 1-4: Test Generation", "status": "completed"},
  {"content": "Phase 5: Test Cycle Execution", "status": "in_progress"},
  {"content": "  → Initial tasks", "status": "completed"},
  {"content": "  → Iteration 1: Initial test (pass: 70%, conservative)", "status": "completed"},
  {"content": "  → Iteration 2: Fix validation (pass: 82%, conservative)", "status": "completed"},
  {"content": "  → Iteration 3: Batch fix (pass: 89%, aggressive)", "status": "in_progress"}
]

15. Session File Structure

.workflow/active/WFS-test-{session}/
├── workflow-session.json              # Session metadata
├── IMPL_PLAN.md                       # Test generation and execution strategy
├── TODO_LIST.md                       # Task checklist
├── .task/
│   ├── IMPL-001.json                  # Test understanding & generation
│   ├── IMPL-001.3-validation.json     # Code validation gate
│   ├── IMPL-001.5-review.json         # Test quality gate
│   ├── IMPL-002.json                  # Test execution & fix cycle
│   └── IMPL-fix-{N}.json             # Generated fix tasks (Phase 5 fix loop)
├── .process/
│   ├── [test-]context-package.json    # Context and coverage analysis
│   ├── TEST_ANALYSIS_RESULTS.md       # Test requirements (L0-L3)
│   ├── iteration-state.json           # Current iteration + strategy + stuck tests
│   ├── test-results.json              # Latest results (pass_rate, criticality)
│   ├── test-output.log                # Full test output
│   ├── fix-history.json               # All fix attempts
│   ├── iteration-{N}-analysis.md      # CLI analysis report
│   └── iteration-{N}-cli-output.txt
└── .summaries/
    └── iteration-summaries/

16. Error Handling

Phase 1-4 (Generation)

Phase 5 (Execution)

17. Commit Strategy (Phase 5)

Automatic commits at key checkpoints: 1. After successful iteration (pass rate increased): test-cycle: iteration N - strategy (pass: old% → new%) 2. Before rollback (regression detected): test-cycle: rollback iteration N - regression detected

18. Completion Conditions

19. Post-Completion Expansion

Auto-sync: Execute /workflow:session:sync -y "{summary}" to update specs/*.md + project-tech.

After completion, ask user if they want to expand into issues (test/enhance/refactor/doc). Selected items call /issue:new "{summary} - {dimension}".

20. Coordinator Checklist

Phase 1 (session-start)

• [ ] Detect input type (session ID / description / file path)
• [ ] Initialize TaskCreate before any execution
• [ ] Read("phases/01-session-start.md"), execute Steps 1.0 + 1.1
• [ ] Parse testSessionId from step output, store in memory

Phase 2 (test-context-gather)

• [ ] Read("phases/02-test-context-gather.md"), execute Step 1.2
• [ ] Parse contextPath from step output, store in memory

Phase 3 (test-concept-enhanced)

• [ ] Read("phases/03-test-concept-enhanced.md"), execute Step 1.3
• [ ] Verify TEST_ANALYSIS_RESULTS.md created

Phase 4 (test-task-generate)

• [ ] Read("phases/04-test-task-generate.md"), execute Step 1.4
• [ ] Verify all Phase 1-4 outputs (4 task JSONs, IMPL_PLAN.md, TODO_LIST.md)
• [ ] Display Summary output (inline)
• [ ] Collapse Phase 1-4 tasks, auto-continue to Phase 5

Phase 5 (test-cycle-execute)

• [ ] Read("phases/05-test-cycle-execute.md")
• [ ] Load session, tasks, iteration state
• [ ] Execute initial tasks sequentially
• [ ] Calculate pass rate from test-results.json
• [ ] If pass_rate < 95%: Enter fix loop
• [ ] Track iteration count, stuck tests, regression
• [ ] If pass_rate >= 95% or max iterations: Complete
• [ ] Generate completion summary
• [ ] Offer post-completion expansion

21. Related Skills

Prerequisite Skills:

• workflow-plan skill or workflow-execute skill - Complete implementation (Session Mode source)
• None for Prompt Mode

Follow-up Skills:

• Display session status inline - Review workflow state
• review-cycle skill - Post-implementation review
• /issue:new - Create follow-up issues

</process>

<auto_mode> When -y or --yes is detected in $ARGUMENTS or propagated via ccw:

• Skip all AskUserQuestion confirmations
• Use default values for all workflow preferences (workflowPreferences = { autoYes: true })
• Auto-continue through all phases without user interaction
• Phase 1→2→3→4→Summary→5 executes as a fully automatic pipeline

</auto_mode>

<success_criteria>

• [ ] Input type correctly detected (session ID / description / file path)
• [ ] All 5 phases execute in sequence (full pipeline) or Phase 5 only (execute-only)
• [ ] Phase documents loaded progressively via Read() only when phase executes
• [ ] TaskCreate/TaskUpdate tracking maintained throughout with attachment/collapse pattern
• [ ] All phase outputs parsed and passed to subsequent phases (testSessionId, contextPath, etc.)
• [ ] Summary displayed after Phase 4 with all task and threshold details
• [ ] Phase 5 fix loop iterates with adaptive strategy until pass rate >= 95% or max iterations
• [ ] Completion summary generated with final pass rate and session archived
• [ ] Post-completion expansion offered to user

</success_criteria>

Phase 1: Session Start (session-start)

Detect input mode and create test workflow session.

Objective

• Detect input mode (session ID vs description)
• Create test workflow session with appropriate metadata

Execution

Step 1.0: Detect Input Mode

// Automatic mode detection based on input pattern
if (input.startsWith("WFS-")) {
  MODE = "session"
  // Load source session to preserve original task description
  Read(".workflow/active/[sourceSessionId]/workflow-session.json")
} else {
  MODE = "prompt"
}

Step 1.1: Create Test Session

// Session Mode - preserve original task description
Skill(skill="workflow:session:start", args="--type test --new \"Test validation for [sourceSessionId]: [originalTaskDescription]\"")

// Prompt Mode - use user's description directly
Skill(skill="workflow:session:start", args="--type test --new \"Test generation for: [description]\"")

Parse Output:

• Extract: SESSION_ID: WFS-test-[slug] (store as testSessionId)

Validation:

• Session Mode: Source session .workflow/active/[sourceSessionId]/ exists with completed IMPL tasks
• Both Modes: New test session directory created with metadata

TodoWrite: Mark step 1.1 completed, step 1.2 in_progress

Session Metadata

File: workflow-session.json

Output

• Variable: testSessionId (WFS-test-xxx)
• Variable: MODE (session | prompt)

Next Phase

Continue to Phase 2: Test Context Gather.

Phase 2: Test Context Gather (test-context-gather)

Gather test context via coverage analysis or codebase scan.

Objective

• Gather test context (coverage analysis or codebase scan)
• Generate context package for downstream analysis

Execution

Step 1.2: Gather Test Context

Two modes are available depending on whether a source session exists:

---

Mode A: Session Mode (gather from source session)

Collect test coverage context using test-context-search-agent and package into standardized test-context JSON.

Core Philosophy

• Agent Delegation: Delegate all test coverage analysis to test-context-search-agent for autonomous execution
• Detection-First: Check for existing test-context-package before executing
• Coverage-First: Analyze existing test coverage before planning new tests
• Source Context Loading: Import implementation summaries from source session
• Standardized Output: Generate .workflow/active/{test_session_id}/.process/test-context-package.json

Step A.1: Test-Context-Package Detection

Execute First - Check if valid package already exists:

const testContextPath = `.workflow/${test_session_id}/.process/test-context-package.json`;

if (file_exists(testContextPath)) {
  const existing = Read(testContextPath);

  // Validate package belongs to current test session
  if (existing?.metadata?.test_session_id === test_session_id) {
    console.log("Valid test-context-package found for session:", test_session_id);
    console.log("Coverage Stats:", existing.test_coverage.coverage_stats);
    console.log("Framework:", existing.test_framework.framework);
    console.log("Missing Tests:", existing.test_coverage.missing_tests.length);
    return existing; // Skip execution, return existing
  } else {
    console.warn("Invalid test_session_id in existing package, re-generating...");
  }
}

Step A.2: Invoke Test-Context-Search Agent

Only execute if Step A.1 finds no valid package

Task(
  subagent_type="test-context-search-agent",
  run_in_background=false,
  description="Gather test coverage context",
  prompt=`

## Execution Mode
**PLAN MODE** (Comprehensive) - Full Phase 1-3 execution

## Session Information
- **Test Session ID**: ${test_session_id}
- **Output Path**: .workflow/${test_session_id}/.process/test-context-package.json

## Mission
Execute complete test-context-search-agent workflow for test generation planning:

### Phase 1: Session Validation & Source Context Loading
1. **Detection**: Check for existing test-context-package (early exit if valid)
2. **Test Session Validation**: Load test session metadata, extract source_session reference
3. **Source Context Loading**: Load source session implementation summaries, changed files, tech stack

### Phase 2: Test Coverage Analysis
Execute coverage discovery:
- **Track 1**: Existing test discovery (find *.test.*, *.spec.* files)
- **Track 2**: Coverage gap analysis (match implementation files to test files)
- **Track 3**: Coverage statistics (calculate percentages, identify gaps by module)

### Phase 3: Framework Detection & Packaging
1. Framework identification from package.json/requirements.txt
2. Convention analysis from existing test patterns
3. Generate and validate test-context-package.json

## Output Requirements
Complete test-context-package.json with:
- **metadata**: test_session_id, source_session_id, task_type, complexity
- **source_context**: implementation_summaries, tech_stack, project_patterns
- **test_coverage**: existing_tests[], missing_tests[], coverage_stats
- **test_framework**: framework, version, test_pattern, conventions
- **assets**: implementation_summary[], existing_test[], source_code[] with priorities
- **focus_areas**: Test generation guidance based on coverage gaps

## Quality Validation
Before completion verify:
- [ ] Valid JSON format with all required fields
- [ ] Source session context loaded successfully
- [ ] Test coverage gaps identified
- [ ] Test framework detected (or marked as 'unknown')
- [ ] Coverage percentage calculated correctly
- [ ] Missing tests catalogued with priority
- [ ] Execution time < 30 seconds (< 60s for large codebases)

Execute autonomously following agent documentation.
Report completion with coverage statistics.
`
)

Step A.3: Output Verification

After agent completes, verify output:

// Verify file was created
const outputPath = `.workflow/${test_session_id}/.process/test-context-package.json`;
if (!file_exists(outputPath)) {
  throw new Error("Agent failed to generate test-context-package.json");
}

// Load and display summary
const testContext = Read(outputPath);
console.log("Test context package generated successfully");
console.log("Coverage:", testContext.test_coverage.coverage_stats.coverage_percentage + "%");
console.log("Tests to generate:", testContext.test_coverage.missing_tests.length);

---

Mode B: Prompt Mode (gather from codebase)

Intelligently collect project context using context-search-agent based on task description, packages into standardized JSON.

Core Philosophy

• Agent Delegation: Delegate all discovery to context-search-agent for autonomous execution
• Detection-First: Check for existing context-package before executing
• Plan Mode: Full comprehensive analysis (vs lightweight brainstorm mode)
• Standardized Output: Generate .workflow/active/{session}/.process/context-package.json

Step B.1: Context-Package Detection

Execute First - Check if valid package already exists:

const contextPackagePath = `.workflow/${session_id}/.process/context-package.json`;

if (file_exists(contextPackagePath)) {
  const existing = Read(contextPackagePath);

  // Validate package belongs to current session
  if (existing?.metadata?.session_id === session_id) {
    console.log("Valid context-package found for session:", session_id);
    console.log("Stats:", existing.statistics);
    console.log("Conflict Risk:", existing.conflict_detection.risk_level);
    return existing; // Skip execution, return existing
  } else {
    console.warn("Invalid session_id in existing package, re-generating...");
  }
}

Step B.2: Complexity Assessment & Parallel Explore

Only execute if Step B.1 finds no valid package

// B.2.1 Complexity Assessment
function analyzeTaskComplexity(taskDescription) {
  const text = taskDescription.toLowerCase();
  if (/architect|refactor|restructure|modular|cross-module/.test(text)) return 'High';
  if (/multiple|several|integrate|migrate|extend/.test(text)) return 'Medium';
  return 'Low';
}

const ANGLE_PRESETS = {
  architecture: ['architecture', 'dependencies', 'modularity', 'integration-points'],
  security: ['security', 'auth-patterns', 'dataflow', 'validation'],
  performance: ['performance', 'bottlenecks', 'caching', 'data-access'],
  bugfix: ['error-handling', 'dataflow', 'state-management', 'edge-cases'],
  feature: ['patterns', 'integration-points', 'testing', 'dependencies'],
  refactor: ['architecture', 'patterns', 'dependencies', 'testing']
};

function selectAngles(taskDescription, complexity) {
  const text = taskDescription.toLowerCase();
  let preset = 'feature';
  if (/refactor|architect|restructure/.test(text)) preset = 'architecture';
  else if (/security|auth|permission/.test(text)) preset = 'security';
  else if (/performance|slow|optimi/.test(text)) preset = 'performance';
  else if (/fix|bug|error|issue/.test(text)) preset = 'bugfix';

  const count = complexity === 'High' ? 4 : (complexity === 'Medium' ? 3 : 1);
  return ANGLE_PRESETS[preset].slice(0, count);
}

const complexity = analyzeTaskComplexity(task_description);
const selectedAngles = selectAngles(task_description, complexity);
const sessionFolder = `.workflow/active/${session_id}/.process`;

// B.2.2 Launch Parallel Explore Agents
const explorationTasks = selectedAngles.map((angle, index) =>
  Task(
    subagent_type="cli-explore-agent",
    run_in_background=false,
    description=`Explore: ${angle}`,
    prompt=`
## Task Objective
Execute **${angle}** exploration for task planning context. Analyze codebase from this specific angle to discover relevant structure, patterns, and constraints.

## Assigned Context
- **Exploration Angle**: ${angle}
- **Task Description**: ${task_description}
- **Session ID**: ${session_id}
- **Exploration Index**: ${index + 1} of ${selectedAngles.length}
- **Output File**: ${sessionFolder}/exploration-${angle}.json

## MANDATORY FIRST STEPS (Execute by Agent)
1. Run: ccw tool exec get_modules_by_depth '{}' (project structure)
2. Run: rg -l "{keyword_from_task}" --type ts (locate relevant files)
3. Execute: cat ~/.ccw/workflows/cli-templates/schemas/explore-json-schema.json (get output schema reference)

## Exploration Strategy (${angle} focus)

**Step 1: Structural Scan** (Bash)
- get_modules_by_depth.sh -> identify modules related to ${angle}
- find/rg -> locate files relevant to ${angle} aspect
- Analyze imports/dependencies from ${angle} perspective

**Step 2: Semantic Analysis** (Gemini CLI)
- How does existing code handle ${angle} concerns?
- What patterns are used for ${angle}?
- Where would new code integrate from ${angle} viewpoint?

**Step 3: Write Output**
- Consolidate ${angle} findings into JSON
- Identify ${angle}-specific clarification needs

## Expected Output

**File**: ${sessionFolder}/exploration-${angle}.json

**Schema Reference**: Schema obtained in MANDATORY FIRST STEPS step 3, follow schema exactly

**Required Fields** (all ${angle} focused):
- project_structure: Modules/architecture relevant to ${angle}
- relevant_files: Files affected from ${angle} perspective
  **MANDATORY**: Every file MUST use structured object format with ALL required fields:
  [{path: "src/file.ts", relevance: 0.85, rationale: "Contains AuthService.login() - entry point for JWT token generation", role: "modify_target", discovery_source: "bash-scan", key_symbols: ["AuthService", "login"]}]
  - **rationale** (required): Specific selection basis tied to ${angle} topic (>10 chars, not generic)
  - **role** (required): modify_target|dependency|pattern_reference|test_target|type_definition|integration_point|config|context_only
  - **discovery_source** (recommended): bash-scan|cli-analysis|ace-search|dependency-trace|manual
  - **key_symbols** (recommended): Key functions/classes/types in the file relevant to the task
  - Scores: 0.7+ high priority, 0.5-0.7 medium, <0.5 low
- patterns: ${angle}-related patterns to follow
- dependencies: Dependencies relevant to ${angle}
- integration_points: Where to integrate from ${angle} viewpoint (include file:line locations)
- constraints: ${angle}-specific limitations/conventions
- clarification_needs: ${angle}-related ambiguities (options array + recommended index)
- _metadata.exploration_angle: "${angle}"

## Success Criteria
- [ ] Schema obtained via cat explore-json-schema.json
- [ ] get_modules_by_depth.sh executed
- [ ] At least 3 relevant files identified with ${angle} rationale
- [ ] Patterns are actionable (code examples, not generic advice)
- [ ] Integration points include file:line locations
- [ ] Constraints are project-specific to ${angle}
- [ ] JSON output follows schema exactly
- [ ] clarification_needs includes options + recommended

## Output
Write: ${sessionFolder}/exploration-${angle}.json
Return: 2-3 sentence summary of ${angle} findings
`
  )
);

// B.2.3 Generate Manifest after all complete
const explorationFiles = bash(`find ${sessionFolder} -name "exploration-*.json" -type f`).split('\n').filter(f => f.trim());
const explorationManifest = {
  session_id,
  task_description,
  timestamp: new Date().toISOString(),
  complexity,
  exploration_count: selectedAngles.length,
  angles_explored: selectedAngles,
  explorations: explorationFiles.map(file => {
    const data = JSON.parse(Read(file));
    return { angle: data._metadata.exploration_angle, file: file.split('/').pop(), path: file, index: data._metadata.exploration_index };
  })
};
Write(`${sessionFolder}/explorations-manifest.json`, JSON.stringify(explorationManifest, null, 2));

Step B.3: Invoke Context-Search Agent

Only execute after Step B.2 completes

// Load user intent from planning-notes.md (from Phase 1)
const planningNotesPath = `.workflow/active/${session_id}/planning-notes.md`;
let userIntent = { goal: task_description, key_constraints: "None specified" };

if (file_exists(planningNotesPath)) {
  const notesContent = Read(planningNotesPath);
  const goalMatch = notesContent.match(/\*\*GOAL\*\*:\s*(.+)/);
  const constraintsMatch = notesContent.match(/\*\*KEY_CONSTRAINTS\*\*:\s*(.+)/);
  if (goalMatch) userIntent.goal = goalMatch[1].trim();
  if (constraintsMatch) userIntent.key_constraints = constraintsMatch[1].trim();
}

Task(
  subagent_type="context-search-agent",
  run_in_background=false,
  description="Gather comprehensive context for plan",
  prompt=`
## Execution Mode
**PLAN MODE** (Comprehensive) - Full Phase 1-3 execution with priority sorting

## Session Information
- **Session ID**: ${session_id}
- **Task Description**: ${task_description}
- **Output Path**: .workflow/${session_id}/.process/context-package.json

## User Intent (from Phase 1 - Planning Notes)
**GOAL**: ${userIntent.goal}
**KEY_CONSTRAINTS**: ${userIntent.key_constraints}

This is the PRIMARY context source - all subsequent analysis must align with user intent.

## Exploration Input (from Step B.2)
- **Manifest**: ${sessionFolder}/explorations-manifest.json
- **Exploration Count**: ${explorationManifest.exploration_count}
- **Angles**: ${explorationManifest.angles_explored.join(', ')}
- **Complexity**: ${complexity}

## Mission
Execute complete context-search-agent workflow for implementation planning:

### Phase 1: Initialization & Pre-Analysis
1. **Project State Loading**:
   - Run: \`ccw spec load --category execution\` to load project context, tech stack, and guidelines.
   - Run: \`ccw spec load --category test\` to load test framework conventions, coverage targets, and fixtures.
   - If files don't exist, proceed with fresh analysis.
2. **Detection**: Check for existing context-package (early exit if valid)
3. **Foundation**: Initialize CodexLens, get project structure, load docs
4. **Analysis**: Extract keywords, determine scope, classify complexity based on task description and project state

### Phase 2: Multi-Source Context Discovery
Execute all discovery tracks (WITH USER INTENT INTEGRATION):
- **Track -1**: User Intent & Priority Foundation (EXECUTE FIRST)
  - Load user intent (GOAL, KEY_CONSTRAINTS) from session input
  - Map user requirements to codebase entities (files, modules, patterns)
  - Establish baseline priority scores based on user goal alignment
  - Output: user_intent_mapping.json with preliminary priority scores

- **Track 0**: Exploration Synthesis (load explorations-manifest.json, prioritize critical_files, deduplicate patterns/integration_points)
- **Track 1**: Historical archive analysis (query manifest.json for lessons learned)
- **Track 2**: Reference documentation (CLAUDE.md, architecture docs)
- **Track 3**: Web examples (use Exa MCP for unfamiliar tech/APIs)
- **Track 4**: Codebase analysis (5-layer discovery: files, content, patterns, deps, config/tests)

### Phase 3: Synthesis, Assessment & Packaging
1. Apply relevance scoring and build dependency graph
2. **Synthesize 5-source data** (including Track -1): Merge findings from all sources
   - Priority order: User Intent > Archive > Docs > Exploration > Code > Web
   - **Prioritize the context from project-tech.json** for architecture and tech stack unless code analysis reveals it's outdated
3. **Context Priority Sorting**:
   a. Combine scores from Track -1 (user intent alignment) + relevance scores + exploration critical_files
   b. Classify files into priority tiers:
      - **Critical** (score >= 0.85): Directly mentioned in user goal OR exploration critical_files
      - **High** (0.70-0.84): Key dependencies, patterns required for goal
      - **Medium** (0.50-0.69): Supporting files, indirect dependencies
      - **Low** (< 0.50): Contextual awareness only
   c. Generate dependency_order: Based on dependency graph + user goal sequence
   d. Document sorting_rationale: Explain prioritization logic
4. **Populate project_context**: Directly use the overview from project-tech.json
5. **Populate project_guidelines**: Load from specs/*.md
6. Integrate brainstorm artifacts (if .brainstorming/ exists, read content)
7. Perform conflict detection with risk assessment
8. **Inject historical conflicts** from archive analysis into conflict_detection
9. **Generate prioritized_context section**:
   {
     "prioritized_context": {
       "user_intent": { "goal": "...", "scope": "...", "key_constraints": ["..."] },
       "priority_tiers": {
         "critical": [{ "path": "...", "relevance": 0.95, "rationale": "..." }],
         "high": [...], "medium": [...], "low": [...]
       },
       "dependency_order": ["module1", "module2", "module3"],
       "sorting_rationale": "Based on user goal alignment, exploration critical files, and dependency graph"
     }
   }
10. Generate and validate context-package.json with prioritized_context field

## Output Requirements
Complete context-package.json with:
- **metadata**: task_description, keywords, complexity, tech_stack, session_id
- **project_context**: description, technology_stack, architecture, key_components (from project-tech.json)
- **project_guidelines**: {conventions, constraints, quality_rules, learnings} (from specs/*.md)
- **assets**: {documentation[], source_code[], config[], tests[]} with relevance scores
- **dependencies**: {internal[], external[]} with dependency graph
- **brainstorm_artifacts**: {guidance_specification, role_analyses[], synthesis_output} with content
- **conflict_detection**: {risk_level, risk_factors, affected_modules[], mitigation_strategy, historical_conflicts[]}
- **exploration_results**: {manifest_path, exploration_count, angles, explorations[], aggregated_insights}
- **prioritized_context**: {user_intent, priority_tiers{critical, high, medium, low}, dependency_order[], sorting_rationale}

## Quality Validation
Before completion verify:
- [ ] Valid JSON format with all required fields
- [ ] File relevance accuracy >80%
- [ ] Dependency graph complete (max 2 transitive levels)
- [ ] Conflict risk level calculated correctly
- [ ] No sensitive data exposed
- [ ] Total files <= 50 (prioritize high-relevance)

Execute autonomously following agent documentation.
Report completion with statistics.
`
)

Step B.4: Output Verification

After agent completes, verify output:

// Verify file was created
const outputPath = `.workflow/${session_id}/.process/context-package.json`;
if (!file_exists(outputPath)) {
  throw new Error("Agent failed to generate context-package.json");
}

// Verify exploration_results included
const pkg = JSON.parse(Read(outputPath));
if (pkg.exploration_results?.exploration_count > 0) {
  console.log(`Exploration results aggregated: ${pkg.exploration_results.exploration_count} angles`);
}

---

Input: testSessionId from Phase 1

Parse Output:

• Extract: context package path (store as contextPath)
• Pattern: .workflow/active/[testSessionId]/.process/[test-]context-package.json

Validation:

• Context package file exists and is valid JSON
• Contains coverage analysis (session mode) or codebase analysis (prompt mode)
• Test framework detected

TodoWrite Update (tasks attached):

[
  {"content": "Phase 1: Test Generation", "status": "in_progress"},
  {"content": "  -> Create test session", "status": "completed"},
  {"content": "  -> Gather test context", "status": "in_progress"},
  {"content": "    -> Load source/codebase context", "status": "in_progress"},
  {"content": "    -> Analyze test coverage", "status": "pending"},
  {"content": "    -> Generate context package", "status": "pending"},
  {"content": "  -> Test analysis (Gemini)", "status": "pending"},
  {"content": "  -> Generate test tasks", "status": "pending"},
  {"content": "Phase 2: Test Cycle Execution", "status": "pending"}
]

TodoWrite Update (tasks collapsed):

[
  {"content": "Phase 1: Test Generation", "status": "in_progress"},
  {"content": "  -> Create test session", "status": "completed"},
  {"content": "  -> Gather test context", "status": "completed"},
  {"content": "  -> Test analysis (Gemini)", "status": "pending"},
  {"content": "  -> Generate test tasks", "status": "pending"},
  {"content": "Phase 2: Test Cycle Execution", "status": "pending"}
]

Output

• Variable: contextPath (context-package.json path)

Next Phase

Continue to Phase 3: Test Concept Enhanced.

Phase 3: Test Concept Enhanced (test-concept-enhanced)

Analyze test requirements with Gemini using progressive L0-L3 test layers.

Objective

• Use Gemini to analyze coverage gaps
• Detect project type and apply appropriate test templates
• Generate multi-layered test requirements (L0-L3)
• Scan for AI code issues

Core Philosophy

• Coverage-Driven: Focus on identified test gaps from context analysis
• Pattern-Based: Learn from existing tests and project conventions
• Gemini-Powered: Use Gemini for test requirement analysis and strategy design
• Single-Round Analysis: Comprehensive test analysis in one execution
• No Code Generation: Strategy and planning only, actual test generation happens in task execution

Core Responsibilities

• Coordinate test analysis workflow using cli-execution-agent
• Validate test-context-package.json prerequisites
• Execute Gemini analysis via agent for test strategy generation
• Validate agent outputs (gemini-test-analysis.md, TEST_ANALYSIS_RESULTS.md)

Execution

Step 1.3: Test Generation Analysis

Phase 1: Context Preparation

Command prepares session context and validates prerequisites.

1. Session Validation

• Load .workflow/active/{test_session_id}/workflow-session.json
• Verify test session type is "test-gen"
• Extract source session reference

2. Context Package Validation

• Read test-context-package.json
• Validate required sections: metadata, source_context, test_coverage, test_framework
• Extract coverage gaps and framework details

3. Strategy Determination

• Simple (1-3 files): Single Gemini analysis
• Medium (4-6 files): Comprehensive analysis
• Complex (>6 files): Modular analysis approach

Phase 2: Test Analysis Execution

Purpose: Analyze test coverage gaps and generate comprehensive test strategy.

Task(
  subagent_type="cli-execution-agent",
  run_in_background=false,
  description="Analyze test coverage gaps and generate test strategy",
  prompt=`
## TASK OBJECTIVE
Analyze test requirements and generate comprehensive test generation strategy using Gemini CLI

## EXECUTION CONTEXT
Session: {test_session_id}
Source Session: {source_session_id}
Working Dir: .workflow/active/{test_session_id}/.process
Template: ~/.ccw/workflows/cli-templates/prompts/test/test-concept-analysis.txt

## EXECUTION STEPS
1. Execute Gemini analysis:
   ccw cli -p "..." --tool gemini --mode write --rule test-test-concept-analysis --cd .workflow/active/{test_session_id}/.process

2. Generate TEST_ANALYSIS_RESULTS.md:
   Synthesize gemini-test-analysis.md into standardized format for task generation
   Include: coverage assessment, test framework, test requirements, generation strategy, implementation targets

## EXPECTED OUTPUTS
1. gemini-test-analysis.md - Raw Gemini analysis
2. TEST_ANALYSIS_RESULTS.md - Standardized test requirements document

## QUALITY VALIDATION
- Both output files exist and are complete
- All required sections present in TEST_ANALYSIS_RESULTS.md
- Test requirements are actionable and quantified
- Test scenarios cover happy path, errors, edge cases
- Dependencies and mocks clearly identified
`
)

Output Files:

• .workflow/active/{test_session_id}/.process/gemini-test-analysis.md
• .workflow/active/{test_session_id}/.process/TEST_ANALYSIS_RESULTS.md

Phase 3: Output Validation

• Verify gemini-test-analysis.md exists and is complete
• Validate TEST_ANALYSIS_RESULTS.md generated by agent
• Check required sections present
• Confirm test requirements are actionable

Input:

• testSessionId from Phase 1
• contextPath from Phase 2

Expected Behavior:

• Use Gemini to analyze coverage gaps
• Detect project type and apply appropriate test templates
• Generate multi-layered test requirements (L0-L3)
• Scan for AI code issues
• Generate TEST_ANALYSIS_RESULTS.md

Output: .workflow/[testSessionId]/.process/TEST_ANALYSIS_RESULTS.md

Validation - TEST_ANALYSIS_RESULTS.md must include:

• Project Type Detection (with confidence)
• Coverage Assessment (current vs target)
• Test Framework & Conventions
• Multi-Layered Test Plan (L0-L3)
• AI Issue Scan Results
• Test Requirements by File (with layer annotations)
• Quality Assurance Criteria
• Success Criteria

Error Handling

Validation Errors

Execution Errors

Fallback Strategy: Generate basic TEST_ANALYSIS_RESULTS.md from context package if Gemini fails

Output

• File: .workflow/[testSessionId]/.process/TEST_ANALYSIS_RESULTS.md

Next Phase

Continue to Phase 4: Test Task Generate.

Phase 4: Test Task Generate (test-task-generate)

Generate test task JSONs via test-action-planning-agent.

Objective

• Generate test-specific IMPL_PLAN.md and task JSONs based on TEST_ANALYSIS_RESULTS.md
• Create minimum 4 tasks covering test generation, code validation, quality review, and test execution

Execution

Step 1.4: Generate Test Tasks

Phase 1: Context Preparation

Purpose: Assemble test session paths, load test analysis context, and create test-planning-notes.md.

Execution Steps: 1. Parse --session flag to get test session ID 2. Load workflow-session.json for session metadata 3. Verify TEST_ANALYSIS_RESULTS.md exists (from test-concept-enhanced) 4. Load test-context-package.json for coverage data 5. Create test-planning-notes.md with initial context

After Phase 1: Initialize test-planning-notes.md

// Create test-planning-notes.md with N+1 context support
const testPlanningNotesPath = `.workflow/active/${testSessionId}/test-planning-notes.md`
const sessionMetadata = JSON.parse(Read(`.workflow/active/${testSessionId}/workflow-session.json`))
const testAnalysis = Read(`.workflow/active/${testSessionId}/.process/TEST_ANALYSIS_RESULTS.md`)
const sourceSessionId = sessionMetadata.source_session_id || 'N/A'

// Extract key info from TEST_ANALYSIS_RESULTS.md
const projectType = testAnalysis.match(/Project Type:\s*(.+)/)?.[1] || 'Unknown'
const testFramework = testAnalysis.match(/Test Framework:\s*(.+)/)?.[1] || 'Unknown'
const coverageTarget = testAnalysis.match(/Coverage Target:\s*(.+)/)?.[1] || '80%'

Write(testPlanningNotesPath, `# Test Planning Notes

**Session**: ${testSessionId}
**Source Session**: ${sourceSessionId}
**Created**: ${new Date().toISOString()}

## Test Intent (Phase 1)

- **PROJECT_TYPE**: ${projectType}
- **TEST_FRAMEWORK**: ${testFramework}
- **COVERAGE_TARGET**: ${coverageTarget}
- **SOURCE_SESSION**: ${sourceSessionId}

---

## Context Findings (Phase 1)

### Files with Coverage Gaps
(Extracted from TEST_ANALYSIS_RESULTS.md)

### Test Framework & Conventions
- Framework: ${testFramework}
- Coverage Target: ${coverageTarget}

---

## Gemini Enhancement (Phase 1.5)
(To be filled by Gemini analysis)

### Enhanced Test Suggestions
- **L1 (Unit)**: (Pending)
- **L2.1 (Integration)**: (Pending)
- **L2.2 (API Contracts)**: (Pending)
- **L2.4 (External APIs)**: (Pending)
- **L2.5 (Failure Modes)**: (Pending)

### Gemini Analysis Summary
(Pending enrichment)

---

## Consolidated Test Requirements (Phase 2 Input)
1. [Context] ${testFramework} framework conventions
2. [Context] ${coverageTarget} coverage target

---

## Task Generation (Phase 2)
(To be filled by test-action-planning-agent)

## N+1 Context
### Decisions
| Decision | Rationale | Revisit? |
|----------|-----------|----------|

### Deferred
- [ ] (For N+1)
`)

---

Phase 1.5: Gemini Test Enhancement

Purpose: Enrich test specifications with comprehensive test suggestions and record to test-planning-notes.md.

Execution Steps: 1. Load TEST_ANALYSIS_RESULTS.md from .workflow/active/{test-session-id}/.process/ 2. Invoke cli-execution-agent with Gemini for test enhancement analysis 3. Use template: ~/.ccw/workflows/cli-templates/prompts/test-suggestions-enhancement.txt 4. Gemini generates enriched test suggestions across L1-L3 layers -> gemini-enriched-suggestions.md 5. Record enriched suggestions to test-planning-notes.md (Gemini Enhancement section)

Task(
  subagent_type="cli-execution-agent",
  run_in_background=false,
  description="Enhance test specifications with Gemini analysis",
  prompt=`
## Task Objective
Analyze TEST_ANALYSIS_RESULTS.md and generate enriched test suggestions using Gemini CLI

## Input Files
- Read: .workflow/active/{test-session-id}/.process/TEST_ANALYSIS_RESULTS.md
- Extract: Project type, test framework, coverage gaps, identified files

## Gemini Analysis Execution
Execute Gemini with comprehensive test enhancement prompt:
  ccw cli -p "[comprehensive test prompt]" --tool gemini --mode analysis --rule analysis-test-strategy-enhancement --cd .workflow/active/{test-session-id}/.process

## Expected Output
Generate gemini-enriched-suggestions.md with structured test enhancements:
  - L1 (Unit Tests): Edge cases, boundaries, error paths
  - L2.1 (Integration): Module interactions, dependency injection
  - L2.2 (API Contracts): Request/response, validation, error responses
  - L2.4 (External APIs): Mock strategies, failure scenarios, timeouts
  - L2.5 (Failure Modes): Exception handling, error propagation, recovery

## Validation
- gemini-enriched-suggestions.md created and complete
- Suggestions are actionable and specific (not generic)
- All L1-L3 layers covered
`
)

Output: gemini-enriched-suggestions.md (complete Gemini analysis)

After Phase 1.5: Update test-planning-notes.md with Gemini enhancement findings

// Read enriched suggestions from gemini-enriched-suggestions.md
const enrichedSuggestionsPath = `.workflow/active/${testSessionId}/.process/gemini-enriched-suggestions.md`
const enrichedSuggestions = Read(enrichedSuggestionsPath)

// Update Phase 1.5 section in test-planning-notes.md with full enriched suggestions
Edit(testPlanningNotesPath, {
  old: '## Gemini Enhancement (Phase 1.5)\n(To be filled by Gemini analysis)\n\n### Enhanced Test Suggestions\n- **L1 (Unit)**: (Pending)\n- **L2.1 (Integration)**: (Pending)\n- **L2.2 (API Contracts)**: (Pending)\n- **L2.4 (External APIs)**: (Pending)\n- **L2.5 (Failure Modes)**: (Pending)\n\n### Gemini Analysis Summary\n(Pending enrichment)',
  new: `## Gemini Enhancement (Phase 1.5)

**Analysis Timestamp**: ${new Date().toISOString()}
**Template**: test-suggestions-enhancement.txt
**Output File**: .process/gemini-enriched-suggestions.md

### Enriched Test Suggestions (Complete Gemini Analysis)

${enrichedSuggestions}

### Gemini Analysis Summary
- **Status**: Enrichment complete
- **Layers Covered**: L1, L2.1, L2.2, L2.4, L2.5
- **Focus Areas**: API contracts, integration patterns, error scenarios, edge cases
- **Output Stored**: Full analysis in gemini-enriched-suggestions.md`
})

// Append Gemini constraints to consolidated test requirements
const geminiConstraints = [
  '[Gemini] Implement all suggested L1 edge cases and boundary tests',
  '[Gemini] Apply L2.1 module interaction patterns from analysis',
  '[Gemini] Follow L2.2 API contract test matrix from analysis',
  '[Gemini] Use L2.4 external API mock strategies from analysis',
  '[Gemini] Cover L2.5 error scenarios from analysis'
]

const currentNotes = Read(testPlanningNotesPath)
const constraintCount = (currentNotes.match(/^\d+\./gm) || []).length

Edit(testPlanningNotesPath, {
  old: '## Consolidated Test Requirements (Phase 2 Input)',
  new: `## Consolidated Test Requirements (Phase 2 Input)
1. [Context] ${testFramework} framework conventions
2. [Context] ${coverageTarget} coverage target
${geminiConstraints.map((c, i) => `${i + 3}. ${c}`).join('\n')}`
})

---

Phase 2: Test Document Generation (Agent)

Agent Specialization: This invokes @test-action-planning-agent - a specialized variant of action-planning-agent with:

• Progressive L0-L3 test layers (Static, Unit, Integration, E2E)
• AI code issue detection (L0.5) with severity levels
• Project type templates (React, Node API, CLI, Library, Monorepo)
• Test anti-pattern detection with quality gates
• Layer completeness thresholds and coverage targets

See: d:\Claude_dms3\.claude\agents\test-action-planning-agent.md for complete test specifications.

Task(
  subagent_type="test-action-planning-agent",
  run_in_background=false,
  description="Generate test planning documents",
  prompt=`
## TASK OBJECTIVE
Generate test planning documents (IMPL_PLAN.md, task JSONs, TODO_LIST.md) for test workflow session

IMPORTANT: This is TEST PLANNING ONLY - you are generating planning documents, NOT executing tests.

## SESSION PATHS
Input:
  - Session Metadata: .workflow/active/{test-session-id}/workflow-session.json
  - TEST_ANALYSIS_RESULTS: .workflow/active/{test-session-id}/.process/TEST_ANALYSIS_RESULTS.md (REQUIRED)
  - Test Planning Notes: .workflow/active/{test-session-id}/test-planning-notes.md (REQUIRED - contains Gemini enhancement findings)
  - Test Context Package: .workflow/active/{test-session-id}/.process/test-context-package.json
  - Context Package: .workflow/active/{test-session-id}/.process/context-package.json
  - Enriched Suggestions: .workflow/active/{test-session-id}/.process/gemini-enriched-suggestions.md (for reference)
  - Source Session Summaries: .workflow/active/{source-session-id}/.summaries/IMPL-*.md (if exists)

Output:
  - Task Dir: .workflow/active/{test-session-id}/.task/
  - IMPL_PLAN: .workflow/active/{test-session-id}/IMPL_PLAN.md
  - TODO_LIST: .workflow/active/{test-session-id}/TODO_LIST.md

## CONTEXT METADATA
Session ID: {test-session-id}
Workflow Type: test_session
Source Session: {source-session-id} (if exists)
MCP Capabilities: {exa_code, exa_web, code_index}

## CONSOLIDATED CONTEXT
**From test-planning-notes.md**:
- Test Intent: Project type, test framework, coverage target
- Context Findings: Coverage gaps, file analysis
- Gemini Enhancement: Complete enriched test suggestions (L1-L3 layers)
  * Full analysis embedded in planning-notes.md
  * API contracts, integration patterns, error scenarios
- Consolidated Requirements: Combined constraints from all phases

## YOUR SPECIFICATIONS
You are @test-action-planning-agent. Your complete test specifications are defined in:
  d:\Claude_dms3\.claude\agents\test-action-planning-agent.md

This includes:
  - Progressive Test Layers (L0-L3) with L0.1-L0.5, L1.1-L1.5, L2.1-L2.5, L3.1-L3.4
  - AI Code Issue Detection (L0.5) with 7 categories and severity levels
  - Project Type Detection & Templates (6 project types)
  - Test Anti-Pattern Detection (5 categories)
  - Layer Completeness & Quality Metrics (thresholds and gate decisions)
  - Task JSON structure requirements (minimum 4 tasks)
  - Quality validation rules

**Follow your specification exactly** when generating test task JSONs.

## EXPECTED DELIVERABLES
1. Test Task JSON Files (.task/IMPL-*.json) - Minimum 4:
   - IMPL-001.json: Test generation (L1-L3 layers per spec)
   - IMPL-001.3-validation.json: Code validation gate (L0 + AI issues per spec)
   - IMPL-001.5-review.json: Test quality gate (anti-patterns + coverage per spec)
   - IMPL-002.json: Test execution & fix cycle

2. IMPL_PLAN.md: Test implementation plan with quality gates

3. TODO_LIST.md: Hierarchical task list with test phase indicators

## SUCCESS CRITERIA
- All test planning documents generated successfully
- Task count: minimum 4 (expandable for complex projects)
- Test framework: {detected from project}
- Coverage targets: L0 zero errors, L1 80%+, L2 70%+
- L0-L3 layers explicitly defined per spec
- AI issue detection configured per spec
- Quality gates with measurable thresholds
`
)

Input: testSessionId from Phase 1

Note: test-action-planning-agent generates test-specific IMPL_PLAN.md and task JSONs based on TEST_ANALYSIS_RESULTS.md.

Expected Output (minimum 4 tasks):

Validation:

• .workflow/active/[testSessionId]/.task/IMPL-001.json exists
• .workflow/active/[testSessionId]/.task/IMPL-001.3-validation.json exists
• .workflow/active/[testSessionId]/.task/IMPL-001.5-review.json exists
• .workflow/active/[testSessionId]/.task/IMPL-002.json exists
• .workflow/active/[testSessionId]/IMPL_PLAN.md exists
• .workflow/active/[testSessionId]/TODO_LIST.md exists

Test-Specific Execution Modes

Test Generation (IMPL-001)

• Agent Mode (default): @code-developer generates tests within agent context
• CLI Mode: Use CLI tools when command field present in implementation_approach

Test Execution & Fix (IMPL-002+)

• Agent Mode (default): Gemini diagnosis -> agent applies fixes
• CLI Mode: Gemini diagnosis -> CLI applies fixes (when command field present)

CLI Tool Selection: Determined semantically from user's task description (e.g., "use Codex for fixes")

Output Directory Structure

.workflow/active/WFS-test-[session]/
|-- workflow-session.json              # Session metadata
|-- IMPL_PLAN.md                       # Test implementation plan
|-- TODO_LIST.md                       # Task checklist
|-- test-planning-notes.md             # Consolidated planning notes with full Gemini analysis
|-- .task/
|   |-- IMPL-001.json                  # Test generation (L1-L3)
|   |-- IMPL-001.3-validation.json     # Code validation gate (L0 + AI)
|   |-- IMPL-001.5-review.json         # Test quality gate
|   +-- IMPL-002.json                  # Test execution & fix cycle
+-- .process/
    |-- test-context-package.json      # Test coverage and patterns
    |-- gemini-enriched-suggestions.md # Gemini-generated test enhancements
    +-- TEST_ANALYSIS_RESULTS.md       # L0-L3 requirements (from test-concept-enhanced)

Output

• Files: IMPL_PLAN.md, IMPL-*.json (4+), TODO_LIST.md
• TodoWrite: Mark Phase 1-4 completed, Phase 5 in_progress

Next Phase

Return to orchestrator for summary output, then auto-continue to Phase 5: Test Cycle Execute.

Phase 2: Test Cycle Execution (test-cycle-execute)

📌 COMPACT SENTINEL [Phase 5: Test-Cycle-Execute]

This phase contains 4 execution steps (Step 2.1 — 2.4).

If you can read this sentinel but cannot find the full Step protocol below, context has been compressed.

Recovery: Read("phases/05-test-cycle-execute.md")

Execute test-fix workflow with dynamic task generation and iterative fix cycles until test pass rate >= 95% or max iterations reached. Uses @cli-planning-agent for failure analysis and task generation.

Objective

• Discover and load test session with generated tasks
• Execute initial task pipeline (IMPL-001 → 001.3 → 001.5 → 002)
• Run iterative fix loop with adaptive strategy engine
• Achieve pass rate >= 95% or exhaust max iterations
• Complete session with summary and post-expansion options

Quick Start

# Execute test-fix workflow (auto-discovers active session)
/workflow-test-fix

# Resume interrupted session
/workflow-test-fix --resume-session="WFS-test-user-auth"

# Custom iteration limit (default: 10)
/workflow-test-fix --max-iterations=15

Quality Gate: Test pass rate >= 95% (criticality-aware) or 100% Max Iterations: 10 (default, adjustable) CLI Tools: Gemini → Qwen → Codex (fallback chain)

Core Concept

Dynamic test-fix orchestrator with adaptive task generation based on runtime analysis.

Orchestrator Boundary: The orchestrator (this phase) is responsible ONLY for:

• Loop control and iteration tracking
• Strategy selection and threshold decisions
• Delegating analysis to @cli-planning-agent and execution to @test-fix-agent
• Reading results and making pass/fail decisions
• The orchestrator does NOT directly modify source code, run tests, or perform root cause analysis

vs Standard Execute:

• Standard: Pre-defined tasks → Execute sequentially → Done
• Test-Cycle: Initial tasks → Test → Analyze failures → Generate fix tasks → Fix → Re-test → Repeat until pass

Execution

Step 2.1: Discovery

Load session, tasks, and iteration state.

1. Discovery
   └─ Load session, tasks, iteration state

For full-pipeline entry (from Phase 1-4): Use testSessionId passed from Phase 4.

For direct entry (/workflow-test-fix):

• --resume-session="WFS-xxx" → Use specified session
• No args → Auto-discover active test session (find .workflow/active/WFS-test-*)

Step 2.2: Execute Initial Tasks

Execute the generated task pipeline sequentially:

IMPL-001 (test-gen, @code-developer) →
IMPL-001.3 (code-validation, @test-fix-agent) →
IMPL-001.5 (test-quality-review, @test-fix-agent) →
IMPL-002 (test-fix, @test-fix-agent) →
Calculate pass_rate from test-results.json

Agent Invocation - @test-fix-agent (execution):

Task(
  subagent_type="test-fix-agent",
  run_in_background=false,
  description=`Execute ${task.meta.type}: ${task.title}`,
  prompt=`
    ## Task Objective
    ${taskTypeObjective[task.meta.type]}

    ## MANDATORY FIRST STEPS
    1. Read task JSON: ${session.task_json_path}
    2. Read iteration state: ${session.iteration_state_path}
    3. ${taskTypeSpecificReads[task.meta.type]}

    ## CRITICAL: Syntax Check Priority
    **Before any code modification or test execution:**
    - Run project syntax checker (TypeScript: tsc --noEmit, ESLint, etc.)
    - Verify zero syntax errors before proceeding
    - If syntax errors found: Fix immediately before other work
    - Syntax validation is MANDATORY gate - no exceptions

    ## Session Paths
    - Workflow Dir: ${session.workflow_dir}
    - Task JSON: ${session.task_json_path}
    - Test Results Output: ${session.test_results_path}
    - Test Output Log: ${session.test_output_path}
    - Iteration State: ${session.iteration_state_path}

    ## Task Type: ${task.meta.type}
    ${taskTypeGuidance[task.meta.type]}

    ## Expected Deliverables
    ${taskTypeDeliverables[task.meta.type]}

    ## Success Criteria
    - ${taskTypeSuccessCriteria[task.meta.type]}
    - Update task status in task JSON
    - Save all outputs to specified paths
    - Report completion to orchestrator
  `
)

// Task Type Configurations
const taskTypeObjective = {
  "test-gen": "Generate comprehensive tests based on requirements",
  "test-fix": "Execute test suite and report results with criticality assessment",
  "test-fix-iteration": "Apply fixes from strategy and validate with tests"
};

const taskTypeSpecificReads = {
  "test-gen": "Read test context: ${session.test_context_path}",
  "test-fix": "Read previous results (if exists): ${session.test_results_path}",
  "test-fix-iteration": "Read fix strategy: ${session.analysis_path}, fix history: ${session.fix_history_path}"
};

const taskTypeGuidance = {
  "test-gen": `
    - Read task.context.requirements for test scenarios
    - Generate tests following existing patterns and framework conventions
  `,
  "test-fix": `
    - Execute multi-layer test suite (follow your Layer-Aware Diagnosis spec)
    - Save structured results to ${session.test_results_path}
    - Apply criticality assessment per your spec (high/medium/low)
  `,
  "test-fix-iteration": `
    - Load fix_strategy from task.context.fix_strategy
    - Identify modification_points: ${task.context.fix_strategy.modification_points}
    - Apply surgical fixes (minimal changes)
    - Test execution mode: ${task.context.fix_strategy.test_execution.mode}
      * affected_only: Run ${task.context.fix_strategy.test_execution.affected_tests}
      * full_suite: Run complete test suite
    - If failures persist: Document in test-results.json, DO NOT analyze (orchestrator handles)
  `
};

const taskTypeDeliverables = {
  "test-gen": "- Test files in target directories\n    - Test coverage report\n    - Summary in .summaries/",
  "test-fix": "- test-results.json (pass_rate, criticality, failures)\n    - test-output.log (full test output)\n    - Summary in .summaries/",
  "test-fix-iteration": "- Modified source files\n    - test-results.json (updated pass_rate)\n    - test-output.log\n    - Summary in .summaries/"
};

const taskTypeSuccessCriteria = {
  "test-gen": "All test files created, executable without errors, coverage documented",
  "test-fix": "Test results saved with accurate pass_rate and criticality, all failures documented",
  "test-fix-iteration": "Fixes applied per strategy, tests executed, results reported (pass/fail to orchestrator)"
};

Decision after IMPL-002 execution:

pass_rate = Read(test-results.json).pass_rate
├─ 100% → SUCCESS: Proceed to Step 2.4 (Completion)
├─ 95-99% + all failures low criticality → PARTIAL SUCCESS: Proceed to Step 2.4
└─ <95% or critical failures → Enter Step 2.3 (Fix Loop)

Step 2.3: Iterative Fix Loop

Conditional: Only enters when pass_rate < 95% or critical failures exist.

Intelligent Strategy Engine

Auto-selects optimal strategy based on iteration context:

Selection Logic (in orchestrator):

if (iteration <= 2) return "conservative";
if (passRate > 80 && failurePattern.similarity > 0.7) return "aggressive";
if (regressionDetected) return "surgical";
return "conservative";

Integration: Strategy passed to @cli-planning-agent in prompt for tailored analysis.

Progressive Testing

Runs affected tests during iterations, full suite only for final validation.

How It Works: 1. @cli-planning-agent analyzes fix_strategy.modification_points 2. Maps modified files to test files (via imports + integration patterns) 3. Returns affected_tests[] in task JSON 4. @test-fix-agent runs: npm test -- ${affected_tests.join(' ')} 5. Final validation: npm test (full suite)

Benefits: 70-90% iteration speed improvement, instant feedback on fix effectiveness.

Orchestrator Runtime Calculations

From iteration-state.json:

• Current iteration: iterations.length + 1
• Stuck tests: Tests appearing in failed_tests for 3+ consecutive iterations
• Regression: Compare consecutive pass_rate values (>10% drop)
• Max iterations: Read from task.meta.max_iterations

Fix Loop Flow

for each iteration (N = 1 to maxIterations):
  1. Detect: stuck tests, regression, progress trend
  2. Select strategy: conservative/aggressive/surgical
  3. Generate fix task via @cli-planning-agent
  4. Execute fix via @test-fix-agent
  5. Re-test → Calculate pass_rate
  6. Decision:
     ├─ pass_rate >= 95% → EXIT loop → Step 2.4
     ├─ regression detected → Rollback, switch to surgical
     └─ continue → Next iteration

Agent Invocation - @cli-planning-agent (failure analysis)

Task(
  subagent_type="cli-planning-agent",
  run_in_background=false,
  description=`Analyze test failures (iteration ${N}) - ${strategy} strategy`,
  prompt=`
    ## Task Objective
    Analyze test failures and generate fix task JSON for iteration ${N}

    ## Strategy
    ${selectedStrategy} - ${strategyDescription}

    ## PROJECT CONTEXT (MANDATORY)
    1. Run: \`ccw spec load --category execution\` (tech stack, build system, constraints)
    2. Run: \`ccw spec load --category test\` (test framework, coverage targets, conventions)

    ## MANDATORY FIRST STEPS
    1. Read test results: ${session.test_results_path}
    2. Read test output: ${session.test_output_path}
    3. Read iteration state: ${session.iteration_state_path}

    ## Context Metadata (Orchestrator-Calculated)
    - Session ID: ${sessionId} (from file path)
    - Current Iteration: ${N} (= iterations.length + 1)
    - Max Iterations: ${maxIterations} (from task.meta.max_iterations)
    - Current Pass Rate: ${passRate}%
    - Selected Strategy: ${selectedStrategy} (from iteration-state.json)
    - Stuck Tests: ${stuckTests} (calculated from iterations[].failed_tests history)

    ## CLI Configuration
    - Tool Priority: gemini & codex
    - Template: 01-diagnose-bug-root-cause.txt
    - Timeout: 2400000ms

    ## Expected Deliverables
    1. Task JSON: ${session.task_dir}/IMPL-fix-${N}.json
       - Must include: fix_strategy.test_execution.affected_tests[]
       - Must include: fix_strategy.confidence_score
    2. Analysis report: ${session.process_dir}/iteration-${N}-analysis.md
    3. CLI output: ${session.process_dir}/iteration-${N}-cli-output.txt

    ## Strategy-Specific Requirements
    - Conservative: Single targeted fix, high confidence required
    - Aggressive: Batch fix similar failures, pattern-based approach
    - Surgical: Minimal changes, focus on rollback safety

    ## Success Criteria
    - Concrete fix strategy with modification points (file:function:lines)
    - Affected tests list for progressive testing
    - Root cause analysis (not just symptoms)
  `
)

CLI Tool Configuration

Fallback Chain: Gemini → Qwen → Codex Template: ~/.ccw/workflows/cli-templates/prompts/analysis/01-diagnose-bug-root-cause.txt Timeout: 40min (2400000ms)

Tool Details: 1. Gemini (primary): gemini-2.5-pro 2. Qwen (fallback): coder-model 3. Codex (fallback): gpt-5.1-codex

When to Fallback: HTTP 429, timeout, analysis quality degraded

CLI Fallback Triggers (Gemini → Qwen → Codex → manual):

Fallback is triggered when any of these conditions occur:

1. Invalid Output:

• CLI tool fails to generate valid IMPL-fix-N.json (JSON parse error)
• Missing required fields: fix_strategy.modification_points or fix_strategy.affected_tests

2. Low Confidence:

• fix_strategy.confidence_score < 0.4 (indicates uncertain analysis)

3. Technical Failures:

• HTTP 429 (rate limit) or 5xx errors
• Timeout (exceeds 2400000ms / 40min)
• Connection errors

4. Quality Degradation:

• Analysis report < 100 words (too brief, likely incomplete)
• No concrete modification points provided (only general suggestions)
• Same root cause identified 3+ consecutive times (stuck analysis)

Fallback Sequence:

• Try primary tool (Gemini)
• If trigger detected → Try fallback (Qwen)
• If trigger detected again → Try final fallback (Codex)
• If all fail → Mark as degraded, use basic pattern matching from fix-history.json, notify user

Iteration State JSON

Purpose: Persisted state machine for iteration loop - enables Resume and historical analysis.

{
  "current_task": "IMPL-002",
  "selected_strategy": "aggressive",
  "next_action": "execute_fix_task",
  "iterations": [
    {
      "iteration": 1,
      "pass_rate": 70,
      "strategy": "conservative",
      "failed_tests": ["test_auth_flow", "test_user_permissions"]
    },
    {
      "iteration": 2,
      "pass_rate": 82,
      "strategy": "conservative",
      "failed_tests": ["test_user_permissions", "test_token_expiry"]
    },
    {
      "iteration": 3,
      "pass_rate": 89,
      "strategy": "aggressive",
      "failed_tests": ["test_auth_edge_case"]
    }
  ]
}

Field Descriptions:

• current_task: Pointer to active task (essential for Resume)
• selected_strategy: Current iteration strategy (runtime state)
• next_action: State machine next step (execute_fix_task | retest | complete)
• iterations[]: Historical log of all iterations (source of truth for trends)

TodoWrite Update (Fix Loop)

TodoWrite({
  todos: [
    {
      content: "Execute IMPL-001: Generate tests [code-developer]",
      status: "completed",
      activeForm: "Executing test generation"
    },
    {
      content: "Execute IMPL-002: Test & Fix Cycle [ITERATION]",
      status: "in_progress",
      activeForm: "Running test-fix iteration cycle"
    },
    {
      content: "  → Iteration 1: Initial test (pass: 70%, conservative)",
      status: "completed",
      activeForm: "Running initial tests"
    },
    {
      content: "  → Iteration 2: Fix validation (pass: 82%, conservative)",
      status: "completed",
      activeForm: "Fixing validation issues"
    },
    {
      content: "  → Iteration 3: Batch fix auth (pass: 89%, aggressive)",
      status: "in_progress",
      activeForm: "Fixing authentication issues"
    }
  ]
});

Update Rules:

• Add iteration item with: strategy, pass rate
• Mark completed after each iteration
• Update parent task when all complete

Step 2.4: Completion

Completion Conditions

Full Success:

• All tasks completed
• Pass rate === 100%
• Action: Auto-complete session

Partial Success:

• All tasks completed
• Pass rate >= 95% and < 100%
• All failures are "low" criticality
• Action: Auto-approve with review note

Failure:

• Max iterations (10) reached without 95% pass rate
• Pass rate < 95% after max iterations
• Action: Generate failure report, mark blocked, return to user

Commit Strategy

Automatic Commits (orchestrator-managed):

The orchestrator automatically creates git commits at key checkpoints to enable safe rollback:

1. After Successful Iteration (pass rate increased):

   git add .
   git commit -m "test-cycle: iteration ${N} - ${strategy} strategy (pass: ${oldRate}% → ${newRate}%)"

2. Before Rollback (regression detected):

   # Current state preserved, then:
   git revert HEAD
   git commit -m "test-cycle: rollback iteration ${N} - regression detected (pass: ${newRate}% < ${oldRate}%)"

Commit Content:

• Modified source files from fix application
• Updated test-results.json, iteration-state.json
• Excludes: temporary files, logs

Benefits:

• Each successful iteration is a safe rollback point
• Regression detection can instantly revert to last known-good state
• Full iteration history visible in git log for post-mortem analysis
• No manual intervention needed for rollback — orchestrator handles automatically

Post-Completion Expansion

Auto-sync: 执行 /workflow:session:sync -y "{summary}" 更新 specs/*.md + project-tech。

完成后询问用户是否扩展为issue(test/enhance/refactor/doc)，选中项调用 /issue:new "{summary} - {dimension}"

Agent Roles Summary

Core Responsibilities (Detailed):

• Orchestrator (this skill):
• Loop control: iteration count, max iterations enforcement, exit conditions
• Strategy selection based on iteration context (conservative → aggressive → surgical)
• Pass rate calculation from test-results.json after each iteration
• Threshold decisions: 95% gate, criticality-aware partial success
• Commit management: auto-commit on improvement, rollback on regression
• Regression detection: compare consecutive pass_rate values (>10% drop triggers surgical)
• Stuck test tracking: tests failing 3+ consecutive iterations flagged for alternative strategy

• @cli-planning-agent (failure analysis):
• Execute CLI tools (Gemini/Qwen/Codex) with fallback chain for root cause analysis
• Extract concrete modification points (file:function:lines) from analysis
• Generate fix task JSON (IMPL-fix-N.json) with fix_strategy and confidence_score
• Detect affected tests for progressive testing (map modified files → test files)
• Apply strategy-specific analysis (conservative: single fix, aggressive: batch, surgical: minimal)

• @test-fix-agent (execution):
• Execute test suite and capture pass/fail counts, error messages, stack traces
• Apply code fixes per fix_strategy.modification_points (surgical, minimal changes)
• Assess criticality for each failure (high/medium/low based on impact)
• Report structured results to test-results.json with pass_rate and failure details
• Validate syntax before any code modification (TypeScript: tsc --noEmit, ESLint)

Error Handling

Session File Structure

.workflow/active/WFS-test-{session}/
├── workflow-session.json           # Session metadata
├── IMPL_PLAN.md, TODO_LIST.md
├── .task/
│   ├── IMPL-{001,002}.json         # Initial tasks
│   └── IMPL-fix-{N}.json           # Generated fix tasks
├── .process/
│   ├── iteration-state.json        # Current iteration + strategy + stuck tests
│   ├── test-results.json           # Latest results (pass_rate, criticality)
│   ├── test-output.log             # Full test output
│   ├── fix-history.json            # All fix attempts
│   ├── iteration-{N}-analysis.md   # CLI analysis report
│   └── iteration-{N}-cli-output.txt
└── .summaries/iteration-summaries/

Output

• Variable: finalPassRate (percentage)
• File: test-results.json (final results)
• File: iteration-state.json (full iteration history)
• TodoWrite: Mark Phase 5 completed

Next Phase

Return to orchestrator. Workflow complete. Offer post-completion expansion options.