jarvis-ai-framework 7.0.0 → 8.2.0

package/rules/engineering/eng.integrations-rules.md

@@ -9,7 +9,7 @@ O Jarvis não assume Jira, GitLab ou Slack. Leia `$IDE/ENV.md` e siga a cadeia d
 | Variável | Vendors | Como |
 |----------|---------|------|
 | `TASK_MANAGER` (+ `TASK_MANAGER_ACCESS`, `TASK_MANAGER_URL_BASE`) | jira (`acli`, só Cloud), github (`gh`), gitlab (`glab`) | `jarvis tasks comment` |
-| `VERSION_CONTROL` (+ `VERSION_CONTROL_ACCESS`) | github (`gh`), gitlab (`glab`); repo vem do `git remote` | `jarvis vcs create-merge` / `create-issue` |
+| `VERSION_CONTROL` (+ `VERSION_CONTROL_ACCESS`) | github (`gh`), gitlab (`glab`); no `create-merge` o repo vem do `git remote`, no `create-issue` vai em `--repo` | `jarvis vcs create-merge` / `create-issue` |
 | `CENTRAL_DOCS_STORAGE` | filesystem (s3 e gdrive no futuro) | `jarvis docs fetch` / `sync` / `publish` |
 | `MESSAGE_COMUNICATOR` | slack, discord, teams | runtime `communicator/` |
 
@@ -41,11 +41,15 @@ Qual o seu número de controle para esta tarefa?
 
 Com board definido, se o key não veio nos argumentos, perguntar o id do card naquele vendor (ex: Jira `TASK-123`, GitHub `#42`).
 
+## Nada é publicado sem perguntar
+
+É a **regra de ouro**: comentário, PR/MR, issue, push e publicação no Central docs só saem depois de mostrar o texto e perguntar, na hora do envio, com `AskUserQuestion` (sem a ferramenta, a tabela de `prod-rules.md`): **Sim, publicar** / **Não, manter só na sessão** (rótulos equivalentes por contexto). A pergunta vale para cada envio; uma aprovação não vale para o próximo. **Exceção:** documentos aprovados juntos (como a consolidação do `eng.spec-consolidate`) são um envio; e a escolha da Fase 0 do `eng.pr` vale como a pergunta do push e do PR e, conforme a opção, como a revisão do texto. Sem o Sim, o texto fica na sessão (`task-comment-{YYYYMMDD-HHMM}.md`, `pull-request.md`) ou em `.jarvis/issues/`, e o push fica só local.
+
 ## Comentário no card
 
 Falha no comentário não bloqueia o workflow.
 
-Comentar **somente** em eventos relevantes: (a) **desvio do plano** (mudança de direção, fase bloqueada), (b) **auditoria do Advisor** (as questões do `architecture.md` com as opções junto da escolha), (c) **bloqueio** com valor de rastreabilidade, (d) **link do MR**, uma única vez, (e) o **`gate-checklist.md` do `eng.pre-pr`**, só se o usuário escolher registrar (resumo ou relatório completo). **Nunca** comentar início ou fim de etapa ("Iniciando…", "concluído…"): o acompanhamento fica no fluxo e no PR.
+Comentar **somente** em eventos relevantes, **cada um depois da pergunta acima**: (a) **desvio do plano** (mudança de direção, fase bloqueada), (b) **auditoria do Advisor** (as questões do `architecture.md` com as opções junto da escolha), (c) **bloqueio** com valor de rastreabilidade, (d) **link do MR**, uma única vez, (e) o **`gate-checklist.md` do `eng.pre-pr`**, só se o usuário escolher registrar (resumo ou relatório completo), (f) a arquitetura do **`eng.light-arch`**, depois de aprovada, (g) outro comentário que o fluxo peça e você aprove (como o de refinamento do agente de QA e o da 7.4 do `delivery-spec`). **Nunca** comentar início ou fim de etapa ("Iniciando…", "concluído…"): o acompanhamento fica no fluxo e no PR.
 
 ```
 /eng-global-task-comment {TASK_MANAGER_KEY} {mensagem}

package/rules/rtk-rules.md

@@ -60,7 +60,7 @@ cargo install brokk-rtk
 cargo install rtk  # ❌ Isso instala Rust Type Kit, não Token Killer
 ```
 
-Use o comando `npx jarvis install-rtk` que valida e instala a ferramenta correta automaticamente.
+Use o comando `jarvis install-rtk` que valida e instala a ferramenta correta automaticamente.
 
 ---
 

package/rules-on-demand/doc-links-rules.md

@@ -12,7 +12,7 @@ Lida pelo comando antes de escrever o documento. A tabela mostra quem lê:
 
 | Documento | Comando |
 |---|---|
-| `architecture.md`, `plan.md` (inclusive os comentários de fase), `gate-checklist.md`, `pull-request.md` | `eng.start`, `eng.plan`, `eng.work`, `eng.pre-pr`, `eng.pr` |
+| `architecture.md`, `plan.md` (inclusive os comentários de fase), `gate-checklist.md` (e as rodadas anteriores `gate-checklist-rodada-{N}.md`), `pull-request.md` | `eng.start`, `eng.plan`, `eng.work`, `eng.pre-pr`, `eng.pr` |
 | PRD, FRD, épico, história/tarefa, discovery, breakdown | `prod.spec.prd`, `prod.spec.frd`, `prod.spec.epic`, `prod.spec.issue`, `prod.spec.discovery`, `prod.spec.breakdown`, `prod.spec.clarify` |
 | ARD, RFC, SPEC | `prod.spec.ard`, `eng.create-ard`, `eng.create-ard-from-code`, `eng.create-rfc`, `eng.build-tech-spec` |
 | Outros documentos gravados por comando (subtarefas, arquitetura leve, relatório de investigação, documentação do repositório (regra 7), revisão, robô, Central docs) | `eng.breakdown-subtasks`, `eng.light-arch`, `eng.debug`, `eng.docs`, `eng.review`, `eng.rpa.robot`, `eng.spec-consolidate` |
@@ -52,7 +52,7 @@ Lida pelo comando antes de escrever o documento. A tabela mostra quem lê:
    - Issue, PR e card como URL.
    - Código como `{remote}/blob/{sha}/{caminho}#L{n}` (GitLab: `{remote}/-/blob/{sha}/…`). O trecho é `#L{a}-L{b}` no GitHub e `#L{a}-{b}` no GitLab.
    - Sessão e `docs/jarvis/` em texto, sem link: quem lê fora do workspace não abre esses arquivos.
-   - O `{sha}` é o `HEAD` no momento em que o `eng.pr` escreve o `pull-request.md` (Fase 4.1). Se a conferência de marcas (Fase 3.0) reescrever commits, atualize o sha dos links. Com "Só gerar os arquivos", os links valem quando o push for feito sem rebase.
+   - O `{sha}` é o `HEAD` no momento em que o `eng.pr` escreve o `pull-request.md` (Fase 4.1). Se a conferência de marcas (Fase 3.0) reescrever commits, atualize o sha dos links. Com "Só gerar os arquivos" (na Fase 0 ou na revisão da 4.2), os links valem quando o push for feito sem rebase.
    - No Central docs, o `{sha}` é o do merge na branch base (a consolidação roda depois do merge).
    - No `.public.md` (gerado no fim do próprio comando, muitas vezes sem push), o `{sha}` é o último commit já enviado ao remoto (`git rev-parse @{u}`), ou o sha do cabeçalho se ele já estiver no remoto. Sem nenhum dos dois, o código fica em texto.
 7. **Documento versionado no repositório** (`README.md`, `docs/` do projeto, gravados por exemplo pelo `eng.docs`): o caminho é relativo dentro do próprio repositório (nada de subir até o workspace com `../../{repo}/…`), porque ele é lido no GitHub/GitLab. A sessão e o `docs/jarvis/` ficam em texto, sem link.

package/rules-on-demand/engineering/eng.breakdown-subtasks-rules.md

@@ -11,7 +11,7 @@ O workflow `breakdown-subtasks` tem como objetivo **quebrar uma Tech Spec em sub
 ## ⚠️ REGRA INVIOLÁVEL: PRINCÍPIO DE INDEPENDÊNCIA
 
 > **Cada subtarefa é uma unidade de entrega completa e independente.**
-> Cada subtarefa será um card no `$TASK_MANAGER` com **sua própria branch, seu próprio commit e seu próprio deploy**.
+> Cada subtarefa será um card no `$TASK_MANAGER` (criado pela pessoa a partir do Markdown que este comando entrega) com **sua própria branch, seu próprio commit e seu próprio deploy**.
 > Por isso, a subtarefa precisa ser **mergeável isoladamente sem quebrar o sistema**.
 
 **Toda subtarefa deve ser uma fatia vertical completa (vertical slice):**

package/rules-on-demand/engineering/eng.plan-rules.md

@@ -211,6 +211,7 @@ Para cada tarefa, incluir:
 
 ### Fase 5: Validação
 
+0. **Executar** o Checklist de Conclusão (abaixo) item a item contra o `plan.md` e corrigir o plano antes de apresentar (passe crítico, Fase 4 do workflow)
 1. **Apresentar** o plano ao humano
 2. **Discutir** ajustes necessários
 3. **Atualizar** `architecture.md` se houver mudanças arquiteturais
@@ -300,6 +301,7 @@ Antes de considerar o plano completo:
 - [ ] Dependências estão claras (sequencial/paralelo)
 - [ ] Status iniciais definidos (todos ⏳)
 - [ ] Conteúdo em português (pt-BR)
+- [ ] Passe crítico executado (este checklist conferido item a item) e "Ajustes antes da aprovação" atualizado no cabeçalho a cada "Ajustar o plano"
 - [ ] Validado com o humano
 - [ ] `plan.md` criado em `$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/`
 

package/rules-on-demand/engineering/eng.pr-rules.md

@@ -4,7 +4,7 @@
 
 ## Propósito
 
-O workflow `pr` tem como objetivo **criar a branch, commitar as alterações e abrir um Merge Request** seguindo os padrões do time.
+O workflow `pr` tem como objetivo **gerar o `pull-request.md` e, depois da pergunta (regra de ouro), fazer o push e abrir um Merge Request** seguindo os padrões do time.
 
 ---
 
@@ -137,11 +137,11 @@ sempre utiliza a branch main)
 │        ↓                                                    │
 │  4. COMMIT → Mensagem padronizada                           │
 │        ↓                                                    │
-│  5. PUSH → Enviar para remote                               │
+│  5. PUSH → Enviar para remote (depois da Fase 0)            │
 │        ↓                                                    │
-│  6. CRIAR MR (desenvolvedor) → Com template preenchido      │
+│  6. CRIAR MR (desenvolvedor) → Template, depois da Fase 0   │
 │        ↓                                                    │
-│  7. ATUALIZAR JIRA (desenvolvedor) → Mover para "In Review" │
+│  7. ORIENTAR (desenvolvedor) → Mover o card para "In Review"│
 │                                                             │
 └─────────────────────────────────────────────────────────────┘
 ```
@@ -199,6 +199,8 @@ sempre utiliza a branch main)
 
 ### Fase 4: Push
 
+O push só sai depois da escolha de publicar da Fase 0 do `eng.pr` (regra de ouro, `eng.integrations-rules.md`).
+
 1. **Enviar para remote**
    ```bash
    git push -u origin {nome-da-branch}
@@ -331,8 +333,8 @@ Antes de considerar o PR completo:
 ## Sessão e publicação
 
 - O texto do PR fica em **`$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/pull-request.md`**, aprovado pelo usuário.
-- **Publicar (push + MR/PR) só com a escolha "Revisar o texto e publicar" (depois da aprovação do texto) ou "Publicar sem revisar o texto"** da Fase 0 (`eng.transitions-rules.md`). Com "Só gerar os arquivos", o arquivo fica na sessão e nada é enviado.
-- **A sessão nunca é apagada por este comando:** o `/eng.spec-consolidate`, que roda depois do merge, precisa do `architecture.md`, do `plan.md`, do `gate-checklist.md` e do `pull-request.md`. A pessoa apaga à mão quando quiser.
+- **Publicar (push + MR/PR) só com a escolha "Revisar o texto e publicar" (depois da aprovação do texto) ou "Publicar sem revisar o texto"** da Fase 0 (`eng.transitions-rules.md`). Com "Só gerar os arquivos" (na Fase 0 ou no `[Só gerar os arquivos]` da revisão do texto), o arquivo fica na sessão e nada é enviado.
+- **A sessão nunca é apagada por este comando:** o `/eng.spec-consolidate`, que roda depois do merge, precisa do `architecture.md`, do `plan.md`, do `gate-checklist.md` (com as rodadas anteriores `gate-checklist-rodada-{N}.md`, se houver) e do `pull-request.md`. A pessoa apaga à mão quando quiser.
 
 ## daily.md (registro do esforço)
 

package/rules-on-demand/engineering/eng.pre-pr-rules.md

@@ -75,9 +75,11 @@ Avaliar **apenas** as mudanças da branch atual em relação à branch base (`Br
 git diff {BRANCH_BASE}...HEAD
 ```
 
+Da rodada 2 em diante, cada gate roda só se o diff desde o `Commit:` da rodada anterior tocar o que ele lê (seção "Rodada incremental" do `eng.pre-pr.md`). O gate que roda continua revisando a branch inteira.
+
 ### Evidências Obrigatórias
 
-Cada lacuna cita onde está (`arquivo:linha`) ou o comando que a revelou e o resultado.
+Cada lacuna cita onde está (`arquivo:linha` com o trecho) ou o comando que a revelou e o resultado, **e o que a derrubaria** (coluna Refutação). Antes de gravar, o passe crítico (seção "Passe crítico" do `eng.pre-pr.md`) remove a lacuna cuja refutação se sustenta e rebaixa a que pesa menos do que a severidade dada.
 
 ---
 
@@ -86,7 +88,12 @@ Cada lacuna cita onde está (`arquivo:linha`) ou o comando que a revelou e o res
 O workflow **deve sempre** terminar com:
 
 1. **`gate-checklist.md`** em `$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/`:
-   - semáforo (🟢 / 🟡 / 🔴), resumo, lacunas por área (o quê, onde, por que importa, sugestão, severidade, **Decisão**), evidências e PR Brief.
-2. **Decisões do usuário** gravadas na coluna Decisão (Corrigir / Aceitar + motivo; vazia se o usuário escolheu "Só gerar o relatório").
+   - semáforo (🟢 / 🟡 / 🔴), resumo (com a linha `Critério de parada:`), lacunas por área (o quê, com o "(item N)" do gate que a achou no fim, onde, por que importa, refutação, sugestão, severidade, **Decisão**), evidências e PR Brief (com as rodadas por severidade, a rodada em que o critério de parada agiu, os ajustes do `architecture.md` e do `plan.md` antes da aprovação e as lições desta tarefa; guardar lições entre tarefas não é deste comando, é da #169).
+   - `Rodada` e `Commit` no cabeçalho, as rodadas anteriores e, da rodada 2 em diante, a resolução das lacunas da rodada anterior.
+   - Da rodada 2 em diante, as áreas cujos gates não rodaram na rodada incremental, marcadas como "Não reavaliada nesta rodada".
+   - É sempre a rodada mais recente: ao rodar de novo na mesma sessão, o relatório existente é preservado como `gate-checklist-rodada-{N}.md` (seção "Rodadas" do `eng.pre-pr.md`). **Nunca** sobrescrever nem apagar uma rodada; renomear imediatamente antes de gravar.
+2. **Decisões do usuário** gravadas na coluna Decisão (🔧 Corrigir / 👍 Aceitar + motivo; vazia se o usuário escolheu "Só gerar o relatório", exceto as decisões herdadas da rodada anterior). Na variante B do fechamento, as ⚪ aceitas levam `👍 Aceitar: aceito no fechamento da rodada {N}` e as 🟡 aceitas em bloco (só com o teto atingido) levam `👍 Aceitar: teto de rodadas atingido na rodada {N}`, e as decididas uma a uma levam o motivo dado pela pessoa; decisão herdada nunca é trocada.
+   - **Critério de parada** (seção "Fechamento" do `eng.pre-pr.md`): teto de rodadas pela urgência do `context.md` (`alta` 3 · `normal` 5 · `baixa` 8) ou rodada sem lacuna 🔴 ou 🟡 nova (com os itens 2 e 3 tendo rodado). Sem 🔴 pendente nem 🟡 herdada com `🔧 Corrigir`, e com só ⚪ sem decisão (ou também 🟡, com o critério de parada atingido), o fechamento usa a variante B. Na variante B, "Aceitar as ⚪ e seguir para o PR" é a primeira opção (a recomendada) e "Só gerar o relatório" mantém o fluxo de hoje. Só o teto aceita 🟡 em bloco; com o gatilho "sem lacuna nova", as 🟡 são decididas uma a uma. O critério nunca pula a revisão nem a gravação. Fora desses casos (por exemplo, com 🔴 pendente), o ciclo segue na variante A. Sempre que o teto for atingido e houver pendência, o fechamento avisa.
+   - **Pendentes não reavaliadas** (rodada incremental): a lacuna pendente da rodada anterior cujo gate de origem (o "(item N)" da coluna Lacuna) não rodou é copiada para a rodada nova, com a decisão herdada.
 3. **Pergunta** (`AskUserQuestion`) sobre registrar o resultado como comentário no card (`/eng-global-task-comment`): Não, manter só na sessão (como hoje) / Sim, só o resumo / Sim, o relatório completo. Nunca publicar sem a resposta. Freelance: não pergunta, só na sessão.
 4. **Aguardar permissão explícita** do usuário para prosseguir para `/eng.pr`.

package/rules-on-demand/engineering/eng.start-rules.md

@@ -40,11 +40,11 @@ Além dele, o `start` pode criar apenas os arquivos de apoio da própria sessão
 
 O workflow **só é considerado completo** após:
 
-1. O `architecture.md` estar preenchido
+1. O `architecture.md` estar preenchido, com o passe crítico feito (Fase 4.4 do workflow: seção 2.5 "Premissas e Passe Crítico", com o lido separado do presumido e a premissa que derrubaria o documento)
 2. O usuário revisar o documento
-3. O usuário **aprovar explicitamente** para prosseguir — sem Advisor, pela pergunta de transição "Aprovar o architecture.md?" (`eng.transitions-rules.md`)
+3. O usuário **aprovar explicitamente** para prosseguir, pela pergunta de transição "Aprovar o architecture.md?" (`eng.transitions-rules.md`): sempre sem Advisor e, com Advisor, sempre que a aprovação for obrigatória (autonomia `média` ou `baixa`, ou questão nova do passe crítico)
 
-**Exceção (Advisor):** se o usuário escolheu usar o Advisor no início do `eng.start`, as questões em aberto são decididas pela sugestão dele e o gate segue a autonomia do `context.md`: com `autonomia: alta` o `start` apresenta o resumo e segue para o `eng.plan` sem aguardar; com `média` ou `baixa`, a aprovação explícita continua obrigatória.
+**Exceção (Advisor):** se o usuário escolheu usar o Advisor no início do `eng.start`, as questões em aberto são decididas pela sugestão dele e o gate segue a autonomia do `context.md`: com `autonomia: alta` o `start` apresenta o resumo e segue para o `eng.plan` sem aguardar, salvo se o passe crítico (Fase 4.4) abriu questão nova: nesse caso, a aprovação explícita da pessoa é obrigatória; com `média` ou `baixa`, a aprovação explícita continua obrigatória.
 
 ---
 
@@ -91,8 +91,8 @@ O workflow **só é considerado completo** após:
 
 7. **Aguardar aprovação**
    - Se aprovado → Informar próximos passos
-   - Se rejeitado → Iterar no documento
-   - NUNCA prosseguir sem a resposta: "Aprovar e seguir para o `/eng.plan`" (pergunta de transição, `eng.transitions-rules.md`) é a aprovação para seguir; a exceção do Advisor continua valendo
+   - Se rejeitado → Iterar no documento, somar 1 em "Ajustes antes da aprovação" no cabeçalho e refazer o passe crítico no que mudou
+   - NUNCA prosseguir sem a resposta: "Aprovar e seguir para o `/eng.plan`" (pergunta de transição, `eng.transitions-rules.md`) é a aprovação para seguir; a exceção do Advisor continua valendo, sem questão nova aberta pelo passe crítico
 
 ---
 
@@ -238,6 +238,8 @@ Antes de considerar o `start` completo:
 - [ ] Decisões têm justificativas
 - [ ] Riscos têm mitigações
 - [ ] Componentes impactados listados com caminhos reais
+- [ ] Passe crítico feito: seção 2.5 preenchida, presumidas que mudam o plano lidas ou viradas questão
+- [ ] "Ajustes antes da aprovação" atualizado no cabeçalho
 - [ ] Usuário revisou o documento
 - [ ] Usuário aprovou explicitamente
 - [ ] Nenhum código foi executado/criado

package/rules-on-demand/engineering/eng.tech-spec-rules.md

@@ -34,7 +34,7 @@ O `/eng.build-tech-spec` tem dois modos, escolhidos na triagem do workflow:
 
 ## Localização de Arquivos
 
-> **NOTA**: Tech specs NÃO são salvas em `master-docs/`. São salvas na sessão do projeto e anexadas no Jira.
+> **NOTA**: Tech specs NÃO são salvas em `master-docs/`. São salvas na sessão do projeto; o anexo na issue do board só sai depois da pergunta (regra de ouro; Jira pela `acli`, em GitHub/GitLab a pessoa anexa).
 
 Arquivos são referenciados usando `$IDE/` que resolve automaticamente para a pasta do IDE atual (`.windsurf/`, `.claude/`, `.cursor/`).
 
@@ -82,10 +82,10 @@ $SESSION_FOLDER/{TASK_MANAGER_KEY}/tech-spec.md
 
 ### Por que na sessão?
 
-1. **Anexo no Jira**: A tech spec é anexada diretamente na issue do Jira como fonte da verdade
+1. **Anexo na issue**: a tech spec pode ser anexada na issue do board (Jira pela `acli`; em GitHub/GitLab a pessoa anexa, orientada), só depois de mostrar o que vai e perguntar (regra de ouro, `eng.integrations-rules.md`); sem o Sim, fica só na sessão
 2. **Sessão temporária**: A sessão é usada durante o desenvolvimento e pode ser limpa depois
 3. **Evita poluição**: Não cria arquivos permanentes no repositório de código
-4. **Rastreabilidade**: O Jira é o sistema oficial de documentação de tasks
+4. **Rastreabilidade**: o board (`TASK_MANAGER`) é o sistema oficial das tarefas; a criação automática de subtarefas é só no Jira (`acli`), nos outros a pessoa cria pelo template
 
 ### Nomenclatura
 
@@ -106,14 +106,14 @@ $SESSION_FOLDER/{TASK_MANAGER_KEY}/tech-spec.md
 
 **O que isso significa:**
 
-- Link para história do Jira no topo do documento
+- Link para a história (card do board) no topo do documento
 - Referência aos critérios de aceitação de produto
 - Conexão clara entre requisitos de negócio e decisões técnicas
 - IDs de subtarefas vinculadas à história pai
 
 **Validação:**
 
-- [ ] Link para Jira funciona
+- [ ] Link para o card funciona
 - [ ] Critérios de aceitação de produto estão documentados
 - [ ] Cada subtarefa referencia a tech spec
 - [ ] Tech spec referencia PRD/FRD se existirem
@@ -616,9 +616,9 @@ Use formato YAML frontmatter:
 ---
 name: { nome descritivo da tech spec }
 id: { TECH-001 }
-related_story: { STORY-XXX do Jira }
+related_story: { STORY-XXX do board }
 epic_related: { EPIC-XXX se existir }
-link_task: { URL da história no Jira }
+link_task: { URL da história no board }
 created_at: { YYYY-MM-DD }
 updated_at: { YYYY-MM-DD }
 status: { Draft, In Review, Approved, Implemented }
@@ -772,6 +772,8 @@ Use este checklist antes de finalizar uma tech spec:
 
 ## Integração com Jira
 
+> **Escopo:** a criação automática de subtarefas é só no Jira, pela `acli`, depois da pergunta (regra de ouro); em GitHub e GitLab a pessoa cria pelo template.
+
 ### Criação de Subtarefas
 
 **Formato de Descrição no Jira:**

package/rules-on-demand/engineering/eng.transitions-rules.md

@@ -19,8 +19,8 @@ Lida pelos workflows `eng.start`, `eng.plan`, `eng.work`, `eng.pre-pr` e `eng.pr
 3. **A resposta é a aprovação.** "Aprovar e seguir" ou "Aprovar e parar aqui" valem como a aprovação explícita que as rules de cada comando exigem. Sem uma dessas respostas, nada avança.
 4. **Seguir para o próximo comando:** se a IDE permite chamar outro comando (no Claude Code, pelo Skill tool), chame-o com o mesmo `{TASK_MANAGER_KEY}`; senão, mostre o comando pronto para colar.
 5. **Consolidado de links, acumulado a cada etapa.** Ao terminar e antes de **cada pergunta de transição** (todas as da tabela "Transições", inclusive as do início, como "O que fazer com o PR?", e mesmo quando a pergunta é repetida), cada comando mostra o bloco "📄 Arquivos da sessão" com **todos** os arquivos que já existem na sessão, e não só os da etapa, para que a lista fique sempre visível até o `eng.spec-consolidate`:
-   - Ordem do ciclo: `context.md`, `architecture.md`, `plan.md`, `gate-checklist.md`, `pull-request.md`, `daily.md`, as versões `{nome}.public.md` (se houver) e os arquivos de `consolidation/` (do `eng.spec-consolidate`). Só entra o que existe.
-   - Cada item é um link markdown com caminho relativo ao workspace (ex.: `[architecture.md](.jarvis/sessions/eng/TASK-123/architecture.md)`), seguido de uma **nota curta de estado** entre parênteses: `novo` ou `atualizado` quando foi gerado ou alterado nesta etapa, mais o que mudou ou o que o arquivo contém (ex.: `plan.md (atualizado, com comentários por fase)`, `architecture.md (aprovado; 5 questões decididas)`, `daily.md (novo; aprovado, com timesheet)`). Os arquivos que não mudaram na etapa aparecem sem nota ou com o estado em que ficaram.
+   - Ordem do ciclo: `context.md`, `architecture.md`, `plan.md`, as rodadas anteriores `gate-checklist-rodada-{N}.md` (uma por rodada, em ordem crescente do número do nome, se houver), `gate-checklist.md`, `pull-request.md`, `daily.md`, as versões `{nome}.public.md` (se houver) e os arquivos de `consolidation/` (do `eng.spec-consolidate`). Só entra o que existe.
+   - Cada item é um link markdown com caminho relativo ao workspace (ex.: `[architecture.md](.jarvis/sessions/eng/TASK-123/architecture.md)`), seguido de uma **nota curta de estado** entre parênteses: `novo` ou `atualizado` quando foi gerado ou alterado nesta etapa, mais o que mudou ou o que o arquivo contém (ex.: `plan.md (atualizado, com comentários por fase)`, `architecture.md (aprovado; 5 questões decididas)`, `daily.md (novo; aprovado, com timesheet)`, `gate-checklist-rodada-1.md (rodada 1; 27 lacunas)`, `gate-checklist.md (rodada 2, atual; 13 lacunas)`). Os arquivos que não mudaram na etapa aparecem sem nota ou com o estado em que ficaram.
    - A lista é **reimpressa inteira** a cada etapa, sem esconder os arquivos anteriores.
    - Logo abaixo, "🔗 Links" com o card/issue e, quando existir, o PR/MR.
    - **Antes de cada pergunta de transição**, escreva primeiro essa mensagem em markdown, com o resumo, e só então abra o `AskUserQuestion`. Isso vale também para as perguntas que não dependem de um arquivo: a lista é o mapa de onde a tarefa está no ponto de decisão. Na pergunta que depende de um arquivo (`architecture.md`, `plan.md`, `gate-checklist.md`, `pull-request.md`, `daily.md`), o resumo é o desse arquivo. A pergunta fica curta, só com a decisão e o nome do arquivo em texto simples; ela espera a resposta enquanto a pessoa abre e lê com calma. Não dependa do link dentro do `AskUserQuestion`.
@@ -37,19 +37,20 @@ Lida pelos workflows `eng.start`, `eng.plan`, `eng.work`, `eng.pre-pr` e `eng.pr
 | Comando | Quando | Pergunta | Opções (padrão primeiro) |
 |---|---|---|---|
 | `eng.start` | Início, só **sem Advisor** | "Como tratar as questões em aberto que surgirem?" | Tratar no architecture.md (como hoje) · Uma a uma, assim que surgirem |
-| `eng.start` | Fim, só **sem Advisor** | "Aprovar o architecture.md?" | Aprovar e parar aqui (como hoje) · Aprovar e seguir para o `/eng.plan` · Ajustar o documento |
+| `eng.start` | Fim, **sem Advisor**, ou com Advisor quando a aprovação é obrigatória (autonomia `média`/`baixa`, ou questão nova do passe crítico) | "Aprovar o architecture.md?" | Aprovar e parar aqui (como hoje) · Aprovar e seguir para o `/eng.plan` · Ajustar o documento |
 | `eng.plan` | Fim | "O que fazer com o plano?" | Aprovar e implementar agora · Aprovar e seguir manualmente (como hoje) · Ajustar o plano |
 | `eng.work` | Início | Execução | Fase a fase, com aprovação (como hoje) · Todas de uma vez ("N de M tarefas", pelo limite) |
 | `eng.work` | Início | Commits | Um por fase (como hoje) · Um commit só ao final |
 | `eng.work` | Início | Depois do work | Rodar o `/eng.pre-pr` · Rodar o `/eng.pr` · Fluxo normal (como hoje: o usuário segue os próximos comandos manualmente) |
 | `eng.pre-pr` | Fim | Com lacunas: "Como seguir?" (depois da mensagem com o link do relatório) | Corrigir as lacunas agora · Parar aqui para corrigir à mão (como hoje) · Abrir o PR assim mesmo |
 | `eng.pre-pr` | Fim | Sem lacunas: "Como seguir?" | Abrir o PR agora · Parar aqui (como hoje) |
-| `eng.pr` | Início | "O que fazer com o PR?" | Revisar o texto e publicar (como hoje) · Publicar sem revisar o texto · Só gerar os arquivos (o usuário abre o PR à mão) |
+| `eng.pre-pr` | Fim | Variante B do fechamento (sem 🔴 pendente nem 🟡 herdada com `🔧 Corrigir`; só ⚪ sem decisão, ou também 🟡 com o critério de parada atingido): "Restam {c} lacunas ⚪… Como seguir?" (substitui as perguntas 2 e 4 do fechamento; com 🟡 sem decisão, o rótulo da primeira opção varia conforme o gatilho: ver o "Fechamento" do `eng.pre-pr.md`) | Aceitar as ⚪ e seguir para o PR · Corrigir antes do PR · Só gerar o relatório (como hoje) |
+| `eng.pr` | Início | "O que fazer com o PR?" | Revisar o texto e publicar (como hoje) · Publicar sem revisar o texto · Só gerar os arquivos (o usuário abre o PR à mão; quem escolheu revisar também tem o `[Só gerar os arquivos]` na revisão da 4.2) |
 | `eng.pr` | Fim | "O PR já foi aprovado e mergeado?" | Ainda não (como hoje) · Sim, rodar o `/eng.spec-consolidate` |
 
-Nas perguntas "Depois do work" e "O que fazer com o plano?", a opção "como hoje" não é a primeira (em "Depois do work" fica por último), por escolha de produto: as primeiras opções são as ações que o usuário mais quer. Mesmo assim, é o fluxo que vale quando o usuário não escolhe.
+Nas perguntas "Depois do work", "O que fazer com o plano?" e na variante B do fechamento do `eng.pre-pr`, a opção "como hoje" não é a primeira (em "Depois do work" e na variante B fica por último), por escolha de produto: as primeiras opções são as ações que o usuário mais quer. Na variante B, a #191 pede "Aceitar as ⚪ e seguir para o PR" como primeira opção (a recomendada), para lacunas menores não gerarem mais uma rodada. Mesmo assim, é o fluxo que vale quando o usuário não escolhe.
 
-**Com Advisor**, o `eng.start` não ganha pergunta nova: o Advisor decide as questões em aberto e o gate do fim segue a autonomia do `context.md`, como já estava.
+**Com Advisor**, o `eng.start` não ganha pergunta nova: o Advisor decide as questões em aberto e o gate do fim segue a autonomia do `context.md`, como já estava, salvo se o passe crítico (Fase 4.4 do `eng.start`) abriu questão nova: nesse caso, como com autonomia `média` ou `baixa`, a aprovação explícita é obrigatória e é pedida pela pergunta "Aprovar o architecture.md?" da tabela.
 
 ### Recomendado
 

package/skills/AGENTS.md

@@ -229,7 +229,7 @@ Skills são invocados de formas diferentes dependendo da IDE:
 |-------------------|-------|
 | `/jarvis-init` | `jarvis-init` |
 | `/warm-up` | `jarvis-docs-central` (só o recorte escolhido), `context7` (se o MCP estiver disponível) |
-| `eng.start` | `jarvis-docs-central` (buscar PRD/ARD) |
+| `eng.start` | `jarvis-docs-central` (funcionalidades implementadas; PRD/ARD vêm de `docs/jarvis/`) |
 | `/eng.docs` | `eng-global-docs-write`, `jarvis-docs-index` |
 | `/eng.pre-pr` | `eng-qa-planner`, `eng-global-docs-write`, `jarvis-docs-central` (detectar docs) |
 | `/eng.pr` | `eng-global-pr` |
@@ -254,7 +254,7 @@ Skills são invocados de formas diferentes dependendo da IDE:
 | RPA, web scraping, Puppeteer, extração de dados, parsing, ETL | `eng-automation` (base) + `AUTOMATION_SPECIALIZATIONS` |
 | Criar robô RPA novo ou manter existente (new|update + card) | `eng.rpa.robot` (workflow) |
 | Planejar capacidade QA da sprint: risco por task, alocação entre QAs e Quality Champions | workflow `eng.qa-sprint-planning` |
-| Sign-off QA pré-deploy: verifica cobertura, bugs abertos, produz GO/NO-GO + snippet CI para TL | workflow `eng.qa-release-signoff` |
+| Sign-off QA pré-deploy: verifica cobertura, bugs abertos, produz GO/NO-GO | workflow `eng.qa-release-signoff` |
 | Pipelines ETL/ELT, modelagem, qualidade, BI/dashboards, governança, onboarding de fonte, orquestração | `eng-data` (base) + `DATA_SPECIALIZATIONS` |
 | Criar pipeline novo (docs, qualidade, idempotência, gold) | `data.new-pipeline` |
 | Criar contrato de dados para squad requisitante | `data.contract` |

package/skills/SKILLS-ROADMAP.md

@@ -114,8 +114,8 @@ Skills existentes e planejadas do framework Jarvis.
 - **Status**: `criado`
 
 ### `product-specs-update` ✅
-- **Trigger**: atualização de specs existentes
-- **Escopo**: revisão e evolução de requisitos
+- **Trigger**: PRD ou FRD criado ou modificado; pedido para sincronizar ou indexar specs
+- **Escopo**: sincroniza PRD/FRD em cascata e mantém o índice local de specs (`$PROD_DOCS/specs-index.md`)
 - **Status**: `criado`
 
 ### `product-roadmap-report` ✅
@@ -138,7 +138,7 @@ Removidas: `checkin`, `checkout`, `daily`, `task-log`, `send-priority`, `sent-pr
 - **Status**: `criado`
 
 ### `jarvis-report-issue` ✅
-- **Trigger**: auto-report de bugs no framework Jarvis via GitLab API
+- **Trigger**: auto-report de bugs no framework Jarvis pela CLI do host (`gh`), depois da pergunta
 - **Status**: `criado`
 
 ### `jarvis-docs-index` / `jarvis-docs-central` / `jarvis-context-detect` ✅

package/skills/eng-backend-arch-c4/assets/example-container.md

@@ -56,8 +56,8 @@ Rel(workflows, sessions, "Cria/Atualiza", "Filesystem")
 Rel(workflows, docs, "Gera", "Filesystem")
 
 ' === RELACIONAMENTOS EXTERNOS ===
-Rel(workflows, jira, "Sincroniza", "REST API")
-Rel(workflows, gitlab, "Cria MR", "REST API")
+Rel(workflows, jira, "Sincroniza", "CLI oficial")
+Rel(workflows, gitlab, "Cria MR", "CLI oficial")
 
 @enduml
 ```
@@ -87,8 +87,8 @@ Rel(workflows, gitlab, "Cria MR", "REST API")
 | Skills Engine | ENV Config | Lê config | Filesystem |
 | Workflow Engine | Sessions | Cria/Atualiza | Filesystem |
 | Workflow Engine | Documentation | Gera | Filesystem |
-| Workflow Engine | Jira | Sincroniza | REST API |
-| Workflow Engine | GitLab | Cria MR | REST API |
+| Workflow Engine | Jira | Sincroniza | CLI oficial |
+| Workflow Engine | GitLab | Cria MR | CLI oficial |
 
 ## ADRs Relacionados
 

package/skills/eng-backend-arch-c4/assets/example-context.md

@@ -34,8 +34,8 @@ Rel(dev, jarvis, "Usa para criar specs e código", "CLI/IDE")
 Rel(tech_lead, jarvis, "Usa para documentar arquitetura", "CLI/IDE")
 Rel(pm, jarvis, "Usa para criar PRDs e histórias", "CLI/IDE")
 
-Rel(jarvis, jira, "Sincroniza tarefas", "REST API")
-Rel(jarvis, gitlab, "Cria branches e MRs", "REST API")
+Rel(jarvis, jira, "Sincroniza tarefas", "CLI oficial")
+Rel(jarvis, gitlab, "Cria branches e MRs", "CLI oficial")
 Rel(jarvis, slack, "Envia notificações", "Webhook")
 Rel_L(ide, jarvis, "Integra via extensões", "MCP")
 
@@ -50,8 +50,8 @@ Rel_L(ide, jarvis, "Integra via extensões", "MCP")
 | Desenvolvedor | Pessoa | Engenheiro que implementa features | - |
 | Tech Lead | Pessoa | Lidera decisões técnicas | - |
 | Product Manager | Pessoa | Define requisitos de produto | - |
-| Jira | Sistema Externo | Gerenciamento de tarefas | REST API |
-| GitLab | Sistema Externo | Controle de versão | REST API |
+| Jira | Sistema Externo | Gerenciamento de tarefas | CLI oficial |
+| GitLab | Sistema Externo | Controle de versão | CLI oficial |
 | Slack | Sistema Externo | Comunicação | Webhook |
 | IDE | Sistema Externo | Ambiente de desenvolvimento | MCP |
 
@@ -62,8 +62,8 @@ Rel_L(ide, jarvis, "Integra via extensões", "MCP")
 | Desenvolvedor | JARVIS | Usa para criar specs e código | CLI/IDE |
 | Tech Lead | JARVIS | Usa para documentar arquitetura | CLI/IDE |
 | Product Manager | JARVIS | Usa para criar PRDs e histórias | CLI/IDE |
-| JARVIS | Jira | Sincroniza tarefas | REST API |
-| JARVIS | GitLab | Cria branches e MRs | REST API |
+| JARVIS | Jira | Sincroniza tarefas | CLI oficial |
+| JARVIS | GitLab | Cria branches e MRs | CLI oficial |
 | JARVIS | Slack | Envia notificações | Webhook |
 | IDE | JARVIS | Integra via extensões | MCP |
 

package/skills/eng-backend-microservices-trace/SKILL.md

@@ -154,7 +154,7 @@ Este skill é **exclusivamente de investigação**:
 
 **0.1 Buscar o card**
 
-Usar o MCP/`TASK_MANAGER` (se disponível) ou pedir ao usuário que cole o conteúdo:
+Ler o card pela CLI oficial do `$TASK_MANAGER` (ação `view` do catálogo, `eng.integrations-rules.md`; sem REST nem MCP) ou pedir ao usuário que cole o conteúdo:
 - Título e descrição do bug
 - Passos para reproduzir
 - Comportamento esperado vs. observado

package/skills/eng-global-investigation/SKILL.md

@@ -45,6 +45,8 @@ Método para investigar bugs sem chute. Vale para qualquer linguagem, framework
 
 ## Orçamento de etapas
 
+> Parecido com o `ReAct` (investigar um passo por vez, com hipótese e evidência), mas sem o campo `raciocínio` obrigatório a cada passo. Ver #171.
+
 Você investiga sozinho, sem pedir confirmação a cada passo, dentro de um orçamento pela urgência do `context.md` (CDD):
 
 | Urgência | Etapas (leitura, busca ou verificação) |
@@ -61,6 +63,8 @@ Se **3 correções** já foram tentadas e nenhuma resolveu, pare: cada correçã
 
 ## Crítico antes de concluir
 
+> Parecido com o `Reflection` (passe crítico antes de finalizar), mas sem nota de 0 a 100 nem rodadas de correção, e sem registro de lições. Ver #171 e #169.
+
 Antes de declarar a causa, faça um passe contra a sua própria conclusão: que evidência a derrubaria? A reprodução foi feita de fato, ou só lida? Há outra hipótese que explica o mesmo sintoma? Se a evidência for só indireta, rebaixe o veredito.
 
 ## Veredito

package/skills/eng-global-pr/SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: eng-global-pr
-description: Cria branch, commit e Merge Request seguindo os padrões do time. Use quando precisar submeter código para revisão após completar uma tarefa.
+description: Cria a branch e o commit, gera o texto do Merge Request e, depois da pergunta (regra de ouro), faz o push e abre o MR, seguindo os padrões do time. Use quando precisar submeter código para revisão após completar uma tarefa.
 argument-hint: "{TASK_MANAGER_KEY} [branch-destino]"
 disable-model-invocation: false
-allowed-tools: Read Write Edit Grep Glob Bash MCP
+allowed-tools: Read Write Edit Grep Glob Bash
 metadata:
   author: jarvis-team
   version: "1.0"
@@ -16,7 +16,7 @@ Você é um **especialista em Git e processos de code review** focado em criar P
 
 ## Objetivo
 
-Criar branch, commitar alterações e abrir um MR (GitLab) ou PR (GitHub) pela CLI do host (`glab`/`gh`), conforme o `origin` ou o `VERSION_CONTROL` no ENV.md, seguindo (o MR/PR sai pelo `jarvis vcs create-merge`, que respeita o `VERSION_CONTROL_ACCESS`: com `manual` sai com 3 sem abrir; saídas 0/1/3/4 da `rules/engineering/eng.integrations-rules.md`):
+Criar a branch e o commit, gerar o texto do MR/PR e, só depois da pergunta (regra de ouro), fazer o push e abrir o MR (GitLab) ou PR (GitHub) pela CLI do host (`glab`/`gh`), conforme o `origin` ou o `VERSION_CONTROL` no ENV.md. O MR/PR sai pelo `jarvis vcs create-merge`, que respeita o `VERSION_CONTROL_ACCESS` (com `manual`, sai com 3 sem abrir; saídas 0/1/3/4 da `rules/engineering/eng.integrations-rules.md`). Segue:
 - Padrão de nomenclatura de branch
 - Convenção de commits (Conventional Commits)
 - Template de MR preenchido corretamente
@@ -180,6 +180,8 @@ Refs: TASK-123"
 
 ### 4. Push
 
+Os Passos 4 e 5 só acontecem depois da pergunta (regra de ouro, `eng.integrations-rules.md`). Monte antes o texto do MR (preencher o template, Passo 5), mostre-o e pergunte com `AskUserQuestion` (**Sim, publicar** / **Não, manter só na sessão**). Sem o Sim, grave o `pull-request.md` na sessão e pare, sem push nem MR. Quando o skill é chamado pelo `/eng.pr`, a escolha da Fase 0 dele vale como essa pergunta (exceção da regra) e não se pergunta de novo.
+
 ```bash
 git push -u origin {NOME_DA_BRANCH}
 ```
@@ -213,19 +215,20 @@ Usar template oficial em `$IDE/templates/engineering/PR-template.md`.
 
 ### 6. Atualizar o card (`TASK_MANAGER`)
 
-Se `TASK_MANAGER` estiver vazio (freelance): pular este passo.
+Se `TASK_MANAGER` estiver vazio (freelance): pule só o item 1; o item 2 registra o link no `task-log.md` pelo skill.
 
-1. Mover card para **"In Review"** (ou equivalente do vendor)
-2. Adicionar comentário com link do MR via `eng-global-task-comment`
+1. Orientar a pessoa a mover o card para **"In Review"** (ou equivalente do vendor); o Jarvis não move card
+2. Publicar o comentário com o link do MR via `eng-global-task-comment`, que mostra o texto e pergunta (regra de ouro, `eng.integrations-rules.md`)
 
 ### 7. Processar Code Review
 
 1. Aguardar comentários da ferramenta de code review
 2. Analisar cada comentário
-3. Aplicar correções se necessário:
+3. Aplicar correções se necessário. O push das correções só sai depois da pergunta com `AskUserQuestion` (regra de ouro, `eng.integrations-rules.md`); sem o Sim, o commit fica local:
    ```bash
    git add {arquivos}
    git commit -m "fix: corrigir {problema} conforme code review"
+   # só com o Sim da pergunta acima
    git push
    ```
 
@@ -237,7 +240,7 @@ Após MR criado com sucesso, **solicitar confirmação do usuário**:
 🧹 Deseja limpar a sessão?
 
 A pasta $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/ será removida.
-A documentação permanece no card (`TASK_MANAGER`) e no MR.
+O texto do PR permanece no MR e o que foi enviado ao card fica no card; o que você recusou (por exemplo, o `task-comment-*.md` do link do MR) só existe nesta pasta e será apagado junto; no freelance, o `task-log.md` e, com "Só gerar os arquivos", o `pull-request.md` também ficam só aqui.
 
 Confirmar? (s/n)
 ```
@@ -253,7 +256,7 @@ rm -rf $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/
 
 | Passo | Skill | Condição |
 |-------|-------|----------|
-| Passo 6 — Atualizar o card | `/eng-global-task-comment` | Sempre: comentário no card com o link do MR (freelance: registro no `task-log.md` da sessão) |
+| Passo 6 — Atualizar o card | `/eng-global-task-comment` | Com o Sim da pergunta (regra de ouro): comentário no card com o link do MR (freelance: registro no `task-log.md` da sessão) |
 
 ---
 
@@ -275,7 +278,7 @@ rm -rf $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/
 - ✅ Usar mensagem de commit padronizada
 - ✅ Criar branch no padrão `{TASK_MANAGER_KEY}-{titulo}`
 - ✅ Preencher template do MR completamente
-- ✅ Mover card para "In Review"
+- ✅ Orientar a pessoa a mover o card para "In Review" (o Jarvis não move card)
 - ✅ Limpar sessão após criar MR
 
 ---
@@ -294,7 +297,7 @@ rm -rf $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/
 - [ ] Push realizado
 - [ ] MR criado com template preenchido
 - [ ] Branch destino correta
-- [ ] Card movido para "In Review"
+- [ ] Pessoa orientada a mover o card para "In Review"
 - [ ] Sessão limpa
 
 ---
@@ -307,7 +310,7 @@ rm -rf $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/
 📋 Resumo:
 - Branch: {NOME_DA_BRANCH}
 - MR: {LINK_DO_MR}
-- Card ({TASK_MANAGER}): {TASK_MANAGER_KEY} → "In Review"
+- Card ({TASK_MANAGER}): {TASK_MANAGER_KEY} (mover para "In Review" é com a pessoa)
 
 📊 Validações:
 - Testes: ✅ Passando

package/skills/eng-global-task-comment/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: eng-global-task-comment
 description: >
-  Adiciona um comentário no card do TASK_MANAGER (Jira, GitHub Issues ou GitLab Issues) pela CLI oficial do vendor; sem board (freelance), registra no task-log.md da sessão.
-  Trigger: registrar no card um evento relevante: desvio do plano, auditoria do Advisor, bloqueio ou o link do MR (nunca início ou fim de etapa).
+  Adiciona um comentário no card do TASK_MANAGER (Jira, GitHub Issues ou GitLab Issues) pela CLI oficial do vendor, só depois de mostrar o texto e o usuário dizer Sim (regra de ouro); sem board (freelance), registra no task-log.md da sessão.
+  Trigger: registrar no card um evento relevante: desvio do plano, auditoria do Advisor, bloqueio, link do MR ou outro evento que você aprove (nunca início ou fim de etapa).
 argument-hint: "{TASK_MANAGER_KEY} {mensagem}"
 disable-model-invocation: false
 allowed-tools: Read Write Bash
@@ -48,7 +48,15 @@ Formato (criar o arquivo se não existir; só acrescentar, nunca sobrescrever):
 ```
 ````
 
-A cada entrada nova: uma linha nova no fim da tabela do índice e a seção nova no fim do arquivo. `{evento}`: desvio do plano, auditoria do Advisor, bloqueio, link do MR ou gate do pre-pr.
+A cada entrada nova: uma linha nova no fim da tabela do índice e a seção nova no fim do arquivo. `{evento}`: desvio do plano, auditoria do Advisor, bloqueio, link do MR, gate do pre-pr ou outro evento aprovado.
+
+### 0.5 Mostrar e perguntar (com board)
+
+**Regra de ouro** (`rules/engineering/eng.integrations-rules.md`): nada é comentado sem perguntar. Antes de qualquer envio, mostre o texto da mensagem e pergunte com `AskUserQuestion`: **"Publicar este comentário no card {TASK_MANAGER_KEY}?"** → **Sim, publicar** / **Não, manter só na sessão (como hoje)**. A pergunta vale para cada comentário, mesmo quando o workflow que chamou o skill já perguntou algo parecido.
+
+- **`TASK_MANAGER_ACCESS` `manual` ou inválido:** não há envio possível; pule a pergunta e faça o mesmo que no Não, avisando que o texto está no `.md`.
+- **Sim:** siga para o passo 1.
+- **Não:** não envie. Grave o `.md` do passo 3 (`task-comment-{YYYYMMDD-HHMM}.md`) e diga `Comentário não enviado; o texto está em {caminho do .md}`, sem o aviso de falha do passo 3. É lá que o texto recusado fica (na auditoria do Advisor, ele também já está no `architecture.md`). O fluxo principal segue.
 
 ### 1. `jarvis tasks comment`