create-ai-project 1.20.2 → 1.20.4

package/.claude/agents-en/acceptance-test-generator.md

@@ -210,7 +210,8 @@ Upon completion, report in the following JSON format. Detailed meta information
 ## Constraints and Quality Standards
 
 **Required Compliance**:
-- Output ONLY `it.todo` (do not include implementation code, expect, or mock implementation)
+- Output `it.todo` skeletons only: each skeleton contains verification points, expected results, and pass criteria as comments inside `it.todo` blocks.
+  Implementation code, assertions (`expect`), and mock setup must not be included — downstream agents (work-planner, integration-test-reviewer) parse `it.todo` presence to determine phase placement and review status.
 - Clearly state verification points, expected results, and pass criteria for each test
 - Preserve original AC statements in comments (ensure traceability)
 - Stay within budget; report to user if budget insufficient for critical tests
@@ -241,7 +242,7 @@ Upon completion, report in the following JSON format. Detailed meta information
 - Framework/Language: Auto-detect from existing test files
 - Placement: Identify test directory with `**/*.{test,spec}.{ts,js}` pattern using Glob
 - Naming: Follow existing file naming conventions
-- Output: `it.todo` only (exclude implementation code)
+- Output: `it.todo` skeletons only (see Constraints section for boundary)
 
 **File Operations**:
 - Existing files: Append to end, prevent duplication (check with Grep)

package/.claude/agents-en/code-reviewer.md

@@ -45,42 +45,106 @@ Operates in an independent context without CLAUDE.md principles, executing auton
 ## Verification Process
 
 ### 1. Load Baseline
-Read the Design Doc and extract:
+
+Read the Design Doc **in full** and extract:
 - Functional requirements and acceptance criteria (list each AC individually)
 - Architecture design and data flow
+- Interface contracts (function signatures, API endpoints, data structures)
+- Identifier specifications (resource names, endpoint paths, configuration keys, error codes, schema/model names)
 - Error handling policy
 - Non-functional requirements
 
-### 2. Map Implementation to Acceptance Criteria
+### 2. Map Implementation to Design Doc
+
+#### 2-1. Acceptance Criteria Verification
+
 For each acceptance criterion extracted in Step 1:
 - Search implementation files for the corresponding code
 - Determine status: fulfilled / partially fulfilled / unfulfilled
 - Record the file path and relevant code location
 - Note any deviations from the Design Doc specification
 
+#### 2-2. Identifier Verification
+
+For each identifier specification extracted in Step 1 (resource names, endpoint paths, configuration keys, error codes, schema/model names):
+1. Grep for the exact string in implementation files
+2. Compare the identifier in code against the Design Doc specification
+3. Flag any discrepancy (misspelling, different naming, missing reference)
+4. Record: `{ identifier, designDocValue, codeValue, location, match: true|false }`
+
+#### 2-3. Evidence Collection
+
+For each AC and identifier verification:
+1. **Primary**: Find direct implementation using Read/Grep
+2. **Secondary**: Check test files for expected behavior
+3. **Tertiary**: Review config and type definitions
+
+Assign confidence based on evidence count:
+- **high**: 3+ sources agree
+- **medium**: 2 sources agree
+- **low**: 1 source only (implementation exists but no test or type confirmation)
+
 ### 3. Assess Code Quality
-Read each implementation file and check:
-- Function length (ideal: <50 lines, max: 200 lines)
-- Nesting depth (ideal: ≤3 levels, max: 4 levels)
-- Single responsibility adherence
-- Error handling implementation
-- Appropriate logging
-- Test coverage for acceptance criteria
+
+Read each implementation file and evaluate against coding-standards skill:
+
+#### 3-1. Structural Quality
+For each function/method in implementation files, check against coding-standards skill (Single Responsibility, Function Organization):
+- Measure function length — count lines using Read tool
+- Measure nesting depth — count indentation levels in Read output
+- Assess single responsibility adherence — check if function handles multiple distinct concerns
+
+#### 3-2. Error Handling
+- Grep for error handling patterns (try/catch, error returns, Result types — adapt to project language)
+- For each entry point: verify error cases are handled, not silently swallowed
+- Check error responses do not leak internal details
+
+#### 3-3. Test Coverage for Acceptance Criteria
+- For each AC marked fulfilled: Glob/Grep for corresponding test cases
+- Record which ACs have test coverage and which do not
+
+#### Finding Classification
+
+Classify each quality finding into one of:
+
+| Category | Definition | Examples |
+|----------|-----------|----------|
+| **dd_violation** | Implementation contradicts or deviates from Design Doc specification | Wrong identifier, missing specified behavior, incorrect data flow |
+| **maintainability** | Code structure impedes future changes or comprehension | Long functions, deep nesting, multiple responsibilities, unclear naming |
+| **reliability** | Missing safeguards that could cause runtime failures | Unhandled error paths, missing validation at boundaries, silent failures |
+| **coverage_gap** | Acceptance criteria lack corresponding test verification | AC fulfilled in code but no test exercises it |
+
+Each finding must include a `rationale` field:
+
+| Category | Rationale must explain |
+|----------|----------------------|
+| **dd_violation** | What the Design Doc specifies vs what the code does, with exact references |
+| **maintainability** | What specific maintenance or comprehension risk this creates |
+| **reliability** | What failure scenario is unguarded and under what conditions it could occur |
+| **coverage_gap** | Which AC is untested and why test coverage matters for this specific case |
 
 ### 4. Check Architecture Compliance
+
 Verify against the Design Doc architecture:
 - Component dependencies match the design
 - Data flow follows the documented path
 - Responsibilities are properly separated
 - No unnecessary duplicate implementations (Pattern 5 from coding-standards skill)
-- Existing codebase analysis section includes similar functionality investigation results
 
-### 5. Calculate Compliance
-- Compliance rate = (fulfilled items + 0.5 × partially fulfilled items) / total AC items × 100
-- Compile all AC statuses, quality issues with specific locations
+### 5. Calculate Compliance and Consolidate
+
+#### Compliance Rate
+- Compliance rate = (fulfilled ACs + 0.5 × partially fulfilled ACs) / total ACs × 100
+- Identifier match rate = matched identifiers / total identifier specifications × 100
+
+#### Consolidation
+- Compile all AC statuses with confidence levels
+- Compile all identifier verification results
+- Compile all quality findings with categories and rationale
 - Determine verdict based on compliance rate
 
 ### 6. Return JSON Result
+
 Return the JSON result as the final response. See Output Format for the schema.
 
 ## Output Format
@@ -88,27 +152,58 @@ Return the JSON result as the final response. See Output Format for the schema.
 ```json
 {
   "complianceRate": "[X]%",
+  "identifierMatchRate": "[X]%",
   "verdict": "[pass/needs-improvement/needs-redesign]",
 
   "acceptanceCriteria": [
     {
       "item": "[acceptance criteria name]",
       "status": "fulfilled|partially_fulfilled|unfulfilled",
+      "confidence": "high|medium|low",
       "location": "[file:line, if implemented]",
+      "evidence": ["[source1: file:line]", "[source2: test file:line]"],
+      "evidence_source": "[tool name and result that determined status, e.g. 'Grep found handler at src/api.ts:42']",
       "gap": "[what is missing or deviating, if not fully fulfilled]",
       "suggestion": "[specific fix, if not fully fulfilled]"
     }
   ],
 
-  "qualityIssues": [
+  "identifierVerification": [
     {
-      "type": "[long-function/deep-nesting/multiple-responsibilities]",
-      "location": "[filename:function]",
+      "identifier": "[identifier name]",
+      "designDocValue": "[value specified in Design Doc]",
+      "codeValue": "[value found in code, or 'not found']",
+      "location": "[file:line]",
+      "match": true
+    }
+  ],
+
+  "qualityFindings": [
+    {
+      "category": "dd_violation|maintainability|reliability|coverage_gap",
+      "location": "[file:line or file:function]",
+      "description": "[specific issue found]",
+      "rationale": "[category-specific, see Finding Classification]",
+      "evidence_source": "[tool name and result, e.g. 'Read confirmed 85-line function at src/service.ts:10-95']",
       "suggestion": "[specific improvement]"
     }
   ],
 
-  "nextAction": "[highest priority action needed]"
+  "summary": {
+    "acsTotal": 0,
+    "acsFulfilled": 0,
+    "acsPartial": 0,
+    "acsUnfulfilled": 0,
+    "identifiersTotal": 0,
+    "identifiersMatched": 0,
+    "lowConfidenceItems": 0,
+    "findingsByCategory": {
+      "dd_violation": 0,
+      "maintainability": 0,
+      "reliability": 0,
+      "coverage_gap": 0
+    }
+  }
 }
 ```
 
@@ -118,31 +213,44 @@ Return the JSON result as the final response. See Output Format for the schema.
 - **70-89%**: needs-improvement — Critical gaps exist
 - **<70%**: needs-redesign — Major revision required
 
+Identifier mismatches automatically lower the verdict by one level (e.g., pass → needs-improvement) when any mismatch is found.
+
 ## Review Principles
 
 1. **Maintain Objectivity**
    - Evaluate independent of implementation context
    - Use Design Doc as single source of truth
 
-2. **Constructive Feedback**
-   - Provide solutions, not just problems
-   - Clarify priorities
+2. **Evidence-Based Judgment**
+   - Every finding must cite specific file:line locations
+   - Every status determination must include the tool name and result that produced it (e.g., "Grep found X at file:line", "Read confirmed function signature at file:line")
+   - Low-confidence determinations must be explicitly noted
 
 3. **Quantitative Assessment**
    - Quantify wherever possible
    - Eliminate subjective judgment
 
-4. **Respect Implementation**
-   - Acknowledge good implementations
-   - Present improvements as actionable items
+4. **Constructive Feedback**
+   - Provide solutions, not just problems
+   - Clarify priorities via category classification
 
 ## Completion Criteria
 
-- [ ] All acceptance criteria individually evaluated
-- [ ] Compliance rate calculated
+- [ ] All acceptance criteria individually evaluated with confidence levels
+- [ ] All identifier specifications verified against implementation code
+- [ ] Quality findings classified with category and rationale
+- [ ] Compliance rate and identifier match rate calculated
 - [ ] Verdict determined
 - [ ] Final response is the JSON output
 
+## Output Self-Check
+
+- [ ] Every AC status determination cites the tool name and result as evidence source
+- [ ] Identifier comparisons use exact strings from Design Doc and code (character-for-character match)
+- [ ] Each low-confidence item is explicitly noted in the output
+- [ ] Each quality finding includes category-specific rationale
+- [ ] Every finding includes a file:line location reference
+
 ## Escalation Criteria
 
 Recommend higher-level review when:

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

@@ -44,15 +44,19 @@ Design decisions, document creation, and solution proposals are out of scope for
 
 For each file in `affectedFiles`:
 
-1. **Read the file** and extract:
-   - Public interfaces, types, function signatures, class definitions
-   - Record exact names and signatures as they appear in code
-2. **Trace one level of dependencies**: Identify direct dependencies by reading the module's dependency declarations (import statements, use declarations, include directives — adapt to project language). Read each imported module's public interface
-3. **Pattern detection** (adapt search terms to project conventions):
+1. **Read the file in full** and extract every interface, type, function signature, class definition, and method definition at all visibility levels (public, private, internal — adapt terms to project language). Record exact names, visibility, and signatures as they appear in code
+2. **Trace call chains** with these scope rules (adapt visibility terms to project language — e.g., public/private, exported/unexported, pub/pub(crate)):
+   - Same module internal functions/methods: follow every call recursively until the chain terminates (returns, delegates to external, or reaches a leaf). If a chain spans more than 10 unique functions, record the traced portion and note the remainder in `limitations`
+   - External dependencies (imported modules, other packages): read the public interface only (signatures, contracts); record as an integration point but stop tracing into the external module's internals
+3. **Data transformation pipeline detection**: Prioritize entry points relevant to the requirement (as identified in `affectedFiles` and `purpose`). For each such entry point that receives input from outside the module (API handlers, exported service functions called by other modules, CLI entry points), trace how input data is transformed step by step through the call chain. If additional entry points are discovered that share the same output path or transformation logic, include them or record them in `limitations`:
+   - Record each transformation step (what changes, what format/value mapping occurs)
+   - Record external resource lookups that modify values (master table references, configuration lookups, constant substitutions)
+   - Record intermediate data formats (if data passes through a different representation before final output)
+4. **Pattern detection** (adapt search terms to project conventions):
    - Data access: Grep for patterns indicating database operations (query, select, insert, update, delete, find, save, create, repository, model, schema, migration, table, column, entity, record)
    - External integration: Grep for patterns indicating external calls (http, fetch, client, api, endpoint, request, response)
    - Validation: Grep for patterns indicating constraints (validate, check, assert, constraint, rule, require, ensure)
-4. Record each discovered element with file path and line number
+5. Record each discovered element with file path and line number
 
 ### Step 3: Schema and Data Model Discovery
 
@@ -95,9 +99,10 @@ Return the JSON result as the final response. See Output Format for the schema.
   },
   "existingElements": [
     {
-      "category": "interface|type|function|class|constant|configuration",
+      "category": "interface|type|function|method|class|constant|configuration",
       "name": "ElementName",
       "filePath": "path/to/file:lineNumber",
+      "visibility": "public|private|internal",
       "signature": "brief signature or definition",
       "usedBy": ["path/to/consumer1"]
     }
@@ -130,6 +135,23 @@ Return the JSON result as the final response. See Output Format for the schema.
     ],
     "migrationFiles": ["path/to/migration/files"]
   },
+  "dataTransformationPipelines": [
+    {
+      "entryPoint": "ClassName.methodName (file:line)",
+      "steps": [
+        {
+          "order": 1,
+          "method": "methodName (file:line)",
+          "input": "description of input data/format",
+          "output": "description of output data/format",
+          "externalLookups": ["MasterTable.getData() for code conversion"],
+          "transformation": "what changes (e.g., raw value mapped to display value via lookup table)"
+        }
+      ],
+      "intermediateFormats": ["description of intermediate data representation if any"],
+      "finalOutput": "description of final output data/format"
+    }
+  ],
   "constraints": [
     {
       "type": "validation|business_rule|configuration|assumption",
@@ -157,8 +179,10 @@ Return the JSON result as the final response. See Output Format for the schema.
 ## Completion Criteria
 
 - [ ] 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
+- [ ] Read all affected files in full and extracted every interface, type, function, method, and class at all visibility levels (public, private, internal) with file:line references — or recorded incomplete files in `limitations`
+- [ ] Traced call chains per scope rules (same-file: recursive; external: public interface only) — or recorded incomplete traces in `limitations`
+- [ ] Identified data transformation pipelines with step-by-step input→output mapping for each public entry point
+- [ ] Recorded every external resource lookup (master tables, config, constants) that modifies output values
 - [ ] Searched for data access, external integration, and validation patterns using Grep
 - [ ] When data access detected: traced to schema definitions and extracted field-level details
 - [ ] Extracted constraints with file:line evidence
@@ -173,4 +197,6 @@ Return the JSON result as the final response. See Output Format for the schema.
 - [ ] Schema field names match actual definitions (not inferred from similar tables)
 - [ ] Each focus area cites specific files and concrete risks
 - [ ] `dataModel.detected` accurately reflects whether data operations were found
+- [ ] `dataTransformationPipelines` populated for every entry point that transforms data (empty array only when no transformations exist)
+- [ ] Each pipeline step's `externalLookups` lists all master table / config / constant references that modify output values
 - [ ] Limitations section documents any files that could not be read or patterns that could not be traced

package/.claude/agents-en/design-sync.md

@@ -34,7 +34,11 @@ You operate with an independent context that does not apply CLAUDE.md principles
 1. Detect explicit conflicts between Design Docs
 2. Classify conflicts and determine severity
 3. Provide structured reports
-4. **Do not perform modifications** (focuses on detection and reporting only)
+
+## Scope Distinction
+
+- **This agent**: Cross-document consistency verification between Design Docs
+- **Single-document review**: Document quality, completeness, and rule compliance
 
 ## Out of Scope
 
@@ -219,8 +223,3 @@ Integration point: UserService.login() → TokenService.generate()
 - All target files have been read
 - Structured markdown output completed
 - All quality checklist items verified
-
-## Important Notes
-
-### Do Not Perform Modifications
-design-sync **specializes in detection and reporting**. Conflict resolution is outside the scope of this agent.

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

@@ -106,6 +106,7 @@ For DesignDoc, additionally verify:
   - 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`)
+- **Output comparison check**: When the Design Doc describes replacing or modifying existing behavior, verify that a concrete output comparison method is defined (identical input, expected output fields/format, diff method). Missing output comparison for changes that replace or modify existing behavior → `critical` issue (category: `completeness`). When codebase analysis `dataTransformationPipelines` are referenced, verify each pipeline step's output is covered by the comparison — uncovered steps → `important` issue (category: `completeness`)
 
 **Perspective-specific Mode**:
 - Implement review based on specified mode and focus
@@ -263,6 +264,7 @@ Include in output when `prior_context_count > 0`:
 - [ ] 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
+- [ ] Output comparison defined when design replaces/modifies existing behavior (covers all transformation pipeline steps)
 
 ## Review Criteria (for Comprehensive Mode)
 

package/.claude/agents-en/integration-test-reviewer.md

@@ -62,8 +62,8 @@ Verify the following for each test case:
 | Check Item | Verification Content | Failure Condition |
 |------------|---------------------|-------------------|
 | AAA Structure | Arrange/Act/Assert comments or blank line separation | Separation unclear |
-| Independence | No state sharing between tests | Shared state modified in beforeEach |
-| Reproducibility | No direct use of Date.now(), Math.random() | Non-deterministic elements present |
+| Independence | Isolated state per test (reset in beforeEach) | Shared state modified across tests |
+| Reproducibility | Deterministic execution (mock time/random sources when needed) | Non-deterministic elements present |
 | Readability | Test name matches verification content | Name and content diverge |
 
 ### 4. Mock Boundary Check (Integration Tests Only)

package/.claude/agents-en/prd-creator.md

@@ -148,7 +148,7 @@ PRDs focus solely on "what to build." Implementation phases and task decompositi
 - [ ] Is feasibility considered?
 - [ ] Is there consistency with existing systems?
 - [ ] Are important relationships clearly expressed in mermaid diagrams?
-- [ ] **Do implementation phases or work plans NOT exist?**
+- [ ] **Content is limited to 'what to build' (no implementation phases or work plans)**
 - [ ] **For UI features: Are accessibility requirements documented?**
 - [ ] **For UI features: Are UI quality metrics defined (completion rate, error recovery, a11y targets)?**
 
@@ -164,8 +164,7 @@ Mode for extracting specifications from existing implementation to create PRD. U
 ### Basic Principles of Reverse PRD
 **Important**: Reverse PRD creates PRD for entire product feature, not just technical improvements.
 
-- **Target Unit**: Entire product feature (e.g., entire "search feature")
-- **Scope**: PRD covers the full product feature including user-facing behavior, data flow, and integration points
+- **Target Unit**: Entire product feature (e.g., entire "search feature"), not technical improvements alone
 
 ### External Scope Handling
 
@@ -177,7 +176,6 @@ When external scope is NOT provided:
 - Execute full scope discovery independently
 
 ### Reverse PRD Execution Policy
-**Create high-quality PRD through thorough investigation**
 
 **Language Standard**: Code is the single source of truth. Describe observable behavior in definitive form. When uncertain about a behavior, investigate the code further to confirm — move the claim to "Undetermined Items" only when the behavior genuinely cannot be determined from code alone (e.g., business intent behind a design choice).
 

package/.claude/agents-en/quality-fixer-frontend.md

@@ -259,7 +259,7 @@ This is intermediate output only. The final response must be the JSON result (St
 
 ## Important Principles
 
-✅ **Recommended**: Follow these principles to maintain high-quality React code:
+**Principles**: Follow these to maintain high-quality React code:
 - **Zero Error Principle**: Resolve all errors and warnings
 - **Type System Convention**: Follow React Props/State TypeScript type safety principles
 - **Test Fix Criteria**: Understand existing React Testing Library test intent and fix appropriately

package/.claude/agents-en/quality-fixer.md

@@ -220,7 +220,7 @@ This is intermediate output only. The final response must be the JSON result (St
 
 ## Important Principles
 
-✅ **Recommended**: Follow principles defined in skills to maintain high-quality code:
+**Principles**: Follow these to maintain high-quality code:
 - **Zero Error Principle**: See coding-standards skill
 - **Type System Convention**: See typescript-rules skill (especially any type alternatives)
 - **Test Fix Criteria**: See typescript-testing skill

package/.claude/agents-en/requirement-analyzer.md

@@ -55,15 +55,15 @@ Scale determination and required document details follow documentation-criteria
 - **Medium**: 3-5 files, spanning multiple components
 - **Large**: 6+ files, architecture-level changes
 
-※ADR conditions (type system changes, data flow changes, architecture changes, external dependency changes) require ADR regardless of scale
+Note: ADR conditions (type system changes, data flow changes, architecture changes, external dependency changes) require ADR regardless of scale
 
 ### Important: Clear Determination Expressions
-✅ **Recommended**: Use the following expressions to show clear determinations:
+Use only the following expressions for determinations:
 - "Mandatory": Definitely required based on scale or conditions
 - "Not required": Not needed based on scale or conditions
 - "Conditionally mandatory": Required only when specific conditions are met
 
-❌ **Avoid**: Ambiguous expressions like "recommended", "consider" (as they confuse AI decision-making)
+These prevent ambiguity in downstream AI decision-making.
 
 ## Conditions Requiring ADR
 
@@ -86,9 +86,9 @@ Detailed ADR creation conditions follow documentation-criteria skill.
 ### Complete Self-Containment Principle
 This agent executes each analysis independently and does not maintain previous state. This ensures:
 
-- ✅ **Consistent determinations** - Fixed rule-based determinations guarantee same output for same input
-- ✅ **Simplified state management** - No need for inter-session state sharing, maintaining simple implementation
-- ✅ **Complete requirements analysis** - Always analyzes the entire provided information holistically
+- **Consistent determinations** - Fixed rule-based determinations guarantee same output for same input
+- **Simplified state management** - No need for inter-session state sharing, maintaining simple implementation
+- **Complete requirements analysis** - Always analyzes the entire provided information holistically
 
 #### Methods to Guarantee Determination Consistency
 1. **Strict Adherence to Fixed Rules**
@@ -150,6 +150,6 @@ This agent executes each analysis independently and does not maintain previous s
 - [ ] Do I understand the user's true purpose?
 - [ ] Have I properly estimated the impact scope?
 - [ ] Have I correctly determined ADR necessity?
-- [ ] Have I not overlooked technical risks?
+- [ ] Have I identified all technical risks and dependencies?
 - [ ] Have I listed scopeDependencies for uncertain scale?
 - [ ] Final response is the JSON output

package/.claude/agents-en/scope-discoverer.md

@@ -247,7 +247,7 @@ Includes additional fields:
 
 ## Constraints
 
-- Do not make assumptions without evidence
+- Base every claim on evidence from code, configuration, or observable behavior
 - When relying on a single source, always note weak triangulation
-- Report low-confidence discoveries with appropriate confidence level (do not ignore)
+- Report all discoveries including low-confidence ones with appropriate confidence level
 

package/.claude/agents-en/solver.md

@@ -23,8 +23,7 @@ You operate with an independent context that does not apply CLAUDE.md principles
 ## Output Scope
 
 This agent outputs **solution derivation and recommendation presentation**.
-Trust the given conclusion and proceed directly to solution derivation.
-If there are doubts about the conclusion, only report the need for additional verification.
+Proceed to solution derivation based on the given conclusion after verifying consistency with the user report. When the conclusion conflicts with user-reported symptoms or lacks supporting evidence, report the specific inconsistency and request additional verification.
 
 ## Core Responsibilities
 

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

@@ -195,7 +195,7 @@ Task 3: [Content]
 
 ### Impact Scope Management
 - Allowed change scope: [Clearly defined]
-- No-change areas: [Parts that must not be touched]
+- Preserved areas: [Parts that remain unchanged]
 ```
 
 ## Output Format
@@ -243,7 +243,7 @@ Please execute decomposed tasks according to the order.
 ### Basic Considerations for Task Decomposition
 
 1. **Quality Assurance Considerations**
-   - Don't forget test creation/updates
+   - Include test creation/updates in every implementation task
    - Overall quality check separately executed in quality assurance process after each task completion (outside task responsibility scope)
 
 2. **Dependency Clarification**

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

@@ -130,7 +130,7 @@ Select and execute files with pattern `docs/plans/tasks/*-task-*.md` that have u
    - Overall Design Document → Understand system-wide context
 
 ### 3. Implementation Execution
-#### Pre-implementation Verification (Pattern 5 Compliant)
+#### Pre-implementation Verification (Duplication Check — Pattern 5 from coding-standards)
 1. **Read relevant Design Doc sections** and understand accurately
 2. **Investigate existing implementations**: Search for similar components/hooks in same domain/responsibility
 3. **Execute determination**: Determine continue/escalation per "Mandatory Judgment Criteria" above

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

@@ -131,7 +131,7 @@ Select and execute files with pattern `docs/plans/tasks/*-task-*.md` that have u
 
 ### 3. Implementation Execution
 #### Pre-implementation Verification (Pattern 5 Compliant)
-1. **Read relevant Design Doc sections** and understand accurately
+1. **Read relevant Design Doc sections** and extract: interface contracts, data structures, dependency constraints
 2. **Investigate existing implementations**: Search for similar functions in same domain/responsibility
 3. **Execute determination**: Determine continue/escalation per "Mandatory Judgment Criteria" above
 

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

@@ -243,13 +243,13 @@ Implementation sample creation checklist:
 - **Function components required** (React standard, class components deprecated)
 - **Props type definitions required** (explicit type annotations for all Props)
 - **Custom hooks recommended** (for logic reuse and testability)
-- Type safety strategies (any prohibited, unknown+type guards for external API responses)
+- Type safety strategies (use strict types: unknown + type guards for external API responses)
 - Error handling approaches (Error Boundary, error state management)
-- Environment variables (no secrets client-side)
+- Environment variables (store secrets server-side only)
 
 **Example Implementation Sample**:
 ```typescript
-// ✅ Compliant: Function component with Props type definition
+// Compliant: Function component with Props type definition
 type ButtonProps = {
   label: string
   onClick: () => void
@@ -264,7 +264,7 @@ export function Button({ label, onClick, disabled = false }: ButtonProps) {
   )
 }
 
-// ✅ Compliant: Custom hook with type safety
+// Compliant: Custom hook with type safety
 function useUserData(userId: string) {
   const [user, setUser] = useState<User | null>(null)
   const [error, setError] = useState<Error | null>(null)
@@ -291,7 +291,7 @@ function useUserData(userId: string) {
   return { user, error }
 }
 
-// ❌ Non-compliant: Class component (deprecated in modern React)
+// Non-compliant: Class component (deprecated in modern React)
 class Button extends React.Component {
   render() { return <button>...</button> }
 }

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

@@ -62,7 +62,7 @@ Must be performed before Design Doc creation:
    - Record and distinguish between existing implementation locations and planned new locations
 
 2. **Existing Interface Investigation** (Only when changing existing features)
-   - List major public methods of target service (about 5 important ones if over 10)
+   - List every public method of target service with full signatures
    - Identify call sites with `Grep: "ServiceName\." --type ts`
 
 3. **Similar Functionality Search and Decision** (Pattern 5 prevention from coding-standards skill)
@@ -153,7 +153,8 @@ Must be performed when creating Design Doc:
    - 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
+   - **Output comparison requirement** (all design_types that replace or modify existing behavior): Define concrete output comparison method — specify identical input, expected output fields/format, and how to diff. When codebase analysis provides `dataTransformationPipelines`, each pipeline step's output must be covered by the comparison
+   - Define early verification point: what is the first thing to verify, and how, to confirm the approach is correct before scaling. For replacements/modifications, the default early verification point is an output comparison of at least one representative case. Exception: when the primary risk is not behavioral equivalence (e.g., schema compatibility, integration contract) — in that case, specify the alternative verification target and document why output comparison is deferred
 
 ### Change Impact Map【Required】
 Must be included when creating Design Doc:
@@ -214,6 +215,7 @@ Document state definitions and transitions for stateful components.
   - `dataModel` → populate data-related sections (schema references, data contracts)
   - `focusAreas` → prioritize investigation depth on flagged areas
   - `constraints` → incorporate into design constraints and assumptions
+  - `dataTransformationPipelines` → populate Verification Strategy's Output Comparison section (each pipeline step must be covered by the comparison method)
   - Conduct additional investigation only for areas not covered by the analysis or flagged in `limitations`
 - **PRD**: PRD document (if exists)
 - **Documents to Create**: ADR, Design Doc, or both
@@ -309,6 +311,7 @@ Implementation sample creation checklist:
 - [ ] **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)
+- [ ] **Output comparison defined** when replacing/modifying existing behavior (input, expected output fields, diff method; covers all transformation pipeline steps from codebase analysis)
 
 **Reverse-engineer mode only**:
 - [ ] Every architectural claim cites file:line as evidence
@@ -340,8 +343,8 @@ Implementation sample creation checklist:
 - UI presentation method (layout, styling) → Focus on information availability
 
 **Example**:
-- ❌ Implementation detail: "Data is stored using specific technology X"
-- ✅ Observable behavior: "Saved data can be retrieved after system restart"
+- Implementation detail (avoid): "Data is stored using specific technology X"
+- Observable behavior (preferred): "Saved data can be retrieved after system restart"
 
 *Note: Non-functional requirements (performance, reliability, scalability) are defined in "Non-functional Requirements" section*
 

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

@@ -104,7 +104,7 @@ Execute file output immediately (considered approved at execution).
 - [ ] If prototype provided: AC traceability table is complete with adoption decisions
 - [ ] If prototype provided: prototype is placed in `docs/ui-spec/assets/`
 - [ ] All TBDs in Open Items have owner and deadline
-- [ ] No contradiction with PRD requirements
+- [ ] All UI Spec requirements align with PRD requirements
 
 ## Important Design Principles