tjrtm/equipo-en-bucle

El Bucle del Equipo

Usa esta habilidad cuando dos equipos o agentes cooperativos trabajen en un mismo repositorio. Reemplaza Equipo A y Equipo B con los nombres configurados. El Propietario es un humano y es la autoridad para decisiones de prioridad, fusión, despliegue, congelación y políticas.

Incorporación: configuración en cinco minutos

1. Copia esta habilidad en el repositorio de destino e instala el adaptador para la herramienta de agente activa.
2. Copia templates/team-loop.yml a .team-loop.yml; establece los nombres de los equipos y gate_command.
3. Ejecuta scripts/setup-labels.sh --repo OWNER/REPO.
4. El Propietario debe crear un issue de coordinación fijado y un issue etiquetado como ready.
5. Cada equipo lee este archivo, reclama como máximo un elemento y usa el encabezado de estado configurado.

Roles

• Propietario: crea o promueve trabajo listo; publica decisiones directas Propietario: en sus propias palabras; autoriza fusiones y despliegues, excepto dentro de un mandato escrito con alcance y hora de finalización UTC.
• Equipo A / Equipo B: construyen, prueban, revisan, reclaman, transfieren y reportan. Usen identidades separadas de GitHub cuando estén disponibles.
• Revisor (opcional): realiza una revisión con contexto nuevo. Requiérelo para rutas o categorías de riesgo configuradas.

Estados del bucle

backlog -> ready -> in-progress -> blocked o needs-owner -> PR de implementación -> ready-for-owner -> fusionado -> deployed.

• backlog no se puede reclamar. Agrupa semanalmente el trabajo de backlog de baja severidad para que el propietario lo promocione.
• ready autoriza implementación, pruebas y apertura de un PR. Nunca autoriza fusión o despliegue.
• Al cerrar un issue, elimina etiquetas de estado obsoletas como in-progress, ready, blocked y needs-owner.

Protocolo de reclamo

1. Vuelve a leer las etiquetas inmediatamente antes de actuar. No reclames trabajo in-progress, blocked o que no sea ready.
2. Ejecuta scripts/claim.sh --repo OWNER/REPO --issue N --team "Team A" --plan "plan corto".
3. El script añade in-progress y una etiqueta de equipo, publica el reclamo y luego verifica el estado. Si pierde una carrera, se retira.
4. Mantén el trabajo en curso igual o por debajo de wip_limit por equipo. Termina, transfiere o bloquea explícitamente un elemento antes de reclamar otro.
5. Para team:any, el primer comentario de reclamo válido gana; el otro equipo se retira. No resuelvas un empate con implementación duplicada.

Comentarios y comunicación

Cada comentario de equipo comienza en su primera línea con:

Estado: <estado> | Equipo: <equipo configurado> | <contexto breve>

Publica solo un reclamo con plan, veredicto de revisión, resultado de puerta, transferencia, pregunta, escalada al propietario, acuerdo o informe de lanzamiento. No publiques comentarios de "iniciado", "en cola", "aún esperando", "reactivado" u otros comentarios ceremoniales. Mantén los comentarios ordinarios en cinco líneas cortas; coloca la evidencia en la descripción del PR o en detalles colapsados.

Solo el Propietario escribe decisiones Propietario:. Los equipos deben enlazar o solicitar un comentario directo del propietario, nunca transmitir uno como autoridad.

Etiquetas y enrutamiento

Usa las etiquetas en reference/labels.md. Un issue listo sin asignar por defecto es para el Equipo A a menos que la configuración indique lo contrario. team:any permite que cualquier equipo lo reclame. Mientras esté inactivo, ayuda al otro equipo en este orden: revisiones solicitadas, preparación o rebase de trenes, luego lotes semanales de backlog. No realices una barrida de errores sin límite sin una solicitud del Propietario.

Revisión, tren, puerta, certificado

1. Cada PR ejecuta comprobaciones ligeras y enfocadas y recibe el nivel de revisión requerido por su riesgo.

2. Un revisor etiqueta los PR completos como ready-for-owner.

3. El ejecutor del tren reúne los PR revisados disponibles en ese momento. Ejecuta:

   scripts/train.sh --repo OWNER/REPO --name train-YYYYMMDD-N PR_NUMBER...
   

4. train.sh añade train-running a cada PR incluido, registra la base y las cabezas, realiza una verificación de conflictos, construye un resultado de fusión temporal e invoca gate.sh una vez.

5. gate.sh vincula el certificado a git rev-parse HEAD^{tree}. Un certificado existente coincidente es evidencia exitosa a menos que se use --force.

6. Si la base o una cabeza de PR cambia, o si la verificación/puerta falla, el tren es inválido. Elimina o divide los PR problemáticos y luego reconstruye el tren. No fusiones trabajo no relacionado mientras train-running retenga el tren.

7. Después de la aprobación directa del propietario o de un mandato activo, ejecuta train.sh nuevamente con --merge --owner-authorization "Propietario: ..." para fusionar las cabezas de PR registradas en orden. Se niega si la base o una cabeza cambió, y verifica el árbol de la rama protegida después de cada fusión.

Despliegue, congelación, retención y pausa

• Despliega solo la rama protegida configurada y solo con un certificado de árbol coincidente, a menos que el Propietario proporcione una excepción registrada.
• Produce un informe de despliegue para el lanzamiento. Etiqueta los PR y issues enviados como deployed; enlácelos al informe único en lugar de duplicarlo.
• freeze detiene nuevas fusiones y despliegues. Trata las lecturas fallidas de etiquetas como congeladas para acciones irreversibles.
• Una retención de tren bloquea fusiones fuera de ese tren hasta que el tren salga.
• En pausa, detén reclamos, trenes, fusiones y despliegues. El Propietario publica una lista de reinicio que nombra los elementos permitidos para reanudar. Vuelve a verificar etiquetas, cabezas de PR, base y certificados antes de reiniciar.

Escalado y mandatos

Usa needs-owner cuando una decisión de producto, seguridad, legal, lanzamiento o propiedad ambigua bloquee el trabajo. Indica el comportamiento observado, las opciones, la recomendación y la fecha límite si existe. Continúa con el trabajo independiente.

Un mandato debe indicar su alcance exacto y expiración UTC, por ejemplo:

Propietario: El Equipo A puede fusionar y desplegar los PR de documentación revisados 41 y 42 hasta el 2026-05-01T18:00:00Z.

Cualquier cosa fuera de ese alcance o después del vencimiento requiere una decisión directa nueva.

Retrospectiva

Al menos semanalmente, ejecuta scripts/scorecard.sh y discute las definiciones en reference/metrics.md. Mejora un cuello de botella medible a la vez. Revisa las ejecuciones de puerta por PR fusionado, latencia de reclamo, tiempo de ciclo, cambio neto en la cola, tamaño medio de lote, proporción certificada y tasa de fallos por cambio.

Lee reference/rules.md para las reglas normativas numeradas y reference/comment-templates.md antes de publicar estado.