Skip to main content
comet dashboard opens a local read-only browser interface for both Comet workflows. Use the switch in the upper-left corner to show either the detailed Classic workspace or the lightweight Native workspace; the two views are not mixed on one page.

Comet Dashboard light mode

Comet Dashboard dark mode

Comet Dashboard markdown preview

​
Start it

Useful options:

​
Classic / Native switch

Dashboard provides a Classic / Native workflow switch in the upper-left corner. Both workspaces use the same project-summary, Changes Explorer, change-detail, and status-sidebar structure, but only the selected workflow is shown. The Native view reads comet-state.yaml directly and adds a local overlay only when its change and state version match; Dashboard does not rerun checks or re-derive workflow facts. Each Native change shows:
  • Current phase/status: Shape, Build, Verify, Archive, await-user, or blocked
  • Loop iteration, attempt, actor, and next action
  • Passed, failed, blocked, and pending acceptance counts with per-item reasons
  • Builder handoff, Runtime checks, Verifier verdict, and risks
  • Blockers, bounded history, and history-overflow information
  • User-readable brief, complete target Specs, comet-state.yaml, and verification.md
  • Whether the local overlay is running, interrupted, or absent (absence is expected for a completed change)
The Native view provides Active, Archived, and All filters and uses the same Markdown preview drawer as Classic. The Changes Explorer loads lightweight rows in pages and fetches complete detail only after selection; it keeps the current detail visible while loading and offers a retry when a request fails. Use comet native status --details and the other Native CLI commands for complete diagnostics.
The Native view is read-only: it summarizes portable YAML and user documents. It does not expose absolute paths, raw logs, execution IDs, or local Runtime files, and it has no progression, repair, or Archive controls. Native CLI and Runtime remain the only writers.

​
View Supervisor Changes and child changes across Git worktrees

Dashboard scans the worktrees registered for the current Git repository. Each worktree keeps its own branch or directory label, so Classic and Native changes from another working directory remain separate. Native Supervisor Changes show child completion progress and an expand control. Expand a Supervisor Change to select a child and inspect its phase, workspace, and detail. An independent Native change remains a root entry.
Dashboard only discovers and displays state. It does not create worktrees, advance Supervisor Changes or child changes, or run verification. Use /comet-native and the comet native commands to perform those actions.

​
What the Classic workspace shows

  • Active and archived changes.
  • Phase and workflow state.
  • Verification status, with passed, failed, pending, and unknown Classic changes distinguished by color.
  • Proposal, design, tasks, Design Doc, Plan, and verify reports.
  • Runtime status, risk signals, and Git context.
  • Markdown previews for artifacts, including tables, quotes, task lists, syntax highlighting, Mermaid diagrams, and structured YAML/JSON tables (.comet.yaml and handoff/checkpoint files render as tables instead of raw text).
The workspace remains within the viewport when the left explorer is open. Artifact previews remember the current scroll position and return to it when closed. Archived changes are shown as complete rather than being sent back to verify, and their project-root docs/superpowers/ Design Docs, Plans, and verification reports remain available. When Dashboard is launched from a nested repository directory, it first locates the project root. Classic data is collected from the root selected by classic.artifact_layout: docs/openspec/changes/ for the default documentation layout or openspec/changes/ for a retained legacy layout, including the corresponding changes/archive/ directory. Native data is read from the configured Native artifact root. Both views are read-only and best effort. A collection failure is shown as an error instead of an empty workspace and does not prevent the other workflow snapshot from loading.
Last modified on August 13, 2026