jarvis-ai-framework 3.0.0 → 4.0.0

package/workflows/engineering/eng.work.md

@@ -25,7 +25,6 @@ Este comando executa a **implementação de código** seguindo o plano de execu
 |-------|-------|----------|
 | Cabeçalho (agente) | `eng.agent` (agente) | Sempre — identidade do workflow |
 | Fase 0 › 0.1 Verificar ou Gerar Contexto da Sessão | `/jarvis-context-detect` | Se `ENABLE_CDD=true` e o `context.md` não existir (obrigatório antes da Fase 1) |
-| Fase 0.5: Comentário no card — Início | `/eng-global-task-comment` | Se `TASK_MANAGER` estiver preenchido (freelance pula) |
 | Fase 3 › 3.1 Implementar Código (skill de domínio) | `/eng-frontend` (via `eng.specializations-rules.md`) | Se o domínio da feature for frontend (componentes, UI, estado, estilos, bundle, a11y); a regra também carrega `FRONTEND_SPECIALIZATIONS` |
 | Fase 3 › 3.1 Implementar Código (skill de domínio) | `/eng-backend` (via `eng.specializations-rules.md`) | Se o domínio da feature for backend (endpoints, auth, workers, filas, cache, banco, integrações); a regra também carrega `BACKEND_SPECIALIZATIONS` |
 | Fase 3 › 3.1 Implementar Código (skill de domínio) | `/eng-automation` (via `eng.specializations-rules.md`) | Se o domínio da feature for RPA, scraping, extração de dados, ETL ou parsing; a regra também carrega `AUTOMATION_SPECIALIZATIONS` |
@@ -33,7 +32,8 @@ Este comando executa a **implementação de código** seguindo o plano de execu
 | Fase 3 › 3.3.1 Identificar Gaps de Teste | `eng.qa.test-planner` (agente) | Sempre, depois de implementar o código da fase |
 | Fase 3 › 3.3.2 Implementar Testes Faltantes (Opção A) | `eng.qa.testing-engineer` (agente) | Se o test-planner identificar gaps e a estratégia do `architecture.md` seção 6.5 indicar testes manuais (unitário/integração) |
 | Fase 3 › 3.3.2 Implementar Testes Faltantes (Opção B) | `/eng-qa` | Se a estratégia do `architecture.md` seção 6.5 indicar uma especialização registrada em `QA_SPECIALIZATIONS` |
-| Fase 6 › 6.2 Se Todas as Fases Foram Concluídas | `/eng-global-task-comment` | Se `TASK_MANAGER` estiver preenchido e todas as fases estiverem concluídas (freelance pula) |
+| Fase 3 › 3.1 Implementar Código (exceção) | `eng.advisor.agent` (agente) | Só por exceção: questão nova em aberto, com o Advisor habilitado no `eng.start` (cabeçalho do `architecture.md`) |
+| Fase 5 › 5.4 e "Se houver bloqueio técnico" | `/eng-global-task-comment` | Se houver desvio do plano: mudança de direção, fase bloqueada ou questão nova consultada ao Advisor (freelance pula) |
 
 ---
 
@@ -152,20 +152,6 @@ Use as características do projeto detectadas:
 
 ---
 
-## Fase 0.5: Comentário no card — Início
-
-Pular se `TASK_MANAGER` estiver vazio (freelance).
-
-Antes de iniciar a implementação, registrar início:
-
-```
-/eng-global-task-comment {TASK_MANAGER_KEY} ⚙️ [Jarvis] Iniciando implementação - Fase {N} do plano
-```
-
-> Usa o skill `/eng-global-task-comment`. Não bloquear se falhar.
-
----
-
 ## Fase 1: Leitura da Sessão
 
 ### 1.1 Carregar Arquivos
@@ -250,6 +236,8 @@ Para cada tarefa da fase:
    - Testes unitários para cada função/método
    - Cobrir casos de sucesso e erro
 
+**Questão nova em aberto (exceção).** O ideal é que todas as questões tenham sido levantadas no `eng.start`. Se surgir uma nova e o cabeçalho do `architecture.md` indicar um Advisor, consulte `eng.advisor.agent` com o Prompt 2 de `$IDE/templates/engineering/advisor-template.md` (refaça o Prompt 1 se o subagente não existir mais), acrescente a questão à seção 8 marcada "levantada no `eng.work`", adote a sugestão do Advisor e poste o comentário de auditoria com `/eng-global-task-comment` (é desvio do plano; cite-o no PR como lacuna do `eng.start`). Sem Advisor, pergunte ao usuário.
+
 ### 3.2 Executar Validações Locais
 
 Após implementar:
@@ -429,6 +417,8 @@ Atualize o `plan.md`:
 - **Atenção**: {ponto importante para próximas fases}
 ```
 
+Se o comentário registrar uma **mudança de direção** (desvio do plano), comente também no card com `/eng-global-task-comment`, dizendo o que mudou e por quê (freelance pula).
+
 ### 5.3 Commit da Fase (GitFlow)
 
 Após validação do usuário e atualização do `plan.md`, commitar a fase na branch atual:
@@ -494,12 +484,6 @@ Refs: TASK-123"
 
 ### 6.2 Se Todas as Fases Foram Concluídas
 
-**Comentário no card — Conclusão** (pular se freelance):
-
-```
-/eng-global-task-comment {TASK_MANAGER_KEY} ✅ [Jarvis] Implementação concluída - todas as {N} fases completadas. Commits realizados por fase.
-```
-
 ```
 🎉 TODAS AS FASES CONCLUÍDAS!
 
@@ -559,5 +543,6 @@ Refs: TASK-123"
 ### Se houver bloqueio técnico:
 
 → Documente no plan.md como `[Bloqueada 🚫]`
+→ Comente o bloqueio no card com `/eng-global-task-comment` (desvio do plano; freelance pula)
 → Explique o bloqueio ao usuário
 → Sugira alternativas se possível

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

package/bin/lib/docs/redis-cache.js

@@ -1,49 +0,0 @@
-/**
- * @fileoverview Cache best-effort via `redis-cli` para fetch-file.js/publish-file.js.
- * Nunca lança — falha de leitura/escrita no cache nunca quebra o fluxo principal
- * (mesmo contrato do `fetch-file.sh`/`publish-file.sh` originais, que faziam
- * `redis-cli ... 2>/dev/null || true`).
- * @module docs/redis-cache
- */
-
-import { execFileSync } from "node:child_process";
-
-/**
- * @param {string} key
- * @returns {string} valor em cache, ou "" se não houver (ou `redis-cli` falhar)
- */
-export function redisGet(key) {
-  try {
-    return execFileSync("redis-cli", ["GET", key], {
-      encoding: "utf-8",
-      stdio: ["ignore", "pipe", "ignore"],
-    }).trim();
-  } catch {
-    return "";
-  }
-}
-
-/**
- * @param {string} key
- * @param {string|number} ttlSeconds
- * @param {string} value
- */
-export function redisSetex(key, ttlSeconds, value) {
-  try {
-    execFileSync("redis-cli", ["-x", "SETEX", key, String(ttlSeconds)], {
-      input: value,
-      stdio: ["pipe", "ignore", "ignore"],
-    });
-  } catch {
-    // best-effort
-  }
-}
-
-/** @param {string} key */
-export function redisDel(key) {
-  try {
-    execFileSync("redis-cli", ["DEL", key], { stdio: "ignore" });
-  } catch {
-    // best-effort
-  }
-}

package/bin/lib/vcs/fetch-raw.js

@@ -1,42 +0,0 @@
-import { fileURLToPath } from "node:url";
-import { fetchRawFile } from "./api.js";
-
-/**
- * Busca o conteúdo bruto de um arquivo no central-docs via adapter.
- * Usada por `jarvis vcs fetch-raw`.
- * @param {string} filePath - Path do arquivo dentro do repo central-docs
- * @param {string} [ref] - Branch/ref (padrão: "main")
- */
-export async function runFetchRaw(filePath, ref = "main") {
-  const repo = process.env.CENTRAL_DOCS_REPO;
-
-  if (!filePath) {
-    console.error("Uso: jarvis vcs fetch-raw <file-path> [ref]");
-    process.exit(1);
-  }
-  if (!repo) {
-    console.error("CENTRAL_DOCS_REPO não definido");
-    process.exit(1);
-  }
-
-  try {
-    const content = await fetchRawFile(repo, filePath, ref);
-    process.stdout.write(content);
-  } catch (err) {
-    if (err.code === 404) {
-      console.error(`⚠️  Arquivo não encontrado no central-docs: ${filePath}`);
-      process.exit(2);
-    }
-    if (err.code === 401 || err.code === 403) {
-      console.error("❌ Token sem permissão para acessar o repositório");
-      process.exit(1);
-    }
-    console.error(err.message);
-    process.exit(1);
-  }
-}
-
-// Compatibilidade: continua funcionando como `node bin/lib/vcs/fetch-raw.js <file-path> [ref]`
-if (fileURLToPath(import.meta.url) === process.argv[1]) {
-  await runFetchRaw(process.argv[2], process.argv[3] || "main");
-}