[dinakarjs]

The release artifact checks exercised inclusion verification, while chain and receipt smoke tests used an editable checkout. This PR extends the existing wheel and sdist checks to run all three commands from installed packages outside the source tree.

The chain smoke check now feeds both existing September 1 and September 25 checkpoints in order and requires checkpoints == 2, exercising the adjacent-checkpoint consistency proof. Its negative control alters only the second entry's producer while preserving both signed checkpoints and their proof, and requires the specific recomputed-entry-root mismatch diagnostic. A generic root error or a one-checkpoint success cannot pass.

Before adding optional dependencies, require the documented missing-witness-extra diagnostic. Then install the existing hash-pinned witness lock, run pip check, verify the archived September 7 receipt, and reject an unrelated valid Ed25519 witness key while confirming the registry checkpoint signature still passes. Fixture files and accepted keys are unchanged. These are offline archive checks, not fresh witness observations.

Validation — 31 October 2026

Published head: 0387e94. Published tree 06ed1d145e5bd5d9ecf515f964386b3d6e887dbc equals the locally validated tree.

Fresh hash-locked Linux/Python 3.12 environment:

• Full unittest suite: 412 passed; focused release-safeguards suite: 17 passed.
• Ruff and changed-file whitespace checks pass.
• Fresh wheel and sdist built with hash-pinned CI/publish dependencies and build --no-isolation; both pass twine check.
• The exact workflow installed-artifact shell block passes against both distributions in separate fresh environments outside the checkout, before and after witness extras. Both pip check runs pass. No release workflow dispatched or package published.
• Restoring only the previous artifact checker makes test_actual_chain_controls fail because it invokes only one checkpoint, and test_chain_refuses_a_success_response_with_only_one_checkpoint fail because it accepts the incomplete positive result. Both fail by assertion, not import errors.
• Existing always-accept/reject and unrelated-root-error controls remain effective.

Hosted checks and independent maintainer review on this new head remain pending. The follow-up changes only the external checker, its tests and contribution documentation; packaged runtime source is unchanged. Complements #167 without changing its adapter or verifier semantics.

Prepared with OpenAI Codex; commit DCO-signed.

[dinakarjs]

Closure review request to @lywinged / @rajnisht7: #171 at 9de161a and portable-corpus #167 at 934efa3 retain their documented technical validation and still need independent maintainer acceptance. These are bounded offline distribution/corpus checks; the archived witness receipt is not a fresh witness observation. The journal/readback drafts #144/#156 remain gated on their separate identity, retry and reconciliation contract decisions. I cannot independently approve my own implementation or select those owner policies. Prepared with OpenAI Codex.

[rajnisht7]

check_chain() only passes registry/2026/09/01.ndjson and asserts checkpoints == 1 which covers single-checkpoint signature + MMR rebuild + the altered-entry diagnostic, but never exercises the adjacent-checkpoint path (verify_checkpoint_link / consistency proof), repo already has the second checkpoint in registry/2026/09/25.ndjson (mmr_size=3, prev_size=1, real consistency_proof extending the first). Both the CLI help and docs treat checkpoint-to-checkpoint consistency as one of the two independent properties of chain

kindly update check_chain() to feed both entries in order and assert checkpoints == 2. Keep the altered-entry negative test, just run it against the multi-entry invocation. That makes the installed-artifact check actually match the claim “verify a valid checkpoint chain”.

[dinakarjs]

@rajnisht7 please re-review 0387e94. Your adjacent-checkpoint finding is addressed: the installed checker feeds September 1 and September 25 entries in order, requires checkpoints == 2, and rejects altered successor content while preserving both signed checkpoints and the consistency proof. Both new controls fail by assertion with the old checker restored. Full suite: 412 passed; Ruff, fresh wheel/sdist builds and both isolated installed-artifact smoke paths pass. Current-head CI, Workflow lint and CodeQL have all succeeded. These remain offline archive checks. Formal reviewer assignment returned 403, so this conversation comment is the re-review request. Prepared with OpenAI Codex.

[drk-ram]

Technical Review ( ools/check_installed_artifact.py, .github/workflows/publish.yml & ests/test_release_safeguards.py):

1. Adjacent-checkpoint consistency & MMR rebuild verification (check_chain): Feeding both
   egistry/2026/09/01.ndjson and
   egistry/2026/09/25.ndjson in order and requiring checkpoints == 2 verifies the multi-checkpoint consistency proof (prev_size=1 -> mmr_size=3) in the installed wheel/sdist, while the tampered-successor negative control (�ltered["producer"] += "-tampered") confirms that post-checkpoint content mutation is rejected (
   ecomputed root ... altered after it was checkpointed) even when both checkpoint signatures and the consistency proof remain intact.
2. Two-phase witness-extra packaging gate (--witness): Exercising check_installed_artifact.py first without
   equirements/witness.txt (asserting exit code 2, clean user-facing pip install "trace-verify[witness]" remediation, and "Traceback" not in result.stderr) and then re-running with --witness after --require-hashes installation tests both packaging states in .github/workflows/publish.yml.
3. Key-separation negative control (REGISTRY_KEY vs. WITNESS_KEY): Passing the valid 32-byte Ed25519 REGISTRY_KEY in place of WITNESS_KEY (checks.checkpoint_signature is True while
   eceipt signature/inclusion failed) verifies actual cryptographic domain/key separation rather than a trivial hex-parser error.