Highlight charts using branch dev schema versus prod fallback

Problem

In branch-based dbt workflows, schema names are dynamic (branch/user/env-aware) and model relations may exist only for changed models. The common pattern is: attempt relation resolution in branch/dev schema first, then fall back to prod/default relation when no branch relation exists.

Today, dashboard users cannot tell which charts are actually reading changed branch relations versus unchanged prod relations. This makes branch review slower and increases risk of false confidence when validating dashboard changes.

Context

• Existing related task: tasks/workstreams/ide-extension/tasks/cross-dashboard-changed-charts-view-with-canonical-links.md (IDE aggregate view, M3).
• This task is different: chart-level status directly in dashboard render surfaces (serve/cloud), not just IDE cross-dashboard inventory.
• Dataface execution paths currently include dbt-aware and non-dbt adapter paths; schema-resolution correctness for BigQuery/dbt relation identity is tracked separately in:
• tasks/workstreams/dft-core/tasks/ensure-dbt-generate-schema-name-safe-bigquery-ref-source-resolution.md
• Desired signal:
• changed: query resolved to branch/dev schema object(s)
• unchanged: query resolved only to prod/default object(s)
• unknown: insufficient provenance to classify
• Scope should include explicit behavior limits for ephemeral models, partial manifests, and missing metadata.
• Key architecture insight: dbt manifests contain per-model schema fields. The dev manifest (target/manifest.json) reflects the current branch build; the committed manifest.snapshot.json serves as the prod baseline. Comparing schemas between manifests gives accurate changed/unchanged classification.
• Provenance flow: resolve_dbt_refs in dbt_utils.py → SqlAdapter._resolve_dbt_sql → Executor._provenance_cache → _render_chart_item_inner reads provenance and sets data-schema-status on the chart SVG wrapper.
• Limits: Ephemeral models are not materialized and won't appear in manifest schema comparison. Partial manifests (no snapshot) yield unknown. Non-dbt queries have no provenance.

Possible Solutions

1. Recommended: Query provenance instrumentation + chart badge classification - Instrument adapter execution to record resolved relation targets per query (dev/prod classification). - Attach per-query provenance to execution result metadata and map it to chart status at render time. - Render a compact chart badge (changed/unchanged/unknown) with tooltip details. - Pros: accurate and runtime-truthful, works per chart, extensible for future aggregate views. - Cons: requires plumbing metadata through executor and render layers.
2. Static pre-execution diff only - Infer changed state from manifest/git/model diffs without runtime resolution. - Pros: simpler runtime. - Cons: lower accuracy for fallback behavior and dynamic adapter logic.
3. IDE-only indicator - Rely on existing/future extension views only. - Pros: avoids runtime changes. - Cons: misses cloud/serve dashboard consumers and inline review workflow.

Plan

1. Define provenance contract: - Query execution returns relation targets and resolution mode (dev hit, prod fallback, unknown).
2. Add adapter/executor plumbing: - Capture resolved relation identity in SQL execution path. - Persist metadata per query execution for chart mapping.
3. Add renderer UI states: - Chart-level badge and tooltip with source relation namespace summary.
4. Add classification logic: - Determine changed/unchanged/unknown based on namespace policy and fallback semantics.
5. Validate in branch workflow: - Repo with dynamic dev schema naming and mixed changed/unchanged models.
6. Document limits and ops behavior: - Unknown-state reasons and troubleshooting guidance.
7. Coordinate follow-ups: - Feed same metadata into the IDE cross-dashboard changed-charts task for aggregate views.

Implementation Progress

• 2026-03-23: Task created from Garegin feature request.
• 2026-03-23: Scoped as in-dashboard runtime highlighting, explicitly linked to existing IDE cross-dashboard task and dbt relation-resolution hardening task.
• 2026-03-23: Implementation complete (Option 1 — query provenance instrumentation):
• [x] ResolvedRelation dataclass + SchemaStatus type in base.py
• [x] classify_schema_status() and resolve_dbt_refs_with_provenance() in dbt_utils.py
• [x] SqlAdapter captures provenance during _resolve_dbt_sql, attaches to QueryResult
• [x] SqlAdapter loads prod manifest from manifest.snapshot.json for baseline comparison
• [x] Executor._provenance_cache stores per-query provenance, exposed via get_query_provenance()
• [x] Chart renderer adds data-schema-status attribute and dft-schema-{status} CSS class
• [x] _resolve_schema_status() aggregates per-relation statuses (changed > unknown > unchanged)
• [x] 21 regression tests covering all layers in tests/core/test_schema_provenance.py

QA Exploration

• [x] N/A — This is a data-attribute and CSS class change on the SVG chart wrapper. No visible UI change without downstream CSS/JS consumers (Suite, IDE extension). Visual verification deferred to the downstream tasks that consume data-schema-status to render badges/highlights.

Review Feedback

• [ ] Review cleared