/roster: one-click spawn & monitor flower daemons (Solo bridge, v2)

You are being dispatched from flower Brief #22: /roster: one-click spawn & monitor flower daemons (Solo bridge, v2)

Recall pointer:
- Use recall_brief with id 22 for the full folder if you need provenance.

Target:
- project: flower (/Users/mikeferrara/Documents/code/flower)
- branch: flower/roster-spawn-ui
- worktree: not specified
- kind: fresh

Current brief spec:
## Goal
Surface daemon spawning + monitoring in the flower `/roster` UI so the operator can start
orchestrator/ops/refine daemons in any project without hand-driving Solo. **v2 = one-click.**

## What's now in place (unblocked as of 2026-07-01)
- **The seam exists (Brief #26, merged):** `daemon_agents` has an `expected` status +
  `daemon_register_expected` MCP tool; `daemon_checkin` reconciles an expected (role,project)
  placeholder → live (no phantom rows); `/roster` can render a daemon as "spawning". Roster health
  degrades gracefully when only session-link data exists.
- **The spawn packet render exists (spawn-flow-ui, 973):** `/roster` already renders a filled
  charter + Solo spawn instructions from `SpawnPacketService`.
- **The Solo-bridge answer = `solo-cli`** (the non-MCP Solo bridge). flower does NOT hold the Solo
  MCP, but it CAN shell out to `solo-cli` to spawn an agent + send the kickoff.

## Scope (split)
**Backend bridge (this dispatch):**
1. Design the Solo-bridge spawn flow via `solo-cli`: given (project, role, optional charter
   override), (a) `daemon_register_expected` to show "spawning" on the roster, (b) invoke solo-cli
   to `spawn_agent` in the target Solo project, (c) deliver the rendered charter packet as the
   kickoff, (d) the daemon's own `daemon_checkin` then reconciles the expected row → live.
2. **SAFETY GATE — do NOT wire a live agent-spawn to a button without operator review.** Spawning
   agents is a real, sensitive action. First **report the bridge design + safety model via
   brief_append** (auth, how the target Solo project is resolved, guardrails: confirm before
   spawning into a project with active operator sessions, default new daemons to HOLD/no-loop-timer).
   Build + unit-test the plumbing (register-expected, packet handoff, solo-cli invocation behind a
   small service seam that can be faked in tests), but keep the actual live spawn behind the gate /
   an explicit confirm until the design is reviewed.

**UI (follow-up dispatch to design 973 after #25):** `/roster` "Spawn daemon" action (project+role+
charter preview) calling the backend bridge; monitor rows (expected/live/stale/dead, context,
needs_compaction, last checkin) + actions (poke / request-compaction / retire).

## Open questions to resolve in the design report
- How does flower authenticate to / target the right Solo project headlessly via solo-cli?
- "Go live" == arming the daemon's recurring loop timer — owned by flower or the daemon itself?

## Acceptance (backend slice)
- Bridge service + `daemon_register_expected` integration, unit-tested with a faked solo-cli seam.
- Design + safety model reported via `brief_append`; live-spawn gated pending review.
- `php artisan test` green + pint. `Brief: #22` trailer; brief_append; brief_dispatch_complete if available.

## Provenance
2026-07-01 daemon-spawn dogfood + operator ask. Prereq (Brief #26 seam) merged; v1 copy-paste skipped.

Recent/key trace events:
[6] link_added flower-orchestrator: (no body)
[7] spec_snapshot flower-orchestrator: ## Goal
Surface daemon spawning + monitoring in the flower /roster UI so the operator can start
orchestrator/ops/refine daemons in any project without hand-driving Solo. **Skip the
copy-paste v1; build the one-click v2** (operator decision, 2026-07-01).

## Background — the mechanism already exists server-side
- `SpawnPacketService` renders the full spawn packet: the filled role charter (via
  `recall_charters`) + step-by-step spawn/readiness/`daemon_checkin`/handoff instructions.
  Charters are `PromptTemplate` rows (kind=daemon_charter), editable in the prompt-library UI.
- `daemon_checkin` self-registers a daemon into the roster. Freshly-spawned agents negotiate
  the FULL flower MCP surface — verified 2026-07-01: orchestrator + refine daemons spawned
  into thedarkroom_automation registered cleanly as daemon ids 6/7.
- Today flower deliberately does NOT hold the Solo MCP (the packet says "flower is only
  rendering this packet; it does not hold Solo").

## v2 scope — one-click spawn via a Solo bridge
- /roster gains a "Spawn daemon" action: choose project + role (+ optional charter override /
  draft-body preview via `SpawnPacketService::previewCharter`).
- flower holds a **Solo bridge** (solo-cli or a Solo MCP handle) that can actually
  `spawn_agent` in the target Solo project, deliver the kickoff (charter packet), confirm
  readiness, then the daemon self-checks-in and appears live in the roster.
- Monitor: roster rows already derive live/idle/stale/dead; add context size, needs_compaction,
  last checkin, and actions (poke / request-compaction / retire).
- Guardrails: confirm before spawning into a project with active operator sessions; default
  new daemons to a HOLD posture (no autonomous loop timer) until explicitly enabled.

## Open questions
- Where does the Solo bridge live and how does flower authenticate to Solo MCP headlessly?
- "Go live" == arming the recurring loop timer — owned by flower or by the daemon itself?

## Provenance
2026-07-01 TDA daemon-spawn dogfood + operator request: "a way to fire those orchestrators up
in those projects properly prompted/instructed on their roles" + a /roster start/monitor surface.
[8] refinement flower-orchestrator: ## Goal
Surface daemon spawning + monitoring in the flower `/roster` UI so the operator can start
orchestrator/ops/refine daemons in any project without hand-driving Solo. **v2 = one-click.**

## What's now in place (unblocked as of 2026-07-01)
- **The seam exists (Brief #26, merged):** `daemon_agents` has an `expected` status +
  `daemon_register_expected` MCP tool; `daemon_checkin` reconciles an expected (role,project)
  placeholder → live (no phantom rows); `/roster` can render a daemon as "spawning". Roster health
  degrades gracefully when only session-link data exists.
- **The spawn packet render exists (spawn-flow-ui, 973):** `/roster` already renders a filled
  charter + Solo spawn instructions from `SpawnPacketService`.
- **The Solo-bridge answer = `solo-cli`** (the non-MCP Solo bridge). flower does NOT hold the Solo
  MCP, but it CAN shell out to `solo-cli` to spawn an agent + send the kickoff.

## Scope (split)
**Backend bridge (this dispatch):**
1. Design the Solo-bridge spawn flow via `solo-cli`: given (project, role, optional charter
   override), (a) `daemon_register_expected` to show "spawning" on the roster, (b) invoke solo-cli
   to `spawn_agent` in the target Solo project, (c) deliver the rendered charter packet as the
   kickoff, (d) the daemon's own `daemon_checkin` then reconciles the expected row → live.
2. **SAFETY GATE — do NOT wire a live agent-spawn to a button without operator review.** Spawning
   agents is a real, sensitive action. First **report the bridge design + safety model via
   brief_append** (auth, how the target Solo project is resolved, guardrails: confirm before
   spawning into a project with active operator sessions, default new daemons to HOLD/no-loop-timer).
   Build + unit-test the plumbing (register-expected, packet handoff, solo-cli invocation behind a
   small service seam that can be faked in tests), but keep the actual live spawn behind the gate /
   an explicit confirm until the design is reviewed.

**UI (follow-up dispatch to design 973 after #25):** `/roster` "Spawn daemon" action (project+role+
charter preview) calling the backend bridge; monitor rows (expected/live/stale/dead, context,
needs_compaction, last checkin) + actions (poke / request-compaction / retire).

## Open questions to resolve in the design report
- How does flower authenticate to / target the right Solo project headlessly via solo-cli?
- "Go live" == arming the daemon's recurring loop timer — owned by flower or the daemon itself?

## Acceptance (backend slice)
- Bridge service + `daemon_register_expected` integration, unit-tested with a faked solo-cli seam.
- Design + safety model reported via `brief_append`; live-spawn gated pending review.
- `php artisan test` green + pint. `Brief: #22` trailer; brief_append; brief_dispatch_complete if available.

## Provenance
2026-07-01 daemon-spawn dogfood + operator ask. Prereq (Brief #26 seam) merged; v1 copy-paste skipped.
[9] status_change flower-orchestrator: (no body)
[10] dispatched flower-orchestrator: Dispatch request #7 queued for flower.
[11] participant_joined flower-backend-977: (no body)
[12] note_added flower-backend-977: Bridge design + safety model (backend worker 977, before implementation):

- Target resolution/auth: flower shells out to configured solo-cli (`config("flower.solo.binary")`, optional `flower.solo.app_data_dir`) and accepts JSON only. The bridge resolves the Flower project, lists Solo projects, and requires exactly one Solo project with canonical path matching the Flower project root_path. Missing or ambiguous mappings fail closed before registering expected or spawning.
- Spawn sequence: render packet with `SpawnPacketService`, register expected with `DaemonRosterService::registerExpected`, spawn through a fakeable Solo client seam, send the packet as kickoff, then wait for the daemon to reconcile itself via `daemon_checkin`. Flower will not synthesize live status after spawn.
- Safety gate: live spawn requires explicit `confirmed=true`; dry run/plan is the default. No live spawn is wired to a roster button in this backend slice.
- Active operator guard: before confirmed spawn, inspect running Solo processes for the target Solo project and block if active operator/manual sessions are present. This implementation reports a blocker; it does not override automatically.
- HOLD/no-loop posture: kickoff tells the daemon to start in HOLD, run whoami + daemon_checkin, and not arm any recurring Solo loop timer until the operator enables it. Recurring loop ownership stays with daemon/operator review, not automatic backend spawn.
- Tests will fake Solo client behavior and assert project resolution, expected registration, packet delivery, confirmation gating, active-session blocking, and no live-status fabrication.
[13] note_added flower-backend-977: Completed backend Solo-bridge slice on branch `flower/roster-spawn-bridge`.

- Commit: `27843fa916c9f1074f96b2eb66fb201fd221a43d` (`Add daemon Solo spawn bridge`, trailer `Brief: #22`).
- Added `SpawnDaemonBridge` with non-mutating plan, explicit confirmed live spawn, path-based Solo project resolution through `solo-cli projects list`, active operator/manual process blocking through project-scoped `solo-cli processes list`, expected-daemon registration before fakeable Solo spawn, and HOLD/no-loop packet delivery.
- Extended `SoloClient` with fakeable `agents`, project-scoped `runningProcesses`, and `spawnAgent` primitives; extended `SpawnPacketService` with charter body override + HOLD packet mode.
- No route, Livewire action, or MCP live-spawn tool was wired. Live spawn remains service-gated by explicit confirmation and safety checks.
- Verification: `~/bin/php artisan test` passed (385 tests, 384 passed, 1 skipped, 2802 assertions). Pint passed on touched files.
[14] dispatched flower-backend-977: Dispatch request #7 marked done.
[15] status_change flower-backend-977: (no body)
[16] status_change flower-orchestrator: (no body)
[17] note_added flower-orchestrator: [orchestrator 969, 2026-07-01] Backend Solo-bridge slice DONE + merged (master f17d2c4, commit 27843fa): SpawnDaemonBridge (plan/confirmed-spawn), SoloClient project-scoped lookup + spawnAgent, config/flower.php solo bridge settings (block_active_operator_sessions default true), DaemonSpawnSafetyException, tests. **Live spawn is GATED — no UI/route/MCP tool wired.** Design + safety model = event 188 (review before enabling live spawn).

RE-OPENED to in_progress: the dispatch-completion rollup auto-marked the brief `complete` when the backend dispatch closed, but #22's scope still has: (1) the /roster "Spawn daemon" + monitor UI (design lane, after #25), (2) enabling the live spawn after operator review of the design report. Remaining scope tracked here.

NB (hygiene nuance for the rollup): a multi-slice brief (backend + UI) shouldn't read `complete` after just one slice's dispatch closes. Options to consider: worker should set in_progress (not complete) when more scope remains, OR each slice is its own brief. Candidate follow-up.

Recommended linked context:
{
    "todos": [],
    "scratchpads": [
        {
            "id": 346,
            "solo_scratchpad_id": "1026",
            "name": "Orchestrator HANDOFF — flower build (live state)",
            "archived": false,
            "revision": 17
        },
        {
            "id": 351,
            "solo_scratchpad_id": "1031",
            "name": "Spawn packets / charters / dispatch conventions — working notes",
            "archived": false,
            "revision": 1
        }
    ]
}

Execution notes:
- Treat the brief as the source of truth.
- Keep work scoped to this dispatch request.
- Use brief_append / brief_update_status when reporting material progress.
- Add a git commit trailer `Brief: #22` to every commit for this brief so flower can exact-link commits back to the brief.

You are being dispatched from flower Brief #22: /roster: one-click spawn & monitor flower daemons (Solo bridge, v2)

Recall pointer:
- Use recall_brief with id 22 for the full folder if you need provenance.

Target:
- project: flower (/Users/mikeferrara/Documents/code/flower)
- branch: flower/roster-spawn-bridge
- worktree: not specified
- kind: fresh

Current brief spec:
## Goal
Surface daemon spawning + monitoring in the flower `/roster` UI so the operator can start
orchestrator/ops/refine daemons in any project without hand-driving Solo. **v2 = one-click.**

## What's now in place (unblocked as of 2026-07-01)
- **The seam exists (Brief #26, merged):** `daemon_agents` has an `expected` status +
  `daemon_register_expected` MCP tool; `daemon_checkin` reconciles an expected (role,project)
  placeholder → live (no phantom rows); `/roster` can render a daemon as "spawning". Roster health
  degrades gracefully when only session-link data exists.
- **The spawn packet render exists (spawn-flow-ui, 973):** `/roster` already renders a filled
  charter + Solo spawn instructions from `SpawnPacketService`.
- **The Solo-bridge answer = `solo-cli`** (the non-MCP Solo bridge). flower does NOT hold the Solo
  MCP, but it CAN shell out to `solo-cli` to spawn an agent + send the kickoff.

## Scope (split)
**Backend bridge (this dispatch):**
1. Design the Solo-bridge spawn flow via `solo-cli`: given (project, role, optional charter
   override), (a) `daemon_register_expected` to show "spawning" on the roster, (b) invoke solo-cli
   to `spawn_agent` in the target Solo project, (c) deliver the rendered charter packet as the
   kickoff, (d) the daemon's own `daemon_checkin` then reconciles the expected row → live.
2. **SAFETY GATE — do NOT wire a live agent-spawn to a button without operator review.** Spawning
   agents is a real, sensitive action. First **report the bridge design + safety model via
   brief_append** (auth, how the target Solo project is resolved, guardrails: confirm before
   spawning into a project with active operator sessions, default new daemons to HOLD/no-loop-timer).
   Build + unit-test the plumbing (register-expected, packet handoff, solo-cli invocation behind a
   small service seam that can be faked in tests), but keep the actual live spawn behind the gate /
   an explicit confirm until the design is reviewed.

**UI (follow-up dispatch to design 973 after #25):** `/roster` "Spawn daemon" action (project+role+
charter preview) calling the backend bridge; monitor rows (expected/live/stale/dead, context,
needs_compaction, last checkin) + actions (poke / request-compaction / retire).

## Open questions to resolve in the design report
- How does flower authenticate to / target the right Solo project headlessly via solo-cli?
- "Go live" == arming the daemon's recurring loop timer — owned by flower or the daemon itself?

## Acceptance (backend slice)
- Bridge service + `daemon_register_expected` integration, unit-tested with a faked solo-cli seam.
- Design + safety model reported via `brief_append`; live-spawn gated pending review.
- `php artisan test` green + pint. `Brief: #22` trailer; brief_append; brief_dispatch_complete if available.

## Provenance
2026-07-01 daemon-spawn dogfood + operator ask. Prereq (Brief #26 seam) merged; v1 copy-paste skipped.

Recent/key trace events:
[1] participant_joined flower-orchestrator: (no body)
[2] note_added flower-orchestrator: Operator asked for a /roster surface to start + monitor orchestrator/ops/refine daemons in any project. Skip v1 copy-paste; build v2 one-click Solo bridge.
[3] plan_proposed flower-orchestrator: ## Goal
Surface daemon spawning + monitoring in the flower /roster UI so the operator can start
orchestrator/ops/refine daemons in any project without hand-driving Solo. **Skip the
copy-paste v1; build the one-click v2** (operator decision, 2026-07-01).

## Background — the mechanism already exists server-side
- `SpawnPacketService` renders the full spawn packet: the filled role charter (via
  `recall_charters`) + step-by-step spawn/readiness/`daemon_checkin`/handoff instructions.
  Charters are `PromptTemplate` rows (kind=daemon_charter), editable in the prompt-library UI.
- `daemon_checkin` self-registers a daemon into the roster. Freshly-spawned agents negotiate
  the FULL flower MCP surface — verified 2026-07-01: orchestrator + refine daemons spawned
  into thedarkroom_automation registered cleanly as daemon ids 6/7.
- Today flower deliberately does NOT hold the Solo MCP (the packet says "flower is only
  rendering this packet; it does not hold Solo").

## v2 scope — one-click spawn via a Solo bridge
- /roster gains a "Spawn daemon" action: choose project + role (+ optional charter override /
  draft-body preview via `SpawnPacketService::previewCharter`).
- flower holds a **Solo bridge** (solo-cli or a Solo MCP handle) that can actually
  `spawn_agent` in the target Solo project, deliver the kickoff (charter packet), confirm
  readiness, then the daemon self-checks-in and appears live in the roster.
- Monitor: roster rows already derive live/idle/stale/dead; add context size, needs_compaction,
  last checkin, and actions (poke / request-compaction / retire).
- Guardrails: confirm before spawning into a project with active operator sessions; default
  new daemons to a HOLD posture (no autonomous loop timer) until explicitly enabled.

## Open questions
- Where does the Solo bridge live and how does flower authenticate to Solo MCP headlessly?
- "Go live" == arming the recurring loop timer — owned by flower or by the daemon itself?

## Provenance
2026-07-01 TDA daemon-spawn dogfood + operator request: "a way to fire those orchestrators up
in those projects properly prompted/instructed on their roles" + a /roster start/monitor surface.
[4] status_change flower-orchestrator: (no body)
[5] link_added flower-orchestrator: (no body)
[6] link_added flower-orchestrator: (no body)
[7] spec_snapshot flower-orchestrator: ## Goal
Surface daemon spawning + monitoring in the flower /roster UI so the operator can start
orchestrator/ops/refine daemons in any project without hand-driving Solo. **Skip the
copy-paste v1; build the one-click v2** (operator decision, 2026-07-01).

## Background — the mechanism already exists server-side
- `SpawnPacketService` renders the full spawn packet: the filled role charter (via
  `recall_charters`) + step-by-step spawn/readiness/`daemon_checkin`/handoff instructions.
  Charters are `PromptTemplate` rows (kind=daemon_charter), editable in the prompt-library UI.
- `daemon_checkin` self-registers a daemon into the roster. Freshly-spawned agents negotiate
  the FULL flower MCP surface — verified 2026-07-01: orchestrator + refine daemons spawned
  into thedarkroom_automation registered cleanly as daemon ids 6/7.
- Today flower deliberately does NOT hold the Solo MCP (the packet says "flower is only
  rendering this packet; it does not hold Solo").

## v2 scope — one-click spawn via a Solo bridge
- /roster gains a "Spawn daemon" action: choose project + role (+ optional charter override /
  draft-body preview via `SpawnPacketService::previewCharter`).
- flower holds a **Solo bridge** (solo-cli or a Solo MCP handle) that can actually
  `spawn_agent` in the target Solo project, deliver the kickoff (charter packet), confirm
  readiness, then the daemon self-checks-in and appears live in the roster.
- Monitor: roster rows already derive live/idle/stale/dead; add context size, needs_compaction,
  last checkin, and actions (poke / request-compaction / retire).
- Guardrails: confirm before spawning into a project with active operator sessions; default
  new daemons to a HOLD posture (no autonomous loop timer) until explicitly enabled.

## Open questions
- Where does the Solo bridge live and how does flower authenticate to Solo MCP headlessly?
- "Go live" == arming the recurring loop timer — owned by flower or by the daemon itself?

## Provenance
2026-07-01 TDA daemon-spawn dogfood + operator request: "a way to fire those orchestrators up
in those projects properly prompted/instructed on their roles" + a /roster start/monitor surface.
[8] refinement flower-orchestrator: ## Goal
Surface daemon spawning + monitoring in the flower `/roster` UI so the operator can start
orchestrator/ops/refine daemons in any project without hand-driving Solo. **v2 = one-click.**

## What's now in place (unblocked as of 2026-07-01)
- **The seam exists (Brief #26, merged):** `daemon_agents` has an `expected` status +
  `daemon_register_expected` MCP tool; `daemon_checkin` reconciles an expected (role,project)
  placeholder → live (no phantom rows); `/roster` can render a daemon as "spawning". Roster health
  degrades gracefully when only session-link data exists.
- **The spawn packet render exists (spawn-flow-ui, 973):** `/roster` already renders a filled
  charter + Solo spawn instructions from `SpawnPacketService`.
- **The Solo-bridge answer = `solo-cli`** (the non-MCP Solo bridge). flower does NOT hold the Solo
  MCP, but it CAN shell out to `solo-cli` to spawn an agent + send the kickoff.

## Scope (split)
**Backend bridge (this dispatch):**
1. Design the Solo-bridge spawn flow via `solo-cli`: given (project, role, optional charter
   override), (a) `daemon_register_expected` to show "spawning" on the roster, (b) invoke solo-cli
   to `spawn_agent` in the target Solo project, (c) deliver the rendered charter packet as the
   kickoff, (d) the daemon's own `daemon_checkin` then reconciles the expected row → live.
2. **SAFETY GATE — do NOT wire a live agent-spawn to a button without operator review.** Spawning
   agents is a real, sensitive action. First **report the bridge design + safety model via
   brief_append** (auth, how the target Solo project is resolved, guardrails: confirm before
   spawning into a project with active operator sessions, default new daemons to HOLD/no-loop-timer).
   Build + unit-test the plumbing (register-expected, packet handoff, solo-cli invocation behind a
   small service seam that can be faked in tests), but keep the actual live spawn behind the gate /
   an explicit confirm until the design is reviewed.

**UI (follow-up dispatch to design 973 after #25):** `/roster` "Spawn daemon" action (project+role+
charter preview) calling the backend bridge; monitor rows (expected/live/stale/dead, context,
needs_compaction, last checkin) + actions (poke / request-compaction / retire).

## Open questions to resolve in the design report
- How does flower authenticate to / target the right Solo project headlessly via solo-cli?
- "Go live" == arming the daemon's recurring loop timer — owned by flower or the daemon itself?

## Acceptance (backend slice)
- Bridge service + `daemon_register_expected` integration, unit-tested with a faked solo-cli seam.
- Design + safety model reported via `brief_append`; live-spawn gated pending review.
- `php artisan test` green + pint. `Brief: #22` trailer; brief_append; brief_dispatch_complete if available.

## Provenance
2026-07-01 daemon-spawn dogfood + operator ask. Prereq (Brief #26 seam) merged; v1 copy-paste skipped.

Recommended linked context:
{
    "todos": [],
    "scratchpads": [
        {
            "id": 346,
            "solo_scratchpad_id": "1026",
            "name": "Orchestrator HANDOFF — flower build (live state)",
            "archived": false,
            "revision": 17
        },
        {
            "id": 351,
            "solo_scratchpad_id": "1031",
            "name": "Spawn packets / charters / dispatch conventions — working notes",
            "archived": false,
            "revision": 1
        }
    ]
}

Execution notes:
- Treat the brief as the source of truth.
- Keep work scoped to this dispatch request.
- Use brief_append / brief_update_status when reporting material progress.
- Add a git commit trailer `Brief: #22` to every commit for this brief so flower can exact-link commits back to the brief.