Files

T

JesseMarkowitzandClaude Opus 5 c8755c21c2 Planning: close M3 and record active-head architecture

M3's review recommended planning changes and, following the M2 pattern,
reported rather than applied them. This applies them, and adds the ADR the
review asked for.

ADR 012 records the architecture rather than the requirement. ADR 005
already says that going backward must preserve abandoned history and that
the user sees Undo/Redo/Retry rather than branch management; it names a
movable active head as the direction and stops. What M3 settled is the
shape: the head is stored rather than derived, every read of the story is
capped at it in one place, one mechanism moves it, the state of a position
comes off the node rather than from a replay, the first write below a
moved-back head is the divergence, and whether Redo exists is decided by
the lineage rather than by a flag that could be stale. The last of those
is the property worth keeping — a flag can be wrong and make the story
wrong; a lineage cannot.

Two semantics are ratified in STORY-BRANCH-SEMANTICS.md, both of them
reversals or narrowings that a reader would otherwise take for bugs. Undo
now crosses fork points and continues to the campaign opening, because
refusing at the fork was a consequence of deleting rows the parent line
was also reading, and nothing is deleted any more. And the system refuses
to switch which take is live while a later story is off screen, because
doing it quietly would leave retained history continuing from words the
story no longer says.

A new §14A covers editing in place. §14-15 describe the finished
behaviour — the edit becomes authoritative, the state it implies is
re-evaluated, a new continuation is created, the original is retained —
and that requirement is intact and explicitly not weakened here. It is
also not built, because re-evaluating state from prose a user typed needs
M5's extraction pass. §14A says what exists in the meantime and why
refusing is the minimum that holds the invariant rather than the
destination.

TECHNICAL-DESIGN.md gains §8.7 and §9.1, recording the implemented model
and the bundle behaviour as fact in the way §5.2 records M1 and M2. §10.4
gains a constraint that is easy to lose: the snapshot half of the hybrid
state model is a requirement, not an optimization. Head movement is a row
lookup plus a restore, which is why Undo, Redo and Save Point restore cost
the same at any distance into a campaign; a state model recoverable only
by replaying from the opening would make all three proportional to
campaign length, on exactly the long campaigns this product is for.

DATA-MODEL.md records the head as stored on the campaign rather than
derived from its newest turn — two campaigns holding identical turns can
be read at different places, and nothing about the turns can tell them
apart — and the branch disposition as implemented: the depth a divergent
write left the branch at, deliberately advisory, and carried through
export because every row of an abandoned line is exported either way.

BUILD-MILESTONES.md marks M3 complete and states the one condition still
open. M4 is told a Save Point is a durable pointer and that restoring one
is head movement with a bounds check, not a restore system: a second
mover is the specific failure to avoid, because the two paths would
silently disagree about what restore means. M5 gets three constraints —
keep state efficiently recoverable, move the test instrumentation rather
than the assertions when the world-state protocol goes, and finish the
narrator edit §14A defers.

V1-ACCEPTANCE-TESTS.md clarifies ownership without lowering a bar. D10
keeps all three pass conditions and is explicitly recorded as *not*
satisfied at the end of M3; what changed is that the document now says
which milestone delivers which condition. D03's result is recorded as a
full pass rather than the partial the text allowed for, I07 gains the
pre-M3 bundle clause, and L01 gains the note that resolves its apparent
conflict with A05 — a failed turn does advance the head by one, onto the
player's retained input, and that is A05 working rather than L01 failing.

README.md described a different application: a hosted demo, guest
accounts, cloud providers, Postgres, a Render blueprint, an analytics
dashboard, a QuickJS scripting engine, and 549 tests. M2 removed all of
that and the README was never updated — a gap M2's own debt table missed.
It now describes what this fork is, including the endpoint policy and the
TLS behaviour, and the numbers in it are the current ones.

M3's report is included here as its own evidence record: no separate
baseline report was produced, so it carries the raw counts and runtime
observations as well as the review, and §W records this closeout.

SPECIFICATION.md and SECURITY-THREAT-MODEL.md are unchanged. M3 altered no
product requirement and touched no path in the threat model.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QF5TcoB86QADgjHz1GZe8u

2026-09-03 13:54:44 -04:00

6.1 KiB

Raw Blame History

ADR 012 — Active-Head Non-Destructive History

Status: Accepted; implemented in M3 Date: 2026-09-03

Decision

Where the story is being read and how much story is retained are two separate facts, stored separately and answered by different code.

The active head is a stored position — a branch and a depth on it. It is where the story currently ends as far as the reader, the narrator prompt, and every feature built on them are concerned.
The retained tip is the deepest node still kept on the same lineage. It may be ahead of the head.

Undo and Redo move the active head. They delete nothing, restore nothing from a log, and recompute nothing. Every ordinary read of the story is bounded by the head; retained story beyond it stays live in the database, reachable by Redo, and available to a divergence.

Concretely, and as implemented:

The active head is persisted on the campaign, not derived from the newest row. It is a decision, and no read may re-derive it.
Lineage resolution caps every entry at the head, in one place, so the transcript, the assembled context, take/parent resolution and memory retrieval narrow together and cannot disagree.
Reading past the head is possible through one narrow, named exception, and only two callers may use it: Redo, and the check that decides whether a write must fork.
The state belonging to a position is recorded on the node that produced it, so moving the head is a row lookup plus a restore — the same cost at any distance, in either direction.
Undo alone never forks. The first write below a moved-back head is the divergence: it creates a new continuation, and the displaced future stays where it was written, on the line it was written on.
Whether an ordinary Redo exists is decided by the lineage, not by a flag. After a divergence the displaced future is no longer on the lineage, so there is nothing ahead to walk into and no state to invalidate.
A branch the story has left records the depth it was left at and when, as metadata that nothing reads to decide behavior. It exists so a divergence is observable and so later cleanup and recovery features have something to select on.
Derived work — memories, summary coverage — is anchored to the node it came from and is therefore filtered by the same capped lineage. Undo prunes nothing; Redo re-derives nothing.
Export carries the active head, because it is a chosen position rather than a fact about the newest row. Import honors it. A file that predates the field is opened at its tip, which is the position such a file recorded.

Context

ADR 005 states the product requirement: returning to an earlier point preserves abandoned future history rather than erasing it, and the user sees Undo/Redo/Retry/Save Point rather than branch management. It names a movable active head as the implementation direction and stops there.

This ADR records the architecture selected to implement it, as built and demonstrated in M3. It does not restate or revise ADR 005.

The production base shipped a destructive Undo: it deleted the trailing turns, pruned the memories covering them, and let the tip fall back to whatever survived. That made the head a derived value, made Redo impossible, and — as Phase 0B found — let an export silently reopen an undone campaign at its newest retained turn.

Alternatives Considered

Keep the head derived and mark rows inactive. Rejected: every read would need its own filter, and the filters would drift. Capping the lineage once is what makes the whole application agree about where the story ends.
Rebuild state by replaying events from the opening. Rejected: it makes the cost of Undo proportional to campaign length, and long campaigns are the case this product exists for.
Fork on Undo rather than on the first write below the head. Rejected: moving the head is not a decision to abandon anything — the user may be reading, or about to Redo — and forking on every Undo fills the branch table with branches nobody chose. Redo could not survive it.
Decide Redo from a stored flag. Rejected: a flag can be stale or hand-edited, and a wrong value would produce a wrong story. Deriving it from the lineage cannot.

Reason

The head is the smallest thing that can move. Making it a stored position rather than a derived one turns Undo from an operation that destroys accepted story into one that changes a coordinate, and everything else — Redo, divergence preserving the old future, memory isolation, an export that reopens where the user left it — follows from that single change rather than needing machinery of its own.

Consequences

Undo deletes zero accepted rows. This is the invariant the architecture exists to hold, and it is asserted directly on row identity.
Retained history accumulates. v1 requires no automatic cleanup; the disposition metadata is what a later cleanup or recovery feature will select on.
Any operation that changes what the story says at a position must ask whether story descends from that position and is off screen. Switching the selected take and editing a turn's text in place both must refuse in that situation rather than act silently. See STORY-BRANCH-SEMANTICS.md §10 and §14A.
Undo crosses fork points, because a forked story includes the story it was forked out of and nothing is being deleted. The floor is the campaign opening.
Save Points must reuse this mechanism. A named save point is a durable coordinate; restoring one is head movement with a bounds check. Introducing a second restore path would reintroduce exactly the divergence this ADR removes.
The narrative-state model must keep state efficiently recoverable at a position — a per-node snapshot or an equivalent cache — or Undo, Redo and Save Point restore all become proportional to campaign length. This is a constraint on ADR 010's engine, not a reversal of it.
Every feature that reads story must read it through the capped lineage. Anything that queries rows directly will see retained history the story is not telling.

6.1 KiB Raw Blame History