feat(pr-pipeline): let the lane resolve answered non-CRITICAL bot threads on owner-login PRs

Problem

Row 15 of the #12284 findings: main's ruleset sets required_review_thread_resolution: true, so an unresolved review thread blocks a merge. On pull requests opened from the owner's login, the owner resolved about 30 bot threads across 16 PRs in 23 hours on 10-27/28 (touchpoint audit T4, not re-measured). Each of those is a manual step that stops a PR the lanes have already answered.

Fix

Let the lane that settles bot review threads (pr-unblock / publish-feedback) also resolve them on owner-login pull requests when the thread is outdated or answered and its finding is not CRITICAL. Leave CRITICAL findings and every human-authored thread to a person.

Done when

On an owner-login pull request, the lane resolves a bot thread that is outdated or answered and not CRITICAL.
A CRITICAL bot finding and any human-authored thread stay unresolved by the lane; a test covers both.
Owner thread resolves per day are measured for 7 days before and after, and posted here.

Filed by the issue-triage session from #12284's findings.

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

Decision recorded.
Agent choice, not an owner answer.
What is left goes to the host queue (host-run): two observations that can only be made after the merge.
Written by the Issue Triage session from the issue history, the body of #12893 and origin/main.

Delivered by 53e1db0 (#12893), against the criteria as amended at 16:10Z and confirmed at 19:05Z:
[quote truncated; the full decision is at the link]

#12634 (comment)

I read this as: let the lane resolve answered or outdated non-CRITICAL bot threads on owner-login PRs. The recorded decision says the implementation and its tests landed in #12893. It settles the open questions. Two observations remain: a live run of the resolve job, and the 7-day after-window measurement of owner thread resolves. Both need a host, so they stay in the host-run queue. No duplicates found.

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

No description provided.

Decision recorded.
Agent choice, not an owner answer.
What is left goes to the host queue (host-run): two observations that can only be made after the merge.
Written by the Issue Triage session from the issue history, the body of #12893 and origin/main.

Delivered by 53e1db0 (#12893), against the criteria as amended at 16:10Z and confirmed at 19:05Z:

A resolve-feedback-threads job in .github/workflows/pr-unblock.yml that checks out only the trusted base with persist-credentials: false, never the PR head, runs no model step, and is the only job holding the added mutate-branch write; publish-feedback keeps its publish-artifact grant and job permissions: met, covered by callers.test.mjs and live-config.test.mjs per the PR's Verification table.
A CRITICAL bot finding and any human-authored thread stay unresolved, and resolve-threads.test.mjs covers both: met.
The probe of the permissions resolveReviewThread needs is posted here (17:29Z: contents: write alone): met.
The before-window baseline is posted (17:33Z, about 182 resolves per day under the owner login).

Left:

On a live owner-login pull request after 53e1db0, the resolve-feedback-threads job is observed resolving an outdated or answered non-CRITICAL bot thread (resolvedBy the lanes App), and a link to that run is posted on feat(pr-pipeline): let the lane resolve answered non-CRITICAL bot threads on owner-login PRs #12634.
Owner thread resolves per day are measured on a host for the 7 days after the job went live, with the same query as the 17:33Z baseline, and posted on feat(pr-pipeline): let the lane resolve answered non-CRITICAL bot threads on owner-login PRs #12634 beside the before-window.

Claim. Lane 6 takes the first open item: find a resolve-feedback-threads run that resolved a non-CRITICAL bot thread on an owner-login PR after 53e1db0, read-only. The 7-day count stays open.

Host check: item 1 is not observed yet. The job works, but no owner-login PR has had a thread it could resolve. Read-only, 2026-11-04 15:30Z.

Owner-login PRs: 184 PRs by kyle-sexton updated since 2026-11-03T19:00Z. All 225 resolved threads on them were resolved by kyle-sexton, none by the lanes App.
Lane PRs, same window: the lanes App resolved 75 threads and kyle-sexton 31. So the job resolves threads where it is allowed to.
Where the job ran: resolve-feedback-threads / run ran in 9 of the 40 newest successful pr-unblock runs. 8 were on lanes App PRs. The one owner-login PR was #13139, job 126490107897, which logged resolved 0 review thread(s) on #13139.
Why docs: fill the Windows Git Bash cells of the wall-clock baseline #13139 got nothing: its one thread (discussion_r4464897644) carries the owner's "pr-fix lane: please fix this finding". resolve-threads.mjs:11 resolves only threads whose every comment is a review bot's or the lanes App's, so skipping it is correct.

Item 1 needs an owner-login PR whose bot thread is answered by the lane, or goes outdated, with no human comment on it. Today that happens only when address-feedback runs on an owner PR without a human prompt on the thread, and owner PRs usually get their threads resolved by their own session first. Left open. Item 2 (7-day count) is due from about 2026-11-10. The Lane 6 claim is released.

Host check 2: item 1 is still not observed. Read-only, 2026-11-05 15:2xZ, covering 2026-11-04T15:39Z onward.

55 successful pr-unblock runs. resolve-feedback-threads / run ran in 24 of them and was skipped in 31.
All 24 were on lanes App PRs (test(evals): add setup check cases for work-items and autonomy #13316 to feat(planning): build the plan view from PLAN.md with links to the Brief, criteria and decisions #13438, e.g. feat(planning): check shape fences anchored by path plus symbol in the citation gate #13415, author app/melodic-automation-lanes). Each logged not opened by a person on the trusted-actors list; nothing is resolved, the designed early return for a non-owner PR (resolve-threads.mjs:116-118). None logged a resolved N review thread(s) line.
No owner-login PR got a run of the job in this window, so item 1 still has no case to observe. Lane 6 will check again later. The 7-day count stays open.

Claimed by the Automation Lanes host session (aee81595), assigned by the hub: finding why the resolve job never reaches an owner-login PR, then fixing it. Branch fix/12634-resolve-owner-pr-threads.

No gate blocks owner-login PRs; item 1 waits on a qualifying case. Read on main and live runs:

resolve-feedback-threads runs only inside an address-feedback round. On an owner PR the round starts only after the PR and its head commit sit idle for the adoption window, 2 h (feedback-dispatch.mjs:240-249 ownerSkip), with no Hold: line.
After Lane 6's last window the job did run on owner PRs, for example feat(control-claude-code-plugins): map hook and mod changes to UI-surface features #13638 (run https://github.com/melodic-software/claude-code-plugins/actions/runs/42157989905): PRRT_kwDOTCGFQM60WEDx: left open (left-open), resolved 0 review thread(s) on #13638. Also fix(harness-ops): mark inventory validated against Claude Code 2.1.318 #13598 (run 42123585011) and docs: fill the Windows Git Bash cells of the wall-clock baseline #13139. Each time the lane's answer was UNCERTAIN or the finding stood (left open by design, resolve-threads.mjs:104), or the thread already carried an owner reply, which makes it human-joined. The owner's sessions then fixed, replied and resolved within 33 to 65 min.
Item 2 is covered: workflow-gates.test.mjs:486-505 (a person's PR runs the job), resolve-threads.test.mjs:61-88, 134-146, 168-176 (CRITICAL and human threads stay open). pr-unblock 1340/0, resolve-config 933/0 on main.

So item 1 needs an owner PR idle 2 h after its head is reviewed, holding a bot-only thread with no human reply, that the round answers VALID/fixed or finds outdated. No code change is needed; this stays open for that observation and item 3's 7-day measure.

Navigation Menu

Repository navigation

feat(pr-pipeline): let the lane resolve answered non-CRITICAL bot threads on owner-login PRs #12634

Problem

Fix

Done when

31 remaining items

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

feat(pr-pipeline): let the lane resolve answered non-CRITICAL bot threads on owner-login PRs #12634

Description

Problem

Fix

Done when

Activity

github-actions commented on Nov 3, 2026

github-actions commented on Nov 3, 2026

github-actions commented on Nov 3, 2026

31 remaining items

kyle-sexton commented on Nov 4, 2026

kyle-sexton commented on Nov 4, 2026

kyle-sexton commented on Nov 4, 2026

kyle-sexton commented on Nov 5, 2026

kyle-sexton commented on Nov 6, 2026

kyle-sexton commented on Nov 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions