Public launch scope completion

Problem

The connector dashboard pack feature set has been iterated through internal pilots and design partners, but launch-critical gaps remain: some packs may not handle production edge cases gracefully, error behavior for missing or stale connector data is undefined, and there is no rollback plan if a published pack causes problems for users. Shipping without closing these gaps risks a public launch where users encounter broken dashboards, confusing errors, or data they can't trust—with no clear path to recover. Every launch-blocking issue must be resolved with production-safe behavior before the feature goes public.

Context

• The backlog for connector-specific dashboard packs and KPI narratives for Fivetran sources 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 dashboard pack YAML, dbt/example assets, connector fixtures, and quickstart docs, 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 connector-specific dashboard packs and KPI narratives for Fivetran sources 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