jarvis-ai-framework 3.2.0 → 5.0.0

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

@@ -3,18 +3,22 @@ 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.
 
-> ⚠️ **O ARD é um documento de engenharia.** O arquivo resultante fica em `$DOCS_FOLDER/engineering/ARD/` (como no `eng.create-ard`), e as decisões de arquitetura pertencem à engenharia. Este comando só levanta os requisitos e abre o fluxo. Diga isso ao usuário no início.
+> ⚠️ **O ARD é um documento de engenharia.** O arquivo resultante fica em `$ENG_DOCS/ARD/` (como no `eng.create-ard`), e as decisões de arquitetura pertencem à engenharia. Este comando só levanta os requisitos e abre o fluxo. Diga isso ao usuário no início.
 
 Utilize o `$ARGUMENTS` que o usuário passar como ponto de partida e para entender o contexto do que foi pedido.
 <requirement>
@@ -41,12 +45,12 @@ 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 conhecer as funcionalidades já implementadas relacionadas |
 | 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
 - Um **resumo dos requisitos arquiteturais** confirmado pelo usuário (Gate 3), entregue como insumo ao `eng.create-ard`
-- O **ARD** gerado pelo `eng.create-ard` (numeração `ARD-###`, versão `1.0.0`, template `$IDE/templates/engineering/ARD-template.md` e caminho `$DOCS_FOLDER/engineering/ARD/{ARD-ID}-{slug}.md`)
+- O **ARD** gerado pelo `eng.create-ard` (numeração `ARD-###`, versão `1.0.0`, template `$IDE/templates/engineering/ARD-template.md` e caminho `$ENG_DOCS/ARD/{ARD-ID}-{slug}.md`)
 - Rascunhos WIP, se houver, em `$SESSIONS_DIR/prod/{TASK_MANAGER_KEY}/`; o documento canônico é o ARD
 - O arquivo final no mesmo idioma da interação do usuário
 
@@ -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, consulte também no Central docs as funcionalidades já implementadas relacionadas (o PRD e o FRD ficam em `$PROD_DOCS`).
 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,10 +62,10 @@ 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`)
+2. Localizar no Central docs as funcionalidades já implementadas relacionadas (nome, tags, `TASK_MANAGER_KEY`); o Documento de Requisitos de Produto / funcional vem de `$PROD_DOCS`
 3. Usar como contexto; se não achar, seguir com arquivos locais em `$PROD_DOCS`
 
 ## Sessões

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,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, 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" |
 
 ## Resultado final
 - Por padrão, use o modelo `$PROD_TEMPLATES/prod-epic-template.md` integralmente
@@ -118,48 +121,17 @@ 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:
+- Consultar no Central docs as funcionalidades já implementadas relacionadas (o que existe hoje):
   ```bash
   jarvis docs sync --silent
   ```
-- Buscar PRD e épicos existentes relacionados usando o contexto do usuário
-- Se PRD ou épico encontrado: carregar como contexto e informar o usuário
+- Buscar PRD e épicos existentes em `$PROD_DOCS` e, no Central docs, as funcionalidades já implementadas relacionadas
+- Se encontrar: carregar como contexto e informar o usuário
 - Se não encontrado: continuar com fluxo normal
 
-## Publicação no Central Docs (condicional)
-
-Após salvar o épico localmente e obter aprovação do usuário:
-
-1. Se `CENTRAL_DOCS_REPO` definido no ENV.md:
-   - Perguntar ao usuário:
-     ```
-     Deseja publicar este épico no repositório central de documentação?
-     - ( ) Sim, publicar agora
-     - ( ) Não, vou publicar depois manualmente
-     ```
-
-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}
-     ```
+## Central docs
 
-3. Informar resultado:
-   - ✅ Sucesso: "Épico publicado no central-docs. MR criado: [URL]"
-   - ❌ Erro: Exibir mensagem de erro e orientar troubleshooting
+Este documento é um **documento de trabalho**: fica em `$PROD_DOCS`/`$ENG_DOCS` (`docs/jarvis/`) e **não** é publicado no Central docs. O Central docs registra só o que foi implementado, e quem o atualiza é o `/eng.spec-consolidate`, depois do PR da entrega.
 
-4. Se **Não**:
-   - Informar: "Para publicar depois, execute: `jarvis docs publish --file {caminho} --tipo epic --feature {slug}`"
-
-> **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.
-
-Utilize o que o usuário fornecer analisar em:
-<requirement>
-#$ARGUMENTS
-</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,7 @@ 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 |
 
 ## Princípios Fundamentais
 1. **Sempre use o template** `$PROD_TEMPLATES/prod-frd-template.md` para o output final
@@ -56,20 +59,20 @@ 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:
+   - Consultar no Central docs as funcionalidades já implementadas relacionadas (o que existe hoje):
      ```bash
      jarvis docs sync --silent
      ```
-   - Buscar PRD relacionado usando:
+   - Buscar o PRD relacionado em `$PROD_DOCS` (documento de trabalho; o Central docs não guarda PRD) usando:
      - Nome/contexto fornecido pelo usuário
      - Jira ID (se disponível)
      - Tags semânticas
-   - Se PRD encontrado no central-docs:
+   - Se o PRD for encontrado em `$PROD_DOCS`:
      - Carregar automaticamente como base para o FRD
-     - Informar ao usuário: "✅ PRD encontrado no central-docs: [nome]"
+     - Informar ao usuário: "✅ PRD encontrado: [caminho]"
      - Passar como contexto para o Gate 1 (Fluxo de Trabalho, abaixo)
    - Se não encontrado:
      - Perguntar ao usuário se tem PRD localmente
@@ -183,36 +186,7 @@ O sistema deve validar os dados do formulário.
   - Se for uma spec nova:
     - Salve na pasta `$PROD_DOCS` seguindo todos os padrões de nomenclatura e estrutura de pastas já estabelecidos em `$PROD_RULES/**/*`
 
-## Publicação no Central Docs (condicional)
-
-Após salvar o FRD localmente e obter aprovação do usuário:
-
-1. Se `CENTRAL_DOCS_REPO` definido no ENV.md:
-   - Perguntar ao usuário:
-     ```
-     Deseja publicar este FRD no repositório central de documentação?
-     - ( ) Sim, publicar agora
-     - ( ) Não, vou publicar depois manualmente
-     ```
-
-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}
-     ```
-
-3. Informar resultado:
-   - ✅ Sucesso: "FRD publicado no central-docs. MR criado: [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}`"
+## Central docs
 
-5. Se `CENTRAL_DOCS_REPO` não estiver definido:
-   - Informar: "Para habilitar publicação automática, configure `CENTRAL_DOCS_REPO` no ENV.md"
+Este documento é um **documento de trabalho**: fica em `$PROD_DOCS`/`$ENG_DOCS` (`docs/jarvis/`) e **não** é publicado no Central docs. O Central docs registra só o que foi implementado, e quem o atualiza é o `/eng.spec-consolidate`, depois do PR da entrega.
 
-> **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.

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,7 @@ 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) |
 
 ## Princípios Fundamentais
 1. **Sempre use o template** `$PROD_TEMPLATES/prod-prd-template.md` para o output final
@@ -41,20 +44,20 @@ 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:
+   - Consultar no Central docs as funcionalidades já implementadas relacionadas (o que existe hoje):
      ```bash
      jarvis docs sync --silent
      ```
-   - Buscar PRD relacionado usando:
+   - Buscar o PRD relacionado em `$PROD_DOCS` (documento de trabalho; o Central docs não guarda PRD) usando:
      - Nome/contexto do PRD fornecido pelo usuário
      - Jira ID (se disponível)
      - Tags semânticas
-   - Se PRD encontrado no central-docs:
+   - Se o PRD for encontrado em `$PROD_DOCS`:
      - Carregar automaticamente como base para iteração
-     - Informar ao usuário: "✅ PRD encontrado no central-docs: [nome]"
+     - Informar ao usuário: "✅ PRD encontrado: [caminho]"
      - Usar como contexto para o Gate 1 (Fluxo de Trabalho, abaixo)
    - Se não encontrado:
      - Perguntar ao usuário se tem PRD localmente
@@ -170,37 +173,7 @@ Quais métricas? A) Engajamento B) Receita C) Outro
   - Se for uma spec nova:
     - Salve na pasta `$PROD_DOCS` seguindo todos os padrões de nomenclatura e estrutura de pastas já estabelecidos em `$PROD_RULES/**/*`
 
-## Publicação no Central Docs (condicional)
-
-Após salvar o PRD localmente e obter aprovação do usuário:
-
-1. Se `CENTRAL_DOCS_REPO` definido no ENV.md:
-   - Perguntar ao usuário:
-     ```
-     Deseja publicar este PRD no repositório central de documentação?
-     - ( ) Sim, publicar agora
-     - ( ) Não, vou publicar depois manualmente
-     ```
-
-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}
-     ```
-
-3. Informar resultado:
-   - ✅ Sucesso: "PRD publicado no central-docs. MR criado: [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}`"
-
-5. Se `CENTRAL_DOCS_REPO` não estiver definido:
-   - Informar: "Para habilitar publicação automática, configure `CENTRAL_DOCS_REPO` no ENV.md"
+## Central docs
 
-> **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.
+Este documento é um **documento de trabalho**: fica em `$PROD_DOCS`/`$ENG_DOCS` (`docs/jarvis/`) e **não** é publicado no Central docs. O Central docs registra só o que foi implementado, e quem o atualiza é o `/eng.spec-consolidate`, depois do PR da entrega.
 

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,14 +129,14 @@ 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 **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.
 
 > ⚠️ **IMPORTANTE**: NÃO executar `jarvis docs sync` diretamente via Bash.
 > Usar sempre: **Skill tool → jarvis-docs-central (Modo 1: Buscar Docs)**
 
 O skill `jarvis-docs-central` gerencia:
-- Extração de token do `.npmrc`
-- Fallback quando `index.md` não existe (navegação por árvore)
+- 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:**
@@ -150,17 +150,15 @@ Contexto: warm-up - sincronização inicial
 ```
 🔄 Sincronizando docs de {SQUAD}/{WORKSPACE}...
 ✅ Docs sincronizados
-📊 5 documentos disponíveis:
-   - 1 PRD(s)
-   - 1 FRD(s)
-   - 2 ARD(s)
-   - 1 RFC(s)
+📊 7 documentos disponíveis:
+   - 4 funcionalidade(s)
+   - 3 entrega(s) recente(s)
 ```
 
 **Comportamento:**
-- Se `CENTRAL_DOCS_REPO` 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 `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
 
 Após sincronizar, exibir resumo dos documentos disponíveis:

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");
-}