Design local dashboard after observability data is ready

[codeforester]

Problem

A local Base dashboard could make workspace health, project status, doctor findings, recent command runs, and onboarding state easier for team leads and less CLI-fluent users to understand. The risk is building a UI before Base has enough structured local data to support it cleanly.

Desired outcome

Define the dashboard sequencing: what local observability, status, and finding data must exist first, and what a future basectl serve or equivalent dashboard should show once that data is ready.

Scope

• Inventory the local data Base can already expose: workspace status, last check records, doctor findings, logs, project manifests, and command history.
• Identify gaps that should be solved in CLI/JSON/observability surfaces before a dashboard.
• Define the first useful dashboard view without making it a separate product surface.
• Decide whether the entry point should be basectl serve, a static report, or another local-only mechanism.
• Capture privacy, local-only behavior, and browser-launch expectations.

Non-goals

• Do not build the dashboard before the data contract is ready.
• Do not add a hosted service or remote telemetry.
• Do not replace CLI text and JSON surfaces with the dashboard.

Acceptance criteria

• A design document or follow-up implementation issue defines dashboard prerequisites.
• The first dashboard slice is tied to existing or planned structured local data.
• The design explains local-only behavior, privacy boundaries, command entry point, and how dashboard output stays consistent with CLI diagnostics.