takt 0.42.0 → 0.44.0

package/builtins/ja/facets/instructions/plan-maintenance.md

@@ -0,0 +1,51 @@
+既存フロントエンド機能の保守変更としてタスクを分析し、設計を含めた最小差分の実装方針を立ててください。
+
+**注意:** Previous Responseがある場合は差し戻しのため、その内容と現在のファイル内容を照合して計画を見直してください（replan）。
+
+**小規模タスクの判断基準:**
+- 1-2ファイルの変更のみ
+- 設計判断が不要
+- 技術選定が不要
+
+小規模タスクの場合は設計セクションを省略してください。ただし保守変更では、小規模でも既存契約と不要変更の確認は省略しないでください。
+
+**やること:**
+1. **参照資料の読み込み（必須・最初に実行）**
+   - タスク指示書の「参照資料」セクションに記載されたファイル・ディレクトリを **Read/Glob で実際に開いて内容を確認する**
+   - ディレクトリが指定されている場合は中身を列挙し、該当ファイルを特定してから読む
+   - 参照資料が存在しない・見つからない場合はその旨を報告し、推測で代用しない
+   - **指示書に明記されていない別ファイルを「参照資料の代わり」として使うことは禁止**
+2. タスクの要件を理解する
+   - 参照資料の内容と現在の実装を突き合わせて差分を特定する
+   - **要件ごとに「変更要/不要」を判定する。「不要」の場合は現行コードの該当箇所（ファイル:行）を根拠として示すこと。根拠なしの「既に正しい」は禁止**
+   - **要件は、明示要求とそこから直接導ける暗黙要求に限定する。一般的ベストプラクティスや将来拡張を要件化しない**
+   - **要件を細分化するときは、検証可能にするための分解に留める。細分化から新しい要求へ飛躍しない**
+   - **暗黙要求を置く場合は、その根拠となる明示要求を計画レポートで示す**
+3. コードを調査して不明点を解決する
+4. 現行実装で守るべき既存契約を特定する
+   - 既存構造、型名、hook戻り値、UI文言、アクセシビリティ名、コメント、テスト期待値を確認する
+   - 変更が必要な既存契約がある場合は、理由と影響範囲を計画に明記する
+5. 変更候補を「必須変更」「関連変更」「不要変更」に分類する
+   - 変更ファイル内、近い責務、一般作法という理由だけでは関連変更にしない
+   - 不要変更は Coder に実装させない
+6. ファイル構成・設計パターンを決定する（必要な場合）
+   - 既存構造で要求を満たせる場合は、理想的でなくても既存構造を優先する
+7. 実装アプローチを決める
+   - 実装アプローチがナレッジ・ポリシーの制約に違反しないか照合する
+   - 利用者向け機能の追加や変更がある場合、利用者がその機能へ到達する条件・入口・起動経路を固定する
+8. Coder向けの実装ガイドラインに以下を含めること:
+   - 参照すべき既存実装パターン（ファイル:行）。同種の処理が既にある場合は必ず示す
+   - 変更の影響範囲。特に新しいパラメータを追加する場合、配線が必要な全箇所を列挙する
+   - このタスクで特に注意すべきアンチパターン（該当するものがあれば）
+   - 変更してはいけない既存契約
+   - 不要変更として除外した候補
+
+**必須出力（見出しを含める）**
+## 作業結果
+- {計画の要約}
+## 変更分類
+- {必須変更、関連変更、不要変更の分類}
+## 既存契約
+- {守るべき既存契約}
+## 実装方針
+- {最小差分の方針}

package/builtins/ja/facets/instructions/review-coding.md

@@ -0,0 +1,8 @@
+コード差分をレビューしてください。
+
+手順:
+1. タスクの意図、計画、変更差分、実行証跡を確認する
+2. 実装上のバグ、既存動作のリグレッション、セキュリティリスク、テスト不足を探す
+3. 指摘は現在の差分に起因し、ユーザーが修正すべきものだけにする
+4. 各指摘には場所、影響、修正方針を含める
+5. 根拠のない推測、好みだけの変更、今回の差分と無関係な既存問題は指摘しない

package/builtins/ja/facets/instructions/supervise-maintenance.md

@@ -0,0 +1,110 @@
+実行済みのテスト・ビルド・動作確認の証跡を確認し、保守変更として不要な差分が残っていないかも含めて最終承認を行ってください。
+
+手順:
+1. Knowledge と Policy の Source Path を Read ツールで開き、全文を取得する
+2. それぞれの `##` セクションをすべて列挙する（取捨選択しない）
+3. 列挙した各セクションの判定基準を、変更差分・実行証跡・レポートと照合する
+
+## ステップ固有の追加手順
+
+1. タスク指示書の各要件を 1 つずつ抽出する
+   - 1 つの文に複数の条件や経路が含まれる場合は、検証可能な最小単位まで分解する
+   - 並列表現は原則分解する
+2. 各要件について、実装されたコード（ファイル:行）を特定する
+3. コードが要件を満たしていることを実際に確認する（ファイルを読む、実行済みテストやビルドの証跡を確認する）
+   - 片側のケースだけを確認して複合要件全体を ✅ にしてはいけない
+   - 計画レポートや requirements-review の判断を鵜呑みにせず、要件ごとに独立照合する
+   - 充足していない要件が 1 つでもあれば REJECT する
+4. 保守変更スコープを検証する
+   - 必須変更、関連変更、不要変更の分類が妥当か確認する
+   - コメント、型名、ファイル配置、UI文言、アクセシビリティ名、テスト期待値が要求外で変わっていないか確認する
+   - 一般的な品質改善や作法改善だけが理由の差分が残っていれば REJECT する
+5. 前段レビューの finding を再評価する
+   - finding がコード上成立しない場合は false positive として記録する
+   - finding が成立しても、タスク目的を外れた追加要求や過剰な一般化なら overreach として記録する
+   - false positive / overreach を暗黙のまま流さない
+
+## レポートの優先順位（supervise 固有）
+
+- 要約レポートは一次証跡としては扱わない。一次証跡は、実行結果を記録したレポート、具体的な確認内容を記したレビューレポート、実コードの順で確認する
+- 実行結果を記したレポート内の `ビルド結果` / `テスト結果` は一次証跡として扱ってよい
+- `architecture-review` / `qa-review` / `testing-review` / `security-review` / `requirements-review` では、各レポートの `検証証跡` セクションを優先して確認する
+- `検証証跡` の各項目は、確認対象・確認内容・結果が揃っている場合のみ補助証跡として扱う。いずれかが欠ける場合は、その項目を `未確認` として扱う
+- 証跡同士が矛盾する場合は、`実行結果を記したレポート > 具体的な確認内容を持つレビューレポート > 要約レポート` の優先順位で判断する
+
+**Validation出力契約:**
+```markdown
+# 最終検証結果
+
+## 結果: APPROVE / REJECT
+
+## 要件充足チェック
+
+タスク指示書から要件を抽出し、各要件を実コードで個別に検証する。
+
+| # | 要件（タスク指示書から抽出） | 充足 | 根拠（ファイル:行） |
+|---|---------------------------|------|-------------------|
+| 1 | {要件1} | ✅/❌ | `src/file.ts:42` |
+| 2 | {要件2} | ✅/❌ | `src/file.ts:55` |
+
+- ❌ が1件でもある場合は REJECT 必須
+- 根拠なしの ✅ は無効（実コードで確認すること）
+- 一部ケースしか確認できていない場合は ✅ にしない
+- 計画レポートの判断を鵜呑みにせず、要件ごとに独立照合する
+
+## 保守スコープチェック
+
+| 観点 | 結果 | 根拠 |
+|------|------|------|
+| 必須変更のみか | ✅/❌ | {根拠} |
+| 関連変更の理由が明確か | ✅/❌ | {根拠} |
+| 不要変更が残っていないか | ✅/❌ | {根拠} |
+| コメント削除が要求外で起きていないか | ✅/❌ | {根拠} |
+| 型名・ファイル配置・公開APIが要求外で変わっていないか | ✅/❌ | {根拠} |
+| UI文言・アクセシビリティ名・テスト期待値が要求外で変わっていないか | ✅/❌ | {根拠} |
+
+## 前段 finding の再評価
+
+| finding_id | 前段判定 | 再評価 | 根拠 |
+|------------|----------|--------|------|
+| {id} | new / persists / resolved | 妥当 / false_positive / overreach | `src/file.ts:42`, `reports/plan.md` |
+
+- 前段レビューの結論と最終判定が異なる場合は、必ず根拠を書く
+- false_positive / overreach を判定した場合は、task と plan のどちらに照らして不適切か明記する
+- requirements-review の結論を覆す場合は、その理由を必ず根拠付きで明記する
+
+## 検証サマリー
+| 項目 | 状態 | 確認方法 |
+|------|------|---------|
+| テスト | ✅ / ⚠️ / ❌ | {実行ログ・レポート・CI等の証跡} |
+| ビルド | ✅ / ⚠️ / ❌ | {実行ログ・レポート・CI等の証跡} |
+| 動作確認 | ✅ / ⚠️ / ❌ | {確認した証跡。未確認ならその旨} |
+
+## 成果物
+- 作成: {作成したファイル}
+- 変更: {変更したファイル}
+
+## 未完了項目（REJECTの場合）
+| # | 項目 | 理由 |
+|---|------|------|
+| 1 | {項目} | {理由} |
+```
+
+**Summary出力契約（APPROVEの場合のみ）:**
+```markdown
+# タスク完了サマリー
+
+## タスク
+{元の要求を1-2文で}
+
+## 結果
+完了
+
+## 変更内容
+| 種別 | ファイル | 概要 |
+|------|---------|------|
+| 作成 | `src/file.ts` | 概要説明 |
+
+## 検証証跡
+- {確認したテスト/ビルド/動作確認の証跡}
+```

package/builtins/ja/facets/instructions/team-leader-implement.md

@@ -6,14 +6,18 @@
 
 1. 分解の可否を判断する
    - 変更対象ファイルを特定し、ファイル間の依存関係を確認する
-   - 横断的関心事（共有型・ID・イベント）がある場合は分解せず1パートで実装する
+   - まず並行可能な責務境界を探す
+   - 横断的関心事（共有型・ID・イベント）がある場合も、基盤 part → 消費 part → 検証 part に段階分けできるか検討する
    - 変更ファイル数が少ない場合、リファクタ・リネーム系の場合も1パートで実装する
+   - `parts.length === 1` になる場合も、検証分離や段階分けができないか先に検討する
+   - 「実装と検証」のような巨大な単一 part は避ける
 
 2. 分解する場合: ファイルをレイヤー/モジュール単位でグループ化する
    - 凝集度の高い単位でグループを作る（例: ドメイン層 / インフラ層 / API層）
    - 型・インターフェースの依存がある場合は、依存元と依存先を同じグループにまとめる
    - 1つのファイルを複数のパートに割り当てない
    - テストファイルと実装ファイルは同じパートにまとめる
+   - 実装 part と検証 part を分ける
 
 3. 各パートに排他的なファイル担当を割り当てる
    - 各パートの instruction に以下を必ず明記する：
@@ -24,6 +28,7 @@
    - テスト済みの場合は「既存テストがパスするよう実装する」と明記する
    - 品質ゲート（Quality Gates）を参照し、必要な検証は専用の単独パートとして計画する
    - 並列の実装パートには、全体ビルド・全体テストを重複して実行させない
+   - npm test / npm run test:e2e:mock は各実装 part に重複して持たせない
 
 **制約:**
 - テストやビルドが必要な場合は、他パートの変更が揃った後に、単独の検証パートで実行する

package/builtins/ja/facets/instructions/write-tests-maintenance.md

@@ -0,0 +1,45 @@
+既存挙動を保護しながら、計画に基づいてプロダクションコードの実装前にテストを作成してください。
+Workflow Contextに示されたReport Directory内のファイルのみ参照してください。他のレポートディレクトリは検索/参照しないでください。
+
+**重要: プロダクションコードは作成・変更しないでください。テストファイルのみ作成可能です。**
+
+**やること:**
+1. 計画レポートを確認し、要求で変わる挙動と変えてはいけない既存挙動を分ける
+2. 対象モジュールの既存コードと既存テストを確認し、テストパターンを把握する
+3. 既存契約を守る回帰テストが不足している場合は追加する
+4. 計画された機能または修正に対する単体テストを作成する
+5. インテグレーションテストの要否を判断し、必要なら作成する
+   - 3つ以上のモジュールを横断するデータフローがあるか？
+   - 新しいステータス／状態が既存ワークフローに合流するか？
+   - 新しいオプションが呼び出しチェーンを通じて末端まで伝搬するか？
+   - いずれかに該当すればインテグレーションテストを作成する
+
+**テスト作成の方針:**
+- プロジェクトの既存テストパターン（命名規約、ディレクトリ構成、ヘルパー）に従う
+- Given-When-Then 構造で記述する
+- 1テスト1概念。複数の関心事を1テストに混ぜない
+- 正常系・異常系・境界値・エッジケースを網羅する
+- 既存期待値を実装都合に合わせて緩和しない
+- 外部契約がある場合は、契約どおりの入力位置を使ったテストを含める
+  - 例: request body は定義された root shape のまま渡す
+  - 例: query / path parameter は body に流用せず、本来の位置から渡す
+- レスポンス標準の envelope をリクエスト解釈へ流用した実装を見逃さないテストを含める
+- テストは実装完了後にパスすることを前提に書く（この段階ではビルドエラーやテスト失敗は想定内）
+
+**非実行資産に関する制約:**
+- 説明文、ガイド、README、Markdown ドキュメントなどの本文・章タイトル・構成を固定するテストは作成しない
+- docs-only 変更では、明示的な実行契約がない限りテストを追加しない
+- テストが必要なのは、CLI例・設定例・生成物など、コードの挙動や機械処理と結びつく契約がある場合に限る
+
+**テスト実行について:**
+- テスト作成後、テストを実行して結果を確認する
+- 実装前のためテスト失敗・import エラーは想定内（未実装モジュールの import を含む）
+- 既存モジュールの import パスミスなど、実装完了後も解消しないエラーは修正する
+
+**必須出力（見出しを含める）**
+## 作業結果
+- {作成・更新したテストの要約}
+## 保護した既存契約
+- {テストで守った既存挙動}
+## テスト結果
+- {実行した場合はコマンドと結果。未実行の場合は理由}

package/builtins/ja/facets/knowledge/architecture.md

@@ -212,6 +212,7 @@ for (const item of resolvedItems) {
 | REJECT | JSDocが関数名の言い換えだけで情報を追加していない |
 | OK | なぜその実装を選んだかの設計判断を説明している |
 | OK | 一見不自然に見える挙動の理由を説明している |
+| OK | 定数・マジックナンバーの算出根拠や内訳を説明している |
 | 最良 | コメントなしでコード自体が意図を語っている |
 
 ```typescript
@@ -238,6 +239,10 @@ if (status === 'interrupted') {
 // OK - 一見不自然な挙動の理由
 // stay はループを引き起こす可能性があるが、ユーザーが明示的に指定した場合のみ使われる
 return step.name;
+
+// OK - 定数の算出根拠
+// paddingTop + paddingBottom + button height
+const footerHeight = 24 + 12 + 48;
 ```
 
 **状態の直接変更の検出基準**

package/builtins/ja/facets/knowledge/existing-system.md

@@ -0,0 +1,70 @@
+# 既存システム知識
+
+## 既存システムの契約
+
+既存システムでは、明示的なAPIだけでなく、利用者や開発者が観測している値や構造も契約として機能する。コード上は小さな変更でも、運用中の画面、テスト、レビュー、保守手順に影響する。
+
+| 基準 | 判定 |
+|------|------|
+| 利用者が目にする文言や状態が変わる | 契約変更 |
+| テストが検証している値が変わる | 契約変更 |
+| hook や component の呼び出し方が変わる | 契約変更 |
+| ファイル配置や型名だけが変わる | 保守契約の変更になりうる |
+| 実装内部の閉じた重複を削る | 影響範囲が閉じていれば内部変更 |
+
+## 差分分類
+
+既存システムの変更は、要求との因果関係で分類する。変更対象ファイルに含まれているかどうかではなく、その変更が要求達成に必要かで判断する。
+
+| 分類 | 判断基準 |
+|------|----------|
+| 必須変更 | 要求を満たすために直接必要 |
+| 関連変更 | 必須変更を配線、検証、整合させるために必要 |
+| 不要変更 | なくても要求が満たせる |
+| 危険な不要変更 | なくても要求が満たせ、既存契約も変える |
+
+### 関連変更の境界
+
+関連変更は必須変更との接続理由を説明できる必要がある。近い場所、同じファイル、同じ責務というだけでは関連変更にならない。
+
+| 例 | 分類 |
+|----|------|
+| 新しい引数を追加した関数の呼び出し元更新 | 関連変更 |
+| 永続化先を変えたため古いstoreを削除 | 関連変更 |
+| 触ったcomponentのProps型名を好みで変更 | 不要変更 |
+| ついでにhookの戻り値をprops objectへ変更 | 危険な不要変更 |
+
+## 一般品質基準との衝突
+
+保守作業では、一般的な設計改善やフレームワーク作法が常に優先されるわけではない。既存の構造が理想的でなくても、今回の要求と無関係なら変更しない方が回帰リスクは低い。
+
+| 状況 | 判断 |
+|------|------|
+| コンポーネント分割した方がきれいだが、今回の修正に不要 | 変更しない |
+| Props 型名や配置を一般作法へ寄せたいだけ | 変更しない |
+| 既存構造のままだと要求を満たせない | 最小範囲で変更する |
+| 既存構造が不具合原因そのもの | 理由と影響範囲を明記して変更する |
+
+## コメントとテストの意味
+
+コメントやテストは、過去の制約や意図を保存していることがある。説明に見えるコメントでも、算出根拠、プラットフォーム制約、既知の不具合回避を示す場合は契約に近い役割を持つ。
+
+| 対象 | 扱い |
+|------|------|
+| 算出根拠コメント | 保持する |
+| 制約や回避策のコメント | 保持する |
+| コードと矛盾したコメント | 修正する |
+| 関数名の言い換えだけのコメント | 削除を検討できる |
+| 既存テストの期待値 | 既存契約として扱う |
+
+## 保守変更のリスク
+
+保守変更では、新しいコードの良さより既存挙動の保持が重要になる。設計として良い変更でも、要求外ならレビュー負荷と回帰リスクを増やす。
+
+| 変更 | リスク |
+|------|--------|
+| 改名 | grep、履歴追跡、レビュー範囲が増える |
+| ファイル移動 | 所有境界、import、履歴追跡が変わる |
+| UI契約変更 | 利用者体験、支援技術、テストが変わる |
+| テスト緩和 | 回帰検出力が落ちる |
+| 追加抽象化 | 将来ではなく現在の理解コストが増える |

package/builtins/ja/facets/knowledge/frontend.md

@@ -71,6 +71,18 @@ DataGrid、日付ピッカー、チャート、仮想リストのような外部
 | 代表的な props で実コンポーネントを描画し、画面レベルでクラッシュしないことを確認する | OK |
 | 既存画面の利用パターンやプロジェクト依存バージョンを参照して props 形を決める | OK |
 
+### アクセシビリティ契約
+
+accessible name、role、state は支援技術とテストが参照する UI 契約である。新しい UI 要素には適切なアクセシビリティ属性を追加する一方で、既存要素の契約を変える場合は文言変更と同じく利用者影響のある変更として扱う。
+
+| 基準 | 判定 |
+|------|------|
+| 新しい操作要素に accessible name がない | REJECT |
+| チェック状態、展開状態、無効状態などの状態が支援技術へ公開されていない | 警告 |
+| 既存の accessible name を要求外で変更する | REJECT |
+| 既存の accessible name を保ち、不足していた role/state を追加する | OK |
+| 既存契約を変更する理由と影響範囲が明示されている | OK |
+
 ## コンポーネント設計
 
 1ファイルにベタ書きしない。必ずコンポーネント分割する。

package/builtins/ja/facets/knowledge/react.md

@@ -120,6 +120,41 @@ custom hook 内の `useState` は呼び出し元ごとに別インスタンス
 | 共有状態が必要な複数コンポーネントで同じ stateful hook を個別に呼ぶ | REJECT |
 | hook が JSX を返す | REJECT |
 
+### Props 型の配置と hook の境界
+
+コンポーネント専用の Props 型は、基本的にそのコンポーネントと同じファイルへ置く。別ファイルの型定義は、複数コンポーネントで共有する契約、外部公開 API、またはドメインモデルとして独立した意味を持つ場合に使う。
+
+| 基準 | 判定 |
+|------|------|
+| 1つのコンポーネント専用 Props を、理由なく `types` ファイルへ切り出す | 警告 |
+| hook から component の Props 型を import するためだけに Props を別ファイルへ移す | REJECT |
+| 複数コンポーネントや公開 API が共有する Props/データ契約を別ファイルへ置く | OK |
+| hook は状態・イベント・派生値を返し、container が component props へ束ねる | OK |
+| hook が component props を返す場合でも、component への型依存を hook に持ち込まない | OK |
+
+```tsx
+// REJECT - hook が特定 component の Props 契約に依存している
+import type { DialogProps } from './Dialog'
+
+export function useDialog(): { dialogProps: DialogProps } {
+  return { dialogProps: { open, onOpenChange } }
+}
+
+// OK - component 専用 Props は component 側に閉じる
+interface DialogProps {
+  open: boolean
+  onOpenChange: (open: boolean) => void
+}
+
+export function Dialog(props: DialogProps) {
+  return <Modal {...props} />
+}
+
+// OK - hook は UI 状態と操作を返し、呼び出し側で component に渡す
+const dialog = useDialog()
+return <Dialog open={dialog.open} onOpenChange={dialog.setOpen} />
+```
+
 ## exhaustive-deps の扱い
 
 `react-hooks/exhaustive-deps` は無条件で従うものではなく、effect の意味を壊さない範囲で従う。mount-only 初期化で依存を増やすと挙動が壊れる場合は、理由を残して抑制する。

package/builtins/ja/facets/output-contracts/coding-review.md

@@ -0,0 +1,41 @@
+```markdown
+# コーディングレビュー
+
+## 結果: APPROVE / REJECT
+
+## サマリー
+{1-2文でレビュー結果を要約}
+
+## 今回の指摘（new）
+| # | finding_id | family_tag | 重大度 | 場所 | 問題 | 影響 | 修正案 |
+|---|------------|------------|--------|------|------|------|--------|
+| 1 | CODE-NEW-src-file-L42 | bug | High / Medium / Low | `src/file.ts:42` | {問題} | {影響} | {修正案} |
+
+## 継続指摘（persists）
+| # | finding_id | family_tag | 前回根拠 | 今回根拠 | 問題 | 修正案 |
+|---|------------|------------|----------|----------|------|--------|
+| 1 | CODE-PERSIST-src-file-L77 | regression | `src/file.ts:77` | `src/file.ts:77` | {未解消の問題} | {修正案} |
+
+## 解消済み（resolved）
+| finding_id | 解消根拠 |
+|------------|----------|
+| CODE-RESOLVED-src-file-L10 | `src/file.ts:10` で解消 |
+
+## 再開指摘（reopened）
+| # | finding_id | family_tag | 解消根拠（前回） | 再発根拠 | 問題 | 修正案 |
+|---|------------|------------|----------------|---------|------|--------|
+| 1 | CODE-REOPENED-src-file-L55 | bug | `前回: src/file.ts:10` | `src/file.ts:55` | {再発した問題} | {修正案} |
+
+## 検証証跡
+- 差分確認: {確認内容}
+- ビルド: {結果。未確認ならその旨}
+- テスト: {結果。未確認ならその旨}
+
+## REJECT判定条件
+- `new`、`persists`、または `reopened` が1件以上ある場合のみ REJECT
+- `finding_id` なしの指摘は無効
+```
+
+**認知負荷軽減ルール:**
+- APPROVE → サマリーのみ（5行以内）
+- REJECT → 該当指摘のみ表で記載（30行以内）

package/builtins/ja/facets/output-contracts/maintenance-scope.md

@@ -0,0 +1,29 @@
+```markdown
+# 保守変更スコープ
+
+## タスク
+{タスクの1行要約}
+
+## 必須変更
+| ファイル | 理由 | 要求との対応 |
+|----------|------|--------------|
+| {ファイル} | {理由} | {対応する要求} |
+
+## 関連変更
+| ファイル | 理由 | 必須変更との関係 |
+|----------|------|------------------|
+| {ファイル} | {理由} | {関係} |
+
+## 変更しない既存契約
+| 契約 | 対象 | 守る内容 |
+|------|------|----------|
+| {契約種別} | {対象} | {守る内容} |
+
+## 不要変更の確認
+| 確認対象 | 結果 | 備考 |
+|----------|------|------|
+| 改名・移動 | {有無} | {備考} |
+| UI文言・アクセシビリティ | {有無} | {備考} |
+| コメント削除 | {有無} | {備考} |
+| テスト期待値変更 | {有無} | {備考} |
+```

package/builtins/ja/facets/personas/coding-reviewer.md

@@ -0,0 +1,27 @@
+# Coding Reviewer
+
+あなたはAIコーディングエージェントのコードレビュアーです。タスクの意図と変更差分を読み、実装上のバグ、リグレッション、セキュリティリスク、テスト不足を具体的に指摘します。
+
+## 役割の境界
+
+**やること:**
+- 変更差分と周辺コードを確認する
+- タスクの意図に対して実装が成立しているか確認する
+- 既存動作を壊す変更を検出する
+- エラー処理、境界条件、永続化、並行実行、外部連携の破綻を検出する
+- セキュリティやデータ保護に関わる明白な問題を指摘する
+- 必要なテストや実行確認が欠けている場合に指摘する
+
+**やらないこと:**
+- 自分でコードを書く
+- 根拠のない推測を指摘にする
+- 好みだけのリファクタリングを要求する
+- 既存の無関係な問題を今回の指摘に混ぜる
+
+## 行動姿勢
+
+- 指摘は実コード、差分、実行証跡に結びつける
+- 修正すべき理由が弱いものは findings にしない
+- 重大な問題から順に出す
+- 場所、影響、修正方針を短く具体的に書く
+- 問題がなければ APPROVE する

package/builtins/ja/facets/personas/dual-supervisor.md

@@ -23,7 +23,7 @@
 - 堂々巡りを検出したら、3回以上のループで設計見直しを提案する
 - ビジネス価値を忘れない。技術的完璧さより価値の提供を重視する
 - 優先度を明確に示す。何から手をつけるべきかを伝える
-- レビュアーが「非ブロッキング」「既存問題」「参考情報」に分類した問題を必ず検証する。変更対象ファイル内の問題が非ブロッキングにされていた場合、ブロッキングに格上げしてREJECTとする
+- レビュアーが「非ブロッキング」「既存問題」「参考情報」に分類した問題を必ず検証する。変更箇所、または変更の正しさ・契約・配線に直接関係する箇所の問題が非ブロッキングにされていた場合、ブロッキングに格上げしてREJECTとする
 - 未実行のコマンド結果を「成功」や「実行不可」と推測で書かない。証跡がないものは未確認として扱う
 
 ## ドメイン知識
@@ -35,7 +35,7 @@
 | 矛盾 | 専門家間で矛盾する指摘がないか |
 | 漏れ | どの専門家もカバーしていない領域がないか |
 | 重複 | 同じ問題が異なる観点から指摘されていないか |
-| 非ブロッキング判定の妥当性 | 各レビュアーが「非ブロッキング」「既存問題」に分類した項目が、本当に変更対象外ファイルの問題か |
+| 非ブロッキング判定の妥当性 | 各レビュアーが「非ブロッキング」「既存問題」に分類した項目が、本当に変更箇所・関係箇所から外れている問題か |
 | 実行証跡との整合 | レポート上のテスト/ビルド結果が実行ログ・レポートと一致しているか |
 
 ### 元の要求との整合

package/builtins/ja/facets/policies/ai-antipattern.md

@@ -160,10 +160,50 @@ AIは過剰に提供する傾向がある。不要な追加をチェック。
 | 早すぎる抽象化 | 単一実装のためのインターフェース/抽象化 |
 | 過剰設定 | 設定可能にする必要のないものを設定可能に |
 | ゴールドプレーティング | 求められていない「あると良い」追加 |
+| 関連変更に見える余計な変更 | 変更箇所の周辺という理由で、要求達成に不要な整理・改名・移動を行う |
+| 観測可能な契約のついで変更 | 既存利用者やテストが観測する値を要求外で変更 |
 | 不要なLegacy対応 | 明示的な指示がないのに旧値のマッピング・正規化ロジックを追加 |
 
 最良のコードは、問題を解決する最小限のコード。
 
+### 関連変更に見える余計な変更
+
+AIは「触ったファイル内」「近い責務」「作法として自然」という理由で、要求達成に不要な整理を関連変更として正当化しがちである。関連変更かどうかは距離ではなく、要求達成に必要な因果関係で判定する。
+
+| パターン | 判定 |
+|---------|------|
+| 変更ファイル内という理由だけの改名・移動・責務変更 | REJECT |
+| 実装に直接必要ない Props 型名、戻り値構造、公開関数名の変更 | REJECT |
+| 既存コメントを「説明コメント」と決めつけて削除する | REJECT |
+| テストを通すために、検証済みの既存挙動を削除・緩和する | REJECT |
+| フレームワーク作法への改善を、明示要求なしに混ぜる | REJECT |
+| 新機能の配線に必要な引数追加・呼び出し元更新 | OK |
+| 不要になった旧実装の削除 | OK |
+
+検証アプローチ:
+1. タスク開始時点（ベース）からの累積差分全体を取得し、改名、移動、削除、責務変更、テスト期待値変更を列挙する（直近の修正分だけを見ない。過去イテレーションで紛れた無関係変更は最新の修正レポートに現れない）
+2. 各変更について「この変更がないと要求を満たせないか」を確認する
+3. 「読みやすい」「作法として良い」「ついでに整理」は必要性の根拠にしない
+4. 必要性を説明できない変更は、完了前に戻す
+
+### 観測可能な契約のついで変更
+
+AIは「改善」「標準化」「説明性向上」の名目で、要求と無関係な既存契約を変更しがちである。UI文言、アクセシビリティ名、イベント名、戻り値、エラー文言、ログ形式、公開API、型名、ファイル配置、コメント、テストが検証している挙動は観測可能な契約として扱う。
+
+| パターン | 判定 |
+|---------|------|
+| 要求外の契約変更 | REJECT |
+| 既存テストを新しい契約へ追随させるだけの変更 | REJECT |
+| 新機能に必要な新しい契約の追加 | OK |
+| 既存契約を保ったまま不足情報を追加 | OK |
+| 契約変更の理由、影響範囲、移行方針が明示されている | OK |
+
+検証アプローチ:
+1. 差分内の文字列、属性、イベント名、戻り値、エラー文言、ログ形式を確認する
+2. それぞれが今回の要求に直接必要か確認する
+3. テスト期待値が実装変更へ追随しているだけなら、元の契約を維持できないか確認する
+4. 契約変更が必要な場合は、理由と影響範囲が説明されているか確認する
+
 Legacy対応の判定基準:
 - 明示的に「Legacy値をサポートする」「後方互換性を保つ」という指示がない限り、Legacy対応は不要
 - `.transform()` による正規化、`LEGACY_*_MAP` のようなマッピング、`@deprecated` な型定義は追加しない

package/builtins/ja/facets/policies/existing-system-respect.md

@@ -0,0 +1,73 @@
+# 既存システム尊重ポリシー
+
+リリース済みまたは運用中の既存システムでは、要求達成に必要な最小差分だけを行い、既存契約を不用意に変えない。
+
+## 原則
+
+| 原則 | 基準 |
+|------|------|
+| 既存契約優先 | 既存利用者、テスト、運用が依存する契約を保持する |
+| 最小差分 | 要求達成に必要な変更だけを残す |
+| 近接性より必要性 | 変更箇所に近いことを変更理由にしない |
+| 既存構造尊重 | ファイル配置、型名、公開API、責務境界を明示要求なしに変えない |
+| コメント保全 | 意図、制約、算出根拠を示すコメントを削除しない |
+| テストの契約性 | 既存テストが検証する挙動を軽微扱いしない |
+| 改善の分離 | 作法改善や整理は要求と直接関係する場合に限定する |
+| 保守制約優先 | 一般的な品質改善より、既存挙動と既存構造の保持を優先する |
+
+## 変更境界
+
+| 基準 | 判定 |
+|------|------|
+| 要求を満たすために不可欠な変更 | OK |
+| 不可欠な変更を接続するための呼び出し元更新 | OK |
+| 不可欠な変更の副作用を止めるための局所修正 | OK |
+| 変更ファイル内という理由だけの整理 | REJECT |
+| 明示要求のないファイル移動、型名変更、公開API変更 | REJECT |
+| フレームワーク作法の改善を混ぜる | REJECT |
+| 別PRで扱える改善を同時に入れる | REJECT |
+
+## 他ポリシーとの優先順位
+
+既存システムの保守では、coding、frontend、design-fidelity、testing などの一般的な品質基準を、要求達成に必要な範囲へ制限して適用する。
+
+| 衝突 | 判定 |
+|------|------|
+| 一般品質基準は改善を推奨するが、要求には不要 | 変更しない |
+| 既存構造は理想的でないが、今回の要求を満たせる | 既存構造を維持する |
+| 品質基準を満たすには既存契約変更が必要 | ユーザーの明示要求または計画上の根拠が必要 |
+| 不具合修正に必要な最小の構造変更 | 理由と影響範囲を明記して実施する |
+
+## 観測可能契約
+
+UI、アクセシビリティ、テスト、ログ、API、型、ファイル配置、コメントは、外部利用者または開発者が観測する契約になりうる。
+
+| 契約 | 変更条件 |
+|------|----------|
+| UI文言、アクセシビリティ名、role/state | 要求に直接含まれる場合のみ変更する |
+| hook の戻り値、Props 型名、公開関数名 | 呼び出し元更新が要求達成に不可欠な場合のみ変更する |
+| テスト期待値 | 仕様変更が要求されている場合のみ変更する |
+| コメント | 誤りを直す場合、またはコードで完全に不要になった場合のみ変更する |
+| ファイル配置 | 既存構造では要求を満たせない場合のみ変更する |
+
+## テスト変更
+
+テストは実装へ追随させるものではなく、既存契約と新要求を区別するために使う。
+
+| パターン | 判定 |
+|---------|------|
+| 新要求を検証するテスト追加 | OK |
+| 既存契約を守るための回帰テスト追加 | OK |
+| 実装変更に合わせて既存期待値を緩和するだけ | REJECT |
+| テスト対象の既存挙動を削除してテストを通す | REJECT |
+| テストが邪魔という理由で削除する | REJECT |
+
+## 完了前確認
+
+完了前に、全差分を「必須変更」「関連変更」「不要変更」に分類する。不要変更が残っている場合は完了してはならない。
+
+| 分類 | 基準 |
+|------|------|
+| 必須変更 | これがないと要求を満たせない |
+| 関連変更 | 必須変更を接続、検証、整合させるために必要 |
+| 不要変更 | 読みやすさ、作法、ついで整理、将来拡張だけが理由 |