theus-cli-linux-x64 1.2.1 → 1.3.0

package/vendor/theus-arsenal/commands/plan.md

@@ -1,198 +0,0 @@
----
-description: "Reformula los requisitos, evalúa riesgos y crea un plan de implementación paso a paso. ESPERA la CONFIRMACIÓN del usuario antes de tocar cualquier código."
-argument-hint: "[descripción de la funcionalidad | ruta/a/*.prd.md]"
----
-
-# Comando Plan
-
-Este comando crea un plan de implementación integral antes de escribir cualquier código. Acepta tanto requisitos en texto libre como un archivo PRD en markdown.
-
-Ejecuta en línea por defecto. No invoques la herramienta Task ni ningún subagente por defecto. Esto mantiene `/plan` usable en instalaciones del plugin que incluyen comandos sin archivos de agentes.
-
-## Qué hace este comando
-
-1. **Reformular requisitos** - Aclarar qué hay que construir
-2. **Identificar riesgos** - Sacar a la superficie posibles problemas y bloqueos
-3. **Crear plan por pasos** - Descomponer la implementación en fases
-4. **Esperar confirmación** - DEBE recibir la aprobación del usuario antes de continuar
-
-## Cuándo usarlo
-
-Usa `/plan` cuando:
-- Empieces una funcionalidad nueva
-- Hagas cambios arquitectónicos significativos
-- Trabajes en un refactor complejo
-- Se vayan a afectar múltiples archivos/componentes
-- Los requisitos sean poco claros o ambiguos
-
-## Cómo funciona
-
-El asistente:
-
-1. **Analiza la petición** y reformula los requisitos en términos claros
-2. **Fundamenta el plan** en patrones relevantes del código cuando el repositorio está disponible
-3. **Descompone en fases** con pasos específicos y accionables
-4. **Identifica dependencias** entre componentes
-5. **Evalúa riesgos** y posibles bloqueos
-6. **Estima la complejidad** (Alta/Media/Baja)
-7. **Presenta el plan** y ESPERA tu confirmación explícita
-
-## Modos de entrada
-
-| Entrada | Modo | Comportamiento |
-|---|---|---|
-| `ruta/a/nombre.prd.md` | Modo artefacto PRD | Lee el PRD, elige el siguiente hito de entrega o fase de implementación pendiente y escribe `.theus/plans/{nombre}.plan.md` |
-| Cualquier otra ruta markdown | Modo referencia | Lee el archivo como contexto y produce un plan en línea |
-| Texto libre | Modo conversacional | Produce un plan en línea |
-| Entrada vacía | Modo aclaración | Pregunta qué se debe planificar |
-
-En modo artefacto PRD, crea `.theus/plans/` si es necesario. Si el PRD contiene una tabla de `Hitos de entrega`, actualiza solo la fila seleccionada de `pendiente` a `en-progreso` y coloca en su celda `Plan` la ruta del plan generado.
-
-## Fundamentación en patrones
-
-Antes de escribir el plan, busca en el código las convenciones que la implementación debe imitar. Captura el mejor ejemplo de cada categoría relevante con referencias a archivos:
-
-| Categoría | Qué capturar |
-|---|---|
-| Nomenclatura | Nombres de archivos, funciones, tipos, comandos o scripts en el área afectada |
-| Manejo de errores | Cómo se lanzan, retornan, registran o manejan con gracia los fallos |
-| Logging | Niveles, formato y qué se registra |
-| Acceso a datos | Patrones de repositorio, servicio, consultas o sistema de archivos |
-| Tests | Ubicación de los archivos de test, framework, fixtures y estilo de aserciones |
-
-Si no existe código similar, dilo explícitamente. No inventes un patrón.
-
-## Salida de artefacto PRD
-
-Cuando se invoca con un archivo `.prd.md`, escribe el plan en `.theus/plans/{nombre-en-kebab-case}.plan.md` con esta estructura:
-
-````markdown
-# Plan: {Nombre de la funcionalidad}
-
-**PRD de origen**: {ruta}
-**Hito seleccionado**: {nombre del hito o fase}
-**Complejidad**: {Pequeña | Media | Grande}
-
-## Resumen
-{2-3 frases}
-
-## Patrones a imitar
-| Categoría | Fuente | Patrón |
-|---|---|---|
-| Nomenclatura | `ruta:línea` | {descripción corta} |
-| Errores | `ruta:línea` | {descripción corta} |
-| Tests | `ruta:línea` | {descripción corta} |
-
-## Archivos a cambiar
-| Archivo | Acción | Por qué |
-|---|---|---|
-| `ruta` | CREAR / ACTUALIZAR / ELIMINAR | {motivo} |
-
-## Tareas
-### Tarea 1: {nombre}
-- **Acción**: {qué hacer}
-- **Imitar**: {patrón a seguir}
-- **Validar**: {comando que demuestra la corrección}
-
-## Validación
-```bash
-{comandos de validación específicos del proyecto}
-```
-
-## Riesgos
-| Riesgo | Probabilidad | Mitigación |
-|---|---|---|
-
-## Aceptación
-- [ ] Todas las tareas completas
-- [ ] La validación pasa
-- [ ] Patrones imitados, no reinventados
-````
-
-Tras escribir el artefacto, reporta su ruta y ESPERA la confirmación antes de escribir código.
-
-## Ejemplo de uso
-
-```
-Usuario: /plan Necesito añadir notificaciones en tiempo real cuando los mercados se resuelvan
-
-Asistente:
-# Plan de implementación: Notificaciones en tiempo real de resolución de mercados
-
-## Reformulación de requisitos
-- Enviar notificaciones a los usuarios cuando se resuelvan los mercados que siguen
-- Soportar múltiples canales de notificación (in-app, email, webhook)
-- Garantizar la entrega confiable de las notificaciones
-- Incluir el resultado del mercado y el resultado de la posición del usuario
-
-## Fases de implementación
-
-### Fase 1: Esquema de base de datos
-- Añadir tabla notifications con columnas: id, user_id, market_id, type, status, created_at
-- Añadir tabla user_notification_preferences para preferencias de canal
-- Crear índices sobre user_id y market_id para rendimiento
-
-### Fase 2: Servicio de notificaciones
-- Crear el servicio de notificaciones en lib/notifications.ts
-- Implementar la cola de notificaciones con BullMQ/Redis
-- Añadir lógica de reintentos para entregas fallidas
-- Crear plantillas de notificación
-
-### Fase 3: Puntos de integración
-- Engancharse a la lógica de resolución de mercados (cuando el estado cambia a "resolved")
-- Consultar todos los usuarios con posiciones en el mercado
-- Encolar notificaciones para cada usuario
-
-### Fase 4: Componentes de frontend
-- Crear el componente NotificationBell en la cabecera
-- Añadir el modal NotificationList
-- Implementar actualizaciones en tiempo real vía suscripciones de Supabase
-- Añadir página de preferencias de notificación
-
-## Dependencias
-- Redis (para la cola)
-- Servicio de email (SendGrid/Resend)
-- Suscripciones en tiempo real de Supabase
-
-## Riesgos
-- ALTO: Entregabilidad del email (requiere SPF/DKIM)
-- MEDIO: Rendimiento con más de 1000 usuarios por mercado
-- MEDIO: Spam de notificaciones si los mercados se resuelven con frecuencia
-- BAJO: Sobrecarga de las suscripciones en tiempo real
-
-## Complejidad estimada: MEDIA
-- Backend: 4-6 horas
-- Frontend: 3-4 horas
-- Testing: 2-3 horas
-- Total: 9-13 horas
-
-**ESPERANDO CONFIRMACIÓN**: ¿Procedo con este plan? (sí/no/modificar)
-```
-
-## Notas importantes
-
-**CRÍTICO**: Este comando **NO** escribirá código hasta que confirmes explícitamente el plan con "sí", "procede" o una respuesta afirmativa similar.
-
-Si quieres cambios, responde con:
-- "modificar: [tus cambios]"
-- "otro enfoque: [alternativa]"
-- "salta la fase 2 y haz primero la fase 3"
-
-## Integración con otros comandos
-
-Después de planificar:
-- Usa la skill `flujo-tdd` para implementar con desarrollo guiado por tests
-- Usa `/arreglar-build` si aparecen errores de build
-- Usa el agente `revisor-codigo` para revisar la implementación completada
-- Usa `/pr` para abrir un pull request
-
-> **¿Necesitas primero los requisitos?** Usa `/plan-prd` para un PRD ligero en `.theus/prds/{nombre}.prd.md`.
-
-## Agente planificador opcional
-
-Theus también provee un agente `planificador` para instalaciones manuales que incluyan archivos de agentes. Úsalo solo cuando el runtime local ya exponga ese subagente y el usuario pida explícitamente delegar la planificación.
-
-Si el subagente `planificador` no está disponible, continúa planificando en línea en lugar de mostrar un error de "agente no encontrado".
-
-Para instalaciones manuales, el archivo fuente vive en:
-`agents/planificador.md`

package/vendor/theus-arsenal/commands/podar.md

@@ -1,31 +0,0 @@
----
-description: Elimina los instintos pendientes con más de 30 días que nunca fueron promovidos.
-argument-hint: "[--max-age <días>] [--dry-run]"
----
-
-# Podar instintos pendientes
-
-Elimina los instintos pendientes caducados que se generaron automáticamente pero nunca fueron revisados ni promovidos.
-
-## Implementación
-
-Ejecuta la CLI de instintos usando la raíz del plugin. El motor de Theus inyecta `THEUS_PLUGIN_ROOT` al cargar el comando; fuera de ese contexto (ejecución manual), resuélvela con `scripts/lib/resolve-theus-root.js` del arsenal, que centraliza el orden de búsqueda (variable de entorno → instalación estándar bajo `~/.theus/plugins` → fallback a `~/.theus`) y evita divergencias cuando conviven varias instalaciones.
-
-```bash
-python3 "${THEUS_PLUGIN_ROOT}/skills/aprendizaje-continuo-v2/scripts/instinct-cli.py" prune $ARGUMENTS
-```
-
-Si el script no está disponible en la instalación, realiza la poda manualmente: lista los instintos pendientes en `~/.theus/arsenal/instincts/` (y en `~/.theus/arsenal/projects/<id-proyecto>/instincts/` para el proyecto actual), identifica los que superen el umbral de antigüedad sin haber sido promovidos y elimínalos, informando cuántos se borraron.
-
-## Uso
-
-```
-/podar                    # Elimina instintos pendientes con más de 30 días
-/podar --max-age 60       # Umbral de antigüedad personalizado (días)
-/podar --dry-run          # Vista previa sin eliminar nada
-```
-
-## Relacionados
-
-- Comando: `/instintos-estado` — ver los instintos actuales antes de podar
-- Skill: `skills/aprendizaje-continuo-v2/`

package/vendor/theus-arsenal/commands/pr.md

@@ -1,181 +0,0 @@
----
-description: "Crea un PR de GitHub desde la rama actual con commits sin subir — descubre plantillas, analiza los cambios y hace push."
-argument-hint: "[rama-base] (por defecto: main)"
----
-
-# Crear Pull Request
-
-**Entrada**: `$ARGUMENTS` — opcional, puede contener el nombre de una rama base y/o flags (p. ej., `--draft`).
-
-**Parsear `$ARGUMENTS`**:
-- Extrae los flags reconocidos (`--draft`)
-- Trata el texto restante que no sea flag como el nombre de la rama base
-- Si no se especifica, la rama base por defecto es `main`
-
----
-
-## Fase 1 — VALIDAR
-
-Verifica las precondiciones:
-
-```bash
-git branch --show-current
-git status --short
-git log origin/<base>..HEAD --oneline
-```
-
-| Verificación | Condición | Acción si falla |
-|---|---|---|
-| No estar en la rama base | Rama actual ≠ base | Detener: "Cámbiate primero a una rama de funcionalidad." |
-| Directorio de trabajo limpio | Sin cambios sin commitear | Advertir: "Tienes cambios sin commitear. Haz commit o stash primero." |
-| Hay commits por delante | `git log origin/<base>..HEAD` no vacío | Detener: "No hay commits por delante de `<base>`. Nada que llevar a PR." |
-| No existe un PR previo | `gh pr list --head <rama> --json number` está vacío | Detener: "Ya existe un PR: #<número>. Usa `gh pr view <número> --web` para abrirlo." |
-
-Si todas las verificaciones pasan, continúa.
-
----
-
-## Fase 2 — DESCUBRIR
-
-### Plantilla de PR
-
-Busca la plantilla de PR en este orden:
-
-1. Directorio `.github/PULL_REQUEST_TEMPLATE/` — si existe, lista los archivos y deja que el usuario elija (o usa `default.md`)
-2. `.github/PULL_REQUEST_TEMPLATE.md`
-3. `.github/pull_request_template.md`
-4. `docs/pull_request_template.md`
-
-Si la encuentras, léela y usa su estructura para el cuerpo del PR.
-
-### Análisis de commits
-
-```bash
-git log origin/<base>..HEAD --format="%h %s" --reverse
-```
-
-Analiza los commits para determinar:
-- **Título del PR**: usa el formato de conventional commits con prefijo de tipo — `feat: ...`, `fix: ...`, etc.
-  - Si hay varios tipos, usa el dominante
-  - Si hay un solo commit, usa su mensaje tal cual
-- **Resumen de cambios**: agrupa los commits por tipo/área
-
-### Análisis de archivos
-
-```bash
-git diff origin/<base>..HEAD --stat
-git diff origin/<base>..HEAD --name-only
-```
-
-Categoriza los archivos cambiados: fuente, tests, docs, configuración, migraciones.
-
-### Artefactos de planificación
-
-Busca artefactos relacionados producidos por `/plan-prd` o `/plan`:
-- `.theus/prds/` — PRDs de los que este PR implementa un hito
-- `.theus/plans/` — Planes ejecutados por este PR
-
-Referéncialos en el cuerpo del PR si existen.
-
----
-
-## Fase 3 — PUSH
-
-```bash
-git push -u origin HEAD
-```
-
-Si el push falla por divergencia:
-```bash
-git fetch origin
-git rebase origin/<base>
-git push -u origin HEAD
-```
-
-Si el rebase produce conflictos, detente e informa al usuario.
-
----
-
-## Fase 4 — CREAR
-
-### Con plantilla
-
-Si se encontró una plantilla de PR en la Fase 2, completa cada sección usando el análisis de commits y archivos. Conserva todas las secciones de la plantilla — deja las secciones como "N/A" si no aplican, en lugar de eliminarlas.
-
-### Sin plantilla
-
-Usa este formato por defecto:
-
-```markdown
-## Resumen
-
-<descripción de 1-2 frases de qué hace este PR y por qué>
-
-## Cambios
-
-<lista con viñetas de los cambios agrupados por área>
-
-## Archivos cambiados
-
-<tabla o lista de archivos cambiados con el tipo de cambio: Añadido/Modificado/Eliminado>
-
-## Pruebas
-
-<descripción de cómo se probaron los cambios, o "Requiere pruebas">
-
-## Issues relacionados
-
-<issues enlazados con Closes/Fixes/Relates to #N, o "Ninguno">
-```
-
-### Crear el PR
-
-```bash
-gh pr create \
-  --title "<título del PR>" \
-  --base <rama-base> \
-  --body "<cuerpo del PR>"
-  # Añade --draft si el flag --draft se parseó de $ARGUMENTS
-```
-
----
-
-## Fase 5 — VERIFICAR
-
-```bash
-gh pr view --json number,url,title,state,baseRefName,headRefName,additions,deletions,changedFiles
-gh pr checks --json name,status,conclusion 2>/dev/null || true
-```
-
----
-
-## Fase 6 — SALIDA
-
-Reporta al usuario:
-
-```
-PR #<número>: <título>
-URL: <url>
-Rama: <head> → <base>
-Cambios: +<adiciones> -<eliminaciones> en <archivosCambiados> archivos
-
-Checks de CI: <resumen de estado, o "pendiente", o "sin configurar">
-
-Artefactos referenciados:
-  - <PRDs/planes enlazados en el cuerpo del PR>
-
-Siguientes pasos:
-  - gh pr view <número> --web   → abrir en el navegador
-  - /revisar-pr <número>        → revisar el PR
-  - gh pr merge <número>        → hacer merge cuando esté listo
-```
-
----
-
-## Casos límite
-
-- **Sin CLI `gh`**: detente con: "Se requiere el CLI de GitHub (`gh`). Instálalo: <https://cli.github.com/>"
-- **Sin autenticar**: detente con: "Ejecuta primero `gh auth login`."
-- **Se necesita force push**: si el remoto divergió y se hizo rebase, usa `git push --force-with-lease` (nunca `--force`).
-- **Múltiples plantillas de PR**: si `.github/PULL_REQUEST_TEMPLATE/` tiene varios archivos, lístalos y pide al usuario que elija.
-- **PR grande (>20 archivos)**: advierte sobre el tamaño del PR. Sugiere dividirlo si los cambios son separables lógicamente.

package/vendor/theus-arsenal/commands/promover.md

@@ -1,41 +0,0 @@
----
-description: Promueve instintos del ámbito de proyecto al ámbito global.
-argument-hint: "[id-instinto] [--force] [--dry-run]"
----
-
-# Comando Promover
-
-Promueve instintos del ámbito de proyecto al ámbito global en `aprendizaje-continuo-v2`.
-
-## Implementación
-
-Ejecuta la CLI de instintos usando la raíz del plugin. El motor de Theus inyecta `THEUS_PLUGIN_ROOT` al cargar el comando; fuera de ese contexto (ejecución manual), resuélvela con `scripts/lib/resolve-theus-root.js` del arsenal, que centraliza el orden de búsqueda (variable de entorno → instalación estándar bajo `~/.theus/plugins` → fallback a `~/.theus`).
-
-```bash
-python3 "${THEUS_PLUGIN_ROOT}/skills/aprendizaje-continuo-v2/scripts/instinct-cli.py" promote [id-instinto] [--force] [--dry-run]
-```
-
-Si el script no está disponible en la instalación, realiza el mismo proceso manualmente siguiendo los pasos de "Qué hacer".
-
-## Uso
-
-```
-/promover                      # Detecta automáticamente candidatos a promoción
-/promover --dry-run            # Previsualiza los candidatos sin promover nada
-/promover --force              # Promueve todos los candidatos calificados sin preguntar
-/promover grep-before-edit     # Promueve un instinto concreto del proyecto actual
-```
-
-## Qué hacer
-
-1. Detectar el proyecto actual
-2. Si se indica `id-instinto`, promover solo ese instinto (si existe en el proyecto actual)
-3. En caso contrario, buscar candidatos entre proyectos que:
-   - Aparezcan en al menos 2 proyectos
-   - Superen el umbral de confianza
-4. Escribir los instintos promovidos en `~/.theus/arsenal/instincts/` con `scope: global`
-
-## Relacionados
-
-- `/instintos-estado` — ver instintos de proyecto y globales
-- `/proyectos` — registro de proyectos y sus contadores

package/vendor/theus-arsenal/commands/proyectos.md

@@ -1,33 +0,0 @@
----
-description: Lista los proyectos conocidos y sus estadísticas de instintos.
----
-
-# Comando Proyectos
-
-Lista las entradas del registro de proyectos y los contadores de instintos y observaciones por proyecto de `aprendizaje-continuo-v2`.
-
-## Implementación
-
-Ejecuta la CLI de instintos usando la raíz del plugin. El motor de Theus inyecta `THEUS_PLUGIN_ROOT` al cargar el comando; fuera de ese contexto (ejecución manual), resuélvela con `scripts/lib/resolve-theus-root.js` del arsenal, que centraliza el orden de búsqueda (variable de entorno → instalación estándar bajo `~/.theus/plugins` → fallback a `~/.theus`).
-
-```bash
-python3 "${THEUS_PLUGIN_ROOT}/skills/aprendizaje-continuo-v2/scripts/instinct-cli.py" projects
-```
-
-Si el script no está disponible en la instalación, realiza el mismo proceso manualmente siguiendo los pasos de "Qué hacer".
-
-## Uso
-
-```
-/proyectos
-```
-
-## Qué hacer
-
-1. Leer el registro `~/.theus/arsenal/projects.json`
-2. Para cada proyecto, mostrar:
-   - Nombre, id, raíz y remoto del proyecto
-   - Conteo de instintos propios y heredados
-   - Conteo de eventos de observación
-   - Marca de tiempo de la última actividad
-3. Mostrar también los totales globales de instintos (`~/.theus/arsenal/instincts/`)

package/vendor/theus-arsenal/commands/prp-commit.md

@@ -1,112 +0,0 @@
----
-description: "Commit rápido con selección de archivos en lenguaje natural — describe qué commitear con tus palabras."
-argument-hint: "[descripción de qué incluir] (vacío = todos los cambios)"
----
-
-# Commit inteligente
-
-Parte de la serie de flujos PRP (planificar → implementar → commit).
-
-**Entrada**: $ARGUMENTS
-
----
-
-## Fase 1 — EVALUAR
-
-```bash
-git status --short
-```
-
-Si la salida está vacía → detente: "No hay nada que commitear."
-
-Muestra al usuario un resumen de lo que cambió (añadido, modificado, eliminado, sin seguimiento).
-
----
-
-## Fase 2 — INTERPRETAR Y PREPARAR (STAGE)
-
-Interpreta `$ARGUMENTS` para determinar qué preparar:
-
-| Entrada | Interpretación | Comando git |
-|---|---|---|
-| *(vacío)* | Preparar todo | `git add -A` |
-| `staged` | Usar lo que ya esté preparado | *(sin git add)* |
-| `*.ts`, `*.py`, etc. | Preparar el glob coincidente | `git add '*.ts'` |
-| `menos los tests` | Preparar todo y quitar los tests del stage | `git add -A && git reset -- '**/*.test.*' '**/*.spec.*' '**/test_*' 2>/dev/null \|\| true` |
-| `solo archivos nuevos` | Preparar solo los archivos sin seguimiento | `git ls-files --others --exclude-standard \| grep . && git ls-files --others --exclude-standard \| xargs git add` |
-| `los cambios de auth` | Interpretar desde status/diff — encontrar los archivos relacionados con auth | `git add <archivos identificados>` |
-| Nombres de archivo concretos | Preparar esos archivos | `git add <archivos>` |
-
-Para entradas en lenguaje natural (como "los cambios de auth"), cruza la salida de `git status` y `git diff` para identificar los archivos relevantes. Muestra al usuario qué archivos vas a preparar y por qué.
-
-```bash
-git add <archivos determinados>
-```
-
-Tras preparar, verifica:
-```bash
-git diff --cached --stat
-```
-
-Si no hay nada preparado, detente: "Ningún archivo coincidió con tu descripción."
-
----
-
-## Fase 3 — COMMIT
-
-Redacta un mensaje de commit de una sola línea en modo imperativo:
-
-```
-{tipo}: {descripción}
-```
-
-Tipos:
-- `feat` — funcionalidad o capacidad nueva
-- `fix` — corrección de un bug
-- `refactor` — reestructuración de código sin cambio de comportamiento
-- `docs` — cambios de documentación
-- `test` — añadir o actualizar tests
-- `chore` — build, configuración, dependencias
-- `perf` — mejora de rendimiento
-- `ci` — cambios de CI/CD
-
-Reglas:
-- Modo imperativo ("añade la función", no "añadida la función")
-- Minúscula después del prefijo de tipo
-- Sin punto final
-- Menos de 72 caracteres
-- Describe QUÉ cambió, no CÓMO
-
-```bash
-git commit -m "{tipo}: {descripción}"
-```
-
----
-
-## Fase 4 — SALIDA
-
-Informe al usuario:
-
-```
-Commit:    {hash_corto}
-Mensaje:   {tipo}: {descripción}
-Archivos:  {cantidad} archivo(s) cambiado(s)
-
-Siguientes pasos:
-  - git push           → subir al remoto
-  - /pr                → crear un pull request
-  - /revisar-codigo    → revisar antes de subir
-```
-
----
-
-## Ejemplos
-
-| Tú dices | Qué ocurre |
-|---|---|
-| `/prp-commit` | Prepara todo y genera el mensaje automáticamente |
-| `/prp-commit staged` | Commitea solo lo que ya está preparado |
-| `/prp-commit *.ts` | Prepara todos los archivos TypeScript y commitea |
-| `/prp-commit menos los tests` | Prepara todo excepto los archivos de test |
-| `/prp-commit la migración de base de datos` | Encuentra los archivos de migración desde el status y los prepara |
-| `/prp-commit solo archivos nuevos` | Prepara únicamente los archivos sin seguimiento |