Description
The /wr-itil:work-problems AFK orchestrator assembles each iteration's dispatch briefing from the Step 3.6 relevance-evaluator output. That assembly can attach one ticket's evaluator caveat to a different ticket's briefing.
Observed 2026-07-19: the iter prompt dispatched for downstream ticket P054 stated that "the Step 3.6 relevance evaluator flagged P054 as CLOSE-CANDIDATE-WITH-CAVEAT (driver P007 closed; 3 of 8 tasks done, 5 outstanding)" and cited "ADR-026 fix shipped in v2.3.0". Every element of that caveat belongs to a different ticket, P015. The review's caveated CLOSE-CANDIDATE list names P015 with "driver P007 closed", P054 is absent from that list entirely, and the same sweep's P015 re-rate is what cites ADR-026 shipped in v2.3.0. P054's actual state was an unfixed upstream defect with its tracking issue still open.
The evaluator's own per-ticket output was correct here: the caveat genuinely described P015. The defect is downstream of it, in the orchestrator's Step 3.6 to Step 5 briefing assembly attaching that caveat to the wrong ticket.
Symptoms
- The 2026-07-19 P054 iter prompt carried "CLOSE-CANDIDATE-WITH-CAVEAT (driver P007 closed; 3 of 8 tasks done, 5 outstanding)" and "ADR-026 fix shipped in v2.3.0", all facts belonging to P015.
- The downstream review notes list P015, not P054, in the caveated CLOSE-CANDIDATEs section. P054 was auto-transitioned Open to Known Error in the same sweep with no caveat attached.
- The iter's own evidence check contradicted the briefing outright: the named upstream defect was live in the dependency's shipped source and its tracking issue was open.
Workaround
Iter agents re-derive the ticket's state from its own file plus primary evidence before acting on any CLOSE-CANDIDATE caveat in the dispatch briefing, and check the caveat against the review's own caveated-candidates list. The orchestrator's existing framing, that the evaluator is unreliable and iters should investigate on real evidence, partially mitigates the consequence but does not prevent the misattribution.
Affected plugin or component
@windyroad/itil: the work-problems orchestrator's Step 3.6 to Step 5 iter-prompt assembly.
Frequency
Observed once (2026-07-19). Structurally exposed on any iteration dispatched while evaluator caveats exist for other tickets in the same sweep, which is the normal state of a multi-ticket backlog.
Versions
- Local plugin:
@windyroad/itil@0.59.2
- Upstream package:
@windyroad/itil@0.59.2
- Claude Code CLI: 2.1.219 (Claude Code)
- Node: v24.16.0
- OS: Darwin 25.3.0 x86_64
Evidence
The failure mode worth guarding is a blind close: an iter agent that trusts the briefing without re-deriving would close an unfixed ticket on another ticket's evidence. It is reversible via a transition back to known-error plus git history, but it quietly degrades what an AFK loop is for. The maintainer cannot tell a trustworthy disposition from an untrustworthy one without redoing the iteration's work.
Suggested direction: key the evaluator metadata to the ticket ID at assembly time rather than carrying a sweep-level caveat list into a per-ticket prompt, and assert during assembly that a caveat's named ticket ID matches the ticket being dispatched.
Additional context
Sibling of #306 and the evaluator-precision family, but a distinct defect with a distinct fix locus. Those are about what the evaluator concludes; this is about which ticket the orchestrator attaches a conclusion to.
Cross-reference
Reported from the downstream addressr project; tracked locally as P061 in its docs/problems/ directory.
Description
The
/wr-itil:work-problemsAFK orchestrator assembles each iteration's dispatch briefing from the Step 3.6 relevance-evaluator output. That assembly can attach one ticket's evaluator caveat to a different ticket's briefing.Observed 2026-07-19: the iter prompt dispatched for downstream ticket P054 stated that "the Step 3.6 relevance evaluator flagged P054 as CLOSE-CANDIDATE-WITH-CAVEAT (driver P007 closed; 3 of 8 tasks done, 5 outstanding)" and cited "ADR-026 fix shipped in v2.3.0". Every element of that caveat belongs to a different ticket, P015. The review's caveated CLOSE-CANDIDATE list names P015 with "driver P007 closed", P054 is absent from that list entirely, and the same sweep's P015 re-rate is what cites ADR-026 shipped in v2.3.0. P054's actual state was an unfixed upstream defect with its tracking issue still open.
The evaluator's own per-ticket output was correct here: the caveat genuinely described P015. The defect is downstream of it, in the orchestrator's Step 3.6 to Step 5 briefing assembly attaching that caveat to the wrong ticket.
Symptoms
Workaround
Iter agents re-derive the ticket's state from its own file plus primary evidence before acting on any CLOSE-CANDIDATE caveat in the dispatch briefing, and check the caveat against the review's own caveated-candidates list. The orchestrator's existing framing, that the evaluator is unreliable and iters should investigate on real evidence, partially mitigates the consequence but does not prevent the misattribution.
Affected plugin or component
@windyroad/itil: thework-problemsorchestrator's Step 3.6 to Step 5 iter-prompt assembly.Frequency
Observed once (2026-07-19). Structurally exposed on any iteration dispatched while evaluator caveats exist for other tickets in the same sweep, which is the normal state of a multi-ticket backlog.
Versions
@windyroad/itil@0.59.2@windyroad/itil@0.59.2Evidence
The failure mode worth guarding is a blind close: an iter agent that trusts the briefing without re-deriving would close an unfixed ticket on another ticket's evidence. It is reversible via a transition back to known-error plus git history, but it quietly degrades what an AFK loop is for. The maintainer cannot tell a trustworthy disposition from an untrustworthy one without redoing the iteration's work.
Suggested direction: key the evaluator metadata to the ticket ID at assembly time rather than carrying a sweep-level caveat list into a per-ticket prompt, and assert during assembly that a caveat's named ticket ID matches the ticket being dispatched.
Additional context
Sibling of #306 and the evaluator-precision family, but a distinct defect with a distinct fix locus. Those are about what the evaluator concludes; this is about which ticket the orchestrator attaches a conclusion to.
Cross-reference
Reported from the downstream addressr project; tracked locally as P061 in its
docs/problems/directory.