[I] Triage CLI: 'move back' affordance to revisit / undo previously applied actions [airflow-steward]

["potiuk (via GitHub)" <gi...@apache.org>]

potiuk opened a new issue, #74:
URL: https://github.com/apache/airflow-steward/issues/74

   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 (`b` for back), or a menu entry on the post-action prompt?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] Triage CLI: 'move back' affordance to revisit / undo previously applied actions [magpie]

["potiuk (via GitHub)" <gi...@apache.org>]

potiuk commented on issue #74:
URL: https://github.com/apache/magpie/issues/74#issuecomment-5189998290

   **Status check against `main` — not implemented, and one of the open design questions can now be answered concretely.**
   
   **Not implemented.** [`interaction-loop.md:224`](https://github.com/apache/magpie/blob/main/skills/pr-management-triage/interaction-loop.md) offers `[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. The `gh pr ready --undo` calls in `actions.md` are 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:
   
   - The **gist** rules itself out explicitly ([`session-history.md:281-287`](https://github.com/apache/magpie/blob/main/skills/pr-management-triage/session-history.md)): append-only, human-readable, and *"not designed to be parsed back into structured data"*.
   - The **local state file** (`: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.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@magpie.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org