Feature Delivery

このページは、PCE 2.0 の概念を抽象的に説明するのではなく、
ひとつの feature delivery が実際にどのような frame、actor、bundle、context、gate、delta、memory update として進むかを追うためのケーススタディである。

ここで扱うシナリオは仮想だが、意図的に現実の開発に近い形にしてある。
目的は「こう実装すべき」という標準実装を示すことではなく、
PCE 2.0 の各概念がどこで何を説明するのかを、ひとつの具体的な流れで貫通させることにある。

このケースの目的

このケースでは、次のことを同時に見たい。

1. feature delivery を Process Frame としてどう立ち上げるか
2. actor ごとに Responsibility Bundle がどう分かれるか
3. Actor-local Compiled Context がどのように変わるか
4. Process Delta が artifact 以外も含むこと
5. Approval Points と Eval Contract がどこで働くか
6. Memory Promotion Rules と Memory Promotion Criteria が何を残すかをどう選ぶか
7. Checkpoint and Recovery が long-running な仕事の継続性をどう支えるか

つまりこのケースは、PCE 2.0 の理論を一つの実務フローとして読むための最小貫通例である。

---

シナリオ

対象は、EC サービスの checkout に対する小さく見えて実は影響範囲の広い変更である。

機能要求
checkout に「クーポン併用制約」を導入する。
既存の購入フローを損なわず、既存クーポンとの後方互換性を保ちつつ、
新しい制約ルールを validation / pricing / tests / review / operational note まで含めて反映する。

この feature がケースとして良いのは、単なるコード変更では終わらないからである。
次のような問いが自然に発生する。

• 仕様上、どのクーポンが併用不可なのか
• 既存の precedence rule と衝突しないか
• checkout total の determinism は保たれるか
• どこまでが in-scope で、何を触ってはいけないのか
• merge 前に誰が何を承認すべきか
• 今回得られた failure lesson や review checklist を future process のために残すべきか

このように、feature delivery という一見単純な仕事の中に、
PCE 2.0 のほぼすべての論点が入っている。

---

全体像

このケース全体を PCE 2.0 の流れとして短く書くと、次のようになる。

Issue / request
  ↓
Parent Process Frame (feature delivery)
  ↓
spec-analysis child frame
  ↓
spec approval
  ↓
implementation child frame
  ↓
evaluation + review handoff
  ↓
approval point
  ↓
promotion / merge
  ↓
durable project state update
  ↓
close

ただし重要なのは、これは単なる工程列ではないということだ。
実際には各段階で、

• responsibility が配分され
• actor-local context が compile され
• delta が emitted され
• gate が開閉し
• 必要に応じて checkpoint が切られ
• durable state に戻すものが選別される

という運動が起きている。

---

初期状態

この feature に着手する前、project にはすでに次のような Durable Project State があるとする。

Canonical にあるもの

• checkout pricing flow の仕様
• coupon precedence に関する既存 ADR
• 現行の validation 実装
• 既存の regression test suite
• checkout 関連の review checklist
• merge に reviewer approval が必要という governance record

Provisional にあるもの

• 過去の pricing 変更から残った edge-case notes
• 古い coupon redesign の rejected proposal
• 以前の release で残された pending checklist candidate

ここで重要なのは、この feature が完全な白紙から始まらないことだ。
新しい frame は、既存 durable state を前提にして起動する。

---

親フレーム

このケースの最上位 frame は、次のように書ける。

process_frame:
  frame_id: feature.checkout.coupon-combination
  parent_frame_id: release.checkout.spring-2026
  goal: >
    checkout にクーポン併用制約を導入し、
    既存の pricing / validation flow を損なわずに運用可能な形で反映する
  success_criteria:
    - 制約仕様が承認されている
    - 対象コードに変更が反映されている
    - required regression suite が通過している
    - rollback path が明示されている
    - 今回の変更から得られた durable memory 候補が評価されている
  scope:
    in_scope:
      - coupon validation logic
      - checkout pricing flow
      - related tests
      - decision rationale
      - operational notes if warranted
    out_of_scope:
      - payment gateway changes
      - marketing rule redesign
      - coupon domain model full rewrite
  actors:
    - product_owner
    - analyst_agent
    - coding_agent
    - reviewer
    - ci_evaluator
    - memory_writer
    - checkpoint_manager
  approval_points:
    - spec_approval
    - code_review_approval
  eval_contract:
    - eval.feature.checkout.coupon-combination.artifact.v1
    - eval.checkout.operational-memory.v1
  memory_write_policy:
    promote:
      - accepted_decision_rationale
      - reusable_failure_lesson
      - operational_memory_candidate_if_reusable
    reject:
      - raw_working_notes
      - unverifiable_hypotheses
  recovery_strategy:
    checkpoint_policy:
      - after_spec_approval
      - after_implementation
      - before_merge
    escalation_path: product_owner

この frame が重要なのは、「クーポン併用制約を実装する」という task を、
最初から goal・scope・approval・eval・memory write・recovery を持つ単位として定義している点である。

---

主な actor と bundle

このケースでは、少なくとも次の actor が主要になる。

Product Owner

• goal_ownership
• spec approval authority
• final incident ownership
• escalation receiver

Analyst Agent

• spec analysis の execution
• impact analysis の execution
• decision candidate の提示

Coding Agent

• implementation execution
• limited write scope
• local test execution
• implementation delta の emission

Reviewer

• code review execution
• approval authority for code change
• scope / rollback / rationale の確認
• memory candidate の一次評価

CI Evaluator

• deterministic test evaluation
• required regression suite の blocking evaluation

Memory Writer

• memory_write_authority
• promoted candidate の最終昇格判断

Checkpoint Manager

• checkpoint creation
• recovery orchestration
• resumable state reconstruction

この段階ですでに、feature delivery が「実装者一人の仕事」ではなく、
複数 actor の bundle が切り替わる process であることが見える。

---

ケース本体

以下、実際の進行を段階的に追う。

---

0. Frame の起動

起きること

issue が起票され、parent frame が instantiate される。
ここでまだ誰もコードを書いていない。
しかし PCE 2.0 的には、すでに重要なことが起きている。

• frame identity が作られる
• actors が enrollment される
• responsibility allocation が設定される
• spec approval と code review approval という approval topology が先に定義される
• checkpoint policy と memory write policy が先に入る

関連する概念

• Process Frame
• Actor
• Responsibility Bundle
• Transitions

ここでのポイント

この段階ではまだ outcome は何もない。
それでも process は始まっている。
これが PCE 2.0 の process-first な見方である。

---

1. Spec-analysis child frame

親 frame は、まず仕様確認と影響分析を独立した child frame として切り出す。

1-1. Decompose

親 frame から child frame が作られる。

child_frame:
  frame_id: feature.checkout.coupon-combination.spec-analysis
  parent_frame_id: feature.checkout.coupon-combination
  goal: >
    仕様案を整理し、影響範囲と未解決論点を特定し、
    parent frame が spec approval に進める状態を作る
  actors:
    - analyst_agent
    - product_owner

1-2. Analyst Agent の local context

analyst agent には、次のような actor-local context が compile される。

• approved されている checkout spec の relevant 部分
• coupon precedence に関する ADR の抜粋
• 現行 validation 実装の read-only view
• 既知の regression failures の要約
• out-of-scope: payment gateway changes
• expected output:
  • spec summary
  • impact analysis
  • unresolved issues
  • decision candidates

ここで重要なのは、analyst agent に 書き込み権限はない ことだ。
goal slice は明確だが、capability surface は read-only に制限されている。

1-3. Child frame の結果

analyst agent は次のような Process Delta を返す。

• decision delta
  「payment gateway changes は out-of-scope とする」
• decision delta
  「coupon precedence rule の再利用が前提」
• artifact-like summary delta
  approved spec draft candidate
• status delta
  unresolved issue: stacked discount rounding edge case
• failure/rejection delta
  「domain model full rewrite は過剰であるため reject 候補」

1-4. Child → Parent return handoff

child frame は親 frame に、単なる長文メモではなく次を返す。

• spec summary
• impact analysis
• unresolved issues
• decision candidates
• required next action: spec approval

この段階で見えること

artifact はまだ何も merge されていない。
しかし process としては十分意味のある成果が出ている。
つまりこの child frame は artifact delivery ではなく decision preparation を outcome とする frame である。

---

2. Spec approval

親 frame は Approval Point に到達する。
この point の subject は spec candidate であり、approver は product owner である。

必要なもの

• spec summary
• unresolved issues list
• scope note
• required spec review evidence

起こりうる verdict

• approve
• reject
• request_changes
• escalate

今回の流れ

product owner は、未解決事項を1つ残したままでも implementation phase に進めると判断する。
ただし次を条件とする。

• rounding edge case は implementation note に明示する
• reviewer は rollback feasibility も確認する

ここで approve が出ると、実装 phase を legal に開始できる。

ここで重要なこと

spec approval は eval を置き換えない。
spec candidate はすでに最低限の review を受けている。
approval point はその上で goal owner が ratify する構造 である。

---

3. Implementation child frame

次に parent frame は implementation 用の child frame を作る。
ここで context と bundle は spec-analysis 時とは大きく変わる。

3-1. Coding Agent の bundle

• execution: implementation
• capability authority: limited write
• approval authority: none
• memory_write_authority: none
• incident ownership: none

3-2. Coding Agent の local context

coding agent 用の context は、次のように compile される。

• approved spec summary
• target files
• existing tests
• coupon precedence rule summary
• prohibition:
  • payment gateway edit
  • unrelated module edit
  • production access
• expected output:
  • code diff
  • updated tests
  • implementation note
• stop conditions:
  • failing regression tests
  • scope violation detected
  • unresolved spec conflict

重要なのは、spec-analysis child frame で analyst agent に見せていたものと完全には一致しないことだ。
同じ project state を使っていても、context は actor-local に変わる。

3-3. 実装の進行

coding agent は実装を進める。
その過程で、単なる code patch だけではなく次の差分が生まれる。

• artifact delta
  coupon validation code change
• artifact delta
  related tests update
• failure delta
  naive threshold check が precedence regression を起こした
• decision-supporting note
  rollback note
• status delta
  implementation completed

3-4. Checkpoint

implementation 完了時点で checkpoint を切る。
これは後の review / recovery を楽にするためである。

この checkpoint は少なくとも次を保持する。

• frame state: pending review handoff
• emitted delta refs
• pending gates:
  • required regression confirmation
  • reviewer approval
• stale_on_recover:
  • coding agent implementation context
• recompile_required_for:
  • reviewer
  • memory_writer

ここで重要なのは、checkpoint が transcript 保存ではなく、
review へ進むための continuity 保存 になっている点である。

---

4. Reviewer への handoff

実装が終わったら、coding agent から reviewer へ handoff が起きる。

handoff package に含まれるもの

• goal slice
  「approved spec に対して code change が適合しているか判断する」
• transferred responsibility
  review execution
• retained responsibility
  goal ownership / incident ownership / memory write authority
• evidence refs
  code diff, test results, approved spec summary, rollback note
• pending gates
  required regression suite confirmation, code review approval
• unresolved issues
  stacked discount rounding edge case
• expected output
  approval verdict, review comments, accepted rationale or rejection reason

ここで重要なこと

reviewer は coding agent の prompt 全体をそのまま受け取らない。
reviewer 用の actor-local context が、handoff package を材料として再コンパイルされる。

つまり handoff は「source context のコピペ」ではなく、
continuity package を source から target に渡し、target 用 local context を再生成する遷移 である。

---

5. Evaluation と review

review では outcome と process の両方が評価される。

Outcome 側

• diff が仕様に合っているか
• tests が十分か
• rollback path があるか

Process 側

• scope violation がないか
• required gate を飛ばしていないか
• required evidence が揃っているか
• stale / weak rationale で進んでいないか

CI Evaluator の役割

CI evaluator は blocking evaluator として働く。
required regression suite が失敗した場合、reviewer が良さそうだと思っても merge readiness は成立しない。

Reviewer の役割

reviewer は human evaluator であり、同時に approval authority を持つ。
ただしこの二つは概念上は別である。

• evaluation: diff / rationale / rollback / scope を判断する
• approval: merge readiness を ratify する

今回のケース

CI は pass する。
reviewer は edge case note を含めれば accept 可能と判断し、approve を出す。

ここで parent frame の次の legal transition が開く。

---

6. Memory candidate の抽出

この feature では、artifact merge とは別に memory promotion 候補が生まれる。

候補1: Failure lesson

naive threshold check が precedence regression を起こした、という failure lesson。

候補2: Approved rationale

payment gateway changes は out-of-scope であり、coupon precedence rule を再利用する、という decision rationale。

候補3: Operational checklist candidate

coupon-related pricing changes を review するときの edge-case checklist。

候補4: Raw implementation note

coding agent の局所メモ。

ここで重要なのは、これらを全部同じように durable 化しないことだ。

---

7. Memory promotion evaluation

memory writer は各 candidate を評価する。

Failure lesson

• reuse value: 高
• scope boundedness: 高
• provenance: 高
• evidence adequacy: 高
• verdict: canonical failure memory へ promote

Approved rationale

• reuse value: 高
• authority trace: 高
• scope boundedness: 高
• verdict: canonical decision memory へ promote

Operational checklist candidate

• actionability: 高
• reuse value: 中〜高
• decontextualization: 中
• repeatability evidence: まだ弱い
• verdict: provisional pending candidate に留める

Raw implementation note

• decontextualization: 低
• reuse value: 低
• provenance: あっても local noise が多い
• verdict: reject promotion

ここで見えるのは、artifact correctness と memory worthiness が全く別だということだ。
code patch が merge できても、implementation note は memory として reject されうる。

---

8. Promote / Merge / Close

ここで初めて durable state が更新される。

Canonical に入るもの

• code artifact update
• tests update
• approved decision rationale
• failure memory

Provisional に残るもの

• operational checklist candidate
• checkpoint history
• pending edge-case note if further confirmation required

Reject されるもの

• raw implementation notes
• unverifiable local hypotheses

Close

親 frame は completed として close される。
ただし完全に消えるのではなく、trace、approval records、promotion records は audit surface 上に残る。

---

このケースでの durable state 更新

このケースの前後で durable project state を比べると、重要なのは code だけではない。

Before

• 現行 checkout spec
• coupon precedence ADR
• review checklist v1

After

• canonical code / tests 更新
• decision memory:
  • coupon combination は precedence rule 再利用前提
  • payment gateway changes は out-of-scope
• failure memory:
  • naive threshold check regression
• operational memory:
  • edge-case checklist candidate は provisional
• evaluation memory:
  • required regression suite record
• governance record:
  • review approval record

これにより、future process は「今回何があったか」だけでなく、
何を学んだか、何が採用され、何がまだ候補か を再利用できる。

---

recovery を伴う分岐例

ここまでは素直な流れだった。
ここで reviewer がすぐ対応できず、翌日別 session で review を再開するケースを考える。

何が起きるか

implementation 完了後に切った checkpoint から recover が行われる。

recover でやること

• recovery point の integrity check
• required refs が存在するか確認
• spec や governance rule に drift がないか確認
• coding agent context を stale 扱いにする
• reviewer 用 context を再コンパイルする
• pending approval point を reopening する

なぜこれが重要か

単にチャット履歴を開くだけでは、

• 何が pending approval だったか
• 何が stale か
• 何を reviewer が判断すべきか
• 次の legal transition は何か

が曖昧になりやすい。

PCE 2.0 では、review の再開は transcript continuity ではなく
governed continuation として扱われる。

---

このケースを PCE 2.0 なしでやると何が壊れやすいか

この比較は重要である。
同じ feature delivery を、PCE 2.0 的な frame / bundle / gate / delta / durable state を意識せずに進めた場合、典型的には次が起こる。

1. “ひとつの巨大な context” に押し込む

誰に何を見せるべきかが曖昧になり、reviewer に不要なノイズが増え、coding agent に不要な authority が漏れやすくなる。

2. spec approval と code review が曖昧になる

「たぶん仕様はこれでよい」「CI が通ったからたぶん merge してよい」が起こりやすい。

3. failure lesson が消える

artifact が正しく見えると、その背後の失敗知や rejected alternative が durable に残らない。

4. memory pollution が起こる

良さそうな note を全部残し、後で stale / duplicate / local noise が durable state を汚す。

5. review 再開が transcript 依存になる

翌日レビューで「どこまで決まっていたか」が会話履歴頼みになり、gate continuity が弱くなる。

PCE 2.0 は、この feature delivery を単に整然と見せるためではなく、
壊れ方を抑えるため に必要になる。

---

このケースで見るべき process metrics

この feature delivery を process として観測するなら、少なくとも次が有効である。

Handoff Completeness Rate

coding agent → reviewer の handoff が十分だったかを見る。
rollback note や unresolved issue が欠けていると下がる。

Approval Cycle Time

review approval にかかった時間。
ただし速ければ良いわけではなく、後続の rework rate とセットで読む。

Eval Coverage Ratio

required eval が本当に通ったかを見る。
blocking evaluator を飛ばしていないか確認できる。

Recovery Success Rate

翌日の review recovery が legal resume につながったかを見る。

Corrupt Success Rate

もし reviewer approval を飛ばして merge したら、outcome は良くても process は悪い。
このケースを可視化できる。

Memory Promotion Precision

今回 promote した failure memory や decision memory が、後続の feature delivery で実際に再利用されるかを見る。

このように metrics は、artifact 自体ではなく
この feature delivery の壊れ方と継続性 を観測する。

---

このケースが示していること

このケースを通して見える PCE 2.0 の特徴は、少なくとも次のとおりである。

1. Feature delivery は task ではなく frame である

実装作業だけでなく、approval、memory、recovery を含む単位として扱われる。

2. Context は actor ごとに変わる

同じ project state からでも、analyst、coder、reviewer、memory writer で view は異なる。

3. Artifact 以外も process の成果である

decision、failure、evaluation、governance、recovery も delta として扱われる。

4. Approval と eval は別である

CI が pass しても、approver が ratify しなければ先へ進めない。

5. Memory promotion は merge のおまけではない

artifact merge と memory worthiness は別の問題である。

6. 長い仕事は recovery semantics を要する

review が翌日にずれても、frame / gate / bundle continuity を失わずに再開できる必要がある。

---

このケースの最終要約

この feature delivery を一文で要約すると、次のようになる。

PCE 2.0 における feature delivery とは、
issue を実装して終わることではなく、
goal を frame として立て、責任を配分し、actor ごとの局所 context を compile し、
child frame と handoff を通して仕事を進め、
eval と approval を経た delta だけを canonical state に戻し、
さらに future process に効く knowledge だけを選別して memory に昇格させ、
途中で止まっても recovery semantics によって継続可能にすること
である。

この意味で、feature delivery は単なる delivery ではない。
それは、PCE 2.0 が扱う process architecture の最も基本的な実例である。

---

このあとに読むとつながるページ

• Process Frame
• Responsibility Bundle
• Actor-local Compiled Context
• Process Delta
• Handoff
• Approval Points
• Checkpoint and Recovery
• Outcome vs Process
• Process Metrics
• Memory Promotion Rules
• Memory Promotion Criteria