failproofai 1.0.1-beta.0 → 1.0.1

package/.next/standalone/docs-old/es/getting-started.mdx

@@ -0,0 +1,199 @@
+---
+title: Primeros pasos
+description: "Instala failproofai, activa las políticas y deja que tus agentes funcionen de forma confiable"
+icon: rocket
+---
+
+## Requisitos
+
+- **Node.js** >= 20.9.0
+- **Bun** >= 1.3.0 (opcional - solo necesario para compilar desde el código fuente)
+
+---
+
+## Instalación
+
+<CodeGroup>
+
+```bash npm
+npm install -g failproofai
+```
+
+```bash bun
+bun add -g failproofai
+```
+
+</CodeGroup>
+
+---
+
+## Inicio rápido
+
+<Steps>
+  <Step title="Activar las políticas">
+    Las políticas son reglas que se ejecutan antes y después de cada llamada a una herramienta del agente. Detectan comandos destructivos, filtraciones de secretos y otros modos de fallo antes de que causen daños.
+
+    ```bash
+    failproofai policies --install
+    ```
+
+    Esto escribe entradas de hooks en los CLIs de agentes instalados (el `~/.claude/settings.json` de Claude Code, el `~/.codex/hooks.json` de OpenAI Codex, el `~/.copilot/hooks/failproofai.json` de GitHub Copilot CLI, el `~/.cursor/hooks.json` de Cursor Agent, el shim de plugin generado por OpenCode en `~/.config/opencode/plugins/failproofai.mjs` más una entrada de registro en el array `plugin` de `~/.config/opencode/opencode.json`, el `~/.pi/agent/settings.json` de Pi, el `~/.hermes/config.yaml` de Hermes, el `~/.openclaw/openclaw.json` de OpenClaw, el `~/.factory/hooks.json` de Factory Droid, el `~/.config/devin/config.json` de Devin CLI, el `~/.gemini/config/hooks.json` de Antigravity CLI, o el directorio de plugins autodescubierto de Goose en `~/.agents/plugins/failproofai/hooks/hooks.json`). Si hay más de uno instalado se te pedirá que elijas; pasa `--cli claude codex copilot cursor opencode pi hermes openclaw factory devin antigravity goose` (cualquier subconjunto) para omitir el aviso.
+
+    El soporte para GitHub Copilot CLI, Cursor Agent, OpenCode y Pi está en **beta** — instala con `--cli copilot`, `--cli cursor`, `--cli opencode` o `--cli pi`. Hermes (hermes-agent, una pasarela Slack/Telegram) se instala con ámbito de usuario con `--cli hermes` y es **también** una fuente de auditoría offline. OpenClaw (pasarela openclaw, un asistente multicanal autoalojado) se instala con ámbito de usuario con `--cli openclaw` — la aplicación de políticas se ejecuta a través de sus hooks de plugin en proceso (`before_agent_finalize` es una compuerta real de fin de turno, por lo que los builtins `require-*-before-stop` se aplican) — y es **también** una fuente de auditoría offline. Factory Droid (`droid`) se instala con `--cli factory` (ámbito de usuario y proyecto) y es **también** una fuente de auditoría offline. Devin CLI (`devin`, Cognition) se instala con `--cli devin` (ámbito de usuario y proyecto) y es **también** una fuente de auditoría offline. Antigravity CLI (`agy`) se instala con `--cli antigravity` (ámbito de usuario y proyecto) y es **también** una fuente de auditoría offline. Goose (nombre en clave goose, Block) se instala con `--cli goose` (ámbito de usuario y proyecto) — el instalador simplemente crea un directorio de plugin en `~/.agents/plugins/failproofai/` que Goose autodescubre, y es **también** una fuente de auditoría offline.
+
+    ```bash
+    failproofai policies --install --scope project
+    failproofai policies --install --cli codex --scope project
+    failproofai policies --install --cli copilot --scope project
+    failproofai policies --install --cli cursor --scope project
+    failproofai policies --install --cli opencode --scope project
+    failproofai policies --install --cli pi --scope project
+    failproofai policies --install --cli hermes --scope user
+    failproofai policies --install --cli openclaw --scope user
+    failproofai policies --install --cli factory --scope project
+    failproofai policies --install --cli devin --scope project
+    failproofai policies --install --cli antigravity --scope project
+    failproofai policies --install --cli goose --scope project
+    failproofai policies --install block-sudo block-rm-rf sanitize-api-keys
+    ```
+  </Step>
+  <Step title="Verificar">
+    ```bash
+    failproofai policies
+    ```
+
+    Muestra todas las políticas, si están habilitadas y cualquier parámetro configurado.
+  </Step>
+  <Step title="Abrir el panel de control">
+    ```bash
+    failproofai
+    ```
+
+    Abre un panel de control local en `http://localhost:8020` donde puedes navegar por las sesiones, inspeccionar llamadas a herramientas y gestionar políticas.
+  </Step>
+  <Step title="Ejecutar tu agente">
+    Inicia Claude Code como de costumbre. Si el agente intenta algo arriesgado, failproofai lo intercepta automáticamente. Déjalo correr sin supervisión y revisa lo que ocurrió en el panel de control.
+  </Step>
+</Steps>
+
+---
+
+## Cómo funcionan las políticas
+
+Cada vez que un agente ejecuta una herramienta, Claude Code llama a failproofai como subproceso:
+
+```text
+Claude Code  →  failproofai --hook PreToolUse  →  reads stdin JSON
+                                                 evaluates policies
+                                                 writes decision to stdout
+```
+
+Cada política devuelve una de tres decisiones:
+
+- **allow** - el agente continúa con normalidad
+- **deny** - la acción es bloqueada y se le indica al agente el motivo
+- **instruct** - se añade contexto adicional al prompt del agente
+
+<Note>
+Las políticas se ejecutan en tu proceso local. No se envía nada a un servicio remoto.
+</Note>
+
+---
+
+## Configurar políticas de equipo con políticas basadas en convenciones
+
+La forma más rápida de establecer estándares de calidad en todo tu equipo es la convención `.failproofai/policies/`. Coloca archivos de política en este directorio y se cargan automáticamente — sin flags, sin cambios de configuración, sin comandos de instalación.
+
+<Steps>
+  <Step title="Crear el directorio de políticas">
+    ```bash
+    mkdir -p .failproofai/policies
+    ```
+  </Step>
+  <Step title="Agregar archivos de política">
+    Copia los ejemplos de inicio o escribe los tuyos propios:
+
+    ```bash
+    cp node_modules/failproofai/examples/convention-policies/*.mjs .failproofai/policies/
+    ```
+
+    O crea uno nuevo:
+
+    ```js
+    // .failproofai/policies/team-policies.mjs
+    import { customPolicies, allow, deny, instruct } from "failproofai";
+
+    customPolicies.add({
+      name: "test-before-commit",
+      match: { events: ["PreToolUse"] },
+      fn: async (ctx) => {
+        if (ctx.toolName !== "Bash") return allow();
+        if (/git\s+commit/.test(ctx.toolInput?.command ?? "")) {
+          return instruct("Run tests before committing.");
+        }
+        return allow();
+      },
+    });
+    ```
+  </Step>
+  <Step title="Confirmar en git">
+    ```bash
+    git add .failproofai/policies/
+    git commit -m "Add team quality policies"
+    ```
+
+    Cada miembro del equipo que tenga failproofai instalado incorporará estas políticas automáticamente. No se necesita configuración por desarrollador.
+  </Step>
+</Steps>
+
+<Tip>
+Confirma `.failproofai/policies/` en tu repositorio para que todo el equipo comparta los mismos estándares. A medida que el equipo descubra nuevos modos de fallo, añade políticas y súbelas — todos reciben la actualización en su próximo `git pull`. Con el tiempo, estas políticas se convierten en un estándar de calidad vivo que sigue mejorando.
+</Tip>
+
+---
+
+## Almacenamiento de datos
+
+Toda la configuración y los registros permanecen en tu máquina:
+
+| Ruta | Qué almacena |
+|------|--------------|
+| `~/.failproofai/policies/local-policies/policies-config.json` | Configuración global de políticas |
+| `~/.failproofai/hook-activity/` | Historial de ejecución de hooks (JSONL paginado) |
+| `~/.failproofai/logs/` | Registros de depuración para errores de hooks personalizados |
+| `.failproofai/policies-config.json` | Configuración por proyecto (confirmada en git) |
+| `.failproofai/policies-config.local.json` | Anulaciones personales (en gitignore) |
+
+---
+
+## Desinstalación
+
+```bash
+failproofai policies --uninstall
+```
+
+Elimina las entradas de hooks de `~/.claude/settings.json`. Los archivos de configuración en `~/.failproofai/` se conservan.
+
+---
+
+## Próximos pasos
+
+<CardGroup cols={2}>
+
+<Card title="Configuración" icon="gear" href="/es/configuration">
+  Ámbitos y formato del archivo de configuración
+</Card>
+
+<Card title="Políticas integradas" icon="shield" href="/es/built-in-policies">
+  Las 26 políticas con sus parámetros
+</Card>
+
+<Card title="Políticas personalizadas" icon="code" href="/es/custom-policies">
+  Escribe tus propias políticas en JavaScript
+</Card>
+
+<Card title="Monitor de agentes" icon="chart-line" href="/es/dashboard">
+  Monitorea sesiones y revisa la actividad de las políticas
+</Card>
+
+</CardGroup>

package/.next/standalone/docs-old/es/introduction.mdx

@@ -0,0 +1,57 @@
+---
+title: "Failproof AI"
+description: "FailproofAI ofrece a los agentes de IA 39 políticas de fallos integradas que detectan bucles, filtraciones de secretos, llamadas a herramientas destructivas y más, todo en una sola instalación."
+---
+
+[![npm weekly downloads](https://img.shields.io/npm/dw/failproofai?style=flat-square&color=2ea44f)](https://www.npmjs.com/package/failproofai)
+
+Hooks y políticas para el **manejo de fallos en IA**, **recuperación ante errores** y **fiabilidad de LLM**. Mantén tus agentes de IA estables y funcionando de forma autónoma en **Claude Code**, **OpenAI Codex**, **GitHub Copilot**, **Cursor Agent**, **OpenCode**, **Pi**, **Hermes**, **OpenClaw**, **Factory Droid**, **Devin CLI**, **Antigravity CLI** y el **Agents SDK**.
+
+Los agentes de IA fallan de maneras predecibles: ejecutan comandos destructivos, filtran secretos, se desvían de sus tareas, quedan atrapados en bucles o hacen push directamente a main. Sin supervisión, los fallos menores se convierten en interrupciones del servicio, credenciales expuestas y trabajo perdido.
+
+FailproofAI resuelve esto mediante **políticas**. Estas reglas se enganchan en cada llamada a herramientas del agente para **detectar fallos**, **mitigarlos** (bloquear, instruir, sanitizar) y **alertarte** cuando algo requiere atención. Un panel de control local te permite revisar cada llamada a herramienta, cada fallo del agente y cada acción de recuperación.
+
+Las transcripciones y la evaluación de políticas permanecen en tu máquina. Los datos solo se envían cuando utilizas explícitamente una función en línea, como recordatorios de auditoría autenticados o invitaciones.
+
+## Primeros pasos
+
+<CardGroup cols={2}>
+
+<Card title="39 políticas integradas" icon="shield" href="/es/built-in-policies">
+  Bloquea comandos destructivos, previene la filtración de secretos, mantiene a los agentes dentro de los límites del proyecto y mucho más. Todo listo desde el primer momento.
+</Card>
+
+<Card title="Políticas personalizadas" icon="code" href="/es/custom-policies">
+  Escribe tus propias reglas en JavaScript con una API sencilla de allow / deny / instruct.
+</Card>
+
+<Card title="Monitor de agentes" icon="chart-line" href="/es/dashboard">
+  Descubre qué hicieron tus agentes mientras no estabas. Explora sesiones, inspecciona llamadas a herramientas y revisa dónde se activaron las políticas.
+</Card>
+
+<Card title="Configuración sencilla" icon="gear" href="/es/configuration">
+  Ajusta cualquier política sin tocar el código. Define listas de permisos, ramas protegidas o umbrales por proyecto o de forma global.
+</Card>
+
+</CardGroup>
+
+## Inicio rápido
+
+<CodeGroup>
+
+```bash npm
+npm install -g failproofai
+```
+
+```bash bun
+bun add -g failproofai
+```
+
+</CodeGroup>
+
+```bash
+failproofai policies --install   # enable policies (or skip — `failproofai` will offer to set them up on first run)
+failproofai                      # launch the dashboard
+```
+
+Consulta la guía de [Primeros pasos](/es/getting-started) para ver el tutorial completo.

package/.next/standalone/docs-old/es/package-aliases.mdx

@@ -0,0 +1,82 @@
+---
+title: Aliases de Paquetes
+description: "Aliases registrados para prevención de typosquatting y cómo funcionan"
+icon: copy
+---
+
+## Paquete oficial
+
+El paquete npm canónico es **`failproofai`**:
+
+```bash
+npm install -g failproofai
+# o
+bun add -g failproofai
+```
+
+---
+
+## Por qué controlamos los nombres de alias
+
+El typosquatting es un ataque común a la cadena de suministro en el que un actor malicioso registra un nombre de paquete que difiere en una sola tecla de uno popular. Los usuarios desprevenidos que escriben mal el comando de instalación terminan ejecutando código controlado por el atacante con acceso total al sistema — exactamente el tipo de amenaza que Failproof AI está diseñado para combatir.
+
+Para eliminar esta superficie de ataque, **registramos de forma preventiva todas las variantes de escritura y formato comunes** de `failproofai` en npm. Ninguno de estos nombres puede ser registrado por un tercero. Cada uno es un proxy ligero que instala y delega al paquete real `failproofai`.
+
+---
+
+## Aliases registrados
+
+**Variantes de formato** — distintas formas de escribir "failproof ai":
+
+| Paquete | Estado |
+|---------|--------|
+| `failproof` | ✅ Publicado |
+| `failproof-ai` | ⏳ Pendiente de aprobación por npm |
+| `fail-proof-ai` | ⏳ Pendiente de aprobación por npm |
+| `failproof_ai` | ⏳ Pendiente de aprobación por npm |
+| `fail_proof_ai` | ⏳ Pendiente de aprobación por npm |
+| `fail-proofai` | ⏳ Pendiente de aprobación por npm |
+
+**Errores tipográficos `failprof*`** — falta una `o` en "proof":
+
+| Paquete | Estado |
+|---------|--------|
+| `failprof` | ✅ Publicado |
+| `failprof-ai` | ✅ Publicado |
+| `failprofai` | ⏳ Pendiente de aprobación por npm |
+| `fail-prof-ai` | ⏳ Pendiente de aprobación por npm |
+| `failprof_ai` | ⏳ Pendiente de aprobación por npm |
+
+**Errores tipográficos `faliproof*`** — `a` e `i` transpuestas:
+
+| Paquete | Estado |
+|---------|--------|
+| `faliproof` | ✅ Publicado |
+| `faliproof-ai` | ✅ Publicado |
+| `faliproofai` | ⏳ Pendiente de aprobación por npm |
+
+> **¿Por qué están pendientes?** La política anti-spam de npm bloquea nombres que, tras eliminar la puntuación y aplicar comprobaciones de similitud, se normalizan a la misma cadena que un paquete existente. Hemos contactado con el soporte de npm para reservar estos nombres con fines de protección contra squatting. Se activarán una vez aprobados.
+
+Puedes verificar que cualquier alias publicado nos pertenece:
+
+```bash
+npm info failproof
+# Busca: "ExosphereHost Inc." en el campo maintainers
+```
+
+---
+
+## Cómo funcionan los aliases
+
+Cada paquete alias:
+
+1. Incluye `failproofai` como dependencia — de modo que el paquete real se instala y su binario queda disponible
+2. Expone un binario con su propio nombre (por ejemplo, `failprof-ai`) que redirige todos los argumentos al binario `failproofai`
+
+El proxy es un script de Node de dos líneas; no contiene lógica adicional, ni llamadas de red, ni recopilación de datos más allá de lo que hace `failproofai` por sí mismo.
+
+---
+
+## Si encuentras un nombre que nos falta
+
+Abre un issue en [failproofai/failproofai](https://github.com/failproofai/failproofai/issues) y lo registraremos.

package/.next/standalone/docs-old/es/testing.mdx

@@ -0,0 +1,260 @@
+---
+title: Pruebas
+description: "Pruebas unitarias, pruebas E2E y utilidades de prueba"
+icon: flask-vial
+---
+
+failproofai cuenta con dos suites de pruebas: **pruebas unitarias** (rápidas, con mocks) y **pruebas end-to-end** (invocaciones reales de subprocesos).
+
+---
+
+## Ejecución de pruebas
+
+```bash
+# Ejecutar todas las pruebas unitarias una vez
+bun run test:run
+
+# Ejecutar pruebas unitarias en modo watch
+bun run test
+
+# Ejecutar pruebas E2E (requiere configuración previa - ver más abajo)
+bun run test:e2e
+
+# Verificar tipos sin compilar
+bunx tsc --noEmit
+
+# Linting
+bun run lint
+```
+
+---
+
+## Pruebas unitarias
+
+Las pruebas unitarias se encuentran en `__tests__/` y usan [Vitest](https://vitest.dev) con `jsdom`.
+
+```text
+__tests__/
+  hooks/
+    builtin-policies.test.ts      # Lógica de políticas para cada builtin
+    hooks-config.test.ts          # Carga de configuración y fusión de scopes
+    policy-evaluator.test.ts      # Inyección de parámetros y orden de evaluación
+    custom-hooks-registry.test.ts # Registro globalThis: add/get/clear
+    custom-hooks-loader.test.ts   # Cargador ESM, importaciones transitivas, manejo de errores
+    manager.test.ts               # Operaciones install/remove/list
+  components/
+    sessions-list.test.tsx        # Componente de lista de sesiones
+    project-list.test.tsx         # Componente de lista de proyectos
+    ...
+  lib/
+    logger.test.ts
+    paths.test.ts
+    date-filters.test.ts
+    telemetry.test.ts
+    ...
+  actions/
+    get-hooks-config.test.ts
+    get-hook-activity.test.ts
+    ...
+  contexts/
+    ThemeContext.test.tsx
+    AutoRefreshContext.test.tsx
+```
+
+### Cómo escribir una prueba unitaria de política
+
+```typescript
+import { describe, it, expect, beforeEach } from "vitest";
+import { getBuiltinPolicies } from "../../src/hooks/builtin-policies";
+import { allow, deny } from "../../src/hooks/policy-types";
+
+describe("block-sudo", () => {
+  const policy = getBuiltinPolicies().find((p) => p.name === "block-sudo")!;
+
+  it("denies sudo commands", () => {
+    const ctx = {
+      eventType: "PreToolUse" as const,
+      payload: {},
+      toolName: "Bash",
+      toolInput: { command: "sudo apt install nodejs" },
+      params: { allowPatterns: [] },
+    };
+    expect(policy.fn(ctx)).toEqual(deny("sudo command blocked by failproofai"));
+  });
+
+  it("allows non-sudo commands", () => {
+    const ctx = {
+      eventType: "PreToolUse" as const,
+      payload: {},
+      toolName: "Bash",
+      toolInput: { command: "ls -la" },
+      params: { allowPatterns: [] },
+    };
+    expect(policy.fn(ctx)).toEqual(allow());
+  });
+
+  it("allows patterns in allowPatterns", () => {
+    const ctx = {
+      eventType: "PreToolUse" as const,
+      payload: {},
+      toolName: "Bash",
+      toolInput: { command: "sudo systemctl status nginx" },
+      params: { allowPatterns: ["sudo systemctl status"] },
+    };
+    expect(policy.fn(ctx)).toEqual(allow());
+  });
+});
+```
+
+---
+
+## Pruebas end-to-end
+
+Las pruebas E2E invocan el binario real de `failproofai` como subproceso, envían un payload JSON por stdin y verifican la salida en stdout junto con el código de salida. Esto prueba la integración completa que utiliza Claude Code.
+
+### Configuración
+
+Las pruebas E2E ejecutan el binario directamente desde el código fuente del repositorio. Antes de la primera ejecución, compila el bundle CJS que usan los archivos de hooks personalizados cuando importan desde `'failproofai'`:
+
+```bash
+bun build src/index.ts --outdir dist --target node --format cjs
+```
+
+Luego ejecuta las pruebas:
+
+```bash
+bun run test:e2e
+```
+
+Reconstruye `dist/` cada vez que modifiques la API pública de hooks (`src/hooks/custom-hooks-registry.ts`, `src/hooks/policy-helpers.ts` o `src/hooks/policy-types.ts`).
+
+### Estructura de las pruebas E2E
+
+```text
+__tests__/e2e/
+  helpers/
+    hook-runner.ts      # Lanza el binario, envía el JSON del payload, captura código de salida + stdout + stderr
+    fixture-env.ts      # Directorios temporales aislados por prueba con archivos de configuración
+    payloads.ts         # Fábricas de payloads precisos para cada tipo de evento de Claude
+  hooks/
+    builtin-policies.e2e.test.ts   # Cada política builtin con subproceso real
+    custom-hooks.e2e.test.ts       # Carga y evaluación de hooks personalizados
+    config-scopes.e2e.test.ts      # Fusión de configuración entre scopes: project/local/global
+    policy-params.e2e.test.ts      # Inyección de parámetros para cada política parametrizada
+```
+
+### Uso de los helpers E2E
+
+**`FixtureEnv`** - entorno aislado por prueba:
+
+```typescript
+import { createFixtureEnv } from "../helpers/fixture-env";
+
+const env = createFixtureEnv();
+// env.cwd    - directorio temporal; pásalo como payload.cwd para cargar .failproofai/policies-config.json
+// env.home   - directorio home aislado; evita que se filtre el ~/.failproofai real
+
+env.writeConfig({
+  enabledPolicies: ["block-sudo"],
+  policyParams: {
+    "block-sudo": { allowPatterns: ["sudo systemctl status"] },
+  },
+});
+```
+
+`createFixtureEnv()` registra la limpieza con `afterEach` automáticamente.
+
+**`runHook`** - invoca el binario:
+
+```typescript
+import { runHook } from "../helpers/hook-runner";
+import { Payloads } from "../helpers/payloads";
+
+const result = await runHook(
+  "PreToolUse",
+  Payloads.preToolUse.bash("sudo apt install nodejs", env.cwd),
+  { homeDir: env.home }
+);
+
+expect(result.exitCode).toBe(0);
+expect(result.parsed?.hookSpecificOutput?.permissionDecision).toBe("deny");
+```
+
+**`Payloads`** - fábricas de payloads listas para usar:
+
+```typescript
+Payloads.preToolUse.bash(command, cwd)
+Payloads.preToolUse.write(filePath, content, cwd)
+Payloads.preToolUse.read(filePath, cwd)
+Payloads.postToolUse.bash(command, output, cwd)
+Payloads.postToolUse.read(filePath, content, cwd)
+Payloads.notification(message, cwd)
+Payloads.stop(cwd)
+```
+
+### Cómo escribir una prueba E2E
+
+```typescript
+import { describe, it, expect } from "vitest";
+import { createFixtureEnv } from "../helpers/fixture-env";
+import { runHook } from "../helpers/hook-runner";
+import { Payloads } from "../helpers/payloads";
+
+describe("block-rm-rf (E2E)", () => {
+  it("denies rm -rf", async () => {
+    const env = createFixtureEnv();
+    env.writeConfig({ enabledPolicies: ["block-rm-rf"] });
+
+    const result = await runHook(
+      "PreToolUse",
+      Payloads.preToolUse.bash("rm -rf /", env.cwd),
+      { homeDir: env.home }
+    );
+
+    expect(result.exitCode).toBe(0);
+    expect(result.parsed?.hookSpecificOutput?.permissionDecision).toBe("deny");
+  });
+
+  it("allows non-recursive rm", async () => {
+    const env = createFixtureEnv();
+    env.writeConfig({ enabledPolicies: ["block-rm-rf"] });
+
+    const result = await runHook(
+      "PreToolUse",
+      Payloads.preToolUse.bash("rm /tmp/file.txt", env.cwd),
+      { homeDir: env.home }
+    );
+
+    expect(result.exitCode).toBe(0);
+    expect(result.stdout).toBe("");  // allow → stdout vacío
+  });
+});
+```
+
+### Formatos de respuesta E2E
+
+| Decisión | Código de salida | stdout |
+|----------|-----------------|--------|
+| `PreToolUse` deny | `0` | `{"hookSpecificOutput":{"permissionDecision":"deny","permissionDecisionReason":"..."}}` |
+| `PostToolUse` deny | `0` | `{"hookSpecificOutput":{"additionalContext":"Blocked ... because: ..."}}` |
+| Instruct (distinto de Stop) | `0` | `{"hookSpecificOutput":{"additionalContext":"Instruction from failproofai: ..."}}` |
+| Stop instruct | `2` | stdout vacío; motivo en stderr |
+| Allow | `0` | cadena vacía |
+
+### Configuración de Vitest
+
+Las pruebas E2E usan `vitest.config.e2e.mts` con:
+
+- `environment: "node"` - no se necesitan globales de navegador
+- `pool: "forks"` - aislamiento real de procesos (las pruebas lanzan subprocesos)
+- `testTimeout: 20_000` - 20s por prueba (arranque del binario + evaluación del hook)
+
+El pool `forks` es importante: los workers basados en hilos comparten `globalThis`, lo que puede interferir con las pruebas que lanzan subprocesos. Los forks basados en procesos evitan este problema.
+
+---
+
+## CI
+
+La ejecución completa de CI (`bun run lint && bunx tsc --noEmit && bun run test:run && bun run build`) debe pasar antes de hacer merge. La suite E2E se ejecuta como un job de CI independiente en paralelo.
+
+Consulta [Contributing](../CONTRIBUTING.md) para ver el checklist completo previo al merge.