Workspace Cleanup — Auditoría y Limpieza de Entorno
Resumen
Procedimiento para auditar un entorno de agente (Hermes, Claude Code, etc.): medir espacio por componente, identificar dead weight, clasificar por utilidad real, y ejecutar limpieza ordenada por impacto.
Cuándo usar
- Usuario pide "limpiar", "qué ocupa", "haz un resumen del estado", "qué borrar"
- El entorno crece descontroladamente y necesita mantenimiento
- Antes de un deploy o migración, para reducir superficie
- Cuando el usuario nota que algo ocupa demasiado
Flujo de Auditoría (7 pasos)
Paso 1: Mapear estructura
Medir todo en capas:
# Raíz del entorno
du -sh /hermes-home/* | sort -rh
# Workspace de proyectos
du -sh /root/workspace/*/ 2>/dev/null | sort -rh
# Subcomponentes de los grandes
du -sh /root/workspace/GRANDE/*/ 2>/dev/null | sort -rh
Objetivo: Ver qué componentes son los gordos y dónde está el espacio.
Paso 2: Clasificar por categoría
Cada componente se clasifica en una de estas categorías:
| Categoría |
Qué incluye |
Ejemplo |
| Código fuente |
Archivos de código, configs, docs |
src/, README.md, package.json |
| Dependencias |
node_modules/, .venv/, vendor/ |
node_modules/, chromadb-venv/ |
| Datos cache |
Sesiones, logs, audio, modelos |
sessions/, audio_cache/, logs/ |
| Modelos/ML |
ONNX, PyTorch, embeddings |
PINTO_model_zoo/, presidio/ |
| Bases de datos |
SQLite, ChromaDB, state |
state.db, chromadb-data/ |
| Output cron |
Resultados de jobs programados |
cron/output/ |
| Proyectos activos |
Repos que se usan actualmente |
TimeIneco/, GTFSSpain/ |
| Proyectos muertos |
Reos abandonados o de prueba |
AdelaTest01/ |
Paso 3: Evaluar utilidad real
Para cada componente grande, verificar:
- ¿Se referencia en código actual?
grep -rl "nombre" /root/workspace/ProyectoActual/
- ¿Tiene cron asociado?
cat /hermes-home/cron/jobs.json | grep nombre
- ¿Es un proyecto propio o de terceros?
- ¿Los datos se pueden regenerar? (node_modules →
npm install, modelos → descargar de nuevo)
- ¿Hay un plan de mantenimiento? (cron de limpieza, rotación)
Paso 4: Priorizar por impacto
| Impacto |
Criterio |
Acción |
| 🔴 Alto |
>100 MB y no esencial |
Borrar o comprimir |
| 🟠 Medio |
50-100 MB y regenerable |
Borrar deps, regenerar después |
| 🟡 Bajo |
10-50 MB y útil |
Mantener, revisar periódicamente |
| 🟢 Mínimo |
<10 MB |
No tocar |
Paso 5: Presentar informe al usuario
Formato del informe:
## 🧹 Estado del Workspace
### Componentes principales
| Componente | Tamaño | Categoría | Utilidad |
|---|---|---|---|
| state.db | 1.3 GB | Base de datos | 🔴 CRÍTICO - investigar |
| sessions/ | 960 MB | Cache | 3,154 archivos >7 días |
| Adela/ | 1.79 GB | Código + deps | node_modules regenerables |
| repos/ | 592 MB | Modelos terceros | PINTO y presidio no referenciados |
### Propuesta de limpieza
1. 🔴 Adela node_modules → 1.79 GB → 104 MB (código intacto)
2. 🟠 repos/ PINTO + presidio → 592 MB → 25 MB (no referenciados)
3. 🟠 Sesiones >7 días → 960 MB → 232 MB (3,308 archivos)
4. 🟡 Audio cache duplicados → 11 MB → 1.4 MB
5. 🟡 Cron output antiguos → 7.6 MB → 2.5 MB
Total ahorrado: ~2.5 GB
Paso 6: Ejecutar limpieza
Orden de ejecución:
- Dependencias regenerables primero (
node_modules, .venv)
- Modelos/ML no referenciados (buscar referencias antes de borrar)
- Sesiones caché antiguas (>7 días para JSONL, >14 días para audio)
- Output cron antiguos (>7 días)
- Datos duplicados (.ogg + .mp3 del mismo timestamp)
Regla: NUNCA borrar state.db sin investigar primero. Es la base de datos interna del agente.
Paso 6.5: Verificar post-limpieza
# Medir delta
du -sh /hermes-home/
du -sh /root/workspace/
du -sh /root/workspace/*/ | sort -rh | head -10
Paso 7: Configurar mantenimiento preventivo
Para evitar que el problema se repita:
| Componente |
Frecuencia |
Acción |
| Sesiones JSONL |
Semanal |
Borrar >7 días |
| Audio cache |
Mensual |
Borrar >14 días |
| Cron output |
Mensual |
Borrar >7 días |
| node_modules |
Al cambiar código |
Regenerar con npm install |
| state.db |
Trimestral |
Investigar crecimiento anómalo |
Ejemplos reales
Caso: Workspace de Hermes (23 junio 2026)
- Antes: 3.69 GB workspace + 3.0 GB /hermes-home
- Después: 1.5 GB workspace + 3.0 GB /hermes-home
- Ahorro: 2.19 GB workspace
- Método: Borrar node_modules de Adela (1.69 GB), repos no referenciados (567 MB), sesiones antiguas (728 MB)
- state.db: 1.3 GB sin tocar (investigar en otra sesión)
Pitfalls
- No borrar state.db sin investigar — Es la base de datos interna del agente. Si creció a 1.3 GB, puede ser normal (muchas sesiones) o puede indicar un problema. Investigar las tablas antes de tocar.
- Verificar referencias antes de borrar — Un modelo o repo puede parecer inútil pero estar referenciado en un cron o script. Siempre
grep -rl antes de borrar.
- Los node_modules son regenerables — Si un proyecto tiene código fuente intacto, borrar node_modules es siempre seguro. El usuario puede reinstalar con
npm install o pip install.
- Sesiones JSONL vs JSON — Los archivos
.jsonl son el formato compacto de sesiones. Los .json grandes (2+ MB) son duplicados o formatos antiguos. Priorizar borrar los .json.
- Audio cache duplicado — El TTS genera tanto
.ogg como .mp3 del mismo contenido. Borrar uno de los dos (el más pesado) es seguro.
- Cron output son directorios — La estructura de
/hermes-home/cron/output/ usa directorios con hash como nombre, no archivos sueltos. Contar directorios, no archivos.
- Metadata de proyectos — Archivos como
metadata/conjuntos-datos.json en GTFSSpain pueden ser usados por crons. Verificar el cron antes de borrar.
1---2name: workspace-cleanup3description: Procedimiento sistemático para auditar y limpiar el workspace de un agente AI — identificar espacio ocupado, clasificar por utilidad, eliminar lo innecesario.4---56# Workspace Cleanup — Auditoría y Limpieza de Entorno78## Resumen910Procedimiento para auditar un entorno de agente (Hermes, Claude Code, etc.): medir espacio por componente, identificar dead weight, clasificar por utilidad real, y ejecutar limpieza ordenada por impacto.1112## Cuándo usar1314- Usuario pide "limpiar", "qué ocupa", "haz un resumen del estado", "qué borrar"15- El entorno crece descontroladamente y necesita mantenimiento16- Antes de un deploy o migración, para reducir superficie17- Cuando el usuario nota que algo ocupa demasiado1819## Flujo de Auditoría (7 pasos)2021### Paso 1: Mapear estructura2223Medir todo en capas:2425```bash26# Raíz del entorno27du -sh /hermes-home/* | sort -rh2829# Workspace de proyectos30du -sh /root/workspace/*/ 2>/dev/null | sort -rh3132# Subcomponentes de los grandes33du -sh /root/workspace/GRANDE/*/ 2>/dev/null | sort -rh34```3536**Objetivo:** Ver qué componentes son los gordos y dónde está el espacio.3738### Paso 2: Clasificar por categoría3940Cada componente se clasifica en una de estas categorías:4142| Categoría | Qué incluye | Ejemplo |43|-----------|-------------|---------|44| **Código fuente** | Archivos de código, configs, docs | `src/`, `README.md`, `package.json` |45| **Dependencias** | `node_modules/`, `.venv/`, `vendor/` | `node_modules/`, `chromadb-venv/` |46| **Datos cache** | Sesiones, logs, audio, modelos | `sessions/`, `audio_cache/`, `logs/` |47| **Modelos/ML** | ONNX, PyTorch, embeddings | `PINTO_model_zoo/`, `presidio/` |48| **Bases de datos** | SQLite, ChromaDB, state | `state.db`, `chromadb-data/` |49| **Output cron** | Resultados de jobs programados | `cron/output/` |50| **Proyectos activos** | Repos que se usan actualmente | `TimeIneco/`, `GTFSSpain/` |51| **Proyectos muertos** | Reos abandonados o de prueba | `AdelaTest01/` |5253### Paso 3: Evaluar utilidad real5455Para cada componente grande, verificar:56571. **¿Se referencia en código actual?** `grep -rl "nombre" /root/workspace/ProyectoActual/`582. **¿Tiene cron asociado?** `cat /hermes-home/cron/jobs.json | grep nombre`593. **¿Es un proyecto propio o de terceros?**604. **¿Los datos se pueden regenerar?** (node_modules → `npm install`, modelos → descargar de nuevo)615. **¿Hay un plan de mantenimiento?** (cron de limpieza, rotación)6263### Paso 4: Priorizar por impacto6465| Impacto | Criterio | Acción |66|---------|----------|--------|67| **🔴 Alto** | >100 MB y no esencial | Borrar o comprimir |68| **🟠 Medio** | 50-100 MB y regenerable | Borrar deps, regenerar después |69| **🟡 Bajo** | 10-50 MB y útil | Mantener, revisar periódicamente |70| **🟢 Mínimo** | <10 MB | No tocar |7172### Paso 5: Presentar informe al usuario7374Formato del informe:7576```77## 🧹 Estado del Workspace7879### Componentes principales80| Componente | Tamaño | Categoría | Utilidad |81|---|---|---|---|82| state.db | 1.3 GB | Base de datos | 🔴 CRÍTICO - investigar |83| sessions/ | 960 MB | Cache | 3,154 archivos >7 días |84| Adela/ | 1.79 GB | Código + deps | node_modules regenerables |85| repos/ | 592 MB | Modelos terceros | PINTO y presidio no referenciados |8687### Propuesta de limpieza881. 🔴 Adela node_modules → 1.79 GB → 104 MB (código intacto)892. 🟠 repos/ PINTO + presidio → 592 MB → 25 MB (no referenciados)903. 🟠 Sesiones >7 días → 960 MB → 232 MB (3,308 archivos)914. 🟡 Audio cache duplicados → 11 MB → 1.4 MB925. 🟡 Cron output antiguos → 7.6 MB → 2.5 MB9394Total ahorrado: ~2.5 GB95```9697### Paso 6: Ejecutar limpieza9899Orden de ejecución:1001011. **Dependencias regenerables primero** (`node_modules`, `.venv`)1022. **Modelos/ML no referenciados** (buscar referencias antes de borrar)1033. **Sesiones caché antiguas** (>7 días para JSONL, >14 días para audio)1044. **Output cron antiguos** (>7 días)1055. **Datos duplicados** (.ogg + .mp3 del mismo timestamp)106107**Regla:** NUNCA borrar state.db sin investigar primero. Es la base de datos interna del agente.108109### Paso 6.5: Verificar post-limpieza110111```bash112# Medir delta113du -sh /hermes-home/114du -sh /root/workspace/115du -sh /root/workspace/*/ | sort -rh | head -10116```117118### Paso 7: Configurar mantenimiento preventivo119120Para evitar que el problema se repita:121122| Componente | Frecuencia | Acción |123|------------|------------|--------|124| Sesiones JSONL | Semanal | Borrar >7 días |125| Audio cache | Mensual | Borrar >14 días |126| Cron output | Mensual | Borrar >7 días |127| node_modules | Al cambiar código | Regenerar con `npm install` |128| state.db | Trimestral | Investigar crecimiento anómalo |129130## Ejemplos reales131132### Caso: Workspace de Hermes (23 junio 2026)133134- **Antes:** 3.69 GB workspace + 3.0 GB /hermes-home135- **Después:** 1.5 GB workspace + 3.0 GB /hermes-home136- **Ahorro:** 2.19 GB workspace137- **Método:** Borrar node_modules de Adela (1.69 GB), repos no referenciados (567 MB), sesiones antiguas (728 MB)138- **state.db:** 1.3 GB sin tocar (investigar en otra sesión)139140## Pitfalls141142- **No borrar state.db sin investigar** — Es la base de datos interna del agente. Si creció a 1.3 GB, puede ser normal (muchas sesiones) o puede indicar un problema. Investigar las tablas antes de tocar.143- **Verificar referencias antes de borrar** — Un modelo o repo puede parecer inútil pero estar referenciado en un cron o script. Siempre `grep -rl` antes de borrar.144- **Los node_modules son regenerables** — Si un proyecto tiene código fuente intacto, borrar node_modules es siempre seguro. El usuario puede reinstalar con `npm install` o `pip install`.145- **Sesiones JSONL vs JSON** — Los archivos `.jsonl` son el formato compacto de sesiones. Los `.json` grandes (2+ MB) son duplicados o formatos antiguos. Priorizar borrar los `.json`.146- **Audio cache duplicado** — El TTS genera tanto `.ogg` como `.mp3` del mismo contenido. Borrar uno de los dos (el más pesado) es seguro.147- **Cron output son directorios** — La estructura de `/hermes-home/cron/output/` usa directorios con hash como nombre, no archivos sueltos. Contar directorios, no archivos.148- **Metadata de proyectos** — Archivos como `metadata/conjuntos-datos.json` en GTFSSpain pueden ser usados por crons. Verificar el cron antes de borrar.
ntizar