Archived supporting record · Earlier methodology

This dated note retains preparation evidence, not a separate research story. SDK and Microsoft examples are separate technical material, not this incident's evidence chain, next stage or repair. Read the continuing incident case

Supporting record 03 · Code and reproducibility · Topic 01

Follow the repair beyond its version label

The candidate repair still declared 0.22.0 in development. Source ancestry identifies v0.22.1 as the first stable release containing it. Runtime validation remains a separate gate.

Source history · not an execution result

A repair has a lineage.

  1. Prerequisite #4650 Earlier recovery work
  2. Parent 18de6513 Candidate baseline
  3. Repair 3603dc92 Candidate fix · #4654
  4. Stable v0.22.1 8 September 2026

Arrows show the reviewed source progression, not relative timing or measured improvement. Inspect the candidate diff

The correction

The initial 17 October review said the first released package containing the SDK repair was unverified. On 18 October, a read-only source-history review resolved the first stable release as v0.22.1, published 8 September 2026 at 09:18 UTC. The earlier uncertainty remains part of the record; it is no longer the current conclusion.

Follow the source, not just the label

The candidate before/after pair is the immediate parent 18de6513 and repair 3603dc92. It retains prerequisite PR #4650 and isolates PR #4654. At the repair, the package configuration still says 0.22.0.

The repair-to-v0.22.1 comparison reports 50 commits ahead and zero behind, with the repair as merge base. The release tag points to commit f0b884ac4c583637a0757b31702fa9808f0f84ad. The preceding stable v0.22.0 does not contain the repair. The review checked the relevant official release history; this is a first-stable-release conclusion, not an exhaustive claim about every possible prerelease artifact.

PyPI 0.22.1 supplies the corresponding package record and artifact provenance. Source ancestry and artifact identity tell us where the change was released. They do not establish that our fixture reproduces the original failure or that the released wheel behaves correctly in our environment.

A useful dependency finding

The candidate baseline and repair have identical uv.lock files. This reduces one source of variation but does not close the environment gate: the build-system requirement for hatchling is unpinned and absent from that lock. A reproducibility package needs an explicit, reviewed build environment in addition to its application dependency lock.

Inspection of tests/conftest.py also found that a dummy API key is inserted only when ambient credentials are absent. That fixture does not sanitize existing credentials or enforce network isolation. A later execution must supply those controls explicitly. No upstream tests or scientific fixtures were executed for this journal entry.

Decision and remaining uncertainty

The release-identity gap has narrowed. Rights and dependency review, an agreed behavioral check, a pinned build environment, and credential-free isolation remain prerequisites to admission. The public fix is already known, so this candidate is development material rather than an unseen-diagnosis holdout. The evidence count stays at three source families, zero independent reproductions, zero admitted executable benchmark cases and zero benchmark scores.

Inspect the exact artifacts