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
This commit is contained in:
JesseMarkowitz
2026-09-07 14:01:20 -04:00
co-authored by Claude Opus 5
parent 1013c94eb1
commit 144406cd48
57 changed files with 7374 additions and 97 deletions
+60 -6
View File
@@ -344,6 +344,46 @@ subsystem comes back as a route, if an API key becomes settable again, if the
model timeout stops being configurable or becomes unbounded, or if a supported
start path stops binding loopback.
## The release-validation harnesses
M11 added six runnable harnesses under `backend/tools/`. They are the evidence
behind `planning/reports/M11-IMPLEMENTATION-REPORT.md`, and they live in the
repository so a reviewer can re-run them rather than take the report's word for
anything. None is part of the application and none is imported by it.
```bash
cd backend
# The 100-turn release campaign (M01-M04): real narrator, genuine process
# restarts, every history operation. Hours, not minutes.
AIDND_TEST_ENDPOINT=https://<host>:<port>/v1 \
AIDND_TEST_MODEL=<model> AIDND_TEST_EMBED_MODEL=<embedding model> \
.venv/bin/python -m tools.m11_long_run --turns 100 --out /tmp/m01
# What that campaign is worth on a machine that has never seen it (I01-I07).
.venv/bin/python -m tools.m11_recovery --bundle /tmp/m01/bundle.json --out /tmp/m01
# The browser release regression and the accessibility measurements. Needs
# `frontend/dist` built and geckodriver on PATH.
.venv/bin/python -m tools.m11_browser --out /tmp/browser
# A container with no network at all: the offline run and the packaging path.
.venv/bin/python -m tools.m11_offline --out /tmp/offline
# The multi-character identity diagnostic (post-M8 finding D), and the run that
# proves its detectors fire.
.venv/bin/python -m tools.m11_identity --out /tmp/identity
.venv/bin/python -m tools.m11_identity --scripted --inject
# The palette, against WCAG AA.
.venv/bin/python -m tools.contrast_audit
```
`tools/m11_webdriver.py` is the W3C WebDriver client the browser harness uses.
It exists so browser evidence needs no Selenium in the dependency surface, and
it documents the one environment quirk that matters here: a snap Firefox will
not open a file the driver names under `/tmp`, but will under `$HOME`.
## Backing up, and getting a campaign back
There are two recovery tools and they answer different questions. Using the
@@ -460,6 +500,17 @@ system block: the narrator rules and the campaign canon. The symptom is a
narrator that forgets canon deep into a long session, with nothing on screen
explaining why.
**The application now checks, and will not over-budget.** Since M11 it asks the
server what window your model actually gets — `/api/ps` for a model that is
loaded, `/api/show` for one that is not — and caps the prompt to that number. A
4,096-token server therefore no longer receives a 16,384-token prompt: the
campaign gets less history than the setting asks for, which is a visible,
explicable loss rather than a silent one, and Settings' **Test connection**
reports the window it found or says plainly that it could not check.
That does not make the window *bigger*, and the rest of this section is still
how you do that.
**Setting it per request does not work from this application.** Ollama's
OpenAI-compatible endpoint accepts `num_ctx` — nested in `options` or at the top
level — returns HTTP 200 and ignores it. Worse, it *reloads the model at its own
@@ -486,17 +537,20 @@ Where you *do* control the server environment, `OLLAMA_CONTEXT_LENGTH=16384`
does the same job. Either way a larger window costs roughly proportionally more
KV cache.
If you would rather not raise it at all, set **How much story to send** in
Settings to the number `/api/ps` reports, and the prompt will be assembled to
fit.
If you would rather not raise it at all, you no longer need to do anything: the
application caps itself to what the server reports. Setting **How much story to
send** to the same number simply makes the intent explicit.
**This matters most on the machine you import to.** A campaign carries its
history, not the window the machine that wrote it had, and a long imported
campaign fills a prompt on its very first turn — so a deployment that has applied
neither the derived model above nor a matching budget meets its ceiling
immediately rather than gradually. Importing succeeds either way; it is the first
turn afterwards that truncates. Check `/api/ps` on the destination before playing
on an imported campaign, not after.
immediately rather than gradually. Importing succeeds either way, and since M11
the first turn afterwards is *capped* rather than truncated — so what a small
window costs is history, not the canon at the front of the prompt. It is still
worth giving the model its window before playing an imported campaign: a
4,096-token context on a hundred-turn story is a much shorter memory than the
story was written with.
## What was made offline-safe, and how to check