Menü
Analyze reference retention paths that prevent GC of removed entries
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | audit-memory-retention |
| description | Analyze reference retention paths that prevent GC of removed entries |
| context | fork |
| agent | auditor |
| disable-model-invocation | true |
Analyze the cache for memory retention defects — cases where logically removed entries remain reachable through internal data structures.
This is NOT about liveness. Assume the entry IS removed from the CHM. The question is whether internal references still pin the key, value, or node in memory.
Assume at least one retention path exists where removed entries remain reachable longer than necessary. If your analysis yields zero findings, re-examine the write buffer and removal listener queue — explain specifically why retention is bounded.
Trace what happens to references after removal in each data structure:
For each retention path:
Do not report intentional strong references or retention bounded by a single maintenance cycle (unless maintenance can be delayed indefinitely).
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
