jarvis-ai-framework 7.0.0 → 8.2.0

package/AGENTS.md

@@ -255,7 +255,7 @@ Cada pasta pode ter seu proprio AGENTS.md com instrucoes especificas:
 /eng.plan "feature"      # Plano de execucao faseado (somente planejamento)
 /eng.work "feature"      # Implementacao e testes (commit por fase, sem push/PR)
 /eng.pre-pr              # Validacao pre-PR
-/eng.pr                  # Cria branch, commit e PR
+/eng.pr                  # Push e PR, depois da pergunta (regra de ouro)
 ```
 
 ### Documentacao
@@ -285,7 +285,7 @@ Tabela completa de mapeamento comando/trigger → skill: ver `$IDE/skills/AGENTS
 |------|---------|-----------|
 | Planejamento | `eng.start`, `eng.plan` | Somente analise, sem codigo |
 | Implementacao | `eng.work` | Codigo e testes, commit por fase, sem push nem PR |
-| Entrega | `eng.pr` | Branch, commit e PR |
+| Entrega | `eng.pr` | Push e PR, depois da pergunta (regra de ouro) |
 
 ---
 

package/README.md

@@ -14,18 +14,13 @@
 
 ### 1. Instale
 
-Global (comando `jarvis` no PATH):
+O Jarvis é instalado **só global** (comando `jarvis` no PATH):
 
 ```bash
 npm install -g jarvis-ai-framework
 ```
 
-**Só neste workspace** (não sobe no PATH):
-
-```bash
-cd workspace-squad/
-npm install jarvis-ai-framework --save-dev
-```
+Não instale o pacote dentro do projeto: o `jarvis init` roda **dentro do projeto** e copia os assets do Jarvis global para a pasta da IDE. Se ele achar uma cópia local (`node_modules` ou dependência no `package.json`), avisa que ela é ignorada.
 
 Confira **onde** o binário ficou no PATH (útil se houver mais de uma instalação):
 
@@ -42,8 +37,6 @@ jarvis --version
 jarvis init --ide cursor
 ```
 
-Se instalou só com `--save-dev`, use `npx jarvis init --ide cursor`.
-
 IDEs: `windsurf` · `claude` · `cursor` · `codex` · `opencode` · `gemini` · `kiro`
 
 ### 3. No chat da IDE
@@ -76,13 +69,6 @@ Global (comando `jarvis` no PATH):
 npm install -g /caminho/para/jarvis
 ```
 
-**Só neste workspace** (não sobe no PATH):
-
-```bash
-cd workspace-squad/
-npm install /caminho/para/jarvis --save-dev
-```
-
 **`npm link`** (útil se você altera o clone e quer refletir na hora):
 
 ```bash
@@ -90,12 +76,7 @@ cd /caminho/para/jarvis
 npm link
 ```
 
-Isso já registra o comando `jarvis` no global. Opcional, para o workspace resolver o pacote:
-
-```bash
-cd workspace-squad/
-npm link jarvis-ai-framework
-```
+Isso já registra o comando `jarvis` no global. Não rode `npm link jarvis-ai-framework` dentro do workspace: isso cria uma cópia local em `node_modules`, que o `jarvis init` ignora (e avisa).
 
 Confira **onde** o binário ficou no PATH (útil se houver mais de uma instalação):
 
@@ -119,7 +100,9 @@ npm install -g jarvis-ai-framework@latest
 jarvis init --upgrade --ide {ide}   # assets + variáveis novas do ENV.md + documentos para as pastas novas
 ```
 
-Depois, na IDE, rode `/jarvis-init upgrade`: ele vai direto ao Upgrade (C) e cuida do que precisa de conversa (Central docs antigo e o passo das stacks). O `--upgrade` só **acrescenta** chaves ao `ENV.md`: nenhuma chave existente muda. Ele mostra os documentos que estão em caminhos antigos e pergunta antes de movê-los (`--yes` move sem perguntar; sem terminal interativo, não move). Também lista os skills instalados que saíram do framework e pergunta antes de removê-los (`--remove-stale` remove sem perguntar só os listados; skills registrados em `*_SPECIALIZATIONS` nunca são listados).
+`jarvis init --ide {ide}` numa pasta já instalada mostra o menu **Atualizar** (Enter, o mesmo que o `--upgrade`) / **Reinstalar** (o mesmo que o `--force`) / **Cancelar**, com a versão instalada e a do pacote. No fim, ele só manda rodar o `/jarvis-init upgrade` quando há pendência.
+
+Na IDE, o `/jarvis-init upgrade` vai direto ao Upgrade (C), cuida do que precisa de conversa (Central docs antigo e o passo das stacks) e, no fim, valida o `ENV.md` inteiro: pergunta cada problema e regrava o arquivo separado por assunto, na ordem do template. O `--upgrade` só **acrescenta** chaves ao `ENV.md`, no fim do arquivo: nenhuma chave existente muda. Ele mostra os documentos que estão em caminhos antigos e pergunta antes de movê-los (`--yes` move sem perguntar; sem terminal interativo, não move). Também lista os skills instalados que saíram do framework e pergunta antes de removê-los (`--remove-stale` remove sem perguntar só os listados; skills registrados em `*_SPECIALIZATIONS` nunca são listados).
 
 **Instalou via clone local** (fluxo de [Desenvolvendo o Jarvis localmente](#desenvolvendo-o-jarvis-localmente)) — quando o repo no GitHub ganhar commits novos, sincronize assim:
 
@@ -137,12 +120,6 @@ git pull
 npm install -g /caminho/para/jarvis
 ```
 
-**Só no workspace (`--save-dev`):**
-```bash
-cd workspace-squad/
-npm install /caminho/para/jarvis --save-dev
-```
-
 **Com `npm link`:** o `git pull` no clone já basta — o link aponta para a pasta.
 
 Antes de seguir, confira se o `jarvis` do PATH é o que você acabou de atualizar:
@@ -164,7 +141,7 @@ jarvis init --ide cursor
 
 Isso copia de novo `agents/`, `skills/`, `workflows/`, `rules/`, `templates/` para `.$IDE/` e atualiza o `jarvis-lock.json`.
 
-Se o workspace usa `--save-dev` e já tem `jarvis-lock.json`, o `npm install` do passo 2 também dispara o **postinstall** e sincroniza sozinho para a IDE do lock.
+Esse é o único caminho de atualização dos assets: o `npm install -g` não sincroniza nenhum projeto sozinho. Quando os assets do projeto estão atrás do Jarvis global, o `/jarvis-init` avisa no início e oferece o `jarvis init --upgrade`.
 
 ### 4. ENV.md (só se houver variáveis novas)
 
@@ -183,8 +160,8 @@ Escolha **Upgrade (C)** — adiciona chaves novas do template sem apagar os valo
 | Passo | O que muda |
 |-------|------------|
 | `git pull` | Código do framework no clone |
-| `npm install -g` / `--save-dev` | Binário `jarvis` + pacote que o `init` lê |
-| `jarvis init` (ou postinstall com lock) | Arquivos em `.$IDE/` (skills, agents, workflows…) e o Context7 no arquivo de MCP da IDE (ex.: `.mcp.json` no Claude Code; só acrescenta, sem apagar outros servidores) |
+| `npm install -g` | Binário `jarvis` + pacote que o `init` lê |
+| `jarvis init` | Arquivos em `.$IDE/` (skills, agents, workflows…) e o Context7 no arquivo de MCP da IDE (ex.: `.mcp.json` no Claude Code; só acrescenta, sem apagar outros servidores) |
 | `/jarvis-init` Upgrade | Só `$IDE/ENV.md` (variáveis faltantes) e, se você aceitar o passo opcional "adicionar as stacks", as listas de especializações |
 
 `ENV.md`, `.jarvis/sessions/` e o `.gitignore` do workspace **não** são sobrescritos pelo sync de assets. O `.gitignore` só é criado ou alterado quando a raiz tem `.git`; sem `.git` (como no modo workspace) a raiz não é versionada e o init não o toca.
@@ -212,7 +189,7 @@ O `/jarvis-init` pergunta o `ARTIFACT_STYLE` (variável do `ENV.md`):
 | Valor | O que acontece |
 |---|---|
 | `ai-generated` (padrão) | Como sempre: metadados, links de rastreabilidade e padrões da ferramenta |
-| `human-generated` | Nada do que o Jarvis publica (commit, PR/MR, comentário no card, issue) leva marca de IA ou da IDE: o `/eng.pr` confere e limpa antes do push. Todo documento gerado pergunta, no fim, se você quer a versão humanizada, gravada ao lado como `{nome}.public.md` para repassar a clientes ou stakeholders |
+| `human-generated` | Nada do que o Jarvis publica (commit, PR/MR, comentário no card, issue; sempre depois da pergunta) leva marca de IA ou da IDE: o `/eng.pr` confere e limpa antes do push. Todo documento gerado pergunta, no fim, se você quer a versão humanizada, gravada ao lado como `{nome}.public.md` para repassar a clientes ou stakeholders |
 
 Com `human-generated`, o `/jarvis-init` copia a rule `rules/artifact-style-rules.md` (eixo `ARTIFACT_STYLE` do `Applies to`); com `ai-generated`, ela nem existe na sessão. Trocou o valor à mão? Rode `/jarvis-init upgrade`.
 
@@ -253,6 +230,6 @@ Precisa de ajuda?
 - **Engenharia (um guia por comando `eng.*`)** — [`docs/engenharia/`](docs/engenharia/README.md)
 - **Indice de docs/** — [`docs/README.md`](docs/README.md)
 - **Instrucoes para agentes / mapa de skills** — `AGENTS.md`
-- **Issues/Feedback** — skill `jarvis-report-issue` (sem a CLI do host (`gh`), sem login ou sem rede, o issue fica em `.jarvis/issues/issue-{desc}.md` para abrir à mão)
+- **Issues/Feedback** — skill `jarvis-report-issue` (pergunta antes de abrir; sem a CLI do host (`gh`), sem login, sem rede ou com o seu Não, a issue fica em `.jarvis/issues/issue-{desc}.md` para abrir à mão)
 - **Duvidas sobre comandos** — Pergunte diretamente ao agent:
   `"Como funciona /eng.start?"` | `"Qual a diferenca entre /eng.work e /pr?"` | `"O que e CDD?"`

package/agents/engineering/data/eng.data-engineer.agent.md

@@ -66,7 +66,7 @@ Ativado quando há suspeita de dado incorreto, queda de volume ou falha de pipel
 - Identificar causa raiz: fonte, transformação ou carga
 - Verificar logs de execução e checks de qualidade
 - Propor correção e plano de reprocessamento idempotente
-- Alertar squads afetadas com contexto claro
+- Alertar squads afetadas com contexto claro (mostrando a mensagem e perguntando antes de enviar, regra de ouro)
 
 **Skill integrada**: `$IDE/skills/eng-data/SKILL.md` + `DATA_SPECIALIZATIONS`
 
@@ -126,7 +126,7 @@ CONTEXT_PROFILE:
 
 | Sinal | Urgência | Comportamento |
 |-------|----------|---------------|
-| `dado errado em produção`, `dashboard parado`, `pipeline falhou` | **CRÍTICA** | Fast track: diagnóstico imediato, isolar causa, comunicar squads afetadas |
+| `dado errado em produção`, `dashboard parado`, `pipeline falhou` | **CRÍTICA** | Fast track: diagnóstico imediato, isolar causa, comunicar squads afetadas (texto pronto; o envio só depois da pergunta, regra de ouro) |
 | `atraso`, `dado desatualizado`, `queda de volume` | **ALTA** | Investigação ágil, reprocessar com idempotência |
 | `nova feature`, `novo pipeline`, `contrato de dados` | **NORMAL** | Fluxo completo: documentar antes, implementar, validar |
 | `melhoria`, `refactoring de query`, `otimização` | **BAIXA** | Análise cuidadosa de impacto antes de qualquer mudança |
@@ -226,7 +226,7 @@ Para detecção automática de contexto de tarefas:
 ### 3. Qualidade e Monitoramento
 
 - Bloquear promoção de camada quando falha de qualidade ocorre
-- Alertar no canal do time de Data quando falha afeta `gold`
+- Alertar no canal do time de Data quando falha afeta `gold` (depois da pergunta, regra de ouro; o alerta automático de pipeline é do runtime)
 - Manter tabela `gold.pipeline_audit` com metadados de execução
 
 ### 4. Política de Dados Sensíveis

package/agents/engineering/eng.agent.md

@@ -175,20 +175,26 @@ Para detecção automática de contexto de tarefas:
 - Uso: `/jarvis-context-detect [jira-key]` ou `/jarvis-context-detect --override tipo=hotfix`
 - Chamado automaticamente pelo workflow `eng.start`
 
-### eng-platform (performance)
-Quando a tarefa envolver análise ou otimização de performance, observabilidade, gargalos, latência, load testing, chaos engineering ou cache multi-camada — temas 7, 14, 15 e 16 da base de platform:
+### eng-platform
+Quando a tarefa envolver infraestrutura, performance ou segurança de infraestrutura — base de platform, complementada pela especialização registrada em `PLATFORM_SPECIALIZATIONS`:
 - Arquivo: `$IDE/skills/eng-platform/SKILL.md`
+- Performance: análise ou otimização de performance, observabilidade, gargalos, latência, load testing, chaos engineering ou cache multi-camada (temas 7, 14, 15 e 16)
+- Segurança: segurança de infraestrutura, fundamentos de segurança da informação (risco, ameaças, identidade, resposta a incidente, GRC, privacidade) ou auditoria de dependências/supply chain (temas 9 e 13)
+- Segurança de código de aplicação (OWASP, inputs, auth) já é padrão embutido em `eng-backend`/`eng-frontend`
 
 ### eng-ai
 Quando a tarefa envolver features com LLM, sistemas RAG, agentes de IA, chatbots, embeddings, busca vetorial ou integrações com modelos de IA:
 - Arquivo: `$IDE/skills/eng-ai/SKILL.md`
 
-### Backend e frontend (skill base + especializações)
-Quando a tarefa envolver **backend** (APIs, autenticação, workers e jobs assíncronos, filas e mensageria, integrações externas, cache, banco de dados) ou **frontend** (componentes, estado, estilos, performance de UI, acessibilidade, testes de interface), não escolha o skill por nome: aplique a regra `$IDE/rules/engineering/eng.specializations-rules.md` para a área envolvida. Ela carrega o skill base e as especializações que o projeto registrou no `ENV.md`:
-- Backend: `$IDE/skills/eng-backend/SKILL.md` + itens de `BACKEND_SPECIALIZATIONS`
-- Frontend: `$IDE/skills/eng-frontend/SKILL.md` + itens de `FRONTEND_SPECIALIZATIONS`
+### eng-backend
+Quando a tarefa envolver backend (APIs, autenticação, workers e jobs assíncronos, filas e mensageria, integrações externas, cache, banco de dados). Não escolha o skill por nome: aplique a regra `$IDE/rules/engineering/eng.specializations-rules.md` para a área backend, que carrega o skill base e as especializações de `BACKEND_SPECIALIZATIONS` do `ENV.md`:
+- Arquivo: `$IDE/skills/eng-backend/SKILL.md`
 - Workflows relacionados: `eng.start` (arquitetura), `eng.work` (implementação), `eng.debug` (troubleshooting)
-- Para ver o que está instalado e registrado: `/jarvis-list-specializations`
+
+### eng-frontend
+Quando a tarefa envolver frontend (componentes, estado, estilos, performance de UI, acessibilidade, testes de interface). Não escolha o skill por nome: aplique a regra `$IDE/rules/engineering/eng.specializations-rules.md` para a área frontend, que carrega o skill base e as especializações de `FRONTEND_SPECIALIZATIONS` do `ENV.md`:
+- Arquivo: `$IDE/skills/eng-frontend/SKILL.md`
+- Para ver o que está instalado e registrado (backend e frontend): `/jarvis-list-specializations`
 
 ### eng-automation
 Quando a tarefa envolver web scraping, extração de dados de páginas web, automação de browser com Puppeteer, parsing de HTML/XML/PDF, pipelines ETL leves ou monitoramento de mudanças em sites:
@@ -200,10 +206,6 @@ Quando precisar planejar estratégia de testes, validar fluxos completos de usu
 - Arquivo: `$IDE/skills/eng-qa/SKILL.md`
 - Workflows relacionados: `eng.pr` (validação pré-PR), `eng.pre-pr` (cobertura de testes E2E)
 
-### eng-platform
-Quando a tarefa envolver segurança de infraestrutura, fundamentos de segurança da informação (risco, ameaças, identidade, resposta a incidente, GRC, privacidade) ou auditoria de dependências/supply chain — base de platform, complementada pela especialização registrada em `PLATFORM_SPECIALIZATIONS`:
-- Arquivo: `$IDE/skills/eng-platform/SKILL.md` (temas 9 e 13)
-- Segurança de código de aplicação (OWASP, inputs, auth) já é padrão embutido em `eng-backend`/`eng-frontend`
 
 ---
 

package/agents/engineering/eng.dev-code-reviewer.md

@@ -6,18 +6,18 @@ model: opus
 color: green
 ---
 
-# code-reviewe
+# code-reviewer
 Você é um especialista em revisão de código responsável por analisar mudanças de código em preparação para a abertura de um Pull Request.
 Seu objetivo é fornecer feedback abrangente e acionável, ajudando a garantir qualidade de código e prontidão para PR.
 
 Processo de Revisão
 1. Coleta de Informações sobre as Mudanças
-Primeiro, entenda exatamente o que foi alterado:
+Primeiro, entenda exatamente o que foi alterado (`{BRANCH_BASE}` é a branch base recebida de quem chama (o `/eng.pre-pr` passa a `Branch base:` do `architecture.md`); sem ela, `origin/main`.):
  - Execute git status para verificar mudanças não commitadas
  - Execute git diff para visualizar mudanças não staged
  - Execute git diff --staged para visualizar mudanças staged
- - Execute git log origin/main..HEAD --oneline para ver os commits da branch atual
- - Execute git diff origin/main...HEAD para ver todas as mudanças comparadas com a branch principal
+ - Execute git log {BRANCH_BASE}..HEAD --oneline para ver os commits da branch atual
+ - Execute git diff {BRANCH_BASE}...HEAD para ver todas as mudanças comparadas com a branch base
 
 2. Análise das Mudanças de Código
 Para cada arquivo alterado, avalie:
@@ -71,6 +71,21 @@ Avalie os testes:
 
 Nenhuma — agente autocontido, não depende de skill
 
+## Quando chamado pelo `/eng.pre-pr`
+
+O `/eng.pre-pr` passa a branch base (a `Branch base:` do `architecture.md`) e, da rodada 2 em diante, o diff incremental desde a rodada anterior. Use essa base no lugar de `origin/main` nos comandos de diff e log. Só aponte: não edite nem grave arquivos.
+
+Devolva uma lista de lacunas, uma por item, com os campos da tabela de lacunas do `gate-checklist.md`:
+
+- **Lacuna**: o que falta ou está errado, terminando com "(item 2)", o número deste gate na lista do `/eng.pre-pr`.
+- **Onde**: `arquivo:linha` com o trecho, ou o comando que a revelou e o resultado.
+- **Por que importa**: o impacto, em linguagem simples.
+- **Refutação**: o que derrubaria esta lacuna, com o lugar a conferir.
+- **Sugestão**: como resolver.
+- **Severidade**: 🔴 Bloqueador, 🟡 Importante ou ⚪ Menor (redação é ⚪).
+
+Lista vazia é uma resposta válida. Fora do `/eng.pre-pr`, vale o formato de resposta deste arquivo.
+
 ## Formato da Resposta
 Forneça uma revisão estruturada no seguinte formato:
 

package/agents/engineering/eng.docs-consolidator.agent.md

@@ -15,7 +15,7 @@ tools: Read, Glob, Grep, Bash, Write, Edit
 
 Você transforma o que foi **implementado** num registro que dure. Duas pessoas vão ler o que você escreve:
 - **humanos:** outro squad, alguém novo no time, a própria pessoa daqui a seis meses;
-- **IAs:** o `/warm-up`, o `/eng.start` e os `/prod.spec.*` consultam o Central docs como verdade sobre o sistema.
+- **IAs:** o `/warm-up`, o `/eng.start` e os `/prod.spec.*` consultam o Central docs como verdade sobre o que está implementado.
 
 Por isso o texto tem de ser **completo, autossuficiente e sem ambiguidade**.
 
@@ -46,7 +46,7 @@ Por isso o texto tem de ser **completo, autossuficiente e sem ambiguidade**.
 4. `git log {base}..HEAD --format='%h|%an|%ad|%s' --date=short` e `git diff --stat {base}...HEAD`.
 5. O código alterado, só leitura, para confirmar o comportamento real.
 6. O documento atual da funcionalidade no Central docs (`jarvis docs fetch`), quando for atualização.
-7. O `gate-checklist.md` e o `pull-request.md` da sessão, se existirem.
+7. O `gate-checklist.md` (a rodada mais recente; as anteriores, `gate-checklist-rodada-{N}.md`, são histórico) e o `pull-request.md` da sessão, se existirem.
 
 ## O que você produz
 

package/agents/engineering/eng.docs-writer.md

@@ -17,6 +17,21 @@ Fonte de verdade do processo e do formato de entrega da documentação:
 
 ---
 
+## Quando chamado pelo `/eng.pre-pr`
+
+O `/eng.pre-pr` passa a branch base (a `Branch base:` do `architecture.md`) e, da rodada 2 em diante, o diff incremental desde a rodada anterior. Use essa base no lugar de `origin/main` nos comandos de diff e log. Só aponte: não edite nem grave arquivos. Não proponha aplicar as atualizações nem pergunte se deve aplicá-las: cada documentação desatualizada vira uma lacuna.
+
+Devolva uma lista de lacunas, uma por item, com os campos da tabela de lacunas do `gate-checklist.md`:
+
+- **Lacuna**: o que falta ou está errado, terminando com "(item 9)", o número deste gate na lista do `/eng.pre-pr`.
+- **Onde**: `arquivo:linha` com o trecho, ou o comando que a revelou e o resultado.
+- **Por que importa**: o impacto, em linguagem simples.
+- **Refutação**: o que derrubaria esta lacuna, com o lugar a conferir.
+- **Sugestão**: como resolver.
+- **Severidade**: 🔴 Bloqueador, 🟡 Importante ou ⚪ Menor (redação é ⚪).
+
+Lista vazia é uma resposta válida. Fora do `/eng.pre-pr`, vale o formato de resposta deste arquivo.
+
 ## Fluxo de Trabalho
 
 ### 1. Analisar Mudanças de Código
@@ -26,8 +41,8 @@ Comece entendendo exatamente o que mudou:
 - Execute `git status` para verificar mudanças não commitadas
 - Execute `git diff` para visualizar mudanças não staged
 - Execute `git diff --staged` para visualizar mudanças staged
-- Execute `git log origin/main..HEAD --oneline` para ver os commits da branch
-- Execute `git diff origin/main...HEAD` para ver todas as mudanças da branch
+- Execute `git log {BRANCH_BASE}..HEAD --oneline` para ver os commits da branch
+- Execute `git diff {BRANCH_BASE}...HEAD` para ver todas as mudanças da branch (`{BRANCH_BASE}` é a branch base recebida de quem chama (o `/eng.pre-pr` passa a `Branch base:` do `architecture.md`); sem ela, `origin/main`.)
 
 Foque especialmente em:
 - Novas funcionalidades

package/agents/engineering/qa/eng.qa.quality-champion-task-agent.md

@@ -39,7 +39,7 @@ Você opera estritamente dentro do **contexto de tarefas Jira e especificações
    - Casos extremos não cobertos
    - Riscos potenciais, ambiguidades ou complexidade oculta
 
-5. Comentar melhorias diretamente no Jira:
+5. Comentar melhorias no Jira pelo `/eng-global-task-comment`, que mostra o texto e pergunta antes de enviar (regra de ouro, `eng.integrations-rules.md`):
    - Sugerir redação mais clara
    - Propor critérios de aceitação faltantes
    - Recomendar cenários de teste adicionais
@@ -54,7 +54,7 @@ Você opera estritamente dentro do **contexto de tarefas Jira e especificações
 
 ### Formato de Saída (Sempre Estruturado)
 
-Use o seguinte formato em comentários Jira:
+Use o seguinte formato nos comentários Jira (eles só saem depois da pergunta, regra de ouro):
 
 **Resumo da Revisão de Qualidade**
 

package/agents/engineering/qa/eng.qa.test-planner.md

@@ -21,10 +21,25 @@ Aplicar quando invocado via `eng.qa-refinement-entry` ou quando o argumento rece
 
 **Modo B — Análise de Cobertura (pós-código)**
 Aplicar quando invocado via `eng-qa`, `eng-qa-planner` ou quando houver código implementado na branch (git diff retorna resultados).
-- Fonte de dados: `git diff origin/main...HEAD`
+- Fonte de dados: `git diff {BRANCH_BASE}...HEAD` (`{BRANCH_BASE}` é a branch base recebida de quem chama (o `/eng.pre-pr` passa a `Branch base:` do `architecture.md`); sem ela, `origin/main`.)
 - Saída: `$ENG_DOCS/qa/{task-id}-test_coverage_branch_report.md`
 
-Regra de decisão: se `git diff origin/main...HEAD` retornar vazio, operar em Modo A. Se retornar código, operar em Modo B.
+Regra de decisão: se `git diff {BRANCH_BASE}...HEAD` retornar vazio, operar em Modo A. Se retornar código, operar em Modo B.
+
+## Quando chamado pelo `/eng.pre-pr`
+
+O `/eng.pre-pr` passa a branch base (a `Branch base:` do `architecture.md`) e, da rodada 2 em diante, o diff incremental desde a rodada anterior. Use essa base no lugar de `origin/main` nos comandos de diff e log. Só aponte: não edite nem grave arquivos. É o Modo B, mas sem gravar o relatório em `$ENG_DOCS/qa/`: as lacunas voltam só na resposta.
+
+Devolva uma lista de lacunas, uma por item, com os campos da tabela de lacunas do `gate-checklist.md`:
+
+- **Lacuna**: o que falta ou está errado, terminando com "(item 3)", o número deste gate na lista do `/eng.pre-pr`.
+- **Onde**: `arquivo:linha` com o trecho, ou o comando que a revelou e o resultado.
+- **Por que importa**: o impacto, em linguagem simples.
+- **Refutação**: o que derrubaria esta lacuna, com o lugar a conferir.
+- **Sugestão**: como resolver.
+- **Severidade**: 🔴 Bloqueador, 🟡 Importante ou ⚪ Menor (redação é ⚪).
+
+Lista vazia é uma resposta válida. Fora do `/eng.pre-pr`, vale o formato de resposta deste arquivo.
 
 ## Skills Disponíveis
 
@@ -290,9 +305,9 @@ Usar quando: invocado via `eng-qa` ou `eng-qa-planner`, ou quando git diff retor
 
 Comece entendendo o que mudou na branch atual:
 
-- Execute `git diff origin/main...HEAD --name-only` para listar todos os arquivos alterados
-- Execute `git diff origin/main...HEAD` para ver as mudanças em detalhe
-- Execute `git log origin/main..HEAD --oneline` para entender o histórico de commits
+- Execute `git diff {BRANCH_BASE}...HEAD --name-only` para listar todos os arquivos alterados
+- Execute `git diff {BRANCH_BASE}...HEAD` para ver as mudanças em detalhe
+- Execute `git log {BRANCH_BASE}..HEAD --oneline` para entender o histórico de commits
 - Foque especialmente em:
   - Novas funções/métodos/classes
   - Lógica modificada em código existente

package/agents/product/prod.pm-checker.md

@@ -28,7 +28,7 @@ Em seguida, você deve:
   - quais mudanças não estão alinhadas.
 
 Formato da Resposta
-Você deve fornecer sua resposta exatamente no seguinte formato:
+Você deve fornecer sua resposta exatamente no seguinte formato (quando chamado pelo `/eng.pre-pr`, use o formato da seção "Quando chamado pelo `/eng.pre-pr`"):
 
 ```
 [nome da branch]
@@ -51,6 +51,21 @@ Você deve fornecer sua resposta exatamente no seguinte formato:
 Regras Importantes
 Não faça nenhuma alteração no código ou nos requisitos, a menos que o usuário solicite explicitamente. Seu papel é avaliar e reportar, não corrigir.
 
+## Quando chamado pelo `/eng.pre-pr`
+
+O `/eng.pre-pr` passa a branch base (a `Branch base:` do `architecture.md`) e, da rodada 2 em diante, o diff incremental desde a rodada anterior. Use essa base no lugar de `origin/main` nos comandos de diff e log. Só aponte: não edite nem grave arquivos. Compare as mudanças com os documentos do projeto (os "Master Docs") como descrito acima.
+
+Devolva uma lista de lacunas, uma por item, com os campos da tabela de lacunas do `gate-checklist.md`:
+
+- **Lacuna**: o que falta ou está errado, terminando com "(item 1)", o número deste gate na lista do `/eng.pre-pr`.
+- **Onde**: `arquivo:linha` com o trecho, ou o comando que a revelou e o resultado.
+- **Por que importa**: o impacto, em linguagem simples.
+- **Refutação**: o que derrubaria esta lacuna, com o lugar a conferir.
+- **Sugestão**: como resolver.
+- **Severidade**: 🔴 Bloqueador, 🟡 Importante ou ⚪ Menor (redação é ⚪).
+
+Lista vazia é uma resposta válida. Fora do `/eng.pre-pr`, vale o formato de resposta deste arquivo.
+
 ## Skills Disponíveis
 
 Nenhuma — agente autocontido, não depende de skill

package/bin/README.md

@@ -7,11 +7,11 @@ Fonte do binário `jarvis` (instalado via `npm install -g jarvis-ai-framework`,
 ```
 bin/
 ├── jarvis.js                  # Entrypoint (shebang). ~10 linhas, não cresce.
-├── postinstall.js             # Roda no `npm install` (sincroniza assets se já havia .{ide}/ no cwd)
+├── postinstall.js             # Roda no `npm install` (só imprime as dicas de uso)
 ├── commands/                  # Um arquivo por comando. Lógica pura, zero commander.
 │   ├── init.js, list.js, info.js, whoami.js, ...
 │   ├── docs-sync.js, docs-publish.js
-│   └── qa-signoff.js, install-rtk.js, tokens.js, map.js
+│   └── install-rtk.js, tokens.js, map.js
 └── lib/
     ├── cli/
     │   ├── program.js         # Único lugar que monta o commander — ver "Arquitetura"
@@ -119,12 +119,12 @@ if (fileURLToPath(import.meta.url) === process.argv[1]) {
 
 ## Variáveis de ambiente lidas diretamente (fora do ENV.md)
 
-`bin/lib/tasks/comment.js` e `bin/lib/vcs/*.js` leem `process.env` direto (`TASK_MANAGER`, `TASK_MANAGER_ACCESS`, `TASK_MANAGER_URL_BASE`, `VERSION_CONTROL`, etc.; nenhum token: o login é o da CLI do vendor) — não passam pelo `env-loader.js`/ENV.md. O `jarvis tasks comment` e o `jarvis vcs create-merge` completam o que faltar no ambiente lendo o `$IDE/ENV.md` do workspace (`readFileEnv`/`resolveFileEnv` em `integrations/cli-runner.js`, com `--ide`/`--env-file`; o ambiente do processo vence; `setting` tira aspas e comentário de fim de linha), então os skills não precisam exportar nada nem usar `eval`. O `accessGate` decide antes de qualquer envio: só `cli` (ou vazio, com aviso) segue; `manual`, valor inválido e ENV.md ilegível saem com 3. O ENV.md lido é repassado ao `createMergeRequest` (`fileEnvResult`), inclusive pelo Central docs. Se um comando novo precisar ler o `ENV.md` diretamente, use `env-loader.js#resolveEnvPath`/`loadEnv` (ver `whoami.js`, `tokens.js`, `qa-signoff.js` como exemplo) em vez de `process.env`.
+`bin/lib/tasks/comment.js` e `bin/lib/vcs/*.js` leem `process.env` direto (`TASK_MANAGER`, `TASK_MANAGER_ACCESS`, `TASK_MANAGER_URL_BASE`, `VERSION_CONTROL`, etc.; nenhum token: o login é o da CLI do vendor) — não passam pelo `env-loader.js`/ENV.md. O `jarvis tasks comment` e o `jarvis vcs create-merge` completam o que faltar no ambiente lendo o `$IDE/ENV.md` do workspace (`readFileEnv`/`resolveFileEnv` em `integrations/cli-runner.js`, com `--ide`/`--env-file`; o ambiente do processo vence; `setting` tira aspas e comentário de fim de linha), então os skills não precisam exportar nada nem usar `eval`. O `accessGate` decide antes de qualquer envio: só `cli` (ou vazio, com aviso) segue; `manual`, valor inválido e ENV.md ilegível saem com 3. O ENV.md lido é repassado ao `createMergeRequest` (`fileEnvResult`), inclusive pelo Central docs. Se um comando novo precisar ler o `ENV.md` diretamente, use `env-loader.js#resolveEnvPath`/`loadEnv` (ver `whoami.js` e `tokens.js` como exemplo) em vez de `process.env`.
 
 ## Testes
 
 - `npm run test:comandos` — valida que toda referência a comando/skill nos workflows e skills existe de fato (não testa o CLI em runtime).
-- `npm run test:filtro` — testes unitários de `profile-filter.js`, `token-report.js`, `flow-map`, `env-loader.js`, `sync-engine.js`, `vcs/api.js`, `tasks/comment.js`, `integrations/` (catálogo e runner) e do upgrade.
+- `npm run test:filtro` — testes unitários de `profile-filter.js`, `token-report.js`, `flow-map`, `env-loader.js`, `sync-engine.js`, `vcs/api.js`, `tasks/comment.js`, `integrations/` (catálogo e runner) e do upgrade, além dos testes que guardam o texto de workflows e rules (por exemplo, `gate-checklist-rodadas`, `publish-comments-rules` e `pre-pr-criterio`). A lista completa é o script `test:filtro` do `package.json`.
 - Não há teste automatizado de ponta a ponta do CLI (`jarvis <comando>` real) — a camada de dispatch (`program.js`, `bin/commands/*.js`) não é cobrida pelos testes unitários. Qualquer mudança ali precisa de validação manual dos comandos afetados.
 
 ### Como testar código que lê `fs`/rede sem mockar módulo