Feedback visibility/surfacing items needing operator action Let's do

You are being dispatched from flower Brief #156: Feedback visibility/surfacing items needing operator action

Let's do

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

Target:
- project: flower (/Users/mikeferrara/Documents/code/flower)
- branch: flower/156-feedback-visibility
- worktree: not specified
- kind: fresh

Current brief spec:
## Goal
Make feedback that **needs operator action** visible and easy to find (mirror the Open Questions nav pattern), and make the **feedback status model legible** so the operator knows which items they must act on vs. which the daemons handle autonomously.

## Grounded status model (current — `App\Models\Feedback` + `App\Services\Feedback\FeedbackPromotionService`)
**Kinds** (`FeedbackKind`): `bug`, `note`, `idea`, `mcp_issue`.
**Statuses** (`Feedback::STATUSES`): `open` (new/untriaged) → `triaged` → `planned` (promoted to a brief or routed to the orchestrator) → resolved: `addressed` | `wontfix` | `duplicate`.
**Who acts (the funnel):**
- `note` → self-handled → `addressed`. **No operator action.**
- `bug` / `mcp_issue` / sentry-sourced → **AUTONOMOUS (Funnel B)** → promoted to a brief (no approval) or routed to the orchestrator (todo + fix-spec) → `planned`. **No operator action.**
- `idea` (and feature / changed-functionality signals) → **OPERATOR-GATED (Funnel A)** → promoted to a brief with `needs_operator_approval=true` (draft, non-dispatchable); the operator must approve (`FeedbackPromotionService::approveBrief`) before it can dispatch. **← the only bucket that needs operator action.**

So **"needs operator action" = feedback whose promotion produced an operator-gated brief still pending approval** (Funnel A / idea-class).

## Scope
1. **Nav "needs action" count + badge + link** — mirror `BriefQuestion::openCount()` / the Open Questions badge: a single source of truth (e.g. `Feedback::needsOperatorActionCount()` or a `briefs.needs_operator_approval` count) feeding the nav badge, broadcast on change (like `OpenQuestionsChanged`). Clicking → the `/feedback` view filtered to the needs-action set.
2. **/feedback filter** for "needs my action" (the operator-gated pending-approval set), alongside the existing kind/status filters.
3. **Status legend / help on `/feedback`** — a short inline legend explaining each status + which kinds are autonomous vs operator-gated + what the operator is expected to do (approve/reject the gated ones). Directly resolves the "I'm confused which items I act on" ask.

## Decision (defaulted — adjust if desired)
"Needs action" is scoped to **operator-gated briefs pending approval** (recommended — it's the only set the funnel actually requires the operator to touch). If you also want `open`/untriaged feedback surfaced (e.g. as a health signal for when the autonomous triage loop is down), add it as a **secondary** count rather than folding it into the primary badge. Defaulting to the former.

## Acceptance
- Nav shows a feedback "needs action" badge/count (single source of truth + live update) linking to the filtered `/feedback` view; count = operator-gated briefs pending approval.
- `/feedback` has a "needs my action" filter + a status legend explaining the model and who acts.
- Tests: the count excludes autonomous/resolved and includes only pending operator-gated; the filter works. `php artisan test` green + `./vendor/bin/pint`. `Brief: #156` trailer.

## Non-goals
- Changing the feedback status set or the funnel routing (this brief surfaces + explains the current model; if the review prompts a status-model change, that's a separate brief).

## Provenance
Operator note (#156, 2026-07-03) — "surface feedback needing my action, and clarify the status model." Grounded against `Feedback::STATUSES` + `FeedbackPromotionService` funnel by flower-refine 2026-07-03. UI pattern to mirror: the Open Questions badge (`BriefQuestion::openCount` / #109). Related: #154 (open-questions view/badge realignment).

Recent/key trace events:
[1] participant_joined operator:mike: (no body)
[2] note_added operator:mike: Feedback visibility/surfacing items needing operator action

Let's do something similar to the Open Questions link + count/badge + filter for Feedback so I know if there are items awaiting my action from the nav menu

Also - let's review how and what statuses the Feedback items can fall into and what those mean/what's next for them. I'm kind of confused as to which items I'm supposed to do something with and if I'm supposed to do something what I'm supposed to do.
[3] status_change operator:mike: (no body)
[4] participant_joined flower-refine: (no body)
[5] spec_snapshot flower-refine: Feedback visibility/surfacing items needing operator action

Let's do something similar to the Open Questions link + count/badge + filter for Feedback so I know if there are items awaiting my action from the nav menu

Also - let's review how and what statuses the Feedback items can fall into and what those mean/what's next for them. I'm kind of confused as to which items I'm supposed to do something with and if I'm supposed to do something what I'm supposed to do.
[6] refinement flower-refine: ## Goal
Make feedback that **needs operator action** visible and easy to find (mirror the Open Questions nav pattern), and make the **feedback status model legible** so the operator knows which items they must act on vs. which the daemons handle autonomously.

## Grounded status model (current — `App\Models\Feedback` + `App\Services\Feedback\FeedbackPromotionService`)
**Kinds** (`FeedbackKind`): `bug`, `note`, `idea`, `mcp_issue`.
**Statuses** (`Feedback::STATUSES`): `open` (new/untriaged) → `triaged` → `planned` (promoted to a brief or routed to the orchestrator) → resolved: `addressed` | `wontfix` | `duplicate`.
**Who acts (the funnel):**
- `note` → self-handled → `addressed`. **No operator action.**
- `bug` / `mcp_issue` / sentry-sourced → **AUTONOMOUS (Funnel B)** → promoted to a brief (no approval) or routed to the orchestrator (todo + fix-spec) → `planned`. **No operator action.**
- `idea` (and feature / changed-functionality signals) → **OPERATOR-GATED (Funnel A)** → promoted to a brief with `needs_operator_approval=true` (draft, non-dispatchable); the operator must approve (`FeedbackPromotionService::approveBrief`) before it can dispatch. **← the only bucket that needs operator action.**

So **"needs operator action" = feedback whose promotion produced an operator-gated brief still pending approval** (Funnel A / idea-class).

## Scope
1. **Nav "needs action" count + badge + link** — mirror `BriefQuestion::openCount()` / the Open Questions badge: a single source of truth (e.g. `Feedback::needsOperatorActionCount()` or a `briefs.needs_operator_approval` count) feeding the nav badge, broadcast on change (like `OpenQuestionsChanged`). Clicking → the `/feedback` view filtered to the needs-action set.
2. **/feedback filter** for "needs my action" (the operator-gated pending-approval set), alongside the existing kind/status filters.
3. **Status legend / help on `/feedback`** — a short inline legend explaining each status + which kinds are autonomous vs operator-gated + what the operator is expected to do (approve/reject the gated ones). Directly resolves the "I'm confused which items I act on" ask.

## Decision (defaulted — adjust if desired)
"Needs action" is scoped to **operator-gated briefs pending approval** (recommended — it's the only set the funnel actually requires the operator to touch). If you also want `open`/untriaged feedback surfaced (e.g. as a health signal for when the autonomous triage loop is down), add it as a **secondary** count rather than folding it into the primary badge. Defaulting to the former.

## Acceptance
- Nav shows a feedback "needs action" badge/count (single source of truth + live update) linking to the filtered `/feedback` view; count = operator-gated briefs pending approval.
- `/feedback` has a "needs my action" filter + a status legend explaining the model and who acts.
- Tests: the count excludes autonomous/resolved and includes only pending operator-gated; the filter works. `php artisan test` green + `./vendor/bin/pint`. `Brief: #156` trailer.

## Non-goals
- Changing the feedback status set or the funnel routing (this brief surfaces + explains the current model; if the review prompts a status-model change, that's a separate brief).

## Provenance
Operator note (#156, 2026-07-03) — "surface feedback needing my action, and clarify the status model." Grounded against `Feedback::STATUSES` + `FeedbackPromotionService` funnel by flower-refine 2026-07-03. UI pattern to mirror: the Open Questions badge (`BriefQuestion::openCount` / #109). Related: #154 (open-questions view/badge realignment).
[7] status_change flower-refine: (no body)
[8] link_added flower-refine: (no body)

Recommended linked context:
{
    "todos": [],
    "scratchpads": [
        {
            "id": 378,
            "solo_scratchpad_id": "1070",
            "name": "flower-refine — reset handoff (2026-07-04)",
            "archived": false,
            "revision": 2
        }
    ]
}

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: #156` to every commit for this brief so flower can exact-link commits back to the brief.