takt 0.41.0 → 0.43.0

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/frontend-review.md

@@ -11,6 +11,7 @@
 |------|------|------|
 | コンポーネント設計 | ✅ | - |
 | 状態管理 | ✅ | - |
+| 正規状態と派生状態 | ✅ | - |
 | パフォーマンス | ✅ | - |
 | アクセシビリティ | ✅ | - |
 | 型安全性 | ✅ | - |

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,15 +160,74 @@ 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` な型定義は追加しない
 - 新しい値のみをサポートし、シンプルに保つ
 
+### 関数オブジェクトによる過剰抽象化
+
+AIは少数の具体分岐を、設定配列・関数オブジェクト・汎用ループに置き換えて「拡張しやすく」見せがちである。問題は Strategy ではなく、概念名を与えずに差分をデータへ隠すこと。業務概念として名前が付き、差し替え点が明確になる Strategy は有効である。
+
+| パターン | 例 | 判定 |
+|---------|-----|------|
+| 1箇所でしか使わない処理設定配列 | `[{ kind, fields, removedFields }]` を loop で処理 | REJECT |
+| 削除・副作用・例外条件が設定オブジェクトに隠れる | 設定値を読まないと破壊的変更が分からない | REJECT |
+| 分岐ごとの処理が1-3行で完結するのに関数オブジェクト化 | `handlers[type]()` だけが増える | REJECT |
+| Strategy が業務概念を表し、実装差し替えの境界を明確にする | `TaxPolicy`, `PaymentMethod`, `RetryStrategy` | OK |
+| 分岐数が多く、処理形が同じで、今後も追加される | handler map を検討 | OK |
+
+検証アプローチ:
+1. 追加された配列・Map・Strategy・関数オブジェクトの使用箇所を grep する
+2. 使用箇所が1つなら、明示分岐の方が読みやすいか確認する
+3. 設定オブジェクトに副作用・削除対象・互換処理が隠れていないか確認する
+4. ドメイン上の意味が分岐名で十分に表せるなら `when` / `switch` を優先する
+5. 概念として名前を付けることで理解が進むなら Strategy を許容する
+
 ## 早すぎるキャッシュ戦略の導入
 
 AIはパフォーマンスを「改善」するためにキャッシュ機構を先回りで導入しがちである。明示的に要求されるまでキャッシュ戦略は追加しない。

package/builtins/ja/facets/policies/coding.md

@@ -14,6 +14,7 @@
 | ボーイスカウト | 触った箇所は少し改善して去る |
 | Fail Fast | エラーは早期に検出。握りつぶさない |
 | プロジェクトスクリプト優先 | ツール実行はプロジェクト定義のスクリプトを使う。直接実行は最後の手段 |
+| 状態の正規化 | 同じ事実を複数の状態として保持しない |
 
 ## フォールバック・デフォルト引数の禁止
 
@@ -183,6 +184,41 @@ const handlers = { A: handleA, B: handleB, C: handleC };
 handlers[type]?.();
 ```
 
+### 抽象化しすぎない
+
+抽象化は重複や変更軸を減らすだけでなく、概念に名前を与えて理解しやすくするためにも使う。ただし、数件の具体処理を「設定オブジェクト + 関数オブジェクト + ループ」に変換して、業務上の違いが読みづらくなるだけなら抽象化ではない。
+
+| 基準 | 判定 |
+|------|------|
+| 少数の分岐がイベント種別・状態・業務概念ごとに異なる | `when` / `switch` で明示する |
+| 同じ処理を同じ引数構造で3箇所以上繰り返す | 抽象化を検討 |
+| 1箇所でしか使わない設定配列・関数オブジェクト | REJECT。まず明示分岐 |
+| 設定オブジェクトを読まないと副作用や削除対象が分からない | REJECT |
+| Strategy が業務概念に名前を与え、複数実装の差し替え点を明確にしている | OK |
+| 分岐名がドメイン概念として読める | OK |
+
+```typescript
+// ❌ 過剰抽象化 - 何が起きるかを設定配列とループの両方から読む必要がある
+const operations = [
+  { kind: 'create', normalize: ['owner'], remove: [] },
+  { kind: 'revise', normalize: ['owner'], remove: ['legacyOwner'] },
+]
+for (const operation of operations) {
+  applyOperation(record, operation)
+}
+
+// ✅ 分岐ごとの意味が重要なら明示する
+switch (record.kind) {
+  case 'create':
+    normalizeOwner(record)
+    break
+  case 'revise':
+    removeLegacyOwner(record)
+    normalizeOwner(record)
+    break
+}
+```
+
 ### 抽象度を揃える
 
 1つの関数内では同じ粒度の処理を並べる。詳細な処理は別関数に切り出す。「何をするか」と「どうやるか」を混ぜない。
@@ -319,11 +355,56 @@ return storage.upload(file, options)
 | 再実行条件が URL・フィルタ・明示的更新操作などの仕様に対応している | OK |
 | 初期化と再取得のトリガーを分けて設計している | OK |
 
+## 契約変更の整合性
+
+型、インターフェース、API、設定スキーマ、永続化形式、イベント、ファイル形式など、他のコードや利用者が依存する契約を変更する場合は、定義側・生成側・利用側・検証側を同じ変更で整合させる。
+
+| 基準 | 判定 |
+|------|------|
+| 契約定義だけを変更し、呼び出し元・生成元・読み取り側を更新していない | REJECT |
+| 新しい引数・フィールド・設定値を追加したが、利用側へ値を渡す経路がない | REJECT |
+| 文書化されたスキーマや設定形式に存在しないフィールド・値を使っている | REJECT |
+| モック、fixture、テストデータが実際の契約と異なる形を返している | REJECT |
+| 契約変更と呼び出し元・生成元・テスト更新が同じ変更で行われている | OK |
+
 ## 状態管理
 
 - 状態は使う場所に閉じ込める
 - 子は状態を直接変更しない（イベントを親に通知）
 - 状態の流れは単方向
+- 正規状態から計算できる派生値を、独立した状態として保持しない
+- 複数フィールド間に常時同期が必要なら、状態モデルを見直す
+
+| 基準 | 判定 |
+|------|------|
+| ある状態から常に計算できる値を別の状態として保持している | REJECT |
+| 複数の状態間に「常に一致すべき」不変条件がある | REJECT |
+| 保存・送信・差分判定が派生値に依存している | REJECT |
+| 正規状態だけを保持し、派生値は利用箇所や境界で生成している | OK |
+
+## 未完成コード
+
+TODO/FIXME、空実装、スタブ、コメントアウトされた旧実装を、完成した実装の代わりに残さない。今必要な処理は今実装し、不要な処理は削除する。
+
+| 基準 | 判定 |
+|------|------|
+| Issue番号・外部制約・除去条件のない TODO/FIXME | REJECT |
+| 認可、バリデーション、永続化、エラー処理を TODO で先送りしている | REJECT |
+| 空実装、`return null`、`pass`、コメントアウトされた旧実装が残っている | REJECT |
+| 外部依存や既知バグにより今は実装不能で、Issue番号と除去条件が明記されている | 許容 |
+| 将来拡張のためだけの TODO | REJECT |
+
+## 機密情報の扱い
+
+パスワード、トークン、APIキー、セッションID、認証ヘッダ、個人情報などの機密情報をコード、ログ、エラーレスポンス、テスト出力に露出させない。
+
+| 基準 | 判定 |
+|------|------|
+| 機密情報をソースコードや設定ファイルにハードコードしている | REJECT |
+| ログ、例外、エラーレスポンス、テストスナップショットに機密情報が含まれる | REJECT |
+| リクエストやDTO全体をログ出力し、機密フィールドが混入しうる | REJECT |
+| 機密フィールドを明示的に除外またはマスクしている | OK |
+| デバッグログに個人情報が含まれるが本番では無効化される想定 | 警告。設定ミスで露出しないか確認 |
 
 ## エラーハンドリング
 
@@ -486,10 +567,11 @@ function replaceFacetRefs(text: string): string {
 - **フォールバックは原則禁止** - `?? 'unknown'`、`|| 'default'`、`try-catch` で握りつぶすフォールバックを書かない。エラーは上位に伝播させる。どうしても必要な場合はコメントで理由を明記する
 - **説明コメント** - コードで意図を表現する。What/How のコメントは書かない
 - **未使用コード** - 「念のため」のコードは書かない
+- **未完成コード** - Issue番号・外部制約・除去条件のない TODO/FIXME、空実装、コメントアウト旧実装を残さない
 - **any型** - 型安全を破壊しない
 - **オブジェクト/配列の直接変更** - スプレッド演算子で新規作成
 - **console.log** - 本番コードに残さない
-- **機密情報のハードコーディング**
+- **機密情報の露出** - ハードコード、ログ、エラーレスポンス、テスト出力に機密情報を含めない
 - **契約文字列のハードコード散在** - ファイル名・設定キー名は定数で1箇所管理。リテラルの散在は禁止
 - **各所でのtry-catch** - エラーは上位層で一元処理
 - **後方互換・Legacy対応の自発的追加** - 明示的な指示がない限り不要
@@ -497,6 +579,6 @@ function replaceFacetRefs(text: string): string {
 - **リファクタリング後の旧コード残存** - 置き換えたコード・エクスポートは削除する。明示的に残すよう指示されない限り残さない
 - **安全機構を迂回するワークアラウンド** - 根本修正が正しいなら追加の迂回は不要
 - **プロジェクトスクリプトを迂回するツール直接実行** - `npx tool` 等の直接実行は lockfile を迂回しバージョン不一致を起こす。プロジェクトが定義したスクリプト（npm scripts, Makefile 等）を探して使う。見つからない場合のみ直接実行を検討する
-- **配線忘れ** - 新しいパラメータやフィールドを追加したら、grep で呼び出しチェーン全体を確認する。呼び出し元が値を渡していないと `options.xxx ?? fallback` で常にフォールバックが使われる
+- **配線忘れ** - 新しいパラメータやフィールドを追加したら、呼び出しチェーン全体を検索して確認する。呼び出し元が値を渡していないと `options.xxx ?? fallback` で常にフォールバックが使われる
 - **冗長な条件分岐** - if/else で同一関数を呼び出し引数の差異のみの場合、三項演算子やスプレッド構文で統一する
-- **コピペパターン** - 新しいコードを書く前に同種の既存実装を grep で確認し、既存パターンに合わせる。独自の書き方を持ち込まない
+- **コピペパターン** - 新しいコードを書く前に同種の既存実装を検索し、既存パターンに合わせる。独自の書き方を持ち込まない

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 |
+
+## 完了前確認
+
+完了前に、全差分を「必須変更」「関連変更」「不要変更」に分類する。不要変更が残っている場合は完了してはならない。
+
+| 分類 | 基準 |
+|------|------|
+| 必須変更 | これがないと要求を満たせない |
+| 関連変更 | 必須変更を接続、検証、整合させるために必要 |
+| 不要変更 | 読みやすさ、作法、ついで整理、将来拡張だけが理由 |

package/builtins/ja/facets/policies/qa.md

@@ -22,7 +22,9 @@
 
 | パターン | 判定 |
 |---------|------|
-| TODO/FIXMEの放置 | 警告 |
+| Issue番号・外部制約・除去条件のない TODO/FIXME | REJECT |
+| Issue番号・外部制約・除去条件がある TODO/FIXME | 警告 |
+| 空実装、スタブ、コメントアウトされた旧実装の放置 | REJECT |
 | 理由なしの @ts-ignore, @ts-expect-error | 警告 |
 | 理由なしの eslint-disable | 警告 |
 | 非推奨APIの使用 | 警告 |

package/builtins/ja/facets/policies/review.md

@@ -10,7 +10,7 @@
 | 曖昧さ排除 | 「もう少し整理して」等の曖昧な指摘は禁止。ファイル・行・修正案を具体的に示す |
 | ファクトチェック | 推測ではなく実コードを確認してから指摘する |
 | 実践的修正案 | 理想論ではなく実装可能な対策を提示する |
-| ボーイスカウト | 変更したファイルに問題があれば、タスクスコープ内で改善させる |
+| ボーイスカウト | 変更箇所と、その正しさ・契約・配線に直接関係する箇所の問題をタスクスコープ内で改善させる |
 
 ## スコープ判定
 
@@ -18,9 +18,10 @@
 |------|------|------|
 | 今回の変更で導入された問題 | ブロッキング | REJECT |
 | 今回の変更により未使用になったコード（引数、import、変数、関数） | ブロッキング | REJECT（変更起因の問題） |
-| 変更ファイル内の既存問題 | ブロッキング | REJECT（ボーイスカウトルール） |
-| 変更モジュール内の構造的問題 | ブロッキング | スコープ内なら REJECT |
+| 変更箇所・関係箇所の既存問題 | ブロッキング | REJECT（ボーイスカウトルール） |
+| 変更の正しさに直接影響する構造的問題 | ブロッキング | スコープ内なら REJECT |
 | 変更外ファイルの問題 | 非ブロッキング | 記録のみ（参考情報） |
+| 同じ変更ファイル内にあるだけで変更の正しさに直接関係しない既存問題 | 非ブロッキング | 記録のみ（参考情報） |
 | タスクスコープを大きく逸脱するリファクタリング | 非ブロッキング | 提案として記載 |
 
 ## 判定基準
@@ -37,13 +38,15 @@
 - 未使用コード（「念のため」のコード）
 - オブジェクト/配列の直接変更
 - エラーの握りつぶし（空の catch）
-- TODO コメント（Issue化されていないもの）
+- Issue番号・外部制約・除去条件のない TODO/FIXME
 - 本質的に同じロジックの重複（DRY違反）
 - 同じことをするメソッドの増殖（構成の違いで吸収すべき）
 - 特定実装の汎用層への漏洩（汎用層に特定実装のインポート・分岐がある）
 - 内部実装のパブリック API エクスポート（インフラ層の関数・内部クラスが公開されている）
 - リファクタリングで置き換えられた旧コード・旧エクスポートの残存
 - 関連フィールドのクロスバリデーション欠如（意味的に結合した設定値の不変条件が未検証）
+- 契約変更後の呼び出し元・生成元・テストデータの更新漏れ
+- ログ、エラーレスポンス、テスト出力への機密情報露出
 
 DRY違反の修正案は、単に共通化を求めるだけでは不十分とする。以下を満たさない共通化案は不適切であり、別案を検討する。
 
@@ -59,7 +62,7 @@ DRY違反の修正案は、単に共通化を求めるだけでは不十分と
 - テストが実装の詳細に依存
 - 関数/ファイルが複雑すぎる
 - 命名が不明確
-- TODO/FIXME の放置（Issue番号付きは許容）
+- Issue番号・外部制約・除去条件がある TODO/FIXME
 - 理由なしの `@ts-ignore`、`eslint-disable`
 
 ### APPROVE（承認）
@@ -73,7 +76,7 @@ DRY違反の修正案は、単に共通化を求めるだけでは不十分と
 | やるべきこと | やってはいけないこと |
 |-------------|-------------------|
 | ファイルを開いて実コードを確認 | 「修正済みのはず」と思い込む |
-| grep で呼び出し元・使用箇所を検索 | 記憶に基づいて指摘する |
+| 呼び出し元・使用箇所を検索 | 記憶に基づいて指摘する |
 | 型定義・スキーマを突合 | 推測でデッドコードと判断する |
 | 生成ファイル（レポート等）とソースを区別 | 生成ファイルをソースコードとしてレビュー |
 | ツール出力が正常に読めることを確認 | 文字化け・異常文字を含む出力に基づいて指摘する |
@@ -175,19 +178,20 @@ DRY違反の修正案は、単に共通化を求めるだけでは不十分と
 
 ### 対象
 
-- 変更したファイル内の既存の問題（未使用コード、不適切な命名、壊れた抽象化）
-- 変更したモジュール内の構造的な問題（責務の混在、不要な依存）
+- 変更箇所、および変更の正しさ・契約・配線に直接影響する関係箇所の既存問題（未使用コード、不適切な命名、壊れた抽象化）
+- 変更の正しさに直接影響する構造的な問題（責務の混在、不要な依存）
 
 ### 対象外
 
 - 変更していないファイル（既存問題として記録のみ）
+- 同じ変更ファイル内にあるだけで、変更の正しさ・契約・配線に直接影響しない既存問題
 - タスクスコープを大きく逸脱するリファクタリング（提案として記載、非ブロッキング）
 
 ### 判定
 
 | 状況 | 判定 |
 |------|------|
-| 変更ファイル内に明らかな問題がある | REJECT — 一緒に修正させる |
+| 変更箇所・関係箇所に明らかな問題がある | REJECT — 一緒に修正させる |
 | 冗長な式（同値の短い書き方がある） | REJECT |
 | 不要な分岐・条件（到達しない、または常に同じ結果） | REJECT |
 | 数秒〜数分で修正可能な問題 | REJECT（「非ブロッキング」にしない） |
@@ -198,15 +202,24 @@ DRY違反の修正案は、単に共通化を求めるだけでは不十分と
 
 ## 判定ルール
 
-- 変更対象ファイル内で検出した問題は、既存コードであっても全てブロッキング（REJECT対象）として扱う
-- 「既存問題」「非ブロッキング」に分類してよいのは、変更対象外のファイルの問題のみ
-- 「コード自体は以前から存在していた」は非ブロッキングの理由にならない。変更ファイル内にある以上、ボーイスカウトルールが適用される
+- 変更箇所、および変更の正しさ・契約・配線に直接影響する関係箇所で検出した問題は、既存コードであってもブロッキング（REJECT対象）として扱う
+- 「既存問題」「非ブロッキング」に分類してよいのは、変更と直接関係しない箇所の問題のみ
+- 「コード自体は以前から存在していた」は、変更箇所・関係箇所の問題を非ブロッキングにする理由にならない
 - 問題が1件でもあればREJECT。「APPROVE + 警告」「APPROVE + 提案」は禁止
 
 ## レビューの基本手順
 
 全レビュアーが共通して踏むべき手順を定義する。各 instruction で個別に書かない。
 
+### 差分の基準点（ベースを固定する）
+
+レビュー対象は、タスク開始時点（ベース）からの累積差分全体とする。直前イテレーションの修正分だけを対象にしない。
+
+- fix ↔ review のループでは、毎回ベースから差分を取り直して全体を評価する。基準点を直近の修正へ動かさない
+- ベースは統合先ブランチとのマージベース、または `plan` / `order` に記録された起点とする。`Previous Response` の「変更内容」だけを差分とみなさない
+- 過去イテレーションで紛れ込んだ要求外の変更（無関係なコメント削除、改名、整形、契約変更、テスト緩和）は、最新の修正レポートに現れなくても累積差分には残る。毎回これを照合する
+- finding の状態追跡（new / persists / resolved）は基準点を固定した前提で行う。差分基準を狭めて「もう差分に無い」と判断しない
+
 ### 一次情報の参照
 
 - `order.md`、`plan.md`、実コードを一次情報として参照する

package/builtins/ja/facets/policies/testing.md

@@ -11,6 +11,7 @@
 | 振る舞いを検証 | 実装の詳細ではなく振る舞いをテストする |
 | 独立性 | 他のテストや実行順序に依存しない |
 | 再現性 | 時間やランダム性に依存せず、毎回同じ結果 |
+| 非実行資産を固定しない | 実行時の振る舞いを定義しない本文や章構成を CI の失敗条件にしない |
 
 ## カバレッジ基準
 
@@ -32,6 +33,23 @@
 
 **注意:** デザイン参照が指定されている場合、UIの見た目の検証は中優先度に格上げする。デザイン忠実再現ポリシーを参照。
 
+## 非実行資産のテスト
+
+説明文、ガイド、README、Markdown ドキュメントなど、実行時の振る舞いを定義しない非実行資産の本文・見出し・構成を固定するテストは原則禁止。
+これらは表現改善や整理で頻繁に変わるため、本文差分を CI 失敗条件にすると保守コストが高くなる。
+
+| 基準 | 判定 |
+|------|------|
+| 非実行資産の本文・見出し・章構成の一致検証 | REJECT |
+| 表記ゆれ検出だけを目的に非実行資産全体を走査するテスト | REJECT |
+| 削除・統合され得る説明ファイルの存在前提テスト | REJECT |
+| 実行契約を持たない docs-only 変更にテストを追加する | REJECT |
+| CLI例・設定例・生成物など、実行可能または機械処理される契約の検証 | OK |
+| schema、設定、コード、生成器など実行時挙動に関わる契約検証 | OK |
+| 実行契約を持たない docs-only 変更でテストを追加しない判断 | OK |
+
+非実行資産の変更確認は、必要に応じてレビュー、Markdown lint、リンクチェック、サンプルコマンドの実行で行う。
+
 ## テスト構造: Given-When-Then
 
 ```typescript
@@ -57,6 +75,18 @@ test('ユーザーが存在しない場合、NotFoundエラーを返す', async
 | 明確性 | 失敗時に原因が分かる | 失敗しても原因不明 |
 | 焦点 | 1テスト1概念 | 複数の関心事が混在 |
 
+## テストデータとフィクスチャ
+
+テストデータは、テストごとに必要最小限の事実を明示して生成する。共有フィクスチャの破壊的変更や、実契約と異なるモックはテストの信頼性を下げる。
+
+| 基準 | 判定 |
+|------|------|
+| テスト間で共有する fixture を変更して使い回している | REJECT |
+| モック、fixture、factory が実際の型・API契約と異なる形を返している | REJECT |
+| テストごとに巨大な全項目 fixture を直書きしている | 警告。factory 化を検討 |
+| factory でデフォルトを用意し、テストに関係するフィールドだけ上書きしている | OK |
+| 契約変更時に fixture、mock、snapshot を同じ変更で更新している | OK |
+
 ### 命名
 
 テスト名は期待される振る舞いを記述する。`should {期待する振る舞い} when {条件}` パターンを使う。
@@ -125,8 +155,11 @@ DataGrid、日付ピッカー、仮想リスト、チャートなど、外部 UI
 
 ## E2Eテスト基準
 
+E2E は、利用者が実際に入る起点から設計する。ドキュメント上の想定だけでなく、route、command、endpoint、navigation、button、external callback などコード上の入口を基準にする。
+
 | 基準 | 判定 |
 |------|------|
+| 起点を確認せず、想像上の操作フローだけで E2E を書いている | REJECT |
 | 外部API呼び出しをモックせず本番APIを叩く | REJECT。テストの再現性が失われる |
 | テスト対象のコア処理をモックする | REJECT。E2Eの意味がなくなる |
 | 固定 sleep でタイミングを合わせる | REJECT。状態ベースの待機を使う |

package/builtins/ja/workflow-categories.yaml

@@ -19,6 +19,7 @@ workflow_categories:
     workflows:
       - frontend
       - frontend-mini
+      - frontend-maintenance
   ⚙️ バックエンド:
     workflows:
       - backend

package/builtins/ja/workflows/auto-improvement-loop.yaml

@@ -117,7 +117,11 @@ steps:
       - type: enqueue_task
         mode: new
         workflow: takt-default
-        base_branch: improve
+        base_branch:
+          name: improve
+          create_if_missing:
+            from: main
+            push: true
         task: "{structured:plan_from_issue.task_markdown}"
         issue: "{structured:plan_from_issue.issue}"
         worktree:
@@ -187,7 +191,11 @@ steps:
       - type: enqueue_task
         mode: new
         workflow: takt-default
-        base_branch: improve
+        base_branch:
+          name: improve
+          create_if_missing:
+            from: main
+            push: true
         task: "{structured:plan_fresh_improvement.task_markdown}"
         issue: "{structured:plan_fresh_improvement.issue}"
         worktree:
@@ -255,7 +263,11 @@ steps:
         mode: from_pr
         pr: "{context:route_context.selected_pr.number}"
         workflow: takt-default
-        base_branch: improve
+        base_branch:
+          name: improve
+          create_if_missing:
+            from: main
+            push: true
         task: "{structured:plan_from_existing_pr.task_markdown}"
     rules:
       - when: effect.enqueue_from_pr.enqueue_task.success == true
@@ -296,7 +308,11 @@ steps:
         mode: from_pr
         pr: "{context:route_context.selected_pr.number}"
         workflow: takt-default
-        base_branch: improve
+        base_branch:
+          name: improve
+          create_if_missing:
+            from: main
+            push: true
         task: |
           PR の base branch 取り込み時に発生したコンフリクトを解消すること。
           対象 PR: {context:route_context.selected_pr.number}