Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#6,989 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
8/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
github-actions
Área
ci-cd, devtools

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Shell
Estrellas
22
Forks
2
Merge medio
8 h 24 min
PR fusionados (30 d)
947

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de melodic-software/claude-code-plugins

Todos los issues de melodic-software/claude-code-plugins

Issues similares

Más issues de Shell/Bash

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.