Proyecto 4, feedback de runtime e indexado

Arreglar una avería a oscuras

Un coche hace un ruido raro. Con el capó cerrado y sin chivatos, el mecánico prueba a ciegas. Con un testigo encendido y un código de error, va directo al fallo. Para un agente, los logs son esos chivatos. Este proyecto mide la diferencia. La teoría está en ver lo que hace el agente y en de la revisión a la regla.

Qué construyes

Sobre el proyecto 3 añades:

• Logs de runtime: arranque, importación, indexación y estados de error.
• Restricciones de arquitectura: un script que detecta violaciones entre capas.
• Un bug sembrado: el indexado rompe el troceado de archivos grandes, y el agente debe corregirlo.

Ejecútalo dos veces: sin logs ni restricciones, y con ambos.

Los dos intentos

La pregunta: ¿cuánto tarda el agente en hallar la causa raíz sin señales y cuánto con ellas? ¿La corrección es más rápida y menos invasiva?

Un log útil

Un log con estructura (qué evento, sobre qué, con qué resultado) se lee mejor que texto suelto:

{"evento":"index.chunk","doc":"informe.pdf","bytes":2400000,"chunks":0,"nivel":"error"}

Ver chunks: 0 en un archivo grande apunta al fallo sin leer todo el código.

El script de límites

Una comprobación mecánica, por ejemplo «los servicios no importan nada del renderer», convierte una norma que el modelo podría olvidar en un fallo visible. Cuando una revisión detecta el mismo error dos veces, ese es el momento de convertirla en regla ejecutable.

Qué mirar al comparar

• Tiempo hasta localizar la causa.
• Número de archivos tocados (¿arregló solo lo necesario?).
• Si el script de límites saltó ante algún cambio indebido.