[Stella Huang (StellaHuang95)]

Summary

Add report-only packaged-release compatibility assurance without changing Python's production defaults, explicit Environments opt-out, extension dependencies, PET bundling, or publishing/approval behavior. Existing source/native/smoke tests remain intact.

This addresses a specific release gap, not an alleged lack of all integration testing or an existing public PET mismatch: inspect exact original VSIX bytes, load Core/Environments as installed extensions, and verify real discovery, selection/switching and normal Core execution with Environments explicitly on and explicitly off.

Before and after

Before, the existing smoke/source/mocked paths did not establish the requested deterministic final-package pair coverage and actual selected-interpreter execution across both modes/platforms.

After, the shared runner (run.js --plan --output) consumes pinned local VSIX/version/SHA inputs, isolates profiles/processes before activation, discovers two real shallow venvs, selects each, invokes normal python.execInTerminal, and checks nonce-tagged actual sys.executable and sys.prefix. A terminal appearing or a command returning is not a pass. Only the independent controller is a development extension; product identities, versions and installed locations must match the inspected archives.

On mode observes/restores the real public Environments execution method, including inherited class methods. Native PET startup path/hash must match the actual installed supplier; PET-omitting Environments must use Core's packaged PET. Off mode checks native Core PET when observed, or positively observed supported legacy JavaScript discovery plus the same complete functional assertions; it never forces an experiment or fabricates runtime PET identity from package presence. Missing/wrong provenance still fails. Optional metadata remains explicitly unavailable rather than imposing a new supplier version floor.

Actual CI-built candidate direction

The existing PR/CI workflow now has a small read-only Windows/Linux candidate job after its unchanged build-vsix job. It downloads that same run's original ms-python-insiders-vsix-{target} artifact, requires its exact one expected VSIX, and reuses the fixed-partner preparation and unchanged functional runner. There is no rebuild, native-build step or binary replacement in the consuming job. Candidate version/hash and producer run/artifact/head/merge-source provenance are retained; missing, wrong or explicitly empty candidate inputs fail instead of substituting a released Core.

The frozen released-pair harness self-test is kept separately. Thus source assurance of the framework does not stand in for testing the current CI-built candidate.

Genuine persistent upgrade lifecycle

Upgrade phases use normal isolated VS Code windows without --extensionTestsPath. VS Code explicitly uses in-memory Memento storage during extension tests, even when profile/workspace paths are reused. The controller activates normally, returns immediately rather than holding a driver promise, runs the same assertions, writes evidence and requests a graceful quit. The directly owned process boundary verifies full shutdown before replacing only the installed Environments directory.

A controller-private global and workspace Memento nonce is seeded only before restart and checked read-only afterward. Storage continuity failure is infrastructure evidence, not a product association verdict. The last selected product fixture must still be observed before any reselection; product state is never serialized/reseeded or patched. Explicit false/settings survive. Single-phase candidate/released checks retain their original test-host route.

Verified execution at the reviewed head

Head: 36931aba4f11db19e29f7bdefaeec9acdaff1832; inspected upstream base: 893ed0b7b22319c91c77b51cdb242b2eab5e857e.

Actual coverage	Result and retained evidence
Frozen Core 2026.10.0 + released Environments 1.42.0, VS Code 1.110.0	Windows and Linux on/off passed: run 42289233311
Same-run CI-built Core 2026.11.0 candidate + released Environments 1.42.0, VS Code 1.110.0	Windows and Linux on/off passed, two real executions per mode: producer/consumer run 42289233383
Companion no-PET Environments 1.43.0 candidate + released Core 2026.10.0, upgrading from bundled-PET Environments 1.42.0	Actual Windows normal-host before/after passed both modes, both disk nonce controls and strict saved-fixture-two read before reselection: run 42289867126

Independently downloaded the original producer VSIXes and compared them with the tested candidate hashes:

Core candidate artifact from run 42289233383	Original = tested SHA-256
ms-python-insiders-vsix-win32-x64	4522c94cdd2c4fef94bf15e8c9cfb6e3bec3ca00c13edcef3fab5cb377486a99
ms-python-insiders-vsix-linux-x64	43ecb5b95c63f12a0677dda4098146835b54de173038bbcd30c72e2d98d71e4c

Manual retained-report inspection verified installed versions/locations, requested/effective/global mode, each .venv-one / .venv-two executable/prefix/nonce and on-mode delegation. The companion upgrade's four actual process argument lists contain no test-storage flag, controller mode is Development, global/workspace nonce tokens survive, and all eight raw Python result JSONs match the reported executions. On mode genuinely switches from Environments' own PET to Core's exact path/hash (60f09e780cdb97f9fd4e353bf2f9be533463d7183bcb9d978a4f1d459b941120); off mode remains positively observed legacy JS/no runtime PET.

Final hosted guards: 35 passing on Linux; 34 passing on Windows with the one Linux-only regression explicitly pending there. Local focused tests, ESLint, Prettier, YAML and PowerShell AST checks pass. Original Core PR/CI is green. The self-contained ZIP's dependency/file hashes and extracted-package execution outside the checkout were checked. No developer profile/updater/existing process or downloaded product bytes were modified.

Review, isolation and rollout

Independent focused review/re-reviews and manual source/actual-host walkthroughs corrected inherited API observation, documented-public-API mode proof, actual expanded ZIP bounds, owned descendants after parent exit and normal completion, cold Windows test timing, legacy search depth/backend evidence, workspace-only setting scope, and real-storage upgrade semantics. Missing inputs and incomplete cases remain explicit failed/infrastructure/not-run evidence. Signing/publishing/OAuth tokens and developer injection variables are not inherited by candidate processes.

Known released Environments 1.42.0 lifecycle/manager warnings remain in raw baseline logs; they are not described as an error-free baseline or blamed on the candidate. The companion candidate's missing-context lifecycle error is fixed there, and remaining shutdown warnings remain observable. Passing the functional assertions is not a claim that every vendor log line is clean.

The standalone Azure adapter is an opt-in, same-project, pre-sign Build-artifact report consumer (System.TeamProject, including a DevDiv-hosted consumer). It has no signing, publishing or feed-authentication steps and invents no Core DevDiv production graph. Existing stable human approval, prerelease schedules/defaults and source-built PET policy are unchanged.

Still not official signed/CD certification: shared-template owners must validate real Azure producer permissions, connect a final post-Sign hook, reconcile tested VSIX SHA-256 with exact signed/published bytes without rebuilding, and resolve one trusted PET producer snapshot before packaging targets where the architecture permits. CI-built candidate coverage above is distinct from that release-owner handoff.

All five contribution commits are intentionally unsigned (git %G? = N) with the coauthor trailer. The existing VS Code PR Check therefore correctly awaits two collaborator approvals; no gate/signing workaround, merge or extension publication is requested.