Add render command for precomputed dashboard data artifacts

ID	DASHBOARD_FACTORY-ADD_RENDER_COMMAND_FOR_PRECOMPUTED_DASHBOARD_DATA_ARTIFACTS
Status	cancelled
Priority	p2
Milestone	m1-ft-analytics-analyst-pilot
Owner	data-analysis-evangelist-ai-training

Cancelled (2026-03-23). No separate “precomputed JSON → render” CLI. Structured JSON output is already add-json-render-output-format (completed). Frozen round-trip / offline re-render is add-resolved-yaml-render-output-format (format=yaml, valid face YAML with values:).

Problem (archived rationale)

The “freeze then re-render without the warehouse” story is not best expressed as a bespoke JSON snapshot + special CLI if we can emit valid Dataface YAML where every query is materialized as inline values: data. That artifact is human-readable, agent-native, and round-trips through the normal compiler — exactly the intent captured in add-resolved-yaml-render-output-format (format=yaml / resolved YAML).

Context

Filed elsewhere (your read is right)

add-resolved-yaml-render-output-format — ready (p2). Resolved output as valid dataface YAML, queries → values:, re-runnable without DB once compile/render fully support that path. This is the original “orig intent” for a frozen, re-renderable artifact.
add-json-render-output-format — Completed. Structured JSON of resolved face + data for MCP, tests, and “what did the engine decide?” — still useful; it is the natural input shape to map into resolved YAML (per the YAML task’s plan).

Is JSON-only “precomputed render” still useful?

Yes for machines: agents, diffs, eval harnesses, quick pipes — JSON is done and good.
For humans and round-trip: prefer resolved YAML; avoid maintaining a second frozen format unless JSON replay stays strictly internal.

Pipeline today

dft render is YAML → compile → execute → render.

Plain English: “values / adapter” (the confusing note)

In face YAML, a query can be sql: (run against a warehouse) or values: (rows inlined in YAML). For resolved YAML to work as a frozen snapshot, re-rendering must treat values: queries as “data is already here — do not hit the DB.”

The DuckDB metrics pipeline task recorded a real bug/limitation: in at least one path, dft render hit No adapter found for query type: values, so that pipeline worked around it by writing CSV files and pointing queries at files instead of inline values. That is not an argument for a second JSON format — it means fix values (and/or file-backed queries) in the normal render path while implementing format=yaml. Same workstream as add-resolved-yaml-render-output-format.

Possible Solutions

Plan

Implementation Progress

2026-03-23: Cancelled — superseded by resolved YAML + existing JSON render format; see banner above.

QA Exploration

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

N/A for browser QA. Validation: render a dashboard from a saved artifact, compare output to the same dashboard rendered through the full pipeline.

Review Feedback

[ ] Review cleared