codex-workflows 0.4.7 → 0.4.8

package/.agents/skills/integration-e2e-testing/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: integration-e2e-testing
-description: "Integration and E2E test design principles, ROI calculation, test skeleton specification, and review criteria. Use when: designing integration tests, E2E tests, generating test skeletons, or reviewing test quality."
+description: "Integration and E2E test design principles, value-based selection, test skeleton specification, and review criteria. Use when: designing integration tests, E2E tests, generating test skeletons, or reviewing test quality."
 ---
 
 # Integration and E2E Testing Principles
@@ -20,13 +20,13 @@ description: "Integration and E2E test design principles, ROI calculation, test
 
 ## Behavior-First Principle [MANDATORY]
 
-### MUST Include (High ROI)
+### MUST Include (High Value)
 - Business logic correctness (calculations, state transitions, data transformations)
 - Data integrity and persistence behavior
 - User-visible functionality completeness
 - Error handling behavior (what user sees/experiences)
 
-### MUST Exclude (Low ROI in CI/CD)
+### MUST Exclude (Low Value in CI/CD)
 - External service real connections — use contract/interface verification instead
 - Performance metrics — non-deterministic, defer to load testing
 - Implementation details — test observable behavior only
@@ -34,20 +34,52 @@ description: "Integration and E2E test design principles, ROI calculation, test
 
 **ENFORCEMENT**: Test = User-observable behavior verifiable in isolated CI environment
 
-## ROI Calculation
+## Value and Selection Model
 
 ```
-ROI Score = (Business Value x User Frequency + Legal Requirement x 10 + Defect Detection)
-            / (Creation Cost + Execution Cost + Maintenance Cost)
+Value Score = (Business Value x User Frequency) + (Legal Requirement x 10) + Defect Detection
 ```
 
-### Cost Table
+Use `Value Score` for ranking candidates of the same test type. Handle E2E cost through budget limits and reserved-slot rules instead of cost-division scoring.
 
-| Test Type | Create | Execute | Maintain | Total |
-|-----------|--------|---------|----------|-------|
-| Unit | 1 | 1 | 1 | 3 |
-| Integration | 3 | 5 | 3 | 11 |
-| E2E | 10 | 20 | 8 | 38 |
+### E2E Threshold
+
+- `E2E threshold = Value Score >= 50`
+- Use this threshold for non-reserved E2E selection only
+- Reserved-slot eligibility overrides the threshold when the candidate is the highest-value user-facing multi-step journey
+
+### Selection Rules
+
+| Test Type | Ranking Basis | Selection Rule |
+|-----------|---------------|----------------|
+| Integration | Highest `Value Score` among integration candidates | Select up to budget |
+| E2E | Highest `Value Score` among E2E candidates | Select when `reservedSlotEligible = true`, or when `Value Score >= 50` |
+
+### E2E Candidate Rules
+
+- Treat integration and E2E as complementary coverage layers
+- Retain an E2E candidate when it validates a user-facing multi-step journey, even if integration tests partially cover the behavior
+- Preserve E2E candidates for user-facing multi-step journeys that validate cross-screen or cross-boundary continuity
+- Distinguish user-facing journeys from service-internal chains; reserved E2E coverage applies only to user-facing journeys
+
+### Reserved E2E Slot
+
+Reserve 1 E2E slot for the highest-value user-facing multi-step journey when such a journey exists, even if it does not satisfy `Value Score >= 50`.
+
+### E2E Absence Contract
+
+When no E2E test is generated, downstream artifacts must treat that as an explicit decision, not an error. Carry:
+- `generatedFiles.e2e: null`
+- `e2eAbsenceReason`: one of `no_user_facing_multi_step_journey`, `all_e2e_candidates_below_threshold`, `covered_by_existing_e2e`, `budget_not_justified`
+
+### E2E Selection Decision Table
+
+| Condition | Result |
+|-----------|--------|
+| At least one user-facing multi-step journey exists | Reserve 1 E2E slot for the highest-value such journey |
+| Remaining E2E candidate has `Value Score >= 50` | Eligible for non-reserved E2E selection |
+| Remaining E2E candidate has `Value Score < 50` | Exclude and use `all_e2e_candidates_below_threshold` if no E2E remains |
+| Existing E2E already covers the same journey | Exclude and use `covered_by_existing_e2e` if no E2E remains |
 
 ## Test Skeleton Specification [MANDATORY]
 
@@ -62,7 +94,7 @@ Each test MUST include the following annotations:
 // @dependency: none | [component names] | full-system
 // @real-dependency: [component names] (optional)
 // @complexity: low | medium | high
-// ROI: [score]
+// Value Score: [score]
 ```
 
 Adapt comment syntax to the project's language when generating or reviewing test skeletons.

package/.agents/skills/integration-e2e-testing/agents/openai.yaml

@@ -1,6 +1,6 @@
 interface:
   display_name: "Integration & E2E Testing"
-  short_description: "Test design and ROI calculation"
+  short_description: "Test design and value-based selection"
   default_prompt: "Use $integration-e2e-testing to design integration tests."
 
 policy:

package/.agents/skills/integration-e2e-testing/references/e2e-design.md

@@ -2,7 +2,9 @@
 
 ## When to Create E2E Tests
 
-E2E tests target **critical user journeys** that span multiple pages or require real browser interaction. Apply the same ROI framework from the parent skill -- only create E2E tests when ROI > 50.
+E2E tests target **critical user journeys** that span multiple pages or require real browser interaction. Apply the parent skill rules exactly:
+- Reserve 1 E2E slot for the highest-value user-facing multi-step journey
+- Use `Value Score >= 50` for any additional non-reserved E2E candidate
 
 ### Candidate Sources
 
@@ -15,7 +17,7 @@ E2E tests target **critical user journeys** that span multiple pages or require
 
 ### Selection Criteria
 
-**Include** (high E2E ROI):
+**Include** (high-value E2E coverage):
 - Multi-page user journeys (login -> dashboard -> action -> confirmation)
 - Flows requiring real browser APIs (navigation, cookies, localStorage)
 - Accessibility verification requiring actual DOM rendering
@@ -44,7 +46,7 @@ User Journey: [Description of what the user accomplishes]
 Preconditions: [Auth state, data state]
 Verification Points:
   - [What to assert at each step]
-E2E ROI Score: [calculated score]
+E2E Value Score: [calculated score]
 ```
 
 ## Playwright Test Architecture
@@ -82,5 +84,6 @@ When UI Spec defines responsive behavior, test critical breakpoints:
 
 Hard limits per feature (same as parent skill):
 - **E2E Tests**: MAX 1-2 tests
-- Only generate if ROI score > 50
+- Generate the reserved user-journey E2E when eligible
+- Generate any additional E2E only when `Value Score >= 50`
 - Prefer fewer, comprehensive journey tests over many granular tests

package/.agents/skills/recipe-add-integration-tests/SKILL.md

@@ -147,13 +147,16 @@ Check Step 5 result:
 Spawn quality-fixer routed by task filename pattern:
 - `*-backend-task-*` -> Spawn `quality-fixer`
 - `*-frontend-task-*` -> Spawn `quality-fixer-frontend`
-- Prompt: "Final quality assurance for test files added in this workflow. Run all tests and verify coverage."
+- Prompt: "Final quality assurance for test files added in this workflow. Task file: [current task file]. filesModified: [Step 4 testsAdded]. Use these files as the stub-detection scope. Run all tests and verify coverage."
 
-**Expected output**: `status` (`approved`/`blocked`)
+**Expected output**: `status` (`stub_detected`/`approved`/`blocked`)
 
 ### Step 8: Commit
 
-On `status: "approved"` from quality-fixer:
+On quality-fixer result:
+- `status: "stub_detected"` -> Return to Step 4 with `stubFindings`
+- `status: "blocked"` -> Escalate to user
+- `status: "approved"` -> Commit test files
 - MUST commit test files with appropriate message
 ENFORCEMENT: Commits without quality-fixer approval are invalid.
 

package/.agents/skills/recipe-build/SKILL.md

@@ -79,8 +79,12 @@ For EACH task, YOU MUST:
      - `needs_revision` -> Return to step 2 with `requiredFixes`
      - `approved` -> Proceed to step 4
    - `readyForQualityCheck: true` -> Proceed to step 4
-4. **Spawn quality-fixer agent**: "Execute all quality checks and fixes"
-5. **COMMIT on approval**: After `status: "approved"` from quality-fixer -> Execute git commit
+4. **Spawn quality-fixer agent**: "Execute all quality checks and fixes. Task file: [task-file-path]. filesModified: [task-executor response filesModified]. Use these files as the stub-detection scope."
+5. **CHECK quality-fixer response**:
+   - `status: "stub_detected"` -> Return to step 2 with `stubFindings`
+   - `status: "blocked"` -> STOP and escalate to user
+   - `status: "approved"` -> Proceed to step 6
+6. **COMMIT on approval**: After `status: "approved"` from quality-fixer -> Execute git commit
 
 **CRITICAL**: MUST monitor ALL structured responses WITHOUT EXCEPTION and ENSURE every quality gate is passed.
 ENFORCEMENT: Proceeding past a failed quality gate invalidates all subsequent work.

package/.agents/skills/recipe-diagnose/SKILL.md

@@ -8,7 +8,7 @@ description: "Investigate problem, verify findings, and derive solutions through
 1. [LOAD IF NOT ACTIVE] `ai-development-guide` — AI development patterns
 2. [LOAD IF NOT ACTIVE] `coding-rules` — coding standards
 
-**Context**: Diagnosis flow to identify root cause and present solutions
+**Context**: Diagnosis flow to identify concrete failure points and present solutions
 
 Target problem: $ARGUMENTS
 
@@ -69,10 +69,10 @@ Confirm from rule-advisor output:
 ```
 Problem -> investigator -> verifier -> solver --+
                  ^                              |
-                 +-- confidence < high ---------+
+                 +-- coverage insufficient -----+
                       (max 2 iterations)
 
-confidence=high reached -> Report
+coverage sufficient -> Report
 ```
 
 **Context Separation**: Pass only structured output to each step. Each step starts fresh with the data only.
@@ -99,7 +99,7 @@ For change failures, also include:
 - what both areas share
 ```
 
-**Expected output**: Evidence matrix, comparison analysis results, causal tracking results, list of unexplored areas, investigation limitations
+**Expected output**: Evidence matrix, path map, failure points, comparison analysis results, list of unexplored areas, investigation limitations
 
 ### Step 2: Investigation Quality Check
 
@@ -107,10 +107,11 @@ Review investigation output:
 
 **Quality Check** (verify output contains the following):
 - [ ] `comparisonAnalysis` is present and `normalImplementation` is non-null, or explicitly states that no working implementation was found
-- [ ] causalChain for each hypothesis reaches a stop condition
-- [ ] causeCategory for each hypothesis
+- [ ] `pathMap` is present with ordered nodes or explicit unknown segments
+- [ ] causalChain for each failure point reaches a stop condition
+- [ ] causeCategory for each failure point
 - [ ] `investigationSources` covers at least 3 distinct source types
-- [ ] each hypothesis has supporting evidence with a concrete source
+- [ ] each failure point has supporting evidence with a concrete source
 - [ ] Investigation covering investigationFocus items (when provided)
 
 **If quality insufficient**: MUST re-spawn investigator agent specifying the missing items and include the previous investigation output for context
@@ -132,45 +133,45 @@ Proceed to verifier once quality is satisfied.
 
 Spawn verifier agent: "Verify the following investigation results. Investigation results: [Investigation output]"
 
-**Expected output**: Alternative hypotheses (at least 3), Devil's Advocate evaluation, final conclusion, confidence
+**Expected output**: Path coverage findings, independent failure-point evaluation, final conclusion, coverageAssessment/finalStatus
 
-**Confidence Criteria**:
-- **high**: No uncertainty affecting solution selection or implementation
-- **medium**: Uncertainty exists but resolvable with additional investigation
-- **low**: Fundamental information gap exists
+**Coverage Criteria**:
+- **sufficient**: No major uncovered boundary affects solution selection or implementation
+- **partial**: Some uncertainty exists but a bounded next investigation is possible
+- **insufficient**: Fundamental information gap exists on the relevant path
 
 ### Step 4: Solution Derivation (solver)
 
-Spawn solver agent: "Derive solutions based on the following verified conclusion. Causes: [verifier's conclusion.causes]. Causes relationship: [causesRelationship: independent/dependent/exclusive]. Confidence: [high/medium/low]."
+Spawn solver agent: "Derive solutions based on the following verified conclusion. Failure points: [verifier's conclusion.confirmedFailurePoints]. Failure-point relationships: [verifier's conclusion.failurePointRelationships]. Coverage assessment: [verifier's conclusion.coverageAssessment]. Final status: [verifier's conclusion.finalStatus]. Impact analysis: [investigator output impactAnalysis]."
 
 **Expected output**: Multiple solutions (at least 3), tradeoff analysis, recommendation and implementation steps, residual risks
 
-**Completion condition**: confidence=high
+**Completion condition**: `coverageAssessment=sufficient` and `finalStatus=ready_for_solution`
 
 **When not reached**:
 1. Return to Step 1 with uncertainties identified by solver as investigation targets
 2. Maximum 2 additional investigation iterations
-3. After 2 iterations without reaching high, present user with options:
+3. After 2 iterations without reaching sufficient coverage, present user with options:
    - Continue additional investigation
-   - Execute solution at current confidence level
+   - Execute solution at current coverage level
 
 ### Step 5: Final Report Creation
 
-**Prerequisite**: confidence=high achieved
+**Prerequisite**: sufficient coverage achieved
 
 After diagnosis completion, report to user in the following format:
 
 ```
 ## Diagnosis Result Summary
 
-### Identified Causes
-[Cause list from verification results]
-- Causes relationship: [independent/dependent/exclusive]
+### Identified Failure Points
+[Failure point list from verification results]
+- Failure-point relationships: [independent/upstream_of/downstream_of/amplifies/same_boundary]
 
 ### Verification Process
 - Investigation scope: [Scope confirmed in investigation]
 - Additional investigation iterations: [0/1/2]
-- Alternative hypotheses count: [Number generated in verification]
+- Coverage assessment: [sufficient/partial/insufficient]
 
 ### Recommended Solution
 [Solution derivation recommendation]
@@ -197,7 +198,7 @@ Rationale: [Selection rationale]
 
 - [ ] Spawned investigator and obtained evidence matrix, comparison analysis, and causal tracking
 - [ ] Performed investigation quality check and re-ran if insufficient
-- [ ] Spawned verifier and obtained confidence level
+- [ ] Spawned verifier and obtained coverage assessment
 - [ ] Spawned solver
-- [ ] Achieved confidence=high (or obtained user approval after 2 additional iterations)
+- [ ] Achieved sufficient coverage (or obtained user approval after 2 additional iterations)
 - [ ] Presented final report to user

package/.agents/skills/recipe-front-build/SKILL.md

@@ -87,8 +87,12 @@ For EACH task, YOU MUST:
      - `needs_revision` -> Return to step 2 with `requiredFixes`
      - `approved` -> Proceed to step 4
    - `readyForQualityCheck: true` -> Proceed to step 4
-4. **Spawn quality-fixer-frontend agent**: "Execute all frontend quality checks and fixes"
-5. **COMMIT on approval**: After `status: "approved"` from quality-fixer-frontend -> Execute git commit. Use `changeSummary` for commit message.
+4. **Spawn quality-fixer-frontend agent**: "Execute all frontend quality checks and fixes. Task file: docs/plans/tasks/[filename].md. filesModified: [task-executor-frontend response filesModified]. Use these files as the stub-detection scope."
+5. **CHECK quality-fixer-frontend response**:
+   - `status: "stub_detected"` -> Return to step 2 with `stubFindings`
+   - `status: "blocked"` -> STOP and escalate to user
+   - `status: "approved"` -> Proceed to step 6
+6. **COMMIT on approval**: After `status: "approved"` from quality-fixer-frontend -> Execute git commit. Use `changeSummary` for commit message.
 
 **CRITICAL**: MUST monitor ALL structured responses WITHOUT EXCEPTION and ENSURE every quality gate is passed.
 ENFORCEMENT: Proceeding past a failed quality gate invalidates all subsequent work.

package/.agents/skills/recipe-front-plan/SKILL.md

@@ -46,7 +46,7 @@ Check for existence of design documents in docs/design/.
 Spawn acceptance-test-generator agent: "Generate test skeletons from Design Doc at [path]. [UI Spec at [ui-spec path] if exists.]"
 
 ### Step 3: Work Plan Creation
-Spawn work-planner agent: "Create work plan from Design Doc at [path]. Integration test file: [path from step 2]. E2E test file: [path from step 2]. Integration tests are created simultaneously with each phase implementation, E2E tests are executed only in final phase."
+Spawn work-planner agent: "Create work plan from Design Doc at [path]. Integration test file: [path from step 2]. E2E test file: [path from step 2 or null]. E2E absence reason: [value from step 2 when E2E file is null]. Integration tests are created simultaneously with each phase implementation, E2E tests are executed only in final phase when an E2E file exists."
 
 **[STOP -- BLOCKING]** Interact with user to complete plan and obtain approval for plan content. Clarify specific implementation steps and risks.
 **CANNOT proceed until user explicitly approves the work plan.**

package/.agents/skills/recipe-fullstack-build/SKILL.md

@@ -97,8 +97,12 @@ For EACH task, YOU MUST:
      - `needs_revision` -> Return to step 2 with `requiredFixes`
      - `approved` -> Proceed to step 4
    - `readyForQualityCheck: true` -> Proceed to step 4
-4. **Spawn quality-fixer agent** (layer-appropriate per routing table): "Execute all quality checks and fixes"
-5. **COMMIT on approval**: After `status: "approved"` from quality-fixer -> Execute git commit
+4. **Spawn quality-fixer agent** (layer-appropriate per routing table): "Execute all quality checks and fixes. Task file: [task-file-path]. filesModified: [executor response filesModified]. Use these files as the stub-detection scope."
+5. **CHECK quality-fixer response**:
+   - `status: "stub_detected"` -> Return to step 2 with `stubFindings`
+   - `status: "blocked"` -> STOP and escalate to user
+   - `status: "approved"` -> Proceed to step 6
+6. **COMMIT on approval**: After `status: "approved"` from quality-fixer -> Execute git commit
 
 **CRITICAL**: MUST monitor ALL structured responses WITHOUT EXCEPTION and ENSURE every quality gate is passed.
 ENFORCEMENT: Proceeding past a failed quality gate invalidates all subsequent work.

package/.agents/skills/recipe-fullstack-implement/SKILL.md

@@ -124,8 +124,9 @@ ENFORCEMENT: Sub-agent prompts missing the constraint suffix MUST be re-issued w
 **Rules**:
 1. Execute ONE task completely before starting next (each task goes through the full 4-step cycle individually, using the correct executor per filename pattern)
 2. Check executor status before quality-fixer (escalation check)
-3. Quality-fixer MUST run after each executor (no skipping)
-4. Commit MUST execute when quality-fixer returns `status: "approved"` (do not defer to end)
+3. Quality-fixer MUST run after each executor (no skipping) and MUST receive the executor `filesModified` list as stub-detection scope
+4. If quality-fixer returns `status: "stub_detected"`, route the task back to the same executor with `stubFindings`
+5. Commit MUST execute only when quality-fixer returns `status: "approved"` (do not defer to end)
 
 ### Post-Implementation Verification (After All Tasks Complete)
 
@@ -149,8 +150,9 @@ After all task cycles finish, collect all `filesModified` from every task-execut
 ### Test Information Communication
 After acceptance-test-generator execution, when calling work-planner, communicate:
 - Generated integration test file path
-- Generated E2E test file path
-- Explicit note that integration tests are created simultaneously with implementation, E2E tests are executed after all implementations
+- Generated E2E test file path or `null`
+- E2E absence reason when no E2E file is generated
+- Explicit note that integration tests are created simultaneously with implementation, E2E tests are executed after all implementations only when an E2E file exists
 
 **[STOP -- BLOCKING]** Upon detecting ANY requirement changes, halt execution immediately.
 **CANNOT proceed until user explicitly confirms the change scope.**

package/.agents/skills/recipe-implement/SKILL.md

@@ -105,8 +105,12 @@ After user grants "batch approval for entire implementation phase", enter autono
      - `needs_revision` -> Return to step 1 with `requiredFixes`
      - `approved` -> Proceed to step 3
    - Otherwise -> Proceed to step 3
-3. Spawn quality-fixer (or quality-fixer-frontend) agent: "Quality check and fixes"
-4. git commit -> Execute on `status: "approved"`
+3. Spawn quality-fixer (or quality-fixer-frontend) agent: "Quality check and fixes. Task file: [task-file-path]. filesModified: [executor response filesModified]. Use these files as the stub-detection scope."
+4. Check quality-fixer response:
+   - `status: "stub_detected"` -> Return to step 1 with `stubFindings`
+   - `status: "blocked"` -> Escalate to user
+   - `status: "approved"` -> Proceed to step 5
+5. git commit -> Execute on `status: "approved"`
 
 ### Post-Implementation Verification (After All Tasks Complete)
 
@@ -130,8 +134,9 @@ After all task cycles finish, collect all `filesModified` from every executor re
 ### Test Information Communication
 After acceptance-test-generator execution, when spawning work-planner, communicate:
 - Generated integration test file path
-- Generated E2E test file path
-- Note: integration tests are created with implementation; E2E tests run after all implementations
+- Generated E2E test file path or `null`
+- E2E absence reason when no E2E file is generated
+- Note: integration tests are created with implementation; E2E tests run after all implementations when an E2E file exists
 
 ## Completion Criteria
 

package/.agents/skills/recipe-plan/SKILL.md

@@ -47,9 +47,10 @@ Present options if multiple exist (can be specified with $ARGUMENTS).
 - Confirm with user whether to generate E2E test skeleton first
 - If user wants generation: Spawn acceptance-test-generator agent: "Generate test skeletons from Design Doc at [design-doc-path]"
 - Pass generation results to next process according to subagents-orchestration-guide skill coordination specification
+- If no E2E file is generated, carry the explicit `e2eAbsenceReason` forward as a valid planning input
 
 ### Step 3: Work Plan Creation
-- Spawn work-planner agent: "Create work plan from design document at [design-doc-path]. Include deliverables from previous process according to subagents-orchestration-guide skill coordination specification."
+- Spawn work-planner agent: "Create work plan from design document at [design-doc-path]. Include deliverables from previous process according to subagents-orchestration-guide skill coordination specification. If `generatedFiles.e2e` is null, use `e2eAbsenceReason` and accept the null E2E file as a valid planning input."
 - Interact with user to complete plan and obtain approval for plan content
 - Clarify specific implementation steps and risks
 

package/.agents/skills/recipe-update-doc/SKILL.md

@@ -109,7 +109,7 @@ Spawn [Update Agent from Step 2] agent: "Operation Mode: update. Existing Docume
 
 For Design Doc updates, first verify the updated document against code:
 
-Spawn code-verifier agent: "Verify the updated Design Doc against current code. doc_type: design-doc. document_path: [path from Step 1]. verbose: false."
+Spawn code-verifier agent: "Verify the updated Design Doc against current code. doc_type: design-doc. document_path: [path from Step 1]. verbose: false. Focus especially on literal identifier referential integrity for concrete paths, endpoints, type names, config keys, and other exact identifiers changed in this update."
 
 **Store output as**: `$CODE_VERIFICATION_OUTPUT`
 

package/.agents/skills/subagents-orchestration-guide/SKILL.md

@@ -180,13 +180,13 @@ Subagents respond in JSON format. The final response from each JSON-returning su
 - **requirement-analyzer**: scale, confidence, affectedLayers, adrRequired, scopeDependencies, questions
 - **codebase-analyzer**: analysisScope, existingElements, dataModel, focusAreas, limitations
 - **task-executor**: status (escalation_needed/completed), escalation_type (design_compliance_violation/similar_function_found/similar_component_found/investigation_target_not_found/out_of_scope_file/test_environment_not_ready), testsAdded, requiresTestReview
-- **quality-fixer**: status (approved/blocked). For blocked responses, discriminate by `reason`: specification conflicts use `blockingIssues[]`; execution prerequisites use `missingPrerequisites[]`, and each item provides its own `resolutionSteps`
+- **quality-fixer**: status (`stub_detected`/approved/blocked). `stub_detected` returns `stubFindings[]` and routes back to the task executor. For blocked responses, discriminate by `reason`: specification conflicts use `blockingIssues[]`; execution prerequisites use `missingPrerequisites[]`, and each item provides its own `resolutionSteps`
 - **document-reviewer**: verdict.decision (approved/approved_with_conditions/needs_revision/rejected)
 - **code-verifier**: summary.status, summary.consistencyScore, discrepancies, reverseCoverage
 - **design-sync**: sync_status (CONFLICTS_FOUND/NO_CONFLICTS) — text format with [SUMMARY] block
 - **integration-test-reviewer**: status (approved/needs_revision/blocked), requiredFixes
 - **security-reviewer**: status (approved/approved_with_notes/needs_revision/blocked), findings, notes, requiredFixes
-- **acceptance-test-generator**: status, generatedFiles
+- **acceptance-test-generator**: status, generatedFiles, `e2eAbsenceReason`
 
 ## Handling Requirement Changes
 
@@ -296,7 +296,8 @@ Batch approval -> Start autonomous execution mode
               - needs_revision -> back to task-executor
               - approved -> quality-fixer
           - No issues -> quality-fixer
-      -> quality-fixer: Quality check and fixes
+      -> quality-fixer: Quality check and fixes using the executor `filesModified` set as the stub-detection scope
+          - stub_detected -> task-executor/task-executor-frontend: complete implementation -> re-run quality-fixer
       -> Orchestrator: Execute git commit
       -> Check remaining tasks:
           - Yes -> next task
@@ -352,13 +353,15 @@ Maximum retry count is 1 verification fix cycle. If any failed verifier still fa
 
 **Orchestrator verification items**:
 - Verify integration test file path retrieval and existence
-- Verify E2E test file path retrieval and existence
+- Verify E2E test file path retrieval and existence when `generatedFiles.e2e` is not null
+- Verify `e2eAbsenceReason` is present when `generatedFiles.e2e` is null
 
 **Pass to work-planner**:
 - Integration test file: [path] (create and execute simultaneously with each phase implementation)
-- E2E test file: [path] (execute only in final phase)
+- E2E test file: [path] or `null` (execute only in final phase when present)
+- E2E absence reason: [value when E2E test file is null]
 
-**On error**: Escalate to user if files are not generated
+**On error**: Escalate to user only when required outputs are missing without a valid absence reason
 
 ### Design Doc to Work Plan Verification Handoff
 

package/.agents/skills/task-analyzer/references/skills-index.yaml

@@ -118,7 +118,7 @@ skills:
   integration-e2e-testing:
     skill: "integration-e2e-testing"
     tags: [testing, integration-testing, e2e-testing, test-design, behavior-first, roi, test-skeleton, ears-format]
-    typical-use: "Integration and E2E test design principles, ROI-based test selection, behavior-first approach, test skeleton specification"
+    typical-use: "Integration and E2E test design principles, value-based test selection, behavior-first approach, test skeleton specification"
     size: medium
     key-references:
       - "Test Pyramid - Mike Cohn"
@@ -127,7 +127,7 @@ skills:
       - "References"
       - "Test Type Definition and Limits [MANDATORY]"
       - "Behavior-First Principle [MANDATORY]"
-      - "ROI Calculation"
+      - "Value and Selection Model"
       - "Test Skeleton Specification [MANDATORY]"
       - "EARS Format Mapping"
       - "Test File Naming Convention"

package/.agents/skills/testing/references/typescript.md

@@ -213,7 +213,7 @@ export const test = base.extend<{ authenticatedPage: Page }>({
 ### E2E Budget
 
 - **MAX 1-2 E2E tests per feature**
-- Only generate if ROI score > 50
+- Only generate an additional non-reserved E2E test when `Value Score >= 50`
 - Prefer fewer comprehensive journey tests over many granular tests
 
 ### Test Isolation