v4.11.0

COLEMAN 4.11.0 — Reproduce Python faults with their execution context

A fix can reproduce in one locale and disappear in another. COLEMAN's optional
Python source producer keeps those conditions and outcomes visible: unchanged
buggy/fixed PySnooper trees, one common upstream fixture, pinned wheels and a
declared CPython image. The existing controlled-observation domain carries the
results; native TCPCI experiments keep their established runner and checkpoints.

What you can use

• Collect the frozen pysnooper-1-ascii-v1 and pysnooper-1-utf8-v1 profiles
  through python -m coleman.transports.python or the typed Python API.
• Inspect original bounded packets, actual interpreter/locale/distribution facts,
  explicit exception identities and separate case/producer nanosecond counters.
• Install pinned wheels in an atomically allocated private temporary directory
  inside bounded container tmpfs, with explicit storage policy and cleanup.
• Reopen completed evidence offline without Docker. A real process kill recovers
  an uncommitted role as interrupted, without silently repeating its observation.
• Validate recipe, context, raw protocol, normalized observations and immutable
  receipt together. Completion is written last and requires both protocols.

The complete guide covers installation, explicit
arm64 runtime preparation, collection, component terms, Python API validation and
recovery. Foreign source, wheels and raw data stay outside the repository and
package. No image is pulled or project setup script executed by the producer.

What the qualification found

The installed package collected four role observations from one selected upstream
test in two predeclared contexts. Under ASCII, the buggy revision raises
UnicodeEncodeError and the fixed revision passes. Under C.UTF-8, both pass.
The existing strict classifier retains the exception-to-pass pair as
inconclusive; it is not relabeled as an assertion failure or expected pair.

These contexts share one curated fix and dependence group. They do not establish
independent-fault diversity, a full upstream suite, historical CI chronology,
policy benefit or scientific admission. Case timing is not native scheduling
cost. Results retain constructed, not_evaluated and insufficient_evidence.

Architecture and compatibility

The optional transport reuses source views, materialization, bounded ZIP
selection, process collection, immutable artifact writing and controlled-result
conversion. A small shared implementation-identity helper preserves the Java
matrix's existing hash algorithm while serving Python capture too. The core
does not import CLI, MCP, Docker or the Python producer.

New records require explicit schema version 1. Missing/future/unknown versions
and incompatible units reject. Existing controlled/JUnit schemas and meanings
remain unchanged; no old data is silently migrated. Transport validation binds
the installed package/version: retain the original reviewed package to validate
its old producer artifacts, or collect a new generation under a new package.
Generic domain datasets remain readable through their existing API.

Terms and limits

Subject, fixture, wheels, vendored components and additional notices have
independent pins and recorded terms. PythonToolbox is not blanket MIT; its
component map retains Apache, BSD, wxPython and inferred CPython-derived code
alongside MIT components. The unused headerless mapping-test attribution remains
explicitly inferred and available for later source-admission review.

The SDK remains Python 3.14+. The historical CPython 3.8.1 image is an optional
isolated benchmark condition; SDK dependency audits do not establish that image's
security. Initial presets are native linux/arm64 and an explicitly partial
fixture. Broader source coverage, admission, comparisons and the confirmatory
corpus report remain in #261's public subtasks, beginning next with #306.