Worktree-isolated active work (MAIN = stable served/prod); flexible agents-per-worktree

Worktree-isolation work STARTED (orchestrator): canonical playbook symlinks added to flower base path + git-excluded; CLAUDE.md updated to document Briefs/dispatch/#19/worktree convention; worktree-manager create flags confirmed (shared mode, branch design). Next: create the flower-design worktree + Herd site, then migrate design off MAIN.

## Spec: Worktree-isolated active work (MAIN = stable served/prod) **Principle (operator's framing):** the isolation unit is the **worktree — a stream of active work / a branch — NOT the agent.** Active editing happens in worktrees; **MAIN is the stable served/prod environment** and only ever receives *merged* code. A worktree can host **one OR MORE agents** — assignment is flexible (a feature might want an orchestrator + a worker, or a backend + a UI agent collaborating on the same branch). **Why this framing:** it decouples agent count from worktree count. Isolation is BETWEEN worktrees (different features/branches never interfere); WITHIN a worktree, collaborating agents just coordinate on the shared tree (don't edit the same file at the same instant). We can add or remove agents on a worktree as the work needs, without spinning up a worktree per agent. **Problem it fixes (PROVEN today):** design editing directly in MAIN fataled all of artisan (a Livewire-reserved `dispatch()` method), taking out flower.test AND flower-ops's DB pulls — because active work lived in the served tree. Move active work into worktrees → MAIN stays stable. **Layout:** - **MAIN** — served/prod (flower.test). The orchestrator merges into it; the **ops loop monitors it read-only.** (Brief #4's original "ops needs a stable checkout" need is largely MET just by keeping active work OUT of MAIN — ops is no longer broken by active-branch churn, without needing its own checkout.) - **Worktrees** — one per active work-stream/feature: `flower-ccparse` (backend), a `flower-design` worktree + a `flower-design.test` Herd site (live bloom-UI verification against the shared DB). Semi-persistent for ongoing lanes; ephemeral (`claude -w` / worktree-manager) for bursts, removed on merge. - **Agents** — assigned to worktrees as needed; **1+ per worktree.** Standing agents keep warm domain context (refresh when they rot — design hit 250k today); spawn on-demand for fan-out. **Mechanics:** worktrees share MAIN's MySQL/Meili/Redis → coordinate via shared data; migrations from any worktree land for all (run deliberately). Served worktrees need an `.env` (DB/Meili/Reverb); the LLM/Horizon work stays on MAIN's daemons; code-only worktrees stay key-less. Push work via the Briefs dispatch pipeline (dispatch → claim → execute → auto-link). **First step:** a `flower-design` worktree + `flower-design.test` Herd site; move design's active work off MAIN.

## Spec: Agent / worktree topology — isolation + a small standing pool + on-demand spawn **Problem (PROVEN today):** active build agents working directly in MAIN break the served/"prod" environment. design's in-progress `dispatch()` (a Livewire-reserved name) collision fataled ALL of artisan — taking out flower.test AND flower-ops's DB pulls — purely because design shares MAIN's working tree. Originally framed narrowly as "the ops loop needs a stable checkout"; the real principle is broader. **Principle:** MAIN is the **stable served/prod environment** — it only ever receives *merged* code. **Every active build agent works in its OWN isolated git worktree.** The orchestrator is the single merge/coordination point. **Topology (recommended ~3 standing lanes + on-demand):** - **Backend** — Codex in `flower-ccparse` (have it). Code+tests; no served instance needed; no OpenRouter key (LLM runs on MAIN). - **Design/UI** — a Claude agent in `flower-design` + a dedicated `flower-design.test` Herd site, so it verifies bloom UI live against the shared DB without touching MAIN. - **Ops** — `flower-ops` in its own worktree tracking `master` (the stable served state), isolated from active-branch churn. - **On-demand** — for bursts (fan-out sub-tasks, research, one-off fixes): spawn a fresh agent in an ephemeral worktree (`claude -w` / worktree-manager), dispatch it a Brief, retire after. Briefs give provenance + auto-claim. **Why ~3 standing (not 1, not n):** the work clusters into backend/UI/ops; standing agents keep warm domain context but ROT (design hit 250k tokens today → need a refresh discipline); each standing agent past ~3 adds a worktree + a merge lane + tracking cost with diminishing parallelism. Scale bursts via on-demand, not standing headcount. **Mechanics:** - Worktrees share MAIN's MySQL/Meili/Redis → coordinate via shared data; migrations from any worktree land for all (run them deliberately). - Served worktrees (design) need an `.env` (DB/Meili/Reverb); the LLM/Horizon work stays on MAIN's daemons. Code-only worktrees (Codex) stay key-less. - Push work via the **Briefs dispatch pipeline** (dispatch_request → claim → execute → auto-link) — the wave model operationalized. - Refresh discipline: recycle a standing agent's context when it nears its limit; the Brief + recall carry continuity. **First step:** give design its `flower-design` worktree + `flower-design.test` Herd site; migrate it off MAIN. Then ops gets its stable worktree. (Open: final standing-lane count — operator weighing 1 vs 3 vs n; recommendation is 3 + on-demand.)

## Spec: Agent / worktree topology — isolation + a small standing pool + on-demand spawn **Problem (PROVEN today):** active build agents working directly in MAIN break the served/"prod" environment. design's in-progress `dispatch()` (a Livewire-reserved name) collision fataled ALL of artisan — taking out flower.test AND flower-ops's DB pulls — purely because design shares MAIN's working tree. Originally framed narrowly as "the ops loop needs a stable checkout"; the real principle is broader. **Principle:** MAIN is the **stable served/prod environment** — it only ever receives *merged* code. **Every active build agent works in its OWN isolated git worktree.** The orchestrator is the single merge/coordination point. **Topology (recommended ~3 standing lanes + on-demand):** - **Backend** — Codex in `flower-ccparse` (have it). Code+tests; no served instance needed; no OpenRouter key (LLM runs on MAIN). - **Design/UI** — a Claude agent in `flower-design` + a dedicated `flower-design.test` Herd site, so it verifies bloom UI live against the shared DB without touching MAIN. - **Ops** — `flower-ops` in its own worktree tracking `master` (the stable served state), isolated from active-branch churn. - **On-demand** — for bursts (fan-out sub-tasks, research, one-off fixes): spawn a fresh agent in an ephemeral worktree (`claude -w` / worktree-manager), dispatch it a Brief, retire after. Briefs give provenance + auto-claim. **Why ~3 standing (not 1, not n):** the work clusters into backend/UI/ops; standing agents keep warm domain context but ROT (design hit 250k tokens today → need a refresh discipline); each standing agent past ~3 adds a worktree + a merge lane + tracking cost with diminishing parallelism. Scale bursts via on-demand, not standing headcount. **Mechanics:** - Worktrees share MAIN's MySQL/Meili/Redis → coordinate via shared data; migrations from any worktree land for all (run them deliberately). - Served worktrees (design) need an `.env` (DB/Meili/Reverb); the LLM/Horizon work stays on MAIN's daemons. Code-only worktrees (Codex) stay key-less. - Push work via the **Briefs dispatch pipeline** (dispatch_request → claim → execute → auto-link) — the wave model operationalized. - Refresh discipline: recycle a standing agent's context when it nears its limit; the Brief + recall carry continuity. **First step:** give design its `flower-design` worktree + `flower-design.test` Herd site; migrate it off MAIN. Then ops gets its stable worktree. (Open: final standing-lane count — operator weighing 1 vs 3 vs n; recommendation is 3 + on-demand.)

Mike (2026-06-30): The flower-ops self-healing loop (proc 964) is working well — but it currently runs from a checkout shared with active build work. Merges, migrations, daemon restarts, and branch/worktree churn during feature work can disrupt the ops agent loop/flow/ability to work. Give the ops loop a dedicated, STABLE production/main worktree + environment + Solo project to run from, isolated from active development, so in-flight work in any branch/worktree never breaks its loop. Involves: a stable checkout (worktree-manager), its own Solo project scope, and pointing flower-ops 964 at it. Decision input needed from Mike on exact topology (dedicated worktree vs separate clone vs the primary MAIN reserved-as-prod).