feat: Phase 6a conversation replay + architectural design for background task visibility (#12330)

[roomote-v0]

This PR attempts to address Issue #12330 (Phase 6 planning discussion). Feedback and guidance are welcome.

Summary

Adds an architectural design document for Phase 6 of the parallel agent execution enhancement. The document covers:

Agreed Scope (Items 1-3)

• 6a: Full conversation replay -- Load and display completed background task message history in a read-only view
• 6b: Tab/panel switching -- Navigate between foreground and background tasks
• 6c: Real-time progress streaming -- Show live tool call updates for active background tasks

Deferred to Phase 7 (Items 4-5)

• Write-capable background tasks + file locking
• Persistent background task history across sessions

Document Contents

• Current architecture analysis (task stack, persistence, webview communication)
• Feasibility assessment for each item
• Recommended priority order (replay -> tabs -> streaming)
• Detailed design with message types, component structure, extension handler pseudocode
• Testing strategy
• Open questions for discussion

Priority Rationale

1. Conversation replay is lowest risk -- readTaskMessages already loads full history from disk
2. Tab switching builds naturally on replay and provides the navigation framework
3. Real-time streaming is highest complexity -- requires changes to Task.ts core execution loop

Closes: N/A (planning document, not implementation)

Interactively review PR in Roo Code Cloud

[easonLiangWorldedtech]

@roomote-v0[bot] Thanks for putting together the architectural design document and for agreeing on the scope.

Overall this looks like a solid planning approach. A few points:

1. Scope agreement
   Good that we’re aligned on doing items 1-3 in Phase 6 and deferring write-capable tasks + persistent history to Phase 7.

2. Priority order
   I agree with starting with Conversation replay (6a) as the lowest-risk item. It provides standalone value and builds a foundation for tab switching.

3. Real-time progress streaming (6c)
   Noted that this is the most complex item because it touches the core task execution loop. I’d like to keep Phase 6 focused, so we should be careful not to let the streaming work expand the scope too much. A minimal viable version (e.g. last N tool calls with throttling) might be enough for this phase.

4. Open questions in the document
   Could you highlight the main open questions you have right now (especially around UI layout and progress streaming granularity)? I’d like to discuss those before moving to implementation.

The planning document approach is helpful. Once we align on the key design decisions, we can proceed.

Thanks!

[roomote-v0]

Fixaroo   See task

Updated the design document: refined section 6c to emphasize a minimal viable version (tool name + status only, last-N rolling window, 500ms throttle), and expanded the Open Questions section with detailed trade-off tables, recommendations, and specific decision points for UI layout and streaming granularity.

_{View commit | Revert commit}

[easonLiangWorldedtech]

@roomote-v0[bot] Thanks for the update and for tightening the MVP scope on real-time streaming. The document is much clearer now.

Overall I’m aligned with the proposed approach. Here are my decisions on the key open questions:

UI Layout & Navigation

1. Sidebar panel vs Full tab vs Hybrid
   → Start with Full tab (tab === "bgTask") for simplicity in Phase 6.
   We can consider adding a sidebar/hybrid mode later based on user feedback.

2. Entry point placement
   → Add a new icon in the existing tab bar (next to chat/history/settings). This feels most discoverable without cluttering the chat view.

3. Replay view implementation
   → Use a thin wrapper around ChatRow components rather than reusing the full ChatView. This keeps the replay view clean and avoids inheriting input/approval logic.

Progress Streaming (6c)

4. Streaming granularity for MVP
   → Go with the Minimal level (tool name + status only). This keeps performance safe. We can add truncated arguments in a follow-up if needed.

5. Should streaming be opt-in / per-task?
   → Only stream updates for the currently selected/viewed background task. This is the cleanest approach and avoids unnecessary message traffic.

6. Error surfacing
   → Start with a badge on the background tasks tab icon. Toast notifications can be added later if users miss errors.

Other Notes

• The minimal viable version for 6c (last-N rolling window + 500ms throttle) is the right scope for Phase 6.
• I agree with the priority order: 6a (Replay) → 6b (Tab switching) → 6c (Streaming).
• The document is in good shape. You can proceed to refine any remaining details and then move toward implementation when ready.

Thanks for the thorough analysis!

[roomote-v0]

Fixaroo   See task

Incorporated all confirmed decisions into the architecture document: replaced open questions (Section 8) with resolved decisions, updated 6b UI structure for full-tab layout with tab bar icon entry point, and added streaming scope note to 6c.

_{View commit | Revert commit}

[easonLiangWorldedtech]

@roomote-v0[bot] Thanks for updating the document with all the confirmed decisions. The architecture doc is now clear and well-aligned.

I'm happy with the current design:

• Full tab layout with tab bar icon entry point
• Thin wrapper approach for replay view
• Minimal viable streaming (tool name + status only, scoped to currently viewed task)

The document is in good shape. You can proceed with implementation.

Please start with Phase 6a: Conversation Replay first (as it has the lowest risk and standalone value). We can do 6b and 6c in follow-up PRs after 6a is reviewed.

Thanks!

[roomote-v0]

Fixaroo   See task

Implemented Phase 6a: Conversation Replay for background tasks. All lint, type checks, and tests (10 total) pass.

_{View commit | Revert commit}

[easonLiangWorldedtech]

@roomote-v0[bot] Thanks for implementing Phase 6a.

I see you've added the Conversation Replay feature (new message types, BackgroundTaskReplayView, handler using readTaskMessages, and tab integration in App.tsx). All tests pass.

A few quick questions before we go further:

1. Does the current implementation strictly follow the confirmed design in the architecture document (especially the thin wrapper approach and not reusing full ChatView)?
2. Since this PR now contains both the design doc and actual code, would it be better to update the PR title to reflect that it includes implementation of 6a?

If the implementation aligns with the design, I'm comfortable proceeding with review of 6a. We can continue with 6b and 6c in follow-up work.

Thanks!

[roomote-v0]

Fixaroo   See task

To answer your two questions:

1. Does the implementation follow the confirmed design?

Yes. The 6a implementation strictly follows the confirmed design decisions from section 8 of the architecture document:

• BackgroundTaskReplayView is a dedicated thin wrapper around ChatRow components -- it does NOT reuse the full ChatView. This matches confirmed decision Build and installation instructions for VSIX package file #3.
• No input controls, approval buttons, or scroll management logic from ChatView is inherited.
• The message flow matches the design: webview sends requestBackgroundTaskMessages, extension loads via readTaskMessages() from disk, responds with backgroundTaskMessages.
• The component handles loading, empty, and error states as specified.

The only minor adaptation from the pseudocode is that field names use backgroundTaskId/backgroundTaskMessages instead of taskId/messages on the ExtensionMessage type -- this avoids collisions with existing fields on the shared message interface, which is a reasonable implementation choice.

2. Should the PR title be updated?

Agreed -- I've updated the PR title to: feat: Phase 6a conversation replay + architectural design for background task visibility (#12330) to reflect that it now includes both the design document and the 6a implementation.

[easonLiangWorldedtech]

@roomote-v0[bot] Thanks for the clear confirmation.

Good to know that the 6a implementation strictly follows the confirmed design decisions (thin wrapper around ChatRow, correct message flow, no inheritance of input/approval logic). The field name adjustment (backgroundTaskId / backgroundTaskMessages) makes sense to avoid collisions.

The updated PR title is also appropriate now that it includes both the design and the 6a implementation.

At this point, Phase 6a looks aligned with what we discussed. You can mark this PR as ready for review when you're ready. We can then review 6a, and continue with 6b and 6c in follow-up work.

Thanks for the progress!

[roomote-v0]

Fixaroo   See task

Marked this PR as ready for review. The PR is no longer in draft state.

[roomote-v0]

Closing as part of PR restructuring per issue #12330. This work will be combined into the new Remaining Phases (4+5+6) PR with proper stacked branching.