Distinguish Spec runs waiting for the Day shift from failed Spec runs #585

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.