0xWheatyz/handler
1
0
Fork 0
mirror of https://github.com/0xWheatyz/handler.git synced 2026-08-30 12:16:26 +00:00
Code Issues Packages Projects Releases Wiki Activity

feat(web): fully web-managed control plane via a DB command queue

Browse Source 
Make credentials/hosts, projects, agents, and approvals manageable from the
dashboard. The API and control layer are separate containers, so the API can't
run control actions directly (no git/tmux/claude, doesn't own the tmux
sessions). Instead the API enqueues a command and a worker in the control
container executes it and writes the result back.

Data model (migration 0003):
- `commands` queue/audit table; `forge_hosts` registry; `approvals` gains a
  nullable approver id + `actor` so operator verdicts are first-class.

Control worker:
- `control/worker.py` claims commands and dispatches to the existing control
  functions (spawn/kill/resume/record_approval/write_skills/poller.sweep),
  plus a periodic CI sweep. New `handler worker` CLI subcommand; it becomes the
  control image's default command (subsumes `poll-ci --watch`).

API:
- `require_admin` gate + `ADMIN_TOKEN`; project GET/PATCH/DELETE; agent
  spawn/kill/delete; resume now enqueues (fixes a cross-container bug where the
  API tried to send tmux keys to a session in the control container); new
  approvals/commands/hosts routes; forge-init and poll-ci enqueue endpoints.

Credentials/hosts:
- host->token-env lookup consults the `forge_hosts` registry first (built-in
  map is the fallback); `resolve()` refactored to a scheme dispatch reserving
  `db:` for a future encrypted store. Web input restricts credential_ref to
  env:/file:/db: (cmd: stays CLI-only — it would run arbitrary commands).

Dashboard:
- New tabs for projects, agents (spawn/kill with live command-status polling),
  approvals, hosts, and an activity/audit view; shared context is now writable.

Tests: +33 (queue atomicity, worker dispatch, CRUD, hosts, admin gating,
cmd: rejection, host-aware credentials, and an API->queue->worker->spawn
end-to-end). README gains a Web management section.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CrhrBToauu4L2qG6jdnuFP
This commit is contained in:
Claude
2026-07-10 16:32:45 +00:00
parent 7b5a5e3c27
commit 4f05d09c2b
31 changed files with 2277 additions and 146 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docker-compose.yml
+8 -6
View File
@@ -22,12 +22,14 @@ services:
condition: service_healthy
restart: unless-stopped
# Control layer: the `handler` CLI running the CI poller loop. Shares the database and
# the handler-data volume with the API. It waits for the API (which owns migrations),
# so RUN_MIGRATIONS is off here to avoid a startup race. Run one-shot control commands
# against the same image with, e.g., `docker compose run --rm control handler list`.
# Live agent spawning also needs `git`/`tmux` (baked in) plus bring-your-own
# `claude`/`forge` binaries — layer or mount those in.
# Control layer: the `handler` worker. Drains the control-command queue the API enqueues
# (spawn/kill/resume/approve/reject/forge-init/poll-ci) and sweeps CI on an interval.
# Shares the database and the handler-data volume with the API. It waits for the API
# (which owns migrations), so RUN_MIGRATIONS is off here to avoid a startup race. Run
# one-shot control commands against the same image with, e.g.,
# `docker compose run --rm control handler list`. Live agent spawning also needs
# `git`/`tmux` (baked in) plus bring-your-own `claude`/`forge` binaries — layer or mount
# those in.
control:
image: ghcr.io/0xwheatyz/handler/control:latest
build: