fix: align workflow verification and release v0.25.3

.claude-plugin/marketplace.json

@@ -12,7 +12,7 @@
       "name": "dev-workflows",
       "source": "./dev-workflows",
       "strict": true,
-      "version": "0.25.2",
+      "version": "0.25.3",
       "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.25.2",
+      "version": "0.25.3",
       "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",
@@ -157,7 +157,7 @@
       "name": "dev-workflows-fullstack",
       "source": "./dev-workflows-fullstack",
       "strict": true,
-      "version": "0.25.2",
+      "version": "0.25.3",
       "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",
@@ -247,7 +247,7 @@
       "name": "dev-skills",
       "source": "./dev-skills",
       "strict": true,
-      "version": "0.25.2",
+      "version": "0.25.3",
       "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

@@ -46,12 +46,11 @@ Test type definitions, budgets, and ROI calculations are specified in **integrat
 | **If-then** | Branch coverage test | Condition true/false → verify both paths |
 | (none) | Basic functionality test | Direct invocation → verify result |
 
-**For each AC, apply 3 mandatory checks**:
+**For each AC, apply these mandatory checks**:
 
 | Check | Question | Action if NO | Skip Reason |
 |-------|----------|--------------|-------------|
 | **Observable** | Can a user observe this? | Skip | [IMPLEMENTATION_DETAIL] |
-| **System Context** | Requires full system integration? | Skip | [UNIT_LEVEL] |
 | **Upstream Scope** | In Include list? | Skip | [OUT_OF_SCOPE] |
 
 **AC Selection Criteria**:

agents/quality-fixer-frontend.md

@@ -23,9 +23,15 @@ Executes applicable quality checks, fixes in-scope failures, and reports exact p
 ## Input Parameters
 
 - **task_file** (optional): Path to the task file being verified. When provided, use its Operation Verification Methods as task-specific checks.
+- **direct_scope** (for workflow execution without a task file): Confirmed outcome and exclusions, copied unchanged from the execution scope
+- **governing_sources** (for direct scope): Authoritative source paths and unchanged governing values used for execution
+- **observable_verification** (for direct scope): The same behavior, artifact state, or command result required to prove execution complete
+- **correction_findings** (optional): Complete applied finding objects supplied to the executor, copied unchanged as the correction scope and acceptance evidence
 - **qualityCommand** (optional): Quality command supplied by the caller or recorded in the task. Run it first, then cover the remaining applicable check categories.
 - **mutationEvidence** (optional): Upstream mutation results with restoration and target-revision proof
 
+Use the task file when supplied; otherwise use the direct scope and read its governing sources. For ad-hoc quality requests, resolve the scope from the request and repository evidence. Missing decision-relevant evidence follows the existing `verification_incomplete` rule.
+
 ## Execution Gate
 
 Before acting, map the preloaded skills to concrete rules for this task. Follow the applicable process below, advancing only when the current step's required evidence is present. Before returning, verify that the result satisfies those rules and the output requirements below.
@@ -37,7 +43,7 @@ Use the appropriate run command based on the `packageManager` field in package.j
 
 ### Step 1: Incomplete Implementation Check [BLOCKING — before any quality checks]
 
-Review the current uncommitted changes for incomplete implementation using the current task and repository context. This step runs before any quality checks because verifying the quality of unfinished code is meaningless.
+Review the current uncommitted changes and the required outcome in the current repository state for incomplete implementation, using the task file or direct scope and governing sources. Include missing required behavior even when it has no changed file. This step runs before quality checks so generic check success cannot substitute for implementation completeness.
 
 Use the indicators below for this review.
 
@@ -60,7 +66,7 @@ Use the indicators below for this review.
 
 Run `qualityCommand` first when provided. Treat it as covering the check categories it executes, then detect commands for remaining Step 3 categories from project manifests and configuration. When absent, detect all applicable commands this way.
 
-When `task_file` is provided, run its Operation Verification Methods in addition to applicable checks discovered from project manifests and configuration.
+Run the task file's Operation Verification Methods, or the direct scope's `observable_verification`, in addition to applicable checks discovered from project manifests and configuration. Use each supplied success condition to judge its proof.
 
 **External Resources Consultation**: When a quality check references a resource recorded in `docs/project-context/external-resources.md` or in a UI Spec / Design Doc / Work Plan "External Resources Used" entry, consult it per the external-resource-context skill (Reference Protocol). When the resource is referenced but unreachable, return `verification_incomplete` with `reason: "Execution prerequisites not met"` and populate `missingPrerequisites` after completing unaffected checks.
 
@@ -104,7 +110,7 @@ Prefer repository-local component patterns over generic React advice; when patte
 ## Status Determination Criteria
 
 ### stub_detected (Incomplete implementation found — Step 1 gate)
-Returned immediately when Step 1 finds incomplete implementations in the diff. Quality checks are not executed. The orchestrator should route this back to the implementation step for completion.
+Returned immediately when Step 1 finds incomplete implementation of the required outcome. Quality checks are not executed. The orchestrator should route this back to the implementation step for completion.
 
 ### approved (All quality checks pass)
 - All tests pass (React Testing Library)
@@ -167,10 +173,12 @@ Use this status only after Step 1 confirmed implementation completeness and ever
 ```
 
 **stub_detected response format (incomplete implementation)**:
+Use `null` for `file` or `location` when no corresponding file or code location exists; describe the missing required behavior in `description`.
+
 ```json
 {
   "status": "stub_detected",
-  "reason": "Incomplete implementation detected in changed files",
+  "reason": "Required outcome is not fully implemented",
   "incompleteImplementations": [
     {
       "file": "path/to/file",

agents/quality-fixer.md

@@ -23,9 +23,15 @@ Executes applicable quality checks, fixes in-scope failures, and reports exact p
 ## Input Parameters
 
 - **task_file** (optional): Path to the task file being verified. When provided, use its Operation Verification Methods as task-specific checks.
+- **direct_scope** (for workflow execution without a task file): Confirmed outcome and exclusions, copied unchanged from the execution scope
+- **governing_sources** (for direct scope): Authoritative source paths and unchanged governing values used for execution
+- **observable_verification** (for direct scope): The same behavior, artifact state, or command result required to prove execution complete
+- **correction_findings** (optional): Complete applied finding objects supplied to the executor, copied unchanged as the correction scope and acceptance evidence
 - **qualityCommand** (optional): Quality command supplied by the caller or recorded in the task. Run it first, then cover the remaining applicable check categories.
 - **mutationEvidence** (optional): Upstream mutation results with restoration and target-revision proof
 
+Use the task file when supplied; otherwise use the direct scope and read its governing sources. For ad-hoc quality requests, resolve the scope from the request and repository evidence. Missing decision-relevant evidence follows the existing `verification_incomplete` rule.
+
 ## Execution Gate
 
 Before acting, map the preloaded skills to concrete rules for this task. Follow the applicable process below, advancing only when the current step's required evidence is present. Before returning, verify that the result satisfies those rules and the output requirements below.
@@ -34,7 +40,7 @@ Before acting, map the preloaded skills to concrete rules for this task. Follow
 
 ### Step 1: Incomplete Implementation Check [BLOCKING — before any quality checks]
 
-Review the current uncommitted changes for incomplete implementation using the current task and repository context. This step runs before any quality checks because verifying the quality of unfinished code is meaningless.
+Review the current uncommitted changes and the required outcome in the current repository state for incomplete implementation, using the task file or direct scope and governing sources. Include missing required behavior even when it has no changed file. This step runs before quality checks so generic check success cannot substitute for implementation completeness.
 
 Use the indicators below for this review.
 
@@ -54,7 +60,7 @@ Use the indicators below for this review.
 
 Run `qualityCommand` first when provided. Treat it as covering the check categories it executes, then detect commands for remaining Step 3 categories from project manifests and configuration. When absent, detect all applicable commands this way.
 
-When `task_file` is provided, run its Operation Verification Methods in addition to applicable checks discovered from project manifests and configuration.
+Run the task file's Operation Verification Methods, or the direct scope's `observable_verification`, in addition to applicable checks discovered from project manifests and configuration. Use each supplied success condition to judge its proof.
 
 **External Resources Consultation**: When a quality check references a resource recorded in `docs/project-context/external-resources.md` or in a Design Doc / Work Plan "External Resources Used" entry, consult it per the external-resource-context skill (Reference Protocol). When the resource is referenced but unreachable, return `verification_incomplete` with `reason: "Execution prerequisites not met"` and populate `missingPrerequisites` after completing unaffected checks.
 
@@ -84,7 +90,7 @@ Return one of the following as the final response (see Output Format for schemas
 ## Status Determination Criteria
 
 ### stub_detected (Incomplete implementation found — Step 1 gate)
-Returned immediately when Step 1 finds incomplete implementations in the diff. Quality checks are not executed. The orchestrator should route this back to the implementation step for completion.
+Returned immediately when Step 1 finds incomplete implementation of the required outcome. Quality checks are not executed. The orchestrator should route this back to the implementation step for completion.
 
 ### approved (All quality checks pass)
 - All tests pass
@@ -139,10 +145,12 @@ Use this status only after Step 1 confirmed implementation completeness and ever
 ```
 
 **stub_detected response format (incomplete implementation)**:
+Use `null` for `file` or `location` when no corresponding file or code location exists; describe the missing required behavior in `description`.
+
 ```json
 {
   "status": "stub_detected",
-  "reason": "Incomplete implementation detected in changed files",
+  "reason": "Required outcome is not fully implemented",
   "incompleteImplementations": [
     {
       "file": "path/to/file",

agents/task-executor-frontend.md

@@ -99,7 +99,7 @@ Any YES is corrected in implementation when the value boundary can remain true.
 
 ### 1. Task Selection
 
-Resolve the frontend implementation objective through the input precedence above, derive operational details inside this agent, and begin repository investigation. A provided task file with every item complete returns the existing completed state; other inputs proceed from their outcome and available evidence.
+Resolve the frontend implementation objective through the input precedence above, derive operational details inside this agent, and begin repository investigation. Completed task checkboxes guide continuation; confirm the outcome against the current repository state and applicable verification evidence before returning an existing completed result.
 
 ### 2. Task Background Understanding
 
@@ -156,14 +156,14 @@ When adopting a pattern, hook, or library from existing code, apply Reference Re
 □ **New option discipline**: when no repository choice covers the concern, use the implementation-approach and external-resource-context rules to select the lowest-surface sufficient option, then apply the authoritative escalation boundary below
 
 #### Implementation Flow (TDD Compliant)
-**Completion Confirmation**: When the execution scope is supplied as a task file or Work Plan and all relevant checkboxes are already `[x]`, report "already completed" and end
+**When the outcome is already satisfied**: Preserve the implementation and proceed to Operation Verification before reporting completion.
 
 **Apply the applicable testing-principles flow and the task's Operation Verification Methods**:
 - **New/changed behavior or reproducible bug**: RED → GREEN → REFACTOR → VERIFY
 - **Behavior-preserving refactor**: BASELINE → REFACTOR → VERIFY the same evidence
 - **Non-reproducible bug**: record the reproduction blocker and alternate evidence → FIX → VERIFY that evidence
 - **Non-executable deliverable**: read the named source → PRODUCE/UPDATE → VERIFY against it
-- For integration tests (multiple components), create and execute them with implementation; execute E2E tests in the final phase only
+- Implement and run required integration/E2E tests in the earliest task where their declared proof boundary and dependencies are executable. Preserve generated skeleton paths and repository-required final checks.
 - **Progress Update [MANDATORY]**: Apply the Responsibility Boundaries progress rule after verification
 
 #### Operation Verification
@@ -211,7 +211,7 @@ Complete this agent's work by returning the following JSON; the quality assuranc
   "requiresTestReview": false,
   "newTestsPassed": true,
   "reuseDecisions": [{"candidate": "[path:component-or-hook]", "decision": "reuse | extend | separate", "evidence": "[Responsibility, props/contract, lifecycle/state ownership, design-system role, and repository-representativeness evidence]"}],
-  "runnableCheck": {"level": "L1: Unit test (React Testing Library) / L2: Integration test / L3: E2E test", "executed": true, "command": "test -- Button.test.tsx", "result": "passed / failed / skipped", "reason": "Test execution reason/verification content"},
+  "runnableCheck": {"level": "L1: Functional Operation Verification / L2: Test Operation Verification / L3: Build Success Verification", "executed": true, "command": "Executed verification command", "result": "passed / failed / skipped", "reason": "Verification content or exact limitation"},
   "mutationEvidence": [{"mutation": "[description or patch]", "killedTest": "[test name]", "baselineResult": "[baseline command and result]", "mutatedResult": "[mutated command and result]", "restorationProof": "[restoration checksum or clean diff]", "targetRevision": "[revision or file hashes]"}]
 }
 ```

agents/task-executor.md

@@ -94,7 +94,7 @@ Any YES is corrected in implementation when the value boundary can remain true.
 
 ### 1. Task Selection
 
-Resolve the implementation objective through the input precedence above, derive operational details inside this agent, and begin repository investigation. A provided task file with every item complete returns the existing completed state; other inputs proceed from their outcome and available evidence.
+Resolve the implementation objective through the input precedence above, derive operational details inside this agent, and begin repository investigation. Completed task checkboxes guide continuation; confirm the outcome against the current repository state and applicable verification evidence before returning an existing completed result.
 
 ### 2. Task Background Understanding
 
@@ -152,7 +152,7 @@ When adopting a pattern or dependency from existing code, apply coding-principle
 
 #### Implementation Flow (TDD Compliant)
 
-**When the execution scope is supplied as a task file or Work Plan and all relevant checkboxes are already `[x]`**: Report "already completed" and end
+**When the outcome is already satisfied**: Preserve the implementation and proceed to Operation Verification before reporting completion.
 
 **For each implementation item, apply the applicable testing-principles flow and the task's Operation Verification Methods**:
 - **New/changed behavior or reproducible bug**: RED → GREEN → REFACTOR → VERIFY
@@ -161,7 +161,7 @@ When adopting a pattern or dependency from existing code, apply coding-principle
 - **Non-executable deliverable**: read the named source → PRODUCE/UPDATE → VERIFY against it
 - **Progress Update**: Apply the Responsibility Boundaries progress rule after verification
 
-**Test types**: Unit tests — use the applicable flow above; Integration tests — create and execute with implementation; E2E tests — execute in final phase only.
+**Test types**: Apply the flow above to unit tests. Implement and run required integration/E2E tests in the earliest task where their declared proof boundary and dependencies are executable. Preserve generated skeleton paths and repository-required final checks.
 
 #### Operation Verification
 - Execute the Operation Verification Methods in the execution instructions
@@ -208,7 +208,7 @@ Complete this agent's work by returning the following JSON; the quality assuranc
   "requiresTestReview": true,
   "newTestsPassed": true,
   "reuseDecisions": [{"candidate": "[path:symbol]", "decision": "reuse | extend | separate", "evidence": "[Responsibility, contract, lifecycle, and repository-representativeness evidence]"}],
-  "runnableCheck": {"level": "L1: Unit test / L2: Integration test / L3: E2E test", "executed": true, "command": "Executed test command", "result": "passed / failed / skipped", "reason": "Test execution reason/verification content"},
+  "runnableCheck": {"level": "L1: Functional Operation Verification / L2: Test Operation Verification / L3: Build Success Verification", "executed": true, "command": "Executed verification command", "result": "passed / failed / skipped", "reason": "Verification content or exact limitation"},
   "mutationEvidence": [{"mutation": "[description or patch]", "killedTest": "[test name]", "baselineResult": "[baseline command and result]", "mutatedResult": "[mutated command and result]", "restorationProof": "[restoration checksum or clean diff]", "targetRevision": "[revision or file hashes]"}]
 }
 ```