UI: human-submitted bug/feedback capture → feeds the ops triage chain

You are being dispatched from flower Brief #3: UI: human-submitted bug/feedback capture → feeds the ops triage chain

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

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

Current brief spec:
## Spec: Human-Submitted Feedback Capture

### Goal
Provide an operator-facing UI in the flower application that allows a human user to submit bug reports, ideas, or general notes. These submissions write to the same `feedback` store (database table and model) that the `flower-ops` triage loop consumes, so that human-found bugs enter the same Sentry + feedback triage pipeline as agent-submitted feedback.

### Existing assets
- `Feedback` model (with fields: kind, detail, context, status, etc.)
- `FeedbackKind` enum: `bug`, `note`, `idea`, `mcp_issue`
- `flower_feedback` MCP tool (agent-only, not exposed in UI)
- `/feedback` page (review-only: triage, overrides)
- Livewire component infrastructure in the flower project

### Requirements

1. **Capture form** — A small Livewire component (e.g., `FeedbackCapture`) with:
   - Kind selector: `bug`, `idea`, `note` (not `mcp_issue`)
   - Free-text detail/description field (required for `bug`, optional otherwise)
   - Optional context field (e.g., URL, screenshot reference, environment)
   - Submit button -> calls `feedback.store` or equivalent backend action

2. **Persistence** — On submit, create a new `Feedback` record with:
   - `kind` = selected kind
   - `detail` = user-supplied text
   - `context` = user-supplied context string (nullable)
   - `status` = `new` (so it appears in the triage queue)
   - `source` = `operator` (distinguish from agent/MCP submissions)
   - `created_by` = current user (if available; else anonymous)

3. **Global affordance** — A persistent "Report a bug" or "Give feedback" button/entry point visible in the flower UI chrome (e.g., top bar or sidebar). Clicking opens the capture form as a modal or slide-out panel.

4. **Integration** — The `/feedback` triage page should already surface these new records because it reads from the same `feedback` table. No change to the triage page is required, but the triage UI should display `source` for context.

### Non-requirements
- No Sentry integration at capture time (the triage loop attaches Sentry context later).
- No access control beyond existing authentication.
- No file attachments in initial version.

### Implementation notes
- Reuse existing Livewire patterns and the Feedback model/store.
- Add a `source` column to the `feedback` migration if not already present (default: `agent`).
- Register the Livewire component globally in the layout.
- Minimal new code; the primary delta is the UI form and its endpoint.

Recent/key trace events:
[1] participant_joined operator:mike: (no body)
[2] note_added operator:mike: Mike (2026-06-30): We need a way in the flower UI for a HUMAN to submit feedback/bug reports when they find a bug, so it enters the same chain the ops loop already triages. Today only AGENTS can file (flower_feedback MCP); the /feedback page is review-only (triage + overrides). Gap: no operator-facing capture. Build an operator-facing capture box (bug | idea | note, + optional detail/context) on the flower UI that writes to the SAME feedback store flower-ops (964) consumes, so human-found bugs flow into the same Sentry+feedback triage loop and get routed to build agents. Likely a small Livewire form reusing the existing feedback model/store; surface it globally (a persistent report affordance) and/or on /feedback.
[3] participant_joined agent:brief-refiner: (no body)
[4] plan_proposed agent:brief-refiner: ## Spec: Human-Submitted Feedback Capture

### Goal
Provide an operator-facing UI in the flower application that allows a human user to submit bug reports, ideas, or general notes. These submissions write to the same `feedback` store (database table and model) that the `flower-ops` triage loop consumes, so that human-found bugs enter the same Sentry + feedback triage pipeline as agent-submitted feedback.

### Existing assets
- `Feedback` model (with fields: kind, detail, context, status, etc.)
- `FeedbackKind` enum: `bug`, `note`, `idea`, `mcp_issue`
- `flower_feedback` MCP tool (agent-only, not exposed in UI)
- `/feedback` page (review-only: triage, overrides)
- Livewire component infrastructure in the flower project

### Requirements

1. **Capture form** — A small Livewire component (e.g., `FeedbackCapture`) with:
   - Kind selector: `bug`, `idea`, `note` (not `mcp_issue`)
   - Free-text detail/description field (required for `bug`, optional otherwise)
   - Optional context field (e.g., URL, screenshot reference, environment)
   - Submit button -> calls `feedback.store` or equivalent backend action

2. **Persistence** — On submit, create a new `Feedback` record with:
   - `kind` = selected kind
   - `detail` = user-supplied text
   - `context` = user-supplied context string (nullable)
   - `status` = `new` (so it appears in the triage queue)
   - `source` = `operator` (distinguish from agent/MCP submissions)
   - `created_by` = current user (if available; else anonymous)

3. **Global affordance** — A persistent "Report a bug" or "Give feedback" button/entry point visible in the flower UI chrome (e.g., top bar or sidebar). Clicking opens the capture form as a modal or slide-out panel.

4. **Integration** — The `/feedback` triage page should already surface these new records because it reads from the same `feedback` table. No change to the triage page is required, but the triage UI should display `source` for context.

### Non-requirements
- No Sentry integration at capture time (the triage loop attaches Sentry context later).
- No access control beyond existing authentication.
- No file attachments in initial version.

### Implementation notes
- Reuse existing Livewire patterns and the Feedback model/store.
- Add a `source` column to the `feedback` migration if not already present (default: `agent`).
- Register the Livewire component globally in the layout.
- Minimal new code; the primary delta is the UI form and its endpoint.
[5] spec_snapshot operator:mike: ## Spec: Human-Submitted Feedback Capture

### Goal
Provide an operator-facing UI in the flower application that allows a human user to submit bug reports, ideas, or general notes. These submissions write to the same `feedback` store (database table and model) that the `flower-ops` triage loop consumes, so that human-found bugs enter the same Sentry + feedback triage pipeline as agent-submitted feedback.

### Existing assets
- `Feedback` model (with fields: kind, detail, context, status, etc.)
- `FeedbackKind` enum: `bug`, `note`, `idea`, `mcp_issue`
- `flower_feedback` MCP tool (agent-only, not exposed in UI)
- `/feedback` page (review-only: triage, overrides)
- Livewire component infrastructure in the flower project

### Requirements

1. **Capture form** — A small Livewire component (e.g., `FeedbackCapture`) with:
   - Kind selector: `bug`, `idea`, `note` (not `mcp_issue`)
   - Free-text detail/description field (required for `bug`, optional otherwise)
   - Optional context field (e.g., URL, screenshot reference, environment)
   - Submit button -> calls `feedback.store` or equivalent backend action

2. **Persistence** — On submit, create a new `Feedback` record with:
   - `kind` = selected kind
   - `detail` = user-supplied text
   - `context` = user-supplied context string (nullable)
   - `status` = `new` (so it appears in the triage queue)
   - `source` = `operator` (distinguish from agent/MCP submissions)
   - `created_by` = current user (if available; else anonymous)

3. **Global affordance** — A persistent "Report a bug" or "Give feedback" button/entry point visible in the flower UI chrome (e.g., top bar or sidebar). Clicking opens the capture form as a modal or slide-out panel.

4. **Integration** — The `/feedback` triage page should already surface these new records because it reads from the same `feedback` table. No change to the triage page is required, but the triage UI should display `source` for context.

### Non-requirements
- No Sentry integration at capture time (the triage loop attaches Sentry context later).
- No access control beyond existing authentication.
- No file attachments in initial version.

### Implementation notes
- Reuse existing Livewire patterns and the Feedback model/store.
- Add a `source` column to the `feedback` migration if not already present (default: `agent`).
- Register the Livewire component globally in the layout.
- Minimal new code; the primary delta is the UI form and its endpoint.
[6] refinement operator:mike: ## Spec: Human-Submitted Feedback Capture

### Goal
Provide an operator-facing UI in the flower application that allows a human user to submit bug reports, ideas, or general notes. These submissions write to the same `feedback` store (database table and model) that the `flower-ops` triage loop consumes, so that human-found bugs enter the same Sentry + feedback triage pipeline as agent-submitted feedback.

### Existing assets
- `Feedback` model (with fields: kind, detail, context, status, etc.)
- `FeedbackKind` enum: `bug`, `note`, `idea`, `mcp_issue`
- `flower_feedback` MCP tool (agent-only, not exposed in UI)
- `/feedback` page (review-only: triage, overrides)
- Livewire component infrastructure in the flower project

### Requirements

1. **Capture form** — A small Livewire component (e.g., `FeedbackCapture`) with:
   - Kind selector: `bug`, `idea`, `note` (not `mcp_issue`)
   - Free-text detail/description field (required for `bug`, optional otherwise)
   - Optional context field (e.g., URL, screenshot reference, environment)
   - Submit button -> calls `feedback.store` or equivalent backend action

2. **Persistence** — On submit, create a new `Feedback` record with:
   - `kind` = selected kind
   - `detail` = user-supplied text
   - `context` = user-supplied context string (nullable)
   - `status` = `new` (so it appears in the triage queue)
   - `source` = `operator` (distinguish from agent/MCP submissions)
   - `created_by` = current user (if available; else anonymous)

3. **Global affordance** — A persistent "Report a bug" or "Give feedback" button/entry point visible in the flower UI chrome (e.g., top bar or sidebar). Clicking opens the capture form as a modal or slide-out panel.

4. **Integration** — The `/feedback` triage page should already surface these new records because it reads from the same `feedback` table. No change to the triage page is required, but the triage UI should display `source` for context.

### Non-requirements
- No Sentry integration at capture time (the triage loop attaches Sentry context later).
- No access control beyond existing authentication.
- No file attachments in initial version.

### Implementation notes
- Reuse existing Livewire patterns and the Feedback model/store.
- Add a `source` column to the `feedback` migration if not already present (default: `agent`).
- Register the Livewire component globally in the layout.
- Minimal new code; the primary delta is the UI form and its endpoint.

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.