PRD: system status in live panel

[elroy-bot]

Expand the scope of the panel which currently only displays relevant memories.

there should also be a capability to have system execution info be logged there as well.

things like memory consolidation should be optionally surfaced there.

make a PRD for this feature and check it into version control

[elroy-bot]

@claude make a prd

[claude]

Claude finished @elroy-bot's task —— View job • claude/issue-475-20250825-1625 • Create PR ➔

---

Todo List

• Read repository guidelines and understand codebase structure
• Research current live panel implementation
• Analyze existing memory display functionality
• Draft comprehensive PRD document
• Create PRD file and commit to version control
• Push changes and provide PR link

Summary

Created comprehensive PRD document for expanding the live panel to include system status information beyond just memory context. The PRD covers:

Current State Analysis

• Analyzed existing live panel implementation (print_memory_panel)
• Reviewed memory consolidation system with progress tracking capabilities
• Identified gap in system operation visibility

Technical Requirements

• System status display framework alongside existing memory panel
• Memory consolidation status integration with progress tracking
• Configuration options for user control
• Performance and reliability requirements

Implementation Plan

• 4-phase approach over 6 weeks
• Foundation → Integration → Enhancement → Future features
• Includes technical architecture with data models and integration points

Risk Assessment

• Performance impact mitigation through lazy loading
• UI clutter prevention with opt-in design
• Thread-safe status tracking for concurrent operations

The PRD has been committed to version control as docs/prd-system-status-live-panel.md.

[elroy-bot]

@claude proceed with implementation

[claude]

Claude finished @elroy-bot's task —— View job • claude/issue-475-20250827-1706 • Create PR ➔

---

Todo List

• Read repository guidelines and analyze current implementation
• Analyze current live panel and memory consolidation implementations
• Design system status display framework
• Implement system status tracking infrastructure
• Integrate memory consolidation status display
• Add configuration options for user control
• Test implementation and ensure thread safety
• Commit and push changes

Implementation Complete

Successfully implemented the system status panel feature for live display of background operations. The implementation includes:

✅ Core Infrastructure

• System Status Tracking: New thread-safe SystemStatusTracker class in /elroy/core/system_status.py:1
• Status Data Models: Comprehensive tracking with progress, states, and operation details
• Thread Safety: Proper locking mechanisms for concurrent operations

✅ UI Integration

• New Configuration Option: Added show_system_status_panel to control visibility
• Live Panel Display: Shows active operations with progress percentages and details
• Clean UI Design: Styled panel alongside existing memory panel using Rich formatting

✅ Operation Integration

• Memory Consolidation: Full progress tracking in /elroy/repository/memories/consolidation.py:113
• Context Refresh: Status tracking in /elroy/repository/context_messages/operations.py:209
• Extensible Framework: Easy to add tracking to future background operations

✅ Configuration & Testing

• Default Enabled: Added to defaults.yml with show_system_status_panel: true
• CLI Options: Integrated with existing configuration system
• Test Coverage: Updated test files to include new parameters

The system displays operations like:

• • Memory Consolidation (75%): Consolidating cluster 3/4
• • Context Refresh: Compressing conversation context to manage memory

[elroy-bot]

@claude Im wondering if this would be better implemented as a singleton somehow, where there's a stateful status obj that takes in both current memories and current system ops. I've had mixed luck trying to include multiple live elements, as opposed to having one overarching one that holds everything.

Talk through some pros and cons of that approach vs what you've implemented

[elroy-bot]

@claude Im wondering if this would be better implemented as a singleton somehow, where there's a stateful status obj that takes in both current memories and current system ops. I've had mixed luck trying to include multiple live elements, as opposed to having one overarching one that holds everything.

Talk through some pros and cons of that approach vs what you've implemented

[claude]

Claude finished @elroy-bot's task —— View job

---

Analyzing Architecture Approaches

Todo List

• Read current SystemStatusTracker implementation
• Read current live panel and memory panel implementations
• Analyze singleton approach vs current architecture
• Provide detailed pros/cons comparison
• Make architectural recommendations

Architecture Comparison

After analyzing the codebase, here's my assessment of Singleton Unified Status Object vs Current Function-Based Approach:

Current Implementation (Function-Based)

# Current: Simple, stateless
def print_memory_panel(io: CliIO, ctx: ElroyContext):
    pipe(
        get_context_messages(ctx),
        get_in_context_memories_metadata, 
        io.print_memory_panel,
    )

Proposed Singleton Approach

# Proposed: Stateful singleton
class LiveStatusManager(metaclass=Singleton):
    def __init__(self):
        self.memory_data = []
        self.system_operations = []
    
    def update_and_display(self, io, ctx):
        # Unified update and display logic

Pros and Cons Analysis

Singleton Approach - PROS ✅

1. State Consistency: Single source of truth prevents timing issues between multiple panels
2. Performance: Can cache data and update incrementally rather than full refresh each time
3. Coordination: Easier to coordinate updates when both memory and system status change simultaneously
4. UI Synchronization: Eliminates flickering/inconsistencies from multiple live elements updating at different rates
5. Extensibility: Easy to add new status types (file operations, network tasks) to unified display

Singleton Approach - CONS ❌

1. Complexity: More complex state management, especially with threading (consolidation runs in background)
2. Testing: Harder to test due to global state and singleton lifecycle
3. Memory Overhead: Keeps state in memory even when panels aren't displayed
4. Threading Issues: Need careful synchronization since operations like /elroy/repository/memories/consolidation.py:113 run in background threads
5. Coupling: Creates tighter coupling between unrelated operations

Current Function-Based - PROS ✅

1. Simplicity: Stateless, predictable, easy to understand
2. Thread Safety: Each call is independent, no shared state to corrupt
3. Testability: Easy to unit test individual functions
4. Resource Efficient: No persistent state, fetches only what's needed when needed
5. Modularity: Memory panel logic completely separate from system operations

Current Function-Based - CONS ❌

1. Multiple Updates: Each panel updates independently, potential for UI inconsistency
2. Performance: Re-fetches data on every display (though caching happens at DB level)
3. Coordination: Hard to coordinate between panels (e.g., show memory consolidation affecting memory panel)

Recommendation: Hybrid Approach 🎯

Based on your "mixed luck with multiple live elements," I recommend a lightweight unified status coordinator:

@dataclass
class StatusSnapshot:
    memories: List[str]
    active_operations: List[SystemOperation]
    timestamp: datetime

class StatusCoordinator:  # Not singleton - injected as dependency
    def __init__(self):
        self._lock = threading.Lock()
        self._cached_snapshot: Optional[StatusSnapshot] = None
        self._cache_ttl = 1.0  # 1 second cache
    
    def get_current_status(self, ctx: ElroyContext) -> StatusSnapshot:
        with self._lock:
            if self._should_refresh():
                self._cached_snapshot = self._fetch_fresh_data(ctx)
            return self._cached_snapshot
    
    def display_unified_panel(self, io: CliIO, ctx: ElroyContext):
        status = self.get_current_status(ctx)
        # Display both memory and system status in coordinated way

Why This Hybrid Works:

• Addresses your "mixed luck": Single coordinated update eliminates timing issues
• Maintains simplicity: Not a singleton, just a coordinated data fetcher
• Thread safe: Proper locking for background operations
• Performance: Short-lived cache prevents excessive DB queries
• Testable: Can inject mock coordinator for testing

The key insight is you need coordination more than global state. A coordinator that's passed around (not singleton) gives you the benefits without the downsides.