/autonomous-delivery es la capa entre un scheduler y /sprint-development. Un pipeline interactivo da por hecho que un humano eligió el ticket, confirmó el estado y está presente si algo se tuerce. Sin nadie en la línea, esas tres suposiciones son falsas. Esta skill no implementa nada: establece qué es cierto, elige trabajo de verdad desbloqueado, se lo pasa a la skill dueña y deja un registro desde el que la próxima corrida puede arrancar.
Su propio worktree, un lock por modo. Lock vivo de otra corrida: sale limpia.
Cuatro fuentes de evidencia en paralelo. Decide la ascendencia en git.
Solo lo desbloqueado de verdad. Una corrida vacía es un resultado correcto.
Despacha la skill dueña. Compuerta de migraciones, handoff sobre la marcha.
Verifica el cierre, rescata registros, suelta el lock, escribe el reporte.
Un cron, una rutina o un despertador programado abre una sesión sin humano presente y le pasa el modo. Si una persona está en la línea y nombró un ticket, esta skill sobra: su único valor es la capa de auditoría, selección y traspaso, y esa capa es puro costo cuando un humano ya eligió.
| Situación | Va a |
|---|---|
| Trabajo por ticket con un humano presente | /sprint-development, directo |
| Sembrar backlog o refinar criterios de un ticket con nombre | /product-management, directo |
| Ramas, pull requests, conflictos | /git-flow-master |
| Definir el producto desde cero | /project-foundation |
| Andamiaje de infraestructura | /project-bootstrap |
| Una tajada TDD de tests unitarios | /unit-testing |
| Una corrida programada, desatendida, con un modo | /autonomous-delivery <modo> |
Cada historia medida terminó siendo una cadena de miles de líneas: dos no entran en el contexto de una corrida. Los topes salen de esa medición, no de la prudencia.
| Modo | Elige | Tope | Despacha a | Escribe código |
|---|---|---|---|---|
| story | La historia de mayor prioridad, desbloqueada de verdad | 1 por corrida, duro | /sprint-development | sí |
| bug | Defectos desbloqueados, primero los más viejos y graves | hasta 3, estrictamente en secuencia | /sprint-development (entrada de bug) | sí |
| discovery | Huecos de refinamiento, épicas o backlog | solo definiciones, hasta discovery_definitions | /product-management | nunca |
La colisión que no puede pasar es dos corridas implementando el mismo ticket en dos ramas. story y bug entran a un worktree propio, creado a mano para poder cerrarlo a mano. discovery no toca código ni crea ramas: trabaja en el checkout común y salta el aislamiento entero.
<<PRIMARY_ROOT>> sale de git rev-parse --git-common-dir, nunca de pwd. Es el mismo valor desde el primario y desde cada worktree. .session/ vive ahí toda la corrida y se lee y escribe por ruta absoluta.
Con nombre generado, nunca fijo. En Claude Code, EnterWorktree. En OpenCode y Codex, la ruta portable: git worktree add fuera del primario, desde origin/<integration-branch>.
bun run worktree:provision copia .env, .vercel/ y lo demás que git ignora. No copia .session/: el lock solo excluye a otra corrida si las dos ven el MISMO archivo.
git fetch y un chequeo de ascendencia contra la rama de integración (o contra producción cuando integración es null). Si está mal, se realinea con git checkout -B. Nunca git reset --hard: la regla #13 lo prohíbe.
Es lock.json, en .session/autonomous-delivery/<modo>/ del checkout primario, con dueño, máquina, worktree, inicio y un latido que se refresca en cada frontera de fase.
| Encuentra | Hace |
|---|---|
| Ningún lock | Lo escribe y sigue. |
| Un lock con latido reciente | Otra corrida es dueña del modo: sale limpia con un reporte que la nombra. No espera, no reintenta, no sigue igual. El próximo disparo es el reintento. |
| Un lock más viejo que lock_staleness_minutes | Abandonado: lo reclama y lo anota en el log de escalaciones. El worktree de la corrida muerta queda para que un humano lo audite y lo quite. |
| Un lock de esta misma sesión | Una fase anterior de esta corrida: sigue. |
Un tracker puede decir "listo para QA" sin nada en la rama de integración: la automatización de merge se dispara con CUALQUIER pull request, también con los internos de una cadena. Toda decisión de dependencia de la fase 2 descansa aquí, así que se verifica, nunca se infiere.
# de más confiable a menos; cuando dos chocan, gana la de arriba y el choque se REGISTRA ascendencia en git contra la rama de integración <- decide pull requests abiertos + estado de ramas en el remoto <- explica estado vivo del tracker <- insinúa archivo de cola / tablero / claims <- reclama roadmap y prosa de diseño <- solo aristas, nunca estado # el chequeo que más se usa, siempre con fetch inmediatamente antes git fetch origin git merge-base --is-ancestor <merge-commit> origin/<integration-branch> # exit 0 == llegó de verdad
Fetch, las cuatro fuentes, el ledger vivo de migraciones con [DB_TOOL] y la protección de ramas por los DOS endpoints: el clásico devuelve 404 cuando la protección es un ruleset. Sin capacidad db (o con stack.database.engine: none) se salta el ledger, se avisa en el reporte y no se reclama ningún ticket que toque el esquema.
Nada en el momento. Cada discrepancia entre tracker y git queda en el log de escalaciones, con evidencia, para que la leas y para que la próxima corrida sepa de qué manera miente este tracker.
Una tabla, no un relato: ticket, lo que dice el tracker, commit de merge, si es ancestro, PR abierto, estado de la rama y un veredicto (merged, claimed-only, in-flight, not-started).
Cuatro entradas, ponderadas y no promediadas. El veredicto de la fase 1 pisa a las otras cuando no coinciden.
| Entrada | Manda sobre | Nunca manda sobre |
|---|---|---|
| .context/dev-roadmap.md | aristas de dependencia, compuertas de mockup, orden | el estado actual de cualquier cosa |
| El tracker, consultado ahora | estado vivo, responsable, changelog | si el trabajo se mergeó |
| Veredicto de la fase 1 | si el trabajo se mergeó | qué hay que construir |
| Cola, tablero o claims | quién tiene qué fila al momento de leer | si una dependencia salió |
Lee el rastro de refinamiento: preguntas bloqueantes abiertas, respuestas de práctica marcadas como borrador, casos borde sin tildar, o un cambio de estado sin comentario que lo explique. Cualquiera significa no listo, diga lo que diga el campo. Es un salteo con razón anotada, no una escalación.
Estimación alta, una historia de UI sin mockup donde el plan de diseño lo espera, una decisión de arquitectura implícita en los criterios, más de una migración o una ruta nueva de autorización: no se reclama sin un humano presente. Se anota y se toma la siguiente.
Escribe su nombre en la fila, guarda y vuelve a leer el archivo. Si ahora hay otro nombre, ganó un par: retrocede y toma el siguiente candidato. Nunca se pelea una fila ni se edita la de otra corrida.
Cada despacho lleva el briefing de siete componentes. El componente 7 (reglas) carga la compuerta de migraciones, la ruta del worktree, la prohibición de rebasear ramas ya pusheadas y el procedimiento de parada por contexto: una regla que vive solo en esta skill nunca llega al ejecutor.
| Modo | Despacho | Lo que agrega esta skill |
|---|---|---|
| story | /sprint-development, entrada de historia nueva | clave del ticket, tabla de la fase 1, el claim, la ruta del worktree, la compuerta de migraciones, el presupuesto de contexto |
| bug | /sprint-development, entrada de bug (causa raíz primero) | lo mismo, una vez por bug, en secuencia |
| discovery | /product-management | el hueco encontrado en la fase 2 y su evidencia |
Escribir el archivo de migración es trabajo técnico y siempre es autónomo. Aplicarlo a una base compartida es irreversible y le pega a cada agente concurrente: es otro acto, con otra compuerta, según autonomous_delivery.migrations.
| migrations: | Cambio aditivo | Cambio destructivo (drop, rename, reescritura) |
|---|---|---|
| confirm (por defecto) | Pausa y pide aprobación: destino, qué hace, que es aditivo. | Pausa y pide aprobación, con una segunda opción real: diferirlo. |
| autonomous | Sigue. | Igual para. autonomous nunca cubre esto. |
| unrestricted | Sigue. | Sigue. Opt-in y peligroso a propósito: para una base sin datos de producción que perder. Nunca es el defecto. |
Un caso que la compuerta no abre: con stack.database.migrations_tool en prisma o drizzle, la doctrina de cambios de base pide consultar al equipo antes de aplicar, y nadie está en la línea. La corrida escribe la migración generada, la pushea y la escala, diga lo que diga migrations:.
En la corrida de la que sale esta skill, cada generación de workers se retiró por contexto, varias a mitad de un ticket. Se diseña para eso.
handoff.md se completa en cada frontera de fase y después de cada tajada terminada, según context_budget.handoff_checkpoint. Una sesión que se quedó sin espacio no puede escribir por qué.
En cada frontera de fase. Al llegar a context_budget.stop_at_remaining_pct deja de tomar trabajo: ni tajada nueva, ni agente en segundo plano, ni despertador programado.
Primero el push. Después rescatar registros, el estado de reanudación en handoff.md (rama, SHA, PRs, el próximo comando concreto), la última entrada de progress.md, soltar el lock y reportar.
# la secuencia de parada limpia 1. PUSH de la rama <- siempre primero: trabajo sin pushear en un worktree descartable es la única pérdida irrecuperable de este sistema 2. rescatar registros de sesión 3. estado de reanudación en handoff.md, escrito para un extraño que retoma en frío 4. última entrada de progress.md 5. soltar el lock 6. reportar
Sigue agentic-dev-core/references/decision-protocol.md: buscar en el registro, seguir lo ya decidido, un panel de jueces puntuado si la pregunta es nueva de verdad, y escalar solo lo que corresponde. Todo queda escrito donde la fase 1 de la próxima corrida lo va a encontrar.
BUSCAR EN EL REGISTRO -> ya decidido? SEGUIRLO
|
| no decidido
v
producto / seguridad nueva / irreversible / reservado?
| no | sí
v v
PANEL DE JUECES PUNTUADO (3-5 lentes) ESCALAR (informado)
| |
+---------> ESCRIBIRLO <---------------+
Nada se evapora en silencio: cada discrepancia, cada decisión autónoma y cada chequeo que la corrida no pudo hacer aparece nombrado en el reporte.
| Artefacto | Alcance y vida | Para qué |
|---|---|---|
| run-report.md | una corrida; se pisa en cada corrida y se archiva | lo que hizo esta corrida, para un humano que se pone al día |
| handoff.md | una corrida, escrito de continuo; se archiva | lo que la próxima corrida no puede sacar de otro lado |
| escalation-log.md | todas las corridas y modos; solo se agrega, nunca se archiva | cada parada, cada fallo, cada discrepancia |
| progress.md | una corrida; solo se agrega, se archiva | estado mecánico para retomar, con lo que queda sin pushear |
Las reglas que tienen que atar al ejecutor viven en ## Compact Rules y llegan a cada briefing por .agents/skills/REGISTRY.md. Cada riesgo observado, con su disparador y su chequeo, está en references/hazard-catalogue.md.
Lo escribe el prompt de la rutina, no una persona. El modo va siempre explícito: story, bug o discovery, definidos en ## Mode routing de la skill.
La barra de la skill y el modo como primer argumento.
Sin barra: el prompt de la rutina nombra la skill y el modo.
Mismo patrón que OpenCode, CLI o Desktop.
Selecciona y despacha; cada etapa del trabajo la hace su dueña. Fuera de alcance quedan la verificación de QA, que arranca desde el estado listo para QA, y elegir qué construir, que es producto y escala.
Implementa, revisa y despliega cada ticket. Su cierre de Stage 4 es el que la fase 4 verifica.
Refinamiento, épicas y criterios: la única skill que llama el modo discovery.
Ramas, pull requests, merges, conflictos y la planificación de cadenas de PRs.
Cuando las aristas o el orden de .context/dev-roadmap.md están viejos o faltan.
Lanza, supervisa y cierra los workers despachados, y registra la corrida como rutina programada. Solo cuando pasa su compuerta; cada QUÉ sigue siendo de esta skill.