Menü
Analyze shutdown, close, and GC-of-cache lifecycle correctness
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
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
| name | audit-lifecycle |
| description | Analyze shutdown, close, and GC-of-cache lifecycle correctness |
| context | fork |
| agent | auditor |
| disable-model-invocation | true |
Analyze the cache for defects during shutdown, close, and garbage collection of the cache instance itself.
Assume at least one shutdown or lifecycle race exists. If your analysis yields zero findings, re-examine scheduler/executor lifecycle and in-flight operations during close — explain specifically why no race is possible.
Operations racing with close/cleanup: get/put/compute during cleanUp() or GC? close() state transition? Operations after close()?
Scheduler lifecycle: Does the scheduled future prevent cache GC? Can scheduler fire after cache is collected? Is the task cancelled on close?
Executor lifecycle: Reference cycle between cache and executor? RejectedExecutionException handling when executor is shut down?
Removal listener drain on shutdown: Are pending notifications delivered or dropped? Notifications lost if executor shuts down first?
In-flight operations during shutdown:
Multiple close calls: Is close() idempotent? Concurrent close() corruption?
Finalizer / Cleaner interactions: Reference queues outliving the cache? Reference queue processing accessing dead cache?
For each defect: state the lifecycle transition, provide a concrete scenario, state the observable incorrect behavior.
