Research Stack Toolkit 0.3.10 — Know When a Newer Release Exists, and Report a Problem Without Sending Your Notes

Public preview: This release is experimental. Gates G1–G4 remain open and the complete onboarding, Copilot, external-provider and data-recovery workflows have not been accepted. Back up your research documents and configuration before trying setup or indexing. Validate citations against their sources. Report problems through the extension or the links below.

Requires VS Code Desktop 1.140.0 or later. Version 1.145.2 was tested with an isolated Windows Extension Host; the minimum version, other platforms, remote hosts and a live Copilot workflow remain unverified. Some components require separately installed software, accounts, provider terms or internet access. Qdrant, vector and embedding search are planned rather than implemented.

Install from the Visual Studio Marketplace, open the Research Toolkit control panel, select a package and run setup explicitly. See the onboarding guide for prerequisites and first steps. For support and security reporting see SUPPORT.md and SECURITY.md.

Install the components each package actually needs from the VS Code control panel, read one plain-language verdict for the last component setup — what completed, what failed, and what to do next — verify real MCP reading, see actual component versions and readiness, and choose a tools preset shaped by the goal you are working on so your assistant is offered fewer, better-matched tools. This release adds the two things a locally installed extension was missing: an update channel that tells you a newer Toolkit is published and can install it through the Marketplace, and a problem report that writes your diagnostics to a file you can read, redacts the personal facts from it, and hands you a draft to send to the maintainer in your own mail program.

Start with the onboarding walkthrough or guide hub. The hub is assembled from 29 individual component guides, each with setup, a first task, readiness interpretation, troubleshooting and a maintained official documentation link.

What 0.3.10 adds

Everything below is covered by the automated suites on this Linux development host. The isolated VS Code Extension Host test passed on Windows; the full Copilot and provider workflows have not been verified.

The Toolkit can tell you a newer version exists. VS Code updates an extension installed from the Marketplace by itself. It does not update an extension installed from a local .vsix file — VS Code marks that install as pinned and leaves it where you put it — and every release of this Toolkit since 0.3.0 reached people as a .vsix file. Check for a newer Toolkit version asks the Marketplace one question and answers it in the panel: up to date, an update is available, this copy is newer than the published one, your VS Code is too old for the published build, nothing is published yet, or the check did not complete. Update from the Marketplace then asks VS Code to install the published build through the Marketplace — the same signed path any extension update takes — which also returns the Toolkit to normal automatic updating. If the editor refuses, the Toolkit opens the Marketplace page and says so.

One request, disclosed and switchable. The check is a single HTTPS GET to marketplace.visualstudio.com, at most once a day, never at startup, with an 8-second timeout and a 64 KB response cap. The URL contains the publisher id and the extension name, both already public in the manifest: no workspace path, no file name, no user identity, no diagnostics. researchStack.checkForUpdates (on by default) switches it off, and with it off the update checker makes no Marketplace request. Optional research tools and setup can separately contact external services. It is the only packaged JavaScript in the release that can open a socket, and the packaging audit names it, counts its request sites and re-checks its timeout, byte cap and cooldown on the shipped bytes.

A problem report you read before anyone else does. Report a problem to the maintainer collects the environment (VS Code, platform, Node, install kind), the package and preset, the recorded setup verdict, the last 40 lines of the setup log, up to 12 failures seen in this window and a note you type, and writes it as a plain-text file in the extension's own storage folder. Absolute paths, home directories, workspace folder names and token-shaped strings are replaced with <path>, <home>, <workspace> and <redacted> — including inside your own note and inside the log lines — and the report ends with a count of what it removed. The file is opened and copied to your clipboard. Only after that, and only after you confirm in a modal, does the Toolkit hand a short draft to your own mail program addressed to princ.michael@gmail.com. Nothing is uploaded, no message is sent by the extension, and the full report reaches the maintainer as the file or the paste you already have.

A Marketplace tile icon. The manifest now declares media/toolkit.png (256×256 PNG, generated from the reviewed media/toolkit.svg by scripts/make_icon.js and byte-reproducible). The Marketplace rejects an SVG icon outright, so the activity-bar icon stays SVG and the tile gets a PNG. The manifest also declares bugs.url and bugs.email, so the Marketplace page and Report a Problem point at the same place.

What 0.3.9 adds

Everything below is covered by the automated suites on this Linux development host. Nothing in that release has been run on a Windows host or in a live VS Code session, and no statement below depends on one.

PDF and DOCX sources can be indexed directly. index_corpus accepts explicitly selected workspace PDF and DOCX files beside Markdown and text. A PDF chunk carries the page number it came from and its character offsets inside that page's extracted text; a DOCX chunk carries its ordered paragraph or table-row item. A chunk never crosses a page or an item. The Markdown/text chunker paragraph-window-v1 is unchanged, so chunk ids and locators written by an earlier release still resolve; PDF and DOCX get their own chunker identities (pdf-page-window-v1, docx-item-window-v1).

Each indexed source states what was actually read. The stored record carries the workspace-relative path, the source-byte SHA-256, the byte size, the kind, the parser and its version (pypdf, python-docx), unit counts, coverage (units read, units holding text, empty units, failed units, batches), warnings, and one outcome: complete, partial or failed. A source whose bytes change while it is being read is refused with SOURCE_CHANGED_DURING_INDEX.

The indexed version and the present file are separate facts. verify_sources is the tenth verb on the store server and the only verb that may call a source verified. The states are verified, changed, missing, inaccessible and unchecked. index_corpus gained accept_partial (the CLI's --accept-partial); a partial or failed read does not replace an indexed version unless the operator accepts it, and the control-panel index command offers no such acceptance — a partial source is reported as refused and left at its previous version. One index call is one transaction, and every call leaves exactly one row in the new index_runs table. Claim exports exclude stale and unverified references by default and count them (excludedStaleReferences, excludedUnverifiedReferences, uncheckedReferences).

The store is at schema 3, reached by an additive 2→3 migration. A migrated row is labelled legacy / unchecked and is never back-filled: 0.3.8 did not record what 0.3.9 now records, and the toolkit does not invent it. Existing chunk ids are unchanged. backup works on a store that has not been migrated yet. restore stages a validated candidate and only confirm=true activates it, preserving the previous store in a named file.

Topic skill bundles. The extension ships a reviewed built-in catalog (extension/bundles/catalog.json, generated by scripts/build_bundle_catalog.py) and five new actions: Index Selected PDF / DOCX / Text Sources, Verify Source Freshness, Install Topic Skill Bundle, Repair Topic Skill Bundle and Show Topic Bundle Status. A bundle installs under .github/skills/<skill-id>/…. Every file is copied to a staging directory and hashed there against the catalog before anything moves into the workspace; a file you edited is left exactly as it is; nothing is ever deleted; a skill owned by another bundle is neither written nor removed. The install writes a receipt at .research-toolkit/bundles/<bundle-id>.json. The receipt separates three claims and never merges them: filesInstalled (verified by hash), hostDiscoveryVerified (false — the toolkit cannot observe this host's skill discovery from the machine that ran the install) and workflowTested (false). "Files installed" is the only status an automated install may claim.

Topic bundles and licensing. The theological-research bundle is attributed to sestra Denisa and Michael. The document-corpus-bridge bundle supports indexing PDF and DOCX and citing by page or item. Both bundles and the extension are distributed under MIT; their license notices are included. The bundle installer can verify copied files but cannot verify that the host discovered the skill or that a workflow was tested.

Unchanged exclusions. No OCR, no scanned-image recognition, no vector or embedding search, no background ingestion, no external account provisioning, no automatic acquisition of papers. The toolkit still does not install uv, does not run setup silently or in the background, and does not execute notebook kernels.

What 0.3.8 fixes

If you installed 0.3.7 in a workspace whose name contains characters your Windows console cannot represent — for example k:\Soukromé_aktivity\Bankovní účet SVJ ČSA368 — and Corpus index and record store ended with "python.exe -I failed with exit code 2: {"error": "'charmap' codec can't encode character '\u010d' … character maps to <undefined>"}", this release is for you. The record store was created. What failed was the worker's ability to report that it had been created: the report contained your workspace path, and the child process had been handed your system's console encoding (cp1252 on an English-locale Windows 11), which has no byte for č. Your workspace, your Python, your uv and your network were not at fault.

• The worker states its own output encoding. Every Python child this toolkit starts is started with UTF-8 standard streams, and the worker restates that promise itself before it writes anything — so it holds however the process was launched, including a managed runtime left behind by an older toolkit release that this one can still activate.
• The receipt the panel parses is ASCII-only. A workspace path in a report can no longer be garbled or crash the command that prints it. ČSA368 appears as ČSA368 in the raw JSON and as ČSA368 in the panel, which parses the JSON.
• A report the extension cannot read is refused, not recorded. If a worker's report arrives as bytes that are not valid UTF-8, the step is reported as a named failure that says the step was not recorded and that re-running it is safe — instead of recording a store path containing replacement characters that the panel would later fail to find.
• A text-encoding failure is named as one. The step now says it is a text-encoding problem and explicitly not a network, proxy or interpreter problem, and it is never retried as if it were a transport failure.
• Every command the worker answers is covered, not only the store step: inspect, init, add-recommended, read and export-bundle, and the error sentences that name a Czech path.
• The MCP servers the editor starts carry the same flags, so the guarantee lives in this toolkit rather than only in the MCP library's transport.

What 0.3.7 fixed

If you installed 0.3.6 and Set up package components ended with "Installation incomplete — 1 step(s) verified, 1 need attention (Isolated locked worker (Python 3.12))", and the step log said (that release fixed it; the record below is kept as history): "uv.exe sync failed with exit code 1: … The lockfile at uv.lock needs to be updated, but --locked was provided", this release is for you. The cause was inside the toolkit's own build: 0.3.6 shipped a locked dependency file that still recorded an older version of the worker project than the project file beside it, and uv refuses such a pair before it installs anything. Your workspace, your network, your proxy and your Python were not at fault.

• A bad build is refused before anything runs. The extension compares the dependency lock and the project file it ships, inside itself, before it takes the setup lock, starts a process or writes a file. If they disagree it stops with "This toolkit build ships a locked dependency file that does not match its own project file: … No process ran and no file was written. Reinstall the Research Stack Toolkit VSIX; this is a defect in the toolkit build, not in this workspace."
• A lock mismatch is explained in plain language. When a host's uv still refuses the shipped lock, the step names it as a lockfile disagreement — explicitly not a network, proxy or interpreter problem — instead of an exit-code line you had to interpret yourself. The toolkit then compares the two files itself and says which side disagrees: a broken toolkit build, or this host's uv refusing a lockfile the toolkit reads as current.
• One reviewed retry, and it says so. The worker step installs the locked set first. Only when uv's own refusal is recognised as a lock mismatch does the toolkit retry exactly once with the reviewed fallback that installs the packages the shipped lock pins, without rewriting the lock. That fallback is recorded in the step evidence, in the setup log and in Copy Installation Diagnostics, so a fallback install is never presented as a clean one. The toolkit never re-locks a managed runtime and never installs without a lock.
• The shipped lock was regenerated, not hand-edited (uv 0.13.6): the same 40 resolved packages and the same 39 third-party version pins, with only the worker project's own recorded version corrected to 0.3.7.
• A stray shell variable can no longer change what setup does. The variables that would alter the reviewed uv command (UV_INDEX, UV_INDEX_URL, UV_DEFAULT_INDEX, UV_EXTRA_INDEX_URL, UV_FIND_LINKS, UV_NO_INDEX, UV_LOCKED, UV_FROZEN, UV_UPGRADE, UV_NO_SYNC, UV_OFFLINE, UV_NO_DEV, UV_SYSTEM_PYTHON, UV_EXCLUDE_NEWER, UV_PYTHON_PREFERENCE) are removed before the reviewed environment is applied, whatever spelling the host used — on Windows the same variable can arrive as Uv_Index_Url or uv_locked.
• The build refuses this class of defect. The worker bundle builder, the packaged-VSX audit and the test suite all compare the shipped lock with the shipped project file, so a stale pair cannot leave the toolkit again.

Install and open

1. Run Extensions: Install from VSIX... in VS Code and choose research-stack-toolkit-0.3.10.vsix.
2. Click the Research Toolkit beaker icon in the Activity Bar, then Open Control Panel. You can also click the Research: … status-bar item or run Research Toolkit: Open Control Panel from the Command Palette.
3. Select the research folder under Workspace to inspect, then click Check components. Search the list to find a component and inspect its installation, actual version, readiness, evidence and next action.
4. In Component setup for this package, review the steps this package offers and click Set up package components. Setup starts with a preflight — workspace trust, a local desktop workspace, the host tools the plan needs, the managed paths and the setup lock — and nothing is written or downloaded until that preflight passes. Each step is recorded in the workspace receipt, so a later run resumes instead of repeating finished work.
5. Read the Installation status card. It names the overall outcome of the last component setup and each step, with the failing or blocked step, its exit code where there was one, and the action that clears it. The verdict is read from the workspace record, so it is still there after you close the panel or reload the window.
6. Click Read selected PDF / DOCX to verify a source inside the workspace and see text, locators and its hash. On the Full package, Index Selected PDF / DOCX / Text Sources puts your own sources into the research store and Verify Source Freshness re-hashes them against the files present now.
7. Use Guide for its bundled setup steps or Latest docs for current official instructions. Choose and save a package preference and a tools preset independently of installation.
8. Under Tools preset, pick the goal you are working on, open Context usage and tools in the selected preset, and save. The preset changes which tools your assistant is offered; it installs nothing.

Your existing 0.2.0/0.3.0 package and interface preferences are retained. Preferences belong to the active VS Code user profile. Component observations are scoped to the selected folder/current editor and retained in this session with a check timestamp; rerun checks after environment changes or restart.

Component setup, step by step

The install plan is declarative: components.json (schemaVersion 2) states, for every component, who installs it, which step provides it, how it is verified and what you should do next. The extension runs only the steps your package needs, in order, and records each one in .research-toolkit/managed/worker-0.3.10/installation.json.

• Set up package components runs the missing steps. Update or repair component steps re-runs the steps an earlier toolkit release recorded and the steps this release recorded but whose produced files are gone. Retry Failed Component Steps re-runs the steps whose last attempt failed or was blocked, together with the steps those failures blocked, and keeps the work that completed. Check component status runs the bounded host/library checks; Refresh component status re-reads the plan and re-verifies the produced files without running the functional MCP check.
• A step is reported as installed only when its produced files are still present. A recorded step whose files were deleted is reported as needs repair and is re-run, not presented as complete.
• The Installation status card names the outcome of the last component setup and each step, in one of these words: Installation complete — N component step(s) verified., Installation incomplete — N step(s) verified, M need attention (step ids)., Installation failed — <step>: <error>., Setup blocked — <reason>., Setup cancelled — N step(s) already completed were kept. or No component setup has run in this workspace yet. A success verdict is only given when the files each step was supposed to produce were re-checked on disk after the run; for the worker step that means .venv/bin/python on Linux/macOS, .venv/Scripts/python.exe on Windows, and the managed src/research_stack/mcp_server.py.
• Setup runs a preflight before any component command: workspace trust, a local (non-remote) desktop workspace, the required host tools from the component registry, the managed path being a real directory rather than a link, a writable workspace, and the setup-lock state. A blocked preflight writes a status record with the outcome blocked and runs nothing. Before the plan touches anything, the extension also compares the dependency lock it ships with the project file it ships beside it: a build whose pair disagrees is refused as a defect in the toolkit build, with no process started and no file written.
• uv is resolved in a fixed order: researchStack.uvPath, then absolute PATH entries, then the documented install locations for the platform (Windows: %USERPROFILE%\.local\bin, %LOCALAPPDATA%\Programs\uv, %APPDATA%\Python\Python312\Scripts, %APPDATA%\Python\Scripts, scoop shims, WinGet Links and C:\Program Files\uv; macOS/Linux: /usr/local/bin, /opt/homebrew/bin, /usr/bin, ~/.local/bin, ~/.cargo/bin and $XDG_BIN_HOME), then the workspace's managed toolkit folder. A found tool is version-probed with uv --version; a tool whose version command fails, or whose version is older than the registry minimum (uv 0.5.0), is reported as unusable rather than as installed. An executable inside the workspace is refused as a host tool. If uv is not found, setup is blocked before anything is written, and the message names the locations searched and the researchStack.uvPath remedy.
• A failing step no longer aborts the whole plan. Independent steps continue, steps that depend on the failure are recorded as blocked with the step that blocked them, and every attempt is recorded. A transient failure — a timeout, output over the capture limit, or network-flavoured tool output — is retried once; a launch failure (ENOENT), a cancellation or an explicit refusal is not retried.
• An optional step you did not install is reported as a deliberate omission, not as an unmet requirement.
• Each component row in the panel and in the sidebar has Install / Update where the toolkit can install it; rows the toolkit cannot install state who does (editor, host tool, external service, or planned).
• A step that needs another step pulls that step in and says why, instead of failing the click or half-installing: the record store needs the worker.
• Existing files are never overwritten. Overlay files are created once, hash-verified against the bundle, and classified on re-run as unchanged or changed by you and preserved; a linked or junctioned path is refused rather than followed.
• A cancelled or failed run leaves the completed steps recorded, so the next run resumes at the first missing step. The receipt and the active-runtime pointer are written atomically, and one setup lock covers the whole plan so two windows cannot interleave steps. A lock is classified stale only when it is older than the setup window, or older than 60 seconds with a dead owner process; Clear Interrupted Setup Lock removes only such a lock and refuses a live one.
• Two steps reach the network, and only those two: the isolated document worker step syncs its locked Python 3.12 environment, and the optional notebook analysis environment step syncs the reviewed notebooks/analysis project (uv sync --locked). Only the two locked sync steps have a fallback, and only for a recognised lock mismatch: one uv sync --frozen run that installs exactly what the lock pins, recorded in the step evidence and the setup log as a fallback rather than as a clean install. It runs only when the toolkit's own check of the same pair says the pair is current — a build whose pair really disagrees is refused instead. The toolkit never runs uv lock in a managed runtime and never runs a plain unlocked uv sync. No other step downloads anything, and no step starts a kernel. Both honour researchStack.setupTimeoutSeconds (default 900 s, allowed 60–3600 s), because a first run can fetch a managed Python 3.12 and the locked packages. Setup runs with a reviewed uv environment: pinned Python 3.12, copy link mode, no progress spinners, no user config file, and a workspace-contained project environment; the UV_* variables that would change what the reviewed command means are removed before those values are applied. The MCP reading check that closes the worker step honours the same bound instead of a fixed 90 s. The notebook step first classifies what is already in notebooks/analysis — reviewed project, compatible existing project, or neither — refuses a linked environment, and records that ipykernel and matplotlib import in the environment it created.
• Setup evidence stays in the workspace: .research-toolkit/logs/last-setup.json is the status record the panel reads when it reopens, and .research-toolkit/logs/setup-<timestamp>.jsonl is the append-only attempt log. The bootstrap workspace's .gitignore ignores .research-toolkit/logs/ alongside the existing derived-data rules. Open Setup Log opens the newest log file, and Copy Installation Diagnostics copies the verdict, the host tools, the preflight results, the per-step attempts and the log file path to the clipboard.
• Roll back managed runtime lists the managed runtimes this workspace holds, re-verifies the candidate with the real reading check, and only then points the workspace back at it. The runtime an earlier release installed stays on disk.

Controls

Choose a goal, not a server

Assistant clients cap how many tools one session may enable — Copilot agent mode refuses more than 128 enabled tools, and selection reliability starts dropping well before that, around 30–50 tools. Tool definitions are re-sent with every request, so a wide tool surface is a recurring context cost, not a one-off cost. The toolkit therefore lets you trade surface for focus, and no preset ships more than 12 toolkit tools.

Basic offers the first two presets, Recommended Research offers the first five, and Full offers all nine. Each package has exactly one default preset; a saved preset that the selected package does not offer falls back to that default and the panel says so. The panel also distinguishes the preset you saved from the one currently applied to the assistant's tool list. Recently used presets are offered first. The preset reaches the managed workers as RESEARCH_STACK_TOOL_PRESET, so only the tools serving that goal are registered and a server the goal does not use is not offered.

Context estimate. After component setup, the receipt stores the measured size of every discovered tool definition (name + title + description + input schema; characters ÷ 4, plus 40 tokens of framing per tool). Every figure states its basis: measured from this worker's tools/list, partial (some tools measured, the rest at the vendor figure), or vendor estimate at 640 tokens per tool definition. External counts are published vendor toolset figures, never presented as measurements taken by this extension.

Every shipped tool also publishes a title and read-only/destructive/idempotent annotations, and the workers answer tools/list with a 300-second private cache hint, so a client does not re-fetch the same definitions on every turn.

Read the inventory correctly

Installed means the running editor/extension, editor registry, setup receipt or selected Python environment supplied installation evidence. Ready means the specific check in the row succeeded (host running, version command, SDK import, library test, real MCP fixture read/report or corpus/record-store round trip). Files prepared and Configuration present do not establish an installed or running MCP server. Not verified identifies a client/kernel/account/service first task still required. Not detected means absent from inspected locations, not a machine-wide absence. Planned / Not bundled describes toolkit integration status even when unrelated software exists elsewhere.

The readiness text now states setup completeness as well as gates: Package setup for Full: 3 of 4 component steps installed, 1 recorded but needing repair (files it produced are missing), 1 optional step(s) deliberately not installed · G3 not passed. That line describes what this workspace has installed and observed; it does not close a gate.

Host-tool rows report where the tool was resolved from and the version its version command reported, or the categories searched when nothing was found. A tool that exists but does not answer --version, or that is older than the registry minimum, is reported as detected with a failed check — not as installed, and not used by setup.

The extension shows its actual running version. Python worker and dependency versions come from the inspected environment, not catalog requirements or your selected package. Editor-extension presence does not prove authentication or kernel execution. The running managed worker is verified through real local MCP fixture tests. No external provider or Zotero endpoint is contacted during those checks. The walkthrough shows how to complete each first functional task.

Preview scope

Selecting a package or a tools preset saves a preference. Neither installs, removes, nor configures components; a preset only changes which tools the toolkit registers when its managed servers start. Setup runs only when you start it. Basic/Research remain prototypes with G1/G2 open; Full is a foundation with G3 open, and its shipped slice is now real: a persistent workspace corpus index and a standard-library SQLite record store (schema 3) with ten verbs — index_corpus, unindex_corpus, search_corpus, verify_sources, evidence_read, claims_read, claims_write, claims_export, store_status, store_maintenance — where the everyday workflow verbs are separated from the destructive maintenance verbs. Markdown and text files, and now PDF and DOCX files, can be indexed into that store with their original-document locators. Vector search, embedding models, DuckDB/Qdrant, HTTP index services, external account/service provisioning, notebook kernel setup and automatic updates remain separate. Successful reading checks prove the tested local protocol workflow and do not close every profile gate or establish assistant authorization. 0.3.9 does not install uv itself, does not run setup silently or in the background, does not execute notebook kernels, does not connect to external providers, does not build the extraction-to-index bridge, and does not OCR a scanned page. This version does not complete G4.

The VSIX contains the controller, install-plan engine, diagnostic script/probe, GUI assets, registry, Markdown guides, reviewed worker source/locks, reviewed overlay templates and the reviewed topic skill bundles with their generated catalog, with no production npm dependencies or prebuilt Python environment. The panel accepts validated component IDs, validated step ids, boolean settings and fixed actions. Every external tool run goes through one reviewed module, extension/runner.js: a single execFile boundary with windowsHide: true, shell: false, an 8-second default timeout for probes, an 8 MiB output cap and bounded report text. Host-tool lookup is extension/hosttools.js, preflight is extension/preflight.js, step bodies are extension/steps.js, status wording is extension/status.js, log/status persistence is extension/setuplog.js, and the uv-free comparison of a shipped lock against its shipped project file is extension/lockfile.js. No command is read from MCP configuration. Setup explicitly syncs only the toolkit-owned environments. Reading checks explicitly start temporary local stdio MCP servers; selected-document reads require a file choice inside the workspace. See the onboarding check disclosure and VS Code webview guide.

Keep guides useful as components grow

Each component has its own Markdown guide and registry entry. Packaging generates the hub and validates guide sections/links, and the VSIX audit verifies every guide against its source. Guide text is a release snapshot with a review date; Latest docs opens the official maintained source on request. No background download or automatic freshness claim is made. Read documentation maintenance to add/update a component without rewriting the control panel.

The 0.3.2 reference test host is Windows 11 x64 / VS Code Desktop 1.141.0. The 0.3.6 install engine, host-tool resolution, preflight, setup log and installation status, the 0.3.7 lock/project comparison and lock-drift recovery, the 0.3.8 UTF-8 output guarantee, and the 0.3.9 ingestion, freshness, migration and bundle rules are covered on this Linux development host by the automated node test suite (the seventeen test files npm test runs, including test/hosttools.test.js, test/runner.test.js, test/preflight.test.js, test/setuplog.test.js, test/status.test.js, test/steps.test.js, test/lockfile.test.js, test/lockfile-adversarial.test.js, test/bundles.test.js, test/module-boundaries.test.js and test/gui-status.test.js) and by the Python suite, which also gates every shipped lock against the project file beside it. The real Extension Host and browser renderer receipts for 0.3.8 were never produced; the ones for 0.3.9 are still to be produced on that reference host, and the exact 0.3.10 candidate has passed an isolated Windows VS Code 1.145.2 Extension Host smoke test. The declared 1.140.0 floor has not been retested for this release. macOS, web, remote and other editor versions remain unverified. This is a public preview with G1–G4 open.

Build and verify from source

From extension/, run npm ci, npm test, npm run package, then npm run verify-package and npm run check:payload. Both gates take the artifact path from extension/vsix-manifest.json, so they audit the VSIX this release cuts instead of an older one. python3 scripts/lockintegrity.py reports whether every lock this toolkit ships matches the project file beside it, and exits non-zero when one does not. The repository also includes real Extension Host tests (npm run test:host) and a browser renderer test (node test/browser.test.js). The latter uses development-only Playwright, resolved from your test environment; set PLAYWRIGHT_CHROMIUM_EXECUTABLE when using an existing Chromium executable. No browser is shipped in the VSIX.