Repository navigation
note what kind of run it was in notice email (architect, pickup, manual, etc) #709
Description
example email that would be nice to know this for:
subject:
[thirdshift] #707 A Merge run reports "review required" without trying a merge it knows will be refused: merged
body:
Result: merged
Pull request: #708
Session log: /home/jacob/.thirdshift/logs/JacobStephens2/thirdshift/commands/pickup/707-20261016T194201+0000-repair-1.jsonl
Command log: /home/jacob/.thirdshift/logs/JacobStephens2/thirdshift/commands/pickup/707-20261016T194201+0000.log
Built with codex · gpt-6.1-sol · high (configured)
Host: stephens
Took: 1h 11m 50s
Session models:
Listed sessions launched the harness. Requested models are not confirmed by harness evidence.
- implement: codex · gpt-6.1-sol (requested; actual model not reported) · session effort: high
- repair-1: codex · gpt-6.1-sol (requested; actual model not reported) · session effort: high
Activity
JacobStephens2 commentedon Oct 17, 2026
Triage Notes
Architect and Security notifications already identify those Command kinds. Pickup currently reuses the notification of the Run or Spec it dispatches, as the Run notification domain contract explicitly specifies; the Command log path is the current provenance clue.
Next decision: add an explicit Command kind field, or change the subject as well, and confirm that Pickup's kind should be retained alongside the dispatched Run/Spec kind. The software can report
pickupversus a direct issue Command; it cannot reliably call either “manual” or “cron”, since the same command can be typed or scheduled (ADR 0009). Update that domain wording when the new presentation is chosen. Keep one notification per owning Command and quiet skips.JacobStephens2 commentedon Oct 21, 2026
Agent Brief
Category: enhancement
Summary: Every Run notification says which Command sent it: a Run, a Spec run, or a Pickup run that dispatched one
Current behavior:
Architect run and Security run notifications name their Command: in the subject, and in a
Command:line in the body. A Run's or Spec run's notification has the issue subject ([thirdshift] <owner>/<repo>#<n> <title>: <outcome>) and noCommand:line. A Pickup run that took a Ready issue sends the notification its dispatched Run or Spec run would have sent, so it reads exactly like one started on the Issue URL. Only the Command log's path (commands/pickup/…) gives it away.Desired behavior:
Every Run notification's body has a
Command:line, aligned with its other fields:Command: RunorCommand: Spec run.Command: Pickup run, which dispatched a Run, or… a Spec run.A Merge run is a Run, so it reads
Run. Architect run and Security run notifications keep their currentCommand:line, and every subject is unchanged. One notification is still sent per owning Command, and a skipped Pass still sends none. thirdshift can't tell a command typed by hand from one a scheduler started, so the line never says "manual" or "cron".Key interfaces:
command_lines), and the issue subject a Pickup run switches to when it takes an issue (took).Acceptance criteria:
Command: Run, and a Spec run one withCommand: Spec run.Command: Pickup run, which dispatched a Run. One that dispatched a Spec run says so.Out of scope: