Quality and performance improvements

Problem

Post-v1.0 user feedback and telemetry will surface specific quality and performance pain points: diagnostics that are too slow to feel real-time, preview rendering that lags on complex dashboards, memory usage that grows unbounded during long editing sessions, or diagnostic accuracy gaps where valid YAML is flagged as invalid (or vice versa). These issues erode the perception of quality even when core functionality works. Without tying improvement work to measurable user-facing outcomes — diagnostic latency p95, preview render time, false-positive rate, crash-free session rate — the team risks optimizing things that don't matter while ignoring what users actually feel.

Context

• Once analyst authoring in VS Code/Cursor with preview, diagnostics, and assist is in regular use, quality and performance work needs to target the actual slow, flaky, or costly paths rather than generic optimization ideas.
• The right scope here is evidence-driven: identify bottlenecks, remove the highest-friction issues, and make sure the fixes are measurable and regression-resistant.
• Expected touchpoints include apps/ide/vscode-extension/, preview/inspector runtime code, and extension docs/tests, telemetry or QA evidence, and any heavy workflows where users are paying the cost today.

Possible Solutions

• A - Tune isolated hotspots as they are reported: useful for emergencies, but it rarely produces a coherent quality/performance program.
• B - Recommended: prioritize measurable bottlenecks and quality gaps: couple performance work with correctness and UX validation so improvements are both faster and safer.
• C - Rewrite broad subsystems for theoretical speedups: tempting, but usually too risky and poorly grounded for this milestone.

Plan

1. Identify the biggest quality and performance pain points in analyst authoring in VS Code/Cursor with preview, diagnostics, and assist using real usage data, QA findings, and support feedback.
2. Choose a small set of improvements with clear before/after measures and explicit user-facing benefit.
3. Implement the fixes together with regression checks, docs, or operator notes wherever the change affects behavior or expectations.
4. Review the measured outcome and turn any remaining hotspots into sequenced follow-up tasks instead of leaving them as vague future work.

Implementation Progress

Review Feedback

• [ ] Review cleared