skills/vibe-reliability/references/idempotency-concurrency-audit.md

# Idempotency & Concurrency Audit

## Operation

Inspect the named boundary and report supported findings. Do not edit product code. Include concrete evidence, impact, the owning source, one remediation direction and a meaningful validation route. Severity follows actual impact, not a category example.

## Goal and scope

Audit one operation for duplicate execution, races, lost updates, lock/lease ownership, ordering, and stale completion.

## Domain invariants

- The logical operation has a stable identity and a defined duplicate result across retries/processes.
- Read-check-write transitions are atomic, versioned, serialized, or otherwise protected at the authoritative store.
- Locks/leases have bounded lifetime, fencing or stale-owner rejection, and do not span slow external work without design evidence.
- Parallelism preserves required ordering and cannot apply stale completion over newer state.

## Audit method

1. Map operation identity, mutable state, critical sections, side effects, acknowledgement, and retry sources.
2. Construct simultaneous, duplicate, delayed, timeout-after-success, crash, lease-expiry, and stale-worker interleavings.
3. Inspect database constraints/transactions, compare-and-set/version fields, distributed lock semantics, and consumer ordering.
4. Distinguish idempotent effect from deduplicated request and document retention window.

## Priority model

- **P0:** outage, data loss, duplicate irreversible effect, tenant breach, deadlock, request collapse, or runaway cost.
- **P1:** a hot-path reliability, consistency, concurrency, or performance defect with clear impact.
- **P2:** a lower-risk but concrete scaling, diagnosability, or secondary-path issue.