Surface Spec human gates early and provide actionable continuation instructions #586

This was generated by AI during triage.

Problem

In the 17-hour Spec run on #427, the final notification listed #550–#552 as “unready: labelled needs-triage.” Their specs already explained the required human decision: grade trial findings, choose the Security review mode, write the choice into the Tickets, then relabel them.

The operator needs this information before a long run ends, and needs concrete instructions for continuing afterward. Thirdshift already preserves failed work and supports Continuations; improving visibility should build on that behavior.

Proposed behavior

• At startup, summarize known human gates and their affected Tickets while allowing independent ready Tickets to run.
• Refresh the summary when graph re-reads reveal that gates changed.
• On an incomplete outcome, provide a correctly quoted continuation command that preserves the relevant original Command options.
• Explain the required human actions using available issue context and links. Distinguish observable facts, such as labels and blocker edges, from a decision description that requires interpretation.
• Separate execution failures, blocked dependents, and human-gated work in the final notification, with links to the affected issues, PRs, and logs.
• Describe relabelling as an operator action after a decision is made; do not change readiness automatically.

Decisions needed

• Where should early gate summaries appear: Command output, Spec PR checklist, an early notification, or a combination?
• How should a decision's description be obtained reliably without adding an agent session just to interpret Ticket prose?
• Which original options must a continuation command retain, and how should an unavailable Model or Harness be handled?
• Should this be implemented independently of the proposed waiting outcome? Clear reporting should still work with current Failed spec run semantics.

Validation targets

• A Spec with both ready and human-gated Tickets reports its gates before starting long-running Ticket sessions, and still runs independent work.
• Removing or adding a gate while Tickets run is reflected after the next graph re-read.
• The final continuation command targets the original issue and preserves the agreed Command options without exposing credentials.
• A continuation reuses existing work and skips closed Tickets; it does not imply starting over.
• Human actions are linked to their source issues, and inferred decision descriptions are clearly distinguished from observed tracker state.
• No extra confirmation or human response is required for the ongoing run to continue its independent work.

Scope

Operator visibility and recovery instructions. No automatic human decisions, readiness changes, daemon, or change to completion and merge requirements.

Evidence and related work

• Security runs and the Security review: thirdshift finds, reproduces and fixes vulnerabilities #427, Spec PR Security runs and the Security review: thirdshift finds, reproduces and fixes vulnerabilities #556, and deliberately deferred Tickets The Security review in a Run #550–Old vulnerabilities from a Security review go to the private record #552.
• The final notification reported 13 landed Tickets, one failed Ticket, and three Unready Tickets.
• put run result status in body of notification email as well as link to spec issue in spec run email #219 already requests result status and the Spec issue link in notification bodies; this proposal adds early gate visibility and actionable continuation instructions.
• Refuse to start a Run or Spec run on an issue whose own triage label says it isn't agent work #228 concerns preflight checks of the top-level issue's own labels; it is related but does not cover child Ticket gate summaries.
• ADR 0002 and ADR 0006 define existing Continuations.