codex-workflows 0.6.6 → 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

@@ -111,6 +111,7 @@ For each valid AC from Phase 1:
    - Happy path (1 test mandatory)
    - Error handling (only if user-visible error)
    - Edge cases (only if high business impact)
+   - Boundary path (behavior-changing AC only): when the AC can hold on the main path while a distinct branch, state, input class, lifecycle step, or fallback regresses, capture that boundary as a proof obligation. Prefer merging the boundary path into the selected happy-path or highest-value candidate; create a separate candidate only when the boundary needs separate setup.
 
 2. **Classify test level**:
    - Integration test candidate (feature-level interaction)
@@ -167,7 +168,8 @@ Value score and E2E selection rules are defined in **integration-e2e-testing ski
 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
+7. For every behavior-changing AC kept in scope, ensure at least one selected test represents its required boundary proof obligation. Merge the boundary path into a selected happy-path or highest-value candidate when possible; otherwise replace the lowest-value optional selected candidate. When required boundary obligations exceed the budget and no optional candidate is replaceable, keep the budget hard limit and add uncovered AC IDs and boundary paths to `boundaryProofGaps`.
+8. If a lane emits no tests, return its generated file as `null` with a concrete lane-specific absence reason
 ```
 
 **Output**: Final test set
@@ -178,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
@@ -214,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
@@ -237,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
@@ -272,7 +281,8 @@ Adapt comment syntax to the project's language when generating annotations.
   "e2eAbsenceReason": {
     "fixtureE2e": "all_e2e_candidates_below_threshold",
     "serviceE2e": "no_real_service_dependency"
-  }
+  },
+  "boundaryProofGaps": []
 }
 ```
 
@@ -293,7 +303,14 @@ Adapt comment syntax to the project's language when generating annotations.
   "e2eAbsenceReason": {
     "fixtureE2e": null,
     "serviceE2e": null
-  }
+  },
+  "boundaryProofGaps": [
+    {
+      "acId": "[AC-XXX]",
+      "boundaryPath": "[branch/state/input/lifecycle/fallback/visibility path]",
+      "reason": "budget_insufficient_for_boundary_proof"
+    }
+  ]
 }
 ```
 
@@ -306,7 +323,7 @@ Each test case MUST have the following standard annotations for test implementat
 - **@dependency**: none | [component names] | full-ui (mocked backend) | full-system
 - **@complexity**: low | medium | high
 - **Primary failure mode**: the specific regression that should make the implemented test fail
-- **Proof obligation**: what the implemented test must assert to prove the claim, including the boundary to exercise, before/action/after state for state-changing claims, and which boundaries may be mocked with rationale
+- **Proof obligation**: what the implemented test must assert to prove the claim, including the boundary to exercise, before/action/after state for state-changing claims, and which boundaries may be mocked with rationale. A behavior-changing AC is one whose promised observable behavior could still pass on the main path while a separate branch, state, input class, lifecycle step, fallback, or visibility boundary regresses. For behavior-changing ACs, name the boundary path the test must traverse when the main path alone would stay green through the regression
 
 These annotations are used when planning and prioritizing test implementation. Primary failure mode and proof obligation carry the proof contract to work-planner, task-decomposer, and integration-test-reviewer.
 

package/.codex/agents/code-reviewer.toml

@@ -75,6 +75,9 @@ For each acceptance criterion extracted in Step 1:
 - Determine status: fulfilled / partially fulfilled / unfulfilled
 - Record the file path and relevant code location
 - Note any deviations from the Design Doc specification
+- For behavior-changing ACs, confirm the evidence covers main and boundary paths. Where a distinct branch, state, input class, lifecycle step, or fallback governs the behavior, verify it is exercised. Compare source/referenced behavior and implemented behavior at the same granularity; an unsupported change in a boundary dimension is a `dd_violation`.
+- Confirm the implementation keeps the core mechanism the AC, Design Doc, or referenced materials require. A simpler substitute that passes tests but drops the required mechanism is a `dd_violation`.
+- For changes to persisted, shared, or externally observable state, identify the publication boundary where the new state becomes observable to another process, component, user, or later step. State that is observable as complete while still partial, uninitialized, stale, or rollback-only (written as a rollback/compensation path rather than committed usable state) is a `reliability` finding.
 
 #### 2-2. Identifier Verification
 For each identifier specification extracted in Step 1:

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

@@ -27,10 +27,7 @@ The task file is the single source of truth for write scope.
 
 ## Required Skills [LOADING PROTOCOL]
 
-For each [[skills.config]] entry:
-1. Verify the skill is loaded before any task work.
-2. If not loaded, read its SKILL.md.
-3. Record one evidence line per configured skill: `Skill Status: [path] - ACTIVE`.
+Confirm configured skills are active and record `Skill Status: [path] - ACTIVE` for each loaded skill.
 
 ## Mandatory Rules
 
@@ -79,6 +76,12 @@ Use the appropriate run command based on the `packageManager` field in package.j
 
 **Low Duplication (Continue Implementation)** - 1 or fewer items match
 
+### Step4: Core Mechanism Check (Failure of either check → Immediate Escalation)
+Step1 catches contract/structure deviations; Step4 catches visible-contract-compatible substitutes that drop the required mechanism.
+□ Planned implementation preserves the mechanism required by task/AC/Design Doc/UI Spec/references?
+□ Required mechanism is feasible as specified?
+Failure of either check → return `design_compliance_violation` with source expectation, substitute, behavior change, and unblock condition.
+
 ### Safety Measures: Handling Ambiguous Cases
 
 **Gray Zone Examples (Escalation Recommended)**:
@@ -171,16 +174,7 @@ Run this check after Pre-implementation Verification and before behavior-first i
 
 #### Reference Representativeness (Applied During Implementation)
 
-When adopting a pattern, UI composition, or dependency from existing code, apply repository-wide representativeness checks at the point of adoption:
-
-□ **Repository-wide verification**: Confirm the referenced pattern is representative across the repository, not just the nearest 2-3 files
-□ **Dependency version verification** (when adopting external dependencies):
-  - verify repository-wide usage distribution for the same dependency
-  - if following one existing version when alternatives exist, state the reason
-  - if repository-wide verification is insufficient to determine the appropriate dependency version or pattern choice, escalate with `reason: "Dependency version uncertain"` and `escalation_type: "dependency_version_uncertain"`
-□ **Coexistence resolution**: When multiple patterns or versions coexist, identify the majority before choosing
-
-This is a repeated self-check during implementation, not a one-time pre-implementation gate.
+During implementation, apply coding-rules Reference Representativeness before adopting existing patterns, UI composition, or dependency versions. Record majority/coexistence rationale; when repository-wide evidence is insufficient for dependency version or pattern choice, escalate with `reason: "Dependency version uncertain"` and `escalation_type: "dependency_version_uncertain"`.
 
 #### Implementation Flow (Behavior-First RTL)
 **Completion Confirmation**: If all checkboxes are `[x]`, report "already completed" and end
@@ -260,6 +254,8 @@ Report in the following JSON format upon task completion (**without executing qu
 When unable to implement per Design Doc, escalate in following JSON format:
 
 Use Binding Decision Violation Escalation instead when the task has a Binding Decisions row covering the same issue.
+For task/AC/UI Spec/reference core-mechanism sources, set `details.design_doc_expectation` to `[source type] [location]: [cited expectation]`.
+For core-mechanism violations, put the substitute in `details.actual_situation`, the behavior change in `details.why_cannot_implement`, and the unblock condition in `recommendation`.
 
 ```json
 {
@@ -426,13 +422,14 @@ Triggered when the Test Environment Check finds the project-configured test tool
 ☐ Investigation Targets were processed, or marked N/A when the task file has no Investigation Targets section
 ☐ Investigation Notes were updated before implementation when Investigation Targets exist
 ☐ Implementation is consistent with the observations recorded in Investigation Notes
+☐ Final implementation preserves the required core mechanism from the task, AC, Design Doc, UI Spec, or referenced materials, with evidence recorded in Investigation Notes or runnableCheck.reason
 ☐ Every Binding Decisions Compliance Check evaluates to `Y` against the final implementation, with evidence recorded in Investigation Notes (when the task file has a Binding Decisions section)
 ☐ When test runs are cited as `runnableCheck` evidence, they are substantive per the `runnableCheck.result` field spec; non-test verification is evaluated by command success
 ☐ Output format validated (JSON response with all required fields)
 ☐ Quality standards satisfied (tests pass, progress updated)
 ☐ Final response is a single JSON with status `completed` or `escalation_needed`
 
-**ENFORCEMENT**: HALT if any gate unchecked. Return `status: "escalation_needed"` to caller. Use `escalation_type: "binding_decision_violation"` with `phase: "completion_gate"` when the unchecked item is a Binding Decisions Compliance Check. Use `escalation_type: "design_compliance_violation"` for other completion gate failures.
+**ENFORCEMENT**: HALT if any gate unchecked. Return `status: "escalation_needed"` to caller. Use `escalation_type: "binding_decision_violation"` with `phase: "completion_gate"` when the unchecked item is a Binding Decisions Compliance Check. Use `escalation_type: "design_compliance_violation"` for core mechanism preservation or other completion gate failures.
 
 """
 

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

@@ -27,10 +27,7 @@ The task file is the single source of truth for write scope.
 
 ## Required Skills [LOADING PROTOCOL]
 
-For each [[skills.config]] entry:
-1. Verify the skill is loaded before any task work.
-2. If not loaded, read its SKILL.md.
-3. Record one evidence line per configured skill: `Skill Status: [path] - ACTIVE`.
+Confirm configured skills are active and record `Skill Status: [path] - ACTIVE` for each loaded skill.
 
 ## Mandatory Rules
 
@@ -75,6 +72,12 @@ For each [[skills.config]] entry:
 
 **Low Duplication (Continue Implementation)** - 1 or fewer items match
 
+### Step4: Core Mechanism Check (Failure of either check → Immediate Escalation)
+Step1 catches contract/structure deviations; Step4 catches visible-contract-compatible substitutes that drop the required mechanism.
+- Planned implementation preserves the mechanism required by task/AC/Design Doc/references?
+- Required mechanism is feasible as specified?
+Failure of either check → return `design_compliance_violation` with source expectation, substitute, behavior change, and unblock condition.
+
 ### Safety Measures: Handling Ambiguous Cases
 
 **Gray Zone Examples (Escalation Recommended)**:
@@ -171,16 +174,7 @@ Run this check after Pre-implementation Verification and before the TDD cycle wh
 
 #### Reference Representativeness (Applied During Implementation)
 
-When adopting a pattern, API usage, or dependency from existing code, apply repository-wide representativeness checks at the point of adoption:
-
-□ **Repository-wide verification**: Confirm the referenced pattern is representative across the repository, not just the nearest 2-3 files
-□ **Dependency version verification** (when adopting external dependencies):
-  - verify repository-wide usage distribution for the same dependency
-  - if following one existing version when alternatives exist, state the reason
-  - if repository-wide verification is insufficient to determine the appropriate dependency version or pattern choice, escalate with `reason: "Dependency version uncertain"` and `escalation_type: "dependency_version_uncertain"`
-□ **Coexistence resolution**: When multiple versions or patterns coexist, identify the majority before choosing
-
-This is a repeated self-check during implementation, not a one-time pre-implementation gate.
+During implementation, apply coding-rules Reference Representativeness before adopting existing patterns, API usage, or dependency versions. Record majority/coexistence rationale; when repository-wide evidence is insufficient for dependency version or pattern choice, escalate with `reason: "Dependency version uncertain"` and `escalation_type: "dependency_version_uncertain"`.
 
 #### Implementation Flow (TDD Compliant)
 
@@ -259,6 +253,8 @@ Report in the following JSON format upon task completion (**without executing qu
 When unable to implement per Design Doc, escalate in following JSON format:
 
 Use Binding Decision Violation Escalation instead when the task has a Binding Decisions row covering the same issue.
+For task/AC/reference core-mechanism sources, set `details.design_doc_expectation` to `[source type] [location]: [cited expectation]`.
+For core-mechanism violations, put the substitute in `details.actual_situation`, the behavior change in `details.why_cannot_implement`, and the unblock condition in `recommendation`.
 
 ```json
 {
@@ -425,13 +421,14 @@ Triggered when the Test Environment Check finds the project-configured test tool
 ☐ Investigation Targets were processed, or marked N/A when the task file has no Investigation Targets section
 ☐ Investigation Notes were updated before implementation when Investigation Targets exist
 ☐ Implementation is consistent with the observations recorded in Investigation Notes
+☐ Final implementation preserves the required core mechanism from the task, AC, Design Doc, or referenced materials, with evidence recorded in Investigation Notes or runnableCheck.reason
 ☐ Every Binding Decisions Compliance Check evaluates to `Y` against the final implementation, with evidence recorded in Investigation Notes (when the task file has a Binding Decisions section)
 ☐ When test runs are cited as `runnableCheck` evidence, they are substantive per the `runnableCheck.result` field spec; non-test verification is evaluated by command success
 ☐ Output format validated (JSON response with all required fields)
 ☐ Quality standards satisfied (tests pass, progress updated)
 ☐ Final response is a single JSON with status `completed` or `escalation_needed`
 
-**ENFORCEMENT**: HALT if any gate unchecked. Return `status: "escalation_needed"` to caller. Use `escalation_type: "binding_decision_violation"` with `phase: "completion_gate"` when the unchecked item is a Binding Decisions Compliance Check. Use `escalation_type: "design_compliance_violation"` for other completion gate failures.
+**ENFORCEMENT**: HALT if any gate unchecked. Return `status: "escalation_needed"` to caller. Use `escalation_type: "binding_decision_violation"` with `phase: "completion_gate"` when the unchecked item is a Binding Decisions Compliance Check. Use `escalation_type: "design_compliance_violation"` for core mechanism preservation or other completion gate failures.
 
 """
 

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

@@ -18,15 +18,7 @@ You are a frontend technical design specialist AI assistant for creating Archite
 
 Verify skills from [[skills.config]] are active. For each inactive skill, execute BLOCKING READ of SKILL.md, then confirm all skills active before proceeding.
 
-**EVIDENCE REQUIRED:**
-```
-Skill Status:
-✓ documentation-criteria/SKILL.md - ACTIVE
-✓ coding-rules/SKILL.md - ACTIVE
-✓ testing/SKILL.md - ACTIVE
-✓ ai-development-guide/SKILL.md - ACTIVE
-✓ implementation-approach/SKILL.md - ACTIVE
-```
+**EVIDENCE REQUIRED:** Record `Skill Status: [path] - ACTIVE` for each loaded skill.
 
 ## Initial Mandatory Tasks
 
@@ -35,11 +27,7 @@ Skill Status:
 
 ## Document Creation Criteria
 
-Follow documentation-criteria skill. If scale or document-type assessments conflict, report the discrepancy in output.
-Representative triggers:
-- ADR: component architecture, state-management, React pattern, or external library changes
-- Design Doc: 3+ component/file changes, complex state management, or new React patterns/custom hooks
-
+Follow documentation-criteria skill for document selection. If scale or document-type assessments conflict, report the discrepancy in output.
 When `confirmed_requirement_context.documentTypeRationale` is provided by the orchestrator, treat it as the authority for the overall confirmed document path. When `document_to_create` is also provided, it is the authority for the current invocation's single document output. Do not re-derive or override either value. If they conflict with the criteria above, report the discrepancy inside the created document and follow the orchestrator-provided values.
 
 ## Mandatory Process Before Design Doc Creation
@@ -100,34 +88,7 @@ For each integration boundary, define:
 
 ### Minimal Surface Alternatives【Required when introducing maintenance-surface elements】
 
-Applies to each maintenance-surface-bearing element the design introduces. The goal is to select the smallest design surface that satisfies the same current requirements. Use the canonical in-scope, out-of-scope, precedence, and subjective-only rationale definitions from coding-rules skill, "Minimum Surface Terms".
-
-Frontend examples: persistent client/server state (localStorage, sessionStorage, IndexedDB, cookies, server-saved fields, URL state intended as a durable contract), props or fields crossing component boundaries, Context values, lifted state, behavioral modes/variants, mode props, reusable component splits, extracted custom hooks, or shared utilities intended for multiple parents. Local render-only state or private hooks used by one component stay out of scope unless they cross a public or component boundary.
-
-Execute the 5 steps below for each in-scope element, and record the result in the Design Doc's "Minimal Surface Alternatives" section. If no in-scope elements are introduced, mark the section as N/A with rationale.
-
-1. **Fix Requirements**
-   - List the current user-visible requirements / ACs / accepted technical constraints (accessibility, performance, security, compatibility, data integrity) this element would serve, citing AC IDs or constraint IDs from the Design Doc or referenced UI Spec.
-   - Eligibility rule: only requirements / constraints that are part of the current Design Doc's adopted scope qualify. Future-only, speculative, or "users might want" requirements are out of scope for this list.
-
-2. **Diverge** (generate alternatives)
-   - Produce at least 2 alternative realizations that cover the same fixed requirements.
-   - At least one alternative must be subtractive. Subtractive alternatives include deriving from existing props/state, keeping responsibility at the caller, reusing an existing component/variant/hook, computing on render, or not introducing a new mode / prop / state field.
-
-3. **Compare** (record alternatives in a table)
-
-   | Alternative | Current requirements covered (AC or constraint IDs) | New state introduced (count) | New concept / mode / flag / prop / variant (count) | Crosses component boundary (yes/no) | Breaking change or migration required (yes/no) | Subjective cost notes |
-   |-------------|------------------------------------------------------|------------------------------|--------------------------------------|--------------------------------------|-------------------------------------------------|-----------------------|
-
-   Resolution priority (later columns are tiebreakers when earlier are equal): (1) new persistent state (lower=smaller); (2) crosses component boundary (no=smaller); (3) new concepts/modes/flags/props/variants (lower=smaller); (4) breaking change or migration (no=smaller); (5) subjective cost notes.
-
-4. **Converge** (select)
-   - Select the alternative with the smallest surface that covers all fixed requirements, applying the resolution priority above.
-   - When the selected alternative is not the smallest, name the current requirement from step 1 that smaller alternatives fail to satisfy.
-   - Subjective-only rationales from coding-rules belong in the Subjective cost notes column as tiebreakers only.
-
-5. **Record Rejected Alternatives**
-   - For each rejected alternative, record 1-2 lines: what it was, why rejected. Include this in the Design Doc to prevent re-proposal in later iterations.
+For each maintenance-surface-bearing element, apply coding-rules "Minimum Surface Terms" and record the result in the Design Doc: fixed current requirements, at least 2 alternatives including one subtractive alternative, comparison by the required table axes, selected smallest sufficient alternative, and rejected alternatives log. Resolve ties by lower persistent state, no boundary crossing, fewer concepts/modes/flags/props/variants, no breaking change/migration, then subjective notes. Frontend candidates include durable client/server state, cross-boundary props/fields, Context values, lifted state, behavioral modes/variants, reusable component splits, extracted hooks, and shared utilities. If no in-scope elements are introduced, mark the section N/A with rationale.
 
 ### Agreement Checklist【Most Important】
 Must be performed at the beginning of Design Doc creation:
@@ -146,52 +107,16 @@ Must be performed at the beginning of Design Doc creation:
 ### Implementation Approach Decision【Required】
 Must be performed when creating Design Doc:
 
-1. **Approach Selection Criteria**
-   - Execute Phase 1-4 of implementation-approach skill to select strategy
-   - **Vertical Slice**: Complete by feature unit, minimal component dependencies, early value delivery
-   - **Horizontal Slice**: Implementation by the project's component layering convention. Use Atomic Design layer names only when the project already adopts Atomic Design.
-   - **Hybrid**: Composite, handles complex requirements
-   - Document selection reason (record results of metacognitive strategy selection process)
-
-2. **Integration Point Definition**
-   - Which task first makes the entire UI operational
-   - Verification level for each task (L1/L2/L3 defined in implementation-approach skill)
-
-3. **Verification Strategy Definition**
-   - Define what correctness means for this UI change and how it will be proven
-   - Use the Design Doc template fields directly
-   - Include at minimum: correctness definition, target comparison, verification method, observable success indicator, verification timing, and early verification point
-   - Use normalized verification timing values: `phase_1`, `per_phase`, `integration_phase`, or `final_phase`
-   - For low-risk or self-evident changes, a minimal form or explicit `N/A` with rationale is acceptable
-   - For new UI features, specify acceptance-criteria verification beyond unit tests
-   - For extensions, specify regression verification that proves existing behavior and UX expectations are preserved
-   - For refactors or rewrites, specify behavioral equivalence verification against the current UI behavior when applicable
-   - Define an early verification point: the first screen, state transition, or interaction that proves the approach works
+Follow implementation-approach skill and record: selected strategy, rationale, first task that makes the UI operational, task verification levels, correctness definition, target comparison, verification method, observable success indicator, timing (`phase_1` / `per_phase` / `integration_phase` / `final_phase`), and early verification point. For UI behavior extensions/refactors, include regression or behavioral-equivalence verification against current UI behavior and UX expectations.
 
 ### Change Impact Map【Required】
 Must be included when creating Design Doc:
 
-```yaml
-Change Target: UserProfileCard component
-Direct Impact:
-  - src/components/UserProfileCard/UserProfileCard.tsx (Props change)
-  - src/pages/ProfilePage.tsx (usage site)
-Indirect Impact:
-  - User context (data format change)
-  - Theme settings (style prop additions)
-No Ripple Effect:
-  - Other components, API endpoints
-```
+Record direct impact, indirect impact, and explicitly unaffected components/routes/API contracts in the Design Doc Change Impact Map.
 
 ### Interface Change Impact Analysis【Required】
 
-**Component Props Change Matrix:**
-| Existing Props | New Props | Conversion Required | Wrapper Required | Compatibility Method |
-|----------------|-----------|-------------------|------------------|---------------------|
-| userName       | userName  | None              | Not Required     | -                   |
-| profile        | userProfile| Yes             | Required         | Props mapping wrapper |
-
-When conversion is required, clearly specify wrapper implementation or migration path.
+Record existing props/contracts, new props/contracts, conversion need, wrapper need, and compatibility method. When conversion is required, specify wrapper implementation or migration path.
 
 ### Common ADR Process
 Perform before Design Doc creation:
@@ -364,6 +289,10 @@ Implementation sample creation checklist:
 **Example**: "Form works" → "After entering valid email and password, clicking submit button calls API and displays success message"
 Cover happy path, unhappy path, and edge cases including empty and loading states. Place important criteria first.
 
+### Boundary-Aware AC Drafting
+
+Draft behavior-changing ACs value-first: user value, then observable UI behavior. Record technical boundaries as proof metadata or verification context, using them as pass/fail conditions only when externally observable. For boundary paths where the happy path can pass while branch/state/input/lifecycle/fallback/visibility behavior regresses, consider list scope, sibling props/fields, loading/empty/error and later interaction states, stale/missing data, failed fetch/fallback UI, permission/validation, ordering/selection, side effects, and route/visibility. Compare existing/referenced and target behavior at the same granularity.
+
 ### AC Scoping for Autonomous Implementation (Frontend)
 
 **Include** (High automation value):

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

@@ -15,39 +15,21 @@ You are a technical design specialist AI assistant for creating Architecture Dec
 **ENFORCEMENT**: HALT and return to caller if any gate unchecked
 
 ## Required Skills [LOADING PROTOCOL]
-
 Verify skills from [[skills.config]] are active. For each inactive skill, execute BLOCKING READ of SKILL.md, then confirm all skills active before proceeding.
 
-**EVIDENCE REQUIRED:**
-```
-Skill Status:
-✓ documentation-criteria/SKILL.md - ACTIVE
-✓ coding-rules/SKILL.md - ACTIVE
-✓ testing/SKILL.md - ACTIVE
-✓ ai-development-guide/SKILL.md - ACTIVE
-✓ implementation-approach/SKILL.md - ACTIVE
-```
+**EVIDENCE REQUIRED:** Record `Skill Status: [path] - ACTIVE` for each loaded skill.
 
 ## Initial Mandatory Tasks
-
 **Progress Tracking**: Track work steps. Always include first "Confirm skill constraints" and final "Verify skill fidelity"; update progress upon completion.
 **Current Date Retrieval**: Before starting, retrieve the actual current date from the operating environment.
 
 ## Document Creation Criteria
-
-Follow documentation-criteria skill. If scale or document-type assessments conflict, report the discrepancy in output.
-Representative triggers:
-- ADR: contract, architecture, data-flow, or external dependency changes
-- Design Doc: 3+ file changes, complex implementation logic, or new algorithms/patterns
-
+Follow documentation-criteria skill for document selection. If scale or document-type assessments conflict, report the discrepancy in output.
 When `confirmed_requirement_context.documentTypeRationale` is provided by the orchestrator, treat it as the authority for the overall confirmed document path. When `document_to_create` is also provided, it is the authority for the current invocation's single document output. Do not re-derive or override either value. If they conflict with the criteria above, report the discrepancy inside the created document and follow the orchestrator-provided values.
 
 ## Mandatory Process Before Design Doc Creation
-
 ### External Resources Integration
-
 When external resources are recorded for the project:
-
 1. Read `docs/project-context/external-resources.md`
 2. Read the target Design Doc's `External Resources Used` section in update mode
 3. Fill the Design Doc `External Resources Used` subsection with project resource labels and feature-specific identifiers for API, backend, data, or infrastructure sources
@@ -55,7 +37,6 @@ When external resources are recorded for the project:
 
 ### Standards Identification Gate【Required】
 Must be performed before any investigation:
-
 1. **Identify Project Standards**
    - Scan project configuration, rule files, and existing code patterns
    - Classify each: **Explicit** (documented) or **Implicit** (observed pattern only)
@@ -131,34 +112,7 @@ When the design introduces or significantly modifies data structures:
 
 ### Minimal Surface Alternatives【Required when introducing maintenance-surface elements】
 
-Applies to each maintenance-surface-bearing element the design introduces. The goal is to select the smallest design surface that satisfies the same current requirements. Use the canonical in-scope, out-of-scope, precedence, and subjective-only rationale definitions from coding-rules skill, "Minimum Surface Terms".
-
-Examples: database columns, stored records, cache entries, config values, local files, queue payloads, client storage, public-contract fields, cross-boundary fields/props, behavioral modes/flags/variants, reusable abstractions, extracted services, shared utilities, or component splits.
-
-Execute the 5 steps below for each in-scope element, and record the result in the Design Doc's "Minimal Surface Alternatives" section. If no in-scope elements are introduced, mark the section as N/A with rationale.
-
-1. **Fix Requirements**
-   - List the current user-visible requirements / ACs / accepted technical constraints (audit, data integrity, compatibility, security, performance, accessibility) this element would serve, citing AC IDs or constraint IDs from the Design Doc.
-   - Eligibility rule: only requirements / constraints that are part of the current Design Doc's adopted scope qualify. Future-only, speculative, or "users might want" requirements are out of scope for this list.
-
-2. **Diverge** (generate alternatives)
-   - Produce at least 2 alternative realizations that cover the same fixed requirements.
-   - At least one alternative must be subtractive. Subtractive alternatives include deriving from existing data, computing on demand, keeping responsibility at the caller, reusing existing structures, or not introducing new state / mode / abstraction.
-
-3. **Compare** (record alternatives in a table)
-
-   | Alternative | Current requirements covered (AC or constraint IDs) | New state introduced (count) | New concept / mode / flag / prop / variant (count) | Crosses component boundary (yes/no) | Breaking change or migration required (yes/no) | Subjective cost notes |
-   |-------------|------------------------------------------------------|------------------------------|------------------------------------|--------------------------------------|-------------------------------------------------|-----------------------|
-
-   Resolution priority (later columns are tiebreakers when earlier are equal): (1) new persistent state (lower=smaller); (2) crosses component boundary (no=smaller); (3) new concepts/modes/flags/props/variants (lower=smaller); (4) breaking change or migration (no=smaller); (5) subjective cost notes.
-
-4. **Converge** (select)
-   - Select the alternative with the smallest surface that covers all fixed requirements, applying the resolution priority above.
-   - When the selected alternative is not the smallest, name the current requirement from step 1 that smaller alternatives fail to satisfy.
-   - Subjective-only rationales from coding-rules belong in the Subjective cost notes column as tiebreakers only.
-
-5. **Record Rejected Alternatives**
-   - For each rejected alternative, record 1-2 lines: what it was, why rejected. Include this in the Design Doc to prevent re-proposal in later iterations.
+For each maintenance-surface-bearing element, apply coding-rules "Minimum Surface Terms" and record the result in the Design Doc: fixed current requirements, at least 2 alternatives including one subtractive alternative, comparison by the required table axes, selected smallest sufficient alternative, and rejected alternatives log. Resolve ties by lower persistent state, no boundary crossing, fewer concepts/modes/flags/props/variants, no breaking change/migration, then subjective notes. If no in-scope elements are introduced, mark the section N/A with rationale.
 
 ### Integration Points【Important】
 Document all integration points with existing systems in a "## Integration Point Map" section.
@@ -196,44 +150,12 @@ Must be performed at the beginning of Design Doc creation:
 ### Implementation Approach Decision【Required】
 Must be performed when creating Design Doc:
 
-1. **Approach Selection Criteria**
-   - Follow the principles in implementation-approach skill to select strategy
-   - **Vertical Slice**: Complete by feature unit, minimal external dependencies, early value delivery
-   - **Horizontal Slice**: Implementation by layer, important common foundation, technical consistency priority
-   - **Hybrid**: Composite, handles complex requirements
-   - Document selection reason (record results of metacognitive strategy selection process)
-
-2. **Integration Point Definition**
-   - Which task first makes the whole system operational
-   - Verification level for each task (L1/L2/L3 defined in implementation-approach skill)
-
-3. **Verification Strategy Definition**
-   - Define what correctness means for this change and how it will be proven
-   - Use the Design Doc template fields directly
-   - Include at minimum: correctness definition, target comparison, verification method, observable success indicator, verification timing, and early verification point
-   - Use normalized verification timing values: `phase_1`, `per_phase`, `integration_phase`, or `final_phase`
-   - For low-risk or self-evident changes, a minimal form or explicit `N/A` with rationale is acceptable
-   - For new features, specify acceptance-criteria verification beyond unit tests
-   - For extensions, specify regression verification that proves existing behavior is preserved
-   - For refactors or rewrites, specify behavioral equivalence verification against the current implementation when applicable
-   - When the design changes existing observable behavior, an external contract, or a persisted data shape, define a concrete `Output Comparison` method: identical input, expected output fields or format, diff method, and a mapping from each listed pipeline step to the comparison that verifies it
-   - When `Codebase Analysis` provides `dataTransformationPipelines`, use them to populate the `Output Comparison` section. Steps that pass data through unchanged may be excluded only with explicit rationale
-   - Define an early verification point: the first target to validate before scaling the approach. For changes to existing observable behavior, external contracts, or persisted data shapes, this must be an output comparison of at least one representative case
+Follow implementation-approach skill and record: selected strategy, rationale, first task that makes the system operational, task verification levels, correctness definition, target comparison, verification method, observable success indicator, timing (`phase_1` / `per_phase` / `integration_phase` / `final_phase`), and early verification point. For existing observable behavior, external contract, or persisted data shape changes, include Output Comparison: identical input, expected output fields/format, diff method, each transformation-pipeline step mapped to a comparison, explicit rationale for excluded unchanged steps, and at least one representative early comparison.
 
 ### Change Impact Map【Required】
 Must be included when creating Design Doc:
 
-```yaml
-Change Target: [ServiceName.methodName()]
-Direct Impact:
-  - [service file path] (method change)
-  - [API handler path] (call site)
-Indirect Impact:
-  - [Component name] (data format change)
-  - [Component name] (new fields added)
-No Ripple Effect:
-  - [Explicitly list unaffected components]
-```
+Record direct impact, indirect impact, and explicitly unaffected components in the Design Doc Change Impact Map.
 
 ### Field Propagation Map【Required】
 When new or changed fields cross component boundaries:
@@ -243,13 +165,7 @@ Skip if no fields cross component boundaries.
 
 ### Interface Change Impact Analysis【Required】
 
-**Change Matrix:**
-| Existing Operation | New Operation | Conversion Required | Adapter Required | Compatibility Method |
-|-------------------|---------------|-------------------|------------------|---------------------|
-| operationA()      | operationA()  | None              | Not Required     | -                   |
-| operationB(x)     | operationC(x,y)| Yes             | Required         | Adapter implementation |
-
-When conversion is required, clearly specify adapter implementation or migration path.
+Record existing operation, new operation, conversion need, adapter/wrapper need, and compatibility method. When conversion is required, specify adapter implementation or migration path.
 
 ### Common ADR Process
 Perform before Design Doc creation:
@@ -268,7 +184,6 @@ Document state definitions and transitions for stateful components.
 Confirm and document conflicts with existing systems at each integration point to prevent inconsistencies.
 
 ## Required Information
-
 - **Operation Mode**:
   - `create`: New creation (default)
   - `update`: Update existing document
@@ -316,14 +231,12 @@ Confirm and document conflicts with existing systems at each integration point t
   - Unit Inventory (routes, test files, public exports)
 
 ## Document Output Format
-
 ### Document Creation
 - **ADR**: `docs/adr/ADR-[4-digit number]-[title].md`; check existing numbers, use max+1, initial status "Proposed"
 - **Design Doc**: `docs/design/[feature-name]-design.md`
 - Follow respective templates (`template.md`)
 
 ## ADR Responsibility Boundaries
-
 Include in ADR: decisions, rationale, principled guidelines. Exclude: schedules, implementation procedures, specific code.
 Implementation guidelines MUST only include principles (e.g., "Use dependency injection" is correct, "Implement in Phase 1" is not).
 
@@ -386,11 +299,14 @@ Implementation sample creation checklist:
 
 
 ## Acceptance Criteria Creation Guidelines
-
 **Principle**: Set specific, verifiable conditions. Avoid ambiguous expressions and make each criterion convertible to tests.
 **Example**: "Login works" → "After authentication with correct credentials, navigates to dashboard screen"
 Cover happy path, unhappy path, and edge cases. Place important criteria first.
 
+### Boundary-Aware AC Drafting
+
+Draft behavior-changing ACs value-first: user/operator/maintainer value, then observable behavior. Record technical boundaries as proof metadata or verification context, using them as pass/fail conditions only when externally observable. For boundary paths where the main path can pass while branch/state/input/lifecycle/fallback/visibility behavior regresses, consider collection scope, sibling fields, lifecycle/retry, stale/missing data, failed refresh/fallback, permission/validation, ordering/identity, side effects, and publication/visibility. Compare existing/referenced and target behavior at the same granularity.
+
 ### AC Scoping for Autonomous Implementation
 
 **Include** (High automation value):

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "codex-workflows",
-  "version": "0.6.6",
+  "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",