Chapitre 6.3 — Continuité entre sessions & personnes

⏱️ TL;DR — La continuité, c’est faire en sorte que la reprise — la tienne demain, ou celle d’un collègue (humain ou agent) — parte d’un état clair, pas d’un tas de contexte perdu. Les véhicules : la mémoire (CLAUDE.md, docs, ADR) pour ce qui est permanent, le /handoff pour l’état d’un travail en cours, et les artefacts git (messages de commit, PR) pour l’historique des décisions. Règle : laisse toujours le projet dans un état reprenable.

🎯 Objectifs

• Distinguer continuité permanente (conventions) et de travail (en cours).
• Utiliser /handoff pour transmettre un état de travail.
• Faire des commits/PR qui portent la décision, pas juste le diff.
• Laisser un projet dans un état « reprenable ».

Deux continuités, deux véhicules

• Permanente : les conventions et décisions durables. Elles vivent dans le repo (P3) et ne se re-transmettent pas — elles sont là.
• De travail : « où en est-on sur cette feature, qu’a-t-on décidé cette semaine, quel piège nous attend ». Ça change vite ; ça se transmet par handoff et par git.

Confondre les deux est la source des CLAUDE.md transformés en journaux (3.4). La convention va dans la mémoire ; l’état du chantier va dans le handoff/git.

/handoff comme passage de relais

On a vu /handoff côté hygiène de contexte (5.2). Côté continuité, c’est le passage de relais : à la fin d’un chantier non terminé, il produit un document « fait / reste / décisions / pièges » qui permet à la prochaine session (toi ou un autre) de reprendre sans archéologie.

Bon usage inter-personnes :

Tu dois passer une feature en cours à un collègue (ou la reprendre dans deux semaines) : lance /handoff, commite le document (ou colle-le dans la PR). L’autre — humain ou agent — démarre avec l’état exact, pas avec « euh, j’en étais où ? ».

Les commits et PR portent la décision

Un historique git n’est pas qu’une sauvegarde : c’est de la continuité. Un bon message de commit / une bonne description de PR explique le pourquoi, pas seulement le quoi (le diff montre déjà le quoi). Six mois plus tard, c’est ce pourquoi qui évite de « défaire » une décision réfléchie.

« Rédige le message de commit : résume le changement et le pourquoi (le problème résolu, l’alternative écartée si pertinent), format concis. »

L’agent est excellent pour ça — il a tout le contexte de la session. Un historique qui porte les décisions transforme ton git en mémoire longue du projet.

💡 Réflexe d’architecte — Les trois horizons de mémoire d’un projet : le CLAUDE.md (« comment on travaille, toujours »), les ADR (« pourquoi ces choix structurants »), l’historique git (« pourquoi ce changement précis »). Ensemble, ils font qu’aucune décision ne se perd. Un projet bien tenu se raconte tout seul à qui le reprend.

Laisser le projet « reprenable »

Le geste qui résume la continuité : à chaque fin de session, laisse un état reprenable :

• le code build et les tests passent (pas de chantier cassé laissé en plan) ;
• un commit propre marque l’avancement ;
• si le travail est inachevé, un handoff (ou une note « next steps ») dit où reprendre ;
• la mémoire est à jour (si une convention a changé, elle est mise à jour, cf. 3.4).

⚠️ Piège — Laisser une session sur un état à moitié cassé (« je finirai demain »), sans commit ni note. Demain — ou le collègue — hérite d’un puzzle : quel changement était volontaire ? qu’est-ce qui est cassé exprès ? La continuité se prépare en fin de session, pas en début de la suivante.

🧭 Sur TaskFlow — Notre discipline : chaque feature de TaskFlow finit sur un build vert + un commit qui explique le pourquoi + la mémoire à jour. Si une feature déborde sur deux sessions, un /handoff fait le pont. Résultat : reprendre TaskFlow — toi, plus tard, ou quelqu’un d’autre — est trivial. C’est la continuité comme habitude, pas comme effort ponctuel.

✏️ Exercices

Exercice 1 — Commit qui porte le pourquoi. Sur ton prochain changement, fais rédiger un message de commit qui explique le problème résolu et l’alternative écartée. Compare avec tes messages habituels (« fix », « update »).

Exercice 2 — État reprenable. À la fin d’une vraie session, applique la checklist (build vert / commit / handoff si inachevé / mémoire à jour). Le lendemain, mesure le temps pour te remettre dedans.

🧠 Quiz de révision

Chapitre suivant : Les gros codebases — naviguer et modifier du code à grande échelle sans saturer le contexte.