jarvis-ai-framework 2.1.1 → 3.2.0

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.
@@ -40,11 +38,11 @@ apontando riscos, gaps e melhorias, sempre respeitando `$IDE/rules/engineering/e
 
 | Passo | Skill | Condição |
 |-------|-------|----------|
-| Skills recomendados | `/eng-qa-test-plan` | Se a revisão envolver mudanças de código (revisar cobertura de testes da branch e gaps) |
+| 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 com TestSprite (opcional) | `/eng-qa-testsprite` | Se o projeto estiver rodando localmente (`/eng-qa-testsprite diff`) |
+| 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 |
@@ -157,19 +155,15 @@ O agente irá:
 - Identificar lacunas de cobertura
 - Gerar relatório com recomendações
 
-### Validação com TestSprite (opcional)
+### Validação automatizada (opcional)
 
-Se o projeto estiver rodando localmente, execute o skill **eng-qa-testsprite** para obter evidências de cobertura:
-
-```
-/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

@@ -23,8 +23,6 @@ Workflow unificado para criação (`new`) ou manutenção (`update`) de robôs d
 | 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` › Exploração do sistema-alvo | `/eng-scraper-robot-builder` | Se o fluxo for descrito em linguagem natural com seletores desconhecidos (com MAX=100: só se o MCP estiver indisponível) |
-| Modo `new` › Fase N1 — escolha da ferramenta do robô | `/eng-scraper-robot-builder` | Se o fluxo for descrito em linguagem natural e os seletores forem desconhecidos (Stagehand) |
 | 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` |
@@ -46,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.
 
 ---
@@ -100,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.
 
@@ -152,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.
 
@@ -266,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

@@ -26,17 +26,17 @@ Este comando inicia o **planejamento** de uma nova feature.
 |-------|-------|----------|
 | 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 0.5: Advisor (opcional) | `eng.advisor.agent` (agente) | Se o usuário escolher usar o Advisor no alerta e o `architecture.md` tiver questões em aberto (aberto só na primeira questão) |
 | 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-devops-performance-engineer` | Se a feature tiver requisitos de performance (latência, throughput, escalabilidade) |
-| Fase 3.4: Estratégia de Testes | `/eng-ai-engineer` | Se a feature envolver IA (LLM, RAG, agentes, chatbots, embeddings) |
+| 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-engineer` | Se a feature envolver engenharia de dados (pipelines ETL/ELT, Glue, Airflow, contratos de dados, camadas bronze/silver/gold) |
-| Fase 3.4: Estratégia de Testes | `/eng-scraper` | Se a feature envolver extração de dados ou scraping |
-| Fase 3.4: Estratégia de Testes | `/eng-security-cybersecurity` | Se a feature envolver autenticação, autorização, inputs de usuário, dados sensíveis ou endpoints públicos |
-| 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) |
+| 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 4.3: Questões em Aberto | `/eng-global-task-comment` | Se o Advisor foi usado e houve questões em aberto: **um** comentário de auditoria (freelance pula; o registro fica só no `architecture.md`) |
 
 ---
 
@@ -123,17 +123,13 @@ Se o usuário solicitar ajustes, re-execute com `--override`.
 
 ---
 
-## Fase 0.5: Comentário no card — Início
+## Fase 0.5: Advisor (opcional)
 
-Pular se `TASK_MANAGER` estiver vazio (freelance).
+Logo depois de obter o `TASK_MANAGER_KEY`, pergunte com `AskUserQuestion` (sem a ferramenta, use a tabela de `prod-rules.md`): **"Usar o Advisor nas questões em aberto desta tarefa?"** (**Não**, padrão / **Sim**). Com **Não**, siga como sempre e não mencione mais o Advisor.
 
-Após obter o `TASK_MANAGER_KEY`, registrar o início do planejamento:
+Com **Sim**, pergunte **"Qual modelo para o Advisor?"** com os itens de `ADVISOR_MODELS` do `ENV.md` (até 4 opções; o resto em "Outro"). Lista vazia ou ausente: use `Sonnet 5.5` sem perguntar; lista de um item: use-o sem perguntar. Traduza o nome pela família (primeira palavra em minúsculas: `sonnet`, `opus`, `fable`, `haiku`); se o modelo não for aceito pela IDE, use `sonnet` e avise em uma linha. Se a IDE não permitir escolher o modelo do subagente, avise e não faça a segunda pergunta.
 
-```
-/eng-global-task-comment {TASK_MANAGER_KEY} 🚀 [Jarvis] Iniciando planejamento - architecture.md sendo criado
-```
-
-> Usa o skill `/eng-global-task-comment` (MCP Atlassian → fallback curl). Não bloquear se falhar.
+Registre a escolha no cabeçalho do `architecture.md` (`Advisor:`). O agente `eng.advisor.agent` só é aberto na primeira questão em aberto (Fase 4.3).
 
 ---
 
@@ -312,12 +308,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
@@ -334,23 +330,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.
 
 ---
@@ -377,6 +378,18 @@ Preencha **TODAS** as seções com as informações coletadas nas fases anterior
 - Use nomes de classes/funções existentes
 - Referencie código encontrado na investigação
 
+### 4.3 Questões em Aberto
+
+Levante na seção 8 **tudo** que for diferente do código ou ambíguo no card, no formato do template (é aqui que as questões devem aparecer; levantá-las depois é exceção).
+
+**Com Advisor** (Fase 0.5), use os textos de `$IDE/templates/engineering/advisor-template.md`:
+1. Na primeira questão, abra `eng.advisor.agent` em segundo plano com o modelo escolhido e envie o **Prompt 1** (carga inicial). Se ele responder que precisa de ajuda para localizar o contexto, pergunte ao usuário com `AskUserQuestion` (opção "Não há documento: siga só com o card e o código") e reenvie.
+2. Envie cada questão com o **Prompt 2**, uma por mensagem, para a mesma instância.
+3. Preencha "Sugestão do Sub-Agent (Advisor)", **"Decisão adotada" (a sugestão do Advisor, que prevalece; não a substitua nem a conteste)**, "Divergência" e "Impacto da decisão". Confira no código os fatos em que a sugestão se apoia antes de registrar.
+4. Poste **um** comentário de auditoria na issue com `/eng-global-task-comment`, no modelo do template (freelance pula).
+
+**Sem Advisor:** apresente as questões ao usuário, como sempre.
+
 ---
 
 ## Fase 5: Revisão e Aprovação
@@ -398,23 +411,15 @@ Se o usuário tiver feedback:
 - Apresente novamente
 - Continue até aprovação explícita
 
+**Com Advisor**, o gate segue a autonomia do `context.md` (CDD): `alta` → apresente o resumo e siga para o `eng.plan` sem aguardar; `média` ou `baixa` → aguarde a aprovação explícita. Sem `context.md`, use a tabela "Autonomia por POSITION" de `eng-rules.md`. Sem Advisor, nada muda.
+
 ### 5.3 Atualizar Board
 
 Pular se `TASK_MANAGER` estiver vazio (freelance).
 
 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
-
-Pular se `TASK_MANAGER` estiver vazio (freelance).
-
-Registrar conclusão do planejamento:
-
-```
-/eng-global-task-comment {TASK_MANAGER_KEY} ✅ [Jarvis] Planejamento concluído - architecture.md criado. Branch: {NOME_DA_BRANCH}
-```
-
-### 5.5 Finalização
+### 5.4 Finalização
 
 Quando o usuário aprovar, informe:
 

package/workflows/engineering/eng.work.md

@@ -25,15 +25,15 @@ Este comando executa a **implementação de código** seguindo o plano de execu
 |-------|-------|----------|
 | Cabeçalho (agente) | `eng.agent` (agente) | Sempre — identidade do workflow |
 | Fase 0 › 0.1 Verificar ou Gerar Contexto da Sessão | `/jarvis-context-detect` | Se `ENABLE_CDD=true` e o `context.md` não existir (obrigatório antes da Fase 1) |
-| Fase 0.5: Comentário no card — Início | `/eng-global-task-comment` | Se `TASK_MANAGER` estiver preenchido (freelance pula) |
 | Fase 3 › 3.1 Implementar Código (skill de domínio) | `/eng-frontend` (via `eng.specializations-rules.md`) | Se o domínio da feature for frontend (componentes, UI, estado, estilos, bundle, a11y); a regra também carrega `FRONTEND_SPECIALIZATIONS` |
 | Fase 3 › 3.1 Implementar Código (skill de domínio) | `/eng-backend` (via `eng.specializations-rules.md`) | Se o domínio da feature for backend (endpoints, auth, workers, filas, cache, banco, integrações); a regra também carrega `BACKEND_SPECIALIZATIONS` |
-| Fase 3 › 3.1 Implementar Código (skill de domínio) | `/eng-scraper` | Se o domínio da feature for scraping, extração de dados, ETL ou parsing |
-| Fase 3 › 3.1 Implementar Código (skill de domínio) | `/eng-scraper-robot-builder` | Se a tarefa for converter um fluxo manual em Playwright via Stagehand, sem seletores conhecidos |
+| Fase 3 › 3.1 Implementar Código (skill de domínio) | `/eng-automation` (via `eng.specializations-rules.md`) | Se o domínio da feature for RPA, scraping, extração de dados, ETL ou parsing; a regra também carrega `AUTOMATION_SPECIALIZATIONS` |
+| Fase 3 › 3.1 Implementar Código (skill de domínio) | `/eng-platform` (via `eng.specializations-rules.md`) | Se o domínio da feature for infraestrutura (IaC, contêineres, CI/CD, observabilidade, SRE, custo); a regra também carrega `PLATFORM_SPECIALIZATIONS` |
 | Fase 3 › 3.3.1 Identificar Gaps de Teste | `eng.qa.test-planner` (agente) | Sempre, depois de implementar o código da fase |
 | Fase 3 › 3.3.2 Implementar Testes Faltantes (Opção A) | `eng.qa.testing-engineer` (agente) | Se o test-planner identificar gaps e a estratégia do `architecture.md` seção 6.5 indicar testes manuais (unitário/integração) |
-| Fase 3 › 3.3.2 Implementar Testes Faltantes (Opção B) | `/eng-qa-testsprite` | Se a estratégia do `architecture.md` seção 6.5 indicar TestSprite (`testScope=diff`) |
-| Fase 6 › 6.2 Se Todas as Fases Foram Concluídas | `/eng-global-task-comment` | Se `TASK_MANAGER` estiver preenchido e todas as fases estiverem concluídas (freelance pula) |
+| Fase 3 › 3.3.2 Implementar Testes Faltantes (Opção B) | `/eng-qa` | Se a estratégia do `architecture.md` seção 6.5 indicar uma especialização registrada em `QA_SPECIALIZATIONS` |
+| Fase 3 › 3.1 Implementar Código (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 5 › 5.4 e "Se houver bloqueio técnico" | `/eng-global-task-comment` | Se houver desvio do plano: mudança de direção, fase bloqueada ou questão nova consultada ao Advisor (freelance pula) |
 
 ---
 
@@ -152,20 +152,6 @@ Use as características do projeto detectadas:
 
 ---
 
-## Fase 0.5: Comentário no card — Início
-
-Pular se `TASK_MANAGER` estiver vazio (freelance).
-
-Antes de iniciar a implementação, registrar início:
-
-```
-/eng-global-task-comment {TASK_MANAGER_KEY} ⚙️ [Jarvis] Iniciando implementação - Fase {N} do plano
-```
-
-> Usa o skill `/eng-global-task-comment`. Não bloquear se falhar.
-
----
-
 ## Fase 1: Leitura da Sessão
 
 ### 1.1 Carregar Arquivos
@@ -232,8 +218,8 @@ Se o usuário tiver sugestões, ajuste o plano.
 |---------|-------------|-------|
 | Frontend | componentes, UI, estado, estilos, bundle, a11y | regra [eng.specializations-rules.md]($IDE/rules/engineering/eng.specializations-rules.md) (área frontend: `eng-frontend` + `FRONTEND_SPECIALIZATIONS`) |
 | Backend | endpoints, auth, workers, filas, cache, banco, integrações | regra [eng.specializations-rules.md]($IDE/rules/engineering/eng.specializations-rules.md) (área backend: `eng-backend` + `BACKEND_SPECIALIZATIONS`) |
-| Scraping | web scraping, Puppeteer, extração de dados, ETL, parsing | [eng-scraper]($IDE/skills/eng-scraper/SKILL.md) |
-| Robô / automação | converter fluxo manual em Playwright via Stagehand, sem seletores conhecidos | [eng-scraper-robot-builder]($IDE/skills/eng-scraper-robot-builder/SKILL.md) |
+| Automation (RPA & Web) | RPA, web scraping, Puppeteer, extração de dados, ETL, parsing | regra [eng.specializations-rules.md]($IDE/rules/engineering/eng.specializations-rules.md) (área automation: `eng-automation` + `AUTOMATION_SPECIALIZATIONS`) |
+| Platform (infra) | IaC, contêineres/orquestração, pipeline de CI/CD, observabilidade, SRE, custo de nuvem | regra [eng.specializations-rules.md]($IDE/rules/engineering/eng.specializations-rules.md) (área platform: `eng-platform` + `PLATFORM_SPECIALIZATIONS`) |
 
 Para cada tarefa da fase:
 
@@ -250,6 +236,8 @@ Para cada tarefa da fase:
    - Testes unitários para cada função/método
    - Cobrir casos de sucesso e erro
 
+**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.work`", 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.
+
 ### 3.2 Executar Validações Locais
 
 Após implementar:
@@ -291,25 +279,17 @@ Invoque o agente [eng.qa.testing-engineer]($IDE/agents/engineering/qa/eng.qa.tes
 - Seguir padrões de teste do projeto (Jest, Vitest, pytest, etc.)
 - Garantir cobertura mínima definida na estratégia
 
-**Opção B: Testes automatizados via TestSprite**
+**Opção B: Especialização registrada em QA_SPECIALIZATIONS**
 
-Se a estratégia de testes (definida pelo `test-architect` no `eng.start`) indicar uso de TestSprite, execute o skill [eng-qa-testsprite]($IDE/skills/eng-qa-testsprite/SKILL.md) com `testScope=diff`:
-
-- Gera testes automaticamente para o código implementado
-- Executa e valida cobertura
-- Suporta: E2E, API, integração, frontend, backend
-- Ideal para fluxos complexos ou quando velocidade é prioridade
+Se a estratégia de testes (definida pelo `test-architect` no `eng.start`) indicar uma ferramenta de geração/execução automatizada, use a especialização registrada em `QA_SPECIALIZATIONS` (via a base [eng-qa]($IDE/skills/eng-qa/SKILL.md)) para o escopo do diff da fase.
 
 **Quando usar cada opção:**
 
 | Cenário | Usar |
 |---------|------|
 | Testes unitários de funções/classes | testing-engineer |
-| Testes de API/endpoints | eng-qa-testsprite ou testing-engineer |
-| Testes E2E de fluxos de usuário | eng-qa-testsprite |
-| Testes de integração complexos | eng-qa-testsprite |
-| Projeto sem TestSprite configurado | testing-engineer |
-| Projeto sem TestSprite configurado | testing-engineer |
+| Fluxo com ferramenta automatizada já registrada em `QA_SPECIALIZATIONS` | a especialização registrada |
+| Sem especialização registrada | testing-engineer |
 
 > ⚠️ **Importante**: Consulte `architecture.md` seção 6.5 para ver qual abordagem foi definida pelo test-architect.
 
@@ -325,7 +305,7 @@ npm test # ou comando do projeto
 npm run test:coverage # se disponível
 ```
 
-> 💡 **Fluxo**: Implementa código → test-planner (gaps) → testing-engineer OU eng-qa-testsprite (implementa) → valida
+> 💡 **Fluxo**: Implementa código → test-planner (gaps) → testing-engineer OU especialização de `QA_SPECIALIZATIONS` (implementa) → valida
 
 ---
 
@@ -437,6 +417,8 @@ Atualize o `plan.md`:
 - **Atenção**: {ponto importante para próximas fases}
 ```
 
+Se o comentário registrar uma **mudança de direção** (desvio do plano), comente também no card com `/eng-global-task-comment`, dizendo o que mudou e por quê (freelance pula).
+
 ### 5.3 Commit da Fase (GitFlow)
 
 Após validação do usuário e atualização do `plan.md`, commitar a fase na branch atual:
@@ -502,12 +484,6 @@ Refs: TASK-123"
 
 ### 6.2 Se Todas as Fases Foram Concluídas
 
-**Comentário no card — Conclusão** (pular se freelance):
-
-```
-/eng-global-task-comment {TASK_MANAGER_KEY} ✅ [Jarvis] Implementação concluída - todas as {N} fases completadas. Commits realizados por fase.
-```
-
 ```
 🎉 TODAS AS FASES CONCLUÍDAS!
 
@@ -567,5 +543,6 @@ Refs: TASK-123"
 ### Se houver bloqueio técnico:
 
 → Documente no plan.md como `[Bloqueada 🚫]`
+→ Comente o bloqueio no card com `/eng-global-task-comment` (desvio do plano; freelance pula)
 → Explique o bloqueio ao usuário
 → Sugira alternativas se possível

package/workflows/engineering/qa/eng.qa-sprint-planning.md

@@ -82,7 +82,7 @@ Com base no risco e na capacidade mapeada na Fase 0:
 |-------|------------------|
 | Alto | QA obrigatório — não delegar a Champion |
 | Médio | QA preferencial; Champion se QA sobrecarregado |
-| Baixo | Champion ou delegar ao dev via eng-qa-dev-guide |
+| Baixo | Champion ou delegar ao dev, orientado pela base `eng-qa` + `QA_SPECIALIZATIONS` |
 
 **Detectar sobrecarga**: se demanda > capacidade total, sinalizar quais tasks ficam sem cobertura designada e sugerir redução de escopo nos itens de menor risco.
 

package/workflows/product/prod.spec.discovery.md

@@ -47,7 +47,7 @@ O comando e o agente seguem obrigatoriamente `$PROD_RULES` (`prod-rules.md`):
 | Passo 2 — Reconhecer o projeto | `/jarvis-docs-central` | Se `CENTRAL_DOCS_REPO` estiver configurado |
 | Passo 2 — Reconhecer o projeto | `/jarvis-context-detect` | Para calibrar a profundidade da entrevista |
 | Passo 2 — Reconhecer o projeto | `/eng-backend-arch-c4` | Só com a confirmação do usuário; o retorno é tratado como suposição a validar |
-| Passo 2 — Reconhecer o projeto | `/eng-security-cybersecurity` | Só com a confirmação do usuário; o retorno é tratado como suposição a validar |
+| Passo 2 — Reconhecer o projeto | `/eng-platform` + `PLATFORM_SPECIALIZATIONS` | Só com a confirmação do usuário; o retorno é tratado como suposição a validar |
 
 ## Passo 0 — Entender o que foi pedido
 
@@ -72,7 +72,7 @@ Antes de perguntar, consulte o que já existe:
 - O código e os últimos commits, quando ajudarem a embasar a viabilidade
 - `jarvis-docs-central`, se `CENTRAL_DOCS_REPO` estiver configurado
 - `jarvis-context-detect`, para calibrar a profundidade da entrevista
-- `eng-backend-arch-c4` e `eng-security-cybersecurity` são skills de engenharia: só consulte **com a confirmação do usuário**, e trate o retorno como **suposição a validar**, não como fato
+- `eng-backend-arch-c4` e `eng-platform` (+ `PLATFORM_SPECIALIZATIONS`) são skills de engenharia: só consulte **com a confirmação do usuário**, e trate o retorno como **suposição a validar**, não como fato
 
 ## Passo 3 — Criar o arquivo
 

package/workflows/warm-up.md

@@ -20,10 +20,10 @@ evitando leitura desnecessária de arquivos e economizando tokens.
 |-------|-------|----------|
 | Passo 0.5 › 2. Para cada tecnologia identificada | `context7` (MCP: `resolve-library-id`, `query-docs`) | Se houver variável de stack com valor no ENV.md (uma consulta por tecnologia identificada); sem variável de stack, pula silenciosamente |
 | Passo 2 — Sincronizar Documentação Central | `/jarvis-docs-central` | Se `CENTRAL_DOCS_REPO` estiver configurado no ENV.md (Modo 1: Buscar Docs, via Skill tool) |
-| Passo 4 › Menu TECH LEAD › opções A a K | `/eng.start`, `/eng.debug`, `/eng.create-ard`, `/eng.create-ard-from-code`, `/eng.create-rfc`, `/eng.build-tech-spec`, `/eng.review`, `/eng.docs`, `/eng.security-audit`, `/eng.security-review`, `/eng.security-incident` | Se `POSITION=TECH LEAD` e `AREA=ENGINEERING` (menu dedicado) e o usuário escolher uma das opções (cada opção chama o workflow correspondente, na ordem do menu e do roteamento do Passo 4; `Outro` não chama workflow) |
-| Passo 4 › Menu CTO › opções A a F | `/eng.security-audit`, `/eng.security-incident`, `/eng.review`, `/eng.create-ard`, `/eng.create-rfc`, `/eng.build-tech-spec` | Se `POSITION` for CTO ou equivalente (menu dedicado, para qualquer `AREA`) e o usuário escolher uma das opções (cada opção chama o workflow correspondente, na ordem do menu e do roteamento do Passo 4; `Outro` não chama workflow) |
-| Passo 4 › Menu ENGINEERING + DATA › opções A a F | `/data.new-pipeline`, `/eng-data-onboard`, `/eng-data-debug`, `/eng-data-bi`, `/eng-data-orchestrator`, `/data.contract` | Se `AREA=ENGINEERING` e `HUB=DATA` e o usuário escolher uma das opções (cada opção chama o workflow correspondente, na ordem do menu e do roteamento do Passo 4; `Outro` não chama workflow) |
-| Passo 4 › Menu ENGINEERING + QA › opções A a H | `/eng.qa-refinement-entry`, `/eng.qa-e2e-test-generation`, `/eng.qa-exploratory-session`, `/eng.qa-quality-gate-validation`, `/eng.qa-quality-report`, `/eng.qa-dev-quality-guide`, `/eng.qa-sprint-planning`, `/eng.qa-release-signoff` | Se `AREA=ENGINEERING` e (`HUB=QA` ou Quality Champion) e o usuário escolher uma das opções (cada opção chama o workflow correspondente, na ordem do menu e do roteamento do Passo 4; `Outro` não chama workflow) |
+| Passo 4 › Menu TECH LEAD › opções A a H | `/eng.start`, `/eng.debug`, `/eng.create-ard`, `/eng.create-ard-from-code`, `/eng.create-rfc`, `/eng.build-tech-spec`, `/eng.review`, `/eng.docs` | Se `POSITION=TECH LEAD` e `AREA=ENGINEERING` (menu dedicado) e o usuário escolher uma das opções (cada opção chama o workflow correspondente, na ordem do menu e do roteamento do Passo 4; `Outro` não chama workflow) |
+| Passo 4 › Menu CTO › opções A a D | `/eng.review`, `/eng.create-ard`, `/eng.create-rfc`, `/eng.build-tech-spec` | Se `POSITION` for CTO ou equivalente (menu dedicado, para qualquer `AREA`) e o usuário escolher uma das opções (cada opção chama o workflow correspondente, na ordem do menu e do roteamento do Passo 4; `Outro` não chama workflow) |
+| Passo 4 › Menu ENGINEERING + DATA › opções A a C | `/data.new-pipeline`, `/eng-data`, `/data.contract` | Se `AREA=ENGINEERING` e `HUB=DATA` e o usuário escolher uma das opções (cada opção chama o workflow correspondente, na ordem do menu e do roteamento do Passo 4; `Outro` não chama workflow) |
+| Passo 4 › Menu ENGINEERING + QA › opções A a C | `/eng.qa-refinement-entry`, `/eng.qa-sprint-planning`, `/eng.qa-release-signoff` | Se `AREA=ENGINEERING` e (`HUB=QA` ou Quality Champion) e o usuário escolher uma das opções (cada opção chama o workflow correspondente, na ordem do menu e do roteamento do Passo 4; `Outro` não chama workflow) |
 | Passo 4 › Menu ENGINEERING (qualquer HUB) › opções A a I | `/eng.start`, `/eng.debug`, `/eng.create-ard`, `/eng.create-ard-from-code`, `/eng.create-rfc`, `/eng.build-tech-spec`, `/eng.review`, `/eng.docs`, `/eng.rpa.robot` | Se `AREA=ENGINEERING` (qualquer HUB, sem menu mais específico) e o usuário escolher uma das opções (cada opção chama o workflow correspondente, na ordem do menu e do roteamento do Passo 4; `Outro` não chama workflow) |
 | Passo 4 › Menu PRODUCT › opções A a D | `/prod.spec.prd`, `/prod.spec.frd`, `/prod.spec.issue`, `/prod.spec.epic` | Se `AREA=PRODUCT` (ou `POSITION` PM/TPM/GPM em `AREA=ENGINEERING`) e o usuário escolher uma das opções (cada opção chama o workflow correspondente, na ordem do menu e do roteamento do Passo 4; `Outro` não chama workflow) |
 | Passo 4 › Menu genérico › opção B | `/eng.docs` | Se `AREA` não tiver menu próprio (menu genérico) e o usuário escolher a opção B (se existir; senão criar diretamente) |
@@ -279,12 +279,11 @@ O menu é determinado pelos valores de `POSITION`, `AREA` e `HUB` lidos do ENV.m
 ### Menu para POSITION=TECH LEAD (sobrepõe menu genérico de ENGINEERING)
 
 > ℹ️ Usar este menu quando `POSITION=TECH LEAD` e `AREA=ENGINEERING`.
-> O Tech Lead é responsável pelos gates de qualidade e segurança do time — workflows de segurança aparecem em destaque.
+> O Tech Lead é responsável pelos gates de qualidade do time.
 
 ```
 Como você quer continuar?
 
-── Engenharia ──────────────────────────────────────────────
 A: Iniciar sessão para codar (eng.start)
 B: Debug / Investigar problema (eng.debug)
 C: Criar ou iterar ARD (eng.create-ard)
@@ -293,11 +292,7 @@ E: Abrir ou iterar RFC (eng.create-rfc)
 F: Fazer tech spec (eng.build-tech-spec)
 G: Revisar código / PR (eng.review)
 H: Documentar (eng.docs)
-── Segurança ───────────────────────────────────────────────
-I: Auditar segurança do repositório (eng.security-audit)
-J: Revisar PR com foco em segurança (eng.security-review)
-K: Responder incidente de segurança (eng.security-incident)
-L: Outro
+I: Outro
 ```
 
 Roteamento:
@@ -309,40 +304,31 @@ Roteamento:
 - F → `$FLOWS_FOLDER/engineering/eng.build-tech-spec.md`
 - G → `$FLOWS_FOLDER/engineering/eng.review.md`
 - H → `$FLOWS_FOLDER/engineering/eng.docs.md`
-- I → `$FLOWS_FOLDER/engineering/eng.security-audit.md`
-- J → `$FLOWS_FOLDER/engineering/eng.security-review.md`
-- K → `$FLOWS_FOLDER/engineering/eng.security-incident.md`
-- L → perguntar e rotear dinamicamente
+- I → perguntar e rotear dinamicamente
 
 ---
 
 ### Menu para POSITION=CTO (sobrepõe AREA)
 
 > ℹ️ Usar este menu para qualquer `AREA` quando `POSITION` é equivalente a CTO.
-> Foco estratégico: segurança, arquitetura, risco e decisões de alto impacto — sem granularidade operacional.
+> Foco estratégico: arquitetura, risco e decisões de alto impacto — sem granularidade operacional.
 
 ```
 Como você quer continuar?
 
-── Segurança & Risco ────────────────────────────────────────
-A: Auditar segurança do repositório (eng.security-audit)
-B: Responder incidente de segurança (eng.security-incident)
-── Arquitetura & Estratégia ────────────────────────────────
-C: Revisar código / PR estratégico (eng.review)
-D: Criar ou iterar ARD (eng.create-ard)
-E: Abrir ou iterar RFC (eng.create-rfc)
-F: Fazer tech spec (eng.build-tech-spec)
-G: Outro
+A: Revisar código / PR estratégico (eng.review)
+B: Criar ou iterar ARD (eng.create-ard)
+C: Abrir ou iterar RFC (eng.create-rfc)
+D: Fazer tech spec (eng.build-tech-spec)
+E: Outro
 ```
 
 Roteamento:
-- A → `$FLOWS_FOLDER/engineering/eng.security-audit.md`
-- B → `$FLOWS_FOLDER/engineering/eng.security-incident.md`
-- C → `$FLOWS_FOLDER/engineering/eng.review.md`
-- D → `$FLOWS_FOLDER/engineering/eng.create-ard.md`
-- E → `$FLOWS_FOLDER/engineering/eng.create-rfc.md`
-- F → `$FLOWS_FOLDER/engineering/eng.build-tech-spec.md`
-- G → perguntar e rotear dinamicamente
+- A → `$FLOWS_FOLDER/engineering/eng.review.md`
+- B → `$FLOWS_FOLDER/engineering/eng.create-ard.md`
+- C → `$FLOWS_FOLDER/engineering/eng.create-rfc.md`
+- D → `$FLOWS_FOLDER/engineering/eng.build-tech-spec.md`
+- E → perguntar e rotear dinamicamente
 
 ---
 
@@ -354,22 +340,16 @@ Roteamento:
 Como você quer continuar?
 
 A: Criar pipeline novo (data.new-pipeline)
-B: Integrar fonte de dados nova (eng-data-onboard)
-C: Diagnosticar falha em pipeline (eng-data-debug)
-D: Dashboard ou query analítica (eng-data-bi)
-E: Criar ou depurar DAG / orquestração (eng-data-orchestrator)
-F: Criar contrato de dados (data.contract)
-G: Outro
+B: Trabalhar com dados — onboarding de fonte, debug, dashboard/BI ou orquestração (eng-data)
+C: Criar contrato de dados (data.contract)
+D: Outro
 ```
 
 Roteamento:
 - A → `$FLOWS_FOLDER/engineering/data/data.new-pipeline.md`
-- B → skill `eng-data-onboard`
-- C → skill `eng-data-debug`
-- D → skill `eng-data-bi`
-- E → skill `eng-data-orchestrator`
-- F → `$FLOWS_FOLDER/engineering/data/data.contract.md`
-- G → perguntar e rotear dinamicamente
+- B → skill `eng-data`
+- C → `$FLOWS_FOLDER/engineering/data/data.contract.md`
+- D → perguntar e rotear dinamicamente
 
 ---
 
@@ -389,26 +369,16 @@ Roteamento:
 Como você quer continuar?
 
 A: Mapear estratégia de testes para uma feature (qa.refinement-entry)
-B: Gerar testes E2E para uma feature (qa.e2e-test-generation)
-C: Sessão de teste exploratório (qa.exploratory-session)
-D: Validar quality gate de uma spec (eng.qa-quality-gate-validation)
-E: Gerar relatório de qualidade (qa.quality-report)
-F: Orientar dev sobre cobertura de testes (qa.dev-quality-guide)
-G: Planejar capacidade QA da sprint (qa.sprint-planning)
-H: Sign-off de release (qa.release-signoff)
-I: Outro
+B: Planejar capacidade QA da sprint (qa.sprint-planning)
+C: Sign-off de release (qa.release-signoff)
+D: Outro
 ```
 
 Roteamento:
 - A → `$FLOWS_FOLDER/engineering/qa/eng.qa-refinement-entry.md`
-- B → `$FLOWS_FOLDER/engineering/qa/eng.qa-e2e-test-generation.md`
-- C → `$FLOWS_FOLDER/engineering/qa/eng.qa-exploratory-session.md`
-- D → `$FLOWS_FOLDER/engineering/qa/eng.qa-quality-gate-validation.md`
-- E → `$FLOWS_FOLDER/engineering/qa/eng.qa-quality-report.md`
-- F → `$FLOWS_FOLDER/engineering/qa/eng.qa-dev-quality-guide.md`
-- G → `$FLOWS_FOLDER/engineering/qa/eng.qa-sprint-planning.md`
-- H → `$FLOWS_FOLDER/engineering/qa/eng.qa-release-signoff.md`
-- I → perguntar e rotear dinamicamente
+- B → `$FLOWS_FOLDER/engineering/qa/eng.qa-sprint-planning.md`
+- C → `$FLOWS_FOLDER/engineering/qa/eng.qa-release-signoff.md`
+- D → perguntar e rotear dinamicamente
 
 ---
 
@@ -479,8 +449,8 @@ Roteamento:
 
 | POSITION semântico | Ajuste no menu |
 |-------------------|----------------|
-| CTO e equivalentes | Menu estratégico com segurança em destaque — ver seção "Menu para POSITION=CTO" acima |
-| TECH LEAD em AREA=ENGINEERING | Menu completo de engenharia + workflows de segurança — ver seção "Menu para POSITION=TECH LEAD" acima |
+| CTO e equivalentes | Menu estratégico (arquitetura e risco) — ver seção "Menu para POSITION=CTO" acima |
+| TECH LEAD em AREA=ENGINEERING | Menu completo de engenharia — ver seção "Menu para POSITION=TECH LEAD" acima |
 | PM, TPM, GPM em AREA=ENGINEERING | Mostrar menu PRODUCT mesmo estando na área ENGINEERING |
 
 ---
@@ -565,4 +535,6 @@ Se `ENABLE_CDD=false` ou não definido, prossiga diretamente para o workflow.
 | 1.4 | Menu específico para `AREA=ENGINEERING` + `HUB=DATA`: pipeline novo, onboarding de fonte, debug, dashboard, contrato |
 | 1.5 | Opção de robô RPA no menu de ENGINEERING (skill técnica, sem squad dedicado) |
 | 1.6 | Menu específico para `POSITION=TECH LEAD`: engenharia completa + workflows de segurança em destaque; Menu para `POSITION=CTO`: foco estratégico em segurança, arquitetura e risco |
-| 1.7 | **Bugfix**: menus de POSITION movidos para antes dos menus de AREA — corrige TL recebendo menu genérico sem opções de segurança; bloco de precedência explícita no início do Passo 4 |
+| 1.7 | **Bugfix**: menus de POSITION movidos para antes dos menus de AREA — corrige TL recebendo menu genérico sem opções de segurança; bloco de precedência explícita no início do Passo 4 |
+| 1.8 | Removidas as opções de workflow de segurança dos menus de TECH LEAD e CTO (eng.security-audit/review/incident foram descontinuados — ver `skills/security-skills-deleted.md`) |
+| 1.9 | Menu de `HUB=DATA` consolidado: `eng-data-onboard`/`eng-data-debug`/`eng-data-bi`/`eng-data-orchestrator` foram descontinuados — virou uma única opção (`eng-data`, a base nova) — ver `skills/data-skills-deleted.md` |