Aprenda olhando, testando e entendendo o risco.

Quando uma tool é classificada como controlada ou de alto risco, a missão entra em waiting_approval e o operador revisa antes de continuar.

Modo de aprovação, políticas por tipo de ação e permissões do conector.

strict, balanced, jarvis e autonomous — sempre respeitando gates que não podem ser autoaprovados.

Aprovar uma ação altera o estado real do computador, Git, arquivos ou serviços conforme a tool.

git push → HIGH_RISK → tarefa pendente → operador revisa → execução somente pelo fluxo permitido.

Se uma tarefa não avançar, consulte task_status e confirme se está pending_approval, done ou failed.

A aprovação não garante rollback automático. Cada operação precisa documentar sua reversibilidade.

Aprender a revisar evidências e riscos antes de aprovar.

Use capabilities para listar recursos e capability_status para saber se uma capability está disponível, degradada, ausente, bloqueada ou requer aprovação.

O Registry deriva do catálogo real da bridge; não existe uma lista manual paralela.

Filtros por categoria, risco e requiresApproval.

Baixo: é leitura de metadados operacionais.

capability_status('run_command') → disponibilidade + risco + supervisorSignal.

Se uma tool nova não aparecer, valide a bridge/túnel e refaça o initialize/tools-list do cliente.

Não aplicável: reload apenas atualiza cache em memória.

Consultar a capability antes de construir automações dependentes dela.

list_directory, file_info, read_multiple_files e search_content são read-only. copy_file e move_file são mutações controladas.

Roots autorizados e regras de arquivos sensíveis são definidos pelo runtime.

Limites de itens, bytes por arquivo, total de bytes e resultados de busca.

Tentativas de traversal, symlink/reparse escape, .env, tokens e secrets são bloqueadas.

Ler D:\JARVIS\hud\server.js funciona; sair do root com '..' é negado.

path_not_allowed indica caminho fora do escopo ou arquivo protegido.

Copy mantém origem; move pode exigir restauração manual dependendo do destino.

Preferir tools estruturadas em vez de shell para arquivos.

Ideal para git status, node --check, testes e builds permitidos.

Allowlist de executáveis/subcomandos, timeout e cwd autorizado.

cwd, executable, args, timeout e reason.

PowerShell, cmd, bash, node -e, python -c e comandos Git mutativos são bloqueados ou redirecionados para tools dedicadas.

git status executa; git push não passa pelo runner genérico.

blocked significa que a policy reconheceu execução fora do contrato seguro.

Comandos permitidos são escolhidos para não exigirem rollback mutativo.

Usar Process Sessions quando o comando for longo.

process_start → process_session_status/process_output → process_wait → resultado.

Timeout, cwd, executable, args e nome da sessão.

Listar, acompanhar stdout/stderr, esperar, parar processo gerenciado.

Não aceita PID arbitrário nem processo do sistema como alvo.

Rodar testes longos e acompanhar a saída sem perder o estado da missão.

UNKNOWN após restart significa que o processo não pôde ser reconciliado com certeza.

process_stop tenta encerramento controlado; force deve ser usado com cautela.

Associar processSessionId às missões e evidências.

window_list → window_capture → screen_analyze ou screen_compare.

Política SCREEN_CAPTURE_DISABLED, WINDOW_ONLY, REGION_ONLY ou FULL_SCREEN_ALLOWED; retenção em dias.

Captura de janela, região, evidência BEFORE/AFTER/ERROR/VALIDATION/MANUAL.

Screenshots podem conter dados sensíveis. Prefira WINDOW_ONLY e revise retenção.

Capturar painel antes de uma ação, executar, capturar depois e medir a alteração visual.

window_only_policy significa que tela inteira está bloqueada pela política ativa.

Captura não altera o sistema; evidências expiram pela política de retenção.

Integrar validação visual ao Critic e, depois, UI Control estruturado.