chore(i18n): refresh pt-BR translations

docs/pt-BR/reference/RELEASING.md

@@ -1,27 +1,27 @@
 ---
 read_when:
     - Procurando definições de canais de lançamento públicos
-    - Procurando nomenclatura de versão e cadência
-summary: Canais de lançamento públicos, nomenclatura de versão e cadência
+    - Procurando nomenclatura de versões e cadência
+summary: Canais de lançamento públicos, nomenclatura de versões e cadência
 title: Política de lançamento
 x-i18n:
-    generated_at: "2026-04-14T02:08:34Z"
+    generated_at: "2026-04-14T05:33:33Z"
     model: gpt-5.4
     provider: openai
-    source_hash: fdc32839447205d74ba7a20a45fbac8e13b199174b442a1e260e3fce056c63da
+    source_hash: 3eaf9f1786b8c9fd4f5a9c657b623cb69d1a485958e1a9b8f108511839b63587
     source_path: reference/RELEASING.md
     workflow: 15
 ---
 
 # Política de lançamento
 
-O OpenClaw tem três canais de lançamento públicos:
+O OpenClaw tem três linhas públicas de lançamento:
 
 - stable: lançamentos com tag que publicam no npm `beta` por padrão, ou no npm `latest` quando solicitado explicitamente
 - beta: tags de pré-lançamento que publicam no npm `beta`
-- dev: a cabeça móvel de `main`
+- dev: a ponta móvel de `main`
 
-## Nomenclatura de versão
+## Nomenclatura de versões
 
 - Versão de lançamento stable: `YYYY.M.D`
   - Tag Git: `vYYYY.M.D`
@@ -30,153 +30,112 @@ O OpenClaw tem três canais de lançamento públicos:
 - Versão de pré-lançamento beta: `YYYY.M.D-beta.N`
   - Tag Git: `vYYYY.M.D-beta.N`
 - Não use preenchimento com zero para mês ou dia
-- `latest` significa o lançamento npm stable promovido atual
-- `beta` significa o alvo de instalação beta atual
-- Lançamentos stable e lançamentos de correção stable publicam no npm `beta` por padrão; operadores de lançamento podem direcionar para `latest` explicitamente, ou promover depois uma build beta validada
+- `latest` significa o lançamento stable promovido atual do npm
+- `beta` significa o destino de instalação beta atual
+- Lançamentos stable e de correção stable publicam no npm `beta` por padrão; operadores de lançamento podem direcionar para `latest` explicitamente, ou promover depois uma build beta validada
 - Todo lançamento do OpenClaw envia o pacote npm e o app macOS juntos
 
 ## Cadência de lançamento
 
 - Os lançamentos passam primeiro por beta
-- Stable só vem depois que o beta mais recente for validado
-- Procedimento detalhado de lançamento, aprovações, credenciais e notas de recuperação são
-  apenas para mantenedores
+- stable vem somente depois que o beta mais recente é validado
+- O procedimento detalhado de lançamento, aprovações, credenciais e notas de recuperação é exclusivo para mantenedores
 
 ## Verificações prévias de lançamento
 
-- Execute `pnpm build && pnpm ui:build` antes de `pnpm release:check` para que os
-  artefatos de lançamento esperados em `dist/*` e o bundle da UI de Controle existam para a etapa
-  de validação do pacote
+- Execute `pnpm build && pnpm ui:build` antes de `pnpm release:check` para que os artefatos de lançamento esperados em `dist/*` e o bundle da Control UI existam para a etapa de validação do pack
 - Execute `pnpm release:check` antes de todo lançamento com tag
 - As verificações de lançamento agora são executadas em um workflow manual separado:
   `OpenClaw Release Checks`
-- Essa separação é intencional: mantenha o caminho real de lançamento npm curto,
-  determinístico e focado em artefatos, enquanto verificações live mais lentas ficam em sua
-  própria trilha para não atrasarem nem bloquearem a publicação
-- As verificações de lançamento devem ser disparadas a partir da ref de workflow `main` para que a
-  lógica do workflow e os segredos permaneçam canônicos
-- Esse workflow aceita uma tag de lançamento existente ou o SHA completo de 40 caracteres
-  atual do commit `main`
-- No modo commit-SHA, ele aceita apenas o HEAD atual de `origin/main`; use uma
-  tag de lançamento para commits de lançamento mais antigos
-- A verificação prévia somente de validação de `OpenClaw NPM Release` também aceita o
-  SHA completo atual de 40 caracteres do commit `main` sem exigir uma tag enviada
-- Esse caminho por SHA é somente para validação e não pode ser promovido a uma publicação real
-- No modo SHA, o workflow sintetiza `v<package.json version>` apenas para a
-  verificação de metadados do pacote; a publicação real ainda exige uma tag de lançamento real
-- Ambos os workflows mantêm o caminho real de publicação e promoção em runners
-  hospedados pelo GitHub, enquanto o caminho de validação não mutável pode usar os
-  runners Linux Blacksmith maiores
+- Essa separação é intencional: mantém o caminho real de lançamento no npm curto,
+  determinístico e focado em artefatos, enquanto verificações live mais lentas ficam em sua própria linha para não atrasar nem bloquear a publicação
+- As verificações de lançamento devem ser disparadas a partir da ref de workflow `main` para que a lógica do workflow e os segredos permaneçam canônicos
+- Esse workflow aceita uma tag de lançamento existente ou o SHA completo de 40 caracteres do commit atual de `main`
+- No modo de commit SHA, ele aceita apenas o HEAD atual de `origin/main`; use uma tag de lançamento para commits de lançamento mais antigos
+- A validação prévia apenas de validação de `OpenClaw NPM Release` também aceita o SHA completo de 40 caracteres do commit atual de `main` sem exigir uma tag enviada
+- Esse caminho por SHA é apenas para validação e não pode ser promovido para uma publicação real
+- No modo SHA, o workflow sintetiza `v<package.json version>` apenas para a verificação dos metadados do pacote; a publicação real ainda exige uma tag de lançamento real
+- Ambos os workflows mantêm o caminho real de publicação e promoção em runners hospedados pelo GitHub, enquanto o caminho de validação não mutável pode usar os runners Linux maiores da Blacksmith
 - Esse workflow executa
   `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache`
   usando os segredos de workflow `OPENAI_API_KEY` e `ANTHROPIC_API_KEY`
-- A verificação prévia de lançamento npm não espera mais pela trilha separada de verificações de lançamento
+- A validação prévia de lançamento no npm não espera mais pela linha separada de verificações de lançamento
 - Execute `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`
   (ou a tag beta/correção correspondente) antes da aprovação
-- Após a publicação no npm, execute
+- Depois da publicação no npm, execute
   `node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D`
-  (ou a versão beta/correção correspondente) para verificar o caminho de instalação
-  publicado no registro em um prefixo temporário novo
-- A automação de lançamento dos mantenedores agora usa preflight-then-promote:
-  - a publicação npm real precisa passar por um `preflight_run_id` npm bem-sucedido
+  (ou a versão beta/correção correspondente) para verificar o caminho de instalação publicado no registro em um prefixo temporário novo
+- A automação de lançamento dos mantenedores agora usa pré-verificação seguida de promoção:
+  - a publicação real no npm deve passar por um `preflight_run_id` bem-sucedido
   - lançamentos npm stable usam `beta` por padrão
-  - a publicação npm stable pode direcionar para `latest` explicitamente via entrada do workflow
+  - a publicação npm stable pode direcionar para `latest` explicitamente por meio da entrada do workflow
   - a promoção npm stable de `beta` para `latest` continua disponível como um modo manual explícito no workflow confiável `OpenClaw NPM Release`
-  - publicações stable diretas também podem executar um modo explícito de sincronização de dist-tag que
-    faz `latest` e `beta` apontarem para a versão stable já publicada
+  - publicações stable diretas também podem executar um modo explícito de sincronização de dist-tag que aponta `latest` e `beta` para a versão stable já publicada
   - esses modos de dist-tag ainda precisam de um `NPM_TOKEN` válido no ambiente `npm-release`, porque o gerenciamento de `npm dist-tag` é separado da publicação confiável
   - `macOS Release` público é somente para validação
-  - a publicação privada real para mac deve passar por `preflight_run_id` e `validate_run_id`
-    privados de mac bem-sucedidos
-  - os caminhos de publicação reais promovem artefatos preparados em vez de reconstruí-los
-    novamente
-- Para lançamentos de correção stable como `YYYY.M.D-N`, o verificador pós-publicação
-  também verifica o mesmo caminho de upgrade em prefixo temporário de `YYYY.M.D` para `YYYY.M.D-N`
-  para que correções de lançamento não possam deixar silenciosamente instalações globais mais antigas na
-  carga do stable base
-- A verificação prévia de lançamento npm falha de forma fechada a menos que o tarball inclua
-  tanto `dist/control-ui/index.html` quanto uma carga útil não vazia em `dist/control-ui/assets/`
-  para que não enviemos novamente um painel do navegador vazio
-- Se o trabalho de lançamento tocou no planejamento de CI, manifests de temporização de extensões ou
-  matrizes de teste de extensões, regenere e revise as saídas de matriz do workflow
-  `checks-node-extensions` de propriedade do planner a partir de `.github/workflows/ci.yml`
-  antes da aprovação para que as notas de lançamento não descrevam um layout de CI desatualizado
-- A prontidão para lançamento stable no macOS também inclui as superfícies do atualizador:
+  - a publicação real privada do mac deve passar por `preflight_run_id` e `validate_run_id` privados do mac bem-sucedidos
+  - os caminhos de publicação reais promovem artefatos preparados em vez de reconstruí-los novamente
+- Para lançamentos de correção stable como `YYYY.M.D-N`, o verificador pós-publicação também verifica o mesmo caminho de upgrade em prefixo temporário de `YYYY.M.D` para `YYYY.M.D-N`, para que correções de lançamento não possam deixar silenciosamente instalações globais antigas na carga stable base
+- A validação prévia de lançamento no npm falha em modo fechado, a menos que o tarball inclua `dist/control-ui/index.html` e uma carga `dist/control-ui/assets/` não vazia, para que não enviemos novamente um painel do navegador vazio
+- `pnpm test:install:smoke` também impõe o orçamento de `unpackedSize` do `npm pack` no tarball de atualização candidato, para que o e2e do instalador detecte aumento acidental do pack antes do caminho de publicação de lançamento
+- Se o trabalho de lançamento tiver alterado o planejamento de CI, manifestos de tempo de extensões ou matrizes de teste de extensões, regenere e revise as saídas da matriz de workflow `checks-node-extensions` de propriedade do planejador a partir de `.github/workflows/ci.yml` antes da aprovação, para que as notas de lançamento não descrevam um layout de CI desatualizado
+- A prontidão de lançamento stable do macOS também inclui as superfícies do atualizador:
   - o lançamento no GitHub deve terminar com os arquivos empacotados `.zip`, `.dmg` e `.dSYM.zip`
   - `appcast.xml` em `main` deve apontar para o novo zip stable após a publicação
-  - o app empacotado deve manter um bundle id não-debug, uma URL de feed Sparkle não vazia
-    e um `CFBundleVersion` igual ou acima do piso de build Sparkle canônico
-    para essa versão de lançamento
+  - o app empacotado deve manter um bundle id que não seja de depuração, uma URL de feed Sparkle não vazia e um `CFBundleVersion` igual ou superior ao piso canônico de build do Sparkle para essa versão de lançamento
 
-## Entradas do workflow NPM
+## Entradas de workflow do npm
 
 `OpenClaw NPM Release` aceita estas entradas controladas pelo operador:
 
 - `tag`: tag de lançamento obrigatória, como `v2026.4.2`, `v2026.4.2-1` ou
-  `v2026.4.2-beta.1`; quando `preflight_only=true`, também pode ser o
-  SHA completo atual de 40 caracteres do commit `main` para verificação prévia somente de validação
-- `preflight_only`: `true` para somente validação/build/pacote, `false` para o
-  caminho de publicação real
-- `preflight_run_id`: obrigatório no caminho de publicação real para que o workflow reutilize
-  o tarball preparado da execução de verificação prévia bem-sucedida
-- `npm_dist_tag`: tag npm de destino para o caminho de publicação; o padrão é `beta`
-- `promote_beta_to_latest`: `true` para pular a publicação e mover uma build stable `beta`
-  já publicada para `latest`
-- `sync_stable_dist_tags`: `true` para pular a publicação e fazer `latest` e
-  `beta` apontarem para uma versão stable já publicada
+  `v2026.4.2-beta.1`; quando `preflight_only=true`, também pode ser o SHA completo de 40 caracteres do commit atual de `main` para uma validação prévia somente de validação
+- `preflight_only`: `true` para apenas validação/build/package, `false` para o caminho de publicação real
+- `preflight_run_id`: obrigatório no caminho de publicação real para que o workflow reutilize o tarball preparado da execução de pré-verificação bem-sucedida
+- `npm_dist_tag`: tag de destino do npm para o caminho de publicação; o padrão é `beta`
+- `promote_beta_to_latest`: `true` para pular a publicação e mover uma build stable `beta` já publicada para `latest`
+- `sync_stable_dist_tags`: `true` para pular a publicação e apontar `latest` e `beta` para uma versão stable já publicada
 
 `OpenClaw Release Checks` aceita estas entradas controladas pelo operador:
 
-- `ref`: tag de lançamento existente ou o SHA completo de 40 caracteres do commit
-  atual `main` para validar
+- `ref`: tag de lançamento existente ou o SHA completo de 40 caracteres do commit atual de `main` para validar
 
 Regras:
 
 - Tags stable e de correção podem publicar em `beta` ou `latest`
-- Tags de pré-lançamento beta podem publicar apenas em `beta`
-- A entrada com SHA completo de commit é permitida apenas quando `preflight_only=true`
-- O modo commit-SHA das verificações de lançamento também exige o HEAD atual de `origin/main`
-- O caminho de publicação real deve usar o mesmo `npm_dist_tag` usado durante a verificação prévia;
-  o workflow verifica esses metadados antes de a publicação continuar
+- Tags de pré-lançamento beta podem publicar somente em `beta`
+- A entrada de SHA completo de commit é permitida apenas quando `preflight_only=true`
+- O modo por commit SHA das verificações de lançamento também exige o HEAD atual de `origin/main`
+- O caminho de publicação real deve usar o mesmo `npm_dist_tag` usado durante a pré-verificação; o workflow verifica esses metadados antes de a publicação continuar
 - O modo de promoção deve usar uma tag stable ou de correção, `preflight_only=false`,
   `preflight_run_id` vazio e `npm_dist_tag=beta`
 - O modo de sincronização de dist-tag deve usar uma tag stable ou de correção,
-  `preflight_only=false`, `preflight_run_id` vazio, `npm_dist_tag=latest`
+  `preflight_only=false`, `preflight_run_id` vazio, `npm_dist_tag=latest`,
   e `promote_beta_to_latest=false`
-- Os modos de promoção e sincronização de dist-tag também exigem um `NPM_TOKEN` válido porque
-  `npm dist-tag add` ainda precisa de autenticação npm normal; a publicação confiável cobre
-  apenas o caminho de publicação do pacote
+- Os modos de promoção e sincronização de dist-tag também exigem um `NPM_TOKEN` válido porque `npm dist-tag add` ainda precisa de autenticação npm normal; a publicação confiável cobre apenas o caminho de publicação do pacote
 
 ## Sequência de lançamento npm stable
 
-Ao fazer um lançamento npm stable:
+Ao criar um lançamento npm stable:
 
 1. Execute `OpenClaw NPM Release` com `preflight_only=true`
-   - Antes de existir uma tag, você pode usar o SHA completo de `main` atual para uma
-     execução seca somente de validação do workflow de verificação prévia
-2. Escolha `npm_dist_tag=beta` para o fluxo normal beta-first, ou `latest` apenas
-   quando você quiser intencionalmente uma publicação stable direta
-3. Execute `OpenClaw Release Checks` separadamente com a mesma tag ou o
-   SHA completo atual de `main` quando quiser cobertura live de cache de prompt
-   - Isso é separado de propósito para que a cobertura live continue disponível sem
-     reacoplar verificações demoradas ou instáveis ao workflow de publicação
+   - Antes de existir uma tag, você pode usar o SHA completo atual de `main` para uma simulação somente de validação do workflow de pré-verificação
+2. Escolha `npm_dist_tag=beta` para o fluxo normal beta-first, ou `latest` somente quando quiser intencionalmente uma publicação stable direta
+3. Execute `OpenClaw Release Checks` separadamente com a mesma tag ou o SHA completo atual de `main` quando quiser cobertura live de cache de prompt
+   - Isso é separado de propósito para que a cobertura live continue disponível sem reacoplar verificações demoradas ou instáveis ao workflow de publicação
 4. Salve o `preflight_run_id` bem-sucedido
 5. Execute `OpenClaw NPM Release` novamente com `preflight_only=false`, a mesma
    `tag`, o mesmo `npm_dist_tag` e o `preflight_run_id` salvo
-6. Se o lançamento caiu em `beta`, execute `OpenClaw NPM Release` mais tarde com a
-   mesma `tag` stable, `promote_beta_to_latest=true`, `preflight_only=false`,
-   `preflight_run_id` vazio e `npm_dist_tag=beta` quando quiser mover essa
-   build publicada para `latest`
+6. Se o lançamento chegou a `beta`, execute `OpenClaw NPM Release` mais tarde com a mesma `tag` stable, `promote_beta_to_latest=true`, `preflight_only=false`,
+   `preflight_run_id` vazio e `npm_dist_tag=beta` quando quiser mover essa build publicada para `latest`
 7. Se o lançamento foi intencionalmente publicado diretamente em `latest` e `beta`
    deve seguir a mesma build stable, execute `OpenClaw NPM Release` com a mesma
    `tag` stable, `sync_stable_dist_tags=true`, `promote_beta_to_latest=false`,
    `preflight_only=false`, `preflight_run_id` vazio e `npm_dist_tag=latest`
 
-Os modos de promoção e sincronização de dist-tag ainda exigem a aprovação do ambiente
-`npm-release` e um `NPM_TOKEN` válido acessível a essa execução do workflow.
+Os modos de promoção e sincronização de dist-tag ainda exigem a aprovação do ambiente `npm-release` e um `NPM_TOKEN` válido acessível a essa execução de workflow.
 
-Isso mantém tanto o caminho de publicação direta quanto o caminho de promoção beta-first
-documentados e visíveis para o operador.
+Isso mantém o caminho de publicação direta e o caminho de promoção beta-first ambos documentados e visíveis para o operador.
 
 ## Referências públicas