Four removals and one move, all found by reading the tree rather than by a
test, because none of them can fail: code nobody calls cannot be wrong.
Work.launched_with had no caller anywhere, tests included.
StealthSession.where_pages_are had no caller in the product. Three assertions
kept it alive, and they were the only reason it still existed: it is the cheap
half of describe_pages, from the days when a command asked for page urls on
every call. The two assertions worth keeping moved onto describe_pages, which
is the one thing that answers where the pages are.
The saved session file carried a name that was always a copy of its id. It was
kept on the argument that an older build rolled back onto this directory would
expect to find it, and no build ever read it: its one reader was known(),
which went with the session_list tool when MCP stopped having a session
concept. Files already on disk still carry it and are read exactly as before -
load hands back what it finds and remembered() reads two keys.
And the thing the storage split missed, because it went looking for duplicated
VALUES. When aihawk.storage was carved out it took the three things that carry
a value somebody could get wrong: where the data lives, how an id becomes a
file name, how a file is replaced without a torn read. Reading and deleting
stayed behind in both halves, four lines each, looking like plumbing. They are
not: load answering None for a file that will not parse is a DECISION, and it
was written twice with only one of the two explaining itself. Deleting was the
same again, and both copies answered a bool that neither caller read and whose
False meant "there was nothing there" and "it could not be deleted", which are
opposite news - the exact ambiguity Sessions.forget carries a scar from, on the
day it answered False for a session somebody else had already deleted and the
page said it was still working. Both now live in storage, once, and erase
answers nothing.
Two gates make the removals stick rather than leaving them to be undone. The
saved session's whole key set is asserted, the way the listing's rows are since
0.54.0 - nothing was watching that document, which is how a copy of a field
sat in it unread. And the wiring is asserted rather than the behaviour: both
halves are shown to go through the one reader and the one eraser, because two
identical implementations agree on every input by construction, which is
exactly why this duplication survived a refactor that went looking for it.
Suite 594 green, and seven known-bad inputs, seven killed: each half given
back its own parse, each half given back its own unlink, an unparsable file
raising instead of reading as nothing, erasing something absent failing again,
and the copy of id coming back into the file.