Menu
Analyze the cache for liveness defects (progress, termination, starvation)
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | audit-liveness |
| description | Analyze the cache for liveness defects (progress, termination, starvation) |
| context | fork |
| agent | auditor |
| disable-model-invocation | true |
Analyze the cache for liveness defects. Safety (no bad states) has already been verified. Focus exclusively on liveness (good things eventually happen).
For each of the following properties, either prove it holds or construct a violating execution:
TERMINATION: If no new operations are submitted, does the maintenance loop eventually reach IDLE state? Can drainWriteBuffer loop indefinitely? Can any spin loop fail to terminate?
EVICTION PROGRESS: If weightedSize > maximum and no new entries are added, does eviction eventually reduce weightedSize to <= maximum? Can an entry that should be evicted survive indefinitely?
EXPIRATION PROGRESS: If an entry has expired and no new operations touch it, is it eventually removed from the map? Under what conditions can an expired entry persist indefinitely?
REFRESH PROGRESS: If a refresh is triggered, does it eventually complete (either successfully or by giving up)? Can a refresh remain in-flight indefinitely?
BUFFER DRAIN PROGRESS: Can the write buffer fill up and never be drained? Can the read buffer permanently lose entries in a way that causes incorrect eviction policy?
STARVATION: Can one thread's cache operations be starved indefinitely by other threads? Can the eviction lock be held for unbounded time?
NOTIFICATION PROGRESS: Can a removal/eviction listener notification be permanently lost (not delayed, but never delivered)?
For each property:
Do not analyze safety properties. Do not suggest code improvements.
Audit the adaptive window hill-climber and region-resize logic for implementation defects (not algorithm quality)
JSR-107 (JCache) spec-conformance audit
Audit explicit state machines (drain status, node lifecycle, async-value lifecycle) for illegal or missed transitions
Heavyweight history-mining bug audit. Walks the caffeine module's git history chronologically (oldest to HEAD), maintains a forward-tracked issue database, and surfaces concerns introduced by past commits that were never resolved. Catches bugs that snapshot mining cannot — half-fixes invisible from current state, latent+trigger pairs across multi-commit interactions, and partial refactors. Slow (model/effort-dependent; ~24h on Opus + max effort) and rare-run (every several months or before a major release).
Differential audit comparing matched code paths that should behave identically. Spawns one auditor per sibling pair (sync/async, bounded/unbounded, view consistency, bulk vs single, generated node variants, read fast vs slow, adapter conformance) and requires a concrete witness scenario where the two paths diverge observably.
Find places where documented API contracts and the implementation diverge
