It would be nice to be able to 'dogfood' the MCP tools in some fashion

You are being dispatched from flower Brief #99: It would be nice to be able to 'dogfood' the MCP tools in some fashion

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

Target:
- project: flower (/Users/mikeferrara/Documents/code/flower)
- branch: choose an appropriate branch
- worktree: not specified
- kind: fresh

Current brief spec:
## Ask
Let the operator SEE what agents see — surface MCP tool output (starting with `recall_brief`) in the
flower UI so the operator can eyeball the exact payload an agent gets, spot fields worth improving or
removing, and dogfood the tools.

## Scope — v1 (recall_brief on the brief detail page)
1. On the **brief detail page**, add an **"Agent's-eye view"** affordance — a collapsible panel or a
   link/modal — that renders the **`recall_brief` payload** for that brief exactly as the MCP tool
   returns it (reuse the same service path the tool uses, so the view can't drift from the real tool
   output).
2. Show it two ways: a **readable/structured** render (spec, Q&A, participants, links, recent events)
   and a **raw JSON** toggle (the literal tool output) so the operator can inspect field shape/size.
3. Read-only. No new data; just a view over the existing `recall_brief` path.

## Why
Dogfooding: the operator can spot over-verbose / under-informative fields (e.g. giant audit arrays,
missing summaries) and file targeted improvements — a feedback flywheel for the MCP surface itself.

## v2 (noted, out of v1)
- Generalize to other MCP tools/records via a reusable **"what agents see" preview** component any
  record page can mount, tool-selectable: a daemon-detail `recall_roster`/activity view (**overlaps
  #87 item [5] / child #92**), a project-page `recall_resume` / `recall_search` preview, session pages.

## Acceptance
- Brief detail exposes a `recall_brief` preview (structured + raw JSON toggle) via the real service path.
- Read-only; matches the bloom design system; `php artisan test` green + pint. `Brief: #99` trailer.

## Provenance
Operator note (#99, 2026-07-03). Scoped to a v1 (recall_brief on brief detail) + noted v2
generalization by flower-refine (2026-07-03). Related: #87 item [5] / #92 (daemon detail view).

Recent/key trace events:
[2] note_added operator:mike: It would be nice to be able to 'dogfood' the MCP tools in some fashion, for some tools. Like.. the recall_brief tool - if I could see what the agents see/get for a given brief on the brief page or from a link on that page or something - would be illuminating and help me kind of spot things that I think maybe could be improved or removed.
[3] status_change operator:mike: (no body)
[4] participant_joined flower-refine: (no body)
[5] spec_snapshot flower-refine: It would be nice to be able to 'dogfood' the MCP tools in some fashion, for some tools. Like.. the recall_brief tool - if I could see what the agents see/get for a given brief on the brief page or from a link on that page or something - would be illuminating and help me kind of spot things that I think maybe could be improved or removed.
[6] refinement flower-refine: ## Ask
Let the operator SEE what agents see — surface MCP tool output (starting with `recall_brief`) in the
flower UI so the operator can eyeball the exact payload an agent gets, spot fields worth improving or
removing, and dogfood the tools.

## Scope — v1 (recall_brief on the brief detail page)
1. On the **brief detail page**, add an **"Agent's-eye view"** affordance — a collapsible panel or a
   link/modal — that renders the **`recall_brief` payload** for that brief exactly as the MCP tool
   returns it (reuse the same service path the tool uses, so the view can't drift from the real tool
   output).
2. Show it two ways: a **readable/structured** render (spec, Q&A, participants, links, recent events)
   and a **raw JSON** toggle (the literal tool output) so the operator can inspect field shape/size.
3. Read-only. No new data; just a view over the existing `recall_brief` path.

## Why
Dogfooding: the operator can spot over-verbose / under-informative fields (e.g. giant audit arrays,
missing summaries) and file targeted improvements — a feedback flywheel for the MCP surface itself.

## v2 (noted, out of v1)
- Generalize to other MCP tools/records via a reusable **"what agents see" preview** component any
  record page can mount, tool-selectable: a daemon-detail `recall_roster`/activity view (**overlaps
  #87 item [5] / child #92**), a project-page `recall_resume` / `recall_search` preview, session pages.

## Acceptance
- Brief detail exposes a `recall_brief` preview (structured + raw JSON toggle) via the real service path.
- Read-only; matches the bloom design system; `php artisan test` green + pint. `Brief: #99` trailer.

## Provenance
Operator note (#99, 2026-07-03). Scoped to a v1 (recall_brief on brief detail) + noted v2
generalization by flower-refine (2026-07-03). Related: #87 item [5] / #92 (daemon detail view).
[7] status_change flower-refine: (no body)
[8] link_added flower-refine: (no body)
[9] participant_joined flower-orchestrator: (no body)
[10] status_change flower-orchestrator: (no body)
[11] link_added flower-orchestrator: (no body)
[12] refinement flower-refine: Grounding review (2026-07-03) VERIFIED the no-drift seam exists exactly as the spec wants: `recall_brief` is a thin wrapper — `app/Mcp/Tools/RecallBriefTool::handle()` just returns `RecallService::briefFolder($id, $slug)` (`app/Services/Recall/RecallService.php:198`). The new "agent's-eye view" panel calls that same method → guaranteed no drift from the real tool output. Note for the builder: `app/Livewire/Briefs/Show.php` currently uses BriefService/BriefRelationService (not RecallService), so the panel adds one `briefFolder()` call (a second query, not a free re-render of existing state). Bonus that validates the brief's premise: the review confirmed the payload IS bloated — each `spec_snapshot`/`refinement` event duplicates the full spec body, so the `events` array dominates size — precisely the over-verbose field this feature exists to surface. Spec is technically sound as-is → moving to planned.
[13] status_change flower-refine: (no body)

Recommended linked context:
{
    "todos": [],
    "scratchpads": [
        {
            "id": 346,
            "solo_scratchpad_id": "1026",
            "name": "Orchestrator HANDOFF — flower build (live state)",
            "archived": false,
            "revision": 83
        },
        {
            "id": 364,
            "solo_scratchpad_id": "1055",
            "name": "flower-refine — reset handoff (2026-07-03)",
            "archived": false,
            "revision": 1
        }
    ]
}

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