jarvis-ai-framework 2.1.0 → 3.0.0

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

@@ -23,6 +23,13 @@ Além disso, quando houver campo `Versão` no RFC, aplicar obrigatoriamente:
 
 - `$IDE/rules/engineering/eng.bump-rules.md`
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Passo 0.6 – Buscar Documentação Relacionada no Central Docs | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_REPO` estiver definido no ENV.md |
+| Passo 7 – Publicar no Central Docs | `/jarvis-docs-central` (via `jarvis docs publish --tipo rfc`) | Se `CENTRAL_DOCS_REPO` estiver definido **e** o usuário aprovar o RFC e responder "Sim, publicar agora" |
+
 ---
 
 ## Passo 0 – Definir se é novo RFC ou iteração

package/workflows/engineering/eng.debug.md

@@ -27,7 +27,7 @@ sempre respeitando `$IDE/rules/engineering/eng-rules.md`.
 
 ### Rules
 - **`$IDE/rules/engineering/eng-rules.md`** — regras obrigatórias de engenharia
-  - Inclui: Correlation ID obrigatório, fluxo downstream de cards, rigor por contexto (CDD)
+  - Inclui: Correlation ID obrigatório, autonomia no card, rigor por contexto (CDD)
 
 ### Skills invocados durante o workflow
 
@@ -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 | `/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:
-
-```
-/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.docs.md

@@ -17,6 +17,15 @@ Quando a solicitação for diretamente sobre escrita/atualização de documenta
 
 Quando a solicitação for sobre organização/índice de documentação, use o skill `$IDE/skills/jarvis-docs-index/SKILL.md`.
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Skills recomendados | `/eng-global-docs-write` | Se a solicitação for diretamente sobre escrita ou atualização de documentação |
+| Skills recomendados | `/jarvis-docs-index` | Se a solicitação for sobre organização ou índice de documentação |
+| Passo 1 — Ativar o contexto de Engenharia | `eng.agent` (agente) | Sempre |
+| Passo 2 — Ativar o agente de documentação | `eng.docs-writer` (agente) | Sempre |
+
 O assistente deve:
 
 1. Ativar o contexto de Engenharia:

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

@@ -11,6 +11,13 @@ model_justification: Design arquitetural requer análise de codebase, padrões e
 
 Este é o comando para disparar o início do desenho de estrutura arquitetural para uma feature.
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Arquitetura (dicas) e Pesquisa | `context7` (MCP) | Se for necessário consultar melhores práticas ou a documentação de uma biblioteca; não adivinhar |
+| Pesquisa | `Perplexity` (MCP) | Se não houver certeza de como uma biblioteca específica funciona |
+
 ## Exame
 
 1. Passe pelos cards, pais e filhos se necessário, e construa um entendimento inicial do que precisa ser construído. Pense cuidadosamente sobre o que é solicitado, certifique-se de que entende exatamente:

package/workflows/engineering/eng.plan.md

@@ -2,7 +2,7 @@
 description: Planejamento de execução faseada para a feature
 auto_execution_mode: 3
 agent: "$IDE/agents/engineering/eng.agent.md"
-rules_file: "$IDE/rules/engineering/eng.plan-rules.md"
+rules_file: "$IDE/rules-on-demand/engineering/eng.plan-rules.md"
 template_file: "$IDE/templates/engineering/plan-template.md"
 recommended_model: claude-sonnet-4-20250514
 model_tier: high
@@ -13,6 +13,8 @@ model_justification: Planejamento detalhado requer decomposição de tarefas com
 
 Este workflow cria um **plano de execução detalhado e faseado** para implementar a feature de forma incremental.
 
+> 📋 **Rules**: `$IDE/rules-on-demand/engineering/eng.plan-rules.md` — **antes de começar, leia esse arquivo e siga-o**: ele não é carregado automaticamente no início da sessão.
+
 ---
 
 ## Argumentos
@@ -34,6 +36,17 @@ Antes de executar este workflow:
 
 > 📁 **Padrão de pasta**: `{TASK_MANAGER_KEY}` é o ID do card em **lowercase** (ex: `TASK-123` → `task-123`)
 
+### Skills invocados durante o 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
@@ -207,7 +220,7 @@ Após a validação do plano com o humano, informar:
 
 ## Regras Importantes
 
-- ⚠️ **Consulte** as regras completas em `$IDE/rules/engineering/eng.plan-rules.md`
+- ⚠️ **Consulte** as regras completas em `$IDE/rules-on-demand/engineering/eng.plan-rules.md`
 - ⏱️ **Fases de ~1 hora** - Não criar fases maiores
 - 🔄 **Incremental** - Cada fase deve entregar valor testável
 - 🗣️ **Validar** - Sempre confirmar o plano com o humano antes de prosseguir

package/workflows/engineering/eng.pr.md

@@ -2,7 +2,7 @@
 description: Criação de branch, commit e merge request (MR)
 auto_execution_mode: 3
 agent: "$IDE/agents/engineering/eng.agent.md"
-rules_file: "$IDE/rules/engineering/eng.pr-rules.md"
+rules_file: "$IDE/rules-on-demand/engineering/eng.pr-rules.md"
 template_file: "$IDE/templates/engineering/PR-template.md"
 recommended_model: claude-sonnet-4-20250514
 model_tier: medium
@@ -13,23 +13,19 @@ model_justification: Operações Git e preenchimento de templates são tarefas e
 
 Este comando cria a **branch, commita as alterações e abre um Merge Request**.
 
-> 📋 **Rules**: `$IDE/rules/engineering/eng.pr-rules.md`
+> 📋 **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`
 
 ## Skills recomendados
 
 - **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)
 
@@ -37,6 +33,20 @@ Este comando cria a **branch, commita as alterações e abre um Merge Request**.
   - Arquivo: `$IDE/agents/engineering/qa/eng.qa.test-planner.md`
   - Quando usar: Se houver dúvidas sobre cobertura de testes ou mudanças significativas.
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| 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-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 |
+| 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 | `jarvis vcs create-merge` (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) |
+
 ---
 
 ## Entrada
@@ -93,19 +103,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.
 
@@ -227,7 +225,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}" \
@@ -238,7 +236,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,13 +264,9 @@ Após MR criado com sucesso, registrar:
 
 Pular se `TASK_MANAGER` estiver vazio (freelance).
 
-> Consultar `$IDE/rules/engineering/eng.downstream-flow-rules.md` para regras completas de transição.
-
 ### 6.1 Mover Card
 
-De acordo com o fluxo downstream, após abertura do MR o **DEV** (`JUNIOR` / `PLENO` / `SENIOR` / `SPECIALIST`) move o card para **"Review de código"**.
-
-> O próximo passo (**Pronto para QA**) é responsabilidade do **TECH LEAD**, após merge ou revisão do MR.
+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
 

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

@@ -2,7 +2,7 @@
 description: Validação de segurança para realizar um pull request ou merge request
 auto_execution_mode: 3
 env_file: "@/ENV.md"
-rules_file: "$IDE/rules/engineering/eng.pre-pr-rules.md"
+rules_file: "$IDE/rules-on-demand/engineering/eng.pre-pr-rules.md"
 recommended_model: claude-sonnet-4-20250514
 model_tier: high
 model_justification: Revisão multi-agente requer coordenação, análise de código, validação de testes e verificação de conformidade
@@ -12,27 +12,48 @@ model_justification: Revisão multi-agente requer coordenação, análise de có
 
 Estamos nos aproximando de finalizar o trabalho nesta branch e nos preparar para um solicitação de integração. Agora, é hora de fazer verificações finais e limpezas para assegurar que estamos alinhados com nossos convenções e objetivos.
 
+> 📋 **Rules**: `$IDE/rules-on-demand/engineering/eng.pre-pr-rules.md` — **antes de começar, leia esse arquivo e siga-o**: ele não é carregado automaticamente no início da sessão.
+
 ## 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
 </arguments>
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| 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-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 |
+| 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` + `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 | Nenhuma — checklist inline | 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).
@@ -93,10 +114,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`)
@@ -104,7 +122,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
@@ -117,7 +135,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).

package/workflows/engineering/eng.review.md

@@ -16,10 +16,8 @@ apontando riscos, gaps e melhorias, sempre respeitando `$IDE/rules/engineering/e
 
 ## Skills recomendados
 
-- **eng-qa-test-plan**: para revisar cobertura de testes da branch e sugerir gaps (quando a revisão envolver mudanças de código).
-  - Arquivo: `$IDE/skills/eng-qa-test-plan/SKILL.md`
-- **eng-qa-testsprite**: para executar testes automatizados e validar cobertura real das mudanças.
-  - Arquivo: `$IDE/skills/eng-qa-testsprite/SKILL.md`
+- **eng-qa-planner**: para revisar cobertura de testes da branch e sugerir gaps (quando a revisão envolver mudanças de código) — 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`
 - **Skills de backend e frontend**: quando a revisão envolver código de backend (endpoints, autenticação, workers, banco de dados) ou de frontend (componentes, estado, estilos, performance de UI, acessibilidade), aplique a regra `$IDE/rules/engineering/eng.specializations-rules.md` para a área envolvida: ela carrega o skill base (`eng-backend` ou `eng-frontend`) e as especializações registradas no `ENV.md`.
   - Arquivo da regra: `$IDE/rules/engineering/eng.specializations-rules.md`
   - Para mudanças arquiteturais relevantes que exijam atualizar diagramas, use a especialização de arquitetura registrada em `BACKEND_SPECIALIZATIONS`, se houver; sem ela, descreva a mudança no próprio documento de arquitetura.
@@ -36,6 +34,19 @@ apontando riscos, gaps e melhorias, sempre respeitando `$IDE/rules/engineering/e
   - Arquivo: `$IDE/agents/engineering/eng.ux-designer.agent.md`
   - Quando usar: PR que introduz nova feature de UI ou altera fluxo de usuário existente.
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Skills recomendados | `/eng-qa-planner` | Se a revisão envolver mudanças de código **e** a especialização estiver registrada em `QA_SPECIALIZATIONS` |
+| Skills recomendados | `/eng-backend` (via `eng.specializations-rules.md`) | Se a revisão envolver código de backend (endpoints, autenticação, workers, banco de dados); a regra também carrega as especializações de `BACKEND_SPECIALIZATIONS` |
+| Skills recomendados | `/eng-frontend` (via `eng.specializations-rules.md`) | Se a revisão envolver código de frontend (componentes, estado, estilos, performance de UI, acessibilidade); a regra também carrega as especializações de `FRONTEND_SPECIALIZATIONS` |
+| Skills recomendados | `especialização de arquitetura registrada em BACKEND_SPECIALIZATIONS` | Se houver mudança arquitetural relevante que exija atualizar diagramas e existir essa especialização registrada; sem ela, descrever a mudança no documento de arquitetura |
+| Passo 6 › Validação automatizada (opcional) | `/eng-qa` + `QA_SPECIALIZATIONS` | Para obter evidências de cobertura das mudanças |
+| Passo 6 › Análise de Cobertura (opcional) | `eng.qa.test-planner` (agente) | Se a revisão identificar problemas de cobertura que exijam análise mais profunda |
+| Agentes recomendados | `eng.frontend.agent` (agente) | Se o PR tiver mudanças significativas de interface ou componentes |
+| Agentes recomendados | `eng.ux-designer.agent` (agente) | Se o PR introduzir nova feature de UI ou alterar fluxo de usuário existente |
+
 ---
 
 ## Passo 1 – Entender o objetivo da mudança
@@ -144,19 +155,15 @@ O agente irá:
 - Identificar lacunas de cobertura
 - Gerar relatório com recomendações
 
-### Validação com TestSprite (opcional)
-
-Se o projeto estiver rodando localmente, execute o skill **eng-qa-testsprite** para obter evidências de cobertura:
+### Validação automatizada (opcional)
 
-```
-/eng-qa-testsprite diff
-```
+Use a base [eng-qa](../../skills/eng-qa/SKILL.md) (ou a especialização registrada em `QA_SPECIALIZATIONS`, se houver uma) para obter evidências de cobertura.
 
 Inclua no parecer:
 
 - Resultado dos testes executados (passou/falhou)
 - Cobertura atingida vs. esperada
-- Gaps identificados pelo TestSprite
+- Gaps identificados
 
 ---
 

package/workflows/engineering/eng.rpa.robot.md

@@ -16,6 +16,20 @@ Workflow unificado para criação (`new`) ou manutenção (`update`) de robôs d
 > 📋 **Docs**: `$IDE/rules/engineering/eng.docs-scraping-rules.md`
 > 🤖 **Agente**: ARACHNE (`$IDE/agents/engineering/eng.rpa.agent.md`)
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Cabeçalho (agente) | `eng.rpa.agent` (agente) | Sempre — agente ARACHNE do workflow |
+| Fase 0 — Setup | `/jarvis-context-detect` | Se `ENABLE_CDD=true` no ENV.md |
+| Modo `new` › Exploração do sistema-alvo | `Playwright MCP` | Se o MCP Playwright estiver disponível na sessão (com `MAX_AI_EXECUTION_PERCENTAGE=100`, escolhido automaticamente; senão o dev escolhe a ferramenta) |
+| Modo `new` › Fase N2 — Plano de Execução | `/eng.plan` | Sempre no modo `new`, depois de o `architecture.md` ser aprovado |
+| Modo `new` › Fase N3 — Implementação | `/eng.work` | Sempre no modo `new`, depois do plano |
+| Modo `new` › Fase N4 — Documentação | `/jarvis-docs-index` | Sempre, após criar o `{robot-tag}-robot.md` |
+| Modo `new` › Fase N5 — Pre-PR e PR | `/eng.pre-pr` | Sempre no modo `new`, ao final da implementação |
+| Modo `new` › Fase N5 — Pre-PR e PR | `/eng.pr` | Sempre no modo `new`, depois do pre-PR |
+| Modo `update` › Fase U2 (se a mudança envolve o sistema-alvo) | `Playwright MCP` | Se o MCP Playwright estiver disponível na sessão |
+
 ---
 
 ## Entrada
@@ -30,14 +44,14 @@ Formato esperado: `new {TASK_MANAGER_KEY}` ou `update {TASK_MANAGER_KEY}`
 
 1. **Modo**: criar robô novo (`new`) ou atualizar/manter robô existente (`update`)?
 2. **Card**: qual o ID da tarefa no board? (ex: RPA-123)
-3. **[se `new`]** Qual o tag do serviço? (ex: `ba`, `sp`, `mg`) — será usado como `{robot-tag}`
+3. **[se `new`]** Qual o tag do serviço? (ex: `consulta-orgao`, `extrator-dados`) — será usado como `{robot-tag}`
 4. **[se `update`]** Qual robô será mantido? Listar opções:
    ```bash
    ls docs/engineering/robots/
    ```
    Apresentar a lista e pedir que o dev escolha.
 
-> O `{robot-tag}` é o nome do serviço do robô em kebab-case (ex: `ba` → `ba-robot.md`).
+> O `{robot-tag}` é o nome do serviço do robô em kebab-case (ex: `consulta-orgao` → `consulta-orgao-robot.md`).
 > Nunca usar nomes de sistemas externos hardcodados como tag.
 
 ---
@@ -84,14 +98,12 @@ echo "$(date -u +"%Y-%m-%dT%H:%M:%SZ")" > $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/.
 > |----------|-----------|
 > | MCP Playwright disponível na sessão | **Playwright MCP** — navega e inspeciona direto da IDE sem sair do contexto |
 > | Dev quer demonstrar o fluxo manualmente | **Playwright CLI** — `npx playwright codegen {url}` grava as interações e sugere seletores |
-> | Fluxo descrito em linguagem natural, seletores desconhecidos | **Stagehand** (`/eng-scraper-robot-builder`) — usa `observe()` para descobrir seletores via IA |
 >
 > **Escolha da ferramenta:**
 > - **Padrão** — perguntar ao dev qual ferramenta prefere usar para explorar o sistema-alvo
 > - **Se `MAX_AI_EXECUTION_PERCENTAGE=100`** — decidir automaticamente, sem perguntar:
 >   1. Playwright MCP disponível na sessão → usar MCP
->   2. MCP indisponível + fluxo descrito em linguagem natural → Stagehand
->   3. MCP indisponível + fluxo não descrito → Playwright CLI codegen
+>   2. MCP indisponível → Playwright CLI codegen
 >
 > O output de qualquer ferramenta é insumo para o `architecture.md` — não vai para produção diretamente.
 
@@ -136,7 +148,6 @@ Ordem de investigação:
 | Cheerio + axios | HTML estático sem JS relevante |
 | Puppeteer ou Playwright | Renderização JS obrigatória, sem API HTTP viável |
 | Puppeteer stealth | Anti-bot agressivo (Cloudflare, fingerprinting) |
-| `/eng-scraper-robot-builder` (Stagehand) | Fluxo descrito em linguagem natural, seletores desconhecidos |
 
 > ⚠️ **Captchas e proxies**: verificar se a infraestrutura anti-bot já existe no projeto (serviço de resolução de captcha, pool de proxies) — esses recursos são **pré-requisito compartilhado**, não devem ser implementados do zero por robô. Se não existirem, escalar para o TL antes de prosseguir.
 
@@ -250,7 +261,6 @@ Com base no card e no `{robot-tag}-robot.md`, identificar:
 |----------|-----------|
 | MCP Playwright disponível | **Playwright MCP** — inspecionar o estado atual do site |
 | Dev quer demonstrar o que mudou | **Playwright CLI** (`codegen`) |
-| Fluxo descrito em texto | **Stagehand** (`observe()`) |
 
 > A escolha segue a mesma regra do modo `new`: perguntar ao dev qual prefere, exceto se `MAX_AI_EXECUTION_PERCENTAGE=100` — nesse caso decidir automaticamente.
 

package/workflows/engineering/eng.start.md

@@ -2,7 +2,7 @@
 description: Inicia o planejamento de uma tarefa criando o architecture.md
 auto_execution_mode: 3
 agent: "$IDE/agents/engineering/eng.agent.md"
-rules_file: "$IDE/rules/engineering/eng.start-rules.md"
+rules_file: "$IDE/rules-on-demand/engineering/eng.start-rules.md"
 template_file: "$IDE/templates/engineering/architecture-template.md"
 recommended_model: claude-sonnet-4-20250514
 model_tier: high
@@ -13,13 +13,31 @@ model_justification: Requer análise arquitetural profunda, investigação de co
 
 Este comando inicia o **planejamento** de uma nova feature.
 
-> 📋 **Rules**: `$IDE/rules/engineering/eng.start-rules.md`
+> 📋 **Rules**: `$IDE/rules-on-demand/engineering/eng.start-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/architecture-template.md`
 
 > ⚠️ **IMPORTANTE**: Este workflow é APENAS para planejamento e documentação.
 > **NÃO execute código, NÃO crie arquivos de código, NÃO faça commits.**
 > O único artefato a ser criado é o `architecture.md`.
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Cabeçalho (agente) | `eng.agent` (agente) | Sempre — identidade do workflow |
+| Fase 0.1: Análise de Contexto (CDD) | `/jarvis-context-detect` | Se `ENABLE_CDD=true` no ENV.md (execução obrigatória antes da Fase 1); `ENABLE_CDD=false` pula |
+| Fase 0.5: Comentário no card — Início | `/eng-global-task-comment` | Se `TASK_MANAGER` estiver preenchido (freelance pula) |
+| Fase 2.2: Buscar Documentação Central | `/jarvis-docs-central` | Se `CENTRAL_DOCS_REPO` estiver configurado no ENV.md (buscar PRD, ARD e RFCs relacionados) |
+| Fase 3.4: Estratégia de Testes | `eng.qa.test-architect` (agente) | Se a feature tiver requisitos de performance ou segurança (APIs públicas, dados sensíveis, alta carga ou requisitos não-funcionais explícitos) |
+| Fase 3.4: Estratégia de Testes | `/eng-platform` | Se a feature tiver requisitos de performance (latência, throughput, escalabilidade) |
+| Fase 3.4: Estratégia de Testes | `/eng-ai` | Se a feature envolver IA (LLM, RAG, agentes, chatbots, embeddings) |
+| Fase 3.4: Estratégia de Testes | `/eng-frontend` (via `eng.specializations-rules.md`) | Se a feature envolver interface ou componentes frontend; a regra também carrega as especializações de `FRONTEND_SPECIALIZATIONS` |
+| Fase 3.4: Estratégia de Testes | `/eng-backend` (via `eng.specializations-rules.md`) | Se a feature envolver APIs, autenticação ou workers backend; a regra também carrega as especializações de `BACKEND_SPECIALIZATIONS` |
+| Fase 3.4: Estratégia de Testes | `/eng-data` (via `eng.specializations-rules.md`) | Se a feature envolver engenharia de dados (pipelines ETL/ELT, Glue, Airflow, contratos de dados, camadas bronze/silver/gold); a regra também carrega as especializações de `DATA_SPECIALIZATIONS` |
+| Fase 3.4: Estratégia de Testes | `/eng-automation` (via `eng.specializations-rules.md`) | Se a feature envolver RPA ou extração de dados/scraping; a regra também carrega as especializações de `AUTOMATION_SPECIALIZATIONS` |
+| Fase 3.4: Estratégia de Testes | `/eng-platform` (via `eng.specializations-rules.md`) | Se a feature envolver infraestrutura (IaC, contêineres, CI/CD, observabilidade, SRE, custo); a regra também carrega as especializações de `PLATFORM_SPECIALIZATIONS` |
+| Fase 5.4: Comentário no card — Conclusão | `/eng-global-task-comment` | Se `TASK_MANAGER` estiver preenchido, após o usuário aprovar o `architecture.md` (freelance pula) |
+
 ---
 
 ## Entrada
@@ -294,12 +312,12 @@ Documente:
 
 > ⚠️ **Quando executar**: Features que envolvam APIs públicas, processamento de dados sensíveis, alta carga esperada ou requisitos não-funcionais explícitos.
 
-**Se a feature tiver requisitos de performance** (latência, throughput, escalabilidade), use o skill [eng-devops-performance-engineer]($IDE/skills/eng-devops-performance-engineer/SKILL.md) para:
+**Se a feature tiver requisitos de performance** (latência, throughput, escalabilidade), use a base [eng-platform]($IDE/skills/eng-platform/SKILL.md) (temas 14 — Profiling, 15 — Testes de Carga e Chaos Engineering, 16 — Cache Multi-Camada) para:
 - Estabelecer baseline de métricas antes de implementar
 - Definir thresholds e SLIs/SLOs da feature
 - Planejar load tests com cenários realistas
 
-**Se a feature envolver IA** (LLM, RAG, agentes, chatbots, embeddings), use o skill [eng-ai-engineer]($IDE/skills/eng-ai-engineer/SKILL.md) para:
+**Se a feature envolver IA** (LLM, RAG, agentes, chatbots, embeddings), use o skill [eng-ai]($IDE/skills/eng-ai/SKILL.md) para:
 - Projetar a arquitetura de IA com fluxo de dados e seleção de modelo
 - Definir estratégias de cache, custo e guardrails de segurança
 - Planejar observabilidade e métricas de avaliação do sistema de IA
@@ -316,23 +334,28 @@ Documente:
 - Arquitetar workers, filas e integrações com retry/circuit breaker
 - Seguir o que cada especialização registrada pedir para a stack do projeto
 
-**Se a feature envolver engenharia de dados** (pipelines ETL/ELT, modelagem dimensional, ingestão em S3/Athena, jobs AWS Glue, DAGs Airflow, contratos de dados, Great Expectations, camadas bronze/silver/gold), use o skill [eng-data-engineer]($IDE/skills/eng-data-engineer/SKILL.md) para:
+**Se a feature envolver engenharia de dados** (pipelines ETL/ELT, modelagem dimensional, ingestão em S3/Athena, jobs AWS Glue, DAGs Airflow, contratos de dados, Great Expectations, camadas bronze/silver/gold), aplique a regra [eng.specializations-rules.md]($IDE/rules/engineering/eng.specializations-rules.md) para a área **data**: ela carrega o skill base [eng-data]($IDE/skills/eng-data/SKILL.md) mais as especializações registradas em `DATA_SPECIALIZATIONS`, e então:
 - Definir a arquitetura Medallion da feature (bronze → silver → gold)
 - Planejar Expectation Suite obrigatória e checks de qualidade
 - Documentar pipeline com `data-pipeline-template.md` antes de implementar
 - Garantir idempotência e nomenclatura padronizada
 
-**Se a feature envolver extração de dados ou scraping** (web scraping, Puppeteer, parsing, ETL), use o skill [eng-scraper]($IDE/skills/eng-scraper/SKILL.md) para:
+**Se a feature envolver RPA ou extração de dados** (web scraping, Puppeteer, parsing, ETL, automação de browser/fluxos de trabalho), aplique a regra [eng.specializations-rules.md]($IDE/rules/engineering/eng.specializations-rules.md) para a área **automation**: ela carrega o skill base [eng-automation]($IDE/skills/eng-automation/SKILL.md) mais as especializações registradas em `AUTOMATION_SPECIALIZATIONS`, e então:
 - Avaliar viabilidade ética e legal (robots.txt, ToS)
-- Definir ferramenta e arquitetura do scraper
+- Definir ferramenta e arquitetura do robô/scraper
 - Planejar resiliência, rate limiting e formato de saída
 
-**Se a feature envolver autenticação, autorização, inputs de usuário, dados sensíveis ou endpoints públicos**, use o skill [eng-security-cybersecurity]($IDE/skills/eng-security-cybersecurity/SKILL.md) para:
+**Se a feature envolver autenticação, autorização, inputs de usuário, dados sensíveis ou endpoints públicos**, use os padrões de segurança já embutidos na base de domínio ([eng-backend]($IDE/skills/eng-backend/SKILL.md) tema 10, [eng-frontend]($IDE/skills/eng-frontend/SKILL.md)) ou, para infraestrutura, no [eng-platform]($IDE/skills/eng-platform/SKILL.md) (temas 9 e 13), e então:
 - Mapear superfície de ataque e dados sensíveis (PII, financeiros)
 - Definir modelo de auth e RBAC adequado
 - Planejar estratégia de sanitização de inputs
 - Documentar vetores de risco na seção de segurança do `architecture.md`
 
+**Se a feature envolver infraestrutura** (provisionamento, IaC, contêineres/orquestração, pipeline de CI/CD, observabilidade, confiabilidade/SRE ou custo de nuvem), aplique a regra [eng.specializations-rules.md]($IDE/rules/engineering/eng.specializations-rules.md) para a área **platform**: ela carrega o skill base [eng-platform]($IDE/skills/eng-platform/SKILL.md) mais as especializações registradas em `PLATFORM_SPECIALIZATIONS`, e então:
+- Definir provedor, orquestrador e ferramenta de IaC a usar (ou já em uso no projeto)
+- Planejar observabilidade mínima (métricas, logs, traces) e SLO/SLI quando a mudança afetar confiabilidade
+- Estimar custo e revisar segurança de infraestrutura (menor privilégio, segredos) antes de provisionar
+
 Documente a estratégia de testes no `architecture.md` na seção apropriada.
 
 ---
@@ -382,11 +405,9 @@ Se o usuário tiver feedback:
 
 ### 5.3 Atualizar Board
 
-> Consultar `$IDE/rules/engineering/eng.downstream-flow-rules.md` para regras completas de transição.
-
-De acordo com o fluxo downstream, ao assumir este card o **DEV** (`JUNIOR` / `PLENO` / `SENIOR` / `SPECIALIST`) deve mover o card para **"Em progresso"**.
+Pular se `TASK_MANAGER` estiver vazio (freelance).
 
-> Este é o sinal de que a entrega está em andamento e o DEV assumiu a responsabilidade ponta-a-ponta.
+Se estiver preenchido, mova o card para a etapa equivalente a "em andamento" no seu board. Quem assumiu o card conduz a entrega; ninguém precisa liberar a transição.
 
 ### 5.4 Comentário no card — Conclusão