M11: what the server will actually read

The release-validation milestone, and the thing it had to settle first was
whether any of the earlier evidence meant what it said. M8 measured a deployment
enforcing a 4,096-token input window while the application budgeted 16,384.
Every request returned 200. What Ollama does with the excess is drop the oldest
tokens, and the oldest tokens here are the system block — the narrator's rules
and the campaign canon. A hundred-turn certification against that server would
have looked perfect and proved nothing, which is why this milestone could not
begin with a hundred turns.

So the application asks now. Ollama's window is a property of how a model was
loaded rather than of the request — sending num_ctx is accepted, ignored, and
worse, reloads the model at the server's own default — so the only honest move
is to find out and then tell the truth about it. /api/ps reports what a resident
model is being served with, /api/show what an unloaded one will load with, both
on the same host inference already uses, through the same endpoint policy and
the same TLS trust store. A verified window is a ceiling on the budget; an
unverified one leaves the budget alone and is recorded as unverified in the
turn's own provenance, so an old turn can be asked afterwards whether it was
built against a checked window. There is no third behaviour, and in particular
no hard-coded 4,096: a number the server did not say would be right on one
machine and wrong on the next.

The proof that this is doing something is a campaign whose canon sits at the
front of the prompt, 120 turns of history, and a 4,096-token window. The canon
is still there afterwards and the oldest history is gone. The same campaign
built the old way produces a prompt more than twice the window — the defect,
reproduced, so the fix is measured against it rather than asserted.

Two defects the validation found on its own, and they are the same defect twice:
something was true and nobody was told. A manual state correction of four
changes with one bad reference applied three, returned 201, and said nothing —
while recording the refusal on the audit row nobody reads. It came to light
because the identity diagnostic's own fixture was refused that way and the whole
run proceeded on a campaign with no scene, which would have read as a model
failure. And the narration-length setting moved no number: brief, medium and
long each became one English sentence, while the numeric hint the model actually
reads was derived from the global reply cap and said the same thing for all
three. Both now say what they did.

The other two post-M8 findings are closed as well. The tab said AI D&D, which no
document had ever claimed it did not; it says Interactive Story now, with the
open campaign first, and the name is the owner's decision rather than a
find-and-replace to something narrower than the engine. After an Undo the reader
could not tell where they had landed; the control row now ends with
"Moment 11 · later story ahead", from the server's own answer, in the word the
transcript already uses, with none of head, branch or depth anywhere near it.

The identity diagnostic exists and the root cause does not. That campaign was
destroyed, so no cause can be established — what M11 owes the finding is
something that can classify the next occurrence, and a diagnostic that makes only
the judgements a program can honestly make: duplicate keys, shared names,
protagonist drift, state and context disagreeing. Whether prose misattributed a
line is left to a person reading it beside its prompt, because a regex cannot
read dialogue and one that pretended to would produce exactly the confident wrong
answer this finding is about. Its detectors are proved to fire against a planted
second Alice.

Two entities may still share a display name. That was checked first, as the
finding asked, and left permitted: a mother and a daughter, or a stranger giving
a false name, are ordinary fiction, and refusing them to guard against a model
mistake would refuse the wrong thing. What was missing was that it happened
silently. It is reported now.

Evidence, not inference: a hundred accepted turns against a real narrator with
genuine process restarts; a real browser against the built SPA; a container with
no network at all; a campaign moved into a data directory that never existed.
Each was discarded and re-run whenever the product changed under it, and the runs
that were thrown away are listed in the report with the reason, along with ten
defects in the harnesses themselves — because a harness that has only ever
agreed with itself is not evidence, and two of M8's five harness defects were
masking real ones.

No dependency was added, removed or upgraded. No acceptance test was retired,
relaxed or reclassified. M11 is implemented and verified; it is not accepted, and
there is no release tag.

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

planning/README.md

@@ -3,8 +3,9 @@
 **This file is the index. Start here.**
 
 **Current state:** Phase 0 complete; AI-DnD forked as the production base;
-milestones **M1 through M8 implemented and accepted**, and **M9 and M10
-implemented and awaiting review**. M1-M6 were accepted on the dates below (M3 and M4: 2026-09-03;
+milestones **M1 through M8 implemented and accepted**; **M9 and M10 implemented,
+committed and signed**; **M11 implemented and verified, awaiting independent
+review and v1 acceptance**. M11 is the last planned milestone. M1-M6 were accepted on the dates below (M3 and M4: 2026-09-03;
 M5: 2026-09-04; M6: 2026-09-06). M5 and M6 were each accepted only after an
 independent review found a real defect and a corrective pass fixed it.
 
@@ -15,28 +16,34 @@ report keeps all three in sequence, and is now in
 
 **M8 — Browser UX Completion for v1 Story Operations — is complete and
 accepted** (2026-09-06), after an independent review and a closeout pass.
-`reports/M8-IMPLEMENTATION-REPORT.md` is the implementer's account and now
-carries the closeout: the build-evidence classification in its §P, finding 14's
-operational resolution, and the acceptance record in its §V. The M8 tree is
-staged and awaits the repository owner's signed commit.
+`archive/milestone-reports/M8-IMPLEMENTATION-REPORT.md` is the implementer's
+account and carries the closeout: the build-evidence classification in its §P,
+finding 14's operational resolution, and the acceptance record in its §V. It is
+committed and signed (`1ce9972`).
 
-**M9 — Export, Backup, Recovery, and Migration Hardening — is implemented and
-awaiting independent review** (2026-09-07).
-`reports/M9-IMPLEMENTATION-REPORT.md` is the implementer's account, written for
-a reviewer: a set of claims with the measurements attached, not yet a record of
-acceptance. M8's report has moved to `archive/milestone-reports/`, which is
-where a milestone report goes once the next milestone's report replaces it.
+**M9 — Export, Backup, Recovery, and Migration Hardening — is committed and
+signed** (`44edece`). It made a campaign portable in the way that matters: the
+bundle became `ai-dnd-adventure-v3`, prompt provenance and state events travel,
+and a verified SQLite backup exists. Its report is in
+`archive/milestone-reports/`, along with M8's and M10's.
 
-**M10 — Future Media Extension Hooks Only — is implemented and awaiting
-independent review** (2026-09-07). `reports/M10-IMPLEMENTATION-REPORT.md` is the
-implementer's account. It built the seam and no media: one `visual_profiles`
-table, a scene packet derived on read, provider contracts with an empty
-registry, and no dependency added. Its central finding is that the scene
-snapshot the media contract asks for **already existed**, built by M5.
+**M10 — Future Media Extension Hooks Only — is committed and signed**
+(`1013c94`). It built the seam and no media: one `visual_profiles` table, a
+scene packet derived on read, provider contracts with an empty registry, and no
+dependency added. Its central finding was that the scene snapshot the media
+contract asks for **already existed**, built by M5.
 
-**Next: M11 — v1 Security, Long-Run, and Release Validation.** It has not been
-started, and no brief for it exists. It also owns the four post-M8 hands-on
-playtest findings recorded in `BUILD-MILESTONES.md`.
+**M11 — v1 Security, Long-Run, and Release Validation — is implemented and
+verified, and awaits independent review** (2026-09-07).
+`reports/M11-IMPLEMENTATION-REPORT.md` is the evidence package. It closed the
+context-window release blocker M8 found, fixed two defects the validation itself
+surfaced, and disposed of all four post-M8 playtest findings. **It is not
+accepted**, there is no release tag, and the tree is staged rather than
+committed.
+
+**After M11 there is no further planned milestone.** What follows is
+independent review and the v1 acceptance decision, which is the repository
+owner's.
 
 **Package version:** see `VERSION.md`, which records what each revision changed
 and why.
@@ -98,7 +105,7 @@ Two standing qualifications:
 | Document | What it is for |
 | --- | --- |
 | `SPECIFICATION.md` | What the product must do. The top of the authority order. |
-| `TECHNICAL-DESIGN.md` | The selected architecture, including what M1-M10 built, recorded as fact. |
+| `TECHNICAL-DESIGN.md` | The selected architecture, including what M1-M11 built, recorded as fact. |
 | `DATA-MODEL.md` | Entities, the stored head, branch disposition, and the v3 export contract. |
 | `STORY-BRANCH-SEMANTICS.md` | Undo/Redo/Retry/branch/take behavior, including the M3 ratifications. |
 | `CONTEXT-AND-MEMORY.md` | Prompt assembly, summarization, branch-safe memory. |
@@ -126,9 +133,8 @@ Two standing qualifications:
 10. `BROWSER-UX-SPEC.md`
 11. `V1-ACCEPTANCE-TESTS.md`
 12. `DECISIONS/` — all of them; they are short.
-13. `reports/M10-IMPLEMENTATION-REPORT.md` and
-    `reports/M9-IMPLEMENTATION-REPORT.md`, for what the most recent milestones
-    actually left behind — read as claims to check, not records, until they are
+13. `reports/M11-IMPLEMENTATION-REPORT.md`, for what the release validation
+    actually found — read as claims to check, not a record, until it is
     reviewed. Nothing in `planning/archive/` unless sent there.
 
 ## Architectural decisions
@@ -160,19 +166,17 @@ work until Phase 0 closes — which Phase 0 satisfied on 2026-09-01. It is in
 `reports/` holds the report for the milestone most recently completed, because
 that is the one the next milestone's planning has to consult:
 
-- `reports/M10-IMPLEMENTATION-REPORT.md` — the M10 implementation: the media
-  seam, everything it deliberately did not build, and the evidence for K01-K04.
-  Written by the implementer for an independent reviewer, so it is a set of
-  claims with the measurements attached and **not** a record of acceptance.
-- `reports/M9-IMPLEMENTATION-REPORT.md` — the M9 implementation: the measured M8
-  portability baseline it started from, the final bundle contract, and the
-  evidence for every acceptance test it claims. Its §W carries the M10-M11
-  handoff and its §Y holds the post-M8 playtest findings.
+- `reports/M11-IMPLEMENTATION-REPORT.md` — the release validation: the
+  acceptance matrix run end to end, the 100-turn campaign, the offline and
+  browser evidence, and every defect the run found. Written by the implementer
+  for an independent reviewer, so it is a set of claims with the measurements
+  attached and **not** a record of acceptance.
 
-  **It stays here rather than moving to the archive**, against the usual
-  rotation, because M9 has not been accepted yet: a reviewer of either milestone
-  needs it, since M10 built on M9 and its baseline is M9's. It moves once M9 is
-  accepted.
+M9's and M10's reports both moved to `archive/milestone-reports/` when this one
+was written. M9's had been kept here past its turn because M9 was unaccepted;
+both are now committed and signed, so the ordinary rotation applies again. M9's
+§Y — the post-M8 playtest findings — has a durable copy in `BUILD-MILESTONES.md`
+and did not depend on that file staying put.
 
 Completed earlier milestones are in `archive/milestone-reports/`, which M8's
 report joined when M9's was written: a milestone report is useful during the
@@ -298,34 +302,37 @@ Milestone M7                        COMPLETE (2026-09-06)
         |
         v
 Milestone M8                        COMPLETE / ACCEPTED (2026-09-06)
-  browser UX completion for v1      reports/M8-IMPLEMENTATION-REPORT.md
+  browser UX completion for v1      archive/milestone-reports/
   story operations                  review + closeout, in sequence
         |
         v
 Milestone M9                        COMPLETE — awaiting review (2026-09-07)
-  export, backup, recovery,         reports/M9-IMPLEMENTATION-REPORT.md
+  export, backup, recovery,         archive/milestone-reports/
   migration hardening               bundle format v3; SQLite online backup
         |
         v
-Milestone M10                       COMPLETE — awaiting review (2026-09-07)
-  future media extension hooks      reports/M10-IMPLEMENTATION-REPORT.md
+Milestone M10                       COMMITTED AND SIGNED (1013c94)
+  future media extension hooks      archive/milestone-reports/
                                     scene packet derived, not stored; no media
         |
         v
-Milestone M11                       NEXT — not started
-  v1 security, long-run, release    see BUILD-MILESTONES.md
-  validation                        also owns the post-M8 playtest findings
+Milestone M11                       IMPLEMENTED AND VERIFIED (2026-09-07)
+  v1 security, long-run, release    reports/M11-IMPLEMENTATION-REPORT.md
+  validation                        awaiting independent review; no release tag
+        |
+        v
+v1 acceptance                       the repository owner's decision
 ```
 
 ## Stop Rule
 
 **One milestone at a time. Do not begin a milestone before its brief exists.**
 
-**No M11 brief has been prepared**, and neither M9 nor M10 is accepted — both
-are implemented and awaiting independent review. Writing the M11 brief is the
-action after those reviews close, informed by the M9 report's §W, the M10
-report's handoff, and the four post-M8 playtest findings in
-`BUILD-MILESTONES.md`.
+**Every planned milestone is now implemented.** M11 is verified and staged, and
+the next action is not another milestone: it is an independent review of
+`reports/M11-IMPLEMENTATION-REPORT.md` against the acceptance contract, and then
+the owner's v1 acceptance decision. **Do not begin post-v1 work before that
+decision**, and do not treat M11's own report as the acceptance record.
 
 All three questions the M8 debt raised against M9 are settled and recorded:
 the bundle carries historical context snapshots (`DATA-MODEL.md` §29); story