takt 0.50.0 → 0.51.0

package/builtins/ja/facets/instructions/fix.md

@@ -4,6 +4,10 @@ ledger がない場合は、Report Directory内のレビューレポートを確
 **修正の原則:**
 - 指摘の「修正案」が示されている場合はそれに沿った対応を優先し、独自の迂回策を取らない
 - 指摘の対象コードを直接修正すること。テストやドキュメントの追加で指摘を回避しない
+- ledger がある場合、異議を申し立ててよいのは、指摘が現在のコードと矛盾する、またはこのステップの責務外で構造的に解消不能な場合だけ。無理に修正したことにせず、具体的な反証と file:line を添えて `## Disputed Findings` へ正式に異議を申し立てること（形式は Finding Contract の指示に従う）。異議申告は裁定待ちであり、resolved / waived を意味しない
+  - 一時的なツール失敗・作業の難しさ・不確実さを異議の理由にしない
+  - 「意図的なトレードオフ」を理由にできるのは、既存仕様やユーザー決定の証拠がある場合だけ
+- ledger がない場合は異議申告の機構が存在しないため使わない。修正不能な指摘は「修正した」と書かず、blocker として作業結果に明記すること
 
 **レポート参照方針:**
 - parse 可能な Finding Contract の ledger summary / `findings-ledger.json` がある場合は、何を修正するかを決める唯一の正本として統合 ledger を参照してください。
@@ -14,14 +18,16 @@ ledger がない場合は、Report Directory内のレビューレポートを確
 - 過去イテレーションのレポートは `{ファイル名}.{タイムスタンプ}` 形式で同ディレクトリに保存されています（例: `architect-review.md.20260304T123456Z`）。各レポートについて `{レポート名}.*` パターンで Glob を実行し、タイムスタンプ降順で最大2件まで読み、persists / reopened の傾向を把握してから修正に入ること。
 
 **完了条件（以下をすべて満たすこと）:**
-- 今回受け取った open findings（`new` / `persists` / `reopened`）をすべて修正したこと
-- 同一 `family_tag` の潜在箇所を同時に修正したこと（部分修正で再発させない）
-- `family_tag` ごとに最低1件の再発防止テストを追加したこと（config契約/境界チェック系は必須）
+- ledger がある場合: 今回受け取った open findings（`new` / `persists` / `reopened`）を、すべて修正するか、証拠を添えて `## Disputed Findings` へ異議を申し立てたこと。この2つだけが正式な処理結果であり、どちらでもない finding を残さないこと
+- ledger がない場合: 修正できた指摘はすべて修正し、修正不能な指摘は「修正した」と書かず blocker として作業結果に明記したこと
+- 修正した finding について、同一 `family_tag` の潜在箇所を同時に修正したこと（部分修正で再発させない）
+- 修正した finding のうち、コード上の欠陥を適切な層の自動テストで検証できるものについて、`family_tag` ごとに最低1件の再発防止テストを追加したこと（config契約/境界チェック系は必須）。意味のある自動テストが作れない場合は、理由と検証手順（実行したコマンドと結果）を作業結果に書くこと。ファイルの存在確認のようなメタテストで完了条件を満たしたことにしない。異議を申し立てた finding にはテストを書かない
 - 複数レビュアーから同一 `family_tag` の指摘が届いている場合は1件に統合して対応したこと
 
 **重要**: 修正後、ビルド（型チェック）とテストを必ず実行してください。
 
 **必須出力（見出しを含める）**
+異議を申し立てた finding がある場合は、`## Disputed Findings` を含めること（形式は Finding Contract の指示に従う）。
 ## 作業結果
 - {実施内容の要約}
 ## 変更内容

package/builtins/ja/facets/instructions/loop-monitor-reviewers-fix.md

@@ -12,4 +12,11 @@ ledger がない場合は Report Directory 内の最新レビューレポート
 - ledger は存在するが incomplete な場合は、mapped findings は ledger に従い、unmapped raw findings は findings-manager reconciliation 待ちの potential new entries として扱う
 - ledger がない、unreadable、または unparseable の場合は、Report Directory 内の最新レビューレポートを primary evidence として扱う
 - 修正が実際にコードに反映されているか
+  - 修正は反映済みなのに同じ指摘が続く（指摘が現状コードと乖離している）場合、
+    行き詰まりの原因はコードではなく指摘の側にある。この場合は異議申告
+    （dispute → manager 裁定 → waive）という打開手段が残っているため、
+    「再計画で打開できる」と判断して計画への差し戻しを選ぶこと
 - new / reopened の指摘件数が全体として減少傾向にあるか
+
+打ち切り（ABORT）を選ぶのは、修正・再計画・異議申告のどの手段でも打開できないと
+判断できる場合だけにしてください。

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

@@ -106,6 +106,17 @@ Vertical Slice の判定基準:
 - エラーハンドリングが一元化されているか（各所でtry-catch禁止）
 - ビジネスロジックがController/Viewに漏れていないか
 
+**プロトコル境界の例外変換**
+
+HTTP、CLI、GraphQL、message consumer などの adapter は、内部例外を外部プロトコルの表現へ変換する境界である。endpoint や handler ごとに同じ try-catch / response 変換を散在させると、ステータス、エラー形状、ログ、認可失敗の扱いが不整合になりやすい。例外変換は adapter 境界の専用レイヤに集約し、真に横断的な変換だけを global handler に置く。
+
+| 基準 | 判定 |
+|------|------|
+| endpoint / handler ごとに同じ例外から同じプロトコル表現への変換を実装している | REJECT |
+| プロトコル表現への変換が application/domain 層に入っている | REJECT |
+| 特定 API 固有の例外変換を全 API 共通の global handler に置いている | REJECT |
+| adapter 境界の例外変換レイヤで、外部表現への変換を一元化している | OK |
+
 ## 境界での解決
 
 設定、Option、provider、権限、パスのような値は、境界で解決してから内部へ渡す。メイン処理は「何が解決済みか」を前提に組み立て、各所で設定ソースを問い合わせない。

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

@@ -62,6 +62,7 @@ data class Order(
 | Controller から Repository を直接参照 | REJECT。UseCase層を経由 |
 | ドメイン層から外向きの依存（DB, HTTP等） | REJECT |
 | adapter 間の直接依存（inbound → outbound） | REJECT |
+| application / domain 層の型や識別子が、HTTP request/response、endpoint、status code 等のプロトコル固有の意味を持つ | REJECT。境界でユースケースの概念へ変換する。ドメイン上の語彙として Request 等を含むだけなら違反ではない |
 
 ## API層設計（Controller）
 
@@ -208,6 +209,37 @@ fun confirm(confirmedBy: String): OrderConfirmedEvent {
 | 構造バリデーション（@NotBlank等）がドメインにある | REJECT。API層で |
 | UseCase層のバリデーションがAggregate内にある | REJECT。Read Model参照はUseCase層 |
 
+### 入口バリデーションの所有権
+
+同一の入口制約は一つの所有者と実行機構に寄せる。層ごとに目的が異なる検証は重複ではないが、同じ境界・同じ条件を複数方式で再実装しない。宣言的検証が有効な構成では、不正入力は処理本体より前に拒否される。後段の手書きチェックは正常入力では到達するが、同じ条件を冗長に再評価するだけで、違反時の応答を決定できない。宣言的検証が実際に有効かどうかはフレームワークの構成に依存するため、確認したうえで実効的な所有者を一つにする。
+
+```kotlin
+// NG - 同じ制約の二重実装。違反時の応答は宣言的検証が所有する
+@GetMapping("/orders/{id}")
+fun get(@PathVariable @Size(max = MAX_ID) id: String): OrderResponse {
+    requireIdWithinLimit(id)  // 正常入力でのみ実行され、違反時の応答は決定できない
+    return orderReadService.get(id).toResponse()
+}
+
+// OK - 宣言に一本化し、手続き的チェックを削除
+@GetMapping("/orders/{id}")
+fun get(@PathVariable @Size(max = MAX_ID) id: String): OrderResponse =
+    orderReadService.get(id).toResponse()
+```
+
+Spring の例では、`@PathVariable` や `@RequestParam` のようなスカラー引数の制約は method validation が有効な前提で機能する。古い構成では Controller クラスへの `@Validated` が必要になることが多く、Spring 6.1+ では構成に応じて組み込みの method validation を使える。
+
+検証違反時の応答は、自前の例外階層の外でフレームワーク既定の変換に落ちることがある（400 へ変換する構成もあれば、未変換のまま 500 になる構成もある）。既定の変換を使うこと自体ではなく、明示した API 契約（ステータス・応答形状）と一致しているかで判定する。違反時に投げられる例外の型は構成やバージョンに依存するため推測せず、統合テストで実際に飛ぶ例外と応答を固定する。変換の配置は「例外変換のスコープ」に従う。
+
+| 基準 | 判定 |
+|------|------|
+| 同じ入口・同じ条件を複数の検証機構で実装している | REJECT。実効的な所有者を一つにし、到達不能な側を削除する |
+| 検証違反時のステータス・応答形状が明示した API 契約と一致していない（契約を定義せず既定の変換へ暗黙に依存している場合を含む） | REJECT。契約を明示し、変換を整備する |
+| 検証違反時のステータスと応答形状を固定するテストがない | REJECT。実際に飛ぶ例外型を統合テストで確認 |
+| 同じ信頼境界・同じ入力契約を持つ入口間で検証方針が不統一 | REJECT。差異の理由を明示するか方針を統一する |
+| 外部エラー契約が実行環境のデフォルトロケールのメッセージに依存している | REJECT。安定したエラーコードまたは明示メッセージを契約にする |
+| 制約値（最大長等）を検証と API 仕様が単一の定数で共有している | OK |
+
 ### 読み取りと書き込みの入口
 
 読み取りと書き込みは入口で分離する。読み取り用の問い合わせ層は副作用を持たず、書き込みはコマンドまたはUseCaseで扱う。
@@ -259,6 +291,7 @@ class OrderExceptionHandler {
 | 汎用的な Exception や RuntimeException を throw | REJECT。具体的な例外型を使う |
 | try-catch の空 catch | REJECT |
 | Controller 内で例外を握りつぶして 200 を返す | REJECT |
+| 実際に到達し得る呼び出しパターン（別ロールの呼び出し者等）を 500 で表現する | REJECT。4xx で明示し、「到達しない」前提は認可で保証する |
 
 ### 例外変換のスコープ
 
@@ -270,6 +303,7 @@ HTTPステータスへの例外変換は、HTTP adapter 境界の例外変換レ
 | 特定 API 固有の例外変換を global handler に追加する | スコープ過大。対象 API の境界へ閉じる |
 | 認証失敗、入力検証、共通エラー形状など全 API 共通の変換 | OK。global な境界で扱う |
 | 例外型から HTTP 表現への変換が application/domain 層にある | REJECT。HTTP adapter 境界で扱う |
+| 同じ例外型を複数の変換レイヤが扱い、適用範囲・優先順位が契約化されていない | REJECT。単一の所有者へ寄せるか、非重複の適用条件を明示する |
 
 ## ドメインモデル設計
 
@@ -384,6 +418,18 @@ data class OrderEntity(
 | Entity に ビジネスロジック | REJECT。Entity はデータ構造のみ |
 | Repository 実装がドメイン層にある | REJECT。adapter/outbound に |
 
+### 構造化属性の永続化境界
+
+relational / Read Model 永続化の構造化属性は、現在の検索要件だけでなく、更新単位、整合性、サイズ、スキーマ進化を基準に保存形式を選ぶ。ドメイン型の汎用シリアライズ結果を暗黙の永続化契約にせず、永続化専用の表現または明示的な変換を使う。イベントストアの型識別子と payload は、明示的かつバージョン管理されたシリアライズ契約としてよい。その進化は CQRS-ES の互換性・upcaster 規則に従う。
+
+| 基準 | 判定 |
+|------|------|
+| 全体を一括で読み書きし、検索・結合・参照整合性・部分更新が不要な有界の構造 | 構造化カラム（JSON等）を検討 |
+| 参照整合性、独立したライフサイクル、他テーブルとの結合が重要 | 別テーブルへ正規化 |
+| 必要な検索・索引・部分更新を DB の構造化カラム機能（jsonb 等）が保証でき、整合性要件も満たせる | 構造化カラムも選択可 |
+| ドメイン型を汎用シリアライザで直接変換し、フィールド名を DB スキーマとして暗黙利用している | REJECT。永続化専用の表現または明示的な変換を挟む |
+| 保存済み構造のフィールド変更に対して、互換読み取り・移行・再構築のいずれの経路も選ばれておらず、テストもない | REJECT。いずれかの経路を選びテストで固定する |
+
 ## 認証・認可の配置
 
 認証・認可は横断的関心事として適切な層で処理する。
@@ -414,6 +460,34 @@ fun execute(input: DeleteInput, currentUserId: String) {
 | 認可ロジックが UseCase 層やドメイン層にある | REJECT。Controller層で |
 | データアクセス制御が Controller にある | REJECT。UseCase層で |
 | 認証処理が Controller 内にある | REJECT。Filter/Interceptor で |
+| Application 層のサービスがセキュリティコンテキスト（現在ユーザーの解決等）を直接読む | REJECT。境界で解決し引数で渡す |
+| 同じ認可チェックが Controller と下位層で重複している | REJECT。責務を一箇所へ一本化 |
+
+## 呼び出し者とドメイン上のアクターの区別
+
+API の呼び出し者（認証主体）と、記録に残す業務上のアクター（担当者・作成者・確定者）は別の概念として扱う。取り込み・代理操作・管理経路では両者が一致しない。
+
+| 基準 | 判定 |
+|------|------|
+| 呼び出し者を無条件に業務上の担当者として記録する | 警告。取り込み・代理・管理経路で破綻しないか確認 |
+| 作成時の呼び出し者を、後続操作のアクターとして状態経由で流用する | REJECT。操作ごとに実行者を引数で渡す |
+| 業務上の担当者がまだ確定しない段階で担当者フィールドを必須にする | 警告。担当者が確定する操作（承認・確定等）の時点で記録できないか確認 |
+| 表示用に非正規化する氏名等を、その事実が確定する操作の境界で解決する | OK |
+| 呼び出し者がリソースの構成員である前提の解決処理を、構成員以外も通る経路に置く | REJECT |
+
+メモの作成者は「その操作をした本人」、確定者は「確定操作をした本人」のように、アクターは各操作の実行者から都度取得する。担当者のように後から確定する事実は、確定を表す操作・イベントの時点で記録し、作成時に無理に埋めない。
+
+```kotlin
+// NG - 作成時の呼び出し者を状態に保存し、後続操作のアクターとして流用
+fun addMemo(text: String): MemoAddedEvent {
+    return MemoAddedEvent(id, text, authorId = this.registeredBy)  // 登録者 ≠ メモ作成者
+}
+
+// OK - 操作ごとに実行者を受け取る
+fun addMemo(text: String, authorId: String): MemoAddedEvent {
+    return MemoAddedEvent(id, text, authorId = authorId)
+}
+```
 
 ## テスト戦略
 

package/builtins/ja/facets/knowledge/cqrs-es.md

@@ -52,6 +52,7 @@ Command Model（Aggregate）の役割は「コマンドを受けて判断し、
 | 判断に使わないフィールドを保持 | REJECT |
 | `source` / `input` / `origin` / `channel` / `type` などの由来メタデータで状態遷移を分岐 | 原則REJECT |
 | 既存Aggregateの通常ライフサイクルで許可される状態を、特定入力元だけ拒否 | REJECT |
+| 作成時の呼び出し者を Aggregate 状態に保持し、後続イベントのアクターとして流用 | REJECT。各コマンドで実行者を渡す |
 
 `if`/`require` に使われていることだけでは、Aggregate state に保持する根拠にならない。先に、その分岐や検証が Aggregate 全体の本質的な不変条件かを確認する。
 
@@ -266,6 +267,40 @@ OrderPlaced, PaymentReceived, ItemShipped
 OrderUpdated, OrderDeleted
 ```
 
+### 事実イベントと要求イベント
+
+イベントは発生した事実を表し、名前はその業務上の意味から決める。`〜Requested` という接尾辞や現在の消費者数だけでは、事実イベントか偽装コマンドかを判定できない。要求を受理・開始したこと自体が業務上の出来事なら事実になり得るが、既知の宛先へ処理を命令する以外の意味を持たない通知はコマンドとして表す。
+
+| 判断軸 | 事実イベント | コマンドを検討 |
+|--------|-------------|----------------|
+| 業務上の意味 | 受理・開始・却下など、監査や状態復元にも意味がある出来事 | 特定処理を実行させることだけが目的 |
+| 発行元のライフサイクル | 待機、重複拒否、期限切れ等の後続判断に使う | 発行元は結果や状態を追跡しない |
+| 結果 | 完了・失敗等の別の事実へ続く、不確実な処理 | 同一境界内で直ちに実行でき、結果もその場で扱える |
+| 消費者 | 増減してもイベントの意味が変わらない | 宛先と処理内容がイベントの意味そのもの |
+
+イベントは技術的な消費先ではなく、独立した業務上の事実を単位に分ける。同じ出来事を状態復元用と処理起動用に重複発行せず、発行元集約が所有する事実を EventHandler や Projection がそれぞれ購読する。複数のイベントが必要なのは、別々に命名・監査・再生する意味を持つ事実が同時に成立した場合である。別集約の内部状態や初期化詳細はイベントに詰め込まず、安定したIDや参照を境界側で解決する。
+
+```kotlin
+// NG - 1つの業務上の事実を、状態用と技術的な処理起動用に重複分割
+fun addItem(itemId: String, productId: String, quantity: Int): List<OrderEvent> = listOf(
+    OrderItemLinkedEvent(orderId, itemId),                 // 状態用
+    OrderItemCreationRequestedEvent(orderId, itemId, productId, quantity), // トリガー用（実質コマンド）
+)
+
+// OK - 発行元集約の事実として必要な内容を持つ単一イベント
+fun addItem(itemId: String, productId: String, quantity: Int): OrderItemAddedEvent =
+    OrderItemAddedEvent(orderId, itemId, productId, quantity)
+```
+
+| 基準 | 判定 |
+|------|------|
+| 接尾辞または現在の消費者数だけでイベント／コマンドを判定する | REJECT。業務上の意味とライフサイクルで判断する |
+| 同じ業務上の事実を、状態用（Linked 等）と処理起動用（Requested 等）に重複分割する | REJECT。発行元集約が所有する事実へ統合する |
+| 外部サービス・別コンテキストへの非同期依頼で、受理・待機が業務上の事実となり、完了/失敗を追跡する | OK。要求を受理した事実として表現できる |
+| 確定・承認などの既存事実イベントで表せる処理起動に、専用の要求イベントを追加する | REJECT。既存の事実を EventHandler（必要ならドメインポリシー）が購読する |
+| 他集約の状態だけが変わる出来事を、自分のストリームのイベントとして記録する | REJECT。事実はそれが起きた集約自身のストリームに積む |
+| 自分の状態やライフサイクルに関与しない操作を集約に経由させ、中継イベントで対象集約へ転送する | REJECT。対象集約へコマンドを送り、所属・存在確認は不変条件の所有境界で行う |
+
 ### sealed interface によるイベント型階層
 
 集約のイベントは sealed interface で型階層化する。集約ルートIDを共通フィールドとして強制し、`when` 式の網羅性チェックを有効にする。
@@ -370,6 +405,20 @@ CQRS+ES の migration は、DB schema migration、data migration、event upcaste
 | ハンドラが複数Aggregateを変更 | REJECT |
 | コマンドのバリデーションがない | REJECT |
 | ハンドラがクエリを実行して判断 | 要検討 |
+| 操作が生み得るイベント数と戻り値の契約が一致しない | 要検討。単一・任意・複数・結果型のどれを使うかは、ドメイン上の多重度と言語・フレームワークの規約で決める |
+
+### コマンドとイベントの契約寿命
+
+イベントは履歴として永続化される長寿命の契約であり、保存済みの型識別子と payload を再生できなければならない。型識別子が完全修飾名か論理名か、変更時に upcaster・alias・migration のどれを使うかは、イベントストアとシリアライズ方式で決まる。
+
+コマンドは通常、application 境界で生成・処理される短寿命のメッセージだが、予約実行、outbox、再試行、dead-letter、監査等で永続化される構成もある。配置と互換性は「コマンドだから一時的」と決め打ちせず、責務と実際の保存契約で判断する。ドメインモデルは配送方式やフレームワークのコマンド型に依存せず、application / adapter 境界でドメインの引数・値オブジェクトへ変換する。
+
+| 基準 | 判定 |
+|------|------|
+| ドメインモデルが配送・フレームワーク固有のコマンド型を直接受け取る | REJECT。application / adapter 境界でドメインの入力へ変換する |
+| domain 層から参照されない application メッセージを domain パッケージに置く | application 境界へ移す |
+| コマンドの移動・改名時に、永続参照の有無を確認せず互換性不要と判断する | REJECT。予約・outbox・再試行・dead-letter・監査等の保存契約を確認する |
+| イベントの型識別子や payload を、保存済みデータの変換経路なしで変更する | REJECT。利用する識別・シリアライズ方式に応じた互換経路を用意する。直接変更できるのは保存済みイベントがまだ存在しない場合だけであり、リリース状態では判断しない |
 
 良いコマンドハンドラ:
 ```

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

@@ -80,6 +80,8 @@ accessible name、role、state は支援技術とテストが参照する UI 契
 | 新しい操作要素に accessible name がない | REJECT |
 | チェック状態、展開状態、無効状態などの状態が支援技術へ公開されていない | 警告 |
 | 既存の accessible name を要求外で変更する | REJECT |
+| 動的な accessible name を断片の連結だけで組み立て、最終的な文の意味・自然さを確認していない | REJECT |
+| 同一の操作コンテキストにある別要素が、名前またはプログラム上の文脈（行・グループとの関連付け等）で識別できない | REJECT。対象名を accessible name に含めるのは識別の有力な手段 |
 | 既存の accessible name を保ち、不足していた role/state を追加する | OK |
 | 既存契約を変更する理由と影響範囲が明示されている | OK |
 
@@ -207,6 +209,7 @@ state にはユーザー入力、サーバーデータ、UIの一時状態など
 | 複数の state フィールド間に常時同期が必要な不変条件がある | REJECT |
 | 表示ラベル、件数、合計、全選択状態、並び替え結果、グルーピング結果を正規 state として保持している | REJECT |
 | API送信、保存、差分判定が正規 state ではなく派生 state に依存している | REJECT |
+| フィルタ・ページング・グルーピング後の表示位置の連番を、元データの順序番号として扱っている | REJECT。ラベルがどの集合の順序かを定義し、その集合から導出する |
 | 正規 state だけを保持し、表示・集計・判定は selector、render、useMemo で導出している | OK |
 | 外部契約で必要な派生値を、送信・保存の境界で正規 state から生成している | OK |
 
@@ -355,6 +358,7 @@ const OrderStatusWidget = ({ status }: { status: OrderStatus }) => {
 | 一覧APIのレスポンスを詳細画面でも使い回す | REJECT |
 | 一覧の表示単位とAPIの取得単位がずれている | REJECT |
 | 判定だけのために全件取得する（集計APIを使うべき） | REJECT |
+| UI が必要とする概念が応答に存在せず、意味の異なる本文・説明フィールドを暗黙に見出しへ流用している | REJECT。表示契約として要約・フォールバックを定義するか、専用フィールドを用意する |
 | 画面ごとに専用の取得口を持ち、必要なデータだけ返す | OK |
 
 ```tsx
@@ -411,7 +415,7 @@ ui/ と domain/ の判断基準: ドメイン用語がコンポーネント名
 
 ### 共有化の基準
 
-同じパターンのUIは共有コンポーネント化する。インラインスタイルのコピペは禁止。
+同じパターンのUIは共有コンポーネント化する。インラインスタイルのコピペは禁止。同じ役割・意味状態（プレースホルダー、無効、未確認等）を表す UI は、同じ共有コンポーネントまたは明示されたデザイン契約の中では文言・スタイル・読み上げを揃える。表示文脈（画面階層、密度、テーマ等）による表現差は許容するが、意味と操作契約は維持する。
 
 ```tsx
 // WRONG - インラインスタイルのコピペ

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

@@ -232,6 +232,7 @@ if (!safePath.startsWith(path.resolve(baseDir))) {
 | 書き込み操作でクライアント提供のテナントIDを使用 | REJECT |
 | テナントリゾルバーを使うエンドポイントに認可制御がない | REJECT |
 | ロール分岐の一部パスでテナント解決が未考慮 | REJECT |
+| エンドポイントの想定呼び出し者（ロール・トークン種別）に認証機構の適用範囲が及んでいない | REJECT |
 
 ### 読み書きの一貫性
 
@@ -277,6 +278,8 @@ fun getSettings(): SettingsResponse {
 
 ロール分岐があるエンドポイントでは、全パスでテナント解決が成功するか検証する。
 
+逆パターンにも注意する。特定ロール専用のエンドポイントを追加する場合、そのロールを認証する機構（フィルタ等）の適用範囲拡張と、ロール必須の認可制御を同じ変更で行う。認証機構の適用範囲外だと想定呼び出し者がそもそも認証されず、認可がないと想定外ロールが通ってしまう。
+
 ## OWASP Top 10 チェックリスト
 
 | カテゴリ | 確認事項 |

package/builtins/ja/facets/personas/coder.md

@@ -22,11 +22,11 @@
 - デザイン参照が指定されている場合、UIの見た目・構造・文言をデザインに一致させる。独自判断で追加・省略・変更しない
 - 作業は必ず指定されたプロジェクトディレクトリ内で行う（参照読みのみ外部可）
 
-**レビュワーの指摘は絶対。あなたの認識が間違っている。**
+**レビュー指摘を、記憶や推測だけで退けない。**
 - レビュワーが「未修正」と指摘したら、まずファイルを開いて事実確認
 - 「修正済みのはず」という思い込みを捨てる
-- 指摘された問題を全て Edit tool で修正する
-- 反論せず、まず従う
+- 妥当で、このステップに許可された操作で解消できる指摘は、全て Edit tool で修正する
+- 現在のコードを再検証せずに、失敗した修正を機械的に繰り返さない
 
 **AI の悪い癖を自覚する:**
 - 不確実なときにフォールバックで隠す → 禁止

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

@@ -232,6 +232,7 @@ AIは「改善」「標準化」「説明性向上」の名目で、要求と無
 | 新機能に必要な新しい契約の追加 | OK |
 | 既存契約を保ったまま不足情報を追加 | OK |
 | 契約変更の理由、影響範囲、移行方針が明示されている | OK |
+| 要求された変更が新たに生んだ表示・アクセシビリティ・テスト契約の破綻の修正 | OK。変更起因の整合修正でありスコープクリープではない |
 
 検証アプローチ:
 1. 差分内の文字列、属性、イベント名、戻り値、エラー文言、ログ形式を確認する

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

@@ -303,6 +303,17 @@ interface Channel {
 }
 ```
 
+### 依存の明示
+
+依存は役割と型が読める形で渡す。関数型引数を一律に禁止せず、安定した業務上の役割や外部依存を匿名のコールバックとして隠していないかで判定する。
+
+| パターン | 判定 |
+|---------|------|
+| 業務規則や外部照会が匿名のコールバックとして複数層を中継される | REJECT。役割に名前を付け、ポート・validator・サービス等の境界へ昇格する |
+| 関数型が業務上の役割を表す名前付きの型やポートとして定義されている | OK。依存の意味と差し替え境界が読める |
+| 層境界で値を局所的に補完・変換する関数を渡す | OK。責務が境界内に閉じ、別の層へ中継されない |
+| ロック・トランザクション・リソースのスコープを制御するブロックを渡す | OK。依存の密輸ではなく制御構造 |
+
 ### 抽象化の漏れ
 
 特定実装が汎用層に現れたら抽象化が漏れている。汎用層はインターフェースだけを知り、分岐は実装側で吸収する。
@@ -329,6 +340,8 @@ return storage.upload(file, options)
 | 副作用や実行頻度が読めない | 初期化、取得、更新のどれが起きるか名前から判断できない | REJECT |
 | 近接する API と区別できない | ラップ元や委譲先と同じ名前で、どちらの責務か読めない | REJECT |
 | 役割・効果で命名 | 実際に提供する値、状態変化、責務が名前から読める | OK |
+| 経路・由来サフィックスに対応する別経路が実在しない | 唯一の経路なのに FromRequest / ViaApi が付く | REJECT。サフィックスを外す。対の経路が消えたら命名も追随する |
+| 同種操作の並びで一部だけ命名規則が異なる | createXxxFromRequest / updateXxxFromRequest / deleteXxx | REJECT。揃える |
 
 ```typescript
 // REJECT - 名前は毎回副作用を起こすように読めるが、実体はメモ化アクセサ
@@ -362,6 +375,7 @@ function getResource(): Promise<Resource> {
 - 独自のstateを持つ → 分離
 - 50行超のUI/ロジック → 分離
 - 複数の責務がある → 分離
+- 独立した変更理由・責務・再利用単位を持つ定義 → 分離。小さな補助型の同居可否は、言語の慣習とファイルの凝集度で判断する
 
 ### 機能追加時の到達経路
 
@@ -459,8 +473,7 @@ async function createUser(data) {
 }
 
 // ✅ 上位層で一元処理
-// Controller/Handler層でまとめてキャッチ
-// または @ControllerAdvice / ErrorBoundary で処理
+// 境界の例外変換レイヤでまとめて処理
 async function createUser(data) {
   return await userService.create(data)  // 例外はそのまま上に投げる
 }
@@ -471,8 +484,20 @@ async function createUser(data) {
 | 層 | 責務 |
 |----|------|
 | ドメイン/サービス層 | ビジネスルール違反時に例外をスロー |
-| Controller/Handler層 | 例外をキャッチしてレスポンスに変換 |
-| グローバルハンドラ | 共通例外（NotFound, 認証エラー等）を処理 |
+| Application層 | 例外を握りつぶさず、必要な補償や再試行だけを明示的に扱う |
+| Adapter境界 | 例外をプロトコル固有のレスポンスや表示に変換 |
+| グローバルハンドラ | 認証、入力検証、共通エラー形状など横断的な例外だけを処理 |
+
+### HTTP 例外変換
+
+HTTP adapter / controller / handler は、endpoint ごとに例外を HTTP 表現へ変換しない。例外から HTTP ステータス、レスポンス本文、ヘッダへの変換は HTTP adapter 境界の例外変換レイヤへ集約する。
+
+| 基準 | 判定 |
+|------|------|
+| 各 endpoint が同じ try-catch や wrapper で例外を HTTP 表現に変換している | REJECT。HTTP adapter 境界の例外変換レイヤに分離 |
+| 特定 API 固有の例外変換を全 API 共通の global handler に追加する | REJECT。対象 API の境界に閉じる |
+| 認証、入力検証、共通エラー形状など真に横断的な変換だけを global handler で扱う | OK |
+| 例外型から HTTP 表現への変換が application/domain 層にある | REJECT。HTTP adapter 境界で扱う |
 
 ## 変換処理の配置
 
@@ -540,6 +565,8 @@ AIは同じ処理を異なる関数名で複数定義しがちである。
 |---------|-----|------|
 | 同一実装の別名関数 | `copyFacets()` と `placeFacetFiles()` が同じ処理 | REJECT |
 | 引数シグネチャが同一で本体も同一 | 2つの関数が同じパラメータを受け取り同じ処理を行う | REJECT |
+| public メソッドが同一シグネチャの private メソッドへ1:1委譲し、固有の公開契約・登録・デコレーター・認可・計測・副作用を持たない | 内部別名が実装へそのまま委譲する | REJECT。委譲先を昇格して統合 |
+| 1:1委譲する public メソッドが、安定 API またはフレームワーク登録・デコレーター・認可・計測の入口である | 外部契約を維持する公開境界が実装へ委譲する | OK。境界を維持し、役割を明示する |
 
 ```typescript
 // REJECT - 同じ実装が別名で存在

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

@@ -123,6 +123,7 @@ DRY違反の修正案は、単に共通化を求めるだけでは不十分と
 | 出力が文字化け・エンコーディング異常を含む | 文字化けを認識し、別の手段（ファイルを直接開く、行番号指定で該当箇所を読む）で正しい内容を取得してから判断する |
 | 検索コマンドで該当コードが見つからなかった | ファイルの該当行を直接読み、存在しないことを確認してから指摘する。検索失敗＝コード不在ではない |
 | 前回と同じ指摘を出す際に実コードを再確認していない | persists 判定前に必ず現在のコードを読む。前回の記憶で再指摘しない |
+| 検証タスクがキャッシュ・スキップ・設定不在により対象処理を実行していない | 合格の証拠にしない。実際に実行された検査と未検証の範囲を分けて記録する |
 
 ## 具体的な指摘の書き方
 
@@ -281,7 +282,7 @@ workflow レベルの `finding_contract` 設定がない場合は、以下の従
 
 - fix ↔ review のループでは、毎回ベースから差分を取り直して全体を評価する。基準点を直近の修正へ動かさない
 - ベースは統合先ブランチとのマージベース、または `plan` / `order` に記録された起点とする。`Previous Response` の「変更内容」だけを差分とみなさない
-- 過去イテレーションで紛れ込んだ要求外の変更（無関係なコメント削除、改名、整形、契約変更、テスト緩和）は、最新の修正レポートに現れなくても累積差分には残る。毎回これを照合する
+- 過去イテレーションで紛れ込んだ要求外の変更（無関係なコメント削除、改名、整形、契約変更、テスト緩和、ツール生成の環境依存差分 — バージョン刻印・再シリアライズ・意味を変えない並び替え）は、最新の修正レポートに現れなくても累積差分には残る。毎回これを照合し、要求との因果関係を確認する
 - finding の状態追跡（new / persists / resolved）は基準点を固定した前提で行う。差分基準を狭めて「もう差分に無い」と判断しない
 
 ### 一次情報の参照

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

@@ -91,6 +91,8 @@ test('ユーザーが存在しない場合、NotFoundエラーを返す', async
 | 再現性 | 毎回同じ結果 | 時間やランダム性に依存 |
 | 明確性 | 失敗時に原因が分かる | 失敗しても原因不明 |
 | 焦点 | 1テスト1概念 | 複数の関心事が混在 |
+| UI要素の同定 | role と accessible name の完全一致など、利用者が観測する契約で特定する | 広い部分一致、最初の一致、表示位置で対象を特定する |
+| 衝突ケース | 同じ表示文字列を持つ有効なデータでも対象を区別できることを検証する | フィクスチャの表示値を意図的にすべて異ならせ、衝突の可能性を隠す |
 
 ## 副作用・状態遷移のテスト
 
@@ -236,6 +238,7 @@ DataGrid、日付ピッカー、仮想リスト、チャートなど、外部 UI
 | 3つ以上のモジュールを横断するデータフロー | インテグレーションテスト必須 |
 | 新しいステータス／状態が既存のワークフローに合流する | 遷移フロー全体のインテグレーションテスト必須 |
 | 新しいオプションが呼び出しチェーンを通じて末端まで伝搬する | チェーン全体の結合テスト必須 |
+| ハンドラ・ミドルウェア・変換器の選択や優先順位が実行時の構成で決まる | 本番相当の構成でのインテグレーションテスト必須。限定構成（slice）のテストは、含めた構成の挙動しか証明しない |
 | 各モジュールのユニットテストが全てパスしている | ユニットテストのみで十分（上記に該当しない場合） |
 
 ## ユニットテスト基準

package/builtins/ja/workflows/backend-cqrs-for-local-llm.yaml

@@ -145,7 +145,7 @@ steps:
       - condition: 実装完了
         next: reviewers
       - condition: 実装を進められない（環境問題・情報不足）
-        next: ABORT
+        next: plan
 
   - name: reviewers
     tags:

package/builtins/ja/workflows/backend-for-local-llm.yaml

@@ -142,7 +142,7 @@ steps:
       - condition: 実装完了
         next: reviewers
       - condition: 実装を進められない（環境問題・情報不足）
-        next: ABORT
+        next: plan
 
   - name: reviewers
     tags:

package/builtins/ja/workflows/draft.yaml

@@ -49,7 +49,6 @@ steps:
     policy:
       - coding
       - testing
-    session: refresh
     knowledge:
       $param: impl_knowledge
     provider_options:

package/builtins/ja/workflows/dual-for-local-llm.yaml

@@ -148,7 +148,7 @@ steps:
       - condition: 実装完了
         next: reviewers
       - condition: 実装を進められない（環境問題・情報不足）
-        next: ABORT
+        next: plan
 
   - name: reviewers
     tags:

package/builtins/ja/workflows/dual.yaml

@@ -124,7 +124,6 @@ steps:
       - testing
       - design-fidelity
       - screen-api
-    session: refresh
     knowledge:
       - frontend
       - react

package/builtins/ja/workflows/frontend-for-local-llm.yaml

@@ -145,7 +145,7 @@ steps:
       - condition: 実装完了
         next: reviewers
       - condition: 実装を進められない（環境問題・情報不足）
-        next: ABORT
+        next: plan
 
   - name: reviewers
     tags:

package/builtins/ja/workflows/takt-default-for-local-llm.yaml

@@ -141,7 +141,7 @@ steps:
       - condition: 実装完了
         next: reviewers
       - condition: 実装を進められない（環境問題・情報不足）
-        next: ABORT
+        next: plan
 
   - name: reviewers
     tags:

package/builtins/ja/workflows/takt-default-refresh-all.yaml

@@ -118,7 +118,6 @@ steps:
     policy:
       - coding
       - testing
-    session: refresh
     knowledge:
       - takt
       - architecture

package/builtins/ja/workflows/takt-default-refresh-fast.yaml

@@ -117,7 +117,6 @@ steps:
     policy:
       - coding
       - testing
-    session: refresh
     knowledge:
       - takt
       - architecture

package/builtins/skill/references/yaml-schema.md

@@ -57,7 +57,7 @@ step 定義内では**キー名**で参照する（パスを直接書かない
   knowledge: architecture      # ナレッジキー（knowledge マップを参照、任意）
   edit: true                   # ファイル編集可否（必須）
   required_permission_mode: edit # 必要最小権限: edit / readonly / full（任意）
-  session: refresh             # セッション管理（任意）
+  session: refresh             # セッション管理: continue / refresh / compact（任意）
   pass_previous_response: true # 前の出力を渡すか（デフォルト: true）
   allowed_tools: [...]         # 許可ツール一覧（任意、参考情報）
   output_contracts: [...]      # 出力契約設定（任意）
@@ -65,6 +65,8 @@ step 定義内では**キー名**で参照する（パスを直接書かない
   rules: [...]                 # 遷移ルール（必須）
 ```
 
+`session` は通常の agent step と parallel sub-step でのみ指定できる。`continue` は保存済み session を resume し、`refresh` は resume せず開始する。`compact` は保存済み persona session を resume したうえで Phase 1 前だけ provider の圧縮 capability を呼び出す。report phase / status phase 前には圧縮しない。圧縮 capability がない provider ではそのまま続行し、圧縮失敗時は warning を出して未圧縮 session で続行する。
+
 複数ポリシー指定（配列）:
 
 ```yaml
@@ -126,6 +128,24 @@ step 定義内では**キー名**で参照する（パスを直接書かない
 
 **重要**: サブステップの `rules` は結果分類のための condition 定義のみ。`next` は無視される（親の rules が遷移先を決定）。
 
+### Finding Contract manager の provider/model
+
+`finding_contract.manager` は、Finding Manager 合成 step 専用の `provider` / `model` を指定できる。
+
+```yaml
+finding_contract:
+  ledger_path: .takt/findings/review.json
+  raw_findings_path: .takt/findings/review/raw
+  manager:
+    persona: findings-manager
+    instruction: findings-manager
+    output_contract: findings-manager
+    provider: codex
+    model: gpt-5.5
+```
+
+指定値は step レベル provider/model として扱われ、`provider_routing`、deprecated の `persona_providers.findings-manager`、workflow 既定値、解決済み入力より優先される。両方とも未指定の場合は通常の workflow step provider/model 解決を使う。`provider` だけを指定すると下位優先度の model fallback は停止し、明示 model が必須の provider では検証エラーになる。
+
 ### Finding Contract parallel の invalid manager output rule
 
 workflow に `finding_contract` がある場合、各 parallel 親 step は Finding Manager output が retry 後も意味論的に invalid な場合の制御先を宣言する必要がある。許可される rule は、選択優先順に `return: need_replan`（推奨）、`return: needs_fix`、非AIの `next: fix`。`ai("...")` で `fix` へ向かう rule は、この失敗経路では自動選択されない。該当 rule がない場合、workflow validation は実行前に失敗する。

package/builtins/skill-codex/references/yaml-schema.md

@@ -57,7 +57,7 @@ step 定義内では**キー名**で参照する（パスを直接書かない
   knowledge: architecture      # ナレッジキー（knowledge マップを参照、任意）
   edit: true                   # ファイル編集可否（必須）
   required_permission_mode: edit # 必要最小権限: edit / readonly / full（任意）
-  session: refresh             # セッション管理（任意）
+  session: refresh             # セッション管理: continue / refresh / compact（任意）
   pass_previous_response: true # 前の出力を渡すか（デフォルト: true）
   allowed_tools: [...]         # 許可ツール一覧（任意、参考情報）
   output_contracts: [...]      # 出力契約設定（任意）
@@ -65,6 +65,8 @@ step 定義内では**キー名**で参照する（パスを直接書かない
   rules: [...]                 # 遷移ルール（必須）
 ```
 
+`session` は通常の agent step と parallel sub-step でのみ指定できる。`continue` は保存済み session を resume し、`refresh` は resume せず開始する。`compact` は保存済み persona session を resume したうえで Phase 1 前だけ provider の圧縮 capability を呼び出す。report phase / status phase 前には圧縮しない。圧縮 capability がない provider ではそのまま続行し、圧縮失敗時は warning を出して未圧縮 session で続行する。
+
 複数ポリシー指定（配列）:
 
 ```yaml
@@ -126,6 +128,24 @@ step 定義内では**キー名**で参照する（パスを直接書かない
 
 **重要**: サブステップの `rules` は結果分類のための condition 定義のみ。`next` は無視される（親の rules が遷移先を決定）。
 
+### Finding Contract manager の provider/model
+
+`finding_contract.manager` は、Finding Manager 合成 step 専用の `provider` / `model` を指定できる。
+
+```yaml
+finding_contract:
+  ledger_path: .takt/findings/review.json
+  raw_findings_path: .takt/findings/review/raw
+  manager:
+    persona: findings-manager
+    instruction: findings-manager
+    output_contract: findings-manager
+    provider: codex
+    model: gpt-5.5
+```
+
+指定値は step レベル provider/model として扱われ、`provider_routing`、deprecated の `persona_providers.findings-manager`、workflow 既定値、解決済み入力より優先される。両方とも未指定の場合は通常の workflow step provider/model 解決を使う。`provider` だけを指定すると下位優先度の model fallback は停止し、明示 model が必須の provider では検証エラーになる。
+
 ### Finding Contract parallel の invalid manager output rule
 
 workflow に `finding_contract` がある場合、各 parallel 親 step は Finding Manager output が retry 後も意味論的に invalid な場合の制御先を宣言する必要がある。許可される rule は、選択優先順に `return: need_replan`（推奨）、`return: needs_fix`、非AIの `next: fix`。`ai("...")` で `fix` へ向かう rule は、この失敗経路では自動選択されない。該当 rule がない場合、workflow validation は実行前に失敗する。