You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Observed during the change-card UI/UX review of the file-write-safety series (epic #1375) while verifying the B3c rollback flow against the acceptance criteria.
What was wrong
The change-card rollback button restored a file to the checkpoint the card was keyed by - i.e. the step's own post-write checkpoint. For the most recent step that is a no-op: the card would say "Rolled back" while the file kept exactly the content the agent just wrote. That contradicts the epic acceptance criteria ("the user can always see and undo what the agent did"; "roll back per step or per file") and the card's own confirm copy ("Restores the previous content").
There was also no forward direction: once a user (or a later step) moved past a step's content, the UI offered no way to bring a file back to its most recent recorded version.
What changed
Rollback now means "undo this step's write" (pre-step semantics). The restore target is resolved from the B2 change journal: the file's immediately preceding journal entry's checkpoint (the state it had before the step). For a first-ever change of the file, the task-start baseline is used - undoing a created file deletes it again, undoing a deleted file restores it.
Per-file "Restore latest version". A new forward-direction control on every change-card file row restores the file to its most recent recorded write checkpoint. A task that never wrote the file is a clean no-op (still reported as success).
UI polish from the same review. The per-file rollback confirmation now shows the same warning text as the step confirmation, the copy now says what actually happens, and the 18 locales were updated.
feat(webview): change cards UI and rollback buttons (B3b, #1375) #1412 (B3b change-card UI) - new head 9a430d6: new webview message + handler case, per-file restore-latest control with two-step confirmation, result correlation via the existing checkpointRollbackResult shape (kind-distinguished), and the i18n copy correction.
Observed during the change-card UI/UX review of the file-write-safety series (epic #1375) while verifying the B3c rollback flow against the acceptance criteria.
What was wrong
The change-card rollback button restored a file to the checkpoint the card was keyed by - i.e. the step's own post-write checkpoint. For the most recent step that is a no-op: the card would say "Rolled back" while the file kept exactly the content the agent just wrote. That contradicts the epic acceptance criteria ("the user can always see and undo what the agent did"; "roll back per step or per file") and the card's own confirm copy ("Restores the previous content").
There was also no forward direction: once a user (or a later step) moved past a step's content, the UI offered no way to bring a file back to its most recent recorded version.
What changed
Affected PRs
Context