jarvis-ai-framework 7.0.0 → 8.2.0

package/templates/engineering/AGENTS-template.md

@@ -38,7 +38,7 @@
 - Nunca commite credenciais, tokens ou senhas
 - Use variáveis de ambiente para dados sensíveis
 - Siga as práticas de segurança definidas em `{IDE_FOLDER}/rules/engineering/`
-- Reporte vulnerabilidades ao time de segurança
+- Reporte vulnerabilidades ao time de segurança (a pessoa do projeto, pela via combinada; o Jarvis não envia nada sem perguntar)
 
  Available Workflows
 
@@ -50,7 +50,7 @@ O projeto utiliza o framework JARVIS com os seguintes comandos principais:
 | `/eng.start` | Iniciar nova tarefa (cria architecture.md) |
 | `/eng.plan` | Criar plano de execução faseado |
 | `/eng.work` | Implementar código seguindo o plano |
-| `/eng.pr` | Criar branch, commit e Merge Request |
+| `/eng.pr` | Push e Merge Request, depois da pergunta (regra de ouro) |
 | `/eng.debug` | Investigar e resolver bugs |
 
  For AI Agents

package/templates/engineering/CONTACTS-template.md

@@ -73,7 +73,7 @@ Recomendação: ler o playbook de tomada de decisões em tecnologia do time (wik
  Incidentes em Produção
 
 ```
-. Alertar no canal squad-{nome}-alerts
+. A pessoa avisa no canal squad-{nome}-alerts (o Jarvis, só depois da pergunta)
       
 . Acionar pessoa de plantão (PagerDuty)
       

package/templates/engineering/advisor-template.md

@@ -14,7 +14,7 @@ Etapas da tarefa:
 | Alerta no início do eng.start | O usuário escolhe usar o Advisor e o modelo | Ainda não existe |
 | eng.start | Escrevo o architecture.md; o que diverge do código ou é ambíguo vira "Questões em Aberto" | Aqui: você orienta cada questão |
 | Orientação acatada | Atualizo o architecture.md e registro | Não |
-| Registro da auditoria | Posto um comentário na issue com as questões e as suas sugestões (sem TASK_MANAGER, só no architecture.md) | Não |
+| Registro da auditoria | Mostro o comentário com as questões e as suas sugestões e, só com o Sim do usuário (regra de ouro), posto na issue pelo `/eng-global-task-comment`, que pergunta (sem o Sim, o texto fica no task-comment-*.md e no architecture.md; sem TASK_MANAGER, o skill registra no task-log.md) | Não |
 | eng.plan / eng.work | Plano e implementação | Só por exceção: questão nova em aberto |
 | Commit e PR | Um commit; o usuário valida em "Files changed" | Não |
 | Merge e fechamento | O usuário faz o merge | Não |
@@ -41,7 +41,7 @@ Analise o repositório só se precisar para ter certeza (sem chutar). Responda (
 1. SUGESTÃO DO ADVISOR (opção 1-3 ou a 4 detalhada) · 2. DIVERGÊNCIA · 3. BASE · 4. ANÁLISE NO REPOSITÓRIO · 5. RELAÇÃO COM OUTRAS TAREFAS · 6. CERTEZA (escrito / confirmado no código / inferência). Não altere arquivos; aponte o risco se uma opção for destrutiva ou fugir do card.
 ```
 
-## Modelo do comentário de auditoria (postado pelo agente principal)
+## Modelo do comentário de auditoria (postado pelo agente principal, só depois da pergunta: regra de ouro)
 
 ```
 ## Auditoria — questões do architecture.md

package/templates/engineering/architecture-template.md

@@ -10,7 +10,8 @@
 > **Commit base:** `{sha}` (no modo workspace, `{repo}@{sha}` por repositório: as linhas citadas nos links são deste commit)  
 > **Status:** 🔄 Em Revisão | ✅ Aprovado | ❌ Rejeitado  
 > **Advisor:** {modelo escolhido no início do eng.start} | não utilizado  
-> **Questões em aberto:** tratar no architecture.md (como hoje) | uma a uma, assim que surgirem (só sem Advisor)
+> **Questões em aberto:** tratar no architecture.md (como hoje) | uma a uma, assim que surgirem (só sem Advisor)  
+> **Ajustes antes da aprovação:** {0} (o `eng.start` soma 1 a cada "Ajustar o documento"; o `eng.pre-pr` copia o número para o PR Brief)
 
 ---
 
@@ -86,6 +87,18 @@ Novo fluxo:
 | {convenção de API} | {ex: REST, naming conventions} | {caminho/arquivo-exemplo}  |
 | {padrão de testes} | {ex: AAA, mocks}               | {caminho/arquivo-exemplo}  |
 
+### 2.5 Premissas e Passe Crítico
+
+> Preenchida no passe crítico (Fase 4.4 do `eng.start`), antes da aprovação. Parecido com o `Reflection`: um passe contra o próprio documento (ver #171). Só entram premissas que mudam o plano se estiverem erradas; até cerca de 10 linhas.
+
+| Premissa | Fonte | O que a derrubaria | Como conferir |
+| -------- | ----- | ------------------ | ------------- |
+| {afirmação em que o documento se apoia} | {lida: [`{arquivo}:{n}`](../../../../{repo}/{caminho}#L{n}) \| presumida} | {fato que, se verdadeiro, invalida a premissa} | {leitura, comando ou pergunta} |
+
+**O que derrubaria este documento:** {a premissa mais frágil, em uma frase}
+
+> Toda premissa **presumida** que mudaria o plano vira, antes da aprovação, uma leitura feita (e passa a "lida") ou uma questão em aberto na seção 8.
+
 ---
 
 ## 3. Decisões Arquiteturais

package/templates/engineering/data-contract-template.md

@@ -122,7 +122,7 @@ WHERE data_referencia BETWEEN '{{DATA_INICIO}}' AND '{{DATA_FIM}}'
 
 Qualquer alteração de schema (adição, remoção ou mudança de tipo de campo) deve:
 
-1. Ser comunicada no canal `$DATA_REQUESTS_CHANNEL` com **7 dias de antecedência**
+1. Ser comunicada no canal `$DATA_REQUESTS_CHANNEL` com **7 dias de antecedência** (pela pessoa; um aviso enviado pelo Jarvis só sai depois da pergunta)
 2. Ter nova versão do contrato criada (versionamento semântico: `MAJOR.MINOR`)
 3. Período de coexistência: versão antiga disponível por **30 dias** após nova versão publicada
 

package/templates/engineering/plan-template.md

@@ -7,6 +7,8 @@
 > Links (inclusive nos comentários de fase): `rules-on-demand/doc-links-rules.md`; os arquivos de "Onde fazer" que já existem viram link (`../../../../{repo}/{arquivo}#L{n}`), e os novos ficam em texto.
 >
 > **Execução:** {fase a fase | todas de uma vez} · **Commits:** {um por fase | um só ao final} · **Depois do work:** {sugerir /eng.pre-pr | rodar /eng.pre-pr | direto para /eng.pr | parar} _(preenchido pelo `eng.work`, Fase 1.3)_
+>
+> **Ajustes antes da aprovação:** {0} _(o `eng.plan` soma 1 a cada "Ajustar o plano"; o `eng.pre-pr` copia o número para o PR Brief)_
 
 ---
 

package/templates/engineering/tech-spec-delivery-template.md

@@ -1,10 +1,10 @@
 # Tech Spec — Formatos de Entrega
 
-> Template com os formatos usados no fim do `eng.build-tech-spec`: descrição da subtarefa no Jira, comentário na história original, mensagem de entrega e um exemplo preenchido, além do diagrama do fluxo. Substitua os placeholders `{...}`.
+> Template com os formatos usados no fim do `eng.build-tech-spec`: descrição da subtarefa no board, comentário na história original, mensagem de entrega e um exemplo preenchido, além do diagrama do fluxo. Substitua os placeholders `{...}`.
 
-## Descrição da subtarefa no Jira
+## Descrição da subtarefa no board
 
-Fase 7.2 do workflow. Use este formato na descrição de cada subtarefa criada no Jira (ou entregue ao usuário para copiar e colar).
+Fase 7.2 do workflow. Use este formato na descrição de cada subtarefa criada no Jira pela `acli` (ou entregue ao usuário para copiar e colar no board).
 
 ```markdown
 ## Descrição
@@ -37,7 +37,7 @@ Tech Spec: [Link para tech-spec.md]
 
 ## Comentário na história original
 
-Fase 7.4 do workflow. Comentário a registrar na história (STORY-XXX) depois de criar as subtarefas.
+Fase 7.4 do workflow. Comentário a registrar na história (STORY-XXX) depois de criar as subtarefas, pelo `/eng-global-task-comment`, que mostra o texto e pergunta (regra de ouro).
 
 ```
 Tech Spec criada: [Link para tech-spec.md]
@@ -60,7 +60,7 @@ Fase 8.2 do workflow. O que entregar ao usuário ao final.
 ✅ Tech Spec criada com sucesso!
 
 📄 Documento Local: $SESSIONS_DIR/eng/{feature-name}/tech-spec.md
-📎 Anexada no Jira: {STORY-XXX}
+📎 {Anexada na issue: {STORY-XXX} | A anexar pela pessoa (orientado: GitHub/GitLab, sem a CLI, CLI que não anexa ou acesso manual) | Não anexada (só na sessão; sem o Sim) | Sem issue (freelance)}
 
 📋 Resumo:
 - História: {STORY-XXX} - {Título}
@@ -68,7 +68,7 @@ Fase 8.2 do workflow. O que entregar ao usuário ao final.
 - Subtarefas: {Y subtarefas}
 - Estimativa total: {Z horas}
 
-🔗 Subtarefas criadas no Jira:
+🔗 Subtarefas {criadas no Jira pela acli | entregues em template para criação manual (outros boards, sem a CLI, com acesso manual, sem o Sim ou sem board)}:
 - SUBTASK-001: {Nome} (P0, 6h)
 - SUBTASK-002: {Nome} (P1, 4h)
 - SUBTASK-003: {Nome} (P1, 8h)
@@ -93,7 +93,7 @@ Exemplo preenchido da mensagem de entrega (fictício).
 ✅ Tech Spec para STORY-456 criada com sucesso!
 
 📄 **Documento Local**: $SESSIONS_DIR/eng/story-456/tech-spec.md
-📎 **Anexado no Jira**: STORY-456
+📎 **Anexada na issue**: STORY-456
 
 📊 **Resumo**:
 
@@ -102,7 +102,7 @@ Exemplo preenchido da mensagem de entrega (fictício).
 - **Subtarefas**: 5 subtarefas
 - **Estimativa total**: 26 horas
 
-🔗 **Subtarefas criadas no Jira**:
+🔗 **Subtarefas criadas no Jira**:   ← ou "entregues em template"
 
 - SUBTASK-101: [BACKEND] Criar endpoint POST /api/auth/register (P0, 6h)
 - SUBTASK-102: [BACKEND] Criar endpoint POST /api/auth/login (P0, 6h)

package/templates/engineering/tech-spec-template.md

@@ -1,7 +1,7 @@
 ---
 name: {nome da tech-spec}
 id: {TECH-001}
-related_story: {STORY-XXX do Jira}
+related_story: {STORY-XXX do board}
 epic_related: {EPIC-XXX se existir}
 related_rfc: {RFC-XXX ou "Não aplicável"}
 link_task: {URL da história no $TASK_MANAGER}
@@ -16,7 +16,7 @@ reviewers: {lista de revisores}
 
 ## 1. Contexto da História
 
-### História Original do Jira
+### História Original (card do board)
 **ID**: {STORY-XXX}
 **Link**: {URL}
 
@@ -443,7 +443,7 @@ TIMEOUT_MS=5000
 - [ ] Rollback testado
 
 **Produto:**
-- [ ] Critérios de aceitação do Jira atendidos
+- [ ] Critérios de aceitação do card atendidos
 - [ ] Product Owner aceitou
 - [ ] QA sign-off
 - [ ] Stakeholders notificados

package/templates/product/prod-frd-template.md

@@ -165,7 +165,7 @@ Ele é um sistema de gestão de dados pessoais de saúde, que agrega informaçõ
 - {Exclusão adicional}
 
 ## Especificações relacionadas
-{liste todos os PRDs, FRDs ou outros documentos relacionados a este FRD fazendo uma análise prévia do projeto e das especificações existentes no Central docs (`jarvis docs sync`). Pergunte para o usuário se existe outras relações que ele conheça. Antes de adicionar as sugestões, confirme com o usuário se elas estão corretas.}
+{liste todos os PRDs, FRDs ou outros documentos relacionados a este FRD fazendo uma análise prévia do projeto e das especificações existentes em `$PROD_DOCS` (e, se configurado, das funcionalidades já implementadas no Central docs, `jarvis docs sync`). Pergunte para o usuário se existe outras relações que ele conheça. Antes de adicionar as sugestões, confirme com o usuário se elas estão corretas.}
 
 **PRDs relacionadas**:
 | ID | Título | Descrição |

package/templates/product/prod-prd-template.md

@@ -179,7 +179,7 @@ Estes são indicadores que podem ser usados para medir o sucesso dessa solução
 
 
 ## Especificações relacionadas
-{liste todos os PRDs, FRDs ou outros documentos relacionados a este FRD fazendo uma análise prévia do projeto e das especificações existentes no Central docs (`jarvis docs sync`). Pergunte para o usuário se existe outras relações que ele conheça. Antes de adicionar as sugestões, confirme com o usuário se elas estão corretas.}
+{liste todos os PRDs, FRDs ou outros documentos relacionados a este PRD fazendo uma análise prévia do projeto e das especificações existentes em `$PROD_DOCS` (e, se configurado, das funcionalidades já implementadas no Central docs, `jarvis docs sync`). Pergunte para o usuário se existe outras relações que ele conheça. Antes de adicionar as sugestões, confirme com o usuário se elas estão corretas.}
 
 **PRDs relacionadas**:
 | ID | Título | Descrição |

package/workflows/AGENTS.md

@@ -155,7 +155,7 @@ Workflows de engenharia seguem fases restritas:
 |------|-----------|-----------|
 | Planejamento | `eng.start`, `eng.plan` | Somente analise, SEM codigo |
 | Implementacao | `eng.work` | Codigo e testes, commit por fase, SEM push nem PR |
-| Entrega | `eng.pr` | Branch, commit e PR |
+| Entrega | `eng.pr` | Push e PR, depois da pergunta (regra de ouro) |
 
 **IMPORTANTE**: Respeitar estritamente as restricoes de cada fase.
 

package/workflows/README.md

@@ -85,7 +85,7 @@ workflows/
 | `eng.plan.md` | Criar plano de execução por fases |
 | `eng.work.md` | Executar implementação de código |
 | `eng.pre-pr.md` | Validação final antes do PR |
-| `eng.pr.md` | Criar branch, commit e Pull Request |
+| `eng.pr.md` | Push e Pull Request, depois da pergunta (regra de ouro) |
 | `eng.review.md` | Revisão de solução/PR |
 | `eng.debug.md` | Investiga um bug ou varre um escopo atrás de problemas |
 | `eng.docs.md` | Atualizar documentação de engenharia |

package/workflows/engineering/data/data.contract.md

@@ -161,7 +161,9 @@ Salvar o contrato preenchido em:
 
 ### 4.2 — Comunicar à squad requisitante
 
-Notificar no canal de solicitação de dados (thread original) com:
+Mostre o texto e pergunte com `AskUserQuestion` antes de notificar (regra de ouro, `eng.integrations-rules.md`); sem o Sim, deixe o texto pronto para a pessoa enviar.
+
+Notificar no canal de solicitação de dados (thread original), depois do Sim acima, com:
 - Link para o contrato
 - Como acessar os dados (método, IAM role ou equivalente)
 - SLA combinado
@@ -169,10 +171,12 @@ Notificar no canal de solicitação de dados (thread original) com:
 
 ### 4.3 — Abrir card no board do time de Data
 
-Criar card no board `DE` (ou equivalente) com:
+Mostre o texto do card e, se a criação vai sair (board configurado, CLI logada e `TASK_MANAGER_ACCESS=cli` ou vazio), pergunte com `AskUserQuestion` antes de criar (regra de ouro); sem o Sim, sem board, sem a CLI ou com acesso manual, deixe o card descrito para a pessoa criar.
+
+Com o Sim, criar card no board `DE` (ou equivalente) pela CLI oficial do vendor (`acli jira workitem create` no projeto `DE` do Jira, ou `gh issue create`/`glab issue create` com `--repo` a partir de `TASK_MANAGER_URL_BASE`, o repositório que faz as vezes do board `DE`; flags no `--help`; sem `--repo`, `gh`/`glab` criariam a issue no repositório do diretório atual. O `jarvis vcs create-issue` é o do `/jarvis-report-issue`, com `--repo` explícito, não um atalho para o board). Sem a CLI logada, com acesso manual ou sem board, a pessoa cria com o texto pronto. O card leva:
 - Squad requisitante
 - Tabela/recurso
-- Status: `Ativo`
+- Status: `Ativo` (no corpo do card; nenhuma CLI põe status na criação)
 - Link para o contrato
 
 ---
@@ -183,7 +187,7 @@ Criar card no board `DE` (ou equivalente) com:
 
 Qualquer mudança de schema (adição, remoção ou tipo de campo) deve:
 
-1. Ser comunicada no canal de dados com **antecedência** (prazo definido nas rules)
+1. Ser comunicada no canal de dados com **antecedência** (prazo definido nas rules), depois de mostrar a mensagem e perguntar com `AskUserQuestion` (regra de ouro, `eng.integrations-rules.md`); sem o Sim, deixe o texto pronto
 2. Gerar nova versão do contrato (versionamento semântico: `MAJOR.MINOR`)
 3. Manter versão antiga disponível pelo período de coexistência definido nas rules
 
@@ -191,8 +195,8 @@ Qualquer mudança de schema (adição, remoção ou tipo de campo) deve:
 
 Quando o contrato não for mais necessário:
 1. Atualizar `Status` para `Deprecado` no documento
-2. Comunicar à squad requisitante com prazo de encerramento
-3. Atualizar (ou remover) o card no board do time de Data
+2. Comunicar à squad requisitante com prazo de encerramento, depois de mostrar a mensagem e perguntar com `AskUserQuestion` (regra de ouro); sem o Sim, deixe o texto pronto
+3. Orientar a pessoa a atualizar (ou remover) o card no board do time de Data (o Jarvis não move card); um comentário no card sai pelo `/eng-global-task-comment`, que mostra o texto e pergunta (regra de ouro)
 
 ---
 
@@ -205,6 +209,6 @@ Quando o contrato não for mais necessário:
 [ ] Contrato preenchido (schema, SLA, acesso, campos sensíveis)
 [ ] Campos sensíveis com tratamento aplicado (ou ausência confirmada)
 [ ] Contrato salvo no repositório de pipelines
-[ ] Squad requisitante notificada com acesso e SLA
-[ ] Card aberto no board do time de Data
+[ ] Squad requisitante notificada com acesso e SLA (ou texto entregue à pessoa, sem o Sim)
+[ ] Card aberto no board do time de Data (ou descrito para a pessoa criar; sem board, só o texto)
 ```

package/workflows/engineering/eng.breakdown-subtasks.md

@@ -8,7 +8,7 @@ rules_file: "$IDE/rules-on-demand/engineering/eng.breakdown-subtasks-rules.md"
 ---
 # Breakdown Subtasks - Gerador de Subtarefas Mastigadas
 
-Você receberá uma Tech Spec completa e deve quebrá-la em subtarefas **EXTREMAMENTE DETALHADAS** para o Jira.
+Você receberá uma Tech Spec completa e deve quebrá-la em subtarefas **EXTREMAMENTE DETALHADAS** para o board. Este comando **não cria cards**: entrega as subtarefas em Markdown para a pessoa criar; a criação automática (só no Jira, pela `acli`, depois da pergunta) é a Fase 7 do `delivery-spec` do `/eng.build-tech-spec`.
 
 > ⚠️ **PRINCÍPIO FUNDAMENTAL**: Cada subtarefa deve ser tão detalhada que um desenvolvedor júnior possa executá-la SEM precisar perguntar nada. A subtarefa deve ser um "tutorial passo-a-passo" completo.
 
@@ -45,7 +45,7 @@ Analise a Tech Spec e extraia **TUDO**:
 
 ### 1.2 Investigação do Codebase (OBRIGATÓRIA)
 
-**ANTES de criar subtarefas**, use as ferramentas para:
+**ANTES de escrever as subtarefas**, use as ferramentas para:
 
 1. **Encontrar arquivos similares** - Use glob para localizar exemplos no projeto
 2. **Entender padrões existentes** - Use grep para ver como funcionalidades similares foram implementadas

package/workflows/engineering/eng.build-tech-spec.md

@@ -65,7 +65,7 @@ Gerar uma especificação técnica completa e auto-contida, em um de dois modos:
 | Delivery Spec › Processo de Criação › verificação de necessidade de RFC | `/eng.create-rfc` | Se a Tech Spec atender aos critérios que exigem RFC e o usuário escolher "A: Criar uma RFC agora" |
 | Delivery Spec › Caminho A › 2A.2 Análise de Documentação de Produto | `/jarvis-docs-central` | Se `CENTRAL_DOCS_STORAGE` estiver configurado (funcionalidades já implementadas relacionadas ao épico; PRD/FRD vêm de `$PROD_DOCS`) |
 | Reference Spec › 2. Checagem de RFC | `/eng.create-rfc` | Se não houver RFC/ARD de origem, algum dos 7 critérios for "Sim" e o usuário escolher "A: Criar uma RFC agora" |
-| Delivery Spec › FASE 7 › 7.3 Criação no Jira | `acli jira workitem create` (CLI do vendor) ou MCP do Jira configurado à mão | Se o projeto usar Jira com a `acli` logada (ou um MCP do Jira configurado pela pessoa); senão, template para criação manual |
+| Delivery Spec › FASE 7 › 7.3 Criação no Jira | `acli jira workitem create` (CLI do vendor) | Se o projeto usar Jira com a `acli` logada, só depois de mostrar o texto e perguntar (regra de ouro); senão, template para criação manual |
 
 ---
 

package/workflows/engineering/eng.create-ard-from-code.md

@@ -68,16 +68,14 @@ priorizando a **arquitetura observada no código do repositório**, usando o tem
 
 ## Passo 1 – Verificar PRD (obrigatório quando existir)
 
-### 1.1 – Buscar PRD no Central Docs (condicional)
+### 1.1 – Buscar o PRD em `$PROD_DOCS` e o implementado no Central docs
 
-Se `CENTRAL_DOCS_STORAGE` definido no ENV.md:
-
-1. Consultar no Central docs as funcionalidades já implementadas relacionadas (o que existe hoje):
+1. Se `CENTRAL_DOCS_STORAGE` estiver definido no ENV.md, consultar no Central docs as funcionalidades já implementadas relacionadas (o que existe hoje); vazio: pule só este item:
    ```bash
    jarvis docs sync --silent
    ```
 
-2. Buscar o PRD relacionado em `$PROD_DOCS` (documento de trabalho; o Central docs não guarda PRD) usando:
+2. Buscar o PRD relacionado em `$PROD_DOCS` (sempre, com ou sem Central docs; é documento de trabalho e o Central docs não o guarda) usando:
    - Título/objetivo do ARD
    - Jira ID (se disponível)
    - Tags semânticas

package/workflows/engineering/eng.create-ard.md

@@ -121,16 +121,14 @@ Regras:
 
 ## Passo 1.1 – Verificar PRD (obrigatório)
 
-### 1.1.1 – Buscar PRD no Central Docs (condicional)
+### 1.1.1 – Buscar o PRD em `$PROD_DOCS` e o implementado no Central docs
 
-Se `CENTRAL_DOCS_STORAGE` definido no ENV.md:
-
-1. Consultar no Central docs as funcionalidades já implementadas relacionadas (o que existe hoje):
+1. Se `CENTRAL_DOCS_STORAGE` estiver definido no ENV.md, consultar no Central docs as funcionalidades já implementadas relacionadas (o que existe hoje); vazio: pule só este item:
    ```bash
    jarvis docs sync --silent
    ```
 
-2. Buscar o PRD relacionado em `$PROD_DOCS` (documento de trabalho; o Central docs não guarda PRD) usando:
+2. Buscar o PRD relacionado em `$PROD_DOCS` (sempre, com ou sem Central docs; é documento de trabalho e o Central docs não o guarda) usando:
    - Título/objetivo do ARD
    - Jira ID (se disponível)
    - Tags semânticas

package/workflows/engineering/eng.create-rfc.md

@@ -91,11 +91,11 @@ Regras:
 
 ---
 
-## Passo 0.6 – Buscar Documentação Relacionada no Central Docs (condicional)
+## Passo 0.6 – Buscar Documentação Relacionada (`docs/jarvis/` sempre; Central docs se configurado)
 
-Se `CENTRAL_DOCS_STORAGE` definido no ENV.md:
+A busca em `docs/jarvis/` (PRD, ARD, RFCs) é sempre feita; a consulta ao Central docs só se `CENTRAL_DOCS_STORAGE` estiver definido no ENV.md (vazio: pule só o item 1).
 
-1. Consultar no Central docs as funcionalidades já implementadas relacionadas (o que existe hoje):
+1. Se `CENTRAL_DOCS_STORAGE` estiver definido, consultar no Central docs as funcionalidades já implementadas relacionadas (o que existe hoje):
    ```bash
    jarvis docs sync --silent
    ```
@@ -106,13 +106,13 @@ Se `CENTRAL_DOCS_STORAGE` definido no ENV.md:
    - Tags semânticas
 
 3. Documentos a buscar:
-   - **Funcionalidades já implementadas** relacionadas (Central docs: `feature-*`)
+   - **Funcionalidades já implementadas** relacionadas (Central docs, se configurado: `feature-*`)
    - **PRD relacionado** (em `$PROD_DOCS`, para rastreabilidade e contexto de negócio)
    - **ARD existente** e **RFCs anteriores** relacionados ao tema (em `$ENG_DOCS/ARD` e `$ENG_DOCS/RFC`)
 
 4. Se documentos encontrados:
    - Carregar automaticamente como contexto
-   - Informar ao usuário: "✅ Documentos encontrados no central-docs: [lista]"
+   - Informar ao usuário: "✅ Documentos encontrados (`docs/jarvis/` e, se configurado, Central docs): [lista]"
    - Incorporar ao contexto antes do Passo 1
 
 5. Se não encontrado:

package/workflows/engineering/eng.light-arch.md

@@ -79,7 +79,7 @@ Se ajudar a construir um diagrama MERMAID, sinta-se livre para fazê-lo.
 
 5. Uma vez que tenha um bom entendimento do que está sendo construído, mostre ao usuário na forma de um artefato e aguarde sua aprovação. Iterate juntos até estar pronto. PAUSE para aguardar a aprovação do humano.
 
-6. Quando o humano concordar com seu entendimento, você pode proceder ao próximo passo, salvando os detalhes da estrutura arquitetural no card do $TASK_MANAGER como um comentário ao card original.
+6. Quando o humano concordar com seu entendimento, você pode proceder ao próximo passo, salvando os detalhes da estrutura arquitetural no card do $TASK_MANAGER como um comentário ao card original, pelo `/eng-global-task-comment`, que mostra o texto e pergunta antes de enviar (regra de ouro, `eng.integrations-rules.md`); sem o Sim, o texto fica só na sessão.
 
 ## Pesquisa
 

package/workflows/engineering/eng.plan.md

@@ -45,10 +45,9 @@ Antes de executar este workflow:
 |-------|-------|----------|
 | Cabeçalho (agente) | `eng.agent` (agente) | Sempre — identidade do workflow |
 | Fase 0 › 0.1 Herdar Contexto da Sessão | `/jarvis-context-detect` | Se `ENABLE_CDD=true` e o `context.md` não existir |
-| Fase 2: Pesquisa no Codebase | `repoprompt` (MCP: `search`, `read_selected_files`) | Para buscar e ler arquivos relevantes do codebase |
 | Fase 2: Pesquisa no Codebase (se necessário) | `context7` (MCP) | Se for preciso consultar a documentação de bibliotecas |
 | Fase 3: Criação do Plano (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 3: Criação do Plano (exceção) | `/eng-global-task-comment` | Só por exceção: comentário de auditoria da questão nova consultada ao Advisor (freelance pula) |
+| Fase 3: Criação do Plano (exceção) | `/eng-global-task-comment` | Só por exceção: comentário de auditoria da 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` e no `architecture.md` |
 
 ---
 
@@ -129,9 +128,12 @@ CONTEXT_PROFILE:
 
 ### Fase 2: Pesquisa no Codebase
 
-1. **Buscar** arquivos relevantes usando:
-   - `repoprompt:search` para encontrar arquivos específicos
-   - `repoprompt:read_selected_files` para ler código em batch
+1. **Buscar** arquivos relevantes com as ferramentas de busca, como na Fase 3.1 do `eng.start`:
+   - **Glob** para encontrar arquivos relacionados
+   - **Grep** para buscar padrões e implementações parecidas
+   - **Read** para ler os arquivos que serão modificados
+
+   Com `WORKSPACE_MODE=workspace`, busque só nos repositórios do workspace e siga a regra "Buscas de código em modo workspace" de `eng-rules.md`.
 2. **Analisar**:
    - Padrões existentes no projeto
    - Arquivos que serão modificados
@@ -163,14 +165,15 @@ CONTEXT_PROFILE:
 
 4. **Usar** o template em `$IDE/templates/engineering/plan-template.md`
 
-**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.plan`", 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.plan`", 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.
 
 ### Fase 4: Validação
 
+0. **Passe crítico**, antes de apresentar: percorra o "Checklist de Conclusão" de `eng.plan-rules.md` item a item contra o `plan.md` (toda fase cabe em cerca de 1 hora; toda fase tem a tarefa `X.T`; toda tarefa tem o que, onde, como e como verificar; dependências explícitas; status iniciais ⏳) e corrija o plano antes de mostrar. Registre o resultado nos comentários da última fase: `Passe crítico: {n} itens conferidos, {m} corrigidos`. Parecido com o `Reflection` (ver #171), como o passe crítico do `eng.start` (Fase 4.4).
 1. **Apresentar** o plano ao humano, com o consolidado de links da sessão (regra 5 de `eng.transitions-rules.md`: `context.md`, `architecture.md` e o `plan.md` novo)
 2. **Discutir** ajustes necessários
 3. **Atualizar** `architecture.md` se houver mudanças arquiteturais
-4. **Confirmar** antes de prosseguir, com a pergunta de transição (`eng.transitions-rules.md`): **"O que fazer com o plano?"** (depois da mensagem em markdown com o consolidado de links) → **Aprovar e implementar agora** (chame o `/eng.work {TASK_MANAGER_KEY}`, ou mostre o comando) / **Aprovar e seguir manualmente (como hoje)** (o comando termina e o usuário chama o `/eng.work` quando quiser) / **Ajustar o plano** (o usuário diz o que mudar; atualize o `plan.md` e mostre de novo). As duas aprovações valem como a aprovação explícita do plano
+4. **Confirmar** antes de prosseguir, com a pergunta de transição (`eng.transitions-rules.md`): **"O que fazer com o plano?"** (depois da mensagem em markdown com o consolidado de links) → **Aprovar e implementar agora** (chame o `/eng.work {TASK_MANAGER_KEY}`, ou mostre o comando) / **Aprovar e seguir manualmente (como hoje)** (o comando termina e o usuário chama o `/eng.work` quando quiser) / **Ajustar o plano** (o usuário diz o que mudar; atualize o `plan.md`, some 1 em "Ajustes antes da aprovação" no cabeçalho, refaça o passe crítico no que mudou e mostre de novo). As duas aprovações valem como a aprovação explícita do plano
 
 ---
 

package/workflows/engineering/eng.pr.md

@@ -11,7 +11,7 @@ model_justification: Operações Git e preenchimento de templates são tarefas e
 
 # Pull Request / Merge Request
 
-Este comando cria a **branch, commita as alterações e abre um Merge Request**.
+Este comando **gera o `pull-request.md` na sessão e, com a escolha de publicar da Fase 0 (regra de ouro), faz o push e abre o Merge Request**. A branch e os commits vêm do `eng.start` e do `eng.work`.
 
 > 📋 **Rules**: `$IDE/rules-on-demand/engineering/eng.pr-rules.md` — **antes de começar, leia esse arquivo e siga-o**: ele não é carregado automaticamente no início da sessão.
 > 📤 **Template**: `$IDE/templates/engineering/PR-template.md`
@@ -47,7 +47,7 @@ Este comando cria a **branch, commita as alterações e abre um Merge Request**.
 | Skills recomendados | `/eng-global-docs-write` | Se houver necessidade de atualizar documentação junto do PR |
 | Agentes recomendados (opcional) | `eng.qa.test-planner` (agente) | Se houver dúvidas sobre cobertura de testes ou mudanças significativas |
 | Fase 4 › 4.4 Criar MR/PR pela CLI | `jarvis vcs create-merge` (CLI do Jarvis → `gh`/`glab`) | Só se a escolha da Fase 0 for publicar (4.3): abre o MR/PR pela cadeia de `eng.integrations-rules.md`, pelo host do `origin` |
-| Fase 5 › 5.2 Link do MR | `/eng-global-task-comment` | Depois de o MR ser criado (só ao publicar, 4.3): um único comentário no card com o link do MR, seguindo o Passo 6 do skill `eng-global-pr` (freelance: registra no `task-log.md`) |
+| Fase 5 › 5.2 Link do MR | `/eng-global-task-comment` | Depois de o MR ser criado (só ao publicar, 4.3): um único comentário no card com o link do MR, só com o Sim da pergunta (regra de ouro), seguindo o Passo 6 do skill `eng-global-pr` (freelance: registra no `task-log.md`) |
 
 ---
 
@@ -72,7 +72,7 @@ Ler `TASK_MANAGER` do `$IDE/ENV.md`. Seguir `$IDE/rules/engineering/eng.integrat
 ## Fase 0: O que fazer com o PR (`eng.transitions-rules.md`)
 
 Pergunte com `AskUserQuestion`: **"O que fazer com o PR?"**
-- **Revisar o texto e publicar (como hoje):** gera o `pull-request.md`, você aprova ou ajusta (4.2) e, com a aprovação, faz o push e abre o PR (4.4). A aprovação do texto é a confirmação da publicação.
+- **Revisar o texto e publicar (como hoje):** gera o `pull-request.md`, você aprova, ajusta ou escolhe `[Só gerar os arquivos]` (4.2) e, com a aprovação, faz o push e abre o PR (4.4). A aprovação do texto é a confirmação da publicação.
 - **Publicar sem revisar o texto:** gera o `pull-request.md` (4.1), faz o push e abre o PR (4.4) sem a revisão (4.2); você ajusta o texto direto no PR.
 - **Só gerar os arquivos:** gera o `pull-request.md` (4.1), mostra para revisão (4.2) e não faz push nem abre o PR; você abre à mão. A Fase 7 gera o `daily.md` mesmo assim.
 
@@ -209,7 +209,7 @@ Use **MR** se GitLab, **PR** se GitHub.
 
 ### 4.1 Gerar `pull-request.md` na sessão
 
-Escreva o título e a descrição do PR em **`$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/pull-request.md`** (primeira linha `# {título}`, depois o corpo). Se a sessão tiver o `gate-checklist.md` do `eng.pre-pr`, use o PR Brief e as decisões dele.
+Escreva o título e a descrição do PR em **`$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/pull-request.md`** (primeira linha `# {título}`, depois o corpo). Se a sessão tiver o `gate-checklist.md` do `eng.pre-pr`, use o PR Brief e as decisões da rodada mais recente (o `gate-checklist.md`; as rodadas anteriores, `gate-checklist-rodada-{N}.md`, são histórico). Os labels sugeridos do PR Brief **não** entram no corpo do PR nem na criação do MR (o `jarvis vcs create-merge` não põe label): eles aparecem na mensagem final (7.3), para a pessoa adicionar no host.
 
 Template, nesta ordem (o primeiro que existir):
 
@@ -234,11 +234,11 @@ Preencher com a tarefa. Link do card:
 
 ### 4.2 Revisão do texto
 
-Mostre o consolidado de links da sessão (regra 5 de `eng.transitions-rules.md`, com o `pull-request.md` novo), o título e o resumo das seções e pergunte com `AskUserQuestion` (depois da mensagem com o consolidado de links): `[Aprovar]` / `[Ajustar]`. Ajuste até a aprovação. (Pulada com "Publicar sem revisar o texto" na Fase 0.)
+Mostre o consolidado de links da sessão (regra 5 de `eng.transitions-rules.md`, com o `pull-request.md` novo), o título e o resumo das seções e pergunte com `AskUserQuestion` (depois da mensagem com o consolidado de links): `[Aprovar]` / `[Ajustar]`, mais `[Só gerar os arquivos]` quando a Fase 0 foi "Revisar o texto e publicar" (essa opção troca a escolha da Fase 0 por "Só gerar os arquivos": nada é enviado). Ajuste até a aprovação ou até o `[Só gerar os arquivos]`. (Pulada com "Publicar sem revisar o texto" na Fase 0.)
 
 ### 4.3 Publicar ou não (sem pergunta nova)
 
-A decisão já veio da Fase 0; não pergunte de novo. Aprovado o texto na 4.2, siga a escolha:
+A decisão vem da Fase 0, que vale como a pergunta do push e do PR (exceção da regra de ouro, `eng.integrations-rules.md`), ou do `[Só gerar os arquivos]` da 4.2, que a troca por "Só gerar os arquivos"; não pergunte de novo. Aprovado o texto na 4.2 (ou escolhido o `[Só gerar os arquivos]` dela; com "Publicar sem revisar o texto", sem a revisão), siga a escolha:
 
 - **Só gerar os arquivos:** nada é enviado. O `pull-request.md` fica na sessão para você publicar quando quiser (à mão ou rodando o `/eng.pr` de novo). Pule para a Fase 7, que gera o `daily.md` mesmo assim (para não passar batido quando você abrir o PR à mão), com a mensagem "PR não publicado".
 - **Revisar o texto e publicar** ou **Publicar sem revisar o texto:** faça o push (Fase 3) e crie o MR/PR (4.4).
@@ -284,11 +284,11 @@ Pular a 5.1 se `TASK_MANAGER` estiver vazio (freelance); a 5.2 registra o link d
 
 ### 5.1 Mover Card
 
-Mova o card para a etapa equivalente a "em revisão" no seu board. Quem assumiu o card o move; não é preciso esperar o TECH LEAD ou o PM.
+Oriente a pessoa a mover o card para a etapa equivalente a "em revisão" no board (o Jarvis não move card). Quem assumiu o card o move; não é preciso esperar o TECH LEAD ou o PM.
 
 ### 5.2 Link do MR no card
 
-Siga o Passo 6 do skill `eng-global-pr`: um único comentário no card, com o link e a branch. É o único comentário do `eng.pr` no card.
+Siga o Passo 6 do skill `eng-global-pr`: monte um único comentário, com o link e a branch, e publique-o no card com `/eng-global-task-comment`, que mostra o texto e pergunta (regra de ouro, `eng.integrations-rules.md`); sem o Sim, ele fica no `task-comment-*.md` da sessão. É o único comentário do `eng.pr` no card.
 
 ---
 
@@ -308,12 +308,13 @@ Para cada comentário:
 
 ### 6.3 Aplicar Correções
 
-Se necessário:
+Se necessário, faça as correções e o commit. O push das correções sai só depois da pergunta (regra de ouro, `eng.integrations-rules.md`): mostre o commit e pergunte com `AskUserQuestion` (**Sim, publicar** / **Não, manter só local**); sem o Sim, o commit fica local.
 
 ```bash
 # Fazer mudanças
 git add {arquivos_alterados}
 git commit -m "fix: corrigir {problema} conforme code review"
+# só com o Sim da pergunta acima
 git push
 ```
 
@@ -357,7 +358,7 @@ fi
 
 Regras em `$IDE/rules-on-demand/engineering/eng.pr-rules.md` (seção "daily.md"); template em `$IDE/templates/engineering/daily-template.md`. Arquivo: `$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/daily.md`, **só na sessão, nunca publicado**.
 
-1. **Gere sempre**, com ou sem PR publicado: quem abre o PR à mão ("Só gerar os arquivos" na Fase 0) também precisa do registro, e é aí que ele costuma passar batido. Se houver PR (o criado na 4.4 ou o PR já aberto da branch, via CLI/adapter do vendor, ex.: `gh pr view --json state,number,url`), preencha o campo `pr`; sem PR, deixe-o vazio e atualize quando o PR for aberto.
+1. **Gere sempre**, com ou sem PR publicado: quem abre o PR à mão ("Só gerar os arquivos" na Fase 0 ou o `[Só gerar os arquivos]` da 4.2) também precisa do registro, e é aí que ele costuma passar batido. Se houver PR (o criado na 4.4 ou o PR já aberto da branch, via CLI/adapter do vendor, ex.: `gh pr view --json state,number,url`), preencha o campo `pr`; sem PR, deixe-o vazio e atualize quando o PR for aberto.
 2. **Data:** pergunte com `AskUserQuestion`: **"Registrar o esforço com qual data?"** → `Hoje ({AAAA-MM-DD})` | `Outra data` (o usuário digita `AAAA-MM-DD`).
 3. **Dias trabalhados** (só se o período entre a data do `.timestamp_start` e a data do registro tiver mais de um dia), uma pergunta por vez:
    - se o período tiver sábado ou domingo: **"Você trabalhou em {datas de sábado/domingo}?"** (Sim / Não; com várias datas, pode responder por data);
@@ -374,7 +375,7 @@ Regras em `$IDE/rules-on-demand/engineering/eng.pr-rules.md` (seção "daily.md"
 
    Atualize a seção da data escolhida. Se a data for nova, acrescente uma seção `## AAAA-MM-DD`.
 6. **Gerar** a descrição detalhada **e** a linha de timesheet, juntas.
-   - **Fontes:** `architecture.md`, `plan.md`, `gate-checklist.md`, `pull-request.md`, `git log {BRANCH_BASE}..HEAD`, o PR/MR e o card.
+   - **Fontes:** `architecture.md`, `plan.md`, `gate-checklist.md` (a rodada mais recente), `pull-request.md`, `git log {BRANCH_BASE}..HEAD`, o PR/MR e o card.
    - **Descrição:** um parágrafo narrativo (contexto técnico, trabalho realizado, decisões), mais o *post mortem* quando couber (problema e causa raiz, investigação, solução/direcionamento), com detalhe suficiente para embasar questionamentos futuros.
    - **Timesheet:** **uma única linha** (`{TASK_KEY} — {resumo}`).
    - Sem e-mails, tokens nem valores de variáveis.
@@ -383,12 +384,14 @@ Regras em `$IDE/rules-on-demand/engineering/eng.pr-rules.md` (seção "daily.md"
 ### 7.3 Mensagem Final
 
 ```
-✅ MERGE REQUEST CRIADO COM SUCESSO!
+✅ MERGE REQUEST CRIADO COM SUCESSO!       ← com o PR publicado
+📝 PR NÃO PUBLICADO                         ← com "Só gerar os arquivos", ou quando a 4.4 termina sem PR no host (saída 3 sem a CLI direta, ou saída 4 sem o PR criado); o pull-request.md fica pronto
 
 📋 Resumo:
 - Branch: {NOME_DA_BRANCH}
-- MR: {LINK_DO_MR}
-- Jira: {TASK_MANAGER_KEY} → "In Review"
+- MR: {LINK_DO_MR}   ← sem PR publicado: "— (abra à mão com o pull-request.md)"
+- Card: {URL do card, pela tabela da 4.1}   ← só com board; com o PR aberto, mova-o para a etapa equivalente a "em revisão" (o Jarvis não move card)
+- Labels: {labels sugeridos no PR Brief do gate-checklist.md, ex.: security}   ← só se houver; sem o relatório, ou sem o campo nele, avalie `eng-security-rules.md` direto; a pessoa adiciona no host (o `jarvis vcs create-merge` não põe label)
 
 📊 Validações:
 - Testes: ✅ Passando
@@ -401,27 +404,31 @@ Regras em `$IDE/rules-on-demand/engineering/eng.pr-rules.md` (seção "daily.md"
 - [context.md]({caminho relativo}) ({nota de estado})
 - [architecture.md]({caminho relativo}) ({nota de estado})
 - [plan.md]({caminho relativo}) ({nota de estado})
+- [gate-checklist-rodada-{N}.md]({caminho relativo}) (rodada {N})  ← uma por rodada anterior do `eng.pre-pr`, em ordem crescente do número do nome, se houver
 - [gate-checklist.md]({caminho relativo}) ({nota de estado})  ← se o `eng.pre-pr` rodou
 - [pull-request.md]({caminho relativo}) (novo; {publicado como PR #N | gerado, PR não publicado})
 - [daily.md]({caminho relativo}) (novo; {aprovado, com timesheet})
 🕒 Timesheet: {LINHA_DE_TIMESHEET_APROVADA}
 
-📌 Próximos passos:
+📌 Próximos passos (com o PR publicado):
 1. Aguardar revisão do time e processar os comentários do code review
 2. Merge após aprovação
 3. /eng.spec-consolidate {TASK_MANAGER_KEY} depois do merge → registrar no Central docs o que esta entrega implementou
+📌 Próximos passos (sem o PR publicado):
+1. Abrir o PR com o pull-request.md (à mão ou rodando o /eng.pr de novo)
+2. /eng.spec-consolidate {TASK_MANAGER_KEY} depois do merge
 
 🗂️ A sessão $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/ não é apagada (o /eng.spec-consolidate precisa dela).
    Remova à mão quando quiser.
 
 🔗 Links:
-- MR: {LINK_DO_MR}
-- Jira: {TASK_MANAGER_URL_BASE}/browse/{TASK_MANAGER_KEY}
+- MR: {LINK_DO_MR}   ← só com o PR publicado
+- Card: {URL do card, pela tabela da 4.1}   ← só com board
 ```
 
 ### 7.4 Versões humanizadas (só com `ARTIFACT_STYLE=human-generated`)
 
-Pergunte uma vez, com `AskUserQuestion` de várias perguntas em abas (`rules/artifact-style-rules.md`, regra 2), uma aba por documento da sessão que existir: `architecture.md`, `plan.md`, `gate-checklist.md` e `daily.md` (o `pull-request.md` não entra: já é público). Cada aba: **"Gerar a versão humanizada de {documento}?"** → **Não (como hoje)** / **Sim**. Com Sim, grave `{nome}.public.md` ao lado do original, seguindo o checklist da regra, e mostre o link. Com outro `ARTIFACT_STYLE`, pule esta etapa.
+Pergunte uma vez, com `AskUserQuestion` de várias perguntas em abas (`rules/artifact-style-rules.md`, regra 2), uma aba por documento da sessão que existir: `architecture.md`, `plan.md`, `gate-checklist.md` e `daily.md` (o `pull-request.md` não entra: já é público; as rodadas anteriores `gate-checklist-rodada-{N}.md` não ganham versão humanizada, só o `gate-checklist.md` atual). Cada aba: **"Gerar a versão humanizada de {documento}?"** → **Não (como hoje)** / **Sim**. Com Sim, grave `{nome}.public.md` ao lado do original, seguindo o checklist da regra, e mostre o link. Com outro `ARTIFACT_STYLE`, pule esta etapa.
 
 ### 7.5 PR mergeado? (`eng.transitions-rules.md`)
 
@@ -446,7 +453,7 @@ Pergunte com `AskUserQuestion`: **"O PR já foi aprovado e mergeado?"**
 - ✅ 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 a etapa equivalente a "em revisão" (o Jarvis não move card)
 - ✅ Gerar o `pull-request.md` na sessão e só publicar com a escolha de publicar da Fase 0 (4.3)
 - ✅ Com PR aberto, registrar o esforço no `daily.md` (7.2), com revisão conjunta da descrição e do timesheet
 - ✅ **Nunca apagar a sessão:** o `/eng.spec-consolidate` precisa dela