Memory

Memory は、単なる長文保存や long context の置き場ではない。 PCE 2.0 では memory とは、 後続の process が current truth として参照してよい project state を、評価と権限の条件つきで保持する層 である。

重要なのは、何か useful-looking なものが出たからといって、それが即 memory になるわけではないことだ。 memory は常に

provenance

eval

approval / authority

conflict check

future reuse value

を伴って扱う必要がある。

このセクションの役割

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

1. delta と durable state を分ける

PCE 2.0 では、process から出たものはまず Process Delta である。それがそのまま canonical project state になるとは限らない。

2. promotion の条件を明示する

何を残し、何を捨て、何を provisional のまま持ち、何を昇格させるかには rule が必要である。さもないと project state は、便利そうな断片の集積になって壊れる。

3. 継続可能性を担保する

memory は later process にとっての grounding layer である。良い memory は later work を速くするが、悪い memory は later work を誤誘導する。

中心ページ

Memory Promotion Rules

現在の memory セクションの中心ページ。何をどの条件で durable state に昇格させるかを扱う。

このページが主に見るもの:

promotion の原則
candidate と canonical の区別
authority と write path
duplicate / conflict の扱い
retained provenance

memory をどう理解すべきか

memory は context ではない

Context は actor-local に compile される局所視界であり、 memory は project が later に参照する durable layer である。

短く言えば、

context はその場で使う
memory は後で使う

だが、もっと重要なのは durability semantics である。

memory は artifact だけではない

memory に残りうるのはコードや docs だけではない。たとえば、

decision
operational lesson
evaluation finding
recovery anchor
routing rationale

も、条件を満たせば memory 候補になりうる。

memory は archive ではない

何でも保存することが目的ではない。むしろ、 後続の process が参照してよい current truth を細く保つ ことが重要である。

memory と他セクションの関係

Ontology との関係

Durable Project State は memory の存在論的な核である
Process Delta は memory に昇格する前の emitted change である

Evaluation との関係

Memory Promotion Criteria が昇格可否の判断軸を与える
Corrupt Success は useful-looking だが危険な記録を見分ける視点を与える

Responsibility との関係

Memory Writing が write authority と責任の所在を定める

Process との関係

Checkpoint and Recovery は memory と close だが、常に同じものではない
Handoff の continuity package の一部は memory 候補になりうる

memory に残すときの典型判断

残しやすいもの

後続作業で再利用価値が高い
provenance が辿れる
evaluator / approver の基準を通っている
conflict 時に current truth として扱ってよい

残しにくいもの

一時的な exploration note
current scope でしか意味を持たない scratch
evidence が弱い結論
stale な assumption に依存した recommendation

特に危険なもの

prototype success を一般化した知見
pass したが process violation を含む成果
duplicate / conflict check が弱い decision
approval collapse による premature canonicalization

記憶の層をどう考えるか

今の docs ではすべてを個別ページ化してはいないが、実務上は少なくとも次の層を区別して考えるとよい。

canonical artifact memory

コード、正式 doc、承認済み runbook のように、そのまま project state の一部として参照されるもの。

decision memory

何を選び、何を捨て、なぜそうしたかを保持する層。

operational memory

運用上の癖、失敗モード、復旧知見のように、後続の incident / handoff / triage を速くする層。

evaluation memory

どういう failure が繰り返されるか、どういう checklist が効くかを保持する層。

これらは概念的には分けた方がよいが、どこまで formalize するかは later な docs evolution の対象である。

先に読むとよいページ

memory を初めて読むなら

promotion judgment を深めるなら

failure mode を見るなら

ケースでどう現れるか

Feature Delivery

artifact, decision, operational note が delta として出て、何が durable state に昇格するかが end-to-end で見える。

Research Loop

provisional recommendation と canonical decision memory を分ける必要がよく見える。

Human-AI Handoff

continuity package のどこまでを ephemeral handoff とし、どこからを durable memory にするべきかが見えやすい。

memory を読むときのコツ

1. useful と canonical を分ける

役に立つことと、current truth として採用してよいことは別である。

2. provenance を軽視しない

誰が、どの evidence に基づき、どの gate を通して残したかが分からない memory は危険である。

3. provisional を恥とみなさない

曖昧なものを無理に canonicalize するより、 provisional のまま扱う方が安全なことは多い。

4. memory 書き込みを merge の副作用にしない

memory promotion は、artifact merge のついでではなく独立判断として扱った方が壊れにくい。

暫定的なまとめ

このセクションが言いたいことは、最終的には次の一文に集約できる。

PCE 2.0 の memory は、何でも残すための棚ではない。
後続の process が current truth として参照してよい project state を、delta・evidence・authority・promotion judgment を通して選別し、継続可能性を支えるための durable layer である。