chore(i18n): refresh pt-BR translations

2026-05-04 18:25:48 +00:00 · 2026-05-04 18:25:48 +00:00 · f71f51da9a
commit f71f51da9a
parent 2543340e26
11 changed files with 1013 additions and 949 deletions
--- a/docs/pt-BR/channels/zalouser.md
+++ b/docs/pt-BR/channels/zalouser.md
@ -1,14 +1,14 @@
 ---
 read_when:
    - Configurando o Zalo Personal para o OpenClaw
-    - Depuração do fluxo de login ou de mensagens do Zalo Personal
-summary: Compatibilidade com conta pessoal do Zalo via zca-js nativo (login por QR), recursos e configuração
+    - Depuração do login ou do fluxo de mensagens do Zalo Personal
+summary: Suporte a contas pessoais do Zalo via zca-js nativo (login por QR), capacidades e configuração
 title: Zalo pessoal
 x-i18n:
-    generated_at: "2026-05-02T22:17:21Z"
+    generated_at: "2026-05-04T18:23:33Z"
    model: gpt-5.5
    provider: openai
-    source_hash: 0096775e0017e504130f2e19e05ab8114eadb873a9e11f79ea8f0dd91297567f
+    source_hash: 0f6d27f0ca502e6426abe21d609efd0a168a0b6b0fafe8d52d59f1a717da1ed5
    source_path: channels/zalouser.md
    workflow: 16
 ---
@ -16,15 +16,15 @@ x-i18n:
 Status: experimental. Esta integração automatiza uma **conta pessoal do Zalo** via `zca-js` nativo dentro do OpenClaw.

 <Warning>
-Esta é uma integração não oficial e pode resultar em suspensão ou banimento da conta. Use por sua conta e risco.
+Esta é uma integração não oficial e pode resultar em suspensão ou banimento da conta. Use por sua própria conta e risco.
 </Warning>

 ## Plugin incluído

-O Zalo Personal é distribuído como um Plugin incluído nas versões atuais do OpenClaw, portanto builds
-empacotados normais não precisam de uma instalação separada.
+O Zalo Personal é fornecido como um Plugin incluído nas versões atuais do OpenClaw, portanto builds
+empacotadas normais não precisam de uma instalação separada.

-Se você estiver em um build mais antigo ou em uma instalação personalizada que exclui o Zalo Personal,
+Se você estiver em uma build mais antiga ou em uma instalação personalizada que exclui o Zalo Personal,
 instale o pacote npm diretamente:

 - Instale via CLI: `openclaw plugins install @openclaw/zalouser`
@ -32,11 +32,11 @@ instale o pacote npm diretamente:
 - Ou a partir de um checkout do código-fonte: `openclaw plugins install ./path/to/local/zalouser-plugin`
 - Detalhes: [Plugins](/pt-BR/tools/plugin)

-Nenhum binário externo da CLI `zca`/`openzca` é necessário.
+Nenhum binário de CLI externo `zca`/`openzca` é necessário.

 ## Configuração rápida (iniciante)

-1. Garanta que o Plugin Zalo Personal esteja disponível.
+1. Verifique se o Plugin Zalo Personal está disponível.
   - As versões empacotadas atuais do OpenClaw já o incluem.
   - Instalações mais antigas/personalizadas podem adicioná-lo manualmente com os comandos acima.
 2. Faça login (QR, na máquina do Gateway):
@ -60,16 +60,16 @@ Nenhum binário externo da CLI `zca`/`openzca` é necessário.

 ## O que é

- Executa inteiramente em processo via `zca-js`.
+- Executa totalmente em processo via `zca-js`.
 - Usa listeners de eventos nativos para receber mensagens de entrada.
 - Envia respostas diretamente pela API JS (texto/mídia/link).
- Projetado para casos de uso de “conta pessoal” nos quais a API do Zalo Bot não está disponível.
+- Projetado para casos de uso de “conta pessoal” em que a API de Bot do Zalo não está disponível.

 ## Nomenclatura

-O id do canal é `zalouser` para deixar explícito que isto automatiza uma **conta de usuário pessoal do Zalo** (não oficial). Mantemos `zalo` reservado para uma possível integração oficial futura com a API do Zalo.
+O id do canal é `zalouser` para deixar explícito que isso automatiza uma **conta pessoal de usuário do Zalo** (não oficial). Mantemos `zalo` reservado para uma possível futura integração oficial com a API do Zalo.

-## Encontrar IDs (diretório)
+## Como encontrar IDs (diretório)

 Use a CLI de diretório para descobrir pares/grupos e seus IDs:

@ -88,7 +88,9 @@ openclaw directory groups list --channel zalouser --query "work"

 `channels.zalouser.dmPolicy` aceita: `pairing | allowlist | open | disabled` (padrão: `pairing`).

-`channels.zalouser.allowFrom` aceita IDs ou nomes de usuários. Durante a configuração, os nomes são resolvidos para IDs usando a busca de contatos em processo do Plugin.
+`channels.zalouser.allowFrom` deve usar IDs estáveis de usuários do Zalo. Durante a configuração interativa, nomes inseridos podem ser resolvidos para IDs usando a consulta de contatos em processo do Plugin.
+
+Se um nome bruto permanecer na configuração, a inicialização o resolverá somente quando `channels.zalouser.dangerouslyAllowNameMatching: true` estiver habilitado. Sem essa adesão explícita, as verificações de remetente em tempo de execução usam apenas ID e nomes brutos são ignorados para autorização.

 Aprove via:

@ -98,17 +100,17 @@ Aprove via:
 ## Acesso a grupos (opcional)

 - Padrão: `channels.zalouser.groupPolicy = "open"` (grupos permitidos). Use `channels.defaults.groupPolicy` para substituir o padrão quando não definido.
- Restrinja a uma allowlist com:
+- Restrinja a uma lista de permissões com:
  - `channels.zalouser.groupPolicy = "allowlist"`
-  - `channels.zalouser.groups` (as chaves devem ser IDs de grupo estáveis; nomes são resolvidos para IDs na inicialização quando possível)
+  - `channels.zalouser.groups` (as chaves devem ser IDs estáveis de grupos; nomes são resolvidos para IDs na inicialização somente quando `channels.zalouser.dangerouslyAllowNameMatching: true` está habilitado)
  - `channels.zalouser.groupAllowFrom` (controla quais remetentes em grupos permitidos podem acionar o bot)
 - Bloqueie todos os grupos: `channels.zalouser.groupPolicy = "disabled"`.
- O assistente de configuração pode solicitar allowlists de grupos.
- Na inicialização, o OpenClaw resolve nomes de grupos/usuários em allowlists para IDs e registra o mapeamento em log.
- A correspondência da allowlist de grupos é somente por ID por padrão. Nomes não resolvidos são ignorados para autenticação, a menos que `channels.zalouser.dangerouslyAllowNameMatching: true` esteja habilitado.
- `channels.zalouser.dangerouslyAllowNameMatching: true` é um modo de compatibilidade emergencial que reabilita a correspondência mutável por nome de grupo.
- Se `groupAllowFrom` não estiver definido, o runtime volta para `allowFrom` nas verificações de remetente em grupos.
- As verificações de remetente se aplicam tanto a mensagens normais de grupo quanto a comandos de controle (por exemplo `/new`, `/reset`).
+- O assistente de configuração pode solicitar listas de permissões de grupos.
+- Na inicialização, o OpenClaw resolve nomes de grupos/usuários em listas de permissões para IDs e registra o mapeamento somente quando `channels.zalouser.dangerouslyAllowNameMatching: true` está habilitado.
+- A correspondência de lista de permissões de grupos usa apenas ID por padrão. Nomes não resolvidos são ignorados para autenticação, a menos que `channels.zalouser.dangerouslyAllowNameMatching: true` esteja habilitado.
+- `channels.zalouser.dangerouslyAllowNameMatching: true` é um modo de compatibilidade de emergência que reabilita a resolução mutável de nomes na inicialização e a correspondência de nomes de grupos em tempo de execução.
+- Se `groupAllowFrom` não estiver definido, o tempo de execução recorre a `allowFrom` para verificações de remetente de grupo.
+- As verificações de remetente se aplicam tanto a mensagens normais de grupo quanto a comandos de controle (por exemplo, `/new`, `/reset`).

 Exemplo:

@ -127,15 +129,15 @@ Exemplo:
 }
 ```

-### Controle de menções em grupo
+### Controle por menção em grupos

 - `channels.zalouser.groups.<group>.requireMention` controla se respostas em grupo exigem uma menção.
 - Ordem de resolução: id/nome exato do grupo -> slug normalizado do grupo -> `*` -> padrão (`true`).
- Isso se aplica tanto a grupos em allowlist quanto ao modo de grupo aberto.
+- Isso se aplica tanto a grupos na lista de permissões quanto ao modo de grupo aberto.
 - Citar uma mensagem do bot conta como uma menção implícita para ativação em grupo.
- Comandos de controle autorizados (por exemplo `/new`) podem contornar o controle de menções.
- Quando uma mensagem de grupo é ignorada porque a menção é obrigatória, o OpenClaw a armazena como histórico de grupo pendente e a inclui na próxima mensagem de grupo processada.
- O limite de histórico de grupo usa `messages.groupChat.historyLimit` por padrão (fallback `50`). Você pode substituir por conta com `channels.zalouser.historyLimit`.
+- Comandos de controle autorizados (por exemplo, `/new`) podem contornar o controle por menção.
+- Quando uma mensagem de grupo é ignorada porque uma menção é exigida, o OpenClaw a armazena como histórico de grupo pendente e a inclui na próxima mensagem de grupo processada.
+- O limite de histórico de grupo usa `messages.groupChat.historyLimit` por padrão (fallback `50`). Você pode substituí-lo por conta com `channels.zalouser.historyLimit`.

 Exemplo:

@ -153,9 +155,9 @@ Exemplo:
 }
 ```

-## Várias contas
+## Múltiplas contas

-Contas são mapeadas para perfis `zalouser` no estado do OpenClaw. Exemplo:
+As contas são mapeadas para perfis `zalouser` no estado do OpenClaw. Exemplo:

 ```json5
 {
@ -186,19 +188,19 @@ Contas são mapeadas para perfis `zalouser` no estado do OpenClaw. Exemplo:
 - `openclaw channels status --probe`
 - Faça login novamente: `openclaw channels logout --channel zalouser && openclaw channels login --channel zalouser`

-**O nome na allowlist/grupo não foi resolvido:**
+**O nome na lista de permissões/grupo não foi resolvido:**

- Use IDs numéricos em `allowFrom`/`groupAllowFrom`/`groups`, ou nomes exatos de amigos/grupos.
+- Use IDs numéricos em `allowFrom`/`groupAllowFrom` e IDs estáveis de grupos em `groups`. Se você precisar intencionalmente de nomes exatos de amigos/grupos, habilite `channels.zalouser.dangerouslyAllowNameMatching: true`.

-**Atualizado de uma configuração antiga baseada em CLI:**
+**Atualizou de uma configuração antiga baseada em CLI:**

- Remova quaisquer suposições antigas sobre processos externos `zca`.
- O canal agora executa totalmente no OpenClaw sem binários externos de CLI.
+- Remova quaisquer pressupostos antigos sobre processo `zca` externo.
+- O canal agora executa totalmente no OpenClaw sem binários de CLI externos.

 ## Relacionados

- [Visão geral de canais](/pt-BR/channels) — todos os canais compatíveis
+- [Visão geral dos canais](/pt-BR/channels) — todos os canais compatíveis
 - [Pareamento](/pt-BR/channels/pairing) — autenticação por DM e fluxo de pareamento
- [Grupos](/pt-BR/channels/groups) — comportamento de chat em grupo e controle de menções
+- [Grupos](/pt-BR/channels/groups) — comportamento de chat em grupo e controle por menção
 - [Roteamento de canais](/pt-BR/channels/channel-routing) — roteamento de sessões para mensagens
- [Segurança](/pt-BR/gateway/security) — modelo de acesso e proteção
+- [Segurança](/pt-BR/gateway/security) — modelo de acesso e reforço
--- a/docs/pt-BR/cli/daemon.md
+++ b/docs/pt-BR/cli/daemon.md
@ -2,13 +2,13 @@
 read_when:
    - Você ainda usa `openclaw daemon ...` nos scripts
    - Você precisa de comandos de ciclo de vida do serviço (install/start/stop/restart/status)
-summary: Referência da CLI para `openclaw daemon` (apelido legado para gerenciamento do serviço Gateway)
+summary: Referência da CLI para `openclaw daemon` (alias legado para gerenciamento do serviço Gateway)
 title: Serviço em segundo plano
 x-i18n:
-    generated_at: "2026-05-02T22:17:33Z"
+    generated_at: "2026-05-04T18:23:37Z"
    model: gpt-5.5
    provider: openai
-    source_hash: 3f11b75bf2781e69f6f59b23364f06cf359f9f24407f25f19b9d2186f7158512
+    source_hash: f84e11fc50bdf38da518a8fcf415ae461a2688c2299f996eee384357c0d04a05
    source_path: cli/daemon.md
    workflow: 16
 ---
@ -17,7 +17,7 @@ x-i18n:

 Alias legado para comandos de gerenciamento do serviço Gateway.

-`openclaw daemon ...` mapeia para a mesma superfície de controle de serviço dos comandos de serviço `openclaw gateway ...`.
+`openclaw daemon ...` mapeia para a mesma superfície de controle de serviço que os comandos de serviço `openclaw gateway ...`.

 ## Uso

@ -32,34 +32,35 @@ openclaw daemon uninstall

 ## Subcomandos

- `status`: mostrar o estado de instalação do serviço e sondar a integridade do Gateway
- `install`: instalar o serviço (`launchd`/`systemd`/`schtasks`)
- `uninstall`: remover o serviço
- `start`: iniciar o serviço
- `stop`: parar o serviço
- `restart`: reiniciar o serviço
+- `status`: mostra o estado de instalação do serviço e verifica a integridade do Gateway
+- `install`: instala o serviço (`launchd`/`systemd`/`schtasks`)
+- `uninstall`: remove o serviço
+- `start`: inicia o serviço
+- `stop`: interrompe o serviço
+- `restart`: reinicia o serviço

 ## Opções comuns

 - `status`: `--url`, `--token`, `--password`, `--timeout`, `--no-probe`, `--require-rpc`, `--deep`, `--json`
 - `install`: `--port`, `--runtime <node|bun>`, `--token`, `--force`, `--json`
- `restart`: `--force`, `--wait <duration>`, `--json`
+- `restart`: `--safe`, `--force`, `--wait <duration>`, `--json`
 - ciclo de vida (`uninstall|start|stop`): `--json`

 Observações:

- `status` resolve SecretRefs de autenticação configuradas para autenticação de sondagem quando possível.
- Se uma SecretRef de autenticação obrigatória não for resolvida neste caminho de comando, `daemon status --json` relata `rpc.authWarning` quando a conectividade/autenticação da sondagem falha; passe `--token`/`--password` explicitamente ou resolva primeiro a fonte do segredo.
- Se a sondagem for bem-sucedida, avisos de referência de autenticação não resolvida são suprimidos para evitar falsos positivos.
- `status --deep` adiciona uma varredura de serviço em nível de sistema em melhor esforço. Quando encontra outros serviços semelhantes ao Gateway, a saída para humanos imprime dicas de limpeza e avisa que um Gateway por máquina ainda é a recomendação normal.
- Em instalações Linux com systemd, as verificações de desvio de token de `status` incluem fontes de unidade `Environment=` e `EnvironmentFile=`.
- As verificações de desvio resolvem SecretRefs de `gateway.auth.token` usando o env de runtime mesclado (primeiro o env do comando de serviço, depois o fallback para o env do processo).
- Se a autenticação por token não estiver efetivamente ativa (`gateway.auth.mode` explícito de `password`/`none`/`trusted-proxy`, ou modo não definido em que a senha pode vencer e nenhum candidato a token pode vencer), as verificações de desvio de token ignoram a resolução do token de configuração.
- Quando a autenticação por token exige um token e `gateway.auth.token` é gerenciado por SecretRef, `install` valida que a SecretRef pode ser resolvida, mas não persiste o token resolvido nos metadados de ambiente do serviço.
- Se a autenticação por token exigir um token e a SecretRef de token configurada não for resolvida, a instalação falhará fechada.
- Se `gateway.auth.token` e `gateway.auth.password` estiverem configurados e `gateway.auth.mode` não estiver definido, a instalação será bloqueada até que o modo seja definido explicitamente.
- No macOS, `install` mantém os plists do LaunchAgent somente para o proprietário e carrega valores de ambiente do serviço gerenciado por meio de um arquivo e wrapper somente para o proprietário, em vez de serializar chaves de API ou referências de env de perfil de autenticação em `EnvironmentVariables`.
- Se você executa intencionalmente vários Gateways em um host, isole portas, configuração/estado e workspaces; consulte [/gateway#multiple-gateways-same-host](/pt-BR/gateway#multiple-gateways-same-host).
+- `status` resolve SecretRefs de autenticação configuradas para autenticação de verificação quando possível.
+- Se uma SecretRef de autenticação obrigatória não for resolvida neste caminho de comando, `daemon status --json` relata `rpc.authWarning` quando a conectividade/autenticação da verificação falha; passe `--token`/`--password` explicitamente ou resolva primeiro a origem do segredo.
+- Se a verificação for bem-sucedida, avisos de auth-ref não resolvidos são suprimidos para evitar falsos positivos.
+- `status --deep` adiciona uma varredura de serviço em nível de sistema em regime de melhor esforço. Quando encontra outros serviços semelhantes a gateway, a saída humana imprime dicas de limpeza e avisa que um Gateway por máquina ainda é a recomendação normal.
+- Em instalações systemd no Linux, as verificações de desvio de token de `status` incluem tanto origens de unidade `Environment=` quanto `EnvironmentFile=`.
+- As verificações de desvio resolvem SecretRefs de `gateway.auth.token` usando o env de runtime mesclado (primeiro o env do comando de serviço, depois o fallback do env do processo).
+- Se a autenticação por token não estiver efetivamente ativa (`gateway.auth.mode` explícito de `password`/`none`/`trusted-proxy`, ou modo não definido em que a senha pode prevalecer e nenhum candidato de token pode prevalecer), as verificações de desvio de token pulam a resolução do token de configuração.
+- Quando a autenticação por token exige um token e `gateway.auth.token` é gerenciado por SecretRef, `install` valida que a SecretRef é resolvível, mas não persiste o token resolvido nos metadados de ambiente do serviço.
+- Se a autenticação por token exige um token e a SecretRef de token configurada não está resolvida, a instalação falha de forma fechada.
+- Se tanto `gateway.auth.token` quanto `gateway.auth.password` estiverem configurados e `gateway.auth.mode` não estiver definido, a instalação será bloqueada até que o modo seja definido explicitamente.
+- No macOS, `install` mantém os plists do LaunchAgent acessíveis somente ao proprietário e carrega valores de ambiente do serviço gerenciado por meio de um arquivo e wrapper acessíveis somente ao proprietário, em vez de serializar chaves de API ou refs de env de perfil de autenticação em `EnvironmentVariables`.
+- Se você executar intencionalmente vários Gateways em um host, isole portas, configuração/estado e espaços de trabalho; consulte [/gateway#multiple-gateways-same-host](/pt-BR/gateway#multiple-gateways-same-host).
+- `restart --safe` pede ao Gateway em execução que faça uma pré-verificação do trabalho ativo e agende uma reinicialização coalescida após o escoamento do trabalho ativo. `restart` simples mantém o comportamento existente do gerenciador de serviço; `--force` continua sendo o caminho de substituição imediata.

 ## Prefira

--- a/docs/pt-BR/cli/gateway.md
+++ b/docs/pt-BR/cli/gateway.md
@ -1,16 +1,16 @@
 ---
 read_when:
    - Executando o Gateway pela CLI (desenvolvimento ou servidores)
-    - Depuração de autenticação, modos de vinculação e conectividade do Gateway
-    - Descobrindo Gateways via Bonjour (DNS-SD local e de área ampla)
+    - Depuração de autenticação do Gateway, modos de vinculação e conectividade
+    - Descoberta de Gateways via Bonjour (DNS-SD local + de área ampla)
 sidebarTitle: Gateway
-summary: CLI do OpenClaw Gateway (`openclaw gateway`) — execute, consulte e descubra instâncias do Gateway
+summary: OpenClaw Gateway CLI (`openclaw gateway`) — execute, consulte e descubra Gateways
 title: Gateway
 x-i18n:
-    generated_at: "2026-05-02T22:17:38Z"
+    generated_at: "2026-05-04T18:23:47Z"
    model: gpt-5.5
    provider: openai
-    source_hash: f7f948a8f0ee6e065afa02f354e690ad5cc4f71bdb8b8674f1b0396c439ab242
+    source_hash: 310867c59148577f2e8ce6f708da6bce936e09243ce7fbe5daeb453c6b3b370d
    source_path: cli/gateway.md
    workflow: 16
 ---
@ -18,14 +18,14 @@ x-i18n:
 O Gateway é o servidor WebSocket do OpenClaw (canais, nós, sessões, hooks). Os subcomandos nesta página ficam em `openclaw gateway …`.

 <CardGroup cols={3}>
-  <Card title="Bonjour discovery" href="/pt-BR/gateway/bonjour">
-    Configuração local de mDNS + DNS-SD de área ampla.
+  <Card title="Descoberta Bonjour" href="/pt-BR/gateway/bonjour">
+    Configuração de mDNS local + DNS-SD de área ampla.
  </Card>
-  <Card title="Discovery overview" href="/pt-BR/gateway/discovery">
+  <Card title="Visão geral da descoberta" href="/pt-BR/gateway/discovery">
    Como o OpenClaw anuncia e encontra gateways.
  </Card>
-  <Card title="Configuration" href="/pt-BR/gateway/configuration">
-    Chaves de configuração de nível superior do Gateway.
+  <Card title="Configuração" href="/pt-BR/gateway/configuration">
+    Chaves de configuração de nível superior do gateway.
  </Card>
 </CardGroup>

@ -44,13 +44,13 @@ openclaw gateway run
 ```

 <AccordionGroup>
-  <Accordion title="Startup behavior">
-    - Por padrão, o Gateway se recusa a iniciar a menos que `gateway.mode=local` esteja definido em `~/.openclaw/openclaw.json`. Use `--allow-unconfigured` para execuções ad hoc/de desenvolvimento.
-    - Espera-se que `openclaw onboard --mode local` e `openclaw setup` gravem `gateway.mode=local`. Se o arquivo existir, mas `gateway.mode` estiver ausente, trate isso como uma configuração quebrada ou sobrescrita e repare-a em vez de presumir implicitamente o modo local.
-    - Se o arquivo existir e `gateway.mode` estiver ausente, o Gateway trata isso como dano suspeito à configuração e se recusa a "adivinhar local" para você.
-    - Vincular além do loopback sem autenticação é bloqueado (medida de segurança).
-    - `SIGUSR1` aciona uma reinicialização dentro do processo quando autorizado (`commands.restart` é habilitado por padrão; defina `commands.restart: false` para bloquear a reinicialização manual, enquanto a aplicação/atualização da ferramenta/configuração do Gateway continua permitida).
-    - Os manipuladores de `SIGINT`/`SIGTERM` param o processo do Gateway, mas não restauram nenhum estado personalizado do terminal. Se você envolver a CLI com uma TUI ou entrada em modo bruto, restaure o terminal antes de sair.
+  <Accordion title="Comportamento de inicialização">
+    - Por padrão, o Gateway se recusa a iniciar a menos que `gateway.mode=local` esteja definido em `~/.openclaw/openclaw.json`. Use `--allow-unconfigured` para execuções ad-hoc/de desenvolvimento.
+    - Espera-se que `openclaw onboard --mode local` e `openclaw setup` gravem `gateway.mode=local`. Se o arquivo existir, mas `gateway.mode` estiver ausente, trate isso como uma configuração quebrada ou sobrescrita e repare-a em vez de assumir implicitamente o modo local.
+    - Se o arquivo existir e `gateway.mode` estiver ausente, o Gateway trata isso como dano suspeito na configuração e se recusa a "adivinhar local" para você.
+    - Vincular além do loopback sem autenticação é bloqueado (barreira de segurança).
+    - `SIGUSR1` aciona uma reinicialização dentro do processo quando autorizado (`commands.restart` é habilitado por padrão; defina `commands.restart: false` para bloquear a reinicialização manual, enquanto aplicação/atualização da ferramenta/configuração do gateway continuam permitidas).
+    - Os manipuladores de `SIGINT`/`SIGTERM` interrompem o processo do gateway, mas não restauram nenhum estado personalizado do terminal. Se você encapsular a CLI com uma TUI ou entrada em modo bruto, restaure o terminal antes de sair.

  </Accordion>
 </AccordionGroup>
@ -61,7 +61,7 @@ openclaw gateway run
  Porta WebSocket (o padrão vem da configuração/env; geralmente `18789`).
 </ParamField>
 <ParamField path="--bind <loopback|lan|tailnet|auto|custom>" type="string">
-  Modo de vinculação do listener.
+  Modo de bind do listener.
 </ParamField>
 <ParamField path="--auth <token|password>" type="string">
  Substituição do modo de autenticação.
@ -73,78 +73,88 @@ openclaw gateway run
  Substituição da senha.
 </ParamField>
 <ParamField path="--password-file <path>" type="string">
-  Ler a senha do Gateway a partir de um arquivo.
+  Leia a senha do gateway de um arquivo.
 </ParamField>
 <ParamField path="--tailscale <off|serve|funnel>" type="string">
-  Expor o Gateway via Tailscale.
+  Exponha o Gateway via Tailscale.
 </ParamField>
 <ParamField path="--tailscale-reset-on-exit" type="boolean">
-  Redefinir a configuração de serve/funnel do Tailscale ao desligar.
+  Redefina a configuração serve/funnel do Tailscale ao encerrar.
 </ParamField>
 <ParamField path="--allow-unconfigured" type="boolean">
-  Permitir iniciar o Gateway sem `gateway.mode=local` na configuração. Ignora a proteção de inicialização apenas para bootstrap ad hoc/de desenvolvimento; não grava nem repara o arquivo de configuração.
+  Permita que o gateway inicie sem `gateway.mode=local` na configuração. Ignora a proteção de inicialização apenas para bootstrap ad-hoc/de desenvolvimento; não grava nem repara o arquivo de configuração.
 </ParamField>
 <ParamField path="--dev" type="boolean">
-  Criar uma configuração de desenvolvimento + workspace se estiver ausente (ignora BOOTSTRAP.md).
+  Crie uma configuração de desenvolvimento + workspace se ausentes (ignora BOOTSTRAP.md).
 </ParamField>
 <ParamField path="--reset" type="boolean">
-  Redefinir configuração de desenvolvimento + credenciais + sessões + workspace (requer `--dev`).
+  Redefina configuração de desenvolvimento + credenciais + sessões + workspace (requer `--dev`).
 </ParamField>
 <ParamField path="--force" type="boolean">
-  Encerrar qualquer listener existente na porta selecionada antes de iniciar.
+  Encerre qualquer listener existente na porta selecionada antes de iniciar.
 </ParamField>
 <ParamField path="--verbose" type="boolean">
  Logs detalhados.
 </ParamField>
 <ParamField path="--cli-backend-logs" type="boolean">
-  Mostrar apenas logs do backend da CLI no console (e habilitar stdout/stderr).
+  Mostre apenas logs do backend da CLI no console (e habilite stdout/stderr).
 </ParamField>
 <ParamField path="--ws-log <auto|full|compact>" type="string" default="auto">
-  Estilo de log Websocket.
+  Estilo de log do WebSocket.
 </ParamField>
 <ParamField path="--compact" type="boolean">
  Alias para `--ws-log compact`.
 </ParamField>
 <ParamField path="--raw-stream" type="boolean">
-  Registrar eventos brutos do fluxo do modelo em jsonl.
+  Registre eventos brutos de stream do modelo em jsonl.
 </ParamField>
 <ParamField path="--raw-stream-path <path>" type="string">
-  Caminho jsonl do fluxo bruto.
+  Caminho jsonl do stream bruto.
 </ParamField>

+## Reiniciar o Gateway
+
+```bash
+openclaw gateway restart
+openclaw gateway restart --safe
+openclaw gateway restart --force
+```
+
+`openclaw gateway restart --safe` pede ao Gateway em execução que faça uma pré-verificação do trabalho ativo do OpenClaw antes de reiniciar. Se operações em fila, entrega de respostas, execuções incorporadas ou execuções de tarefas estiverem ativas, o Gateway relata os bloqueadores, agrupa solicitações duplicadas de reinicialização segura e reinicia quando o trabalho ativo é escoado. `restart` simples mantém o comportamento existente do gerenciador de serviço para compatibilidade. Use `--force` somente quando você quiser explicitamente o caminho de substituição imediata.
+
 <Warning>
 `--password` inline pode ser exposto em listagens de processos locais. Prefira `--password-file`, env ou um `gateway.auth.password` baseado em SecretRef.
 </Warning>

-### Perfilamento de inicialização
+### Perfilamento da inicialização

- Defina `OPENCLAW_GATEWAY_STARTUP_TRACE=1` para registrar temporizações de fases durante a inicialização do Gateway, incluindo atraso `eventLoopMax` por fase e temporizações de tabelas de consulta de plugins para índice instalado, registro de manifesto, planejamento de inicialização e trabalho de mapa de proprietários.
- Defina `OPENCLAW_DIAGNOSTICS=timeline` com `OPENCLAW_DIAGNOSTICS_TIMELINE_PATH=<path>` para gravar uma linha do tempo de diagnóstico de inicialização JSONL de melhor esforço para harnesses externos de QA. Você também pode habilitar a flag com `diagnostics.flags: ["timeline"]` na configuração; o caminho ainda é fornecido por env. Adicione `OPENCLAW_DIAGNOSTICS_EVENT_LOOP=1` para incluir amostras de loop de eventos.
- Execute `pnpm test:startup:gateway -- --runs 5 --warmup 1` para medir a inicialização do Gateway. O benchmark registra a primeira saída do processo, `/healthz`, `/readyz`, temporizações do trace de inicialização, atraso do loop de eventos e detalhes de temporização da tabela de consulta de plugins.
+- Defina `OPENCLAW_GATEWAY_STARTUP_TRACE=1` para registrar tempos de fases durante a inicialização do Gateway, incluindo atraso `eventLoopMax` por fase e tempos de tabelas de consulta de plugins para índice instalado, registro de manifestos, planejamento de inicialização e trabalho de mapa de proprietários.
+- Defina `OPENCLAW_DIAGNOSTICS=timeline` com `OPENCLAW_DIAGNOSTICS_TIMELINE_PATH=<path>` para gravar uma timeline de diagnósticos de inicialização JSONL de melhor esforço para harnesses externos de QA. Você também pode habilitar a flag com `diagnostics.flags: ["timeline"]` na configuração; o caminho ainda é fornecido por env. Adicione `OPENCLAW_DIAGNOSTICS_EVENT_LOOP=1` para incluir amostras do loop de eventos.
+- Execute `pnpm test:startup:gateway -- --runs 5 --warmup 1` para medir a inicialização do Gateway. O benchmark registra a primeira saída do processo, `/healthz`, `/readyz`, tempos do trace de inicialização, atraso do loop de eventos e detalhes de tempo das tabelas de consulta de plugins.

 ## Consultar um Gateway em execução

 Todos os comandos de consulta usam RPC por WebSocket.

 <Tabs>
-  <Tab title="Output modes">
+  <Tab title="Modos de saída">
    - Padrão: legível por humanos (colorido em TTY).
    - `--json`: JSON legível por máquina (sem estilo/spinner).
    - `--no-color` (ou `NO_COLOR=1`): desabilita ANSI mantendo o layout humano.

  </Tab>
-  <Tab title="Shared options">
+  <Tab title="Opções compartilhadas">
    - `--url <url>`: URL WebSocket do Gateway.
    - `--token <token>`: token do Gateway.
    - `--password <password>`: senha do Gateway.
-    - `--timeout <ms>`: tempo limite/orçamento (varia por comando).
-    - `--expect-final`: aguardar uma resposta "final" (chamadas de agente).
+    - `--timeout <ms>`: timeout/orçamento (varia por comando).
+    - `--expect-final`: aguarda uma resposta "final" (chamadas de agente).

  </Tab>
 </Tabs>

 <Note>
-Quando você define `--url`, a CLI não recorre às credenciais da configuração ou do ambiente. Passe `--token` ou `--password` explicitamente. Credenciais explícitas ausentes são um erro.
+Quando você define `--url`, a CLI não recorre a credenciais da configuração ou do ambiente. Passe `--token` ou `--password` explicitamente. Credenciais explícitas ausentes são um erro.
 </Note>

 ### `gateway health`
@ -153,11 +163,11 @@ Quando você define `--url`, a CLI não recorre às credenciais da configuraçã
 openclaw gateway health --url ws://127.0.0.1:18789
 ```

-O endpoint HTTP `/healthz` é uma verificação de vivacidade: ele retorna quando o servidor consegue responder HTTP. O endpoint HTTP `/readyz` é mais rigoroso e permanece vermelho enquanto sidecars de plugins de inicialização, canais ou hooks configurados ainda estão estabilizando. Respostas detalhadas locais ou autenticadas de prontidão incluem um bloco de diagnóstico `eventLoop` com atraso do loop de eventos, utilização do loop de eventos, proporção de núcleos de CPU e uma flag `degraded`.
+O endpoint HTTP `/healthz` é uma sonda de vitalidade: ele retorna quando o servidor consegue responder por HTTP. O endpoint HTTP `/readyz` é mais rigoroso e permanece vermelho enquanto sidecars de plugins de inicialização, canais ou hooks configurados ainda estão se acomodando. Respostas detalhadas de prontidão locais ou autenticadas incluem um bloco de diagnóstico `eventLoop` com atraso do loop de eventos, utilização do loop de eventos, proporção de núcleos de CPU e uma flag `degraded`.

 ### `gateway usage-cost`

-Buscar resumos de custo de uso nos logs de sessão.
+Busca resumos de custo de uso dos logs de sessão.

 ```bash
 openclaw gateway usage-cost
@ -171,7 +181,7 @@ openclaw gateway usage-cost --json

 ### `gateway stability`

-Buscar o registrador recente de estabilidade diagnóstica de um Gateway em execução.
+Busca o gravador recente de estabilidade de diagnóstico de um Gateway em execução.

 ```bash
 openclaw gateway stability
@ -185,32 +195,32 @@ openclaw gateway stability --json
  Número máximo de eventos recentes a incluir (máx. `1000`).
 </ParamField>
 <ParamField path="--type <type>" type="string">
-  Filtrar por tipo de evento diagnóstico, como `payload.large` ou `diagnostic.memory.pressure`.
+  Filtre por tipo de evento de diagnóstico, como `payload.large` ou `diagnostic.memory.pressure`.
 </ParamField>
 <ParamField path="--since-seq <seq>" type="number">
-  Incluir apenas eventos após um número de sequência diagnóstica.
+  Inclua apenas eventos após um número de sequência de diagnóstico.
 </ParamField>
 <ParamField path="--bundle [path]" type="string">
-  Ler um pacote de estabilidade persistido em vez de chamar o Gateway em execução. Use `--bundle latest` (ou apenas `--bundle`) para o pacote mais novo no diretório de estado, ou passe diretamente um caminho JSON de pacote.
+  Leia um pacote de estabilidade persistido em vez de chamar o Gateway em execução. Use `--bundle latest` (ou apenas `--bundle`) para o pacote mais novo no diretório de estado, ou passe diretamente um caminho JSON do pacote.
 </ParamField>
 <ParamField path="--export" type="boolean">
-  Gravar um zip de diagnóstico de suporte compartilhável em vez de imprimir detalhes de estabilidade.
+  Grave um zip de diagnósticos de suporte compartilhável em vez de imprimir detalhes de estabilidade.
 </ParamField>
 <ParamField path="--output <path>" type="string">
  Caminho de saída para `--export`.
 </ParamField>

 <AccordionGroup>
-  <Accordion title="Privacy and bundle behavior">
-    - Os registros mantêm metadados operacionais: nomes de eventos, contagens, tamanhos em bytes, leituras de memória, estado de fila/sessão, nomes de canal/plugin e resumos de sessão redigidos. Eles não mantêm texto de chat, corpos de webhook, saídas de ferramentas, corpos brutos de solicitação ou resposta, tokens, cookies, valores secretos, nomes de host ou ids brutos de sessão. Defina `diagnostics.enabled: false` para desabilitar completamente o registrador.
-    - Em saídas fatais do Gateway, tempos limite de desligamento e falhas de inicialização de reinício, o OpenClaw grava o mesmo snapshot diagnóstico em `~/.openclaw/logs/stability/openclaw-stability-*.json` quando o registrador tem eventos. Inspecione o pacote mais novo com `openclaw gateway stability --bundle latest`; `--limit`, `--type` e `--since-seq` também se aplicam à saída do pacote.
+  <Accordion title="Privacidade e comportamento do pacote">
+    - Os registros mantêm metadados operacionais: nomes de eventos, contagens, tamanhos em bytes, leituras de memória, estado de filas/sessões, nomes de canais/plugins e resumos de sessão redigidos. Eles não mantêm texto de chat, corpos de webhook, saídas de ferramentas, corpos brutos de solicitação ou resposta, tokens, cookies, valores secretos, nomes de host ou ids brutos de sessão. Defina `diagnostics.enabled: false` para desabilitar o gravador totalmente.
+    - Em encerramentos fatais do Gateway, timeouts de desligamento e falhas de inicialização após reinicialização, o OpenClaw grava o mesmo snapshot de diagnóstico em `~/.openclaw/logs/stability/openclaw-stability-*.json` quando o gravador tem eventos. Inspecione o pacote mais novo com `openclaw gateway stability --bundle latest`; `--limit`, `--type` e `--since-seq` também se aplicam à saída do pacote.

  </Accordion>
 </AccordionGroup>

 ### `gateway diagnostics export`

-Grava um zip local de diagnóstico projetado para anexar a relatórios de bug. Para o modelo de privacidade e o conteúdo do pacote, consulte [Exportação de Diagnóstico](/pt-BR/gateway/diagnostics).
+Grava um zip de diagnósticos local projetado para anexar a relatórios de bugs. Para o modelo de privacidade e o conteúdo do pacote, consulte [Exportação de diagnósticos](/pt-BR/gateway/diagnostics).

 ```bash
 openclaw gateway diagnostics export
@ -237,22 +247,22 @@ openclaw gateway diagnostics export --json
  Senha do Gateway para o snapshot de integridade.
 </ParamField>
 <ParamField path="--timeout <ms>" type="number" default="3000">
-  Tempo limite do snapshot de status/integridade.
+  Timeout do snapshot de status/integridade.
 </ParamField>
 <ParamField path="--no-stability-bundle" type="boolean">
-  Ignorar a busca por pacote de estabilidade persistido.
+  Ignore a busca de pacote de estabilidade persistido.
 </ParamField>
 <ParamField path="--json" type="boolean">
-  Imprimir o caminho gravado, o tamanho e o manifesto como JSON.
+  Imprima o caminho gravado, o tamanho e o manifesto como JSON.
 </ParamField>

-A exportação contém um manifesto, um resumo em Markdown, formato da configuração, detalhes sanitizados de configuração, resumos sanitizados de logs, snapshots sanitizados de status/integridade do Gateway e o pacote de estabilidade mais novo quando existir.
+A exportação contém um manifesto, um resumo em Markdown, formato da configuração, detalhes sanitizados da configuração, resumos sanitizados de logs, snapshots sanitizados de status/integridade do Gateway e o pacote de estabilidade mais novo quando existir.

-Ela foi pensada para ser compartilhada. Mantém detalhes operacionais que ajudam na depuração, como campos seguros de log do OpenClaw, nomes de subsistemas, códigos de status, durações, modos configurados, portas, ids de plugins, ids de provedores, configurações não secretas de recursos e mensagens de log operacional redigidas. Ela omite ou redige texto de chat, corpos de webhook, saídas de ferramentas, credenciais, cookies, identificadores de conta/mensagem, texto de prompt/instruções, nomes de host e valores secretos. Quando uma mensagem no estilo LogTape parece texto de payload de usuário/chat/ferramenta, a exportação mantém apenas que uma mensagem foi omitida, além de sua contagem de bytes.
+Ela foi feita para ser compartilhada. Mantém detalhes operacionais que ajudam na depuração, como campos seguros de log do OpenClaw, nomes de subsistemas, códigos de status, durações, modos configurados, portas, ids de plugins, ids de provedores, configurações de recursos não secretas e mensagens de log operacional redigidas. Omite ou redige texto de chat, corpos de webhook, saídas de ferramentas, credenciais, cookies, identificadores de contas/mensagens, texto de prompts/instruções, nomes de host e valores secretos. Quando uma mensagem no estilo LogTape parece texto de payload de usuário/chat/ferramenta, a exportação mantém apenas que uma mensagem foi omitida, além de sua contagem de bytes.

 ### `gateway status`

-`gateway status` mostra o serviço do Gateway (launchd/systemd/schtasks) mais uma verificação opcional de capacidade de conectividade/autenticação.
+`gateway status` mostra o serviço do Gateway (launchd/systemd/schtasks) mais uma sonda opcional de capacidade de conectividade/autenticação.

 ```bash
 openclaw gateway status
@ -261,44 +271,44 @@ openclaw gateway status --require-rpc
 ```

 <ParamField path="--url <url>" type="string">
-  Adicionar um destino explícito de verificação. Remoto configurado + localhost ainda são verificados.
+  Adicione um destino de sondagem explícito. O remoto configurado + localhost ainda são sondados.
 </ParamField>
 <ParamField path="--token <token>" type="string">
-  Autenticação por token para a verificação.
+  Autenticação por token para a sondagem.
 </ParamField>
 <ParamField path="--password <password>" type="string">
-  Autenticação por senha para a verificação.
+  Autenticação por senha para a sondagem.
 </ParamField>
 <ParamField path="--timeout <ms>" type="number" default="10000">
-  Tempo limite da verificação.
+  Tempo limite da sondagem.
 </ParamField>
 <ParamField path="--no-probe" type="boolean">
-  Ignorar a verificação de conectividade (visualização somente do serviço).
+  Pule a sondagem de conectividade (visão apenas do serviço).
 </ParamField>
 <ParamField path="--deep" type="boolean">
-  Verificar também serviços em nível de sistema.
+  Examine também serviços em nível de sistema.
 </ParamField>
 <ParamField path="--require-rpc" type="boolean">
-  Promover a verificação padrão de conectividade para uma verificação de leitura e sair com código diferente de zero quando essa verificação de leitura falhar. Não pode ser combinado com `--no-probe`.
+  Atualize a sondagem de conectividade padrão para uma sondagem de leitura e saia com código diferente de zero quando essa sondagem de leitura falhar. Não pode ser combinado com `--no-probe`.
 </ParamField>

 <AccordionGroup>
-  <Accordion title="Status semantics">
-    - `gateway status` permanece disponível para diagnósticos mesmo quando a configuração local da CLI está ausente ou inválida.
+  <Accordion title="Semântica de status">
+    - `gateway status` permanece disponível para diagnósticos mesmo quando a configuração local da CLI está ausente ou é inválida.
    - O `gateway status` padrão comprova o estado do serviço, a conexão WebSocket e a capacidade de autenticação visível no momento do handshake. Ele não comprova operações de leitura/gravação/administração.
-    - As sondagens de diagnóstico não fazem mutações para autenticação inicial de dispositivo: elas reutilizam um token de dispositivo em cache existente quando houver um, mas não criam uma nova identidade de dispositivo da CLI nem um registro de pareamento de dispositivo somente leitura apenas para verificar o status.
-    - `gateway status` resolve SecretRefs de autenticação configuradas para autenticação de sondagem quando possível.
-    - Se uma SecretRef de autenticação obrigatória não for resolvida neste caminho de comando, `gateway status --json` relata `rpc.authWarning` quando a conectividade/autenticação da sondagem falha; passe `--token`/`--password` explicitamente ou resolva a origem do segredo primeiro.
-    - Se a sondagem for bem-sucedida, avisos de referência de autenticação não resolvida são suprimidos para evitar falsos positivos.
-    - Use `--require-rpc` em scripts e automação quando um serviço em escuta não for suficiente e você também precisar que chamadas RPC com escopo de leitura estejam saudáveis.
-    - `--deep` adiciona uma varredura de melhor esforço por instalações launchd/systemd/schtasks extras. Quando vários serviços semelhantes ao gateway são detectados, a saída humana imprime dicas de limpeza e avisa que a maioria das configurações deve executar um gateway por máquina.
-    - A saída humana inclui o caminho resolvido do arquivo de log mais um instantâneo dos caminhos/validade da configuração CLI versus serviço para ajudar a diagnosticar divergência de perfil ou diretório de estado.
+    - As sondagens de diagnóstico não fazem mutações para autenticação de dispositivo de primeira vez: elas reutilizam um token de dispositivo existente em cache quando ele existe, mas não criam uma nova identidade de dispositivo da CLI nem um registro de pareamento de dispositivo somente leitura apenas para verificar o status.
+    - `gateway status` resolve SecretRefs de autenticação configurados para autenticação da sondagem quando possível.
+    - Se um SecretRef de autenticação obrigatório não for resolvido nesse caminho de comando, `gateway status --json` relatará `rpc.authWarning` quando a conectividade/autenticação da sondagem falhar; passe `--token`/`--password` explicitamente ou resolva a origem do segredo primeiro.
+    - Se a sondagem for bem-sucedida, avisos de referências de autenticação não resolvidas serão suprimidos para evitar falsos positivos.
+    - Use `--require-rpc` em scripts e automação quando um serviço em escuta não for suficiente e você também precisar que chamadas RPC com escopo de leitura estejam íntegras.
+    - `--deep` adiciona uma verificação de melhor esforço por instalações extras de launchd/systemd/schtasks. Quando vários serviços semelhantes ao Gateway são detectados, a saída humana imprime dicas de limpeza e avisa que a maioria das configurações deve executar um Gateway por máquina.
+    - A saída humana inclui o caminho resolvido do log em arquivo mais um instantâneo dos caminhos/validade da configuração CLI-vs-serviço para ajudar a diagnosticar desvios de perfil ou diretório de estado.

  </Accordion>
-  <Accordion title="Linux systemd auth-drift checks">
-    - Em instalações Linux systemd, as verificações de divergência de autenticação do serviço leem valores de `Environment=` e `EnvironmentFile=` da unidade (incluindo `%h`, caminhos entre aspas, vários arquivos e arquivos opcionais com `-`).
-    - As verificações de divergência resolvem SecretRefs de `gateway.auth.token` usando o ambiente de runtime mesclado (primeiro o ambiente de comando do serviço, depois o ambiente do processo como fallback).
-    - Se a autenticação por token não estiver efetivamente ativa (`gateway.auth.mode` explícito de `password`/`none`/`trusted-proxy`, ou modo não definido em que a senha pode vencer e nenhum candidato a token pode vencer), as verificações de divergência de token ignoram a resolução do token de configuração.
+  <Accordion title="Verificações de desvio de autenticação do systemd no Linux">
+    - Em instalações Linux systemd, as verificações de desvio de autenticação do serviço leem valores `Environment=` e `EnvironmentFile=` da unidade (incluindo `%h`, caminhos entre aspas, múltiplos arquivos e arquivos opcionais com `-`).
+    - As verificações de desvio resolvem SecretRefs de `gateway.auth.token` usando o ambiente de runtime mesclado (primeiro o ambiente do comando do serviço, depois fallback para o ambiente do processo).
+    - Se a autenticação por token não estiver efetivamente ativa (`gateway.auth.mode` explícito de `password`/`none`/`trusted-proxy`, ou modo não definido em que a senha pode prevalecer e nenhum candidato a token pode prevalecer), as verificações de desvio de token pulam a resolução do token de configuração.

  </Accordion>
 </AccordionGroup>
@ -307,8 +317,8 @@ openclaw gateway status --require-rpc

 `gateway probe` é o comando de "depurar tudo". Ele sempre sonda:

- seu gateway remoto configurado (se definido), e
- localhost (loopback) **mesmo que o remoto esteja configurado**.
+- seu Gateway remoto configurado (se definido), e
+- localhost (loopback) **mesmo se o remoto estiver configurado**.

 Se você passar `--url`, esse destino explícito será adicionado antes de ambos. A saída humana rotula os destinos como:

@ -317,7 +327,7 @@ Se você passar `--url`, esse destino explícito será adicionado antes de ambos
 - `Local loopback`

 <Note>
-Se vários gateways estiverem acessíveis, ele imprime todos eles. Vários gateways são compatíveis quando você usa perfis/portas isolados (por exemplo, um bot de resgate), mas a maioria das instalações ainda executa um único gateway.
+Se vários Gateways estiverem acessíveis, ele imprime todos. Múltiplos Gateways têm suporte quando você usa perfis/portas isolados (por exemplo, um bot de resgate), mas a maioria das instalações ainda executa um único Gateway.
 </Note>

 ```bash
@ -326,52 +336,52 @@ openclaw gateway probe --json
 ```

 <AccordionGroup>
-  <Accordion title="Interpretation">
+  <Accordion title="Interpretação">
    - `Reachable: yes` significa que pelo menos um destino aceitou uma conexão WebSocket.
-    - `Capability: read-only|write-capable|admin-capable|pairing-pending|connect-only` relata o que a sondagem conseguiu comprovar sobre autenticação. Isso é separado da acessibilidade.
-    - `Read probe: ok` significa que chamadas RPC de detalhe com escopo de leitura (`health`/`status`/`system-presence`/`config.get`) também foram bem-sucedidas.
-    - `Read probe: limited - missing scope: operator.read` significa que a conexão foi bem-sucedida, mas RPC com escopo de leitura está limitada. Isso é relatado como acessibilidade **degradada**, não falha completa.
-    - `Read probe: failed` após `Connect: ok` significa que o Gateway aceitou a conexão WebSocket, mas os diagnósticos de leitura subsequentes expiraram ou falharam. Isso também é acessibilidade **degradada**, não um Gateway inacessível.
-    - Assim como `gateway status`, a sondagem reutiliza autenticação de dispositivo em cache existente, mas não cria identidade de dispositivo inicial nem estado de pareamento.
-    - O código de saída é diferente de zero somente quando nenhum destino sondado está acessível.
+    - `Capability: read-only|write-capable|admin-capable|pairing-pending|connect-only` relata o que a sondagem conseguiu comprovar sobre autenticação. Isso é separado da alcançabilidade.
+    - `Read probe: ok` significa que chamadas RPC detalhadas com escopo de leitura (`health`/`status`/`system-presence`/`config.get`) também foram bem-sucedidas.
+    - `Read probe: limited - missing scope: operator.read` significa que a conexão foi bem-sucedida, mas o RPC com escopo de leitura está limitado. Isso é relatado como alcançabilidade **degradada**, não falha total.
+    - `Read probe: failed` após `Connect: ok` significa que o Gateway aceitou a conexão WebSocket, mas os diagnósticos de leitura subsequentes atingiram o tempo limite ou falharam. Isso também é alcançabilidade **degradada**, não um Gateway inalcançável.
+    - Assim como `gateway status`, a sondagem reutiliza a autenticação de dispositivo em cache existente, mas não cria identidade de dispositivo de primeira vez nem estado de pareamento.
+    - O código de saída é diferente de zero apenas quando nenhum destino sondado está acessível.

  </Accordion>
-  <Accordion title="JSON output">
+  <Accordion title="Saída JSON">
    Nível superior:

    - `ok`: pelo menos um destino está acessível.
    - `degraded`: pelo menos um destino aceitou uma conexão, mas não concluiu todos os diagnósticos RPC detalhados.
-    - `capability`: melhor capacidade observada entre os destinos acessíveis (`read_only`, `write_capable`, `admin_capable`, `pairing_pending`, `connected_no_operator_scope` ou `unknown`).
-    - `primaryTargetId`: melhor destino a tratar como o vencedor ativo nesta ordem: URL explícita, túnel SSH, remoto configurado e depois local loopback.
+    - `capability`: melhor capacidade vista entre destinos acessíveis (`read_only`, `write_capable`, `admin_capable`, `pairing_pending`, `connected_no_operator_scope` ou `unknown`).
+    - `primaryTargetId`: melhor destino a tratar como vencedor ativo nesta ordem: URL explícita, túnel SSH, remoto configurado e depois local loopback.
    - `warnings[]`: registros de aviso de melhor esforço com `code`, `message` e `targetIds` opcionais.
    - `network`: dicas de URL de local loopback/tailnet derivadas da configuração atual e da rede do host.
-    - `discovery.timeoutMs` e `discovery.count`: o orçamento de descoberta real/contagem de resultados usado para esta passagem de sondagem.
+    - `discovery.timeoutMs` e `discovery.count`: o orçamento/contagem de resultados de descoberta reais usados nesta passagem de sondagem.

    Por destino (`targets[].connect`):

-    - `ok`: acessibilidade após conexão + classificação degradada.
-    - `rpcOk`: sucesso completo de RPC detalhado.
-    - `scopeLimited`: RPC detalhado falhou por falta de escopo de operador.
+    - `ok`: alcançabilidade após conexão + classificação degradada.
+    - `rpcOk`: sucesso total do RPC detalhado.
+    - `scopeLimited`: RPC detalhado falhou devido à ausência de escopo de operador.

    Por destino (`targets[].auth`):

    - `role`: função de autenticação relatada em `hello-ok` quando disponível.
    - `scopes`: escopos concedidos relatados em `hello-ok` quando disponíveis.
-    - `capability`: a classificação de capacidade de autenticação apresentada para esse destino.
+    - `capability`: a classificação de capacidade de autenticação exposta para esse destino.

  </Accordion>
-  <Accordion title="Common warning codes">
-    - `ssh_tunnel_failed`: a configuração do túnel SSH falhou; o comando voltou para sondagens diretas.
+  <Accordion title="Códigos de aviso comuns">
+    - `ssh_tunnel_failed`: a configuração do túnel SSH falhou; o comando recorreu a sondagens diretas.
    - `multiple_gateways`: mais de um destino estava acessível; isso é incomum, a menos que você execute intencionalmente perfis isolados, como um bot de resgate.
-    - `auth_secretref_unresolved`: uma SecretRef de autenticação configurada não pôde ser resolvida para um destino com falha.
+    - `auth_secretref_unresolved`: um SecretRef de autenticação configurado não pôde ser resolvido para um destino com falha.
    - `probe_scope_limited`: a conexão WebSocket foi bem-sucedida, mas a sondagem de leitura foi limitada pela ausência de `operator.read`.

  </Accordion>
 </AccordionGroup>

-#### Remoto por SSH (paridade com o app para Mac)
+#### Remoto via SSH (paridade com o app para Mac)

-O modo "Remote over SSH" do app macOS usa um encaminhamento de porta local para que o gateway remoto (que pode estar vinculado apenas a loopback) fique acessível em `ws://127.0.0.1:<port>`.
+O modo "Remote over SSH" do app macOS usa um encaminhamento de porta local para que o Gateway remoto (que pode estar vinculado apenas ao loopback) fique acessível em `ws://127.0.0.1:<port>`.

 Equivalente na CLI:

@ -386,7 +396,7 @@ openclaw gateway probe --ssh user@gateway-host
  Arquivo de identidade.
 </ParamField>
 <ParamField path="--ssh-auto" type="boolean">
-  Escolhe o primeiro host de gateway descoberto como destino SSH a partir do endpoint de descoberta resolvido (`local.` mais o domínio de longa distância configurado, se houver). Dicas somente TXT são ignoradas.
+  Escolha o primeiro host de Gateway descoberto como destino SSH a partir do endpoint de descoberta resolvido (`local.` mais o domínio de longa distância configurado, se houver). Dicas somente TXT são ignoradas.
 </ParamField>

 Configuração (opcional, usada como padrão):
@ -419,7 +429,7 @@ openclaw gateway call logs.tail --params '{"sinceMs": 60000}'
  Orçamento de tempo limite.
 </ParamField>
 <ParamField path="--expect-final" type="boolean">
-  Principalmente para RPCs no estilo agente que transmitem eventos intermediários antes de uma carga útil final.
+  Principalmente para RPCs no estilo agente que transmitem eventos intermediários antes de um payload final.
 </ParamField>
 <ParamField path="--json" type="boolean">
  Saída JSON legível por máquina.
@ -439,11 +449,11 @@ openclaw gateway restart
 openclaw gateway uninstall
 ```

-### Instale com um wrapper
+### Instalar com um wrapper

 Use `--wrapper` quando o serviço gerenciado precisar iniciar por meio de outro executável, por exemplo um
 shim de gerenciador de segredos ou um auxiliar run-as. O wrapper recebe os argumentos normais do Gateway e é
-responsável por eventualmente executar `openclaw` ou Node com esses argumentos.
+responsável por eventualmente executar `openclaw` ou Node com esses argumentos via exec.

 ```bash
 cat > ~/.local/bin/openclaw-doppler <<'EOF'
@ -459,14 +469,15 @@ openclaw gateway restart

 Você também pode definir o wrapper pelo ambiente. `gateway install` valida que o caminho é
 um arquivo executável, grava o wrapper em `ProgramArguments` do serviço e persiste
-`OPENCLAW_WRAPPER` no ambiente do serviço para reinstalações forçadas, atualizações e reparos do doctor posteriores.
+`OPENCLAW_WRAPPER` no ambiente do serviço para reinstalações forçadas, atualizações e reparos do doctor
+posteriores.

 ```bash
 OPENCLAW_WRAPPER="$HOME/.local/bin/openclaw-doppler" openclaw gateway install --force
 openclaw doctor
 ```

-Para remover um wrapper persistido, limpe `OPENCLAW_WRAPPER` ao reinstalar:
+Para remover um wrapper persistido, limpe `OPENCLAW_WRAPPER` durante a reinstalação:

 ```bash
 OPENCLAW_WRAPPER= openclaw gateway install --force
@ -474,48 +485,48 @@ openclaw gateway restart
 ```

 <AccordionGroup>
-  <Accordion title="Command options">
+  <Accordion title="Opções de comando">
    - `gateway status`: `--url`, `--token`, `--password`, `--timeout`, `--no-probe`, `--require-rpc`, `--deep`, `--json`
    - `gateway install`: `--port`, `--runtime <node|bun>`, `--token`, `--wrapper <path>`, `--force`, `--json`
    - `gateway restart`: `--force`, `--wait <duration>`, `--json`
    - `gateway uninstall|start|stop`: `--json`

  </Accordion>
-  <Accordion title="Lifecycle behavior">
+  <Accordion title="Comportamento do ciclo de vida">
    - Use `gateway restart` para reiniciar um serviço gerenciado. Não encadeie `gateway stop` e `gateway start` como substituto de reinicialização; no macOS, `gateway stop` desativa intencionalmente o LaunchAgent antes de pará-lo.
-    - `gateway restart --wait 30s` substitui o orçamento configurado de drenagem de reinicialização para essa reinicialização. Números sem unidade são milissegundos; unidades como `s`, `m` e `h` são aceitas. `--wait 0` espera indefinidamente.
-    - `gateway restart --force` ignora a drenagem de trabalho ativo e reinicia imediatamente. Use quando um operador já tiver inspecionado os bloqueadores de tarefa listados e quiser o gateway de volta agora.
-    - Comandos de ciclo de vida aceitam `--json` para scripting.
+    - `gateway restart --wait 30s` substitui o orçamento configurado de drenagem de reinicialização para essa reinicialização. Números sem unidade são milissegundos; unidades como `s`, `m` e `h` são aceitas. `--wait 0` aguarda indefinidamente.
+    - `gateway restart --force` pula a drenagem de trabalho ativo e reinicia imediatamente. Use quando um operador já tiver inspecionado os bloqueadores de tarefas listados e quiser o Gateway de volta agora.
+    - Comandos de ciclo de vida aceitam `--json` para scripts.

  </Accordion>
-  <Accordion title="Auth and SecretRefs at install time">
-    - Quando a autenticação por token exige um token e `gateway.auth.token` é gerenciada por SecretRef, `gateway install` valida que a SecretRef é resolvível, mas não persiste o token resolvido nos metadados de ambiente do serviço.
-    - Se a autenticação por token exigir um token e a SecretRef de token configurada não for resolvida, a instalação falha de modo fechado em vez de persistir texto simples de fallback.
-    - Para autenticação por senha em `gateway run`, prefira `OPENCLAW_GATEWAY_PASSWORD`, `--password-file` ou um `gateway.auth.password` respaldado por SecretRef em vez de `--password` inline.
-    - No modo de autenticação inferido, `OPENCLAW_GATEWAY_PASSWORD` apenas no shell não afrouxa os requisitos de token de instalação; use configuração durável (`gateway.auth.password` ou `env` de configuração) ao instalar um serviço gerenciado.
+  <Accordion title="Autenticação e SecretRefs no momento da instalação">
+    - Quando a autenticação por token requer um token e `gateway.auth.token` é gerenciado por SecretRef, `gateway install` valida que o SecretRef pode ser resolvido, mas não persiste o token resolvido nos metadados de ambiente do serviço.
+    - Se a autenticação por token requer um token e o SecretRef de token configurado não é resolvido, a instalação falha de forma fechada em vez de persistir fallback em texto claro.
+    - Para autenticação por senha em `gateway run`, prefira `OPENCLAW_GATEWAY_PASSWORD`, `--password-file` ou um `gateway.auth.password` com suporte de SecretRef em vez de `--password` inline.
+    - No modo de autenticação inferido, `OPENCLAW_GATEWAY_PASSWORD` apenas no shell não relaxa os requisitos de token de instalação; use configuração durável (`gateway.auth.password` ou `env` de configuração) ao instalar um serviço gerenciado.
    - Se `gateway.auth.token` e `gateway.auth.password` estiverem configurados e `gateway.auth.mode` não estiver definido, a instalação será bloqueada até que o modo seja definido explicitamente.

  </Accordion>
 </AccordionGroup>

-## Descubra gateways (Bonjour)
+## Descobrir Gateways (Bonjour)

-`gateway discover` procura beacons do Gateway (`_openclaw-gw._tcp`).
+`gateway discover` verifica beacons do Gateway (`_openclaw-gw._tcp`).

- DNS-SD multicast: `local.`
- DNS-SD unicast (Bonjour de longa distância): escolha um domínio (exemplo: `openclaw.internal.`) e configure DNS dividido + um servidor DNS; consulte [Bonjour](/pt-BR/gateway/bonjour).
+- Multicast DNS-SD: `local.`
+- Unicast DNS-SD (Bonjour de área ampla): escolha um domínio (exemplo: `openclaw.internal.`) e configure DNS dividido + um servidor DNS; consulte [Bonjour](/pt-BR/gateway/bonjour).

-Somente gateways com descoberta Bonjour habilitada (padrão) anunciam o beacon.
+Somente gateways com descoberta Bonjour habilitada (padrão) anunciam o sinalizador.

-Registros de descoberta de longa distância incluem (TXT):
+Registros de descoberta de área ampla incluem (TXT):

 - `role` (dica de função do gateway)
 - `transport` (dica de transporte, por exemplo, `gateway`)
 - `gatewayPort` (porta WebSocket, geralmente `18789`)
- `sshPort` (opcional; clientes usam `22` como padrão para destinos SSH quando ausente)
+- `sshPort` (opcional; clientes usam `22` como destino SSH padrão quando ausente)
 - `tailnetDns` (nome de host MagicDNS, quando disponível)
 - `gatewayTls` / `gatewayTlsSha256` (TLS habilitado + impressão digital do certificado)
- `cliPath` (dica de instalação remota gravada na zona de longa distância)
+- `cliPath` (dica de instalação remota gravada na zona de área ampla)

 ### `gateway discover`

@ -527,7 +538,7 @@ openclaw gateway discover
  Tempo limite por comando (busca/resolução).
 </ParamField>
 <ParamField path="--json" type="boolean">
-  Saída legível por máquina (também desativa estilos/spinner).
+  Saída legível por máquina (também desabilita estilo/spinner).
 </ParamField>

 Exemplos:
@ -538,13 +549,13 @@ openclaw gateway discover --json | jq '.beacons[].wsUrl'
 ```

 <Note>
- A CLI verifica `local.` mais o domínio de longa distância configurado quando um está habilitado.
+- A CLI examina `local.` mais o domínio de área ampla configurado quando um está habilitado.
 - `wsUrl` na saída JSON é derivado do endpoint de serviço resolvido, não de dicas apenas em TXT, como `lanHost` ou `tailnetDns`.
- No mDNS `local.`, `sshPort` e `cliPath` só são transmitidos quando `discovery.mdns.mode` é `full`. DNS-SD de longa distância ainda grava `cliPath`; `sshPort` continua opcional ali também.
+- Em mDNS `local.`, `sshPort` e `cliPath` só são transmitidos quando `discovery.mdns.mode` é `full`. DNS-SD de área ampla ainda grava `cliPath`; `sshPort` também permanece opcional lá.

 </Note>

-## Relacionado
+## Relacionados

 - [Referência da CLI](/pt-BR/cli)
- [Manual operacional do Gateway](/pt-BR/gateway)
+- [Runbook do Gateway](/pt-BR/gateway)
--- a/docs/pt-BR/cli/models.md
+++ b/docs/pt-BR/cli/models.md
@ -1,14 +1,14 @@
 ---
 read_when:
-    - Você quer alterar os modelos padrão ou ver o status de autenticação do provedor
+    - Você quer alterar os modelos padrão ou visualizar o status de autenticação do provedor
    - Você quer examinar os modelos/provedores disponíveis e depurar perfis de autenticação
-summary: Referência da CLI para `openclaw models` (status/list/set/scan, apelidos, alternativas, autenticação)
+summary: Referência da CLI para `openclaw models` (status/list/set/scan, apelidos, alternativas de contingência, autenticação)
 title: Modelos
 x-i18n:
-    generated_at: "2026-05-01T05:55:10Z"
+    generated_at: "2026-05-04T18:23:40Z"
    model: gpt-5.5
    provider: openai
-    source_hash: 538d3e4808329737fdc044dc6e14e5c7c78052e75d8a8b3b257b1ebd821c84d1
+    source_hash: dc7842f02e29aa0ac2ae88f3d42bba71f1890a58ab22d818dbee0585bc562fea
    source_path: cli/models.md
    workflow: 16
 ---
@ -17,11 +17,11 @@ x-i18n:

 Descoberta, varredura e configuração de modelos (modelo padrão, fallbacks, perfis de autenticação).

-Relacionados:
+Relacionado:

 - Provedores + modelos: [Modelos](/pt-BR/providers/models)
 - Conceitos de seleção de modelo + comando de barra `/models`: [Conceito de modelos](/pt-BR/concepts/models)
- Configuração de autenticação de provedor: [Primeiros passos](/pt-BR/start/getting-started)
+- Configuração de autenticação do provedor: [Primeiros passos](/pt-BR/start/getting-started)

 ## Comandos comuns

@ -33,81 +33,81 @@ openclaw models scan
 ```

 `openclaw models status` mostra o padrão/fallbacks resolvidos, além de uma visão geral de autenticação.
-Quando snapshots de uso do provedor estão disponíveis, a seção de status de OAuth/chave de API inclui
-janelas de uso do provedor e snapshots de cota.
-Provedores atuais com janela de uso: Anthropic, GitHub Copilot, Gemini CLI, OpenAI
+Quando instantâneos de uso do provedor estão disponíveis, a seção de status OAuth/chave de API inclui
+janelas de uso do provedor e instantâneos de cota.
+Provedores atuais de janela de uso: Anthropic, GitHub Copilot, Gemini CLI, OpenAI
 Codex, MiniMax, Xiaomi e z.ai. A autenticação de uso vem de hooks específicos do provedor
-quando disponíveis; caso contrário, o OpenClaw recorre a credenciais OAuth/chave de API
-correspondentes de perfis de autenticação, env ou configuração.
-Na saída `--json`, `auth.providers` é a visão geral de provedores ciente de env/config/store,
-enquanto `auth.oauth` é apenas a integridade de perfis do armazenamento de autenticação.
-Adicione `--probe` para executar probes de autenticação ao vivo em cada perfil de provedor configurado.
-Probes são solicitações reais (podem consumir tokens e acionar limites de taxa).
+quando disponíveis; caso contrário, o OpenClaw recorre a credenciais
+OAuth/chave de API correspondentes de perfis de autenticação, env ou configuração.
+Na saída `--json`, `auth.providers` é a visão geral do provedor ciente de env/configuração/store,
+enquanto `auth.oauth` é apenas a integridade do perfil do store de autenticação.
+Adicione `--probe` para executar sondagens de autenticação ao vivo contra cada perfil de provedor configurado.
+Sondagens são solicitações reais (podem consumir tokens e acionar limites de taxa).
 Use `--agent <id>` para inspecionar o estado de modelo/autenticação de um agente configurado. Quando omitido,
 o comando usa `OPENCLAW_AGENT_DIR`/`PI_CODING_AGENT_DIR` se definido; caso contrário, usa o
 agente padrão configurado.
-Linhas de probe podem vir de perfis de autenticação, credenciais env ou `models.json`.
+Linhas de sondagem podem vir de perfis de autenticação, credenciais env ou `models.json`.

 Observações:

 - `models set <model-or-alias>` aceita `provider/model` ou um alias.
- `models list` é somente leitura: ele lê a configuração, perfis de autenticação, estado de catálogo
-  existente e linhas de catálogo pertencentes ao provedor, mas não reescreve
+- `models list` é somente leitura: ele lê configuração, perfis de autenticação, estado existente do catálogo
+  e linhas de catálogo pertencentes ao provedor, mas não reescreve
  `models.json`.
- A coluna `Auth` é em nível de provedor e somente leitura. Ela é calculada a partir de metadados
-  locais de perfil de autenticação, marcadores env, chaves de provedor configuradas, marcadores de
-  provedor local, marcadores env/perfil do AWS Bedrock e metadados de autenticação sintética de Plugin;
-  ela não carrega o runtime do provedor, não lê segredos do keychain, não chama APIs do provedor
-  nem comprova prontidão exata de execução por modelo.
+- A coluna `Auth` é em nível de provedor e somente leitura. Ela é calculada com base em
+  metadados locais de perfil de autenticação, marcadores env, chaves de provedor configuradas, marcadores
+  de provedor local, marcadores env/perfil do AWS Bedrock e metadados de autenticação sintética de plugin;
+  ela não carrega o runtime do provedor, não lê segredos do keychain, não chama APIs
+  do provedor nem comprova a prontidão exata de execução por modelo.
 - `models list --all --provider <id>` pode incluir linhas de catálogo estático pertencentes ao provedor
-  vindas de manifestos de Plugin ou metadados de catálogo de provedor incluído, mesmo quando você
+  de manifestos de plugin ou metadados de catálogo de provedor incluídos, mesmo quando você
  ainda não se autenticou com esse provedor. Essas linhas ainda aparecem como
  indisponíveis até que a autenticação correspondente seja configurada.
 - `models list` mantém o plano de controle responsivo enquanto a descoberta de catálogo do provedor
  está lenta. As visualizações padrão e configurada recorrem a linhas de modelo configuradas ou
-  sintéticas após uma espera curta e deixam a descoberta terminar em
-  segundo plano. Use `--all` quando precisar do catálogo descoberto completo exato e
+  sintéticas após uma espera curta e permitem que a descoberta termine em segundo
+  plano. Use `--all` quando precisar do catálogo descoberto completo e exato e
  estiver disposto a esperar pela descoberta do provedor.
- `models list --all` amplo mescla linhas de catálogo de manifesto sobre linhas de registro
-  sem carregar hooks suplementares do runtime do provedor. Caminhos rápidos de manifesto filtrados por provedor
+- `models list --all` amplo mescla linhas de catálogo de manifesto sobre linhas do registro
+  sem carregar hooks suplementares de runtime do provedor. Caminhos rápidos de manifesto filtrados por provedor
  usam apenas provedores marcados como `static`; provedores marcados como `refreshable`
-  permanecem apoiados por registro/cache e acrescentam linhas de manifesto como suplementos, enquanto
-  provedores marcados como `runtime` permanecem em descoberta de registro/runtime.
- `models list` mantém metadados nativos de modelo e limites de runtime distintos. Na saída em tabela,
+  permanecem baseados em registro/cache e anexam linhas de manifesto como suplementos, enquanto
+  provedores marcados como `runtime` permanecem na descoberta de registro/runtime.
+- `models list` mantém metadados nativos do modelo e limites de runtime distintos. Na saída em tabela,
  `Ctx` mostra `contextTokens/contextWindow` quando um limite efetivo de runtime
  difere da janela de contexto nativa; linhas JSON incluem `contextTokens`
  quando um provedor expõe esse limite.
- `models list --provider <id>` filtra por id do provedor, como `moonshot` ou
+- `models list --provider <id>` filtra por id de provedor, como `moonshot` ou
  `openai-codex`. Ele não aceita rótulos de exibição de seletores interativos de provedor,
  como `Moonshot AI`.
 - Referências de modelo são analisadas dividindo na **primeira** `/`. Se o ID do modelo incluir `/` (estilo OpenRouter), inclua o prefixo do provedor (exemplo: `openrouter/moonshotai/kimi-k2`).
 - Se você omitir o provedor, o OpenClaw resolve a entrada primeiro como um alias, depois
-  como uma correspondência única de provedor configurado para esse id de modelo exato, e só então
+  como uma correspondência única de provedor configurado para esse id de modelo exato e só então
  recorre ao provedor padrão configurado com um aviso de depreciação.
  Se esse provedor não expuser mais o modelo padrão configurado, o OpenClaw
-  recorre ao primeiro provedor/modelo configurado em vez de mostrar um
+  recorre ao primeiro provedor/modelo configurado em vez de expor um
  padrão obsoleto de provedor removido.
- `models status` pode mostrar `marker(<value>)` na saída de autenticação para placeholders não secretos (por exemplo `OPENAI_API_KEY`, `secretref-managed`, `minimax-oauth`, `oauth:chutes`, `ollama-local`) em vez de mascará-los como segredos.
+- `models status` pode mostrar `marker(<value>)` na saída de autenticação para placeholders não secretos (por exemplo, `OPENAI_API_KEY`, `secretref-managed`, `minimax-oauth`, `oauth:chutes`, `ollama-local`) em vez de mascará-los como segredos.

 ### Varredura de modelos

 `models scan` lê o catálogo público `:free` do OpenRouter e classifica candidatos para
-uso como fallback. O catálogo em si é público, então varreduras apenas de metadados não precisam
-de uma chave do OpenRouter.
+uso como fallback. O catálogo em si é público, portanto varreduras apenas de metadados não precisam de
+uma chave do OpenRouter.

-Por padrão, o OpenClaw tenta testar suporte a ferramentas e imagens com chamadas de modelo ao vivo.
+Por padrão, o OpenClaw tenta sondar suporte a ferramentas e imagens com chamadas de modelo ao vivo.
 Se nenhuma chave do OpenRouter estiver configurada, o comando recorre à saída apenas de metadados
 e explica que modelos `:free` ainda exigem `OPENROUTER_API_KEY` para
-probes e inferência.
+sondagens e inferência.

 Opções:

- `--no-probe` (somente metadados; sem consulta de config/segredos)
+- `--no-probe` (somente metadados; sem consulta de configuração/segredos)
 - `--min-params <b>`
 - `--max-age-days <days>`
 - `--provider <name>`
 - `--max-candidates <n>`
- `--timeout <ms>` (solicitação de catálogo e timeout por probe)
+- `--timeout <ms>` (solicitação de catálogo e timeout por sondagem)
 - `--concurrency <n>`
 - `--yes`
 - `--no-input`
@ -115,29 +115,29 @@ Opções:
 - `--set-image`
 - `--json`

-`--set-default` e `--set-image` exigem probes ao vivo; resultados de varredura
-apenas de metadados são informativos e não são aplicados à configuração.
+`--set-default` e `--set-image` exigem sondagens ao vivo; resultados de varredura
+somente de metadados são informativos e não são aplicados à configuração.

-### Status de modelos
+### Status dos modelos

 Opções:

 - `--json`
 - `--plain`
- `--check` (exit 1=expirado/ausente, 2=expirando)
- `--probe` (probe ao vivo dos perfis de autenticação configurados)
- `--probe-provider <name>` (testar um provedor)
- `--probe-profile <id>` (repetir ou ids de perfil separados por vírgula)
+- `--check` (sai com 1=expirado/ausente, 2=expirando)
+- `--probe` (sondagem ao vivo dos perfis de autenticação configurados)
+- `--probe-provider <name>` (sonda um provedor)
+- `--probe-profile <id>` (repita ou use ids de perfil separados por vírgula)
 - `--probe-timeout <ms>`
 - `--probe-concurrency <n>`
 - `--probe-max-tokens <n>`
- `--agent <id>` (id de agente configurado; substitui `OPENCLAW_AGENT_DIR`/`PI_CODING_AGENT_DIR`)
+- `--agent <id>` (id do agente configurado; substitui `OPENCLAW_AGENT_DIR`/`PI_CODING_AGENT_DIR`)

 `--json` mantém stdout reservado para o payload JSON. Diagnósticos de perfil de autenticação, provedor
 e inicialização são roteados para stderr para que scripts possam encaminhar stdout diretamente
 para ferramentas como `jq`.

-Buckets de status de probe:
+Buckets de status de sondagem:

 - `ok`
 - `auth`
@ -148,15 +148,15 @@ Buckets de status de probe:
 - `unknown`
 - `no_model`

-Casos de código de detalhe/motivo de probe esperados:
+Casos de detalhe/código de motivo de sondagem esperados:

- `excluded_by_auth_order`: existe um perfil armazenado, mas `auth.order.<provider>` explícito
-  o omitiu, então o probe relata a exclusão em vez de
+- `excluded_by_auth_order`: existe um perfil armazenado, mas
+  `auth.order.<provider>` explícito o omitiu, então a sondagem relata a exclusão em vez de
  tentar usá-lo.
 - `missing_credential`, `invalid_expires`, `expired`, `unresolved_ref`:
  o perfil está presente, mas não é elegível/resolvível.
- `no_model`: existe autenticação do provedor, mas o OpenClaw não conseguiu resolver um candidato
-  de modelo testável para esse provedor.
+- `no_model`: a autenticação do provedor existe, mas o OpenClaw não conseguiu resolver um candidato
+  de modelo sondável para esse provedor.

 ## Aliases + fallbacks

@ -169,25 +169,32 @@ openclaw models fallbacks list

 ```bash
 openclaw models auth add
+openclaw models auth list [--provider <id>] [--json]
 openclaw models auth login --provider <id>
 openclaw models auth setup-token --provider <id>
 openclaw models auth paste-token
 ```

 `models auth add` é o auxiliar interativo de autenticação. Ele pode iniciar um fluxo de autenticação
-de provedor (OAuth/chave de API) ou guiar você para colar um token manualmente, dependendo do
+do provedor (OAuth/chave de API) ou orientar você para a colagem manual de token, dependendo do
 provedor escolhido.

-`models auth login` executa o fluxo de autenticação de um Plugin de provedor (OAuth/chave de API). Use
+`models auth list` lista perfis de autenticação salvos para o agente selecionado sem
+imprimir token, chave de API ou material secreto OAuth. Use `--provider <id>` para
+filtrar por um provedor, como `openai-codex`, e `--json` para scripting.
+
+`models auth login` executa o fluxo de autenticação de um plugin de provedor (OAuth/chave de API). Use
 `openclaw plugins list` para ver quais provedores estão instalados.
 Use `openclaw models auth --agent <id> <subcommand>` para gravar resultados de autenticação em um
-armazenamento específico de agente configurado. A flag pai `--agent` é respeitada por
-`add`, `login`, `setup-token`, `paste-token` e `login-github-copilot`.
+store específico de agente configurado. A flag pai `--agent` é respeitada por
+`add`, `list`, `login`, `setup-token`, `paste-token` e
+`login-github-copilot`.

 Exemplos:

 ```bash
 openclaw models auth login --provider openai-codex --set-default
+openclaw models auth list --provider openai-codex
 ```

 Observações:
@ -201,12 +208,12 @@ Observações:
 - `paste-token` exige `--provider`, solicita o valor do token e o grava
  no id de perfil padrão `<provider>:manual`, a menos que você passe
  `--profile-id`.
- `paste-token --expires-in <duration>` armazena uma expiração absoluta de token a partir de uma
+- `paste-token --expires-in <duration>` armazena uma expiração absoluta do token a partir de uma
  duração relativa, como `365d` ou `12h`.
- Observação sobre Anthropic: a equipe da Anthropic nos informou que o uso do Claude CLI no estilo OpenClaw voltou a ser permitido, então o OpenClaw trata a reutilização do Claude CLI e o uso de `claude -p` como sancionados para esta integração, a menos que a Anthropic publique uma nova política.
- Anthropic `setup-token` / `paste-token` continuam disponíveis como um caminho de token do OpenClaw com suporte, mas o OpenClaw agora prefere reutilizar o Claude CLI e `claude -p` quando disponíveis.
+- Observação sobre Anthropic: a equipe da Anthropic nos disse que o uso no estilo Claude CLI do OpenClaw é permitido novamente, então o OpenClaw trata a reutilização da Claude CLI e o uso de `claude -p` como sancionados para esta integração, a menos que a Anthropic publique uma nova política.
+- Anthropic `setup-token` / `paste-token` continuam disponíveis como um caminho de token OpenClaw compatível, mas o OpenClaw agora prefere reutilização da Claude CLI e `claude -p` quando disponíveis.

-## Relacionados
+## Relacionado

 - [Referência da CLI](/pt-BR/cli)
 - [Seleção de modelo](/pt-BR/concepts/model-providers)
--- a/docs/pt-BR/cli/proxy.md
+++ b/docs/pt-BR/cli/proxy.md
@ -1,36 +1,36 @@
 ---
 read_when:
    - Você precisa validar o roteamento de proxy gerenciado pelo operador antes da implantação
-    - Você precisa capturar o tráfego de transporte do OpenClaw localmente para depuração
-    - Você quer inspecionar sessões do proxy de depuração, blobs ou predefinições de consulta integradas
-summary: Referência da CLI para `openclaw proxy`, incluindo validação de proxy gerenciado pelo operador e o inspetor local de captura do proxy de depuração
+    - Você precisa capturar localmente o tráfego de transporte do OpenClaw para depuração
+    - Você quer inspecionar sessões de proxy de depuração, blobs ou predefinições de consulta integradas
+summary: Referência da CLI para `openclaw proxy`, incluindo validação de proxy gerenciado pelo operador e o inspetor de captura do proxy de depuração local
 title: Proxy
 x-i18n:
-    generated_at: "2026-05-04T05:52:05Z"
+    generated_at: "2026-05-04T18:23:48Z"
    model: gpt-5.5
    provider: openai
-    source_hash: 9589bedafb97c31bcb6536a04307cd0c6550e1f307693bd4401785d79f34a1eb
+    source_hash: 092c4e946dcab5e78e37d6fc77bb067b7a649368f8571fa127e462a85fa14ce5
    source_path: cli/proxy.md
    workflow: 16
 ---

 # `openclaw proxy`

-Valide o roteamento de proxy gerenciado pelo operador ou execute o proxy de depuração explícito local
+Valide o roteamento de proxy gerenciado pelo operador, ou execute o proxy de depuração explícito local
 e inspecione o tráfego capturado.

-Use `validate` para verificar previamente um proxy de encaminhamento gerenciado pelo operador antes de habilitar
+Use `validate` para fazer uma pré-verificação de um proxy de encaminhamento gerenciado pelo operador antes de habilitar
 o roteamento de proxy do OpenClaw. Os outros comandos são ferramentas de depuração para
-investigação no nível de transporte: eles podem iniciar um proxy local, executar um comando filho
+investigação em nível de transporte: eles podem iniciar um proxy local, executar um comando filho
 com captura habilitada, listar sessões de captura, consultar padrões comuns de tráfego, ler
-blobs capturados e limpar dados locais de captura.
+blobs capturados e limpar dados de captura locais.

 ## Comandos

 ```bash
 openclaw proxy start [--host <host>] [--port <port>]
 openclaw proxy run [--host <host>] [--port <port>] -- <cmd...>
-openclaw proxy validate [--json] [--proxy-url <url>] [--allowed-url <url>] [--denied-url <url>] [--timeout-ms <ms>]
+openclaw proxy validate [--json] [--proxy-url <url>] [--allowed-url <url>] [--denied-url <url>] [--apns-reachable] [--apns-authority <url>] [--timeout-ms <ms>]
 openclaw proxy coverage
 openclaw proxy sessions [--limit <count>]
 openclaw proxy query --preset <name> [--session <id>]
@ -42,22 +42,27 @@ openclaw proxy purge

 `openclaw proxy validate` verifica a URL efetiva do proxy gerenciado pelo operador a partir de
 `--proxy-url`, da configuração ou de `OPENCLAW_PROXY_URL`. Ele relata um problema de configuração quando
-nenhum proxy está habilitado e configurado; use `--proxy-url` para uma verificação prévia pontual
-antes de alterar a configuração. Por padrão, ele verifica se um destino público funciona
-por meio do proxy e se o proxy não consegue alcançar um canário de loopback temporário.
-Destinos negados personalizados falham fechados: respostas HTTP e falhas ambíguas de
-transporte também falham, a menos que você possa verificar separadamente um sinal de negação
-específico da implantação.
+nenhum proxy está habilitado e configurado; use `--proxy-url` para uma pré-verificação pontual
+antes de alterar a configuração. Por padrão, ele verifica que um destino público tem êxito
+por meio do proxy e que o proxy não consegue alcançar um canário temporário de loopback.
+Destinos negados personalizados falham de modo fechado: respostas HTTP e falhas de
+transporte ambíguas falham, a menos que você consiga verificar separadamente um sinal de negação
+específico da implantação. Adicione `--apns-reachable` para também abrir um túnel CONNECT
+HTTP/2 de APNs por meio do proxy e confirmar que o APNs de sandbox responde; a sondagem usa um
+token de provedor intencionalmente inválido, portanto uma resposta APNs `403 InvalidProviderToken`
+é um sinal de acessibilidade bem-sucedido.

 Opções:

 - `--json`: imprime JSON legível por máquina.
 - `--proxy-url <url>`: valida esta URL de proxy em vez da configuração ou do ambiente.
- `--allowed-url <url>`: adiciona um destino esperado para funcionar por meio do proxy. Repita para verificar vários destinos.
- `--denied-url <url>`: adiciona um destino esperado para ser bloqueado pelo proxy. Repita para verificar vários destinos.
- `--timeout-ms <ms>`: tempo limite por solicitação em milissegundos.
+- `--allowed-url <url>`: adiciona um destino que deve ter êxito por meio do proxy. Repita para verificar vários destinos.
+- `--denied-url <url>`: adiciona um destino que deve ser bloqueado pelo proxy. Repita para verificar vários destinos.
+- `--apns-reachable`: também verifica se o HTTP/2 de APNs de sandbox é acessível por meio do proxy.
+- `--apns-authority <url>`: autoridade de APNs a sondar com `--apns-reachable` (`https://api.sandbox.push.apple.com` por padrão; produção é `https://api.push.apple.com`).
+- `--timeout-ms <ms>`: tempo limite por requisição em milissegundos.

-Consulte [Proxy de rede](/pt-BR/security/network-proxy) para orientações de implantação e semântica
+Consulte [Proxy de rede](/pt-BR/security/network-proxy) para obter orientação de implantação e semântica
 de negação.

 ## Predefinições de consulta
@ -74,12 +79,12 @@ de negação.
 ## Observações

 - `start` usa `127.0.0.1` por padrão, a menos que `--host` seja definido.
- `run` inicia um proxy de depuração local e então executa o comando após `--`.
- O encaminhamento direto para upstream do proxy de depuração abre sockets upstream para diagnósticos. Quando o modo de proxy gerenciado do OpenClaw está ativo, o encaminhamento direto para solicitações de proxy e túneis CONNECT fica desabilitado por padrão; defina `OPENCLAW_DEBUG_PROXY_ALLOW_DIRECT_CONNECT_WITH_MANAGED_PROXY=1` apenas para diagnósticos locais aprovados.
+- `run` inicia um proxy de depuração local e depois executa o comando após `--`.
+- O encaminhamento direto upstream do proxy de depuração abre sockets upstream para diagnóstico. Quando o modo de proxy gerenciado do OpenClaw está ativo, o encaminhamento direto para requisições de proxy e túneis CONNECT é desabilitado por padrão; defina `OPENCLAW_DEBUG_PROXY_ALLOW_DIRECT_CONNECT_WITH_MANAGED_PROXY=1` apenas para diagnósticos locais aprovados.
 - `validate` sai com código 1 quando a configuração do proxy ou as verificações de destino falham.
- Capturas são dados de depuração locais; use `openclaw proxy purge` quando terminar.
+- Capturas são dados de depuração locais; use `openclaw proxy purge` ao terminar.

-## Relacionados
+## Relacionado

 - [Referência da CLI](/pt-BR/cli)
 - [Proxy de rede](/pt-BR/security/network-proxy)
--- a/docs/pt-BR/gateway/cli-backends.md
+++ b/docs/pt-BR/gateway/cli-backends.md
@ -1,20 +1,20 @@
 ---
 read_when:
    - Você quer uma alternativa confiável quando os provedores de API falham
-    - Você está executando o Codex CLI ou outras CLIs de IA locais e quer reutilizá-las
-    - Você quer entender a ponte de loopback MCP para acesso às ferramentas de suporte da CLI
-summary: 'Back-ends de CLI: alternativa de reserva de CLI de IA local com ponte opcional para ferramentas MCP'
-title: Back-ends da CLI
+    - Você está executando o Codex CLI ou outras CLIs locais de IA e quer reutilizá-las
+    - Você quer entender a ponte de retorno MCP para acesso a ferramentas de back-end da CLI
+summary: 'Backends de CLI: alternativa local de CLI de IA com ponte opcional de ferramentas MCP'
+title: Backends da CLI
 x-i18n:
-    generated_at: "2026-05-02T20:46:23Z"
+    generated_at: "2026-05-04T18:23:47Z"
    model: gpt-5.5
    provider: openai
-    source_hash: f343469d6a42dc6146196355dc2ba3feed045515c3d8446941b90971aadc9a16
+    source_hash: 55534c48c5e226857b9320fd369416583e5c2efc80eabd4746f939afdd027dc1
    source_path: gateway/cli-backends.md
    workflow: 16
 ---

-OpenClaw pode executar **CLIs locais de IA** como um **fallback somente texto** quando provedores de API estiverem fora do ar,
+OpenClaw pode executar **CLIs de IA locais** como um **fallback somente texto** quando provedores de API estão indisponíveis,
 com limite de taxa ou temporariamente se comportando mal. Isso é intencionalmente conservador:

 - **As ferramentas do OpenClaw não são injetadas diretamente**, mas backends com `bundleMcp: true`
@ -23,23 +23,23 @@ com limite de taxa ou temporariamente se comportando mal. Isso é intencionalmen
 - **Sessões são compatíveis** (para que turnos de acompanhamento permaneçam coerentes).
 - **Imagens podem ser repassadas** se a CLI aceitar caminhos de imagem.

-Isso foi projetado como uma **rede de segurança**, não como um caminho primário. Use quando você
-quiser respostas de texto que “sempre funcionem” sem depender de APIs externas.
+Isso foi projetado como uma **rede de segurança**, e não como o caminho principal. Use quando você
+quiser respostas de texto que “sempre funcionam” sem depender de APIs externas.

-Se você quiser um runtime de harness completo com controles de sessão ACP, tarefas em segundo plano,
-vinculação de thread/conversa e sessões externas persistentes de codificação, use
-[Agentes ACP](/pt-BR/tools/acp-agents). Backends de CLI não são ACP.
+Se você quer um runtime de harness completo com controles de sessão ACP, tarefas em segundo plano,
+vinculação de thread/conversa e sessões externas persistentes de programação, use
+[Agentes ACP](/pt-BR/tools/acp-agents) em vez disso. Backends de CLI não são ACP.

 ## Início rápido para iniciantes

-Você pode usar o Codex CLI **sem nenhuma configuração** (o Plugin OpenAI incluído
+Você pode usar a CLI do Codex **sem nenhuma configuração** (o Plugin OpenAI integrado
 registra um backend padrão):

 ```bash
 openclaw agent --message "hi" --model codex-cli/gpt-5.5
 ```

-Se o seu gateway roda sob launchd/systemd e o PATH é mínimo, adicione apenas o
+Se seu gateway roda sob launchd/systemd e o PATH é mínimo, adicione apenas o
 caminho do comando:

 ```json5
@ -56,16 +56,16 @@ caminho do comando:
 }
 ```

-É só isso. Nenhuma chave, nenhuma configuração extra de autenticação necessária além da própria CLI.
+É isso. Nenhuma chave, nenhuma configuração extra de autenticação necessária além da própria CLI.

-Se você usa um backend de CLI incluído como o **provedor primário de mensagens** em um
-host de gateway, o OpenClaw agora carrega automaticamente o Plugin incluído proprietário quando sua configuração
-referencia explicitamente esse backend em uma referência de modelo ou em
+Se você usar um backend de CLI integrado como o **provedor principal de mensagens** em um
+host de gateway, o OpenClaw agora carrega automaticamente o Plugin integrado proprietário quando sua configuração
+faz referência explícita a esse backend em uma ref de modelo ou em
 `agents.defaults.cliBackends`.

 ## Usando como fallback

-Adicione um backend de CLI à sua lista de fallback para que ele só execute quando os modelos primários falharem:
+Adicione um backend de CLI à sua lista de fallbacks para que ele só rode quando os modelos principais falharem:

 ```json5
 {
@ -86,8 +86,8 @@ Adicione um backend de CLI à sua lista de fallback para que ele só execute qua

 Observações:

- Se você usa `agents.defaults.models` (lista de permissões), também deve incluir seus modelos de backend de CLI ali.
- Se o provedor primário falhar (autenticação, limites de taxa, tempos limite), o OpenClaw
+- Se você usar `agents.defaults.models` (lista de permissão), também deverá incluir seus modelos de backend de CLI ali.
+- Se o provedor principal falhar (autenticação, limites de taxa, timeouts), o OpenClaw
  tentará o backend de CLI em seguida.

 ## Visão geral da configuração
@ -99,7 +99,7 @@ agents.defaults.cliBackends
 ```

 Cada entrada é identificada por um **id de provedor** (por exemplo, `codex-cli`, `my-cli`).
-O id de provedor se torna o lado esquerdo da sua referência de modelo:
+O id do provedor se torna o lado esquerdo da sua ref de modelo:

 ```
 <provider>/<model>
@ -150,42 +150,48 @@ O id de provedor se torna o lado esquerdo da sua referência de modelo:
 1. **Seleciona um backend** com base no prefixo do provedor (`codex-cli/...`).
 2. **Cria um prompt de sistema** usando o mesmo prompt do OpenClaw + contexto do workspace.
 3. **Executa a CLI** com um id de sessão (se compatível) para que o histórico permaneça consistente.
-   O backend `claude-cli` incluído mantém um processo stdio do Claude ativo por
+   O backend `claude-cli` integrado mantém um processo Claude stdio ativo por
   sessão do OpenClaw e envia turnos de acompanhamento por stdin stream-json.
 4. **Analisa a saída** (JSON ou texto simples) e retorna o texto final.
 5. **Persiste ids de sessão** por backend, para que acompanhamentos reutilizem a mesma sessão de CLI.

 <Note>
-O backend Anthropic `claude-cli` incluído voltou a ter suporte. A equipe da Anthropic
-nos informou que o uso do Claude CLI no estilo OpenClaw voltou a ser permitido, então o OpenClaw trata
-o uso de `claude -p` como sancionado para esta integração, a menos que a Anthropic publique
+O backend Anthropic `claude-cli` integrado voltou a ser compatível. Funcionários da Anthropic
+nos disseram que o uso do Claude CLI no estilo OpenClaw voltou a ser permitido, então o OpenClaw trata o
+uso de `claude -p` como sancionado para esta integração, a menos que a Anthropic publique
 uma nova política.
 </Note>

-O backend OpenAI `codex-cli` incluído passa o prompt de sistema do OpenClaw por meio da
+O backend OpenAI `codex-cli` integrado passa o prompt de sistema do OpenClaw por meio da
 substituição de configuração `model_instructions_file` do Codex (`-c
 model_instructions_file="..."`). O Codex não expõe uma flag no estilo Claude
 `--append-system-prompt`, então o OpenClaw grava o prompt montado em um
 arquivo temporário para cada nova sessão do Codex CLI.

-O backend Anthropic `claude-cli` incluído recebe o snapshot de Skills do OpenClaw
-de duas formas: o catálogo compacto de Skills do OpenClaw no prompt de sistema anexado e
+O backend Anthropic `claude-cli` integrado recebe o snapshot de skills do OpenClaw
+de duas formas: o catálogo compacto de skills do OpenClaw no prompt de sistema anexado e
 um Plugin temporário do Claude Code passado com `--plugin-dir`. O Plugin contém
-apenas as Skills elegíveis para aquele agente/sessão, então o resolvedor nativo de Skills
-do Claude Code vê o mesmo conjunto filtrado que o OpenClaw anunciaria de outra forma no
-prompt. Substituições de env/chave de API de Skills ainda são aplicadas pelo OpenClaw ao
+apenas as skills elegíveis para esse agente/sessão, então o resolvedor nativo de skill
+do Claude Code vê o mesmo conjunto filtrado que o OpenClaw anunciaria de outro modo no
+prompt. Substituições de env/chave de API de skill ainda são aplicadas pelo OpenClaw ao
 ambiente do processo filho para a execução.

 O Claude CLI também tem seu próprio modo de permissão não interativo. O OpenClaw mapeia isso
-para a política de exec existente, em vez de adicionar uma configuração específica do Claude: quando a
-política de exec efetiva solicitada é YOLO (`tools.exec.security: "full"` e
+para a política exec existente em vez de adicionar configuração específica do Claude: quando a
+política exec efetiva solicitada é YOLO (`tools.exec.security: "full"` e
 `tools.exec.ask: "off"`), o OpenClaw adiciona `--permission-mode bypassPermissions`.
-Configurações por agente em `agents.list[].tools.exec` substituem `tools.exec` global para
-esse agente. Para forçar um modo Claude diferente, defina argumentos brutos explícitos de backend
+Configurações por agente `agents.list[].tools.exec` substituem `tools.exec` global para
+esse agente. Para forçar um modo diferente do Claude, defina argumentos brutos explícitos de backend
 como `--permission-mode default` ou `--permission-mode acceptEdits` em
 `agents.defaults.cliBackends.claude-cli.args` e `resumeArgs` correspondentes.

-Antes que o OpenClaw possa usar o backend `claude-cli` incluído, o próprio Claude Code
+O backend Anthropic `claude-cli` integrado também mapeia níveis de `/think` do OpenClaw
+para a flag nativa `--effort` do Claude Code para níveis diferentes de off. `minimal` e
+`low` mapeiam para `low`, `adaptive` e `medium` mapeiam para `medium`, e `high`,
+`xhigh` e `max` mapeiam diretamente. Outros backends de CLI precisam que seu Plugin proprietário
+declare um mapeador argv equivalente antes que `/think` possa afetar a CLI gerada.
+
+Antes que o OpenClaw possa usar o backend `claude-cli` integrado, o próprio Claude Code
 já deve estar logado no mesmo host:

 ```bash
@ -194,72 +200,71 @@ claude auth status --text
 openclaw models auth login --provider anthropic --method cli --set-default
 ```

-Use `agents.defaults.cliBackends.claude-cli.command` apenas quando o binário `claude`
+Use `agents.defaults.cliBackends.claude-cli.command` somente quando o binário `claude`
 ainda não estiver no `PATH`.

 ## Sessões

- Se a CLI oferece suporte a sessões, defina `sessionArg` (por exemplo, `--session-id`) ou
+- Se a CLI oferecer suporte a sessões, defina `sessionArg` (por exemplo, `--session-id`) ou
  `sessionArgs` (placeholder `{sessionId}`) quando o ID precisar ser inserido
  em várias flags.
- Se a CLI usa um **subcomando de retomada** com flags diferentes, defina
+- Se a CLI usar um **subcomando de retomada** com flags diferentes, defina
  `resumeArgs` (substitui `args` ao retomar) e, opcionalmente, `resumeOutput`
-  (para retomadas que não sejam JSON).
+  (para retomadas não JSON).
 - `sessionMode`:
-  - `always`: sempre envia um id de sessão (novo UUID se nenhum estiver armazenado).
-  - `existing`: envia um id de sessão apenas se um tiver sido armazenado antes.
-  - `none`: nunca envia um id de sessão.
- `claude-cli` usa como padrão `liveSession: "claude-stdio"`, `output: "jsonl"`,
-  e `input: "stdin"` para que turnos de acompanhamento reutilizem o processo Claude ativo enquanto
-  ele estiver ativo. Stdio aquecido agora é o padrão, inclusive para configurações personalizadas
+  - `always`: sempre enviar um id de sessão (novo UUID se nenhum estiver armazenado).
+  - `existing`: enviar um id de sessão somente se um tiver sido armazenado antes.
+  - `none`: nunca enviar um id de sessão.
+- `claude-cli` usa por padrão `liveSession: "claude-stdio"`, `output: "jsonl"`,
+  e `input: "stdin"` para que turnos de acompanhamento reutilizem o processo Claude ativo
+  enquanto ele estiver ativo. Stdio aquecido agora é o padrão, inclusive para configurações personalizadas
  que omitem campos de transporte. Se o Gateway reiniciar ou o processo ocioso
-  sair, o OpenClaw retoma a partir do id de sessão Claude armazenado. Os ids de sessão
+  encerrar, o OpenClaw retoma a partir do id de sessão Claude armazenado. Ids de sessão
  armazenados são verificados contra uma transcrição de projeto existente e legível antes de
-  retomar, então vinculações fantasmas são limpas com `reason=transcript-missing`
+  retomar, então vinculações fantasmas são removidas com `reason=transcript-missing`
  em vez de iniciar silenciosamente uma nova sessão do Claude CLI sob `--resume`.
- Sessões Claude ativas mantêm guardas limitados de saída JSONL. Os padrões permitem até
-  8 MiB e 20.000 linhas JSONL brutas por turno. Turnos Claude com muitas ferramentas podem aumentá-los
+- Sessões Claude ativas mantêm proteções limitadas de saída JSONL. Os padrões permitem até
+  8 MiB e 20.000 linhas JSONL brutas por turno. Turnos Claude com muitas ferramentas podem aumentá-las
  por backend com
  `agents.defaults.cliBackends.claude-cli.reliability.outputLimits.maxTurnRawChars`
  e `maxTurnLines`; o OpenClaw limita essas configurações a 64 MiB e 100.000
  linhas.
 - Sessões de CLI armazenadas são continuidade pertencente ao provedor. O reset diário implícito de sessão
-  não as corta; `/reset` e políticas explícitas de `session.reset` ainda
+  não as corta; `/reset` e políticas explícitas `session.reset` ainda
  cortam.

 Observações de serialização:

- `serialize: true` mantém execuções da mesma faixa ordenadas.
+- `serialize: true` mantém execuções na mesma faixa ordenadas.
 - A maioria das CLIs serializa em uma faixa de provedor.
 - O OpenClaw descarta a reutilização de sessão de CLI armazenada quando a identidade de autenticação selecionada muda,
-  incluindo uma mudança no id do perfil de autenticação, chave de API estática, token estático ou identidade de
-  conta OAuth quando a CLI expõe uma. A rotação de token de acesso e atualização OAuth
-  não corta a sessão de CLI armazenada. Se uma CLI não expõe um
-  id de conta OAuth estável, o OpenClaw deixa essa CLI aplicar as permissões de retomada.
+  incluindo uma alteração de id de perfil de autenticação, chave de API estática, token estático ou identidade de conta OAuth
+  quando a CLI expõe uma. A rotação de tokens OAuth de acesso e refresh não corta a sessão de CLI armazenada. Se uma CLI não expõe um
+  id estável de conta OAuth, o OpenClaw deixa essa CLI impor permissões de retomada.

 ## Prelúdio de fallback de sessões claude-cli

-Quando uma tentativa `claude-cli` faz failover para um candidato que não é CLI em
-[`agents.defaults.model.fallbacks`](/pt-BR/concepts/model-failover), o OpenClaw alimenta
+Quando uma tentativa `claude-cli` faz failover para um candidato não CLI em
+[`agents.defaults.model.fallbacks`](/pt-BR/concepts/model-failover), o OpenClaw semeia
 a próxima tentativa com um prelúdio de contexto coletado da transcrição JSONL local
 do Claude Code em `~/.claude/projects/`. Sem essa semente, o provedor de fallback
-começaria frio porque a transcrição de sessão do próprio OpenClaw está vazia
+começaria frio porque a própria transcrição de sessão do OpenClaw fica vazia
 para execuções `claude-cli`.

- O prelúdio prefere o resumo `/compact` mais recente ou o marcador `compact_boundary`,
+- O prelúdio prefere o resumo `/compact` mais recente ou marcador `compact_boundary`,
  depois anexa os turnos pós-limite mais recentes até um orçamento de caracteres.
  Turnos pré-limite são descartados porque o resumo já os representa.
 - Blocos de ferramentas são agrupados em dicas compactas `(tool call: name)` e
  `(tool result: …)` para manter o orçamento de prompt honesto. O resumo é
-  rotulado como `(truncated)` se estourar.
- Fallbacks do mesmo provedor de `claude-cli` para `claude-cli` dependem do próprio
-  `--resume` do Claude e pulam o prelúdio.
- A semente reutiliza a validação existente do caminho do arquivo de sessão do Claude, então
+  rotulado como `(truncated)` se estourar o limite.
+- Fallbacks de mesmo provedor de `claude-cli` para `claude-cli` dependem do próprio
+  `--resume` do Claude e ignoram o prelúdio.
+- A semente reutiliza a validação de caminho de arquivo de sessão Claude existente, então
  caminhos arbitrários não podem ser lidos.

 ## Imagens (repasse)

-Se sua CLI aceita caminhos de imagem, defina `imageArg`:
+Se sua CLI aceitar caminhos de imagem, defina `imageArg`:

 ```json5
 imageArg: "--image",
@ -267,14 +272,14 @@ imageMode: "repeat"
 ```

 O OpenClaw gravará imagens base64 em arquivos temporários. Se `imageArg` estiver definido, esses
-caminhos são passados como argumentos da CLI. Se `imageArg` estiver ausente, o OpenClaw anexa os
+caminhos serão passados como argumentos de CLI. Se `imageArg` estiver ausente, o OpenClaw anexa os
 caminhos de arquivo ao prompt (injeção de caminho), o que é suficiente para CLIs que carregam automaticamente
 arquivos locais a partir de caminhos simples.

 ## Entradas / saídas

 - `output: "json"` (padrão) tenta analisar JSON e extrair texto + id de sessão.
- Para saída JSON do Gemini CLI, o OpenClaw lê o texto da resposta de `response` e
+- Para saída JSON do Gemini CLI, o OpenClaw lê o texto de resposta de `response` e
  o uso de `stats` quando `usage` está ausente ou vazio.
 - `output: "jsonl"` analisa streams JSONL (por exemplo, Codex CLI `--json`) e extrai a mensagem final do agente, além de identificadores de sessão
  quando presentes.
@ -288,7 +293,7 @@ Modos de entrada:

 ## Padrões (pertencentes ao Plugin)

-O Plugin OpenAI incluído também registra um padrão para `codex-cli`:
+O Plugin OpenAI integrado também registra um padrão para `codex-cli`:

 - `command: "codex"`
 - `args: ["exec","--json","--color","never","--sandbox","workspace-write","--skip-git-repo-check"]`
@ -299,7 +304,7 @@ O Plugin OpenAI incluído também registra um padrão para `codex-cli`:
 - `imageArg: "--image"`
 - `sessionMode: "existing"`

-O Plugin Google incluído também registra um padrão para `google-gemini-cli`:
+O Plugin Google integrado também registra um padrão para `google-gemini-cli`:

 - `command: "gemini"`
 - `args: ["--output-format", "json", "--prompt", "{prompt}"]`
@ -310,32 +315,32 @@ O Plugin Google incluído também registra um padrão para `google-gemini-cli`:
 - `sessionMode: "existing"`
 - `sessionIdFields: ["session_id", "sessionId"]`

-Pré-requisito: a CLI Gemini local deve estar instalada e disponível como
+Pré-requisito: a CLI local do Gemini deve estar instalada e disponível como
 `gemini` no `PATH` (`brew install gemini-cli` ou
 `npm install -g @google/gemini-cli`).

-Observações sobre JSON do Gemini CLI:
+Observações de JSON do Gemini CLI:

 - O texto da resposta é lido do campo JSON `response`.
 - O uso recorre a `stats` quando `usage` está ausente ou vazio.
 - `stats.cached` é normalizado para `cacheRead` do OpenClaw.
- Se `stats.input` estiver ausente, o OpenClaw deriva tokens de entrada de
+- Se `stats.input` estiver ausente, o OpenClaw deriva os tokens de entrada de
  `stats.input_tokens - stats.cached`.

-Substitua apenas se necessário (comum: caminho absoluto de `command`).
+Substitua somente se necessário (comum: caminho absoluto de `command`).

-## Padrões pertencentes ao Plugin
+## Padrões de propriedade do Plugin

-Os padrões de backend de CLI agora fazem parte da superfície do Plugin:
+Os padrões de backend da CLI agora fazem parte da superfície do plugin:

 - Plugins os registram com `api.registerCliBackend(...)`.
- O `id` do backend se torna o prefixo do provedor nas refs de modelo.
+- O `id` do backend se torna o prefixo do provedor nas referências de modelo.
 - A configuração do usuário em `agents.defaults.cliBackends.<id>` ainda substitui o padrão do plugin.
- A limpeza de configuração específica do backend continua pertencendo ao plugin por meio do hook opcional
+- A limpeza de configuração específica do backend continua sendo de propriedade do plugin por meio do hook opcional
  `normalizeConfig`.

 Plugins que precisam de pequenos shims de compatibilidade de prompt/mensagem podem declarar
-transformações de texto bidirecionais sem substituir um provedor ou backend da CLI:
+transformações de texto bidirecionais sem substituir um provedor ou backend de CLI:

 ```typescript
 api.registerTextTransforms({
@ -353,7 +358,7 @@ api.registerTextTransforms({
 ```

 `input` reescreve o prompt do sistema e o prompt do usuário passados para a CLI. `output`
-reescreve deltas transmitidos do assistente e o texto final analisado antes que o OpenClaw processe
+reescreve deltas transmitidos do assistente e o texto final analisado antes que o OpenClaw manipule
 seus próprios marcadores de controle e a entrega ao canal.

 Para CLIs que emitem JSONL compatível com Claude Code stream-json, defina
@ -361,45 +366,45 @@ Para CLIs que emitem JSONL compatível com Claude Code stream-json, defina

 ## Sobreposições de MCP do pacote

-Backends da CLI **não** recebem chamadas de ferramenta do OpenClaw diretamente, mas um backend pode
-optar por uma sobreposição de configuração MCP gerada com `bundleMcp: true`.
+Backends de CLI **não** recebem chamadas de ferramentas do OpenClaw diretamente, mas um backend pode
+aderir a uma sobreposição de configuração MCP gerada com `bundleMcp: true`.

 Comportamento empacotado atual:

 - `claude-cli`: arquivo de configuração MCP estrito gerado
 - `codex-cli`: substituições de configuração inline para `mcp_servers`; o servidor
-  local loopback do OpenClaw gerado é marcado com o modo de aprovação de ferramentas por servidor do Codex
+  local loopback do OpenClaw gerado é marcado com o modo de aprovação de ferramenta por servidor do Codex
  para que chamadas MCP não possam travar em prompts de aprovação local
 - `google-gemini-cli`: arquivo de configurações do sistema Gemini gerado

-Quando MCP do pacote está habilitado, o OpenClaw:
+Quando o bundle MCP está habilitado, o OpenClaw:

- inicia um servidor HTTP MCP local loopback que expõe ferramentas do gateway ao processo da CLI
+- inicia um servidor HTTP MCP de local loopback que expõe ferramentas do gateway ao processo da CLI
 - autentica a ponte com um token por sessão (`OPENCLAW_MCP_TOKEN`)
- limita o acesso a ferramentas ao contexto da sessão, conta e canal atuais
+- limita o acesso às ferramentas ao contexto da sessão, conta e canal atuais
 - carrega servidores bundle-MCP habilitados para o workspace atual
- os mescla com qualquer formato existente de configuração/configurações MCP do backend
- reescreve a configuração de inicialização usando o modo de integração pertencente ao backend vindo da extensão proprietária
+- os mescla com qualquer forma existente de configuração/definições MCP do backend
+- reescreve a configuração de inicialização usando o modo de integração de propriedade do backend da extensão proprietária

 Se nenhum servidor MCP estiver habilitado, o OpenClaw ainda injeta uma configuração estrita quando um
-backend opta por MCP do pacote, para que execuções em segundo plano permaneçam isoladas.
+backend adere ao bundle MCP para que execuções em segundo plano permaneçam isoladas.

-Runtimes MCP empacotados com escopo de sessão são armazenados em cache para reutilização dentro de uma sessão e, depois,
-removidos após `mcp.sessionIdleTtlMs` milissegundos de inatividade (padrão de 10
+Runtimes MCP empacotados com escopo de sessão são armazenados em cache para reutilização dentro de uma sessão e,
+em seguida, removidos após `mcp.sessionIdleTtlMs` milissegundos de tempo ocioso (padrão de 10
 minutos; defina `0` para desabilitar). Execuções incorporadas de uso único, como sondagens de autenticação,
-geração de slug e chamadas de Active Memory, solicitam limpeza ao final da execução para que
-processos filhos stdio e streams HTTP/SSE Streamable não sobrevivam à execução.
+geração de slug e limpeza de solicitações de recall de active-memory no fim da execução para que filhos stdio
+e streams Streamable HTTP/SSE não sobrevivam à execução.

 ## Limitações

- **Sem chamadas diretas de ferramentas do OpenClaw.** O OpenClaw não injeta chamadas de ferramenta no
-  protocolo de backend da CLI. Backends só veem ferramentas do gateway quando optam por
+- **Sem chamadas diretas de ferramentas do OpenClaw.** O OpenClaw não injeta chamadas de ferramentas no
+  protocolo do backend da CLI. Backends só veem ferramentas do gateway quando aderem a
  `bundleMcp: true`.
- **Streaming é específico do backend.** Alguns backends transmitem JSONL; outros armazenam em buffer
+- **Streaming é específico do backend.** Alguns backends transmitem JSONL; outros fazem buffer
  até a saída.
 - **Saídas estruturadas** dependem do formato JSON da CLI.
- **Sessões da CLI Codex** retomam por saída de texto (sem JSONL), que é menos
-  estruturada do que a execução inicial com `--json`. Sessões do OpenClaw ainda funcionam
+- **Sessões da CLI Codex** são retomadas via saída de texto (sem JSONL), que é menos
+  estruturada do que a execução inicial com `--json`. As sessões do OpenClaw ainda funcionam
  normalmente.

 ## Solução de problemas
@ -407,10 +412,10 @@ processos filhos stdio e streams HTTP/SSE Streamable não sobrevivam à execuç
 - **CLI não encontrada**: defina `command` como um caminho completo.
 - **Nome de modelo incorreto**: use `modelAliases` para mapear `provider/model` → modelo da CLI.
 - **Sem continuidade de sessão**: garanta que `sessionArg` esteja definido e que `sessionMode` não seja
-  `none` (atualmente a CLI Codex não consegue retomar com saída JSON).
- **Imagens ignoradas**: defina `imageArg` (e verifique se a CLI aceita caminhos de arquivos).
+  `none` (a CLI Codex atualmente não consegue retomar com saída JSON).
+- **Imagens ignoradas**: defina `imageArg` (e verifique se a CLI oferece suporte a caminhos de arquivos).

-## Relacionados
+## Relacionado

 - [Runbook do Gateway](/pt-BR/gateway)
 - [Modelos locais](/pt-BR/gateway/local-models)
--- a/docs/pt-BR/help/testing-live.md
+++ b/docs/pt-BR/help/testing-live.md
@ -1,29 +1,28 @@
 ---
 read_when:
-    - Executando testes de fumaça de matriz de modelos ao vivo / backend da CLI / ACP / media-provider
+    - Executando testes smoke da matriz de modelos ao vivo / back-end da CLI / ACP / provedor de mídia
    - Depuração da resolução de credenciais de testes ao vivo
-    - Adicionando um novo teste ao vivo específico do provedor
+    - Adicionando um novo teste ao vivo específico de provedor
 sidebarTitle: Live tests
-summary: 'Testes em ambiente real (com acesso à rede): matriz de modelos, backends da CLI, ACP, provedores de mídia, credenciais'
+summary: 'Testes em ambiente real (que acessam a rede): matriz de modelos, backends da CLI, ACP, provedores de mídia, credenciais'
 title: 'Testes: suítes ao vivo'
 x-i18n:
-    generated_at: "2026-05-03T05:50:02Z"
+    generated_at: "2026-05-04T18:23:51Z"
    model: gpt-5.5
    provider: openai
-    source_hash: 4057d8875fa3404108e89e4381c1dd14e96abbc2af13c4934fc6c0dbf878fc00
+    source_hash: 03b8ca6348137a55c8d5f67c9c166a130a75a744f6a433cb00496756b29d7016
    source_path: help/testing-live.md
    workflow: 16
 ---

-Para início rápido, executores de QA, suítes unitárias/de integração e fluxos Docker, consulte
+Para início rápido, executores de QA, suítes unitárias/de integração e fluxos Docker, veja
 [Testes](/pt-BR/help/testing). Esta página cobre as suítes de teste **live** (com acesso à rede):
-matriz de modelos, backends de CLI, ACP e testes live de provedores de mídia, além do
-manuseio de credenciais.
+matriz de modelos, backends CLI, ACP e testes live de provedores de mídia, além do
+tratamento de credenciais.

 ## Live: comandos de smoke do perfil local

-Carregue `~/.profile` antes de verificações live ad hoc para que as chaves de provedores e os
-caminhos de ferramentas locais correspondam ao seu shell:
+Faça `source` de `~/.profile` antes de verificações live ad hoc para que as chaves de provedores e os caminhos de ferramentas locais correspondam ao seu shell:

 ```bash
 source ~/.profile
@ -44,34 +43,34 @@ pnpm openclaw voicecall setup --json
 pnpm openclaw voicecall smoke --to "+15555550123"
 ```

-`voicecall smoke` é uma execução simulada, a menos que `--yes` também esteja presente. Use `--yes` somente
+`voicecall smoke` é uma simulação, a menos que `--yes` também esteja presente. Use `--yes` somente
 quando você quiser intencionalmente fazer uma chamada real de notificação. Para Twilio, Telnyx e
-Plivo, uma verificação de prontidão bem-sucedida exige uma URL pública de webhook; fallbacks
-somente locais de loopback/privados são rejeitados por design.
+Plivo, uma verificação de prontidão bem-sucedida exige uma URL pública de webhook; fallbacks apenas locais
+de loopback/privados são rejeitados por design.

-## Live: varredura de capacidades de nó Android
+## Live: varredura de capacidades de node Android

 - Teste: `src/gateway/android-node.capabilities.live.test.ts`
 - Script: `pnpm android:test:integration`
- Objetivo: invocar **todos os comandos anunciados atualmente** por um nó Android conectado e validar o comportamento do contrato de comandos.
+- Objetivo: invocar **todos os comandos anunciados atualmente** por um node Android conectado e validar o comportamento de contrato dos comandos.
 - Escopo:
  - Configuração pré-condicionada/manual (a suíte não instala/executa/pareia o app).
-  - Validação comando a comando do `node.invoke` do gateway para o nó Android selecionado.
+  - Validação `node.invoke` do gateway comando por comando para o node Android selecionado.
 - Pré-configuração obrigatória:
-  - App Android já conectado + pareado ao gateway.
+  - App Android já conectado e pareado ao gateway.
  - App mantido em primeiro plano.
-  - Permissões/consentimento de captura concedidos para as capacidades que você espera aprovar.
- Sobrescritas opcionais de destino:
+  - Permissões/consentimento de captura concedidos para as capacidades que você espera que passem.
+- Substituições opcionais de destino:
  - `OPENCLAW_ANDROID_NODE_ID` ou `OPENCLAW_ANDROID_NODE_NAME`.
  - `OPENCLAW_ANDROID_GATEWAY_URL` / `OPENCLAW_ANDROID_GATEWAY_TOKEN` / `OPENCLAW_ANDROID_GATEWAY_PASSWORD`.
- Detalhes completos da configuração do Android: [App Android](/pt-BR/platforms/android)
+- Detalhes completos de configuração do Android: [App Android](/pt-BR/platforms/android)

-## Live: smoke de modelos (chaves de perfil)
+## Live: smoke de modelo (chaves de perfil)

-Os testes live são divididos em duas camadas para podermos isolar falhas:
+Os testes live são divididos em duas camadas para que possamos isolar falhas:

- “Modelo direto” mostra se o provedor/modelo consegue responder com a chave fornecida.
- “Smoke do Gateway” mostra se o pipeline completo de gateway+agente funciona para esse modelo (sessões, histórico, ferramentas, política de sandbox etc.).
+- “Modelo direto” informa se o provedor/modelo consegue responder com a chave fornecida.
+- “Smoke do Gateway” informa se o pipeline completo gateway+agent funciona para esse modelo (sessões, histórico, ferramentas, política de sandbox etc.).

 ### Camada 1: conclusão direta de modelo (sem gateway)

@ -81,61 +80,61 @@ Os testes live são divididos em duas camadas para podermos isolar falhas:
  - Usar `getApiKeyForModel` para selecionar modelos para os quais você tem credenciais
  - Executar uma pequena conclusão por modelo (e regressões direcionadas quando necessário)
 - Como habilitar:
-  - `pnpm test:live` (ou `OPENCLAW_LIVE_TEST=1` se invocar o Vitest diretamente)
- Defina `OPENCLAW_LIVE_MODELS=modern` (ou `all`, alias de modern) para executar esta suíte de fato; caso contrário, ela é ignorada para manter `pnpm test:live` focado no smoke do gateway
+  - `pnpm test:live` (ou `OPENCLAW_LIVE_TEST=1` ao invocar o Vitest diretamente)
+- Defina `OPENCLAW_LIVE_MODELS=modern` (ou `all`, alias de modern) para realmente executar esta suíte; caso contrário, ela é ignorada para manter `pnpm test:live` focado no smoke do gateway
 - Como selecionar modelos:
-  - `OPENCLAW_LIVE_MODELS=modern` para executar a allowlist moderna (Opus/Sonnet 4.6+, GPT-5.2 + Codex, Gemini 3, DeepSeek V4, GLM 4.7, MiniMax M2.7, Grok 4.3)
-  - `OPENCLAW_LIVE_MODELS=all` é um alias para a allowlist moderna
-  - ou `OPENCLAW_LIVE_MODELS="openai/gpt-5.5,openai-codex/gpt-5.5,anthropic/claude-opus-4-6,..."` (allowlist separada por vírgulas)
+  - `OPENCLAW_LIVE_MODELS=modern` para executar a lista permitida moderna (Opus/Sonnet 4.6+, GPT-5.2 + Codex, Gemini 3, DeepSeek V4, GLM 4.7, MiniMax M2.7, Grok 4.3)
+  - `OPENCLAW_LIVE_MODELS=all` é um alias da lista permitida moderna
+  - ou `OPENCLAW_LIVE_MODELS="openai/gpt-5.5,openai-codex/gpt-5.5,anthropic/claude-opus-4-6,..."` (lista permitida separada por vírgulas)
  - Varreduras modern/all usam por padrão um limite curado de alto sinal; defina `OPENCLAW_LIVE_MAX_MODELS=0` para uma varredura moderna exaustiva ou um número positivo para um limite menor.
-  - Varreduras exaustivas usam `OPENCLAW_LIVE_TEST_TIMEOUT_MS` como timeout para todo o teste direto de modelo. Padrão: 60 minutos.
-  - As sondagens diretas de modelos são executadas com paralelismo de 20 por padrão; defina `OPENCLAW_LIVE_MODEL_CONCURRENCY` para sobrescrever.
+  - Varreduras exaustivas usam `OPENCLAW_LIVE_TEST_TIMEOUT_MS` para o timeout de todo o teste de modelo direto. Padrão: 60 minutos.
+  - Sondagens de modelo direto rodam com paralelismo de 20 vias por padrão; defina `OPENCLAW_LIVE_MODEL_CONCURRENCY` para substituir.
 - Como selecionar provedores:
-  - `OPENCLAW_LIVE_PROVIDERS="google,google-antigravity,google-gemini-cli"` (allowlist separada por vírgulas)
+  - `OPENCLAW_LIVE_PROVIDERS="google,google-antigravity,google-gemini-cli"` (lista permitida separada por vírgulas)
 - De onde vêm as chaves:
-  - Por padrão: armazenamento de perfis e fallbacks de env
-  - Defina `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` para exigir somente o **armazenamento de perfis**
+  - Por padrão: armazenamento de perfil e fallbacks de env
+  - Defina `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` para impor somente o **armazenamento de perfil**
 - Por que isso existe:
-  - Separa “a API do provedor está quebrada / a chave é inválida” de “o pipeline do agente do gateway está quebrado”
-  - Contém regressões pequenas e isoladas (exemplo: replay de raciocínio de OpenAI Responses/Codex Responses + fluxos de chamadas de ferramenta)
+  - Separa “a API do provedor está quebrada / a chave é inválida” de “o pipeline do agente de gateway está quebrado”
+  - Contém regressões pequenas e isoladas (exemplo: replay de raciocínio de OpenAI Responses/Codex Responses + fluxos de chamada de ferramenta)

-### Camada 2: smoke de Gateway + agente de desenvolvimento (o que "@openclaw" realmente faz)
+### Camada 2: smoke de Gateway + agente dev (o que "@openclaw" realmente faz)

 - Teste: `src/gateway/gateway-models.profiles.live.test.ts`
 - Objetivo:
  - Iniciar um gateway em processo
-  - Criar/aplicar patch a uma sessão `agent:dev:*` (sobrescrita de modelo por execução)
-  - Iterar modelos com chaves e validar:
+  - Criar/aplicar patch em uma sessão `agent:dev:*` (substituição de modelo por execução)
+  - Iterar pelos modelos com chaves e validar:
    - resposta “significativa” (sem ferramentas)
    - uma invocação real de ferramenta funciona (sondagem de leitura)
-    - sondagens opcionais extras de ferramentas (sondagem de exec+read)
-    - caminhos de regressão da OpenAI (somente chamada de ferramenta → acompanhamento) continuam funcionando
- Detalhes da sondagem (para você explicar falhas rapidamente):
-  - Sondagem `read`: o teste grava um arquivo nonce no workspace e pede ao agente para fazer `read` dele e ecoar o nonce de volta.
-  - Sondagem `exec+read`: o teste pede ao agente para gravar via `exec` um nonce em um arquivo temporário e depois fazer `read` dele.
-  - Sondagem de imagem: o teste anexa um PNG gerado (cat + código aleatório) e espera que o modelo retorne `cat <CODE>`.
+    - sondagens opcionais extras de ferramenta (sondagem exec+read)
+    - caminhos de regressão OpenAI (somente chamada de ferramenta → acompanhamento) continuam funcionando
+- Detalhes das sondagens (para você explicar falhas rapidamente):
+  - Sondagem `read`: o teste grava um arquivo nonce no workspace e pede ao agente para `read`-lo e ecoar o nonce de volta.
+  - Sondagem `exec+read`: o teste pede ao agente para gravar um nonce com `exec` em um arquivo temporário e depois `read`-lo de volta.
+  - Sondagem de imagem: o teste anexa um PNG gerado (cat + código randomizado) e espera que o modelo retorne `cat <CODE>`.
  - Referência de implementação: `src/gateway/gateway-models.profiles.live.test.ts` e `src/gateway/live-image-probe.ts`.
 - Como habilitar:
-  - `pnpm test:live` (ou `OPENCLAW_LIVE_TEST=1` se invocar o Vitest diretamente)
+  - `pnpm test:live` (ou `OPENCLAW_LIVE_TEST=1` ao invocar o Vitest diretamente)
 - Como selecionar modelos:
-  - Padrão: allowlist moderna (Opus/Sonnet 4.6+, GPT-5.2 + Codex, Gemini 3, DeepSeek V4, GLM 4.7, MiniMax M2.7, Grok 4.3)
-  - `OPENCLAW_LIVE_GATEWAY_MODELS=all` é um alias para a allowlist moderna
+  - Padrão: lista permitida moderna (Opus/Sonnet 4.6+, GPT-5.2 + Codex, Gemini 3, DeepSeek V4, GLM 4.7, MiniMax M2.7, Grok 4.3)
+  - `OPENCLAW_LIVE_GATEWAY_MODELS=all` é um alias da lista permitida moderna
  - Ou defina `OPENCLAW_LIVE_GATEWAY_MODELS="provider/model"` (ou lista separada por vírgulas) para restringir
  - Varreduras de gateway modern/all usam por padrão um limite curado de alto sinal; defina `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0` para uma varredura moderna exaustiva ou um número positivo para um limite menor.
- Como selecionar provedores (evite “todo o OpenRouter”):
-  - `OPENCLAW_LIVE_GATEWAY_PROVIDERS="google,google-antigravity,google-gemini-cli,openai,anthropic,zai,minimax"` (allowlist separada por vírgulas)
- Sondagens de ferramentas + imagem estão sempre ativadas neste teste live:
-  - Sondagem `read` + sondagem `exec+read` (stress de ferramenta)
-  - A sondagem de imagem é executada quando o modelo anuncia suporte a entrada de imagem
+- Como selecionar provedores (evite “tudo via OpenRouter”):
+  - `OPENCLAW_LIVE_GATEWAY_PROVIDERS="google,google-antigravity,google-gemini-cli,openai,anthropic,zai,minimax"` (lista permitida separada por vírgulas)
+- Sondagens de ferramenta + imagem estão sempre ativadas neste teste live:
+  - Sondagem `read` + sondagem `exec+read` (estresse de ferramentas)
+  - Sondagem de imagem roda quando o modelo anuncia suporte a entrada de imagem
  - Fluxo (alto nível):
-    - O teste gera um PNG pequeno com “CAT” + código aleatório (`src/gateway/live-image-probe.ts`)
+    - O teste gera um PNG minúsculo com “CAT” + código aleatório (`src/gateway/live-image-probe.ts`)
    - Envia via `agent` `attachments: [{ mimeType: "image/png", content: "<base64>" }]`
-    - O Gateway analisa anexos em `images[]` (`src/gateway/server-methods/agent.ts` + `src/gateway/chat-attachments.ts`)
-    - O agente incorporado encaminha uma mensagem multimodal do usuário para o modelo
-    - Validação: a resposta contém `cat` + o código (tolerância de OCR: pequenos erros permitidos)
+    - Gateway analisa anexos em `images[]` (`src/gateway/server-methods/agent.ts` + `src/gateway/chat-attachments.ts`)
+    - Agente incorporado encaminha uma mensagem de usuário multimodal ao modelo
+    - Validação: resposta contém `cat` + o código (tolerância de OCR: pequenos erros permitidos)

 <Tip>
-Para ver o que você pode testar na sua máquina (e os ids exatos de `provider/model`), execute:
+Para ver o que você pode testar na sua máquina (e os ids `provider/model` exatos), execute:

 ```bash
 openclaw models list
@ -144,27 +143,27 @@ openclaw models list --json

 </Tip>

-## Live: smoke de backend de CLI (Claude, Codex, Gemini ou outras CLIs locais)
+## Live: smoke de backend CLI (Claude, Codex, Gemini ou outras CLIs locais)

 - Teste: `src/gateway/gateway-cli-backend.live.test.ts`
- Objetivo: validar o pipeline Gateway + agente usando um backend de CLI local, sem tocar na sua configuração padrão.
- Os padrões de smoke específicos do backend ficam na definição `cli-backend.ts` da extensão responsável.
+- Objetivo: validar o pipeline Gateway + agente usando um backend CLI local, sem tocar na sua configuração padrão.
+- Os padrões de smoke específicos de backend ficam na definição `cli-backend.ts` da extensão proprietária.
 - Habilitar:
-  - `pnpm test:live` (ou `OPENCLAW_LIVE_TEST=1` se invocar o Vitest diretamente)
+  - `pnpm test:live` (ou `OPENCLAW_LIVE_TEST=1` ao invocar o Vitest diretamente)
  - `OPENCLAW_LIVE_CLI_BACKEND=1`
 - Padrões:
  - Provedor/modelo padrão: `claude-cli/claude-sonnet-4-6`
-  - Comando/args/comportamento de imagem vêm dos metadados do plugin de backend de CLI responsável.
- Sobrescritas (opcional):
+  - Comando/args/comportamento de imagem vêm dos metadados do Plugin de backend CLI proprietário.
+- Substituições (opcionais):
  - `OPENCLAW_LIVE_CLI_BACKEND_MODEL="codex-cli/gpt-5.5"`
  - `OPENCLAW_LIVE_CLI_BACKEND_COMMAND="/full/path/to/codex"`
  - `OPENCLAW_LIVE_CLI_BACKEND_ARGS='["exec","--json","--color","never","--sandbox","read-only","--skip-git-repo-check"]'`
-  - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_PROBE=1` para enviar um anexo de imagem real (caminhos são injetados no prompt). Receitas Docker deixam isso desativado por padrão, a menos que solicitado explicitamente.
-  - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image"` para passar caminhos de arquivos de imagem como args da CLI em vez de injeção no prompt.
+  - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_PROBE=1` para enviar um anexo de imagem real (caminhos são injetados no prompt). Receitas Docker deixam isso desativado por padrão, a menos que seja solicitado explicitamente.
+  - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image"` para passar caminhos de arquivos de imagem como args de CLI em vez de injeção no prompt.
  - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat"` (ou `"list"`) para controlar como os args de imagem são passados quando `IMAGE_ARG` está definido.
  - `OPENCLAW_LIVE_CLI_BACKEND_RESUME_PROBE=1` para enviar um segundo turno e validar o fluxo de retomada.
  - `OPENCLAW_LIVE_CLI_BACKEND_MODEL_SWITCH_PROBE=1` para optar pela sondagem de continuidade na mesma sessão Claude Sonnet -> Opus quando o modelo selecionado oferece suporte a um destino de troca. Receitas Docker deixam isso desativado por padrão para confiabilidade agregada.
-  - `OPENCLAW_LIVE_CLI_BACKEND_MCP_PROBE=1` para optar pela sondagem de MCP/ferramenta em loopback. Receitas Docker deixam isso desativado por padrão, a menos que solicitado explicitamente.
+  - `OPENCLAW_LIVE_CLI_BACKEND_MCP_PROBE=1` para optar pela sondagem de MCP/ferramenta em local loopback. Receitas Docker deixam isso desativado por padrão, a menos que seja solicitado explicitamente.

 Exemplo:

@ -181,10 +180,10 @@ OPENCLAW_LIVE_TEST=1 \
  pnpm test:live src/agents/cli-runner/bundle-mcp.gemini.live.test.ts
 ```

-Isso não pede ao Gemini para gerar uma resposta. Ele grava as mesmas configurações de sistema
-que o OpenClaw fornece ao Gemini, depois executa `gemini --debug mcp list` para provar que um
-servidor salvo com `transport: "streamable-http"` é normalizado para o formato MCP HTTP do Gemini
-e consegue se conectar a um servidor MCP HTTP streamable local.
+Isso não pede que o Gemini gere uma resposta. Ele grava as mesmas configurações de sistema
+que o OpenClaw fornece ao Gemini e então executa `gemini --debug mcp list` para provar que um
+servidor `transport: "streamable-http"` salvo é normalizado para o formato MCP HTTP do Gemini
+e consegue se conectar a um servidor MCP streamable-HTTP local.

 Receita Docker:

@ -204,21 +203,30 @@ pnpm test:docker:live-cli-backend:gemini
 Observações:

 - O executor Docker fica em `scripts/test-live-cli-backend-docker.sh`.
- Ele executa o smoke live de backend de CLI dentro da imagem Docker do repo como o usuário não root `node`.
- Ele resolve metadados de smoke da CLI a partir da extensão responsável, depois instala o pacote de CLI Linux correspondente (`@anthropic-ai/claude-code`, `@openai/codex` ou `@google/gemini-cli`) em um prefixo gravável em cache em `OPENCLAW_DOCKER_CLI_TOOLS_DIR` (padrão: `~/.cache/openclaw/docker-cli-tools`).
- `pnpm test:docker:live-cli-backend:claude-subscription` exige OAuth portátil de assinatura Claude Code por meio de `~/.claude/.credentials.json` com `claudeAiOauth.subscriptionType` ou `CLAUDE_CODE_OAUTH_TOKEN` de `claude setup-token`. Primeiro ele prova `claude -p` direto no Docker, depois executa dois turnos de backend de CLI do Gateway sem preservar variáveis de ambiente de chave de API da Anthropic. Esta lane de assinatura desativa por padrão as sondagens MCP/ferramenta e imagem do Claude porque atualmente o Claude roteia uso de apps de terceiros por cobrança de uso extra, em vez dos limites normais do plano de assinatura.
- O smoke live de backend de CLI agora exercita o mesmo fluxo ponta a ponta para Claude, Codex e Gemini: turno de texto, turno de classificação de imagem e depois chamada de ferramenta MCP `cron` verificada por meio da CLI do gateway.
- O smoke padrão do Claude também aplica patch à sessão de Sonnet para Opus e verifica que a sessão retomada ainda lembra uma anotação anterior.
+- Ele executa o smoke live de backend CLI dentro da imagem Docker do repositório como o usuário não root `node`.
+- Ele resolve os metadados de smoke CLI a partir da extensão proprietária e então instala o pacote CLI Linux correspondente (`@anthropic-ai/claude-code`, `@openai/codex` ou `@google/gemini-cli`) em um prefixo gravável em cache em `OPENCLAW_DOCKER_CLI_TOOLS_DIR` (padrão: `~/.cache/openclaw/docker-cli-tools`).
+- `pnpm test:docker:live-cli-backend:claude-subscription` exige OAuth portátil de assinatura do Claude Code por meio de `~/.claude/.credentials.json` com `claudeAiOauth.subscriptionType` ou `CLAUDE_CODE_OAUTH_TOKEN` de `claude setup-token`. Primeiro ele comprova `claude -p` direto no Docker e depois executa dois turnos de backend CLI do Gateway sem preservar variáveis de ambiente de chave de API da Anthropic. Esta lane de assinatura desativa por padrão as sondagens MCP/ferramenta e imagem do Claude porque atualmente o Claude roteia o uso de apps de terceiros por cobrança de uso extra, em vez de limites normais do plano de assinatura.
+- O smoke live de backend CLI agora exercita o mesmo fluxo de ponta a ponta para Claude, Codex e Gemini: turno de texto, turno de classificação de imagem e então chamada de ferramenta MCP `cron` verificada pelo gateway CLI.
+- O smoke padrão do Claude também aplica patch na sessão de Sonnet para Opus e verifica que a sessão retomada ainda lembra uma nota anterior.

-## Live: smoke de bind do ACP (`/acp spawn ... --bind here`)
+## Live: alcançabilidade do proxy HTTP/2 APNs
+
+- Teste: `src/infra/push-apns-http2.live.test.ts`
+- Objetivo: tunelar por um proxy HTTP CONNECT local até o endpoint APNs sandbox da Apple, enviar a solicitação de validação HTTP/2 do APNs e validar que a resposta real `403 InvalidProviderToken` da Apple retorna pelo caminho do proxy.
+- Habilitar:
+  - `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_APNS_REACHABILITY=1 pnpm test:live src/infra/push-apns-http2.live.test.ts`
+- Timeout opcional:
+  - `OPENCLAW_LIVE_APNS_TIMEOUT_MS=30000`
+
+## Live: smoke de bind ACP (`/acp spawn ... --bind here`)

 - Teste: `src/gateway/gateway-acp-bind.live.test.ts`
 - Objetivo: validar o fluxo real de vinculação de conversa ACP com um agente ACP ao vivo:
  - enviar `/acp spawn <agent> --bind here`
-  - vincular no local uma conversa sintética de canal de mensagens
+  - vincular no lugar uma conversa sintética de canal de mensagens
  - enviar um acompanhamento normal nessa mesma conversa
  - verificar se o acompanhamento chega à transcrição da sessão ACP vinculada
- Ativar:
+- Habilitar:
  - `pnpm test:live src/gateway/gateway-acp-bind.live.test.ts`
  - `OPENCLAW_LIVE_ACP_BIND=1`
 - Padrões:
@ -239,10 +247,10 @@ Observações:
  - `OPENCLAW_LIVE_ACP_BIND_REQUIRE_TRANSCRIPT=1`
  - `OPENCLAW_LIVE_ACP_BIND_REQUIRE_CRON=1`
  - `OPENCLAW_LIVE_ACP_BIND_PARENT_MODEL=openai/gpt-5.5`
- Notas:
-  - Esta rota usa a superfície `chat.send` do gateway com campos de rota de origem sintéticos somente para administradores, para que os testes possam anexar contexto de canal de mensagens sem fingir entrega externa.
-  - Quando `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND` não está definido, o teste usa o registro de agentes integrado do Plugin `acpx` embutido para o agente de harness ACP selecionado.
-  - A criação de MCP por Cron de sessão vinculada é de melhor esforço por padrão porque harnesses ACP externos podem cancelar chamadas MCP depois que a prova de vinculação/imagem tiver passado; defina `OPENCLAW_LIVE_ACP_BIND_REQUIRE_CRON=1` para tornar essa sondagem de Cron pós-vinculação estrita.
+- Observações:
+  - Esta faixa usa a superfície `chat.send` do Gateway com campos de rota de origem sintética somente para administradores, para que os testes possam anexar contexto de canal de mensagens sem fingir entregar externamente.
+  - Quando `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND` não está definido, o teste usa o registro de agentes integrado do Plugin `acpx` embutido para o agente selecionado do ambiente de teste ACP.
+  - A criação de MCP de Cron da sessão vinculada é de melhor esforço por padrão, porque ambientes de teste ACP externos podem cancelar chamadas MCP depois que a prova de vínculo/imagem passou; defina `OPENCLAW_LIVE_ACP_BIND_REQUIRE_CRON=1` para tornar essa sondagem de Cron pós-vínculo estrita.

 Exemplo:

@ -252,13 +260,13 @@ OPENCLAW_LIVE_ACP_BIND=1 \
  pnpm test:live src/gateway/gateway-acp-bind.live.test.ts
 ```

-Receita Docker:
+Receita do Docker:

 ```bash
 pnpm test:docker:live-acp-bind
 ```

-Receitas Docker de agente único:
+Receitas Docker para agente único:

 ```bash
 pnpm test:docker:live-acp-bind:claude
@ -268,38 +276,38 @@ pnpm test:docker:live-acp-bind:gemini
 pnpm test:docker:live-acp-bind:opencode
 ```

-Notas do Docker:
+Observações do Docker:

 - O executor Docker fica em `scripts/test-live-acp-bind-docker.sh`.
- Por padrão, ele executa o smoke de vinculação ACP contra os agentes CLI ao vivo agregados em sequência: `claude`, `codex` e depois `gemini`.
+- Por padrão, ele executa o teste de fumaça de vínculo ACP contra os agentes CLI ao vivo agregados em sequência: `claude`, `codex` e depois `gemini`.
 - Use `OPENCLAW_LIVE_ACP_BIND_AGENTS=claude`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=codex`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=droid`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=gemini` ou `OPENCLAW_LIVE_ACP_BIND_AGENTS=opencode` para restringir a matriz.
- Ele carrega `~/.profile`, prepara o material de autenticação da CLI correspondente no contêiner e então instala a CLI ao vivo solicitada (`@anthropic-ai/claude-code`, `@openai/codex`, Factory Droid via `https://app.factory.ai/cli`, `@google/gemini-cli` ou `opencode-ai`) se estiver ausente. O próprio backend ACP é o pacote `acpx/runtime` embutido do Plugin oficial `acpx`.
- A variante Docker do Droid prepara `~/.factory` para configurações, encaminha `FACTORY_API_KEY` e exige essa chave de API porque a autenticação local OAuth/keyring da Factory não é portátil para dentro do contêiner. Ela usa a entrada de registro integrada do ACPX `droid exec --output-format acp`.
- A variante Docker do OpenCode é uma rota de regressão estrita de agente único. Ela grava um modelo padrão temporário `OPENCODE_CONFIG_CONTENT` a partir de `OPENCLAW_LIVE_ACP_BIND_OPENCODE_MODEL` (padrão `opencode/kimi-k2.6`) depois de carregar `~/.profile`, e `pnpm test:docker:live-acp-bind:opencode` exige uma transcrição de assistente vinculada em vez de aceitar o salto genérico pós-vinculação.
- Chamadas diretas da CLI `acpx` são apenas um caminho manual/alternativo para comparar comportamento fora do Gateway. O smoke Docker de vinculação ACP exercita o backend de runtime `acpx` embutido do OpenClaw.
+- Ele carrega `~/.profile`, prepara o material de autenticação CLI correspondente no contêiner e então instala a CLI ao vivo solicitada (`@anthropic-ai/claude-code`, `@openai/codex`, Factory Droid via `https://app.factory.ai/cli`, `@google/gemini-cli` ou `opencode-ai`) se estiver ausente. O próprio backend ACP é o pacote `acpx/runtime` embutido do Plugin `acpx` oficial.
+- A variante Docker do Droid prepara `~/.factory` para configurações, encaminha `FACTORY_API_KEY` e exige essa chave de API, porque a autenticação OAuth/keyring local da Factory não é portável para dentro do contêiner. Ela usa a entrada de registro integrada do ACPX `droid exec --output-format acp`.
+- A variante Docker do OpenCode é uma faixa de regressão estrita de agente único. Ela grava um modelo padrão temporário em `OPENCODE_CONFIG_CONTENT` a partir de `OPENCLAW_LIVE_ACP_BIND_OPENCODE_MODEL` (padrão `opencode/kimi-k2.6`) depois de carregar `~/.profile`, e `pnpm test:docker:live-acp-bind:opencode` exige uma transcrição de assistente vinculada em vez de aceitar o salto pós-vínculo genérico.
+- Chamadas diretas à CLI `acpx` são apenas um caminho manual/de contorno para comparar comportamento fora do Gateway. O teste de fumaça de vínculo ACP do Docker exercita o backend de runtime `acpx` embutido do OpenClaw.

-## Ao vivo: smoke do harness app-server do Codex
+## Ao vivo: teste de fumaça do ambiente de teste do servidor de aplicativo Codex

- Objetivo: validar o harness do Codex de propriedade do Plugin por meio do método
-  `agent` normal do gateway:
+- Objetivo: validar o ambiente de teste Codex pertencente ao Plugin por meio do método
+  `agent` normal do Gateway:
  - carregar o Plugin `codex` incluído
  - selecionar `OPENCLAW_AGENT_RUNTIME=codex`
-  - enviar um primeiro turno de agente pelo gateway para `openai/gpt-5.5` com o harness do Codex forçado
-  - enviar um segundo turno para a mesma sessão do OpenClaw e verificar se a thread do app-server
+  - enviar um primeiro turno de agente do Gateway para `openai/gpt-5.5` com o ambiente de teste Codex forçado
+  - enviar um segundo turno para a mesma sessão OpenClaw e verificar se a thread do servidor de aplicativo
    consegue retomar
-  - executar `/codex status` e `/codex models` pelo mesmo caminho de comando do gateway
-  - opcionalmente executar duas sondagens de shell escaladas revisadas pelo Guardian: um comando
-    benigno que deve ser aprovado e um upload de segredo falso que deve ser
-    negado para que o agente responda perguntando
+  - executar `/codex status` e `/codex models` pelo mesmo caminho de comando do Gateway
+  - opcionalmente executar duas sondagens de shell escaladas revisadas pelo Guardian: um comando benigno
+    que deve ser aprovado e um upload de segredo falso que deve ser
+    negado para que o agente pergunte de volta
 - Teste: `src/gateway/gateway-codex-harness.live.test.ts`
- Ativar: `OPENCLAW_LIVE_CODEX_HARNESS=1`
+- Habilitar: `OPENCLAW_LIVE_CODEX_HARNESS=1`
 - Modelo padrão: `openai/gpt-5.5`
- Sondagem opcional de imagem: `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=1`
- Sondagem opcional de MCP/ferramenta: `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=1`
- Sondagem opcional do Guardian: `OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=1`
- O smoke usa `agentRuntime.id: "codex"` para que um harness do Codex quebrado não possa
+- Sondagem de imagem opcional: `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=1`
+- Sondagem MCP/ferramenta opcional: `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=1`
+- Sondagem Guardian opcional: `OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=1`
+- O teste de fumaça usa `agentRuntime.id: "codex"` para que um ambiente de teste Codex quebrado não consiga
  passar ao recorrer silenciosamente ao PI.
- Autenticação: autenticação app-server do Codex pelo login de assinatura local do Codex. Smokes Docker
+- Autenticação: autenticação do servidor de aplicativo Codex a partir do login de assinatura local do Codex. Testes de fumaça em Docker
  também podem fornecer `OPENAI_API_KEY` para sondagens não Codex quando aplicável,
  além de `~/.codex/auth.json` e `~/.codex/config.toml` copiados opcionalmente.

@ -315,26 +323,26 @@ OPENCLAW_LIVE_CODEX_HARNESS=1 \
  pnpm test:live -- src/gateway/gateway-codex-harness.live.test.ts
 ```

-Receita Docker:
+Receita do Docker:

 ```bash
 source ~/.profile
 pnpm test:docker:live-codex-harness
 ```

-Notas do Docker:
+Observações do Docker:

 - O executor Docker fica em `scripts/test-live-codex-harness-docker.sh`.
- Ele carrega o `~/.profile` montado, passa `OPENAI_API_KEY`, copia arquivos de autenticação da CLI do Codex
+- Ele carrega o `~/.profile` montado, passa `OPENAI_API_KEY`, copia arquivos de autenticação da CLI Codex
  quando presentes, instala `@openai/codex` em um prefixo npm montado gravável,
-  prepara a árvore de origem e então executa somente o teste ao vivo do harness do Codex.
- O Docker ativa por padrão as sondagens de imagem, MCP/ferramenta e Guardian. Defina
+  prepara a árvore de código-fonte e então executa apenas o teste ao vivo do ambiente de teste Codex.
+- O Docker habilita as sondagens de imagem, MCP/ferramenta e Guardian por padrão. Defina
  `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0` ou
  `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0` ou
-  `OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=0` quando precisar de uma execução de depuração
+  `OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=0` quando você precisar de uma execução de depuração
  mais restrita.
- O Docker usa a mesma configuração explícita de runtime do Codex, portanto aliases legados ou fallback para PI
-  não podem ocultar uma regressão do harness do Codex.
+- O Docker usa a mesma configuração explícita de runtime Codex, então aliases legados ou fallback para PI
+  não conseguem ocultar uma regressão do ambiente de teste Codex.

 ### Receitas ao vivo recomendadas

@ -343,40 +351,40 @@ Listas de permissão restritas e explícitas são mais rápidas e menos instáve
 - Modelo único, direto (sem gateway):
  - `OPENCLAW_LIVE_MODELS="openai/gpt-5.5" pnpm test:live src/agents/models.profiles.live.test.ts`

- Modelo único, smoke do gateway:
+- Modelo único, teste de fumaça do Gateway:
  - `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.5" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts`

- Chamada de ferramentas entre vários provedores:
+- Chamada de ferramentas em vários provedores:
  - `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.5,openai-codex/gpt-5.5,anthropic/claude-opus-4-6,google/gemini-3-flash-preview,deepseek/deepseek-v4-flash,zai/glm-5.1,minimax/MiniMax-M2.7" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts`

 - Foco no Google (chave de API Gemini + Antigravity):
  - Gemini (chave de API): `OPENCLAW_LIVE_GATEWAY_MODELS="google/gemini-3-flash-preview" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts`
  - Antigravity (OAuth): `OPENCLAW_LIVE_GATEWAY_MODELS="google-antigravity/claude-opus-4-6-thinking,google-antigravity/gemini-3-pro-high" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts`

- Smoke de raciocínio adaptativo do Google:
-  - Se as chaves locais ficam no perfil do shell: `source ~/.profile`
+- Teste de fumaça de pensamento adaptativo do Google:
+  - Se as chaves locais estiverem no perfil do shell: `source ~/.profile`
  - Padrão dinâmico do Gemini 3: `pnpm openclaw qa manual --provider-mode live-frontier --model google/gemini-3.1-pro-preview --alt-model google/gemini-3.1-pro-preview --message '/think adaptive Reply exactly: GEMINI_ADAPTIVE_OK' --timeout-ms 180000`
  - Orçamento dinâmico do Gemini 2.5: `pnpm openclaw qa manual --provider-mode live-frontier --model google/gemini-2.5-flash --alt-model google/gemini-2.5-flash --message '/think adaptive Reply exactly: GEMINI25_ADAPTIVE_OK' --timeout-ms 180000`

-Notas:
+Observações:

 - `google/...` usa a API Gemini (chave de API).
- `google-antigravity/...` usa a ponte OAuth do Antigravity (endpoint de agente no estilo Cloud Code Assist).
+- `google-antigravity/...` usa a ponte OAuth Antigravity (endpoint de agente no estilo Cloud Code Assist).
 - `google-gemini-cli/...` usa a CLI Gemini local na sua máquina (autenticação separada + peculiaridades de ferramentas).
- API Gemini versus CLI Gemini:
-  - API: o OpenClaw chama a API Gemini hospedada do Google por HTTP (chave de API / autenticação de perfil); é isso que a maioria dos usuários quer dizer com “Gemini”.
-  - CLI: o OpenClaw executa um binário `gemini` local via shell; ele tem sua própria autenticação e pode se comportar de forma diferente (suporte a streaming/ferramentas/desalinhamento de versões).
+- Gemini API vs Gemini CLI:
+  - API: o OpenClaw chama a API Gemini hospedada do Google via HTTP (chave de API / autenticação de perfil); é isso que a maioria dos usuários quer dizer com “Gemini”.
+  - CLI: o OpenClaw executa um binário `gemini` local via shell; ele tem sua própria autenticação e pode se comportar de forma diferente (suporte a streaming/ferramentas/desalinhamento de versão).

 ## Ao vivo: matriz de modelos (o que cobrimos)

-Não há uma “lista de modelos de CI” fixa (ao vivo é opt-in), mas estes são os modelos **recomendados** para cobrir regularmente em uma máquina de desenvolvimento com chaves.
+Não há uma “lista de modelos de CI” fixa (ao vivo é opcional), mas estes são os modelos **recomendados** para cobrir regularmente em uma máquina de desenvolvimento com chaves.

-### Conjunto de smoke moderno (chamada de ferramentas + imagem)
+### Conjunto moderno de teste de fumaça (chamada de ferramentas + imagem)

 Esta é a execução de “modelos comuns” que esperamos manter funcionando:

 - OpenAI (não Codex): `openai/gpt-5.5`
- OAuth do OpenAI Codex: `openai-codex/gpt-5.5`
+- OpenAI Codex OAuth: `openai-codex/gpt-5.5`
 - Anthropic: `anthropic/claude-opus-4-6` (ou `anthropic/claude-sonnet-4-6`)
 - Google (API Gemini): `google/gemini-3.1-pro-preview` e `google/gemini-3-flash-preview` (evite modelos Gemini 2.x mais antigos)
 - Google (Antigravity): `google-antigravity/claude-opus-4-6-thinking` e `google-antigravity/gemini-3-flash`
@ -384,10 +392,10 @@ Esta é a execução de “modelos comuns” que esperamos manter funcionando:
 - Z.AI (GLM): `zai/glm-5.1`
 - MiniMax: `minimax/MiniMax-M2.7`

-Executar smoke do gateway com ferramentas + imagem:
+Execute o teste de fumaça do Gateway com ferramentas + imagem:
 `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.5,openai-codex/gpt-5.5,anthropic/claude-opus-4-6,google/gemini-3.1-pro-preview,google/gemini-3-flash-preview,google-antigravity/claude-opus-4-6-thinking,google-antigravity/gemini-3-flash,deepseek/deepseek-v4-flash,zai/glm-5.1,minimax/MiniMax-M2.7" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts`

-### Linha de base: chamada de ferramentas (Read + Exec opcional)
+### Base: chamada de ferramentas (Read + Exec opcional)

 Escolha pelo menos um por família de provedor:

@ -398,22 +406,22 @@ Escolha pelo menos um por família de provedor:
 - Z.AI (GLM): `zai/glm-5.1`
 - MiniMax: `minimax/MiniMax-M2.7`

-Cobertura adicional opcional (útil ter):
+Cobertura adicional opcional (bom ter):

 - xAI: `xai/grok-4.3` (ou o mais recente disponível)
- Mistral: `mistral/`… (escolha um modelo compatível com “tools” que você tenha ativado)
+- Mistral: `mistral/`… (escolha um modelo compatível com “tools” que você tenha habilitado)
 - Cerebras: `cerebras/`… (se você tiver acesso)
 - LM Studio: `lmstudio/`… (local; a chamada de ferramentas depende do modo de API)

 ### Visão: envio de imagem (anexo → mensagem multimodal)

-Inclua pelo menos um modelo compatível com imagem em `OPENCLAW_LIVE_GATEWAY_MODELS` (variantes compatíveis com visão de Claude/Gemini/OpenAI etc.) para exercitar a sondagem de imagem.
+Inclua pelo menos um modelo compatível com imagem em `OPENCLAW_LIVE_GATEWAY_MODELS` (variantes Claude/Gemini/OpenAI compatíveis com visão etc.) para exercitar a sondagem de imagem.

 ### Agregadores / gateways alternativos

-Se você tiver chaves ativadas, também damos suporte a testes via:
+Se você tiver chaves habilitadas, também oferecemos suporte a testes via:

- OpenRouter: `openrouter/...` (centenas de modelos; use `openclaw models scan` para encontrar candidatos compatíveis com ferramenta+imagem)
+- OpenRouter: `openrouter/...` (centenas de modelos; use `openclaw models scan` para encontrar candidatos compatíveis com ferramentas+imagem)
 - OpenCode: `opencode/...` para Zen e `opencode-go/...` para Go (autenticação via `OPENCODE_API_KEY` / `OPENCODE_ZEN_API_KEY`)

 Mais provedores que você pode incluir na matriz ao vivo (se tiver credenciais/configuração):
@ -422,10 +430,10 @@ Mais provedores que você pode incluir na matriz ao vivo (se tiver credenciais/c
 - Via `models.providers` (endpoints personalizados): `minimax` (nuvem/API), além de qualquer proxy compatível com OpenAI/Anthropic (LM Studio, vLLM, LiteLLM etc.)

 <Tip>
-Não codifique rigidamente "todos os modelos" na documentação. A lista autoritativa é o que `discoverModels(...)` retornar na sua máquina mais as chaves disponíveis.
+Não codifique "todos os modelos" de forma fixa na documentação. A lista autoritativa é o que `discoverModels(...)` retorna na sua máquina, mais as chaves que estiverem disponíveis.
 </Tip>

-## Credenciais (nunca comitar)
+## Credenciais (nunca commite)

 Testes ao vivo descobrem credenciais da mesma forma que a CLI faz. Implicações práticas:

@ -434,10 +442,10 @@ Testes ao vivo descobrem credenciais da mesma forma que a CLI faz. Implicações

 - Perfis de autenticação por agente: `~/.openclaw/agents/<agentId>/agent/auth-profiles.json` (é isso que “chaves de perfil” significa nos testes ao vivo)
 - Configuração: `~/.openclaw/openclaw.json` (ou `OPENCLAW_CONFIG_PATH`)
- Diretório de estado legado: `~/.openclaw/credentials/` (copiado para o home ao vivo preparado quando presente, mas não para o armazenamento principal de chaves de perfil)
- Execuções locais ao vivo copiam por padrão a configuração ativa, os arquivos `auth-profiles.json` por agente, `credentials/` legado e diretórios de autenticação de CLIs externas compatíveis para um home de teste temporário; homes ao vivo preparados ignoram `workspace/` e `sandboxes/`, e substituições de caminho de `agents.*.workspace` / `agentDir` são removidas para que as sondagens fiquem fora do workspace real do seu host.
+- Diretório de estado legado: `~/.openclaw/credentials/` (copiado para a home de teste ao vivo preparada quando presente, mas não é o armazenamento principal de chaves de perfil)
+- Execuções locais ao vivo copiam a configuração ativa, arquivos `auth-profiles.json` por agente, `credentials/` legado e diretórios de autenticação de CLI externa compatíveis para uma home de teste temporária por padrão; homes ao vivo preparadas ignoram `workspace/` e `sandboxes/`, e substituições de caminho `agents.*.workspace` / `agentDir` são removidas para que as sondagens fiquem fora do workspace real do seu host.

-Se quiser depender de chaves de env (por exemplo, exportadas no seu `~/.profile`), execute os testes locais após `source ~/.profile`, ou use os executores Docker abaixo (eles podem montar `~/.profile` no contêiner).
+Se você quiser depender de chaves de ambiente (por exemplo, exportadas no seu `~/.profile`), execute os testes locais após `source ~/.profile`, ou use os executores Docker abaixo (eles podem montar `~/.profile` no contêiner).

 ## Deepgram ao vivo (transcrição de áudio)

@ -455,24 +463,24 @@ Se quiser depender de chaves de env (por exemplo, exportadas no seu `~/.profile`
 - Teste: `extensions/comfy/comfy.live.test.ts`
 - Habilitar: `OPENCLAW_LIVE_TEST=1 COMFY_LIVE_TEST=1 pnpm test:live -- extensions/comfy/comfy.live.test.ts`
 - Escopo:
-  - Exercita os caminhos integrados de imagem, vídeo e `music_generate` do comfy
+  - Exercita os caminhos agrupados de imagem, vídeo e `music_generate` do comfy
  - Ignora cada capacidade a menos que `plugins.entries.comfy.config.<capability>` esteja configurado
-  - Útil após alterar envio de workflow comfy, sondagem, downloads ou registro de plugin
+  - Útil após alterar envio de workflow comfy, polling, downloads ou registro de Plugin

-## Geração de imagem ao vivo
+## Geração de imagens ao vivo

 - Teste: `test/image-generation.runtime.live.test.ts`
 - Comando: `pnpm test:live test/image-generation.runtime.live.test.ts`
- Harness: `pnpm test:live:media image`
+- Harness de teste: `pnpm test:live:media image`
 - Escopo:
-  - Enumera todos os plugins provedores de geração de imagem registrados
-  - Carrega variáveis de env ausentes do provedor a partir do seu shell de login (`~/.profile`) antes da sondagem
-  - Usa chaves de API ao vivo/env antes dos perfis de autenticação armazenados por padrão, para que chaves de teste obsoletas em `auth-profiles.json` não mascarem credenciais reais do shell
+  - Enumera todos os plugins de provedor de geração de imagens registrados
+  - Carrega variáveis de ambiente ausentes do provedor a partir do seu shell de login (`~/.profile`) antes da sondagem
+  - Usa chaves de API ao vivo/de ambiente antes dos perfis de autenticação armazenados por padrão, para que chaves de teste obsoletas em `auth-profiles.json` não ocultem credenciais reais do shell
  - Ignora provedores sem autenticação/perfil/modelo utilizável
-  - Executa cada provedor configurado pelo runtime compartilhado de geração de imagem:
+  - Executa cada provedor configurado pelo runtime compartilhado de geração de imagens:
    - `<provider>:generate`
    - `<provider>:edit` quando o provedor declara suporte a edição
- Provedores integrados atuais cobertos:
+- Provedores agrupados atuais cobertos:
  - `deepinfra`
  - `fal`
  - `google`
@ -481,15 +489,15 @@ Se quiser depender de chaves de env (por exemplo, exportadas no seu `~/.profile`
  - `openrouter`
  - `vydra`
  - `xai`
- Restrição opcional:
+- Estreitamento opcional:
  - `OPENCLAW_LIVE_IMAGE_GENERATION_PROVIDERS="openai,google,openrouter,xai"`
  - `OPENCLAW_LIVE_IMAGE_GENERATION_PROVIDERS="deepinfra"`
  - `OPENCLAW_LIVE_IMAGE_GENERATION_MODELS="openai/gpt-image-2,google/gemini-3.1-flash-image-preview,openrouter/google/gemini-3.1-flash-image-preview,xai/grok-imagine-image"`
  - `OPENCLAW_LIVE_IMAGE_GENERATION_CASES="google:flash-generate,google:pro-edit,openrouter:generate,xai:default-generate,xai:default-edit"`
 - Comportamento opcional de autenticação:
-  - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` para forçar autenticação do armazenamento de perfis e ignorar substituições somente por env
+  - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` para forçar autenticação pelo armazenamento de perfil e ignorar substituições somente de ambiente

-Para o caminho da CLI distribuída, adicione um smoke `infer` depois que o teste ao vivo de provedor/runtime passar:
+Para o caminho da CLI distribuída, adicione uma verificação smoke de `infer` depois que o teste ao vivo de provedor/runtime passar:

 ```bash
 OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_INFER_CLI_TEST=1 pnpm test:live -- test/image-generation.infer-cli.live.test.ts
@ -501,75 +509,75 @@ openclaw infer image generate \
  --json
 ```

-Isso cobre a análise de argumentos da CLI, a resolução de configuração/agente padrão, a ativação de plugins integrados, o runtime compartilhado de geração de imagem e a solicitação ao provedor ao vivo. As dependências dos plugins devem estar presentes antes do carregamento em runtime.
+Isso cobre análise de argumentos da CLI, resolução de configuração/agente padrão, ativação de Plugin agrupado, o runtime compartilhado de geração de imagens e a solicitação ao provedor ao vivo. Espera-se que as dependências de Plugin estejam presentes antes do carregamento em runtime.

 ## Geração de música ao vivo

 - Teste: `extensions/music-generation-providers.live.test.ts`
 - Habilitar: `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/music-generation-providers.live.test.ts`
- Harness: `pnpm test:live:media music`
+- Harness de teste: `pnpm test:live:media music`
 - Escopo:
-  - Exercita o caminho compartilhado de provedor integrado de geração de música
+  - Exercita o caminho compartilhado agrupado de provedor de geração de música
  - Atualmente cobre Google e MiniMax
-  - Carrega variáveis de env do provedor a partir do seu shell de login (`~/.profile`) antes da sondagem
-  - Usa chaves de API ao vivo/env antes dos perfis de autenticação armazenados por padrão, para que chaves de teste obsoletas em `auth-profiles.json` não mascarem credenciais reais do shell
+  - Carrega variáveis de ambiente do provedor a partir do seu shell de login (`~/.profile`) antes da sondagem
+  - Usa chaves de API ao vivo/de ambiente antes dos perfis de autenticação armazenados por padrão, para que chaves de teste obsoletas em `auth-profiles.json` não ocultem credenciais reais do shell
  - Ignora provedores sem autenticação/perfil/modelo utilizável
  - Executa ambos os modos de runtime declarados quando disponíveis:
    - `generate` com entrada somente de prompt
    - `edit` quando o provedor declara `capabilities.edit.enabled`
-  - Cobertura atual da faixa compartilhada:
+  - Cobertura atual da lane compartilhada:
    - `google`: `generate`, `edit`
    - `minimax`: `generate`
    - `comfy`: arquivo ao vivo separado do Comfy, não esta varredura compartilhada
- Restrição opcional:
+- Estreitamento opcional:
  - `OPENCLAW_LIVE_MUSIC_GENERATION_PROVIDERS="google,minimax"`
  - `OPENCLAW_LIVE_MUSIC_GENERATION_MODELS="google/lyria-3-clip-preview,minimax/music-2.6"`
 - Comportamento opcional de autenticação:
-  - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` para forçar autenticação do armazenamento de perfis e ignorar substituições somente por env
+  - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` para forçar autenticação pelo armazenamento de perfil e ignorar substituições somente de ambiente

 ## Geração de vídeo ao vivo

 - Teste: `extensions/video-generation-providers.live.test.ts`
 - Habilitar: `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/video-generation-providers.live.test.ts`
- Harness: `pnpm test:live:media video`
+- Harness de teste: `pnpm test:live:media video`
 - Escopo:
-  - Exercita o caminho compartilhado de provedor integrado de geração de vídeo
-  - Usa por padrão o caminho de smoke seguro para release: provedores que não sejam FAL, uma solicitação de texto para vídeo por provedor, prompt de lagosta de um segundo e um limite de operação por provedor de `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS` (`180000` por padrão)
-  - Ignora FAL por padrão porque a latência da fila do lado do provedor pode dominar o tempo de release; passe `--video-providers fal` ou `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="fal"` para executá-lo explicitamente
-  - Carrega variáveis de env do provedor a partir do seu shell de login (`~/.profile`) antes da sondagem
-  - Usa chaves de API ao vivo/env antes dos perfis de autenticação armazenados por padrão, para que chaves de teste obsoletas em `auth-profiles.json` não mascarem credenciais reais do shell
+  - Exercita o caminho compartilhado agrupado de provedor de geração de vídeo
+  - Usa como padrão o caminho smoke seguro para release: provedores que não são FAL, uma solicitação de texto para vídeo por provedor, prompt de lagosta de um segundo e um limite de operação por provedor vindo de `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS` (`180000` por padrão)
+  - Ignora FAL por padrão porque a latência da fila no lado do provedor pode dominar o tempo de release; passe `--video-providers fal` ou `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="fal"` para executá-lo explicitamente
+  - Carrega variáveis de ambiente do provedor a partir do seu shell de login (`~/.profile`) antes da sondagem
+  - Usa chaves de API ao vivo/de ambiente antes dos perfis de autenticação armazenados por padrão, para que chaves de teste obsoletas em `auth-profiles.json` não ocultem credenciais reais do shell
  - Ignora provedores sem autenticação/perfil/modelo utilizável
-  - Executa somente `generate` por padrão
+  - Executa apenas `generate` por padrão
  - Defina `OPENCLAW_LIVE_VIDEO_GENERATION_FULL_MODES=1` para também executar modos de transformação declarados quando disponíveis:
    - `imageToVideo` quando o provedor declara `capabilities.imageToVideo.enabled` e o provedor/modelo selecionado aceita entrada de imagem local baseada em buffer na varredura compartilhada
    - `videoToVideo` quando o provedor declara `capabilities.videoToVideo.enabled` e o provedor/modelo selecionado aceita entrada de vídeo local baseada em buffer na varredura compartilhada
-  - Provedores `imageToVideo` atualmente declarados mas ignorados na varredura compartilhada:
-    - `vydra` porque o `veo3` integrado é somente texto e o `kling` integrado exige uma URL remota de imagem
+  - Provedores atuais de `imageToVideo` declarados, mas ignorados, na varredura compartilhada:
+    - `vydra` porque o `veo3` agrupado aceita apenas texto e o `kling` agrupado exige uma URL de imagem remota
  - Cobertura específica do provedor Vydra:
    - `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_VYDRA_VIDEO=1 pnpm test:live -- extensions/vydra/vydra.live.test.ts`
-    - esse arquivo executa texto para vídeo `veo3` mais uma faixa `kling` que usa por padrão uma fixture de URL remota de imagem
+    - esse arquivo executa texto para vídeo com `veo3` mais uma lane `kling` que usa um fixture de URL de imagem remota por padrão
  - Cobertura ao vivo atual de `videoToVideo`:
    - `runway` somente quando o modelo selecionado é `runway/gen4_aleph`
-  - Provedores `videoToVideo` atualmente declarados mas ignorados na varredura compartilhada:
-    - `alibaba`, `qwen`, `xai` porque esses caminhos atualmente exigem URLs remotas `http(s)` / de referência MP4
-    - `google` porque a faixa compartilhada atual Gemini/Veo usa entrada local baseada em buffer e esse caminho não é aceito na varredura compartilhada
-    - `openai` porque a faixa compartilhada atual não tem garantias de acesso específicas da organização a inpaint/remix de vídeo
- Restrição opcional:
+  - Provedores atuais de `videoToVideo` declarados, mas ignorados, na varredura compartilhada:
+    - `alibaba`, `qwen`, `xai` porque esses caminhos atualmente exigem URLs remotas de referência `http(s)` / MP4
+    - `google` porque a lane compartilhada atual de Gemini/Veo usa entrada local baseada em buffer e esse caminho não é aceito na varredura compartilhada
+    - `openai` porque a lane compartilhada atual não tem garantias de acesso específico da organização a inpaint/remix de vídeo
+- Estreitamento opcional:
  - `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="deepinfra,google,openai,runway"`
  - `OPENCLAW_LIVE_VIDEO_GENERATION_MODELS="google/veo-3.1-fast-generate-preview,openai/sora-2,runway/gen4_aleph"`
  - `OPENCLAW_LIVE_VIDEO_GENERATION_SKIP_PROVIDERS=""` para incluir todos os provedores na varredura padrão, incluindo FAL
-  - `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS=60000` para reduzir o limite de cada operação de provedor em uma execução smoke agressiva
+  - `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS=60000` para reduzir o limite de operação de cada provedor para uma execução smoke agressiva
 - Comportamento opcional de autenticação:
-  - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` para forçar autenticação do armazenamento de perfis e ignorar substituições somente por env
+  - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` para forçar autenticação pelo armazenamento de perfil e ignorar substituições somente de ambiente

-## Harness de mídia ao vivo
+## Harness de teste ao vivo de mídia

 - Comando: `pnpm test:live:media`
 - Finalidade:
-  - Executa as suítes ao vivo compartilhadas de imagem, música e vídeo por meio de um único ponto de entrada nativo do repo
-  - Carrega automaticamente variáveis de env ausentes do provedor a partir de `~/.profile`
-  - Restringe automaticamente cada suíte aos provedores que atualmente têm autenticação utilizável por padrão
-  - Reutiliza `scripts/test-live.mjs`, então o comportamento de Heartbeat e modo silencioso permanece consistente
+  - Executa as suítes ao vivo compartilhadas de imagem, música e vídeo por um único ponto de entrada nativo do repositório
+  - Carrega automaticamente variáveis de ambiente ausentes do provedor a partir de `~/.profile`
+  - Estreita automaticamente cada suíte para provedores que atualmente têm autenticação utilizável por padrão
+  - Reutiliza `scripts/test-live.mjs`, portanto o comportamento de Heartbeat e modo silencioso permanece consistente
 - Exemplos:
  - `pnpm test:live:media`
  - `pnpm test:live:media image video --providers openai,google,minimax`
--- a/docs/pt-BR/plugins/hooks.md
+++ b/docs/pt-BR/plugins/hooks.md
@ -1,30 +1,30 @@
 ---
 read_when:
-    - Você está criando um Plugin que precisa de before_tool_call, before_agent_reply, hooks de mensagem ou hooks de ciclo de vida
-    - É necessário bloquear, reescrever ou exigir aprovação para chamadas de ferramenta de um Plugin
+    - Você está criando um Plugin que precisa de before_tool_call, before_agent_reply, ganchos de mensagem ou ganchos de ciclo de vida
+    - Você precisa bloquear, reescrever ou exigir aprovação para chamadas de ferramenta de um Plugin
    - Você está decidindo entre ganchos internos e ganchos de Plugin
 summary: 'Ganchos de Plugin: intercepte eventos do ciclo de vida de agente, ferramenta, mensagem, sessão e Gateway'
 title: Ganchos de Plugin
 x-i18n:
-    generated_at: "2026-05-03T21:36:03Z"
+    generated_at: "2026-05-04T18:23:43Z"
    model: gpt-5.5
    provider: openai
-    source_hash: 2c4ed060f1b89917e1f2f46d2da9448cd562edbcd6ce03bc9b1a83da3ed9a591
+    source_hash: 37c7273036463c87e478db5678822b676c89447caee65f2f3f47a45194d1e37b
    source_path: plugins/hooks.md
    workflow: 16
 ---

-Hooks de plugins são pontos de extensão em processo para plugins do OpenClaw. Use-os
-quando um plugin precisar inspecionar ou alterar execuções de agentes, chamadas de ferramentas, fluxo de mensagens,
-ciclo de vida de sessões, roteamento de subagentes, instalações ou inicialização do Gateway.
+Hooks de Plugin são pontos de extensão em processo para plugins do OpenClaw. Use-os
+quando um plugin precisa inspecionar ou alterar execuções de agentes, chamadas de ferramentas, fluxo de mensagens,
+ciclo de vida da sessão, roteamento de subagentes, instalações ou inicialização do Gateway.

-Use [hooks internos](/pt-BR/automation/hooks) em vez disso quando quiser um pequeno
-script `HOOK.md` instalado pelo operador para eventos de comando e do Gateway, como
+Use [hooks internos](/pt-BR/automation/hooks) quando quiser um pequeno script
+`HOOK.md` instalado pelo operador para eventos de comando e Gateway, como
 `/new`, `/reset`, `/stop`, `agent:bootstrap` ou `gateway:startup`.

 ## Início rápido

-Registre hooks tipados de plugin com `api.on(...)` a partir da entrada do seu plugin:
+Registre hooks de plugin tipados com `api.on(...)` a partir da entrada do seu plugin:

 ```typescript
 import { definePluginEntry } from "openclaw/plugin-sdk/plugin-entry";
@ -56,16 +56,16 @@ export default definePluginEntry({
 });
 ```

-Manipuladores de hook são executados sequencialmente em ordem decrescente de `priority`. Hooks com a mesma prioridade
-mantêm a ordem de registro.
+Os manipuladores de hook são executados sequencialmente em ordem decrescente de `priority`. Hooks
+com a mesma prioridade mantêm a ordem de registro.

 `api.on(name, handler, opts?)` aceita:

- `priority` — ordenação do manipulador (maior executa primeiro).
+- `priority` — ordenação dos manipuladores (valores maiores executam primeiro).
 - `timeoutMs` — orçamento opcional por hook. Quando definido, o executor de hooks interrompe esse
  manipulador após o orçamento expirar e continua com o próximo, em vez de
-  permitir que uma configuração lenta ou trabalho de recordação consuma o timeout de modelo
-  configurado pelo chamador. Omita para usar o timeout padrão de observação/decisão que o
+  deixar configuração lenta ou trabalho de recuperação consumir o timeout de modelo configurado
+  pelo chamador. Omita para usar o timeout padrão de observação/decisão que o
  executor de hooks aplica genericamente.

 Operadores também podem definir orçamentos de hook sem alterar o código do plugin:
@ -88,54 +88,54 @@ Operadores também podem definir orçamentos de hook sem alterar o código do pl
 }
 ```

-`hooks.timeouts.<hookName>` substitui `hooks.timeoutMs`, que substitui o valor
-`api.on(..., { timeoutMs })` criado pelo plugin. Cada valor configurado deve
+`hooks.timeouts.<hookName>` substitui `hooks.timeoutMs`, que substitui o
+valor `api.on(..., { timeoutMs })` criado pelo plugin. Cada valor configurado deve
 ser um inteiro positivo não maior que 600000 milissegundos. Prefira substituições por hook
-para hooks conhecidos por serem lentos, para que um plugin não receba um orçamento maior
+para hooks reconhecidamente lentos, para que um plugin não receba um orçamento maior
 em todos os lugares.

 Cada hook recebe `event.context.pluginConfig`, a configuração resolvida para o
-plugin que registrou aquele manipulador. Use isso para decisões de hook que precisam das
+plugin que registrou aquele manipulador. Use-a para decisões de hook que precisam das
 opções atuais do plugin; o OpenClaw a injeta por manipulador sem modificar o
 objeto de evento compartilhado visto por outros plugins.

 ## Catálogo de hooks

 Hooks são agrupados pela superfície que estendem. Nomes em **negrito** aceitam um
-resultado de decisão (bloquear, cancelar, substituir ou exigir aprovação); todos os outros são
+resultado de decisão (bloquear, cancelar, substituir ou exigir aprovação); todos os demais são
 somente de observação.

 **Turno do agente**

 - `before_model_resolve` — substitui o provedor ou modelo antes de carregar as mensagens da sessão
 - `agent_turn_prepare` — consome injeções de turno de plugin enfileiradas e adiciona contexto no mesmo turno antes dos hooks de prompt
- `before_prompt_build` — adiciona contexto dinâmico ou texto de prompt de sistema antes da chamada do modelo
- `before_agent_start` — fase combinada apenas para compatibilidade; prefira os dois hooks acima
+- `before_prompt_build` — adiciona contexto dinâmico ou texto de prompt do sistema antes da chamada ao modelo
+- `before_agent_start` — fase combinada somente para compatibilidade; prefira os dois hooks acima
 - **`before_agent_reply`** — interrompe o turno do modelo com uma resposta sintética ou silêncio
 - **`before_agent_finalize`** — inspeciona a resposta final natural e solicita mais uma passagem do modelo
 - `agent_end` — observa mensagens finais, estado de sucesso e duração da execução
 - `heartbeat_prompt_contribution` — adiciona contexto somente de Heartbeat para plugins de monitoramento em segundo plano e ciclo de vida

-**Observação de conversa**
+**Observação da conversa**

- `model_call_started` / `model_call_ended` — observa metadados higienizados de chamada de provedor/modelo, temporização, resultado e hashes limitados de IDs de solicitação sem conteúdo de prompt ou resposta
- `llm_input` — observa a entrada do provedor (prompt de sistema, prompt, histórico)
+- `model_call_started` / `model_call_ended` — observa metadados higienizados de chamada de provedor/modelo, tempo, resultado e hashes limitados de IDs de solicitação sem conteúdo de prompt ou resposta
+- `llm_input` — observa a entrada do provedor (prompt do sistema, prompt, histórico)
 - `llm_output` — observa a saída do provedor

 **Ferramentas**

- **`before_tool_call`** — reescreve parâmetros da ferramenta, bloqueia a execução ou exige aprovação
+- **`before_tool_call`** — reescreve parâmetros de ferramenta, bloqueia a execução ou exige aprovação
 - `after_tool_call` — observa resultados de ferramenta, erros e duração
 - **`tool_result_persist`** — reescreve a mensagem do assistente produzida a partir de um resultado de ferramenta
 - **`before_message_write`** — inspeciona ou bloqueia uma gravação de mensagem em andamento (raro)

 **Mensagens e entrega**

- **`inbound_claim`** — reivindica uma mensagem recebida antes do roteamento do agente (respostas sintéticas)
- `message_received` — observa conteúdo recebido, remetente, thread e metadados
+- **`inbound_claim`** — reivindica uma mensagem de entrada antes do roteamento do agente (respostas sintéticas)
+- `message_received` — observa conteúdo de entrada, remetente, thread e metadados
 - **`message_sending`** — reescreve conteúdo de saída ou cancela a entrega
 - `message_sent` — observa sucesso ou falha na entrega de saída
- **`before_dispatch`** — inspeciona ou reescreve um despacho de saída antes da entrega ao canal
+- **`before_dispatch`** — inspeciona ou reescreve um despacho de saída antes da transferência para o canal
 - **`reply_dispatch`** — participa do pipeline final de despacho de resposta

 **Sessões e Compaction**
@ -150,9 +150,9 @@ somente de observação.

 **Ciclo de vida**

- `gateway_start` / `gateway_stop` — inicia ou interrompe serviços pertencentes ao plugin junto com o Gateway
- `cron_changed` — observa mudanças no ciclo de vida de Cron pertencente ao gateway (adicionado, atualizado, removido, iniciado, finalizado, agendado)
- **`before_install`** — inspeciona varreduras de instalação de Skills ou plugins e opcionalmente bloqueia
+- `gateway_start` / `gateway_stop` — inicia ou para serviços pertencentes ao plugin com o Gateway
+- `cron_changed` — observa mudanças no ciclo de vida de cron pertencente ao gateway (adicionado, atualizado, removido, iniciado, concluído, agendado)
+- **`before_install`** — inspeciona varreduras de instalação de skill ou plugin e opcionalmente bloqueia

 ## Política de chamadas de ferramenta

@ -163,7 +163,7 @@ somente de observação.
 - `event.runId` opcional
 - `event.toolCallId` opcional
 - campos de contexto como `ctx.agentId`, `ctx.sessionKey`, `ctx.sessionId`,
-  `ctx.runId`, `ctx.jobId` (definido em execuções acionadas por Cron) e `ctx.trace` de diagnóstico
+  `ctx.runId`, `ctx.jobId` (definido em execuções acionadas por cron) e `ctx.trace` diagnóstico

 Ele pode retornar:

@ -188,35 +188,34 @@ type BeforeToolCallResult = {

 Regras:

- `block: true` é terminal e ignora manipuladores de prioridade menor.
+- `block: true` é terminal e ignora manipuladores de prioridade mais baixa.
 - `block: false` é tratado como ausência de decisão.
 - `params` reescreve os parâmetros da ferramenta para execução.
 - `requireApproval` pausa a execução do agente e pergunta ao usuário por meio de aprovações
-  de plugin. O comando `/approve` pode aprovar aprovações de exec e de plugin.
- Um `block: true` de prioridade menor ainda pode bloquear após um hook de prioridade maior
-  ter solicitado aprovação.
+  de plugin. O comando `/approve` pode aprovar tanto aprovações de exec quanto de plugin.
+- Um `block: true` de prioridade mais baixa ainda pode bloquear depois que um hook de prioridade mais alta
+  solicitou aprovação.
 - `onResolution` recebe a decisão de aprovação resolvida — `allow-once`,
  `allow-always`, `deny`, `timeout` ou `cancelled`.

 Plugins incluídos que precisam de política em nível de host podem registrar políticas de ferramenta confiáveis
-com `api.registerTrustedToolPolicy(...)`. Elas são executadas antes dos hooks
-`before_tool_call` comuns e antes das decisões de plugins externos. Use-as apenas
-para verificações confiadas pelo host, como política de workspace, aplicação de orçamento ou
-segurança de fluxos de trabalho reservados. Plugins externos devem usar hooks normais
-`before_tool_call`.
+com `api.registerTrustedToolPolicy(...)`. Elas executam antes dos hooks comuns de
+`before_tool_call` e antes das decisões de plugins externos. Use-as apenas
+para bloqueios confiáveis do host, como política de workspace, aplicação de orçamento ou
+segurança de fluxos de trabalho reservados. Plugins externos devem usar hooks normais de `before_tool_call`.

 ### Persistência de resultado de ferramenta

-Resultados de ferramenta podem incluir `details` estruturados para renderização de UI, diagnósticos,
+Resultados de ferramenta podem incluir `details` estruturados para renderização na UI, diagnósticos,
 roteamento de mídia ou metadados pertencentes ao plugin. Trate `details` como metadados de runtime,
 não como conteúdo de prompt:

- O OpenClaw remove `toolResult.details` antes da reprodução no provedor e da entrada de Compaction,
-  para que metadados não se tornem contexto do modelo.
+- O OpenClaw remove `toolResult.details` antes da repetição para o provedor e da entrada de Compaction
+  para que os metadados não se tornem contexto do modelo.
 - Entradas de sessão persistidas mantêm apenas `details` limitados. Detalhes grandes demais são
  substituídos por um resumo compacto e `persistedDetailsTruncated: true`.
- `tool_result_persist` e `before_message_write` são executados antes do limite final
-  de persistência. Hooks ainda devem manter `details` retornados pequenos e evitar
+- `tool_result_persist` e `before_message_write` executam antes do limite final
+  de persistência. Hooks ainda devem manter pequenos os `details` retornados e evitar
  colocar texto relevante para o prompt apenas em `details`; coloque a saída de ferramenta visível ao modelo
  em `content`.

@ -224,53 +223,68 @@ não como conteúdo de prompt:

 Use os hooks específicos de fase para novos plugins:

- `before_model_resolve`: recebe apenas o prompt atual e metadados de anexo.
-  Retorne `providerOverride` ou `modelOverride`.
+- `before_model_resolve`: recebe apenas o prompt atual e metadados de anexos.
+  Retorna `providerOverride` ou `modelOverride`.
 - `agent_turn_prepare`: recebe o prompt atual, mensagens de sessão preparadas
-  e quaisquer injeções enfileiradas de execução única drenadas para esta sessão. Retorne
+  e quaisquer injeções enfileiradas exatamente uma vez drenadas para esta sessão. Retorna
  `prependContext` ou `appendContext`.
 - `before_prompt_build`: recebe o prompt atual e mensagens da sessão.
-  Retorne `prependContext`, `appendContext`, `systemPrompt`,
+  Retorna `prependContext`, `appendContext`, `systemPrompt`,
  `prependSystemContext` ou `appendSystemContext`.
 - `heartbeat_prompt_contribution`: executa apenas para turnos de Heartbeat e retorna
  `prependContext` ou `appendContext`. Destina-se a monitores em segundo plano
  que precisam resumir o estado atual sem alterar turnos iniciados pelo usuário.

-`before_agent_start` permanece para compatibilidade. Prefira os hooks explícitos acima
+`before_agent_start` permanece por compatibilidade. Prefira os hooks explícitos acima
 para que seu plugin não dependa de uma fase combinada legada.

 `before_agent_start` e `agent_end` incluem `event.runId` quando o OpenClaw consegue
 identificar a execução ativa. O mesmo valor também está disponível em `ctx.runId`.
-Execuções acionadas por Cron também expõem `ctx.jobId` (o ID do job Cron de origem) para que
+Execuções acionadas por Cron também expõem `ctx.jobId` (o id do job cron de origem) para que
 hooks de plugin possam escopar métricas, efeitos colaterais ou estado para um job agendado
 específico.

-Para execuções originadas em canais, `ctx.messageProvider` é a superfície do provedor, como
+Para execuções originadas por canal, `ctx.messageProvider` é a superfície do provedor, como
 `discord` ou `telegram`, enquanto `ctx.channelId` é o identificador de destino da conversa
-quando o OpenClaw consegue derivar um a partir da chave de sessão ou dos metadados de
-entrega.
+quando o OpenClaw consegue derivá-lo da chave de sessão ou dos metadados de entrega.

 `agent_end` é um hook de observação e executa em modo fire-and-forget após o turno. O
 executor de hooks aplica um timeout de 30 segundos para que um plugin travado ou endpoint
-de embeddings não possa deixar a promessa do hook pendente para sempre. Um timeout é registrado e
+de embeddings não deixe a promise do hook pendente para sempre. Um timeout é registrado em log e
 o OpenClaw continua; ele não cancela trabalho de rede pertencente ao plugin, a menos que o
-plugin também use seu próprio sinal de aborto.
+plugin também use seu próprio sinal de abort.

-Use `model_call_started` e `model_call_ended` para telemetria de chamadas de provedor
+Use `model_call_started` e `model_call_ended` para telemetria de chamada de provedor
 que não deve receber prompts brutos, histórico, respostas, cabeçalhos, corpos de solicitação
-ou IDs de solicitação do provedor. Esses hooks incluem metadados estáveis, como
-`runId`, `callId`, `provider`, `model`, `api`/`transport` opcional,
+ou IDs de solicitação do provedor. Esses hooks incluem metadados estáveis como
+`runId`, `callId`, `provider`, `model`, `api`/`transport` opcionais,
 `durationMs`/`outcome` terminal e `upstreamRequestIdHash` quando o OpenClaw consegue derivar um
 hash limitado de ID de solicitação do provedor.

 `before_agent_finalize` executa apenas quando um harness está prestes a aceitar uma resposta
 final natural do assistente. Ele não é o caminho de cancelamento `/stop` e não
-executa quando o usuário interrompe um turno. Retorne `{ action: "revise", reason }` para pedir
+executa quando o usuário aborta um turno. Retorne `{ action: "revise", reason }` para pedir
 ao harness mais uma passagem do modelo antes da finalização, `{ action:
 "finalize", reason? }` para forçar a finalização, ou omita um resultado para continuar.
-Hooks nativos `Stop` do Codex são retransmitidos para este hook como decisões
+Hooks `Stop` nativos do Codex são retransmitidos para este hook como decisões
 `before_agent_finalize` do OpenClaw.

+Ao retornar `action: "revise"`, plugins podem incluir metadados `retry` para tornar
+a passagem extra do modelo limitada e segura para repetição:
+
+```typescript
+type BeforeAgentFinalizeRetry = {
+  instruction: string;
+  idempotencyKey?: string;
+  maxAttempts?: number;
+};
+```
+
+`instruction` é anexado ao motivo de revisão enviado ao harness.
+`idempotencyKey` permite que o host conte tentativas para a mesma solicitação de plugin entre
+decisões de finalização equivalentes, e `maxAttempts` limita quantas passagens extras o
+host permitirá antes de continuar com a resposta final natural.
+
 Plugins não incluídos que precisam de `llm_input`, `llm_output`,
 `before_agent_finalize` ou `agent_end` devem definir:

@ -288,53 +302,53 @@ Plugins não incluídos que precisam de `llm_input`, `llm_output`,
 }
 ```

-Hooks que modificam prompts e injeções duráveis para o próximo turno podem ser desabilitados por plugin
+Hooks que alteram prompts e injeções duráveis de próximo turno podem ser desativados por plugin
 com `plugins.entries.<id>.hooks.allowPromptInjection=false`.

-### Extensões de sessão e injeções no próximo turno
+### Extensões de sessão e injeções de próximo turno

-Plugins de fluxo de trabalho podem persistir pequeno estado de sessão compatível com JSON com
-`api.registerSessionExtension(...)` e atualizá-lo pelo método
-`sessions.pluginPatch` do Gateway. Linhas de sessão projetam estado de extensão registrado
-por meio de `pluginExtensions`, permitindo que Control UI e outros clientes renderizem
+Os plugins de workflow podem persistir pequenos estados de sessão compatíveis com JSON com
+`api.registerSessionExtension(...)` e atualizá-los por meio do método
+`sessions.pluginPatch` do Gateway. As linhas de sessão projetam o estado de extensão registrado
+por meio de `pluginExtensions`, permitindo que a Control UI e outros clientes renderizem
 status pertencente ao plugin sem conhecer os detalhes internos do plugin.

-Use `api.enqueueNextTurnInjection(...)` quando um plugin precisa de contexto durável para
-chegar ao próximo turno do modelo exatamente uma vez. O OpenClaw drena as injeções enfileiradas antes dos
-hooks de prompt, descarta injeções expiradas e faz deduplicação por `idempotencyKey`
+Use `api.enqueueNextTurnInjection(...)` quando um plugin precisar que contexto durável
+chegue ao próximo turno do modelo exatamente uma vez. O OpenClaw drena as injeções enfileiradas antes
+dos hooks de prompt, descarta injeções expiradas e desduplica por `idempotencyKey`
 por plugin. Esta é a interface correta para retomadas de aprovação, resumos de política,
-deltas de monitores em segundo plano e continuações de comandos que devem ficar visíveis para
-o modelo no próximo turno, mas não devem se tornar texto permanente do prompt do sistema.
+deltas de monitor em segundo plano e continuações de comandos que devem ficar visíveis para
+o modelo no próximo turno, mas não devem se tornar texto permanente do prompt de sistema.

-As semânticas de limpeza fazem parte do contrato. A limpeza de extensão de sessão e os
-callbacks de limpeza do ciclo de vida em runtime recebem `reset`, `delete`, `disable` ou
-`restart`. O host remove o estado persistente da extensão de sessão do plugin proprietário
-e as injeções pendentes do próximo turno para reset/delete/disable; restart mantém
-o estado durável da sessão enquanto os callbacks de limpeza permitem que os plugins liberem tarefas de
-agendador, contexto de execução e outros recursos fora de banda da antiga geração de
+As semânticas de limpeza fazem parte do contrato. A limpeza de extensão de sessão e
+os callbacks de limpeza do ciclo de vida de runtime recebem `reset`, `delete`, `disable` ou
+`restart`. O host remove o estado persistente de extensão de sessão do plugin proprietário
+e as injeções pendentes de próximo turno para reset/delete/disable; restart mantém
+o estado durável da sessão enquanto os callbacks de limpeza permitem que plugins liberem jobs
+do agendador, contexto de execução e outros recursos fora de banda da antiga geração de
 runtime.

 ## Hooks de mensagem

-Use hooks de mensagem para roteamento e política de entrega no nível do canal:
+Use hooks de mensagem para roteamento em nível de canal e política de entrega:

- `message_received`: observe conteúdo de entrada, remetente, `threadId`, `messageId`,
+- `message_received`: observa conteúdo de entrada, remetente, `threadId`, `messageId`,
  `senderId`, correlação opcional de execução/sessão e metadados.
- `message_sending`: reescreva `content` ou retorne `{ cancel: true }`.
- `message_sent`: observe sucesso ou falha final.
+- `message_sending`: reescreve `content` ou retorna `{ cancel: true }`.
+- `message_sent`: observa sucesso ou falha final.

 Para respostas TTS somente com áudio, `content` pode conter a transcrição falada oculta
 mesmo quando o payload do canal não tem texto/legenda visível. Reescrever esse
-`content` atualiza apenas a transcrição visível ao hook; ela não é renderizada como uma
+`content` atualiza apenas a transcrição visível ao hook; ela não é renderizada como
 legenda de mídia.

-Os contextos de hooks de mensagem expõem campos de correlação estáveis quando disponíveis:
+Contextos de hook de mensagem expõem campos de correlação estáveis quando disponíveis:
 `ctx.sessionKey`, `ctx.runId`, `ctx.messageId`, `ctx.senderId`, `ctx.trace`,
 `ctx.traceId`, `ctx.spanId`, `ctx.parentSpanId` e `ctx.callDepth`. Prefira
 esses campos de primeira classe antes de ler metadados legados.

-Prefira os campos tipados `threadId` e `replyToId` antes de usar metadados
-específicos do canal.
+Prefira os campos tipados `threadId` e `replyToId` antes de usar metadados específicos
+do canal.

 Regras de decisão:

@ -345,7 +359,7 @@ Regras de decisão:

 ## Hooks de instalação

-`before_install` executa após a varredura integrada para instalações de skill e plugin.
+`before_install` é executado após a varredura integrada para instalações de skill e plugin.
 Retorne achados adicionais ou `{ block: true, blockReason }` para interromper a
 instalação.

@ -355,21 +369,21 @@ instalação.

 Use `gateway_start` para serviços de plugin que precisam de estado pertencente ao Gateway. O
 contexto expõe `ctx.config`, `ctx.workspaceDir` e `ctx.getCron?.()` para
-inspeção e atualizações de Cron. Use `gateway_stop` para limpar recursos
+inspeção e atualizações de cron. Use `gateway_stop` para limpar recursos
 de longa duração.

 Não dependa do hook interno `gateway:startup` para serviços de runtime
 pertencentes ao plugin.

-`cron_changed` dispara para eventos de ciclo de vida de Cron pertencentes ao Gateway com um payload de
-evento tipado que cobre os motivos `added`, `updated`, `removed`, `started`, `finished`
+`cron_changed` dispara para eventos de ciclo de vida de cron pertencentes ao gateway com um payload
+de evento tipado cobrindo os motivos `added`, `updated`, `removed`, `started`, `finished`
 e `scheduled`. O evento carrega um snapshot `PluginHookGatewayCronJob`
 (incluindo `state.nextRunAtMs`, `state.lastRunStatus` e
 `state.lastError` quando presente), além de um `PluginHookGatewayCronDeliveryStatus`
 de `not-requested` | `delivered` | `not-delivered` | `unknown`. Eventos removidos
-ainda carregam o snapshot da tarefa excluída para que agendadores externos possam
+ainda carregam o snapshot do job excluído para que agendadores externos possam
 reconciliar o estado. Use `ctx.getCron?.()` e `ctx.config` do contexto de runtime
-ao sincronizar agendadores externos de ativação, e mantenha o OpenClaw como a
+ao sincronizar agendadores de ativação externos, e mantenha o OpenClaw como a
 fonte da verdade para verificações de vencimento e execução.

 ## Próximas descontinuações
@ -379,18 +393,17 @@ antes da próxima versão principal:

 - **Envelopes de canal em texto simples** em handlers `inbound_claim` e `message_received`.
  Leia `BodyForAgent` e os blocos estruturados de contexto do usuário
-  em vez de analisar texto plano de envelope. Consulte
+  em vez de analisar texto plano do envelope. Consulte
  [Envelopes de canal em texto simples → BodyForAgent](/pt-BR/plugins/sdk-migration#active-deprecations).
 - **`before_agent_start`** permanece por compatibilidade. Novos plugins devem usar
-  `before_model_resolve` e `before_prompt_build` em vez da fase
-  combinada.
+  `before_model_resolve` e `before_prompt_build` em vez da fase combinada.
 - **`onResolution` em `before_tool_call`** agora usa a união tipada
  `PluginApprovalResolution` (`allow-once` / `allow-always` / `deny` /
-  `timeout` / `cancelled`) em vez de uma `string` de formato livre.
+  `timeout` / `cancelled`) em vez de uma `string` livre.

 Para a lista completa — registro de capacidade de memória, perfil de raciocínio do provedor,
-provedores externos de autenticação, tipos de descoberta de provedor, acessores de runtime
-de tarefa e a renomeação de `command-auth` → `command-status` — consulte
+provedores externos de autenticação, tipos de descoberta de provedor, acessadores de runtime
+de tarefa e a renomeação `command-auth` → `command-status` — consulte
 [Migração do Plugin SDK → Descontinuações ativas](/pt-BR/plugins/sdk-migration#active-deprecations).

 ## Relacionados
--- a/docs/pt-BR/plugins/sdk-overview.md
+++ b/docs/pt-BR/plugins/sdk-overview.md
@ -2,32 +2,32 @@
 read_when:
    - Você precisa saber de qual subcaminho do SDK importar
    - Você quer uma referência para todos os métodos de registro em OpenClawPluginApi
-    - Você está consultando uma exportação específica do SDK
+    - Você está procurando uma exportação específica do SDK
 sidebarTitle: Plugin SDK overview
 summary: Mapa de importação, referência da API de registro e arquitetura do SDK
 title: Visão geral do SDK de Plugin
 x-i18n:
-    generated_at: "2026-05-02T05:53:42Z"
+    generated_at: "2026-05-04T18:24:31Z"
    model: gpt-5.5
    provider: openai
-    source_hash: be5fa531e603fb6d87f84e3193ebd61be1431b57b8f284871ae15f34ca93fc69
+    source_hash: 8187e7d4cfb9d6fb19bbdebfbaea0bb4d98fa5cea4742d0f82a765ae5bc60127
    source_path: plugins/sdk-overview.md
    workflow: 16
 ---

-O SDK de plugins é o contrato tipado entre plugins e o core. Esta página é a
+O SDK de plugins é o contrato tipado entre plugins e o núcleo. Esta página é a
 referência para **o que importar** e **o que você pode registrar**.

 <Note>
-  Esta página é para autores de plugins que usam `openclaw/plugin-sdk/*` dentro
-  do OpenClaw. Para apps externos, scripts, dashboards, tarefas de CI e extensões
-  de IDE que querem executar agentes por meio do Gateway, use o
-  [SDK de Apps OpenClaw](/pt-BR/concepts/openclaw-sdk) e o pacote `@openclaw/sdk`
+  Esta página é para autores de plugins que usam `openclaw/plugin-sdk/*` dentro do
+  OpenClaw. Para apps externos, scripts, dashboards, jobs de CI e extensões de IDE
+  que querem executar agentes por meio do Gateway, use o
+  [SDK de apps do OpenClaw](/pt-BR/concepts/openclaw-sdk) e o pacote `@openclaw/sdk`
  em vez disso.
 </Note>

 <Tip>
-Procurando um guia prático? Comece com [Criação de plugins](/pt-BR/plugins/building-plugins), use [Plugins de canal](/pt-BR/plugins/sdk-channel-plugins) para plugins de canal, [Plugins de provedor](/pt-BR/plugins/sdk-provider-plugins) para plugins de provedor e [Hooks de plugin](/pt-BR/plugins/hooks) para plugins de ferramentas ou hooks de ciclo de vida.
+Procurando um guia prático? Comece com [Criando plugins](/pt-BR/plugins/building-plugins), use [Plugins de canal](/pt-BR/plugins/sdk-channel-plugins) para plugins de canal, [Plugins de provedor](/pt-BR/plugins/sdk-provider-plugins) para plugins de provedor e [hooks de Plugin](/pt-BR/plugins/hooks) para plugins de ferramenta ou hook de ciclo de vida.
 </Tip>

 ## Convenção de importação
@ -39,45 +39,46 @@ import { definePluginEntry } from "openclaw/plugin-sdk/plugin-entry";
 import { defineChannelPluginEntry } from "openclaw/plugin-sdk/channel-core";
 ```

-Cada subcaminho é um módulo pequeno e autocontido. Isso mantém a inicialização rápida e
-previne problemas de dependência circular. Para helpers de entrada/build específicos de canal,
+Cada subcaminho é um módulo pequeno e autossuficiente. Isso mantém a inicialização rápida e
+evita problemas de dependência circular. Para auxiliares de entrada/build específicos de canal,
 prefira `openclaw/plugin-sdk/channel-core`; mantenha `openclaw/plugin-sdk/core` para
-a superfície guarda-chuva mais ampla e helpers compartilhados, como
+a superfície abrangente mais ampla e auxiliares compartilhados, como
 `buildChannelConfigSchema`.

 Para configuração de canal, publique o JSON Schema pertencente ao canal por meio de
 `openclaw.plugin.json#channelConfigs`. O subcaminho `plugin-sdk/channel-config-schema`
 é para primitivas de esquema compartilhadas e o builder genérico. Os plugins
-incluídos no OpenClaw usam `plugin-sdk/bundled-channel-config-schema` para esquemas
-retidos de canais incluídos. Exports de compatibilidade obsoletos permanecem em
-`plugin-sdk/channel-config-schema-legacy`; nenhum subcaminho de esquema incluído é um
+incluídos do OpenClaw usam `plugin-sdk/bundled-channel-config-schema` para esquemas
+de canais incluídos preservados. Exportações de compatibilidade obsoletas permanecem em
+`plugin-sdk/channel-config-schema-legacy`; nenhum dos subcaminhos de esquema incluído é um
 padrão para novos plugins.

 <Warning>
-  Não importe seams de conveniência com marca de provedor ou canal (por exemplo
+  Não importe costuras de conveniência com marca de provedor ou canal (por exemplo,
  `openclaw/plugin-sdk/slack`, `.../discord`, `.../signal`, `.../whatsapp`).
  Plugins incluídos compõem subcaminhos genéricos do SDK dentro de seus próprios barrels
-  `api.ts` / `runtime-api.ts`; consumidores do core devem usar esses barrels locais do plugin
+  `api.ts` / `runtime-api.ts`; consumidores do núcleo devem usar esses barrels locais do plugin
  ou adicionar um contrato genérico estreito do SDK quando uma necessidade for realmente
  entre canais.

-Um pequeno conjunto de seams helper de plugins incluídos ainda aparece no mapa de exportação
-gerado quando há uso rastreado pelo proprietário. Eles existem apenas para manutenção de
-plugins incluídos e não são caminhos de importação recomendados para novos plugins de terceiros.
+Um pequeno conjunto de costuras auxiliares de plugins incluídos ainda aparece no mapa de exportação
+gerado quando há uso de proprietário rastreado. Elas existem apenas para manutenção de plugins incluídos
+e não são caminhos de importação recomendados para novos plugins de terceiros.

 `openclaw/plugin-sdk/discord` e `openclaw/plugin-sdk/telegram-account` também são
-mantidos como facades de compatibilidade obsoletas para uso rastreado pelo proprietário. Não
-copie esses caminhos de importação para novos plugins; use helpers de runtime injetados e
+mantidos como fachadas de compatibilidade obsoletas para uso de proprietário rastreado. Não
+copie esses caminhos de importação para novos plugins; use auxiliares de runtime injetados e
 subcaminhos genéricos do SDK de canal em vez disso.
 </Warning>

 ## Referência de subcaminhos

 O SDK de plugins é exposto como um conjunto de subcaminhos estreitos agrupados por área (entrada de plugin,
-canal, provedor, autenticação, runtime, capacidade, memória e helpers reservados de plugins incluídos). Para o catálogo completo — agrupado e vinculado — consulte
+canal, provedor, autenticação, runtime, capacidade, memória e auxiliares reservados de
+plugins incluídos). Para o catálogo completo, agrupado e com links, consulte
 [Subcaminhos do SDK de plugins](/pt-BR/plugins/sdk-subpaths).

-A lista gerada de mais de 200 subcaminhos fica em `scripts/lib/plugin-sdk-entrypoints.json`.
+A lista gerada com mais de 200 subcaminhos fica em `scripts/lib/plugin-sdk-entrypoints.json`.

 ## API de registro

@ -86,114 +87,117 @@ métodos:

 ### Registro de capacidades

-| Método                                           | O que registra                         |
+| Método                                           | O que ele registra                    |
 | ------------------------------------------------ | ------------------------------------- |
-| `api.registerProvider(...)`                      | Inferência de texto (LLM)              |
+| `api.registerProvider(...)`                      | Inferência de texto (LLM)             |
 | `api.registerAgentHarness(...)`                  | Executor experimental de agente de baixo nível |
-| `api.registerCliBackend(...)`                    | Backend local de inferência da CLI     |
-| `api.registerChannel(...)`                       | Canal de mensagens                     |
-| `api.registerSpeechProvider(...)`                | Texto para fala / síntese STT          |
+| `api.registerCliBackend(...)`                    | Backend local de inferência da CLI    |
+| `api.registerChannel(...)`                       | Canal de mensagens                    |
+| `api.registerSpeechProvider(...)`                | Síntese de texto para fala / STT      |
 | `api.registerRealtimeTranscriptionProvider(...)` | Transcrição em tempo real por streaming |
-| `api.registerRealtimeVoiceProvider(...)`         | Sessões de voz em tempo real duplex    |
-| `api.registerMediaUnderstandingProvider(...)`    | Análise de imagem/áudio/vídeo          |
-| `api.registerImageGenerationProvider(...)`       | Geração de imagens                     |
-| `api.registerMusicGenerationProvider(...)`       | Geração de música                      |
-| `api.registerVideoGenerationProvider(...)`       | Geração de vídeo                       |
-| `api.registerWebFetchProvider(...)`              | Provedor de busca/coleta na web        |
-| `api.registerWebSearchProvider(...)`             | Pesquisa na web                        |
+| `api.registerRealtimeVoiceProvider(...)`         | Sessões de voz em tempo real duplex   |
+| `api.registerMediaUnderstandingProvider(...)`    | Análise de imagem/áudio/vídeo         |
+| `api.registerImageGenerationProvider(...)`       | Geração de imagem                     |
+| `api.registerMusicGenerationProvider(...)`       | Geração de música                     |
+| `api.registerVideoGenerationProvider(...)`       | Geração de vídeo                      |
+| `api.registerWebFetchProvider(...)`              | Provedor de busca/coleta da Web       |
+| `api.registerWebSearchProvider(...)`             | Busca na Web                          |

 ### Ferramentas e comandos

-| Método                          | O que registra                                 |
-| ------------------------------- | --------------------------------------------- |
+| Método                          | O que ele registra                             |
+| ------------------------------- | ---------------------------------------------- |
 | `api.registerTool(tool, opts?)` | Ferramenta de agente (obrigatória ou `{ optional: true }`) |
 | `api.registerCommand(def)`      | Comando personalizado (ignora o LLM)           |

-Comandos de plugin podem definir `agentPromptGuidance` quando o agente precisa de uma dica curta
-de roteamento pertencente ao comando. Mantenha esse texto sobre o próprio comando; não adicione
-política específica de provedor ou plugin aos builders de prompt do core.
+Comandos de plugin podem definir `agentPromptGuidance` quando o agente precisa de uma dica curta,
+pertencente ao comando, para roteamento. Mantenha esse texto sobre o próprio comando; não adicione
+política específica de provedor ou plugin aos builders de prompts do núcleo.

 ### Infraestrutura

-| Método                                         | O que registra                         |
-| ---------------------------------------------- | --------------------------------------- |
-| `api.registerHook(events, handler, opts?)`     | Hook de evento                          |
-| `api.registerHttpRoute(params)`                | Endpoint HTTP do Gateway                |
-| `api.registerGatewayMethod(name, handler)`     | Método RPC do Gateway                   |
-| `api.registerGatewayDiscoveryService(service)` | Anunciante local de descoberta do Gateway |
-| `api.registerCli(registrar, opts?)`            | Subcomando da CLI                       |
-| `api.registerService(service)`                 | Serviço em segundo plano                |
-| `api.registerInteractiveHandler(registration)` | Handler interativo                      |
-| `api.registerAgentToolResultMiddleware(...)`   | Middleware de resultado de ferramenta em runtime |
-| `api.registerMemoryPromptSupplement(builder)`  | Seção aditiva de prompt adjacente à memória |
-| `api.registerMemoryCorpusSupplement(adapter)`  | Corpus aditivo de pesquisa/leitura de memória |
+| Método                                         | O que ele registra                       |
+| ---------------------------------------------- | ---------------------------------------- |
+| `api.registerHook(events, handler, opts?)`     | Hook de evento                           |
+| `api.registerHttpRoute(params)`                | Endpoint HTTP do Gateway                 |
+| `api.registerGatewayMethod(name, handler)`     | Método RPC do Gateway                    |
+| `api.registerGatewayDiscoveryService(service)` | Anunciante de descoberta local do Gateway |
+| `api.registerCli(registrar, opts?)`            | Subcomando da CLI                        |
+| `api.registerService(service)`                 | Serviço em segundo plano                 |
+| `api.registerInteractiveHandler(registration)` | Manipulador interativo                   |
+| `api.registerAgentToolResultMiddleware(...)`   | Middleware de runtime de resultado de ferramenta |
+| `api.registerMemoryPromptSupplement(builder)`  | Seção de prompt aditiva adjacente à memória |
+| `api.registerMemoryCorpusSupplement(adapter)`  | Corpus aditivo de busca/leitura de memória |

 ### Hooks de host para plugins de workflow

-Hooks de host são os seams do SDK para plugins que precisam participar do ciclo de vida do host,
+Hooks de host são as costuras do SDK para plugins que precisam participar do ciclo de vida do host
 em vez de apenas adicionar um provedor, canal ou ferramenta. Eles são contratos
-genéricos; o Modo Planejamento pode usá-los, mas fluxos de aprovação,
+genéricos; o Modo de Planejamento pode usá-los, mas workflows de aprovação,
 gates de política de workspace, monitores em segundo plano, assistentes de configuração e plugins
 companheiros de UI também podem.

-| Método                                                                   | Contrato que ele possui                                                                                                            |
+| Método                                                                   | Contrato que ele possui                                                                                                           |
 | ------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------- |
-| `api.registerSessionExtension(...)`                                      | Estado de sessão pertencente ao plugin, compatível com JSON, projetado por meio de sessões do Gateway                              |
-| `api.enqueueNextTurnInjection(...)`                                      | Contexto durável exatamente uma vez injetado no próximo turno do agente para uma sessão                                            |
-| `api.registerTrustedToolPolicy(...)`                                     | Política de ferramenta pré-plugin incluída/confiável que pode bloquear ou reescrever parâmetros de ferramenta                       |
-| `api.registerToolMetadata(...)`                                          | Metadados de exibição do catálogo de ferramentas sem alterar a implementação da ferramenta                                          |
-| `api.registerCommand(...)`                                               | Comandos de plugin com escopo; resultados de comando podem definir `continueAgent: true`; comandos nativos do Discord suportam `descriptionLocalizations` |
-| `api.registerControlUiDescriptor(...)`                                   | Descritores de contribuição da Control UI para superfícies de sessão, ferramenta, execução ou configurações                         |
-| `api.registerRuntimeLifecycle(...)`                                      | Callbacks de limpeza para recursos de runtime pertencentes ao plugin em caminhos de reset/exclusão/recarregamento                   |
-| `api.registerAgentEventSubscription(...)`                                | Assinaturas de eventos sanitizadas para estado de workflow e monitores                                                              |
-| `api.setRunContext(...)` / `getRunContext(...)` / `clearRunContext(...)` | Estado temporário por execução do plugin limpo no ciclo de vida terminal da execução                                                |
-| `api.registerSessionSchedulerJob(...)`                                   | Registros de tarefas do agendador de sessão pertencentes ao plugin com limpeza determinística                                       |
+| `api.registerSessionExtension(...)`                                      | Estado de sessão pertencente ao plugin, compatível com JSON, projetado por meio de sessões do Gateway                            |
+| `api.enqueueNextTurnInjection(...)`                                      | Contexto durável exatamente uma vez injetado no próximo turno do agente para uma sessão                                           |
+| `api.registerTrustedToolPolicy(...)`                                     | Política de ferramenta pré-plugin, incluída/confiável, que pode bloquear ou reescrever parâmetros de ferramenta                  |
+| `api.registerToolMetadata(...)`                                          | Metadados de exibição do catálogo de ferramentas sem alterar a implementação da ferramenta                                       |
+| `api.registerCommand(...)`                                               | Comandos de plugin com escopo; resultados de comandos podem definir `continueAgent: true`; comandos nativos do Discord aceitam `descriptionLocalizations` |
+| `api.registerControlUiDescriptor(...)`                                   | Descritores de contribuição da UI de controle para superfícies de sessão, ferramenta, execução ou configurações                  |
+| `api.registerRuntimeLifecycle(...)`                                      | Callbacks de limpeza para recursos de runtime pertencentes ao plugin em caminhos de redefinição/exclusão/recarregamento         |
+| `api.registerAgentEventSubscription(...)`                                | Assinaturas de eventos sanitizadas para estado de workflow e monitores                                                           |
+| `api.setRunContext(...)` / `getRunContext(...)` / `clearRunContext(...)` | Estado temporário de plugin por execução limpo no ciclo de vida terminal da execução                                             |
+| `api.registerSessionSchedulerJob(...)`                                   | Registros de jobs do agendador de sessão pertencentes ao plugin com limpeza determinística                                       |

-Os contratos dividem autoridade intencionalmente:
+Os contratos dividem autoridade de propósito:

- Plugins externos podem possuir extensões de sessão, descritores de UI, comandos, metadados de ferramenta, injeções de próximo turno e hooks normais.
- Políticas de ferramentas confiáveis são executadas antes de hooks `before_tool_call` comuns e são apenas para plugins incluídos porque participam da política de segurança do host.
- Propriedade de comandos reservados é apenas para plugins incluídos. Plugins externos devem usar seus próprios nomes de comando ou aliases.
- `allowPromptInjection=false` desativa hooks que alteram prompts, incluindo
+- Plugins externos podem possuir extensões de sessão, descritores de UI, comandos, metadados de ferramenta,
+  injeções do próximo turno e hooks normais.
+- Políticas de ferramenta confiáveis rodam antes de hooks comuns `before_tool_call` e são
+  apenas para incluídos porque participam da política de segurança do host.
+- A propriedade reservada de comandos é apenas para incluídos. Plugins externos devem usar seus
+  próprios nomes de comando ou aliases.
+- `allowPromptInjection=false` desativa hooks que modificam prompts, incluindo
  `agent_turn_prepare`, `before_prompt_build`, `heartbeat_prompt_contribution`,
  campos de prompt do `before_agent_start` legado e
  `enqueueNextTurnInjection`.

-Exemplos de consumidores que não são do Plano:
+Exemplos de consumidores que não são de Planejamento:

-| Arquétipo de plugin          | Hooks usados                                                                                                                           |
-| ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
-| Workflow de aprovação        | Extensão de sessão, continuação de comando, injeção de próximo turno, descritor de UI                                                   |
-| Gate de política de orçamento/workspace | Política de ferramenta confiável, metadados de ferramenta, projeção de sessão                                               |
-| Monitor de ciclo de vida em segundo plano | Limpeza de ciclo de vida de runtime, assinatura de eventos do agente, propriedade/limpeza do agendador de sessão, contribuição de prompt de Heartbeat, descritor de UI |
-| Assistente de configuração ou onboarding | Extensão de sessão, comandos com escopo, descritor da Control UI                                                            |
+| Arquétipo de plugin            | Hooks usados                                                                                                                        |
+| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------- |
+| Workflow de aprovação          | Extensão de sessão, continuação de comando, injeção do próximo turno, descritor de UI                                               |
+| Gate de política de orçamento/workspace | Política de ferramenta confiável, metadados de ferramenta, projeção de sessão                                             |
+| Monitor de ciclo de vida em segundo plano | Limpeza de ciclo de vida de runtime, assinatura de eventos do agente, propriedade/limpeza do agendador de sessão, contribuição de prompt de heartbeat, descritor de UI |
+| Assistente de configuração ou onboarding | Extensão de sessão, comandos com escopo, descritor da UI de controle                                                       |

 <Note>
-  Namespaces reservados de administração do core (`config.*`, `exec.approvals.*`, `wizard.*`,
+  Namespaces reservados de administração do núcleo (`config.*`, `exec.approvals.*`, `wizard.*`,
  `update.*`) sempre permanecem `operator.admin`, mesmo se um plugin tentar atribuir um
-  escopo de método Gateway mais estreito. Prefira prefixos específicos do plugin para
+  escopo de método de gateway mais estreito. Prefira prefixos específicos do plugin para
  métodos pertencentes ao plugin.
 </Note>

 <Accordion title="Quando usar middleware de resultado de ferramenta">
  Plugins incluídos podem usar `api.registerAgentToolResultMiddleware(...)` quando
  precisam reescrever um resultado de ferramenta após a execução e antes que o runtime
-  alimente esse resultado de volta ao modelo. Este é o seam confiável e neutro de runtime
-  para redutores de saída assíncronos, como tokenjuice.
+  alimente esse resultado de volta ao modelo. Esta é a costura confiável, neutra em relação ao runtime,
+  para redutores de saída assíncronos como tokenjuice.

 Plugins incluídos devem declarar `contracts.agentToolResultMiddleware` para cada
 runtime direcionado, por exemplo `["pi", "codex"]`. Plugins externos
-não podem registrar este middleware; mantenha hooks normais de plugin do OpenClaw para trabalho
-que não precise de timing de resultado de ferramenta antes do modelo. O antigo caminho de registro
-de factory de extensão embutida apenas para Pi foi removido.
+não podem registrar este middleware; mantenha hooks normais de plugin do OpenClaw para trabalhos
+que não precisam de temporização de resultado de ferramenta antes do modelo. O antigo caminho de registro
+de factory de extensão embutida exclusivo do Pi foi removido.
 </Accordion>

 ### Registro de descoberta do Gateway

-`api.registerGatewayDiscoveryService(...)` permite que um plugin anuncie o Gateway ativo
+`api.registerGatewayDiscoveryService(...)` permite que um Plugin anuncie o Gateway ativo
 em um transporte de descoberta local, como mDNS/Bonjour. O OpenClaw chama o
-serviço durante a inicialização do Gateway quando a descoberta local está ativada, passa as
-portas atuais do Gateway e dados de dica TXT não secretos, e chama o manipulador
+serviço durante a inicialização do Gateway quando a descoberta local está habilitada, passa as
+portas atuais do Gateway e dados de dica TXT que não são secretos, e chama o manipulador
 `stop` retornado durante o desligamento do Gateway.

 ```typescript
@ -211,7 +215,7 @@ api.registerGatewayDiscoveryService({
 ```

 Plugins de descoberta do Gateway não devem tratar valores TXT anunciados como segredos ou
-autenticação. Descoberta é uma dica de roteamento; a autenticação do Gateway e o pinning de TLS ainda
+autenticação. A descoberta é uma dica de roteamento; a autenticação do Gateway e a fixação de TLS ainda
 controlam a confiança.

 ### Metadados de registro da CLI
@ -220,9 +224,9 @@ controlam a confiança.

 - `commands`: raízes de comando explícitas pertencentes ao registrador
 - `descriptors`: descritores de comando em tempo de análise usados para a ajuda da CLI raiz,
-  roteamento e registro lazy da CLI do plugin
+  roteamento e registro preguiçoso da CLI do Plugin

-Se você quiser que um comando de plugin permaneça carregado de forma lazy no caminho normal da CLI raiz,
+Se você quiser que um comando de Plugin permaneça carregado preguiçosamente no caminho normal da CLI raiz,
 forneça `descriptors` que cubram cada raiz de comando de nível superior exposta por esse
 registrador.

@ -244,98 +248,100 @@ api.registerCli(
 );
 ```

-Use `commands` sozinho apenas quando não precisar de registro lazy da CLI raiz.
-Esse caminho de compatibilidade eager continua sendo compatível, mas não instala
-placeholders baseados em descritores para carregamento lazy em tempo de análise.
+Use `commands` sozinho apenas quando você não precisar do registro preguiçoso da CLI raiz.
+Esse caminho de compatibilidade ansioso continua compatível, mas não instala
+marcadores de posição baseados em descritores para carregamento preguiçoso em tempo de análise.

 ### Registro de backend da CLI

-`api.registerCliBackend(...)` permite que um plugin controle a configuração padrão de um backend local
-de CLI de IA, como `codex-cli`.
+`api.registerCliBackend(...)` permite que um Plugin controle a configuração padrão de um backend local de
+CLI de IA, como `codex-cli`.

 - O `id` do backend se torna o prefixo do provedor em referências de modelo como `codex-cli/gpt-5`.
- A `config` do backend usa o mesmo formato que `agents.defaults.cliBackends.<id>`.
+- A `config` do backend usa o mesmo formato de `agents.defaults.cliBackends.<id>`.
 - A configuração do usuário ainda prevalece. O OpenClaw mescla `agents.defaults.cliBackends.<id>` sobre o
-  padrão do plugin antes de executar a CLI.
+  padrão do Plugin antes de executar a CLI.
 - Use `normalizeConfig` quando um backend precisar de reescritas de compatibilidade após a mesclagem
  (por exemplo, normalizar formatos antigos de flags).
+- Use `resolveExecutionArgs` para reescritas de argv com escopo de requisição que pertencem ao
+  dialeto da CLI, como mapear níveis de pensamento do OpenClaw para uma flag de esforço nativa.

 ### Slots exclusivos

-| Método                                     | O que registra                                                                                                                                         |
+| Método                                     | O que ele registra                                                                                                                                         |
 | ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `api.registerContextEngine(id, factory)`   | Engine de contexto (um ativo por vez). O callback `assemble()` recebe `availableTools` e `citationsMode` para que o engine possa personalizar acréscimos ao prompt. |
+| `api.registerContextEngine(id, factory)`   | Mecanismo de contexto (um ativo por vez). O callback `assemble()` recebe `availableTools` e `citationsMode` para que o mecanismo possa personalizar acréscimos ao prompt. |
 | `api.registerMemoryCapability(capability)` | Capacidade de memória unificada                                                                                                                                 |
-| `api.registerMemoryPromptSection(builder)` | Builder de seção de prompt de memória                                                                                                                             |
-| `api.registerMemoryFlushPlan(resolver)`    | Resolvedor de plano de flush de memória                                                                                                                                |
+| `api.registerMemoryPromptSection(builder)` | Construtor de seção de prompt de memória                                                                                                                             |
+| `api.registerMemoryFlushPlan(resolver)`    | Resolvedor de plano de descarregamento de memória                                                                                                                                |
 | `api.registerMemoryRuntime(runtime)`       | Adaptador de runtime de memória                                                                                                                                    |

 ### Adaptadores de embedding de memória

-| Método                                         | O que registra                              |
+| Método                                         | O que ele registra                              |
 | ---------------------------------------------- | ---------------------------------------------- |
-| `api.registerMemoryEmbeddingProvider(adapter)` | Adaptador de embedding de memória para o plugin ativo |
+| `api.registerMemoryEmbeddingProvider(adapter)` | Adaptador de embedding de memória para o Plugin ativo |

- `registerMemoryCapability` é a API exclusiva preferida para plugin de memória.
+- `registerMemoryCapability` é a API exclusiva preferida de Plugin de memória.
 - `registerMemoryCapability` também pode expor `publicArtifacts.listArtifacts(...)`
-  para que plugins companheiros possam consumir artefatos de memória exportados por meio de
-  `openclaw/plugin-sdk/memory-host-core`, em vez de acessar o layout privado de um
-  plugin de memória específico.
+  para que Plugins complementares possam consumir artefatos de memória exportados por meio de
+  `openclaw/plugin-sdk/memory-host-core` em vez de acessar o layout privado de um
+  Plugin de memória específico.
 - `registerMemoryPromptSection`, `registerMemoryFlushPlan` e
-  `registerMemoryRuntime` são APIs exclusivas de plugin de memória compatíveis com legado.
- `MemoryFlushPlan.model` pode fixar o turno de flush em uma referência exata de `provider/model`,
-  como `ollama/qwen3:8b`, sem herdar a cadeia de fallback ativa.
- `registerMemoryEmbeddingProvider` permite que o plugin de memória ativo registre um
-  ou mais ids de adaptador de embedding (por exemplo `openai`, `gemini` ou um id personalizado
-  definido pelo plugin).
+  `registerMemoryRuntime` são APIs exclusivas de Plugin de memória compatíveis com legado.
+- `MemoryFlushPlan.model` pode fixar o turno de descarregamento em uma referência exata de
+  `provider/model`, como `ollama/qwen3:8b`, sem herdar a cadeia de fallback ativa.
+- `registerMemoryEmbeddingProvider` permite que o Plugin de memória ativo registre um
+  ou mais ids de adaptador de embedding (por exemplo, `openai`, `gemini` ou um id personalizado
+  definido pelo Plugin).
 - Configurações do usuário como `agents.defaults.memorySearch.provider` e
  `agents.defaults.memorySearch.fallback` são resolvidas contra esses ids de adaptador
  registrados.

 ### Eventos e ciclo de vida

-| Método                                       | O que faz                  |
+| Método                                       | O que ele faz                  |
 | -------------------------------------------- | ----------------------------- |
-| `api.on(hookName, handler, opts?)`           | Hook tipado de ciclo de vida          |
-| `api.onConversationBindingResolved(handler)` | Callback de vinculação de conversa |
+| `api.on(hookName, handler, opts?)`           | Hook de ciclo de vida tipado          |
+| `api.onConversationBindingResolved(handler)` | Callback de vínculo de conversa |

 Veja [hooks de Plugin](/pt-BR/plugins/hooks) para exemplos, nomes comuns de hooks e
-semântica de guard.
+semântica de proteções.

 ### Semântica de decisão de hooks

- `before_tool_call`: retornar `{ block: true }` é terminal. Depois que qualquer manipulador o define, manipuladores de prioridade mais baixa são ignorados.
- `before_tool_call`: retornar `{ block: false }` é tratado como nenhuma decisão (igual a omitir `block`), não como uma sobrescrita.
- `before_install`: retornar `{ block: true }` é terminal. Depois que qualquer manipulador o define, manipuladores de prioridade mais baixa são ignorados.
- `before_install`: retornar `{ block: false }` é tratado como nenhuma decisão (igual a omitir `block`), não como uma sobrescrita.
- `reply_dispatch`: retornar `{ handled: true, ... }` é terminal. Depois que qualquer manipulador reivindica o despacho, manipuladores de prioridade mais baixa e o caminho padrão de despacho do modelo são ignorados.
- `message_sending`: retornar `{ cancel: true }` é terminal. Depois que qualquer manipulador o define, manipuladores de prioridade mais baixa são ignorados.
- `message_sending`: retornar `{ cancel: false }` é tratado como nenhuma decisão (igual a omitir `cancel`), não como uma sobrescrita.
- `message_received`: use o campo tipado `threadId` quando precisar de roteamento de tópico/thread de entrada. Mantenha `metadata` para extras específicos do canal.
+- `before_tool_call`: retornar `{ block: true }` é terminal. Depois que qualquer manipulador o define, manipuladores de menor prioridade são ignorados.
+- `before_tool_call`: retornar `{ block: false }` é tratado como ausência de decisão (igual a omitir `block`), não como uma substituição.
+- `before_install`: retornar `{ block: true }` é terminal. Depois que qualquer manipulador o define, manipuladores de menor prioridade são ignorados.
+- `before_install`: retornar `{ block: false }` é tratado como ausência de decisão (igual a omitir `block`), não como uma substituição.
+- `reply_dispatch`: retornar `{ handled: true, ... }` é terminal. Depois que qualquer manipulador reivindica o envio, manipuladores de menor prioridade e o caminho padrão de envio do modelo são ignorados.
+- `message_sending`: retornar `{ cancel: true }` é terminal. Depois que qualquer manipulador o define, manipuladores de menor prioridade são ignorados.
+- `message_sending`: retornar `{ cancel: false }` é tratado como ausência de decisão (igual a omitir `cancel`), não como uma substituição.
+- `message_received`: use o campo tipado `threadId` quando precisar de roteamento de thread/tópico de entrada. Mantenha `metadata` para extras específicos do canal.
 - `message_sending`: use os campos de roteamento tipados `replyToId` / `threadId` antes de recorrer a `metadata` específico do canal.
- `gateway_start`: use `ctx.config`, `ctx.workspaceDir` e `ctx.getCron?.()` para o estado de inicialização pertencente ao gateway, em vez de depender de hooks internos `gateway:startup`.
- `cron_changed`: observe mudanças no ciclo de vida do cron pertencentes ao gateway. Use `event.job?.state?.nextRunAtMs` e `ctx.getCron?.()` ao sincronizar agendadores externos de ativação, e mantenha o OpenClaw como fonte da verdade para verificações de vencimento e execução.
+- `gateway_start`: use `ctx.config`, `ctx.workspaceDir` e `ctx.getCron?.()` para o estado de inicialização pertencente ao Gateway, em vez de depender de hooks internos `gateway:startup`.
+- `cron_changed`: observe mudanças no ciclo de vida de Cron pertencente ao Gateway. Use `event.job?.state?.nextRunAtMs` e `ctx.getCron?.()` ao sincronizar agendadores de despertar externos, e mantenha o OpenClaw como a fonte da verdade para verificações de vencimento e execução.

 ### Campos do objeto da API

 | Campo                    | Tipo                      | Descrição                                                                                 |
 | ------------------------ | ------------------------- | ------------------------------------------------------------------------------------------- |
-| `api.id`                 | `string`                  | Id do plugin                                                                                   |
+| `api.id`                 | `string`                  | Id do Plugin                                                                                   |
 | `api.name`               | `string`                  | Nome de exibição                                                                                |
-| `api.version`            | `string?`                 | Versão do plugin (opcional)                                                                   |
-| `api.description`        | `string?`                 | Descrição do plugin (opcional)                                                               |
-| `api.source`             | `string`                  | Caminho de origem do plugin                                                                          |
-| `api.rootDir`            | `string?`                 | Diretório raiz do plugin (opcional)                                                            |
-| `api.config`             | `OpenClawConfig`          | Snapshot da configuração atual (snapshot do runtime ativo em memória quando disponível)                  |
-| `api.pluginConfig`       | `Record<string, unknown>` | Configuração específica do plugin de `plugins.entries.<id>.config`                                   |
-| `api.runtime`            | `PluginRuntime`           | [Helpers de runtime](/pt-BR/plugins/sdk-runtime)                                                     |
+| `api.version`            | `string?`                 | Versão do Plugin (opcional)                                                                   |
+| `api.description`        | `string?`                 | Descrição do Plugin (opcional)                                                               |
+| `api.source`             | `string`                  | Caminho de origem do Plugin                                                                          |
+| `api.rootDir`            | `string?`                 | Diretório raiz do Plugin (opcional)                                                            |
+| `api.config`             | `OpenClawConfig`          | Snapshot da configuração atual (snapshot de runtime ativo em memória quando disponível)                  |
+| `api.pluginConfig`       | `Record<string, unknown>` | Configuração específica do Plugin de `plugins.entries.<id>.config`                                   |
+| `api.runtime`            | `PluginRuntime`           | [Ajudantes de runtime](/pt-BR/plugins/sdk-runtime)                                                     |
 | `api.logger`             | `PluginLogger`            | Logger com escopo (`debug`, `info`, `warn`, `error`)                                            |
 | `api.registrationMode`   | `PluginRegistrationMode`  | Modo de carregamento atual; `"setup-runtime"` é a janela leve de inicialização/configuração antes da entrada completa |
-| `api.resolvePath(input)` | `(string) => string`      | Resolve caminho relativo à raiz do plugin                                                        |
+| `api.resolvePath(input)` | `(string) => string`      | Resolve o caminho relativo à raiz do Plugin                                                        |

 ## Convenção de módulo interno

-Dentro do seu plugin, use arquivos barrel locais para imports internos:
+Dentro do seu Plugin, use arquivos barrel locais para importações internas:

 ```
 my-plugin/
@ -346,35 +352,34 @@ my-plugin/
 ```

 <Warning>
-  Nunca importe seu próprio plugin por meio de `openclaw/plugin-sdk/<your-plugin>`
-  a partir de código de produção. Encaminhe imports internos por `./api.ts` ou
+  Nunca importe seu próprio Plugin por meio de `openclaw/plugin-sdk/<your-plugin>`
+  a partir do código de produção. Direcione importações internas por `./api.ts` ou
  `./runtime-api.ts`. O caminho do SDK é apenas o contrato externo.
 </Warning>

-Superfícies públicas de plugins empacotados carregadas por facade (`api.ts`, `runtime-api.ts`,
+Superfícies públicas de Plugins empacotados carregadas por fachada (`api.ts`, `runtime-api.ts`,
 `index.ts`, `setup-entry.ts` e arquivos de entrada públicos semelhantes) preferem o
-snapshot de configuração do runtime ativo quando o OpenClaw já está em execução. Se ainda não existir
+snapshot de configuração de runtime ativo quando o OpenClaw já está em execução. Se ainda não houver
 snapshot de runtime, elas recorrem ao arquivo de configuração resolvido no disco.
-Facades de plugins empacotados devem ser carregadas pelos carregadores de facade de plugin do OpenClaw;
-imports diretos de `dist/extensions/...` ignoram o manifesto
-e as verificações de sidecar de runtime que instalações empacotadas usam para código pertencente ao plugin.
+Fachadas de Plugins empacotados empacotadas devem ser carregadas pelos carregadores de fachada de Plugin do OpenClaw; importações diretas de `dist/extensions/...` ignoram as verificações de manifesto
+e sidecar de runtime que instalações empacotadas usam para código pertencente ao Plugin.

-Plugins de provedor podem expor um barrel de contrato estreito e local ao plugin quando um
-helper é intencionalmente específico do provedor e ainda não pertence a um subcaminho genérico do SDK.
+Plugins de provedor podem expor um barrel de contrato estreito e local ao Plugin quando um
+ajudante é intencionalmente específico do provedor e ainda não pertence a um subcaminho genérico do SDK.
 Exemplos empacotados:

- **Anthropic**: interface pública `api.ts` / `contract-api.ts` para helpers de header beta do Claude
+- **Anthropic**: camada pública `api.ts` / `contract-api.ts` para ajudantes de cabeçalho beta do Claude
  e stream de `service_tier`.
- **`@openclaw/openai-provider`**: `api.ts` exporta builders de provedor,
-  helpers de modelo padrão e builders de provedor em tempo real.
- **`@openclaw/openrouter-provider`**: `api.ts` exporta o builder de provedor
-  mais helpers de onboarding/configuração.
+- **`@openclaw/openai-provider`**: `api.ts` exporta construtores de provedor,
+  ajudantes de modelo padrão e construtores de provedor em tempo real.
+- **`@openclaw/openrouter-provider`**: `api.ts` exporta o construtor de provedor
+  além de ajudantes de onboarding/configuração.

 <Warning>
-  Código de produção de extensões também deve evitar imports de `openclaw/plugin-sdk/<other-plugin>`.
-  Se um helper for realmente compartilhado, promova-o para um subcaminho neutro do SDK,
+  O código de produção de extensões também deve evitar importações de `openclaw/plugin-sdk/<other-plugin>`.
+  Se um ajudante for realmente compartilhado, promova-o para um subcaminho neutro do SDK,
  como `openclaw/plugin-sdk/speech`, `.../provider-model-shared` ou outra
-  superfície orientada a capacidade, em vez de acoplar dois plugins.
+  superfície orientada a capacidade, em vez de acoplar dois Plugins.
 </Warning>

 ## Relacionado
@ -386,7 +391,7 @@ Exemplos empacotados:
  <Card title="Auxiliares de runtime" icon="gears" href="/pt-BR/plugins/sdk-runtime">
    Referência completa do namespace `api.runtime`.
  </Card>
-  <Card title="Configuração e setup" icon="sliders" href="/pt-BR/plugins/sdk-setup">
+  <Card title="Configuração e ajustes" icon="sliders" href="/pt-BR/plugins/sdk-setup">
    Empacotamento, manifestos e esquemas de configuração.
  </Card>
  <Card title="Testes" icon="vial" href="/pt-BR/plugins/sdk-testing">
@ -395,7 +400,7 @@ Exemplos empacotados:
  <Card title="Migração do SDK" icon="arrows-turn-right" href="/pt-BR/plugins/sdk-migration">
    Migração de superfícies obsoletas.
  </Card>
-  <Card title="Detalhes internos do Plugin" icon="diagram-project" href="/pt-BR/plugins/architecture">
-    Arquitetura aprofundada e modelo de capacidades.
+  <Card title="Internos do Plugin" icon="diagram-project" href="/pt-BR/plugins/architecture">
+    Arquitetura detalhada e modelo de capacidades.
  </Card>
 </CardGroup>
--- a/docs/pt-BR/security/network-proxy.md
+++ b/docs/pt-BR/security/network-proxy.md
@ -1,67 +1,67 @@
 ---
 read_when:
-    - Você quer defesa em profundidade contra ataques de SSRF e de revinculação de DNS
-    - Configuração de um proxy direto externo para o tráfego em tempo de execução do OpenClaw
-summary: Como rotear o tráfego HTTP e WebSocket do runtime do OpenClaw por meio de um proxy de filtragem gerenciado pelo operador
+    - Você quer defesa em profundidade contra ataques de SSRF e de reassociação de DNS
+    - Configurar um proxy direto externo para o tráfego de runtime do OpenClaw
+summary: Como rotear o tráfego HTTP e WebSocket do tempo de execução do OpenClaw por meio de um proxy de filtragem gerenciado pelo operador
 title: Proxy de rede
 x-i18n:
-    generated_at: "2026-05-04T05:55:11Z"
+    generated_at: "2026-05-04T18:24:29Z"
    model: gpt-5.5
    provider: openai
-    source_hash: fc7140c5ced0e7454a6f85d1ea8f3256bbd28cc0cb42eeafe8e5e6439b90e3f0
+    source_hash: eedbf3bac14800c34c7ca2e3b6879dac360a88d51b5b7449ddf41a4dd471648b
    source_path: security/network-proxy.md
    workflow: 16
 ---

 # Proxy de Rede

-O OpenClaw pode rotear tráfego HTTP e WebSocket em tempo de execução por meio de um proxy de encaminhamento gerenciado pelo operador. Esta é uma defesa opcional em profundidade para implantações que desejam controle central de saída, proteção SSRF mais forte e melhor auditabilidade de rede.
+O OpenClaw pode rotear tráfego HTTP e WebSocket em tempo de execução por meio de um proxy de encaminhamento gerenciado pelo operador. Esta é uma defesa em profundidade opcional para implantações que desejam controle central de saída, proteção SSRF mais forte e melhor auditabilidade de rede.

-O OpenClaw não fornece, baixa, inicia, configura nem certifica um proxy. Você executa a tecnologia de proxy adequada ao seu ambiente, e o OpenClaw roteia clientes HTTP e WebSocket locais ao processo por meio dela.
+O OpenClaw não fornece, baixa, inicia, configura nem certifica um proxy. Você executa a tecnologia de proxy adequada ao seu ambiente, e o OpenClaw roteia clientes HTTP e WebSocket normais, locais ao processo, por meio dele.

 ## Por Que Usar um Proxy?

-Um proxy dá aos operadores um ponto único de controle de rede para tráfego HTTP e WebSocket de saída. Isso pode ser útil mesmo fora do reforço contra SSRF:
+Um proxy dá aos operadores um único ponto de controle de rede para tráfego HTTP e WebSocket de saída. Isso pode ser útil mesmo fora do endurecimento contra SSRF:

- Política central: mantenha uma única política de saída em vez de depender de cada ponto de chamada HTTP da aplicação para aplicar as regras de rede corretamente.
+- Política central: mantenha uma política de saída em vez de depender de cada ponto de chamada HTTP da aplicação para acertar as regras de rede.
 - Verificações no momento da conexão: avalie o destino após a resolução DNS e imediatamente antes de o proxy abrir a conexão upstream.
- Defesa contra religação DNS: reduza a lacuna entre uma verificação DNS no nível da aplicação e a conexão de saída real.
- Cobertura JavaScript mais ampla: roteie clientes comuns como `fetch`, `node:http`, `node:https`, WebSocket, axios, got, node-fetch e similares pelo mesmo caminho.
+- Defesa contra DNS rebinding: reduza a lacuna entre uma verificação DNS no nível da aplicação e a conexão de saída real.
+- Cobertura JavaScript mais ampla: roteie `fetch`, `node:http`, `node:https`, WebSocket, axios, got, node-fetch e clientes semelhantes comuns pelo mesmo caminho.
 - Auditabilidade: registre destinos permitidos e negados no limite de saída.
- Controle operacional: imponha regras de destino, segmentação de rede, limites de taxa ou listas de permissões de saída sem reconstruir o OpenClaw.
+- Controle operacional: aplique regras de destino, segmentação de rede, limites de taxa ou listas de permissão de saída sem recompilar o OpenClaw.

-O roteamento por proxy é uma proteção no nível do processo para saída HTTP e WebSocket normal. Ele dá aos operadores um caminho que falha fechado para rotear clientes HTTP JavaScript compatíveis por meio de seu próprio proxy de filtragem, mas não é uma sandbox de rede no nível do sistema operacional e não faz o OpenClaw certificar a política de destino do proxy.
+O roteamento por proxy é uma barreira de proteção em nível de processo para saída HTTP e WebSocket normal. Ele oferece aos operadores um caminho que falha fechado para rotear clientes HTTP JavaScript compatíveis por meio de seu próprio proxy de filtragem, mas não é uma sandbox de rede em nível de SO e não faz o OpenClaw certificar a política de destino do proxy.

-## Como o OpenClaw Roteia Tráfego
+## Como o OpenClaw Roteia o Tráfego

-Quando `proxy.enabled=true` e uma URL de proxy está configurada, processos protegidos em tempo de execução, como `openclaw gateway run`, `openclaw node run` e `openclaw agent --local`, roteiam a saída HTTP e WebSocket normal pelo proxy configurado:
+Quando `proxy.enabled=true` e uma URL de proxy está configurada, processos de tempo de execução protegidos, como `openclaw gateway run`, `openclaw node run` e `openclaw agent --local`, roteiam saída HTTP e WebSocket normal pelo proxy configurado:

 ```text
-OpenClaw process
-  fetch                  -> operator-managed filtering proxy -> public internet
-  node:http and https    -> operator-managed filtering proxy -> public internet
-  WebSocket clients      -> operator-managed filtering proxy -> public internet
+Processo do OpenClaw
+  fetch                  -> proxy de filtragem gerenciado pelo operador -> internet pública
+  node:http e https      -> proxy de filtragem gerenciado pelo operador -> internet pública
+  Clientes WebSocket     -> proxy de filtragem gerenciado pelo operador -> internet pública
 ```

-O contrato público é o comportamento de roteamento, não os hooks internos do Node usados para implementá-lo. Os clientes WebSocket do plano de controle do OpenClaw Gateway usam um caminho direto restrito para tráfego RPC local loopback do Gateway quando a URL do Gateway usa `localhost` ou um IP literal de loopback, como `127.0.0.1` ou `[::1]`. Esse caminho do plano de controle precisa conseguir alcançar Gateways de loopback mesmo quando o proxy do operador bloqueia destinos de loopback. As solicitações HTTP e WebSocket normais em tempo de execução ainda usam o proxy configurado.
+O contrato público é o comportamento de roteamento, não os ganchos internos do Node usados para implementá-lo. Clientes WebSocket do plano de controle do OpenClaw Gateway usam um caminho direto estreito para tráfego RPC do Gateway em local loopback quando a URL do Gateway usa `localhost` ou um IP de loopback literal, como `127.0.0.1` ou `[::1]`. Esse caminho do plano de controle precisa conseguir alcançar Gateways de loopback mesmo quando o proxy do operador bloqueia destinos de loopback. Requisições HTTP e WebSocket normais em tempo de execução ainda usam o proxy configurado.

-Internamente, o OpenClaw usa dois hooks de roteamento no nível do processo para este recurso:
+Internamente, o OpenClaw usa dois ganchos de roteamento em nível de processo para este recurso:

- O roteamento do dispatcher do Undici cobre `fetch`, clientes baseados em undici e transportes que fornecem seu próprio dispatcher do undici.
- O roteamento do `global-agent` cobre chamadores do núcleo do Node `node:http` e `node:https`, incluindo muitas bibliotecas em camadas sobre `http.request`, `https.request`, `http.get` e `https.get`. O modo de proxy gerenciado força esse agente global para que agentes HTTP explícitos do Node não contornem acidentalmente o proxy do operador.
+- O roteamento de dispatcher do Undici cobre `fetch`, clientes baseados em undici e transportes que fornecem seu próprio dispatcher undici.
+- O roteamento de `global-agent` cobre chamadores do núcleo do Node `node:http` e `node:https`, incluindo muitas bibliotecas sobrepostas a `http.request`, `https.request`, `http.get` e `https.get`. O modo de proxy gerenciado força esse agente global para que agentes HTTP explícitos do Node não ignorem acidentalmente o proxy do operador.

-Alguns plugins possuem transportes personalizados que precisam de configuração explícita de proxy mesmo quando existe roteamento no nível do processo. Por exemplo, o transporte da Bot API do Telegram usa seu próprio dispatcher HTTP/1 do undici e, portanto, respeita o ambiente de proxy do processo mais o fallback gerenciado `OPENCLAW_PROXY_URL` nesse caminho de transporte específico do proprietário.
+Alguns plugins possuem transportes personalizados que precisam de configuração explícita de proxy mesmo quando existe roteamento em nível de processo. Por exemplo, o transporte da Bot API do Telegram usa seu próprio dispatcher undici HTTP/1 e, portanto, respeita o ambiente de proxy do processo mais o fallback gerenciado `OPENCLAW_PROXY_URL` nesse caminho de transporte específico do proprietário.

 A própria URL do proxy deve usar `http://`. Destinos HTTPS ainda são compatíveis por meio do proxy com HTTP `CONNECT`; isso significa apenas que o OpenClaw espera um listener de proxy de encaminhamento HTTP simples, como `http://127.0.0.1:3128`.

-Enquanto o proxy está ativo, o OpenClaw limpa `no_proxy`, `NO_PROXY` e `GLOBAL_AGENT_NO_PROXY`. Essas listas de desvio são baseadas em destino, portanto deixar `localhost` ou `127.0.0.1` nelas permitiria que alvos SSRF de alto risco pulassem o proxy de filtragem.
+Enquanto o proxy está ativo, o OpenClaw limpa `no_proxy`, `NO_PROXY` e `GLOBAL_AGENT_NO_PROXY`. Essas listas de bypass são baseadas em destino, então deixar `localhost` ou `127.0.0.1` nelas permitiria que alvos SSRF de alto risco ignorassem o proxy de filtragem.

-No encerramento, o OpenClaw restaura o ambiente de proxy anterior e redefine o estado de roteamento de processo em cache.
+No desligamento, o OpenClaw restaura o ambiente de proxy anterior e redefine o estado de roteamento em cache do processo.

-## Termos de Proxy Relacionados
+## Termos Relacionados a Proxy

- `proxy.enabled` / `proxy.proxyUrl`: roteamento de proxy de encaminhamento de saída para o tráfego de saída em tempo de execução do OpenClaw. Esta página documenta esse recurso.
- `gateway.auth.mode: "trusted-proxy"`: autenticação de proxy reverso de entrada ciente de identidade para acesso ao Gateway. Consulte [Autenticação de proxy confiável](/pt-BR/gateway/trusted-proxy-auth).
+- `proxy.enabled` / `proxy.proxyUrl`: roteamento de proxy de encaminhamento de saída para a saída em tempo de execução do OpenClaw. Esta página documenta esse recurso.
+- `gateway.auth.mode: "trusted-proxy"`: autenticação de proxy reverso de entrada com reconhecimento de identidade para acesso ao Gateway. Consulte [autenticação de proxy confiável](/pt-BR/gateway/trusted-proxy-auth).
 - `openclaw proxy`: proxy local de depuração e inspetor de captura para desenvolvimento e suporte. Consulte [openclaw proxy](/pt-BR/cli/proxy).
 - Configurações de proxy específicas de canal ou provedor: substituições específicas do proprietário para um transporte específico. Prefira o proxy de rede gerenciado quando o objetivo for controle central de saída em todo o tempo de execução.

@ -81,7 +81,7 @@ OPENCLAW_PROXY_URL=http://127.0.0.1:3128 openclaw gateway run

 `proxy.proxyUrl` tem precedência sobre `OPENCLAW_PROXY_URL`.

-Se `enabled=true`, mas nenhuma URL de proxy válida estiver configurada, os comandos protegidos falham na inicialização em vez de voltar para acesso direto à rede.
+Se `enabled=true`, mas nenhuma URL de proxy válida estiver configurada, os comandos protegidos falharão na inicialização em vez de voltar para acesso direto à rede.

 Para serviços de Gateway gerenciados iniciados com `openclaw gateway start`, prefira armazenar a URL na configuração:

@ -92,9 +92,9 @@ openclaw gateway install --force
 openclaw gateway start
 ```

-O fallback de ambiente é melhor para execuções em primeiro plano. Se você o usar com um serviço instalado, coloque `OPENCLAW_PROXY_URL` no ambiente durável do serviço, como `$OPENCLAW_STATE_DIR/.env` ou `~/.openclaw/.env`, e então reinstale o serviço para que launchd, systemd ou Tarefas Agendadas iniciem o gateway com esse valor.
+O fallback de ambiente é mais adequado para execuções em primeiro plano. Se você usá-lo com um serviço instalado, coloque `OPENCLAW_PROXY_URL` no ambiente durável do serviço, como `$OPENCLAW_STATE_DIR/.env` ou `~/.openclaw/.env`, depois reinstale o serviço para que launchd, systemd ou Tarefas Agendadas iniciem o gateway com esse valor.

-Para comandos `openclaw --container ...`, o OpenClaw encaminha `OPENCLAW_PROXY_URL` para a CLI filha destinada ao contêiner quando ele está definido. A URL precisa ser acessível de dentro do contêiner; `127.0.0.1` se refere ao próprio contêiner, não ao host. O OpenClaw rejeita URLs de proxy de loopback para comandos destinados a contêiner, a menos que você substitua explicitamente essa verificação de segurança.
+Para comandos `openclaw --container ...`, o OpenClaw encaminha `OPENCLAW_PROXY_URL` para a CLI filha destinada ao contêiner quando ele está definido. A URL deve ser acessível de dentro do contêiner; `127.0.0.1` se refere ao próprio contêiner, não ao host. O OpenClaw rejeita URLs de proxy de loopback para comandos destinados a contêiner, a menos que você substitua explicitamente essa verificação de segurança.

 ## Requisitos do Proxy

@ -102,41 +102,41 @@ A política do proxy é o limite de segurança. O OpenClaw não consegue verific

 Configure o proxy para:

- Vincular apenas a loopback ou a uma interface privada confiável.
+- Vincular apenas ao loopback ou a uma interface privada confiável.
 - Restringir o acesso para que apenas o processo, host, contêiner ou conta de serviço do OpenClaw possa usá-lo.
 - Resolver destinos por conta própria e bloquear IPs de destino após a resolução DNS.
- Aplicar política no momento da conexão tanto para solicitações HTTP simples quanto para túneis HTTPS `CONNECT`.
- Rejeitar desvios baseados em destino para faixas de loopback, privadas, link-local, metadados, multicast, reservadas ou de documentação.
- Evitar listas de permissões de hostname, a menos que você confie totalmente no caminho de resolução DNS.
- Registrar destino, decisão, status e motivo sem registrar corpos de solicitação, cabeçalhos de autorização, cookies ou outros segredos.
+- Aplicar a política no momento da conexão tanto para requisições HTTP simples quanto para túneis HTTPS `CONNECT`.
+- Rejeitar bypasses baseados em destino para intervalos de loopback, privados, link-local, metadados, multicast, reservados ou de documentação.
+- Evitar listas de permissão de nomes de host, a menos que você confie totalmente no caminho de resolução DNS.
+- Registrar destino, decisão, status e motivo sem registrar corpos de requisição, cabeçalhos de autorização, cookies ou outros segredos.
 - Manter a política do proxy sob controle de versão e revisar alterações como configuração sensível à segurança.

-## Destinos Recomendados para Bloqueio
+## Destinos Bloqueados Recomendados

 Use esta lista de negação como ponto de partida para qualquer proxy de encaminhamento, firewall ou política de saída.

-A lógica de classificação no nível da aplicação do OpenClaw fica em `src/infra/net/ssrf.ts` e `src/shared/net/ip.ts`. Os hooks de paridade relevantes são `BLOCKED_HOSTNAMES`, `BLOCKED_IPV4_SPECIAL_USE_RANGES`, `BLOCKED_IPV6_SPECIAL_USE_RANGES`, `RFC2544_BENCHMARK_PREFIX` e o tratamento de sentinela IPv4 embutido para NAT64, 6to4, Teredo, ISATAP e formas IPv4 mapeadas. Esses arquivos são referências úteis ao manter uma política de proxy externa, mas o OpenClaw não exporta nem impõe automaticamente essas regras no seu proxy.
+A lógica de classificação em nível de aplicação do OpenClaw vive em `src/infra/net/ssrf.ts` e `src/shared/net/ip.ts`. Os ganchos de paridade relevantes são `BLOCKED_HOSTNAMES`, `BLOCKED_IPV4_SPECIAL_USE_RANGES`, `BLOCKED_IPV6_SPECIAL_USE_RANGES`, `RFC2544_BENCHMARK_PREFIX` e o tratamento de sentinela IPv4 incorporado para NAT64, 6to4, Teredo, ISATAP e formas IPv4 mapeadas. Esses arquivos são referências úteis ao manter uma política de proxy externa, mas o OpenClaw não exporta nem aplica automaticamente essas regras no seu proxy.

-| Faixa ou host                                                                        | Por que bloquear                                    |
-| ------------------------------------------------------------------------------------ | --------------------------------------------------- |
-| `127.0.0.0/8`, `localhost`, `localhost.localdomain`                                  | Loopback IPv4                                       |
-| `::1/128`                                                                            | Loopback IPv6                                       |
-| `0.0.0.0/8`, `::/128`                                                                | Endereços não especificados e desta rede            |
-| `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`                                      | Redes privadas RFC1918                              |
+| Intervalo ou host                                                                    | Por que bloquear                                      |
+| ------------------------------------------------------------------------------------ | ----------------------------------------------------- |
+| `127.0.0.0/8`, `localhost`, `localhost.localdomain`                                  | Loopback IPv4                                         |
+| `::1/128`                                                                            | Loopback IPv6                                         |
+| `0.0.0.0/8`, `::/128`                                                                | Endereços não especificados e desta rede              |
+| `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`                                      | Redes privadas RFC1918                                |
 | `169.254.0.0/16`, `fe80::/10`                                                        | Endereços link-local e caminhos comuns de metadados de nuvem |
-| `169.254.169.254`, `metadata.google.internal`                                        | Serviços de metadados de nuvem                      |
-| `100.64.0.0/10`                                                                      | Espaço de endereço compartilhado de NAT de operadora |
-| `198.18.0.0/15`, `2001:2::/48`                                                       | Faixas de benchmarking                              |
-| `192.0.0.0/24`, `192.0.2.0/24`, `198.51.100.0/24`, `203.0.113.0/24`, `2001:db8::/32` | Faixas de uso especial e documentação               |
-| `224.0.0.0/4`, `ff00::/8`                                                            | Multicast                                           |
-| `240.0.0.0/4`                                                                        | IPv4 reservado                                      |
-| `fc00::/7`, `fec0::/10`                                                              | Faixas IPv6 locais/privadas                         |
-| `100::/64`, `2001:20::/28`                                                           | Faixas IPv6 de descarte e ORCHIDv2                  |
-| `64:ff9b::/96`, `64:ff9b:1::/48`                                                     | Prefixos NAT64 com IPv4 embutido                    |
-| `2002::/16`, `2001::/32`                                                             | 6to4 e Teredo com IPv4 embutido                     |
-| `::/96`, `::ffff:0:0/96`                                                             | IPv6 compatível com IPv4 e IPv6 mapeado para IPv4   |
+| `169.254.169.254`, `metadata.google.internal`                                        | Serviços de metadados de nuvem                        |
+| `100.64.0.0/10`                                                                      | Espaço de endereços compartilhado de NAT de operadora |
+| `198.18.0.0/15`, `2001:2::/48`                                                       | Intervalos de benchmark                               |
+| `192.0.0.0/24`, `192.0.2.0/24`, `198.51.100.0/24`, `203.0.113.0/24`, `2001:db8::/32` | Intervalos de uso especial e documentação             |
+| `224.0.0.0/4`, `ff00::/8`                                                            | Multicast                                             |
+| `240.0.0.0/4`                                                                        | IPv4 reservado                                        |
+| `fc00::/7`, `fec0::/10`                                                              | Intervalos IPv6 locais/privados                       |
+| `100::/64`, `2001:20::/28`                                                           | Intervalos IPv6 discard e ORCHIDv2                    |
+| `64:ff9b::/96`, `64:ff9b:1::/48`                                                     | Prefixos NAT64 com IPv4 incorporado                   |
+| `2002::/16`, `2001::/32`                                                             | 6to4 e Teredo com IPv4 incorporado                    |
+| `::/96`, `::ffff:0:0/96`                                                             | IPv6 compatível com IPv4 e IPv6 mapeado para IPv4     |

-Se seu provedor de nuvem ou plataforma de rede documentar hosts de metadados ou faixas reservadas adicionais, adicione-os também.
+Se seu provedor de nuvem ou plataforma de rede documentar hosts de metadados ou intervalos reservados adicionais, adicione-os também.

 ## Validação

@ -146,9 +146,9 @@ Valide o proxy a partir do mesmo host, contêiner ou conta de serviço que execu
 openclaw proxy validate --proxy-url http://127.0.0.1:3128
 ```

-Por padrão, quando nenhum destino personalizado é fornecido, o comando verifica se `https://example.com/` tem sucesso e inicia um canário temporário de loopback que o proxy não deve alcançar. A verificação negada padrão passa quando o proxy retorna uma resposta de negação não 2xx ou bloqueia o canário com uma falha de transporte; ela falha se uma resposta bem-sucedida alcançar o canário. Se nenhum proxy estiver habilitado e configurado, a validação relata um problema de configuração; use `--proxy-url` para uma pré-verificação pontual antes de alterar a configuração. Use `--allowed-url` e `--denied-url` para testar expectativas específicas da implantação. Destinos negados personalizados falham fechados: qualquer resposta HTTP significa que o destino era alcançável por meio do proxy, e qualquer erro de transporte é relatado como inconclusivo porque o OpenClaw não consegue provar que o proxy bloqueou uma origem alcançável. Em caso de falha de validação, o comando sai com código 1.
+Por padrão, quando nenhum destino personalizado é fornecido, o comando verifica se `https://example.com/` tem sucesso e inicia um canário de loopback temporário que o proxy não deve alcançar. A verificação negada padrão passa quando o proxy retorna uma resposta de negação não 2xx ou bloqueia o canário com uma falha de transporte; ela falha se uma resposta bem-sucedida chegar ao canário. Se nenhum proxy estiver habilitado e configurado, a validação relata um problema de configuração; use `--proxy-url` para uma pré-verificação pontual antes de alterar a configuração. Use `--allowed-url` e `--denied-url` para testar expectativas específicas da implantação. Adicione `--apns-reachable` para também verificar se a entrega direta HTTP/2 do APNs consegue abrir um túnel CONNECT pelo proxy e receber uma resposta de sandbox do APNs; a sondagem usa um token de provedor intencionalmente inválido, então `403 InvalidProviderToken` é esperado e conta como acessível. Destinos negados personalizados falham fechados: qualquer resposta HTTP significa que o destino estava acessível pelo proxy, e qualquer erro de transporte é relatado como inconclusivo porque o OpenClaw não consegue provar que o proxy bloqueou uma origem acessível. Em caso de falha de validação, o comando sai com código 1.

-Use `--json` para automação. A saída JSON contém o resultado geral, a origem efetiva da configuração do proxy, quaisquer erros de configuração e cada verificação de destino. Credenciais de URL de proxy são redigidas na saída de texto e JSON:
+Use `--json` para automação. A saída JSON contém o resultado geral, a origem efetiva da configuração de proxy, quaisquer erros de configuração e cada verificação de destino. Credenciais de URL de proxy são redigidas na saída de texto e JSON:

 ```json
 {
@ -165,6 +165,12 @@ Use `--json` para automação. A saída JSON contém o resultado geral, a origem
      "url": "https://example.com/",
      "ok": true,
      "status": 200
+    },
+    {
+      "kind": "apns",
+      "url": "https://api.sandbox.push.apple.com",
+      "ok": true,
+      "status": 403
    }
  ]
 }
@ -178,7 +184,7 @@ curl -x http://127.0.0.1:3128 http://127.0.0.1/
 curl -x http://127.0.0.1:3128 http://169.254.169.254/
 ```

-A solicitação pública deve ser bem-sucedida. As solicitações de loopback e metadados devem ser bloqueadas pelo proxy. Para `openclaw proxy validate`, o canário de loopback integrado consegue distinguir uma negação do proxy de uma origem alcançável. Verificações personalizadas de `--denied-url` não têm esse canário, portanto trate tanto respostas HTTP quanto falhas ambíguas de transporte como falhas de validação, a menos que seu proxy exponha um sinal de negação específico da implantação que você possa verificar separadamente.
+A solicitação pública deve ser bem-sucedida. As solicitações de loopback e de metadados devem ser bloqueadas pelo proxy. Para `openclaw proxy validate`, o canário de loopback integrado consegue distinguir uma negação do proxy de uma origem acessível. As verificações personalizadas de `--denied-url` não têm esse canário, portanto trate tanto respostas HTTP quanto falhas ambíguas de transporte como falhas de validação, a menos que seu proxy exponha um sinal de negação específico da implantação que você possa verificar separadamente.

 Em seguida, habilite o roteamento de proxy do OpenClaw:

@ -198,11 +204,11 @@ proxy:

 ## Limites

- O proxy melhora a cobertura para clientes HTTP e WebSocket JavaScript locais ao processo, mas não é um sandbox de rede no nível do SO.
- Sockets `net`, `tls` e `http2` brutos, addons nativos e processos filho podem contornar o roteamento de proxy no nível do Node, a menos que herdem e respeitem variáveis de ambiente de proxy.
- IRC é um canal TCP/TLS bruto fora do roteamento pelo proxy de encaminhamento gerenciado pelo operador. Em implantações que exigem que toda a saída passe por esse proxy de encaminhamento, defina `channels.irc.enabled=false`, a menos que a saída direta por IRC seja explicitamente aprovada.
- O proxy local de depuração é uma ferramenta de diagnóstico, e seu encaminhamento direto upstream para solicitações de proxy e túneis CONNECT fica desabilitado por padrão enquanto o modo de proxy gerenciado está ativo; habilite o encaminhamento direto somente para diagnósticos locais aprovados.
- WebUIs locais do usuário e servidores de modelo locais devem ser incluídos na lista de permissões na política de proxy do operador quando necessário; o OpenClaw não expõe um desvio geral de rede local para eles.
- O desvio de proxy do plano de controle do Gateway é intencionalmente limitado a `localhost` e URLs de IP de loopback literais. Use `ws://127.0.0.1:18789`, `ws://[::1]:18789` ou `ws://localhost:18789` para conexões locais diretas ao plano de controle do Gateway; outros nomes de host são roteados como tráfego comum baseado em nome de host.
+- O proxy melhora a cobertura para clientes HTTP e WebSocket JavaScript locais ao processo, mas não é um sandbox de rede no nível do sistema operacional.
+- Soquetes brutos `net`, `tls` e `http2`, addons nativos e processos filhos podem contornar o roteamento de proxy no nível do Node, a menos que herdem e respeitem variáveis de ambiente de proxy.
+- IRC é um canal TCP/TLS bruto fora do roteamento de proxy de encaminhamento gerenciado pelo operador. Em implantações que exigem que todo egresso passe por esse proxy de encaminhamento, defina `channels.irc.enabled=false`, a menos que o egresso IRC direto seja aprovado explicitamente.
+- O proxy de depuração local é uma ferramenta de diagnóstico, e seu encaminhamento upstream direto para solicitações de proxy e túneis CONNECT fica desabilitado por padrão enquanto o modo de proxy gerenciado está ativo; habilite o encaminhamento direto somente para diagnósticos locais aprovados.
+- WebUIs locais do usuário e servidores de modelo locais devem ser adicionados à lista de permissões na política de proxy do operador quando necessário; o OpenClaw não expõe um bypass geral para rede local para eles.
+- O bypass de proxy do plano de controle do Gateway é intencionalmente limitado a `localhost` e URLs de IP de loopback literais. Use `ws://127.0.0.1:18789`, `ws://[::1]:18789` ou `ws://localhost:18789` para conexões diretas locais do plano de controle do Gateway; outros nomes de host são roteados como tráfego comum baseado em nome de host.
 - O OpenClaw não inspeciona, testa nem certifica sua política de proxy.
- Trate alterações de política de proxy como alterações operacionais sensíveis à segurança.
+- Trate alterações na política de proxy como alterações operacionais sensíveis à segurança.
--- a/docs/pt-BR/tools/thinking.md
+++ b/docs/pt-BR/tools/thinking.md
@ -1,13 +1,13 @@
 ---
 read_when:
-    - Ajuste da análise de diretivas ou dos padrões de raciocínio, modo rápido ou verbosidade
-summary: Sintaxe de diretiva para /think, /fast, /verbose, /trace e visibilidade do raciocínio
-title: Níveis de pensamento
+    - Ajuste da análise de diretivas ou padrões de raciocínio, modo rápido ou verbosidade
+summary: Sintaxe de diretivas para /think, /fast, /verbose, /trace e visibilidade do raciocínio
+title: Níveis de raciocínio
 x-i18n:
-    generated_at: "2026-05-04T05:55:58Z"
+    generated_at: "2026-05-04T18:24:30Z"
    model: gpt-5.5
    provider: openai
-    source_hash: 6fa1b0a2b5f7b93a706488c3ad39dfe08c08eed0bdd30880eb4c07d730ee4d4f
+    source_hash: fcd1cd76ca5d0b08656e0629df656ad8aa037201d8de68093b3e46eb0708f811
    source_path: tools/thinking.md
    workflow: 16
 ---
@ -16,104 +16,105 @@ x-i18n:

 - Diretiva inline em qualquer corpo recebido: `/t <level>`, `/think:<level>` ou `/thinking <level>`.
 - Níveis (aliases): `off | minimal | low | medium | high | xhigh | adaptive | max`
-  - minimal → “pensar”
-  - low → “pensar com afinco”
-  - medium → “pensar com mais afinco”
-  - high → “ultrapensar” (orçamento máximo)
-  - xhigh → “ultrapensar+” (modelos GPT-5.2+ e Codex, além do esforço Anthropic Claude Opus 4.7)
-  - adaptive → pensamento adaptativo gerenciado pelo provedor (compatível com Claude 4.6 na Anthropic/Bedrock, Anthropic Claude Opus 4.7 e pensamento dinâmico do Google Gemini)
+  - minimal → “think”
+  - low → “think hard”
+  - medium → “think harder”
+  - high → “ultrathink” (orçamento máximo)
+  - xhigh → “ultrathink+” (modelos GPT-5.2+ e Codex, além do esforço do Anthropic Claude Opus 4.7)
+  - adaptive → pensamento adaptativo gerenciado pelo provedor (com suporte para Claude 4.6 na Anthropic/Bedrock, Anthropic Claude Opus 4.7 e pensamento dinâmico do Google Gemini)
  - max → raciocínio máximo do provedor (Anthropic Claude Opus 4.7; o Ollama mapeia isso para seu maior esforço `think` nativo)
  - `x-high`, `x_high`, `extra-high`, `extra high` e `extra_high` mapeiam para `xhigh`.
  - `highest` mapeia para `high`.
 - Observações sobre provedores:
-  - Menus e seletores de pensamento são orientados por perfis de provedor. Plugins de provedor declaram o conjunto exato de níveis para o modelo selecionado, incluindo rótulos como o binário `on`.
-  - `adaptive`, `xhigh` e `max` são anunciados apenas para perfis de provedor/modelo que dão suporte a eles. Diretivas digitadas para níveis sem suporte são rejeitadas com as opções válidas desse modelo.
-  - Níveis sem suporte armazenados anteriormente são remapeados pela classificação do perfil do provedor. `adaptive` recua para `medium` em modelos não adaptativos, enquanto `xhigh` e `max` recuam para o maior nível diferente de off compatível com o modelo selecionado.
+  - Menus e seletores de pensamento são orientados por perfil de provedor. Plugins de provedor declaram o conjunto exato de níveis para o modelo selecionado, incluindo rótulos como `on` binário.
+  - `adaptive`, `xhigh` e `max` só são anunciados para perfis de provedor/modelo que os suportam. Diretivas digitadas para níveis sem suporte são rejeitadas com as opções válidas desse modelo.
+  - Níveis sem suporte armazenados anteriormente são remapeados pela classificação do perfil do provedor. `adaptive` volta para `medium` em modelos não adaptativos, enquanto `xhigh` e `max` voltam para o maior nível não `off` com suporte para o modelo selecionado.
  - Modelos Anthropic Claude 4.6 usam `adaptive` por padrão quando nenhum nível explícito de pensamento é definido.
-  - Anthropic Claude Opus 4.7 não usa pensamento adaptativo por padrão. O padrão de esforço da API permanece sob controle do provedor, a menos que você defina explicitamente um nível de pensamento.
+  - Anthropic Claude Opus 4.7 não usa pensamento adaptativo por padrão. O padrão de esforço da API continua pertencendo ao provedor, a menos que você defina explicitamente um nível de pensamento.
  - Anthropic Claude Opus 4.7 mapeia `/think xhigh` para pensamento adaptativo mais `output_config.effort: "xhigh"`, porque `/think` é uma diretiva de pensamento e `xhigh` é a configuração de esforço do Opus 4.7.
-  - Anthropic Claude Opus 4.7 também expõe `/think max`; ele mapeia para o mesmo caminho de esforço máximo controlado pelo provedor.
-  - Modelos DeepSeek V4 expõem `/think xhigh|max`; ambos mapeiam para `reasoning_effort: "max"` do DeepSeek, enquanto níveis menores diferentes de off mapeiam para `high`.
-  - Modelos Ollama com suporte a pensamento expõem `/think low|medium|high|max`; `max` mapeia para o `think: "high"` nativo, porque a API nativa do Ollama aceita as strings de esforço `low`, `medium` e `high`.
-  - Modelos OpenAI GPT mapeiam `/think` por meio do suporte a esforço da Responses API específico do modelo. `/think off` envia `reasoning.effort: "none"` apenas quando o modelo de destino dá suporte a isso; caso contrário, o OpenClaw omite a carga útil de raciocínio desativado em vez de enviar um valor sem suporte.
-  - Entradas de catálogo personalizadas compatíveis com OpenAI podem optar por `/think xhigh` definindo `models.providers.<provider>.models[].compat.supportedReasoningEfforts` para incluir `"xhigh"`. Isso usa os mesmos metadados de compatibilidade que mapeiam cargas úteis de esforço de raciocínio OpenAI de saída, então menus, validação de sessão, CLI de agente e `llm-task` concordam com o comportamento de transporte.
-  - Referências obsoletas configuradas do OpenRouter Hunter Alpha ignoram a injeção de raciocínio por proxy, porque essa rota aposentada podia retornar texto da resposta final por meio de campos de raciocínio.
-  - Google Gemini mapeia `/think adaptive` para o pensamento dinâmico controlado pelo provedor do Gemini. Solicitações Gemini 3 omitem um `thinkingLevel` fixo, enquanto solicitações Gemini 2.5 enviam `thinkingBudget: -1`; níveis fixos ainda mapeiam para o `thinkingLevel` ou orçamento Gemini mais próximo para essa família de modelos.
-  - MiniMax (`minimax/*`) no caminho de streaming compatível com Anthropic usa `thinking: { type: "disabled" }` por padrão, a menos que você defina explicitamente pensamento nos parâmetros do modelo ou nos parâmetros da solicitação. Isso evita vazamentos de deltas `reasoning_content` do formato de stream Anthropic não nativo do MiniMax.
-  - Z.AI (`zai/*`) só dá suporte a pensamento binário (`on`/`off`). Qualquer nível diferente de `off` é tratado como `on` (mapeado para `low`).
-  - Moonshot (`moonshot/*`) mapeia `/think off` para `thinking: { type: "disabled" }` e qualquer nível diferente de `off` para `thinking: { type: "enabled" }`. Quando o pensamento está ativado, o Moonshot só aceita `tool_choice` `auto|none`; o OpenClaw normaliza valores incompatíveis para `auto`.
+  - Anthropic Claude Opus 4.7 também expõe `/think max`; ele mapeia para o mesmo caminho de esforço máximo pertencente ao provedor.
+  - Modelos DeepSeek V4 expõem `/think xhigh|max`; ambos mapeiam para `reasoning_effort: "max"` do DeepSeek, enquanto níveis menores não `off` mapeiam para `high`.
+  - Modelos Ollama com capacidade de pensamento expõem `/think low|medium|high|max`; `max` mapeia para `think: "high"` nativo porque a API nativa do Ollama aceita as strings de esforço `low`, `medium` e `high`.
+  - Modelos OpenAI GPT mapeiam `/think` pelo suporte de esforço da Responses API específico do modelo. `/think off` envia `reasoning.effort: "none"` somente quando o modelo de destino oferece suporte; caso contrário, o OpenClaw omite o payload de raciocínio desativado em vez de enviar um valor sem suporte.
+  - Entradas de catálogo personalizadas compatíveis com OpenAI podem optar por `/think xhigh` definindo `models.providers.<provider>.models[].compat.supportedReasoningEfforts` para incluir `"xhigh"`. Isso usa os mesmos metadados de compatibilidade que mapeiam payloads de esforço de raciocínio OpenAI de saída, então menus, validação de sessão, CLI de agente e `llm-task` concordam com o comportamento de transporte.
+  - Refs configuradas obsoletas do OpenRouter Hunter Alpha pulam a injeção de raciocínio por proxy porque essa rota aposentada poderia retornar o texto da resposta final por campos de raciocínio.
+  - Google Gemini mapeia `/think adaptive` para o pensamento dinâmico pertencente ao provedor do Gemini. Requisições Gemini 3 omitem um `thinkingLevel` fixo, enquanto requisições Gemini 2.5 enviam `thinkingBudget: -1`; níveis fixos ainda mapeiam para o `thinkingLevel` ou orçamento Gemini mais próximo para essa família de modelos.
+  - MiniMax (`minimax/*`) no caminho de streaming compatível com Anthropic usa `thinking: { type: "disabled" }` por padrão, a menos que você defina explicitamente pensamento nos parâmetros do modelo ou da requisição. Isso evita deltas `reasoning_content` vazados do formato de stream Anthropic não nativo da MiniMax.
+  - Z.AI (`zai/*`) oferece suporte apenas a pensamento binário (`on`/`off`). Qualquer nível diferente de `off` é tratado como `on` (mapeado para `low`).
+  - Moonshot (`moonshot/*`) mapeia `/think off` para `thinking: { type: "disabled" }` e qualquer nível diferente de `off` para `thinking: { type: "enabled" }`. Quando o pensamento está ativado, Moonshot aceita apenas `tool_choice` `auto|none`; o OpenClaw normaliza valores incompatíveis para `auto`.

 ## Ordem de resolução

-1. Diretiva inline na mensagem (aplica-se apenas a essa mensagem).
-2. Substituição da sessão (definida ao enviar uma mensagem somente com diretiva).
+1. Diretiva inline na mensagem (aplica-se somente a essa mensagem).
+2. Substituição da sessão (definida ao enviar uma mensagem contendo apenas a diretiva).
 3. Padrão por agente (`agents.list[].thinkingDefault` na configuração).
 4. Padrão global (`agents.defaults.thinkingDefault` na configuração).
-5. Fallback: padrão declarado pelo provedor quando disponível; caso contrário, modelos com capacidade de raciocínio resolvem para `medium` ou para o nível diferente de `off` compatível mais próximo para esse modelo, e modelos sem raciocínio permanecem `off`.
+5. Fallback: padrão declarado pelo provedor quando disponível; caso contrário, modelos com capacidade de raciocínio resolvem para `medium` ou para o nível não `off` com suporte mais próximo para esse modelo, e modelos sem raciocínio permanecem `off`.

-## Como definir um padrão de sessão
+## Definir um padrão de sessão

 - Envie uma mensagem que seja **somente** a diretiva (espaços em branco permitidos), por exemplo, `/think:medium` ou `/t high`.
- Isso permanece na sessão atual (por remetente, por padrão); é limpo por `/think:off` ou pela redefinição por inatividade da sessão.
- Uma resposta de confirmação é enviada (`Thinking level set to high.` / `Thinking disabled.`). Se o nível for inválido (por exemplo, `/thinking big`), o comando será rejeitado com uma dica e o estado da sessão permanecerá inalterado.
- Envie `/think` (ou `/think:`) sem argumento para ver o nível de pensamento atual.
+- Isso permanece para a sessão atual (por remetente, por padrão); é limpo por `/think:off` ou pela redefinição de sessão ociosa.
+- Uma resposta de confirmação é enviada (`Thinking level set to high.` / `Thinking disabled.`). Se o nível for inválido (por exemplo, `/thinking big`), o comando será rejeitado com uma dica e o estado da sessão ficará inalterado.
+- Envie `/think` (ou `/think:`) sem argumento para ver o nível atual de pensamento.

 ## Aplicação por agente

- **Pi incorporado**: o nível resolvido é passado para o runtime do agente Pi em processo.
+- **Pi embutido**: o nível resolvido é passado para o runtime do agente Pi em processo.
+- **Backend Claude CLI**: níveis diferentes de off são passados para Claude Code como `--effort` ao usar `claude-cli`; consulte [backends CLI](/pt-BR/gateway/cli-backends).

 ## Modo rápido (/fast)

 - Níveis: `on|off`.
- Mensagem somente com diretiva alterna uma substituição de modo rápido da sessão e responde `Fast mode enabled.` / `Fast mode disabled.`.
+- Mensagem contendo apenas a diretiva alterna uma substituição de modo rápido da sessão e responde `Fast mode enabled.` / `Fast mode disabled.`.
 - Envie `/fast` (ou `/fast status`) sem modo para ver o estado efetivo atual do modo rápido.
 - O OpenClaw resolve o modo rápido nesta ordem:
-  1. `/fast on|off` inline/somente diretiva
+  1. `/fast on|off` inline/contendo apenas a diretiva
  2. Substituição da sessão
  3. Padrão por agente (`agents.list[].fastModeDefault`)
  4. Configuração por modelo: `agents.defaults.models["<provider>/<model>"].params.fastMode`
  5. Fallback: `off`
- Para `openai/*`, o modo rápido mapeia para processamento prioritário da OpenAI enviando `service_tier=priority` em solicitações Responses compatíveis.
- Para `openai-codex/*`, o modo rápido envia o mesmo sinalizador `service_tier=priority` em Codex Responses. O OpenClaw mantém uma alternância `/fast` compartilhada entre os dois caminhos de autenticação.
- Para solicitações públicas diretas `anthropic/*`, incluindo tráfego autenticado por OAuth enviado para `api.anthropic.com`, o modo rápido mapeia para níveis de serviço da Anthropic: `/fast on` define `service_tier=auto`, `/fast off` define `service_tier=standard_only`.
+- Para `openai/*`, o modo rápido mapeia para processamento prioritário da OpenAI enviando `service_tier=priority` em requisições Responses com suporte.
+- Para `openai-codex/*`, o modo rápido envia a mesma flag `service_tier=priority` em Responses do Codex. O OpenClaw mantém uma alternância `/fast` compartilhada entre os dois caminhos de autenticação.
+- Para requisições públicas diretas `anthropic/*`, incluindo tráfego autenticado por OAuth enviado para `api.anthropic.com`, o modo rápido mapeia para camadas de serviço da Anthropic: `/fast on` define `service_tier=auto`, `/fast off` define `service_tier=standard_only`.
 - Para `minimax/*` no caminho compatível com Anthropic, `/fast on` (ou `params.fastMode: true`) reescreve `MiniMax-M2.7` para `MiniMax-M2.7-highspeed`.
- Parâmetros de modelo Anthropic explícitos `serviceTier` / `service_tier` substituem o padrão do modo rápido quando ambos estão definidos. O OpenClaw ainda ignora a injeção de nível de serviço Anthropic para URLs base de proxy não Anthropic.
- `/status` mostra `Fast` apenas quando o modo rápido está ativado.
+- Parâmetros de modelo Anthropic explícitos `serviceTier` / `service_tier` substituem o padrão do modo rápido quando ambos são definidos. O OpenClaw ainda pula a injeção de camada de serviço Anthropic para URLs base de proxy não Anthropic.
+- `/status` mostra `Fast` somente quando o modo rápido está ativado.

-## Diretivas verbosas (/verbose ou /v)
+## Diretivas detalhadas (/verbose ou /v)

 - Níveis: `on` (mínimo) | `full` | `off` (padrão).
- Mensagem somente com diretiva alterna o modo verboso da sessão e responde `Verbose logging enabled.` / `Verbose logging disabled.`; níveis inválidos retornam uma dica sem alterar o estado.
+- Mensagem contendo apenas a diretiva alterna o detalhamento da sessão e responde `Verbose logging enabled.` / `Verbose logging disabled.`; níveis inválidos retornam uma dica sem alterar o estado.
 - `/verbose off` armazena uma substituição explícita da sessão; limpe-a pela UI de Sessões escolhendo `inherit`.
- Diretiva inline afeta apenas essa mensagem; padrões de sessão/globais se aplicam caso contrário.
- Envie `/verbose` (ou `/verbose:`) sem argumento para ver o nível verboso atual.
- Quando o modo verboso está ativado, agentes que emitem resultados estruturados de ferramentas (Pi, outros agentes JSON) enviam cada chamada de ferramenta de volta como sua própria mensagem somente de metadados, prefixada com `<emoji> <tool-name>: <arg>` quando disponível. Esses resumos de ferramentas são enviados assim que cada ferramenta inicia (bolhas separadas), não como deltas de streaming.
- Resumos de falhas de ferramentas permanecem visíveis no modo normal, mas sufixos com detalhes de erro brutos ficam ocultos, a menos que o modo verboso esteja `on` ou `full`.
- Quando o modo verboso está `full`, as saídas de ferramentas também são encaminhadas após a conclusão (bolha separada, truncada para um tamanho seguro). Se você alternar `/verbose on|full|off` enquanto uma execução estiver em andamento, as bolhas de ferramentas subsequentes respeitarão a nova configuração.
- `agents.defaults.toolProgressDetail` controla o formato dos resumos de ferramentas de `/verbose` e das linhas de ferramenta de rascunho de progresso. Use `"explain"` (padrão) para rótulos humanos compactos, como `🛠️ Exec: checking JS syntax`; use `"raw"` quando também quiser o comando/detalhe bruto anexado para depuração. `agents.list[].toolProgressDetail` por agente substitui o padrão.
+- Diretiva inline afeta somente essa mensagem; padrões de sessão/globais se aplicam caso contrário.
+- Envie `/verbose` (ou `/verbose:`) sem argumento para ver o nível detalhado atual.
+- Quando o modo detalhado está ativado, agentes que emitem resultados estruturados de ferramentas (Pi, outros agentes JSON) enviam cada chamada de ferramenta de volta como sua própria mensagem apenas de metadados, prefixada com `<emoji> <tool-name>: <arg>` quando disponível. Esses resumos de ferramentas são enviados assim que cada ferramenta inicia (bolhas separadas), não como deltas de streaming.
+- Resumos de falha de ferramenta permanecem visíveis no modo normal, mas sufixos com detalhes brutos de erro ficam ocultos, a menos que o detalhamento seja `on` ou `full`.
+- Quando o detalhamento é `full`, saídas de ferramentas também são encaminhadas após a conclusão (bolha separada, truncada para um tamanho seguro). Se você alternar `/verbose on|full|off` enquanto uma execução está em andamento, bolhas de ferramentas posteriores respeitarão a nova configuração.
+- `agents.defaults.toolProgressDetail` controla o formato dos resumos de ferramentas de `/verbose` e das linhas de ferramenta de rascunho de progresso. Use `"explain"` (padrão) para rótulos humanos compactos como `🛠️ Exec: checking JS syntax`; use `"raw"` quando também quiser o comando/detalhe bruto anexado para depuração. `agents.list[].toolProgressDetail` por agente substitui o padrão.
  - `explain`: `🛠️ Exec: check JS syntax for /tmp/app.js`
  - `raw`: `🛠️ Exec: check JS syntax for /tmp/app.js, node --check /tmp/app.js`

 ## Diretivas de rastreamento de Plugin (/trace)

 - Níveis: `on` | `off` (padrão).
- Mensagem somente com diretiva alterna a saída de rastreamento de Plugin da sessão e responde `Plugin trace enabled.` / `Plugin trace disabled.`.
- Diretiva inline afeta apenas essa mensagem; padrões de sessão/globais se aplicam caso contrário.
- Envie `/trace` (ou `/trace:`) sem argumento para ver o nível de rastreamento atual.
- `/trace` é mais restrito que `/verbose`: ele expõe apenas linhas de rastreamento/depuração pertencentes ao Plugin, como resumos de depuração do Active Memory.
- Linhas de rastreamento podem aparecer em `/status` e como uma mensagem diagnóstica de acompanhamento após a resposta normal do assistente.
+- Mensagem contendo apenas a diretiva alterna a saída de rastreamento de Plugin da sessão e responde `Plugin trace enabled.` / `Plugin trace disabled.`.
+- Diretiva inline afeta somente essa mensagem; padrões de sessão/globais se aplicam caso contrário.
+- Envie `/trace` (ou `/trace:`) sem argumento para ver o nível atual de rastreamento.
+- `/trace` é mais restrito que `/verbose`: ele expõe apenas linhas de rastreamento/depuração pertencentes ao Plugin, como resumos de depuração da Active Memory.
+- Linhas de rastreamento podem aparecer em `/status` e como mensagem diagnóstica de acompanhamento após a resposta normal do assistente.

 ## Visibilidade do raciocínio (/reasoning)

 - Níveis: `on|off|stream`.
- Mensagem somente com diretiva alterna se blocos de pensamento são mostrados nas respostas.
+- Mensagem contendo apenas a diretiva alterna se blocos de pensamento são mostrados nas respostas.
 - Quando ativado, o raciocínio é enviado como uma **mensagem separada** prefixada com `Reasoning:`.
- `stream` (somente Telegram): transmite o raciocínio para a bolha de rascunho do Telegram enquanto a resposta está sendo gerada e, em seguida, envia a resposta final sem raciocínio.
+- `stream` (somente Telegram): transmite o raciocínio para a bolha de rascunho do Telegram enquanto a resposta está sendo gerada, depois envia a resposta final sem raciocínio.
 - Alias: `/reason`.
- Envie `/reasoning` (ou `/reasoning:`) sem argumento para ver o nível de raciocínio atual.
+- Envie `/reasoning` (ou `/reasoning:`) sem argumento para ver o nível atual de raciocínio.
 - Ordem de resolução: diretiva inline, depois substituição da sessão, depois padrão por agente (`agents.list[].reasoningDefault`), depois fallback (`off`).

-Tags de raciocínio de modelo local malformadas são tratadas de forma conservadora. Blocos fechados `<think>...</think>` permanecem ocultos em respostas normais, e raciocínio não fechado após texto já visível também fica oculto. Se uma resposta estiver totalmente envolvida em uma única tag de abertura não fechada e, caso contrário, fosse entregue como texto vazio, o OpenClaw remove a tag de abertura malformada e entrega o texto restante.
+Tags de raciocínio de modelo local malformadas são tratadas de forma conservadora. Blocos `<think>...</think>` fechados permanecem ocultos em respostas normais, e raciocínio não fechado após texto já visível também fica oculto. Se uma resposta estiver totalmente envolvida em uma única tag de abertura não fechada e, de outra forma, seria entregue como texto vazio, o OpenClaw remove a tag de abertura malformada e entrega o texto restante.

 ## Relacionado

@ -121,23 +122,23 @@ Tags de raciocínio de modelo local malformadas são tratadas de forma conservad

 ## Heartbeats

- O corpo da sondagem de Heartbeat é o prompt de Heartbeat configurado (padrão: `Read HEARTBEAT.md if it exists (workspace context). Follow it strictly. Do not infer or repeat old tasks from prior chats. If nothing needs attention, reply HEARTBEAT_OK.`). Diretivas inline em uma mensagem de Heartbeat se aplicam normalmente (mas evite alterar padrões de sessão a partir de heartbeats).
- A entrega de Heartbeat usa por padrão apenas a carga útil final. Para também enviar a mensagem `Reasoning:` separada (quando disponível), defina `agents.defaults.heartbeat.includeReasoning: true` ou `agents.list[].heartbeat.includeReasoning: true` por agente.
+- O corpo da sondagem de Heartbeat é o prompt de Heartbeat configurado (padrão: `Read HEARTBEAT.md if it exists (workspace context). Follow it strictly. Do not infer or repeat old tasks from prior chats. If nothing needs attention, reply HEARTBEAT_OK.`). Diretivas inline em uma mensagem de Heartbeat se aplicam normalmente (mas evite alterar padrões de sessão a partir de Heartbeats).
+- A entrega de Heartbeat usa somente o payload final por padrão. Para também enviar a mensagem `Reasoning:` separada (quando disponível), defina `agents.defaults.heartbeat.includeReasoning: true` ou `agents.list[].heartbeat.includeReasoning: true` por agente.

 ## UI de chat web

- O seletor de pensamento do chat web espelha o nível armazenado da sessão a partir do armazenamento/configuração da sessão recebida quando a página carrega.
- Escolher outro nível grava a substituição da sessão imediatamente via `sessions.patch`; ele não espera o próximo envio e não é uma substituição única `thinkingOnce`.
- A primeira opção é sempre `Default (<resolved level>)`, em que o padrão resolvido vem do perfil de pensamento do provedor do modelo da sessão ativa mais a mesma lógica de fallback usada por `/status` e `session_status`.
- O seletor usa `thinkingLevels` retornado pela linha/padrões da sessão do Gateway, com `thinkingOptions` mantido como uma lista legada de rótulos. A UI do navegador não mantém sua própria lista de regex de provedores; Plugins são donos dos conjuntos de níveis específicos de modelo.
- `/think:<level>` ainda funciona e atualiza o mesmo nível de sessão armazenado, então diretivas de chat e o seletor permanecem sincronizados.
+- O seletor de pensamento do chat web reflete o nível armazenado da sessão a partir do armazenamento/configuração da sessão recebida quando a página carrega.
+- Escolher outro nível grava a substituição da sessão imediatamente via `sessions.patch`; ele não espera o próximo envio e não é uma substituição `thinkingOnce` de uso único.
+- A primeira opção é sempre `Default (<resolved level>)`, em que o padrão resolvido vem do perfil de pensamento do provedor do modelo da sessão ativa mais a mesma lógica de fallback que `/status` e `session_status` usam.
+- O seletor usa `thinkingLevels` retornado pela linha/padrões de sessão do Gateway, com `thinkingOptions` mantido como uma lista legada de rótulos. A UI do navegador não mantém sua própria lista de regex de provedores; Plugins possuem os conjuntos de níveis específicos de modelo.
+- `/think:<level>` ainda funciona e atualiza o mesmo nível armazenado da sessão, então diretivas de chat e o seletor permanecem sincronizados.

 ## Perfis de provedor

- Plugins de provedor podem expor `resolveThinkingProfile(ctx)` para definir os níveis compatíveis e o padrão do modelo.
- Plugins de provedor que fazem proxy de modelos Claude devem reutilizar `resolveClaudeThinkingProfile(modelId)` de `openclaw/plugin-sdk/provider-model-shared` para que os catálogos diretos da Anthropic e de proxy permaneçam alinhados.
+- Plugins de provedor podem expor `resolveThinkingProfile(ctx)` para definir os níveis compatíveis do modelo e o padrão.
+- Plugins de provedor que atuam como proxy de modelos Claude devem reutilizar `resolveClaudeThinkingProfile(modelId)` de `openclaw/plugin-sdk/provider-model-shared` para que os catálogos diretos da Anthropic e de proxy permaneçam alinhados.
 - Cada nível de perfil tem um `id` canônico armazenado (`off`, `minimal`, `low`, `medium`, `high`, `xhigh`, `adaptive` ou `max`) e pode incluir um `label` de exibição. Provedores binários usam `{ id: "low", label: "on" }`.
- Plugins de ferramenta que precisam validar uma substituição explícita de raciocínio devem usar `api.runtime.agent.resolveThinkingPolicy({ provider, model })` mais `api.runtime.agent.normalizeThinkingLevel(...)`; eles não devem manter suas próprias listas de níveis por provedor/modelo.
- Plugins de ferramenta com acesso a metadados configurados de modelos personalizados podem passar `catalog` para `resolveThinkingPolicy` para que adesões a `compat.supportedReasoningEfforts` sejam refletidas na validação do lado do Plugin.
+- Plugins de ferramenta que precisam validar uma substituição explícita de raciocínio devem usar `api.runtime.agent.resolveThinkingPolicy({ provider, model })` mais `api.runtime.agent.normalizeThinkingLevel(...)`; eles não devem manter suas próprias listas de níveis de provedor/modelo.
+- Plugins de ferramenta com acesso aos metadados configurados de modelo personalizado podem passar `catalog` para `resolveThinkingPolicy` para que adesões de `compat.supportedReasoningEfforts` sejam refletidas na validação no lado do Plugin.
 - Hooks legados publicados (`supportsXHighThinking`, `isBinaryThinking` e `resolveDefaultThinkingLevel`) permanecem como adaptadores de compatibilidade, mas novos conjuntos de níveis personalizados devem usar `resolveThinkingProfile`.
 - Linhas/padrões do Gateway expõem `thinkingLevels`, `thinkingOptions` e `thinkingDefault` para que clientes ACP/chat renderizem os mesmos ids e rótulos de perfil que a validação em tempo de execução usa.