failproofai 1.0.1-beta.0 → 1.0.1

package/.next/standalone/docs-old/pt-br/getting-started.mdx

@@ -0,0 +1,199 @@
+---
+title: Primeiros passos
+description: "Instale o failproofai, ative as políticas e deixe seus agentes funcionando com confiabilidade"
+icon: rocket
+---
+
+## Requisitos
+
+- **Node.js** >= 20.9.0
+- **Bun** >= 1.3.0 (opcional - necessário apenas para compilar a partir do código-fonte)
+
+---
+
+## Instalação
+
+<CodeGroup>
+
+```bash npm
+npm install -g failproofai
+```
+
+```bash bun
+bun add -g failproofai
+```
+
+</CodeGroup>
+
+---
+
+## Início rápido
+
+<Steps>
+  <Step title="Ativar políticas">
+    Políticas são regras que são executadas antes e depois de cada chamada de ferramenta do agente. Elas interceptam comandos destrutivos, vazamento de segredos e outros modos de falha antes que causem danos.
+
+    ```bash
+    failproofai policies --install
+    ```
+
+    Isso insere entradas de hook nos CLIs de agente instalados (o `~/.claude/settings.json` do Claude Code, o `~/.codex/hooks.json` do OpenAI Codex, o `~/.copilot/hooks/failproofai.json` do GitHub Copilot CLI, o `~/.cursor/hooks.json` do Cursor Agent, o shim de plugin gerado pelo OpenCode em `~/.config/opencode/plugins/failproofai.mjs` mais uma entrada de registro no array `plugin` do `~/.config/opencode/opencode.json`, o `~/.pi/agent/settings.json` do Pi, o `~/.hermes/config.yaml` do Hermes, o `~/.openclaw/openclaw.json` do OpenClaw, o `~/.factory/hooks.json` do Factory Droid, o `~/.config/devin/config.json` do Devin CLI, o `~/.gemini/config/hooks.json` do Antigravity CLI, ou o diretório de plugin autodescoberto do Goose em `~/.agents/plugins/failproofai/hooks/hooks.json`). Quando mais de um estiver presente, você será solicitado a escolher; passe `--cli claude codex copilot cursor opencode pi hermes openclaw factory devin antigravity goose` (qualquer subconjunto) para pular a solicitação.
+
+    O suporte ao GitHub Copilot CLI, Cursor Agent, OpenCode e Pi está em **beta** — instale com `--cli copilot`, `--cli cursor`, `--cli opencode` ou `--cli pi`. O Hermes (hermes-agent, um gateway Slack/Telegram) é instalado no escopo do usuário com `--cli hermes` e é **também** uma fonte de auditoria offline. O OpenClaw (gateway openclaw, um assistente multicanal auto-hospedado) é instalado no escopo do usuário com `--cli openclaw` — a aplicação de políticas ocorre por meio de seus hooks de plugin em processo (`before_agent_finalize` é uma barreira real de fim de turno, portanto os built-ins `require-*-before-stop` são aplicados) — e é **também** uma fonte de auditoria offline. O Factory Droid (`droid`) é instalado com `--cli factory` (escopo de usuário e projeto) e é **também** uma fonte de auditoria offline. O Devin CLI (`devin`, Cognition) é instalado com `--cli devin` (escopo de usuário e projeto) e é **também** uma fonte de auditoria offline. O Antigravity CLI (`agy`) é instalado com `--cli antigravity` (escopo de usuário e projeto) e é **também** uma fonte de auditoria offline. O Goose (codinome goose, Block) é instalado com `--cli goose` (escopo de usuário e projeto) — o instalador simplesmente cria um diretório de plugin em `~/.agents/plugins/failproofai/` que o Goose autodescobre, e é **também** uma fonte de auditoria 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
+    ```
+
+    Exibe todas as políticas, se estão habilitadas e quaisquer parâmetros configurados.
+  </Step>
+  <Step title="Abrir o painel">
+    ```bash
+    failproofai
+    ```
+
+    Abre um painel local em `http://localhost:8020` onde você pode navegar por sessões, inspecionar chamadas de ferramentas e gerenciar políticas.
+  </Step>
+  <Step title="Executar seu agente">
+    Inicie o Claude Code normalmente. Se o agente tentar algo arriscado, o failproofai intercepta automaticamente. Deixe-o rodando sem supervisão e revise o que aconteceu no painel.
+  </Step>
+</Steps>
+
+---
+
+## Como as políticas funcionam
+
+Sempre que um agente executa uma ferramenta, o Claude Code chama o failproofai como subprocesso:
+
+```text
+Claude Code  →  failproofai --hook PreToolUse  →  reads stdin JSON
+                                                 evaluates policies
+                                                 writes decision to stdout
+```
+
+Cada política retorna uma de três decisões:
+
+- **allow** - o agente prossegue normalmente
+- **deny** - a ação é bloqueada e o agente é informado do motivo
+- **instruct** - contexto adicional é inserido no prompt do agente
+
+<Note>
+As políticas são executadas em seu processo local. Nada é enviado para um serviço remoto.
+</Note>
+
+---
+
+## Configure políticas de equipe com políticas baseadas em convenção
+
+A maneira mais rápida de estabelecer padrões de qualidade em toda a sua equipe é a convenção `.failproofai/policies/`. Coloque arquivos de política neste diretório e eles serão carregados automaticamente — sem flags, sem alterações de configuração, sem comandos de instalação.
+
+<Steps>
+  <Step title="Criar o diretório de políticas">
+    ```bash
+    mkdir -p .failproofai/policies
+    ```
+  </Step>
+  <Step title="Adicionar arquivos de política">
+    Copie os exemplos iniciais ou escreva os seus próprios:
+
+    ```bash
+    cp node_modules/failproofai/examples/convention-policies/*.mjs .failproofai/policies/
+    ```
+
+    Ou crie um novo:
+
+    ```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="Enviar para o git">
+    ```bash
+    git add .failproofai/policies/
+    git commit -m "Add team quality policies"
+    ```
+
+    Todos os membros da equipe que têm o failproofai instalado recebem essas políticas automaticamente. Nenhuma configuração por desenvolvedor é necessária.
+  </Step>
+</Steps>
+
+<Tip>
+Faça commit de `.failproofai/policies/` no seu repositório para que toda a equipe compartilhe os mesmos padrões. À medida que sua equipe descobre novos modos de falha, adicione políticas e faça push — todos recebem a atualização no próximo `git pull`. Com o tempo, essas políticas se tornam um padrão de qualidade vivo que continua melhorando.
+</Tip>
+
+---
+
+## Armazenamento de dados
+
+Todas as configurações e logs permanecem na sua máquina:
+
+| Caminho | O que armazena |
+|------|----------------|
+| `~/.failproofai/policies/local-policies/policies-config.json` | Configuração global de políticas |
+| `~/.failproofai/hook-activity/` | Histórico de execução de hooks (JSONL paginado) |
+| `~/.failproofai/logs/` | Logs de depuração para erros de hooks personalizados |
+| `.failproofai/policies-config.json` | Configuração por projeto (versionada) |
+| `.failproofai/policies-config.local.json` | Substituições pessoais (ignoradas pelo git) |
+
+---
+
+## Desinstalação
+
+```bash
+failproofai policies --uninstall
+```
+
+Remove as entradas de hook do `~/.claude/settings.json`. Os arquivos de configuração em `~/.failproofai/` são mantidos.
+
+---
+
+## Próximos passos
+
+<CardGroup cols={2}>
+
+<Card title="Configuração" icon="gear" href="/pt-br/configuration">
+  Escopos e formato dos arquivos de configuração
+</Card>
+
+<Card title="Políticas integradas" icon="shield" href="/pt-br/built-in-policies">
+  Todas as 26 políticas com seus parâmetros
+</Card>
+
+<Card title="Políticas personalizadas" icon="code" href="/pt-br/custom-policies">
+  Escreva suas próprias políticas em JavaScript
+</Card>
+
+<Card title="Monitor de agente" icon="chart-line" href="/pt-br/dashboard">
+  Monitore sessões e revise a atividade das políticas
+</Card>
+
+</CardGroup>

package/.next/standalone/docs-old/pt-br/introduction.mdx

@@ -0,0 +1,57 @@
+---
+title: "Failproof AI"
+description: "FailproofAI oferece aos agentes de IA 39 políticas de falha integradas que detectam loops, vazamentos de segredos, chamadas de ferramentas destrutivas e muito mais em uma única instalação."
+---
+
+[![npm weekly downloads](https://img.shields.io/npm/dw/failproofai?style=flat-square&color=2ea44f)](https://www.npmjs.com/package/failproofai)
+
+Hooks e políticas para **tratamento de falhas de IA**, **recuperação de erros** e **confiabilidade de LLM**. Mantenha seus agentes de IA confiáveis e funcionando de forma autônoma no **Claude Code**, **OpenAI Codex**, **GitHub Copilot**, **Cursor Agent**, **OpenCode**, **Pi**, **Hermes**, **OpenClaw**, **Factory Droid**, **Devin CLI**, **Antigravity CLI** e no **Agents SDK**.
+
+Agentes de IA falham de maneiras previsíveis. Eles executam comandos destrutivos, vazam segredos, desviam de suas tarefas, ficam presos em loops ou fazem push diretamente para a branch main. Sem supervisão, pequenas falhas se transformam em indisponibilidades, credenciais expostas e trabalho perdido.
+
+O FailproofAI resolve isso com **políticas**. Essas regras se conectam a cada chamada de ferramenta do agente para **detectar falhas**, **mitigá-las** (bloquear, instruir, sanitizar) e **alertar você** quando algo precisa de atenção. Um painel local permite revisar cada chamada de ferramenta, falha de agente e ação de recuperação depois.
+
+Transcrições e avaliações de políticas ficam na sua máquina. Os dados são enviados apenas quando você usa explicitamente um recurso online, como lembretes de auditoria autenticados ou convites.
+
+## Primeiros passos
+
+<CardGroup cols={2}>
+
+<Card title="39 políticas integradas" icon="shield" href="/pt-br/built-in-policies">
+  Bloqueie comandos destrutivos, evite vazamentos de segredos, mantenha os agentes dentro dos limites do projeto e muito mais. Tudo pronto para uso.
+</Card>
+
+<Card title="Políticas personalizadas" icon="code" href="/pt-br/custom-policies">
+  Escreva suas próprias regras em JavaScript com uma API simples de allow / deny / instruct.
+</Card>
+
+<Card title="Monitor de agentes" icon="chart-line" href="/pt-br/dashboard">
+  Veja o que seus agentes fizeram enquanto você estava ausente. Navegue por sessões, inspecione chamadas de ferramentas e revise onde as políticas foram acionadas.
+</Card>
+
+<Card title="Configuração simples" icon="gear" href="/pt-br/configuration">
+  Ajuste qualquer política sem escrever código. Defina allowlists, branches protegidas ou limites por projeto ou globalmente.
+</Card>
+
+</CardGroup>
+
+## Início 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
+```
+
+Consulte o guia de [Primeiros passos](/pt-br/getting-started) para o passo a passo completo.

package/.next/standalone/docs-old/pt-br/package-aliases.mdx

@@ -0,0 +1,82 @@
+---
+title: Aliases de Pacote
+description: "Aliases registrados para prevenção de typosquatting e como funcionam"
+icon: copy
+---
+
+## Pacote oficial
+
+O pacote npm canônico é **`failproofai`**:
+
+```bash
+npm install -g failproofai
+# or
+bun add -g failproofai
+```
+
+---
+
+## Por que detemos os nomes de alias
+
+Typosquatting é um ataque comum à cadeia de suprimentos de software, onde um agente malicioso registra um nome de pacote que difere por apenas um caractere de um pacote popular. Usuários desavisados que digitam incorretamente o comando de instalação acabam executando código controlado pelo atacante com acesso total ao sistema — exatamente o tipo de ameaça que o Failproof AI foi projetado para combater.
+
+Para eliminar essa superfície de ataque, **detemos preventivamente todas as grafias incorretas comuns e variantes de formatação** de `failproofai` no npm. Nenhum desses nomes pode ser registrado por terceiros. Cada um é um proxy simples que instala e delega para o pacote real `failproofai`.
+
+---
+
+## Aliases registrados
+
+**Variantes de formatação** — diferentes formas de escrever "failproof ai":
+
+| Pacote | Status |
+|--------|--------|
+| `failproof` | ✅ Publicado |
+| `failproof-ai` | ⏳ Aguardando aprovação do npm |
+| `fail-proof-ai` | ⏳ Aguardando aprovação do npm |
+| `failproof_ai` | ⏳ Aguardando aprovação do npm |
+| `fail_proof_ai` | ⏳ Aguardando aprovação do npm |
+| `fail-proofai` | ⏳ Aguardando aprovação do npm |
+
+**Erros de digitação `failprof*`** — faltando um `o` em "proof":
+
+| Pacote | Status |
+|--------|--------|
+| `failprof` | ✅ Publicado |
+| `failprof-ai` | ✅ Publicado |
+| `failprofai` | ⏳ Aguardando aprovação do npm |
+| `fail-prof-ai` | ⏳ Aguardando aprovação do npm |
+| `failprof_ai` | ⏳ Aguardando aprovação do npm |
+
+**Erros de digitação `faliproof*`** — `a` e `i` invertidos:
+
+| Pacote | Status |
+|--------|--------|
+| `faliproof` | ✅ Publicado |
+| `faliproof-ai` | ✅ Publicado |
+| `faliproofai` | ⏳ Aguardando aprovação do npm |
+
+> **Por que aguardando aprovação?** A política de prevenção de spam do npm bloqueia nomes que são normalizados para a mesma string de um pacote existente após remoção de pontuação e verificações de similaridade. Entramos em contato com o suporte do npm para reservar esses nomes com fins anti-typosquatting. Eles serão ativados após aprovação.
+
+Você pode verificar que qualquer alias publicado pertence a nós:
+
+```bash
+npm info failproof
+# Look for: "ExosphereHost Inc." in the maintainers field
+```
+
+---
+
+## Como os aliases funcionam
+
+Cada pacote de alias:
+
+1. Lista `failproofai` como dependência — assim o pacote real é instalado e seu binário fica disponível
+2. Expõe um binário correspondente ao seu próprio nome (ex.: `failprof-ai`) que repassa todos os argumentos para o binário `failproofai`
+
+O proxy é um script Node de duas linhas; não há lógica adicional, chamadas de rede nem coleta de dados além do que o próprio `failproofai` já realiza.
+
+---
+
+## Se você encontrar um nome que esquecemos
+
+Abra uma issue em [failproofai/failproofai](https://github.com/failproofai/failproofai/issues) e nós o registraremos.

package/.next/standalone/docs-old/pt-br/testing.mdx

@@ -0,0 +1,260 @@
+---
+title: Testes
+description: "Testes unitários, testes E2E e utilitários de teste"
+icon: flask-vial
+---
+
+failproofai possui dois conjuntos de testes: **testes unitários** (rápidos, com mocks) e **testes end-to-end** (invocações reais de subprocessos).
+
+---
+
+## Executando os testes
+
+```bash
+# Executar todos os testes unitários uma vez
+bun run test:run
+
+# Executar testes unitários em modo watch
+bun run test
+
+# Executar testes E2E (requer configuração — veja abaixo)
+bun run test:e2e
+
+# Verificar tipos sem compilar
+bunx tsc --noEmit
+
+# Lint
+bun run lint
+```
+
+---
+
+## Testes unitários
+
+Os testes unitários ficam em `__tests__/` e utilizam [Vitest](https://vitest.dev) com `jsdom`.
+
+```text
+__tests__/
+  hooks/
+    builtin-policies.test.ts      # Lógica de políticas para cada builtin
+    hooks-config.test.ts          # Carregamento de configuração e mesclagem de escopos
+    policy-evaluator.test.ts      # Injeção de parâmetros e ordem de avaliação
+    custom-hooks-registry.test.ts # Registro globalThis: add/get/clear
+    custom-hooks-loader.test.ts   # Loader ESM, imports transitivos, tratamento de erros
+    manager.test.ts               # Operações de install/remove/list
+  components/
+    sessions-list.test.tsx        # Componente de lista de sessões
+    project-list.test.tsx         # Componente de lista de projetos
+    ...
+  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
+```
+
+### Escrevendo um teste unitário 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());
+  });
+});
+```
+
+---
+
+## Testes end-to-end
+
+Os testes E2E invocam o binário real do `failproofai` como subprocesso, enviam um payload JSON via stdin e validam a saída no stdout e o código de saída. Isso testa o caminho completo de integração que o Claude Code utiliza.
+
+### Configuração
+
+Os testes E2E executam o binário diretamente a partir do código-fonte do repositório. Antes da primeira execução, compile o bundle CJS que os arquivos de hook customizados utilizam ao importar de `'failproofai'`:
+
+```bash
+bun build src/index.ts --outdir dist --target node --format cjs
+```
+
+Em seguida, execute os testes:
+
+```bash
+bun run test:e2e
+```
+
+Recompile o `dist/` sempre que alterar a API pública de hooks (`src/hooks/custom-hooks-registry.ts`, `src/hooks/policy-helpers.ts` ou `src/hooks/policy-types.ts`).
+
+### Estrutura dos testes E2E
+
+```text
+__tests__/e2e/
+  helpers/
+    hook-runner.ts      # Inicia o binário, envia o payload JSON, captura código de saída + stdout + stderr
+    fixture-env.ts      # Diretórios temporários isolados por teste com arquivos de configuração
+    payloads.ts         # Fábricas de payload fiéis ao Claude para cada tipo de evento
+  hooks/
+    builtin-policies.e2e.test.ts   # Cada política builtin com subprocesso real
+    custom-hooks.e2e.test.ts       # Carregamento e avaliação de hooks customizados
+    config-scopes.e2e.test.ts      # Mesclagem de configuração entre escopos project/local/global
+    policy-params.e2e.test.ts      # Injeção de parâmetros para cada política parametrizada
+```
+
+### Usando os utilitários E2E
+
+**`FixtureEnv`** — ambiente isolado por teste:
+
+```typescript
+import { createFixtureEnv } from "../helpers/fixture-env";
+
+const env = createFixtureEnv();
+// env.cwd    - diretório temporário; passe como payload.cwd para carregar .failproofai/policies-config.json
+// env.home   - diretório home isolado; nenhum dado real de ~/.failproofai vaza para os testes
+
+env.writeConfig({
+  enabledPolicies: ["block-sudo"],
+  policyParams: {
+    "block-sudo": { allowPatterns: ["sudo systemctl status"] },
+  },
+});
+```
+
+`createFixtureEnv()` registra a limpeza via `afterEach` automaticamente.
+
+**`runHook`** — invoca o binário:
+
+```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 payload prontas para uso:
+
+```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)
+```
+
+### Escrevendo um teste 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 vazio
+  });
+});
+```
+
+### Formatos de resposta E2E
+
+| Decisão | Código de saída | stdout |
+|----------|-----------|--------|
+| `PreToolUse` deny | `0` | `{"hookSpecificOutput":{"permissionDecision":"deny","permissionDecisionReason":"..."}}` |
+| `PostToolUse` deny | `0` | `{"hookSpecificOutput":{"additionalContext":"Blocked ... because: ..."}}` |
+| Instruct (non-Stop) | `0` | `{"hookSpecificOutput":{"additionalContext":"Instruction from failproofai: ..."}}` |
+| Stop instruct | `2` | stdout vazio; motivo no stderr |
+| Allow | `0` | string vazia |
+
+### Configuração do Vitest
+
+Os testes E2E utilizam `vitest.config.e2e.mts` com:
+
+- `environment: "node"` — sem globals de browser
+- `pool: "forks"` — isolamento real de processos (os testes iniciam subprocessos)
+- `testTimeout: 20_000` — 20s por teste (inicialização do binário + avaliação do hook)
+
+O pool `forks` é importante: workers baseados em threads compartilham `globalThis`, o que pode interferir em testes que iniciam subprocessos. Forks baseados em processos evitam esse problema.
+
+---
+
+## CI
+
+A execução completa de CI (`bun run lint && bunx tsc --noEmit && bun run test:run && bun run build`) deve passar antes de qualquer merge. O conjunto de testes E2E é executado como um job de CI separado, em paralelo.
+
+Consulte [Contributing](../CONTRIBUTING.md) para o checklist completo de pré-merge.

package/.next/standalone/docs-old/ru/agenteye/alerts.mdx

@@ -0,0 +1,63 @@
+---
+title: "Оповещения"
+description: "Узнайте о проблеме в тот момент, когда она возникает, в канале, который уже смотрит ваша команда, вместо того чтобы услышать об этом от клиента."
+---
+
+
+Узнайте о проблеме в тот момент, когда она возникает, в канале, который уже смотрит ваша команда, вместо того чтобы услышать об этом от клиента. Установите правило один раз, и Failproof AI Observability будет проверять его по расписанию, затем отправит вам уведомление по электронной почте, Slack, webhook или прямо в панель управления.
+
+![Страница оповещений: сетка карточек правил оповещений, каждая из которых показывает триггер, окно оценки, каналы и значок серьезности (информация, предупреждение или критический уровень)](/agenteye/images/alerts.png)
+*Все правила оповещений с первого взгляда: что они контролируют, как часто, куда отправляются уведомления и как срочны.*
+
+## Узнайте о проблемах прежде, чем о них узнают пользователи
+
+Прекратите обновлять панель управления в надежде поймать регрессию. Установите оповещение для любого сигнала, о котором вы хотели бы узнать даже когда никто не смотрит, и доставьте его туда, где уже находится ваша команда:
+
+- **По электронной почте** тем, кому нужно знать.
+- **В Slack** с расширенным сообщением и кнопкой, которая прямо переводит на инцидент.
+- **По webhook** в виде JSON POST для PagerDuty, Opsgenie или собственной конечной точки с опциональной сигнатурой, чтобы получатель мог доверять источнику.
+- **В панели управления** — по умолчанию без уведомлений для тех случаев, когда вы настраиваете правило и еще не хотите никого беспокоить.
+
+Прикрепите любую комбинацию к одному правилу, и его серьезность (информация, предупреждение или критический уровень) будет передана вместе, чтобы срочные оповещения выглядели как срочные.
+
+## Создавайте правило в форме, а не в JSON
+
+Вы описываете, что означает «сбой», в форме, а Failproof AI Observability создает базовое правило за вас. JSON спецификация — это просто то, что создает эта форма под капотом, поэтому вы можете его прочитать, чтобы понять правило, но редко вводите его вручную.
+
+![Форма нового оповещения: имя и описание, переключатель включения и выбор триггера с предложениями порога метрики, пользовательского SQL, оценки оценивания, составного оценивания и условий для каждого события](/agenteye/images/alert-new.png)
+*Выберите триггер и форма заменит нужные поля; нажмите Сохранить.*
+
+Быстрый путь прост: дайте имя, выберите **триггер** (что контролировать), установите **пороговое значение и окно** (насколько плохо, в течение какого времени), прикрепите по крайней мере один **канал**, затем **Сохраните** и нажмите **Тест**, чтобы отправить синтетическое уведомление и подтвердить, что все назначения настроены правильно. Под капотом это создает небольшую спецификацию вроде:
+
+```json
+{ "metric": "p95_latency_ms", "op": ">", "value": 5000, "window_secs": 900 }
+```
+
+Вы не ограничены одним видом сигнала. Выберите триггер, который соответствует тому, как вы думаете об ошибке:
+
+| Триггер | Срабатывает, когда |
+|---|---|
+| **Порог метрики** | заданная метрика (частота ошибок, задержка p95 или p99, количество событий или ошибок, трата токенов) пересекает вашу линию в течение окна |
+| **Пользовательский SQL** | ваш собственный запрос только для чтения возвращает строку, или вычисленное им значение пересекает пороговое значение |
+| **Оценка оценивания** | среднее значение оценки оценивающего (например, галлюцинация) пересекает пороговое значение |
+| **Составное оценивание** | несколько проверок оценки объединяются логикой any, all или at-least-N, чтобы поймать регрессию, которая проявляется только в разных оценках |
+| **Для каждого события** | приходит одно соответствующее событие: конкретный агент, конкретный тип ошибки или подстрока сообщения |
+
+Уже смотрите на сбой на [странице Ошибок](/ru/agenteye/error-tracking)? Каждая строка там имеет кнопку **+ оповещение**, которая открывает эту же форму предварительно заполненную, чтобы поймать эту точную ошибку снова, так что инцидент, который вы только что разобрали, станет тем, который вас предупредит в следующий раз.
+
+**Где это найти:** Оповещения находятся по адресу `/<org-slug>/alerts`. Создание, редактирование, удаление и тестирование правил требует **`alerts:write`**; `alerts:read` достаточно для просмотра. Выбор получателя показывает членов вашей организации по имени, поэтому вы можете отправить уведомление человеку, не выходя из формы.
+
+## Уведомляй меня только когда это действительно важно
+
+Одно плохое измерение не должно вас будить. Фильтр шума **M из N** контролирует, сколько из последних нескольких проверок должны не пройти, прежде чем оповещение действительно вас уведомит. Установите его на **3 из 5**, и правило срабатывает только после того, как оно нарушено в трех из последних пяти проверок, так что дрожащий сигнал прекращает ложные тревоги; оставьте значение по умолчанию **1 из 1**, чтобы срабатывать при первом нарушении. Вы также выбираете, как часто запускается правило, из предустановок 1m, 5m, 15m и 1h, подобранных в соответствии с тем, насколько быстро движется сигнал.
+
+## Что происходит, когда срабатывает оповещение
+
+Нарушение открывает **инцидент** и уведомляет ваши каналы один раз. После этого ваша команда подтверждает его, назначает владельца, обсуждает и разрешает, все с чистой атрибутированной записью. Этот рабочий процесс сортировки имеет свой собственный дом: см. [Инциденты](/ru/agenteye/incidents).
+
+## Связанное
+
+- [Инциденты](/ru/agenteye/incidents): отслеживайте срабатывающее оповещение от открытия до подтверждения до разрешения.
+- [Отслеживание ошибок](/ru/agenteye/error-tracking): группируйте ошибки агентов и повысьте одну до оповещения в один клик.
+- [Панели управления](/ru/agenteye/dashboards): смотрите общие доски, из которых берутся пороги, для которых вы устанавливаете оповещения.
+- [CLI и агенты](/ru/agenteye/cli-and-agents): создавайте оповещения и подтверждайте инциденты из терминала, или встраивайте их в CI.