[architect] — owner 方針（2026-08-11）: model などの非権限 config も、agent / session 層で
ユーザまたは親セッションが規定を指定できるようにしたい。owner 同意: 全ての非権限ではなく★選別が要る。
実装は私は持ちません。 以下は設計の骨格と、選別のための材料です。
現状（実測）
agent 層 .reyn/agents/<name>/profile.yaml name / role / created_at / allowed_mcp
session 層 <session-state-dir>/config.yaml name / description / categories /
tool_allow / tool_deny / mcp_allow / mcp_deny
どちらも capability 軸と identity のみ。非権限の設定は★1 つも置けません。
∴ 現状の規則は「agent / session 層は capability narrowing と identity のみ、それ以外は project 単位」で、
一貫して守られていますが、どこにも書かれていません。
🔴 「権限 / 非権限」の 2 分では足りない — model が反例
budget.py:3 "A process-shared BudgetTracker accumulates token + USD usage per agent"
daily_cost_usd / monthly_cost_usd = ★プロセス共有のクォータ
子セッションが高価なモデルを選ぶと、全 agent が共有する日次/月次クォータを食います。
∴ **model は「好み」ではなく「★共有された有界資源を消費する軸」**です。
自由な上書きを許すと、子が親の予算を使い切れます。
提案 — 軸は 3 つ
| 軸 |
例 |
合成法 |
状態 |
| ① capability |
tool / mcp / categories / file zone |
restrict-only（子は狭めるのみ） |
✅ 実装済み |
| ② bounding |
model / timeout / router_max_iterations |
子は狭めるのみ。天井は operator |
⚪ #3903 に前例 |
| ③ preference |
output_language / render_mode |
自由に上書き |
新規（単純） |
⚪ ②は今夜すでに設計されています — #3903① の max_timeout_seconds:
operator が天井を設定でき、LLM はそこまで伸ばせ、超えたら reject して★実際の上限を名指しする
（clamp しない）。この形を軸の法則として一般化するだけで、model にも適用できます
（llm.model_max_class のような天井 ＋ 子は等価以下を選べる）。
⚪ 新しい機構を 1 つも要求しません — ①実装済み、②既存形の再利用、③単純な上書き。
「誰が指定できるか」も軸で決まります
operator（user） ①②③ すべて、どの層でも
親セッション ① 狭めるのみ ／ ② 狭めるのみ ／ ③ 自由
⚪ 既存の継承規律とそのまま整合します — spawn_session は親の narrowing を合成し（#3556）、
spawn_agent は ⊆ spawner を構造的に保証（#2103 B-core）。②を同じ形に載せられます。
🔴 やること — 37 キーを 3 軸に割り振る（選別）
これが本 issue の実体です。境界例が必ず出ます:
sandbox ①か？（policy は capability だが backend 選択は？）
chat.compaction ②か③か（トークン消費に効くので②の可能性）
offload ②か③か（tool 結果サイズ＝コンテキスト消費）
embedding ②（cost_warn_threshold を持つ）か
action_retrieval hot_list_n はコンテキストを食う → ②か
⚪ 割り振りが決まれば、各キーの実装は機械的です。決めるべきは分類そのもの。
範囲
測ったもの: agent / session 層の現行スキーマ、BudgetTracker が process-shared であること、
daily/monthly が共有クォータであること、#3903 の天井機構、#3556 / #2103 B-core の継承規律。
測っていないもの: 🔴 ②に入れるべき他のキーは★推測です —
router_max_iterations が実際に何を縛るか、offload / action_retrieval が資源を食うかは
確認していません。上の境界例リストは当たりを付けるためのもので、根拠ではありません。
選別作業の第一歩は、各キーが「共有資源を消費するか」を測ることです。
⚪ 私が選別の測定パスを実施できます（設計・測定は私の役割）。owner は境界例の裁定だけを
担当する形が最短だと考えます。指示があれば着手します。
📌 確定版分類（2026-08-11、lead-coder が本文へ引き上げ）
architect が 3 回の訂正を経て確定させた分類を、コメントから本文へ上げます。コメントは流れますが、本文は最初に読まれる面だからです。単位はキーではなくサブ config（この粒度に下げたことで sandbox の矛盾と chat の混在が両方解けました）。
① 可視性のみ レジストリ群の可視性（.reyn/config/*.yaml の 内容は ④）
② bounding chat.compaction ほか
③ preference chat.reasoning / chat.gutters / chat.render_mode / chat.neutralize_body
tool_use / output_language / project_context_path
④ project-only events / embedding / llm 系（owner 裁定）/ sandbox の 3 スカラー
web.* / observability / auth / external_transports / fs_watch
agent.id / voice / レジストリ群の内容
⚠️ architect の確認事項（未回答）: EmbeddingConfig はフラットなのでサブ config 単位では embedding 全体が 1 単位 ∴ embedding 全体を ④ と読んでいる。enabled だけセッション毎に切りたい等の意図があれば訂正が要ります。
🔴 着手順の依存（実装前に決めること）
2 が 1 に先行し得る:
chat.render_mode / chat.gutters は ★client 側でしか読まれない（実測済み）
∴ 「層に開く」より先に「★client: ブロックへ移す」（#4174 の軸 C）が来る可能性
★移してから軸を付ける方が 手戻りが 無い
⚪ doc / ADR は実装と同じ PR で
実装前に reference doc や ADR を書きません — 未実装の分類を doc に書くと「宣言されているが存在しない」形を新規に作ります（#3987 が「ADR-0038 の Implemented が未配線 2 件を含む」を今も open で抱えています）。実装する人が、実装と同じ PR で ADR＋doc を書くのが正しい順序です（lead-coder 判断、2026-08-11）。
[architect] — owner 方針（2026-08-11）:
modelなどの非権限 config も、agent / session 層でユーザまたは親セッションが規定を指定できるようにしたい。owner 同意: 全ての非権限ではなく★選別が要る。
実装は私は持ちません。 以下は設計の骨格と、選別のための材料です。
現状（実測）
どちらも capability 軸と identity のみ。非権限の設定は★1 つも置けません。
∴ 現状の規則は「agent / session 層は capability narrowing と identity のみ、それ以外は project 単位」で、
一貫して守られていますが、どこにも書かれていません。
🔴 「権限 / 非権限」の 2 分では足りない —
modelが反例子セッションが高価なモデルを選ぶと、全 agent が共有する日次/月次クォータを食います。
∴ **
modelは「好み」ではなく「★共有された有界資源を消費する軸」**です。自由な上書きを許すと、子が親の予算を使い切れます。
提案 — 軸は 3 つ
⚪ ②は今夜すでに設計されています — #3903① の
max_timeout_seconds:operator が天井を設定でき、LLM はそこまで伸ばせ、超えたら reject して★実際の上限を名指しする
（clamp しない）。この形を軸の法則として一般化するだけで、
modelにも適用できます（
llm.model_max_classのような天井 ＋ 子は等価以下を選べる）。⚪ 新しい機構を 1 つも要求しません — ①実装済み、②既存形の再利用、③単純な上書き。
「誰が指定できるか」も軸で決まります
⚪ 既存の継承規律とそのまま整合します —
spawn_sessionは親の narrowing を合成し（#3556）、spawn_agentは ⊆ spawner を構造的に保証（#2103 B-core）。②を同じ形に載せられます。🔴 やること — 37 キーを 3 軸に割り振る（選別）
これが本 issue の実体です。境界例が必ず出ます:
⚪ 割り振りが決まれば、各キーの実装は機械的です。決めるべきは分類そのもの。
範囲
測ったもの: agent / session 層の現行スキーマ、
BudgetTrackerが process-shared であること、daily/monthly が共有クォータであること、#3903 の天井機構、#3556 / #2103 B-core の継承規律。
測っていないもの: 🔴 ②に入れるべき他のキーは★推測です —
router_max_iterationsが実際に何を縛るか、offload/action_retrievalが資源を食うかは確認していません。上の境界例リストは当たりを付けるためのもので、根拠ではありません。
選別作業の第一歩は、各キーが「共有資源を消費するか」を測ることです。
⚪ 私が選別の測定パスを実施できます（設計・測定は私の役割）。owner は境界例の裁定だけを
担当する形が最短だと考えます。指示があれば着手します。
📌 確定版分類（2026-08-11、lead-coder が本文へ引き上げ）
architect が 3 回の訂正を経て確定させた分類を、コメントから本文へ上げます。コメントは流れますが、本文は最初に読まれる面だからです。単位はキーではなくサブ config（この粒度に下げたことで
sandboxの矛盾とchatの混在が両方解けました）。EmbeddingConfigはフラットなのでサブ config 単位ではembedding全体が 1 単位 ∴embedding全体を ④ と読んでいる。enabledだけセッション毎に切りたい等の意図があれば訂正が要ります。🔴 着手順の依存（実装前に決めること）
⚪ doc / ADR は実装と同じ PR で
実装前に reference doc や ADR を書きません — 未実装の分類を doc に書くと「宣言されているが存在しない」形を新規に作ります（#3987 が「ADR-0038 の Implemented が未配線 2 件を含む」を今も open で抱えています）。実装する人が、実装と同じ PR で ADR＋doc を書くのが正しい順序です（lead-coder 判断、2026-08-11）。