feat(ux): consolidate Launch Swarm + telemetry UX with minimized strip

- Removed broken LaunchSwarmDialog (formula-based) from TopBar/LeftPanel
- All Rocket buttons (TopBar, LeftPanel, DAG nodes, social cards) now open
  AssignmentPanel (archetype-based) which actually works
- Every Rocket clears taskId first so assignMode && !taskId condition passes
- Conversation button priority: taskId always shows conversation, not assign panel
- Added TelemetryStrip: minimized right sidebar with status dots when non-telemetry
  panel (conversation/assignment) is active
- Live feed has minimize button → restores last taskId or assignMode
- DAG nodes: Signal icon → restores telemetry feed
- Social button on DAG nodes: single router.push to avoid race (setView + setTaskId)
- Fixed social card message button: opens right panel with drawer:closed (no popup)

Co-Authored-By: Oz <oz-agent@warp.dev>

docs/prompts/2026-02-28-next-session-dolt-repair.md

@@ -0,0 +1,75 @@
+# Next Session Prompt: Dolt/Beads Database Recovery and Source-of-Truth Reconciliation
+
+You are continuing work in `/mnt/c/Users/Zenchant/codex/beadboard`.
+
+## Problem snapshot (as of 2026-02-28)
+Bead state appears empty in `bd ready`, but `.beads/issues.jsonl` contains historical data.
+
+Observed signals:
+- `bd status` reports only **3 closed issues** (0 open/in_progress/blocked).
+- `.beads/issues.jsonl` has **381 lines**.
+- `bd doctor --dry-run` reports:
+  - **Dolt-JSONL count mismatch** (`Dolt has 3, JSONL has 381`)
+  - stale/merge artifacts and lock issues
+  - config mismatch hints in `.beads/metadata.json`
+- Prior repair attempt hit lock/permission conflicts (`database is locked by another dolt process`).
+
+## Goal
+Restore BeadBoard to a consistent, usable state where `bd` in this repo reflects the expected issue set, and `bd ready` shows correct ready work.
+
+## Non-goals
+- No frontend feature work.
+- No broad refactors.
+- No destructive git resets.
+
+## Required outcomes
+1. Clear diagnosis of why Dolt state diverged from JSONL state.
+2. Safe repair path applied (or a precise blocker report if repair cannot complete).
+3. Post-repair verification evidence showing issue counts and ready-state are sane.
+4. Short write-up on recurrence prevention.
+
+## Guardrails
+- Treat `.beads/issues.jsonl` as historical source candidate, but verify before forcing import.
+- Avoid direct manual edits to `.beads/issues.jsonl`.
+- Use `bd` commands and documented repair flows first.
+- Do not run destructive git commands.
+
+## Suggested execution order
+1. **Capture baseline evidence**
+   - `bd where`
+   - `bd status`
+   - `bd ready`
+   - `bd list --status open --status in_progress --status blocked --json`
+   - `wc -l .beads/issues.jsonl`
+   - `bd doctor --dry-run`
+
+2. **Check lock/process state**
+   - Identify active `bd`/`dolt` processes.
+   - Identify stale lock files in `.beads`.
+   - Resolve lock conflicts in a non-destructive way.
+
+3. **Repair using bd-supported flow**
+   - Attempt `bd doctor --fix --source=jsonl --yes`.
+   - If still divergent, run focused checks (`bd doctor --check=validate`, `bd doctor --check=artifacts`).
+   - If needed, document and execute the minimal additional `bd` recovery command sequence.
+
+4. **Reconcile and verify**
+   - Re-run `bd status`, `bd ready`, `bd list --json`.
+   - Confirm counts are no longer `3 vs 381` divergent.
+   - Confirm expected open/ready beads appear.
+
+5. **Record root cause + prevention**
+   - Add a concise note in docs (or bead notes) on:
+     - root cause
+     - repair steps that worked
+     - required hygiene (locks, hooks, sync flow, config keys)
+
+## Deliverables
+1. Repair summary with command evidence.
+2. Final healthy `bd` status/ready output summary.
+3. Minimal prevention checklist for future sessions.
+
+## Completion criteria
+- `bd` issue inventory in this repo is consistent with expected project history.
+- `bd ready` is no longer falsely empty due to DB divergence.
+- No destructive repository actions were used.

docs/prompts/2026-02-28-next-session-holistic-ux-critique.md

@@ -0,0 +1,94 @@
+# Next Session Prompt: Holistic UX Critique for Professional Multi-Agent Operations
+
+You are continuing work in `/mnt/c/Users/Zenchant/codex/beadboard`.
+
+## Understanding Brief
+BeadBoard is intended to be a **professional multi-agent communication + work management system** where:
+- agents coordinate through Beads (`bd`) state,
+- humans supervise, intervene, and steer,
+- both can collaborate across multiple repos/projects.
+
+This is **not** just a task board. It is an operations surface for swarm-style execution, communication, assignment, and recovery.
+
+## Recent work completed (must understand before critique)
+1. `bd`/Dolt recovery was performed after severe divergence:
+   - prior broken state: Dolt showed only a few issues while historical stores had hundreds,
+   - repaired state now shows healthy inventory (381 issues) and non-empty `bd ready`.
+2. Runtime assumptions changed:
+   - `bd` upgraded to `0.56.1`.
+   - Dolt server mode is operationally relevant (`127.0.0.1:3307`).
+3. `bd` command execution was moved toward PATH-based portability and clearer setup failure handling.
+
+Do not re-do this recovery unless evidence shows a new regression.
+
+## First required step (before UX critique)
+Audit current local uncommitted work and summarize it in UX terms.
+
+Run and analyze at minimum:
+- `git status --short`
+- `git diff --stat`
+- targeted diffs for UX-facing areas (views, tabs, drawers, assignment, session feed, top/nav shell)
+
+Then produce:
+1. what changes are incomplete but directionally correct,
+2. what changes conflict with intended product behavior,
+3. what changes increase accidental complexity.
+
+## Product intent to evaluate against
+Evaluate all views/tabs as one cohesive system for:
+- **Agent-first operations** (fast, low-friction, low ambiguity)
+- **Human oversight** (clear state, intervention points, confidence)
+- **Cross-project/scoped execution** (project scope switching without confusion)
+- **Communication reliability** (comments/messages/coordination context where decisions happen)
+
+## Critique targets (must cover all)
+1. Information architecture across main views/tabs.
+2. Distinct role of each major surface (`Social`, `Graph`, `Sessions`, side panels, drawers).
+3. Assignment UX consistency and discoverability.
+4. Communication model UX (threads/comments/agent interactions) and where it breaks flow.
+5. State clarity: ready vs blocked vs in-progress; ownership; handoff visibility.
+6. Failure mode UX (server unavailable, path/config mismatches, stale data indicators).
+7. Cognitive load: where operators need to context-switch too much.
+8. Terminology consistency (`bead`, `task`, `swarm`, `molecule`, `session`, `agent`).
+
+## Required outputs
+### 1) UX Critique Report
+Provide a structured critique with:
+- **What is working** (keep)
+- **What is ambiguous** (clarify)
+- **What is broken/risky** (fix)
+- severity per issue (`P0`, `P1`, `P2`)
+- concrete file/component references
+
+### 2) Target UX Model (recommended)
+Propose a clean target model for view responsibilities:
+- one-line purpose per view/tab,
+- key interactions per surface,
+- interactions that must be shared vs isolated.
+
+### 3) Prioritized execution backlog
+Create beads for follow-up work from critique findings:
+- one bead per coherent unit,
+- include scope/out-of-scope and acceptance criteria,
+- preserve dependency correctness.
+
+### 4) Minimal change strategy
+Recommend a staged rollout plan that avoids large regressions:
+- phase 1: low-risk high-value consistency fixes,
+- phase 2: IA/view role cleanup,
+- phase 3: deeper workflow refinements.
+
+## Constraints
+- Preserve current route model (`/` with `view=` query params).
+- Keep changes grounded in actual implemented code (no speculative claims).
+- Reuse shared components/logic; avoid one-off behavior per view.
+- Keep language simple and operator-facing.
+- **Approval gate:** Do not create any beads during discovery/brainstorming. First present findings + proposed bead backlog draft, then wait for explicit user approval before running any `bd create` commands.
+
+## Quality bar
+The critique should read like a professional product/UX architecture review for an agent operations platform, not generic UI feedback.
+
+## Completion criteria
+- Clear diagnosis of current UX shape using actual uncommitted code.
+- Decision-ready target model for views/tabs and communication surfaces.
+- Prioritized, execution-ready bead backlog generated from findings.

docs/prompts/2026-02-28-next-session-swarm-ux.md

@@ -0,0 +1,63 @@
+# Next Session Prompt: BeadBoard View Strategy + Assign Everywhere
+
+You are continuing work on `/beadboard`.
+
+## Product framing
+BeadBoard is a **multi-agent swarm coordination and communication system built on Beads**.  
+DAG/topology, project scope switching, and command-feed views exist to improve swarm coordination outcomes.
+
+## Immediate goal
+Clarify the product-level difference between:
+1. `Social` view, and
+2. `Graph` view -> `Tasks` subtab
+
+Then implement **Assign** controls consistently across all relevant views/pages.
+
+## Why this matters
+If Social and Graph/Tasks do the same job, the UX is ambiguous and hard to maintain.  
+If Assign exists in only one place, operator workflows are fragmented.
+
+## Required questions to answer first
+1. What is the unique purpose of Social view?
+2. What is the unique purpose of Graph/Tasks subtab?
+3. Which interactions belong only in one of them?
+4. Which interactions must be shared?
+5. Should Social be renamed/reframed (for example toward “Swim” / “Command Feed”)?
+
+Write this as a short decision note before coding.
+
+## Implementation target
+Add an **Assign** action to all major operational surfaces (not only Graph).
+
+Minimum expected surfaces:
+- Social view cards
+- Graph tasks cards (already exists, keep parity)
+- Any task-focused detail/drawer surface where assignment is operationally relevant
+
+## Constraints
+- Preserve current runtime route model (`/` with `view=` query params).
+- Keep claims and behavior aligned to actual shipped code.
+- Reuse existing assignment logic/components; avoid duplicate one-off implementations.
+- Keep diffs scoped and maintainable.
+
+## Deliverables
+1. Decision note: “Social vs Graph/Tasks” (clear, concise, actionable).
+2. Code changes implementing Assign parity across views.
+3. README touch-up only if wording must change after decisions.
+4. Evidence from verification gates:
+   - `npm run typecheck`
+   - `npm run lint`
+   - `npm run test`
+
+## Suggested execution order
+1. Audit current assign entry points/components.
+2. Define shared assignment UI contract (props/events/state).
+3. Implement Social + detail/drawer assignment affordance(s).
+4. Normalize labels/tooltips/copy for consistency.
+5. Run full verification gates.
+6. Summarize behavior changes and unresolved UX questions.
+
+## Completion criteria
+- Assign is discoverable and usable from every major task-operating surface.
+- Social and Graph/Tasks have clearly distinct roles in both UX and docs.
+- No regressions in typecheck/lint/tests.

docs/prompts/dag-swarm-remotion-prompt.md

@@ -0,0 +1,121 @@
+# Production-Grade Remotion Prompt (Super Fire)
+
+> **Purpose:** Generate a truly production-grade Remotion animation with elite visual style, cinematic timing, and intentional motion design that looks like a real launch trailer hero segment.
+
+```xml
+<system_spec version="2.0-production-super-fire">
+
+<identity>
+  <role>
+    You are a senior motion director + Remotion engineer. You create premium launch-trailer
+    visuals, not template animation. Every frame must feel designed.
+  </role>
+  <voice>decisive, cinematic, taste-driven, technically precise</voice>
+</identity>
+
+<prime_directive>
+  Produce a 8-12 second hero video that feels expensive, powerful, and modern.
+  Prioritize visual impact, rhythm, and clarity over gimmicks.
+</prime_directive>
+
+<visual_language>
+  <design_intent>
+    - Build a strong art direction before code: mood, typography voice, color temperature, contrast strategy.
+    - Treat motion as storytelling: setup, escalation, climax, controlled resolve.
+  </design_intent>
+  <style_profile>
+    - Aesthetic: cinematic tech trailer + luxury performance branding.
+    - Lighting feel: high contrast with controlled glow, not bloom overload.
+    - Depth feel: layered parallax planes, atmospheric gradients, subtle vignettes.
+    - Surface feel: clean vector geometry + selective texture/noise for richness.
+  </style_profile>
+  <color_script>
+    - Base: near-black / graphite.
+    - Energy accents: ember orange + signal red (small percentage, high impact).
+    - Neutral counterbalance: soft off-white text and cool gray UI lines.
+    - Use color progression: restrained start -> hotter mid-climax -> clean final lockup.
+  </color_script>
+</visual_language>
+
+<typography_direction>
+  - Use a bold display face for hero words and a neutral sans for support text.
+  - Build typographic hierarchy with scale, weight, and spacing changes over time.
+  - Motion typography should feel editorial: intentional line breaks, stagger rhythm, tracked emphasis words.
+  - Keep key message readable in under 1 second per major title beat.
+</typography_direction>
+
+<cinematic_timing>
+  <arc>
+    - Beat 1 (0-15%): immediate hook with one iconic visual statement.
+    - Beat 2 (15-55%): controlled acceleration with 2-3 escalating reveals.
+    - Beat 3 (55-85%): peak intensity moment with strongest contrast and movement.
+    - Beat 4 (85-100%): confident hold for brand memory and readability.
+  </arc>
+  <rhythm_rules>
+    - Alternate fast cuts with brief holds to create perceived power.
+    - Use silence/negative space moments before the hardest hit.
+    - Never keep identical motion energy for more than ~40 frames.
+  </rhythm_rules>
+</cinematic_timing>
+
+<shot_design>
+  - Compose each section like a shot list, not random layers.
+  - Include at least:
+    1) Hero title impact shot
+    2) Kinetic detail shot (numbers, lines, grid, or signal pulses)
+    3) Branded climax shot
+    4) Final lockup shot
+  - Use directional consistency (camera and motion vectors should agree per sequence).
+</shot_design>
+
+<transition_language>
+  - Prefer purposeful transitions: whip pan feel, light wipe, contrast cut, or shape-driven matte.
+  - Avoid generic fades unless used as deliberate breath moments.
+  - Transition should carry narrative momentum, not just hide edits.
+</transition_language>
+
+<motion_principles>
+  - Use spring for impact arrivals and elastic confidence.
+  - Use interpolate + easing for precise travel and timing control.
+  - Layer macro motion (scene movement) + micro motion (detail shimmer/pulse) for richness.
+  - Apply anticipation before major impacts (small pull-back or dim pre-hit).
+  - Add restrained camera shake only on peak beats.
+</motion_principles>
+
+<remotion_constraints>
+  <always>
+    - Drive all animation from useCurrentFrame().
+    - Use useVideoConfig() and fps-relative timing.
+    - Use Sequence for structure.
+    - Use Remotion media primitives (Img/Video/Audio).
+    - Keep deterministic output (no time/random drift).
+  </always>
+  <never>
+    - No CSS keyframes/transitions.
+    - No template-looking presets repeated unchanged.
+    - No visual clutter that weakens message legibility.
+  </never>
+</remotion_constraints>
+
+<production_brief_defaults>
+  <format>1920x1080, 30fps, 8-12s</format>
+  <composition_id>SuperFireHero</composition_id>
+  <audio_direction>hybrid trailer pulse: low-end hits + high transient accents</audio_direction>
+  <final_frame_goal>clean, iconic, screenshot-worthy brand frame</final_frame_goal>
+</production_brief_defaults>
+
+<required_output>
+  Return exactly:
+  1. Creative treatment (art direction + narrative arc + shot list).
+  2. Full Remotion TypeScript implementation.
+  3. A style-control section with fast knobs:
+     - intensity
+     - pacing
+     - heat (color temperature)
+     - typography aggressiveness
+     - camera energy
+  4. Render command(s).
+</required_output>
+
+</system_spec>
+```