public/galaxy
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: introduce Rig agent runtime migration

Browse Source
This commit is contained in:
rkw6086
2026-08-04 02:15:18 -05:00
parent d9cf0d8ae3
commit 4c7270db8d
39 changed files with 2551 additions and 211 deletions
Download Patch File Download Diff File Expand all files Collapse all files
plans/galaxy-local-first-rig.md
+393
View File
@@ -0,0 +1,393 @@
# Galaxy Local-First Recovery and Rig Migration
> **Started:** 2026-08-04
> **Status:** Active architecture recovery
> **UI ledger:** [`ui-flow-inventory.md`](ui-flow-inventory.md)
> **Supersedes:** [`galaxy-refactor.md`](galaxy-refactor.md)
## Product contract
Galaxy is a local-first developer terminal with Warp-quality interaction design. It may communicate
with a model provider, remote machine, or tool only when the user or an administrator has explicitly
configured that boundary. It must not depend on Warp authentication, cloud storage, billing,
telemetry, remote logging, remote feature control, session sharing, or Oz.
The non-negotiable properties are:
1. A fresh install works without an account.
2. Terminal, editor, conversation, rules, profiles, notebooks, workflows, and history data are local.
3. No inherited Warp endpoint can address an external host in the OSS build.
4. Model traffic goes only to the provider selected for the active model.
5. ACP agents are explicit, trusted local subprocesses with a visible permission boundary.
6. Network-capable tools are off by default and visible when enabled or invoked.
7. The UI consumes Galaxy-owned domain types, not a provider SDK or Warp wire protocol.
8. Provider and agent implementations are replaceable without changing conversation UI code.
## Current baseline
The code is not merely untidy; it has conflicting architectural centers.
- `app/src` contains roughly 1.08 million lines of Rust across product and test code.
- `app/src/ai` alone contains roughly 270,000 lines in 555 Rust files.
- Seventy-six app files reference `warp_multi_agent_api`.
- The provider and ACP implementation inspected for this plan spans more than 22,000 lines.
- Large presentation/coordinator files include `workspace/view.rs` (about 29,000 lines),
`terminal/view.rs` (about 29,000), `terminal/input.rs` (about 16,000), and
`settings_view/ai_page.rs` (about 8,500).
- The OSS binary configured Warp production HTTP, RTC, session-sharing, and Firebase values even
though telemetry sending had already been stubbed out. The first safety patch replaces those
values with loopback-only disabled configuration and rejects Warp/Firebase auth exchange.
The provider-backed prompt path currently resembles:
```text
Galaxy UI/controller
-> RequestParams (already contains provider-specific Bedrock history fields)
-> warp_multi_agent_api::Request protobuf
-> Bedrock or OpenAI request translator
-> provider SDK / JSON / SSE
-> provider response translator
-> warp_multi_agent_api::ResponseEvent protobuf
-> Galaxy controller/history/UI
```
ACP takes another branch inside the same `ResponseStream` model and translates ACP events into the
same legacy Warp response events. Provider choice, provider credentials, ACP session state, retry
policy, network recovery, cancellation, telemetry remnants, and UI event emission therefore meet in
one coordinator.
The problem is not that translations exist. Every integration needs one boundary translation. The
problem is that Warp's former server protocol is acting as Galaxy's domain model, so every new
provider needs translations on both sides of a protocol Galaxy does not own.
## Target architecture
```text
GalaxyUI views and models
|
v
Galaxy application services
conversation / permissions / local persistence / provider registry
|
v
galaxy_agent_core
TurnRequest, Message, Content, ToolSpec, AgentEvent, Usage, StopReason, AgentError
AgentRuntime trait -> AgentEventStream
|
+-------------------------+
| |
v v
galaxy_agent_rig galaxy_agent_acp
OpenAI-compatible ACP subprocess/session
LiteLLM/Ollama/LM Studio ACP event adapter
AWS Bedrock Galaxy tool bridge
Rig/MCP tool bridge
| |
+------------+------------+
v
explicit egress policy
```
### `galaxy_agent_core`
This crate is the dependency rule that makes the refactor possible. It owns only stable Galaxy
concepts:
- ordered conversation messages with text, images, reasoning, tool calls, and tool results;
- model/provider identifiers that do not encode a particular SDK type;
- dynamic tool descriptions and JSON schemas;
- turn events such as text delta, reasoning delta, tool proposed, permission requested, tool
started, tool completed, usage updated, turn stopped, and failure;
- cancellation and live steering control;
- structured stop and error classification;
- the `AgentRuntime` interface.
It must not depend on GalaxyUI, `warp_multi_agent_api`, Rig, an AWS SDK, ACP, GraphQL, or app
persistence.
### `galaxy_agent_runtime`
This application-service layer owns:
- resolving a conversation's backend once per conversation;
- resolving a model to a configured provider endpoint;
- building system and project context;
- conversation history and summarization policy;
- tool registration and permission policy;
- retry, cancellation, steering, and recovery semantics;
- mapping runtime events to local persistence and UI-facing models.
The current UI can initially be kept alive with a temporary adapter from `AgentEvent` to legacy
`warp_multi_agent_api::ResponseEvent`. That adapter is a migration device, not the final boundary.
### `galaxy_agent_rig`
Rig becomes the implementation for provider-backed conversations. The version evaluated for this
plan is Rig 0.40.0. When introduced, it must be pinned exactly until its documented breaking-change
cadence settles for Galaxy.
Rig is a good fit for the provider side because it already defines a canonical completion request,
provider implementations, streaming content/tool events, model history, typed tools, hooks, MCP via
`rmcp`, and a multi-turn agent runner. The integration should use those abstractions rather than
copying Rig's internal provider request structs into Galaxy types.
Provider coverage for the first migration:
| Galaxy provider | Rig implementation | Notes |
|---|---|---|
| LiteLLM / generic OpenAI-compatible | Rig OpenAI-compatible client | Custom base URL and key; preserve per-model endpoint routing. |
| Ollama / LM Studio | OpenAI-compatible or Rig provider adapter | Treat as explicit local/LAN endpoints. |
| AWS Bedrock | `rig-bedrock` through the Rig facade | Preserve profile, static credential, SSO, region, and inference-profile behavior through a focused compatibility audit. |
| MCP tools | Rig `rmcp` tool server/client support | Reuse existing Galaxy MCP lifecycle where it is stronger; bridge tools at one boundary. |
Rig's documented integrations cover model providers and MCP, not Agent Client Protocol. ACP should
not be forced through Rig. It is a peer implementation of `AgentRuntime`.
### Tool execution and permissions
Galaxy must continue to own the user-facing tool lifecycle. A model framework may drive the loop,
but it must not silently bypass Galaxy's permission cards or execute a shell/file operation before
the UI can authorize it.
The Rig adapter will therefore:
1. register thin Rig tools that delegate into Galaxy's tool executor;
2. attach a Rig agent hook to observe and fail closed on tool calls;
3. emit a Galaxy `ToolProposed` or `PermissionRequested` event before execution;
4. await a permission decision when required;
5. execute through the existing Galaxy tool implementation;
6. return the result to Rig and emit correlated start/result events using a stable Galaxy call ID.
Rig 0.40's streamed model-tool-call, tool-execution-start, tool-result, hooks, request patching, and
fail-closed flow semantics are useful here, but contract tests must prove the exact ordering Galaxy's
UI expects.
### `galaxy_agent_acp`
The existing `crates/acp` runtime has useful protocol/session work and should be retained initially.
Its application adapter should move out of `ResponseStream` and emit `AgentEvent` directly.
ACP-specific capabilities remain visible in backend metadata:
- session load/new-session support;
- agent authentication methods;
- configuration discovery;
- filesystem and terminal capability negotiation;
- permission requests;
- prompt steering and cancellation.
Provider model controls should not appear for ACP-owned conversations because the external agent
owns its model and authentication.
## Local data architecture
"Galaxy Drive" becomes a local content library, not a renamed cloud sync client. Existing UI for
rules, profiles, notebooks, workflows, environment-variable collections, and MCP configurations can
be preserved while its storage service is replaced.
The target repository interface is local and revisioned:
```text
LocalObjectRepository
list(kind, scope)
get(id)
create(object)
update(id, expected_revision, object)
delete(id)
watch(kind/scope)
```
SQLite remains the default store. Filesystem import/export can be layered on later. The UI should
not know whether an object used to be a `CloudObject`; it should receive local object IDs and local
repository events.
Migration must preserve existing local rows before removing cloud-shaped schemas. A temporary
compatibility repository can read the current tables without starting `SyncQueue`, `UpdateManager`,
GraphQL, or RTC listeners.
## Network and trust model
Every runtime network path belongs to one of these classes:
| Class | Default | Examples |
|---|---|---|
| Inherited product service | Forbidden | Warp auth, GraphQL, RTC, session sharing, Oz, telemetry, remote logs, remote flags. |
| Configured model provider | Allowed only when selected | Bedrock, LiteLLM, OpenAI-compatible endpoint, Ollama on another host. |
| User-initiated remote development | Allowed with visible intent | SSH, Git fetch/push, remote MCP, provider/model discovery. |
| Agent network tool | Disabled until enabled by policy | Web fetch/search, HTTP MCP tools, computer-use browser actions. |
| Product maintenance | Separate explicit policy | Update checks, release download, optional LSP/runtime downloads. |
The OSS binary must never contain a usable inherited Warp endpoint. UI hiding and feature flags do
not satisfy this requirement by themselves.
## Migration sequence
### Phase 0 — Freeze, inventory, and close implicit egress
- Maintain the UI ledger and classify every registered action/menu/settings route.
- Disable inherited Warp service endpoints in OSS and fail closed on auth exchange.
- Rotate and revoke the signing credential currently tracked in migration documentation, remove it
from the working tree, and purge it from repository history in a coordinated security change.
- Add an automated forbidden-domain test for shipped configuration and runtime network fixtures.
- Mark old Bedrock-only architecture documents as historical.
- Stop porting upstream cloud, billing, telemetry, or Oz features during this migration.
Exit condition: a clean OSS launch and normal local terminal use cannot address a Warp-operated
runtime endpoint, even if a stale UI action is triggered.
### Phase 1 — Introduce the Galaxy agent domain seam
- [x] Add `galaxy_agent_core` with requests, messages, events, errors, turn control, and the
`AgentRuntime` trait.
- [x] Add contract tests using a deterministic fake runtime.
- [x] Move the provider-neutral conversation message and tool-definition types out of the app
crate, retaining only a temporary compatibility re-export.
- [x] Route provider request startup through a named `ProviderRuntime` boundary so the controller
no longer calls the provider generator directly.
- [ ] Map legacy response events to `AgentEvent` and make the compatibility runtime implement
`AgentRuntime`; keep the inverse UI adapter until consumers migrate.
- [ ] Remove provider-specific fields such as `bedrock_message_history` from UI-level
`RequestParams`.
The compatibility path still produces a Warp protobuf stream for the UI, but Rig-backed providers
implement `AgentRuntime` and cross that protocol boundary only in the app-owned UI adapter. Legacy
providers remain behind `ProviderRuntime` while their migrations continue.
Exit condition: the conversation controller selects an `AgentRuntime` and does not match directly on
Bedrock/OpenAI/ACP configuration.
### Phase 2 — First Rig vertical slice: OpenAI-compatible streaming
- [x] Pin `rig-core` 0.40.0 and implement one explicit OpenAI-compatible provider.
- [x] Support text, reasoning where available, cancellation, stop reason, usage, and persisted
history.
- [x] Route any model entry with `use_rig = true` through Rig while leaving unmarked models on the
compatibility path.
- [x] Test Rig's real Chat Completions SSE parser against normalized events, plus the UI stop/usage
compatibility mappings.
Initial opt-in example:
```toml
[ai.openai]
enabled = true
[[ai.providers]]
name = "LiteLLM (ai.ryserve.net)"
base_url = "https://ai.ryserve.net/v1"
api_key = "REPLACE_WITH_LOCAL_KEY"
[[ai.providers.models]]
model_id = "codex-gpt-5.6-sol-xhigh"
display_name = "Codex GPT-5.6 SOL (xhigh)"
context_size = 200000
provider = "openai"
use_rig = true
supports_system_messages = false
```
Phase 2 intentionally does not expose Galaxy's legacy tool list to Rig. That ownership moves as a
unit in Phase 3; until then, the opt-in slice validates text conversation streaming without two
competing tool executors.
Exit condition: a LiteLLM or local OpenAI-compatible conversation streams through Rig without
`warp_multi_agent_api::Request` on the provider side.
### Phase 3 — Tools, permissions, MCP, and multi-turn behavior
- Bridge the core Galaxy tools into Rig.
- Preserve permission cards, denial, cancellation, parallel-call ordering, and error visibility.
- Bridge current MCP tools through Rig's `rmcp` support or a single Galaxy tool-server adapter.
- Port loop prevention and unknown-tool handling to domain-level policies.
Exit condition: representative read, edit, shell, MCP, denial, and failure flows pass integration
tests without provider-specific UI code.
### Phase 4 — Bedrock through Rig
- Implement Bedrock client construction and model resolution through `rig-bedrock`.
- Compare request behavior for system prompts, images, tool schemas, cache controls, reasoning,
inference profiles, token usage, and context limits.
- Keep a short-lived compatibility fallback for unsupported Bedrock behavior, measured by tests.
- Delete custom Bedrock translation code only after parity is proven.
Exit condition: supported Bedrock models use the same `AgentRuntime` event contract as
OpenAI-compatible models.
### Phase 5 — ACP convergence
- Move ACP launch/session/transport control behind `galaxy_agent_acp`.
- Translate ACP events directly to `AgentEvent`.
- Remove ACP branching from the UI response stream model.
- Keep ACP-specific settings and capability disclosure, but share transcript and permission UI.
Exit condition: the controller cannot distinguish ACP from Rig except through backend capability
metadata.
### Phase 6 — Local Galaxy Drive and identity removal
- Introduce `LocalObjectRepository` over existing SQLite data.
- Move rules, profiles, notebooks, workflows, env collections, and MCP configs to the local service.
- Replace account/workspace ownership with local scopes.
- Remove auth, teams, billing, referral, cloud sync, GraphQL, RTC, sharing, and remote-control UI.
Exit condition: none of the kept content flows require `AuthState`, `CloudModel`, `UpdateManager`,
`SyncQueue`, or a server ID.
### Phase 7 — UI untangling
- Split coordinator files along the flow boundaries in the UI ledger.
- Views render state and emit intent; application services perform persistence and runtime work.
- Reuse existing shared button themes and theme tokens.
- Remove unreachable modals/actions instead of continuing to hide them behind flags.
Exit condition: every kept flow has an owner, a state model, a service boundary, and automated
coverage for success, failure, cancellation, and restore where applicable.
### Phase 8 — Delete the legacy protocol center
- Remove `warp_multi_agent_api` from UI/controller and persistence code.
- Delete the custom OpenAI/Bedrock request and response translators replaced by Rig.
- Delete no-op telemetry schemas/macros after call sites no longer depend on them.
- Remove Warp server, GraphQL, Firebase, cloud-object, Oz, billing, and referral crates from default
and then workspace builds when no retained feature needs them.
Exit condition: `rg` finds no runtime dependency from the shipped app to Warp service code or Warp's
multi-agent wire protocol.
## Verification gates
Every phase must keep these checks green:
- formatting and Clippy for changed crates;
- unit tests for the new domain/runtime layer;
- deterministic transcript contract tests;
- integration coverage for terminal and agent flows touched by the phase;
- a local-only egress test using request interception or a denied-network test environment;
- restart/restore tests for conversations and local content;
- no secret or prompt contents in logs unless a user explicitly enables a diagnostic mode.
Provider parity tests should compare semantic events, not provider JSON snapshots alone. The stable
contract is what the UI and persistence observe.
## Decisions
| Decision | Choice |
|---|---|
| Provider abstraction | Rig behind a Galaxy-owned runtime interface. |
| ACP relationship | Peer runtime, not a Rig provider. |
| UI compatibility during migration | Temporary `AgentEvent` to legacy response-event adapter. |
| Long-term UI model | Galaxy domain events only. |
| Galaxy Drive | Local SQLite-backed content library. |
| Login/account | Remove from OSS product flows. |
| Telemetry/remote logs/remote flags | Remove, not merely default-off. |
| SSH and remote Git | Keep as explicit user-initiated remote development boundaries. |
| Web/network agent tools | Disabled by default and permission-visible. |
| Rig dependency | Exact version pin with upgrade contract tests. |
## Immediate next vertical slice
After the Phase 0 egress guard and UI ledger are verified, the next implementation change is a small
`galaxy_agent_core` crate plus a legacy adapter. It should move only provider-neutral message/event
types and runtime selection. Adding Rig before this seam would couple the UI to a new framework and
repeat the current mistake with a different name.
plans/galaxy-refactor.md
+5
View File
@@ -1,5 +1,10 @@
# Galaxy Refactor — Implementation Plan
> **Superseded:** This Bedrock-only plan no longer represents the product direction.
> Use [`galaxy-local-first-rig.md`](galaxy-local-first-rig.md) and
> [`ui-flow-inventory.md`](ui-flow-inventory.md). This file remains as historical
> context so completed work and earlier decisions are not silently lost.
> **Created:** 2026-05-07
> **Status:** In Progress
> **Current Phase:** Phase 1 — Crate Renaming
plans/ui-flow-inventory.md
+129
View File
@@ -0,0 +1,129 @@
# Galaxy UI Flow Inventory
> **Started:** 2026-08-04
> **Status:** First-pass surface classification; action-level trace audit in progress
> **Architecture:** [`galaxy-local-first-rig.md`](galaxy-local-first-rig.md)
## How this ledger is used
This is the source of truth for deciding what Galaxy keeps, rebuilds, or removes. A directory name is
not a product decision. Each user intent is traced from every entry point through state, persistence,
runtime/network dependencies, and rendered outcomes.
Audit sources include:
- root/onboarding states in `app/src/root_view.rs`;
- registered workspace actions in `app/src/workspace/action.rs`;
- app menus, command palette, keybindings, context menus, URI handlers, and toolbar buttons;
- settings navigation and widgets under `app/src/settings_view`;
- left/right panels and terminal/agent input modes;
- existing integration-test modules under `app/src/integration_testing` and `crates/integration`;
- feature flags that make otherwise hidden flows reachable in OSS/dogfood builds.
For each kept or rebuilt flow, completion means checking:
- [ ] every mouse, keyboard, command-palette, menu, URI, startup, and programmatic entry point;
- [ ] empty, loading, success, partial-stream, denied, cancelled, offline, error, and retry states;
- [ ] close/reopen, restart, and session-restore behavior where state persists;
- [ ] focus, hover, accessibility, and context-flag behavior;
- [ ] local writes and migration behavior;
- [ ] every network destination and the user intent that authorizes it;
- [ ] unit and integration coverage;
- [ ] removal of obsolete actions, flags, settings, assets, and service code after migration.
Status values:
- **Keep/local:** core behavior remains and must require no service.
- **Keep/explicit:** remote behavior remains only behind explicit user/admin configuration or action.
- **Rebuild:** preserve the intent/UI value but replace its backing service or state model.
- **Remove:** the intent belongs to Warp's hosted product and should disappear completely.
- **Audit:** disposition or reachability still needs code/runtime validation.
## Flow ledger
| ID | Surface and user intent | Current coupling observed | Target disposition | Status |
|---|---|---|---|---|
| BOOT-01 | Launch app and reach a usable workspace | Root auth/onboarding state, server API provider, auth manager, cloud/update models | Launch directly into local workspace; provider setup is optional and non-blocking | Rebuild |
| BOOT-02 | First-run education and appearance setup | Agent onboarding, login slide, server `is_onboarded` state | Local onboarding focused on terminal mode, privacy boundary, and provider/ACP choices | Rebuild |
| BOOT-03 | Restore windows, tabs, panes, CWDs, and agent conversations | SQLite plus cloud-shaped conversation/object state | Local SQLite restore only | Keep/local |
| BOOT-04 | Sign in, sign out, reauth, SSO, anonymous user | Firebase/Warp auth and account UI | No account in OSS | Remove |
| WS-01 | Create, close, reorder, rename, pin, group, and color tabs | Workspace action/controller mega-file | Preserve behavior; split state ownership later | Keep/local |
| WS-02 | Split, close, focus, rename, maximize, and navigate panes | PaneGroup, Workspace, terminal model | Preserve | Keep/local |
| WS-03 | Save/launch tab configurations and worktrees | Local TOML/repo plus some telemetry/cloud vocabulary | Preserve as local templates | Keep/local |
| WS-04 | Open settings, resource center, logs, and diagnostic panes | Mixed local and server/account actions | Preserve local pages; remove hosted links/actions | Rebuild |
| TERM-01 | Run shell commands and view structured blocks | Terminal/UI core | Preserve | Keep/local |
| TERM-02 | Search command history, blocks, commands, files, and palettes | SQLite/local index plus cloud object sources | Preserve local sources; remove hosted sources | Rebuild |
| TERM-03 | Use SSH, remote shells, and Wormhole/warpification | Remote host and remote-server components | Keep only explicit remote-host behavior; audit branding and hidden service calls | Keep/explicit |
| TERM-04 | Share a terminal/session by URL or QR code | Warp session-sharing service | No hosted replacement in local-first scope | Remove |
| TERM-05 | Sync terminal input across panes/tabs | Local workspace state | Preserve | Keep/local |
| AGENT-01 | Start an agent conversation in a tab/pane | Blocklist controller, Warp proto request, provider/ACP branch | Route through `AgentRuntime` | Rebuild |
| AGENT-02 | Select provider, model, profile, and context limits | LLM preferences, Bedrock/OpenAI settings, ACP special cases | Unified provider registry; capability-aware controls | Rebuild |
| AGENT-03 | Compose prompts with files, selections, images, rules, and project context | Context chips, cloud-shaped rules, provider-specific request fields | Galaxy domain content/context builder | Rebuild |
| AGENT-04 | Watch text, reasoning, status, usage, and stop state stream | Provider translators emit Warp response events | Render `AgentEvent` stream | Rebuild |
| AGENT-05 | Review/approve/deny shell, file, MCP, and other tool calls | Blocklist action model and permissions; ACP has a parallel policy | One Galaxy tool/permission lifecycle shared by Rig and ACP | Rebuild |
| AGENT-06 | Cancel, interrupt, queue, send-now, or steer a running turn | ResponseStream/PendingResponseStreams and ACP steering | Provider-neutral turn control | Rebuild |
| AGENT-07 | Rename, pin, resume, fork, summarize, rewind, or delete conversations | SQLite plus server/cloud conversation vocabulary | Preserve meaningful local operations; remove cloud handoff/link actions | Rebuild |
| AGENT-08 | Inspect context usage, costs, and progressive summary | Bedrock-specific history fields and usage mapping | Provider-neutral usage; cost shown only when pricing is known/configured | Rebuild |
| AGENT-09 | Spawn and inspect child agents/orchestration | Warp MAA task schema, blocklist orchestration, some cloud assumptions | Defer until single-agent Rig tools are stable; local-only implementation | Audit |
| AGENT-10 | Start/restore an ACP-backed conversation | ACP runtime + separate ResponseStream branch | `galaxy_agent_acp` peer runtime with shared transcript and permissions | Rebuild |
| AGENT-11 | Detect/manage CLI agents and notifications | Agent SDK, Codex/OpenCode/Claude/Gemini harness/plugin code | Keep only ACP configuration and explicitly requested local integrations; remove Warp plugin cruft | Audit |
| AGENT-12 | Run Oz/cloud/ambient/scheduled agents and hand off local/cloud work | Agent SDK, cloud environments, Warp APIs, RTC | Hosted intent is out of scope | Remove |
| AGENT-13 | Configure/use MCP servers and resources | Local files, OAuth, managed/server MCP, tool execution | Keep local/explicit remote MCP; remove managed Warp gallery/secrets dependencies | Rebuild |
| AGENT-14 | Create/use global and project rules and skills | CloudModel AIFacts plus local rule/skill files | Local repository/filesystem only | Rebuild |
| AGENT-15 | Use voice input/transcription | Local capture plus Warp transcription endpoint or provider assumptions | Keep only with an explicit local/configured transcription backend | Audit |
| CODE-01 | Browse project files and global search | Local filesystem/index plus remote indexing branches | Preserve local; remote only for explicit SSH session | Keep/local |
| CODE-02 | Edit files with LSP completion, diagnostics, actions, rename, and signature help | Local filesystem/LSP/runtime downloads | Preserve; downloads are explicit product-maintenance egress | Keep/local |
| CODE-03 | Review local Git diffs, comments, stage/revert, commit | Local Git plus optional remote/GitHub models | Preserve local Git review | Keep/local |
| CODE-04 | Fetch PR metadata, push, or authenticate GitHub | Git/GitHub/server integration paths | Keep ordinary explicit Git operations; remove Warp-mediated GitHub auth | Rebuild |
| DRIVE-01 | Open Galaxy Drive/content library and navigate folders | Drive UI backed by CloudModel/UpdateManager/GraphQL | Local content library over SQLite | Rebuild |
| DRIVE-02 | Create/edit/import/export notebooks | Cloud object ownership/sync around useful local editors | Preserve editor; replace repository | Rebuild |
| DRIVE-03 | Create/edit/run/import/export workflows | Cloud object ownership/sync around useful local runner/UI | Preserve runner/editor; replace repository | Rebuild |
| DRIVE-04 | Manage environment-variable collections and external secrets | Cloud objects, server-managed secrets, local execution | Local encrypted/OS-keychain-backed storage; never cloud sync | Rebuild |
| DRIVE-05 | Manage profiles, rules, prompts, and MCP objects | Cloud object polymorphism | Local typed repositories | Rebuild |
| DRIVE-06 | Share objects, team folders, team roles, and sync conflicts | Warp cloud/team services | No hosted replacement in current scope | Remove |
| SET-01 | Change appearance, fonts, themes, terminal behavior, keyboard shortcuts | Local settings plus some cloud preference sync | Local settings only | Keep/local |
| SET-02 | Configure AI providers, models, profiles, ACP, MCP, rules, and experiments | One 8,500-line page with provider/hosted modes interleaved | Split by intent and capability; remove hosted modes | Rebuild |
| SET-03 | Configure privacy, telemetry, crash reporting, and cloud storage | No-op telemetry plus hosted-setting vocabulary | Replace with a read-only local-first network/privacy status page | Rebuild |
| SET-04 | Teams, billing, usage plans, referrals, upgrades | Warp account/services | Remove | Remove |
| SET-05 | About, update check, release notes, diagnostics | Local info plus remote release/service URLs | Keep; network operations separately disclosed/configured | Keep/explicit |
| NET-01 | Emit telemetry, analytics, remote logs, or crash reports | Most send macros are no-op, but schemas and hooks remain | Delete runtime path and eventually schemas/call sites | Remove |
| NET-02 | Discover models and call inference | Bedrock SDK, OpenAI client, provider routing map | Rig provider registry; selected provider only | Rebuild |
| NET-03 | Open web links, web fetch/search, browser/computer use | External URLs and agent tools | Explicit user action/policy with visible destination class | Keep/explicit |
| NET-04 | Check/download updates, fonts, LSPs, runtimes, or plugins | Several independent download paths, including inherited server-root usage | Audit each destination; allow only signed/pinned, explicit maintenance paths | Audit |
| UI-01 | Use command palette, menus, keybindings, context menus, toolbar, and URI routes | Hundreds of action variants include both local and hosted intents | Retain as entry-point layer; remove every obsolete registered action | Audit |
| UI-02 | Receive notifications, toasts, modals, and banners | Local status mixed with billing/login/Oz/agent marketing | Preserve local status; remove hosted/marketing state machines | Rebuild |
| UI-03 | Accessibility, focus, mouse/hover, themes, and responsive panels | GalaxyUI view state | Preserve and cover while splitting views | Keep/local |
## First reachability findings
1. The OSS binary enabled dogfood flags, including ACP and multiple experimental local/remote UI
features. Audit cannot assume a `DOGFOOD_FLAGS` item is unreachable in OSS.
2. Telemetry send macros and collectors are no-ops, but thousands of telemetry event definitions and
call-site dependencies remain architectural glue.
3. The settings sidebar exposes Agents, Code, Appearance, Features, Keyboard shortcuts, Wormhole,
Galaxy Drive, Privacy, About, and optionally Galaxy Control. The Agents page combines Galaxy
Agent, Profiles, MCP servers, Knowledge, third-party CLI agents, Bedrock, OpenAI/LiteLLM, and
Experiments.
4. The left panel combines Project Explorer, Global Search, Galaxy Drive, and Conversation List.
Code Review is a separate right panel. This is a useful UI shell, but both panels currently import
cloud/telemetry vocabulary.
5. `WorkspaceAction` still registers login, upgrade, sharing, team Drive creation, cloud handoff,
cloud-agent setup, Oz install/launch, ambient agents, and other hosted actions alongside core tab,
pane, terminal, editor, and local-agent actions.
## Audit order
The action-level audit proceeds in this order because each later surface depends on the earlier
state boundary:
1. boot/onboarding and network initialization;
2. workspace/tabs/panes and session restoration;
3. terminal input, blocks, history, and search;
4. provider-backed agent conversation happy path;
5. tool permissions, errors, cancellation, queueing, and restore;
6. ACP parity;
7. local content library and settings;
8. editor/code review/remote development;
9. removal sweep across menus, palette, URI routes, banners, modals, flags, and tests.
The ledger is complete only when every user-visible action variant has a flow ID or has been deleted.