jarvis-ai-framework 4.0.0 → 5.0.0

package/skills/eng-global-docs-write/SKILL.md

@@ -100,7 +100,7 @@ ls -la docs/ 2>/dev/null || echo "Pasta docs/ não encontrada"
 - Comentários inline no código
 - Documentação de APIs
 - Exemplos e tutoriais
-- `docs/engineering/c4/` - Diagramas de arquitetura
+- `$ENG_DOCS/c4/` - Diagramas de arquitetura
 
 ---
 

package/skills/eng-qa-planner/SKILL.md

@@ -28,7 +28,7 @@ Garantir que todo código novo ou modificado possua cobertura de testes adequada
 ## Recursos
 
 - **Base**: [eng-qa](../eng-qa/SKILL.md) — princípios de risco e priorização usados aqui vêm da base
-- **Saída**: `$DOCS_FOLDER/engineering/qa/{task-id}-test_coverage_branch_report.md`
+- **Saída**: `$ENG_DOCS/qa/{task-id}-test_coverage_branch_report.md`
 
 ---
 
@@ -126,7 +126,7 @@ Determinar quais testes estão faltando:
 
 ### 5. Gerar o relatório
 
-Gerar arquivo `$DOCS_FOLDER/engineering/qa/{task-id}-test_coverage_branch_report.md`:
+Gerar arquivo `$ENG_DOCS/qa/{task-id}-test_coverage_branch_report.md`:
 
 ```markdown
 # Análise de Cobertura de Testes da Branch
@@ -232,7 +232,7 @@ describe('[Funcionalidade]', () => {
 - [ ] Diff da branch analisado (`git diff origin/main...HEAD`)
 - [ ] Cada arquivo alterado mapeado para seu teste correspondente (ou marcado como ausente)
 - [ ] Lacunas priorizadas por criticidade (alta/média/baixa)
-- [ ] Relatório gerado em `$DOCS_FOLDER/engineering/qa/{task-id}-test_coverage_branch_report.md`
+- [ ] Relatório gerado em `$ENG_DOCS/qa/{task-id}-test_coverage_branch_report.md`
 
 ---
 
@@ -240,7 +240,7 @@ describe('[Funcionalidade]', () => {
 
 | Artefato | Descrição |
 |----------|-----------|
-| `$DOCS_FOLDER/engineering/qa/{task-id}-test_coverage_branch_report.md` | Relatório de cobertura com plano de implementação priorizado |
+| `$ENG_DOCS/qa/{task-id}-test_coverage_branch_report.md` | Relatório de cobertura com plano de implementação priorizado |
 
 > O artefato é gerado na raiz do projeto ou no diretório especificado em `$ARGUMENTS`.
 
@@ -259,6 +259,6 @@ Prioridade alta: {N} cenários
 Prioridade média: {N} cenários
 Prioridade baixa: {N} cenários
 
-Relatório: $DOCS_FOLDER/engineering/qa/{task-id}-test_coverage_branch_report.md
+Relatório: $ENG_DOCS/qa/{task-id}-test_coverage_branch_report.md
 Próximo passo: implementar os testes do plano ou registrar uma especialização de execução em QA_SPECIALIZATIONS
 ```

package/skills/jarvis-docs-central/README.md

@@ -1,18 +1,18 @@
 # jarvis-docs-central
 
-Integração com o **Central docs**: a documentação aprovada (PRD, FRD, épicos, histórias, ARD, RFC) de todos os produtos do squad, com um índice que os outros comandos consultam.
+Integração com o **Central docs**: o registro do que **foi implementado** em cada produto do squad (um documento completo por funcionalidade e um registro por entrega), com um índice que os outros comandos consultam. Os documentos de trabalho (PRD, FRD, ARD, RFC) ficam em `docs/jarvis/` e não vão para lá.
 
 ## Visão Geral
 
-- **Buscar** documentos (`jarvis docs sync`, `jarvis docs fetch`)
-- **Publicar** documentos aprovados (`jarvis docs publish`)
+- **Buscar** o que já foi implementado (`jarvis docs sync`, `jarvis docs fetch`)
+- **Publicar** a consolidação de cada entrega (`jarvis docs publish`, pelo `/eng.spec-consolidate`)
 - **Índice** regenerado a cada publicação (`{SQUAD}/index.md`)
 
 O Central docs funciona por **adaptador de armazenamento**: hoje uma pasta do disco (`filesystem`). Se essa pasta for um clone de um repositório de documentação (tem `.git`), a publicação vira branch + commit + push + Pull/Merge Request. S3 e Google Drive são as issues #144 e #145.
 
 ## Configuração
 
-Pelo `/jarvis-init` (pergunta "Onde fica a documentação central?": pasta local, repositório git ou não usar), ou à mão no `ENV.md`:
+Ligado por padrão. O `/jarvis-init` (Passo 5.2) pergunta "Onde fica o Central docs?" (pasta local, repositório git ou desligar). À mão, no `ENV.md`:
 
 ```ini
 CENTRAL_DOCS_STORAGE=filesystem
@@ -28,7 +28,7 @@ WORKSPACE=loja                           # vira a pasta do produto
 | Modo de trabalho | Pasta padrão | Fora do versionamento por |
 |---|---|---|
 | Workspace (vários repositórios) | `./central-docs` | `central-docs/` no `.gitignore` do workspace |
-| Projeto único | `docs/jarvis/central-docs` | `docs/jarvis/*` no `.gitignore` do projeto |
+| Projeto único | `docs/jarvis/central-docs` | `docs/jarvis/` no `.gitignore` do projeto |
 
 > Com `.git`, o PR usa o token do vendor (GitLab `.npmrc`, GitHub `gh auth`/`GITHUB_TOKEN`, Bitbucket `BITBUCKET_TOKEN`). O token **nunca** vai no chat nem no `ENV.md`.
 
@@ -37,45 +37,33 @@ WORKSPACE=loja                           # vira a pasta do produto
 ## Comandos
 
 ```bash
-jarvis docs sync                                  # resumo do índice do squad
+jarvis docs sync                                  # resumo: funcionalidades e entregas recentes
 jarvis docs fetch CORE/index.md                   # conteúdo de um arquivo (exit 2 se não existir)
-jarvis docs publish --file ./docs/product/prd-001-checkout.md --tipo prd
-jarvis docs publish --file ./ard-001-x.md --tipo ard --produto outro-produto
-jarvis docs publish --file ./openapi.yaml --tipo swagger --feature api-wallet
+jarvis docs publish --file .../consolidation/feature-checkout.md --tipo feature            # pelo /eng.spec-consolidate
+jarvis docs publish --file .../consolidation/delivery-2026-10-15-task-123.md --tipo delivery
 ```
 
-- **Tipos:** `prd, frd, feat, epic, story, task` (vão para `product/`) e `ard, rfc, swagger, qa-report` (vão para `engineering/`).
-- **Nome no Central docs:** o do arquivo local, quando ele segue `{tipo}-{id}-{nome}`. Se não seguir, use `--feature {slug}`.
+- **Tipos:** só `feature` (vai para `product/`) e `delivery` (vai para `engineering/`). PRD, ARD e os outros documentos de trabalho são recusados.
+- Quem gera e publica é o [`/eng.spec-consolidate`](../../workflows/engineering/eng.spec-consolidate.md), depois do PR e do seu Sim.
 
 ## Estrutura e índice
 
 ```
 {SQUAD}/
-├── index.md                 # gerado; não editar
-├── product/{produto}/       # prd-, frd-, feat-, epic-, story-, task-
-├── engineering/{produto}/   # ard-, rfc-, swagger-, qa-report-
-└── context/                 # opcional
+├── index.md                                     # gerado; não editar
+├── product/{produto}/feature-{slug}.md          # funcionalidade: estado atual, completo
+└── engineering/{produto}/delivery-{data}-{key}.md   # registro de uma entrega
 ```
 
-```markdown
-# CORE
-
-## product
-
-### loja
-- [prd-001-checkout.md](product/loja/prd-001-checkout.md) | v1.0.0 | backlog | Checkout
-```
-
-Com `.git` e `scripts/build-index.sh` no repositório de documentação, o índice vem do script dele.
+O índice lista as funcionalidades e as 10 entregas mais recentes de cada produto. Com `.git` e `scripts/build-index.sh` no repositório de documentação, o índice vem do script dele.
 
 ## Integração com Workflows
 
 | Comando | Uso |
 |---|---|
-| `/warm-up` | `jarvis docs sync` (se `CENTRAL_DOCS_STORAGE` estiver configurado) |
-| `/eng.start`, `/eng.create-ard`, `/eng.create-rfc`, `/eng.build-tech-spec` | Buscar PRD, ARD e RFC relacionados |
-| `/prod.spec.*` | Buscar specs existentes e publicar a aprovada |
-| `/eng.pre-pr` | Oferecer a publicação de um ARD novo ou atualizado |
+| `/eng.spec-consolidate` | Gera e publica a funcionalidade e a entrega (e a carga inicial, `--inicial`) |
+| `/jarvis-init` | Liga o Central docs (Passo 5.2) e oferece a carga inicial |
+| `/warm-up`, `/eng.start`, `/prod.spec.*`, `/eng.create-ard`, `/eng.create-rfc`, `/eng.build-tech-spec` | Consultam as funcionalidades já implementadas |
 
 ## Arquitetura
 
@@ -86,7 +74,7 @@ bin/
 │   └── docs-publish.js        # jarvis docs publish
 └── lib/docs/
     ├── fetch-file.js          # openStorageFromEnv + fetchFile (jarvis docs fetch)
-    ├── publish-file.js        # tipos, destino e publicação
+    ├── publish-file.js        # tipos (feature, delivery), destino e publicação
     ├── validate-frontmatter.js
     └── storage/
         ├── index.js           # getStorage(env): escolhe o adaptador pelo CENTRAL_DOCS_STORAGE

package/skills/jarvis-docs-central/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: jarvis-docs-central
-description: Integração com o Central docs, a documentação aprovada (PRD, FRD, épicos, histórias, ARD, RFC) guardada por um adaptador de armazenamento (hoje uma pasta do disco, com git opcional). Busca, publica e indexa pelo CLI jarvis docs.
+description: Integração com o Central docs, o registro do que foi implementado (um documento completo por funcionalidade e um registro por entrega, gerados pelo /eng.spec-consolidate), guardado por um adaptador de armazenamento (hoje uma pasta do disco, com git opcional). Busca, publica e indexa pelo CLI jarvis docs.
 argument-hint: "[contexto da tarefa]"
 allowed-tools: Bash Read Write
 disable-model-invocation: false
 license: AGPL-3.0
 metadata:
   author: jarvis-team
-  version: "4.0"
+  version: "5.0"
   area: global
 ---
 
@@ -15,38 +15,46 @@ metadata:
 
 ## Objetivo
 
-Integrar os comandos do framework com o **Central docs**: o lugar onde fica a documentação aprovada de todos os produtos do squad, com um índice (`{SQUAD}/index.md`) que os outros comandos consultam.
+Integrar os comandos do framework com o **Central docs**: o registro do que **de fato foi implementado** em cada produto do squad, com um índice (`{SQUAD}/index.md`) que os outros comandos consultam.
 
-- Buscar documentos relevantes durante os workflows (Modo 1)
-- Publicar documentos aprovados (Modo 2)
-- Reparar o índice (Modo 3)
+**Duas camadas de documentação:**
+
+| Camada | O que é | Onde fica |
+|---|---|---|
+| Documentos de trabalho | PRD, FRD, épicos, histórias, ARD, RFC, QA, swagger, robôs, C4: o que se pretende e se discute | `docs/jarvis/` (`$PROD_DOCS`, `$ENG_DOCS`), fora do versionamento |
+| **Central docs** | O que foi implementado: um documento **completo e autossuficiente** por funcionalidade (estado atual) e um **registro por entrega** (PR, commits, autores) | Pasta do Central docs (adaptador) |
+
+Quem escreve no Central docs é o **`/eng.spec-consolidate`** (agente `eng.docs-consolidator`), logo depois do PR. Os documentos de trabalho nunca são publicados lá.
+
+**Modos deste skill:**
+- buscar o que já foi implementado (Modo 1);
+- publicar a consolidação (Modo 2);
+- reparar o índice (Modo 3).
 
 ## Adaptadores de armazenamento
 
-O Central docs não depende de um serviço: `CENTRAL_DOCS_STORAGE` escolhe o adaptador e `CENTRAL_DOCS_LOCATION` diz onde ele guarda. Os comandos são sempre os mesmos (`jarvis docs fetch | sync | publish`), venha o conteúdo de onde vier.
+`CENTRAL_DOCS_STORAGE` escolhe o adaptador e `CENTRAL_DOCS_LOCATION` diz onde ele guarda. Os comandos são sempre os mesmos (`jarvis docs fetch | sync | publish`).
 
 | `CENTRAL_DOCS_STORAGE` | `CENTRAL_DOCS_LOCATION` | Situação |
 |---|---|---|
-| *(vazio)* | — | Desligado: os comandos pulam em silêncio |
-| `filesystem` | Pasta (relativa à pasta do workspace ou absoluta) | Disponível |
-| `s3`, `gdrive` | — | Ainda não suportados (o comando para com a mensagem de "não suportado") |
+| `filesystem` (**padrão**) | Pasta (relativa à pasta do workspace ou absoluta) | Disponível |
+| *(vazio)* | — | Desligado: os comandos pulam em silêncio; o `/eng.spec-consolidate` orienta ligar |
+| `s3`, `gdrive` | — | Ainda não suportados (#144, #145) |
 
-**Camada git do `filesystem`:** se a pasta tiver `.git` (clone de um repositório de documentação), o adaptador:
-- faz `git pull --ff-only` em `CENTRAL_DOCS_REF` antes de ler (se falhar, avisa e lê a cópia local);
-- ao publicar: branch `docs/{caminho}` → cópia → índice → commit → push → Pull/Merge Request para `CENTRAL_DOCS_TARGET_BRANCH`, com `CENTRAL_DOCS_REVIEWERS` na descrição.
+**Camada git do `filesystem`:** se a pasta tiver `.git` (clone de um repositório de documentação):
+- antes de ler: `git pull --ff-only` em `CENTRAL_DOCS_REF` (se falhar, avisa e lê a cópia local);
+- ao publicar: branch → cópia → índice → commit → push → PR para `CENTRAL_DOCS_TARGET_BRANCH`.
 
 Sem `.git`, grava direto na pasta.
 
-**Onde fica a pasta** (o `/jarvis-init` sugere): no modo workspace, `./central-docs` (no `.gitignore` do workspace); no projeto único, `docs/jarvis/central-docs` (com `docs/jarvis/*` no `.gitignore`). Nunca no versionamento de um repositório de código.
+**Onde fica a pasta** (o `/jarvis-init` configura no Passo 5.2): no modo workspace, `./central-docs` (no `.gitignore` do workspace); no projeto único, `docs/jarvis/central-docs` (coberto por `docs/jarvis/` no `.gitignore`). Nunca no versionamento de um repositório de código.
 
 ## Pré-condição
 
 Ler do `$IDE/ENV.md`:
 - `CENTRAL_DOCS_STORAGE` e `CENTRAL_DOCS_LOCATION` (vazio: encerrar em silêncio)
 - `CENTRAL_DOCS_REF`, `CENTRAL_DOCS_TARGET_BRANCH`, `CENTRAL_DOCS_REVIEWERS` (só com `.git`)
-- `SQUAD` (ALL-CAPS-COM-HIFEN), `WORKSPACE` (vira a pasta do produto) e `AREA` (que tipos buscar)
-
-`ENV.md` da versão anterior (com a variável do repositório remoto e sem `CENTRAL_DOCS_STORAGE`): os comandos pedem o Upgrade do `/jarvis-init`, que faz a migração.
+- `SQUAD` (ALL-CAPS-COM-HIFEN) e `WORKSPACE` (vira a pasta do produto)
 
 Com `.git`, o PR usa o token do vendor pelo adaptador de VCS (GitLab `.npmrc`; GitHub `gh auth`/`GITHUB_TOKEN`; Bitbucket `BITBUCKET_TOKEN`). ❌ **Nunca** colar token no chat.
 
@@ -56,128 +64,105 @@ Com `.git`, o PR usa o token do vendor pelo adaptador de VCS (GitLab `.npmrc`; G
 
 ```
 {SQUAD}/
-├── index.md                          # GERADO a cada publicação — não editar à mão
+├── index.md                                   # GERADO a cada publicação — não editar à mão
 ├── product/
-│   └── {produto}/                    # WORKSPACE do ENV.md (ou --produto)
-│       ├── prd-{id}-{nome}.md
-│       ├── frd-{id}-{nome}.md
-│       ├── feat-{id}-{nome}.md
-│       ├── epic-{id}-{nome}.md
-│       ├── story-{id}-{nome}.md
-│       └── task-{id}-{nome}.md
-├── engineering/
-│   └── {produto}/
-│       ├── ard-{id}-{nome}.md
-│       ├── rfc-{id}-{nome}.md
-│       ├── swagger-{nome}.{md|yaml|json}
-│       └── qa-report-{nome}.md
-└── context/                          # opcional — formato livre
+│   └── {produto}/                             # WORKSPACE do ENV.md (ou --produto)
+│       └── feature-{slug}.md                  # funcionalidade: estado atual, completo
+└── engineering/
+    └── {produto}/
+        └── delivery-{AAAA-MM-DD}-{task_key}.md   # registro de uma entrega (PR)
 ```
 
-- **Nome do arquivo:** o do arquivo local, que já segue `{tipo}-{id}-{nome}.md` (`prod-rules.md`). Só quando o nome foge do padrão, `--feature {slug}` gera `{tipo}-{slug}.{ext}`.
-- **`{produto}`:** `WORKSPACE` (a pasta que contém o `$IDE/`), ou `--produto`.
+- Templates: `templates/engineering/central-feature-template.md` (11 seções) e `central-delivery-template.md` (7 seções).
+- `related_docs`/`feature` citam só o **basename**.
 
 ### Frontmatter obrigatório (validado no `publish`)
 
 | Tipo | Campos |
 |------|--------|
-| `prd` | `id`, `name`, `version`, `status` |
-| `frd`, `feat`, `epic` | `id`, `name`, `version`, `status`, `related_prd` |
-| `story` | `id`, `name`, `status`, `related_prd` |
-| `task` | `id`, `name`, `status` |
-| `ard` | `id`, `name`, `version`, `status` |
-| `rfc` | `Status`, `Criado em`, `Proponente` |
-| `qa-report` | `period`, `squad`, `version` |
+| `feature` | `id`, `name`, `status`, `product`, `updated_at` |
+| `delivery` | `id`, `feature`, `task_key`, `pr`, `date` |
 
-**Status reconhecidos:**
-- produto: `icebox`, `in_review`, `backlog`, `in_progress`, `in_production`, `cancelled`, `deprecated`;
-- ARD: `proposed`, `in_progress`, `in_review`, `approved`;
-- RFC: `Draft`, `In Review`, `Ready for Decision`, `Accepted`, `Rejected`, `Superseded`.
+Status da funcionalidade: a lista de produto (`icebox`, `in_review`, `backlog`, `in_progress`, `in_production`, `cancelled`, `deprecated`).
 
-Status fora da lista só gera aviso.
+### Índice
 
-**Campos `related_*`:** só o **basename** do arquivo (sem path nem `./`).
+O `{SQUAD}/index.md` é **regenerado** a cada publicação, a partir do frontmatter:
+- **`## product`:** as funcionalidades de cada produto (status, nome, data da última atualização);
+- **`## engineering`:** as **10 entregas mais recentes** de cada produto.
 
-### Índice
+Arquivos que não são `feature-*`/`delivery-*` ficam **fora** do índice. Exemplo: PRD e ARD publicados inteiros na versão 4.0.0, que podem ser apagados à mão ou transformados em funcionalidades pela carga inicial (`/eng.spec-consolidate --inicial`).
 
-O `{SQUAD}/index.md` é **regenerado** a partir do frontmatter de todos os documentos a cada publicação (nunca editado, para duas publicações não apagarem a entrada uma da outra). Com `.git` e um `scripts/build-index.sh` no repositório de documentação, o adaptador usa o script dele (o CI do repositório confere o índice com ele).
+Com `.git` e um `scripts/build-index.sh` no repositório de documentação, o adaptador usa o script dele.
 
 ```markdown
 # CORE
 
 ## product
 
+> Funcionalidades (estado atual)
+
 ### loja
-- [prd-001-checkout.md](product/loja/prd-001-checkout.md) | v1.0.0 | backlog | Checkout
+- [feature-checkout.md](product/loja/feature-checkout.md) | in_production | Checkout | 2026-10-15
 
 ## engineering
 
+> Entregas recentes
+
 ### loja
-- [ard-001-pagamentos.md](engineering/loja/ard-001-pagamentos.md) | v1.0.0 | approved | Pagamentos
+- [delivery-2026-10-15-task-123.md](engineering/loja/delivery-2026-10-15-task-123.md) | TASK-123 | 2026-10-15
 ```
 
 ---
 
 ## Quando Usar
 
-- `/warm-up`: carregar o contexto do produto (Modo 1)
-- `/eng.start`, `/eng.create-ard`, `/eng.create-rfc`, `/eng.build-tech-spec`: buscar PRD/ARD/RFC relacionados (Modo 1)
-- `/prod.spec.*`: buscar specs existentes e publicar a aprovada (Modos 1 e 2)
-- `/eng.pre-pr`: detectar ARD novo ou desatualizado e oferecer a publicação (Modo 2)
+- `/warm-up`, `/eng.start`, `/prod.spec.*`, `/eng.create-ard*`, `/eng.create-rfc`, `/eng.build-tech-spec`: conhecer o que **já foi implementado** (Modo 1)
+- `/eng.spec-consolidate`: publicar a consolidação de uma entrega ou a carga inicial (Modo 2)
 - Índice ausente ou divergente (Modo 3)
 
 ---
 
 ## Fluxo de Trabalho
 
-### Modo 1: Buscar docs
+### Modo 1: Buscar o que foi implementado
 
 ```bash
-jarvis docs sync                         # lê {SQUAD}/index.md e resume o que há
-jarvis docs fetch {SQUAD}/index.md       # conteúdo do índice
-jarvis docs fetch {SQUAD}/product/{produto}/prd-001-checkout.md
+jarvis docs sync                                           # resumo: funcionalidades e entregas recentes
+jarvis docs fetch {SQUAD}/index.md
+jarvis docs fetch {SQUAD}/product/{produto}/feature-checkout.md
 ```
 
-- Com `.git`, o primeiro acesso faz `pull`.
-- `docs fetch` sai com código **2** quando o arquivo não existe.
-
 1. Buscar o índice do squad.
-2. Identificar os documentos pelo `TASK_MANAGER_KEY`, pelo nome ou pelo produto; filtrar por `AREA`:
-   - `PRODUCT` → PRD, FRD, épicos e histórias;
-   - `ENGINEERING` → PRD (contexto), ARD e RFC.
-3. Buscar cada arquivo com `jarvis docs fetch`.
-4. Devolver o conteúdo carregado, com um resumo (squad, produto, documentos e versões).
+2. Identificar as funcionalidades relacionadas à tarefa (nome, produto, card citado no histórico).
+3. Buscar cada `feature-*` com `jarvis docs fetch` (e um `delivery-*`, se o detalhe de uma entrega importar).
+4. Devolver o resumo: funcionalidades, status e o que cada uma faz hoje.
+
+Os documentos de trabalho da tarefa (PRD, FRD, ARD, RFC) **não** estão aqui: leia-os em `$PROD_DOCS`/`$ENG_DOCS`.
+
+### Modo 2: Publicar a consolidação
 
-### Modo 2: Publicar doc
+Feito pelo `/eng.spec-consolidate`, depois do **Sim** do usuário:
 
 ```bash
-jarvis docs publish --file ./docs/product/prd-001-checkout.md --tipo prd
-jarvis docs publish --file ./docs/engineering/ARD/ard-001-pagamentos.md --tipo ard --produto loja
-jarvis docs publish --file ./openapi.yaml --tipo swagger --feature api-wallet
+jarvis docs publish --file .../consolidation/delivery-2026-10-15-task-123.md --tipo delivery
+jarvis docs publish --file .../consolidation/feature-checkout.md --tipo feature
 ```
 
-Tipos: `prd, frd, feat, epic, story, task` (em `product/`) e `ard, rfc, swagger, qa-report` (em `engineering/`).
+- Tipos aceitos: **`feature`** e **`delivery`**.
+- `prd`, `frd`, `ard`, `rfc` e os outros documentos de trabalho são recusados com a explicação.
+- `--produto` troca o `WORKSPACE`.
 
 **Fluxo:**
-1. Validar o frontmatter (tabela acima).
-2. Calcular o destino `{SQUAD}/{área}/{produto}/{nome}`.
-3. Sem `.git`: copiar o arquivo e regenerar `{SQUAD}/index.md`.
-4. Com `.git`:
-   1. `checkout` + `pull` de `CENTRAL_DOCS_TARGET_BRANCH`;
-   2. branch `docs/{SQUAD}/{área}/{produto}/{nome}`;
-   3. cópia + índice;
-   4. commit e push;
-   5. PR para `CENTRAL_DOCS_TARGET_BRANCH`;
-   6. voltar para a branch base.
-5. Mostrar o destino, o índice e a URL do PR (com `.git`).
-
-Antes de publicar, **confirmar com o usuário**. Sem `.git` não há PR: a confirmação é a única revisão.
+1. Validar o frontmatter.
+2. Calcular o destino.
+3. Sem `.git`: copiar e regenerar o índice.
+4. Com `.git`: branch, cópia, índice, commit, push e PR.
 
 ### Modo 3: Reparar o índice
 
-Quando o índice não existe ou não lista todos os documentos:
-- **Sem `.git`:** publicar de novo qualquer documento do squad regenera o índice. Na prática, o próximo `jarvis docs publish` já corrige.
-- **Com `.git`:** no clone, rodar `bash scripts/build-index.sh` (se existir) e abrir um PR `repair/index-{SQUAD}-{data}` com o índice atualizado.
+- **Sem `.git`:** a próxima publicação regenera o índice.
+- **Com `.git`:** no clone, rodar `bash scripts/build-index.sh` (se existir) e abrir um PR `repair/index-{SQUAD}-{data}`.
 
 ### Skills invocados durante a execução do skill
 
@@ -191,19 +176,17 @@ Quando o índice não existe ou não lista todos os documentos:
 
 ### Nunca
 
-- Publicar documento sem validar o frontmatter
+- Publicar documento de trabalho (PRD, FRD, ARD, RFC…) no Central docs
+- Publicar sem o Sim do usuário (Modo 2 é sempre pelo `/eng.spec-consolidate`)
 - Editar `{SQUAD}/index.md` à mão
 - Push direto para a branch base quando a pasta tem `.git` (sempre por PR)
-- Buscar docs com `CENTRAL_DOCS_STORAGE` vazio (encerrar em silêncio)
-- Inventar metadados (`version`, `status`, `id`)
-- Usar path em campos `related_*`
+- Inventar metadados; incluir e-mails, tokens ou valores de variáveis
 - Colocar o Central docs no versionamento de um repositório de código
 
 ### Sempre
 
-- Ler e publicar só pelo CLI (`jarvis docs fetch | sync | publish`), nunca lendo a pasta por fora do adaptador
+- Ler e publicar só pelo CLI (`jarvis docs fetch | sync | publish`)
 - Se o Central docs tiver `AGENTS.md` na raiz, lê-lo antes de operar
-- Confirmar com o usuário antes de publicar
 - Usar `SQUAD` em ALL-CAPS-COM-HIFEN
 
 ---
@@ -212,11 +195,11 @@ Quando o índice não existe ou não lista todos os documentos:
 
 | Mensagem | Causa | O que fazer |
 |---|---|---|
-| `Central docs desligado (CENTRAL_DOCS_STORAGE vazio)` | Não configurado | `/jarvis-init` → Central docs |
+| `Central docs desligado (CENTRAL_DOCS_STORAGE vazio)` | Desligado no ENV | `/jarvis-init` → Passo 5.2 |
 | `… não é mais usado. Rode o /jarvis-init e escolha Upgrade (C)` | `ENV.md` da versão anterior | `/jarvis-init` → Upgrade (C) |
 | `Armazenamento "s3" ainda não suportado` | Valor de `STORAGE` sem adaptador | Use `filesystem` |
 | `Pasta do Central docs não encontrada` | `LOCATION` errado ou pasta não criada | Criar a pasta ou ajustar `LOCATION` |
-| `Arquivo não encontrado no Central docs: {SQUAD}/index.md` | Squad sem publicação ainda | Publicar o primeiro documento |
+| `Arquivo não encontrado no Central docs: {SQUAD}/index.md` | Squad sem consolidação ainda | `/eng.spec-consolidate --inicial` ou consolidar a próxima entrega |
+| `O Central docs guarda só o que foi implementado` | Tentativa de publicar PRD/ARD/… | Gere a consolidação com `/eng.spec-consolidate` |
 | `Campos obrigatórios ausentes` | Frontmatter incompleto | Completar conforme a tabela |
-| `O arquivo "…" não segue o padrão` | Nome fora de `{tipo}-{id}-{nome}` | Renomear ou usar `--feature` |
 | `git pull`/`push` falhou (com `.git`) | Rede, permissão ou pasta suja | `git status` na pasta; o commit local fica para repetir |

package/skills/jarvis-init/SKILL.md

@@ -208,20 +208,24 @@ Identificar qual IDE o usuário está utilizando:
 
    Serão adicionadas ao final do ENV.md sem alterar os valores existentes.
    ```
-8. **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.
-9. **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.
-10. 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
    ```
-11. 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.
    ```
-12. 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**:
 
@@ -573,19 +577,7 @@ Token NÃO vai no ENV.md:
 Nunca grave TOKEN_VERSION_CONTROL (chave removida do template).
 ```
 
-**Central docs (onde fica a documentação aprovada — PRD, FRD, épicos, ARD, RFC):**
-```
-Onde fica a documentação central?
-A. Pasta local
-B. Repositório de documentação (git)
-C. Não usar → CENTRAL_DOCS_STORAGE= vazio
-```
-- **A ou B** → `CENTRAL_DOCS_STORAGE=filesystem` e `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`, e `central-docs/` no `.gitignore` do workspace;
-  - **projeto único** (só a raiz tem `.git`): `docs/jarvis/central-docs` (já coberto por `docs/jarvis/*` no `.gitignore`, ver Passo 5).
-- **A**: `mkdir -p {LOCATION}` e criar `{LOCATION}/AGENTS.md` mínimo explicando a estrutura `{SQUAD}/{product|engineering}/{produto}/` e que o `{SQUAD}/index.md` é gerado pelo `jarvis docs publish`.
-- **B**: pedir a URL do repositório e rodar `git clone {URL} {LOCATION}`. Se `{LOCATION}` já existir com `.git`, só usar. Perguntar `CENTRAL_DOCS_TARGET_BRANCH` (padrão `main`).
-- Nunca colocar o Central docs no versionamento de um repositório de código.
+**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`)
 
@@ -612,7 +604,8 @@ C. Não usar → CENTRAL_DOCS_STORAGE= vazio
 | `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_STORAGE` / `_LOCATION` | *(vazio = desligado)* | Central docs: `filesystem` + pasta (padrão por modo de trabalho) |
+| `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 |
@@ -678,14 +671,50 @@ 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. Modo de trabalho (detectado no Passo 3, Pergunta 1):
-#    - Projeto único (só a raiz tem .git): PROD_DOCS=docs/jarvis/product 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
-#    - Modo workspace: PROD_DOCS=$DOCS_FOLDER/$PROD_FOLDER_NAME (padrão do template) e, se o
-#      Central docs ficar dentro do workspace: grep -qxF 'central-docs/' .gitignore || echo 'central-docs/' >> .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
@@ -729,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=...
@@ -756,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:**
@@ -1105,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) |
 
 ---