create-ai-project 1.20.9 → 1.22.0

package/.claude/commands-en/build.md

@@ -18,33 +18,76 @@ Work plan: $ARGUMENTS
 
 ## Pre-execution Prerequisites
 
-### Task File Existence Check
-```bash
-# Check work plans
-! ls -la docs/plans/*.md | grep -v template | tail -5
+### Implementation Readiness Check
 
-# Check task files
-! ls docs/plans/tasks/*.md 2>/dev/null || echo "⚠️ No task files found"
-```
+Before any task processing, locate the work plan to gate against.
+
+**When `$ARGUMENTS` is provided**, it is the work plan path supplied by the user. Use it directly without auto-resolution. Extract `{plan-name}` from the filename by stripping the `.md` extension (and any trailing `-plan` suffix when present).
+
+**When `$ARGUMENTS` is empty**, auto-resolve from task files:
+1. List task files in `docs/plans/tasks/` matching this recipe's consumable patterns (these correspond to the routes in subagents-orchestration-guide "Layer-Aware Agent Routing" that go through `task-executor`):
+   - `{plan-name}-task-*.md` (single-layer; reserved for backend by the routing table)
+   - `{plan-name}-backend-task-*.md` (backend portion of a multi-layer plan)
+   - `{plan-name}-frontend-task-*.md` is **not** consumable by this recipe — it routes to `task-executor-frontend` and is owned by the frontend build recipe
+2. From the matched files, also exclude every file matching any of these patterns — they originate from other workflow phases and are not implementation tasks for this run's plan: `*-task-prep-*.md` (readiness preflight tasks), `_overview-*.md` (decomposition overview file), `*-phase*-completion.md` (per-phase completion files), `review-fixes-*.md` (post-implementation review fixes), `integration-tests-*-task-*.md` (integration-test add-on scaffolding)
+3. For each remaining file, extract `{plan-name}` by stripping the trailing `-task-{NN}.md` or `-backend-task-{NN}.md` suffix
+4. When at least one task file matches, the work plan is `docs/plans/{plan-name}.md` for the prefix that has the most recent task-file mtime; ties broken by the lexicographically last `{plan-name}`
+5. **When the consumable patterns find no matches but `*-frontend-task-*.md` files exist in `docs/plans/tasks/`**: stop and report: "Only frontend-named task files were found. If you intended to run the frontend build recipe, switch to it. If the plan is backend, re-run task-decomposer so it emits backend-named task files, or pass the work plan path as `$ARGUMENTS`."
+6. When neither consumable patterns nor `*-frontend-task-*.md` match, fall back to the most-recent-mtime non-template `.md` in `docs/plans/` ONLY after **positively verifying the plan is a backend plan**. Absence of frontend markers is not enough — many plan templates include layer-neutral paths (e.g., `src/presentation`, `src/app`) that match neither marker set, so a confirmed backend signal is required. Read the plan and check:
+
+   **Backend signals (need at least one)**:
+   - Target Files in `## Impact Scope > ### Target Files` (or equivalent) exclusively match backend markers: `**/api/**`, `**/server/**`, `**/services/**`, `**/backend/**`, `**/handlers/**`, `**/repositories/**`, or the project's backend-equivalent paths declared in `technical-spec` skill
+   - The plan's `## Related Documents` references a Design Doc whose filename explicitly identifies it as backend (e.g., `*-backend-design.md`, `backend-*-design.md`)
+   - The plan title, `## Objective`, or `## Background` section explicitly identifies the work as backend (e.g., "backend implementation", "API endpoint", "database migration", "server-side")
+
+   **Frontend signals (any disqualifies, even if a backend signal is also present)**:
+   - `## Related Documents` entry pointing to `docs/ui-spec/*`
+   - An `## UI Spec Component → Task Mapping` section
+   - Target Files exclusively under frontend paths (`**/components/**`, `**/pages/**`, `**/web/**`, `**/*.tsx`, `**/*.jsx`)
+   - Plan title or objective explicitly mentions React, UI components, screens, or frontend
+
+   **Decision**:
+   - At least one backend signal AND zero frontend signals → plan is acceptable; proceed
+   - Otherwise (no backend signal found, OR any frontend signal present, OR layer-neutral paths only) → stop and report: "Cannot positively verify the most-recent work plan at `[path]` is a backend plan (signals examined: [list of signals checked and their results]). Pass the intended backend plan path as `$ARGUMENTS`, or run task-decomposer first to populate `docs/plans/tasks/` with backend-named task files."
+7. When no plan exists at all in `docs/plans/`, stop and report: "No work plan found. Pass a work plan path as `$ARGUMENTS`, or complete the planning phase first."
+
+Read the work plan header and find the line `Implementation Readiness: <status>`. Apply this rule:
+
+| Status | Action |
+|--------|--------|
+| `ready` | Proceed to Consumed Task Set computation |
+| `escalated` | Read the work plan's Readiness Report section, surface remaining gaps to the user via AskUserQuestion: "Implementation Readiness is `escalated` with the following remaining gaps: [list]. Continue execution? (y/n)". On `y` proceed; on `n` stop |
+| `pending` | Present via AskUserQuestion: "Implementation Readiness is `pending`. Run the readiness preflight first to verify the work plan is implementable, then resume. Continue without preflight? (y/n)". On `y` proceed; on `n` stop |
+| absent (line missing) | Treat as `pending` — older work plans created before the readiness marker existed should be preflighted explicitly |
+
+### Consumed Task Set
+
+Compute the **Consumed Task Set** for this run — the exact files this recipe owns, executes, and later deletes. Use the same consumable patterns as the Implementation Readiness Check:
+
+1. List task files in `docs/plans/tasks/` matching `{plan-name}-task-*.md` OR `{plan-name}-backend-task-*.md` for the `{plan-name}` resolved by the readiness check. `{plan-name}-frontend-task-*.md` is excluded — it is owned by the frontend build recipe
+2. Exclude every file matching: `*-task-prep-*.md`, `_overview-*.md`, `*-phase*-completion.md`, `review-fixes-*.md`, `integration-tests-*-task-*.md` (these originate from other workflow phases)
+
+Every subsequent reference to "task files" in this recipe — Task Generation Decision Flow, Task Execution Cycle iteration, and Final Cleanup — uses this set, not the unrestricted `docs/plans/tasks/*.md` glob.
 
 ### Task Generation Decision Flow
 
-Analyze task file existence state and determine the action required:
+Analyze the Consumed Task Set and determine the action required. Reaching this section implies the readiness check above resolved a work plan (Steps 1-6 succeeded); the "no plan" state is already terminated by readiness-check Step 7 and never reaches this table.
 
 | State | Criteria | Next Action |
 |-------|----------|-------------|
-| Tasks exist | .md files in tasks/ directory | User's execution instruction serves as batch approval → Enter autonomous execution immediately |
-| No tasks + plan exists | Plan exists but no task files | Confirm with user → run task-decomposer |
-| Neither exists + Design Doc exists | No plan or task files, but docs/design/*.md exists | Invoke work-planner to create work plan from Design Doc, then proceed to task decomposition |
-| Neither exists | No plan, no task files, no Design Doc | Report missing prerequisites to user and stop |
+| Tasks exist | Consumed Task Set is non-empty | User's execution instruction serves as batch approval → Enter autonomous execution immediately |
+| No tasks + plan supplied via `$ARGUMENTS` | `$ARGUMENTS` provided AND Consumed Task Set empty | Confirm with user → run task-decomposer |
+| No tasks + plan auto-resolved | Consumed Task Set empty AND plan came from auto-resolution AND Step 6 confirmed at least one backend signal with zero frontend signals | Confirm with user → run task-decomposer (the layer verification in Step 6 already excluded frontend and ambiguous plans, so this is safe) |
+
+To bootstrap from a Design Doc when no plan exists yet, run the planning recipe first to produce a work plan, then re-invoke this recipe — the readiness check above intentionally requires a resolved work plan rather than auto-creating one, to keep the layer decision explicit.
 
 ## Task Decomposition Phase (Conditional)
 
-When task files don't exist:
+When the Consumed Task Set is empty:
 
 ### 1. User Confirmation
 ```
-No task files found.
+No task files in the Consumed Task Set.
 Work plan: docs/plans/[plan-name].md
 
 Generate tasks from the work plan? (y/n):
@@ -57,17 +100,14 @@ Invoke task-decomposer using Agent tool:
 - `prompt`: "Read work plan at docs/plans/[plan-name].md and decompose into atomic tasks. Output: Individual task files in docs/plans/tasks/. Granularity: 1 task = 1 commit = independently executable"
 
 ### 3. Verify Generation
-```bash
-# Verify generated task files
-! ls -la docs/plans/tasks/*.md | head -10
-```
+Recompute the Consumed Task Set using the same restricted pattern from the Consumed Task Set section above. Confirm it is now non-empty. If it is still empty, escalate to the user — task-decomposer either failed silently or produced files that don't match the expected pattern.
 
-**Flow**: Task generation → Autonomous execution (in this order)
+**Flow**: Task generation → Consumed Task Set recompute → Autonomous execution (in this order)
 
 ## Pre-execution Checklist
 
-- [ ] Confirmed task files exist in docs/plans/tasks/
-- [ ] Identified task execution order (dependencies)
+- [ ] Confirmed Consumed Task Set is non-empty (computed in the Consumed Task Set section above)
+- [ ] Identified task execution order within the Consumed Task Set (dependencies)
 - [ ] **Environment check**: Can I execute per-task commit cycle?
   - If commit capability unavailable → Escalate before autonomous mode
   - Other environments (tests, quality tools) → Subagents will escalate
@@ -75,7 +115,7 @@ Invoke task-decomposer using Agent tool:
 ## Task Execution Cycle (4-Step Cycle)
 **MANDATORY EXECUTION CYCLE**: `task-executor → escalation check → quality-fixer → commit`
 
-For EACH task, YOU MUST:
+For EACH task in the Consumed Task Set, YOU MUST:
 1. **Register tasks using TaskCreate**: Register work steps. Always include first task "Map preloaded skills to applicable concrete rules" and final task "Verify the mapped rules before final JSON"
 2. **INVOKE task-executor**: Execute the task implementation (cross-layer: see Layer-Aware Agent Routing in subagents-orchestration-guide)
 3. **CHECK task-executor response**:
@@ -126,7 +166,18 @@ After all task cycles finish, run verification agents **in parallel** before the
    - Then quality-fixer, then re-run only the failed verifiers.
    - If still failing after 2 cycles → Escalate to user with remaining findings
 
-4. **All passed** → Proceed to completion report
+4. **All passed** → Proceed to Final Cleanup
+
+## Final Cleanup
+
+Before the completion report, delete the implementation task files this recipe consumed. Their work is committed; `docs/plans/` is ephemeral working state and is not retained between recipe runs:
+
+- Delete every file in the Consumed Task Set
+- Delete every file matching `docs/plans/tasks/{plan-name}-phase*-completion.md` (the per-phase completion files generated by task-decomposer for this `{plan-name}`)
+- Delete the corresponding `docs/plans/tasks/_overview-{plan-name}.md` if present
+- Preserve the work plan itself (`docs/plans/{plan-name}.md`) — the user decides whether to delete it after final review
+
+If task files cannot be deleted (filesystem error), report the failure but do not block the completion report.
 
 ## Output Example
 Implementation phase completed.
@@ -134,6 +185,7 @@ Implementation phase completed.
 - Implemented tasks: [number] tasks
 - Quality checks: All passed
 - Commits: [number] commits created
+- Cleanup: Task files removed from docs/plans/tasks/
 
 **Responsibility Boundary**:
 - IN SCOPE: Task decomposition to implementation completion

package/.claude/commands-en/front-build.md

@@ -18,33 +18,57 @@ Work plan: $ARGUMENTS
 
 ## Pre-execution Prerequisites
 
-### Task File Existence Check
-```bash
-# Check work plans
-! ls -la docs/plans/*.md | grep -v template | tail -5
+### Implementation Readiness Check
 
-# Check task files
-! ls docs/plans/tasks/*.md 2>/dev/null || echo "⚠️ No task files found"
-```
+Before any task processing, locate the work plan to gate against.
+
+**When `$ARGUMENTS` is provided**, it is the work plan path supplied by the user. Use it directly without auto-resolution. Extract `{plan-name}` from the filename by stripping the `.md` extension (and any trailing `-plan` suffix when present).
+
+**When `$ARGUMENTS` is empty**, auto-resolve from task files:
+1. List task files in `docs/plans/tasks/` matching this recipe's only consumable pattern (per subagents-orchestration-guide "Layer-Aware Agent Routing", `task-executor-frontend` owns this filename suffix and no other):
+   - `{plan-name}-frontend-task-*.md`
+   - The bare `{plan-name}-task-*.md` is **not** consumable — that filename is reserved for backend by the routing table and is owned by the backend build recipe. `{plan-name}-backend-task-*.md` is also not consumable for the same reason.
+2. From the matched files, also exclude every file matching any of these patterns — they originate from other workflow phases and are not implementation tasks for this run's plan: `*-task-prep-*.md` (readiness preflight tasks), `_overview-*.md` (decomposition overview file), `*-phase*-completion.md` (per-phase completion files), `review-fixes-*.md` (post-implementation review fixes), `integration-tests-*-task-*.md` (integration-test add-on scaffolding)
+3. For each remaining file, extract `{plan-name}` by stripping the trailing `-frontend-task-{NN}.md` suffix
+4. When at least one task file matches, the work plan is `docs/plans/{plan-name}.md` for the prefix that has the most recent task-file mtime; ties broken by the lexicographically last `{plan-name}`
+5. When no `*-frontend-task-*.md` is found AND a non-template work plan exists in `docs/plans/`, do not assume the most-recent plan applies — frontend tasks must be explicitly named. Stop and report: "No `*-frontend-task-*.md` found in `docs/plans/tasks/`. If you intended to run this recipe on a frontend plan, either re-run task-decomposer so it emits frontend-named task files, or pass the work plan path as `$ARGUMENTS`. If the plan is backend, use the backend build recipe instead."
+
+Read the work plan header and find the line `Implementation Readiness: <status>`. Apply this rule:
+
+| Status | Action |
+|--------|--------|
+| `ready` | Proceed to Consumed Task Set computation |
+| `escalated` | Read the work plan's Readiness Report section, surface remaining gaps to the user via AskUserQuestion: "Implementation Readiness is `escalated` with the following remaining gaps: [list]. Continue execution? (y/n)". On `y` proceed; on `n` stop |
+| `pending` | Present via AskUserQuestion: "Implementation Readiness is `pending`. Run the readiness preflight first to verify the work plan is implementable, then resume. Continue without preflight? (y/n)". On `y` proceed; on `n` stop |
+| absent (line missing) | Treat as `pending` — older work plans created before the readiness marker existed should be preflighted explicitly |
+
+### Consumed Task Set
+
+Compute the **Consumed Task Set** for this run — the exact files this recipe owns, executes, and later deletes. Per the routing table, the only consumable pattern is:
+
+1. List task files in `docs/plans/tasks/` matching `{plan-name}-frontend-task-*.md` for the `{plan-name}` resolved by the readiness check. `{plan-name}-task-*.md` and `{plan-name}-backend-task-*.md` are excluded — they route to `task-executor` and are owned by the backend build recipe
+2. Exclude every file matching: `*-task-prep-*.md`, `_overview-*.md`, `*-phase*-completion.md`, `review-fixes-*.md`, `integration-tests-*-task-*.md` (these originate from other workflow phases)
+
+Every subsequent reference to "task files" in this recipe — Task Generation Decision Flow, Task Execution Cycle iteration, and Final Cleanup — uses this set, not the unrestricted `docs/plans/tasks/*.md` glob.
 
 ### Task Generation Decision Flow
 
-Analyze task file existence state and determine the action required:
+Analyze the Consumed Task Set and determine the action required. Note: when `$ARGUMENTS` is empty AND no `*-frontend-task-*.md` exist, the readiness check above already stops execution — so the rows below that involve "no tasks" only fire when the user explicitly supplied `$ARGUMENTS`.
 
 | State | Criteria | Next Action |
 |-------|----------|-------------|
-| Tasks exist | .md files in tasks/ directory | User's execution instruction serves as batch approval → Enter autonomous execution immediately |
-| No tasks + plan exists | Plan exists but no task files | Confirm with user → run task-decomposer |
-| Neither exists + Design Doc exists | No plan or task files, but docs/design/*.md exists | Invoke work-planner to create work plan from Design Doc, then proceed to task decomposition |
-| Neither exists | No plan, no task files, no Design Doc | Report missing prerequisites to user and stop |
+| Tasks exist | Consumed Task Set is non-empty | User's execution instruction serves as batch approval → Enter autonomous execution immediately |
+| No tasks + plan supplied via `$ARGUMENTS` | `$ARGUMENTS` provided AND Consumed Task Set empty | Confirm with user → run task-decomposer (which will emit `*-frontend-task-*.md` per the frontend naming rule) |
+| Neither exists + Design Doc exists + `$ARGUMENTS` provided | `$ARGUMENTS` provided, no plan, no Consumed Task Set, but docs/design/*.md exists | Invoke work-planner to create work plan from Design Doc, then proceed to task decomposition |
+| Neither exists | No `$ARGUMENTS`, no plan, no Consumed Task Set, no Design Doc | Report missing prerequisites to user and stop |
 
 ## Task Decomposition Phase (Conditional)
 
-When task files don't exist:
+When the Consumed Task Set is empty:
 
 ### 1. User Confirmation
 ```
-No task files found.
+No task files in the Consumed Task Set.
 Work plan: docs/plans/[plan-name].md
 
 Generate tasks from the work plan? (y/n):
@@ -57,17 +81,14 @@ Invoke task-decomposer using Agent tool:
 - `prompt`: "Read work plan at docs/plans/[plan-name].md and decompose into atomic tasks. Output: Individual task files in docs/plans/tasks/. Granularity: 1 task = 1 commit = independently executable"
 
 ### 3. Verify Generation
-```bash
-# Verify generated task files
-! ls -la docs/plans/tasks/*.md | head -10
-```
+Recompute the Consumed Task Set using the same restricted pattern from the Consumed Task Set section above. Confirm it is now non-empty. If it is still empty, escalate to the user — task-decomposer either failed silently or produced files that don't match the expected pattern.
 
-**Flow**: Task generation → Autonomous execution (in this order)
+**Flow**: Task generation → Consumed Task Set recompute → Autonomous execution (in this order)
 
 ## Pre-execution Checklist
 
-- [ ] Confirmed task files exist in docs/plans/tasks/
-- [ ] Identified task execution order (dependencies)
+- [ ] Confirmed Consumed Task Set is non-empty (computed in the Consumed Task Set section above)
+- [ ] Identified task execution order within the Consumed Task Set (dependencies)
 - [ ] **Environment check**: Can I execute per-task commit cycle?
   - If commit capability unavailable → Escalate before autonomous mode
   - Other environments (tests, quality tools) → Subagents will escalate
@@ -75,7 +96,7 @@ Invoke task-decomposer using Agent tool:
 ## Task Execution Cycle (4-Step Cycle)
 **MANDATORY EXECUTION CYCLE**: `task-executor-frontend → escalation check → quality-fixer-frontend → commit`
 
-For EACH task, YOU MUST:
+For EACH task in the Consumed Task Set, YOU MUST:
 1. **Register tasks using TaskCreate**: Register work steps. Always include first task "Map preloaded skills to applicable concrete rules" and final task "Verify the mapped rules before final JSON"
 2. **Agent tool** (subagent_type: "task-executor-frontend") → Pass task file path in prompt, receive structured response
 3. **CHECK task-executor-frontend response**:
@@ -104,8 +125,6 @@ Use loaded skills to execute that scope.
 Escalate when the required fix or investigation falls outside that scope.
 ```
 
-! ls -la docs/plans/*.md | head -10
-
 VERIFY approval status before proceeding. Once confirmed, INITIATE autonomous execution mode. STOP IMMEDIATELY upon detecting ANY requirement changes.
 
 ## Post-Implementation Verification (After All Tasks Complete)
@@ -128,7 +147,18 @@ After all task cycles finish, run verification agents **in parallel** before the
    - Then quality-fixer-frontend, then re-run only the failed verifiers.
    - If still failing after 2 cycles → Escalate to user with remaining findings
 
-4. **All passed** → Proceed to completion report
+4. **All passed** → Proceed to Final Cleanup
+
+## Final Cleanup
+
+Before the completion report, delete the implementation task files this recipe consumed. Their work is committed; `docs/plans/` is ephemeral working state and is not retained between recipe runs:
+
+- Delete every file in the Consumed Task Set
+- Delete every file matching `docs/plans/tasks/{plan-name}-phase*-completion.md` (the per-phase completion files generated by task-decomposer for this `{plan-name}`)
+- Delete the corresponding `docs/plans/tasks/_overview-{plan-name}.md` if present
+- Preserve the work plan itself (`docs/plans/{plan-name}.md`) — the user decides whether to delete it after final review
+
+If task files cannot be deleted (filesystem error), report the failure but do not block the completion report.
 
 ## Output Example
 Frontend implementation phase completed.
@@ -136,3 +166,4 @@ Frontend implementation phase completed.
 - Implemented tasks: [number] tasks
 - Quality checks: All passed
 - Commits: [number] commits created
+- Cleanup: Task files removed from docs/plans/tasks/

package/.claude/commands-en/front-plan.md

@@ -43,17 +43,18 @@ Invoke acceptance-test-generator using Agent tool:
 - If UI Spec exists: `prompt: "Generate test skeletons from Design Doc at [path]. UI Spec at [ui-spec path]."`
 - If no UI Spec: `prompt: "Generate test skeletons from Design Doc at [path]."`
 
-Pass integration test file path, E2E test file path (or null), and e2eAbsenceReason to work-planner according to subagents-orchestration-guide "acceptance-test-generator → work-planner" section.
+Pass per-lane test file paths and absence reasons to work-planner according to subagents-orchestration-guide "acceptance-test-generator → work-planner" section.
 
 ### Step 3: Work Plan Creation
 Invoke work-planner using Agent tool:
 - `subagent_type`: "work-planner"
 - `description`: "Work plan creation"
-- If test skeletons were generated in Step 2:
-  - When `generatedFiles.e2e` is not null:
-    `prompt`: "Create work plan from Design Doc at [path]. Integration test file: [integration test path]. E2E test file: [E2E test path]. Integration tests are created simultaneously with each phase implementation, E2E tests are executed only in final phase."
-  - When `generatedFiles.e2e` is null:
-    `prompt`: "Create work plan from Design Doc at [path]. Integration test file: [integration test path]. No E2E test skeletons were generated (reason: [e2eAbsenceReason]). Integration tests are created simultaneously with each phase implementation."
+- If test skeletons were generated in Step 2, build the prompt by listing every lane's status:
+  - Always include: "Integration test file: [path or 'not generated']"
+  - For each E2E lane (`fixtureE2e`, `serviceE2e`):
+    - When `generatedFiles.<lane>` is not null: "[lane] test file: [path]"
+    - When `generatedFiles.<lane>` is null: "No [lane] skeleton generated (reason: [e2eAbsenceReason.<lane>])"
+  - Append placement guidance: "Integration tests are created simultaneously with each phase implementation. fixture-e2e tests are created alongside the UI feature phase. service-integration-e2e tests are executed only in the final phase."
 - If test skeletons were not generated:
   `prompt`: "Create work plan from Design Doc at [path]."
 

package/.claude/commands-en/front-review.md

@@ -14,9 +14,10 @@ description: Design Doc compliance and security validation with optional auto-fi
 
 - Compliance validation → performed by code-reviewer
 - Security validation → performed by security-reviewer
-- Fix implementation → performed by task-executor-frontend
-- Quality checks → performed by quality-fixer-frontend
-- Re-validation → performed by code-reviewer / security-reviewer
+- **Code-side fix path**: Fix implementation → task-executor-frontend; Quality checks → quality-fixer-frontend; Re-validation → code-reviewer / security-reviewer
+- **Design-side update path**: DD revision → technical-designer-frontend (update mode); DD review → document-reviewer; cross-DD consistency → design-sync (when multiple DDs exist); Re-validation → code-reviewer
+
+Orchestrator invokes sub-agents and passes structured JSON between them. The design-side path applies when the discrepancy reflects code that was correct but the Design Doc became stale, rather than code that violated the Design Doc.
 
 Design Doc (uses most recent if omitted): $ARGUMENTS
 
@@ -59,7 +60,24 @@ Invoke security-reviewer using Agent tool:
 - `approved` or `approved_with_notes` → Pass
 - `needs_revision` → Fail
 
-**Report both results independently using subagent output fields only** (do not add fields that are not in the subagent response):
+**Report both results independently using subagent output fields only** (do not add fields that are not in the subagent response).
+
+**Early exit (no findings to route)**: When code-reviewer's `verdict` is `pass` AND every entry in `acceptanceCriteria[]` has `status: "fulfilled"` AND `identifierMismatches[]` is empty AND `qualityFindings[]` is empty AND security-reviewer's `findings[]` is empty, skip Steps 5-10 and proceed directly to Step 11 — there is nothing to route. Present the clean result to the user.
+
+Otherwise, before presenting to the user, the orchestrator computes a recommended route per finding using the rule below (this rule is internal — do not include it in the user-facing prompt). The rule keys off code-reviewer's existing structured fields only — interpretation of "DD intent" is intentionally avoided to prevent unstable inference:
+
+| Finding source | Pattern detectable from existing fields | Recommended route |
+|---------------|-----------------------------------------|-------------------|
+| `acceptanceCriteria[]` with `status: "partially_fulfilled"` or `"unfulfilled"` | The cited `gap` indicates the code does not satisfy the AC — needs additional implementation | `c` (Code-side fix) |
+| `acceptanceCriteria[]` with `status: "partially_fulfilled"` or `"unfulfilled"` | The cited `gap` indicates the AC text itself diverged from the implemented (and team-accepted) behavior — i.e., the DD's AC wording captured the wrong intent rather than the code missing requirements (verify by reading the AC and comparing against the cited `location`) | `d` (Design-side update — AC text outdated) |
+| `identifierMismatches[]` | `codeValue` is a plausible rename of `designDocValue` (camelCase ↔ kebab-case ↔ snake_case, abbreviation expansion/contraction, semantic renaming where both names refer to the same concept) — verify by inspecting the cited `location` to confirm the code uses the new name consistently | `d` (Design-side update — DD likely outdated) |
+| `identifierMismatches[]` | All other identifier mismatches (e.g., wrong type, wrong cardinality, missing entirely) | `c` (Code-side fix) |
+| `qualityFindings[]` | All categories (`dd_violation`, `maintainability`, `reliability`, `coverage_gap`) | `c` (Code-side fix) |
+| security-reviewer `findings[]` | All categories (`confirmed_risk`, `defense_gap`, `hardening`, `policy`) | `c` (Code-side fix) |
+
+The user can override any recommendation per finding. AC items with `status: "fulfilled"` are not routed (no action needed).
+
+Then present to the user (label each finding with its recommended route, grouped by route):
 
 ```
 Code Compliance: [complianceRate from code-reviewer]
@@ -67,30 +85,57 @@ Code Compliance: [complianceRate from code-reviewer]
   Identifier Match Rate: [identifierMatchRate from code-reviewer]
   Acceptance Criteria:
   - [fulfilled] [item] (confidence: [high/medium/low])
-  - [partially_fulfilled] [item]: [gap] — [suggestion]
-  - [unfulfilled] [item]: [gap] — [suggestion]
+  - [partially_fulfilled] [item]: [gap] — [suggestion] [recommended: c | d]
+  - [unfulfilled] [item]: [gap] — [suggestion] [recommended: c | d]
   Identifier Mismatches:
-  - [identifier]: DD=[designDocValue] Code=[codeValue] at [location]
+  - [identifier]: DD=[designDocValue] Code=[codeValue] at [location] [recommended: c | d]
   Quality Findings:
-  - [category] [location]: [description] — [rationale]
+  - [category] [location]: [description] — [rationale] [recommended: c]
 
 Security Review: [status from security-reviewer]
   Findings by category:
-  - [confirmed_risk] [location]: [description] — [rationale]
-  - [defense_gap] [location]: [description] — [rationale]
-  - [hardening] [location]: [description] — [rationale]
-  - [policy] [location]: [description] — [rationale]
+  - [confirmed_risk] [location]: [description] — [rationale] [recommended: c]
+  - [defense_gap] [location]: [description] — [rationale] [recommended: c]
+  - [hardening] [location]: [description] — [rationale] [recommended: c]
+  - [policy] [location]: [description] — [rationale] [recommended: c]
   Notes: [notes from security-reviewer, if present]
 
-Execute fixes? (y/n):
+Resolve discrepancies — confirm or override the recommended route per finding:
+  c) Code-side fix       — code violates Design Doc; modify code to match
+  d) Design-side update  — code is correct; Design Doc is stale, revise it
+  s) Skip                — accept current state without changes
 ```
 
-If both pass and user selects `n`: Skip Steps 5-10, proceed to Step 11.
+Use AskUserQuestion. The default offer is **"accept all recommended routes"** — a single confirmation for the typical case where the orchestrator's recommendations are correct. When the user wants to override, collect per-finding c/d/s decisions instead. If the user selects `s` for everything: skip Steps 5-10, proceed to Step 11.
 
 ### Step 5: Load Task Template
 
 Read documentation-criteria skill to obtain the task file template (references/task-template.md) for Step 6.
 
+### Step 5d: Design-Side Update
+
+Run this step only when the user routed at least one finding to `d`. When all routes are `c` or `s`, skip directly to Step 6.
+
+1. Invoke technical-designer-frontend in update mode using Agent tool:
+   - `subagent_type`: "technical-designer-frontend"
+   - `description`: "Design Doc update from review findings"
+   - `prompt`: "Update Design Doc at [path] in update mode. The implementation has diverged in the following ways that the team has decided to ratify in the design rather than in the code: [list of `d`-routed findings with codeLocation and designDocValue from $STEP_2_OUTPUT]. Reflect the current code behavior in the relevant sections and add a history entry."
+
+2. Invoke document-reviewer to verify the updated Design Doc:
+   - `subagent_type`: "document-reviewer"
+   - `description`: "Document review of updated Design Doc"
+   - `prompt`: "Review updated Design Doc at [path] for consistency and completeness."
+
+3. When multiple Design Docs exist (`ls docs/design/*.md | grep -v template | wc -l > 1`), invoke design-sync:
+   - `subagent_type`: "design-sync"
+   - `description`: "Cross-DD consistency check"
+   - `prompt`: "source_design: [updated DD path]. Detect conflicts across all Design Docs after the update."
+   - When `sync_status: conflicts_found`: present conflicts to the user; resolution requires re-invoking technical-designer-frontend for affected DDs.
+
+4. After Step 5d completes:
+   - If the user selected zero `c` routes (whether all `d`, all `s`, or a `d` + `s` mix with no `c`) → skip Steps 6-8, proceed to Step 9 for re-validation
+   - If the user selected both `d` and `c` → re-evaluate the `c`-routed findings against the updated DD and drop any that are now satisfied by the DD revision; then proceed to Step 6 with the remaining `c` findings
+
 ### Step 6: Create Task File
 
 Create task file at `docs/plans/tasks/review-fixes-YYYYMMDD.md`
@@ -113,7 +158,7 @@ Invoke quality-fixer-frontend using Agent tool:
 Invoke code-reviewer using Agent tool:
 - `subagent_type`: "code-reviewer"
 - `description`: "Re-validate compliance"
-- `prompt`: "Re-validate Design Doc compliance after fixes. Design Doc: [path]. Implementation files: [file list]. Prior compliance issues: $STEP_2_OUTPUT. Verify each prior issue is resolved."
+- `prompt`: "Re-validate Design Doc compliance after fixes. Design Doc: [path]. Implementation files: [file list]. Prior compliance issues: $STEP_2_OUTPUT. Verify each prior issue is resolved (whether resolved code-side or design-side)."
 
 ### Step 10: Re-validate security-reviewer
 
@@ -122,7 +167,16 @@ Invoke security-reviewer using Agent tool (only if security fixes were applied):
 - `description`: "Re-validate security"
 - `prompt`: "Re-validate security after fixes. Prior findings: $STEP_3_OUTPUT. Design Doc: [path]. Implementation files: [file list]."
 
-### Step 11: Final Report
+### Step 11: Final Cleanup and Report
+
+Delete the review-fix task file this recipe created (if any). Its work is committed; `docs/plans/` is ephemeral working state and is not retained between recipe runs:
+
+- Delete `docs/plans/tasks/review-fixes-YYYYMMDD.md` if it exists
+
+If the file cannot be deleted (filesystem error), report the failure but do not block the final report.
+
+Then present the final report:
+
 ```
 Code Compliance:
   Initial: [X]%
@@ -135,9 +189,11 @@ Security Review:
 
 Remaining issues:
 - [items requiring manual intervention]
+
+Cleanup: review-fixes task file removed
 ```
 
-## Auto-fixable Items
+## Auto-fixable Items (code-side path)
 - Simple unimplemented acceptance criteria
 - Error handling additions
 - Contract definition fixes
@@ -147,10 +203,16 @@ Remaining issues:
 ## Non-fixable Items
 - Fundamental business logic changes
 - Architecture-level modifications
-- Design Doc deficiencies
 - Committed secrets (blocked → human intervention)
 
-**Scope**: Design Doc compliance validation, security review, and auto-fixes.
+## Design-Side Update Triggers
+Discrepancies suitable for the design-side path (code is correct, DD became stale):
+- Identifier renames where the new identifier reflects the team's current naming
+- Behavioral changes that match the original requirement intent better than what the DD captured
+- Component splits or merges where the new structure is sound and the DD documented the prior structure
+- New ACs that the implementation already satisfies but the DD never enumerated
+
+**Scope**: Design Doc compliance validation, security review, code-side auto-fixes, and design-side update routing.
 
 ## Scope Boundary for Subagents
 

package/.claude/commands-en/implement.md

@@ -58,6 +58,19 @@ After scale determination, **register all steps of the applicable subagents-orch
 
 **Flow Adherence**: Follow "Autonomous Execution Task Management" in subagents-orchestration-guide skill, managing 4 steps with TaskCreate/TaskUpdate
 
+## Implementation Readiness Check (between work-planner approval and task-decomposer)
+
+After work-planner completes and the user grants batch approval, before invoking task-decomposer, read the work plan header and find the line `Implementation Readiness: <status>`. Apply this rule:
+
+| Status | Action |
+|--------|--------|
+| `ready` | Proceed to task-decomposer |
+| `escalated` | Read the work plan's Readiness Report section, surface remaining gaps to the user via AskUserQuestion: "Implementation Readiness is `escalated` with the following remaining gaps: [list]. Continue execution? (y/n)". On `y` proceed; on `n` stop |
+| `pending` | Present via AskUserQuestion: "Implementation Readiness is `pending`. Run the readiness preflight first to verify the work plan is implementable, then resume. Continue without preflight? (y/n)". On `y` proceed; on `n` stop |
+| absent (line missing) | Treat as `pending` — older work plans created before the readiness marker existed should be preflighted explicitly |
+
+This check applies to all scales (Small / Medium / Large) because this recipe is the scale-agnostic orchestrator.
+
 ## Scope Boundary for Subagents
 
 Append the following block to every subagent prompt invoked from this recipe:
@@ -101,11 +114,29 @@ After all task cycles finish, invoke security-reviewer before the completion rep
    - `blocked` → Escalate to user
 
 ### Test Information Communication
-After acceptance-test-generator execution, when invoking work-planner (subagent_type: "work-planner"), communicate:
-- Generated integration test file path (from `generatedFiles.integration`)
-- Generated E2E test file path or null (from `generatedFiles.e2e`)
-- E2E absence reason (from `e2eAbsenceReason`, when E2E is null)
-- Explicit note that integration tests are created simultaneously with implementation, E2E tests are executed after all implementations (when E2E path is provided)
+After acceptance-test-generator execution, when invoking work-planner (subagent_type: "work-planner"), communicate per-lane:
+- Integration test file path (from `generatedFiles.integration`) or null
+- fixture-e2e test file path (from `generatedFiles.fixtureE2e`) or null
+- service-integration-e2e test file path (from `generatedFiles.serviceE2e`) or null
+- Per-lane absence reason (from `e2eAbsenceReason.fixtureE2e` / `e2eAbsenceReason.serviceE2e`) when that lane is null
+- Explicit timing notes: integration tests are created alongside each phase implementation; fixture-e2e tests are created alongside the UI feature phase; service-integration-e2e tests are executed only in the final phase
+
+### Final Cleanup
+
+Before the completion report, delete the implementation task files this recipe consumed. Their work is committed; `docs/plans/` is ephemeral working state and is not retained between recipe runs.
+
+This recipe is scale-agnostic and may execute single-layer or multi-layer plans, so cleanup must cover all task naming patterns produced by task-decomposer's "Layer-aware naming" output:
+
+- Delete every file matching ANY of these patterns for the `{plan-name}` derived from the work plan path used in this run:
+  - `docs/plans/tasks/{plan-name}-task-*.md` (single-layer tasks)
+  - `docs/plans/tasks/{plan-name}-backend-task-*.md` (backend portion of multi-layer plan)
+  - `docs/plans/tasks/{plan-name}-frontend-task-*.md` (frontend portion of multi-layer plan)
+- From those matches, exclude `*-task-prep-*.md`, `_overview-*.md`, `*-phase*-completion.md`, `review-fixes-*.md`, `integration-tests-*-task-*.md` (these originate from other workflow phases)
+- Delete every file matching `docs/plans/tasks/{plan-name}-phase*-completion.md` (the per-phase completion files generated by task-decomposer)
+- Delete the corresponding `docs/plans/tasks/_overview-{plan-name}.md` if present
+- Preserve the work plan itself (`docs/plans/{plan-name}.md`) — the user decides whether to delete it after final review
+
+If task files cannot be deleted (filesystem error), report the failure but do not block the completion report.
 
 ## Execution Method
 

package/.claude/commands-en/plan.md

@@ -36,20 +36,21 @@ Follow subagents-orchestration-guide skill strictly and create work plan with th
    - Check for existence of design documents, notify user if none exist
    - Present options if multiple exist (can be specified with $ARGUMENTS)
 
-2. **E2E Test Skeleton Generation Confirmation**
-   - Confirm with user whether to generate E2E test skeleton first
-   - If user wants generation: Generate test skeleton with acceptance-test-generator
+2. **Test Skeleton Generation Confirmation**
+   - Confirm with user whether to generate test skeletons (integration + E2E lanes) first
+   - If user wants generation: invoke acceptance-test-generator
    - Pass generation results to next process according to subagents-orchestration-guide skill coordination specification
 
 3. **Work Plan Creation**
    Invoke work-planner using Agent tool:
    - `subagent_type`: "work-planner"
    - `description`: "Work plan creation"
-   - If test skeletons were generated in Step 2:
-     - When `generatedFiles.e2e` is not null:
-       `prompt`: "Create work plan from Design Doc at [path]. Integration test file: [integration test path]. E2E test file: [E2E test path]. Integration tests are created simultaneously with each phase implementation, E2E tests are executed only in final phase."
-     - When `generatedFiles.e2e` is null:
-       `prompt`: "Create work plan from Design Doc at [path]. Integration test file: [integration test path]. No E2E test skeletons were generated (reason: [e2eAbsenceReason]). Integration tests are created simultaneously with each phase implementation."
+   - If test skeletons were generated in Step 2, build the prompt by listing every lane's status:
+     - Always include: "Integration test file: [path or 'not generated']"
+     - For each E2E lane (`fixtureE2e`, `serviceE2e`):
+       - When `generatedFiles.<lane>` is not null: "[lane] test file: [path]"
+       - When `generatedFiles.<lane>` is null: "No [lane] skeleton generated (reason: [e2eAbsenceReason.<lane>])"
+     - Append placement guidance: "Integration tests are created simultaneously with each phase implementation. fixture-e2e tests are created alongside the UI feature phase. service-integration-e2e tests are executed only in the final phase."
    - If test skeletons were not generated:
      `prompt`: "Create work plan from Design Doc at [path]."