proofline
TR

concurrency-proof

Purpose

Concurrency review of a change (working tree, branch, pull request or proofline run) that reports only proven problems.

Source Skill purpose

When to use it

Use concurrency-proof to review changed shared state, transactions and critical sections for proven races, deadlocks, lost updates, duplicate processing, retry effects or ordering problems. It works on a working tree, branch, pull request or proofline run. A concern needs a concrete schedule across at least two actors with source locations at each step. The project's own test runner may reproduce that schedule; when it cannot, reproduction is marked unsupported. A successful review means no problem was proved, while unproved risks remain visible separately.

For each candidate, the reviewer records shared state, readers, writers, locks and transaction boundaries. A claimed failure includes the exact order in which actors run and the point where an invariant breaks. A candidate that cannot be proved is kept with its location and the missing evidence. Findings outside changed lines are treated as pre-existing rather than attributed to this change.

Source Skill purpose

How it works

Steps of the skill, in source orderEach numbered step follows the skill definition and links to its source.1. Resolve changeFlow2. Find candidatesFlow3. Map critical sectionsFlow4. Build an interleavingFlow5. Reproduce safelyFlow6. Check the planFlow7. Report evidenceFlow
Steps of the skill, in source order

Source Flow

  1. Resolve change Record base and head, changed lines and the current working-tree state.

    Source Flow

  2. Find candidates Scan changed code for shared state and possible concurrent access.

    Source Flow

  3. Map critical sections Trace writers, readers, locks, transactions and retry boundaries for each candidate.

    Source Flow

  4. Build an interleaving Write a concrete two-actor schedule with file and line evidence for each transition.

    Source Flow

  5. Reproduce safely Run concurrent or repeated project tests for traced schedules when the runner permits.

    Source Flow

  6. Check the plan Compare a proved problem with any explicitly accepted concurrency behavior in the plan.

    Source Flow

  7. Report evidence Validate and report proven interleavings separately from unproved risks.

    Source Flow

Key rules

  • A finding needs a traced or reproduced interleaving across at least two actors.

    Source Evidence rules

  • Record an unproved candidate as a risk that cannot affect the gate.

    Source Evidence rules

  • Keep scope to schedules that go through added or changed lines.

    Source Evidence rules

  • Describe a pass as no proven problem, never as a guarantee of safety.

    Source Evidence rules

Output and gate

Output

  • Write validated concurrency findings and a report with the concrete actor schedule.

    Source Output

Gate

  • A proven concurrent defect makes the review fail.

    Source Gate rule (REVIEW concurrency focus)

  • Without a proven defect the review may pass, while unproved risks stay listed.

    Source Gate rule (REVIEW concurrency focus)

Source

Source Skill definition

← All skills