Authorize Feature effects and protected input at operation boundaries

Remove non-MCP activation gates without expanding legacy grants. Bind resource resolution, background Job attenuation, protected prompt provenance and repeated model supply to current Host authority. Align generated contracts and regression fixtures.
This commit is contained in:
2026-10-28 11:44:34 +09:00
parent 618880d38d
commit 960a1b4364
75 changed files with 13191 additions and 1143 deletions
+18
View File
@@ -12,6 +12,24 @@
委譲では親が実際に委譲できる範囲を上限にする。読取り、書込み、コマンド実行、観測、レビュー、統合を混同しない。探索で対象を発見できても操作権限を得たことにはならない。
### 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の生成に影響する入力は、リクエストへ加える前に履歴へ確定し、永続化形式からリクエストを再構成できるようにする。揮発的な入力の差込みでは、後のターンから発言やツール呼出しの根拠を追えなくなる。