You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat(work-items): investigate-only mode on the bug path #11877
Some bugs need their cause found without a fix (access missing, fix out of budget). The bug path
(K2) has no way to stop after diagnosis.
Origin: Lauren's (Q530, accepted as drafted).
Fix
A bug_path.mode: investigate setting (default: off, the full path) ends the bug path after the root
cause with one marker comment carrying the outcome, the repro evidence, the ranked causes and what
access was missing. Starting it from an incident thread waits for the chat adapter and is not in
this item.
Done when
The schema declares bug_path.mode with values for the full path and investigate; the work skill reads it.
The work skill states the investigate stop point and the marker comment's four parts.
An eval case runs investigate mode and expects no branch, no PR and one marker comment; python3 plugins/evals/skills/validate/scripts/validate-cases.py plugins/work-items/evals and bash plugins/skill-quality/scripts/check-skill.sh plugins/work-items/skills exit 0, and bash scripts/check-changelog-fragments.sh passes with a work-items fragment.
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Small
Complexity: Low
Uncertainty: Known
Flags: none
Blocked by: none
Understood: add a bug_path.mode: investigate setting (default is the full path) to the work-items plugin. In investigate mode the bug path stops after root cause and posts one marker comment with four parts: the outcome, the repro evidence, the ranked causes, and the access that was missing. The work is a schema entry, work skill text, and an eval case. The done-when items are exact. I found no likely duplicates among the open issues. Starting the path from an incident thread is explicitly out of scope.
This records a re-fire of an earlier refusal, not a new refusal. The lanes kill switch stopped run 41326456763, the work-resolve-issue run that agent-ready started, before it did any work; that run ended at 2026-11-01T16:37:11Z. work-unblock has now removed and added agent-ready back to start a fresh run. A kill-switch refusal is no fault in this issue or the lanes, so it never counts against later re-fires; after limits.limit-stops-per-issue of them since a person last added agent-ready or a run last reported, work-unblock waits longer before each one, up to 24 hours.
The work-resolve-issue run that agent-ready started failed or was cancelled before it reported, or it stopped or the token broker refused it because its workflow files differ from main's. work-unblock removed and added agent-ready back to start a fresh run on main's workflow files. If this run ends the same way, it re-fires the issue again, waiting longer each time.
Activity
github-actions commentedon Nov 1, 2026
The triage sweep dispatched intake triage for this issue (attempt 1 of 2).
github-actions commentedon Nov 1, 2026
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Small
Complexity: Low
Uncertainty: Known
Flags: none
Blocked by: none
Understood: add a
bug_path.mode: investigatesetting (default is the full path) to the work-items plugin. In investigate mode the bug path stops after root cause and posts one marker comment with four parts: the outcome, the repro evidence, the ranked causes, and the access that was missing. The work is a schema entry, work skill text, and an eval case. The done-when items are exact. I found no likely duplicates among the open issues. Starting the path from an incident thread is explicitly out of scope.Automated triage, applied by the lanes App.
github-actions commentedon Nov 1, 2026
melodic-automation-lanes commentedon Nov 1, 2026
This records a re-fire of an earlier refusal, not a new refusal. The lanes kill switch stopped run 41326456763, the work-resolve-issue run that
agent-readystarted, before it did any work; that run ended at 2026-11-01T16:37:11Z. work-unblock has now removed and addedagent-readyback to start a fresh run. A kill-switch refusal is no fault in this issue or the lanes, so it never counts against later re-fires; after limits.limit-stops-per-issue of them since a person last addedagent-readyor a run last reported, work-unblock waits longer before each one, up to 24 hours.github-actions commentedon Nov 1, 2026
github-actions commentedon Nov 1, 2026
melodic-automation-lanes commentedon Nov 1, 2026
The work-resolve-issue run that
agent-readystarted failed or was cancelled before it reported, or it stopped or the token broker refused it because its workflow files differ from main's. work-unblock removed and addedagent-readyback to start a fresh run on main's workflow files. If this run ends the same way, it re-fires the issue again, waiting longer each time.github-actions commentedon Nov 1, 2026