¿Qué hace Diagnóstico de errores?
Construye una señal de aprobación/fallo rápida y específica antes de formar una teoría sólida. Oculta secretos de comandos, salidas, trazas y artefactos guardados.
Bucle
- Reproducir. Escribe un comando que alcance el síntoma exacto del usuario y pueda fallar debido a este error. Si no existe un reproductor ajustado, consulta references/feedback-loop.md.
- Minimizar. Elimina entradas, pasos, invocaciones y configuración uno a la vez. Conserva solo lo que el fallo necesita.
- Hipótesis. Escribe 3-5 causas ordenadas y falsables. Para cada una, nombra la observación que la confirmaría o la rechazaría.
- Probar. Cambia una variable a la vez. Prefiere un depurador o instrumentación centrada en los límites. Etiqueta los registros temporales con un prefijo único
[DEBUG-...]. - Fijar la corrección. Convierte la reproducción real más pequeña en una prueba de regresión fallida en el seam público correcto. Aplica la corrección más pequeña. Vuelve a ejecutar la prueba y la reproducción original.
- Limpiar. Elimina la instrumentación y los andamiajes temporales. Reporta la causa, la evidencia, la corrección y cualquier brecha de cobertura restante.
Reglas
- Después de dos intentos de corrección fallidos, detente. Revisa la hipótesis o el diseño antes de probar otro parche. No acumules conjeturas.
- Para una regresión de rendimiento, mide una línea base y perfila o biseca antes de cambiar el código. Los registros por sí solos no constituyen un diagnóstico de rendimiento.
- Si no existe un seam de prueba correcto, dilo. Después de la corrección, usa
$codebase-designpara juzgar si el seam faltante necesita trabajo estructural. - Reclama éxito solo cuando el síntoma original haya desaparecido y la comprobación de regresión pase.