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
This commit is contained in:
JesseMarkowitz
2026-09-03 13:54:44 -04:00
co-authored by Claude Opus 5
parent 7f082b61d8
commit c8755c21c2
10 changed files with 2216 additions and 144 deletions
+46 -10
View File
@@ -1,7 +1,7 @@
# Adventure Storyteller Planning Package
**Status:** Phase 0 complete; architecture selected; **Milestones M1 and M2 implemented and accepted (2026-09-02)**.
**Production coding:** Underway, milestone by milestone. M1 and M2 are done; M3 is the next milestone to brief.
**Status:** Phase 0 complete; architecture selected; **Milestones M1, M2 and M3 implemented and accepted (M3: 2026-09-03)**.
**Production coding:** Underway, milestone by milestone. M1, M2 and M3 are done; M4 is the next milestone to brief.
This package contains the current product requirements, final Phase 0 architecture decisions, detailed subsystem designs, acceptance tests, research evidence, and the production milestone plan for the local-only interactive-story project.
@@ -168,8 +168,13 @@ Milestone M2 COMPLETE (2026-09-02)
policy
|
v
Milestone M3 NEXT — brief not yet prepared
non-destructive undo/redo
Milestone M3 COMPLETE (2026-09-03)
non-destructive undo/redo, see planning/reports/M3-*.md and ADR 012
active-head export one open condition: the browser smoke test
|
v
Milestone M4 NEXT — brief not yet prepared
named Save Points
|
v
Implement and review milestone-by-milestone
@@ -179,12 +184,43 @@ Implement and review milestone-by-milestone
**One milestone at a time. Do not begin a milestone before its brief exists.**
M1 and M2 are complete and accepted; the evidence is in `reports/M1-*.md` and
`reports/M2-*.md`. **No M3 brief has been prepared.** The current action is to
write one, informed by the post-M2 corrections below and by
`reports/M2-IMPLEMENTATION-REPORT.md` §Q, which records that M3's chokepoints
were left untouched or simplified by M2 and that the Phase 0B undo/redo spike
still applies.
M1, M2 and M3 are complete and accepted; the evidence is in `reports/M1-*.md`,
`reports/M2-*.md` and `reports/M3-IMPLEMENTATION-REPORT.md` — the last of which
is M3's primary evidence record as well as its review, since no separate M3
baseline report was produced. **No M4 brief has been prepared.** The current
action is to write one, informed by the post-M3 corrections below, by the note
`BUILD-MILESTONES.md` now attaches to M4, and by **ADR 012**, which records the
head-movement mechanism M4 must reuse rather than reimplement.
One M3 condition remains open and is not a blocker for M4: the required
**browser smoke test has not been performed**, because no session in which M3
was implemented or reviewed had a browser available. See
`reports/M3-IMPLEMENTATION-REPORT.md` §M and §W.4.
### Post-M3 corrections applied (2026-09-03)
M3's review recommended planning changes and, following the M2 pattern, reported
rather than applied them. All are now applied, together with the closeout work
the milestone itself required:
| Document | Correction |
| --- | --- |
| `DECISIONS/012-active-head-non-destructive-history.md` | **New ADR.** The architecture selected to implement ADR 005: head stored not derived, one capped read path, one movement mechanism, state from the node, divergence on first write below the head, Redo decided by the lineage, advisory disposition metadata, and the head as an exported decision. |
| `STORY-BRANCH-SEMANTICS.md` §5 | Undo crosses fork points and continues to the campaign opening. The old refusal was a consequence of destructive deletion, not a product decision. |
| `STORY-BRANCH-SEMANTICS.md` §10 | Switching which take is live is refused while a later story is off screen, with the two resolutions the user has. |
| `STORY-BRANCH-SEMANTICS.md` §14A | **New.** In-place editing before §14-15 exist: refuse when story descends from the turn and is not on screen. States explicitly that the full narrator-edit requirement stands and is completed in M5. |
| `TECHNICAL-DESIGN.md` §8.7, §9.1 | **New.** The implemented active-head model and bundle behaviour, recorded as fact. |
| `TECHNICAL-DESIGN.md` §10.4 | Constraint from M3: the snapshot half of the hybrid state model is a requirement, or head movement becomes proportional to campaign length. |
| `DATA-MODEL.md` §4, §5, §29 | The head as campaign-stored rather than derived; the branch disposition as implemented and deliberately advisory; the export as carrying a chosen position. |
| `BUILD-MILESTONES.md` M3 | Marked COMPLETE, with inherited capabilities, the open browser condition, and carried debt. |
| `BUILD-MILESTONES.md` M4 | Note: a Save Point is a durable pointer; restore by reusing M3's head movement rather than building a second restore path. |
| `BUILD-MILESTONES.md` M5 | Note: keep state efficiently recoverable at a position; move the test instrumentation rather than the assertions; complete the narrator edit. |
| `V1-ACCEPTANCE-TESTS.md` D03, D10, I07, L01 | D03's result recorded as a full pass; **D10's milestone ownership stated without weakening any pass condition**; I07's pre-M3 bundle clause added; the apparent L01/A05 conflict resolved. |
| `README.md` | Corrected to describe the current local-only single-user application. The scripting, accounts, analytics, hosted-demo, cloud-provider, Postgres and Render material described subsystems M2 removed. |
`SPECIFICATION.md` and `SECURITY-THREAT-MODEL.md` were deliberately **not**
changed. M3 altered no product requirement and touched no path in the threat
model.
### Post-M2 corrections applied (2026-09-03)