Cross-dashboard changed charts view with canonical links

Problem

Analysts working in a dbt repo with many face files cannot see, in one place, which charts are “hot” after edits. Git shows file-level diffs, and dbt lineage is model-centric—not chart-centric—so it is easy to miss a chart on another dashboard that reuses a query or references a model that just changed. The extension already understands faces and previews; without a cross-dashboard aggregate, users still hunt board-by-board to find what to re-preview or fix.

Context

• Canonical chart location means the defining face YAML file plus a stable in-file identity: chart id / YAML key path (whatever the compiler uses as the chart’s logical id). Links should use vscode.open (or equivalent) to that uri + range or symbol, not only the dashboard file without scrolling to the chart block.
• Chart diff bucket: dirty buffers, workspace edits since open, and/or diff against HEAD (git) for the face file—define which signals are in M3 v1 and which are follow-ups.
• Model-change bucket: requires resolving each chart’s query → dbt model(s) (and possibly sources); compare against changed .sql / .yml in git status or dbt ls / manifest—spike which source of truth is reliable inside the extension host.
• Likely touch: apps/ide/vscode-extension/ (tree view, webview, or command palette results), shared logic if dft-core already exposes compile metadata for query→model mapping.
• Multi-root workspaces, unsaved files, and charts inlined vs extracted to shared YAML are edge cases; document explicit behavior.

Possible Solutions

1. Tree view (Activity Bar) — Two top-level nodes: “Chart definition changed”, “Upstream model changed”; children grouped by dashboard (face title or file basename), then chart rows with “reveal in editor”. Pros: native VS Code pattern, persistent. Cons: tree UX limits rich columns (e.g. last commit, model name).

2. Webview dashboard — Single scrollable page with two sections and sticky dashboard headings; rows are links. Pros: room for columns, badges, filters. Cons: more UI code, theming, accessibility work.

3. Command palette quick-pick — Fuzzy list merged from both buckets. Pros: fastest to ship. Cons: poor scanning for “all charts on board X”; weak grouping.

Recommended: Tree view for M3 with two roots and dashboard-grouped second-level nodes; add optional Open in editor code lens or secondary command if a flat list is needed later. If design demands columns, iterate to webview in a follow-up task.

Plan

1. Spec: Define “chart changed” (git diff on face path vs last saved buffer) and “model changed” (manifest/ref graph vs git diff model paths or dbt artifact watcher)—write acceptance criteria and known false positives.
2. Index: On workspace open and on relevant file save/git change, build an in-memory map: dashboard (face file) → charts → query ids → resolved model paths (reuse compile/inspect if available).
3. UI: Implement the tree (or chosen surface); each leaf: chart display name, command to open canonical chart location; parent nodes = dashboard (face).
4. Refresh: Debounce file watcher + git events; document cost on huge repos (cap + “refresh” button if needed).
5. Tests: Unit-test the classifier (which bucket) with fixture faces + mock git/model change sets; extension integration test if the repo already has patterns.
6. Docs: User-facing paragraph in extension README or docs: what each bucket means and what it does not cover (e.g. macro-only changes, ephemeral SQL).

Implementation Progress

QA Exploration

Extension UI (not Cloud web): run Extension Development Host with a multi-face sample workspace; verify both buckets populate, dashboard grouping, and reveal-navigation to the correct chart block. Playwright MCP is N/A unless this ships as a webview tested in a browser harness—if so, note the URL/surface here.

• [ ] QA exploration completed (or N/A for non-UI tasks)

Review Feedback

• [ ] Review cleared