codex-workflows 0.6.7 → 0.6.9

package/.agents/skills/ai-development-guide/SKILL.md

@@ -165,7 +165,9 @@ To isolate problems, attempt reproduction with minimal code:
 - Replace external dependencies with mocks
 - Create minimal configuration that reproduces problem
 
-### 4. Debug Log Output
+### 4. Debug Log Output (temporary)
+Add structured debug logs to isolate the issue, then remove them before commit.
+
 ```
 Pattern: Structured logging with context
 {
@@ -204,7 +206,7 @@ Universal quality assurance phases applicable to all languages:
 ### Phase 3: Testing
 1. **Unit Tests**: Run all unit tests
 2. **Integration Tests**: Run integration tests
-3. **Test Coverage**: Measure and verify coverage meets standards
+3. **Test Coverage**: Measure coverage when configured and use it to find gaps
 4. **E2E Tests**: Run end-to-end tests
 
 ### Phase 4: Final Quality Gate [MANDATORY]
@@ -212,7 +214,7 @@ All checks MUST pass before proceeding:
 - Zero static analysis errors
 - Build succeeds
 - All tests pass
-- Coverage meets threshold
+- Coverage threshold passes when the project, task file, work plan, or Design Doc defines one. When no threshold is configured, use coverage output only to identify untested critical paths.
 
 **ENFORCEMENT**: Cannot proceed with ANY quality check failures — fix ALL errors before marking task complete
 

package/.agents/skills/ai-development-guide/references/frontend.md

@@ -75,28 +75,19 @@ console.log('DEBUG:', {
 
 ## Frontend Quality Check Workflow
 
-Use the appropriate run command based on the `packageManager` field in package.json.
+Read `package.json` scripts and run them with the project's package manager from the `packageManager` field. Map the phases below using the script names declared in `package.json`.
 
-### Common Commands
-- `dev` - Development server
-- `build` - Production build
-- `preview` - Preview production build
-- `type-check` - Type check (no emit)
-
-### Quality Check Phases
-**Phase 1-3: Basic Checks**
-- `check` - Linter + formatter (Biome, ESLint, Prettier, etc.)
-- `build` - TypeScript build
-
-**Phase 4-5: Tests and Final Confirmation**
-- `test` - Test execution
-- `test:coverage:fresh` - Coverage measurement (fresh cache)
-- `check:all` - Overall integrated check
+### Phases
+1. **Lint/format** - the project's formatter and linter, such as Biome or ESLint plus Prettier
+2. **Type check** - type check without emit when the project has a dedicated command
+3. **Build** - production build
+4. **Test** - unit and integration tests
+5. **Coverage** - coverage run when configured or when the task added or changed behavior
 
 ### Troubleshooting
-- **Port in use error**: Run `cleanup:processes` script if available
-- **Cache issues**: Run tests with fresh cache option
-- **Dependency errors**: Clean reinstall dependencies
+- **Port already in use**: stop the stale dev, preview, or test process holding the port
+- **Stale cache**: re-run with the project's fresh or clean-cache option
+- **Dependency errors**: clean reinstall dependencies
 
 ## Frontend Technical Decisions
 
@@ -108,6 +99,7 @@ Use the appropriate run command based on the `packageManager` field in package.j
 ### Performance vs Readability
 - Prioritize readability unless clear bottleneck exists
 - Measure before optimizing (use React DevTools Profiler, not guesses)
+- When React Compiler is enabled, routine memoization is automatic. Use manual memoization only for a measured bottleneck or stable reference identity required by third-party APIs or effect dependencies.
 - Document reason with comments when optimizing
 
 ## Frontend Impact Analysis

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

@@ -62,6 +62,11 @@ function isUser(value: unknown): value is User {
 - **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
 
+**Server/Client Boundary (RSC frameworks only, such as Next.js App Router)**
+- Default to server components for data fetching and rendering. Isolate interactivity behind a `"use client"` boundary at the smallest scope that needs it.
+- Keep browser-only APIs such as `window`, `localStorage`, and event handlers inside client components.
+- Skip this section for client-only SPAs with no server-component runtime.
+
 **State Management Patterns**
 - **Local State**: `useState` for component-specific state
 - **Context API**: For sharing state across component tree (theme, auth, etc.)
@@ -95,19 +100,18 @@ setUsers(users)
 - Type-safe: Always define Props type explicitly
 
 **Environment Variables**
-- **Use build tool's environment variable system**: `process.env` does not work in browsers
-- Centrally manage environment variables through configuration layer
-- Implement proper type safety and default value handling
+- **Use the build tool's env accessor**: read client-side env through the bundler's exposed accessor, such as Vite `import.meta.env` or Next.js/CRA prefixed `process.env`.
+- **Only prefixed vars reach the client**: build tools expose only vars carrying their public prefix. Match the project's bundler, such as Vite `VITE_`, Next.js `NEXT_PUBLIC_`, or CRA `REACT_APP_`.
+- Centrally manage environment variables through a typed configuration layer with defaults.
 
 ```typescript
-// Build tool environment variables (public values only)
+// Client-exposed env must carry the bundler's public prefix, or it is undefined in the browser.
+// Vite:    import.meta.env.VITE_API_URL
+// Next.js: process.env.NEXT_PUBLIC_API_URL
 const config = {
-  apiUrl: import.meta.env.API_URL || 'http://localhost:3000',
-  appName: import.meta.env.APP_NAME || 'My App'
+  apiUrl: import.meta.env.VITE_API_URL || 'http://localhost:3000',
+  appName: import.meta.env.VITE_APP_NAME || 'My App'
 }
-
-// Does not work in frontend
-// const apiUrl = process.env.API_URL
 ```
 
 **Security (Client-side Constraints)**
@@ -118,7 +122,7 @@ const config = {
 
 ```typescript
 // Bad: API key exposed in browser
-// const apiKey = import.meta.env.API_KEY
+// const apiKey = import.meta.env.VITE_API_KEY
 // const response = await fetch(`https://api.example.com/data?key=${apiKey}`)
 
 // Good: Backend manages secrets, frontend accesses via proxy
@@ -132,6 +136,7 @@ const response = await fetch('/api/data') // Backend handles API key authenticat
 - Promise Handling: Always use `async/await`
 - Error Handling: Always handle with `try-catch` or Error Boundary
 - Type Definition: Explicitly define return value types (e.g., `Promise<Result>`)
+- Effect race/cleanup: guard `useEffect` data fetches against out-of-order responses and post-unmount state updates with `AbortController`, a mounted/stale flag, or a server-state library such as React Query or SWR.
 
 **Format Rules**
 - Semicolon omission (follow project formatter settings)
@@ -209,10 +214,10 @@ Never include sensitive information (password, token, apiKey, secret, creditCard
 
 ## Performance Optimization
 
-- Component Memoization: Use React.memo for expensive components
+- Automatic memoization: when React Compiler is enabled, rely on it. Use manual `React.memo`, `useMemo`, or `useCallback` only for a profiler-confirmed bottleneck or stable reference identity required by third-party APIs or effect dependencies.
 - State Optimization: Minimize re-renders with proper state structure
 - Lazy Loading: Use React.lazy and Suspense for code splitting
-- Bundle Size: Monitor with the `build` script and keep under 500KB
+- Bundle Size: Monitor with the build script against the project's budget
 
 ## Non-functional Requirements
 

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

@@ -243,7 +243,7 @@ This phase is required for all implementation approaches.
 - [ ] Security review: Verify security considerations from Design Doc are implemented
 - [ ] Quality checks (types, lint, format)
 - [ ] Execute all tests (including integration/E2E from test skeletons, when provided)
-- [ ] Coverage 70%+
+- [ ] Coverage threshold passes when configured
 - [ ] Document updates
 
 ### Quality Assurance

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

@@ -17,6 +17,13 @@ Metadata:
 Files to read before starting implementation. Use concrete file paths, optionally with a section/function hint:
 - [e.g., src/orders/checkout.ts (processOrder function)]
 
+## Change Category
+(Include this field only when the task is a bug fix, regression, state-change, or boundary-change. Omit otherwise.)
+
+`Change Category: <one or more of bug-fix, regression, state-change, boundary-change, comma-separated>`
+
+When present, sweep cases sharing the same path, contract, persisted state, or external boundary for the same class of defect during the Red Phase.
+
 ## Binding Decisions
 (Include this section when the work plan's ADR Bindings table covers this task. Omit otherwise.)
 
@@ -34,6 +41,7 @@ Brief observations recorded after reading Investigation Targets:
 ## Implementation Steps (TDD: Red-Green-Refactor)
 ### 1. Red Phase
 - [ ] Read all Investigation Targets and update Investigation Notes
+- [ ] (When Change Category is set) Sweep adjacent cases sharing the same path, contract, persisted state, or external boundary for the same class of defect; fold any in-scope residual into failing tests
 - [ ] Review dependency deliverables (if any)
 - [ ] Verify/create contract definitions
 - [ ] Write failing tests

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

@@ -156,7 +156,7 @@ The test runner or framework in the project determines the appropriate file exte
 
 | Check | Failure Condition |
 |-------|-------------------|
-| Behavior Verification | No assertion for "observable result" in skeleton |
+| Behavior Verification | No assertion for "observable result" in the implemented test |
 | Verification Item Coverage | Listed items not all covered by assertions |
 | Mock Boundary | Real dependencies from `@real-dependency` are isolated away or internal components are mocked without rationale |
 

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

@@ -29,9 +29,9 @@ Work plan: $ARGUMENTS
 
 ## Pre-execution Prerequisites
 
-### Implementation Readiness Check
+### Implementation Readiness Resolution
 
-Before task processing, locate the work plan to gate against.
+Before task processing, locate the work plan and resolve implementation readiness.
 
 Resolution rule:
 1. If `$ARGUMENTS` contains a work plan path, use that exact file and derive `{plan-name}` from its basename. This takes precedence over task-file mtimes.
@@ -40,7 +40,14 @@ Resolution rule:
 4. If matching task files exist, infer `{plan-name}` from the most recent matching task file and use `docs/plans/{plan-name}.md`.
 5. If no matching task files exist, use the most recent non-template work plan in `docs/plans/`.
 
-Read the work plan header and apply the Implementation Readiness Marker Contract from `subagents-orchestration-guide`.
+Read the work plan header and apply this readiness rule:
+
+| Header state | Action |
+|--------------|--------|
+| `Implementation Readiness: ready` | Proceed to Consumed Task Set computation |
+| `Implementation Readiness: pending` | Execute the Implementation Readiness Preflight Procedure from `subagents-orchestration-guide` for the resolved work plan. Re-read the resulting marker: proceed to Consumed Task Set only when it is `ready`; if it is `escalated`, follow the `escalated` row |
+| `Implementation Readiness: escalated` | Present the persisted Readiness Report remaining gaps, then continue only on explicit user approval |
+| marker absent | Execute the Implementation Readiness Preflight Procedure from `subagents-orchestration-guide` for the resolved work plan. Re-read the resulting marker: proceed to Consumed Task Set only when it is `ready`; if it is `escalated`, follow the `escalated` row |
 
 ### Consumed Task Set
 

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

@@ -29,9 +29,9 @@ Work plan: $ARGUMENTS
 
 ## Pre-execution Prerequisites
 
-### Implementation Readiness Check
+### Implementation Readiness Resolution
 
-Before task processing, locate the work plan to gate against.
+Before task processing, locate the work plan and resolve implementation readiness.
 
 Resolution rule:
 1. If `$ARGUMENTS` contains a work plan path, use that exact file and derive `{plan-name}` from its basename. This takes precedence over task-file mtimes.
@@ -40,7 +40,14 @@ Resolution rule:
 4. If matching task files exist, infer `{plan-name}` from the most recent matching task file and use `docs/plans/{plan-name}.md`.
 5. If no matching task files exist, use the most recent non-template work plan in `docs/plans/`.
 
-Read the work plan header and apply the Implementation Readiness Marker Contract from `subagents-orchestration-guide`.
+Read the work plan header and apply this readiness rule:
+
+| Header state | Action |
+|--------------|--------|
+| `Implementation Readiness: ready` | Proceed to Consumed Task Set computation |
+| `Implementation Readiness: pending` | Execute the Implementation Readiness Preflight Procedure from `subagents-orchestration-guide` for the resolved work plan. Re-read the resulting marker: proceed to Consumed Task Set only when it is `ready`; if it is `escalated`, follow the `escalated` row |
+| `Implementation Readiness: escalated` | Present the persisted Readiness Report remaining gaps, then continue only on explicit user approval |
+| marker absent | Execute the Implementation Readiness Preflight Procedure from `subagents-orchestration-guide` for the resolved work plan. Re-read the resulting marker: proceed to Consumed Task Set only when it is `ready`; if it is `escalated`, follow the `escalated` row |
 
 ### Consumed Task Set
 

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

@@ -39,9 +39,9 @@ Work plan: $ARGUMENTS
 
 ## Pre-execution Prerequisites
 
-### Implementation Readiness Check
+### Implementation Readiness Resolution
 
-Before task processing, locate the work plan to gate against.
+Before task processing, locate the work plan and resolve implementation readiness.
 
 Resolution rule:
 1. If `$ARGUMENTS` contains a work plan path, use that exact file and derive `{plan-name}` from its basename. This takes precedence over task-file mtimes.
@@ -50,7 +50,14 @@ Resolution rule:
 4. If matching task files exist, infer `{plan-name}` from the most recent matching task file and use `docs/plans/{plan-name}.md`.
 5. If no matching task files exist, use the most recent non-template work plan in `docs/plans/`.
 
-Read the work plan header and apply the Implementation Readiness Marker Contract from `subagents-orchestration-guide`.
+Read the work plan header and apply this readiness rule:
+
+| Header state | Action |
+|--------------|--------|
+| `Implementation Readiness: ready` | Proceed to Consumed Task Set computation |
+| `Implementation Readiness: pending` | Execute the Implementation Readiness Preflight Procedure from `subagents-orchestration-guide` for the resolved work plan. Re-read the resulting marker: proceed to Consumed Task Set only when it is `ready`; if it is `escalated`, follow the `escalated` row |
+| `Implementation Readiness: escalated` | Present the persisted Readiness Report remaining gaps, then continue only on explicit user approval |
+| marker absent | Execute the Implementation Readiness Preflight Procedure from `subagents-orchestration-guide` for the resolved work plan. Re-read the resulting marker: proceed to Consumed Task Set only when it is `ready`; if it is `escalated`, follow the `escalated` row |
 
 ### Consumed Task Set
 

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

@@ -104,7 +104,7 @@ When user responds to questions:
 **Required Flow Compliance**:
 - Run quality-fixer (layer-appropriate) before every commit
 - Obtain user approval before Edit/Write outside autonomous mode
-- Run implementation readiness preflight for the approved work plan before autonomous implementation, or continue without it only after explicit user approval
+- Resolve implementation readiness for the approved work plan before autonomous implementation
 
 ENFORCEMENT: Commits without quality-fixer approval are invalid and MUST be reverted.
 

package/.agents/skills/recipe-prepare-implementation/SKILL.md

@@ -80,6 +80,7 @@ When all applicable criteria are `pass`:
 
 When one or more criteria fail:
 1. Present the proposed prep tasks to the user and continue only after explicit approval.
+   - If the user declines prep execution, persist `Implementation Readiness: escalated` with the current Readiness Report and stop before creating prep task files.
 2. Create task files in `docs/plans/tasks/` using the task template:
    - Backend prep: `{plan-name}-backend-task-prep-{NN}.md`
    - Frontend prep: `{plan-name}-frontend-task-prep-{NN}.md`

package/.agents/skills/subagents-orchestration-guide/SKILL.md

@@ -210,14 +210,14 @@ Work plans use the header line `Implementation Readiness: <status>`.
 
 | Status | Meaning | Consumer Action |
 |--------|---------|-----------------|
-| `pending` | Initial state from work-planner; readiness has not been checked | Present the unchecked state, recommend running implementation readiness preflight, and continue only on explicit user approval |
+| `pending` | Initial state from work-planner; readiness has not been checked | Run the Implementation Readiness Preflight Procedure before task execution |
 | `ready` | Readiness scan completed and no applicable failures remain | Proceed with task execution |
 | `escalated` | Readiness scan completed, but one or more failures remain | Read the work plan's Implementation Readiness Report, present remaining gaps, and continue only on explicit user approval |
-| absent | Older work plan without the marker | Treat as `pending` |
+| absent | Older work plan without the marker | Run the Implementation Readiness Preflight Procedure and persist the resulting marker |
 
 ## Implementation Readiness Preflight Procedure
 
-Use this procedure after work-plan approval and before autonomous task execution when the flow needs to verify implementation readiness.
+Use this procedure after work-plan approval and before autonomous task execution when the flow needs to verify implementation readiness. The procedure supplies the evidence needed for user decisions; prompts for approval only after concrete failing criteria and proposed prep tasks are known.
 
 1. Load the approved work plan exact path and extract Verification Strategies, Quality Assurance Mechanisms, Design-to-Plan Traceability, ADR Bindings, UI Spec Component -> Task Mapping, Connection Map, test skeleton references, E2E absence reasons, phase structure, referenced Design Docs, ADRs, and UI Specs.
 2. Evaluate these criteria with evidence:
@@ -227,9 +227,12 @@ Use this procedure after work-plan approval and before autonomous task execution
    - R4 UI rendering surface exists when UI work is present
    - R5 Local service stack or browser harness procedure exists when applicable
 3. If every applicable criterion passes, persist `## Implementation Readiness Report` in the work plan and set `Implementation Readiness: ready`.
-4. If any criterion fails, create the smallest approved prep tasks that close the gaps, execute each exact prep task file through the standard executor -> quality-fixer -> commit cycle, then re-run the scan.
-5. After re-scan, set `Implementation Readiness: ready` when all applicable criteria pass, otherwise `Implementation Readiness: escalated`, and persist remaining gaps in the Readiness Report.
-6. Collapse completed prep task references into the Readiness Report and delete only the prep task files created for the current work plan.
+4. If any criterion fails, present the failing criteria, evidence, and the smallest proposed prep tasks that close the gaps. Continue with prep execution only after explicit user approval for those tasks.
+5. If the user declines prep execution, persist `Implementation Readiness: escalated` with the remaining gaps and stop before autonomous task execution.
+6. If the user approves prep execution, create the approved prep task files under `docs/plans/tasks/` using the task template. Use `{plan-name}-task-prep-{NN}.md` for single-layer plans, `{plan-name}-backend-task-prep-{NN}.md` for backend prep, and `{plan-name}-frontend-task-prep-{NN}.md` for frontend prep.
+7. Execute each exact prep task file through the standard executor -> quality-fixer -> commit cycle, then re-run the scan.
+8. After re-scan, set `Implementation Readiness: ready` when all applicable criteria pass, otherwise `Implementation Readiness: escalated`, and persist remaining gaps in the Readiness Report.
+9. Collapse completed prep task references into the Readiness Report and delete only the prep task files created for the current work plan.
 
 ## Handling Requirement Changes
 

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

@@ -155,7 +155,7 @@ skills:
 
   subagents-orchestration-guide:
     skill: "subagents-orchestration-guide"
-    tags: [orchestration, workflow, subagents, context-isolation, autonomous-execution, guided-autonomous-execution, planning, design-flow, implementation-flow, implementation-readiness, readiness-gate]
+    tags: [orchestration, workflow, subagents, context-isolation, autonomous-execution, guided-autonomous-execution, planning, design-flow, implementation-flow, implementation-readiness, readiness-resolution]
     typical-use: "Orchestrating subagents through implementation workflows, scale determination, stop points, guided autonomous execution mode"
     size: large
     key-references:

package/.agents/skills/testing/SKILL.md

@@ -52,11 +52,11 @@ For language-specific testing patterns, also read:
 
 ## Quality Requirements [MANDATORY]
 
-### Coverage Standards
+### Coverage
 
-- **Minimum 80% code coverage** for production code
-- Prioritize critical paths and business logic
-- Use coverage as a guide, not a goal
+- Treat coverage as a diagnostic signal for finding untested areas, not a target. Targets get gamed into trivial tests.
+- Concentrate tests on critical paths, business logic, and behavior whose regression would matter.
+- Prioritize meaningful assertions over the coverage number. Any required threshold comes from the project's CI, task file, work plan, or Design Doc.
 
 ### Test Characteristics
 
@@ -279,7 +279,7 @@ Always test:
 ☐ All tests pass
 ☐ No tests skipped or commented
 ☐ No debug code left in tests
-☐ Test coverage meets standards (≥ 80%)
+☐ Coverage threshold passes when the project, task file, work plan, or Design Doc defines one
 ☐ Tests run in reasonable time
 
 ### Zero Tolerance Policy

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

@@ -10,13 +10,9 @@ import { render, screen } from '@testing-library/react'
 import userEvent from '@testing-library/user-event'
 ```
 
-### Coverage Requirements
+### Where to Concentrate Test Rigor
 
-- **Overall minimum**: 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%+
+Test foundational, high-reuse units the hardest: shared components, custom hooks, utilities, and business rules reused across features carry the widest blast radius. Higher-composition surfaces such as pages and organisms lean more on integration or E2E coverage. Any numeric threshold is the project's CI, task file, work plan, or Design Doc config.
 
 ### Test Types
 

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

@@ -180,33 +180,40 @@ Value score and E2E selection rules are defined in **integration-e2e-testing ski
 
 Adapt comment syntax to the project's language when generating annotations.
 
+A skeleton is committed before its implementation exists, so its committed form contains only comments and omits executable imports, runner blocks, and runner globals such as `describe` or `it`. This keeps freshly committed skeletons green under typecheck, lint, and build gates. The implementing task adds executable imports, runner blocks, and assertions alongside the implementation.
+
 ```
 // [Feature Name] Integration Test - Design Doc: [filename]
 // Generated: [date] | Budget Used: 2/3 integration, 0/2 E2E
-
-[Import statement using detected test framework]
-
-[Test suite using detected framework syntax]
-  // AC1: "After successful payment, order is created and persisted"
-  // Value Score: 95 | Business Value: 10 (business-critical) | Frequency: 9 (90% users)
-  // Behavior: User completes payment → Order created in DB + Payment recorded
-  // @category: core-functionality
-  // @dependency: PaymentService, OrderRepository, Database
-  // @real-dependency: OrderRepository, Database
-  // @complexity: high
-  // Primary failure mode: payment succeeds but the order row is absent or unpersisted
-  // Proof obligation: assert order persistence after successful payment while keeping OrderRepository and Database real; only the external payment gateway may be mocked
-  [Test: 'AC1: Successful payment creates persisted order with correct status']
-
-  // AC1-error: "Payment failure shows user-friendly error message"
-  // Value Score: 34 | Business Value: 8 (prevents support tickets) | Frequency: 2 (rare)
-  // Behavior: Payment fails → User sees actionable error + Order not created
-  // @category: core-functionality
-  // @dependency: PaymentService, ErrorHandler
-  // @complexity: medium
-  // Primary failure mode: payment failure still creates an order or hides the user-facing error
-  // Proof obligation: assert the visible error and the unchanged order state after a failed payment; mock only the external payment gateway failure
-  [Test: 'AC1: Failed payment displays error without creating order']
+//
+// Test case: AC1 successful payment creates persisted order
+// AC: "After successful payment, order is created and persisted"
+// Value Score: 95 | Business Value: 10 (business-critical) | Frequency: 9 (90% users)
+// Behavior: User completes payment -> Order created in DB + Payment recorded
+// @category: core-functionality
+// @lane: integration
+// @dependency: PaymentService, OrderRepository, Database
+// @real-dependency: OrderRepository, Database
+// @complexity: high
+// Primary failure mode: payment succeeds but the order row is absent or unpersisted
+// Proof obligation: assert order persistence after successful payment while keeping OrderRepository and Database real; only the external payment gateway may be mocked
+// Verification items:
+// - Persisted order exists with correct status
+// - Payment record exists
+//
+// Test case: AC1 payment failure displays error without creating order
+// AC: "Payment failure shows user-friendly error message"
+// Value Score: 34 | Business Value: 8 (prevents support tickets) | Frequency: 2 (rare)
+// Behavior: Payment fails -> User sees actionable error + Order not created
+// @category: core-functionality
+// @lane: integration
+// @dependency: PaymentService, ErrorHandler
+// @complexity: medium
+// Primary failure mode: payment failure still creates an order or hides the user-facing error
+// Proof obligation: assert the visible error and the unchanged order state after a failed payment; mock only the external payment gateway failure
+// Verification items:
+// - Visible actionable error appears
+// - Order count or order state remains unchanged
 ```
 
 ### fixture-e2e Test File
@@ -216,20 +223,20 @@ Adapt comment syntax to the project's language when generating annotations.
 // 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: 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
-  // Primary failure mode: undo banner appears but the dismissed card is not restored
-  // Proof obligation: assert browser-visible state before dismissal, after dismissal, and after undo using fixture-controlled backend state
-  [Test: 'User Journey: Dismiss and undo restores the card']
+//
+// 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
+// Primary failure mode: undo banner appears but the dismissed card is not restored
+// Proof obligation: assert browser-visible state before dismissal, after dismissal, and after undo using fixture-controlled backend state
+// Verification items:
+// - Card is visible before dismissal
+// - Undo banner is visible after dismissal
+// - Card is restored after undo
 ```
 
 ### service-integration-e2e Test File
@@ -239,72 +246,30 @@ Adapt comment syntax to the project's language when generating annotations.
 // 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
-  // Primary failure mode: checkout appears successful but the persisted order or confirmation event is missing
-  // Proof obligation: exercise the full local service stack and assert persisted order state plus confirmation event after checkout
-  [Test: 'User Journey: Complete product purchase persists order and emits confirmation']
+//
+// 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
+// Primary failure mode: checkout appears successful but the persisted order or confirmation event is missing
+// Proof obligation: exercise the full local service stack and assert persisted order state plus confirmation event after checkout
+// Verification items:
+// - Checkout completes
+// - Order row persists
+// - Confirmation event is emitted
 ```
 
 ### Generation Report
 
 ```json
-{
-  "status": "completed",
-  "feature": "[feature name]",
-  "generatedFiles": {
-    "integration": "[path]/[feature].int.test.[ext]",
-    "fixtureE2e": null,
-    "serviceE2e": null
-  },
-  "budgetUsage": {
-    "integration": "2/3",
-    "fixtureE2e": "0/3",
-    "serviceE2e": "0/2"
-  },
-  "e2eAbsenceReason": {
-    "fixtureE2e": "all_e2e_candidates_below_threshold",
-    "serviceE2e": "no_real_service_dependency"
-  },
-  "boundaryProofGaps": []
-}
+{"status":"completed","feature":"[feature name]","generatedFiles":{"integration":"[path]/[feature].int.test.[ext]","fixtureE2e":null,"serviceE2e":null},"budgetUsage":{"integration":"2/3","fixtureE2e":"0/3","serviceE2e":"0/2"},"e2eAbsenceReason":{"fixtureE2e":"all_e2e_candidates_below_threshold","serviceE2e":"no_real_service_dependency"},"boundaryProofGaps":[]}
 ```
 
 ```json
-{
-  "status": "completed",
-  "feature": "[feature name]",
-  "generatedFiles": {
-    "integration": "[path]/[feature].int.test.[ext]",
-    "fixtureE2e": "[path]/[feature].fixture.e2e.test.[ext]",
-    "serviceE2e": "[path]/[feature].service.e2e.test.[ext]"
-  },
-  "budgetUsage": {
-    "integration": "2/3",
-    "fixtureE2e": "1/3",
-    "serviceE2e": "1/2"
-  },
-  "e2eAbsenceReason": {
-    "fixtureE2e": null,
-    "serviceE2e": null
-  },
-  "boundaryProofGaps": [
-    {
-      "acId": "[AC-XXX]",
-      "boundaryPath": "[branch/state/input/lifecycle/fallback/visibility path]",
-      "reason": "budget_insufficient_for_boundary_proof"
-    }
-  ]
-}
+{"status":"completed","feature":"[feature name]","generatedFiles":{"integration":"[path]/[feature].int.test.[ext]","fixtureE2e":"[path]/[feature].fixture.e2e.test.[ext]","serviceE2e":"[path]/[feature].service.e2e.test.[ext]"},"budgetUsage":{"integration":"2/3","fixtureE2e":"1/3","serviceE2e":"1/2"},"e2eAbsenceReason":{"fixtureE2e":null,"serviceE2e":null},"boundaryProofGaps":[{"acId":"[AC-XXX]","boundaryPath":"[branch/state/input/lifecycle/fallback/visibility path]","reason":"budget_insufficient_for_boundary_proof"}]}
 ```
 
 ## Test Meta Information Assignment