Lifecycle

定義

Lifecycle

Lifecycle とは、ある process frame が時間に沿って取りうる
意味的・統治的な状態の体系 である。

それは単なる進捗ラベルではなく、
existence、progression、gate status、resolution、recovery readiness を通して、
いま何が進行中で、何が止まっており、何が未解決で、何を次に合法的に行えるか を定める。

より短く言えば、Lifecycle とは
「この frame はいまどの状態にあり、何が pending で、どの next transition が legal か」を表す状態モデル である。

PCE 2.0 において process は、ただ「進んでいる / 終わった」で表現できない。
同じ feature delivery でも、

• まだ start してよい状態か
• active に work 中か
• approval 待ちか
• evaluation 待ちか
• blocked なのか intentionally suspended なのか
• recover 中なのか
• close してよいのか
• abandoned / superseded なのか

は明確に違う。

Lifecycle は、この違いを process semantics として保持する。

---

なぜ Lifecycle が必要なのか

PCE 2.0 が Lifecycle を独立概念として置くのは、
長時間・多段・多主体の process では「どこまで進んだか」だけでは不十分だからである。

少なくとも、次の問いに答えなければならない。

1. いま何が legal か

• execute してよいのか
• approval を待つべきか
• replan が必要か
• merge に近づいてよいか
• recover してよいか

2. いま何が pending か

• approval
• evaluation
• memory promotion review
• external dependency
• incident disposition

3. いま止まっているなら、それはどの種類の停止か

• blocked
• suspended
• pending approval
• pending evaluation
• recovering
• escalated

これらは同じ「止まっている」ではない。

4. 同じ phase の中でも状態が違う

implementation phase の中でも、

• active に実装中
• diff を出して review 待ち
• test fail で blocked
• checkpoint 後に suspended

は別状態である。

5. recovery と handoff は lifecycle を前提にする

何が active / suspended / stale / recoverable なのかが分からなければ、
Handoff も Checkpoint and Recovery も成立しない。

だから Lifecycle は、単なる進捗表示ではなく、
process が何を次にしてよいかを定める合法状態のモデル
として必要になる。

---

Lifecycle は何ではないか

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

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

「調査 → 実装 → テスト → レビュー」は phase や workflow の並びであって、
lifecycle そのものではない。
同じ phase にいても active / blocked / pending approval は区別される。

2. 単なるカンバン列ではない

UI 上の In Progress, Review, Done は lifecycle の粗い投影にすぎない。
PCE 2.0 の lifecycle は、authority、gate、recovery まで含む。

3. 単なる Process Frame ではない

Process Frame は構造的な仕事単位である。
Lifecycle は、その frame が時間に沿ってどの状態を取っているかを表す。

4. 単なる Transitions ではない

Transitions は状態変化そのもの。
Lifecycle は、その変化の前後で frame がどんな状態にあるかを表す。

5. 単なる delta lifecycle ではない

Process Delta にも emitted / evaluated / merged などの lifecycle がある。
しかし frame lifecycle と delta lifecycle は同一ではない。

6. 単なる approval point state ではない

approval point は構造、pending approval は lifecycle 上の状態である。
point と state を混同してはならない。

7. 単なる actor bundle の状態ではない

actor ごとの bundle の active / suspended 状態は lifecycle の一部材料だが、
frame lifecycle そのものではない。

---

Lifecycle が答える問い

Lifecycle は、少なくとも次の問いに答えるためにある。

• この frame は start 可能か
• いま active progression 中か
• いま何の gate で止まっているか
• その停止は healthy pause か failure か
• recover に入れるか
• replan / rollback / escalate が必要か
• close してよいか
• close するとしたら completed / abandoned / superseded のどれか

このため Lifecycle は、単一のラベルというより
legal next transition を規定する状態ベクトル
として理解した方が正確である。

---

Lifecycle は単一ラベルではなく状態ベクトルである

PCE 2.0 では、Lifecycle を単一 enum で表すより、
少なくとも四つの軸を持つ状態ベクトルとして考える方が自然である。

lifecycle(frame, t) =
  (
    existence_state,
    progression_state,
    gate_state,
    resolution_state,
    overlays
  )

1. Existence State

frame が存在論的にどの段階にあるか。

例:

• draft
• instantiated
• closed
• archived

2. Progression State

active に前進しているのか、止まっているのか、復元中なのか。

例:

• not_ready
• executable
• active
• blocked
• suspended
• recovering

3. Gate State

いま何の gate が unresolved なのか。

例:

• clear
• pending_evaluation
• pending_approval
• pending_promotion
• escalated

4. Resolution State

最終的にどう閉じる方向にあるか。

例:

• open
• completion_ready
• completed
• abandoned
• superseded

5. Overlays

incident や rollback など、他の状態軸に重なる特性。

例:

• incident_open
• rollback_pending
• replan_pending
• recovery_required
• drift_detected

このモデルの利点は、
同じ「review 中」に見える状態でも、

• active なのか
• pending approval なのか
• blocked なのか
• recovering なのか

を区別できることである。

---

Canonical Composite States

実務上は state vector を毎回そのまま使うより、
いくつかの代表的な複合状態として扱うと分かりやすい。
以下は PCE 2.0 における代表的な composite state である。

1. Draft

frame は定義され始めているが、まだ executable ではない状態。
goal、scope、actors、bundle、eval contract などが不十分である。

典型:

• instantiate 直後
• reframe 中
• major ambiguity unresolved

2. Executable

frame が start 可能な状態。
最低限必要な goal、scope、bundle、capability、gate 定義が揃っている。

重要なのは、executable は active と同じではないこと。
まだ誰も work を始めていないこともある。

3. Active

現在、legal な execution / evaluation / handoff / coordination が進行中の状態。

典型:

• analysis 実行中
• implementation 実行中
• review 実施中
• memory candidate triage 中

4. Pending Evaluation

required evaluator に subject が差し出され、
その verdict が揃うまで次へ進めない状態。

典型:

• required regression suite 待ち
• memory promotion eval 待ち
• trace grading 待ち

5. Pending Approval

required authority による ratification 待ちの状態。
evaluation が終わっていることもあれば、evidence 不足のまま submit されていることもある。

典型:

• spec approval 待ち
• code review approval 待ち
• risky resume approval 待ち

6. Blocked

何らかの unresolved condition により、通常の progression が legal または practical に不可能な状態。

典型:

• missing evidence
• unresolved ambiguity
• policy conflict
• missing dependency
• failed required check with no local remedy

7. Suspended

意図的に active progression を止めている状態。
blocked と違い、必ずしも failure ではない。
しばしば checkpoint とセットになる。

典型:

• later session へ持ち越し
• approver 不在待ち
• cross-team response 待ち
• controlled pause before risky transition

8. Recovering

Recovery Point から continuity を再構成中の状態。
この時点ではまだ active progression に戻っていない。
integrity check、drift reconciliation、context recompile などが進んでいる。

9. Completion Ready

frame として必要な work、gate、evidence が概ね揃い、
close / promote / merge の最終処理へ進める状態。

重要なのは、completion ready は completed ではないこと。
まだ final close や final durable mutation が残っている場合がある。

10. Completed

goal と success criteria に照らして十分と判断され、
frame が成功として閉じられた状態。

11. Abandoned

goal を達成しないまま、意図的に閉じられた状態。
未達であることを traceable に残すべきである。

12. Superseded

別の frame、reframe、higher-order process によって置き換えられた状態。
abandoned とは違い、「別の継続が採用された」ことを意味する。

13. Archived

active lifecycle の外へ出て、履歴として保持される状態。
archived は completed / abandoned / superseded の後に来ることが多い。

---

Lifecycle と Phase の違い

この区別は特に重要である。

Phase

work の内容上の区分である。

例:

• analysis
• implementation
• review
• promotion
• incident handling

Lifecycle State

その frame が process semantics 上どういう状態にあるかである。

例:

• active
• pending_approval
• blocked
• suspended
• recovering

同じ phase にいても lifecycle state は変わりうる。

例

implementation phase の中でも、

• active に実装中
• required eval 待ち
• reviewer 不在で suspended
• scope conflict で blocked
• rollback 後に recovering

はすべて違う。

したがって PCE 2.0 では、phase と lifecycle を別に持つべきである。

---

Lifecycle と Approval / Evaluation / Promotion の関係

Lifecycle は、gate をどこで抱えているかを示す。
特に重要なのは次の三つである。

Pending Evaluation

まだ required evaluation path が閉じていない。
この状態では通常、merge や close は legal ではない。

Pending Approval

authority による ratification が未了である。
approval point が open / pending であり、次の progression は gated である。

Pending Promotion

memory candidate や delta item が durable write path に乗っているが、
まだ canonical / provisional の実反映が未了である状態。

これらは見かけ上似ていても意味が違う。
Lifecycle がこれを区別することで、
「何を待っているのか」がはっきりする。

---

Lifecycle と Handoff の関係

Handoff は often lifecycle state を変える。

代表例

• active → pending_approval
  reviewer へ approval handoff した

• active → suspended
  cross-session handoff のため pause した

• child active → parent pending_return
  これは parent 側の view では unresolved child return として現れうる

• blocked → active
  handoff により specialized actor が引き取った

Handoff の重要点は、
単なる message transfer ではなく continuity の state change だということ。
したがって lifecycle は handoff 前後で変わるべきである。

---

Lifecycle と Checkpoint / Recovery の関係

Lifecycle は Checkpoint and Recovery を前提にして設計されるべきである。

Checkpoint の前後

• active → suspended
  later resume のために停止した

• pending_approval → suspended
  approval 待ちの continuity を durable にした

Recovery の前後

• suspended → recovering
  recovery point を再構成中

• recovering → active
  revalidation と context recompile を終えて resumed

• recovering → blocked / replan_pending
  drift や invalidation により straight resume が不可能

このように recovery-aware な process では、
lifecycle が continuity semantics を含む。

---

Lifecycle と Process Delta の関係

Lifecycle は frame の状態であり、delta の状態ではない。
しかし両者は強く結びつく。

例

• active 中に delta が emitted される
• emitted delta により pending_evaluation に入る
• evaluated delta により pending_approval に入る
• approved delta により completion_ready に近づく
• promoted / merged delta により completed が可能になる

したがって lifecycle は、
delta lifecycle を消費して frame-level progression を定める構造
と理解できる。

---

Lifecycle と Governance Surface の関係

Lifecycle は、Governance Surface が process にどう効いているかを、時間方向に見たものでもある。

例

• capability gate に引っかかる
  → active ではなく blocked になる

• approval surface が unresolved
  → pending_approval になる

• promotion surface が閉じたまま
  → pending_promotion / completion_ready どまり

• recovery surface が invalidation を検出
  → recovering から replan_pending へ

つまり lifecycle は、
governance が static に存在するだけでなく、
いつ process を止め、通し、遅らせ、収束させているか を示す。

---

Lifecycle は単一路ではない

PCE 2.0 では、lifecycle は一本道ではない。
よくあるのはループと分岐である。

例1: Rework loop

active
  -> pending_approval
  -> request_changes
  -> active
  -> pending_approval
  -> approve
  -> completion_ready

例2: Recovery loop

active
  -> checkpoint
  -> suspended
  -> recovering
  -> active

例3: Incident loop

active
  -> blocked
  -> escalation_pending
  -> replan_pending
  -> executable
  -> active

例4: Supersession

blocked
  -> reframe
  -> superseded

このため lifecycle は、「何番目の工程か」を表すのではなく、
状態空間の中をどう移るか を表す。

---

Lifecycle と Parent / Child Process の関係

親子 frame では、lifecycle が入れ子になる。

親 frame

• child の return を待って open のままいる
• child failure により blocked になる
• child completion により completion_ready に近づく

子 frame

• 自分自身の active / pending / completed を持つ

ここで重要なのは、child の completed が parent の completed を意味しないこと。
child は parent lifecycle を変える要因だが、同一ではない。

このため parent-child process では、

• child lifecycle
• parent lifecycle
• relation lifecycle

を分けて考えるのが有用である。
詳しくは Parent-Child Process を参照。

---

Lifecycle と Escalation / Rollback の関係

これらは lifecycle を大きく変える遷移である。

Escalation

通常 progression では処理不能な問題を上位 / 別系統へ引き上げる。
しばしば

• blocked
• escalation_pending
• suspended

を伴う。

Rollback

以前の許容状態へ戻る。
roll back 後は

• active に戻ることもある
• recovering に入ることもある
• replan_pending に入ることもある

つまり escalation / rollback は、
lifecycle 上の「例外的だが正常に設計されるべき」分岐である。
詳しくは Escalation と Rollback を参照。

---

Lifecycle の最小スキーマ

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

process_lifecycle:
  frame_id:
  existence_state:
  progression_state:
  gate_state:
  resolution_state:
  overlays:
  current_phase:
  active_subject_refs:
  pending_gate_refs:
  active_bundle_refs:
  suspended_bundle_refs:
  current_recovery_ref:
  last_transition_ref:
  legal_next_transitions:
  invalidation_conditions:
  provenance:

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

lifecycle_snapshot:
  frame_ref:
  state:
    existence:
      # draft | instantiated | closed | archived
    progression:
      # not_ready | executable | active | blocked | suspended | recovering
    gate:
      # clear | pending_evaluation | pending_approval | pending_promotion | escalated
    resolution:
      # open | completion_ready | completed | abandoned | superseded
    overlays:
      - incident_open
      - rollback_pending
      - replan_pending
      - recovery_required
  phase_ref:
  active_subjects:
  gate_refs:
  bundle_refs:
  legal_next_transitions:
  evidence_refs:
  timestamp:

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

1. phase と lifecycle state を分けている
2. gate を独立に持てる
3. overlays で incident / rollback を表せる
4. legal next transitions が出せる
5. bundle / gate / recovery ref に接続できる

---

小さな例

feature.checkout.coupon-combination frame の lifecycle は、たとえば次のように進む。

1. Frame 定義直後

state:
  existence: instantiated
  progression: not_ready
  gate: clear
  resolution: open
  overlays: []
current_phase: planning

まだ spec-analysis child frame も bundle 配分も不足しているので executable ではない。

2. Spec-analysis 開始

state:
  existence: instantiated
  progression: active
  gate: clear
  resolution: open
  overlays: []
current_phase: analysis

3. Spec candidate 完了後

state:
  existence: instantiated
  progression: suspended
  gate: pending_approval
  resolution: open
  overlays: []
current_phase: spec_review

ここで product owner の spec approval を待つ。

4. Spec approval 後、実装中

state:
  existence: instantiated
  progression: active
  gate: clear
  resolution: open
  overlays: []
current_phase: implementation

5. Implementation 完了後、review 待ち

state:
  existence: instantiated
  progression: suspended
  gate: pending_evaluation
  resolution: open
  overlays: []
current_phase: review_preparation

CI evaluator と reviewer の判定待ち。

6. Review pass 後

state:
  existence: instantiated
  progression: executable
  gate: pending_promotion
  resolution: completion_ready
  overlays: []
current_phase: promotion

artifact / decision / failure memory の promote / merge を待っている。

7. Merge 完了後

state:
  existence: closed
  progression: suspended
  gate: clear
  resolution: completed
  overlays: []
current_phase: closed

8. 後に archive

state:
  existence: archived
  progression: suspended
  gate: clear
  resolution: completed
  overlays: []

ここで重要なのは、review は phase であり、
pending_approval や pending_evaluation は lifecycle state だということだ。

---

Lifecycle の不変条件

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

1. Every frame has a lifecycle state

frame は常に何らかの lifecycle state にあるべきである。
「いま何状態か分からない frame」は不完全である。

2. Legal next transitions depend on lifecycle

どの遷移が合法かは lifecycle に依存する。
active と pending_approval では、許される next transition が違う。

3. Phase and lifecycle must remain distinguishable

phase を lifecycle の代わりにしてはならない。
「review 中」が pending_approval なのか active review なのかは別である。

4. Pending gate states must be recoverable

pending approval / evaluation / promotion は later recovery でも失われてはならない。

5. Lifecycle must change when governance-relevant state changes

approval が通った、bundle が revoke された、policy drift が起きた、recover に入った、などは lifecycle に反映されるべきである。

6. Closed is not always completed

close には completed / abandoned / superseded など複数の resolution meaning がある。

7. Recovery is not active progression

recovering state と active state を混同してはならない。

8. Lifecycle is frame-scoped

delta lifecycle や actor bundle lifecycle を、そのまま frame lifecycle と混同してはならない。

---

いつ lifecycle を進めるべきで、いつ新しい frame を切るべきか

これは実務上かなり重要である。

Lifecycle state の変化でよい場合

• goal identity は保たれている
• success criteria は大きく変わっていない
• authority topology は局所的変更に留まる
• work は同じ frame の continuation である

例:

• active → pending_approval
• active → blocked
• suspended → recovering
• completion_ready → completed

新しい frame を切るべき場合

• goal が実質的に別になった
• success criteria が別物になった
• approval / incident / memory topology が大きく変わった
• child に独立した return contract が必要
• reframe の結果、旧 frame を supersede すべき

短く言えば、
同じ仕事の状態変化なら lifecycle、
仕事単位そのものが変わるなら新しい frame
である。

---

最低限の自己点検

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

1. その frame がいま active / blocked / suspended / recovering のどれか言えるか
2. phase と lifecycle state を区別できるか
3. pending approval / evaluation / promotion を別状態として持てるか
4. legal next transitions を state に応じて言えるか
5. recovery 後に active へ直行できるとは限らないことを扱えるか
6. completed / abandoned / superseded を区別できるか
7. gate 状態が later recovery で失われないか
8. lifecycle change が transitions と結びついているか
9. child frame の完了と parent frame の完了を混同していないか
10. incident / rollback / replan を overlays または例外状態として扱えているか

このどれかが欠けるなら、その process はまだ lifecycle を十分に持っていない。

---

関連する概念

Lifecycle は、PCE 2.0 の process semantics の時間軸として、次の概念と強く結びつく。

• Process Frame
• Transitions
• Handoff
• Approval Points
• Checkpoint and Recovery
• Process Delta
• Responsibility Bundle
• Actor-local Compiled Context
• Governance Surface
• Recovery Point
• Eval Contract
• Parent-Child Process
• Branch and Join
• Escalation
• Rollback

---

暫定的なまとめ

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

process は、「やっているか終わったか」では足りない。
いま何が active で、何が pending で、何が blocked で、何が legal で、どの条件で close できるのかを状態として持ってはじめて、長時間・多主体の仕事を継続可能にできる。

PCE 2.0 において lifecycle は、単なるステータス表示ではない。
それは、process の合法状態、gate 状態、回復可能性、終端意味を束ねる状態モデルである。

だから Lifecycle は、単なる kanban status ではない。
それは、PCE 2.0 において process が時間に沿ってどのように存在し、止まり、回復し、閉じるのかを定める継続状態の意味論 である。