Fix diagnosis handling of symptom corrections (v0.29.1)

.claude-plugin/marketplace.json

@@ -12,7 +12,7 @@
       "name": "dev-workflows",
       "source": "./dev-workflows",
       "strict": true,
-      "version": "0.29.0",
+      "version": "0.29.1",
       "description": "Skills + Subagents for backend development - Use skills for coding guidance, or run recipe workflows for full orchestrated agentic coding with specialized agents",
       "author": {
         "name": "Shinsuke Kagawa",
@@ -80,7 +80,7 @@
       "name": "dev-workflows-frontend",
       "source": "./dev-workflows-frontend",
       "strict": true,
-      "version": "0.29.0",
+      "version": "0.29.1",
       "description": "Skills + Subagents for React/TypeScript - Use skills for coding guidance, or run recipe workflows for full orchestrated agentic coding with specialized agents",
       "author": {
         "name": "Shinsuke Kagawa",
@@ -149,7 +149,7 @@
       "name": "dev-workflows-fullstack",
       "source": "./dev-workflows-fullstack",
       "strict": true,
-      "version": "0.29.0",
+      "version": "0.29.1",
       "description": "Skills + Subagents for fullstack development (backend + React/TypeScript) - Use skills for coding guidance, or run recipe workflows for full orchestrated agentic coding with specialized agents",
       "author": {
         "name": "Shinsuke Kagawa",
@@ -235,7 +235,7 @@
       "name": "dev-skills",
       "source": "./dev-skills",
       "strict": true,
-      "version": "0.29.0",
+      "version": "0.29.1",
       "description": "Lightweight skills for users with existing workflows - coding best practices, testing principles, and design guidelines without recipe workflows or agents",
       "author": {
         "name": "Shinsuke Kagawa",

agents/investigator.md

@@ -16,7 +16,7 @@ Before acting, map the preloaded skills to concrete rules for this task. Follow
 ## Input and Responsibility Boundaries
 
 - **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
+- **Unclear input**: Distinguish reported facts from interpretations in `problemSummary`. Resolve target-changing uncertainty from available evidence; if unavailable, name the missing fact and its effect in `investigationLimitations` and continue unaffected investigation
 - **With investigationFocus input**: Collect evidence for each focus point and include in failurePoints or factualObservations
 - **With diagnosisScopeEnvelope input**: Investigate broadly within it and account for every item; include a newly discovered area only when it satisfies the supplied envelope's relationships and evidence shows it can change the supported cause set, coverage judgment, or counter-evidence
 - **Without investigationFocus input**: Execute standard investigation flow
@@ -37,7 +37,7 @@ Solution derivation is out of scope for this agent.
   - Determine if the change is a "correct fix" or "new bug" (based on official documentation compliance, consistency with existing working code)
   - Select comparison baseline based on determination
   - Identify shared API/components between cause change and affected area
-- Decompose the phenomenon and organize "since when", "under what conditions", "what scope"
+- Use the current report and corrections to identify observed and expected behavior, location, trigger, conditions, and onset. Preserve unresolved facts in `problemSummary`; select investigation paths from evidence rather than an assumed screen or entrypoint
 - Search for comparison targets (working implementations using the same class/interface)
 
 ### Step 2: Information Collection
@@ -102,7 +102,7 @@ For each failure point:
 
 Disclose unexplored areas and investigation limitations.
 
-Before output, account for every diagnosis-scope item as investigated, excluded by an explicit governing boundary, or unavailable. For unavailable evidence, state whether it could change the supported cause set.
+Before output, account for every diagnosis-scope item as investigated, excluded by an explicit governing boundary, or unavailable. In `scopeAccounting`, reference mapped node IDs and the evidence for their fault checks, including checks that found no fault; reference `failurePoints` for faults already recorded. Nodes may share an entry when the same evidence establishes their result. For unavailable evidence, state whether it could change the supported cause set.
 
 ## Evidence Strength Classification
 

agents/solver.md

@@ -23,7 +23,7 @@ Before acting, map the preloaded skills to concrete rules for this task. Follow
 
 ## Output Scope
 
-This agent outputs **solution derivation and recommendation presentation**. 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.
+This agent outputs **solution derivation and recommendation presentation**. Use the verified cause set to derive remedies for the current symptom and expected behavior in the supplied diagnosis scope envelope, or the available report for direct callers. Cause verification belongs to verifier; return `verification_required` if the supplied evidence exposes a material contradiction or missing prerequisite.
 
 ## Core Responsibilities
 
@@ -52,11 +52,6 @@ This agent outputs **solution derivation and recommendation presentation**. Proc
 - Look for explicit semantic closure
 - Look for uncertainty-related descriptions
 
-**User Report Consistency Check**:
-- 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, return `verification_required` with the exact mismatch and the verification needed to resolve it
-
 **Approach Selection Based on impactAnalysis**:
 - Impact confined to one responsibility → Direct fix is sufficient unless another verified cause requires a broader mechanism
 - The same defect affects adjacent cases under one existing owner or contract → Compare direct correction with the smallest coordinated affected-area correction
@@ -99,7 +94,7 @@ Select from the materially distinct approaches only after the verified `closed`
 ### Step 5: Implementation Steps Creation
 - Each step independently verifiable
 - Explicitly state dependencies between steps
-- Define completion conditions for each step
+- Define completion conditions for each step and the observable check that the original symptom is resolved under its reported trigger and conditions, preserving the expected behavior
 - Include rollback procedures
 
 ## Output Format
@@ -169,12 +164,11 @@ The first criterion applies to both statuses. All later criteria and Self-Valida
 - [ ] Created concrete implementation steps
 - [ ] Documented residual risks
 - [ ] Verified solutions align with project rules or best practices
-- [ ] Verified input consistency with user report
+- [ ] Proposed remedy and its verification address the current symptom and expected behavior
 
 ## Self-Validation [BLOCKING — before output]
 
 Run each item below before producing the final JSON. When any item is unsatisfied, return to the relevant Step and complete it before producing the JSON output.
 
 - [ ] Solution addresses the user's reported symptoms (not just the technical conclusion)
-- [ ] Input failure points consistency with user report was verified before solution derivation
 - [ ] Each confirmed failure point has a corresponding fix in the implementation plan

agents/verifier.md

@@ -16,7 +16,7 @@ Before acting, map the preloaded skills to concrete rules for this task. Follow
 ## Input and Responsibility Boundaries
 
 - **Input**: Structured investigation results (JSON) or text format investigation results
-- **Diagnosis scope envelope**: When supplied, use its recorded relationships as the semantic coverage boundary and verify every item within it is accounted for
+- **Diagnosis scope envelope**: When supplied, use its current report and corrections as the symptom source independently of the investigator's interpretation, and its relationships as the semantic coverage boundary
 - **Text format**: Extract failure points and evidence for internal structuring. Verify within extractable scope
 - **No investigation results**: Mark as "No prior investigation" and attempt verification within input information scope
 - **Out of scope**: From-scratch information collection and solution proposals
@@ -61,7 +61,7 @@ Record each supplementary finding with its impact on existing failure points.
 Check the upstream investigation's pathMap for completeness:
 
 1. **Missing paths**: Are there code paths the symptom could traverse that the upstream investigation did not trace? (e.g., error handling branches, async forks, fallback paths)
-2. **Unchecked nodes**: Are there nodes on traced paths that were not checked for faults?
+2. **Unchecked nodes**: Do `scopeAccounting` and `failurePoints` provide evidence for the mapped nodes' fault checks, including no-fault judgments? Identify checks whose evidence is absent or invalid for the current symptom
 3. **Adjacent cases**: When the investigation concerns a `bug-fix`, `regression`, `state-change`, or `boundary-change` (the debugging flow carries no Change Category field, so judge these from the investigation itself), are there cases sharing the same path, contract, persisted state, or external boundary that could carry the same fault? Trace all plausible adjacent cases, or explicitly justify any left untraced
 4. **Additional failure points**: If missing paths, unchecked nodes, or adjacent cases reveal new faults, record them
 
@@ -90,10 +90,7 @@ Evaluate every failure point independently and allow multiple confirmed failure
 | blocked | Cannot verify due to missing information (e.g., no runtime access) |
 | not_reached | Node exists on the path but could not be investigated |
 
-**User Report Consistency**: Verify that the confirmed failure points are consistent with the user's report
-- Example: "I changed A and B broke" → Do the failure points explain that causal relationship?
-- Example: "The implementation is wrong" → Was design_gap considered?
-- If inconsistent, explicitly note "Investigation focus may be misaligned with user report"
+**User Report Consistency**: Verify that the supported failure points together explain the current reported symptom, including its location, expected behavior, trigger, and conditions. Compare against the scope envelope's report and corrections when supplied; otherwise use the available report and identify material missing context. Record unexplained symptoms in `unresolvedSymptoms` and target mismatches in `identifiedGaps`. A material mismatch requires `gaps_remaining` with the exact re-investigation target, or `evidence_unavailable` when no available action can resolve it.
 
 **Conclusion**: Evaluate each failure point individually and retain every supported cause. For each pair of confirmed failure points, determine their relationship (independent / dependent / same_chain) and record it in `failurePointRelationships`
 
@@ -107,7 +104,7 @@ Evaluate every failure point independently and allow multiple confirmed failure
 
 Set `coverageDisposition` independently:
 
-- `closed`: the sufficient criteria hold.
+- `closed`: the sufficient criteria hold and the supported cause set explains the current reported symptom without a material unresolved mismatch.
 - `gaps_remaining`: an accessible named gap could materially change the cause set; identify the precise next investigation target.
 - `evidence_unavailable`: unavailable evidence could materially change the cause set and no available investigation action can close it; identify the unavailable evidence and attempted recovery.
 

dev-skills/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "dev-skills",
   "description": "Lightweight skills for users with existing workflows - coding best practices, testing principles, and design guidelines without recipe workflows or agents",
-  "version": "0.29.0",
+  "version": "0.29.1",
   "author": {
     "name": "Shinsuke Kagawa",
     "url": "https://github.com/shinpr"

dev-workflows-frontend/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "dev-workflows-frontend",
   "description": "Skills + Subagents for React/TypeScript - Use skills for coding guidance, or run recipe workflows for full orchestrated agentic coding with specialized agents",
-  "version": "0.29.0",
+  "version": "0.29.1",
   "author": {
     "name": "Shinsuke Kagawa",
     "url": "https://github.com/shinpr"

dev-workflows-frontend/agents/investigator.md

@@ -16,7 +16,7 @@ Before acting, map the preloaded skills to concrete rules for this task. Follow
 ## Input and Responsibility Boundaries
 
 - **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
+- **Unclear input**: Distinguish reported facts from interpretations in `problemSummary`. Resolve target-changing uncertainty from available evidence; if unavailable, name the missing fact and its effect in `investigationLimitations` and continue unaffected investigation
 - **With investigationFocus input**: Collect evidence for each focus point and include in failurePoints or factualObservations
 - **With diagnosisScopeEnvelope input**: Investigate broadly within it and account for every item; include a newly discovered area only when it satisfies the supplied envelope's relationships and evidence shows it can change the supported cause set, coverage judgment, or counter-evidence
 - **Without investigationFocus input**: Execute standard investigation flow
@@ -37,7 +37,7 @@ Solution derivation is out of scope for this agent.
   - Determine if the change is a "correct fix" or "new bug" (based on official documentation compliance, consistency with existing working code)
   - Select comparison baseline based on determination
   - Identify shared API/components between cause change and affected area
-- Decompose the phenomenon and organize "since when", "under what conditions", "what scope"
+- Use the current report and corrections to identify observed and expected behavior, location, trigger, conditions, and onset. Preserve unresolved facts in `problemSummary`; select investigation paths from evidence rather than an assumed screen or entrypoint
 - Search for comparison targets (working implementations using the same class/interface)
 
 ### Step 2: Information Collection
@@ -102,7 +102,7 @@ For each failure point:
 
 Disclose unexplored areas and investigation limitations.
 
-Before output, account for every diagnosis-scope item as investigated, excluded by an explicit governing boundary, or unavailable. For unavailable evidence, state whether it could change the supported cause set.
+Before output, account for every diagnosis-scope item as investigated, excluded by an explicit governing boundary, or unavailable. In `scopeAccounting`, reference mapped node IDs and the evidence for their fault checks, including checks that found no fault; reference `failurePoints` for faults already recorded. Nodes may share an entry when the same evidence establishes their result. For unavailable evidence, state whether it could change the supported cause set.
 
 ## Evidence Strength Classification
 

dev-workflows-frontend/agents/solver.md

@@ -23,7 +23,7 @@ Before acting, map the preloaded skills to concrete rules for this task. Follow
 
 ## Output Scope
 
-This agent outputs **solution derivation and recommendation presentation**. 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.
+This agent outputs **solution derivation and recommendation presentation**. Use the verified cause set to derive remedies for the current symptom and expected behavior in the supplied diagnosis scope envelope, or the available report for direct callers. Cause verification belongs to verifier; return `verification_required` if the supplied evidence exposes a material contradiction or missing prerequisite.
 
 ## Core Responsibilities
 
@@ -52,11 +52,6 @@ This agent outputs **solution derivation and recommendation presentation**. Proc
 - Look for explicit semantic closure
 - Look for uncertainty-related descriptions
 
-**User Report Consistency Check**:
-- 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, return `verification_required` with the exact mismatch and the verification needed to resolve it
-
 **Approach Selection Based on impactAnalysis**:
 - Impact confined to one responsibility → Direct fix is sufficient unless another verified cause requires a broader mechanism
 - The same defect affects adjacent cases under one existing owner or contract → Compare direct correction with the smallest coordinated affected-area correction
@@ -99,7 +94,7 @@ Select from the materially distinct approaches only after the verified `closed`
 ### Step 5: Implementation Steps Creation
 - Each step independently verifiable
 - Explicitly state dependencies between steps
-- Define completion conditions for each step
+- Define completion conditions for each step and the observable check that the original symptom is resolved under its reported trigger and conditions, preserving the expected behavior
 - Include rollback procedures
 
 ## Output Format
@@ -169,12 +164,11 @@ The first criterion applies to both statuses. All later criteria and Self-Valida
 - [ ] Created concrete implementation steps
 - [ ] Documented residual risks
 - [ ] Verified solutions align with project rules or best practices
-- [ ] Verified input consistency with user report
+- [ ] Proposed remedy and its verification address the current symptom and expected behavior
 
 ## Self-Validation [BLOCKING — before output]
 
 Run each item below before producing the final JSON. When any item is unsatisfied, return to the relevant Step and complete it before producing the JSON output.
 
 - [ ] Solution addresses the user's reported symptoms (not just the technical conclusion)
-- [ ] Input failure points consistency with user report was verified before solution derivation
 - [ ] Each confirmed failure point has a corresponding fix in the implementation plan