create-ai-project 1.23.1 → 1.23.3

package/.claude/agents-ja/task-decomposer.md

@@ -104,6 +104,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
    - `## Implementation Steps (TDD: Red-Green-Refactor)`
    - `## Quality Assurance Mechanisms`（作業計画書ヘッダーから導出 — 下記「品質保証メカニズムの伝播」参照）
    - `## Operation Verification Methods`（作業計画書の Verification Strategy から導出）
+   - `## Proof Obligations`（主張ごと — 下記「証明義務の伝播」参照）
    - `## Completion Criteria`
 
 6. **Investigation Targets の決定**
@@ -152,6 +153,14 @@ implementation-approachスキルで決定された実装戦略パターンに基
    - **検証レベル**: implementation-approachスキルに従いL1/L2/L3を選択
 3. **調査対象**: 検証に必要なリソースを含める（例: 比較対象の既存実装、スキーマ定義、seed dataのパス）
 
+## 証明義務の伝播
+
+主張を実装する各タスクは Proof Obligations（task template参照）を持ち、下流のレビューがテストが主張を証明しているか（単に実行されるだけでないか）を判定できるようにする:
+
+1. **出所**: テストスケルトンがタスクをカバーしている場合、その「主要な故障モード」と「証明義務」の注釈をタスクの Proof Obligations に転記する。スケルトンが主張をカバーしていない場合、主要な故障モードをACから導出し、境界・操作前後の状態アサーション・モック境界の根拠・残余をACとタスクの対象ファイルから導出する（その主張に該当しないフィールドは `N/A` とする — 例: 状態を変更しない主張では状態アサーションなし）。
+2. **主張ごと**: ACまたは主張ごとに1エントリを記録し、task template で定義された Proof Obligations の全フィールドを埋める。
+3. **主張がある場合に適用**: 振る舞いの主張を持たないタスク（純粋な設定やスキャフォールディング等）は本セクションを省略する。
+
 ## UI Spec伝播
 
 作業計画書に「UI Specコンポーネント → タスクマッピング」表が含まれる場合、各実装タスクにコンポーネント参照を以下のように伝播する:
@@ -348,6 +357,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
 - [ ] 全体設計書の作成
 - [ ] 実装効率と手戻り防止（共通処理の事前識別、影響範囲の明確化）
 - [ ] 全タスクに調査対象が指定されている（具体的なファイルパス、曖昧なカテゴリではない）
+- [ ] 主張を実装する各タスクに Proof Obligations を記録（主要な故障モード + 検証する境界）
 - [ ] 作業計画書ヘッダーの品質保証メカニズムを該当タスクに伝播済み
 
 ## タスク設計の原則

package/.claude/agents-ja/task-executor-frontend.md

@@ -94,6 +94,12 @@ package.json の `packageManager` フィールドに従って実行コマンド
 - 一致したのが (a+c) または (b+c) の組み合わせのみ → エスカレーション。その他の2項目組み合わせ → 継続実装
 - 1項目以下一致 → 継続実装
 
+### Step4: 中核メカニズム保全チェック（以下1つでもYES → 即エスカレーション）
+タスク・AC・Design Doc・UI Spec が要求する中核メカニズムを保全する。実装詳細（変数名、内部のロジック順序、ローカルな構造）は自由に変更してよいが、要求された中核メカニズムそのものは保つ。
+□ 要求された中核メカニズムを、より単純または弱い代替で置き換えようとしている？（テストが通ることは代替を正当化しない）
+□ 要求された中核メカニズムが仕様どおりには実現不可能？
+1つでもYES → 実装を中止し、`escalation_type: "design_compliance_violation"` でエスカレーション（エスカレーションレスポンス表に従い、ケースを契約フィールドに対応づける）: `design_doc_expectation` = 要求された中核メカニズムと、その出所となる文言（task/AC/Design Doc/UI Spec）; `actual_situation` = 提案された代替と、結果として生じる振る舞いの差分; `why_cannot_implement` = 中核メカニズムを置き換えた、または仕様どおりに実現できない理由; `attempted_approaches[]` = 中核メカニズムを保全するために試みた方法。実装前に実現不可能と判明している場合は `[]`; `claude_recommendation` = ブロックを解除する条件。
+
 ### 境界ケースと鉄則
 
 | ケース | 継続 | エスカレーション |
@@ -105,7 +111,7 @@ package.json の `packageManager` フィールドに従って実行コマンド
 
 **鉄則 — 客観的に判定不可のときはエスカレーション**: 判定項目について2通り以上の解釈が成り立つ; 過去の実装経験で遭遇していないパターン; 判定に必要な情報がDesign Docにない; 同等の技術者でも判断が分かれる。
 
-### 継続実装可（Step1-3 の全チェックが NO かつ明確に該当）
+### 継続実装可（Step1-4 の全チェックが NO かつ明確に該当）
 内部詳細の最適化（変数名、ロジック順序）; Design Doc 未記載の詳細仕様; 外部 API レスポンス用の `unknown` → 具体型への安全な型ガード; 軽微なUI・メッセージ文言調整。
 
 ## 責務・権限・境界

package/.claude/agents-ja/task-executor.md

@@ -94,6 +94,12 @@ package.json の `packageManager` フィールドに従って実行コマンド
 - 一致したのが (a+c) または (b+c) の組み合わせのみ → エスカレーション。その他の2項目組み合わせ → 継続実装
 - 1項目以下一致 → 継続実装
 
+### Step4: 中核メカニズム保全チェック（以下1つでもYES → 即エスカレーション）
+タスク・AC・Design Doc・参照資料が要求する中核メカニズムを保全する。実装詳細（変数名、内部の処理順序、ローカルな構造）は自由に変更してよいが、要求された中核メカニズムそのものは保つ。
+□ 要求された中核メカニズムを、より単純または弱い代替で置き換えようとしている？（テストが通ることは代替を正当化しない）
+□ 要求された中核メカニズムが仕様どおりには実現不可能？
+1つでもYES → 実装を中止し、`escalation_type: "design_compliance_violation"` でエスカレーション（エスカレーションレスポンス表に従い、ケースを契約フィールドに対応づける）: `design_doc_expectation` = 要求された中核メカニズムと、その出所となる文言（task/AC/Design Doc/参照資料）; `actual_situation` = 提案された代替と、結果として生じる振る舞いの差分; `why_cannot_implement` = 中核メカニズムを置き換えた、または仕様どおりに実現できない理由; `attempted_approaches[]` = 中核メカニズムを保全するために試みた方法。実装前に実現不可能と判明している場合は `[]`; `claude_recommendation` = ブロックを解除する条件。
+
 ### 境界ケースと鉄則
 
 | ケース | 継続 | エスカレーション |
@@ -105,7 +111,7 @@ package.json の `packageManager` フィールドに従って実行コマンド
 
 **鉄則 — 客観的に判定不可のときはエスカレーション**: 判定項目について2通り以上の解釈が成り立つ; 過去の実装経験で遭遇していないパターン; 判定に必要な情報がDesign Docにない; 同等の技術者でも判断が分かれる。
 
-### 継続実装可（Step1-3 の全チェックが NO かつ明確に該当）
+### 継続実装可（Step1-4 の全チェックが NO かつ明確に該当）
 内部詳細の最適化（変数名、処理順序）; Design Doc 未記載の詳細仕様; `unknown` → 具体型への安全な型ガード; 軽微なUI・メッセージ文言調整。
 
 ## 責務・権限・境界

package/.claude/agents-ja/technical-designer-frontend.md

@@ -30,29 +30,7 @@ ADR/Design Docの作成閾値はdocumentation-criteriaスキルに準拠。判
 
 ### ゲート順序 [BLOCKING]
 
-以下のサブセクションは並列の必須事項ではなく、4段階の直列ゲートを構成する。各ゲートを完了してから次のゲートに進むこと。各ゲート内では列挙されたサブセクションすべてが必須（各サブセクションの条件に従う）。
-
-**Gate 0 — Inputs and Standards**（上流依存なし）:
-- Agreement Checklist
-- Standards Identification
-
-**Gate 1 — Existing State Analysis**（Gate 0 に依存）:
-- Existing Code Investigation
-- Fact Disposition（Codebase Analysis 入力が提供される場合）
-- Minimal Surface Alternatives（永続化されるクライアント/サーバー状態、所有境界を越える Props またはフィールド — エクスポートされた再利用可能コンポーネントの公開 API Props、Context 値、所有境界を越えて持ち上げられた状態 — 観測可能な振る舞いを変える振る舞いモード/バリアント、または再利用可能なコンポーネント分割を導入する場合）
-
-**Gate 2 — Design Decisions**（Gate 1 に依存）:
-- Implementation Approach Decision
-- Common ADR Process
-- Data Contracts
-- State Transitions（該当する場合）
-
-**Gate 3 — Impact Documentation**（Gate 2 に依存）:
-- Integration Point Analysis
-- Change Impact Map
-- Interface Change Impact Analysis
-
-各サブセクションには見出しに `[Gate N — ...]` の注記を付す。サブセクションはゲート順（Gate 0 → 1 → 2 → 3）で記載されており、文書順に実行すること。
+以下のサブセクションは並列の必須事項ではなく、4段階の直列ゲートを構成する: **Gate 0** Inputs & Standards → **Gate 1** Existing-State Analysis → **Gate 2** Design Decisions → **Gate 3** Impact Documentation。各ゲートを完了してから次のゲートに進むこと。各サブセクションには見出しに `[Gate N — ...]` の注記（適用条件を含む）が付き、ゲート順に記載されている。文書順に実行すること。
 
 ### 合意事項チェックリスト [Gate 0 — Required]
 Design Doc作成の最初に必ず実施：
@@ -331,31 +309,7 @@ UI Specが存在する場合（`docs/ui-spec/{feature-name}-ui-spec.md`）:
 
 **必須**: ADR/Design Doc 内の実装サンプルは frontend-typescript-rules スキルに必ず準拠すること。必須項目: function components（class components は非推奨）; 全コンポーネントに Props 型定義; ロジック再利用にはカスタムフック; 厳密な型（外部APIレスポンスは `unknown` + 型ガード、`any` 禁止）; Error Boundary / エラー状態管理; 環境変数 — 秘密情報はサーバーサイドのみ。
 
-準拠サンプル（Props型付き function component、`unknown` を型ガードする fetch のカスタムフック）:
-
-```typescript
-type ButtonProps = { label: string; onClick: () => void; disabled?: boolean }
-export function Button({ label, onClick, disabled = false }: ButtonProps) {
-  return <button onClick={onClick} disabled={disabled}>{label}</button>
-}
-
-function useUserData(userId: string) {
-  const [user, setUser] = useState<User | null>(null)
-  const [error, setError] = useState<Error | null>(null)
-  useEffect(() => {
-    void (async () => {
-      try {
-        const data: unknown = await (await fetch(`/api/users/${userId}`)).json()
-        if (!isUser(data)) throw new Error('Invalid user data')
-        setUser(data)
-      } catch (e) { setError(e instanceof Error ? e : new Error('Unknown error')) }
-    })()
-  }, [userId])
-  return { user, error }
-}
-```
-
-非準拠: class components、`any`、ガードなし型なしレスポンス、クライアントサイドに埋め込まれた秘密情報。
+非準拠: class components（Error Boundary を除く）、`any`、ガードなし型なしレスポンス、クライアントサイドに埋め込まれた秘密情報。
 
 ## 図表作成（mermaid）
 
@@ -394,6 +348,14 @@ function useUserData(userId: string) {
 
 ## 受け入れ基準作成ガイドライン
 
+### 価値起点のドラフトと境界拡張
+
+各ACは価値起点でドラフトし、下記のスコーピングルールを適用する前に要件境界へ展開する:
+
+1. **価値起点**: まずユーザーにとっての価値を挙げ、次にそれを実現する観察可能なUIの振る舞い、最後にそれを支える技術的境界を特定する。
+2. **境界への展開**（候補抽出 — 採否は下記のスコーピングルールが決定）: ある振る舞いはハッピーパスでは成立しつつ、別の状態で退行しうる。振る舞いを変えるACごとに、約束した振る舞いが成立すべき箇所すべてでACを検討する — 単一/最新/全件のリスト描画、隣接する Props やフィールド、ローディング/空/エラーおよび後続のインタラクション状態、stale または欠損データ、フェッチ失敗やフォールバックUI、権限/バリデーションのゲーティング、入力スコープと順序/選択、副作用、可視性やルートの境界（状態が別画面・別コンポーネント・ナビゲーション後に観察可能になる箇所）。
+3. **同一粒度での比較**: ACが既存または参照先の振る舞いに関わる場合、参照元（source）の振る舞いと対象（target）の振る舞いを同じ詳細度で記述し、各境界が保持されているか意図的に変更されたかをレビュアーが確認できるようにする。
+
 ### 自律実装のためのACスコーピング（フロントエンド）
 
 **原則**: AC = 隔離されたCI環境でブラウザ上で検証可能なユーザー観察可能動作。ハッピーパス、アンハッピーパス（エラー）、エッジケース（空状態・ローディング状態）をカバー。重要なACを上位に配置し、非機能要件は別セクションで定義する。

package/.claude/agents-ja/technical-designer.md

@@ -29,31 +29,7 @@ ADR/Design Docの作成閾値はdocumentation-criteriaスキルに準拠。判
 
 ### ゲート順序 [BLOCKING]
 
-以下のサブセクションは並列の必須事項ではなく、4段階の直列ゲートを構成する。各ゲートを完了してから次のゲートに進むこと。各ゲート内では列挙されたサブセクションすべてが必須（各サブセクションの条件に従う）。
-
-**Gate 0 — Inputs and Standards**（上流依存なし）:
-- Agreement Checklist
-- Standards Identification
-
-**Gate 1 — Existing State Analysis**（Gate 0 に依存）:
-- Existing Code Investigation
-- Fact Disposition（Codebase Analysis 入力が提供される場合）
-- Data Representation Decision（新規または変更されるデータ構造を導入する場合）
-- Minimal Surface Alternatives（永続状態、公開コントラクト要素または境界を越えるフィールド、振る舞いモード/フラグ、再利用可能な抽象を導入する場合）
-
-**Gate 2 — Design Decisions**（Gate 1 に依存）:
-- Implementation Approach Decision
-- Common ADR Process
-- Data Contracts
-- State Transitions（該当する場合）
-
-**Gate 3 — Impact Documentation**（Gate 2 に依存）:
-- Integration Points
-- Change Impact Map
-- Field Propagation Map（フィールドがコンポーネント境界を越える場合）
-- Interface Change Impact Analysis
-
-各サブセクションには見出しに `[Gate N — ...]` の注記を付す。サブセクションはゲート順（Gate 0 → 1 → 2 → 3）で記載されており、文書順に実行すること。
+以下のサブセクションは並列の必須事項ではなく、4段階の直列ゲートを構成する: **Gate 0** Inputs & Standards → **Gate 1** Existing-State Analysis → **Gate 2** Design Decisions → **Gate 3** Impact Documentation。各ゲートを完了してから次のゲートに進むこと。各サブセクションには見出しに `[Gate N — ...]` の注記（適用条件を含む）が付き、ゲート順に記載されている。文書順に実行すること。
 
 ### 合意事項チェックリスト [Gate 0 — Required]
 Design Doc作成の最初に必ず実施：
@@ -370,6 +346,14 @@ Design Doc作成時に必ず含める:
 
 ## 受け入れ基準作成ガイドライン
 
+### 価値起点のドラフトと境界拡張
+
+各ACは価値起点でドラフトし、下記のルールを適用する前に要件境界へ展開する:
+
+1. **価値起点**: まずユーザー/オペレーター/保守者にとっての価値を挙げ、次にそれを実現する観測可能な振る舞い、最後にそれを支える技術的境界を特定する。
+2. **境界への展開**（候補抽出 — 採否は下記ルールが決定）: ある振る舞いはメインパスでは成立しつつ、別の次元で退行しうる。振る舞いを変えるACごとに、約束した振る舞いが成立すべき箇所すべてでACを検討する — 単一/最新/全件のコレクション、同一サーフェス上の隣接フィールド、後続のライフサイクル状態やリトライ、stale/欠損/空の値、リフレッシュ失敗やフォールバック不在、権限/バリデーション/ポリシーの境界、入力スコープと選択/順序/識別キー、副作用、公開・可視性の境界（状態が別プロセス・コンポーネント・ユーザー・後続ステップから観測可能になる箇所）。
+3. **同一粒度での比較**: ACが既存または参照先の振る舞いに関わる場合、参照元（source）の振る舞いと対象（target）の振る舞いを同じ詳細度で記述し、各境界が保持されているか意図的に変更されたかをレビュアーが確認できるようにする。
+
 ### 測定可能なACの書き方
 
 **原則**: AC = 独立した環境で検証可能かつユーザーが観測可能な振る舞い。正常系・異常系・エッジケースをカバー。非機能要件（パフォーマンス、信頼性、スケーラビリティ）は別の「非機能要件」セクションで定義する。

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/frontend-technical-spec/SKILL.md

@@ -17,10 +17,10 @@ TypeScript-based React application implementation. Architecture patterns should
 - Properly implement default value settings and mandatory checks
 
 ```typescript
-// Build tool environment variables (public values only)
+// Build tool environment variables (public values only; client-exposed vars need the VITE_ prefix)
 const config = {
-  apiUrl: import.meta.env.API_URL || 'http://localhost:3000',
-  appName: import.meta.env.APP_NAME || 'My App'
+  apiUrl: import.meta.env.VITE_API_URL || 'http://localhost:3000',
+  appName: import.meta.env.VITE_APP_NAME || 'My App'
 }
 
 // Does not work in frontend
@@ -37,7 +37,7 @@ const apiUrl = process.env.API_URL
 **Correct Approach for Secrets**:
 ```typescript
 // Security risk: API key exposed in browser
-const apiKey = import.meta.env.API_KEY
+const apiKey = import.meta.env.VITE_API_KEY
 const response = await fetch(`https://api.example.com/data?key=${apiKey}`)
 
 // Correct: Backend manages secrets, frontend accesses via proxy