[noahgift]

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.

default = ["cpu"], cpu = ["tokio", "num_cpus"], so --no-default-features drops tokio while
four source files still name it.

tokio, not cpu — a deliberate departure from the ticket

#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, true exactly when some
feature brought tokio in. That is the predicate the code actually depends on.

What is gated, and why each

executor::cpu	the only executor module that was not already 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, scheduler	tokio throughout
Pool, PoolBuilder, their impls and imports	the crate's high-level API is async to its core — tokio::sync::RwLock, JoinSet, time::sleep, and a CpuExecutor that spawns processes through tokio. There is no meaningful tokio-free Pool to preserve, so the surface is gated with the runtime it requires rather than half-gated into something that compiles and cannot run

Verified in every direction

A gate that breaks the normal path is worse than the defect it fixes.

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, by mutation: removing the gate on executor::cpu alone puts
--no-default-features back to 10 errors; restoring it returns 0.

Context

This was the last red clause of T-1's deep lane. With it, three of T-1's constituents are measured
and green and cost ~5 minutes combined — and none has ever run in CI:

doctests                978 pass, 0 fail     192 s
examples build          980 targets, 0 err    83 s
--no-default-features   0 errors              26 s   ← this PR

Closes #3176

🤖 Generated with Claude Code

[github-actions]

§13.11 rung 1 — quorum shadow verdict

S13-SHADOW pr=3257 head=f18e257dcbf01e64f242249046a373df737fdae6 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]

The feature = "tokio" gate here is right and necessary, but it is not sufficient — measured against a full 430-pair (crate, feature) sweep (#3262), this crate has 24 red pairs on two causes, and this PR addresses one of them.

executor/cpu.rs also uses num_cpus, and only the cpu feature pulls it:

cpu        = ["tokio", "num_cpus"]
remote     = ["tokio", "bincode", "tracing-subscriber"]
checkpoint = ["trueno-db", "tokio", "arrow", "parquet"]
tui        = ["crossterm", "tokio"]
serverless = ["pepita", "tokio"]
microvm    = ["pepita", "tokio"]

So for every selection with tokio on and num_cpus off, this PR's gate lets executor::cpu compile and it then fails on num_cpus instead:

$ cargo check -p aprender-distribute --no-default-features --features checkpoint
error[E0433]: failed to resolve: use of unresolved module or unlinked crate `num_cpus`

Seven selections are in that shape: checkpoint, microvm, remote, remote-tls, serverless, tokio, tui. (The other 17 are the tokio cause this PR fixes.)

Two ways to close it, both one line:

• gate on all(feature = "tokio", feature = "num_cpus"), or
• add num_cpus alongside tokio in each feature that enables it — which also makes the declarations read as what the executor actually needs.

I have deliberately not touched this crate in #3263 since this PR owns it. Happy to push the follow-up here if that is easier than re-rolling.

🤖 Generated with Claude Code

[noahgift]

Superseded by #3295, which carries this change unmodified along with eight other
collision-free CI/guard PRs as a single merge-queue entry.

Not abandoned and not rejected: the commits are merged into
PMAT-3231-batch-1-ci-guards verbatim (clean=9 conflicted=0), and this branch is
retained — reopening is one click if #3295 does not land.

Why: a successful merge_group CI run is median 78 min with max_entries_to_merge = 1,
so nine entries is ~12 h of queue for 623 insertions. As one entry it is 78 minutes.
Root cause and the full five-whys: #3294.