claim-sweep: the pr-sweep sibling that owns claim staleness (#286)

[bdelanghe]

Closes #286

claim-ticket.yml's own header already named this file as the fix:

"Releasing a claim = remove the claimed label (and unassign). Nothing expires stale claims yet; if that starts to hurt, it is a scheduled sweep in the board-parity family, not more logic here."

The measured problem

Against the live API on 2026-08-29:

Claims on finished work, org-wide	114 (92 in this repo + .github-private)
Open claims past the 14-day window, no linked PR	3 (.github-private #373, #372, #314)
Open PRs anywhere	0 — the PR backlog is drained; the claim backlog is not

The claim doors write the claimed label and nothing removes it, so the count only grows. claims.bounded.tools renders it as "114 finished, still labelled" and says outright it "only grows until someone drains it."

.github-private#435 is the standing record of the same class. This closes its label half.

What this adds

claim-sweep.yml, built as the pr-sweep.yml sibling — weekly cron (a real run, per the #713 standing decision) plus dispatch with dry-run default. Per claimed issue, in order:

1. Exempt — a standing claim, at any age.
2. Release iff the issue is closed, whatever closed it. A claim on a closed issue guards nothing.
3. Release iff open, no linked open PR, untouched for stale_days (default 14 — claims are leases on attention, shorter than the 30-day PR window).
4. Keep everything else, reason printed.

Release = label removal + unassign + one comment naming the run. That is exactly what every claim record already instructs; this makes the convention a mechanism.

The standing-claim exemption is load-bearing

#273, #274, #278, #279, #280 here and .github-private#731 are held by machine lanes so pr-claim has an open, claimed issue to resolve. They are open, PR-less, and never refresh — precisely the shape rule 3 deletes. .github-private#731 predicts this sweep by name:

"a standing claim never refreshes, so any wall-clock expiry (#717) would expire it first."

This sweep is #717. Without the exemption its first cron breaks every machine lane in the org — for the three fan-out lanes, in ~86 repos at once. Those six issues were all created or last touched on 08-29, so they age past the 14-day window around 2026-09-12; the exemption had to be in place before then, and now is.

Two guards, because one was not enough:

• Keyed on a label (standing-claim), not on parsing a machine/* claimant out of hand-written comment prose, which is not a checkable interface.
• The staleness rule refuses to run in any repo where that label does not exist, and says why in a warning. If no standing claim there can be marked, rule 3 is not safe to apply. Rule 2 is unaffected — a standing claim is open by construction, so releasing claims on closed issues can never touch one.

Unassign failure is reported, never fatal — the label is the half pr-claim reads, so its removal is what ends the claim; the assignee is a human-facing projection and must not be load-bearing.

Rollout

• Create the standing-claim label in bounded-systems/.github and bounded-systems/.github-private — done; auto-created on first use, currently default grey (ededed) with no description.
• Apply it to Standing claim: org-defaults.yml — the bootstrap pin bump lane #273, Standing claim: registry-graph.yml — the profile knowledge-graph sync lane #274, Standing claim: reroll-claude-harness — the harness baseline re-roll lane #278, Standing claim: adopt-claude-harness — the harness adoption lane #279, Standing claim: front-desk-reroll — the front-desk check-in re-roll lane #280 and .github-private#731 — done and verified: all six now carry claimed + standing-claim, with claimed and existing assignees preserved.
• [settings] Register the claim-sweep broker entry pinned to this workflow at refs/heads/main, with issues. Until then cross-repo runs fail at mint naming the gap — the intended arrival state; same-repo runs work on the workflow's own token.
• Cosmetic: give the standing-claim label a colour and the description "Held by a machine lane, not a session — never released by claim-sweep." No label-update API was available to this session.

Verification

• node --test *.test.mjs — 254 pass
• node --test .claude/*.test.mjs — 207 pass
• node --test workflows.test.mjs — 93 pass

The workflow ratchet earned its keep: it rejected the first draft because the release comment had prose at column 0 inside a run: block — a leaked block scalar. Rebuilt with jq -nc, the way _claim.yml does it.

Not yet run against live data — workflow_dispatch only exposes workflows present on the default branch, so the first dry run has to follow the merge rather than precede it. Projected from the same API data the table above came from, that run should read: 92 WOULD RELEASE (closed issues), 6 exempt, 10 keep.

Noted, not fixed here

Door 1 (claim-ticket.yml) exposes no release input — only .github-private's claim.yml does. So releasing a claim on an issue in this repo has no mechanized door today, which is part of why the label never comes off by hand either. Out of scope for this PR rather than widened into it.

Parts 2 (claim feed in front-desk-feed) and 3 (claims.bounded.tools in desk) of .github-private#717 live in other repos. Part 3's page already exists, so that part is likely reconciliation.