jarvis-ai-framework 4.0.0 → 5.0.0

package/templates/ENV-template.md

@@ -57,14 +57,19 @@ RULES_FOLDER=.$IDE/rules
 # Cookie/HTTP session (auth) NÃO é esta pasta.
 SESSIONS_DIR=.jarvis/sessions
 
+# Documentos de trabalho gerados pelos comandos (PRD, FRD, épicos, ARD, RFC, QA, swagger,
+# robôs, C4…): sempre em $DOCS_FOLDER/jarvis/, nos dois modos de trabalho, com docs/jarvis/
+# no .gitignore (o /jarvis-init garante). O que foi implementado vai para o Central docs.
+JARVIS_DOCS=$DOCS_FOLDER/jarvis
+# Engenharia: ARD/, RFC/, qa/, swagger/, openapi/, robots/, c4/
+ENG_DOCS=$JARVIS_DOCS/engineering
+
 # 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
+PROD_DOCS=$JARVIS_DOCS/$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)
@@ -205,17 +210,18 @@ QA_SIGNOFF_MAX_AGE=24
 JARVIS_PROJECT=https://github.com/phelipperibeiro/jarvis-framework
 
 
-# --- Central docs (opcional) -------------------------------------------------
-# Onde fica a documentação canônica (PRD, FRD, épicos, ARD, RFC). Em branco = desligado.
+# --- Central docs -------------------------------------------------------------
+# O registro do que FOI IMPLEMENTADO: um documento completo por funcionalidade e um registro
+# por entrega, gerados pelo /eng.spec-consolidate depois de cada PR. Ligado por padrão.
 # 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_STORAGE: filesystem (s3 e gdrive virão nas issues #144 e #145); vazio = desligado
 #   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).
+#     ou docs/jarvis/central-docs (projeto único, coberto por 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=
+CENTRAL_DOCS_STORAGE=filesystem
+CENTRAL_DOCS_LOCATION=./central-docs
 # Só quando a pasta tem .git: branch lida no pull e branch base dos PRs.
 CENTRAL_DOCS_REF=main
 CENTRAL_DOCS_TARGET_BRANCH=main

package/templates/engineering/ARD-template.md

@@ -36,7 +36,7 @@ last_editor: [nome]
 
 # 🧱 ARD Template — Architecture Requirement Document
 
-**Arquivo:** /docs/engineering/ARD/ARD-xxx-nome-da-arquitetura.md
+**Arquivo:** $ENG_DOCS/ARD/ARD-xxx-nome-da-arquitetura.md
 
 ---
 

package/templates/engineering/central-delivery-template.md

@@ -0,0 +1,65 @@
+---
+# 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 da entrega. Padrão: DEL-{AAAA-MM-DD}-{task_key}
+id: {DEL-AAAA-MM-DD-task_key}
+
+# Documento da funcionalidade que esta entrega atualizou (basename).
+feature: {feature-slug.md}
+
+# Card ou número de controle da tarefa (TASK_MANAGER do ENV.md; freelance = número de controle).
+task_key: {TASK-123}
+
+# URL do card no task manager (padrão da eng.integrations-rules.md). Vazio no modo freelance.
+card_url: {URL}
+
+# Pull/Merge Request: número e URL (VERSION_CONTROL / remote origin).
+pr: {#n URL}
+
+# Branch de trabalho e branch base (Branch base: do architecture.md).
+branch: {branch}
+base: {main | dev | outra}
+
+# Data da consolidação (YYYY-MM-DD).
+date: {YYYY-MM-DD}
+---
+
+# Entrega {task_key}: {título}
+
+> Registro **autossuficiente** do que esta entrega fez. O estado atual da funcionalidade fica em [{feature-slug.md}](../../product/{produto}/{feature-slug.md}).
+
+## 1. O que a entrega fez
+
+{Resumo completo em linguagem de produto e de engenharia: o que passou a existir ou mudou.}
+
+## 2. Decisões tomadas
+
+| Questão | Decisão | Por quê |
+|---|---|---|
+| {das Questões em Aberto do architecture.md e das decisões do card} | {…} | {…} |
+
+## 3. Commits
+
+| Commit | Autor | Data | Mensagem |
+|---|---|---|---|
+| `{hash curto}` | {nome (sem e-mail)} | {AAAA-MM-DD} | {mensagem} |
+
+## 4. Arquivos alterados
+
+{Resumo do `git diff --stat {base}...HEAD`, agrupado por área (código, testes, docs, config).}
+
+## 5. Fora do escopo e follow-ups
+
+{O que ficou para depois, com card quando existir.}
+
+## 6. Testes e validação
+
+{Comandos rodados e resultados; testes manuais; o que ficou para validar.}
+
+## 7. Referências
+
+- Card: [{TASK_KEY}]({URL})
+- PR/MR: [#{n}]({URL})
+- Documentos de trabalho de origem (referência): {basenames}

package/templates/engineering/central-feature-template.md

@@ -0,0 +1,86 @@
+---
+# 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 da funcionalidade no Central docs (estável; não muda entre entregas). Ex.: FEAT-checkout
+id: {FEAT-slug}
+
+# Nome da funcionalidade, como as pessoas a chamam. Vai no título.
+name: {Nome da funcionalidade}
+
+# Em que ponto a funcionalidade está (lista em rules/product/prod-rules.md).
+# Opções: icebox | in_review | backlog | in_progress | in_production | cancelled | deprecated
+# in_progress = parte entregue, ainda em evolução | in_production = em produção
+# deprecated = esteve em produção e foi descontinuada
+status: {um dos valores acima}
+
+# Produto (pasta do Central docs): o WORKSPACE do ENV.md, ou o informado no comando.
+product: {produto}
+
+# Data da última consolidação (YYYY-MM-DD).
+updated_at: {YYYY-MM-DD}
+
+# Registro da última entrega consolidada (nome do arquivo delivery-*.md). Vazio na carga inicial.
+last_delivery: {delivery-AAAA-MM-DD-task_key.md}
+
+# Documentos de trabalho de origem, só como referência (basename). O entendimento NÃO depende deles.
+related_docs: {prd-001-nome.md, frd-001-nome.md, ARD-001-nome.md, RFC-001-nome.md}
+---
+
+# {Nome da funcionalidade}
+
+> Documento **autossuficiente**: descreve o que está implementado hoje. Se os documentos de origem (PRD, FRD, ARD, RFC) se perderem, este documento basta. Escrito para humanos e para IAs: frases completas, termos definidos, nada implícito.
+
+## 1. Visão geral
+
+{O problema que a funcionalidade resolve, para quem, e o valor entregue. 3 a 6 frases.}
+
+## 2. Comportamento atual
+
+{O que o sistema faz hoje, regra por regra, fluxo por fluxo. Use listas "Quando X, o sistema Y". Inclua os estados de erro e os casos de borda tratados. Critérios de aceite cumpridos.}
+
+## 3. Requisitos não funcionais atendidos
+
+| Requisito | Como foi atendido | Evidência |
+|---|---|---|
+| {desempenho, segurança, acessibilidade, limites…} | {…} | {teste, medição, arquivo} |
+
+## 4. Arquitetura e decisões
+
+{Componentes envolvidos e como conversam. Cada decisão relevante com o porquê e as alternativas descartadas (ex.: vindas do ARD, do RFC e das questões do architecture.md).}
+
+## 5. Onde está no código
+
+| Parte | Caminho | O que faz |
+|---|---|---|
+| {módulo, endpoint, comando, job} | `{caminho/arquivo}` | {…} |
+
+## 6. Configuração e dependências
+
+{Variáveis de ambiente (só nomes, nunca valores), flags, serviços externos, migrações, permissões.}
+
+## 7. O que mudou em relação ao especificado
+
+{Diferenças entre o que os documentos de trabalho pediam e o que foi implementado, e por quê. "Nenhuma" se não houver.}
+
+## 8. Fora do escopo e limitações conhecidas
+
+{O que a funcionalidade não faz (de propósito ou por limitação), com o motivo. Follow-ups abertos, com card.}
+
+## 9. Testes e evidências
+
+{Como a funcionalidade é verificada: suítes, cenários cobertos, testes manuais. Onde ficam.}
+
+## 10. Histórico de entregas
+
+| Data | Card | PR/MR | Autores | Resumo | Registro |
+|---|---|---|---|---|---|
+| {AAAA-MM-DD} | [{TASK_KEY}]({URL do card}) | [#{n}]({URL do PR/MR}) | {nomes} | {1 frase} | [delivery-…](../../engineering/{produto}/delivery-….md) |
+
+## 11. Glossário e referências
+
+- **{Termo}:** {definição}
+- Cards: {TASK_KEY com URL}
+- PRs/MRs: {números com URL}
+- Documentos de origem (referência): {basenames}

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_STORAGE` 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) |
 
 ---
@@ -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

@@ -23,7 +23,6 @@ priorizando a **arquitetura observada no código do repositório**, usando o tem
 |-------|-------|----------|
 | 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_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 |
 
 ---
 
@@ -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` (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)
+  - `Caminho do arquivo` (`$ENG_DOCS/ARD/{ARD-ID}-{slug}.md` ou caminho fornecido para iteração)
 
 ---
 
@@ -71,20 +70,20 @@ priorizando a **arquitetura observada no código do repositório**, usando o tem
 
 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,30 +235,7 @@ Entregar:
 
 ---
 
-## Passo 7 – Publicar no Central Docs (condicional)
+## Central docs
 
-Se `CENTRAL_DOCS_STORAGE` 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**:
-   - Executar:
-     ```bash
-     jarvis docs publish \
-       --file {caminho_do_ard} \
-       --tipo ard
-     ```
-   
-3. Informar resultado:
-   - ✅ 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`"
-
-> **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

@@ -29,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_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 |
+| 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 |
 
 ---
 
@@ -50,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**:
@@ -65,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.
+  - 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` (`$DOCS_FOLDER/engineering/ARD/{ARD-ID}-{slug}.md` ou caminho fornecido para iteração)
+- `Caminho do arquivo` (`$ENG_DOCS/ARD/{ARD-ID}-{slug}.md` ou caminho fornecido para iteração)
 
 ---
 
@@ -114,7 +113,7 @@ Regras:
    - `ARD-ID`
    - `Título`
    - `Status` (campo `status` no frontmatter)
-   - `Caminho do arquivo` (`$DOCS_FOLDER/engineering/ARD/{ARD-ID}-{slug}.md` ou caminho fornecido para iteração)
+   - `Caminho do arquivo` (`$ENG_DOCS/ARD/{ARD-ID}-{slug}.md` ou caminho fornecido para iteração)
 
 ---
 
@@ -124,20 +123,20 @@ Regras:
 
 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)
@@ -264,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}`
@@ -363,30 +362,7 @@ Peça explicitamente para o usuário:
 
 ---
 
-## Passo 8 – Publicar no Central Docs (condicional)
+## Central docs
 
-Se `CENTRAL_DOCS_STORAGE` 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**:
-   - Executar:
-     ```bash
-     jarvis docs publish \
-       --file {caminho_do_ard} \
-       --tipo ard
-     ```
-   
-3. Informar resultado:
-   - ✅ 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`"
-
-> **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

@@ -28,7 +28,6 @@ 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_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" |
 
 ---
 
@@ -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`
 
 ---
 
@@ -94,7 +93,7 @@ Regras:
 
 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_STORAGE` 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,30 +220,7 @@ Entregar:
 
 ---
 
-## Passo 7 – Publicar no Central Docs (condicional)
+## Central docs
 
-Se `CENTRAL_DOCS_STORAGE` 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**:
-   - Executar:
-     ```bash
-     jarvis docs publish \
-       --file {caminho_do_rfc} \
-       --tipo rfc
-     ```
-   
-3. Informar resultado:
-   - ✅ 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`"
-
-> **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.