jarvis-ai-framework 3.2.0 → 5.0.0

package/skills/jarvis-init/SKILL.md

@@ -195,12 +195,12 @@ Identificar qual IDE o usuário está utilizando:
 3. Ler `HUB` do ENV.md existente
 4. Se `HUB≠DATA`: excluir do diff todas as chaves `DATA_*` — não propor adicioná-las
 5. Calcular diff: chaves no template que **não existem** no ENV.md atual (respeitando exclusão de DATA_* para não-DATA)
-4. Se não houver diff:
+6. Se não houver diff:
    ```
    ✅ ENV.md já está atualizado. Nenhuma variável nova encontrada.
    ```
    Oferecer o **passo 9 (adicionar as stacks)**, que a pessoa pode pular, e então encerrar.
-5. Se houver diff, exibir prévia:
+7. Se houver diff, exibir prévia:
    ```
    🔍 Variáveis novas encontradas no template:
      + NOVA_VAR_1=
@@ -208,18 +208,24 @@ Identificar qual IDE o usuário está utilizando:
 
    Serão adicionadas ao final do ENV.md sem alterar os valores existentes.
    ```
-6. Appender as novas variáveis ao final do `ENV.md` com comentário de data:
+8. **Exceção — documentos nos caminhos antigos:** procure documentos de trabalho em `$DOCS_FOLDER/product`, `$DOCS_FOLDER/engineering/{ARD,RFC,qa,swagger,openapi,robots,c4}` e `docs/engineering/{robots,swagger,openapi,c4}`.
+   - Se houver, liste o que encontrou e pergunte com `AskUserQuestion` se move para `docs/jarvis/…` (`$PROD_DOCS` e `$ENG_DOCS/…`). Use `git mv` quando o arquivo for versionado e `mv` quando não for, e garanta `docs/jarvis/` no `.gitignore`.
+   - **Sem confirmação, não mova nada:** grave `PROD_DOCS`/`ENG_DOCS` apontando para os caminhos antigos.
+   - Depois, ofereça a carga inicial do Central docs (Passo 5.3).
+9. **Exceção — Central docs antigo:** se o `ENV.md` tiver `CENTRAL_DOCS_REPO` preenchido e não tiver `CENTRAL_DOCS_STORAGE`, propor a migração (só com confirmação): `CENTRAL_DOCS_STORAGE=filesystem`, `CENTRAL_DOCS_LOCATION` com o padrão do modo de trabalho (Passo 4, "Central docs") e `git clone {CENTRAL_DOCS_REPO} {LOCATION}`. Depois, comentar a linha antiga (`# CENTRAL_DOCS_REPO=… (migrado em YYYY-MM-DD)`) e `CENTRAL_DOCS_CACHE_TTL`. Sem confirmação, não mexe e avisa que os comandos de docs vão pedir o Upgrade.
+10. **Exceção — `PROD_MODE`:** se `PROD_MODE` estiver entre as chaves novas, faça a mesma pergunta do Passo 3 (Pergunta 8 — modo de condução) e grave a resposta no lugar do valor vazio. As demais chaves continuam sem pergunta.
+11. Appender as novas variáveis ao final do `ENV.md` com comentário de data:
    ```
    # --- Upgrade YYYY-MM-DD ---
    NOVA_VAR_1=
    NOVA_VAR_2=valor-padrão
    ```
-7. Confirmar:
+12. Confirmar:
    ```
    ✅ ENV.md atualizado! N variável(is) nova(s) adicionada(s).
    ⚠️ Preencha os valores em branco antes de usar os novos recursos.
    ```
-8. Oferecer o **passo 9 (adicionar as stacks)**, que a pessoa pode pular, e então encerrar (não continuar para o fluxo de onboarding completo).
+13. Oferecer o **passo 9 (adicionar as stacks)**, que a pessoa pode pular, e então encerrar (não continuar para o fluxo de onboarding completo).
 
 **⚠️ OBRIGATÓRIO - Criação do ENV.md**:
 
@@ -261,6 +267,7 @@ Fluxo correto:
 - **IDE** (7 opções) → mostrar em texto numerado
 - **SQUAD** (do taxonomy) → mostrar em texto numerado
 - **POSITION** (do taxonomy) → mostrar em texto numerado
+- **PROD_MODE** (2 opções: product-led, developer-guided) → AskUserQuestion, sempre perguntado e sem opção sugerida
 
 ```
 // Exemplo 1: HUB (5 opções) - MOSTRAR EM TEXTO
@@ -401,6 +408,15 @@ Pergunta 7 (opções fixas - POSITION do taxonomy - texto se >4):
 
 *[Mostrar TODAS as opções de POSITION do taxonomy.md e aguardar]*
 
+```
+Pergunta 8 (opções fixas - 2 opções - usar AskUserQuestion) — PROD_MODE:
+Como você quer que os comandos de produto (prod.*) e o eng.create-ard conduzam a conversa?
+- Product-Led: para PMs. Fluxo direto, com os termos de PM, sem explicações extras.
+- Developer-Guided: para devs e futuros PMs. Uma pergunta por vez, explicando cada termo e etapa enquanto você faz.
+```
+
+*[Perguntar **sempre**, para qualquer `AREA` e qualquer `POSITION` (inclusive `GENERALIST` e PM). **Não** marcar nenhuma opção como recomendada nem sugerir padrão por área ou cargo. Gravar `PROD_MODE=product-led` ou `PROD_MODE=developer-guided`.]*
+
 **Regras de Implementação:**
 - **Opções fixas com ≤4 opções** → usar AskUserQuestion
 - **Opções fixas com >4 opções** (HUB com DATA, IDE, SQUAD, POSITION) → mostrar em texto numerado
@@ -424,6 +440,7 @@ Pergunta 7 (opções fixas - POSITION do taxonomy - texto se >4):
 | `MAX_AI_EXECUTION_PERCENTAGE` | Limite de execução da AI | Número entre 60 e 100 |
 | `USER` | Identidade do usuário (email ou nome) | ENV.md → git `user.email` → usuário do SO. Sem login |
 | `POSITION` | Cargo do usuário | Deve estar em `taxonomy.md` → Positions. Autonomia ponta a ponta em qualquer cargo |
+| `PROD_MODE` | Modo de condução dos comandos de produto e do `eng.create-ard` | `product-led` ou `developer-guided`. Sempre perguntado, sem opção sugerida (Pergunta 8) |
 
 > **💡 Nota**:
 > - As opções para SQUAD, HUB, AREA e POSITION são definidas em `taxonomy.md` e podem ser customizadas por organização.
@@ -560,6 +577,8 @@ Token NÃO vai no ENV.md:
 Nunca grave TOKEN_VERSION_CONTROL (chave removida do template).
 ```
 
+**Central docs:** não é perguntado aqui. Ele é ligado por padrão e configurado no **Passo 5.2**, que roda sempre.
+
 #### Variáveis Opcionais (alinhar ao `templates/ENV-template.md`)
 
 | Variável | Valor Padrão | Descrição |
@@ -585,7 +604,9 @@ Nunca grave TOKEN_VERSION_CONTROL (chave removida do template).
 | `TEST_FOLDER` | *(vazio)* | Pasta de testes |
 | `QA_SIGNOFF_BRANCHES` / `QA_SIGNOFF_MAX_AGE` | `main,release/*` / `24` | Sign-off QA |
 | `JARVIS_PROJECT` | `https://github.com/phelipperibeiro/jarvis-framework` | Repo do framework (`/jarvis-report-issue`) |
-| `CENTRAL_DOCS_REPO` / `_REF` / `_TARGET_BRANCH` / `_REVIEWERS` / `_CACHE_TTL` | *(opcional)* | Docs centrais |
+| `CENTRAL_DOCS_STORAGE` / `_LOCATION` | `filesystem` / pasta padrão do modo de trabalho | Central docs (o que foi implementado), configurado no Passo 5.2; vazio = desligado |
+| `JARVIS_DOCS` / `ENG_DOCS` | `$DOCS_FOLDER/jarvis` / `$JARVIS_DOCS/engineering` | Documentos de trabalho (não perguntar; `docs/jarvis/` no `.gitignore`) |
+| `CENTRAL_DOCS_REF` / `_TARGET_BRANCH` / `_REVIEWERS` | `main` / `main` / *(vazio)* | Só quando a pasta do Central docs tem `.git` |
 | `SESSIONS_DIR` | `.jarvis/sessions` | Não perguntar — gravar fixo |
 | `RTK_ENABLED` | `false` (ou true se detectar `rtk`) | Token Killer |
 | `ADVISOR_MODELS` | `"Sonnet 5.5,Opus 5.5,Opus 5,Fable 5.1"` | Advisor do `eng.start` — não perguntar, gravar o padrão |
@@ -649,8 +670,51 @@ cat templates/ENV-template.md
 mkdir -p .jarvis/sessions/eng .jarvis/sessions/prod .jarvis/sessions/qa
 # Garantir .jarvis/ no .gitignore do workspace
 grep -qxF '.jarvis/' .gitignore 2>/dev/null || echo '.jarvis/' >> .gitignore
+
+# 8. Documentos de trabalho em docs/jarvis/ — nos DOIS modos de trabalho:
+#    JARVIS_DOCS=$DOCS_FOLDER/jarvis, PROD_DOCS=$JARVIS_DOCS/product, ENG_DOCS=$JARVIS_DOCS/engineering
+#    (valores do template) e docs/jarvis/ fora do versionamento (uma docs/ já existente não é tocada):
+grep -qxF 'docs/jarvis/' .gitignore 2>/dev/null || echo 'docs/jarvis/' >> .gitignore
+```
+
+### 5.2 Central docs (sempre)
+
+O Central docs é **ligado por padrão**: é onde fica o registro do que **foi implementado**, gerado pelo `/eng.spec-consolidate` depois de cada PR. Explique em uma frase ao usuário:
+
+```
+📚 Central docs: o registro do que foi implementado (um documento completo por funcionalidade
+e um por entrega), consultado pela IA e por outros squads. Os rascunhos (PRD, FRD, ARD, RFC)
+ficam em docs/jarvis/ e não vão para lá.
 ```
 
+Pergunte com `AskUserQuestion`:
+- **"Onde fica o Central docs?"**
+  - A) Pasta local (padrão)
+  - B) Repositório de documentação (git)
+  - C) Desligar
+
+**A ou B:**
+- `CENTRAL_DOCS_STORAGE=filesystem`.
+- `CENTRAL_DOCS_LOCATION` com o padrão do **modo de trabalho** (a pessoa pode digitar outro caminho):
+  - **modo workspace** (2+ subpastas com `.git`): `./central-docs`, com `central-docs/` no `.gitignore` do workspace;
+  - **projeto único** (só a raiz tem `.git`): `docs/jarvis/central-docs`, já coberto por `docs/jarvis/` no `.gitignore`.
+- **A:** `mkdir -p {LOCATION}` e criar `{LOCATION}/AGENTS.md` mínimo, explicando:
+  - a estrutura `{SQUAD}/product/{produto}/feature-*.md` e `{SQUAD}/engineering/{produto}/delivery-*.md`;
+  - que o `{SQUAD}/index.md` é gerado pelo `jarvis docs publish`.
+- **B:** pedir a URL e rodar `git clone {URL} {LOCATION}`. Se `{LOCATION}` já existir com `.git`, só usar. Perguntar `CENTRAL_DOCS_TARGET_BRANCH` (padrão `main`).
+
+**C:** `CENTRAL_DOCS_STORAGE=` vazio. O `/eng.spec-consolidate` fica indisponível até ligar.
+
+Nunca coloque o Central docs no versionamento de um repositório de código.
+
+### 5.3 Carga inicial do Central docs (se houver documentos)
+
+Com o Central docs ligado:
+1. Procure PRD, FRD, ARD e RFC em `$PROD_DOCS`, `$ENG_DOCS/{ARD,RFC}` (e nos caminhos antigos, se não foram movidos).
+2. Se encontrar algum, mostre a contagem e pergunte com `AskUserQuestion` (**Sim / Não**): **"Gerar o Central docs agora a partir desses documentos?"**
+3. Com **Sim**, chame `/eng.spec-consolidate --inicial`. Ele agrupa os documentos por funcionalidade, gera um `feature-*.md` por grupo (sem registro de entrega, porque não há PR) e só publica depois da revisão e do seu Sim.
+4. Com **Não**, siga. Dá para rodar o `/eng.spec-consolidate --inicial` depois.
+
 **⚠️ REGRA CRÍTICA — Bloco DATA:**
 
 ```javascript
@@ -694,6 +758,8 @@ FLOWS_FOLDER={commands|workflows}
 TEMPLATES_FOLDER=templates
 RULES_FOLDER=.$IDE/rules
 SESSIONS_DIR=.jarvis/sessions
+JARVIS_DOCS=$DOCS_FOLDER/jarvis
+ENG_DOCS=$JARVIS_DOCS/engineering
 PROD_FOLDER_NAME=product
 PROD_RULES=...
 PROD_FLOWS=...
@@ -721,11 +787,13 @@ RULES_FOLDER=.$IDE/rules
 SESSIONS_DIR=.jarvis/sessions
 ENABLE_CDD=true
 
+JARVIS_DOCS=$DOCS_FOLDER/jarvis
+ENG_DOCS=$JARVIS_DOCS/engineering
 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
 ```
 
 **⚠️ IMPORTANTE - FLOWS_FOLDER por IDE:**
@@ -1070,6 +1138,7 @@ Apresentar checklist de onboarding por período (Dia 1, Semana 1, Mês 1).
 
 | Passo | Skill | Condição |
 |-------|-------|----------|
+| Passo 5.3 — Carga inicial do Central docs | `/eng.spec-consolidate --inicial` | Se o Central docs estiver ligado, houver PRD/FRD/ARD/RFC e o usuário responder Sim (também no Upgrade, depois da migração) |
 | Passo 9 — Adicionar as stacks (opcional) | `/jarvis-create-specialization {área} {stack}` | Se a pessoa escolher criar um skill novo para uma stack que ainda não tem especialização instalada (uma stack por vez; pular o passo não chama nada) |
 
 ---
@@ -1234,7 +1303,10 @@ Pergunta 6: Qual o limite de execução da AI? (60-100)
 Pergunta 7: Qual seu cargo?
 [mostrar opções em texto numerado]
 
-Pergunta 8 (opcional): Usa task manager? jira/linear/github/asana ou Nenhum (freelance)
+Pergunta 8: Modo dos comandos de produto?
+[AskUserQuestion: Product-Led | Developer-Guided, sem opção sugerida]
+
+Pergunta 9 (opcional): Usa task manager? jira/linear/github/asana ou Nenhum (freelance)
 ```
 
 **Agente**: *(cria ENV.md + `.jarvis/sessions/{eng,prod,qa}`, valida Context7, cria AGENTS.md e confirma)*
@@ -1281,6 +1353,7 @@ Bem-vindo! 🎉
 - [ ] **Perguntou UMA variável POR VEZ** (nunca fez múltiplas perguntas juntas)
 - [ ] **Usou AskUserQuestion só para ≤4 opções** (AREA se aplicável — HUB com DATA vai em texto)
 - [ ] **Mostrou em texto numerado para >4 opções** (HUB, IDE, SQUAD, POSITION)
+- [ ] **Perguntou o `PROD_MODE`** (Product-Led ou Developer-Guided), sem opção sugerida, qualquer que seja a área ou o cargo
 - [ ] **Mostrou TODAS as opções disponíveis** (HUB inclui DATA; nunca omitiu)
 - [ ] **Incluiu descrição útil em cada opção** (seja AskUserQuestion ou texto)
 - [ ] **Validou respostas em texto contra lista de opções válidas**

package/templates/ENV-template.md

@@ -57,12 +57,25 @@ 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_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)
+#   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 -------------------------------------------------
@@ -197,12 +210,20 @@ QA_SIGNOFF_MAX_AGE=24
 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=
+# --- 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); 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, 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=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
-# 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,17 +1,50 @@
+---
+# 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
+**Arquivo:** $ENG_DOCS/ARD/ARD-xxx-nome-da-arquitetura.md
 
 ---
 
 ## 🏗️ 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/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/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 |