Terse Planner

Nightly prerelease. This build is a release candidate for testing, not an official stable release.

Terse Planner is a VS Code extension that turns a short request into a validated implementation plan, requires revision-specific approval by default, and executes dependency-ready tasks through explicit provider/model routes. Planning, review, and execution can independently use OpenAI Codex, Anthropic Claude, or an OpenRouter model compatible with that lifecycle phase.

Plan, review, and execute

1. Open a trusted file workspace and run Terse: New Plan.
2. Enter a request, optionally add supported workspace files, upload files from the computer running VS Code, or paste supported clipboard items, and create the plan. The selected planning provider/model runs read-only. A live, linked planning trace shows bounded, redacted workspace, tool, decision, and task-graph summaries. If the planning turn needs a decision, Terse pauses it in a clarification dialog; answer every question to continue, or choose Stop planning to cancel the pending request and turn. Transient provider errors are retried automatically with bounded backoff, with retry status shown in the planning trace.
3. Review the objective, constraints, task graph, acceptance criteria, and validation. Every task has an explicit repository-wide or workspace-relative predicted write scope. Material task or scope edits increment the plan revision, clear approval, and clear execution results from the older revision. The plan view also retains the prompt used to create the plan in a read-only Original request section, with no edit affordance.
4. Approve that exact revision, then execute it. Execution uses a workspace-write sandbox with per-request review for sensitive access; up to four dependency-ready tasks can execute concurrently within each plan, each with an independent provider agent session. Scope locks automatically serialize detected overlapping task scopes within and across plans, while disjoint ready scopes may execute concurrently. Completed tasks from the same plan revision are retained across cancellation, failure, restart, and resume.

For a quick task that does not need planning, choose Execute, enter the request, and run it directly. Terse creates an approved, repository-scoped single-task plan and sends it through the same execution, sandbox review, locking, persistence, cancellation, and result flow as a planned task; it only skips the planning-model turn.

terse.requireApproval defaults to true. Disabling it bypasses only the local approval gate and shows a warning; it is not a conflict-safety guarantee.

Automatic plan review

terse.automaticReview defaults to false. When explicitly enabled, each new or revised plan receives a second read-only review from its selected review provider/model before execution. Terse persists the decision, reason categories, timestamp, and plan revision separately from human approval; the revision's pinned review route records the provider/model. A continue decision can start only that exact revision and only while revision-specific approval protection remains enabled.

Automatic plan review fails closed to Human review required when the reviewer or output fails, the revision changes, policy checks find risks, open questions, unsafe or repository-wide scopes, sensitive operations, or a predicted execution conflict, or when review is cancelled or interrupted. Automatic continuation does not resume after an extension restart; the persisted review is retained as recovery context, but the plan returns to human review.

A model review is not proof of safety. It can miss hazards, misunderstand scope, or approve an incomplete plan. Deterministic checks reduce known risks but cannot establish that a plan or its execution is safe. Keep the default human, revision-specific approval flow for work that needs human judgment.

Tool-call sandbox review

The sandbox is native to Terse — no external binaries or kernel features. A static shell-effect analyzer proves the complete set of paths a command can write and enforces workspace containment and the approved write scope on those proven paths before the command runs: a command that provably writes outside the workspace is refused outright, and provably confined commands run with a credential-stripped environment. A shell request counts as sandboxed exactly when its effects were proven; anything the analyzer cannot prove — command substitution, interpreters, unrecognized programs — escalates to review as described below.

Automatic plan review and execution-time tool review are separate flows. terse.automaticReview controls only plan review. Sensitive tool requests always go through the revision's pinned review route first. The reviewer may continue an exact request only with a valid, high-confidence safe decision; otherwise Terse adds it to the Plan webview's Tool review queue for a person. Structural failures such as stale approval, identity mismatch, out-of-scope writes, and reviewer failure always escalate.

Each queue card shows the provider, task, tool, action category, detected write paths, bounded input, sandbox status, policy flags, reviewer verdict, and available reason summary. Details are redacted and bounded before rendering; credentials and hidden chain-of-thought are not exposed. Allow once applies to one request. Allow for this task creates a standing allowance scoped to the same plan revision, task, tool, and action category for the rest of that run. Deny returns bounded feedback so the same agent turn can try a safer alternative. Closing the webview or ending the run denies unresolved requests. None of these decisions creates session-wide permission.

A denial is non-terminal: Terse returns bounded feedback asking the same agent turn to reconsider and try a safe in-scope alternative. The agent should seek a plan revision only when no such alternative can complete the approved task.

Plan presentation and results

Run Terse: Open Plan or use a Terse view-container button to open the full Terse Plan webview in VS Code's right secondary sidebar. VS Code 1.96 through 1.105 does not support contributed secondary-sidebar containers, so Terse falls back to its primary Activity Bar container on those versions.

The Plan webview provides two presentations over the same task cards and actions:

• Board groups tasks by status into Queued, Running, Attention, and Done lanes.
• Flow groups tasks into Start and numbered Stage lanes by dependency depth, with directional connectors between dependencies. Lanes wrap to the available width, and connectors are redrawn when the view or sidebar is resized.

Choose either presentation from the View control. The choice survives a webview reload.

Flow includes text relationships for screen readers and when visual connectors are unavailable. Cycles and missing references are grouped under Attention with repair guidance; large plans keep dependency labels while suppressing an overcrowded connector layer. Both presentations share keyboard-openable task cards and the same edit, approval, execution, cancellation, and result paths. On cards, long provider summaries are escaped and capped at 280 characters. Open a task to inspect its full escaped summary, error, diagnostics, attempts, status, and confirmed changed-file count.

Commit-message generation

Use the always-available sparkle action in a Git Source Control title bar or run Terse: Generate Commit Message from the Command Palette after the workspace has staged or unstaged Git changes. Commit-message generation is not available in the Plan webview. Terse selects the single matching Git repository and asks the selected plan revision's review route for a validated message in read-only mode at that repository root. Without an active plan, it uses the current workspace and configured default review route. The generated message is placed in VS Code's Source Control input for review.

Generated messages do not stage files, create commits, modify the working tree, or contact a remote. Ambiguous repositories, no matching repository, no changes, cancellation, and malformed model output fail without changing the Source Control input.

To fit the repository instead of imposing a universal style, generation samples recent commit subjects and asks the review model to match their casing, tense, and prefix conventions. When the history does not establish a convention, the prompt defaults to a sentence-case imperative subject without a conventional commit prefix.

Multiple plans and parallel execution

A workspace can hold multiple plans. Plans have independent IDs, revisions, approvals, workspace-folder bindings, attachments, execution results, and cancel controls. Use Select Plan, Archive Current Plan, and Restore Plan to manage the collection. Discarding a plan deletes that plan and its owned attachments. Choosing a saved plan from the plan selector leaves the New Plan screen immediately; an unsent New Plan draft remains available when you return to it.

Within each active plan, the dependency scheduler starts only ready tasks and uses at most four workers. Different plans may also execute at the same time after plan-scoped validation:

• Task write scopes predict paths that may change. Missing scopes are treated as unknown, and repository-wide or overlapping scopes are treated conservatively.
• Disjoint dependency-ready task scopes can proceed concurrently within or across plans. Detected overlapping task scopes are automatically serialized; unrelated ready work can continue while a conflicting task waits.
• A predicted overlap between plans is shown with the affected plan IDs and path evidence; declining leaves the new execution inactive. Continuing requires acknowledgement of that exact conflict.
• Acknowledgement does not disable scope locking or serialization.
• Provider diff events expand the observed scope during execution. A newly overlapping reported path pauses the affected plan and retains completed task results.

Conflict detection is a warning and serialization aid, not proof of isolation. It is path-based and depends on declared scopes and provider-reported diffs, so even apparently disjoint scopes do not prove that tasks are isolated. It cannot detect every semantic conflict, external edit, omitted diff, or future write before it happens. An acknowledged warning therefore never means that undetected execution is conflict-free. Review unrelated workspace changes before resuming a paused plan.

Clipboard and attachment custody

Clipboard access happens only when the user pastes into a planning text area. Terse reads file items from that paste event; it does not poll the clipboard or call the ambient clipboard API. Ordinary pasted text remains text and is not staged as an attachment. Upload from this computer uses a webview file picker, so local workstation files remain available while the workspace and extension host are connected through Remote SSH. Add from workspace uses VS Code's workspace-side picker.

Accepted clipboard file items are image/gif, image/jpeg, image/png, image/webp, and text/plain. The upload and workspace pickers additionally accept .csv, .json, .md, .pdf, .yaml, and .yml files. Each item is limited to 10 MiB, and a plan can own at most 20 attachments. Unsupported, oversized, duplicate, and excess pasted items are rejected individually so valid items in the same paste can remain selected.

Before submission, chosen file references and uploaded or pasted bytes are held only in the open playground draft; attachment bytes are deliberately excluded from saved webview draft state. On create or revision submission, Terse copies accepted items into an extension-owned attachments/<plan-id> directory under VS Code's managed global storage. The repository is never used for attachment staging, and persisted plan state contains only the owned paths.

Removing a draft item drops it from the draft. Terse: Remove Plan Attachment deletes an already-owned copy and removes its plan reference. Failed creation/revision imports clean up their new copies, and Discard Plan removes the plan's entire attachment directory. Archiving preserves a plan and its attachments. For a disposable-profile test, exit VS Code and delete the temporary profile directories to remove all remaining extension storage.

Platform architecture

Codex, Claude, and OpenRouter are built-in platform plugins behind one internal framework contract. The registry is closed to third-party loading. Each plugin declares authentication methods, model discovery, executor creation, and a per-model tuning schema; shared routing, approval, persistence, redaction, and error handling remain platform-independent.

A lightweight in-extension authentication library handles OAuth2 and API keys, stores credentials only in VS Code SecretStorage, and supplies direct API clients. All plugins use the shared agent runtime for tools, streaming, cancellation, and deterministic enforcement of the approved write scope. The extension never delegates scope enforcement to a provider.

One universal VSIX supports every VS Code platform and CPU architecture. It contains the extension and webview code, not provider CLIs or native provider runtimes. Install the same artifact locally or on a Remote SSH, WSL, or development-container extension host.

Provider routes, authentication, and permissions

Use Terse: Sign In to a Provider to establish any of these explicit connections:

Provider	Supported sign-in	Credential custody	Runtime and transport
Codex	ChatGPT subscription or OpenAI API key	VS Code SecretStorage	OpenAI Responses API through the shared in-extension agent runtime
Claude	Claude.ai OAuth2 subscription or Console key	VS Code SecretStorage	Anthropic Messages API through the shared in-extension agent runtime
OpenRouter	OpenRouter API key	VS Code SecretStorage, after /key and compatible-model discovery validate	OpenRouter API through the shared in-extension agent runtime

Codex ChatGPT sign-in uses browser OAuth2 locally and device code on remote extension hosts. An OpenAI API key is the separate Codex path. Claude sign-in always asks which billing source to use: Claude.ai uses browser OAuth2 and an Anthropic Console key uses the API-key path. OpenRouter uses an API key. Terse forces the selected method for model discovery and every routed session; expiry, cancellation, or an entitlement failure never falls back to the other billing source. To re-authenticate, run Terse: Sign In to a Provider, choose Claude and the same billing path again; the prior validated selection remains in place unless the replacement completes and validates.

OAuth tokens and API keys are validated before replacing an existing connection and are stored under distinct VS Code SecretStorage keys. Credentials are stored only in VS Code SecretStorage and are not deliberately placed in settings, workspace state, webview state or messages, provider logs, model prompts, connection IDs, model metadata, persisted results, or repository files. Provider account/catalog fields, streamed events, diagnostics, diffs, and bounded summaries are validated and redacted by src/core/redaction.ts before they cross Terse's provider boundary. Redaction uses known active credentials plus patterns for supported credential forms; it is defense in depth, not a guarantee that arbitrary secret-like text can be recognized. Do not put unrelated secrets in prompts or provider-visible files. OpenRouter receives the selected model slug directly and may choose an upstream inference provider according to the account's OpenRouter routing policy; Terse never substitutes another platform or model.

Phase and model compatibility

terse.planningRoute, terse.reviewRoute, and terse.executionRoute define an exact provider/model pair at user or workspace scope. When unset, each route is Codex with default, the model recommended by the signed-in Codex account. Planning and revision use the planning route; automatic plan review, tool review, and commit-message generation use the review route; and execute, retry, and resume use the execution route. Mixed-provider revisions are supported.

The settings UI offers only models reported by the signed-in connection as compatible with that phase. Planning and review require tool use and structured output; execution requires tool use and approval support. OpenRouter discovery filters its live catalog accordingly. Claude uses the models and account metadata reported for the explicitly selected Claude.ai or Console billing connection. Codex uses its account-scoped model catalog. Attachments additionally require support from the chosen model and provider route. A Claude.ai subscription does not guarantee that every model or operation is entitled; an unavailable entitlement fails visibly and never switches to Console billing.

All three routes are snapshotted onto the resulting plan revision. Changing defaults does not mutate an existing plan. Explicitly applying new routes to a plan creates a material revision, clears its approval and older results, and resets its tasks. An unavailable, signed-out, incompatible, or stale pinned route fails visibly; Terse never falls back to another provider/model or silently updates an approved revision.

Settings reference

Settings are available at user or workspace scope and are grouped in the Plan webview under Providers & models, Safety & review, and Orchestration.

• terse.planningRoute: provider, model, and tuning for planning. Defaults to Codex default.
• terse.reviewRoute: provider, model, and tuning for reviews and commit messages. Defaults to Codex default.
• terse.executionRoute: provider, model, and tuning for execution. Defaults to Codex default.
• terse.requireApproval: require revision-specific approval. Defaults to true.
• terse.automaticReview: run read-only model review after planning. Defaults to false.
• terse.taskOrchestration: keep per-task route recommendations off, suggest them, or apply them automatically. Defaults to off.

Each route has provider, model, optional effort, and optional tuning. The settings UI exposes only parameters declared by the selected model, such as reasoning effort, speed, temperature, top-p, token limits, or penalties, and validates their type and range before saving. Omitted values use model defaults.

Per-task model orchestration

terse.taskOrchestration controls benchmark-informed execution-model routing for individual tasks:

• off (the default) preserves the single revision-pinned execution route.
• suggest adds available recommended task routes when the plan is created, so they are visible in the revision route snapshot before approval.
• automatic selects and persists available recommended task routes in that same revision's route snapshot immediately before execution begins.

Every effective task route remains revision-bound and approval-gated. Terse uses an optional planner-supplied task category, or a local heuristic when the planner omits it, to select a recommendation from a bundled static benchmark snapshot. The current snapshot is version 2026-07-02 and attributes its data to BridgeBench and DesignArena; Terse never fetches benchmark data at runtime. Benchmark results are third-party data, not independently verified endorsements. Entries without verifiable source data are omitted from the snapshot, and categories with no eligible sourced entry use the plan revision's default execution route.

Provider permissions and failures

Planning, revision, automatic plan review, tool review, and commit-message generation are read-only for every platform. Execution uses the shared workspace-write agent runtime. Its tools normalize and check write paths against the task's approved scope before access; sensitive or exceptional requests enter the configured review queue. Dismissal, denial, cancellation, malformed input, reviewer uncertainty or failure, and missing sandbox enforcement fail closed without granting session-wide access.

The human revision gate, automatic-plan-review fail-closed policy, scope locks, conflict prompts, runtime scope-expansion checks, redaction, and persisted provider/model provenance apply regardless of route. A planning failure leaves no approved revision, a review failure returns to human review, and an execution failure marks the affected task while retaining completed results from the same revision. Authentication, entitlement, unavailable-model, runtime, network, rate-limit, malformed-response, permission-denial, and cancellation errors remain provider-specific and visible. Retrying never changes the pinned route.

Cancellation aborts the active API request and agent turn. Starting a new sign-in for a provider cancels that provider's earlier unfinished sign-in and does not overwrite the last credential unless the replacement first validates.

On Remote SSH, WSL, and development-container extension hosts, Codex ChatGPT sign-in uses device code so the browser never has to reach a callback on the remote host's localhost. Claude.ai OAuth asks for the returned callback URL. All OAuth tokens and API keys remain in that extension host profile's VS Code SecretStorage.

State and recovery

Plan collections are stored in VS Code workspace state under terse.planState.v4; Terse creates no plan file in the repository. Activation migrates supported v1-v3 and legacy single-plan state into the v4 collection, binding migrated revisions to Codex. Stored routes, approvals, and execution results are revision-scoped, and task results include provider/model provenance. In-flight work is restored as interrupted/paused, and only completed results from the matching revision are eligible for resume. Credentials, pasted bytes, and raw provider event histories are not stored in workspace state. Automatic-review decisions and their separate revision-bound automatic-approval markers are persisted; stale or malformed review metadata is discarded with recovery information, and an interrupted automatic continuation returns to human review.

Requirements and development

• The extension manifest requires VS Code ^1.96.0; the extension-host bundle targets ES2022 and does not use Bun runtime APIs.
• Bun 1.3.10 is the pinned CI and release-qualification toolchain.
• Credentials for the explicitly selected provider are required for live provider operations: Codex ChatGPT/OpenAI API access, a Claude.ai subscription or Anthropic Console API key, or an OpenRouter API key.

Provider access uses direct API clients on the shared in-extension runtime.

bun install --frozen-lockfile
bun run validate:all

TAG=$(bun -e 'const p = require("./package.json"); process.stdout.write(`v${p.version}`)')
bun run release:check -- "$TAG"

Packaging performs a clean rebuild, creates one metadata-derived universal VSIX and SHA-256 sidecar, and verifies the exact archive inventory, metadata, entry points, sizes, CRCs, and checksum. The VSIX contains extension/webview output, manifests, licenses, and documentation, with no provider executables. Packaging rejects vendor payloads, source, tests, tooling, temporary state, credentials, and unapproved entries.

VERSION=$(bun -e 'process.stdout.write(require("./package.json").version)')
ARTIFACT="artifacts/terse-planner-$VERSION.vsix"
bun scripts/verify-vsix.ts "$ARTIFACT" --check

Disposable-profile smoke checklist

Use a desktop VS Code CLI that supports isolated user-data and extension directories. Do not point this test at a normal profile.

PROFILE=$(mktemp -d)
code --user-data-dir "$PROFILE/user" \
  --extensions-dir "$PROFILE/extensions" \
  --install-extension "$ARTIFACT"
code --user-data-dir "$PROFILE/user" \
  --extensions-dir "$PROFILE/extensions" \
  --new-window /path/to/disposable/workspace

Before using live credentials, inspect the VSIX with bun scripts/verify-vsix.ts "$ARTIFACT" --check. Confirm its exact inventory contains no provider executable, settings, workspace state, SecretStorage database, .env file, credential, log, attachment, profile data, or packaging scratch file.

In the disposable local window:

1. Open Terse: Sign In to a Provider and exercise Codex ChatGPT browser sign-in, Codex OpenAI API-key sign-in, Claude.ai OAuth locally and through a remote window, Claude Console API-key sign-in, and OpenRouter API-key sign-in. Cancel and repeat the Claude.ai flow, then re-authenticate through Terse: Sign In to a Provider and confirm its subscription metadata and models refresh without exposing a token. Confirm every key field is password-masked, invalid credentials or entitlement failures leave the previous billing selection intact, and no Claude or OpenRouter route switches credentials implicitly.
2. Refresh provider settings and confirm all three connections report their live compatible models. For each provider in turn, select one compatible model for all three routes and complete planning, automatic plan review, approval, and execution. Confirm the displayed revision routes and each review/result provenance match exactly; no phase silently uses another provider or model.
3. Create and execute a mixed route revision: Codex planning, Claude review, and OpenRouter execution. Repeat with the providers rotated through the three phases. Change the default routes before execution and confirm the approved revision retains its pinned routes. Apply routes to the current plan explicitly and confirm that creates a revision and clears approval and older results.
4. Select or preserve a model that becomes unavailable or is incompatible with a phase. Confirm save/rebind/execute fails with the named provider, model, and phase; the UI does not substitute a route, the revision and completed results remain intact, and automatic plan review falls back to human review.
5. For each execution provider, exercise sensitive workspace, command, filesystem, network, credential, deployment, and out-of-scope requests where supported; deny one, close the webview on one, allow one once, and allow one for its task. Confirm one exact, high-confidence safe request continues and uncertainty, reviewer failure, stale approval, identity mismatch, and scope mismatch escalate to a person. Confirm escalated requests appear as redacted cards in the webview queue with a correct badge, focus advances after each decision, standing allowances remain visible, and denial/disposal does not execute the tool or end the agent turn. Confirm the same turn can try a safe in-scope alternative, an allow-once permission is not remembered, and an allow-for-this-task permission covers only the same task, tool, and category until the run ends. During planning and model-based review, confirm no workspace or Git file changes occur.
6. Cancel planning, review, and execution once for each provider. Confirm the active API request and agent turn stop, no later event changes state, approval is not broadened, and only same-revision completed task results remain resumable.
7. Restart the extension host with a mixed-route execution interrupted. Confirm the revision routes, provenance, and completed results recover; automatic continuation returns to human review; retry/resume uses the original pinned execution route and never a new default.
8. Inspect the workspace files, user/workspace settings.json, Terse output, task results/diagnostics, webview developer-console messages, and persisted terse.planState.v4 data without printing or copying a key. Confirm none contains a credential or raw provider event history. Confirm the disposable profile keeps distinct OAuth and API-key entries in VS Code SecretStorage, not plaintext settings or workspace-state values.
9. Start a plan that requests a clarification. Inspect the linked Planning trace and accessible text trace; confirm detailed provider-supplied activity and reasoning summaries are bounded and redacted, update without raw hidden reasoning, and remain readable at narrow widths. Navigate the clarification choices and optional Other field using only the keyboard, confirm a screen reader announces the question and status, answer it, and verify planning resumes once. Repeat and choose Stop planning; verify the dialog, pending request, and planning turn all cancel without creating a plan.
10. With terse.automaticReview still at its default false, create a plan and confirm it waits for revision-specific human approval. Enable the setting in this disposable workspace and exercise one eligible continue decision and one Human review required decision; inspect the displayed revision and reason categories. Restart during a pending automatic continuation and confirm it fails closed to human review rather than resuming.
11. While another plan has an overlapping predicted scope, generate a plan that would otherwise receive continue; confirm automatic continuation stops at human review with an execution-conflict reason and requires explicit conflict acknowledgement through the normal execution flow.
12. Create a plan with five independent, disjoint-scoped tasks and confirm no more than four run at once and the fifth starts when a worker becomes free. Add overlapping scopes and dependencies, then confirm only dependency-ready, non-overlapping tasks run together. Create two disjoint-scoped plans, start both, and confirm their state and cancel controls remain isolated. Open New Plan, enter an unsent draft, then select each saved plan—including the already active one—and confirm navigation leaves New Plan immediately; return and confirm the unsent draft was preserved.
13. Start a plan whose predicted scope overlaps an active plan. Decline once and confirm it stays inactive; retry, acknowledge the displayed plan/path evidence, and confirm detected overlapping writes serialize.
14. Exercise a runtime scope expansion that overlaps the other active plan and confirm the affected plan pauses with completed results retained.
15. In a workspace with one Git repository, confirm the Source Control sparkle action stays visible with no active plan. With visible staged or unstaged changes, generate a commit message there or through Terse: Generate Commit Message in the Command Palette; confirm the default review route is used without a plan, then repeat with a selected plan and its pinned review route. Confirm the Plan webview has no commit-message action, only the matching Source Control input is populated, and no file is staged, no commit is created, and the working tree is unchanged. Cancel a second generation and confirm its input is unchanged.
16. Switch between Board and Flow with the keyboard. Confirm Board groups tasks by status, Flow groups them into dependency stages with directional connectors, the selected view survives reload, and dependencies are conveyed visually and by a screen reader. Confirm task actions remain usable and cycle/missing/large-plan fallbacks retain readable dependency labels. Resize the sidebar through narrow and wide widths; confirm Flow lanes wrap to fit and connectors redraw against their tasks, then repeat in a high-contrast theme.
17. Exercise a task result longer than 280 characters. Confirm each board card stays bounded in both views, then open it with the keyboard and verify the full escaped summary, error, diagnostics, attempts, status, and changed-file count remain readable by a screen reader and at a narrow width.
18. Paste one supported image or text file into a request or revision field, submit it, reload VS Code, and confirm the plan and attachment recover.
19. Remove one attachment, discard its plan, and inspect the disposable profile's extension global storage to confirm the plan attachment directory is gone.
20. Exit VS Code, remove $PROFILE, and confirm no test profile or staged data remains.

Repeat steps 1-8 on a disposable Remote SSH, WSL, or development-container extension host. Confirm Codex ChatGPT uses device code instead of a remote localhost callback, and Claude.ai OAuth, Claude Console keys, and OpenRouter keys remain in the remote profile's VS Code SecretStorage. Confirm live planning/review/execution and denial recovery work there, restart/resume preserves pinned routes, and deleting both disposable local and remote profiles removes their test state. Do not reuse production credentials or a normal remote profile.

The automated bundled-activation fixture imports the built extension entry in an isolated, credential-stripped process and runs deterministic activation, extension, parallel-execution, and playground tests. The wider unit suite covers route pinning and migration, provider compatibility and provenance, credential non-disclosure, multi-plan restart, scoped attachment custody, conflict handling, four-worker execution, cancellation, cleanup, clarification and planning traces, the LLM-first tool-review pipeline, denial recovery, OAuth re-authentication, Git commit-message integration, plan navigation, Flow/Board presentation, and bounded results. This fixture does not launch VS Code and neither automated suite replaces the installed-VSIX live-provider, local/remote sign-in, permission, keyboard, screen-reader, Git state, clipboard, high-contrast, narrow-layout, credential-store, and storage inspection above.

Nightly release status

Forgejo validation runs frozen installation, formatting, strict type checks, behavioral tests, workflow validation, clean packaging, checksum verification, and isolated extension-host tests. Automatic release publication is limited to nightly tags and marks them as prereleases. No stable release is authorized by this document.

Before a stable release:

• run the complete clean-checkout gate with the pinned Bun version;
• pass the installed-VSIX disposable-profile checklist, including keyboard and screen-reader review;
• confirm attachment cleanup and exact package inventory;
• confirm the registered Marketplace publisher and stable tag/version;
• require the explicit stable publication acknowledgements; and
• confirm the final candidate is committed and reproducible from a clean checkout.

CHANGELOG.md records candidate changes and qualification notes.