codex-workflows 0.4.11 → 0.5.0

package/.agents/skills/coding-rules/references/typescript.md

@@ -59,7 +59,7 @@ function isUser(value: unknown): value is User {
 - **Function Components (Mandatory)**: Official React recommendation, optimizable by modern tooling
 - **Classes Prohibited**: Class components completely deprecated (Exception: Error Boundary)
 - **Custom Hooks**: Standard pattern for logic reuse and dependency injection
-- **Component Hierarchy**: Atoms > Molecules > Organisms > Templates > Pages
+- **Component Hierarchy**: Follow the project's existing component architecture. Use Atoms > Molecules > Organisms > Templates > Pages only when the project adopts Atomic Design.
 - **Co-location**: Place tests, styles, and related files alongside components
 
 **State Management Patterns**

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

@@ -5,6 +5,7 @@ Type: feature|fix|refactor
 Estimated Duration: X days
 Estimated Impact: X files
 Related Issue/PR: #XXX (if any)
+Implementation Readiness: pending
 
 ## Related Documents
 - Design Doc(s):
@@ -66,6 +67,24 @@ Map each Design Doc technical requirement to the task or phase that covers it. U
 - Merge duplicate restatements of the same obligation from multiple DD sections into one row and cite the primary section in `DD Section`
 - Keep `scope-boundary` rows concrete: name the protected file group, component boundary, contract, or workflow that must remain unchanged
 
+## UI Spec Component -> Task Mapping
+
+Include this section when a UI Spec is among the inputs. Map each UI component section to the task(s) that implement it so task-decomposer can pass the exact UI Spec context to executor tasks. Omit this section when no UI Spec exists.
+
+| UI Spec Component (section heading) | States to Cover | Covered By Task(s) | Gap Status | Notes |
+|-------------------------------------|-----------------|--------------------|------------|-------|
+| [Use the UI Spec heading exactly as written, e.g. "Component: AlertCard"] | [default / loading / empty / error / partial] | [P1-T1, P2-T1] | covered | |
+
+**Reference key rule**: The component identifier is the UI Spec section heading verbatim. Component headings must be unique within a UI Spec.
+
+## Connection Map
+
+Include this section when implementation crosses runtime, process, deployment, or service boundaries. Omit it when the change stays inside one runtime or only uses in-process package imports.
+
+| Boundary | Caller / Producer | Callee / Consumer | Expected Signal | Covered By Task(s) |
+|----------|-------------------|-------------------|-----------------|--------------------|
+| [e.g. "web client -> API"] | [module/package initiating request or message] | [module/package receiving request or message] | [Observable evidence, e.g. HTTP 200 matching schema X] | [P1-T1, P1-T2] |
+
 ## Objective
 [Why this change is necessary, what problem it solves]
 

package/.agents/skills/documentation-criteria/references/ui-spec-template.md

@@ -59,6 +59,8 @@ Map PRD acceptance criteria to prototype references. Skip this section if no pro
 
 ### Component: [ComponentName]
 
+> Component heading uniqueness: every `Component: [ComponentName]` heading must be unique within this UI Spec. Work plans and task decomposition reference components by exact heading text.
+
 #### State x Display Matrix
 
 List only states that actually exist for this component. Remove unused rows. Include fallback or degraded states only when explicitly required by the PRD or existing behavior.

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

@@ -7,14 +7,15 @@ description: "Integration and E2E test design principles, value-based selection,
 
 ## References
 
-**E2E test design with Playwright**: See [references/e2e-design.md](references/e2e-design.md) for UI Spec-driven E2E test candidate selection and Playwright test architecture.
+**E2E test design**: See [references/e2e-design.md](references/e2e-design.md) for UI Spec-driven E2E test candidate selection and browser test architecture. Playwright is the default browser harness example; use the project's standard when different.
 
 ## Test Type Definition and Limits [MANDATORY]
 
-| Test Type | Purpose | Scope | Limit per Feature | Implementation Timing |
-|-----------|---------|-------|-------------------|----------------------|
-| Integration | Verify component interactions | Partial system integration | MAX 3 | Created alongside implementation |
-| E2E | Verify critical user journeys | Full system | MAX 1-2 | Executed in final phase only |
+| Test Type | Purpose | Scope | External Deps | Limit per Feature | Implementation Timing |
+|-----------|---------|-------|---------------|-------------------|----------------------|
+| Integration | Verify component interactions in-process | Partial system integration | Project-local dependencies | MAX 3 | Created alongside implementation |
+| fixture-e2e | Verify browser/user journey with controlled state | Browser UI + mocked backend or fixtures | No live stack required | MAX 3 | Created alongside UI implementation |
+| service-integration-e2e | Verify live-stack cross-service correctness | Full local stack | Local services, DB, queues, stubs | MAX 1-2 | Executed in final phase only |
 
 **ENFORCEMENT**: Exceeding test limits requires explicit justification
 
@@ -42,44 +43,53 @@ Value Score = (Business Value x User Frequency) + (Legal Requirement x 10) + Def
 
 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.
 
-### E2E Threshold
+### E2E Lane Thresholds
 
-- `E2E threshold = Value Score >= 50`
-- Use this threshold for non-reserved E2E selection only
+- `fixture-e2e threshold = Value Score >= 20` for non-reserved candidates
+- `service-integration-e2e threshold = Value Score > 50` for non-reserved candidates
 - Reserved-slot eligibility overrides the threshold when the candidate is the highest-value user-facing multi-step journey
 
+The fixture-e2e threshold is lower because this lane uses mocked backend or fixture-driven state, avoids live-stack setup, and has a higher per-feature budget. The service-integration-e2e threshold stays higher because live-stack tests are slower, more brittle, and more expensive to maintain.
+
 ### 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` |
+| fixture-e2e | Highest `Value Score` among fixture-e2e candidates | Select reserved user-facing journey or candidates with `Value Score >= 20` |
+| service-integration-e2e | Highest `Value Score` among service-integration-e2e candidates | Select reserved cross-service journey or candidates with `Value Score > 50` |
 
 ### E2E Candidate Rules
 
 - Treat integration and E2E as complementary coverage layers
+- Default browser-level user journeys to `fixture-e2e` when mocked backend or fixture-driven state can verify the behavior
+- Promote to `service-integration-e2e` only when correctness depends on real cross-service behavior such as DB persistence, queue/event delivery, transactional consistency, or external service contract payloads
 - 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
+- Distinguish user-facing journeys from service-internal chains; reserved fixture-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`.
+Reserve 1 fixture-e2e slot for the highest-value user-facing multi-step journey when such a journey exists, even if it does not satisfy `Value Score >= 20`.
+
+Reserve 1 service-integration-e2e slot only when that journey requires real cross-service verification that fixture-e2e cannot prove.
 
 ### 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`
+- `generatedFiles.fixtureE2e: null`
+- `generatedFiles.serviceE2e: null`
+- `e2eAbsenceReason.fixtureE2e`: one of `no_user_facing_multi_step_journey`, `all_e2e_candidates_below_threshold`, `covered_by_existing_e2e`, `budget_not_justified`
+- `e2eAbsenceReason.serviceE2e`: one of the fixture reasons plus `no_real_service_dependency`
 
 ### 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 |
+| At least one user-facing multi-step journey exists | Reserve 1 fixture-e2e slot for the highest-value such journey |
+| Journey correctness requires live cross-service behavior | Reserve or consider service-integration-e2e |
+| Remaining fixture-e2e candidate has `Value Score >= 20` | Eligible for non-reserved fixture-e2e selection |
+| Remaining service-integration-e2e candidate has `Value Score > 50` | Eligible for non-reserved service-integration-e2e selection |
+| Existing E2E already covers the same journey | Exclude and use `covered_by_existing_e2e` if no lane remains |
 
 ## Test Skeleton Specification [MANDATORY]
 
@@ -90,8 +100,9 @@ Each test MUST include the following annotations:
 ```
 // AC: [Original acceptance criteria text]
 // Behavior: [Trigger] -> [Process] -> [Observable Result]
-// @category: core-functionality | integration | edge-case | e2e
-// @dependency: none | [component names] | full-system
+// @category: core-functionality | integration | edge-case | fixture-e2e | service-integration-e2e
+// @lane: integration | fixture-e2e | service-integration-e2e
+// @dependency: none | [component names] | full-ui (mocked backend) | full-system
 // @real-dependency: [component names] (optional)
 // @complexity: low | medium | high
 // Value Score: [score]
@@ -133,7 +144,9 @@ These annotations allow work-planner to create prerequisite tasks before E2E exe
 ## Test File Naming Convention
 
 - Integration tests: `*.int.test.*` or `*.integration.test.*`
-- E2E tests: `*.e2e.test.*`
+- fixture-e2e tests: `*.fixture.e2e.test.*`
+- service-integration-e2e tests: `*.service.e2e.test.*`
+- legacy E2E tests: `*.e2e.test.*`
 
 The test runner or framework in the project determines the appropriate file extension.
 

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

@@ -1,10 +1,12 @@
-# E2E Test Design with Playwright
+# E2E Test Design
 
 ## When to Create E2E Tests
 
-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
+E2E tests target critical user journeys that span multiple interaction boundaries or require browser-level verification. Apply the parent skill rules exactly:
+- Reserve 1 fixture-e2e slot for the highest-value user-facing multi-step journey
+- Use `Value Score >= 20` for additional fixture-e2e candidates
+- Use service-integration-e2e only when correctness depends on real cross-service behavior
+- Use `Value Score > 50` for additional service-integration-e2e candidates
 
 ### Candidate Sources
 
@@ -22,6 +24,7 @@ E2E tests target **critical user journeys** that span multiple pages or require
 - Flows requiring real browser APIs (navigation, cookies, localStorage)
 - Accessibility verification requiring actual DOM rendering
 - Responsive behavior across viewports
+- Live-stack verification where DB persistence, queue/event delivery, transaction consistency, or external service payloads are the behavior under test
 
 **Exclude** (use integration tests instead):
 - Single-component state changes (use RTL)
@@ -47,20 +50,22 @@ Preconditions: [Auth state, data state]
 Verification Points:
   - [What to assert at each step]
 E2E Value Score: [calculated score]
+Lane: fixture-e2e | service-integration-e2e
 ```
 
-## Playwright Test Architecture
+## Browser Test Architecture
 
 ### Page Object Pattern
 
-Organize browser interactions through page objects for maintainability:
+Organize browser interactions through page objects or the project's equivalent harness pattern for maintainability:
 
 ```
 tests/
 ├── e2e/
 │   ├── pages/           # Page objects
 │   ├── fixtures/        # Test fixtures and helpers
-│   └── *.e2e.test.ts    # Test files
+│   ├── *.fixture.e2e.test.ts
+│   └── *.service.e2e.test.ts
 ```
 
 ### Test Isolation
@@ -83,7 +88,8 @@ When UI Spec defines responsive behavior, test critical breakpoints:
 ## Budget Enforcement
 
 Hard limits per feature (same as parent skill):
-- **E2E Tests**: MAX 1-2 tests
-- Generate the reserved user-journey E2E when eligible
-- Generate any additional E2E only when `Value Score >= 50`
+- **fixture-e2e**: MAX 3 tests
+- **service-integration-e2e**: MAX 1-2 tests
+- Generate the reserved fixture-e2e user journey when eligible
+- Generate service-integration-e2e only when live cross-service behavior must be verified
 - Prefer fewer, comprehensive journey tests over many granular tests

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

@@ -171,3 +171,10 @@ ENFORCEMENT: Commits without quality-fixer approval are invalid.
 - [ ] Tests reviewed via integration-test-reviewer (approved or fixes applied)
 - [ ] Quality check passed via quality-fixer
 - [ ] Test files committed
+- [ ] Task files created by this recipe deleted from `docs/plans/tasks/`
+
+## Final Cleanup
+
+Before the completion report, delete only the integration-test task files this recipe created for the current run. Their work is committed; `docs/plans/` is ephemeral working state.
+
+If cleanup fails, report the failed path but do not invalidate completed test work.

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

@@ -29,8 +29,24 @@ Work plan: $ARGUMENTS
 
 ## Pre-execution Prerequisites
 
-### Task File Existence Check
-Check for work plans in docs/plans/ and task files in docs/plans/tasks/.
+### Implementation Readiness Check
+
+Before task processing, locate the work plan to gate against.
+
+Resolution rule:
+1. If `$ARGUMENTS` contains a work plan path, use that exact file and derive `{plan-name}` from its basename. This takes precedence over task-file mtimes.
+2. If `$ARGUMENTS` is empty, list task files in `docs/plans/tasks/` matching the single-layer pattern `{plan-name}-task-*.md`.
+3. Exclude `*-task-prep-*.md`, `_overview-*.md`, `*-phase*-completion.md`, `review-fixes-*.md`, and `integration-tests-*-task-*.md`.
+4. If matching task files exist, infer `{plan-name}` from the most recent matching task file and use `docs/plans/{plan-name}.md`.
+5. If no matching task files exist, use the most recent non-template work plan in `docs/plans/`.
+
+Read the work plan header and apply the Implementation Readiness Marker Contract from `subagents-orchestration-guide`.
+
+### Consumed Task Set
+
+Compute the **Consumed Task Set** for this run: task files in `docs/plans/tasks/` matching `{plan-name}-task-*.md`, excluding `*-task-prep-*.md`, `_overview-*.md`, `*-phase*-completion.md`, `review-fixes-*.md`, and `integration-tests-*-task-*.md`.
+
+Every subsequent reference to task files in this recipe uses this set, not an unrestricted `docs/plans/tasks/*.md` scan.
 
 ### Task Generation Decision Flow
 
@@ -38,8 +54,8 @@ Analyze task file existence state and determine the action required:
 
 | State | Criteria | Next Action |
 |-------|----------|-------------|
-| Tasks exist | .md files in tasks/ directory | User's execution instruction serves as batch approval -> Enter autonomous execution immediately |
-| No tasks + plan exists | Plan exists but no task files | Confirm with user -> spawn task-decomposer |
+| Tasks exist | Consumed Task Set is non-empty | User's execution instruction serves as batch approval -> Enter autonomous execution immediately |
+| No tasks + plan exists | Consumed Task Set is empty but plan exists | Confirm with user -> spawn task-decomposer |
 | Neither exists | No plan or task files | Error: Prerequisites not met |
 
 ## Task Decomposition Phase (Conditional)
@@ -58,7 +74,7 @@ Generate tasks from the work plan? (y/n):
 Spawn task-decomposer agent: "Read work plan at docs/plans/[plan-name].md and decompose into atomic tasks. Output: Individual task files in docs/plans/tasks/. Granularity: 1 task = 1 commit = independently executable."
 
 ### 3. Verify Generation
-Verify generated task files exist in docs/plans/tasks/.
+Recompute the Consumed Task Set and verify it is non-empty.
 
 ## Pre-execution Checklist
 
@@ -123,6 +139,17 @@ After all task cycles finish, collect all `filesModified` from every task-execut
    - Maximum retry count is 1 verification fix cycle; if any failed verifier still fails after re-run, escalate to the user
 5. If both verifiers pass -> Proceed to completion report
 
+## Final Cleanup
+
+Before the completion report, delete only these files for the current `{plan-name}`:
+- Every file in the Consumed Task Set
+- `docs/plans/tasks/{plan-name}-phase*-completion.md`
+- `docs/plans/tasks/_overview-{plan-name}.md`
+
+Preserve the work plan itself.
+
+If cleanup fails, report the failed path but do not invalidate completed implementation work.
+
 **[STOP — BLOCKING]** Upon detecting ANY requirement changes, halt execution immediately.
 **CANNOT proceed until user explicitly confirms the change scope.**
 

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

@@ -29,8 +29,24 @@ Work plan: $ARGUMENTS
 
 ## Pre-execution Prerequisites
 
-### Task File Existence Check
-Check for work plans in docs/plans/ and task files in docs/plans/tasks/.
+### Implementation Readiness Check
+
+Before task processing, locate the work plan to gate against.
+
+Resolution rule:
+1. If `$ARGUMENTS` contains a work plan path, use that exact file and derive `{plan-name}` from its basename. This takes precedence over task-file mtimes.
+2. If `$ARGUMENTS` is empty, list task files in `docs/plans/tasks/` matching `{plan-name}-frontend-task-*.md`.
+3. Exclude `*-task-prep-*.md`, `_overview-*.md`, `*-phase*-completion.md`, `review-fixes-*.md`, and `integration-tests-*-task-*.md`.
+4. If matching task files exist, infer `{plan-name}` from the most recent matching task file and use `docs/plans/{plan-name}.md`.
+5. If no matching task files exist, use the most recent non-template work plan in `docs/plans/`.
+
+Read the work plan header and apply the Implementation Readiness Marker Contract from `subagents-orchestration-guide`.
+
+### Consumed Task Set
+
+Compute the **Consumed Task Set** for this run: task files in `docs/plans/tasks/` matching `{plan-name}-frontend-task-*.md`, excluding `*-task-prep-*.md`, `_overview-*.md`, `*-phase*-completion.md`, `review-fixes-*.md`, and `integration-tests-*-task-*.md`.
+
+Every subsequent reference to task files in this recipe uses this set, not an unrestricted `docs/plans/tasks/*.md` scan.
 
 ### Task Generation Decision Flow
 
@@ -38,8 +54,8 @@ Analyze task file existence state and determine the action required:
 
 | State | Criteria | Next Action |
 |-------|----------|-------------|
-| Tasks exist | .md files in tasks/ directory | User's execution instruction serves as batch approval -> Enter autonomous execution immediately |
-| No tasks + plan exists | Plan exists but no task files | Confirm with user -> spawn task-decomposer |
+| Tasks exist | Consumed Task Set is non-empty | User's execution instruction serves as batch approval -> Enter autonomous execution immediately |
+| No tasks + plan exists | Consumed Task Set is empty but plan exists | Confirm with user -> spawn task-decomposer |
 | Neither exists | No plan or task files | Error: Prerequisites not met |
 
 ## Task Decomposition Phase (Conditional)
@@ -58,7 +74,7 @@ Generate tasks from the work plan? (y/n):
 Spawn task-decomposer agent: "Read work plan at docs/plans/[plan-name].md and decompose into atomic tasks. Output: Individual task files in docs/plans/tasks/. Granularity: 1 task = 1 commit = independently executable"
 
 ### 3. Verify Generation
-Verify generated task files exist in docs/plans/tasks/.
+Recompute the Consumed Task Set and verify it is non-empty.
 
 ## Pre-execution Checklist
 
@@ -131,6 +147,17 @@ After all task cycles finish, collect all `filesModified` from every task-execut
    - Maximum retry count is 1 verification fix cycle; if any failed verifier still fails after re-run, escalate to the user
 5. If both verifiers pass -> Proceed to completion report
 
+## Final Cleanup
+
+Before the completion report, delete only these files for the current `{plan-name}`:
+- Every file in the Consumed Task Set
+- `docs/plans/tasks/{plan-name}-phase*-completion.md`
+- `docs/plans/tasks/_overview-{plan-name}.md`
+
+Preserve the work plan itself.
+
+If cleanup fails, report the failed path but do not invalidate completed implementation work.
+
 **[STOP -- BLOCKING]** Upon detecting ANY requirement changes, halt execution immediately.
 **CANNOT proceed until user explicitly confirms the change scope.**
 

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

@@ -48,7 +48,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 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."
+Spawn work-planner agent: "Create work plan from Design Doc at [path]. Integration test file: [path from step 2]. fixture-e2e test file: [path from step 2 or null]. service-integration-e2e test file: [path from step 2 or null]. E2E absence reasons by lane: [values from step 2 when an E2E lane is null]. Integration tests are created with each phase implementation, fixture-e2e runs alongside UI implementation, service-integration-e2e runs only in the final phase when a service E2E file exists. Include `Implementation Readiness: pending` in the work plan header."
 
 **[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-front-review/SKILL.md

@@ -18,7 +18,8 @@ description: "Frontend Design Doc compliance and security validation with option
 - Compliance validation -> performed by code-reviewer
 - Security validation -> performed by security-reviewer
 - Rule analysis -> performed by rule-advisor
-- Fix implementation -> performed by task-executor-frontend
+- Code-side fix path -> performed by task-executor-frontend
+- Design-side update path -> performed by technical-designer-frontend in update mode, then document-reviewer, then design-sync when multiple Design Docs exist
 - Quality checks -> performed by quality-fixer-frontend
 - Re-validation -> performed by code-reviewer / security-reviewer
 
@@ -80,28 +81,45 @@ Security Review: [status from security-reviewer]
   - [policy] [location]: [description] — [rationale]
   Notes: [notes from security-reviewer, if present]
 
-Execute fixes? (y/n):
+Resolve discrepancies by route:
+  c) Code-side fix
+  d) Design-side update
+  s) Skip
+
+Default: accept all recommended routes.
+
+Accepted response formats:
+- empty input -- accept every recommended route
+- `all-recommended` -- accept every recommended route
+- `all:c`, `all:d`, or `all:s` -- apply one route to every finding
+- Per-finding routes, e.g. `F1:c, F2:d, F3:s`
 ```
 
-**[STOP -- BLOCKING]** Wait for user response on whether to execute fixes.
-**CANNOT proceed with auto-fixes without user approval.**
+Before presenting results, recommend a route for each finding:
+- Use `d` when implementation intent matches the requirement but the Design Doc is stale or too narrow.
+- Use `c` when code drifted from a still-correct Design Doc, or when the finding is reliability, security, or maintainability related.
+- Use `s` only when the user explicitly accepts the current state without changes.
 
-If both pass and user selects `n`: Skip fix steps, proceed to Final Report.
+**[STOP -- BLOCKING]** Wait for user response on routes.
+**CANNOT proceed with fixes or document updates without user approval.**
 
-If user selects `y`:
+If all findings are skipped: Skip fix steps, proceed to Final Report.
 
 ## Pre-fix Metacognition
 
 1. **Spawn rule-advisor agent**: "Analyze fixes needed. Code issues: $STEP_2_OUTPUT. Security findings: $STEP_3_OUTPUT. Determine root solutions vs symptomatic treatments."
-2. **Register tasks**: Register work steps. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Create task file -> `docs/plans/tasks/review-fixes-YYYYMMDD.md`. Include both code compliance issues and security requiredFixes.
-3. **Spawn task-executor-frontend agent**: "Execute staged auto-fixes for [task-file-path]. Stop at 5 files."
-4. **Spawn quality-fixer-frontend agent**: "Execute all frontend quality checks and confirm quality gate passage"
-5. **Re-validate code-reviewer**: Spawn code-reviewer agent: "Re-validate compliance for [design-doc-path]. Prior issues: $STEP_2_OUTPUT. Measure improvement."
-6. **Re-validate security-reviewer** (only if security fixes were applied): Spawn security-reviewer agent: "Re-validate security after fixes. Prior findings: $STEP_3_OUTPUT. Design Doc: [path]. Implementation files: [union of $STEP_1_FILES and task-executor-frontend filesModified from step 3, deduplicated]."
+2. **Design-side update**: If any finding is routed to `d`, spawn technical-designer-frontend in update mode, then document-reviewer, then design-sync when multiple Design Docs exist. If both `d` and `c` routes exist, re-evaluate `c` findings against the updated Design Doc and drop any now satisfied.
+3. **Register tasks**: Register work steps. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Create task file -> `docs/plans/tasks/review-fixes-YYYYMMDD.md`. Include only code compliance issues and security requiredFixes routed to `c`.
+4. **Spawn task-executor-frontend agent**: "Execute staged auto-fixes for [task-file-path]. Stop at 5 files."
+5. **Spawn quality-fixer-frontend agent**: "Execute all frontend quality checks and confirm quality gate passage"
+6. **Re-validate code-reviewer**: Spawn code-reviewer agent: "Re-validate compliance for [design-doc-path]. Prior issues: $STEP_2_OUTPUT. Measure improvement."
+7. **Re-validate security-reviewer** (only if security fixes were applied): Spawn security-reviewer agent: "Re-validate security after fixes. Prior findings: $STEP_3_OUTPUT. Design Doc: [path]. Implementation files: [union of $STEP_1_FILES and task-executor-frontend filesModified from step 4, deduplicated]."
 
 ENFORCEMENT: Auto-fixes MUST go through quality-fixer-frontend before re-validation. Skipping quality checks invalidates fixes.
 
 ### Final Report
+Delete the review-fix task file this recipe created, if present. Its work is committed; `docs/plans/` is ephemeral working state.
+
 ```
 Code Compliance:
   Initial: [X]%

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

@@ -39,8 +39,24 @@ Work plan: $ARGUMENTS
 
 ## Pre-execution Prerequisites
 
-### Task File Existence Check
-Check for work plans in docs/plans/ and task files in docs/plans/tasks/.
+### Implementation Readiness Check
+
+Before task processing, locate the work plan to gate against.
+
+Resolution rule:
+1. If `$ARGUMENTS` contains a work plan path, use that exact file and derive `{plan-name}` from its basename. This takes precedence over task-file mtimes.
+2. If `$ARGUMENTS` is empty, list task files in `docs/plans/tasks/` matching `{plan-name}-backend-task-*.md` or `{plan-name}-frontend-task-*.md`.
+3. Exclude `*-task-prep-*.md`, `_overview-*.md`, `*-phase*-completion.md`, `review-fixes-*.md`, and `integration-tests-*-task-*.md`.
+4. If matching task files exist, infer `{plan-name}` from the most recent matching task file and use `docs/plans/{plan-name}.md`.
+5. If no matching task files exist, use the most recent non-template work plan in `docs/plans/`.
+
+Read the work plan header and apply the Implementation Readiness Marker Contract from `subagents-orchestration-guide`.
+
+### Consumed Task Set
+
+Compute the **Consumed Task Set** for this run: task files in `docs/plans/tasks/` matching `{plan-name}-backend-task-*.md` or `{plan-name}-frontend-task-*.md`, excluding `*-task-prep-*.md`, `_overview-*.md`, `*-phase*-completion.md`, `review-fixes-*.md`, and `integration-tests-*-task-*.md`.
+
+Every subsequent reference to task files in this recipe uses this set, not an unrestricted `docs/plans/tasks/*.md` scan.
 
 ### Task Generation Decision Flow
 
@@ -48,8 +64,8 @@ Analyze task file existence state and determine the action required:
 
 | State | Criteria | Next Action |
 |-------|----------|-------------|
-| Tasks exist | .md files in tasks/ directory | User's execution instruction serves as batch approval -> Enter autonomous execution immediately |
-| No tasks + plan exists | Plan exists but no task files | Confirm with user -> spawn task-decomposer |
+| Tasks exist | Consumed Task Set is non-empty | User's execution instruction serves as batch approval -> Enter autonomous execution immediately |
+| No tasks + plan exists | Consumed Task Set is empty but plan exists | Confirm with user -> spawn task-decomposer |
 | Neither exists | No plan or task files | Error: Prerequisites not met |
 
 ## Task Decomposition Phase (Conditional)
@@ -68,7 +84,7 @@ Generate tasks from the work plan? (y/n):
 Spawn task-decomposer agent: "Read work plan at docs/plans/[plan-name].md and decompose into atomic tasks. Output: Individual task files in docs/plans/tasks/. Granularity: 1 task = 1 commit = independently executable. Use layer-aware naming: {plan}-backend-task-{n}.md, {plan}-frontend-task-{n}.md based on target file paths."
 
 ### 3. Verify Generation
-Verify generated task files exist in docs/plans/tasks/.
+Recompute the Consumed Task Set and verify it is non-empty.
 
 ## Pre-execution Checklist
 
@@ -141,6 +157,17 @@ After all task cycles finish, collect all `filesModified` from every task-execut
    - Maximum retry count is 1 verification fix cycle; if any failed verifier still fails after re-run, escalate to the user
 5. If all verifiers pass -> Proceed to completion report
 
+## Final Cleanup
+
+Before the completion report, delete only these files for the current `{plan-name}`:
+- Every file in the Consumed Task Set
+- `docs/plans/tasks/{plan-name}-phase*-completion.md`
+- `docs/plans/tasks/_overview-{plan-name}.md`
+
+Preserve the work plan itself.
+
+If cleanup fails, report the failed path but do not invalidate completed implementation work.
+
 **[STOP -- BLOCKING]** Upon detecting ANY requirement changes, halt execution immediately.
 **CANNOT proceed until user explicitly confirms the change scope.**
 

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

@@ -101,6 +101,7 @@ When user responds to questions:
 **Required Flow Compliance**:
 - Run quality-fixer (layer-appropriate) before every commit
 - Obtain user approval before Edit/Write outside autonomous mode
+- Run implementation readiness preflight for the approved work plan before autonomous implementation, or continue without it only after explicit user approval
 
 ENFORCEMENT: Commits without quality-fixer approval are invalid and MUST be reverted.
 
@@ -117,6 +118,10 @@ ENFORCEMENT: Sub-agent prompts missing the constraint suffix MUST be re-issued w
 
 ## Task Execution Quality Cycle (Filename-Pattern-Based)
 
+### Implementation Readiness Gate
+
+Before executing task files, execute the Implementation Readiness Preflight Procedure from `subagents-orchestration-guide` for the approved work plan exact path. This means loading the work plan, evaluating R1-R5, resolving approved prep gaps through exact prep task files when needed, persisting the Readiness Report, and setting `Implementation Readiness: ready` or `escalated`. Then apply the Implementation Readiness Marker Contract before entering autonomous execution.
+
 **Agent routing by task filename** (see monorepo-flow.md reference):
 ```
 *-backend-task-*   -> task-executor + quality-fixer
@@ -152,9 +157,10 @@ 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 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
+- Generated fixture-e2e test file path or `null`
+- Generated service-integration-e2e test file path or `null`
+- E2E absence reason per lane when no E2E file is generated
+- Explicit note that integration tests are created simultaneously with implementation, fixture-e2e runs alongside UI implementation, and service-integration-e2e executes after all implementations only when a service 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

@@ -72,7 +72,10 @@ Follow subagents-orchestration-guide skill Large/Medium/Small scale flow exactly
 **STEP 4**: Spawn acceptance-test-generator agent → spawn work-planner agent.
 **[STOP — BLOCKING]** Present Work Plan for user approval. **CANNOT proceed until user explicitly confirms.**
 
-**STEP 5**: Enter guided autonomous execution (see Autonomous Execution Mode below) using task-executor-frontend + quality-fixer-frontend agents.
+**STEP 5**: Run implementation readiness preflight.
+Execute the Implementation Readiness Preflight Procedure from `subagents-orchestration-guide` for the approved work plan exact path. This means loading the work plan, evaluating R1-R5, resolving approved prep gaps through exact prep task files when needed, persisting the Readiness Report, and setting `Implementation Readiness: ready` or `escalated`. Apply the Implementation Readiness Marker Contract before entering autonomous execution.
+
+**STEP 6**: Enter guided autonomous execution (see Autonomous Execution Mode below) using task-executor-frontend + quality-fixer-frontend agents.
 
 ---
 
@@ -90,6 +93,10 @@ Follow subagents-orchestration-guide `references/monorepo-flow.md` for the compl
 
 After user grants "batch approval for entire implementation phase", enter autonomous execution.
 
+### Implementation Readiness Gate
+
+Before executing task files, read the associated work plan header and apply the Implementation Readiness Marker Contract from `subagents-orchestration-guide`.
+
 ### Task Execution Quality Cycle (4-Step Cycle per Task)
 
 **Agent routing by task filename** (for fullstack projects):
@@ -136,9 +143,10 @@ 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 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
+- Generated fixture-e2e test file path or `null`
+- Generated service-integration-e2e test file path or `null`
+- E2E absence reason per lane when no E2E file is generated
+- Note: integration tests are created with implementation; fixture-e2e runs alongside UI implementation; service-integration-e2e runs after all implementations when a service E2E file exists
 
 ## Completion Criteria
 

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

@@ -45,14 +45,14 @@ Follow the planning process below:
 Check for existence of design documents in docs/design/, notify user if none exist.
 Present options if multiple exist (can be specified with $ARGUMENTS).
 
-### Step 2: E2E Test Skeleton Generation Confirmation
-- Confirm with user whether to generate E2E test skeleton first
+### Step 2: Integration/E2E Test Skeleton Generation Confirmation
+- Confirm with user whether to generate integration and E2E test skeletons 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
+- If no E2E file is generated for a lane, carry the explicit lane-specific `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. If `generatedFiles.e2e` is null, use `e2eAbsenceReason` and accept the null E2E file as a valid planning input."
+- 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.fixtureE2e` or `generatedFiles.serviceE2e` is null, use the corresponding `e2eAbsenceReason` and accept the null E2E lane as a valid planning input. Include `Implementation Readiness: pending` in the work plan header."
 - Interact with user to complete plan and obtain approval for plan content
 - Clarify specific implementation steps and risks
 
@@ -61,7 +61,7 @@ Present options if multiple exist (can be specified with $ARGUMENTS).
 ## Completion Criteria
 
 - [ ] Design document identified and selected
-- [ ] E2E test skeleton generation confirmed with user (generated if requested)
+- [ ] Integration/E2E test skeleton generation confirmed with user (generated if requested)
 - [ ] Work plan created via work-planner
 - [ ] Plan content approved by user
 - [ ] All stopping points honored with user confirmation