codex-workflows 0.6.7 → 0.6.8

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/.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,20 +246,20 @@ 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

package/package.json

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