Historical compatibility follow-up protocol

Prepared after the first historical run and before executing this follow-up. This is explicitly exploratory compatibility recovery, not a preplanned success. Original ledger, inputs, failures and results remain available unchanged.

The first run reproduced the uppercase FILE-scheme fix, but both jsonschema 3.0.x versions failed importing pkg_resources, jsonschema 4.17.2 was unavailable from the package index, and the chosen IDN email was accepted by both Marshmallow versions.

Two changes are fixed in advance of the new run:

  1. Add setuptools 70.3.0 (which supplies pkg_resources) to both jsonschema 3.0.x environments. Keep all other captured dependencies pinned.
  2. Use jsonschema 4.17.1 as the available predecessor to 4.17.3. Issue #1018 describes the regression starting in 4.16.0; the pinned changelog associates the fix with 4.17.3. This is not evidence about the unavailable 4.17.2 package.

All eight paired inputs, labels, policies and adapters remain identical. The IDN case is rerun unchanged; no search for a different successful reproducer is made. The same two Marshmallow version comparisons act as checks on repeat execution.

The follow-up driver, base collector, protocol, dependency requirements and parent capture identity are frozen before new collection. The driver hash is included in the prepared inputs; requirements hashes are verified before installing. Actual installation reports retain artifact URLs and hashes, along with pip-freeze locks. Offline replay and fresh package execution are distinct operations. Both the initial and follow-up tables must be reported, including failed reproduction.

A successful reproduction requires the issue-triggering outcome to change from incorrect to correct and the preservation control to pass in both versions. A fixed example is a historical regression reproduced, not a newly discovered bug, an external adopter, or evidence of a sensitivity advantage over detailed pytest.

Lockfile correction after the first follow-up attempt

The first follow-up accidentally retained setuptools 84.0.0 while also requesting 70.3.0. Pip refused these two environments before executing their samples. Other candidates ran; that capture and replay remain under compatibility-followup/. Version 2 replaces the existing setuptools pin instead of appending a conflicting one. The corrected driver and requirements were frozen again before new execution. Case inputs and labels remain unchanged. Results of all attempts are retained.