Fencing
Status: open/active · Aliases: lease fencing, fence token, fencing check
Definition
Section titled “Definition”A read-only check that a lease holder is still the legitimate owner before it acts. The holder
presents the lease_id it believes it holds; the check compares that against the current lease on
the task ref. A match means proceed; a mismatch means a newer holder has the lease and the caller
has been fenced out and must stop. It stops two workers from acting on the same task at once.
Contrast
Section titled “Contrast”Fencing is not the lease itself. The lease is the exclusive claim on a task; fencing is the gate
that asks “do I still hold it?” before a side effect. The fence_token (the lease_id carried in
the PR footer) is the credential the check compares; fencing is the comparison.
The check is the sdlc lease task fence <task-id> --expect-lease <lease-id> op — side-effect-free,
never mutating a ref. Three outcomes:
- Match →
LEASE-FENCING-OK(exit 0). The caller proceeds. - Mismatch →
LEASE-FENCING-MISMATCH expected=<footer> actual=<discovered>on stderr, exit 0. The lease rotated since the PR opened; the caller is a stale holder and stops. - Missing →
LEASE-MISSING ref=refs/sdlc/tasks/<task-id>(exit 5). No active lease exists.
/sdlc:pr-respond runs it before acting on a task PR. The pattern is the distributed-systems
fencing token: a lease carries a unique id, and the holder proves currency before any side effect.
See conventions/lease-aware-skills.md §4b and the lease ADR’s
Fencing and PR↔lease binding section.