Merge pull request #159 from shinpr/fix/code-verifier-review-convergence

Simplify review status convergence

Author: shinpr

.claude-plugin/marketplace.json

@@ -12,7 +12,7 @@
       "name": "dev-workflows",
       "source": "./dev-workflows",
       "strict": true,
-      "version": "0.24.1",
+      "version": "0.24.2",
       "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",
@@ -82,7 +82,7 @@
       "name": "dev-workflows-frontend",
       "source": "./dev-workflows-frontend",
       "strict": true,
-      "version": "0.24.1",
+      "version": "0.24.2",
       "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",
@@ -155,7 +155,7 @@
       "name": "dev-workflows-fullstack",
       "source": "./dev-workflows-fullstack",
       "strict": true,
-      "version": "0.24.1",
+      "version": "0.24.2",
       "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",
@@ -244,7 +244,7 @@
       "name": "dev-skills",
       "source": "./dev-skills",
       "strict": true,
-      "version": "0.24.1",
+      "version": "0.24.2",
       "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/acceptance-test-generator.md

@@ -19,7 +19,7 @@ Operates in an independent context, executing autonomously until task completion
 
 ### Implementation Approach Compliance
 - **Test Code Generation**: MUST strictly comply with Design Doc implementation patterns (function vs class selection)
-- **Contract Safety**: MUST enforce testing-principles skill mock creation and contract definition rules without exception
+- **Contract Safety**: Apply the testing-principles skill mock creation and contract definition rules to every generated skeleton
 
 ## Input Parameters
 
@@ -50,15 +50,15 @@ Test type definitions, budgets, and ROI calculations are specified in **integrat
 | **System Context** | Requires full system integration? | Skip | [UNIT_LEVEL] |
 | **Upstream Scope** | In Include list? | Skip | [OUT_OF_SCOPE] |
 
-**AC Include/Exclude Criteria**:
+**AC Selection Criteria**:
 
 **Include** (High automation ROI):
 - Business logic correctness (calculations, state transitions, data transformations)
 - Data integrity and persistence behavior
 - User-visible functionality completeness
 - Error handling behavior (what user sees/experiences)
 
-**Exclude** (Low ROI in LLM/CI/CD environment):
+**Use alternative verification** (Low ROI in LLM/CI/CD environment):
 - External service real connections → Use contract/interface verification instead
 - Performance metrics → Non-deterministic in CI, defer to load testing
 - Implementation details → Focus on observable behavior
@@ -116,7 +116,7 @@ ROI calculation formula and cost table are defined in **integration-e2e-testing
      - A downstream service receives a real event/message (e.g., topic publish, queue enqueue, webhook call)
      - An external service receives a real API call with the expected payload
      - Transactional consistency across services (e.g., two-phase commit, saga compensation)
-5. **Sort by ROI** within each lane using the score and tie-break order from integration-e2e-testing skill — this is the single ranking step; Phase 4 budget enforcement consumes this ranked list directly without re-sorting.
+5. **Sort by ROI** within each lane using the score and tie-break order from integration-e2e-testing skill — this is the single ranking step, and Phase 4 budget enforcement processes the ranked list in the order produced here.
 
 **Output**: Ranked, deduplicated candidate list with lane assigned per E2E candidate.
 

agents/code-reviewer.md

@@ -71,7 +71,7 @@ When `prior_feedback` is present, complete the correction re-review here:
 
 For each acceptance criterion extracted in Step 1:
 - Search implementation files for the corresponding code
-- Determine status: fulfilled / partially fulfilled / unfulfilled
+- Mark it `fulfilled` only when evidence covers every governing boundary path; otherwise mark it `unfulfilled` and name each uncovered path in `gap`
 - Record the file path and relevant code location
 - Note any deviations from the Design Doc specification
 - 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`
@@ -124,7 +124,7 @@ For each function/method in implementation files, check against coding-principle
 #### 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
-- For each test claimed as AC coverage, inspect the test body and confirm at least one assertion exercises the AC's observable behavior. Tests that are `skip`/`xit`-marked (on tests that should run), contain only TODO/placeholder bodies, or use always-true assertions (e.g., `expect(true).toBe(true)`, `expect(arr.length).toBeGreaterThanOrEqual(0)`) do not count as AC coverage even when grep finds them; record those as `coverage_gap` with rationale explaining the substance issue. Tests verifying intentional absence (e.g., empty list, null result) are substantive when the absence is the AC's expectation.
+- For each test claimed as AC coverage, inspect the test body and count it as coverage only when at least one assertion exercises the AC's observable behavior. Record `skip`/`xit`-marked tests that should run, TODO/placeholder-only bodies, and always-true assertions (e.g., `expect(true).toBe(true)`, `expect(arr.length).toBeGreaterThanOrEqual(0)`) as `coverage_gap` even when grep finds them, with rationale explaining the substance issue. Tests verifying intentional absence (e.g., empty list, null result) are substantive when the absence is the AC's expectation.
 - Beyond substance, confirm each AC test exercises the claimed boundary and would turn red if the promised behavior regressed. When a task file is in scope, verify its Operation Verification Methods and optional Verification Focus. Missing required evidence is a `coverage_gap`.
 
 #### Finding Classification
@@ -185,13 +185,13 @@ Verify against the Design Doc architecture:
 verdict:              string ("pass" | "needs-improvement" | "needs-redesign")
 
 acceptanceCriteria[].item:        string
-acceptanceCriteria[].id:          string (required only when status is not fulfilled; stable within this review chain)
-acceptanceCriteria[].status:      string ("fulfilled" | "partially_fulfilled" | "unfulfilled")
+acceptanceCriteria[].id:          string (required only when status is unfulfilled; stable within this review chain)
+acceptanceCriteria[].status:      string ("fulfilled" | "unfulfilled")
 acceptanceCriteria[].confidence:  string ("high" | "medium" | "low")
 acceptanceCriteria[].location:    string (file:line; null if unimplemented)
 acceptanceCriteria[].evidence:    string[] (each "source: file:line")
-acceptanceCriteria[].gap:         string (null when fully fulfilled)
-acceptanceCriteria[].suggestion:  string (null when fully fulfilled)
+acceptanceCriteria[].gap:         string (null when status is fulfilled)
+acceptanceCriteria[].suggestion:  string (null when status is fulfilled)
 
 identifierVerification[].identifier:    string
 identifierVerification[].id:            string (required only when match is false; stable within this review chain)

agents/code-verifier.md

@@ -54,21 +54,21 @@ Stop expanding the search when additional evidence cannot change a discrepancy o
 - `conflict`: Observed behavior or a governing contract contradicts the document.
 - `unverified`: Available evidence cannot establish the claim; state the exact limitation and effect.
 
-Use `critical` only when the issue makes approved scope incorrect, non-executable, or non-verifiable. Use `major` for a material correction and `minor` for non-blocking precision. Group locations that share one cause and correction into one discrepancy.
+Emit a discrepancy only when leaving it unresolved can change scope, feasibility, implementation, a contract, or verification. Group locations that share one cause and correction into one discrepancy.
 
-Use `unverified` only for a specific material document claim whose unresolved truth can change scope, feasibility, implementation, a contract, or verification; assign it `critical` or `major`. Use `limitations` only for an evidence-access or coverage constraint that does not itself identify a material document claim. Record a fact in one place, not both; a material limitation becomes an `unverified` discrepancy.
+Use `unverified` only for a specific material document claim whose unresolved truth can change scope, feasibility, implementation, a contract, or verification. Use `limitations` only for an evidence-access or coverage constraint that does not itself identify a material document claim. Record a fact in one place, not both; a material limitation becomes an `unverified` discrepancy.
 
 ## Output
 
 Return exactly one JSON object:
 
 ```json
 {
-  "summary": {"docType": "design-doc", "documentPath": "docs/design/example.md", "status": "consistent|mostly_consistent|needs_review|inconsistent|blocked"},
+  "summary": {"docType": "design-doc", "documentPath": "docs/design/example.md", "status": "consistent|needs_review|inconsistent|blocked"},
   "blockingReason": null,
   "inventoryCoverage": null,
   "discrepancies": [
-    {"id": "D001", "status": "drift|gap|conflict|unverified", "severity": "critical|major|minor", "claim": "document claim", "documentLocation": "section or line", "codeLocation": "file:line or null", "relatedLocations": ["other location with the same cause"], "evidence": "observed fact", "effect": "why this changes scope, feasibility, implementation, contract, or verification"}
+    {"id": "D001", "status": "drift|gap|conflict|unverified", "claim": "document claim", "documentLocation": "section or line", "codeLocation": "file:line or null", "relatedLocations": ["other location with the same cause"], "evidence": "observed fact", "effect": "why this changes scope, feasibility, implementation, contract, or verification"}
   ],
   "limitations": ["exact evidence-access or coverage constraint and its verification effect"]
 }
@@ -86,12 +86,11 @@ When `unit_inventory` is supplied, replace `inventoryCoverage: null` with this o
 
 For each inventory category, `accountedCount + excluded.length + unaccounted.length` equals `inputCount`. Report every unaccounted item as one cause-grouped `gap` discrepancy.
 
-An unaccounted inventory item makes `consistent` and `mostly_consistent` invalid; use at least `needs_review`. When the supplied inventory cannot be parsed or the counts cannot be made balanced from it, use `blocked` and state the exact input defect.
+An unaccounted inventory item makes `consistent` invalid; use at least `needs_review`. When the supplied inventory cannot be parsed or the counts cannot be made balanced from it, use `blocked` and state the exact input defect.
 
 Status rules:
 
-- `consistent`: no discrepancy or material limitation exists;
-- `mostly_consistent`: only minor precision issues or non-material coverage limitations remain, and inventory has no unaccounted item;
+- `consistent`: no discrepancy exists;
 - `needs_review`: a repairable material discrepancy, including any `unverified` discrepancy, exists;
 - `inconsistent`: governing evidence contradicts the selected outcome or contract;
 - `blocked`: required input or repository evidence is unusable for the requested verification.

agents/integration-test-reviewer.md

@@ -78,7 +78,7 @@ Evaluate each test for:
 - Clear Arrange section (setup)
 - Single Act (action)
 - Meaningful Assert (verification)
-- Substantive assertion: each test must execute at least one assertion that observes the AC's behavior. Always-true assertions (e.g., `expect(true).toBe(true)`, `expect(arr.length).toBeGreaterThanOrEqual(0)`), TODO-only bodies, or leftover `skip`/`xit` markers on tests that should run do not count as substantive evidence. Tests verifying intentional absence (e.g., `expect(queryAllBy*).toHaveLength(0)`) are substantive when the absence is the AC's expectation
+- Substantive assertion: classify a test as substantive only when it executes at least one assertion that observes the AC's behavior. Classify always-true assertions (e.g., `expect(true).toBe(true)`, `expect(arr.length).toBeGreaterThanOrEqual(0)`), TODO-only bodies, and leftover `skip`/`xit` markers on tests that should run as insufficient evidence. Tests verifying intentional absence (e.g., `expect(queryAllBy*).toHaveLength(0)`) are substantive when the absence is the AC's expectation
 - Isolated state per test (reset in beforeEach)
 - Deterministic execution (mock time/random sources when needed)
 

agents/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: Comprehensively collects problem-related information and creates evidence matrix. Use PROACTIVELY when bug/error/issue/defect/not working/strange behavior is reported. Reports observations and evidence for downstream cause verification.
 tools: Read, Grep, Glob, LS, Bash, WebSearch, TaskCreate, TaskUpdate
 skills:
   - ai-development-guide
@@ -79,7 +79,7 @@ For each node listed in the path map, check whether there is a fault. A node is
 - It contains an inconsistency that can explain the user-reported symptom
 
 If a fault is found, record it as a failure point with the required fields (see Output Format).
-- **Do NOT stop after finding the first fault** — check all remaining nodes on all mapped paths
+- After finding a fault, continue through every remaining node on all mapped paths
 - A single symptom can have multiple failure points at different layers
 
 For each failure point found:
@@ -129,7 +129,7 @@ Disclose unexplored areas and investigation limitations.
     {
       "type": "code|history|dependency|config|document|external",
       "location": "Location investigated",
-      "findings": "Facts discovered (without interpretation)"
+      "findings": "Observed facts"
     }
   ],
   "externalResearch": [

agents/quality-fixer-frontend.md

@@ -52,7 +52,7 @@ Use the indicators below for this review.
 - Functions with TODO comments but 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 any incomplete implementation is found**: Stop at Step 1 and return `status: "stub_detected"` (see Output Format).
 
 **If no incomplete implementation is found**: Proceed to Step 2.
 

agents/quality-fixer.md

@@ -46,7 +46,7 @@ Use the indicators below for this review.
 
 **Legitimate patterns** (treat as complete; proceed to Step 2): intentionally minimal implementations, functions with TODO comments but functionally correct logic, and legitimate empty/default returns 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 any incomplete implementation is found**: Stop at Step 1 and return `status: "stub_detected"` (see Output Format).
 
 **If no incomplete implementation is found**: Proceed to Step 2.
 

agents/scope-discoverer.md

@@ -247,7 +247,7 @@ Includes additional fields:
 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.
 
 - [ ] Output is limited to scope discovery (no PRD or Design Doc content generated)
-- [ ] Every discovery is backed by evidence (no assumptions without sources)
+- [ ] Every discovery cites its source evidence
 - [ ] Low-confidence discoveries are reported with appropriate confidence markers
 - [ ] Triangulation strength reflects actual source count (weak noted when single-source)
 - [ ] Saturation check was performed before concluding discovery