theus-cli-linux-arm64 0.2.84

package/vendor/theus-arsenal/commands/test-react.md

@@ -0,0 +1,265 @@
+---
+description: Aplica el flujo TDD para React. Primero se escriben tests con React Testing Library (enfocados en comportamiento, con la accesibilidad primero) y luego se implementan los componentes. Detecta Vitest o Jest y verifica los objetivos de cobertura.
+---
+
+# Comando de TDD para React
+
+Este comando aplica desarrollo guiado por tests (TDD) para React usando React Testing Library más Vitest o Jest, detectados en tiempo de ejecución.
+
+## Qué hace este comando
+
+1. **Definir la firma del componente**: crea el esqueleto del componente, el tipo de props y los exports
+2. **Escribir primero los tests de comportamiento**: queries de RTL (rol primero), `userEvent`, MSW para la red — ROJO
+3. **Ejecutar los tests**: verificar que fallan por la razón correcta
+4. **Implementar el código mínimo**: justo lo suficiente para pasar — VERDE
+5. **Refactorizar**: mejorar manteniendo los tests en verde
+6. **Verificar la cobertura**: alcanzar los objetivos de [rules/react/testing.md](../rules/react/testing.md)
+
+## Cuándo usarlo
+
+Usa `/test-react` cuando:
+
+- Implementes un componente de React o un hook personalizado nuevo
+- Añadas cobertura de tests a un componente sin tests
+- Corrijas un bug (primero escribe un test que falle y lo reproduzca)
+- Construyas formularios, máquinas de estado o UI crítica en accesibilidad
+- Te estés incorporando al flujo de RTL + Vitest/Jest
+
+## Ciclo TDD
+
+```
+ROJO       -> Escribir un test que falle para el siguiente comportamiento
+VERDE      -> Implementar el código mínimo del componente para pasar
+REFACTOR   -> Mejorar el componente; los tests siguen en verde
+REPETIR    -> Siguiente comportamiento
+```
+
+## Detección del runner
+
+```bash
+test -f vitest.config.ts -o -f vitest.config.js -o -f vite.config.ts   # Vitest
+grep -l '"jest"' package.json                                          # Jest
+```
+
+Prefiere Vitest para proyectos nuevos basados en Vite; respeta Jest en configuraciones existentes.
+
+## Sesión de ejemplo
+
+````text
+Usuario: /test-react Necesito un componente SearchInput con búsqueda con debounce
+
+Agente:
+# Sesión TDD: SearchInput
+
+## Paso 1: Definir la firma
+
+```tsx
+// src/components/SearchInput.tsx
+type Props = {
+  onSearch: (query: string) => void;
+  placeholder?: string;
+  debounceMs?: number;
+};
+
+export function SearchInput({ onSearch, placeholder, debounceMs }: Props) {
+  throw new Error("no implementado");
+}
+```
+
+## Paso 2: Escribir los tests de comportamiento (ROJO)
+
+```tsx
+// src/components/SearchInput.test.tsx
+import { describe, expect, test, vi } from "vitest";
+import { render, screen } from "@testing-library/react";
+import userEvent from "@testing-library/user-event";
+import { SearchInput } from "./SearchInput";
+
+describe("SearchInput", () => {
+  test("se renderiza con placeholder", () => {
+    render(<SearchInput onSearch={() => {}} placeholder="Buscar usuarios" />);
+    expect(screen.getByPlaceholderText("Buscar usuarios")).toBeInTheDocument();
+  });
+
+  test("llama a onSearch después de escribir", async () => {
+    vi.useFakeTimers();
+    const user = userEvent.setup({ advanceTimers: vi.advanceTimersByTime });
+    const onSearch = vi.fn();
+    render(<SearchInput onSearch={onSearch} debounceMs={300} />);
+
+    await user.type(screen.getByRole("textbox"), "alice");
+
+    expect(onSearch).not.toHaveBeenCalled();        // antes del debounce
+    vi.advanceTimersByTime(300);
+    expect(onSearch).toHaveBeenCalledWith("alice"); // después del debounce
+
+    vi.useRealTimers();
+  });
+
+  test("no llama a onSearch cuando la escritura pausa y luego continúa", async () => {
+    vi.useFakeTimers();
+    const user = userEvent.setup({ advanceTimers: vi.advanceTimersByTime });
+    const onSearch = vi.fn();
+    render(<SearchInput onSearch={onSearch} debounceMs={300} />);
+
+    await user.type(screen.getByRole("textbox"), "ali");
+    vi.advanceTimersByTime(200);                    // a mitad del debounce
+    await user.type(screen.getByRole("textbox"), "ce");
+    vi.advanceTimersByTime(300);
+
+    expect(onSearch).toHaveBeenCalledTimes(1);
+    expect(onSearch).toHaveBeenCalledWith("alice");
+
+    vi.useRealTimers();
+  });
+
+  test("es alcanzable por teclado y accesible", () => {
+    render(<SearchInput onSearch={() => {}} />);
+    const input = screen.getByRole("textbox");
+    input.focus();
+    expect(input).toHaveFocus();
+  });
+});
+```
+
+## Paso 3: Ejecutar los tests — verificar que FALLAN
+
+```bash
+$ vitest run src/components/SearchInput.test.tsx
+
+× src/components/SearchInput.test.tsx (4 tests) ✘ Error: no implementado
+```
+
+✓ Los tests fallan como se esperaba.
+
+## Paso 4: Implementar el código mínimo (VERDE)
+
+```tsx
+import { useEffect, useState } from "react";
+
+export function SearchInput({ onSearch, placeholder, debounceMs = 300 }: Props) {
+  const [query, setQuery] = useState("");
+
+  useEffect(() => {
+    const id = setTimeout(() => onSearch(query), debounceMs);
+    return () => clearTimeout(id);
+  }, [query, onSearch, debounceMs]);
+
+  return (
+    <input
+      type="text"
+      value={query}
+      placeholder={placeholder}
+      onChange={(e) => setQuery(e.target.value)}
+    />
+  );
+}
+```
+
+## Paso 5: Ejecutar los tests — verificar que PASAN
+
+```bash
+$ vitest run src/components/SearchInput.test.tsx
+
+✓ src/components/SearchInput.test.tsx (4 tests) 47ms
+```
+
+## Paso 6: Cobertura
+
+```bash
+$ vitest run --coverage src/components/SearchInput.test.tsx
+
+% Stmts: 100  % Branch: 100  % Funcs: 100  % Lines: 100
+```
+
+## ¡TDD completado!
+````
+
+## Patrones de testing
+
+### Comportamiento, no implementación
+
+Usa `getByRole`, `getByLabelText`, `getByText`. Evita `container.querySelector` y hacer aserciones sobre el estado del componente.
+
+### `userEvent.setup()` por test
+
+```tsx
+const user = userEvent.setup();
+await user.click(screen.getByRole("button", { name: /save/i }));
+```
+
+### MSW para la red
+
+```tsx
+beforeAll(() => server.listen({ onUnhandledRequest: "error" }));
+afterEach(() => server.resetHandlers());
+afterAll(() => server.close());
+
+server.use(http.post("/api/users", () => HttpResponse.json({ id: "1" }, { status: 201 })));
+```
+
+### Hooks personalizados
+
+```tsx
+const { result } = renderHook(() => useCounter(0));
+act(() => result.current.increment());
+expect(result.current.count).toBe(1);
+```
+
+### Accesibilidad
+
+```tsx
+import { axe } from "vitest-axe";
+expect(await axe(container)).toHaveNoViolations();
+```
+
+## Objetivos de cobertura
+
+| Capa | Objetivo |
+|---|---|
+| Utilidades puras | >=90% |
+| Hooks personalizados | >=85% |
+| Componentes de presentación | >=80% |
+| Componentes contenedores | >=70% |
+| Páginas | Cubiertas aparte por E2E |
+
+Configura los umbrales en `vitest.config.ts` / `jest.config.js` para hacerlos cumplir en CI.
+
+## Antipatrones a evitar
+
+- `container.querySelector(...)` — se salta las queries de accesibilidad
+- Hacer aserciones sobre el número de renders
+- Mockear el propio `react` (`jest.mock("react", ...)`)
+- Mockear componentes hijos por defecto (mockea solo cuando el hijo tiene efectos secundarios pesados)
+- Ignorar las advertencias de `act()` — señalan bugs reales
+- Tests de snapshot de componentes renderizados (frágiles, se aprueban sin mirar) — usa diff visual con Playwright/Cypress en su lugar
+
+## Comandos de test
+
+```bash
+# Vitest
+vitest                              # modo watch
+vitest run                          # una sola pasada
+vitest run --coverage               # con cobertura
+vitest run path/to/file.test.tsx    # un solo archivo
+
+# Jest
+jest --watch
+jest --coverage
+jest path/to/file.test.tsx
+
+# Modo CI
+CI=true vitest run --coverage
+```
+
+## Comandos relacionados
+
+- `/build-react` — arreglar errores de build antes de ejecutar los tests
+- `/revisar-react` — revisar después de la implementación
+- Skill `bucle-verificacion` — bucle de verificación completo
+
+## Relacionado
+
+- Skills: `skills/testing-react/`, `skills/flujo-tdd/`, `skills/accesibilidad/`, `skills/testing-e2e/`
+- Reglas: `rules/react/testing.md`
+- Agentes: `revisor-react` (revisa la calidad de los tests), `guia-tdd` (hace cumplir el proceso TDD)

package/vendor/theus-arsenal/commands/test-rust.md

@@ -0,0 +1,309 @@
+---
+description: Aplica el flujo TDD en Rust — escribe los tests primero, luego implementa y verifica cobertura 80%+ con cargo-llvm-cov.
+argument-hint: <descripción de la función o comportamiento a implementar>
+---
+
+# Comando TDD para Rust
+
+Este comando aplica la metodología de desarrollo guiado por tests (TDD) para código Rust usando `#[test]`, rstest, proptest y mockall.
+
+## Qué hace este comando
+
+1. **Definir tipos/traits**: Esqueleto de firmas de funciones con `todo!()`
+2. **Escribir tests**: Crear un módulo de tests exhaustivo (ROJO)
+3. **Ejecutar tests**: Verificar que fallan por la razón correcta
+4. **Implementar código**: Escribir el mínimo código para pasar (VERDE)
+5. **Refactorizar**: Mejorar manteniendo los tests en verde
+6. **Comprobar cobertura**: Asegurar 80%+ con cargo-llvm-cov
+
+## Cuándo usarlo
+
+Usa `/test-rust` cuando:
+- Implementes nuevas funciones, métodos o traits en Rust
+- Añadas cobertura de tests a código Rust existente
+- Corrijas bugs (escribe primero el test que falla)
+- Construyas lógica de negocio crítica
+- Quieras interiorizar el flujo TDD en Rust
+
+## Ciclo TDD
+
+```
+ROJO       -> Escribe primero un test que falla
+VERDE      -> Implementa el mínimo código para pasar
+REFACTOR   -> Mejora el código, los tests siguen en verde
+REPITE     -> Siguiente caso de test
+```
+
+## Sesión de ejemplo
+
+````text
+Usuario: /test-rust Necesito una función que valide el registro de usuarios
+
+Agente:
+# Sesión TDD: Validador de registro
+
+## Paso 1: Definir la interfaz
+
+```rust
+// src/validator.rs
+pub struct RegistrationRequest {
+    pub name: String,
+    pub email: String,
+    pub password: String,
+}
+
+pub enum ValidationResult {
+    Valid,
+    Invalid(Vec<String>),
+}
+
+pub fn validate_registration(request: &RegistrationRequest) -> ValidationResult {
+    todo!()
+}
+```
+
+## Paso 2: Escribir tests (ROJO)
+
+```rust
+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    #[test]
+    fn valid_registration_returns_valid() {
+        let request = RegistrationRequest {
+            name: "Alice".into(),
+            email: "alice@example.com".into(),
+            password: "SecureP@ss1".into(),
+        };
+        assert!(matches!(validate_registration(&request), ValidationResult::Valid));
+    }
+
+    #[test]
+    fn blank_name_returns_invalid() {
+        let request = RegistrationRequest {
+            name: "".into(),
+            email: "alice@example.com".into(),
+            password: "SecureP@ss1".into(),
+        };
+        match validate_registration(&request) {
+            ValidationResult::Invalid(errors) => {
+                assert!(errors.contains(&"Name is required".to_string()));
+            }
+            ValidationResult::Valid => panic!("se esperaba Invalid"),
+        }
+    }
+
+    #[test]
+    fn invalid_email_returns_invalid() {
+        let request = RegistrationRequest {
+            name: "Alice".into(),
+            email: "not-an-email".into(),
+            password: "SecureP@ss1".into(),
+        };
+        assert!(matches!(
+            validate_registration(&request),
+            ValidationResult::Invalid(_)
+        ));
+    }
+
+    #[test]
+    fn short_password_returns_invalid() {
+        let request = RegistrationRequest {
+            name: "Alice".into(),
+            email: "alice@example.com".into(),
+            password: "short".into(),
+        };
+        assert!(matches!(
+            validate_registration(&request),
+            ValidationResult::Invalid(_)
+        ));
+    }
+}
+```
+
+## Paso 3: Ejecutar tests — verificar que FALLAN
+
+```bash
+$ cargo test
+running 4 tests
+test tests::valid_registration_returns_valid ... FAILED (not yet implemented)
+test tests::blank_name_returns_invalid ... FAILED
+test tests::invalid_email_returns_invalid ... FAILED
+test tests::short_password_returns_invalid ... FAILED
+```
+
+Los tests fallan como se esperaba (pánico por `todo!`).
+
+## Paso 4: Implementar el mínimo código (VERDE)
+
+```rust
+pub fn validate_registration(request: &RegistrationRequest) -> ValidationResult {
+    let mut errors = Vec::new();
+
+    if request.name.trim().is_empty() {
+        errors.push("Name is required".into());
+    }
+    if !request.email.contains('@') {
+        errors.push("Invalid email format".into());
+    }
+    if request.password.len() < 8 {
+        errors.push("Password must be at least 8 characters".into());
+    }
+
+    if errors.is_empty() {
+        ValidationResult::Valid
+    } else {
+        ValidationResult::Invalid(errors)
+    }
+}
+```
+
+## Paso 5: Ejecutar tests — verificar que PASAN
+
+```bash
+$ cargo test
+running 4 tests
+test tests::valid_registration_returns_valid ... ok
+test tests::blank_name_returns_invalid ... ok
+test tests::invalid_email_returns_invalid ... ok
+test tests::short_password_returns_invalid ... ok
+
+test result: ok. 4 passed; 0 failed
+```
+
+¡Todos los tests pasan!
+
+## Paso 6: Comprobar cobertura
+
+```bash
+$ cargo llvm-cov
+Coverage: 100.0% of lines
+```
+
+Cobertura: 100%
+
+## ¡TDD completo!
+````
+
+## Patrones de tests
+
+### Tests unitarios
+
+```rust
+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    #[test]
+    fn adds_two_numbers() {
+        assert_eq!(add(2, 3), 5);
+    }
+
+    #[test]
+    fn handles_error() -> Result<(), Box<dyn std::error::Error>> {
+        let result = parse_config(r#"port = 8080"#)?;
+        assert_eq!(result.port, 8080);
+        Ok(())
+    }
+}
+```
+
+### Tests parametrizados con rstest
+
+```rust
+use rstest::{rstest, fixture};
+
+#[rstest]
+#[case("hello", 5)]
+#[case("", 0)]
+#[case("rust", 4)]
+fn test_string_length(#[case] input: &str, #[case] expected: usize) {
+    assert_eq!(input.len(), expected);
+}
+```
+
+### Tests asíncronos
+
+```rust
+#[tokio::test]
+async fn fetches_data_successfully() {
+    let client = TestClient::new().await;
+    let result = client.get("/data").await;
+    assert!(result.is_ok());
+}
+```
+
+### Tests basados en propiedades
+
+```rust
+use proptest::prelude::*;
+
+proptest! {
+    #[test]
+    fn encode_decode_roundtrip(input in ".*") {
+        let encoded = encode(&input);
+        let decoded = decode(&encoded).unwrap();
+        assert_eq!(input, decoded);
+    }
+}
+```
+
+## Comandos de cobertura
+
+```bash
+# Informe resumido
+cargo llvm-cov
+
+# Informe HTML
+cargo llvm-cov --html
+
+# Fallar si queda por debajo del umbral
+cargo llvm-cov --fail-under-lines 80
+
+# Ejecutar un test específico
+cargo test test_name
+
+# Ejecutar mostrando la salida
+cargo test -- --nocapture
+
+# Ejecutar sin detenerse en el primer fallo
+cargo test --no-fail-fast
+```
+
+## Objetivos de cobertura
+
+| Tipo de código | Objetivo |
+|----------------|----------|
+| Lógica de negocio crítica | 100% |
+| API pública | 90%+ |
+| Código general | 80%+ |
+| Generado / bindings FFI | Excluir |
+
+## Buenas prácticas de TDD
+
+**SÍ:**
+- Escribe el test PRIMERO, antes de cualquier implementación
+- Ejecuta los tests después de cada cambio
+- Usa `assert_eq!` en lugar de `assert!` para mensajes de error más claros
+- Usa `?` en tests que devuelven `Result` para una salida más limpia
+- Testea el comportamiento, no la implementación
+- Incluye casos límite (vacío, frontera, rutas de error)
+
+**NO:**
+- Escribir la implementación antes de los tests
+- Saltarte la fase ROJO
+- Usar `#[should_panic]` cuando `Result::is_err()` sirve
+- Usar `sleep()` en tests — usa canales o `tokio::time::pause()`
+- Mockear todo — prefiere tests de integración cuando sea viable
+
+## Comandos relacionados
+
+- `/build-rust` — corregir errores de compilación
+- `/revisar-rust` — revisar el código tras la implementación
+- Skill `bucle-verificacion` — ejecutar el bucle completo de verificación
+
+## Relacionados
+
+- Skill: `skills/testing-rust/`
+- Skill: `skills/patrones-rust/`

package/vendor/theus-arsenal/commands/vigilancia-canary.md

@@ -0,0 +1,43 @@
+---
+description: Monitorea y verifica una URL desplegada después de un release — chequea estado HTTP, streams SSE, assets estáticos, errores de consola y regresiones de rendimiento. Soporta chequeo rápido, vigilancia sostenida y modo diff staging vs producción.
+---
+
+# Comando Vigilancia Canary
+
+Verifica que un deploy está sano monitoreando la URL desplegada en busca de regresiones. Punto de entrada de la skill `vigilancia-canary` — carga esa skill y sigue su procedimiento completo.
+
+## Uso
+
+```
+/vigilancia-canary <url>                                        # chequeo rápido (una pasada)
+/vigilancia-canary <url> --interval 5m --duration 2h            # vigilancia sostenida
+/vigilancia-canary --compare <url-staging> <url-produccion>     # modo diff
+```
+
+## Cuándo usarlo
+
+- Después de desplegar a producción o staging
+- Después de hacer merge de un PR riesgoso
+- Para verificar que un fix realmente arregló el problema
+- Monitoreo continuo durante una ventana de lanzamiento
+- Después de actualizar dependencias
+
+## Qué hace
+
+1. Carga la skill `vigilancia-canary`.
+2. Ejecuta los chequeos sobre la URL objetivo:
+   - Estado HTTP (¿devuelve 200?)
+   - Errores de consola (solo errores nuevos respecto a la línea base)
+   - Fallos de red (llamadas a la API fallidas, respuestas 5xx)
+   - Rendimiento (LCP/CLS/INP contra la línea base)
+   - Contenido (elementos clave presentes: h1, nav, footer, CTA)
+   - Salud de la API (endpoints críticos dentro del SLA)
+   - Assets estáticos (JS, CSS, imágenes y fuentes con 2xx/3xx y content types esperados)
+   - Streams SSE (conexión y primer evento o heartbeat)
+3. Evalúa los umbrales de alerta (critical / warning / info) definidos en la skill.
+4. Produce el reporte canary en tabla con resultado, línea base y delta por chequeo.
+5. En modo sostenido, repite el ciclo cada intervalo hasta agotar la duración; registra en `~/.theus/vigilancia-canary.log` y notifica si se cruza un umbral crítico.
+
+## Salida
+
+Un reporte en Markdown con el estado global (SALUDABLE / DEGRADADO / CAÍDO), la tabla de chequeos y el veredicto final sobre si el deploy está limpio o presenta regresiones.