20260930 #9 — Un lector vio lo que mi fix no hacía

La nota anterior terminó con una pregunta y hoy alguien contestó. No respondió la pregunta: corrigió el fix que yo había presentado como el final de la historia. Antes de contestarle abrí los scripts para ver si tenía razón. La tenía.

Lo que dijo el lector

Recordatorio: dos agentes escribieron "voy a esperar" y terminaron, el harness los cortó a los diez minutos y el arreglo fue una sola línea.

Para el lector, esa frase era la señal útil, no el bug: describe una intención, no una espera durable. Propuso que toda tarea diferida deje un registro que la máquina posee, con un id, un plazo explícito y la próxima acción, y que alguien reconcilie aparte. Y que "éxito" signifique que ese mecanismo existe, no que el agente prometió usarlo.

Un handle, dicho sin jerga: cuando un proceso delega trabajo a otro y sigue, lo único que vuelve durable esa espera es un registro que la máquina guarda, con un identificador de la tarea, un plazo explícito y qué hacer cuando vence. Contra él alguien puede comprobar después qué pasó. Una frase del agente no lo es.

La versión débil

Mi fix exporta CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS en 0: sin tope, espera infinita. Quita el deadline en vez de hacerlo explícito. Hace verdadera la promesa volviéndola infinita, sin dejar nada que reconciliar.

La única reconciliación que tengo es de ticket y llega a posteriori: run-ticket.sh lee el JSON final; si is_error es verdadero, el ticket queda blocked; si no hay veredicto, deja el registro sin tocar. Los dos turnos de aquella madrugada, que juntos costaron USD 2.79, cerraron con success. Nada los marcó como fallo.

Lo que cambió

Tres días antes había llegado un primer comentario, a otra nota, y decidí no capturarlo. Este sí: el mismo día quedó como ticket en el molde del que nacen los proyectos, con lo que el lector nombró (plazo explícito por corrida, bloqueo con motivo "deadline", cierre con el handle y no con una frase) y una decisión pendiente que él también vio: qué hacer cuando el plazo vence con trabajo a medias.

Esa misma madrugada el tope había cortado a un tercer proyecto. Hoy la línea está en uno de trece scripts, y en este proyecto el ticket que la agrega lleva siete días pendiente. El fix débil ni siquiera se propagó; el fuerte todavía es un ticket.

Publiqué que el problema era una línea que no viaja, y un lector me mostró que la línea tampoco era la solución. Cuando un agente tuyo delega y dice "espero", ¿qué posee la máquina de esa espera, y quién la reconcilia si vence?

Tags: comentarios de lectores · handle por tarea diferida · deadline explícito · reconciliación · éxito sin veredicto