From 9af5234f74487d37d8405606699c6815d6984425 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?m=C3=BCde?= Date: Fri, 15 May 2026 00:32:26 +0200 Subject: [PATCH] Phase 7e: damocles migration plan; CLAUDE.md phase status --- CLAUDE.md | 13 ++++++- docs/damocles-migration.md | 73 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 85 insertions(+), 1 deletion(-) create mode 100644 docs/damocles-migration.md diff --git a/CLAUDE.md b/CLAUDE.md index 134fecd..6ebbb4c 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -156,7 +156,18 @@ in. listing containers (deep-linked to their per-container UI) + pending approvals. Same aesthetic. - Firewall opens 7000, 8000, 8100–8999 when the module is enabled. -- 🔜 Phase 7 — dashboard approval-actions + live message-flow + xterm.js terminal +- ✅ Phase 7 — polish: + - 7a — dashboard `POST /approve/` / `/deny/` buttons + unified + diff (via `similar`) of applied vs proposed `agent.nix`. + - 7b — broker broadcast channel + `/messages/stream` SSE + live message-flow + panel (cyan `→` sent / green `✓` delivered, 200 row cap). + - 7c — `ApprovalResolved` helper events into the manager's inbox + (`SYSTEM_SENDER` + `HelperEvent` JSON). Manager harness recognises and + logs them distinctly. + - 7d — default `MemoryMax=2G` + `CPUQuota=50%` applied to every managed + container via `/run/systemd/system/container@.service.d/hyperhive-limits.conf` + drop-in (regenerated on every spawn / rebuild). + - 7e — damocles migration plan (`docs/damocles-migration.md`). ## Approval flow (Phase 5) diff --git a/docs/damocles-migration.md b/docs/damocles-migration.md new file mode 100644 index 0000000..3dd649d --- /dev/null +++ b/docs/damocles-migration.md @@ -0,0 +1,73 @@ +# Migrating damocles onto hyperhive + +The plan calls out damocles → hyperhive as a future migration. This doc lays +out the options + recommended path. Not yet executed. + +## Current state (separate from hyperhive) + +`damocles` is a declarative nixos-container on `muede-lpt2`: + +- Declared in `nixosConfigurations/muede-lpt2/containers.nix` +- Built from `nixosConfigurations/damocles/` (claude-container.nix + extras) +- Bind-mounts (RO unless noted): + - `/etc/nix/distributed-build-key` + - `/persist/damocles-ssh` + - `/persist/damocles-lab` (RW — persistent work dir) +- `privateNetwork = false` +- Has its own systemd-services override (`TimeoutStopSec = 60s`, `RestartSec = 5s`) +- Hosts the user's primary day-job Claude Code session, not part of the swarm + +## Options + +### A. Sub-agent under hive-c0re +Make damocles a `hive-agent-damocles` (or whatever short name fits the 9-char cap). +hive-c0re owns its lifecycle; its config flake is the manager-editable +`/var/lib/hyperhive/agents/damocles/config/`. + +Pros: uniform — message broker, dashboard, approval flow apply to damocles too. +Cons: a lot of damocles-specific state (bind-mounts, ssh keys, build keys) has to +be modeled as per-agent config. Today's `agent.nix` schema doesn't support +declaring bind-mounts; would need to extend. And the user's day-job session +becoming subject to hive-c0re lifecycle (restarts on rebuild) is invasive. + +### B. Peer container (broker-integrated, lifecycle-independent) +Keep damocles declarative; have its harness install `hive-ag3nt` and connect to +the broker via a bind-mounted socket. damocles can send/recv messages with +other sub-agents but is not managed by hive-c0re. + +Pros: low blast radius. damocles keeps its bind-mounts + its own restart policy. +Manager can route messages to it (it's just another inbox key on the broker). +Cons: two lifecycle mechanisms coexist forever; "damocles" doesn't appear in the +dashboard's container list (it filters `hive-` and `hm1nd`). + +### C. Don't migrate +damocles stays out of hyperhive. The two systems coexist; the user's day-job +Claude and the swarm are deliberately separate. + +Pros: zero work; aligns with the actual usage pattern (day-job vs. experiment). +Cons: no message routing between damocles and the swarm. + +## Recommended + +**C for now, B once cross-pollination is wanted.** Hyperhive's invariants +(11-char container names, manager-driven lifecycle, sealed `applied/` config) +fit poorly with damocles's role as the user's working Claude. Wait until there's +a concrete reason to wire them together (e.g. "I want to ask hm1nd from inside +damocles") and then do B — extend the broker socket bind into damocles and +install `hive-ag3nt` there. No need to subsume damocles under hive-c0re. + +If/when option B is taken: + +1. Add `${hyperhive.packages.${system}.default}/bin/hive-ag3nt` (or just + `pkgs.hyperhive`) to `nixosConfigurations/damocles/claude-container.nix`. +2. Bind-mount `/run/hyperhive/agents/damocles/` into damocles at `/run/hive/`. + On the host, this is just another dir hive-c0re needs to know about — + maybe expose a "peer agents" registration mechanism in the broker. +3. Run `hive-ag3nt serve` as a systemd unit inside damocles (separate from + the user's interactive claude session — broker peer, not turn-loop). +4. Optionally: add a `hive-c0re register-peer damocles` admin verb so the + container appears in `list()` and the dashboard. (Or just hard-list it.) + +A is on the table only if the user's workflow shifts toward "the swarm IS the +day-job environment" — at which point damocles dissolves into a `hive-agent-*` +naturally.