v1.2 release and migration readiness

Problem

The v1.2 release may introduce breaking changes to extension settings, YAML schema expectations, MCP tool contracts, or profiler/inspector panel APIs. Users on v1.0 need a clear upgrade path — what changed, what action they need to take, and whether their existing dashboards will continue to work. Without migration guides, changelog documentation, and in-extension upgrade notifications, users will experience silent breakage after auto-update or will avoid upgrading entirely, fragmenting the user base across versions. Release readiness also requires validating that the upgrade path works across the supported matrix of VS Code versions, OS platforms, and dbt project configurations.

Context

• Deeper or changed behavior in analyst authoring in VS Code/Cursor with preview, diagnostics, and assist often creates migration work for users, operators, or downstream systems, and that work is easy to underestimate until release time.
• This task should make the release path explicit: what is changing, who is affected, what needs communication or tooling help, and how rollback would work if adoption goes sideways.
• Expected touchpoints include apps/ide/vscode-extension/, preview/inspector runtime code, and extension docs/tests, release notes, migration docs, compatibility checks, and any support/runbook surfaces that will absorb the change.

Possible Solutions

• A - Treat release readiness as a final checklist after implementation: simple, but it often surfaces migration risk too late to respond well.
• B - Recommended: plan release and migration alongside the feature depth work: document contract changes, compatibility handling, communication, and rollback before the release window.
• C - Force all users onto the new behavior with minimal migration help: faster to ship, but costly in trust and support load.

Plan

1. List the behavior, contract, or configuration changes in analyst authoring in VS Code/Cursor with preview, diagnostics, and assist that could affect users, operators, or downstream consumers.
2. Define the migration path, release notes, compatibility expectations, and any temporary bridges or tooling needed for safe adoption.
3. Confirm the rollback and support posture for the riskiest changes and make sure the release owner surfaces are documented.
4. Review the plan against the actual implementation scope and create follow-up items for anything that cannot safely make the release cut.

Implementation Progress

Review Feedback

• [ ] Review cleared