A failure report links the most recent session's log, not the one that caused the failure #911

Activity

1. JacobStephens2

   added

   bugSomething isn't workingSomething isn't working

   on Oct 20, 2026
2. JacobStephens2 commented on Oct 20, 2026

   

   JacobStephens2

   on Oct 20, 2026

   OwnerAuthor

   More actions

   This was generated by AI during triage.

   Agent Brief

   Category: bug
   Summary: A failure report's Session log names the session the failure came from, not the most recent session

   Current behavior:
   When a Run or Spec run fails, the terminal report, the Command log's closing session log: line and the Run notification give one Session log path. For #776, whose cause was a refused Security review, that path was the last session to run (a later CI-fix Repair), not the Security review.

   Desired behavior:

   • The Session log in a failure report is the log of the session the cause came from. That covers a refused or incomplete Security review, a Repair that failed, a Spec review that failed, and an implement session that failed.
   • When the cause comes from no session (CI red with Repairs exhausted, a Declined CI fix, the upstream-move budget, a Harness check, git or GitHub errors), the report either names the most recent session or says no single session caused it. Pick one, apply it consistently, and document it in the guide where the failure report is described.
   • A cause that comes from an earlier session held to the end (a Security review hold reported only after Delivery finishes) still points at that earlier session.
   • The Run notification gives the same path as the terminal report.

   Key interfaces:

   • Where the failure report's Session log is chosen, likely tracked as "the current or last session" during a Command.
   • Where a Security review's outcome becomes a hold (the Security review Outcome): it needs to carry its Session log with it.
   • The terminal report, the Command log's closing lines and the Run notification body.

   Acceptance criteria:

   • A test with a refused Security review followed by a Repair: the failure report and notification name the Security review's Session log.
   • A failing Repair: the report names that Repair's log.
   • A cause with no session behind it follows the documented rule.
   • cargo test, cargo clippy --all-targets -- -D warnings and cargo fmt --check pass.

   Out of scope:

   • Which Harness the Security review runs on (Run the Security review on security.harness when it is set #910).
   • The wording of causes.
3. JacobStephens2

   added

   ready-for-agentFully specified, ready for an AFK agentFully specified, ready for an AFK agent

   in-progressA Claim: thirdshift has taken this issueA Claim: thirdshift has taken this issue

   and removed

   ready-for-agentFully specified, ready for an AFK agentFully specified, ready for an AFK agent

   on Oct 20, 2026
4. JacobStephens2

   closed this as completedin #933on Oct 21, 2026
5. JacobStephens2

   removed

   in-progressA Claim: thirdshift has taken this issueA Claim: thirdshift has taken this issue

   on Oct 21, 2026