The self-hosted Actions runner is aarch64 (Apple M1 Linux); the CI toolchain
assumed x86_64, so every workflow has been failing at environment setup — on
main and every PR, not a code regression.
Two root causes, both arm64:
* pyrage==1.2.3 publishes no linux-aarch64 wheel, so uv fell back to an sdist
build and modern uv rejects pyrage's own pyproject.toml ("[project] without
project.version") — "TOML parse error at line 5". Bump to pyrage==1.2.4, the
first release shipping a cp39-abi3 manylinux_2_17_aarch64 wheel (x86_64 and
macOS wheels retained). No source build -> no parse error. Fixes smoke,
full-pytest, contemplation, ratify-proposal.
Verified: age/X25519 encrypt+decrypt round-trips on 1.2.4, and the committed
sealed-holdout artifacts (sealed under 1.2.3) still decrypt
(tests/test_holdout_encryption.py, tests/test_adr_0119_7_sealed_gsm8k.py —
7 passed). No ADR pins the patch version; only a size-tally doc referenced
it (updated).
* lane-shas used actions/setup-python@v5, which has no arm64 build for the
pinned 3.12.13 ("version '3.12.13' with architecture 'arm64' was not found"
-> "python: command not found"). Switch to astral-sh/setup-uv@v5 + uv (uv
provisions arm64 Python reliably), matching the other four workflows.
Files: pyproject.toml (pyrage 1.2.3->1.2.4), docs/model_dependency_size_tally.md,
.github/workflows/lane-shas.yml. uv.lock is gitignored (uv re-resolves per run).
Separate pre-existing issue (NOT addressed here): with setup fixed, lane-shas
now reaches its SHA check, where 2 demo lanes (demo_composition, public_demo)
drift from their pins. This is content drift on main, unrelated to the toolchain
(public_demo is a known wall-clock/env flake). Left for an explicit re-pin vs
degate decision rather than silently re-pinning.
* perf(tests): extract math_teaching_corpus lane from pytest into CI lane SHAs
The two slowest tests in the pytest suite were:
388s test_adr_0131_2_teaching_corpus_lane::test_report_is_byte_equal_across_runs
161s test_adr_0131_2_teaching_corpus_lane::test_lane_passes_exit_criterion
Both invoked build_report() from evals.math_teaching_corpus.v1.runner —
the canonical math-teaching-corpus lane runner — once for the exit
criterion and again for byte-equality. Together: 549s = 9m 9s, 30% of
the full pytest suite, recomputed on every developer run.
This is the exact 'lane runner invoked from pytest' anti-pattern that
the existing scripts/verify_lane_shas.py CI job is designed to absorb.
The other 7 lanes (reviewer_registry, miner_loop_closure, etc.) all
run in CI via SHA pinning rather than in pytest.
Changes:
scripts/verify_lane_shas.py — add math_teaching_corpus_v1 spec +
PINNED_SHAS entry (eaf160d145da29f9..., computed locally from
a clean run of the lane in this commit's tree).
scripts/generate_claims.py — add _LANE_ADR entry (ADR-0131) +
claim text. Failing fast on missing lanes is by design.
CLAIMS.md — regenerated; one new row.
tests/test_adr_0131_2_teaching_corpus_lane.py — delete TestLaneGate
class (2 tests, 549s). Retain TestDatasetIntegrity (5 tests),
TestBoundedDomain (2), TestHonestEvidence (1) — these are
fast (0.26s total) and pin contracts the lane runner does not
cover (dataset shape, lemma boundedness, evidence reachability).
Replace deletion with an explanatory comment block.
The deleted contracts are still enforced — just in CI instead of
pytest:
exit criterion → runner exit code (returns 1 on failure)
byte-equality → PINNED_SHAS verification (SHA-256 of report.json)
Verified locally:
scripts/verify_lane_shas.py — 8/8 lanes match pinned SHAs
pytest tests/test_adr_0131_2_teaching_corpus_lane.py — 8/8 pass in 0.26s
Expected full-suite delta: -549s (from ~30m to ~21m). Further speedup
will come from the upcoming full-pytest CI gate with pytest-xdist -n4.
* ci: bump lane-shas timeout 12m → 20m for new math_teaching_corpus lane
The math_teaching_corpus_v1 lane added in this PR runs in ~5-6 min,
pushing the total lane-shas job over the previous 12-min timeout.
First CI run cancelled at 12m17s. Bumping to 20m gives ~8m headroom.
* fix(ci): bump lane subprocess timeout 300s→900s + add math_teaching_corpus to test_lane_sha_verifier EXPECTED_LANES
Two issues surfaced by CI run on the prior commit:
1. The math_teaching_corpus lane takes ~142s wall-clock locally (3.79
cores × ~538s CPU). On CI's single/dual-core runner that translates
to ~5-9 min, exceeding the 300s subprocess timeout in
scripts/verify_lane_shas.py. Bumping to 900s gives ~60% headroom.
2. tests/test_lane_sha_verifier.py::TestExpectedLaneCoverage::test_all_expected_lanes_covered
hardcodes the expected lane set. Adding math_teaching_corpus_v1 to
LANE_SPECS triggered the 'extra lanes' assertion. Adding it to
EXPECTED_LANES (the file's own contract: 'if intentional, add here').
CLAIMS.md is now mechanically derived from two ground-truth sources:
- core.capability.ledger_report (Tier 1: ratified domains)
- scripts/verify_lane_shas.PINNED_SHAS (Tier 2: pinned lane reports)
The generator is deterministic and gated by
tests/test_claims_md_is_current.py + the lane-shas CI workflow's new
'verify CLAIMS.md is current' step. Drift between in-tree state and
the published claims fails CI before merge.
Tier 1 (5 ratified domains) and Tier 2 (6 pinned lanes) cover every
ADR-0092..0102 invariant currently CI-pinned.
Six lanes (reviewer_registry, miner_loop_closure,
domain_contract_validation, fabrication_control_summary,
demo_composition, public_demo) now have CI-enforced SHA-256 pins.
A failing job means a lane's deterministic output changed without
an explicit ADR-tracked pin update.
- new scripts/verify_lane_shas.py: single source of truth
- PINNED_SHAS dict mapping lane_id → 64-char hex SHA
- LANE_SPECS tuple wiring each lane to its runner module + canonical
report path
- accepts_report_flag handles the fabrication_control runner's
different arg shape (--lane-dir not --report)
- verify_all() runs each lane in subprocess isolation (clean Python
state per lane — relevant for adapters that cache pack loads at
module import)
- --update flag refreshes pins after intentional ADR-tracked changes;
diff is the audit trail
- --json flag emits machine-readable report
- exits non-zero on any mismatch
- new .github/workflows/lane-shas.yml:
- triggers on push to main and pull_request to main
- concurrency group cancels in-progress runs on new commits
- Python 3.11 + pip-cached deps + editable install
- runs verify_lane_shas.py; emits JSON report on failure
- 12-minute timeout (lanes take ~30s in practice)
- new tests/test_lane_sha_verifier.py: cheap local-pytest pinning
- every LaneSpec has a corresponding PINNED_SHAS entry
- no orphan pins without a LaneSpec
- every pin is a 64-char hex SHA-256
- every runner module path exists on disk
- canonical report paths are under repo root
- all six expected lanes (ADR-0092/0093/0095/0096/0098/0099) covered;
ADR-0094 and ADR-0097 are schema/ratification only, intentionally
excluded from EXPECTED_LANES
- 6 tests run in <100ms — catches drift before CI
- evals/public_demo/results/v1_dev.json: refreshed to match the new
pin (21751aaf..) — earlier pin was generated under slightly different
runner argparse defaults; --update produced the canonical bytes
Local verifier: 6/6 lanes match pinned SHAs. Smoke 67/67. Lane SHAs:
reviewer_registry 681a2aab..
miner_loop_closure 9f071733..
domain_contract_validation f9c06cde..
fabrication_control_summary 01e1b6b7..
demo_composition 27d83824..
public_demo 21751aaf..
