feat(pr-pipeline): read lane limit settings from a limits leaf in pr-pipeline.yaml #7764

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

   

   github-actionsBot

   on Oct 17, 2026 – with GitHub Actions

   Contributor

   More actions

   Thanks for the report. Automated triage handed this issue to a maintainer.

   _{Automated triage. A maintainer reviews it.}
3. github-actions

   added

   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.

   on Oct 17, 2026
4. kyle-sexton commented on Oct 18, 2026

   

   kyle-sexton

   on Oct 18, 2026

   MemberAuthor

   More actions

   This was generated by AI during triage.

   Verified: request valid

   Default branch: 30e97ed (not applicable)
   Open linked PRs: none (parent #7737 merged and hard-coded these values)

   The constants are still hard-coded on main, each with a comment pointing at this issue: FALLBACK_RESET_MS and MAX_LIMIT_STOPS (per head) in .github/scripts/pr-unblock/limit-stop.mjs:17-23 plus its inline 1 h to 7 d clamp; FALLBACK_RESET_MS and clampReset in .github/scripts/work-resolve-issue/report-outcome.mjs; RESTARTS_PER_RUN and MAX_LIMIT_STOPS (per issue) in .github/scripts/work-unblock/label-unblocked.mjs:73-78. pr-pipeline.yaml and its schema have no limits leaf; resolve-config emits loop with defaults, which is the pattern to copy. The two MAX_LIMIT_STOPS constants count different things (per PR head vs per issue since a person last added agent-ready). Config plumbing differs: work-unblock and the write runner already resolve config and feedback-dispatch.mjs resolves it in-script, but pr-unblock-dispatch.yml runs dispatch.mjs with no resolved config.

   needs-human was applied by the intake lane at filing, not by a person; the item is fully specified, additive, and keeps today's values as defaults, so it is routed to the lane with the defaulted decision below.
5. kyle-sexton

   added

   status: confirmedA maintainer confirmed the item is real and in scope; ready to be worked.A maintainer confirmed the item is real and in scope; ready to be worked.

   on Oct 18, 2026
6. kyle-sexton commented on Oct 18, 2026

   

   kyle-sexton

   on Oct 18, 2026

   MemberAuthor

   More actions

   This was generated by AI during triage.

   Agent Brief

   Type: Feature
   Summary: Move the lane limit-stop constants into a new limits leaf of the pr-pipeline config, with schema defaults equal to today's values so behavior does not change.

   Current behavior:
   The limit-stop restart logic from #7737 hard-codes five values: the 5-hour fallback reset, the 1-hour-to-7-day reset clamp, 5 restarts per hourly sweep, 3 limit stops per head before the pr-unblock dispatchers stop re-dispatching, and 3 limit stops per issue before the work-unblock sweep hands the issue to a person. Each carries a comment pointing at this issue.

   Desired behavior:
   The pr-pipeline schema gains an optional limits object with integer leaves (see the decision comment for names and units) defaulting to today's values. resolve-config emits a resolved limits object with those defaults, next to loop. Each consumer reads its values from the resolved config instead of a constant: report-outcome (fallback reset and clamp, through clampReset); the work-unblock sweep (clampReset, restarts per run, limit stops per issue); the pr-unblock dispatch and feedback-dispatch path (limitResetsAt, anyHandles). The pr-unblock dispatch path gets the resolved config the way feedback-dispatch resolves it inside the script, so no workflow file needs editing.

   Key interfaces:

   • pr-pipeline schema: new limits property, additionalProperties: false, integer leaves with minimum 1 and today's defaults
   • resolve-config output: new limits object
   • clampReset(resets, from, limits), limitResetsAt(run, limits), anyHandles(runs, { now, limits }) take the values as parameters
   • restartLimited takes its cap and stop count from the resolved config
   • the convention README and CHANGELOG entry for the new leaf

   Acceptance criteria:

   • The schema accepts a config with and without a limits leaf, and rejects an unknown key under limits or a non-positive integer.
   • With no limits leaf, the resolved limits equals today's six values.
   • A test per consumer (report-outcome, work-unblock sweep, pr-unblock limit stop) shows a non-default value changes its behavior.
   • The existing limit-stop, report-outcome, work-unblock and resolve-config suites pass with unchanged expectations under defaults.
   • No source comment points at this issue, and no FALLBACK_RESET_MS, RESTARTS_PER_RUN or MAX_LIMIT_STOPS constant remains.
   • The repository's pr-pipeline.yaml either omits limits or sets exactly the defaults.

   Out of scope:

   • Changing any value from today's.
   • Making other lane caps configurable (max-turns, RUN_WINDOW_MS, the review-round caps in loop).
   • Editing any workflow file.
7. kyle-sexton commented on Oct 18, 2026

   

   kyle-sexton

   on Oct 18, 2026

   MemberAuthor

   More actions

   This was generated by AI during triage.

   Decision defaulted: include all of them (fallback reset, reset clamp, restarts per run, both stop caps), keep the issue's key names limits.fallback-reset and limits.restarts-per-run, add limits.reset-clamp-min / limits.reset-clamp-max, give the two stop caps separate keys limits.limit-stops-per-head and limits.limit-stops-per-issue, and express every duration as integer hours (documented in the schema description) — veto before merge
   Basis: verified, the issue body and the code comments name limits.fallback-reset and limits.restarts-per-run (.github/scripts/pr-unblock/limit-stop.mjs:17, .github/scripts/work-unblock/label-unblocked.mjs:73); the two stop caps count different things (limit-stop.mjs:21-23 vs label-unblocked.mjs:76-78); every existing leaf in docs/conventions/pr-pipeline/pr-pipeline.schema.json is a plain integer. All choices are reversible schema edits before any consumer depends on them.
8. kyle-sexton

   added

   priority: lowNice-to-have, cosmetic, or speculative; opportunistic.Nice-to-have, cosmetic, or speculative; opportunistic.

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

   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.

   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.

   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.

   status: confirmedA maintainer confirmed the item is real and in scope; ready to be worked.A maintainer confirmed the item is real and in scope; ready to be worked.

   on Oct 18, 2026
9. kyle-sexton

   added the

   Feature

   issue type on Oct 18, 2026
10. kyle-sexton

    added

    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

    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 18, 2026
11. melodic-automation-lanes

    added a commit that references this issue on Oct 18, 2026

    feat(pr-pipeline): read lane limit settings from a limits leaf in pr-…

    ...

    84d367f
12. kyle-sexton

    closed this as completedin #7918on Oct 18, 2026