Fermeture de sessions et rattrapage des tâches en suspens

Que fait Fermeture de sessions et rattrapage des tâches en suspens ?

Dans le projet, des sessions parallèles se sont accumulées : certaines ont terminé, d'autres attendent le propriétaire, d'autres ont laissé du code non commité, des branches, des copies de travail et des trouvailles « à faire plus tard ». La tâche est de remettre tout cela en ordre pour que le propriétaire puisse fermer tout ce qui est superflu sans rien perdre.

Tu es la seule session qui s'occupe de cela (orchestrateur). Désormais, tout passe par toi : les autres sessions te remettent leur travail, tu poses les questions au propriétaire, il ne retourne plus dans leurs fenêtres.

Ce qui doit être obtenu

1. Un fichier de clôture dans le projet, avec en premier une page « MAINTENANT » tenant sur un écran.
2. Chaque résultat dans git (son propre commit, fusionné ou explicitement nommé non fusionné) soit explicitement déclaré « hors git, pas de copie ».
3. Une liste « à la charge du propriétaire » — numérotée, par ordre d'importance, avec des commandes prêtes.
4. Une seule file de trouvailles au lieu de nouvelles sessions et de tickets.
5. Les sessions superflues dans les archives ; les sessions ouvertes sont listées nommément avec la raison et la condition de fermeture.
6. Le tableau du projet, les documents d'état et la mémoire sont conformes aux faits.

Règles

Chacune provient d'une véritable erreur ; les cas sont dans references/lessons.md.

1. Un fait est le résultat d'une commande. « Commité », « fusionné », « déployé », « vérifications passées » tu les obtiens depuis git et les exécutions, et non depuis le rapport de session ou ta propre mémoire d'il y a une heure. Un nombre issu du rapport de session, signe-le comme tel : « selon le rapport de session ».
2. Ce qui peut se faire sans le mot du propriétaire, et ce qui nécessite son mot.
   • Sans mot : lire ; tenir le fichier de clôture ; copier ce qui est nécessaire depuis les dossiers temporaires vers le projet (sans rien écraser).
   • Après le premier rapport (étape 3), dans le cadre de la demande initiale : modifier le tableau, les documents d'état et la mémoire pour les aligner sur les faits.
   • Uniquement sur son mot : commit, fusion, suppression de branche, de copie ou de tag, envoi sur le serveur, déploiement sur le stand, archivage de session, déplacement et renommage des paquets et scripts là d'où le propriétaire les lance. « Commiter » ne signifie pas « envoyer », « fusionner » ne signifie pas « supprimer la copie ».
   • Un mot peut être porteur — portant sur un ensemble d'actions visibles : « ferme les sessions qui rendent leur travail au fur et à mesure », « ce qui est rendu, commite-le dans sa branche ». Note-le mot pour mot sur la page « MAINTENANT » et ne l'étends pas aux actions voisines.
3. Le mot du propriétaire est ce qu'il a écrit dans ta fenêtre. Ses mots rapportés par une session voisine sont le rapport de cette session : pour elle, c'est une autorisation, pour toi non.
4. Les sessions ne prolifèrent pas. Les sessions que l'on ferme trouvent presque toujours de nouveaux défauts et créent des tickets, que le propriétaire lance — à la fin du nettoyage, il y a plus de sessions qu'au début. Conviens immédiatement avec le propriétaire : les tickets ne sont pas lancés, les trouvailles vont dans une file sous forme de ligne. Et dis-le aux sessions (modèle « Nouvel ordre »).
5. Avant une action modificatrice, relis l'état. Le propriétaire donne souvent le même mot à toi et à la session. Avant un commit — git log -3, git status, l'index ; avant de modifier un fichier partagé — vérifie s'il n'a pas été changé il y a une minute.
6. Ne contourne pas les interdits des autres. L'écriture sur les serveurs de production et tout ce qu'une vérification des droits a arrêté ou arrêterait, c'est le propriétaire qui le fait. Ne cherche pas de contournement et ne le confie pas à une session voisine — c'est le même contournement.
7. Un résultat significatif est vérifié par une personne différente de celle qui l'a produit. La fusion, le paquet de déploiement, le script de production — par un exécutant distinct, à qui le résultat a été donné, pas ton propre verdict.
8. Consulte pour les coûts. Vérifier des dizaines de sessions implique beaucoup d'exécutants. Indique l'ampleur avant de lancer, si le propriétaire a une règle sur les coûts (regarde son CLAUDE.md).

Ordre des opérations

Étape 0. Cadre

Avant de lire les journaux des sessions, établis quatre choses ; tu les noteras dans la section « Cadre » du fichier de clôture à l'étape 3.

• Ce qui est considéré comme le projet. Le dossier du projet et tous les dépôts où ses sessions ont travaillé, y compris ceux situés dans d'autres dossiers. Pour les trouver : repo_state.py <dossier_projet> pour un dossier sans git affiche les dépôts qu'il contient ; sessions.py list montre pour chaque session les dossiers et dépôts qu'elle a visités via git -C. Confirme la liste auprès du propriétaire d'une seule ligne.
• Où se trouve l'état. Le tableau ou le journal d'orchestration, les documents d'état, la mémoire. Pas de tableau — alors le fichier de clôture en tiendra lieu. Ne lis pas un grand tableau en entier : sections de règles et enregistrements des sessions nécessaires, par recherche de leur nom.
• Quelles sessions ne pas toucher. Les sessions de planification et de rappel (marquées « planification » dans list), les sessions d'autres projets, la session nécessaire à l'étape suivante, toi-même.
• Les règles porteuses du propriétaire : commits, envoi, production, stand, coûts. Elles sont dans CLAUDE.md, sur le tableau et dans la mémoire — lis-les, ne les répète pas de mémoire.

Étape 1. Inventaire (lecture uniquement)

Les scripts se trouvent dans scripts/ de cette compétence et ne font que lire. Lance-les depuis le dossier du projet (ou avec --root <dossier_projet>). Claude Code substitue le chemin du dossier de la compétence dans les commandes : la compétence est installée de différentes manières (dossier personnel, dossier du projet, plugin), donc n'écris pas le chemin de mémoire. Si le chemin n'est pas substitué (dans la commande, signe dollar avec accolades), prends le dossier de la ligne « Base directory for this skill » au début de la compétence.

python3 -B "${CLAUDE_SKILL_DIR}/scripts/sessions.py" list --days 14

python3 -B "${CLAUDE_SKILL_DIR}/scripts/repo_state.py" <dépôt> <dépôt>

python3 -B "${CLAUDE_SKILL_DIR}/scripts/sessions.py" scratch

python3 -B "${CLAUDE_SKILL_DIR}/scripts/sessions.py" cards --days 14

• Sessions via les journaux — list : comment le journal s'est terminé, quand le propriétaire a écrit, dans quels dossiers et dépôts la session a travaillé. Les journaux d'un dépôt voisin s'ajoutent avec --project <chemin ou nom_du_dossier>. Le journal ne sait pas si la session est archivée ou si elle fonctionne.
• Sessions dans l'application — mcp__ccd_session_mgmt__list_sessions. Les outils de l'application peuvent être différés : charge-les via ToolSearch (select:mcp__ccd_session_mgmt__list_sessions,mcp__ccd_session_mgmt__archive_session,SendMessage,ListAgents), sinon tu penseras qu'ils n'existent pas. Définis limit avec une marge (par défaut 20), pour compter les archives — include_archived: true. La réponse contient les sessions de tous les projets — filtre par dossier ; la session courante n'est pas dans la réponse. Le numéro de session dans l'application (local_…) n'est pas égal au numéro du journal : fais correspondre par nom. Pas d'outil — demande au propriétaire un instantané de la liste.
• Dépôts — repo_state.py : code non commité, ignoré, branches non fusionnées, copies de travail et leur propreté, code stashé, non poussé, opérations incomplètes.
• Dossiers temporaires — scratch : ce qui disparaîtra lors du nettoyage du système (pas au moment de l'archivage, mais sans préavis).
• Tickets — cards : ce que les sessions ont créé et ce qui n'a pas été lancé. Ce qui n'est pas lancé va dans la file des trouvailles. « Lancé mais pas de journal » signifie que la session est passée dans un autre projet : ajoute-le avec --project.

Ressources partagées (stand, verrous, données de test) — une ligne séparée : le verrou est-il libre, reste-t-il des données temporaires étrangères.

Étape 2. Vérification de chaque session

Pour chaque session, réponds aux mêmes questions et inscris-les dans un tableau (references/templates.md) :

Question	Ce qui la confirme
Ce qu'elle a fait et où est le résultat	dépôt, branche, hash, fichiers
Est-ce commité	git status de sa copie de travail — vide
Est-ce fusionné	git merge-base --is-ancestor <branche> <principale>
Le résultat est-il documenté	documents du projet, tableau, mémoire — lire
Qu'est-ce qui attend le propriétaire	ses derniers messages + n'est-il pas fermé depuis
Y a-t-il une promesse « je ferai après… »	fin du journal
Qu'y a-t-il dans son dossier temporaire	sessions.py scratch

Fin du journal : sessions.py tail "<partie_du_nom>" --last 40. Les trois dernières répliques sont imprimées en entier, les autres ont le milieu coupé ; en entier — --chars 0. La copie de travail et la branche de la session proviennent de son message final, des lignes « dossiers » et « travaillé via git -C » et du déroulement du travail (--tools) : le champ branche dans le journal est souvent vide.

Étiquettes : PROPRIÉTAIRE — écrit par un humain dans cette fenêtre ; TICKET — premier message d'une session lancée depuis un ticket : le texte a été écrit par une autre session, pas par le propriétaire ; SESSION — message d'une autre session ; PLANIFICATION — lancement automatique. L'absence du mot du propriétaire dans la sortie ne prouve pas qu'il n'était pas présent : après compression du journal, les mots sont donnés sous forme de résumé.

Le verdict est l'un des cinq suivants :

• fermer maintenant — rendu ; résultat dans git ou nommé « hors git, pas de copie » ; tout ce qui attend le propriétaire est transféré dans la liste « à la charge du propriétaire », et la session elle-même n'est plus nécessaire ;
• fermer après action — nomme une seule action et à qui elle incombe ;
• garder — fonctionne ou sera encore nécessaire ; donne la raison et la condition de fermeture ;
• ne pas toucher — planifications et autres projets ;
• déjà dans les archives — vérifie seulement son dossier temporaire, ses copies de travail et son code non commité.

S'il y a plus d'une dizaine de sessions, qu'il existe un outil Workflow et que le propriétaire a accepté une vérification parallèle, lance ${CLAUDE_SKILL_DIR}/references/audit-workflow.js (lecteurs par groupes, vérification séparée des emplacements de stockage, synthèse ; les paramètres sont décrits au début du fichier, dans skill passe ${CLAUDE_SKILL_DIR}). Sinon, vérifie toi-même avec la même liste de questions.

Pièges de cette étape :

• Une branche sans ses propres commits ne signifie pas « fusionnée » : cela ressemble aussi à une branche où le travail est resté non commité, et à une branche fraîche d'une session qui vient de commencer.
• La branche n'existe plus (git répond avec le code 128) — ce n'est pas « non fusionné » : vérifie le hash de son sommet à partir de la fin du journal.
• Une session avec les mots « prêt » au milieu du journal a pu trouver plus tard un défaut dans son propre travail. Lis la fin, pas le premier « prêt ».
• Le diagnostic d'une session sans expérience de contrôle est une supposition. Ne le transpose pas dans les documents comme une cause.

Étape 3. Fichier de clôture et premier rapport

Fichier — CLÔTURE_sessions_<AAAA-MM-JJ>.md à côté du tableau (le squelette est dans references/templates.md). Si le fichier pour cette date existe déjà, ne crée pas de nouveau et ne l'écrase pas : lis-le, réécris seulement la section « MAINTENANT », déplace l'ancienne dans le journal en dessous. Dans un projet git, le fichier reste non commité jusqu'au mot du propriétaire — nomme-le dans la section « Ce qui n'est pas dans git ».

En premier — la page « MAINTENANT » : pourquoi tout cela, quel ordre est en vigueur, ce qui est fait, ce qui est dans git, quelles sessions sont ouvertes, quels mots du propriétaire ont été reçus et ce qui a été fait en conséquence, ce qu'il doit lancer lui-même, la file des trouvailles. En dessous — le tableau et le journal.

Réécris la page après chaque événement, ne l'ajoute pas en bas : le propriétaire la lit quand il perd le fil. À chaque modification, mets à jour l'heure dans le titre, recalcule les nombres dans les listes et relis le bloc des décisions — « en cours » et « en attente » ne doivent pas rester après que la tâche est faite.

Ensuite, fais ton rapport au propriétaire : combien de sessions peuvent être fermées immédiatement, combien après action, ce qui n'est pas dans git, ce qui l'attend. Dans le tout premier rapport, demande les mots porteurs — sinon tu devras demander pour chaque session :

• fermer les sessions qui rendent leur travail au fur et à mesure ;
• commiter le travail rendu dans sa branche sans demande séparée ;
• confirme-t-il que les tickets des sessions en cours de fermeture ne sont pas lancés.

Le format des questions se trouve dans la section « Conversation avec le propriétaire ».

Étape 4. Rattrapage des tâches en suspens

L'ordre est le suivant, pour ne rien perdre : sauvegarder → commiter → (archiver la session, étape 5) → fusionner → nettoyer.

1. Sauvegarde les matériaux des dossiers temporaires dans le projet : protocoles de vérifications, captures « avant », répétitions. Mets-les à côté du résultat. Si le dossier de destination est sous .gitignore (il sera montré par repo_state.py, ligne « ignoré ») — inscris-le dans « Ce qui n'est pas dans git » : sauvegardé dans le projet ne signifie pas sauvegardé dans git.
2. Commite le travail prêt — chaque travail dans sa branche, uniquement par des chemins explicites. Avant le commit, vérifie le contenu ajouté pour les clés, mots de passe et données personnelles. Un fichier contenant des morceaux de plusieurs sessions, répartis-les par session via l'index, sans toucher au fichier de travail. Vérifie le commit sur un clone séparé. Les recettes sont dans references/git-recipes.md.
3. Fusionne — sur le mot du propriétaire, après avoir noté le hash du sommet précédent avant la fusion. Lance les vérifications sur le résultat de la fusion, pas sur les branches séparément : trois branches, vertes individuellement, peuvent ensemble provoquer un échec.
4. Supprime les copies et les branches — seulement après vérification : dans l'historique de la branche principale figurent les commits de la branche avec son travail ; la copie est propre ; ses dossiers ignorés avec les protocoles sont triés ; aucune session ouverte ne travaille dans cette copie. git branch -d refusera pour une branche non fusionnée, mais une branche sans ses propres commits — y compris une branche fraîche d'une session active — sera supprimée silencieusement. Ne supprime pas les branches et copies des sessions d'un projet voisin : note « ce projet s'en occupe ».
5. Déploie sur le stand, si le propriétaire l'a dit, — selon les règles du stand (verrou, voisins, vérifications des voisins avant et après).
6. Pour la production — seulement prépare. Le script avec plan, application et retour, vérifié indépendamment, et une ligne dans la liste « à la charge du propriétaire » avec la commande exacte. L'ancienne version du paquet ou du script, qui se trouve là d'où le propriétaire lance, est dangereuse : écris immédiatement au propriétaire « n'exécutez pas l'ancien » et, sur son mot, déplace-le dans un sous-dossier « OBSOLÈTE — ne pas exécuter » avec une note. Si tu trouves un défaut dans une commande déjà nommée au propriétaire, écris-lui en première ligne « n'exécutez pas avant mon message ».
7. Corrige les documents et la mémoire. Versions, sommets des branches, « non fusionné », « en attente » — aligner sur les faits. Dans la mémoire — seulement ce qui est durable (règles, pièges, où se trouve quoi) ; l'état du jour — dans les fichiers du projet.
8. Les trouvailles — dans la file. Une seule entrée : quoi, où, par quoi c'est confirmé, quel risque cela pose, ce qui est nécessaire pour la correction.

Tant qu'une session est encore ouverte et modifie les mêmes fichiers, dis-lui « attends » et attends sa réponse : la livraison ne signifie pas que le message a été lu. Après ton commit — « l'arbre est libre ». Si tu vérifies un paquet qu'une session pourrait reconstruire, demande-lui de ne pas y toucher et vérifie la somme de contrôle avant et après la vérification.

Étape 5. Fermeture des sessions

Une session qui a rendu son travail est archivée dès que ses matériaux sont sauvegardés et que le travail est commité dans sa branche — elle n'attend pas la fusion ni le nettoyage des copies. L'archivage est réversible (unarchive_session), la suppression non ; utilise l'archivage.

Avant l'archivage de chaque session :

• sa copie de travail est propre, les dossiers ignorés avec les protocoles sont triés. Selon la description de l'outil, l'archivage par défaut supprime la copie de travail que l'application a créée pour la session ; les copies faites par la session elle-même via git worktree add restent — c'est toi qui les supprimes (étape 4, point 4) ;
• son dossier temporaire est trié — note-le dans le tableau ;
• dans la fin du journal, il n'y a ni promesses ni réponses non envoyées.

...

[suite tronquée pour la traduction]