jarvis-ai-framework 3.2.0 → 5.0.0

package/rules-on-demand/engineering/eng.pr-rules.md

@@ -279,7 +279,7 @@ O MR deve seguir o template em `$IDE/templates/engineering/PR-template.md`:
 - ✅ Verificar `git status` antes do commit
 - ✅ Usar mensagens de commit descritivas
 - ✅ Referenciar o TASK_MANAGER_KEY no commit
-- ✅ **Limpar sessão após criar MR**
+- ✅ Gerar o `pull-request.md` na sessão e publicar só com o **Sim**
 
 ---
 
@@ -316,40 +316,18 @@ Antes de considerar o PR completo:
 - [ ] Arquivos adicionados individualmente (não `git add .`)
 - [ ] Commit com mensagem padronizada
 - [ ] Commit referencia o TASK_MANAGER_KEY
-- [ ] Push realizado
-- [ ] MR criado com template preenchido
+- [ ] Push realizado (só com o Sim)
+- [ ] MR criado a partir do `pull-request.md` (só com o Sim)
 - [ ] Branch de destino correta
 - [ ] Card do Jira movido para "In Review"
 - [ ] Comentários de code review processados
-- [ ] **Sessão limpa** (`$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/` removida)
+- [ ] `pull-request.md` aprovado na sessão (e publicado, se o usuário respondeu Sim)
+- [ ] Lembrete do `/eng.spec-consolidate` na mensagem final
 
 ---
 
-## Limpeza da Sessão
+## Sessão e publicação
 
-### Por que limpar?
-
-1. **Evitar poluição**: Sessões antigas ocupam espaço e confundem
-2. **Fonte da verdade**: A documentação oficial está no Jira e no MR
-3. **Organizacão**: Manter apenas sessões ativas
-
-### O que é removido?
-
-```
-$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/
-├── architecture.md    → Removido
-├── plan.md            → Removido
-└── context.md         → Removido (se existir)
-```
-
-### Onde a documentação permanece?
-
-- **Card do Jira**: Tech spec anexada, comentários
-- **Merge Request**: Descrição, histórico de commits
-- **Código**: Comentários inline, docstrings
-
-### Comando de limpeza
-
-```bash
-rm -rf $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/
-```
+- O texto do PR fica em **`$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/pull-request.md`**, aprovado pelo usuário.
+- **Publicar (push + MR/PR) só com o Sim** do `AskUserQuestion` "Publicar o PR agora?". Com Não, o arquivo fica na sessão e nada é enviado.
+- **A sessão nunca é apagada por este comando:** o `/eng.spec-consolidate`, que roda em seguida, precisa do `architecture.md`, do `plan.md`, do `gate-checklist.md` e do `pull-request.md`. A pessoa apaga à mão quando quiser.

package/rules-on-demand/engineering/eng.pre-pr-rules.md

@@ -63,25 +63,21 @@ Confirmar que está na branch certa? (s/n)
 
 ## Regras de Validação
 
+### Só revisar
+
+O `eng.pre-pr` **aponta lacunas e não corrige nada**: não altera código, não escreve testes, não atualiza documentação e não publica no Central docs. Quem decide o que ajustar é o usuário.
+
 ### Escopo de Análise
 
-Avaliar **apenas** as mudanças da branch atual em relação ao branch base (`main`/`develop`):
+Avaliar **apenas** as mudanças da branch atual em relação à branch base (`Branch base:` do `architecture.md`; sem ele, perguntar):
 
 ```bash
-git diff main...HEAD
+git diff {BRANCH_BASE}...HEAD
 ```
 
 ### Evidências Obrigatórias
 
-Ao citar "testes passando" ou "validações OK", incluir:
-- Qual comando foi executado
-- Output do resultado (ou smoke test manual se não houver suíte)
-
-### Revalidação após Mudanças
-
-Se qualquer gate levar a mudanças de código, reexecutar obrigatoriamente:
-- Revisão técnica do código alterado
-- Testes/validações
+Cada lacuna cita onde está (`arquivo:linha`) ou o comando que a revelou e o resultado.
 
 ---
 
@@ -89,11 +85,8 @@ Se qualquer gate levar a mudanças de código, reexecutar obrigatoriamente:
 
 O workflow **deve sempre** terminar com:
 
-1. **Semáforo de status**:
-   - 🟢 Green: pronto para PR
-   - 🟡 Yellow: pode abrir PR com ressalvas documentadas
-   - 🔴 Red: bloqueado — listar o que impede o PR
-
-2. **Comentário no card só se a validação reprovar** (🔴 RED, bloqueio), com o motivo (via `/eng-global-task-comment`) — pular se freelance; GREEN e YELLOW não comentam
-
-3. **Aguardar permissão explícita** do usuário para prosseguir para `/eng.pr`
+1. **`gate-checklist.md`** em `$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/`:
+   - semáforo (🟢 / 🟡 / 🔴), resumo, lacunas por área (o quê, onde, por que importa, sugestão, severidade, **Decisão**), evidências e PR Brief.
+2. **Decisões do usuário** gravadas na coluna Decisão (Ajustar / Não ajustar + motivo).
+3. **Pergunta Sim / Não** (`AskUserQuestion`) para publicar o relatório como comentário na issue/card (`/eng-global-task-comment`). Nunca publicar sem a resposta. Freelance: só na sessão.
+4. **Aguardar permissão explícita** do usuário para prosseguir para `/eng.pr`.

package/rules-on-demand/product/prod.guided-rules.md

@@ -0,0 +1,104 @@
+> **Applies to:** HUB: all | POSITION: all | AREA: all | SQUAD: all
+
+# Regras do Modo Developer-Guided
+
+## Objetivo
+
+Definir como a IA conduz os comandos de produto quando o usuário escolheu o **Modo Developer-Guided** (Modo Fácil): uma conversa didática, para quem vem do código e quer aprender Product Management (PM, gestão de produto) enquanto faz.
+
+O Modo Fácil **não é um Jarvis simplificado**. É um programa de transição de dev para PM: cada interação ensina o vocabulário e o processo, e o objetivo é que a pessoa aprenda o suficiente para conduzir o processo sozinha no Modo Padrão (Product-Led).
+
+## Escopo
+
+- Vale **somente** quando `PROD_MODE=developer-guided` no `$IDE/ENV.md`. Com `PROD_MODE` vazio ou `product-led`, este arquivo não se aplica.
+- Vale em todos os comandos de `workflows/product/` (`prod.spec`, `prod.spec.discovery`, `.prd`, `.frd`, `.ard`, `.epic`, `.issue`, `.breakdown`, `.clarify`, `prod.roadmap.preview`) e no `eng.create-ard`.
+- Muda **a conversa**, não o documento: etapas, seções e conteúdo de cada documento seguem o workflow e o template, como no Modo Padrão.
+- Complementa `rules/product/prod-rules.md`. Onde as duas falam do mesmo assunto (formato das perguntas), esta prevalece.
+
+## Regras
+
+### Obrigatório
+
+#### Linguagem e ritmo
+
+- **Uma pergunta por vez.** Nunca juntar várias perguntas nem despejar blocos longos de texto. Espere a resposta antes de seguir.
+- **Termo real + explicação simples, sempre juntos.** Use o nome técnico de PM e explique na mesma frase. Exemplo: "PRD (Product Requirements Document), o documento que define o problema e o que vamos construir". A pessoa precisa absorver o vocabulário, não fugir dele.
+- Analogias com código funcionam bem: a pessoa é dev (ex.: "o FRD está para o PRD como a implementação está para a interface").
+
+#### Perguntas e opções
+
+Use `AskUserQuestion` em **toda transição de artefato** (ex.: FRD → ARD) e em **toda questão ou gate em aberto**. A ferramenta aceita até 4 opções, mais um "Outro" automático de texto livre:
+
+| Tipo de pergunta | Opções |
+|---|---|
+| Gate (seguir, pular, aprovar uma etapa) | `[Sim]` · `[Não]` · `[Explicar melhor]` + Outro = `[Dúvida]` |
+| Pergunta de conteúdo (ex.: "qual o público-alvo?") | até 3 respostas · `[Explicar melhor]` + Outro = `[Dúvida]` |
+
+- `[Explicar melhor]` aparece **sempre**.
+- `[Dúvida]` **é** o "Outro": a pessoa escreve a dúvida no texto livre.
+- Sem `AskUserQuestion` na IDE: use a tabela de `prod-rules.md`, com as mesmas opções nas linhas.
+
+#### Comportamento de cada opção
+
+| Opção | O que fazer |
+|---|---|
+| `[Sim]` | Seguir para o próximo passo. |
+| `[Não]` | Dizer em **uma frase** a consequência de pular (ex.: "Sem o FRD, o ARD fica sem base para decidir a arquitetura") e confirmar. Se a pessoa insistir, registrar o artefato como **pendente** e seguir. |
+| `[Explicar melhor]` | A pessoa pode digitar o que não entendeu (opcional). Com texto, explique aquele ponto; sem texto, explique o passo inteiro. Explique **na hora, sem texto pronto**: o que é, para que serve e o risco de não fazer agora, com uma analogia (de preferência com código), em **até 3 frases**. Depois, repita **a mesma** pergunta. |
+| `[Dúvida]` | Responda **só aquele ponto**, sem reiniciar o fluxo. Ao terminar, volte à pergunta original. |
+
+Nunca avance enquanto a pessoa não tiver esclarecido o que não entendeu.
+
+#### Mentoria entre artefatos
+
+Nunca pule de um artefato para outro sem avisar. Antes de cada transição:
+
+1. Apresente o próximo passo de forma leve.
+2. Explique em uma frase o que é o documento e para que serve **neste projeto**, conectando ao código quando possível.
+3. Dê o controle à pessoa com as opções de gate.
+
+#### Fechamento de cada iteração
+
+Ao terminar um documento, sem esperar pedido:
+
+1. Gere o documento completo.
+2. Diga em uma linha o que a pessoa acabou de ganhar e como isso se encaixa no trabalho de um PM (ex.: "Agora você tem o ARD: o registro de por que escolhemos essa arquitetura.").
+3. Peça a revisão: `[Aprovar]` · `[Ajustar]` · `[Explicar melhor]` + Outro = `[Dúvida]`.
+4. **Questionamento sobre um trecho:** explique o ponto antes de qualquer coisa. Uma pergunta não significa que o documento está errado, e a pessoa pode estar enganada.
+   - Documento correto: explique o porquê e diga claramente que não há o que mudar.
+   - A pessoa tem razão, ou a dúvida revelou falha ou ambiguidade no texto: explique e **sugira uma alteração**, dizendo o que mudaria e por quê.
+   - Opções: `[Entendi]` (mantém e volta à revisão) · `[Explicar melhor]` (outra analogia, até 3 frases, e repete a pergunta) · `[Sugerir alteração]`.
+   - `[Sugerir alteração]`: avalie se a mudança faz sentido (se não fizer, explique o motivo com honestidade), proponha o texto novo e **só aplique depois da confirmação**.
+   - Melhorias que a própria IA identificar também passam por `[Sugerir alteração]`, sempre com o que mudaria, por que ajuda e o risco de não mudar.
+5. Só avance para o próximo artefato depois da aprovação.
+
+#### Documento final e frontmatter
+
+- O documento gerado é **idêntico em qualidade e estrutura** ao do Modo Padrão: completo, técnico e denso. A simplicidade fica na conversa. O documento é o padrão que a pessoa terá de produzir sozinha depois.
+- Mantenha os comentários `#` do frontmatter que vêm do template. Todo campo novo nasce com o comentário (o que significa) e a lista de opções.
+- Ao mudar o valor de um campo durante a conversa (ex.: `status: in_review` → `backlog`), diga em uma frase o que a mudança significa.
+
+### Proibido
+
+- Simplificar, encurtar ou pular seções do documento final por causa do modo.
+- Alterar o documento sem confirmação, inclusive para aplicar uma melhoria proposta pela própria IA.
+- Sugerir uma alteração sem dizer o que muda, por que ajuda e o risco de não mudar.
+- Fazer várias perguntas de uma vez.
+- Perguntar, sugerir ou lembrar a troca para o Modo Padrão. A troca é manual (`/jarvis-init` ou `PROD_MODE` no `ENV.md`), quando a pessoa quiser.
+
+### Recomendado
+
+- Preferir exemplos do próprio projeto (código, telas, entidades) aos genéricos.
+- Quando a pessoa usar um termo errado, corrigir com gentileza, citando o termo certo junto com a explicação.
+
+## Exceções
+
+- Se a pessoa pedir explicitamente outro formato na conversa (ex.: "pode me perguntar tudo de uma vez"), siga o pedido naquele comando.
+- O aviso de modelo (`recommended_model`) não é deste arquivo: vale nos dois modos e está no topo de cada workflow.
+
+## Referências
+
+- `rules/product/prod-rules.md`: regras gerais de produto (ambiente, status, formato das perguntas)
+- `rules/product/prod.spec-rules.md`: princípios de escrita de spec
+- `templates/product/`: templates com o frontmatter comentado
+- `docs/produto/`: guia humano de cada comando (para quem mantém o framework)

package/skills/eng-backend-arch-c4/SKILL.md

@@ -42,7 +42,7 @@ Criar e manter documentação de arquitetura usando os 4 níveis do C4:
 
 - **Script de detecção**: `$IDE/scripts/detect-stack.sh`
 - **Template**: `$IDE/templates/engineering/c4-model-template.md`
-- **Saída**: `$DOCS_FOLDER/engineering/c4/`
+- **Saída**: `$ENG_DOCS/c4/`
 
 ### Exemplos de Output
 
@@ -84,7 +84,7 @@ Code      -> Quais classes/interfaces críticas?
 ### 1. Verificar Documentação Existente
 
 ```bash
-ls -la $DOCS_FOLDER/engineering/c4/ 2>/dev/null || echo "Nenhum diagrama C4"
+ls -la $ENG_DOCS/c4/ 2>/dev/null || echo "Nenhum diagrama C4"
 ls -la $DOCS_FOLDER/architecture/adr/ 2>/dev/null
 ```
 
@@ -318,7 +318,7 @@ git diff origin/main --name-only | grep -E "docker|config|src/(domain|infrastruc
 ```
 ✅ Diagrama C4 criado/atualizado!
 
-📄 Arquivo: $DOCS_FOLDER/engineering/c4/{arquivo}.md
+📄 Arquivo: $ENG_DOCS/c4/{arquivo}.md
 📊 Nível: {nivel}
 🏗️ Sistema: {nome}
 

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,313 +1,89 @@
 # jarvis-docs-central
 
-Integração com repositório centralizado de documentação canônica (PRDs, FRDs, ARDs, RFCs) — GitLab, GitHub ou Bitbucket.
+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
 
-Esta skill permite:
-- **Buscar** documentação do central-docs via API do vendor (GitLab / GitHub / Bitbucket)
-- **Publicar** documentos aprovados via MR/PR (git flow seguro)
-- **Sincronizar** automaticamente em /warm-up
+- **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`)
 
-## Pré-requisitos
+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.
 
-1. **Token VCS** (GitLab `.npmrc`, GitHub `gh auth` / `GITHUB_TOKEN`, Bitbucket `BITBUCKET_TOKEN`)
-2. **ENV.md** com variáveis do central-docs
+## Configuração
 
-> ℹ️ Cache local via `redis-cli` é opcional. Sem Redis, a busca vai direto na API.
-
-> ⚠️ Token **nunca** vai no chat. GitLab: `.npmrc`. GitHub: `gh auth` ou `GITHUB_TOKEN`. Bitbucket: `BITBUCKET_TOKEN`.
-
-### Configuração Mínima
+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
-# .windsurf/ENV.md
-CENTRAL_DOCS_REPO=https://gitlab.com/org/group/central-docs.git
+CENTRAL_DOCS_STORAGE=filesystem
+CENTRAL_DOCS_LOCATION=./central-docs     # relativo à pasta do workspace, ou absoluto
+# Só se a pasta tiver .git:
 CENTRAL_DOCS_REF=main
-CENTRAL_DOCS_TARGET_BRANCH=dev
-SQUAD=core
-WORKSPACE=meu-workspace
-```
-
-```ini
-# .npmrc (projeto ou ~/.npmrc)
-//gitlab.com/api/v4/packages/npm/:_authToken=glpat-seu-token-aqui
+CENTRAL_DOCS_TARGET_BRANCH=main
+CENTRAL_DOCS_REVIEWERS=
+SQUAD=CORE
+WORKSPACE=loja                           # vira a pasta do produto
 ```
 
-## Comandos Disponíveis
+| 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 |
 
-### Sincronizar Docs
+> 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`.
 
-```bash
-# Sincronizar docs do squad
-jarvis docs sync
-
-# Modo silencioso (sem output)
-jarvis docs sync --silent
+**Vindo da versão anterior (Central docs como repositório remoto)?** Rode `/jarvis-init` → Upgrade (C). Ele propõe `CENTRAL_DOCS_STORAGE=filesystem`, a pasta padrão e o `git clone` do repositório antigo.
 
-# Modo verbose (mostra conteúdo)
-jarvis docs sync --verbose
-```
-
-### Publicar Documento
+## Comandos
 
 ```bash
-# Publicar ARD
-jarvis docs publish \
-  --file ./docs/engineering/ard-api-wallet.md \
-  --tipo ard \
-  --feature api-wallet-auth-jwt
-
-# Publicar PRD
-jarvis docs publish \
-  --file ./docs/product/prd-gestao-carteiras.md \
-  --tipo prd \
-  --feature gestao-carteiras
-
-# Publicar Swagger/OpenAPI (YAML)
-jarvis docs publish \
-  --file ./docs/engineering/swagger/api-wallet.yaml \
-  --tipo swagger \
-  --feature wallet
-
-# Com override de squad/workspace:
-jarvis docs publish \
-  --file ./docs/engineering/ard-api-wallet.md \
-  --tipo ard \
-  --feature api-wallet-auth-jwt \
-  --squad core \
-  --workspace meu-workspace
-```
-
-**Tipos válidos:** `prd`, `frd`, `ard`, `rfc`, `swagger`
-
-## Estrutura do Repositório Central
-
-```
-central-docs/
-└── {squad}/
-    ├── index.md                      # Lista todos os docs do squad
-    ├── product/
-    │   └── {workspace}/
-    │       ├── prd-{feature}.md
-    │       └── frd-{feature}.md
-    └── engineering/
-        └── {workspace}/
-            ├── ard-{feature}.md
-            ├── rfc-{feature}.md
-            └── swagger-{feature}.md  (ou api-{service}.yaml / api-{service}.json)
-```
-
-**Exemplos reais:**
-
+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 .../consolidation/feature-checkout.md --tipo feature            # pelo /eng.spec-consolidate
+jarvis docs publish --file .../consolidation/delivery-2026-10-15-task-123.md --tipo delivery
 ```
-central-docs/
-└── core/
-    ├── index.md
-    ├── product/
-    │   └── gestao-de-carteiras/
-    │       ├── prd-gestao-carteiras.md
-    │       └── frd-gestao-carteiras-onboarding.md
-    └── engineering/
-        └── api-wallet/
-            ├── ard-api-wallet.md
-            └── rfc-api-wallet-idempotencia.md
-```
-
-## Formato do index.md
-
-O `index.md` fica na raiz do squad (`{squad}/index.md`) e lista todos os documentos organizados por área e produto:
-
-```markdown
-# core
-
-## product
 
-### gestao-de-carteiras
-- [prd-gestao-carteiras.md](product/gestao-de-carteiras/prd-gestao-carteiras.md) | v1.2.0 | in_progress | jira: WAL-001 | tags: carteiras,onboarding
-- [frd-gestao-carteiras-onboarding.md](product/gestao-de-carteiras/frd-gestao-carteiras-onboarding.md) | v1.0.0 | in_review | jira: WAL-123 | tags: onboarding,cadastro
+- **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.
 
-## engineering
+## Estrutura e índice
 
-### api-wallet
-- [ard-api-wallet.md](engineering/api-wallet/ard-api-wallet.md) | v2.1 | Finalizada | tags: arquitetura,rest,api
-- [rfc-api-wallet-idempotencia.md](engineering/api-wallet/rfc-api-wallet-idempotencia.md) | Accepted | tags: idempotencia,redis
 ```
-
-## Frontmatter Obrigatório
-
-### PRD/FRD
-
-```yaml
----
-id: PRD-001
-name: Gestão de Carteiras
-version: 1.2.0
-status: in_progress
-task_link: https://jira.com/WAL-001
-related_repo: api-wallet,wallet-worker
----
+{SQUAD}/
+├── 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
 ```
 
-### ARD/RFC
-
-```yaml
----
-Status: Proposta
-Data: 2026-03-10
-Autor: João Silva
-Versão: 1.0
----
-```
+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
 
-### /warm-up
-
-Carrega contexto do produto:
-
-```markdown
-✅ Docs sincronizados do central-docs
-📊 5 documentos disponíveis:
-   - 1 PRD(s)
-   - 1 FRD(s)
-   - 2 ARD(s)
-   - 1 RFC(s)
-```
-
-### /eng.start
-
-Busca docs relacionados ao Jira ID antes de iniciar feature.
-
-### /eng.pre-pr
-
-Detecta docs desatualizados e oferece publicação.
-
-## Troubleshooting
-
-### Token não encontrado
-
-```
-❌ Token GitLab não encontrado no .npmrc
-```
-
-**Solução:** Adicionar ao `.npmrc`:
-```
-//gitlab.com/api/v4/packages/npm/:_authToken=glpat-seu-token
-```
-
-### Arquivo não encontrado
-
-```
-❌ Arquivo não encontrado no central-docs: core/index.md
-```
-
-**Solução:** Verificar se o squad existe no central-docs ou criar o `index.md` do squad.
-
-### Frontmatter inválido
-
-```
-❌ Campos obrigatórios ausentes no frontmatter de ARD:
-  - Status
-  - Data
-```
-
-**Solução:** Adicionar campos obrigatórios ao YAML.
+| Comando | Uso |
+|---|---|
+| `/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
 
-### Componentes
-
 ```
 bin/
 ├── commands/
-│   ├── docs-sync.js           # CLI: jarvis docs sync
-│   └── docs-publish.js        # CLI: jarvis docs publish
-└── lib/
-    ├── utils/
-    │   ├── npmrc-parser.js    # Extrai token do .npmrc
-    │   └── git-parser.js      # Parseia URL GitLab
-    ├── vcs/
-    │   └── api.js             # fetchRawFile/createMergeRequest/commitFiles — GitLab/GitHub/Bitbucket
-    └── docs/
-        ├── validate-frontmatter.js  # Valida YAML
-        ├── redis-cache.js     # Cache best-effort via redis-cli (get/setex/del)
-        ├── fetch-file.js      # Busca via vcs/api.js — CLI: jarvis docs fetch
-        └── publish-file.js    # Publica via vcs/api.js + MR — CLI: jarvis docs publish
+│   ├── docs-sync.js           # jarvis docs sync
+│   └── docs-publish.js        # jarvis docs publish
+└── lib/docs/
+    ├── fetch-file.js          # openStorageFromEnv + fetchFile (jarvis docs fetch)
+    ├── 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
+        ├── filesystem.js      # pasta + camada git (pull, branch, commit, push, PR)
+        └── build-index.js     # gera {SQUAD}/index.md a partir do frontmatter
 ```
 
-### Fluxo de Publicação
-
-```
-1. Validar frontmatter YAML
-2. Extrair metadados (version, status, jira)
-3. Criar branch: docs/{squad}/{area}/{produto}/{tipo}-{feature}
-4. Commit via GitLab API:
-   - Adicionar arquivo em {squad}/{area}/{produto}/{tipo}-{feature}.md
-   - Atualizar {squad}/index.md
-5. Criar MR → dev
-6. Retornar URL do MR
-```
+Um adaptador novo (S3, Drive) implementa o mesmo contrato do `filesystem.js` (`fetch`, `list`, `publish`, `buildIndex`) e entra no `storage/index.js`.
 
-## Variáveis de Ambiente
-
-| Variável | Obrigatória | Padrão | Descrição |
-|----------|-------------|--------|-----------|
-| `CENTRAL_DOCS_REPO` | Sim | - | URL do repo GitLab |
-| `CENTRAL_DOCS_REF` | Não | `main` | Branch para leitura |
-| `CENTRAL_DOCS_TARGET_BRANCH` | Não | `dev` | Branch para MRs |
-| `CENTRAL_DOCS_CACHE_TTL` | Não | `3600` | TTL do cache (segundos) |
-| `SQUAD` | Sim | - | Squad do usuário |
-| `WORKSPACE` | Sim | - | Nome do workspace |
-
-## Exemplos Completos
-
-### Exemplo 1: Setup Inicial
-
-```bash
-# 1. Configurar token
-echo '//gitlab.com/api/v4/packages/npm/:_authToken=glpat-xxx' >> .npmrc
-
-# 2. Configurar ENV.md
-cat >> .windsurf/ENV.md << EOF
-CENTRAL_DOCS_REPO=https://gitlab.com/org/group/central-docs.git
-CENTRAL_DOCS_REF=main
-CENTRAL_DOCS_TARGET_BRANCH=dev
-EOF
-
-# 3. Sincronizar
-jarvis docs sync
-```
-
-### Exemplo 2: Publicar ARD
-
-```bash
-# 1. Criar ARD localmente
-cat > docs/engineering/ard-api-wallet-auth.md << EOF
----
-Status: Proposta
-Data: 2026-03-10
-Autor: João Silva
-Versão: 1.0
----
-
-# ARD-CORE-API-AUTH — Autenticação JWT
-
-...
-EOF
-
-# 2. Publicar
-jarvis docs publish \
-  --file docs/engineering/ard-api-wallet-auth.md \
-  --tipo ard \
-  --feature api-wallet-auth
-
-# 3. Resultado
-# ✅ MR criado: docs/core/engineering/api-wallet/ard-api-wallet-auth → dev
-# URL: https://gitlab.com/.../merge_requests/42
-```
-
-## Referências
+## Troubleshooting
 
-- [SKILL.md](SKILL.md) - Documentação completa da skill
-- [GitLab API Docs](https://docs.gitlab.com/ee/api/) - API do GitLab
+Ver a tabela "Troubleshooting" do `SKILL.md`.