theus-cli-linux-arm64 1.2.2 → 1.3.0

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

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

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

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

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

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

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

@@ -1,160 +0,0 @@
----
-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`.