jarvis-ai-framework 1.0.3 → 2.0.0

package/rules/AGENTS.md

@@ -22,6 +22,8 @@ rules/
 │   ├── eng.pr-rules.md       # Regras para /eng.pr
 │   ├── eng.bump-rules.md     # Regras para versionamento
 │   ├── eng.tech-spec-rules.md # Regras para tech specs
+│   ├── eng.specializations-rules.md # Carregamento de especializações por stack
+│   ├── eng.skills-rules.md       # Área obrigatória nos skills e aviso de skill inexistente
 │   └── qa/                   # Regras de QA
 └── product/                  # Regras de produto
     └── prod-rules.md    # Regras de especificacao
@@ -67,14 +69,14 @@ Cada arquivo de rule declara para quais perfis se aplica via bloco `applies_to`,
 | HUB | FRONTEND, BACKEND, QA, DATA, AI, FULLCYCLE | qualquer hub |
 | POSITION | TECH LEAD, PM, QA-ENGINEER, SENIOR, GENERALIST | qualquer cargo |
 | AREA | ENGINEERING, PRODUCT | qualquer área |
-| SQUAD | CORE, SUPPORT | qualquer squad |
+| SQUAD | CORE | qualquer squad |
 
 **Regras:**
 - Uma rule é aplicada se **todos** os eixos forem satisfeitos (AND, não OR)
 - Arquivos sem bloco `applies_to` são considerados **universais** — copiados para qualquer perfil
 - `rules/AGENTS.md` nunca é filtrado — sempre copiado
 
-**Quem faz a filtragem:** o skill `/init-jarvis` (Passo 9 — Profile-Aware Rules Sync). Ao criar, atualizar ou fazer upgrade do ENV.md, copia para `$IDE/rules/` apenas as rules que batem com o perfil (HUB + POSITION + AREA + SQUAD) e deleta as que não batem mais.
+**Quem faz a filtragem:** o skill `/jarvis-init` (Passo 9 — Profile-Aware Rules Sync). Ao criar, atualizar ou fazer upgrade do ENV.md, copia para `$IDE/rules/` apenas as rules que batem com o perfil (HUB + POSITION + AREA + SQUAD) e deleta as que não batem mais.
 
 **Ao criar uma nova rule**, definir o bloco `applies_to` é obrigatório. Sem ele, a rule é tratada como universal — o que pode ser indesejado para rules domain-specific.
 
@@ -147,7 +149,7 @@ Links para documentacao relacionada.
 | Fase | Comandos | Restricao |
 |------|----------|-----------|
 | Planejamento | `eng.start`, `eng.plan` | Somente analise, SEM codigo |
-| Implementacao | `eng.work` | Codigo e testes, SEM commits |
+| Implementacao | `eng.work` | Codigo e testes, commit por fase, SEM push nem PR |
 | Entrega | `eng.pr` | Branch, commit e PR |
 
 ### Seguranca
@@ -159,7 +161,7 @@ Links para documentacao relacionada.
 
 ### ENV.md
 
-- Validar ENV.md antes de qualquer comando (exceto `/init-jarvis`)
+- Validar ENV.md antes de qualquer comando (exceto `/jarvis-init`)
 - Respeitar `MAX_AI_EXECUTION_PERCENTAGE`
 
 ---

package/rules/engineering/eng-rules.md

@@ -7,7 +7,7 @@ env_file: "@/ENV.md"
 
 - **🚨 PRÉ-REQUISITO: VALIDAÇÃO DO ENV.md**
   - **ANTES de executar qualquer comando ou workflow**, o agente **DEVE verificar** se o arquivo `$IDE/ENV.md` existe e está preenchido corretamente.
-  - **Exceção**: O comando `/init-jarvis` é o único que pode ser executado sem o `ENV.md`, pois é ele que cria o arquivo.
+  - **Exceção**: O comando `/jarvis-init` é o único que pode ser executado sem o `ENV.md`, pois é ele que cria o arquivo.
   - **Validação obrigatória**: O arquivo deve conter as seguintes variáveis preenchidas (não vazias):
     - `WORKSPACE` (se vazio: nome da pasta que contém `$IDE/`)
     - `IDE`
@@ -20,13 +20,15 @@ env_file: "@/ENV.md"
   - **Se o ENV.md não existir ou estiver incompleto**, o agente deve:
     1. Interromper a execução do comando solicitado
     2. Informar ao usuário que o framework não foi inicializado
-    3. Orientar o usuário a executar `/init-jarvis` primeiro
+    3. Orientar o usuário a executar `/jarvis-init` primeiro
     ```
     ⚠️ O framework não foi inicializado.
     
     O arquivo ENV.md não existe ou está incompleto.
-    Por favor, execute `/init-jarvis` para configurar o ambiente antes de continuar.
+    Por favor, execute `/jarvis-init` para configurar o ambiente antes de continuar.
     ```
+  - **Listas de especializações (presentes, podem estar vazias)**: `BACKEND_SPECIALIZATIONS` e `FRONTEND_SPECIALIZATIONS` devem **existir** no `ENV.md`. Lista **vazia** é válida (só o skill base). Variável **ausente** interrompe o comando de backend ou de frontend e orienta o Upgrade do `/jarvis-init`. Detalhes e mensagens em `eng.specializations-rules.md`.
+  - **Skills sem área**: skill instalado sem `metadata.area` reconhecida bloqueia o comando, e skill pedido que não existe gera aviso. Detalhes e mensagens em `eng.skills-rules.md`.
 
 - **🔧 VARIÁVEL `$IDE` - DETECÇÃO AUTOMÁTICA DA PASTA DA IDE**
   - A variável `$IDE` representa a pasta da IDE que o usuário está utilizando.

package/rules/engineering/eng-security-rules.md

@@ -8,7 +8,7 @@ env_file: "@/ENV.md"
 # Regras de Seguranca para Engenharia
 
 Regras de seguranca aplicaveis a todo o fluxo de engenharia — do planejamento ao merge.
-Toda implementacao deve seguir estas regras por padrao, sem necessidade de invocar o skill `eng-cybersecurity` explicitamente.
+Toda implementacao deve seguir estas regras por padrao, sem necessidade de invocar o skill `eng-security-cybersecurity` explicitamente.
 
 ---
 
@@ -118,7 +118,7 @@ Se o PR toca em areas sensiveis (auth, sessions, RBAC, CORS, CSP, permissoes), o
 
 ## Fronteira Read-Only (Analise de Seguranca)
 
-Os skills de seguranca (`eng-threat-model`, `eng.security-audit`, `eng-security-triage`) operam em **modo estatico apenas**:
+Os skills de seguranca (`eng-security-threat-model`, `eng.security-audit`, `eng-security-triage`) operam em **modo estatico apenas**:
 
 - Leem codigo-fonte, historico git e relatorios fornecidos pelo usuario
 - **Nunca** executam, buildam, fuzzam ou modificam o codigo-alvo
@@ -129,7 +129,7 @@ Os skills de seguranca (`eng-threat-model`, `eng.security-audit`, `eng-security-
 
 ## Calibracao CDD por Risco
 
-Usar `context-detect` para calibrar a profundidade da analise de seguranca:
+Usar `jarvis-context-detect` para calibrar a profundidade da analise de seguranca:
 
 | Nivel de risco | Criterio | Estrategia | Tokens (estimado) |
 |---|---|---|---|
@@ -165,7 +165,7 @@ O agente de engenharia (ATHENA) deve recomendar o uso do agente SENTINEL (`eng.c
 - Feature envolve fluxo financeiro, PII ou auth complexa (OAuth, MFA)
 - Duvida sobre impacto de seguranca que excede o escopo das regras acima
 
-> O skill `/eng-cybersecurity` pode ser invocado diretamente para consulta rapida sem ativar o agente completo.
+> O skill `/eng-security-cybersecurity` pode ser invocado diretamente para consulta rapida sem ativar o agente completo.
 
 ---
 

package/rules/engineering/eng.breakdown-subtasks-rules.md

@@ -373,35 +373,32 @@ Ao gerar subtarefas com escopo de QA/testes, aplique a seguinte divisão **obrig
 
 ---
 
-## Formato de Saída: JSON
+## Formato de Saída: Markdown
 
 ### Estrutura Obrigatória
 
-```json
-{
-  "subtasks": [
-    {
-      "summary": "[STACK] Título específico da subtarefa",
-      "description": "Template completo com:\n\n## 🎯 O Que Você Vai Fazer\n\n... (resto conforme template acima)"
-    },
-    {
-      "summary": "[STACK] Próxima subtarefa",
-      "description": "..."
-    }
-  ]
-}
+Uma seção por subtarefa, em Markdown puro, na ordem de implementação:
+
+```markdown
+# Subtarefa N: [STACK] Título específico da subtarefa
+
+**Depende de:** Subtarefa X (ou "nenhuma")
+**Desbloqueia:** Subtarefa Y (ou "nenhuma")
+**Paralela com:** Subtarefa Z (ou "nenhuma")
+
+{Description ULTRA DETALHADA seguindo o template da seção "Estrutura de Subtarefa"}
+
+---
 ```
 
-### Regras CRÍTICAS para o JSON
+### Regras CRÍTICAS de formatação
 
-1. **APENAS JSON** - Sem texto antes ou depois
-2. **Use `\n` para quebras de linha** dentro das strings
-3. **Escape aspas com `\"`** dentro das strings
-4. **Todos os títulos com [STACK]** - Obrigatório
-5. **Description ULTRA DETALHADA** - Siga o template COMPLETAMENTE
-6. **Código COMPLETO** - Não use "..." ou placeholder
-7. **Caminhos reais** - Use paths que existem no projeto
-8. **Valide JSON** - Antes de retornar
+1. **Markdown nativo** - sem JSON, sem strings escapadas, sem `\n`
+2. **Todos os títulos com [STACK]** - Obrigatório
+3. **Description ULTRA DETALHADA** - Siga o template COMPLETAMENTE
+4. **Código COMPLETO** - Não use "..." ou placeholder
+5. **Caminhos reais** - Use paths que existem no projeto
+6. **Numeração sequencial** - Subtarefa 1, Subtarefa 2, etc.
 
 ---
 
@@ -434,7 +431,7 @@ Cada subtarefa deve ter seção "🔗 Dependências" indicando:
 
 ## Checklist de Qualidade Final
 
-Antes de retornar o JSON, valide CADA subtarefa:
+Antes de retornar, valide CADA subtarefa:
 
 ### ✅ Completude
 
@@ -479,7 +476,7 @@ Antes de retornar o JSON, valide CADA subtarefa:
 
 ### ✅ Validação
 
-- [ ] JSON é válido
+- [ ] Saída em Markdown válido, uma seção por subtarefa
 - [ ] Nenhuma subtarefa vaga
 - [ ] Toda subtarefa tem ≥ 4h e ≤ 1 dia de trabalho
 - [ ] Nenhuma fatia horizontal (split por camada)
@@ -500,7 +497,7 @@ eng.build-tech-spec → tech-spec.md → eng.breakdown-subtasks
 ### Saída (para onde vai)
 
 ```
-eng.breakdown-subtasks → subtasks JSON → Jira
+eng.breakdown-subtasks → subtarefas em Markdown → board
 ```
 
 ### Relação com Outros Workflows
@@ -550,12 +547,17 @@ eng.breakdown-subtasks → subtasks JSON → Jira
 
 ### ❌ MAL FEITA
 
-```json
-{
-  "summary": "[BACKEND] Criar autenticação",
-  "description": "Implementar o sistema de autenticação com JWT.\n\nFaça: Login, registro e validação.\n\nUse bcrypt para senha e JWT para token.\n\nRetorne o usuário no login."
-}
-```
+````markdown
+# Subtarefa 1: [BACKEND] Criar autenticação
+
+Implementar o sistema de autenticação com JWT.
+
+Faça: Login, registro e validação.
+
+Use bcrypt para senha e JWT para token.
+
+Retorne o usuário no login.
+````
 
 **Problemas:**
 
@@ -567,12 +569,181 @@ eng.breakdown-subtasks → subtasks JSON → Jira
 
 ### ✅ BEM FEITA
 
-````json
-{
-  "summary": "[BACKEND] Criar endpoint POST /api/auth/register com validação",
-  "description": "## 🎯 O Que Você Vai Fazer\n\nCriar o endpoint de registro que recebe email/senha, valida dados, cria usuário no banco e retorna JWT.\n\n---\n\n## 📋 Contexto\n\n### Por que?\nSistema precisa permitir novos usuários se cadastrem.\n\n### Pré-requisitos\n- [ ] Migration de usuários ([DATA] Criar migration tabela users)\n\n---\n\n## 🛠️ Stack\n\n| Tech | Versão | Para |\n|------|--------|------|\n| Express | 4.18+ | Framework HTTP |\n| bcrypt | 5.1+ | Hash de senha |\n| JWT | 9.0+ | Tokens |\n\n---\n\n## 📁 Arquivos\n\n| Arquivo | Ação | Descrição |\n|---------|------|--------|\n| `src/controllers/auth.controller.ts` | 🆕 | Controlador |\n| `src/services/auth.service.ts` | 🆕 | Lógica de negócio |\n| `src/routes/auth.ts` | 🆕 | Rotas |\n| `src/__tests__/auth.spec.ts` | 🆕 | Testes |\n\n---\n\n## 👣 Passos\n\n### Passo 1: Criar schema de validação\n\n```typescript\n// src/schemas/auth.schema.ts\nimport { body } from 'express-validator';\n\nexport const registerSchema = [\n  body('email')\n    .isEmail()\n    .withMessage('Email inválido')\n    .normalizeEmail(),\n  body('password')\n    .isLength({ min: 8 })\n    .withMessage('Mínimo 8 caracteres')\n    .matches(/[A-Z]/)\n    .withMessage('Precisa letra maiúscula'),\n];\n```\n\n**Explicação:**\n- `isEmail()`: Valida formato\n- `normalizeEmail()`: Padroniza\n- `matches(/[A-Z]/)`: Regex para maiúscula\n\n---\n\n### Passo 2: Criar AuthService\n\n```typescript\n// src/services/auth.service.ts\nimport bcrypt from 'bcrypt';\nimport jwt from 'jsonwebtoken';\n\nexport class AuthService {\n  async register(email: string, password: string) {\n    // Hash da senha\n    const hash = await bcrypt.hash(password, 10);\n    \n    // Criar usuário (assumindo repo existe)\n    const user = await this.userRepo.create({\n      email,\n      passwordHash: hash,\n    });\n    \n    // Gerar token\n    const token = jwt.sign(\n      { userId: user.id },\n      process.env.JWT_SECRET!,\n      { expiresIn: '24h' }\n    );\n    \n    return { user, token };\n  }\n}\n```\n\n**Explicação:**\n- `bcrypt.hash(password, 10)`: 10 salt rounds é seguro\n- `jwt.sign()`: Cria token que expira em 24h\n- Não retornamos passwordHash no response\n\n---\n\n## 🧪 Testes\n\n```typescript\n// src/__tests__/auth.spec.ts\nimport request from 'supertest';\nimport { app } from '../app';\n\ndescribe('POST /api/auth/register', () => {\n  it('deve registrar com email e senha válidos', async () => {\n    const response = await request(app)\n      .post('/api/auth/register')\n      .send({\n        email: 'test@example.com',\n        password: 'Senha123!',\n      });\n    \n    expect(response.status).toBe(201);\n    expect(response.body).toHaveProperty('token');\n  });\n  \n  it('deve retornar 400 para email inválido', async () => {\n    const response = await request(app)\n      .post('/api/auth/register')\n      .send({\n        email: 'invalid',\n        password: 'Senha123!',\n      });\n    \n    expect(response.status).toBe(400);\n  });\n});\n```\n\n### Cenários\n\n| Cenário | Input | Output |\n|---------|-------|--------|\n| Válido | email + senha válidos | 201 + token |\n| Email inválido | email sem @ | 400 VALIDATION_ERROR |\n| Senha fraca | < 8 chars | 400 VALIDATION_ERROR |\n\n---\n\n## ✅ Checklist\n\n- [ ] Schema criado\n- [ ] AuthService implementado\n- [ ] AuthController implementado\n- [ ] Rotas configuradas\n- [ ] Testes passando\n- [ ] Linter clean\n- [ ] Build ok\n\n---\n\n## ⚠️ Riscos\n\n| Risco | Como Evitar |\n|-------|-------------|\n| JWT_SECRET exposto | Usar .env, nunca commitar |\n| Senha em log | Não logar req.body |\n\n---\n\n## 🔗 Dependências\n\n**Depende de:** [DATA] Criar migration tabela users\n**Desbloqueia:** [FRONTEND] Criar tela de registro\n**Paralela com:** [INFRA] Configurar variáveis JWT\n"
+`````markdown
+# Subtarefa 1: [BACKEND] Criar endpoint POST /api/auth/register com validação
+
+## 🎯 O Que Você Vai Fazer
+
+Criar o endpoint de registro que recebe email/senha, valida dados, cria usuário no banco e retorna JWT.
+
+---
+
+## 📋 Contexto
+
+### Por que?
+Sistema precisa permitir novos usuários se cadastrem.
+
+### Pré-requisitos
+- [ ] Migration de usuários ([DATA] Criar migration tabela users)
+
+---
+
+## 🛠️ Stack
+
+| Tech | Versão | Para |
+|------|--------|------|
+| Express | 4.18+ | Framework HTTP |
+| bcrypt | 5.1+ | Hash de senha |
+| JWT | 9.0+ | Tokens |
+
+---
+
+## 📁 Arquivos
+
+| Arquivo | Ação | Descrição |
+|---------|------|--------|
+| `src/controllers/auth.controller.ts` | 🆕 | Controlador |
+| `src/services/auth.service.ts` | 🆕 | Lógica de negócio |
+| `src/routes/auth.ts` | 🆕 | Rotas |
+| `src/__tests__/auth.spec.ts` | 🆕 | Testes |
+
+---
+
+## 👣 Passos
+
+### Passo 1: Criar schema de validação
+
+```typescript
+// src/schemas/auth.schema.ts
+import { body } from 'express-validator';
+
+export const registerSchema = [
+  body('email')
+    .isEmail()
+    .withMessage('Email inválido')
+    .normalizeEmail(),
+  body('password')
+    .isLength({ min: 8 })
+    .withMessage('Mínimo 8 caracteres')
+    .matches(/[A-Z]/)
+    .withMessage('Precisa letra maiúscula'),
+];
+```
+
+**Explicação:**
+- `isEmail()`: Valida formato
+- `normalizeEmail()`: Padroniza
+- `matches(/[A-Z]/)`: Regex para maiúscula
+
+---
+
+### Passo 2: Criar AuthService
+
+```typescript
+// src/services/auth.service.ts
+import bcrypt from 'bcrypt';
+import jwt from 'jsonwebtoken';
+
+export class AuthService {
+  async register(email: string, password: string) {
+    // Hash da senha
+    const hash = await bcrypt.hash(password, 10);
+    
+    // Criar usuário (assumindo repo existe)
+    const user = await this.userRepo.create({
+      email,
+      passwordHash: hash,
+    });
+    
+    // Gerar token
+    const token = jwt.sign(
+      { userId: user.id },
+      process.env.JWT_SECRET!,
+      { expiresIn: '24h' }
+    );
+    
+    return { user, token };
+  }
 }
-````
+```
+
+**Explicação:**
+- `bcrypt.hash(password, 10)`: 10 salt rounds é seguro
+- `jwt.sign()`: Cria token que expira em 24h
+- Não retornamos passwordHash no response
+
+---
+
+## 🧪 Testes
+
+```typescript
+// src/__tests__/auth.spec.ts
+import request from 'supertest';
+import { app } from '../app';
+
+describe('POST /api/auth/register', () => {
+  it('deve registrar com email e senha válidos', async () => {
+    const response = await request(app)
+      .post('/api/auth/register')
+      .send({
+        email: 'test@example.com',
+        password: 'Senha123!',
+      });
+    
+    expect(response.status).toBe(201);
+    expect(response.body).toHaveProperty('token');
+  });
+  
+  it('deve retornar 400 para email inválido', async () => {
+    const response = await request(app)
+      .post('/api/auth/register')
+      .send({
+        email: 'invalid',
+        password: 'Senha123!',
+      });
+    
+    expect(response.status).toBe(400);
+  });
+});
+```
+
+### Cenários
+
+| Cenário | Input | Output |
+|---------|-------|--------|
+| Válido | email + senha válidos | 201 + token |
+| Email inválido | email sem @ | 400 VALIDATION_ERROR |
+| Senha fraca | < 8 chars | 400 VALIDATION_ERROR |
+
+---
+
+## ✅ Checklist
+
+- [ ] Schema criado
+- [ ] AuthService implementado
+- [ ] AuthController implementado
+- [ ] Rotas configuradas
+- [ ] Testes passando
+- [ ] Linter clean
+- [ ] Build ok
+
+---
+
+## ⚠️ Riscos
+
+| Risco | Como Evitar |
+|-------|-------------|
+| JWT_SECRET exposto | Usar .env, nunca commitar |
+| Senha em log | Não logar req.body |
+
+---
+
+## 🔗 Dependências
+
+**Depende de:** [DATA] Criar migration tabela users
+**Desbloqueia:** [FRONTEND] Criar tela de registro
+**Paralela com:** [INFRA] Configurar variáveis JWT
+`````
 
 **Diferenças:**
 

package/rules/engineering/eng.docs-scraping-rules.md

@@ -50,7 +50,7 @@ Todo arquivo `{robot-tag}-robot.md` deve conter:
 
 ### Recomendado
 
-- Chamar `/docs-index` após criar ou atualizar qualquer `{robot-tag}-robot.md` para manter o índice atualizado
+- Chamar `/jarvis-docs-index` após criar ou atualizar qualquer `{robot-tag}-robot.md` para manter o índice atualizado
 - Incluir o índice de colunas da tabela HTML (com numeração `[0]`, `[1]`, etc.) sempre que for inspecionado via log
 
 ---

package/rules/engineering/eng.downstream-flow-rules.md

@@ -28,7 +28,7 @@ Papéis no fluxo (ainda existem; não são cadeado):
 | **TECH LEAD** | `TECH LEAD` | Apoia priorização, review e deploy quando pedido |
 | **PM** | `PM`, `TPM`, `GPM` | Apoia aceite de produto quando pedido |
 | **QA** | `QA-ENGINEER` | Executa testes em apoio; não bloqueia o owner |
-| **N2** | Tech Analyst / suporte | Validação operacional se o time tiver esse papel |
+| **N2** | Suporte N2 | Validação operacional se o time tiver esse papel |
 
 ## Diagrama do Fluxo
 

package/rules/engineering/eng.integrations-rules.md

@@ -32,7 +32,7 @@ Qual o seu número de controle para esta tarefa?
 ```
 
 3. Usar a resposta (lowercase) como pasta `$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/` e no prefixo da branch.
-4. **Não** chamar `/eng-task-comment`, **não** mover card, **não** buscar issue no board.
+4. **Não** chamar `/eng-global-task-comment`, **não** mover card, **não** buscar issue no board.
 
 Com board definido, se o key não veio nos argumentos, perguntar o id do card naquele vendor (ex: Jira `TASK-123`).
 
@@ -41,7 +41,7 @@ Com board definido, se o key não veio nos argumentos, perguntar o id do card na
 Só se `TASK_MANAGER` estiver preenchido com um vendor. Freelance → pular.
 
 ```
-/eng-task-comment {TASK_MANAGER_KEY} {mensagem}
+/eng-global-task-comment {TASK_MANAGER_KEY} {mensagem}
 ```
 
 ## MR / PR

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

@@ -98,6 +98,6 @@ O workflow **deve sempre** terminar com:
    - 🟡 Yellow: pode abrir PR com ressalvas documentadas
    - 🔴 Red: bloqueado — listar o que impede o PR
 
-2. **Comentário no card** com o status final (via `/eng-task-comment`) — pular se freelance
+2. **Comentário no card** com o status final (via `/eng-global-task-comment`) — pular se freelance
 
 3. **Aguardar permissão explícita** do usuário para prosseguir para `/eng.pr`

package/rules/engineering/eng.skills-rules.md

@@ -0,0 +1,60 @@
+---
+trigger: always_on
+---
+
+> **Applies to:** HUB: all | POSITION: all | AREA: ENGINEERING | SQUAD: all
+
+# Regras de Skills: área obrigatória e nome inexistente
+
+## Objetivo
+
+Garantir que todo skill instalado tenha uma área reconhecida e avisar a pessoa, na hora, quando algo pede um skill que não existe.
+
+## Escopo
+
+Vale para todo comando `eng.*` e seus agentes, **ao iniciar**. A pasta de skills considerada é `$IDE/skills/`.
+
+**Áreas reconhecidas:** `qa`, `data`, `ai`, `frontend`, `backend`, `security`, `scraper`, `devops`, `global`, `product`.
+
+## Regras
+
+### Obrigatório
+
+1. **Bloqueio, primeiro.** Leia só o frontmatter de cada `$IDE/skills/*/SKILL.md`:
+
+   ```bash
+   for f in $IDE/skills/*/SKILL.md; do
+     awk -v f="$f" 'BEGIN{fm=0} /^---[[:space:]]*$/{fm++; next}
+       fm==1 && /^name:/{n=$2}
+       fm==1 && /^[[:space:]]+area:/{a=$2}
+       END{printf "%s|area=%s\n", n, a}' "$f"
+   done
+   ```
+
+   Se algum skill tem `area` vazia ou fora das áreas reconhecidas, **interrompa o comando** e exiba:
+   `⛔ Skills instalados sem área (metadata.area): {lista}. Marque a área de cada um (ou remova o skill) e execute o comando de novo. O comando foi interrompido.`
+2. **Aviso de nome inexistente.** Quando o usuário, um workflow, um agente ou uma das listas (`BACKEND_SPECIALIZATIONS`, `FRONTEND_SPECIALIZATIONS`) pedir um skill cujo `$IDE/skills/{nome}/SKILL.md` não existe, exiba na hora:
+   `⚠️ O skill "{nome}" não existe em $IDE/skills/. Use /jarvis-list-specializations para ver os nomes atuais e corrija a referência. Seguindo sem ele.`
+   e **siga sem esse skill** (em backend e frontend, com o skill base e os demais itens).
+
+### Proibido
+
+- Pular o bloqueio ou seguir como se o skill sem área estivesse marcado
+- Corrigir sozinho o nome, a área ou a lista do `ENV.md`
+- Usar um skill que não existe, nem adivinhar um nome parecido
+
+### Recomendado
+
+- Na mensagem do bloqueio, listar cada skill pelo nome da pasta
+- No aviso, citar o nome exatamente como foi pedido
+
+## Exceções
+
+- Só Claude Code e Cursor são suportados. Em IDEs com outra pasta de skills (por exemplo, Kiro e Codex), o bloqueio e o aviso podem não funcionar.
+- O comando `/jarvis-init` e a consulta `/jarvis-list-specializations` não passam pelo bloqueio (são como a pessoa descobre e corrige o problema).
+
+## Referências
+
+- `eng.specializations-rules.md`: listas de especializações e carregamento por área
+- `skills/jarvis-list-specializations/SKILL.md`: consulta do que está instalado e registrado
+- `skills/AGENTS.md`: áreas reconhecidas e padrão de nomes

package/rules/engineering/eng.specializations-rules.md

@@ -0,0 +1,69 @@
+---
+trigger: always_on
+---
+
+> **Applies to:** HUB: all | POSITION: all | AREA: ENGINEERING | SQUAD: all
+
+# Regras de Especializações por Stack
+
+## Objetivo
+
+Fazer todo comando `eng.*` carregar o **skill base** da área mais as **especializações** que o projeto registrou no `ENV.md`, e avisar a pessoa quando algo falta.
+
+## Escopo
+
+Vale para qualquer comando `eng.*` e seus agentes, **ao iniciar um trabalho de backend** (APIs, autenticação, workers, banco de dados, servidor) **ou de frontend** (componentes, interface, estilos, estado). Se o trabalho envolve as duas áreas, aplique a regra a cada uma. Se não é de nenhuma das duas, não carregue nada.
+
+| Área | Variável no `ENV.md` | Skill base |
+|------|----------------------|------------|
+| backend | `BACKEND_SPECIALIZATIONS` | `eng-backend` |
+| frontend | `FRONTEND_SPECIALIZATIONS` | `eng-frontend` |
+
+## Regras
+
+### Obrigatório
+
+1. **Leia a variável** da área no `$IDE/ENV.md`.
+2. **Variável ausente** (a chave não existe, diferente de vazia): **interrompa o comando** e exiba:
+   `⚠️ A variável {VAR} não existe no ENV.md. Execute /jarvis-init e escolha Upgrade (C) para acrescentá-la. O comando foi interrompido.`
+3. **Lista vazia:** siga só com o skill base e exiba:
+   `ℹ️ Sem especialização registrada para {área}. Usando só a skill base ({base}).`
+4. **Lista com itens:** carregue o skill base e, para **cada item**:
+   - nome fora de `^[a-z0-9][a-z0-9-]*$` (inclui `/`, `..` e maiúsculas): ignore o item e exiba
+     `⚠️ O item "{item}" de {VAR} tem caracteres inválidos (use letras minúsculas, números e hífen). Item ignorado.`
+   - `$IDE/skills/{item}/SKILL.md` não existe: exiba
+     `⚠️ O item "{item}" de {VAR} não corresponde a um skill instalado em $IDE/skills/. Instale o skill ou corrija a lista. Seguindo com o neutro e os demais itens.`
+   - existe: leia o `SKILL.md` e aplique-o junto com o skill base.
+5. **Informe** o que foi carregado: `✅ Skills carregados ({área}): {base} (base), {itens carregados}`.
+6. As especializações **somam-se** ao skill base; nenhuma o substitui.
+
+### Formato da lista
+
+- Itens **separados por vírgula**: `eng-backend-golang,eng-backend-nestjs`.
+- **Leia** com ou sem colchetes, espaços e aspas (`a,b`, `[a,b]`, `[ a , b ]`, `["a","b"]`).
+- Ao **gravar**, escreva sempre separado por vírgula, sem colchetes.
+
+### Proibido
+
+- Criar ou alterar a variável por conta própria.
+- Seguir só com o skill base quando a variável está **ausente**.
+- Carregar skills que não estão na lista.
+- Aceitar item com caminho (`/`, `..`) ou fora do padrão de nome.
+
+### Recomendado
+
+- Citar na mensagem o nome da variável e do item.
+- Com vários itens, carregar todos.
+
+## Exceções
+
+- Áreas além de backend e frontend não têm lista (evolução futura).
+- Skills de outras áreas não passam por esta regra.
+
+## Referências
+
+- `eng-rules.md`: validação do `ENV.md` (lista presente, mesmo vazia).
+- `eng.skills-rules.md`: área obrigatória nos skills e aviso de skill inexistente (o nome citado em uma lista que não existe também segue o aviso de lá).
+- `skills/jarvis-create-specialization/SKILL.md`: criação de uma especialização a partir do código do projeto e registro na lista.
+- `skills/jarvis-list-specializations/SKILL.md`: consulta das especializações instaladas e registradas.
+- `templates/ENV-template.md`: seção "Especializações de stack".

package/rules/engineering/eng.start-rules.md

@@ -18,19 +18,19 @@ O workflow `start` tem como **único objetivo** criar o documento de arquitetura
 
 O `start` é **estritamente proibido** de:
 
-| ❌ Proibido                          | ✅ Permitido                              |
-| ------------------------------------ | ----------------------------------------- |
-| Criar arquivos de código (.ts, .js)  | Criar `architecture.md`                   |
-| Modificar código existente           | Ler código para análise                   |
-| Executar comandos no terminal        | Listar arquivos e estruturas              |
-| Instalar dependências                | Buscar padrões no codebase                |
-| Fazer commits                        | Criar diretório da sessão                 |
-| Executar testes                      | Documentar decisões                       |
-| Iniciar servidores                   | Dialogar com usuário                      |
+| ❌ Proibido                          | ✅ Permitido                                                |
+| ------------------------------------ | ----------------------------------------------------------- |
+| Criar arquivos de código (.ts, .js)  | Criar `architecture.md`                                     |
+| Modificar código existente           | Ler código para análise                                     |
+| Instalar dependências                | Comandos de leitura (`git`, `ls`, `grep`) para investigar   |
+| Fazer commits                        | Criar a branch de feature (Fase 1.1 do workflow)            |
+| Executar testes                      | Criar o diretório da sessão e `context.md`                  |
+| Iniciar servidores                   | Registrar `.timestamp_start` na sessão                      |
+| Alterar arquivos do projeto          | Documentar decisões e dialogar com usuário                  |
 
 ### 2. Artefato Único
 
-O **único artefato** produzido pelo `start` é:
+O **único entregável** do `start` é:
 
 ```
 $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/architecture.md
@@ -38,7 +38,7 @@ $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/architecture.md
 
 > 📁 **Padrão**: `TASK_MANAGER_KEY` é o ID do card em **lowercase** (ex: `TASK-123` → `task-123`)
 
-Nenhum outro arquivo deve ser criado, modificado ou deletado.
+Além dele, o `start` pode criar apenas os arquivos de apoio da própria sessão (`context.md` e `.timestamp_start`, em `$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/`) e a branch de feature. Nenhum arquivo do projeto deve ser criado, modificado ou deletado.
 
 ### 3. Aprovação Obrigatória