Merge pull request #163 from shinpr/refactor/remove-review-change-set

Refine review scope contracts and remove unsupported defaults

Author: shinpr

.claude-plugin/marketplace.json

@@ -12,7 +12,7 @@
       "name": "dev-workflows",
       "source": "./dev-workflows",
       "strict": true,
-      "version": "0.24.5",
+      "version": "0.24.6",
       "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.5",
+      "version": "0.24.6",
       "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.5",
+      "version": "0.24.6",
       "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.5",
+      "version": "0.24.6",
       "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

@@ -35,7 +35,7 @@ Operates in an independent context, executing autonomously until task completion
 ## Input Parameters
 
 - **designDoc**: Path to the Design Doc (or multiple paths for fullstack features)
-- **implementationFiles**: Complete list of files in the review change set
+- **implementationFiles**: Complete list of artifacts whose contents implement or verify reviewed behavior or control its schema, build, deployment, or runtime behavior
 - **reviewMode**: `full` (default) | `acceptance` | `architecture`
 - **prior_feedback** (optional): Array of `{ id, disposition, reason?, evidence }` from the preceding Review Resolution decision
 
@@ -77,7 +77,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 diff is a bug fix, regression fix, state change, or boundary change, check cases sharing its path, contract, persisted state, or external boundary. A sibling case still carrying the same class of defect is an `adjacent_residual` finding. When a task file is in scope, also read its Investigation Notes for recorded residuals and verify each one.
+- When the reviewed diff is a bug fix, regression fix, state change, or boundary change, check cases sharing its path, contract, persisted state, or external boundary. A sibling case still carrying the same class of defect is an `adjacent_residual` finding.
 
 #### 2-2. Identifier Verification
 
@@ -125,7 +125,7 @@ For each function/method in implementation files, check against coding-principle
 - 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 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`.
+- Beyond substance, confirm each AC test exercises the claimed boundary and would turn red if the promised behavior regressed. Missing required boundary evidence is a `coverage_gap`.
 
 #### Finding Classification
 

agents/code-verifier.md

@@ -20,13 +20,12 @@ Your discrepancies are independent evidence for orchestrator Review Resolution.
 
 - **doc_type**: `prd`, `design-doc`, or `work-plan`
 - **document_path**: Exact readable document path
-- **code_paths**: Optional explicit implementation paths, or a starting scope for reverse-engineering when `unit_inventory` is supplied
 - **unit_inventory**: Optional reverse-engineering baseline with `routes`, `testFiles`, and `publicExports`
 - **verbose**: Optional evidence detail
 
 Return `summary.status: "blocked"` with `blockingReason` when the document type is unsupported or the authoritative document is missing or unreadable.
 
-Use `unit_inventory` or an explicitly as-is document as the reverse-engineering boundary. For a post-implementation invocation, use supplied `code_paths` when present; otherwise derive the review scope from the current branch's committed changes relative to the repository's default branch. Verify the governing document's implemented behavior in that scope. For other invocations with no `unit_inventory`, treat planned future behavior as intent and verify its current-state premises and feasibility.
+Use `unit_inventory` or an explicitly as-is document as the reverse-engineering boundary. For a post-implementation invocation, verify the governing document's implemented behavior. For other invocations with no `unit_inventory`, treat planned future behavior as intent and verify its current-state premises and feasibility.
 
 ## Verification Boundary
 

agents/security-reviewer.md

@@ -25,11 +25,9 @@ Operates in an independent context, executing autonomously until task completion
 ## Input Parameters
 
 - **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**: Optional explicit implementation files for the review
+- **implementationFiles**: Optional complete list of artifacts whose contents implement or verify reviewed behavior or control its schema, build, deployment, or runtime behavior
 - **prior_feedback** (optional): Array of `{ id, disposition, reason?, evidence }` from the preceding Review Resolution decision
 
-For a post-implementation invocation, use supplied `implementationFiles` when present; otherwise derive the review scope from the current branch's committed changes relative to the repository's default branch.
-
 ## Review Criteria
 
 Review criteria are defined in **coding-principles skill** (Security Principles section) and **references/security-checks.md** (detection patterns).

agents/solver.md

@@ -46,7 +46,6 @@ This agent outputs **solution derivation and recommendation presentation**. Proc
 - `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 failure point descriptions

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.24.5",
+  "version": "0.24.6",
   "author": {
     "name": "Shinsuke Kagawa",
     "url": "https://github.com/shinpr"

dev-skills/skills/documentation-criteria/references/prd-template.md

@@ -85,7 +85,7 @@ C4Context
 - [Considerations for future scaling]
 
 ### Accessibility (when feature includes UI)
-- Compliance standard: [Use the organization standard when defined; otherwise default to WCAG 2.2 AA]
+- Compliance standard (when established by an accepted organizational, legal, contractual, or confirmed product source): [standard]
 - Target assistive technologies: [Screen reader, keyboard operation, voice control, etc.]
 - Platform requirements: [e.g., app store review requirements]
 - Known constraints: [e.g., external library limitations]

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.24.5",
+  "version": "0.24.6",
   "author": {
     "name": "Shinsuke Kagawa",
     "url": "https://github.com/shinpr"

dev-workflows-frontend/agents/code-reviewer.md

@@ -35,7 +35,7 @@ Operates in an independent context, executing autonomously until task completion
 ## Input Parameters
 
 - **designDoc**: Path to the Design Doc (or multiple paths for fullstack features)
-- **implementationFiles**: Complete list of files in the review change set
+- **implementationFiles**: Complete list of artifacts whose contents implement or verify reviewed behavior or control its schema, build, deployment, or runtime behavior
 - **reviewMode**: `full` (default) | `acceptance` | `architecture`
 - **prior_feedback** (optional): Array of `{ id, disposition, reason?, evidence }` from the preceding Review Resolution decision
 
@@ -77,7 +77,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 diff is a bug fix, regression fix, state change, or boundary change, check cases sharing its path, contract, persisted state, or external boundary. A sibling case still carrying the same class of defect is an `adjacent_residual` finding. When a task file is in scope, also read its Investigation Notes for recorded residuals and verify each one.
+- When the reviewed diff is a bug fix, regression fix, state change, or boundary change, check cases sharing its path, contract, persisted state, or external boundary. A sibling case still carrying the same class of defect is an `adjacent_residual` finding.
 
 #### 2-2. Identifier Verification
 
@@ -125,7 +125,7 @@ For each function/method in implementation files, check against coding-principle
 - 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 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`.
+- Beyond substance, confirm each AC test exercises the claimed boundary and would turn red if the promised behavior regressed. Missing required boundary evidence is a `coverage_gap`.
 
 #### Finding Classification
 

dev-workflows-frontend/agents/code-verifier.md

@@ -20,13 +20,12 @@ Your discrepancies are independent evidence for orchestrator Review Resolution.
 
 - **doc_type**: `prd`, `design-doc`, or `work-plan`
 - **document_path**: Exact readable document path
-- **code_paths**: Optional explicit implementation paths, or a starting scope for reverse-engineering when `unit_inventory` is supplied
 - **unit_inventory**: Optional reverse-engineering baseline with `routes`, `testFiles`, and `publicExports`
 - **verbose**: Optional evidence detail
 
 Return `summary.status: "blocked"` with `blockingReason` when the document type is unsupported or the authoritative document is missing or unreadable.
 
-Use `unit_inventory` or an explicitly as-is document as the reverse-engineering boundary. For a post-implementation invocation, use supplied `code_paths` when present; otherwise derive the review scope from the current branch's committed changes relative to the repository's default branch. Verify the governing document's implemented behavior in that scope. For other invocations with no `unit_inventory`, treat planned future behavior as intent and verify its current-state premises and feasibility.
+Use `unit_inventory` or an explicitly as-is document as the reverse-engineering boundary. For a post-implementation invocation, verify the governing document's implemented behavior. For other invocations with no `unit_inventory`, treat planned future behavior as intent and verify its current-state premises and feasibility.
 
 ## Verification Boundary