Phase 1 — Local flower-managed agents (Solo-decoupled coordination)

✅ **Phase 1 core proof LANDED (independently verified) — 2026-07-05.** A Solo-spawned Claude (v2.1.201, Opus 4.8, Max subscription) launched `--strict-mcp-config --mcp-config flower-only.json` (only flower-over-HTTP, ZERO Solo tools) completed the full acceptance walk against scratch brief #267: 1. tool namespaces: ✅ mcp__flower__* present, mcp__solo__* ABSENT 2. daemon_checkin → ✅ roster daemon id 44 (project 16, alive) 3. recall_roster → ✅ read 4 live flower daemons + itself 4. recall_brief #267 → ✅ read 5. brief_append #267 → ✅ event 3461 6. brief_update_status #267 → in_progress ✅ Cross-checked from the orchestrator (claude-interactive): recall_roster shows daemon 44 / actor `flower-only-tester`; brief #267 shows its authored note + status change. Not self-report — verified. **Two findings (feed Phase 2):** - **A. daemon_checkin role enum is fixed** = orchestrator|ops|refine|lead|other. No custom roles (e.g. 'tester' rejected → used 'other'). - **B. Roster identity is role-derived and collapses.** Checking in with actor_ref=`flower-only-tester` + role='other' produced canonical roster actor_ref `flower-other` (one slot per role/project); the original ref is preserved in the audit trail + all brief events. **Phase 2 implication:** multiple decoupled workers sharing a role collapse to ONE roster daemon → Phase 2 needs a scheme for distinct per-worker roster identities (distinct roles, or a per-worker identity field). OPEN QUESTION for #265. **Launch recipe (Phase 1b deliverable — reusable verbatim in Phase 2):** - `flower-only.mcp.json`: `{"mcpServers":{"flower":{"type":"http","url":"http://flower.test/mcp"}}}` - Launch: `claude --strict-mcp-config --mcp-config <path>` (Solo spawn_agent tool_id=3 + extra_args `["--strict-mcp-config","--mcp-config","<path>"]`; add `--dangerously-skip-permissions` for unattended runs). - Phase 2 change: `url` → tailnet URL, add `headers.Authorization: Bearer <token>` once /mcp auth ships. Net: the decoupling thesis is proven locally. Remaining Phase 1: persist this recipe as a repo doc/script (optional) — the /mcp auth middleware stays backlogged.

Phase 1a spike results (2026-07-05, live probes by claude-interactive): - **#1 LINCHPIN ✅** — flower `/mcp` is a fully working MCP server over HTTP. `initialize` → HTTP 200 (protocol 2025-06-18, serverInfo flower/0.1.0, session id issued); `tools/list` → **69 tools** incl. recall_* / brief_* / daemon_checkin / brief_claim / recall_roster; `tools/call recall_projects` → HTTP 200 with real data. The entire architecture's transport is proven end-to-end. - **#2 auth ✅ confirmed OPEN** — no Authorization header sent on any call, all returned data; routes/ai.php:12 still reads "a future middleware/auth seam." Open is fine on loopback/local; MUST be closed before any Tailscale exposure. - **#5 client-config shape ✅** — `.mcp.json`'s `sentry` entry shows the HTTP form: `{type:"http", url:..., headers:{}}`. A flower-only agent uses `{"flower":{"type":"http","url":"http://flower.test/mcp","headers":{...}}}`. To omit Solo (which is registered GLOBALLY in ~/.claude.json), launch with `claude --strict-mcp-config --mcp-config <flower-only.json>` — strict config ignores all other MCP sources. **Net:** Phase 1 local proof needs **NO new code** — `/mcp` already serves callable tools on loopback. The auth middleware is the one code change and it's a Phase-2 (Tailscale) prerequisite, not a Phase-1-local blocker. Next: Phase 1b — construct the flower-only config + run a local decoupled-agent session against a scratch brief.

# Phase 1 — Local flower-managed agents (Solo-decoupled coordination) Parent epic: #263. **This is the start-here phase.** ## Goal A coding-agent session running **locally** (in a flower worktree, any harness) that participates as a first-class fleet member using **only flower's `/mcp`** — with **no `mcp__solo__*` configured at all**. Proves the decoupling thesis and is immediately usable for real flower work. ## Acceptance criteria An agent configured with flower's MCP over HTTP (not Solo's) can, with **zero Solo MCP tools available**: 1. Announce + stay live: `daemon_checkin` → appears in `recall_roster` / `recall_active`. 2. Take work atomically: `brief_claim` / `signal_claim` (single-writer). 3. Drive a brief: `brief_update_spec` / `brief_append` / `brief_update_status`. 4. Coordinate async: `daemon_poke` / `decision_ask` / `brief_ask`. 5. Report done: `brief_dispatch_complete` (or status → complete). Verified by inspecting the agent's MCP config (no `solo` server) and walking a real scratch brief end-to-end. ## Phase 1a — Feasibility spike (do first; cheap, mostly non-disruptive) 1. **`/mcp` serves callable tools?** curl an MCP `initialize → tools/list → tools/call` (e.g. `recall_search`) at `http://flower.test/mcp`. **LINCHPIN** — if this doesn't work, the whole approach reshapes. 2. **Auth posture on `/mcp`** — confirm it's currently open (code review said "future auth seam"); scope the tailnet-only + bearer middleware. 3. **flower.test over Tailscale** — `tailscale serve status`; is it live or still brief #110 (a Phase-2 dependency, but confirm now). 4. **Substrate liveness + real capacity** — `tailscale ping` + `ssh` R710/AMD → `pveversion` / `free -h` / `pct list` / `zfs list`. Refreshes the doc-inferred capacity numbers; feeds Phase 2. 5. **HTTP MCP client config shape** — confirm from the existing `sentry` http entry in flower `.mcp.json` how to register an HTTP MCP server (+ auth header) for a harness. 6. (Deferred — not needed for local) token-rotation cadence; ssh-wrapper spawn. ## Phase 1b — Build 1. **Add auth middleware to `/mcp`** (tailnet + bearer) — the one real prerequisite (currently a "future seam"). Keep it minimal; this unblocks both local-remote and Phase 2. 2. **Produce a "flower-only" harness MCP config** that points a local Claude Code session at flower `/mcp` and **omits Solo** (per-project `.mcp.json` or a launch profile). 3. **Run a real local session** against a scratch brief; walk the acceptance criteria above. 4. **Document the launch recipe** — this becomes the verbatim Phase 2 remote template. ## Explicitly NOT in Phase 1 - No flowerd / process supervision (Track B). - No remote/Proxmox steps beyond the read-only spike probes (#3, #4). - No Solo→flower proxy. ## Why it's valuable immediately The moment 1b works you have a **local agent that coordinates through flower and leaves a full provenance trail** — usable for real work now, and the exact substrate Phase 2 drops onto a Proxmox LXC unchanged. ## Suggested first action Run spike #1 (the `/mcp` curl) — a ~30-second local check that either green-lights everything downstream or reshapes the plan.

Start here. A LOCAL coding-agent session that participates as a first-class fleet member using ONLY flower's /mcp — zero Solo MCP. Opens with a cheap feasibility spike (does /mcp serve callable tools end-to-end? auth posture? tailnet live? real capacity?), then builds the "flower-only agent" launch recipe. Immediately dogfoodable and the exact substrate Phase 2 drops onto a Proxmox LXC. Full spec to follow.