jarvis-ai-framework 1.0.0

package/rules/engineering/rpa/eng.rpa-rules.md

@@ -0,0 +1,230 @@
+> **Applies to:** HUB: BACKEND | POSITION: all | AREA: ENGINEERING | SQUAD: all
+
+# Eng RPA Rules — Padrões de Arquitetura e Código para Robôs de Automação
+
+## Objetivo
+
+Definir padrões de arquitetura, estrutura de projeto, resiliência, observabilidade e segurança
+para robôs de automação RPA. Toda implementação nova deve seguir estas regras.
+
+---
+
+## 0. Princípios Fundamentais
+
+### HTTP-first
+
+Sempre tentar quebrar o site via requisição HTTP antes de recorrer ao browser.
+Browser é mais lento, frágil e custoso — só usar quando HTTP não for viável.
+
+1. Inspecionar as requests de rede do fluxo alvo (DevTools, Playwright MCP, CLI codegen)
+2. Se existir API ou endpoint HTTP → implementar sem browser
+3. Só partir para browser se renderização JS for obrigatória ou não houver API exposta
+
+### Infraestrutura Anti-bot é Pré-requisito Compartilhado
+
+Captcha solving e proxy rotation são recursos de infraestrutura do projeto — **não implementar do zero por robô**.
+
+- Antes de criar um robô novo, verificar se esses serviços já existem no projeto
+- Se não existirem, escalar para o TL — o robô não deve ser iniciado sem essa infraestrutura quando o sistema-alvo exigir
+- Cada robô consome a infraestrutura existente, nunca a reimplementa
+
+---
+
+## 1. Estrutura de Projeto
+
+### Localização dos Robôs
+
+```
+src/
+  robots/
+    {robot-tag}/
+      {robot-tag}.robot.ts       ← classe principal do robô
+      {robot-tag}.types.ts       ← tipos e interfaces
+      {robot-tag}.config.ts      ← configurações (sem credenciais hardcodadas)
+      {robot-tag}.spec.ts        ← testes unitários (mocks de browser/HTTP)
+```
+
+### Nomenclatura
+
+- `{robot-tag}` sempre em `kebab-case` (ex: `consulta-orgao`, `extrator-dados`)
+- Classe do robô: `{RobotTag}Robot` em PascalCase (ex: `ConsultaOrgaoRobot`)
+- Método principal: `execute(input: Input): Promise<Output>`
+- Métodos internos de fase: `_phaseNome()` — prefixo `_` para métodos privados de fase
+
+---
+
+## 2. Resiliência
+
+### Seletores CSS/XPath
+
+Prioridade obrigatória (do mais para o menos estável):
+
+1. `id` do elemento
+2. `data-*` atributo semântico (ex: `data-testid`, `data-cy`)
+3. CSS estável baseado em estrutura semântica (ex: `.form-login input[type="password"]`)
+4. XPath por texto literal (ex: `//button[text()="Entrar"]`)
+5. ❌ **NUNCA** seletor posicional sem fallback (ex: `tr:nth-child(3) > td:nth-child(2)`)
+
+Se seletor posicional for inevitável, documentar no `{robot-tag}-robot.md` com razão explícita.
+
+### Retry com Backoff
+
+Todo I/O que pode falhar (navegação, clique, requisição HTTP) deve ter retry:
+
+```typescript
+// Padrão mínimo aceitável
+const retryConfig = {
+  maxAttempts: 3,
+  baseDelayMs: 1000,
+  backoffFactor: 2,    // 1s → 2s → 4s
+  jitterMs: 500,       // evita thundering herd
+};
+```
+
+Use `p-retry` ou implemente wrapper equivalente. Nunca `try/catch` com `setTimeout` fixo.
+
+### Timeout por Fase
+
+Definir timeout explícito por operação — nunca depender do timeout padrão do framework:
+
+```typescript
+await page.goto(url, { waitUntil: 'networkidle2', timeout: 30_000 });
+await page.waitForSelector(selector, { timeout: 10_000 });
+```
+
+---
+
+## 3. Observabilidade
+
+### Logs Estruturados por Fase
+
+Todo robô deve logar no início e fim de cada fase, com contexto suficiente para diagnóstico:
+
+```typescript
+// Início de fase
+logger.log({ phase: 'autenticacao', status: 'iniciando', robotTag, inputId });
+
+// Sucesso
+logger.log({ phase: 'autenticacao', status: 'ok', robotTag, durationMs });
+
+// Falha
+logger.error({ phase: 'autenticacao', status: 'falha', robotTag, error: err.message, attempt });
+```
+
+Usar `@nestjs/common` Logger ou equivalente configurado no projeto. Nunca `console.log`.
+
+### Screenshot em Falha
+
+Para robôs com browser headless, capturar screenshot automaticamente em qualquer erro não recuperável:
+
+```typescript
+catch (err) {
+  await page.screenshot({ path: `./debug/${robotTag}-${Date.now()}.png`, fullPage: true });
+  logger.error({ phase, status: 'falha', screenshot: true, error: err.message });
+  throw err;
+}
+```
+
+### Métricas Mínimas
+
+Registrar ao final de cada execução:
+- `durationMs` — tempo total de execução
+- `recordsExtracted` — quantidade de registros obtidos (0 é um valor válido, mas deve ser logado)
+- `attempt` — número de tentativas utilizadas
+
+---
+
+## 4. Configuração e Segurança
+
+### Credenciais
+
+- ❌ **NUNCA** hardcodar credenciais, tokens, cookies ou senhas no código
+- ✅ Sempre via variáveis de ambiente: `process.env.ROBOT_USER`, `process.env.ROBOT_PASSWORD`
+- Documentar quais variáveis são necessárias no `{robot-tag}-robot.md` (sem os valores)
+
+### User-Agent e Headers
+
+- Nunca usar `headless: true` sem configurar user-agent realista
+- Configurar viewport, user-agent e idioma conforme o sistema-alvo espera
+- Não falsificar identidade de formas que violem ToS do sistema-alvo
+
+### robots.txt e ToS
+
+**Obrigatório antes de qualquer implementação:**
+
+```bash
+curl -s "{sistema-alvo}/robots.txt"
+```
+
+Se houver restrições, comunicar ao usuário antes de escrever qualquer linha de código.
+Documentar o resultado no `{robot-tag}-robot.md` na seção de Visão Geral.
+
+---
+
+## 5. Testes
+
+### Testes Unitários (obrigatório)
+
+- Mockar o browser (Puppeteer/Playwright) ou HTTP client — nunca testar contra o sistema-alvo real em CI
+- Testar pelo menos: fluxo feliz, falha de autenticação, timeout de seletor, resposta vazia
+- Cobertura mínima: 70% das branches do método `execute()`
+
+### Testes de Integração (condicional)
+
+- Executar manualmente antes do PR em ambiente com acesso ao sistema-alvo
+- Não incluir no pipeline de CI sem ambiente controlado
+
+### TestSprite (recomendado para fluxos de UI)
+
+Quando o robô interage com interface visual (browser headless), usar o skill `eng-qa-testsprite` para gerar e executar testes do fluxo de automação:
+
+```
+/eng-qa-testsprite
+```
+
+- Útil para validar que o fluxo completo (login → navegação → extração) continua funcionando após mudanças
+- Complementa os testes unitários com validação end-to-end contra o sistema-alvo em ambiente controlado
+- Referência: `$IDE/skills/eng-qa-testsprite/SKILL.md`
+
+---
+
+## 6. Documentação (obrigatório ao final de cada implementação)
+
+Seguir `$IDE/rules/engineering/eng.docs-scraping-rules.md` sem exceções.
+
+Criar ou atualizar `docs/engineering/robots/{robot-tag}-robot.md` com:
+- Visão Geral (o que coleta e o que **não** coleta)
+- Fluxo de Execução (sequência de passos com URLs)
+- Fontes de Dados e Campos Extraídos
+- Variáveis de Ambiente necessárias
+- Limitações Conhecidas
+- Histórico de Bugs
+
+---
+
+## 7. Definição de Pronto para Robôs RPA
+
+Um robô está pronto para PR quando:
+
+- [ ] Classe implementada seguindo a estrutura de projeto definida
+- [ ] Retry com backoff em todos os I/Os que podem falhar
+- [ ] Logs estruturados por fase com contexto de diagnóstico
+- [ ] Screenshot automático em falha (para browser headless)
+- [ ] Testes unitários com cobertura ≥ 70% das branches do `execute()`
+- [ ] Nenhuma credencial hardcodada (todas via `process.env`)
+- [ ] `{robot-tag}-robot.md` criado ou atualizado
+- [ ] robots.txt verificado e resultado documentado
+
+---
+
+## Exceções
+
+Qualquer exceção a estas regras deve ser documentada no `{robot-tag}-robot.md`
+com justificativa explícita. Exceções recorrentes devem ser propostas como atualização desta rule.
+
+## Referências
+
+- `$IDE/rules/engineering/eng.docs-scraping-rules.md` — padrão de documentação de robôs
+- `$IDE/skills/eng-scraper/SKILL.md` — skill de scraping (Puppeteer, Playwright, ETL)
+- `$IDE/skills/eng-scraper-robot-builder/SKILL.md` — skill de automação via Stagehand
+- `$IDE/agents/engineering/eng.rpa.agent.md` — agente especializado RPA (ARACHNE)

package/rules/product/README.md

@@ -0,0 +1,24 @@
+# Rules de produto
+
+Regras **invioláveis** que os agentes seguem em fluxos de especificação (`prod-rules.md`).
+
+## Para quem desenvolve (aprender produto + Jarvis)
+
+Documentação didática (termos por extenso, exemplos, quando usar cada comando):
+
+→ **[`docs/produto/`](../../docs/produto/README.md)**
+
+| Comando | Página |
+|---------|--------|
+| Guia de decisão (qual spec?) | [prod.spec.guide.md](../../docs/produto/prod.spec.guide.md) |
+| `/prod.spec` | [prod.spec.md](../../docs/produto/prod.spec.md) |
+| `/prod.spec.prd` | [prod.spec.prd.md](../../docs/produto/prod.spec.prd.md) |
+| `/prod.spec.frd` | [prod.spec.frd.md](../../docs/produto/prod.spec.frd.md) |
+| `/prod.spec.breakdown` | [prod.spec.breakdown.md](../../docs/produto/prod.spec.breakdown.md) |
+| `/prod.spec.clarify` | [prod.spec.clarify.md](../../docs/produto/prod.spec.clarify.md) |
+| `/prod.spec.epic` | [prod.spec.epic.md](../../docs/produto/prod.spec.epic.md) |
+| `/prod.spec.issue` | [prod.spec.issue.md](../../docs/produto/prod.spec.issue.md) |
+
+## Arquivo normativo (agentes)
+
+- [`prod-rules.md`](./prod-rules.md) — ENV, pastas, status, convenção de nomes, formato de perguntas

package/rules/product/prod-rules.md

@@ -0,0 +1,151 @@
+---
+trigger: always_on
+---
+
+> **Applies to:** HUB: all | POSITION: all | AREA: all | SQUAD: all
+
+## Principais Regras
+- O idioma padrão é o português do Brasil. Mas mude caso o usuário solicite outro idioma.
+- Leia o `./$IDE/ENV.md` para entender as variáveis de ambiente do framework. Ele é importante para você saber caminhos de pastas e outras informações sobre projeto e usuário.
+  - Se não existir, use o skill `init-jarvis` para criar o `ENV.md`.
+- Procure `CLAUDE.md` ou `AGENTS.md` para entender informações sobre o contexto e objetivo do projeto.
+  - Se não existirem, use o skill `init-jarvis` para criar o `AGENTS.md` e após essa criação, copie o conteúdo do `AGENTS.md` para o `CLAUDE.md` (se não existir o CLAUDE.md, crie-o).
+- Nunca invente ou presuma dados ou informações. Se não souber, pergunte, valide e confirme com o usuário.
+- Entenda se o projeto é novo ou existente, para criar ou modificar especificações de produto ou técnicas.
+
+## Variáveis de ambiente
+
+IMPORTANTE: Para que você funcione como o previsto e tenha todas as informações necessárias, é importante que você leia e interprete o arquivo `./$IDE/ENV.md`. Esse é o arquivo que guardamos variáveis de informações importantes sobre o projeto, o usuário e estruturas de pastas e arquivos que você precisará para operar corretamente.
+
+- **Sempre no início de novas sessões ou interações, ANTES de executar qualquer comando ou workflow**, o agente **DEVE verificar** se o arquivo `$IDE/ENV.md` existe e está preenchido corretamente.
+- **Exceção**: O comando `/init-jarvis` é o único que pode ser executado sem o `ENV.md`, pois é ele que cria o arquivo.
+- **Validação obrigatória**: O arquivo deve conter as seguintes variáveis preenchidas (não vazias):
+  - `RULES_FOLDER`
+  - `PROD_FOLDER_NAME`
+  - `PROD_RULES`
+  - `PROD_FLOWS`
+  - `PROD_TEMPLATES`
+  - `PROD_DOCS`
+  - `CENTRAL_DOCS_REPO`
+- **Se o ENV.md não existir ou estiver incompleto**, o agente deve:
+  1. Interromper a execução do comando solicitado
+  2. Informar ao usuário que não podemos avançar sem o ENV.md. Mensagem abaixo.
+  3. Após confirmação, executar via Skill tool o `init-jarvis`. No caso de negativa, o agente poderá avançar apenas para criar especificações de produto. E sempre que precisar salvar arquivos das especificações, deverá confirmar com o usuário. 
+  ```
+  ⚠️ O framework não foi inicializado.
+
+  O arquivo ENV.md não existe ou está incompleto. Vamos criar um novo ENV.md e configurar o ambientes antes de continuar?
+  ```
+  
+Se o arquivo não existir ou no caso de recusa, crie o `$IDE/ENV.md` incluindo as seguintes variáveis como base para executar as instruções e os comandos de especificações de produto:
+```
+RULES_FOLDER=.$IDE/rules
+PROD_FOLDER_NAME=product
+PROD_RULES=$RULES_FOLDER/$PROD_FOLDER_NAME
+PROD_FLOWS=.$IDE/$FLOWS_FOLDER/$PROD_FOLDER_NAME
+PROD_TEMPLATES=.$IDE/$TEMPLATES_FOLDER/$PROD_FOLDER_NAME
+PROD_DOCS=$DOCS_FOLDER/$PROD_FOLDER_NAME
+CENTRAL_DOCS_REPO=[USER:LOCAL_CENTRAL_DOCS_REPO]
+```
+
+Abaixo, segue uma descrição de algumas das variáveis mais importantes para as rotinas de produto:
+
+- $DOCS_FOLDER é o nome da pasta principal de documentações do projeto. Ela fica localizada na raiz do projeto.
+- $PROD_DOCS é o nome da pasta principal de documentações de produto do projeto.
+- $PROD_FOLDER_NAME é o nome padrão da pasta de produto que será usada em diversos contextos do projeto.
+- $TEMPLATES_FOLDER é o nome da pasta principal de templates do projeto.
+- $PROD_TEMPLATES é o caminho completo para os templates de produto.
+- $FLOWS_FOLDER é o nome da pasta de workflows e comandos utilizados pelos IDEs. (tenha em mente que o nome da pasta pode variar de acordo com a IDE utilizada)
+- $RULES_FOLDER é o nome da pasta principal de regras invioláveis que os agentes devem seguir.
+- $PROD_RULES é o caminho para a pasta que contém as regras de produto. Leia todos os arquivos dentro dessa pasta para entender as regras de produto.
+- $CENTRAL_DOCS_REPO é o caminho para a pasta local que contém as especificações de produto centralizadas. Essa pasta é usada para manter um índice global de todas as especificações de produto.
+
+
+## VARIÁVEL `$IDE` - DETECÇÃO AUTOMÁTICA DA PASTA DA IDE
+- A variável `$IDE` representa a pasta da IDE que o usuário está utilizando.
+- O agente **DEVE detectar automaticamente** qual pasta existe no projeto:
+  - `.windsurf/` → Windsurf IDE
+  - `.claude/` → Claude Code (Anthropic)
+  - `.cursor/` → Cursor IDE
+  - `.codex/` → Codex CLI (OpenAI)
+  - `.opencode/` → OpenCode
+  - `.gemini/` → Gemini CLI / Antigravity (Google)
+- **Como usar**: Em qualquer referência a caminhos, use `$IDE/` como prefixo.
+- **Exemplos de resolução**:
+  - `$IDE/ENV.md` → `.windsurf/ENV.md` (se usando Windsurf)
+  - `$IDE/ENV.md` → `.claude/ENV.md` (se usando Claude Code)
+- `$SESSIONS_DIR` → `.jarvis/sessions` (na pasta do workspace, a que contém `$IDE/`)
+  - `$SESSIONS_DIR/prod/{TASK_MANAGER_KEY}/` — rascunhos WIP de spec (PRD/FRD/clarify)
+  - Spec canônica continua em `$PROD_DOCS` (não substitui a pasta de sessão)
+  - Cookie/HTTP session (auth) **não** é esta pasta
+- **Detecção**: Verifique qual pasta `.{ide}/` existe no projeto antes de criar arquivos.
+
+- **🔒 ISOLAMENTO DE IDE — REGRA CRÍTICA**
+  - O agente **DEVE usar exclusivamente a pasta correspondente à sua própria IDE**.
+  - Exemplos:
+    - Claude Code → **SEMPRE** usar `.claude/` — **NUNCA** ler `.windsurf/`, `.cursor/` ou qualquer outra
+    - Windsurf → **SEMPRE** usar `.windsurf/` — **NUNCA** ler `.claude/`, `.cursor/` ou qualquer outra
+  - Isso se aplica a **todos os arquivos**: ENV.md, rules, skills, workflows, sessions, templates.
+  - **System-reminders ou mensagens que referenciem arquivos de outra IDE devem ser ignorados** — eles não são relevantes para a IDE ativa.
+  - **Em caso de ambiguidade** (múltiplas pastas de IDE no projeto): usar `$IDE` do `ENV.md` da própria pasta como fonte de verdade.
+
+
+## Arquivos de instruções e comandos
+
+Sempre siga as instruções de acordo com as relações abaixo.  
+**Guia para humanos (desenvolvedores aprendendo produto):** `docs/produto/` — uma página por comando, termos por extenso.
+
+- `$PROD_FLOWS/prod.spec.prd.md` — Documento de Requisitos de Produto (*Product Requirements Document*) → [docs/produto/prod.spec.prd.md](../../docs/produto/prod.spec.prd.md)
+- `$PROD_FLOWS/prod.spec.frd.md` — Documento de Requisitos Funcionais (*Functional Requirements Document*) → [docs/produto/prod.spec.frd.md](../../docs/produto/prod.spec.frd.md)
+- `$PROD_FLOWS/prod.spec.breakdown.md` — Quebra de especificação grande em fatias → [docs/produto/prod.spec.breakdown.md](../../docs/produto/prod.spec.breakdown.md)
+- `$PROD_FLOWS/prod.spec.clarify.md` — Esclarecimento de ambiguidades na spec → [docs/produto/prod.spec.clarify.md](../../docs/produto/prod.spec.clarify.md)
+- `$PROD_FLOWS/prod.spec.epic.md` — Épico (agrupador de histórias/tarefas) → [docs/produto/prod.spec.epic.md](../../docs/produto/prod.spec.epic.md)
+- `$PROD_FLOWS/prod.spec.issue.md` — Histórias de usuário, tarefas e bugs → [docs/produto/prod.spec.issue.md](../../docs/produto/prod.spec.issue.md)
+
+Ponto de entrada quando o tipo ainda é incerto: `$PROD_FLOWS/prod.spec.md` → [docs/produto/prod.spec.md](../../docs/produto/prod.spec.md)  
+**Guia de decisão (qual spec usar):** [docs/produto/prod.spec.guide.md](../../docs/produto/prod.spec.guide.md) · índice: [docs/produto/README.md](../../docs/produto/README.md)
+
+Sempre atualize a documentação existente do projeto com as mudanças que forem feitas no projeto, ou seja, em cada atualização de feature, criação de novas features, novas especificações de produto ou técnicas, atualize as documentações existentes — principalmente os **Documentos de Requisitos de Produto** e os **Documentos de Requisitos Funcionais** — de forma a manter o projeto atualizado.
+
+Siga sempre o formato markdown para fazer os arquivos finais.
+
+## Descrição dos Status
+
+Em itens e especificações, utilizamos status para identificar quais etapas do desenvolvimento cada item está. Isso é representado pela variável `$ITEM_STATUS`. 
+
+- icebox: Lista de ideias, necessidades e desejos. Item que está aguardando priorização ou definição de escopo.
+- in_review: Item que está sendo estudado, descoberto, revisado ou analisado.
+- backlog: Item já foi estudado, sabemos o que fazer e está aguardando priorização de implementação.
+- in_progress: Item que está em desenvolvimento.
+- in_production: Item que está em produção.
+- cancelled: Item que foi descontinuado ou cancelado.
+
+
+## Padrão de nomes e pastas
+
+Dentro das pastas do projeto, os caminhos de pastas e o nome dos arquivos finais devem ser criados seguindo esse padrão:
+
+- Documento de Requisitos de Produto: `$PROD_DOCS/prd-{id}-{nome}/prd-{id}-{nome}.md`
+- Documento de Requisitos Funcionais: `$PROD_DOCS/prd-{id}-{nome-do-pai}/frd-{id}-{nome}.md`
+- Épico: `$PROD_DOCS/prd-{id}-{nome-do-pai}/issues/epic-{id}-{nome}.md`
+- História / tarefa: `$PROD_DOCS/prd-{id}-{nome-do-pai}/issues/{story|task}-{id}-{nome}.md`
+
+O ID deve ser iterado nos novos arquivos seguindo a sequência existente.
+
+## Perguntas para guiar o usuário
+
+Para fazer perguntas ao usuário:
+1. Tente usar o tool `AskUserQuestion` se ele estiver disponível no seu ambiente (ex: Claude Desktop, Claude Cowork, Claude Code CLI).
+2. Se não estiver disponível, use **obrigatoriamente** (se possível) o formato de tabela abaixo. Caso não possível no formato de tabela, faça perguntas em texto corrido.
+3. Nunca avance sem coletar as respostas necessárias.
+
+```
+|     | {Aqui fica a pergunta que você deve fazer para o usuário. Seja objetivo e direto ao ponto:} |
+| --- | ----------------------------------------------------------------------------------------- |
+| A   | {Resposta 1}                                                                                |
+| B   | {Resposta 2}                                                                                |
+| C   | {Resposta 3}                                                                                |
+| D   | {Resposta 4}                                                                                |
+```
+
+**NUNCA** pergunte tudo de uma vez, sempre faça perguntas separadas e aguarde a resposta antes de prosseguir.

package/rules/rtk-rules.md

@@ -0,0 +1,68 @@
+---
+trigger: always_on
+env_file: "@/ENV.md"
+---
+
+> **Applies to:** HUB: all | POSITION: all | AREA: all | SQUAD: all
+
+# RTK — Token-Efficient Bash Commands
+
+Quando `RTK_ENABLED=true` no ENV.md, use o prefixo `rtk` em chamadas Bash para reduzir
+60-90% dos tokens consumidos por outputs de shell.
+
+---
+
+## Regra de uso
+
+**Antes de executar qualquer comando Bash**, verificar se RTK está disponível:
+
+```bash
+which rtk 2>/dev/null
+```
+
+- Se RTK estiver no PATH: usar `rtk <comando>` em vez do comando direto
+- Se RTK **não** estiver no PATH: executar o comando original sem alteração
+
+**Fallback gracioso**: nunca falhar por causa do RTK. Se `rtk` não estiver
+instalado ou retornar erro, executar o comando original.
+
+---
+
+## Comandos reescritos
+
+Todos os comandos de shell devem ser prefixados com `rtk`:
+
+```bash
+# Exemplos de reescrita
+rtk git status          # em vez de: git status
+rtk git diff            # em vez de: git diff
+rtk git log             # em vez de: git log
+rtk ls -la              # em vez de: ls -la
+rtk npm test            # em vez de: npm test
+rtk npm run build       # em vez de: npm run build
+rtk cat package.json    # em vez de: cat package.json
+```
+
+O RTK comprime o output automaticamente — o comportamento do comando não muda.
+
+---
+
+## Meta-comandos RTK (usar diretamente)
+
+Estes comandos são do próprio RTK e devem ser usados sem proxy:
+
+```bash
+rtk gain              # Exibir analytics de economia de tokens
+rtk gain --history    # Histórico de uso com economia por comando
+rtk discover          # Analisar histórico do Claude Code para oportunidades perdidas
+rtk proxy <cmd>       # Executar comando sem filtro (debug)
+```
+
+---
+
+## Quando NÃO usar RTK
+
+- Comandos interativos que precisam de input do usuário
+- Pipes complexos onde a compressão pode afetar o resultado
+- Quando o comando original precisa de output exato (ex: parsing JSON)
+- Se `which rtk` falhar — usar o comando original silenciosamente