fix(mobile): show Working and Monitoring when background work outlives the turn

[cristip73]

What Changed

Mobile now reads thread.backgroundLiveness, the field the server already puts on the thread shell and the web sidebar already uses:

• resolveThreadListV2Status maps "working" to Working and "monitoring" to Monitoring. Approval, input, a running/starting session, and error still take priority, as they do in resolveThreadStatusPill on web.
• The open thread's floating status pill gets a background variant: Working with the activity indicator, or Monitoring with no spinner (calm, like the web pill). It only shows when there is no active turn to time.

No contract, server, or schema change. 6 files, +92/-6, about half of it tests.

This is the fix suggested in the triage on #10372, ported from #10436 by @Gigioxx (credited as co-author). #10436 no longer applies after #13183 retired the legacy list and threadPresentation.ts, so this version touches only the v2 list and the open-thread pill.

Fixes #10372
Fixes #4962

Why

The parent turn settles as soon as the agent fans work out to background subagents, so mobile showed the thread as idle while the subagents were still running for minutes. The desktop sidebar shows Working for exactly this case since #5219. From the phone, the thread read as finished or dead when the correct answer was "working" (see the reports on #4962 and #10372, on iOS and on two Android devices).

UI Changes

iOS Simulator (iPhone 17 Pro Max), the repo's own showcase fixture (scripts/mobile-showcase.ts). Both threads have a completed parent turn and a ready session. For the capture only, the server was patched locally to report backgroundLiveness for them (working for "Make remote coding feel local", monitoring for "Make boot logs oddly beautiful"). That patch is not part of this PR. Same fixture and same server patch for both columns; only the mobile code differs.

Thread list: on main the rows show only a timestamp, so the thread reads as finished.

Open thread: "Worked for 2m" says the turn ended; after the fix the floating pill still shows Working while subagents run.

Verification

• threadListV2.test.ts: new cases for settled turn + working / monitoring / null, and for approval, input, running, starting, and error keeping priority over both liveness values. The first case fails on main and passes with the fix (89/89).
• tsc --noEmit in apps/mobile: clean.
• vp fmt --check: clean. vp lint: no new warnings in the touched files (28 before, the same 28 after).

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes (not applicable: static label, no new motion)

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features
  • Threads can now show a “Monitoring” status when background activity continues after the main turn finishes.
  • Floating status labels distinguish “Monitoring” from “Working”; an activity indicator appears only while work is actively underway.
  • Approval requests, user input, active sessions, and errors continue to take precedence over background status.

[macroscopeapp]

Approvability

Verdict: Approved at 3d3d072

Macroscope's review found this PR approvable — This is a small, self-contained mobile UI bug fix that surfaces an existing background-liveness state in the thread list and open-thread status pill. It preserves existing status precedence, adds focused coverage, and introduces no schema, server, default, or production-workflow changes.

Notes:

• Diff unchanged. Approvability was decided on eligibility alone.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository: pingdotgg/t3code/.coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: ae216257-7010-4f12-bf57-5ecca6cee63f

📥 Commits

Reviewing files that changed from the base of the PR and between 2679d27 and 3d3d072.

📒 Files selected for processing (6)

• apps/mobile/src/features/threads/ThreadDetailScreen.tsx
• apps/mobile/src/features/threads/floating-working-control.tsx
• apps/mobile/src/features/threads/floating-working-status.ts
• apps/mobile/src/features/threads/thread-list-v2-items.tsx
• apps/mobile/src/features/threads/threadListV2.test.ts
• apps/mobile/src/features/threads/threadListV2.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

---

📝 Walkthrough

Walkthrough

Mobile thread-list and open-thread status handling now includes background liveness. The list resolves and labels monitoring after higher-priority statuses. The open-thread floating status displays Monitoring or Working, with an activity indicator for Working.

Changes

Background status presentation

Layer / File(s)	Summary
Thread-list status resolution and label apps/mobile/src/features/threads/threadListV2.ts, apps/mobile/src/features/threads/threadListV2.test.ts, apps/mobile/src/features/threads/thread-list-v2-items.tsx	The status resolver returns background liveness after approval, input, session, and error checks. Tests cover those precedence rules and the ready fallback. The list displays a Monitoring label.
Open-thread background status apps/mobile/src/features/threads/floating-working-status.ts, apps/mobile/src/features/threads/ThreadDetailScreen.tsx, apps/mobile/src/features/threads/floating-working-control.tsx	The screen adds a background status when content is ready. The floating label displays Monitoring or Working, and shows an activity indicator only for Working.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix · Severity of issue fixed: Medium

Suggested reviewers: juliusmarminge

Merge Risk: ⚪ Minimal · up to 3d3d0

The mobile thread list and open thread now distinguish Working from Monitoring. No actionable merge-blocking risk is established; merge after normal checks.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 4 functions across 6 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the mobile fix and the two background-work states shown after the parent turn ends.
Description check	✅ Passed	The description covers what changed, why it changed, UI effects, verification results, screenshots, issue references, and checklist items. It is focused and complete.
Linked Issues check	✅ Passed	The changes satisfy both direct coding objectives. For [#10372], resolveThreadListV2Status returns monitoring, the row label map renders “Monitoring”, and ThreadDetailScreen renders a visible Mo…
Out of Scope Changes check	✅ Passed	The changed production files implement mobile list and open-thread presentation for the two linked status objectives. The status type update, label rendering, remount key, and resolver tests directly …

• Fix all pre-merge checks with AI

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

---

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

[kvnloo]

This is the right projection boundary: mobile consumes the existing canonical backgroundLiveness instead of inventing a second task-liveness model. The precedence matrix is the important part — approvals/input/active session/error stay authoritative, then settled-parent background work can project Working / Monitoring. That should also keep iOS and Android behavior aligned because the state owner is shared.

Dismissing prior approval to re-evaluate 3d3d072

[juliusmarminge]

Thanks for working on this. We merged the orchestrator V2 rewrite in #2829, and we are closing this PR as part of that transition.

This PR adds mobile backgroundLiveness handling for the old thread shell. V2 replaced that shell and background-work presentation. Verify the current mobile behavior before refiling.

Sorry for the extra work this creates. If the change is still needed on V2, please rebuild it on current main, verify it there, and open a new PR linking back here. We're closing the current implementation without assuming the underlying request is resolved.