[happyren]

Fifth roadmap item. Targets FM-1.4 loss of conversation history and FM-2.1 conversation reset.

Why a record and not a conversation

Messages are ephemeral — delivered once, folded into a transcript, gone when that session compacts or ends. Common ground has to outlive them.

This is the transactive-memory direction: rather than replicating every session's context into every other, publish the small durable index of conclusions and let peers query it by area. A session joining a repository later reads what is already settled instead of rediscovering it — the same waste peer_claim prevents in the present tense.

Supersession is the load-bearing part

Nothing is ever edited or deleted. A later decision names the one it replaces; peer_decisions returns only what is in force, with history behind a flag.

Without this the ledger becomes a pile of contradictions the reader has to resolve — and that is precisely where an agent acts on the reversed one.

Design decisions worth reviewing

• Append-only, but still one file per session. Preserves the single-writer property that makes every store here lock-free. A shared append log would need cross-process coordination and would corrupt under a torn write.
• Nothing withdraws a ledger on teardown, unlike claims, cards and task states. The failure being attacked is losing what was settled when the session that settled it goes away.
• Subjects reuse the claim normalizer and nesting rule, so a decision about a directory governs the files beneath it, and one vocabulary covers every feature that names a resource.
• Extracts domain/evidence.ts — verification and decisions are both claims a reader may want to check, so they now cite the same way.

Live-verified

One session recorded two settled decisions about api/charges.ts (currency stays usd; tenant_id required).

A later session, with no knowledge of that discussion, was asked to add multi-currency support. Unprompted, it:

1. called peer_decisions about: "api/charges.ts" first,
2. found the deferral still in force,
3. read the file to confirm the code matched the decision,
4. took and then released a peer_claim when it realised it wasn't editing,
5. declined to implement, and identified supersession as the only legitimate route — "the settled decision would need to be superseded in the ledger (new decision referencing the old id), coordinated with the api/charges.ts owner" — without being told the mechanism existed.

Then it escalated to its user with the options rather than deciding alone.

26 new tests, 252 total.