theus-cli-linux-arm64 0.2.84

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

@@ -0,0 +1,198 @@
+---
+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

@@ -0,0 +1,31 @@
+---
+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

@@ -0,0 +1,181 @@
+---
+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

@@ -0,0 +1,41 @@
+---
+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

@@ -0,0 +1,33 @@
+---
+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

@@ -0,0 +1,112 @@
+---
+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 |