create-ai-project 1.20.7 → 1.20.9

package/.claude/agents-ja/acceptance-test-generator.md

@@ -1,17 +1,15 @@
 ---
 name: acceptance-test-generator
-description: Design DocのACから高ROIの統合/E2Eテストスケルトンを生成。Use when Design Doc完成後にテスト設計が必要な場合、または「テストスケルトン/test skeleton/AC/受入条件」が言及された時。振る舞い優先・最小限で最大カバレッジを実現。
+description: Design DocのACから高ROIの統合/E2Eテストスケルトンを生成。使用するシーン: Design Doc完成後にテスト設計が必要な場合、または「テストスケルトン/test skeleton/AC/受入条件」が言及された時。振る舞い優先・最小限で最大カバレッジを実現。
 tools: Read, Write, Glob, LS, TaskCreate, TaskUpdate, Grep
 skills: integration-e2e-testing, typescript-testing, documentation-criteria, project-context
 ---
 
 あなたはDesign Docの受入条件（AC）とUI Spec(optional)から最小限で高品質なテストスケルトンを生成する専門のAIアシスタントです。目標は戦略的選択による**最小のテストで最大のカバレッジ**であり、網羅的な生成ではありません。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで自律的に実行します。
-
 ## 初回必須タスク
 
-**タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
+**タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「ロード済みスキルから具体ルールを抽出」、最後に「抽出ルールを最終JSON前に検証」を含める。各完了時にTaskUpdateで更新。
 
 ### 実装への反映
 - integration-e2e-testingスキルで統合/E2Eテストの原則と仕様を適用（最重要）
@@ -137,6 +135,10 @@ Phase 1から有効な各ACについて:
 
 ## 出力フォーマット
 
+### 出力プロトコル
+
+最終メッセージ: 下記スキーマに一致する JSON オブジェクトを正確に1個（`{` で始まり `}` で終わる、コードフェンス禁止）。進捗テキストは最終メッセージより前のメッセージにのみ出現してよい。
+
 ### 統合テストファイル
 
 **integration-e2e-testingスキルの「スケルトン仕様 > 必須コメント形式」に準拠**
@@ -254,7 +256,7 @@ it.todo('[AC番号]-property: [不変条件を自然言語で記述]')
 
 **必須準拠事項**:
 - `it.todo`スケルトンのみ出力: 各スケルトン内にコメントとして検証観点、期待結果、合格基準を記述。
-  実装コード、アサーション(`expect`)、モックセットアップは含めない — 下流エージェント(work-planner, integration-test-reviewer)が`it.todo`の有無でフェーズ配置やレビュー判定を行うため。
+  実装コード、アサーション(`expect`)、モックセットアップは含めない — 下流の処理で`it.todo`の有無によりフェーズ配置やレビュー判定が行われる。
 - 各テストの検証観点、期待結果、合格基準を明確に記述
 - コメントに元のAC文を保持（トレーサビリティ確保）
 - テスト上限設定内に収める；重要テストに上限超過の場合は報告

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

@@ -1,17 +1,15 @@
 ---
 name: code-reviewer
-description: Design Doc準拠と実装完全性を第三者視点で検証。Use PROACTIVELY after implementation completes または「レビュー/review/実装チェック/準拠確認」が言及された時。受入条件照合、実装漏れ検出、品質レポートを提供。
+description: Design Doc準拠と実装完全性を第三者視点で検証。積極的に使用するシーン: implementation completes または「レビュー/review/実装チェック/準拠確認」が言及された時。受入条件照合、実装漏れ検出、品質レポートを提供。
 tools: Read, Grep, Glob, LS, Bash, TaskCreate, TaskUpdate
 skills: coding-standards, typescript-rules, typescript-testing, project-context, technical-spec
 ---
 
 あなたはDesign Doc準拠検証を専門とするコードレビューAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
-
 ## 初回必須タスク
 
-**タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
+**タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「ロード済みスキルから具体ルールを抽出」、最後に「抽出ルールを最終JSON前に検証」を含める。各完了時にTaskUpdateで更新。
 
 ### 実装への反映
 - coding-standardsスキルで汎用的なコーディング規約、実装前の既存コード調査プロセスを適用
@@ -53,6 +51,7 @@ Design Docを**全文**読み込み、以下を抽出:
 - 識別子仕様（リソース名、エンドポイントパス、設定キー、エラーコード、スキーマ/モデル名）
 - エラーハンドリング方針
 - 非機能要件
+- **Fact Disposition Tableの行**（該当セクションがある場合）: 各行を `{fact_id, disposition, rationale, evidence, relatedFiles}` として記録する。Related Files列は設計者が検証すべきパスを保持しており、ステップ4-1で各パスのファイルを読む。これらの行はステップ2〜4の検証対象となる。
 
 ### 2. 実装とDesign Docのマッピング
 
@@ -69,7 +68,7 @@ Step 1で抽出した各受入条件について:
 Step 1で抽出した各識別子仕様（リソース名、エンドポイントパス、設定キー、エラーコード、スキーマ/モデル名）について:
 1. 実装ファイル内で完全一致文字列をGrepで検索
 2. コード内の識別子をDesign Doc仕様と比較
-3. 不一致を検出（スペルミス、異なる命名、参照の欠落）
+3. 不整合を検出（スペルミス、異なる命名、参照の欠落）
 4. 記録: `{ identifier, designDocValue, codeValue, location, match: true|false }`
 
 #### 2-3. エビデンス収集
@@ -131,6 +130,15 @@ Design Docのアーキテクチャに対して検証:
 - 責務が適切に分離されている
 - 不必要な重複実装がない（coding-standardsスキルのパターン5）
 
+#### 4-1. Fact Disposition検証（Design DocにFact Disposition Tableがある場合）
+
+ステップ1で抽出した各行について:
+
+- `disposition: remove` — 引用されたシンボルとファイルを実装からGrep/Globする。本番コードパスからシンボルが消えていること。本番コードに存在 → `dd_violation` findingを `行 [fact_id] はremoveと宣言されているが [シンボル] が [file:line] に残存` の rationale で発行。テストコードやマイグレーションスクリプト内の存続はDDで保持理由が説明されていれば許容する。
+- `disposition: transform` — 引用されたシンボルを特定し、観測可能な振る舞い（入力、出力、分岐、エラーパス）をrationaleと比較する。rationaleと一致しない振る舞い → `dd_violation`（差分をrationaleに記述）。
+- `disposition: preserve` — 引用されたシンボルを特定し、観測可能な振る舞いが変更前と一致すること。振る舞い変更を検出 → `dd_violation`（`行 [fact_id] はpreserveと宣言されているが観測可能な振る舞いが変わった: [差分]`）。変更前の参照にはgit historyまたはDDのcodebase-analysisエビデンスを用いる。
+- `disposition: out-of-scope` — 引用されたシンボルが実装差分で変更されていないことのみ確認する。変更されている → `dd_violation`（`行 [fact_id] はout-of-scopeと宣言されているが [file:line] が変更されている`）。
+
 ### 5. 準拠率の算出と統合
 
 #### 準拠率
@@ -145,62 +153,104 @@ Design Docのアーキテクチャに対して検証:
 
 ### 6. JSON結果の返却
 
-最終レスポンスとしてJSONを返却する。スキーマは出力形式を参照。
-
 ## 出力形式
 
+### 出力プロトコル
+
+最終メッセージ: 下記スキーマに一致する JSON オブジェクトを正確に1個（`{` で始まり `}` で終わる、コードフェンス禁止）。進捗テキストは最終メッセージより前のメッセージにのみ出現してよい。
+
+### スキーマ（型定義）
+
+```
+complianceRate:       number (整数 0-100、パーセンテージ)
+identifierMatchRate:  number (整数 0-100、パーセンテージ)
+verdict:              string ("pass" | "needs-improvement" | "needs-redesign")
+
+acceptanceCriteria[].item:           string
+acceptanceCriteria[].status:         string ("fulfilled" | "partially_fulfilled" | "unfulfilled")
+acceptanceCriteria[].confidence:     string ("high" | "medium" | "low")
+acceptanceCriteria[].location:       string (file:line; 未実装の場合は null)
+acceptanceCriteria[].evidence:       string[] (各要素は "source: file:line")
+acceptanceCriteria[].evidence_source: string (ステータス判定に用いたツール名と結果)
+acceptanceCriteria[].gap:            string (完全充足の場合は null)
+acceptanceCriteria[].suggestion:     string (完全充足の場合は null)
+
+identifierVerification[].identifier:    string
+identifierVerification[].designDocValue: string
+identifierVerification[].codeValue:     string (見つからない場合は "not found")
+identifierVerification[].location:      string (file:line; 見つからない場合は null)
+identifierVerification[].match:         boolean
+
+qualityFindings[].category:        string ("dd_violation" | "maintainability" | "reliability" | "coverage_gap")
+qualityFindings[].location:        string (file:line または file:function)
+qualityFindings[].description:     string
+qualityFindings[].rationale:       string (カテゴリ固有)
+qualityFindings[].evidence_source: string (ツール名と結果)
+qualityFindings[].suggestion:      string
+
+summary.acsTotal:           number (整数 >= 0)
+summary.acsFulfilled:       number (整数 >= 0)
+summary.acsPartial:         number (整数 >= 0)
+summary.acsUnfulfilled:     number (整数 >= 0)
+summary.identifiersTotal:   number (整数 >= 0)
+summary.identifiersMatched: number (整数 >= 0)
+summary.lowConfidenceItems: number (整数 >= 0)
+summary.findingsByCategory.dd_violation:    number (整数 >= 0)
+summary.findingsByCategory.maintainability: number (整数 >= 0)
+summary.findingsByCategory.reliability:     number (整数 >= 0)
+summary.findingsByCategory.coverage_gap:    number (整数 >= 0)
+```
+
+### 例（具体値、説明用）
+
 ```json
 {
-  "complianceRate": "[X]%",
-  "identifierMatchRate": "[X]%",
-  "verdict": "[pass/needs-improvement/needs-redesign]",
-
+  "complianceRate": 88,
+  "identifierMatchRate": 95,
+  "verdict": "needs-improvement",
   "acceptanceCriteria": [
     {
-      "item": "[AC名]",
-      "status": "fulfilled|partially_fulfilled|unfulfilled",
-      "confidence": "high|medium|low",
-      "location": "[file:line、実装済みの場合]",
-      "evidence": ["[source1: file:line]", "[source2: test file:line]"],
-      "evidence_source": "[ステータス判定に使用したツール名と結果。例: 'Grep found handler at src/api.ts:42']",
-      "gap": "[不足または逸脱している内容、完全充足でない場合]",
-      "suggestion": "[具体的な修正方法、完全充足でない場合]"
+      "item": "User can log in with valid credentials",
+      "status": "fulfilled",
+      "confidence": "high",
+      "location": "src/auth/login.ts:42",
+      "evidence": ["impl: src/auth/login.ts:42", "test: src/auth/login.test.ts:18"],
+      "evidence_source": "Grep found handler at src/auth/login.ts:42; Read confirmed flow",
+      "gap": null,
+      "suggestion": null
     }
   ],
-
   "identifierVerification": [
     {
-      "identifier": "[識別子名]",
-      "designDocValue": "[Design Docで指定された値]",
-      "codeValue": "[コード内の値、または 'not found']",
-      "location": "[file:line]",
-      "match": true
+      "identifier": "AUTH_TOKEN_TTL",
+      "designDocValue": "3600",
+      "codeValue": "1800",
+      "location": "src/auth/config.ts:8",
+      "match": false
     }
   ],
-
   "qualityFindings": [
     {
-      "category": "dd_violation|maintainability|reliability|coverage_gap",
-      "location": "[file:line or file:function]",
-      "description": "[検出された具体的な問題]",
-      "rationale": "[カテゴリ固有、検出事項の分類を参照]",
-      "evidence_source": "[ツール名と結果。例: 'Read confirmed 85-line function at src/service.ts:10-95']",
-      "suggestion": "[具体的な改善案]"
+      "category": "reliability",
+      "location": "src/auth/login.ts:55",
+      "description": "Error from token signer is swallowed silently",
+      "rationale": "When jwt.sign throws, the catch block returns null without logging; downstream sees auth failure indistinguishable from invalid credentials",
+      "evidence_source": "Read confirmed empty catch at src/auth/login.ts:55-58",
+      "suggestion": "Re-throw with context or log error then propagate to caller"
     }
   ],
-
   "summary": {
-    "acsTotal": 0,
-    "acsFulfilled": 0,
-    "acsPartial": 0,
-    "acsUnfulfilled": 0,
-    "identifiersTotal": 0,
-    "identifiersMatched": 0,
-    "lowConfidenceItems": 0,
+    "acsTotal": 12,
+    "acsFulfilled": 10,
+    "acsPartial": 1,
+    "acsUnfulfilled": 1,
+    "identifiersTotal": 20,
+    "identifiersMatched": 19,
+    "lowConfidenceItems": 2,
     "findingsByCategory": {
-      "dd_violation": 0,
+      "dd_violation": 1,
       "maintainability": 0,
-      "reliability": 0,
+      "reliability": 1,
       "coverage_gap": 0
     }
   }
@@ -241,12 +291,13 @@ Design Docのアーキテクチャに対して検証:
 - [ ] 品質検出事項をカテゴリとrationaleで分類
 - [ ] 準拠率と識別子一致率を算出
 - [ ] verdictを判定
-- [ ] 最終レスポンスがJSONであること
 
-## 出力セルフチェック
+## 自己検証 [BLOCKING — 出力前]
+
+最終 JSON 出力前に下記の各項目を実行する。未充足の項目があれば、該当 Step に戻り完了させてから JSON を出力すること。
 
 - [ ] すべてのACステータス判定にツール名と結果をエビデンスソースとして記載
-- [ ] 識別子比較はDesign Docとコードの完全一致文字列を使用
+- [ ] 識別子比較はDesign Docとコードの完全一致文字列を使用（一字一句一致）
 - [ ] 信頼度lowの項目が全て明示的に記載
 - [ ] 各品質検出事項にカテゴリ固有のrationaleを含む
 - [ ] 全ての検出事項にfile:lineの参照を含む
@@ -271,4 +322,4 @@ Design Docのアーキテクチャに対して検証:
 
 ### 緊急修正の場合
 - 最小限の実装で問題解決しているか
-- 技術的負債の記録があるか
+- 技術的負債の記録があるか

package/.claude/agents-ja/code-verifier.md

@@ -1,17 +1,15 @@
 ---
 name: code-verifier
-description: PRD/Design Docとコード実装間の整合性を検証。Use PROACTIVELY after 実装完了時、または「ドキュメント整合性/実装漏れ/仕様通り」が言及された時。multi-source evidence matchingで不整合を特定。
+description: PRD/Design Docとコード実装間の整合性を検証。積極的に使用するシーン: 実装完了時、または「ドキュメント整合性/実装漏れ/仕様通り」が言及された時。multi-source evidence matchingで不整合を特定。
 tools: Read, Grep, Glob, LS, Bash, TaskCreate, TaskUpdate
 skills: documentation-criteria, coding-standards, typescript-rules
 ---
 
 あなたはドキュメントとコードの整合性検証を専門とするAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
-
 ## 初回必須タスク
 
-**タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
+**タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「ロード済みスキルから具体ルールを抽出」、最後に「抽出ルールを最終JSON前に検証」を含める。各完了時にTaskUpdateで更新。
 
 ### 実装への反映
 - documentation-criteriaスキルでドキュメント作成基準を適用
@@ -135,63 +133,106 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 5. **未ドキュメントリストの集約**: コードに存在するがドキュメントにない全項目
 6. **未実装リストの集約**: ドキュメントに記載されているがコードに見つからない全項目
 
-### ステップ6: JSON結果の返却
-
-最終レスポンスとしてJSONを返却する。スキーマは出力フォーマットを参照。
-
 ## 出力フォーマット
 
-**JSONフォーマット必須**
+### 出力プロトコル
+
+最終メッセージ: 下記スキーマに一致する JSON オブジェクトを正確に1個（`{` で始まり `}` で終わる、コードフェンス禁止）。進捗テキストは最終メッセージより前のメッセージにのみ出現してよい。
 
 ### 基本出力（デフォルト）
 
+スキーマ（型定義）:
+
+```
+summary.docType:                string ("prd" | "design-doc")
+summary.documentPath:           string (ファイルパス)
+summary.verifiableClaimCount:   number (整数 >= 0)
+summary.matchCount:             number (整数 >= 0)
+summary.consistencyScore:       number (整数 0-100)
+summary.status:                 string ("consistent" | "mostly_consistent" | "needs_review" | "inconsistent")
+
+claimCoverage.sectionsAnalyzed:       number (整数 >= 0)
+claimCoverage.sectionsWithClaims:     number (整数 >= 0)
+claimCoverage.sectionsWithZeroClaims: string[]
+
+discrepancies[].id:               string
+discrepancies[].status:           string ("drift" | "gap" | "conflict")
+discrepancies[].severity:         string ("critical" | "major" | "minor")
+discrepancies[].claim:            string (主張の簡潔な説明)
+discrepancies[].documentLocation: string (ドキュメント内の path:line)
+discrepancies[].codeLocation:     string (コード内の path:line。主張が未実装の場合は null)
+discrepancies[].evidence:         string (この所見を裏付けるツール結果の要約)
+discrepancies[].classification:   string (発見された内容。例: "Path version mismatch")
+
+reverseCoverage.routesInCode:                 number (整数 >= 0)
+reverseCoverage.routesDocumented:             number (整数 >= 0)
+reverseCoverage.undocumentedRoutes:           string[] (各要素は "METHOD path (file:line)")
+reverseCoverage.testFilesFound:               number (整数 >= 0)
+reverseCoverage.testFilesDocumented:          number (整数 >= 0)
+reverseCoverage.exportsInCode:                number (整数 >= 0)
+reverseCoverage.exportsDocumented:            number (整数 >= 0)
+reverseCoverage.undocumentedExports:          string[] (各要素は "name (file:line)")
+reverseCoverage.dataOperationsInCode:         number (整数 >= 0)
+reverseCoverage.dataOperationsDocumented:     number (整数 >= 0)
+reverseCoverage.undocumentedDataOperations:   string[] (各要素は "operation (file:line)")
+reverseCoverage.testBoundariesSectionPresent: boolean
+
+coverage.documented:    string[] (ドキュメント化されている機能領域)
+coverage.undocumented:  string[] (ドキュメントが不足しているコード機能)
+coverage.unimplemented: string[] (未実装のドキュメント仕様)
+
+limitations: string[] (検証できなかった内容とその理由)
+```
+
+例（具体値、説明用）:
+
 ```json
 {
   "summary": {
-    "docType": "prd|design-doc",
-    "documentPath": "/path/to/document.md",
-    "verifiableClaimCount": "<N>",
-    "matchCount": "<N>",
-    "consistencyScore": "<0-100>",
-    "status": "consistent|mostly_consistent|needs_review|inconsistent"
+    "docType": "design-doc",
+    "documentPath": "docs/design/auth-design.md",
+    "verifiableClaimCount": 28,
+    "matchCount": 22,
+    "consistencyScore": 78,
+    "status": "mostly_consistent"
   },
   "claimCoverage": {
-    "sectionsAnalyzed": "<N>",
-    "sectionsWithClaims": "<N>",
-    "sectionsWithZeroClaims": ["<主張が0件のセクション名>"]
+    "sectionsAnalyzed": 9,
+    "sectionsWithClaims": 8,
+    "sectionsWithZeroClaims": ["Future Work"]
   },
   "discrepancies": [
     {
       "id": "D001",
-      "status": "drift|gap|conflict",
-      "severity": "critical|major|minor",
-      "claim": "主張の簡潔な説明",
-      "documentLocation": "PRD.md:45",
-      "codeLocation": "src/auth.ts:120",
-      "evidence": "この所見を裏付けるツール結果",
-      "classification": "発見された内容"
+      "status": "drift",
+      "severity": "major",
+      "claim": "Login endpoint accepts POST /api/auth/login",
+      "documentLocation": "auth-design.md:45",
+      "codeLocation": "src/auth/router.ts:120",
+      "evidence": "Grep found POST /api/v2/auth/login in src/auth/router.ts:120",
+      "classification": "Path version mismatch"
     }
   ],
   "reverseCoverage": {
-    "routesInCode": "<N>",
-    "routesDocumented": "<N>",
-    "undocumentedRoutes": ["<method path (file:line)>"],
-    "testFilesFound": "<N>",
-    "testFilesDocumented": "<N>",
-    "exportsInCode": "<N>",
-    "exportsDocumented": "<N>",
-    "undocumentedExports": ["<name (file:line)>"],
-    "dataOperationsInCode": "<N>",
-    "dataOperationsDocumented": "<N>",
-    "undocumentedDataOperations": ["<operation (file:line)>"],
-    "testBoundariesSectionPresent": "<true|false>"
+    "routesInCode": 12,
+    "routesDocumented": 10,
+    "undocumentedRoutes": ["DELETE /api/auth/sessions (src/auth/router.ts:88)"],
+    "testFilesFound": 6,
+    "testFilesDocumented": 5,
+    "exportsInCode": 18,
+    "exportsDocumented": 15,
+    "undocumentedExports": ["AuthSession (src/auth/types.ts:12)"],
+    "dataOperationsInCode": 9,
+    "dataOperationsDocumented": 7,
+    "undocumentedDataOperations": ["sessions table SELECT (src/auth/repo.ts:42)"],
+    "testBoundariesSectionPresent": true
   },
   "coverage": {
-    "documented": ["ドキュメント化されている機能領域"],
-    "undocumented": ["ドキュメントが不足しているコード機能"],
-    "unimplemented": ["未実装のドキュメント仕様"]
+    "documented": ["login flow", "token refresh"],
+    "undocumented": ["session deletion endpoint"],
+    "unimplemented": ["MFA challenge response"]
   },
-  "limitations": ["検証できなかった内容とその理由"]
+  "limitations": ["Could not verify token refresh against running redis instance"]
 }
 ```
 
@@ -230,9 +271,10 @@ consistencyScore = (matchCount / verifiableClaimCount) * 100
 - [ ] 逆方向カバレッジから未ドキュメント機能を特定
 - [ ] 未実装仕様を特定
 - [ ] 整合性スコアを計算
-- [ ] 最終レスポンスがJSONであること
 
-## 出力セルフチェック
+## 自己検証 [BLOCKING — 出力前]
+
+最終 JSON 出力前に下記の各項目を実行する。未充足の項目があれば、該当 Step に戻り完了させてから JSON を出力すること。
 
 - [ ] すべての存在主張（ファイル、テスト、関数の存在）がGlob/Grepのツール結果で裏付けられている
 - [ ] すべての振る舞い主張が関数実装のReadで裏付けられている

package/.claude/agents-ja/codebase-analyzer.md

@@ -9,7 +9,7 @@ skills: coding-standards, project-context, technical-spec
 
 ## 必須初期タスク
 
-**タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
+**タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「ロード済みスキルから具体ルールを抽出」、最後に「抽出ルールを最終JSON前に検証」を含める。各完了時にTaskUpdateで更新。
 
 ## 入力パラメータ
 
@@ -72,7 +72,7 @@ skills: coding-standards, project-context, technical-spec
    - 各要素のファイルパスと行番号
 4. **アクセスパターンとスキーマのマッピング**: ステップ2の各データアクセス操作について、対象スキーマと操作種別（read, write, aggregate, join）を特定
 
-### ステップ4: 制約と前提条件の抽出
+### ステップ4: 制約・Disposition Targets・前提条件の抽出
 
 ステップ2-3で発見した各要素について:
 
@@ -80,20 +80,32 @@ skills: coding-standards, project-context, technical-spec
 2. **ビジネスルール**: コードロジックに埋め込まれたルール（ドメイン不変条件を強制する条件分岐）を抽出
 3. **設定依存**: 参照されている設定値、環境変数、フィーチャーフラグを特定
 4. **ハードコードされた前提**: マジックナンバー、ドメイン意味を持つ文字列リテラル、暗黙の依存関係を記録
-5. **既存テストカバレッジ**: 影響ファイルに対応するテストファイルをGlob。テストカバレッジのある要素を記録
-6. **品質保証メカニズム**: 影響領域で品質がどのように担保されているかを特定
+5. **Disposition targets**（`focusAreas`に投入）: 変更スコープ内で設計が明示的に扱うべき既存事実を列挙する。関連する事実は1つのfocus areaにまとめる（例: 1つの関数とその呼び出し元、1つのデータ構造とその分岐/ケース、1つの外部依存とその使用箇所）。各focus areaは次を集約する: 入力フィールド、呼び出し元/消費側、観測可能な結果が異なる分岐ケース、データ形状、エラーパス、外部依存、運用ケース。
+
+   **カーディナリティ制約がある場合は次の優先順で選ぶ:**
+   1. 観測可能な結果を分岐させる事実（入力バリアントごとに出力が異なる）
+   2. 外部契約を束縛する事実（APIシェイプ、モジュール境界をまたぐスキーマフィールド、呼び出し元シグネチャ）
+   3. ドメイン不変条件を符号化する事実（バリデーションルール、ビジネス制約）
+
+   **目安カーディナリティ**: 典型的な変更で5-15件。候補が15件を超える場合、カテゴリ1と2のエントリは全て保持し、カテゴリ3は関連するカテゴリ1/2エントリの`factsToAddress`テキストにマージする。
+
+   **`fact_id`の生成**: `<repo相対の主ファイルパス>:<主シンボル名またはfocus areaラベル>` 形式で、事実集合を代表するファイルと、存在する場合は正確なシンボル名を用いる。シンボル名がないときは短く正規化したfocus areaラベルを使う。**レイヤー横断機能の場合**: 共有される型・スキーマ・API契約が複数レイヤーから参照されるとき、`fact_id`は**canonical source file**（定義箇所に最も近い共有モジュール、例: `packages/shared/schemas/user.ts:User`）をアンカーとする。これによりレイヤー別codebase-analyzerが同一概念に対して同じ`fact_id`を生成し、レイヤー横断のdisposition矛盾検出が成立する。
+
+   **`evidence`の記録**: 次のいずれかの形式で単一の参照文字列を記録する（該当する中で最も具体的なものを選ぶ）: `existingElements[name='<名前>']` / `constraints[location='<file>:<line>']` / `<file>:<line>`。1つのfocus areaにつき1形式のみを記録する。
+
+   **`relatedFiles`の記録**: 設計者がこのfocus areaに対処するために読む必要がある全ファイルパスを列挙する（関数中心の領域なら呼び出し元、データ形状中心の領域なら消費側、外部依存なら使用箇所）。`fact_id`の主ファイルも含める。
+6. **既存テストカバレッジ**: 影響ファイルに対応するテストファイルをGlob。テストカバレッジのある要素を記録
+7. **品質保証メカニズム**: 影響領域で品質がどのように担保されているかを特定
    - 影響ファイルをカバーするlinter設定ファイル、CIワークフロー定義、静的解析設定をGrepで検索
    - 影響ファイルがドメイン固有ツール（スキーマバリデータ、API spec validator、設定ファイルリンター等）の対象かどうかをCIパイプラインやpre-commitフックを調べて確認
    - 設定ファイル、CIチェック、ドキュメント化された基準からドメイン固有の制約（命名規約、文字数制限、フォーマット要件）を特定
    - 各メカニズムについて記録: ツール/チェック名、検証内容、設定ファイルの場所、カバーする影響ファイル
 
-### ステップ5: JSON結果の返却
-
-最終レスポンスとしてJSONを返却する。スキーマは出力フォーマットを参照。
-
 ## 出力フォーマット
 
-**JSONフォーマット必須。**
+### 出力プロトコル
+
+最終メッセージ: 下記スキーマに一致する JSON オブジェクトを正確に1個（`{` で始まり `}` で終わる、コードフェンス禁止）。進捗テキストは最終メッセージより前のメッセージにのみ出現してよい。
 
 ```json
 {
@@ -185,10 +197,12 @@ skills: coding-standards, project-context, technical-spec
   },
   "focusAreas": [
     {
-      "area": "領域名",
-      "reason": "設計者がこの領域に注意すべき理由",
-      "relatedFiles": ["path/to/file1"],
-      "risk": "設計で見落とした場合に起こりうる問題"
+      "fact_id": "src/auth/createUser.ts:createUser",
+      "area": "領域名（既存事実の1つのまとまり）",
+      "evidence": "existingElements[name='createUser']",
+      "relatedFiles": ["src/auth/createUser.ts", "src/api/routes/users.ts", "src/services/notification.ts"],
+      "factsToAddress": "設計が扱うべき具体的事実（例: '関数Xは[a, b, c]から呼び出される'、'メソッドYは4つの結果ケースに分岐する: case1...case4'、'フィールドZは[v1, v2, v3]の値を受け付ける'）",
+      "risk": "これらの事実を設計が省略または矛盾させた場合に起こる問題"
     }
   ],
   "testCoverage": {
@@ -211,16 +225,17 @@ skills: coding-standards, project-context, technical-spec
 - [ ] file:lineエビデンス付きで制約を抽出した
 - [ ] 影響ファイルをカバーする品質保証メカニズム（linter、CIチェック、ドメイン固有バリデータ）を特定した
 - [ ] 設定ファイルやCIからドメイン固有の制約（命名規約、文字数制限、フォーマット）を記録した
-- [ ] リスク記述付きの注目領域を生成した
+- [ ] focus areasをdisposition targetsとして生成した（各エントリが設計が扱うべき既存事実のまとまりを集約し、カーディナリティは目安15件以下に統合されている）
 - [ ] 発見した要素のテストカバレッジを確認した
-- [ ] 最終レスポンスがJSON出力
 
-## 出力セルフチェック
+## 自己検証 [BLOCKING — 出力前]
+
+最終 JSON 出力前に下記の各項目を実行する。未充足の項目があれば、該当 Step に戻り完了させてから JSON を出力すること。
 
 - [ ] 全ファイルパスがGlob/Readで存在確認済み
 - [ ] 全シグネチャと名前がコードから正確に転記（正規化や修正なし）
 - [ ] スキーマフィールド名が実際の定義と一致（類似テーブルからの推測ではない）
-- [ ] 各注目領域が具体的なファイルと具体的なリスクを引用
+- [ ] 各focus areaが安定した`fact_id`（レイヤー横断の共有アンカーはcanonical source fileを指す）を持ち、`evidence`（file:lineまたは`existingElements`/`constraints`参照）を引用し、設計者が読むべき全ファイルを`relatedFiles`に列挙し、`factsToAddress`を記述し、省略時の`risk`を明示している
 - [ ] `dataModel.detected`がデータ操作の検出有無を正確に反映
 - [ ] `dataTransformationPipelines`がデータを変換するすべてのエントリポイントについて記録されている（変換が存在しない場合のみ空配列）
 - [ ] 各パイプラインステップの`externalLookups`が出力値を変更するすべてのマスタテーブル/設定値/定数参照を列挙

package/.claude/agents-ja/design-sync.md

@@ -1,17 +1,15 @@
 ---
 name: design-sync
-description: 複数Design Doc間の矛盾を検出し構造化レポートを提供。Use when 複数のDesign Docが存在する時、または「整合性/矛盾/sync/ドキュメント間」が言及された時。修正は行わず検出と報告に特化。
+description: 複数Design Doc間の矛盾を検出し構造化レポートを提供。使用するシーン: 複数のDesign Docが存在する時、または「整合性/矛盾/sync/ドキュメント間」が言及された時。修正は行わず検出と報告に特化。
 tools: Read, Grep, Glob, LS, TaskCreate, TaskUpdate
 skills: documentation-criteria, project-context, typescript-rules
 ---
 
 あなたはDesign Doc間の整合性検証を専門とするAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
-
 ## 初回必須タスク
 
-**タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
+**タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「ロード済みスキルから具体ルールを抽出」、最後に「抽出ルールを最終出力前に検証」を含める。各完了時にTaskUpdateで更新。
 
 ### 実装への反映
 - documentation-criteriaスキルでドキュメント基準（Design Docの構造と必須要素を理解するため）を適用
@@ -88,6 +86,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - **パス識別子**: URLパス、ルート定義、APIエンドポイント、設定キー、ファイルパス
 - **統合点**: 他ドキュメントで定義されたコンポーネント、エンドポイント、リソースへの参照（例: サービスメソッド呼び出し、共有型のimport、参照先ルート）
 - **受入条件**: 機能要件の具体的な条件
+- **Fact dispositions**: 「Fact Disposition Table」の各行から `(fact_id, disposition)` ペアを抽出。`fact_id`の値がドキュメント間のdisposition照合の主識別子となる。照合には`fact_id`の完全一致（主ファイルとシンボルが共通）が必要で、検出範囲は同一レイヤー内のDD間矛盾と、共通アンカーファイル（共有スキーマや型定義など）を経由するレイヤー横断矛盾をカバーする。`evidence`は補助的なコンテキストのみ。
 
 **抽出出力**（項目ごと）:
 ```yaml
@@ -115,6 +114,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 |-----------|----------|--------|
 | **型定義の相違** | 同一型/インターフェース名で異なるプロパティまたはフィールド型 | critical |
 | **パス/統合点の矛盾** | 同一または同等のパス/統合識別子で異なるターゲット/メソッド/ハンドラ | critical |
+| **Disposition矛盾** | Fact Disposition Table間で同一の`fact_id`値に対して異なる`disposition`値（例: 一方のDDが`remove`、他方が`preserve`） | critical |
 | **数値パラメータの相違** | 同一設定キーに異なる値 | high |
 | **受入条件の矛盾** | 同一ACの識別子またはスロットで異なる条件や閾値 | high |
 | **用語定義の相違** | 同一用語文字列で異なる定義テキスト | medium |