The pre-password "Taken" list goes. It could only ever be a column of
timestamps, and the card directly above it already said how many snapshots
there were and how recent the newest was — so it answered a question that had
just been answered. The real choice now lives on Contents, where snapshots have
names. The times came out of the scan and verify payloads with it; carried but
unread is debt.
The read result is a card too, matching the folder's. They were a card and a
sentence sitting one above the other, looking like two different kinds of
thing. Shortened to the host and what it holds — "Change-Me · settings + 2
apps". No "continue to see what will happen": Next is right there and has just
become available, which says it better.
And a real bug, caught by asserting Next's state after a genuine read rather
than a simulated one: readBackup CLEARS the password field the moment it hands
the value to the host, so a gate that re-checked the source fields reported a
missing password about a repository it had already opened. Next stayed disabled
for good after a successful read. Both the button and validateStep now treat an
open backup as settling the question — they have to agree, because
enabled-but-refused is worse than either alone.
The test that caught it could not run at first: BACKUP was declared after the
block using it, so the whole eval died in the temporal dead zone and reported
as "the browser failed".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three things.
The snapshot times now sit under the count. They are the only thing about a
snapshot legible without the key — the filename is an opaque hash and
everything describing what is inside is in the encrypted object — so they
answer "is this the backup I think it is, and did it run when I expect", which
is the question someone actually has before typing a password into it.
Next is disabled until the backup has been opened, rather than accepting the
click and then arguing. validateStep still refuses, for anyone who arrives
another way, but the disabled state says "something above me is unfinished"
before the click instead of after. It re-enables on a successful read and goes
back to disabled the moment the path, type or password changes, since that read
is then about a different repository.
Error text was rgb(220,53,69) on a 10%-opacity danger background — a mid red on
a dark blue panel, legible in theory and squinted at in practice. Lighter text,
a firmer border, more line-height. The test asserts perceived brightness rather
than an exact colour, so a theme change cannot quietly undo it.
One real bug on the way: _adoptSingleResult rebuilt the record by hand, naming
four fields, so `times` was dropped and the list came out empty even though the
data was right there. It passes the whole record through now — a field lost
that way is invisible until something downstream needs it.
Not done, and worth stating plainly: these times are not selectable. Picking
one would be picking a hash — a restic snapshot is ONE app's data or the
settings tree, not a whole machine, and which is which cannot be known until
the repository is open. Choosing a point in time to restore from is a real
thing to want and belongs on Contents, after unlocking, where the snapshots
have names.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Backup step opened with an empty box and /mnt/usb/libreportal-backups as
the placeholder — a path nobody has, presented as the shape of the answer.
Someone rebuilding a server was being asked to recall from memory the one thing
they came here because they had lost.
Two additions, and the point of both is that neither needs the repository
password. A restic repository keeps one file per snapshot under snapshots/, so
"is there a backup here, and how many" is a directory listing. Nothing is
decrypted — reading what is IN those snapshots is the next step, and that does
need the password.
restore scan looks where a backup actually is: this install's own backups root
(the disk often survives), every location the install already knows about, and
one level under each non-OS mount, a just-plugged-in drive being the other half
of "the system drive died". Bounded to named shapes and maxdepth 1, never a
filesystem walk — a scan nobody waits for is a scan nobody uses. Results are
buttons, most snapshots first, each showing its count and the age of its
newest snapshot; clicking one fills the path in.
restore verify <path> answers the same for a typed path. Its most useful answer
is the near-miss: pointing at the folder that CONTAINS the repositories rather
than at one of them, which it names and offers as a button rather than
explaining the distinction in prose.
A repository is recognised by config plus the snapshots, keys and data
directories together. config alone would match any folder with a file of that
name, and offering a stray directory as someone's backup is worse than finding
nothing.
The placeholder now comes from this machine — the first repository found, or
the install's own backups root — since a placeholder's job is to show the shape
of the answer and only a real one does that. The backups root is in the storage
feed for it.
The found entries are buttons and had to own their geometry: .setup-app-card
carries no layout, it is a bare wrapper elsewhere, so a <button> wearing it
collapsed to one cramped line.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
