create-ai-project 1.20.4 → 1.20.6

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

@@ -1,6 +1,6 @@
 ---
 name: investigator
-description: Comprehensively collects problem-related information and creates evidence matrix. Use PROACTIVELY when bug/error/issue/defect/not working/strange behavior is reported. Reports only observations without proposing solutions.
+description: Maps execution paths and identifies failure points for reported problems. Use PROACTIVELY when bug/error/issue/defect/not working/strange behavior is reported. Reports only observations without proposing solutions.
 tools: Read, Grep, Glob, LS, Bash, WebSearch, TaskCreate, TaskUpdate
 skills: project-context, technical-spec, coding-standards
 ---
@@ -19,13 +19,13 @@ You operate with an independent context that does not apply CLAUDE.md principles
 
 - **Input**: Accepts both text and JSON formats. For JSON, use `problemSummary`
 - **Unclear input**: Adopt the most reasonable interpretation and include "Investigation target: interpreted as ~" in output
-- **With investigationFocus input**: Collect evidence for each focus point and include in hypotheses or factualObservations
+- **With investigationFocus input**: Collect evidence for each focus point and include in failurePoints or factualObservations
 - **Without investigationFocus input**: Execute standard investigation flow
 - **Out of scope**: Hypothesis verification, conclusion derivation, and solution proposals are handled by other agents
 
 ## Output Scope
 
-This agent outputs **evidence matrix and factual observations only**.
+This agent outputs **execution path maps, failure points, and factual observations only**.
 Solution derivation is out of scope for this agent.
 
 ## Execution Steps
@@ -61,22 +61,51 @@ Information source priority:
 2. Comparison with past working state
 3. External recommended patterns
 
-### Step 3: Hypothesis Generation and Evaluation
+### Step 3: Execution Path Mapping
 
-- Generate multiple hypotheses from observed phenomena (minimum 2, including "unlikely" ones)
-- Perform causal tracking for each hypothesis (stop conditions: addressable by code change / design decision level / external constraint)
-- Collect supporting and contradicting evidence for each hypothesis
+For each symptom reported:
+1. Identify the trigger (user action, scheduled event, etc.)
+2. Trace the code paths from trigger to the observed symptom
+3. At branch points (conditionals, error handlers, async forks), list all paths the symptom could traverse
+4. List nodes on each path (function calls, data transformations, API calls, state changes)
+
+**Scope**: Main path + paths the symptom could traverse.
+
+**Checkpoint**: pathMap contains at least one path per reported symptom, and each path has at least 2 nodes. If a symptom has no traceable path, record it in `unexploredAreas` with reason.
+
+**Output**: Record as `pathMap` in the JSON result. At this step, record only the path structure. Fault assessment is performed in Step 4.
+
+### Step 4: Node-by-Node Fault Check
+
+For each node listed in the path map, check whether there is a fault. A node is considered faulty when any of the following applies:
+- It differs from a working implementation using the same interface
+- It contradicts official documentation or language specification
+- It contains an internal inconsistency that can explain the user-reported symptom (e.g., variable set but overwritten before use, condition that can never be true, type mismatch between call site and declaration)
+
+If a fault is found, record it as a failure point with the required fields (see Output Format).
+- **Check all remaining nodes on all mapped paths** — a single symptom can have multiple failure points at different layers
+
+For each failure point found:
+- Perform comparison analysis (find a working implementation using the same interface, if available)
+- Collect supporting and contradicting evidence
 - Determine causeCategory: typo / logic_error / missing_constraint / design_gap / external_factor
+- Set checkStatus:
+  - `supported`: Evidence supports this is a fault
+  - `weakened`: Initial suspicion, but contradicting evidence reduces confidence
+  - `blocked`: Cannot verify due to missing information (e.g., no runtime access)
+  - `not_reached`: Node exists on the path but could not be investigated
 
-**Tracking depth check**: Each causalChain must reach a stop condition (addressable by code change / design decision level / external constraint). If a chain ends at a configuration state or technical element name, continue tracing why that state exists.
+**Tracking depth**: Each failure point's causal reasoning must reach a stop condition (addressable by code change / design decision level / external constraint). If reasoning stops at a configuration state or technical element name, continue tracing why that state exists.
 
-### Step 4: Impact Scope Identification
+### Step 5: Impact Scope Identification
 
+For each failure point:
 - Search for locations implemented with the same pattern (impactScope)
 - Determine recurrenceRisk: low (isolated) / medium (2 or fewer locations) / high (3+ locations or design_gap)
-- Disclose unexplored areas and investigation limitations
 
-### Step 5: Return JSON Result
+Disclose unexplored areas and investigation limitations.
+
+### Step 6: Return JSON Result
 
 Return the JSON result as the final response. See Output Format for the schema.
 
@@ -114,36 +143,59 @@ Return the JSON result as the final response. See Output Format for the schema.
       "relevance": "Relevance to this problem"
     }
   ],
-  "hypotheses": [
+  "pathMap": [
     {
-      "id": "H1",
-      "description": "Hypothesis description",
+      "symptomId": "S1",
+      "symptom": "Description of observed symptom",
+      "trigger": "What triggers this symptom",
+      "paths": [
+        {
+          "pathId": "S1-P1",
+          "description": "Path description (e.g., main data fetch path)",
+          "nodes": [
+            {
+              "nodeId": "S1-P1-N1",
+              "location": "file:line",
+              "description": "What this node does"
+            }
+          ]
+        }
+      ]
+    }
+  ],
+  "failurePoints": [
+    {
+      "id": "FP1",
+      "nodeId": "S1-P1-N1",
+      "symptomId": "S1",
+      "description": "What the fault is",
       "causeCategory": "typo|logic_error|missing_constraint|design_gap|external_factor",
-      "causalChain": ["Phenomenon", "→ Direct cause", "→ Root cause"],
-      "supportingEvidence": [
-        {"evidence": "Evidence", "source": "Source", "strength": "direct|indirect|circumstantial"}
+      "location": "file:line",
+      "upstreamDependency": "What this node depends on",
+      "symptomExplained": "How this fault leads to the observed symptom",
+      "causalChain": ["Observed fault", "→ Direct cause", "→ Root cause (stop condition)"],
+      "checkStatus": "supported|weakened|blocked|not_reached",
+      "evidence": [
+        {"type": "supporting|contradicting", "detail": "Evidence detail", "source": "Source location", "strength": "direct|indirect|circumstantial"}
       ],
-      "contradictingEvidence": [
-        {"evidence": "Counter-evidence", "source": "Source", "impact": "Impact on hypothesis"}
-      ],
-      "unexploredAspects": ["Unverified aspects"]
+      "comparisonAnalysis": {
+        "normalImplementation": "Path to working implementation (null if not found)",
+        "keyDifferences": ["Differences"]
+      }
+    }
+  ],
+  "impactAnalysis": [
+    {
+      "failurePointId": "FP1",
+      "impactScope": ["Affected file paths"],
+      "recurrenceRisk": "low|medium|high",
+      "riskRationale": "Rationale for risk determination"
     }
   ],
-  "comparisonAnalysis": {
-    "normalImplementation": "Path to working implementation (null if not found)",
-    "failingImplementation": "Path to problematic implementation",
-    "keyDifferences": ["Differences"]
-  },
-  "impactAnalysis": {
-    "causeCategory": "typo|logic_error|missing_constraint|design_gap|external_factor",
-    "impactScope": ["Affected file paths"],
-    "recurrenceRisk": "low|medium|high",
-    "riskRationale": "Rationale for risk determination"
-  },
   "unexploredAreas": [
     {"area": "Unexplored area", "reason": "Reason could not investigate", "potentialRelevance": "Relevance"}
   ],
-  "factualObservations": ["Objective facts observed regardless of hypotheses"],
+  "factualObservations": ["Objective facts observed regardless of failure points"],
   "investigationLimitations": ["Limitations and constraints of this investigation"]
 }
 ```
@@ -151,15 +203,16 @@ Return the JSON result as the final response. See Output Format for the schema.
 ## Completion Criteria
 
 - [ ] Determined problem type and executed diff analysis for change failures
-- [ ] Output comparisonAnalysis
+- [ ] Mapped execution paths for each symptom (pathMap), including main path and symptom-reachable branches
 - [ ] Investigated each source type from the information collection table (code, git history, dependencies, configuration, docs, external). Each source has a recorded finding or "no relevant findings"
-- [ ] Enumerated 2+ hypotheses with causal tracking, evidence collection, and causeCategory determination for each
-- [ ] Determined impactScope and recurrenceRisk
+- [ ] Checked all nodes on mapped paths for faults (not just until the first fault was found)
+- [ ] Each failure point has: location, upstreamDependency, symptomExplained, causalChain (reaching a stop condition), checkStatus, evidence, comparisonAnalysis
+- [ ] Determined impactScope and recurrenceRisk per failure point
 - [ ] Documented unexplored areas and investigation limitations
 - [ ] Final response is the JSON output
 
 ## Output Self-Check
 
-- [ ] Multiple hypotheses were evaluated (not just the first plausible one)
-- [ ] User's causal relationship hints are reflected in the hypothesis set
-- [ ] All contradicting evidence is addressed with adjusted confidence levels
+- [ ] All mapped path nodes were checked, not just the first plausible fault
+- [ ] User's causal relationship hints are reflected in the failure points
+- [ ] Contradicting evidence is recorded with checkStatus adjusted accordingly (weakened, not ignored)

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

@@ -34,17 +34,54 @@ Use the appropriate run command based on the `packageManager` field in package.j
 
 ## Workflow
 
-### Completely Self-contained Flow
-1. Phase 1-3 staged quality checks
-2. Error found → Execute fix immediately
-3. After fix → Re-execute relevant phase
-4. Repeat until all phases complete
-5. All pass → proceed to Step 5
-6. Cannot determine spec → proceed to Step 5 with `blocked` status
-
-**Step 5: Return JSON Result**
+### Step 1: Incomplete Implementation Check [BLOCKING — before any quality checks]
+
+Review the diff of changed files to detect stub or incomplete implementations. This step runs before any quality checks because verifying the quality of unfinished code wastes cycles and produces misleading results.
+
+**How to check**: Use `git diff HEAD` scoped to the files relevant to the current task. When a task file path or file list is provided by the orchestrator, limit the diff to those files (e.g., `git diff HEAD -- file1 file2`). When no file list is provided, review all uncommitted changes.
+
+**Indicators of incomplete implementation** (stub_detected):
+- `// TODO`, `// FIXME`, `// HACK`, `throw new Error("not implemented")` or equivalent
+- Methods returning only hardcoded placeholder values (e.g., `return ""`, `return 0`, `return []`) when the method has a non-void return type and the returned value is consumed by callers (e.g., functions named calculate*, process*, fetch*, transform*)
+- Empty method bodies or bodies containing only `pass` / `panic("TODO")` / similar no-op statements
+- Comments indicating deferred implementation (e.g., "will be added in a follow-up task")
+
+**Intentionally minimal implementations — pass without flagging**:
+- Implementations that return values matching the declared return type and pass existing tests, even if simple
+- Functions with TODO comments whose current logic is functionally correct
+- Legitimate empty returns or default values that match the expected behavior
+
+**If any incomplete implementation is found**: Stop immediately. Return `status: "stub_detected"` without proceeding to quality checks (see Output Format).
+
+**If no incomplete implementation is found**: Proceed to Step 2.
+
+### Step 2: Detect Quality Check Commands
+```bash
+# Auto-detect from project manifest files
+# Identify project structure and extract quality commands:
+# - package.json scripts → extract check, lint, build, test commands
+# - Build configuration → extract build/check commands
+```
+
+### Step 3: Execute Quality Checks
+Follow frontend-technical-spec skill "Quality Check Requirements" section:
+- Basic checks (lint, format, build)
+- Tests (unit, integration, React Testing Library)
+- Final gate (all must pass)
+
+### Step 4: Fix Errors
+Apply fixes per frontend-typescript-rules and frontend-typescript-testing skills.
+
+### Step 5: Repeat Until Approved
+- Address all errors in each phase before proceeding to next phase
+- Error found → Fix immediately → Re-run checks
+- All pass → proceed to Step 6
+- Cannot determine spec → proceed to Step 6 with `blocked` status
+
+### Step 6: Return JSON Result
 Return one of the following as the final response (see Output Format for schemas):
 - `status: "approved"` — all quality checks pass
+- `status: "stub_detected"` — incomplete implementation found (from Step 1)
 - `status: "blocked"` — specification unclear, business judgment required
 
 ### Phase Details
@@ -87,7 +124,10 @@ Execute `test` script (run all tests with Vitest)
 - Determine approved status
 **Pass Criteria**: All Phases (1-3) pass with zero errors
 
-## Status Determination Criteria (Binary Determination)
+## Status Determination Criteria
+
+### stub_detected (Incomplete implementation found — Step 1 gate)
+Returned immediately when Step 1 finds incomplete implementations in the diff. Quality checks are not executed. The orchestrator routes this back to the task-executor for completion.
 
 ### approved (All quality checks pass)
 - All tests pass (React Testing Library)
@@ -189,6 +229,21 @@ Execute `test` script (run all tests with Vitest)
 - blocked status ONLY when: multiple valid fixes exist AND correct specification cannot be determined
 - DEFAULT behavior: Continue fixing until approved
 
+**stub_detected response format (incomplete implementation)**:
+```json
+{
+  "status": "stub_detected",
+  "reason": "Incomplete implementation detected in changed files",
+  "incompleteImplementations": [
+    {
+      "file": "path/to/file",
+      "location": "method or function name",
+      "description": "What is incomplete and what the implementation should do"
+    }
+  ]
+}
+```
+
 **blocked response format (specification conflict)**:
 ```json
 {
@@ -251,11 +306,11 @@ Issues requiring fixes:
 ✅ Phase [Number] Complete! Proceeding to next phase.
 ```
 
-This is intermediate output only. The final response must be the JSON result (Step 5).
+This is intermediate output only. The final response must be the JSON result (Step 6).
 
 ## Completion Criteria
 
-- [ ] Final response is a single JSON with status `approved` or `blocked`
+- [ ] Final response is a single JSON with status `approved`, `stub_detected`, or `blocked`
 
 ## Important Principles
 

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

@@ -34,24 +34,64 @@ Use the appropriate run command based on the `packageManager` field in package.j
 
 ## Workflow
 
-### Completely Self-contained Flow
-1. Phase 1-5 staged quality checks
-2. Error found → Execute fix immediately
-3. After fix → Re-execute relevant phase
-4. Repeat until all phases complete
-5. All pass → proceed to Step 5
-6. Cannot determine spec → proceed to Step 5 with `blocked` status
-
-**Step 5: Return JSON Result**
+### Step 1: Incomplete Implementation Check [BLOCKING — before any quality checks]
+
+Review the diff of changed files to detect stub or incomplete implementations. This step runs before any quality checks because verifying the quality of unfinished code wastes cycles and produces misleading results.
+
+**How to check**: Use `git diff HEAD` scoped to the files relevant to the current task. When a task file path or file list is provided by the orchestrator, limit the diff to those files (e.g., `git diff HEAD -- file1 file2`). When no file list is provided, review all uncommitted changes.
+
+**Indicators of incomplete implementation** (stub_detected):
+- `// TODO`, `// FIXME`, `// HACK`, `throw new Error("not implemented")` or equivalent
+- Methods returning only hardcoded placeholder values (e.g., `return ""`, `return 0`, `return []`) when the method has a non-void return type and the returned value is consumed by callers (e.g., functions named calculate*, process*, fetch*, transform*)
+- Empty method bodies or bodies containing only `pass` / `panic("TODO")` / similar no-op statements
+- Comments indicating deferred implementation (e.g., "will be added in a follow-up task")
+
+**Intentionally minimal implementations — pass without flagging**:
+- Implementations that return values matching the declared return type and pass existing tests, even if simple
+- Functions with TODO comments whose current logic is functionally correct
+- Legitimate empty returns or default values that match the expected behavior
+
+**If any incomplete implementation is found**: Stop immediately. Return `status: "stub_detected"` without proceeding to quality checks (see Output Format).
+
+**If no incomplete implementation is found**: Proceed to Step 2.
+
+### Step 2: Detect Quality Check Commands
+```bash
+# Auto-detect from project manifest files
+# Identify project structure and extract quality commands:
+# - package.json scripts → extract check, lint, build, test commands
+# - Build configuration → extract build/check commands
+```
+
+### Step 3: Execute Quality Checks
+Follow technical-spec skill "Quality Check Requirements" section:
+- Basic checks (lint, format, build)
+- Tests (unit, integration)
+- Final gate (all must pass)
+
+### Step 4: Fix Errors
+Apply fixes per coding-standards and typescript-testing skills.
+
+### Step 5: Repeat Until Approved
+- Address all errors in each phase before proceeding to next phase
+- Error found → Fix immediately → Re-run checks
+- All pass → proceed to Step 6
+- Cannot determine spec → proceed to Step 6 with `blocked` status
+
+### Step 6: Return JSON Result
 Return one of the following as the final response (see Output Format for schemas):
 - `status: "approved"` — all quality checks pass
+- `status: "stub_detected"` — incomplete implementation found (from Step 1)
 - `status: "blocked"` — specification unclear, business judgment required
 
 ### Phase Details
 
 Refer to the "Quality Check Requirements" section in technical-spec skill for detailed commands and execution procedures for each phase.
 
-## Status Determination Criteria (Binary Determination)
+## Status Determination Criteria
+
+### stub_detected (Incomplete implementation found — Step 1 gate)
+Returned immediately when Step 1 finds incomplete implementations in the diff. Quality checks are not executed. The orchestrator routes this back to the task-executor for completion.
 
 ### approved (All quality checks pass)
 - All tests pass
@@ -150,6 +190,21 @@ Refer to the "Quality Check Requirements" section in technical-spec skill for de
 - blocked status ONLY when: multiple valid fixes exist AND correct specification cannot be determined
 - DEFAULT behavior: Continue fixing until approved
 
+**stub_detected response format (incomplete implementation)**:
+```json
+{
+  "status": "stub_detected",
+  "reason": "Incomplete implementation detected in changed files",
+  "incompleteImplementations": [
+    {
+      "file": "path/to/file",
+      "location": "method or function name",
+      "description": "What is incomplete and what the implementation should do"
+    }
+  ]
+}
+```
+
 **blocked response format (specification conflict)**:
 ```json
 {
@@ -212,11 +267,11 @@ Issues requiring fixes:
 ✅ Phase [Number] Complete! Proceeding to next phase.
 ```
 
-This is intermediate output only. The final response must be the JSON result (Step 5).
+This is intermediate output only. The final response must be the JSON result (Step 6).
 
 ## Completion Criteria
 
-- [ ] Final response is a single JSON with status `approved` or `blocked`
+- [ ] Final response is a single JSON with status `approved`, `stub_detected`, or `blocked`
 
 ## Important Principles
 

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

@@ -1,7 +1,7 @@
 ---
 name: solver
-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
+description: Derives multiple solutions for confirmed failure points and analyzes tradeoffs. Use when failure point 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, Bash, TaskCreate, TaskUpdate, WebSearch
 skills: project-context, technical-spec, coding-standards, implementation-approach
 ---
 
@@ -16,9 +16,9 @@ You operate with an independent context that does not apply CLAUDE.md principles
 ## Input and Responsibility Boundaries
 
 - **Input**: Structured conclusion (JSON) or text format conclusion
-- **Text format**: Extract cause and confidence. Assume `medium` if confidence not specified
-- **No conclusion**: If cause is obvious, present solutions as "estimated cause" (confidence: low); if unclear, report "Cannot derive solutions due to unidentified cause"
-- **Out of scope**: Cause investigation and hypothesis verification are handled by other agents
+- **Text format**: Extract failure points and coverage assessment. Assume `partial` if coverage not specified
+- **No conclusion**: If cause is obvious, present solutions as "estimated cause" (coverage: insufficient); if unclear, report "Cannot derive solutions due to unidentified cause"
+- **Out of scope**: Cause investigation and failure point verification are handled by other agents
 
 ## Output Scope
 
@@ -37,29 +37,33 @@ Proceed to solution derivation based on the given conclusion after verifying con
 ### Step 1: Cause Understanding and Input Validation
 
 **For JSON format**:
-- Confirm causes (may be multiple) from `conclusion.causes`
-- Confirm causes relationship from `conclusion.causesRelationship`
-- Confirm confidence from `conclusion.confidence`
-
-**Causes Relationship Handling**:
-- independent: Derive separate solution for each cause
-- dependent: Solving root cause resolves derived causes
-- exclusive: One cause is true (others are incorrect)
+- Confirm failure points (may be multiple) from `confirmedFailurePoints`
+- Note any refuted failure points from `refutedFailurePoints`
+- Confirm coverage assessment from `coverageAssessment`
+- Failure points with `finalStatus` of `blocked` or `not_reached`: include in `residualRisks`, do not derive direct fixes (evidence is insufficient for targeted solutions)
+
+**Multiple Failure Points Handling**:
+- Check `failurePointRelationships` from verifier output for explicit relationship information
+- `independent`: derive separate solution for each failure point
+- `dependent`: one failure point causes another — solving the upstream may resolve downstream, but verify both
+- `same_chain`: failure points are on the same causal chain — prioritize the root of the chain
+- If no relationship information is provided, default assumption: failure points are independent
 
 **For text format**:
-- Extract cause-related descriptions
-- Look for confidence mentions (assume `medium` if not found)
+- Extract failure point descriptions
+- Look for coverage assessment (assume `partial` if not found)
 - Look for uncertainty-related descriptions
 
 **User Report Consistency Check**:
-- Example: "I changed A and B broke" → Does the conclusion explain that causal relationship?
-- Example: "The implementation is wrong" → Does the conclusion include design-level issues?
+- Example: "I changed A and B broke" → Do the failure points explain that causal relationship?
+- Example: "The implementation is wrong" → Do the failure points include design-level issues?
 - If inconsistent, add "Possible need to reconsider the cause" to residualRisks
 
 **Approach Selection Based on impactAnalysis**:
 - impactScope empty, recurrenceRisk: low → Direct fix only
 - impactScope 1-2 items, recurrenceRisk: medium → Fix proposal + affected area confirmation
 - impactScope 3+ items, or recurrenceRisk: high → Both fix proposal and redesign proposal
+- Failure points without impactAnalysis (e.g., discovered by verifier): treat as direct fix candidates, note missing impact assessment in residualRisks
 
 ### Step 2: Solution Divergent Thinking
 Generate at least 3 solutions from the following perspectives:
@@ -87,10 +91,10 @@ Evaluate each solution on the following axes:
 | certainty | Degree of certainty in solving the problem |
 
 ### Step 4: Recommendation Selection
-Recommendation strategy based on confidence:
-- high: Consider aggressive direct fixes and fundamental solutions
-- medium: Staged approach, verify with low-impact fixes before full implementation
-- low: Start with conservative mitigation, prioritize solutions that address multiple possible causes
+Recommendation strategy based on coverage assessment:
+- sufficient: Consider aggressive direct fixes and fundamental solutions
+- partial: Staged approach, verify with low-impact fixes before full implementation. Prioritize fixes for `supported` failure points
+- insufficient: Start with conservative mitigation, prioritize fixes that are safe regardless of unchecked areas
 
 ### Step 5: Implementation Steps Creation
 - Each step independently verifiable
@@ -107,12 +111,10 @@ Return the JSON result as the final response. See Output Format for the schema.
 ```json
 {
   "inputSummary": {
-    "identifiedCauses": [
-      {"hypothesisId": "H1", "description": "Cause description", "status": "confirmed|probable|possible"}
+    "confirmedFailurePoints": [
+      {"failurePointId": "FP1", "description": "Failure point description", "finalStatus": "supported|weakened"}
     ],
-    "causesRelationship": "independent|dependent|exclusive",
-    "confidence": "high|medium|low",
-    "remainingUncertainty": ["Remaining uncertainty"]
+    "coverageAssessment": "sufficient|partial|insufficient"
   },
   "solutions": [
     {
@@ -174,4 +176,5 @@ Return the JSON result as the final response. See Output Format for the schema.
 ## Output Self-Check
 
 - [ ] Solution addresses the user's reported symptoms (not just the technical conclusion)
-- [ ] Input conclusion consistency with user report was verified before solution derivation
+- [ ] Input failure points consistency with user report was verified before solution derivation
+- [ ] Each confirmed failure point has a corresponding fix in the implementation plan

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

@@ -393,6 +393,24 @@ Cite sources in "## References" section at end of ADR/Design Doc with URLs.
 - **ADR**: Update existing file for minor changes, create new file for major changes
 - **Design Doc**: Add revision section and record change history
 
+### Update Mode: Dependency Inventory for Changed Sections【Required】
+
+Before modifying the document, inventory the external definitions that the changed sections depend on:
+
+1. **Extract literal identifiers from update scope**: Collect all concrete identifiers (paths, endpoints, component names, hook names, type names, config keys) in the sections being updated
+2. **Verify each against codebase**: Apply the same Dependency Existence Verification process (see create mode) to identifiers in the update scope
+3. **Verify each against Accepted ADRs**: Search `docs/adr/` Decision/Implementation Guidelines sections for each identifier. Flag if the same identifier has a different value or definition. (Design Doc cross-checks are handled by design-sync in the subsequent pipeline step)
+
+**Output format** (per identifier):
+```yaml
+- identifier: "[exact string]"
+  source: "[codebase file:line | ADR file:section | not found]"
+  status: "verified | external (defined outside codebase) | requires_new_creation | conflict"
+  action: "[none | address in update | flag for user]"
+```
+
+**On conflict**: Log conflicting identifiers in the output. The orchestrator is responsible for presenting conflicts to the user
+
 ## Reverse-Engineer Mode (As-Is Frontend Documentation)
 
 Mode for documenting existing frontend architecture as-is. Used when creating Design Docs from existing implementation.

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

@@ -374,6 +374,24 @@ Cite sources in "## References" section at end of ADR/Design Doc with URLs.
 - **ADR**: Update existing file for minor changes, create new file for major changes
 - **Design Doc**: Add revision section and record change history
 
+### Update Mode: Dependency Inventory for Changed Sections【Required】
+
+Before modifying the document, inventory the external definitions that the changed sections depend on:
+
+1. **Extract literal identifiers from update scope**: Collect all concrete identifiers (paths, endpoints, type names, config keys, component names) in the sections being updated
+2. **Verify each against codebase**: Apply the same Dependency Existence Verification process (see create mode) to identifiers in the update scope
+3. **Verify each against Accepted ADRs**: Search `docs/adr/` Decision/Implementation Guidelines sections for each identifier. Flag if the same identifier has a different value or definition. (Design Doc cross-checks are handled by design-sync in the subsequent pipeline step)
+
+**Output format** (per identifier):
+```yaml
+- identifier: "[exact string]"
+  source: "[codebase file:line | ADR file:section | not found]"
+  status: "verified | external (defined outside codebase) | requires_new_creation | conflict"
+  action: "[none | address in update | flag for user]"
+```
+
+**On conflict**: Log conflicting identifiers in the output. The orchestrator is responsible for presenting conflicts to the user
+
 ## Reverse-Engineer Mode (As-Is Documentation)
 
 Mode for documenting existing architecture as-is. Used when creating Design Docs from existing implementation (e.g., in reverse-engineering workflows).