M9: a campaign you can actually get back

A campaign could already be exported and imported. What could not survive the
trip was everything that explains it: the state events behind the authoritative
document, the prompt each turn was actually given, the passages it was shown,
the summaries that carry long-story continuity, and which take belonged to which
turn. An imported campaign could be read and could no longer say why it was what
it was — and a manual correction, the one state change no narration explains,
was indistinguishable from something the story had established.

The bundle is now `ai-dnd-adventure-v3`, and the version is the design rather
than a side effect. Everything added here could have been another optional key,
the way persona, Save Points, narrative state and imported knowledge each were.
That mechanism stops working at exactly this addition: a v2 file with no prompt
provenance is ambiguous between "written before M9" and "written by M9 from a
campaign that has none", and those are different facts about a campaign. A
version number is how a recovery file states what it was capable of recording.
v1 and v2 still import, and every seam from pre-active-head onward is tested for
the rule that an older file is never reinterpreted under a newer assumption.

Two categories became three. "Chosen travels, derived is recomputed" was enough
until stored prompts had to be decided: they are derived, and they must travel
anyway. The test that separates evidence from cache is not "could this be
recomputed" but "would a recomputation answer the same question" — a rebuilt
search index answers the same question, a rebuilt prompt says what the turn
would be told *now*, which is the opposite of what the inspector is for.

Also here: a real SQLite backup, through the online backup API rather than a
file copy, taken while the application is running and verified before it is
kept; story cards settled as compatibility-only legacy data and taken out of the
narrator's prompt, because they were the untracked path around knowledge
authority that IMPORTED-KNOWLEDGE-DESIGN §73 already forbade; and no schema
change at all, proved against a database M8's own code wrote.

Three defects, found by running the milestone's own tests rather than by reading
them. Deleting a campaign leaked its FTS index rows, and SQLite then handed the
freed ids to the next source imported into any campaign, which failed with an
integrity error that Reindex could not repair — both ends are closed, and a
database already carrying the damage now repairs itself. An imported node with
no state snapshot was being stamped with the campaign's head state, so an Undo
to turn 2 showed what the story knew at turn 20. And the snapshot relink did not
persist at all, because it mutated a dict in place on a column SQLAlchemy tracks
by assignment: it looked correct in memory and wrote the wrong ids to disk.

Carrying per-turn prompts looked like it would halve the length of campaign that
can be restored. Measured — and after compressing them inside the file —
everything M9 added costs 12% of it: the import ceiling moves from about 318
turns to about 279, against a 100-turn certification target. The dominant cost
is not M9's at all. The per-position narrative state document is 74% of a
bundle, and v2 already carried it.

Backend 1,102 passed / 14 skipped / 0 failed. Frontend 145 passed. Lint,
production build and Docker build clean. Verified across two server processes
with two data directories, and in a real browser against a real narrator.

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

DEVELOPMENT.md

@@ -328,6 +328,100 @@ 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.
 
+## Backing up, and getting a campaign back
+
+There are two recovery tools and they answer different questions. Using the
+wrong one is the most common way to be surprised later, so they are described
+together.
+
+| | Campaign export | Database backup |
+| --- | --- | --- |
+| Covers | one campaign | every campaign, and your settings |
+| Shape | a JSON file you can read | a copy of the SQLite database |
+| Moves between machines | **yes** — this is the supported way | no; it is this machine's database |
+| Taken from | Export, on a campaign | Settings → *Back up everything on this machine* |
+| Restored by | Import campaign, on the library screen | replacing the database file, below |
+
+### Exporting and importing a campaign
+
+Export is on each campaign in the library, and in the campaign's own Settings
+panel. It writes one `.json` file holding the whole campaign: the story and its
+entire retained tree, the branch you are on and **the exact position you are
+reading at** — including one you undid back to — every alternate take, your Save
+Points, the authoritative state and its per-position snapshots, the state
+history that explains it, your imported knowledge with its classifications, the
+summaries and memories, and the prompt each turn was actually given.
+
+Import is on the library screen and takes that file back, into this or any other
+installation. Nothing about the file refers to the machine that wrote it: the
+imported files come back from their content, not from a path, and no setting of
+yours is changed by importing somebody's campaign.
+
+Two things it deliberately does **not** carry: your inference endpoint and model
+settings, which describe your machine rather than the campaign, and the
+rebuildable search indexes, which are rebuilt from the imported content before
+the import returns.
+
+**A campaign imports whether or not the model that wrote it is installed here.**
+Recovering a campaign and being able to play it on are separate questions; the
+first never depends on the second.
+
+### Backing up the whole database
+
+Settings → Advanced → *Back up everything on this machine*. It writes a verified
+copy into a `backups/` directory beside the database itself, and tells you where.
+
+It is a real backup rather than a file copy. It uses SQLite's online backup API,
+so it is safe to take **while you are playing** — a `cp` of a live database can
+read one page before a transaction and another after it, producing a file that
+opens, reports a schema, and is quietly missing rows. The copy is checked with
+`PRAGMA quick_check` before it is kept, an existing backup is never overwritten,
+and a failure leaves nothing behind.
+
+You can also take one from the command line, or from `cron`:
+
+```bash
+curl -s -X POST http://127.0.0.1:8000/api/backups | python3 -m json.tool
+```
+
+### Restoring a whole database
+
+There is deliberately no restore button, because restoring means replacing the
+file the running application has open — which is how you lose both copies at
+once. It is a three-step procedure and each step needs the application stopped:
+
+```bash
+# 1. Stop the application. Nothing below is safe while it is running.
+#    (Ctrl-C the server, or `docker compose down`.)
+
+# 2. Keep what is there now, whatever state it is in. You may want it back.
+mv backend/data.db backend/data.db.before-restore
+
+# 3. Put the backup in its place, and start the application again.
+cp backend/backups/adventure-storyteller-20260907-043000.db backend/data.db
+```
+
+Check the file before you trust it, and check it again after starting:
+
+```bash
+sqlite3 backend/backups/adventure-storyteller-20260907-043000.db 'PRAGMA quick_check;'
+# -> ok
+```
+
+The database path is `backend/data.db` by default, and whatever `AIDND_DB_PATH`
+names otherwise — in Docker that is the mounted volume.
+
+There is one file to move and no others: this build leaves SQLite in its default
+rollback-journal mode, so there are no `-wal` or `-shm` companions beside the
+database (`PRAGMA journal_mode` reports `delete`). A build that switched to WAL
+would have to move those too, and leaving them behind would pair a new database
+with an old write-ahead log.
+
+**Prefer the campaign export for anything smaller than "everything".** Restoring
+a whole database rolls every campaign back to the moment the backup was taken,
+including the ones you did not mean to touch. To recover one campaign, export it
+and import it.
+
 ## The context window your Ollama actually enforces
 
 **Check this before a long campaign.** The application budgets a prompt up to
@@ -380,6 +474,14 @@ 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.
 
+**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.
+
 ## What was made offline-safe, and how to check
 
 Two runtime downloads were removed in Milestone M1. Both were invisible on a