thebpandey/session-cleanup

Limpieza de sesión

Auditar primero, eliminar después, y solo tras inspeccionar el objetivo. El objetivo es que el propietario pueda abandonar la sesión sabiendo que nada se está ejecutando, nada se ha perdido y no se ha dejado nada obsoleto. Un residuo pasado por alto es barato; un commit sin subir eliminado no lo es. Ante la duda, un hallazgo va a PREGUNTAR, nunca a LIMPIEZA AUTOMÁTICA.

Funciona en cualquier repositorio git. El harness lanes, beads y las partes de Vercel se activan solo cuando están presentes; en caso contrario, se omiten silenciosamente.

Fase 1: Auditoría (solo lectura)

Ejecuta la auditoría incluida desde el repositorio (cualquier worktree del mismo). Usa el script para tu sistema operativo; la carpeta del skill puede estar en ~/.claude/skills/, ~/.codex/skills/ o ~/.agents/skills/:

# Linux y macOS
bash <directorio-skill>/scripts/audit.sh                 # añadir --no-fetch offline

# Windows (PowerShell 5.1 o 7)
powershell -NoProfile -ExecutionPolicy Bypass -File <directorio-skill>\scripts\audit.ps1   # añadir -NoFetch offline

Ambos imprimen una sección por área (CONTEXTO, ÁRBOL_DE_TRABAJO, SINCRONIZACIÓN, WORKTREES, RAMAS, STASHES, LANES, PROCESOS, ARTEFACTOS, TRACKER, DESPLIEGUE, REGISTRO_SESIÓN). Su única escritura es un simple git fetch (nunca --prune). Nunca lee archivos .env ni imprime entornos de proceso.

Cómo decide "esta sesión" (esto es importante para cada clasificación):

• Procesos: propietario=esta_sesión significa que esta sesión (o algo que ella lanzó) inició el proceso. En Linux, esto se demuestra mediante el CLAUDE_CODE_SESSION_ID heredado, que sobrevive a nohup. macOS y Windows ocultan los entornos de otros procesos, por lo que allí significa "descendiente del proceso de Claude" (CLAUDE_PID); un proceso que fue desvinculado y reasignado se muestra como iniciado_durante_sesión, que es PREGUNTAR a menos que puedas rastrearlo en esta conversación. propietario=arnés_no_matar son los propios servidores MCP y plugins de Claude Code: no tocarlos nunca. otra_sesión_o_usuario es de otra persona.
• Archivos, ramas, stashes: esta_sesión / pre_sesión compara la marca de tiempo con inicio_sesión (la primera marca de tiempo en la transcripción de esta sesión). Las marcas de tiempo son una pista, no una prueba: algo creado durante la ventana de la sesión podría provenir de una sesión paralela. Trata un elemento como de esta sesión solo cuando la marca de tiempo lo indique y puedas rastrearlo en esta conversación (ejecutaste el comando que lo creó). De lo contrario, es PREGUNTAR.

Fuera de Claude Code (por ejemplo, en Codex) no hay CLAUDE_CODE_SESSION_ID ni CLAUDE_PID, por lo que id_sesión es desconocido, todo se etiqueta como pre_sesión, y los procesos se emparejan solo mediante en_repo. Pasa --since <hora ISO> (-Since en Windows) con el inicio de la sesión si lo conoces; de lo contrario, trata los archivos y procesos como PREGUNTAR a menos que puedas rastrearlos hasta un comando en esta conversación.

Luego, completa los vacíos que el script no puede ver, en paralelo cuando sea posible:

1. Tu propio trabajo en segundo plano. Enumera las tareas Bash en segundo plano, Monitores, subagentes y reactivaciones programadas que iniciaste en esta conversación y que aún se están ejecutando. Detén las que hayan finalizado o estén inactivas con la herramienta que las inició (TaskStop, detener Monitor, etc.).
2. Solicitudes de residuos. Escanea la conversación en busca de cualquier cosa que el propietario pidió eliminar más tarde o mantener solo temporalmente (una carpeta de subidas, un flag de depuración, una cuenta de prueba, un archivo temporal). Comprueba si aún existe.
3. Estado del despliegue (solo si DESPLIEGUE muestra una plataforma). Obtén el SHA del commit del último despliegue de producción y compáralo con punta_main. Para Vercel: vercel ls --prod para encontrar el último despliegue de producción, luego vercel inspect <url> (o el MCP / panel de Vercel) para su commit git. Si no puedes obtener el SHA, informa "despliegue: no verificado" con el motivo. Nunca inferir una coincidencia a partir de marcas de tiempo.
4. Cualquier cosa fuera del repositorio que la sesión haya tocado (el worktree de otro repositorio, una instalación global). Repórtalo; no lo modifiques.

Fase 2: Clasificar cada hallazgo

LIMPIEZA AUTOMÁTICA (seguro y recuperable; hazlo, luego repórtalo):

• Ramas locales completamente fusionadas en main (git branch -d, nunca -D), excluyendo main, la rama actual y cualquier rama verificada en un worktree.
• Registros de worktree podables cuya carpeta ya no existe (git worktree prune).
• Worktrees vinculados limpios dentro de este repositorio cuya rama está fusionada en main y no tiene commits por delante (git worktree remove <ruta>, sin --force; luego git branch -d). Si el harness lanes es el propietario, usa el script del harness en su lugar (ver más abajo).
• Carpetas temporales cuya lane o rama ya no existe y que ningún proceso tiene abiertas (manejadores_abiertos=0; vuelve a comprobar con lsof +D <dir> inmediatamente antes de eliminar).
• Procesos con propietario=esta_sesión que puedas rastrear hasta esta conversación y que estén inactivos o ya no sean necesarios (servidores de desarrollo, watchers, navegadores headless). Mata solo por PID (kill <pid> en Linux/macOS, Stop-Process -Id <pid> en Windows).
• Cachés de build obsoletas (.next/types, .next/dev/types) que estén en gitignore. Se regeneran en la próxima compilación.
• Archivos temporales propios de esta sesión en su carpeta de bloc de notas, y basura no rastreada en el repositorio (*.orig, *.rej, logs sueltos) que sea de esta_sesión y rastreable hasta un comando que ejecutaste.

PREGUNTAR (podría perder trabajo, o no es demostrablemente de esta sesión):

• Ramas sin fusionar, o cualquier commit que no esté en main. Una rama marcada PATCHES_YA_EN_main probablemente se fusionó con squash o rebase: dilo, pero aún así pregunta antes de -D.
• Worktrees sucios (archivos_sucios > 0), stashes, coverage/ y test-results/ que puedan ser deseados como evidencia.
• Procesos otra_sesión_o_usuario o iniciado_durante_sesión, y cualquier proceso que no puedas rastrear.
• Cualquier cosa pre_sesión, y cualquier archivo no rastreado que no hayas creado.

SOLO INFORMAR (el propietario actúa, o es informativo):

• Deriva entre main y origin (commits sin subir o por detrás). Recomienda el push o pull; no lo hagas como parte de la limpieza.
• Desajustes de despliegue o estado de despliegue "no verificado".
• Elementos abiertos del tracker (beads en_progreso, tasks.md WIP) sin trabajo activo, y trabajo finalizado cuya tarea aún está abierta. Nombra el elemento y lo que viste.
• Worktrees o carpetas fuera de este repositorio, y ramas upstream_gone que aún tienen commits únicos.

Reglas de seguridad

Estas protegen el trabajo que no se puede recrear. Cada una existe porque el atajo obvio ha destruido trabajo antes.

• Inspeccionar antes de eliminar. Para cada carpeta, lista su contenido y tamaño primero. Para cada rama, muestra git log --oneline main..<rama> primero. Pon esa evidencia en el informe.
• Nunca eliminar commits sin fusionar, worktrees sucios o stashes sin la aprobación explícita del propietario en esta conversación. La aprobación para un elemento no cubre el siguiente.
• Matar procesos solo por PID, después de confirmar propietario=esta_sesión y que lo iniciaste. Nunca pkill, killall, kill -9 en el primer intento, ni matar solo por puerto.
• Nunca uses git stash simple, git reset --hard, git clean -fdx (o cualquier git clean -f), o rm -rf con un comodín. Estos no tienen deshacer. Elimina rutas nombradas de una en una.
• git branch -D, git stash drop y git worktree remove --force se ejecutan solo sobre el único elemento que el propietario aprobó, después de mostrar lo que se perderá (commits, diff stat). Registra el SHA de la punta de la rama en el informe para que pueda restaurarse.
• Nunca leer, imprimir, mover o eliminar archivos .env, claves o credenciales, incluso cuando parezcan basura. Repórtalos solo por ruta.
• Permanecer dentro de este repositorio. Los worktrees de otras aplicaciones, checkouts desvinculados o carpetas /tmp compartidas se informan, no se tocan. Nunca elimines con comodín en /tmp.
• Nunca matar procesos arnés_no_matar ni el propio proceso de Claude.

Cuando el harness lanes está presente

Solo si la sección LANES muestra un directorio de estado. De lo contrario, omitir este bloque.

• Eliminar worktrees de lane, directorios temporales de lane, directorios de trabajos relay y filas de lanes.tsv con el script propio del harness, nunca con rm: bash ~/.claude/skills/lanes/lane/cleanup.sh <dir-lane> <rama> para una lane fusionada, luego bash ~/.claude/skills/lanes/lane/cleanup.sh --sweep. Ejecútalo desde el worktree principal.
• Las filas WORKTREE_FALTANTE y RAMA_FUSIONADA pasan por el sweep. Las filas de lanes no fusionadas son PREGUNTAR.
• Los trabajos relay que aún se ejecutan (sin archivo rc) son SOLO INFORMAR; el watchdog de lanes es su propietario.
• En una sesión /lanes la lane principal se integra; no eliminar una rama de lane cuyo trabajo aún no está fusionado en origin/main.

Sin el harness, los worktrees bajo .claude/worktrees/ (por ejemplo, de EnterWorktree de Claude Code) siguen las reglas simples de git anteriores.

Fase 3: Informe

Usa esta estructura exactamente. Mantenlo escaneable; el propietario lo lee al final de una larga sesión.

## Limpieza de sesión

**Ya limpio:** árbol de trabajo, sincronización, worktrees, ramas, stashes, procesos, artefactos, tracker, despliegue
(lista solo las áreas que pasaron)

**Limpiado**
- Rama `feat/login-form`: fusionada en main en a1b2c3d, 0 commits por delante. Eliminada con `git branch -d` (restaurar: `git branch feat/login-form a1b2c3d`).
- `python3 -m http.server 3000` (PID 170308): iniciado por esta sesión para vista previa, inactivo. Detenido.
- `.next/types` (1.2M): en gitignore, se regenera en la compilación.

**Requiere tu decisión**
- Rama `feat/wip`: 1 commit no en main ("wip: draft parser"), último commit hace 2h, tarea vinculada bd-42 en_progreso.
  Continuar (mantenerla) o abandonar (`git branch -D feat/wip`)?
- `stash@{0}` "En main: sc test stash", hace 5d. ¿Aplicar o eliminar?

**Solo informar**
- main está 2 commits por delante de origin/main (sin subir). Se recomienda push.
- Despliegue de producción: no verificado (vercel CLI no ha iniciado sesión).

**Próximas acciones**
- Ejecuta `git worktree list`, espera solo el worktree principal.
- Ejecuta `git status --short`, espera ninguna salida.

Reglas para el informe:

• Cada línea de "Limpiado" dice qué era, su tamaño (para archivos y carpetas) y por qué era seguro. Para las ramas, incluye el SHA de la punta para que pueda restaurarse.
• Cada elemento de "Requiere tu decisión" proporciona los datos necesarios para decidir (antigüedad, número de commits, asuntos de commits, tarea vinculada) y dos opciones concretas.
• Nunca digas que un área está limpia a menos que la auditoría o un comando en esta sesión lo haya mostrado. Si una comprobación se omitió (sin conexión, CLI faltante, sin permiso), dilo en Solo informar.
• Próximas acciones siempre incluye al menos un comando de verificación con su salida esperada.

Después de que el propietario responda a los elementos PREGUNTAR, lleva a cabo exactamente lo que aprobó, vuelve a ejecutar la sección de auditoría relevante e informa el resultado.

Registro

Si el repositorio tiene una carpeta de registro de sesión (REGISTRO_SESIÓN muestra _sessions/ o similar), añade una entrada de limpieza breve: fecha, qué se limpió, qué está esperando al propietario. Confírmalo solo si las reglas del proyecto permiten confirmar registros de sesión; consulta CLAUDE.md o el estado de ignorado de la carpeta (ignorado=sí significa no confirmar).

Fuera del alcance

Refactorización, correcciones de lint, eliminación de código muerto y actualizaciones de dependencias. Si los notas, regístralos como elementos del backlog (memoria o tracker) y menciónalos en una línea. Hacer push, pull y desplegar también están fuera del alcance: recomiéndalos, no los hagas.