Update _flower-playbook.md: refresh to current flower capabilities + add a recall-first quickstart for a Solo-driven (non-brief) agent

Worker 1090 delivered. Rewrote ~/Documents/code/_flower-playbook.md (267 ins / 66 del), audited from the LIVE surface (app/Mcp/Servers/FlowerServer.php tool list, write-side tool schemas, docs/USING-FLOWER-MCP.md, CLAUDE.md, config/flower.php + AutoDispatchService — not from memory). Committed ac7f3f0 with `Brief: #195`, targeted add of only the playbook (left the catalog dir's other unrelated modified files untouched). Two headline sections as directed: (A) recall-first quickstart; (B) AUTHOR BRIEFS FOR DAEMON PICKUP (the primary ask) — ASCII lifecycle→handoff diagram (driven agent does create→update_spec→set_parent→depend→append→update_status(planned) and STOPS; orchestrator owns dispatch/claim/complete/merge), a tool table with exact args incl. the id-vs-brief_id arg gotcha + actor_ref-required-everywhere, a worked epic+3-children example with a 203⟵202⟵201 dependency chain (only 201 dispatchable), read-back via recall_briefs/recall_brief/recall_dispatch_queue, and a correctly-grounded auto_dispatch_on_planned explanation. Plus an audited 18-tool recall_* reference, a Decisions note (gated sets + follow-up chains), daemon roster/coordination, dogfooding, and gotchas. Commit is LOCAL (not pushed).

Spawned Claude doc worker proc 1090 in ~/Documents/code (Solo 23), kicked off 05:41 with the CORRECTED emphasis: brief-authoring for daemon pickup is now a first-class headline section (operator clarified this is the primary reason for the update — a driven agent should be able to author a chain/collection of briefs the daemons then execute), alongside the recall-first quickstart. Doc task — no flower branch/merge. Dispatch request #77.

Refresh `~/Documents/code/_flower-playbook.md` (OUTSIDE the flower repo — a doc edit, NOT a flower branch/merge) so a normal Solo-driven agent in another project can (a) use flower recall for awareness AND (b) **author a chain/collection of briefs for the flower daemons to pick up**. Two headline sections, both first-class: **1. Recall-first quickstart** (read-only awareness): ground at session start via recall_resume / recall_search / recall_touching / recall_file_story / recall_active / recall_open_loops; the flower MCP is globally registered (already available in Claude/Codex/Pi). **2. Authoring briefs for daemon pickup (THE PRIMARY REASON for this update).** Teach the driven agent to CAPTURE a set/chain/collection of briefs during a working session that the flower daemons then dispatch + execute. Document the WRITE side, audited against the LIVE tools (read app/Mcp/Tools/* — do NOT guess the names/args): brief_create (idea) → brief_update_spec (refine the spec) → brief_update_status (idea→refining→planned) → brief_set_parent (group children under an epic/collection) → brief_depend / brief_undepend (order a chain via dependencies) → brief_append (notes/provenance) → brief_ask / brief_answer (async operator Q&A). Note: mutating brief tools require `actor_ref` (auto-attaches the caller as a participant). Explain the lifecycle → HANDOFF clearly: the driven agent CREATES + STRUCTURES + moves briefs to **planned**; it does NOT dispatch/merge — the **orchestrator daemon** picks up planned briefs and dispatches workers (and `auto_dispatch_on_planned` briefs enqueue automatically). Include a concrete worked example: create an epic brief + 2–3 children with a dependency chain, set them planned, and note the daemons will pick them up. Cover the read-back tools too: recall_briefs / recall_brief / recall_dispatch_queue so the agent can see its briefs + their dispatch state. Then: a refreshed recall_* reference audited against the LIVE surface (app/Mcp/Tools/* + app/Mcp/Servers/*), a shorter note on Decisions (gated sets + follow-up chains) + the daemon roster/coordination, the flower_feedback dogfooding expectation, and practical gotchas (flower.test UI, MySQL-over-TCP for raw CLI, the session-map hook behind recall_active, pointer to docs/USING-FLOWER-MCP.md). Ground from the live surface, not memory. Keep it tight/skimmable. Commit with trailer `Brief: #195` if `~/Documents/code` is a git repo, else save + report. Full requirements: see the brief note (plus this corrected emphasis on brief-authoring).

Refresh `~/Documents/code/_flower-playbook.md` (OUTSIDE the flower repo — a doc edit, NOT a flower branch/merge) to flower's CURRENT capabilities, with a **recall-first quickstart on top** aimed at a normal Solo-driven agent that should be flower-aware: how to ground at session start (recall_resume / recall_search / recall_touching / recall_file_story / recall_active / recall_open_loops), that it's READ-ONLY awareness needing no brief/dispatch machinery, and that the flower MCP is globally registered (already available in Claude/Codex/Pi). Below that: a refreshed recall_* tool reference AUDITED against the LIVE surface (read app/Mcp/Tools/* + app/Mcp/Servers/*, don't guess), awareness (not usage) of the bigger systems (Briefs, Decisions incl. gated sets + follow-up chains, daemon roster/coordination, exact session↔Solo linking), the flower_feedback dogfooding expectation, and practical gotchas (flower.test UI, MySQL-over-TCP for raw CLI, the session-map hook behind recall_active, pointer to docs/USING-FLOWER-MCP.md). Ground from the live surface, not memory. Keep it tight/skimmable. Commit with trailer `Brief: #195` if `~/Documents/code` is a git repo, else save the file + report. Full requirements: see the brief note.

Refresh `~/Documents/code/_flower-playbook.md` (OUTSIDE the flower repo — a doc edit, NOT a flower branch/merge) to flower's CURRENT capabilities, with a **recall-first quickstart on top** aimed at a normal Solo-driven agent that should be flower-aware: how to ground at session start (recall_resume / recall_search / recall_touching / recall_file_story / recall_active / recall_open_loops), that it's READ-ONLY awareness needing no brief/dispatch machinery, and that the flower MCP is globally registered (already available in Claude/Codex/Pi). Below that: a refreshed recall_* tool reference AUDITED against the LIVE surface (read app/Mcp/Tools/* + app/Mcp/Servers/*, don't guess), awareness (not usage) of the bigger systems (Briefs, Decisions incl. gated sets + follow-up chains, daemon roster/coordination, exact session↔Solo linking), the flower_feedback dogfooding expectation, and practical gotchas (flower.test UI, MySQL-over-TCP for raw CLI, the session-map hook behind recall_active, pointer to docs/USING-FLOWER-MCP.md). Ground from the live surface, not memory. Keep it tight/skimmable. Commit with trailer `Brief: #195` if `~/Documents/code` is a git repo, else save the file + report. Full requirements: see the brief note.

## Ask (operator, 2026-07-04) `~/Documents/code/_flower-playbook.md` is a few days old and predates a lot of flower's current surface. The operator wants to spin up a **normal Solo-driven agent they drive** in another project right now and have it be flower-**aware** — i.e. use flower's recall MCP for cross-session memory/awareness — WITHOUT driving the brief/dispatch/daemon machinery. Update the playbook so that agent (and any future one) knows how to use flower. ## Deliverable Rewrite/refresh **`~/Documents/code/_flower-playbook.md`** in place. IMPORTANT: this file is OUTSIDE the flower git repo (it lives in the `~/Documents/code` catalog dir). This is a doc-edit task, NOT a flower branch/merge. If `~/Documents/code` is itself a git repo, commit with a clear message (trailer `Brief: #<this>`); if not, just save the file and report. Keep the existing playbook's voice/structure where still accurate; update what's stale; add what's new. Keep it tight and skimmable — it's an opt-in reference, not auto-loaded. ## Must include 1. **A "recall-first quickstart" up top** for the operator's exact use case: a Solo-driven agent in ANY project that should be flower-aware. Cover: ground at session start (`recall_resume`, `recall_search`, `recall_touching`, `recall_file_story`, `recall_active`, `recall_open_loops`), when to reach for each, that it's READ-ONLY awareness (no brief/dispatch needed), and that the flower MCP is globally registered so it is already available (Claude/Codex/Pi). Make it copy-pasteable / skimmable and place it ABOVE the daemon/orchestrator machinery. 2. **Refreshed recall_* tool reference** — the full CURRENT surface with a one-line what/when each. Audit against the LIVE tools: read `app/Mcp/Tools/*` and `app/Mcp/Servers/*` in the flower repo — do NOT guess. Include at least: recall_search, recall_resume, recall_open_loops, recall_touching, recall_file_story, recall_projects, recall_active, recall_health, recall_brief, recall_briefs, recall_dispatch_queue, recall_decisions, recall_roster, recall_signals, recall_charters, recall_inbox, recall_compaction, and flower_feedback (note any others found live). 3. **Awareness of the bigger capabilities** (so a driven agent knows they EXIST even if it won't drive them): Briefs (idea→spec→dispatch→provenance), Decisions (async operator Q&A / gated sets / follow-up chains — recently shipped), the daemon roster + coordination signals, exact session↔Solo linking, and the feedback loop. 4. **Dogfooding expectation:** file `flower_feedback` (bug/note/idea/mcp_issue) when recall is surprising/empty/wrong or you have an improvement idea. 5. **Practical notes:** flower UI at http://flower.test, the MySQL-over-TCP gotcha for raw CLI, the session-map hook that makes recall_active exact, and a pointer to `docs/USING-FLOWER-MCP.md` for the deep dive. ## How to do it well - Ground FIRST via `recall_search` on flower's own capabilities, then read (in the flower repo `/Users/mikeferrara/Documents/code/flower`): `docs/USING-FLOWER-MCP.md`, `CLAUDE.md`, `app/Mcp/Tools/*`, `app/Mcp/Servers/*`, and the current `../_flower-playbook.md`. Build the update from the LIVE surface, not memory. - Suggested structure: recall-first quickstart (operator's need) → full recall reference → awareness of briefs/decisions/daemons → dogfooding → setup/gotchas → pointer to the full doc. - Do NOT edit anything inside the flower repo (read-only there); only write the playbook file.