[Feature Request] Continuous review sessions with live updates and agent replies

[rrei]

Continuous review sessions with live updates and agent replies

Summary

Today, submitting feedback ends the session: the decision resolves, the server stops, the tab is done. The core ask is for the review/annotate surface to stay live after a submit so you can keep exploring the material and keep sending comments to the agent while it works on the feedback you already sent - and for the agent to reply and for the material to update live. A one-shot handoff becomes an ongoing review conversation.

Core behaviour - continue reviewing after submit

• After a submit, the tab does not close. The session stays live; you keep browsing and adding comments.
• Delivery-mode config knob:
  • manual - during the live session, comments are delivered only when you explicitly send one or more via the Send button (what happens to unsent comments on Accept/End is left open below);
  • automatic - each comment is queued for delivery immediately and reaches the agent at its next contact point (e.g. a PreToolUse hook).
• The agent keeps working on feedback already received; new comments are additional input, not a blocking gate.

Session controls

The single "submit" button is replaced by explicit controls:

• Send - deliver the current batch of pending comments and keep the session alive.
• Accept - final user approval; ends the session. May also carry any pending/unsent comments.
• End - ends the session without approval; the agent is notified (queued immediately, received at its next contact point).
• Close the tab - ends without approval implicitly; a keepalive timeout is picked up by the agent.

Agent replies

Once the session is live, the agent can reply to user feedback. It only replies to existing user comments - it never opens new comments or annotations of its own. Each reply states one of:

• accepted and addressed, linking the respective commit(s) and specific line ranges, if applicable;
• pushback on the feedback;
• request for clarification / more info.

A reply is sent only after committing the associated changes. The only exceptions - where the agent replies without making any changes - are when it needs clarification / additional context, or wants to push back on the feedback.

Rendered GitHub PR-thread-style, and the user can mark comments/threads as resolved (purely UI/Plannotator state; no message is sent to the agent).

Live change detection

Change detection is unified on git. For plannotator annotate, use a disposable git repo so every surface reduces to the same mechanism:

• plannotator review - the existing git workspace (working tree / PR head).
• plannotator annotate <file|dir> - versioned in a temporary git repo.
• plannotator annotate <url> - download the page to a temp dir, then version that dir as a temporary git repo.

Locate these temporary repos under the plugin's data dir, where the agent host (e.g. Claude Code) usually already has write permission, so the agent can commit without blocking on a permission prompt (writability is host-dependent - see Open questions).

For plannotator annotate, every commit to the temp repo is synced back to the original location (the file or directory). URL-backed sessions are the exception - there is no writable origin to sync to.

The surface refreshes as new commits are detected.

Comment delivery and freshness

• Each comment is stamped with the revision it was authored against (a revision identifier; its exact representation is left open below).
• At delivery time (hook-based), check whether the targeted lines changed since that revision.
• Stale-target config knob:
  • hold - don't deliver; report status back to the browser;
  • deliver-with-note - deliver anyway, annotated "this may be stale - it referenced revision <id>, since changed".
• Every comment carries a delivery status shown in the browser (WhatsApp-style): queued, delivered, delivered-stale, held-stale.
• A held-stale comment isn't a dead end - you can re-anchor it to the current revision, edit and resend it, or discard it.

Acceptance criteria

• A mode exists where submitting feedback does not terminate the session; the tab stays open and keeps accepting comments.
• Session controls: Send (flush pending, stay live), Accept (approve and end, optionally carrying any pending comments), End / tab-close (end without approval, agent notified).
• Delivery-mode knob selects manual (explicit Send) vs automatic (each comment delivered at the next possible delivery point).
• The agent posts replies to user feedback - accepted (with commit link) / pushback / clarification - and nothing else.
• For plannotator annotate, the agent commits its changes to the temporary git repo (under the plugin's data dir) before replying, except for clarification-only or pushback-only replies.
• For plannotator annotate, committed changes are synced back to the original file/directory (URL-backed sessions excepted).
• The UI renders PR-style threads and supports marking comments/threads resolved (UI-only; not sent to the agent).
• Change detection is unified on git, including a disposable repo for plannotator annotate file/dir/URL.
• Every comment carries the revision id it was authored against and a delivery status (queued / delivered / delivered-stale / held-stale).
• A stale-target policy knob selects hold vs deliver-with-note.

Open questions

I'm a user filing a feature request, not prescribing an implementation - these are the design questions I know I'm hand-waving, left for whoever picks this up:

• URL-backed annotate sync. The local copy is a normal temp repo, so the agent edits and commits there as usual; there's simply no writable origin to sync those commits back to. What, if anything, should happen to them - discard, or offer an export?
• Snapshot identity in review. A bare commit hash can't uniquely pin a comment authored against a dirty working tree. Some fuller snapshot (a synthetic commit/tree, plus path and diff side) is probably needed.
• Stale-range algorithm. "Did the targeted lines change" needs a real definition: mapping an old line range onto the new revision across renames, deletions, overlapping edits, and diff side (old vs new).
• Delivery semantics when the agent isn't running. What does delivered mean between turns, when stopped, or if no further hook fires? Ordering, retries, idempotency (duplicate hook fires), and offline queuing are all unspecified.
• Accept/End with pending comments. If queued or held-stale comments remain at Accept/End, are they flushed, discarded, or does approval block until they resolve?
• Reply commit links. A throwaway local repo has no browser-addressable commit URL - how does a reply's "linked commit" become navigable?
• Plugin data-dir writability. Assumed writable by the agent host; this is host-dependent. What's the fallback when it isn't?
• Concurrency. An agent commit or a live refresh can race with an in-progress line selection - the displayed revision a comment anchors to should be captured atomically at annotation time.