jarvis-ai-framework 3.2.0 → 5.0.0

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

@@ -1,13 +1,13 @@
 ---
 name: jarvis-docs-central
-description: Integração com repositório centralizado de documentação (GitLab, GitHub ou Bitbucket). Busca e publica PRDs, FRDs, ARDs e RFCs via API do vendor.
+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: "3.0"
+  version: "5.0"
   area: global
 ---
 
@@ -15,274 +15,154 @@ metadata:
 
 ## Objetivo
 
-Integrar o framework com o repositório `central-docs` (`CENTRAL_DOCS_REPO`), permitindo:
-- Buscar docs relevantes automaticamente durante workflows
-- Publicar docs aprovados via MR com git flow seguro
-- Sincronização automática em /warm-up
+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.
 
-## Fonte de Verdade
+**Duas camadas de documentação:**
 
-> **Antes de qualquer operação**, leia `$CENTRAL_DOCS_REPO/AGENTS.md`.
-> Ele define o contrato completo do repositório: estrutura, naming, frontmatter e regras de índice.
-> Este skill implementa esse contrato — não o duplica.
+| 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) |
 
-## Pré-condição
-
-Ler do `$IDE/ENV.md`:
-- `CENTRAL_DOCS_REPO` — URL do repo (GitLab, GitHub ou Bitbucket; se vazio: encerrar silenciosamente)
-- `CENTRAL_DOCS_REF` — branch para leitura (padrão: `main`)
-- `VERSION_CONTROL` — fallback se o hostname da URL não identificar o vendor
-- `SQUAD` — squad do usuário (formato: ALL-CAPS-COM-HIFEN)
-- `WORKSPACE` — nome do workspace em kebab-case
-- `AREA` — define quais tipos de doc buscar
+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á.
 
-**Token VCS** (resolvido pelo adapter `bin/lib/utils/npmrc-parser.js` → `getVcsToken`):
-- GitLab: `.npmrc` `:_authToken=` ou `GITLAB_TOKEN`
-- GitHub: `gh auth token`, `GITHUB_TOKEN` ou `.npmrc` npm.pkg.github.com
-- Bitbucket: `BITBUCKET_TOKEN`
+**Modos deste skill:**
+- buscar o que já foi implementado (Modo 1);
+- publicar a consolidação (Modo 2);
+- reparar o índice (Modo 3).
 
-❌ **NUNCA** colar o token no chat.
+## Adaptadores de armazenamento
 
-Se `CENTRAL_DOCS_REPO` não estiver definido, encerrar silenciosamente sem erro.
+`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 |
+|---|---|---|
+| `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) |
 
-## Convenções do central-docs (resumo operacional)
+**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`.
 
-### Estrutura de pastas
-
-```
-{SQUAD}/
-├── index.md                          # GERADO — não editar à mão
-├── product/
-│   └── {produto-em-kebab}/
-│       ├── 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-em-kebab}/
-│       ├── ard-{id}-{nome}.md
-│       └── rfc-{id}-{nome}.md
-└── context/                          # opcional — só nasce com conteúdo
-    ├── CLAUDE.md
-    └── (pesquisas, dados, assets — formato livre)
-```
-
-**Squads válidos** (pastas raiz ALL-CAPS): detectados dinamicamente pelo script.
-Fonte de verdade: `taxonomy.md` na raiz do repo.
-
-### Naming de arquivos
-
-```
-{tipo}-{id}-{nome-em-kebab}.md
-```
+Sem `.git`, grava direto na pasta.
 
-Exemplos: `prd-001-minha-feature.md`, `ard-001-minha-api.md`, `story-TASK-4-meu-exemplo.md`
+**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.
 
-- Tipo sempre **lowercase**: `prd-`, `frd-`, `feat-`, `epic-`, `story-`, `task-`, `ard-`, `rfc-` , `swagger-`
-- Pasta de produto: `kebab-case`, um produto = uma pasta
+## Pré-condição
 
-### Frontmatter obrigatório
+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) e `WORKSPACE` (vira a pasta do produto)
 
-| Campo | PRD | FRD/FEAT/STORY | EPIC | TASK | ARD/RFC |
-|-------|-----|----------------|------|------|---------|
-| `id` | ✓ | ✓ | ✓ | ✓ | ✓ |
-| `name` | ✓ | ✓ | ✓ | ✓ | ✓ |
-| `version` | ✓ | ✓ | ✓ | ✓ | ✓ |
-| `status` | ✓ | ✓ | ✓ | ✓ | ✓ |
-| `created` / `updated` | ✓ | ✓ | ✓ | ✓ | ✓ |
-| `created_by` / `last_editor` | ✓ | ✓ | ✓ | ✓ | ✓ |
-| `related_prd` | – | ✓ | ✓ | – | – |
-| `related_epic` | – | – | – | ✓ | – |
+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.
 
-**Status válidos:** `draft`, `in_review`, `planejado`, `in_progress`, `in_production`, `icebox`, `deprecated`
+---
 
-**Campos `related_*`:** sempre apenas o **basename** do arquivo, sem path nem `./`.
-```yaml
-# ✅ Certo
-related_prd: prd-001-minha-feature.md
+## Estrutura do Central docs
 
-# ❌ Errado
-related_prd: ./prd-001-minha-feature.md
-related_prd: ../minha-feature/prd-001-minha-feature.md
 ```
-
-### Índices — regra crítica
-
-O arquivo `{SQUAD}/index.md` é **gerado pelo script** `scripts/build-index.sh`. **Nunca editar à mão.**
-
-```bash
-# Sempre rodar após qualquer add/move/remove de spec
-bash scripts/build-index.sh
+{SQUAD}/
+├── index.md                                   # GERADO a cada publicação — não editar à mão
+├── product/
+│   └── {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)
 ```
 
-O script detecta squads dinamicamente (pastas raiz ALL-CAPS) e gera um único `index.md` por squad lendo o frontmatter de todos os specs em `product/` e `engineering/`, e listando o conteúdo de `context/`.
+- 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**.
 
-O CI (`.gitlab-ci.yml`) **falha** se o `index.md` commitado divergir do que o script geraria.
+### Frontmatter obrigatório (validado no `publish`)
 
----
+| Tipo | Campos |
+|------|--------|
+| `feature` | `id`, `name`, `status`, `product`, `updated_at` |
+| `delivery` | `id`, `feature`, `task_key`, `pr`, `date` |
 
-## Quando Usar
+Status da funcionalidade: a lista de produto (`icebox`, `in_review`, `backlog`, `in_progress`, `in_production`, `cancelled`, `deprecated`).
 
-- `/warm-up` — carregar contexto do produto (Modo 1; aciona Modo 3 se índice ausente)
-- `/eng.start` — buscar PRD/ARD antes de iniciar feature (Modo 1)
-- `/eng.create-ard` — buscar PRD relacionado (Modo 1)
-- `/eng.pre-pr` — detectar docs desatualizados (Modo 1)
-- Publicação de doc aprovado (Modo 2)
-- Reparo de índices inconsistentes ou ausentes (Modo 3)
+### Índice
 
----
+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.
 
-## Fluxo de Trabalho
-
-### Modo 1: Buscar Docs (usado em warm-up, eng.start)
-
-**Passo 1 — Buscar índice do squad**
-
-```bash
-jarvis docs sync
-
-# Internamente chama fetchFile() de bin/lib/docs/fetch-file.js, equivalente a:
-jarvis docs fetch "${SQUAD}/index.md" "${CENTRAL_DOCS_REF}"
-```
+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`).
 
-**Passo 1.b — Fallback: navegar árvore (quando index.md não existe)**
+Com `.git` e um `scripts/build-index.sh` no repositório de documentação, o adaptador usa o script dele.
 
-Se `jarvis docs sync` retornar exit code 2 (arquivo não encontrado):
+```markdown
+# CORE
 
-```bash
-# Fallback: clonar o CENTRAL_DOCS_REPO e listar arquivos locais
-# (funciona igual em GitLab, GitHub e Bitbucket)
-git ls-tree -r --name-only "${CENTRAL_DOCS_REF}" -- "${SQUAD}/product/${WORKSPACE}" "${SQUAD}/engineering/${WORKSPACE}"
-```
+## product
 
-**Identificar docs por caminho (naming padrão):**
-- `engineering/{produto}/ard-*.md` → ARD
-- `engineering/{produto}/rfc-*.md` → RFC
-- `product/{produto}/prd-*.md` → PRD
-- `product/{produto}/frd-*.md` → FRD
-- `product/{produto}/feat-*.md` → FEAT
-- `product/{produto}/story-*.md` → STORY
-- `context/` → artefatos de contexto (pesquisas, dados, assets)
+> Funcionalidades (estado atual)
 
-**Passo 2 — Identificar docs relevantes**
+### loja
+- [feature-checkout.md](product/loja/feature-checkout.md) | in_production | Checkout | 2026-10-15
 
-Com base no contexto da tarefa (`TASK_MANAGER_KEY`, tags, descrição):
-- Buscar no `index.md` por `TASK_MANAGER_KEY` matching
-- Se não encontrar, buscar por tags semânticas
-- Filtrar por AREA:
-  - `PRODUCT` → PRDs e FRDs
-  - `ENGINEERING` → PRD (contexto) + ARDs + RFCs
+## engineering
 
-**Passo 3 — Buscar arquivos identificados**
+> Entregas recentes
 
-```bash
-jarvis docs fetch "${SQUAD}/product/${WORKSPACE}/prd-feature.md" "main"
-jarvis docs fetch "${SQUAD}/engineering/${WORKSPACE}/ard-feature.md" "main"
+### loja
+- [delivery-2026-10-15-task-123.md](engineering/loja/delivery-2026-10-15-task-123.md) | TASK-123 | 2026-10-15
 ```
 
-**Passo 4 — Retornar resultado**
-
-```markdown
-# Contexto Carregado do Central Docs
-
-## Squad: MEU-SQUAD / Produto: meu-produto
+---
 
-### PRD-001: Minha Feature (v1.2.0)
-[conteúdo do PRD]
+## Quando Usar
 
-### ARD-001: Arquitetura da Minha Feature (v1.5)
-[conteúdo do ARD]
-```
+- `/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)
 
 ---
 
-### Modo 2: Publicar Doc
+## Fluxo de Trabalho
 
-**Uso:**
+### Modo 1: Buscar o que foi implementado
 
 ```bash
-jarvis docs publish \
-  --file ./docs/engineering/ard-001-minha-feature.md \
-  --squad MEU-SQUAD \
-  --produto meu-produto \
-  --tipo ard
+jarvis docs sync                                           # resumo: funcionalidades e entregas recentes
+jarvis docs fetch {SQUAD}/index.md
+jarvis docs fetch {SQUAD}/product/{produto}/feature-checkout.md
 ```
 
-**Fluxo interno:**
-
-1. Validar frontmatter YAML (campos obrigatórios conforme tabela acima)
-2. Validar naming do arquivo (`{tipo}-{id}-{nome-em-kebab}.md`)
-3. Validar que `related_*` usam apenas basename
-4. Determinar destino: `{SQUAD}/engineering/{produto}/` ou `{SQUAD}/product/{produto}/`
-5. Criar branch `docs/{SQUAD}/{area}/{produto}/{tipo}-{id}-{nome}`
-6. Commit via API do vendor (GitLab / GitHub / Bitbucket) com o doc
-7. Rodar `bash scripts/build-index.sh` localmente no clone e incluir o `{SQUAD}/index.md` atualizado no mesmo commit atômico
-8. Criar MR → main
-9. Retornar URL do MR
+1. Buscar o índice do squad.
+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.
 
-**Commit atômico (doc + index):**
+Os documentos de trabalho da tarefa (PRD, FRD, ARD, RFC) **não** estão aqui: leia-os em `$PROD_DOCS`/`$ENG_DOCS`.
 
-```
-actions:
-  - { action: "create_or_update", file_path: "{SQUAD}/engineering/{produto}/ard-001-feature.md", content: "..." }
-  - { action: "create_or_update", file_path: "{SQUAD}/index.md", content: "..." }
-```
-
-> Usar `POST /repository/commits` com array `actions`.
-> O `index.md` é o output de `build-index.sh` — nunca construído manualmente.
+### Modo 2: Publicar a consolidação
 
-**Output:**
+Feito pelo `/eng.spec-consolidate`, depois do **Sim** do usuário:
 
-```
-✅ MR criado: docs/MEU-SQUAD/engineering/meu-produto/ard-001-minha-feature → main
-URL: {url do MR/PR retornada pelo adapter}
+```bash
+jarvis docs publish --file .../consolidation/delivery-2026-10-15-task-123.md --tipo delivery
+jarvis docs publish --file .../consolidation/feature-checkout.md --tipo feature
 ```
 
----
-
-### Modo 3: Reparar Índices
-
-> Detecta `{SQUAD}/index.md` ausente ou divergente e abre MR de reparo.
-
-**Quando ativar:**
-
-- Durante Modo 1, se o fallback de árvore encontrar docs que não aparecem no `index.md`
-- Durante warm-up, se `index.md` não existir
-- Quando o usuário pedir explicitamente
+- 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.
+2. Calcular o destino.
+3. Sem `.git`: copiar e regenerar o índice.
+4. Com `.git`: branch, cópia, índice, commit, push e PR.
 
-```
-1. Clonar ou usar clone local de central-docs
-2. Rodar: bash scripts/build-index.sh
-3. Comparar output com os index.md commitados (git diff)
-4. Se há divergência:
-   a. Criar branch: repair/index-{SQUAD}-{timestamp}
-   b. Commitar os index.md atualizados
-   c. Abrir MR → main
-5. Reportar ao usuário
-```
-
-> O `build-index.sh` detecta squads dinamicamente — não é necessário listar squads manualmente.
+### Modo 3: Reparar o índice
 
-**Output ao usuário:**
-
-```
-🔍 Verificando índices do central-docs (MEU-SQUAD)...
-
-⚠️  MEU-SQUAD/index.md divergente — 3 docs ausentes no índice
-
-📋 Abrindo MR de reparo...
-   Branch: repair/index-MEU-SQUAD-20260510
-   Arquivo: MEU-SQUAD/index.md
-
-✅ MR aberto:
-   URL: {CENTRAL_DOCS_REPO}/-/merge_requests/44
-```
+- **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
 
@@ -296,97 +176,30 @@ URL: {url do MR/PR retornada pelo adapter}
 
 ### Nunca
 
-- Publicar doc sem validar frontmatter
-- Push direto para main (sempre via MR)
-- Buscar docs se `CENTRAL_DOCS_REPO` vazio (encerrar silenciosamente)
-- Inventar metadados (version, status, id)
-- Editar `{SQUAD}/index.md` manualmente — sempre via `build-index.sh`
-- Usar path em campos `related_*` — sempre basename apenas
-- Usar squad em minúsculas (ex: `core`) — sempre ALL-CAPS-COM-HIFEN: `MEU-SQUAD`
-- Criar subpastas `engineering/index.md` ou `product/index.md` (não existem neste repo)
+- 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)
+- 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 `$CENTRAL_DOCS_REPO/AGENTS.md` antes de operar
-- Usar GitLab API (não `git archive` ou `git clone` desnecessário)
-- Invalidar cache local (`redis-cli`) ao publicar, se o comando existir
-- Seguir git flow (branch → MR → main)
-- Extrair token do `.npmrc` automaticamente
-- Validar naming do arquivo antes de publicar
-- Incluir `{SQUAD}/index.md` (gerado por `build-index.sh`) em todo commit de publicação
+- 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
+- Usar `SQUAD` em ALL-CAPS-COM-HIFEN
 
 ---
 
 ## Troubleshooting
 
-### Erro: Token VCS não encontrado
-
-GitLab: `.npmrc` `:_authToken=` ou `GITLAB_TOKEN`.
-GitHub: `gh auth login` ou `GITHUB_TOKEN`.
-Bitbucket: `BITBUCKET_TOKEN`.
-
-### Erro: index.md não encontrado (Modo 1)
-
-```
-❌ Arquivo não encontrado: MEU-SQUAD/index.md
-```
-
-**Causa:** Squad ainda sem docs publicados. Índice só existe após o primeiro `publish`.
-
-**Solução:** Publicar ao menos um doc via `jarvis docs publish`. O MR já incluirá o `index.md`.
-
-### Erro: Frontmatter inválido
-
-```
-❌ Campos obrigatórios ausentes: name, version, created_by
-```
-
-**Solução:** Adicionar campos conforme tabela de frontmatter obrigatório acima.
-
-### Erro: Naming inválido
-
-```
-❌ Nome do arquivo não segue o padrão: {tipo}-{id}-{nome-em-kebab}.md
-   Recebido: ARD-001-MinhaFeature.md
-   Esperado: ard-001-minha-feature.md
-```
-
-**Solução:** Renomear o arquivo seguindo o padrão lowercase com hífens.
-
-### CI falha com "Índices stale"
-
-```
-❌ Índices stale. Rode 'bash scripts/build-index.sh' localmente,
-   commita o resultado e empurre de novo.
-```
-
-**Solução:** O `{SQUAD}/index.md` no commit diverge do que o script geraria. Sempre incluir o output de `build-index.sh` no mesmo commit do doc.
-
----
-
-## Integração com Workflows
-
-### /warm-up
-
-```markdown
-Se CENTRAL_DOCS_REPO configurado:
-1. jarvis docs sync
-2. Exibir resumo de docs disponíveis do squad/produto
-```
-
-### /eng.start
-
-```markdown
-Se CENTRAL_DOCS_REPO definido:
-- Buscar docs relacionados ao `TASK_MANAGER_KEY` no index.md do squad
-- Carregar PRD + ARDs relevantes antes de criar architecture.md
-```
-
-### /eng.pre-pr
-
-```markdown
-1. Detectar mudanças arquiteturais no diff
-2. Verificar se ARD local existe e está atualizado vs central-docs
-3. Se desatualizado ou novo: perguntar "Publicar no central-docs?"
-4. Se sim: jarvis docs publish
-```
+| Mensagem | Causa | O que fazer |
+|---|---|---|
+| `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 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 |
+| `git pull`/`push` falhou (com `.git`) | Rede, permissão ou pasta suja | `git status` na pasta; o commit local fica para repetir |