jarvis-ai-framework 5.1.0 → 5.2.0

package/workflows/warm-up.md

@@ -1,538 +1,123 @@
 ---
-description: Fluxo para preparar a sessão com contexto personalizado por perfil
-version: "1.7"
+description: Prepara o contexto de uma tarefa nova carregando só o que é relevante (mapa de tecnologias do workspace, repositórios, especialidades, recorte do Central docs, entregas recentes e versões) e o guarda por apelido para o /eng.start ou o /prod.spec usar.
+version: "2.0"
 auto_execution_mode: 1
 env_file: "@/ENV.md"
 model_tier: low
-model_justification: Leitura seletiva de contexto e apresentação de menu — não requer raciocínio complexo
+model_justification: Leitura seletiva e perguntas de escopo — não requer raciocínio complexo
 ---
 
-# warm-up — Contexto Personalizado por Perfil
+# warm-up — preparação de contexto da tarefa
 
 ## Objetivo
 
-Preparar a sessão carregando **somente o contexto necessário** para o perfil do usuário,
-evitando leitura desnecessária de arquivos e economizando tokens.
+Antes de uma tarefa nova, carregar e guardar **só o contexto estritamente relevante**, para os comandos seguintes não reprocessarem nada. O resultado fica em `$SESSIONS_DIR/warm-ups/{apelido}/warm-up.md`; quem o usa (`/eng.start`, `/prod.spec*`) o leva para o `context.md` da sessão e apaga a pasta.
+
+As rules já estão no contexto da sessão: **não as releia**. Perfil de comunicação e autonomia ficam com o CDD (`/jarvis-context-detect`), que o comando da tarefa chama.
 
 ### Skills invocados durante o workflow
 
 | Passo | Skill | Condição |
 |-------|-------|----------|
-| 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_STORAGE` estiver configurado no ENV.md (Modo 1: Buscar Docs, via Skill tool) |
-| 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) |
-| Integração com CDD | `/jarvis-context-detect` | Se `ENABLE_CDD=true` no ENV.md, depois de o usuário selecionar a opção do menu e antes de iniciar o workflow escolhido |
+| Passo 5 — Central docs | `/jarvis-docs-central` | Se `CENTRAL_DOCS_STORAGE` estiver configurado no ENV.md (Modo 1: Buscar Docs, só o recorte escolhido) |
+| Passo 7 — Versões das ferramentas | `context7` (MCP: `resolve-library-id`, `query-docs`) | Se o MCP `context7` estiver disponível na sessão (até 5 ferramentas principais dos repositórios ativos); sem o MCP, pula em silêncio |
+| Passo 9 — Resumo e próximos comandos | `/eng.start`, `/prod.spec` | Só sugeridos ao usuário no fim (não são executados pelo warm-up) |
 
 ---
 
-## Passo 0 — Ler ENV.md (silenciosamente)
-
-Leia o arquivo `$IDE/ENV.md` e extraia as seguintes variáveis:
+## Passo 1 — Perfil (silencioso)
 
 ```bash
-grep -E "^(POSITION|SQUAD|HUB|AREA|WORKSPACE|WORKSPACE_REPOS|DOCS_FOLDER|RULES_FOLDER|FLOWS_FOLDER|TEMPLATES_FOLDER|MAX_AI_EXECUTION_PERCENTAGE|ENABLE_CDD)=" $IDE/ENV.md
-```
-
-Variáveis que guiam o carregamento de contexto:
-
-| Variável | Uso |
-|----------|-----|
-| `POSITION` | Define profundidade e foco do contexto |
-| `HUB` | Define especialidade técnica prioritária |
-| `AREA` | Define domínio (ENGINEERING vs PRODUCT vs outros) |
-| `SQUAD` | Referência de squad para contexto do time |
-| `WORKSPACE` | Pasta do `$IDE/`. Vazio = nome dessa pasta |
-| `WORKSPACE_REPOS` | Allowlist. Vazio = todas as subpastas com `.git/` |
-| `DOCS_FOLDER` | Caminho base dos documentos do workspace |
-| `RULES_FOLDER` | Caminho base das regras |
-| `FLOWS_FOLDER` | Caminho base dos workflows |
-| `MAX_AI_EXECUTION_PERCENTAGE` | Calibra nível de autonomia |
-| `ENABLE_CDD` | Ativa/desativa calibração contextual |
-
-> **Não invente valores ausentes.** Se uma variável crítica não estiver definida, continue com o comportamento padrão indicado abaixo.
->
-> `$IDE/ENV.md` pode estar num ancestral do cwd (workspace acima do repo aberto).
-> Se `WORKSPACE` estiver vazio, usar o nome da pasta que contém `$IDE/`.
-> Repos = `WORKSPACE_REPOS` ou scan de subpastas com `.git/`. Se houver mais de um, perguntar quais carregar nesta sessão (`ACTIVE_REPOS`). Um git na raiz = fluxo atual.
-
----
-
-## Passo 0.5 — Reconhecimento do Stack Técnico (silenciosamente)
-
-Objetivo: garantir contexto completo do stack **antes** de qualquer workflow,
-para nunca inventar ou sugerir tecnologias fora do que o projeto usa.
-
-### 1. Extrair variáveis de stack do ENV.md
-
-Além das variáveis de perfil (Passo 0), extrair todas as variáveis de tecnologia
-definidas no ENV.md — qualquer variável não relacionada a perfil de usuário com
-valor não vazio. Exemplos de padrões comuns:
-
-- Mensageria  : `MESSAGE_BROKER`, `MESSAGE_BROKER_URL_API`, `MESSAGE_BROKER_API_AUTH`
-- Banco       : `DB_*`, `DATABASE_*`
-- Cache       : `CACHE_*`, `REDIS_*`
-- Outros serviços: qualquer var com `_URL`, `_HOST`, `_API` no nome
-
-> Não hardcode nomes de tecnologias. Leia o que está definido e infira a tech
-> pelo valor da variável (ex: `MESSAGE_BROKER=rabbitmq` → tech = RabbitMQ).
-
-### 2. Para cada tecnologia identificada
-
-**a) Carregar documentação via context7:**
+grep -E "^(POSITION|AREA|HUB|SQUAD|WORKSPACE|WORKSPACE_REPOS|PROD_MODE|ENABLE_CDD|CENTRAL_DOCS_STORAGE|[A-Z]+_SPECIALIZATIONS)=" $IDE/ENV.md
 ```
-mcp__context7__resolve-library-id → query: {nome da tecnologia}
-mcp__context7__query-docs         → carregar docs relevantes
-```
-→ Usar a documentação como referência para toda a sessão.
-
-**b) Se houver URL de API de gerenciamento + credenciais:**
-- Consultar a API para entender a topologia real do serviço
-  (ex: exchanges, filas e bindings ativos para RabbitMQ via management API)
-- Usar as variáveis `*_URL_API` + `*_API_AUTH` correspondentes
-- Registrar o que foi encontrado como contexto da sessão
 
-### 3. Invariante de sessão — crítica
+`$IDE/ENV.md` pode estar num ancestral do cwd. `WORKSPACE` vazio = nome da pasta que contém `$IDE/`. Não invente valores ausentes; não pergunte o que está no ENV.
 
-> 🔒 A partir deste passo, para toda a sessão:
-> - Trabalhar **somente** com as tecnologias identificadas aqui
-> - **Nunca sugerir alternativas tecnológicas** não presentes no stack identificado
-> - **Nunca inventar** configurações, topologias ou comportamentos não confirmados
->   via ENV, API ou codebase
-> - Exceção: **somente se o usuário solicitar explicitamente**
+## Passo 2 — Mapa de tecnologias (`CDD-MIND-MAP.md`)
 
-> Se nenhuma variável de stack for encontrada no ENV.md, pular silenciosamente.
+O mapa é o **contexto de workspace**: stack e papel de cada repositório. Fica na raiz do workspace (ao lado do `AGENTS.md`), fora do versionamento. Formato e instruções de preenchimento: `$IDE/templates/cdd-mind-map-template.md`.
 
----
-
-## Passo 1 — Determinar Perfil de Comunicação
-
-O perfil de comunicação é derivado de `POSITION` (conforme definido no `$IDE/taxonomy.md`).
-**Não use a lista abaixo como hardcode** — use-a como referência de interpretação semântica:
-
-| Categoria semântica | Exemplos de POSITION | Perfil de comunicação |
-|---------------------|---------------------|----------------------|
-| Técnico iniciante | JUNIOR, PLENO | `didático` — explicar decisões, incluir contexto |
-| Técnico sênior | SENIOR, TECH LEAD, SPECIALIST | `direto` — foco em trade-offs e riscos |
-| Gestão de produto | PM, TPM, GPM | `estratégico` — impacto e visão de produto |
-| Executivo | CTO e equivalentes | `estratégico` — visão de alto nível |
-| Não definido | — | `didático` (padrão conservador) |
+1. **Repositórios do workspace:** os de `WORKSPACE_REPOS` ou, se vazia, as subpastas com `.git/`; só a raiz com `.git` = projeto único (uma linha).
+2. **Mapa não existe:** infira cada repositório pela tabela `$IDE/skills/jarvis-init/assets/sinais-de-stack.md` e pela estrutura (papel), mostre a tabela e pergunte com `AskUserQuestion`: **Confirmar** | **Corrigir** | **Incluir informação**. Repita até confirmar. Então:
+   - grave `CDD-MIND-MAP.md` na raiz do workspace;
+   - garanta a linha no `.gitignore`: `grep -qxF 'CDD-MIND-MAP.md' .gitignore 2>/dev/null || echo 'CDD-MIND-MAP.md' >> .gitignore`;
+   - se o `AGENTS.md` da raiz não citar o mapa, acrescente uma linha:
+     `> Contexto de workspace: [CDD-MIND-MAP.md](CDD-MIND-MAP.md) (tecnologias e papel de cada repositório; lido pelo /warm-up).`
+3. **Mapa existe:** leia-o. Repositório com `.git` que não está no mapa → infira, valide com o usuário e acrescente só ele. Não reprocesse as linhas existentes.
 
-> O mapeamento exato de quais POSITIONs existem vem do `$IDE/taxonomy.md` — não assuma valores fora desse arquivo.
+Nunca leia `.env*`, chaves nem credenciais.
 
----
-
-## Passo 2 — Sincronizar Documentação Central (condicional)
+## Passo 3 — Repositórios ativos
 
-Se `CENTRAL_DOCS_STORAGE` estiver configurado no ENV.md, invocar o skill `jarvis-docs-central` via Skill tool para carregar **o que já foi implementado** no produto (funcionalidades `feature-*` e entregas recentes `delivery-*`). Os documentos de trabalho (PRD, FRD, ARD, RFC) ficam em `docs/jarvis/` e não estão no Central docs.
+- Projeto único: segue sem perguntar.
+- Workspace com vários: `AskUserQuestion` (multiSelect) **"Quais repositórios aquecer nesta sessão?"**, com papel e stack do mapa em cada opção → `ACTIVE_REPOS`.
 
-> ⚠️ **IMPORTANTE**: NÃO executar `jarvis docs sync` diretamente via Bash.
-> Usar sempre: **Skill tool → jarvis-docs-central (Modo 1: Buscar Docs)**
+## Passo 4 — Especialidades (em memória)
 
-O skill `jarvis-docs-central` gerencia:
-- O adaptador de `CENTRAL_DOCS_STORAGE` (pasta, com `git pull` quando a pasta é um clone)
-- Índice ausente (o squad ainda não tem consolidação)
-- Tratamento de erros
-
-**Invocação:**
-```
-Skill tool: jarvis-docs-central
-Modo: 1 (Buscar Docs)
-Contexto: warm-up - sincronização inicial
-```
+1. Áreas dos `ACTIVE_REPOS` pela coluna **Área** do mapa.
+2. `AskUserQuestion` (multiSelect) **"Quais áreas a tarefa envolve?"**, com as inferidas já marcadas.
+3. Aplique a regra de especializações (`eng.specializations-rules`) **só** nas áreas confirmadas: skill base + lista `{ÁREA}_SPECIALIZATIONS`. As das outras áreas não são carregadas.
 
-**Output esperado:**
-```
-🔄 Sincronizando docs de {SQUAD}/{WORKSPACE}...
-✅ Docs sincronizados
-📊 7 documentos disponíveis:
-   - 4 funcionalidade(s)
-   - 3 entrega(s) recente(s)
-```
+Tudo em memória: o `ENV.md` e qualquer configuração persistente **nunca** são alterados.
 
-**Comportamento:**
-- Se `CENTRAL_DOCS_STORAGE` vazio → pula silenciosamente
-- Se o `git pull` falhar (pasta com git) → avisa e lê a cópia local
-- Se `index.md` não existe → avisa que o squad ainda não tem consolidação (sugere `/eng.spec-consolidate --inicial`)
-- Se erro genérico → exibe mensagem clara e continua sem bloquear
+## Passo 5 — Central docs (condicional)
 
-Após sincronizar, exibir resumo dos documentos disponíveis:
-- PRDs compartilhados do produto
-- ARDs gerais e específicos do repo atual
-- RFCs relevantes
-- Dependências externas (outros produtos/squads)
+Se `CENTRAL_DOCS_STORAGE` estiver vazio, pule. Senão, via Skill tool `jarvis-docs-central` (Modo 1):
 
----
+1. Leia só o índice `{SQUAD}/index.md`.
+2. `AskUserQuestion`: **"Qual produto ou funcionalidade a tarefa vai impactar?"** (opções do índice; "Nenhuma / tarefa nova").
+3. Leia **só** os `feature-*.md` escolhidos e os `delivery-*.md` desse recorte. Resuma em poucas linhas o comportamento atual e onde está no código.
 
-## Passo 3 — Carregar Contexto Seletivo por AREA e HUB
+Sem índice: avise que o squad ainda não tem consolidação (`/eng.spec-consolidate --inicial`) e siga. Erro: avise e siga, sem bloquear.
 
-**Regra fundamental**: os caminhos são construídos **dinamicamente** a partir dos valores lidos do ENV.md.
-Não use caminhos hardcoded. Não escaneie pastas inteiras.
+## Passo 6 — Entregas recentes
 
-### 3.1 — Construir caminhos base a partir do ENV e taxonomy
+Por repositório ativo, na branch alvo (`main`, `dev` ou a padrão do remoto):
 
 ```bash
-# 1. Ler AREA e HUB do ENV
-AREA=$(grep "^AREA=" $IDE/ENV.md | cut -d= -f2)
-HUB=$(grep "^HUB=" $IDE/ENV.md | cut -d= -f2)
-
-# 2. Ler prefixo da AREA no taxonomy (linha "prefix: xxx" abaixo do ### AREA)
-{prefix}   = valor de "prefix:" definido sob ### {AREA} em $IDE/taxonomy.md
-{area}     = lowercase(AREA)
-
-ex: AREA=ENGINEERING → prefix="eng",  area="engineering"
-    AREA=PRODUCT     → prefix="prod", area="product"
-```
-
-> Se o prefixo não estiver definido no taxonomy, usar `lowercase(AREA)` como fallback.
-
-### 2.2 — Sequência de leitura (executar nessa ordem)
-
-**Sempre leia:**
-```
-git log --oneline -3             ← commits recentes (independente de perfil)
-git status --short               ← estado atual do repositório
-```
-
-**Docs da área (tentar em ordem, parar no primeiro encontrado):**
-```
-1. $DOCS_FOLDER/{area}/index.md  ← índice de docs da área (ex: docs/engineering/index.md)
-2. $DOCS_FOLDER/index.md         ← índice geral (fallback)
-2. $DOCS_FOLDER/AGENTS.md        ← resumo para agents geral (fallback)
-(não ler os docs em si — apenas o índice para mapear o que existe)
-```
-
-**Regras da área:**
-```
-$RULES_FOLDER/{area}/{prefix}-rules.md
-ex: $RULES_FOLDER/engineering/eng-rules.md
-    $RULES_FOLDER/product/prod-rules.md
-```
-
-**Regras do hub (adicionar ao contexto base, se existir):**
-```
-$RULES_FOLDER/{area}/{hub}/{hub}-rules.md
-ex: $RULES_FOLDER/engineering/qa/qa-rules.md
-    $RULES_FOLDER/engineering/ai/ai-rules.md
+git -C {repo} log --merges -5 --format='%h %ad %s%n%b' --date=short {branch}
+git -C {repo} show --stat --format= {hash}   # só os arquivos tocados, sem diff
 ```
 
-**README (apenas para perfil didático ou quando não há docs/index.md):**
-```
-README.md (raiz do projeto)      ← visão geral do projeto
-```
+Sem merges (squash/rebase): use os 5 últimos commits e avise em uma linha. Registre título, descrição e arquivos tocados; destaque padrões ou decisões recentes que valem para a tarefa.
 
-### 2.3 — Exemplos de caminhos gerados (ilustrativo)
+## Passo 7 — Versões das ferramentas (só com o MCP `context7`)
 
-| AREA | prefix | HUB | Caminhos tentados |
-|------|--------|-----|-------------------|
-| ENGINEERING | eng | QA | `docs/engineering/index.md` → `rules/engineering/eng-rules.md` → `rules/engineering/qa/qa-rules.md` |
-| ENGINEERING | eng | AI | `docs/engineering/index.md` → `rules/engineering/eng-rules.md` → `rules/engineering/ai/ai-rules.md` |
-| PRODUCT | prod | — | `docs/product/index.md` → `rules/product/prod-rules.md` |
+Sem o MCP disponível, pule em silêncio. Com ele: para até **5** ferramentas principais dos repositórios ativos (coluna do mapa), `resolve-library-id` + `query-docs` só para a versão atual e mudanças relevantes. Uma linha por ferramenta: versão no projeto × atual.
 
-> **Importante**: Se um arquivo ou pasta não existir, ignore silenciosamente — não errar, não inventar.
-> Novos valores de AREA ou HUB adicionados ao taxonomy.md funcionam automaticamente sem alterar este workflow.
-
----
+## Passo 8 — Apelido e gravação
 
-## Passo 3 — Resumo de Contexto Carregado
+1. `AskUserQuestion`: **"Qual apelido para este aquecimento?"**, com uma sugestão derivada dos repositórios e do recorte (ex.: `api-2-checkout`) e a opção de digitar. Kebab-case, sem acentos.
+2. Apelido já existe em `$SESSIONS_DIR/warm-ups/`: pergunte se sobrescreve ou escolhe outro.
+3. Grave `$SESSIONS_DIR/warm-ups/{apelido}/warm-up.md` pelo template `$IDE/templates/warm-up-template.md`. Sem tokens, e-mails nem valores do ENV.
 
-Após as leituras, exiba **somente** um resumo compacto:
+## Passo 9 — Resumo e próximos comandos
 
 ```
-── Sessão iniciada ──────────────────────────────────────
-  Workspace: {WORKSPACE}
-  Perfil   : {POSITION} · {HUB} · {SQUAD}
-  Autonomia: {MAX_AI_EXECUTION_PERCENTAGE}%
-  Stack    : {lista das techs identificadas no ENV}
-  Docs     : {context7 carregado para cada tech + docs de área}
-  Topologia: {resumo da consulta à API de gerenciamento, se disponível}
-  Commits  : {N} commits recentes carregados
-─────────────────────────────────────────────────────────
-```
-
----
-
-## Passo 4 — Menu Adaptado por AREA
-
-O menu é determinado pelos valores de `POSITION`, `AREA` e `HUB` lidos do ENV.md.
-
-> ⚠️ **Ordem de precedência — verificar SEMPRE nesta sequência:**
-> 1. **POSITION** — se houver menu dedicado para o POSITION, usá-lo diretamente (ignora AREA+HUB)
-> 2. **AREA + HUB** — combinações específicas (DATA, QA, RPA)
-> 3. **AREA** — menu genérico da área
-> 4. **Genérico** — fallback para AREAs sem menu próprio
->
-> **Nunca avaliar menus de AREA antes de verificar se o POSITION tem menu dedicado.**
-
-> Se o valor de AREA não tiver menu definido abaixo, use o **menu genérico**.
-> Novos valores de AREA adicionados ao taxonomy.md devem ganhar um menu correspondente aqui.
-
----
-
-### Menu para POSITION=TECH LEAD (sobrepõe menu genérico de ENGINEERING)
+🔥 Warm-up "{apelido}" pronto
 
-> ℹ️ Usar este menu quando `POSITION=TECH LEAD` e `AREA=ENGINEERING`.
-> O Tech Lead é responsável pelos gates de qualidade do time.
+🗺️  Mapa: {n} repositórios ({criado | atualizado: +{repos} | sem mudança})
+📦 Ativos: {repo (papel, stack)} …
+🧩 Áreas: {áreas} · fora: {áreas descartadas}
+📚 Central docs: {recorte | não configurado}
+🔀 Entregas: {n} merges lidos
+🔧 Versões: {ferramenta x.y → atual} … | não consultado
 
+➡️  Próximos: /eng.start {KEY} · /prod.spec …  (eles usam este aquecimento)
 ```
-Como você quer continuar?
-
-A: Iniciar sessão para codar (eng.start)
-B: Debug / Investigar problema (eng.debug)
-C: Criar ou iterar ARD (eng.create-ard)
-D: Criar ou iterar ARD desde o codebase (eng.create-ard-from-code)
-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)
-I: Outro
-```
-
-Roteamento:
-- A → `$FLOWS_FOLDER/engineering/eng.start.md`
-- B → `$FLOWS_FOLDER/engineering/eng.debug.md`
-- C → `$FLOWS_FOLDER/engineering/eng.create-ard.md`
-- D → `$FLOWS_FOLDER/engineering/eng.create-ard-from-code.md`
-- E → `$FLOWS_FOLDER/engineering/eng.create-rfc.md`
-- F → `$FLOWS_FOLDER/engineering/eng.build-tech-spec.md`
-- G → `$FLOWS_FOLDER/engineering/eng.review.md`
-- H → `$FLOWS_FOLDER/engineering/eng.docs.md`
-- I → perguntar e rotear dinamicamente
 
 ---
 
-### Menu para POSITION=CTO (sobrepõe AREA)
+## Regras
 
-> ℹ️ Usar este menu para qualquer `AREA` quando `POSITION` é equivalente a CTO.
-> Foco estratégico: arquitetura, risco e decisões de alto impacto — sem granularidade operacional.
-
-```
-Como você quer continuar?
-
-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.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
-
----
-
-### Menu para AREA=ENGINEERING e HUB=DATA
-
-> ℹ️ Usar este menu quando `AREA=ENGINEERING` **e** `HUB=DATA`.
-
-```
-Como você quer continuar?
-
-A: Criar pipeline novo (data.new-pipeline)
-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`
-- C → `$FLOWS_FOLDER/engineering/data/data.contract.md`
-- D → perguntar e rotear dinamicamente
-
----
-
-### Menu para AREA=ENGINEERING e (HUB=QA ou Quality Champion)
-
-> ℹ️ Usar este menu quando `AREA=ENGINEERING` **e** uma das condições:
-> - `HUB=QA`
-> - O usuário atual (`USER` do ENV.md) constar em `members.md` com `Quality Champion` no campo Posição
->
-> Para verificar se o usuário é Quality Champion:
-> ```bash
-> grep -i "$USER" members.md | grep -i "Quality Champion"
-> ```
-> Se retornar resultado → usuário é Quality Champion → usar este menu.
-
-```
-Como você quer continuar?
-
-A: Mapear estratégia de testes para uma feature (qa.refinement-entry)
-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-sprint-planning.md`
-- C → `$FLOWS_FOLDER/engineering/qa/eng.qa-release-signoff.md`
-- D → perguntar e rotear dinamicamente
-
----
-
-### Menu para AREA=ENGINEERING (qualquer HUB)
-
-```
-Como você quer continuar?
-
-A: Iniciar sessão para codar (eng.start)
-B: Debug / Investigar problema (eng.debug)
-C: Criar ou iterar um ARD do zero ou desde um PRD (eng.create-ard)
-D: Criar ou iterar um ARD desde o codebase (eng.create-ard-from-code)
-E: Abrir ou iterar um RFC (eng.create-rfc)
-F: Fazer uma tech spec (eng.build-tech-spec)
-G: Revisar código / PR (eng.review)
-H: Documentar (eng.docs)
-I: Criar ou manter robô RPA (eng.rpa.robot) — skill técnica, não depende de squad
-J: Outro
-```
-
-Roteamento:
-- A → `$FLOWS_FOLDER/engineering/eng.start.md`
-- B → `$FLOWS_FOLDER/engineering/eng.debug.md`
-- C → `$FLOWS_FOLDER/engineering/eng.create-ard.md`
-- D → `$FLOWS_FOLDER/engineering/eng.create-ard-from-code.md`
-- E → `$FLOWS_FOLDER/engineering/eng.create-rfc.md`
-- 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.rpa.robot.md`
-- J → perguntar e rotear dinamicamente
-
-### Menu para AREA=PRODUCT
-
-```
-Como você quer continuar?
-
-A: Criar nova PRD (prod.spec.prd)
-B: Criar novo FRD (prod.spec.frd)
-C: Criar story, task ou issue (prod.spec.issue)
-D: Detalhar épico (prod.spec.epic)
-E: Outro
-```
-
-Roteamento:
-- A → `$FLOWS_FOLDER/product/prod.spec.prd.md`
-- B → `$FLOWS_FOLDER/product/prod.spec.frd.md`
-- C → `$FLOWS_FOLDER/product/prod.spec.issue.md`
-- D → `$FLOWS_FOLDER/product/prod.spec.epic.md`
-- E → perguntar e rotear dinamicamente
-
-### Menu genérico (qualquer AREA além de ENGINEERING/PRODUCT)
-
-```
-Como você quer continuar?
-
-A: Perguntar algo sobre o projeto
-B: Criar documentação
-C: Outro
-```
-
-Roteamento:
-- A → responder com base no contexto carregado
-- B → `$FLOWS_FOLDER/engineering/eng.docs.md` (se existir) ou criar diretamente
-- C → perguntar qual atividade e rotear dinamicamente
-
-### Ajuste de menu por POSITION (sobrepõe AREA quando aplicável)
-
-| POSITION semântico | Ajuste no menu |
-|-------------------|----------------|
-| 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 |
-
----
-
-## Passo 5 — Limite de Execução (MAX_AI_EXECUTION_PERCENTAGE)
-
-`MAX_AI_EXECUTION_PERCENTAGE` é um **limite hard de execução** — a IA para obrigatoriamente quando atinge esse percentual do plano e **sempre pergunta** antes de continuar, mesmo com valores altos.
-
-**Regra de cálculo:**
-```
-tarefas_executáveis = floor(total_tarefas × (MAX_AI_EXECUTION_PERCENTAGE / 100))
-
-ex: 10 tarefas, MAX=70  → IA executa 7, para, pergunta ao usuário
-ex: 10 tarefas, MAX=90  → IA executa 9, para, pergunta ao usuário
-ex: 10 tarefas, MAX=100 → IA executa todas, mas ainda reporta e pergunta ao final
-```
-
-**Ao atingir o limite — sempre, sem exceção:**
-1. Parar a execução imediatamente
-2. Reportar o que foi feito
-3. Listar o que resta com sugestões de como o humano pode executar
-4. Perguntar explicitamente como o usuário deseja prosseguir
-5. Nunca continuar sem resposta explícita do usuário
-
-**Tarefas restantes (acima do limite):**
-- A IA **nunca executa** as tarefas restantes de forma autônoma — nem que o usuário peça "continua tudo"
-- A IA **pode assistir**: explicar, sugerir comandos, preparar código para revisão
-- Quem executa é o humano
-
-**O nível de autonomia calibra o comportamento *dentro* do limite, mas não o substitui:**
-
-| Valor | Nível | O que muda dentro do limite |
-|-------|-------|-----------------------------|
-| ≥ 90% | alto | Executa sem pedir confirmação a cada passo |
-| 70–89% | médio | Pausa em decisões críticas antes de continuar |
-| 60–69% | baixo | Apresenta opções e aguarda aprovação a cada passo |
-| Não definido | médio | Usa 80% como padrão |
-
-Declare ao usuário: limite configurado, quantas tarefas isso representa e o que ficará para execução humana.
-
----
-
-## Regras do Warm-up
-
-### Nunca faça
-- Ler uma pasta inteira para mapear contexto — use o índice ou leia arquivos específicos
-- Inventar valores de ENV não definidos
-- Recusar contexto de outra área: Dev/TL/PM podem carregar rules de engenharia **e** de produto (autonomia ponta-a-ponta)
-- Perguntar informações que já constam no ENV.md
-- Sugerir tecnologia alternativa não presente no stack identificado no Passo 0.5
-- Assumir topologia de serviços sem consultar ENV ou API de gerenciamento
-
-### Sempre faça
-- Ler ENV.md primeiro, antes de qualquer outra coisa
-- Carregar stack técnico do ENV antes de qualquer workflow (Passo 0.5)
-- Usar context7 para documentação das tecnologias identificadas no stack
-- Consultar API de gerenciamento quando disponível (`*_URL_API` + `*_API_AUTH` no ENV)
-- Usar `$RULES_FOLDER`, `$DOCS_FOLDER`, `$FLOWS_FOLDER` em vez de caminhos hardcoded
-- Exibir o resumo de contexto antes do menu
-- Rotear para o workflow correto sem repetir perguntas já respondidas
-- Ignorar silenciosamente arquivos que não existem
-
----
-
-## Integração com CDD
-
-Se `ENABLE_CDD=true` no ENV.md, **após o usuário selecionar a opção do menu**,
-execute `/jarvis-context-detect` antes de iniciar o workflow escolhido.
-
-Se `ENABLE_CDD=false` ou não definido, prossiga diretamente para o workflow.
-
----
+### Nunca
+- Reler rules (já estão no contexto) ou ler uma pasta inteira
+- Alterar o `ENV.md` ou qualquer configuração persistente
+- Ler `.env*`, chaves ou credenciais
+- Inventar stack, papel ou versão: inferência sempre passa pela validação do usuário
+- Consultar o `context7` sem o MCP ou para mais de 5 ferramentas
 
-## Notas de Versão
-
-| Versão | Mudança |
-|--------|---------|
-| 1.0 | Leitura genérica de `$RULES_FOLDER/` e `$DOCS_FOLDER/` — sem filtro por perfil |
-| 1.1 | Carregamento seletivo por `POSITION` + `HUB`; menu adaptado; integração com CDD |
-| 1.2 | Menu específico para `AREA=ENGINEERING` + `HUB=QA` com roteamento para workflows `eng-qa-*` |
-| 1.3 | Menu QA expandido: sprint planning (G) + release sign-off (H); condição estendida para `POSITION=QUALITY_CHAMPION` |
-| 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.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` |
+### Sempre
+- Uma pergunta por decisão, com `AskUserQuestion` (sem a ferramenta, a tabela de `prod-rules`)
+- Ignorar em silêncio arquivos e passos opcionais que não existem
+- Terminar com o resumo e os próximos comandos