Repository navigation
Distinguish Spec runs waiting for the Day shift from failed Spec runs #585
Description
This was generated by AI during triage.
Problem
A Spec run skips Unready Tickets while scheduling, but every open Ticket counts as unfinished at completion. Consequently, intentionally deferred human decisions receive the same overall failed outcome as an execution failure.
In #427, Tickets #550, #551, and #552 deliberately remain labelled needs-triage until the Day shift grades the Security review trial findings and chooses a mode. The trial landed as #557, but the decision remained open. These Tickets would have caused “Tickets not done” even if #544's capacity failure had not happened.
This is an intentional existing contract, not an accidental regression: #144 explicitly requires a Failed spec run whenever any Ticket is unfinished.
Proposed behavior
- Introduce a distinct outcome for a Spec run that has exhausted runnable work and is awaiting Day shift action, with no actual execution failure.
- Keep the Spec PR draft, the Spec open, and unfinished Tickets unchecked. Do not start the Spec review or merge an incomplete Spec.
- Name the Tickets awaiting action and their reasons in progress, the Activity log, and the notification.
- For mixed outcomes, retain an overall failure while separating failed Tickets from Tickets awaiting action. The Security runs and the Security review: thirdshift finds, reproduces and fixes vulnerabilities #427 notification should clearly express: 13 landed; A failed fix pauses Security runs; the notification offers fixing; Fencing is documented #544 failed; 3 awaiting review-mode selection.
- Preserve the existing Continuation behavior when the operator returns after resolving the gate.
Decisions needed
- Which situations qualify as waiting: Unready triage labels, external blockers, nested Tickets, or some subset?
- How should dependents of a human-gated Ticket be presented?
- What exit code should a waiting Spec run return, and how should notifications and Activity logs represent it?
- How should cycles, failed blockers, interruptions, and mixed causes retain their distinct meanings?
- What Claim behavior should apply? Waiting must not cause scheduled passes to repeatedly take the same unfinished Spec.
Validation targets
- Independent ready Tickets still run when another Ticket is awaiting a human decision.
- A run with only human-gated unfinished work has the agreed waiting outcome and explains the action needed.
- A run containing a failed Ticket remains failed and reports both the failure and any independent human gates.
- Cycles and interruptions are not silently reported as successful completion or ordinary human waiting.
- An incomplete Spec PR stays draft; no Spec review or Self-merge starts.
- Continuing after the gate is resolved skips closed Tickets and processes newly runnable Tickets.
Scope
Outcome classification and its presentation. No automatic triage decisions, relabelling of human-gated Tickets, partial-Spec merging, or new scheduler.
Evidence and related work
- Security runs and the Security review: thirdshift finds, reproduces and fixes vulnerabilities #427 and Security runs and the Security review: thirdshift finds, reproduces and fixes vulnerabilities #556, with intentionally deferred Tickets The Security review in a Run #550–Old vulnerabilities from a Security review go to the private record #552.
- Trial PR Trial the Security review's two modes #557 explicitly leaves grading and mode choice open.
- Going as far as it can: Failed spec runs #144 defines current completion behavior; ADR 0006 defines Ticket integration and Spec continuation.
- put run result status in body of notification email as well as link to spec issue in spec run email #219 concerns notification body content and is related, but does not define waiting outcomes.
Activity
JacobStephens2 commentedon Oct 20, 2026
Another case: a Spec whose only unfinished Ticket is Unready
Educational-Travel-Adventures/tourbot#880, a Pickup run on 2026-10-20 at 07:57 on dev.etadventures.com:
needs-infobecause its grilling is unfinished.ready-for-agent. It claimed it (in-progress), pushedissue-880, found nothing it could run, and stopped as failed after 34s withTickets not done: #883/#883 unready: labelled needs-info.What this adds to the decisions above:
#855 is a Ticket of #590, which is not ready. Then no Claim, push or failure notification would happen for a run that can't do anything.in-progress. Then "claimed and running" and "claimed and waiting for you" look different without reading the email. Swappingin-progressfor a triage label was considered and rejected, because that would take the issue out of the Claim limit and blur the hand-back label history.JacobStephens2 commentedon Oct 28, 2026
Another case: a Ticket labelled ready-for-human and one outside the Spec's repository
Educational-Travel-Adventures/tourbot#1689, a Pickup run on 2026-10-27 on dev.etadventures.com, failed after 9m 31s:
ready-for-human, so the run skipped it.No Ticket failed. Every unfinished Ticket is waiting on the Day shift, so this run fits the waiting outcome proposed here.
The Cause line also left out why the Tickets were not done (
Tickets not done: #1690, …/orchestration/issues/789). Fixing that wording is split out as #1518 and doesn't need any of the decisions in this issue.JacobStephens2 commentedon Nov 9, 2026
The #1165 grill (Q1.3, Q2.3) settled part of this, now in Spec #1901:
ready-for-agentback on its Spec, notagent-failed#1903): a Spec run that failed no Ticket and is only waiting putsready-for-agentback on its Spec, with noin-progressand noagent-failed, so it doesn't count toward the Failure limit. Pickup passes over it until a Ticket becomes startable. Waiting means every undone Ticket is an Unready Ticket, blocked by Unready Tickets or by work elsewhere, or outside the Spec's repository. A blocking cycle, or any failed or interrupted Ticket, is a failure. If an untrusted edit came after the Spec's last Trusted labelling, it getsneeds-triageinstead.Still open here: the outcome name, exit code, notification and Activity-log wording, and how mixed results are presented.
JacobStephens2 commentedon Nov 10, 2026
Investigation summary
Confirmed against selected Base main at 9eea88c: unfinished human-gated work still fails Ticket accounting even when independent runnable work lands. In src/spec_run.rs:445–457, every nonempty TicketBoard::not_done result becomes a Tickets not done error. account_tickets wraps it as FailedRun, and src/processes/spec.rs returns before Spec review or Delivery. src/run_ending.rs classifies it as failed and returns exit 1.
The passing spec_run::tests::an_unready_ticket_and_what_it_blocks_are_not_started_and_are_named_in_the_lines reproduces the distinction needed: #23 lands, #21 needs-info and dependent #22 never start, yet accounting returns an error. Other passing tests cover outside-repository Tickets, external blockers, cycles, actual failures, interruptions, and gates removed during graph rereads.
Settled work and dependencies
Do not duplicate #1901. Its Tickets #1903 and #1904 settle waiting classification, Claim ending, trust-safe handback, and generated issue comments. They are closed because PRs #1936 and #1940 merged into issue-1901; parent PR #1935 is still open against main. Their implementation is therefore absent from this Base. Coordinate with that work before implementation.
Pickup already passes over Specs without a Startable Ticket (src/ready.rs:564); all 31 ready::tests passed. #1518 is closed and its richer unfinished-Ticket reasons are present in TicketBoard::not_done. #585 remains independent: #1901 explicitly excludes its outcome name, exit code, notification wording, and mixed-result presentation.
Remaining decisions and next steps
Use #1903's agreed waiting/failure classification rather than reopening it. Decide the observable outcome and exit-code contract, summaries for waiting and mixed results, and whether the new outcome needs explicit Inbox treatment. src/run_ending.rs supplies terminal, Activity-log, and notification accounting; src/logs/command_record.rs persists its outcome; src/notification.rs formats notifications. src/logs/reading/inbox.rs:223–243 currently recognizes failures and pauses but has no waiting-Spec category. Simply changing the outcome string could therefore remove these runs from Needs you.
After the questionnaire is answered, shape the remaining work into the proposed two Tickets. Preserve ADR 0006's draft Spec PR and Continuation behavior: unfinished Tickets remain unchecked, the Spec stays open, and no Spec review, ready marking, or Self-merge starts. Retain distinct failure and interruption reporting, including mixed runs. Update the Failed spec run glossary definition, guide exit-code contract, and relevant hand-written site descriptions with the implementation.
Questionnaire
For the Day shift deciding #585:
The repository confirms the behavior. #1901 already settles waiting classification, labels, automatic Pickup continuation, and issue comments; this questionnaire concerns the remaining observable outcome and presentation.
waiting, with a dedicated exit code such as3, or should waiting return0? A dedicated code distinguishes incomplete waiting from completed delivery and execution failure; returning zero makes waiting operationally successful but changes how shell callers interpret success. Apply the chosen contract consistently to direct Spec runs and Commands dispatching them.13 landed; 3 awaiting action; mixed,13 landed; #544 failed; #550, #551, #552 awaiting review-mode selection. Should dependents be listed under their blocking cause, without counting them as additional failed Tickets? The implementation should report factory-known reasons and avoid inferring a business decision from a triage label alone. This settles progress, Activity-log, and notification wording and counts.in-progressmarks only a live Run #1901. Ticket B depends on A and adds mixed-result summaries and dependency-cause grouping. Each includes focused regression coverage and its documentation changes. Neither repeats Spec:in-progressmarks only a live Run #1901's Claim/comment work or Name why each Ticket is not done in a Failed spec run's Cause #1518's cause wording. If Inbox behavior deserves independent scope, make it a third Ticket explicitly.