lanes: make the automation lanes reusable by any repository #7656

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

   

   github-actionsBot

   on Oct 16, 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: none
   Blocked by: none

   Understood: the goal is a design, then per-lane slices, that move the lanes into ci-workflows as reusable workflows that each consumer configures. The owner's decision settles the trust-model question.

   Decision recorded. The owner answered in the Refinement session (2026-10-26). He rejected one GitHub App per repository ("One app per repo sound like a terrible maintenance burden to me") and accepted the recommendation that followed:

   go w/ recommendations

   Decided: one lanes App, installed across the organization, and one admission row per repository.

   • A consumer repository in the organization is admitted by adding its id to the broker's existing allowlist (BROKER_ALLOWED_REPOSITORY_IDS, azure-iac src/lanes-token-broker/src/claims.mjs:170-171), plus its grant set in a central grant file in this repository. Adopting a lane needs no broker code change and no copy of the lanes: the consumer calls the reusable workflows.
   • The broker keeps reading grants from this repository's main (azure-iac authorize.mjs:6-8), never from the consumer's, so a consumer cannot grant itself more than its row says. A repository with no row gets no token.
   • Public consumers outside the organization do not get this App's token. They run the reusable lanes with their own App or the built-in GITHUB_TOKEN.

   (Decision comment: #7656 (comment))

   That decision settles the open questions. The start condition also holds, since ADR 0082 is accepted.

   _{Automated triage, applied by the lanes App.}
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.

   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 16, 2026
4. github-actions

   added the

   Task

   issue type on Oct 16, 2026
5. kyle-sexton

   removed

   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 24, 2026
6. kyle-sexton commented on Oct 24, 2026

   

   kyle-sexton

   on Oct 24, 2026

   MemberAuthor

   More actions

   Released for re-triage under the owner's 2026-10-24 rule: an issue stops for a person only for an intent or vision question, a security call, a host or attended run, or spend outside prepaid credit. The hold label came off and intake triage runs again now; it re-applies a hold, with a numbered question, when one of those applies.

   To hold this issue again, add needs-human (or status: needs-decision) and say why in a comment.
7. 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.

   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 24, 2026
8. github-actions

   changed the issue type from

   Task

   to

   Feature

   on Oct 24, 2026
9. 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: structuralRefactors, migrations, contract changes; cross-cutting and hard to reverse.Refactors, migrations, contract changes; cross-cutting and hard to reverse.

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

   on Oct 24, 2026
10. melodic-automation-lanes commented on Oct 24, 2026

    

    melodic-automation-lanesBot

    on Oct 24, 2026

    Contributor

    More actions

    Not admitted to the issue lane: no trusted-human acceptance criteria: a listed human must put the confirmed - [ ] criteria in the body or post them as their own comment, or, on an issue a listed human filed, intake's newest refinement comment must hold them unedited; Size large: the split into sub-issues at intake is pending (owner Q93). Admission takes the issue once each of those is met, when intake triages it again (.github/actions/resolve-config/admission-rules.json).
11. 10 remaining items

    Load more
12. melodic-automation-lanes

    added

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

    admission-deferred

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

    and removed

    admission-deferred

    on Oct 26, 2026
13. melodic-automation-lanes commented on Oct 26, 2026

    

    melodic-automation-lanesBot

    on Oct 26, 2026

    Contributor

    More actions

    The work-resolve-issue lane stopped on its funding (funding: no credit or a disabled key), not on this issue. It keeps agent-ready; once the lane is funded again, a person removes and adds agent-ready to restart it.

    Run: https://github.com/melodic-software/claude-code-plugins/actions/runs/40354698247
14. kyle-sexton commented on Oct 26, 2026

    

    kyle-sexton

    on Oct 26, 2026

    MemberAuthor

    More actions

    Design for criterion 1: decisions taken on the evidence. The design is ADR 0085
    (docs/adr/0085-run-org-lanes-from-ci-workflows-under-one-lanes-app-with-central-grants.md, in the
    pull request that delivers criterion 1). The open questions the draft raised were decided as
    recommended, under the owner's standing rule to decide on facts and loosen no security boundary:

    1. Trusted actors (criterion 4): every consumer is judged against the central list on this
       repository's main, plus optional additions in its grant row. ADR 0049 Decision 1 already
       requires one central list every lane reads.
    2. Reusable binding: the broker accepts a ci-workflows reusable only at a commit listed in the
       central grant file. ci-workflows does not join the trust root.
    3. Admission: three fail-closed rows, not two: the azure-iac BROKER_ALLOWED_REPOSITORY_IDS
       constant, the central grant row, and the github-iac LanesBrokerClientRepositories entry. The
       third exists because the broker denies a repository with no kill-switch variable
       (azure-iac kill-switch.mjs:51-54), and that variable comes from the github-iac entry
       (OrgCiRouting.cs:91-98). A missing row denies; it never widens. The allowlist row is a code
       constant (azure-iac BrokerConstants.cs:79), so each admission is still an azure-iac pull
       request and an owner-run deploy. Consumers do not join
       trust-root: today it adds no effective rule over the organization base ruleset
       (github-iac OrgRulesets.cs:79-105 against :152-187).
    4. Protecting the central files: the grant file and the trusted-actor list join a new
       UNIVERSAL_REFUSE class in patch-rules, so no lane patch can change them. Every lane model
       activity is effect: read, so lanes change files only through scripted patches.

    Corrected premise. The decision says the broker "keeps reading grants from this repository's
    main (authorize.mjs:6-8)". Those lines cover the resolve-config code only. The broker reads grant
    data and trusted actors from the caller's own main (azure-iac authorize.mjs:260-268,298, the latter through
    readTipFiles), and claims.mjs:232-235 requires the caller's own workflow. Central reading is a
    new one-time broker change, sliced as the azure-iac prerequisite, with a matching amendment to
    github-iac ADR 0015 Decisions 2 and 5.

    Slices to file under this issue: three prerequisites (the central grant file, the broker change,
    the shared reusables and resolve-config move), then one per lane: work-unblock, intake-triage,
    work-resolve-issue, pr-refine, pr-unblock, pr-merge.
15. melodic-automation-lanes

    added

    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

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

    

    melodic-automation-lanesBot

    on Oct 28, 2026

    Contributor

    More actions

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

    Why, in the run's own words:

    Nothing to change in the repository. The design this issue asks for is already merged on main as docs/adr/0085-run-org-lanes-from-ci-workflows-under-one-lanes-app-with-central-grants.md (accepted, 2026-10-26). That ADR covers the decision's first four acceptance criteria. The one open criterion is "Slices are filed under this issue, one per lane, each with its own criteria". That means writing to the tracker, which this lane cannot do: it has no tracker or gh access and only produces a patch. Next step for a person: publish the slices with /work-items:decompose from ADR 0085's Migration section. A draft of 13 slices is in the lane scratchpad as slices-draft-7656.md:5 prerequisites, 6 lanes (work-unblock, intake-triage, work-resolve-issue, pr-refine, pr-unblock, pr-merge) and 2 closeout items. Then close this issue.

    What the run says it did not do:

    • Slices were not filed under ＃7656 (acceptance criterion 5). This lane cannot write to the tracker.
    • Not checked: ADR 0085 links the decision as issuecomment-6418743610, but the decision comment the runner kept is issuecomment-6418576234. Confirm which comment it should link.

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

    To retry, remove needs-human and add agent-ready again.
17. kyle-sexton commented on Oct 29, 2026

    

    kyle-sexton

    on Oct 29, 2026

    MemberAuthor

    More actions

    Re-triage: decompose from ADR 0085's Migration section. The design is merged: docs/adr/0085-run-org-lanes-from-ci-workflows-under-one-lanes-app-with-central-grants.md, accepted 2026-10-26. It covers criteria 1 to 4 of the owner's decision (#7656 (comment)). Criterion 5, filing the slices, is what remains, and it is tracker work, not a lane change. Nothing here goes to the owner. The owner already decided the trust model, and each admission deploy stays a step the owner runs, as ADR 0085 Decision 7 records.

    The Migration order is sequential. Steps 1 and 3 can start now, and Automation Lanes builds both under this issue (no child issues), because both change lane trust controls. Each later step is filed in the repository it changes once the steps before it close:

    1. github-iac: amend ADR 0015 Decisions 2 and 5 to read grants and trusted actors centrally (ADR 0085 Decisions 2, 3 and 7). Built now by Automation Lanes.
    2. Measure one week of log-api-budget output for this repository's lanes and pr-pipeline-sandbox's lanes, and post it here. A host session reads the run logs. This step gates only step 8.
    3. Here: add the central grant file under .github/actions/resolve-config/, with rows that reproduce today's grants for this repository and pr-pipeline-sandbox. Add the grant file and the trusted-actor list to a new UNIVERSAL_REFUSE class and to the patch-rules.schema.json enum (Decision 6). Also correct ADR 0085's decision link, which points to the deleted duplicate (issuecomment-6418743610), to issuecomment-6418576234. Built now by Automation Lanes' builder, since it changes a lane trust control.
    4. azure-iac: the one-time broker change (Decision 7). It accepts both the same-repository reusable and the ci-workflows reusable at a listed SHA, both reading grants centrally. Filed when 1 and 3 close. Its deploy is an attended step.
    5. ci-workflows: move the shared reusables, request-lane-token, check-kill-switch, the trusted-trigger gate and resolve-config, with a token-source input. This fixes the layout assumptions in fix(source-control): review-venue.sh gives absent, stale and healthy for the same repository minutes apart #9086 and fix(source-control): review-venue misses review lanes that call pr-review-cli.yml #9601. Filed when 4 closes.
    6. One slice per lane, pr-pipeline-sandbox first, then this repository, in this order: work-unblock, intake-triage, work-resolve-issue, pr-refine, pr-unblock, pr-merge. Each one changes .github/workflows callers, so it goes to the builder. Filed one at a time as the previous lane lands.
    7. azure-iac: remove the same-repository reusable path after the last lane moves.
    8. Admit the first new repository by its three rows (Decision 5). This is an attended deploy, after step 2's numbers.

    This issue closes when step 8 lands.
18. 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.

    and removed

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

    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 29, 2026