feat(workflow)!: implement inline mode with visual indicators and interrupt recovery

[lavaman131]

Summary

This PR implements a comprehensive workflow inline mode experience that provides clear visual feedback, improved interrupt handling, and context preservation throughout workflow execution. Users can now interrupt and redirect workflows mid-execution without losing orchestration state.

Key Changes

🎨 Visual Indicators

• Teal border on chat input when workflow is active (uses themeColors.accent)
• Workflow mode label displaying workflow type (e.g., "plan") with keyboard hints
• Clear visual distinction between normal mode and workflow mode

⌨️ Improved Interrupt Handling

• Single Ctrl+C: Interrupts current stream while keeping workflow active
• Double Ctrl+C: Cancels workflow entirely
• User input recovery: After stream interruption, workflow waits for user input and resumes with full context
• ESC key: Only interrupts stream, doesn't cancel workflow

💾 Context Preservation

• Removed clearContext() calls from Ralph workflow (src/ui/commands/workflow-commands.ts:684,734)
• Conversation history persists throughout entire workflow execution
• Task list panel stays visible during workflow, auto-hides only on natural completion

🐛 Bug Fixes

• Normalize markdown newlines for correct terminal rendering
• Clean sub-agent output and hide intermediate stream content
• Scope Ralph session state reset to Copilot agent type
• Add error handling to reset workflowActive on workflow failures

Breaking Changes

⚠️ Ctrl+C behavior during workflows has changed:

• Single Ctrl+C press no longer cancels the workflow
• Users must press Ctrl+C twice to exit an active workflow
• First press interrupts the stream and allows user input within workflow context

Testing

• ✅ Unit tests: Border color logic, Ctrl+C handler priority chain, state transitions
• ✅ Integration tests: Workflow inline mode, interrupt recovery, user input passthrough
• ✅ E2E tests: Visual verification, stream interruption, task list lifecycle

Related Documentation

• Spec: specs/workflow-sdk-inline-mode.md
• Research: research/docs/2026-02-21-workflow-sdk-inline-mode-research.md

[claude]

PR Review: Workflow SDK Inline Mode Implementation

This PR implements a significant enhancement to the workflow system, adding visual mode indicators (teal border), double Ctrl+C workflow exit, user prompt passthrough after interruption, and removal of clearContext() calls. Here's my detailed review:

---

✅ Code Quality & Best Practices

Strengths:

• Well-documented with comprehensive research doc and spec (research/docs/2026-02-21-workflow-sdk-inline-mode-research.md and specs/workflow-sdk-inline-mode.md)
• Good separation of concerns with the streamWithInterruptRecovery helper function in workflow-commands.ts
• Proper TypeScript typing throughout (e.g., StreamAndWaitResult, wasCancelled property)
• Comprehensive test coverage with unit tests, integration tests, and E2E tests

Suggestions:

1. Unused parameter prefix: In workflow-commands.ts:576, the onInterrupted callback receives userPrompt but some call sites don't use the returned options:

   const result = await streamWithInterruptRecovery(
       context,
       prompt,
   );

   This is fine, but consider documenting that onInterrupted defaults to passing through the user prompt directly.

2. Magic string: The error message "Workflow cancelled" is used as a control flow signal in chat.tsx:2063 and caught in workflow-commands.ts:1998. Consider extracting this to a constant:

   export const WORKFLOW_CANCELLED_ERROR = "Workflow cancelled";

---

⚠️ Potential Bugs or Issues

1. Race condition in waitForUserInput (chat.tsx:3754-3758):
   The waitForUserInputResolverRef is set but there's no timeout or cleanup if the user never submits. If the workflow is cancelled while waiting, the promise might stay pending. While the catch block handles "Workflow cancelled" errors, consider adding a cleanup in the workflow cancellation path.

2. Missing null check (chat.tsx:4345):

   if (hideStreamContentRef.current && interruptedId) {

   The interruptedId might be undefined if isStreamingRef.current was false when Ctrl+C was pressed. This is guarded by the outer streaming check, but adding defensive coding would be safer.

3. Duplicate logic (chat.tsx:4440-4449 and chat.tsx:4329-4341):
   The workflow termination logic on double Ctrl+C is duplicated in two places (streaming and non-streaming paths). Consider extracting to a helper function:

   function terminateWorkflow() {
     updateWorkflowState({ workflowActive: false, workflowType: null, initialPrompt: null });
     if (waitForUserInputResolverRef.current) {
       waitForUserInputResolverRef.current.reject(new Error("Workflow cancelled"));
       waitForUserInputResolverRef.current = null;
     }
   }

4. State cleanup on ESC (chat.tsx:4600-4618):
   The ESC handler also resolves streamCompletionResolverRef but does NOT call waitForUserInputResolverRef.reject(). If a user presses ESC during waitForUserInput, the workflow might hang. Consider aligning ESC behavior with Ctrl+C for consistency.

---

🚀 Performance Considerations

1. useEffect dependency (chat.tsx:2697-2703):

   useEffect(() => {
     if (!workflowState.workflowActive && ralphSessionDir) {
       setRalphSessionDir(null);
       setRalphSessionId(null);
     }
   }, [workflowState.workflowActive, ralphSessionDir]);

   This effect runs whenever ralphSessionDir changes. If workflowActive is false and ralphSessionDir is set, it will immediately clear it. This is intentional but could cause unnecessary re-renders. Consider using a ref to track the previous workflowActive state to only trigger on transitions.

2. Markdown normalization (format.ts:2542-2556):
   The normalizeMarkdownNewlines function uses regex replacement which is called on every render of text/reasoning parts. For large content, this could be expensive. Consider memoizing the normalized content at the component level.

---

🔒 Security Concerns

No significant security concerns identified. The changes are primarily UI/UX focused and don't introduce new attack surfaces.

---

🧪 Test Coverage

Excellent coverage with:

• Unit tests for waitForUserInput context method
• Integration tests for the full workflow lifecycle (workflow-commands.test.ts)
• E2E tests for teal border state, Ctrl+C interruption, and task list persistence (workflow-inline-mode-e2e.test.ts)

One test removal noted (workflow-commands.test.ts:283-285):

-    // Verify context was cleared before review
-    expect(clearCallCount).toBeGreaterThanOrEqual(1);

This is intentional as clearContext() calls were removed, but ensure this behavioral change is documented in the PR description.

---

📝 Minor Style/Consistency Issues

1. Inconsistent agent type check (chat.tsx:3807-3815 and chat.tsx:5405-5413):
   The Ralph state reset on /clear only applies to agentType === "copilot". This is mentioned in the spec but consider adding a comment explaining why this is Copilot-only.

2. Try-catch nesting (workflow-commands.ts:851):
   The closing brace for the try block is not aligned with its opening, making the code harder to read. The catch at line 1997 seems to be catching errors from a large try block starting around line 623. Consider refactoring for clarity.

---

📋 Summary

Aspect	Rating
Code Quality	⭐⭐⭐⭐
Test Coverage	⭐⭐⭐⭐⭐
Documentation	⭐⭐⭐⭐⭐
Performance	⭐⭐⭐
Security	⭐⭐⭐⭐⭐

Overall: This is a well-structured PR with good documentation and test coverage. The main concerns are around potential edge cases with the waitForUserInput promise lifecycle and some duplicated code that could be refactored. The removal of clearContext() calls is a significant behavioral change that should be validated in manual testing to ensure the reviewer sub-agent still functions correctly with the full conversation context.

Recommendation: Approve with minor suggestions. Consider addressing the waitForUserInput cleanup and duplicated workflow termination logic before merging.