release: 5.1.0 — ship the envelope profile in the distribution - #161
Merged
Conversation
added 4 commits
August 31, 2026 04:07
…ay why it was missing THE MEASUREMENT THAT COMES FIRST. Built from main at 27a84db: `docs/RECEIPT_ENVELOPE_PROFILE.md` appeared **0 times in the sdist and 0 times in the wheel**. The vectors were already complete — 21 of 21 files, 10 of 10 case.json — because `graft conformance` covers them. Only the prose document was absent. THE CAUSE, stated precisely because the obvious explanation was wrong. NO prune and NO exclude rule matched the file; both were checked pattern by pattern and matched zero. MANIFEST.in is an allowlist and the file was on no line: it was missing BY ABSENCE, NOT BY EXCLUSION. Searching for the offending prune rule would have found nothing and left the document out. One `include docs/RECEIPT_ENVELOPE_PROFILE.md` fixes it. MEASURED AGAIN AFTER THE FIX, because a repair without a second measurement does not count: 1 occurrence in the sdist, the file readable from the archive at its full 240 lines, docs entries 19 -> 20 (exactly one more), vectors unchanged at 10 of 10. The wheel still carries 0, which is correct — the wheel is the import package and prose does not belong in it. The 5.1.0 sdist carries version and profile in the same artefact (PKG-INFO: 5.1.0, profile: 1). WHY MINOR, argued from the changes rather than from habit. Measured against tag v5.0.0: 23 commits, 41 files, 2071 insertions, 32 deletions, 0 files removed. Across all of src/: 0 removed public names and 0 removed or changed signatures (`-def`/`-class` lines in the diff: zero). One new public function, `classify_eval_claim`, and one private helper. New shipped material rules out PATCH; nothing removed and no signature changed rules out MAJOR. Version anchors pulled together in one step: pyproject.toml, src/proofbundle/__init__.py and CITATION.cff now agree on 5.1.0. The integrity checker named two prose places that still said 5.0.0 (RELEASE.md line 81, docs/readiness_pack/PROGRESS.md line 3); both corrected, after which `check_version_and_changelog` reports OK. The CHANGELOG entry records `scripts/mutation_operators_fresh.py` as A SCRIPT AND NOT A GATE — it reports operator staleness and nothing blocks on its output. NOT A RELEASE. No tag, no publish. `release.yml` runs on `push: tags: ["v*"]`; the tag is the one-way door and is not this commit's to open.
…se was corrected
MEASURED, one failure in 2598 local tests:
`test_audit_candidate_360.py::TestReadinessPackManifest::test_check_passes_on_generated`
with `manifest drift: a pack file changed but MANIFEST.sha256 was not regenerated`.
THE CHAIN, and it is mine. The version-integrity checker required `docs/readiness_pack/
PROGRESS.md` line 3 to say 5.1.0 instead of 5.0.0. That file is part of the readiness pack,
and the pack carries a SHA-256 manifest over every one of its files. Correcting the prose
therefore invalidated the manifest — the derived artefact was not pulled along.
Regenerated with the intended producer (`scripts/readiness_pack_manifest.py --generate`),
not by hand. PROGRESS.md now hashes to 940ecb46… on both sides; the test passes.
The advisory self-receipt and its public key change with it. That is the design and not
drift: the script states it in its own header — the receipt is signed with an EPHEMERAL key
generated at build time, so it proves the pack CAN be receipted and verifies offline, and is
explicitly NOT an attestation of authorship by a pinned identity.
TWO WRONG TRAILS DISCARDED BY MEASUREMENT, not by opinion:
* `VERSION_UNDER_TEST = "5.0.0"` in the audit matrix is NOT the cause and stays. Its test
passes (8 of 8); it checks the BINDING, not the literal. The docstring warns explicitly
that editing the literal "would make this instance green and recreate the class at the
next version bump" — the matrix indexes `release_evidence_slots` by that pin, and there
is no 5.1.0 evidence slot yet.
* The `MANIFEST.in` line is NOT the cause. sdist from main: 740 files; from this branch:
741. The difference is exactly the added profile document; nothing disappeared.
STILL OPEN, and not claimed: whether this also clears `coverage`, `crypto-floor` and
`hermetic-cleanroom` on CI. Those run in their own environment and are re-measured by pushing
this commit, not by asserting it here.
… — die Matrix urteilt jetzt ueber das, was ausgeliefert wird
Owner-Karte OA-4f783bfb5b, Option 1: "5.1.0-Slot fuellen und das Receipt ueber
den Runner erzeugen, dann ziehen und neu messen."
WAS GEMESSEN WAR. audit-candidate-matrix meldete auf diesem Zweig VERSION PIN
DRIFT: die Matrix war auf 5.0.0 gepinnt, das Paket liefert 5.1.0. Sie las damit
5.0.0-Bereitschaftsbelege und einen 5.0.0-Vorab-Audit-Eintrag, und ihr Urteil
sagte nichts ueber 5.1.0 aus. Der Riegel version_pin_binding hat das selbst
gemeldet — er wurde am 25.08. genau dafuer gebaut und hat getan, wozu er da ist.
DER 5.1.0-SLOT nennt drei delivers und ZWEI open, und die zwei sind der
eigentliche Inhalt: das Rad traegt das Umschlagprofil und die Vektoren weiterhin
NICHT (null Eintraege unter docs/ und conformance/, vor wie nach dem Fix), und
weil pip das Rad bevorzugt, bekommt ein schlichtes pip install proofbundle beides
nicht. Dazu die Vektorluecke bei R5/R6. Ein Bereitschafts-Slot, der das
verschweigt, waere die Ueberbehauptung, gegen die C11.1 steht.
MANIFEST.sha256 ist mit dem vorgesehenen Erzeuger neu erzeugt, nicht von Hand:
scripts/readiness_pack_manifest.py, 11 von 11 OK, zweiter Lauf byte-identisch.
Von Hand haette es denselben Fehler wiederholt, der in der Nacht zum 31.08. vier
Checks rot gemacht hat.
DIE KONSTANTE: scripts/audit_candidate_matrix.py:60, genau eine Stelle,
5.0.0 -> 5.1.0. version_pin_binding steht danach auf bound. Sweep nach weiteren
fest verdrahteten Versionen: ein zweiter Treffer geprueft und verworfen
(gate_qualification_harness.py:155 ist eine in sich geschlossene Attrappe —
_receipt() baut damit und _v() prueft mit expected_version=_VER dagegen, der
Literalwert ist beliebig).
NEU: scripts/audit_output_aufloesbar.py. Das v5.0.0-Receipt ist gueltig und
bindet den Tag-Baum, aber sein signierter audit_output_digest liegt auf 0 von 915
verfolgten Dateien; die im audit_command genannte Aufzeichnung existiert, ist
verfolgt und traegt einen ANDEREN Digest. C12.1 fuehrt das als ehrliche Grenze
("tamper-evident and attributable, not checkable"). Dieser Pruefer macht es
pruefbar: drei Zustaende mit eigenen Exit-Codes, und er rechnet wie das Receipt
ueber den DEKODIERTEN Text statt ueber Rohbytes — bei einer Datei mit einem
ungueltigen Byte weichen beide ab. BEWUSST NICHT in pre_tag_audit_gate
verdrahtet: das liesse v5.0.0 rueckwirkend durchfallen, und eine Regel, die die
Vergangenheit aendert, ist keine.
WAS C12.1 WEITERHIN ROT LAESST, und das ist richtig so: es gibt kein Receipt fuer
5.1.0, und es darf hier auch keines geben. Ein Receipt bindet
subject_tree_digest; ein Arbeitszweig bekommt beim Merge einen weiteren Commit,
ein hier erzeugtes Receipt bezeugte also einen Baum, der gleich aufhoert zu
existieren. Owner-Entscheid vom 31.08.: Merge, dann Beleg gegen den GEMERGTEN
Baum, dann die Owner-Signatur, dann der Tag.
NICHT IN DIESEM COMMIT: die inspect_ai-Pin-Anhebung auf <=0.3.261. Die Messung
dafuer liegt vor (frische Umgebung, 19 von 19 Tests, alle 17 on_*-Methoden der
0.3.261-API, die unter 0.3.217 aufgezeichnete Fixture liest weiter) — der Owner
hat sie fuer diesen Merge ausdruecklich zurueckgestellt.
Tests: tests/test_audit_output_aufloesbar.py 7/7. ruff sauber.
… still geweitet
Owner-Anordnung 2026-08-31T12:28:32Z. Sie faehrt mit dem Lauf mit, der durch den
vorigen Commit ohnehin faellig ist, und kostet damit keinen zusaetzlichen
Mutationslauf — eine pyproject-Aenderung beruehrt ihn nachweislich nicht.
DER PIN-KOMMENTAR VERLANGT GENAU DAS: "a new inspect_ai release now needs a
MEASURED bump here, not a silent widen". Hier ist die Messung.
Gemessen in einer FRISCHEN Umgebung (eigenes venv, inspect_ai==0.3.261 plus
dieses Paket vom Zweig gebaut, keine Mocks — die Tests importieren das echte
Paket):
* Entry-Point-Discovery findet `proofbundle`; `ProofbundleHooks` ist eine
echte `Hooks`-Unterklasse und traegt alle 17 `on_*`-Methoden der
0.3.261-API. Keine ist verschwunden, keine ist dazugekommen, die wir nicht
implementieren.
* `test_inspect_hook.py` 9 von 9, zusammen mit `test_adapters.py` 19 von 19.
* Die unter 0.3.217 aufgezeichnete Fixture liest weiter (`version=2`,
`status=success`) — das Log-Format ist uns nicht unter den Fuessen weggezogen.
DIE OBERGRENZE BLEIBT EINE OBERGRENZE. 0.3.262 und spaeter sind weiterhin
UNGEMESSEN und damit ausgeschlossen. Zugelassen ist, was gemessen wurde, und die
naechste Version verlangt dieselbe Arbeit noch einmal.
Geaendert an beiden Stellen, wie angeordnet: das optionale Extra `inspect` und
die `dev`-Liste. Der historische Kommentar zur 0.3.260-Messung bleibt stehen —
er ist die Spur der vorigen Messung, nicht veralteter Text.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Prepares 5.1.0. Not a release: no tag, no publish.
release.ymlruns onpush: tags: ["v*"].The measurement that comes first
Built from
mainat27a84db3c6dc:docs/RECEIPT_ENVELOPE_PROFILE.mdconformance/envelope_profile/vectorscase.jsonThe vectors shipped. The document explaining what they prove did not.
The cause, stated precisely — the obvious explanation was wrong
No
pruneand noexcluderule matched the file. Both rule sets were checked pattern bypattern against the path and matched zero.
MANIFEST.inis an allowlist and the file was on noline: it was missing by absence, not by exclusion.
That distinction is not pedantry. Searching for the offending
prunerule —prune audit_artifactsis the natural suspect — finds nothing, and the document stays out.
One line fixes it:
Measured again after the fix
A repair without a second measurement does not count.
maindocsentries in sdistThe 5.1.0 sdist carries both in the same artefact:
PKG-INFO: Version: 5.1.0, profile present.Why MINOR, argued from the changes
Measured against tag
v5.0.0:src/: 0 removed public names, 0 removed or changed signatures(
-def/-classlines in the diff: zero)classify_eval_claim; one private helperNew shipped material rules out PATCH. Nothing removed and no signature changed rules out MAJOR.
Version anchors
pyproject.toml,src/proofbundle/__init__.pyandCITATION.cffnow agree on 5.1.0. Theintegrity checker named two prose places that still said 5.0.0 —
RELEASE.mdline 81 anddocs/readiness_pack/PROGRESS.mdline 3. Both corrected;check_version_and_changelogthenreports OK.
The CHANGELOG records
scripts/mutation_operators_fresh.pyas a script and not a gate — itreports operator staleness and nothing blocks on its output.
Status
Opened as a draft, so the required
guardcheck runs against the branch. Merging and taggingare separate decisions and are not requested here.