codex-workflows 0.4.7 → 0.4.9

package/.agents/skills/ai-development-guide/SKILL.md

@@ -131,13 +131,14 @@ How to handle duplicate code based on Martin Fowler's "Refactoring":
 - For low certainty cases, create minimal verification code first
 
 ### Pattern 5: Insufficient Existing Code Investigation
-**Symptom**: Duplicate implementations, architecture inconsistency, integration failures
-**Cause**: Insufficient understanding of existing code before implementation
+**Symptom**: Duplicate implementations, architecture inconsistency, integration failures, adopting outdated patterns
+**Cause**: Insufficient understanding of existing code before implementation; referencing only nearby files without checking representativeness
 **Avoidance**:
 - Before implementation, always search for similar functionality
 - Similar functionality found: Use that implementation (do not create new)
 - Similar functionality is technical debt: Create ADR improvement proposal
 - No similar functionality: Implement following existing design philosophy
+- When adopting a pattern or dependency from nearby code, verify it is representative across the repository before adopting it
 
 ## Debugging Techniques
 
@@ -175,6 +176,15 @@ Pattern: Structured logging with context
 }
 ```
 
+## Quality Assurance Mechanism Awareness
+
+Before executing quality checks, discover applicable quality tools and constraints by inspecting the affected files' types, project manifests, CI pipelines, and configuration:
+- Primary detection: inspect affected file types, manifests, configuration, and CI pipelines to identify applicable quality tools
+- Check for domain-specific linters or validators such as schema validators, API spec validators, or configuration-file checkers
+- Check for domain-specific constraints in project configuration such as naming rules, length limits, or format requirements
+- When a task file lists `Quality Assurance Mechanisms`, use that section as supplementary guidance for what to verify
+- Include discovered domain-specific checks alongside the standard quality phases below
+
 ## Quality Check Workflow [MANDATORY]
 
 Universal quality assurance phases applicable to all languages:

package/.agents/skills/coding-rules/SKILL.md

@@ -51,6 +51,21 @@ For language-specific rules, also read:
 - Depend on abstractions, not concrete implementations
 - Minimize inter-module dependencies
 
+## Reference Representativeness
+
+### Verifying References Before Adoption
+
+When adopting patterns, APIs, or dependencies from existing code:
+- If referencing only nearby files, verify the pattern is representative across the repository before adopting it
+- If multiple approaches coexist, identify the majority pattern and make a deliberate choice
+- If adopting an external dependency, verify repository-wide usage distribution for that dependency and its version
+- If repository evidence is insufficient to choose an appropriate dependency version, escalate instead of guessing
+- If following an existing pattern when alternatives exist, state the reason for following it
+
+### Principle
+
+Nearby code is a starting point for investigation, not a sufficient basis for adoption. Confirm that the reference is representative of repository conventions before using it as the model.
+
 ## Performance
 
 - **Measure first**: Profile before optimizing — no premature optimization

package/.agents/skills/documentation-criteria/references/design-template.md

@@ -52,6 +52,12 @@ unknowns:
 - [ ] [Standard/convention] `[explicit]` - Source: [config / rule file / documentation path]
 - [ ] [Observed pattern] `[implicit]` - Evidence: [file paths] - Confirmed: [Yes/No]
 
+#### Quality Assurance Mechanisms
+How quality is enforced in the change area. Each item is either adopted for this change or noted with a reason.
+
+- [ ] [Tool/check name] — Enforces: [what] — Config: [path] — Covers: [file paths/patterns or "project-wide"] — Status: `adopted` / `noted (reason)`
+- [ ] [Domain-specific constraint] — Enforces: [what] — Source: [path] — Covers: [file paths/patterns or "project-wide"] — Status: `adopted` / `noted (reason)`
+
 ### Problem to Solve
 
 [Specific problems or challenges this feature aims to address]

package/.agents/skills/documentation-criteria/references/plan-template.md

@@ -32,6 +32,15 @@ Repeat this block for each Design Doc when multiple Design Docs exist. Preserve
 - **Success criteria**: [extracted from Design Doc]
 - **Failure response**: [extracted from Design Doc]
 
+## Quality Assurance Mechanisms (from Design Docs)
+
+Adopted quality gates for the change area. Each task in this plan must satisfy the applicable mechanisms.
+
+| Mechanism | Enforces | Config Location | Covered Files |
+|-----------|----------|-----------------|---------------|
+| [Tool/check name] | [What quality aspect it enforces] | [path/to/config] | [file paths or patterns covered, or "project-wide"] |
+| [Domain constraint] | [What it enforces] | [path/to/source] | [file paths or patterns covered, or "project-wide"] |
+
 ## Design-to-Plan Traceability
 
 Map each Design Doc technical requirement to the task or phase that covers it. Use one row per extracted requirement item. Every row must have at least one covering task, or an explicit justified gap.

package/.agents/skills/documentation-criteria/references/task-template.md

@@ -37,6 +37,10 @@ Brief observations recorded after reading Investigation Targets:
 - [ ] Improve code (maintain passing tests)
 - [ ] Confirm added tests still pass
 
+## Quality Assurance Mechanisms
+(From the work plan header — include only mechanisms relevant to this task's target files)
+- [Tool/check name] — Enforces: [what] — Config: [path]
+
 ## Operation Verification Methods
 (Derived from Verification Strategy in the work plan)
 - **Verification method**: [What to verify and how]

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]. The task file path above is also the `task_file` input. Read its `Quality Assurance Mechanisms` section as supplementary quality-check hints. 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. The task file path above is also the `task_file` input. Read its `Quality Assurance Mechanisms` section as supplementary quality-check hints. 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]. The task file path above is also the `task_file` input. Read its `Quality Assurance Mechanisms` section as supplementary quality-check hints. 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), MUST receive the executor `filesModified` list as stub-detection scope, and MUST receive the current task file as the `task_file` input so it reads the task file's `Quality Assurance Mechanisms` section as supplementary quality-check hints
+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]. The task file path above is also the `task_file` input. Read its `Quality Assurance Mechanisms` section as supplementary quality-check hints. 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

@@ -178,15 +178,15 @@ All agents MUST use this vocabulary consistently:
 
 Subagents respond in JSON format. The final response from each JSON-returning subagent must be the JSON payload itself, with no trailing prose. Key fields for orchestrator decisions:
 - **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`
+- **codebase-analyzer**: analysisScope, existingElements, dataModel, qualityAssurance, 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/dependency_version_uncertain), testsAdded, requiresTestReview
+- **quality-fixer**: Input: `task_file` (always pass the current task file path in orchestrated flows). 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
 
@@ -252,7 +252,7 @@ When receiving new features or change requests, start with requirement-analyzer.
 ### Design Flow Data Passing
 
 - Pass requirement-analyzer output and original requirements to codebase-analyzer
-- Pass codebase-analyzer JSON to technical-designer or technical-designer-frontend as `Codebase Analysis`, including `dataTransformationPipelines` when present
+- Pass codebase-analyzer JSON to technical-designer or technical-designer-frontend as `Codebase Analysis`, including `dataTransformationPipelines` and `qualityAssurance` when present
 - Pass Design Doc path to code-verifier
 - Pass code-verifier JSON to document-reviewer as `code_verification`
 
@@ -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