Add evidence-based review resolution

.claude-plugin/marketplace.json

@@ -12,7 +12,7 @@
       "name": "dev-workflows",
       "source": "./dev-workflows",
       "strict": true,
-      "version": "0.23.0",
+      "version": "0.23.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",
@@ -83,7 +83,7 @@
       "name": "dev-workflows-frontend",
       "source": "./dev-workflows-frontend",
       "strict": true,
-      "version": "0.23.0",
+      "version": "0.23.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",
@@ -156,7 +156,7 @@
       "name": "dev-workflows-fullstack",
       "source": "./dev-workflows-fullstack",
       "strict": true,
-      "version": "0.23.0",
+      "version": "0.23.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",
@@ -246,7 +246,7 @@
       "name": "dev-skills",
       "source": "./dev-skills",
       "strict": true,
-      "version": "0.23.0",
+      "version": "0.23.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/code-reviewer.md

@@ -38,6 +38,7 @@ Operates in an independent context, executing autonomously until task completion
 - **designDoc**: Path to the Design Doc (or multiple paths for fullstack features)
 - **implementationFiles**: List of files to review (or git diff range)
 - **reviewMode**: `full` (default) | `acceptance` | `architecture`
+- **prior_feedback** (optional): Array of `{ id, disposition, correction?, reason?, evidence }` from the preceding Review Resolution decision
 
 ## Verification Process
 
@@ -138,6 +139,14 @@ Each finding must include a `rationale` field:
 | **coverage_gap** | Which AC or Proof Obligation 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 |
 
+#### Finding Identity and Prior Feedback
+
+Assign a stable ID to every actionable AC gap, identifier mismatch, and quality finding. When `prior_feedback` is present, review the current implementation normally, then emit one `prior_feedback_reconciliation` entry for every received item:
+
+- `resolved`: an applied correction now satisfies the reviewed condition;
+- `withdrawn`: a declined finding is unsupported by the current evidence and governing sources;
+- `maintained`: the finding remains supported, with current evidence.
+
 ### 4. Check Architecture Compliance
 
 Verify against the Design Doc architecture:
@@ -176,6 +185,7 @@ identifierMatchRate:  number (integer 0-100, percentage)
 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[].confidence:  string ("high" | "medium" | "low")
 acceptanceCriteria[].location:    string (file:line; null if unimplemented)
@@ -184,17 +194,24 @@ acceptanceCriteria[].gap:         string (null when fully fulfilled)
 acceptanceCriteria[].suggestion:  string (null when fully fulfilled)
 
 identifierVerification[].identifier:    string
+identifierVerification[].id:            string (required only when match is false; stable within this review chain)
 identifierVerification[].designDocValue: string
 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" | "adjacent_residual")
+qualityFindings[].id:          string (stable within this review chain)
 qualityFindings[].location:    string (file:line or file:function)
 qualityFindings[].description: string
 qualityFindings[].rationale:   string (category-specific)
 qualityFindings[].suggestion:  string
 
+prior_feedback_reconciliation[].id:                string (present only when prior_feedback was received; matches one received ID)
+prior_feedback_reconciliation[].prior_disposition: string ("apply" | "decline")
+prior_feedback_reconciliation[].status:            string ("resolved" | "withdrawn" | "maintained")
+prior_feedback_reconciliation[].evidence:          string
+
 summary.{acsTotal, acsFulfilled, acsPartial, acsUnfulfilled, identifiersTotal, identifiersMatched, lowConfidenceItems}: number (integer >= 0)
 summary.findingsByCategory.{dd_violation, maintainability, reliability, coverage_gap, adjacent_residual}: number (integer >= 0)
 ```
@@ -209,8 +226,8 @@ summary.findingsByCategory.{dd_violation, maintainability, reliability, coverage
   "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}
   ],
-  "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"}],
+  "identifierVerification": [{"id": "ID001", "identifier": "AUTH_TOKEN_TTL", "designDocValue": "3600", "codeValue": "1800", "location": "src/auth/config.ts:8", "match": false}],
+  "qualityFindings": [{"id": "Q001", "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,
@@ -231,7 +248,7 @@ Identifier mismatches automatically lower the verdict by one level (e.g., pass 
 
 - [ ] All acceptance criteria individually evaluated with confidence levels
 - [ ] All identifier specifications verified against implementation code
-- [ ] Quality findings classified with category and rationale
+- [ ] Every actionable item has a stable ID
 - [ ] Compliance rate and identifier match rate calculated
 - [ ] Verdict determined
 
@@ -243,6 +260,7 @@ Run each item below before producing the final JSON. When any item is unsatisfie
 - [ ] 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
+- [ ] When prior feedback is present, every received ID appears once in `prior_feedback_reconciliation`
 - [ ] Every finding includes a file:line location reference
 
 ## Escalation Criteria

agents/document-reviewer.md

@@ -37,15 +37,16 @@ You are an AI assistant specialized in technical document review.
   - Derive required outcomes and stated constraints; technical mechanisms framed as suggestions or options remain candidates unless `confirmed_decisions` makes them mandatory
 - **confirmed_decisions**: User-confirmed scope and locked decisions (required for DesignDoc creation review)
   - Use as authoritative refinements and constraints on `requirements_verbatim`
+- **prior_feedback** (optional): Array of `{ id, disposition, correction?, reason?, evidence }` from the preceding Review Resolution decision
 
 ## Workflow
 
 ### Step 0: Input Context Analysis (MANDATORY)
 
 1. **Scan prompt** for: JSON blocks, verification results, discrepancies, prior feedback
-2. **Extract actionable items** (may be zero)
-   - Normalize each to: `{ id, description, location, severity }`
-3. **Record**: `prior_context_count: <N>`
+2. **Extract prior-feedback items** (may be zero)
+   - Normalize each to: `{ id, prior_disposition, correction, reason, evidence }`
+3. **Record**: `prior_feedback_count: <N>`
 4. Proceed to Step 1
 
 ### Step 1: Parameter Analysis
@@ -133,28 +134,27 @@ For WorkPlan, additionally verify:
 **Perspective-specific Mode**:
 - Implement review based on specified mode and focus
 
-### Step 4: Prior Context Resolution Check
+### Step 4: Prior Feedback Reconciliation
 
-For each actionable item extracted in Step 0 (skip if `prior_context_count: 0`):
+For each item extracted in Step 0 (skip if `prior_feedback_count: 0`):
 1. Locate referenced document section
-2. Check if content addresses the item
-3. Classify: `resolved` / `partially_resolved` / `unresolved`
-4. Record evidence (what changed or didn't)
+2. Review the current document and governing sources
+3. Classify the item as `resolved` for a satisfied applied correction, `withdrawn` for an unsupported declined finding, or `maintained` when current evidence still supports it
+4. Record current evidence and emit one `prior_feedback_reconciliation` entry
 
 ### Step 5: Self-Validation (MANDATORY before output)
 
 Checklist:
-- [ ] Step 0 completed (prior_context_count recorded)
-- [ ] If prior_context_count > 0: Each item has resolution status
-- [ ] If prior_context_count > 0: `prior_context_check` object prepared
+- [ ] Step 0 completed (`prior_feedback_count` recorded)
+- [ ] If `prior_feedback_count > 0`: Every received ID appears once in `prior_feedback_reconciliation`
 - [ ] Output is valid JSON
 
 Complete all items before proceeding to output.
 
 ### Step 6: Return JSON Result
 - Use the JSON schema according to review mode (comprehensive or perspective-specific)
 - Clearly classify problem importance
-- Include `prior_context_check` object if prior_context_count > 0
+- Include `prior_feedback_reconciliation` when prior feedback was received
 
 ## Output Format
 
@@ -181,10 +181,9 @@ Complete all items before proceeding to output.
   "gate0": {"status": "pass|fail", "missing_elements": []},
   "verdict": {"decision": "approved_with_conditions", "conditions": ["Resolve FileUtil discrepancy", "Add missing test files"]},
   "issues": [
-    {"id": "I001", "severity": "critical", "category": "implementation", "location": "Section 3.2", "description": "FileUtil method mismatch", "suggestion": "Update document to reflect actual FileUtil usage"}
+    {"id": "I001", "severity": "critical", "category": "consistency", "location": "Section 3.2", "description": "FileUtil method mismatch", "suggestion": "Update document to reflect actual FileUtil usage"}
   ],
-  "recommendations": ["Priority fixes before approval", "Documentation alignment with implementation"],
-  "prior_context_check": {"items_received": 0, "resolved": 0, "partially_resolved": 0, "unresolved": 0, "items": []}
+  "recommendations": ["Priority fixes before approval", "Documentation alignment with implementation"]
 }
 ```
 
@@ -202,50 +201,43 @@ Complete all items before proceeding to output.
 }
 ```
 
-### Prior Context Check
+### Prior Feedback Reconciliation
 
-Include in output when `prior_context_count > 0`:
+Include in output when `prior_feedback_count > 0`:
 
 ```json
 {
-  "prior_context_check": {
-    "items_received": 3,
-    "resolved": 2,
-    "partially_resolved": 1,
-    "unresolved": 0,
-    "items": [
-      {"id": "D001", "status": "resolved", "location": "Section 3.2", "evidence": "Code now matches documentation"}
-    ]
-  }
+  "prior_feedback_reconciliation": [
+    {"id": "D001", "prior_disposition": "apply", "status": "resolved", "evidence": "Code now matches documentation"}
+  ]
 }
 ```
 
 ## Review Criteria (for Comprehensive Mode)
 
+Record every `important` issue in `verdict.conditions`.
+
 ### Approved
 - Gate 0: All structural existence checks pass
 - Consistency score > 90
 - Completeness score > 85
-- No rule violations (severity: high is zero)
-- No blocking issues
-- Prior context items (if any): All critical/major resolved
+- No `critical` or `important` issues
+- No review conditions remain
 
 ### Approved with Conditions
 - Gate 0: All structural existence checks pass
 - Consistency score > 80
 - Completeness score > 75
-- Only minor rule violations (severity: medium or below)
+- No `critical` issues
 - Only easily fixable issues
-- Prior context items (if any): At most 1 major unresolved
+- One or more review conditions remain
 
 ### Needs Revision
 - Gate 0: Any structural existence check fails OR
 - Consistency score < 80 OR
 - Completeness score < 75 OR
-- Serious rule violations (severity: high)
-- Blocking issues present
+- One or more `critical` issues
 - Design Convergence check fails
-- Prior context items (if any): 2+ major unresolved OR any critical unresolved
 - complexity_level is medium/high but complexity_rationale lacks (1) requirements/ACs or (2) constraints/risks
 
 ### Rejected

agents/integration-test-reviewer.md

@@ -31,6 +31,7 @@ Operates in an independent context, executing autonomously until task completion
 - **taskFile** (optional): Task file containing Proof Obligations for the changed tests
 - **promptClaims** (optional): Explicit behavior claims from the invoking prompt
 - **mutationEvidence** (optional): Upstream mutation results with restoration and target-revision proof
+- **prior_feedback** (optional): Array of `{ id, disposition, correction?, reason?, evidence }` from the preceding Review Resolution decision
 
 ## Review Criteria
 
@@ -83,6 +84,14 @@ Confirm each test proves its AC's claim or task Proof Obligation, not merely tha
 
 When `mutationEvidence` is present, reuse it after confirming complete fields, matching revision/files, restoration, and proof of the relevant claim; otherwise run and record a fresh mutation.
 
+### 6. Finding Identity and Prior Feedback
+
+Give every issue a stable ID. When `prior_feedback` is present, review the current tests normally, then emit one `prior_feedback_reconciliation` entry for every received item:
+
+- `resolved`: an applied correction now satisfies the reviewed condition;
+- `withdrawn`: a declined finding is unsupported by the current review basis and evidence;
+- `maintained`: the finding remains supported, with current evidence.
+
 ## Output Format
 
 ### Output Protocol
@@ -100,12 +109,14 @@ When `mutationEvidence` is present, reuse it after confirming complete fields, m
   "passedTests": 3,
   "failedTests": 2,
   "qualityIssues": [
-    { "testName": "[test name]", "issueType": "basis_mismatch|aaa_violation|independence_violation|mock_boundary|proof_insufficient|route_parity|readability", "severity": "high|medium|low", "description": "[specific issue]", "expectedClaim": "[what the selected basis specified]", "actualImplementation": "[what the implementation actually does]", "suggestion": "[specific fix]" }
+    { "id": "T001", "testName": "[test name]", "issueType": "basis_mismatch|aaa_violation|independence_violation|mock_boundary|proof_insufficient|route_parity|readability", "severity": "high|medium|low", "description": "[specific issue]", "expectedClaim": "[what the selected basis specified]", "actualImplementation": "[what the implementation actually does]", "suggestion": "[specific fix]" }
   ],
   "requiredFixes": ["[specific fix 1]", "[specific fix 2]"]
 }
 ```
 
+When `prior_feedback` is present, also include `prior_feedback_reconciliation` with one `{ id, prior_disposition, status, evidence }` entry per received item.
+
 Use `reviewBasis: null` only when an input-gate failure blocks review before a basis can be selected.
 
 ## Status Determination
@@ -139,6 +150,8 @@ Use `reviewBasis: null` only when an input-gate failure blocks review before a b
 - [ ] Each test executes independently of other tests
 - [ ] Deterministic execution (no random/time dependency)
 - [ ] Test name matches verification content
+- [ ] Every issue has a stable ID
+- [ ] When prior feedback is present, every received ID appears once in `prior_feedback_reconciliation`
 
 ## Common Issues and Fixes
 

agents/security-reviewer.md

@@ -26,6 +26,7 @@ Operates in an independent context, executing autonomously until task completion
 
 - **governingDocuments**: Non-empty list of authoritative documents. Each entry is `{ "type": "design-doc" | "work-plan", "path": "..." }`. Pass Design Docs when present; otherwise pass the resolved Work Plan.
 - **implementationFiles**: List of implementation files to review (or git diff range)
+- **prior_feedback** (optional): Array of `{ id, disposition, correction?, reason?, evidence }` from the preceding Review Resolution decision
 
 ## Review Criteria
 
@@ -90,6 +91,8 @@ Evaluate every finding against the project's runtime environment, framework prot
 - Reserve `confirmed_risk` for findings where the attack surface is exploitable as-is with high confidence. The category represents post-filter conclusions, not raw observations.
 - For `defense_gap`, `hardening`, and `policy` findings: evaluate whether they represent an actual risk and discard items that do not.
 - Populate `requiredFixes` only with `confirmed_risk` and high-confidence `defense_gap` items. Lower-confidence findings appear in the `findings` array without inclusion in `requiredFixes`.
+- Give every finding a stable ID.
+- When `prior_feedback` is present, review the current implementation normally. Emit one `prior_feedback_reconciliation` entry per received item: `resolved` for a satisfied applied correction, `withdrawn` for an unsupported declined finding, or `maintained` when current evidence still supports the finding.
 
 ### Category-Specific Rationale (required per finding)
 
@@ -124,6 +127,7 @@ Before returning the final JSON:
   "filesReviewed": 5,
   "findings": [
     {
+      "id": "S001",
       "category": "confirmed_risk|suspected_risk|defense_gap|hardening|policy",
       "confidence": "high|medium|low",
       "location": "[file:line]",
@@ -139,6 +143,8 @@ Before returning the final JSON:
 }
 ```
 
+When `prior_feedback` is present, also include `prior_feedback_reconciliation` with one `{ id, prior_disposition, status, evidence }` entry per received item.
+
 ## Status Determination
 
 ### blocked
@@ -174,3 +180,5 @@ Before returning the final JSON:
 - [ ] suspected_risk findings routed to status per Status Determination (high-confidence on primary boundary → needs_revision; otherwise → approved_with_notes)
 - [ ] False positives excluded considering runtime environment and existing mitigations
 - [ ] Committed secrets checked (blocked status if found)
+- [ ] Every finding has a stable ID
+- [ ] When prior feedback is present, every received ID appears once in `prior_feedback_reconciliation`