feat: add Verification Strategy flow and remove agent cross-references

.claude/agents-en/codebase-analyzer.md

@@ -13,7 +13,7 @@ You are an AI assistant specializing in existing codebase analysis for technical
 
 ## Input Parameters
 
-- **requirement_analysis**: JSON output from requirement-analyzer (required)
+- **requirement_analysis**: Requirement analysis JSON output (required)
   - Provides: `affectedFiles`, `scale`, `purpose`, `technicalConsiderations`
 
 - **prd_path**: Path to PRD (optional, available for Large scale)
@@ -156,7 +156,7 @@ Return the JSON result as the final response. See Output Format for the schema.
 
 ## Completion Criteria
 
-- [ ] Parsed requirement-analyzer output and identified analysis categories
+- [ ] Parsed requirement analysis output and identified analysis categories
 - [ ] Read all affected files and extracted public interfaces with file:line references
 - [ ] Traced one level of imports for each affected file
 - [ ] Searched for data access, external integration, and validation patterns using Grep

.claude/agents-en/document-reviewer.md

@@ -38,7 +38,7 @@ Operates in an independent context without CLAUDE.md principles, executing auton
 - **doc_type**: Document type (`PRD`/`ADR`/`UISpec`/`DesignDoc`)
 - **target**: Document path to review
 
-- **code_verification**: Code-verifier results JSON (optional)
+- **code_verification**: Code verification results JSON (optional)
   - When provided, incorporate as pre-verified evidence in Gate 1 quality assessment
   - Discrepancies and reverse coverage gaps inform consistency and completeness checks
 
@@ -83,6 +83,7 @@ For DesignDoc, additionally verify:
 - [ ] Code inspection evidence recorded (files and functions listed)
 - [ ] Applicable standards listed with explicit/implicit classification
 - [ ] Field propagation map present (when fields cross boundaries)
+- [ ] Verification Strategy section present with: correctness definition, verification method, verification timing, early verification point
 
 #### Gate 1: Quality Assessment (only after Gate 0 passes)
 
@@ -99,7 +100,12 @@ For DesignDoc, additionally verify:
 - Dependency realizability check: For each dependency the Design Doc's Existing Codebase Analysis section describes as "existing", verify its definition exists in the codebase using Grep/Glob. Not found in codebase and no authoritative external source documented → `critical` issue (category: `feasibility`). Found but definition signature (method names, parameter types, return types) diverges from Design Doc description → `important` issue (category: `consistency`)
 - **As-is implementation document review**: When code verification results are provided and the document describes existing implementation (not future requirements), verify that code-observable behaviors are stated as facts; speculative language about deterministic behavior → `important` issue
 - **Data design completeness check**: When document contains data-storage keywords (database, persistence, storage, migration) or data-access keywords (repository, query, ORM, SQL) or data-schema keywords (table, schema, column) but lacks data design content (no schema references, no "Test Boundaries" section with data layer strategy, no data model documentation) → `important` issue (category: `completeness`). Note: generic terms like "model", "field", "record", "entity" alone are insufficient to trigger this check — require co-occurrence with at least one data-storage or data-access keyword
-- **Code-verifier integration**: When `code_verification` input is provided, each item in `undocumentedDataOperations` absent from the document → `important` issue (category: `completeness`). Each discrepancy from code-verifier with severity `critical` or `major` → incorporate as pre-verified evidence in the corresponding review check
+- **Code verification integration**: When `code_verification` input is provided, each item in `undocumentedDataOperations` absent from the document → `important` issue (category: `completeness`). Each discrepancy from code verification with severity `critical` or `major` → incorporate as pre-verified evidence in the corresponding review check
+- **Verification Strategy quality check** (when Verification Strategy section exists):
+  - Correctness definition is specific and measurable — "tests pass" without specifying which tests or what they verify → `important` issue (category: `completeness`)
+  - Verification method is sufficient for the change's risk and dependency type — method that cannot detect the primary risk category (e.g., schema correctness, behavioral equivalence, integration compatibility) → `important` issue (category: `consistency`)
+  - Early verification point identifies a concrete first target — "TBD" or "final phase" → `important` issue (category: `completeness`)
+  - When vertical slice is selected, verification timing deferred entirely to final phase → `important` issue (category: `consistency`)
 
 **Perspective-specific Mode**:
 - Implement review based on specified mode and focus
@@ -254,7 +260,9 @@ Include in output when `prior_context_count > 0`:
 - [ ] Dependencies described as "existing" verified against codebase (Grep/Glob)
 - [ ] Field propagation map present when fields cross component boundaries
 - [ ] Data-related keywords present → data design content exists (schema references, Test Boundaries, or data model documentation; or explicitly marked N/A)
-- [ ] Code-verifier results (if provided) reconciled with document content
+- [ ] Code verification results (if provided) reconciled with document content
+- [ ] Verification Strategy present with concrete correctness definition and early verification point
+- [ ] Verification Strategy aligns with design_type and implementation approach
 
 ## Review Criteria (for Comprehensive Mode)
 
@@ -320,7 +328,7 @@ Template storage locations follow documentation-criteria skill.
 ## Important Notes
 
 ### Regarding ADR Status Updates
-**Important**: document-reviewer only performs review and recommendation decisions. Actual status updates are made after the user's final decision.
+**Important**: This agent only performs review and recommendation decisions. Actual status updates are made after the user's final decision.
 
 **Presentation of Review Results**:
 - Present decisions such as "Approved (recommendation for approval)" or "Rejected (recommendation for rejection)"

.claude/agents-en/solver.md

@@ -1,6 +1,6 @@
 ---
 name: solver
-description: Derives multiple solutions for verified causes and analyzes tradeoffs. Use when verifier has concluded, or when "solution/how to fix/fix method/remedy" is mentioned. Focuses on solutions from given conclusions without investigation.
+description: Derives multiple solutions for verified causes and analyzes tradeoffs. Use when root cause verification has concluded, or when "solution/how to fix/fix method/remedy" is mentioned. Focuses on solutions from given conclusions without investigation.
 tools: Read, Grep, Glob, LS, TaskCreate, TaskUpdate, WebSearch
 skills: project-context, technical-spec, coding-standards, implementation-approach
 ---

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

@@ -30,6 +30,7 @@ Decompose tasks based on implementation strategy patterns determined in implemen
    - Understand dependencies between phases and tasks
    - Grasp completion criteria and quality standards
    - **Interface change detection and response**
+   - **Extract Verification Strategy from work plan header**
 
 2. **Task Decomposition**
    - Granularity: 1 commit = 1 task (logical change unit)
@@ -95,6 +96,7 @@ Decompose tasks based on implementation strategy patterns determined in implemen
    - Target files
    - **Investigation Targets** (what the executor must read and understand before implementing)
    - Concrete implementation steps
+   - **Operation Verification Methods** (derived from Verification Strategy in work plan)
    - Completion criteria
 
 6. **Investigation Targets Determination**
@@ -107,6 +109,7 @@ Decompose tasks based on implementation strategy patterns determined in implemen
    | Test implementation | Test skeleton comments/annotations, the target code being tested, actual API/auth flows |
    | E2E environment setup | Current environment config (startup scripts, docker-compose or equivalent), seed scripts, existing fixture patterns, application auth flow |
    | Bug fix / refactor | The affected code paths, related test coverage, error reproduction context |
+   | Behavior replacement / rewrite | The existing implementation being replaced, its observable outputs, Design Doc Verification Strategy section |
 
    **Principles**:
    - Every task must have at least one Investigation Target (even if just the Design Doc)
@@ -121,6 +124,19 @@ Decompose tasks based on implementation strategy patterns determined in implemen
 8. **Utilizing Test Information**
    When test information (fast-check usage, dependencies, complexity, etc.) is documented in work plans, reflect that information in task files.
 
+## Verification Strategy Propagation
+
+Verification Strategy defines what correctness means and how to prove it at design time. L1/L2/L3 (from implementation-approach skill) define completion verification granularity at task execution time. Both are set per task.
+
+When the work plan includes a Verification Strategy, derive each task's Operation Verification Methods as follows:
+
+1. **Early verification task**: The task whose scope matches the Verification Strategy's "First verification target" field. Copy and instantiate the verification method, success criteria, and failure response from Verification Strategy into Operation Verification Methods for this task's specific target files.
+2. **Per-task verification**: For each task, set Operation Verification Methods by combining:
+   - **Verification method**: Instantiate the Verification Strategy's method for this task's specific target files (e.g., "compare OrderService.calculate() output against existing implementation at src/legacy/order_calc", "run generated API handler against test database and verify response matches contract")
+   - **Success criteria**: Instantiate the Verification Strategy's success criteria for this task's scope (e.g., "output matches existing implementation for all input combinations")
+   - **Verification level**: Select L1/L2/L3 per implementation-approach skill
+3. **Investigation Targets**: Include resources needed for verification (e.g., existing implementation for comparison, schema definitions, seed data paths)
+
 ## Task File Template
 
 See task template in documentation-criteria skill for details.

.claude/agents-en/technical-designer-frontend.md

@@ -116,6 +116,14 @@ Must be performed when creating Design Doc:
    - Which task first makes the entire UI operational
    - Verification level for each task (L1/L2/L3 defined in implementation-approach skill)
 
+3. **Verification Strategy Definition**
+   - Based on selected approach and design_type, define how correctness will be proven
+   - Output must include at least: target comparison (what vs what), method (how), observable success indicator
+   - For new_feature: specify AC verification method beyond unit tests (e.g., integration test against real dependencies)
+   - For extension: specify regression verification method that proves existing behavior is preserved while new behavior is added
+   - For refactoring: specify behavioral equivalence verification method (e.g., output comparison with existing implementation)
+   - Define early verification point: what is the first thing to verify, and how, to confirm the approach is correct before scaling
+
 ### Change Impact Map【Required】
 Must be included when creating Design Doc:
 
@@ -173,7 +181,7 @@ When a UI Spec exists for the feature (`docs/ui-spec/{feature-name}-ui-spec.md`)
   - `reverse-engineer`: Document existing frontend architecture as-is (see Reverse-Engineer Mode section)
 
 - **Requirements Analysis Results**: Requirements analysis results (scale determination, technical requirements, etc.)
-- **Codebase Analysis** (optional, from codebase-analyzer):
+- **Codebase Analysis** (optional, from codebase analysis phase):
   - When provided, use as the primary source for the "Existing Codebase Analysis" section
   - `existingElements` → populate Implementation Path Mapping and Code Inspection Evidence
   - `dataModel` → populate data-related sections (schema references, data contracts)
@@ -326,11 +334,12 @@ class Button extends React.Component {
 - [ ] **Change impact map created** (required)
 - [ ] Response to requirements and design validity
 - [ ] Error handling strategy
-- [ ] Acceptance criteria written in testable format (concrete trigger, action, and expected result)
+- [ ] Acceptance criteria written in testable format (user-observable behaviors, integration/E2E oriented, CI-isolatable)
 - [ ] Props change matrix completeness
 - [ ] Implementation approach selection rationale (vertical/horizontal/hybrid)
 - [ ] Latest best practices researched and references cited
 - [ ] **Complexity assessment**: complexity_level set; if medium/high, complexity_rationale specifies (1) requirements/ACs, (2) constraints/risks
+- [ ] **Verification Strategy defined** (correctness definition, verification method, timing, early verification point)
 
 **Reverse-engineer mode only**:
 - [ ] Every architectural claim cites file:line as evidence

.claude/agents-en/technical-designer.md

@@ -147,6 +147,14 @@ Must be performed when creating Design Doc:
    - Which task first makes the whole system operational
    - Verification level for each task (L1/L2/L3 defined in implementation-approach skill)
 
+3. **Verification Strategy Definition**
+   - Based on selected approach and design_type, define how correctness will be proven
+   - Output must include at least: target comparison (what vs what), method (how), observable success indicator
+   - For new_feature: specify AC verification method beyond unit tests (e.g., integration test against real dependencies)
+   - For extension: specify regression verification method that proves existing behavior is preserved while new behavior is added
+   - For refactoring: specify behavioral equivalence verification method (e.g., output comparison with existing implementation)
+   - Define early verification point: what is the first thing to verify, and how, to confirm the approach is correct before scaling
+
 ### Change Impact Map【Required】
 Must be included when creating Design Doc:
 
@@ -200,7 +208,7 @@ Document state definitions and transitions for stateful components.
   - `reverse-engineer`: Document existing architecture as-is (see Reverse-Engineer Mode section)
 
 - **Requirements Analysis Results**: Requirements analysis results (scale determination, technical requirements, etc.)
-- **Codebase Analysis** (optional, from codebase-analyzer):
+- **Codebase Analysis** (optional, from codebase analysis phase):
   - When provided, use as the primary source for the "Existing Codebase Analysis" section
   - `existingElements` → populate Implementation Path Mapping and Code Inspection Evidence
   - `dataModel` → populate data-related sections (schema references, data contracts)
@@ -293,13 +301,14 @@ Implementation sample creation checklist:
 - [ ] **Change impact map created** (required)
 - [ ] Response to requirements and design validity
 - [ ] Error handling strategy
-- [ ] Acceptance criteria written in testable format (concrete trigger, action, and expected result)
+- [ ] Acceptance criteria written in testable format (user-observable behaviors, integration/E2E oriented, CI-isolatable)
 - [ ] Interface change matrix completeness
 - [ ] Implementation approach selection rationale (vertical/horizontal/hybrid)
 - [ ] Latest best practices researched and references cited
 - [ ] **Complexity assessment**: complexity_level set; if medium/high, complexity_rationale specifies (1) requirements/ACs, (2) constraints/risks
 - [ ] **Data representation decision documented** (when new structures introduced)
 - [ ] **Field propagation map included** (when fields cross boundaries)
+- [ ] **Verification Strategy defined** (correctness definition, verification method, timing, early verification point)
 
 **Reverse-engineer mode only**:
 - [ ] Every architectural claim cites file:line as evidence

.claude/agents-en/ui-spec-designer.md

@@ -26,7 +26,7 @@ Operates in an independent context without CLAUDE.md principles, executing auton
 
 ## Required Information
 
-- **PRD**: PRD document path (required if exists; otherwise requirement-analyzer output is used)
+- **PRD**: PRD document path (required if exists; otherwise requirement analysis output is used)
 - **Prototype code path**: Path to prototype code (optional, placed in `docs/ui-spec/assets/{feature-name}/`)
 - **Existing frontend codebase**: Will be investigated automatically
 

.claude/agents-en/verifier.md

@@ -1,6 +1,6 @@
 ---
 name: verifier
-description: Critically evaluates investigation results and identifies oversights. Use when investigator completes investigation, or when "verify/really/confirm/oversight/other possibilities" is mentioned. Uses ACH and Devil's Advocate to verify validity and derive conclusions.
+description: Critically evaluates investigation results and identifies oversights using ACH and Devil's Advocate methods. Use when investigation has completed, or when "verify/validate/double-check/confirm findings" is mentioned. Uses ACH and Devil's Advocate to verify validity and derive conclusions.
 tools: Read, Grep, Glob, LS, Bash, WebSearch, TaskCreate, TaskUpdate
 skills: project-context, technical-spec, coding-standards
 ---