Adjacent-case sweep, frontend skill modernization, and coverage reframe (0.20.5)

.claude-plugin/marketplace.json

@@ -12,7 +12,7 @@
       "name": "dev-workflows",
       "source": "./dev-workflows",
       "strict": true,
-      "version": "0.20.4",
+      "version": "0.20.5",
       "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",
@@ -81,7 +81,7 @@
       "name": "dev-workflows-frontend",
       "source": "./dev-workflows-frontend",
       "strict": true,
-      "version": "0.20.4",
+      "version": "0.20.5",
       "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",
@@ -152,7 +152,7 @@
       "name": "dev-workflows-fullstack",
       "source": "./dev-workflows-fullstack",
       "strict": true,
-      "version": "0.20.4",
+      "version": "0.20.5",
       "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",
@@ -240,7 +240,7 @@
       "name": "dev-skills",
       "source": "./dev-skills",
       "strict": true,
-      "version": "0.20.4",
+      "version": "0.20.5",
       "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/code-reviewer.md

@@ -60,6 +60,7 @@ For each acceptance criterion extracted in Step 1:
 - For behavior-changing ACs, confirm the evidence covers the boundary paths, not only the main path: where a distinct branch, state, input class, lifecycle step, or fallback governs the behavior, verify it is exercised. Compare the source/referenced behavior and the implemented behavior at the same granularity; an unsupported change in a boundary dimension is a `dd_violation`
 - Confirm the implementation keeps the core mechanism the AC, Design Doc, or referenced materials require. A simpler substitute that passes tests but drops the required mechanism is a `dd_violation`
 - For changes to persisted, shared, or externally observable state, identify the publication boundary (where the new state becomes observable to another process, component, user, or later step). State that is observable as complete while still partial, uninitialized, stale, or rollback-only is a `reliability` finding, because a downstream consumer can treat the incomplete state as complete and fail
+- When the reviewed change is classified as `bug-fix`, `regression`, `state-change`, or `boundary-change` (the task's `Change Category` field, when present, names the kind), check the cases sharing its path, contract, persisted state, or external boundary. A sibling case still carrying the same class of defect the change addressed is an `adjacent_residual` finding
 
 #### 2-2. Identifier Verification
 
@@ -112,6 +113,7 @@ Classify each quality finding into one of:
 | **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 |
+| **adjacent_residual** | A case sharing the change's path, contract, persisted state, or external boundary still carries the class of defect the change addressed | Fallback path left unfixed, sibling state transition still stale, another consumer of a changed contract not updated |
 
 Each finding must include a `rationale` field:
 
@@ -121,6 +123,7 @@ Each finding must include a `rationale` field:
 | **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 |
+| **adjacent_residual** | Which adjacent case shares the path/contract/state/boundary and how it still exhibits the defect class |
 
 ### 4. Check Architecture Compliance
 
@@ -173,14 +176,14 @@ identifierVerification[].codeValue:     string (or "not found")
 identifierVerification[].location:      string (file:line; null if not found)
 identifierVerification[].match:         boolean
 
-qualityFindings[].category:    string ("dd_violation" | "maintainability" | "reliability" | "coverage_gap")
+qualityFindings[].category:    string ("dd_violation" | "maintainability" | "reliability" | "coverage_gap" | "adjacent_residual")
 qualityFindings[].location:    string (file:line or file:function)
 qualityFindings[].description: string
 qualityFindings[].rationale:   string (category-specific)
 qualityFindings[].suggestion:  string
 
 summary.{acsTotal, acsFulfilled, acsPartial, acsUnfulfilled, identifiersTotal, identifiersMatched, lowConfidenceItems}: number (integer >= 0)
-summary.findingsByCategory.{dd_violation, maintainability, reliability, coverage_gap}: number (integer >= 0)
+summary.findingsByCategory.{dd_violation, maintainability, reliability, coverage_gap, adjacent_residual}: number (integer >= 0)
 ```
 
 ### Minimal Shape Example
@@ -191,22 +194,14 @@ summary.findingsByCategory.{dd_violation, maintainability, reliability, coverage
   "identifierMatchRate": 95,
   "verdict": "needs-improvement",
   "acceptanceCriteria": [
-    {
-      "item": "User can log in with valid credentials",
-      "status": "fulfilled",
-      "confidence": "high",
-      "location": "src/auth/login.ts:42",
-      "evidence": ["impl: src/auth/login.ts:42", "test: src/auth/login.test.ts:18"],
-      "gap": null,
-      "suggestion": null
-    }
+    {"item": "User can log in with valid credentials", "status": "fulfilled", "confidence": "high", "location": "src/auth/login.ts:42", "evidence": ["impl: src/auth/login.ts:42", "test: src/auth/login.test.ts:18"], "gap": null, "suggestion": null}
   ],
   "identifierVerification": [{"identifier": "AUTH_TOKEN_TTL", "designDocValue": "3600", "codeValue": "1800", "location": "src/auth/config.ts:8", "match": false}],
   "qualityFindings": [{"category": "reliability", "location": "src/auth/login.ts:55", "description": "Error from token signer is swallowed silently", "rationale": "When jwt.sign throws, the catch block returns null without logging", "suggestion": "Re-throw with context or log then propagate"}],
   "summary": {
     "acsTotal": 12, "acsFulfilled": 10, "acsPartial": 1, "acsUnfulfilled": 1,
     "identifiersTotal": 20, "identifiersMatched": 19, "lowConfidenceItems": 2,
-    "findingsByCategory": { "dd_violation": 1, "maintainability": 0, "reliability": 1, "coverage_gap": 0 }
+    "findingsByCategory": { "dd_violation": 1, "maintainability": 0, "reliability": 1, "coverage_gap": 0, "adjacent_residual": 0 }
   }
 }
 ```

agents/quality-fixer-frontend.md

@@ -102,7 +102,7 @@ Return one of the following as the final response (see Output Format for schemas
 Prefer repository-local component patterns over generic React advice; when patterns coexist for the same concern, follow the dominant one in the changed feature area — the surrounding feature folder, or the nearest parent directory containing siblings using the same concern. Route any new library/pattern decision through the `blocked` output (`reason: "Cannot determine due to unclear specification"`).
 
 ### Testing Quality
-- **Test Coverage**: 60% baseline; foundational/leaf components (Atomic Design atoms, or reused-across-features components) target 70%, molecules 65%, organisms 60%
+- **Test Coverage**: concentrate rigor on foundational/high-reuse units (shared components, hooks, utils); treat coverage as a signal for gaps, not a target. Enforce the project's configured threshold when one exists
 - **Mock layering**: Use the repository's existing network/API mocking layer for network behavior; browser-primitive doubles (e.g., ResizeObserver, IntersectionObserver, time, router/provider) are acceptable when the test environment requires them; the component under test is exercised through real renders and user interactions
 - **Query selection**: Prefer role/name queries for user-visible elements; use async queries (`findBy*`, `waitFor`) for async appearance and `queryBy*`/`queryAllBy*` only when asserting intentional absence
 

agents/solver.md

@@ -71,6 +71,10 @@ Generate at least 3 solutions from the following perspectives:
 | mitigation | Measures to reduce impact | Temporary measure while waiting for root fix |
 | fundamental | Comprehensive fix including recurrence prevention | When similar problems have occurred repeatedly |
 
+**Adjacent Case Coverage**:
+- When the confirmed failure point concerns a `bug-fix`, `regression`, `state-change`, or `boundary-change` (the debugging flow carries no Change Category field, so judge these from the failure point itself), evaluate whether cases sharing the same path, contract, persisted state, or external boundary need the same fix
+- Include those adjacent cases in the solution scope when they share the same class of defect; record in residualRisks why any are excluded
+
 **Generated Solution Verification**:
 - Check if project rules have applicable guidelines
 - For areas without guidelines, research current best practices via WebSearch to verify solutions align with standard approaches
@@ -116,24 +120,12 @@ Recommendation strategy based on coverage assessment:
   },
   "solutions": [
     {
-      "id": "S1",
-      "name": "Solution name",
-      "type": "direct|workaround|mitigation|fundamental",
-      "description": "Detailed solution description",
-      "implementation": {
-        "approach": "Implementation approach description",
-        "affectedFiles": ["Files requiring changes"],
-        "dependencies": ["Affected dependencies"]
-      },
+      "id": "S1", "name": "Solution name", "type": "direct|workaround|mitigation|fundamental", "description": "Detailed solution description",
+      "implementation": {"approach": "Implementation approach description", "affectedFiles": ["Files requiring changes"], "dependencies": ["Affected dependencies"]},
       "tradeoffs": {
-        "cost": {"level": "low|medium|high", "details": "Details"},
-        "risk": {"level": "low|medium|high", "details": "Details"},
-        "scope": {"level": "low|medium|high", "details": "Details"},
-        "maintainability": {"level": "low|medium|high", "details": "Details"},
-        "certainty": {"level": "low|medium|high", "details": "Details"}
+        "cost": {"level": "low|medium|high", "details": "Details"}, "risk": {"level": "low|medium|high", "details": "Details"}, "scope": {"level": "low|medium|high", "details": "Details"}, "maintainability": {"level": "low|medium|high", "details": "Details"}, "certainty": {"level": "low|medium|high", "details": "Details"}
       },
-      "pros": ["Advantages"],
-      "cons": ["Disadvantages"]
+      "pros": ["Advantages"], "cons": ["Disadvantages"]
     }
   ],
   "recommendation": {
@@ -144,12 +136,7 @@ Recommendation strategy based on coverage assessment:
   },
   "implementationPlan": {
     "steps": [
-      {
-        "order": 1,
-        "action": "Specific action",
-        "verification": "How to verify this step",
-        "rollback": "Rollback procedure if problems occur"
-      }
+      {"order": 1, "action": "Specific action", "verification": "How to verify this step", "rollback": "Rollback procedure if problems occur"}
     ],
     "criticalPoints": ["Points requiring special attention"]
   },

agents/task-decomposer.md

@@ -92,6 +92,7 @@ Decompose tasks based on implementation strategy patterns determined in implemen
    - Task overview
    - Target files
    - **Investigation Targets** (what the executor must read and understand before implementing)
+   - **Change Category** (when the task is a bug fix / regression / state-change / boundary-change — see Change Category Classification below)
    - Concrete implementation steps
    - **Quality Assurance Mechanisms** (derived from work plan header — see Quality Assurance Mechanism Propagation below)
    - **Operation Verification Methods** (derived from Verification Strategy in work plan)
@@ -213,6 +214,21 @@ When the work plan contains a Design-to-Plan Traceability table, propagate the m
 2. Deduplicate when the same (Design Doc, DD Section) pair appears in multiple rows for one task
 3. Apply only when the work plan contains a Design-to-Plan Traceability table
 
+## Change Category Classification
+
+When a task corrects observed behavior or alters how state or a boundary behaves, classify it so the executor and downstream reviewers run a scoped adjacent-case sweep from the field value, rather than re-inferring the task's intent:
+
+1. **Classify from the work plan and Design Doc**. A task can match more than one category (e.g., a regression fix that changes a persisted-state boundary); record every value that applies:
+   - `bug-fix`: corrects observed incorrect behavior
+   - `regression`: restores behavior a prior change broke
+   - `state-change`: alters how state is written, transitioned, or persisted
+   - `boundary-change`: changes a published or consumed contract at an external, cross-package, or persisted boundary
+2. **Populate the task's `Change Category` field** with all matched values, comma-separated (see task template).
+3. **Extend Investigation Targets with the adjacent cases**. For every matched category, add the files sharing the same path, contract, persisted state, or external boundary as the change — including the owner module on both sides of an affected boundary — so the executor can sweep them for the same class of defect. Union the targets across all matched categories.
+4. **Apply only on a match**. Purely additive, config, or scaffolding tasks default to no `Change Category` field and skip this propagation.
+
+This is distinct from per-AC boundary-path proof (which proves a boundary path *within* an AC): Change Category drives a sweep of cases that sit *outside* the task's ACs but share its path, contract, state, or boundary.
+
 ## Task File Template
 
 See task template in documentation-criteria skill for details.
@@ -312,6 +328,7 @@ Please execute decomposed tasks according to the order.
 - [ ] Appropriate granularity (1-5 files/task)
 - [ ] Investigation Targets specified for every task (specific file paths, not vague categories)
 - [ ] Proof Obligations recorded for each claim-implementing task (primary failure mode + boundary to exercise)
+- [ ] Change Category set for bug-fix / regression / state-change / boundary-change tasks, with adjacent path/boundary owners added to Investigation Targets
 - [ ] Quality Assurance Mechanisms from work plan header propagated to relevant tasks
 - [ ] UI Spec Component → Task Mapping rows propagated to matching tasks (when work plan has the table)
 - [ ] Connection Map boundary rows propagated to matching tasks (when work plan has the table)