codex-workflows 0.4.11 → 0.6.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/design-template.md

@@ -33,6 +33,14 @@ unknowns:
 - [ADR File Name]: [Related decision items]
 - Reference common technical ADRs when applicable
 
+### External Resources Used
+
+| Project Resource Label | Feature Identifier | Purpose |
+|------------------------|--------------------|---------|
+| frontend-design-origin | [screen / node / frame / route / story id] | [why this feature uses it] |
+| api-schema-source | [endpoint / operation id / schema name] | [why this feature uses it] |
+| infra-iac-source | [service / module / environment] | [why this feature uses it] |
+
 ### Agreement Checklist
 
 #### Scope

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]
 
@@ -100,7 +119,7 @@ Use when implementation approach is Vertical Slice. Each phase represents one va
 #### Tasks
 - [ ] [P1-T1] Specific work content
 - [ ] [P1-T2] Verification for this value unit
-- [ ] Quality check: Implement staged quality checks (refer to ai-development-guide skill)
+- [ ] Quality check: Run staged static analysis, build verification, tests, and final quality gate
 
 #### Phase Completion Criteria
 - [ ] Early verification point passed
@@ -132,7 +151,7 @@ Use when implementation approach is Horizontal Slice. Phases follow Foundation -
 #### Tasks
 - [ ] [P1-T1] Specific work content
 - [ ] [P1-T2] Specific work content
-- [ ] Quality check: Implement staged quality checks (refer to ai-development-guide skill)
+- [ ] Quality check: Run staged static analysis, build verification, tests, and final quality gate
 - [ ] Unit tests: All related tests pass
 
 #### Phase Completion Criteria
@@ -182,7 +201,7 @@ This phase is required for all implementation approaches.
 - [ ] Document updates
 
 ### Quality Assurance
-- [ ] Implement staged quality checks (details: refer to ai-development-guide skill)
+- [ ] Run staged static analysis, build verification, tests, and final quality gate
 - [ ] All tests pass
 - [ ] Static check pass
 - [ ] Lint check pass

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

@@ -46,7 +46,7 @@ Brief observations recorded after reading Investigation Targets:
 - **Verification method**: [What to verify and how]
 - **Success criteria**: [Observable outcome that proves correctness]
 - **Failure response**: [What to do if verification fails]
-- **Verification level**: [L1/L2/L3, per implementation-approach skill]
+- **Verification level**: [L1 unit/local verification, L2 integration verification, or L3 end-to-end verification]
 
 ## Completion Criteria
 - [ ] All added tests pass

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

@@ -13,6 +13,14 @@
 |--------|------|---------|
 | Prototype code | [docs/ui-spec/assets/xxx/] | [commit SHA / tag] |
 
+## External Resources Used
+
+| Project Resource Label | Feature Identifier | Purpose |
+|------------------------|--------------------|---------|
+| [frontend-design-origin] | [screen / node / frame / route / story id] | [why this feature uses it] |
+| [frontend-design-system] | [component / token / variant / story id] | [why this feature uses it] |
+| [frontend-visual-verification] | [route / story / viewport / scenario] | [how this feature is verified] |
+
 ## Prototype Management
 
 Prototype code is an **attachment** to this UI Spec. The canonical specification is always this document + the Design Doc.
@@ -59,6 +67,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/external-resource-context/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: external-resource-context
+description: "Discovers, confirms, and records external resource access methods for project design and implementation work, including design sources, design systems, API schemas, database schemas, IaC sources, secret stores, environment config, and verification environments. Use when external resource context needs to be discovered or refreshed, recorded in docs/project-context/external-resources.md, or referenced from a Design Doc/UI Spec."
+---
+
+# External Resource Context
+
+## Purpose
+
+This skill helps Codex discover required external resources, record stable access methods, and reuse recorded context during design, planning, implementation, and review work.
+
+Covered resources include design origin, design system, guidelines, visual verification environment, database schema source, migration history, secret store location, API schema source, mock environment, IaC source, and environment configuration.
+
+## Scope Boundaries
+
+**In scope**: hearing protocol for unclear external resources, storage location, single-source ownership rule, and lookup protocol for known resources.
+
+**Freshness handling**: record access methods and feature identifiers here. The consuming workflow checks current resource content at use time.
+
+## Storage Locations
+
+| Tier | Location | Holds | Update Frequency |
+|------|----------|-------|------------------|
+| Project | `docs/project-context/external-resources.md` | Environment-stable facts: resource labels, presence, and access methods | When the project environment changes |
+| Feature | `## External Resources Used` section in the relevant UI Spec or Design Doc | Feature-specific identifiers that reference project-tier labels | Per feature |
+
+### Single Source Rule
+
+The project tier owns environment facts such as URLs, MCP server names, file paths, commands, and secret-store locations. Feature-tier sections list feature-specific identifiers such as design node ids, API paths, schema names, or IaC module names, then reference the project-tier label.
+
+## Hearing Protocol
+
+### When to Hear
+
+| Condition | Action |
+|-----------|--------|
+| `docs/project-context/external-resources.md` is absent | Run full hearing for the relevant domain |
+| File exists | Ask for one choice: keep current axes, refresh all axes, or refresh selected axes |
+
+When the user chooses `refresh selected axes`, ask for the exact domain and axis labels before updating. Confirm the selected labels against the loaded domain reference, then hear only those axes.
+
+### Domain Routing
+
+Load the domain reference matching the current task:
+
+| Task type | References to load |
+|-----------|--------------------|
+| Frontend UI work | [references/frontend.md](references/frontend.md) |
+| Backend or data work | [references/backend.md](references/backend.md) |
+| API contract work | [references/api.md](references/api.md) |
+| Infrastructure or deployment | [references/infra.md](references/infra.md) |
+| Fullstack | Load each relevant domain reference |
+
+Each domain reference defines axes and question templates. Use `N/A` for axes outside the current project.
+
+### Two-Phase Hearing
+
+1. **Structured hearing**: ask each axis from the domain reference. For each non-N/A axis, collect the access or reference method: MCP server name, URL, file path, command, repository-owned source, project convention, manual confirmation path, or existing implementation.
+2. **Self-declaration**: ask for additional external resources outside the structured axes. Append any resources the user provides under `Additional Resources`.
+
+## Storage Protocol
+
+After hearing completes:
+
+1. Build project-tier content from the answers using [references/template.md](references/template.md).
+2. Write `docs/project-context/external-resources.md`, creating `docs/project-context/` as needed.
+3. When a target UI Spec or Design Doc exists, update its `External Resources Used` section with project-tier labels plus feature-specific identifiers.
+4. If a write fails, return the error with the intended path and leave completion status unresolved.
+5. Report touched file paths to the calling workflow.
+
+## Lookup Protocol
+
+Consumers resolve external context in this order:
+
+1. Read `docs/project-context/external-resources.md`.
+2. Read the target UI Spec or Design Doc `External Resources Used` section for feature-specific identifiers.
+3. Use the project-tier access method to fetch or inspect the resource.
+
+Codex custom agents inherit parent `mcp_servers` when the agent file omits `mcp_servers`. Preserve that inheritance for agents that may need project-specific MCP tools. Reserve MCP `enabled_tools` for a deliberately narrow server-level allow list.
+
+## Output Format
+
+The project-tier file follows [references/template.md](references/template.md). Feature-tier sections use the fixed heading `External Resources Used`; heading level follows the parent document structure.
+
+## Quality Checklist
+
+- [ ] Each relevant axis has a presence indicator and access method, or is marked `N/A`
+- [ ] Self-declaration phase completed
+- [ ] Project-tier file contains environment facts
+- [ ] Feature-tier sections contain feature identifiers and project-tier labels
+- [ ] Existing project-tier updates are confirmed before writes
+
+## References
+
+- [references/frontend.md](references/frontend.md)
+- [references/backend.md](references/backend.md)
+- [references/api.md](references/api.md)
+- [references/infra.md](references/infra.md)
+- [references/template.md](references/template.md)

package/.agents/skills/external-resource-context/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "external-resource-context"
+  short_description: "Discover and reuse external resource context"
+  default_prompt: "Use $external-resource-context to identify or consult external resources for: "
+
+policy:
+  allow_implicit_invocation: true

package/.agents/skills/external-resource-context/references/api.md

@@ -0,0 +1,20 @@
+# API External Resource Axes
+
+Use these axes when work depends on API contracts outside the repository.
+
+| Axis | Purpose | Presence Choices | Access Method Examples |
+|------|---------|------------------|------------------------|
+| API Schema Source | OpenAPI, GraphQL SDL, proto, or typed contract source | Present / Repository-owned / N/A | schema repo path, docs URL, MCP |
+| API Explorer | Interactive or generated contract inspection | Present / N/A | Swagger UI URL, GraphQL explorer URL |
+| Mock Server | Contract-backed mock or sandbox endpoint | Present / N/A | mock URL, command, docker compose service |
+| Consumer Contract Source | Downstream expectations or contract tests | Present / N/A | contract repo, pact broker URL, file path |
+
+## Question Template
+
+Ask each axis in positive form:
+
+1. "Which API contract resources are available for this work?"
+2. "For each applicable resource, what access method or reference method should Codex use?"
+3. "Which feature-specific identifier applies, such as endpoint path, operation id, schema name, or event name?"
+
+Record `N/A` for axes outside the project.

package/.agents/skills/external-resource-context/references/backend.md

@@ -0,0 +1,21 @@
+# Backend External Resource Axes
+
+Use these axes when backend or data work depends on resources outside the repository.
+
+| Axis | Purpose | Presence Choices | Access Method Examples |
+|------|---------|------------------|------------------------|
+| Database Schema Source | Canonical schema, ERD, or generated model source | Present / Repository-owned / N/A | schema repo path, DB docs URL, MCP |
+| Migration History | Deployment-applied migration sequence | Present / Repository-owned / N/A | migration repo, migration table query command |
+| Secret Store | Runtime secret names and lookup location | Present / N/A | cloud secret manager path, vault path |
+| Environment Configuration | Runtime config source and environment matrix | Present / Repository-owned / N/A | config repo, deployment docs, command |
+| Mock or Fixture Environment | Local or shared backend verification setup | Present / N/A | docker compose path, seeded DB command, service URL |
+
+## Question Template
+
+Ask each axis in positive form:
+
+1. "Which backend external resources are available for this work?"
+2. "For each applicable resource, what access method or reference method should Codex use?"
+3. "Which feature-specific identifier applies, such as table name, service name, secret name, or environment name?"
+
+Record `N/A` for axes outside the project.

package/.agents/skills/external-resource-context/references/frontend.md

@@ -0,0 +1,21 @@
+# Frontend External Resource Axes
+
+Use these axes when frontend UI work depends on resources outside the repository.
+
+| Axis | Purpose | Presence Choices | Access Method Examples |
+|------|---------|------------------|------------------------|
+| Design Origin | Canonical visual or interaction source | Present / Existing implementation / N/A | Figma MCP, public URL, exported file path |
+| Design System | Component catalog, tokens, variants, usage rules | Present / Existing package only / N/A | Storybook URL, package docs, MCP, local docs |
+| Guidelines | Accessibility, responsive, copy, brand, i18n, or platform rules | Present / Project conventions only / N/A | URL, file path, wiki export |
+| Visual Verification Environment | Rendered UI inspection path | Present / Manual confirmation / N/A | browser MCP, Playwright command, Storybook URL, dev server URL |
+| Generated UI Artifacts | Generated CSS typings, route typings, message catalogs, snapshots | Present / N/A | generator command, config path |
+
+## Question Template
+
+Ask each axis in positive form:
+
+1. "Which frontend external resources are available for this work?"
+2. "For each applicable resource, what access method or reference method should Codex use?"
+3. "Which feature-specific identifier applies, such as screen name, node id, route, story id, or component name?"
+
+Record `N/A` for axes outside the project.

package/.agents/skills/external-resource-context/references/infra.md

@@ -0,0 +1,21 @@
+# Infrastructure External Resource Axes
+
+Use these axes when infrastructure, deployment, or runtime environment work depends on resources outside the repository.
+
+| Axis | Purpose | Presence Choices | Access Method Examples |
+|------|---------|------------------|------------------------|
+| IaC Source | Terraform, Pulumi, CDK, or deployment source | Present / Repository-owned / N/A | repo path, module registry, docs URL |
+| Environment Inventory | Accounts, regions, clusters, services | Present / N/A | cloud console URL, inventory file, command |
+| Deployment Pipeline | CI/CD workflow and promotion process | Present / Repository-owned / N/A | pipeline URL, workflow file path |
+| Observability Source | Logs, metrics, traces, dashboards | Present / N/A | dashboard URL, MCP, CLI command |
+| Runtime Access Method | How to inspect deployed state | Present / N/A | kubectl context, cloud CLI profile, bastion docs |
+
+## Question Template
+
+Ask each axis in positive form:
+
+1. "Which infrastructure external resources are available for this work?"
+2. "For each applicable resource, what access method or reference method should Codex use?"
+3. "Which feature-specific identifier applies, such as module name, service name, environment, account, or dashboard?"
+
+Record `N/A` for axes outside the project.

package/.agents/skills/external-resource-context/references/template.md

@@ -0,0 +1,72 @@
+# Project External Resources Template
+
+Use this structure for `docs/project-context/external-resources.md`.
+
+```markdown
+# External Resources
+
+## Overview
+
+This file records project-level access methods for resources outside the repository. Feature documents reference these labels and add feature-specific identifiers.
+
+## Frontend
+
+| Label | Axis | Status | Access Method | Owner / Notes |
+|-------|------|--------|---------------|---------------|
+| frontend-design-origin | Design Origin | present / existing-implementation / N/A | MCP / URL / file path / command | [owner or notes] |
+| frontend-design-system | Design System | present / existing-package / N/A | MCP / URL / file path / command | [owner or notes] |
+| frontend-guidelines | Guidelines | present / project-conventions / N/A | URL / file path | [owner or notes] |
+| frontend-visual-verification | Visual Verification Environment | present / manual-confirmation / N/A | MCP / URL / command | [owner or notes] |
+| frontend-generated-artifacts | Generated UI Artifacts | present / N/A | command / config path | [owner or notes] |
+
+## Backend
+
+| Label | Axis | Status | Access Method | Owner / Notes |
+|-------|------|--------|---------------|---------------|
+| backend-schema-source | Database Schema Source | present / repository-owned / N/A | URL / file path / command | [owner or notes] |
+| backend-migration-history | Migration History | present / repository-owned / N/A | URL / file path / command | [owner or notes] |
+| backend-secret-store | Secret Store | present / N/A | store path / docs path | [owner or notes] |
+| backend-environment-config | Environment Configuration | present / repository-owned / N/A | URL / file path / command | [owner or notes] |
+| backend-mock-environment | Mock or Fixture Environment | present / N/A | URL / command | [owner or notes] |
+
+## API
+
+| Label | Axis | Status | Access Method | Owner / Notes |
+|-------|------|--------|---------------|---------------|
+| api-schema-source | API Schema Source | present / repository-owned / N/A | URL / file path / MCP | [owner or notes] |
+| api-explorer | API Explorer | present / N/A | URL / MCP | [owner or notes] |
+| api-mock-server | Mock Server | present / N/A | URL / command | [owner or notes] |
+| api-consumer-contract | Consumer Contract Source | present / N/A | URL / file path | [owner or notes] |
+
+## Infrastructure
+
+| Label | Axis | Status | Access Method | Owner / Notes |
+|-------|------|--------|---------------|---------------|
+| infra-iac-source | IaC Source | present / repository-owned / N/A | URL / file path | [owner or notes] |
+| infra-environment-inventory | Environment Inventory | present / N/A | URL / file path / command | [owner or notes] |
+| infra-deployment-pipeline | Deployment Pipeline | present / repository-owned / N/A | URL / file path | [owner or notes] |
+| infra-observability-source | Observability Source | present / N/A | URL / MCP / command | [owner or notes] |
+| infra-runtime-access | Runtime Access Method | present / N/A | command / docs path | [owner or notes] |
+
+## Additional Resources
+
+| Label | Description | Access Method | Owner / Notes |
+|-------|-------------|---------------|---------------|
+| [label] | [description] | [URL / MCP / file path / command] | [owner or notes] |
+
+## Update History
+
+| Date | Change | Author |
+|------|--------|--------|
+| YYYY-MM-DD | Initial capture | [name] |
+```
+
+Feature-tier sections use this compact table:
+
+```markdown
+## External Resources Used
+
+| Project Resource Label | Feature Identifier | Purpose |
+|------------------------|--------------------|---------|
+| frontend-design-origin | [screen / node / frame id] | [why this feature uses it] |
+```

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

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

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

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

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

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