codex-workflows 0.4.10 → 0.5.0

package/.codex/agents/acceptance-test-generator.toml

@@ -58,7 +58,8 @@ Test type definitions, budgets, and value-based selection rules are specified in
 
 Key points:
 - **Integration Tests**: MAX 3 per feature, created alongside implementation
-- **E2E Tests**: MAX 1-2 per feature, executed in final phase only
+- **fixture-e2e**: MAX 3 per feature, created alongside UI implementation, mocked backend / fixture-driven state
+- **service-integration-e2e**: MAX 1-2 per feature, executed in final phase only, live local stack
 
 ## 4-Phase Generation Process
 
@@ -123,7 +124,7 @@ For each valid AC from Phase 1:
 
 **Output**: Candidate pool with value metadata
 
-### Phase 3: Value-Based Selection (Two-Pass #2)
+### Phase 3: Value-Based Selection and Lane Assignment (Two-Pass #2)
 
 Value score and E2E selection rules are defined in **integration-e2e-testing skill**.
 
@@ -138,14 +139,15 @@ Value score and E2E selection rules are defined in **integration-e2e-testing ski
 3. **Push-Down Analysis**:
    ```
    Can this be unit-tested? → Remove from integration/E2E pool
-   Already integration-tested? → Keep E2E candidate when it validates a user-facing multi-step journey
+   Already integration-tested AND verifiable in-process? → Remove from E2E pool
    ```
-4. **Journey Classification**:
+4. **Lane Assignment**:
    ```
-   User-facing multi-step journey? → Mark as reserved-slot eligible
-   Service-internal chain only? → Not reserved-slot eligible
+   UI journey verifiable with mocked backend / fixture-driven state → fixture-e2e
+   Journey correctness depends on real cross-service behavior → service-integration-e2e
+   Service-internal chain only → Not reserved-slot eligible
    ```
-5. **Sort by Value Score** (descending order)
+5. **Sort by Value Score within each lane** (descending order)
 
 **Output**: Ranked, deduplicated candidate list
 
@@ -153,16 +155,19 @@ Value score and E2E selection rules are defined in **integration-e2e-testing ski
 
 **Hard Limits per Feature**:
 - **Integration Tests**: MAX 3 tests
-- **E2E Tests**: MAX 1-2 tests
+- **fixture-e2e**: MAX 3 tests
+- **service-integration-e2e**: MAX 1-2 tests
 
 **Selection Algorithm**:
 
 ```
 1. Sort integration candidates by Value Score (descending)
 2. Select up to 3 integration candidates
-3. Reserve 1 E2E slot for the highest-value user-facing multi-step journey, if one exists
-4. Fill any remaining E2E budget with the next highest-value E2E candidates that satisfy `Value Score >= 50`
-5. If no E2E is selected, return `generatedFiles.e2e: null` with a concrete `e2eAbsenceReason`
+3. Reserve 1 fixture-e2e slot for the highest-value user-facing multi-step journey, if one exists
+4. Reserve 1 service-integration-e2e slot only when the journey needs real cross-service verification
+5. Fill remaining fixture-e2e budget with candidates that satisfy `Value Score >= 20`
+6. Fill remaining service-integration-e2e budget with candidates that satisfy `Value Score > 50`
+7. If a lane emits no tests, return its generated file as `null` with a concrete lane-specific absence reason
 ```
 
 **Output**: Final test set
@@ -198,24 +203,46 @@ Adapt comment syntax to the project's language when generating annotations.
   [Test: 'AC1: Failed payment displays error without creating order']
 ```
 
-### E2E Test File
+### fixture-e2e Test File
 
 ```
-// [Feature Name] E2E Test - Design Doc: [filename]
-// Generated: [date] | Budget Used: 1/2 E2E
-// Test Type: End-to-End Test
-// Implementation Timing: After all feature implementations complete
+// [Feature Name] fixture-e2e Test - Design Doc: [filename]
+// Generated: [date] | Budget Used: 1/3 fixture-e2e
+// Test Type: Browser UI with mocked backend / fixture-driven state
+// Implementation Timing: Alongside UI implementation
 
 [Import statement using detected test framework]
 
 [Test suite using detected framework syntax]
-  // User Journey: Complete purchase flow (browse → add to cart → checkout → payment → confirmation)
-  // Value Score: 120 | Business Value: 10 (business-critical) | Frequency: 10 (core flow) | Legal: true (PCI compliance)
-  // Verification: End-to-end user experience from product selection to order confirmation
-  // @category: e2e
+  // User Journey: Dismiss card -> Undo banner appears -> Undo restores card
+  // Value Score: 60 | Business Value: 6 | Frequency: 7 | Defect Detection: 8
+  // Verification: Browser-visible state transitions with mocked backend state
+  // @category: fixture-e2e
+  // @lane: fixture-e2e
+  // @dependency: full-ui (mocked backend)
+  // @complexity: medium
+  [Test: 'User Journey: Dismiss and undo restores the card']
+```
+
+### service-integration-e2e Test File
+
+```
+// [Feature Name] service-integration-e2e Test - Design Doc: [filename]
+// Generated: [date] | Budget Used: 1/2 service-integration-e2e
+// Test Type: End-to-end against running local stack
+// Implementation Timing: Final phase only
+
+[Import statement using detected test framework]
+
+[Test suite using detected framework syntax]
+  // User Journey: Complete purchase flow (browse -> checkout -> payment -> confirmation persisted)
+  // Value Score: 120 | Business Value: 10 (business-critical) | Frequency: 10 (core flow) | Legal: true
+  // Verification: Order persists in DB and confirmation event is emitted
+  // @category: service-integration-e2e
+  // @lane: service-integration-e2e
   // @dependency: full-system
   // @complexity: high
-  [Test: 'User Journey: Complete product purchase from browse to confirmation email']
+  [Test: 'User Journey: Complete product purchase persists order and emits confirmation']
 ```
 
 ### Generation Report
@@ -226,13 +253,18 @@ Adapt comment syntax to the project's language when generating annotations.
   "feature": "[feature name]",
   "generatedFiles": {
     "integration": "[path]/[feature].int.test.[ext]",
-    "e2e": null
+    "fixtureE2e": null,
+    "serviceE2e": null
   },
   "budgetUsage": {
     "integration": "2/3",
-    "e2e": "0/2"
+    "fixtureE2e": "0/3",
+    "serviceE2e": "0/2"
   },
-  "e2eAbsenceReason": "all_e2e_candidates_below_threshold"
+  "e2eAbsenceReason": {
+    "fixtureE2e": "all_e2e_candidates_below_threshold",
+    "serviceE2e": "no_real_service_dependency"
+  }
 }
 ```
 
@@ -242,13 +274,18 @@ Adapt comment syntax to the project's language when generating annotations.
   "feature": "[feature name]",
   "generatedFiles": {
     "integration": "[path]/[feature].int.test.[ext]",
-    "e2e": "[path]/[feature].e2e.test.[ext]"
+    "fixtureE2e": "[path]/[feature].fixture.e2e.test.[ext]",
+    "serviceE2e": "[path]/[feature].service.e2e.test.[ext]"
   },
   "budgetUsage": {
     "integration": "2/3",
-    "e2e": "1/2"
+    "fixtureE2e": "1/3",
+    "serviceE2e": "1/2"
   },
-  "e2eAbsenceReason": null
+  "e2eAbsenceReason": {
+    "fixtureE2e": null,
+    "serviceE2e": null
+  }
 }
 ```
 
@@ -256,8 +293,9 @@ Adapt comment syntax to the project's language when generating annotations.
 
 Each test case MUST have the following standard annotations for test implementation planning:
 
-- **@category**: core-functionality | integration | edge-case | ux
-- **@dependency**: none | [component names] | full-system
+- **@category**: core-functionality | integration | edge-case | ux | fixture-e2e | service-integration-e2e
+- **@lane**: integration | fixture-e2e | service-integration-e2e
+- **@dependency**: none | [component names] | full-ui (mocked backend) | full-system
 - **@complexity**: low | medium | high
 
 These annotations are used when planning and prioritizing test implementation.
@@ -282,7 +320,7 @@ These annotations are used when planning and prioritizing test implementation.
 
 ### Auto-processable
 - **Directory Absent**: Auto-create appropriate directory following detected test structure
-- **No E2E Selected**: Valid outcome when accompanied by `e2eAbsenceReason`
+- **No E2E Selected**: Valid outcome when accompanied by lane-specific `e2eAbsenceReason`
 - **Budget Exceeded by Critical Test**: Report to user
 
 ### Escalation Required
@@ -316,7 +354,7 @@ These annotations are used when planning and prioritizing test implementation.
 - **Post-execution**:
   - Completeness of selected tests
   - Dependency validity verified
-  - Integration tests and E2E tests generated in separate files
+  - Integration tests, fixture-e2e tests, and service-integration-e2e tests generated in separate files when selected
   - Generation report completeness
 
 ## Completion Gate [BLOCKING]

package/.codex/agents/task-decomposer.toml

@@ -130,8 +130,12 @@ Decompose tasks based on implementation strategy patterns determined in implemen
    |---|---|
    | Existing code modification | Files being changed, adjacent tests, relevant Design Doc sections |
    | New feature/component | Adjacent implementations in the same layer/domain, interface-defining Design Doc sections |
-   | Integration/E2E test work | Test skeleton file, target implementation under test, existing fixture/auth/setup patterns |
-   | E2E environment/setup work | Current environment config, startup scripts, seed/fixture scripts, auth flow references |
+   | Frontend component implementation | UI Spec component section cited by the work plan's UI Spec Component -> Task Mapping, interface-defining Design Doc sections, adjacent components |
+   | Frontend integration / fixture-e2e test work | UI Spec component section including state and interaction tables, test skeleton file, target implementation, fixture data, browser harness config |
+   | Integration test work | Test skeleton file, target implementation under test, existing fixture/auth/setup patterns |
+   | fixture-e2e environment/setup work | Existing fixture data, API mock layer, browser harness configuration |
+   | service-integration-e2e environment/setup work | Current environment config, startup scripts, seed scripts, auth flow references, external service stubs |
+   | Cross-boundary implementation | Connection Map rows touching the task target files, caller/producer module, callee/consumer module, expected signal, contract definition |
    | Bug fix/refactor | Affected code paths, failing tests, reproduction-related files |
    | Behavior replacement/rewrite | Existing implementation being replaced, observable outputs, Verification Strategy section in the Design Doc |
 
@@ -140,6 +144,8 @@ Decompose tasks based on implementation strategy patterns determined in implemen
    - Investigation Targets are file paths to read, not actions to perform
    - Use specific paths with optional hints such as `docs/design/payments.md (§ Retry Flow)` or `src/orders/service.ts (createOrder)`
    - When test skeletons exist, include them explicitly
+   - When the work plan contains a UI Spec Component -> Task Mapping table, propagate matching component sections to every task listed in the row
+   - When the work plan contains a Connection Map, propagate boundary rows touching the task's target files to every task on either side of the boundary
    - When a task matches multiple natures, include Investigation Targets from all matching rows and deduplicate overlaps
 
 7. **Implementation Pattern Consistency**
@@ -185,6 +191,25 @@ When the work plan includes a `Design-to-Plan Traceability` section:
 5. **Verification integrity**: For `verification` rows, ensure the corresponding task file includes the required comparison or verification method in Operation Verification Methods.
 6. **Prerequisite integrity**: For `prerequisite` rows, place setup, migration, seed, auth, or environment work before dependent implementation tasks.
 
+## UI Spec Propagation
+
+When the work plan includes a `UI Spec Component -> Task Mapping` section:
+
+1. For each row, locate the task IDs listed in `Covered By Task(s)`.
+2. Add the component section heading to those task files' Investigation Targets.
+3. Include the states listed in `States to Cover` in Investigation Notes and Operation Verification Methods.
+4. Preserve `gap` rows as planning issues and surface them to the caller.
+5. If a task implements UI but no component mapping row covers it, add a warning in the decomposition report.
+
+## Connection Map Propagation
+
+When the work plan includes a `Connection Map` section:
+
+1. For each boundary row, locate all tasks listed in `Covered By Task(s)`.
+2. Add the caller/producer module, callee/consumer module, serialized contract, and expected signal to each listed task's Investigation Targets or Notes.
+3. For tasks on one side of a boundary, include an Operation Verification Method that observes the expected signal from the other side.
+4. Propagate only boundary rows explicitly mapped in the work plan.
+
 ## Task File Template
 
 See task template in documentation-criteria skill for details.

package/.codex/agents/task-executor-frontend.toml

@@ -133,7 +133,9 @@ Use the appropriate run command based on the `packageManager` field in package.j
 
 ### 1. Task Selection
 
-Select and execute files with pattern `docs/plans/tasks/*-task-*.md` that have uncompleted checkboxes `[ ]` remaining
+If the orchestrator prompt provides a task file path, execute only that exact task file. Do not scan or select any other task file.
+
+When no task file path is provided, select and execute files with pattern `docs/plans/tasks/*-task-*.md` that have uncompleted checkboxes `[ ]` remaining.
 
 ### 2. Task Background Understanding
 #### Investigation Targets (Required when present)
@@ -185,7 +187,7 @@ This is a repeated self-check during implementation, not a one-time pre-implemen
 
 **Implementation procedure for each checkbox item**:
 1. **Red**: Create React Testing Library test for that checkbox item (failing state)
-   ※For integration tests (multiple components), create and execute simultaneously with implementation; E2E tests are executed in final phase only
+   ※For integration tests and fixture-e2e tests, create and execute with the related UI implementation; service-integration-e2e tests are executed in final phase only. Legacy E2E tests without `@lane` are treated as service-integration-e2e unless the task file or skeleton clearly states mocked backend / fixture-driven execution.
 2. **Green**: Implement minimum code to pass test (React function component)
 3. **Refactor**: Improve code quality (readability, maintainability, React best practices)
 4. **Progress Update [MANDATORY]**: Execute the following in sequence (cannot be omitted)
@@ -211,16 +213,11 @@ Return one of the following as the final response (see Structured Response Speci
 - `status: "completed"` — task fully implemented
 - `status: "escalation_needed"` — design deviation or similar component discovered
 
-## Research Task Deliverables
-
-Research/analysis tasks create deliverable files specified in metadata "Provides".
-Examples: `docs/plans/analysis/component-research.md`, `docs/plans/analysis/api-integration.md`
-
 ## Structured Response Specification
 
 ### Field Specifications
 
-**requiresTestReview**: Set to `true` when the task added or updated integration tests or E2E tests. Set to `false` for unit-test-only tasks or tasks with no tests.
+**requiresTestReview**: Set to `true` when the task added or updated integration tests, fixture-e2e tests, or service-integration-e2e tests. Set to `false` for unit-test-only tasks or tasks with no tests.
 
 ### 1. Task Completion Response
 Report in the following JSON format upon task completion (**without executing quality checks or commits**, delegating to quality assurance process):
@@ -380,9 +377,6 @@ When repository-wide verification is insufficient to determine the appropriate d
 
 **ENFORCEMENT**: HALT if any gate unchecked. Return `status: "escalation_needed"` to caller.
 
-## Completion Criteria
-
-- [ ] Final response is a single JSON with status `completed` or `escalation_needed`
 """
 
 [[skills.config]]

package/.codex/agents/task-executor.toml

@@ -133,7 +133,9 @@ Skill Status:
 
 ### 1. Task Selection
 
-Select and execute files with pattern `docs/plans/tasks/*-task-*.md` that have uncompleted checkboxes `[ ]` remaining
+If the orchestrator prompt provides a task file path, execute only that exact task file. Do not scan or select any other task file.
+
+When no task file path is provided, select and execute files with pattern `docs/plans/tasks/*-task-*.md` that have uncompleted checkboxes `[ ]` remaining.
 
 ### 2. Task Background Understanding
 #### Investigation Targets (Required when present)
@@ -194,7 +196,9 @@ This is a repeated self-check during implementation, not a one-time pre-implemen
 **Test types**:
 - Unit tests: RED-GREEN-REFACTOR cycle
 - Integration tests: Create and execute with implementation
-- E2E tests: Execute only (in final phase)
+- fixture-e2e tests: Create and execute with the related UI/browser task when the task file specifies that lane
+- service-integration-e2e tests: Execute only in final phase when the task file specifies that lane
+- legacy E2E tests without `@lane`: Treat as service-integration-e2e unless the task file or skeleton clearly states mocked backend / fixture-driven execution
 
 #### Operation Verification
 - Execute "Operation Verification Methods" section in task
@@ -212,16 +216,11 @@ Return one of the following as the final response (see Structured Response Speci
 - `status: "completed"` — task fully implemented
 - `status: "escalation_needed"` — design deviation or similar function discovered
 
-## Research Task Deliverables
-
-Research/analysis tasks create deliverable files specified in metadata "Provides".
-Examples: `docs/plans/analysis/research-results.md`, `docs/plans/analysis/api-spec.md`
-
 ## Structured Response Specification
 
 ### Field Specifications
 
-**requiresTestReview**: Set to `true` when the task added or updated integration tests or E2E tests. Set to `false` for unit-test-only tasks or tasks with no tests.
+**requiresTestReview**: Set to `true` when the task added or updated integration tests, fixture-e2e tests, or service-integration-e2e tests. Set to `false` for unit-test-only tasks or tasks with no tests.
 
 ### 1. Task Completion Response
 Report in the following JSON format upon task completion (**without executing quality checks or commits**, delegating to quality assurance process):
@@ -364,11 +363,9 @@ When repository-wide verification is insufficient to determine the appropriate d
 ```
 
 ## Execution Principles
-
 - Follow RED-GREEN-REFACTOR (see the principles in testing skill)
 - Update progress checkboxes per step
-- Escalate when: design deviation, similar functions found, investigation target not found, test environment missing
-- Escalate when dependency version or representative pattern choice cannot be determined from repository evidence
+- Escalate when design deviation, similar functions, missing investigation targets/test environment, or uncertain dependency/pattern choice blocks repository-evidence-based implementation
 - Stop after implementation and test creation — quality checks and commits are handled separately
 
 ## Completion Gate [BLOCKING]
@@ -383,9 +380,6 @@ When repository-wide verification is insufficient to determine the appropriate d
 
 **ENFORCEMENT**: HALT if any gate unchecked. Return `status: "escalation_needed"` to caller.
 
-## Completion Criteria
-
-- [ ] Final response is a single JSON with status `completed` or `escalation_needed`
 """
 
 [[skills.config]]

package/.codex/agents/technical-designer-frontend.toml

@@ -119,7 +119,7 @@ Must be performed when creating Design Doc:
 1. **Approach Selection Criteria**
    - Execute Phase 1-4 of implementation-approach skill to select strategy
    - **Vertical Slice**: Complete by feature unit, minimal component dependencies, early value delivery
-   - **Horizontal Slice**: Implementation by component layer (Atoms→Molecules→Organisms), important common components, design consistency priority
+   - **Horizontal Slice**: Implementation by the project's component layering convention. Use Atomic Design layer names only when the project already adopts Atomic Design.
    - **Hybrid**: Composite, handles complex requirements
    - Document selection reason (record results of metacognitive strategy selection process)
 
@@ -267,7 +267,7 @@ Implementation sample creation checklist:
 **Design Doc**: Component hierarchy diagram and data flow diagram are mandatory. Add state transition diagram and sequence diagram for complex cases.
 
 **React Diagrams**:
-- Component hierarchy (Atoms → Molecules → Organisms → Templates → Pages)
+- Component hierarchy (use the project's existing component architecture; Atomic Design labels apply only when adopted)
 - Props flow diagram (parent → child data flow)
 - State management diagram (Context, custom hooks)
 - User interaction flow (click → state update → re-render)

package/.codex/agents/work-planner.toml

@@ -43,7 +43,8 @@ Skill Status:
 5. Place test implementation and execution appropriately for each phase
 6. Concretize risks and countermeasures
 7. Create explicit Design-to-Plan Traceability so Design Doc technical requirements are covered without silent omission
-8. Document in progress-trackable format
+8. Propagate UI Spec component and runtime boundary context into the plan so task decomposition can pass it to executors
+9. Document in progress-trackable format
 
 ## Input Parameters
 
@@ -53,8 +54,8 @@ Skill Status:
 - **prd** (optional): Path to PRD document
 - **adr** (optional): Path to ADR document
 - **testSkeletons** (optional): Paths to integration/E2E test skeleton files from acceptance-test-generator
-  - `generatedFiles.e2e` may be `null` when no E2E skeleton is intentionally generated
-  - When provided, carry `e2eAbsenceReason` into the work plan and treat it as an explicit planning input
+  - `generatedFiles.fixtureE2e` and `generatedFiles.serviceE2e` may be `null` when a lane is intentionally not generated
+  - When provided, carry lane-specific `e2eAbsenceReason` into the work plan and treat it as an explicit planning input
 - **updateContext** (update mode only): Path to existing plan, reason for changes
 
 ## Workflow
@@ -86,7 +87,9 @@ Choose Strategy A (TDD) if test skeletons are provided, Strategy B (implementati
 - Place tasks with the lowest dependencies in earlier phases
 - Map normalized verification timing to phases as follows: `phase_1` -> earliest implementation phase, `per_phase` -> each relevant phase, `integration_phase` -> integration phase, `final_phase` -> final Quality Assurance phase
 - Include verification tasks in the phase corresponding to the Verification Strategy timing
-- When test skeletons are provided, place integration test implementation based on `@dependency` metadata from test skeletons (see Test Design Information Processing > Step 2) and place E2E test execution in the final phase
+- When test skeletons are provided, place integration test implementation based on `@dependency` metadata from test skeletons (see Test Design Information Processing > Step 2)
+- When fixture-e2e skeletons are provided, place creation/execution alongside the relevant UI implementation phase
+- When service-integration-e2e skeletons are provided, place execution-only tasks in the final phase
 - When test skeletons are not provided, include test implementation tasks based on Design Doc acceptance criteria
 - Final phase is always Quality Assurance
 
@@ -115,12 +118,37 @@ Traceability rules:
 - Any `gap` without justification is an error
 - Any justified `gap` must be flagged for user confirmation before plan approval
 
+### 5a. Map UI Spec Components to Tasks
+
+When a UI Spec is provided, map each documented component to the task(s) that implement it or test it.
+
+Rules:
+- Use the UI Spec component section heading exactly as written.
+- Identify required states such as default, loading, empty, error, and partial.
+- Record the mapping in the `UI Spec Component -> Task Mapping` table from the plan template.
+- Mark components with no covering task as `gap` with justification and user confirmation before approval.
+
+### 5b. Map Runtime Boundaries to Tasks
+
+When implementation crosses runtime, process, deployment, or service boundaries, create a `Connection Map`.
+
+A boundary qualifies only when all of the following hold:
+- The two sides run in separate processes, services, runtimes, or deployed artifacts.
+- A serialized contract crosses the boundary, such as HTTP, RPC, event payload, queue message, or webhook payload.
+- A failure on one side creates an observable signal on the other side, such as a status code, timeout, missing field, dropped message, or persisted row.
+
+Map only boundaries satisfying all three qualifications above: separate runtime, serialized contract, and observable cross-side signal.
+
+For each boundary, record the caller/producer, callee/consumer, expected signal, and covering tasks in the `Connection Map` table.
+
 ### 6. Define Tasks with Completion Criteria
 For each task, derive completion criteria from Design Doc acceptance criteria. Apply the 3-element completion definition (Implementation Complete, Quality Complete, Integration Complete).
 
 ### 7. Produce Work Plan Document
 Write the work plan following the plan template from documentation-criteria skill. Include Phase Structure Diagram and Task Dependency Diagram (mermaid).
 
+The plan header MUST include `Implementation Readiness: pending`. This marker is promoted by the implementation-readiness orchestration before build execution.
+
 ## Work Plan Output Format
 
 - Storage location and naming convention follow the principles in documentation-criteria skill
@@ -161,7 +189,8 @@ Create Red state tests based on unit test definitions provided from previous pro
 **Test Implementation Timing and Placement**:
 - Unit tests: Phase 0 Red → Green during implementation
 - Integration tests: Create and execute at completion of relevant feature implementation (include in phase tasks like "[Feature name] implementation with integration test creation")
-- E2E tests: Execute only in final phase (execution only, no separate implementation needed)
+- fixture-e2e tests: Create and execute alongside the relevant UI feature implementation
+- service-integration-e2e tests: Execute only in final phase
 
 #### Meta Information Utilization
 Analyze meta information (@category, @dependency, @complexity, etc.) included in test definitions,
@@ -181,6 +210,7 @@ Read available test skeleton files (integration tests, and E2E tests only when p
 
 **Comment patterns to extract**:
 - `// @category:` → Test classification (core-functionality, edge-case, e2e, etc.)
+- `// @lane:` → Test lane (integration, fixture-e2e, service-integration-e2e)
 - `// @dependency:` → Dependent components (material for phase placement decisions)
 - `// @complexity:` → Complexity (high/medium/low, material for effort estimation)
 - `// Value Score:` → Priority judgment
@@ -190,6 +220,7 @@ Read available test skeleton files (integration tests, and E2E tests only when p
 1. **Dependency-based Phase Placement**
    - `// @dependency: none` → Place in earlier phases
    - `// @dependency: [component name]` → Place in phase after dependent component implementation
+   - `// @dependency: full-ui (mocked backend)` → Place alongside UI implementation
    - `// @dependency: full-system` → Place in final phase
 
 2. **Complexity-based Effort Estimation**
@@ -198,32 +229,36 @@ Read available test skeleton files (integration tests, and E2E tests only when p
 
 #### Step 3: Extract Environment Prerequisites from E2E Skeletons
 
-When E2E test skeletons are provided, first identify the E2E skeleton subset using file naming conventions such as `*.e2e.test.*` and then scan only those files for environment prerequisites in two stages:
+When E2E test skeletons are provided, first identify the E2E skeleton subset using file naming conventions such as `*.fixture.e2e.test.*`, `*.service.e2e.test.*`, or `*.e2e.test.*`, then scan only those files for environment prerequisites in two stages:
 
 **Stage 1: Detect precondition patterns**
 - `Preconditions:` annotations mentioning seed data, test users, subscriptions, or required DB state
+- `@lane: fixture-e2e` or `@dependency: full-ui (mocked backend)` combined with fixture loaders or API mock handlers
 - `@dependency: full-system` combined with auth/login setup
 - Environment variable references such as `E2E_*` or `TEST_*`
 - External service dependencies that require mock/intercept or a running local dependency
 
 **Stage 2: Generate Phase 0 setup tasks**
-- Seed data → Add a Phase 0 task for fixture or seed preparation
-- Auth fixture/login state → Add a Phase 0 task for auth setup
-- External service mocks → Add a Phase 0 task for mock/intercept setup
-- Environment configuration → Add a Phase 0 task for env var or local service configuration
+- fixture-e2e fixture data → Add a Phase 0 task for fixture state files
+- fixture-e2e mocked backend → Add a Phase 0 task for the project's API mock layer
+- fixture-e2e browser harness → Add a Phase 0 task for Playwright or the project's browser harness
+- service-integration-e2e seed data → Add a Phase 0 task for seed preparation
+- service-integration-e2e auth fixture/login state → Add a Phase 0 task for auth setup
+- service-integration-e2e external service stubs → Add a Phase 0 task for stubs or intercepts
+- service-integration-e2e environment configuration → Add a Phase 0 task for env vars and local service startup
 - Other prerequisites → Add a matching setup task with clear traceability to the E2E skeleton
 
-Place these setup tasks before implementation and annotate them as E2E setup work.
+Place these setup tasks before implementation and annotate them as E2E setup work with the relevant lane.
 
 #### Step 3a: E2E Absence Handling
 
-When `generatedFiles.e2e` is `null`:
-- Require `e2eAbsenceReason` from the generator output
+When an E2E lane generated file is `null`:
+- Require the corresponding lane-specific `e2eAbsenceReason` from the generator output
 - Record the absence reason in the work plan header
-- Skip E2E prerequisite extraction and E2E execution task creation
-- Accept the null E2E file as a valid planning input when a concrete `e2eAbsenceReason` is present
+- Skip prerequisite extraction and execution task creation for that lane
+- Accept the null E2E lane as a valid planning input when a concrete absence reason is present
 
-When `generatedFiles.e2e` is `null` and `e2eAbsenceReason` is missing:
+When an E2E lane generated file is `null` and its `e2eAbsenceReason` is missing:
 - Flag a planning gap for user confirmation before plan approval
 
 #### Step 4: Classify and Place Tests
@@ -232,7 +267,9 @@ When `generatedFiles.e2e` is `null` and `e2eAbsenceReason` is missing:
 - Setup items (Mock preparation, measurement tools, Helpers, etc.) → Prioritize in Phase 1
 - Unit tests (individual functions) → Start from Phase 0 with Red-Green-Refactor
 - Integration tests → Place as create/execute tasks when relevant feature implementation is complete
-- E2E tests → Place as execute-only tasks in final phase when an E2E skeleton exists
+- fixture-e2e tests → Place as create/execute tasks alongside relevant UI implementation
+- service-integration-e2e tests → Place as execute-only tasks in final phase when a skeleton exists
+- legacy E2E tests without a lane → Treat as service-integration-e2e unless the skeleton clearly uses mocked backend fixtures
 - Non-functional requirement tests (performance, UX, etc.) → Place in quality assurance phase
 - Risk levels ("high risk", "required", etc.) → Move to earlier phases
 

package/README.md

@@ -27,8 +27,6 @@ $recipe-implement Add user authentication with JWT
 
 Small changes stay lightweight. Larger tasks get structure: requirements → design → task decomposition → TDD implementation → quality gates.
 
-codex-workflows is the Codex-native counterpart of [Claude Code Workflows](https://github.com/shinpr/claude-code-workflows): same document-driven development style, adapted for Codex CLI, subagents, and GPT models.
-
 ---
 
 ## Why codex-workflows?
@@ -159,6 +157,7 @@ Invoke recipes with `$recipe-name` in Codex. Type `$recipe-` and use tab complet
 | `$recipe-task` | Single task with rule selection | Bug fixes, small changes |
 | `$recipe-design` | Requirements → ADR/Design Doc | Architecture planning |
 | `$recipe-plan` | Design Doc → test skeletons → work plan | Planning phase, including nullable E2E skeleton handling |
+| `$recipe-prepare-implementation` | Verify work plan readiness and resolve prep gaps | Pre-build check that the plan is implementable |
 | `$recipe-build` | Execute backend tasks autonomously | Resume backend implementation |
 | `$recipe-review` | Design Doc compliance and security validation with auto-fixes | Post-implementation check |
 | `$recipe-diagnose` | Problem investigation → failure-point verification → solution | Bug investigation |
@@ -182,6 +181,16 @@ Invoke recipes with `$recipe-name` in Codex. Type `$recipe-` and use tab complet
 | `$recipe-fullstack-implement` | Full lifecycle with separate Design Docs per layer | Cross-layer features |
 | `$recipe-fullstack-build` | Execute tasks with layer-aware agent routing | Resume cross-layer implementation |
 
+### Working State
+
+Recipes use `docs/plans/` as ephemeral working state for work plans, decomposed task files, prep tasks, review-fix tasks, and intermediate analysis files. Add it to your project's `.gitignore` unless your team intentionally wants to review those transient files:
+
+```gitignore
+docs/plans/
+```
+
+PRDs, ADRs, UI Specs, and Design Docs are durable project documents and are intended to be committed.
+
 ### Examples
 
 **Full feature development:**
@@ -315,6 +324,7 @@ your-project/
 │   ├── recipe-design/
 │   ├── recipe-build/
 │   ├── recipe-plan/
+│   ├── recipe-prepare-implementation/
 │   ├── recipe-review/
 │   ├── recipe-diagnose/
 │   ├── recipe-task/

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "codex-workflows",
-  "version": "0.4.10",
+  "version": "0.5.0",
   "description": "Task-oriented agentic coding framework for OpenAI Codex CLI — skills, recipes, and subagents for structured development workflows",
   "license": "MIT",
   "author": "Shinsuke Kagawa",