jarvis-ai-framework 3.2.0 → 4.0.0

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

@@ -40,7 +40,7 @@ Estamos nos aproximando de finalizar o trabalho nesta branch e nos preparar para
 | Skills recomendados | `/jarvis-docs-index` | Se for necessário atualizar o índice de documentação |
 | Skills recomendados | `/eng-platform` + `PLATFORM_SPECIALIZATIONS` | Se a feature tiver requisitos não-funcionais de latência, throughput ou escalabilidade |
 | Skills recomendados | `/eng-backend` e `/eng-frontend` (via `eng.specializations-rules.md`) | Para validar código de backend (endpoints, autenticação, workers) ou de frontend (componentes, performance de UI, WCAG 2.1 AA); a regra também carrega as especializações registradas no ENV.md |
-| Gate 0: Verificar Documentação Central | `/jarvis-docs-central` (via `jarvis docs publish --tipo ard`) | Se `CENTRAL_DOCS_REPO` estiver configurado, houver mudança arquitetural, o ARD estiver desatualizado ou novo e o usuário aceitar publicar |
+| Gate 0: Verificar Documentação Central | `/jarvis-docs-central` (via `jarvis docs publish --tipo ard`) | Se `CENTRAL_DOCS_STORAGE` estiver configurado, houver mudança arquitetural, o ARD estiver desatualizado ou novo e o usuário aceitar publicar |
 | Gates › item 1 | `prod.pm-checker` (agente) | Sempre — verificar alinhamento da branch com os docs de produto e engenharia |
 | Gates › item 2 | `eng.dev-code-reviewer` (agente) | Sempre — revisar o código antes de lançar |
 | Gates › item 3 | `eng.qa.test-planner` (agente) | Sempre — identificar gaps de cobertura de testes na branch |
@@ -65,7 +65,7 @@ Estamos nos aproximando de finalizar o trabalho nesta branch e nos preparar para
 
 ### Gate 0: Verificar Documentação Central (condicional)
 
-Se `CENTRAL_DOCS_REPO` estiver configurado no ENV.md:
+Se `CENTRAL_DOCS_STORAGE` estiver configurado no ENV.md:
 
 **Passo 1:** Detectar mudanças arquiteturais no diff da branch
 ```bash
@@ -77,14 +77,14 @@ git diff main...HEAD | grep -E "(class|interface|schema|migration|config)" || tr
 - Comparar com ARD do central-docs (se existir)
 - Se desatualizado ou novo:
   - Perguntar: "Publicar ARD atualizado no central-docs?"
-  - Se sim: executar `jarvis docs publish --file <path> --tipo ard --feature <slug>`
+  - Se sim: executar `jarvis docs publish --file <path> --tipo ard`
 
 **Passo 3:** Se novos contratos/APIs criados:
 - Verificar se há RFC relacionado
 - Se não: sugerir criar RFC para decisões arquiteturais
 
 **Comportamento:**
-- Se `CENTRAL_DOCS_REPO` vazio → pular silenciosamente
+- Se `CENTRAL_DOCS_STORAGE` vazio → pular silenciosamente
 - Não bloquear PR por docs desatualizados (apenas avisar)
 
 ---

package/workflows/engineering/eng.rpa.robot.md

@@ -75,14 +75,16 @@ grep "^ENABLE_CDD=" $IDE/ENV.md
 
 ### 0.3 Criar Branch e Sessão
 
+Pergunte a branch base com `AskUserQuestion` (**"De qual branch partir?"**: `main`, `dev`, `{branch atual}` se for outra, ou Outro) e grave `Branch base:` no `architecture.md` da sessão; o `eng.pr` abre o PR para ela.
+
 ```bash
-git checkout dev && git pull origin dev
+git checkout {BRANCH_BASE} && git pull --ff-only origin {BRANCH_BASE}
 git checkout -b {TASK_MANAGER_KEY}-{robot-tag}
 mkdir -p $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/
 echo "$(date -u +"%Y-%m-%dT%H:%M:%SZ")" > $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/.timestamp_start
 ```
 
-> Branch sempre criada a partir de `dev`. Nunca de `main`/`master`.
+> A base é sempre perguntada: não presuma `dev` nem `main`. A branch de trabalho nunca é a própria base.
 
 ---
 

package/workflows/engineering/eng.start.md

@@ -27,7 +27,7 @@ Este comando inicia o **planejamento** de uma nova feature.
 | Cabeçalho (agente) | `eng.agent` (agente) | Sempre — identidade do workflow |
 | Fase 0.1: Análise de Contexto (CDD) | `/jarvis-context-detect` | Se `ENABLE_CDD=true` no ENV.md (execução obrigatória antes da Fase 1); `ENABLE_CDD=false` pula |
 | Fase 0.5: Advisor (opcional) | `eng.advisor.agent` (agente) | Se o usuário escolher usar o Advisor no alerta e o `architecture.md` tiver questões em aberto (aberto só na primeira questão) |
-| Fase 2.2: Buscar Documentação Central | `/jarvis-docs-central` | Se `CENTRAL_DOCS_REPO` estiver configurado no ENV.md (buscar PRD, ARD e RFCs relacionados) |
+| Fase 2.2: Buscar Documentação Central | `/jarvis-docs-central` | Se `CENTRAL_DOCS_STORAGE` estiver configurado no ENV.md (buscar PRD, ARD e RFCs relacionados) |
 | Fase 3.4: Estratégia de Testes | `eng.qa.test-architect` (agente) | Se a feature tiver requisitos de performance ou segurança (APIs públicas, dados sensíveis, alta carga ou requisitos não-funcionais explícitos) |
 | Fase 3.4: Estratégia de Testes | `/eng-platform` | Se a feature tiver requisitos de performance (latência, throughput, escalabilidade) |
 | Fase 3.4: Estratégia de Testes | `/eng-ai` | Se a feature envolver IA (LLM, RAG, agentes, chatbots, embeddings) |
@@ -135,14 +135,16 @@ Registre a escolha no cabeçalho do `architecture.md` (`Advisor:`). O agente `en
 
 ## Fase 1: Preparação do Ambiente
 
-### 1.1 Criar Branch de Feature (GitFlow)
+### 1.1 Criar Branch de Feature
 
-Crie a branch de trabalho a partir de `dev` seguindo o padrão GitFlow:
+**Pergunte sempre a branch base** com `AskUserQuestion` (sem a ferramenta, use a tabela de `prod-rules.md`): **"De qual branch partir?"** com as opções `main`, `dev` e `{branch atual}` (só se a branch atual for outra), mais "Outro" para digitar. Não presuma `dev` nem `main`: cada projeto tem o seu fluxo.
+
+Grave a escolha no cabeçalho do `architecture.md` (`Branch base:`). O `eng.pr` abre o PR para essa mesma branch.
 
 ```bash
-# Garantir que está em dev e atualizado
-git checkout dev
-git pull origin dev
+# Garantir que a base está atualizada
+git checkout {BRANCH_BASE}
+git pull --ff-only origin {BRANCH_BASE}
 
 # Criar branch no padrão {TASK_MANAGER_KEY}-{titulo-em-kebab-case}
 git checkout -b {TASK_MANAGER_KEY}-{titulo-em-kebab-case}
@@ -175,9 +177,9 @@ git branch --show-current
 | `TASK-123` | "Implementar autenticação JWT" | `TASK-123-implementar-autenticacao-jwt` |
 | `BUG-789` | "Fix null pointer em login" | `BUG-789-fix-null-pointer-em-login` |
 
-> ⚠️ Se o usuário já estiver em uma branch com o padrão correto do TASK_MANAGER_KEY, use-a sem criar nova.
-> ⚠️ **NUNCA** criar branch a partir de `main`/`master`. Sempre a partir de `dev`.
-> ✅ A branch criada aqui será usada em todos os workflows subsequentes (work, pre-pr, pr).
+> ⚠️ Se o usuário já estiver em uma branch com o padrão correto do TASK_MANAGER_KEY, use-a sem criar nova (e ainda assim pergunte a base, para o `eng.pr`).
+> ⚠️ Se o projeto tiver convenção própria de nome de branch (ex.: `CONTRIBUTING.md`), siga a do projeto.
+> ✅ A branch criada aqui será usada em todos os workflows subsequentes (work, pre-pr, pr). Ela é sempre uma branch de trabalho: nunca implemente direto na base.
 
 ### 1.2 Criar Diretório de Sessão
 
@@ -215,7 +217,7 @@ Solicite ao usuário os dados de entrada:
 
 ### 2.2 Buscar Documentação Central (condicional)
 
-Se `CENTRAL_DOCS_REPO` estiver configurado no ENV.md, buscar docs relacionados:
+Se `CENTRAL_DOCS_STORAGE` estiver configurado no ENV.md, buscar docs relacionados:
 
 **Passo 1:** Identificar docs relevantes com base no Jira ID e tags do card
 
@@ -230,7 +232,7 @@ Se `CENTRAL_DOCS_REPO` estiver configurado no ENV.md, buscar docs relacionados:
 **Comportamento:**
 - Se docs encontrados → carregar e exibir resumo
 - Se não encontrados → perguntar se tem docs localmente
-- Se `CENTRAL_DOCS_REPO` vazio → pular silenciosamente
+- Se `CENTRAL_DOCS_STORAGE` vazio → pular silenciosamente
 
 ### 2.3 Análise do Requisito
 
@@ -426,16 +428,15 @@ Quando o usuário aprovar, informe:
 ```
 ✅ Architecture.md criado com sucesso!
 
-🌿 Branch: {TASK_MANAGER_KEY}-{titulo-em-kebab-case} (criada a partir de dev)
+🌿 Branch: {NOME_DA_BRANCH} (criada a partir de {BRANCH_BASE})
 📄 Arquivo: $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/architecture.md
-🌿 Branch:  {NOME_DA_BRANCH}
 
 🔄 Board: mova o card para "Em progresso" no seu board de tarefas.
 
 📌 Próximos passos:
 1. Execute `eng.plan` para criar o plano detalhado de execução
 2. Execute `eng.work` para implementar (commita automaticamente ao final de cada fase)
-3. Execute `eng.pr` para abrir o MR para dev
+3. Execute `eng.pr` para abrir o MR para {BRANCH_BASE}
 
 🚫 Lembre-se: Este workflow NÃO executa código.
    Para implementar, use os comandos de execução.
@@ -452,11 +453,11 @@ Quando o usuário aprovar, informe:
 - ❌ NÃO faça commits
 - ❌ NÃO instale dependências
 - ❌ NÃO modifique arquivos de código existentes
-- ❌ NÃO crie branch a partir de `main`/`master`
+- ❌ NÃO crie a branch sem perguntar a base
 
 ### ✅ FAÇA APENAS
 
-- ✅ Criar branch a partir de `dev` no padrão `{TASK_MANAGER_KEY}-{titulo}`
+- ✅ Criar branch a partir da base escolhida pelo usuário, no padrão `{TASK_MANAGER_KEY}-{titulo}`
 - ✅ Criar o diretório `$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/`
 - ✅ Criar o arquivo `architecture.md`
 - ✅ Investigar e analisar o codebase (leitura apenas)

package/workflows/product/prod.roadmap.preview.md

@@ -3,12 +3,15 @@ name: prod.roadmap.preview
 description: Conhecer e ter visibilidade do roadmap de entregas planejadas do produto, como períodos de entrega, nome dos projetos e responsáveis.
 auto_execution_mode: 3
 env_file: "@/ENV.md"
+recommended_model: opus
 model_tier: high
 model_justification: Gestores e time precisam entender quais as próximas prioridades de entrega que serão feitas pelos times baseados nas informações disponíveis no projeto e também no task manager utilizado pela empresa.
 ---
 
 # Roadmap Preview
 
+> 🎓 **Modo de condução**: leia `PROD_MODE` no `$IDE/ENV.md`. Se for `developer-guided`, **antes de começar leia `$IDE/rules-on-demand/product/prod.guided-rules.md` e siga-o** em toda a conversa. Vazio ou `product-led`: siga este fluxo como está.
+
 Este comando tem como objetivo de buscar e trazer informações sobre o roadmap de entregas planejadas do produto, como períodos de entrega, nome dos projetos e responsáveis.
 
 Antes de iniciar, revise o arquivo de regras invioláveis em `$PROD_RULES/**/*`. Se você não estiver familiarizado com essa variável, leia as regras diretamente na pasta `.$IDE/rules/product/**/*.*`.
@@ -23,7 +26,7 @@ Utilize o `$ARGUMENTS` que o usuário passar como ponto de partida e para entend
 - Sempre identifique o quadrimestre atual e o próximo com base na data de hoje.
 - Utilize o MCP disponível relacionado ao $TASK_MANAGER utilizado pelo usuário.
 - Antes de qualquer coisa, procure por informações sobre o projeto ou produto que o usuário está solicitando dentro da pasta de trabalho utilizado. Confirme com o usuário o que foi encontrado. Utilize também informações que o usuário já compartilhou.
-- As documentações de projeto podem ser encontradas na pasta do projeto (`$PROD_DOCS`). Rascunhos WIP: `$SESSIONS_DIR/prod/`. Caso não estejam disponíveis localmente, utilize via Skill tool a `jarvis-docs-central` para buscar as informações do repositório `$CENTRAL_DOCS_REPO`.
+- As documentações de projeto podem ser encontradas na pasta do projeto (`$PROD_DOCS`). Rascunhos WIP: `$SESSIONS_DIR/prod/`. Caso não estejam disponíveis localmente, utilize via Skill tool a `jarvis-docs-central` para buscar as informações no Central docs (se `CENTRAL_DOCS_STORAGE` estiver configurado).
 - Para trazer as informações, utilize via Skill tool a skill `product-roadmap-report`
 
 ### Status Reports por Squad

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

@@ -3,13 +3,17 @@ name: prod.spec.ard
 description: Ponto de entrada de produto para o ARD (Architecture Requirements Document): levanta com o PM os requisitos arquiteturais em termos de produto e conduz o ARD pelo fluxo de engenharia.
 auto_execution_mode: 3
 env_file: "@/ENV.md"
-recommended_model: gpt-4o
+recommended_model: opus
 model_tier: medium
 model_justification: Levantamento estruturado de requisitos arquiteturais a partir de PRD e FRD, seguido da condução do fluxo de engenharia existente
 ---
 
 # ARD a partir do produto (Architecture Requirements Document)
 
+> 🎓 **Modo de condução**: leia `PROD_MODE` no `$IDE/ENV.md`. Se for `developer-guided`, **antes de começar leia `$IDE/rules-on-demand/product/prod.guided-rules.md` e siga-o** em toda a conversa. Vazio ou `product-led`: siga este fluxo como está.
+>
+> 🤖 **Modelo**: se a IDE informar o modelo desta sessão e ele for de outra família que o `recommended_model` do documento (ou do template, se o documento for novo), avise em uma linha e siga, sem bloquear e sem repetir. Sem essa informação, não avise.
+
 Antes de iniciar, revise o arquivo de regras invioláveis em `$PROD_RULES/**/*`. Se você não estiver familiarizado com essa variável, leia as regras diretamente na pasta `.$IDE/rules/product/**/*.*`.
 
 Este fluxo é a **porta de entrada de produto** para o ARD. Ele levanta com o PM, em linguagem de produto, o que a arquitetura precisa atender (restrições, requisitos não funcionais, integrações, volumes e riscos) e, com isso, **conduz o ARD pelo fluxo de engenharia** (`eng.create-ard`), sem duplicá-lo.
@@ -41,7 +45,7 @@ Utilize o `$ARGUMENTS` que o usuário passar como ponto de partida e para entend
 
 | Passo | Skill | Condição |
 |-------|-------|----------|
-| Gate 1: Reconhecer o contexto | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_REPO` estiver definido no ENV.md e for preciso buscar o PRD ou FRD relacionado |
+| Gate 1: Reconhecer o contexto | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_STORAGE` estiver definido no ENV.md e for preciso buscar o PRD ou FRD relacionado |
 | Gate 4: Conduzir o ARD | `/eng.create-ard` | Sempre, depois de os requisitos serem confirmados: modo `new`, com `--prd` quando houver PRD (workflow de engenharia; o aviso de transição de domínio é dado antes) |
 
 ## Resultado final
@@ -60,7 +64,7 @@ Utilize o `$ARGUMENTS` que o usuário passar como ponto de partida e para entend
 
 ### Gate 1: Reconhecer o contexto
 1. Valide o `ENV.md` (regra geral de produto) e avise que o ARD é um documento de engenharia.
-2. Identifique o PRD ou FRD de origem em `$PROD_DOCS` (ou o caminho que o usuário informar) e leia-o. Se `CENTRAL_DOCS_REPO` estiver definido, busque no central docs o PRD ou FRD relacionado.
+2. Identifique o PRD ou FRD de origem em `$PROD_DOCS` (ou o caminho que o usuário informar) e leia-o. Se `CENTRAL_DOCS_STORAGE` estiver definido, busque no central docs o PRD ou FRD relacionado.
 3. Resuma em poucas linhas o que a especificação pede e confirme com o usuário que é essa a origem. Se `AREA` do usuário não for `ENGINEERING`, avise que o ARD seguirá o fluxo de engenharia e deve ser revisado por alguém da engenharia.
 
 ### Gate 2: Levantar os requisitos arquiteturais em termos de produto

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

@@ -3,13 +3,17 @@ name: prod.spec.breakdown
 description: Quebra uma especificação de produto grande (Documento de Requisitos de Produto ou Documento de Requisitos Funcionais) em fatias gerenciáveis — versões, épicos e histórias — sem perder o objetivo de valor.
 auto_execution_mode: 3
 env_file: "@/ENV.md"
-recommended_model: claude-sonnet-4-20250514
+recommended_model: opus
 model_tier: high
 model_justification: Breakdown de produto exige julgamento de valor, sequenciamento e decomposição em entregas incrementais
 ---
 
 # Quebra de especificação (breakdown)
 
+> 🎓 **Modo de condução**: leia `PROD_MODE` no `$IDE/ENV.md`. Se for `developer-guided`, **antes de começar leia `$IDE/rules-on-demand/product/prod.guided-rules.md` e siga-o** em toda a conversa. Vazio ou `product-led`: siga este fluxo como está.
+>
+> 🤖 **Modelo**: se a IDE informar o modelo desta sessão e ele for de outra família que o `recommended_model` do documento (ou do template, se o documento for novo), avise em uma linha e siga, sem bloquear e sem repetir. Sem essa informação, não avise.
+
 Este comando transforma uma especificação **grande demais para executar de uma vez** em um **plano detalhado (breakdown)**: versões / releases, épicos e esboço de histórias ou tarefas — com foco em **valor perceptível ao usuário**, não só em camadas técnicas.
 
 Antes de iniciar, revise as regras invioláveis em `$PROD_RULES/**/*`. Se a variável for desconhecida, leia `.$IDE/rules/product/**/*.*`.
@@ -48,7 +52,7 @@ Utilize o `$ARGUMENTS` como ponto de partida (caminho da spec, nome da feature o
 |-------|-------|----------|
 | Pré-requisitos (item 2) | `/prod.spec.prd` | Se não houver spec pai e o usuário aceitar criar o PRD |
 | Pré-requisitos (item 2) | `/prod.spec.frd` | Se não houver spec pai e o usuário aceitar criar o FRD |
-| Busca no Central Docs (condicional) | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_REPO` estiver no ENV.md (best-effort) |
+| Busca no Central Docs (condicional) | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_STORAGE` estiver no ENV.md (best-effort) |
 | Resultado esperado (materialização) | `/prod.spec.epic` | Se o usuário aprovar criar os arquivos de épico a partir do breakdown (nunca automaticamente) |
 | Resultado esperado (materialização) | `/prod.spec.issue` | Se o usuário aprovar criar os arquivos de história ou tarefa a partir do breakdown (nunca automaticamente) |
 
@@ -58,7 +62,7 @@ O artefato de breakdown segue o template `$PROD_TEMPLATES/prod-breakdown-templat
 
 ## Busca no Central Docs (condicional)
 
-Se `CENTRAL_DOCS_REPO` estiver no `ENV.md`:
+Se `CENTRAL_DOCS_STORAGE` estiver no `ENV.md`:
 
 1. `jarvis docs sync --silent` (best-effort)
 2. Localizar Documento de Requisitos de Produto / funcional relacionado (nome, tags, `TASK_MANAGER_KEY`)

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

@@ -3,13 +3,17 @@ name: prod.spec.clarify
 description: Identificar áreas subespecificadas na especificação da feature atual fazendo até 5 perguntas de esclarecimento altamente direcionadas e incorporando as respostas de volta na spec.
 auto_execution_mode: 3
 env_file: "@/ENV.md"
-recommended_model: gpt-4o
+recommended_model: opus
 model_tier: medium
 model_justification: Esclarecimento de specs requer análise estruturada e formulação de perguntas, mas segue processo bem definido
 ---
 
 ## Clarify workflow
 
+> 🎓 **Modo de condução**: leia `PROD_MODE` no `$IDE/ENV.md`. Se for `developer-guided`, **antes de começar leia `$IDE/rules-on-demand/product/prod.guided-rules.md` e siga-o** em toda a conversa. Vazio ou `product-led`: siga este fluxo como está.
+>
+> 🤖 **Modelo**: se a IDE informar o modelo desta sessão e ele for de outra família que o `recommended_model` do documento (ou do template, se o documento for novo), avise em uma linha e siga, sem bloquear e sem repetir. Sem essa informação, não avise.
+
 Detectar e reduzir ambiguidades ou pontos de decisão ausentes na especificação da feature ativa e registrar os esclarecimentos diretamente no arquivo da spec.
 
 Rascunhos WIP (se houver) em `$SESSIONS_DIR/prod/{TASK_MANAGER_KEY}/`. O heading `### Session YYYY-MM-DD` é um log **dentro da spec canônica** — não é a pasta `$SESSIONS_DIR`.

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

@@ -3,13 +3,17 @@ name: prod.spec.discovery
 description: Investigação inicial de uma ideia: entrevista o usuário sobre a ideia, o problema, os requisitos iniciais e a viabilidade, sem chutar, e registra um rascunho estruturado com veredito e próximo passo sugerido.
 auto_execution_mode: 3
 env_file: "@/ENV.md"
-recommended_model: claude-sonnet-4-20250514
+recommended_model: opus
 model_tier: high
 model_justification: Discovery exige conduzir uma entrevista adaptativa, julgar evidências e registrar hipóteses sem presumir dados
 ---
 
 # Discovery (investigação inicial de uma ideia)
 
+> 🎓 **Modo de condução**: leia `PROD_MODE` no `$IDE/ENV.md`. Se for `developer-guided`, **antes de começar leia `$IDE/rules-on-demand/product/prod.guided-rules.md` e siga-o** em toda a conversa. Vazio ou `product-led`: siga este fluxo como está.
+>
+> 🤖 **Modelo**: se a IDE informar o modelo desta sessão e ele for de outra família que o `recommended_model` do documento (ou do template, se o documento for novo), avise em uma linha e siga, sem bloquear e sem repetir. Sem essa informação, não avise.
+
 Este comando conduz uma **entrevista** para investigar uma ideia ainda crua e registrar o resultado em um **rascunho estruturado**: o problema, o que precisaria ser verdade e se parece viável.
 
 Antes de iniciar, revise as regras invioláveis em `$PROD_RULES/**/*`.
@@ -44,7 +48,7 @@ O comando e o agente seguem obrigatoriamente `$PROD_RULES` (`prod-rules.md`):
 | Passo | Skill | Condição |
 |-------|-------|----------|
 | Regras do framework / Passo 4 — A entrevista | `prod.discovery-interviewer` (agente) | Sempre — conduz a entrevista, e o comando segue a postura dele |
-| Passo 2 — Reconhecer o projeto | `/jarvis-docs-central` | Se `CENTRAL_DOCS_REPO` estiver configurado |
+| Passo 2 — Reconhecer o projeto | `/jarvis-docs-central` | Se `CENTRAL_DOCS_STORAGE` estiver configurado |
 | Passo 2 — Reconhecer o projeto | `/jarvis-context-detect` | Para calibrar a profundidade da entrevista |
 | Passo 2 — Reconhecer o projeto | `/eng-backend-arch-c4` | Só com a confirmação do usuário; o retorno é tratado como suposição a validar |
 | Passo 2 — Reconhecer o projeto | `/eng-platform` + `PLATFORM_SPECIALIZATIONS` | Só com a confirmação do usuário; o retorno é tratado como suposição a validar |
@@ -70,7 +74,7 @@ Antes de perguntar, consulte o que já existe:
 
 - Documentos em `$PROD_DOCS` (PRDs, FRDs e discoveries), para não duplicar o que já está especificado
 - O código e os últimos commits, quando ajudarem a embasar a viabilidade
-- `jarvis-docs-central`, se `CENTRAL_DOCS_REPO` estiver configurado
+- `jarvis-docs-central`, se `CENTRAL_DOCS_STORAGE` estiver configurado
 - `jarvis-context-detect`, para calibrar a profundidade da entrevista
 - `eng-backend-arch-c4` e `eng-platform` (+ `PLATFORM_SPECIALIZATIONS`) são skills de engenharia: só consulte **com a confirmação do usuário**, e trate o retorno como **suposição a validar**, não como fato
 

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

@@ -3,13 +3,17 @@ name: prod.spec.epic
 description: Fluxo de trabalho para criação de épicos que agrupam histórias de usuários e tarefas relacionadas seguindo as diretrizes do Product Spec Kit.
 auto_execution_mode: 3
 env_file: "@/ENV.md"
-recommended_model: gpt-4o
+recommended_model: opus
 model_tier: medium
 model_justification: Criação de épicos segue templates estruturados e requer compreensão de contexto de produto
 ---
 
 # Crie um fluxo de trabalho épico
 
+> 🎓 **Modo de condução**: leia `PROD_MODE` no `$IDE/ENV.md`. Se for `developer-guided`, **antes de começar leia `$IDE/rules-on-demand/product/prod.guided-rules.md` e siga-o** em toda a conversa. Vazio ou `product-led`: siga este fluxo como está.
+>
+> 🤖 **Modelo**: se a IDE informar o modelo desta sessão e ele for de outra família que o `recommended_model` do documento (ou do template, se o documento for novo), avise em uma linha e siga, sem bloquear e sem repetir. Sem essa informação, não avise.
+
 Antes de iniciar, revise o arquivo de regras invioláveis em `$PROD_RULES/**/*`. Se você não estiver familiarizado com essa variável, leia as regras diretamente na pasta `.$IDE/rules/product/**/*.*`.
 
 Este fluxo de trabalho orienta você na criação de um épico usando `$PROD_TEMPLATES/prod-epic-template.md`. épicos agrupam histórias de usuários relacionadas que oferecem uma funcionalidade significativa.
@@ -37,9 +41,9 @@ Utilize o `$ARGUMENTS` que o usuário passar como ponto de partida e para entend
 
 | Passo | Skill | Condição |
 |-------|-------|----------|
-| Busca no Central Docs (condicional) | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_REPO` estiver definido no ENV.md, antes de criar o épico |
+| Busca no Central Docs (condicional) | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_STORAGE` estiver definido no ENV.md, antes de criar o épico |
 | Próximas etapas | `/prod.spec.issue` | Depois de criar o épico, se o usuário quiser escrever as histórias ou tarefas relacionadas |
-| Publicação no Central Docs (condicional) | `/jarvis-docs-central` (via `jarvis docs publish --tipo epic`) | Se `CENTRAL_DOCS_REPO` estiver definido, o épico estiver salvo e aprovado e o usuário responder "Sim, publicar agora" |
+| Publicação no Central Docs (condicional) | `/jarvis-docs-central` (via `jarvis docs publish --tipo epic`) | Se `CENTRAL_DOCS_STORAGE` estiver definido, o épico estiver salvo e aprovado e o usuário responder "Sim, publicar agora" |
 
 ## Resultado final
 - Por padrão, use o modelo `$PROD_TEMPLATES/prod-epic-template.md` integralmente
@@ -118,7 +122,7 @@ Após a aprovação do usuário:
 
 ## Busca no Central Docs (condicional)
 
-Se `CENTRAL_DOCS_REPO` definido no ENV.md, antes de criar o épico:
+Se `CENTRAL_DOCS_STORAGE` definido no ENV.md, antes de criar o épico:
 
 - Executar busca automática no central-docs:
   ```bash
@@ -132,7 +136,7 @@ Se `CENTRAL_DOCS_REPO` definido no ENV.md, antes de criar o épico:
 
 Após salvar o épico localmente e obter aprovação do usuário:
 
-1. Se `CENTRAL_DOCS_REPO` definido no ENV.md:
+1. Se `CENTRAL_DOCS_STORAGE` definido no ENV.md:
    - Perguntar ao usuário:
      ```
      Deseja publicar este épico no repositório central de documentação?
@@ -141,23 +145,21 @@ Após salvar o épico localmente e obter aprovação do usuário:
      ```
 
 2. Se **Sim**:
-   - Extrair o slug do nome do arquivo (ex: `epic-123-checkout.md` → `checkout`)
    - Executar:
      ```bash
      jarvis docs publish \
        --file {caminho_do_epico} \
-       --tipo epic \
-       --feature {slug}
+       --tipo epic
      ```
 
 3. Informar resultado:
-   - ✅ Sucesso: "Épico publicado no central-docs. MR criado: [URL]"
+   - ✅ Sucesso: "Épico publicado no Central docs." (com git: "PR aberto: [URL]")
    - ❌ Erro: Exibir mensagem de erro e orientar troubleshooting
 
 4. Se **Não**:
-   - Informar: "Para publicar depois, execute: `jarvis docs publish --file {caminho} --tipo epic --feature {slug}`"
+   - Informar: "Para publicar depois, execute: `jarvis docs publish --file {caminho} --tipo epic`"
 
-> **Nota**: A publicação cria um Merge Request no GitLab. O épico só será visível no central-docs após aprovação e merge do MR.
+> **Nota**: se a pasta do Central docs for um repositório git, a publicação abre um Pull/Merge Request e o épico só entra na branch base depois do merge. Sem git, o documento é gravado direto e o índice é regenerado.
 
 Utilize o que o usuário fornecer analisar em:
 <requirement>

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

@@ -3,13 +3,17 @@ name: prod.spec.frd
 description: Fluxo para criação de FRD (Functional Requirements Document), que auxilia na definição detalhada dos requisitos funcionais de uma feature
 auto_execution_mode: 3
 env_file: "@/ENV.md"
-recommended_model: claude-sonnet-4-20250514
+recommended_model: opus
 model_tier: high
 model_justification: FRDs requerem análise detalhada de requisitos funcionais, comportamento de usuário e especificações técnicas
 ---
 
 # FRD - Functional Requirements Document
 
+> 🎓 **Modo de condução**: leia `PROD_MODE` no `$IDE/ENV.md`. Se for `developer-guided`, **antes de começar leia `$IDE/rules-on-demand/product/prod.guided-rules.md` e siga-o** em toda a conversa. Vazio ou `product-led`: siga este fluxo como está.
+>
+> 🤖 **Modelo**: se a IDE informar o modelo desta sessão e ele for de outra família que o `recommended_model` do documento (ou do template, se o documento for novo), avise em uma linha e siga, sem bloquear e sem repetir. Sem essa informação, não avise.
+
 Este comando tem como objetivo criar, atualizar ou editar uma FRD seguindo o template especificado e as instruções.
 
 Antes de iniciar, revise o arquivo de regras invioláveis em `$PROD_RULES/**/*`. Se você não estiver familiarizado com essa variável, leia as regras diretamente na pasta `.$IDE/rules/product/**/*.*`.
@@ -30,8 +34,8 @@ Utilize o `$ARGUMENTS` que o usuário passar como ponto de partida e para entend
 
 | Passo | Skill | Condição |
 |-------|-------|----------|
-| Busca no Central Docs (condicional) | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_REPO` estiver definido no ENV.md |
-| Publicação no Central Docs (condicional) | `/jarvis-docs-central` (via `jarvis docs publish --tipo frd`) | Se `CENTRAL_DOCS_REPO` estiver definido, o FRD estiver salvo e aprovado e o usuário responder "Sim, publicar agora" |
+| Busca no Central Docs (condicional) | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_STORAGE` estiver definido no ENV.md |
+| Publicação no Central Docs (condicional) | `/jarvis-docs-central` (via `jarvis docs publish --tipo frd`) | Se `CENTRAL_DOCS_STORAGE` estiver definido, o FRD estiver salvo e aprovado e o usuário responder "Sim, publicar agora" |
 
 ## Princípios Fundamentais
 1. **Sempre use o template** `$PROD_TEMPLATES/prod-frd-template.md` para o output final
@@ -56,7 +60,7 @@ A FRD não é um épico, história ou task: ela serve como documento de detalham
 
 ## Busca no Central Docs (condicional)
 
-Se `CENTRAL_DOCS_REPO` definido no ENV.md:
+Se `CENTRAL_DOCS_STORAGE` definido no ENV.md:
 
 1. **Buscar PRD correspondente:**
    - Executar busca automática no central-docs:
@@ -187,7 +191,7 @@ O sistema deve validar os dados do formulário.
 
 Após salvar o FRD localmente e obter aprovação do usuário:
 
-1. Se `CENTRAL_DOCS_REPO` definido no ENV.md:
+1. Se `CENTRAL_DOCS_STORAGE` definido no ENV.md:
    - Perguntar ao usuário:
      ```
      Deseja publicar este FRD no repositório central de documentação?
@@ -196,23 +200,21 @@ Após salvar o FRD localmente e obter aprovação do usuário:
      ```
 
 2. Se **Sim**:
-   - Extrair o slug do nome do arquivo (ex: `frd-wallet-saque.md` → `wallet-saque`)
    - Executar:
      ```bash
      jarvis docs publish \
        --file {caminho_do_frd} \
-       --tipo frd \
-       --feature {slug}
+       --tipo frd
      ```
 
 3. Informar resultado:
-   - ✅ Sucesso: "FRD publicado no central-docs. MR criado: [URL]"
+   - ✅ Sucesso: "FRD publicado no Central docs." (com git: "PR aberto: [URL]")
    - ❌ Erro: Exibir mensagem de erro e orientar troubleshooting
 
 4. Se **Não**:
-   - Informar: "Para publicar depois, execute: `jarvis docs publish --file {caminho} --tipo frd --feature {slug}`"
+   - Informar: "Para publicar depois, execute: `jarvis docs publish --file {caminho} --tipo frd`"
 
-5. Se `CENTRAL_DOCS_REPO` não estiver definido:
-   - Informar: "Para habilitar publicação automática, configure `CENTRAL_DOCS_REPO` no ENV.md"
+5. Se `CENTRAL_DOCS_STORAGE` não estiver definido:
+   - Informar: "Para habilitar publicação automática, configure o Central docs no `/jarvis-init` (`CENTRAL_DOCS_STORAGE`)"
 
-> **Nota**: A publicação cria um Merge Request no GitLab. O FRD só será visível no central-docs após aprovação e merge do MR.
+> **Nota**: se a pasta do Central docs for um repositório git, a publicação abre um Pull/Merge Request e o FRD só entra na branch base depois do merge. Sem git, o documento é gravado direto e o índice é regenerado.

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

@@ -3,13 +3,17 @@ name: prod.spec.issue
 description: Criar um especificação de issues como Histórias de Usuário, Tarefas técnicas e bugs, seguindo as melhores práticas de gestão de produto e projeto.
 auto_execution_mode: 3
 env_file: "@/ENV.md"
-recommended_model: gpt-4o
+recommended_model: opus
 model_tier: medium
 model_justification: Criação de issues é estruturada e segue templates, requer boa compreensão mas não raciocínio extremamente complexo
 ---
 
 # Fluxo de Criação de Issues
 
+> 🎓 **Modo de condução**: leia `PROD_MODE` no `$IDE/ENV.md`. Se for `developer-guided`, **antes de começar leia `$IDE/rules-on-demand/product/prod.guided-rules.md` e siga-o** em toda a conversa. Vazio ou `product-led`: siga este fluxo como está.
+>
+> 🤖 **Modelo**: se a IDE informar o modelo desta sessão e ele for de outra família que o `recommended_model` do documento (ou do template, se o documento for novo), avise em uma linha e siga, sem bloquear e sem repetir. Sem essa informação, não avise.
+
 Antes de iniciar, revise o arquivo de regras invioláveis em `$PROD_RULES/**/*.*`.
 
 Este fluxo orienta você na criação de issues (histórias de usuários, tarefas, bugs etc) bem definidas usando o template `$PROD_TEMPLATES/prod-issue-template.md`. Cada issue deve ser uma unidade de trabalho autocontida que pode ser completada dentro de uma única sprint.

package/workflows/product/prod.spec.md

@@ -3,13 +3,15 @@ name: prod.spec
 description: Guia o usuário para construir especificações macro ou micro de produto, como PRDs, histórias, tarefas, RFDs e outros.
 auto_execution_mode: 3
 env_file: "@/ENV.md"
-recommended_model: claude-sonnet-4-20250514
+recommended_model: opus
 model_tier: medium
 model_justification: Especificações de produto requerem compreensão de requisitos e estruturação de documentos
 ---
 
 # Iniciar uma especificação
 
+> 🎓 **Modo de condução**: leia `PROD_MODE` no `$IDE/ENV.md`. Se for `developer-guided`, **antes de começar leia `$IDE/rules-on-demand/product/prod.guided-rules.md` e siga-o** em toda a conversa. Vazio ou `product-led`: siga este fluxo como está.
+
 Estas instruções ajudam a orientar o usuário que deseja começar a construir uma especificação. Esta especificação pode variar desde um PRD, história de usuário até tarefas. Devemos orientá-lo nessa construção de forma que a especificação, seja ela macro ou micro seja criada de acordo com as instruções e padrões do projeto.
 
 ## Quando usar

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

@@ -3,13 +3,17 @@ name: prod.spec.prd
 description: Alterar ou criar um especificação de produto PRD - Product Requirement Document seguindo o template especificado, regras invioláveis, possibilitando a utilização por agentes de IA e humanos.
 auto_execution_mode: 3
 env_file: "@/ENV.md"
-recommended_model: claude-sonnet-4-20250514
+recommended_model: opus
 model_tier: high
 model_justification: PRDs requerem análise profunda de requisitos, estruturação de documentos complexos e compreensão de contexto de negócio
 ---
 
 # PRD - Product Requirement Document
 
+> 🎓 **Modo de condução**: leia `PROD_MODE` no `$IDE/ENV.md`. Se for `developer-guided`, **antes de começar leia `$IDE/rules-on-demand/product/prod.guided-rules.md` e siga-o** em toda a conversa. Vazio ou `product-led`: siga este fluxo como está.
+>
+> 🤖 **Modelo**: se a IDE informar o modelo desta sessão e ele for de outra família que o `recommended_model` do documento (ou do template, se o documento for novo), avise em uma linha e siga, sem bloquear e sem repetir. Sem essa informação, não avise.
+
 Este comando tem como objetivo criar, atualizar ou editar uma PRD seguindo o template especificado e as instruções.
 
 Antes de iniciar, revise o arquivo de regras invioláveis em `$PROD_RULES/**/*`. Se você não estiver familiarizado com essa variável, leia as regras diretamente na pasta `.$IDE/rules/product/**/*.*`.
@@ -29,8 +33,8 @@ Utilize o `$ARGUMENTS` que o usuário passar como ponto de partida e para entend
 
 | Passo | Skill | Condição |
 |-------|-------|----------|
-| Busca no Central Docs (condicional) | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_REPO` estiver definido no ENV.md (iteração de PRD existente) |
-| Publicação no Central Docs (condicional) | `/jarvis-docs-central` (via `jarvis docs publish --tipo prd`) | Se `CENTRAL_DOCS_REPO` estiver definido, o PRD estiver salvo e aprovado e o usuário responder "Sim, publicar agora" |
+| Busca no Central Docs (condicional) | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_STORAGE` estiver definido no ENV.md (iteração de PRD existente) |
+| Publicação no Central Docs (condicional) | `/jarvis-docs-central` (via `jarvis docs publish --tipo prd`) | Se `CENTRAL_DOCS_STORAGE` estiver definido, o PRD estiver salvo e aprovado e o usuário responder "Sim, publicar agora" |
 
 ## Princípios Fundamentais
 1. **Sempre use o template** `$PROD_TEMPLATES/prod-prd-template.md` para o output final
@@ -41,7 +45,7 @@ Utilize o `$ARGUMENTS` que o usuário passar como ponto de partida e para entend
 
 ## Busca no Central Docs (condicional)
 
-Se `CENTRAL_DOCS_REPO` definido no ENV.md:
+Se `CENTRAL_DOCS_STORAGE` definido no ENV.md:
 
 1. **Para iteração de PRD existente:**
    - Executar busca automática no central-docs:
@@ -174,7 +178,7 @@ Quais métricas? A) Engajamento B) Receita C) Outro
 
 Após salvar o PRD localmente e obter aprovação do usuário:
 
-1. Se `CENTRAL_DOCS_REPO` definido no ENV.md:
+1. Se `CENTRAL_DOCS_STORAGE` definido no ENV.md:
    - Perguntar ao usuário:
      ```
      Deseja publicar este PRD no repositório central de documentação?
@@ -183,24 +187,22 @@ Após salvar o PRD localmente e obter aprovação do usuário:
      ```
 
 2. Se **Sim**:
-   - Extrair o slug do nome do arquivo (ex: `prd-wallet.md` → `wallet`)
    - Executar:
      ```bash
      jarvis docs publish \
        --file {caminho_do_prd} \
-       --tipo prd \
-       --feature {slug}
+       --tipo prd
      ```
 
 3. Informar resultado:
-   - ✅ Sucesso: "PRD publicado no central-docs. MR criado: [URL]"
+   - ✅ Sucesso: "PRD publicado no Central docs." (com git: "PR aberto: [URL]")
    - ❌ Erro: Exibir mensagem de erro e orientar troubleshooting
 
 4. Se **Não**:
-   - Informar: "Para publicar depois, execute: `jarvis docs publish --file {caminho} --tipo prd --feature {slug}`"
+   - Informar: "Para publicar depois, execute: `jarvis docs publish --file {caminho} --tipo prd`"
 
-5. Se `CENTRAL_DOCS_REPO` não estiver definido:
-   - Informar: "Para habilitar publicação automática, configure `CENTRAL_DOCS_REPO` no ENV.md"
+5. Se `CENTRAL_DOCS_STORAGE` não estiver definido:
+   - Informar: "Para habilitar publicação automática, configure o Central docs no `/jarvis-init` (`CENTRAL_DOCS_STORAGE`)"
 
-> **Nota**: A publicação cria um Merge Request no GitLab. O PRD só será visível no central-docs após aprovação e merge do MR.
+> **Nota**: se a pasta do Central docs for um repositório git, a publicação abre um Pull/Merge Request e o PRD só entra na branch base depois do merge. Sem git, o documento é gravado direto e o índice é regenerado.
 

package/workflows/warm-up.md

@@ -19,7 +19,7 @@ evitando leitura desnecessária de arquivos e economizando tokens.
 | 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_REPO` estiver configurado no ENV.md (Modo 1: Buscar Docs, via Skill tool) |
+| 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) |
@@ -129,7 +129,7 @@ O perfil de comunicação é derivado de `POSITION` (conforme definido no `$IDE/
 
 ## Passo 2 — Sincronizar Documentação Central (condicional)
 
-Se `CENTRAL_DOCS_REPO` estiver configurado no ENV.md, invocar o skill `jarvis-docs-central` via Skill tool para carregar docs do produto.
+Se `CENTRAL_DOCS_STORAGE` estiver configurado no ENV.md, invocar o skill `jarvis-docs-central` via Skill tool para carregar docs do produto.
 
 > ⚠️ **IMPORTANTE**: NÃO executar `jarvis docs sync` diretamente via Bash.
 > Usar sempre: **Skill tool → jarvis-docs-central (Modo 1: Buscar Docs)**
@@ -158,7 +158,7 @@ Contexto: warm-up - sincronização inicial
 ```
 
 **Comportamento:**
-- Se `CENTRAL_DOCS_REPO` vazio → pula silenciosamente
+- Se `CENTRAL_DOCS_STORAGE` vazio → pula silenciosamente
 - Se erro de token → exibe aviso mas continua
 - Se `index.md` não existe → navega estrutura do repo e lista docs disponíveis
 - Se erro genérico → exibe mensagem clara e continua sem bloquear