Any reason we couldn't set up the brief view/detail page to allow a di

#36 (brief detail direct-dispatch v1) merged to master (dd693a8). Shipped: DispatchKind::Direct + isQueued() guard; DispatchService::dispatchDirect() + new DirectDispatchService (resolves target project/Solo scope/harness, spawns a fresh agent with the packet as launch prompt via SoloClient::spawnAgent, records a direct dispatch_request, operator-inbox heads-up only when a live orchestrator exists); SpawnDaemonBridge::resolveSoloProjectForPath extracted; brief-detail "Dispatch direct" panel (harness + worktree-grouped scope picker). Faked-Solo-seam tests (DirectDispatchServiceTest + 3 ShowTest). No migration. Suite 808 passed / 806 / 2 skip / 0 fail, pint clean, build OK. Worker 1064 closed. Unblocked v1-verification brief #103. Note: #36 also touched BriefDispatchTool.php; #171 (dispatched after this merge) branches on top, so no conflict expected.

## Goal From the brief detail, let the operator **dispatch a brief directly by spawning a fresh, dedicated agent tasked with it** — bypassing the orchestrator's queue — for the motivating case of **projects with no orchestrator daemon running**. Notify any active project orchestrator so it stays aware. ## Delivery decision — RESOLVED (Q27; operator 2026-07-03: "go with your recommendation" = Option B) Code-grounding review found the original "deliver the packet to an EXISTING idle agent via solo-cli" plan **unbuildable** on the current stack: - `app/Services/Solo/SoloClient.php` has **no `send_input`**; `SoloClient::timerSet()` is **unsupported by solo-cli 0.9.3**; the only working wake-path (`CoordinationQueue` → `DaemonSignal`) needs a **live orchestrator** to drain it — contradicting the "no orchestrator" motivation. - What **works today**: `SoloClient::spawnAgent()` / `app/Services/Daemons/SpawnDaemonBridge.php` (the existing `/roster` one-click spawn). **v1 = spawn a fresh dedicated agent tasked with the brief** (Option B). The brief dispatch packet is delivered as the **spawned agent's launch prompt** — the same mechanism the daemon-roster spawn already uses — so **no `send_input` is required**. Directly satisfies the operator's goal ("an easy way to spawn an agent directly tasked with a brief when we're not using a daemon in a project") and reuses infra that exists today. ## Scope — v1 (single dispatch): spawn-a-fresh-agent 1. **Brief detail "Dispatch direct" mode.** For a brief with a target project, let the operator choose a **harness** (reuse the `/roster` harness selector / `SoloAgentToolService` agentTool ids) and a **target Solo scope** — the project's existing worktrees / Solo projects, shown **grouped by worktree** with liveness so it's clear where the agent will land. (Reusing an existing *idle* agent is dropped from v1 — unbuildable; we spawn fresh instead.) 2. **Spawn + task.** Via `SpawnDaemonBridge` / `SoloClient::spawnAgent`, spawn a fresh agent of the chosen harness in the chosen Solo scope, with the **brief dispatch packet as its launch prompt**. Record a `dispatch_requests` row with **`kind='direct'`** — a net-new `App\Enums\DispatchKind` case (today only `Fresh`/`Resume`) — so it lands in the brief trace + dispatch history like any other dispatch. 3. **Orchestrator heads-up.** If an active orchestrator exists on the project, post an operator-inbox / daemon message (new direct task: brief #N, worktree/branch, harness, agent + `solo_process_id`). No-op when none — the motivating case. ## Out of v1 → v2 (chained, gated on verification) - **Create a NEW worktree** (from a chosen base branch) → its **own Solo project** → spawn agent there → task it (rides #22 `SpawnDaemonBridge` + worktree-manager). The remaining piece of the operator's original vision. - v2 is **blocked on the v1-verification brief #103** (already exists, depends on #36). *(v2 brief not yet created — flagged to operator.)* ## Acceptance - Brief detail offers "Dispatch direct": pick harness + target Solo scope (worktrees grouped, with liveness); available even when the project has no orchestrator. - Dispatching spawns a fresh agent with the brief packet as its launch prompt, records a `direct` dispatch_request, and notifies an active orchestrator via inbox when one exists (no-op otherwise). - Tests with a faked Solo/spawn seam (no live spawn). `php artisan test` green + `./vendor/bin/pint`. `Brief: #36` trailer. ## Provenance Operator note (#36, 2026-07-01). Scoped by flower-design; Q1/Q2 answered (2026-07-01). flower-refine folded Q1=solo-cli, then **corrected via code-grounding (2026-07-03)** — that seam doesn't exist. Delivery re-decided as **Option B (spawn fresh agent, packet-as-launch-prompt)** per operator "go with your recommendation" (2026-07-03). Shares the "spawn/task an agent" primitive with #143 (reviewer) and #39 (chat room). v1-verification = #103; v2 (new worktree + Solo project) chained after.

## Goal Let the operator dispatch a brief **directly to a specific agent** from the brief detail — bypassing the orchestrator's queue — with clear worktree grouping, and notify any active project orchestrator. Motivating case: projects **with no orchestrator daemon running**, where queuing for an orchestrator isn't viable. ## ⚠️ Delivery mechanism — Q1 RE-OPENED (grounding review 2026-07-03 found the prior decision technically wrong) The earlier spec committed to "deliver the packet to the chosen running agent via solo-cli (send_input / timer poke)." **Code grounding shows that seam does not exist:** - `app/Services/Solo/SoloClient.php` has **no `send_input`** method (only projects / agents / processes / stopProcess / spawnAgent / todos / scratchpads / kv / startCommands / timerSet). - `SoloClient::timerSet()` is **explicitly unsupported by the installed solo-cli 0.9.3** — its own comment says app code must NOT attempt wakes directly; the orchestrator drains `daemon_signals` and uses its own Solo MCP tools. - The only working "wake a running daemon" seam is `app/Services/Daemons/CoordinationQueue.php::enqueuePoke()` → a `DaemonSignal` row that a **live orchestrator holding the Solo MCP** drains and delivers. **This contradicts #36's "no orchestrator present" motivation.** - What solo-cli CAN do today is **spawn a NEW process** (`SoloClient::spawnAgent` / `app/Services/Daemons/SpawnDaemonBridge.php`) — the existing `/roster` one-click path. Net inversion: "deliver to an EXISTING idle agent with no orchestrator" is the **unbuilt/harder** capability; "spawn a fresh agent" already works. The operator's own suggested alternative (flower holding the Solo MCP via a headless harness) is the realistic path. **Decision needed (see brief_ask):** how should v1 deliver? - **(A)** flower gains its own Solo-MCP delivery — a small headless harness / delivery daemon that holds the Solo MCP to send_input/poke a target process. Best fit for the "no orchestrator" goal; new infra. - **(B)** Re-scope v1 to **spawn a fresh, dedicated agent** for the brief via the existing `spawnAgent`/`SpawnDaemonBridge` path (works today) and task it — instead of reusing an existing idle agent. Lowest new infra; overlaps v2. - **(C)** Deliver via the `CoordinationQueue`/`DaemonSignal` poke — requires a live orchestrator (defeats the motivation; only useful when one exists). ## Scope — v1 (pending the delivery decision above) 1. **Brief detail "Dispatch direct" mode.** For a brief with a target project, show that project's daemons from the roster **grouped by worktree** with liveness (live / idle / dead); idle-only selectable. (UI half is well-supported — `DaemonAgent` already carries `solo_process_id` + liveness.) 2. **Deliver the brief packet** via the chosen mechanism. Record a `dispatch_requests` row with **`kind='direct'`** — NOTE: `app/Enums/DispatchKind.php` today has only `Fresh`/`Resume`, so `direct` is a net-new enum case — so it lands in the brief trace + dispatch history like any other dispatch. 3. **Orchestrator heads-up.** If an active orchestrator exists on the project, post an operator-inbox / daemon message (new direct task on {worktree/branch}, brief #N, agent + solo_process_id). No-op when none — the motivating case. ## Follow-ups (chain already exists) - v1-verification brief **#103** (depends on #36). v2 — new-worktree + new-agent + Solo-project creation (rides #22 `SpawnDaemonBridge` + worktree-manager) — chained after verification. ## Acceptance - Brief detail offers "Dispatch direct": daemons grouped by worktree, idle-only selectable. - Delivery via the decided mechanism; records a `direct` dispatch_request; notifies an active orchestrator when present. - Tests with a faked Solo/roster seam (no live spawn). `php artisan test` green + pint. `Brief: #36` trailer. ## Provenance Operator note (#36, 2026-07-01); flower-design scoped + posted Qs; operator delegated Q1 (delivery); flower-refine folded Q1=solo-cli (2026-07-03) — **corrected 2026-07-03 by code-grounding review: that seam doesn't exist; Q1 re-opened.** Shares the "deliver to a running agent" primitive with **#143** (reviewer handoff) and **#39** (chat room) — worth ONE foundational decision, not three.

Grounding review found the prior 'deliver via solo-cli send_input/poke' plan is technically unbuildable: SoloClient has no send_input, its timerSet is unsupported by solo-cli 0.9.3, and the only working wake-path (CoordinationQueue → DaemonSignal) needs a LIVE ORCHESTRATOR to drain it — which contradicts this feature's 'no orchestrator running' motivation. How should direct-dispatch v1 deliver the brief to an agent?

## Goal Let the operator dispatch a brief **directly to a specific agent** from the brief detail — bypassing the orchestrator's queue — with clear worktree grouping, and notify any active project orchestrator. Motivating case: projects **with no orchestrator daemon running**, where queuing for an orchestrator isn't viable. ## ⚠️ Delivery mechanism — Q1 RE-OPENED (grounding review 2026-07-03 found the prior decision technically wrong) The earlier spec committed to "deliver the packet to the chosen running agent via solo-cli (send_input / timer poke)." **Code grounding shows that seam does not exist:** - `app/Services/Solo/SoloClient.php` has **no `send_input`** method (only projects / agents / processes / stopProcess / spawnAgent / todos / scratchpads / kv / startCommands / timerSet). - `SoloClient::timerSet()` is **explicitly unsupported by the installed solo-cli 0.9.3** — its own comment says app code must NOT attempt wakes directly; the orchestrator drains `daemon_signals` and uses its own Solo MCP tools. - The only working "wake a running daemon" seam is `app/Services/Daemons/CoordinationQueue.php::enqueuePoke()` → a `DaemonSignal` row that a **live orchestrator holding the Solo MCP** drains and delivers. **This contradicts #36's "no orchestrator present" motivation.** - What solo-cli CAN do today is **spawn a NEW process** (`SoloClient::spawnAgent` / `app/Services/Daemons/SpawnDaemonBridge.php`) — the existing `/roster` one-click path. Net inversion: "deliver to an EXISTING idle agent with no orchestrator" is the **unbuilt/harder** capability; "spawn a fresh agent" already works. The operator's own suggested alternative (flower holding the Solo MCP via a headless harness) is the realistic path. **Decision needed (see brief_ask):** how should v1 deliver? - **(A)** flower gains its own Solo-MCP delivery — a small headless harness / delivery daemon that holds the Solo MCP to send_input/poke a target process. Best fit for the "no orchestrator" goal; new infra. - **(B)** Re-scope v1 to **spawn a fresh, dedicated agent** for the brief via the existing `spawnAgent`/`SpawnDaemonBridge` path (works today) and task it — instead of reusing an existing idle agent. Lowest new infra; overlaps v2. - **(C)** Deliver via the `CoordinationQueue`/`DaemonSignal` poke — requires a live orchestrator (defeats the motivation; only useful when one exists). ## Scope — v1 (pending the delivery decision above) 1. **Brief detail "Dispatch direct" mode.** For a brief with a target project, show that project's daemons from the roster **grouped by worktree** with liveness (live / idle / dead); idle-only selectable. (UI half is well-supported — `DaemonAgent` already carries `solo_process_id` + liveness.) 2. **Deliver the brief packet** via the chosen mechanism. Record a `dispatch_requests` row with **`kind='direct'`** — NOTE: `app/Enums/DispatchKind.php` today has only `Fresh`/`Resume`, so `direct` is a net-new enum case — so it lands in the brief trace + dispatch history like any other dispatch. 3. **Orchestrator heads-up.** If an active orchestrator exists on the project, post an operator-inbox / daemon message (new direct task on {worktree/branch}, brief #N, agent + solo_process_id). No-op when none — the motivating case. ## Follow-ups (chain already exists) - v1-verification brief **#103** (depends on #36). v2 — new-worktree + new-agent + Solo-project creation (rides #22 `SpawnDaemonBridge` + worktree-manager) — chained after verification. ## Acceptance - Brief detail offers "Dispatch direct": daemons grouped by worktree, idle-only selectable. - Delivery via the decided mechanism; records a `direct` dispatch_request; notifies an active orchestrator when present. - Tests with a faked Solo/roster seam (no live spawn). `php artisan test` green + pint. `Brief: #36` trailer. ## Provenance Operator note (#36, 2026-07-01); flower-design scoped + posted Qs; operator delegated Q1 (delivery); flower-refine folded Q1=solo-cli (2026-07-03) — **corrected 2026-07-03 by code-grounding review: that seam doesn't exist; Q1 re-opened.** Shares the "deliver to a running agent" primitive with **#143** (reviewer handoff) and **#39** (chat room) — worth ONE foundational decision, not three.

## Goal Let the operator dispatch a brief **directly to a specific agent** from the brief detail — bypassing the orchestrator's queue — choosing an existing idle agent, with clear worktree grouping, and notify any active project orchestrator so it stays aware. Motivating case (operator): projects that **don't have an orchestrator daemon running**, where queuing for an orchestrator to pick up isn't viable. ## Scope — v1 (single dispatch): direct-to-EXISTING-idle-agent 1. **Brief detail "Dispatch direct" mode.** For a brief with a target project, show that project's daemons from the roster **grouped by worktree**, each with liveness (live / idle / dead). Only **idle** agents (not actively working) are selectable. 2. **Deliver the brief packet to the chosen agent (RESOLVED — Q1).** Push the packet directly into the chosen agent's **Solo process via `solo-cli`** — the same solo-cli bridge flower already uses for the /roster spawn feature (`SoloClient` / `SoloAgentToolService`) — rather than waiting on an orchestrator queue or the agent voluntarily polling/claiming. This satisfies the "no orchestrator present" motivation by triggering the idle agent directly. Record it as a `dispatch_request` (kind = `direct`) so it lands in the brief trace + dispatch history like any other dispatch. - Implementation note: deliver via solo-cli to the target `solo_process_id` (send_input of the brief packet, and/or a `timer_set delay_ms=0`-style poke to wake an idle agent — mirror the orchestrator poke mechanism). flower does NOT hold the Solo MCP directly; the solo-cli bridge is the delivery seam. (Operator was open to flower "holding the Solo MCP" via a headless harness; that heavier path is unnecessary for v1 since solo-cli already reaches the Solo process.) 3. **Orchestrator heads-up.** If an active orchestrator exists on the project, post an operator-inbox / daemon message: *new direct task on {worktree/branch}, brief #N, agent + Solo process id* — so it can reconcile the work when it lands. (No-op when there is no orchestrator — the motivating case.) ## Resolved decisions (operator, 2026-07-01) - **Q1 Delivery → direct-to-Solo-process via solo-cli** (operator delegated the choice; decided by flower-refine to fit the "no orchestrator" motivation and reuse existing solo-cli infra). Recorded as a `dispatch_request` kind=`direct`. - **Q2 Scope → existing-idle-agents only for v1.** New-worktree / new-agent creation is **v2**, gated behind a **v1-verification brief**. [REQUIRED follow-ups — see below.] ## Required follow-ups (operator-requested chain) - Create a **v1-verification brief** — "Verify direct-dispatch v1 works end-to-end" — **depends on #36**. - Create a **v2 brief** — "Direct dispatch v2 — new-worktree + new-agent + Solo-project creation" (rides on #22's `SpawnDaemonBridge` + worktree-manager) — **depends on the verification brief**, so v2 stays blocked until v1 is verified. (Not yet created — pending operator/orchestrator decomposition; flower-refine flagged this to the operator.) ## Acceptance - Brief detail offers "Dispatch direct"; lists the project's daemons grouped by worktree with liveness; idle-only selectable. - Delivering to a chosen agent pushes the packet to its Solo process via solo-cli, records a `direct` dispatch_request, and notifies an active orchestrator via inbox (when one exists). - Tests with a faked Solo/roster seam (no live spawn). `php artisan test` green + pint. `Brief: #36` trailer. ## Provenance Operator note (#36, 2026-07-01). Scoped + blocking Qs by flower-design (2026-07-01); answered by operator (2026-07-01, delivery delegated to the agent); answers folded in (delivery decided = solo-cli direct-to-process) + moved to planned by flower-refine (2026-07-03). Shares the "how does a message reach a running daemon" decision with **#39** (chat room).

## Goal Let the operator dispatch a brief **directly to a specific agent** from the brief detail — bypassing the orchestrator's queue — choosing an existing idle agent, with clear worktree grouping, and notify any active project orchestrator so it stays aware. Motivating case (operator): projects that **don't have an orchestrator daemon running**, where queuing for an orchestrator to pick up isn't viable. ## Scope — v1 (single dispatch): direct-to-EXISTING-idle-agent 1. **Brief detail "Dispatch direct" mode.** For a brief with a target project, show that project's daemons from the roster **grouped by worktree**, each with liveness (live / idle / dead). Only **idle** agents (not actively working) are selectable. 2. **Deliver the brief packet to the chosen agent (RESOLVED — Q1).** Push the packet directly into the chosen agent's **Solo process via `solo-cli`** — the same solo-cli bridge flower already uses for the /roster spawn feature (`SoloClient` / `SoloAgentToolService`) — rather than waiting on an orchestrator queue or the agent voluntarily polling/claiming. This satisfies the "no orchestrator present" motivation by triggering the idle agent directly. Record it as a `dispatch_request` (kind = `direct`) so it lands in the brief trace + dispatch history like any other dispatch. - Implementation note: deliver via solo-cli to the target `solo_process_id` (send_input of the brief packet, and/or a `timer_set delay_ms=0`-style poke to wake an idle agent — mirror the orchestrator poke mechanism). flower does NOT hold the Solo MCP directly; the solo-cli bridge is the delivery seam. (Operator was open to flower "holding the Solo MCP" via a headless harness; that heavier path is unnecessary for v1 since solo-cli already reaches the Solo process.) 3. **Orchestrator heads-up.** If an active orchestrator exists on the project, post an operator-inbox / daemon message: *new direct task on {worktree/branch}, brief #N, agent + Solo process id* — so it can reconcile the work when it lands. (No-op when there is no orchestrator — the motivating case.) ## Resolved decisions (operator, 2026-07-01) - **Q1 Delivery → direct-to-Solo-process via solo-cli** (operator delegated the choice; decided by flower-refine to fit the "no orchestrator" motivation and reuse existing solo-cli infra). Recorded as a `dispatch_request` kind=`direct`. - **Q2 Scope → existing-idle-agents only for v1.** New-worktree / new-agent creation is **v2**, gated behind a **v1-verification brief**. [REQUIRED follow-ups — see below.] ## Required follow-ups (operator-requested chain) - Create a **v1-verification brief** — "Verify direct-dispatch v1 works end-to-end" — **depends on #36**. - Create a **v2 brief** — "Direct dispatch v2 — new-worktree + new-agent + Solo-project creation" (rides on #22's `SpawnDaemonBridge` + worktree-manager) — **depends on the verification brief**, so v2 stays blocked until v1 is verified. (Not yet created — pending operator/orchestrator decomposition; flower-refine flagged this to the operator.) ## Acceptance - Brief detail offers "Dispatch direct"; lists the project's daemons grouped by worktree with liveness; idle-only selectable. - Delivering to a chosen agent pushes the packet to its Solo process via solo-cli, records a `direct` dispatch_request, and notifies an active orchestrator via inbox (when one exists). - Tests with a faked Solo/roster seam (no live spawn). `php artisan test` green + pint. `Brief: #36` trailer. ## Provenance Operator note (#36, 2026-07-01). Scoped + blocking Qs by flower-design (2026-07-01); answered by operator (2026-07-01, delivery delegated to the agent); answers folded in (delivery decided = solo-cli direct-to-process) + moved to planned by flower-refine (2026-07-03). Shares the "how does a message reach a running daemon" decision with **#39** (chat room).

## Goal Let the operator dispatch a brief **directly to a specific agent** from the brief detail — bypassing the orchestrator's queue — choosing an existing idle agent, with clear worktree grouping, and notify any active project orchestrator so it stays aware. ## Scope — v1 (single dispatch): direct-to-EXISTING-idle-agent The raw note describes a **multi-dispatch** feature (agent selection + new-agent spawn + new-worktree creation + Solo-project creation + orchestrator notification). v1 is scoped to the highest-leverage, lowest-new-infra slice; creation flows are deferred to v2. **v1:** 1. **Brief detail "Dispatch direct" mode.** For a brief with a target project, show that project's daemons from the roster **grouped by worktree**, each with liveness (live / idle / dead). Only **idle** agents (not actively working) are selectable. 2. **Deliver the brief packet to the chosen agent** via `‹DELIVERY MECHANISM — open question Q1›`. Record it as a `dispatch_request` (kind = `direct`) so it lands in the brief trace + dispatch history like any other dispatch. 3. **Orchestrator heads-up.** If an active orchestrator exists on the project, post an operator-inbox / daemon message: *new direct task on {worktree/branch}, brief #N, agent + Solo process id* — so it can reconcile the work when it lands. **v2 (noted, OUT of v1):** create a NEW agent of a chosen harness (reuses #22 `SpawnDaemonBridge`); create a NEW worktree from a chosen base branch → Solo project → spawn agent → task it (worktree-manager integration). The note's worktree-creation vision lives here. ## Open questions (BLOCKING — see brief_ask; brief stays `refining`) - Q1 — delivery mechanism to a running agent (flower holds no Solo MCP; it uses solo-cli). - Q2 — whether v1 includes new-worktree/new-agent creation or is existing-idle-agent only. ## Acceptance (once Q1/Q2 resolved) - Brief detail offers "Dispatch direct"; lists the project's daemons grouped by worktree with liveness; idle-only selectable. - Delivering to a chosen agent records a `direct` dispatch_request + notifies an active orchestrator via inbox. - Tests with a faked Solo/roster seam (no live spawn). `php artisan test` green + pint. `Brief: #36` trailer. ## Provenance Operator note (#36, 2026-07-01). Scoped to a v1 + blocking questions posted by flower-design (2026-07-01); worktree/agent creation deferred to v2 (rides on #22's spawn bridge). Shares the "how does a message reach a running daemon" decision with **#39** (chat room).

I'll leave this one to you, you decide on what you think makes the most sense. Part of the idea behind this feature was for projects that don't already have an orchestrator daemon running, so queuing it up for the orchestrator to pick up and dispatch isn't optimal. I'm fine with flower "holding the Solo MCP" if that's something we can do - even if it means just spawning a headless harness just to hit the MCP to trigger the agent? Thoughts?

How should a direct-dispatched brief actually reach a chosen running agent? flower does NOT hold the Solo MCP — it shells out to solo-cli. (a) push the packet into the agent's Solo process via solo-cli send_input; (b) a new 'agent inbox' the agent polls via an MCP tool; (c) create a dispatch_request the agent claims via brief_claim. Which for v1?

## Goal Let the operator dispatch a brief **directly to a specific agent** from the brief detail — bypassing the orchestrator's queue — choosing an existing idle agent, with clear worktree grouping, and notify any active project orchestrator so it stays aware. ## Scope — v1 (single dispatch): direct-to-EXISTING-idle-agent The raw note describes a **multi-dispatch** feature (agent selection + new-agent spawn + new-worktree creation + Solo-project creation + orchestrator notification). v1 is scoped to the highest-leverage, lowest-new-infra slice; creation flows are deferred to v2. **v1:** 1. **Brief detail "Dispatch direct" mode.** For a brief with a target project, show that project's daemons from the roster **grouped by worktree**, each with liveness (live / idle / dead). Only **idle** agents (not actively working) are selectable. 2. **Deliver the brief packet to the chosen agent** via `‹DELIVERY MECHANISM — open question Q1›`. Record it as a `dispatch_request` (kind = `direct`) so it lands in the brief trace + dispatch history like any other dispatch. 3. **Orchestrator heads-up.** If an active orchestrator exists on the project, post an operator-inbox / daemon message: *new direct task on {worktree/branch}, brief #N, agent + Solo process id* — so it can reconcile the work when it lands. **v2 (noted, OUT of v1):** create a NEW agent of a chosen harness (reuses #22 `SpawnDaemonBridge`); create a NEW worktree from a chosen base branch → Solo project → spawn agent → task it (worktree-manager integration). The note's worktree-creation vision lives here. ## Open questions (BLOCKING — see brief_ask; brief stays `refining`) - Q1 — delivery mechanism to a running agent (flower holds no Solo MCP; it uses solo-cli). - Q2 — whether v1 includes new-worktree/new-agent creation or is existing-idle-agent only. ## Acceptance (once Q1/Q2 resolved) - Brief detail offers "Dispatch direct"; lists the project's daemons grouped by worktree with liveness; idle-only selectable. - Delivering to a chosen agent records a `direct` dispatch_request + notifies an active orchestrator via inbox. - Tests with a faked Solo/roster seam (no live spawn). `php artisan test` green + pint. `Brief: #36` trailer. ## Provenance Operator note (#36, 2026-07-01). Scoped to a v1 + blocking questions posted by flower-design (2026-07-01); worktree/agent creation deferred to v2 (rides on #22's spawn bridge). Shares the "how does a message reach a running daemon" decision with **#39** (chat room).

Any reason we couldn't set up the brief view/detail page to allow a dispatch type that doesn't wait for dispatch from the orchestrator, rather it's dispatched directly to an agent? Where the user would have selected a project already, and they're then presented with a card/list of the agents in that project and their state (live, dead, etc) (if not actively working on something they're selectable) and allows them to choose one of those agents, or create a new agent of their selected harness. This display should break up the agents by worktrees - however you see that working out is fine, but if I choose a project with 4 worktrees I should see those worktrees represented some how and their respective agents associated with them so it's clear what worktree a brief would be getting sent to when choosing the agents, or creating them. The user should also have the ability to create a new worktree for brief to get pushed to, with it's new agent to handle it. That worktree should also get a Solo project so we can work with it easily. (thus, worktree -> solo project -> spawn agent -> task it). The user should be able to choose what branch this worktree is created from. When the work from one of these briefs is dispatched around the orchestrator/directly - if there's an active orchestrator on the project in the roster we should send it an 'inbox' message letting it know there's a new agent/worktree/task starting and what worktree/branch/brief/solo process id they're on so it can have a heads up on how to handle it when it's done/ready.

Any reason we couldn't set up the brief view/detail page to allow a dispatch type that doesn't wait for dispatch from the orchestrator, rather it's dispatched directly to an agent? Where the user would have selected a project already, and they're then presented with a card/list of the agents in that project and their state (live, dead, etc) (if not actively working on something they're selectable) and allows them to choose one of those agents, or create a new agent of their selected harness. This display should break up the agents by worktrees - however you see that working out is fine, but if I choose a project with 4 worktrees I should see those worktrees represented some how and their respective agents associated with them so it's clear what worktree a brief would be getting sent to when choosing the agents, or creating them. The user should also have the ability to create a new worktree for brief to get pushed to, with it's new agent to handle it. That worktree should also get a Solo project so we can work with it easily. (thus, worktree -> solo project -> spawn agent -> task it). The user should be able to choose what branch this worktree is created from. When the work from one of these briefs is dispatched around the orchestrator/directly - if there's an active orchestrator on the project in the roster we should send it an 'inbox' message letting it know there's a new agent/worktree/task starting and what worktree/branch/brief/solo process id they're on so it can have a heads up on how to handle it when it's done/ready.