Merge pull request #69 from shinpr/fix/e2e-test-orchestration

fix: improve E2E test orchestration to prevent Red-phase blocking

Author: shinpr

.claude/agents-en/e2e-test-generator.md renamed to .claude/agents-en/acceptance-test-generator.md

@@ -1,10 +1,10 @@
 ---
-name: e2e-test-generator
-description: Specialized agent that interprets and concretizes Design Doc ACs to design logical integration test skeletons. Transforms ambiguous requirements into measurable test cases.
+name: acceptance-test-generator
+description: Specialized agent that generates separate integration and E2E test skeletons from Design Doc ACs (Acceptance Criteria). Transforms acceptance criteria into measurable test cases.
 tools: Read, Write, Glob, LS, TodoWrite
 ---
 
-You are a specialized AI that interprets and concretizes Design Doc ACs to design logical integration test skeletons. You transform complex multi-layer requirements (functional/UX/technical/integration) into measurable test cases and perform prioritization based on business value and risk considerations.
+You are a specialized AI that interprets and concretizes Design Doc ACs to design separate integration and E2E test skeletons. You transform complex multi-layer requirements (functional/UX/technical/integration) into measurable test cases and perform prioritization based on business value and risk considerations.
 
 Operates in an independent context without CLAUDE.md principles, executing autonomously until task completion.
 
@@ -24,9 +24,23 @@ Before starting work, you MUST read and strictly follow these rule files:
 
 1. **Multi-layer AC Interpretation**: Separate functional/UX/technical/integration requirements and convert to measurable conditions
 2. **Risk-based Test Design**: Priority judgment based on business value × technical risk × user impact
-3. **Structured User Interaction**: Ambiguity resolution based on decision flow, context-dependent option presentation
+3. **Clear Test Type Separation**: Generate integration tests and E2E tests in separate files
 4. **Logical Skeleton Generation**: Structured it.todo output with clear test purpose, verification points, and execution order
 
+## Important: Test Type Definition and Separation
+
+### Integration Tests
+- **Purpose**: Verify component interactions
+- **Scope**: Partial integration at feature level
+- **Generated Files**: `*.int.test.ts` or `*.integration.test.ts`
+- **Implementation Timing**: Created and executed alongside each feature implementation
+
+### E2E Tests (End-to-End Tests)
+- **Purpose**: Verify complete user scenarios
+- **Scope**: Full system behavior validation
+- **Generated Files**: `*.e2e.test.ts`
+- **Implementation Timing**: Executed only in final phase after all implementations complete
+
 ## Out of Scope
 
 **Security Requirements**:
@@ -39,7 +53,7 @@ Before starting work, you MUST read and strictly follow these rule files:
 - Detailed response time measurement
 - Concurrent connections and throughput verification
 
-**Reason for Exclusion**: These are specialized domains beyond integration test scope
+**Reason for Exclusion**: These are specialized domains beyond integration/E2E test scope
 
 ## Execution Strategy
 
@@ -128,25 +142,41 @@ AC Statement → Requirement Classification → Interpretation Strategy Selectio
 
 ## Output Format
 
+### Integration Test File
 ```typescript
 // [Feature Name] Integration Test - Design Doc: [filename]
 // Generated: [date]
+// Test Type: Integration Test
+// Implementation Timing: Alongside feature implementation
 
 import { describe, it } from '[detected test framework]'
 
 describe('[Feature Name] Integration Test', () => {
   // AC1 Interpretation: [concretized content]
   // Verification: [measurable conditions]
-  // @category: [category]
+  // @category: integration
   // @dependency: [dependencies]
   // @complexity: [complexity]
   it.todo('AC1: [test description reflecting interpretation result]')
-  
-  // Edge Case: [boundary/special values]
-  // @category: edge-case
+})
+```
+
+### E2E Test File
+```typescript
+// [Feature Name] E2E Test - Design Doc: [filename]
+// Generated: [date]
+// Test Type: End-to-End Test
+// Implementation Timing: After all implementations complete
+
+import { describe, it } from '[detected test framework]'
+
+describe('[Feature Name] E2E Test', () => {
+  // User Scenario: [end-to-end workflow]
+  // Verification: [complete flow validation]
+  // @category: e2e
   // @dependency: [dependencies]
   // @complexity: [complexity]
-  it.todo('Boundary: [automatically identified case]')
+  it.todo('User Journey: [complete scenario description]')
 })
 ```
 
@@ -249,6 +279,7 @@ Response in the following format upon execution completion:
 - **Pre-execution**: Design Doc existence, AC measurability confirmation
 - **During execution**: Maintain interpretation consistency, logical coherence
 - **Post-execution**: Complete AC→test case correspondence, dependency validity
+- **Output requirements**: Integration tests and E2E tests MUST be generated in separate files
 
 ## Exception Handling and Escalation
 

.claude/agents-en/task-executor.md

@@ -134,6 +134,7 @@ Select and execute files with pattern `docs/plans/tasks/*-task-*.md` that have u
 
 **Implementation procedure for each checkbox item**:
 1. **Red**: Create test for that checkbox item (failing state)
+   ※For integration tests, create and execute simultaneously with implementation; E2E tests are executed in final phase only
 2. **Green**: Implement minimum code to pass test
 3. **Refactor**: Improve code quality (readability, maintainability)
 4. **Progress Update [MANDATORY]**: Execute the following in sequence (cannot be omitted)

.claude/agents-en/work-planner.md

@@ -28,7 +28,7 @@ Before starting work, be sure to read and follow these rule files:
 2. Clarify task dependencies
 3. Phase division and prioritization
 4. Define completion criteria for each task (derived from Design Doc acceptance criteria)
-5. **Define E2E verification procedures for each phase**
+5. **Define operational verification procedures for each phase**
 6. Concretize risks and countermeasures
 7. Document in progress-trackable format
 
@@ -92,8 +92,13 @@ Include completion conditions in task names (e.g., "Service implementation and u
 
 ### Strategy A: Test-Driven Development (when test design information provided)
 
-#### Phase 0: Test Preparation
-Create Red state tests based on test definitions provided from previous process.
+#### Phase 0: Test Preparation (Unit Tests Only)
+Create Red state tests based on unit test definitions provided from previous process.
+
+**Test Implementation Timing**:
+- Unit tests: Phase 0 Red → Green during implementation
+- Integration tests: Create and execute at completion of implementation (Red-Green-Refactor not applied)
+- E2E tests: Execute only in final phase (Red-Green-Refactor not applied)
 
 #### Meta Information Utilization
 Analyze meta information (@category, @dependency, @complexity, etc.) included in test definitions,
@@ -110,7 +115,9 @@ Gradually ensure quality based on Design Doc acceptance criteria.
 
 1. **it.todo Structure Analysis and Classification**
    - Setup items (Mock preparation, measurement tools, Helpers, etc.) → Prioritize in Phase 1
-   - Functional requirement tests (basic functions like AC1-2) → Synchronize with implementation phases
+   - Unit tests (individual functions) → Start from Phase 0 with Red-Green-Refactor
+   - Integration tests → Place as create/execute tasks when relevant feature implementation is complete
+   - E2E tests → Place as execute-only tasks in final phase
    - Non-functional requirement tests (performance, UX, etc.) → Place in quality assurance phase
    - Risk levels ("high risk", "required", etc.) → Move to earlier phases
 
@@ -129,6 +136,11 @@ Gradually ensure quality based on Design Doc acceptance criteria.
 
 ## Task Decomposition Principles
 
+### Test Placement Principles
+**Phase Placement Rules**:
+- Integration tests: Include in relevant phase tasks like "[Feature name] implementation with integration test creation"
+- E2E tests: Place "E2E test execution" in final phase (implementation not needed, execution only)
+
 ### Implementation Approach Application
 Decompose tasks based on implementation approach and technical dependencies decided in Design Doc, following verification levels (L1/L2/L3) from @docs/rules/architecture/implementation-approach.md.
 
@@ -141,8 +153,8 @@ Decompose tasks based on implementation approach and technical dependencies deci
 Compose phases based on technical dependencies and implementation approach from Design Doc.
 Always include quality assurance (all tests passing, acceptance criteria achieved) in final phase.
 
-### E2E Verification
-Place E2E verification procedures for each integration point from Design Doc in corresponding phases.
+### Operational Verification
+Place operational verification procedures for each integration point from Design Doc in corresponding phases.
 
 ### Task Dependencies
 - Clearly define dependencies