[Feature] Web UI dashboard for task DAG visualization

[JackChen-me]

Summary

Build a web-based dashboard that visualizes the task DAG, agent status, and execution progress in real-time.

Motivation

Multi-agent workflows can be complex. A visual representation would help users:

• Understand the task dependency graph at a glance
• Monitor which agents are running, waiting, or completed
• Debug failures by seeing where the pipeline broke
• Demo the framework to stakeholders

Proposed Approach

• Lightweight web server (express or built-in http) serving a single-page app
• DAG rendered with a graph library (e.g., D3, dagre, or elkjs)
• WebSocket connection for real-time status updates
• Display: task nodes with status colors, agent assignments, execution time, token usage

Design Sketch

[Architect: Design API] ──→ [Developer: Implement] ──→ [Reviewer: Review]
     ✅ Done (2.3s)              🔄 Running              ⏳ Waiting

Open Questions

• Ship as a separate package or built-in opt-in?
• How much detail to show (full LLM conversation, tool calls, etc.)?

[riturajFi]

@JackChen-me I am working on this :)

[ibrahimkzmv]

I used Google Stitch, and it created the design below:

I know things like deployment, etc., are irrelevant. Just sharing for inspiration

what do you think @JackChen-me @riturajFi

[JackChen-me]

Like the detail panel idea, keeping that.

v1 scope: static HTML file after execution. DAG + status colors, click node to see token/duration/tool calls. No server, no new deps for now.

v2: live monitoring during execution via WebSocket. v3: interactive control (pause, intervene, redirect agents mid-run), depends on more core work.

@riturajFi you mentioned working on this, still interested? If so you'd own v1, @ibrahimkzmv's design can be a reference.

[JackChen-me]

@riturajFi no update for a while, opening this up.

v1 scope: static HTML post-execution. DAG + status colors, click node for token/duration/tool calls. No server, no new deps.

@ibrahimkzmv interested?

[ibrahimkzmv]

Sure, I can work on this

[JackChen-me]

Tracking the framework/CLI split from PR #122.

// src/types.ts, framework core, domain-neutral
export interface TaskExecutionMetrics {
  readonly startMs: number
  readonly endMs: number
  readonly durationMs: number
  readonly tokenUsage: TokenUsage
  readonly toolCalls: readonly ToolCallRecord[]
}

export interface TaskExecutionRecord {
  readonly id: string
  readonly title: string
  readonly assignee?: string
  readonly status: TaskStatus
  readonly dependsOn: readonly string[]
  readonly metrics?: TaskExecutionMetrics
}

// TeamRunResult gains:
readonly goal: string
readonly tasks: readonly TaskExecutionRecord[]

// src/dashboard/index.ts
export function renderTeamRunDashboard(result: TeamRunResult): string

Framework types stay domain-neutral so future consumers (trace exporter, JSON log writer, alternate renderers) can reuse them without inheriting a dashboard prefix. Non-breaking for existing TeamRunResult consumers, just lifts what RunContext.taskMetrics already tracks.

CLI side: oma run --dashboard (default off) calls the renderer and writes to disk.

Security and network-dep notes from the PR #122 review still apply on the renderer side.