Repository navigation
Triage CLI: 'move back' affordance to revisit / undo previously applied actions #74
Description
During a triage session the user should be able to step back and revisit a previously-applied (or previously-skipped) PR — to inspect what was applied, undo, or re-classify.
Why: mistakes happen; right now the only recovery is to manually re-find the PR on GitHub and reverse the change there.
Open questions for design
- Scope: per-PR step-back only (one previous), per-session history (any earlier PR), or per-batch?
- Undo semantics: just review the action, or actively reverse the GitHub-side change (delete comment, re-add label, restore draft state)?
- Storage: in-memory session log only, or persisted across runs so a session interrupted and resumed still has its history?
- UX: dedicated key (
bfor back), or a menu entry on the post-action prompt?
Activity
potiuk commentedon Aug 5, 2026
Status check against
main— not implemented, and one of the open design questions can now be answered concretely.Not implemented.
interaction-loop.md:224offers[B]ack to group, but that is navigation back to the group listing, not stepping back to an applied action. Easy to mistake for this when scanning the file. Thegh pr ready --undocalls inactions.mdare the draft action's own mechanics, unrelated to session undo.On the "Storage" open question — neither existing mechanism can back this. Session-history now exists, so it looks like the natural foundation. It is not:
session-history.md:281-287): append-only, human-readable, and "not designed to be parsed back into structured data".:38-47) holds three fields —history_gist_id,history_gist_url,history_filename. No per-PR action record at all.So an undo needs a new structured per-PR action log (PR number, action applied, the GitHub object IDs created — comment ID, label name, prior draft state — and a timestamp). It cannot be layered on what is there. Worth starting the design from that rather than discovering it later.
That also bears on the Undo semantics question: reversing a GitHub-side change requires having recorded the created object's ID at apply time. If the log is added, record those IDs from the start even if the first version only supports review-and-reclassify — retrofitting them means the undo cannot act on any action taken before the change.
The Scope and UX questions are unaffected and still open.
ameeer-in commentedon Nov 13, 2026
@potiuk I’d like to pick this up. Your storage distinction makes sense: neither the history gist nor its local state file contains the evidence needed for undo.
I propose adding a structured per-PR action log alongside the existing triage session cache, reusing its atomic-write helper. It would record the repository, actor, PR/head, timestamp, relevant before/after state, created object IDs, and each operation’s outcome from the start.
For scope and UX, I’d add
[H]istoryto revisit any applied or skipped PR within the saved session, leaving[B]ack to groupunchanged. Revisit would refresh the PR and bypass only its session-cache suppression; normal classification and safety rules would remain.Recovery would unwind actions on a PR newest first, with an explicit preview and confirmation. It would account for labels, assignments, draft/open state, session-created comments, and Magpie’s description block. Conflicting edits or incomplete evidence would block the affected recovery. Irreversible effects would be identified explicitly, and partial recovery would never be reported as a full undo.
I’d cover compound actions, partial failures, repeated recovery, saved-session resumption, and older cache files in tests and behavioral evals.
Does this resolve the remaining scope and UX questions sufficiently to proceed?
ameeer-in commentedon Nov 13, 2026
Opened #2065 for this.
It adds the structured action log discussed above, history/revisit support, and confirmed recovery based on recorded operation outcomes. Compound actions and partial failures are tracked individually; irreversible effects remain explicit.
The PR is ready for review, particularly the session scope and recovery semantics.