Dataface Tasks
    Heartbeat snapshot (JSON)

    M3 chart and visualization extensibility

    Objective

    Research how Vega, Vega-Lite, major charting libraries, headless BI tools, and declarative UI frameworks enable custom visualizations and extensions. Recommend a lightweight path for Dataface (Python, SVG-first). Preferred default: type: inline as a normal built-in chart, shipped early, so many teams never need a separate plugin / registry system. No rich HTML widget framework. If Dataface ships with dbt (locked installer / Cloud image), inline + dbt-package templates carry most extensibility; Python plugins behave like blessed extras, not ad hoc pip install — see spec §4.5. Capture implications for chart module layout and YAML schema versioning.

    Milestone coordination

    • type: inline can ship as soon as it is ready (often M2 or earlier if scope is tight); it should not wait on the full extensible schema / registry task unless we choose to couple them.
    • M3 remains the umbrella for optional catalog/registry/Python extension work (extensible-schema-with-custom-elements-and-chart-types), potentially smaller if inline satisfies most “custom chart” demand.
    • M2 owns YAML schema versioning and migrations (task-m2-yaml-version-migrations); inline payload keys and any later extension IDs should version cleanly.

    Deliverables

    • [ ] Complete research review with graph-library + dft-core stakeholders.
    • [ ] Adopt or revise the recommended tiered model in spec.
    • [ ] Record ADRs in decisions (first ship: VL templates vs Python; naming).
    • [ ] Add a worked example (e.g. streamgraph) using inline (vega_lite → vega if needed).
    • [ ] Ensure implementation tasks reference versioning rules from M2 before M3 code merge.