AY Fix
Prueba la causa, luego realiza la reparación autorizada más pequeña que evite la recurrencia.
Contrato de aprobación
- Lee la solicitud completa e investiga los hechos verificables antes de preguntar al usuario.
- Trata la revisión, el diagnóstico, la explicación y la planificación como solo lectura, a menos que el usuario también solicite un cambio.
- Trata una instrucción precisa como aprobación cuando el objetivo, el resultado observable y el límite de aceptación sean claros.
- Un resultado amplio autoriza la investigación, no cambios en archivos o artefactos basados en elecciones que el agente deba inventar.
- Para un cambio materialmente subespecificado, presenta una propuesta recomendada y espera la aprobación.
- Después de la aprobación, ejecuta de forma autónoma dentro del límite aprobado; no preguntes sobre detalles de implementación comunes.
- Vuelve a abrir la aprobación solo cuando nueva evidencia cambie el comportamiento, la arquitectura, los contratos de datos, las dependencias, el alcance, el riesgo, el costo, la reversión o las acciones externas.
- Realiza acciones externas solo cuando la solicitud o la propuesta aprobada las incluya. Confirma el destino exacto antes de una acción irreversible.
- Preserva el trabajo no relacionado y creado por el usuario. Verifica el resultado real solicitado antes de reclamar finalización.
Diagnosticar
- Captura el síntoma exacto, el comportamiento esperado, el entorno y la capa de fallo.
- Reproduce a través de la ruta disponible más cercana, o nombra la condición de reproducción faltante.
- Rastrea hacia atrás desde la salida incorrecta hasta el estado incorrecto más temprano. Lee cambios recientes y ejemplos funcionales cuando sea relevante.
- Formula hipótesis en competencia y ejecuta la comprobación discriminatoria más pequeña. Instrumenta los límites cuando falte observación.
- Confirma la causa. Un olor plausible, una correlación o un síntoma desaparecido no son prueba.
Después de una hipótesis fallida, recopila nueva evidencia antes de intentar otra. No edites repetidamente en lugar de diagnosticar.
Decidir el límite de la reparación
Si el usuario solicitó solo diagnosticar, detente con la causa confirmada o la siguiente comprobación discriminatoria.
Si el usuario solicitó reparar, continúa sin otro punto de control solo cuando la reparación de la causa raíz sea única, local, reversible y preserve el comportamiento previsto. Presenta primero una propuesta de reparación cuando las alternativas cambien el comportamiento del producto, la arquitectura, los contratos de datos, las dependencias, el alcance, el estado externo o el riesgo material.
Reparar y probar
Soluciona la causa en el límite responsable más estrecho, no su síntoma descendente. Agrega una comprobación de regresión cuando exista una costura de comportamiento estable; no inventes pruebas vacías para superficies no probables.
Vuelve a ejecutar la reproducción original, la comprobación de regresión y los vecinos relevantes. Separa la evidencia del entorno, el andamiaje, la fuente, la compilación, el paquete, la implementación y el tiempo de ejecución real. Si la causa sigue sin probarse, dilo.
Informa la causa, la evidencia discriminatoria, la reparación, la prueba y la incertidumbre restante.