create-ai-project 1.23.0 → 1.23.2

package/.claude/agents-ja/work-planner.md

@@ -38,6 +38,9 @@ Design Doc、UI Spec、PRD、ADR（提供されている場合）を読み込み
 **全アプローチ共通**:
 - **検証戦略の要約を作業計画書ヘッダーに記載**（後続タスクへの参照用）
 - **採用した品質保証メカニズムを作業計画書ヘッダーに記載**（後続タスクへの参照用） — 各メカニズムについてツール名、検証内容、設定パス、カバー範囲（Design Docのファイルパスまたはディレクトリプレフィックス、スコープが限定されない場合は "project-wide"）を記載
+- **証明戦略を作業計画書ヘッダーに記載**（plan template参照） — 証明義務の出所（スケルトンが提供される場合はテストスケルトンの注釈、なければ各ACの主要な故障モード）を明示し、主張を実装する各タスクが下流レビュー用に Proof Obligations を記録する旨を記載する
+- **レビュースコープを作業計画書ヘッダーに記録** — 実装前の新規計画では Design Doc とタスク対象ファイルから導出した変更予定ファイルの範囲、既存作業に対する改訂計画ではベースブランチと diff範囲 — を記録し、作業計画書レビューと下流検証が同一スコープを共有できるようにする
+- **故障モードチェックリストを作業計画書に含める**（plan template参照） — ドメイン非依存の8つの故障カテゴリ（same-value, no-op, empty input, invalid option, missing config, unavailable boundary, shared-state dependency, rollback-only visibility）をすべて列挙し、該当するものに印を付け、該当する各カテゴリをカバーするタスクにマッピングする。エントリにはプロジェクト固有の名称を含めない
 - 検証戦略の検証タイミングに対応するフェーズに検証タスクを配置
 - テストスケルトンが提供されている場合、統合テスト実装を対応するフェーズに配置し、E2Eテスト実行を最終フェーズに配置
 - テストスケルトンが提供されていない場合、Design Docの受入条件に基づくテスト実装タスクを含める
@@ -361,6 +364,9 @@ Design Docの技術的依存関係と実装アプローチに基づいてフェ
   - [ ] 全行が少なくとも1つのカバータスクにマッピングされている
 - [ ] 計画書ヘッダーに `Implementation Readiness: pending` を含める（medium / large のみ）
 - [ ] Design Docから検証戦略を抽出し計画書ヘッダーに記載
+- [ ] 計画書ヘッダーに証明戦略を記載（証明義務の出所 + タスクごとの伝播ルール）
+- [ ] 計画書ヘッダーにレビュースコープを記録（ベースブランチ / diff範囲 / 変更ファイル範囲）
+- [ ] 故障モードチェックリストを含め、該当カテゴリをカバーするタスクにマッピングし、プロジェクト固有の名称を含めない
 - [ ] Design Docから採用済み品質保証メカニズムを抽出し計画書ヘッダーに記載
 - [ ] フェーズ構成が実装アプローチと整合（垂直 → 価値単位フェーズ、水平 → レイヤーフェーズ）
 - [ ] 早期検証ポイントをPhase 1に配置（検証戦略で指定されている場合）

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

@@ -59,9 +59,22 @@ Analyze the Consumed Task Set and determine the action required. Note: when `$AR
 |-------|----------|-------------|
 | 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 + 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 run **Work Plan Review** (see below) before task decomposition |
 | Neither exists | No `$ARGUMENTS`, no plan, no Consumed Task Set, no Design Doc | Report missing prerequisites to user and stop |
 
+## Work Plan Review (when this recipe created the plan)
+
+When the decision flow above created the work plan from a Design Doc, review it before decomposition:
+
+1. Invoke document-reviewer using Agent tool:
+   - `subagent_type`: "document-reviewer"
+   - `description`: "Work plan review"
+   - `prompt`: "doc_type: WorkPlan target: docs/plans/[plan-name].md design_doc: [the Design Doc path]. Review semantic traceability to the Design Doc, early verification placement, real-boundary verification coverage, Failure Mode Checklist, and Review Scope."
+2. Branch on the reviewer's `verdict.decision`:
+   - `needs_revision` → re-invoke work-planner (update) with the findings and re-review until `approved`/`approved_with_conditions`
+   - `rejected` → stop before task decomposition and escalate to the user
+3. Present the reviewed plan for batch approval before task decomposition.
+
 ## Task Decomposition Phase (Conditional)
 
 When the Consumed Task Set is empty:

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

@@ -23,6 +23,7 @@ description: Create frontend work plan from design document and obtain plan appr
 - Design document selection
 - Test skeleton generation with acceptance-test-generator
 - Work plan creation with work-planner
+- Work plan review with document-reviewer
 - Plan approval obtainment
 
 **Responsibility Boundary**: This command completes with work plan approval.
@@ -59,8 +60,20 @@ Invoke work-planner using Agent tool:
   `prompt`: "Create work plan from Design Doc at [path]."
 
 - Follow subagents-orchestration-guide Prompt Construction Rule for additional prompt parameters
-- Present work plan to user for review. If user requests changes, re-invoke work-planner with revised parameters
-- Highlight steps with unclear scope or external dependencies and ask user to confirm
+
+### Step 4: Work Plan Review
+Invoke document-reviewer to review the work plan:
+- `subagent_type`: "document-reviewer"
+- `description`: "Work plan review"
+- `prompt`: "doc_type: WorkPlan target: docs/plans/[plan-name].md design_doc: [the Design Doc path selected in Step 1]. Review semantic traceability to the Design Doc, early verification placement, real-boundary verification coverage, Failure Mode Checklist, and Review Scope."
+- The work plan is a derivation of the Design Doc, so plan-fidelity findings are resolved without user input. Branch on the reviewer's `verdict.decision`:
+  - `needs_revision`: re-invoke work-planner in update mode with the findings and re-review, repeating until `approved` or `approved_with_conditions`
+  - `approved` / `approved_with_conditions`: proceed to Step 5
+  - `rejected`: escalate to the user
+
+### Step 5: Present for Approval
+- Present the reviewed work plan to the user for batch approval. If the user requests changes, re-invoke work-planner with revised parameters and re-run Step 4.
+- Highlight steps with unclear scope or external dependencies and ask the user to confirm
 
 **Scope**: Up to work plan creation and obtaining approval for plan content.
 

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

@@ -23,6 +23,7 @@ description: Create work plan from design document and obtain plan approval
 - Design document selection
 - E2E test skeleton generation (optional, with user confirmation)
 - Work plan creation with work-planner
+- Work plan review with document-reviewer
 - Plan approval obtainment
 
 **Responsibility Boundary**: This command completes with work plan approval.
@@ -55,7 +56,20 @@ Follow subagents-orchestration-guide skill strictly and create work plan with th
      `prompt`: "Create work plan from Design Doc at [path]."
 
    - Follow subagents-orchestration-guide Prompt Construction Rule for additional prompt parameters
-   - Interact with user to complete plan and obtain approval for plan content
+
+4. **Work Plan Review**
+   Invoke document-reviewer to review the work plan:
+   - `subagent_type`: "document-reviewer"
+   - `description`: "Work plan review"
+   - `prompt`: "doc_type: WorkPlan target: docs/plans/[plan-name].md design_doc: [the Design Doc path selected in Step 1]. Review semantic traceability to the Design Doc, early verification placement, real-boundary verification coverage, Failure Mode Checklist, and Review Scope."
+   - The work plan is a derivation of the Design Doc, so plan-fidelity findings are resolved without user input. Branch on the reviewer's `verdict.decision`:
+     - `needs_revision`: re-invoke work-planner in update mode with the findings and re-review, repeating until `approved` or `approved_with_conditions`
+     - `approved` / `approved_with_conditions`: proceed to Step 5
+     - `rejected`: escalate to the user
+
+5. **Present for Approval**
+   - Present the reviewed work plan to the user for batch approval. If the user requests changes, re-invoke work-planner with revised parameters and re-run Step 4.
+   - Highlight steps with unclear scope or external dependencies and ask the user to confirm
 
 Create a work plan from the selected design document, clarifying specific implementation steps and risks.
 

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

@@ -59,9 +59,22 @@ Consumed Task Set を確認し、適切な対応を決定する。注: `$ARGUMEN
 |------|------|--------------|
 | タスク存在 | Consumed Task Set が非空 | ユーザーの実行指示をバッチ承認として自律実行へ移行 |
 | タスクなし + `$ARGUMENTS`で計画書指定 | `$ARGUMENTS`が提供され Consumed Task Set が空 | ユーザーに確認 → task-decomposer実行（frontend命名ルールにより `*-frontend-task-*.md` を出力する） |
-| どちらもなし＋Design Docあり + `$ARGUMENTS`提供 | `$ARGUMENTS`が提供され、計画書なし、Consumed Task Setなし、ただし docs/design/*.md が存在 | work-plannerでDesign Docから作業計画書を作成し、タスク分解へ進む |
+| どちらもなし＋Design Docあり + `$ARGUMENTS`提供 | `$ARGUMENTS`が提供され、計画書なし、Consumed Task Setなし、ただし docs/design/*.md が存在 | work-plannerでDesign Docから作業計画書を作成し、タスク分解の前に**作業計画書レビュー**（下記参照）を行う |
 | どちらもなし | `$ARGUMENTS`なし、計画書なし、Consumed Task Setなし、Design Docなし | 前提条件未達成をユーザーに報告して停止 |
 
+## 作業計画書レビュー（本レシピが計画書を作成した場合）
+
+上記の判断フローでDesign Docから作業計画書を作成した場合、タスク分解の前にレビューする:
+
+1. Agentツールでdocument-reviewerを呼び出す:
+   - `subagent_type`: "document-reviewer"
+   - `description`: "作業計画書レビュー"
+   - `prompt`: "doc_type: WorkPlan target: docs/plans/[plan-name].md design_doc: [Design Docのパス]。Design Docへの意味的トレーサビリティ、早期検証の配置、実境界での検証カバレッジ、故障モードチェックリスト、レビュースコープをレビューする。"
+2. reviewerの `verdict.decision` で分岐する:
+   - `needs_revision` → 所見を渡してwork-plannerをupdateモードで再実行し、`approved`/`approved_with_conditions` になるまで再レビューする
+   - `rejected` → タスク分解の前に停止しユーザーにエスカレーションする
+3. レビュー済みの計画書をタスク分解の前にバッチ承認のため提示する。
+
 ## タスク分解フェーズ（条件付き）
 
 Consumed Task Set が空の場合：

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

@@ -23,6 +23,7 @@ description: 設計ドキュメントからフロントエンド作業計画書
 - 設計書の選択
 - acceptance-test-generatorによるテストスケルトン生成
 - work-plannerによる作業計画書作成
+- document-reviewerによる作業計画書レビュー
 - 計画承認の取得
 
 **責務境界**: このコマンドは作業計画書承認で責務完了。
@@ -59,7 +60,19 @@ Agentツールでwork-plannerを呼び出す:
   `prompt`: "[パス]のDesign Docから作業計画を作成。"
 
 - subagents-orchestration-guideのPrompt Construction Ruleに従い追加パラメータを構成
-- 作業計画書をユーザーに提示しレビューを受ける。変更要望があればwork-plannerを修正パラメータで再実行
+
+### Step 4: 作業計画書レビュー
+document-reviewerを呼び出し作業計画書をレビューする:
+- `subagent_type`: "document-reviewer"
+- `description`: "作業計画書レビュー"
+- `prompt`: "doc_type: WorkPlan target: docs/plans/[plan-name].md design_doc: [ステップ1で選択したDesign Docのパス]。Design Docへの意味的トレーサビリティ、早期検証の配置、実境界での検証カバレッジ、故障モードチェックリスト、レビュースコープをレビューする。"
+- 作業計画書はDesign Docの派生物であるため、計画の忠実性に関する指摘はユーザー入力なしで解消する。reviewerの `verdict.decision` で分岐する:
+  - `needs_revision`: 所見を渡してwork-plannerをupdateモードで再実行し、`approved`/`approved_with_conditions` になるまで再レビューを繰り返す
+  - `approved` / `approved_with_conditions`: ステップ5へ進む
+  - `rejected`: ユーザーにエスカレーションする
+
+### Step 5: 承認のための提示
+- レビュー済みの作業計画書をユーザーにバッチ承認のため提示する。変更要望があればwork-plannerを修正パラメータで再実行し、ステップ4を再実行する。
 - スコープが不明確なステップや外部依存があるステップを強調し、ユーザーに確認を求める
 
 **スコープ**: 作業計画書作成と計画内容の承認取得まで。

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

@@ -23,6 +23,7 @@ description: 設計書から作業計画書を作成し計画承認を取得
 - 設計書の選択
 - E2Eテストスケルトン生成（オプション、ユーザー確認後）
 - work-plannerによる作業計画書作成
+- document-reviewerによる作業計画書レビュー
 - 計画承認の取得
 
 **責務境界**: このコマンドは作業計画書承認で責務完了。
@@ -55,7 +56,20 @@ description: 設計書から作業計画書を作成し計画承認を取得
      `prompt`: "[パス]のDesign Docから作業計画を作成。"
 
    - subagents-orchestration-guideのプロンプト構成ルールに従い追加パラメータを設定
-   - ユーザーと対話して計画を完成させ、計画内容の承認を得る
+
+4. **作業計画書レビュー**
+   document-reviewerを呼び出し作業計画書をレビューする:
+   - `subagent_type`: "document-reviewer"
+   - `description`: "作業計画書レビュー"
+   - `prompt`: "doc_type: WorkPlan target: docs/plans/[plan-name].md design_doc: [ステップ1で選択したDesign Docのパス]。Design Docへの意味的トレーサビリティ、早期検証の配置、実境界での検証カバレッジ、故障モードチェックリスト、レビュースコープをレビューする。"
+   - 作業計画書はDesign Docの派生物であるため、計画の忠実性に関する指摘はユーザー入力なしで解消する。reviewerの `verdict.decision` で分岐する:
+     - `needs_revision`: 所見を渡してwork-plannerをupdateモードで再実行し、`approved`/`approved_with_conditions` になるまで再レビューを繰り返す
+     - `approved` / `approved_with_conditions`: ステップ5へ進む
+     - `rejected`: ユーザーにエスカレーションする
+
+5. **承認のための提示**
+   - レビュー済みの作業計画書をユーザーにバッチ承認のため提示する。変更要望があればwork-plannerを修正パラメータで再実行し、ステップ4を再実行する。
+   - スコープが不明確なステップや外部依存があるステップを強調し、ユーザーに確認を求める
 
 選択された設計書から作業計画書を作成し、実装の具体的なステップとリスクを明確にします。
 

package/.claude/skills-en/documentation-criteria/references/plan-template.md

@@ -4,6 +4,7 @@ Created Date: YYYY-MM-DD
 Type: feature|fix|refactor
 Estimated Impact: X files
 Related Issue/PR: #XXX (if any)
+Review Scope: [planned-files scope derived from Design Doc and task targets; for a revision plan over existing work, base branch + diff range]
 <!-- The line below is medium / large only — small scale uses task-template instead of this plan-template. Keep the value line free of trailing comments so downstream parsers can extract the bare status (pending | ready | escalated). -->
 Implementation Readiness: pending
 
@@ -26,6 +27,10 @@ Implementation Readiness: pending
 - **Success criteria**: [extracted from Design Doc]
 - **Failure response**: [extracted from Design Doc]
 
+### Proof Strategy
+- **Proof obligation source**: [test skeleton annotations (primary failure mode, proof obligation) when skeletons exist; otherwise each AC's primary failure mode]
+- **Per-task propagation**: every task that implements a claim records Proof Obligations (see task template) so downstream review can judge whether the tests prove the claim, not merely run
+
 ## Quality Assurance Mechanisms (from Design Doc)
 
 Adopted quality gates for the change area. Each task in this plan must satisfy these mechanisms.
@@ -48,6 +53,21 @@ Maps each Design Doc technical requirement to the covering task(s). One row per
 
 **Gap Status values**: `covered` (task exists), `gap` (no task — requires justification in Notes, user confirmation required before plan approval)
 
+## Failure Mode Checklist
+
+Domain-independent failure categories this implementation must guard against. Enumerate all eight categories, mark each in the Applies? column as yes/no, and list a covering task for each that applies; keep entries free of project-specific names.
+
+| Category | Applies? | Covered By Task(s) |
+|---|---|---|
+| same-value | yes/no | [Phase X Task Y] |
+| no-op | yes/no | |
+| empty input | yes/no | |
+| invalid option | yes/no | |
+| missing config | yes/no | |
+| unavailable boundary | yes/no | |
+| shared-state dependency | yes/no | |
+| rollback-only visibility | yes/no | |
+
 ## UI Spec Component → Task Mapping
 
 Include this section when a UI Spec is among the inputs. Maps each component documented in the UI Spec to the task(s) that implement it. task-decomposer reads this table to populate each task's Investigation Targets with the corresponding UI Spec section. Omit the section when no UI Spec exists.

package/.claude/skills-en/documentation-criteria/references/task-template.md

@@ -56,9 +56,21 @@ Each row is an ADR decision the implementation in this task must comply with.
 - **Failure response**: [What to do if verification fails — e.g., "reassess approach before proceeding", "escalate to user"]
 - **Verification level**: [L1: Functional operation as end-user feature / L2: New tests added and passing / L3: Code builds without errors]
 
+## Proof Obligations
+(One entry per AC or claim this task implements. Derived from test skeleton annotations when present, otherwise from the AC's primary failure mode. Each test must prove its claim. Repeat the block below once per claim; the heading carries the AC ID or claim ID so downstream review can resolve coverage per claim.)
+
+### Obligation: [AC ID or claim ID]
+- **Claim**: [the behavior the AC promises]
+- **Primary failure mode**: [the regression the test turns red on]
+- **Boundary to exercise**: [public/integration boundary the test traverses, or "in-process unit"]
+- **State assertion**: [observable state before → action → after for state-changing claims; "N/A" otherwise]
+- **Mock boundary rationale**: [which boundaries may be mocked and why; "none" when all real]
+- **Residual**: [what this proof leaves unestablished, if any]
+
 ## Completion Criteria
 - [ ] All added tests pass
 - [ ] Operation verified per Operation Verification Methods above
+- [ ] Each Proof Obligation is met: the test turns red under its primary failure mode and exercises the stated boundary
 - [ ] Deliverables created (for research/design tasks)
 - [ ] (When Binding Decisions exist) Every Compliance Check evaluates to `Y` against the final implementation, with evidence recorded in Investigation Notes (file:line, test result, or command output)
 

package/.claude/skills-en/subagents-orchestration-guide/SKILL.md

@@ -156,9 +156,9 @@ Subagents respond in JSON format. Key fields for orchestrator decisions:
 | codebase-analyzer | analysisScope.categoriesDetected, dataModel.detected, qualityAssurance (mechanisms[], domainConstraints[]), focusAreas[], existingElements count, limitations | Pass focusAreas to technical-designer as context |
 | ui-analyzer | externalResources (status, per-axis fetch_status), componentStructure[], propsPatterns[], cssLayout[], stateDisplay[], focusAreas[], candidateWriteSet[], limitations | Pass the ui-analyzer JSON to ui-spec-designer and technical-designer-frontend; each consumes the fields named in its own input declaration |
 | code-verifier | status (consistent/mostly_consistent/needs_review/inconsistent), consistencyScore, discrepancies[], reverseCoverage (dataOperationsInCode, testBoundariesSectionPresent). Pre-implementation: verifies Design Doc claims against existing codebase. Post-implementation: verifies implementation consistency against Design Doc (pass `code_paths` scoped to changed files) | Flag discrepancies for document-reviewer |
-| task-executor | Input: `task_file` (required in orchestrated flows); optional Fix Mode signals `requiredFixes` or `incompleteImplementations` — when either is non-empty, skip `task_already_completed` and extend allowed list with each item's `file_path` / `location` (parse `location` as `file[:line]`). Output: status (escalation_needed/completed), filesModified[], testsAdded, requiresTestReview, escalation_type ∈ {task_file_not_found, task_already_completed, target_files_missing, design_compliance_violation, similar_function_found, similar_component_found, investigation_target_not_found, out_of_scope_file, dependency_version_uncertain, binding_decision_violation}. | On escalation_needed: handle by escalation_type |
-| quality-fixer | Input: `task_file` (path to current task file — always pass this in orchestrated flows), `filesModified` (extract from the upstream implementation step's response — passes the task's write set as the primary scope for stub-detection; falls back to `git diff HEAD` when omitted). Status: approved/stub_detected/blocked. `stub_detected` → route back to the implementation step with `incompleteImplementations[]` details for completion, then re-run quality-fixer. `blocked` → see quality-fixer blocked handling below | On stub_detected: re-invoke the implementation step. On blocked: see handling below |
-| document-reviewer | approvalReady (true/false) | Proceed to next step on true; request fixes on false |
+| task-executor | Input: `task_file` (required in orchestrated flows); optional Fix Mode signals `requiredFixes` or `incompleteImplementations` — when either is non-empty, skip `task_already_completed` and extend allowed list with each item's `file_path` / `location` (parse `location` as `file[:line]`); each `incompleteImplementations[]` entry may carry `type: "missing_logic" \| "hollow_test"` and the executor branches its fix action by `type`. Output: status (escalation_needed/completed), filesModified[], testsAdded, requiresTestReview, runnableCheck{level, executed, command, result, substance, substanceIssue, reason}, escalation_type ∈ {task_file_not_found, task_already_completed, target_files_missing, design_compliance_violation, similar_function_found, similar_component_found, investigation_target_not_found, out_of_scope_file, dependency_version_uncertain, binding_decision_violation, test_environment_not_ready}. | On escalation_needed: handle by escalation_type |
+| quality-fixer | Input: `task_file` (path to current task file — always pass this in orchestrated flows), `filesModified` (extract from the upstream implementation step's response — passes the task's write set as the primary scope for stub-detection; falls back to `git diff HEAD` when omitted), `runnableCheck` (extract from the upstream implementation step's response — passes the test execution evidence including `substance` and `substanceIssue` so the substance check has the runtime signal; omit when the upstream did not run tests). Status: approved/stub_detected/blocked. `stub_detected` → `incompleteImplementations[]` items carry `type: "missing_logic" \| "hollow_test"`; route back to the implementation step (which branches its fix action on `type`), then re-run quality-fixer. `blocked` → see quality-fixer blocked handling below | On stub_detected: re-invoke the implementation step. On blocked: see handling below |
+| document-reviewer | verdict.decision (approved/approved_with_conditions/needs_revision/rejected) | Proceed on approved/approved_with_conditions; request fixes on needs_revision; escalate on rejected |
 | design-sync | sync_status (NO_CONFLICTS/CONFLICTS_FOUND) | On CONFLICTS_FOUND: present conflicts to user before proceeding |
 | integration-test-reviewer | status (approved/needs_revision/blocked), requiredFixes | On needs_revision: re-invoke the routed executor in Fix Mode with the same task_file and requiredFixes[] |
 | security-reviewer | status (approved/approved_with_notes/needs_revision/blocked), findings, notes, requiredFixes | On needs_revision: create a consolidated fix task file with the affected file paths from `requiredFixes[].location` populated into Target Files, then invoke the routed executor in Fix Mode with that task_file and the `requiredFixes[]` array, then quality-fixer, then re-invoke security-reviewer to verify resolution. On blocked: escalate to user with the blocking findings — fix is not within the agent layer's authority |
@@ -175,7 +175,7 @@ When quality-fixer returns `status: "blocked"`, discriminate by `reason`:
 When receiving new features or change requests, I first request requirement analysis from requirement-analyzer.
 According to scale determination:
 
-### Large Scale (6+ Files) - 13 Steps (backend) / 15 Steps (frontend/fullstack)
+### Large Scale (6+ Files) - 14 Steps (backend) / 16 Steps (frontend/fullstack)
 
 1. requirement-analyzer → Requirement analysis + Check existing PRD **[Stop]**
 2. prd-creator → PRD creation
@@ -190,10 +190,11 @@ According to scale determination:
 11. document-reviewer → Design Doc review (pass code-verifier results as code_verification; cross-layer: per Design Doc)
 12. design-sync → Consistency verification **[Stop: Design Doc Approval]**
 13. acceptance-test-generator → Test skeleton generation, pass to work-planner (*1)
-14. work-planner → Work plan creation **[Stop: Batch approval]**
-15. task-decomposer → Autonomous execution → Completion report
+14. work-planner → Work plan creation
+15. document-reviewer → Work plan review (doc_type: WorkPlan; pass the Design Doc path so AC/contract/state coverage is traceable). On `needs_revision`: re-invoke work-planner (update) and re-review until `approved`/`approved_with_conditions` — the plan is a derivation of the Design Doc, so plan-fidelity findings need no user adjudication. On `rejected`: escalate to user. **[Stop: Batch approval]**
+16. task-decomposer → Autonomous execution → Completion report
 
-### Medium Scale (3-5 Files) - 9 Steps (backend) / 11 Steps (frontend/fullstack)
+### Medium Scale (3-5 Files) - 10 Steps (backend) / 12 Steps (frontend/fullstack)
 
 1. requirement-analyzer → Requirement analysis **[Stop]**
 2. **(frontend/fullstack only)** Ask user for prototype code → ui-spec-designer → UI Spec creation (UI Spec informs component structure for technical design)
@@ -204,8 +205,9 @@ According to scale determination:
 7. document-reviewer → Design Doc review (pass code-verifier results as code_verification; cross-layer: per Design Doc)
 8. design-sync → Consistency verification **[Stop: Design Doc Approval]**
 9. acceptance-test-generator → Test skeleton generation, pass to work-planner (*1)
-10. work-planner → Work plan creation **[Stop: Batch approval]**
-11. task-decomposer → Autonomous execution → Completion report
+10. work-planner → Work plan creation
+11. document-reviewer → Work plan review (doc_type: WorkPlan; pass the Design Doc path so AC/contract/state coverage is traceable). On `needs_revision`: re-invoke work-planner (update) and re-review until `approved`/`approved_with_conditions` — the plan is a derivation of the Design Doc, so plan-fidelity findings need no user adjudication. On `rejected`: escalate to user. **[Stop: Batch approval]**
+12. task-decomposer → Autonomous execution → Completion report
 
 ### Small Scale (1-2 Files) - 2 Steps
 

package/.claude/skills-ja/documentation-criteria/references/plan-template.md

@@ -4,6 +4,7 @@
 種別: feature|fix|refactor
 想定影響範囲: Xファイル
 関連Issue/PR: #XXX（該当する場合）
+レビュースコープ: [Design Docとタスク対象から導出した変更予定ファイルの範囲。既存作業に対する改訂計画の場合はベースブランチ + diff範囲]
 <!-- 下記の行はmedium / large規模のみ — small規模はこのplan-templateではなくtask-templateを使用する。値の行は末尾コメントを付けず、下流のパーサがbare statusの抽出（pending | ready | escalated）を行えるように保つこと。 -->
 Implementation Readiness: pending
 
@@ -26,6 +27,10 @@ Implementation Readiness: pending
 - **成功基準**: [Design Docから抽出]
 - **失敗時の対応**: [Design Docから抽出]
 
+### 証明戦略
+- **証明義務の出所**: [スケルトンが存在する場合はテストスケルトンの注釈（主要な故障モード、証明義務）。存在しない場合は各ACの主要な故障モード]
+- **タスクごとの伝播**: 主張を実装する各タスクは Proof Obligations（task template参照）を記録し、下流のレビューがテストが主張を証明しているか（単に実行されるだけでないか）を判定できるようにする
+
 ## 品質保証メカニズム（Design Docより）
 
 変更対象領域で採用された品質ゲート。本計画の各タスクはこれらのメカニズムを満たす必要がある。
@@ -48,6 +53,21 @@ Design Docの各技術要件をカバーするタスクへのマッピング。
 
 **ギャップステータス値**: `covered`（タスクあり）、`gap`（タスクなし — 備考に理由必須、計画承認前にユーザー確認が必要）
 
+## 故障モードチェックリスト
+
+この実装が防ぐべきドメイン非依存の故障カテゴリ。8カテゴリすべてを列挙し、各カテゴリの該当列に yes/no を記入し、該当する各カテゴリにカバーするタスクを挙げる。エントリにはプロジェクト固有の名称を含めない。
+
+| カテゴリ | 該当? | カバーするタスク |
+|---|---|---|
+| same-value | yes/no | [Phase X タスクY] |
+| no-op | yes/no | |
+| empty input | yes/no | |
+| invalid option | yes/no | |
+| missing config | yes/no | |
+| unavailable boundary | yes/no | |
+| shared-state dependency | yes/no | |
+| rollback-only visibility | yes/no | |
+
 ## UI Specコンポーネント → タスクマッピング
 
 入力にUI Specが含まれる場合のみ本セクションを記載する。UI Specに記述された各コンポーネントを実装するタスクへのマッピング。task-decomposerはこの表を読み込み、対応するUI Specセクションを各タスクのInvestigation Targetsに伝播させる。UI Specがない場合は本セクションを省略する。

package/.claude/skills-ja/documentation-criteria/references/task-template.md

@@ -56,9 +56,21 @@ Metadata:
 - **失敗時の対応**: [検証失敗時の対処 — 例: 「続行前にアプローチを再評価」「ユーザーにエスカレーション」]
 - **検証レベル**: [L1: エンドユーザー機能としての動作確認 / L2: 新規テスト追加・パス / L3: ビルドエラーなし]
 
+## Proof Obligations
+（このタスクが実装するACまたは主張ごとに1エントリ。スケルトンの注釈がある場合はそこから、なければACの主要な故障モードから導出する。各テストは主張を証明すること。下記ブロックを主張ごとに繰り返し、見出しにAC IDまたは主張IDを記載して下流のレビューが主張ごとにカバレッジを解決できるようにする。）
+
+### Obligation: [AC IDまたは主張ID]
+- **主張**: [ACが約束する振る舞い]
+- **主要な故障モード**: [テストがレッドになるリグレッション]
+- **検証する境界**: [テストが通過する公開/統合境界、または "in-process unit"]
+- **状態アサーション**: [状態変更を伴う主張では 操作前 → 操作 → 操作後 の観察可能な状態。それ以外は "N/A"]
+- **モック境界の根拠**: [どの境界をモックしてよいか、その理由。すべて実物なら "none"]
+- **残余**: [この証明で未確立のまま残る事項があれば記載]
+
 ## Completion Criteria
 - [ ] 追加した全テストがパス
 - [ ] Operation Verification Methods に基づく動作確認完了
+- [ ] 各 Proof Obligation が満たされている: テストが主要な故障モードでレッドになり、指定された境界を通過する
 - [ ] 成果物作成完了（調査・設計タスクの場合）
 - [ ] （Binding Decisionsがある場合）全てのCompliance Checkが最終実装に対して`Y`と評価され、根拠（file:line、テスト結果、またはコマンド出力）がInvestigation Notesに記録されている
 

package/.claude/skills-ja/subagents-orchestration-guide/SKILL.md

@@ -154,9 +154,9 @@ description: サブエージェントのタスク分担と連携を調整。規
 | codebase-analyzer | analysisScope.categoriesDetected, dataModel.detected, qualityAssurance (mechanisms[], domainConstraints[]), focusAreas[], existingElements count, limitations | focusAreasをtechnical-designerにコンテキストとして渡す |
 | ui-analyzer | externalResources (status, per-axis fetch_status), componentStructure[], propsPatterns[], cssLayout[], stateDisplay[], focusAreas[], candidateWriteSet[], limitations | ui-analyzerのJSONをui-spec-designerとtechnical-designer-frontendに渡す。各エージェントは自身の入力宣言に記載されたフィールドを使う |
 | code-verifier | status (consistent/mostly_consistent/needs_review/inconsistent), consistencyScore, discrepancies[], reverseCoverage (dataOperationsInCode, testBoundariesSectionPresent). 実装前: Design Docの主張を既存コードに対して検証。実装後: 実装のDesign Doc整合性を検証（`code_paths`で変更ファイルにスコープ） | discrepanciesをdocument-reviewerに連携 |
-| task-executor | 入力: `task_file`（オーケストレーションフローでは必須）; 任意の Fix Mode シグナル `requiredFixes` または `incompleteImplementations` — いずれかが非空の場合、`task_already_completed` チェックをスキップし、各項目の `file_path` / `location`（`location` は `file[:line]` として解釈）で許可リストを拡張する。出力: status (escalation_needed/completed), filesModified[], testsAdded, requiresTestReview, escalation_type ∈ {task_file_not_found, task_already_completed, target_files_missing, design_compliance_violation, similar_function_found, similar_component_found, investigation_target_not_found, out_of_scope_file, dependency_version_uncertain, binding_decision_violation} | escalation_needed時: escalation_type別に対応 |
-| quality-fixer | 入力: `task_file`（現在のタスクファイルパス — オーケストレーションフローでは常に渡す）、`filesModified`（上流の実装ステップのレスポンスから抽出 — 当該タスクの書き込み集合を未完成実装検出の主要スコープとして渡す。省略時は `git diff HEAD` にフォールバック）。Status: approved/stub_detected/blocked。`stub_detected` → 上流の実装ステップに `incompleteImplementations[]` の詳細を添えて差し戻し、本実装完了後にquality-fixerを再実行。`blocked` → 下記quality-fixer blockedハンドリング参照 | stub_detected: 実装ステップを再実行。blocked: 下記参照 |
-| document-reviewer | approvalReady (true/false) | trueで次ステップへ。falseで修正を依頼 |
+| task-executor | 入力: `task_file`（オーケストレーションフローでは必須）; 任意の Fix Mode シグナル `requiredFixes` または `incompleteImplementations` — いずれかが非空の場合、`task_already_completed` チェックをスキップし、各項目の `file_path` / `location`（`location` は `file[:line]` として解釈）で許可リストを拡張する。`incompleteImplementations[]` の各エントリは `type: "missing_logic" \| "hollow_test"` を持ち得て、executor は `type` で修正アクションを分岐する。出力: status (escalation_needed/completed), filesModified[], testsAdded, requiresTestReview, runnableCheck{level, executed, command, result, substance, substanceIssue, reason}, escalation_type ∈ {task_file_not_found, task_already_completed, target_files_missing, design_compliance_violation, similar_function_found, similar_component_found, investigation_target_not_found, out_of_scope_file, dependency_version_uncertain, binding_decision_violation, test_environment_not_ready} | escalation_needed時: escalation_type別に対応 |
+| quality-fixer | 入力: `task_file`（現在のタスクファイルパス — オーケストレーションフローでは常に渡す）、`filesModified`（上流の実装ステップのレスポンスから抽出 — 当該タスクの書き込み集合を未完成実装検出の主要スコープとして渡す。省略時は `git diff HEAD` にフォールバック）、`runnableCheck`（上流の実装ステップのレスポンスから抽出 — `substance` と `substanceIssue` を含むテスト実行のエビデンスを渡し、Substance チェックが実行時のシグナルを受け取れるようにする。上流がテストを実行していない場合は省略可）。Status: approved/stub_detected/blocked。`stub_detected` → `incompleteImplementations[]` の各エントリは `type: "missing_logic" \| "hollow_test"` を持ち、`type` で executor 側の修正アクションを分岐させた上で上流の実装ステップに差し戻し、本実装完了後にquality-fixerを再実行。`blocked` → 下記quality-fixer blockedハンドリング参照 | stub_detected: 実装ステップを再実行。blocked: 下記参照 |
+| document-reviewer | verdict.decision (approved/approved_with_conditions/needs_revision/rejected) | approved/approved_with_conditionsで次へ。needs_revisionで修正依頼。rejectedでエスカレーション |
 | design-sync | sync_status (NO_CONFLICTS/CONFLICTS_FOUND) | CONFLICTS_FOUND時: 矛盾をユーザーに提示してから進む |
 | integration-test-reviewer | status (approved/needs_revision/blocked), requiredFixes | needs_revision時: 同じ task_file と requiredFixes[] を渡してルーティング先の executor を Fix Mode で再実行 |
 | security-reviewer | status (approved/approved_with_notes/needs_revision/blocked), findings, notes, requiredFixes | needs_revision時: `requiredFixes[].location` から影響ファイルパスを抽出して Target Files に投入した統合修正タスクファイルを作成し、その task_file と `requiredFixes[]` 配列を渡してルーティング先の executor を Fix Mode で起動。続いて quality-fixer を実行し、最後に security-reviewer を再起動して解消を検証する。blocked 時: ブロッキング findings を添えてユーザーにエスカレーション — エージェント層の権限外の修正である |
@@ -170,7 +170,7 @@ quality-fixerが `status: "blocked"` を返した場合、`reason`で判別：
 
 ## 作業計画時の基本フロー
 
-### 大規模（6ファイル以上） - 13ステップ（バックエンド） / 15ステップ（フロントエンド/フルスタック）
+### 大規模（6ファイル以上） - 14ステップ（バックエンド） / 16ステップ（フロントエンド/フルスタック）
 
 1. requirement-analyzer → 要件分析 + 既存PRD確認 **[停止]**
 2. prd-creator → PRD作成
@@ -185,10 +185,11 @@ quality-fixerが `status: "blocked"` を返した場合、`reason`で判別：
 11. document-reviewer → Design Docレビュー（code-verifier結果をcode_verificationとして入力。レイヤー横断時: Design Doc毎に実行）
 12. design-sync → 整合性検証 **[停止: Design Doc承認]**
 13. acceptance-test-generator → テストスケルトン生成、work-plannerに渡す (*1)
-14. work-planner → 作業計画書作成 **[停止: 一括承認]**
-15. task-decomposer → 自律実行 → 完了報告
+14. work-planner → 作業計画書作成
+15. document-reviewer → 作業計画書レビュー（doc_type: WorkPlan。AC/コントラクト/状態のカバレッジをトレースできるようDesign Docのパスを渡す）。`needs_revision` の場合: work-plannerを（updateで）再実行し `approved`/`approved_with_conditions` になるまで再レビューする — 作業計画書はDesign Docの派生物であるため、計画の忠実性に関する指摘にユーザー裁定は不要。`rejected` の場合: ユーザーにエスカレーション。 **[停止: 一括承認]**
+16. task-decomposer → 自律実行 → 完了報告
 
-### 中規模（3-5ファイル） - 9ステップ（バックエンド） / 11ステップ（フロントエンド/フルスタック）
+### 中規模（3-5ファイル） - 10ステップ（バックエンド） / 12ステップ（フロントエンド/フルスタック）
 
 1. requirement-analyzer → 要件分析 **[停止]**
 2. **（フロントエンド/フルスタックのみ）** プロトタイプコードの有無を確認 → ui-spec-designer → UI Spec作成（コンポーネント構造が技術設計に反映されるため先に実施）
@@ -199,8 +200,9 @@ quality-fixerが `status: "blocked"` を返した場合、`reason`で判別：
 7. document-reviewer → Design Docレビュー（code-verifier結果をcode_verificationとして入力。レイヤー横断時: Design Doc毎に実行）
 8. design-sync → 整合性検証 **[停止: Design Doc承認]**
 9. acceptance-test-generator → テストスケルトン生成、work-plannerに渡す (*1)
-10. work-planner → 作業計画書作成 **[停止: 一括承認]**
-11. task-decomposer → 自律実行 → 完了報告
+10. work-planner → 作業計画書作成
+11. document-reviewer → 作業計画書レビュー（doc_type: WorkPlan。AC/コントラクト/状態のカバレッジをトレースできるようDesign Docのパスを渡す）。`needs_revision` の場合: work-plannerを（updateで）再実行し `approved`/`approved_with_conditions` になるまで再レビューする — 作業計画書はDesign Docの派生物であるため、計画の忠実性に関する指摘にユーザー裁定は不要。`rejected` の場合: ユーザーにエスカレーション。 **[停止: 一括承認]**
+12. task-decomposer → 自律実行 → 完了報告
 
 ### 小規模（1-2ファイル） - 2ステップ
 

package/CHANGELOG.md

@@ -5,6 +5,27 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.23.2] - 2026-06-01
+
+### Added
+
+- **Proof-quality review gate** (agents, skills) — Verification is raised from "tests exist" to "tests prove the claim's primary failure mode." `acceptance-test-generator` emits `Primary failure mode` / `Proof obligation` annotations on every skeleton; `work-planner`, `task-decomposer`, plan-template, and task-template carry per-claim Proof Obligations into task files; `integration-test-reviewer` adds a Claim Proof Adequacy check with a `proof_insufficient` issue type; `code-reviewer` requires AC-coverage tests to turn red under the recorded primary failure mode and exercise the claimed boundary directly
+- **Planning-fidelity review gate** (agents, commands, skills) — The work plan now gets the same automated review the Design Doc does, before implementation starts. `document-reviewer` gains a `WorkPlan` doc_type semantic gate (Design-to-Plan traceability, early-verification placement, real-boundary coverage, Failure Mode Checklist, Review Scope) with a verdict mapping and a `design_doc` input; `work-planner` and plan-template add a Proof Strategy, Review Scope, and Failure Mode Checklist; the plan / front-plan recipes review the plan and self-heal `needs_revision` (re-plan and re-review) while escalating `rejected`; front-build reviews a plan it creates from a Design Doc before decomposition; `subagents-orchestration-guide` wires WorkPlan review into the Medium/Large planning flow and moves the `document-reviewer` output contract to `verdict.decision`
+
+## [1.23.1] - 2026-05-28
+
+### Added
+
+- **Acceptance evidence discipline** (agents, skills) — Substance check rejects cited test evidence that is hollow (skipped, TODO-only, always-true, or 0-match). `task-executor` reports `runnableCheck.substance` / `substanceIssue`; `quality-fixer` gates on it and routes unrecoverable hollow tests via `stub_detected` with new `incompleteImplementations[].type` (`missing_logic` / `hollow_test`). `code-reviewer` §3-3 and `integration-test-reviewer` add matching inspection criteria
+- **`test_environment_not_ready` escalation** (agents, skills) — `task-executor` / `-frontend` escalate with a typed reason when the required test toolchain is unavailable. Registered in `subagents-orchestration-guide`
+- **Frontend executor symmetry** (agents) — `task-executor-frontend` gains Reference Representativeness (IF-THEN by repository-wide file count) and `dependency_version_uncertain` escalation, matching the backend executor
+
+### Changed
+
+- **Reference Representativeness rule** (agents, skills) — Rewritten as explicit IF-THEN (3+ adopt / 1-2 investigate canonical-vs-legacy / 0 justify) so a canonical pattern with only 1-2 nearby files can still be adopted instead of being forced to escalate
+- **Frontend quality-fixer guidance** (agents) — Replace obsolete patterns (manual `cleanup()`, snapshot-first thinking) with current RTL practice (auto-cleanup, behavior assertions over snapshots, mock at the existing network boundary)
+- **Prompt tightening** (agents, skills) — Compressed Similar Function / Component Duplication Check; removed redundant Special Considerations (`code-reviewer`) and Important Principles (`quality-fixer`); added a Policy References hub to Fix Execution Policy; split `quality-fixer` `blocked` example into Variant A (specification conflict) and Variant B (missing prerequisites); `subagents-orchestration-guide` task-executor Output and quality-fixer Input contracts updated to carry `runnableCheck` through
+
 ## [1.23.0] - 2026-05-22
 
 ### Added

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-ai-project",
-  "version": "1.23.0",
+  "version": "1.23.2",
   "packageManager": "npm@10.8.2",
   "description": "TypeScript boilerplate with skills and sub-agents for Claude Code. Prevents context exhaustion through role-based task splitting.",
   "keywords": [