fix(mobile): suppress haptics during thread sync

[mackinleysmith]

What Changed

Streaming haptics are now enabled only after the selected thread has finished synchronizing. Catch-up publications still advance the streaming-message baseline, so reaching the live state cannot emit a final haptic for replayed message growth.

Why

Long thread synchronization publishes incremental message updates that resemble live streaming updates. Those replayed updates could trigger repeated selection haptics.

The client already tracks an authoritative thread synchronization status, so this uses that state directly instead of introducing timing or timestamp heuristics. Existing haptic behavior resumes unchanged for new live streaming updates.

UI Changes

There are no visual changes.

• Before: synchronizing a long thread could repeatedly trigger haptics.
• After: catch-up remains silent; new live streaming updates retain haptic feedback.
• Video: not included because this is a haptics-only change; iOS screen recordings do not capture tactile output, and there is no visual UI change to demonstrate.

Verification

• vp test run packages/client-runtime/src/state/threads-sync.test.ts — 14 passed
• vp run --filter @t3tools/mobile typecheck
• Targeted formatting, lint, and diff checks
• iOS Simulator forced disconnect/reconnect with a seeded long thread; retry state cleared and the complete thread remained after synchronization

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (not applicable: no visual change)
• I included a video for animation/interaction changes (not applicable: haptic output is not visible or captured by iOS screen recording)

Prepared with GPT-5.6-sol using the Codex harness in T3 Code.

Note

Suppress haptic feedback in useStreamingHaptics during thread sync

• Adds an enabled parameter to useStreamingHaptics; when false, haptics are suppressed and the baseline is advanced to the latest streaming message to avoid a spurious haptic when sync completes.
• ThreadDetailScreen passes enabled as threadSyncStatus === "live", so haptics only fire when the thread is fully live.

^{Macroscope summarized 6883284.}

---

Note

Low Risk
Haptics-only behavior gated on existing thread sync status; no auth, data, or visual UI changes.

Overview
Streaming selection haptics in ThreadDetailScreen now run only when the selected thread’s sync status is live, so catch-up message updates during long thread synchronization no longer feel like live streaming.

useStreamingHaptics accepts an enabled flag. While sync is not live, haptics are skipped but the internal streaming-message baseline still advances with each feed update, preventing a one-off haptic when the thread transitions to live after replayed assistant text growth.

The prop comment for threadSyncStatus is updated to note it also drives live streaming feedback, not only status UI.

^{Reviewed by Cursor Bugbot for commit 6883284. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 603b06a5-e947-43c6-9a94-bfffd5c5b08a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 6883284. Configure here.}

[cursor]

Sync suppresses post-reconnect haptics

Low Severity

When useStreamingHaptics runs with enabled false during thread sync, it advances the streaming baseline but leaves lastStreamHapticAtRef unchanged. After a quick reconnect, the same assistant stream can grow while threadSyncStatus is live again, yet the existing 320ms throttle still compares against a haptic fired just before sync and skips feedback for that growth.

 

^{Reviewed by Cursor Bugbot for commit 6883284. Configure here.}

[mackinleysmith]

Thanks — this is intentional throttle continuity. A same-stream text update inside 320 ms would be throttled even without synchronization; resetting the timestamp during sync would allow two haptics closer together than the existing cadence permits. A longer sync naturally ages out the throttle, and a genuinely new assistant stream already bypasses it via isNewStream, so I am keeping the timestamp unchanged.

[macroscopeapp]

Approvability

Verdict: Approved 6883284

Small, self-contained fix that suppresses haptic feedback during thread sync catch-up. The change only affects cosmetic UX (haptics) with no business logic impact. The unresolved low-severity comment about a minor timing edge case doesn't affect correctness.

^{You can customize Macroscope's approvability policy. Learn more.}