tpierrain/second-brain-generator/sync

/sync — Synchronisation repo inter-machines

Commande utilisateur. Utile quand on travaille sur plusieurs machines (laptop perso / pro)

et qu'on veut récupérer les changements pushés depuis l'autre sans quitter la session.

Quand l'utiliser

• Quand on a travaillé sur une autre machine et qu'on veut récupérer les changements ici.
• En milieu de session, sans avoir à quitter et relancer Claude Code.
• Complète le hook SessionStart (qui fait un pull au démarrage) pour les cas mid-session.

ℹ️ Nécessite un remote git configuré (origin). En usage purement local, ce skill est inutile.

Procédure

Étape 1 — État local

git status --porcelain

Clean → passer à l'étape 3. Dirty → étape 2.

Étape 2 — Commit des changements locaux

git add .
git commit -m "auto: vault/claude sync"

Crée un point de retour sûr avant le rebase.

Étape 3 — Fetch et rebase

node scripts/set-active-universe.mjs current   # le mémoriser : l'étape 5 compare
git rev-parse HEAD                             # mémoriser ce sha : l'étape 5 le passe en --before
git fetch origin
git rebase origin/$(git branch --show-current)

Succès → résumé + étape 5. Conflit → étape 4.

Lire l'univers actif avant de rebaser. Le pull peut transporter un changement de contexte

fait sur l'autre machine du propriétaire (c'est un état versionné, ADR 0034), et l'étape 5 ne

peut le dire qu'en comparant. Au démarrage de session, la même chose est traitée de façon

déterministe par un hook ; en cours de session, ce skill est le seul canal.

Étape 4 — Gestion des conflits

1. Lister les fichiers en conflit : git diff --name-only --diff-filter=U
2. Afficher le diff de chacun avec contexte.
3. Demander à l'utilisateur :

> Conflit sur N fichier(s). Options : > - merge : je résous et on continue le rebase > - abort : git rebase --abort — retour à l'état d'avant (le commit local est safe)

1. Si merge : résoudre intelligemment (contenu vault = souvent append-only → garder les deux versions), git add les fichiers résolus, git rebase --continue.
2. Si abort : git rebase --abort, signaler que le commit local est intact, stop.

Le seul fichier avec une règle permanente : .vault-rag/active-universe

Il contient l'univers (le contexte) dans lequel travaille le propriétaire. C'est une valeur unique, donc « garder les deux » n'a aucun sens, et improviser ici change silencieusement la portée de toutes les recherches pour le reste de la session. La règle, tranchée une fois :

La machine devant laquelle tu es assis·e gagne. On garde la valeur courante de cette

machine ; le prochain /switch du propriétaire la propagera partout.

git checkout --theirs -- .vault-rag/active-universe && git add .vault-rag/active-universe

⚠️ `--theirs` est le bon, et c'est le contre-intuitif. Un rebase rejoue TES commits par-dessus ceux d'origin : pendant le conflit, --ours désigne donc origin (l'autre machine) et --theirs le commit de cette machine, celui qui est en train d'être rejoué. Ne « corrige » pas ça en --ours : ce serait confier la session au contexte de l'autre laptop, exactement ce que la règle refuse. Résous, puis git rebase --continue, et laisse l'étape 5 l'annoncer.

Étape 5 — Push et résumé

git push
node scripts/sync-report.mjs --before <sha de l'étape 3> --committed <yes|no> --pushed <ok|failed>
node scripts/set-active-universe.mjs current   # comparer avec ce qu'a lu l'étape 3
node scripts/set-active-universe.mjs gate      # de quel côté de la porte de divulgation

--committed yes si l'étape 2 a fait un commit ; --pushed ok si git push a réussi.

Relayer le rapport TEL QUEL, tel qu'imprimé, dans un bloc de citation. Ne pas le reformuler, le raccourcir, le résumer ni le compléter, et surtout ne jamais écrire soi-même une date, une heure ou un jour de la semaine : toutes celles du rapport sont calculées par la machine. Pourquoi : ce rapport était rédigé ici, et il a dit « ton autre machine n'a rien poussé » à propos d'une machine qui avait poussé toute la journée. La synchro en arrière-plan avait déjà rapatrié son travail, le rebase n'avait donc plus rien à faire, et seule la trace des arrivées que lit le script distingue ces deux cas. Si le script sort en erreur, dire que le rapport n'a pas pu être produit et pourquoi ; ne pas en rédiger un à la place.

La condition, c'est la PORTE, pas le changement. /sync est précisément le moment où l'univers actif peut arriver d'une autre machine, puisque c'est un état versionné (ADR 0034). Un rapport qui nomme tout ce que le côté git n'a pas changé, en omettant la seule information qu'une synchro peut réellement transporter, laisse le doute là où cette fonctionnalité existe pour l'enlever. Ne jamais trancher en comptant les univers soi-même (ADR 0009) : la commande gate ci-dessus répond.

• `PAST the disclosure gate` : le dire en UNE ligne, en premier, dans la langue du propriétaire.

Toujours, qu'il ait changé ou non. > (changé) Tu es maintenant dans ton univers `<nom>`. > Il t'a suivi·e depuis ton autre ordinateur, et les recherches sont limitées à cet > univers, plus tes notes transverses. > > (inchangé) Univers actif : `<nom>`, inchangé.

• `BELOW the disclosure gate` : ne rien dire du tout sur les univers. Un cerveau mono-contexte

ne doit jamais entendre parler de la fonctionnalité (divulgation progressive, ADR 0034), et ce silence n'est légitime que dans ce cas précis.

Cas limites

• Rien à sync : repo clean + à jour → faire quand même l'étape 5 ; le rapport dit ce qui est

déjà ici et depuis quand. Ne jamais répondre « rien à synchroniser » de soi-même.

• Réseau indisponible : git fetch échoue → signaler, changements locaux intacts.
• Conflit complexe (binaires, restructuration) : recommander une résolution manuelle.