c246ceaf21
- 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>
63 lines
2.5 KiB
Markdown
63 lines
2.5 KiB
Markdown
# 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.
|