feat(web): show Claude workflow phases and members in Lineage

[Bil0000]

Problem

Claude workflows appeared as one opaque subagent in Lineage. Their phases, members and answers were missing, and the app could not stop an entire workflow.

Scope and approval

This continues the existing Claude workflow Lineage feature under maintainer-directed takeover. Scope is phase/member visibility, member answers and the lifecycle handling needed to keep those rows correct.

Julius's scope and implementation review says the feature is worth having and specifies the requested server and UI direction. His follow-up review records the remaining performance and recovery requirements. This is a feature, not a small-fix exemption; final human re-review and approval are still pending.

Change

• Expand workflows into phase sections with member rows, status, counts and elapsed time. Each member opens its chat with the original prompt, final answer and workflow breadcrumb. Queued members remain pending, their timers begin when they start running, and late answers preserve their finish times. Member navigation waits for the chat to exist in the destination environment.
• Read final answers from the transcript tail so long transcripts retain their ending.
• Add workflow Stop in the UI and MCP, guarded by orchestration:operate and the caller's dispatch mode limit. Individual native Stop requires an owning run, so projected workflow members do not expose a control that cannot dispatch. Workflow timers remain visible when the viewer cannot stop the workflow.
• Settle members and their child threads when the coordinator stops or fails, the parent run ends unsuccessfully, the Claude process exits between turns, or the server restarts. Activate continuations only after acquiring the replay lock, serialize replay with live SDK messages during transcript reads, keep pending completions visible to process-exit cleanup, apply outcomes only to the current lifecycle, discard stale transcript projections after settlement, and use the same cleanup if closing the CLI times out. Provider stop requests are bounded at 15 seconds.
• Persist roster updates only for explicit snapshots and terminal notifications. Refresh child-thread metadata idempotently while preserving existing thread state. Publish Codex approval items before their pending requests. The child-thread ingestion change exposed a race where an immediate response arrived before the item existed, leaving it waiting. The existing single-child and nested-child replay assertions require the item to be completed after approval; both fail when the order is reverted.

Verification

• Replay ordering and cleanup: all 212 Claude adapter tests pass. Two new cases fail on the prior head and pass after continuation activation moves inside the replay lock: a live result cannot create an extra continuation, and a query that closes while activation waits cannot accept that continuation. Two independent async-stream diagnostics also pass. Earlier replay and interruption cases remain covered in the same test file; pending completions remain visible to cleanup. Tests use queued-frame and Deferred milestones. Server typecheck and targeted lint/formatting pass.
• Fallback Stop now settles workflow members that have no subagent turn item, including their execution nodes and child roots. One regression in the existing BackgroundWorkStop suite failed before the fix; all 20 related Stop/projection tests now pass. Server typecheck and targeted lint/formatting pass.
• Main integration passed 185 tests across eight focused suites covering native task cancellation, background Stop, persistence, projection selection, recovery, restart continuation, run routing and subagent projection. Server and provider-core typechecks and targeted lint/formatting pass. Main's shared cleanup now handles workflow members; the retained workflow recovery tests pass and the duplicate implementation is removed. The subsequent project-scoped thread-query integration passed all 64 ProjectionStore and ThreadManagementService tests, server typecheck and targeted lint/formatting.
• The preceding UI correction passed all 18 Lineage component tests, web typecheck, and targeted lint/formatting. One new case in the existing Stop table reproduced the ineffective individual Stop on a runless workflow member, then passed with the ownership guard. Two temporary rendered checks verify timer visibility with Stop permission granted and denied. Existing ordinary native/app-owned Stop and workflow-wide Stop cases still pass.
• Current head 3c34fcc integrates main through 61eb4af, preserving its Claude MCP registration changes. All 256 tests across the Claude adapter, RPC authorization and Lineage component suites pass, along with server/web typechecks and targeted lint/formatting. All eight required checks pass on this head, including lint, typecheck, build and tests.
• Member navigation uses the existing destination-environment thread graph. The extended seven-member case stays disabled when matching IDs exist only in another environment and opens every phased/unphased member after the correct shells arrive. The negative control fails on the preceding published head; all 18 Lineage tests pass.
• Integrated browser verification at 350f895 covered phase expansion, counts, member answers, breadcrumbs and cancelled members. The recordings use isolated sample data. A further preview check at 5ad877e confirmed phase expansion and member-chat navigation after integrating main. Earlier live-Claude evidence is retained below. No new browser or live-provider verification is claimed for the latest integrations. A fresh preview attempt reached the target thread but timed out during the server restart before navigation could be verified.
• Independent Opus 5.5 and Sol 6.1 reviews completed the full 56-file feature diff at 3c34fcc with no remaining findings. Opus ran 596 focused tests and nine external semaphore diagnostics. Sol ran 37 focused checks, including adapter cancellation and queued/async-stream burst controls. Both verified the member-navigation correction and prior replay/Stop fixes. All 53 inline review threads are resolved. Final human re-review remains required; Macroscope did not run correctness review because of its per-PR cost cap. Native mobile and a live root-turn API failure were not exercised in the browser.

Short feature demos

Recorded with T3 Code's server-owned preview browser at 350f895, using sample workflow data in an isolated development environment. These clips demonstrate the UI; the stopped clip shows the resulting state rather than a live Stop request.

Workflow phases and members, 5 seconds

https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/2c125e7574b76926/01-phases.mp4

Open a member's chat and read its answer, 10 seconds

https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/73cb1fb198ab0cd2/02-member-answers.mp4

Inspect stopped members and open their chat, 10 seconds

https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/c7f3bc208ae946ed/03-stopped-members.mp4

Screenshots (dark mode, live Claude workflows)

Before (this PR before the takeover), and after with the same data:

Collapsed: workflows sit in Lineage like any other subagent, with a split chevron to expand them.

Running: the active phase is emphasized and open, finished phases fold, and Stop appears on hover.

Stopped workflow and member hover card:

Member thread: the breadcrumb and badge name the workflow.

Recording (87s): two live workflows running and finishing, phase toggles and the member hover card.
https://uploads-production-47e4.up.railway.app/files/9f1fc624-2701-41c3-89ea-6f9cb2d17311/workflow-sections-dark.mp4

Built by Claude Opus 5 and 5.5 in Claude Code, with GPT-6.1-Sol updates and review in Codex. Takeover passes used Claude Opus 5.5 for tests and Claude Fable 5.1 for implementation; integration used GPT-6.1-Sol in Codex.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This is a substantial cross-layer feature that adds workflow member projection, transcript reads, lifecycle/recovery handling, and destructive stop controls across server, provider, RPC/MCP, and Lineage UI code. It also introduces static-analysis diagnostic suppressions in new server modules, so human review is required.

Not approved because:

• Per-PR cost limit exceeded (workspace setting). Approvability relies on correctness review in order to determine eligibility

^{Review your spending limits in Billing settings, or comment @macroscope-app review this PR to bypass the limit and review now. You can add or adjust custom eligibility rules. Learn more.}

[juliusmarminge]

Reviewed at 9aee040. The feature is worth having and the server-side design (members as ordinary subagents, additive merge, between-turn refresh) is the right shape. Two correctness problems block, and the UI needs another pass before this ships.

Blocking: correctness

1. Members never settle when the coordinator stops or fails.

Member status is derived only from member.state in the last snapshot (ClaudeAdapterV2.ts:3385). You cite the CLI emitter guard (status !== "running" → return) to argue no stale frame can arrive after the notification; I confirmed the guard is there in 2.1.236. The flip side is that when the run is interrupted, killed, or the script throws while members are start, the last snapshot is the one that says they are running, the task_notification arrives as stopped/failed, and neither updateClaudeSubagentNode nor applyWorkflowProgressWithoutTurn walks workflow.agents to close them. workflowMemberStates is never touched on coordinator terminal. Members also carry runId: null, so the run's interrupt cascade in RunExecutionService does not know about them either.

Result: press Stop on a running workflow and the coordinator row goes cancelled while every in-flight member row spins forever, and each member child thread keeps a root_turn node stuck running.

Fix: in the task_notification branch, when the coordinator goes terminal, map every member still running/queued to cancelled (stopped) or failed, emit the same node/subagent updates, and record them in workflowMemberStates. Test: existing wake harness, snapshot with a member in start, then task_notification with status: "stopped"; assert the member's last subagent.updated is terminal.

2. Truncated transcripts are the common case, not the edge case, and the fallback presents the excerpt as the final answer.

TRANSCRIPT_BYTE_CAP is 512 KiB and a truncated read returns [], so the capped resultPreview is emitted as the member's answer. On my machine 22 of 111 real workflow-member transcripts exceed 512 KiB, so roughly one in five members would get a few-hundred-character preview rendered as a complete assistant message in a thread that otherwise looks whole. The read is already positional; when stat.size > byteCap, read the tail 512 KiB instead of the head and drop the first partial line (the parser already tolerates a cut line). That recovers the final answer, which is the thing the user opened the thread for.

Blocking: UI

I looked at the three screenshots closely. It does not read as a finished T3 surface yet. Concrete things:

Lineage card

• Phase headers (LIST 2/2, RANK 1/1) are uppercase mono in green while the member rows below them are proportional sentence case. Three type treatments inside one small tree. The panel's existing rows use one.
• The coordinator row shows ●●● plus 24s. Three green dots with no legend means nothing to a user; the Agents tab already solves this with 4 done. Pick one vocabulary.
• The collapsed rows (queue-choice, index-strategy) also show ●●● and a duration but give no indication they are workflows rather than plain subagents until you expand them. The Lineage list already had a way to show a subagent; this adds a second, different-looking row type next to it.
• Member rows use a filled green dot as their icon while the coordinator uses the provider glyph and phases use a check. Three icon systems in a 4-level tree.

Agents tab

• The phase rail (✓ Collect ●●●● › ✓ Check ●●●● › ✓ Wrapup ●) repeats the same information as the phase group headers directly below it (✓ COLLECT 4 done). One of the two should go; the group headers already scroll with the content and carry the count.
• Every member row is three lines: title, Completed, then sonnet-5 · 96.6k tok · 0 tools, with a check and duration on the right. Completed and the check say the same thing, and a nine-member run becomes ~30 lines of near-identical text. One line per member (title left, model/tokens/duration right, status carried by the row icon) would show the whole run without scrolling.
• Mixed mono and proportional again: titles proportional, metadata mono, phase labels mono uppercase, 9/9 settled mono. The rest of the app does not do this.
• Collapsed workflow rows at the bottom (cache-review, retry-policy) look like a different component from the expanded card above them: no card, different padding, right chevron instead of a header disclosure.

Member thread

• Breadcrumb says server / list:refresh while the badge says Subagent of · Review session auth. The user's own workflow label is list:refresh; the badge should name the workflow (or the coordinator) so the two agree. Right now the thread tells you which project it is in but not which workflow it belongs to.
• The Lineage back-link at the bottom right says Review session auth with no indication it is a workflow, so you cannot tell you are inside a fan-out at all from this view.

I do not have a specific mockup to hand you. The direction I would take: one row type for a workflow member that matches the existing subagent row, phase grouping done with the panel's existing section-header style rather than a new mono uppercase label, drop the dot-strings in favor of n/m counts, and lose either the rail or the group headers. If it helps, do the UI as a follow-up PR on top of the server change once the two blockers above are fixed; the server piece can stand on its own.

Non-blocking, for the record

• Your rebuttals on the Macroscope threads (symlink intermediate dir, task-id scoping, [] vs undefined frames) are correct; no action.
• applyWorkflowProgressWithoutTurn only reaches the projection while the launching run's event subscription is still open, which holds because the coordinator subagent is non-terminal. Worth one comment line so nobody assumes it works after the run stream closes.

[Bil0000]

UI follow-up complete at df6346235ab473342d1dfea1e725fd0aa5d988d9, on top of the maintainer rebase.

The Lineage workflow group now follows the Agents tab on main: a bordered group, status dots, activity previews, model and usage details, and elapsed time. Member rows open their normal chats. The workflow title and count use separate lines, and the list has more room. The shared row-style finding is fixed and resolved.

Validation: 16 focused UI/client tests passed, including every phase, failed/running members, unphased members, and collapse/reopen. Web type checking, targeted lint, and the web build passed. In the real client, all five sample members opened the correct chat, across all three phases; the parent workflow link also worked. Real before/after and member-chat screenshots are in the PR description. The screenshots use isolated sample data, not a live provider run.

Final CI is green on this SHA, including all three server shards. The earlier unrelated Git diff test failure did not reproduce locally and passes in this run. Macroscope correctness, Effect conventions, and UI consistency checks pass. No unresolved review threads or new actionable findings remain.

The PR is CLEAN and MERGEABLE. Julius still needs to re-review: his earlier changes-requested review remains, and Macroscope requires human approval for this feature. The PR remains open.

[juliusmarminge]

Rebased this PR onto the current t3code/codex-turn-mapping at 4a4c22b29c.

What changed on the branch

• The branch carried two merge commits from the base plus a number of base-branch commits that had since landed on v2 in their own form. I dropped all of that and cherry-picked only the 13 workflow-specific commits in their original order (from "capture workflow telemetry" through "retain reported workflow phase titles"). The server, contracts and client-runtime commits all applied cleanly; the expected conflicts in ClaudeAdapterV2.ts, Orchestrator.ts, ProjectionStore.ts, ProviderFailure.ts and TurnStartReads.test.ts did not materialize because v2 already contains the same base commits.
• apps/web/src/components/AgentsPanel.tsx was removed on v2 (refactor(web): remove the agents right panel #12835), so every change to it was dropped. That includes the whole of "keep pending agent tooltips accessible" (4979d689c8), which only touched that file, and the Agents-tab halves of "correct member timing..." and "simplify workflow rows and phase groups". The Lineage-card path (ThreadLineageWorkflowRow.tsx, ThreadRelationshipsControl.tsx) is intact. ThreadRelationshipsControl.tsx needed two small merges: the AgentElapsed import now comes from ./AgentElapsed (where v2 moved it), and the shared relationshipLink uses v2's RelationshipPopup (hover card for subagents) instead of the plain TooltipPopup.
• One commit of my own on top: ThreadLineageWorkflowRow.tsx imported AgentElapsed from ../AgentsPanel; it now imports from ./AgentElapsed.
• 47084b9698 ("load shared checkpoint scopes for queued turns") was left out. v2 already has an equivalent fix in ProjectionStore.ts (the checkpoint scope query now selects by the nodes' checkpointScopeId values), so it is not needed here. If you think there is still a gap, please open it as a separate PR.
• I read the "settle workflow members when the coordinator's turn stops" logic (ee94883211 / c7a850fb28) in the rebased ClaudeAdapterV2.ts; the run-id guard and failed/cancelled mapping are present.

Verified

• vp test run in apps/server for ClaudeAdapterV2.test.ts, claudeWorkflowProgress.test.ts, workflowAgentAnswers.test.ts, workflowScriptQuery.test.ts: 146 passed.
• vp test run src/state/subagentWorkflowProjection.test.ts in packages/client-runtime: 13 passed.
• vp test run for ThreadRelationshipsControl.test.tsx and ThreadRelationshipsControl.agents.test.tsx in apps/web: 6 passed.
• vpr typecheck in packages/contracts, packages/client-runtime, apps/server, apps/web: clean.

Left for you / a maintainer

• The Agents-tab half of this PR no longer has a target; the PR title and description should drop it and describe only the Lineage card.
• No browser pass was done on the Lineage rendering after the rebase.

Rebased and touched up by a maintainer's agent; a human will re-review.

[macroscopeapp]

UI consistency review found one Button height override in ThreadRelationshipsControl.tsx; the inline review comment identifies the shared size or panel variant fix.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

UI consistency review found one styled raw bulk-action button in ThreadLineageWorkflowRow.tsx; the inline review comment identifies the shared Button variant fix. The per-phase semantic disclosure rows are not included in this finding.

^{Posted via Macroscope — UI Consistency}

[maria-rcks]

Note

Written by claude-opus-5-5 on behalf of Maria

Hi! We are cleaning up open PRs, and this one appears to have been created with an older model (opus 5). If this change is really important, we recommend rebuilding the PR with a newer model if possible.

[maria-rcks]

Note

Written by claude-opus-5-5 on behalf of Maria

Reopening, this was closed by mistake. Sorry for the noise!

[maria-rcks]

Note

Written by claude-opus-5-5 on behalf of Maria

Closing again after a second look, sorry for the back and forth. This PR was opened more than two weeks ago. If this change is still important, please rebuild it on current main with a newer model and note the model in the PR description.