claim-sweep: make the door a reusable, and emit the claim-activity dispatch (#290)

[bdelanghe]

Closes #290

Two changes, both consequences of the lane shipping in #286/#288 and then meeting reality.

1. The door becomes a reusable

claim-sweep.yml shipped with a cross-repo fan-out: a repo input (or *) and a token minted through the OIDC broker under a claim-sweep entry.

That entry does not exist. Measured, not inferred — dispatching the merged lane at .github-private returns:

broker refused to mint for app 'claim-sweep' (HTTP 404): unknown app: claim-sweep

So the lane worked on exactly one repository: the one it lives in. I had asserted this from reading the workflow header and then tested it, because a gate's own claim about itself is not evidence (docs/agentic-code-hygiene.md rule 3).

_claim-sweep.yml runs against the caller's github.repository with the caller's GITHUB_TOKEN. issues: write is exactly what releasing a claim uses — the same argument _claim.yml's header makes for why that door alone travels. No broker entry, no fan-in App growing issues: write, and adoption becomes a short caller instead of an infra grant.

It is also the shape this org has converged on twice. _claim.yml records what the alternative cost: "copy this file" produced copies that drifted, one of which left issues labelled claimed with no comment naming anyone — unheld, unclaimable, clearable only by hand (.github-private#652). _pr-claim.yml is the same pattern.

Behaviour moves across verbatim: the four rules in order, the standing-claim exemption, both fail-closed guards, comment-before-label ordering, and the one-request unassign with its non-fatal warning. The -d→--input correction from #288 travels with the reason recorded at the call site, so nobody reintroduces it by reading _claim.yml's correct curl -d as a house idiom.

Caller drops 297 lines → 72.

2. The claim-activity sender that nothing was emitting

front-desk-feed's publish lane already accepts repository_dispatch: types: [pr-activity, claim-activity]. The type was added in front-desk-feed#6 for exactly this, and that header names the gap:

"No sender emits claim-activity yet; the claim doors are the natural one, since they are the only things that know a claim changed."

This is a claim door. After a real sweep it is the only thing in the org that knows a batch of claims stopped being claims.

Why it matters, measured three times. The feed's 35 * * * * cron is best-effort and GitHub drops slots under load — a denser cron is skipped more often:

• 2026-08-28, PRs: six slots between 06:35 and 12:35 produced nothing; the page served 3 open for 6.5h after the last PR merged.
• 2026-08-28, claims: seven released ~21:20–21:35Z, listed as live work — one already closed and merged — until a hand dispatch at 22:38Z.
• 2026-08-29, today: the .github sweep released 23 at 16:59Z; the page still read 114 at 17:04Z and moved to 92 only after this session dispatched publish.yml by hand.

Fires only when something changed: never on a dry run, never when a real run released nothing — otherwise the weekly no-op cron spends a publish run republishing an identical feed. continue-on-error, because the release already happened and is already correct; a failed notification costs freshness, not truth.

Inert until provisioned, the same posture the receiving half shipped with. repository_dispatch needs contents: write on the target, which a caller's GITHUB_TOKEN does not carry cross-repo, so it wants a broker binding-plane entry bounded by an installation on that repo alone. Absent feed_dispatch_token the step prints a notice and exits 0.

The token is checked in the shell, not in the if. The secrets context's availability in a step conditional is the kind of thing that evaluates to something surprising rather than erroring, and #289 is the standing record of shipping a branch no dry run reaches. An empty env var is unambiguous on every runner.

The payload carries no issue-derived data and no repo name — every event produces the same whole-board reprojection so there is nothing to branch on, and a caller may be private while the receiver's logs are world-readable.

Evidence the behaviour is right

Run 33264394589 on the pre-refactor file, against .github:

claim-sweep: released 23, kept 0, exempted 5 claim(s) across .github.

All five standing claims printed exempt (standing claim). claims.bounded.tools moved 114 → 92 once the feed republished. Only the plumbing changed here.

Verification

• node --test *.test.mjs — 256 pass (up from 254; two tests auto-cover the new workflow)
• node --test .claude/*.test.mjs — 207 pass
• node --test workflows.test.mjs — 95 pass (up from 93)
• grep confirms no gh api … -d anywhere in either file

Rollout

• standing-claim label created in both repos and applied to all six standing claims.
• [settings] broker binding-plane entry that can mint contents: write on front-desk-feed, to activate the sender.
• A caller in .github-private (.github-private#765) — its 69 finished claims were drained by hand in the meantime, via the REST API rather than 69 workflow runs, because that repo is ~1 day from a projected Actions budget stop (.github-private#705, #467).

Related: #286, #288, #289, .github-private#717, #765, front-desk-feed#5, desk#22.

---

Generated by Claude Code