jarvis-ai-framework 3.2.0 → 5.0.0

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 (funcionalidades já implementadas relacionadas ao épico; PRD/FRD vêm de `$PROD_DOCS`) |
 | 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
 
@@ -418,8 +418,8 @@ Identifique:
   >
   > **1. Buscar contrato no repositório primeiro:**
   > Procure por specs existentes nos seguintes locais:
-  > - `docs/engineering/swagger/`
-  > - `docs/engineering/openapi/`
+  > - `$ENG_DOCS/swagger/`
+  > - `$ENG_DOCS/openapi/`
   > - `**/*swagger*.{yaml,yml,json}`
   > - `**/*openapi*.{yaml,yml,json}`
   > - `**/*api-spec*.{yaml,yml,json}`

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

@@ -22,8 +22,7 @@ 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 |
 
 ---
 
@@ -43,7 +42,7 @@ priorizando a **arquitetura observada no código do repositório**, usando o tem
 
 - Se o usuário tiver passado `edit <nome-ou-caminho>`, use isso como entrada inicial.
 - Peça o **caminho do arquivo** do ARD existente (preferencial) ou o **nome** do ARD, se ainda não tiver.
-- Se o usuário passar só o nome, confirme onde ele está (ex.: `$DOCS_FOLDER/engineering/ARD/...`).
+- Se o usuário passar só o nome, confirme onde ele está (ex.: `$ENG_DOCS/ARD/...`).
 - Leia o ARD atual e pergunte quais seções mudam (ou qual é o objetivo da iteração).
 
 3. Se for **novo ARD**:
@@ -58,10 +57,10 @@ priorizando a **arquitetura observada no código do repositório**, usando o tem
   - `Título`
   - `Slug` para o nome do arquivo (kebab-case)
 - 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.
+  - Se a pasta `$ENG_DOCS/ARD/` existir e houver arquivos no padrão `ARD-###-*.md`, use o maior `###` + 1.
 - Defina:
-  - `Status`
-  - `Caminho do arquivo` (`$DOCS_FOLDER/engineering/ARD/{ARD-ID}-{slug}.md` ou caminho fornecido para iteração)
+  - `Status` (campo `status` no frontmatter: `proposed | in_progress | in_review | approved`)
+  - `Caminho do arquivo` (`$ENG_DOCS/ARD/{ARD-ID}-{slug}.md` ou caminho fornecido para iteração)
 
 ---
 
@@ -69,22 +68,22 @@ 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:
+1. Consultar no Central docs as funcionalidades já implementadas relacionadas (o que existe hoje):
    ```bash
    jarvis docs sync --silent
    ```
 
-2. Buscar PRD relacionado usando:
+2. Buscar o PRD relacionado em `$PROD_DOCS` (documento de trabalho; o Central docs não guarda PRD) usando:
    - Título/objetivo do ARD
    - Jira ID (se disponível)
    - Tags semânticas
 
-3. Se PRD encontrado no central-docs:
+3. Se o PRD for encontrado em `$PROD_DOCS`:
    - Carregar automaticamente como contexto
    - Pular para item 2 (extração de requisitos)
-   - Informar ao usuário: "✅ PRD encontrado no central-docs: [nome]"
+   - Informar ao usuário: "✅ PRD encontrado: [caminho]"
 
 4. Se PRD não encontrado:
    - Continuar com pergunta manual (item 1.2)
@@ -122,7 +121,7 @@ Objetivo: montar um retrato fiel do que o código revela hoje.
 
 - `README.md`
 - `ENV.md`
-- `$DOCS_FOLDER/**` (especialmente `$DOCS_FOLDER/engineering/ARD/**` e docs de arquitetura existentes)
+- `$DOCS_FOLDER/**` (especialmente `$ENG_DOCS/ARD/**` e docs de arquitetura existentes)
 
 2. Identificar a stack e artefatos de build:
 
@@ -150,8 +149,8 @@ Objetivo: montar um retrato fiel do que o código revela hoje.
   >
   > **1. Buscar contrato no repositório primeiro:**
   > Procure por specs existentes nos seguintes locais:
-  > - `docs/engineering/swagger/`
-  > - `docs/engineering/openapi/`
+  > - `$ENG_DOCS/swagger/`
+  > - `$ENG_DOCS/openapi/`
   > - `**/*swagger*.{yaml,yml,json}`
   > - `**/*openapi*.{yaml,yml,json}`
   > - `**/*api-spec*.{yaml,yml,json}`
@@ -236,32 +235,7 @@ Entregar:
 
 ---
 
-## Passo 7 – Publicar no Central Docs (condicional)
+## Central docs
 
-Se `CENTRAL_DOCS_REPO` definido no ENV.md **E** o usuário aprovar o ARD:
+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.
 
-1. Perguntar ao usuário:
-   ```
-   Deseja publicar este ARD 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: `ARD-001-api-wallet-auth.md` → `api-wallet-auth`)
-   - Executar:
-     ```bash
-     jarvis docs publish \
-       --file {caminho_do_ard} \
-       --tipo ard \
-       --feature {slug}
-     ```
-   
-3. Informar resultado:
-   - ✅ Sucesso: "ARD 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 ard --feature {slug}`"
-
-> **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.

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,7 @@ 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 – Consultar funcionalidades no Central Docs | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_STORAGE` estiver definido no ENV.md |
 
 ---
 
@@ -46,7 +49,7 @@ usando o template `$IDE/templates/engineering/ARD-template.md`, sempre alinhado
 
 - Se o usuário tiver passado `edit <nome-ou-caminho>`, use isso como entrada inicial.
 - Peça o **caminho do arquivo** do ARD existente (preferencial) ou o **nome** do ARD, se ainda não tiver.
-- Se o usuário passar só o nome, confirme onde ele está (ex.: `$DOCS_FOLDER/engineering/ARD/...`).
+- Se o usuário passar só o nome, confirme onde ele está (ex.: `$ENG_DOCS/ARD/...`).
 - Leia o ARD atual e pergunte quais seções mudam (ou qual é o objetivo da iteração).
 
 3. Se for **novo ARD**:
@@ -61,11 +64,11 @@ usando o template `$IDE/templates/engineering/ARD-template.md`, sempre alinhado
   - `Título`
   - `Slug` para o nome do arquivo (kebab-case)
 - 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.
+  - Se a pasta `$ENG_DOCS/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`
-- `Caminho do arquivo` (`$DOCS_FOLDER/engineering/ARD/{ARD-ID}-{slug}.md` ou caminho fornecido para iteração)
+  - Se a pasta `$ENG_DOCS/ARD/` existir e houver arquivos no padrão `ARD-###-*.md`, use o maior `###` + 1.
+- `Status` (campo `status` no frontmatter: `proposed | in_progress | in_review | approved`)
+- `Caminho do arquivo` (`$ENG_DOCS/ARD/{ARD-ID}-{slug}.md` ou caminho fornecido para iteração)
 
 ---
 
@@ -109,8 +112,8 @@ Regras:
 3. Confirme os metadados definidos no Passo 0:
    - `ARD-ID`
    - `Título`
-   - `Status`
-   - `Caminho do arquivo` (`$DOCS_FOLDER/engineering/ARD/{ARD-ID}-{slug}.md` ou caminho fornecido para iteração)
+   - `Status` (campo `status` no frontmatter)
+   - `Caminho do arquivo` (`$ENG_DOCS/ARD/{ARD-ID}-{slug}.md` ou caminho fornecido para iteração)
 
 ---
 
@@ -118,22 +121,22 @@ 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:
+1. Consultar no Central docs as funcionalidades já implementadas relacionadas (o que existe hoje):
    ```bash
    jarvis docs sync --silent
    ```
 
-2. Buscar PRD relacionado usando:
+2. Buscar o PRD relacionado em `$PROD_DOCS` (documento de trabalho; o Central docs não guarda PRD) usando:
    - Título/objetivo do ARD
    - Jira ID (se disponível)
    - Tags semânticas
 
-3. Se PRD encontrado no central-docs:
+3. Se o PRD for encontrado em `$PROD_DOCS`:
    - Carregar automaticamente como contexto
    - Pular para item 2 (extração de requisitos)
-   - Informar ao usuário: "✅ PRD encontrado no central-docs: [nome]"
+   - Informar ao usuário: "✅ PRD encontrado: [caminho]"
 
 4. Se PRD não encontrado:
    - Continuar com pergunta manual (item 1.1.2)
@@ -260,8 +263,8 @@ Sempre que possível, destaque:
 >
 > **1. Buscar contrato no repositório primeiro:**
 > Procure por specs existentes nos seguintes locais:
-> - `docs/engineering/swagger/`
-> - `docs/engineering/openapi/`
+> - `$ENG_DOCS/swagger/`
+> - `$ENG_DOCS/openapi/`
 > - `**/*swagger*.{yaml,yml,json}`
 > - `**/*openapi*.{yaml,yml,json}`
 > - `**/*api-spec*.{yaml,yml,json}`
@@ -359,32 +362,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:
+## Central docs
 
-1. Perguntar ao usuário:
-   ```
-   Deseja publicar este ARD no repositório central de documentação?
-   - ( ) Sim, publicar agora
-   - ( ) Não, vou publicar depois manualmente
-   ```
+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.
 
-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}
-     ```
-   
-3. Informar resultado:
-   - ✅ Sucesso: "ARD 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 ard --feature {slug}`"
-
-> **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.

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

@@ -27,8 +27,7 @@ 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 |
 
 ---
 
@@ -59,11 +58,11 @@ Além disso, quando houver campo `Versão` no RFC, aplicar obrigatoriamente:
   - `Owner`
   - `Reviewers`
 - Defina o `RFC-ID` automaticamente assim:
-  - Se a pasta `$DOCS_FOLDER/engineering/RFC/` existir e houver arquivos no padrão `RFC-###-*.md`, use o maior `###` + 1.
+  - Se a pasta `$ENG_DOCS/RFC/` existir e houver arquivos no padrão `RFC-###-*.md`, use o maior `###` + 1.
   - Caso não exista ou não haja arquivos, iniciar em `RFC-001`.
 - Defina:
   - `Status` inicial = `Draft`
-  - `Caminho do arquivo` = `$DOCS_FOLDER/engineering/RFC/{RFC-ID}-{slug}.md`
+  - `Caminho do arquivo` = `$ENG_DOCS/RFC/{RFC-ID}-{slug}.md`
 
 ---
 
@@ -92,9 +91,9 @@ 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:
+1. Consultar no Central docs as funcionalidades já implementadas relacionadas (o que existe hoje):
    ```bash
    jarvis docs sync --silent
    ```
@@ -105,9 +104,9 @@ Se `CENTRAL_DOCS_REPO` definido no ENV.md:
    - Tags semânticas
 
 3. Documentos a buscar:
-   - **PRD relacionado** (para rastreabilidade e contexto de negócio)
-   - **ARD existente** (para consistência arquitetural)
-   - **RFCs anteriores** relacionados ao tema
+   - **Funcionalidades já implementadas** relacionadas (Central docs: `feature-*`)
+   - **PRD relacionado** (em `$PROD_DOCS`, para rastreabilidade e contexto de negócio)
+   - **ARD existente** e **RFCs anteriores** relacionados ao tema (em `$ENG_DOCS/ARD` e `$ENG_DOCS/RFC`)
 
 4. Se documentos encontrados:
    - Carregar automaticamente como contexto
@@ -221,32 +220,7 @@ Entregar:
 
 ---
 
-## Passo 7 – Publicar no Central Docs (condicional)
+## Central docs
 
-Se `CENTRAL_DOCS_REPO` definido no ENV.md **E** o usuário aprovar o RFC:
+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.
 
-1. Perguntar ao usuário:
-   ```
-   Deseja publicar este RFC 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: `RFC-001-wallet-idempotencia.md` → `wallet-idempotencia`)
-   - Executar:
-     ```bash
-     jarvis docs publish \
-       --file {caminho_do_rfc} \
-       --tipo rfc \
-       --feature {slug}
-     ```
-   
-3. Informar resultado:
-   - ✅ Sucesso: "RFC 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 rfc --feature {slug}`"
-
-> **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.

package/workflows/engineering/eng.pr.md

@@ -1,5 +1,5 @@
 ---
-description: Criação de branch, commit e merge request (MR)
+description: Gera o pull-request.md na sessão e, com o Sim do usuário, faz o push e abre o merge request (MR)
 auto_execution_mode: 3
 agent: "$IDE/agents/engineering/eng.agent.md"
 rules_file: "$IDE/rules-on-demand/engineering/eng.pr-rules.md"
@@ -43,8 +43,8 @@ Este comando cria a **branch, commita as alterações e abre um Merge Request**.
 | Fase 1 › 1.4 Executar Testes Automatizados (Opcional) | `/eng-qa` + `QA_SPECIALIZATIONS` | Passo opcional, recomendado em mudanças significativas |
 | Skills recomendados | `/eng-global-docs-write` | Se houver necessidade de atualizar documentação junto do PR |
 | Agentes recomendados (opcional) | `eng.qa.test-planner` (agente) | Se houver dúvidas sobre cobertura de testes ou mudanças significativas |
-| Fase 4 › 4.2 Criar MR/PR via adapter | `jarvis vcs create-merge` (CLI do Jarvis) | Sempre — abre o MR/PR conforme `VERSION_CONTROL` ou o host do `origin` |
-| Fase 6 › 6.2 Link do MR | `/eng-global-task-comment` | Depois de o MR ser criado: um único comentário no card com o link do MR, seguindo o Passo 6 do skill `eng-global-pr` (freelance pula) |
+| Fase 4 › 4.4 Criar MR/PR via adapter | `jarvis vcs create-merge` (CLI do Jarvis) | Só se o usuário responder **Sim** na Fase 4.3: abre o MR/PR conforme `VERSION_CONTROL` ou o host do `origin` |
+| Fase 6 › 6.2 Link do MR | `/eng-global-task-comment` | Depois de o MR ser criado (só com o Sim da 4.3): um único comentário no card com o link do MR, seguindo o Passo 6 do skill `eng-global-pr` (freelance pula) |
 
 ---
 
@@ -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`.
@@ -156,6 +156,8 @@ Refs: {TASK_MANAGER_KEY}"
 
 ## Fase 3: Push
 
+> ⚠️ O push só acontece **depois do Sim** da Fase 4.3. Esta fase descreve o comando; ele roda dentro da publicação.
+
 ### 3.1 Enviar para Remote
 
 ```bash
@@ -175,7 +177,9 @@ git log --oneline -3
 Ler `VERSION_CONTROL` do `$IDE/ENV.md` (`gitlab` | `github` | `bitbucket`).
 Use **MR** se GitLab, **PR** se GitHub/Bitbucket.
 
-### 4.1 Preparar descrição
+### 4.1 Gerar `pull-request.md` na sessão
+
+Escreva o título e a descrição do PR em **`$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/pull-request.md`** (primeira linha `# {título}`, depois o corpo). Se a sessão tiver o `gate-checklist.md` do `eng.pre-pr`, use o PR Brief e as decisões dele.
 
 Template, nesta ordem (o primeiro que existir):
 
@@ -199,21 +203,32 @@ Preencher com a tarefa. Link do card:
 
 > ⚠️ Não mencione AI, Claude ou assistentes no MR/PR.
 
-### 4.2 Criar MR/PR via adapter
+### 4.2 Revisão do texto
+
+Mostre o `pull-request.md` (título e resumo das seções) e pergunte com `AskUserQuestion`: `[Aprovar]` / `[Ajustar]`. Ajuste até a aprovação.
+
+### 4.3 Publicar? (Sim / Não)
+
+Pergunte com `AskUserQuestion` (**Sim / Não**): **"Publicar o PR agora?"**
+
+- **Não:** nada é enviado. O `pull-request.md` fica na sessão para você publicar quando quiser (à mão ou rodando o `/eng.pr` de novo). Pule para a Fase 7, com a mensagem "PR não publicado".
+- **Sim:** faça o push (Fase 3) e crie o MR/PR (4.4).
+
+### 4.4 Criar MR/PR via adapter
 
 - **Título**: `{TASK_MANAGER_KEY}: {Título da tarefa}`
 - **Branch origem**: `{NOME_DA_BRANCH}`
-- **Branch destino**: a informada pelo usuário (`dev` / `main` / hotfix)
-- **Descrição**: template preenchido, gravado em arquivo temporário
+- **Branch destino**: `{BRANCH_BASE}` (a `Branch base:` do `architecture.md`)
+- **Descrição**: o corpo do `pull-request.md` aprovado (sem a linha do título)
 
 ```bash
 BODY_FILE=$(mktemp)
-# gravar a descrição preenchida em $BODY_FILE
+tail -n +2 $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/pull-request.md > "$BODY_FILE"
 
 jarvis vcs create-merge \
   --source "${NOME_DA_BRANCH}" \
-  --target "${TARGET_BRANCH}" \
-  --title "${TASK_MANAGER_KEY}: ${TITULO_DA_TAREFA}" \
+  --target "${BRANCH_BASE}" \
+  --title "${TITULO_DO_PULL_REQUEST_MD}" \
   --body-file "$BODY_FILE"
 
 rm -f "$BODY_FILE"
@@ -326,65 +341,18 @@ fi
 {LEAD_TIME_MSG}
 
 📌 Próximos passos:
-1. Aguardar revisão do time
-2. Processar comentários do code review
+1. /eng.spec-consolidate {TASK_MANAGER_KEY} → registrar no Central docs o que esta entrega implementou
+2. Aguardar revisão do time e processar os comentários do code review
 3. Merge após aprovação
 
+🗂️ A sessão $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/ não é apagada (o /eng.spec-consolidate precisa dela).
+   Remova à mão quando quiser.
+
 🔗 Links:
 - MR: {LINK_DO_MR}
 - Jira: {TASK_MANAGER_URL_BASE}/browse/{TASK_MANAGER_KEY}
 ```
 
-## Fase 8: Limpeza da Sessão
-
-### 9.1 Solicitar Confirmação
-
-Após o MR ser criado com sucesso, **solicitar confirmação do usuário**:
-
-```
-🧹 Deseja limpar a sessão?
-
-A pasta $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/ será removida.
-A documentação permanece no Jira e no MR.
-
-Confirmar? (s/n)
-```
-
-> ⚠️ **IMPORTANTE**: Sempre pedir confirmação antes de executar comandos destrutivos.
-
-### 9.2 Remover Pasta da Sessão
-
-Se confirmado:
-
-```bash
-rm -rf $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/
-```
-
-**Exemplo:**
-
-```bash
-rm -rf $SESSIONS_DIR/eng/task-123/
-```
-
-### 9.3 Confirmar Limpeza
-
-```
-🧹 SESSÃO LIMPA!
-
-📁 Removido: $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/
-   - architecture.md ✅
-   - plan.md ✅
-   - context.md ✅ (se existia)
-
-ℹ️ A documentação permanece no:
-   - Card do Jira: {TASK_MANAGER_KEY}
-   - Merge Request: {LINK_DO_MR}
-```
-
-> ⚠️ **NOTA**: A documentação não é perdida! Ela está anexada no Jira e registrada no MR.
-
----
-
 ## Regras Importantes
 
 ### ⛔ NÃO FAÇA
@@ -403,7 +371,8 @@ rm -rf $SESSIONS_DIR/eng/task-123/
 - ✅ Criar branch no padrão `{TASK_MANAGER_KEY}-{titulo}`
 - ✅ Preencher template do MR completamente
 - ✅ Mover card para "In Review"
-- ✅ **Limpar sessão após criar MR** (`rm -rf $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/`)
+- ✅ Gerar o `pull-request.md` na sessão e só publicar com o **Sim** (Fase 4.3)
+- ✅ **Nunca apagar a sessão:** o `/eng.spec-consolidate` precisa dela
 
 ---