@the-bearded-bear/claude-craft 8.23.3 → 8.26.0-next.2a54921

package/Dev/i18n/pt/Common/commands/ralph-run.md

@@ -76,6 +76,35 @@ O sistema de DoD valida a conclusão por meio de múltiplos critérios:
 | `hook` | Executar hook existente do Claude |
 | `human` | Validação humana interativa |
 
+#### Limite do validador `command` → usar `type: hook`
+
+`type: command` só executa comandos que passam na lista de permissões de `Tools/Ralph/lib/dod-validator.sh`: letras, dígitos, espaço e `_ . / " ' -`. Qualquer comando contendo `=`, `|`, `&` ou `:` (assim como `;`, `>`, `$` etc.) é rejeitado com `ERROR: Invalid command`: o critério **nunca** é validado e o loop roda até o circuit breaker disparar.
+
+| Comando rejeitado | Caractere culpado |
+|-------------------|-------------------|
+| `dotnet build /p:TreatWarningsAsErrors=true` | `:` e `=` |
+| `npm test && npm run lint` | `&` |
+| `pytest \| tee out.log` | `\|` |
+
+Nesses casos, colocar o comando em um script e declará-lo como `type: hook`:
+
+```yaml
+definition_of_done:
+  checklist:
+    - id: build
+      type: hook
+      script: ".ralph/dod/build.sh"
+      required: true
+```
+
+```bash
+#!/usr/bin/env bash
+# .ralph/dod/build.sh — recebe {"cwd": ..., "output": ...} em JSON via stdin
+dotnet build /p:TreatWarningsAsErrors=true || exit 2
+```
+
+O script retorna `0` (critério atendido) ou `2` (critério falhou). Chaves lidas por tipo: `command` → `command:`, `output_contains` e `file_changed` → `pattern:`, `hook` → `script:`, `human` → `prompt:`.
+
 ### 4. Circuit Breaker Adaptativo (v2.0)
 
 Seleciona automaticamente o perfil com base nas palavras-chave da tarefa:
@@ -100,6 +129,23 @@ Claude trabalha...
 Stop → stop-dod-gate.sh → Bloquear se DoD não satisfeito (exit 2)
 ```
 
+## /goal (interativo) ou Ralph (autônomo/CI)?
+
+`/goal` é um comando nativo do Claude Code digitado dentro de uma sessão: não é uma opção de `ralph.sh`, que não oferece nenhuma para isso e nunca gera um `/goal`. As duas ferramentas são complementares:
+
+| Critério | `/goal` (nativo) | Ralph (`ralph.sh`) |
+|----------|------------------|--------------------|
+| Critério de conclusão | Julgamento LLM: um modelo pequeno e rápido avalia, após cada turno, o que está visível na conversa — não executa nenhum comando nem lê nenhum arquivo | Determinístico: comandos, padrões e hooks executados por `dod-validator.sh` |
+| Limite de iterações | Sem limite fixo: termina quando a condição é atendida ou julgada impossível, com `/goal clear`, ou se Claude encadeia vários turnos sem ferramentas; um limite pode ser escrito na condição | `max_iterations` + circuit breaker adaptativo |
+| Headless / CI | `claude -p "/goal ..."` itera até o fim em uma única invocação; uso em CI não documentado | Feito para isso: execução autônoma (`--autonomous`, `--overnight`), dashboard `headless` |
+| `disableAllHooks: true` | Indisponível: `/goal` envolve um Stop hook de sessão (idem com `allowManagedHooksOnly`) | O loop e a DoD rodam dentro de `ralph.sh`; só a integração de hooks (`stop-dod-gate.sh`) é desativada |
+| Configuração | Nenhuma; um único goal por sessão, apagado por `/clear` | `ralph.yml` |
+
+- **Escolher `/goal`** para uma tarefa interativa cuja conclusão aparece na conversa (exibir a saída dos testes: o avaliador não os executa).
+- **Escolher Ralph** quando a conclusão deve ser comprovada por comandos, com limite de iterações, sem supervisão ou em CI.
+
+Referência: [documentação do `/goal`](https://code.claude.com/docs/en/goal).
+
 ## Exemplos de Início Rápido
 
 ```bash
@@ -275,4 +321,4 @@ Quando um timeout ocorre:
 
 - `@ralph-conductor` - Agente para orquestração Ralph
 - `/qa:tdd` - Correção de bugs baseada em TDD
-- `/sprint:dev` - Desenvolvimento de sprint com TDD
+- `/workflow:implement` - Desenvolvimento de sprint com TDD

package/Dev/i18n/pt/Common/commands/release-checklist.md

@@ -1,245 +1,9 @@
 ---
-description: Checklist de Release
-argument-hint: [arguments]
+description: "Obsoleto (removido na 9.0): use /gate:check release"
+deprecated: true
+replaced-by: /gate:check
 ---
 
-# Checklist de Release
+> ⚠️ `/common:release-checklist` está obsoleto e será removido na 9.0. Use `/gate:check release`.
 
-Você é um Release Manager especializado. Você deve guiar a equipe através de todas as etapas de um release de qualidade, verificando cada ponto crítico.
-
-## Argumentos
-$ARGUMENTS
-
-Argumentos:
-- Versão (ex: `1.2.0`, `2.0.0-beta.1`)
-- Tipo (patch, minor, major)
-
-Exemplo: `/common:release-checklist 1.2.0 minor`
-
-## MISSÃO
-
-### Etapa 1: Validação Pré-Release
-
-#### 1.1 Estado do Código
-```bash
-# Verificar se está no branch correto
-git branch --show-current  # Deve ser main/master ou release/*
-
-# Verificar ausência de alterações não commitadas
-git status
-
-# Verificar se todos os testes passam
-# [Executar testes de acordo com a tecnologia]
-```
-
-#### 1.2 Changelog
-```bash
-# Verificar se CHANGELOG.md está atualizado
-cat CHANGELOG.md | head -50
-
-# Gerar changelog desde a última tag
-git log $(git describe --tags --abbrev=0)..HEAD --pretty=format:"- %s"
-```
-
-#### 1.3 Arquivos de Versão
-```bash
-# Verificar/atualizar arquivos de versão
-# PHP: composer.json
-# Python: pyproject.toml, __version__.py
-# Node: package.json
-# Flutter: pubspec.yaml
-# iOS: Info.plist
-# Android: build.gradle
-```
-
-### Etapa 2: Testes Exaustivos
-
-```bash
-# Testes unitários
-# Testes de integração
-# Testes E2E
-# Testes de performance
-# Testes de segurança
-```
-
-### Etapa 3: Documentação
-
-```bash
-# Verificar documentação
-# - README atualizado
-# - Docs de API gerados
-# - Guia de migração (se breaking changes)
-```
-
-### Etapa 4: Gerar Checklist Interativo
-
-```
-══════════════════════════════════════════════════════════════
-🚀 CHECKLIST DE RELEASE - v{VERSION}
-══════════════════════════════════════════════════════════════
-
-Tipo: {TYPE} (patch/minor/major)
-Data: YYYY-MM-DD
-Branch: main
-
-══════════════════════════════════════════════════════════════
-📋 PRÉ-RELEASE
-══════════════════════════════════════════════════════════════
-
-## Qualidade de Código
-- [ ] Todos os testes passam (unit, integration, e2e)
-- [ ] Cobertura de testes ≥ 80%
-- [ ] Análise estática sem erros
-- [ ] Code review concluído em todos os PRs
-- [ ] Nenhum TODO/FIXME bloqueante
-
-## Segurança
-- [ ] Auditoria de dependências (sem CVEs críticos)
-- [ ] Nenhum segredo no código
-- [ ] Testes de segurança passaram (OWASP)
-- [ ] Certificados SSL válidos
-
-## Documentação
-- [ ] CHANGELOG.md atualizado
-- [ ] README.md atualizado
-- [ ] Documentação de API gerada
-- [ ] Guia de migração (se breaking changes)
-- [ ] Release notes escritas
-
-## Versionamento
-- [ ] Número de versão incrementado
-- [ ] Tags Git preparadas
-- [ ] Branches de release criadas (se aplicável)
-
-══════════════════════════════════════════════════════════════
-📦 BUILD & EMPACOTAMENTO
-══════════════════════════════════════════════════════════════
-
-## Backend
-- [ ] Build de produção bem-sucedido
-- [ ] Assets compilados e minificados
-- [ ] Migrações de BD preparadas
-- [ ] Variáveis de ambiente documentadas
-
-## Frontend Web
-- [ ] Bundle otimizado (code splitting, tree shaking)
-- [ ] Assets prontos para CDN
-- [ ] Service worker atualizado
-- [ ] Sourcemaps gerados (mas não deployados em prod)
-
-## Mobile (se aplicável)
-- [ ] Build iOS assinado
-- [ ] Build Android assinado
-- [ ] Screenshots da loja atualizadas
-- [ ] Metadados da loja prontos
-
-══════════════════════════════════════════════════════════════
-🔧 VALIDAÇÃO EM STAGING
-══════════════════════════════════════════════════════════════
-
-- [ ] Deploy em staging bem-sucedido
-- [ ] Migrações de BD executadas com sucesso
-- [ ] Testes manuais de smoke OK
-- [ ] Testes de regressão passaram
-- [ ] Performance aceitável (< limiares definidos)
-- [ ] Monitoramento funcionando (logs, métricas)
-- [ ] Rollback testado
-
-══════════════════════════════════════════════════════════════
-🚀 DEPLOY EM PRODUÇÃO
-══════════════════════════════════════════════════════════════
-
-## Pré-Deploy
-- [ ] Modo de manutenção ativado (se necessário)
-- [ ] Backup do banco de dados realizado
-- [ ] Comunicação com equipe de suporte
-- [ ] Janela de deployment validada
-
-## Deploy
-- [ ] Deploy em produção lançado
-- [ ] Migrações de BD executadas
-- [ ] Health checks passam
-- [ ] Modo de manutenção desativado
-
-## Pós-Deploy
-- [ ] Testes de smoke em produção OK
-- [ ] Monitoramento verificado (sem erros)
-- [ ] Performance nominal
-- [ ] Tag Git criada e enviada
-- [ ] Release GitHub/GitLab criado
-
-══════════════════════════════════════════════════════════════
-📢 COMUNICAÇÃO
-══════════════════════════════════════════════════════════════
-
-- [ ] Release notes publicadas
-- [ ] Equipe de suporte informada
-- [ ] Clientes notificados (se aplicável)
-- [ ] Documentação pública atualizada
-- [ ] Anúncio em blog/redes sociais (se aplicável)
-
-══════════════════════════════════════════════════════════════
-🔙 PLANO DE ROLLBACK
-══════════════════════════════════════════════════════════════
-
-Em caso de problema crítico:
-
-1. Identificar problema
-   - Logs: [URL de monitoramento]
-   - Alertas: [URL de alertas]
-
-2. Decisão de rollback
-   - Limite: > 5% de erros 5xx por 5 min
-   - Responsável pela decisão: [Nome]
-
-3. Executar rollback
-   ```bash
-   # Comando de rollback
-   [Adaptar de acordo com a infraestrutura]
-   ```
-
-4. Rollback de BD (se necessário)
-   ```bash
-   # Migrations down
-   [Adaptar de acordo com o ORM]
-   ```
-
-5. Comunicação
-   - Notificar equipe
-   - Abrir incidente
-   - Post-mortem
-
-══════════════════════════════════════════════════════════════
-✅ VALIDAÇÃO FINAL
-══════════════════════════════════════════════════════════════
-
-[ ] Todas as caixas marcadas
-[ ] Release validado por: _______________
-[ ] Data/hora do release: _______________
-
-Notas:
-_________________________________________________
-_________________________________________________
-```
-
-## Comandos Úteis
-
-```bash
-# Criar tag
-git tag -a v{VERSION} -m "Release v{VERSION}"
-git push origin v{VERSION}
-
-# Criar release no GitHub
-gh release create v{VERSION} --title "v{VERSION}" --notes-file RELEASE_NOTES.md
-
-# Gerar changelog automático
-git-cliff --unreleased --tag v{VERSION} > CHANGELOG.md
-```
-
-## Lembrete de Versionamento Semântico
-
-| Tipo | Quando | Exemplo |
-|------|-------|---------|
-| MAJOR | Breaking changes | 1.0.0 → 2.0.0 |
-| MINOR | Nova funcionalidade | 1.0.0 → 1.1.0 |
-| PATCH | Correção de bug | 1.0.0 → 1.0.1 |
+Execute `/gate:check release $ARGUMENTS`: leia `.claude/commands/gate/check.md` e siga-o com estes argumentos. Se esse arquivo faltar, reinstale o claude-craft com o gerenciamento de projetos.

package/Dev/i18n/pt/Common/commands/setup-project-context.md

@@ -1,290 +1,9 @@
 ---
-name: setup-project-context
-description: Analisar o codigo e configurar o contexto do projeto interativamente
-arguments:
-  - name: mode
-    description: Modo de detecao (--auto perguntas minimas, --full questionario completo)
-    required: false
+description: "Obsoleto (removido na 9.0): use /common:init --context"
+deprecated: true
+replaced-by: /common:init
 ---
 
-# Configuracao do Contexto do Projeto
+> ⚠️ `/common:setup-project-context` está obsoleto e será removido na 9.0. Use `/common:init --context`.
 
-Configura `.claude/rules/00-project-context.md` analisando o codigo e fazendo perguntas direcionadas.
-
-## Execucao
-
-### Fase 1: Detecao Automatica
-
-Analisar os seguintes arquivos e diretorios:
-
-**Arquivos de Configuracao:**
-- `package.json` → Nome do projeto Node.js, dependencias, scripts
-- `composer.json` → Nome do projeto PHP, dependencias, framework
-- `pubspec.yaml` → Nome do projeto Flutter/Dart, dependencias
-- `requirements.txt` / `pyproject.toml` → Dependencias Python
-- `Cargo.toml` → Projeto Rust
-- `go.mod` → Modulo Go
-
-**Ambiente e Configuracao:**
-- `.env`, `.env.example` → Banco de dados, servicos
-- `config/` → Configuracao do framework
-- `docker-compose.yml` → Servicos (DB, Redis, etc.)
-
-**Estrutura:**
-- `src/`, `lib/`, `app/` → Localizacao do codigo fonte
-- `tests/`, `spec/` → Framework de testes
-- `docs/`, `specifications/` → Documentacao
-- `.github/`, `.gitlab-ci.yml` → CI/CD
-
-**Dominio (se aplicavel):**
-- `src/Entity/`, `src/Domain/` → Entidades de negocio (PHP/Symfony)
-- `lib/models/`, `lib/domain/` → Modelos (Flutter/Dart)
-- `models/`, `schemas/` → Modelos de dados
-- `migrations/` → Schema do banco de dados
-
-Exibir resultados da analise:
-
-```
-╔══════════════════════════════════════════════════════════════╗
-║             RESULTADOS DA ANALISE DO PROJETO                  ║
-╚══════════════════════════════════════════════════════════════╝
-
-✅ Informacoes Detectadas:
-┌─────────────────┬────────────────────────────────┐
-│ Elemento        │ Valor                          │
-├─────────────────┼────────────────────────────────┤
-│ Nome do Projeto │ {nome_detectado}               │
-│ Linguagem       │ {linguagem_detectada}          │
-│ Framework       │ {framework_detectado}          │
-│ Banco de Dados  │ {database_detectado}           │
-│ Testes          │ {testes_detectados}            │
-│ CI/CD           │ {cicd_detectado}               │
-└─────────────────┴────────────────────────────────┘
-
-📁 Estrutura do Projeto:
-{estrutura_detectada}
-
-📄 Documentacao Encontrada:
-{docs_detectados}
-
-❌ Nao Detectado (sera perguntado):
-- {elementos_faltantes}
-```
-
-### Fase 2: Perguntas Interativas
-
-Perguntar apenas sobre informacoes NAO detectadas na Fase 1.
-Pular perguntas se o modo `--auto` for usado e existir um padrao razoavel.
-
-**Perguntas Essenciais:**
-
-1. **Tipo de Aplicacao** (se nao detectado):
-   ```
-   Que tipo de aplicacao e esta?
-   [ ] API REST      [ ] Aplicacao Web     [ ] Aplicativo Movel
-   [ ] Ferramenta CLI [ ] Biblioteca/Pacote [ ] Monorepo
-   ```
-
-2. **Dominio de Negocio**:
-   ```
-   Qual e o dominio de negocio?
-   [ ] E-commerce    [ ] Plataforma SaaS   [ ] FinTech
-   [ ] HealthTech    [ ] EdTech            [ ] Social/Comunidade
-   [ ] Midia/Conteudo [ ] IoT              [ ] Outro: _____
-   ```
-
-3. **Usuarios Alvo** (2-3 personas):
-   ```
-   Descreva seus usuarios principais:
-
-   Usuario Principal:
-   > Funcao: _____
-   > Objetivo principal: _____
-
-   Usuario Secundario (opcional):
-   > Funcao: _____
-   > Objetivo principal: _____
-   ```
-
-4. **Requisitos de Conformidade**:
-   ```
-   Quais requisitos de conformidade se aplicam?
-   [ ] LGPD/GDPR (Protecao de dados)
-   [ ] HIPAA (Saude EUA)
-   [ ] PCI-DSS (Cartoes de pagamento)
-   [ ] SOC2 (Seguranca)
-   [ ] Nenhum / Nao aplicavel
-   ```
-
-**Perguntas Estendidas** (apenas com modo `--full`):
-
-5. **Objetivos de Negocio**:
-   ```
-   Objetivos de curto prazo (3-6 meses):
-   > _____
-
-   Objetivos de medio prazo (6-12 meses):
-   > _____
-   ```
-
-6. **Problemas Conhecidos/Divida Tecnica**:
-   ```
-   Ha problemas conhecidos ou divida tecnica a documentar?
-   > _____
-   ```
-
-7. **Termos do Glossario**:
-   ```
-   Termos de negocio chave para definir (separados por virgula):
-   > _____
-   ```
-
-### Fase 3: Gerar Arquivo de Contexto
-
-Criar `.claude/rules/00-project-context.md`:
-
-```markdown
-# Contexto do Projeto - {NOME_PROJETO}
-
-> Gerado automaticamente por `/common:setup-project-context` em {DATA}
-> Revisar e personalizar conforme necessario.
-
-## Modo Plano
-
-> **O modo plano é recomendado.** Claude ativa o modo plano para estruturar a abordagem, identificar dependências e apresentar uma estratégia de geração antes de criar artefatos.
-
-## Visao Geral
-
-**{NOME_PROJETO}** e uma aplicacao {TIPO} para o dominio {DOMINIO}.
-
-{DESCRICAO_DO_README_OU_USUARIO}
-
-## Stack Tecnico
-
-| Componente   | Tecnologia           |
-|--------------|----------------------|
-| Linguagem    | {LINGUAGEM}          |
-| Framework    | {FRAMEWORK}          |
-| Banco Dados  | {DATABASE}           |
-| Cache        | {CACHE_SE_DETECTADO} |
-| Testes       | {FRAMEWORKS_TESTE}   |
-| CI/CD        | {PLATAFORMA_CICD}    |
-
-## Estrutura do Projeto
-
-```
-{ESTRUTURA_DETECTADA}
-```
-
-## Dominio de Negocio
-
-### Conceitos Chave
-
-{ENTIDADES_SE_DETECTADAS}
-
-### Bounded Contexts
-
-<!-- Adicionar se usar DDD -->
-- Contexto 1: ...
-- Contexto 2: ...
-
-## Usuarios e Personas
-
-### {FUNCAO_USUARIO_PRINCIPAL}
-- **Objetivo:** {OBJETIVO_USUARIO_PRINCIPAL}
-- **Pontos de dor:** A documentar
-- **Fluxos chave:** A documentar
-
-### {FUNCAO_USUARIO_SECUNDARIO}
-- **Objetivo:** {OBJETIVO_USUARIO_SECUNDARIO}
-- **Pontos de dor:** A documentar
-- **Fluxos chave:** A documentar
-
-## Restricoes
-
-### Conformidade
-{REQUISITOS_CONFORMIDADE}
-
-### Metas de Desempenho
-- Tempo de carregamento da pagina: < 3s
-- Tempo de resposta da API: < 200ms
-- Disponibilidade: 99.9%
-
-### Requisitos de Seguranca
-- Conformidade OWASP Top 10
-- Validacao de entrada em todos os endpoints
-- Autenticacao necessaria para recursos protegidos
-
-## Objetivos
-
-### Curto prazo
-{OBJETIVOS_CURTO_PRAZO_OU_PLACEHOLDER}
-
-### Medio prazo
-{OBJETIVOS_MEDIO_PRAZO_OU_PLACEHOLDER}
-
-## Problemas Conhecidos / Divida Tecnica
-
-{PROBLEMAS_OU_PLACEHOLDER}
-
-## Glossario
-
-| Termo | Definicao |
-|-------|-----------|
-{TERMOS_GLOSSARIO_OU_EXEMPLOS}
-```
-
-### Fase 4: Validacao e Proximos Passos
-
-Exibir resumo e recomendacoes:
-
-```
-╔══════════════════════════════════════════════════════════════╗
-║              CONTEXTO DO PROJETO GERADO                       ║
-╚══════════════════════════════════════════════════════════════╝
-
-✅ Arquivo criado: .claude/rules/00-project-context.md
-
-Resumo:
-┌─────────────────┬────────────────────────────────┐
-│ Projeto         │ {NOME_PROJETO}                 │
-│ Tipo            │ {TIPO}                         │
-│ Stack           │ {FRAMEWORK} + {DATABASE}       │
-│ Dominio         │ {DOMINIO}                      │
-│ Conformidade    │ {CONFORMIDADE}                 │
-│ Personas        │ {QUANTIDADE} definidos         │
-└─────────────────┴────────────────────────────────┘
-
-📋 Proximos Passos Recomendados:
-
-1. Revisar arquivo gerado e completar secoes placeholder
-2. Adicionar bounded contexts detalhados se usar DDD
-3. Documentar fluxos de negocio chave
-4. Considerar executar agentes especializados:
-   - @database-architect → Documentar schema do banco de dados
-   - @api-designer → Documentar endpoints da API
-   - @security-reviewer → Revisar restricoes de seguranca
-
-Deseja que eu abra o arquivo para revisao?
-```
-
-## Modos
-
-| Modo | Comportamento |
-|------|---------------|
-| (padrao) | Detecao + perguntas essenciais (tipo, dominio, usuarios, conformidade) |
-| `--auto` | Detecao maxima, pular perguntas com padroes razoaveis |
-| `--full` | Todas as perguntas incluindo objetivos, problemas e glossario |
-
-## Exemplos
-
-```bash
-# Modo padrao - detecao e perguntas equilibradas
-/common:setup-project-context
-
-# Modo auto - interacao minima
-/common:setup-project-context --auto
-
-# Modo completo - questionario exaustivo
-/common:setup-project-context --full
-```
+Execute `/common:init --context $ARGUMENTS`: leia `.claude/commands/common/init.md` e siga-o com estes argumentos.

package/Dev/i18n/pt/Common/rules/12-context-management.md

@@ -386,7 +386,7 @@ Sessao 2: Implementacao (codificar, testar)
 O comando `/loop` permite agendar tarefas recorrentes:
 
 ```bash
-/loop 5m /common:pre-commit-check    # Verificar a cada 5 minutos
+/loop 5m /gate:check commit    # Verificar a cada 5 minutos
 /loop "Monitorar testes CI"           # Auto-cadencia pelo modelo
 ```
 

package/Dev/i18n/pt/QA/commands/fix.md

@@ -227,19 +227,19 @@ resume_from:
 
 ```bash
 # Corrigir todos os bugs de uma sessao recette
-/qa:recette-fix --session=REC-20260130-143022
+/qa:fix --session=REC-20260130-143022
 
 # Dry run: refinar e documentar sem corrigir
-/qa:recette-fix --session=REC-20260130-143022 --dry-run
+/qa:fix --session=REC-20260130-143022 --dry-run
 
 # Corrigir apenas bugs criticos e altos
-/qa:recette-fix --session=REC-20260130-143022 --severity=high
+/qa:fix --session=REC-20260130-143022 --severity=high
 
 # Gerar documentos BMAD sem lancar o TDD
-/qa:recette-fix --session=REC-20260130-143022 --skip-fix
+/qa:fix --session=REC-20260130-143022 --skip-fix
 
 # Corrigir com commit automatico
-/qa:recette-fix --session=REC-20260130-143022 --auto-commit
+/qa:fix --session=REC-20260130-143022 --auto-commit
 ```
 
 ## Estrutura de Saida
@@ -269,9 +269,9 @@ resume_from:
 | Comando | Descricao |
 |---------|-----------|
 | `/qa:recette` | Executar testes de aceitacao |
-| `/qa:recette-status` | Mostrar status da sessao |
-| `/qa:recette-regression` | Ver testes de regressao |
-| `/qa:recette-report` | Gerar relatorio |
+| `/qa:status` | Mostrar status da sessao |
+| `/qa:regression` | Ver testes de regressao |
+| `/qa:status --report` | Gerar relatorio |
 
 ## Mensagens de Erro
 

package/Dev/i18n/pt/QA/commands/recette.md

@@ -214,12 +214,11 @@ entries:
 
 | Comando | Descricao |
 |---------|-----------|
-| `/qa:recette-fix` | Corrigir bugs de uma sessao |
-| `/qa:recette-status` | Mostrar status da sessao |
-| `/qa:recette-regression` | Ver testes de regressao |
-| `/qa:recette-report` | Gerar relatorio |
-| `/qa:validate` | Validar AC de uma story |
-| `/qa:automate` | Criar testes automatizados |
+| `/qa:fix` | Corrigir bugs de uma sessao |
+| `/qa:status` | Mostrar status da sessao |
+| `/qa:regression` | Ver testes de regressao |
+| `/qa:status --report` | Gerar relatorio |
+| `/gate:check story` | Validar AC de uma story |
 
 ## Capacidades do Chrome
 
@@ -262,9 +261,9 @@ entries:
 ║    Correção com abordagem TDD                            ║
 ║                                                          ║
 ║  Se todos os testes passam:                              ║
-║  → /qa:report                                            ║
+║  → /qa:status --report                                            ║
 ║    Gerar o relatório de recette                          ║
-║  → /sprint:transition done                               ║
+║  → /project:backlog move story done                               ║
 ║    Marcar a story como concluída                         ║
 ║                                                          ║
 ╚══════════════════════════════════════════════════════════╝