JesseMarkowitzandClaude Opus 5
c8755c21c2
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
126 lines
6.9 KiB
Markdown
126 lines
6.9 KiB
Markdown
# Planning Package Version
|
|
|
|
**Package:** Adventure Storyteller Planning Package v2.3
|
|
**Revision date:** 2026-09-03
|
|
**Status:** Phase 0 complete; architecture selected; **Milestones M1, M2 and M3 implemented and accepted**; M4 is next to brief.
|
|
|
|
## v2.3 — Post-M3 Closeout (2026-09-03)
|
|
|
|
M3 replaced destructive Undo with a stored active head. Its review is
|
|
`reports/M3-IMPLEMENTATION-REPORT.md`, which is also M3's primary evidence
|
|
record — no separate baseline report was produced — and whose §W records this
|
|
closeout.
|
|
|
|
In summary:
|
|
|
|
- the architecture is recorded as **ADR 012 — Active-Head Non-Destructive
|
|
History**: the head is stored rather than derived, every read of the story is
|
|
capped at it in one place, one mechanism moves it, state comes from the node
|
|
rather than from a replay, the first write below a moved-back head is the
|
|
divergence, and Redo is decided by the lineage rather than by a flag. ADR 005
|
|
is unchanged: it states the product requirement, and ADR 012 states the
|
|
architecture chosen to implement it,
|
|
- two history semantics are **ratified** in `STORY-BRANCH-SEMANTICS.md`: Undo
|
|
crosses fork points to the campaign opening (§5), and the system refuses to
|
|
switch which take is live while a later story is off screen (§10),
|
|
- a **new §14A** records the interim in-place-editing rule — refuse when story
|
|
descends from the turn and is not on screen — and states explicitly that
|
|
§14-15's full narrator-edit requirement stands and is completed in M5,
|
|
- `TECHNICAL-DESIGN.md` gains **§8.7** and **§9.1** recording the implemented
|
|
model and bundle behaviour as fact, and a constraint on §10.4: the snapshot
|
|
half of the hybrid state model is a requirement, because head movement must
|
|
not become proportional to campaign length,
|
|
- `DATA-MODEL.md` records the head as campaign-stored, the branch disposition as
|
|
implemented and deliberately advisory, and the export as carrying a chosen
|
|
position rather than a derived one,
|
|
- `BUILD-MILESTONES.md` marks **M3 complete**, states the one outstanding
|
|
condition (the browser smoke test), tells **M4** to reuse M3's head movement
|
|
rather than build a second restore path, and gives **M5** three constraints,
|
|
- `V1-ACCEPTANCE-TESTS.md` records D03's full pass, states **D10's milestone
|
|
ownership without weakening any pass condition**, adds I07's pre-M3 bundle
|
|
clause, and resolves the apparent L01/A05 conflict,
|
|
- `README.md` is corrected to describe the current local-only single-user
|
|
application rather than the upstream hosted one.
|
|
|
|
`SPECIFICATION.md` and `SECURITY-THREAT-MODEL.md` are unchanged: M3 altered no
|
|
product requirement and touched no path in the threat model.
|
|
|
|
## v2.2 — Post-M2 Closeout (2026-09-03)
|
|
|
|
M2 removed the hosted, cloud, account and scripting surface and added the
|
|
inference endpoint policy. Its review recommended six planning changes and
|
|
reported rather than applied them; all six are applied in this revision, listed
|
|
in `README.md` § *Post-M2 corrections applied*, with the evidence in
|
|
`reports/M2-BASELINE-REPORT.md` and `reports/M2-IMPLEMENTATION-REPORT.md`.
|
|
|
|
In summary:
|
|
|
|
- the **inference endpoint policy is recorded as implemented** — an address
|
|
allowlist of explicit local-network CIDRs, every resolved address checked,
|
|
enforced when settings are saved and again before every outbound request, with
|
|
TLS verification never traded against it (new **ADR 011**,
|
|
`SECURITY-THREAT-MODEL.md` §10A),
|
|
- its two **residual limits are stated rather than mitigated**: a hostile host
|
|
already on the trusted LAN, and the DNS-rebinding interval between the
|
|
policy's resolution and the client's connection,
|
|
- `TECHNICAL-DESIGN.md` §5.1 items 3 and 4 are **resolved**, and a new §5.2
|
|
records the M1/M2 production architecture as fact,
|
|
- a **wiring rule** is added (§18.1): removing a setting requires testing a real
|
|
consumer path, and adding one requires proving it reaches its component — M2
|
|
shipped two defects behind a 604-test green suite because the tests at that
|
|
boundary were mocks,
|
|
- `BUILD-MILESTONES.md` records **M2 complete**, warns M5 that eight rollback
|
|
tests use the world-state engine as instrumentation rather than as
|
|
architecture, and requires M6 to make background memory failure observable,
|
|
- the security acceptance contract is strengthened: **H10** now names the
|
|
wildcard-origin and `/api` 404 conditions, and new **H12** covers inference
|
|
endpoint enforcement including the database-edited-behind-the-API case.
|
|
|
|
`SPECIFICATION.md` is unchanged: M2 altered no product requirement. Nothing in
|
|
the architecture selected in v2 was reversed.
|
|
|
|
## v2.1 — Post-M1 Corrections (2026-09-02)
|
|
|
|
M1 implementation evidence contradicted or under-specified parts of v2. The
|
|
corrections are recorded in the documents themselves and listed in
|
|
`README.md` § *Post-M1 corrections applied*; the evidence behind them is in
|
|
`reports/M1-BASELINE-REPORT.md` and `reports/M1-IMPLEMENTATION-REPORT.md`.
|
|
|
|
In summary:
|
|
|
|
- a trusted-LAN Ollama may be **HTTPS with a privately issued certificate**;
|
|
clients verify against the operating system's CA store, with full certificate
|
|
and hostname verification and no bypass option (ADR 002,
|
|
`TECHNICAL-DESIGN.md` §5, A06),
|
|
- offline claims require a **fresh cache and no route out** to be evidence at
|
|
all, and vendored runtime artifacts should be integrity-verifiable
|
|
(ADR 004),
|
|
- A05's invariant is about **accepted** history; the user's submitted text is
|
|
deliberately retained on a failed turn,
|
|
- A06 requires a **real second machine and an HTTPS endpoint**; a plain-HTTP
|
|
LAN test is no longer sufficient evidence,
|
|
- the standard test environment records **CPU/GPU/RAM**, because cold model
|
|
load on a CPU-only host exceeded the inherited 120 s client timeout,
|
|
- `BUILD-MILESTONES.md` records M1 as complete and reframes M2's endpoint work
|
|
as **narrowing** an existing capability rather than inventing it,
|
|
- `SECURITY-THREAT-MODEL.md` §53 distinguishes **inbound** TLS (still deferred)
|
|
from **outbound** certificate verification (required, done in M1).
|
|
|
|
Nothing in the architecture selected in v2 was reversed.
|
|
|
|
## v2 — Post Phase 0B Revision (2026-09-01)
|
|
|
|
This v2 package supersedes the earlier planning package produced before the final Phase 0B review and the trusted-LAN Ollama deployment clarification.
|
|
|
|
Key v2 changes include:
|
|
|
|
- AI-DnD selected as the production base at the pinned Phase 0B commit.
|
|
- Non-destructive head-cursor Undo/Redo design selected.
|
|
- Explicit typed/absolute narrative-state events selected for production state handling.
|
|
- Imported knowledge separated from AI-DnD Story Cards.
|
|
- Trusted-LAN Ollama inference supported in v1 while the storyteller UI/API remains loopback-bound by default.
|
|
- Offline first-use dependencies and runtime remote assets identified as M1 hardening work.
|
|
- Production implementation divided into milestones M1-M11.
|
|
|
|
Historical Phase 0 prompts/reports are retained as evidence and should not be treated as current implementation instructions unless a current milestone prompt explicitly refers to them.
|