En 2026, un equipo empresarial creó un agente que leía tickets de gestión de incidentes, generaba autopsias a partir de ellos y creaba elementos de reparación automáticamente. Un segundo agente del mismo equipo observó nuevos elementos de trabajo y abrió borradores de relaciones públicas para cada uno para ayudar a los desarrolladores a comenzar. Un desarrollador revisó uno de esos RP, lo encontró razonable, lo aprobó y lo fusionó con la rama principal.

**El problema fue que el cambio fue totalmente inventado.**

El agente había inventado una solución aparentemente plausible para un problema que no existía en la forma que describía. El cambio retrocedió a un escenario de producción real. Un cliente real se dio cuenta. Hubo un apagón.

Por eso existe la Constitución del EDD.

La constitución es un archivo único que gobierna cada cambio no trivial en el código base. Define cómo se ve un cambio terminado, qué evidencia debe llevar, qué debe cubrir una auditoría de alcance y cómo pueden evolucionar las reglas mismas. Cada agente y cada humano que toca el repositorio lo carga en cada sesión. La barra sólo sube.

Esta publicación recorre la constitución paso a paso: el incidente que la motivó, la pregunta de diseño que responde, cómo está estructurada, cómo se redactó (y en qué nos equivocamos al principio), cómo funcionan las enmiendas y cómo se despliega el kit completo en un nuevo repositorio.

Paso 1 - ¿Qué es?

El incidente es la ilustración más clara posible del modo de falla que el EDD está diseñado para prevenir. El agente no tuvo alucinaciones al azar. Produjo un PR coherente, legible y con formato profesional. El desarrollador que lo revisó hizo lo que hacen los desarrolladores: leyeron la intención, la encontraron plausible y la aprobaron. La brecha no fue la atención. La brecha fue la ausencia de pruebas. Nada en el proceso de revisión requería que el agente demostrara que el problema que pretendía solucionar realmente existía, que la solución abordaba el comportamiento real o que el cambio no hacía retroceder nada.

El EDD responde a esa brecha con un único requisito estricto: si el agente no puede probarlo, la tarea no está realizada. La prueba no es un resumen. La prueba no es una afirmación de confianza. La prueba es un artefacto que se puede verificar de forma independiente: una prueba fallida, un resultado del escáner, una captura de pantalla del antes/después, una diferencia del plan. El PR lleva el artefacto o el PR está incompleto.

La constitución se encuentra en `docs/methodology/CONSTITUTION.md`. Cada agente de IA configurado en el proyecto lo carga en cada sesión a través de su propio archivo de carga. El cuerpo es neutral respecto al agente: no hay nombres de herramientas ni sintaxis específica de la plataforma. Define nueve principios fundamentales, restricciones estrictas con ID de slug estables, el ciclo de implementación de 10 pasos, dimensiones de auditoría, criterios de aceptación de evidencia por tipo de cambio, excepciones de trivialidad para trabajos de bajo riesgo y la cláusula de enmienda.

Cada restricción estricta tiene un slug como `[HC-EVIDENCE-BEFORE]` y declara tres cosas: la barra (lo que debe ser cierto), la verificación (cómo se verifica el cumplimiento) y la fuente del patrón (qué archivo de instrucciones elabora la guía de implementación).

El ciclo de 10 pasos es el corazón operativo: definir lo hecho, escribir una prueba que demuestre la brecha, observar cómo falla, capturar evidencia previa, implementar, observar cómo pasa la prueba, capturar evidencia posterior, verificar documentos, auditar en todas las dimensiones declaradas y luego revisión humana. Los pasos 1 a 4 ocurren antes de cualquier edición de implementación. El orden es constitucional porque este incidente muestra exactamente lo que sucede cuando no lo es.

Como salvaguarda adicional, EDD toma prestado un principio básico de TDD: se debe demostrar que el escenario falla antes de comenzar el trabajo. Una prueba que pasa al final de un cambio no es evidencia suficiente por sí sola: si la prueba también pasó antes del cambio, es posible que el agente haya arreglado algo que nunca se rompió. Este es un modo de falla específico en los flujos de trabajo asistidos por IA: un agente genera una solución que suena plausible, la verificación se cumple y el cambio se envía como si resolviera un problema real. Exigir un estado fallido documentado antes de que comience la implementación cierra esa brecha. El paso previo a la evidencia no es sólo una base para la comparación: es una prueba de que el problema que se estaba resolviendo era real.

De todas las restricciones estrictas que se han incluido en la constitución, dos han detectado más defectos que todas las demás juntas, y son posiblemente la actualización más importante que EDD realiza en cualquier flujo de trabajo asistido por IA: `[HC-EVIDENCE]` y `[HC-EVIDENCE-INTEGRITY]`. Ambos se declaran en `.github/copilot-instructions.md`, el archivo cargado con impaciencia que se encuentra en el contexto del agente en cada sesión.

`[HC-EVIDENCE]` requiere que cada PR lleve artefactos reales del antes y el después, no descripciones de lo que mostrarían los artefactos, ni resúmenes de lo que el agente cree que sucedió, sino el resultado bruto. `[HC-EVIDENCE-INTEGRITY]` va más allá: requiere que la evidencia en el PR pueda rastrearse hasta el trabajo que realmente se realizó. Valida que el PR contenga lo que dice contener.

Juntas, estas dos limitaciones han detectado cientos de errores generados por la IA antes de que llegaran a ser revisados. El modo de fracaso del que se protegen no es la alucinación en el sentido obvio. Es un comportamiento más sutil: el agente marca una tarea como completada, escribe una descripción de relaciones públicas segura e incluye lo que se lee como evidencia, pero la evidencia fue compuesta, no capturada. El agente describió cómo debería verse el resultado en lugar de ejecutar el comando e incluir el resultado real.

`[HC-EVIDENCE-INTEGRITY]` es específicamente eficaz para detectar lo que podría llamarse el patrón "No pude hacer eso". Un agente que se enfrenta a una tarea difícil o desconocida a veces afirmará que la tarea es imposible o está fuera de alcance en lugar de intentarla. La afirmación a menudo se formula como una limitación: una herramienta que no existe, una restricción que impide el enfoque, un entorno que no respalda la operación. `[HC-EVIDENCE-INTEGRITY]` emerge esto: si el agente afirma que una tarea no se pudo realizar, el RP debe mostrar evidencia de que la tarea se intentó genuinamente y que el obstáculo es real. "No pude ejecutar el conjunto de pruebas" requiere una salida de terminal que muestre la falla, no una declaración de que ocurrió la falla. Sin ese requisito, el hecho de que el agente evite el trabajo difícil es invisible en el momento de la revisión y la tarea se envía incompleta como si estuviera terminada.

Paso 2 - Cómo llegamos aquí

La constitución no es una acumulación de lecciones aprendidas. Es la respuesta a una pregunta de diseño formulada al principio: ¿cómo se puede obligar a un agente de IA a demostrar su trabajo cada vez, de una manera que no se pueda evitar y que no dependa de que un ser humano recuerde preguntar?

Responder a esa pregunta obligó a una descomposición. La prueba requiere saber cómo se ve lo hecho antes de que comience la implementación, lo que produjo el paso de documentación. La prueba requiere una prueba que falla antes del cambio y pasa después, lo que produjo la disciplina de prueba reprobada/aprobada. La prueba requiere un estado previo que fue capturado antes de que la implementación tocara algo, lo que produjo el requisito de la evidencia previa. La prueba requiere una auditoría independiente que detecte lo que la evidencia por cambio no puede detectar: ​​eso produjo las dimensiones de la auditoría. Y la prueba tiene que sobrevivir al proceso de revisión sin suavizarse, lo que produjo la dura restricción de que el revisor humano es la puerta final y la única que no puede automatizarse.

El resultado es el bucle de 10 pasos. Cada paso existe porque eliminarlo crea un agujero a través del cual puede pasar el trabajo no probado. El bucle no es una lista de verificación. Es una cadena causal.

A partir de ahí la pregunta pasó a ser: ¿qué categorías de fallas puede producir un agente que el bucle no detecta por defecto? Eso produjo las duras limitaciones. El silencio de la pelusa de seguridad mientras se degradaban las reglas produjo "[HC-SECURITY-LINT]". Un error de codificación de caracteres en un artefacto implementado produjo "[HC-ASCII-PUNCT]". Cada HC cierra una clase de falla específica con una verificación automatizada específica. Se rechazaron las reglas que no podían nombrar una verificación: si una verificación no puede automatizarse, la regla es aspiracional, no constitucional.

La pregunta del diseño final fue: ¿quién gobierna la constitución misma? La respuesta es el trinquete. La constitución sólo puede volverse más estricta. Las enmiendas deben llevar pruebas de que el comportamiento de los agentes mejora o se mantiene. El suelo nunca baja. Esto significa que se puede confiar en la constitución a lo largo del tiempo de una manera que no se puede confiar en una guía de estilo de vida: cada versión es estrictamente más sólida que la anterior.

Paso 3: cómo está estructurado

La constitución sigue una arquitectura de tres niveles.

**Capa 1: El cuerpo canónico.** Un archivo, `docs/methodology/CONSTITUTION.md`. Ésta es la fuente de la verdad. Es neutral respecto al agente: no hace suposiciones sobre qué herramienta de IA se está utilizando. Define principios, restricciones estrictas, el bucle, dimensiones de la auditoría, criterios de aceptación de evidencia, excepciones de trivialidad y la cláusula de superación personal. Cuando el cuerpo supera aproximadamente las 250 líneas, las reglas que se aplican a un patrón de ruta específico se factorizan en archivos con alcance de ruta, dejando un puntero de una línea en el cuerpo.

**Capa 2: Cargadores de agentes.** Cada agente configurado obtiene exactamente un archivo de cargador en la ubicación que el agente carga con entusiasmo. Para GitHub Copilot, eso es `.github/copilot-instructions.md`. Para Claude, eso es `CLAUDE.md`. El cargador importa o integra el cuerpo constitucional según lo que admita actualmente la plataforma. El cargador está fabricado mecánicamente a partir del cuerpo canónico; no está editado a mano. Si un proyecto utiliza tres herramientas de inteligencia artificial, hay tres archivos de carga y todos presentan el mismo contenido constitucional.

**Capa 3: reglas con alcance de ruta.** Algunas reglas se aplican solo a tipos de archivos específicos. Las reglas de accesibilidad y localización se aplican a archivos JSX y CSS, no a plantillas de infraestructura. Esas reglas se encuentran en archivos de instrucciones con un globo frontal:

El agente carga estos archivos solo cuando toca una ruta coincidente. Esto mantiene ajustado el presupuesto del contexto de carga ansiosa (las reglas principales siempre están presentes, las reglas especializadas se cargan a pedido) y evita que aparezcan instrucciones de accesibilidad en la edición de una plantilla de Bicep.

Los archivos de soporte completan la estructura: `/constitute` cuerpos de comando en `.github/prompts/`, carpetas por función en `docs/methodology/features/`, escenarios de evaluación en `docs/methodology/eval/scenarios/` y `verify-sequence.yaml` en la raíz del repositorio que define el orden de las puertas de CI.

Paso 4: cómo lo escribimos

**El contexto lo es todo. Lo que no está en contexto está muerto para el agente.**

Ésta es la idea más importante a la hora de redactar una constitución para un desarrollo regido por la IA. Una regla que existe en un archivo que el agente nunca carga no existe. Una restricción estricta oculta en un documento que solo se carga cuando se toca una ruta de archivo específica no es una restricción estricta para ninguna otra ruta. La constitución siempre debe estar en contexto, y todo lo que siempre debe aplicarse debe vivir allí.

Esto impulsa tres decisiones de redacción:

**La optimización del token no es negociable.** El cuerpo canónico apunta a menos de 300 líneas y 8k tokens. Cada enmienda debe mantener o mejorar la eficiencia simbólica: las reglas detalladas que logran lo que las concisas pueden ser rechazadas sólo por ese motivo. Esta no es una preferencia de estilo. Es una restricción de carga. Si la constitución excede el presupuesto, los agentes en ventanas de contexto más pequeñas comienzan a truncarla, y las reglas truncadas no son reglas.

**Carga condicional a través de frontmatter.** Las reglas que se aplican solo a tipos de archivos específicos se excluyen del cuerpo canónico y se incluyen en archivos de instrucciones con alcance de ruta con una declaración global de frontmatter. La guía de accesibilidad y localización se carga solo cuando el agente toca JSX o CSS. La guía de infraestructura se carga solo cuando el agente toca Bicep. El cuerpo canónico mantiene un puntero de una línea. El agente carga el archivo con alcance de ruta solo cuando es relevante. Esto no es solo eficiencia: evita que la guía de accesibilidad surja como una distracción en una edición de infraestructura, lo que entrena al agente para ignorarla.

Este proyecto no utiliza archivos de reglas separados por temas iniciales porque la constitución es lo suficientemente pequeña como para cargarla completamente en contexto: un único desarrollador, un alcance enfocado, un conjunto de reglas reducido. Para equipos más grandes el cálculo cambia. Un proyecto a escala empresarial que actualmente ejecuta EDD tiene 75 restricciones estrictas en materia de seguridad, cumplimiento, accesibilidad y requisitos específicos de la plataforma. Incluir los 75 en un solo archivo de carga entusiasta llevaría a la constitución mucho más allá del presupuesto contextual para la mayoría de los agentes. La división de Frontmatter mantiene el cuerpo canónico por debajo de 250 líneas (un puntero de resumen por dominio) y carga de forma diferida los detalles completos de la regla solo cuando el agente toca rutas coincidentes. La constitución se mantiene rápida y ágil. Las reglas permanecen completas. El costo del token permanece limitado.

**Enmiendas como unidades de cambio.** Una enmienda constitucional no es un cambio de palabra en un archivo de rebajas. Es un paquete de tres artefactos: la regla delta exacta, el mecanismo de verificación que detectará violaciones futuras y un escenario de evaluación del comportamiento que demuestra que el comportamiento del agente mejora. Los tres se envían juntos en el mismo PR. La enmienda es atómica. Se rechazan las enmiendas parciales que prometen añadir la verificación más tarde; más tarde no llega y la regla no verificable es la decoración.

**Escribe las evaluaciones y rúbricas antes de que creas que las necesitas.** La evaluación es el trinquete. Sin él, las enmiendas se aceptan de buena fe y la Constitución se desvía. La rúbrica califica el comportamiento de los agentes en escenarios realistas. Cada nueva regla produce al menos un escenario. La rúbrica produce una puntuación numérica. La enmienda se aprueba sólo si la puntuación del árbol de trabajo cumple o supera la línea de base.

**Documente lo que puede y lo que no puede cubrir. No te mientas sobre la cobertura.**

Al principio, la estricta restricción de accesibilidad declaró que las nuevas superficies de interfaz de usuario interactivas requerían cobertura e2e a11y utilizando axe-core. Esto se sintió completo. En la práctica fue ingenuo. axe-core maneja un subconjunto significativo de WCAG: detecta etiquetas faltantes, estructura de puntos de referencia, orden de enfoque y contraste en los casos en que el DOM está completamente renderizado y los colores se resuelven. No detecta la lógica de anuncios del lector de pantalla, los patrones de carga cognitiva, los complejos contratos de teclado de widgets ni los problemas de contraste que involucran gradientes y nodos de imágenes SVG donde el color calculado no se puede resolver.

Tener `[HC-A11Y-GATE]` con axe-core en la verificación no significa que todos los errores sean cero. Significa que el conjunto de reglas específico de axe-core se ejecuta en contra del DOM renderizado. La diferencia es enormemente importante en las reclamaciones de cobertura de relaciones públicas.

La solución fue la descomposición. En lugar de "limpieza de núcleo de hacha", la verificación se reescribió para enumerar qué criterios de éxito de las WCAG cubre de manera determinista el conjunto de reglas de axe-core (1.1.1 para contenido no textual, 1.3.1 para información y relaciones, 1.4.3 para contraste cuando se pueda resolver, 4.1.2 para nombre/rol/valor) y cuáles tienen cero cobertura automatizada (1.3.3 características sensoriales, 2.4.6 encabezados y etiquetas semántica, todos de 3.x Criterios comprensibles). La sección de brechas conocidas de la dimensión de auditoría ahora establece explícitamente: axe-core maneja estos criterios; para ellos se requiere escaneo manual. Los revisores de relaciones públicas ven la cobertura real, no un resumen de confianza falsa.

El principio más amplio: para cada verificación, documente lo que detecta y lo que no. Los "pases de pelusa de seguridad" no significan que el código base sea seguro. "Axe-Core Clean" no significa que cumpla con WCAG 2.2 AA. Nombra la brecha. Regístrelo en la dimensión de auditoría. Requiere escaneo manual de la superficie del espacio. No permita que la verificación automatizada sustituya el juicio humano que no puede reemplazar.

Paso 5: cómo redactamos las enmiendas

Las enmiendas casi nunca comienzan como propuestas de enmienda. Comienzan como insectos.

Aparece un error. Se aplica la solución. Antes del envío, `/reflect` plantea una pregunta: ¿se trata de un caso excepcional o falta algo en la constitución que habría detectado este tipo de fracaso? Si la respuesta es única, la solución se envía y ese es el final. Si la respuesta es que falta algo, es cuando se invoca `/constitute`.

**La ruta /reflect -> brecha -> enmienda.** `/reflect` examina la solución y la clasifica: brecha constitucional (ninguna regla cubría esta clase de falla) o brecha de verificación (existía una regla pero ninguna verificación automática la aplicaba). Ambas rutas conducen a `/constituir`. Una brecha constitucional produce un nuevo HC. Una brecha de verificación produce una verificación más estricta en un HC existente (generalmente una nueva subsección de dimensión de auditoría, una nueva regla de análisis o un nuevo escenario de evaluación).

**Los tres artefactos requeridos.** `/constitute` se niega a proceder sin los tres en el mismo PR:

• **Regla delta.** El cambio de texto exacto, clasificado: nueva regla, redacción modificada, desplazamiento (reemplazar y eliminar la antigua), sustitución (elevar el listón con la antigua como piso) o reubicación. Los duplicados se rechazan a la vista.
• **Mecanismo de verificación.** La puerta específica que detectará una infracción futura: un nombre de prueba, ID de regla de pelusa, subsección de dimensión de auditoría, verificación de código de salida del escáner o escenario de evaluación de comportamiento. Debe existir en el momento de la confirmación. Las reglas sin violaciones detectables son decorativas.
• **Escenario de evaluación.** Almacenado en `docs/methodology/eval/scenarios/<id>.md`. Describe una situación realista en la que la antigua regla produce un comportamiento incorrecto del agente y la nueva regla produce la respuesta correcta puntuable.

**El trinquete.** Una vez aprobados los tres artefactos, la enmienda se aplica a una rama. La evaluación va en contra de las reglas de la rama principal y del árbol de trabajo. La rúbrica califica a ambos. Pass requiere árbol de trabajo >= main en cada escenario. La regresión bloquea la enmienda hasta que se corrija la redacción. El trinquete no es opcional para enmiendas obvias: aún pueden producir regresiones sutiles, y la evaluación es el único mecanismo que las detecta antes de que aterricen.

**El barrido retroactivo.** Una enmienda fija la regla para el nuevo código inmediatamente: el alcance diferencial de `/audit` significa que el nuevo trabajo cumple con el nuevo estándar desde el momento en que llega la enmienda. El código preexistente que viola la nueva regla es manejado por un PR de barrido separado en cola a través de `/rollout`. El sitio de reparación no necesita reparar todas las instancias preexistentes en línea. Eso haría que las enmiendas fueran prohibitivamente costosas. En cambio: el código nuevo cumple con la nueva barra de inmediato, el código antiguo está en la cola de implementación y el PR de barrido lleva su propia evidencia de que las instancias preexistentes se resuelven.

Los cuatro desencadenantes válidos para "/constitute" son: un error, un incidente, una autopsia y un nuevo estándar contractual. Las propuestas con la forma "probablemente deberíamos..." sin ninguno de los cuatro factores desencadenantes se rechazan y se envían a `/reflect`.

Paso 6 - Cómo lo desplegamos

El kit de metodología portátil (`EDD - Portable Methodology Kit.md`) es un documento independiente que se entrega a cualquier agente de IA con las instrucciones para ejecutar `/begin`. El agente inspecciona el repositorio, ejecuta una pasada de descubrimiento, confirma los valores detectados con usted en una sola tabla, pregunta solo qué descubrimiento no puede responder y emite el andamiaje mínimo viable para su proyecto. Una sesión para poner en marcha toda la infraestructura del EDD.

La forma en que lo despliegue depende completamente de si está comenzando de nuevo o si lo está incorporando a una base de código existente. Los dos caminos son lo suficientemente diferentes como para tratarlos por separado.

**Greenfield.** En un proyecto nuevo, incluya todas las reglas que se le ocurran en la constitución desde el primer día. No tiene ningún código preexistente que auditar, ni prácticas de equipo que proteger, ni RP existentes que proteger. El costo del rigor desde el primer día es casi nulo. Agregue todas las restricciones estrictas, todas las dimensiones de auditoría, todas las reglas con alcance de ruta. Luego ejecuta el bucle. Lo que descubrirá rápidamente es dónde la constitución crea fricción: tiempos de construcción que se disparan porque cada cambio desencadena una auditoría completa, conjuntos de pruebas que son lentos porque la barra de cobertura está demasiado alta para la complejidad actual, presupuestos simbólicos que son ajustados porque el cuerpo canónico es demasiado detallado. El rigor desde el primer día saca a la luz estos problemas en el desarrollo, no en la producción. Luego se optimiza: se ajustan las puertas de construcción, se ajustan las reglas de cobertura, se recorta el cuerpo constitucional al mínimo. Estabilizas todo a la vez, sin que ningún cliente se vea afectado ni ningún equipo se vea afectado. El costo a corto plazo es un primer sprint ligeramente más lento. La ganancia a largo plazo es una constitución que ha sido puesta a prueba desde el primer compromiso.

**Brownfield.** Una base de código existente tiene un equipo existente, prácticas existentes y RP existentes que no siguieron EDD. El despliegue aquí es incremental y debe ser aditivo, no disruptivo. El objetivo para el primer mes no es actualizar cada decisión pasada, sino comenzar a generar la garantía que hace que EDD sea confiable: una dimensión de auditoría que detecte algo real, una restricción estricta que automatice una revisión que el equipo ya estaba haciendo manualmente, un ciclo de enmienda de principio a fin. Utilizar como materia prima las señales de calidad existentes en el equipo. Si el equipo ya tiene una regla de seguridad, agregue `[HC-SECURITY-LINT]` y apúntelo a la puerta existente; nada cambia para los desarrolladores, pero ahora el registro constitucional refleja lo que la puerta realmente impone.

La regla fundamental en las zonas industriales abandonadas es: ganar aliados antes de ganar discusiones. No impulse una constitución completa que abarque todas las áreas del código base durante la primera semana. Comience con la dimensión que más le importa al equipo: generalmente la seguridad o la confiabilidad. Demuestre que el proceso de enmienda cierra una brecha real que han visto antes. Deje que el trinquete se componga desde allí. Un equipo que haya visto al EDD detectar un error real que se había escapado de su proceso existente dejará espacio para la siguiente regla. Un equipo que encuentre el EDD como un documento que les dice que han estado haciendo todo mal lo evitará.

**Lo que desbloquea.** La razón para realizar el despliegue, ya sea en una zona nueva o abandonada, no es el documento constitucional. Es lo que permite la constitución una vez que la maquinaria de verificación está en funcionamiento.

La calidad del código de producción y la velocidad de entrega se combinan de una manera que es genuinamente contradictoria si no lo ha visto. Los ingenieros detienen el cambio de contexto para depurar las regresiones que el bucle habría captado. Los ciclos de revisión se acortan porque los RP aportan evidencia en lugar de explicaciones. La auditoría se ejecuta automáticamente y señala los problemas que habrían detectado el revisor más experimentado, liberándolo para centrarse en las decisiones arquitectónicas que realmente requieren su criterio.

La evidencia más clara de esto: un nuevo ingeniero que se une al equipo, con acceso completo a la constitución, las especificaciones de funciones y el bucle, puede hacer una contribución de funciones de calidad de producción registrada en principal dentro de las 48 horas posteriores al primer día. Not a toy change. No es una actualización de la documentación. Una característica real, con evidencia, pasando la auditoría completa. No es una casualidad y no es un ingeniero particularmente inusual. Las barreras de seguridad hacen posible que cualquier desarrollador capacitado opere con el estándar de calidad del equipo desde el primer día, porque el estándar de calidad está escrito, es verificable y se aplica automáticamente en lugar de ser un conocimiento institucional en la cabeza de quien haya estado en el lugar por más tiempo.

Esa es la forma que alcanza: un equipo donde la IA hace el trabajo de verificación, las barreras de seguridad detectan las clases de fallas que de otro modo pasarían desapercibidas en la revisión del código y los ingenieros dedican su tiempo a pensar en los problemas que realmente requieren criterio de ingeniería.

Esto se ha verificado en diferentes escalas: primero proyectos individuales, luego equipos de tamaño mediano y luego organizaciones de escala empresarial. La mecánica se mantiene en los tres. El costo de implementación es diferente (un desarrollador en solitario puede omitir los registros de requisitos y la revisión contradictoria entre proveedores; un equipo empresarial los necesita). La cadencia de enmienda es diferente (un proyecto en solitario puede pasar semanas entre invocaciones "/constitute"; un equipo empresarial con múltiples agentes contribuyentes los ejecuta semanalmente). Pero el bucle central, el trinquete y el requisito de evidencia se comportan de la misma manera independientemente del tamaño del equipo. El piso de calidad solo aumenta, y la maquinaria de verificación lo mantiene allí sin depender de quién sea el revisor más experimentado en la sala esa semana.

Ganchos de IA

La constitución gobierna el comportamiento del agente a través de un contexto cargado. Los ganchos lo aplican en el momento de la acción, antes de que el trabajo esté terminado y un PR ya esté abierto. Sin ganchos, se detecta una infracción en la revisión: el agente ya ha escrito el código, el PR existe y solucionarlo significa volver a hacer el trabajo. Con los ganchos, la interceptación ocurre antes de presionar cualquier tecla.

**Tanto Claude Code como GitHub Copilot ejecutan un gancho al enviar el mensaje.** Cuando llega una nueva tarea, el gancho se activa antes de que el agente haga algo. Su trabajo: verificar si la tarea no es trivial, luego volver a cablear la lista de tareas en el bucle `/wow`, la secuencia EDD de 10 pasos que el agente debe seguir antes de enviar cualquier cosa.

Un agente que llega al paso 5 sin completar los pasos 1 a 4 ha violado el bucle. El gancho establece la secuencia al inicio de la sesión, no después del hecho.

**Claude Code** además activa un enlace de llamada previa a la herramienta antes de cualquier escritura de archivo, comando de terminal u operación de git. No se puede intentar una confirmación si no se han cumplido los pasos del bucle.

**GitHub Copilot** activa además un gancho de creación de relaciones públicas. Antes de finalizar la descripción del PR, el gancho ejecuta `/audit` en modo de autoevaluación, detectando violaciones de dimensiones, evidencia faltante y planes de prueba vacíos antes de que un revisor humano vea el borrador. Lo que llega al revisor ya está preseleccionado.

**Codex y otros agentes** no tienen una superficie de gancho nativa al momento de escribir este artículo. La alternativa es un robot observador de CI que comenta las relaciones públicas inmediatamente después de su creación y señala las infracciones. Es un tope de respaldo, no una puerta de primera superficie: el trabajo ya está hecho cuando se dispara, por lo que no evita el retrabajo que eliminan los ganchos.

En un proyecto con ganchos activos, las infracciones se corrigen en línea durante la sesión. El agente detecta la brecha, produce la evidencia y la incluye desde el principio. El tiempo de revisión disminuye. El retrabajo desaparece. La constitución pasa de un documento que el agente lee a una restricción en la que el agente opera en tiempo real.

Apéndice - La Constitución completa

Lo que sigue es el `CONSTITUTION.md` real de este proyecto: un proyecto de desarrollo asistido por IA totalmente autónomo y de un solo desarrollador. Gobierna todos los cambios no triviales realizados en este código base. Esto no es una plantilla ni una ilustración. Este es el documento en vivo cargado por cada agente en cada sesión.