[zackees]

Opened as a DRAFT because this repository already ships a local-gate.toml and adding a ci.toml changes where ci-lint local-gate reads gate config from. I did not add any [local.gate.*] key — ci_lint/local_gate.py:293-306 only prefers ci.toml [local.gate] when that table is present, so with it absent local-gate.toml stays the sole declaration. Verified: local-gate lint reports the identical result with and without this file (1 violation, 3 other findings — all pre-existing, and three of them are just "PyYAML not importable" parser gaps).

Why

mimalloc-pprof runs at 85 cache entries / 8.48 GB = 83% of GitHub's 10 GiB per-repo cap, with no ci.toml to bound it. A toolchain bump lands on top of that.

The critical constraint, and how it is met

ci-lint cache janitor LRU-evicts each evict = "lru" family down to max x cardinality(per). Under-stating that product makes the janitor delete live caches. So every family's product is at or above its measured live footprint. Verified against all 85 live entries:

family           live_n   live_MB   lru_budget_MB   safe
compile              14       207            700   YES
cook                 10      1584           4200   YES
cook-delta            3         6             30   YES
registry             15        67            210   YES
soldr-mini            8        82            280   YES
solo-toolchain        8      2475           2800   YES

ALL FAMILIES SAFE (janitor LRU deletes nothing live): True

shapes deliberately not used, despite #334

shapes was merged in forge-ci/ci.yml#334 and works in ci_lint.rules.cache_static.family_footprint — but ci_lint.cache.ops._lru_evictions (line 210) still computes max x cardinality(per) and ignores it. Declaring shapes here would make CACHE-004's arithmetic look correct while the janitor evicted down to a smaller number — precisely the truncation hazard this PR is meant to avoid. max + per keeps both paths in agreement. This looks like a gap in #334 worth its own issue: ops._lru_evictions should route through family_footprint.

Budget arithmetic

compile: 100MB x 7 (platform) = 734003200 B (lockfile peak counted again)
cook: 600MB x 7 (platform) = 4404019200 B (lockfile peak counted again)
cook-delta: 10MB x 3 (os) = 31457280 B
registry: 30MB x 7 (platform) = 220200960 B (lockfile peak counted again)
soldr-mini: 40MB x 7 (platform) = 293601280 B
solo-toolchain: 400MB x 7 (platform) = 2936012800 B (lockfile peak counted again)
steady total            = 8619294720 B
+ [cache.pr].budget     = 0 B
formula applied: worst = steady + [cache.pr].budget (every writer flow pre-prunes: lockfile peak waived)
= worst case            = 8619294720 B
budget ([cache].budget) = 10200547328 B

8.02 GiB worst case vs a 9.5 GiB budget. It fits, with ~1.4 GiB of headroom for the lockfile generations a setup-soldr bump produces before the janitor reclaims them.

per = "platform" (7) rather than "os" (3) for the four families that need it: cardinality() has no per-lockfile axis, and the live check (_check_family_live_excess) compares live entry count against cardinality(per) x2. With per = "os" four families fired CACHE-004 needs_review at 10/14/15/8 live entries against a model of 6.

Live audit (ci-lint cache audit, ci.yml@92106df)

ci-lint cache audit: 85 live cache entrie(s), 8482877804B total
family                    count        bytes
compile                      14    217458483
cook                         10   1660730489
cook-delta                    3       6660187
registry                     15     70357011
soldr-mini                    8     86216756
solo-toolchain                8   2595186496
undeclared                   27   3846268382
budget: 8482877804B / 10200547328B (83.2%)

Counts: 27 CACHE-001, 2 CACHE-004 needs_review, 16 CACHE-005, 12 CACHE-006, 1 GEN-009. None of these are static-proof failures of this document — load_ci_toml is 0 findings and CACHE-004/029/030 are each 0 findings statically. They describe the existing cache state.

Two things the task brief got wrong, and one real finding

1. soldr-prepare-* is NOT setup-soldr:cross-targets. The brief said it was. It isn't:

setup-soldr:cross-targets -> ('setup-soldr-prepare-v3-',)

The live keys are soldr-prepare-<triple>-<sha> — no v3 segment, so no via value classifies them. All 1.87 GB is therefore correctly reported undeclared, not silently bound to a family. Declaring it as cross-targets would have been a lie the audit couldn't catch.

2. msys2-pkgs-upd:* and benchmark-* are hand-written actions/cache keys, not any sanctioned action's output. Same conclusion: undeclareable via via.

3. The undeclared row is 3.58 GiB — 42% of the repository's cache. Breaking it down:

prefix	entries	note
setup-soldr-targetcache-thin-v2-	11	no via exists for it
soldr-prepare-*	4	1.87 GB; prefix mismatch above
benchmark-allocators-*	4	900 MB, hand-written
msys2-pkgs-upd:*	4	338 MB, hand-written
benchmark-references-* / benchmark-fork-*	3	223 MB
solo-toolchain-v2-*	1	older major, not a declared legacy_prefix

So no ci.toml can currently get this repository under budget, and I'm not claiming otherwise. ci-lint needs via entries for setup-soldr-targetcache-thin-v2- and the soldr-prepare-* shape before 3.58 GiB can be declared rather than left unbounded. That's a ci.yml follow-up, not something to fudge here.

Other choices

• [cache.promote] mode = "off" — nearest-ancestor promotion is unreleased (setup-soldr#566); claiming it would be a promise nothing implements (CACHE-030).
• cook-delta declared as a family, not under [cache].retired: setup-soldr 0.9.27 still writes it, so retiring would fire CACHE-009 against 3 live entries.
• [cache.pr] mode = "none", budget 0MB — no PR-scoped cache is declared today.
• platform-selector = "src/prim/prim.c", platform-code = ["src/prim/{osx,unix,windows,wasi,emscripten}/**"] — the C library's real OS-branch layout.
• allow.setup-soldr.only-in = ".github/actions/soldr" names a directory that does not exist: setup-soldr is called directly from ~15 workflows with no composite wrapper. It's deliberately non-matching rather than naming a fiction. Creating the wrapper is a follow-up.
• 7 platforms, from cross.yml's build+test matrices and macos-bundles.yml's cross matrix. aarch64-pc-windows-msvc is excluded: cross.yml builds it but has no runner for it.

What I did NOT do

• Did not delete any cache. The 16 CACHE-005 and 12 CACHE-006 findings are pre-existing and left in place — cleaning them up is a separate, deliberate cache janitor run, not a side effect of adding a policy file.
• Did not touch [local.gate], local-gate.toml, or any workflow.
• Did not add [[exceptions]]. The 3 GEN-003 needs_review findings on ci.toml are the known "required suite's run command isn't in a literal run: line" case; they resolve to needs_review by design, not a defect to suppress.
• Did not merge.

Reviewer checklist

1. Confirm the shapes gap in ops._lru_evictions is worth its own ci.yml issue (it makes bench: hole-purging chart under jemalloc, upstream mimalloc, Bun mimalloc and mimalloc-pprof (Performance section) #334 unusable for exactly the families it was built for).
2. Decide whether undeclared families should block adopting a budget at all — 42% of this repo's cache is currently unbounded by any document.
3. Confirm [allow] should be populated this loosely for a repo with no ci.toml history, or whether this should land as a minimal cache-only document first.