fix(pr-pipeline): let a hand-cleared pr-unblock stop drop off the stalled-stop signal

Problem

The maintenance monitor's stalled lane stop signal (.github/scripts/maintenance-monitor-signals/collect.mjs) counts a pr-unblock stop as stalled when no non-skip pr-unblock / <activity> check started after the lane-stopped comment's last edit. When a person clears a stop by hand (resolves the threads, then dispatches pr-unblock), the run posts a Skipped: not-applicable check, so the stop stays listed as stalled until the head moves.

Neither fix offered on the #10252 review thread holds as written: counting a not-applicable skip as a resolution also counts the other not-applicable skips (fix-ci-context.mjs returns that reason in more than one place), and having clear edit the lanes App comment needs a token scope the report-stop-status job does not hold (contents: read, statuses: write).

Desired behavior

A cleared stop posts a distinct skip reason (for example stop-resolved), and the signal treats a check with that reason, started after the stop comment, as resolving the stop.
A test in collect.test.mjs covers a hand-cleared stop dropping off the list.

Done when

A stop cleared by a person's dispatch is no longer listed as a stalled lane stop at the same head.
Other not-applicable skips still do not count as a resolution.

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: a pr-unblock stop cleared by hand still shows as a stalled lane stop, because the resulting skip is not-applicable. The fix is to add a distinct stop-resolved skip reason to the schema enum, return it from fix-ci-context.mjs and address-feedback.mjs where they set resolved: true, and have collect.mjs treat it as clearing the stop. Other not-applicable skips must not count, and no workflow files change. Tests should cover each change.

The earlier blocker, PR #10252, has merged. I found no open issue asking for the same thing.

_{Automated triage, applied by the lanes App.}

The work-resolve-issue lane stopped partway through this issue and needs a person.

Why, in the run's own words:

blocked on unmerged PR ＃10252: the code this issue changes is not on main. The stalled lane stop signal in .github/scripts/maintenance-monitor-signals/collect.mjs, the pr-unblock report-stop-status job and its clear path are all added by PR ＃10252 (fix/pr-unblock-route-not-park), which is still open. On main (5fb1184), collect.mjs's only lane-stop source reads work-resolve-issue outcome markers, and no stalled-stop signal, report-stop-status job or lane-stopped comment exists. The fix can't be built or tested against this base. Re-run this issue once ＃10252 merges, or fold the change into ＃10252.

What the run says it did not do:

The issue's change (a distinct stop-resolved skip reason and a collect.test.mjs case for a hand-cleared stop) was not built: the code it modifies exists only on open PR ＃10252
review-venue.txt was absent; no diff exists, so there was nothing to review

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

To retry, remove needs-human and add agent-ready again.

Re-triage. The lane stopped because the code it needed existed only on open PR #10252. #10252 merged on 2026-10-28T13:57Z, so that stop is gone. Under the owner's 2026-10-27 rule (stop only for an intent change, a design-changing finding, or a HIGH/CRITICAL security or cost risk), nothing else holds this issue.

No workflow file changes. The skip reason starts in the scripts' own skipReason (.github/scripts/pr-unblock/fix-ci-context.mjs:150, .github/scripts/pr-unblock/address-feedback.mjs:586). It reaches report-check-run through needs.*.outputs.skip-reason, and .github/workflows/pr-unblock.yml already carries stop-resolved (:638, :1916) and reads it to clear a stop (:2591-2592). report-check-run accepts only reasons in the skip-reason enum of docs/conventions/pr-pipeline/pr-pipeline.schema.json (:464).

stop-resolved is added to the skip-reason enum in docs/conventions/pr-pipeline/pr-pipeline.schema.json.
fix-ci-context.mjs and address-feedback.mjs return skipReason: "stop-resolved" where they set resolved: true today. Every other skip keeps its current reason.
.github/scripts/maintenance-monitor-signals/collect.mjs counts a stop-resolved skip as clearing the stop, so a hand-cleared pr-unblock stop drops off the stalled-stop signal.
Tests cover each of the three changes, and each test fails on the current main.
No file under .github/workflows/ changes.

Not admitted to the issue lane: a criterion names .github/workflows/, which the issue lane cannot push (patch-protected-path); a builder session takes it. Admission takes the issue once each of those is met, when intake triages it again (.github/actions/resolve-config/admission-rules.json).

The latest triage verdict holds nothing: admission moved the issue to status: confirmed; its comment says why.

Navigation Menu

Repository navigation

fix(pr-pipeline): let a hand-cleared pr-unblock stop drop off the stalled-stop signal #10434

Problem

Desired behavior

Done when

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

fix(pr-pipeline): let a hand-cleared pr-unblock stop drop off the stalled-stop signal #10434

Description

Problem

Desired behavior

Done when

Activity

github-actions commented on Oct 27, 2026

melodic-automation-lanes commented on Oct 27, 2026

kyle-sexton commented on Oct 28, 2026

melodic-automation-lanes commented on Oct 28, 2026

melodic-automation-lanes commented on Oct 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions