Integrate Solo API/CLI for real agent spawn destinations + configurable daemon/dispatch defaults

Checked current state: the core Solo-targeting SHIPPED via #22 (resolves the Solo project by matching flower project root_path, fail-closed) + #34 (SoloAgentToolService syncs harnesses from solo-cli w/ cache+fallback+last-chosen). Residual = configurable default destinations per role/dispatch. Left REFINING with 1 blocking fork: is #22's path-resolution enough (→ just config defaults, plannable) or do you want to target arbitrary non-flower Solo projects (→ a Solo-sourced picker + SoloDestinationService)? Not build-ready until answered.

#22 already resolves the target Solo project by matching a flower project's root_path (fail-closed on ambiguity). Is that enough — so #18's residual is just configurable default destinations per daemon role + for dispatched agents — OR do you also want to spawn/dispatch into Solo projects that are NOT in flower's registry (which needs a Solo-sourced destination picker + a cached SoloDestinationService)?

## Goal Make flower target **real Solo destinations** for spawns + dispatches, and give daemons / dispatched agents **configurable default destinations** so the operator isn't hand-picking every time. ## What already shipped (via #22 + #34) - **#22 (spawn bridge):** `SpawnDaemonBridge` resolves the target **Solo project by matching the flower project's `root_path`** against `solo-cli projects list` (fail-closed on missing/ambiguous). So a flower→Solo destination mapping already works — for flower-registered projects. - **#34 (agent tools):** `SoloAgentToolService` syncs the harness list from `solo-cli agents list` (cache + graceful fallback + persist last-chosen). The "Solo is the source of truth" pattern is established. ## Residual (this brief) — configurable defaults The un-shipped, valuable part: **configurable default destination (project + optional branch) per daemon role + for dispatched agents**, so an `ops` spawn defaults to the right target without manual entry — surfaced as the pre-selected default in the /roster spawn composer + the dispatch form, and validated against the resolvable set. Config-as-data (config/flower.php or a settings row), following #34's last-chosen pattern. ## Open question (BLOCKING — see brief_ask; brief stays `refining`) The original ask was "source destinations from Solo, not flower's own registry." #22 shipped a DIFFERENT approach (flower registry → resolve to Solo **by path**). Is that sufficient — so the residual is just **config defaults** (small, plannable) — OR do you also want to spawn/dispatch into **Solo projects that AREN'T in flower's registry** (→ a Solo-sourced destination picker + a cached `SoloDestinationService`, a bigger v1)? ## Acceptance (once the fork is resolved) - Configurable default destinations per daemon role + for dispatched agents, surfaced as the default selection + validated. - (If the Solo-sourced picker is chosen) a cached `SoloDestinationService` (solo-cli projects list + graceful fallback) feeds the pickers. - Tests with a faked Solo seam. `php artisan test` green + pint. `Brief: #18` trailer. ## Provenance Orchestrator brief #18 (2026-07-01). Core Solo-targeting shipped via #22 (path resolution) + #34 (agent-tool sync); residual = configurable defaults + a genuine design fork (flower-registered-only vs any-Solo-project). Refined + fork posted as a question by flower-design (2026-07-01).

## Spec: Solo-sourced spawn destinations + configurable defaults **Problem (Mike, 2026-07-01):** flower's spawn-flow + dispatch surfaces use flower's own project registry for "where to launch." But the real, valid spawn targets are **Solo's** projects/environments (Solo owns process spawning). flower should source destinations from Solo, not guess or reuse its own registry. ### Integrate Solo API/CLI - Use the **`solo-cli`** (the non-MCP bridge) or Solo's API to fetch the real destination list: Solo projects (+ environments where relevant) — ids / names / paths. - A `SoloDestinationService` that queries + caches the list, with config for the solo-cli path / API endpoint and a **graceful fallback** (flower's project list) when Solo is unreachable. Read-only. ### Expose the choices - **Spawn UI** (`/spawn`): the destination picker uses the Solo destination list so the rendered spawn packet targets a real Solo project. - **MCP:** where a tool takes a spawn/dispatch destination, expose/validate against Solo destinations. - **Dispatch:** map a dispatch's target project to a real Solo destination too. ### Configurable defaults - Config (config/flower.php and/or the daemon/charter configs) for **default destinations per daemon role** + for **dispatched agents**, sourced from / validated against the Solo destination list — so spawning e.g. an `ops` daemon defaults to the right Solo project without manual entry. ### Notes - flower doesn't hold Solo MCP at runtime, but the app CAN shell out to `solo-cli` or hit Solo's API. Keep it read-only (list destinations); actual spawning stays operator-mediated via the copy-paste packet. - Owner: backend for the Solo integration + config; design for wiring the destination pickers into the spawn UI (builds on the spawn-flow UI). - Related: brief #11 (daemon control plane / spawn flow), brief #17 (editable prompts). Commit trailer `Brief: #<this>`.

## Spec: Solo-sourced spawn destinations + configurable defaults **Problem (Mike, 2026-07-01):** flower's spawn-flow + dispatch surfaces use flower's own project registry for "where to launch." But the real, valid spawn targets are **Solo's** projects/environments (Solo owns process spawning). flower should source destinations from Solo, not guess or reuse its own registry. ### Integrate Solo API/CLI - Use the **`solo-cli`** (the non-MCP bridge) or Solo's API to fetch the real destination list: Solo projects (+ environments where relevant) — ids / names / paths. - A `SoloDestinationService` that queries + caches the list, with config for the solo-cli path / API endpoint and a **graceful fallback** (flower's project list) when Solo is unreachable. Read-only. ### Expose the choices - **Spawn UI** (`/spawn`): the destination picker uses the Solo destination list so the rendered spawn packet targets a real Solo project. - **MCP:** where a tool takes a spawn/dispatch destination, expose/validate against Solo destinations. - **Dispatch:** map a dispatch's target project to a real Solo destination too. ### Configurable defaults - Config (config/flower.php and/or the daemon/charter configs) for **default destinations per daemon role** + for **dispatched agents**, sourced from / validated against the Solo destination list — so spawning e.g. an `ops` daemon defaults to the right Solo project without manual entry. ### Notes - flower doesn't hold Solo MCP at runtime, but the app CAN shell out to `solo-cli` or hit Solo's API. Keep it read-only (list destinations); actual spawning stays operator-mediated via the copy-paste packet. - Owner: backend for the Solo integration + config; design for wiring the destination pickers into the spawn UI (builds on the spawn-flow UI). - Related: brief #11 (daemon control plane / spawn flow), brief #17 (editable prompts). Commit trailer `Brief: #<this>`.

Mike (2026-07-01): the spawn flow + dispatch currently use flower's own project registry for 'where to launch', but the ACTUAL valid spawn destinations (Solo projects/environments) come from Solo. Source destinations from Solo and expose them in the spawn UI + MCP where appropriate, with configurable defaults for daemons + dispatched agents from those values.