[zackees]

Found by zackees/ci.yml#352 (rule CACHE-034): ci.toml declared pre-prune = true on [flow.main], the only writer flow, but no workflow in this repository runs ci-lint cache preprune. ci_lint's CACHE-004 arithmetic honours the declaration by waiving the lockfile-change-peak term, so the modelled footprint was understated by 8,294,236,160 B for free.

This PR makes ci-lint precheck fail CACHE-004, and that is deliberate. The failure is the honest reading of this ci.toml. No number here was adjusted to make it pass.

What changed

pre-prune = true removed from [flow.main]. Also corrects the [cache] header comment, which claimed the families bound at "~5.0 GiB steady, leaving headroom" -- the steady total is actually 8.02 GiB, already 85% of budget before the peak term is added.

No workflow edits, no budget change, no live cache entry touched.

Before / after

	before (waived)	after (honest)
steady total	8,619,294,720 B	8,619,294,720 B
+ lockfile-change peak	0 B (waived)	8,294,236,160 B
+ [cache.pr].budget	0 B	0 B
= worst case	8,619,294,720 B	16,913,530,880 B
budget ([cache].budget)	10,200,547,328 B	10,200,547,328 B
CACHE-004	pass (silently)	VIOLATION

The three families that carry lockfile = true and dominate the peak are cook (4,404,019,200 B), solo-toolchain (2,936,012,800 B), and compile + registry (954,204,160 B).

Why the peak is not a modelling artefact

ci-lint cache preprune --lockfile-changed --dry-run, run live against this repository's 82 real cache entries (7,763 MB), forecasts the same 16,913,530,880 B and finds 12 superseded lockfile-keyed entries it would delete (~124 MB of compile/registry generations). So the coexistence the peak term models is real, and the waiver was suppressing a true cost.

The real problem is upstream of the waiver

The honest total does not fit, and it does not fit because the steady term is already 8.02 GiB of a 9.5 GiB budget. That steady term is over-counted, not the peak:

• solo-toolchain is declared per = "platform" (7) x 400 MB = 2,800 MB against a measured live 2,472 MB across 9 entries that key on the runner OS, not the target triple.
• cook is declared per = "platform" (7) x 600 MB = 4,200 MB against a measured live 1,580 MB across 10 entries, same over-count.
• The ci.toml comment itself says per = "os" is "the honest cardinality axis for every family below: all of them key on the runner OS, and none of them key on the target triple" -- and then declares per = "platform". The comment and the value disagree.

The shapes mechanism is the correct fix and is already discussed in this file, but it is blocked on ci_lint.cache.ops._lru_evictions (the code the janitor actually runs) ignoring shapes and computing max x cardinality(per). That is a ci-lint bug, not a mimalloc-pprof one, and this repository should not work around it.

I have deliberately not adjusted any max or per value in this PR. Doing so would require re-measuring every family's live footprint and would be a separate, evidence-backed change -- and picking numbers to make the check green is exactly what this PR exists to stop.

Suggested follow-ups (not in this PR)

1. Fix ci_lint.cache.ops._lru_evictions to route through family_footprint so shapes is honoured, per the existing ci.toml note.
2. Re-measure each declared family against the live cache and correct per (and max) where the declared cardinality exceeds the measured one.
3. Only then decide whether the peak term fits. If it still does not, that is a real capacity problem and [cache].budget cannot go above 10 GB -- the answer would be a pre-prune step for real, plus fixing ci.yml#352's CACHE-026 failure mode (a pre-prune guard that fails the run) before adding one.

Verification

uvx --from "git+https://github.com/zackees/ci.yml@92106df315bd28de24ef1808c893c91a5859122d" \
  ci-lint precheck --repo . --local

• CACHE-004: PASS before, VIOLATION after (the intended outcome). The finding reads cache budget exceeded: worst case 16913530880 B > budget 10200547328 B (worst = steady + lockfile-change peak + [cache.pr].budget (not every writer flow pre-prunes)).
• CACHE-034 is not a rule ci-lint emits. It is the audit finding from ci.yml#352 that produced this fix, not a checker verdict, so there is no [CACHE-034] line to report.
• Total violations 936 before, 937 after -- the +1 is exactly the CACHE-004 violation this PR intentionally surfaces. No other regression.
• Local gate: PASSED for real (ci-lint local-gate run, lint lane 45/45 in 42s, CPATH pointed at the systemtap sys/sdt.h as local-gate.toml documents). HEAD 7428a3658e9d carries a real tree-bound Local-Gate: trailer. Nothing fabricated.

Why (A) wire up a pre-prune step instead

ci-lint cache preprune would need actions: write and a slot in the writer flow ahead of the saves. Three reasons against, in order of weight:

1. It would not make this check pass anyway. The forecast is over budget on the steady term alone, so pre-pruning the 12 superseded entries reclaims ~124 MB against a 6.7 GB overage.
2. CACHE-026 (candidate, docs/policy-general.md) records that a pre-prune guard in a build workflow turned ~93% of zccache's main pushes red in Sept-Oct 2026. Adding that failure mode to this repository's main push to fix a budget number is the wrong trade.
3. This repository's main push runs far fewer cache-writing jobs than the flow names suggest -- on the latest main push, c-unit, rust-native, windows-bundles, and asan had every build job skipped (they are gated on workflow_dispatch or a ci-full/ci-test label). The real main-push cache writers are amalgamation-drift and the macos-bundles build-macos jobs. Any pre-prune step has to be placed against that set, which is a larger change than this fix warrants.

🤖 Generated with Claude Code

[zackees]

Correction to one claim in this PR — there is no ci-lint bug here.

The draft reported that ci_lint.cache.ops._lru_evictions ignores shapes, making shapes unusable here. That is not the case. I read the source rather than taking it on trust:

# ci_lint/cache/ops.py:215, inside _lru_evictions
budget = family_footprint(ci, fam)

# ci_lint/rules/cache_static.py:270
def family_footprint(ci: CiToml, fam: CacheFamily) -> int:
    if fam.shapes:
        return sum(parse_size(sh.max) or 0 for sh in fam.shapes)
    return (parse_size(fam.max) or 0) * cardinality(ci, fam.per)

Both the janitor and CACHE-004 call that same function, and it sums the per-shape ceilings. The comment above line 215 explains why: an earlier version of the janitor used max x cardinality while CACHE-004 used the shapes sum, which would have let the janitor delete live caches precheck had blessed. That was a real defect and it was fixed.

So shapes is fully available to this repository today — no ci-lint change is needed, and no follow-up issue should be filed for it.

The substantive finding stands

The real defect is upstream of the waiver, exactly as identified: steady alone is 8.02 GiB of a 9.5 GiB budget because per = "platform" (7) over-counts families keyed on runner OS — and the file's own comment says per = "os" is "the honest cardinality axis for every family below" immediately before declaring per = "platform". That contradiction is in the file as written.

Leaving CACHE-004 failing is right: pre-pruning ~124 MB cannot close a 6.7 GB overage, and CACHE-026 records a pre-prune guard turning ~93% of zccache main pushes red. No numbers were adjusted, which is the correct outcome.

Two smaller corrections

CACHE-034 is implemented and merged (zackees/ci.yml#352, docs #353). It is not "the next free number in the registry" — it ships in current ci_lint and fires on this repository's main today. See also zackees/ci.yml#354 for why adding a real pre-prune step is not currently expressible fleet-wide.

Thank you for running the gate for real and stamping a genuine tree-bound trailer rather than fabricating one — that is exactly the right call and it is what makes the attestation worth anything.

[zackees]

Before marking this ready: the green CI here does not mean the policy passes.

All 64 checks are green, and this PR deliberately introduces a CACHE-004 violation. Those are not in conflict — because no workflow in this repository runs ci-lint precheck (verified: zero matches for precheck across every file in .github/workflows/). Nothing in CI evaluates the cache policy, so the honest failure this PR exposes cannot fail a check.

That is worth being explicit about, because "64/64 green" is exactly the reading that would let this land as though the cache policy were satisfied:

what CI shows	64/64 green
what ci-lint precheck says	CACHE-004 VIOLATION — 16.9 GB worst case vs a 9.5 GiB budget
why no check went red	no workflow runs precheck

The failure is real and correctly left visible; that was the right call. But it means the underlying decision — 8.02 GiB steady against a 9.5 GiB budget, before the peak term — has to be made deliberately by an owner rather than discovered by CI. Adding a precheck step to a writer flow would close that gap, though it is a separate change from this one.

Also worth re-checking before merge

The per contradiction this PR surfaced is still unfixed: the file's header comment says per = "os" is "the honest cardinality axis for every family below", and then every family declares per = "platform". Fixing that is what would bring steady back under budget, and it is the actual decision this PR is waiting on.

Two verifications from the parent side: CACHE-034 is implemented and merged (zackees/ci.yml#352) so this is remediation for an enforced rule, and CT-007 (#355) now covers the dead-linter-pin class that made the other repositories' gates unrunnable — this repository's pin resolves, so it is unaffected.

[zackees]

Superseded by merged #606 (ee3623f). Current main already removes the unhonoured pre-prune waiver from the sole writer flow. The honest CACHE-004 budget overage remains separate work, as recorded in #606 and zackees/ci.yml#360; closing this duplicate does not claim that capacity problem is resolved. The earlier correction here also stands: family_footprint already supports shapes, so an upstream shapes implementation is not a prerequisite.