Repository navigation
Say which machine holds a Claim #833
Description
From the #711 grilling, Q23 (c). Two machines run thirdshift, thirdshift and stephens, and both pick up from some of the same repositories, thirdshift and clave among them. Each Console shows only its own machine's Commands (#776) and links to the others. But GitHub alone can't answer "which machine is working on this issue?": a Claim is just the in-progress label.
Wanted: the Claim says which machine took the issue, so the issue on GitHub answers it. Today:
- The Pickup reservation on origin (ADR 0017,
refs/heads/thirdshift/pickup/<n>) has a commit message naming the Launch directory, process and start time, but not the machine. - thirdshift already knows its hostname, and uses it in Run notifications and failed-run commits.
Options to weigh:
- a comment on the issue when it's Claimed, naming the machine and the Command (and edited when it ends);
- the hostname added to the Pickup reservation's commit message;
- a label per machine, such as
on:stephens. That's probably too noisy.
Open questions:
- Should a Run started by hand on an Issue URL say so too, or only Pickup runs?
- Is a comment per Claim too noisy on issues that get picked up many times?
- Should the Console link a Command to the other machine's Console when it isn't local?
Activity
JacobStephens2 commentedon Oct 20, 2026
Another reason for the Claim comment: say how the run ended
A Claim kept after a Failed run looks the same on GitHub as a run still in progress. Educational-Travel-Adventures/tourbot#880 kept
in-progressafter a Pickup run on 2026-10-20 that failed after 34s withTickets not done: #883. Nothing on the issue said it had stopped. You could only tell from the notification email.If the Claim comment is edited when the Claim ends, as this issue already suggests, it could also say how the run ended:
originandready-for-agentwent back on.Then the issue answers "is the factory still working on this?" without changing what the Claim means.
in-progressstays on, so the Claim limit and the hand-back label history work as they do now. Swappingin-progressfor a triage label when a run fails was considered and rejected for those two reasons.Related: #884 (Pickup passes over a Spec with no Ticket it can start) would have stopped the #880 run from happening at all.
JacobStephens2 commentedon Oct 25, 2026
Triage: the trivial, reversible slice (recording
Host:in the Pickup reservation) is split out as #1328. This staysneeds-triagefor the Claim-comment questions (post one and edit it with the outcome? also on direct Runs?). I'd grill it together with #1165, #585, #710, #959 and #960, which all concern how a Claim lives and ends.JacobStephens2 commentedon Nov 9, 2026
Partly covered by Spec #1901 (Ticket #1904): when a Run ends
agent-failed, its issue gets a generated Recovery comment that names the machine. Nothing names the machine while a Run is live, so this stays open for that. The Fleet Console (#1769) also shows every listed machine's live Commands.JacobStephens2 commentedon Nov 10, 2026
Investigation summary
What's left of this issue is naming the machine on GitHub while a Run is live. The other parts have been split out or covered elsewhere.
Already done or decided (confirmed):
refs/heads/thirdshift/pickup/<n>now recordsHost: <hostname>(src/reservation.rs:68-71). It covers only Pickup runs and sits on a git ref, not on the issue page.in-progressmarks only a live Run #1901 (open), ADR 0029:in-progressmarks only a live Run, and each ending is marked by labels (agent-failed,ready-for-agenton a waiting Spec, nothing at ready for review). This covers the 2026-10-20 comment's "say how the run ended". Spec:in-progressmarks only a live Run #1901's Out of Scope lists "Naming the machine that holds a live Claim (Say which machine holds a Claim #833)".agent-failedgets a generated Recovery comment naming the machine. I found no caller that posts it on this Base, so it may not have landed onmainyet (inference).Code facts (confirmed on Base):
src/run.rs(make_claim→claim::make) and ended inclaim.end(ending)(src/claim.rs).GitHub::comment_issue(src/github.rs:319) only posts a comment. No edit-comment API exists, so editing a Claim comment when the Claim ends would need a new GitHub operation and a fake-ghseam.crate::host::name()(src/host.rs) already supplies the hostname to notifications, the Console, logs and the reservation.Still open (Day shift decisions): whether to name the machine during a live Run at all, how to do it, which Commands do it, and how to keep issues that are claimed many times from filling with comments. See the questionnaire.
Suggested minimal slice if approved: when the Claim is made, post one AI-attributed comment naming the machine and the Command (no edit, no local paths), for every Command that makes a Claim. Test it through the fake
ghintegration tests by asserting the recorded comment.Questionnaire
Questions for the Day shift: naming the machine that holds a live Claim (#833)
Context: two machines (
thirdshiftandstephens) pick up from the same repositories. The Pickup reservation ref now recordsHost:(#1328). Spec #1901 makesin-progressmean only a live Run and marks each ending by labels. Failed Runs get a Recovery comment naming the machine (#1904). The Fleet Console (#1769) shows every machine's live Commands. The issue page itself still doesn't say which machine is working on a live Claim, and a Run started by hand records its machine nowhere on GitHub.Host:line cover it? (If they cover it, Say which machine holds a Claim #833 closes as done.)on:stephenswere already judged too noisy. Note that (b) needs a new edit-comment GitHub operation, and Spec:in-progressmarks only a live Run #1901 already shows the ending through labels and the Recovery comment.If the answer is form (a) for every Claim-making Command, the work is one ready-for-agent Ticket.