Capability Scope

定義

Capability Scope

Capability Scope とは、ある actor が、ある process frame のある時点において、
どの対象に対して、どの種類の行為を、どの効果範囲まで、どの条件のもとで実行してよいか を定める境界である。

それは単なる tool allowlist ではなく、
operation scope、resource scope、effect scope、temporal validity、quantitative limits、delegation bounds、preconditions、postconditions を含む。

より短く言えば、Capability Scope とは
「この actor は、いまこの局面で、何に対して何をしてよく、その結果どこまで世界を変えてよいか」を process 上で bounded に定めたもの
である。

PCE 2.0 において process は、何を達成したいかだけでなく、
誰がどこまで手を伸ばしてよいか を持たなければ成立しない。
Capability Scope は、その「手を伸ばしてよい範囲」を process-local かつ governance-aware に定義する概念である。

この意味で Capability Scope は、
Governance Surface の中でも特に action / mutation / side-effect に関わる中核概念である。

なぜ Capability Scope が必要なのか

PCE 2.0 が Capability Scope を独立に扱うのは、
「できること」が bounded でなければ、責任・承認・評価・memory discipline の設計が簡単に壊れるからである。

少なくとも、次の理由がある。

1. capability が無境界だと process が drift する

たとえば、execution actor に広すぎる capability を与えると、

out-of-scope の変更
unrelated module への波及
approval を要するはずの action の先行実行
local optimization による goal drift

が起きやすい。

2. visibility と capability は違う

ある情報が見えることは、その情報に基づいて何かを変えてよいことを意味しない。
逆に、ある action を実行できても、その actor がすべての周辺情報を見てよいとは限らない。

Capability Scope を explicit にしないと、

見えるから触ってよい
ツールが使えるから使ってよい

という誤推論が起きやすい。

3. AI 時代では action surface が多層になる

いまの process では、

search
read
summarize
edit
run tests
call external service
write durable memory
approve
resume
deploy

のように、行為の型が多い。
この多層性を一つの「権限あり / なし」に潰すと粗すぎる。

4. side effect の重さが違う

同じ execute でも、

read-only observation
local reversible mutation
canonical durable write
external irreversible effect

では、要求される governance がまったく違う。
Capability Scope は、この差を process 上で扱うために必要である。

5. phase ごとに capability は変わる

analysis では read-only でよいが、implementation では limited write が必要かもしれない。
review では diff view だけで十分で、edit は禁止されるかもしれない。
Capability Scope は、phase-relative でなければならない。

6. recovery と incident で capability を絞り直す必要がある

recover 後や incident 中は、通常時の capability をそのまま戻すと危険なことがある。
Capability Scope は、active state に応じて narrow / suspend / revalidate される必要がある。

Capability Scope は何ではないか

輪郭をはっきりさせるために、まず何ではないかを書いておく。

1. 単なる identity permission ではない

identity system が持つ一般的な認可と、
current frame / phase / subject に対する capability scope は違う。
前者は可能性、後者は process-local な実効境界である。

2. 単なる role ではない

reviewer や coding agent という role 名だけでは、
実際にどの resource に対して、どの effect class の action が allowed かは分からない。

3. 単なる visibility ではない

何を見てよいかは visibility scope の問題であり、
何をしてよいかは capability scope の問題である。
両者は強く関係するが同一ではない。

4. 単なる execution responsibility ではない

実行責任を持つ actor が、必要以上に広い capability を持ってよいとは限らない。
逆に capability があるから execution responsibility があるとも限らない。

5. 単なる approval authority ではない

approve できることと edit / write / invoke できることは別である。
approval は ratification、capability scope は行為可能範囲である。

6. 単なる context budget ではない

Context Budget は何を active に持てるかの上限 / 下限を定める。
Capability Scope は何をしてよいかの境界を定める。
両者は違うが、actor-local context の設計で交差する。

7. 単なる tool list ではない

repository_search や code_edit が listed されていても、

どの path に対して
どの mode で
どこまで副作用を許すか

がなければ scope としては不十分である。

Capability Authority と Capability Scope の違い

これは PCE 2.0 で特に重要な区別である。

Capability Authority

Responsibility Bundle の一部であり、
ある actor が原理的にどの capability class を持ちうるかを示す責任上の権限である。

Capability Scope

その authority が、現在の frame / phase / runtime / governance の下で、
実際にどの resource・どの action・どの effect へ materialize されているかを示す operational 境界である。

概念的には、次のように書ける。

capability_scope(actor, frame, t) =
  materialize(
    capability_authority(actor, frame, t),
    governance_surface(frame, t),
    runtime_state(t)
  )

ここで重要なのは、
authority は潜在的 entitlement、scope は現在の実効境界
だという点である。

たとえば、

actor は code edit authority を持つ
しかし current phase では read-only analysis only
または特定 path だけ write 可能
または approval 通過後まで write 禁止

ということがありうる。

Capability Scope の主要軸

PCE 2.0 では、Capability Scope を少なくとも次の軸で考えるとよい。

1. Operation Scope

何の種類の action が許されるか。

例:

read
search
summarize
transform
edit
delete
run tests
call service
approve
promote
merge
checkpoint
recover

2. Resource Scope

どの対象に対してその action が許されるか。

例:

repository path
document collection
issue tracker
test environment
memory collection
branch set
recovery point store

3. Effect Scope

その action がどこまで世界を変えてよいか。

例:

observe-only
local reversible mutation
child-frame-local mutation
provisional durable write
canonical durable write
external side effect

4. Quantitative Scope

どれだけの量を一度に扱ってよいか。

例:

max changed files
max API calls
max rows updated
max branch fan-out
max memory items promoted
max deploy targets

5. Temporal Scope

いつ有効で、いつ失効するか。

例:

implementation phase only
valid until review handoff
invalidated by spec change
invalidated after recovery
one-shot capability

6. Delegation Scope

その actor が、さらに別 actor / subagent / tool にどこまで capability を引き渡してよいか。

例:

may spawn read-only subagent
may not delegate write
may request but not directly invoke deploy

7. Gate Dependencies

その capability が使える前提条件。

例:

spec approved
required approval granted
no open policy block
current branch not frozen
checkpoint exists

8. Required Postconditions

使ったあとに何を残さなければならないか。

例:

emit delta
attach evidence
create rollback note
record audit event
checkpoint before external side effect

Effect Scope は特に重要である

PCE 2.0 では、capability の危険度は what tool だけでなく
what effect class に大きく依存する。
少なくとも次の階層で考えるとよい。

1. Observe-only

世界を変えずに読む / 調べるだけ。

例:

search
read file
read decision memory
inspect diff

2. Derived Output without Mutation

外部 state を変えずに summary / analysis / proposal を作る。

例:

summarize docs
propose plan
classify issue

3. Local Reversible Mutation

局所的で、比較的戻しやすい変更。

例:

edit local branch file
draft note
create temporary artifact

4. Structured Provisional Write

durable だが canonical ではない書き込み。

例:

checkpoint
pending candidate creation
provisional note write

5. Canonical Durable Write

future process の前提を変える書き込み。

例:

decision memory canonicalization
governance record update
final artifact merge

6. External World Effect

system 外や不可逆に近い side effect。

例:

production deploy
user-facing state change
external API action with real effect

原則として、上に行くほど

stronger gate
stronger audit
stronger rollback requirement
stronger authority

が必要になる。

Capability Scope は stateful である

Capability Scope は static な設定ではない。
同じ actor でも、lifecycle や phase に応じて変わる。

例

Analysis phase

search: allowed
read spec: allowed
code edit: prohibited
memory write: prohibited

Implementation phase

bounded code edit: allowed
run local tests: allowed
deploy: prohibited
final merge: prohibited

Review phase

diff view: allowed
approve / reject: allowed
direct code edit: prohibited

Incident phase

normal execution: suspended
emergency rollback order: maybe allowed to incident owner only
regular promotion: frozen

つまり Capability Scope は、
current state によって有効化 / 縮退 / 無効化される operational envelope
である。

Capability Scope の主要操作

PCE 2.0 では、capability scope は少なくとも次の操作を受ける。

Assign

新しい frame や actor に初期 scope を与える。

Narrow

scope を狭める。

例:

read-only にする
specific path のみに限定する
external call を止める

Widen

条件付きで scope を広げる。

例:

review 後に limited write を許す
incident owner に temporary freeze authority を与える

ただし widen は traceable であるべきで、静かに行ってはならない。

Suspend

一時的に capability を止める。

例:

approval pending 中は write stop
incident 中は merge freeze

Revoke

capability を取り消す。

例:

policy violation detected
actor removed from frame
branch abandoned

Revalidate

recover や reframe の後に、scope を current state に照らして再有効化する。

これらの操作は、Transitions と Governance Surface に結びついている。

Capability Scope と Actor-local Context の関係

Capability Scope は、Actor-local Compiled Context の中で
active action affordance として見える。

context に出るもの

allowed tools
allowed actions
prohibited actions
write scope
escalation conditions if scope is exceeded
must-emit obligations after action

ここで重要なのは、
context に見える action affordance が actual capability scope と一致しているべきだという点である。

悪い例

prompt には edit code と書いてあるのに actual scope は read-only
UI 上 approve ボタンが見えるが actor はその authority を持たない
recovery 後も古い tool scope が表示されたまま

これは authority leakage や corrupt progression を生みやすい。

Capability Scope と Context Budget / Selection / Compaction の関係

Capability Scope は context 系の設計とも強く結びつく。

Context Budget

Context Budget では、allowed / prohibited actions の表示も floor に入りうる。
actor が今何をしてよいか分からない context は unsafe である。

Context Selection

Context Selection では、visible であっても capability scope 外のものを active に入れない、または明示的に prohibited として出す必要がある。

Compaction

Compaction では、禁止事項や gate dependency を summary で消してはならない。
たとえば review package から direct edit prohibited を落とすのは governance failure になりうる。

つまり Capability Scope は、
context の「何が見えるか」だけでなく「何ができるか」を stable にする役割を持つ。

Capability Scope と Parent-Child Process の関係

Parent-Child Process では、child に何を委ねるかが重要である。
Capability Scope は、その bounded autonomy の実体である。

親が retain しやすいもの

final merge
global reframe
canonical memory write
incident closure
release-level action

child に delegate しやすいもの

read-only analysis
local implementation
bounded evaluation
local checkpoint creation
provisional candidate creation

原則

child は親より広い capability を黙って持ってはならない
retained authority を compacted summary で消してはならない
child return handoff では、どこまで child ができていたかが分かる必要がある

つまり parent-child relation は、
goal slice だけでなく capability scope も切る構造である。

Capability Scope と Branch-and-Join の関係

複数 branch では、sibling 間の scope collision が問題になる。
そのため branch ごとの capability scope を明示すべきである。

典型例

implementation branch: limited write
rollback-readiness branch: read-only
memory triage branch: write to pending candidates only

重要な点

sibling branch が同じ mutable resource を触るなら collision policy が必要
branch abandon / supersede 時には scope も revoke されるべき
join 前に stale branch capability が残っていないかを見るべき

Capability Scope は、Branch and Join を安全に parallelize する前提になる。

Capability Scope と Approval / Escalation の関係

Capability Scope は often gate と結びつく。

Approval と結びつく例

local write は allowedだが canonical write は approval required
deploy capability is hidden until release approval
broadened scope requires goal-owner approval

Escalation と結びつく例

actor が out-of-scope change を必要とした
current capability では rollback cannot be guaranteed
local bundle cannot invoke required higher-risk action

このとき正しい response は silent overreach ではなく Escalation である。

つまり Capability Scope は、
「できないなら諦める」のではなく
できないなら誰へ返すべきか も定義する。

Capability Scope Violation

PCE 2.0 では、capability scope violation は process 上の明確な異常として扱うべきである。

violation の典型

resource outside allowed path
action beyond allowed operation class
effect class stronger than allowed
using capability after invalidation
delegated actor using non-delegable capability
hidden direct write around promotion surface

典型 response

block or suspend execution
reopen gate
invalidate delta or approval path
escalate
create incident record
rollback if already materialized

Capability Scope は、ただ「allowed list」を持つのではなく、
違反時に何を起こすか まで持つ必要がある。

Capability Scope と Recovery の関係

recover 後に old capability scope をそのまま戻してよいとは限らない。

理由

frame may have been reframed
governance rules may have changed
approvals may have expired
old branch may be superseded
old actor may no longer be the right principal

そのため必要なこと

recover 時の revalidation
stale scope invalidation
recompiled actor-local context with current scope
explicit resume authority for stronger effect classes

つまり Capability Scope は、recoverable であると同時に
blindly restorable であってはならない。

Capability Scope の最小スキーマ

PCE 2.0 における最小スキーマは、次のように置ける。

capability_scope:
  actor_ref:
  frame_id:
  phase:
  modality:
  authority_basis:
  operations:
    allowed:
    prohibited:
  resources:
    repository_paths:
    document_collections:
    environments:
    services:
    memory_collections:
  effect_scope:
    class:
    max_externality:
  quantitative_limits:
    max_changed_files:
    max_calls:
    max_write_targets:
  delegation:
    may_delegate: true | false
    allowed_delegations:
  preconditions:
    required_approvals:
    required_evals:
    required_state:
    policy_conditions:
  postconditions:
    must_emit_deltas:
    must_record_audit:
    must_checkpoint_before:
  validity:
    active_when:
    invalidated_by:
    expires_when:
  escalation_path:
  violation_response:
    on_soft_violation:
    on_hard_violation:
  provenance:

bundle に近い形で簡潔に書くなら、次のようにも置ける。

capability_scope:
  scope_id:
  actor_ref:
  frame_ref:
  current_phase:
  allowed_actions:
  allowed_resources:
  prohibited_actions:
  effect_class:
  temporal_validity:
  quantitative_limits:
  gate_dependencies:
  delegation_bounds:
  audit_requirements:
  invalidation_triggers:

このスキーマで重要なのは、次の点である。

operation と resource を分けている
effect scope を独立に持つ
temporal validity と invalidation を持つ
delegation bounds がある
pre/postconditions と violation response がある

つまり Capability Scope は、
単なる permission table ではなく process-local action envelope として扱われるべきである。

小さな例

feature.checkout.coupon-combination frame における coding_agent の capability scope は、たとえば次のように書ける。

capability_scope:
  actor_ref: coding_agent
  frame_id: feature.checkout.coupon-combination
  phase: implementation
  modality: llm_plus_tools
  authority_basis:
    - coding_agent_impl_bundle_v2
  operations:
    allowed:
      - search_repository
      - read_files
      - edit_files
      - run_local_tests
    prohibited:
      - merge
      - approve
      - deploy
      - canonical_memory_write
  resources:
    repository_paths:
      - src/checkout/coupon_validation.ts
      - src/checkout/pricing/*
      - tests/checkout/*
    document_collections:
      - approved_spec_summary
      - precedence_adr_excerpt
    environments:
      - local_repo
      - ci_readonly_view
    services: []
    memory_collections: []
  effect_scope:
    class: bounded_local_mutation
    max_externality: no_external_side_effects
  quantitative_limits:
    max_changed_files: 6
    max_write_targets: 1_module_cluster
    max_calls: 20
  delegation:
    may_delegate: false
    allowed_delegations: []
  preconditions:
    required_approvals:
      - spec_approval
    required_evals: []
    required_state:
      - frame_phase_is_implementation
    policy_conditions:
      - payment_gateway_changes_are_out_of_scope
  postconditions:
    must_emit_deltas:
      - artifact_delta
      - implementation_note
      - rollback_note
    must_record_audit:
      - changed_file_list
    must_checkpoint_before: []
  validity:
    active_when: spec_approved
    invalidated_by:
      - review_started
      - spec_changed
      - incident_open
    expires_when: implementation_handoff_completed
  escalation_path:
    - reviewer
    - product_owner
  violation_response:
    on_soft_violation:
      - stop_and_escalate
    on_hard_violation:
      - suspend_execution
      - incident_record
  provenance:
    assigned_by: feature.checkout.coupon-combination

この例で重要なのは、code_edit が allowed でも、

path が bounded であり
effect class が local reversible mutation に限定され
merge や canonical write は含まれず
phase 変更や incident で invalidated される

という点である。

Capability Scope の不変条件

PCE 2.0 では、少なくとも次の不変条件を置ける。

1. No capability without scope

「使える」というだけでは不十分であり、何に対してどこまでかが必要である。

2. Visibility does not imply capability

見えることとできることは別である。

3. Capability does not imply responsibility

scope を持つことは、その action を今やる責任を持つことを意味しない。

4. Higher effect classes require stronger governance

canonical write や external side effect は、read-only action と同じ扱いにしてはならない。

5. Child / branch scopes must not silently widen

親や sibling の retained authority を黙って超えてはならない。

6. Capability must be time-bounded

phase / state / recovery / incident に応じて失効・再検証される必要がある。

7. Delegation must be explicit

delegable か non-delegable かを曖昧にしてはならない。

8. Violation must have a defined response

違反しても何も起きない scope は governance として不十分である。

9. Scope must remain traceable

誰が、どの authority で、どの範囲を持っていたかを追える必要がある。

10. Scope should be sufficient but minimal

仕事に必要十分であるべきだが、それ以上に広くしてはならない。

いつ Capability Scope を分けるべきか

次の条件があるなら、一つの capability scope ではなく分割を考えるべきである。

1. effect class が大きく違うとき

read-only analysis と canonical write は分けるべきである。

2. resource domain が違うとき

code repository、memory store、runtime controls、external services は別 surface にした方が安全なことが多い。

3. phase が違うとき

analysis / implementation / review / promotion / incident / recovery で scope を変えるべきである。

4. audit / revoke 単位を分けたいとき

同じ actor identity でも、別 scope として切った方が traceability が高いことがある。

5. delegation policy が違うとき

subagent に read-only だけ許す場合などである。

短く言えば、
resource、effect、phase、audit、delegation のいずれかが意味的に変わるなら scope を分ける
のが基本である。

最低限の自己点検

ある process が capability-scope-aware かどうかは、次で点検できる。

actor ごとに allowed action と prohibited action を言えるか
action ごとの resource boundary を言えるか
effect class を言えるか
visibility と capability を混同していないか
canonical write や external side effect に強い gate を置いているか
phase / recovery / incident で scope を更新しているか
delegation bounds があるか
violation response があるか
actor-local context に current scope が正しく反映されているか
その scope が「広すぎず、しかし仕事には足りる」と説明できるか

このどれかが欠けるなら、その process はまだ capability scope を十分に設計していない。

暫定的なまとめ

Capability Scope が言っていることは、最終的には次の一文に集約できる。

process において重要なのは、「この actor は何ができるか」を漠然と持つことではない。
どの対象に、どの種類の action を、どの効果範囲まで、どの条件のもとで許すのかを bounded に定め、その境界を phase・governance・recovery に応じて更新することである。

PCE 2.0 において capability は、単なる便宜ではない。
それは process integrity と durable state の健全性を守るための統治対象である。

だから Capability Scope は、単なる permission list ではない。
それは、PCE 2.0 において actor の action power を bounded にし、過剰な自律と hidden side effect を防ぐための governance boundary である。