After SAPE-17, the old product name is gone from the format tag and from
every key label. It survives in exactly three non-test constants, each spelled from single-character
literals so that a string grep does not find it:
internal/naming/naming.go:31 var target = string([]byte{'r','s','q','l'})
internal/server/server.go:857 var oldFileExt = "." + string([]byte{'r','s','q','l'})
internal/cli/cli.go:474 var oldFileExt = "." + string([]byte{'r','s','q','l'})All three are intentional, and the page should say so rather than read as a cleanup list.
grep -F for the old name finds none of them, which is the point of how they are
written. The full set across the tree is eight sites: these three plus five in
_test.go files (signing_test.go:61,224,
connection_test.go:53, server_test.go:640,
cli_test.go:429), which mirror the production ones on purpose.naming.target is the patrol's own needle. Its comment says why it is
spelled apart: "Not for disguise: it is so that adding this package to the tree does not itself
become a hit, and so that nobody can 'fix' a red patrol by deleting the one place that still names
what it is watching for." Removing it disables the patrol.oldFileExt are a migration aid, not a leftover.
checkOldExtension refuses to open a database when the .sapedb path does
not exist but a same-named file under the old extension does. That is the one variant of the old
name that fails silently: an old connection scheme or signing label gets a parse or verify
error, and a file with the old format tag is refused as ErrNotSapedb — but a
missing .sapedb next to a real old file does not look like an error at all. The opener
would create a new empty database and every call would answer as if the real one were empty. That
is not "not found", it is data going invisible.os.MkdirAll and
before vfs.LockDir, so a refusal leaves SAPEDB_DIR exactly as it found it
— no .lock, no account folder. Pinned by
TestARefusalOnTheLockedDirectoryLeavesNoAccountFolder
(internal/cli/cli_test.go:838). That job has nothing to do with the name, so even a
decision to drop the migration aid does not simply delete these lines.oldFileExt comments say
"This is now the last place in the tree that still carries the old name at all." There are
three places, and two of them are the two copies of that sentence. The environment-variable twin the
same comment refers to was removed in 88178cc; the sentence was not updated when the
second copy of the guard made it false.
Does it lose data, break a promise on a public surface, or stop somebody installing and
running? No — and the residue is the thing preventing a data-loss shape, not
causing one. Removing oldFileExt would take away the guard that stops a silently empty
database; removing naming.target would take away the patrol that keeps the rename done.
Defer, and reframe: there is no cleanup to schedule here. The open decision is when the migration aid retires, which both comments already call out as "meant to be removed once operators have confirmed they have moved their database files". Since no build has ever been released, there are no such operators and no such files, so the aid guards against a case that cannot yet exist — but it costs nothing and removing it is a decision about a migration, not about a rename.
The stale sentence is a two-line edit and is worth doing whenever somebody is next in either file. It is not a release gate; it is the reason this issue is open rather than closed.