[C-Hipple]

Summary

With [Webhooks] configured, the server already patches its caches from each GitHub delivery, but an open page only found out on a manual Sync or a reload. This uses the server → client notifications from #303: for every PR a delivery changes, the server sends a Server.PRUpdated notification, and the web client re-reads that PR in place and shows a short toast saying what happened ("alice approved", "bob commented on server/notify.go", "Checks failed: build").

The aim is for this to be as seamless as possible:

• The refresh reads from the caches the delivery just wrote, so it never waits on GitHub, and it shows no loading state.
• Open threads, expanded hunks, the comment being written and the feedback being typed are all kept.
• A new diff (after a push) waits while an inline comment is open, since the comment is anchored to a diff row. A toast says the page will refresh once the comment is done, and closing the form applies the update.
• Bursts are batched: a push sets off one delivery per check, so updates are collected for 400 ms from the first one and the page refreshes once.
• If the /api/events stream drops and reconnects, the review and the list re-read quietly, since anything sent while it was down is lost (as Push plugin and AI result changes to clients instead of having them poll #305 does for plugin and AI changes).
• CI is announced only when it settles (passing, or newly failing). Checks starting update the CI line without a toast.
• The user's own changes (own: the actor is the configured GithubUsername) refresh without a toast, since the UI already reported them.
• On the review list, a changed row refreshes in place and gets a brief accent highlight. The toast names the PR (widgets#42: alice edited the title).
• With a filtered diff on screen (Serve the diff since my last review or interaction, precomputed and cached #306's diff-range select), the new full diff is kept for comment positions. The filtered diff is asked for again quietly after a push or the user's own review or comment, either of which can move it, and is swapped in only if the answer changed.

Changes

• workflows/webhook_changes.go (new): PRChange, SetPRChangedHook, and the summary helpers (pullRequestSummary, reviewSummary, reviewCommentSummary, reviewThreadSummary, issueCommentSummary, ciOutcome / ciSummaryChange).
• workflows/webhook_events.go: each apply function's heldPR now carries changes (the cache fields it wrote, head after a refetch, pr for a pull_request payload) and a summary. applyWebhookEvent hands each changed PR to the hook. patchCachedCI returns what it wrote, plus a summary when the head's CI settles. A delivery that changed nothing (PR not held, cache missing) sends nothing.
• workflows/webhook_membership.go: when the re-check rewrites section rows, it sends a sections change so the list can pick up adds and drops.
• server/notify.go: PRUpdatedMethod, the PRUpdated payload, and NotifyPRChanged, alongside Push plugin and AI result changes to clients instead of having them poll #305's plugin and AI notifications. main.go wires it up in server mode.
• bun_client/frontend/src/server_events.ts: parsePRUpdate, changesPR, prUpdateMessage (newest three per burst, …and N more), onPRUpdates (the batching), and onReconnect (a reconnect after a drop, skipping the first connect). Matching a PR uses Push plugin and AI result changes to clients instead of having them poll #305's isChangeFor. hooks/usePRUpdates.ts wraps them for React.
• Review.tsx: refreshLive, which holds a new diff while a comment is being written, keeps unchanged state identity, and drops a stale response if a newer refresh has started. Plugin output isn't reloaded after a push, since with Push plugin and AI result changes to clients instead of having them poll #305 the re-run plugins announce themselves. It builds on Serve the diff since my last review or interaction, precomputed and cached #306's fullDiffRef / applyFullDiff, and loadFilteredDiff gains a quiet mode (no spinner, no error toast, and the diff left alone when the answer hasn't changed). PRList.tsx: refreshes its rows in place, skips updates about PRs it doesn't show (unless it's a section change), and highlights changed rows (.crs-row-updated, a steady tint under prefers-reduced-motion). App.tsx passes the toast to the list.
• e2e: E2E.UpdatePR in the fake backend and backend.updatePR in the harness simulate a delivery. live_updates.e2e.ts covers seven cases: in-place review refresh, the user's own change, a diff held for an open comment, a sections-only update, a push with a filtered diff showing, another user's comment with a filtered diff showing, and the list.
• Docs: protocol.md (Server.PRUpdated), webhooks.md ("Clients Follow Deliveries"), web_client_features.md §3.18, building_clients.md, CLAUDE.md, e2e/README.md.

Since #305 the Emacs client and the Chrome extension subscribe too, but they only act on the plugin and AI notifications and ignore other methods, so Server.PRUpdated doesn't affect them.

Test Plan

• go build ./... passes
• go test ./... passes (new: workflows/webhook_changes_test.go, TestNotifyPRChangedSendsAPRUpdated; also under -race for the new tests)
• bun run lint, bun run format:check, bun run type-check, tsc -p e2e in bun_client/
• bun run test in bun_client/ (new server_events.test.tsx cases for parsing, messages, batching and reconnects)
• Full bun_client e2e suite after merging main (97 passed, 2 opt-in real-LSP specs skipped), including the seven live_updates.e2e.ts specs. I confirmed the sections-only spec fails when the review's changesPR filter is removed.
• Manual: with [Webhooks] on, open a review and comment / approve / push from github.com, and watch the page update with a toast.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AMPYZg3x4vXfFzqgvJ1AbU