Rooms UI: persistent "active refs" rail — live working-set of cited briefs/feedback/decisions (#N title status)

You are being dispatched from flower Brief #246: Rooms UI: persistent "active refs" rail — live working-set of cited briefs/feedback/decisions (#N title status)

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

Target:
- project: flower (/Users/mikeferrara/Documents/code/flower)
- branch: flower/246-active-refs-rail
- worktree: not specified
- kind: fresh

Current brief spec:
# Rooms UI: persistent "active refs" rail

## Concept (operator-endorsed, Mike 2026-07-04)
A persistent, always-visible **"active refs" rail** in the flower rooms UI holding the citations currently in play — each shown as `#N <short title> (status)`, auto-updating as new refs are cited. The durable, cross-harness, operator-in-the-web-UI expression of a "sticky working-set of references" (the CC-todo-list instinct, done right): the operator always has the numbers decoded WITHOUT them repeating inline in every message.

## Relationship to #244 (the inline convention)
#244 defines the inline `Refs:` charter convention (deduped, ambient `{title,status}`, capped, status) — the baseline that works in every surface + harness. This rail is the **richer UI layer**: it carries the working-set persistently, so inline `Refs:` only fires on genuinely-new numbers → it *feeds/enables* #244's cross-message dedupe. Baseline convention + rail = both, not either.

## Strawman
- A pinned strip / sidebar in `rooms/show` near the message stream, listing "active" cited entities: `#N` · short title (~40ch) · status badge, each a click-through/deep-link (reuse the #216 flyout).
- **"Active" = a rolling working-set** — cited in the last N messages / M minutes (configurable), not the full history.
- Rides on #216's room/feed surface + the same recall_* `{title,status}` enrichment #244 needs.

## Open design questions (→ light design pass before planned)
1. **Placement:** room sidebar vs collapsible strip atop the stream vs woven into the "Needs you" lane?
2. **"Active" definition:** last-N-messages, time-window, operator-pinned, or a combination?
3. **Entity scope:** briefs only, or briefs + feedback + decisions + sessions (matching #244's typed refs)?
4. **Interaction:** click → deep-link/flyout; operator pin/unpin; dismiss?
5. **Data source:** the "recently-cited" signal — parse daemon messages for `#N`, or emit explicit ref events on brief/decision writes? Combined with #244's `{title,status}` enrichment.

## Relationships
- **#244** — the inline Refs charter convention this complements (shares the `{title,status}` enrichment).
- **#216** — rooms / decisions-feed redesign (the UI surface this lives on).
- **#78** — entity-ref recommendation (compact refs; link on first mention).

## Provenance
Operator endorsed 2026-07-04; spun out of #244 round-3 refinement (CC-todo-list vehicle dropped in favor of this durable UI version).

**Disposition:** `refining` — light design pass on placement + "active" semantics + data-source before `planned`.

Recent/key trace events:
[1] participant_joined flower-refine: (no body)
[2] note_added flower-refine: Operator-endorsed (Mike, 2026-07-04), spun out of #244 round-3. Durable, cross-harness UI version of the "sticky working-set of citations" idea (CC-todo-list vehicle dropped). See #244 event trail for the reasoning.
[3] plan_proposed flower-refine: # Rooms UI: persistent "active refs" rail

## Concept (operator-endorsed, Mike 2026-07-04)
A persistent, always-visible **"active refs" rail** in the flower rooms UI holding the citations currently in play — each shown as `#N <short title> (status)`, auto-updating as new refs are cited. The durable, cross-harness, operator-in-the-web-UI expression of a "sticky working-set of references" (the CC-todo-list instinct, done right): the operator always has the numbers decoded WITHOUT them repeating inline in every message.

## Relationship to #244 (the inline convention)
#244 defines the inline `Refs:` charter convention (deduped, ambient `{title,status}`, capped, status) — the baseline that works in every surface + harness. This rail is the **richer UI layer**: it carries the working-set persistently, so inline `Refs:` only fires on genuinely-new numbers → it *feeds/enables* #244's cross-message dedupe. Baseline convention + rail = both, not either.

## Strawman
- A pinned strip / sidebar in `rooms/show` near the message stream, listing "active" cited entities: `#N` · short title (~40ch) · status badge, each a click-through/deep-link (reuse the #216 flyout).
- **"Active" = a rolling working-set** — cited in the last N messages / M minutes (configurable), not the full history.
- Rides on #216's room/feed surface + the same recall_* `{title,status}` enrichment #244 needs.

## Open design questions (→ light design pass before planned)
1. **Placement:** room sidebar vs collapsible strip atop the stream vs woven into the "Needs you" lane?
2. **"Active" definition:** last-N-messages, time-window, operator-pinned, or a combination?
3. **Entity scope:** briefs only, or briefs + feedback + decisions + sessions (matching #244's typed refs)?
4. **Interaction:** click → deep-link/flyout; operator pin/unpin; dismiss?
5. **Data source:** the "recently-cited" signal — parse daemon messages for `#N`, or emit explicit ref events on brief/decision writes? Combined with #244's `{title,status}` enrichment.

## Relationships
- **#244** — the inline Refs charter convention this complements (shares the `{title,status}` enrichment).
- **#216** — rooms / decisions-feed redesign (the UI surface this lives on).
- **#78** — entity-ref recommendation (compact refs; link on first mention).

## Provenance
Operator endorsed 2026-07-04; spun out of #244 round-3 refinement (CC-todo-list vehicle dropped in favor of this durable UI version).

**Disposition:** `refining` — light design pass on placement + "active" semantics + data-source before `planned`.
[4] status_change flower-refine: (no body)
[5] plan_proposed flower-refine: **Build-ready (operator wants dispatch, 2026-07-04)** — resolving the 5 open design Qs to defaults so this goes to `planned` + dispatches WITHOUT a separate design-loop. Worker: build to these; adjust with craft judgment.

1. **Placement:** a **collapsible rail/strip on `rooms/show`** — right sidebar or a pinned strip atop the message stream, on the #216 room surface (bloom). Collapsible so it's never in the way.
2. **"Active" = rolling working-set:** entities cited in the last ~15 messages OR ~30 min (**config-as-data, env-overridable**), PLUS operator **pin/unpin** to keep one sticky. Newest-first, capped ~10 (config).
3. **Entity scope:** all typed refs — briefs + feedback + decisions + sessions (matches #244's typed prefixes: bare `#`=brief, `fb#`, `dec#`, `sess#`).
4. **Interaction:** each row = `#N · short title (~40ch) · status badge`; click → deep-link / #216 flyout; operator pin/unpin + dismiss.
5. **Data source:** resolve `{title,status}` **directly** (query brief/feedback/decision/session) — NOT blocked on #244's recall_* enrichment (nicer if #244 lands first, but #246 resolves independently). "Recently-cited" signal v1 = derive from the room message/event stream (parse `#N` mentions); explicit ref-events can be a fast-follow.

**Soft dependency:** #244 (shares title/status resolution + the "cited" concept) — coordinate, not blocking. Surface = #216.

**Acceptance:** a working collapsible "active refs" rail in `rooms/show` showing recently-cited entities with title + status, click-through, pin/unpin; config knobs for window/cap; `php artisan test` green + `./vendor/bin/pint`; `Brief: #246` trailer; worktree-pinned.

**Disposition:** `planned` — dispatch-ready (operator opted for direct build over a design-loop).
[6] 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: #246` to every commit for this brief so flower can exact-link commits back to the brief.
- Need an operator call while working this brief? A question ABOUT THIS BRIEF -> brief_ask(246, ...); a standalone decision not tied to the brief -> decision_ask(...). Both expose the full affordance set (confirm | single_choice | multi_choice | text, options + recommended, allow_write_in); prefer async questions over blocking and set is_blocking only when you truly cannot proceed.
- Cited-refs index (Brief #244): when a report / checkpoint / DONE summary cites numbered entities, append a compact `Refs:` block at the END mapping each `#N` to its REAL stored title + status — `#<num>: <title> (<status>)`, one per line (typed prefixes: bare `#N` = brief, `fb#N` feedback, `dec#N` decision, `sess#N` session, `dr#N` dispatch_request). Resolve any title you did not already pull with recall_refs instead of guessing; skip the block on trivial one-liners.