The reclaim succeeded because the representation had become consumerless, not because 16.8 GB looked expensive.
Disk pressure created a question, not an authority
Runtime HP0-C started with a real capacity problem.
The cache tree contained more than 49 GB before the decisive reclaim. One legacy subtree, cache/build/sources/<sha256>, accounted for:
16,837,908,578 bytesThe storage layer was above its 32 GiB high watermark.
A traditional cleanup loop could stop there:
Find old large cache. Delete old large cache.
Runtime could not.
Some old bytes are durable execution evidence. Some large bytes are active Workspace build state. Some reconstructible bytes are still required for rollback. Some caches are owned by package managers rather than Runtime.
Capacity pressure can demand a decision. It cannot decide who has authority to delete.
The old rule protected the wrong thing
The decisive falsifier was a stale retention relationship.
Runtime's current execution model had already moved build targets to Workspace-scoped identities:
cache/build/<workspaceId>But the cache operator still protected legacy source-scoped build state whenever the corresponding repository had an open Workspace:
cache/build/sources/<sourceKey>That relationship used to make sense.
It no longer described an execution dependency.
The repository could be actively used while the old source-scoped representation had zero current consumers.
An unused write path made the problem worse
The cache CLI still exposed a migrate command capable of moving Workspace build state into the retired source-scoped hierarchy.
Nothing in current execution consumed that destination.
So Runtime had both:
- a stale protection rule for obsolete state;
- a write path that could manufacture more of the obsolete state.
HP0-C deleted the migrate path instead of building a better migration manager for a representation that had lost its consumer.
Reconstructible was not enough
It is tempting to define cache as “anything reconstructible.”
That is also too broad.
Runtime separated several retention classes:
- durable Runtime truth — Registry, Attempt, Event, Artifact, immutable admitted input evidence;
- Workspace state — governed by active, dirty, pinned, and retention state;
- Workspace-scoped build cache — reconstructible but protected while referenced;
- legacy source-build cache — reconstructible and no longer consumed;
- package-manager shared caches — physical pressure observed by Runtime, semantic deletion owned elsewhere;
- release material — current/previous candidates and receipts carry rollback/audit authority.
The same property—reconstructible—does not imply the same deletion rule.
The new rule followed current consumption
The repair aligned retention with the actual execution graph.
Legacy source_build children became Runtime-reclaimable regardless of whether the same repository had an open Workspace, because no current execution plan consumed that hierarchy.
Workspace-scoped caches remained protected while open or active.
Shared package caches remained outside Runtime's semantic deletion authority.
The cache inspector began projecting those distinctions explicitly instead of exposing the obsolete migration model.
The counterfactual selected only the dead representation
Before touching production, the patched-source storage model selected exactly:
11 source_build candidates
16,837,908,578 bytes
0 protected Workspace cachesThe modeled result dropped below the high watermark.
Protected Workspace violation count was zero.
That was the admission evidence for the production prune.
Production removed 16.8 GB
The production cache operator then executed the same authority model.
No Workspace cache was selected.
The package-manager-owned shared cache was observed but untouched.
The resulting cache state was within the high watermark.
We checked what survived, not just what disappeared
A deletion receipt saying “16.8 GB removed” would be weak evidence by itself.
HP0-C checked the retained responsibilities:
- post-prune Doctor remained healthy with zero violations;
- historical HP0-B Job artifacts remained digest-verifiable and readable;
- current and previous release candidates were preserved;
- canonical deployment receipts were preserved;
- dirty and active Workspaces remained protected;
- package-manager cache internals remained owned by their native managers.
The proof of a retention policy is not only what it deletes.
It is what it refuses to delete under the same pressure.
Age, size, and pressure all failed as policies
HP0-C explicitly rejected:
old → delete
large → delete
over quota → deleteThose are observations.
The semantic decision needs more:
who owns these bytes?
what current consumer can still name them?
are they durable evidence?
are they rollback authority?
are they active or dirty state?
can the owner reconstruct them safely?Only after those questions were answered did the 16.8 GB become reclaimable.
What HP0-C earned
HP0-C did not create a universal GarbageCollector or age-based retention service.
It earned a narrower storage law:
Retention authority follows current semantic/physical responsibility and live consumption. Reclaim only after the representation's owner can prove that the bytes no longer carry an active, durable-evidence, rollback, or external-owner role.
The safest delete command is not the one with the best age threshold. It is the one that can explain why every selected byte has lost the right to remain.
Evidence boundary
Public implementation, retained production proof
The Runtime implementation that aligned cache retention with execution authority is public at the exact owner commit below. The production prune receipt and retained post-prune authority evidence are currently held by Runtime/Host rather than exposed as a public canonical repository record, so Web classifies this article as E2.