Catch up on policyengine.py releases whose dispatch never arrived

[MaxGhenis]

Stacked on #163. WIP: W6 of the Autumn Budget 2026 CI plan.

Why

W4's post-release NotifyConsumers dispatch can be lost to a missing GitHub App, an outage or a cancelled run. The r4 audit's design asked for a scheduled reconciliation that finds missed releases. Before this PR, the receiver's schedule only drained its own queue.

What

• Discovery. The scheduled run (and a manual run without a request) now begins with a discover job, pipeline/uk_replay_discover.py. It takes every policyengine.py release on PyPI that is newer than the newest certified replay variant, final, and named by no request yet. It handles them oldest first, at most three per run, and logs the rest.
• Request built from primary artifacts:
  • the wrapper wheel, checked against PyPI's SHA-256;
  • the wheel's packaged bundle manifest (its SHA-256, UK model and certified dataset);
  • the uk extra's model and core pins, which must match the manifest;
  • the model wheel digest from PyPI, which must equal the manifest's;
  • the core wheel digest from PyPI;
  • the data release manifest from Hugging Face. It must certify the bundle's dataset digest; its SHA-256 and the dataset size come from it.
• Expected bundle. The expected release bundle is read from a scratch install with tokens removed. For a discovered request the receiver's bundle check therefore repeats that reading; the artifact digests are the independent part.
• Inconsistent releases. A release that cannot form a consistent request is logged and skipped, never queued half-built.
• Shared scripts. The workflow's state-branch checkout and enqueue steps move to .github/scripts/uk_replay_state.sh and uk_replay_enqueue.sh. The drain tolerates a state branch that so far exists only locally.

Verified

• Differential check. Rebuilt by provisional_request + expected_bundle for 6.2.6, the candidate block is identical to the request built by hand for Replay the five events on policyengine.py 6.2.6 and diff against the legacy run #164.
• End to end against a local bare origin, with the real scripts:
  • a wrong-dataset-digest request went queued → running → rejected (artifact_hash_mismatch);
  • a schema-invalid request went queued → running → rejected (schema_invalid);
  • each receipt was committed before its terminal STATUS.json, and the status names that exact commit;
  • a positive run of the valid 6.2.6 request through uk_replay_drain.sh, in a fresh environment, went queued → running → complete. Its integrity was complete; it diffed against the legacy run with the same flag counts as Replay the five events on policyengine.py 6.2.6 and diff against the legacy run #164 (304 numerical, 15 structural, 6 construction, 34 support); the receipt and results landed under requests/<id>/results/, and the terminal status named the receipt commit. All 111 artifact and progress files are byte-identical to the committed Replay the five events on policyengine.py 6.2.6 and diff against the legacy run #164 namespace (replay determinism across independent runs).
• Tests. tests/test_uk_replay_discover.py (9 tests):
  • a valid released_bundle request;
  • five inconsistency skips (model digest, dataset digest, dataset absent, missing pin, pin mismatch);
  • candidate selection: newer, unrequested and final only; property-tested ordering and floor;
  • per-run cap, and continuing past a skip.
• shellcheck is clean.

axiom: n/a: replay CI plumbing in scorecard, no policy encoding.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
policyengine-scorecard	Ready	Preview	Oct 11, 2026 8:21pm UTC