Explore clickable/slug references for briefs, feedback, projects, sessions (session-nav UX)

You are being dispatched from flower Brief #78: Explore clickable/slug references for briefs, feedback, projects, sessions (session-nav UX)

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

Target:
- project: flower (/Users/mikeferrara/Documents/code/flower)
- branch: flower/78-discovery
- worktree: not specified
- kind: fresh

Current brief spec:
## Objective
Discovery + recommendation (NOT implementation): define a canonical way for agents and the UI to **reference and open** flower entities (briefs, feedback, projects, sessions, roster daemons) instead of bare numbers, and propose a small change set. The deliverable is a recommendation to **discuss before any build**.

## Problem
In multi-agent sessions, flower items are referenced by bare numbers everywhere (`#67`, `feedback #49`, `proj 16`, `session 0410d7d4…`). With many items in flight this is hard to track, and there is no easy way to open the referenced item. Operator pain raised 2026-07-02.

## Discovery questions (answer each with a recommendation)
1. **Reference / linking scheme.** Weigh: (a) http deep links to the item page (e.g. `https://flower.test/briefs/{id-or-slug}`, `/feedback/{id}`, `/projects/{slug}`, a session view); (b) Solo's `solo://` deep-link scheme — determine whether it can address flower entities at all, or only Solo projects/scratchpads/todos (investigate; cf. `solo://proj/49/scratchpad/…`); (c) both, and when to use which. **Recommend one canonical scheme.**
2. **Slug vs numeric id as the PRIMARY human reference.** Briefs already have slugs (more memorable/greppable); numbers are terser. Recommend a convention per entity type (briefs, feedback, projects, sessions, daemons) — and note which entities even have slugs today.
3. **Inline-link emission policy for agents.** When should an agent emit a link when it references an item? Tradeoff: navigability vs message verbosity. **Hard constraint: the operator does NOT want every reference bloated with links.** Candidate policies to weigh: link only on first reference per turn; only in summaries/checkpoints; or a "resolve these ids" affordance instead of always inlining. **Recommend a default.**
4. **UI affordances.** Which of: clickable ids in `/briefs`, `/feedback`, `/roster`; a copy-link action; human-facing cross-links between related briefs/feedback (briefs already auto-link participants/commits — extend to human-facing anchors). **Recommend a minimal high-value set.**

## Investigation scope (keep it light — discovery, not a build)
- Existing routes / Livewire pages and their URL shape (what resolves by id vs slug today).
- Which entities have slugs now (briefs do; feedback / projects / sessions / daemons?).
- Whether `solo://` can target flower entities (vs only Solo projects/scratchpads/todos).
- Current agent reference conventions in charters/playbooks (bare numbers everywhere).

## Deliverable
A concise recommendation covering **(reference format, http vs `solo://` vs both, slug-vs-number per entity, inline-link policy)** PLUS a **small proposed UI + agent-convention change set** (sized as thin slices). Written up for operator discussion. NOT an implementation.

## Constraints / non-goals
- Do NOT over-build; this is a discovery brief.
- Do NOT bloat every reference with links (hard operator constraint).
- Implementation of the linking scheme / UI is **out of scope here** — it becomes separate follow-up brief(s) AFTER the recommendation is discussed ("to discuss before building").

## Definition of done
Recommendation written up (as a brief note or linked doc) and posted for operator discussion; brief ready to hand back to the operator/orchestrator for the build decision.

Recent/key trace events:
[1] participant_joined flower-orchestrator: (no body)
[2] note_added flower-orchestrator: Operator pain (raised 2026-07-02): in these multi-agent sessions we refer to briefs/feedback/projects/sessions by BARE NUMBERS everywhere (#67, feedback #49, proj 16, session 0410d7d4…). With many items in flight it's hard to track what's what, and there's no easy way to open the referenced item. Explore + recommend (discovery brief, don't over-build):
1. A canonical linking scheme for referencing flower items — options: (a) http deep links to the item page (e.g. https://flower.test/briefs/{id-or-slug}, /feedback, /projects/{slug}, session view), (b) Solo's `solo://` deep-link scheme (does it cover flower entities, or only Solo projects/scratchpads/todos? — investigate), (c) both.
2. Slugs vs numeric ids as the PRIMARY human reference for briefs (briefs already have slugs). More memorable/greppable; but numbers are terser. Recommend a convention.
3. Whether/when agents should EMIT links inline when they reference an item — tradeoff: navigability vs. message verbosity. Maybe: emit a link the first time an item is referenced in a turn, or only in summaries/checkpoints, or provide a "resolve these ids" affordance rather than always inlining. Operator explicitly does NOT want every reference bloated with links if that's the only option.
4. UI affordances: clickable ids in /briefs, /feedback, /roster; a copy-link action; cross-links between related briefs/feedback (briefs already auto-link participants/commits — extend to human-facing anchors).
Deliverable: a recommendation on (reference format, http vs solo://, slug-vs-number, inline-link policy) + a small proposed UI/agent-convention change set. To discuss before building.
[3] participant_joined operator:mike: (no body)
[4] status_change operator:mike: (no body)
[5] link_added flower-orchestrator: (no body)
[6] participant_joined flower-refine: (no body)
[7] plan_proposed flower-refine: ## Objective
Discovery + recommendation (NOT implementation): define a canonical way for agents and the UI to **reference and open** flower entities (briefs, feedback, projects, sessions, roster daemons) instead of bare numbers, and propose a small change set. The deliverable is a recommendation to **discuss before any build**.

## Problem
In multi-agent sessions, flower items are referenced by bare numbers everywhere (`#67`, `feedback #49`, `proj 16`, `session 0410d7d4…`). With many items in flight this is hard to track, and there is no easy way to open the referenced item. Operator pain raised 2026-07-02.

## Discovery questions (answer each with a recommendation)
1. **Reference / linking scheme.** Weigh: (a) http deep links to the item page (e.g. `https://flower.test/briefs/{id-or-slug}`, `/feedback/{id}`, `/projects/{slug}`, a session view); (b) Solo's `solo://` deep-link scheme — determine whether it can address flower entities at all, or only Solo projects/scratchpads/todos (investigate; cf. `solo://proj/49/scratchpad/…`); (c) both, and when to use which. **Recommend one canonical scheme.**
2. **Slug vs numeric id as the PRIMARY human reference.** Briefs already have slugs (more memorable/greppable); numbers are terser. Recommend a convention per entity type (briefs, feedback, projects, sessions, daemons) — and note which entities even have slugs today.
3. **Inline-link emission policy for agents.** When should an agent emit a link when it references an item? Tradeoff: navigability vs message verbosity. **Hard constraint: the operator does NOT want every reference bloated with links.** Candidate policies to weigh: link only on first reference per turn; only in summaries/checkpoints; or a "resolve these ids" affordance instead of always inlining. **Recommend a default.**
4. **UI affordances.** Which of: clickable ids in `/briefs`, `/feedback`, `/roster`; a copy-link action; human-facing cross-links between related briefs/feedback (briefs already auto-link participants/commits — extend to human-facing anchors). **Recommend a minimal high-value set.**

## Investigation scope (keep it light — discovery, not a build)
- Existing routes / Livewire pages and their URL shape (what resolves by id vs slug today).
- Which entities have slugs now (briefs do; feedback / projects / sessions / daemons?).
- Whether `solo://` can target flower entities (vs only Solo projects/scratchpads/todos).
- Current agent reference conventions in charters/playbooks (bare numbers everywhere).

## Deliverable
A concise recommendation covering **(reference format, http vs `solo://` vs both, slug-vs-number per entity, inline-link policy)** PLUS a **small proposed UI + agent-convention change set** (sized as thin slices). Written up for operator discussion. NOT an implementation.

## Constraints / non-goals
- Do NOT over-build; this is a discovery brief.
- Do NOT bloat every reference with links (hard operator constraint).
- Implementation of the linking scheme / UI is **out of scope here** — it becomes separate follow-up brief(s) AFTER the recommendation is discussed ("to discuss before building").

## Definition of done
Recommendation written up (as a brief note or linked doc) and posted for operator discussion; brief ready to hand back to the operator/orchestrator for the build decision.
[8] status_change flower-refine: (no body)
[9] refinement flower-refine: ⚠️ GROUNDING REVIEW (2026-07-03) — factual correction for the recommendation (brief stays planned; this sharpens Q2/Q1):

"Briefs already have slugs" is true at the DATA layer but MISLEADING at the URL layer. `briefs.slug` is a unique auto-generated column (`BriefService::uniqueSlug()`), BUT the route `/briefs/{brief}` uses default primary-key binding — NO model overrides `getRouteKeyName` anywhere — so brief pages are reachable only by NUMERIC ID today. Making a brief slug-openable is a small net change (`getRouteKeyName` or `{brief:slug}`).

Accurate slug/route inventory: only `Project` resolves by slug in routes (`/projects/{project:slug}`); `Brief` is slug-capable-but-id-routed; `Feedback`, `Session`, `DaemonAgent` have NO slug + no override → id-only (sessions also carry a `session_id` string but the route binds by pk). So the honest answer to Q2 (slug vs number per entity) = projects: slug (canonical); briefs: slug-capable but id-routed; feedback/sessions/daemons: id-only.

`solo://` is neither emitted nor consumed anywhere in flower (the app talks to Solo via solo-cli only), so "can solo:// target flower entities" (Q1) is genuine EXTERNAL investigation, correctly scoped as discovery.

Precedent to cite: `/roster/{daemon}` detail already exists (its route comment calls it the concrete instance of this clickable-refs idea), and briefs already auto-link participants/commits via `BriefAutoLinkService` — real substrate for "extend auto-links to human-facing anchors".
[10] link_added 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": 93
        },
        {
            "id": 375,
            "solo_scratchpad_id": "1067",
            "name": "flower-refine — reset handoff (2026-07-03 #2)",
            "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: #78` to every commit for this brief so flower can exact-link commits back to the brief.