UI Feedback/Requests /briefs view: 1) When/if the user clicks into/f

DECOMPOSED into 5 child briefs (this brief is now the umbrella epic). The two new /briefs-view items you added (inline dispatch button on qualifying rows; collapse the merge-into select behind a merge button) were folded into the /briefs child (#90) since they touch the same view/components. Children (all parent=#87, status=planned/dispatchable except where noted): - #90 — /briefs view UX (items 1, 9 + inline dispatch button + collapsible merge-into). Markdown editor stays separate as #81. - #91 — /roster action-button statefulness (items 3, 8). Open question filed on it re: the global-shutdown action ([8]); disable-states build regardless. - #92 — /roster daemon-row diagnostics (items 5, 6) — the concrete instance of #78's clickable-refs; build one daemon-detail route. - #93 — /roster flower PLATFORM card styling (item 7). - #94 — /roster Pipeline "+N more" expand (item 4) — follow-up to #79. Suggested build order once the fleet is back: #90 → #93 → #94 → #91 → #92. Item [2] (markdown editor) → #81.

## Summary Operator UI feedback cluster (9 items) across the `/briefs` and `/roster` views. Organized below into 5 themed groups (A–E) — each group is a natural single-worker child brief. Original item numbers preserved in [brackets]. Item [2] (markdown editor) has been moved to Brief #81 (canonical markdown-editor brief); item [5] overlaps Brief #78 (clickable refs). ## Group A — /briefs create form UX (items 1, 9) · small - **[1]** On focus of the new-brief textarea, expand its height to ~3–4× default (operator resizes it manually every time). CSS/Alpine on focus (and keep expanded while it has content); collapse when blurred+empty is fine. - **[9]** Remember the last-used **project** select on the create-new-brief form and default to it on page load (session/localStorage). Do the same for the **feedback** composer's project/target select. Reduces repetitive re-selection. - (item [2] markdown editor → **Brief #81**.) ## Group B — /roster action-button statefulness (items 3, 8) · small–medium - **[3]** Per-project card: "Turn out the lights" disabled when the project has **no active daemons**; "Water the garden" disabled when the project **already has all expected daemons running**. Drive off the roster/liveness data already on the card. - **[8]** flower PLATFORM card: "And there was light" disabled when all flower daemons are up. **Question for operator:** add a flower-side "Turn out the lights" that shuts everything down? If clicked while non-flower daemons are still live, show a FluxUI confirm ("this will ALSO shut down N project daemons: …") before proceeding. — needs operator decision on whether to build the global-shutdown action. ## Group C — /roster daemon-row diagnostics (items 5, 6) · medium · overlaps #78 - **[5]** Make the proc # / session id on a daemon row link to a **daemon detail / diagnostic view**: full activity for that daemon — every brief/item it's touched (incl. closed/finished), checkins, context history, reset/winddown state, and any readily-available metadata. Especially valuable for the orchestrator row. (This is the concrete, high-value instance of Brief #78's clickable-refs idea — coordinate so we build one daemon-detail route, not two.) - **[6]** On the daemon row, add badges/semantic signaling for DB-known states: winddown_requested, reset_state (resetting/handed_off), **reset_pending** (NOTE: reset_pending badge already shipped in Brief #86 — extend the same pattern to the other states). ## Group D — /roster flower PLATFORM card styling (item 7) · small - **[7]** The flower card currently just adds a "PLATFORM" header but is otherwise identical to project cards. Instead: drop the "PLATFORM" label, make the project name bigger, and give the card subtle distinct treatment (color/highlight — intuitive, not busy) so it visually stands apart. Add the asterisk logo mark next to "flower" in that header. ## Group E — /roster Pipeline list expand (item 4) · small · follow-up to #79 - **[4]** The Pipeline section (shipped in Brief #79) truncates to 8 with a "+1 more" hint; the orchestrator currently has 9. Make the "+N more" clickable to expand the full list (and collapse back). ## Recommended decomposition & sequencing Split into 5 children (A–E) under #87 as parent, so each is one worker-sized unit. Suggested order once the fleet is back: **A** (quick wins) → **D** (quick styling) → **E** (quick) → **B** (button state) → **C** (daemon-detail view; coordinate with #78). Awaiting operator OK on: (i) the split, (ii) the item [8] global-shutdown question. ## Constraints (all children) - bloom design system (`resources/views/components/ui/*`) + FluxUI; Livewire 4; keep `php artisan test` green; `./vendor/bin/pint`; verify in the real app. Commit trailer `Brief: #<child-id>` (or `#87` until split).

UI Feedback/Requests /briefs view: 1) When/if the user clicks into/focuses the textarea input to create a new brief (like I'm doing now) let's expand the vertical height of the textarea to something 3-4 times what it is at default, I end up having to do it every time manually. 2) Do we use a/the same markdown-supporting editor here that I've requested we use on the brief detail view? I'm fine if we don't think so since I'm just generally typing in plain text anyway - but maybe I wouldn't if we did, or... if they support inline images I could use that for copy/pasting screenshots where appropriate? 9) The create new brief form should remember (session stored?) the last value used for the project select and have that as the default on page load - it's almost always the same so it's annoying to have to re-select every time) - Same for feedback? /roster view: 3) On the project card header we've got the 'Turn out the lights' button and 'water the garden' button - we should ensure that these are responsive to the environment, ie: if there's no active daemons in that project the turn out the lights button should be properly disabled. And same with water the garden - if there's already all the daemons running in that project that button should be disabled. 4) We've added the 'Pipeline' section that gives a display of the briefs/items in that orchestrator/ops/refine agents pipeline at the time - currently the flower-orchestrator has 9 items but we show 8 in that list with a "+1 more" help text at the bottom - can we make that click-able to expand? 5) On the daemon row for each project we list the proc # and session id - do we currently have views where we could link these values to for a detailed view/summary view or something? Particularly nice would be able to click the orchestrator row/id/session for a detailed list of that orchestrators activity, including all the briefs/items it's touched, including closed/finished and really any other metadata that we've readily got as a way to kind of get a full diagnostic view of that daemon. 6) On the same daemon row - let's make sure we've got badges/cards/semantic signaling of things that are known in the database like if it's requested a shutdown/replacement or things like that. 7) On the roster view we've got the 'flower' card that has a "PLATFORM" header but other the card/presentation looks exactly the same. Rather than have that "PLATFORM" text let's make the project name bigger and otherwise style the card in a way that makes it clear it stands out/apart from the rest. Different colors or some sort of subtle highlighting - nothing too busy but something intuitively clear. Also let's use the asterisk looking thing we're using as a logo and add it there in that top header where we say 'flower' as well. 8) Let's make sure to give the "And there was light" button on the flower card is properly stateful/semantic - ie: if we have all the daemons up, it should be disabled. And - should we have a 'Turn out lights' style button/function for flower's daemons as well that ultimately shuts everything down? (when clicked, if daemons other than flower daemons are still live we should throw an alert/confirmation (fluxui) that we'll _also_ shut down those daemons) I know this is a lot - happy to break it down/apart as needed

UI Feedback/Requests /briefs view: 1) When/if the user clicks into/focuses the textarea input to create a new brief (like I'm doing now) let's expand the vertical height of the textarea to something 3-4 times what it is at default, I end up having to do it every time manually. 2) Do we use a/the same markdown-supporting editor here that I've requested we use on the brief detail view? I'm fine if we don't think so since I'm just generally typing in plain text anyway - but maybe I wouldn't if we did, or... if they support inline images I could use that for copy/pasting screenshots where appropriate? 9) The create new brief form should remember (session stored?) the last value used for the project select and have that as the default on page load - it's almost always the same so it's annoying to have to re-select every time) - Same for feedback? /roster view: 3) On the project card header we've got the 'Turn out the lights' button and 'water the garden' button - we should ensure that these are responsive to the environment, ie: if there's no active daemons in that project the turn out the lights button should be properly disabled. And same with water the garden - if there's already all the daemons running in that project that button should be disabled. 4) We've added the 'Pipeline' section that gives a display of the briefs/items in that orchestrator/ops/refine agents pipeline at the time - currently the flower-orchestrator has 9 items but we show 8 in that list with a "+1 more" help text at the bottom - can we make that click-able to expand? 5) On the daemon row for each project we list the proc # and session id - do we currently have views where we could link these values to for a detailed view/summary view or something? Particularly nice would be able to click the orchestrator row/id/session for a detailed list of that orchestrators activity, including all the briefs/items it's touched, including closed/finished and really any other metadata that we've readily got as a way to kind of get a full diagnostic view of that daemon. 6) On the same daemon row - let's make sure we've got badges/cards/semantic signaling of things that are known in the database like if it's requested a shutdown/replacement or things like that. 7) On the roster view we've got the 'flower' card that has a "PLATFORM" header but other the card/presentation looks exactly the same. Rather than have that "PLATFORM" text let's make the project name bigger and otherwise style the card in a way that makes it clear it stands out/apart from the rest. Different colors or some sort of subtle highlighting - nothing too busy but something intuitively clear. Also let's use the asterisk looking thing we're using as a logo and add it there in that top header where we say 'flower' as well. 8) Let's make sure to give the "And there was light" button on the flower card is properly stateful/semantic - ie: if we have all the daemons up, it should be disabled. And - should we have a 'Turn out lights' style button/function for flower's daemons as well that ultimately shuts everything down? (when clicked, if daemons other than flower daemons are still live we should throw an alert/confirmation (fluxui) that we'll _also_ shut down those daemons) I know this is a lot - happy to break it down/apart as needed