thebpandey/session-cleanup

Nettoyage de session

Auditer d'abord, supprimer ensuite, et seulement après inspection de la cible. L'objectif est que le propriétaire puisse quitter la session en sachant que rien ne tourne, rien n'est perdu et rien d'obsolète n'est laissé derrière. Un résidu oublié est peu coûteux ; un commit non poussé supprimé ne l'est pas. En cas de doute, un élément va dans ASK, jamais dans AUTO-CLEAN.

Fonctionne dans tout dépôt git. Les parties relatives au harnais lanes, aux perles et à Vercel ne s'activent que lorsqu'elles sont présentes ; elles sont ignorées silencieusement sinon.

Phase 1 : Audit (lecture seule)

Exécutez l'audit fourni depuis le dépôt (n'importe quel arbre de travail de celui-ci). Utilisez le script pour votre système d'exploitation ; le dossier de la compétence peut se trouver sous ~/.claude/skills/, ~/.codex/skills/ ou ~/.agents/skills/ :

# Linux et macOS
bash <skill-dir>/scripts/audit.sh                 # ajouter --no-fetch hors ligne

# Windows (PowerShell 5.1 ou 7)
powershell -NoProfile -ExecutionPolicy Bypass -File <skill-dir>\scripts\audit.ps1   # ajouter -NoFetch hors ligne

Les deux affichent une section par domaine (CONTEXT, WORKING_TREE, SYNC, WORKTREES, BRANCHES, STASHES, LANES, PROCESSES, ARTIFACTS, TRACKER, DEPLOY, SESSION_LOG). La seule écriture est un simple git fetch (jamais --prune). Il ne lit jamais les fichiers .env ni n'affiche les environnements des processus.

Comment il décide « cette session » (cela compte pour chaque classification) :

• Processus : owner=this_session signifie que cette session (ou quelque chose lancé par elle) a démarré le processus. Sous Linux, cela est prouvé par le CLAUDE_CODE_SESSION_ID hérité, qui survit à nohup. macOS et Windows masquent les environnements des autres processus, donc cela signifie « descendant du processus Claude » (CLAUDE_PID) ; un processus qui a été détaché et réparenté s'affiche comme started_during_session à la place, ce qui est ASK sauf si vous pouvez le tracer dans cette conversation. owner=harness_do_not_kill correspond aux propres serveurs MCP et plugins de Claude Code : ne jamais y toucher. other_session_or_user appartient à quelqu'un d'autre.
• Fichiers, branches, stashs : this_session / pre_session compare l'horodatage avec session_start (premier horodatage dans le transcript de cette session). Les horodatages sont une indication, pas une preuve : quelque chose créé pendant la fenêtre de session pourrait provenir d'une session parallèle. Traitez un élément comme appartenant à cette session uniquement lorsque l'horodatage le dit et que vous pouvez le tracer dans cette conversation (vous avez exécuté la commande qui l'a créé). Sinon, c'est ASK.

En dehors de Claude Code (par exemple dans Codex), il n'y a ni CLAUDE_CODE_SESSION_ID ni CLAUDE_PID, donc session_id est unknown, tout est étiqueté pre_session, et les processus sont appariés uniquement par in_repo. Passez --since <heure ISO> (-Since sur Windows) avec le début de session si vous le connaissez, et sinon traitez les fichiers et processus comme ASK sauf si vous pouvez les tracer jusqu'à une commande dans cette conversation.

Ensuite, comblez les lacunes que le script ne peut pas voir, en parallèle si possible :

1. Votre propre travail en arrière-plan. Listez les tâches Bash en arrière-plan, les Moniteurs, les sous-agents et les réveils planifiés que vous avez démarrés dans cette conversation et qui sont encore en cours d'exécution. Arrêtez ceux qui sont terminés ou inactifs avec l'outil qui les a démarrés (TaskStop, arrêt du Moniteur, etc.).
2. Résidus de demandes. Parcourez la conversation pour tout ce que le propriétaire a demandé de supprimer plus tard ou de ne conserver que temporairement (un dossier uploads, un indicateur de débogage, un compte de test, un fichier temporaire). Vérifiez s'il existe toujours.
3. État du déploiement (uniquement si DEPLOY montre une plateforme). Obtenez le SHA du commit du dernier déploiement de production et comparez-le avec main_tip. Pour Vercel : vercel ls --prod pour trouver le dernier déploiement de production, puis vercel inspect <url> (ou le MCP/tableau de bord Vercel) pour son commit git. Si vous ne pouvez pas obtenir le SHA, signalez « déploiement : non vérifié » avec la raison. Ne déduisez jamais une correspondance à partir des horodatages.
4. Tout ce qui est en dehors du dépôt que la session a touché (un arbre de travail d'un autre dépôt, une installation globale). Signalez-le ; ne le modifiez pas.

Phase 2 : Classifier chaque résultat

AUTO-CLEAN (sûr et récupérable ; faites-le, puis signalez-le) :

• Branches locales entièrement fusionnées dans main (git branch -d, jamais -D), à l'exclusion de main, de la branche courante et de toute branche extraite dans un arbre de travail.
• Enregistrements d'arbres de travail élagables dont le dossier a déjà disparu (git worktree prune).
• Arbres de travail liés et propres à l'intérieur de ce dépôt dont la branche est fusionnée dans main et n'a pas de commits en avance (git worktree remove <path>, sans --force ; puis git branch -d). Si le harnais lanes le possède, utilisez le script du harnais à la place (voir ci-dessous).
• Dossiers temporaires dont la lane ou la branche n'existe plus et qu'aucun processus n'a ouverts (open_handles=0 ; revérifiez avec lsof +D <dir> immédiatement avant de supprimer).
• Processus avec owner=this_session que vous pouvez tracer jusqu'à cette conversation et qui sont inactifs ou inutiles (serveurs de dev, observateurs, navigateurs sans tête). Tuez uniquement par PID (kill <pid> sous Linux/macOS, Stop-Process -Id <pid> sous Windows).
• Caches de build obsolètes (.next/types, .next/dev/types) qui sont gitignorés. Ils se régénèrent à la prochaine build.
• Propres fichiers temporaires de cette session dans son dossier de bloc-notes, et déchets non suivis dans le dépôt (*.orig, *.rej, journaux épars) qui sont this_session et traçables jusqu'à une commande que vous avez exécutée.

ASK (pourrait entraîner une perte de travail, ou n'est pas prouvé comme appartenant à cette session) :

• Branches non fusionnées, ou tout commit qui n'est pas dans main. Une branche marquée PATCHES_ALREADY_IN_main a probablement été fusionnée par squash ou rebase : dites-le, mais demandez quand même avant de faire -D.
• Arbres de travail sales (dirty_files > 0), stashs, dossiers coverage/ et test-results/ qui pourraient être souhaités comme preuves.
• Processus other_session_or_user ou started_during_session, et tout processus que vous ne pouvez pas tracer.
• Tout ce qui est pre_session, et tout fichier non suivi que vous n'avez pas créé.

REPORT ONLY (le propriétaire agit, ou c'est informationnel) :

• Écart entre main et origin (non poussé ou en retard). Recommandez le push ou pull ; ne le faites pas dans le cadre du nettoyage.
• Décalages de déploiement ou état de déploiement « non vérifié ».
• Éléments de suivi ouverts (perles in_progress, tasks.md WIP) sans travail actif, et travail terminé dont la tâche est toujours ouverte. Nommez l'élément et ce que vous avez vu.
• Arbres de travail ou dossiers en dehors de ce dépôt, et branches upstream_gone qui ont encore des commits uniques.

Règles de sécurité

Elles protègent le travail qui ne peut pas être recréé. Chacune existe parce que le raccourci évident a déjà détruit du travail.

• Inspectez avant de supprimer. Pour chaque dossier, listez son contenu et sa taille d'abord. Pour chaque branche, affichez git log --oneline main..<branch> d'abord. Mettez cette preuve dans le rapport.
• Ne supprimez jamais de commits non fusionnés, d'arbres de travail sales ou de stashs sans l'approbation explicite du propriétaire dans cette conversation. L'approbation pour un élément ne couvre pas le suivant.
• Tuez les processus uniquement par PID, après avoir confirmé owner=this_session et que vous l'avez démarré. Jamais pkill, killall, kill -9 en première tentative, ou tuer par port seul.
• N'utilisez jamais git stash brut, git reset --hard, git clean -fdx (ou tout git clean -f), ou rm -rf avec un glob. Ceux-ci n'ont pas d'annulation. Supprimez les chemins nommés un par un.
• git branch -D, git stash drop et git worktree remove --force ne s'exécutent que sur l'élément unique approuvé par le propriétaire, après avoir montré ce qui sera perdu (commits, diff stat). Enregistrez le SHA de la pointe de la branche dans le rapport afin qu'elle puisse être restaurée.
• Ne lisez, n'imprimez, ne déplacez ou ne supprimez jamais les fichiers .env, les clés ou les identifiants, même s'ils ressemblent à des déchets. Signalez-les uniquement par leur chemin.
• Restez à l'intérieur de ce dépôt. Les arbres de travail d'autres applications, les extractions détachées ou les dossiers partagés /tmp sont signalés, pas touchés. Ne glob-deletez jamais dans /tmp.
• Ne tuez jamais les processus harness_do_not_kill ni le processus Claude lui-même.

Quand le harnais lanes est présent

Uniquement si la section LANES montre un répertoire d'état. Sinon, ignorez ce bloc.

• Supprimez les arbres de travail de lane, les répertoires temporaires de lane, les répertoires de travaux de relais et les lignes de lanes.tsv avec le script propre du harnais, jamais avec rm : bash ~/.claude/skills/lanes/lane/cleanup.sh <lane-dir> <branch> pour une lane fusionnée, puis bash ~/.claude/skills/lanes/lane/cleanup.sh --sweep. Exécutez-le depuis l'arbre de travail principal.
• Les lignes WORKTREE_MISSING et BRANCH_MERGED passent par le sweep. Les lignes pour les lanes non fusionnées sont ASK.
• Les travaux de relais encore en cours d'exécution (pas de fichier rc) sont REPORT ONLY ; le chien de garde des lanes les possède.
• Dans une session /lanes, la lane principale intègre ; ne supprimez pas une branche de lane dont le travail n'est pas encore fusionné dans origin/main.

Sans le harnais, les arbres de travail sous .claude/worktrees/ (par exemple de EnterWorktree de Claude Code) suivent les règles git simples ci-dessus.

Phase 3 : Rapport

Utilisez cette structure exactement. Rendez-la scrutable ; le propriétaire la lit à la fin d'une longue session.

## Nettoyage de session

**Déjà propres :** arbre de travail, synchronisation, arbres de travail, branches, stashs, processus, artefacts, suivi, déploiement
(listez uniquement les domaines qui ont réussi)

**Nettoyé**
- Branche `feat/login-form` : fusionnée dans main à a1b2c3d, 0 commits en avance. Supprimée avec `git branch -d` (restauration : `git branch feat/login-form a1b2c3d`).
- `python3 -m http.server 3000` (PID 170308) : démarré par cette session pour prévisualisation, inactif. Arrêté.
- `.next/types` (1,2 Mo) : gitignoré, se régénère à la build.

**Nécessite votre décision**
- Branche `feat/wip` : 1 commit pas dans main (« wip : brouillon analyseur »), dernier commit il y a 2h, tâche liée bd-42 in_progress.
  Reprendre (la garder) ou abandonner (`git branch -D feat/wip`) ?
- `stash@{0}` « Sur main : stash de test sc », vieux de 5j. Appliquer ou supprimer ?

**Signalé uniquement**
- main a 2 commits d'avance sur origin/main (non poussés). Push recommandé.
- Déploiement de production : non vérifié (CLI Vercel non connectée).

**Prochaines actions**
- Exécutez `git worktree list`, attendez-vous uniquement à l'arbre de travail principal.
- Exécutez `git status --short`, attendez-vous à aucune sortie.

Règles pour le rapport :

• Chaque ligne « Nettoyé » indique ce que c'était, sa taille (pour les fichiers et dossiers) et pourquoi c'était sûr. Pour les branches, incluez le SHA de pointe pour qu'elle puisse être restaurée.
• Chaque élément « Nécessite votre décision » donne les faits nécessaires pour décider (âge, nombre de commits, sujets des commits, tâche liée) et deux options concrètes.
• Ne dites jamais qu'un domaine est propre à moins que l'audit ou une commande dans cette session ne l'ait montré. Si une vérification a été sautée (hors ligne, CLI manquante, pas d'autorisation), dites-le sous « Signalé uniquement ».
• Les Prochaines actions incluent toujours au moins une commande de vérification avec sa sortie attendue.

Après que le propriétaire a répondu aux éléments ASK, exécutez exactement ce qu'il a approuvé, relancez la section d'audit pertinente, et signalez le résultat.

Journalisation

Si le dépôt a un dossier de journal de session (SESSION_LOG montre _sessions/ ou similaire), ajoutez une courte entrée de nettoyage : date, ce qui a été nettoyé, ce qui attend le propriétaire. Committez-la uniquement si les règles du projet autorisent la journalisation des sessions ; vérifiez CLAUDE.md ou l'état d'ignorance du dossier (ignored=yes signifie ne pas committer).

Hors du périmètre

Refactorisation, corrections de lint, suppression de code mort et mises à niveau de dépendances. Si vous les remarquez, enregistrez-les comme éléments de backlog (mémoire ou suivi) et mentionnez-les en une ligne. Pousser, tirer et déployer sont également hors du périmètre : recommandez-les, ne les faites pas.