CacheRegistry

Corex\Cache\CacheRegistry · class · Core layer

Everything CoreX caches, and what each of those things is (spec 078, FR-001/003). This is the only place that decides what a clear operation may remove, and it decides by consulting a declaration rather than by matching a pattern. That distinction is the whole design. A pattern-matching clear — DELETE ... LIKE 'corex_%', or foreach transients starting corex_ — is one line shorter and would delete every rate-limit counter and every spent-captcha token, because both are stored as corex_* transients. Worse, it would keep doing so silently as new entries appear. Walking a declared list means a key nobody declared is a key nothing clears, and an entry classified as security state cannot be reached by any scope, present or future. Adding a cached value to CoreX means adding it here. That is deliberate friction.

Public API

all(): array

clearable(CacheScope $scope): array

The entries a given scope is allowed to remove. Classification decides first and the scope narrows afterwards — never the reverse. A scope cannot widen its way into security state, because security state is filtered out before the scope is even considered.

protected(): array

Entries a scope may not touch, with the reason — so a report can say what it left alone rather than quietly doing less than the operator expected.

find(string $key): ?CacheEntry