Propuesta: sección de remotos genérica en AGENTS.md/CLAUDE.md
Con la última sincronización (2026-07-20) notamos que las secciones "Flujo Git y espejos" en AGENTS.md y CLAUDE.md están escritas desde la configuración de un usuario específico:
El repositorio canonico es `Mar-IA-no/HarMoCAP`, remoto local `origin`.
Esa redacción es correcta para la copia de @Mar-IA-no pero no para la de @nicoechaniz, que usa nicoechaniz/HarMoCAP como origin con doble pushurl a AlterMundi. Como ambos trabajamos sobre el mismo repo y estos archivos son instrucciones operativas para agentes, cada merge reintroduce una divergencia cosmética que no refleja diferencias reales de código.
Propuesta: reformular la sección para que describa la arquitectura de remotos sin nombrar un usuario específico como canónico. Algo como:
El repositorio tiene dos líneas públicas: la personal de cada colaborador
(Mar-IA-no, nicoechaniz) y el espejo compartido de la organización
(AlterMundi/HarMoCAP).
Cada colaborador configura `origin` para fetch de su propio repositorio,
con dos `pushurl`: el personal primero y AlterMundi después. El flujo
normal `git push` publica ambos. Tras cada push se verifica que ambos
remotos queden en el mismo commit...
Esto mantiene toda la información operativa (doble pushurl, verificación post-push, merge ante divergencia) sin que un agente en la copia de Nico lea que su origin debería ser Mar-IA-no, ni viceversa.
Propuesta: sección de remotos genérica en AGENTS.md/CLAUDE.md
Con la última sincronización (2026-07-20) notamos que las secciones "Flujo Git y espejos" en
AGENTS.mdyCLAUDE.mdestán escritas desde la configuración de un usuario específico:Esa redacción es correcta para la copia de @Mar-IA-no pero no para la de @nicoechaniz, que usa
nicoechaniz/HarMoCAPcomo origin con doble pushurl a AlterMundi. Como ambos trabajamos sobre el mismo repo y estos archivos son instrucciones operativas para agentes, cada merge reintroduce una divergencia cosmética que no refleja diferencias reales de código.Propuesta: reformular la sección para que describa la arquitectura de remotos sin nombrar un usuario específico como canónico. Algo como:
Esto mantiene toda la información operativa (doble pushurl, verificación post-push, merge ante divergencia) sin que un agente en la copia de Nico lea que su origin debería ser Mar-IA-no, ni viceversa.