feat(pr-pipeline): let lanes resolve their answered threads on owner-login PRs #10763

Activity

1. 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 28, 2026
2. github-actions commented on Oct 28, 2026

   

   github-actionsBot

   on Oct 28, 2026 – with GitHub Actions

   Last edited by melodic-automation-lanes

   Contributor

   More actions

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

   Size: Medium
   Complexity: Medium
   Uncertainty: Knowable
   Flags: intent
   Blocked by: none

   The decision comment, #10763 (comment):

   Decision recorded.

   Question, asked by the GitHub Support hub session on 2026-10-28 at about 20:5xZ: the rule stated in this issue's body, recommended yes (friction audit, owner standing direction §8).

   The owner's answer, in that session on 2026-10-28 at about 21:0xZ: "go w/ recommendations"

   The acceptance criteria are the - [ ] list in the issue body.

   It settles that the rule in the body is wanted. It does not say which route delivers it, and the refinement's questions 1 and 2 stay open. "Recommendations" could mean the hub's yes or the refinement's lanes App route.

   1. Which route: a resolve-only grant for owner-login PRs, or opening agent PRs as the lanes App (create --pushed)?
      RECOMMENDED: Open agent PRs as the lanes App. Basis: it removes the cause, adds no permission, and is the body's own "weigh first" option.
   2. If agent PRs open as the lanes App, do criteria 1-3 still cover PRs a person opens by hand on the owner login?
      RECOMMENDED: No, leave those to the person. Basis: docs/conventions/pr-pipeline/README.md says address-feedback serves lanes App PRs only.

   To answer, post a comment that starts with this line:

   **Decision recorded.** <answer>
   

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

   added

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

   status: needs-decisionAwaiting a human or maintainer judgment call.Awaiting a human or maintainer judgment call.

   on Oct 28, 2026
4. github-actions

   added the

   Feature

   issue type on Oct 28, 2026
5. melodic-automation-lanes commented on Oct 28, 2026

   

   melodic-automation-lanesBot

   on Oct 28, 2026

   Contributor

   More actions

   The triage verdict left this issue at status: needs-decision:

   • flagged: intent
   • held by status: needs-decision
   • no lanes App verdict comment shows whether an earlier verdict was flagged
6. melodic-automation-lanes

   added

   work-class: structuralRefactors, migrations, contract changes; cross-cutting and hard to reverse.Refactors, migrations, contract changes; cross-cutting and hard to reverse.

   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 28, 2026
7. melodic-automation-lanes commented on Oct 28, 2026

   

   melodic-automation-lanesBot

   on Oct 28, 2026

   Contributor

   More actions

   Refinement. A read-only run explored this repository, searched its issues and pull requests, and read the allowed docs to draft what follows. On an issue a listed human filed, it counts as the issue's spec once posted, while unedited; it is still model text, so check it.

   Intended outcome: Agent PRs open as the lanes App (create --pushed), so address-feedback's existing thread resolution covers them and no new grant is needed; this is the likely outcome but unconfirmed.

   Related work

   • feat(pr-pipeline): let fix-ci adopt idle owner PRs #8997 (related): fix-ci adopts idle owner PRs, which bears on which PRs stay owner-login.
   • feat(pr-pipeline): dispatch address-feedback from the review lanes #7533 (related): dispatches address-feedback from the review lanes, which serves lanes App PRs only.
   • feat(pr-pipeline): merge lanes App pull requests through native auto-merge #9508 (related): lanes App PR handling through native auto-merge; same App-vs-person PR split.

   Open questions

   1. Which route: a resolve-only grant for owner-login PRs, or opening agent PRs as the lanes App (create --pushed)? The issue says an owner decision is recorded in a comment, but there are no comments.
      RECOMMENDED: Open agent PRs as the lanes App, which removes the cause and adds no permission. Basis: The issue's own 'remove the cause' option and acceptance criterion 4; no **Decision recorded.** comment exists.
   2. If agent PRs open as the lanes App, do criteria 1-3 still apply to PRs a person opens on the owner login by hand? Those would still fail with 'Resource not accessible by integration'.
      RECOMMENDED: No: leave person-opened PRs to the person, so the grant is dropped and criteria 1-4 become checks on lanes App PRs. Basis: docs/conventions/pr-pipeline/README.md:232 says every address-feedback round goes only to lanes App PRs.
   3. If the grant route is chosen, how does the lane check that a thread is outdated, was replied to by the lane, was not written by a person, and is not a CRITICAL security-lane thread?
      RECOMMENDED: Resolve only when the thread is outdated, its first comment is by the lanes App and not CRITICAL, and the lane has replied. Take the actor from the API author, not from comment text. Basis: judgment

   Sources read

   • docs/conventions/pr-pipeline/README.md:224-233: address-feedback rounds go only to lanes App PRs; publish-feedback resolves stale verify-note threads as the lanes App; the post-verify-notes token cannot resolve threads.
   • refine-data/context.json: no maintainer comments, so no recorded decision.

   To answer, post a comment that starts with this line:

   **Decision recorded.** <answer>
   

   _{Automated refinement by the lanes App. Answer with a comment whose first line is **Decision recorded.**.}
8. kyle-sexton commented on Oct 28, 2026

   

   kyle-sexton

   on Oct 28, 2026

   MemberAuthor

   More actions

   Decision recorded.

   Question, asked by the GitHub Support hub session on 2026-10-28 at about 20:5xZ: the rule stated in this issue's body, recommended yes (friction audit, owner standing direction §8).

   The owner's answer, in that session on 2026-10-28 at about 21:0xZ: "go w/ recommendations"

   The acceptance criteria are the - [ ] list in the issue body.
9. 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.

   status: needs-decisionAwaiting a human or maintainer judgment call.Awaiting a human or maintainer judgment call.

   and removed

   status: needs-decisionAwaiting a human or maintainer judgment call.Awaiting a human or maintainer judgment call.

   on Oct 28, 2026
10. melodic-automation-lanes

    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 28, 2026
11. kyle-sexton

    added 2 commits that reference this issue on Oct 29, 2026

    feat(source-control): fall back to the repo agent identity for own-PR…

    ...

    a34f406

    fix(source-control): count only a fixed lane disposition as an own-PR…

    ...

    59b4562
12. kyle-sexton commented on Oct 29, 2026

    

    kyle-sexton

    on Oct 29, 2026

    MemberAuthor

    More actions

    Route decision for lane review threads on owner-login PRs. This was decided on evidence under the owner's standing direction ("Decide on facts, data and metrics ... When the evidence settles a question, act on it"; the direction was re-pasted 2026-10-29 in place of an answer).

    Decision: keep #10848's route.

    • address-feedback serves idle adopted owner PRs. It posts replies and pushes fixes, both under fix-ci's existing adoption rule.
    • The worker tier (feat(source-control): resolve lane-answered outdated threads on owner PRs in the worker tier #10841) resolves lane-answered outdated threads.

    Basis:

    • No new token scope or App grant is needed: fix-ci already pushes to adopted owner PRs.
    • The alternatives are worse:
      • Resolve-only on owner PRs needs a new resolve grant.
      • Opening agent PRs as the lanes App needs App credentials on every machine, because request-lane-token is OIDC-only (action.yml:3).
    • This supersedes this issue's earlier route wherever the two differ. feat(pr-pipeline): answer lane review threads on owner-login PRs from the lanes App #10848 and feat(source-control): resolve lane-answered outdated threads on owner PRs in the worker tier #10841 implement it.