Durable Project State

定義

Durable Project State

Durable Project State とは、ある project において、複数の process frame、複数の session、複数の actor をまたいでも参照・継承・再利用される
型付きの永続状態 である。

それは単なる情報の保管庫ではなく、
canonical artifacts、decision memory、failure / rejection memory、operational memory、evaluation memory、governance records、recovery points を、
それぞれの status、provenance、authority、scope、freshness、retention とともに保持する。

より短く言えば、Durable Project State とは
「この project について、将来の process が何を前提としてよく、何を参照でき、何を再利用でき、何をまだ provisional として扱うべきか」を保持する永続層
である。

PCE 2.0 において、開発は毎回ゼロから始まりません。
新しい Process Frame は、Durable Project State を読み、その上に局所的な責任と局所コンテキストを構築します。
さらに process の結果は Process Delta として返り、評価を通ったものだけが Durable Project State を更新します。

この意味で Durable Project State は、
PCE 2.0 の循環における 持続する基盤状態 です。

なぜ Durable Project State が必要なのか

AI 時代の開発では、長い context window があっても、それだけでは長時間の仕事は成立しません。
本当に必要なのは、次のことです。

何を次の process へ持ち越すのか
何を忘れてよいのか
何を canonical とみなすのか
何を provisional のまま留めるのか
何を workflow knowledge として再利用するのか
何が承認済みで、何が未確定なのか

これらを毎回チャット履歴や作業ログから再構成するのは不安定です。
必要なのは、将来の process が依拠できる 持続的な project-level state です。

Durable Project State は、そのための概念です。

言い換えると、Durable Project State は
「会話を超えて project を継続させるための制度化された記憶」
です。

`Durable` / `Project` / `State` の意味

この概念は三つの語から成り、それぞれに意味があります。

Durable

一時的な run や session を越えて残る、という意味です。
単に長く保存されるだけでなく、後続の process が参照可能であること が重要です。

Project

個人の思いつきや単発の conversation ではなく、
ある project、feature line、repository、initiative に紐づくという意味です。
Durable Project State は actor 個人の私的メモリではなく、project の継続性に属します。

State

単なる情報の集合ではなく、
「今この project がどのような状態として採用されているか」を表すという意味です。
ここには artifacts だけでなく、決定、却下、評価履歴、承認痕跡、運用知も含まれます。

Durable Project State は何ではないか

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

1. 単なるファイル置き場ではない

repository や drive は素材になりえますが、それだけで Durable Project State とは限りません。
何が canonical で、何が pending で、何が rejected で、何が reusable なのかが分からなければ state にはなりません。

2. 単なるチャット履歴ではない

会話履歴は raw material にはなりますが、そのまま durable state ではありません。
履歴は冗長で、責任状態や採用済み判断が明確でないことが多いからです。

3. 単なる検索インデックスではない

検索可能であることは有用ですが、state の中心は検索性ではありません。
中心にあるのは、何を project の正規状態として採用しているか です。

4. 単なるメモリ機構ではない

memory という語はしばしば想起を意味しますが、Durable Project State はそれより強いです。
それは project の持続的な存在条件であり、将来の process の前提そのものです。

5. 単なる canonical artifacts だけでもない

コードや仕様書だけでは足りません。
なぜその状態になったのか、何を却下したのか、どの評価を通ったのか、今後どう運用するのかも state に含まれます。

6. 単なるアプリケーションの実運用データではない

本番 DB や business runtime state は、そのまま Durable Project State ではありません。
必要なら snapshot、contract、schema、運用上の前提として project 側に取り込まれますが、両者は区別されます。

Durable Project State の基本構造

PCE 2.0 では、Durable Project State を少なくとも二つの層に分けて考えます。

1. Canonical Zone

将来の process が「前提として依拠してよい」とみなされる正規状態です。
ここにあるものは、評価・承認・promotion を経た内容です。

2. Provisional Zone

一時保存はされているが、まだ canonical とはみなされていない状態です。
checkpoint、pending promotion candidates、検証中の仮説、途中メモなどが入りえます。

この区別は重要です。
PCE 2.0 は、「保存されているもの」と「正規状態として採用されているもの」を同一視しません。

したがって Durable Project State は、単一の平坦な箱ではなく、
canonical と provisional を型付きで区別した永続層 です。

Canonical Zone に含まれるもの

1. Canonical Artifacts

project が現在採用している成果物です。

code
specification
ADR
tests
schema
runbook
approved summaries
release notes

これらは「いま何が作られているか」を表します。

2. Decision Memory

なぜそう決めたのかを保持する層です。

accepted decisions
rationale
alternatives considered
trade-offs
decision scope
supersession history

成果物だけを残して理由を失うと、将来の process は再び同じ議論をやり直します。

3. Failure / Rejection Memory

何を却下し、何が失敗し、何を避けるべきかを保持する層です。

rejected approaches
failed experiments with reusable lessons
scope violations
known anti-patterns
do-not-repeat decisions

PCE 2.0 では、成功だけが durable になるわけではありません。
評価済みの失敗知 も durable になりえます。

4. Operational Memory

再利用可能な手順知・実務知です。

skills
playbooks
workflows
checklists
conventions
integration recipes
incident response patterns

これは「何を作ったか」ではなく、「どう進めるとうまくいくか」を保持します。

5. Evaluation Memory

何がどう評価されたかを保持する層です。

eval results
grading rubrics
accepted thresholds
regression baselines
review outcomes
trace judgments
quality history

この層があることで、将来の process は過去の評価条件や品質水準を再利用できます。

6. Governance Records

権限・承認・ポリシーに関わる永続情報です。

approval records
policy decisions
authority boundaries
escalation rules
audit-relevant annotations
scope constraints

これは、将来の process がどの governance 条件の下で動くべきかを支えます。

Provisional Zone に含まれるもの

1. Recovery Points

再開可能な checkpoint です。

session checkpoint
paused run state
pending approval state
resumable summaries
restart metadata

これは durable ですが、canonical ではありません。

2. Pending Promotion Candidates

durable state に残す候補だが、まだ eval / approval を完了していないものです。

proposed memory entries
tentative playbooks
unratified summaries
candidate decisions
promotion queues

3. Experimental / Working Notes

一時的に保持したいが、まだ project の正規状態として採用していないものです。

working hypotheses
raw investigation notes
partial findings
scratch structures with project value
exploratory branches

ここで重要なのは、provisional であることが明示されている ことです。
未評価の内容が canonical と混ざってはなりません。

Durable Project State を構成する単位は「型付き項目」である

Durable Project State は、大きな文書の集合というより、
型とメタデータを持つ durable item の集合 として理解した方がよいです。

各 durable item には、少なくとも次の属性が必要です。

1. Kind

それが何の型か。
artifact、decision、failure memory、evaluation record、recovery point など。

2. Status

canonical か、provisional か、superseded か、retracted か、archived か。

3. Scope

どの feature、module、service、release、policy scope に属するか。

4. Provenance

どの process frame / delta / authority / evidence から生まれたか。

5. Authority

誰または何がそれを承認・昇格・更新したか。

6. Freshness / Validity

いつ時点で有効か、どの条件のもとで妥当か。

7. Retention

いつまで保持するのか、いつ archive / retire されるのか。

この型付けがあることで、Durable Project State は単なる保管庫ではなく、
将来の process が安全に参照できる状態空間 になります。

`No merge without eval` との関係

Durable Project State の中心原理は、
No merge without eval によって支えられています。

ここで重要なのは、書き込みが二種類あることです。

1. Provisional Write

checkpoint や pending candidate のように、provisional zone に書き込む操作です。
これは後で再開・再評価するために必要であり、必ずしも full promotion を伴いません。

2. Canonical Promotion

ある delta を canonical zone に昇格させる操作です。
これは将来の process の前提になるため、eval と authority を要します。

したがって PCE 2.0 では、
durable に書くこと と canonical に昇格すること を区別します。

この区別があるからこそ、

checkpoint は保存できる
しかし未評価の summary は canonical にはならない
pending playbook は持てる
しかし reusable operational memory としてはまだ扱わない

という設計が可能になります。

Durable Project State と Process Frame の関係

Durable Project State は、Process Frame の外側にある巨大な背景ではありません。
それは frame と直接に循環しています。

frame が state から受け取るもの

canonical artifacts
accepted decisions
rejected approaches
operational memory
evaluation history
governance constraints
recovery points

frame が state へ返すもの

evaluated artifact delta
accepted decision delta
useful failure / rejection delta
evaluation delta
updated operational memory
updated governance records
recovery points

つまり、Durable Project State は
frame の入力源であり、評価済み結果の受け皿 です。

Durable Project State と Actor-local Compiled Context の関係

Actor-local Compiled Context は、Durable Project State から直接生まれるわけではありません。
しかし重要な素材の大部分は Durable Project State から供給されます。

概念的には、次のようになります。

actor_local_context(actor, frame, t) =
  compile(
    process_frame,
    responsibility_bundle(actor, frame, t),
    durable_project_state,
    runtime_state(t)
  )

ここで Durable Project State が提供するのは、たとえば次です。

current canonical artifacts
approved summaries
decision rationale
known failures
applicable playbooks
evaluation baselines
authority and policy records
resumable checkpoints

したがって Durable Project State が粗いと、
actor-local context も安定して compile できません。

Durable Project State と Process Delta の関係

Durable Project State は静的な倉庫ではありません。
それは Process Delta を受けて変化します。

ただし、すべての delta が同じように state を更新するわけではありません。

artifact delta

canonical artifacts を更新しうる。

decision delta

decision memory を更新しうる。

failure / rejection delta

failure memory を更新しうる。

evaluation delta

evaluation memory を更新しうる。

operational delta

skills や playbooks を更新しうる。

recovery delta

recovery points を更新しうる。

このように Durable Project State は、
型付き delta を型付き zone へ反映する永続基盤
として理解されます。

by-value と by-reference

Durable Project State のすべてを巨大な blob として保存する必要はありません。
むしろ多くの場合、by-value と by-reference の使い分けが必要です。

by-value

内容そのものを durable item として保持する。

short rationale
checklist
accepted summary
evaluation verdict

by-reference

外部 artifact への参照を durable item として保持する。

repository path + commit ref
document URI
issue / PR ID
dataset version handle
model / policy version

この使い分けにより、Durable Project State は

必要なものは直接保持し
大きなものは参照で持ち
しかし provenance と status は project 側で管理する

という構造を取れます。

State は「全部残すこと」ではなく「残し方を設計すること」

Durable Project State の目的は、あらゆるものを保存することではありません。
むしろ重要なのは、何をどの型で残すかを設計すること です。

残しすぎると、

canonical と provisional が混ざる
stale な判断が残る
local noise が reusable memory を汚す
future context compilation の精度が落ちる

逆に残さなすぎると、

decision rationale が失われる
同じ失敗を繰り返す
workflow knowledge が蓄積しない
再開や引き継ぎが困難になる

したがって Durable Project State の本質は、
保存量ではなく 選別と型付け にあります。

Durable Project State の最小スキーマ

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

durable_project_state:
  project_id:
  canonical:
    artifacts:
    decisions:
    failure_memory:
    operational_memory:
    evaluation_memory:
    governance_records:
  provisional:
    recovery_points:
    pending_candidates:
    working_notes:
  indexes:
    provenance:
    scope:
    authority:
    freshness:
    retention:

より item 指向に書くなら、各項目は次のような型を持ちます。

durable_item:
  item_id:
  kind:
  status:
  scope:
  payload_or_ref:
  provenance:
    source_frame:
    source_delta:
    evidence_refs:
  authority:
  freshness:
  retention:

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

canonical / provisional が分かれている
item ごとに provenance と authority がある
state が「中身」だけでなく「採用条件」を持つ

小さな例

「checkout にクーポン併用制約を追加する」project の一部として、Durable Project State が次のように見えるとします。

durable_project_state:
  project_id: checkout
  canonical:
    artifacts:
      - item_id: artifact.spec.coupon-combination.v1
        kind: specification
        status: canonical
        scope: feature.checkout.coupon-combination
        payload_or_ref:
          doc_ref: docs/checkout/coupon-combination.md
        provenance:
          source_frame: feature.checkout.coupon-combination
          source_delta: decision_delta_v2
          evidence_refs:
            - spec_review_approval
        authority: product_owner
        freshness: current
        retention: active

      - item_id: artifact.code.coupon-validation.patch-20260308
        kind: code_ref
        status: canonical
        scope: feature.checkout.coupon-combination
        payload_or_ref:
          commit_ref: abc1234
          files:
            - src/checkout/coupon_validation.ts
            - tests/checkout/coupon_validation.test.ts
        provenance:
          source_frame: feature.checkout.coupon-combination
          source_delta: artifact_delta_v1
          evidence_refs:
            - ci_green_run_554
            - review_approval_20260308
        authority: reviewer
        freshness: current
        retention: active

    decisions:
      - item_id: decision.no-payment-gateway-change
        kind: decision
        status: canonical
        scope: feature.checkout.coupon-combination
        payload_or_ref:
          summary: payment gateway changes are out of scope
        provenance:
          source_frame: feature.checkout.coupon-combination
          source_delta: decision_delta_v1
          evidence_refs:
            - approved_spec_summary
        authority: product_owner
        freshness: current
        retention: active

    failure_memory:
      - item_id: failure.naive-stackable-threshold-check
        kind: failure_memory
        status: canonical
        scope: feature.checkout.coupon-combination
        payload_or_ref:
          summary: naive threshold check caused regression on existing coupon precedence
        provenance:
          source_frame: feature.checkout.coupon-combination
          source_delta: failure_delta_v1
          evidence_refs:
            - failed_test_run_552
        authority: reviewer
        freshness: current
        retention: active

    operational_memory:
      - item_id: opmem.checkout-review-checklist
        kind: checklist
        status: canonical
        scope: checkout
        payload_or_ref:
          summary: review checklist for coupon-related pricing changes
        provenance:
          source_frame: release.checkout.spring-2026
          source_delta: operational_delta_v1
          evidence_refs:
            - repeated_review_notes
        authority: memory_writer
        freshness: current
        retention: active

    evaluation_memory:
      - item_id: eval.checkout-regression-baseline
        kind: evaluation_record
        status: canonical
        scope: checkout
        payload_or_ref:
          summary: required regression suite for pricing-related changes
        provenance:
          source_frame: release.checkout.spring-2026
          source_delta: evaluation_delta_v1
          evidence_refs:
            - ci_policy_update_202603
        authority: ci_evaluator
        freshness: current
        retention: active

    governance_records:
      - item_id: gov.checkout-coupon-approval-rule
        kind: governance_record
        status: canonical
        scope: feature.checkout.coupon-combination
        payload_or_ref:
          summary: coupon validation changes require reviewer approval before merge
        provenance:
          source_frame: release.checkout.spring-2026
          source_delta: governance_delta_v1
          evidence_refs:
            - policy_update_note
        authority: product_owner
        freshness: current
        retention: active

  provisional:
    recovery_points:
      - item_id: checkpoint.feature.checkout.coupon-combination.after-implementation
        kind: recovery_point
        status: provisional
        scope: feature.checkout.coupon-combination
        payload_or_ref:
          checkpoint_ref: cp-20260308-01
        provenance:
          source_frame: feature.checkout.coupon-combination
          source_delta: recovery_delta_v1
          evidence_refs: []
        authority: runtime
        freshness: current
        retention: short_term

    pending_candidates:
      - item_id: candidate.playbook.coupon-edge-cases
        kind: pending_operational_memory
        status: provisional
        scope: checkout
        payload_or_ref:
          summary: possible playbook for coupon edge-case verification
        provenance:
          source_frame: feature.checkout.coupon-combination
          source_delta: memory_candidate_v1
          evidence_refs:
            - implementation_note
        authority: memory_writer_pending
        freshness: current
        retention: pending_review

    working_notes:
      - item_id: note.unverified-edge-case-hypothesis
        kind: working_note
        status: provisional
        scope: feature.checkout.coupon-combination
        payload_or_ref:
          summary: hypothesis about stacked discount rounding edge case
        provenance:
          source_frame: feature.checkout.coupon-combination
          source_delta: working_note_v1
          evidence_refs: []
        authority: coding_agent
        freshness: volatile
        retention: short_term

この例で重要なのは、同じ durable state の内部でも

canonical
provisional
authority
provenance
freshness

が明確に分かれていることです。

Durable Project State の不変条件

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

1. Every durable item is typed

durable に残るものは、必ず kind と status を持たなければなりません。
何なのか分からない durable item を作ってはなりません。

2. Canonical and provisional must be distinguishable

canonical と provisional は明示的に区別されなければなりません。
未評価の内容が正規状態に混ざってはなりません。

3. Every canonical item has provenance

どの frame / delta / evidence / authority から来たか追跡できなければなりません。

4. No canonical promotion without eval

canonical zone への昇格は、評価と必要な authority を経ていなければなりません。

5. Durable state is project-scoped, not actor-private by default

個人の私的メモは、そのまま durable project state とはみなしません。
project が参照可能な形へ明示的に取り込まれてはじめて durable になります。

6. Supersession must be explicit

古い decisions や playbooks が無言で置き換わってはなりません。
superseded / retracted / archived の関係が追跡可能である必要があります。

7. Future compilation must be possible

durable item は、将来の actor-local context compilation に使える粒度と構造で保持される必要があります。

いつ Durable Project State に昇格させるべきか

これは実務上かなり重要です。
PCE 2.0 では、次のものは durable に残す価値があります。

1. 将来の process が前提として使うもの

仕様、承認済み summary、baseline tests などです。

2. 同じ議論や失敗の再発を防ぐもの

decision rationale、rejected alternatives、failure lessons などです。

3. 再利用可能な運用知

playbooks、skills、review checklists、incident patterns などです。

4. 継続や再開に必要なもの

recovery points、paused states、pending approvals などです。

逆に、次のようなものは原則としてそのまま canonical にはしません。

raw chat logs
未検証の仮説
局所的な一時メモ
provenance のない要約
authority の不明な判断
再利用価値の低いノイズ

短く言えば、
将来の process に前提として使わせたいものだけを durable に昇格し、その他は provisional または消去対象として扱う
のが基本です。

最低限の自己点検

ある設計が Durable Project State を十分に持っているかは、次で点検できます。

canonical と provisional を区別して書けるか
code / spec 以外に、decision・failure・evaluation・operational memory を持てるか
各 durable item に kind / status / provenance / authority があるか
将来の process が何を前提にしてよいか説明できるか
未評価の内容が canonical に混ざっていないか
recovery points が state のどこに属するか言えるか
superseded / retracted / archived の扱いがあるか
actor-local context をこの state から compile できるか
process delta がどの zone を更新するか説明できるか
durable state が単なる保管庫ではなく、project の継続条件になっているか

このどれかが欠けるなら、その durable state はまだ粗いままです。

暫定的なまとめ

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

project は、単なる artifacts の集まりでは継続しない。
何が canonical で、何が provisional で、どの判断が採用され、どの失敗が学習済みで、どの手順が再利用可能なのかが、型付きで持続してはじめて継続する。

PCE 2.0 において durable state は、単なる memory ではありません。
それは、将来の process が依拠してよい project の存在条件そのものです。

だから Durable Project State は、単なる背景知識ではなく、
PCE 2.0 における 継続可能性の基盤層 です。