Redesign /decisions feed to deliver decision context (project + links + what it's about)

You are being dispatched from flower Brief #216: Redesign /decisions feed to deliver decision context (project + links + what it's about)

Recall pointer:
- Use recall_brief with id 216 for the full folder if you need provenance.

Target:
- project: flower (/Users/mikeferrara/Documents/code/flower)
- branch: flower/216-decisions-feed-design
- worktree: not specified
- kind: fresh

Current brief spec:
## Goal
Redesign the `/decisions` feed so every decision card **delivers its context inline** — project, originating brief/feedback provenance, and a plain-language "what this is about" — so a human (or agent) can answer well without leaving the page. High-leverage surface: real decisions get made in this feed.

## Operator decisions (2026-07-04)
- **Q51 — Design path:** **design-loop pass first** (produce a design doc + sequenced PR plan before building).
- **Q52 — Context source:** **structured data by default + an optional, on-demand AI summary button** (AI is not the always-on centerpiece).
- **Elaboration (event #10):** the AI button is **RAG-fed by flower's own recall** — assemble our findings (subject brief spec + recent related commits & their subjects + related sessions/segments + links) and prompt the model (deepseek via existing OpenRouter plumbing) with enough of that context that it **highlights what we should highlight**. It's a "brief me" over OUR assembled context, not a model fetching/guessing its own.

## Current state (grounded, Explore-confirmed)
- Context is ALREADY eager-loaded every board render (`app/Livewire/Decisions/Index.php:65`: `brief, subject, project, links.linkable, group, parentAnswer`), but the card face (`resources/views/components/decisions/card.blade.php`) shows only header + blocking badge + one-hop parent quote + question + affordance + "View more" flyout. Richer context (project, subject brief + spec, links, `assigned_to`/`asked_by`/type) is loaded but hidden in `detail.blade.php`.
- `DecisionAutoLinkService` (`:30`) auto-links only the subject brief — not session/feedback/commits (the polymorphic `decision_links` table supports them).
- Detail shows only brief title + 520-char spec excerpt — not the brief's own web (sessions/commits/trace/deps/participants/source-feedback/parent), which `resources/views/livewire/briefs/show.blade.php` already renders.

## Scope — three seams (for the design-loop to sequence)
1. **Display (promote):** card leads with a provenance header (project chip · "from brief #N / feedback #N / epic" · role-being-asked) + a one-glance "what this is about" (subject brief title + spec excerpt + top links) above the question + affordance. Reuse bloom `x-ui.card`/`badge` + the `briefs/show` provenance chips (`:66`/`:73`); `x-decisions.card` already supports `:view-more=false`.
2. **Capture (enrich):** extend `DecisionAutoLinkService` to link the originating session/segment, related commits, and feedback at ask time (or resolve them from the subject brief's own links) so the context list is actually populated.
3. **Depth + "Brief me" AI button:**
   - (a) extend the decision context serializer (`RecallService::decisionSummary()`, `:919`, beside `briefDetail`/`briefRelations`) to assemble the subject brief's web (sessions/commits/trace/deps/participants/source-feedback/parent) — structured, progressive (glance → expand).
   - (b) an **optional on-demand "Brief me" button** that builds a prompt from that assembled recall context (spec + recent related commits & subjects + related sessions + links) and calls the LLM (deepseek via existing OpenRouter/summarize plumbing) to HIGHLIGHT the salient points. Cache the result on the decision; surface a clear cost/latency signal; button, not auto. The LLM highlights over OUR recall — it does not fetch its own.

## What the design-loop should produce
- A design doc: redesigned card anatomy (glance state), expand/detail state, provenance-chip vocabulary, the "Brief me" button UX (loading, caching, cost signal), empty/standalone (no-subject) decision degradation, gated-set + blocking treatment, feed density.
- A sequenced PR plan across the 3 seams (Display first — highest value, mostly promoting already-loaded data; then Capture; then Depth + AI button).
- A reuse audit vs bloom UI + `briefs/show`; explicit "no regression to answer affordances."

## Acceptance
- Each card shows project + originating brief/feedback provenance + plain-language "what this is about" + role-being-asked BEFORE any click.
- "Brief me" produces a recall-grounded highlight on demand (RAG over flower's own findings), cached, with a clear cost/latency signal.
- Blocking + gated-set state obvious; deep context one expand away; answer affordances unregressed; standalone decisions degrade gracefully.

## Build path
Design-loop first (Q51). Refine stops at `planned`; the **orchestrator dispatches the design-loop** — a refine daemon does not run the multi-agent design-loop inline (it would block the heartbeat). Touch points: `Decisions\Index`, `components/decisions/{card,detail}.blade.php`, `DecisionAutoLinkService`, `RecallService::decisionSummary`/`briefDetail`/`briefRelations`, `briefs/show.blade.php`, bloom `components/ui/*`, OpenRouter/summarize plumbing (AI button). Cross-links: **#170** (dogfood decisions), **#87** (UI-feedback epic).

Recent/key trace events:
[1] participant_joined flower-refine: (no body)
[2] note_added flower-refine: Operator (2026-07-04): The **/decisions** feed presents decisions the operator must answer but delivers **no surrounding context** — it doesn't even show the **project**, let alone links to the brief / session / feedback the decision came from, or *what* the decision is asking / about / around. This feed is a **huge lever on the whole platform's usefulness** — real decisions get made here, in a feed. We should **DELIVER the context** the way an agent would brief a human (or another agent): use flower's own data + tools to surface, inline, what each decision is about — the originating brief and its spec, the project, related session/segment, feedback, the role being asked, prior answers/threads — instead of offering nothing. Goal: dramatically improve the /decisions UI/UX so a human can make each decision well without leaving the page. Refine into a concrete design direction + spec (candidate for a design-loop pass).
[3] status_change flower-refine: (no body)
[4] refinement flower-refine: **Refinement (flower-refine gen-5, 2026-07-04) — grounded current-state + design direction**

**Pivotal insight — the context is ALREADY loaded; the feed just doesn't show it.** `Decisions\Index` eager-loads `brief, subject, project, links.linkable, group, parentAnswer.decision` on every board render (`app/Livewire/Decisions/Index.php:65`), but the board **card face** (`resources/views/components/decisions/card.blade.php`) renders only: header, blocking badge, a one-hop parent quote, the question, the answer affordance, and a "View more" flyout. Everything richer — project, subject brief + spec excerpt, linked-context list, `assigned_to`/`asked_by`/type/timestamps — is loaded but hidden in the flyout (`components/decisions/detail.blade.php`) or the `/decisions/{id}` page. So a large share of the fix is **promoting already-loaded context onto the feed face**, not new plumbing.

**Two real capture/depth gaps beyond display:**
- **Capture:** `DecisionAutoLinkService` v1 (`app/Services/Briefs/DecisionAutoLinkService.php:30`) auto-links **only the subject brief** (as `reference`). It never links the originating **session/segment, commits, or feedback**, though the polymorphic `decision_links` table supports all of them. In practice the "linked context" list is empty or one row.
- **Depth:** the detail shows only the brief's **title + 520-char spec excerpt** (`detail.blade.php:103`) — not the brief's own context web (its linked sessions/commits/trace/dependencies/participants/**source feedback**/**parent epic**), which the **brief detail page already renders** (`resources/views/livewire/briefs/show.blade.php`). This is the richest untapped seam: "what the decision is about" ≈ the subject brief's provenance graph, surfaced inline.

**Context we can surface (all already modeled — Explore-confirmed):** project + room scope; subject brief (title/spec/status) + provenance chips ("from feedback #N", "epic · title" — already a pattern in `briefs/show` header, `:66`/`:73`); `decision_links` (session/segment, commits, scratchpads, feedback, related briefs); the role being asked (`assigned_to`) + asker (`asked_by`); `decision_type` + options (with `recommended`/`detail`); blocking; the answer thread (`parent_answer` → `decision_answers` chain → follow-ups); gated-set siblings + k/N.

**Proposed direction — three seams:**
1. **Display (promote):** redesign the decision card to lead with a **provenance header** (project chip · "from brief #N / feedback #N / epic" chip · role-being-asked) and a one-glance **"what this is about"** block (subject brief title + spec excerpt + top links) ABOVE the question + affordance — so the feed answers what/why/for-whom without a click. Reuse bloom `x-ui.card`/`badge` + the `briefs/show` provenance-chip pattern; `x-decisions.card` already supports embedding (`:view-more=false`).
2. **Capture (enrich auto-link):** extend `DecisionAutoLinkService` to link the originating **session/segment**, related **commits**, and **feedback** at ask time (or resolve them from the subject brief's own links), so the context list is actually populated.
3. **Depth (assemble the web):** extend the decision context serializer (`RecallService::decisionSummary()`, `:919`, beside `briefDetail`/`briefRelations`) to include the subject brief's linked sessions/commits/trace/deps/participants/source-feedback/parent — rendered progressively (glance on card → expand for full).

**Acceptance (draft):** each /decisions card shows project + originating brief/feedback provenance + a plain-language "what this is about" + the role being asked, before any click; blocking + gated-set state obvious; deep context one expand away; answer affordances unchanged/unregressed; empty/standalone (no-subject) decisions degrade gracefully.

**Build path:** strong candidate for a **design-loop pass** (writer↔reviewer → design doc + sequenced PR plan) given the UX ambition — recommend that before build. Two design decisions opened (below). Holding at `refining` pending operator direction.
[5] agent_question flower-refine: This is a UX-heavy redesign. Kick off a design-loop pass (writer↔reviewer → design doc + sequenced PR plan) before building, or go straight to a build-ready spec?
[6] agent_question flower-refine: How should each card's 'what this is about' be produced? Structured data we already have (brief spec excerpt, links, provenance chips) is instant and free; an LLM-synthesized brief-style summary reads more like an agent briefing you but adds cost/latency/staleness.
[7] participant_joined operator:mike: (no body)
[8] operator_answer operator:mike: {"choice":"Design-loop pass first (design doc + PR plan) — recommended"}
[9] operator_answer operator:mike: {"choice":"Structured + optional on-demand AI summary (button)"}
[10] note_added operator:mike: I like the idea of the button for a deepseek review/overview/summary but I'd also like to include things from our own recall-style findings - maybe that's exactly what deepseek can help highlight? Do we make sure to prompt out to deepseek with enough context and results from our recall that it can highlight what we should highlight? ie: The summary + list of recent related commits and their subject or whatever.
[11] plan_proposed flower-refine: ## Goal
Redesign the `/decisions` feed so every decision card **delivers its context inline** — project, originating brief/feedback provenance, and a plain-language "what this is about" — so a human (or agent) can answer well without leaving the page. High-leverage surface: real decisions get made in this feed.

## Operator decisions (2026-07-04)
- **Q51 — Design path:** **design-loop pass first** (produce a design doc + sequenced PR plan before building).
- **Q52 — Context source:** **structured data by default + an optional, on-demand AI summary button** (AI is not the always-on centerpiece).
- **Elaboration (event #10):** the AI button is **RAG-fed by flower's own recall** — assemble our findings (subject brief spec + recent related commits & their subjects + related sessions/segments + links) and prompt the model (deepseek via existing OpenRouter plumbing) with enough of that context that it **highlights what we should highlight**. It's a "brief me" over OUR assembled context, not a model fetching/guessing its own.

## Current state (grounded, Explore-confirmed)
- Context is ALREADY eager-loaded every board render (`app/Livewire/Decisions/Index.php:65`: `brief, subject, project, links.linkable, group, parentAnswer`), but the card face (`resources/views/components/decisions/card.blade.php`) shows only header + blocking badge + one-hop parent quote + question + affordance + "View more" flyout. Richer context (project, subject brief + spec, links, `assigned_to`/`asked_by`/type) is loaded but hidden in `detail.blade.php`.
- `DecisionAutoLinkService` (`:30`) auto-links only the subject brief — not session/feedback/commits (the polymorphic `decision_links` table supports them).
- Detail shows only brief title + 520-char spec excerpt — not the brief's own web (sessions/commits/trace/deps/participants/source-feedback/parent), which `resources/views/livewire/briefs/show.blade.php` already renders.

## Scope — three seams (for the design-loop to sequence)
1. **Display (promote):** card leads with a provenance header (project chip · "from brief #N / feedback #N / epic" · role-being-asked) + a one-glance "what this is about" (subject brief title + spec excerpt + top links) above the question + affordance. Reuse bloom `x-ui.card`/`badge` + the `briefs/show` provenance chips (`:66`/`:73`); `x-decisions.card` already supports `:view-more=false`.
2. **Capture (enrich):** extend `DecisionAutoLinkService` to link the originating session/segment, related commits, and feedback at ask time (or resolve them from the subject brief's own links) so the context list is actually populated.
3. **Depth + "Brief me" AI button:**
   - (a) extend the decision context serializer (`RecallService::decisionSummary()`, `:919`, beside `briefDetail`/`briefRelations`) to assemble the subject brief's web (sessions/commits/trace/deps/participants/source-feedback/parent) — structured, progressive (glance → expand).
   - (b) an **optional on-demand "Brief me" button** that builds a prompt from that assembled recall context (spec + recent related commits & subjects + related sessions + links) and calls the LLM (deepseek via existing OpenRouter/summarize plumbing) to HIGHLIGHT the salient points. Cache the result on the decision; surface a clear cost/latency signal; button, not auto. The LLM highlights over OUR recall — it does not fetch its own.

## What the design-loop should produce
- A design doc: redesigned card anatomy (glance state), expand/detail state, provenance-chip vocabulary, the "Brief me" button UX (loading, caching, cost signal), empty/standalone (no-subject) decision degradation, gated-set + blocking treatment, feed density.
- A sequenced PR plan across the 3 seams (Display first — highest value, mostly promoting already-loaded data; then Capture; then Depth + AI button).
- A reuse audit vs bloom UI + `briefs/show`; explicit "no regression to answer affordances."

## Acceptance
- Each card shows project + originating brief/feedback provenance + plain-language "what this is about" + role-being-asked BEFORE any click.
- "Brief me" produces a recall-grounded highlight on demand (RAG over flower's own findings), cached, with a clear cost/latency signal.
- Blocking + gated-set state obvious; deep context one expand away; answer affordances unregressed; standalone decisions degrade gracefully.

## Build path
Design-loop first (Q51). Refine stops at `planned`; the **orchestrator dispatches the design-loop** — a refine daemon does not run the multi-agent design-loop inline (it would block the heartbeat). Touch points: `Decisions\Index`, `components/decisions/{card,detail}.blade.php`, `DecisionAutoLinkService`, `RecallService::decisionSummary`/`briefDetail`/`briefRelations`, `briefs/show.blade.php`, bloom `components/ui/*`, OpenRouter/summarize plumbing (AI button). Cross-links: **#170** (dogfood decisions), **#87** (UI-feedback epic).
[12] status_change flower-refine: (no body)

Recommended linked context:
{
    "todos": [],
    "scratchpads": []
}

Execution notes:
- Treat the brief as the source of truth.
- Keep work scoped to this dispatch request.
- Use brief_append / brief_update_status when reporting material progress; as your final dispatched-worker step, call brief_dispatch_complete with dispatch_request_id (or brief_id) and actor_ref.
- Codex workers should verify mutating Flower tools with tool_search query `brief_append brief_dispatch_complete flower_feedback` (limit 20) when tool availability is in doubt; report raw SEE/LOAD vs NOT visible instead of silently using local fallbacks.
- Add a git commit trailer `Brief: #216` to every commit for this brief so flower can exact-link commits back to the brief.