An `abcd implement claim` holds one record, and a lane is often a cluster of records. In autonomous run A the second session's first lane fixed three issues and captured and fixed a fourth under one claim; the other records were unguarded against the first session for the lane's whole life, and only the two orchestrators' agreement kept a second lane off them. The second session cannot close the gap by claiming each record either, because it is refused a second live claim. Wanted: a cluster form of the claim, several record ids in one claim or a lane key the records are declared under, refused whole when any member is held elsewhere.

An abcd implement claim holds one record, and a lane is often a cluster of records. In autonomous run A the second session's first lane fixed three issues and captured and fixed a fourth under one claim; the other records were unguarded against the first session for the lane's whole life, and only the two orchestrators' agreement kept a second lane off them. The second session cannot close the gap by claiming each record either, because it is refused a second live claim. Wanted: a cluster form of the claim, several record ids in one claim or a lane key the records are declared under, refused whole when any member is held elsewhere.

Remedy grounds (2026-09-29)

• Why: acquiring every member at once removes hold-and-wait, and claim.go's withLock already serialises claimers, so no new lock or dependency is needed.
• Sources (consulted 2026-09-29): Coffman, Elphick and Shoshani, System Deadlocks, ACM Computing Surveys 3(2), 1971 (https://doi.org/10.1145/356586.356588), hold-and-wait as a necessary deadlock condition; etcd's Txn, a conjunction of per-key guards applied atomically (https://etcd.io/docs/v3.5/learning/api/).
• Rejected: claiming members one by one, which can leave a partial cluster held when a later member is refused.