npm - theus-cli-linux-x64 - Versions diffs - 1.2.2 → 1.3.0 - Mend

theus-cli-linux-x64 1.2.2 → 1.3.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (758) hide show

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

@@ -1,265 +0,0 @@
----
-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 DELETED Viewed

@@ -1,309 +0,0 @@
----
-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 DELETED Viewed

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