REVIEW RULE: VALID STATE MUST SURVIVE FAILURE

Status: Untested review aid. AIHackers adaptation, not Calif's original skill.
Format: Plain-text review reference; this is not an installed SKILL.md.
Provenance: https://calif.io/php2shell/
Calif describes generalizing an initial finding into a reusable review pattern.
The wording and evaluation proposal here are independently written by AIHackers.

INVARIANT
State visible to cleanup, a later request, or another worker must be fully
initialized and valid for as long as those consumers can access it. An aborted
operation must not leave visible state that falsely appears complete or live.

REVIEW SEQUENCE
1. Identify operations that can fail, throw, abort, or skip ordinary cleanup.
   Read their actual failure contracts; do not assume a helper can fail.
2. Find earlier changes that publish a pointer, increment a visible count,
   transfer ownership, or update shared bookkeeping.
3. Identify initialization, rollback, reset, or cleanup scheduled afterward.
4. Trace what the failure skips and what state survives that failure.
5. Find a reachable consumer that can observe the surviving invalid state.
6. Report a defect only when the supplied code supports the complete chain.

EVIDENCE REQUIRED FOR A SUPPORTED FINDING
- Source location of the premature state change.
- Specific fallible operation and the supplied failure contract.
- Repair, initialization, or cleanup skipped on that path.
- State that survives, and a reachable consumer of that state.
- Violated invariant and the resulting correctness or security consequence.
- Necessary preconditions, with missing information explicitly identified.

NEGATIVE CONTROLS: DO NOT FLAG ORDERING ALONE
- Initialization completes before state becomes visible to any consumer.
- Failure reliably restores the relevant invariant before observation.
- The operation cannot fail under the stated contract.
- Relevant state and all potential consumers are terminated together, with
  no surviving shared state or external consumer.
- The proposed consumer cannot reach or observe the incomplete state.
These are questions to verify in the code, not assumptions of safety.

OUTPUT DISCIPLINE
Use concise source evidence and describe the failure path. Separate a supported
defect from a hypothesis needing context. A clean result means no supported
finding in the supplied scope, not that the program is secure. Suggest a fix
intent and a local regression-test idea; do not invent an exploit or payload.

LIMITS
This aid targets one family of failure-handling defects. It is not a complete
security audit, proof of exploitability, or substitute for a maintained runtime.
Success on seeded examples would validate only that bounded exercise.