Add issue/PR work leases so multiple LLMs cannot accidentally do the same work #267

Closed
opened 2026-07-06 12:49:34 -05:00 by jcwalker3 · 2 comments
Owner

Multiple LLM sessions can accidentally work on the same issue or PR because “open issue” is not enough state to prove work is available. A task may already have an active branch, dirty worktree, pushed remote branch, open PR, recovery branch, or recent handoff. Without a hard claim/lease system, another LLM can start duplicate work and create branch/PR/worktree cleanup debt.

Observed risk:

  • Branches can appear stale/no PR while still containing the only copy of unmerged work.
  • Dirty recovery branches can be mistaken for cleanup candidates.
  • Open PR heads must be protected from unrelated cleanup.
  • Multiple LLMs may select the same issue from the queue if there is no enforceable lease.
  • Review and author sessions can collide when one is fixing while another is reviewing.

Required behavior:
Before any LLM starts coding, reviewing, fixing, creating a branch, creating a PR, or mutating an issue, it must acquire or verify an operation-scoped work lease.

Lease types:

  • author_issue_work
  • review_pr_work
  • fix_pr_changes
  • cleanup_branch_work
  • issue_filing_work
  • recovery_work

Required preflight:
For the target issue/PR, check:

  • existing open PRs linked to the issue,
  • branches matching the issue number,
  • dirty worktrees matching the issue or branch,
  • remote branches matching the issue number,
  • recent issue/PR comments or handoffs showing active work,
  • existing active lease,
  • merged PRs that may already complete the issue.

Acceptance criteria:

  1. LLM cannot start work on an issue if an active lease exists for the same issue and operation.
  2. LLM cannot start work on an issue if an open PR already exists unless the task is explicitly to review or fix that PR.
  3. LLM cannot create a second branch for the same issue unless the previous branch is proven abandoned or superseded.
  4. LLM cannot delete or clean up a branch if it has an active lease, dirty worktree, open PR, or is the only copy of unmerged work.
  5. Leases include:
    • issue number,
    • PR number if applicable,
    • branch,
    • worktree path,
    • operation type,
    • claimant identity/profile,
    • created timestamp,
    • expiry timestamp,
    • last heartbeat timestamp.
  6. Expired leases require recovery review before takeover.
  7. A takeover must produce a handoff explaining why the prior lease is abandoned, completed, or unsafe.
  8. Tests cover duplicate author work, duplicate review work, author/reviewer collision, stale branch recovery, dirty worktree protection, and expired lease takeover.
  9. Documentation explains the lease lifecycle and required stop messages.
  10. No prompt-only rule is sufficient; the resolver/preflight must enforce the lease.

Non-goals:

  • Do not allow author profiles to approve, request changes, or merge.
  • Do not allow reviewer profiles to mutate author branches unless exact capability allows it.
  • Do not auto-delete branches just because leases expire.
Multiple LLM sessions can accidentally work on the same issue or PR because “open issue” is not enough state to prove work is available. A task may already have an active branch, dirty worktree, pushed remote branch, open PR, recovery branch, or recent handoff. Without a hard claim/lease system, another LLM can start duplicate work and create branch/PR/worktree cleanup debt. Observed risk: * Branches can appear stale/no PR while still containing the only copy of unmerged work. * Dirty recovery branches can be mistaken for cleanup candidates. * Open PR heads must be protected from unrelated cleanup. * Multiple LLMs may select the same issue from the queue if there is no enforceable lease. * Review and author sessions can collide when one is fixing while another is reviewing. Required behavior: Before any LLM starts coding, reviewing, fixing, creating a branch, creating a PR, or mutating an issue, it must acquire or verify an operation-scoped work lease. Lease types: * `author_issue_work` * `review_pr_work` * `fix_pr_changes` * `cleanup_branch_work` * `issue_filing_work` * `recovery_work` Required preflight: For the target issue/PR, check: * existing open PRs linked to the issue, * branches matching the issue number, * dirty worktrees matching the issue or branch, * remote branches matching the issue number, * recent issue/PR comments or handoffs showing active work, * existing active lease, * merged PRs that may already complete the issue. Acceptance criteria: 1. LLM cannot start work on an issue if an active lease exists for the same issue and operation. 2. LLM cannot start work on an issue if an open PR already exists unless the task is explicitly to review or fix that PR. 3. LLM cannot create a second branch for the same issue unless the previous branch is proven abandoned or superseded. 4. LLM cannot delete or clean up a branch if it has an active lease, dirty worktree, open PR, or is the only copy of unmerged work. 5. Leases include: * issue number, * PR number if applicable, * branch, * worktree path, * operation type, * claimant identity/profile, * created timestamp, * expiry timestamp, * last heartbeat timestamp. 6. Expired leases require recovery review before takeover. 7. A takeover must produce a handoff explaining why the prior lease is abandoned, completed, or unsafe. 8. Tests cover duplicate author work, duplicate review work, author/reviewer collision, stale branch recovery, dirty worktree protection, and expired lease takeover. 9. Documentation explains the lease lifecycle and required stop messages. 10. No prompt-only rule is sufficient; the resolver/preflight must enforce the lease. Non-goals: * Do not allow author profiles to approve, request changes, or merge. * Do not allow reviewer profiles to mutate author branches unless exact capability allows it. * Do not auto-delete branches just because leases expire.
jcwalker3 added the status:in-progress label 2026-07-07 04:31:03 -05:00
Author
Owner

Implementation PR opened: #386 (branch feat/issue-267-work-leases, head 0cc3ed8868442fc7b3298676f76c18224b9f9dcd).

Stalled-claim adoption note: this branch was authored and pushed at 05:35 today by an earlier session that stopped before opening a PR (claim label present, no claim comment, no PR). This session adopted the stalled work without adding commits: validated the head (1202 passed; single failure is the pre-existing #359 base failure, fixed on master by PR #364), ran a clean merge simulation against master 7b71113 (1317 passed; single failure is the standing master failure in test_final_report_validator), re-locked, and opened PR #386.

Scope: author_issue_work lease enforcement in gitea_lock_issue (4h TTL, fail-closed active-lease block, expired-lease recovery takeover, remote-branch reuse), tests, and runbook/wiki docs. Heartbeat lease tooling continues separately in #268 / PR #370. Awaiting reviewer.

Implementation PR opened: #386 (branch `feat/issue-267-work-leases`, head `0cc3ed8868442fc7b3298676f76c18224b9f9dcd`). **Stalled-claim adoption note:** this branch was authored and pushed at 05:35 today by an earlier session that stopped before opening a PR (claim label present, no claim comment, no PR). This session adopted the stalled work without adding commits: validated the head (1202 passed; single failure is the pre-existing #359 base failure, fixed on master by PR #364), ran a clean merge simulation against master `7b71113` (1317 passed; single failure is the standing master failure in `test_final_report_validator`), re-locked, and opened PR #386. Scope: `author_issue_work` lease enforcement in `gitea_lock_issue` (4h TTL, fail-closed active-lease block, expired-lease recovery takeover, remote-branch reuse), tests, and runbook/wiki docs. Heartbeat lease tooling continues separately in #268 / PR #370. Awaiting reviewer.
Author
Owner

Evidence update — PR #393 / Issue #390 showed branch/worktree ownership and cleanup confusion.

The author handoff for Issue #390 reported a cross-session collision: a concurrent session co-built in the same worktree, committed 91c6793, opened PR #393, then the original session replaced/expanded tests and pushed a2bd23d as the final PR head.

This is a branch/worktree ownership and reconciliation risk:

  • two sessions wrote to the same issue worktree
  • one session opened the PR while another still had uncommitted/superset work
  • final head ownership became ambiguous
  • cleanup/reconciliation needs to know which worktree/session/branch is active before another session writes or cleans it

Expected cleanup/reconciliation behavior:

  • identify local worktrees tied to open PR branches
  • identify owner/session/heartbeat if available
  • prevent concurrent write access to the same worktree
  • classify worktrees with active PRs as owned, not generic cleanup candidates
  • after merge, verify remote branch and local worktree cleanup candidates with proof
Evidence update — PR #393 / Issue #390 showed branch/worktree ownership and cleanup confusion. The author handoff for Issue #390 reported a cross-session collision: a concurrent session co-built in the same worktree, committed `91c6793`, opened PR #393, then the original session replaced/expanded tests and pushed `a2bd23d` as the final PR head. This is a branch/worktree ownership and reconciliation risk: - two sessions wrote to the same issue worktree - one session opened the PR while another still had uncommitted/superset work - final head ownership became ambiguous - cleanup/reconciliation needs to know which worktree/session/branch is active before another session writes or cleans it Expected cleanup/reconciliation behavior: - identify local worktrees tied to open PR branches - identify owner/session/heartbeat if available - prevent concurrent write access to the same worktree - classify worktrees with active PRs as owned, not generic cleanup candidates - after merge, verify remote branch and local worktree cleanup candidates with proof
sysadmin removed the status:in-progress label 2026-07-07 09:52:39 -05:00
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Scaled-Tech-Consulting/Gitea-Tools#267