Sustainable operating model

Problem

The extension is maintained through ad-hoc heroics: one or two engineers handle all support questions, triage is informal, release timing is opportunistic, and there is no on-call rotation or escalation path. This works at small scale but becomes unsustainable as the user base grows post-launch. Without a documented operating model covering support channels, triage cadence, release process, on-call responsibilities, and contributor onboarding, the extension will either burn out its maintainers or suffer from neglect as attention shifts to new features. A v1.0 product needs operational maturity, not just code maturity.

Context

• A launch can succeed briefly even with fuzzy ownership, but analyst authoring in VS Code/Cursor with preview, diagnostics, and assist will drift quickly without a clear model for maintenance, triage, and decision-making.
• This task is about defining who owns backlog hygiene, review standards, incidents, documentation, and the cadence for future improvements.
• Expected touchpoints include apps/ide/vscode-extension/, preview/inspector runtime code, and extension docs/tests, runbooks, planning docs, and team processes that currently rely too heavily on shared memory.

Possible Solutions

• A - Let the current contributors coordinate informally: low overhead, but it becomes brittle as scope and contributors grow.
• B - Recommended: define a lightweight operating model with named owners and cadences: make maintenance, incident response, prioritization, and release decisions explicit.
• C - Centralize all ownership in one person or team indefinitely: clearer in the short term, but usually unsustainable and a bottleneck.

Plan

1. Map the recurring operational decisions around analyst authoring in VS Code/Cursor with preview, diagnostics, and assist and identify where ownership, handoff, or cadence is currently unclear.
2. Document the operating model: owners, review loops, incident or support handling, documentation upkeep, and backlog-management expectations.
3. Align the model with the actual command/docs/test surfaces that people use day to day so it is operational rather than aspirational.
4. Publish the model in the relevant planning/runbook surfaces and refine it after one real cycle of use.

Implementation Progress

Review Feedback

• [ ] Review cleared