chimera-reproduce-before-diagnosing
Un diagnóstico es una afirmación sobre una máquina que no has ejecutado. Reproduce primero el fallo con un solo comando corto — sobre todo cuando el diagnóstico llegó de otra persona.
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
- llegó un reporte de bug
- otro agente explicó la causa
- el traceback apunta a un archivo
- a punto de arreglar algo que no viste fallar
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 cambiar código por un fallo que no has visto ocurrir personalmente: un job de CI en rojo, un extracto de log en un issue, la descripción de un usuario, o — el caso del que realmente trata esta tarjeta — un diagnóstico seguro que te entrega un revisor, un subagente o una herramienta de análisis estático, completo con archivo y número de línea.
No aplica cuando el fallo ya es un solo comando. Una prueba que falla localmente cuando la ejecutas es una reproducción; no construyas una segunda. Tampoco aplica a trabajo que no tiene ningún fallo dentro — una funcionalidad nueva, una refactorización, una pregunta de diseño. Eso no tiene nada que reproducir.
Haz
- Escribe la cosa más corta que falla y se puede ejecutar por sí sola: un script, un node id de pytest, una invocación de la CLI. «Ejecuta la suite y mira el tercer error» no lo es — leerás por encima del error cada vez.
- Ejecútala. Copia la salida real en tus notas: el tipo de excepción, el valor equivocado junto al esperado, el código de salida. No tu resumen de ello.
- Ahora enuncia el diagnóstico, e inmediatamente intenta matarlo. Pon un
raise RuntimeError("here")al principio de la función a la que el diagnóstico culpa y vuelve a ejecutar la reproducción. Si el fallo original sigue apareciendo sin cambios, esa función no está en el camino que falla y el diagnóstico está equivocado por bien argumentado que estuviera. - Arregla, vuelve a ejecutar el mismo comando, y conserva la reproducción como prueba dentro del mismo cambio. Una reproducción que se borra tras el arreglo no puede decirte cuándo el arreglo se revierte.
Evita
Editar el frame del traceback que reconoces. El frame que reconoces es el que has leído antes, no el que está mal, y una edición plausible ahí a menudo hará que el síntoma se mueva a otro sitio — lo cual entonces se lee como progreso.
Evita heredar un diagnóstico como un hecho. Una explicación entregada es texto, y el proceso que produce una explicación fluida y equivocada es el mismo que produce una fluida y correcta, así que la fluidez no lleva información sobre cuál te tocó. Trátalo como una hipótesis con un nombre pegado: útil para ordenar qué probar, inútil como evidencia.
# reviewer says the cache key is missing the tenant id
key = f"{tenant.id}:{user.id}"
# yes — first make the failure appear on demand
# repro.py: two tenants, same user id, assert the second read misses
Y evita el reflejo de reejecutar-hasta-que-esté-verde con un fallo intermitente. Reejecutar no diagnostica una condición de carrera, la esconde, y convierte un bug reproducible una vez en un bug que nadie puede reproducir en absoluto.
Comprueba
Antes de escribir el arreglo, responde sí o no: ¿puedo hacer que este fallo ocurra otra vez, ahora mismo, con un solo comando? Si no, no estás depurando, estás especulando con un editor abierto.
Después del arreglo: ¿pasa ahora el mismo comando, y lo viste fallar antes con tus propios ojos? Un arreglo validado solo porque la suite se pone verde prueba que la suite está verde — algo que puede haber estado así por la razón equivocada, si el caso que fallaba nunca estuvo en la suite.
Riesgo
Algunos fallos son genuinamente caros de reproducir: una condición de carrera que aparece una vez al día, un estado que solo existe en producción, un cuelgue seis horas después de empezar un job largo. Insistir en una reproducción barata ahí quema más de lo que cuesta el bug. Ponle un límite de tiempo, y si el límite expira, di con claridad que el arreglo está sin verificar en lugar de describirlo como confirmado.
La trampa más sutil es minimizar de más. Un script reducido puede empezar a fallar por una razón distinta a la original, y entonces arreglas el juguete. Protégete aplicando el arreglo también al camino original que falla, y confirmando que el síntoma original desaparece ahí — el caso minimizado es una herramienta para encontrar la causa, nunca la prueba de que era la causa.
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-reproduce-before-diagnosing/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.
9d70fa5a61992e3b79a2d0ab2afb592c41a7b63274efbdca0afec1724a5b8338