brief_ask ↔ decision_ask affordance parity (allow_write_in + recommended + decision_type) + verify write-in renders

You are being dispatched from flower Brief #228: brief_ask ↔ decision_ask affordance parity (allow_write_in + recommended + decision_type) + verify write-in renders

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

Target:
- project: flower (/Users/mikeferrara/Documents/code/flower)
- branch: flower/228-ask-parity
- worktree: not specified
- kind: fresh

Current brief spec:
# brief_ask ↔ decision_ask affordance parity

## Problem
Standalone `decision_ask` has the full rich affordance set (shipped in #95 PR-3/#119): `decision_type` (confirm | single_choice | multi_choice | text), object `options` ({key,label,recommended,detail}), `allow_write_in`, `allow_multi`. But **`brief_ask`** (used for brief-attached decisions) only exposes `options` + `allow_multi` — so brief-scoped questions can't offer a free-form **write-in**, a **`recommended`** option, or the **`text`** type. The `decisions` data model + the `/decisions` UI already support all of these (PR-3); only the `brief_ask` MCP tool schema (and its path into `DecisionService`) doesn't surface them.

## Scope
- Widen the `brief_ask` MCP tool schema (`app/Mcp/Tools/BriefAskTool.php` or equivalent) to accept, per question: `allow_write_in` (bool), `decision_type` (confirm|single_choice|multi_choice|text), and object `options` carrying per-option `recommended`. **Reuse `Decision::normalizeOptionList` from PR-3** so brief-attached + standalone decisions share one canonical option shape.
- Thread these through the `brief_ask` → `DecisionService` path so brief-attached `Decision`s get the same columns set that `decision_ask` sets.
- **Verify rendering:** confirm the write-in box + `recommended` tag + the non-`confirm` types actually render for **subject=Brief** decisions in the redesigned `/decisions` feed (#216) and on brief detail — PR-3 built the affordances; this confirms they light up for brief-attached, not just standalone.

## Acceptance
- `brief_ask` accepts `allow_write_in` / `recommended` / `decision_type`; a brief-attached single_choice decision with `allow_write_in=true` renders a working write-in box on `/decisions` and brief detail.
- Back-compat: existing bare-string `options` + single-text `brief_ask` calls keep working unchanged.
- `php artisan test` green + `./vendor/bin/pint`. `Brief: #228` trailer. Worktree-pinned; never edit MAIN.

## Relationships
- **Parent #95** (decisions epic); sibling of PR-3 (#119, which shipped the standalone affordances).
- **Unblocks #196's parked dogfood** — #196's Q42/43/44 are parked pending "richer decision types (allow_write_in, recommended, follow-up chains)"; once this lands they can be re-asked with write-in. (Soft/workflow link; #196 itself is about cross-project support, so NOT wired as a hard dependency.)
- Referenced by **#170 Phase 3** charter integration (charter currently steers rich asks to `decision_ask` "until brief_ask parity lands" — this removes that caveat).

## Provenance
Feature-gap surfaced by flower-refine dogfooding decisions on #226/#170; operator confirmed 2026-07-04.

**Disposition:** `planned` — mechanical + well-scoped; no design-loop needed. Orchestrator owns dispatch.

Recent/key trace events:
[1] participant_joined flower-refine: (no body)
[2] note_added flower-refine: Feature-gap surfaced dogfooding decisions (#170) + operator ask (2026-07-04): bring brief-attached decisions (brief_ask) up to parity with standalone decision_ask, which already supports allow_write_in / recommended / decision_type. Small schema-widening + UI verify. See #170 event trail for the analysis.
[3] plan_proposed flower-refine: # brief_ask ↔ decision_ask affordance parity

## Problem
Standalone `decision_ask` has the full rich affordance set (shipped in #95 PR-3/#119): `decision_type` (confirm | single_choice | multi_choice | text), object `options` ({key,label,recommended,detail}), `allow_write_in`, `allow_multi`. But **`brief_ask`** (used for brief-attached decisions) only exposes `options` + `allow_multi` — so brief-scoped questions can't offer a free-form **write-in**, a **`recommended`** option, or the **`text`** type. The `decisions` data model + the `/decisions` UI already support all of these (PR-3); only the `brief_ask` MCP tool schema (and its path into `DecisionService`) doesn't surface them.

## Scope
- Widen the `brief_ask` MCP tool schema (`app/Mcp/Tools/BriefAskTool.php` or equivalent) to accept, per question: `allow_write_in` (bool), `decision_type` (confirm|single_choice|multi_choice|text), and object `options` carrying per-option `recommended`. **Reuse `Decision::normalizeOptionList` from PR-3** so brief-attached + standalone decisions share one canonical option shape.
- Thread these through the `brief_ask` → `DecisionService` path so brief-attached `Decision`s get the same columns set that `decision_ask` sets.
- **Verify rendering:** confirm the write-in box + `recommended` tag + the non-`confirm` types actually render for **subject=Brief** decisions in the redesigned `/decisions` feed (#216) and on brief detail — PR-3 built the affordances; this confirms they light up for brief-attached, not just standalone.

## Acceptance
- `brief_ask` accepts `allow_write_in` / `recommended` / `decision_type`; a brief-attached single_choice decision with `allow_write_in=true` renders a working write-in box on `/decisions` and brief detail.
- Back-compat: existing bare-string `options` + single-text `brief_ask` calls keep working unchanged.
- `php artisan test` green + `./vendor/bin/pint`. `Brief: #228` trailer. Worktree-pinned; never edit MAIN.

## Relationships
- **Parent #95** (decisions epic); sibling of PR-3 (#119, which shipped the standalone affordances).
- **Unblocks #196's parked dogfood** — #196's Q42/43/44 are parked pending "richer decision types (allow_write_in, recommended, follow-up chains)"; once this lands they can be re-asked with write-in. (Soft/workflow link; #196 itself is about cross-project support, so NOT wired as a hard dependency.)
- Referenced by **#170 Phase 3** charter integration (charter currently steers rich asks to `decision_ask` "until brief_ask parity lands" — this removes that caveat).

## Provenance
Feature-gap surfaced by flower-refine dogfooding decisions on #226/#170; operator confirmed 2026-07-04.

**Disposition:** `planned` — mechanical + well-scoped; no design-loop needed. Orchestrator owns dispatch.
[4] parent_set flower-refine: Grouped under epic #95.
[5] 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: #228` to every commit for this brief so flower can exact-link commits back to the brief.