zenchantlive c246ceaf21 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>

2026-03-01 18:17:58 -08:00

2.5 KiB

Raw Blame History

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:

Social view, and
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

What is the unique purpose of Social view?
What is the unique purpose of Graph/Tasks subtab?
Which interactions belong only in one of them?
Which interactions must be shared?
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

Decision note: “Social vs Graph/Tasks” (clear, concise, actionable).
Code changes implementing Assign parity across views.
README touch-up only if wording must change after decisions.
Evidence from verification gates:
- npm run typecheck
- npm run lint
- npm run test

Suggested execution order

Audit current assign entry points/components.
Define shared assignment UI contract (props/events/state).
Implement Social + detail/drawer assignment affordance(s).
Normalize labels/tooltips/copy for consistency.
Run full verification gates.
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.

2.5 KiB Raw Blame History