jarvis-ai-framework 7.0.0 → 8.1.0

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.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

@@ -87,6 +87,8 @@ 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").
+   - `Rodada` e `Commit` no cabeçalho, as rodadas anteriores e, da rodada 2 em diante, a resolução das lacunas da rodada anterior.
+   - É 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).
 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.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`.
@@ -44,7 +44,7 @@ Lida pelos workflows `eng.start`, `eng.plan`, `eng.work`, `eng.pre-pr` e `eng.pr
 | `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.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.

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

@@ -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`
 

package/skills/eng-global-tech-spec/references/delivery-spec.md

@@ -44,7 +44,7 @@ B: História / Task — implementação específica, pronta para desenvolvimento
 
 **Se recebeu URL/ID do $TASK_MANAGER:**
 
-- Busque o card usando a API ou ferramenta disponível
+- Leia o card pela CLI oficial do `$TASK_MANAGER` (ação `view` do catálogo, `eng.integrations-rules.md`), sem REST nem MCP; sem acesso, peça para colar o conteúdo
 - **Épico**: extraia título, descrição, objetivo de negócio, escopo e iniciativa relacionada
 - **História**: extraia título, descrição, critérios de aceitação, épico relacionado, comentários relevantes
 
@@ -322,8 +322,8 @@ Use as ferramentas de busca para identificar:
 
 Verifique se há documentação relevante:
 
-- **PRD relacionada**: `$DOCS_FOLDER/**/*prd*.md` ou anexos no Jira
-- **FRD relacionada**: `$DOCS_FOLDER/**/*frd*.md` ou anexos no Jira
+- **PRD relacionada**: `$DOCS_FOLDER/**/*prd*.md` ou anexos no card (lidos pela CLI ou colados pelo usuário)
+- **FRD relacionada**: `$DOCS_FOLDER/**/*frd*.md` ou anexos no card (lidos pela CLI ou colados pelo usuário)
 - **ADRs (Architecture Decision Records)**: `$DOCS_FOLDER/ARD/*.md` ou `./sessions/**/adr.md`
 - **README e documentação técnica**: `README.md`, `ARCHITECTURE.md`, `API.md`
 
@@ -671,7 +671,7 @@ Para cada caso extremo/erro:
 
 Exemplo: `$SESSIONS_DIR/eng/story-123/tech-spec.md`
 
-> **IMPORTANTE**: A tech spec é salva na sessão e anexada no Jira. O Jira é a fonte da verdade, não o repositório.
+> **IMPORTANTE**: A tech spec é salva na sessão. O anexo na issue é opcional e só sai na 6.4, depois da aprovação final e da pergunta.
 
 #### 6.2 Revisão de Qualidade
 
@@ -707,17 +707,23 @@ Apresente ao usuário:
 
 **Aguarde aprovação final do usuário.**
 
+#### 6.4 Anexo da tech spec na issue (opcional, com pergunta)
+
+Só com board configurado (no freelance não há issue: pule este passo). Só há pergunta quando o anexo vai sair: no Jira, com a `acli` logada que anexa arquivo (confira no `--help`) e `TASK_MANAGER_ACCESS=cli` (ou vazio). Nesse caso: para anexá-la na issue do board, depois da aprovação da 6.3, mostre o que vai e pergunte com `AskUserQuestion` (regra de ouro, `eng.integrations-rules.md`): **Sim, anexar** / **Não, manter só na sessão**; com o Sim, anexe pela `acli`; sem o Sim, a tech spec fica só na sessão. Nos demais casos (Jira sem a `acli` logada, `acli` que não anexa, acesso manual, GitHub ou GitLab, cuja CLI não anexa arquivo à issue) não há envio e, portanto, nenhuma pergunta: oriente a pessoa a anexar à mão. A mensagem da 8.2 diz o que aconteceu.
+
 ---
 
 ### ═══════════════════════════════════════════════
 
-### FASE 7: Criação de Subtarefas no Jira
+### FASE 7: Criação de Subtarefas (automática só no Jira)
 
 ### ═══════════════════════════════════════════════
 
+> **Escopo:** a criação automática de subtarefas é só no Jira, pela `acli`. Em GitHub ou GitLab, ou no Jira sem a `acli` logada ou com `TASK_MANAGER_ACCESS=manual`, esta fase entrega o template formatado e as instruções para a pessoa criar as subtarefas à mão; como não há envio, a 7.3 não faz a pergunta nesse caso. A generalização para `gh`/`glab` fica para uma issue à parte.
+
 #### 7.1 Preparação para Criação
 
-**Se o projeto usa Jira e a `acli` está logada (`acli jira workitem create`, conferindo os flags no `--help`), ou há uma ferramenta MCP do Jira configurada à mão:**
+**Se o projeto usa Jira, a `acli` está logada e `TASK_MANAGER_ACCESS=cli` ou vazio (vazio vale como `cli`, com o aviso do `/jarvis-init`), com `acli jira workitem create` (conferindo os flags no `--help`; a criação só sai na 7.3, depois da pergunta, regra de ouro):**
 
 Para cada subtarefa no plano:
 
@@ -729,26 +735,27 @@ Para cada subtarefa no plano:
 - Estimativa: {X horas}
 - Labels: `tech-spec`, `{área}` (ex: backend, frontend)
 
-#### 7.2 Estrutura da Descrição no Jira
+#### 7.2 Estrutura da Descrição no board
+
+Use o formato **Descrição da subtarefa no board** de `$IDE/templates/engineering/tech-spec-delivery-template.md` (seções: Descrição, Arquivos a Modificar/Criar, Critérios de Aceitação, Testes Requeridos, Dependências, Referência).
 
-Use o formato **Descrição da subtarefa no Jira** de `$IDE/templates/engineering/tech-spec-delivery-template.md` (seções: Descrição, Arquivos a Modificar/Criar, Critérios de Aceitação, Testes Requeridos, Dependências, Referência).
+#### 7.3 Criação (Jira pela `acli`; outros boards, template)
 
-#### 7.3 Criação no Jira
+Só há pergunta quando a criação vai sair: no Jira, com a `acli` logada e `TASK_MANAGER_ACCESS=cli` (ou vazio). Nos demais casos (fora do Jira, sem a `acli` ou com acesso manual) não há envio e, portanto, nenhuma pergunta: entregue o template formatado direto. Quando a criação vai sair, antes de criar as subtarefas, mostre o texto e pergunte com `AskUserQuestion` (**Sim, publicar** / **Não, manter só na sessão**), regra de ouro de `eng.integrations-rules.md`; sem o Sim, entregue só o template formatado e deixe o texto na sessão. O comentário da 7.4 tem a sua própria pergunta, feita pelo `/eng-global-task-comment`.
 
-**Se houver API/ferramenta disponível:**
+**No Jira, com a `acli` logada, `TASK_MANAGER_ACCESS=cli` (ou vazio) e o Sim:**
 
-- Use para criar subtarefas automaticamente
-- Vincule à história pai
-- Configure dependências entre subtarefas
+- Crie as subtarefas com `acli jira workitem create` (flags no `--help`)
+- Vincule à história pai e configure as dependências entre subtarefas no que a `acli` permitir (com o Sim acima); o resto vai no template manual abaixo
 
-**Se não houver ferramenta:**
+**Em GitHub/GitLab, sem a `acli` logada (ou com `TASK_MANAGER_ACCESS=manual`), ou sem o Sim:**
 
-- Forneça ao usuário **template formatado** para copiar/colar no Jira
+- Forneça ao usuário **template formatado** para copiar/colar no board (Jira, GitHub ou GitLab)
 - Forneça **instruções passo-a-passo** para criação manual
 
 #### 7.4 Atualização da História Original
 
-Adicione comentário na história original (STORY-XXX) com:
+Publique o comentário na história original (STORY-XXX) com o `/eng-global-task-comment`, que mostra o texto e pergunta (regra de ouro). O comentário segue este formato:
 
 Use o formato **Comentário na história original** de `$IDE/templates/engineering/tech-spec-delivery-template.md`.
 
@@ -766,10 +773,10 @@ Valide que:
 
 - [ ] Tech Spec completa e aprovada pelo usuário
 - [ ] Arquivo salvo na sessão: `$SESSIONS_DIR/eng/{feature-name}/tech-spec.md`
-- [ ] Tech Spec anexada na issue do Jira
+- [ ] Tech Spec anexada na issue (com o Sim), a anexar pela pessoa (orientado) ou deixada na sessão
 - [ ] Subtarefas documentadas com critérios claros
-- [ ] Subtarefas criadas no Jira (ou template fornecido)
-- [ ] História original atualizada com link para tech spec
+- [ ] Subtarefas criadas no Jira pela `acli`, ou template fornecido (outros boards, sem a CLI, com acesso manual, sem o Sim ou sem board)
+- [ ] História original atualizada com link para tech spec (com o Sim do comentário da 7.4) ou texto deixado na sessão
 - [ ] Decisões arquiteturais documentadas
 - [ ] Riscos identificados e mitigados
 - [ ] Dependências mapeadas
@@ -800,7 +807,7 @@ Use o formato **Mensagem de entrega** de `$IDE/templates/engineering/tech-spec-d
 - `$SESSIONS_DIR/eng/**/*.md` - Tech specs e ADRs de sessões anteriores
 - `README.md` - Visão geral do projeto
 - `ARCHITECTURE.md` - Arquitetura do sistema (se existir)
-- Anexos no Jira - PRD, FRD, ARD, RFC
+- Anexos no card (lidos pela CLI ou colados) - PRD, FRD, ARD, RFC
 
 ### Templates
 
@@ -821,7 +828,7 @@ O diagrama do fluxo (épico x história, fases 0 a 8) está na seção **Fluxo r
 
 → Liste o que falta e peça ao usuário para completar
 
-### Se não conseguir acessar o Jira:
+### Se não conseguir acessar o card no board:
 
 → Peça ao usuário para copiar/colar o conteúdo da história
 

package/skills/jarvis-docs-central/README.md

@@ -5,7 +5,7 @@ Integração com o **Central docs**: o registro do que **foi implementado** em c
 ## Visão Geral
 
 - **Buscar** o que já foi implementado (`jarvis docs sync`, `jarvis docs fetch`)
-- **Publicar** a consolidação de cada entrega (`jarvis docs publish`, pelo `/eng.spec-consolidate`)
+- **Publicar** a consolidação de cada entrega (`jarvis docs publish`, pelo `/eng.spec-consolidate`, depois da pergunta)
 - **Índice** regenerado a cada publicação (`{SQUAD}/index.md`)
 
 O Central docs funciona por **adaptador de armazenamento**: hoje uma pasta do disco (`filesystem`). Se essa pasta for um clone de um repositório de documentação (tem `.git`), a publicação vira branch + commit + push + Pull/Merge Request. S3 e Google Drive são as issues #144 e #145.
@@ -27,7 +27,7 @@ WORKSPACE=loja                           # vira a pasta do produto
 
 A pasta padrão é `docs/jarvis/central-docs` nos dois modos de trabalho, junto dos documentos de trabalho. No projeto único, `docs/jarvis/` no `.gitignore` a deixa fora do versionamento; no workspace (vários repositórios) a raiz não é versionada. Quem já usa `./central-docs` continua funcionando, e o Upgrade do `/jarvis-init` oferece mover a pasta.
 
-> Com `.git`, o PR é aberto pela CLI do host (`gh pr create` / `glab mr create`), com o login dela (`gh auth login`, `glab auth login`). Sem a CLI, ou com `VERSION_CONTROL_ACCESS` `manual`/inválido no `ENV.md` do projeto, a branch fica no remote e a publicação mostra o link para abrir o MR à mão. Nenhum token vai no chat nem no `ENV.md`.
+> Com `.git` (e só depois da pergunta do `/eng.spec-consolidate`, regra de ouro), o PR é aberto pela CLI do host (`gh pr create` / `glab mr create`), com o login dela (`gh auth login`, `glab auth login`). Sem a CLI, ou com `VERSION_CONTROL_ACCESS` `manual`/inválido no `ENV.md` do projeto, a branch fica no remote e a publicação mostra o link para abrir o MR à mão. Nenhum token vai no chat nem no `ENV.md`.
 
 **Vindo da versão anterior (Central docs como repositório remoto)?** Rode `/jarvis-init` → Upgrade (C). Ele propõe `CENTRAL_DOCS_STORAGE=filesystem`, a pasta padrão e o `git clone` do repositório antigo.
 
@@ -36,8 +36,8 @@ A pasta padrão é `docs/jarvis/central-docs` nos dois modos de trabalho, junto
 ```bash
 jarvis docs sync                                  # resumo: funcionalidades e entregas recentes
 jarvis docs fetch CORE/index.md                   # conteúdo de um arquivo (exit 2 se não existir)
-jarvis docs publish --file .../consolidation/feature-checkout.md --tipo feature            # pelo /eng.spec-consolidate
-jarvis docs publish --file .../consolidation/delivery-2026-10-15-task-123.md --tipo delivery
+jarvis docs publish --file .../consolidation/feature-checkout.md --tipo feature            # pelo /eng.spec-consolidate, depois do Sim (regra de ouro)
+jarvis docs publish --file .../consolidation/delivery-2026-10-15-task-123.md --tipo delivery  # idem
 ```
 
 - **Tipos:** só `feature` (vai para `product/`) e `delivery` (vai para `engineering/`). PRD, ARD, SPEC e os outros documentos de trabalho são recusados, com a explicação de que ficam em `docs/jarvis/`.

package/skills/jarvis-docs-central/SKILL.md

@@ -56,6 +56,8 @@ Ler do `$IDE/ENV.md`:
 - `CENTRAL_DOCS_REF`, `CENTRAL_DOCS_TARGET_BRANCH`, `CENTRAL_DOCS_REVIEWERS` (só com `.git`)
 - `SQUAD` (ALL-CAPS-COM-HIFEN) e `WORKSPACE` (vira a pasta do produto)
 
+O `jarvis docs publish` só roda depois da pergunta do `/eng.spec-consolidate` (regra de ouro, `rules/engineering/eng.integrations-rules.md`).
+
 Com `.git`, o PR é aberto pela CLI do host (`gh pr create` / `glab mr create`), com o login dela, respeitando o `VERSION_CONTROL_ACCESS` do `ENV.md` do projeto (não do repositório do Central docs). Sem a CLI, sem login, ou com `manual`/valor inválido/ENV.md ilegível, a branch fica no remote e a publicação mostra o link para abrir o MR à mão. ❌ **Nunca** colar token no chat nem gravar no `ENV.md`.
 
 ---
@@ -157,12 +159,12 @@ jarvis docs publish --file .../consolidation/feature-checkout.md --tipo feature
 1. Validar o frontmatter.
 2. Calcular o destino.
 3. Sem `.git`: copiar e regenerar o índice.
-4. Com `.git`: branch, cópia, índice, commit, push e PR.
+4. Com `.git`: branch, cópia, índice, commit, push e PR (só depois da pergunta, regra de ouro).
 
 ### Modo 3: Reparar o índice
 
 - **Sem `.git`:** a próxima publicação regenera o índice.
-- **Com `.git`:** no clone, rodar `bash scripts/build-index.sh` (se existir) e abrir um PR `repair/index-{SQUAD}-{data}`.
+- **Com `.git`:** no clone, rodar `bash scripts/build-index.sh` (se existir) e abrir um PR `repair/index-{SQUAD}-{data}` (só depois de mostrar o que será enviado e perguntar, regra de ouro).
 
 ### Skills invocados durante a execução do skill