Pessimistic Offline Lock Implementer

When to Use

This skill implements the Pessimistic Offline Lock pattern after offline-concurrency-strategy-selector (or your team) has confirmed it is the right concurrency strategy. The pattern applies when a business transaction spans multiple HTTP requests — user opens a record, edits for minutes or hours, then saves — AND the rework cost of a late collision rejection is unacceptably high.

The core trade-off: Optimistic Offline Lock detects conflicts at commit time (user loses work already done). Pessimistic Offline Lock prevents conflicts at load time (user sees "locked by Alice" immediately, before doing any work). Use Pessimistic when late failure is genuinely unacceptable — insurance policy underwriting, complex order editing, legal document authoring.

Do not use if collisions are rare and rework cost is low (use optimistic instead). Do not use if the entire workflow fits in a single DB transaction (use isolation levels).

Context & Input Gathering

Gather the following before proceeding. Grep the codebase or ask the user directly.