tao.chen/codespace
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: add plan for opencode acp panel and shadcn migration

Browse Source 
Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
tao.chen
2026-07-03 18:29:12 +08:00
co-authored by Claude
parent 3c6e0c3121
commit 84fa86c490
1 changed files with 87 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
plan.md
+87
View File
@@ -0,0 +1,87 @@
# 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)?