From eae9b2866d840d6102b9b5bdb56e9b85c5395fe9 Mon Sep 17 00:00:00 2001 From: Jacob Stephens Date: Tue, 27 Oct 2026 12:19:27 -0400 Subject: [PATCH 1/9] Grill #1165: resume Round 1, covering #1388's Custom-process Delivery --- docs/grill-with-docs/1165-claim-labels.md | 91 +++++++++++++++++++++++ 1 file changed, 91 insertions(+) create mode 100644 docs/grill-with-docs/1165-claim-labels.md diff --git a/docs/grill-with-docs/1165-claim-labels.md b/docs/grill-with-docs/1165-claim-labels.md new file mode 100644 index 000000000..896aeea4e --- /dev/null +++ b/docs/grill-with-docs/1165-claim-labels.md @@ -0,0 +1,91 @@ +# Grilling: #1165, in-progress stays on issues whose Run has ended + +Issue: https://github.com/JacobStephens2/thirdshift/issues/1165 +Research: [proposed direction](https://github.com/JacobStephens2/thirdshift/issues/1165#issuecomment-6369972244), #585, #710, #833 + +Paused 2026-10-23 with Round 1 unanswered; resumed 2026-10-27. Round 1 is revised in place for what landed since: a Custom process's Delivery now removes the Claim at ready for review (#1388, in Q1.2), and #977, #978 and #981 have closed (Q1.3). `GLOSSARY.md` is unchanged so far: its **Claim**, **Claim limit**, **Sweep** and **Ready issue** entries wait on Q1.1–Q1.3. + +Already agreed in chat (2026-10-23), before Round 1: + +- A **Failed run** that leaves work on `origin` swaps `in-progress` for a new label, `run-failed`, instead of keeping its Claim. +- `run-failed` does not count toward `pickup.limit`. Q1.1 questions this. +- A Spec run that stops only for the Day shift gets `ready-for-human` in place of `in-progress`, not `run-failed`. Q1.3 questions this. +- Still open: Recovery on the issue (Q1.4) and Ready for review (Q1.2). + +## Round 1 (open) + +**Q1.1 - What stops Pickup working through every Ready issue when every Run fails?** The glossary gives the **Claim limit** two jobs: "It keeps a broken **Base branch** from failing every **Ready issue** in turn, and pull requests from piling up unreviewed." Today a Failed run keeps its Claim, so failures fill the limit and Pickup stops. With `run-failed` left out of the limit, the brake is gone. Picture a broken Base branch with `base.fix` off, or a Harness outage like today's Grok `402 Payment Required`, which failed 48 Commands on stephens.page. A Pickup run every 10 minutes would then label one Ready issue after another `run-failed`, and the Day shift would have to hand each back. The options: +- (a) Accept it. Inherited failures and the Base fix cover the broken Base branch, and Harness outages are rare. +- (b) Count `run-failed` toward the Claim limit after all, which takes back answer 1. +- (c) A separate **Failure limit** in the User config, say `pickup.failure_limit`, default 3. Pickup is skipped while the repository has that many open `run-failed` issues. Failures don't use up live slots, but they do stop the line. +- (d) Pickup is skipped after N Failed runs in a row that Pickup dispatched on the repository, until the Day shift hands one back. + +*Recommended:* (c). It keeps answer 1's point, that a failure isn't a live Run, while keeping the brake. It is also easy to read: the skip line can name the `run-failed` issues holding it, as the Claim limit's names its Claims (#787). (d) catches more, but needs a way to reset that the Day shift would have to learn. Note that a failure that leaves nothing on `origin`, such as a Harness that fails at the first session, releases its Claim to `ready-for-agent` today. Pickup can take that same issue again on its next pass, and no label brakes it under any option. Is that a separate issue? + +*Answer:* + +**Q1.2 - What label does a Run whose pull request waits for review leave?** A Ticket run or Spec run keeps `in-progress` (`Goal::ReadyForReview` ends the Claim with no change, in `src/claim.rs`). That is half of what made the label untrustworthy: #1043, #965 and #957 all looked live. The Claim limit's second job, stopping unreviewed pull requests from piling up, relies on these issues counting. Since 2026-10-26, though, a **Custom process**'s Delivery does the opposite: it removes `in-progress` at ready for review and puts nothing back (`Claim::remove`, #1388). So the same ending now leaves two different labels depending on which Command ran, and Custom-process pull requests already escape the Claim limit. Whichever option wins applies to both. The options: +- (a) Keep `in-progress`, and make the Custom process keep it too, undoing that part of #1388. The limit still works, but the label still overstates live work. +- (b) Swap it for a new label, `in-review`, on both paths. It is still a Claim and still counts toward the Claim limit. `in-progress` then means a live Run and nothing else. +- (c) Take the label off on both paths, as the Custom process already does, and let the open pull request stand for the work. The limit then no longer brakes unreviewed pull requests. + +*Recommended:* (b). It is the only option where the issue list answers "what is running?" and the Claim limit keeps both of its jobs. `in-review` mirrors `in-progress` and stays clear of the `ready-for-*` triage roles. The three issues relabelled by hand on 2026-10-23 would get `in-review`. #1388 chose removal so that Pickup would not take the issue again while its pull request is open; `in-review` gives that too, since the issue carries no `ready-for-agent`. + +*Answer:* + +**Q1.3 - Which label does a Spec run that is only waiting leave on its Spec?** The agreed answer is `ready-for-human`. Two cases test it. +- **Waiting on another Spec's ordinary work.** #978's undone Tickets wait on #1014, a Ticket in #977. If #977 were still running, with nothing gated on a human, #978 would end "Tickets not done" with no failure and no human action needed. `ready-for-human` would be wrong for it. +- **Waiting on a human gate.** Pickup already passes over a Spec with no **Startable Ticket**. A Spec labelled `ready-for-agent` whose Tickets are all gated or blocked therefore stays put on its own, and Pickup continues it once a Ticket becomes startable. The `ready-for-human` work the Day shift owed was on the Tickets themselves: #1009, #1011, #1018 and #1019. (All of these, and #977, #978 and #981, have since closed, so they are worked examples now, not live ones.) + +The options: +- (a) `ready-for-human` on the Spec when every undone Ticket is an **Unready Ticket**, or is blocked, in any Spec, only behind ones. A Spec waiting only on ordinary work elsewhere gets `run-failed`. +- (b) thirdshift puts `ready-for-agent` back on any Spec whose undone Tickets are all waiting, gated or blocked, and the **Ready issue** rule accepts it as a handback. The Spec continues on its own once the Day shift clears a gate or a blocker closes, and only the Tickets carry `ready-for-human`. +- (c) (a) for human gates, (b) for waiting on other work. + +In every option, a Spec run with any failed Ticket gets `run-failed`, as #585 proposes. + +*Recommended:* (b). The Day shift does one thing, clearing the Ticket's gate, rather than two, clearing it and then handing the Spec back. The `ready-for-human` list then shows exactly the work that is human: Tickets, not Specs. This reverses the chat answer, so say if the Spec itself should still show it. The cost: the Ready issue rule gains an exception. Today a started issue is Ready again only after a Day shift handback, and with (b) thirdshift could make a waiting Spec Ready itself. + +*Answer:* + +**Q1.4 - Does a Failed run post its Recovery on the issue?** **Recovery** lines are built only from factory-owned facts. Today they reach only the command log on the host that ran the Run and, if asked for, the Run notification. A `run-failed` label on GitHub would say that a Run failed, but not why or what to do. The repository is public, and Recovery lines include the host's paths (for #977, `/home/jacob/repos/thirdshift`) and the full continue command. The options: +- (a) A comment on the issue at each Failed run: the cause, where it stopped, what was preserved (the branch and pull request), and how to retry ("apply `ready-for-agent`"). It names the host, as #833 asks, but no local paths and no continue command. +- (b) The full Recovery lines, paths and command included. +- (c) No comment. The label points the Day shift to `thirdshift status` on the hosts. + +*Recommended:* (a). Handing back with `ready-for-agent` makes the host-specific continue command unnecessary, since Pickup on any host continues on the kept branch. The comment then needs only what GitHub can act on. A Run that fails again posts again, which also leaves a history of its attempts. + +*Answer:* + +## Settled by earlier answers (shout if any is wrong) + +- **Interrupted runs:** a Failed run ended by interruption, not by a Stop, with work on `origin`, gets `run-failed` too. The glossary already counts interruption as a Failed run. +- **Failed Security fixes:** a failed Security fix gets `run-failed` even with nothing on `origin`, instead of keeping its Claim, since it already stays with the Day shift today. +- **Unchanged endings:** a Stop still leaves `needs-triage`. A Failed run with nothing on `origin` still releases its Claim to `ready-for-agent`. +- **Pickup:** it never takes a `run-failed` issue, because a Ready issue needs `ready-for-agent`. The Day shift retries by applying `ready-for-agent`, which the Ready issue rule already accepts as a handback after the last Claim ended. Pickup then starts a **Continuation** on the kept Issue branch and pull request. +- **Label upkeep:** making a Claim takes `run-failed` off, and the **Sweep** takes it off closed issues, as both do for `in-progress`. +- **Tickets:** a Ticket's Run makes no Claim, so it gets no label of its own. Its Spec carries the outcome. +- **Out of scope:** a Run killed outright never ends its Claim (#710). +- **Glossary:** **Claim**, **Claim limit**, **Sweep** and **Ready issue** in `GLOSSARY.md` change once Round 1 settles the Claim limit (Q1.1), what counts as a Claim (Q1.2) and the handback rule (Q1.3). + +## Research results (2026-10-23) + +- The **Claim limit**'s two stated jobs are stopping a broken Base branch failing every Ready issue in turn, and stopping unreviewed pull requests piling up. Confirmed by `GLOSSARY.md`. +- A **Spec** with no **Startable Ticket** is not a **Ready issue**, so Pickup already passes over a waiting Spec. Confirmed by `GLOSSARY.md` (Startable Ticket, from #884). +- An **Unready Ticket** carries `ready-for-human`, `needs-info`, `wontfix` or `needs-triage`. Confirmed by `GLOSSARY.md`. +- `Claim::end` leaves the labels as they are on `Goal::ReadyForReview` and on a failed Security fix, releases only when nothing is on `origin`, and removes the Claim once the issue is closed after a merge. Confirmed by source, `src/claim.rs:231`. +- Pickup counts open `in-progress` issues for the Claim limit, and the Sweep removes `in-progress` from closed issues. Confirmed by source, `src/pickup.rs:241` and `src/pickup.rs:263`. +- `JacobStephens2/thirdshift` is public. Confirmed by `gh repo view`. +- #977, #978 and #981 all ended "Tickets not done", waiting on #977's four `ready-for-human` Tickets (#1009, #1011, #1018, #1019) through #1014 and #1029. Confirmed by `thirdshift status --json` and the #977 command log on stephens.page. +- #585 (open, `needs-triage`) proposes a distinct waiting outcome for Spec runs and asks what Claim behaviour it should have. Q1.3 answers that part. Confirmed by the issue. + +## Research results (2026-10-27) + +- A Custom process's Delivery that leaves a ready-for-review pull request removes `in-progress` and puts nothing back, so the issue is neither Ready nor counted by the Claim limit. Confirmed by source, `Claim::remove` in `src/claim.rs` (commit 944a9766, #1388). +- The glossary's **Claim** entry still says a Claim stays while its pull request is ready for review, with no exception for a Custom process. Confirmed by `GLOSSARY.md:39`. It gets fixed with the Q1.2 rewrite. +- #977, #978, #981 and Tickets #1009, #1011, #1018 and #1019 are all closed, so no Spec needs `ready-for-agent` put back by hand. Confirmed by `gh issue view`. +- Open `in-progress` issues today: #1446, #1443, #1252. Confirmed by `gh issue list --label in-progress`. + +## Waiting on research + +- Nothing. From cf54291bead6b4b1337646661a2b9e4416094203 Mon Sep 17 00:00:00 2001 From: Jacob Stephens Date: Mon, 9 Nov 2026 12:43:55 -0500 Subject: [PATCH 2/9] Grill #1165: revise Round 1 for agent-failed and the Failure limit --- docs/grill-with-docs/1165-claim-labels.md | 106 +++++++++++----------- 1 file changed, 55 insertions(+), 51 deletions(-) diff --git a/docs/grill-with-docs/1165-claim-labels.md b/docs/grill-with-docs/1165-claim-labels.md index 896aeea4e..8d3e29b7d 100644 --- a/docs/grill-with-docs/1165-claim-labels.md +++ b/docs/grill-with-docs/1165-claim-labels.md @@ -1,90 +1,94 @@ # Grilling: #1165, in-progress stays on issues whose Run has ended Issue: https://github.com/JacobStephens2/thirdshift/issues/1165 -Research: [proposed direction](https://github.com/JacobStephens2/thirdshift/issues/1165#issuecomment-6369972244), #585, #710, #833 +Research: [proposed direction](https://github.com/JacobStephens2/thirdshift/issues/1165#issuecomment-6369972244), #585, #710, #833, [#1532 grill](1532-keep-working-the-backlog.md) -Paused 2026-10-23 with Round 1 unanswered; resumed 2026-10-27. Round 1 is revised in place for what landed since: a Custom process's Delivery now removes the Claim at ready for review (#1388, in Q1.2), and #977, #978 and #981 have closed (Q1.3). `GLOSSARY.md` is unchanged so far: its **Claim**, **Claim limit**, **Sweep** and **Ready issue** entries wait on Q1.1–Q1.3. +Paused 2026-10-23 with Round 1 unanswered. Revised in place on 2026-10-27, and again on 2026-11-09, after the #1532 grill and Spec #1564 shipped the `agent-failed` label and the **Failure limit** in place of the **Claim limit**. Q1.1 is withdrawn, Q1.2–Q1.4 are rewritten for the new labels, and Q1.5 is new. `GLOSSARY.md` is unchanged so far: its **Claim**, **Failure limit**, **Sweep** and **Ready issue** entries wait on Q1.2, Q1.3 and Q1.5. -Already agreed in chat (2026-10-23), before Round 1: +Agreed in chat on 2026-10-23, before Round 1, and where each stands now: -- A **Failed run** that leaves work on `origin` swaps `in-progress` for a new label, `run-failed`, instead of keeping its Claim. -- `run-failed` does not count toward `pickup.limit`. Q1.1 questions this. -- A Spec run that stops only for the Day shift gets `ready-for-human` in place of `in-progress`, not `run-failed`. Q1.3 questions this. -- Still open: Recovery on the issue (Q1.4) and Ready for review (Q1.2). +- A **Failed run** that leaves work on `origin` swaps `in-progress` for a new label, `run-failed`. *Now:* #1564 added `agent-failed` for this case, but next to `in-progress` rather than in its place. Q1.5 asks whether to finish the swap. +- `run-failed` does not count toward the limit. *Now:* the reverse shipped. `agent-failed` is exactly what the Failure limit counts (Q1.1, withdrawn). +- A Spec run that stops only for the Day shift gets `ready-for-human`, not a failure label. Q1.3 questions this. ## Round 1 (open) -**Q1.1 - What stops Pickup working through every Ready issue when every Run fails?** The glossary gives the **Claim limit** two jobs: "It keeps a broken **Base branch** from failing every **Ready issue** in turn, and pull requests from piling up unreviewed." Today a Failed run keeps its Claim, so failures fill the limit and Pickup stops. With `run-failed` left out of the limit, the brake is gone. Picture a broken Base branch with `base.fix` off, or a Harness outage like today's Grok `402 Payment Required`, which failed 48 Commands on stephens.page. A Pickup run every 10 minutes would then label one Ready issue after another `run-failed`, and the Day shift would have to hand each back. The options: -- (a) Accept it. Inherited failures and the Base fix cover the broken Base branch, and Harness outages are rare. -- (b) Count `run-failed` toward the Claim limit after all, which takes back answer 1. -- (c) A separate **Failure limit** in the User config, say `pickup.failure_limit`, default 3. Pickup is skipped while the repository has that many open `run-failed` issues. Failures don't use up live slots, but they do stop the line. -- (d) Pickup is skipped after N Failed runs in a row that Pickup dispatched on the repository, until the Day shift hands one back. +**Q1.1 - What stops Pickup working through every Ready issue when every Run fails?** *Withdrawn 2026-11-09, settled by the #1532 grill.* Pickup now counts open `agent-failed` issues against `pickup.failure_limit`, default 3. A broken Base branch or Harness stops the line after three failures, and pull requests waiting for review never count. One gap was left open here, and it is still open. A failure with nothing on `origin` releases its Claim to `ready-for-agent` and gets no `agent-failed`, so Pickup can take the same issue again on its next pass. See "Settled by earlier answers". -*Recommended:* (c). It keeps answer 1's point, that a failure isn't a live Run, while keeping the brake. It is also easy to read: the skip line can name the `run-failed` issues holding it, as the Claim limit's names its Claims (#787). (d) catches more, but needs a way to reset that the Day shift would have to learn. Note that a failure that leaves nothing on `origin`, such as a Harness that fails at the first session, releases its Claim to `ready-for-agent` today. Pickup can take that same issue again on its next pass, and no label brakes it under any option. Is that a separate issue? +**Q1.2 - What label does a Run whose pull request waits for review leave?** A Ticket run or Spec run keeps `in-progress` (`Goal::ReadyForReview` and a held **Self-merge** leave the labels alone, `src/claim.rs:349`). A **Custom process**'s Delivery removes `in-progress` and puts nothing back (`Claim::remove`, #1388). The same ending therefore leaves different labels depending on which Command ran. When this was first asked, `in-progress` on these issues did a job, because the Claim limit counted them to stop unreviewed pull requests piling up. #1532 dropped that job on purpose: "a pull request that is ready for review or merged never counts, so the factory keeps working while reviews wait." Nothing counts these issues now. Two more facts bear on this. The Console's Inbox lists them under Ready for review, across the **Fleet**. And on pull requests, `in-progress` already means a live reservation that a **Review run** or **Fix run** takes off when it ends. The options: +- (a) Keep `in-progress` on both paths, which undoes that part of #1388. The label still overstates live work. +- (b) A new `in-review` label on both paths. It counts toward nothing, so it would be for reading only. +- (c) Take `in-progress` off on both paths, as the Custom process already does. The open pull request stands for the work. Pickup still won't take the issue again, because a started issue is a **Ready issue** only after a handback. -*Answer:* - -**Q1.2 - What label does a Run whose pull request waits for review leave?** A Ticket run or Spec run keeps `in-progress` (`Goal::ReadyForReview` ends the Claim with no change, in `src/claim.rs`). That is half of what made the label untrustworthy: #1043, #965 and #957 all looked live. The Claim limit's second job, stopping unreviewed pull requests from piling up, relies on these issues counting. Since 2026-10-26, though, a **Custom process**'s Delivery does the opposite: it removes `in-progress` at ready for review and puts nothing back (`Claim::remove`, #1388). So the same ending now leaves two different labels depending on which Command ran, and Custom-process pull requests already escape the Claim limit. Whichever option wins applies to both. The options: -- (a) Keep `in-progress`, and make the Custom process keep it too, undoing that part of #1388. The limit still works, but the label still overstates live work. -- (b) Swap it for a new label, `in-review`, on both paths. It is still a Claim and still counts toward the Claim limit. `in-progress` then means a live Run and nothing else. -- (c) Take the label off on both paths, as the Custom process already does, and let the open pull request stand for the work. The limit then no longer brakes unreviewed pull requests. - -*Recommended:* (b). It is the only option where the issue list answers "what is running?" and the Claim limit keeps both of its jobs. `in-review` mirrors `in-progress` and stays clear of the `ready-for-*` triage roles. The three issues relabelled by hand on 2026-10-23 would get `in-review`. #1388 chose removal so that Pickup would not take the issue again while its pull request is open; `in-review` gives that too, since the issue carries no `ready-for-agent`. +*Recommended:* (c). With no limit counting these issues, a second label would only repeat what the open pull request and the Inbox already show. Under (c), `in-progress` means one thing on issues and on pull requests: a live Run. It also makes the Ticket and Spec paths match what #1388 shipped. An issue whose Self-merge merged but whose closing failed keeps its Claim as it does today, since that is a finish still owed, not a review. *Answer:* -**Q1.3 - Which label does a Spec run that is only waiting leave on its Spec?** The agreed answer is `ready-for-human`. Two cases test it. -- **Waiting on another Spec's ordinary work.** #978's undone Tickets wait on #1014, a Ticket in #977. If #977 were still running, with nothing gated on a human, #978 would end "Tickets not done" with no failure and no human action needed. `ready-for-human` would be wrong for it. -- **Waiting on a human gate.** Pickup already passes over a Spec with no **Startable Ticket**. A Spec labelled `ready-for-agent` whose Tickets are all gated or blocked therefore stays put on its own, and Pickup continues it once a Ticket becomes startable. The `ready-for-human` work the Day shift owed was on the Tickets themselves: #1009, #1011, #1018 and #1019. (All of these, and #977, #978 and #981, have since closed, so they are worked examples now, not live ones.) - -The options: -- (a) `ready-for-human` on the Spec when every undone Ticket is an **Unready Ticket**, or is blocked, in any Spec, only behind ones. A Spec waiting only on ordinary work elsewhere gets `run-failed`. -- (b) thirdshift puts `ready-for-agent` back on any Spec whose undone Tickets are all waiting, gated or blocked, and the **Ready issue** rule accepts it as a handback. The Spec continues on its own once the Day shift clears a gate or a blocker closes, and only the Tickets carry `ready-for-human`. +**Q1.3 - What does a Spec run that is only waiting leave on its Spec?** This matters more now than when first asked. A Spec run whose undone Tickets are all gated or blocked ends with `Tickets not done: #22 (labelled ready-for-human)` (`src/spec_run.rs:457`). That makes it a **Failed spec run**, so it keeps its Claim and gets `agent-failed`. Three such waiting Specs would stop Pickup on the repository under the Failure limit, though nothing is broken. Pickup already passes over a Spec with no **Startable Ticket**, so a Spec labelled `ready-for-agent` whose Tickets are all gated stays put on its own, and Pickup continues it once a Ticket becomes startable. The options: +- (a) `ready-for-human` on the Spec, with no `agent-failed`, when every undone Ticket is an **Unready Ticket** or is blocked only behind ones. A Spec waiting on ordinary work elsewhere, such as a Ticket in another running Spec, gets `agent-failed`. +- (b) thirdshift puts `ready-for-agent` back on any Spec whose undone Tickets are all gated, waiting or blocked, with no `agent-failed`. The **Ready issue** rule accepts that as a handback. The Spec continues on its own once the Day shift clears a gate or a blocker closes, and only the Tickets carry `ready-for-human`. - (c) (a) for human gates, (b) for waiting on other work. -In every option, a Spec run with any failed Ticket gets `run-failed`, as #585 proposes. +In every option, a Spec run with a failed or interrupted Ticket gets `agent-failed`, as #585 proposes. -*Recommended:* (b). The Day shift does one thing, clearing the Ticket's gate, rather than two, clearing it and then handing the Spec back. The `ready-for-human` list then shows exactly the work that is human: Tickets, not Specs. This reverses the chat answer, so say if the Spec itself should still show it. The cost: the Ready issue rule gains an exception. Today a started issue is Ready again only after a Day shift handback, and with (b) thirdshift could make a waiting Spec Ready itself. +*Recommended:* (b), with one guard. The Day shift does one thing, clearing the Ticket's gate, not two. The `ready-for-human` list then shows exactly the work that is human: Tickets, not Specs. The guard comes from the **Trusted account** rule. A Ready issue needs its latest `ready-for-agent` labelling by a Trusted account, with no edit since by an account that is not one. If thirdshift relabelled the Spec itself, as the owner's account, it would clear an untrusted edit made in between. So thirdshift puts `ready-for-agent` back only if no such edit has happened since the Day shift's last labelling. Otherwise the Spec gets `needs-triage`. This reverses the chat answer, so say if the Spec itself should still show `ready-for-human`. *Answer:* -**Q1.4 - Does a Failed run post its Recovery on the issue?** **Recovery** lines are built only from factory-owned facts. Today they reach only the command log on the host that ran the Run and, if asked for, the Run notification. A `run-failed` label on GitHub would say that a Run failed, but not why or what to do. The repository is public, and Recovery lines include the host's paths (for #977, `/home/jacob/repos/thirdshift`) and the full continue command. The options: -- (a) A comment on the issue at each Failed run: the cause, where it stopped, what was preserved (the branch and pull request), and how to retry ("apply `ready-for-agent`"). It names the host, as #833 asks, but no local paths and no continue command. +**Q1.4 - Does a Failed run post its Recovery on the issue?** **Recovery** lines are built only from factory-owned facts. They reach the command log, the Run notification if one is configured, and the Console's Needs you. Since #1769, one Console shows Needs you for every machine in its **Fleet**, which covers most of #833's "which host?" for the Day shift. On GitHub, `agent-failed` says only that a Run failed, not why or what to do next. thirdshift already posts issue comments elsewhere: Base branch CI reports, and Triage runs, which say "This comment was generated by AI." The repository is public, and Recovery lines include the host's paths and the full continue command. A comment from the owner's account is from a Trusted account, so the next session on the issue would be given it. The options: +- (a) A comment on the issue at each Failed run, marked as generated. It gives the cause, where the Run stopped, what was kept (the branch and pull request), the host, and how to retry ("apply `ready-for-agent`"). No local paths and no continue command. - (b) The full Recovery lines, paths and command included. -- (c) No comment. The label points the Day shift to `thirdshift status` on the hosts. +- (c) No comment. `agent-failed` sends the Day shift to the Fleet Console. + +*Recommended:* (a), but only just over (c). The Console covers the Day shift, but only on machines in its Fleet. The comment serves anyone reading the issue on GitHub, and it hands the next Continuation session a factual account of where the last Run stopped. A Run that fails again posts again, which leaves a history of attempts. Pick (c) if you would rather keep factory chatter off issues. -*Recommended:* (a). Handing back with `ready-for-agent` makes the host-specific continue command unnecessary, since Pickup on any host continues on the kept branch. The comment then needs only what GitHub can act on. A Run that fails again posts again, which also leaves a history of its attempts. +*Answer:* + +**Q1.5 - Does a failed Run that keeps its Claim still keep `in-progress` next to `agent-failed`?** This is the heart of #1165, now that #1564 has shipped. Today a Failed run with work on `origin` leaves both labels, so `in-progress` still doesn't mean "running". The pre-Round-1 answer was to swap one for the other, but it now runs into a #1532 rule (Q3.3 there, `src/pickup.rs:423`). Pickup reads an open issue with `agent-failed` and neither `in-progress` nor `needs-triage` as the Day shift having taken it over, and takes `agent-failed` off. Swap the labels without changing that rule, and the next Pickup run would clear every failure, so the brake would never hold. The options: +- (a) Swap: a Failed run that keeps its Claim takes `in-progress` off and leaves `agent-failed`. The take-over signal becomes taking `agent-failed` off, or closing the issue. Putting `ready-for-agent` back still counts as acting, as today. The Q3.3 "took `in-progress` off" rule goes, and so does the case where `in-progress` itself is the label being taken off. +- (b) Keep both. `in-progress` means "Claimed", and "running" is `in-progress` without `agent-failed`, a search you'd run as `label:in-progress -label:agent-failed`. + +*Recommended:* (a). That is what #1165 asks for, and with Q1.2 (c) it leaves `in-progress` on an issue only while a Run is live. The take-over act gets simpler too: you remove the label that names the failure. The cost is a change to a rule shipped two weeks ago, and existing failed issues need `in-progress` taken off once, which the Sweep could do. *Answer:* ## Settled by earlier answers (shout if any is wrong) -- **Interrupted runs:** a Failed run ended by interruption, not by a Stop, with work on `origin`, gets `run-failed` too. The glossary already counts interruption as a Failed run. -- **Failed Security fixes:** a failed Security fix gets `run-failed` even with nothing on `origin`, instead of keeping its Claim, since it already stays with the Day shift today. -- **Unchanged endings:** a Stop still leaves `needs-triage`. A Failed run with nothing on `origin` still releases its Claim to `ready-for-agent`. -- **Pickup:** it never takes a `run-failed` issue, because a Ready issue needs `ready-for-agent`. The Day shift retries by applying `ready-for-agent`, which the Ready issue rule already accepts as a handback after the last Claim ended. Pickup then starts a **Continuation** on the kept Issue branch and pull request. -- **Label upkeep:** making a Claim takes `run-failed` off, and the **Sweep** takes it off closed issues, as both do for `in-progress`. -- **Tickets:** a Ticket's Run makes no Claim, so it gets no label of its own. Its Spec carries the outcome. +- **#1165 still stands.** The Fleet Console's Working group shows live Runs, but only on machines in that Fleet. Anyone reading GitHub, and both hosts, see the labels. +- **Interrupted runs:** a Failed run ended by interruption, not by a Stop, with work on `origin`, is treated like any other Failed run. The glossary already counts interruption as a Failed run. +- **Failed Security fixes:** these keep their Claim even with nothing on `origin` and get `agent-failed` today. Whatever Q1.5 decides applies to them too. +- **Unchanged endings:** a Stop still leaves `needs-triage`. A bug Ticket run that can't reproduce still leaves `needs-info`. +- **A failure with nothing on `origin`** still releases to `ready-for-agent` with no `agent-failed`, so Pickup can retry it at once and nothing brakes it. That is out of scope here, and gets its own issue if you want one. +- **Pickup:** it never takes an `agent-failed` issue, because a Ready issue needs `ready-for-agent`. The Day shift retries by applying `ready-for-agent`, and Pickup then starts a **Continuation** on the kept Issue branch and pull request. +- **Label upkeep:** making a Claim takes `agent-failed` off, and the **Sweep** takes both labels off closed issues. Both already ship. +- **Tickets:** a Ticket run inside a Spec run makes no Claim, so its Spec carries the outcome. - **Out of scope:** a Run killed outright never ends its Claim (#710). -- **Glossary:** **Claim**, **Claim limit**, **Sweep** and **Ready issue** in `GLOSSARY.md` change once Round 1 settles the Claim limit (Q1.1), what counts as a Claim (Q1.2) and the handback rule (Q1.3). +- **Glossary:** **Claim** changes with Q1.2 and Q1.5 (it also still omits the Custom process exception from #1388). **Failure limit** changes with Q1.5's take-over rule, and **Ready issue** with Q1.3's handback. ## Research results (2026-10-23) -- The **Claim limit**'s two stated jobs are stopping a broken Base branch failing every Ready issue in turn, and stopping unreviewed pull requests piling up. Confirmed by `GLOSSARY.md`. -- A **Spec** with no **Startable Ticket** is not a **Ready issue**, so Pickup already passes over a waiting Spec. Confirmed by `GLOSSARY.md` (Startable Ticket, from #884). +- `Claim::end` leaves the labels as they are on `Goal::ReadyForReview` and on a failed Security fix, releases only when nothing is on `origin`, and removes the Claim once the issue is closed after a merge. Confirmed by source, `src/claim.rs`. +- A **Spec** with no **Startable Ticket** is not a **Ready issue**, so Pickup already passes over a waiting Spec. Confirmed by `GLOSSARY.md`. - An **Unready Ticket** carries `ready-for-human`, `needs-info`, `wontfix` or `needs-triage`. Confirmed by `GLOSSARY.md`. -- `Claim::end` leaves the labels as they are on `Goal::ReadyForReview` and on a failed Security fix, releases only when nothing is on `origin`, and removes the Claim once the issue is closed after a merge. Confirmed by source, `src/claim.rs:231`. -- Pickup counts open `in-progress` issues for the Claim limit, and the Sweep removes `in-progress` from closed issues. Confirmed by source, `src/pickup.rs:241` and `src/pickup.rs:263`. - `JacobStephens2/thirdshift` is public. Confirmed by `gh repo view`. -- #977, #978 and #981 all ended "Tickets not done", waiting on #977's four `ready-for-human` Tickets (#1009, #1011, #1018, #1019) through #1014 and #1029. Confirmed by `thirdshift status --json` and the #977 command log on stephens.page. -- #585 (open, `needs-triage`) proposes a distinct waiting outcome for Spec runs and asks what Claim behaviour it should have. Q1.3 answers that part. Confirmed by the issue. +- #585 (open, `needs-triage`) proposes a distinct waiting outcome for Spec runs. Q1.3 answers the label part. Confirmed by the issue. ## Research results (2026-10-27) -- A Custom process's Delivery that leaves a ready-for-review pull request removes `in-progress` and puts nothing back, so the issue is neither Ready nor counted by the Claim limit. Confirmed by source, `Claim::remove` in `src/claim.rs` (commit 944a9766, #1388). -- The glossary's **Claim** entry still says a Claim stays while its pull request is ready for review, with no exception for a Custom process. Confirmed by `GLOSSARY.md:39`. It gets fixed with the Q1.2 rewrite. -- #977, #978, #981 and Tickets #1009, #1011, #1018 and #1019 are all closed, so no Spec needs `ready-for-agent` put back by hand. Confirmed by `gh issue view`. -- Open `in-progress` issues today: #1446, #1443, #1252. Confirmed by `gh issue list --label in-progress`. +- A Custom process's Delivery that leaves a ready-for-review pull request removes `in-progress` and puts nothing back. Confirmed by source, `Claim::remove` in `src/claim.rs` (commit 944a9766, #1388). +- #977, #978, #981 and their Tickets #1009, #1011, #1018 and #1019 are all closed. Confirmed by `gh issue view`. + +## Research results (2026-11-09) + +- The **Failure limit** replaced the **Claim limit**. A Failed ticket run or Failed spec run that keeps its Claim gets `agent-failed`, next to `in-progress`, and Pickup counts open `agent-failed` issues against `pickup.failure_limit`, default 3. A ready or merged pull request never counts. Confirmed by `GLOSSARY.md` (Failure limit), `src/claim.rs:30-40` and `docs/grill-with-docs/1532-keep-working-the-backlog.md` (Q1.1, Q2.5, Q3.3). +- Pickup takes `agent-failed` off an open issue that has `ready-for-agent`, or that has neither `in-progress` nor `needs-triage`. Confirmed by source, `src/pickup.rs:391-423`. +- The **Command limit** now caps live Commands per repository per machine, separately from failures. Confirmed by `GLOSSARY.md`. +- A Spec run whose undone Tickets are gated or blocked fails with "Tickets not done: …", so it gets `agent-failed`. Confirmed by source, `src/spec_run.rs:457` and its tests. +- **Review runs** and **Fix runs** put `in-progress` on a pull request only while they are live, and Pass selection skips `in-progress` pull requests. The Sweep takes `in-progress` off closed pull requests. Confirmed by `GLOSSARY.md` (Review run, Fix run, Sweep). +- One Console now shows, and can stop and dismiss, the Commands of every machine in its **Fleet**, Needs you included (#1769). Confirmed by `GLOSSARY.md` (Console, Fleet, Needs you). +- thirdshift already posts issue comments: Base branch CI reports (`src/github/base_ci.rs:571`) and Triage run links (`src/triage.rs:429`, marked "This comment was generated by AI."). Confirmed by source. +- Sessions are given an issue's comments by Trusted accounts only. Confirmed by `GLOSSARY.md` (Trusted account). +- Open `in-progress` issues on 2026-10-27: #1446, #1443, #1252. Not re-checked. ## Waiting on research From 78b29782cf61e4a9c6c79d046376c54cd2aec154 Mon Sep 17 00:00:00 2001 From: Jacob Stephens Date: Mon, 9 Nov 2026 16:30:09 -0500 Subject: [PATCH 3/9] Grill #1165: revise Round 1 for Spec #1695, #1583 and #585 --- docs/grill-with-docs/1165-claim-labels.md | 28 +++++++++++++++-------- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/docs/grill-with-docs/1165-claim-labels.md b/docs/grill-with-docs/1165-claim-labels.md index 8d3e29b7d..840faf851 100644 --- a/docs/grill-with-docs/1165-claim-labels.md +++ b/docs/grill-with-docs/1165-claim-labels.md @@ -1,9 +1,9 @@ # Grilling: #1165, in-progress stays on issues whose Run has ended Issue: https://github.com/JacobStephens2/thirdshift/issues/1165 -Research: [proposed direction](https://github.com/JacobStephens2/thirdshift/issues/1165#issuecomment-6369972244), #585, #710, #833, [#1532 grill](1532-keep-working-the-backlog.md) +Research: [proposed direction](https://github.com/JacobStephens2/thirdshift/issues/1165#issuecomment-6369972244), #585, #710, #833, #1583, #1695, [#1532 grill](1532-keep-working-the-backlog.md) -Paused 2026-10-23 with Round 1 unanswered. Revised in place on 2026-10-27, and again on 2026-11-09, after the #1532 grill and Spec #1564 shipped the `agent-failed` label and the **Failure limit** in place of the **Claim limit**. Q1.1 is withdrawn, Q1.2–Q1.4 are rewritten for the new labels, and Q1.5 is new. `GLOSSARY.md` is unchanged so far: its **Claim**, **Failure limit**, **Sweep** and **Ready issue** entries wait on Q1.2, Q1.3 and Q1.5. +Paused 2026-10-23 with Round 1 unanswered. Revised in place on 2026-10-27, and twice on 2026-11-09: after the #1532 grill and Spec #1564 shipped the `agent-failed` label and the **Failure limit** in place of the **Claim limit**, and for Spec #1695, which gives Triage runs a Claim. Q1.1 is withdrawn, Q1.2–Q1.4 are rewritten for the new labels, and Q1.5 is new. `GLOSSARY.md` is unchanged so far: its **Claim**, **Failure limit**, **Sweep** and **Ready issue** entries wait on Q1.2, Q1.3 and Q1.5. Agreed in chat on 2026-10-23, before Round 1, and where each stands now: @@ -29,26 +29,29 @@ Agreed in chat on 2026-10-23, before Round 1, and where each stands now: - (b) thirdshift puts `ready-for-agent` back on any Spec whose undone Tickets are all gated, waiting or blocked, with no `agent-failed`. The **Ready issue** rule accepts that as a handback. The Spec continues on its own once the Day shift clears a gate or a blocker closes, and only the Tickets carry `ready-for-human`. - (c) (a) for human gates, (b) for waiting on other work. -In every option, a Spec run with a failed or interrupted Ticket gets `agent-failed`, as #585 proposes. +In every option, a Spec run with a failed or interrupted Ticket gets `agent-failed`, as #585 proposes. Two more cases from #585 are already happening on tourbot. In #880, the only open Ticket was `needs-info`, and the run "failed" after 34s. In #1689, one Ticket was `ready-for-human` and one sat in another repository, so no Spec run can start it. Both count as waiting here. A Ticket outside the Spec's repository is never a **Startable Ticket**, so Pickup passes over the Spec under (b) as well. #585 keeps its other decisions: the outcome name, exit code, notification wording and mixed results. This question decides only the labels. *Recommended:* (b), with one guard. The Day shift does one thing, clearing the Ticket's gate, not two. The `ready-for-human` list then shows exactly the work that is human: Tickets, not Specs. The guard comes from the **Trusted account** rule. A Ready issue needs its latest `ready-for-agent` labelling by a Trusted account, with no edit since by an account that is not one. If thirdshift relabelled the Spec itself, as the owner's account, it would clear an untrusted edit made in between. So thirdshift puts `ready-for-agent` back only if no such edit has happened since the Day shift's last labelling. Otherwise the Spec gets `needs-triage`. This reverses the chat answer, so say if the Spec itself should still show `ready-for-human`. *Answer:* -**Q1.4 - Does a Failed run post its Recovery on the issue?** **Recovery** lines are built only from factory-owned facts. They reach the command log, the Run notification if one is configured, and the Console's Needs you. Since #1769, one Console shows Needs you for every machine in its **Fleet**, which covers most of #833's "which host?" for the Day shift. On GitHub, `agent-failed` says only that a Run failed, not why or what to do next. thirdshift already posts issue comments elsewhere: Base branch CI reports, and Triage runs, which say "This comment was generated by AI." The repository is public, and Recovery lines include the host's paths and the full continue command. A comment from the owner's account is from a Trusted account, so the next session on the issue would be given it. The options: +**Q1.4 - Does a Failed run post its Recovery on the issue?** **Recovery** lines are built only from factory-owned facts. They reach the command log, the Run notification if one is configured, and the Console's Needs you. Since #1769, one Console shows Needs you for every machine in its **Fleet**, which covers most of #833's "which host?" for the Day shift. On GitHub, `agent-failed` says only that a Run failed, not why or what to do next. thirdshift already posts issue comments elsewhere: Base branch CI reports, and Triage runs, which say "This comment was generated by AI." #1695 adds a lot more of them: each triaged issue gets an AI-attributed Agent Brief, Questionnaire or closure comment. A #585 comment also asks for "a comment with the cause and Recovery line" on a waiting Spec. The repository is public, and Recovery lines include the host's paths and the full continue command. A comment from the owner's account is from a Trusted account, so the next session on the issue would be given it. The options: - (a) A comment on the issue at each Failed run, marked as generated. It gives the cause, where the Run stopped, what was kept (the branch and pull request), the host, and how to retry ("apply `ready-for-agent`"). No local paths and no continue command. - (b) The full Recovery lines, paths and command included. - (c) No comment. `agent-failed` sends the Day shift to the Fleet Console. -*Recommended:* (a), but only just over (c). The Console covers the Day shift, but only on machines in its Fleet. The comment serves anyone reading the issue on GitHub, and it hands the next Continuation session a factual account of where the last Run stopped. A Run that fails again posts again, which leaves a history of attempts. Pick (c) if you would rather keep factory chatter off issues. +*Recommended:* (a), a little more firmly than before, now that #1695 makes AI comments on issues routine. The Console covers the Day shift, but only on machines in its Fleet. The comment serves anyone reading the issue on GitHub, and it hands the next Continuation session a factual account of where the last Run stopped. A Run that fails again posts again, which leaves a history of attempts. Pick (c) if you would rather keep factory chatter off issues. *Answer:* -**Q1.5 - Does a failed Run that keeps its Claim still keep `in-progress` next to `agent-failed`?** This is the heart of #1165, now that #1564 has shipped. Today a Failed run with work on `origin` leaves both labels, so `in-progress` still doesn't mean "running". The pre-Round-1 answer was to swap one for the other, but it now runs into a #1532 rule (Q3.3 there, `src/pickup.rs:423`). Pickup reads an open issue with `agent-failed` and neither `in-progress` nor `needs-triage` as the Day shift having taken it over, and takes `agent-failed` off. Swap the labels without changing that rule, and the next Pickup run would clear every failure, so the brake would never hold. The options: -- (a) Swap: a Failed run that keeps its Claim takes `in-progress` off and leaves `agent-failed`. The take-over signal becomes taking `agent-failed` off, or closing the issue. Putting `ready-for-agent` back still counts as acting, as today. The Q3.3 "took `in-progress` off" rule goes, and so does the case where `in-progress` itself is the label being taken off. -- (b) Keep both. `in-progress` means "Claimed", and "running" is `in-progress` without `agent-failed`, a search you'd run as `label:in-progress -label:agent-failed`. +**Q1.5 - Does a failed Run that keeps its Claim still keep `in-progress` next to `agent-failed`?** This is the heart of #1165, now that #1564 has shipped. Today a Failed run with work on `origin` leaves both labels, so `in-progress` still doesn't mean "running". The pre-Round-1 answer was to swap one for the other, but it now runs into a #1532 rule (Q3.3 there, `src/pickup.rs:423`). Pickup reads an open issue with `agent-failed` and neither `in-progress` nor `needs-triage` as the Day shift having taken it over, and takes `agent-failed` off. Swap the labels without changing that rule, and the next Pickup run would clear every failure, so the brake would never hold. -*Recommended:* (a). That is what #1165 asks for, and with Q1.2 (c) it leaves `in-progress` on an issue only while a Run is live. The take-over act gets simpler too: you remove the label that names the failure. The cost is a change to a rule shipped two weeks ago, and existing failed issues need `in-progress` taken off once, which the Sweep could do. +**Spec #1695 already makes this swap, for Triage runs only.** It is being built now (Ticket #1891 is `ready-for-agent`). A failed Triage run on an issue replaces `in-progress` with `ready-for-human` plus `agent-failed`. #1695 then works around the rule above by adding a second take-over signal: the Sweep clears `agent-failed` once the Day shift removes `ready-for-human`. Left alone, that gives two take-over rules depending on which Command failed. #1583 (`ready-for-human`) asks the same about failed Custom process runs, which today keep `in-progress` and get `agent-failed`, like Ticket runs. The options: +- (a) Swap, with one take-over rule for every Command that fails while holding a Claim: Ticket, Spec, Custom process and Triage runs. The failure takes `in-progress` off and leaves `agent-failed`. You take an issue over by removing `agent-failed`, putting `ready-for-agent` back, or closing it. The #1532 "took `in-progress` off" rule goes, and #1695 drops its `ready-for-human` signal. Its failed Triage run still adds `ready-for-human`, but only so the Triage Pass passes over the issue. +- (b) Swap, and follow #1695 everywhere: a failure leaves `ready-for-human` plus `agent-failed`, and removing `ready-for-human` is the take-over. To retry a Ticket, you'd then take `ready-for-human` off and put `ready-for-agent` on, two edits, because `ready-for-human` makes an issue Unready. +- (c) Keep both labels on Ticket, Spec and Custom process runs, so "running" is `in-progress` without `agent-failed`. #1695's Triage runs stay the exception. + +*Recommended:* (a). That is what #1165 asks for, and with Q1.2 (c) it leaves `in-progress` on an issue only while a Run is live. A single take-over act, removing the label that names the failure, is easier to learn than one per kind of Command. It also answers #1583: a failed Custom process counts like any other failure. Under (b), `ready-for-human` would mean "human work" on some issues and "the factory failed" on others. **This is time-sensitive.** If you pick (a), #1891 should drop its `ready-for-human` take-over rule before it lands, so say so and I'll comment on #1891. The cost is a change to a rule shipped two weeks ago. Issues that already failed also need `in-progress` taken off once, which the Sweep could do. *Answer:* @@ -57,7 +60,8 @@ In every option, a Spec run with a failed or interrupted Ticket gets `agent-fail - **#1165 still stands.** The Fleet Console's Working group shows live Runs, but only on machines in that Fleet. Anyone reading GitHub, and both hosts, see the labels. - **Interrupted runs:** a Failed run ended by interruption, not by a Stop, with work on `origin`, is treated like any other Failed run. The glossary already counts interruption as a Failed run. - **Failed Security fixes:** these keep their Claim even with nothing on `origin` and get `agent-failed` today. Whatever Q1.5 decides applies to them too. -- **Unchanged endings:** a Stop still leaves `needs-triage`. A bug Ticket run that can't reproduce still leaves `needs-info`. +- **Unchanged endings:** a Stop still leaves `needs-triage`. #1695's Triage runs are the exception: they leave `ready-for-human`, since `needs-triage` is their own queue. A bug Ticket run that can't reproduce still leaves `needs-info`. +- **Triage runs hold a Claim** under #1695, so Q1.2–Q1.5 apply to them too, and the glossary's **Claim** entry gains them. - **A failure with nothing on `origin`** still releases to `ready-for-agent` with no `agent-failed`, so Pickup can retry it at once and nothing brakes it. That is out of scope here, and gets its own issue if you want one. - **Pickup:** it never takes an `agent-failed` issue, because a Ready issue needs `ready-for-agent`. The Day shift retries by applying `ready-for-agent`, and Pickup then starts a **Continuation** on the kept Issue branch and pull request. - **Label upkeep:** making a Claim takes `agent-failed` off, and the **Sweep** takes both labels off closed issues. Both already ship. @@ -89,6 +93,10 @@ In every option, a Spec run with a failed or interrupted Ticket gets `agent-fail - thirdshift already posts issue comments: Base branch CI reports (`src/github/base_ci.rs:571`) and Triage run links (`src/triage.rs:429`, marked "This comment was generated by AI."). Confirmed by source. - Sessions are given an issue's comments by Trusted accounts only. Confirmed by `GLOSSARY.md` (Trusted account). - Open `in-progress` issues on 2026-10-27: #1446, #1443, #1252. Not re-checked. +- Spec #1695 (`in-progress`) and its Ticket #1891 (`ready-for-agent`) give Triage runs a Claim. A failure replaces `in-progress` with `ready-for-human` plus `agent-failed`. A Stop leaves `ready-for-human`, or `needs-triage` with `--requeue`. The Sweep clears `agent-failed` once the Day shift removes `ready-for-human`. Confirmed by the issues' bodies. No pull request yet. +- #1583 (`ready-for-human`) asks whether a failed Custom process should get `agent-failed`. Today it does, through the same `Claim::end` path, and it keeps `in-progress`. Confirmed by the issue. +- #585 has two new cases: tourbot#880, whose only open Ticket was `needs-info`, and tourbot#1689, with one `ready-for-human` Ticket and one in another repository. Both runs failed with no Ticket failing. Confirmed by #585's comments. +- #1857 (closed): a Claim ending counts only same-repository pull requests as published, so a cross-repository one no longer stops a release. It doesn't affect these questions. Confirmed by the issue. ## Waiting on research From 18c57452ac645055fe5a943f67a2587b2f74aa61 Mon Sep 17 00:00:00 2001 From: Jacob Stephens Date: Mon, 9 Nov 2026 16:49:09 -0500 Subject: [PATCH 4/9] Grill #1165: record Round 1 answers, update the glossary, open Round 2 --- GLOSSARY.md | 8 +-- docs/grill-with-docs/1165-claim-labels.md | 83 +++++++++++++++++++---- 2 files changed, 73 insertions(+), 18 deletions(-) diff --git a/GLOSSARY.md b/GLOSSARY.md index ed302d981..603653958 100644 --- a/GLOSSARY.md +++ b/GLOSSARY.md @@ -27,7 +27,7 @@ An issue scoping one session of work, standing alone or as a sub-issue of a **Sp _Avoid_: task, sub-task **Ready issue**: -An open issue a **Pickup run** may take: labelled `ready-for-agent`, written by a **Trusted account**, with its most recent `ready-for-agent` labelling made by a Trusted account and no edit to its title or body since then by an account that is not one, with no label that makes an **Unready Ticket** and no **Claim**, not a sub-issue, not a **Base fix**'s or a **Security run**'s fix issue, with no open blocker, either never started (no **Issue branch** and no pull request) or handed back by the **Day shift** applying `ready-for-agent` at or after the last **Claim** ended, as recorded in its label history, not a **Spec** whose **Tickets** are all closed, left untouched long enough that whoever is shaping it has finished, and, if it is a Spec, with a **Startable Ticket**. A hand-back made in the same edit as the Claim's removal counts in either listed order at that timestamp; a Claim applied at the same timestamp leaves the issue Claimed. On a Spec, the label says its Tickets are published. A `ready-for-agent` Ticket inside a Spec is not one: it is reached through its Spec, when the Spec is itself a Ready issue. +An open issue a **Pickup run** may take: labelled `ready-for-agent`, written by a **Trusted account**, with its most recent `ready-for-agent` labelling made by a Trusted account and no edit to its title or body since then by an account that is not one, with no label that makes an **Unready Ticket** and no **Claim**, not a sub-issue, not a **Base fix**'s or a **Security run**'s fix issue, with no open blocker, either never started (no **Issue branch** and no pull request) or handed back at or after the last **Claim** ended, as recorded in its label history: by the **Day shift** applying `ready-for-agent`, or by thirdshift putting it back on a Spec whose Spec run ended only waiting, which it does only when no account that is not a Trusted account has edited the Spec since its last `ready-for-agent` labelling, and otherwise labels the Spec `needs-triage`, not a **Spec** whose **Tickets** are all closed, left untouched long enough that whoever is shaping it has finished, and, if it is a Spec, with a **Startable Ticket**. A hand-back made in the same edit as the Claim's removal counts in either listed order at that timestamp; a Claim applied at the same timestamp leaves the issue Claimed. On a Spec, the label says its Tickets are published. A `ready-for-agent` Ticket inside a Spec is not one: it is reached through its Spec, when the Spec is itself a Ready issue. _Avoid_: queued issue, backlog item **Trusted account**: @@ -40,11 +40,11 @@ An open **Ticket** labelled with a triage role that says it is not agent work: ` An open **Ticket** in its **Spec**'s repository, with no sub-issues of its own, no open blocker, and not an **Unready Ticket**: one a **Spec run** could start if no Ticket were running. A Spec run starts only these, and a **Spec** with none is not a **Ready issue**. **Claim**: -The mark that the factory has taken an issue: thirdshift labels the issue `in-progress`, in place of `ready-for-agent` if it has that, when a **Ticket run** or a **Spec run** starts on it, whether started on its **Issue URL** or by an **Architect run**, a **Pickup run** or a **Security run**. A **Ticket run** in a Spec run and a **Base fix** make none. Ending a Claim finishes even after Command interruption. A failed Security fix keeps its Claim even with nothing on `origin`, so it stays with the Day shift. For other Ticket runs, a Claim is released, `ready-for-agent` put back, only when the Ticket run ends with nothing on `origin` to take over and was not ended by a **Stop**: no **Issue branch** and no pull request. Otherwise it stays while the issue is open, whether its pull request is ready for review or the Ticket run failed, until the **Day shift** relabels it, and thirdshift takes the label off once the issue is closed. A bug Ticket run that cannot reproduce the bug ends its Claim with `needs-info`, leaving `ready-for-agent` absent. +The mark that a Run is live on an issue: thirdshift labels the issue `in-progress`, in place of `ready-for-agent` if it has that, when a **Ticket run**, a **Spec run** or a **Custom process** starts on it, whether started on its **Issue URL** or by an **Architect run**, a **Pickup run** or a **Security run**. A **Ticket run** in a Spec run and a **Base fix** make none. It lasts only while the Run is live, and ending it leaves the issue marked with how the Run ended. A Run whose pull request is ready for review, or whose **Self-merge** was held with its pull request ready, takes it off and puts nothing back: the open pull request stands for the work. A Self-merge that closed the issue takes it off; one that merged without closing the issue leaves it until the issue is closed. A Failed run with work on `origin` swaps it for `agent-failed` (see **Failure limit**), as does a failed Security fix even with nothing on `origin`, so it stays with the Day shift. A Ticket run that fails with nothing on `origin` to take over, no **Issue branch** and no pull request, releases it, putting `ready-for-agent` back. A Spec run whose undone **Tickets** are all only waiting, on a person or on other work, puts `ready-for-agent` back on its Spec without `agent-failed` (see **Ready issue**). A **Stop** leaves `needs-triage`, and a bug Ticket run that cannot reproduce the bug leaves `needs-info`. Ending a Claim finishes even after Command interruption. _Avoid_: lock (a lock is per machine and ends with its process), assignment **Failure limit**: -The number of open issues the factory failed on, labelled `agent-failed`, at which a **Pickup run** takes no more, set in the **User config**. thirdshift adds the label when a **Failed ticket run** or a **Failed spec run** keeps its **Claim**, whatever started it. A held **Self-merge** that leaves its pull request ready gets none, and neither does a **Stop**. The label comes off when the **Day shift** acts on the failure: by putting `ready-for-agent` back, by taking `in-progress` off, leaving no `needs-triage`, to take the issue over, or by closing it, which the **Sweep** clears. It keeps a broken **Base branch** or **Harness** from failing every **Ready issue** in turn. A pull request that is ready for review or merged never counts, so the factory keeps working while reviews wait. +The number of open issues the factory failed on, labelled `agent-failed`, at which a **Pickup run** takes no more, set in the **User config**. thirdshift puts the label on in place of the **Claim** when a **Failed ticket run** or a **Failed spec run** leaves work on `origin`, whatever started it. A held **Self-merge** that leaves its pull request ready gets none, and neither does a **Stop** or a Spec run that is only waiting. The label comes off when the **Day shift** acts on the failure: by putting `ready-for-agent` back, by taking `agent-failed` off to take the issue over, or by closing it, which the **Sweep** clears. The next Claim also takes it off. It keeps a broken **Base branch** or **Harness** from failing every **Ready issue** in turn. A pull request that is ready for review or merged never counts, so the factory keeps working while reviews wait. _Avoid_: Claim limit (former name), WIP limit, concurrency (it counts issues waiting on the **Day shift**, not Commands in flight) **Command limit**: @@ -264,7 +264,7 @@ A **Ticket run** that ends, including by interruption, without an open pull requ _Avoid_: Failed run (former name) **Recovery**: -The lines a **Failed ticket run** ends with, saying where it stopped, what work was preserved and where, and the command that continues or retries it, except after a **Spec PR** changed under its **Spec run**, when no command would be safe; built only from factory-owned facts, never agent output. +The lines a **Failed ticket run** ends with, saying where it stopped, what work was preserved and where, and the command that continues or retries it, except after a **Spec PR** changed under its **Spec run**, when no command would be safe; built only from factory-owned facts, never agent output. When the Failed run leaves its issue `agent-failed`, thirdshift also posts it there as a comment marked as generated: the cause, where it stopped, what was preserved, the machine, and how to retry by putting `ready-for-agent` back, without local paths or the continue command. **Continuation**: A **Ticket run** that picks up an existing **Issue branch**, one with no pull request or an open one, instead of starting fresh. When a pull request is open, its base is the **Base branch**. diff --git a/docs/grill-with-docs/1165-claim-labels.md b/docs/grill-with-docs/1165-claim-labels.md index 840faf851..398ef9245 100644 --- a/docs/grill-with-docs/1165-claim-labels.md +++ b/docs/grill-with-docs/1165-claim-labels.md @@ -3,7 +3,7 @@ Issue: https://github.com/JacobStephens2/thirdshift/issues/1165 Research: [proposed direction](https://github.com/JacobStephens2/thirdshift/issues/1165#issuecomment-6369972244), #585, #710, #833, #1583, #1695, [#1532 grill](1532-keep-working-the-backlog.md) -Paused 2026-10-23 with Round 1 unanswered. Revised in place on 2026-10-27, and twice on 2026-11-09: after the #1532 grill and Spec #1564 shipped the `agent-failed` label and the **Failure limit** in place of the **Claim limit**, and for Spec #1695, which gives Triage runs a Claim. Q1.1 is withdrawn, Q1.2–Q1.4 are rewritten for the new labels, and Q1.5 is new. `GLOSSARY.md` is unchanged so far: its **Claim**, **Failure limit**, **Sweep** and **Ready issue** entries wait on Q1.2, Q1.3 and Q1.5. +Paused 2026-10-23 with Round 1 unanswered. Revised in place on 2026-10-27, and twice on 2026-11-09: after the #1532 grill and Spec #1564 shipped the `agent-failed` label and the **Failure limit** in place of the **Claim limit**, and for Spec #1695, which gives Triage runs a Claim. Q1.1 is withdrawn, Q1.2–Q1.4 are rewritten for the new labels, and Q1.5 is new. Round 1 answered 2026-11-09. `GLOSSARY.md` now has the new **Claim**, **Failure limit**, **Ready issue** and **Recovery** entries. Agreed in chat on 2026-10-23, before Round 1, and where each stands now: @@ -11,7 +11,7 @@ Agreed in chat on 2026-10-23, before Round 1, and where each stands now: - `run-failed` does not count toward the limit. *Now:* the reverse shipped. `agent-failed` is exactly what the Failure limit counts (Q1.1, withdrawn). - A Spec run that stops only for the Day shift gets `ready-for-human`, not a failure label. Q1.3 questions this. -## Round 1 (open) +## Round 1 (answered) **Q1.1 - What stops Pickup working through every Ready issue when every Run fails?** *Withdrawn 2026-11-09, settled by the #1532 grill.* Pickup now counts open `agent-failed` issues against `pickup.failure_limit`, default 3. A broken Base branch or Harness stops the line after three failures, and pull requests waiting for review never count. One gap was left open here, and it is still open. A failure with nothing on `origin` releases its Claim to `ready-for-agent` and gets no `agent-failed`, so Pickup can take the same issue again on its next pass. See "Settled by earlier answers". @@ -22,7 +22,7 @@ Agreed in chat on 2026-10-23, before Round 1, and where each stands now: *Recommended:* (c). With no limit counting these issues, a second label would only repeat what the open pull request and the Inbox already show. Under (c), `in-progress` means one thing on issues and on pull requests: a live Run. It also makes the Ticket and Spec paths match what #1388 shipped. An issue whose Self-merge merged but whose closing failed keeps its Claim as it does today, since that is a finish still owed, not a review. -*Answer:* +*Answer:* agreed **Q1.3 - What does a Spec run that is only waiting leave on its Spec?** This matters more now than when first asked. A Spec run whose undone Tickets are all gated or blocked ends with `Tickets not done: #22 (labelled ready-for-human)` (`src/spec_run.rs:457`). That makes it a **Failed spec run**, so it keeps its Claim and gets `agent-failed`. Three such waiting Specs would stop Pickup on the repository under the Failure limit, though nothing is broken. Pickup already passes over a Spec with no **Startable Ticket**, so a Spec labelled `ready-for-agent` whose Tickets are all gated stays put on its own, and Pickup continues it once a Ticket becomes startable. The options: - (a) `ready-for-human` on the Spec, with no `agent-failed`, when every undone Ticket is an **Unready Ticket** or is blocked only behind ones. A Spec waiting on ordinary work elsewhere, such as a Ticket in another running Spec, gets `agent-failed`. @@ -33,7 +33,7 @@ In every option, a Spec run with a failed or interrupted Ticket gets `agent-fail *Recommended:* (b), with one guard. The Day shift does one thing, clearing the Ticket's gate, not two. The `ready-for-human` list then shows exactly the work that is human: Tickets, not Specs. The guard comes from the **Trusted account** rule. A Ready issue needs its latest `ready-for-agent` labelling by a Trusted account, with no edit since by an account that is not one. If thirdshift relabelled the Spec itself, as the owner's account, it would clear an untrusted edit made in between. So thirdshift puts `ready-for-agent` back only if no such edit has happened since the Day shift's last labelling. Otherwise the Spec gets `needs-triage`. This reverses the chat answer, so say if the Spec itself should still show `ready-for-human`. -*Answer:* +*Answer:* agreed **Q1.4 - Does a Failed run post its Recovery on the issue?** **Recovery** lines are built only from factory-owned facts. They reach the command log, the Run notification if one is configured, and the Console's Needs you. Since #1769, one Console shows Needs you for every machine in its **Fleet**, which covers most of #833's "which host?" for the Day shift. On GitHub, `agent-failed` says only that a Run failed, not why or what to do next. thirdshift already posts issue comments elsewhere: Base branch CI reports, and Triage runs, which say "This comment was generated by AI." #1695 adds a lot more of them: each triaged issue gets an AI-attributed Agent Brief, Questionnaire or closure comment. A #585 comment also asks for "a comment with the cause and Recovery line" on a waiting Spec. The repository is public, and Recovery lines include the host's paths and the full continue command. A comment from the owner's account is from a Trusted account, so the next session on the issue would be given it. The options: - (a) A comment on the issue at each Failed run, marked as generated. It gives the cause, where the Run stopped, what was kept (the branch and pull request), the host, and how to retry ("apply `ready-for-agent`"). No local paths and no continue command. @@ -42,7 +42,7 @@ In every option, a Spec run with a failed or interrupted Ticket gets `agent-fail *Recommended:* (a), a little more firmly than before, now that #1695 makes AI comments on issues routine. The Console covers the Day shift, but only on machines in its Fleet. The comment serves anyone reading the issue on GitHub, and it hands the next Continuation session a factual account of where the last Run stopped. A Run that fails again posts again, which leaves a history of attempts. Pick (c) if you would rather keep factory chatter off issues. -*Answer:* +*Answer:* agreed **Q1.5 - Does a failed Run that keeps its Claim still keep `in-progress` next to `agent-failed`?** This is the heart of #1165, now that #1564 has shipped. Today a Failed run with work on `origin` leaves both labels, so `in-progress` still doesn't mean "running". The pre-Round-1 answer was to swap one for the other, but it now runs into a #1532 rule (Q3.3 there, `src/pickup.rs:423`). Pickup reads an open issue with `agent-failed` and neither `in-progress` nor `needs-triage` as the Day shift having taken it over, and takes `agent-failed` off. Swap the labels without changing that rule, and the next Pickup run would clear every failure, so the brake would never hold. @@ -53,21 +53,76 @@ In every option, a Spec run with a failed or interrupted Ticket gets `agent-fail *Recommended:* (a). That is what #1165 asks for, and with Q1.2 (c) it leaves `in-progress` on an issue only while a Run is live. A single take-over act, removing the label that names the failure, is easier to learn than one per kind of Command. It also answers #1583: a failed Custom process counts like any other failure. Under (b), `ready-for-human` would mean "human work" on some issues and "the factory failed" on others. **This is time-sensitive.** If you pick (a), #1891 should drop its `ready-for-human` take-over rule before it lands, so say so and I'll comment on #1891. The cost is a change to a rule shipped two weeks ago. Issues that already failed also need `in-progress` taken off once, which the Sweep could do. +*Answer:* agreed + +*Checked:* answered on the text from before the #1695 revision, where (a) was the plain swap with one take-over rule, removing `agent-failed`. That part is settled. Applying it to #1695's Triage runs and to #1583's Custom processes was added later, so Q2.1 and Q2.2 put those to you. + +## Round 2 (open) + +**Q2.1 - Does #1695's Triage run use the same take-over rule?** Q1.5 settled one take-over rule: a failure swaps `in-progress` for `agent-failed`, and the Day shift acts by putting `ready-for-agent` back, removing `agent-failed`, or closing the issue. Spec #1695, being built now as Ticket #1891, gives a failed Triage run `ready-for-human` plus `agent-failed`, and adds a second signal: the Sweep clears `agent-failed` once `ready-for-human` comes off. The options: +- (a) One rule. A failed Triage run still gets `ready-for-human` next to `agent-failed`, so the Triage Pass passes over it, but `agent-failed` comes off only by the Q1.5 rule. #1891 drops its `ready-for-human` signal. I comment on #1891 and #1695 now, before it lands. +- (b) Keep #1695's extra signal for Triage runs only. + +*Recommended:* (a). The Day shift learns one act for every failure. Under (b), taking `ready-for-human` off would quietly clear a failure for one kind of Command only. Nothing is lost: if you answer a failed triage by relabelling the issue, you'd normally take `agent-failed` off in the same edit. + +*Answer:* + +**Q2.2 - Does a failed Custom process count toward the Failure limit (#1583)?** Today it does: `HeldClaim` ends its Claim through the same path as a Ticket run, so with work on `origin` it gets `agent-failed`. Under Q1.5 it would also lose `in-progress`. #1583 asks whether that is right, since #1564 named only Ticket runs and Spec runs. The options: +- (a) Yes. A failed Custom process on an issue waits for the Day shift exactly as a Failed ticket run does. Answer and close #1583 with that. +- (b) No. A Custom process releases or keeps its Claim without the label, and doesn't count. + +*Recommended:* (a). A Custom process is Day-shift-authored and experimental, but an issue it failed on still waits for the Day shift. Leaving it out would also leave its failures on `in-progress`, which is what #1165 is removing. + +*Answer:* + +**Q2.3 - Which failures post the Recovery comment (Q1.4)?** Q1.4 settled a generated comment with no local paths. Three cases need a boundary: +- **A failed Security fix.** Its issue is a fix issue on the repository, but its cause can describe the vulnerability, which today stays in the private advisory. +- **A failure with nothing on `origin`.** It releases to `ready-for-agent`, and Pickup can take it again at once, so a comment per failure could repeat on every Pickup pass. +- **A Spec run that is only waiting (Q1.3).** It gets no `agent-failed`. #585 asks for the cause on the Spec: which Tickets wait, and on what. + +The options: +- (a) Comment only when the issue ends `agent-failed`, except a failed Security fix, whose Recovery stays in the advisory. Also comment on a waiting Spec, naming each undone Ticket and what it waits on. No comment on a release. +- (b) Comment on every Failed run, Security fixes and releases included. +- (c) Only `agent-failed` issues, Security fixes included, and no waiting-Spec comment. + +*Recommended:* (a). It keeps vulnerability details private and can't repeat on every pass. It gives the waiting Spec what #585 asked for: "claimed and waiting for you" looks different from a failure on GitHub. A waiting Spec isn't taken again until a Ticket becomes startable, so its comment doesn't repeat either. + +*Answer:* + +**Q2.4 - What happens to issues labelled the old way?** When this ships, open issues will still carry `in-progress` beside `agent-failed`, or `in-progress` while their pull request waits for review. Under the new rules, `in-progress` and `agent-failed` never sit on one issue, because a new Claim takes `agent-failed` off. The options: +- (a) The Sweep also takes `in-progress` off any open issue that carries `agent-failed`. That one rule is safe forever. The ready-for-review issues are cleared by hand once, from a list in the pull request, because a live Run can't be told apart from GitHub alone. +- (b) Clear both by hand once, with no Sweep change. +- (c) Leave them. They fade as issues close. + +*Recommended:* (a). The `agent-failed` case can't be ambiguous, so the Sweep can own it. The ready-for-review case can be, because a Continuation could be live on an issue whose pull request was ready, and only a person checking the Inbox can tell. + +*Answer:* + +**Q2.5 - File the unbraked release retry as its own issue?** A Ticket run that fails with nothing on `origin` releases to `ready-for-agent` with no `agent-failed` (unchanged by Round 1). Nothing stops Pickup taking the same issue again on every pass, as a Harness that fails before its first commit would. The options: +- (a) File it as a `needs-triage` issue now, linking #1165 and #1532, and keep it out of this Spec. +- (b) Fold it into this Spec: such a failure gets `agent-failed` too, with no Claim to keep. +- (c) Leave it. + +*Recommended:* (a). It is a Failure-limit question, not a label-meaning one, and (b) would change what the Failure limit counts, which #1532 settled deliberately. + *Answer:* ## Settled by earlier answers (shout if any is wrong) -- **#1165 still stands.** The Fleet Console's Working group shows live Runs, but only on machines in that Fleet. Anyone reading GitHub, and both hosts, see the labels. -- **Interrupted runs:** a Failed run ended by interruption, not by a Stop, with work on `origin`, is treated like any other Failed run. The glossary already counts interruption as a Failed run. -- **Failed Security fixes:** these keep their Claim even with nothing on `origin` and get `agent-failed` today. Whatever Q1.5 decides applies to them too. -- **Unchanged endings:** a Stop still leaves `needs-triage`. #1695's Triage runs are the exception: they leave `ready-for-human`, since `needs-triage` is their own queue. A bug Ticket run that can't reproduce still leaves `needs-info`. -- **Triage runs hold a Claim** under #1695, so Q1.2–Q1.5 apply to them too, and the glossary's **Claim** entry gains them. -- **A failure with nothing on `origin`** still releases to `ready-for-agent` with no `agent-failed`, so Pickup can retry it at once and nothing brakes it. That is out of scope here, and gets its own issue if you want one. -- **Pickup:** it never takes an `agent-failed` issue, because a Ready issue needs `ready-for-agent`. The Day shift retries by applying `ready-for-agent`, and Pickup then starts a **Continuation** on the kept Issue branch and pull request. -- **Label upkeep:** making a Claim takes `agent-failed` off, and the **Sweep** takes both labels off closed issues. Both already ship. +- **`in-progress` means a live Run**, on issues and on pull requests alike (Q1.2, Q1.5). It goes on when a Run starts and always comes off when it ends. +- **Ready for review:** a Ticket run, Spec run or Custom process whose pull request is ready, or whose Self-merge was held with its pull request ready, takes `in-progress` off and puts nothing back. `Claim::remove` from #1388 becomes the ending for all of them (Q1.2). +- **Pickup still won't retake those issues:** a started issue is Ready only after a handback (Q1.2). +- **A merged but still open issue** keeps `in-progress` until it is closed, as today (Q1.2). +- **Failure:** a Failed run with work on `origin`, and a failed Security fix even with nothing, swaps `in-progress` for `agent-failed`. The #1532 take-over rule "neither `in-progress` nor `needs-triage`" is replaced by "`agent-failed` taken off" (Q1.5, at `src/pickup.rs:423`). +- **A waiting Spec run** puts `ready-for-agent` back on its Spec, takes `in-progress` off and adds no `agent-failed`. It does so only if no untrusted edit has happened since the last Trusted `ready-for-agent` labelling, and labels the Spec `needs-triage` otherwise. Waiting means every undone Ticket is an Unready Ticket, blocked, waiting on other running work, or outside the Spec's repository (Q1.3). +- **A Spec run with any failed or interrupted Ticket** gets `agent-failed` (Q1.3). +- **#585** keeps the outcome name, exit code, notification wording and mixed results. This grill settles only the labels (Q1.3). +- **The Recovery comment** is marked as generated, names the machine and how to retry, and leaves out local paths and the continue command. A Run that fails again posts again (Q1.4). Its boundary is Q2.3. +- **Interrupted runs** are treated like any other Failed run. A Stop still leaves `needs-triage`, and a bug that can't be reproduced still leaves `needs-info`. +- **Label upkeep:** a new Claim takes `agent-failed` off, and the Sweep takes both labels off closed issues. Both already ship. - **Tickets:** a Ticket run inside a Spec run makes no Claim, so its Spec carries the outcome. - **Out of scope:** a Run killed outright never ends its Claim (#710). -- **Glossary:** **Claim** changes with Q1.2 and Q1.5 (it also still omits the Custom process exception from #1388). **Failure limit** changes with Q1.5's take-over rule, and **Ready issue** with Q1.3's handback. +- **Glossary:** **Claim**, **Failure limit**, **Ready issue** and **Recovery** updated on 2026-11-09. **Claim** now says it marks a live Run and includes Custom processes. Triage runs join it with Q2.1, and **Sweep** changes with Q2.4. ## Research results (2026-10-23) From 8eabfdc26d439a8f251a4b74f09a8bed5f125881 Mon Sep 17 00:00:00 2001 From: Jacob Stephens Date: Mon, 9 Nov 2026 17:01:51 -0500 Subject: [PATCH 5/9] Grill #1165: record Round 2 answers, update the glossary, open Round 3 --- GLOSSARY.md | 6 +-- docs/grill-with-docs/1165-claim-labels.md | 60 ++++++++++++++++++++--- 2 files changed, 56 insertions(+), 10 deletions(-) diff --git a/GLOSSARY.md b/GLOSSARY.md index 603653958..e2fbcf91b 100644 --- a/GLOSSARY.md +++ b/GLOSSARY.md @@ -44,7 +44,7 @@ The mark that a Run is live on an issue: thirdshift labels the issue `in-progres _Avoid_: lock (a lock is per machine and ends with its process), assignment **Failure limit**: -The number of open issues the factory failed on, labelled `agent-failed`, at which a **Pickup run** takes no more, set in the **User config**. thirdshift puts the label on in place of the **Claim** when a **Failed ticket run** or a **Failed spec run** leaves work on `origin`, whatever started it. A held **Self-merge** that leaves its pull request ready gets none, and neither does a **Stop** or a Spec run that is only waiting. The label comes off when the **Day shift** acts on the failure: by putting `ready-for-agent` back, by taking `agent-failed` off to take the issue over, or by closing it, which the **Sweep** clears. The next Claim also takes it off. It keeps a broken **Base branch** or **Harness** from failing every **Ready issue** in turn. A pull request that is ready for review or merged never counts, so the factory keeps working while reviews wait. +The number of open issues the factory failed on, labelled `agent-failed`, at which a **Pickup run** takes no more, set in the **User config**. thirdshift puts the label on in place of the **Claim** when a **Failed ticket run**, a **Failed spec run** or a failed **Custom process** on an issue leaves work on `origin`, whatever started it. A held **Self-merge** that leaves its pull request ready gets none, and neither does a **Stop** or a Spec run that is only waiting. The label comes off when the **Day shift** acts on the failure: by putting `ready-for-agent` back, by taking `agent-failed` off to take the issue over, or by closing it, which the **Sweep** clears. The next Claim also takes it off. It keeps a broken **Base branch** or **Harness** from failing every **Ready issue** in turn. A pull request that is ready for review or merged never counts, so the factory keeps working while reviews wait. _Avoid_: Claim limit (former name), WIP limit, concurrency (it counts issues waiting on the **Day shift**, not Commands in flight) **Command limit**: @@ -52,7 +52,7 @@ The number of live **Commands** on one repository on one machine at which a **Pa _Avoid_: Pass lock (former, one-wide form), concurrency limit, parallel **Sweep**: -A **Pickup run**'s removal of `in-progress` and `agent-failed` from every closed issue in the repository that still has them, and of `in-progress` from closed pull requests, with other labels kept. Each Pickup run that is not skipped for its **Command limit** makes one, before it holds the repository against its **Failure limit**. A Sweep that fails is a warning, never a failure. +A **Pickup run**'s removal of `in-progress` and `agent-failed` from every closed issue in the repository that still has them, of `in-progress` from every open issue that also has `agent-failed`, and of `in-progress` from closed pull requests, with other labels kept. Each Pickup run that is not skipped for its **Command limit** makes one, before it holds the repository against its **Failure limit**. A Sweep that fails is a warning, never a failure. _Avoid_: cleanup, garbage collection ### Repository and branches @@ -264,7 +264,7 @@ A **Ticket run** that ends, including by interruption, without an open pull requ _Avoid_: Failed run (former name) **Recovery**: -The lines a **Failed ticket run** ends with, saying where it stopped, what work was preserved and where, and the command that continues or retries it, except after a **Spec PR** changed under its **Spec run**, when no command would be safe; built only from factory-owned facts, never agent output. When the Failed run leaves its issue `agent-failed`, thirdshift also posts it there as a comment marked as generated: the cause, where it stopped, what was preserved, the machine, and how to retry by putting `ready-for-agent` back, without local paths or the continue command. +The lines a **Failed ticket run** ends with, saying where it stopped, what work was preserved and where, and the command that continues or retries it, except after a **Spec PR** changed under its **Spec run**, when no command would be safe; built only from factory-owned facts, never agent output. When the Failed run leaves its issue `agent-failed`, thirdshift also posts it there as a comment marked as generated, except for a failed Security fix, whose Recovery stays in its private advisory: the cause, where it stopped, what was preserved, the machine, and how to retry by putting `ready-for-agent` back, without local paths or the continue command. A **Spec run** that ends only waiting posts a comment on its **Spec** instead, naming each undone **Ticket** and what it waits on. **Continuation**: A **Ticket run** that picks up an existing **Issue branch**, one with no pull request or an open one, instead of starting fresh. When a pull request is open, its base is the **Base branch**. diff --git a/docs/grill-with-docs/1165-claim-labels.md b/docs/grill-with-docs/1165-claim-labels.md index 398ef9245..47fa61d66 100644 --- a/docs/grill-with-docs/1165-claim-labels.md +++ b/docs/grill-with-docs/1165-claim-labels.md @@ -57,7 +57,7 @@ In every option, a Spec run with a failed or interrupted Ticket gets `agent-fail *Checked:* answered on the text from before the #1695 revision, where (a) was the plain swap with one take-over rule, removing `agent-failed`. That part is settled. Applying it to #1695's Triage runs and to #1583's Custom processes was added later, so Q2.1 and Q2.2 put those to you. -## Round 2 (open) +## Round 2 (answered) **Q2.1 - Does #1695's Triage run use the same take-over rule?** Q1.5 settled one take-over rule: a failure swaps `in-progress` for `agent-failed`, and the Day shift acts by putting `ready-for-agent` back, removing `agent-failed`, or closing the issue. Spec #1695, being built now as Ticket #1891, gives a failed Triage run `ready-for-human` plus `agent-failed`, and adds a second signal: the Sweep clears `agent-failed` once `ready-for-human` comes off. The options: - (a) One rule. A failed Triage run still gets `ready-for-human` next to `agent-failed`, so the Triage Pass passes over it, but `agent-failed` comes off only by the Q1.5 rule. #1891 drops its `ready-for-human` signal. I comment on #1891 and #1695 now, before it lands. @@ -65,7 +65,9 @@ In every option, a Spec run with a failed or interrupted Ticket gets `agent-fail *Recommended:* (a). The Day shift learns one act for every failure. Under (b), taking `ready-for-human` off would quietly clear a failure for one kind of Command only. Nothing is lost: if you answer a failed triage by relabelling the issue, you'd normally take `agent-failed` off in the same edit. -*Answer:* +*Answer:* agreed + +*Checked:* drafts of the comments for #1891 and #1695 are ready, but posting them was blocked by a permission check, so they wait for you (see "Waiting on research"). #1891 can't simply drop the `ready-for-human` signal before #1165 lands: today's `src/pickup.rs` check would clear `agent-failed` from a failed Triage run at once, since it has neither `in-progress` nor `needs-triage`. The draft says #1891 may treat `ready-for-human` like `needs-triage` in that check for now, but shouldn't document removing it as the take-over act. **Q2.2 - Does a failed Custom process count toward the Failure limit (#1583)?** Today it does: `HeldClaim` ends its Claim through the same path as a Ticket run, so with work on `origin` it gets `agent-failed`. Under Q1.5 it would also lose `in-progress`. #1583 asks whether that is right, since #1564 named only Ticket runs and Spec runs. The options: - (a) Yes. A failed Custom process on an issue waits for the Day shift exactly as a Failed ticket run does. Answer and close #1583 with that. @@ -73,7 +75,7 @@ In every option, a Spec run with a failed or interrupted Ticket gets `agent-fail *Recommended:* (a). A Custom process is Day-shift-authored and experimental, but an issue it failed on still waits for the Day shift. Leaving it out would also leave its failures on `in-progress`, which is what #1165 is removing. -*Answer:* +*Answer:* agreed **Q2.3 - Which failures post the Recovery comment (Q1.4)?** Q1.4 settled a generated comment with no local paths. Three cases need a boundary: - **A failed Security fix.** Its issue is a fix issue on the repository, but its cause can describe the vulnerability, which today stays in the private advisory. @@ -87,7 +89,7 @@ The options: *Recommended:* (a). It keeps vulnerability details private and can't repeat on every pass. It gives the waiting Spec what #585 asked for: "claimed and waiting for you" looks different from a failure on GitHub. A waiting Spec isn't taken again until a Ticket becomes startable, so its comment doesn't repeat either. -*Answer:* +*Answer:* agreed **Q2.4 - What happens to issues labelled the old way?** When this ships, open issues will still carry `in-progress` beside `agent-failed`, or `in-progress` while their pull request waits for review. Under the new rules, `in-progress` and `agent-failed` never sit on one issue, because a new Claim takes `agent-failed` off. The options: - (a) The Sweep also takes `in-progress` off any open issue that carries `agent-failed`. That one rule is safe forever. The ready-for-review issues are cleared by hand once, from a list in the pull request, because a live Run can't be told apart from GitHub alone. @@ -96,7 +98,7 @@ The options: *Recommended:* (a). The `agent-failed` case can't be ambiguous, so the Sweep can own it. The ready-for-review case can be, because a Continuation could be live on an issue whose pull request was ready, and only a person checking the Inbox can tell. -*Answer:* +*Answer:* agreed **Q2.5 - File the unbraked release retry as its own issue?** A Ticket run that fails with nothing on `origin` releases to `ready-for-agent` with no `agent-failed` (unchanged by Round 1). Nothing stops Pickup taking the same issue again on every pass, as a Harness that fails before its first commit would. The options: - (a) File it as a `needs-triage` issue now, linking #1165 and #1532, and keep it out of this Spec. @@ -105,6 +107,45 @@ The options: *Recommended:* (a). It is a Failure-limit question, not a label-meaning one, and (b) would change what the Failure limit counts, which #1532 settled deliberately. +*Answer:* agreed + +## Round 3 (open) + +Round 2 settles the last design branch. What's left is how to publish it. + +**Q3.1 - Publish as a new Spec with three Tickets?** The work spans more than one session, so `docs/agents/triage-labels.md` makes it a Spec, published `needs-triage` until its Tickets are linked. #1532 set the precedent of a new Spec issue (#1564) rather than rewriting the problem issue. The proposed split: +1. **Claim endings.** Ready for review takes `in-progress` off on every path (Q1.2). A failure swaps it for `agent-failed`, Custom processes included (Q1.5, Q2.2). The take-over check becomes "`agent-failed` taken off" (Q1.5), and the Sweep takes `in-progress` off open `agent-failed` issues (Q2.4). These ship together, because the swap without the new check would clear every failure. +2. **Waiting Spec runs.** Put `ready-for-agent` back with no `agent-failed`, guarded by the Trusted-account check, or label the Spec `needs-triage` (Q1.3). Blocked by 1. +3. **Recovery comments.** A generated comment on every `agent-failed` issue except Security fixes, and the waiting-Spec comment (Q1.4, Q2.3). Blocked by 1 and 2. + +Each Ticket updates the guide and the hand-written site pages that its change makes wrong. The one-time clearing of ready-for-review issues (Q2.4) can't happen until the Spec is released, so per "Split a Spec at a release" it becomes a standalone `ready-for-human` issue blocked by the Spec. The options: +- (a) A new Spec as above, which closes #1165 when it lands. +- (b) Rewrite #1165 as the Spec. +- (c) One Ticket for everything. + +*Recommended:* (a). It matches #1564 and keeps #1165's history readable. The split follows the dependencies: 1 is the label meaning, 2 and 3 build on it. + +*Answer:* + +**Q3.2 - What happens to the related open issues?** This grill answers part of three of them: +- **#585**, waiting Spec runs. The labels and the comment are settled here. The outcome name, exit code, notification wording and mixed results are not. +- **#833**, which machine holds a Claim. The Recovery comment names the machine on a failure, but nothing names it while a Run is live. +- **#1165**, closed by the Spec. + +The options: +- (a) Comment on #585 and #833 with what this Spec settles, and leave both open for the rest. +- (b) Fold #585's remaining decisions into this Spec. + +*Recommended:* (a). #585's remaining questions are about outcomes and notifications, not labels. Folding them in would make the Spec wait on a grill of its own. + +*Answer:* + +**Q3.3 - Record an ADR?** A decision earns one when it is hard to reverse, surprising without context, and a real trade-off. "`in-progress` marks only a live Run: a pull request waiting for review gets no label, and a failure gets `agent-failed` instead" passes all three. It changes what both hosts and every reader of GitHub rely on. A future reader will wonder why a Claimed issue with an open pull request has no label. And `in-review` was a real alternative, rejected once #1532 stopped counting reviews. +- (a) Yes, one short ADR covering Q1.2 and Q1.5. +- (b) No. The glossary and this file are enough. + +*Recommended:* (a). The glossary says what the labels mean but not why the alternatives lost, and this file isn't where a future reader would look. + *Answer:* ## Settled by earlier answers (shout if any is wrong) @@ -122,7 +163,12 @@ The options: - **Label upkeep:** a new Claim takes `agent-failed` off, and the Sweep takes both labels off closed issues. Both already ship. - **Tickets:** a Ticket run inside a Spec run makes no Claim, so its Spec carries the outcome. - **Out of scope:** a Run killed outright never ends its Claim (#710). -- **Glossary:** **Claim**, **Failure limit**, **Ready issue** and **Recovery** updated on 2026-11-09. **Claim** now says it marks a live Run and includes Custom processes. Triage runs join it with Q2.1, and **Sweep** changes with Q2.4. +- **One take-over rule for every failure,** Triage runs included: `agent-failed` comes off when the Day shift puts `ready-for-agent` back, takes `agent-failed` off, or closes the issue (Q2.1). A failed Triage run still also gets `ready-for-human`, which is #1695's business. +- **Custom processes** count toward the Failure limit and swap `in-progress` for `agent-failed` like any other failure (Q2.2). +- **Recovery comments** go on every `agent-failed` issue except a failed Security fix, and on a waiting Spec. A released issue gets none (Q2.3). +- **The Sweep** also takes `in-progress` off open issues that carry `agent-failed`, and keeps doing so. Issues whose pull request waits for review are cleared by hand once, after release (Q2.4). +- **The release-retry gap** becomes its own `needs-triage` issue, outside this Spec (Q2.5). +- **Glossary:** **Claim**, **Failure limit**, **Ready issue**, **Recovery** and **Sweep** updated on 2026-11-09. Triage runs join **Claim** when #1891 lands, since they don't hold one yet. ## Research results (2026-10-23) @@ -155,4 +201,4 @@ The options: ## Waiting on research -- Nothing. +- Posting to GitHub was blocked by a permission check, so these wait for you: the comments on #1891 and #1695 (Q2.1), the answer to #1583 and closing it (Q2.2), and a new issue for the release-retry gap (Q2.5). The drafts are in the session scratchpad, `github-drafts.md`. From e230df40a7c2d5ae3465f350ad94b8f8f4e16745 Mon Sep 17 00:00:00 2001 From: Jacob Stephens Date: Mon, 9 Nov 2026 17:02:05 -0500 Subject: [PATCH 6/9] Grill #1165: restore text lost to shell quoting --- docs/grill-with-docs/1165-claim-labels.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/grill-with-docs/1165-claim-labels.md b/docs/grill-with-docs/1165-claim-labels.md index 47fa61d66..438fafcc5 100644 --- a/docs/grill-with-docs/1165-claim-labels.md +++ b/docs/grill-with-docs/1165-claim-labels.md @@ -3,7 +3,7 @@ Issue: https://github.com/JacobStephens2/thirdshift/issues/1165 Research: [proposed direction](https://github.com/JacobStephens2/thirdshift/issues/1165#issuecomment-6369972244), #585, #710, #833, #1583, #1695, [#1532 grill](1532-keep-working-the-backlog.md) -Paused 2026-10-23 with Round 1 unanswered. Revised in place on 2026-10-27, and twice on 2026-11-09: after the #1532 grill and Spec #1564 shipped the `agent-failed` label and the **Failure limit** in place of the **Claim limit**, and for Spec #1695, which gives Triage runs a Claim. Q1.1 is withdrawn, Q1.2–Q1.4 are rewritten for the new labels, and Q1.5 is new. Round 1 answered 2026-11-09. `GLOSSARY.md` now has the new **Claim**, **Failure limit**, **Ready issue** and **Recovery** entries. +Paused 2026-10-23 with Round 1 unanswered. Revised in place on 2026-10-27, and twice on 2026-11-09: after the #1532 grill and Spec #1564 shipped the `agent-failed` label and the **Failure limit** in place of the **Claim limit**, and for Spec #1695, which gives Triage runs a Claim. Q1.1 is withdrawn, Q1.2–Q1.4 are rewritten for the new labels, and Q1.5 is new. Rounds 1 and 2 answered 2026-11-09. `GLOSSARY.md` now has the new **Claim**, **Failure limit**, **Ready issue**, **Recovery** and **Sweep** entries. Agreed in chat on 2026-10-23, before Round 1, and where each stands now: @@ -201,4 +201,4 @@ The options: ## Waiting on research -- Posting to GitHub was blocked by a permission check, so these wait for you: the comments on #1891 and #1695 (Q2.1), the answer to #1583 and closing it (Q2.2), and a new issue for the release-retry gap (Q2.5). The drafts are in the session scratchpad, `github-drafts.md`. +- Posting to GitHub was blocked by a permission check, so these wait for you: the comments on #1891 and #1695 (Q2.1), the answer to #1583 and closing it (Q2.2), and a new `needs-triage` issue for the release-retry gap (Q2.5). The drafts are in `/private/tmp/claude-501/-Users-jacob--herdr-worktrees-thirdshift-1165-triage/eb97d8f7-9a68-4adc-a09b-d3d2898f4fce/scratchpad/github-drafts.md`. From 1f0be9204c1d2dbbbc256043d94d7dee3976ae03 Mon Sep 17 00:00:00 2001 From: Jacob Stephens Date: Mon, 9 Nov 2026 17:08:16 -0500 Subject: [PATCH 7/9] Grill #1165: record Round 3 answers and ADR 0027 --- .../0027-in-progress-marks-only-a-live-run.md | 26 +++++++++++++++++++ docs/grill-with-docs/1165-claim-labels.md | 15 +++++++---- 2 files changed, 36 insertions(+), 5 deletions(-) create mode 100644 docs/adr/0027-in-progress-marks-only-a-live-run.md diff --git a/docs/adr/0027-in-progress-marks-only-a-live-run.md b/docs/adr/0027-in-progress-marks-only-a-live-run.md new file mode 100644 index 000000000..064364fa6 --- /dev/null +++ b/docs/adr/0027-in-progress-marks-only-a-live-run.md @@ -0,0 +1,26 @@ +# `in-progress` marks only a live Run + +This amends [ADR 0026](0026-pickup-counts-failures-and-passes-share-a-repository-up-to-a-command-limit.md)'s take-over rule and its last consequence. The rest of ADR 0026 stands. + +A **Claim** used to outlive its Run. A Ticket run or Spec run whose pull request was ready for review kept `in-progress`, and so did a Failed run with work on `origin`, which ADR 0026 also labelled `agent-failed`. Meanwhile a **Custom process**'s Delivery took `in-progress` off at ready for review (#1388). The issue list therefore couldn't answer "what is running?" (#1165). The Day shift relabelled stale issues by hand, and stopped trusting the label. + +So `in-progress` now means a live Run, on issues as it already did on pull requests. It goes on when a Run starts and comes off when it ends, and the issue is left marked with how the Run ended: + +- **Ready for review**, or a **Self-merge** held with its pull request ready: no label. The open pull request stands for the work, and Pickup still won't take the issue, because a started issue is a **Ready issue** only after a handback. +- **Failed with work on `origin`**, or a failed Security fix: `agent-failed` in place of `in-progress`, whatever kind of Command failed. The Day shift takes over a failure in one of three ways: by putting `ready-for-agent` back, by taking `agent-failed` off, or by closing the issue. +- **A Spec run that is only waiting** on gated, blocked or out-of-repository Tickets: `ready-for-agent` back on its Spec and no `agent-failed`, unless an account that is not a **Trusted account** has edited the Spec since its last Trusted labelling, in which case `needs-triage`. + +Decided in `docs/grill-with-docs/1165-claim-labels.md`: Q1.2, Q1.3, Q1.5, Q2.1, Q2.2 and Q2.4. + +## Considered Options + +- **A new `in-review` label** for a pull request waiting for review. It was recommended while the Claim limit counted those issues to stop reviews piling up. Rejected once ADR 0026 stopped counting them: with nothing counting it, the label would repeat what the open pull request and the Inbox's Ready for review already show. +- **Keep `in-progress` beside `agent-failed`**, so "running" is `in-progress` without `agent-failed`. Rejected: a reader of GitHub, or another host, would need a two-label search to see what is live, and that was #1165's complaint. +- **Follow Spec #1695 everywhere**: a failure leaves `ready-for-human` plus `agent-failed`, and removing `ready-for-human` is the take-over. Rejected: retrying a Ticket would take two label edits, because `ready-for-human` makes an issue Unready, and `ready-for-human` would mean "human work" on some issues and "the factory failed" on others. + +## Consequences + +- ADR 0026's take-over signal "taking `in-progress` off, leaving no `needs-triage`" goes. Without the change, the swap would let the next Pickup run clear every failure. +- The **Sweep** also takes `in-progress` off any open issue that carries `agent-failed`. Under the new rules the two never sit together, so this both migrates old issues and stays safe forever. Issues whose pull request was ready for review under the old rules are cleared by hand once, because GitHub alone can't tell them from a live Continuation. +- A failed Triage run (#1695) also gets `ready-for-human`, so the Triage Pass passes over it, but only `agent-failed` is the failure mark. +- A failure with nothing on `origin` still releases its issue to `ready-for-agent`, and nothing brakes Pickup retaking it. That is left to its own issue. diff --git a/docs/grill-with-docs/1165-claim-labels.md b/docs/grill-with-docs/1165-claim-labels.md index 438fafcc5..88c70f763 100644 --- a/docs/grill-with-docs/1165-claim-labels.md +++ b/docs/grill-with-docs/1165-claim-labels.md @@ -3,7 +3,7 @@ Issue: https://github.com/JacobStephens2/thirdshift/issues/1165 Research: [proposed direction](https://github.com/JacobStephens2/thirdshift/issues/1165#issuecomment-6369972244), #585, #710, #833, #1583, #1695, [#1532 grill](1532-keep-working-the-backlog.md) -Paused 2026-10-23 with Round 1 unanswered. Revised in place on 2026-10-27, and twice on 2026-11-09: after the #1532 grill and Spec #1564 shipped the `agent-failed` label and the **Failure limit** in place of the **Claim limit**, and for Spec #1695, which gives Triage runs a Claim. Q1.1 is withdrawn, Q1.2–Q1.4 are rewritten for the new labels, and Q1.5 is new. Rounds 1 and 2 answered 2026-11-09. `GLOSSARY.md` now has the new **Claim**, **Failure limit**, **Ready issue**, **Recovery** and **Sweep** entries. +Paused 2026-10-23 with Round 1 unanswered. Revised in place on 2026-10-27, and twice on 2026-11-09: after the #1532 grill and Spec #1564 shipped the `agent-failed` label and the **Failure limit** in place of the **Claim limit**, and for Spec #1695, which gives Triage runs a Claim. Q1.1 is withdrawn, Q1.2–Q1.4 are rewritten for the new labels, and Q1.5 is new. Rounds 1–3 answered 2026-11-09; the frontier is empty and the grill is done. `GLOSSARY.md` now has the new **Claim**, **Failure limit**, **Ready issue**, **Recovery** and **Sweep** entries. Agreed in chat on 2026-10-23, before Round 1, and where each stands now: @@ -109,7 +109,7 @@ The options: *Answer:* agreed -## Round 3 (open) +## Round 3 (answered) Round 2 settles the last design branch. What's left is how to publish it. @@ -125,7 +125,7 @@ Each Ticket updates the guide and the hand-written site pages that its change ma *Recommended:* (a). It matches #1564 and keeps #1165's history readable. The split follows the dependencies: 1 is the label meaning, 2 and 3 build on it. -*Answer:* +*Answer:* agreed, using the to-spec and to-tickets skills **Q3.2 - What happens to the related open issues?** This grill answers part of three of them: - **#585**, waiting Spec runs. The labels and the comment are settled here. The outcome name, exit code, notification wording and mixed results are not. @@ -138,7 +138,7 @@ The options: *Recommended:* (a). #585's remaining questions are about outcomes and notifications, not labels. Folding them in would make the Spec wait on a grill of its own. -*Answer:* +*Answer:* agreed **Q3.3 - Record an ADR?** A decision earns one when it is hard to reverse, surprising without context, and a real trade-off. "`in-progress` marks only a live Run: a pull request waiting for review gets no label, and a failure gets `agent-failed` instead" passes all three. It changes what both hosts and every reader of GitHub rely on. A future reader will wonder why a Claimed issue with an open pull request has no label. And `in-review` was a real alternative, rejected once #1532 stopped counting reviews. - (a) Yes, one short ADR covering Q1.2 and Q1.5. @@ -146,7 +146,9 @@ The options: *Recommended:* (a). The glossary says what the labels mean but not why the alternatives lost, and this file isn't where a future reader would look. -*Answer:* +*Answer:* agreed + +*Checked:* written as `docs/adr/0027-in-progress-marks-only-a-live-run.md`, amending ADR 0026's take-over rule. ## Settled by earlier answers (shout if any is wrong) @@ -162,6 +164,9 @@ The options: - **Interrupted runs** are treated like any other Failed run. A Stop still leaves `needs-triage`, and a bug that can't be reproduced still leaves `needs-info`. - **Label upkeep:** a new Claim takes `agent-failed` off, and the Sweep takes both labels off closed issues. Both already ship. - **Tickets:** a Ticket run inside a Spec run makes no Claim, so its Spec carries the outcome. +- **Publication:** a new Spec, published `needs-triage` with the to-spec and to-tickets skills, and three Tickets: Claim endings; waiting Spec runs (blocked by 1); Recovery comments (blocked by 1 and 2). A standalone `ready-for-human` issue, blocked by the Spec, clears the old ready-for-review labels after release. The Spec closes #1165 (Q3.1). +- **Related issues:** #585 and #833 get a comment on what the Spec settles and stay open (Q3.2). +- **ADR 0027** records Q1.2 and Q1.5 (Q3.3). - **Out of scope:** a Run killed outright never ends its Claim (#710). - **One take-over rule for every failure,** Triage runs included: `agent-failed` comes off when the Day shift puts `ready-for-agent` back, takes `agent-failed` off, or closes the issue (Q2.1). A failed Triage run still also gets `ready-for-human`, which is #1695's business. - **Custom processes** count toward the Failure limit and swap `in-progress` for `agent-failed` like any other failure (Q2.2). From b98576e788c07cd73648245adebd3a2b115b311a Mon Sep 17 00:00:00 2001 From: Jacob Stephens Date: Mon, 9 Nov 2026 17:10:01 -0500 Subject: [PATCH 8/9] Grill #1165: a blocking cycle is a failure, not waiting --- docs/grill-with-docs/1165-claim-labels.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/grill-with-docs/1165-claim-labels.md b/docs/grill-with-docs/1165-claim-labels.md index 88c70f763..ec77bacac 100644 --- a/docs/grill-with-docs/1165-claim-labels.md +++ b/docs/grill-with-docs/1165-claim-labels.md @@ -159,6 +159,7 @@ The options: - **Failure:** a Failed run with work on `origin`, and a failed Security fix even with nothing, swaps `in-progress` for `agent-failed`. The #1532 take-over rule "neither `in-progress` nor `needs-triage`" is replaced by "`agent-failed` taken off" (Q1.5, at `src/pickup.rs:423`). - **A waiting Spec run** puts `ready-for-agent` back on its Spec, takes `in-progress` off and adds no `agent-failed`. It does so only if no untrusted edit has happened since the last Trusted `ready-for-agent` labelling, and labels the Spec `needs-triage` otherwise. Waiting means every undone Ticket is an Unready Ticket, blocked, waiting on other running work, or outside the Spec's repository (Q1.3). - **A Spec run with any failed or interrupted Ticket** gets `agent-failed` (Q1.3). +- **A blocking cycle** among undone Tickets is a failure, not waiting: nothing unblocks it until someone reshapes the Tickets. Decided in chat on 2026-11-09, while checking the Spec's test seams. - **#585** keeps the outcome name, exit code, notification wording and mixed results. This grill settles only the labels (Q1.3). - **The Recovery comment** is marked as generated, names the machine and how to retry, and leaves out local paths and the continue command. A Run that fails again posts again (Q1.4). Its boundary is Q2.3. - **Interrupted runs** are treated like any other Failed run. A Stop still leaves `needs-triage`, and a bug that can't be reproduced still leaves `needs-info`. From bb6cf957c6e0757ed6d796819196d7b2f6a16ecb Mon Sep 17 00:00:00 2001 From: Jacob Stephens Date: Mon, 9 Nov 2026 17:22:24 -0500 Subject: [PATCH 9/9] Renumber the #1165 ADR to 0029, after main's 0027 and 0028 --- ...-live-run.md => 0029-in-progress-marks-only-a-live-run.md} | 0 docs/grill-with-docs/1165-claim-labels.md | 4 ++-- 2 files changed, 2 insertions(+), 2 deletions(-) rename docs/adr/{0027-in-progress-marks-only-a-live-run.md => 0029-in-progress-marks-only-a-live-run.md} (100%) diff --git a/docs/adr/0027-in-progress-marks-only-a-live-run.md b/docs/adr/0029-in-progress-marks-only-a-live-run.md similarity index 100% rename from docs/adr/0027-in-progress-marks-only-a-live-run.md rename to docs/adr/0029-in-progress-marks-only-a-live-run.md diff --git a/docs/grill-with-docs/1165-claim-labels.md b/docs/grill-with-docs/1165-claim-labels.md index ec77bacac..fca84d391 100644 --- a/docs/grill-with-docs/1165-claim-labels.md +++ b/docs/grill-with-docs/1165-claim-labels.md @@ -148,7 +148,7 @@ The options: *Answer:* agreed -*Checked:* written as `docs/adr/0027-in-progress-marks-only-a-live-run.md`, amending ADR 0026's take-over rule. +*Checked:* written as `docs/adr/0029-in-progress-marks-only-a-live-run.md`, amending ADR 0026's take-over rule. ## Settled by earlier answers (shout if any is wrong) @@ -167,7 +167,7 @@ The options: - **Tickets:** a Ticket run inside a Spec run makes no Claim, so its Spec carries the outcome. - **Publication:** a new Spec, published `needs-triage` with the to-spec and to-tickets skills, and three Tickets: Claim endings; waiting Spec runs (blocked by 1); Recovery comments (blocked by 1 and 2). A standalone `ready-for-human` issue, blocked by the Spec, clears the old ready-for-review labels after release. The Spec closes #1165 (Q3.1). - **Related issues:** #585 and #833 get a comment on what the Spec settles and stay open (Q3.2). -- **ADR 0027** records Q1.2 and Q1.5 (Q3.3). +- **ADR 0029** records Q1.2 and Q1.5 (Q3.3). - **Out of scope:** a Run killed outright never ends its Claim (#710). - **One take-over rule for every failure,** Triage runs included: `agent-failed` comes off when the Day shift puts `ready-for-agent` back, takes `agent-failed` off, or closes the issue (Q2.1). A failed Triage run still also gets `ready-for-human`, which is #1695's business. - **Custom processes** count toward the Failure limit and swap `in-progress` for `agent-failed` like any other failure (Q2.2).