Rituels d'instance — /pwp, /sync, /wakeup

Les instances Claude de l'écosystème partagent trois rituels outillés en skills Claude Code. Ce document est leur référence canon (le « quoi » et le « pourquoi », durable et versionné). Les skills eux-mêmes vivent hors dépôt, dans ~/.claude/skills/<nom>/SKILL.md (machine de Mathieu, installables par toute instance) — ils portent le « comment » exécutable et font foi sur les détails de procédure.

Les trois sont complémentaires et bornés : aucun ne déborde sur le périmètre d'un autre.

/pwp — Print Working Project

À quoi ça sert : en une ligne, façon pwd mais à l'échelle projet — nom du dépôt, rôle de l'instance, branche git. Sert quand on jongle entre plusieurs fenêtres/sessions et qu'on ne sait plus « c'est quel repo ici ? ».

• Déclencheurs : /pwp, ou « je suis dans quel projet ? », « c'est quel repo ? ».
• Lecture seule, instantané, sans effet de bord.

/wakeup — réveil d'instance

À quoi ça sert : donner une orientation fiable et homogène en début de session — remplace le réveil improvisé « de mémoire » par un rituel reproductible.

• Déclencheurs : « wake up », « réveil », /wakeup, « fais le point », ouverture de session après une absence.
• Déroulé : (1) identité & rôle (mapping dépôt → profil), (2) état des inboxes non lues (lecture seule), (3) état du dépôt (branche, HEAD, arbre), (4) restitution adaptée au rôle.
• Profils de sortie :
  • dev (exécutants) — point scrum : ✅ dernier livré · 🚧 en cours · ⚠️ difficultés/warnings · 📋 TODO · ➡️ next step proposée si TODO, sinon « à dispo ».
  • lead (Chef, Lead Tech) — idem + 🔗 vue dépendances (artefacts pilotés, impacts transverses) + par défaut, ne pas relever les inboxes des autres dépôts.
  • doc (Atlas, telaria-doc) — idem + 🗺️ topologie (versions courantes depuis ecosystem.md) + 📐 canon & coordination (arbitrages ouverts).
• Garde-fous : n'agit pas (pas de code/commit/déploiement), n'écrit aucune inbox (ça reste /sync). La « next step » est une proposition, pas un lancement. Le comptage des #N se fait sur les lignes d'en-tête de message uniquement (jamais sur les #N cités dans le corps — sinon faux positif de courrier en retard).
• S'il y a du courrier en retard, /wakeup propose d'enchaîner sur /sync (lui seul relève et acke).

/sync — synchronisation inter-instances

À quoi ça sert : systématiser la relève (PULL) et le dépôt (PUSH) de courrier entre les instances, via les inboxes fichiers (asynchrones — vérité = commits).

• Déclencheurs : /sync, « check inboxes », « notifie X », « synchroniser les instances », ou en fin de session après un commit qui touche un fichier publié (specs, bundles, releases.md, contrats d'interface).
• PULL : liste les inbox-from-*.md, compare au sync-state.json (last_seen.<inbox>), résume les non-lus, propose de marquer lus.
• PUSH : récolte le signal de session (git log depuis last_pushed_sha_to), drafte un message, le montre pour validation humaine obligatoire, puis l'append à l'inbox cible et met à jour sync-state.json.
• Garde-fous : validation humaine avant toute écriture ; pas de messagerie temps réel ; pas de purge d'inbox. L'état « lu » vit dans sync-state.json côté lecteur, jamais en modifiant le fichier inbox.

Rituel — validation des specs

Ce rituel ne s'exécute pas automatiquement par un hook ou un outil dédié : il s'applique manuellement, aux moments clés décrits ci-dessous (wakeup, release, transition de statut). Sa valeur est d'être un point de passage documenté, opposable à tous.

Tableau des statuts valides

Note de convergence. Les specs existantes utilisent un jeu de valeurs légèrement différent (conceptuel, en-cours, livré) issu des conventions DOCUMENTATION.md. Les valeurs ci-dessus définissent la cible pour les nouvelles specs soumises à ce rituel ; les specs anciennes seront migrées progressivement. En attendant, considérer conceptuel ~ draft et en-cours ~ draft pour l'application des règles ci-dessous.

Règle fondamentale

Une spec en statut draft (ou ses équivalents actuels conceptuel/en-cours) ne peut pas être implémentée : le code correspondant ne peut pas être mergé en master. Seules les specs en stable ou livré sont approuvées pour implémentation.

Cette règle est contraignante côté process humain — pas contraignante côté outillage automatique (pas de hook git qui bloque). La responsabilité de la vérification incombe à l'instance Atlas (via /wakeup) et au Lead Tech du projet concerné (via la checklist de release).

Gate /wakeup

Lors de chaque /wakeup, Atlas (instance telaria-doc) effectue les vérifications suivantes :

1. Lister toutes les specs dans 02-ce-que-je-construis/specs/ dont le status est draft, conceptuel ou en-cours.
2. Pour chacune, vérifier si elle contient une section ## Implémentation ou une mention d'implémentation active (signal qu'un agent exécutant a commencé à travailler dessus).
3. Si une telle spec est trouvée, la signaler explicitement dans le résumé /wakeup — c'est une anomalie de processus à résoudre avant toute release.

Format de signalement dans le résumé /wakeup :

ANOMALIE specs — specs non validées avec implémentation suspectée :
- specs/ia-mcp.md (status: en-cours) — section ## Implémentation présente

Gate release

Avant tout merge develop → master (release), la checklist de release doit inclure l'étape suivante :

Vérifier qu'aucune spec implémentée n'est encore en draft — parcourir 02-ce-que-je-construis/specs/, lister les specs draft/conceptuel/en-cours, confirmer qu'aucune n'a de code actif associé en develop.

Cette étape est à ajouter dans 03-comment-je-travaille/guides/releases.md lors de l'onboarding du Lead Tech Telaria.

Transition de statut : draft -> stable

Pour faire passer une spec de draft à stable, les conditions suivantes doivent être réunies :

1. Contenu complet : toutes les sections requises sont remplies (objectif, périmètre, contrats d'interface si applicable, critères d'acceptance).
2. Revue croisée : Atlas (Doc Lead) et le Lead Tech concerné ont tous deux lu la spec. Pour les specs à fort impact technique, la revue Lead Tech est obligatoire.
3. Validation Mathieu : pour les specs qui définissent un comportement produit visible (non purement technique), Mathieu valide explicitement.
4. Mise à jour du frontmatter : status: stable et updated: AAAA-MM-JJ dans le cartouche YAML.

Procédure concrète :

1. L'auteur (Atlas ou exécutant) ouvre une inbox vers Archie signalant la spec prête pour revue.
2. Le Lead Tech concerné répond (inbox retour) avec validation ou demande de corrections.
3. Une fois les deux validations obtenues (ou Mathieu pour le produit), l'auteur met à jour le status et commit.
4. Le commit de transition de statut est suffisant — pas besoin de PR dédiée (mode solo + IA).

Voir aussi

• Skills (font foi sur le « comment ») : ~/.claude/skills/{pwp,wakeup,sync}/SKILL.md ; rituel /sleep : pilotage/rituel-sleep.md (pas encore de skill dédié).
• Registre canon (rôles, profils, inboxes, versions) : ecosystem.md.
• Journal des décisions partagées : coordination.md.
• Le réflexe « lire son inbox + coordination.md au démarrage » est rappelé dans l'AGENTS.md de chaque dépôt.
• Audit Diátaxis des guides et tutos : pilotage/audit-diataxis.md.