# 正本・権限・実行の分離

## 正本と観測

永続的な判断の根拠は、その判断を所有する明示的な記録に置く。UIの表示、キャッシュ、通知、プロセスの生存情報は、正本を再確認するための観測として扱う。これらだけから操作の成功、作業の完了、権限の継続を推定しない。

永続化する情報と、現在の状態から再構成できる情報を分ける。別の所有者が管理する状態を複写して第二の状態機械を作ると、更新漏れと復旧時の不一致が生じる。親の処理は子の識別子を保持し、必要な時点で子の正本を読む。

## 権限と入力

操作権限は認証された主体、明示的な付与、対象資源の現在の制約から決定する。プロンプト、Profile名、表示名、cwd、ファイルの存在、ツールが見えることを権限の根拠にしない。別の操作経路を設けても、同じ所有者の検証を通す。

委譲では親が実際に委譲できる範囲を上限にする。読取り、書込み、コマンド実行、観測、レビュー、統合を混同しない。探索で対象を発見できても操作権限を得たことにはならない。

### Featureの構成と実操作

Featureの有効化、Tool・service・hookの登録、セッション内状態の初期化は権限を発行せず、それ自体に一律の起動認可を要求しない。外部への作用、保護データの読取り・モデルへの供給、購読・背景処理の開始は、起動中でも通常操作と同じ操作名と実対象資源で認可する。認可の要否をFeature単位のboolや起動専用の許可一覧へ置き換えない。

操作名は完全一致で扱い、親の名前から配下操作への許可を推定しない。Workspaceのcollection操作の許可は、個別のTicket・Subject・Worker等への許可ではない。資源の種類を跨ぐ包含を認めず、パスの再帰範囲などの包含は所有する型の契約だけに従う。保存済みの旧Feature・Workspace grantは読取り互換のために保持しても、新しい操作や資源の包括許可へ変換せず、基礎権限を暗黙に追加しない。

MCPはT-787の移行対象外とする暫定例外であり、既存の `mcp` 起動認可と `PermissionResource::Feature` を保持する。discoveryは外部プロセスを起動するため、既存の拒否を共通コード整理で失わせない。この例外を他のFeatureへ拡張せず、MCPの各呼出し・restoreに新しい操作認可が整備されたとも扱わない。

### 認可境界と継続実行

認可はHostに束縛された主体から、アクセス・供給・作用の直前に行う。共通のFeature内部処理やHost/provider境界を使い、Tool・WIP・typed service・起動・restore・hook・背景処理の入口差で省略しない。providerの所有・scope・capability・CAS等の検査は操作権限と合成する別の制約であり、互いの代替ではない。信頼されたFeature実装が境界を呼ぶ責務を持ち、任意コードの自動捕捉やsandboxを保証するものではない。

起動への必須性は認可の要否から分離する。必須の保護処理が拒否された場合は起動を明確に失敗させる。任意処理は未開始・利用不可を診断し、空データや成功として隠さない。拒否されたデータを先に読んだりモデルへ渡したりせず、認可拒否と通信障害を区別する。購読・背景処理の次のアクセスや配送、保存済み入力の再供給でも現行権限を検査する。登録や履歴の復元は再認可ではなく、取消要求の受付は停止確認でもない。

Subjectの権限未設定は保護操作の拒否であり、ローカルな構成の拒否ではない。Subject未接続Workerの既存Backend/provider契約と、明示的なstandaloneを区別し、接続障害や失効した接続をstandaloneとして迂回しない。主体の本体所有、委譲元、再委譲上限、現行policy、失効をHostで再確認し、保存済みの認可結果や共有clientから継続権限を推定しない。

Subject Jobの実効権限は、対象Subjectに束縛されたJobの限定grantと現行Subject policyの積集合に限る。Job種別のgrant、凍結された起点、現行attempt・入力digest・期限・writer等の制約も維持する。Memory consolidationのgrantをJournalや一般Subject操作へ流用せず、権限未設定・旧Jobの起点欠落・grant不一致で一般Worker互換へfallbackしない。Job結果の保持や過去の入力の存在は、新しい読取り・供給・作用の許可ではない。

## 履歴とLLM入力

LLMの生成に影響する入力は、リクエストへ加える前に履歴へ確定し、永続化形式からリクエストを再構成できるようにする。揮発的な入力の差込みでは、後のターンから発言やツール呼出しの根拠を追えなくなる。

履歴は追記を基本とする。圧縮や保持範囲の変更は、明示的な境界と再構成規則を持つ処理に限定する。過去の記録を黙って書き換えず、キャッシュとトークン消費への影響をセッションの実測に基づいて判断する。

## 初期設定と実行処理

環境変数などの暗黙的なプロセス状態は、起動境界で明示的な入力へ変換する。通常の処理は解決済みの型付き設定を受け取り、実行中に環境を読み直して判断を変えない。秘密情報は明示的な参照で扱い、設定の説明や診断へ値を複製しない。

## 状態と操作の独立性

作業の結論、レビュー判断、コード統合、Worker停止、記録の保持、接続解除、資源削除は別の判断である。一つの成功を別の操作の許可として流用しない。自動的に連動させる場合は、その責任を持つ操作として条件と結果を定義する。

競合確認では、何を、どの観測と比較し、どの操作の前／中／後に検査するかを名前と処理で示す。到着順、時刻、先勝ち・後勝ちで足りる処理に不透明な更新番号を加えず、別の汎用名への言い換えでも済ませない。内容の一致、同じ操作の再送、鍵の一致、接続の生存期間を確認する場合は、それぞれを識別する根拠を使い、順序や時刻だけでは足りない理由を残す。

旧保存データを読むために必要な綴りは現行契約と分離し、残す行とデータ保持上の理由を明示して検査対象にする。文字列分割・符号化や広いディレクトリ除外で命名検査を逃れない。

個別の永続操作と再試行の判断は[永続操作の原則](durable-operations.md)に従う。具体的な認証、保存、復旧の仕組みは所有moduleのドキュメントに置く。