jarvis-ai-framework 2.1.1 → 3.2.0

package/templates/engineering/advisor-template.md

@@ -0,0 +1,65 @@
+# Advisor — prompts e auditoria
+
+> Usado pelo `eng.start` (e, por exceção, pelo `eng.plan` e pelo `eng.work`) com o agente `eng.advisor.agent`. Os campos `{...}` são preenchidos pelo agente principal.
+
+## Prompt 1 — Carga inicial (uma vez por tarefa, na primeira questão em aberto)
+
+```
+Você é o Advisor desta tarefa ({TASK_MANAGER_KEY}). Você esclarece as questões em aberto que eu enviar, uma por vez, e devolve a sugestão mais adequada; ela é adotada como decisão final. Eu (agente principal) faço a análise do card, a documentação, a execução e os registros.
+
+Agora, somente leitura (não edite, não troque de branch, não faça commit; no GitHub, só consulta): leia as fontes de contexto do seu arquivo de agente — card, documentos de especificação ($PROD_DOCS, seguindo task_link e related_*), pastas de sessão ({SESSAO_ENG} e {SESSAO_PROD}) e, se preciso, o repositório {REPO}.
+
+Etapas da tarefa:
+| Etapa | O que acontece | Onde o Advisor entra |
+| 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 |
+| 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 |
+
+Responda SOMENTE com "Contexto lido" + os caminhos que leu + uma frase de até 20 palavras sobre o objetivo da tarefa. Se o contexto for insuficiente para orientar, responda "Preciso de ajuda para localizar o contexto", dizendo onde procurou e o que precisa.
+```
+
+## Prompt 2 — Questão em aberto (uma mensagem por questão)
+
+```
+Questão {QN} de {TOTAL} ({TASK_MANAGER_KEY}). Texto completo na seção 8 do architecture.md ({CAMINHO}).
+
+Contexto: {por que a dúvida existe e o impacto na implementação}
+Arquivos/componentes envolvidos: {arquivo — relação}
+Dúvida: {o que precisa ser decidido}
+Opções:
+1. {opção} — como funciona, vantagens, desvantagens, impacto
+2. {opção} — ...
+3. {opção} — ...
+4. Outra (sua, se houver)
+Sugestão do agente principal: {N}, porque {motivo}
+
+Analise o repositório só se precisar para ter certeza (sem chutar). Responda (até ~250 palavras):
+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)
+
+```
+## Auditoria — questões do architecture.md
+
+Questões levantadas no `architecture.md` desta issue e a sugestão do Advisor ({modelo}). **A sugestão do Advisor prevalece e é a decisão adotada.** Análise, documentação, execução e este registro são do agente principal.
+
+### {QN} — {título}
+- **Contexto:** {...}
+- **Arquivos envolvidos:** {...}
+- **Opções:** 1 — {...} · 2 — {...} · 3 — {...} · 4 — Outra
+- **Sugestão do agente principal:** {N}
+- **Sugestão do Advisor (decisão adotada):** **{N}**
+- **Divergência:** {motivo técnico, ou "sem divergência"}
+- **Base:** {...}
+- **Análise no repositório:** {arquivos e linhas, ou "não foi necessário"}
+- **Certeza:** {alta|média|baixa} — escrito: {...}; confirmado no código: {...}; inferência: {...}
+- **Impacto da decisão:** {...}
+- **Levantada em:** {eng.start | eng.plan | eng.work} (fora do eng.start, é lacuna a citar no PR)
+
+Link do PR: {#PR} (preenchido quando existir; se a decisão for revista na execução, atualizar este mesmo comentário)
+```

package/templates/engineering/architecture-template.md

@@ -5,7 +5,8 @@
 
 > **Criado em:** {DATA}  
 > **Issue:** {JIRA_ISSUE_KEY}  
-> **Status:** 🔄 Em Revisão | ✅ Aprovado | ❌ Rejeitado
+> **Status:** 🔄 Em Revisão | ✅ Aprovado | ❌ Rejeitado  
+> **Advisor:** {modelo escolhido no início do eng.start} | não utilizado
 
 ---
 
@@ -245,9 +246,56 @@ graph TD
 
 ## 8. Questões em Aberto
 
-| ID  | Questão                        | Responsável | Deadline | Status   |
-| --- | ------------------------------ | ----------- | -------- | -------- |
-| Q1  | {questão ainda não respondida} | {quem}      | {data}   | 🔄 Aberta |
+> Tudo que for **diferente do código ou ambíguo no card** vira uma questão aqui, detalhada a ponto de outro agente entendê-la sem reconstruir a análise. No mínimo 3 opções, mais a **4 — Outra**.
+> **Com Advisor** (cabeçalho), a sugestão do Advisor prevalece e é a decisão adotada; o agente principal não a substitui nem contesta. **Sem Advisor**, "Sugestão do Sub-Agent (Advisor)" e "Divergência" ficam "N/A (Advisor não utilizado)", a regra em destaque é omitida e a decisão é a do usuário ao revisar o documento.
+> Questão levantada depois do `eng.start` (consulta por exceção) entra aqui, numerada em sequência, marcada "levantada no `eng.plan`" ou "no `eng.work`". Sem questão em aberto, escreva "Nenhuma" e o motivo em uma frase.
+
+| ID | Questão                      | Responsável                 | Deadline | Status                     |
+| -- | ---------------------------- | --------------------------- | -------- | -------------------------- |
+| Q1 | {resumo objetivo da questão} | {Advisor \| nome do usuário} | {— \| data} | {✅ Decidida \| 🔄 Aberta} |
+
+### Q1 — {Título da questão}
+
+**Contexto:**
+{Explicação detalhada do problema e por que a decisão é necessária.}
+
+**Arquivos/componentes envolvidos:**
+* `{arquivo/caminho}` — {relação com a questão}
+
+**Dúvida:**
+{Descrição clara e inequívoca do que precisa ser decidido.}
+
+**Opções:**
+
+**1. {Opção 1}**
+* Como funciona: {descrição}
+* Vantagens: {vantagens}
+* Desvantagens: {desvantagens}
+* Impacto: {impacto}
+
+**2. {Opção 2}** (mesmo formato)
+
+**3. {Opção 3}** (mesmo formato)
+
+**4. Outra**
+* Alternativa adicional identificada pelo Sub-Agent/Advisor, detalhada caso ele entenda que nenhuma das opções anteriores é a melhor abordagem.
+
+**Sugestão do Agente Principal (Architect):**
+{recomendação do agente principal + justificativa técnica}
+
+**Sugestão do Sub-Agent (Advisor):**
+{recomendação independente do Advisor + justificativa técnica}
+
+**Decisão adotada:**
+**{recomendação do Sub-Agent/Advisor}**
+
+> **Regra:** a recomendação do Advisor sempre prevalece e deve ser adotada na implementação, independentemente de ser igual ou diferente da recomendação do Agente Principal.
+
+**Divergência:**
+{se houver diferença entre as recomendações, explicar objetivamente por que o Advisor escolheu uma abordagem diferente.}
+
+**Impacto da decisão:**
+{consequências da decisão adotada para a arquitetura e implementação.}
 
 ---
 

package/templates/engineering/qa/qa.sprint-plan-template.md

@@ -30,7 +30,7 @@ status: Draft
 |------|--------|-------|-----------|-------------|------------|
 | {ID} | {título} | Alto | E2E + exploratório | {QA} | |
 | {ID} | {título} | Médio | Quality gate | {QA ou Champion} | |
-| {ID} | {título} | Baixo | Delegar ao dev | {Champion} | eng-qa-dev-guide |
+| {ID} | {título} | Baixo | Delegar ao dev | {Champion} | base eng-qa |
 
 ---
 

package/workflows/AGENTS.md

@@ -56,7 +56,9 @@ workflows/
     │   ├── eng.frontend-review.md      # Revisão de PR frontend
     │   └── eng.frontend-perf-audit.md  # Auditoria de performance (Core Web Vitals)
     └── qa/
-        └── eng.qa-quality-gate-validation.md
+        ├── eng.qa-refinement-entry.md
+        ├── eng.qa-release-signoff.md
+        └── eng.qa-sprint-planning.md
 ```
 
 ---

package/workflows/README.md

@@ -45,11 +45,6 @@ workflows/
     │   ├── eng.frontend-review.md        # Revisão de PR frontend (TS, tokens, a11y, MFE)
     │   └── eng.frontend-perf-audit.md    # Auditoria Core Web Vitals e bundle
     └── qa/
-        ├── eng.qa-quality-gate-validation.md
-        ├── eng.qa-e2e-test-generation.md
-        ├── eng.qa-exploratory-session.md
-        ├── eng.qa-dev-quality-guide.md
-        ├── eng.qa-quality-report.md
         ├── eng.qa-refinement-entry.md
         ├── eng.qa-release-signoff.md
         └── eng.qa-sprint-planning.md
@@ -106,11 +101,6 @@ workflows/
 | `eng.frontend-component.md` | Criar ou refatorar componente frontend com qualidade (design system vs remote, a11y, testes) |
 | `eng.frontend-review.md` | Revisão de código específica para PRs frontend (TypeScript, tokens, a11y, MFE) |
 | `eng.frontend-perf-audit.md` | Auditoria de performance frontend (Core Web Vitals, bundle, diagnóstico por métrica) |
-| `eng.qa-quality-gate-validation.md` | Validação de quality gate de um ticket |
-| `eng.qa-e2e-test-generation.md` | Geração de testes E2E Cypress para uma feature |
-| `eng.qa-exploratory-session.md` | Conduzir sessão de teste exploratório |
-| `eng.qa-dev-quality-guide.md` | Orientar dev a escrever seus próprios testes Cypress |
-| `eng.qa-quality-report.md` | Relatório de qualidade consolidado por sprint/release |
 | `eng.qa-refinement-entry.md` | Entrada do QA no refinement de tickets |
 | `eng.qa-release-signoff.md` | Sign-off QA pré-deploy (GO/NO-GO) |
 | `eng.qa-sprint-planning.md` | Planejamento de capacidade QA por sprint |

package/workflows/engineering/data/data.new-pipeline.md

@@ -43,7 +43,7 @@ seguindo as convenções definidas em `$IDE/rules/engineering/data/data-rules.md
 | Passo | Skill | Condição |
 |-------|-------|----------|
 | Agentes recomendados | `eng.data-engineer.agent` (agente) | Sempre — agente primário que conduz todo o workflow |
-| Pré-verificação — Fonte nova ou existente? | `/eng-data-onboard` | Se a fonte nunca foi ingerida antes (pipeline totalmente novo); depois volta a este workflow |
+| Pré-verificação — Fonte nova ou existente? | `/eng-data` | Se a fonte nunca foi ingerida antes (pipeline totalmente novo); depois volta a este workflow |
 | Agentes recomendados | `eng.dev-code-reviewer` (agente) | Se o pipeline tiver lógica de transformação complexa ou antes de qualquer push ao repositório de pipelines |
 | Agentes recomendados | `eng.qa.test-planner` (agente) | Se o pipeline for gold com múltiplos casos de uso, dados sensíveis ou SLA rigoroso (apoio à Expectation Suite) |
 | Agentes recomendados | `eng.docs-writer` (agente) | Se o pipeline for de alta criticidade ou precisar de documentação além do template (diagramas, runbook, troubleshooting) |
@@ -71,10 +71,11 @@ seguindo as convenções definidas em `$IDE/rules/engineering/data/data-rules.md
 
 > Antes de iniciar, verificar se já há dados desta fonte em bronze.
 
-**Se a fonte nunca foi ingerida antes** (pipeline totalmente novo):
-→ Executar `eng-data-onboard` primeiro para fazer schema discovery, amostragem e criar a camada bronze.
-→ Arquivo: `$IDE/skills/eng-data-onboard/SKILL.md`
-→ Voltar para este workflow após o bronze estar validado (Fases 3–5 do onboard concluídas).
+**Se a fonte nunca foi ingerida antes** (pipeline totalmente novo), usar a base [eng-data]($IDE/skills/eng-data/SKILL.md) (tema 1 — Fundamentos, tema 5 — Pipelines e Integração) para:
+1. Entender a fonte (nome, tipo, frequência, volume, owner, campos disponíveis e sensíveis, SLA)
+2. Fazer schema discovery e amostragem
+3. Criar a camada bronze e uma Expectation Suite mínima (tema 6 — Qualidade de Dados)
+→ Voltar para este workflow (Fase 1 abaixo) depois do bronze estar validado.
 
 **Se a fonte já existe em bronze** → continuar diretamente com a Fase 1 abaixo.
 

package/workflows/engineering/eng.bug-audit.md

@@ -62,7 +62,7 @@ Onde [escopo] pode ser:
 | Passo | Skill | Condição |
 |-------|-------|----------|
 | Fase 0 – Análise de Contexto (CDD) | `/jarvis-context-detect` | Se existir uma sessão ativa (e `ENABLE_CDD=true` no ENV.md) |
-| Fase 5 – Ticketing › 5.1 | `/eng-qa-bug-report create` | Para cada problema P0 e P1 encontrado no audit |
+| Fase 5 – Ticketing › 5.1 | `/eng-qa` + `QA_SPECIALIZATIONS` | Para estruturar cada problema P0 e P1 encontrado no audit antes de abrir o card |
 
 ---
 
@@ -463,19 +463,9 @@ echo "✅ Relatório gerado em: $SESSIONS_DIR/eng/bug-audit-$(date +%Y%m%d-%H%M%
 
 ## Fase 5 – Ticketing (Criação de Cards no Task Manager)
 
-### 5.1 Usar Skill eng-qa-bug-report
+### 5.1 Estruturar e abrir o card
 
-Para cada problema P0 e P1:
-
-```bash
-/eng-qa-bug-report create \
-  --title="{título do bug}" \
-  --category="{categoria}" \
-  --severity="{P0|P1|P2|P3}" \
-  --location="{arquivo:linha}" \
-  --description="{descrição}" \
-  --suggestion="{sugestão de correção}"
-```
+Para cada problema P0 e P1, use a base [eng-qa](../../skills/eng-qa/SKILL.md) + a especialização registrada em `QA_SPECIALIZATIONS` (se houver uma) — tema 14, Gestão de Testes e de Defeitos — para estruturar o achado, e abra o card no `$TASK_MANAGER` do projeto com a estrutura da seção 5.2.
 
 ### 5.2 Estrutura dos Cards Criados
 
@@ -576,7 +566,7 @@ Cada card deve conter:
 - **eng.debug**: Para investigar bugs específicos encontrados no audit
 - **eng.work**: Para implementar correções
 - **eng.pr**: Para submeter correções
-- **eng-qa-gate**: Para validar correções antes de merge
+- **eng.pre-pr**: Para validar correções antes de merge
 
 ---
 

package/workflows/engineering/eng.debug.md

@@ -37,8 +37,8 @@ sempre respeitando `$IDE/rules/engineering/eng-rules.md`.
 | Passo 1.0 | `mcp__claude_ai_Atlassian__getJiraIssue` | Se Jira key fornecida |
 | Passo 1.5 | `Read` / `Grep` / `Glob` (leitura do repo) | **Sempre** — obrigatório antes de formular hipóteses |
 | Passo 2.5 | `/eng-backend-microservices-trace` | Se bug suspeito de cruzar serviços **e** a especialização estiver registrada em `BACKEND_SPECIALIZATIONS` |
-| Passo 6 | `/eng-qa-unit-test` | Para criar teste de regressão da correção |
-| Passo 7 | `/eng-qa-bug-report create` | Para cada débito técnico ou melhoria identificada |
+| Passo 6 | `/eng-qa` + `QA_SPECIALIZATIONS` | Para criar teste de regressão da correção |
+| Passo 7 | `/eng-qa` + `QA_SPECIALIZATIONS` | Para estruturar cada débito técnico ou melhoria identificada antes de abrir o card |
 | Conclusão | `mcp__claude_ai_Atlassian__addCommentToJiraIssue` | Sempre — atualizar o card com findings |
 
 ### Próximos workflows (pós-debug)
@@ -383,11 +383,7 @@ Próximo passo: → eng.work {TASK_MANAGER_KEY}
 
 ### 6.1 – Criar teste de regressão
 
-Invocar o skill de testes unitários para criar o teste que reproduz o bug:
-
-```
-/eng-qa-unit-test --mode=regression --bug=”{descrição da causa raiz}” --file=”{arquivo corrigido}”
-```
+Usar a base [eng-qa](../../skills/eng-qa/SKILL.md) + a especialização registrada em `QA_SPECIALIZATIONS` (se houver uma) — tema 5, Automação de Testes — para criar o teste que reproduz o bug, seguindo o framework de testes já usado no projeto.
 
 O teste deve:
 - **Falhar** antes da correção ser aplicada (prova que reproduz o bug)
@@ -424,19 +420,7 @@ Quando fizer sentido, recomendar:
 
 ### 7.2 – Criar cards de débito técnico
 
-Para cada melhoria estrutural identificada, criar um card de débito técnico:
-
-```
-/eng-qa-bug-report create \
-  --title="[{serviço}] {descrição da melhoria}" \
-  --category="DÉBITO-TÉCNICO" \
-  --location="{arquivo:linha relevante}" \
-  --description="{por que essa melhoria é necessária}" \
-  --behavior-actual="{o que existe hoje}" \
-  --behavior-expected="{o que deveria existir}" \
-  --environment="prod" \
-  --linked-to="{TASK_MANAGER_KEY}"
-```
+Para cada melhoria estrutural identificada, estruturar o achado com a base [eng-qa](../../skills/eng-qa/SKILL.md) + a especialização registrada em `QA_SPECIALIZATIONS` (se houver uma) — tema 14, Gestão de Testes e de Defeitos — e abrir o card de débito técnico (`DÉBITO-TÉCNICO P{0-3}`) no `$TASK_MANAGER` do projeto, vinculado a `{TASK_MANAGER_KEY}`, com: localização, comportamento atual vs. esperado e ambiente.
 
 Exemplos típicos após um debug cross-service:
 - `[account] Correlation ID não propagado nas chamadas HTTP para auth` → `DÉBITO-TÉCNICO P2`

package/workflows/engineering/eng.plan.md

@@ -41,25 +41,11 @@ Antes de executar este workflow:
 | Passo | Skill | Condição |
 |-------|-------|----------|
 | Cabeçalho (agente) | `eng.agent` (agente) | Sempre — identidade do workflow |
-| Fase 0.5: Comentário no card — Início | `/eng-global-task-comment` | Se `TASK_MANAGER` estiver preenchido (freelance pula) |
 | 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 |
-| Comentário no card — Conclusão | `/eng-global-task-comment` | Se `TASK_MANAGER` estiver preenchido, após validar o plano com o usuário (freelance pula) |
-
----
-
-## Fase 0.5: Comentário no card — Início
-
-Pular se `TASK_MANAGER` estiver vazio (freelance).
-
-Após confirmar que o `architecture.md` existe, registrar início do planejamento:
-
-```
-/eng-global-task-comment {TASK_MANAGER_KEY} 📋 [Jarvis] Iniciando criação do plano de execução
-```
-
-> Usa o skill `/eng-global-task-comment`. Não bloquear se falhar.
+| 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) |
 
 ---
 
@@ -174,6 +160,8 @@ 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.
+
 ### Fase 4: Validação
 
 1. **Apresentar** o plano ao humano
@@ -200,16 +188,6 @@ Com:
 
 ---
 
-## Comentário no card — Conclusão
-
-Pular se `TASK_MANAGER` estiver vazio (freelance).
-
-Após validação do plano com o usuário, registrar conclusão:
-
-```
-/eng-global-task-comment {TASK_MANAGER_KEY} ✅ [Jarvis] Plano de execução criado e validado - {N} fases definidas. Pronto para implementação.
-```
-
 ## Próximo Passo
 
 Após a validação do plano com o humano, informar:

package/workflows/engineering/eng.pr.md

@@ -20,16 +20,12 @@ Este comando cria a **branch, commita as alterações e abre um Merge Request**.
 
 - **pr**: siga o playbook do skill para padronizar branch, commits e MR.
   - Arquivo: `$IDE/skills/eng-global-pr/SKILL.md`
-- **eng-qa-test-plan**: se precisar validar lacunas de testes antes de abrir o MR.
-  - Arquivo: `$IDE/skills/eng-qa-test-plan/SKILL.md`
-- **eng-qa-testsprite**: para executar testes automatizados E2E/API antes de abrir o MR.
-  - Arquivo: `$IDE/skills/eng-qa-testsprite/SKILL.md`
-- **eng-qa-e2e**: para validar fluxos de usuário críticos com testes E2E em linguagem natural antes de abrir o MR.
-  - Arquivo: `$IDE/skills/eng-qa-e2e/SKILL.md`
+- **eng-qa-planner**: se precisar validar lacunas de testes antes de abrir o MR — se a especialização estiver registrada em `QA_SPECIALIZATIONS`. Sem ela, use a base `eng-qa` diretamente.
+  - Arquivo: `$IDE/skills/eng-qa-planner/SKILL.md`
+- **eng-qa** + a especialização registrada em `QA_SPECIALIZATIONS` (se houver uma): para validar fluxos de usuário críticos ou executar testes automatizados antes de abrir o MR.
+  - Arquivo: `$IDE/skills/eng-qa/SKILL.md`
 - **eng-global-docs-write**: se houver necessidade de atualizar documentação junto do PR.
   - Arquivo: `$IDE/skills/eng-global-docs-write/SKILL.md`
-- **eng-security-cybersecurity**: se o PR toca em auth, inputs, APIs públicas ou permissões — adicionar label `security` ao MR.
-  - Arquivo: `$IDE/skills/eng-security-cybersecurity/SKILL.md`
 
 ## Agentes recomendados (opcional)
 
@@ -43,15 +39,12 @@ Este comando cria a **branch, commita as alterações e abre um Merge Request**.
 |-------|-------|----------|
 | Cabeçalho (agente) | `eng.agent` (agente) | Sempre — identidade do workflow |
 | Skills recomendados | `/eng-global-pr` | Sempre — seguir o playbook do skill para padronizar branch, commits e MR |
-| Skills recomendados | `/eng-qa-test-plan` | Se for preciso validar lacunas de testes antes de abrir o MR |
-| Fase 1 › 1.4 Executar Testes Automatizados (Opcional) | `/eng-qa-testsprite` | Se o projeto estiver rodando localmente (`/eng-qa-testsprite diff`); passo opcional, recomendado em mudanças significativas |
-| Skills recomendados | `/eng-qa-e2e` | Se for preciso validar fluxos de usuário críticos com testes E2E em linguagem natural antes de abrir o MR |
+| Skills recomendados | `/eng-qa-planner` | Se for preciso validar lacunas de testes antes de abrir o MR **e** a especialização estiver registrada em `QA_SPECIALIZATIONS` |
+| Fase 1 › 1.4 Executar Testes Automatizados (Opcional) | `/eng-qa` + `QA_SPECIALIZATIONS` | Passo opcional, recomendado em mudanças significativas |
 | Skills recomendados | `/eng-global-docs-write` | Se houver necessidade de atualizar documentação junto do PR |
-| Skills recomendados | `/eng-security-cybersecurity` | Se o PR tocar em auth, inputs, APIs públicas ou permissões (adicionar label `security` ao MR) |
 | Agentes recomendados (opcional) | `eng.qa.test-planner` (agente) | Se houver dúvidas sobre cobertura de testes ou mudanças significativas |
-| Fase 0.5: Comentário no card — Início | `/eng-global-task-comment` | Se `TASK_MANAGER` estiver preenchido (freelance pula) |
-| Fase 4 › 4.2 Criar MR/PR via adapter | `node bin/lib/vcs/create-merge.js` (CLI do Jarvis) | Sempre — abre o MR/PR conforme `VERSION_CONTROL` ou o host do `origin` |
-| Fase 5: Comentário no card — Conclusão | `/eng-global-task-comment` | Se `TASK_MANAGER` estiver preenchido, depois de o MR ser criado (freelance pula) |
+| Fase 4 › 4.2 Criar MR/PR via adapter | `jarvis vcs create-merge` (CLI do Jarvis) | Sempre — abre o MR/PR conforme `VERSION_CONTROL` ou o host do `origin` |
+| Fase 6 › 6.2 Link do MR | `/eng-global-task-comment` | Depois de o MR ser criado: um único comentário no card com o link do MR, seguindo o Passo 6 do skill `eng-global-pr` (freelance pula) |
 
 ---
 
@@ -73,20 +66,6 @@ Ler `TASK_MANAGER` do `$IDE/ENV.md`. Seguir `$IDE/rules/engineering/eng.integrat
 
 ---
 
-## Fase 0.5: Comentário no card — Início
-
-Pular se `TASK_MANAGER` estiver vazio (freelance).
-
-Registrar início da criação do MR:
-
-```
-/eng-global-task-comment {TASK_MANAGER_KEY} 🔀 [Jarvis] Iniciando criação do Merge Request para {TARGET_BRANCH}
-```
-
-> Usa o skill `/eng-global-task-comment`. Não bloquear se falhar.
-
----
-
 ## Fase 1: Validação Pré-PR
 
 ### 1.1 Executar Testes Unitários
@@ -109,19 +88,7 @@ npm run build  # ou comando do projeto
 
 ### 1.4 Executar Testes Automatizados (Opcional)
 
-Se o projeto estiver rodando localmente, execute o skill **eng-qa-testsprite** para validação completa:
-
-```
-/eng-qa-testsprite diff
-```
-
-Isso irá:
-
-- Gerar plano de testes para as mudanças recentes (diff)
-- Executar testes E2E (frontend) ou API (backend)
-- Gerar relatório em `testsprite_tests/`
-
-> **Observação**: o comportamento exato de "diff" pode variar (staged vs uncommitted). Se necessário, valide com o usuário qual estado do Git deve ser considerado antes de executar.
+Para mudanças significativas, use a base [eng-qa](../../skills/eng-qa/SKILL.md) (ou a especialização registrada em `QA_SPECIALIZATIONS`, se houver uma) para validar os cenários afetados pelo diff antes de abrir o MR.
 
 > **Nota**: Este passo é opcional mas recomendado para mudanças significativas.
 
@@ -243,7 +210,7 @@ Preencher com a tarefa. Link do card:
 BODY_FILE=$(mktemp)
 # gravar a descrição preenchida em $BODY_FILE
 
-node bin/lib/vcs/create-merge.js \
+jarvis vcs create-merge \
   --source "${NOME_DA_BRANCH}" \
   --target "${TARGET_BRANCH}" \
   --title "${TASK_MANAGER_KEY}: ${TITULO_DA_TAREFA}" \
@@ -254,7 +221,7 @@ rm -f "$BODY_FILE"
 
 O adapter lê `git remote get-url origin` e `VERSION_CONTROL` / hostname (GitLab, GitHub, Bitbucket). Token: `.npmrc` (GitLab), `gh auth` / `GITHUB_TOKEN` (GitHub), `BITBUCKET_TOKEN` (Bitbucket).
 
-Se o script não estiver no repo alvo, usar o path do clone do framework Jarvis.
+Se o CLI `jarvis` não estiver instalado no repo alvo, usar `node {caminho-do-clone-do-jarvis}/bin/jarvis.js vcs create-merge ...`.
 
 **Erros comuns:**
 
@@ -266,18 +233,6 @@ Se o script não estiver no repo alvo, usar o path do clone do framework Jarvis.
 
 ---
 
-## Fase 5: Comentário no card — Conclusão
-
-Pular se `TASK_MANAGER` estiver vazio (freelance).
-
-Após MR criado com sucesso, registrar:
-
-```
-/eng-global-task-comment {TASK_MANAGER_KEY} ✅ [Jarvis] MR criado: {TITULO_DO_MR} → {TARGET_BRANCH} | Link: {LINK_DO_MR}
-```
-
----
-
 ## Fase 6: Atualizar Board
 
 Pular se `TASK_MANAGER` estiver vazio (freelance).
@@ -286,14 +241,9 @@ Pular se `TASK_MANAGER` estiver vazio (freelance).
 
 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.
 
-### 6.2 Adicionar Comentário
+### 6.2 Link do MR no card
 
-Adicione um comentário no card com o link do MR:
-
-```
-MR aberto: {LINK_DO_MR}
-Branch: {NOME_DA_BRANCH}
-```
+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.
 
 ---
 

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

@@ -16,20 +16,16 @@ Estamos nos aproximando de finalizar o trabalho nesta branch e nos preparar para
 
 ## Skills recomendados
 
-- **eng-qa-test-plan**: para avaliar cobertura de testes e identificar gaps antes do PR.
-  - Arquivo: `$IDE/skills/eng-qa-test-plan/SKILL.md`
-- **eng-qa-testsprite**: para executar testes automatizados e validar cobertura com TestSprite MCP.
-  - Arquivo: `$IDE/skills/eng-qa-testsprite/SKILL.md`
+- **eng-qa-planner**: para avaliar cobertura de testes e identificar gaps antes do PR — se a especialização estiver registrada em `QA_SPECIALIZATIONS` (ver `$IDE/rules/engineering/eng.specializations-rules.md`). Sem ela, use a base `eng-qa` diretamente.
+  - Arquivo: `$IDE/skills/eng-qa-planner/SKILL.md`
 - **eng-global-docs-write**: para atualizar documentação baseada nas mudanças da branch.
   - Arquivo: `$IDE/skills/eng-global-docs-write/SKILL.md`
 - **jarvis-docs-index**: para atualizar o índice de documentação quando necessário.
   - Arquivo: `$IDE/skills/jarvis-docs-index/SKILL.md`
-- **eng-devops-performance-engineer**: para validar thresholds de performance e analisar regressões quando a feature tiver requisitos não-funcionais de latência, throughput ou escalabilidade.
-  - Arquivo: `$IDE/skills/eng-devops-performance-engineer/SKILL.md`
+- **eng-platform** + a especialização registrada em `PLATFORM_SPECIALIZATIONS` (se houver uma): para validar thresholds de performance e analisar regressões quando a feature tiver requisitos não-funcionais de latência, throughput ou escalabilidade (temas 14, 15 e 16).
+  - Arquivo: `$IDE/skills/eng-platform/SKILL.md`
 - **Skills de backend e frontend**: para validar código de backend (endpoints, autenticação, workers) ou de frontend (componentes, performance de UI e acessibilidade WCAG 2.1 AA), aplique a regra `$IDE/rules/engineering/eng.specializations-rules.md` para a área envolvida: ela carrega o skill base e as especializações registradas no `ENV.md`.
   - Arquivo da regra: `$IDE/rules/engineering/eng.specializations-rules.md`
-- **eng-security-cybersecurity**: quando a branch tocar em auth, sessions, inputs, CORS, CSP, permissões ou adicionar dependências novas.
-  - Arquivo: `$IDE/skills/eng-security-cybersecurity/SKILL.md`
 
 <arguments>
 #$ARGUMENTS
@@ -39,39 +35,23 @@ Estamos nos aproximando de finalizar o trabalho nesta branch e nos preparar para
 
 | Passo | Skill | Condição |
 |-------|-------|----------|
-| Skills recomendados | `/eng-qa-test-plan` | Para avaliar cobertura de testes e identificar gaps antes do PR |
+| Skills recomendados | `/eng-qa-planner` | Se a especialização estiver registrada em `QA_SPECIALIZATIONS`; sem ela, usar a base `/eng-qa` diretamente |
 | Skills recomendados | `/eng-global-docs-write` | Para atualizar a documentação com base nas mudanças da branch |
 | Skills recomendados | `/jarvis-docs-index` | Se for necessário atualizar o índice de documentação |
-| Skills recomendados | `/eng-devops-performance-engineer` | Se a feature tiver requisitos não-funcionais de latência, throughput ou escalabilidade |
+| Skills recomendados | `/eng-platform` + `PLATFORM_SPECIALIZATIONS` | Se a feature tiver requisitos não-funcionais de latência, throughput ou escalabilidade |
 | Skills recomendados | `/eng-backend` e `/eng-frontend` (via `eng.specializations-rules.md`) | Para validar código de backend (endpoints, autenticação, workers) ou de frontend (componentes, performance de UI, WCAG 2.1 AA); a regra também carrega as especializações registradas no ENV.md |
-| Skills recomendados | `/eng-security-cybersecurity` | Se a branch tocar em auth, sessions, inputs, CORS, CSP, permissões ou adicionar dependências novas |
-| Fase 0.5: Comentário no card — Início | `/eng-global-task-comment` | Se `TASK_MANAGER` estiver preenchido (freelance pula) |
 | Gate 0: Verificar Documentação Central | `/jarvis-docs-central` (via `jarvis docs publish --tipo ard`) | Se `CENTRAL_DOCS_REPO` estiver configurado, houver mudança arquitetural, o ARD estiver desatualizado ou novo e o usuário aceitar publicar |
 | Gates › item 1 | `prod.pm-checker` (agente) | Sempre — verificar alinhamento da branch com os docs de produto e engenharia |
 | Gates › item 2 | `eng.dev-code-reviewer` (agente) | Sempre — revisar o código antes de lançar |
 | Gates › item 3 | `eng.qa.test-planner` (agente) | Sempre — identificar gaps de cobertura de testes na branch |
 | Gates › item 4 | `eng.qa.testing-engineer` (agente) | Se o test-planner identificar gaps críticos (escrever os testes faltantes) |
 | Gates › item 5 | `eng.qa.test-architect` (agente) | Se a feature tiver requisitos não-funcionais (no `architecture.md` ou explícitos na task) |
-| Gates › item 6 | `/eng-qa-testsprite` | Sempre — `testScope=diff`, com `type=frontend` e/ou `type=backend` conforme o projeto |
+| Gates › item 6 | `/eng-qa` + `QA_SPECIALIZATIONS` | Sempre — frontend e/ou backend conforme o projeto |
 | Gates › item 7 | `eng.frontend.agent` (agente) | Se a branch tiver mudanças de interface (componentes, estilos, estado) |
 | Gates › item 8 | `eng.ux-designer.agent` (agente) | Se a branch introduzir nova feature de UI ou alterar fluxo de usuário |
 | Gates › item 9 | `eng.docs-writer` (agente) | Sempre — atualizar a documentação do projeto |
-| Gates › item 10 | `/eng.security-review` | Se a branch tocar em auth, sessions, inputs de usuário, CORS, CSP, permissões ou adicionar endpoints públicos |
-| Comentário no card — Conclusão | `/eng-global-task-comment` | Se `TASK_MANAGER` estiver preenchido, com o status final (freelance pula) |
-
-## Fase 0.5: Comentário no card — Início
-
-Pular se `TASK_MANAGER` estiver vazio (freelance).
-
-Ao iniciar o pre-PR, registrar:
-
-```
-/eng-global-task-comment {TASK_MANAGER_KEY} 🔍 [Jarvis] Iniciando validação pre-PR - bateria de testes e revisão de código
-```
-
-> Usa o skill `/eng-global-task-comment`. Não bloquear se falhar.
-
----
+| Gates › item 10 | Nenhuma — checklist inline | Se a branch tocar em auth, sessions, inputs de usuário, CORS, CSP, permissões ou adicionar endpoints públicos |
+| Saída final › 2) Bloqueadores e pendências | `/eng-global-task-comment` | Só se a validação reprovar (status RED): um comentário com o motivo (freelance pula) |
 
 ## Regras de Execução
 
@@ -119,10 +99,7 @@ git diff main...HEAD | grep -E "(class|interface|schema|migration|config)" || tr
    - Testes de performance executados e dentro dos thresholds
    - Testes de segurança passando (RBAC, injection, etc.)
    - Quality gates configurados corretamente
-6. Execute o skill [eng-qa-testsprite]($IDE/skills/eng-qa-testsprite/SKILL.md) com `testScope=diff` para validar testes automatizados nas mudanças da branch.
-   - Se o projeto tiver frontend: execute com `type=frontend`
-   - Se o projeto tiver backend: execute com `type=backend`
-   - Se tiver ambos: execute os dois tipos sequencialmente
+6. Use a base [eng-qa]($IDE/skills/eng-qa/SKILL.md) (ou a especialização registrada em `QA_SPECIALIZATIONS`, se houver uma) para validar testes automatizados nas mudanças da branch, frontend e/ou backend conforme o projeto.
 7. **Se a branch tiver mudanças de interface** (componentes, estilos, estado), invoque o agente [eng.frontend.agent]($IDE/agents/engineering/eng.frontend.agent.md) para validar:
    - Tipagem forte (quando a linguagem tem), tokens de design do projeto usados, acessibilidade WCAG 2.1 AA
    - Aplicar as exigências das especializações de frontend registradas (ver `eng.specializations-rules.md`)
@@ -130,7 +107,7 @@ git diff main...HEAD | grep -E "(class|interface|schema|migration|config)" || tr
    - Empty states, loading states e mensagens de erro em linguagem humana
    - Consistência com padrões visuais existentes no produto
 9. Invoque o agente [eng.docs-writer]($IDE/agents/engineering/eng.docs-writer.md) para atualizar a documentação do projeto.
-10. **Se a branch tocar em auth, sessions, inputs de usuário, CORS, CSP, permissões ou adicionar endpoints públicos**, executar o workflow [eng.security-review]($IDE/workflows/engineering/eng.security-review.md) como gate de segurança:
+10. **Se a branch tocar em auth, sessions, inputs de usuário, CORS, CSP, permissões ou adicionar endpoints públicos**, aplicar o gate de segurança (os padrões de segurança da base [eng-backend]($IDE/skills/eng-backend/SKILL.md) + `BACKEND_SPECIALIZATIONS` / [eng-frontend]($IDE/skills/eng-frontend/SKILL.md) + `FRONTEND_SPECIALIZATIONS` e, para infraestrutura, do [eng-platform]($IDE/skills/eng-platform/SKILL.md) + `PLATFORM_SPECIALIZATIONS` servem de referência):
    - Revisar sanitização de inputs e queries parametrizadas
    - Verificar auth guards em endpoints novos
    - Validar headers de segurança e configurações de CORS
@@ -143,7 +120,7 @@ Você também precisará lidar com todo o feedback que esses agentes fornecerem
 ## Checklist final (obrigatório)
 
 - [ ] Não existem bloqueadores abertos (segurança/bugs críticos).
-- [ ] Testes e validações relevantes foram executados e passaram (com evidências via eng-qa-testsprite ou manual).
+- [ ] Testes e validações relevantes foram executados e passaram (com evidências automatizadas ou manuais).
 - [ ] Cobertura de testes para mudanças da branch foi avaliada (e gaps críticos tratados ou justificados).
 - [ ] Documentação foi revisada/atualizada (listar arquivos alterados) ou foi explicitado por que não foi necessário.
 - [ ] Riscos conhecidos e trade-offs foram registrados (e follow-ups criados quando aplicável).
@@ -158,6 +135,8 @@ Você também precisará lidar com todo o feedback que esses agentes fornecerem
 
 ### 2) Bloqueadores e pendências
 
+Se o status for **RED** (bloqueado), comente o bloqueio e o motivo no card com `/eng-global-task-comment` (freelance pula). GREEN e YELLOW não geram comentário.
+
 - Bloqueadores:
 - Pendências aceitas (com justificativa):
 - Follow-ups (links/IDs):
@@ -170,20 +149,4 @@ Você também precisará lidar com todo o feedback que esses agentes fornecerem
 - Docs atualizadas:
 - Riscos / trade-offs:
 
-## Comentário no card — Conclusão
-
-Pular se `TASK_MANAGER` estiver vazio (freelance).
-
-Após apresentar o resultado final, registrar:
-
-- Se **Green**: `✅ [Jarvis] Pre-PR concluído com status GREEN - pronto para abrir MR`
-- Se **Yellow**: `⚠️ [Jarvis] Pre-PR concluído com status YELLOW - pode abrir MR com ressalvas`
-- Se **Red**: `🚫 [Jarvis] Pre-PR concluído com status RED - bloqueadores encontrados, não abrir MR`
-
-```
-/eng-global-task-comment {TASK_MANAGER_KEY} {mensagem_status}
-```
-
----
-
 Uma vez terminado, me avise e peça minha permissão para abrir o Pull Request.