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>
