Public launch scope completion

Problem

The extension has been validated with internal teams and design partners, but several launch-critical gaps remain before it can be published to the VS Code marketplace for general use. Production-safety concerns are unresolved: the extension may execute queries against user databases without adequate sandboxing, preview rendering has no timeout or resource limits for malformed dashboards, and there is no versioned rollback mechanism if a release introduces regressions. The boundary between "works for known internal projects" and "safe for arbitrary external users" has not been systematically audited. Shipping without closing these gaps risks data-safety incidents and a poor first impression that is hard to recover from.

Context

• The backlog for analyst authoring in VS Code/Cursor with preview, diagnostics, and assist 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 apps/ide/vscode-extension/, preview/inspector runtime code, and extension docs/tests, 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 analyst authoring in VS Code/Cursor with preview, diagnostics, and assist 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