fix(web): delay thread shortcut hints by 200 ms - #8172

💭 I'm looking into the new useThreadJumpHintVisibility hook and tracing where it's imported from to understand the change.

1. git_tools — useThreadJumpHintVisibility

2. git_tools — bce6809..97d9afd

💭 I notice the useThreadJumpHintVisibility hook already existed at the merge base, since the diff only shows the delay change plus Sidebar.tsx — meaning it was added in a prior commit before this run. That aligns with the earlier flagged commit for Sidebar.logic.test.ts. I want to check the hook's history to confirm.

3. browse_code — apps/web/src/components/Sidebar.logic.ts

💭 I'm checking whether the hook already existed at the merge base — confirming this PR just migrates Sidebar.tsx to use it and increases the delay. I'm also considering a possible ordering bug where the controller effect updates jump hints visibility before mounting completes, since child effects fire before parent effects. Since effects run in declaration order within the same component, the controller effect (declared earlier) fires before the consumer effect, so timing is fine on mount, and the stable callback reference means no unnecessary reruns. There's a minor inconsistency where the hook resets internal visibility state on controller recreation but the React state itself isn't reset, though that only matters on remount. Overall this diff is mostly a state refactor and timing tweak rather than something touching shared UI components, styling, or layout, so it's low-relevance for a UI-consistency check. Now I want to check whether useState is still used elsewhere in Sidebar.tsx given it's a large file, and whether LegacySidebar.tsx — which matches the include patterns but wasn't touched — has any related duplication worth flagging. I also want to verify whether the delay change from 100 to 200 broke a hardcoded boundary value in the Sidebar logic test, since a previous run flagged that test for hardcoding a literal timing value.

4. git_tools — THREAD_JUMP_HINT_SHOW_DELAY_MS|advanceTimersByTime

💭 Good, that test issue is resolved since it's now derived from the constant. Now I'm checking whether there's a UI-consistency issue in the current diff, looking at the jump hint area in Sidebar.tsx and whether LegacySidebar used the same hook and setShowJumpHints pattern at the merge base.

5. git_tools — howJumpHints|showThreadJumpHints|shouldShowJumpHintsNow

💭 I'm checking Sidebar.tsx around the sync effect ordering, verifying whether the controller exists before shouldShowJumpHintsNow is evaluated on first render, since the earlier effect at line 2312 should run before the one at 3343. Now I'm considering React StrictMode's double-invocation of effects: mount, cleanup, remount could recreate the controller with isVisible false, but since the consumer effect at 3346 also re-runs during the second mount, the sync should still hold. I'm tracing the dependency array on that consumer effect to see if the controller reference changing could cause a stale sync issue. This is really the crux of the PR: migrating Sidebar.tsx to the same delayed hint controller that LegacySidebar already used, so the fix is about preventing a "sticky" hint that lingers after the modifier key is released. Checking that release path — shouldShowJumpHintsNow going false triggers sync(false), so the hint hides immediately as expected, and the 200ms delay only applies to showing hints, not hiding them. Since the review check focuses on shared UI/styling/layout consistency and this diff touches none of that, I'm concluding there's nothing here that would trigger a finding.

6. git_tools — HINT_(SHOW|DELAY)|_HINT_DELAY|hintDelay|JUMP_HINT

7. browse_code — apps/web/src/components/Sidebar.tsx

💭 I'm checking whether the ordering between the controller-creation effect and the consumer effect is actually safe, and now I'm wondering if controllerRef could still be null the very first time updateThreadJumpHintsVisibility runs during initial effect flush. Effects still fire in declaration order in the commit phase though, so the hook's effect runs first regardless. I don't see a real regression here — cleanup on unmount and state updates via onVisibilityChange look consistent — so I'm just double-checking that useState is still used elsewhere in Sidebar.tsx to make sure imports won't break lint, then moving on to check LegacySidebar's usage of the hook.

8. git_tools — useState

💭 This UI consistency check is clear with no remaining findings. Since the response format requires JSON but the request calls for just "All clear," I'll place that text in the title and summary fields to satisfy both requirements.