Rollback

定義

Rollback

Rollback とは、ある process frame において、現在の execution path、subject state、gate state、delta path、または durable mutation path が
このまま継続してはならない と判断されたときに、
それを以前の acceptable state、approved boundary、またはより狭い safe baseline へ戻し、
以後の legal next transitions を再構成する transition である。

それは単なる「元に戻すこと」ではなく、
rollback target、rollback anchor、rollback horizon、invalidated state、required records、recovery path、re-entry rule を含む。

より短く言えば、Rollback とは
「いまの続け方は process として成立しない、または成立させるべきでない」と判断したときに、どこまでを無効化し、どの時点まで戻し、どの条件で再開・再計画・終了するかを定める遷移
である。

PCE 2.0 において rollback は、失敗の副産物ではない。
それは、異常・逸脱・不整合・誤昇格・危険な継続を、process を壊さずに止めて戻すための正規遷移である。

この意味で Rollback は、
Transitions の中でも
continuity preservation と governed correction を最も強く表す遷移の一つである。

なぜ Rollback が必要なのか

PCE 2.0 が rollback を独立に扱うのは、
すべての問題が単なる local rework では済まないからである。

少なくとも、次の状況では rollback が必要になる。

1. 現在の path がこのままでは不正または危険である

prohibited capability が使われた
out-of-scope change が混入した
required approval を飛ばして先へ進んだ
stale context をもとに重要な変更をした
recovery 不能な状態へ近づいている

この場合、「あとで直せばよい」では不十分であり、
現在 path の継続自体を止める必要がある。

2. いまの state を future process の前提にしてはいけない

wrong decision path が parent や sibling branch へ波及している
invalid delta が promotion path に乗っている
canonical / provisional の扱いを誤った
old approval や old eval が now-invalid になっている

この場合 rollback は、future process を守るために必要である。

3. local rework では integrity が回復しない

単に patch を追加したり説明を足したりするだけでは、
process 上の不整合が消えないことがある。

例:

subject 自体が wrong scope に基づいている
phase の入り口条件を満たしていない
child return 全体が stale になっている
branch join 前提が崩れている

4. incident 後に safe baseline が必要になる

incident が起きた後、いまの continuation をそのまま引きずるより、
以前の許容状態へ戻してから replan / rework した方が安全なことがある。

5. rollback しないと escalation / recovery / merge の意味が壊れる

rollback がないと、
異常 state を抱えたまま escalation や recovery を重ねることになり、
何が current truth で何が invalid path なのか分からなくなる。

だから Rollback は、
「失敗したから戻る」 ではなく
「この path を current admissible continuation として維持してはならないから戻る」
という意味で必要になる。

Rollback は何ではないか

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

1. 単なる Undo ではない

Undo は局所的な取り消しであり、しばしば user-interface 的である。
Rollback は process semantics 上の遷移であり、

何を invalid にするか
どこを再び pending にするか
どの gate を reopen するか
どの authority で戻すか

を伴う。

2. 単なる Git revert ではない

code revert は artifact rollback の一形態にはなりうるが、
rollback はそれだけではない。
必要なら次も巻き戻す。

approval state
evaluation state
promotion path
branch integration state
recovery assumptions

3. 単なる Reject ではない

reject は特定 subject を current path で先へ進めない verdict である。
rollback は、それに加えて すでに積み上がった state を以前の baseline へ戻す ことを含む。

4. 単なる Rework ではない

rework は current path の中で subject を修正する。
rollback は current path 自体の正当性を失わせ、より前の baseline へ戻す。

5. 単なる Recovery ではない

recover は Recovery Point から continuity を再構成することである。
rollback は、どの baseline に戻すかを決め、その baseline 以降の state を invalid にする。
rollback の後に recover が続くことはよくあるが、同一ではない。

6. 単なる Abandon ではない

abandon は frame や path を閉じる。
rollback は、閉じるためではなく、戻してから続ける / 再計画する / 別 path に移る ために使われることが多い。

7. 単なる責任逃れではない

rollback は「なかったことにする」ための操作ではない。
むしろ、何が wrong path だったかを traceable に残したうえで current continuation を正す操作である。

Rollback が扱う subject

PCE 2.0 における rollback は、artifact に限らない。
少なくとも次のような対象が rollback subject になりうる。

1. Artifact Subject

code patch
config change
spec update
generated migration script

2. Gate Subject

approval satisfaction
evaluation pass state
merge readiness
promotion readiness

3. Delta Subject

emitted delta item
pending promotion candidate
integrated branch return
stale child return

4. Runtime Subject

active frame state
branch integration state
suspended / resumed continuity
pending review state

5. Topology Subject

branch set result
child frame continuation
reframe path
delegated path

6. Durable Mutation Subject

wrong canonical memory write
mistaken promotion
governance record update
invalid decision memory

つまり rollback は、
何かを「前へ進める」 path そのもの を対象にしうる。
これが単なる code revert と大きく違う点である。

Rollback target, anchor, horizon

Rollback を曖昧にしないために、PCE 2.0 では少なくとも三つの概念を分けて考えるとよい。

1. Rollback Target

何を戻したいのか、何を invalid にしたいのか。

例:

current artifact delta
current review state
current branch integration result
current provisional promotion path
current frame progression state

2. Rollback Anchor

どこまで戻るのか。
「最後に process として許容可能だった基準点」である。

例:

approved spec boundary
after-analysis checkpoint
last green commit
pre-merge recovery point
pre-branch integration state

anchor はしばしば Recovery Point を参照するが、
必ずしも recovery point に限らない。
明示的な approved version や canonical durable item version が anchor になることもある。

3. Rollback Horizon

どこまで広く戻すか。
rollback の範囲である。

例:

local work only
current phase
current child frame
all siblings after a join point
parent frame progression
canonical durable write itself

Rollback を適切に設計するには、
何を戻すか、どこまで戻るか、どれだけ広く戻すか
を分けて扱う必要がある。

Rollback の主な型

PCE 2.0 では、少なくとも次の rollback type を区別できる。

1. Local Work Rollback

現在の local execution だけを戻す。
主に child frame や single actor scope の中で完結する。

例:

current code edits を捨てる
current generated summary を撤回する
local experiment branch を破棄する

2. Gate Rollback

一度通過した gate を reopened / invalid にする。

例:

old approval を stale として無効化する
old evaluation verdict を invalidate する
merge-ready state を剥がす

これは artifact は変えず、process admissibility を戻す rollback である。

3. Delta Rollback

既に emitted された delta item を current path から外す。
retracted、superseded、invalidated といった状態へ移す。

例:

invalid memory candidate を promotion path から外す
stale child return を join 候補から外す

4. Runtime Rollback

frame の progression state をより前の acceptable runtime state へ戻す。

例:

pending approval 前まで戻す
recovering から safe suspended state へ戻す
active から rollback_anchor へ戻す

5. Durable Rollback

すでに durable state に反映された変更を retracted / superseded / archived する。
これは最も強い rollback の一つであり、通常は強い authority を要する。

例:

canonical decision memory を supersede する
wrong governance record を retract する
mistaken operational memory write を retire する

6. Topology Rollback

branch / child / reframe などの process topology を以前の形へ戻す。

例:

new branch set を abandon する
wrong child frame path を閉じる
failed reframe を元の frame meaning に戻す

7. Incident Rollback

incident containment の一部として、広い blast radius をもつ current path を以前の safe baseline へ戻す。
多くの場合、incident owner の関与を要する。

Semantic rollback と material rollback

Rollback は、必ずしも「物理的に全部消す」ことを意味しない。
PCE 2.0 では次の二つを分けると有用である。

1. Material Rollback

実際の artifact や runtime state を戻す。

例:

code revert
branch state reset
checkpoint restore

2. Semantic Rollback

history を消さず、current admissibility や canonical status を戻す。

例:

approval invalidation
old delta を retracted にする
promoted item を superseded にする
joined branch result を non-current に戻す

この distinction は重要である。
なぜなら PCE 2.0 では、traceability を保つために history を消さないことが多いからである。
rollback は often current truth の変更 であって、過去の痕跡の消去 ではない。

Rollback と他の遷移の違い

Rollback と Rework

Rework
current path を維持したまま subject を修正する
Rollback
current path の admissibility を失わせ、以前の baseline に戻す

rework は「この path はまだ正しいが内容が足りない」。
rollback は「この path を基準にしてはいけない」。

Rollback と Recover

Recover
recovery point から continuity を再構成する
Rollback
どの baseline を current acceptable state とし直すかを決める

多くの場合、rollback → recover → resume という連鎖になる。

Rollback と Reject

Reject
subject を current path で先へ進めない
Rollback
current state の一部を以前の baseline へ戻す

reject だけでは足りない場合に rollback が必要になる。

Rollback と Replan

Replan
これから先の path を設計し直す
Rollback
今の path を以前の baseline へ戻す

しばしば rollback のあとに replan が来る。
逆に replan の結果 rollback が不要と判断されることもある。

Rollback と Escalation

Escalation
authority overflow を上位へ返す
Rollback
authority が current path を invalid にして baseline へ戻す

rollback の判断はしばしば escalation の結果として下る。

Rollback は compound transition であることが多い

実装上は一つのボタンに見えても、PCE 2.0 での rollback はしばしば複合遷移である。

典型的には少なくとも次を含む。

Detect invalidity
何が admissible でなくなったかを確認する
Freeze unsafe continuation
active progression、merge、promotion、approval を止める
Select anchor and horizon
どこまで、どれを戻すかを決める
Invalidate gates / deltas / contexts
stale approval、stale eval、stale local context を invalid にする
Perform material and/or semantic rollback
必要な state を戻す
Emit rollback-related deltas / records
rollback note、retraction note、incident note などを出す
Choose post-rollback path
recover / resume / rework / replan / abandon / close のどれに進むか決める

このため rollback は、「元に戻す操作」というより
current path invalidation + baseline restoration + next-path selection
として理解した方が正確である。

誰が rollback を決め、誰が rollback を実行するか

PCE 2.0 では、rollback decision と rollback execution は分離しうる。

1. Local executor can perform bounded rollback

実行者が、自分の scope 内の local rollback を自分で行えることがある。

例:

uncommitted local edit を捨てる
local generated artifact を撤回する

ただしこれは bounded であるべきで、
gate や durable state まで勝手に戻してはならない。

2. Approver / evaluator can require rollback

reviewer や evaluator が rollback 必要と判断しても、
実際に rollback authority を持つとは限らない。
多くの場合、request rollback や rollback recommended を出す。

3. Incident owner or retained authority may order rollback

広い rollback、特に

parent-level rollback
durable rollback
branch-set rollback
risky post-merge rollback

は incident owner、goal owner、release owner などの retained authority を要することが多い。

4. Runtime may execute rollback mechanically

anchor が明確で、authority が事前に与えられていれば、
runtime が rollback transition を実行することはありうる。
ただし authority basis と audit trail が必要である。

つまり rollback にはしばしば

rollback detector
rollback recommender
rollback authorizer
rollback executor

の分化がある。

Rollback と Process Delta の関係

Rollback は often 新しい Process Delta を生む。
しかも「何を戻したか」は future process にとって重要な知識になる。

rollback から生まれうる delta

1. Status / Coordination Delta

rollback initiated
rollback completed
gate reopened
child return invalidated

2. Governance Delta

previous approval invalidated
merge freeze
exception path closed
policy violation note

3. Failure Delta

reusable rollback lesson
anti-pattern note
why current path became invalid

4. Recovery Delta

rollback anchor selected
post-rollback recovery point created

5. Durable Delta

canonical memory superseded
wrong item retracted
promotion path cancelled

ここで重要なのは、rollback は history を消すのではなく、
history の意味を更新し、その更新自体を delta として残す ことが多い点である。

Rollback と Durability の関係

rollback は durable state との関係で特に慎重であるべきである。

durable write 前 rollback

まだ canonical に書かれていないなら、
rollback は主に current runtime / delta path の問題で済む。

例:

pending code patch を撤回する
pending memory candidate を reject する

durable write 後 rollback

すでに canonical に入ったものを戻す場合は、
単純な「削除」ではなく、しばしば次が必要になる。

retract record
superseding item
historical trace
downstream invalidation
re-evaluation of dependent items

PCE 2.0 では durable rollback は強い操作であり、
通常は explicit authority と explicit records を要する。

Rollback と Lifecycle の関係

Rollback は lifecycle を大きく変える。
典型的には、次のような遷移を生む。

active
  -> rollback_pending
  -> recovering
  -> active | replan_pending | abandoned | superseded

あるいは、

pending_approval
  -> rollback_pending
  -> open

や

completion_ready
  -> rollback_pending
  -> blocked

のようにもなる。

重要なのは、rollback が occurred したこと自体が
lifecycle 上の意味的 state change だということである。
詳しくは Lifecycle を参照する。

Rollback と Handoff の関係

Rollback は often Handoff と組み合わさる。

rollback order handoff

incident owner や approver が executor に rollback を指示する handoff。

rollback evidence handoff

evaluator / reviewer が rollback 必要性の evidence を authority sink に渡す。

post-rollback handoff

戻したあとに、別 actor へ rework / re-evaluation / replan を渡す。

このとき handoff package には少なくとも次が必要になる。

rollback target
rollback anchor
why rollback is required
what became invalid
what remains valid
next expected action after rollback

つまり rollback は current work を単に止めるだけでなく、
次の continuation のための boundary を作る。

Rollback と Parent-Child / Branch-and-Join の関係

Parent-Child

child frame で起きた rollback が、親へどう波及するかを明示すべきである。

child-local rollback only
child rollback + parent waiting
child rollback + parent replan pending
child rollback + parent incident escalation

親が retain している authority を超える rollback は、親へ返す必要がある。

Branch-and-Join

branch set では rollback の範囲が重要になる。

one branch rollback only
all sibling branches back to pre-join anchor
comparative branch loser branches abandoned
integrated join result rollback to branch returns

つまり rollback horizon は、topology に応じて設計される。

Rollback と Checkpoint / Recovery の関係

Rollback は often Checkpoint and Recovery と組み合わさる。

rollback anchor としての recovery point

多くの場合、rollback anchor は recovery point か、それに準ずる safe baseline である。

典型フロー

detect invalidity
  -> freeze progression
  -> choose rollback anchor
  -> rollback to anchor
  -> recover from anchor
  -> resume or replan

recovery without rollback との違い

recover だけで済むのは、current path の admissibility をまだ維持できるときである。
current path 自体が wrong なら、recover の前に rollback が必要になる。

rollback without recover の場合

非常にローカルな rollback では、recover を明示しなくてもよいことがある。
たとえば local generated file を削除するだけなら、same active continuation のまま進められる。

いつ rollback すべきか

これは実務上最も重要な判断の一つである。

rollback すべき典型条件

current path の scope / policy / authority 正当性が失われた
current approval / eval state が stale になった
current branch integration 前提が崩れた
local rework では current path の integrity を回復できない
durable write の前提が誤っていた
recovery legality が current state では成立しない

rollback しなくてよい典型条件

local rework で十分戻せる
evidence を追加すれば current approval / evaluation path が成立する
current path 自体はまだ admissible である
issue は clarification だけで解決できる
output は不足しているが wrong path ではない

短く言えば、
「もっと良くしたい」ではなく「この path を current baseline にしてはいけない」ときに rollback する
と考えるとよい。

Rollback の最小スキーマ

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

rollback_transition:
  transition_id:
  frame_id:
  source:
    actor_ref:
    bundle_ref:
  rollback_subject:
    kind:
    refs:
    scope:
  trigger:
  target:
    kind:
    refs:
  anchor:
    kind:
    ref:
  horizon:
    # local | phase | child_frame | branch_set | parent_frame | durable
  authority_basis:
  invalidations:
    approvals:
    evaluations:
    contexts:
    deltas:
    branch_joins:
  material_actions:
  semantic_actions:
  required_records:
  next_path:
    recover | resume | rework | replan | escalate | abandon | close
  recovery_binding:
  provenance:

もう少し package 指向に書くなら、次のようにも置ける。

rollback_plan:
  rollback_id:
  current_frame_ref:
  reason:
  what_is_invalid_now:
  rollback_target:
  rollback_anchor:
  rollback_horizon:
  retained_valid_state:
  invalidated_state:
  execution_orders:
  gate_reopen_rules:
  delta_retraction_rules:
  durable_mutation_rules:
  authority_refs:
  expected_post_rollback_state:
  next_transition_options:
  evidence_refs:
  audit_refs:

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

target / anchor / horizon が分かれている
material と semantic の両アクションがある
invalidated state を明示する
authority basis がある
post-rollback path がある
audit / provenance がある

つまり rollback は、
単なる「戻せ」ではなく governed rollback plan として扱うべきである。

小さな例

feature.checkout.coupon-combination frame において、
reviewer が payment gateway 変更混入を検出し、product owner が rollback を命じるケースを考える。

rollback_transition:
  transition_id: rb.feature.checkout.coupon-combination.scope-violation.v1
  frame_id: feature.checkout.coupon-combination
  source:
    actor_ref: product_owner
    bundle_ref: product_owner_goal_incident_bundle
  rollback_subject:
    kind: artifact_and_review_path
    refs:
      - delta_item.code_patch
      - review_state.current
    scope: feature.checkout.coupon-combination
  trigger: out_of_scope_payment_gateway_change_detected
  target:
    kind: current_implementation_path
    refs:
      - delta.feature.checkout.coupon-combination.v3
  anchor:
    kind: recovery_point
    ref: rp.feature.checkout.coupon-combination.after-spec-approval.v1
  horizon: phase
  authority_basis:
    - goal_ownership
    - incident_ownership
  invalidations:
    approvals:
      - code_review_approval_pending
    evaluations:
      - reviewer_preliminary_eval
    contexts:
      - coding_agent_impl_context_v2
      - reviewer_review_context_v1
    deltas:
      - delta_item.code_patch
      - delta_item.accepted_rationale_if_depends_on_invalid_scope
    branch_joins: []
  material_actions:
    - revert_changed_payment_gateway_files
    - restore_checkout_files_to_anchor_ref
  semantic_actions:
    - mark_current_review_path_invalid
    - reopen_implementation_phase
    - retain_failure_note_for_possible_memory_candidate
  required_records:
    - rollback_note
    - scope_violation_record
    - affected_delta_refs
  next_path: rework
  recovery_binding:
    use_anchor_then_recompile_coding_agent_context: true
  provenance:
    created_from:
      - escalation.scope_conflict.v1

この例で重要なのは、

rollback が単なる code revert ではなく
review path や preliminary evaluation も invalid にし
old contexts を stale 化し
その後の rework continuation を再構成している

点である。

Rollback の不変条件

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

1. No rollback without explicit target and anchor

何を戻し、どこまで戻るのかが必要である。

2. Rollback must not erase traceability

rollback は history を消すために使ってはならない。
what was invalid and why を追えるべきである。

3. No rollback without invalidation semantics

approval、eval、contexts、deltas の何が invalid になるか明示すべきである。

4. No durable rollback without strong authority basis

canonical state を戻すなら、強い authority と records が必要である。

5. Rollback must define post-rollback path

戻したあとに何をしてよいかがなければならない。

6. Rollback must preserve retained valid state when possible

不要に全部を壊すのではなく、何がまだ valid かを保持すべきである。

7. Rollback and recovery must not be conflated

anchor に戻すことと、そこから安全に継続することは別である。

8. Child / branch rollback propagation must be explicit

局所 rollback が parent や sibling にどう効くか明示されなければならない。

9. Stale approvals and stale contexts must not survive rollback silently

current path に依存していたものは invalid にすべきである。

10. Rollback should minimize blast radius while restoring admissibility

戻しすぎても、戻さなすぎてもいけない。
acceptable continuation を回復するのに十分な horizon を選ぶべきである。

最低限の自己点検

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

何を rollback target として扱うのか言えるか
どの anchor に戻るのか言えるか
rollback horizon を決められるか
rollback と rework / reject / recover / replan を区別できるか
何が invalid になり、何が still valid か分かるか
rollback authority を言えるか
rollback 後の legal next transitions を定義できるか
durable rollback が traceable か
parent-child / branch set で propagation を扱えるか
rollback note や affected delta record を残せるか

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

暫定的なまとめ

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

process が壊れたときに必要なのは、ただ前に進むことでも、全部をなかったことにすることでもない。
いまの continuation を current baseline として維持してよいかを問い、維持してはいけないなら、何を invalid にし、どこまで戻し、何を残し、どの path でやり直すかを定めることが rollback である。

PCE 2.0 において rollback は、単なる revert 操作ではない。
それは、current path を admissible な continuation に戻すための governed correction である。

だから Rollback は、単なる「元に戻す」ではない。
それは、PCE 2.0 において 不適切な continuation を停止し、許容可能な baseline へ戻し、以後の継続を再構成する corrective transition である。