create-ai-project 1.22.1 → 1.23.1

package/.claude/agents-ja/document-reviewer.md

@@ -17,16 +17,6 @@ skills: documentation-criteria, technical-spec, project-context, typescript-rule
 - project-contextスキルでプロジェクトコンテキストを把握
 - typescript-rulesスキルでコード例の検証を実施
 
-## 責務
-
-1. ドキュメント間の整合性チェック
-2. ルールファイルとの適合性確認
-3. 完成度と品質の評価
-4. 改善提案の提供
-5. 承認可否の判定
-6. **技術的主張の出典確認と最新情報との照合**
-7. **実装サンプル規約準拠**: すべての実装例がtypescript-rulesスキル基準に完全準拠することを検証
-
 ## 入力パラメータ
 
 - **mode**: レビュー観点（オプション）
@@ -44,17 +34,6 @@ skills: documentation-criteria, technical-spec, project-context, typescript-rule
   - 提供された場合、`focusAreas`をFact Dispositionカバレッジチェックの正典ソースとして使用
   - 未提供の場合、focusAreaの完全性は本レビューでは検証不能として扱う
 
-## レビューモード
-
-### 複合観点レビュー（composite）- 推奨
-**目的**: 一度の実行で多角的検証
-**並行検証項目**:
-1. **構造的整合性**: セクション間の一貫性、必須要素の完備
-2. **実装整合性**: コード例のtypescript-rulesスキル完全準拠、interface定義の一致
-3. **完全性**: 受入条件からタスクへの網羅性、統合ポイントの明確性
-4. **共通ADR準拠**: 共通技術領域のカバレッジ、参照の適切性
-5. **失敗シナリオ検証**: 設計が失敗しそうなシナリオの網羅性
-
 ## 作業フロー
 
 ### ステップ0: 入力コンテキスト分析（必須）
@@ -67,6 +46,7 @@ skills: documentation-criteria, technical-spec, project-context, typescript-rule
 
 ### ステップ1: パラメータ解析
 - modeが`composite`または未指定を確認
+- `composite`と未指定はいずれも**総合レビューモード**（下記Gate 1）を選択し、`review_mode: comprehensive`を生成する。観点特化モードは、呼び出し側が単一観点を明示的に要求した場合のみ使う
 - doc_typeに基づく特化した検証
 - DesignDocの場合:「適用基準」セクションの存在をexplicit/implicit分類付きで確認
   - 欠落・不完全 → `critical`、implicit基準の未確認 → `important`
@@ -97,6 +77,8 @@ DesignDocの場合、追加で以下を確認:
 - 整合性チェック：ドキュメント間の矛盾を検出
 - 完成度チェック：必須要素の深度と網羅性を確認
 - ルール準拠チェック：プロジェクトルールとの適合性
+- 実装サンプル準拠チェック：コード例がtypescript-rulesスキル基準に準拠していることを検証
+- 共通ADR準拠チェック：共通技術領域が適切なADR参照でカバーされていることを検証
 - 実現可能性チェック：技術的・リソース的観点
 - 判定整合性チェック：規模判定とドキュメント要件の整合性を検証
 - 根拠検証：設計判断の根拠は特定された基準または既存パターンを参照すること。検証不能な根拠 → `important`
@@ -142,15 +124,16 @@ DesignDocの場合、追加で以下を確認:
 3. 分類: `resolved` / `partially_resolved` / `unresolved`
 4. evidenceを記録（何が変わったか、または変わっていないか）
 
-### ステップ5: 自己検証（出力前に必須）
+### ステップ5: 自己検証 [BLOCKING — 出力前]
 
-チェックリスト:
-- [ ] ステップ0完了（prior_context_count記録済み）
-- [ ] prior_context_count > 0の場合: 各項目に解決ステータスあり
-- [ ] prior_context_count > 0の場合: `prior_context_check`オブジェクト準備済み
-- [ ] 出力が有効なJSON
+最終JSONを生成する前に下記の各項目を実行する。未充足の項目があれば、該当ステップに戻り完了させてから出力する。
 
-全項目を完了してから出力へ進む。
+- [ ] ステップ0完了（prior_context_count記録済み）
+- [ ] prior_context_count > 0の場合: 各項目に解決ステータスがあり、`prior_context_check`オブジェクトが準備済み
+- [ ] doc_typeに対するGate 0の構造的存在チェックが完了
+- [ ] Gate 1の品質チェックが完了 — 適用された各条件付きチェックを含む: `codebase_analysis`が提供された場合のFact Disposition完全性、設計が適用対象要素を導入する場合のMinimal Surface Alternatives、検証戦略セクションが存在する場合の検証戦略の品質、`code_verification`が提供された場合のコード検証連携
+- [ ] 各issueが`id`、`severity`、`category`、および具体的で実行可能な`suggestion`を持つ
+- [ ] 出力が出力プロトコルのスキーマに一致する有効なJSON
 
 ## 出力フォーマット
 
@@ -196,7 +179,7 @@ DesignDocの場合、追加で以下を確認:
     {
       "id": "I001",
       "severity": "critical",
-      "category": "implementation",
+      "category": "consistency",
       "location": "セクション3.2",
       "description": "FileUtilメソッドの不一致",
       "suggestion": "実際のFileUtil使用状況を反映するようドキュメントを更新"
@@ -261,32 +244,6 @@ DesignDocの場合、追加で以下を確認:
 }
 ```
 
-## レビューチェックリスト（総合モード用）
-
-- [ ] ドキュメント間の要件・用語・数値の一致
-- [ ] 各ドキュメントの必須要素の完備
-- [ ] プロジェクトルールへの準拠
-- [ ] 技術的実現可能性と見積もりの妥当性
-- [ ] リスクと対策の明確化
-- [ ] 既存システムとの整合性
-- [ ] 承認条件の充足
-- [ ] 技術的主張の出典確認と最新情報との整合性
-- [ ] 失敗シナリオの網羅性
-- [ ] 複雑性の正当化: complexity_levelがmedium/highの場合、complexity_rationaleは(1)その複雑性を必要とする要件/AC、(2)対処する制約/リスクを明記すること
-- [ ] Gate 0の存在チェックが品質レビュー前に通過していること
-- [ ] 設計判断の根拠が特定された基準/パターンに照合されていること
-- [ ] コード調査エビデンスが設計スコープに関連するファイルを網羅していること
-- [ ] 「既存」と記述された依存先がコードベースに対して検証されていること（Grep/Glob）
-- [ ] フィールドが境界を越える場合にフィールド伝播マップが存在すること
-- [ ] データ関連キーワードが存在する場合 → データ設計コンテンツが存在（スキーマ参照、テスト境界、データモデル文書。または明示的にN/A）
-- [ ] コード検証結果（提供された場合）がドキュメント内容と照合済み
-- [ ] 検証戦略に具体的な正しさの定義と早期検証ポイントが存在すること
-- [ ] 検証戦略がdesign_typeと実装アプローチに整合していること
-- [ ] 既存の振る舞いを置換/変更する設計で出力比較が定義されていること（全変換パイプラインステップをカバー）
-- [ ] Fact Disposition Tableが`codebase_analysis.focusAreas`の全エントリをカバーし、`fact_id`/`evidence`が一字一句引き継がれ、Rationale-disposition意味整合がとれている（`codebase_analysis`が提供された場合）
-- [ ] 前レイヤー契約に依存する未解決主張がある場合、Cross-Layer Assumptionsセクションが存在する
-- [ ] Minimal Surface Alternatives セクションが新規の適用対象要素ごとに5ステップの結果をカバーし、ステップ4 の根拠が最小代替案の選定か、より小さい代替案では満たせない現要件の名指しになっている（適用対象要素を導入する場合）
-
 ## レビュー基準（総合モード用）
 
 ### 承認（Approved）
@@ -348,21 +305,9 @@ DesignDocの場合、追加で以下を確認:
    - `[技術名] deprecation`、`[技術名] security vulnerability`
    - 公式リポジトリのrelease notes確認
 
-## 重要な注意事項
-
-### ADRステータス更新について
-**重要**: このエージェントはレビューと推奨判定のみを行います。実際のステータス更新はユーザーの最終判断後に行われます。
-
-**レビュー結果の提示**:
-- 「Approved（承認推奨）」「Rejected（却下推奨）」等の判定を提示
+### ADRステータスのスコープ
 
-**verdict別ADRステータス推奨**:
-| verdict | 推奨ステータス |
-|---------|---------------|
-| Approved | Proposed → Accepted |
-| Approved with Conditions | Accepted（条件充足後） |
-| Needs Revision | Proposedのまま維持 |
-| Rejected | Rejected（却下理由を明記） |
+ADRについては、verdictは助言的なものに過ぎない。ステータス変更は呼び出し側またはユーザーが判断する。
 
 ### 出力フォーマットの厳守
 

package/.claude/agents-ja/integration-test-reviewer.md

@@ -63,6 +63,7 @@ skills: integration-e2e-testing, typescript-testing, project-context
 | 独立性 | テストごとに状態を分離（beforeEachでリセット） | テスト間で共有状態を変更 |
 | 再現性 | 決定論的な実行（必要に応じて時間/乱数をモック） | 非決定的要素あり |
 | 可読性 | テスト名と検証内容の一致 | 名前と内容が乖離 |
+| 実体的なアサーション | 実行されたアサーションのうち少なくとも1つが、AC の観測可能な振る舞いを検証する。意図的な不在を検証するアサーション（例: `toHaveLength(0)`、`toBeNull()`）は、AC が不在を期待する場合に該当する | TODO のみの本体、実行されるべきテストへの `skip`/`xit` 残置、常真のアサーション（例: `expect(true).toBe(true)`、`expect(arr.length).toBeGreaterThanOrEqual(0)`） |
 
 ### 4. モック境界チェック（統合テストのみ）
 
@@ -197,6 +198,11 @@ needs_revision判定時、後続処理で使用できる修正指示を出力:
 - 全コンポーネント実装完了後に実行されているか確認
 - クリティカルユーザージャーニーの網羅性を検証
 
+### 空虚またはプレースホルダーのアサーション
+
+**問題**: テストはパスしているように見えるが、AC の観測可能な振る舞いを検証していない — 常真のアサーション、TODO のみの本体、実行されるべきテストへの `skip`/`xit` 残置のいずれか。
+**修正**: AC の観測可能な振る舞いを検証するアサーションへ置き換える。実行すべきテストの場合は `skip`/`xit` を外す。AC の期待が真に不在である場合は、明示的な不在アサーション（`queryAllBy*`+`toHaveLength(0)`、`toBeNull()`）を使う。
+
 ## 完了条件
 
 - [ ] すべてのスケルトンコメントを実装と照合

package/.claude/agents-ja/quality-fixer-frontend.md

@@ -25,7 +25,8 @@ skills: frontend-typescript-rules, frontend-typescript-testing, frontend-technic
 ## 入力パラメータ
 
 - **task_file**（任意）: 検証対象のタスクファイルへのパス。指定された場合、「品質保証メカニズム」セクションを読み込み、品質チェック検出の補助ヒントとして使用する。これはあくまでヒントであり、コード・マニフェスト・設定ベースの一次検出が優先。
-- **filesModified**（任意）: 上流の実装ステップが現在のタスクで変更したファイルパスのリスト（オーケストレータから提供される）。ステップ1の未完成実装チェックの主要スコープとして使用する。未指定時は `git diff HEAD` にフォールバックする。
+- **filesModified**（任意）: 上流の実装ステップが現在のタスクで変更したファイルパスのリスト。ステップ1の未完成実装チェックの主要スコープとして使用する。未指定時は `git diff HEAD` にフォールバックする。
+- **runnableCheck**（任意）: 上流の実装ステップから受け取るテスト実行のエビデンス。指定された場合、ステップ3の Substance チェックの一次入力として使う。スキーマ: `{ level, executed, command, result: 'passed'|'failed'|'skipped', substance: 'substantive'|'non_substantive'|null, substanceIssue: string|null, reason }`。未指定時は、スコープ内のテスト本体を自分で走査して実体性を判定する。
 
 ## 初回必須タスク
 
@@ -82,6 +83,14 @@ frontend-technical-specスキルの「品質チェック要件」セクション
 - 基本チェック（lint, format, build）
 - テスト（unit, integration, React Testing Library）
 - 最終ゲート（全てパス必須）
+- Substance チェック（テストエビデンスがある場合のみ）:
+  - 適用対象: タスクファイルに記載された AC のエビデンスとしてテスト実行が引用されている場合
+  - 入力: 入力パラメータ `runnableCheck` が渡された場合は `substance` と `substanceIssue` フィールドを一次シグナルとして使う。未指定時はスコープ内のテスト本体を自分で走査する
+  - 実体的と判定する条件: 実行されたアサーションのうち少なくとも1つが、AC の観測可能な振る舞いを検証している。意図的な不在を検証するアサーション（例: `expect(screen.queryAllByRole(...)).toHaveLength(0)`、`expect(value).toBeNull()`）は AC が不在を期待する場合に該当する
+  - 非実体的な例: テストランナーが0件マッチと報告、実行されるべきパスでのテストスキップ、TODO のみの本体、振る舞いに関係なく常に成功するアサーション（例: `expect(true).toBe(true)`、`expect(arr.length).toBeGreaterThanOrEqual(0)`）
+  - 修正範囲内での対処手段: `skip`/`only` マーカーの除去、テストセレクタの拡張、関連テストファイルの追加実行
+  - 修正範囲内で実体性を達成できない場合: 該当する hollow テストファイルを `incompleteImplementations[]` に載せて `stub_detected` を返却する。各エントリは `type: "hollow_test"` を持ち、`description` には AC 参照と実体性の問題を記載する（出力フォーマット参照）
+  - 対象範囲: lint、format、build、typecheck の実行はこのルールの対象外
 
 ### ステップ4: エラーの修正
 frontend-typescript-rulesおよびfrontend-typescript-testingスキルに従って修正を適用。
@@ -95,7 +104,7 @@ frontend-typescript-rulesおよびfrontend-typescript-testingスキルに従っ
 ### ステップ6: JSON結果の返却
 最終レスポンスとして以下のいずれかを返却する（スキーマは出力フォーマットを参照）:
 - `status: "approved"` — すべての品質チェックがパス
-- `status: "stub_detected"` — 未完成実装を検出（ステップ1）
+- `status: "stub_detected"` — ステップ1で未完成実装を検出（`type: "missing_logic"`）、またはステップ3 Substance チェックで修正範囲内で回復不能な hollow テストを検出（`type: "hollow_test"`）
 - `status: "blocked"` — 仕様が不明確、ビジネス判断が必要
 
 ### Phase 詳細
@@ -125,13 +134,14 @@ package.json からフロントエンドビルドコマンドを自動検出し
 
 **よくある修正**:
 - React Testing Library テスト失敗:
-  - 意図的な変更の場合はコンポーネントスナップショットを更新
-  - カスタムフックのモック実装を修正
-  - APIモック用のMSWハンドラを更新
-  - 各テスト後に `cleanup()` で適切にクリーンアップ
+  - 変更された AC を反映するようコンポーネントまたはアサーションを修正。スナップショット再生成より振る舞いアサーションを優先（RTL は `afterEach(cleanup)` を自動実行する。手動の `cleanup()` 呼び出しは追加せず、自動クリーンアップに任せる）
+  - カスタムフックのモック設定を修正
+  - 変更されたコントラクトに合わせて、リポジトリ既存のネットワーク/API モック層（例: MSWハンドラ）を更新
+  - テスト環境が要求する場合は、ブラウザプリミティブのテストダブル（ResizeObserver、IntersectionObserver、時間、ルーター/プロバイダ）を追加
 - テストカバレッジ不足:
-  - 新規コンポーネントにテスト追加（60%カバレッジ目標）
-  - 実装詳細ではなく、ユーザーが観察可能な振る舞いをテスト
+  - ユーザー可視要素には role/name クエリを優先。非同期な出現には `findBy*`/`waitFor`、意図的な不在の検証には `queryBy*`/`queryAllBy*` を使う
+  - 内部状態の検査ではなく、実レンダリングとユーザー操作を通じて観測可能な振る舞いを検証する
+  - カバレッジ目標は frontend-typescript-testing スキルに従う（60% を基準、基礎/葉コンポーネントは 70%、molecules 65%、organisms 60%）
 
 #### Phase 4: 最終確認
 - 全Phaseの結果を確認
@@ -140,11 +150,16 @@ package.json からフロントエンドビルドコマンドを自動検出し
 
 ## ステータス判定基準
 
-### stub_detected（未完成実装を検出 — ステップ1ゲート）
-ステップ1でdiff内に未完成実装が検出された場合に即座に返却される。品質チェックは実行されない。実装を完了させる責務は呼び出し元にある。
+### stub_detected（未完成実装または hollow テストを検出）
+2つの経路から返却される。`incompleteImplementations[].type` で区別する:
+- `type: "missing_logic"` — ステップ1で diff 内に未完成実装を検出（TODO・プレースホルダー本体、ハードコードされた戻り値など）。即座に返却され、品質チェックは実行されない。
+- `type: "hollow_test"` — ステップ3 Substance チェックで、AC のエビデンスとして引用されたテストの本体に実体的なアサーションが欠落しており、修正範囲内では回復できなかった場合。ここまでの品質チェックは既に実行済み。
+
+いずれの場合も、実装（またはテスト本体）の完了は呼び出し元の責務。修正後に本エージェントを再実行して検証する。
 
 ### approved（全品質チェックがパス）
 - 全テストが通過（React Testing Library）
+- タスクファイルに記載された AC のエビデンスとしてテスト実行が引用されている場合、実行されたアサーションのうち少なくとも1つが、その AC の観測可能な振る舞いを検証する（意図的な不在を検証するアサーションは AC が不在を期待する場合に該当）。テストエビデンスが引用されないタスク（純粋なリファクタ（振る舞い変更なし）など）はこの基準の対象外
 - ビルド成功
 - 型チェック成功
 - Lint/Format成功（Biome）
@@ -195,20 +210,26 @@ package.json からフロントエンドビルドコマンドを自動検出し
 | status | 必須フィールド | 使用条件 |
 |---|---|---|
 | `approved` | `summary`, `checksPerformed: {phase1_biome, phase2_typescript, phase3_tests, phase4_final}`（各 `{status, commands[], …}`; `phase3_tests` は `testsRun`, `testsPassed`, `coverage` を含めてよい）, `fixesApplied[{type: auto\|manual, category, description, filesCount}]`, `metrics: {totalErrors, totalWarnings, executionTime}`, `nextActions` | 全Phase（1-4）がエラー0で完了 |
-| `stub_detected` | `reason`, `incompleteImplementations[{file_path, location, description}]` | ステップ1でスコープ内にstub/TODO/プレースホルダーを検出（品質チェック前に即座に返却） |
+| `stub_detected` | `reason`, `incompleteImplementations[{file_path, location, description, type: "missing_logic" \| "hollow_test"}]` | ステップ1でスコープ内に stub/TODO/プレースホルダーを検出（`type: "missing_logic"`、品質チェック前に即座に返却）、またはステップ3 Substance チェックで修正範囲内で回復不能な hollow テストを検出（`type: "hollow_test"`） |
 | `blocked`（specification_conflict） | `reason: "Cannot determine due to unclear specification"`, `blockingIssues[{type: "ux_specification_conflict" \| "specification_conflict", details, test_expects, implementation_behavior, why_cannot_judge}]`, `attemptedFixes[]`, `needsUserDecision` | 以下の3条件が全て成立: 妥当な修正方法が複数存在; UX/仕様判断が必要; 全確認手段を試行済み |
 | `blocked`（missing_prerequisites） | `reason: "Execution prerequisites not met"`, `missingPrerequisites[{type: seed_data\|library\|environment_variable\|running_service\|other, description, affectedTests[], resolutionSteps[]}]`, `testsSkipped`, `testsPassedWithoutPrerequisites` | 本エージェントのスコープ外の環境不足によりテスト実行不可 |
 
 最小例（`stub_detected`; 簡潔のため `taskFileMechanisms` は省略 — `task_file` 提供時は必ず含める）:
 
 ```json
-{
-  "status": "stub_detected",
-  "reason": "Incomplete implementation detected in changed files",
-  "incompleteImplementations": [
-    {"file_path": "src/components/Order/Total.tsx", "location": "calculateTotal", "description": "Returns hardcoded 0; should compute total from items"}
-  ]
-}
+{ "status": "stub_detected", "reason": "Incomplete implementation detected in changed files", "incompleteImplementations": [{ "file_path": "src/components/Order/Total.tsx", "location": "calculateTotal", "description": "Returns hardcoded 0; should compute total from items", "type": "missing_logic" }] }
+```
+
+最小例（`blocked` — Variant A、UX/仕様矛盾）:
+
+```json
+{ "status": "blocked", "reason": "Cannot determine due to unclear specification", "blockingIssues": [{ "type": "ux_specification_conflict", "details": "Test expectation and implementation contradict on user interaction behavior", "test_expects": "Button disabled on form error", "implementation_behavior": "Button enabled, shows error on click", "why_cannot_judge": "Correct UX specification unknown" }], "attemptedFixes": ["Tried aligning test to implementation", "Tried aligning implementation to test", "Tried inferring specification from Design Doc"], "needsUserDecision": "Confirm the correct button-disabled behavior" }
+```
+
+最小例（`blocked` — Variant B、前提条件の不足）:
+
+```json
+{ "status": "blocked", "reason": "Execution prerequisites not met", "missingPrerequisites": [{ "type": "seed_data", "description": "E2E test environment has no test player with active subscription", "affectedTests": ["training.e2e.test.ts"], "resolutionSteps": ["Create seed script for the E2E test player", "Add subscription record to the seed"] }], "testsSkipped": 3, "testsPassedWithoutPrerequisites": 47, "needsUserDecision": "Confirm whether seed setup is in scope for this task" }
 ```
 
 **処理ルール**（内部）:
@@ -241,16 +262,16 @@ package.json からフロントエンドビルドコマンドを自動検出し
 
 - [ ] 最終レスポンスが `approved`、`stub_detected`、または `blocked` ステータスの単一JSON
 
-## 重要原則
+## 修正実行ポリシー
 
-**原則**: 高品質なReactコードを維持するため、以下に従う:
-- **ゼロエラー原則**: 全てのエラーと警告を解決
-- **型システム規約**: React Props/State の TypeScript 型安全性原則に従う
-- **テスト修正基準**: 既存のReact Testing Libraryテストの意図を理解し適切に修正
+**参照すべきポリシー**（修正前に以下のスキルを参照する）:
+- ゼロエラーとコード品質: coding-standards スキル
+- React/TS の型安全性（Props/State、型ガード等）: frontend-typescript-rules スキル
+- テスト修正判断、RTL/MSW 規約、実体性基準: frontend-typescript-testing スキル
 
-### 修正実行ポリシー
+**停止条件**: 全フェーズがパス、または blocked 条件のいずれかに該当した時点で停止する。
 
-#### 自動修正範囲
+### 自動修正範囲
 - **フォーマット・スタイル**: `check:fix` スクリプトでBiome自動修正
   - インデント、セミコロン、クォート
   - import文の並び順
@@ -266,7 +287,7 @@ package.json からフロントエンドビルドコマンドを自動検出し
   - 到達不可能コードの削除
   - console.log文の削除
 
-#### 手動修正範囲
+### 手動修正範囲
 - **React Testing Libraryテスト修正**: プロジェクトテストルールの判断基準に従う
   - 実装が正しくテストが古い場合: テストを修正
   - 実装にバグがある場合: Reactコンポーネントを修正
@@ -291,11 +312,6 @@ package.json からフロントエンドビルドコマンドを自動検出し
   - 必要な Props 型定義を追加
   - ジェネリクスやユニオン型で柔軟に対応
 
-#### 修正継続の判定条件
-- **継続**: いずれかのフェーズでエラー・警告・失敗が存在
-- **完了**: 全フェーズがパス
-- **停止**: blocked の3条件のいずれかに該当する場合のみ
-
 ## アンチパターン（問題を隠蔽してはならない）
 
 | 失敗 | 必要なアクション | 禁止される近道 |

package/.claude/agents-ja/quality-fixer.md

@@ -26,7 +26,8 @@ skills: typescript-rules, typescript-testing, technical-spec, coding-standards,
 ## 入力パラメータ
 
 - **task_file**（任意）: 検証対象のタスクファイルへのパス。指定された場合、「品質保証メカニズム」セクションを読み込み、品質チェック検出の補助ヒントとして使用する。これはあくまでヒントであり、コード・マニフェスト・設定ベースの一次検出が優先。
-- **filesModified**（任意）: 上流の実装ステップが現在のタスクで変更したファイルパスのリスト（オーケストレータから提供される）。ステップ1の未完成実装チェックの主要スコープとして使用する。未指定時は `git diff HEAD` にフォールバックする。
+- **filesModified**（任意）: 上流の実装ステップが現在のタスクで変更したファイルパスのリスト。ステップ1の未完成実装チェックの主要スコープとして使用する。未指定時は `git diff HEAD` にフォールバックする。
+- **runnableCheck**（任意）: 上流の実装ステップから受け取るテスト実行のエビデンス。指定された場合、ステップ3の Substance チェックの一次入力として使う。スキーマ: `{ level, executed, command, result: 'passed'|'failed'|'skipped', substance: 'substantive'|'non_substantive'|null, substanceIssue: string|null, reason }`。未指定時は、スコープ内のテスト本体を自分で走査して実体性を判定する。
 
 ## 初回必須タスク
 
@@ -83,6 +84,14 @@ technical-specスキルの「品質チェック要件」セクションに従う
 - 基本チェック（lint, format, build）
 - テスト（unit, integration）
 - 最終ゲート（全てパス必須）
+- Substance チェック（テストエビデンスがある場合のみ）:
+  - 適用対象: タスクファイルに記載された AC のエビデンスとしてテスト実行が引用されている場合
+  - 入力: 入力パラメータ `runnableCheck` が渡された場合は `substance` と `substanceIssue` フィールドを一次シグナルとして使う。未指定時はスコープ内のテスト本体を自分で走査する
+  - 実体的と判定する条件: 実行されたアサーションのうち少なくとも1つが、AC の観測可能な振る舞いを検証している。意図的な不在を検証するアサーション（例: 空の結果、null 戻り値）は AC が不在を期待する場合に該当する
+  - 非実体的な例: テストランナーが0件マッチと報告、実行されるべきパスでのテストスキップ、TODO のみの本体、振る舞いに関係なく常に成功するアサーション（例: `expect(true).toBe(true)`、`expect(arr.length).toBeGreaterThanOrEqual(0)`）
+  - 修正範囲内での対処手段: `skip`/`only` マーカーの除去、テストセレクタの拡張、関連テストファイルの追加実行
+  - 修正範囲内で実体性を達成できない場合: 該当する hollow テストファイルを `incompleteImplementations[]` に載せて `stub_detected` を返却する。各エントリは `type: "hollow_test"` を持ち、`description` には AC 参照と実体性の問題を記載する（出力フォーマット参照）
+  - 対象範囲: lint、format、build、typecheck の実行はこのルールの対象外
 
 ### ステップ4: エラーの修正
 coding-standardsおよびtypescript-testingスキルに従って修正を適用。
@@ -96,7 +105,7 @@ coding-standardsおよびtypescript-testingスキルに従って修正を適用
 ### ステップ6: JSON結果の返却
 最終レスポンスとして以下のいずれかを返却する（スキーマは出力フォーマットを参照）:
 - `status: "approved"` — すべての品質チェックがパス
-- `status: "stub_detected"` — 未完成実装を検出（ステップ1）
+- `status: "stub_detected"` — ステップ1で未完成実装を検出（`type: "missing_logic"`）、またはステップ3 Substance チェックで修正範囲内で回復不能な hollow テストを検出（`type: "hollow_test"`）
 - `status: "blocked"` — 仕様が不明確、ビジネス判断が必要
 
 ### Phase 詳細
@@ -105,11 +114,16 @@ coding-standardsおよびtypescript-testingスキルに従って修正を適用
 
 ## ステータス判定基準
 
-### stub_detected（未完成実装を検出 — ステップ1ゲート）
-ステップ1でdiff内に未完成実装が検出された場合に即座に返却される。品質チェックは実行されない。実装を完了させる責務は呼び出し元にある。
+### stub_detected（未完成実装または hollow テストを検出）
+2つの経路から返却される。`incompleteImplementations[].type` で区別する:
+- `type: "missing_logic"` — ステップ1で diff 内に未完成実装を検出（TODO・プレースホルダー本体、ハードコードされた戻り値など）。即座に返却され、品質チェックは実行されない。
+- `type: "hollow_test"` — ステップ3 Substance チェックで、AC のエビデンスとして引用されたテストの本体に実体的なアサーションが欠落しており、修正範囲内では回復できなかった場合。ここまでの品質チェックは既に実行済み。
+
+いずれの場合も、実装（またはテスト本体）の完了は呼び出し元の責務。修正後に本エージェントを再実行して検証する。
 
 ### approved（全品質チェックがパス）
 - 全テストが通過
+- タスクファイルに記載された AC のエビデンスとしてテスト実行が引用されている場合、実行されたアサーションのうち少なくとも1つが、その AC の観測可能な振る舞いを検証する（意図的な不在を検証するアサーションは AC が不在を期待する場合に該当）。テストエビデンスが引用されないタスク（純粋なリファクタ（振る舞い変更なし）など）はこの基準の対象外
 - ビルド成功
 - 型チェック成功
 - Lint/Format成功
@@ -160,20 +174,26 @@ coding-standardsおよびtypescript-testingスキルに従って修正を適用
 | status | 必須フィールド | 使用条件 |
 |---|---|---|
 | `approved` | `summary`, `checksPerformed: {phase1_biome, phase2_structure, phase3_typescript, phase4_tests, phase5_code_recheck}`（各 `{status, commands[], …}`）, `fixesApplied[{type: auto\|manual, category, description, filesCount}]`, `metrics: {totalErrors, totalWarnings, executionTime}`, `nextActions` | 全Phase（1-5）がエラー0で完了 |
-| `stub_detected` | `reason`, `incompleteImplementations[{file_path, location, description}]` | ステップ1でスコープ内にstub/TODO/プレースホルダーを検出（品質チェック前に即座に返却） |
+| `stub_detected` | `reason`, `incompleteImplementations[{file_path, location, description, type: "missing_logic" \| "hollow_test"}]` | ステップ1でスコープ内に stub/TODO/プレースホルダーを検出（`type: "missing_logic"`、品質チェック前に即座に返却）、またはステップ3 Substance チェックで修正範囲内で回復不能な hollow テストを検出（`type: "hollow_test"`） |
 | `blocked`（specification_conflict） | `reason: "Cannot determine due to unclear specification"`, `blockingIssues[{type: "specification_conflict", details, test_expects, implementation_returns, why_cannot_judge}]`, `attemptedFixes[]`, `needsUserDecision` | 以下の3条件が全て成立: 妥当な修正方法が複数存在; 仕様判断が必要; 全確認手段を試行済み |
 | `blocked`（missing_prerequisites） | `reason: "Execution prerequisites not met"`, `missingPrerequisites[{type: seed_data\|library\|environment_variable\|running_service\|other, description, affectedTests[], resolutionSteps[]}]`, `testsSkipped`, `testsPassedWithoutPrerequisites` | 本エージェントのスコープ外の環境不足によりテスト実行不可 |
 
 最小例（`stub_detected`; 簡潔のため `taskFileMechanisms` は省略 — `task_file` 提供時は必ず含める）:
 
 ```json
-{
-  "status": "stub_detected",
-  "reason": "Incomplete implementation detected in changed files",
-  "incompleteImplementations": [
-    {"file_path": "src/svc/order.ts", "location": "calculateTotal", "description": "Returns hardcoded 0; should compute total from items"}
-  ]
-}
+{ "status": "stub_detected", "reason": "Incomplete implementation detected in changed files", "incompleteImplementations": [{ "file_path": "src/svc/order.ts", "location": "calculateTotal", "description": "Returns hardcoded 0; should compute total from items", "type": "missing_logic" }] }
+```
+
+最小例（`blocked` — Variant A、仕様矛盾）:
+
+```json
+{ "status": "blocked", "reason": "Cannot determine due to unclear specification", "blockingIssues": [{ "type": "specification_conflict", "details": "Test expectation and implementation contradict", "test_expects": "500 error", "implementation_returns": "400 error", "why_cannot_judge": "Correct specification unknown" }], "attemptedFixes": ["Tried aligning test to implementation", "Tried aligning implementation to test", "Tried inferring specification from related documentation"], "needsUserDecision": "Confirm the correct error code" }
+```
+
+最小例（`blocked` — Variant B、前提条件の不足）:
+
+```json
+{ "status": "blocked", "reason": "Execution prerequisites not met", "missingPrerequisites": [{ "type": "seed_data", "description": "Integration test database has no seed records for the new flow", "affectedTests": ["order-flow.int.test.ts"], "resolutionSteps": ["Create seed script for the test database", "Add the missing records to the seed"] }], "testsSkipped": 3, "testsPassedWithoutPrerequisites": 47, "needsUserDecision": "Confirm whether seed setup is in scope for this task" }
 ```
 
 **処理ルール**（内部）:
@@ -206,16 +226,16 @@ coding-standardsおよびtypescript-testingスキルに従って修正を適用
 
 - [ ] 最終レスポンスが `approved`、`stub_detected`、または `blocked` ステータスの単一JSON
 
-## 重要原則
+## 修正実行ポリシー
 
-**原則**: 高品質なコードを維持するため、以下に従う:
-- **ゼロエラー原則**: coding-standards スキル参照
-- **型システム規約**: typescript-rules スキル参照（特にany型の代替手段）
-- **テスト修正基準**: typescript-testing スキル参照
+**参照すべきポリシー**（修正前に以下のスキルを参照する）:
+- ゼロエラーとコード品質: coding-standards スキル
+- 型安全性（`any` の代替、型ガード等）: typescript-rules スキル
+- テスト修正判断と実体性基準: typescript-testing スキル
 
-### 修正実行ポリシー
+**停止条件**: 全 Phase がパス、または blocked 条件のいずれかに該当した時点で停止する。
 
-#### 自動修正範囲
+### 自動修正範囲
 - **フォーマット・スタイル**: `check:fix` スクリプトでBiome自動修正
   - インデント、セミコロン、クォート
   - import文の並び順
@@ -231,7 +251,7 @@ coding-standardsおよびtypescript-testingスキルに従って修正を適用
   - 到達不可能コードの削除
   - console.log文の削除
 
-#### 手動修正範囲
+### 手動修正範囲
 - **テスト修正**: typescript-testingスキルの判断基準に従う
   - 実装が正しくテストが古い場合: テストを修正
   - 実装にバグがある場合: 実装を修正
@@ -250,11 +270,6 @@ coding-standardsおよびtypescript-testingスキルに従って修正を適用
   - 必要な型定義を追加
   - ジェネリクスやユニオン型で柔軟に対応
 
-#### 修正継続の判定条件
-- **継続**: いずれかのPhaseでエラー・警告・失敗が存在
-- **完了**: 全Phase（1-5）がエラー0
-- **停止**: blocked の3条件のいずれかに該当する場合のみ
-
 ## アンチパターン（問題を隠蔽してはならない）
 
 | 失敗 | 必要なアクション | 禁止される近道 |

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

@@ -120,6 +120,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
    | パッケージ間境界の実装 | 作業計画書のConnection Mapに記載された境界の両側（オーナーモジュールと期待されるシグナル）、両者間のコントラクト定義 |
    | バグ修正 / リファクタリング | 影響を受けるコードパス、関連テストカバレッジ、エラー再現コンテキスト |
    | 振る舞いの置換・リライト | 置換対象の既存実装、その観察可能な出力、Design Docの検証戦略セクション |
+   | ADRに拘束されるタスク（作業計画書のADR Bindings表がこのタスクをカバーする） | このタスクをカバーする各バインディング行について、行の `Source Section` 値に対応するセクションヒント（例: `(§ Decision)` または `(§ Implementation Guidance)`）を付したADRファイル |
 
    **原則**:
    - 全タスクに最低1つの Investigation Target を設定する（Design Docのみでも可）
@@ -129,6 +130,8 @@ implementation-approachスキルで決定された実装戦略パターンに基
    - タスクにテストスケルトンが存在する場合は必ず Investigation Targets に含める
    - 作業計画書に「UI Specコンポーネント → タスクマッピング」表が含まれる場合、該当行のコンポーネントセクションをそのタスクに伝播する（後述の「UI Spec伝播」参照）
    - 作業計画書にConnection Mapが含まれる場合、このタスクの対象ファイルに関連する境界行を伝播する（後述の「Connection Map伝播」参照）
+   - 作業計画書にこのタスクをカバーするADR Bindings表が含まれる場合、該当行を伝播する（後述の「ADR Binding伝播」参照）
+   - 作業計画書に設計-計画トレーサビリティ表が含まれる場合、該当するDDセクション行を伝播する（後述の「設計トレーサビリティ伝播」参照）
 
 7. **実装方針の一貫性**
    実装サンプルを含める場合は、作業計画書の元となったDesign Docの実装方針に完全準拠すること
@@ -172,6 +175,34 @@ implementation-approachスキルで決定された実装戦略パターンに基
 3. **タスク本文に「Boundary Context」ノートを追加**: Connection Mapの行から境界識別子と期待されるシグナルをそのまま記録する。executorは、実装が生み出すべき観測可能な証拠を把握できる。
 4. **未提供の場合はスキップ**: 作業計画書にConnection Mapがない場合は、本伝播ステップをスキップする
 
+## ADR Binding伝播
+
+作業計画書にADR Bindings表が含まれる場合、各バインディング決定を、それがカバーするタスクに伝播する:
+
+1. **タスクIDで照合**: ADR Bindings表の各行について、「Covered By Task(s)」列に記載されたタスクを特定する
+2. **Investigation Targetsに追加**: 行の `Source Section` 値に対応するセクションヒント（例: `docs/adr/ADR-0042.md (§ Decision)` または `docs/adr/ADR-0042.md (§ Implementation Guidance)`）を付したADRファイルパスを、マッチした各タスクに追加する
+3. **タスクにBinding Decisions表を追加**: マッチした各行について、タスクのBinding Decisions表に1行追加する:
+   - **Source**: 行の `Source Section` 値に対応するセクションヒントを付したADRファイルパス
+   - **Axis**: 作業計画書の行から `Axis` 値を逐語コピーする
+   - **Decision**: 作業計画書の行からバインディング決定文を逐語コピーする
+   - **Compliance Check**: 実装が決定を満たすことを述べる、Y/Nで回答可能な肯定述語を書く。バインディング軸ごとの例:
+     - `placement`: 「認証エントリポイントが `src/middleware/**` にある」
+     - `dependency_direction`: 「ドメイン層は `src/domain/**` と `src/shared/**` からのみインポートする」
+     - `contract_schema`: 「APIレスポンスが `ResponseEnvelope<T>` スキーマに一致する」
+     - `data_flow`: 「セッショントークンはRedisクライアント経由でのみ書き込まれる」
+     - `persistence`: 「ユーザーレコードは `UsersRepository` インターフェース経由でのみ永続化される」
+
+     決定がfile:lineやコマンドだけでは検証できない場合、述語は論理的判断に依拠してよいが、Y/Nで回答可能でなければならない
+4. **提供時のみ適用**: この伝播は作業計画書にADR Bindings表が含まれる場合のみ実行する
+
+## 設計トレーサビリティ伝播
+
+作業計画書に設計-計画トレーサビリティ表が含まれる場合、該当するDDセクションを各タスクに伝播する:
+
+1. 各行について、`[Design Doc値] (§ [DDセクション値])` の形式で、(`Design Doc`, `DD Section`) のペアを「カバーするタスク」に記載された全タスクのInvestigation Targetとして追加する
+2. 同一タスクで複数行に同じ (Design Doc, DD Section) ペアが現れる場合は重複排除する
+3. 作業計画書に設計-計画トレーサビリティ表が含まれる場合のみ適用する
+
 ## 品質保証メカニズムの伝播
 
 作業計画書ヘッダーに Quality Assurance Mechanisms テーブルが含まれる場合、以下のルールで各タスクに伝播する: