codex-workflows 0.4.10 → 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

@@ -9,6 +9,8 @@ description: "Add integration/E2E tests to existing codebase using Design Docs."
 2. [LOAD IF NOT ACTIVE] `integration-e2e-testing` — integration and E2E test patterns
 3. [LOAD IF NOT ACTIVE] `documentation-criteria` — document creation rules and templates
 
+**Spawn rule**: every `spawn_agent` call MUST pass `fork_turns="none"` or `fork_context=false` for context isolation.
+
 **Context**: Test addition workflow for existing implementations
 
 ## Orchestrator Definition
@@ -169,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

@@ -10,6 +10,8 @@ description: "Execute decomposed backend tasks in autonomous execution mode usin
 3. [LOAD IF NOT ACTIVE] `ai-development-guide` — AI development patterns
 4. [LOAD IF NOT ACTIVE] `subagents-orchestration-guide` — agent coordination and workflow flows
 
+**Spawn rule**: every `spawn_agent` call MUST pass `fork_turns="none"` or `fork_context=false` for context isolation.
+
 ## Orchestrator Definition
 
 **Core Identity**: "I am not a worker. I am an orchestrator." (see subagents-orchestration-guide skill)
@@ -27,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
 
@@ -36,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)
@@ -56,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
 
@@ -121,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-design/SKILL.md

@@ -9,6 +9,8 @@ description: "Execute from requirement analysis to design document creation."
 2. [LOAD IF NOT ACTIVE] `implementation-approach` — implementation strategy
 3. [LOAD IF NOT ACTIVE] `subagents-orchestration-guide` — agent coordination and workflow flows
 
+**Spawn rule**: every `spawn_agent` call MUST pass `fork_turns="none"` or `fork_context=false` for context isolation.
+
 **Context**: Dedicated to the design phase.
 
 ## Orchestrator Definition

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

@@ -8,6 +8,8 @@ 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
 
+**Spawn rule**: every `spawn_agent` call MUST pass `fork_turns="none"` or `fork_context=false` for context isolation.
+
 **Context**: Diagnosis flow to identify concrete failure points and present solutions
 
 Target problem: $ARGUMENTS

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

@@ -10,6 +10,8 @@ description: "Execute frontend tasks in autonomous execution mode using task-exe
 3. [LOAD IF NOT ACTIVE] `ai-development-guide` -- AI development patterns
 4. [LOAD IF NOT ACTIVE] `subagents-orchestration-guide` -- agent coordination and workflow flows
 
+**Spawn rule**: every `spawn_agent` call MUST pass `fork_turns="none"` or `fork_context=false` for context isolation.
+
 ## Orchestrator Definition
 
 **Core Identity**: "I am not a worker. I am an orchestrator." (see subagents-orchestration-guide skill)
@@ -27,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
 
@@ -36,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)
@@ -56,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
 
@@ -129,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-design/SKILL.md

@@ -11,6 +11,8 @@ description: "Execute from requirement analysis to frontend design document crea
 2. [LOAD IF NOT ACTIVE] `implementation-approach` -- implementation methodology
 3. [LOAD IF NOT ACTIVE] `subagents-orchestration-guide` -- agent coordination and workflow flows
 
+**Spawn rule**: every `spawn_agent` call MUST pass `fork_turns="none"` or `fork_context=false` for context isolation.
+
 ## Orchestrator Definition
 
 **Core Identity**: "I am not a worker. I am an orchestrator."

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

@@ -11,6 +11,8 @@ description: "Create frontend work plan from design document with test skeleton
 2. [LOAD IF NOT ACTIVE] `implementation-approach` -- implementation methodology
 3. [LOAD IF NOT ACTIVE] `subagents-orchestration-guide` -- agent coordination and workflow flows
 
+**Spawn rule**: every `spawn_agent` call MUST pass `fork_turns="none"` or `fork_context=false` for context isolation.
+
 ## Orchestrator Definition
 
 **Core Identity**: "I am not a worker. I am an orchestrator."
@@ -46,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

@@ -11,12 +11,15 @@ description: "Frontend Design Doc compliance and security validation with option
 2. [LOAD IF NOT ACTIVE] `testing` -- test strategy and quality gates
 3. [LOAD IF NOT ACTIVE] `ai-development-guide` -- AI development patterns
 
+**Spawn rule**: every `spawn_agent` call MUST pass `fork_turns="none"` or `fork_context=false` for context isolation.
+
 ## Execution Method
 
 - 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
 
@@ -78,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

@@ -10,6 +10,8 @@ description: "Execute decomposed fullstack tasks with layer-aware agent routing
 3. [LOAD IF NOT ACTIVE] `ai-development-guide` -- AI development patterns
 4. [LOAD IF NOT ACTIVE] `subagents-orchestration-guide` -- agent coordination and workflow flows
 
+**Spawn rule**: every `spawn_agent` call MUST pass `fork_turns="none"` or `fork_context=false` for context isolation.
+
 ## Orchestrator Definition
 
 **Core Identity**: "I am not a worker. I am an orchestrator." (see subagents-orchestration-guide skill)
@@ -37,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
 
@@ -46,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)
@@ -66,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
 
@@ -139,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.**