jarvis-ai-framework 3.2.0 → 4.0.0

package/templates/ENV-template.md

@@ -58,12 +58,20 @@ RULES_FOLDER=.$IDE/rules
 SESSIONS_DIR=.jarvis/sessions
 
 # Pastas de produto (derivadas das de cima — em geral não precisa mexer)
+# PROD_DOCS: no projeto único (sem workspace), o /jarvis-init grava docs/jarvis/product
+# (com docs/jarvis/* no .gitignore); no modo workspace, $DOCS_FOLDER/$PROD_FOLDER_NAME.
 PROD_FOLDER_NAME=product
 PROD_RULES=$RULES_FOLDER/$PROD_FOLDER_NAME
 PROD_FLOWS=.$IDE/$FLOWS_FOLDER
 PROD_TEMPLATES=.$IDE/$TEMPLATES_FOLDER/$PROD_FOLDER_NAME
 PROD_DOCS=$DOCS_FOLDER/$PROD_FOLDER_NAME
 
+# Modo de condução dos comandos de produto (prod.*) e do eng.create-ard.
+#   product-led      = para PMs: fluxo direto, sem explicações extras (padrão se vazio)
+#   developer-guided = para devs e futuros PMs: uma pergunta por vez, explica cada termo e etapa
+# Perguntado sempre pelo /jarvis-init. Para trocar, rode o /jarvis-init ou edite aqui.
+PROD_MODE=
+
 
 # --- Especializações por área -------------------------------------------------
 # Skills especializados que o Jarvis carrega junto com o skill base de cada área.
@@ -198,11 +206,18 @@ JARVIS_PROJECT=https://github.com/phelipperibeiro/jarvis-framework
 
 
 # --- Central docs (opcional) -------------------------------------------------
-# Repo de documentação canônica (PRD, FRD, ARD, RFC). Em branco = desligado.
-CENTRAL_DOCS_REPO=
+# Onde fica a documentação canônica (PRD, FRD, épicos, ARD, RFC). Em branco = desligado.
+# Nunca dentro do versionamento de um repositório de código.
+#   CENTRAL_DOCS_STORAGE: filesystem (s3 e gdrive virão nas issues #144 e #145)
+#   CENTRAL_DOCS_LOCATION: pasta do Central docs, relativa à pasta do workspace ou absoluta.
+#     Padrão do /jarvis-init: ./central-docs (modo workspace, no .gitignore do workspace)
+#     ou docs/jarvis/central-docs (projeto único, com docs/jarvis/* no .gitignore).
+#   Se a pasta for um clone de um repositório de documentação (tem .git): git pull antes
+#   de ler e branch + commit + push + PR ao publicar. Sem .git: grava direto na pasta.
+CENTRAL_DOCS_STORAGE=
+CENTRAL_DOCS_LOCATION=
+# Só quando a pasta tem .git: branch lida no pull e branch base dos PRs.
 CENTRAL_DOCS_REF=main
 CENTRAL_DOCS_TARGET_BRANCH=main
-# Revisores padrão dos MRs (separados por vírgula).
+# Revisores padrão dos PRs (separados por vírgula; vão na descrição).
 CENTRAL_DOCS_REVIEWERS=
-# TTL do cache opcional (redis-cli, se existir). 3600 = 1 hora.
-CENTRAL_DOCS_CACHE_TTL=3600

package/templates/engineering/ARD-template.md

@@ -1,3 +1,39 @@
+---
+# Modelo de IA recomendado para trabalhar neste documento. Se a sessão estiver em outro,
+# o comando avisa e segue (você decide se troca). Opções: opus | sonnet | haiku
+recommended_model: opus
+
+# Identificador único do ARD, em sequência (ex.: ARD-001). Vai no nome do arquivo.
+id: [ARD-xxx]
+
+# Título da arquitetura. Vai no título e, em kebab-case, no nome do arquivo.
+name: [Título da Arquitetura]
+
+# Versão do documento (X.Y.Z). Atualize a cada alteração.
+version: [1.0.0]
+
+# Em que ponto este ARD está no ciclo de vida.
+# Opções: proposed | in_progress | in_review | approved
+# proposed = proposta, ainda em discussão | in_progress = arquitetura em desenvolvimento
+# in_review = em validação com os revisores | approved = finalizada e aprovada
+status: [um dos valores acima]
+
+# Documentos relacionados: RFC (proposta técnica), FRD (requisitos funcionais), PRD (requisitos de produto).
+related: [RFC-xxx, FRD-xxx, PRD-xxx]
+
+# Data de criação (YYYY-MM-DD).
+created_at: [YYYY-MM-DD]
+
+# Data da última alteração (YYYY-MM-DD).
+updated_at: [YYYY-MM-DD]
+
+# Quem criou o documento (Tech Lead ou arquiteto responsável).
+created_by: [nome]
+
+# Quem editou o documento por último.
+last_editor: [nome]
+---
+
 # 🧱 ARD Template — Architecture Requirement Document
 
 **Arquivo:** /docs/engineering/ARD/ARD-xxx-nome-da-arquitetura.md
@@ -6,12 +42,9 @@
 
 ## 🏗️ ARD-[número] — [Título da Arquitetura]
 
-**Status:** Proposta / Em desenvolvimento / Em validação / Finalizada  
-**Data:** [dd/mm/yyyy]  
-**Autor:** [Tech Lead / Arquiteto responsável]  
-**Revisores:** [Chapter Leads, Eng. de Plataforma, etc.]  
-**Relacionado a:** [RFC-xxx], [FRD-xxx], [PRD-xxx]  
-**Versão:** [1.0]
+**Revisores:** [Chapter Leads, Eng. de Plataforma, etc.]
+
+> Status, versão, datas, autor e documentos relacionados ficam no frontmatter (topo do arquivo).
 
 ---
 

package/templates/engineering/architecture-template.md

@@ -5,6 +5,7 @@
 
 > **Criado em:** {DATA}  
 > **Issue:** {JIRA_ISSUE_KEY}  
+> **Branch base:** {main | dev | outra — perguntada no eng.start; destino do PR no eng.pr}  
 > **Status:** 🔄 Em Revisão | ✅ Aprovado | ❌ Rejeitado  
 > **Advisor:** {modelo escolhido no início do eng.start} | não utilizado
 

package/templates/product/prod-breakdown-template.md

@@ -1,8 +1,26 @@
 ---
-name: [Name from PRD]  
+# Modelo de IA recomendado para trabalhar neste documento. Se a sessão estiver em outro,
+# o comando avisa e segue (você decide se troca). Opções: opus | sonnet | haiku
+recommended_model: opus
+
+# Nome do breakdown (o mesmo do PRD ou FRD que está sendo fatiado).
+name: [Name from PRD]
+
+# Time (squad) responsável pela entrega.
 team: [Team Name]
+
+# Em que ponto este documento está no ciclo de vida (lista em rules/product/prod-rules.md).
+# Opções: icebox | in_review | backlog | in_progress | in_production | cancelled | deprecated
+# icebox = ideia aguardando priorização | in_review = sendo estudado ou revisado | backlog = definido, aguardando implementação
+# in_progress = em desenvolvimento | in_production = em produção
+# cancelled = cancelado antes de ser entregue | deprecated = esteve em produção e foi descontinuado
+status: [um dos valores acima]
+
+# Data de criação (YYYY-MM-DD).
 created_at: [YYYY-MM-DD]
-last_updated: [YYYY-MM-DD]  
+
+# Data da última alteração (YYYY-MM-DD).
+updated_at: [YYYY-MM-DD]
 ---
 
 ## Resumo do plano detalhado (breakdown)

package/templates/product/prod-discovery-template.md

@@ -1,11 +1,34 @@
 ---
+# Modelo de IA recomendado para trabalhar neste documento. Se a sessão estiver em outro,
+# o comando avisa e segue (você decide se troca). Opções: opus | sonnet | haiku
+recommended_model: opus
+
+# Identificador único, em sequência (ex.: discovery-001). Vai no nome do arquivo e nos campos related_* de outros documentos.
 id: {discovery-001}
+
+# Nome curto do documento. Vai no título e, em kebab-case, no nome do arquivo.
 name: {nome dessa ideia}
-status: {in_review enquanto o rascunho existe | cancelled se o veredito for do_not_proceed}
+
+# Situação do rascunho. O discovery tem ciclo próprio (rules/product/prod-rules.md).
+# Opções: in_review | cancelled
+# in_review = rascunho em andamento ou concluído | cancelled = o veredito foi do_not_proceed
+status: {in_review | cancelled}
+
+# Recomendação do discovery: vale seguir com essa ideia? Fica vazio durante a entrevista.
+# Opções: proceed | investigate_more | do_not_proceed
+# proceed = vale especificar | investigate_more = há lacuna crítica | do_not_proceed = não seguir (status passa a cancelled)
 verdict: {vazio durante a entrevista | proceed | investigate_more | do_not_proceed}
+
+# Data de criação (YYYY-MM-DD).
 created_at: {YYYY-MM-DD}
+
+# Data da última alteração (YYYY-MM-DD).
 updated_at: {YYYY-MM-DD}
+
+# Quem criou o documento.
 created_by: {nome de quem criou esse doc}
+
+# Quem editou o documento por último.
 last_editor: {nome de quem editou por último}
 ---
 

package/templates/product/prod-epic-template.md

@@ -1,15 +1,46 @@
 ---
+# Modelo de IA recomendado para trabalhar neste documento. Se a sessão estiver em outro,
+# o comando avisa e segue (você decide se troca). Opções: opus | sonnet | haiku
+recommended_model: opus
+
+# Identificador único, em sequência (ex.: EPIC-001). Vai no nome do arquivo e nos campos related_* de outros documentos.
 id: {EPIC-001}
+
+# Nome curto do documento. Vai no título e, em kebab-case, no nome do arquivo.
 name: {nome desse épico}
+
+# Versão do documento (X.Y.Z). Atualize a cada alteração.
 version: {X.Y.Z - atualizar sempre que houver alteração}
-status: {icebox|in_review|in_progress|in_production|deprecated}
+
+# Em que ponto este documento está no ciclo de vida (lista em rules/product/prod-rules.md).
+# Opções: icebox | in_review | backlog | in_progress | in_production | cancelled | deprecated
+# icebox = ideia aguardando priorização | in_review = sendo estudado ou revisado | backlog = definido, aguardando implementação
+# in_progress = em desenvolvimento | in_production = em produção
+# cancelled = cancelado antes de ser entregue | deprecated = esteve em produção e foi descontinuado
+status: {um dos valores acima}
+
+# Link do card no task manager do projeto (TASK_MANAGER no ENV.md). Remova a linha se não houver.
 task_link: {URL referêncial no $TASK_MANAGER - se existir. Se não, ignore essa linha}
+
+# PRD relacionado (Product Requirements Document: o problema e o que vamos construir).
 related_prd: {path PRD relacionado, exemplo /master-docs/product/prd-001.md}
+
+# FRD relacionado (Functional Requirements Document: o comportamento detalhado de uma funcionalidade).
 related_frd: {path FRD relacionado, exemplo /master-docs/product/frds/frd-001.md}
+
+# Discovery de origem (o rascunho da ideia, anterior ao PRD). Remova a linha se não houver.
 related_discovery: {path do discovery de origem, exemplo $PROD_DOCS/discoveries/discovery-001-nome.md. Se não existir, ignore essa linha}
+
+# Data de criação (YYYY-MM-DD).
 created_at: {YYYY-MM-DD}
+
+# Data da última alteração (YYYY-MM-DD).
 updated_at: {YYYY-MM-DD}
+
+# Quem criou o documento.
 created_by: {nome de quem criou esse doc}
+
+# Quem editou o documento por último.
 last_editor: {nome de quem editou por último}
 ---
 

package/templates/product/prod-frd-template.md

@@ -1,13 +1,40 @@
 ---
+# Modelo de IA recomendado para trabalhar neste documento. Se a sessão estiver em outro,
+# o comando avisa e segue (você decide se troca). Opções: opus | sonnet | haiku
+recommended_model: opus
+
+# Identificador único, em sequência (ex.: FRD-001). Vai no nome do arquivo e nos campos related_* de outros documentos.
 id: {FRD-001}
+
+# Nome curto do documento. Vai no título e, em kebab-case, no nome do arquivo.
 name: {nome desse frd}
+
+# Versão do documento (X.Y.Z). Atualize a cada alteração.
 version: {X.Y.Z - atualizar sempre que houver alteração}
-status: {$ITEM_STATUS}
+
+# Em que ponto este documento está no ciclo de vida (lista em rules/product/prod-rules.md).
+# Opções: icebox | in_review | backlog | in_progress | in_production | cancelled | deprecated
+# icebox = ideia aguardando priorização | in_review = sendo estudado ou revisado | backlog = definido, aguardando implementação
+# in_progress = em desenvolvimento | in_production = em produção
+# cancelled = cancelado antes de ser entregue | deprecated = esteve em produção e foi descontinuado
+status: {um dos valores acima}
+
+# Quem editou o documento por último.
 last_editor: {nome de quem editou por último}
+
+# Data da última alteração (YYYY-MM-DD).
 updated_at: {YYYY-MM-DD}
+
+# PRD relacionado (Product Requirements Document: o problema e o que vamos construir).
 related_prd: {Lista de PRDs que são relacionadas a esse PRD, se forem vários, utilize sintaxe compatível com YAML}
+
+# Discovery de origem (o rascunho da ideia, anterior ao PRD). Remova a linha se não houver.
 related_discovery: {path do discovery de origem, exemplo $PROD_DOCS/discoveries/discovery-001-nome.md. Se não existir, ignore essa linha}
+
+# Data de criação (YYYY-MM-DD).
 created_at: {YYYY-MM-DD}
+
+# Quem criou o documento.
 created_by: {nome de quem criou esse doc}
 ---
 
@@ -138,7 +165,7 @@ Ele é um sistema de gestão de dados pessoais de saúde, que agrega informaçõ
 - {Exclusão adicional}
 
 ## Especificações relacionadas
-{liste todos os PRDs, FRDs ou outros documentos relacionados a este FRD fazendo uma análise prévia do projeto e das especificações existentes no `$CENTRAL_DOCS_REPO`. Pergunte para o usuário se existe outras relações que ele conheça. Antes de adicionar as sugestões, confirme com o usuário se elas estão corretas.}
+{liste todos os PRDs, FRDs ou outros documentos relacionados a este FRD fazendo uma análise prévia do projeto e das especificações existentes no Central docs (`jarvis docs sync`). Pergunte para o usuário se existe outras relações que ele conheça. Antes de adicionar as sugestões, confirme com o usuário se elas estão corretas.}
 
 **PRDs relacionadas**:
 | ID | Título | Descrição |

package/templates/product/prod-issue-template.md

@@ -1,16 +1,51 @@
 ---
+# Modelo de IA recomendado para trabalhar neste documento. Se a sessão estiver em outro,
+# o comando avisa e segue (você decide se troca). Opções: opus | sonnet | haiku
+recommended_model: opus
+
+# Identificador único, em sequência (ex.: STORY-001, TASK-001, BUG-001). Vai no nome do arquivo e nos campos related_* de outros documentos.
 id: {issue_type-001}
+
+# Nome curto do documento. Vai no título e, em kebab-case, no nome do arquivo.
 name: {nome dessa issue}
+
+# Tipo da issue.
+# Opções: Story | Task | Bug
+# Story = história de usuário (valor para quem usa) | Task = tarefa técnica | Bug = defeito a corrigir
 type: {Story, Task, Bug}
+
+# PRD relacionado (Product Requirements Document: o problema e o que vamos construir).
 related_prd: {path PRD relacionado, exemplo /master-docs/product/prd-001.md}
+
+# Épico ao qual esta issue pertence (o agrupador de histórias e tarefas). Remova a linha se não houver.
 related_epic: {nome do Epico relacionado, exemplo /master-docs/product/epics/epic-001.md. Se não existir, ignore essa linha}
+
+# FRD relacionado (Functional Requirements Document: o comportamento detalhado de uma funcionalidade).
 related_frd: {path FRD relacionado, exemplo /master-docs/product/frds/frd-001.md}
+
+# Discovery de origem (o rascunho da ideia, anterior ao PRD). Remova a linha se não houver.
 related_discovery: {path do discovery de origem, exemplo $PROD_DOCS/discoveries/discovery-001-nome.md. Se não existir, ignore essa linha}
+
+# Data de criação (YYYY-MM-DD).
 created_at: {YYYY-MM-DD}
+
+# Data da última alteração (YYYY-MM-DD).
 updated_at: {YYYY-MM-DD}
+
+# Link do card no task manager do projeto (TASK_MANAGER no ENV.md). Remova a linha se não houver.
 task_link: {URL referêncial no $TASK_MANAGER - se existir. Se não, ignore essa linha}
-status: {icebox|in_review|in_progress|in_production|deprecated}
+
+# Em que ponto este documento está no ciclo de vida (lista em rules/product/prod-rules.md).
+# Opções: icebox | in_review | backlog | in_progress | in_production | cancelled | deprecated
+# icebox = ideia aguardando priorização | in_review = sendo estudado ou revisado | backlog = definido, aguardando implementação
+# in_progress = em desenvolvimento | in_production = em produção
+# cancelled = cancelado antes de ser entregue | deprecated = esteve em produção e foi descontinuado
+status: {um dos valores acima}
+
+# Quem criou o documento.
 created_by: {nome de quem criou esse doc}
+
+# Quem editou o documento por último.
 last_editor: {nome de quem editou por último}
 ---
 

package/templates/product/prod-prd-template.md

@@ -1,15 +1,46 @@
 ---
+# Modelo de IA recomendado para trabalhar neste documento. Se a sessão estiver em outro,
+# o comando avisa e segue (você decide se troca). Opções: opus | sonnet | haiku
+recommended_model: opus
+
+# Identificador único, em sequência (ex.: PRD-001). Vai no nome do arquivo e nos campos related_* de outros documentos.
 id: {PRD-001}
+
+# Nome curto do documento. Vai no título e, em kebab-case, no nome do arquivo.
 name: {nome desse prd}
+
+# Versão do documento (X.Y.Z). Atualize a cada alteração.
 version: {X.Y.Z - atualizar sempre que houver alteração}
-status: {$ITEM_STATUS}
+
+# Em que ponto este documento está no ciclo de vida (lista em rules/product/prod-rules.md).
+# Opções: icebox | in_review | backlog | in_progress | in_production | cancelled | deprecated
+# icebox = ideia aguardando priorização | in_review = sendo estudado ou revisado | backlog = definido, aguardando implementação
+# in_progress = em desenvolvimento | in_production = em produção
+# cancelled = cancelado antes de ser entregue | deprecated = esteve em produção e foi descontinuado
+status: {um dos valores acima}
+
+# Quem editou o documento por último.
 last_editor: {nome de quem editou por último}
+
+# Data da última alteração (YYYY-MM-DD).
 updated_at: {YYYY-MM-DD}
+
+# Repositórios de código onde este produto é implementado.
 related_repo: {URLs de repositórios relacionados, se forem vários, utilize sintaxe compatível com YAML}
+
+# PRD relacionado (Product Requirements Document: o problema e o que vamos construir).
 related_prd: {Lista de PRDs que são relacionadas a esse PRD, se forem vários, utilize sintaxe compatível com YAML}
+
+# FRD relacionado (Functional Requirements Document: o comportamento detalhado de uma funcionalidade).
 related_frd: {Lista de FRDs que são relacionadas a esse PRD, se forem vários, utilize sintaxe compatível com YAML}
+
+# Discovery de origem (o rascunho da ideia, anterior ao PRD). Remova a linha se não houver.
 related_discovery: {path do discovery de origem, exemplo $PROD_DOCS/discoveries/discovery-001-nome.md. Se não existir, ignore essa linha}
+
+# Data de criação (YYYY-MM-DD).
 created_at: {YYYY-MM-DD}
+
+# Quem criou o documento.
 created_by: {nome de quem criou esse doc}
 ---
 
@@ -148,7 +179,7 @@ Estes são indicadores que podem ser usados para medir o sucesso dessa solução
 
 
 ## Especificações relacionadas
-{liste todos os PRDs, FRDs ou outros documentos relacionados a este FRD fazendo uma análise prévia do projeto e das especificações existentes no `$CENTRAL_DOCS_REPO`. Pergunte para o usuário se existe outras relações que ele conheça. Antes de adicionar as sugestões, confirme com o usuário se elas estão corretas.}
+{liste todos os PRDs, FRDs ou outros documentos relacionados a este FRD fazendo uma análise prévia do projeto e das especificações existentes no Central docs (`jarvis docs sync`). Pergunte para o usuário se existe outras relações que ele conheça. Antes de adicionar as sugestões, confirme com o usuário se elas estão corretas.}
 
 **PRDs relacionadas**:
 | ID | Título | Descrição |

package/workflows/engineering/eng.build-tech-spec.md

@@ -54,7 +54,7 @@ Transformar uma história de usuário (user story) do Jira em uma **Tech Spec co
 | Passo | Skill | Condição |
 |-------|-------|----------|
 | Processo de Criação › verificação de necessidade de RFC | `/eng.create-rfc` | Se a Tech Spec atender aos critérios que exigem RFC e o usuário escolher "A: Criar uma RFC agora" |
-| Caminho A › 2A.2 Análise de Documentação de Produto | `/jarvis-docs-central` | Se `CENTRAL_DOCS_REPO` estiver configurado (buscar PRD/FRD relacionados do épico) |
+| Caminho A › 2A.2 Análise de Documentação de Produto | `/jarvis-docs-central` | Se `CENTRAL_DOCS_STORAGE` estiver configurado (buscar PRD/FRD relacionados do épico) |
 | FASE 7 › 7.3 Criação no Jira | `ferramenta MCP/API do Jira` (referência a confirmar) | Se o projeto usar Jira e houver ferramenta MCP ou API disponível; senão fornecer template para criação manual (o texto não nomeia a ferramenta) |
 
 ---
@@ -264,7 +264,7 @@ Foco em entender o sistema como um todo — não arquivos específicos, mas fron
 #### 2A.2 Análise de Documentação de Produto
 
 - Verifique se há PRD ou FRD relacionado ao épico em `$DOCS_FOLDER` ou no $TASK_MANAGER
-- Se `CENTRAL_DOCS_REPO` configurado: buscar docs via skill `jarvis-docs-central`
+- Se `CENTRAL_DOCS_STORAGE` configurado: buscar docs via skill `jarvis-docs-central`
 
 #### 2A.3 Identificação de Restrições
 

package/workflows/engineering/eng.create-ard-from-code.md

@@ -22,8 +22,8 @@ priorizando a **arquitetura observada no código do repositório**, usando o tem
 | Passo | Skill | Condição |
 |-------|-------|----------|
 | Objetivo | `eng.agent` (agente) | Sempre — identidade do workflow (alinhamento com `eng.agent.md`) |
-| Passo 1 – Verificar PRD | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_REPO` estiver definido no ENV.md |
-| Passo 7 – Publicar no Central Docs | `/jarvis-docs-central` (via `jarvis docs publish --tipo ard`) | Se `CENTRAL_DOCS_REPO` estiver definido, o ARD estiver aprovado e o usuário aceitar publicar |
+| Passo 1 – Verificar PRD | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_STORAGE` estiver definido no ENV.md |
+| Passo 7 – Publicar no Central Docs | `/jarvis-docs-central` (via `jarvis docs publish --tipo ard`) | Se `CENTRAL_DOCS_STORAGE` estiver definido, o ARD estiver aprovado e o usuário aceitar publicar |
 
 ---
 
@@ -60,7 +60,7 @@ priorizando a **arquitetura observada no código do repositório**, usando o tem
 - Defina o `ARD-ID` automaticamente assim:
   - Se a pasta `$DOCS_FOLDER/engineering/ARD/` existir e houver arquivos no padrão `ARD-###-*.md`, use o maior `###` + 1.
 - Defina:
-  - `Status`
+  - `Status` (campo `status` no frontmatter: `proposed | in_progress | in_review | approved`)
   - `Caminho do arquivo` (`$DOCS_FOLDER/engineering/ARD/{ARD-ID}-{slug}.md` ou caminho fornecido para iteração)
 
 ---
@@ -69,7 +69,7 @@ priorizando a **arquitetura observada no código do repositório**, usando o tem
 
 ### 1.1 – Buscar PRD no Central Docs (condicional)
 
-Se `CENTRAL_DOCS_REPO` definido no ENV.md:
+Se `CENTRAL_DOCS_STORAGE` definido no ENV.md:
 
 1. Executar busca automática no central-docs:
    ```bash
@@ -238,7 +238,7 @@ Entregar:
 
 ## Passo 7 – Publicar no Central Docs (condicional)
 
-Se `CENTRAL_DOCS_REPO` definido no ENV.md **E** o usuário aprovar o ARD:
+Se `CENTRAL_DOCS_STORAGE` definido no ENV.md **E** o usuário aprovar o ARD:
 
 1. Perguntar ao usuário:
    ```
@@ -248,20 +248,18 @@ Se `CENTRAL_DOCS_REPO` definido no ENV.md **E** o usuário aprovar o ARD:
    ```
 
 2. Se **Sim**:
-   - Extrair o slug do nome do arquivo (ex: `ARD-001-api-wallet-auth.md` → `api-wallet-auth`)
    - Executar:
      ```bash
      jarvis docs publish \
        --file {caminho_do_ard} \
-       --tipo ard \
-       --feature {slug}
+       --tipo ard
      ```
    
 3. Informar resultado:
-   - ✅ Sucesso: "ARD publicado no central-docs. MR criado: [URL]"
+   - ✅ Sucesso: "ARD 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 ard --feature {slug}`"
+   - Informar: "Para publicar depois, execute: `jarvis docs publish --file {caminho} --tipo ard`"
 
-> **Nota**: A publicação cria um Merge Request no GitLab. O ARD 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 ARD só entra na branch base depois do merge. Sem git, o documento é gravado direto e o índice é regenerado.

package/workflows/engineering/eng.create-ard.md

@@ -3,13 +3,17 @@ description: Fluxo de trabalho de Engenharia para criação/iteração de ARD
 globs:
   alwaysApply: false
   env_file: "@/ENV.md"
-recommended_model: claude-sonnet-4-20250514
+recommended_model: opus
 model_tier: high
 model_justification: Documentação arquitetural requer análise de requisitos, trade-offs técnicos e decisões bem fundamentadas
 ---
 
 # Workflow de Engenharia – ARD (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.
+
 ## Objetivo
 
 Guiar o assistente de Engenharia (ENG) na criação, revisão ou iteração de um ARD,
@@ -25,8 +29,8 @@ usando o template `$IDE/templates/engineering/ARD-template.md`, sempre alinhado
 | Passo | Skill | Condição |
 |-------|-------|----------|
 | Objetivo | `eng.agent` (agente) | Sempre — identidade do workflow (alinhamento com `eng.agent.md`) |
-| Passo 1.1.1 – Buscar PRD no Central Docs | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_REPO` estiver definido no ENV.md |
-| Passo 8 – Publicar no Central Docs | `/jarvis-docs-central` (via `jarvis docs publish --tipo ard`) | Se `CENTRAL_DOCS_REPO` estiver definido, o ARD estiver aprovado e o usuário aceitar publicar |
+| Passo 1.1.1 – Buscar PRD no Central Docs | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_STORAGE` estiver definido no ENV.md |
+| Passo 8 – Publicar no Central Docs | `/jarvis-docs-central` (via `jarvis docs publish --tipo ard`) | Se `CENTRAL_DOCS_STORAGE` estiver definido, o ARD estiver aprovado e o usuário aceitar publicar |
 
 ---
 
@@ -64,7 +68,7 @@ usando o template `$IDE/templates/engineering/ARD-template.md`, sempre alinhado
   - Se a pasta `$DOCS_FOLDER/engineering/ARD/` existir e houver arquivos no padrão `ARD-###-*.md`, use o maior `###` + 1.
 - Defina o `ARD-ID` automaticamente assim:
   - Se a pasta `$DOCS_FOLDER/engineering/ARD/` existir e houver arquivos no padrão `ARD-###-*.md`, use o maior `###` + 1.
-- `Status`
+- `Status` (campo `status` no frontmatter: `proposed | in_progress | in_review | approved`)
 - `Caminho do arquivo` (`$DOCS_FOLDER/engineering/ARD/{ARD-ID}-{slug}.md` ou caminho fornecido para iteração)
 
 ---
@@ -109,7 +113,7 @@ Regras:
 3. Confirme os metadados definidos no Passo 0:
    - `ARD-ID`
    - `Título`
-   - `Status`
+   - `Status` (campo `status` no frontmatter)
    - `Caminho do arquivo` (`$DOCS_FOLDER/engineering/ARD/{ARD-ID}-{slug}.md` ou caminho fornecido para iteração)
 
 ---
@@ -118,7 +122,7 @@ Regras:
 
 ### 1.1.1 – Buscar PRD no Central Docs (condicional)
 
-Se `CENTRAL_DOCS_REPO` definido no ENV.md:
+Se `CENTRAL_DOCS_STORAGE` definido no ENV.md:
 
 1. Executar busca automática no central-docs:
    ```bash
@@ -361,7 +365,7 @@ Peça explicitamente para o usuário:
 
 ## Passo 8 – Publicar no Central Docs (condicional)
 
-Se `CENTRAL_DOCS_REPO` definido no ENV.md **E** o usuário aprovar o ARD:
+Se `CENTRAL_DOCS_STORAGE` definido no ENV.md **E** o usuário aprovar o ARD:
 
 1. Perguntar ao usuário:
    ```
@@ -371,20 +375,18 @@ Se `CENTRAL_DOCS_REPO` definido no ENV.md **E** o usuário aprovar o ARD:
    ```
 
 2. Se **Sim**:
-   - Extrair o slug do nome do arquivo (ex: `ARD-001-api-wallet-auth.md` → `api-wallet-auth`)
    - Executar:
      ```bash
      jarvis docs publish \
        --file {caminho_do_ard} \
-       --tipo ard \
-       --feature {slug}
+       --tipo ard
      ```
    
 3. Informar resultado:
-   - ✅ Sucesso: "ARD publicado no central-docs. MR criado: [URL]"
+   - ✅ Sucesso: "ARD 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 ard --feature {slug}`"
+   - Informar: "Para publicar depois, execute: `jarvis docs publish --file {caminho} --tipo ard`"
 
-> **Nota**: A publicação cria um Merge Request no GitLab. O ARD 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 ARD só entra na branch base depois do merge. Sem git, o documento é gravado direto e o índice é regenerado.

package/workflows/engineering/eng.create-rfc.md

@@ -27,8 +27,8 @@ Além disso, quando houver campo `Versão` no RFC, aplicar obrigatoriamente:
 
 | Passo | Skill | Condição |
 |-------|-------|----------|
-| Passo 0.6 – Buscar Documentação Relacionada no Central Docs | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_REPO` estiver definido no ENV.md |
-| Passo 7 – Publicar no Central Docs | `/jarvis-docs-central` (via `jarvis docs publish --tipo rfc`) | Se `CENTRAL_DOCS_REPO` estiver definido **e** o usuário aprovar o RFC e responder "Sim, publicar agora" |
+| Passo 0.6 – Buscar Documentação Relacionada no Central Docs | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_STORAGE` estiver definido no ENV.md |
+| Passo 7 – Publicar no Central Docs | `/jarvis-docs-central` (via `jarvis docs publish --tipo rfc`) | Se `CENTRAL_DOCS_STORAGE` estiver definido **e** o usuário aprovar o RFC e responder "Sim, publicar agora" |
 
 ---
 
@@ -92,7 +92,7 @@ Regras:
 
 ## Passo 0.6 – Buscar Documentação Relacionada no Central Docs (condicional)
 
-Se `CENTRAL_DOCS_REPO` definido no ENV.md:
+Se `CENTRAL_DOCS_STORAGE` definido no ENV.md:
 
 1. Executar busca automática no central-docs:
    ```bash
@@ -223,7 +223,7 @@ Entregar:
 
 ## Passo 7 – Publicar no Central Docs (condicional)
 
-Se `CENTRAL_DOCS_REPO` definido no ENV.md **E** o usuário aprovar o RFC:
+Se `CENTRAL_DOCS_STORAGE` definido no ENV.md **E** o usuário aprovar o RFC:
 
 1. Perguntar ao usuário:
    ```
@@ -233,20 +233,18 @@ Se `CENTRAL_DOCS_REPO` definido no ENV.md **E** o usuário aprovar o RFC:
    ```
 
 2. Se **Sim**:
-   - Extrair o slug do nome do arquivo (ex: `RFC-001-wallet-idempotencia.md` → `wallet-idempotencia`)
    - Executar:
      ```bash
      jarvis docs publish \
        --file {caminho_do_rfc} \
-       --tipo rfc \
-       --feature {slug}
+       --tipo rfc
      ```
    
 3. Informar resultado:
-   - ✅ Sucesso: "RFC publicado no central-docs. MR criado: [URL]"
+   - ✅ Sucesso: "RFC 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 rfc --feature {slug}`"
+   - Informar: "Para publicar depois, execute: `jarvis docs publish --file {caminho} --tipo rfc`"
 
-> **Nota**: A publicação cria um Merge Request no GitLab. O RFC 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 RFC só entra na branch base depois do merge. Sem git, o documento é gravado direto e o índice é regenerado.

package/workflows/engineering/eng.pr.md

@@ -61,7 +61,7 @@ Ler `TASK_MANAGER` do `$IDE/ENV.md`. Seguir `$IDE/rules/engineering/eng.integrat
 - `TASK_MANAGER` vazio → *Qual o seu número de controle para esta tarefa? (ex: F-042)*
 - `TASK_MANAGER` preenchido → *Qual o id do card no {TASK_MANAGER}?*
 
-> A branch de destino **padrão é `dev`** (GitFlow). Só perguntar se o usuário indicar outra branch (ex: hotfix direto para `main`).
+> A branch de destino é a **`Branch base:`** gravada no cabeçalho do `$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/architecture.md` pelo `eng.start`. Só perguntar (`main`, `dev` ou Outro) se o campo não existir.
 > 💡 A branch de feature já foi criada no `eng.start`. Este workflow apenas faz push e abre o MR.
 
 ---
@@ -122,7 +122,7 @@ A branch deve seguir o padrão `{TASK_MANAGER_KEY}-{titulo-em-kebab-case}`.
 
 ### 2.2 Confirmar Branch de Destino
 
-Branch de destino padrão: **`dev`** (GitFlow).
+Branch de destino: a **`Branch base:`** do `architecture.md` (`{BRANCH_BASE}`). Sem o campo, pergunte com `AskUserQuestion` (`main`, `dev` ou Outro); não presuma.
 
 > ⚠️ **Nunca fazer push direto para `main` ou `master`** sem confirmação explícita do usuário.
 
@@ -137,7 +137,7 @@ git checkout {TASK_MANAGER_KEY}-{titulo-em-kebab-case}
 ### 2.2 Verificar Commits da Branch
 
 ```bash
-git log dev..HEAD --oneline
+git log {BRANCH_BASE}..HEAD --oneline
 ```
 
 Deve listar os commits das fases implementadas no `eng.work`.
@@ -203,7 +203,7 @@ Preencher com a tarefa. Link do card:
 
 - **Título**: `{TASK_MANAGER_KEY}: {Título da tarefa}`
 - **Branch origem**: `{NOME_DA_BRANCH}`
-- **Branch destino**: a informada pelo usuário (`dev` / `main` / hotfix)
+- **Branch destino**: `{BRANCH_BASE}` (a `Branch base:` do `architecture.md`)
 - **Descrição**: template preenchido, gravado em arquivo temporário
 
 ```bash