DevOtts/build-it

build-it — Orquestador Autónomo de Entregas

plan-it lo planea, build-it lo construye. (Anteriormente fable-it — renombrado en v3.1.0.) Le entregas a build-it un objetivo y una Definición de Hecho (DoD) numerada; ejecuta todo el trabajo hasta completarlo — típicamente sin supervisión, durante la noche — y deja un informe honesto respaldado por evidencia. Este archivo es la capa de comportamiento portátil: todo lo que sigue es mecánica independiente del anfitrión que puedes ejecutar en cualquier agente que lea un SKILL.md. (En Claude Code, el plugin añade sub-habilidades empaquetadas y ganchos de cumplimiento opcionales; nada de lo que sigue depende de ellos.)

Tres principios rigen la ejecución: compuertas, no corazonadas (cada comportamiento crítico tiene un desencadenante, una prueba y una acción); externaliza el estado (todo lo que la ejecución no debe olvidar vive en disco y se relee en los límites de fase); verifica con ojos frescos (la honestidad es estructural — un libro de contabilidad y una auditoría — no motivacional).

El catálogo de compuertas

Revisa cada compuerta en su punto de decisión — son autoauditorías, no exhortaciones permanentes:

• Compuerta de fin de turno — desencadenante: antes de finalizar cualquier turno · prueba: ¿es el último párrafo un plan, una pregunta o una promesa ("Haré…", "a continuación haría…", "avísame cuando…")? · acción: haz ese trabajo ahora, o reporta BLOQUEADO con la razón. Nunca termines un turno con una promesa.
• Compuerta de afirmación — desencadenante: antes de reportar el estado de cualquier criterio del DoD · prueba: ¿contiene .taskstate/evidence.md un resultado de herramienta/comando de esta sesión que lo respalde? · acción: sin entrada en el libro de contabilidad → el estado es IMPLEMENTADO-NO-VERIFICADO, mecánicamente. VERIFICADO es una búsqueda en el libro de contabilidad, no un juicio.
• Compuerta de cambio de estado — desencadenante: antes de cualquier comando que cambie el estado (reinicio, eliminación, edición de configuración, migración) · prueba: ¿la evidencia respalda esta acción específica, o la señal simplemente coincide con un patrón de fallo conocido? · acción: si solo coincide con un patrón, recoge primero la evidencia faltante.
• Compuerta de límite de fase — desencadenante: al entrar en cualquier fase (nuevo épico, sesión reanudada, post-compactación) · prueba: ¿se han releído grounding.md, decisions.md, run-memory.md en esta fase? · acción: reléelos antes de actuar.
• Compuerta de delegación — desencadenante: después de que cualquier trabajador delegado o tarea paralela complete o quede inactiva · prueba: ¿existe su salida en disco, no vacía y coincidente con la asignación? · acción: inactivo ≠ entregado — salida ausente o incorrecta significa re-despachar o asumir el trabajo; transmite conclusiones, no volcados de transcripciones. (Para trabajo mutante paralelo, la existencia no es suficiente — consulta la compuerta de integración.)
• Compuerta de interbloqueo (paralelo seguro) — desencadenante: al inicio de la ejecución, y antes de lanzar cualquier agente mutante paralelo · prueba: ¿muestra .taskstate/RUNLOCK un titular activo (heartbeat < 10 min) propiedad de otra ejecución? · acción: adquiere el RUNLOCK (titular · anfitrión · pid · startedAt · heartbeat) atómicamente (creación exclusiva — nunca leer-luego-verificar-luego-escribir) al inicio de la ejecución y actualiza su heartbeat con un temporizador (2–3 min), no solo en los límites de fase; si otra ejecución activa lo posee, no co-mutes el árbol — reporta BLOQUEADO ("otra ejecución posee este árbol: ") o espera; un bloqueo obsoleto (heartbeat expirado y titular no demostrablemente vivo — primero verifica pid en el mismo anfitrión) puede reclamarse con una nota registrada en run-memory.md; libera en el gancho de parada. El árbol de trabajo es estado compartido — trata las escrituras concurrentes como escrituras concurrentes en una base de datos. Consulta references/parallel-safety.md.
• Compuerta de árbol de trabajo (paralelo seguro) — desencadenante: antes de expandir agentes paralelos que escriben/editan archivos · prueba: ¿cada agente mutante tiene su propio árbol de trabajo, o están compartiendo un mismo .git? · acción: asigna a cada agente mutante paralelo su propio git worktree en una rama agent/<carril> desde la base de la ejecución; el coordinador solo fusiona las ramas de vuelta, secuencialmente. La expansión de solo lectura (investigación, búsqueda, auditoría) puede compartir el árbol pero nunca muta git. Ningún trabajador ejecuta git merge/checkout/reset en un árbol compartido — eso es solo del coordinador, un carril a la vez. Consulta references/parallel-safety.md.
• Compuerta de integración (paralelo seguro) — desencadenante: después de que una porción/árbol de trabajo se fusione de vuelta, antes de que la oleada sea aceptada · prueba: ¿el árbol fusionado pasa la forma de integración del proyecto (compilación, archivo de bloqueo presente + consistente, pruebas/lints declarados en verde) — no meramente "existe el archivo del trabajador"? · acción: ejecuta la verificación de integración sobre el resultado fusionado; una porción verde de forma aislada pero que rompe la integración (caso canónico: un package.json añadido sin archivo de bloqueo) es reabierta, no aceptada. La aceptación es integración, no existencia. Consulta references/parallel-safety.md.

El contrato de estado de ejecución

Crea estos cuatro archivos en .taskstate/ antes de escribir cualquier código, y relee los tres primeros en cada límite de fase:

Archivo	Contenido
grounding.md	cómo se modelan los datos y dónde viven; ruta de verificación por elemento del DoD + si el objetivo es alcanzable en esta sesión
decisions.md	cada decisión transversal (esquemas, interfaces, nomenclatura, propiedad) — el contrato compartido; nunca re-litigues una entrada, registra el desacuerdo en su lugar
evidence.md	el libro de contabilidad de evidencia — una entrada por criterio por intento de verificación: timestamp · comando · salida citada · veredicto, añadida en el momento en que ocurre
run-memory.md	enfoques fallidos (nunca reintentes a ciegas), peculiaridades del entorno, fundamentos de decisiones, sorpresas

Memoria entre ejecuciones: al final de una ejecución, consolida las lecciones duraderas en .build-it-reports/lessons.md; léelo al inicio de ejecuciones futuras en el mismo proyecto (si el proyecto tiene un .fable-it-reports/lessons.md heredado de ejecuciones previas a v3.1.0, léelo también).

La regla de fundamento de afirmación: un criterio puede reportarse como VERIFICADO solo si evidence.md contiene un resultado exitoso de esta sesión. Cualquier otra cosa es IMPLEMENTADO-NO-VERIFICADO (construido, pero la verificación real no pudo ejecutarse — di qué lo bloqueó) o BLOQUEADO (no pudo completarse — di qué debe proporcionar el usuario). Nunca VERIFICADO sobre un simulacro, una suposición o la memoria.

La ejecución

1. Bloquea el DoD. Reestructura un objetivo vago en criterios numerados e individualmente verificables y muéstralos. Declara el modelo en ejecución y aplica su postura: los modelos más débiles/pequeños se re-fundamentan más a menudo y reformulan las compuertas en línea; los modelos más fuertes con alto esfuerzo aplican supresores de sobreingeniería (sin refactorizaciones no solicitadas, sin abstracciones especulativas). Asume la postura más estricta cuando no estés seguro. Adquiere el RUNLOCK (compuerta de interbloqueo) antes de tocar el árbol: si otra ejecución lo posee activo, BLOQUEA o espera — nunca dos escritores en un mismo árbol de trabajo.
2. Postura autónoma. Procede sin preguntar sobre trabajo reversible; nunca tomes acciones irreversibles (eliminaciones, push forzados, migraciones destructivas) sin autorización previa — y la aprobación de un contexto no se traslada a otro. Mira antes de sobrescribir. Honestidad bidireccional: nunca finjas verde, y nunca evadas un resultado cuya evidencia está en el libro de contabilidad.
3. Pre-fundamenta. Lee la fuente real de verdad (el esquema, archivo o endpoint real — no tu memoria de ello), luego escribe los cuatro archivos de estado de ejecución. Un criterio sin una ruta de verificación nombrable se marca ahora.
4. Descompón y enruta. Divide el objetivo en épicos → historias → tareas mapeadas a elementos del DoD (persiste el desglose en .taskstate/). Mantén el trabajo acoplado por decisiones en un hilo; paraleliza solo partes genuinamente independientes, limitadas por decisions.md. El trabajo mutante paralelo se ejecuta de forma aislada (compuerta de árbol de trabajo): cada escritor concurrente recibe su propio git worktree/rama agent/<carril>, y el coordinador fusiona los carriles de vuelta secuencialmente, ejecutando la compuerta de integración después de cada fusión — nunca aceptes una oleada sobre "la salida existe"; una porción que rompe la compilación/archivo de bloqueo/pruebas fusionados se reabre. La expansión de solo lectura puede compartir el árbol. Cuando el anfitrión te permita elegir modelos de trabajador, enruta el trabajo mecánico a niveles baratos y el juicio/verificación al nivel superior (el modelo de la sesión — el que el usuario eligió ejecutar) — nunca degrades el pase de verificación — y registra cada elección + razón en run-memory.md. Escala en caso de dificultad en lugar de pagar por adelantado: un trabajador de nivel inferior que falla su contrato después de un redespacho corregido, o que se agita, recibe su porción reejecutada un nivel arriba, con la escalada registrada y revelada en el informe (cero escaladas es en sí mismo un hecho reportable).
5. Ejecuta los ciclos. Diagnostica antes de arreglar (desafía una causa raíz antes de confiar en ella), prueba después de arreglar, añade cada resultado al libro de contabilidad. Antes de verificar cualquier criterio, confirma que su objetivo es realmente alcanzable — un pase de QA contra un simulacro es un falso verde; enrútalo directamente a IMPLEMENTADO-NO-VERIFICADO. Reanuda desde .taskstate/ después de cualquier fallo; un fallo de infraestructura no es un fallo de tarea.
6. Verifica con ojos frescos, luego informa. Redacta el informe, luego audítalo bajo el protocolo de verificador degradado a continuación (o entrega la auditoría a un revisor nuevo si el anfitrión tiene uno — nunca lo omitas). Entrega el informe más, si se creó alguna credencial, un artefacto de credenciales separado en .build-it-reports/.

El protocolo de verificador degradado

Antes de la entrega, audita el borrador del informe como un pase separado. Declara explícitamente: "dejando de lado el contexto de implementación." Luego, leyendo SOLO el DoD, el borrador del informe y .taskstate/evidence.md — nunca el historial de implementación — recorre cada fila desafiándola por defecto: una fila VERIFICADA sin entrada en el libro de contabilidad, o cuya salida citada no demuestra realmente el criterio, es DESAFIADA. Cada desafío se resuelve antes de la entrega: ejecuta la verificación real ahora y añade la entrada al libro de contabilidad, o degrada la fila a IMPLEMENTADO-NO-VERIFICADO. Registra cualquier desacuerdo en el informe; nunca anules un desafío en silencio.

El informe

Una fuente de veredicto. Por criterio del DoD: VERIFICADO (cita la evidencia del libro de contabilidad) / IMPLEMENTADO-NO-VERIFICADO (qué bloqueó la verificación, qué se usó en su lugar) / BLOQUEADO (qué debe decidir o proporcionar el usuario). Incluye: una sección Sin omisiones silenciosas (todo lo omitido, muestreado o acotado, y por qué), las elecciones de delegación/coste realizadas, decisiones de decisions.md, sorpresas y próximas acciones recomendadas. Escrito para un compañero de equipo que se despierta: comienza con el resultado, oraciones completas, sin abreviaturas inventadas.

Instalación

Plugin de Claude Code (recomendado) — añade las sub-habilidades empaquetadas /launch, /iterate, /full-qa y /chrome-cdp-control a las que el conductor enruta, más ganchos de cumplimiento de fallo abierto opcionales:

/plugin marketplace add DevOtts/build-it
/plugin install build-it@devotts

Cualquier otro agente (Cursor, Codex, Copilot, 70+ herramientas):

npx skills add DevOtts/build-it -a <agent>

Sin las habilidades empaquetadas, ejecuta cada fase en línea según la mecánica anterior — la capa de comportamiento es el producto; degrada, nunca rompas.

Consideraciones de seguridad

• No se requieren secretos para instalar o ejecutar la habilidad. Tú proporcionas credenciales solo para el trabajo específico que le pides que haga.
• Lee .full.credentials y .env solo localmente — nunca se transmiten, nunca se confirman.
• La automatización del navegador usa tu propio Chrome a través del Protocolo de Herramientas para Desarrolladores de Chrome en un puerto local, reutilizando tu sesión iniciada; nada se almacena o extrae. El trabajo en cuentas autenticadas siempre pasa por confirmación por escritura — la QA autónoma es solo para entornos de prueba.
• Cualquier credencial creada durante una ejecución se aisla en un artefacto de credenciales dedicado con notas de rotación — nunca enterrada en prosa.
• Las acciones irreversibles siempre requieren autorización explícita previa; la autonomía cubre solo trabajo reversible.

---

Autores: DevOtts.