pr-pipeline: ticket-to-merge lane decisions (pr-unblock, assess-risk) and SDLC gaps

Fermée
  • Quelque chose ne va pas ?
#6,989 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
8/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
Active
Stack technique
github-actions
Domaine
ci-cd, devtools

Piste de recherche

This is a planning issue, not a code change: the decisions and gaps are listed for a later /planning:design pass. Start by reading the pr-pipeline README and its Concurrency table, pr-pipeline.yaml, and ADR 0051, which the issue amends. Done means a design for the pr-unblock lane that the owner approves, not a patch.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

needs-human needs-triage

Refs: #6202

Summary

The owner interview after the first live lane (#6704, pilot #6731) settled the PR-side build order and lane shape. This issue holds those decisions and the gaps an SDLC mapping pass found, so they outlive the local planning notes. Related: #6140 (autonomy alignment), #6720 (kill-switch precedence), #6085 (pstack lanes).

Decisions

  • One pr-unblock lane in stage unblock (replaces pr-update, pr-fix-ci, pr-address-feedback and stage respond). Activities per round, in order: update-branch, fix-ci, address-feedback; a scripted PR-state check picks which apply; one push per round. pr-merge stays separate. "Babysit" is the prose nickname.
  • update-branch acts only on a conflict. A PR that is only behind main is left to the merge queue (main: strict_required_status_checks_policy: false, merge queue ALLGREEN).
  • Regrouping is config. A lane is a thin caller workflow; never-rules move from lanes to activities; splitting an activity out needs only a caller file and a lane-rules row.
  • Concurrency. pr-unblock's run group lets a newer trigger replace a waiting run; pushes go through the shared per-PR write queue that never cancels. The pr-pipeline README gains a Concurrency table, and every new block declares its row.
  • ADR 0051 amendment: workflow_run starts pr-unblock with only fix-ci applying (human merge).
  • Kill switch (#6720): org-only CLAUDE_LANES_DISABLED plus per-repo CLAUDE_LANES_REPO_DISABLED; every lane and the broker stop if either is true. A short design checks GitHub variable precedence and visibility first.
  • assess-risk activity in verify at ready: read-only, outputs a work class and a risk check that pr-merge reads; the stricter of the issue's work-class label and the assessment wins.
  • No cross-PR model-run cap yet; add one only on usage telemetry.
  • Testing before merge: lane-power PRs run a sandbox case first; skill-text changes rely on evals plus one pilot run.
  • Naming: every stage, lane, activity and group name is checked for meaning, size and grouping before it is built.

Build order

  • Map every lane setting and its home; move what can move into pr-pipeline.yaml
  • Naming review of the stage, lane and activity names
  • pr-unblock with update-branch only (own /planning:design, approved plan)
  • Phase 3 findings store, Phase 4 verify lanes (incl. assess-risk), Phase 5 label protocol
  • fix-ci and address-feedback slots; then pr-merge
  • In parallel: #6720 design and fix; review-lane allowlist for the lanes App bot; triage fixes (ci-workflows#662, a reason in the escalation note, no thanks line on owner issues); then backlog re-triage in batches of 25 and an attend-queue pass

Gaps found

Ticket-to-merge path today (repo map):

  • Nothing unattended flips a draft to ready
  • The unattended path skips define, design, plan and local review (work opens the PR with create --pushed); the attended path runs review and verify three times
  • No owner for post-merge bookkeeping (track done, container close-out)
  • Triage runs in two places (CI intake lane and local /work-items:triage) with no rule for which decides
  • Merge authority moves from the local babysit loop to pr-merge in one switch
  • Adding a lane touches a workflow file, a lane-rules row, test fixtures and the standards vocabulary, all human-merged

Stages and gates outside sources include that the plan lacks (research with sources, verified 2026-10-11):

  • Build/package; monitor after deploy with rollback; incident response; postmortem; migrations before and after deploy
  • "Release" means either a version cut or exposing deployed code; define it (version cut) and add rollout if feature flags come into scope
  • Gates: plan approval before work, CI-run approval on agent PRs, PR publish as an explicit step, agent approval separate from review

Prior art already tracked elsewhere that the plan should absorb or decline (pstack, Pocock, 2,000-PRs effort):

  • Swarm verifiers: one owner agent per PR, several independent verifiers give one verdict on the exact SHA with live proof (#6085)
  • Per-app verification skill generated and kept current (verify-<app>), beyond testing:run-e2e (#6085)
  • Learn stage mines session corrections into skills or lint rules (#6085)
  • Post-merge smoke check against the deployed environment and a silent-revert canary (#6202)
  • A single merge.authority field and rung lowering after a bad merge (#6202)
  • Whether a CI lane may fix review threads, which address-feedback depends on (#6810)
  • Route new work by size and fog, and slice it into agent-ready versus human-in-the-loop (#6729, #6917)

Open, deferred to the pr-unblock design

Activity choice from PR state; how fix-ci runs head code and pushes (owner's call); stage-level effect limits (owner's call); interim attempt cap; merge-queue dequeue and UNKNOWN mergeability; push batching; write-queue scope; ship prerequisites. Post-merge failure response (revert or fix forward) stays open from an earlier round.

🤖 Generated with Claude Code

Langage dominant
Shell
Étoiles
22
Forks
2
Merge moyen
1 h 13 min
PR mergées (30 j)
954

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de melodic-software/claude-code-plugins

Toutes les issues de melodic-software/claude-code-plugins

Issues similaires

Plus d'issues Shell/Bash

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.