theus-cli-linux-arm64 1.2.1 → 1.3.0

package/vendor/theus-arsenal/skills/investigacion-profunda/SKILL.md

@@ -1,161 +0,0 @@
----
-name: investigacion-profunda
-description: Investigación multi-fuente con los MCP de firecrawl y exa. Busca en la web, sintetiza hallazgos y entrega informes citados con atribución de fuentes. Úsala cuando el usuario quiera una investigación exhaustiva sobre cualquier tema con evidencia y citas.
----
-
-# Investigación profunda
-
-> **Skill propensa a deriva.** Los nombres de herramientas MCP de firecrawl/exa, sus cuotas y la forma de los resultados cambian con el tiempo. Verifica las herramientas MCP configuradas y la documentación vigente de las API antes de prometer cobertura o citar conteos de fuentes en vivo.
-
-Produce informes de investigación exhaustivos y citados a partir de múltiples fuentes web usando las herramientas MCP de firecrawl y exa.
-
-## Cuándo activarla
-
-- El usuario pide investigar un tema en profundidad
-- Análisis competitivo, evaluación tecnológica o dimensionamiento de mercado
-- Due diligence sobre empresas, inversionistas o tecnologías
-- Cualquier pregunta que requiera sintetizar varias fuentes
-- El usuario dice "investiga", "profundiza", "indaga" o "cuál es el estado actual de"
-
-## Requisitos de MCP
-
-Al menos uno de:
-- **firecrawl** — `firecrawl_search`, `firecrawl_scrape`, `firecrawl_crawl`
-- **exa** — `web_search_exa`, `web_search_advanced_exa`, `crawling_exa`
-
-Con ambos juntos se obtiene la mejor cobertura. Configúralos como servidores MCP del CLI. Si ninguno está disponible, usa las herramientas nativas de búsqueda y lectura web del agente como respaldo, ajustando las expectativas de cobertura.
-
-## Flujo de trabajo
-
-### Paso 1: entiende el objetivo
-
-Haz 1-2 preguntas rápidas de aclaración:
-- "¿Cuál es tu objetivo: aprender, tomar una decisión o escribir algo?"
-- "¿Algún ángulo o profundidad específica que te interese?"
-
-Si el usuario dice "solo investígalo", continúa con valores por defecto razonables.
-
-### Paso 2: planifica la investigación
-
-Divide el tema en 3-5 sub-preguntas de investigación. Ejemplo:
-- Tema: "Impacto de la IA en la salud"
-  - ¿Cuáles son las principales aplicaciones de IA en salud hoy?
-  - ¿Qué resultados clínicos se han medido?
-  - ¿Cuáles son los desafíos regulatorios?
-  - ¿Qué empresas lideran este espacio?
-  - ¿Cuál es el tamaño de mercado y su trayectoria de crecimiento?
-
-### Paso 3: ejecuta la búsqueda multi-fuente
-
-Para CADA sub-pregunta, busca con las herramientas MCP disponibles:
-
-**Con firecrawl:**
-```
-firecrawl_search(query: "<palabras clave de la sub-pregunta>", limit: 8)
-```
-
-**Con exa:**
-```
-web_search_exa(query: "<palabras clave de la sub-pregunta>", numResults: 8)
-web_search_advanced_exa(query: "<palabras clave>", numResults: 5, startPublishedDate: "2025-01-01")
-```
-
-**Estrategia de búsqueda:**
-- Usa 2-3 variaciones de palabras clave por sub-pregunta
-- Mezcla consultas generales y enfocadas en noticias
-- Apunta a 15-30 fuentes únicas en total
-- Prioriza: académicas, oficiales, prensa reputada > blogs > foros
-
-### Paso 4: lee a fondo las fuentes clave
-
-Para las URL más prometedoras, obtén el contenido completo:
-
-**Con firecrawl:**
-```
-firecrawl_scrape(url: "<url>")
-```
-
-**Con exa:**
-```
-crawling_exa(url: "<url>", tokensNum: 5000)
-```
-
-Lee 3-5 fuentes clave completas para ganar profundidad. No te apoyes solo en fragmentos de búsqueda.
-
-### Paso 5: sintetiza y redacta el informe
-
-Estructura del informe:
-
-```markdown
-# [Tema]: Informe de investigación
-*Generado: [fecha] | Fuentes: [N] | Confianza: [Alta/Media/Baja]*
-
-## Resumen ejecutivo
-[Vista general de los hallazgos clave en 3-5 oraciones]
-
-## 1. [Primer tema principal]
-[Hallazgos con citas en línea]
-- Punto clave ([Nombre de la fuente](url))
-- Dato de respaldo ([Nombre de la fuente](url))
-
-## 2. [Segundo tema principal]
-...
-
-## 3. [Tercer tema principal]
-...
-
-## Conclusiones clave
-- [Insight accionable 1]
-- [Insight accionable 2]
-- [Insight accionable 3]
-
-## Fuentes
-1. [Título](url) — [resumen de una línea]
-2. ...
-
-## Metodología
-Se ejecutaron [N] consultas en web y noticias. Se analizaron [M] fuentes.
-Sub-preguntas investigadas: [lista]
-```
-
-### Paso 6: entrega
-
-- **Temas cortos**: publica el informe completo en el chat
-- **Informes largos**: publica el resumen ejecutivo + conclusiones clave y guarda el informe completo en un archivo
-
-## Investigación en paralelo con subagentes
-
-Para temas amplios, usa los subagentes del CLI para paralelizar:
-
-```
-Lanza 3 agentes de investigación en paralelo:
-1. Agente 1: investiga las sub-preguntas 1-2
-2. Agente 2: investiga las sub-preguntas 3-4
-3. Agente 3: investiga la sub-pregunta 5 + temas transversales
-```
-
-Cada agente busca, lee fuentes y devuelve hallazgos. La sesión principal sintetiza el informe final.
-
-## Reglas de calidad
-
-1. **Toda afirmación necesita una fuente.** Nada de aseveraciones sin respaldo.
-2. **Contrasta.** Si solo una fuente lo dice, márcalo como no verificado.
-3. **La recencia importa.** Prefiere fuentes de los últimos 12 meses.
-4. **Reconoce las brechas.** Si no encontraste buena información sobre una sub-pregunta, dilo.
-5. **Cero alucinaciones.** Si no lo sabes, di "datos insuficientes".
-6. **Separa hecho de inferencia.** Etiqueta con claridad estimaciones, proyecciones y opiniones.
-
-## Ejemplos
-
-```
-"Investiga el estado actual de la energía de fusión nuclear"
-"Profundiza en Rust vs Go para servicios backend en 2026"
-"Investiga las mejores estrategias para arrancar un SaaS sin inversión"
-"¿Qué está pasando con el mercado inmobiliario de EE. UU. ahora mismo?"
-"Indaga el panorama competitivo de los editores de código con IA"
-```
-
-## Skills relacionadas
-
-- `operaciones-investigacion`
-- `verificacion-factual`

package/vendor/theus-arsenal/skills/keccak256-nodejs/SKILL.md

@@ -1,100 +0,0 @@
----
-name: keccak256-nodejs
-description: Previene bugs de hashing de Ethereum en JavaScript y TypeScript. El sha3-256 de Node es SHA3 de NIST, no Keccak-256 de Ethereum, y rompe silenciosamente selectores, firmas, slots de almacenamiento y derivación de direcciones.
----
-
-# Keccak-256 en Node.js
-
-Ethereum usa Keccak-256, no la variante SHA3 estandarizada por NIST que expone `crypto.createHash('sha3-256')` de Node.
-
-## Cuándo usarla
-
-- Al calcular selectores de función o topics de eventos de Ethereum
-- Al construir helpers de EIP-712, firmas, Merkle o slots de almacenamiento en JS/TS
-- Al revisar cualquier código que hashee datos de Ethereum con el crypto de Node directamente
-
-## Cómo funciona
-
-Los dos algoritmos producen salidas distintas para la misma entrada, y Node no te avisará.
-
-```javascript
-import crypto from 'crypto';
-import { keccak256, toUtf8Bytes } from 'ethers';
-
-const data = 'hola';
-const nistSha3 = crypto.createHash('sha3-256').update(data).digest('hex');
-const keccak = keccak256(toUtf8Bytes(data)).slice(2);
-
-console.log(nistSha3 === keccak); // false
-```
-
-## Ejemplos
-
-### ethers v6
-
-```typescript
-import { keccak256, toUtf8Bytes, solidityPackedKeccak256, id } from 'ethers';
-
-const hash = keccak256(new Uint8Array([0x01, 0x02]));
-const hash2 = keccak256(toUtf8Bytes('hola'));
-const topic = id('Transfer(address,address,uint256)');
-const packed = solidityPackedKeccak256(
-  ['address', 'uint256'],
-  ['0x742d35Cc6634C0532925a3b8D4C9B569890FaC1c', 100n],
-);
-```
-
-### viem
-
-```typescript
-import { keccak256, toBytes } from 'viem';
-
-const hash = keccak256(toBytes('hola'));
-```
-
-### web3.js
-
-```javascript
-const hash = web3.utils.keccak256('hola');
-const packed = web3.utils.soliditySha3(
-  { type: 'address', value: '0x742d35Cc6634C0532925a3b8D4C9B569890FaC1c' },
-  { type: 'uint256', value: '100' },
-);
-```
-
-### Patrones comunes
-
-```typescript
-import { id, keccak256, AbiCoder } from 'ethers';
-
-const selector = id('transfer(address,uint256)').slice(0, 10);
-const typeHash = keccak256(toUtf8Bytes('Transfer(address from,address to,uint256 value)'));
-
-function getMappingSlot(key: string, mappingSlot: number): string {
-  return keccak256(
-    AbiCoder.defaultAbiCoder().encode(['address', 'uint256'], [key, mappingSlot]),
-  );
-}
-```
-
-### Dirección a partir de la clave pública
-
-```typescript
-import { keccak256 } from 'ethers';
-
-function pubkeyToAddress(pubkeyBytes: Uint8Array): string {
-  const hash = keccak256(pubkeyBytes.slice(1));
-  return '0x' + hash.slice(-40);
-}
-```
-
-### Audita tu base de código
-
-```bash
-grep -rn "createHash.*sha3" --include="*.ts" --include="*.js" --exclude-dir=node_modules .
-grep -rn "keccak256" --include="*.ts" --include="*.js" . | grep -v node_modules
-```
-
-## Regla
-
-En contextos de Ethereum, nunca uses `crypto.createHash('sha3-256')`. Usa helpers conscientes de Keccak de `ethers`, `viem`, `web3` u otra implementación explícita de Keccak.

package/vendor/theus-arsenal/skills/libro-decisiones-recursivo/SKILL.md

@@ -1,82 +0,0 @@
----
-name: libro-decisiones-recursivo
-description: Úsala cuando se pidan corridas repetidas (rollouts), procesos de decisión con marcas
-  explícitas, búsqueda de alta dimensión, optimización estocástica, exploración de óptimos locales,
-  comparación de ensambles o razonamiento recursivo con un rastro de evidencia visible.
----
-
-# Libro de decisiones recursivo
-
-Usa esta skill cuando alguien intente forzar un cómputo más profundo mediante corridas repetidas
-(rollouts) o prompting recursivo estilo "recocido". Conserva la parte útil: ensayos repetidos,
-memoria previa, información fresca y marcas explícitas. Elimina la parte insegura: pretender que
-el bucle prueba certeza.
-
-## Contrato del libro
-
-Cada rollout debe registrar:
-
-- id del rollout y marca de tiempo;
-- ganador aceptado previo y lista de vigilancia previa;
-- información fresca ingerida;
-- tamaño del espacio de búsqueda;
-- familias de modelos o heurísticas usadas;
-- conteo de ensayos y conteo efectivo de ensayos;
-- candidatos principales;
-- marcas de decisión;
-- marcas de coherencia contra el libro previo;
-- resultado de la compuerta de promoción.
-
-Prefiere JSONL para libros de solo anexado (append-only) y Markdown para resúmenes legibles por personas.
-
-El estado persistente vive en `~/.theus/arsenal/` (por ejemplo, un libro por proyecto bajo
-`~/.theus/arsenal/libro-decisiones/`).
-
-## Bucle de rollout
-
-1. Carga el libro previo.
-2. Captura la nueva información en el instante cero.
-3. Ejecuta la búsqueda acotada.
-4. Marca cada candidato: aceptar, vigilar, rechazar, decaer vigilancia o requiere repetición.
-5. Compara los ganadores contra los ganadores previos y el último rollout marcado.
-6. Degrada candidatos cuando la deriva, el riesgo de cola, los datos rancios o una repetición fallida
-   invaliden la marca anterior.
-7. Anexa los artefactos antes de resumir.
-
-## Marca de coherencia
-
-Incluye una marca de coherencia compacta:
-
-```text
-El ensamble coincide con el ganador previo: sí
-El recursivo coincide con el ganador previo: no
-Coincidencia con el último rollout: sí
-Promoción en vivo permitida: no
-Motivo: no se satisfacen las compuertas de repetición y frescura
-```
-
-## Reglas de promoción
-
-Para trading, asignación de capital, despliegues a producción, migraciones u operaciones destructivas,
-la confianza recursiva no es aprobación.
-
-Por defecto, usa modo papel (paper), simulacro (dry-run), solo lectura, vista previa o por etapas,
-salvo que la persona apruebe explícitamente la acción en vivo y la compuerta del repo/servicio la soporte.
-
-Promueve solo cuando:
-
-- el candidato supera al ganador aceptado previo en la métrica elegida;
-- pasan las verificaciones de correctitud y repetición;
-- los límites de riesgo son explícitos;
-- la evidencia es duradera;
-- la persona ha aprobado el paso en vivo cuando se requiere.
-
-## Forma del resumen
-
-Encabeza con la decisión, no con el drama:
-
-```text
-Rollout 15 completo. El ganador previo se mantiene, pero la ventaja se deterioró 17%.
-Estado: en vigilancia, no en vivo. Próxima compuerta: 20 repeticiones de llenado con edad de
-libro de órdenes por debajo del umbral.
-```

package/vendor/theus-arsenal/skills/lienzo-planes/SKILL.md

@@ -1,111 +0,0 @@
----
-name: lienzo-planes
-description: Abre planes y artefactos HTML en un lienzo de revisión en el navegador local, donde la persona anota elementos, conversa y aprueba o pide cambios sin salir de la página. Úsala al presentar un plan para revisión, o cuando feedback tipo "mueve esto, cambia aquello" es más fácil de señalar que de escribir.
----
-
-# Lienzo de planes
-
-Bucle de revisión para planes y artefactos visuales: el agente escribe el artefacto, la persona lo revisa en el navegador — anotando el elemento exacto al que se refiere, conversando y emitiendo un veredicto de **Aprobar plan / Pedir cambios** — mientras el agente queda bloqueado en una sola llamada de CLI que devuelve el feedback como JSON.
-
-## Cuándo usarla
-
-- Acabas de escribir un artefacto de plan (`.theus/plans/*.plan.md` desde `/plan`) y necesitas la decisión de CONFIRMAR/aprobar — el veredicto del lienzo reemplaza al "sí/procede" tecleado.
-- La persona debe *señalar* qué cambiar: revisión de diseños, comparativas, informes o cualquier artefacto local `.md` / `.html`.
-- El usuario pide `/lienzo-planes`, una revisión visual o "ábrelo en el navegador".
-
-NO usarla para: revisión de código de diffs (`/revisar-codigo`), aplicaciones web en ejecución ni URLs remotas. El lienzo sirve únicamente archivos de artefactos locales.
-
-## Cómo funciona
-
-Invoca el CLI con `node "${THEUS_PLUGIN_ROOT}/scripts/plan-canvas.js"`. Ejecútalo desde el proyecto que estás revisando; funciona desde cualquier directorio de trabajo. Gestiona un servidor de loopback desacoplado (`127.0.0.1:4517`) compartido por todas las sesiones, indexado por ruta de artefacto — sin ids de sesión que rastrear.
-
-El flujo es un bucle simple de CLI + JSON, así que es agnóstico de modelo y de harness: cualquier agente capaz de ejecutar un comando de shell y leer stdout lo maneja igual. Actívalo como tu harness exponga las skills — p. ej. `/lienzo-planes` en Theus — o ejecuta los comandos del script directamente.
-
-```bash
-# 1. Abre el artefacto en el navegador del usuario (retorna de inmediato)
-node "${THEUS_PLUGIN_ROOT}/scripts/plan-canvas.js" open .theus/plans/funcionalidad.plan.md
-
-# 2. Bloquea hasta que la persona responda. Déjalo corriendo; reintenta si se
-#    interrumpe — el feedback encolado nunca se pierde. Ejecútalo en segundo
-#    plano si tu harness limita el tiempo de los comandos en primer plano.
-node "${THEUS_PLUGIN_ROOT}/scripts/plan-canvas.js" await .theus/plans/funcionalidad.plan.md
-```
-
-`await` imprime JSON cuando la persona actúa:
-
-```json
-{
-  "status": "feedback",
-  "items": [
-    { "kind": "annotation", "text": "Divide esto en dos fases",
-      "anchor": { "selector": "h2:nth-of-type(3)", "tag": "h2", "snippet": "Fase 2: Migración" } },
-    { "kind": "verdict", "verdict": "request-changes" }
-  ]
-}
-```
-
-- `kind: "chat"` — mensaje libre; responde en el lienzo, no en la terminal.
-- `kind: "annotation"` — feedback anclado a un elemento (`anchor.selector` y `anchor.snippet` muestran qué señaló; `anchor.textRange.text` cuando resaltó un pasaje).
-- `kind: "verdict"` — `approve` significa que el plan queda CONFIRMADO: deja de esperar, cierra la sesión y empieza a implementar. `request-changes` significa revisar el artefacto (el lienzo lo recarga en vivo) y continuar el bucle.
-
-**3. Responde en el lienzo** y sigue escuchando — un solo comando hace ambas cosas:
-
-```bash
-node "${THEUS_PLUGIN_ROOT}/scripts/plan-canvas.js" await <archivo> --reply "Dividí la Fase 2 como pediste — échale un vistazo."
-```
-
-**4. Cierra** cuando la revisión concluya: `node "${THEUS_PLUGIN_ROOT}/scripts/plan-canvas.js" end <archivo>`.
-
-## Diagramas (Mermaid)
-
-Cuando parte del plan sea un flujo, una arquitectura, una secuencia, una máquina de estados, un modelo ER o un grafo de dependencias, escríbelo como bloque cercado ` ```mermaid ` en lugar de arte ASCII o un muro de prosa — el lienzo lo renderiza como diagrama con tema, y la persona puede señalarlo. Úsalo cuando una imagen se lee más rápido que un párrafo; omítelo para listas o tablas simples.
-
-````markdown
-```mermaid
-flowchart LR
-  A[Mercado se resuelve] --> B{¿Observadores?}
-  B -->|sí| C[Encola trabajos] --> D[Worker de fan-out]
-```
-````
-
-Los diagramas se renderizan con el tema oscuro de Theus y su paleta de acento. Mermaid se carga en el navegador desde un CDN fijado; si no está disponible (sin conexión), el bloque degrada a mostrar su código fuente, así que la revisión nunca se bloquea. Apunta `THEUS_PLAN_CANVAS_MERMAID_URL` a un espejo local para entornos sin acceso a internet.
-
-## Reglas
-
-- Los artefactos Markdown se renderizan con la plantilla de planes de Theus (incluidos los bloques Mermaid); los artefactos `.html` se renderizan tal cual con la capa de anotación inyectada. Para pautas de autoría de HTML usa las skills `sistema-diseno` y `patrones-frontend`.
-- Para revisar, edita el archivo del artefacto — el lienzo se recarga en vivo al guardar. Nunca vuelvas a ejecutar `open` para refrescar.
-- `{"status": "ended", "endedBy": "user"}` (o `sessionEnded: true` en un lote de feedback) significa que el usuario cerró la revisión: deja de esperar, entrega las novedades restantes en el chat y no la reabras. Un `open` simple sobre esa sesión será rechazado; pasa `--reopen` solo cuando el usuario pida retomarla.
-- Los recursos hermanos (imágenes, CSS) deben estar junto al artefacto y referenciarse con rutas relativas.
-- El servidor es solo loopback y se apaga tras 30 minutos de inactividad (`THEUS_PLAN_CANVAS_IDLE_MS`); `stop` lo detiene explícitamente. El estado vive en `~/.theus/arsenal/plan-canvas/` (`THEUS_PLAN_CANVAS_STATE_DIR`; puerto configurable con `THEUS_PLAN_CANVAS_PORT`).
-
-## Ejemplos
-
-**Flujo de aprobación de plan** — `/plan` escribe `.theus/plans/notificaciones.plan.md` y debe ESPERAR confirmación:
-
-```bash
-node "${THEUS_PLUGIN_ROOT}/scripts/plan-canvas.js" open .theus/plans/notificaciones.plan.md
-node "${THEUS_PLUGIN_ROOT}/scripts/plan-canvas.js" await .theus/plans/notificaciones.plan.md
-# → {"status":"feedback","items":[{"kind":"verdict","verdict":"approve"}]}
-node "${THEUS_PLUGIN_ROOT}/scripts/plan-canvas.js" end .theus/plans/notificaciones.plan.md
-# plan confirmado — empieza la implementación
-```
-
-**Bucle de revisión** — llega feedback, editas el archivo, respondes y sigues escuchando:
-
-```bash
-# await devolvió anotaciones → edita el .plan.md (el lienzo recarga en vivo)
-node "${THEUS_PLUGIN_ROOT}/scripts/plan-canvas.js" await <archivo> --reply "Rehíce la tabla de riesgos."
-# → vuelve a bloquear hasta la siguiente respuesta
-```
-
-## Antipatrones
-
-- Hacer polling con `--timeout-ms` en bucle — existe para tests. Deja corriendo el `await` simple.
-- Reabrir después de un cierre iniciado por el usuario "solo para mostrar" algo.
-- Pegar el plan completo en el chat *y además* abrir un lienzo — elige el lienzo y limita el resumen en la terminal a una línea.
-- Parsear el chat del lienzo desde los archivos de estado — todo lo que necesitas llega vía `await`.
-
-## Skills relacionadas
-
-- `plano-tecnico`
-- `sistema-diseno`

package/vendor/theus-arsenal/skills/limpieza-configuracion/SKILL.md

@@ -1,116 +0,0 @@
----
-name: limpieza-configuracion
-description: Recolección de basura para tu configuración de Theus. Escanea periódicamente ~/.theus (skills, memoria, hooks, permisos, servidores MCP, cachés) en busca de elementos redundantes, obsoletos, huérfanos o de bajo valor, y guía al usuario por una limpieza con confirmación por cada borrado. Úsala cuando el usuario diga "limpia mi configuración", "GC de config", "tengo demasiadas skills", "audita mi setup", "mi .theus está inflado" o pida una revisión periódica de la configuración.
----
-
-# Limpieza de configuración — recolección de basura para tu setup de Theus
-
-Idea tomada de la recolección de basura en runtimes: escanear periódicamente los objetos que ya no se referencian, están duplicados, caducados o aportan poco, y recuperar el espacio. La diferencia crítica: **aquí la recolección exige un humano en el circuito. Nunca borres de forma autónoma.**
-
-## Cuándo activarla
-
-- El usuario pide limpiar, auditar o adelgazar su configuración de Theus
-- El usuario se queja de demasiadas skills, hooks ruidosos o arranques de sesión lentos
-- Toca la revisión periódica (mensual) de la configuración
-- Tras instalar un paquete grande de skills (p. ej. este plugin), para reconciliar solapamientos con el setup existente
-
-NO la actives para: limpiar código fuente de un proyecto (eso es refactorización), borrar el historial de chat, ni desinstalar el CLI.
-
-## Filosofía de diseño
-
-1. **Las configuraciones de solo-añadir gotean.** Skills, archivos de memoria, hooks y entradas de permisos solo se agregan. Sin revisión periódica, se pudren en silencio.
-2. **Las auditorías regulares ganan a las purgas únicas.** Escanea cada ~30 días y propone un lote pequeño de candidatos cada vez.
-3. **Estrategia por canal.** Cada tipo de acumulación (skills, hooks, permisos, ...) tiene sus propias señales de obsolescencia — no apliques una sola regla a todo.
-4. **Primero borrado suave.** Renombrar a `.disabled` > mover a `~/.theus/arsenal/gc_trash/` > borrado real. Mantén siempre una ruta de deshacer.
-5. **Humano en el circuito obligatorio.** Cada candidato recibe su propia confirmación `[s/n/saltar]`. Sin atajo de "sí a todo".
-6. **Lleva un registro.** Cada ejecución de GC añade una entrada a `~/.theus/arsenal/gc_log.md`: qué se tocó, por qué y cómo deshacerlo.
-
-## Canales de escaneo
-
-| # | Canal | Ruta | Señales de obsolescencia / redundancia |
-|---|-------|------|----------------------------------------|
-| 1 | Skills | `~/.theus/skills/*/` | Nombres muy solapados; nunca activadas en transcripciones recientes; dominio ajeno al trabajo real del usuario; SKILL.md roto o vacío |
-| 2 | Memoria | `~/.theus/**/memory/*.md` + su índice | Varias entradas de índice para un mismo tema; contenidos que contradicen entradas más nuevas; fechas ya pasadas; archivos huérfanos ausentes del índice; fragmentos de menos de 100 palabras que deberían fusionarse |
-| 3 | Hooks | `~/.theus/hooks/` + settings | Scripts presentes en disco que ninguna configuración de hooks referencia; versiones viejas superadas por reescrituras |
-| 4 | Permisos | `permissions.allow` en `settings.json` / `settings.local.json` | Entradas duplicadas; entradas específicas ya cubiertas por un comodín (p. ej. `Bash(git push)` cuando `Bash(*)` está permitido); concesiones puntuales de experimentos pasados |
-| 5 | Servidores MCP | `~/.theus.json` o el `.mcp.json` del proyecto | Servidores que no conectan; duplicados funcionales; largo tiempo sin uso |
-| 6 | Recordatorios / trabajos programados | donde el usuario los guarde | One-shots disparados hace más de 30 días; trabajos cuyos scripts objetivo ya no existen |
-| 7 | Historial de proyectos | `~/.theus/projects/*/` | Snapshots de handoff obsoletos; registros de sesión superados por estado más nuevo |
-| 8 | Cachés de runtime | `cache/`, `file-history/`, `logs/`, `shell-snapshots/` | Ordena por tamaño y mtime; propone elementos de más de 30 días y grandes |
-
-## Flujo de trabajo
-
-1. **Escanea** todos los canales (o el subconjunto que nombre el usuario). Recoge candidatos con: ruta, canal, señal que lo marcó, tamaño, última modificación.
-2. **Clasifica** por confianza (roto/huérfano = alta; solo viejo = baja) y preséntalos como tabla numerada. Limita cada ejecución a ~20 candidatos — la GC es periódica, no exhaustiva.
-3. **Confirma uno por uno.** Por cada candidato muestra la evidencia y pregunta `[s/n/saltar]`. El usuario puede parar en cualquier momento.
-4. **Borrado suave de lo confirmado**: prefiere el renombrado a `.disabled` para skills/hooks y el traslado a `gc_trash/<fecha>/` para archivos. Las entradas de permisos viven en JSON (sin comentarios posibles): respalda el archivo de settings, registra cada entrada eliminada literalmente en `gc_log.md` y luego quítala del array `allow` con `jq`. Solo borra en duro cuando el usuario lo pida explícitamente.
-5. **Registra** la ejecución en `~/.theus/arsenal/gc_log.md`: timestamp, elementos actuados, instrucciones de deshacer.
-6. **Reporta**: tamaño recuperado, canales aún saludables, próxima fecha de revisión sugerida.
-
-## Comandos de escaneo de ejemplo
-
-Scripts de hook huérfanos (canal 3) — scripts en disco que ninguna configuración de hooks referencia:
-
-```bash
-for f in ~/.theus/hooks/*; do
-  name=$(basename "$f")
-  grep -rq "$name" ~/.theus/settings.json ~/.theus/settings.local.json 2>/dev/null \
-    || echo "HUERFANO: $f"
-done
-```
-
-Entradas de permisos redundantes (canal 4) — duplicados, y concesiones específicas eclipsadas por un comodín:
-
-```bash
-jq -r '.permissions.allow[]' ~/.theus/settings.local.json | sort | uniq -d
-if jq -e '.permissions.allow | index("Bash(*)")' ~/.theus/settings.local.json >/dev/null; then
-  jq -r '.permissions.allow[]' ~/.theus/settings.local.json \
-    | grep '^Bash(' | grep -vF 'Bash(*)'
-fi
-```
-
-Cachés obsoletas más grandes (canal 8) — `du -k` en vez del `find -printf` exclusivo de GNU, para que funcione también en macOS/BSD:
-
-```bash
-find ~/.theus/file-history ~/.theus/shell-snapshots -type f -mtime +30 \
-  -exec du -k {} + 2>/dev/null | sort -rn | head -20
-```
-
-Borrado suave con ruta de deshacer (captura la fecha una sola vez para que el registro no pueda contradecir al directorio):
-
-```bash
-gc_date=$(date +%Y-%m-%d)
-mkdir -p ~/.theus/arsenal/gc_trash/$gc_date
-mv ~/.theus/skills/skill-muerta ~/.theus/arsenal/gc_trash/$gc_date/
-echo "$(date -Iseconds) movido skills/skill-muerta -> arsenal/gc_trash/$gc_date/ (deshacer: mv de vuelta)" >> ~/.theus/arsenal/gc_log.md
-```
-
-Eliminar una entrada de permiso confirmada como redundante (el JSON no admite comentarios — respalda, registra y luego edita):
-
-```bash
-cp ~/.theus/settings.local.json ~/.theus/settings.local.json.bak
-echo "$(date -Iseconds) eliminada entrada de permiso: Bash(git push) (deshacer: restaurar desde .bak o volver a añadir)" >> ~/.theus/arsenal/gc_log.md
-jq '.permissions.allow -= ["Bash(git push)"]' ~/.theus/settings.local.json.bak \
-  > ~/.theus/settings.local.json
-```
-
-## Antipatrones
-
-- **Aprobación en bloque.** Preguntar "¿borro los 15? [s/n]" derrota el diseño. Un elemento, una decisión.
-- **Borrar en duro a la primera.** Si no hay copia en `gc_trash/` ni renombrado a `.disabled`, se hizo mal.
-- **Tratar "viejo" como "muerto".** Una skill sin tocar 60 días puede ser estacional (temporada de impuestos, revisiones trimestrales). La edad es una señal, no un veredicto — por eso confirma un humano.
-- **Limpiar la memoria por truncado.** Fusionar dos archivos de memoria que se contradicen exige leer ambos y conservar la verdad más nueva, no borrar el más largo.
-- **Tocar algo fuera de `~/.theus`** (o del `.theus/` del proyecto). La GC de configuración nunca se pasea por árboles de código fuente.
-
-## Buenas prácticas
-
-- Ejecútala tras grandes adiciones, no solo por calendario: instalar un paquete de 50 skills es exactamente cuando aparece el solapamiento con las skills existentes.
-- Cuando dos skills se solapan, prefiere desactivar la que tenga la descripción de activación más débil — es la que probablemente nunca se disparaba.
-- La limpieza de permisos es el canal de mayor valor por minuto invertido: las entradas allow redundantes dificultan la revisión de seguridad.
-- Conserva `gc_log.md` para siempre. Es diminuto, y "cuándo desactivé ese hook y por qué" surge más a menudo de lo que parece.
-
-## Skills relacionadas
-
-- `inventario-skills` — audita la *calidad* de las skills; limpieza-configuracion audita su *existencia*. Pasa el inventario sobre lo que sobreviva a la GC.
-- `aprendizaje-continuo-v2` — produce los archivos de memoria que esta skill audita después.
-- `revision-seguridad` — combina bien con el canal de permisos.