theus-cli-linux-x64 0.2.84

package/vendor/theus-arsenal/commands/orq-agregar-funcionalidad.md

@@ -0,0 +1,36 @@
+---
+description: Orquesta la construcción de una funcionalidad totalmente nueva de punta a punta — investigación, plan, TDD, revisión, commit con puertas de control. Wrapper que lanza la skill de orquestación orq-agregar-funcionalidad.
+---
+
+# /orq-agregar-funcionalidad
+
+Lanza manualmente el orquestador **orq-agregar-funcionalidad**: un pipeline con
+puertas de control Investigar → Planificar → TDD → Revisar → Commit para capacidades nuevas.
+
+## Uso
+
+```
+/orq-agregar-funcionalidad <qué agregar>
+```
+
+Ejemplos:
+
+```
+/orq-agregar-funcionalidad agregar login OAuth2 a nws-poller
+/orq-agregar-funcionalidad soportar exportación a CSV en el dashboard
+```
+
+## Qué hace
+
+Invoca la skill `orq-agregar-funcionalidad` con `$ARGUMENTS` como la solicitud. La skill
+(a través del motor compartido `orq-pipeline`) hará lo siguiente:
+
+1. Clasifica el tamaño y declara el nivel en una línea.
+2. Investiga librerías/patrones existentes y luego planifica una `task_list`. → **PUERTA 1** (aprobar el plan).
+3. Aplica TDD a cada tarea (tests nuevos en rojo → en verde) y luego pasa `revisor-codigo`
+   (+ `revisor-seguridad` si se toca un disparador de seguridad).
+4. Hace commits convencionales `feat:`. → **PUERTA 2** (confirmar antes del commit).
+
+Respeta ambas puertas — no escribas implementación antes de la Puerta 1, no hagas commit antes de la Puerta 2.
+
+Si `$ARGUMENTS` está vacío, pregunta al usuario qué capacidad quiere agregar.

package/vendor/theus-arsenal/commands/orq-cambiar-funcionalidad.md

@@ -0,0 +1,38 @@
+---
+description: Orquesta la modificación de una funcionalidad existente y operativa hacia un nuevo comportamiento deseado — actualiza los tests a la nueva spec, cambia la implementación, revisa, commit con puertas de control. Wrapper de la skill orq-cambiar-funcionalidad.
+---
+
+# /orq-cambiar-funcionalidad
+
+Lanza manualmente el orquestador **orq-cambiar-funcionalidad**: cambia un comportamiento
+que ya funciona hacia una nueva spec deseada, con los tests primero.
+
+## Uso
+
+```
+/orq-cambiar-funcionalidad <el nuevo comportamiento deseado>
+```
+
+Ejemplos:
+
+```
+/orq-cambiar-funcionalidad hacer que nws-poller alerte con 2 advertencias en lugar de 3
+/orq-cambiar-funcionalidad en lugar de ordenar por fecha, ordenar por prioridad
+```
+
+## Qué hace
+
+Invoca la skill `orq-cambiar-funcionalidad` con `$ARGUMENTS` como la solicitud. La skill
+(a través del motor compartido `orq-pipeline`) hará lo siguiente:
+
+1. Clasifica el tamaño (piso por defecto: pequeño) y declara el nivel.
+2. Planifica de forma ligera solo si el nuevo comportamiento requiere investigación. → **PUERTA 1** (aprobar el plan de tests modificados).
+3. **Actualiza los tests existentes** para expresar el nuevo comportamiento, y luego cambia la
+   implementación hasta quedar en verde. (Cambiar los tests primero es lo que hace de esto un
+   ajuste, no un arreglo.)
+4. Pasa `revisor-codigo` (+ `revisor-seguridad` ante un disparador de seguridad) y luego hace commit. → **PUERTA 2**.
+
+Usa esto solo cuando la funcionalidad **funciona** pero debería comportarse distinto — no para
+bugs (`/orq-corregir-defecto`) ni para capacidades nuevas (`/orq-agregar-funcionalidad`).
+
+Si `$ARGUMENTS` está vacío, pregunta al usuario qué comportamiento debe cambiar.

package/vendor/theus-arsenal/commands/orq-construir-mvp.md

@@ -0,0 +1,36 @@
+---
+description: Orquesta el arranque de un MVP funcional a partir de un documento de diseño/spec — ingesta, rebanado, scaffold, TDD, revisión, commit con puertas de control (reutiliza el harness generador-evaluador). Wrapper de la skill orq-construir-mvp.
+---
+
+# /orq-construir-mvp
+
+Lanza manualmente el orquestador **orq-construir-mvp**: convierte un documento
+SDD/PRD/diseño de sistema en una rebanada vertical funcionando.
+
+## Uso
+
+```
+/orq-construir-mvp <ruta al documento de diseño/spec>
+```
+
+Ejemplos:
+
+```
+/orq-construir-mvp civicpulse/docs/SDD-v0.6.md
+```
+
+## Qué hace
+
+Invoca la skill `orq-construir-mvp` con `$ARGUMENTS` como la ruta del documento. La skill
+(a través del motor compartido `orq-pipeline`, pipeline completo incl. Scaffold) hará lo siguiente:
+
+1. Lee la spec; extrae el alcance, las decisiones ya cerradas y una lista de funcionalidades ordenada como
+**rebanadas verticales delgadas** (primero una ruta de punta a punta). → **PUERTA 1** (aprobar el plan de rebanadas).
+2. Hace el scaffold de la primera rebanada de punta a punta.
+3. Reutiliza el harness generador-evaluador: traduce el SDD a `harness/spec.md` +
+   `eval-rubric.md`, y luego conduce `/harness-build "<brief>" --skip-planner`
+   (bucle generador → evaluador) hasta que la puntuación pase o se estanque.
+4. Pasa `revisor-codigo` (+ `revisor-seguridad` en cualquier rebanada con disparador de seguridad) y luego
+   hace commit del scaffold y de cada rebanada como commits `feat:` separados. → **PUERTA 2**.
+
+Si `$ARGUMENTS` está vacío, pide al usuario la ruta al documento de diseño/spec.

package/vendor/theus-arsenal/commands/orq-corregir-defecto.md

@@ -0,0 +1,40 @@
+---
+description: Orquesta la corrección de un bug — reprodúcelo como test de regresión en rojo, corrige hasta verde, revisión y commit con puerta de control. Wrapper que lanza la skill orq-corregir-defecto.
+---
+
+# /orq-corregir-defecto
+
+Lanza manualmente el orquestador **orq-corregir-defecto**: demuestra el bug con
+un test en rojo y luego corrige hasta verde.
+
+## Uso
+
+```
+/orq-corregir-defecto <qué está roto>
+```
+
+Ejemplos:
+
+```
+/orq-corregir-defecto el poller se cae ante una respuesta NWS vacía
+/orq-corregir-defecto el login devuelve 500 cuando el email tiene un signo más
+```
+
+## Qué hace
+
+Invoca la skill `orq-corregir-defecto` con `$ARGUMENTS` como la solicitud. La skill
+(a través del motor compartido `orq-pipeline`) hará lo siguiente:
+
+1. Clasifica el tamaño (piso por defecto: pequeño, a menudo trivial); acota la
+   causa raíz con `explorador-codigo` si no está clara.
+2. **Escribe un test de regresión nuevo que falle** reproduciendo el bug, y luego
+   corrige hasta que pase a verde. (Demostrar el bug primero es lo que convierte
+   esto en una corrección, no en un retoque.)
+3. Pasa `revisor-codigo` (+ `revisor-seguridad` si el defecto está en una ruta sensible).
+4. Hace el commit como un commit convencional `fix:`. → **PUERTA 2** (confirmar antes del commit).
+
+Usa este comando solo cuando el comportamiento está **roto/incorrecto** — no para
+cambios intencionales (`/orq-cambiar-funcionalidad`) ni para capacidades nuevas
+(`/orq-agregar-funcionalidad`).
+
+Si `$ARGUMENTS` está vacío, pide al usuario que describa el defecto.

package/vendor/theus-arsenal/commands/orq-refinar-codigo.md

@@ -0,0 +1,44 @@
+---
+description: Orquesta un refactor que preserva el comportamiento — confirma tests en verde, reestructura sin cambiar comportamiento, mantiene el verde, revisión y commit con puerta de control. Wrapper que lanza la skill orq-refinar-codigo.
+---
+
+# /orq-refinar-codigo
+
+Lanza manualmente el orquestador **orq-refinar-codigo**: mejora la estructura
+mientras el comportamiento permanece idéntico, con la suite de tests existente
+como red de seguridad.
+
+## Uso
+
+```
+/orq-refinar-codigo <qué reestructurar>
+```
+
+Ejemplos:
+
+```
+/orq-refinar-codigo extraer el cliente HTTP de NWS fuera de poller.py
+/orq-refinar-codigo eliminar código muerto y duplicación en el módulo del dashboard
+```
+
+## Qué hace
+
+Invoca la skill `orq-refinar-codigo` con `$ARGUMENTS` como la solicitud. La skill
+(a través del motor compartido `orq-pipeline`) hará lo siguiente:
+
+1. Clasifica el tamaño (piso por defecto: estándar — las reestructuraciones tocan varios archivos).
+2. Confirma que los tests relevantes existen y están **en verde antes** de tocar
+   código; agrega primero tests de caracterización si la cobertura es escasa.
+   Planifica la reestructuración. → **PUERTA 1**.
+3. Reestructura en pasos pequeños, re-ejecutando los tests tras cada uno (sin
+   tests de comportamiento nuevos — la suite existente demuestra que el
+   comportamiento no cambió). Los barridos de código muerto/duplicación se
+   delegan a `limpiador-refactors`.
+4. Pasa `revisor-codigo` y luego hace el commit como `refactor:` (el diff debe ser
+   neutral en comportamiento). → **PUERTA 2**.
+
+Usa este comando solo cuando el comportamiento **no** debe cambiar. Si el
+comportamiento debe cambiar en algo, usa `/orq-cambiar-funcionalidad` o
+`/orq-corregir-defecto`.
+
+Si `$ARGUMENTS` está vacío, pregunta al usuario qué quiere refinar.

package/vendor/theus-arsenal/commands/orq-revisar.md

@@ -0,0 +1,135 @@
+---
+description: Ejecuta la fase de Revisión del pipeline orq-* sobre un diff (cambios locales o un PR de GitHub) e informa hallazgos bloqueantes frente a advertencias.
+argument-hint: [número-de-pr | url-de-pr | vacío para cambios locales sin commitear]
+---
+
+# /orq-revisar
+
+Superficie de la fase 5 (Revisión) del motor compartido `orq-pipeline`, ejecutable
+de forma aislada sobre cualquier diff. Este comando calcula el diff, lanza el
+abanico de revisores en paralelo (un revisor por dimensión, deduplicación,
+verificación adversarial) y presenta el resultado. El comando es dueño de la
+entrada y la salida; la skill `orq-pipeline` define las dimensiones y el
+disparador de seguridad.
+
+**Entrada**: $ARGUMENTS
+
+---
+
+## Selección de modo
+
+| Entrada | Modo |
+|---|---|
+| Vacía | **Modo local** — revisa los cambios sin commitear |
+| Número (p. ej. `42`) o URL de PR | **Modo PR** — revisa un PR de GitHub |
+
+---
+
+## Fase 1 — RECOPILAR
+
+Construye el diff unificado y los metadatos que la revisión necesita.
+
+**Modo local:**
+
+```bash
+git diff --name-only HEAD          # archivos cambiados
+git diff HEAD                      # texto del diff
+```
+
+Si el diff está vacío, detente: "Nada que revisar."
+
+**Modo PR:**
+
+Primero deriva un **id numérico seguro de PR** a partir de `$ARGUMENTS` — nunca
+pases el argumento crudo al shell. Acepta un entero simple, o el número final de
+una URL `https://github.com/<owner>/<repo>/pull/<N>`. Rechaza cualquier otra cosa
+(texto extra, metacaracteres de shell, una URL que no sea de PR) y detente con un
+error. Usa solo el entero extraído `<NUMERO>` en lo que sigue:
+
+```bash
+gh pr diff <NUMERO>                       # texto del diff
+gh pr view <NUMERO> --json files \
+  --jq '.files[].path'                    # archivos cambiados
+```
+
+Si el PR no existe, detente con un error.
+
+Luego deriva el `lenguaje` a partir de la extensión dominante de los archivos
+cambiados (por ejemplo `.ts`/`.tsx` → typescript, `.py` → python, `.go` → go).
+Déjalo sin definir cuando el cambio sea mixto o no sea código — en ese caso
+simplemente se omite el revisor específico del lenguaje.
+
+Descarta de la lista los archivos binarios o generados — añaden ruido al
+disparador de seguridad sin contenido revisable.
+
+## Fase 2 — REVISAR (abanico de agentes)
+
+Lanza los revisores **en paralelo**, cada uno como subagente con el diff completo
+y la lista de archivos cambiados:
+
+1. **`revisor-codigo`** — siempre. Corrección, calidad, casos límite.
+2. **Revisor del lenguaje** (`revisor-typescript`, `revisor-python`, `revisor-go`,
+   `revisor-rust`, …) — solo si derivaste un `lenguaje` con revisor disponible en
+   `agents/`.
+3. **`revisor-seguridad`** — solo si algún archivo cambiado toca un disparador de
+   seguridad según la skill `orq-pipeline` (auth, sesiones, crypto, manejo de
+   secretos, validación de entrada, rutas de pago, etc.).
+
+Con los resultados:
+
+- **Deduplica** los hallazgos por el fragmento de evidencia normalizado (mismo
+  archivo + mismo fragmento señalado = un solo hallazgo; conserva la severidad
+  más alta).
+- **Verificación adversarial**: para cada hallazgo único CRÍTICO/ALTO, relee el
+  código real e intenta refutarlo con un escenario concreto. Clasifícalo como
+  `confirmado`, `refutado` o `no verificable`.
+- Calcula el veredicto:
+  - `CAMBIOS_REQUERIDOS` si queda al menos un hallazgo CRÍTICO/ALTO confirmado o
+    no verificable.
+  - `APROBADO` en caso contrario.
+- Si una dimensión no pudo ejecutarse (el subagente falló), marca el resultado
+  como `incompleto` y registra qué dimensión falló.
+
+Clasificación final:
+
+- **Bloqueantes**: CRÍTICO/ALTO confirmados + hallazgos no verificables.
+- **Advertencias**: MEDIO/BAJO + hallazgos refutados por la verificación.
+
+## Fase 3 — INFORMAR
+
+Presenta el resultado al usuario (esta es la puerta de revisión humana; este
+comando no hace commit de nada):
+
+- Abre con el veredicto y una línea de estadísticas (dimensiones ejecutadas,
+  hallazgos crudos → únicos, confirmados/refutados).
+- Lista cada hallazgo **bloqueante** con archivo, severidad y evidencia — deben
+  resolverse antes de un commit. Los hallazgos "no verificables" permanecen como
+  bloqueantes por diseño; señálalos como pendientes de confirmación manual.
+- Lista brevemente las **advertencias** (MEDIO/BAJO y hallazgos refutados).
+- Si la revisión quedó `incompleta`, indica qué dimensiones no se ejecutaron y
+  que, por tanto, el veredicto no es una aprobación limpia.
+
+## Contrato de fallo cerrado
+
+Este comando nunca debe presentar un APROBADO limpio cuando la revisión no pudo
+ejecutarse completa. Si el abanico de revisores falla, informa el fallo — no
+recurras a una revisión improvisada de una sola pasada ni des a entender que el
+diff fue aprobado.
+
+---
+
+## Casos límite
+
+- **Sin CLI `gh` (Modo PR)**: detente e indica al usuario que el Modo PR necesita
+  `gh`; sugiere el Modo local sobre la rama ya descargada.
+- **Diff grande**: limita la concurrencia de revisores (lánzalos por tandas si
+  hace falta); un diff grande es más lento pero seguro — avisa al usuario de que
+  puede tardar.
+- **Archivos binarios o generados**: exclúyelos antes del abanico — sin contenido
+  revisable solo distorsionan el disparador de seguridad.
+
+## Relacionados
+
+- Skill: `skills/orq-pipeline/` — dimensiones, mapa de agentes y disparador de seguridad
+- Agentes: `agents/revisor-codigo.md`, `agents/revisor-seguridad.md`
+- `/revisar-codigo` — revisión de calidad de propósito general

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

@@ -0,0 +1,160 @@
+---
+description: "Genera un PRD ligero, centrado en el problema, y lo entrega a /plan para la planificación de la implementación."
+argument-hint: "[idea de producto/funcionalidad] (vacío = empezar con preguntas)"
+---
+
+# Comando PRD
+
+Produce un **Documento de Requisitos de Producto (PRD)** — el artefacto de la fase de requisitos del ciclo de vida del software. Captura *qué* debe cumplirse para tener éxito y *por qué*, y se detiene antes del *cómo*. La descomposición de la implementación se delega a `/plan`.
+
+**Entrada**: `$ARGUMENTS`
+
+## Alcance de este comando
+
+| Este comando SÍ hace | Este comando NO hace |
+|---|---|
+| Enmarcar el problema y los usuarios | Diseñar la arquitectura |
+| Capturar criterios de éxito y alcance | Elegir archivos o escribir patrones |
+| Listar preguntas abiertas y riesgos | Enumerar tareas de implementación |
+| Escribir `.theus/prds/{nombre}.prd.md` | Producir un plan de implementación — eso es `/plan` |
+
+Si te descubres escribiendo detalle de implementación, detente y elimínalo. Pertenece a `/plan`.
+
+**Regla anti-relleno**: cuando falte información, escribe `PENDIENTE — requiere validación vía {método}`. Nunca inventes requisitos que suenen plausibles.
+
+## Flujo de trabajo
+
+Cuatro fases. Cada fase es una única compuerta — haz las preguntas, espera al usuario y avanza. Sin bucles anidados ni ceremonias de investigación en paralelo.
+
+### Fase 1 — ENMARCAR
+
+Si `$ARGUMENTS` está vacío, pregunta:
+
+> ¿Qué quieres construir? Una o dos frases.
+
+Si se proporcionó, reformúlalo en una frase y pregunta:
+
+> Entiendo: *{reformulación}*. ¿Es correcto, o debo ajustarlo?
+
+Luego haz las preguntas de encuadre en un solo bloque:
+
+> 1. **¿Quién** tiene este problema? (rol o segmento específico)
+> 2. **¿Cuál** es el dolor observable? (describe comportamiento, no necesidades supuestas)
+> 3. **¿Por qué** no pueden resolverlo con lo que existe hoy?
+> 4. **¿Por qué ahora?** — ¿qué cambió que hace que valga la pena hacerlo?
+
+Espera al usuario. No avances sin respuestas (o un "omitir" explícito).
+
+### Fase 2 — FUNDAMENTAR
+
+Pide evidencia. Es la fase más corta y la que más peso soporta:
+
+> ¿Qué evidencia tienes de que este problema es real y vale la pena resolverlo? (citas de usuarios, tickets de soporte, métricas, comportamiento observado, soluciones improvisadas fallidas — cualquier cosa concreta)
+
+Si el usuario no tiene ninguna, registra la sección de Evidencia del PRD como `Supuesto — requiere validación vía {investigación de usuarios | analítica | prototipo}`. Esto mantiene el PRD honesto.
+
+### Fase 3 — DECIDIR
+
+Alcance e hipótesis en un solo bloque:
+
+> 1. **Hipótesis** — Completa: *Creemos que **{capacidad}** va a **{resolver el problema}** para **{usuarios}**. Sabremos que acertamos cuando **{resultado medible}**.*
+> 2. **MVP** — ¿Lo mínimo necesario para probar la hipótesis?
+> 3. **Fuera de alcance** — ¿Qué explícitamente **no** vas a construir (aunque los usuarios lo pidan)?
+> 4. **Preguntas abiertas** — ¿Incertidumbres que podrían cambiar el enfoque?
+
+Espera las respuestas.
+
+### Fase 4 — GENERAR Y ENTREGAR
+
+Crea el directorio si es necesario, escribe el PRD y reporta.
+
+```bash
+mkdir -p .theus/prds
+```
+
+**Ruta de salida**: `.theus/prds/{nombre-en-kebab-case}.prd.md`
+
+#### Plantilla del PRD
+
+```markdown
+# {Nombre del producto / funcionalidad}
+
+## Problema
+{2–3 frases: quién tiene qué problema, y cuál es el costo de dejarlo sin resolver}
+
+## Evidencia
+- {Cita de usuario, dato o observación}
+- {O BIEN: "Supuesto — requiere validación vía {método}"}
+
+## Usuarios
+- **Primario**: {rol, contexto, qué dispara la necesidad}
+- **No es para**: {a quién excluye explícitamente}
+
+## Hipótesis
+Creemos que **{capacidad}** va a **{resolver el problema}** para **{usuarios}**.
+Sabremos que acertamos cuando **{resultado medible}**.
+
+## Métricas de éxito
+| Métrica | Objetivo | Cómo se mide |
+|---|---|---|
+| {primaria} | {número} | {método} |
+
+## Alcance
+**MVP** — {lo mínimo para probar la hipótesis}
+
+**Fuera de alcance**
+- {ítem} — {por qué se difiere}
+
+## Hitos de entrega
+<!-- Resultados de negocio, no tareas de ingeniería. /plan convierte cada uno en un plan. -->
+<!-- Estado: pendiente | en-progreso | completo -->
+
+| # | Hito | Resultado | Estado | Plan |
+|---|---|---|---|---|
+| 1 | {nombre} | {cambio visible para el usuario} | pendiente | — |
+| 2 | {nombre} | {cambio visible para el usuario} | pendiente | — |
+
+## Preguntas abiertas
+- [ ] {pregunta que podría cambiar el alcance o el enfoque}
+
+## Riesgos
+| Riesgo | Probabilidad | Impacto | Mitigación |
+|---|---|---|---|
+
+---
+*Estado: BORRADOR — solo requisitos. Planificación de implementación pendiente vía /plan.*
+```
+
+#### Reporte al usuario
+
+```
+PRD creado: .theus/prds/{nombre}.prd.md
+
+Problema:  {una línea}
+Hipótesis: {una línea}
+MVP:       {una línea}
+
+Estado de validación:
+  Problema  {validado | supuesto}
+  Usuarios  {concreto | genérico — refinar}
+  Métricas  {definidas | PENDIENTE}
+
+Preguntas abiertas: {cantidad}
+
+Siguiente paso: /plan .theus/prds/{nombre}.prd.md
+  → /plan elegirá el siguiente hito pendiente y producirá un plan de implementación.
+```
+
+## Integración
+
+- `/plan <ruta-del-prd>` — consume el PRD y produce un plan de implementación para el siguiente hito pendiente.
+- Skill `flujo-tdd` — implementa el plan con enfoque test-first.
+- `/pr` — abre un PR que referencia el PRD y el plan.
+
+## Criterios de éxito
+
+- **PROBLEMA_CLARO**: el problema es específico y está evidenciado (o marcado como supuesto).
+- **USUARIO_CONCRETO**: el usuario primario es un rol específico, no "usuarios".
+- **HIPOTESIS_COMPROBABLE**: incluye un resultado medible.
+- **ALCANCE_ACOTADO**: MVP explícito y fuera-de-alcance explícito.
+- **SIN_DETALLE_DE_IMPLEMENTACION**: no hay rutas de archivos, librerías ni desgloses de tareas — si aparecieron, muévelos al paso `/plan`.