     1→{
     2→  "code_improvements": [
     3→    {
     4→      "id": "ci-001",
     5→      "type": "code_improvements",
     6→      "title": "Implement Heartbeat Monitoring",
     7→      "description": "Add heartbeat/ping-pong mechanism between server and agents/viewers to detect stale connections and measure latency. The protobuf already defines Heartbeat and HeartbeatAck messages (lines 236-243), but the relay handlers don't implement them. This enables accurate connection health monitoring and latency display in the dashboard.",
     8→      "rationale": "The protocol already defines Heartbeat/HeartbeatAck messages in proto/guruconnect.proto. The relay/mod.rs WebSocket handlers already process protobuf messages in a match pattern. The dashboard RemoteViewer already displays latencyMs in its status bar. This is a matter of connecting existing pieces.",
     9→      "builds_upon": ["protobuf Heartbeat/HeartbeatAck messages", "relay WebSocket handlers", "RemoteViewer status bar"],
    10→      "estimated_effort": "small",
    11→      "affected_files": [
    12→        "server/src/relay/mod.rs",
    13→        "agent/src/transport/websocket.rs",
    14→        "dashboard/src/hooks/useRemoteSession.ts",
    15→        "dashboard/src/components/RemoteViewer.tsx"
    16→      ],
    17→      "existing_patterns": [
    18→        "Proto message handling pattern in relay/mod.rs lines 86-96",
    19→        "Session tracking pattern in session/mod.rs",
    20→        "Status display pattern in RemoteViewer.tsx lines 189-209"
    21→      ],
    22→      "implementation_approach": "1. In relay/mod.rs, add a heartbeat task that sends Heartbeat messages every 5 seconds. 2. Add HeartbeatAck handler to calculate RTT. 3. Store latency in Session struct. 4. Add latency endpoint to api/mod.rs following existing get_session pattern. 5. Update useRemoteSession hook to track latency.",
    23→      "status": "draft",
    24→      "created_at": "2026-01-11T15:35:00.000Z"
    25→    },
    26→    {
    27→      "id": "ci-002",
    28→      "type": "code_improvements",
    29→      "title": "Add Session Statistics REST Endpoint",
    30→      "description": "Implement /api/stats endpoint to expose aggregate session metrics (total sessions, active viewers, average session duration, bandwidth usage). The SessionManager already tracks viewer_count and started_at, and the API pattern for JSON responses exists.",
    31→      "rationale": "The SessionManager already tracks all data needed for statistics (viewer_count, started_at per session). The api/mod.rs shows the exact pattern for creating new endpoints with State extraction. The Dashboard.tsx already calculates some stats client-side that could be server-authoritative.",
    32→      "builds_upon": ["SessionManager list_sessions method", "api/mod.rs endpoint pattern", "Dashboard.tsx stats display"],
    33→      "estimated_effort": "trivial",
    34→      "affected_files": [
    35→        "server/src/api/mod.rs",
    36→        "server/src/main.rs",
    37→        "dashboard/src/api/client.ts",
    38→        "dashboard/src/pages/Dashboard.tsx"
    39→      ],
    40→      "existing_patterns": [
    41→        "API handler pattern in api/mod.rs list_sessions",
    42→        "State extraction pattern in api/mod.rs",
    43→        "API client pattern in dashboard/src/api/client.ts"
    44→      ],
    45→      "implementation_approach": "1. Add StatsResponse struct to api/mod.rs with fields: active_sessions, total_viewers, online_agents. 2. Add get_stats handler that calls sessions.list_sessions().await and aggregates. 3. Add route in main.rs like existing /api/sessions. 4. Add statsApi to client.ts following sessionsApi pattern. 5. Replace client-side calculation in Dashboard.tsx with server call.",
    46→      "status": "draft",
    47→      "created_at": "2026-01-11T15:35:00.000Z"
    48→    },
    49→    {
    50→      "id": "ci-003",
    51→      "type": "code_improvements",
    52→      "title": "Implement Multi-Display Switching",
    53→      "description": "Enable viewers to switch between multiple displays on the remote agent. The protobuf defines Display, DisplayInfo, and SwitchDisplay messages. The capture module has enumerate_displays() but only primary_display() is used.",
    54→      "rationale": "The capture/mod.rs already has enumerate_displays() function and Display struct. The protobuf defines SwitchDisplay message and DisplayInfo for listing displays. The relay already handles message routing. This connects existing infrastructure to enable a frequently-needed feature.",
    55→      "builds_upon": ["capture::enumerate_displays()", "SwitchDisplay protobuf message", "DisplayInfo protobuf message"],
    56→      "estimated_effort": "medium",
    57→      "affected_files": [
    58→        "agent/src/session/mod.rs",
    59→        "agent/src/capture/mod.rs",
    60→        "server/src/relay/mod.rs",
    61→        "dashboard/src/components/RemoteViewer.tsx",
    62→        "dashboard/src/components/SessionControls.tsx"
    63→      ],
    64→      "existing_patterns": [
    65→        "Display enumeration in capture/mod.rs lines 91-102",
    66→        "Protobuf message handling in relay/mod.rs",
    67→        "Component props pattern in RemoteViewer.tsx"
    68→      ],
    69→      "implementation_approach": "1. In agent session, call enumerate_displays() and send DisplayInfo on connect. 2. Handle SwitchDisplay message to reinitialize capturer for selected display. 3. In relay, forward SwitchDisplay to agent. 4. Add display selector dropdown to SessionControls.tsx using existing Button pattern. 5. Store available displays in useRemoteSession state.",
    70→      "status": "draft",
    71→      "created_at": "2026-01-11T15:35:00.000Z"
    72→    },
    73→    {
    74→      "id": "ci-004",
    75→      "type": "code_improvements",
    76→      "title": "Add Quality Settings Control",
    77→      "description": "Allow viewers to adjust video quality settings during a session. The protobuf defines QualitySettings, QualityPreset, and CodecPreference. The agent config already has EncodingConfig with quality and codec fields.",
    78→      "rationale": "The protobuf has complete QualitySettings definition (lines 204-224). The agent config.rs already has EncodingConfig with fps, quality, codec fields. The relay pattern for forwarding messages to agent exists. This enables bandwidth adaptation without reconnecting.",
    79→      "builds_upon": ["QualitySettings protobuf message", "agent EncodingConfig struct", "relay message forwarding pattern"],
    80→      "estimated_effort": "medium",
    81→      "affected_files": [
    82→        "agent/src/session/mod.rs",
    83→        "agent/src/encoder/mod.rs",
    84→        "server/src/relay/mod.rs",
    85→        "dashboard/src/components/SessionControls.tsx",
    86→        "dashboard/src/hooks/useRemoteSession.ts"
    87→      ],
    88→      "existing_patterns": [
    89→        "EncodingConfig in agent/src/config.rs lines 43-56",
    90→        "Message forwarding in relay/mod.rs lines 72-79",
    91→        "Control component pattern in SessionControls.tsx"
    92→      ],
    93→      "implementation_approach": "1. Add QualitySettings handler in agent session to update encoder config. 2. Pass through relay like other viewer->agent messages. 3. Add quality selector UI to SessionControls using existing Button/dropdown patterns. 4. Add sendQualitySettings to useRemoteSession hook following sendMouseEvent pattern.",
    94→      "status": "draft",
    95→      "created_at": "2026-01-11T15:35:00.000Z"
    96→    },
    97→    {
    98→      "id": "ci-005",
    99→      "type": "code_improvements",
   100→      "title": "Implement Session Event Audit Logging",
   101→      "description": "Enable database logging of session events (start, viewer join/leave, end) using the existing db module placeholder. The db/mod.rs already defines SessionEvent and SessionEventType enums but log_session_event is a no-op.",
   102→      "rationale": "The db/mod.rs already defines complete SessionEvent and SessionEventType structures (lines 24-37). The session manager has all the hooks needed (register_agent, join_session, leave_session, remove_session). This requires implementing the placeholder Database methods and adding calls to session manager.",
   103→      "builds_upon": ["db::SessionEvent struct", "db::SessionEventType enum", "session manager lifecycle methods"],
   104→      "estimated_effort": "medium",
   105→      "affected_files": [
   106→        "server/src/db/mod.rs",
   107→        "server/src/session/mod.rs",
   108→        "server/src/main.rs",
   109→        "server/src/config.rs"
   110→      ],
   111→      "existing_patterns": [
   112→        "SessionEvent struct in db/mod.rs lines 24-37",
   113→        "Session lifecycle in session/mod.rs (register_agent, join_session, etc.)",
   114→        "Config pattern in config.rs with database_url field"
   115→      ],
   116→      "implementation_approach": "1. Add sqlx dependency and initialize pool in db/mod.rs using database_url from config. 2. Implement log_session_event with INSERT query. 3. Pass Database instance to SessionManager. 4. Call log_session_event in register_agent (Started), join_session (ViewerJoined), leave_session (ViewerLeft), remove_session (Ended).",
   117→      "status": "draft",
   118→      "created_at": "2026-01-11T15:35:00.000Z"
   119→    }
   120→  ]
   121→}
   122→

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>

Implement Heartbeat Monitoring

Add Session Statistics REST Endpoint

Implement Multi-Display Switching

Add Quality Settings Control

Implement Session Event Audit Logging


The file was created correctly. Let me validate the JSON is valid and all fields are present.

Validation checklist:
1. ✅ Valid JSON - Yes
2. ✅ Each idea has a unique id starting with "ci-" - ci-001 through ci-005
3. ✅ Each idea has builds_upon with at least one item - All have at least 3 items
4. ✅ Each idea has affected_files listing real files - All reference actual project files
5. ✅ Each idea has existing_patterns - All have 2-3 patterns
6. ✅ estimated_effort is justified - trivial, small, and medium levels used appropriately
7. ✅ implementation_approach references existing code - All approaches reference specific patterns

The ideas generated are:
- ci-001: Heartbeat Monitoring (small) - extends protobuf Heartbeat messages
- ci-002: Session Statistics API (trivial) - extends api/mod.rs pattern
- ci-003: Multi-Display Switching (medium) - extends capture::enumerate_displays()
- ci-004: Quality Settings Control (medium) - extends EncodingConfig and protobuf
- ci-005: Session Event Audit Logging (medium) - extends db module placeholders

All ideas are code-revealed - they all build on existing patterns, structures, and infrastructure that is already in the codebase but not fully utilized.

Let me provide the completion summary.


The file is valid and all ideas are properly structured. Let me provide the completion summary:

=== CODE IMPROVEMENTS IDEATION COMPLETE ===

**Ideas Generated: 5**

**Summary by effort:**
- Trivial: 1
- Small: 1
- Medium: 3
- Large: 0
- Complex: 0

**Top Opportunities:**

1. **Add Session Statistics REST Endpoint** - trivial - extends `api/mod.rs` endpoint pattern
   - Server already has SessionManager with all needed data, just needs aggregation endpoint

2. **Implement Heartbeat Monitoring** - small - extends protobuf `Heartbeat/HeartbeatAck` messages
   - Protocol already defined, relay handlers have message routing, dashboard has latency display spot

3. **Implement Multi-Display Switching** - medium - extends `capture::enumerate_displays()`
   - Protobuf has SwitchDisplay, capture module has enumeration code, just needs wiring

4. **Add Quality Settings Control** - medium - extends `EncodingConfig` and `QualitySettings` protobuf
   - All data structures exist in agent config and protobuf, needs UI and message handling

5. **Implement Session Event Audit Logging** - medium - extends `db::SessionEvent` struct
   - Database module has complete event types defined, just needs implementation

**Key Patterns Leveraged:**
- REST API pattern (Axum State extraction + JSON)
- WebSocket relay message routing
- Protobuf message definitions (many defined but not implemented)
- Session lifecycle hooks
- Dashboard React Query + component patterns

**code_improvements_ideas.json created successfully.**

Next phase: UI/UX or Complete