Menu
Audit exception safety and failure atomicity across all throw sites
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
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-exception-safety |
| description | Audit exception safety and failure atomicity across all throw sites |
| context | fork |
| agent | auditor |
| disable-model-invocation | true |
Audit the cache for exception safety defects. For every code path where exceptions can be thrown, determine whether the cache is left consistent.
Assume at least one exception safety bug exists. If your analysis yields zero findings, re-examine catch-commit-rethrow paths — explain specifically why no exception scenario leaves inconsistent state.
Priority #1: catch-commit-rethrow in doComputeIfAbsent and remap. This is the most commonly misunderstood pattern and historically the most fragile. Trace the EXACT sequence of committed mutations, notification delivery, and exception propagation for every exception type.
User-provided code that can throw:
Runtime exceptions: 6. OutOfMemoryError during node/reference allocation 7. StackOverflowError from deep re-entrancy 8. RejectedExecutionException from executor
For each throw site:
List every mutation already committed before the throw point.
Determine whether the catch block rolls back or commits.
Check for:
For catch-commit-rethrow (doComputeIfAbsent, remap), verify:
For OutOfMemoryError specifically:
For each defect: state the throw site, mutations committed, inconsistent state, and a concrete triggering scenario.
