jarvis-ai-framework 7.0.0 → 8.2.0

package/workflows/engineering/eng.pre-pr.md

@@ -45,25 +45,27 @@ Antes de abrir o PR/MR, este comando **revê a branch atrás de possíveis lacun
 | Skills recomendados | `/jarvis-docs-index` | Se for necessário atualizar o índice de documentação |
 | Skills recomendados | `/eng-platform` + `PLATFORM_SPECIALIZATIONS` | Se a feature tiver requisitos não-funcionais de latência, throughput ou escalabilidade |
 | Skills recomendados | `/eng-backend` e `/eng-frontend` (via `eng.specializations-rules.md`) | Para validar código de backend (endpoints, autenticação, workers) ou de frontend (componentes, performance de UI, WCAG 2.1 AA); a regra também carrega as especializações registradas no ENV.md |
-| Gates › item 1 | `prod.pm-checker` (agente) | Sempre — verificar alinhamento da branch com os docs de produto e engenharia |
-| Gates › item 2 | `eng.dev-code-reviewer` (agente) | Sempre — revisar o código antes de lançar |
-| Gates › item 3 | `eng.qa.test-planner` (agente) | Sempre — identificar gaps de cobertura de testes na branch |
-| Gates › item 5 | `eng.qa.test-architect` (agente) | Se a feature tiver requisitos não-funcionais (no `architecture.md` ou explícitos na task) |
-| Gates › item 6 | `/eng-qa` + `QA_SPECIALIZATIONS` | Sempre — frontend e/ou backend conforme o projeto |
-| Gates › item 7 | `eng.frontend.agent` (agente) | Se a branch tiver mudanças de interface (componentes, estilos, estado) |
-| Gates › item 8 | `eng.ux-designer.agent` (agente) | Se a branch introduzir nova feature de UI ou alterar fluxo de usuário |
-| Gates › item 9 | `eng.docs-writer` (agente) | Sempre — apontar documentação do projeto desatualizada (sem editar) |
-| Gates › item 10 | Nenhuma — checklist inline | Se a branch tocar em auth, sessions, inputs de usuário, CORS, CSP, permissões ou adicionar endpoints públicos |
-| Publicação do relatório | `/eng-global-task-comment` | Só se o usuário escolher um dos **Sim** no fim: o resumo ou o `gate-checklist.md` completo, com as decisões, vira um comentário na issue/card (freelance pula, sem perguntar) |
+| Gates › item 1 | `prod.pm-checker` (agente) | Sempre na rodada 1; da rodada 2 em diante, só se o diff desde o `Commit:` da rodada anterior tiver qualquer arquivo (Rodada incremental) — verificar alinhamento da branch com os docs de produto e engenharia |
+| Gates › item 2 | `eng.dev-code-reviewer` (agente) | Sempre na rodada 1; da rodada 2 em diante, só se o diff desde o `Commit:` da rodada anterior tiver arquivo fora da pasta `docs/` da raiz do repositório (Rodada incremental) — revisar o código antes de lançar |
+| Gates › item 3 | `eng.qa.test-planner` (agente) | Sempre na rodada 1; da rodada 2 em diante, só se o diff desde o `Commit:` da rodada anterior tiver arquivo fora da pasta `docs/` da raiz do repositório (Rodada incremental) — identificar gaps de cobertura de testes na branch |
+| Gates › item 4 | `eng.qa.test-architect` (agente) | Se a feature tiver requisitos não-funcionais (no `architecture.md` ou explícitos na task); da rodada 2 em diante, também só com arquivo fora da pasta `docs/` da raiz do repositório no diff desde o `Commit:` da rodada anterior |
+| Gates › item 5 | `/eng-qa` + `QA_SPECIALIZATIONS` | Sempre na rodada 1; da rodada 2 em diante, só se o diff desde o `Commit:` da rodada anterior tiver qualquer arquivo (Rodada incremental) — frontend e/ou backend conforme o projeto |
+| Gates › item 6 | `eng.frontend.agent` (agente) | Se a branch tiver mudanças de interface (componentes, estilos, estado); da rodada 2 em diante, só se o diff desde o `Commit:` da rodada anterior as tiver |
+| Gates › item 7 | `eng.ux-designer.agent` (agente) | Se a branch introduzir nova feature de UI ou alterar fluxo de usuário; da rodada 2 em diante, só se o diff desde o `Commit:` da rodada anterior o fizer |
+| Gates › item 8 | Nenhuma — checklist inline | Se a branch tocar em auth, sessions, inputs de usuário, CORS, CSP, permissões ou adicionar endpoints públicos; da rodada 2 em diante, só se o diff desde o `Commit:` da rodada anterior os tocar |
+| Gates › item 9 | `eng.docs-writer` (agente) | Sempre na rodada 1; da rodada 2 em diante, só se o diff desde o `Commit:` da rodada anterior tiver qualquer arquivo (Rodada incremental) — apontar documentação do projeto desatualizada (sem editar) |
+| Publicação do relatório | `/eng-global-task-comment` | Só se o usuário escolher um dos **Sim** no fim: o resumo ou o `gate-checklist.md` completo, com as decisões, vira um comentário na issue/card (freelance pula: nesse modo o relatório fica só na sessão) |
 
 ## Regras de Execução
 
 - **Escopo**: avalie apenas as mudanças desta branch em relação à **branch base** (`Branch base:` do `architecture.md`; sem ele, pergunte).
 - **Só apontar**: cada agente/gate devolve lacunas, não correções. Nenhum arquivo do projeto é alterado por este comando.
-- **Evidências**: cite o comando rodado e o resultado, ou `arquivo:linha`, para cada lacuna.
+- **Evidências**: cite o comando rodado e o resultado, ou `arquivo:linha` com o trecho, para cada lacuna, e o que a derrubaria (coluna Refutação; seção "Passe crítico").
 
 ## Gates (revisão)
 
+Passe a cada agente a `Branch base:` do `architecture.md` e, da rodada 2 em diante, o diff incremental, e peça as lacunas no formato da tabela de "Lacunas" (com o "(item N)" e a Refutação; cada agente tem a seção "Quando chamado pelo `/eng.pre-pr`"). Na rodada 1, todos os gates abaixo rodam conforme a condição de cada um. Da rodada 2 em diante, vale também a seção "Rodada incremental": um gate só roda se o diff desde o `Commit:` da rodada anterior tocar o que ele lê.
+
 1. Invoque o agente [prod.pm-checker]($IDE/agents/product/prod.pm-checker.md) para apontar desalinhamentos entre a branch e os documentos de produto e de engenharia (em `$PROD_DOCS`, `$ENG_DOCS` e no Central docs).
 2. Invoque o agente [eng.dev-code-reviewer]($IDE/agents/engineering/eng.dev-code-reviewer.md) para apontar problemas de código (bugs, legibilidade, padrões do projeto).
 3. Invoque o agente [eng.qa.test-planner]($IDE/agents/engineering/qa/eng.qa.test-planner.md) para apontar lacunas de cobertura de testes. Lacunas críticas: funções públicas sem teste, lógica de negócio descoberta, tratamento de erro não validado.
@@ -76,26 +78,87 @@ Antes de abrir o PR/MR, este comando **revê a branch atrás de possíveis lacun
 
 ## Relatório: `gate-checklist.md` (obrigatório)
 
+### Passe crítico
+
+Depois dos gates e antes de gravar o relatório, faça **um** passe contra a lista de lacunas. Parecido com o `Reflection` (um passe contra a própria conclusão), como o "Crítico antes de concluir" da skill `eng-global-investigation` (ver #171), mas sem nota de 0 a 100 nem novas tentativas.
+
+- **Para cada lacuna**, confira a **Refutação** (o que a derrubaria) no lugar que ela aponta, e se o **Onde** traz o trecho ou o resultado do comando, e não só `arquivo:linha`.
+- **Se a refutação se sustenta** (o lugar apontado mostra que a lacuna não existe), a lacuna **sai** da tabela. Registre-a numa linha abaixo da tabela da área: "Removidas no passe crítico: {lacuna} — {motivo}".
+- **Se a lacuna existe, mas pesa menos do que a severidade dada** (por exemplo, 🟡 que é só redação), ela é **rebaixada**, com "(rebaixada: {motivo})" na coluna Lacuna, antes do "(item N)".
+- **Sem evidência verificável** (nem trecho, nem comando, nem resultado): rebaixe para ⚪ ou peça ao gate o lugar exato antes de gravar.
+- O passe vale só para as lacunas achadas pelos gates nesta rodada: as copiadas como "(não reavaliada nesta rodada)" e as que voltam com decisão herdada não passam por ele. O passe não acrescenta lacunas novas nem muda a decisão herdada de uma lacuna. Com mais de um sufixo, a ordem é "(rebaixada: …) (não reavaliada nesta rodada) (item N)".
+
+### Rodadas
+
+O `/eng.pre-pr` pode rodar mais de uma vez na mesma sessão (por exemplo, depois de corrigir lacunas com o `/eng.work`). Cada rodada preserva a anterior. Faça isto **depois dos gates e imediatamente antes de gravar**, com o renomear e o gravar em sequência, sem perguntas entre os dois:
+
+- **Sem `gate-checklist.md` na sessão:** se não houver nenhum `gate-checklist-rodada-{N}.md` (os `.public.md` não contam aqui), é a primeira rodada: grave com `Rodada: 1`. Se houver (o relatório foi movido, ou uma gravação falhou depois do renomear), a nova rodada é o maior número existente + 1, a rodada anterior é o `.md` de maior número, e os arquivos `.md` existentes entram em "Rodadas anteriores". Um `gate-checklist.public.md` solto (sem o relatório que o originou, um estado anormal) fica como está: avise que ele ficou sem o relatório de origem e que um "Sim" na versão humanizada do `eng.pr` o grava por cima.
+- **Com `gate-checklist.md`:** seja `M` o número do arquivo renomeado: o maior entre o `Rodada:` do cabeçalho dele (sem o campo, ou com valor que não seja número, vale `1`) e o maior número existente + 1 (sem arquivo numerado, esse termo vale `1`). Assim `M` nunca repete um número já usado, inclusive quando o nome estiver ocupado ou o `Rodada:` for menor que o de um arquivo existente. Renomeie o arquivo para `gate-checklist-rodada-{M}.md` (a rodada anterior é essa) e grave a nova rodada em `gate-checklist.md` com `Rodada: {M+1}`. Se existir o `gate-checklist.public.md` (versão humanizada, `rules/artifact-style-rules.md`), renomeie-o sempre junto, para `gate-checklist-rodada-{M}.public.md`: com `gate-checklist.md` presente, ele é a versão humanizada desse relatório.
+- **Contagem:** o maior número existente considera os `gate-checklist-rodada-{N}.md` e os `gate-checklist-rodada-{N}.public.md`; a lista de "Rodadas anteriores" traz só os `.md`. O `.public.md` não ganha número próprio: só reserva o que já tem, para a rotação não sobrescrevê-lo (a proibição de contar `{nome}.public.md` na sequência de IDs, em `rules/artifact-style-rules.md`, trata dos IDs de documentos, não deste nome).
+- **Nunca** apague nem sobrescreva uma rodada, e não edite o arquivo renomeado.
+
+O `gate-checklist.md` é sempre a rodada mais recente: o `/eng.pr` e o `/eng.spec-consolidate` leem só ele; as rodadas anteriores são histórico.
+
+### Rodada incremental
+
+Da rodada 2 em diante, um gate roda só se o diff desde a rodada anterior tocar o que ele lê. O diff incremental decide apenas **se** o gate roda: o gate que roda continua revisando a branch inteira em relação à branch base.
+
+- **Diff incremental:** `git diff --name-only {Commit da rodada anterior}..HEAD`, mais os arquivos de `git status --porcelain` (mudanças ainda sem commit; um arquivo que já estava sujo na rodada anterior e não mudou entra de novo, e o gate roda a mais: borda aceita, a favor de revisar). No modo workspace, um diff por repositório do `Commit:` da rodada anterior (`git -C {repo} …`); repositório com mudanças na branch que não estava nesse `Commit:` entra inteiro.
+- **Escopo de cada gate**, pelo que ele lê (não pelo que ele aponta):
+
+  | Gate (item) | Área do relatório | Roda da rodada 2 em diante se o diff incremental tiver |
+  |---|---|---|
+  | Alinhamento (1) | Produto e documentação | qualquer arquivo |
+  | Código (2) | Código | algum arquivo fora da pasta `docs/` da raiz do repositório |
+  | Cobertura de testes (3) | Testes | algum arquivo fora da pasta `docs/` da raiz do repositório |
+  | Não funcionais (4) | Não funcionais | algum arquivo fora da pasta `docs/` da raiz do repositório, e a feature tem requisito não funcional |
+  | Testes automatizados (5) | Testes | qualquer arquivo |
+  | Interface (6) | Interface e UX | mudança de interface (componentes, estilos, estado) |
+  | UX (7) | Interface e UX | nova feature de UI ou mudança de fluxo de usuário |
+  | Segurança (8) | Segurança | algo que toque auth, sessions, inputs de usuário, CORS, CSP, permissões ou endpoints públicos |
+  | Documentação do projeto (9) | Documentação do projeto | qualquer arquivo |
+
+- **Lacuna que depende de arquivo fora do escopo do gate** (por exemplo, documentação que ficou desatualizada por uma mudança de código): fica coberta porque o alinhamento e a documentação rodam com qualquer arquivo no diff.
+- **Lacuna reavaliada:** uma lacuna da rodada anterior é reavaliada só se o gate que a achou (o item entre parênteses no fim da coluna Lacuna) rodou nesta rodada. Em relatório antigo, sem o item, vale a área: é reavaliada se todos os gates da área dela rodaram.
+- **Pendentes não reavaliadas continuam pendentes:** a lacuna da rodada anterior que não foi reavaliada e estava com `🔧 Corrigir` ou sem decisão é copiada para a tabela da área nesta rodada, com a decisão herdada e a coluna Lacuna no formato "{lacuna} (não reavaliada nesta rodada) (item N)": o item fica sempre por último, e uma lacuna já copiada não ganha o sufixo de novo (mantém o sufixo e o item que já tem); sem item na origem (relatório antigo), copie sem ele, e vale a área; na "Resolução da rodada anterior" ela fica `Não reavaliada`. Assim ela entra na conta do fechamento e no PR Brief.
+- **Sem nenhum arquivo no diff incremental:** nenhum gate roda; as pendentes da rodada anterior são copiadas (regra acima) e a rodada serve para decidir de novo sobre elas, no fechamento.
+- **Como o relatório marca:** a área em que nenhum gate rodou leva, acima da tabela (que só traz as pendentes copiadas, se houver), "Não reavaliada nesta rodada (sem diff no escopo desde `{Commit da rodada anterior}`)".
+- **Todos os gates rodam:** na rodada 1; quando a rodada anterior não tem `Commit:` (relatório de versão antiga); quando esse commit não existe mais no repositório (`git cat-file -e {Commit da rodada anterior}` falha: rebase, outro clone); e quando a pessoa pedir. Nos dois casos do meio, avise em uma linha.
+
+### Modelo
+
 Grave em `$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/gate-checklist.md`:
 
 ```markdown
 # Gate checklist — {TASK_MANAGER_KEY}
 
-> Branch: {branch} → {branch base} · Data: {AAAA-MM-DD}
+> Branch: {branch} → {branch base} · Data: {AAAA-MM-DD} · Rodada: {N} · Commit: {sha curto do HEAD; no modo workspace, `{repo}@{sha}` por repositório com mudanças na branch}
 > **Semáforo:** 🟢 pronto para PR | 🟡 pode abrir com notas | 🔴 há bloqueadores
 
+## Rodadas anteriores
+{Um link por rodada anterior, em ordem crescente do número do nome (buracos aceitos): [`gate-checklist-rodada-{N}.md`](gate-checklist-rodada-{N}.md) ({data}, {semáforo}). Na primeira rodada: "Nenhuma (primeira rodada)."}
+
+## Resolução da rodada anterior
+{Só da rodada 2 em diante; na primeira, omita esta seção.}
+
+| # anterior | Lacuna | Decisão anterior | Situação | Corrigido em |
+|---|---|---|---|---|
+| {Área} #{n} | {lacuna da rodada anterior} | {🔧 Corrigir \| vazia} | {Corrigida \| Ainda presente \| Não reavaliada \| Removida no passe crítico} | {hash \| sem commit: {arquivo} \| —} |
+
 ## Resumo
 {3 a 5 frases: o que a branch faz, quantas lacunas por severidade e o principal risco.}
 
+Critério de parada: {atingido na rodada {N} (teto de {T} rodadas da urgência `{u}` | sem lacuna 🔴 ou 🟡 nova) | não atingido}
+
 ## Lacunas
 
 ### {Área: Produto e documentação | Código | Testes | Não funcionais | Interface e UX | Segurança | Documentação do projeto}
 
-| # | Lacuna | Onde | Por que importa | Sugestão | Severidade | Decisão |
-|---|---|---|---|---|---|---|
-| 1 | {o que falta ou está errado} | [`{arquivo}:{linha}`](../../../../{repo}/{caminho}#L{linha}) | {impacto, em linguagem simples} | {como resolver} | 🔴 Bloqueador / 🟡 Importante / ⚪ Menor | {Corrigir \| Aceitar: motivo} |
+| # | Lacuna | Onde | Por que importa | Refutação | Sugestão | Severidade | Decisão |
+|---|---|---|---|---|---|---|---|
+| 1 | {o que falta ou está errado} (item {N}) | [`{arquivo}:{linha}`](../../../../{repo}/{caminho}#L{linha}): {trecho, ou o comando e o resultado} | {impacto, em linguagem simples} | {o que derrubaria esta lacuna, com o lugar a conferir} | {como resolver} | 🔴 Bloqueador / 🟡 Importante / ⚪ Menor | {🔧 Corrigir \| 👍 Aceitar: motivo} |
 
-(uma tabela por área; área sem lacuna: "Nenhuma lacuna encontrada.")
+(uma tabela por área; a Refutação é o que, se verdadeiro, mostraria que a lacuna não existe, e o passe crítico a confere antes de gravar; a coluna Lacuna termina com o item do gate que a achou, entre parênteses, por exemplo "(item 3)", que a rodada incremental usa para saber se ela foi reavaliada; área sem lacuna: "Nenhuma lacuna encontrada."; área cujos gates não rodaram nesta rodada: "Não reavaliada nesta rodada (sem diff no escopo desde `{Commit da rodada anterior}`)", seção "Rodada incremental")
 
 ## Evidências
 {Comandos rodados (testes, lint, build, audit) e resultados.}
@@ -104,28 +167,64 @@ Grave em `$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/gate-checklist.md`:
 - Resumo do que mudou:
 - Como testar:
 - Riscos / trade-offs:
+- Rodadas do pre-pr: {N} (🔴/🟡/⚪ por rodada: {a/b/c, …}); critério de parada: {rodada {K}, por {teto | sem lacuna nova} | não agiu}
+- Ajustes antes da aprovação: architecture.md {n} · plan.md {m}   ← da linha "Ajustes antes da aprovação" do cabeçalho de cada um ("—" se a linha não existir)
+- Lições desta tarefa: {até 3 linhas: o que deu mais voltas, por quê, e em qual rodada apareceu; só o que faria a próxima tarefa gastar menos rodadas}   ← registro só desta tarefa; guardar e recuperar lições entre tarefas é a #169
+- Labels sugeridos: {só o nome, ex.: `security`}   ← critério em `eng-security-rules.md` (auth, sessions, RBAC, CORS, CSP, permissões); a pessoa adiciona no host (o `jarvis vcs create-merge` não põe label); nem o label nem esta nota entram no `pull-request.md`; o `eng.pr` lembra o label na mensagem final
 ```
 
-A coluna **Decisão** nasce vazia: quem preenche é o usuário.
+A coluna **Decisão** nasce vazia: quem preenche é o usuário (exceto a decisão herdada, descrita abaixo).
+
+A **Resolução da rodada anterior** lista as lacunas da rodada anterior com decisão `🔧 Corrigir` (ou `Corrigir` sem ícone, de um relatório anterior à rodada 3, que vale igual) e as sem decisão (coluna vazia; no fechamento, as ⚪ só recebem decisão pela opção "Corrigir todas"). As `👍 Aceitar` não entram e, se reaparecerem, voltam como lacunas novas, com a Decisão vazia. A lacuna `🔧 Corrigir` que continua `Ainda presente` e reaparece nas tabelas novas herda a decisão: nasce com `🔧 Corrigir`, para o usuário confirmar ou mudar: as 🔴 e 🟡 herdadas em "Decidir uma a uma", as ⚪ herdadas à mão, editando a coluna Decisão. As regras da tabela:
+
+- **Situação:** `Corrigida` (não aparece mais nesta rodada), `Ainda presente` (aparece de novo nas tabelas desta rodada) ou `Não reavaliada` (o gate ou a área dela não rodou nesta rodada, inclusive quando a rodada incremental o pulou, então sumir não prova correção). A lacuna da rodada anterior que o passe crítico desta rodada removeu fica `Removida no passe crítico`, com o motivo, e não conta como corrigida. A decisão fica só na coluna "Decisão anterior".
+- **Rodada anterior:** é a do arquivo renomeado (`M`) ou, sem `gate-checklist.md`, o `.md` de maior número; o `Commit:` e as lacunas vêm dela.
+- **Coluna "Onde":** o arquivo é o caminho do link depois de `../../../../`, sem a âncora (`#…`, de linha ou de título) (no modo workspace, o primeiro trecho é o `{repo}` só se for uma subpasta com `.git/` ou listada em `WORKSPACE_REPOS`, e o resto é o arquivo; senão, o arquivo está fora de repositório); com vários arquivos, rode o log em cada um e junte os hashes (no workspace, escreva `{repo}@{hash}`; se um arquivo tem hash e outro não, liste só os hashes); arquivo fora de repositório (da sessão ou em `docs/jarvis/`; no modo workspace, também na raiz do workspace, como `AGENTS.md`), `—`.
+- **Corrigido em:** nas situações `Ainda presente` e `Não reavaliada`, `—`. Para as `Corrigida`, rode `git merge-base --is-ancestor {Commit da rodada anterior} HEAD`; se falhar (rebase, amend, squash ou outro clone), escreva `— (commit anterior fora do histórico)`. Se passar, ache o hash com `git log --format=%h {Commit da rodada anterior}..HEAD -- {arquivo}` (com mais de um, liste todos, separados por vírgula). Se a correção está no diretório de trabalho sem commit, `sem commit: {arquivo}`; se o log volta vazio (por exemplo, a correção criou um teste novo e não tocou o arquivo apontado), `— (não identificado)`. O hash é indicativo: mostra o commit que mexeu no arquivo apontado, não prova que foi a correção.
+- **Modo workspace (`WORKSPACE_MODE=workspace`):** o `Commit:` traz um `{repo}@{sha}` por repositório com mudanças na branch (cada repositório tem o seu `.git`; como em `eng.start.md`), e o git roda no repositório da lacuna: `git -C {repo} …` (o `{repo}` e o arquivo vêm da coluna "Onde", acima). Repositório que não está no `Commit:` da rodada anterior (não tinha mudanças): `— (repositório sem commit na rodada anterior)`. Com `project`, o `Commit:` é um sha só e o git roda na raiz.
+- **Rodada anterior sem `Commit:`** (relatório de versão antiga): `—`.
 
 ## Fechamento
 
-1. Mostre o semáforo, o resumo e a lista de lacunas por severidade, com o consolidado de links da sessão (regra 5 de `eng.transitions-rules.md`: tudo o que já existe, com o `gate-checklist.md` novo).
-2. Peça as decisões com `AskUserQuestion`, depois da mensagem em markdown do passo 1 (com o link clicável): **"O que fazer com as {n} lacunas encontradas ({a} 🔴 bloqueadoras, {b} 🟡 importantes)? Relatório: gate-checklist.md."**
-   - **Corrigir todas antes do PR:** marca as {n} como "Corrigir"; você corrige à mão ou com o `/eng.work`.
-   - **Corrigir só as bloqueadoras 🔴:** marca as {a} 🔴 como "Corrigir"; as 🟡 ficam "Aceitar", com um motivo só, pedido uma vez.
-   - **Decidir uma a uma:** mostra cada lacuna 🔴 e 🟡 e você escolhe "Corrigir" ou "Aceitar" (com o motivo), com `AskUserQuestion` por lacuna.
-   - **Só gerar o relatório (vou analisar com calma):** não registra decisão agora; a coluna **Decisão** fica vazia, o `gate-checklist.md` fica na sessão para você analisar e o comando termina sem as perguntas 3 e 4. Rode o `/eng.pre-pr` de novo, ou preencha o arquivo à mão, quando decidir.
+**Critério de parada.** Calcule-o depois dos gates e antes de gravar o relatório, e grave a linha `Critério de parada:` no Resumo. Ele não impede a rodada de rodar nem de gravar o relatório: muda só o que o fechamento mostra e pergunta. Parecido com o orçamento de etapas do `ReAct` e com o do `/eng.debug` (ver #171).
+
+- **Teto de rodadas**, pela `urgencia` do `context.md` (o mesmo campo do orçamento do `/eng.debug`): `alta` 3 · `normal` 5 · `baixa` 8; sem `context.md`, vale `normal`. Atingido quando o `Rodada:` desta rodada é igual ou maior que o teto.
+- **Rodada sem lacuna nova** (da rodada 2 em diante, e só se os gates de código e de cobertura de testes, itens 2 e 3, rodaram nesta rodada): nenhuma lacuna 🔴 ou 🟡 desta rodada é nova. Nova é a que não aparece na "Resolução da rodada anterior" como `Ainda presente` ou `Não reavaliada`. Atingido, leva à variante B (abaixo), mas não aceita 🟡 sozinho: só o teto aceita 🟡; com este gatilho, as 🟡 sem decisão são decididas uma a uma na própria variante B.
+- **Aviso de teto:** sempre que o teto for atingido e houver lacuna pendente, de qualquer severidade, comece a mensagem do passo 1 com: "⚠️ Teto de {T} rodadas da urgência `{u}` atingido; as pendências seguem abertas e cada rodada a mais fica registrada no PR."
+
+Lacuna **pendente** é a sem decisão ou a herdada com `🔧 Corrigir`, inclusive as copiadas como "(não reavaliada nesta rodada)". Uma decisão herdada nunca é trocada por outra opção da variante B. O passo 2 tem duas variantes:
+
+| Situação | Variante |
+|---|---|
+| Nenhuma 🔴 pendente, nenhuma 🟡 herdada com `🔧 Corrigir`, há lacuna sem decisão, e as sem decisão são só ⚪, ou também 🟡 com o critério de parada atingido (teto ou rodada sem lacuna nova) | **B** (severidade como gatilho) |
+| Qualquer outro caso (inclusive sem lacuna pendente) | **A** (as perguntas de sempre) |
+
+1. Mostre o semáforo, o resumo e a lista de lacunas por severidade, com o consolidado de links da sessão (regra 5 de `eng.transitions-rules.md`: tudo o que já existe, com o `gate-checklist.md` novo e, antes dele e em ordem, as rodadas anteriores `gate-checklist-rodada-{N}.md`; o atual leva a nota "rodada {N}, atual").
+2. Peça as decisões com `AskUserQuestion`, depois da mensagem em markdown do passo 1 (com o link clicável).
+
+   **Variante A.** Se o gatilho "sem lacuna nova" foi atingido (há 🔴 pendente ou 🟡 herdada com `🔧 Corrigir`, senão seria a B), comece com: "ℹ️ Nenhuma 🔴 ou 🟡 nova nesta rodada: as pendentes são as da rodada anterior." Pergunta: **"O que fazer com as {n} lacunas encontradas ({a} 🔴 bloqueadoras, {b} 🟡 importantes)? Relatório: gate-checklist.md."**
+   - **Corrigir todas antes do PR:** marca as {n} como "🔧 Corrigir"; você corrige à mão ou com o `/eng.work`.
+   - **Corrigir só as bloqueadoras 🔴:** marca as 🔴 sem decisão como "🔧 Corrigir"; as 🟡 sem decisão ficam "👍 Aceitar", com um motivo só, pedido uma vez. As lacunas herdadas continuam "🔧 Corrigir".
+   - **Decidir uma a uma:** mostra cada lacuna 🔴 e 🟡 (as herdadas já com "🔧 Corrigir") e você escolhe "🔧 Corrigir" ou "👍 Aceitar" (com o motivo), com `AskUserQuestion` por lacuna.
+   - **Só gerar o relatório (vou analisar com calma):** não registra decisão agora; a coluna **Decisão** fica vazia (exceto as decisões herdadas), o `gate-checklist.md` fica na sessão para você analisar e o comando termina sem as perguntas 3 e 4. Rode o `/eng.pre-pr` de novo (este relatório é preservado como `gate-checklist-rodada-{N}.md`), ou preencha o arquivo à mão, quando decidir.
+
+   **Variante B.** A resposta já decide como seguir, e o passo 4 não é feito. Pergunta: **"Restam {lista} sem decisão{ (motivo)}. Relatório: gate-checklist.md. Como seguir?"**, com `{lista}` = "{c} lacunas ⚪", "{c} ⚪ e {b} 🟡" ou "{b} 🟡" (sem termo em zero) e o motivo, quando há 🟡: "teto de {T} rodadas atingido" ou "nenhuma 🔴 ou 🟡 nova nesta rodada" (com os dois gatilhos atingidos, vale o teto).
+   - **Aceitar as ⚪ e seguir para o PR** (é a primeira opção, a recomendada). Grava `👍 Aceitar: aceito no fechamento da rodada {N}` nas ⚪ sem decisão; depois do passo 3, chame o `/eng.pr {TASK_MANAGER_KEY}` (ou mostre o comando). O rótulo muda conforme o caso:
+     - com 🟡 sem decisão e o **teto** atingido: "Aceitar as 🟡 e as ⚪ e seguir para o PR" (ou "Aceitar as 🟡 e seguir para o PR", sem ⚪); as 🟡 levam `👍 Aceitar: teto de rodadas atingido na rodada {N}`;
+     - com 🟡 sem decisão e só o gatilho **sem lacuna nova**: "Aceitar as ⚪ e decidir as 🟡 uma a uma" (ou "Decidir as 🟡 uma a uma", sem ⚪); cada 🟡 é perguntada com `AskUserQuestion` (🔧 Corrigir ou 👍 Aceitar com o motivo); as ⚪ mantêm o Aceitar já gravado; depois do passo 3, chame o `/eng.work {TASK_MANAGER_KEY}` se alguma 🟡 ficou `🔧 Corrigir`, senão o `/eng.pr {TASK_MANAGER_KEY}` (ou mostre o comando);
+     - com ⚪ herdadas em `🔧 Corrigir`, o rótulo acrescenta "({h} ⚪ seguem em 🔧 Corrigir)": elas mantêm a decisão e vão como pendências no PR Brief.
+   - **Corrigir antes do PR:** marca as sem decisão como `🔧 Corrigir`; depois do passo 3, chame o `/eng.work {TASK_MANAGER_KEY}` para as pendentes (ou mostre o comando).
+   - **Só gerar o relatório (vou analisar com calma):** como na variante A; o comando termina sem os passos 3 e 4. É a opção que mantém o fluxo de hoje e a que vale quando a pessoa não escolhe.
 
-   Grave as decisões na coluna **Decisão** como `Corrigir` ou `Aceitar: motivo`.
+   Grave as decisões na coluna **Decisão** como `🔧 Corrigir` ou `👍 Aceitar: motivo`. As opções acima valem só para as lacunas sem decisão, exceto "Decidir uma a uma", que também deixa mudar as herdadas 🔴 e 🟡 (as ⚪ herdadas mudam à mão); as herdadas entram em `{n}` e, conforme a severidade, em `{a}` ou `{b}`.
 3. **Modo freelance (`TASK_MANAGER` vazio):** não pergunte; o relatório fica só na sessão. **Com board**, pergunte com `AskUserQuestion` (nunca publique sem a resposta): **"Registrar o resultado do `/eng.pre-pr` como comentário no card {TASK_MANAGER_KEY}?"**
-   - **Não, manter só na sessão (como hoje):** nada é enviado ao card.
+   - **Não, manter só na sessão (como hoje):** nada é enviado ao card (o texto fica no `gate-checklist.md`).
    - **Sim, só o resumo:** `/eng-global-task-comment {TASK_MANAGER_KEY}` com o semáforo, o resumo e as lacunas 🔴 com a decisão de cada uma.
    - **Sim, o relatório completo:** `/eng-global-task-comment {TASK_MANAGER_KEY}` com o conteúdo do `gate-checklist.md`.
 
    O texto vai para fora do workspace: converta os links pela regra 6 de `doc-links-rules.md` (URL absoluta; sessão e `docs/jarvis/` em texto).
-4. Próximo passo: corrigir o que foi marcado "Corrigir" (à mão ou com o `/eng.work`) e rodar o `/eng.pr`, que usa o PR Brief deste relatório. Antes, escreva uma mensagem em markdown com o consolidado de links da sessão (regra 5) e o resumo; depois pergunte com `AskUserQuestion` (`eng.transitions-rules.md`):
-   - **Com {n} lacunas marcadas "Corrigir"** — **"O `/eng.pre-pr` encontrou {n} lacunas a corrigir ({a} 🔴, {b} 🟡). Leia o gate-checklist.md com calma e responda quando decidir. Como seguir?"**
+4. Próximo passo (só na variante A do passo 2): corrigir o que foi marcado "🔧 Corrigir" (à mão ou com o `/eng.work`) e rodar o `/eng.pr`, que usa o PR Brief deste relatório. Antes, escreva uma mensagem em markdown com o consolidado de links da sessão (regra 5) e o resumo; depois pergunte com `AskUserQuestion` (`eng.transitions-rules.md`):
+   - **Com {n} lacunas marcadas "🔧 Corrigir"** — **"O `/eng.pre-pr` encontrou {n} lacunas a corrigir ({a} 🔴, {b} 🟡). Leia o gate-checklist.md com calma e responda quando decidir. Como seguir?"**
      - **Corrigir as lacunas agora:** chame o `/eng.work {TASK_MANAGER_KEY}` para as {n} lacunas (ou mostre o comando).
      - **Parar aqui para corrigir à mão (como hoje):** o comando termina.
      - **Abrir o PR assim mesmo:** chame o `/eng.pr {TASK_MANAGER_KEY}`; as {n} pendências seguem registradas no PR Brief.

package/workflows/engineering/eng.spec-consolidate.md

@@ -52,7 +52,7 @@ Os documentos de trabalho (PRD, FRD, ARD, RFC, SPEC…) continuam em `docs/jarvi
 
 ## Passo 1: Coleta (modo normal)
 
-O agente `eng.docs-consolidator` lê **todas** as fontes, na ordem do agente:
+O agente `eng.docs-consolidator.agent` lê **todas** as fontes, na ordem do agente:
 1. `architecture.md` e `plan.md` da sessão.
 2. Documentos de trabalho ligados à tarefa em `$PROD_DOCS` e `$ENG_DOCS` (PRD, FRD, épicos, histórias, ARD, RFC, SPEC, swagger, QA).
 3. Commits e arquivos:
@@ -62,7 +62,7 @@ O agente `eng.docs-consolidator` lê **todas** as fontes, na ordem do agente:
    ```
 4. **PR/MR:** número e URL (`pull-request.md` da sessão, `gh pr view`/equivalente do vendor, ou pergunte).
 5. **Card:** URL no padrão do `TASK_MANAGER` (`eng.integrations-rules.md`); no modo freelance, só o número de controle.
-6. `gate-checklist.md` e `pull-request.md` da sessão, se existirem.
+6. `gate-checklist.md` (a rodada mais recente do `eng.pre-pr`; as anteriores, `gate-checklist-rodada-{N}.md`, são histórico) e `pull-request.md` da sessão, se existirem.
 
 ## Passo 2: Coleta (modo `--inicial`)
 
@@ -92,7 +92,7 @@ O frontmatter segue o template, com os comentários `#`. `product` = `WORKSPACE`
 
 ## Passo 5: Revisão
 
-Mostre o resumo dos dois arquivos (seções, tamanho, referências) e o caminho deles. Pergunte com `AskUserQuestion`:
+Mostre o resumo dos dois arquivos (seções, tamanho, referências) e o caminho deles, para você abrir e ler o texto completo antes de aprovar. Pergunte com `AskUserQuestion`:
 - `[Aprovar]`
 - `[Ajustar]`: diga o que mudar; o agente ajusta e você revisa de novo.
 
@@ -104,7 +104,7 @@ Confira antes de aprovar:
 
 ## Passo 6: Publicar
 
-Pergunte com `AskUserQuestion` (**Sim / Não**): **"Publicar no Central docs?"**
+Pergunte com `AskUserQuestion` (**Sim / Não**): **"Publicar no Central docs?"** (regra de ouro, `eng.integrations-rules.md`; a pergunta cobre os dois documentos que o Passo 5 já mostrou e você aprovou)
 
 - **Sim:**
   ```bash
@@ -121,7 +121,7 @@ Com `ARTIFACT_STYLE=human-generated`, a versão humanizada (`{nome}.public.md`)
 ```
 ✅ Consolidação {publicada | salva na sessão}
 
-📄 Arquivos da sessão (consolidado acumulado, regra 5 de `eng.transitions-rules.md`): links de `context.md`, `architecture.md`, `plan.md`, `gate-checklist.md`, `pull-request.md`, `daily.md` e dos arquivos de `consolidation/` (novos), só os que existem
+📄 Arquivos da sessão (consolidado acumulado, regra 5 de `eng.transitions-rules.md`): links de `context.md`, `architecture.md`, `plan.md`, das rodadas anteriores `gate-checklist-rodada-{N}.md`, `gate-checklist.md`, `pull-request.md`, `daily.md` e dos arquivos de `consolidation/` (novos), só os que existem
 
 📄 Funcionalidade: {SQUAD}/product/{produto}/feature-{slug}.md
 🧾 Entrega:        {SQUAD}/engineering/{produto}/delivery-{AAAA-MM-DD}-{task_key}.md

package/workflows/engineering/eng.start.md

@@ -28,7 +28,7 @@ Este comando inicia o **planejamento** de uma nova feature.
 | Cabeçalho (agente) | `eng.agent` (agente) | Sempre — identidade do workflow |
 | Fase 0.1: Análise de Contexto (CDD) | `/jarvis-context-detect` | Se `ENABLE_CDD=true` no ENV.md (execução obrigatória antes da Fase 1); `ENABLE_CDD=false` pula |
 | Fase 0.5: Advisor (opcional) | `eng.advisor.agent` (agente) | Se o usuário escolher usar o Advisor no alerta e o `architecture.md` tiver questões em aberto (aberto só na primeira questão) |
-| Fase 2.2: Buscar Documentação Central | `/jarvis-docs-central` | Se `CENTRAL_DOCS_STORAGE` estiver configurado no ENV.md (buscar PRD, ARD e RFCs relacionados) |
+| Fase 2.2: Buscar Documentação Central | `/jarvis-docs-central` | Se `CENTRAL_DOCS_STORAGE` estiver configurado no ENV.md (buscar as funcionalidades já implementadas, `feature-*`, e entregas recentes; PRD, ARD e RFC ficam em `docs/jarvis/`) |
 | Fase 3.4: Estratégia de Testes | `eng.qa.test-architect` (agente) | Se a feature tiver requisitos de performance ou segurança (APIs públicas, dados sensíveis, alta carga ou requisitos não-funcionais explícitos) |
 | Fase 3.4: Estratégia de Testes | `/eng-platform` | Se a feature tiver requisitos de performance (latência, throughput, escalabilidade) |
 | Fase 3.4: Estratégia de Testes | `/eng-ai` | Se a feature envolver IA (LLM, RAG, agentes, chatbots, embeddings) |
@@ -37,7 +37,7 @@ Este comando inicia o **planejamento** de uma nova feature.
 | Fase 3.4: Estratégia de Testes | `/eng-data` (via `eng.specializations-rules.md`) | Se a feature envolver engenharia de dados (pipelines ETL/ELT, Glue, Airflow, contratos de dados, camadas bronze/silver/gold); a regra também carrega as especializações de `DATA_SPECIALIZATIONS` |
 | Fase 3.4: Estratégia de Testes | `/eng-automation` (via `eng.specializations-rules.md`) | Se a feature envolver RPA ou extração de dados/scraping; a regra também carrega as especializações de `AUTOMATION_SPECIALIZATIONS` |
 | Fase 3.4: Estratégia de Testes | `/eng-platform` (via `eng.specializations-rules.md`) | Se a feature envolver infraestrutura (IaC, contêineres, CI/CD, observabilidade, SRE, custo); a regra também carrega as especializações de `PLATFORM_SPECIALIZATIONS` |
-| Fase 4.3: Questões em Aberto | `/eng-global-task-comment` | Se o Advisor foi usado e houve questões em aberto: **um** comentário de auditoria (freelance pula; o registro fica só no `architecture.md`) |
+| Fase 4.3: Questões em Aberto | `/eng-global-task-comment` | Se o Advisor foi usado e houve questões em aberto: **um** comentário de auditoria, só com o Sim da pergunta (regra de ouro; freelance: o skill registra no `task-log.md`); sem o Sim, o texto fica no `task-comment-*.md` e no `architecture.md` |
 
 ---
 
@@ -241,14 +241,16 @@ Os documentos de trabalho da tarefa (PRD, FRD, ARD, RFC, SPEC) ficam em `$PROD_D
 **Comportamento:**
 - Se docs encontrados → carregar e exibir resumo
 - Se não encontrados → seguir com os documentos de trabalho em `docs/jarvis/` e o card
-- Se `CENTRAL_DOCS_STORAGE` vazio → pular silenciosamente
+- Se `CENTRAL_DOCS_STORAGE` vazio → pular só a busca no Central docs; os documentos de trabalho em `docs/jarvis/` e o card seguem
 
 ### 2.3 Análise do Requisito
 
 Examine os cards, seus pais e filhos, e desenvolva compreensão do que deve ser implementado.
 
-**Se docs do central foram carregados:**
-- Validar alinhamento com PRD
+**Se funcionalidades do Central docs foram carregadas:** validar o alinhamento com o que já existe (comportamento atual, decisões, onde está no código).
+
+**Com os documentos de trabalho de `docs/jarvis/`:**
+- Validar alinhamento com o PRD
 - Verificar restrições arquiteturais do ARD
 - Considerar decisões de RFCs relacionados
 
@@ -299,7 +301,7 @@ Verifique:
 - `$DOCS_FOLDER/**/*.md` - Documentação do projeto
 - `$SESSIONS_DIR/eng/**/*.md` - Tech specs anteriores
 - `README.md`, `ARCHITECTURE.md` - Visão geral do projeto onde está sendo executado
-- Anexos no Jira - PRD, FRD, ARD, RFC
+- Anexos no card (lidos pela CLI ou colados) - PRD, FRD, ARD, RFC
 
 ### 3.3 Padrões e Convenções
 
@@ -403,10 +405,20 @@ Levante na seção 8 **tudo** que for diferente do código ou ambíguo no card,
 1. Na primeira questão, abra `eng.advisor.agent` em segundo plano com o modelo escolhido e envie o **Prompt 1** (carga inicial). Se ele responder que precisa de ajuda para localizar o contexto, pergunte ao usuário com `AskUserQuestion` (opção "Não há documento: siga só com o card e o código") e reenvie.
 2. Envie cada questão com o **Prompt 2**, uma por mensagem, para a mesma instância.
 3. Preencha "Sugestão do Sub-Agent (Advisor)", **"Decisão adotada" (a sugestão do Advisor, que prevalece; não a substitua nem a conteste)**, "Divergência" e "Impacto da decisão". Confira no código os fatos em que a sugestão se apoia antes de registrar e escreva as citações do Advisor (arquivos, linhas, requisitos) no formato de link da `doc-links-rules.md`.
-4. Poste **um** comentário de auditoria na issue com `/eng-global-task-comment`, no modelo do template (freelance pula).
+4. Monte **um** comentário de auditoria, no modelo do template, e publique-o na issue com `/eng-global-task-comment`, que mostra o texto e pergunta (regra de ouro, `eng.integrations-rules.md`; freelance: o skill registra no `task-log.md`). Sem o Sim, o texto fica no `task-comment-*.md` e no `architecture.md`.
 
 **Sem Advisor:** com "Tratar no architecture.md (como hoje)", apresente as questões ao usuário, como sempre; com "Uma a uma", elas já foram respondidas ao surgir (registre as respostas e escreva só as que surgirem na escrita do documento).
 
+### 4.4 Passe Crítico
+
+Antes de apresentar o documento, faça um passe contra ele e registre-o na seção 2.5 ("Premissas e Passe Crítico") do `architecture.md`. Parecido com o `Reflection` (um passe contra a própria conclusão), como o "Crítico antes de concluir" da skill `eng-global-investigation` (ver #171).
+
+1. Liste as premissas em que o documento se apoia e que mudariam o plano se estivessem erradas (até cerca de 10).
+2. Para cada uma, separe o que foi **lido** (com o link `arquivo:linha` do que foi lido nas Fases 2 e 3) do que foi **presumido**, e escreva o que a derrubaria e como conferir.
+3. Responda em uma frase: **que premissa derrubaria este documento?**
+4. Toda premissa presumida que mudaria o plano vira, agora, uma leitura (e passa a "lida") ou uma questão em aberto na seção 8. A questão que nasce aqui segue a Fase 4.3: com Advisor, vai em Prompt 2 para a mesma instância (e entra no comentário de auditoria, se ele ainda não saiu); sem Advisor, segue o modo escolhido no início. Com questão nova aberta aqui, o gate da Fase 5.2 aguarda a aprovação explícita da pessoa, mesmo com Advisor e autonomia `alta` (a sugestão do Advisor fica registrada, mas não substitui essa aprovação).
+5. Só então siga para a Fase 5. O passe vale com e sem Advisor.
+
 ---
 
 ## Fase 5: Revisão e Aprovação
@@ -425,17 +437,19 @@ Apresente:
 Se o usuário tiver feedback:
 
 - Atualize o documento
+- Some 1 em "Ajustes antes da aprovação" no cabeçalho do `architecture.md`, a cada "Ajustar o documento" (o número vai para o PR Brief do `eng.pre-pr`)
+- Refaça o passe crítico (4.4) no que mudou
 - Apresente novamente
 - Continue até aprovação explícita
 
 **Sem Advisor**, a aprovação é a pergunta de transição (`eng.transitions-rules.md`): **"Aprovar o architecture.md?"** (depois da mensagem em markdown com o link clicável do arquivo) → **Aprovar e parar aqui (como hoje)** / **Aprovar e seguir para o `/eng.plan`** / **Ajustar o documento**. Com "seguir", chame o `/eng.plan {TASK_MANAGER_KEY}` (ou mostre o comando).
-**Com Advisor**, o gate segue a autonomia do `context.md` (CDD): `alta` → apresente o resumo e siga para o `eng.plan` sem aguardar; `média` ou `baixa` → aguarde a aprovação explícita. Sem `context.md`, use a tabela "Autonomia por POSITION" de `eng-rules.md`. Sem Advisor, nada muda.
+**Com Advisor**, o gate segue a autonomia do `context.md` (CDD): `alta` → apresente o resumo e siga para o `eng.plan` sem aguardar, salvo se o passe crítico (Fase 4.4) abriu questão nova; `média` ou `baixa` → aguarde a aprovação explícita. Sem `context.md`, use a tabela "Autonomia por POSITION" de `eng-rules.md`. **Sempre que a aprovação explícita for obrigatória com Advisor** (`média` ou `baixa`, ou questão nova do passe crítico), peça-a com a mesma pergunta de transição de quem não usa Advisor: a pergunta "Aprovar o architecture.md?", com as mesmas opções. Sem Advisor, nada muda.
 
 ### 5.3 Atualizar Board
 
 Pular se `TASK_MANAGER` estiver vazio (freelance).
 
-Se estiver preenchido, mova o card para a etapa equivalente a "em andamento" no seu board. Quem assumiu o card conduz a entrega; ninguém precisa liberar a transição.
+Se estiver preenchido, oriente a pessoa a mover o card para a etapa equivalente a "em andamento" no board (o Jarvis não move card). Quem assumiu o card conduz a entrega; ninguém precisa liberar a transição.
 
 ### 5.4 Finalização
 

package/workflows/engineering/eng.work.md

@@ -36,7 +36,7 @@ Este comando executa a **implementação de código** seguindo o plano de execu
 | Fase 3 › 3.3.2 Implementar Testes Faltantes (Opção A) | `eng.qa.testing-engineer` (agente) | Se o test-planner identificar gaps e a estratégia do `architecture.md` seção 6.5 indicar testes manuais (unitário/integração) |
 | Fase 3 › 3.3.2 Implementar Testes Faltantes (Opção B) | `/eng-qa` | Se a estratégia do `architecture.md` seção 6.5 indicar uma especialização registrada em `QA_SPECIALIZATIONS` |
 | Fase 3 › 3.1 Implementar Código (exceção) | `eng.advisor.agent` (agente) | Só por exceção: questão nova em aberto, com o Advisor habilitado no `eng.start` (cabeçalho do `architecture.md`) |
-| Fase 5 › 5.4 e "Se houver bloqueio técnico" | `/eng-global-task-comment` | Se houver desvio do plano: mudança de direção, fase bloqueada ou questão nova consultada ao Advisor (freelance pula) |
+| Fase 5 › 5.4 e "Se houver bloqueio técnico" | `/eng-global-task-comment` | Se houver desvio do plano: mudança de direção, fase bloqueada ou questão nova consultada ao Advisor, só com o Sim da pergunta (regra de ouro; freelance: o skill registra no `task-log.md`); sem o Sim, o texto fica no `task-comment-*.md` |
 
 ---
 
@@ -253,7 +253,7 @@ Para cada tarefa da fase:
    - Testes unitários para cada função/método
    - Cobrir casos de sucesso e erro
 
-**Questão nova em aberto (exceção).** O ideal é que todas as questões tenham sido levantadas no `eng.start`. Se surgir uma nova e o cabeçalho do `architecture.md` indicar um Advisor, consulte `eng.advisor.agent` com o Prompt 2 de `$IDE/templates/engineering/advisor-template.md` (refaça o Prompt 1 se o subagente não existir mais), acrescente a questão à seção 8 marcada "levantada no `eng.work`", adote a sugestão do Advisor e poste o comentário de auditoria com `/eng-global-task-comment` (é desvio do plano; cite-o no PR como lacuna do `eng.start`). Sem Advisor, pergunte ao usuário.
+**Questão nova em aberto (exceção).** O ideal é que todas as questões tenham sido levantadas no `eng.start`. Se surgir uma nova e o cabeçalho do `architecture.md` indicar um Advisor, consulte `eng.advisor.agent` com o Prompt 2 de `$IDE/templates/engineering/advisor-template.md` (refaça o Prompt 1 se o subagente não existir mais), acrescente a questão à seção 8 marcada "levantada no `eng.work`", adote a sugestão do Advisor e monte o comentário de auditoria e publique-o com `/eng-global-task-comment`, que mostra o texto e pergunta (regra de ouro, `eng.integrations-rules.md`; é desvio do plano; freelance: o skill registra no `task-log.md`). Sem o Sim, o texto fica no `task-comment-*.md` e no `architecture.md`. Cite o desvio no PR como lacuna do `eng.start`. Sem Advisor, pergunte ao usuário.
 
 ### 3.2 Executar Validações Locais
 
@@ -434,7 +434,7 @@ Atualize o `plan.md`:
 - **Atenção**: {ponto importante para próximas fases}
 ```
 
-Se o comentário registrar uma **mudança de direção** (desvio do plano), comente também no card com `/eng-global-task-comment`, dizendo o que mudou e por quê (freelance pula).
+Se o comentário registrar uma **mudança de direção** (desvio do plano), monte também um comentário para o card, dizendo o que mudou e por quê, e publique-o com `/eng-global-task-comment`, que mostra o texto e pergunta (regra de ouro, `eng.integrations-rules.md`; freelance: o skill registra no `task-log.md`). Sem o Sim, o texto fica no `task-comment-*.md`.
 
 ### 5.3 Commit da Fase (GitFlow)
 
@@ -562,6 +562,6 @@ Depois da mensagem, siga a escolha **Depois do work**: chamar o `/eng.pre-pr {TA
 ### Se houver bloqueio técnico:
 
 → Documente no plan.md como `[Bloqueada 🚫]`
-→ Comente o bloqueio no card com `/eng-global-task-comment` (desvio do plano; freelance pula)
+→ Monte o comentário do bloqueio e publique-o no card com `/eng-global-task-comment`, que mostra o texto e pergunta (regra de ouro, `eng.integrations-rules.md`; desvio do plano; freelance: o skill registra no `task-log.md`). Sem o Sim, o texto fica no `task-comment-*.md`
 → Explique o bloqueio ao usuário
 → Sugira alternativas se possível

package/workflows/engineering/qa/eng.qa-release-signoff.md

@@ -11,9 +11,6 @@ model_justification: Leitura de arquivos locais, análise de cobertura e geraç
 
 Sign-off QA antes de um deploy. Verifica cobertura de testes, sessões exploratórias e bugs abertos para a branch atual, e produz um documento GO/NO-GO.
 
-> ℹ️ O documento gerado é validado automaticamente pelo CI via `jarvis qa-signoff`.
-> Para ativar a validação automática, o TL precisa adicionar o job ao pipeline — o snippet é fornecido ao final.
-
 ## Entrada
 
 ```
@@ -105,72 +102,10 @@ Salvar em:
 $ENG_DOCS/qa/signoffs/signoff-{branch-slug}-{YYYYMMDD}.md
 ```
 
-> O frontmatter **deve** conter `status: GO` ou `status: NO-GO` — o CLI `jarvis qa-signoff` lê este campo.
-
----
-
-## Fase 5 — Setup CI (condicional, apenas na primeira vez)
-
-Verificar se o job de sign-off já existe no pipeline:
-
-```bash
-grep -l "qa-signoff\|jarvis qa-signoff" .gitlab-ci.yml .github/workflows/*.yml 2>/dev/null
-```
-
-Se **já encontrado** → pular silenciosamente.
-
-Se **não encontrado**:
-
-**1. Identificar o Tech Lead do squad**
-
-Ler `members.md` e buscar o membro com `TECH LEAD` na seção do squad atual (`SQUAD` do ENV.md):
-
-```bash
-grep -A 20 "^## $SQUAD" members.md | grep -i "TECH LEAD"
-```
-
-Extrair nome e Slack ID do TL encontrado.
-
-**2. Enviar mensagem automática via $MESSAGE_COMUNICATOR**
-
-Enviar Slack DM para o Slack ID do TL com o seguinte conteúdo:
-
-```
-📋 *Setup QA Sign-off — {WORKSPACE}*
-
-Olá, {nome_do_tl}! O QA {nome_do_qa} configurou o sign-off automático de release.
-
-Para ativar a validação no pipeline CI, adicione ao `.gitlab-ci.yml`:
-
-```yaml
-qa-signoff:
-  stage: validate
-  script:
-    - npx jarvis qa-signoff --branch $CI_COMMIT_REF_NAME
-  rules:
-    - if: $CI_COMMIT_BRANCH =~ /^(main|master|release\/.*)$/
-  allow_failure: false
-```
-
-*Pré-requisito:* `jarvis-framework` em `devDependencies` (já instalado se o projeto usa Jarvis).
-
-Após o merge, todo push para `main`/`release/*` será validado automaticamente. ✅
-```
-
-**3. Confirmar ao QA**
-
-```
-✅ Mensagem enviada para {nome_do_tl} via Slack.
-   O CI será ativado assim que ele adicionar o job ao pipeline.
-```
-
-Se $MESSAGE_COMUNICATOR não estiver configurado ou o TL não tiver Slack ID em `members.md`:
-- Exibir o snippet na tela para envio manual
-- Avisar: "Configure MESSAGE_COMUNICATOR no ENV.md para envios automáticos futuros."
+> O frontmatter **deve** conter `status: GO` ou `status: NO-GO`: é a decisão registrada.
 
 ---
 
 ## Output
 
 - `$ENG_DOCS/qa/signoffs/signoff-{branch-slug}-{YYYYMMDD}.md` — documento de sign-off
-- Snippet CI (apenas na primeira execução, se pipeline ainda não configurado)

package/workflows/product/prod.roadmap.preview.md

@@ -24,7 +24,7 @@ Utilize o `$ARGUMENTS` que o usuário passar como ponto de partida e para entend
 ## Regras
 
 - Sempre identifique o quadrimestre atual e o próximo com base na data de hoje.
-- Utilize o MCP disponível relacionado ao $TASK_MANAGER utilizado pelo usuário.
+- Leia o board pela CLI oficial do `$TASK_MANAGER` (`acli` no Jira, `gh` no GitHub, `glab` no GitLab), com o login dela (`eng.integrations-rules.md`: board sem REST nem MCP). Só leitura: este comando não comenta nem cria nada no board.
 - Antes de qualquer coisa, procure por informações sobre o projeto ou produto que o usuário está solicitando dentro da pasta de trabalho utilizado. Confirme com o usuário o que foi encontrado. Utilize também informações que o usuário já compartilhou.
 - As documentações de projeto podem ser encontradas na pasta do projeto (`$PROD_DOCS`). Rascunhos WIP: `$SESSIONS_DIR/prod/`. Caso não estejam disponíveis localmente, utilize via Skill tool a `jarvis-docs-central` para buscar as informações no Central docs (se `CENTRAL_DOCS_STORAGE` estiver configurado).
 - Para trazer as informações, utilize via Skill tool a skill `product-roadmap-report`
@@ -39,10 +39,9 @@ Se o projeto tiver wiki de status report, usar URLs informadas pelo usuário ou
 
 | Passo | Skill | Condição |
 |-------|-------|----------|
-| Regras | `MCP do $TASK_MANAGER` | Se houver MCP disponível relacionado ao `$TASK_MANAGER` do usuário |
 | Regras | `/jarvis-docs-central` | Se as documentações do projeto não estiverem disponíveis localmente (via Skill tool) |
 | Regras | `/product-roadmap-report` | Sempre — via Skill tool, para trazer as informações do roadmap |
-| Status Reports por Squad / Dicas de Ferramenta | `MCP da Atlassian` (ex.: `Atlassian:searchJiraIssuesUsingJql`) | Para buscar os dados do roadmap no Jira, com o JQL ou o filtro salvo informado pelo usuário |
+| Regras / Dicas de Ferramenta | `acli jira workitem search` (CLI do vendor; `gh issue list` / `glab issue list` fora do Jira) | Para ler os dados do roadmap no board, com o JQL ou o filtro informado pelo usuário, se a CLI estiver logada |
 
 ## Formato de Períodos de Referência
 
@@ -62,24 +61,22 @@ Boards: usar o `board_code` de cada squad em `taxonomy.md` (se preenchido). Não
 
 Filtro de roadmap: pedir ao usuário o JQL ou o ID do filtro salvo no `$TASK_MANAGER`. Não usar filtro fixo.
 
-Utilize o MCP da Atlassian para buscar os dados do roadmap. Ele é pré-requisito manual: o `/jarvis-init` não configura MCP de board (board e git do Jarvis usam a CLI oficial). Sem o MCP, peça ao usuário para exportar ou colar os dados.
+Leia os dados do roadmap pela `acli`, com o login dela. Sem a `acli` logada (ou com `TASK_MANAGER_ACCESS=manual`), peça ao usuário para exportar ou colar os dados.
 Não precisa trazer informações embedadas do jira, apenas o output definido aqui nessa skill.
 
 ```
-Atlassian:searchJiraIssuesUsingJql
+acli jira workitem search --jql "{JQL}"   # ou --filter {ID} para o filtro salvo; confira os flags (campos, limite, formato) no --help
 JQL: (filtro informado pelo usuário ou montado a partir de board_code + labels)
 Campos a buscar: key, summary, status, priority, duedate, resolutiondate, assignee, labels, customfield (team, quadrimestre)
 ```
 
-**Importante**: Use `Atlassian:getAccessibleAtlassianResources` para obter o `cloudId` antes de fazer queries.
-
 
 ### Spaces no Jira
 
 Montar URLs com `{TASK_MANAGER_URL_BASE}` + `board_code` do `taxonomy.md`. Se `board_code` estiver vazio, perguntar o projeto ao usuário.
 
 ### Complemento com Jira (opcional)
-Você **pode** complementar com informações do Jira apenas se tiver informações suficientes para fazer a query corretamente (ex: o squad tem um board ou label bem definidos no Jira e você tem certeza do filtro).
+Você **pode** complementar com informações do Jira (lidas pela `acli`, como acima) apenas se tiver informações suficientes para fazer a query corretamente (ex: o squad tem um board ou label bem definidos no Jira e você tem certeza do filtro).
 
 ⚠️ **Se tiver dúvida sobre como filtrar no Jira, NÃO inclua dados do Jira**. Evite trazer informações erradas ou de outros squads.
 
@@ -88,7 +85,7 @@ Você **pode** complementar com informações do Jira apenas se tiver informaç
 
 Use a URL de status report que o usuário informar (ou a wiki configurada no projeto). Não há tabela fixa de squads.
 
-Use `web_fetch` para acessar a URL do time selecionado.
+Use `web_fetch` para acessar a URL do time selecionado (ou peça o texto colado).
 
 Busque os **dois últimos status reports** listados na página.
 Apresente os dois últimos reports no seguinte formato:
@@ -110,11 +107,10 @@ Apresente os dois últimos reports no seguinte formato:
 ## Dicas de Ferramenta
 
 ### Para dados do Jira
-1. Sempre chame `Atlassian:getAccessibleAtlassianResources` primeiro para obter o `cloudId`
-2. Use `Atlassian:searchJiraIssuesUsingJql` com o JQL adequado
-3. Para o roadmap, use o JQL/filtro informado pelo usuário
-4. Para campos customizados (team, quadrimestre), pode ser necessário chamar `Atlassian:getJiraIssueTypeMetaWithFields` para descobrir os IDs dos campos
-5. Links para issues do Jira devem ser no formato: `{TASK_MANAGER_URL_BASE}/browse/KEY-123`
+1. Use `acli jira workitem search` com o JQL adequado (flags no `--help`)
+2. Para o roadmap, use o JQL/filtro informado pelo usuário
+3. Para campos customizados (team, quadrimestre), peça ao usuário os IDs dos campos se a CLI não os mostrar
+4. Links para issues do Jira devem ser no formato: `{TASK_MANAGER_URL_BASE}/browse/KEY-123`
 
 ### Para dados da Wiki
 - Use `web_fetch` diretamente nas URLs dos reports

package/workflows/product/prod.spec.ard.md

@@ -86,7 +86,7 @@ Apresente o **resumo dos requisitos arquiteturais** (por tópico do Gate 2, marc
 ### Gate 4: Conduzir o ARD
 1. Avise, antes de seguir, que a próxima etapa é o fluxo de engenharia e que as decisões de arquitetura passam a ser da engenharia.
 2. Execute o workflow `eng.create-ard` no modo `new`, com o nome do ARD e `--prd <caminho>` quando houver PRD de origem, entregando o resumo do Gate 3 como insumo do documento (seções de premissas, restrições, integrações, segurança, escalabilidade e riscos do template).
-3. O `eng.create-ard` cuida de numeração, versão, preenchimento do template, análise de impacto, estratégia de testes, guard rails e publicação no central docs. Siga as instruções dele a partir daí.
+3. O `eng.create-ard` cuida de numeração, versão, preenchimento do template, análise de impacto, estratégia de testes, guard rails e a consulta ao Central docs (o ARD fica em `$ENG_DOCS`; não é publicado lá). Siga as instruções dele a partir daí.
 
 ### Gate 5: Fechar
 1. Informe o caminho do ARD criado e o que ficou "a validar pela engenharia".
@@ -100,6 +100,6 @@ Apresente o **resumo dos requisitos arquiteturais** (por tópico do Gate 2, marc
 
 ## Don't
 - Escolher tecnologia, desenhar componentes ou definir contratos aqui (isso é do ARD, pela engenharia)
-- Duplicar o `eng.create-ard`: numeração, template e publicação são dele
+- Duplicar o `eng.create-ard`: numeração, template e gravação em `$ENG_DOCS` são dele
 - Criar o ARD sem o resumo confirmado no Gate 3
 - Alterar o PRD ou o FRD de origem sem o usuário pedir

package/workflows/product/prod.spec.breakdown.md

@@ -64,9 +64,9 @@ Utilize o `$ARGUMENTS` como ponto de partida (caminho da spec, nome da feature o
 
 O artefato de breakdown segue o template `$PROD_TEMPLATES/prod-breakdown-template.md`.
 
-## Busca no Central Docs (condicional)
+## Busca de contexto (`$PROD_DOCS` sempre; Central docs se configurado)
 
-Se `CENTRAL_DOCS_STORAGE` estiver no `ENV.md`:
+O Documento de Requisitos de Produto / funcional vem sempre de `$PROD_DOCS`. Se `CENTRAL_DOCS_STORAGE` estiver no `ENV.md`, além disso:
 
 1. `jarvis docs sync --silent` (best-effort)
 2. Localizar no Central docs as funcionalidades já implementadas relacionadas (nome, tags, `TASK_MANAGER_KEY`); o Documento de Requisitos de Produto / funcional vem de `$PROD_DOCS`