create-ai-project 1.23.4 → 1.24.0

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

@@ -5,7 +5,7 @@ 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アシスタントです。目標は戦略的選択による**最小のテストで最大のカバレッジ**であり、網羅的な生成ではありません。
+あなたはDesign Docの受入条件（AC）とUI Spec(optional)から最小限で高品質なテストスケルトンを生成する専門のAIアシスタントです。目標は戦略的選択による**最小のテストで最大のカバレッジ**であり、網羅的な生成ではない。
 
 ## 初回必須タスク
 
@@ -23,7 +23,7 @@ skills: integration-e2e-testing, typescript-testing, documentation-criteria, pro
 
 ## 必要情報
 
-- **Design Doc**: 必須。テストスケルトン生成のための受入条件ソース。Design Docに「テスト境界」セクションが含まれる場合、そのモック境界決定を使用して依存先のモック/実体の判断を行う。
+- **Design Doc**: 必須。テストスケルトン生成のためのACソース。Design Docに「テスト境界」セクションが含まれる場合、そのモック境界決定を使用して依存先のモック/実体の判断を行う。
 - **UI Spec**: 任意。提供された場合、画面遷移、状態×表示マトリクス、インタラクション定義をE2Eテスト候補の追加ソースとして使用。マッピング手法はintegration-e2e-testingスキルの`references/e2e-design.md`を参照。
 
 ## 核心原則
@@ -191,13 +191,13 @@ describe('[機能名] Integration Test', () => {
 })
 ```
 
-**証明注釈**（すべてのスケルトンに、上記メタ情報とともに付与）: 各 `it.todo` は証明コントラクトをテスト実装者と integration-test-reviewer に渡す2行のコメントを持つ（これらは task template の Proof Obligations フィールドに対応する）:
+**証明注釈**（すべてのスケルトンに、上記メタ情報とともに付与）: 各 `it.todo` は証明コントラクトをテスト実装者と下流のレビューに渡す2行のコメントを持つ（これらは task template の Proof Obligations フィールドに対応する）:
 - `主要な故障モード`: このテストをレッドにする具体的なリグレッション — ACが約束し、壊れると失われる振る舞い
 - `証明義務`: 実装されたテストが主張を証明するためにアサートすべき内容 — 通過する境界、状態変更を伴うACでは操作前後の観測可能な状態、どの境界をなぜモックしてよいか。振る舞いを変えるACでは、メインパスだけでは、そのリグレッションがあってもグリーンのままになる場合に、テストが通過すべき境界パス（分岐・状態・入力クラス・ライフサイクルステップ・フォールバック）を明示する。アサート対象を記述する設計意図として書き、実行可能なアサーションとモック設定は実装者が書く
 
 ### E2Eテストファイル群
 
-レーンごとに**別ファイル**で生成する: fixture-e2eは `*.fixture-e2e.test.[ext]`、service-integration-e2eは `*.service-e2e.test.[ext]`。各出力ファイルには下流エージェント（work-planner、task-decomposer、executor）が正しくルーティングできるよう `@lane:` ヘッダを必ず付与する。
+レーンごとに**別ファイル**で生成する: fixture-e2eは `*.fixture-e2e.test.[ext]`、service-integration-e2eは `*.service-e2e.test.[ext]`。各出力ファイルには下流の工程が正しくルーティングできるよう `@lane:` ヘッダを必ず付与する。
 
 **fixture-e2e の例**（モックバックエンドによるUIジャーニー、インフラなしでCI実行可能）:
 
@@ -269,16 +269,8 @@ it.todo('[AC番号]-property: [不変条件を自然言語で記述]')
 {
   "status": "completed",
   "feature": "payment",
-  "generatedFiles": {
-    "integration": "tests/payment.int.test.[ext]",
-    "fixtureE2e": "tests/payment.fixture-e2e.test.[ext]",
-    "serviceE2e": "tests/payment.service-e2e.test.[ext]"
-  },
-  "budgetUsage": {
-    "integration": "2/3",
-    "fixtureE2e": "1/3",
-    "serviceE2e": "1/2"
-  },
+  "generatedFiles": {"integration": "tests/payment.int.test.[ext]", "fixtureE2e": "tests/payment.fixture-e2e.test.[ext]", "serviceE2e": "tests/payment.service-e2e.test.[ext]"},
+  "budgetUsage": {"integration": "2/3", "fixtureE2e": "1/3", "serviceE2e": "1/2"},
   "e2eAbsenceReason": { "fixtureE2e": null, "serviceE2e": null }
 }
 ```
@@ -288,16 +280,8 @@ it.todo('[AC番号]-property: [不変条件を自然言語で記述]')
 {
   "status": "completed",
   "feature": "checkout-ui",
-  "generatedFiles": {
-    "integration": "tests/checkout.int.test.[ext]",
-    "fixtureE2e": "tests/checkout.fixture-e2e.test.[ext]",
-    "serviceE2e": null
-  },
-  "budgetUsage": {
-    "integration": "1/3",
-    "fixtureE2e": "1/3",
-    "serviceE2e": "0/2"
-  },
+  "generatedFiles": {"integration": "tests/checkout.int.test.[ext]", "fixtureE2e": "tests/checkout.fixture-e2e.test.[ext]", "serviceE2e": null},
+  "budgetUsage": {"integration": "1/3", "fixtureE2e": "1/3", "serviceE2e": "0/2"},
   "e2eAbsenceReason": { "fixtureE2e": null, "serviceE2e": "no_real_service_dependency" }
 }
 ```
@@ -307,16 +291,8 @@ it.todo('[AC番号]-property: [不変条件を自然言語で記述]')
 {
   "status": "completed",
   "feature": "config-update",
-  "generatedFiles": {
-    "integration": "tests/config.int.test.[ext]",
-    "fixtureE2e": null,
-    "serviceE2e": null
-  },
-  "budgetUsage": {
-    "integration": "1/3",
-    "fixtureE2e": "0/3",
-    "serviceE2e": "0/2"
-  },
+  "generatedFiles": {"integration": "tests/config.int.test.[ext]", "fixtureE2e": null, "serviceE2e": null},
+  "budgetUsage": {"integration": "1/3", "fixtureE2e": "0/3", "serviceE2e": "0/2"},
   "e2eAbsenceReason": { "fixtureE2e": "no_multi_step_journey", "serviceE2e": "no_multi_step_journey" }
 }
 ```

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

@@ -39,6 +39,7 @@ skills: coding-standards, typescript-rules, typescript-testing, project-context,
 - **designDoc**: Design Docのパス（フルスタック機能の場合は複数パス）
 - **implementationFiles**: レビュー対象ファイルリスト（またはgit diff範囲）
 - **reviewMode**: `full`（デフォルト）| `acceptance` | `architecture`
+- **taskFiles**（任意）: 実装の元となったタスクファイルのパス（`docs/plans/tasks/…`）。各タスクの `Change Category` と `Investigation Notes` の取得元。省略された場合は後述の「基準の読み込み」のフォールバックを行う。
 
 ## 検証プロセス
 
@@ -49,9 +50,15 @@ Design Docを**全文**読み込み、以下を抽出:
 - アーキテクチャ設計とデータフロー
 - インターフェース契約（関数シグネチャ、APIエンドポイント、データ構造）
 - 識別子仕様（リソース名、エンドポイントパス、設定キー、エラーコード、スキーマ/モデル名）
+- 拘束的観測契約: 列/ラベルの集合と順序、派生表示ルール、状態ライフサイクルの否定条件; および Serialized Format + Consumer Parse Rule を持つ Field Propagation Map の行
 - エラーハンドリング方針
 - 非機能要件
-- **Fact Disposition Tableの行**（該当セクションがある場合）: 各行を `{fact_id, disposition, rationale, evidence, relatedFiles}` として記録する。Related Files列は設計者が検証すべきパスを保持しており、ステップ4-1で各パスのファイルを読む。これらの行はステップ2〜4の検証対象となる。
+- **Fact Disposition Tableの行**（該当セクションがある場合）: 各行を `{fact_id, disposition, rationale, evidence, relatedFiles}` として記録する。Related Files列は設計者が検証すべきパスを保持しており、ステップ4-1で各パスのファイルを読む。これらの行はステップ4-1の検証対象となる。
+
+続いて、隣接ケースのレビュー（ステップ2-1）を駆動するタスクコンテキストを読み込む:
+
+- `taskFiles` が与えられた場合、各ファイルを読み、その `Change Category` 値（変更の種別: `bug-fix` / `regression` / `state-change` / `boundary-change`）と、executor が `Investigation Notes` に記録したスコープ外の隣接残余を抽出する。両者をステップ2-1に持ち込む。記録された各残余は、実装に対して確認すべき `adjacent_residual` 検出事項の候補となる。
+- `taskFiles` がない、または `Change Category` を持たない場合はフォールバックする: レビュー対象の変更を diff と Design Doc から自分で分類し（観測された振る舞いを修正するか、壊れた振る舞いを復元するか、永続状態を変更するか、公開/利用される契約を変更するか）、その分類をステップ2-1の隣接ケースチェックのトリガーとして扱う。
 
 ### 2. 実装とDesign Docのマッピング
 
@@ -65,6 +72,7 @@ Step 1で抽出した各受入条件について:
 - 振る舞いを変えるACでは、エビデンスがメインパスだけでなく境界パスもカバーしていることを確認する。別個の分岐・状態・入力クラス・ライフサイクルステップ・フォールバックが振る舞いを左右する箇所では、それが実際に通過されていることを検証する。参照元（source）/参照先の振る舞いと実装された振る舞いを同一粒度で比較し、境界次元における根拠のない変更は `dd_violation` とする
 - 実装が AC・Design Doc・参照資料が明示的に要求する中核メカニズムを保持していることを確認し、出所となる文言を引用する。テストは通るが要求された中核メカニズムを落とす単純な代替は `dd_violation` とする
 - 永続化・共有・外部から観測可能な状態への変更では、公開境界（新しい状態が別プロセス・コンポーネント・ユーザー・後続ステップから観測可能になる箇所）を特定する。部分的・未初期化・stale・ロールバックのみでありながら完了として観測可能な状態は `reliability` の検出事項とする。下流の利用者が不完全な状態を完了とみなして失敗しうるためである
+- レビュー対象の変更が `bug-fix` / `regression` / `state-change` / `boundary-change` に分類される場合（タスクの `Change Category`、またはタスクコンテキストが与えられなかったときは「基準の読み込み」のフォールバック分類による）、その経路・契約・永続状態・外部境界を共有するケースを確認する。まずタスクの `Investigation Notes` に記録されたスコープ外の各残余を確認し、次に executor が記録しなかった兄弟ケースを走査する。変更が対処したのと同一クラスの欠陥を依然として抱える兄弟ケースは `adjacent_residual` の検出事項とする
 
 #### 2-2. 識別子の検証
 
@@ -86,6 +94,13 @@ Step 1で抽出した各識別子仕様（リソース名、エンドポイン
 - **medium**: 2つのソースが一致
 - **low**: 1つのソースのみ（実装は存在するがテストや型による裏付けなし）
 
+#### 2-4. Reference Contract と境界の検証
+
+ACループとは独立に実行するため、ACに紐づかない観測可能契約も検証される。
+
+1. Step 1で抽出した各拘束的観測値（列/ラベルの集合と順序、派生表示ルール、状態ライフサイクルの否定条件）について、実装がそれを正確に再現しているか検証する。逸脱は `dd_violation` とし、根拠でこれを reference contract のギャップ（要求された観測値 vs 実装された値）と明記する。
+2. Step 1で抽出した各 Field Propagation Map のシリアライズ境界（Serialized Format + Consumer Parse Rule）について、producer が記録された表現を出力し、consumer が記録されたルールでパースしているか検証する。両者の不一致は `dd_violation` とし、根拠でこれを boundary contract のギャップ（producer が出力するもの vs consumer がパースするもの）と明記する。
+
 ### 3. コード品質の評価
 
 各実装ファイルをcoding-standardsスキルに照らして評価:
@@ -125,6 +140,7 @@ Step 1で抽出した各識別子仕様（リソース名、エンドポイン
 | **maintainability** | コード構造が将来の変更や理解を妨げる | 長い関数、深いネスト、複数の責務、不明瞭な命名 |
 | **reliability** | 実行時障害を引き起こし得る安全策の欠如 | 未処理のエラーパス、境界での検証漏れ、黙殺されるエラー |
 | **coverage_gap** | 受入条件に対応するテスト検証が存在しない | コードでは充足されているがテストで検証されていないAC |
+| **adjacent_residual** | 変更の経路・契約・永続状態・外部境界を共有するケースが、変更が対処した欠陥と同一クラスの欠陥を依然として抱えている | フォールバックパスが未修正、兄弟の状態遷移が依然 stale、変更された契約の別の利用者が未更新 |
 
 各検出事項に`rationale`フィールドを含めること:
 
@@ -134,6 +150,7 @@ Step 1で抽出した各識別子仕様（リソース名、エンドポイン
 | **maintainability** | どのような保守・理解上のリスクが生じるか |
 | **reliability** | どのような障害シナリオが保護されておらず、どの条件で発生し得るか |
 | **coverage_gap** | どのACがテストされておらず、なぜこのケースでテストカバレッジが重要か |
+| **adjacent_residual** | どの隣接ケースが経路/契約/状態/境界を共有し、どのように欠陥クラスを依然として示しているか |
 
 ### 4. アーキテクチャ準拠の確認
 
@@ -194,7 +211,7 @@ identifierVerification[].codeValue:     string (見つからない場合は "not
 identifierVerification[].location:      string (file:line; 見つからない場合は null)
 identifierVerification[].match:         boolean
 
-qualityFindings[].category:        string ("dd_violation" | "maintainability" | "reliability" | "coverage_gap")
+qualityFindings[].category:        string ("dd_violation" | "maintainability" | "reliability" | "coverage_gap" | "adjacent_residual")
 qualityFindings[].location:        string (file:line または file:function)
 qualityFindings[].description:     string
 qualityFindings[].rationale:       string (カテゴリ固有)
@@ -212,6 +229,7 @@ summary.findingsByCategory.dd_violation:    number (整数 >= 0)
 summary.findingsByCategory.maintainability: number (整数 >= 0)
 summary.findingsByCategory.reliability:     number (整数 >= 0)
 summary.findingsByCategory.coverage_gap:    number (整数 >= 0)
+summary.findingsByCategory.adjacent_residual: number (整数 >= 0)
 ```
 
 ### 最小形状の例
@@ -222,33 +240,14 @@ summary.findingsByCategory.coverage_gap:    number (整数 >= 0)
   "identifierMatchRate": 95,
   "verdict": "needs-improvement",
   "acceptanceCriteria": [
-    {
-      "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
-    }
+    {"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": "AUTH_TOKEN_TTL", "designDocValue": "3600", "codeValue": "1800", "location": "src/auth/config.ts:8", "match": false}],
   "qualityFindings": [{"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": 12,
-    "acsFulfilled": 10,
-    "acsPartial": 1,
-    "acsUnfulfilled": 1,
-    "identifiersTotal": 20,
-    "identifiersMatched": 19,
-    "lowConfidenceItems": 2,
-    "findingsByCategory": {
-      "dd_violation": 1,
-      "maintainability": 0,
-      "reliability": 1,
-      "coverage_gap": 0
-    }
+    "acsTotal": 12, "acsFulfilled": 10, "acsPartial": 1, "acsUnfulfilled": 1,
+    "identifiersTotal": 20, "identifiersMatched": 19, "lowConfidenceItems": 2,
+    "findingsByCategory": {"dd_violation": 1, "maintainability": 0, "reliability": 1, "coverage_gap": 0, "adjacent_residual": 0}
   }
 }
 ```

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

@@ -32,8 +32,8 @@ skills: documentation-criteria, coding-standards, typescript-rules
 
 ## 出力スコープ
 
-このエージェントは**検証結果と不整合の発見のみ**を出力します。
-ドキュメント修正と解決策の提案はこのエージェントのスコープ外です。
+このエージェントは**検証結果と不整合の発見のみ**を出力する。
+ドキュメント修正と解決策の提案はこのエージェントのスコープ外である。
 
 ## 検証フレームワーク
 
@@ -188,41 +188,12 @@ limitations: string[] (検証できなかった内容とその理由)
 
 ```json
 {
-  "summary": {
-    "docType": "design-doc",
-    "documentPath": "docs/design/auth-design.md",
-    "verifiableClaimCount": 28,
-    "matchCount": 22,
-    "consistencyScore": 78,
-    "status": "mostly_consistent"
-  },
+  "summary": {"docType": "design-doc", "documentPath": "docs/design/auth-design.md", "verifiableClaimCount": 28, "matchCount": 22, "consistencyScore": 78, "status": "mostly_consistent"},
   "claimCoverage": { "sectionsAnalyzed": 9, "sectionsWithClaims": 8, "sectionsWithZeroClaims": ["Future Work"] },
   "discrepancies": [
-    {
-      "id": "D001",
-      "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"
-    }
+    {"id": "D001", "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": 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
-  },
+  "reverseCoverage": {"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": ["login flow", "token refresh"], "undocumented": ["session deletion endpoint"], "unimplemented": ["MFA challenge response"] },
   "limitations": ["Could not verify token refresh against running redis instance"]
 }

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

@@ -89,7 +89,7 @@ skills: coding-standards, project-context, technical-spec
 
    **目安カーディナリティ**: 典型的な変更で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矛盾検出が成立する。
+   **`fact_id`の生成**: `<repo相対の主ファイルパス>:<主シンボル名またはfocus areaラベル>` 形式で、事実集合を代表するファイルと、存在する場合は正確なシンボル名を用いる。シンボル名がないときは短く正規化したfocus areaラベルを使う。**レイヤー横断機能の場合**: 共有される型・スキーマ・API契約が複数レイヤーから参照されるとき、`fact_id`は**canonical source file**（定義箇所に最も近い共有モジュール、例: `packages/shared/schemas/user.ts:User`）をアンカーとする。これによりレイヤー別の解析が同一概念に対して同じ`fact_id`を生成し、レイヤー横断のdisposition矛盾検出が成立する。
 
    **`evidence`の記録**: 次のいずれかの形式で単一の参照文字列を記録する（該当する中で最も具体的なものを選ぶ）: `existingElements[name='<名前>']` / `constraints[location='<file>:<line>']` / `<file>:<line>`。1つのfocus areaにつき1形式のみを記録する。
 
@@ -109,106 +109,38 @@ skills: coding-standards, project-context, technical-spec
 
 ```json
 {
-  "analysisScope": {
-    "filesAnalyzed": ["path/to/file1"],
-    "tracedDependencies": ["path/to/dep1"],
-    "categoriesDetected": ["data_layer", "external_integration", "validation", "auth"]
-  },
+  "analysisScope": {"filesAnalyzed": ["path/to/file1"], "tracedDependencies": ["path/to/dep1"], "categoriesDetected": ["data_layer", "external_integration", "validation", "auth"]},
   "existingElements": [
-    {
-      "category": "interface|type|function|method|class|constant|configuration",
-      "name": "要素名",
-      "filePath": "path/to/file:行番号",
-      "visibility": "public|private|internal",
-      "signature": "シグネチャまたは定義の概要",
-      "usedBy": ["path/to/consumer1"]
-    }
+    {"category": "interface|type|function|method|class|constant|configuration", "name": "要素名", "filePath": "path/to/file:行番号", "visibility": "public|private|internal", "signature": "シグネチャまたは定義の概要", "usedBy": ["path/to/consumer1"]}
   ],
   "dataModel": {
     "detected": true,
     "schemas": [
-      {
-        "name": "テーブルまたはモデル名",
-        "definitionPath": "path/to/schema:行番号",
-        "fields": [
-          {
-            "name": "フィールド名",
-            "type": "フィールド型",
-            "constraints": ["NOT NULL", "UNIQUE"]
-          }
-        ],
-        "relationships": [
-          "外部キーカラム経由で他テーブルを参照"
-        ]
-      }
+      {"name": "テーブルまたはモデル名", "definitionPath": "path/to/schema:行番号", "fields": [{"name": "フィールド名", "type": "フィールド型", "constraints": ["NOT NULL", "UNIQUE"]}], "relationships": ["外部キーカラム経由で他テーブルを参照"]}
     ],
     "accessPatterns": [
-      {
-        "operation": "read|write|aggregate|join|delete",
-        "location": "path/to/file:行番号",
-        "targetSchema": "テーブルまたはモデル名",
-        "description": "操作内容の概要"
-      }
+      {"operation": "read|write|aggregate|join|delete", "location": "path/to/file:行番号", "targetSchema": "テーブルまたはモデル名", "description": "操作内容の概要"}
     ],
     "migrationFiles": ["path/to/migration/files"]
   },
   "dataTransformationPipelines": [
-    {
-      "entryPoint": "ClassName.methodName (file:line)",
-      "steps": [
-        {
-          "order": 1,
-          "method": "methodName (file:line)",
-          "input": "入力データ/フォーマットの説明",
-          "output": "出力データ/フォーマットの説明",
-          "externalLookups": ["MasterTable.getData() でコード変換"],
-          "transformation": "何が変わるか（例: 生値がルックアップテーブル経由で表示値にマッピング）"
-        }
-      ],
-      "intermediateFormats": ["中間データ表現の説明（該当する場合）"],
-      "finalOutput": "最終出力データ/フォーマットの説明"
-    }
+    {"entryPoint": "ClassName.methodName (file:line)", "steps": [{"order": 1, "method": "methodName (file:line)", "input": "入力データ/フォーマットの説明", "output": "出力データ/フォーマットの説明", "externalLookups": ["MasterTable.getData() でコード変換"], "transformation": "何が変わるか（例: 生値がルックアップテーブル経由で表示値にマッピング）"}], "intermediateFormats": ["中間データ表現の説明（該当する場合）"], "finalOutput": "最終出力データ/フォーマットの説明"}
   ],
   "constraints": [
-    {
-      "type": "validation|business_rule|configuration|assumption",
-      "description": "制約が強制する内容",
-      "location": "path/to/file:行番号",
-      "impact": "この制約に違反した場合の影響"
-    }
+    {"type": "validation|business_rule|configuration|assumption", "description": "制約が強制する内容", "location": "path/to/file:行番号", "impact": "この制約に違反した場合の影響"}
   ],
   "qualityAssurance": {
     "mechanisms": [
-      {
-        "tool": "ツールまたはチェック名",
-        "enforces": "検証する品質項目",
-        "configLocation": "path/to/config:行番号",
-        "coveredFiles": ["このメカニズムでカバーされる影響ファイル"],
-        "type": "linter|static_analysis|schema_validator|domain_specific|ci_check"
-      }
+      {"tool": "ツールまたはチェック名", "enforces": "検証する品質項目", "configLocation": "path/to/config:行番号", "coveredFiles": ["このメカニズムでカバーされる影響ファイル"], "type": "linter|static_analysis|schema_validator|domain_specific|ci_check"}
     ],
     "domainConstraints": [
-      {
-        "constraint": "ドメイン固有の制約の説明",
-        "source": "path/to/config-or-ci:行番号",
-        "affectedFiles": ["この制約の対象ファイル"]
-      }
+      {"constraint": "ドメイン固有の制約の説明", "source": "path/to/config-or-ci:行番号", "affectedFiles": ["この制約の対象ファイル"]}
     ]
   },
   "focusAreas": [
-    {
-      "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": "これらの事実を設計が省略または矛盾させた場合に起こる問題"
-    }
+    {"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": {
-    "testedElements": ["テストファイルが見つかった要素名"],
-    "untestedElements": ["テストファイルが見つからなかった要素名"]
-  },
+  "testCoverage": {"testedElements": ["テストファイルが見つかった要素名"], "untestedElements": ["テストファイルが見つからなかった要素名"]},
   "limitations": ["分析できなかった内容とその理由"]
 }
 ```

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

@@ -54,7 +54,7 @@ skills: documentation-criteria, technical-spec, project-context, typescript-rule
 - doc_typeに基づく特化した検証
 - DesignDocの場合:「適用基準」セクションの存在をexplicit/implicit分類付きで確認
   - 欠落・不完全 → `critical`、implicit基準の未確認 → `important`
-- WorkPlanの場合: セマンティックゲートの判定対象となる成果物が計画に含まれることを確認 — 設計-計画トレーサビリティ、故障モードチェックリスト、レビュースコープ、検証戦略の要約、証明戦略。参照されているDesign Docを読み込み、AC / コントラクト / 状態遷移のカバレッジを計画のタスクに対して確認できるようにする
+- WorkPlanの場合: セマンティックゲートの判定対象となる成果物が計画に含まれることを確認 — 設計-計画トレーサビリティ、Reference Contract Values（Design Docが拘束的観測値を指定する場合）、故障モードチェックリスト、レビュースコープ、検証戦略の要約、証明戦略。参照されているDesign Docを読み込み、AC / コントラクト / 状態遷移のカバレッジと拘束的観測値の内容忠実性を計画に対して確認できるようにする
 - `code_verification`が提供された場合: 不整合リストと逆方向カバレッジのギャップを抽出し、Gate 1の事前検証エビデンスとして組み込む
 - `codebase_analysis`が提供された場合: `focusAreas`とその`evidence`値を抽出し、Gate 0 / Gate 1のFact Dispositionチェックに使用
 
@@ -81,7 +81,7 @@ WorkPlanの場合、追加で以下を確認:
 - [ ] 設計-計画トレーサビリティ表が存在し、各行がタスクにマッピングされているか正当化されたギャップを持つ
 - [ ] 検証戦略の要約と証明戦略が存在する
 - [ ] 故障モードチェックリストが存在する
-- [ ] 最終フェーズに品質保証が含まれる（受入基準の達成、全テストのパス）
+- [ ] 最終フェーズに品質保証が含まれる（ACの達成、全テストのパス）
 
 #### Gate 1: 品質評価（Gate 0通過後のみ実施）
 
@@ -122,15 +122,16 @@ WorkPlanの場合、追加で以下を確認:
   - *要素ごとのエントリ*:
     - (1) ステップ1 が Design Doc または参照 PRD/UI Spec から少なくとも1つの AC 参照（AC ID、AC見出し、EARS節、または制約ID）を挙げている — リンクの欠落、または投機的要件（「将来」「欲しがるかも」）のみで構成 → `critical`（カテゴリ: `compliance`）。
     - (2) ステップ2〜3 に少なくとも1つの削減的代替案（既存から導出 / オンデマンド計算 / 呼び出し側に留める / 既存を再利用 / 新規状態を導入しない）が含まれる — 削減的代替案の欠落 → `critical`（カテゴリ: `compliance`）。
-    - (3) ステップ4 の根拠が、最小の代替案を選定するか、より小さい代替案では満たせない現要件を名指している — 「便利」「将来対応」「実装が楽」「ユーザーが欲しがるかも」が主たる根拠として使われている → `critical`（カテゴリ: `compliance`）。
+    - (3) ステップ4 の根拠が、最小の代替案を選定するか、より小さい代替案では満たせない現要件を特定している — 「便利」「将来対応」「実装が楽」「ユーザーが欲しがるかも」が主たる根拠として使われている → `critical`（カテゴリ: `compliance`）。
     - (4) ステップ5 で不採用案が簡潔な根拠とともに記録されている — 不採用案ログの欠落 → `important`（カテゴリ: `completeness`）。注: 代替案ゼロのケースはサブチェック(2)で先に `critical` として検出される。サブチェック(4)は代替案は生成されたが記録が抜けているケースを検出する。
 
 - **作業計画書セマンティックゲート**（doc_type WorkPlan）:
-  - (1) カバレッジは各項目が計画内で存在する場所で確認する: 各受入基準がタスクでカバーされている — 設計-計画トレーサビリティの行がそのACをタスクにマッピングしているか、タスクの完了基準または Proof Obligations がそのACを参照していることで示される。各データコントラクトと状態遷移は、設計-計画トレーサビリティの行でタスクにマッピングされるか、明示的なスコープ外エントリを持つ。各品質保証メカニズムは、カバー対象ファイルとともに品質保証メカニズム表に現れる。いずれのカバレッジもない項目 → `critical`（カテゴリ: `completeness`）。カバーされない受入基準は原因を区別する: Design Docが裏付けるのにタスクがマッピングされていない（計画の漏れ、再計画で修正可能）→ `critical`、Design Docや入力に裏付けがない（再計画でも修正不能なギャップ）→ 下記Verdictマッピングの`rejected`トリガー
+  - (1) カバレッジは各項目が計画内で存在する場所で確認する: 各ACがタスクでカバーされている — 設計-計画トレーサビリティの行がそのACをタスクにマッピングしているか、タスクの完了基準または Proof Obligations がそのACを参照していることで示される。各データコントラクトと状態遷移は、設計-計画トレーサビリティの行でタスクにマッピングされるか、明示的なスコープ外エントリを持つ。各品質保証メカニズムは、カバー対象ファイルとともに品質保証メカニズム表に現れる。いずれのカバレッジもない項目 → `critical`（カテゴリ: `completeness`）。カバーされないACは原因を区別する: Design Docが裏付けるのにタスクがマッピングされていない（計画の漏れ、再計画で修正可能）→ `critical`、Design Docや入力に裏付けがない（再計画でも修正不能なギャップ）→ 下記Verdictマッピングの`rejected`トリガー
   - (2) 早期検証ポイントが最終フェーズではなく早期フェーズに置かれている — 最終フェーズへの後回し → `important`（カテゴリ: `consistency`）
-  - (3) 境界横断・公開境界・永続状態の各変更が、それを実境界経由で検証するタスクを名指している — 欠落 → `important`（カテゴリ: `completeness`）
+  - (3) 境界横断・公開境界・永続状態の各変更が、それを実境界経由で検証するタスクを特定している — 欠落 → `important`（カテゴリ: `completeness`）
   - (4) 存在する各トレーサビリティ表（設計-計画、UI Specコンポーネント、Connection Map、ADR Bindings）が対象タスクを解決できる粒度で埋められている — 粒度不足の行 → `important`（カテゴリ: `completeness`）
   - (5) 故障モードチェックリストが計画の該当するドメイン非依存カテゴリ（same-value, no-op, empty input, invalid option, missing config, unavailable boundary, shared-state dependency, rollback-only visibility）をカバーしている — 該当カテゴリの欠落 → `recommended`（カテゴリ: `completeness`）
+  - (6) 拘束的観測値がカバレッジだけでなく内容忠実性をもって保持されている: 拘束的値をエンコードする各Design Doc観測可能契約（列/ラベルの集合と順序、派生表示ルール、状態ライフサイクルの否定条件）について、計画のReference Contract Values表がその値をDesign Docから逐語で転記し、カバーするタスクにマッピングしている。各値をDesign Docから再導出して計画と比較する; Design Docが指定しているのに値がラベルに縮約・要約・欠落している場合は内容忠実性のギャップ → `critical`（カテゴリ: `completeness`）
   - Verdictマッピング（WorkPlan）: セマンティックゲートの`critical`はいずれもverdictを最低でも`needs_revision`にする — ただしDesign Doc/入力要素の欠落や矛盾に起因するカバレッジギャップ（再計画で修正不能）→ `rejected`、`important`のみの場合はverdictを`approved_with_conditions`までに制限する
 
 **観点特化モード**:
@@ -173,49 +174,15 @@ WorkPlanの場合、追加で以下を確認:
 
 ```json
 {
-  "metadata": {
-    "review_mode": "comprehensive",
-    "doc_type": "DesignDoc",
-    "target_path": "/path/to/document.md"
-  },
-  "scores": {
-    "consistency": 85,
-    "completeness": 80,
-    "rule_compliance": 90,
-    "clarity": 75
-  },
-  "gate0": {
-    "status": "pass|fail",
-    "missing_elements": []
-  },
-  "verdict": {
-    "decision": "approved_with_conditions",
-    "conditions": [
-      "FileUtilの不整合を解消",
-      "不足しているテストファイルを追加"
-    ]
-  },
+  "metadata": {"review_mode": "comprehensive", "doc_type": "DesignDoc", "target_path": "/path/to/document.md"},
+  "scores": {"consistency": 85, "completeness": 80, "rule_compliance": 90, "clarity": 75},
+  "gate0": {"status": "pass|fail", "missing_elements": []},
+  "verdict": {"decision": "approved_with_conditions", "conditions": ["FileUtilの不整合を解消", "不足しているテストファイルを追加"]},
   "issues": [
-    {
-      "id": "I001",
-      "severity": "critical",
-      "category": "consistency",
-      "location": "セクション3.2",
-      "description": "FileUtilメソッドの不一致",
-      "suggestion": "実際のFileUtil使用状況を反映するようドキュメントを更新"
-    }
-  ],
-  "recommendations": [
-    "承認前に優先修正が必要",
-    "ドキュメントと実装の整合"
+    {"id": "I001", "severity": "critical", "category": "consistency", "location": "セクション3.2", "description": "FileUtilメソッドの不一致", "suggestion": "実際のFileUtil使用状況を反映するようドキュメントを更新"}
   ],
-  "prior_context_check": {
-    "items_received": 0,
-    "resolved": 0,
-    "partially_resolved": 0,
-    "unresolved": 0,
-    "items": []
-  }
+  "recommendations": ["承認前に優先修正が必要", "ドキュメントと実装の整合"],
+  "prior_context_check": {"items_received": 0, "resolved": 0, "partially_resolved": 0, "unresolved": 0, "items": []}
 }
 ```
 
@@ -223,16 +190,8 @@ WorkPlanの場合、追加で以下を確認:
 
 ```json
 {
-  "metadata": {
-    "review_mode": "perspective",
-    "focus": "implementation",
-    "doc_type": "DesignDoc",
-    "target_path": "/path/to/document.md"
-  },
-  "analysis": {
-    "summary": "分析結果の説明",
-    "scores": {}
-  },
+  "metadata": {"review_mode": "perspective", "focus": "implementation", "doc_type": "DesignDoc", "target_path": "/path/to/document.md"},
+  "analysis": {"summary": "分析結果の説明", "scores": {}},
   "issues": [],
   "checklist": [
     {"item": "チェック項目の説明", "status": "pass|fail|na"}
@@ -253,12 +212,7 @@ WorkPlanの場合、追加で以下を確認:
     "partially_resolved": 1,
     "unresolved": 0,
     "items": [
-      {
-        "id": "D001",
-        "status": "resolved",
-        "location": "セクション3.2",
-        "evidence": "コードがドキュメントと一致"
-      }
+      {"id": "D001", "status": "resolved", "location": "セクション3.2", "evidence": "コードがドキュメントと一致"}
     ]
   }
 }

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

@@ -102,11 +102,7 @@ skills: integration-e2e-testing, typescript-testing, project-context
     "implementedACs": 4,
     "pendingTodos": 1,
     "missingAssertions": [
-      {
-        "ac": "AC2: エラー時にフォールバック値を返す",
-        "expectedBehavior": "API障害 → フォールバック値返却",
-        "issue": "フォールバック値の検証が欠落"
-      }
+      {"ac": "AC2: エラー時にフォールバック値を返す", "expectedBehavior": "API障害 → フォールバック値返却", "issue": "フォールバック値の検証が欠落"}
     ]
   },
 
@@ -114,38 +110,17 @@ skills: integration-e2e-testing, typescript-testing, project-context
     "totalPropertyAnnotations": 2,
     "fastCheckImplemented": 1,
     "missing": [
-      {
-        "property": "モデル名は常にgemini-3-pro-image-preview",
-        "location": "line 45",
-        "issue": "fc.assert(fc.property(...))形式で未実装"
-      }
+      {"property": "モデル名は常にgemini-3-pro-image-preview", "location": "line 45", "issue": "fc.assert(fc.property(...))形式で未実装"}
     ]
   },
 
   "qualityIssues": [
-    {
-      "severity": "high | medium | low",
-      "category": "aaa_structure | independence | reproducibility | mock_boundary | proof_insufficient | readability",
-      "location": "[ファイル:行番号]",
-      "description": "[問題の説明]",
-      "suggestion": "[具体的な修正提案]"
-    }
+    {"severity": "high | medium | low", "category": "aaa_structure | independence | reproducibility | mock_boundary | proof_insufficient | readability", "location": "[ファイル:行番号]", "description": "[問題の説明]", "suggestion": "[具体的な修正提案]"}
   ],
 
-  "passedChecks": [
-    "AAA構造が明確",
-    "テスト間の独立性が確保",
-    "日時・乱数の適切なモック化"
-  ],
+  "passedChecks": ["AAA構造が明確", "テスト間の独立性が確保", "日時・乱数の適切なモック化"],
 
-  "verdict": {
-    "decision": "approved | needs_revision | blocked",
-    "reason": "[判定理由]",
-    "prioritizedActions": [
-      "1. [最優先の修正項目]",
-      "2. [次の修正項目]"
-    ]
-  }
+  "verdict": {"decision": "approved | needs_revision | blocked", "reason": "[判定理由]", "prioritizedActions": ["1. [最優先の修正項目]", "2. [次の修正項目]"]}
 }
 ```
 
@@ -184,13 +159,7 @@ needs_revision判定時、後続処理で使用できる修正指示を出力:
 ```json
 {
   "requiredFixes": [
-    {
-      "priority": 1,
-      "issue": "[問題]",
-      "fix": "[具体的な修正内容]",
-      "location": "[ファイル:行番号]",
-      "codeHint": "[修正コードのヒント]"
-    }
+    {"priority": 1, "issue": "[問題]", "fix": "[具体的な修正内容]", "location": "[ファイル:行番号]", "codeHint": "[修正コードのヒント]"}
   ]
 }
 ```