codex-workflows 0.4.11 → 0.6.0

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

@@ -4,7 +4,7 @@
 skills:
   coding-rules:
     skill: "coding-rules"
-    tags: [implementation, code-quality, refactoring, clean-code, maintainability, function-design, error-handling, parameterized-dependencies, performance, security]
+    tags: [implementation, code-quality, refactoring, clean-code, maintainability, function-design, error-handling, parameterized-dependencies, reference-representativeness, performance, security]
     typical-use: "Language-agnostic code creation, modification, and refactoring principles applicable to all programming languages"
     size: medium
     key-references:
@@ -14,23 +14,26 @@ skills:
       - "Refactoring - Martin Fowler"
       - "Single Responsibility Principle - SOLID"
     sections:
+      - "Language-Specific References"
       - "Core Philosophy [MANDATORY]"
       - "Code Quality [MANDATORY]"
       - "Function Design [MANDATORY]"
       - "Error Handling [MANDATORY]"
       - "Dependency Management"
+      - "Reference Representativeness"
       - "Performance"
       - "Code Organization"
       - "Commenting Principles"
       - "Refactoring [SAFE CHANGE PROTOCOL]"
-      - "Security (Secure Defaults, Input and Output Boundaries, Access Control, Knowledge Cutoff Supplement)"
+      - "Security"
       - "Version Control [MANDATORY]"
     references:
       - "references/typescript.md"
+      - "references/security-checks.md"
 
   testing:
     skill: "testing"
-    tags: [testing, tdd, quality, unit-testing, integration-testing, e2e-testing, test-design, coverage, mocking, test-independence, ci-cd, test-quality-criteria]
+    tags: [testing, tdd, quality, unit-testing, integration-testing, e2e-testing, data-layer-testing, test-design, coverage, mocking, test-independence, ci-cd, test-quality-criteria]
     typical-use: "Universal testing principles, TDD practice, test quality criteria, test creation and quality assurance for all programming languages"
     size: large
     key-references:
@@ -39,6 +42,7 @@ skills:
       - "AAA Pattern - Arrange-Act-Assert"
       - "Test Pyramid - Mike Cohn"
     sections:
+      - "Language-Specific References"
       - "Core Testing Philosophy"
       - "TDD Process [MANDATORY for all code changes]"
       - "Quality Requirements [MANDATORY]"
@@ -46,6 +50,7 @@ skills:
       - "Test Design Principles"
       - "Test Independence"
       - "Mocking and Test Doubles"
+      - "Data Layer Testing"
       - "Test Quality Practices [MANDATORY]"
       - "What to Test"
       - "Test Quality Criteria [MANDATORY]"
@@ -68,19 +73,23 @@ skills:
       - "DRY Principle - The Pragmatic Programmer"
       - "YAGNI Principle - Extreme Programming"
     sections:
+      - "Language-Specific References"
       - "Technical Anti-patterns (Red Flag Patterns) [MANDATORY]"
       - "Fail-Fast Fallback Design Principles"
       - "Rule of Three - Criteria for Code Duplication"
       - "Common Failure Patterns and Avoidance Methods"
       - "Debugging Techniques"
+      - "Quality Assurance Mechanism Awareness"
       - "Quality Check Workflow [MANDATORY]"
       - "Situations Requiring Technical Decisions"
       - "Implementation Completeness Assurance"
       - "Impact Analysis"
+    references:
+      - "references/frontend.md"
 
   documentation-criteria:
     skill: "documentation-criteria"
-    tags: [documentation, decision-making, adr, prd, design-doc, planning, process, scale-assessment]
+    tags: [documentation, decision-making, adr, prd, design-doc, ui-spec, work-plan, templates, planning, process, scale-assessment]
     typical-use: "Scale assessment at implementation start, document creation criteria, ADR/PRD/Design Doc/Work Plan creation standards"
     size: medium
     key-references:
@@ -98,6 +107,13 @@ skills:
       - "AI Automation Rules [MANDATORY]"
       - "Diagram Requirements"
       - "Common ADR Relationships"
+    references:
+      - "references/prd-template.md"
+      - "references/adr-template.md"
+      - "references/ui-spec-template.md"
+      - "references/design-template.md"
+      - "references/plan-template.md"
+      - "references/task-template.md"
 
   implementation-approach:
     skill: "implementation-approach"
@@ -117,7 +133,7 @@ skills:
 
   integration-e2e-testing:
     skill: "integration-e2e-testing"
-    tags: [testing, integration-testing, e2e-testing, test-design, behavior-first, roi, test-skeleton, ears-format]
+    tags: [testing, integration-testing, e2e-testing, fixture-e2e, service-integration-e2e, e2e-absence-reason, test-design, behavior-first, roi, test-skeleton, ears-format]
     typical-use: "Integration and E2E test design principles, value-based test selection, behavior-first approach, test skeleton specification"
     size: medium
     key-references:
@@ -133,11 +149,13 @@ skills:
       - "Test File Naming Convention"
       - "Review Criteria"
       - "Quality Standards [MANDATORY]"
+    references:
+      - "references/e2e-design.md"
 
   subagents-orchestration-guide:
     skill: "subagents-orchestration-guide"
-    tags: [orchestration, workflow, subagents, autonomous-execution, planning, design-flow, implementation-flow]
-    typical-use: "Orchestrating subagents through implementation workflows, scale determination, stop points, autonomous execution mode"
+    tags: [orchestration, workflow, subagents, context-isolation, autonomous-execution, guided-autonomous-execution, planning, design-flow, implementation-flow, implementation-readiness, readiness-gate]
+    typical-use: "Orchestrating subagents through implementation workflows, scale determination, stop points, guided autonomous execution mode"
     size: large
     key-references:
       - "Orchestrator Pattern"
@@ -152,6 +170,8 @@ skills:
       - "Explicit Stop Points [MANDATORY]"
       - "Scale Determination and Document Requirements"
       - "Structured Response Specification"
+      - "Implementation Readiness Marker Contract"
+      - "Implementation Readiness Preflight Procedure"
       - "Handling Requirement Changes"
       - "Basic Flow for Work Planning"
       - "Autonomous Execution Mode"
@@ -160,3 +180,30 @@ skills:
       - "Required Dialogue Points with Humans [MANDATORY]"
       - "Action Checklist"
       - "References"
+    references:
+      - "references/monorepo-flow.md"
+
+  external-resource-context:
+    skill: "external-resource-context"
+    tags: [external-resources, external-resource-hearing, project-context, mcp, design-source, design-system, visual-verification, generated-artifacts, api-schema, infrastructure, secret-store, context-engineering, documentation]
+    typical-use: "Discover, confirm, and record external resource access methods for downstream design, planning, implementation, and review"
+    size: medium
+    key-references:
+      - "Single Source of Truth"
+      - "Context Engineering"
+    sections:
+      - "Purpose"
+      - "Scope Boundaries"
+      - "Storage Locations"
+      - "Hearing Protocol"
+      - "Storage Protocol"
+      - "Lookup Protocol"
+      - "Output Format"
+      - "Quality Checklist"
+      - "References"
+    references:
+      - "references/frontend.md"
+      - "references/backend.md"
+      - "references/api.md"
+      - "references/infra.md"
+      - "references/template.md"

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

@@ -13,9 +13,8 @@ import userEvent from '@testing-library/user-event'
 ### Coverage Requirements
 
 - **Overall minimum**: 60%
-- **Atoms (Button, Text)**: 70%+
-- **Molecules (FormField)**: 65%+
-- **Organisms (Header, Footer)**: 60%+
+- **Atomic Design projects**: Atoms 70%+, Molecules 65%+, Organisms 60%+
+- **Other component architectures**: Keep 60% as the baseline and raise foundational or highly reused components to 70%+
 - **Custom Hooks**: 65%+
 - **Utils**: 70%+
 

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/quality-fixer-frontend.toml

@@ -88,6 +88,7 @@ If incomplete implementation is detected, stop immediately and return `status: "
 
 **Supplementary detection** (when `task_file` is provided):
 - Read the task file's `Quality Assurance Mechanisms` section
+- Read `docs/project-context/external-resources.md` and related `External Resources Used` sections when the task file references them
 - For executable mechanisms, verify the tool exists and is runnable in the current project, then add it to the quality-check command set
 - For non-executable domain constraints, keep them as explicit verification targets and check the changed files against the stated constraint during review
 - Record skipped mechanisms only when neither executable verification nor direct constraint checking is possible
@@ -475,3 +476,7 @@ enabled = true
 [[skills.config]]
 path = ".agents/skills/ai-development-guide/SKILL.md"
 enabled = true
+
+[[skills.config]]
+path = ".agents/skills/external-resource-context/SKILL.md"
+enabled = true

package/.codex/agents/quality-fixer.toml

@@ -86,6 +86,7 @@ If incomplete implementation is detected, stop immediately and return `status: "
 
 **Supplementary detection** (when `task_file` is provided):
 - Read the task file's `Quality Assurance Mechanisms` section
+- Read `docs/project-context/external-resources.md` and related `External Resources Used` sections when the task file references them
 - For executable mechanisms, verify the tool exists and is runnable in the current project, then add it to the quality-check command set
 - For non-executable domain constraints, keep them as explicit verification targets and check the changed files against the stated constraint during review
 - Record skipped mechanisms only when neither executable verification nor direct constraint checking is possible
@@ -369,3 +370,7 @@ enabled = true
 [[skills.config]]
 path = ".agents/skills/ai-development-guide/SKILL.md"
 enabled = true
+
+[[skills.config]]
+path = ".agents/skills/external-resource-context/SKILL.md"
+enabled = true

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)
@@ -152,6 +154,13 @@ Select and execute files with pattern `docs/plans/tasks/*-task-*.md` that have u
    - API Specifications → Understand endpoints, parameters, response formats (for MSW mocking)
    - Overall Design Document → Understand system-wide context
 
+**External Resources Consultation**:
+When the task file, Dependencies, or Investigation Targets reference `docs/project-context/external-resources.md` or an `External Resources Used` section:
+1. Read `docs/project-context/external-resources.md`
+2. Resolve feature-specific identifiers from the UI Spec, Design Doc, or task file
+3. Use declared access methods for design origin, design system, guidelines, and visual verification facts during investigation and verification
+4. Record consulted resources in Investigation Notes
+
 ### 3. Implementation Execution
 
 #### Test Environment Check
@@ -185,7 +194,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 +220,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 +384,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]]
@@ -400,3 +401,7 @@ enabled = true
 [[skills.config]]
 path = ".agents/skills/implementation-approach/SKILL.md"
 enabled = true
+
+[[skills.config]]
+path = ".agents/skills/external-resource-context/SKILL.md"
+enabled = true

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)
@@ -152,6 +154,13 @@ Select and execute files with pattern `docs/plans/tasks/*-task-*.md` that have u
    - Data Schema → Understand table structure, relationships
    - Overall Design Document → Understand system-wide context
 
+**External Resources Consultation**:
+When the task file, Dependencies, or Investigation Targets reference `docs/project-context/external-resources.md` or an `External Resources Used` section:
+1. Read `docs/project-context/external-resources.md`
+2. Resolve feature-specific identifiers from the referenced Design Doc or task file
+3. Use declared access methods for required external facts during investigation and verification
+4. Record consulted resources in Investigation Notes
+
 ### 3. Implementation Execution
 
 #### Test Environment Check
@@ -194,7 +203,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 +223,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 +370,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 +387,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]]
@@ -403,3 +404,7 @@ enabled = true
 [[skills.config]]
 path = ".agents/skills/implementation-approach/SKILL.md"
 enabled = true
+
+[[skills.config]]
+path = ".agents/skills/external-resource-context/SKILL.md"
+enabled = true