ci(night): the two T-1 clauses too slow for a lane anyone waits on — examples RUN and the 430-pair feature matrix

[noahgift]

What

The two APR-RELEASE-001 T-1 clauses that are too slow for a lane anyone waits on. Operator ruling 2026-09-14 — "wouldn't they be best done pre-release and/or night?" — yes.

#3260 (deep.yml) carries the three cheap T-1 clauses: doctests (192 s), --no-default-features (26 s), examples BUILD (83 s). These two are hours:

job	scope	measured
examples-run	980 example targets	~2 h
feature-matrix	430 (crate, feature) pairs over 45 crates	~1–2 h

Runs at 22:40 UTC, clear of every other nightly (the earliest is cuda at 01:30), plus workflow_dispatch for pre-release.

Timeout is a PASS, and that is the whole design

Measured on a random sample of five examples with -- --help and a 60 s cap:

HANG     aprender-core::grid_search_tuning
HANG     aprender-serve::imp_700_realworld_verification
exit101  aprender-serve::debug_q4k_gemv
ok       aprender-simulate::reproducibility
HANG     aprender-serve::bench_barrier_overhead

Three of five ran past it. They are not CLIs — they are compute demos that ignore argv and do the work, so "hang" is the wrong word: they are RUNNING. Treating a timeout as failure would report a working example as broken, 980 times.

So the job asserts what is actually owed: every example starts and does not crash. That catches the #2519 class (an example that panics immediately) without asserting a duration — which check_no_timing_in_required.sh exists to forbid.

Known red, dated and sourced

The first full sweep (#3262) measured 100 of 430 pairs red, every one unreachable from any default set. #3263 fixes 67. The remaining 9 are owned elsewhere:

• seven aprender-distribute selections → fix(distribute): tokio behind an optional feature, used unconditionally — 43 errors under --no-default-features #3257. Its feature = "tokio" gate is right but not sufficient: executor/cpu.rs also uses num_cpus, which only the cpu feature pulls. Verified against that PR's head — all seven fail on num_cpus, and the other 17 selections are green.
• two cuda selections → aprender-zram-core's cuda feature has never compiled: unresolved trueno_gpu imports in library code, dark since before v0.66.0 #3179. PinnedBuffer plus GpuBuffer::copy_{from,to}_pinned_async do not exist post-APR-MONO.

Those 9 are reported, not fatal, so this lane can be GREEN on its first run rather than born red and taught to be ignored. A listed pair that passes is FATAL — the list may only shrink, and it shrinks by deleting a line. The matcher ships a 7-row case table, including the trap that aprender-zram-core cuda must not match the aprender-zram cuda row.

Falsifiers

• Both jobs carry a vacuity floor (800 examples, 400 pairs). A discovery that finds almost nothing reports zero failures, which reads exactly like a pass.
• The matrix routes cargo deaths through cargo_classify.sh, so a saturated runner is reported as ENV rather than as a broken feature declaration.
• Both jobs open with cargo_step.sh --self-test.
• $? is read directly after each command, never through a pipe.
• All five workflow guards pass: reusable-workflow-pinned, no-timing-in-required, workflow-cargo-packages, workflow-env-defined, workflow-path-filters.

Draft until #3263 lands

Held as a draft deliberately: the known-red list is written against the tree after #3263. Merged before it, feature-matrix would be red on 67 pairs the list does not name. Undraft once #3263 is in.

no-close: this adds the lane; #3262 is the umbrella measurement and stays open until the last 9 pairs are green, and #3257/#3179 are owned elsewhere.

🤖 Generated with Claude Code

[github-actions]

§13.11 rung 1 — quorum shadow verdict

S13-SHADOW pr=3264 head=758cde5e68720ef592b0c4f2784ab445b8d1d809 verdict=REFUSE class=Q1 arm_rc=1

Shadow mode: this records a verdict and merges nothing. A refusal
to arm is not a block (§13 adds zero rows to §7) — the pull request is
exactly as green as it was.

[noahgift]

Sequencing note before this is undrafted.

The known-red list in night.yml is dated 2026-09-14 and correct as of that tree. Since then:

• the seven aprender-distribute selections are fixed by fix(distribute): tokio behind an optional feature, used unconditionally — 43 errors under --no-default-features #3257 (the tokio gate) plus fix(distribute): drop num_cpus for std::thread::available_parallelism — the 7 selections the tokio gate leaves red #3266 (dropping num_cpus for std::thread::available_parallelism, decided 3/3 by quorum). Both are needed; neither alone turns them green.
• the two cuda selections are addressed by fix(zram): the cuda feature says why it cannot build, instead of a cascade #3267, which does not make them green — it replaces the unresolved-import cascade with one named compile_error!. They stay red, so they stay on the list, and the reason now lives in the code.

The workflow treats a listed pair that PASSES as FATAL, by design — the list may only shrink. That means whoever undrafts this must re-derive the list against the tree at that moment, not trust the dated one: if #3257 and #3266 have landed, the seven distribute rows must be deleted or the first run goes red on "known-red list is stale".

Re-derive with:

cargo metadata --no-deps --format-version 1 \
  | python3 -c 'import json,sys;[print(p["name"],f) for p in json.load(sys.stdin)["packages"] for f in p["features"] if f!="default"]' \
  | while read -r c f; do
      cargo check -q -p "$c" --no-default-features --features "$f" 2>&1 | grep -qE 'error(\[|:)' && echo "$c $f"
    done

🤖 Generated with Claude Code