jarvis-ai-framework 2.1.1 → 3.2.0

package/agents/engineering/eng.agent.md

@@ -175,17 +175,13 @@ Para detecção automática de contexto de tarefas:
 - Uso: `/jarvis-context-detect [jira-key]` ou `/jarvis-context-detect --override tipo=hotfix`
 - Chamado automaticamente pelo workflow `eng.start`
 
-### eng-devops-performance-engineer
-Quando a tarefa envolver análise ou otimização de performance, observabilidade, gargalos, latência, load testing ou escalabilidade:
-- Arquivo: `$IDE/skills/eng-devops-performance-engineer/SKILL.md`
+### eng-platform (performance)
+Quando a tarefa envolver análise ou otimização de performance, observabilidade, gargalos, latência, load testing, chaos engineering ou cache multi-camada — temas 7, 14, 15 e 16 da base de platform:
+- Arquivo: `$IDE/skills/eng-platform/SKILL.md`
 
-### eng-ai-engineer
+### eng-ai
 Quando a tarefa envolver features com LLM, sistemas RAG, agentes de IA, chatbots, embeddings, busca vetorial ou integrações com modelos de IA:
-- Arquivo: `$IDE/skills/eng-ai-engineer/SKILL.md`
-
-### eng-global-browser-extension-builder
-Quando a tarefa envolver criação ou manutenção de extensões de navegador (Chrome, Firefox, Manifest V3, content scripts, popup UI):
-- Arquivo: `$IDE/skills/eng-global-browser-extension-builder/SKILL.md`
+- Arquivo: `$IDE/skills/eng-ai/SKILL.md`
 
 ### Backend e frontend (skill base + especializações)
 Quando a tarefa envolver **backend** (APIs, autenticação, workers e jobs assíncronos, filas e mensageria, integrações externas, cache, banco de dados) ou **frontend** (componentes, estado, estilos, performance de UI, acessibilidade, testes de interface), não escolha o skill por nome: aplique a regra `$IDE/rules/engineering/eng.specializations-rules.md` para a área envolvida. Ela carrega o skill base e as especializações que o projeto registrou no `ENV.md`:
@@ -194,26 +190,20 @@ Quando a tarefa envolver **backend** (APIs, autenticação, workers e jobs assí
 - Workflows relacionados: `eng.start` (arquitetura), `eng.work` (implementação), `eng.debug` (troubleshooting)
 - Para ver o que está instalado e registrado: `/jarvis-list-specializations`
 
-### eng-scraper
+### eng-automation
 Quando a tarefa envolver web scraping, extração de dados de páginas web, automação de browser com Puppeteer, parsing de HTML/XML/PDF, pipelines ETL leves ou monitoramento de mudanças em sites:
-- Arquivo: `$IDE/skills/eng-scraper/SKILL.md`
+- Arquivo: `$IDE/skills/eng-automation/SKILL.md`
 - Workflows relacionados: `eng.work` (implementação de scrapers)
 
-### eng-scraper-robot-builder
-Quando o produto ou dev descrever um fluxo manual em linguagem natural que precisa virar automação (robô), ou quando for necessário criar um script Playwright sem conhecer seletores do site. Usa Stagehand para exploração e `observe()` para descoberta de seletores — o output final é Playwright TypeScript puro, sem dependência de LLM em runtime:
-- Arquivo: `$IDE/skills/eng-scraper-robot-builder/SKILL.md`
-- Workflows relacionados: `eng.work` (criação de scripts de automação)
-
-### eng-qa-e2e
-Quando o QA precisar criar testes E2E de sistema em linguagem natural, validar fluxos completos de usuário ou gerar testes resilientes a mudanças de UI. Usa Stagehand — testes permanecem em linguagem natural (sem seletores hardcoded). Suporta exportação para Cypress quando necessário para CI/CD:
-- Arquivo: `$IDE/skills/eng-qa-e2e/SKILL.md`
+### eng-qa
+Quando precisar planejar estratégia de testes, validar fluxos completos de usuário ou cobrir testes E2E — base de QA, complementada pela especialização registrada em `QA_SPECIALIZATIONS`:
+- Arquivo: `$IDE/skills/eng-qa/SKILL.md`
 - Workflows relacionados: `eng.pr` (validação pré-PR), `eng.pre-pr` (cobertura de testes E2E)
 
-### eng-security-cybersecurity
-Quando a tarefa envolver segurança de aplicação, auditoria OWASP, secrets management, sanitização de inputs, headers de segurança (CSP, HSTS, CORS), supply chain (npm audit, lockfile), compliance (LGPD/GDPR) ou resposta a CVEs/incidentes de segurança:
-- Arquivo: `$IDE/skills/eng-security-cybersecurity/SKILL.md`
-- Agente dedicado: `$IDE/agents/engineering/eng.cybersecurity.agent.md` (SENTINEL) — para auditorias completas e incident response
-- Workflows relacionados: `eng.security-audit` (auditoria proativa), `eng.security-incident` (resposta a CVEs), `eng.security-review` (gate pré-merge)
+### eng-platform
+Quando a tarefa envolver segurança de infraestrutura, fundamentos de segurança da informação (risco, ameaças, identidade, resposta a incidente, GRC, privacidade) ou auditoria de dependências/supply chain — base de platform, complementada pela especialização registrada em `PLATFORM_SPECIALIZATIONS`:
+- Arquivo: `$IDE/skills/eng-platform/SKILL.md` (temas 9 e 13)
+- Segurança de código de aplicação (OWASP, inputs, auth) já é padrão embutido em `eng-backend`/`eng-frontend`
 
 ---
 

package/agents/engineering/eng.bug-hunter.md

@@ -191,18 +191,16 @@ CONTEXT_PROFILE:
   - Priorize:
     - `$IDE/workflows/engineering/eng.debug.md` (Resolution Mode)
     - `$IDE/workflows/engineering/eng.bug-audit.md` (Audit Mode)
-    - `$IDE/skills/eng-qa-bug-report/SKILL.md` (geração de relatórios)
+    - `$IDE/skills/eng-qa/SKILL.md` (estruturação de achados, tema 14 — Gestão de Testes e de Defeitos)
   - Não acione workflows de outros domínios sem autorização explícita do usuário
 
 ---
 
 ## Skills Disponíveis
 
-### eng-qa-bug-report
-Para geração de relatórios estruturados de bugs encontrados:
-- Arquivo: `$IDE/skills/eng-qa-bug-report/SKILL.md`
-- Uso: `/eng-qa-bug-report [modo] [argumentos]`
-- Integração com Jira para criação automática de cards
+### eng-qa
+Para estruturar os bugs encontrados (tema 14 — Gestão de Testes e de Defeitos) antes de abrir o card no `$TASK_MANAGER` do projeto — base de QA, complementada pela especialização registrada em `QA_SPECIALIZATIONS`:
+- Arquivo: `$IDE/skills/eng-qa/SKILL.md`
 
 ### jarvis-context-detect (CDD)
 Para detecção automática de contexto:
@@ -218,10 +216,9 @@ Para rastreamento automático de bugs em arquitetura de microsserviços, use a e
 - Mapeia cadeia de chamadas HTTP + AMQP, analisa contratos em cada boundary e rankeia hipóteses por risco
 - Sem a especialização registrada, siga a investigação cross-service manualmente
 
-### eng-security-cybersecurity
-Quando o bug tiver impacto de segurança (injection, auth bypass, data exposure), como referência na escalação ao SENTINEL:
-- Arquivo: `$IDE/skills/eng-security-cybersecurity/SKILL.md`
-- Agente dedicado: `$IDE/agents/engineering/eng.cybersecurity.agent.md` (SENTINEL)
+### eng-platform
+Quando o bug tiver impacto de segurança de infraestrutura (injection, auth bypass, data exposure), como referência — segurança de código de aplicação já é padrão embutido em `eng-backend`/`eng-frontend`:
+- Arquivo: `$IDE/skills/eng-platform/SKILL.md` (temas 9 e 13)
 
 ---
 
@@ -322,11 +319,6 @@ Quando o bug tiver impacto de segurança (injection, auth bypass, data exposure)
   - Valida qualidade da correção proposta
   - Garante aderência a padrões do projeto
 
-- **Com SENTINEL (eng.cybersecurity.agent)**
-  - Bugs com impacto de segurança (injection, auth bypass, data exposure) são escalados para SENTINEL
-  - SENTINEL classifica por severidade CVSS e coordena a resposta
-  - Skill de referência: `$IDE/skills/eng-security-cybersecurity/SKILL.md`
-
 ---
 
 ## Checklist de Qualidade

package/agents/engineering/eng.dev-code-reviewer.md

@@ -49,7 +49,7 @@ Para cada arquivo alterado, avalie:
  - Exposição de dados sensíveis (PII em logs, stack traces em produção)
  - Vulnerabilidades em dependências (npm audit)
  - Secrets hardcoded no código (tokens, senhas, API keys)
- - Se achados de segurança HIGH/CRITICAL: escalar para SENTINEL (`$IDE/agents/engineering/eng.cybersecurity.agent.md`) ou recomendar `/eng.security-review`
+ - Se achados de segurança HIGH/CRITICAL: bloquear o PR e pedir revisão humana de um tech lead antes do merge
 
 3. Revisão de Documentação
 Verifique se a documentação reflete as mudanças realizadas:

package/agents/engineering/eng.frontend.agent.md

@@ -57,13 +57,9 @@ Para criar ou refatorar componente, estado ou estilos, aplique a regra `eng.spec
 - Skill base: `$IDE/skills/eng-frontend/SKILL.md` + itens de `FRONTEND_SPECIALIZATIONS`
 - Auditoria de performance: seção Performance do `eng-frontend`
 
-### eng-qa-e2e
-Para testes E2E de fluxo de usuário:
-- Arquivo: `$IDE/skills/eng-qa-e2e/SKILL.md`
-
-### eng-qa-cypress-e2e
-Para testes Cypress (Page Objects, intercept):
-- Arquivo: `$IDE/skills/eng-qa-cypress-e2e/SKILL.md`
+### eng-qa
+Para testes E2E de fluxo de usuário — base de QA, complementada pela especialização registrada em `QA_SPECIALIZATIONS`:
+- Arquivo: `$IDE/skills/eng-qa/SKILL.md`
 
 ## Workflows e Agentes Relacionados
 

package/agents/engineering/eng.rpa.agent.md

@@ -98,16 +98,11 @@ CONTEXT_PROFILE:
 
 ## Skills Disponíveis
 
-### eng-scraper
+### eng-automation
 Para scraping, parsing HTML/XML/PDF, ETL leve, monitoramento de mudanças:
-- Arquivo: `$IDE/skills/eng-scraper/SKILL.md`
+- Arquivo: `$IDE/skills/eng-automation/SKILL.md`
 - Trigger: extração de dados de fontes web, headless browser, pipelines ETL
 
-### eng-scraper-robot-builder
-Para converter fluxo manual em robô Playwright via Stagehand:
-- Arquivo: `$IDE/skills/eng-scraper-robot-builder/SKILL.md`
-- Trigger: produto/dev descreveu passos manuais e quer automação, sem conhecer seletores
-
 ### Backend (skill base + especializações)
 Para filas, retry DLX, publicação e consumo de mensagens, workers, cron jobs e integrações externas com retry/circuit breaker, aplique a regra `$IDE/rules/engineering/eng.specializations-rules.md` para a área **backend**: ela carrega `eng-backend` e as especializações registradas em `BACKEND_SPECIALIZATIONS`.
 - Trigger: robô precisa publicar resultados em fila, consumir tarefas, implementar retry, ter um worker persistente, scheduler ou API de consumo dos dados extraídos
@@ -147,7 +142,6 @@ Para criar um robô novo ou manter um existente:
 |----------|-----------|
 | MCP Playwright disponível na sessão | **Playwright MCP** — navega e inspeciona direto da IDE |
 | Dev quer demonstrar o fluxo | **Playwright CLI** (`npx playwright codegen {url}`) |
-| Fluxo descrito em linguagem natural | **Stagehand** (`observe()`) via `/eng-scraper-robot-builder` |
 
 > Perguntar ao dev qual prefere. Só decidir automaticamente se `MAX_AI_EXECUTION_PERCENTAGE=100`.
 

package/agents/engineering/qa/eng.qa.quality-strategist.md

@@ -21,22 +21,17 @@ Você responde perguntas como:
 
 ## Skills Disponíveis
 
-### eng-qa-test-plan
+### eng-qa-planner
 Para planejar os testes de uma feature específica:
-- Arquivo: `$IDE/skills/eng-qa-test-plan/SKILL.md`
+- Arquivo: `$IDE/skills/eng-qa-planner/SKILL.md`
 
-### eng-qa-gate
-Para a análise de risco pré-release:
-- Arquivo: `$IDE/skills/eng-qa-gate/SKILL.md`
-
-### eng-qa-dev-guide
-Para features de médio risco: o QA orienta e o dev implementa os testes:
-- Arquivo: `$IDE/skills/eng-qa-dev-guide/SKILL.md`
+### eng-qa
+Para a análise de risco pré-release e para orientar o dev em features de médio risco — base de QA, complementada pela especialização registrada em `QA_SPECIALIZATIONS`:
+- Arquivo: `$IDE/skills/eng-qa/SKILL.md`
 
 ## Workflows e Agentes Relacionados
 
 - `eng.qa-refinement-entry` (workflow): entrada no refinamento de uma feature
-- `eng.qa-quality-report` (workflow): gerar o relatório de qualidade do período
 
 ---
 
@@ -72,7 +67,7 @@ Para times com alta proporção de devs por QA:
 | Fator | Estratégia |
 |-------|-----------|
 | Features de alto risco | QA conduz — prioridade máxima |
-| Features de médio risco | QA orienta via `eng-qa-dev-guide`, dev implementa testes |
+| Features de médio risco | QA orienta via a base `eng-qa` + `QA_SPECIALIZATIONS`, dev implementa testes |
 | Features de baixo risco | Dev responsável pela cobertura, QA revisa |
 | Bugs críticos | QA cobre com sessão exploratória após fix |
 

package/agents/engineering/qa/eng.qa.test-architect.md

@@ -81,23 +81,19 @@ Este agente foca em:
 **Para outros tipos de teste, use:**
 - `eng.qa.test-planner` → Análise de cobertura e identificação de gaps
 - `eng.qa.testing-engineer` → Escrita de testes unitários
-- `eng-qa-testsprite` → Execução automatizada E2E/API
+- `eng-qa` → Base de QA, incluindo E2E e automação (via especialização registrada em `QA_SPECIALIZATIONS`)
 
 ---
 
 ## Skills Disponíveis
 
-### eng-qa-testsprite
-Para execução automatizada E2E/API:
-- Arquivo: `$IDE/skills/eng-qa-testsprite/SKILL.md`
+### eng-qa
+Para execução automatizada E2E/API e padrões de testes unitários — base de QA, complementada pela especialização registrada em `QA_SPECIALIZATIONS`:
+- Arquivo: `$IDE/skills/eng-qa/SKILL.md`
 
-### eng-qa-test-plan
+### eng-qa-planner
 Para análise de cobertura:
-- Arquivo: `$IDE/skills/eng-qa-test-plan/SKILL.md`
-
-### eng-qa-unit-test
-Para padrões de testes unitários:
-- Arquivo: `$IDE/skills/eng-qa-unit-test/SKILL.md`
+- Arquivo: `$IDE/skills/eng-qa-planner/SKILL.md`
 
 ### jarvis-context-detect (CDD)
 Para detecção automatizada do contexto (calibração contextual do agente):
@@ -400,12 +396,6 @@ Dependendo da solicitação, gere:
 
 ---
 
-## Integração com TestSprite
-
-Para complementar com testes E2E automatizados:
-
-```bash
-/eng-qa-testsprite codebase
-```
+## Testes E2E automatizados
 
-O TestSprite gera scripts de teste automatizados e relatórios em `testsprite_tests/` que complementam a estratégia definida por este agente.
+Para complementar com testes E2E automatizados, use a especialização registrada em `QA_SPECIALIZATIONS` (via a base `eng-qa`) para o codebase, complementando a estratégia definida por este agente.

package/agents/engineering/qa/eng.qa.test-planner.md

@@ -20,7 +20,7 @@ Aplicar quando invocado via `eng.qa-refinement-entry` ou quando o argumento rece
 - Saída: `$DOCS_FOLDER/engineering/qa/strategies/{task-id}-test-strategy.md`
 
 **Modo B — Análise de Cobertura (pós-código)**
-Aplicar quando invocado via `eng-qa-unit-test`, `eng-qa-test-plan` ou quando houver código implementado na branch (git diff retorna resultados).
+Aplicar quando invocado via `eng-qa`, `eng-qa-planner` ou quando houver código implementado na branch (git diff retorna resultados).
 - Fonte de dados: `git diff origin/main...HEAD`
 - Saída: `$DOCS_FOLDER/engineering/qa/{task-id}-test_coverage_branch_report.md`
 
@@ -30,13 +30,13 @@ Regra de decisão: se `git diff origin/main...HEAD` retornar vazio, operar em Mo
 
 Use os recursos abaixo como fonte de verdade do processo:
 
-### eng-qa-test-plan
+### eng-qa-planner
 Para análise de cobertura e planejamento de testes:
-- Arquivo: `$IDE/skills/eng-qa-test-plan/SKILL.md`
+- Arquivo: `$IDE/skills/eng-qa-planner/SKILL.md`
 
-### eng-qa-testsprite
-Para execução automatizada de testes com TestSprite MCP:
-- Arquivo: `$IDE/skills/eng-qa-testsprite/SKILL.md`
+### eng-qa
+Para execução automatizada de testes — base de QA, complementada pela especialização registrada em `QA_SPECIALIZATIONS`:
+- Arquivo: `$IDE/skills/eng-qa/SKILL.md`
 
 ### jarvis-context-detect (CDD)
 Para detecção automatizada do contexto (calibração contextual do agente):
@@ -284,7 +284,7 @@ Regras de formato:
 
 ## Fluxo de Trabalho — Modo B (Análise de Cobertura pós-código)
 
-Usar quando: invocado via `eng-qa-unit-test` ou `eng-qa-test-plan`, ou quando git diff retornar resultados.
+Usar quando: invocado via `eng-qa` ou `eng-qa-planner`, ou quando git diff retornar resultados.
 
 ### B.1. Analisar Mudanças da Branch
 
@@ -342,13 +342,9 @@ Determine quais testes estão faltando:
 
 ---
 
-### B.5. Validar com TestSprite (Opcional)
+### B.5. Validar com Especialização Registrada (Opcional)
 
-Se o projeto estiver rodando localmente, sugira executar o skill **eng-qa-testsprite** para validação automatizada:
-
-```
-/eng-qa-testsprite diff
-```
+Se houver uma especialização de execução/geração automatizada registrada em `QA_SPECIALIZATIONS`, sugira usá-la (via a base `eng-qa`) para validação automatizada do diff.
 
 Isso permite:
 - Gerar testes automatizados para as mudanças
@@ -482,5 +478,5 @@ Fluxo completo recomendado:
 eng.qa.test-planner (análise)
     → eng.qa.testing-engineer (escrita)
     → eng.qa.test-architect (performance/security)
-    → eng-qa-testsprite (validação E2E)
+    → eng-qa (validação E2E, via especialização de QA_SPECIALIZATIONS)
 ```

package/agents/engineering/qa/eng.qa.testing-engineer.md

@@ -12,25 +12,13 @@ realmente funciona como pretendido — tanto testes unitários quanto E2E Cypres
 
 ## Skills Disponíveis
 
-### eng-qa-cypress-e2e
-Para gerar specs Cypress + TypeScript para fluxos de usuário:
-- Arquivo: `$IDE/skills/eng-qa-cypress-e2e/SKILL.md`
+### eng-qa
+Para gerar specs E2E, escrever testes unitários e orientar devs sobre cobertura — base de QA, complementada pela especialização registrada em `QA_SPECIALIZATIONS`:
+- Arquivo: `$IDE/skills/eng-qa/SKILL.md`
 
-### eng-qa-unit-test
-Para templates e padrões ao **escrever** testes unitários:
-- Arquivo: `$IDE/skills/eng-qa-unit-test/SKILL.md`
-
-### eng-qa-test-plan
+### eng-qa-planner
 Para **analisar** cobertura antes de escrever:
-- Arquivo: `$IDE/skills/eng-qa-test-plan/SKILL.md`
-
-### eng-qa-testsprite
-Para testes E2E/API em linguagem natural via Stagehand:
-- Arquivo: `$IDE/skills/eng-qa-testsprite/SKILL.md`
-
-### eng-qa-dev-guide
-Para orientar devs sobre cobertura sem escrever o teste:
-- Arquivo: `$IDE/skills/eng-qa-dev-guide/SKILL.md`
+- Arquivo: `$IDE/skills/eng-qa-planner/SKILL.md`
 
 ### jarvis-context-detect (CDD)
 Para detecção automatizada do contexto (calibração contextual do agente):
@@ -41,7 +29,90 @@ Para detecção automatizada do contexto (calibração contextual do agente):
 > Consultar `$RULES_FOLDER/engineering/qa/eng.qa.cypress-standards-rules.md` para convenções do projeto.
 >
 > **Testes unitários**: linguagem/framework nativo do projeto (TypeScript/Jest, Python/pytest, etc.)
-> O `eng-qa-testsprite` cobre E2E via Stagehand (linguagem natural) — complementa, não substitui Cypress.
+> A especialização de E2E registrada em `QA_SPECIALIZATIONS` (via a base `eng-qa`) complementa, não substitui Cypress.
+
+---
+
+## Cypress E2E — Domínio e Debugging
+
+> 🔒 **Fonte de verdade de convenções**: `$RULES_FOLDER/engineering/qa/eng.qa.cypress-standards-rules.md`
+> Sempre ler antes de sugerir padrões ou gerar código. Para **gerar** uma spec nova, use a especialização de Cypress registrada em `QA_SPECIALIZATIONS` (via a base `eng-qa`); esta seção cobre o julgamento por trás de revisar, debugar e manter specs existentes.
+
+### Domínios de Expertise
+
+#### Page Objects
+- Estrutura fluent (retorno `this`)
+- Organização por domínio vs. por página
+- Herança e composição entre Page Objects
+- Quando criar vs. quando estender um existente
+
+#### Custom Commands
+- Tipagem com TypeScript (`Cypress.Commands.add`)
+- Declaração em `support/index.d.ts`
+- Commands de autenticação via `cy.request` (não via UI)
+- Commands de setup de estado (seed de dados, limpeza)
+
+#### Fixtures e Intercepts
+- Estrutura de pastas de fixtures por domínio
+- Tipagem de fixtures com tipos do projeto (`cy.fixture<T>`)
+- Padrões de `cy.intercept` para REST e GraphQL
+- Gestão de aliases e `cy.wait`
+- Estratégia de intercept para diferentes cenários (sucesso, erro, timeout)
+
+#### Viewport e Responsividade
+- `cy.viewport()` para testes multi-device
+- Breakpoints a cobrir conforme o projeto
+- Configuração em `cypress.config.ts`
+
+#### Configuração e CI
+- `cypress.config.ts` — baseUrl, env, retries, video
+- Estratégia de retries para flakiness (retry ≠ resolver o problema)
+- Paralelização com Cypress Cloud ou via CI nativo
+- Variáveis de ambiente seguras (`Cypress.env()` vs. hardcode)
+- Artefatos de CI: screenshots, vídeos, relatórios
+
+### Debugging de Testes Flaky
+
+Causas comuns e soluções:
+
+| Causa | Sintoma | Solução |
+|-------|---------|---------|
+| Race condition | Teste falha 1 em 5 vezes | Usar `cy.wait('@alias')` em vez de `cy.wait(ms)` |
+| Estado compartilhado | Teste passa isolado, falha em suite | `beforeEach` garante estado limpo |
+| Animação/transição | Clique em elemento não dispara | `.should('be.visible')` antes de `.click()` |
+| Dados dinâmicos | Assertion em texto que muda | Usar `contain` em vez de `eq`, ou mockar dado |
+| API real | Falha intermitente por timeout | Interceptar sempre — nunca depender de API real |
+| Seletor frágil | Falha após deploy de UI | Migrar para `data-testid` |
+
+### Para Debugging de Spec Cypress
+
+1. Perguntar: o teste falha sempre ou às vezes? (determina se é flaky ou quebrado)
+2. Pedir o erro e o trecho de código relevante
+3. Identificar a causa raiz antes de sugerir solução
+4. Nunca recomendar aumentar retry como solução definitiva
+
+### Para Revisão de Spec Cypress
+
+Ler a spec fornecida e verificar:
+- Seletores: algum usando classe/id? → migrar para `data-testid`
+- Intercepts: alguma API não interceptada? → adicionar
+- Dependência entre testes: algum `it` depende de outro? → corrigir
+- `cy.wait(ms)` hardcoded? → substituir por alias
+- Page Object ausente? → criar ou indicar onde adicionar
+
+### Regras Específicas de Cypress
+
+**Nunca**
+- Sugerir `cy.wait({número})` como solução — identificar a causa real da espera
+- Aceitar seletores por classe CSS em specs novas
+- Recomendar retry como fix de flakiness — é um paliativo, não solução
+- Ignorar tipagem TypeScript — fixtures, commands e Page Objects devem ser tipados
+
+**Sempre**
+- Ler `eng.qa.cypress-standards-rules.md` antes de qualquer sugestão de padrão
+- Justificar por que uma prática é ruim antes de sugerir a alternativa
+- Verificar se já existe Page Object/command para o domínio antes de criar novo
+- Considerar manutenibilidade: um teste bom é um teste que não falha sem razão
 
 ---
 
@@ -302,13 +373,9 @@ pytest test_filename.py -v
 
 ---
 
-## Validação com TestSprite (Opcional)
-
-Após escrever os testes, sugira executar o skill **eng-qa-testsprite** para validação automatizada E2E:
+## Validação Automatizada E2E (Opcional)
 
-```bash
-/eng-qa-testsprite diff
-```
+Após escrever os testes, se houver uma especialização de execução automatizada registrada em `QA_SPECIALIZATIONS`, sugira usá-la (via a base `eng-qa`) para validação E2E do diff.
 
 Isso complementa os testes unitários com:
 - Testes E2E (frontend) ou API (backend)

package/agents/product/prod.discovery-interviewer.md

@@ -89,9 +89,9 @@ Para consultar a arquitetura atual:
 - Arquivo: `$IDE/skills/eng-backend-arch-c4/SKILL.md`
 - Confiança: só com a confirmação do usuário (skill de engenharia: pergunte antes de consultá-la; o que ela retornar entra no discovery como **suposição a validar**, não como fato)
 
-### eng-security-cybersecurity
-Para quando a ideia envolve autenticação, dados pessoais ou fluxo financeiro:
-- Arquivo: `$IDE/skills/eng-security-cybersecurity/SKILL.md`
+### eng-platform
+Para quando a ideia envolve infraestrutura, dados pessoais ou fluxo financeiro com risco de segurança/privacidade:
+- Arquivo: `$IDE/skills/eng-platform/SKILL.md` (temas 9 e 13)
 - Confiança: só com a confirmação do usuário (skill de engenharia: pergunte antes de consultá-la; o que ela retornar entra no discovery como **suposição a validar**, não como fato)
 
 ## Restrições

package/bin/README.md

@@ -0,0 +1,142 @@
+# bin/ — CLI `jarvis`
+
+Fonte do binário `jarvis` (instalado via `npm install -g jarvis-ai-framework`, entrypoint declarado em `package.json#bin`). Este README documenta a arquitetura para quem for adicionar, remover ou alterar um comando.
+
+## Estrutura
+
+```
+bin/
+├── jarvis.js                  # Entrypoint (shebang). ~10 linhas, não cresce.
+├── postinstall.js             # Roda no `npm install` (sincroniza assets se já havia .{ide}/ no cwd)
+├── commands/                  # Um arquivo por comando. Lógica pura, zero commander.
+│   ├── init.js, list.js, info.js, whoami.js, ...
+│   ├── docs-sync.js, docs-publish.js
+│   └── qa-signoff.js, install-rtk.js, tokens.js, map.js
+└── lib/
+    ├── cli/
+    │   ├── program.js         # Único lugar que monta o commander — ver "Arquitetura"
+    │   └── shared-options.js  # .option() repetidos entre comandos (--ide, --quiet, etc.)
+    ├── vcs/                   # Adapters de Git host (GitLab/GitHub/Bitbucket)
+    │   ├── api.js             # Lógica HTTP real (createIssue, createMergeRequest, fetchRawFile)
+    │   ├── create-merge.js, create-issue.js, fetch-raw.js   # função exportada + CLI direto (ver abaixo)
+    ├── tasks/
+    │   └── comment.js         # Adapter de task manager (jira/linear/github/asana) — mesmo padrão
+    ├── config/                # ide-config.js (fonte de verdade de IDEs), constants.js
+    ├── core/                  # scanner.js, sync-engine.js, profile-filter.js, token-report.js
+    ├── docs/                  # central-docs: fetch/publish + validação de frontmatter
+    │   ├── validate-frontmatter.js  # Valida/extrai frontmatter de PRD/FRD/ARD/RFC
+    │   ├── redis-cache.js      # Cache best-effort via `redis-cli` (get/setex/del)
+    │   ├── fetch-file.js       # fetchFile() — usado por `docs sync`/`docs fetch` e por publish-file.js
+    │   └── publish-file.js     # publishFile() — usado por `docs publish`
+    ├── utils/                 # logger.js, ui.js, paths.js, frontmatter.js, git-parser.js, npmrc-parser.js
+    ├── flow-map/              # `jarvis map` — grafo de chamadas entre workflows/skills/agents
+    ├── auth/                  # session.js (auth.json legado, hoje só `jarvis logout` o lê)
+    └── env-loader.js          # Resolve e lê o ENV.md ($IDE/ENV.md)
+```
+
+## Arquitetura: 3 camadas, cada uma com uma responsabilidade
+
+```
+bin/jarvis.js              →  entrypoint: cria o program e faz parseAsync(argv)
+  ↓
+bin/lib/cli/program.js     →  ÚNICO lugar que sabe que existe commander
+  ↓ (chama, já com o `flags` remontado)
+bin/commands/*.js          →  lógica de negócio pura: async (flags) => {...}
+```
+
+**Por que separar assim?** `bin/commands/*.js` nunca importa `commander` nem sabe o que é um `Command`. Cada arquivo só recebe um objeto `flags` e faz o que precisa. Isso significa:
+- Testar a lógica de um comando não exige simular argv/commander — chama a função direto com um objeto.
+- Trocar de biblioteca de CLI um dia (se um dia fizer sentido) significa reescrever só `program.js`, não os 10 arquivos de comando.
+- `program.js` é o **mapa completo** do CLI: para saber todo comando que existe, todas as flags que cada um aceita, é o único arquivo que precisa abrir.
+
+## O adapter: commander → formato antigo de `flags`
+
+O commander entrega ao `.action()` as opções em **camelCase** (`--env-file` → `options.envFile`, `--max-age` → `options.maxAge`) e cada positional como seu próprio parâmetro. As funções em `bin/commands/*.js` foram escritas para um objeto `flags` no formato que o parser manual antigo produzia: chaves com hífen literal (`flags["env-file"]`) e um array `flags._` para positionals.
+
+Em vez de reescrever as 10 funções para o formato novo (risco maior, mexe em lógica que já funciona), `program.js` tem uma função `toLegacyFlags(options, extra)` que remonta o objeto no formato antigo antes de cada chamada:
+
+```js
+// bin/lib/cli/program.js
+const whoamiCmd = cmd(program, "whoami").description("...");
+withEnvOptions(withLogOptions(whoamiCmd)).action((options) => whoami(toLegacyFlags(options)));
+```
+
+`toLegacyFlags` remapeia só as duas chaves que mudam de formato (`envFile`→`"env-file"`, `maxAge`→`"max-age"`); todo o resto passa direto. O `extra` (segundo argumento) serve para injetar positionals como `_` ou flags sintéticas como `{ logout: true }` (usado por `jarvis logout`, que chama a mesma função de `whoami.js` com essa flag).
+
+**Ao adicionar uma opção nova que usa hífen** (ex: `--body-file`), decida: se a função de `bin/commands/*.js` vai ler `flags["body-file"]` (formato antigo) ou se você vai atualizá-la para ler `options.bodyFile` direto. Os 4 comandos novos (`vcs create-merge`, `vcs create-issue`, etc.) já usam o segundo caminho — passam o objeto de opções do commander quase direto, sem o adapter — porque não têm lógica legada para preservar.
+
+## O helper `cmd()` — por que todo comando passa por ele
+
+```js
+function cmd(parent, name) {
+  return parent.command(name).allowUnknownOption().allowExcessArguments();
+}
+```
+
+O parser manual antigo nunca validava nada: qualquer `--flag` era aceito e ignorado silenciosamente se o comando não o lesse. O commander, por padrão, dá erro em flag não declarada e em positional excedente. `allowUnknownOption()`/`allowExcessArguments()` replicam a permissividade antiga — mas **o commander não propaga essas duas configs do comando pai para os subcomandos**: setar só no `program` raiz não é suficiente (testado e confirmado durante a implementação). Por isso `cmd()` existe e **todo** comando — incluindo os aninhados (`docs sync`, `vcs create-merge`) — é criado com ele, nunca com `.command()` direto.
+
+## Argumentos: `[opcional]`, não `<obrigatório>` — de propósito
+
+Note que `info`, `vcs fetch-raw` e `tasks comment` declaram seus positionals como **opcionais** (`[target]`, `[file-path]`) mesmo sendo, na prática, obrigatórios para o comando funcionar. Isso é deliberado: se o commander validar "argumento obrigatório ausente" sozinho, ele intercepta **antes** da função rodar — e cada uma dessas funções já tem sua própria validação com mensagem de uso customizada e mais específica (`info.js`: `"❌ Uso incorreto\nUso: jarvis info <type/name>\nExemplo: ..."`). Deixar o positional opcional no commander e a validação dentro da função preserva essa mensagem.
+
+**A mesma regra vale para `--flag` que já tem validação própria.** Nenhum comando aqui usa `.requiredOption()` ou `.choices()` do commander, mesmo quando faria sentido à primeira vista (ex: `--tipo` em `docs publish` só aceita `prd|frd|ard|rfc|swagger|qa-report`). `docsPublish.js` já valida isso e mostra um bloco de exemplos de uso bem mais rico que o que o commander mostraria. Usar `.choices()` ali faria o commander interceptar o valor errado com uma mensagem genérica, perdendo esse texto. **Ao adicionar uma opção nova**: se a função já vai validar o valor por dentro, deixe o commander permissivo (`.option()` simples) e confie na validação interna. Se não há validação nenhuma hoje, `.choices()`/`.argParser()` são bons lugares para adicionar uma — não há essa perda a proteger.
+
+## `program.command()` vs `program.addCommand()`
+
+Este código usa `.command(nome)` (que cria e já anexa o subcomando) em todo lugar — não `.addCommand(instanciaDeCommand)`. São equivalentes; `.addCommand()` só compensa quando o `Command` é montado em outro módulo e precisa ser importado antes de anexar. Como tudo mora em `program.js`, não há motivo para o nível extra de indireção.
+
+## Os 4 "scripts standalone" (`vcs/*.js`, `tasks/comment.js`): dupla forma
+
+`create-merge.js`, `create-issue.js`, `fetch-raw.js` e `comment.js` são chamados de duas formas:
+
+1. **Como subcomando do CLI**: `jarvis vcs create-merge --source ... --target ...` (via `program.js`)
+2. **Direto, por skills/workflows que ainda shell-am pra eles**: `node bin/lib/vcs/create-merge.js --source ...`
+
+Cada um dos 4 arquivos segue o mesmo padrão: exporta uma função (`runCreateMerge`, `runCreateIssue`, `runFetchRaw`, `runComment`) com a lógica, e termina com um guard que só lê `process.argv` quando o arquivo é executado diretamente:
+
+```js
+// Compatibilidade: continua funcionando como `node bin/lib/vcs/create-merge.js --source ...`
+if (fileURLToPath(import.meta.url) === process.argv[1]) {
+  await runCreateMerge({ source: arg("source"), ... });
+}
+```
+
+**Ao editar um desses 4 arquivos**: a lógica de negócio fica dentro da função exportada. O bloco de `arg()`/guard no final é só para quem ainda invoca via `node bin/lib/.../arquivo.js` direto (uso legado — todo caller novo deve preferir o subcomando `jarvis`). Não remova o guard sem primeiro confirmar que nenhuma skill/workflow ainda referencia o path direto (`grep -rn "bin/lib/vcs\|bin/lib/tasks/comment" --include="*.md" .`).
+
+## Como adicionar um comando novo
+
+1. Criar `bin/commands/meu-comando.js` exportando `export async function meuComando(flags) { ... }` — igual aos outros, sem importar `commander`.
+2. Em `bin/lib/cli/program.js`:
+   - Importar a função no topo.
+   - Registrar com `cmd(program, "meu-comando")` (ou `cmd(parentExistente, "nome")` se for subcomando de um grupo como `docs`/`vcs`/`tasks`).
+   - Declarar as opções/positionals com `.option()`/`.argument()`. Usar `withEnvOptions()`/`withLogOptions()` de `shared-options.js` se o comando precisar de `--ide`/`--env-file` ou `--quiet`/`--verbose`/`--silent`.
+   - No `.action()`, chamar `toLegacyFlags(options, extra)` se a função usa o formato antigo de flags, ou passar `options` quase direto se for um comando novo sem lógica legada (ver os 4 de `vcs`/`tasks` como exemplo).
+3. Rodar manualmente o comando novo e **todos os outros** (não há suíte automatizada de CLI end-to-end — só `test/comandos-docs.test.js`, que valida a documentação dos workflows/skills, não o comportamento do CLI em si). Checklist mínimo: `--help` do comando novo, caminho feliz, caminho de erro (flag/argumento faltando).
+4. `npm run lint && npm run test:comandos && npm run test:filtro` antes de comitar.
+
+## Variáveis de ambiente lidas diretamente (fora do ENV.md)
+
+`bin/lib/tasks/comment.js` e `bin/lib/vcs/*.js` leem `process.env` direto (`TASK_MANAGER`, `TOKEN_TASK_MANAGER`, `CENTRAL_DOCS_REPO`, `VERSION_CONTROL`, etc.) — não passam pelo `env-loader.js`/ENV.md. Isso é intencional: esses adapters são chamados por skills/workflows que já exportam essas variáveis do `ENV.md` para o processo (`set -a; eval "$(grep ... $IDE/ENV.md)"; set +a`) antes de invocar o comando. Se um comando novo precisar ler o `ENV.md` diretamente, use `env-loader.js#resolveEnvPath`/`loadEnv` (ver `whoami.js`, `tokens.js`, `qa-signoff.js` como exemplo) em vez de `process.env`.
+
+## Testes
+
+- `npm run test:comandos` — valida que toda referência a comando/skill nos workflows e skills existe de fato (não testa o CLI em runtime).
+- `npm run test:filtro` — testes unitários de `profile-filter.js`, `token-report.js`, `flow-map`, `env-loader.js`, `sync-engine.js` e `vcs/api.js`.
+- Não há teste automatizado de ponta a ponta do CLI (`jarvis <comando>` real) — a camada de dispatch (`program.js`, `bin/commands/*.js`) não é cobrida pelos testes unitários. Qualquer mudança ali precisa de validação manual dos comandos afetados.
+
+### Como testar código que lê `fs`/rede sem mockar módulo
+
+Os 3 arquivos mais críticos sem cobertura até pouco tempo atrás (`env-loader.js`, `sync-engine.js`, `vcs/api.js`) tocam filesystem real ou rede real — nenhum foi refatorado para isso, cada um usou o hook que já existia:
+
+- **`env-loader.js`** (e `flow-map.test.js`, mais antigo): `mkdtempSync(join(tmpdir(), "jarvis-..."))` monta um workspace fake com `.{ide}/ENV.md`, roda a função contra ele, `rmSync` no `finally`.
+- **`sync-engine.js`**: `getFrameworkRoot()` (`utils/paths.js`) já tem um escape hatch — `process.env.JARVIS_ROOT`, se definido e existir, vence sobre o framework real. O teste aponta `JARVIS_ROOT` para um fixture mínimo (`agents/`, `skills/`, etc. com 1 arquivo cada) em vez de sincronizar o framework inteiro.
+- **`vcs/api.js`**: usa `mock.method(globalThis, "fetch", ...)` do `node:test` pra controlar a resposta por vendor, sem mockar o módulo nem tocar rede real. **Atenção**: toda função de rede chama `getVcsToken()` antes do fetch — fixe `GITLAB_TOKEN`/`GITHUB_TOKEN`/`BITBUCKET_TOKEN` via env var no teste (ver `withEnv` em `vcs-api.test.js`), senão o resultado depende do que a máquina que roda o teste tiver em `.npmrc`/`gh auth`.
+- **`docs/fetch-file.js`/`docs/publish-file.js`**: mesmo mock de `fetch`. `redis-cli` (chamado por `docs/redis-cache.js`) **não dá pra mockar** — é um módulo nativo (`node:child_process`) não configurável, `mock.method` lança `TypeError: Cannot redefine property`. Como pode haver um `redis-cli` de verdade instalado (com ou sem servidor acessível) na máquina que roda o teste, cada teste usa uma chave de cache única (`docs:${randomUUID()}...`) em vez de mockar o cache — garante cache-miss determinístico sem depender do estado de nenhum Redis real.
+
+**Armadilha com `async`**: o helper `withEnv(vars, fn)` (repetido nos 3 arquivos acima) precisa de `return **await** fn()`, não `return fn()`, dentro do `try`. Sem o `await`, o `finally` que restaura a env var roda assim que `fn()` retorna uma Promise pendente — ou seja, **antes** da função terminar. Isso só não quebra quando a leitura da env var acontece antes do primeiro `await` de `fn` (ex: `fetchRawFile` lê o token antes do seu próprio `fetch`); quebra silenciosamente em qualquer função com mais de um `await` no meio do caminho (ex: `publishFile`, que busca o `index.md` antes de chegar no commit, que é onde o token é lido).
+
+Ao escrever um teste novo para um arquivo que toca `fs`/rede, prefira um desses padrões a mockar o módulo inteiro ou refatorar pra injeção de dependência — nenhum dos arquivos acima precisou mudar uma linha de lógica de produção para ganhar teste.
+
+## Lint e formatação
+
+`eslint.config.js` (raiz) + `.prettierrc.json` cobrem `bin/` e `test/`. `npm run lint` / `npm run format` — ver `package.json#scripts`.