offsite — an issue whose deliverable is a PR in another repo

[dan-claude-bot]

Filed from the sherpa session at @danmt's request, who has already agreed to
a new label for this. A proposal for triage to mint under epic #56 — not a
ruling, and not a claim on anyone's work.

#57 landed the linkage rule this morning: a builder working outside its issue's
repo writes Part of <owner>/<repo>#N and comments the draft link on the
authorizing issue. That is the human-readable half, and it works. This is the
machine-readable half, and it is missing — with a live consequence.

The bug

hygiene.sh runs triage's hourly backlog sweep with this instruction:

reclaim claimed issues with no open PR and no recent activity

and it sweeps repos.txt, which is heavy-duty/ceremony. An issue whose
deliverable lives in another repo has no open PR in ceremony by
construction. So a cross-repo claim is shaped exactly like an abandoned one,
and the only thing standing between it and reclamation is comment traffic.

Two issues are in that shape right now:

issue	claimed by	deliverable	open PR in ceremony?
#13 Convert rig	@claude-bot-andresmgsl	heavy-duty/rig#112 (merged 11:58Z)	no
#16 Adopt in incubator	@claude-bot-andresmgsl	dan-claude-bot/incubator#89 (draft)	no

Nothing has misfired, because both saw activity today. That is luck, not a
guard: #16's PR has not moved since 01:20Z, so it is roughly 38 hours from
being reclaimed out from under a builder that is merely blocked, not gone. And
reclamation is not a cheap mistake — it unassigns the owner and flips the issue
back to ready, inviting a second builder onto work that already exists.

This is the same failure family LABELS.md has already solved three times:
blocked skips the staleness sweep, and so does needs-ruling, both because
waiting is legitimately quiet. A cross-repo claim is legitimately quiet in
exactly the same way — the work is loud, just somewhere else.

Proposal

A cross-cutting label, alongside blocked and needs-ruling:

Label	Colour	Meaning
offsite	grey family, near blocked	the deliverable is a PR in another repo; this issue has no local PR by design. Set by the builder when it opens the cross-repo PR, cleared when that PR merges or closes. The staleness sweep skips it.

Following needs-ruling's precedent in every respect that matters: the machine
reads it and never writes it; it coexists with the queue labels rather than
competing with them; and its setter clears it, in the same comment that reports
the outcome, never as a side effect.

BUILDER.md needs the corresponding two lines — set it in the same step that
posts the draft link, clear it in the handoff. #57 would have been the natural
home for that edit; it closed at 11:37Z, so this needs its own.

What this is not

Not state:needs-human on the issue. That was the first shape I proposed to
@danmt and it is wrong. state:needs-human is one of four mutually exclusive
PR states meaning "this PR could be merged right now", and LABELS.md is
explicit about why widening it is a trap: "the retired state:needs-rebase is
the family's proof that a label meaning two things lies about both."

Not a notification mechanism. notify.sh could watch ceremony alone if
issues carried this flag, instead of polling five repos every fifteen minutes.
That is a saving of about four API calls a quarter-hour and it is not a
reason to add doctrine. The staleness bug is the reason; the polling saving is
a side effect, and if the label is added it should not be justified by it.

Open questions

1. Name. offsite reads as a property of the issue ("don't expect a PR
   here"), which is what the sweep needs to know. cross-repo describes the
   mechanism instead. Doctrine leans toward meaning-names — merge-next,
   needs-ruling — which is why offsite is proposed, but the name is the
   part I hold least firmly.
2. Does it suppress anything else? The staleness skip is the point. Whether
   it should also affect the epic-completion nudge is a real question and I do
   not have a view.
3. Should the sweep verify rather than trust? A label saying "the PR is
   elsewhere" can go stale — the PR merges, nobody clears it, the issue is
   exempt forever. The linkage line Part of <owner>/<repo>#N is structured
   enough to resolve, and GitHub records a cross-referenced timeline event on
   the issue when a PR in another repo names it, so the sweep could confirm the
   claim instead of taking it. That is more work than the label and may belong
   in a follow-up rather than in the first cut.

[danmt]

1. offsite is fine as a name. 2. well, i dont really know how important would it be the epic-completion nudge, if you find it important please do so. 3. we can verify, but only if we already trust so we dont have to verify everything. (not sure if that makes sense)

[dan-claude-bot]

Accepted. Two issues minted under epic #56, and this discussion is done.

• offsite — the label, the doctrine, and the claim-reclaim exemption #68 — offsite: the label, the doctrine, the exemption. Blocked by needs-ruling in the sweep — staleness skip, bare-flag detection, the 7-day nudge #52 (its PR feat(labels): needs-ruling sweep invariants — staleness skip, bare-flag check, 7-day nudge #64 rewrites the exact line this extends).
• issueflow-reconcile — the offsite stale-flag nudge, from cross-referenced timeline events #69 — the stale-flag nudge. Blocked by offsite — the label, the doctrine, and the claim-reclaim exemption #68.

Your three answers, as built:

1. Name — offsite.
2. Epic-completion nudge — no interaction to build. The nudge fires when an epic's children are closed; an offsite child is open, so it can't suppress anything. Recorded as a decision so nobody builds it later.
3. Verify vs trust — it makes sense, and it's the design: the label alone stops the reclaim clock, no proof required. issueflow-reconcile — the offsite stale-flag nudge, from cross-referenced timeline events #69 then reads the timeline the sweep already fetches, and only comments when every visible cross-repo PR has closed. It never clears the flag and never reclaims. Can't-see-it means silence, not a verdict — which is what will happen on Adopt in incubator — the greenfield consumer #16, since ceremony's token can't see a private fork's cross-references.

One correction to my own filing: I blamed hygiene.sh. Wrong file. The reclaim that actually runs on this board is claim_decision in issueflow-reconcile.sh — in-repo, and the real deliverable. hygiene.sh lives inside the triage box and is yours; #68 writes the spec line for it and doesn't pretend to fix it.

Also unchanged from the filing: the notify.sh polling saving is not a reason for any of this, and #68 says so explicitly.