Automatización & agentes AFK
Los workflows que hacen correr el tracking solo (responder @claude, auto-labeler) y el runbook de los agentes que trabajan AFK.
La regla de oro: lo mecánico lo hace un workflow, no un humano. Todo lo que
sigue vive en .github/ del repo platform (fuente única de verdad); esta página
explica el por qué y las decisiones.
Las 3 automatizaciones
Cada una es independiente: no hay orden entre ellas, corren en paralelo:
- Runbook AFK
- Review sandwich
- Auto-labeler
Cómo un agente (Claude Code) toma y entrega trabajo sin supervisión en vivo. La versión operativa vive en AGENTS.md del repo (self-contained, la lee el agente al arrancar). El resumen:
Tomar → reclamar
Status = Todo + 0 blockers nativos). Reclamar atómico: asignarse + mover a In Progress antes de empezar (evita que dos agentes tomen el mismo).Entregar → escalar
Closes #N, suite verde en CI. No auto-mergea (lo decide un humano). Escala si se traba >3–5 ciclos o toca tenancy/firma/auth/PII.AGENTS.md + docs/ + ADRs). No se depende de notas fuera del repo.Retirado (ago 2026): existió un cuarto workflow, pm-digest.yml — un status
update semanal (lunes) al Project vía createProjectV2StatusUpdate, para ver el
pulso sin entrar a GitHub. Se eliminó porque no se usaba. El historial de git de
platform conserva el workflow completo; su PAT (AXEL_PROJECT_TOKEN, scope
project) queda sin consumidores.
Cómo auditar todo esto
El setup se validó con un workflow multi-agente adversarial: fan-out por
dimensión (Projects, backlog, automatización, seguridad, cobertura), cada agente
consulta el estado en vivo con gh, verificación adversarial de cada hallazgo
(¿real? ¿importa? ¿ya resuelto?), y síntesis priorizada. Encontró 13 gaps reales
que no se veían a simple vista.