Remote agents on Proxmox: flower-proxy for Solo-equivalent tooling + coordination over tailnet

DEDUP: this seed duplicates epic #263 "Decouple agent/process management from Solo → flower-native fleet" (in_progress), which the operator's interactive session created + decomposed into children #277 (flower /mcp HTTP auth) + #278 (per-worker roster identity) — both already auto-dispatched + building tonight. #263 is the canonical epic. Do NOT plan/dispatch #279 independently; refine/operator should fold #279's extra framing (remote-worktree-as-environment tie to #275; identity/auth + coordination-parity + provisioning open questions) into #263 as follow-up children, then close #279.

## Goal (operator, 2026-07-05) Set us up to **run coding/build agents on the Proxmox homelab** (off the Mac) and have them participate in the flower fleet — check in, get dispatched, coordinate — the same way local Solo-spawned agents do. This is a **large, design-sensitive bite** → refine should PLAN and likely DECOMPOSE it (epic-lead / needs_design_loop candidate), after which the orchestrator dispatches the pieces (parallel workers authorized by the operator). ## What the investigation already established (sessions 3525–3532, 3529; 2026-07-05) - **Solo is fundamentally macOS-local** — no remote-host support; its MCP toolset (spawn, process I/O, timers) is a Mac-local plane that a remote agent CANNOT natively obtain. - **flower's MCP is already HTTP-reachable** (`Mcp::web('/mcp')`), so remote agents CAN reach flower's recall_/brief_/daemon_ surface over the tailnet. → **flower-proxy is the chosen approach**: flower brokers the coordination surface remote agents need; Solo-specific capabilities are largely irrelevant to a remote worker (they don't need spawn/PTY on the Mac). - **Attribution gap:** the Solo HTTP API has no on-behalf/actor param on write endpoints, so flower-proxying Solo *writes* can't attribute correctly — reinforces "don't proxy Solo; give remote agents the flower surface + a scoped identity." - **Already built (on master @ ~3587ff3, `bin/`):** `flower-agent` (flower-only launch wrapper, `--allowedTools` scoping e.g. daemon_checkin + recall_roster) and `provision-flower-agent-lxc.sh` (repeatable LXC build: tun passthrough, node + Claude Code + tailscale, join tailnet, install wrapper). - **Proven:** a headless Claude Code agent launched in **CT 310** over the tailnet successfully `daemon_checkin`'d into the flower roster (the earlier `flower-other` daemon 48/44 test). - **Homelab capacity:** two Proxmox nodes (R710 8c/16t/96GB; Ryzen 5800X3D/32GB/RTX4070S) — room for multiple agent LXCs. ## Open design questions for refine (before build) - Identity/auth: how a remote agent gets a **scoped flower actor identity + token** (per-agent) and what tool subset it's allowed (daemon vs worker vs full recall). - Dispatch to remote: how the orchestrator targets a remote LXC as a dispatch worktree/host — does the dispatch packet + `flower-agent` wrapper cover it, or do we need a remote-worktree model? (ties the worktree/environment-metadata brief #275 — remote envs are another isolation class.) - Coordination parity: heartbeat/reset/wind-down for remote daemons (the roster already caught a remote check-in); what breaks when a remote agent can't reach Solo (timers/pokes)? - Provisioning UX: one-command spin-up/tear-down of an agent LXC; secrets delivery (token, keys). ## Relationships - Builds on `bin/flower-agent` + `bin/provision-flower-agent-lxc.sh` (already on master). - **#275** worktree/environment isolation metadata (remote LXCs are a new environment class to track). - **#110** flower.test on tailnet (adjacent access-over-tailnet work). - homelab docs (`~/Documents/code/homelab`). ## Provenance / disposition Seeded by flower-orchestrator (2026-07-05) from the completed Proxmox-remoting investigation, per the operator's steer that this is the next big bite. **DEDUP NOTE:** if the operator already created a parallel brief for this, merge into that one. `idea` — hand to refine to plan/decompose (epic-lead or design-loop candidate); orchestrator will dispatch the pieces with parallel workers once planned.