[krishhgg]

A link's details now keep their pull request current while you use t3term, as the desktop's live refresh does. Stacked on #57.

• While a link's details show, t3term reads the pull request again 5 minutes after its last read, if a key, click, wheel, mouse move or paste came in the 6 minutes before it reads.
• After 6 minutes with none, as after a Mac slept past the 5 minutes, it asks the host nothing more. The first input after that reads at once, unless the last read was under 10 seconds ago.
• Such a read sends pullRequests.detail alone, then pullRequests.activity only when the detail's updatedAt changed, as the desktop does. A detail that stayed the same keeps the last conversation. Refreshing from github.com… shows meanwhile, as for any read again.
• A read that failed is read again in full, and after a conversation that failed, the next read asks for both.
• The event loop sets a deadline for the next read only while one is due and you used t3term, so an idle TUI doesn't wake for it.
• A read that an input asks for draws at once, also where the input itself changes nothing, as a mouse move.

A new verify-t3term file, features/pull-request-live-refresh.md, maps this, and features/README.md lists it. Its recipe opens #60 and sends no input for 5 minutes, then checks Refreshing from github.com… and that the read asked for the detail alone. After t3v revise and over 6 minutes without input, it checks that nothing read, then clicks and checks a read at once that asks for the conversation too and shows its new remark. It takes about 6 minutes and 20 seconds, since the 5 and 6 minutes can't be shortened, so it lives in its own file. The links scenario needed no change.

Fixture server, #60's Summary tab during the second live read and after it. The pull request changed on the host without a refresh number, so the read asked for the conversation too, and a new remark from fixture-dev tops Comments:

Decision log

What I noticed

#56 and #57 left out the desktop's live refresh, as their Known limits say. A pull request that changed on its host without T3 hearing of it, such as a review given on GitHub, showed the old answer for as long as its details stayed open.

How I confirmed it

In T3 Code at f570bd2, useLiveRefresh (apps/web/src/hooks/useLiveRefresh.ts) reads every 5 minutes (LIVE_REFRESH_INTERVAL_MS) while the window shows, unless no pointerdown, pointermove, keydown or wheel came in the last 6 minutes (LIVE_REFRESH_IDLE_AFTER_MS). The first input after those 6 minutes reads at once through onArrival, at most once in 10 seconds (LIVE_REFRESH_MIN_INTERVAL_MS). The panel passes it detailQuery.refresh() alone (PullRequestDetailPanel.tsx:851-856), whether or not a detail came. It reads the activity again only when the detail's updatedAt changes (836-847, shouldRefreshPullRequestActivity in pullRequestDetail.logic.ts:163-168).

On a fixture server whose revise command changes a pull request's updatedAt and #60's conversation without a refresh number, I opened #60's details and timed the reads from the server's log:

When	Input	Requests	Conversation
Open, 06:26:56	Enter	detail, activity	5 remarks
+5:00	a key every 100 s	detail	kept, updatedAt the same
revise, then +10:00	last key at +9:41	detail, then activity 1.5 s later	6 remarks
+15:00	none since +9:41	detail	kept
revise, then +16:40	a key, 7 minutes idle	detail, then activity at once	7 remarks
+21:40	none since +16:40	detail	kept
+26:40	none since +16:40, so idle	nothing, and t3term's CPU time stays at 0.37 s
+27:40	a key	detail at once	kept

No control text reached the screen.

Options

• Chosen: count the 5 minutes from the last read of any kind. Rejected: a timer that starts when the details open, as the desktop's setInterval does, which reads again a moment after a refresh number's read.
• Chosen: a deadline in the event loop, armed only while a read is due and you used t3term, as the snooze wake is. Rejected: checking on the one-second tick, which runs only while a clock or spinner moves.
• Chosen: read on the first input after an idle spell, as the desktop does. Rejected: waiting for the next 5-minute mark, which shows a stale answer to someone who just came back.
• Chosen: read a failed read again in full. Rejected: reading again only a read that has a detail, which leaves a failure up until you reopen the link or press r, where the desktop tries again.
• Chosen: leave the desktop's reads on arrival, when a link's details open again or the window gains focus, for the next pull request. Opening a link again within a minute shows its last answer, as Show a linked pull request's reviewers, labels, checks and description from its host #50 decided, and reading on arrival changes that rule.

What review changed

Greptile found three gaps, fixed in 7bdeb1e and documented in 38812a5.

• A live read whose detail changed but whose conversation failed kept the new updatedAt beside the old conversation, so later live reads skipped the conversation until the detail changed again. A first read whose conversation failed had the same gap. A live read now skips the conversation only when both answers came and the last read missed neither.
• The idle cutoff was checked against the due time. A Mac that slept past it and woke 20 minutes later still read. Both checks now use the current time, as the desktop's onInterval does, and the event loop drops a deadline that passed while idle.
• No test ran the real reader. A new test runs read_pull_request over a socket to a fake T3 on 127.0.0.1. It checks the request order, that no conversation is asked for after a detail that stayed the same or failed, and that every read ends with Done. Each new assert fails with its fix taken out.

Later, CI on #64 failed the_open_details_read_their_detail_again_while_you_use_t3term. The key and the read it asks for each read the clock, and when the clock ticked between them the read was due 5 minutes and 1 ms after the key, past the test's bound. 12bfdd2 sets the test's clock ahead of the real one, so both read the same time, and the test now checks the exact 5 minutes. The fix is merged forward through #65.

For verify-pr, the refresh key branch was merged in at 09f6907 (643cf7e), which brings master's verify skills and #56's fix for a failed detail read again. The merge kept both branches' new tests where each added one after the refresh key's test. a0975f1 adds the live refresh feature file.

Merged the refresh key branch at 04add82 (ced4934), which brings master at 47e50cd. The README's unit test sentence keeps both sides' additions. Every added or removed line outside Markdown matches the patch at a0975f1 against its old base.

Known limits

• Opening a link's details within a minute of its last answer shows that answer, where the desktop reads the detail again once 10 seconds have passed. Nor does t3term read when the terminal gains focus. Both are next.
• A refresh number's read puts the next live read back 5 minutes. The desktop's timer counts from when it started and skips a read only within 10 seconds of its own last one.
• t3term can't tell whether its terminal is in view, so it reads while the details show and you used it in the last 6 minutes. The desktop stops its timer while its window is hidden.

🤖 Generated with Claude Code

Confidence Score: 5/5

The PR appears safe to merge; no new actionable issues remain.

Summary

Adds live refresh while a link’s details are open.

• Open pull-request details refresh while you use t3term.

All three earlier, unnumbered review findings are addressed: failed conversations are retried, overdue reads respect the current idle time, and a fake-server test covers request order and completion.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Five-minute deadline or return from idle] --> B{Details visible and no read running?}
  B -->|No| C[Wait]
  B -->|Yes| D[Read detail]
  D --> E{Saved answers good and updatedAt unchanged?}
  E -->|Yes| F[Keep conversation]
  E -->|No| G[Read conversation]
  F --> H[Finish read]
  G --> H

Loading

_{Reviews (6) · Last reviewed commit: "Merge the refresh key branch at 04add82,..." · Reviewed by Greptile}

[krishhgg]

PASS+NOTES for head ced4934741d05e8376521a07a75c5b9dd3a8df7a, patch id 9815fa1d006ad298da66d2b7b6b71fa24d33fe38.
Verifier: GPT-6.1 Sol (xhigh), not the author. Base 04add82da072cdbeb78a08662453a0ddccebf7b2. Scenario links, 200x60, truecolor; sweeps use each recipe's sizes.

Claim	Base	Head
Open details read again after five minutes, keeping an unchanged conversation	Stayed at 1 detail and 1 activity request	Detail request at +300.006 seconds; 2 detail and 1 activity request, still 5 comments
Idle suppresses the following five-minute deadline	No automatic reads	Extended run passed ten minutes with only 2 detail and 1 activity request
Returning after idle reads a host change without a refresh number	Click kept 5 comments and sent nothing	Refreshing shown, then 6 comments; 3 detail and 2 activity requests, activity after detail

The recipe waits five real minutes without terminal input. wait, captures, status and revise send no input. The extra run also passed the second deadline. No clock shortcut was used.

Regression sweep: 10 of 10 on base, 11 of 11 on head. Nine unchanged feature recipes have identical rpcRequestsByTag; 31 captures match after normalizing clocks, spinner phases, ports and run IDs. Master 47e50cd1e453176c39317ae84e0ca9a9d8340906 recipes ran on both builds: 9 of 10 each, with the page expectations below.
Rules: check passed live and after stop on the completed claim runs and every sweep recipe; sessions revoked and sockets closed. Requests: Manual counts were base 1 detail/1 activity throughout; head 1/1 at open, 2/1 at five minutes, 2/1 idle and 3/2 after the return click. The extended head run held at 2/1 past the ten-minute deadline.

Tests: 483 TUI tests passed from a fresh compilation of this head. Separately removing the failed-conversation retry guard, the current-time deadline guard and the current-time read guard in a scratch worktree made each corresponding test fail assertions. The real socket reader test passed.
CI: macOS, Linux build, E2E smoke and Greptile passed on this head. Greptile: 3 review threads, all resolved and answered; no new finding.

Binary provenance, Rust 1.95.0. Each build log contains Compiling t3term:

• Base 04add82da072cdbeb78a08662453a0ddccebf7b2: LC_UUID 57191559-E711-3AA0-9CE9-DDF314410886.
• Head ced4934741d05e8376521a07a75c5b9dd3a8df7a: LC_UUID 8C190BC6-3B66-32A5-96EE-C603C9E63C09.

Notes: master's page recipe line 66 expects 3 of 11 after the parent stack's Timeline tabs have replaced that row. It fails identically on base and head. The updated recipe present in both builds passes. No product finding in this layer.

Evidence: /tmp/t3v-verdict/58/claims-base/, claims-head/, smoke-head-own/, smoke-head-master/, regression-comparison.json, binaries.json and head-tui-tests.log.
Extended idle evidence is in idle-cutoff-base/ and idle-cutoff-head/. The original extra baseline wait used an invalid stability duration; its completed observation is recorded in additional-observations.log.