Skip to content

feat(app): revamp provider and workspace surfaces #19

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
astyfx merged 1 commit into from
Jun 17, 2026
Merged

feat(app): revamp provider and workspace surfaces #19

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 23 additions & 22 deletions bun.lock
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

2 changes: 1 addition & 1 deletion docs/architecture/conversation-flow.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ Stave keeps a single task chat UI by separating app-owned conversation state fro

1. The renderer builds a `CanonicalConversationRequest` from the task history, current user input, selected file contexts, and any persisted provider-native conversation id. Task turns also attach Stave-owned retrieved context for the current task/workspace plus bounded workspace-information snapshots. Provider runtimes may filter MCP-specific awareness context back out before rendering the final provider prompt when Stave Local MCP is not actually connected, so non-MCP users do not pay unnecessary prompt overhead. Oversized historical payloads such as `file_context` content, tool outputs, and diff bodies are sanitized before the request crosses IPC so broken replay data does not block later turns.
2. The provider bridge sends that canonical request plus a small fallback prompt across preload into Electron main, which validates the payload and forwards provider execution into the dedicated desktop `host-service` child runtime. The main-process bridge and `host-service` exchange framed JSON messages over stdio so large payloads are not coupled to newline-delimited transport limits.
3. **If the task provider is `stave`**, the runtime first calls `resolveStaveTarget` in `electron/providers/stave-router.ts` to analyse the prompt and select a real provider + model. A `system` event is emitted immediately so the UI can display which model was chosen and why. The resolved `providerId` and `model` are then forwarded into the standard turn flow.
3. `electron/providers/runtime.ts` dispatches the request to the selected Claude or Codex runtime.
4. Provider-specific translators rebuild the exact Claude or Codex prompt from the canonical request inside the runtime.
5. Claude and Codex both stream back normalized `BridgeEvent` records such as `text`, `thinking`, `tool`, `approval`, `user_input`, `diff`, and `done`.
6. The renderer replays those normalized events into one shared message model and one shared chat surface.
Expand Down
Loading
Loading