chimera-write-the-check-before-the-code
Un criterio escrito después de la implementación describe la implementación. Escribe primero la comprobación que falla, obsérvala fallar, y luego construye.
Conferida por quien revisó y leyó la tarjeta, no reclamada por el propio archivo. Una tarjeta que el agente destila durante una ejecución que consumió contenido no confiable nace contaminada y queda retenida para revisión antes de ser recuperada.
Cuándo viene a la mente
- a punto de implementar una funcionalidad
- definiendo qué significa terminado
- escribiendo la prueba después del código
- la tarea no tiene criterios de aceptación
Evita y Comprueba es donde suele estar el valor. Haz es la sección que todo el mundo escribe.
El cuerpo de la tarjeta de arriba es una traducción. El original en inglés es lo que importa la CLI, lo que lee el agente en ejecución y lo que atestigua el hash de abajo.
Disparador
Estás a punto de implementar algo cuyo «hecho» todavía no es observable — una funcionalidad, la corrección de un bug, una refactorización que afirma preservar el comportamiento. Muerde con más fuerza cuando el autor y el único revisor son el mismo proceso: un agente trabajando solo, o un commit en solitario que nadie más leerá.
No aplica a un spike. La exploración cuyo propósito es averiguar qué es siquiera posible todavía no tiene criterio de aceptación, e inventar uno por adelantado solo te ancla a la primera idea. Escribe la comprobación cuando el spike termina y empieza el trabajo de verdad.
Esta tarjeta trata de la comprobación que aún no existe. Su hermana,
chimera-prove-the-test-discriminates, trata de una comprobación que ya existe y puede estar vacía —
a esa recurres después de un arreglo, para mostrar que la prueba falla sin él. El mismo instinto,
extremos opuestos del trabajo.
Haz
- Antes de tocar la implementación, escribe el criterio como algo que puede fallar: una prueba, una aserción, un comando cuyo código de salida cambie, una consulta con una fila esperada. La prosa no es una comprobación — «el endpoint debería ser más rápido» no lo es; «p95 por debajo de 200 ms sobre el conjunto de fixtures, medido con el comando de bench existente» sí.
- Di de dónde viene la observación. De la máquina, no de tu lectura del diff.
- Ejecuta la comprobación ahora, contra el código sin modificar. Debe fallar. Si pasa, o bien el comportamiento ya existe — en cuyo caso para, no hay nada que construir — o bien la comprobación no prueba lo que crees.
- Lee el mensaje de fallo. Debe fallar por la razón buscada, no por un error de import, un fixture ausente, o una errata en el nombre de la prueba. Un rojo que viene de la causa equivocada es un verde disfrazado.
- Publica la comprobación antes que la implementación, en su propio commit. Una vez que la implementación existe, la comprobación se vuelve editable para ajustarse a ella, y se editará.
- Implementa. Hecho es cuando la comprobación pasa — no cuando el código parece terminado.
Evita
Escribir la aserción después, a partir de la salida:
normalize(" Foo ") # -> "foo"
# test transcribed from that observation
assert normalize(" Foo ") == "foo"
Esa aserción no puede fallar contra el código del que fue copiada. Registra comportamiento en lugar
de requisito, así que se mantiene en verde a través de cada bug sobre el que la implementación sea
internamente consistente. Si el requisito era normalización NFKC y entregaste strip().lower(),
esta prueba está de acuerdo contigo para siempre.
Evita también el criterio que es una reformulación del cambio — «hecho cuando la función esté añadida», «hecho cuando la migración corra». Ambos se satisfacen con un cuerpo vacío.
Comprueba
Dos preguntas binarias, ambas respondibles desde el repositorio:
- ¿Viste la comprobación fallar antes de que la implementación existiera? Si no hay un momento en que estuvo en rojo, no tienes evidencia de que pueda ponerse en rojo.
- ¿Seguiría siendo correcta la comprobación si la funcionalidad se hubiera construido de una manera completamente distinta? Una comprobación que nombra internos — una llamada privada, una línea de log, una cadena SQL exacta — está clavada a tu solución en lugar de al requisito, y bloqueará la próxima refactorización sin detectar nada.
Concretamente: git log muestra la comprobación llegando antes o a la vez que la implementación, y
revertir solo el commit de la implementación pone la suite en rojo.
Riesgo
Un requisito que todavía no entiendes no puede fijarse con una comprobación escrita primero. Escribirás una aserción precisa sobre lo equivocado y luego implementarás hacia ella — peor que no tener comprobación, porque blanquea un malentendido convirtiéndolo en una suite verde en la que un revisor confiará. Cuando el criterio es genuinamente desconocido, eso es una señal para ir a preguntar, una pregunta a la vez, no para adivinar en forma de prueba.
También hay un costo llano. Para la corrección de una errata o una edición de documentación, escribir la comprobación primero es ceremonia sin pagador. La tarjeta se gana su sitio cuando el comportamiento es lo bastante estructural como para que alguien salga perjudicado si «hecho» está equivocado.
Cómo usarla
La tarjeta es un dato. Clona el repositorio e impórtala por ruta: lo que llega por la red se trata como contaminado y queda retenido a la espera de aprobación, que es el comportamiento deseable y la razón por la que aquí no hay un instalador de una línea.
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/chimera-write-the-check-before-the-code/SKILL.mdIntegridad
SHA-256 del archivo tal como se publicó. Quien lo importe puede comprobar que lo que recibió es lo que mostró esta página.
95d0a1b750e25af7651e85d26106a91f02f563ab1a1422edc4133d16942b67d7