jarvis-ai-framework 2.1.0 → 3.0.0

package/skills/eng-qa-planner/SKILL.md

@@ -0,0 +1,264 @@
+---
+name: eng-qa-planner
+description: >
+  Especialização de qa: analisa cobertura de testes da branch atual, identifica lacunas e estrutura
+  um plano priorizado para implementar os testes faltantes.
+  Trigger: Use quando precisar verificar se o código novo ou modificado possui testes adequados antes do merge.
+argument-hint: "[caminho-opcional]"
+allowed-tools: Read Grep Glob Bash
+license: AGPL-3.0
+metadata:
+  author: jarvis-team
+  version: "2.0"
+  area: qa
+---
+
+# Eng QA Planner - Planejamento de Testes
+
+Você é um especialista em planejamento de testes, focado em analisar as mudanças de código na branch atual e identificar lacunas de cobertura.
+
+## Objetivo
+
+Garantir que todo código novo ou modificado possua cobertura de testes adequada antes do merge.
+
+## Entrada
+
+- `$ARGUMENTS` - (Opcional) Caminho específico ou nome da feature para análise focada
+
+## Recursos
+
+- **Base**: [eng-qa](../eng-qa/SKILL.md) — princípios de risco e priorização usados aqui vêm da base
+- **Saída**: `$DOCS_FOLDER/engineering/qa/{task-id}-test_coverage_branch_report.md`
+
+---
+
+## Pré-requisito
+
+A branch precisa ter uma base de comparação (`origin/main` ou equivalente) para o `git diff` funcionar:
+
+```bash
+git diff origin/main...HEAD --name-only
+```
+
+---
+
+## Quando Usar
+
+Use esta skill quando:
+- Precisar verificar cobertura de testes antes de um merge/PR
+- Quiser identificar lacunas de testes no código modificado
+- Necessitar de um plano estruturado para implementar testes faltantes
+- Estiver fazendo code review e precisar avaliar a cobertura de testes
+
+**NÃO usar quando:**
+- A tarefa é escrever o teste em si (ver a especialização de execução registrada, ex: ferramenta E2E do projeto)
+- Não há diff contra uma base — nesse caso avalie a cobertura do projeto como um todo, não desta skill
+
+---
+
+## Padrões Críticos
+
+### Padrão 1: Sempre analisar o diff primeiro
+
+Antes de qualquer análise, obtenha as mudanças da branch:
+
+```bash
+git diff origin/main...HEAD --name-only
+git diff origin/main...HEAD
+git log origin/main..HEAD --oneline
+```
+
+Foque especialmente em:
+- Novas funções/métodos/classes
+- Lógica modificada em código existente
+- Novos endpoints ou interfaces de API
+- Mudanças de configuração
+- Breaking changes
+
+### Padrão 2: Priorizar código crítico
+
+Sempre priorize testes para:
+- APIs públicas e endpoints
+- Lógica de negócio e regras de validação
+- Código de autenticação/autorização
+- Manipulação de dados sensíveis
+
+---
+
+## Fluxo de Trabalho
+
+### 1. Mapear código para testes
+
+Para cada arquivo alterado, identifique o arquivo de teste correspondente:
+
+| Padrão | Exemplo |
+|--------|---------|
+| `[filename].test.[ext]` | `user.test.ts` |
+| `[filename].spec.[ext]` | `user.spec.ts` |
+| `tests/[filename]_test.[ext]` | `tests/user_test.py` |
+| `__tests__/[filename].[ext]` | `__tests__/user.ts` |
+| `test_[filename].[ext]` | `test_user.py` |
+
+### 2. Analisar cobertura existente
+
+Para arquivos com testes existentes, verificar:
+- Testes para novas funções/métodos
+- Testes para comportamento modificado
+- Casos de borda da nova lógica
+- Tratamento de erros para novos caminhos
+
+### 3. Identificar lacunas
+
+Determinar quais testes estão faltando:
+- Funcionalidades novas sem testes
+- Comportamentos modificados não refletidos
+- Casos de borda ausentes
+- Cenários de erro não cobertos
+- Pontos de integração não testados
+
+### 4. Priorizar por criticidade
+
+| Prioridade | Critério |
+|------------|----------|
+| Alta | APIs públicas, lógica de negócio crítica, código de segurança |
+| Média | Utilitários compartilhados, tratamento de erros |
+| Baixa | Código de apresentação, configurações simples |
+
+### 5. Gerar o relatório
+
+Gerar arquivo `$DOCS_FOLDER/engineering/qa/{task-id}-test_coverage_branch_report.md`:
+
+```markdown
+# Análise de Cobertura de Testes da Branch
+
+## Informações da Branch
+- **Branch:** [nome]
+- **Base:** main
+- **Arquivos alterados:** [número]
+- **Arquivos com gaps de cobertura:** [número]
+
+## Resumo Executivo
+[Visão geral da cobertura e principais preocupações]
+
+---
+
+## Análise por Arquivo
+
+### 1. `[caminho/do/arquivo.ts]`
+
+**Mudanças Realizadas:**
+- [Resumo das mudanças]
+
+**Cobertura Atual:**
+- Arquivo de teste: `[caminho]` ou ❌ Não encontrado
+- Status: [✅ Totalmente coberto | ⚠️ Parcialmente coberto | ❌ Não coberto]
+
+**Testes Ausentes:**
+- [ ] [Cenário específico]
+- [ ] [Outro cenário]
+
+**Prioridade:** [Alta | Média | Baixa]
+
+---
+
+## Plano de Implementação
+
+### Alta Prioridade
+
+#### `[arquivo/funcionalidade]`
+- **Arquivo de teste:** `[criar/atualizar em caminho]`
+- **Cenários:**
+  1. [Caso de teste com descrição]
+  2. [Outro caso]
+- **Estrutura sugerida:**
+```[linguagem]
+describe('[Funcionalidade]', () => {
+  it('should [comportamento esperado]', () => {
+    // arrange
+    // act
+    // assert
+  });
+});
+```
+
+### Média Prioridade
+[Mesma estrutura]
+
+### Baixa Prioridade
+[Mesma estrutura]
+
+---
+
+## Estatísticas
+
+| Métrica | Valor |
+|---------|-------|
+| Arquivos analisados | X |
+| Com cobertura adequada | X |
+| Precisam de testes | X |
+| Cenários identificados | X |
+
+## Recomendações
+
+1. [Recomendação principal]
+2. [Outra recomendação]
+```
+
+### Skills invocados durante a execução do skill
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| — | Nenhuma — skill autocontida | — |
+
+---
+
+## Regras
+
+### Nunca
+- Reportar código existente não alterado como se fosse gap da branch atual
+- Recomendar teste sem indicar prioridade e cenário concreto
+- Confundir plano/relatório com a implementação do teste em si
+
+### Sempre
+- Analisar apenas arquivos modificados na branch (foco no diff)
+- Priorizar caminhos críticos e casos de borda sobre quantidade de testes
+- Respeitar padrões de teste e helpers já existentes no projeto
+- Gerar o relatório mesmo quando a cobertura já está adequada (declarar isso explicitamente)
+
+---
+
+## Checklist de Conclusão
+
+- [ ] Diff da branch analisado (`git diff origin/main...HEAD`)
+- [ ] Cada arquivo alterado mapeado para seu teste correspondente (ou marcado como ausente)
+- [ ] Lacunas priorizadas por criticidade (alta/média/baixa)
+- [ ] Relatório gerado em `$DOCS_FOLDER/engineering/qa/{task-id}-test_coverage_branch_report.md`
+
+---
+
+## Output
+
+| Artefato | Descrição |
+|----------|-----------|
+| `$DOCS_FOLDER/engineering/qa/{task-id}-test_coverage_branch_report.md` | Relatório de cobertura com plano de implementação priorizado |
+
+> O artefato é gerado na raiz do projeto ou no diretório especificado em `$ARGUMENTS`.
+
+---
+
+## Mensagem de Conclusão
+
+```
+Planejamento de testes concluído!
+
+Branch: {nome da branch}
+Arquivos analisados: {N}
+Com gaps de cobertura: {N}
+
+Prioridade alta: {N} cenários
+Prioridade média: {N} cenários
+Prioridade baixa: {N} cenários
+
+Relatório: $DOCS_FOLDER/engineering/qa/{task-id}-test_coverage_branch_report.md
+Próximo passo: implementar os testes do plano ou registrar uma especialização de execução em QA_SPECIALIZATIONS
+```

package/skills/jarvis-context-detect/SKILL.md

@@ -260,6 +260,12 @@ CONTEXT_PROFILE:
 | feature | * | padrão |
 | refactor | * | alto |
 
+### Skills invocados durante a execução do skill
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| — | Nenhuma — skill autocontida | — |
+
 ---
 
 ## Output
@@ -397,4 +403,4 @@ Se não existir ou for antigo, executar detecção novamente.
 ## Recursos Adicionais
 
 - **Template**: Veja [assets/context-profile-template.md](assets/context-profile-template.md)
-- **Documentação CDD**: Veja `$IDE/templates/CDD aplicado a Prompts.md`
+- **Documentação CDD**: Veja `$IDE/templates/cdd-aplicado-a-prompts.md`

package/skills/jarvis-context-detect/assets/context-profile-template.md

@@ -124,4 +124,4 @@ Ou edite manualmente os valores acima e salve o arquivo.
 ---
 
 > Este perfil é usado automaticamente pelos workflows do Framework Jarvis.
-> Documentação: `$IDE/templates/CDD aplicado a Prompts.md`
+> Documentação: `$IDE/templates/cdd-aplicado-a-prompts.md`

package/skills/jarvis-create-specialization/SKILL.md

@@ -26,6 +26,14 @@ Gerar uma especialização **fiel ao código do projeto** e deixá-la ligada sem
 
 A especialização **soma-se** à skill base da área (`eng-backend` ou `eng-frontend`) e guarda só o que **depende da stack**. O que continua válido ao trocar de linguagem já está na base e não é repetido.
 
+> **Por que só backend e frontend**: essas duas áreas têm universo de stack **aberto** — qualquer
+> linguagem ou framework novo pode aparecer num projeto, então faz sentido ler o código e gerar
+> uma especialização sob demanda. QA, data, automation e platform têm um **conjunto fixo** de
+> especializações pré-construídas pelo framework (sem `metadata.stack`); registrar uma delas é
+> só listar e marcar no `ENV.md` — não há o que detectar por código nem gerar. Ver
+> `$IDE/skills/jarvis-list-specializations/SKILL.md` para listar/registrar as especializações
+> dessas 4 áreas, e o passo 9 do `/jarvis-init` para o mesmo fluxo durante o onboarding.
+
 ## Entrada
 
 - `$ARGUMENTS` - (Opcional) `[backend|frontend] [stack]`, por exemplo `backend golang`. O que faltar, pergunte (uma pergunta por vez).
@@ -151,6 +159,12 @@ awk 'BEGIN{fm=0} /^---[[:space:]]*$/{fm++; next} fm==1 && /^name:/{n=$2} fm==1 &
 3. Edite **só a linha dessa variável** (nunca outra linha do `ENV.md`) e **releia** o `ENV.md` para confirmar o resultado
 4. Se a gravação da lista falhar (skill gravado, lista não): diga que o skill existe mas **não** está registrado e mostre a linha a acrescentar à mão. **Nunca** registre um skill que não foi gravado
 
+### Skills invocados durante a execução do skill
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| — | Nenhuma — skill autocontida | — |
+
 ---
 
 ## Regras

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

@@ -25,7 +25,7 @@ Esta skill permite:
 CENTRAL_DOCS_REPO=https://gitlab.com/org/group/central-docs.git
 CENTRAL_DOCS_REF=main
 CENTRAL_DOCS_TARGET_BRANCH=dev
-SQUAD=squad-driver
+SQUAD=core
 WORKSPACE=meu-workspace
 ```
 
@@ -60,9 +60,9 @@ jarvis docs publish \
 
 # Publicar PRD
 jarvis docs publish \
-  --file ./docs/product/prd-gestao-condutores.md \
+  --file ./docs/product/prd-gestao-carteiras.md \
   --tipo prd \
-  --feature gestao-condutores
+  --feature gestao-carteiras
 
 # Publicar Swagger/OpenAPI (YAML)
 jarvis docs publish \
@@ -75,7 +75,7 @@ jarvis docs publish \
   --file ./docs/engineering/ard-api-wallet.md \
   --tipo ard \
   --feature api-wallet-auth-jwt \
-  --squad squad-driver \
+  --squad core \
   --workspace meu-workspace
 ```
 
@@ -102,16 +102,16 @@ central-docs/
 
 ```
 central-docs/
-└── drivers/
+└── core/
     ├── index.md
     ├── product/
-    │   └── gestao-de-condutores/
-    │       ├── prd-gestao-condutores.md
-    │       └── frd-gestao-condutores-onboarding.md
+    │   └── gestao-de-carteiras/
+    │       ├── prd-gestao-carteiras.md
+    │       └── frd-gestao-carteiras-onboarding.md
     └── engineering/
-        └── drivers-api/
-            ├── ard-drivers-api.md
-            └── rfc-drivers-api-idempotencia.md
+        └── api-wallet/
+            ├── ard-api-wallet.md
+            └── rfc-api-wallet-idempotencia.md
 ```
 
 ## Formato do index.md
@@ -119,19 +119,19 @@ central-docs/
 O `index.md` fica na raiz do squad (`{squad}/index.md`) e lista todos os documentos organizados por área e produto:
 
 ```markdown
-# squad-driver
+# core
 
 ## product
 
-### gestao-de-condutores
-- [prd-gestao-condutores.md](product/gestao-de-condutores/prd-gestao-condutores.md) | v1.2.0 | in_progress | jira: DRV-001 | tags: condutores,onboarding
-- [frd-gestao-condutores-onboarding.md](product/gestao-de-condutores/frd-gestao-condutores-onboarding.md) | v1.0.0 | in_review | jira: DRV-123 | tags: onboarding,cadastro
+### gestao-de-carteiras
+- [prd-gestao-carteiras.md](product/gestao-de-carteiras/prd-gestao-carteiras.md) | v1.2.0 | in_progress | jira: WAL-001 | tags: carteiras,onboarding
+- [frd-gestao-carteiras-onboarding.md](product/gestao-de-carteiras/frd-gestao-carteiras-onboarding.md) | v1.0.0 | in_review | jira: WAL-123 | tags: onboarding,cadastro
 
 ## engineering
 
-### drivers-api
-- [ard-drivers-api.md](engineering/drivers-api/ard-drivers-api.md) | v2.1 | Finalizada | tags: arquitetura,rest,api
-- [rfc-drivers-api-idempotencia.md](engineering/drivers-api/rfc-drivers-api-idempotencia.md) | Accepted | tags: idempotencia,redis
+### api-wallet
+- [ard-api-wallet.md](engineering/api-wallet/ard-api-wallet.md) | v2.1 | Finalizada | tags: arquitetura,rest,api
+- [rfc-api-wallet-idempotencia.md](engineering/api-wallet/rfc-api-wallet-idempotencia.md) | Accepted | tags: idempotencia,redis
 ```
 
 ## Frontmatter Obrigatório
@@ -141,11 +141,11 @@ O `index.md` fica na raiz do squad (`{squad}/index.md`) e lista todos os documen
 ```yaml
 ---
 id: PRD-001
-name: Gestão de Condutores
+name: Gestão de Carteiras
 version: 1.2.0
 status: in_progress
-task_link: https://jira.com/DRV-001
-related_repo: drivers-api,drivers-worker
+task_link: https://jira.com/WAL-001
+related_repo: api-wallet,wallet-worker
 ---
 ```
 
@@ -199,7 +199,7 @@ Detecta docs desatualizados e oferece publicação.
 ### Arquivo não encontrado
 
 ```
-❌ Arquivo não encontrado no central-docs: squad-driver/index.md
+❌ Arquivo não encontrado no central-docs: core/index.md
 ```
 
 **Solução:** Verificar se o squad existe no central-docs ou criar o `index.md` do squad.
@@ -227,10 +227,13 @@ bin/
     ├── utils/
     │   ├── npmrc-parser.js    # Extrai token do .npmrc
     │   └── git-parser.js      # Parseia URL GitLab
+    ├── vcs/
+    │   └── api.js             # fetchRawFile/createMergeRequest/commitFiles — GitLab/GitHub/Bitbucket
     └── docs/
         ├── validate-frontmatter.js  # Valida YAML
-        ├── fetch-file.sh      # Busca via API (cache redis-cli opcional)
-        └── publish-file.sh    # Publica via API + MR
+        ├── redis-cache.js     # Cache best-effort via redis-cli (get/setex/del)
+        ├── fetch-file.js      # Busca via vcs/api.js — CLI: jarvis docs fetch
+        └── publish-file.js    # Publica via vcs/api.js + MR — CLI: jarvis docs publish
 ```
 
 ### Fluxo de Publicação
@@ -280,7 +283,7 @@ jarvis docs sync
 
 ```bash
 # 1. Criar ARD localmente
-cat > docs/engineering/ard-drivers-api-auth.md << EOF
+cat > docs/engineering/ard-api-wallet-auth.md << EOF
 ---
 Status: Proposta
 Data: 2026-03-10
@@ -295,12 +298,12 @@ EOF
 
 # 2. Publicar
 jarvis docs publish \
-  --file docs/engineering/ard-drivers-api-auth.md \
+  --file docs/engineering/ard-api-wallet-auth.md \
   --tipo ard \
-  --feature drivers-api-auth
+  --feature api-wallet-auth
 
 # 3. Resultado
-# ✅ MR criado: docs/squad-driver/engineering/drivers-api/ard-drivers-api-auth → dev
+# ✅ MR criado: docs/core/engineering/api-wallet/ard-api-wallet-auth → dev
 # URL: https://gitlab.com/.../merge_requests/42
 ```
 

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

@@ -145,8 +145,8 @@ O CI (`.gitlab-ci.yml`) **falha** se o `index.md` commitado divergir do que o sc
 ```bash
 jarvis docs sync
 
-# Internamente executa:
-bash bin/lib/docs/fetch-file.sh "${SQUAD}/index.md" "${CENTRAL_DOCS_REF}"
+# Internamente chama fetchFile() de bin/lib/docs/fetch-file.js, equivalente a:
+jarvis docs fetch "${SQUAD}/index.md" "${CENTRAL_DOCS_REF}"
 ```
 
 **Passo 1.b — Fallback: navegar árvore (quando index.md não existe)**
@@ -180,8 +180,8 @@ Com base no contexto da tarefa (`TASK_MANAGER_KEY`, tags, descrição):
 **Passo 3 — Buscar arquivos identificados**
 
 ```bash
-bash bin/lib/docs/fetch-file.sh "${SQUAD}/product/${WORKSPACE}/prd-feature.md" "main"
-bash bin/lib/docs/fetch-file.sh "${SQUAD}/engineering/${WORKSPACE}/ard-feature.md" "main"
+jarvis docs fetch "${SQUAD}/product/${WORKSPACE}/prd-feature.md" "main"
+jarvis docs fetch "${SQUAD}/engineering/${WORKSPACE}/ard-feature.md" "main"
 ```
 
 **Passo 4 — Retornar resultado**
@@ -284,6 +284,12 @@ URL: {url do MR/PR retornada pelo adapter}
    URL: {CENTRAL_DOCS_REPO}/-/merge_requests/44
 ```
 
+### Skills invocados durante a execução do skill
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| — | Nenhuma — skill autocontida | — |
+
 ---
 
 ## Regras
@@ -296,7 +302,7 @@ URL: {url do MR/PR retornada pelo adapter}
 - Inventar metadados (version, status, id)
 - Editar `{SQUAD}/index.md` manualmente — sempre via `build-index.sh`
 - Usar path em campos `related_*` — sempre basename apenas
-- Usar formato `squad-driver` — sempre ALL-CAPS-COM-HIFEN: `MEU-SQUAD`
+- Usar squad em minúsculas (ex: `core`) — sempre ALL-CAPS-COM-HIFEN: `MEU-SQUAD`
 - Criar subpastas `engineering/index.md` ou `product/index.md` (não existem neste repo)
 
 ### Sempre

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

@@ -334,8 +334,16 @@ Além do índice, gerar relatório de saúde:
 
 ## Integração com Outros Skills
 
-- **docs-write**: Após criar/atualizar documentação, rodar `jarvis-docs-index` para atualizar índice
-- **arch-c4**: Incluir diagramas C4 na seção de Arquitetura do índice
+### Skills invocados durante a execução do skill
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| — | Nenhuma — skill autocontida | — |
+
+Relações com outras skills (não são chamadas do fluxo):
+
+- `eng-global-docs-write`: após criar ou atualizar documentação, rodar `jarvis-docs-index` para atualizar o índice
+- `eng-backend-arch-c4`: incluir diagramas C4 na seção de Arquitetura do índice
 
 ---
 

package/skills/jarvis-evolution-architect/SKILL.md

@@ -358,6 +358,12 @@ Recomendação arquitetural
 - Vídeos
 - Opiniões sem fonte
 
+### Skills invocados durante a execução do skill
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| — | Nenhuma — skill autocontida | — |
+
 ---
 
 ## 🎯 Entrada Típica

package/skills/jarvis-init/SKILL.md

@@ -234,7 +234,7 @@ Fluxo correto:
 3. Se `HUB≠DATA`: remover o bloco DATA_* inteiro
 4. Garantir `SESSIONS_DIR=.jarvis/sessions` e `JARVIS_PROJECT=https://github.com/phelipperibeiro/jarvis-framework` (ou URL que o usuário informar)
 5. Escrever `$IDE/ENV.md` com o restante do template (incluindo variáveis vazias)
-6. As chaves `BACKEND_SPECIALIZATIONS` e `FRONTEND_SPECIALIZATIONS` ficam **vazias**: não são perguntadas aqui. O registro de especializações é feito no **passo 9 (adicionar as stacks)**, ou depois, a qualquer momento: consulta com `jarvis-list-specializations` e criação com `jarvis-create-specialization`.
+6. As 6 chaves de especialização ficam **vazias**, exceto `QA_SPECIALIZATIONS`, que vem com `eng-qa-planner` (único hoje, pré-registrado por padrão — ver `templates/ENV-template.md`): não são perguntadas aqui. O registro/ajuste é feito no **passo 9 (adicionar as stacks)**, ou depois, a qualquer momento: consulta com `jarvis-list-specializations` e criação com `jarvis-create-specialization` (só backend/frontend).
 
 ### 3. Coletar Variáveis Obrigatórias
 
@@ -908,13 +908,13 @@ Se não existir na raiz do projeto:
 
 **Executar após gravar o ENV.md** (nos fluxos create, update B e upgrade C).
 
-Objetivo: garantir que `$IDE/rules/` contenha apenas as rules relevantes para o perfil do usuário, reduzindo tokens carregados em sessão.
+Objetivo: garantir que `$IDE/rules/` e `$IDE/rules-on-demand/` contenham apenas as rules relevantes para o perfil do usuário, reduzindo tokens carregados em sessão. A pasta `rules/` é carregada no início da sessão; a `rules-on-demand/` guarda as rules de uma etapa só, que cada workflow lê quando precisa (o Claude Code não a carrega sozinho). O filtro é o mesmo nas duas pastas, e `bin/lib/core/profile-filter.js` o espelha em JS (usado por `jarvis tokens`): ao mudar a lógica aqui, mude lá e em `rules/AGENTS.md`.
 
 **Passos:**
 
 ```
 1. Ler HUB, POSITION, AREA, SQUAD do ENV.md recém-gravado
-2. Listar todos os arquivos .md em rules/ (recursivo, exceto AGENTS.md)
+2. Para cada uma das duas pastas (rules/ e rules-on-demand/), listar todos os arquivos .md (recursivo, exceto AGENTS.md)
 3. Para cada arquivo:
    a. Ler o bloco `> **Applies to:**` (primeira ocorrência no arquivo)
    b. Se o bloco não existir → tratar como universal → copiar sempre
@@ -922,8 +922,8 @@ Objetivo: garantir que `$IDE/rules/` contenha apenas as rules relevantes para o
    d. **Condição especial RTK**: se o arquivo for `rtk-rules.md`,
       copiar APENAS se `RTK_ENABLED=true` no ENV.md
       (mesmo que o perfil bata, RTK é opt-in)
-   e. Se bate com o perfil → copiar para $IDE/rules/ (preservando subpastas)
-   f. Se não bate → deletar de $IDE/rules/ se existir lá
+   e. Se bate com o perfil → copiar para a mesma pasta em $IDE/ (rules/ → $IDE/rules/, rules-on-demand/ → $IDE/rules-on-demand/), preservando subpastas
+   f. Se não bate → deletar de $IDE/ se existir lá
 4. Exibir resumo ao usuário
 ```
 
@@ -976,8 +976,9 @@ function parseAppliesTo(fileContent) {
 ```bash
 # Exemplo: rules/engineering/qa/eng.qa.quality-gate-scoring-rules.md
 # Destino: $IDE/rules/engineering/qa/eng.qa.quality-gate-scoring-rules.md
-mkdir -p "$IDE/rules/$(dirname $relPath)"
-cp "rules/$relPath" "$IDE/rules/$relPath"
+# (o mesmo vale para rules-on-demand/ → $IDE/rules-on-demand/)
+mkdir -p "$IDE/$pasta/$(dirname $relPath)"
+cp "$pasta/$relPath" "$IDE/$pasta/$relPath"   # $pasta = rules ou rules-on-demand
 ```
 
 **Saída para o usuário:**
@@ -986,7 +987,7 @@ cp "rules/$relPath" "$IDE/rules/$relPath"
 🔍 Sincronizando rules para o perfil: HUB={HUB} | POSITION={POSITION} | AREA={AREA} | SQUAD={SQUAD}
 
 ✅ Rules sincronizadas:
-   Copiadas : N arquivos
+   Copiadas : N arquivos (rules/: N | rules-on-demand/: N)
    Removidas: N arquivos (não batem com o perfil)
    Universais: N arquivos (sem applies_to — sempre copiadas)
 ```
@@ -999,13 +1000,13 @@ cp "rules/$relPath" "$IDE/rules/$relPath"
 
 Oferecido sempre que o `ENV.md` fica pronto: criação, atualização, **Upgrade (C)** e o caso "já atualizado". **Não** é oferecido ao cancelar (D). A pessoa pode **pular**; ao pular, as listas ficam como estão e o projeto usa só a skill base.
 
-Trata **somente backend e frontend**. O passo:
+A **detecção de stack por código e a criação de skill novo** (sub-passos 9.4-9.6) tratam **somente backend e frontend** — são as únicas áreas com universo de stack aberto (qualquer linguagem/framework novo). **Listar o que já está instalado e registrar direto** (sub-passo 9.3) vale para as **6 áreas** com especialização (backend, frontend, qa, data, automation, platform): essas 4 últimas têm um conjunto fixo de skills pré-construídos, sem detecção por código nem criação — só listar e registrar (ver `architecture.md` da #63, Decisão 3.5). O passo:
 
-1. Confere que `BACKEND_SPECIALIZATIONS` e `FRONTEND_SPECIALIZATIONS` existem (acrescenta vazias se faltarem)
-2. Lista as especializações instaladas, registradas ou não, e deixa registrar uma direto
-3. **Lê** o workspace (a análise **só lê**: não altera arquivos do projeto nem as listas), identifica as stacks de backend e de frontend, inclusive de vários projetos, e **mostra o que encontrou antes de sugerir**
-4. Para cada stack, sugere **registrar o skill que já existe** (mesmo `area` e `stack`) ou **criar um novo** com `/jarvis-create-specialization {área} {stack}`; a pessoa escolhe, e o que não aceita não muda
-5. Mostra um resumo das listas e do que foi registrado ou criado
+1. Confere que as 6 variáveis de especialização existem (acrescenta vazias as que faltarem)
+2. Lista as especializações instaladas de todas as 6 áreas, registradas ou não, e deixa registrar qualquer uma direto
+3. **Lê** o workspace (a análise **só lê**: não altera arquivos do projeto nem as listas), identifica as stacks de backend e de frontend, inclusive de vários projetos, e **mostra o que encontrou antes de sugerir** (só essas 2 áreas)
+4. Para cada stack de backend/frontend, sugere **registrar o skill que já existe** (mesmo `area` e `stack`) ou **criar um novo** com `/jarvis-create-specialization {área} {stack}`; a pessoa escolhe, e o que não aceita não muda
+5. Mostra um resumo das 6 listas e do que foi registrado ou criado
 
 O tempo de ~10 minutos é referência, não limite. Nunca leia `.env*`, chaves ou credenciais.
 
@@ -1031,7 +1032,7 @@ O tempo de ~10 minutos é referência, não limite. Nunca leia `.env*`, chaves o
 - Usuário: {USER}
 - Cargo: {POSITION}
 - Limite AI: {MAX_AI_EXECUTION_PERCENTAGE}%
-- Especializações: {BACKEND_SPECIALIZATIONS e FRONTEND_SPECIALIZATIONS, ou "só skill base"}
+- Especializações: {as 6 variáveis registradas, ou "só skill base" por área}
 - CDD: habilitado
 - JARVIS_PROJECT: {JARVIS_PROJECT}
 
@@ -1064,6 +1065,12 @@ Apresentar checklist de onboarding por período (Dia 1, Semana 1, Mês 1).
 
 > **Checklists detalhados**: Ver `assets/onboarding-checklist.md`
 
+### Skills invocados durante a execução do skill
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Passo 9 — Adicionar as stacks (opcional) | `/jarvis-create-specialization {área} {stack}` | Se a pessoa escolher criar um skill novo para uma stack que ainda não tem especialização instalada (uma stack por vez; pular o passo não chama nada) |
+
 ---
 
 ## Validações de Segurança