The approve route ran the whole fail-closed execute inline: clone(600s) + gate(1800s) + CI poll(2400s) + publish(300s) ≈ up to 85min worst case. nginx (the single :3000 entry point, ~60s read timeout) 504'd long before it finished, so the CEO's approve always appeared to fail even when the release succeeded server-side — the structured ReleaseResult was unreachable over the wire. dispatch_approve spawns the execute in a background task with a fresh session (built from the request session's engine) and the route returns 202 'accepted' immediately; _INFLIGHT_APPROVES tracks the dispatched task for observability (self-cleans via done-callback; the Redis mutex still refuses a double-execute on a second click). The panel already polls GET /proposal every 30s, so it observes the final status (COMPLETED on published/already_published, else the proposal stays open for retry); the card's approve toast now treats 'accepted' as an info 'dispatched, running in the background' instead of the old 'Release halted' warning. TDD: 2 route tests red→green (approve returns 202 'accepted' + the proposal transitions to COMPLETED / stays PENDING once the background faked execute completes; the dispatched task is awaited while the executor patch is live). 83 release tests green; ruff/mypy clean; panel typecheck+lint+format+test green.
RoboCo Control Panel
Next.js 16 control panel for the RoboCo AI agent system. Formerly a separate repository (rennf93/roboco-panel), now vendored under panel/ in this monorepo so docker compose up -d brings up the whole stack from one place.
Stack
- Next.js 16 (App Router, standalone output)
- TypeScript
- Tailwind CSS
- Radix UI primitives
dnd-kitfor drag/drop (kanban)- pnpm for package management
Running in production (the normal path)
Use the root-level Docker Compose:
# from the repo root (one level up from this directory)
docker compose up -d
The panel is built as part of the compose stack via docker/panel.Dockerfile and served internally on port 3000. Nginx (also in the compose stack) is the single externally-exposed service on http://localhost:3000 and routes:
/api/*and/ws/*→ orchestrator (FastAPI, port 8000)- everything else → the Next.js panel
The panel uses relative URLs (/api/v1, /ws) so nothing here needs a backend URL in .env.
Running the panel alone for UI development
cd panel
pnpm install
pnpm dev
That gives you Next dev-server on localhost:3000, but you still need the orchestrator reachable at localhost:8000 (or via nginx) for API calls to work. Easiest: docker compose up -d the backend services, then run pnpm dev against that.
Build scripts
pnpm dev— development server with hot reloadpnpm build— production build (outputs.next/standalone/)pnpm start— run the standalone buildpnpm lint— ESLint
Where things live
src/app/— Next.js App Router pagessrc/components/— React components (organized by feature: tasks, agents, channels, …)src/lib/api/— typed API client (thin wrappers overfetch)src/lib/— constants, utilities, WebSocket hookssrc/types/— shared TypeScript types mirroring backend schemas
Backend schema changes
When the backend changes response shapes, mirror them in src/types/ and the relevant src/lib/api/ module. Keep API paths relative so nginx routing keeps working.