WebSocket over use

[rjroy]

Many of the web socket operations are better done as REST.
We've opposed the system.

WebSockets are needed for the chat, but I'm not sure what else.

Each message will need to be reviewed and analyzed. Does this need a web socket? not because of how its implemented, but because of what it is intended to do.

[rjroy]

● Yes, that's a cleaner architecture. The current issue exists because WebSocket is being used for everything, but most operations are simple request/response patterns that
don't need persistent connections.

WebSocket makes sense for:

• Streaming AI responses (Discussion tab)
• Real-time progress updates (search indexing)
• Long-running operations with incremental results

REST makes sense for:

• capture_note - fire request, get confirmation
• list_directory, read_file - request/response
• toggle_task, get_goals, get_recent_activity
• start_meeting, stop_meeting

Benefits of the hybrid approach:

1. No connection state to manage for stateless operations (vault ID passed per-request)
2. Each component makes independent API calls without coordination
3. Simpler mental model: HTTP for actions, WebSocket for streams
4. Better error handling (HTTP status codes vs parsing error messages)
5. Easier to test (mock fetch vs mock WebSocket)
6. The bug we just fixed becomes impossible (no "forgot to send select_vault")

The WebSocket would remain only for Discussion mode where streaming is genuinely needed. Everything else becomes standard REST endpoints.

The patch I made today is a band-aid. The refactor you're describing fixes the root cause by choosing the right tool for each job.