Keep a production run to the adventures you meant

The hosted database is not the local one. It holds other people's stories, and
`summary_provider` builds from the adventure owner's Settings, so an unfiltered
`--write` against it would spend other people's money rewriting memories they
never asked about. `--adventure` could already hold a run down, but only if you
knew the ids.

`--email` names accounts instead, and every line of the report now says who owns
the adventure, so a dry run answers "whose keys would this spend" before
anything is written. Guests have no email and stay reachable only by id, which
is the right amount of friction for touching a stranger's bank.

The other half is written down rather than built: stored API keys are encrypted
with AIDND_SECRET_KEY, so a run from a checkout against the Neon database needs
the same value the web service holds. With a different one `decrypt_secret`
returns "" instead of failing, and every adventure is reported as having no key
— a run that looks like it worked and did nothing. The Dockerfile copies
backend/app alone, so tools/ is not on the box either way; the recipe is a
checkout pointed at AIDND_DATABASE_URL.

629 green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Tqgupw5CZGjSZrUTNUd4fW
This commit is contained in:
Claude
2026-08-31 10:18:41 +00:00
parent f184db2aa6
commit 4c94dd0fc0
4 changed files with 113 additions and 7 deletions
+34 -1
View File
@@ -4,7 +4,7 @@ Two changes, in order. Phase 1 gives the adventure a persona. Phase 2 uses it,
along with the cast, to fix the memories. Phase 1 is worth shipping on its own;
Phase 2 depends on it and is much smaller once it lands.
**Both phases are built and green (627 backend tests). Phase 1 was driven in a
**Both phases are built and green (629 backend tests). Phase 1 was driven in a
browser (21/21 checks). Phase 2 was run end to end against a real model, as a
controlled A/B on one story — see "Run with a real model". A bank written under
the old prompt can be rewritten in place — see the last section.**
@@ -615,6 +615,39 @@ a vector written from outside it can sit behind a stale cached copy until it
restarts. Clearing alone is safe at any time: an unembedded memory leaves the
catalogue, which is what the cache invalidates on.
## Running it against the hosted deploy
Two things make production different from a local database, and both are easy
to get wrong quietly.
**It holds other people's stories, and each adventure is summarized with its
owner's key.** An unfiltered `--write` would spend other people's money on
memories they did not ask to have rewritten. `--email` restricts a run to named
accounts and `--adventure` to single adventures; the dry run costs nothing and
prints the owner of each. Guests have no email and are reachable only by id,
which is the right amount of friction for rewriting a stranger's bank.
**The stored API keys are encrypted with `AIDND_SECRET_KEY`.** Render generates
that value and holds it for the web service, so a run from a checkout has to
carry the same one. With a different secret, `decrypt_secret` returns "" rather
than failing, and every adventure is reported as having no key — a run that
looks like it worked and did nothing.
```
AIDND_DATABASE_URL=<the Neon URL from the Render dashboard> \
AIDND_SECRET_KEY=<the value the web service has> \
python -m tools.rewrite_memories --email you@example.com
```
Run it from a checkout rather than from a shell on Render. The image copies
`backend/app` alone, so `tools/` is not on the box, and the free plan has no
shell anyway. The database is the same one either way.
Two smaller notes for that environment. The Neon URL to use is the direct
endpoint, not `-pooler`, for the same reason the sizing queries in STATUS use
it. And an adventure owned by a visitor playing on the shared demo key is
skipped, because summarization has never spent that key.
**The story summary is not rewritten.** It is one text per adventure rather than
a bank, and `_update_story_summary` hands the model the whole of it and asks for
an updated version under the new framing rule, so the next scheduled update
+16 -2
View File
@@ -81,7 +81,7 @@ needed; nothing requires reading a row of anyone's story.
**`plan/18-persona-and-memory-quality.md` is the writeup. Both changes are on `main`**
— the note here that said they were sitting unmerged on
`claude/ai-dnd-memories-summarization-3muo98` is out of date; `main` is at `71b24b6`,
the tip of that work. Both green at 627 tests, plus the backfill below.
the tip of that work. Both green at 629 tests, plus the backfill below.
**The protagonist now has a name.** An adventure carries `persona_name`,
`persona_pronouns` and `persona_desc` (migrations 74-76), and the player's stat block
@@ -137,7 +137,21 @@ python -m tools.rewrite_memories --write --embed # the whole backfill
It reads whichever database the app reads (`AIDND_DB_PATH`, or `DATABASE_URL` on the
hosted deploy), so **take a copy first** — the old text is overwritten and kept nowhere.
`--endpoint`/`--model`/`--api-key` point the summarizer somewhere else, `claude_shim.py`
included. Hand-written memories, and memories whose actions have been deleted, are left
included.
**Against production, name whose adventures you mean.** That database holds other
people's stories and each adventure is summarized with its owner's key, so `--email`
(or `--adventure`) is what keeps a run to your own. Reach it from a checkout, not from
a shell on Render — the image copies `backend/app` alone, so `tools/` is not on the box:
```
AIDND_DATABASE_URL=<Neon URL, direct endpoint> AIDND_SECRET_KEY=<the web service's value> \
python -m tools.rewrite_memories --email you@example.com
```
`AIDND_SECRET_KEY` is not optional there: stored API keys are encrypted with it, and
with the wrong one `decrypt_secret` returns "" and every adventure is reported as having
no key — a run that looks fine and does nothing. Hand-written memories, and memories whose actions have been deleted, are left
alone; so is an adventure whose owner has no API key, because summarization spends the
user's own key and never the demo key.