Let's brainstorm/plan/spec the idea of multi-chain or even big single

Merged flower/226-epic-lead-design into master on MAIN — merge commit **e11ace2** (worker commit acdd98b). Pure-design PR: `docs/design/226-epic-lead-orchestration.md` (594 lines), docs-only diff → no suite/pint/npm/horizon needed. Design done via a real writer→adversarial-review consensus pass (reviewer caught 2 protocol blockers, both fixed: epic signals stranding across reset → null-target/epic-keyed enqueue; dead assertCanDrainOrMerge → charter carve-out only). 6 dependency-wired child briefs created (#231 A→{#232 B, #233 C, #235 E}; #233 C→#234 D; {B,C,D}→#236 F). Worker proc 1132 closed. Next: MAIN orchestrator dispatches the build slices starting with Slice A (#231, no deps) per operator directive.

**Design pass complete (flower-226-worker, dispatch #109).** **Deliverable — design doc:** `docs/design/226-epic-lead-orchestration.md` (committed `acdd98b`, trailer `Brief: #226`). Covers the full epic-lead lifecycle (spawn → own epic brief+children+isolated branch → delegate/review → merge children to epic branch → hand epic-branch→master to MAIN → bounded post-merge window → ops handoff → auto-retire), the coordination protocol (`epic_delegate`/`epic_return` on the existing `daemon_signals` queue), baton/lock semantics, the concrete spawn heuristic, worktree lifecycle, the actor_ref convention + auto-retire trigger, failure/reset behavior, a reuse audit, and the ops boundary. Designs strictly TO the three decided forks (#55/#56/#57) — none re-opened. **Deliverable — sequenced build plan (6 child briefs of #226, dependency-wired):** - **#231 Slice A** — Lead identity & roster scaffolding (`DaemonRole::Lead`, `daemon_agents.epic_brief_id`, thread epic id through the whole placeholder/identity path, `DaemonActorRef` epic segment, exclude leads from EnsureDaemons). *No deps — build first.* - **#232 Slice B** — Lead charter & spawn path (relax 3 spawn/charter guards, `leadBody()` charter, `flower:spawn-epic-lead`). *dep: A.* - **#233 Slice C** — Coordination signals `epic_delegate`/`epic_return` (2 new `KIND_*` consts, null-target/epic-keyed enqueue). *dep: A; parallel to B.* - **#234 Slice D** — Epic-branch merge + baton coexistence (child→epic-branch merge lock, `epic_return{merge}`→MAIN single merge). *dep: C.* - **#235 Slice E** — Spawn heuristic + opt-in flag (`EpicLeadPolicy`, `meta.epic_lead`, config). *dep: A.* - **#236 Slice F** — Auto-retire, post-merge window & ops handoff (cooperative retire, terminal detection, failure/reset). *dep: B, C, D.* Graph: A → {B, C, E}; C → D; {B, C, D} → F. Each targets ≤~300 lines. **Process note:** Ran a real writer→adversarial-review consensus pass (grounded infra study via 4 parallel readers, then a skeptic reviewer verifying every claim against code). Did **not** use the `/design` skill — it's frontend-oriented (both its subagents invoke `frontend-design`), a poor lens for a daemon coordination protocol. The review caught **two protocol blockers**, both now fixed in the doc: 1. **Epic signals would strand across a reset.** `excludePendingHeldForReset()` hides signals targeted at a `reset_pending` daemon, and **`reset_pending` is never cleared on close/retire** — so a daemon-targeted epic signal is hidden forever after that lead retires. Fix: enqueue epic signals **project-scoped with `target_daemon_id = null`, keyed on `payload.epic_brief_id`** → always visible → genuinely reset-robust for both lead and MAIN resets. 2. **`assertCanDrainOrMerge()` is dead code** (never called in `app/`; invariant is charter-convention only). So the lead needs **no new drain "capability"** — it can already claim its own signals; the change is a charter carve-out. Simplifies the design. Also corrected: terminal-child detection (real `BriefStatus::isTerminal()` = complete/cancelled/abandoned, and `childrenRollup()` has no `cancelled` field — derive from `by_status`); cooperative retire (lead quiesces via `daemon_winddown_ready` before MAIN's `CloseDaemon::close`, no hard-kill race); the full identity-plumbing touch-point list; the 4th (deliberately-left) role guard. **Key design decisions worth flagging (internal/reversible — did NOT open new operator forks):** - Epic signals enqueued null-target + epic-keyed (reset-robustness, above). - Lead drains only its own `epic_delegate` mailbox (epic-keyed), never general coordination; MAIN drains `epic_return`; lead re-enqueues `epic_return` idempotently for liveness (no reconciler needed). - Lead uses **direct** child dispatch (out of the project `auto_max_concurrent` accounting) with its own `epic_lead.max_concurrent` cap. - Heuristic defaults: N=3 children, phased (dep-depth≥2), fan-out, >~2h; `meta.epic_lead ∈ {auto,force,never}`; post-merge window 30min. All config-overridable. **No new operator forks opened** — the three decided forks fully constrain the material policy; remaining choices are tunable defaults or reversible internal architecture (enumerated in the doc's Open Questions). Did not merge — MAIN merges from MAIN. Pure-design PR (doc + brief creation); no suite run needed (no PHP touched).

**Plan proposed → `planned` (flower-refine, 2026-07-04)** All three blocking forks are resolved (operator answered #55/#56/#57, all to the recommended options — acked). The canonical spec now folds them in plus the post-merge-monitoring-with-boundary-vs-ops item (operator did not object, so folded in per the refinement's flag). **Recommended handoff: a design-loop** (NOT a code dispatch) to nail the detailed protocol before any build — scope is enumerated in the spec's "design-loop" section (signal kinds `epic_delegate`/`epic_return`; epic-branch-scoped merge lock vs. MAIN baton; worktree/epic-branch lifecycle; spawn-heuristic thresholds; auto-retire trigger + post-merge window + lead→ops handoff; finite-lived roster/reset semantics). **Stopping at `planned` per charter — NO auto-dispatch.** The MAIN orchestrator owns the dispatch/design-loop handoff and the single MAIN merge. Handing off.

# Epic Lead — a task-scoped, per-epic orchestrator ## Problem The MAIN orchestrator context-switches across 3–10 unrelated threads and merges an epic's pieces hours apart, between handoffs/resets. For big features / fan-out / phased builds, end-to-end "does it all fit together" cohesion degrades. A dedicated agent that holds ONE epic's whole design intent from start to retire is a real quality lever. ## Concept An ephemeral, **task-scoped "epic lead"**: a per-epic orchestrator the MAIN orchestrator spawns to own one epic (a parent brief + its children) end-to-end. It carries the whole design intent, delegates or does work itself, decides when adversarial review is warranted, keeps the pieces cohesive, optionally monitors its feature for a bounded post-merge window, then auto-retires. Distinct from the standing role daemons (orchestrator / ops / refine), which are role-scoped + long-lived — the epic lead is **task-scoped + finite-lived**. ## Resolved decisions (operator: mike, 2026-07-04 — decisions #55/#56/#57) - **Merge authority (#55):** The lead owns an **isolated epic branch** and merges children → epic branch. The **MAIN orchestrator** performs the single **epic-branch → master** merge. Preserves exactly one MAIN merge point and keeps the orchestrator baton intact. - **Infra (#56):** Build on the **existing daemon infrastructure** as a **task-scoped daemon** — reuse heartbeat/roster, make-before-break reset, compaction, wind-down, and coordination signals; `actor_ref = <project>-lead-<epic_brief_id>`; **auto-retire on epic completion**. - **When to spawn (#57):** **Heuristic + judgment** — spawn a lead for epics with ≥N children / phased / fan-out / est. multi-hour; otherwise the MAIN orchestrator decides. (Optional per-brief operator opt-in remains available.) ## Strawman shape (agreed direction) - The epic lead owns an **epic (parent) brief + its child briefs** — the epic brief is the shared durable memory — plus an **isolated worktree / epic branch**. - It **delegates/reviews like the orchestrator** (dispatch via DispatchService; adversarial review when warranted), merges children WITHIN its epic branch, and hands the final **epic-branch → master** merge back to MAIN. - **Post-merge monitoring (folded in from refinement; operator did not object):** the lead watches ITS feature's health/feedback for a **bounded window** post-merge (it already holds the context), then hands off to the **ops** daemon for ongoing monitoring, then auto-retires. Boundary: lead = bounded post-merge window for its own feature; ops = standing/ongoing. - **Communication:** reuse existing coordination signals + the epic brief as shared memory; add signal kinds `epic_delegate` (MAIN→lead) and `epic_return` (lead→MAIN) for the handoffs; the lead reports up via the queued `feedback_promote` / `daemon_poke` path (MAIN retains durability + ordering). - **Lifecycle:** MAIN spawns a lead on a qualifying epic → lead owns epic brief + children + epic branch → delegates / reviews / merges within branch → hands epic→master merge + post-window monitoring back to MAIN/ops → **auto-retires on epic completion**. ## Recommended next step: a design-loop for the detailed protocol The forks are set; the detailed protocol is a strong **design-loop** candidate. Scope for that loop: - Signal kinds `epic_delegate` / `epic_return` — payloads, ack/complete semantics, ordering. - **Baton/lock semantics:** the lead does NOT hold the MAIN orchestrator baton; it holds an **epic-branch-scoped merge lock**. Specify how epic-branch merges coexist with the MAIN baton. - **Worktree / epic-branch lifecycle:** creation, isolation, the epic-branch → master handoff, cleanup on retire. - **Spawn heuristic thresholds:** value of N children, phase/fan-out detection, multi-hour estimate, + the optional per-brief opt-in flag. - **Auto-retire trigger** (all epic children complete/merged + post-window elapsed) + post-merge monitoring window length + the lead→ops handoff. - **Finite-lived roster/reset semantics:** does a lead reset mid-epic, or wind-down + respawn? How auto-retire interacts with make-before-break reset. ## Out of scope for this brief (→ design-loop / build) Implementation of the above; new MCP tool / signal-kind schemas; DispatchService changes for lead-owned dispatch; any code. This brief captures the concept + the three resolved forks + the agreed strawman, and hands the detailed protocol to a design-loop. ## Disposition `planned`. **NO auto-dispatch** — this brief opts into a **design-loop** for the detailed protocol, and the MAIN orchestrator owns that handoff (dispatch + the single MAIN merge).

Let's brainstorm/plan/spec the idea of multi-chain or even big single briefs optionally getting assigned their own orchestrator - since it's specific to a single task/chain it doesn't need to be a daemon but I feel like there's times where something like a big feature/fan out/phased approach being all merged by the main orchestrator but over the course of hours apart sometimes and thus between handoffs and all the other work that's unrelated... it can't be the best way to build cohesive features and functionality. Rather - I feel like if we had a dedicated agent that effectively was the orchestrator for just that task and it's related work, where it could/would delegate as needed but also carry the whole general/overall idea of what needs to be done, how and make sure it all works together properly without being distracted by 3-10 other things that might be going on. Of course, it makes sense to allow the main orchestrator decide when these should be used but I'd imagine we should use them rather liberally, really. And probably some set of tools/processes/flows to describe how the orchestrator and the task-orchestrator communicate and handoff responsibilities and what not. This task orchestrator should have access to or be instructed to do similar things as the main orchestrator in that they can choose to delegate work or do it themselves, they can choose if the work warrants an adversarial review, etc. Open to thoughts, push back, improvements, etc. What would you say would be the best way to handle these sorts of longer feature builds? or even something along the lines of feature builds and then monitoring for some period of time after it's merged since it would have context and that frees up the main orchestrator from having to do that... and then being there for feedback work, before finally being retired when everything confirmed and done? Let me know what you think and what questions you might have.

**Refinement (flower-refine, 2026-07-04) — reframe + thoughts/pushback + questions** **The idea, reframed:** an ephemeral, **task-scoped "feature lead"** (a per-epic orchestrator) — spawned by the MAIN orchestrator to own ONE big feature / fan-out / phased chain end-to-end: it carries the whole design intent, delegates or does work itself, decides when adversarial review is warranted, keeps the pieces cohesive, and (optionally) monitors its feature post-merge before retiring. Distinct from the standing role daemons (orchestrator/ops/refine), which are role-scoped + long-lived; this is **task-scoped + finite-lived**. **Why it's compelling (agree):** the MAIN orchestrator context-switches across 3–10 unrelated threads and merges an epic's pieces hours apart between handoffs/resets — so "does it all fit together" cohesion degrades. A dedicated agent holding one epic's whole picture is a real quality lever, especially for phased / fan-out builds and design-loop-style features. **Grounding — what this builds on (already exists):** - **Epics already exist:** briefs have parent/child (`brief_set_parent`, child_count) — a "big feature" = an epic brief + child briefs. The feature-lead would OWN an epic brief + its children (the epic brief = shared durable memory). - **Daemon infra to reuse:** heartbeat/roster, make-before-break reset, compaction, wind-down, coordination signals (recall_signals/signal_claim/daemon_poke/feedback_promote), and dispatch (DispatchService, auto_dispatch signal, auto_max_concurrent). - **The single-merge-point invariant:** today "the active orchestrator baton gates coordination drain and MAIN merges." This is the crux tension (below). **Thoughts / pushback / improvements:** 1. **Merge authority is the central design question.** Two agents merging to MAIN = a coordination hazard. Cleanest: the lead works its epic on an **isolated worktree/epic-branch** and owns merges WITHIN that branch (children → epic branch), while the MAIN orchestrator does the single **epic-branch → master** merge (keeps one MAIN merge point + the baton intact). Alternative: full delegated merge authority scoped to the epic (more autonomy, but needs careful baton/lock semantics). → Q1. 2. **Reuse daemon infra, don't reinvent.** Even though it's "not a daemon" conceptually, if it lives for hours it needs heartbeat/roster/reset/wind-down to be visible + safe. Suggest a **task-scoped daemon**: same infra, actor_ref like `<project>-lead-<epic_brief_id>`, with a **finite lifecycle that auto-retires on epic completion**. → Q2. 3. **"Use liberally" vs. cost.** Each lead is a live agent (tokens + a Solo process + a roster slot). Fully liberal could get noisy/expensive. Suggest a **spawn heuristic** (epic with ≥N children, or a phased/fan-out/design-loop build, or est. multi-hour) + main-orch judgment + optional per-brief operator opt-in. → Q3. 4. **Post-merge monitoring is a good fit — with a boundary vs ops.** The lead has the feature's context, so having it watch its feature's health/feedback for a **bounded window** post-merge (then hand to the **ops** daemon for ongoing) is efficient and frees the main orch. Recommend: lead monitors ITS feature for a window → hands to ops → retires. (Flagging rather than asking — will fold this in unless you disagree.) 5. **Communication protocol:** reuse the existing coordination signals + the epic brief as shared memory; add signal kinds like `epic_delegate` (main→lead) and `epic_return` (lead→main) for the handoffs; the lead reports up via the same queued feedback_promote/daemon_poke path (main-orch retains durability/ordering). **Strawman shape:** a task-scoped "epic lead" daemon, spawned by main-orch for qualifying epics, owning the epic brief + children + an isolated epic branch, delegating/reviewing like the orchestrator, merging within its branch, handing the final epic→master merge + the post-window monitoring back to main-orch/ops, then auto-retiring. The detailed protocol (signal kinds, baton/lock semantics, worktree lifecycle) is a strong **design-loop** candidate once the forks below are set. Three questions opened. Holding at `refining`.

Let's brainstorm/plan/spec the idea of multi-chain or even big single briefs optionally getting assigned their own orchestrator - since it's specific to a single task/chain it doesn't need to be a daemon but I feel like there's times where something like a big feature/fan out/phased approach being all merged by the main orchestrator but over the course of hours apart sometimes and thus between handoffs and all the other work that's unrelated... it can't be the best way to build cohesive features and functionality. Rather - I feel like if we had a dedicated agent that effectively was the orchestrator for just that task and it's related work, where it could/would delegate as needed but also carry the whole general/overall idea of what needs to be done, how and make sure it all works together properly without being distracted by 3-10 other things that might be going on. Of course, it makes sense to allow the main orchestrator decide when these should be used but I'd imagine we should use them rather liberally, really. And probably some set of tools/processes/flows to describe how the orchestrator and the task-orchestrator communicate and handoff responsibilities and what not. This task orchestrator should have access to or be instructed to do similar things as the main orchestrator in that they can choose to delegate work or do it themselves, they can choose if the work warrants an adversarial review, etc. Open to thoughts, push back, improvements, etc. What would you say would be the best way to handle these sorts of longer feature builds? or even something along the lines of feature builds and then monitoring for some period of time after it's merged since it would have context and that frees up the main orchestrator from having to do that... and then being there for feedback work, before finally being retired when everything confirmed and done? Let me know what you think and what questions you might have.