fix\(pr-pipeline\): align every needs-human path with the owner stop rule - part 5 of 6 #11023

Activity

1. melodic-automation-lanes

   added the

   Task

   issue type on Oct 29, 2026
2. melodic-automation-lanes

   added a parent issue on Oct 29, 2026

   • fix(pr-pipeline): align every needs-human path with the owner stop rule #10517
3. melodic-automation-lanes

   marked this as blocking on Oct 29, 2026

   • fix\(pr-pipeline\): align every needs-human path with the owner stop rule - part 6 of 6 #11024
4. github-actions

   added

   needs-triageNot yet classified. Floor until a type and one priority tier are set.Not yet classified. Floor until a type and one priority tier are set.

   on Oct 29, 2026
5. github-actions commented on Oct 29, 2026

   

   github-actionsBot

   on Oct 29, 2026 – with GitHub Actions

   Last edited by melodic-automation-lanes

   Contributor

   More actions

   Proposed work class: work-class: scoped
   Basis: automated intake triage; the lanes App applied this class.

   Size: Small
   Complexity: Medium
   Uncertainty: Known
   Flags: none
   Blocked by: none

   Understood: this is part 5 of 6 of #10517, split at intake. It asks that review rounds hand off to a person on "Unsure: escalate", on a claude[bot] finding with no lane footer, and on feedback-not-converging. It also asks that verify:repeated-fail and verify:too-old stay unlabeled but never clear, so such a PR can't merge unattended. The done-when is concrete and lane-checkable. Sibling parts #11019, #11020, #11021, #11022 and #11024 cover other slices of the same parent, so they are related rather than duplicates.

   _{Automated triage, applied by the lanes App.}
6. github-actions

   added

   priority: mediumReal value, no hard deadline; normal backlog flow.Real value, no hard deadline; normal backlog flow.

   and removed

   needs-triageNot yet classified. Floor until a type and one priority tier are set.Not yet classified. Floor until a type and one priority tier are set.

   on Oct 29, 2026
7. melodic-automation-lanes

   added

   status: readyTriaged, unblocked, and fully specified; eligible to pick up.Triaged, unblocked, and fully specified; eligible to pick up.

   work-class: scopedA briefed fix or small feature; blast radius bounded by the brief, tests exist.A briefed fix or small feature; blast radius bounded by the brief, tests exist.

   admission-deferredAdmitted but waiting for WIP room; the hourly work-unblock sweep labels it agent-ready.Admitted but waiting for WIP room; the hourly work-unblock sweep labels it agent-ready.

   agent-readyFully specified and briefed; eligible for autonomous pickup from the frontier.Fully specified and briefed; eligible for autonomous pickup from the frontier.

   needs-humanHuman-in-the-loop required; autonomous sessions must not resolve items carrying this.Human-in-the-loop required; autonomous sessions must not resolve items carrying this.

   and removed

   admission-deferredAdmitted but waiting for WIP room; the hourly work-unblock sweep labels it agent-ready.Admitted but waiting for WIP room; the hourly work-unblock sweep labels it agent-ready.

   agent-readyFully specified and briefed; eligible for autonomous pickup from the frontier.Fully specified and briefed; eligible for autonomous pickup from the frontier.

   on Oct 29, 2026
8. melodic-automation-lanes commented on Oct 29, 2026

   

   melodic-automation-lanesBot

   on Oct 29, 2026

   ContributorAuthor

   More actions

   The work-resolve-issue lane did not start this issue: it needs a person to make it clearer first.

   Why, in the run's own words:

   For each path, ＃10517 asks for one of two outcomes: route it to a lane (no person stop), or name it in docs/conventions/loop-lane/README.md "When work stops for the owner" as a kept trust control and say why. Neither ＃11023 nor its parent picks one for these paths, and no recorded decision exists. Which should each of these become? (1) A claude[bot] review finding with no lane footer: address-feedback.mjs needsPerson returns true when the root author is not the github-actions[bot] marker account, so past the round cap it escalates feedback-round-cap (route hold, needs-human). Should it be treated as an untrusted reviewer and left untaken, sent to the adjudicator like a claude-review finding, or kept as a person-held trust control? (2) "Unsure: escalate" (pr-pipeline README, line 867) and the feedback-uncertain / feedback-disputed holds: should an Unsure finding go to the adjudicator lane instead of a person, except for the HIGH/CRITICAL security cases the rule keeps? (3) feedback-not-converging (escalation-routes.json route fail, no label; the head just fails): which lane picks the PR up after it stops? Options include a fresh issue-lane run, closing the PR and re-admitting the issue, or naming it as a kept stop. (4) verify:repeated-fail and verify:too-old: no label, and only a person's approval of the head lifts them (merge-holds.mjs). Should a lane clear them (for example by closing the PR and re-admitting the issue for a fresh run, or by re-verifying a too-old PR under a new PR), or should they be named as kept controls? A kept control would bound repeated verifier failures and expired verdict evidence. Each choice changes the primary design of the review and merge lanes, and (1) and (2) touch security-finding paths that the parent says cannot be loosened without a security-review pass. Record a Decision recorded. comment for each and the lane will build it.

   What the run says it did not do:

   • No implementation, tidy, review or test run: the change waits on the owner's choice per path

   Run: https://github.com/melodic-software/claude-code-plugins/actions/runs/40943552674

   To retry, answer the question in a comment whose first line is **Decision recorded.**, then remove needs-human and add agent-ready again.