Transitions

定義

Transition

Transition とは、ある process frame の進行において生じる
型付き・帰属可能・権限制約付きの状態変化 である。

それは単なる workflow 上の矢印ではなく、
runtime state、responsibility allocation、actor-local compiled context、process delta、recovery point、durable project state のいずれかに対して、
明示的な前提条件と効果を持って作用する。

より短く言えば、Transition とは
「この process は、いま何が起きたことによって、どの責任状態・実行状態・差分状態・永続状態へ移ったのか」
を表す、意味的な遷移である。

PCE 2.0 では、process は単なる step の列ではありません。
process の本体は、Responsibility Bundle が配分され、局所コンテキストが compile され、差分が emitted され、評価され、必要に応じて昇格される 遷移の体系 にあります。

この意味で Transitions は、PCE 2.0 における process semantics の中心概念です。

なぜ Transitions が必要なのか

PCE 2.0 が transition を独立概念として置くのは、AI 時代の開発では「何をするか」だけでなく、
何が起きたとみなすのか を明示しないと process を記述できないからです。

少なくとも、次の違いを理論上区別できなければなりません。

frame が生成されたのか
責任が配分されたのか
capability が絞られたのか
actor 用 context が compile されたのか
実行が進んだのか
handoff が起きたのか
承認待ちに入ったのか
承認されたのか拒否されたのか
eval が走ったのか
delta が durable state に昇格したのか
checkpoint が切られたのか
rollback / replan / escalate が起きたのか

これらを単なる「工程の途中」として曖昧にしてしまうと、

どの時点で authority が必要か分からない
どの時点で context が stale になるか分からない
どの時点で delta が canonical 候補になるか分からない
どの時点で新しい frame を切るべきか分からない
どの時点で recovery が可能か分からない

という問題が起こります。

だから PCE 2.0 では、process は step の列ではなく、
責任・状態・差分・昇格のあいだを往復する typed transitions として扱われます。

Transitions は何ではないか

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

1. 単なる TODO の順番ではない

「調査 → 実装 → テスト」のような並びは、まだ transition ではありません。
そこに前提条件、権限、効果、状態変化が必要です。

2. 単なる UI 上のイベントではない

ボタンを押した、コメントを付けた、メッセージを送った、というイベントは transition のトリガーにはなりえます。
しかし event と transition は同じではありません。
transition は、process semantics 上の変化です。

3. 単なる関数呼び出しではない

コード上で関数を呼んだからといって、必ずしも process transition ではありません。
逆に、複数の関数呼び出しをまたいで一つの transition とみなすこともあります。

4. 単なる durable write ではない

state を書き換えることは transition の効果になりえますが、
すべての transition が durable write を伴うわけではありません。

5. 単なる frame の存在ではない

Process Frame は構造的な仕事単位です。
transition は、その frame がどう進むかを表す動的概念です。

6. 単なる actor の意思決定でもない

actor が何かを判断することは transition の一部になりえます。
しかし transition は、その判断が runtime state、responsibility、delta、approval 状態をどう変えたかまで含みます。

Transition が作用する対象

PCE 2.0 における transition は、少なくとも次の対象のいずれかを変化させます。

1. Runtime State

その frame が今どの状態にあるかを変えます。
実行中、承認待ち、評価中、blocked、rolled back などです。

2. Responsibility Allocation

どの actor がどの責任を持つかを変えます。
assign、delegate、revoke、escalate などがこれに当たります。

3. Actor-local Context Validity

どの context が有効で、どの context が stale になったかを変えます。
approval や replan の後に旧 context を使い続けてよいとは限りません。

4. Process Delta Lifecycle

delta が emitted、under review、evaluated、approved、merged、rejected などのどこにあるかを変えます。

5. Durable Project State

一部の transition は、最終的に Durable Project State を更新します。
ただし原理的には、これは eval と authority を経た後に限られます。

6. Recovery Surface

checkpoint が作られたり、recover によって過去の state が再活性化されたりします。

このため transition は、単なる「次の作業へ行く矢印」ではなく、
process のどの層が変化したのかを示す stateful operation です。

Transition の一般形

概念的には、transition は次のように表せます。

transition τ :
  (
    process_frame,
    runtime_state_t,
    responsibility_allocation_t,
    local_context_refs_t,
    inputs
  )
  ->
  (
    runtime_state_t+1,
    responsibility_allocation_t+1,
    context_effects,
    emitted_delta*,
    recovery_point?,
    durable_write?
  )

ここで重要なのは、次の点です。

1. frame 自体は不変とは限らない

多くの transition は frame の runtime state を変えるだけですが、
decompose や replan は frame topology 自体を変えることがあります。

2. context は入力でも出力でもある

transition は既存の local context を消費することがあります。
同時に、新しい context を compile する契機にもなります。

3. delta は transition の重要な副産物ではなく、中心的出力である

実行、評価、承認、checkpoint などは、それぞれ異なる型の Process Delta を生みえます。

4. durable write は特権的である

すべての transition が durable state を直接変えるわけではありません。
promote と merge は、その中でも特別な遷移です。

Transition は actor を持つ

PCE 2.0 では、transition は無主語ではありません。
各 transition は、少なくとも次のいずれかの initiator を持ちます。

1. Human-initiated

人間が起こす遷移です。

approve
reject
escalate
close
manual rollback

2. AI-initiated

AI agent / subagent が起こす遷移です。

execute
emit-delta
propose-handoff
replan proposal

3. Runtime-initiated

システムや runtime が起こす遷移です。

checkpoint
recover
context invalidation
timeout-induced suspension

4. Governance / Policy-initiated

policy engine や registry rule が起こす遷移です。

revoke capability
block merge
force escalation
scope restriction

ここで重要なのは、
誰が起こしたか と
それを起こす authority があるか
は別だということです。

Transition の最小要件

PCE 2.0 では、意味のある transition は最低でも次を持つべきです。

1. Type

何の遷移なのか。
assign、handoff、approve、checkpoint などです。

2. Preconditions

その遷移が起きるために満たされているべき条件です。

3. Initiator

誰または何が遷移を起こしたのか。

4. Acting Bundle / Authority

どの responsibility / authority のもとで遷移したのか。

5. Effects

何が変わったのか。
runtime state、responsibility allocation、context validity、delta lifecycle、durable state などです。

6. Provenance

いつ、どの frame で、どの evidence に基づいて起きたか。

この六つがあることで、transition は後から追跡可能になります。

基本遷移ファミリ

PCE 2.0 では、transition を大きく六つのファミリに分けます。

Framing transitions
Responsibility transitions
Context / work transitions
Gate / evaluation transitions
Persistence / promotion transitions
Recovery / correction transitions

以下、それぞれを定義します。

1. Framing Transitions

これは frame の存在や境界そのものに関わる遷移です。

`instantiate`

新しい Process Frame を立ち上げる遷移です。

何を達成する frame か
誰が初期 actor か
初期 goal / scope / constraints / eval contract は何か

を定めます。

これは process の始点です。

`decompose`

親 frame を、複数の子 frame へ分解する遷移です。

goal slice を切り出す
child に必要な scope と capability を割り当てる
parent 側に留保する authority を残す

この遷移により、長い仕事を統治可能な単位へ分解します。

`reframe`

既存 frame の goal / scope / success criteria / authority boundary を意味的に修正する遷移です。
これは軽い runtime update ではなく、frame の境界定義を変えるため、通常は強い justification を要します。

`close`

その frame を、いま以上 active に進めない状態へ閉じる遷移です。

completed
abandoned
superseded
merged-and-closed
rejected-and-closed

などの終端状態を取りえます。

2. Responsibility Transitions

これは responsibility allocation に関わる遷移です。
Responsibility-first の中心です。

`assign`

ある actor に、ある Responsibility Bundle を割り当てる遷移です。
新しい frame の初期化時にも起こりえますし、途中参加の actor に対しても起こりえます。

`delegate`

bundle の一部を別 actor に委ねる遷移です。
通常、goal ownership や incident ownership まで全面移譲するとは限りません。

`narrow`

bundle や capability scope を狭める遷移です。

read-only に制限する
対象 file / module を限定する
approval authority を外す

などが該当します。

`widen`

bundle や capability scope を条件付きで広げる遷移です。
write authority の付与などが典型ですが、通常は approval を伴います。

`revoke`

bundle の一部または全部を取り消す遷移です。
policy violation、scope violation、review rejection の後に起こりえます。

`escalate`

現在の actor / bundle では処理不能な問題を、
別の actor / bundle / authority に引き上げる遷移です。

この遷移は責任の消失ではなく、責任の再配置です。

3. Context / Work Transitions

これは local context の生成と、そこから行われる work に関わる遷移です。

`compile-context`

ある actor のために Actor-local Compiled Context を生成する遷移です。

goal slice
relevant state
allowed actions
constraints
stop conditions
handoff contract

が局所化されます。

`invalidate-context`

既存の local context を stale とみなす遷移です。
approval、replan、bundle change、rollback、recover の後に起こりえます。

`execute`

actor が bundle と local context の範囲内で work を進める遷移です。
調査、実装、分析、要約、検証実行などが含まれます。

`emit-delta`

意味のある boundary において Process Delta を生成する遷移です。
これは execute の結果であることも、evaluate / checkpoint / approval の結果であることもあります。

`handoff`

active な work package を別 actor に渡す遷移です。
handoff はメッセージ送信ではなく、責任状態・必要 evidence・未解決事項・次の期待出力を伴う引き継ぎです。

詳しくは Handoff を参照します。

4. Gate / Evaluation Transitions

これは approval や eval のような gate に関わる遷移です。

`submit-for-approval`

ある delta、phase、decision を approval point に差し出す遷移です。
しばしば frame はここで pending state に入ります。

`approve`

required authority を持つ actor が、ある delta や phase を ratify する遷移です。
approval は evaluation と同じではありません。
それは authority の行使です。

`reject`

approval または review の結果、差分や進行を拒否する遷移です。
reject は end とは限らず、rework、replan、rollback の起点になりえます。

`evaluate`

Eval Contract に基づいて delta や trace を評価する遷移です。
deterministic test、review rubric、policy check、trace grading などが入りえます。

`mark-evaluated`

ある delta item を「所定の eval path を通過した」状態にする遷移です。
これは merge の前提ですが、merge 自体ではありません。

5. Persistence / Promotion Transitions

これは durable state への書き込みや昇格に関わる遷移です。

`checkpoint`

ある runtime state を Recovery Point として保存する遷移です。
これは多くの場合、Durable Project State の provisional zone を更新します。

`promote`

評価済みの delta item を durable update 候補として昇格させる遷移です。
重要なのは、promote は「merge してよい候補にする」ことであり、merge そのものではないことです。

`merge`

promoted delta item を durable state に反映する遷移です。
PCE 2.0 では、No merge without eval により、merge は常に eval と authority を前提にします。

`archive`

superseded / obsolete / no-longer-active な durable item や frame record を、追跡可能な形で退避する遷移です。
削除と archive は同じではありません。

6. Recovery / Correction Transitions

これは process の修正、回復、巻き戻しに関わる遷移です。

`recover`

checkpoint や stored recovery point から、frame を再開可能状態へ戻す遷移です。

`replan`

failure、new evidence、scope clarification などを受けて、
今後の進め方を再設計する遷移です。
必要なら child frame を追加したり、bundle を再配分したりします。

`rollback`

不適切な進行や誤った適用を、以前の許容状態へ戻す遷移です。
runtime rollback と durable rollback は区別されるべきです。

`suspend`

一時的に active progression を止める遷移です。
pending approval、external dependency、budget hold などが理由になります。

`resume`

suspend された frame を、適切な条件のもとで再開する遷移です。
しばしば context の再コンパイルを伴います。

基本遷移の典型シーケンス

PCE 2.0 における代表的な正常系は、概念的には次のようになります。

instantiate
  -> assign
  -> compile-context
  -> execute
  -> emit-delta
  -> evaluate
  -> submit-for-approval
  -> approve
  -> promote
  -> merge
  -> close

一方、異常系や修正系は次のようになります。

instantiate
  -> assign
  -> compile-context
  -> execute
  -> emit-delta
  -> evaluate
  -> reject
  -> replan
  -> compile-context
  -> execute
  -> emit-delta
  -> evaluate
  -> approve
  -> promote
  -> merge

あるいは、

execute
  -> checkpoint
  -> suspend
  -> recover
  -> recompile-context
  -> resume

という継続系もありえます。

ここで重要なのは、同じ frame の中でも複数の transition path が存在することです。
process は一本道ではありません。

Transition は context freshness を変える

PCE 2.0 では、context の鮮度は transition によって決まります。
とくに次の遷移は、既存の Actor-local Compiled Context を stale にしやすいです。

assign / delegate / revoke
approve / reject
evaluate の結果確定
replan / rollback
recover / resume
capability scope change
governance rule change

したがって、transition の設計は単なる state change だけではなく、
いつ recompile が必要かを定義すること でもあります。

Point と Transition の違い

ここは PCE 2.0 で重要な区別です。

Approval Point

frame 上の「ここでは approval が必要だ」という構造的な場所です。
これは Approval Points の概念です。

Approve / Reject

その point を実際に通過する transition です。

同様に、

Recovery Point

再開可能な保存状態という構造です。
これは Recovery Point の概念です。

Checkpoint / Recover

その recovery point を作る / 使う transition です。

つまり、

point は構造
transition は出来事

です。

同じ frame 内 transition と、新しい frame を切ることの違い

すべてを transition で済ませるべきではありません。
次の条件では、新しい child frame を切るべきです。

1. Goal slice が大きく変わるとき

同じ frame の局所修正ではなく、別の達成対象になっているなら decompose して child frame を作る方がよいです。

2. Approval / Eval / Incident ownership が変わるとき

authority 構造が大きく変わるなら、同一 frame 内の小さな transition より新しい frame の方が追跡しやすいです。

3. Capability boundary が大きく変わるとき

read-only analysis と write-enabled implementation は、別 frame にした方が安全なことが多いです。

4. Recovery strategy が大きく変わるとき

再開点や rollback 条件が異なるなら、frame を分ける意味があります。

短く言えば、
局所的な責任状態の変化なら transition、仕事単位の境界変化なら child frame
と考えるのが基本です。

Transition Record の最小スキーマ

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

process_transition:
  transition_id:
  type:
  frame_id:
  parent_transition_id:
  initiator:
  acting_bundle_ref:
  input_refs:
  preconditions:
  required_authority:
  effects:
    runtime_state_change:
    responsibility_changes:
    context_effects:
    emitted_delta_refs:
    recovery_ref:
    durable_write_refs:
  result_state:
  evidence_refs:
  timestamp:

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

transition type がある
initiator と acting bundle がある
effects が多層である
emitted delta と durable write が分かれている
authority と evidence が追跡できる

つまり transition は、
誰が・何の責任で・何を変えたか
を記録するプロセス単位です。

小さな例

「checkout にクーポン併用制約を追加する」frame の一部として、次の sequence を考えます。

1. `assign`

coding_agent に implementation bundle を割り当てる
reviewer に approval / evaluation bundle を割り当てる
product_owner に goal ownership と incident ownership を残す

2. `compile-context`

coding agent 用に実装対象、禁止領域、必要テストを含む local context を作る

3. `execute`

coding agent が許可された file scope 内で code を変更する
tests を実行する

4. `emit-delta`

code patch
implementation note
failed naive approach の failure candidate
review checkpoint

を含む delta を出す

5. `evaluate`

required regression tests
policy checks

を走らせ、artifact delta の admissibility を判断する

6. `submit-for-approval`

reviewer に対して review package を差し出す

7. `approve`

reviewer が diff と tests を確認し、merge-readiness を ratify する

8. `promote`

code patch と accepted rationale を canonical 候補にする
edge-case playbook candidate は provisional に残す

9. `merge`

artifact と decision を durable state へ反映する

10. `close`

frame を completed にする

この例で分かるのは、process は単なる「実装した」ではなく、
assign / compile / execute / evaluate / approve / promote / merge の連鎖として意味を持つ ということです。

Transitions の不変条件

PCE 2.0 では、少なくとも次の不変条件を置きます。

1. Every significant process change must be attributable to a transition

意味のある process 変化は、何らかの transition として表現されなければなりません。

2. Every transition has an initiator and an authority basis

誰が起こしたかと、何の authority で起こしたかが必要です。

3. No merge without prior eval path

merge は evaluate を経た delta item に対してのみ起こりえます。

4. No hidden responsibility transfer

handoff、delegate、escalate は責任変化を明示しなければなりません。

5. No stale-context progression after invalidating transitions

context を stale にする transition の後は、必要なら recompile が必要です。

6. Checkpoint and recovery are first-class transitions

checkpoint / recover を mere implementation detail に落としてはなりません。
それらは process continuity の中核です。

7. Durable state changes trace back to transitions via deltas

durable state の canonical update は、どの transition / delta / authority から来たか追跡できなければなりません。

最低限の自己点検

ある process 設計が十分に transition-aware かどうかは、次で点検できます。

その process の意味的な境界を transition として言語化できるか
assign / handoff / approve / evaluate / merge / checkpoint / recover を区別できるか
transition ごとに initiator と authority を言えるか
どの transition が context を stale にするか分かるか
delta emission の境界を定義できるか
approval point と approve transition を区別できるか
recovery point と checkpoint / recover transition を区別できるか
rollback / replan / escalate の条件があるか
同一 frame 内の transition と child frame 分割を区別できるか
durable state の更新がどの transition chain から来たか説明できるか

このどれかが欠けるなら、その process はまだ「step の列」に留まっており、PCE 2.0 の意味で transition-aware ではありません。

暫定的なまとめ

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

process は、step の列としてではなく、責任・局所視界・差分・承認・評価・昇格・回復を変化させる型付き遷移の体系として理解されるべきである。

PCE 2.0 において、仕事は「進んだかどうか」だけでは記述できません。
誰が何の責任で何を変え、何を emitted し、何を評価し、何を durable にしたのかが必要です。

だから Transitions は、単なる workflow 記法ではありません。
それは、PCE 2.0 において process を 追跡可能・統治可能・再開可能なものとして成立させる意味論 です。