sandbox:read-only (macOS Seatbelt)
-- reasoning --
I'm scanning the diff across sweep.rs, config.rs, main.rs, admin.rs, and metrics.rs for actual defects, starting with checking whether the scheduled run correctly invokes sweep with the right dry_run flag.

Now I'm examining the candidate removal logic in sweep(): it counts eligible blobs based on remaining size and minimum age, but the sort order looks suspicious. The comment claims candidates are sorted "oldest first" so long-unused blobs get evicted first, but `sort_by_key` on `candidate.age` ascending actually orders from smallest Duration (most recently modified) to largest — meaning newest files come first and the truly oldest ones end up last, contradicting the stated eviction intent.

So the sort order is ascending by age, meaning near-threshold (barely old enough) blobs get evicted before the truly ancient ones further down the list - which contradicts the comment's stated intent of removing the longest-untouched blobs first. This looks like a genuine ordering bug where eviction stops before reaching the oldest candidates.

This confirms the logic is inverted from intended behavior—it should prioritize deleting the truly oldest blobs first, but instead it evaluates recent-but-eligible ones early and stops before ever reaching the genuinely ancient ones at the end of the sorted list, leaving stale blobs stuck in the store.

I want to pin down the exact line numbers for the sort_by_key call and its comment in sweep.rs so this bug is concretely triable, then move on to checking the saturating_sub logic on the remaining count.

Working through other candidate issues: the held total sums candidates before sorting so that's fine, scanned uses a safe try_from conversion, and forget correctly removes index entries tied to a removed digest. I'm also checking whether index entries for kept blobs are affected by that removal logic, and starting to think about potential race conditions when the sweeper's run() function locks its mutex.

But then I notice the admin route's reclaim() calls sweeper.sweep(dry_run) directly instead of going through run(), meaning it skips the mutex that's supposed to enforce "one sweep at a time" per the module doc comment. That's a real concurrency bug — a manual sweep triggered via the API could run simultaneously with the scheduled background sweep, violating the documented invariant.

The doc comment explicitly warns against concurrent sweeps corrupting the total, confirming the on-demand endpoint's failure to take the lock is a genuine defect, not just a stylistic issue. I want to pin down the exact line numbers, and also double-check whether tokio's interval fires its first tick immediately rather than after a full interval, since that's another claim worth verifying.

So in spawn_sweeps, the interval is created and then set to delay missed ticks, but that first `ticks.tick().await` call resolves immediately rather than waiting a full interval — directly contradicting the comment claiming the first sweep is deferred by a full period.

This is worth reporting - I recall tokio's interval documentation confirms the first tick completes immediately, so the mismatch between the documented delayed behavior and the actual eager first sweep is indeed a real bug.

Now I'm checking admin.rs's query extraction and the dry_run parameter handling, which look correct. In config.rs I'm noting that cache_min_age has no validation, but since zero is a valid value (immediate eligibility), that's not actually a problem, and I'm scanning for potential overflow issues in the default byte constants.

The default cache size fits comfortably in u64. I'm also verifying whether Duration::from_hours and from_mins are stable enough given the MSRV, which is ambiguous without knowing the Cargo edition, then moving to metrics.rs to check the ordering of values returned by the metrics array.

Checking COUNTERS array order against values()...
└ 4905 tok ·  94.9 tok/s · 19K ctx · 5763ms ttft · 51.7s wall
↳ read_file: read pr/services/proxy/src/metrics.rs
└ read_file: read complete
↳ read_file: read pr/services/proxy/src/sweep.rs
└ read_file: read complete
↳ read_file: read pr/services/proxy/src/routes/admin.rs
└ read_file: read complete
↳ read_file: read pr/services/proxy/src/main.rs
└ read_file: read complete
auto-compress is on at 85% but the context window of "anthropic/claude-sonnet-5" on openrouter is unknown, so this run will not compress - set AFI_SOURCE_OPENROUTER_CONTEXT_WINDOW (or pass --context-window) to enable it
-- reasoning --
I'm checking the field ordering in the struct versus how record_sweep populates it and how values() returns them—looking for a mismatch between sweep_bytes_reclaimed and sweep_blobs_removed positions.

Comparing against COUNTERS array order, I confirm the bug: index 4 is labeled sweep_blobs_removed_total but values() returns sweep_bytes_reclaimed there, and vice versa for index 5. The two arrays are swapped relative to each other, exactly the kind of mismatch the doc comment warns against.

I'm also noticing a second issue in the sweep loop: candidates are sorted by age using an ascending sort, which puts the smallest age (youngest blob) first and the largest age (oldest blob) last. But the code comment claims this sorts "oldest first," which is backwards -- ascending order by age actually processes newest blobs first, meaning the removal logic would target young blobs before old ones, contradicting its stated intent.

So this contradicts the stated design intent that oldest blobs should be removed first to bring the store back within its ceiling. Checking with example ages confirms it: ascending sort puts newest first, so removal proceeds newest-to-oldest instead of oldest-to-newest, confirming this is a genuine high-severity bug.

Checking Rust's sort_by_key semantics confirms this: ascending order means younger blobs (smaller duration) end up first, exactly backward from the intended "oldest first" eviction. That confirms a genuine bug on that line — it needs to sort descending using Reverse or a custom comparator instead.

I'd rate this 🟠 rather than 🔴, since it's a functional/business-logic bug (evicting fresh entries while stale ones linger, causing extra fetches) rather than crashes or data corruption. Similarly, the metrics issue deserves 🟠 given its operational impact on monitoring and alerting, even though it doesn't cause data loss.

Looking at other areas, the sweep logic follows symlinks via fs::metadata but that seems intentional given the hard-link design. The bigger nuance is that age tracking relies on modification time, which for content-addressed blobs really reflects "oldest inserted" rather than true "least recently used" since mtime doesn't update on access -- this feels more like a design limitation than an outright defect, unless the documentation claims otherwise.

I'm also checking the dry_run behavior for sweep, which correctly reports bytes/removed without actually deleting, so that's fine. Then looking at spawn_sweeps, the background sweep task isn't tracked with a join handle, so I'm considering whether it gets properly cancelled during shutdown or if it could be interrupted mid-write when the runtime drops.

The doc comment actually addresses this by noting sweep is idempotent since it only unlinks with no half-finished state, so this is intentional behavior rather than a bug. Now I'm examining forget() in sweep.rs, tracing how it uses index entries mapped from referenced() to determine what gets deleted from "gone" -- checking whether entries missing from the index versus those evicted for size are handled consistently when forget() looks them up.

For digests removed due to hitting the size limit, forget() correctly clears all their index entries globally, which is the right behavior since the blob itself is gone. I'm also checking config validation -- cache_min_age isn't explicitly validated against zero the way CAIRN_SWEEP_INTERVAL is, but zero seems like a legitimate value (meaning sweep immediately), so that's not really a bug either. Then I move to checking route ordering, confirming the admin sweep endpoint at "/v1/admin/cache/sweep" uses POST as documented, and start looking at credential handling next.

The credential check follows the same pattern as purge, so that looks fine. I also verify the Cargo.toml diff adds the "sync" and "time" features appropriately, and the docs are updated to match. I re-confirm the values()/COUNTERS ordering mismatch is real after rereading the exact lines, and I think about whether to check test files for the sweep's sort behavior, though I'll focus on source rather than tests. I also verify that "held" is computed purely from the blob directory before removing partials, correctly excluding incoming data, and I start tracing through how "remaining" decreases relative to max_bytes as candidates get removed in the loop.

If the sort order is wrong, the sweep would evict newest blobs first instead of oldest, potentially stopping early near the boundary and leaving the true oldest, least-useful blobs untouched -- exactly backwards from the intended design. This is a significant logic bug. For severity, I'm leaning toward rating this sort bug as critical since it defeats the core purpose of the eviction policy, risking perpetual cache misses on frequently used packages while stale entries linger, while I'd rate the metric mismatch as operationally significant but likely one tier lower since it's about incorrect reporting rather than data loss.

I'm double-checking that the dry_run boolean query parameter should parse fine through axum's extractor, and now pinpointing the exact line numbers in metrics.rs to cite for the field ordering issue -- specifically the struct definition, the counters array grouping, and the values() method where the ordering mismatch actually manifests.

Let me look at the full diff of config.rs to check for similar validation issues there.
└ 4789 tok ·  87.1 tok/s · 30K ctx · 4397ms ttft · 55.0s wall
↳ read_file: read pr/services/proxy/src/config.rs
└ read_file: read complete
-- reasoning --
I'm checking the ordering of fields in the COUNTERS array against what values() actually returns in metrics.rs, since a mismatch there would misalign hits, misses, upstream failures, policy refusals, and sweep stats.

Confirming this by tracing the exact index ordering: sweep_blobs_removed and sweep_bytes_reclaimed are swapped between the array declaration and the values() output, so the metric labels end up attached to the wrong numbers. Now I'm moving on to check sweep.rs for whether the `held` calculation properly accounts for partials being cleared beforehand.

Wait, this seems backwards - the comment claims oldest blobs go first, but sorting ascending by age would actually put newest files first in iteration order and oldest last, which contradicts the stated intent. I need to check whether the loop is meant to iterate front-to-back removing early entries, since that's what would make the comment's logic hold.

Actually this seems fine on reflection: removal requires both being over the byte ceiling and old enough, so processing youngest-first just means younger blobs get skipped until the loop reaches old enough candidates, which still end up removed since they satisfy both conditions—so the sort order doesn't actually break correctness, it just changes iteration order without changing which items ultimately qualify for removal.

I want removal order to prioritize the oldest items first, so that when just enough bytes need to be removed, it's genuinely the oldest data that goes rather than an arbitrary pick among items satisfying the age condition.

This actually inverts the intended eviction order: the loop removes borderline-old items first while saving the truly ancient ones for last, so once total bytes drop below the ceiling, the loop stops removing (since remaining < max_bytes makes remove false), leaving the oldest blobs untouched instead of the ones we'd actually want gone.

I need to double check the sort direction — sort_by_key is ascending, and Duration's Ord means smaller duration (younger age) sorts first. So this confirms the bug: the comment claims "oldest first" but the code actually sorts youngest first, which is backwards from what's needed. The fix would be to reverse the sort key.

Confirming that sorts ascending, leaving oldest last — that's a definite bug on line 102.

Checking other areas: the sweep route being outside the timeout layer looks intentional. But I notice something more concerning — the on-demand admin sweep call may bypass the `running` mutex that the interval-based sweep relies on, which could allow concurrent sweeps to race.

That looks like a real violation: `sweep()` itself doesn't lock, only `run()` does, but admin's reclaim endpoint calls `sweep()` directly, skipping the mutex entirely. That means an admin-triggered sweep could run concurrently with the periodic background sweep, breaking the documented "one sweep at a time" guarantee.

There's also a blocking I/O issue: `sweep` runs synchronous filesystem operations directly within an async handler without offloading to a blocking thread pool via `spawn_blocking`. That means the directory walk, metadata reads, and file removal execute on the tokio worker thread, stalling other requests being processed by that same worker.

This confirms the anti-pattern: the module doc even acknowledges the walk is synchronous by design since one pass of stdlib calls is cheaper than scheduling overhead, but the same doc admits large sweeps can legitimately take over ten seconds, meaning that blocking work runs directly on a tokio worker thread without spawn_blocking and can stall that thread for the whole sweep.

The admin sweep route also runs synchronously without the shared mutex protecting concurrent calls, so repeated hits to that endpoint could tie up multiple worker threads at once. I'm settling on the key findings: the metrics counters are mismapped against their labels, the sort order is inverted so oldest blobs aren't evicted first during periodic sweeps, and the admin sweep bypasses the concurrency guard.

Checking other edge cases: age_of returning zero on clock skew seems intentional and matches "young blob" semantics rather than being a bug. I'm also wondering about collect using fs::metadata instead of symlink_metadata—since it follows symlinks, a symlink pointing to a directory could get treated as a directory to recurse into rather than a candidate file, which might be worth flagging.

The `>=` comparison for remaining bytes is slightly conservative but not incorrect—it just means eviction continues until strictly below the max rather than stopping at exact capacity. Now I'm checking whether cache_min_age has zero-value validation like the other config fields do.

I notice cache_min_age isn't validated for zero the way sweep_interval and cache_max_bytes are, but that's probably intentional since a zero grace period just disables the protection window. The docs updates look fine too, and clear_partials running before the held calculation only touches the incoming directory, not blobs, so no ordering issue there. Now I'm re-verifying the metrics array indices against the actual counter order to confirm whether there's a real mismatch—checking cache_hits_total, cache_misses_total, upstream_failures_total, and policy_refusals_total against their expected positions.

Comparing the two orderings directly, I can confirm sweep_bytes_reclaimed and sweep_blobs_removed are swapped between the counter definitions and the values() output — a genuine bug that would silently corrupt monitoring data, since operations.md tells users to watch `cairn_proxy_sweep_bytes_reclaimed_total` but that metric would actually report blob counts instead of bytes. That's a solid, high-severity finding.

Now I want to verify the sort order bug for blob removal by walking through a concrete example: three blobs aged 10 days, 5 days, and 1 hour, with a default min_age of 1 hour, sorted ascending by age to see if the removal order actually behaves as intended.

Working through the removal loop, the newest blob (1 hour old) satisfies the min-age condition first and gets iterated on before the older ones, so if the ceiling is reached partway through, the newest blob could end up removed while the oldest blob is left untouched — the exact opposite of proper LRU eviction. That confirms the sort order needs to be reversed so the oldest blobs are guaranteed removal priority.

This bug is severe: it defeats the entire purpose of LRU eviction, potentially causing thrashing where freshly-fetched blobs get evicted while stale ones persist indefinitely. I've already verified the missing mutex protection issue between admin.rs and sweep.rs's run/sweep separation, so now I'm just weighing severity labels — the sort inversion and metrics swap both look like critical bugs, while the missing mutex protection on the admin side needs its own severity classification.

I'm now digging into whether admin::sweep truly blocks the tokio worker thread synchronously. Tracing through the async function, it calls reclaim which is a plain synchronous function that performs blocking filesystem I/O directly within the async task without yielding or wrapping it in spawn_blocking — this ties up the worker thread for the entire directory walk, which is a legitimate performance issue on its own, though it may overlap with the concurrency concern I already flagged.

I'm splitting this into two distinct findings tied to the same line in admin.rs: first, the direct call to sweeper.sweep bypasses the running Mutex meant to serialize sweeps, letting concurrent sweeps race over the same directory; second, the synchronous blocking I/O inside the async handler stalls the tokio worker thread for large stores, which is a separate technical issue worth reporting on its own even though it stems from the same call site.

I'm also noting that main.rs's periodic run() has the same blocking pattern, but that's arguably intentional for the background task given the documented rationale for a synchronous walk, so it's less of a concern there than in the request-handling path.

Now finalizing the concrete findings: first, metrics.rs:88-96 has its values swapped relative to the COUNTERS order defined at lines 50-57, which mislabels sweep_blobs_removed_total and sweep_bytes_reclaimed_total -- a real correctness bug that could mislead anyone relying on these metrics for operations or alerting.

Second, sweep.rs:102 sorts in ascending order instead of descending, causing newest blobs to be evicted before oldest, which is the opposite of the intended LRU eviction policy -- this defeats the entire feature's purpose and could cause repeated disk churn while stale data lingers.

I'm now moving to look at routes/admin.rs:76.

Actually, I'm second-guessing myself on whether `Duration::from_hours` and `from_mins` are real stabilized std methods, or whether this is a nightly/unstable feature that shouldn't be relied on in the doc example.
└ 8954 tok ·  87.8 tok/s · 33K ctx · 4446ms ttft · 102.0s wall
↳ search_files: search pr/services/proxy for rust-version|edition|from_hours|from_mins
└ search_files: search complete
↳ read_file: read pr/services/proxy/Cargo.toml
└ read_file: read complete
-- reasoning --
I'm tracing how spawn_sweeps and the admin route both trigger sweeps in main.rs. The interval loop goes through sweeper.run(), which locks properly, but the admin route calls sweeper.sweep() directly, bypassing that running mutex entirely.

This confirms a real concurrency bug: the module docs promise "one sweep at a time" is enforced by the type itself, but sweep() is a plain unlocked public method while run() is the only version that acquires the mutex before calling sweep(false). Since admin.rs calls sweeper.sweep(dry_run) directly, a periodic sweep and an admin dry-run could execute concurrently, contradicting the documented guarantee.

I'm also spotting a second bug: the metrics values() function returns counters in order [cache_hits, cache_misses, upstream_failures, policy_refusals, sweep_bytes_reclaimed, sweep_blobs_removed], but COUNTERS names are ordered [..., sweep_blobs_removed, sweep_bytes_reclaimed] - the last two are swapped, so bytes_reclaimed gets zipped with the "blobs_removed" label and vice versa.

That's a genuinely ironic bug — the exact swap the comment warns against, meaning byte counts get labeled as blob counts and vice versa in the metrics output. That's a real, high-severity defect worth flagging.

I'm now checking the dry_run handling, which correctly skips recording, and looking at whether the remaining-size subtraction happens even for candidates not found in the index, which could throw off the accounting.

Now I'm examining the candidate sorting logic — the comment claims "oldest first" but the ascending sort by age would actually put the smallest age (most recently modified) first, not the oldest. That looks backwards from what's intended.

Confirming this: with age as elapsed time since modification, ascending sort puts newest files first (smallest age) and oldest files last, so the removal loop processing front-to-back deletes newest blobs first. That directly contradicts the comment's intent of removing the oldest, unused blobs while preserving recently fetched packages — this is a genuine inversion bug.

This means eviction proceeds from the recently-passed-grace items toward the oldest, so the truly stalest blobs get evicted last or possibly never—contradicting the intended "longest unwanted blobs go first" behavior. This looks like a real bug: the sort should be descending by age so the oldest items are removed first. Let me double-check that sort_by_key indeed orders ascending by the key returned.

Actually, thinking further, since the loop stops once remaining drops below max_bytes, order determines which specific blobs get evicted - with the ascending sort skipping past newer entries first, it stops removal early and leaves older stale blobs untouched while evicting newer ones unnecessarily.

This is a genuine, concrete bug at sweep.rs:102 that inverts the intended eviction behavior - it kicks out recently-used blobs while letting truly stale ones accumulate, causing repeated re-fetching of active artifacts. I'll flag this as 🔴 critical since it defeats the core purpose of the sweep feature.

I'm also confirming the "held" set is computed correctly from all candidates before sorting, so that part checks out. Now I want to check the saturating_sub overflow protection for other potential issues.

Checking the "forget" function's index cleanup: it correctly drops index entries pointing to removed blobs whether they were unreferenced or evicted for age, which properly prevents dangling entries. But I need to verify whether forget gets called during dry_run mode too - that would be a problem since dry_run shouldn't actually mutate the index, so I'm tracing through the sweep function's dry_run branch to see if remove_file is properly gated.

Looking at the actual removal loop, only the blob file deletion is gated behind `!dry_run`, but the hex gets pushed to `gone` and then `forget(&index, &gone)` runs unconditionally at the end - meaning a dry run would still physically delete index entry files from disk even though the blob file stays untouched. That's a real bug since dry_run is supposed to be a no-op preview.

I check `clear_partials` separately and confirm it's properly gated behind `!dry_run`, so that path is safe. That means sweep.rs has two confirmed issues: the inverted sort order causing wrong candidates to be evicted, and forget() running regardless of dry_run.

Now I'm pinning down exact line numbers - sort_by_key at line 102, the forget call at line 140, and for the metrics indices bug, checking the COUNTERS array against the values() function to confirm the order mismatch around lines 94-95 versus 50-57.

Confirmed the array order really is swapped - the labels at lines 50-57 don't match the value order at 94-95, a legitimate bug in metrics.rs. I'm also checking main.rs's spawn_sweeps and confirming the sweeper lock is handled correctly there, and now looking at admin.rs to verify whether its route calls the sweep function directly, bypassing the mutex.

Confirming sweep() is synchronous and doesn't acquire the lock at all, so calling it directly from admin.rs violates the documented "one sweep at a time" guarantee. This is a real concurrency bug - the periodic sweep and an admin-triggered sweep could run simultaneously and interleave, producing inconsistent removal counts or worse.

I'm now checking a couple of other spots for issues: the config's cache_min_age doesn't seem validated but isn't a clear bug, and the scanned count calculated from candidates.len() looks fine since it's computed before the sort.

I'm also considering whether Duration::from_mins is a real stabilized API in the Rust version being used here—can't verify without checking the toolchain, but since it's existing code in the repo, I'll assume it compiles and isn't worth flagging as a new bug.

I find a test already checking parse_duration against Duration::from_hours, confirming this API was in use before this PR, so it's not a toolchain concern introduced by the diff. Now I'm checking whether the sweep endpoint registered on the untimed router might be missing rate limiting or size bounds compared to the purge route on the bounded router.

The sweep route being on the untimed router looks deliberate, since long sweeps can exceed the 10-second timeout, and the purge route stays correctly on the bounded router unrelated to this diff. The bigger issue is that the sweep route doesn't share concurrency locking with the run() path, which I've already flagged as the main bug beyond the metrics and dry-run issues -- the Reclaimed struct's held and partials fields look properly documented and reported separately.

Now I'm identifying four concrete bugs: the sort order in sweep.rs is reversed so it evicts newest blobs instead of oldest, forget() gets called unconditionally even during dry_run causing state mutation despite the dry-run promise, the COUNTERS ordering in metrics.rs mismatches values() and swaps the bytes_reclaimed and blobs_removed labels, and the admin route's on-demand sweep bypasses the one-at-a-time mutex entirely, letting concurrent sweeps run against the stated invariant. I also want to check whether dry_run mode could still remove unreferenced blob entries from the index via forget being bypassed.

Double-checking the eviction logic: age is computed as SystemTime::now().duration_since(modified), so older files produce a larger duration/age while recently modified files have a small age. Since the goal is to evict the oldest blobs first when over the ceiling, the comment confirms this intent — files nobody has touched in the longest time should be removed first, while recently fetched files stay.

Sorting candidates by age ascending and iterating from the front actually processes newest files first, exactly the opposite of the intended "oldest first" removal order — this is a genuine inversion bug in the core sweep logic. I'm confident this is critical: it means actively used blobs could get evicted while stale, unused ones stick around indefinitely, defeating the whole purpose of cache locality and causing unnecessary re-fetches for hot packages.

Beyond that, the dry_run mode still calls forget and mutates index files despite promising no changes, which is a serious safety violation for a preview feature that admins rely on before committing to a real sweep — I'd rate this high severity too since it can cause real production impact. There's also a metrics bug where labels appear swapped, giving operators incorrect data for monitoring and alerting when they check bytes-reclaimed metrics against documentation.

The concurrent sweep bypass is another high-severity issue since it violates a documented invariant and could let two sweeps race, each independently computing "remaining" capacity and causing over-eviction below the intended ceiling — this is realistic given admins can trigger the route anytime alongside periodic sweeps. I'm now pulling together the exact line numbers for each finding: the sort logic in sweep.rs around line 102, the forget call around line 140, and the swapped metric values around lines 94-95, to write up a precise final report.

Resolving the format conflict: I'll keep one file:line per bug report line but mention the secondary location within the explanation text itself, like noting it also enters via a different file and line. Now I'll write the final answer.
Reviewed `pr/services/proxy/src/sweep.rs`, `pr/services/proxy/src/metrics.rs`, `pr/services/proxy/src/routes/admin.rs`, `pr/services/proxy/src/main.rs`, `pr/services/proxy/src/routes/mod.rs`, `pr/services/proxy/src/config.rs`, and `pr/services/proxy/Cargo.toml`.

🔴 `bug` services/proxy/src/sweep.rs:102: `candidates.sort_by_key(|candidate| candidate.age)` sorts ascending, so the smallest `age` (most recently modified, i.e. newest) blob is first and the largest `age` (oldest, longest-unwanted) blob is last. The removal loop that follows walks the vector front-to-back and stops once `remaining < self.max_bytes`, so it evicts the *newest* blobs first and leaves the truly stale ones in place until every newer blob has already gone — the opposite of the "oldest blobs go, this morning's fetch stays" behaviour the comment above it and `docs/operations.md`/`docs/architecture.md` describe. Fix by sorting oldest-first, e.g. `sort_by_key(|c| std::cmp::Reverse(c.age))`.

🟠 `bug` services/proxy/src/sweep.rs:140: `forget(&index, &gone)` runs unconditionally, even when `dry_run` is true. `gone` is populated for every candidate that satisfied the `remove` condition regardless of `dry_run` (the file removal itself is the only thing gated on `!dry_run`, at line 125), so a dry run actually deletes the on-disk index-entry files for those digests via `fs::remove_file` inside `forget`. This contradicts the documented contract that `?dry_run=true` "reports what a sweep would reclaim without removing anything" (docs/operations.md, routes/admin.rs:58-60) — a preview call leaves the store's index mutated.

🟠 `bug` services/proxy/src/metrics.rs:94: The order of `values()` (`sweep_bytes_reclaimed` then `sweep_blobs_removed`) does not match the order of `COUNTERS` (`cairn_proxy_sweep_blobs_removed_total` then `cairn_proxy_sweep_bytes_reclaimed_total`, metrics.rs:50-57), so `render()` zips them and prints the bytes-reclaimed value under the `..._blobs_removed_total` name and the blobs-removed value under `..._bytes_reclaimed_total`. This is exactly the mistake the adjacent doc comment ("Keeping the two side by side is what stops a fifth counter from being rendered under a fourth one's name") warns against, and it breaks the alert `docs/operations.md` tells operators to watch (`cairn_proxy_sweep_bytes_reclaimed_total`), since that metric will actually be a blob count.

🟠 `bug` services/proxy/src/routes/admin.rs:76: The on-demand sweep route calls `app.sweeper.sweep(dry_run)` directly instead of `app.sweeper.run()`, bypassing the `running: Mutex<()>` in `Sweeper` (services/proxy/src/sweep.rs:67,82-85) that the module's own doc comment (sweep.rs:10-12) says exists to guarantee "one sweep at a time." A request to `POST /v1/admin/cache/sweep` while the background interval sweep (main.rs:116, via `Sweeper::run`) is in flight runs concurrently against the same directory, which per the module's own reasoning can "take the store far below the ceiling either was aiming at."
└ 9054 tok ·  98.9 tok/s · 34K ctx · 5175ms ttft · 91.6s wall