codespace/plan.md

Plan

Roadmap for the next phases of the codespace web IDE.

Now: shadcn/ui dialog and dropdown migration

The frontend still uses window.prompt, window.confirm, and an absolute-positioned <div> for the file-tree context menu. Replace these with shadcn/ui components backed by Radix UI primitives. This gives us:

• Consistent visual style for all popups
• Better keyboard navigation and accessibility
• The right-click context menu in the file tree becomes a real DropdownMenu instead of an in-place div

Concrete steps

1. Add Radix UI primitives: @radix-ui/react-dialog, @radix-ui/react-alert-dialog, @radix-ui/react-dropdown-menu.
2. Add shadcn-style wrappers under web/src/components/ui/:
   • dialog.tsx (Dialog, DialogContent, DialogHeader, DialogTitle, DialogDescription, DialogFooter)
   • alert-dialog.tsx (AlertDialog, AlertDialogContent, AlertDialogHeader, AlertDialogTitle, AlertDialogDescription, AlertDialogAction, AlertDialogCancel)
   • dropdown-menu.tsx (DropdownMenu, DropdownMenuTrigger, DropdownMenuContent, DropdownMenuItem, DropdownMenuSeparator)
   • input.tsx (used inside Dialogs for prompts)
3. Migrate the existing callers:
   • WorkspaceSelector.tsx: replace window.prompt for new-workspace with a Dialog containing an Input. Replace window.confirm for delete with an AlertDialog.
   • FileExplorerPanel.tsx: replace all window.prompt (new file, new folder, rename) with a generic Dialog + Input component parameterized by title and callback. Replace window.confirm (delete) with an AlertDialog. Replace the absolute-positioned context menu with DropdownMenu.
4. Do not change backend behavior.

Next: opencode ACP panel and integration

opencode acp exposes the editor as an Agent Client Protocol server. The current opencode process is started in the background but the user has no way to interact with it. The next phase adds a first-class ACP client panel in the web IDE.

Why

The terminal currently runs bash (the shell subsystem). The opencode process is started via the toolbar and is meant to be controlled by an ACP client — the same protocol that editors like Zed use to talk to coding agents. Without an ACP panel, the opencode process is invisible: it has a PID and a status indicator, but no way to send it prompts or read responses.

Scope

1. Backend: switch the opencode process to ACP mode

   • Change the default opencodeCommand from opencode to opencode acp (or add a new process.acpArgs config field).
   • The internal/process package already captures stdout/stderr and exposes stdin via the WebSocket. ACP over stdio maps directly onto this — no transport changes needed; the same /api/workspaces/:id/process/ws route can be used.
   • Optionally, add a thin ACP-aware layer in the service so the frontend can call high-level methods (send a prompt, cancel, get history) without speaking raw JSON-RPC.

2. Backend: ACP-aware HTTP API

   • Add a small JSON-RPC helper that speaks the ACP protocol over the existing process WS, OR add new HTTP routes per ACP method (simpler, more debuggable).
   • For v1, prefer HTTP routes per method. The frontend does not need to know JSON-RPC.
   • Routes (proposed):
     • POST /api/workspaces/:id/acp/prompt — body { content: string }, streams or returns the agent's response.
     • POST /api/workspaces/:id/acp/cancel — cancel an in-flight prompt.
     • GET /api/workspaces/:id/acp/history — return past messages.
     • GET /api/workspaces/:id/acp/status — return agent readiness.

3. Frontend: ACP panel

   • A new AcpPanel component, placed next to the terminal in the bottom panel group.
   • Chat-like UI: a scrollable list of user/agent message bubbles, an input box at the bottom, a "send" button (Cmd/Ctrl+Enter), a "cancel" button while a request is in flight.
   • Show the agent's "thinking" indicator while waiting, the response text on completion, and any tool-call invocations inline.
   • Use useAcpStatus, useAcpHistory, useAcpSend, useAcpCancel hooks (mirror the existing API-hook pattern).
   • Render markdown (use a small library like react-markdown with a code highlighter) so code blocks look right.
   • On the first response, fetch history to populate the list (since ACP may already have context from the start of the process).

4. Frontend: integration with the workspace shell

   • The bottom panel group currently has EditorPanel on top and TerminalPanel on bottom (only when visible).
   • Add a third tab/panel for AcpPanel next to the terminal, or make the bottom panel a tabbed area (Terminal / Agent).
   • Status bar shows the agent status alongside the opencode running status.

Concrete tasks (rough, to be expanded into a full plan when we start)

1. Switch opencodeCommand default to opencode acp; document the change in README.md.
2. Add internal/acp package: ACP JSON-RPC client, speaks stdio to the opencode process. Or use a Go ACP SDK if one exists.
3. Add internal/api/acp_handler.go with the four routes above.
4. Add web/src/lib/api/acp.ts with the four hooks.
5. Add web/src/components/acp/AcpPanel.tsx and supporting subcomponents (MessageBubble, PromptInput, ToolCallBlock).
6. Add react-markdown and a code highlighter (react-syntax-highlighter or shiki) to web/package.json.
7. Wire the ACP panel into WorkspaceShell.tsx as a tabbed bottom panel.
8. Document the ACP routes in README.md.

Out of scope (for v1)

• Streaming responses (use a single round-trip per prompt; add SSE or stream-over-WS later).
• Tool-call approval UI (rely on the agent's own sandboxing for v1; the user can interrupt if it does something wrong).
• Multiple agents / agent switching.
• Authentication.
• Cross-workspace agent memory.
• ACP session persistence across opencode restarts (lose context on restart; accept this for v1).

Open questions to resolve before implementation

• Does the opencode ACP server expect framing on stdio (LSP-style Content-Length: headers) or newline-delimited JSON? (Will check when we start.)
• Should the ACP panel replace the terminal in the bottom area, or live as a sibling tab?
• Do we want the ACP panel to share the bottom area with the terminal (tabs), or always be visible alongside it (split)?