[Avtrkrb]

Description

This pull request implements the proposal to move MCP and LSP connection status from verbose startup chat messages to background initialization with a persistent, summarized status display in the UI status component.

Key Changes:

• Background Initialization: MCP and LSP servers now connect silently in the background without cluttering the chat area
• Dynamic Status Display: Real-time connection progress shown as "MCP: X connected, Y errors" and "LSP: X ready, Y errors" in the status component
• Clean User Experience: Users can immediately start typing after the welcome message
• Preserved Functionality: /mcp and /lsp commands continue to work for detailed connection information

Technical Implementation:

• Enhanced useAppInitialization.tsx with Map-based server state tracking for real-time progress updates
• Modified status.tsx to display MCP/LSP connection status with proper formatting for auto-discovery phases
• Updated app.tsx to pass connection status props and enable dynamic re-rendering
• Implemented proper React state management with immutable updates

Type of Change

• Bug fix (LSP status display during auto-discovery)
• New feature (Dynamic MCP/LSP status display)
• Breaking change
• Documentation update

Testing

Automated Tests

• New features include passing tests in .spec.ts/tsx files
• All existing tests pass (pnpm test:all completes successfully - 1693/1694 tests pass, with 1 timeout unrelated to changes)
• Tests cover both success and error scenarios

New Test Coverage (15 tests total):

• source/components/status.spec.tsx - 6 tests for status component MCP/LSP display logic
• source/hooks/useAppInitialization.spec.ts - 4 tests for app initialization status management
• source/hooks/__tests__/connection-status.spec.ts - 5 tests for React state update patterns and React.memo behavior

Test Scenarios Covered:

• MCP connection progress tracking with dynamic server counting
• LSP auto-discovery phase handling (critical fix for totalCount: 0 during discovery)
• State object immutability patterns for React re-renders
• Status formatting logic edge cases and error conditions
• React.memo comparison behavior for optimal rendering

Manual Testing

• Tested with Ollama (MCP servers show dynamic connection progress)
• Tested with OpenRouter (LSP servers display real-time status during discovery)
• Tested with OpenAI-compatible API (Background initialization works correctly)
• Tested MCP integration (Multiple servers connect in parallel with accurate status updates)

Verification Results:

• MCP servers now show progressive connection updates: "MCP: 1 servers connected" → "MCP: 2 servers connected"
• LSP servers properly handle auto-discovery: Shows "LSP: X servers ready..." during discovery phase
• Final status accurately reflects all connected servers and any errors
• No verbose chat messages during initialization - clean UI experience
• Status component updates dynamically as servers connect/disconnect

Implementation Details

Core Files Modified:

1. source/hooks/useAppInitialization.tsx

   • Added Map-based server state tracking for real-time progress
   • Implemented progress callbacks that update state instead of chat queue
   • Enhanced error handling with proper status updates
   • Maintained existing functionality while removing verbose messages

2. source/components/status.tsx

   • Added formatMCPStatus() function for MCP status display
   • Added formatLSPStatus() function with auto-discovery phase handling
   • Fixed critical LSP display logic: if (status.totalCount === 0 && status.connectedCount === 0)
   • Enhanced React.memo with custom comparison function for dynamic props

3. source/app.tsx

   • Moved Status component from staticComponents to dynamic rendering
   • Added connection status props to Status component
   • Enabled real-time UI updates for connection progress

Technical Improvements:

• React Rendering Optimization: Fixed Status component to re-render properly when connection status changes
• State Immutability: Proper immutable state updates to trigger React re-renders
• Error Handling: Comprehensive error scenarios with visual feedback through status component
• Auto-Discovery Support: Special handling for LSP servers discovered dynamically during initialization

Checklist

• Code follows project style guidelines (Prettier formatting applied)
• Self-review completed (comprehensive testing and validation)
• Documentation updated (implementation complete, user docs not needed)
• No breaking changes (existing /mcp and /lsp commands preserved)

Issue Resolution

This pull request closes #120 by implementing the complete specification:

• Background MCP/LSP initialization ✅
• Summarized status display ✅
• Clean UI without verbose startup messages ✅
• Persistent connection visibility ✅

Quality Assurance:

• All new tests pass (15/15)
• Full test suite passes (1693/1694)
• Knip analysis passes (no unused dependencies)
• ESLint and Prettier checks pass
• TypeScript compilation successful

The implementation provides a polished user experience with real-time feedback while maintaining all existing functionality and comprehensive test coverage.

[will-lamerton]

Hey @Avtrkrb - just testing this out. All seems great. One thing I have noticed is that the status UI follows you everywhere. After every command or message it pops in at the bottom below the command output.

To recreate, just type anything and hit ENTER and the status will always reappear at the bottom.

[will-lamerton]

A quick one here, I see why the status UI now appears at the bottom. I think it's because it's no longer static. This component needs to be static for performance.

How it works with other dynamic elements is the data is fetched and then passed to the component so it can remain static after rendering.

[Avtrkrb]

Hey @Avtrkrb - just testing this out. All seems great. One thing I have noticed is that the status UI follows you everywhere. After every command or message it pops in at the bottom below the command output.

To recreate, just type anything and hit ENTER and the status will always reappear at the bottom.

That might be the dynamic re-rendering. Will take a look at it.

[will-lamerton]

Hey @Avtrkrb - just testing this out. All seems great. One thing I have noticed is that the status UI follows you everywhere. After every command or message it pops in at the bottom below the command output.
To recreate, just type anything and hit ENTER and the status will always reappear at the bottom.

That might be the dynamic re-rendering. Will take a look at it.

Yeah, I think it's doing this because the component is no longer static like it should be. See comment on code. If there is a way to fetch MCP and LSP connections and then pass it to the status component before it renders I think this would be better to maintain existing behaviour with the tidier UI you've put in.

Every time you then run the /status command it can refetch everything it needs, render statically and then happy days!

Let me know what you think :)

[Avtrkrb]

Yeah, I think it's doing this because the component is no longer static like it should be. See comment on code. If there is a way to fetch MCP and LSP connections and then pass it to the status component before it renders II think this would be better to maintain existing behaviour with the tidier UI you've put in.

Let me know what you think :)

I agree with your point, 1 way I can think of is to keep the entire Status section static, poll for the MCP & LSP connection status & then update the Status section without dynamic re-rendering. Let me see what I can do.

[will-lamerton]

Yeah, I think it's doing this because the component is no longer static like it should be. See comment on code. If there is a way to fetch MCP and LSP connections and then pass it to the status component before it renders II think this would be better to maintain existing behaviour with the tidier UI you've put in.
Let me know what you think :)

I agree with your point, 1 way I can think of is to keep the entire Status section static, poll for the MCP & LSP connection status & then update the Status section without dynamic re-rendering. Let me see what I can do.

Awesome. Yeah, I think the status component must stay static really. This is to fit with the current rendering process which is there for performance as if anything stays dynamic it causes too many re-renders which in turn causes a lot of flickering.

I'm not convinced polling is necessary. I might be wrong but just running the /status command can do a one time poll and then render the status component if someone wants an update. A bit like when you change theme, old status components, don't dynamically update but if you then run /status the new theme setting is polled for and shows.