The newest row for a path IS the file's current content, so its `restore`
button could only ever journal a +0 −0 change — attributed to a real person,
on a real device, replicated to every teammate, in the audit trail the whole
history story depends on. It was also the single most tempting row to click.
One rule, enforced at both ends. handleRestore now 409s when the requested
sha is already the path's head (journal.Replay, the way the CLI already
answers this question), placed after the "no such version of that path" 404
and before CheckWrite so an unknown sha still 404s and a refused restore
records no quota. HistoryView computes each path's head from the loaded
window — entries are strictly newest-first, so a path's first occurrence
decides — and restoreSha returns undefined for bytes that already are the
head, which removes the button, its title and its busy state together.
The rule is content equality, not row index: an older row hand-reverted to
the current bytes is just as much of a no-op, and matching what the server
checks means the UI can never show a button that errors.
A newest DELETE leaves the path out of the replay, so a deleted file still
restores — that is a real change. Confirm-on-restore stays out, deliberately
(HistoryRow.tsx:154): the defect was never "restore should ask", it was
"restore should not be offered where it cannot do anything".
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat(history): group agent runs and restore any version (BEA-6)
BearDrive recorded everything and could restore nothing. Now every version
of a file has a Restore button — in the hub's History view and as
`bdrive restore` — and the changes one agent run made read as one card
instead of N loose rows.
Restore is a NEW put op pointing at the old blob: journals are never
rewritten, so one-writer-per-journal holds and peers converge on the
restore like any other edit. The hub reuses RemoteSource.Commit (the
upload commit minus the upload); the CLI writes the bytes into the working
folder and lets the ordinary cycle journal them, so the sync engine gains
no new write path.
Grouping is a pure frontend group-by on (note, device) over the existing
/history response — no journal or API change.
Known gap, stated in the UI and the docs: nothing in the hub writes a
delete op yet, so a file a run *created* cannot be un-created.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(history): don't repeat a run's note on every row in its card
UI pass on the real hub: inside a run card the note is the card's header, so
printing it again on each row said the same thing N times. The header now
carries the note (linkified, so an agent's session link still opens) and the
collapse control is its own button rather than the whole header — the link
could not live inside a button.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
