Cases

このセクションは、PCE 2.0 の概念を「定義の集合」としてではなく、 実際の仕事がどのように壊れ、どのように整理され、どのように governed に進むのか を concrete に読むための入口である。

ここにあるケースは、単なる examples ではない。それぞれが、PCE 2.0 の違う側面を強く照らす。

Feature Delivery は全体像を示す

PR Review は approval / stale invalidation / corrupt success を強く示す

Bug Triage は routing / escalation / incident ownership を強く示す

Research Loop は question freeze / branch-and-join / provisionality を強く示す

Human-AI Handoff は actor symmetry / responsibility asymmetry / continuity package を強く示す

つまりケース群は、PCE 2.0 の理論を五つの方向から切って見せる断面である。

このセクションの役割

cases セクションの役割は、大きく三つある。

1. 抽象概念を process として見る

Process Frame、Responsibility Bundle、Process Delta、Handoff、Corrupt Success のような語が、どんな局面で必要になるのかを concrete に示す。

2. “壊れ方” を可視化する

PCE 2.0 の概念の多くは、理論を美しく見せるためではなく、実務で起きる failure mode を見えるようにするためにある。 cases は、その failure mode を最も分かりやすく示す。

3. 読む順番の違いを許す

このサイト全体は一本道ではあるが、入口は一つではない。 cases セクションは、読者が自分の関心や課題に近い場所から入れるようにする。

まずどのケースを読むべきか

迷ったら、最初は Feature Delivery を読むのがよい。理由は単純で、もっとも広く、もっとも標準的で、PCE 2.0 の背骨が一通り入っているからである。

ただし、関心がはっきりしているなら入口を変えた方が早い。

一般的な最初の一本

Feature Delivery もっともバランスがよく、Process Frame、Responsibility Bundle、Process Delta、Approval、Memory Promotion、Recovery が一通り見える。

「PCE 2.0 の新しさ」を最短で見たい

PR Review approve と eval の違い、stale invalidation、Corrupt Success が非常に分かりやすい。

incident / routing / release risk に関心がある

Bug Triage report と defect を分けること、routing frame、Escalation、Incident Ownership が強く見える。

research / strategy / adoption decision に関心がある

Research Loop question freeze、仮説 branch、counterevidence、provisional recommendation が中心になる。

human と AI の協働設計に関心がある

Human-AI Handoff human と AI が同じ actor plane にいながら、責任は非対称であることがもっともよく見える。

ケース比較表

ケース	最初に読むとよい人	強く示すもの	そのケースの主要 output
Feature Delivery	全体像を先に掴みたい人	frame、bundle、delta、approval、memory、recovery	実装・評価・昇格を含む end-to-end flow
PR Review	governance / review / approval に関心がある人	review frame、stale invalidation、approval vs evaluation、corrupt success	approve / request changes / escalate
Bug Triage	incident / routing / severity に関心がある人	report→subject 正規化、branch-and-join、incident routing、duplicate 判定の危うさ	bugfix / incident / duplicate / hold への routing
Research Loop	exploratory work や adoption decision に関心がある人	question freeze、hypothesis branches、counterevidence、reframe、provisionality	adopt / pilot / defer / reject recommendation
Human-AI Handoff	AI 協働を process として設計したい人	continuity package、retained authority、bounded autonomy、stale invalidation	human↔AI 間の governed handoff loop

各ケースが何を強く示すか

ここでは、各ケースを「どの概念が特に見えやすいか」という観点で短く整理する。

1. Feature Delivery

Canonical case として最も重要な一本である。

強く見える概念

このケースが特に示すこと

feature delivery は「コードを書くこと」ではなく、goal から durable state 更新までを含む frame である
artifact 以外にも、decision、failure、operational note が delta として出る
child frame と handoff により、多主体の flow が整理できる
memory promotion は merge のおまけではない

どんな読者に向くか

PCE 2.0 の first case としてもっとも向いている
「この理論は開発全体をどう見ているのか」を知りたい人に向く

2. PR Review

このケースは、PCE 2.0 の governance の価値をもっとも早く見せる。

強く見える概念

このケースが特に示すこと

review は diff inspection ではなく独立 frame である
approve と pass は同じではない
old review state や old approval は new commit で easily stale になる
“見た感じ問題ない” は current truth を汚すことがある
reviewer は artifact だけでなく process を見ている

どんな読者に向くか

「PCE 2.0 が本当に新しいものを言っているのか」を早く確かめたい人
review, merge, governance の壊れ方に関心がある人

3. Bug Triage

このケースは、曖昧な problem signal をどう governed continuation に変えるかを示す。

強く見える概念

このケースが特に示すこと

incoming report はそのまま bug ではない
triage は label 付けではなく routing frame である
reproduction / spec consistency / blast radius は parallel branch にできる
duplicate closure や premature low-severity closureも corrupt success になりうる
local bugfix と incident path を同一視してはならない

どんな読者に向くか

release risk、severity、incident routing に関心がある人
“triage の質が後段をどう壊すか” を見たい人

4. Research Loop

このケースは、PCE 2.0 が implementation だけの理論ではないことを示す。

強く見える概念

このケースが特に示すこと

research では question freeze が first-class である
plausible narrative は簡単に corrupt success になる
prototype success は adoption readiness を意味しない
branch ごとの反証や counterevidence を later recommendation に保持しなければならない
provisional recommendation と canonical decision memory は別である

どんな読者に向くか

research、strategy、architecture decision に関心がある人
“問いが揺れる仕事” を PCE 2.0 でどう扱うか見たい人

5. Human-AI Handoff

このケースは、PCE 2.0 の actor symmetry / responsibility asymmetry をもっとも具体的に示す。

強く見える概念

このケースが特に示すこと

human と AI は同じ process network 上の actor である
しかし goal ownership、approval、incident closure、canonical write は対称ではない
transcript の引き継ぎではなく continuity package が必要である
human-only evidence が later に入ると AI の old context は stale になる
bounded autonomy を保つには retain / delegate / escalate の設計が必要である

どんな読者に向くか

AI 協働設計を “prompt 設計” 以上のものとして考えたい人
actor symmetry を具体例で理解したい人

標準的な読み順

迷ったときの標準順は、次のように置ける。

標準ルート

この順の理由は明確である。

Feature Delivery で全体像を掴む
PR Review で governance と stale invalidation を深める
Bug Triage で routing / incident を見る
Research Loop で探索型仕事へ広げる
Human-AI Handoff で actor topology を横断的に見る

つまり、 標準開発 -> review -> incident entry -> exploratory work -> human/AI continuity の順に広げる読み方である。

関心別の読み順

governance を先に見たい

AI 協働から入りたい

exploratory work から入りたい

incident / release risk から入りたい

ケース同士の関係

各ケースはバラバラではない。むしろ、相互に zoom in / zoom out の関係にある。

Feature Delivery はベースライン

他の多くのケースは、これを特定局面で拡大したものとして読める。

PR Review は Feature Delivery の review 相を拡大したもの

feature の一部工程を独立 frame として見ることで、approval / stale invalidation / corrupt success が見えやすくなる。

Bug Triage は release / support signal 側から見た routing frame

feature delivery の外から incoming signal が入ったときに、どう current process へ接続するかを扱う。

Research Loop は implementation 以前 / adoption decision 側の探索 frame

feature を作る前に、何を作るべきか / 採用すべきかを governed に決める。

Human-AI Handoff はすべてを横断する

feature delivery、review、triage、research のどれにも現れる actor transition を抽出したケースである。

この関係を意識すると、ケース群は “個別の例” ではなく 同じ理論の異なる断面 として読める。

ケースを読むときのコツ

1. “何が output か” を見る

cases では output が artifact とは限らない。

PR Review の output は verdict である
Bug Triage の output は routing である
Research Loop の output は recommendation である
Human-AI Handoff の output は continuity package と reviewed candidate である

この違いを見ると、PCE 2.0 が artifact-first でないことがよく分かる。

2. “どこで current truth が決まるか” を見る

各ケースで、

何が delta に留まり
何が provisional で
何が later approve / promote / close されるのか

を見ると、PCE 2.0 の durability semantics が見えやすい。

3. “どこで壊れやすいか” を見る

cases の価値は、きれいな流れを見せることではない。むしろ、

stale approval
weak duplicate closure
prototype overclaim
transcript-only handoff

のような壊れ方が、どの概念で可視化されるかを見るとよい。

ケースを読んだあとに戻るとよいページ

case を読んだあとに spec へ戻るなら、次の組み合わせが特に有効である。

Feature Delivery のあと

PR Review のあと

Bug Triage のあと

Research Loop のあと

Human-AI Handoff のあと

このセクションをどう使うか

最も自然な使い方は次のようになる。

1. 興味のあるケースを一本読む

まず concrete な flow を見る。

2. そのケースで分からなかった語を引く

3. 強く出ていた spec ページへ戻る

cases と spec を往復する。

4. 別のケースへ移る

同じ概念が別の壊れ方で出てくることを確認する。

この往復をすると、PCE 2.0 の概念が “定義” ではなく “必要だった語” として見えてくる。

暫定的なまとめ

このページが言いたいことは、最終的には次の一文に集約できる。

PCE 2.0 のケースは、理論をあとから説明するための装飾ではない。それぞれが、開発・レビュー・トリアージ・調査・human/AI 協働のどこで process が壊れやすく、どの概念がその壊れ方を見えるようにするのかを示す入口である。

迷ったら、まずは Feature Delivery から入るのがよい。そこから関心に応じて PR Review、Bug Triage、Research Loop、Human-AI Handoff へ広げていくと、cases セクション全体が一つの地図として読めるようになる。