[t3dotgg]

What Changed

Background-task work-log rows are now titled with the task's actual name instead of generic labels. task.progress activities use the task description ("Typecheck mobile app") as their summary and payload.title instead of "Reasoning update", and task.completed activities get a payload.title too, via a small per-(threadId, taskId) description cache in ingestion — terminal task notifications don't carry the name themselves. task.completed also now emits payload.summary alongside payload.detail, mirroring task.progress, so clients render "name - completion summary".

Why

Providers stream named background work units (subagents, background shells, workflows), but the work log flattened them into anonymous "Reasoning update" / "Task completed" rows, making it impossible to tell what's actually running. The fix is confined to the provider-agnostic ingestion layer in apps/server — clients already prefer payload.title/summary/detail when labeling rows, so web and mobile pick the names up with zero client changes and no provider-specific logic anywhere new.

Edge cases covered: descriptions that trim empty fall back to the old labels; the cache is bounded (capacity + TTL), swept with the other per-thread caches on session exit, and lookups don't consume entries so replayed terminal events stay titled.

Tested via two new ingestion tests (named progress/completion, and completion titled from task.started alone); server orchestration suite passes 153/153, plus web session-logic and mobile threadActivity suites. Reviewed by two independent agent reviews; all findings addressed.

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

🤖 Generated with Claude Code

---

Note

Low Risk
Localized projection/activity shaping in ingestion with fallbacks and tests; no auth, API contract breaks, or client changes required.

Overview
Background-task work-log rows now show the provider’s task description instead of generic labels like “Reasoning update” or unnamed “Task completed”.

In ProviderRuntimeIngestion, descriptions from task.started / task.progress are stored in a bounded per-(threadId, taskId) cache. task.progress uses the trimmed description for the activity summary and payload.title when present (otherwise the old “Reasoning update” label). task.completed gets payload.title from that cache, with a fallback that scans already-persisted task.started / task.progress activities when the cache was cleared (e.g. session.exited). Completion activities also set payload.summary and payload.detail from the terminal summary, matching task.progress so clients can show “name — completion text” without app changes.

Cache keys for the thread are invalidated alongside other per-session ingestion state on session exit; new ingestion tests cover named progress/completion, start-only naming, and post-sweep recovery.

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

Note

Title background-task work-log rows with the task name in ProviderRuntimeIngestion

• task.progress activities now use the task description as their summary and include a payload.title field; task.completed activities include a payload.title sourced from previously seen descriptions, plus payload.summary and payload.detail when a completion summary is available.
• Task descriptions are cached in-memory (keyed by threadId+taskId) when task.started or task.progress events are ingested, and the cached title is passed into runtimeEventToActivities at completion time.
• When the in-memory cache has been swept by a session.exited event, the title is recovered by scanning persisted OrchestrationThreadActivity entries in reverse order via the new findTaskTitleInActivities helper.
• clearTurnStateForSession now also invalidates task description cache entries for the thread alongside other per-thread caches.

^{Macroscope summarized 6485746.}