Repository navigation
Conversation
…since APR-MONO
ALD-002 should be valid: "Failed to read ../../examples/ald/data_table_virtualized.yaml:
No such file or directory (os error 2)"
Every row in tests/examples.rs (27) and tests/prs_examples.rs (7) failed, all on
one cause. The examples are in the SIBLING crate,
crates/aprender-present/examples/{ald,apr,charts,dashboards,edge_cases,prs}/.
examples.rs `Path::new("../../examples/...")` -- two levels up from
crates/aprender-present-yaml/ is the repository ROOT, and CWD
is whatever the runner chose. Both wrong.
prs_examples.rs already anchored on CARGO_MANIFEST_DIR and then walked
`.parent().parent().join("examples").join("prs")` -- to the
same repository root. The CWD-independence was right and the
DESTINATION was wrong, which is why it looks deliberate.
`CARGO_MANIFEST_DIR` + `../aprender-present/examples` rather than a corrected
`../`: it resolves at COMPILE time against the crate being built, so no working
directory can break it and it survives the next move. One helper per file, 27 + 3
call sites.
Proved: pointing the helper back at `../../examples` turns all 27 rows red again;
restoring it turns them green. aprender-present-yaml now 205 lib + 27 + 17 + 7
pass, clippy -D warnings clean.
HOW THIS WAS FOUND, because it is the more useful half. Nothing in this repo runs
integration targets: ci.yml's workspace-test is `--workspace --lib` plus one
explicit `--test` list, and `make coverage` -- the only other full run -- is also
`--lib`. So I ran the whole surface once, on this box:
cargo nextest run --workspace --lib --tests --no-fail-fast
(GPU crates excluded, as the full tier excludes them)
Summary [1141.178s] 98621 tests run: 98584 passed, 37 failed, 329 skipped
19 minutes, and about 18,000 tests that CI has never executed. The 37 failures
are FIVE binaries, not a swamp:
aprender-present-yaml::examples 27 <- this commit
aprender-present-yaml::prs_examples 7 <- this commit
apr-format::golden_fixtures 1 <- #3248
aprender-mcp::falsify_mcp_008 1 <- #3238
aprender-cgp::falsify (doctor_speed_real) 1 <- open
That reframes #3239: the dark surface is cheap to run and has three distinct
defects left, two of which are already in flight.
Not wired here. ci.yml's --test chain is held by #3245 and #3248 this cycle and
only one PR may edit that line; a third would conflict with both. The wiring for
these two targets goes in after they land.
Pmat-Ticket: PMAT-1098
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
noahgift
added a commit
that referenced
this pull request
Sep 14, 2026
Written before the PR was opened, so it cited the number this document then got. The three PRs that take the failing set from 37 to 1 are #3248 (golden_v2), #3250 (present-yaml paths) and #3238 (mcp contract copy). Pmat-Ticket: PMAT-1098 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
noahgift
enabled auto-merge
September 14, 2026 07:23
|
§13.11 rung 1 — quorum shadow verdict Shadow mode: this records a verdict and merges nothing. A refusal |
noahgift
added a commit
that referenced
this pull request
Sep 14, 2026
… it was right on three counts All four agy lanes (3 plan + 1 teamwork) refused the draft. Three findings stand and the spec is revised rather than defended. 1. THE RATCHET HAD NO WRITER. The draft proposed shrink-only, tightening to hard-fail. Three lanes refused it independently and the defect is mechanical, not stylistic: `--update` writes a file and needs a commit, and a scheduled workflow has no PR and no author. Every other ratchet here (unwired_guards, pipe_grep_q, shell_lint) is updated by a human inside a PR BECAUSE it runs in one. A nightly's baseline would only ever be edited by someone who already noticed the job was red -- the exact population the ratchet exists to stop relying on. So: land #3250/#3248/#3238, gate doctor_speed_real, ship hard-failing on day one. The exit condition was already ONE test when the draft was written; there was never an interval in which a ratchet carried information. Fallback if the gating stalls: ONE named exclusion with its issue number, auditable in a line. 2. THE 39 GB TARGET DIR WAS UNBUDGETED. Unanimous, and the draft did not mention it once -- on the same day I spent an hour taking gx10 from 0 bytes free after it dequeued a PR from merge-queue position 1 (#3247). New §4bis makes it a constraint: not on gx10 (916 GB, the box that hit the wall), a per-run target dir reclaimed in-job rather than left to a reaper that already cannot reclaim under keep=3, and a preflight free-space assertion that fails ENV: instead of letting cargo die half-way and read as 650 new defects. 3. THE REVISIT CONDITION WAS WRONG. I keyed it on queue depth vs max_entries_to_build; lane 3 pointed out that is a CAP, not a measure of slack -- a queue can sit at depth 3 with idle capacity. Keyed on arrival rate vs drain rate instead. Also sharpened, from a measurement all lanes converged on: T-1 does not "add the full surface", it must BUILD `ci / deep`. That job has 0 hits in every workflow including the SHA-pinned upstream sovereign-ci.yml, and its other named parts run nowhere either -- `cargo test --doc` 0, `cargo run --example` 0, feature matrix 0, `--no-default-features` 1 hit that is a Windows BUILD flag. And the fast-pool pin leaves this spec entirely (§8bis). All four lanes rejected it with a computable break-even rather than a caveat: `runs-on` is a hard label filter with no fallback, so a pin is non-work-conserving and is a NET LOSS whenever fast-pool wait exceeds the ~18-22 min runtime delta -- which is the condition that holds exactly when the latency mattered. The asymmetry is real (#3251); the actuator is wrong. Lane 4 was briefed as /teamwork but agy 1.2.2 ran ZERO invoke_subagent calls and created no teamwork_projects dir (PMAT-126 reproduced). It is one model answering once and is not counted as a team review anywhere in this document. Refs #3239, #3251 Pmat-Ticket: PMAT-1098 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Member
Author
|
Superseded by #3295, which carries this change unmodified along with eight other Not abandoned and not rejected: the commits are merged into Why: a successful |
Merged
guyernest
pushed a commit
to guyernest/aprender
that referenced
this pull request
Sep 29, 2026
paiml#3253 paiml#3257 paiml#3267 paiml#3272 paiml#3285 paiml#3288 paiml#3289 paiml#3290) (paiml#3295) * fix(present-yaml): 34 example tests read a path nothing has lived at since APR-MONO ALD-002 should be valid: "Failed to read ../../examples/ald/data_table_virtualized.yaml: No such file or directory (os error 2)" Every row in tests/examples.rs (27) and tests/prs_examples.rs (7) failed, all on one cause. The examples are in the SIBLING crate, crates/aprender-present/examples/{ald,apr,charts,dashboards,edge_cases,prs}/. examples.rs `Path::new("../../examples/...")` -- two levels up from crates/aprender-present-yaml/ is the repository ROOT, and CWD is whatever the runner chose. Both wrong. prs_examples.rs already anchored on CARGO_MANIFEST_DIR and then walked `.parent().parent().join("examples").join("prs")` -- to the same repository root. The CWD-independence was right and the DESTINATION was wrong, which is why it looks deliberate. `CARGO_MANIFEST_DIR` + `../aprender-present/examples` rather than a corrected `../`: it resolves at COMPILE time against the crate being built, so no working directory can break it and it survives the next move. One helper per file, 27 + 3 call sites. Proved: pointing the helper back at `../../examples` turns all 27 rows red again; restoring it turns them green. aprender-present-yaml now 205 lib + 27 + 17 + 7 pass, clippy -D warnings clean. HOW THIS WAS FOUND, because it is the more useful half. Nothing in this repo runs integration targets: ci.yml's workspace-test is `--workspace --lib` plus one explicit `--test` list, and `make coverage` -- the only other full run -- is also `--lib`. So I ran the whole surface once, on this box: cargo nextest run --workspace --lib --tests --no-fail-fast (GPU crates excluded, as the full tier excludes them) Summary [1141.178s] 98621 tests run: 98584 passed, 37 failed, 329 skipped 19 minutes, and about 18,000 tests that CI has never executed. The 37 failures are FIVE binaries, not a swamp: aprender-present-yaml::examples 27 <- this commit aprender-present-yaml::prs_examples 7 <- this commit apr-format::golden_fixtures 1 <- paiml#3248 aprender-mcp::falsify_mcp_008 1 <- paiml#3238 aprender-cgp::falsify (doctor_speed_real) 1 <- open That reframes paiml#3239: the dark surface is cheap to run and has three distinct defects left, two of which are already in flight. Not wired here. ci.yml's --test chain is held by paiml#3245 and paiml#3248 this cycle and only one PR may edit that line; a third would conflict with both. The wiring for these two targets goes in after they land. Pmat-Ticket: PMAT-1098 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(cgp): six wall-clock assertions, three of them in the REQUIRED check FALSIFY-CGP-061 FAILED: doctor took 2665ms Measured during a full `--lib --tests` sweep of the workspace — the box was running 98,621 tests in parallel. 2665 against a 2500 ms limit is a 6.6% miss that says nothing about `cgp doctor` and everything about the load. It is the LAST of the 37 failures that sweep found, and the one blocking paiml#3249's hard-failing nightly. Raising the limit is the "clever ratio rewrite" that once blocked all nine open PRs. The fix is to stop asserting duration where duration cannot be measured. FIXED ONE, FOUND SIX. The test that failed was the entry point, not the scope: tests/falsify.rs:457 doctor < 2500 ms <- the one that failed tests/falsify.rs:583 profile < 31 s <- same file, simply not unlucky yet tests/integration.rs:39 doctor < 30 s src/doctor.rs:406 checks < 2 s } src/analysis/diff.rs:344 < 100 ms } IN src/ -- these are #[cfg(test)] src/metrics/export.rs:70 < 100 ms } units, so they run in --workspace } --lib: the REQUIRED workspace-test, } on every PR and every merge group A 100 ms assertion on a shared runner is a coin flip, and two of them have been sitting in a required check. `scripts/check_no_timing_in_required.sh` exists for exactly this — its header says "policy is what failed the other eleven times" — but its registry covers `check_*.sh` GUARDS. It has never been able to see a Rust target, so nobody has ever counted these. `timing-gate`, off by default, is that registry for Rust: nothing enables it, so a timing row cannot reach a required check by accident. Arm it where duration is measurable — a dedicated unloaded runner at release time — not in CI's default set and not in paiml#3249's nightly full surface. GATED, NOT DELETED, proved by mutation rather than asserted: limit -> 0, WITH --features timing-gate FAILED (1 failed) the assertion is live limit -> 0, WITHOUT the feature ok compiled out restored ok Also in CGP-061, a second defect in the same row: assert!(stdout.contains("RTX 4090") || stdout.contains("GPU")); That asserts the RUNNER's hardware — the class fixed in paiml#3210 across four sibling rows — and passes here only because this box happens to have a 4090. What CGP-061 owes is that `doctor` reached a VERDICT about the device and printed it, so that is what it now asserts: non-empty output, and a decision among GPU/CUDA/device/no GPU/not available. aprender-cgp: 121 lib + 3 falsify pass, clippy -D warnings clean. Not fixed here, filed separately: the same regex over the workspace finds ~70 duration assertions in `crates/*/src/` and 36 more in `crates/*/tests/`, across 12 crates. This commit fixes the one crate that actually failed. Refs paiml#3239 Pmat-Ticket: PMAT-1098 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(distribute): tokio behind an optional feature, used unconditionally — 43 errors under --no-default-features cargo check --workspace --no-default-features error[E0433]: failed to resolve: use of unresolved module or unlinked crate `tokio` ... 43 errors, every one in aprender-distribute Found while measuring what APR-RELEASE-001 T-1's `ci / deep` would actually cost. T-1 names `--no-default-features` as one of its clauses, and that clause has never run in CI: `grep -rc no-default-features .github/workflows/*.yml` finds ONE hit and it is a Windows BUILD flag in nightly.yml. paiml#3176 is the standing ticket. `default = ["cpu"]` and `cpu = ["tokio", "num_cpus"]`, so --no-default-features drops tokio while the source still names it in four files. TOKIO, NOT `cpu`, AND THAT IS A DELIBERATE DEPARTURE FROM THE TICKET. paiml#3176 says "the fix is `#[cfg(feature = "cpu")]` on the affected modules ... not adding tokio as a hard dependency". The second half is right and is followed. The first half is not quite: `cpu` is only one of SIX features that pull tokio in — `cpu`, `remote`, `checkpoint`, `tui`, `serverless`, `microvm`. Gating on `cpu` would leave `--no-default-features --features remote` with tokio PRESENT and the modules that need it compiled OUT: one broken configuration traded for another. Cargo creates an implicit `tokio` feature for an optional dependency, and it is true exactly when some feature brought tokio in. That is the predicate the code actually depends on, so that is the gate. What is gated, and why each: executor::cpu the ONLY executor module that was not already feature-gated, and the one needing tokio::process::Command / AsyncReadExt / timeout. Its five siblings (gpu, microvm, remote, tls, simd) are all gated; this makes it consistent rather than special. messaging tokio throughout scheduler tokio throughout Pool, PoolBuilder and their impls, and the imports they need the crate's high-level API is async to its core -- tokio::sync::RwLock, tokio::task::JoinSet, tokio::time::sleep, and a CpuExecutor that spawns processes through tokio. There is no meaningful tokio-free Pool to preserve, so the whole surface is gated with the runtime it requires rather than half-gated into something that compiles and cannot run. Verified in every direction, because a gate that breaks the normal path is worse than the defect: cargo check -p aprender-distribute --no-default-features 0 errors (was 43) cargo check -p aprender-distribute 0 errors cargo check -p aprender-distribute --all-features 0 errors cargo test -p aprender-distribute --lib 84 passed clippy -D warnings, all three feature sets 0 errors cargo check --workspace --no-default-features 0 errors <- the T-1 clause Load-bearing, proved by mutation rather than asserted: removing the gate on `executor::cpu` alone puts --no-default-features back to 10 errors; restoring it returns 0. Closes paiml#3176 Pmat-Ticket: PMAT-1098 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(zram): the cuda feature says why it cannot build, instead of a cascade (paiml#3179) `--features cuda` has not compiled since APR-MONO. Three gaps, each verified by reading the tree rather than inferred: 1. `trueno_gpu::driver::PinnedBuffer` and `GpuBuffer::copy_{from,to}_pinned_async` do not exist and never did in this monorepo — `git log -S PinnedBuffer -- crates/aprender-gpu/` is empty. Only synchronous pageable copies exist. 2. src/gpu/batch/mod.rs:610 launches the entry point `lz4_compress_warp_shuffle` with 32 threads and `shared_mem: 0`. No kernel of that name exists. The one that does, `lz4_compress_warp`, is documented as 128 threads per block with shared memory. 3. `Lz4WarpDecompressKernel::build_ptx` is a STUB whose entire body is `ctx.label("L_exit")`. There is no GPU LZ4 decompressor in this workspace. So this is not one API away from working: it is wired to a kernel ABI removed at consolidation, and its decompressor does not exist. DECIDED BY QUORUM, two rounds. Round 1 (3 agy lanes) voted 2/3 to rewrite the path on the pageable API so it would compile. Facts 1-3 above were verified AFTER that vote, so round 2 put them to three fresh lanes: all three overturned round 1, unanimous that making a dead path compile to turn a matrix cell green is theater. Round 2 split 2/1 between deleting the path and this option. I took the minority option and the reason is a fact neither deleting lane had: this crate's DEFAULT build is green, and `gpu/batch` is live, compiling, public API that `gpu/hybrid.rs` uses. Only the cuda-gated arms are dead. Both deleting lanes argued from "a dark, unused feature"; the module is neither. Deleting it would remove live public types (`GpuBatchCompressor`, `BatchResult`, `BatchDecompressResult`, `GpuBatchConfig`) for no gain, which neither lane actually argued for. One of them said outright that this option "best serves someone who later wants to finish the GPU path". So: one `compile_error!` naming all three gaps, with the real gate moved to a private `__cuda-linked` feature (13+2 sites in batch/mod.rs, 7 in hybrid.rs) so the refusal is the ONLY diagnostic and nothing is deleted. This is the same shape already used in this tree for aprender-simulate's `z3-proofs` and aprender-core's `showcase-profile`. `--features cuda` now prints one named error instead of an unresolved-import cascade; the two selections stay RED in the nightly matrix, but red WITH A REASON, which is the honest state until a real decompress kernel exists. Default builds of both crates are clean, aprender-zram-core --lib is 411/411, and clippy is clean. Refs paiml#3179, paiml#3262 Pmat-Ticket: PMAT-1098 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(guard): the roadmap guard counted agy lane scratch as a second copy of the tree `make gate` went red on a clean branch with 1107 "NEW unprovable claims", every one of them pointing at an innocent roadmap row. The claims were real rows — read twice. `.claude/worktrees/` is agy's throwaway lane workspace: a full checkout, roadmap.yaml included, created per review lane and left behind when a lane dies. It is in `.git/info/exclude`, so nothing under it can ever reach the tree CI gates. But this guard's universe deliberately includes UNTRACKED files — that is the hole it was written to close (paiml#2512, an untracked file is exactly how a new uncited claim arrives) — so it walked straight into the lane checkouts and counted every entry twice. The arithmetic says it plainly: completed claims 2266 before, 1133 after. Exactly half. Universe 46 roadmap files before, 23 after. NEW 1107 -> 0. check_complexity_ratchet.sh:149 already prunes `*/.claude/worktrees/*`. That lesson was paid for once and never propagated; this guard is the second place it was needed. The prune is applied in `is_candidate` rather than only in the walk, so the `git ls-files` half of the universe is covered by the same rule, and the walk skips descending into what was measured as 66 registered lane worktrees. This does not widen any hole: a path under `.claude/worktrees/` is in `.git/info/exclude` and cannot be committed, so it can never be part of the tree this guard gates. Case-table row ships with the fix: a fixture roadmap planted at `.claude/worktrees/lane-deadbeef/docs/roadmaps/roadmap.yaml` with a completed-and-uncited entry must contribute 0 records. It reads `want 0 got 1` without the prune. Pmat-Ticket: PMAT-3226 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(nightly): guards-nightly has been RED naming a step that runs every night — the matcher cannot see a YAML-quoted name Five scheduled lanes are red. This is the one whose cause is entirely inside the guard rather than in the thing it guards. FAIL: manifest names a step this workflow does not run: Test-tier decision case table (BSE-17): quick/full/reuse, drift is ENV The step is there. guards-nightly.yml line 158: - name: "Test-tier decision case table (BSE-17): quick/full/reuse, drift is ENV" The inline check matched the BARE spelling: grep -Fq -- "- name: $name" .github/workflows/guards-nightly.yml A step name containing a colon-space MUST be quoted in YAML, and this one contains `(BSE-17): quick`. So the matcher looked for `- name: Test-tier...` while the file said `- name: "Test-tier...`, and the lane has been red ever since that name was quoted — reporting a step that runs on every nightly as one the workflow does not run. A guard that names a real step as missing is worse than no guard: it teaches the reader to skip the lane. EXTRACTED rather than patched in place. Logic inside a `run:` block cannot be unit-tested and cannot carry a case table, which is why a one-character class of defect survived in it. scripts/check_guards_nightly_manifest.sh now matches on the PARSED name, so all three YAML quotings of one string are one step. Case table, 7 rows, both directions: bare name parsed ok DOUBLE-quoted name unquoted (the defect) ok single-quoted name unquoted ok trailing whitespace stripped ok manifest fully covered -> exit 0 a genuinely absent step -> exit 1 <- still fails; not made permissive vacuity floor, <5 entries parsed -> exit 1 Against the real tree: `ok 7 manifest entries, every one a step in this workflow`. Mutation: appending one bogus entry turns it RED again, so the fix widened the matcher without disarming it. The self-test found a defect in its OWN HARNESS first: invoking `step_names` through `bash -c 'source ...'` re-ran this file's dispatch and returned nothing, so four rows failed while the parser was correct. A broken harness reporting a working parser as broken is the same error as the one being fixed, in the other direction. Wiring: `guard_tree.sh --dry-run` reports it `wired-elsewhere guards-nightly.yml` and check_guards_are_wired.sh exits 0. bashrs 7.4.1: 0 errors. check_roadmap_sorted.sh caught the roadmap entry inserted at a stale slot — main gained PMAT-3228/3229 while this branch was being written, so "after 3222" was no longer sorted. Re-inserted among its numeric peers. ont-delta: none — a CI guard fix; it adds no entity, shape, verdict reason or resolves target of its own. Pmat-Ticket: PMAT-3234 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(examples): an example built WITHOUT its feature is not a broken example — needs-feature examples-nightly is one of five red scheduled lanes. Its verdict is currently not a trustworthy signal about whether examples work, which is the exact property APR-RELEASE-001 §4.2 and T-1 want to depend on. Run 34826552378, 980 example targets: summary pass=602 fail=22 timeout=6 needs-args=30 needs-hardware=2 needs-data=318 The 28 fail+timeout rows, classified by what the output actually says: 6 the example is not built with the feature it needs <- NOT broken 2 needs a network peer (192.168.50.100:9000) <- NOT broken 1 needs a TTY ("No such device or address") <- NOT broken 6 timeout at 180 s (buggy_server, brick_computer ...) <- servers by design? 13 remainder So a quarter of the lane's red is a MISSING LABEL, not a defect. This commit takes the 6: aprender-db::compressed_kv This example requires the 'compression' feature. aprender-rag::compressed_index This example requires the 'compression' feature. aprender-rag::semantic_embeddings This example requires the 'embeddings' feature. aprender-distribute::tensor_example Error: This example requires the 'tensor' feature. ... and cargo's own refusal, which says it differently: target `gpu_info` in package `aprender-zram-core` requires the features: cuda This follows the precedent this file set for `needs-data` on 2026-09-12 (173 rows), and obeys the rule its own header states: "one turns a real defect into a skip, so each addition belongs in the selftest." LIKE needs-hardware, NOT like needs-args. A needs-feature row is a SKIP that must be re-run WITH the feature before a release verdict. A green lane on a default-feature host must never be readable as "the compression example works" — which is why the row cites the line that classified it. THE REGEX SHIPS BOTH POLARITIES, because a skip class can only ever turn a `fail` into a non-failure: MUST match This example requires the 'compression' feature. Error: This example requires the 'tensor' feature. ... requires the features: cuda MUST NOT match thread 'main' panicked at src/main.rs:11:39 error[E0432]: unresolved import `trueno_gpu::driver::PinnedBuffer` Error: Os { code: 6, kind: Uncategorized } assertion failed: left == right feature is required for this operation <- the deciding near-miss Mutation, both directions: regex matching nothing -> selftest RED regex widened to "feature" -> selftest RED shipped regex -> green The harness caught its own staleness too: a completeness assertion hardcoded "one of the six classes" and went red on the seventh. Updated rather than widened — the assertion is what stops a row being written with no class at all. NOT touched here, because they are separate causes and deserve their own triage: the 2 network rows, the 1 TTY row, the 6 timeouts, and the 13 remaining. One of those 13, `aprender-zram-core::gpu_info`, is already owned by paiml#3267 — which found that `trueno_gpu::driver::PinnedBuffer` "does not exist and never did in this monorepo". bashrs 7.4.1: 0 errors. selftest: all rows passed. ont-delta: none — a classification fix in a CI harness; it adds no entity, shape, verdict reason or resolves target of its own. Pmat-Ticket: PMAT-3235 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(silicon): a vanished dep-info file was reported as a SIMD failure — the classifier existed and this lane did not call it Silicon Nightly is red. Its failing step is named SIMD and numeric paths (x86_64, widest vectors) which, on an ML framework, reads as arch-specific numerical incorrectness. It is not. 3511 tests passed; the job died afterwards on: error: could not parse/generate dep info at: .../target/release/deps/arrow_ipc-b83c0a68418506db.d A dep-info file vanished while cargo was writing it. That is a HOST fault, it is already classified, and it is already fixture-tested in this repository: paiml#3241 built scripts/cargo_step.sh for precisely this, after mdBook CI reported the same error as "a book that does not build". Its case table carries the row W2 dep-info ENOENT is ENV MEASURED COVERAGE OF THAT CLASSIFIER, main @ a0634f7: cargo invocation lines across all workflows 75 routed through cargo_step.sh 5 (book.yml, and only book.yml) So the instrument covers 7% of the surface, and the lane that just died is in the other 93%. `scripts/cargo_classify.sh` has said ENV-or-CODE since paiml#2712/paiml#2822 and six check_*.sh guards source it; a cargo command running as a BARE workflow step has no arm at all. That is the shape paiml#3241's own header describes, fixed for one lane rather than for the class. This routes both legs of silicon-nightly — x86_64-cpu and aarch64-cuda-sm121, four cargo invocations — through it, and adds the self-test caller to each job first, because a classifier nothing proves is the same theater as no classifier (book.yml's pattern, and what check_guards_are_wired.sh requires of any script shipping a --self-test). IT DOES NOT MAKE THE LANE GREEN, and must not. cargo_step.sh's own contract: "ENV still exits NON-ZERO -- a gate that goes green on 'we could not measure' is the defect it exists to name." What changes is the CLAIM: a host fault stops reading as a SIMD defect, so nobody spends a morning on AVX-512 correctness because a file disappeared. A defect I introduced and caught before pushing, worth recording because the fix looked right: the first pass used a naive string replace, and the SECOND replacement matched the continuation line INSIDE the wrapper the first had just created — double-wrapping the x86_64 leg while leaving aarch64 raw. Redone by line position. The job-name derivation was wrong too, labelling the x86_64 steps `coverage:` (a real sibling job in this file), corrected after checking which job each line actually sits in rather than trusting the first answer. Guards: check_workflow_cargo_packages.sh 0, check_workflow_env_defined.sh 0, cargo_step.sh --self-test 0. YAML parses, 4 jobs. The other four red nightlies are separate causes: guards-nightly (paiml#3285), examples-nightly (paiml#3288), Coverage Nightly, CUDA Nightly (PP-26). ont-delta: none — a CI classification fix; it adds no entity, shape, verdict reason or resolves target of its own. Pmat-Ticket: PMAT-3236 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(zram): a same-process ratio is load-immune but NOT instrumentation-immune Coverage Nightly has been red every night. paiml#3227 fixed the test it was named for (a lock in apr_serve_tests.rs) and landed 02:19Z; the 08:18Z run on a1a19c4 — which CONTAINS that fix — failed on a different one: thread 'benchmark::tests::test_decompression_faster_than_compression' panicked at crates/aprender-zram-core/src/benchmark.rs:522:9 test result: FAILED. 403 passed; 1 failed WHY THE OBVIOUS DEFENCE DID NOT WORK. This test is ALREADY a same-process ratio, which is the shape its neighbour test_f058_entropy_overhead_minimal was rewritten into and which that comment explains: "load-immune because both measurements are taken in the same process, microseconds apart, under whatever load exists". Load-immune is not instrumentation-immune, and they are different axes. `cargo llvm-cov`'s overhead scales with the number of instrumented branches EXECUTED, and the compress and decompress paths do not execute the same number. So under coverage this ratio measures instrumentation density, not the algorithm — no amount of same-process-ness helps, because the distortion is not noise, it is systematic and asymmetric. The ratio had already been widened once for exactly this reason ("In debug builds with coverage instrumentation, decompression may be slower", 0.25) and the lane failed on it anyway. Widening again is the treadmill f058's own comment names: "the number it measures is how loaded the machine is." SO: assert where the number means something, report where it does not. #[cfg(coverage)] print the two rates; assert only that BOTH paths produced a rate, which stays true under instrumentation and still catches a zero #[cfg(not(coverage))] the 0.25 ratio, unchanged `cargo llvm-cov` compiles with `--cfg=coverage` — verified, not assumed: $ cargo llvm-cov show-env __CARGO_LLVM_COV_RUSTC_WRAPPER_RUSTFLAGS='-Cinstrument-coverage--cfg=coverage' so this is a compile-time split, not a runtime guess at whether we are instrumented. PROVEN, because a passing test does not say which branch ran: without the cfg 0 "informational" lines -> the ASSERT branch ran with --cfg=coverage 1 "informational" line -> the REPORT branch ran mutation 0.25 -> 1000.0, no cfg -> FAILED The third row is the one that matters: the assertion is still load-bearing where it is kept, so this narrows the claim rather than deleting the test. This is the third pattern in this file, beside f058's ratio rewrite and F053's report-don't-assert, and the distinction between them is the finding: f058 defends against LOAD, F053 gives up on an ABSOLUTE bound, and this one gives up on a RATIO only where the instrument distorts it. fmt clean, clippy -D warnings 0 errors, roadmap additive (reserialised=0). ont-delta: none — a test-assertion fix; it adds no entity, shape, verdict reason or resolves target of its own. Pmat-Ticket: PMAT-3237 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(roadmap): collapse my insertion's stray blank line (roadmap_trim.py) Third time tonight. My insertion helper rejoins entry blocks with an added newline, re-serialising the entry ABOVE the insertion without any field changing — PMAT-980 (#2874). The remedy is the one check_roadmap_diff_additive.sh names. Pmat-Ticket: PMAT-3234 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(roadmap): collapse my insertion's stray blank line (roadmap_trim.py) Third time tonight. My insertion helper rejoins entry blocks with an added newline, re-serialising the entry ABOVE the insertion without any field changing — PMAT-980 (#2874). The remedy is the one check_roadmap_diff_additive.sh names. Pmat-Ticket: PMAT-3235 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(roadmap): collapse my insertion's stray blank line (roadmap_trim.py) Third time tonight. My insertion helper rejoins entry blocks with an added newline, re-serialising the entry ABOVE the insertion without any field changing — PMAT-980 (#2874). The remedy is the one check_roadmap_diff_additive.sh names. Pmat-Ticket: PMAT-3236 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * batch-1: collapse the 9-way roadmap re-serialisation (roadmap_trim.py) Pmat-Ticket: PMAT-3231 * batch-1: PMAT-3226 to its sorted slot — a textual merge cannot insert semantically Nine branches each inserted their roadmap entry at the correct slot RELATIVE TO MAIN AT THE TIME. main then gained PMAT-3228 and PMAT-3229, so merging paiml#3272 placed PMAT-3226 after them by textual context: 3222, 3228, 3229, 3226. check_roadmap_sorted.sh is RED on the merged tree and GREEN on all nine branches individually. This is the class of defect a batch surfaces and per-PR CI cannot: each input is sorted, the union is not. Pmat-Ticket: PMAT-3231 --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
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.
Every row in
tests/examples.rs(27) andtests/prs_examples.rs(7) failed, all on one cause.The examples are in the sibling crate,
crates/aprender-present/examples/{ald,apr,charts,dashboards,edge_cases,prs}/.examples.rsPath::new("../../examples/…")— two levels up fromcrates/aprender-present-yaml/is the repository root, and CWD is whatever the runner chose. Both wrong.prs_examples.rsCARGO_MANIFEST_DIR, then walked.parent().parent().join("examples").join("prs")— to the same repository root. The CWD-independence was right and the destination was wrong, which is why it reads as deliberate.CARGO_MANIFEST_DIR+../aprender-present/examplesrather than a corrected../: it resolvesat compile time against the crate being built, so no working directory can break it and it
survives the next move. One helper per file, 27 + 3 call sites.
Proved: pointing the helper back at
../../examplesturns all 27 rows red again; restoring itturns them green.
aprender-present-yamlnow 205 lib + 27 + 17 + 7 pass,clippy -D warningsclean.
How this was found — the more useful half
Nothing in this repo runs integration targets:
ci.yml'sworkspace-testis--workspace --libplus one explicit
--testlist, andmake coverage— the only other full run — is also--lib. So I ran the whole surface once:19 minutes, and ~16,000 tests across 654 binaries that CI has never linked. The 37 failures
are five binaries, not a swamp:
The cadence decision that follows from it is #3249.
Not wired here
ci.yml's--testchain is held by #3245 and #3248 this cycle and only one PR may edit thatline; a third would conflict with both. The wiring for these two targets goes in after they land
— and the wiring must land with a fix, never before it, or main goes red the moment it merges.
Refs #3239
no-close: #3239 stays OPEN — this fixes 34 of its 37 measured failures; the tiering decision it
describes is #3249's.
🤖 Generated with Claude Code