[krishhgg]

t3term now opens or closes T3's refresh subscription as soon as a config turns the environment's pullRequests capability off or on. It used to wait for the next key or read answer.

• update_config in src/tui/mod.rs calls read_opened_pull when pullRequests changes. That's the same step a key runs, and it calls follow_refreshes.
• docs/pull-request-panel.md's Refreshes row and the linked-pull-requests feature file say so. The feature file's gotcha gives the count a verifier should see: two pullRequests.subscribeRefreshes by the end of the recipe.

Nothing on screen changes.

Decision log

What I noticed. Sol's verdict on #90 noted that the linked-pull-requests recipe sometimes ended with one pullRequests.subscribeRefreshes and sometimes two, on the same build. It suggested a 1500 ms idle wait after capability off in the recipe.

How I confirmed it.

• on_config_event and update_config never called follow_refreshes. Only keys, the live timer and read answers did, through read_opened_pull.
• So the subscription closed while pullRequests was off only if a read's answer happened to land in that window. In Sol's runs that was the pullRequests.stack answer.
• I let the reads settle (wait --idle 1500 after the details open) and ran the recipe five times on master's build (748c6b8's tree). All five counted 1: the first subscription stayed open through capability off, and nothing subscribed again after on. On this branch's build all five counted 2, with the interrupt right after off and a new subscription right after on. The unchanged recipe counted 2 in five runs on each build.
• The desktop passes a null query once capabilities.pullRequests isn't true, and re-reads the server config on each render (apps/web/src/components/RightPanelTabs.tsx:749-760 at f570bd2), so its reads and their refresh trigger follow the config straight away.

Options.

• Chosen: follow the capability in t3term. The count is then the same however the reads are timed.
• Rejected: Sol's idle wait in the recipe. It would hide the lag rather than remove it, and a verifier comparing counts across builds would still see 1 or 2.
• Rejected: calling read_opened_pull on every config change. Provider status updates come often and can't change what it decides, so the call runs only when pullRequests flips.

What review changed. Greptile found nothing. Sol passed it with a note: on either build, line 27 of the recipe can leave the link's details before the host's detail answers, so the fixture fails that read and t3term asks for no stack. That is the recipe's own race, apart from this fix, and a follow-up waits for the host's read there.

Known limits.

• A read asked for while pullRequests was off is still dropped, not kept. Turning it on again doesn't read the open link until you open its details again, as before.
• The threadPullRequests capability alone doesn't touch the subscription, since reads follow pullRequests.

Tests

• the_refresh_numbers_follow_a_config_that_turns_pull_requests_off_and_on in src/tui/mod.rs: details held, on the list, then a config with pullRequests off, on, and on again. It checks that the subscription closes, a second one opens, and a config that leaves it on opens no third. With the three lines in update_config removed, it fails at assert!(app.refreshes.is_none()).
• On 774c81d, fmt, clippy and all 935 tests pass (837 lib, 2 main, 48 CLI, 48 RPC). The linked-pull-requests recipe passes on its build.

🤖 Generated with Claude Code

Confidence Score: 5/5

The PR appears safe to merge.

Summary

Makes the refresh subscription follow changes to pullRequests immediately, without waiting for input or a read answer.

• T3 refresh subscriptions now follow pull-request capability changes immediately.

Known limits acknowledged by krishhgg:

• Reads requested while disabled are still dropped, rather than saved. This is an existing, intentional limit.
• Changes to threadPullRequests alone do not control the refresh subscription, since reads follow pullRequests.

_{Reviews (1) · Last reviewed commit: "Say what the refresh count is after the ..." · Reviewed by Greptile}

[krishhgg]

PASS+NOTES for head 774c81d4a0effb0f2a899a76a24f4e9a6114e9d7, patch id 143ecbb78b60eb2103240adfdd78669513ebae8c.
Verifier: GPT-6.1 Sol (xhigh), not the author. Base 748c6b86e7a30c4378bd2316ab9a56885a3ba541, the merge base with fetched origin/master. Scenario links, 200x50, truecolor. Additional retained-detail checks used 200x69. The sweep used each recipe's stated scenario and size.

Claim	Base	Head
With reads settled before leaving details, capability off closes the refresh subscription and on opens it without input or another read answer.	Five runs kept one subscription. No interrupt between off and on.	Five runs counted two. Each interrupted after off and subscribed after on. All other RPC counts matched.
Restoring capability while loaded details remain open does not ask for an extra host read.	Two Summary runs kept detail, activity and stack at one each.	Same. One Code run also kept its viewed-file and HTTP diff reads unchanged.
A config that keeps capability on does not subscribe again, and a list with no retained read subscribes nowhere.	Both held.	Both held.
Nothing on screen changes outside the intended subscription behavior.	All 13 feature recipes passed.	All 13 passed; no unexplained screen difference.

Regression sweep: 13 of 13 recipes passed on base and head. src/tui/mod.rs can reach the mapped TUI features, so all 13 recipes ran on each side, including the CLI. Compared 113 paired text captures. Of these, 55 matched exactly and 45 differed only in run addresses or paths. The other 13 differed in clocks, spinners or reconnect phase. A separate same-phase reconnect control matched after port normalization. Across the sweep, the only RPC-count difference was pullRequests.subscribeRefreshes, one on base and two on head in the linked-pull-requests recipe.
Rules: doctor, live check and after-stop check passed for both sweeps, all 20 recipe repetitions and all corrected probes. Request comparisons are in sweep-comparison.json and claim-comparison.json.

Tests: formatting, Clippy with warnings denied, and all 935 tests passed locally on Rust 1.95.0. Removing exactly the three-line call block in update_config made the_refresh_numbers_follow_a_config_that_turns_pull_requests_off_and_on fail at assert!(app.refreshes.is_none()). The same test passed on unmodified head. Evidence: reversion.patch, reverted-test.log, tests.log.

Desktop reference: RightPanelTabs.tsx:749-760 at f570bd21 reads the current server config and passes a null query when pullRequests is not true. The new caller still uses pulls_project, live, and the take_*_ask gates. No unconditional host read was found. The updated feature file documents the subscription change.

CI: macOS, optional Linux and E2E smoke all passed on this head, run 39163390952. Greptile: passed on this head, zero review threads or inline findings.

Notes: .claude/skills/verify-t3term/features/linked-pull-requests.md:27 still has a pre-existing fixture timing race. Its metadata wait does not settle the delayed host detail before lines 31-33 remove and restore the link. That can make the fixture refuse #70 and omit pullRequests.stack on either binary. The unchanged recipe's subscription counts were base [1,1,1,1,2], head [2,2,2,2,2]; stack counts were base [1,0,1,1,1], head [1,0,0,0,0]. The author's unchanged-recipe counts therefore did not repeat here. Adding the requested 1500 ms settled-read barrier yielded stack count one on all ten runs and left only the intended subscription difference. This is a verification-recipe note, not a product regression.

Evidence root: /tmp/t3v-verdict/92/round1/. Repeated runs are in claims-base and claims-head; retained-detail checks are in edge2-base and edge2-head. Each run's final-status.json or run-path.txt records its own run path. No command relied on /tmp/t3v-current.

Binaries driven:

• Base /tmp/t3v-bin/748c6b86e7a30c4378bd2316ab9a56885a3ba541/t3term, LC_UUID FFDF7684-176A-301B-8488-2E7779B6D6DA.
• Head /tmp/t3v-bin/774c81d4a0effb0f2a899a76a24f4e9a6114e9d7/t3term, LC_UUID 6F3E8858-4A74-37A2-8336-960CDBF772F0.
• Head CLI integration-test binary /tmp/t3v-verdict/92/round1/test-target/debug/t3term, LC_UUID 15477969-137B-39E0-A76C-7C41BB968D43.

Both t3v build logs show Compiling t3term. The driver came from origin/master, unchanged in this PR. Cleanup: all runs stopped with t3v stop and checked before cleanup. All 64 tracked run directories and my three detached worktrees are removed. The main checkout and PR branches were not changed..