Public launch scope completion

Problem

The graph library has open work items across chart types, theming, interaction behavior, and rendering edge cases — not all of which are required for public launch. Without a clearly scoped and completed set of launch-critical features with production-safe behavior (graceful error handling for unsupported chart configurations, no silent rendering failures, predictable output for all supported data shapes), the launch carries unquantified risk. Rollback clarity is also missing: if a critical rendering bug surfaces post-launch, there is no documented path to revert specific chart behaviors without regressing others.

Context

• The backlog for visual language, chart defaults, interaction behavior, and differentiated styling is broader than what public launch can safely absorb, so this task has to separate launch-critical scope from attractive but deferrable work.
• A credible launch needs stable default behavior, explicit unsupported cases, and a rollback story for the riskiest surfaces rather than a promise to finish everything.
• Expected touchpoints include dataface/core/render/chart/, chart design docs, examples, and visualization test coverage, launch checklists, and any tasks or docs that currently blur the line between required launch scope and post-launch follow-up.

Possible Solutions

• A - Keep the full backlog in scope until the last minute: preserves ambition, but guarantees launch risk remains unclear.
• B - Recommended: define a minimum externally supportable launch scope and close only those blockers: make explicit deferrals, owner assignments, and rollback expectations.
• C - Shrink scope aggressively to the point of a weak launch: lowers risk, but may undercut the product story and user value.

Plan

1. Audit the open work for visual language, chart defaults, interaction behavior, and differentiated styling and classify each item as launch-critical, launch-adjacent, or post-launch follow-up.
2. Document the required launch behaviors, known unsupported cases, and any rollback or kill-switch expectations for high-risk areas.
3. Close or explicitly defer the remaining blockers, linking each deferral to a tracked follow-up with clear risk notes.
4. Reconcile the launch scope with docs, QA/review evidence, and operator expectations so launch readiness is credible and explainable.

Implementation Progress

Review Feedback

• [ ] Review cleared