spec-first-copilot 0.6.0-beta.9 → 0.7.0

package/templates/.github/templates/specs/tasks.template.md

@@ -1,63 +1,65 @@
-# Tasks — {{NOME}}
-
-> Plano de implementação: todas as tasks em tabela única com coluna Área.
-> Gerado pelo /sf-plan a partir do SDD + specs/{{NOME}}/. NUNCA editado manualmente.
-
----
-
-<!--
-=============================================================================
-INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
-=============================================================================
-
-ORIGEM: /sf-plan — deriva de sdd.md + contracts.md + scenarios.md
-ATUALIZAÇÃO: /sf-plan re-roda se SDD/contracts/scenarios mudarem.
-
-STATUS: vive em workspace/Output/{{NOME}}/Progresso.md — NÃO aqui.
-Tasks são só a definição do que precisa ser feito, não o estado atual.
-
-CAMPOS OBRIGATÓRIOS (toda task):
-- ID:       {ÁREA}-NNN sequencial por área (DB-001, BACK-001, FRONT-001, INFRA-001)
-- Área:     derivada do SDD — dinâmica, não fixa. Só as áreas que esta feature toca.
-- Fase:     número da fase de entrega (do PRD §11). 1 fase = 1 entregável = 1 PR.
-            Em bootstrap (PRD empty): toda task vai pra Fase 1 (setup inicial).
-- Tam:      S (≤2h) | M (≤4h) | L (≤2 dias)
-- Título:   verbo imperativo + objeto ("Criar migration tabela pedidos")
-- Repo:     nome do serviço em projetos.yaml (api, web, worker...)
-- Arquivos: paths relativos ao repo que serão criados/modificados
-- Depende:  IDs de tasks que precisam estar concluídas antes. Cross-área OK.
-- Ref SDD:  seção do SDD que originou a task (ex: "§4.2", "§Área-BACK"). Obrigatório.
-- Ref CA:   ID do CA em scenarios.md que esta task satisfaz. Opcional
-            (INFRA/DOC costumam não ter; BACK/FRONT normalmente têm).
-
-PARA TASKS TAMANHO L:
-- Preencher bloco "Done When — {TASK-ID}" logo abaixo da tabela
-- L sugere: considerar dividir em 2 tasks M (INVEST: Small)
-- Reviewer usa "Done When" como checklist antes de aprovar
-
-REGRAS:
-- IDs estáveis — nunca renumerar após commit
-- Toda task com Ref CA deve ter teste correspondente (unit ou integration)
-- Mesma fase = podem rodar em paralelo dentro da área
-- Fases são SEQUENCIAIS entre si
-- Áreas são dinâmicas — preencher apenas as tocadas pela feature
-
-=============================================================================
--->
-
-## Tasks
-
-| ID | Área | Fase | Tam | Título | Repo | Arquivos | Depende de | Ref SDD | Ref CA |
-|----|------|------|-----|--------|------|----------|-----------|---------|--------|
-|    |      |      |     |        |      |          | —         |         | —      |
-
-## Done When — Tasks L
-
-<!-- 1 bloco por task L. Remover esta seção inteira se não houver tasks L.
-3-5 bullets verificáveis. Cada bullet deve ser observável objetivamente. -->
-
-### {TASK-ID}
-
-- [ ] 
-- [ ] 
-- [ ] 
+# Tasks — {{NOME}}
+
+> Plano de implementação: todas as tasks em tabela única com coluna Área.
+> Gerado pelo /sf-plan a partir de PRD + TRD + specs/{{NOME}}/. NUNCA editado manualmente.
+
+---
+
+<!--
+=============================================================================
+INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
+=============================================================================
+
+ORIGEM: /sf-plan — deriva de PRD.md + TRD.md + contracts.md + scenarios.md
+ATUALIZAÇÃO: /sf-plan re-roda se PRD/TRD/contracts/scenarios mudarem.
+
+STATUS: vive em workspace/Output/{{NOME}}/Progresso.md — NÃO aqui.
+Tasks são só a definição do que precisa ser feito, não o estado atual.
+
+CAMPOS OBRIGATÓRIOS (toda task):
+- ID:       {ÁREA}-NNN sequencial por área (DB-001, BACK-001, FRONT-001, INFRA-001)
+- Área:     derivada dos GATEs do TRD §2-§5 — dinâmica, só as áreas tocadas.
+- Fase:     número da fase de entrega (do PRD §10). 1 fase = 1 entregável = 1 PR.
+            Se scope não tem PRD (puro-técnico): toda task vai pra Fase 1.
+- Tam:      S (≤2h) | M (≤4h) | L (≤2 dias)
+- Título:   verbo imperativo + objeto ("Criar migration tabela pedidos")
+- Repo:     nome do serviço em projetos.yaml (api, web, worker...)
+- Arquivos: paths relativos ao repo que serão criados/modificados
+- Depende:  IDs de tasks que precisam estar concluídas antes. Cross-área OK.
+- Ref TRD:  seção do TRD que originou a task (ex: "§2.1", "§4.1"). Obrigatório
+            quando existe TRD (quase sempre — scopes puro-produto são raros).
+- Ref CA:   ID do CA em scenarios.md que esta task satisfaz. Opcional
+            (INFRA costuma não ter; BACK/FRONT normalmente têm).
+
+PARA TASKS TAMANHO L:
+- Preencher bloco "Done When — {TASK-ID}" logo abaixo da tabela
+- L sugere: considerar dividir em 2 tasks M (INVEST: Small)
+- Reviewer usa "Done When" como checklist antes de aprovar
+
+REGRAS:
+- IDs estáveis — nunca renumerar após commit
+- Toda task com Ref CA deve ter teste correspondente (unit ou integration)
+- Mesma fase = podem rodar em paralelo dentro da área
+- Fases são SEQUENCIAIS entre si
+- Áreas são dinâmicas — preencher apenas as tocadas pela feature
+- Fase vem do PRD §10; task sem PRD correspondente (infra pura) usa Fase 1
+
+=============================================================================
+-->
+
+## Tasks
+
+| ID | Área | Fase | Tam | Título | Repo | Arquivos | Depende de | Ref TRD | Ref CA |
+|----|------|------|-----|--------|------|----------|-----------|---------|--------|
+|    |      |      |     |        |      |          | —         |         | —      |
+
+## Done When — Tasks L
+
+<!-- 1 bloco por task L. Remover esta seção inteira se não houver tasks L.
+3-5 bullets verificáveis. Cada bullet deve ser observável objetivamente. -->
+
+### {TASK-ID}
+
+- [ ] 
+- [ ] 
+- [ ] 

package/templates/_gitignore

@@ -1,35 +1,35 @@
-# Insumos brutos do usuário — conteúdo nunca vai pro repositório
-# A pasta workspace/Input/ existe no repo (via .gitkeep), mas seu conteúdo é ignorado
-workspace/Input/**
-!workspace/Input/.gitkeep
-!workspace/Input/**/.gitkeep
-
-# Memory pessoal (opcional — commit napkin.md se quiser compartilhar com o time)
-# .ai/memory/napkin.md
-
-# Repositórios de serviços (clonados/criados pelo workflow — cada um tem seu próprio .git)
-projetos/
-
-# MCP config — contém credenciais hardcoded (Confluence token, etc.)
-.mcp.json
-
-# Logs internos do workflow (append-only, gerados pelos commands)
-.ai/load-log.md
-.ai/publish-log.md
-
-# IDEs
-.vscode/
-.idea/
-
-# OS
-.DS_Store
-Thumbs.db
-
-# Node
-node_modules/
-dist/
-
-# Env
-.env
-.env.*
-!.env.example
+# Insumos brutos do usuário — conteúdo nunca vai pro repositório
+# A pasta workspace/Input/ existe no repo (via .gitkeep), mas seu conteúdo é ignorado
+workspace/Input/**
+!workspace/Input/.gitkeep
+!workspace/Input/**/.gitkeep
+
+# Memory pessoal (opcional — commit napkin.md se quiser compartilhar com o time)
+# .ai/memory/napkin.md
+
+# Repositórios de serviços (clonados/criados pelo workflow — cada um tem seu próprio .git)
+projetos/
+
+# MCP config — contém credenciais hardcoded (Confluence token, etc.)
+.mcp.json
+
+# Logs internos do workflow (append-only, gerados pelos commands)
+.ai/load-log.md
+.ai/publish-log.md
+
+# IDEs
+.vscode/
+.idea/
+
+# OS
+.DS_Store
+Thumbs.db
+
+# Node
+node_modules/
+dist/
+
+# Env
+.env
+.env.*
+!.env.example

package/templates/sfw.config.yml.example

@@ -1,147 +1,147 @@
-# ============================================================================
-# sfw.config.yml — Manifesto do projeto SFW
-# ============================================================================
-# Este arquivo define COMO o pipeline SFW fala com o mundo externo:
-# - De onde vêm os insumos do PM/PO (input)
-# - Pra onde vão os artefatos gerados (output.targets[])
-# - Como os nomes dos itens são formados (naming)
-#
-# É commitável (zero segredos). Credenciais ficam em .mcp.json gitignored
-# ou variáveis de ambiente exportadas ANTES de abrir o Claude Code.
-#
-# Gerado pelo CLI: `spec-first-claude init --name=X`
-#
-# Referências:
-# - Interface do adapter: .github/adapters/interface.md
-# - Adapters disponíveis: .github/adapters/registry.md
-# - Templating de nomes:  .github/adapters/naming.md
-# - Erros:                .github/adapters/errors.md
-# ============================================================================
-
-# ----------------------------------------------------------------------------
-# project — identidade do projeto
-# ----------------------------------------------------------------------------
-project:
-  name: "Meu Projeto"
-  # Page ID raiz do projeto no Confluence (o framework conhece o projeto inteiro)
-  # root_page_id: "65708"
-
-# ----------------------------------------------------------------------------
-# naming — templates de nome (aplicados pela engine em .github/adapters/naming.md)
-# ----------------------------------------------------------------------------
-# Placeholders suportados: {scope}, {type}
-#   {scope} = nome do item no Input (ex: "app_barbearia", "feat_login")
-#   {type}  = tipo do artefato (ex: "PRD", "SDD", "Progresso")
-# Qualquer outro placeholder → ValidationError no load do manifest.
-#
-# O usuário nomeia livremente os items no Input — o agent NÃO impõe naming.
-# Estes templates controlam apenas o que o agent GERA no Output.
-naming:
-  # Subpasta (ou page-mãe) criada no Output por scope
-  # Ex: "out_app_barbearia", "out_feat_login"
-  output_container: "out_{scope}"
-
-  # Nome do artefato DENTRO do container
-  # No Confluence: {scope} no nome evita colisão de títulos no space
-  # No filesystem: pode simplificar pra "{type}" (sem redundância de scope)
-  output_artifact: "{scope} - {type}"
-
-# ----------------------------------------------------------------------------
-# input — de onde vêm os insumos do PM/PO (single source no MVP)
-# ----------------------------------------------------------------------------
-# /load {scope} usa esta seção pra puxar o conteúdo pro filesystem local.
-# Dev nunca edita o backend de input — só lê. PM owns este espaço.
-#
-# O agent faz listChildren(parent_page_id) e busca o scope pelo nome.
-# Se o scope não existir no backend, /load falha com erro explícito.
-input:
-  # Chave do adapter no registry. MVP: "confluence" | "filesystem"
-  adapter: confluence
-
-  # Config passada pro adapter.validateConfig(). Campos obrigatórios/opcionais
-  # são documentados no arquivo do adapter (ex: .github/adapters/confluence.md).
-  config:
-    space_key: ST
-    parent_page_id: "360668"      # page-mãe que contém os scopes no Input
-    recursive: true               # desce na árvore de scopes
-    include_attachments: true     # baixa PNGs, PDFs, planilhas
-
-  # Cache local onde /load materializa os insumos
-  cache:
-    local_dir: "workspace/Input/"
-    log: ".ai/load-log.md"        # append-only: id, version, sha256, timestamp
-    incremental: true             # hash-based re-load (NOVO/MODIFICADO/INALTERADO)
-
-# ----------------------------------------------------------------------------
-# output — pra onde os artefatos vão (MVP: 1 target, multi-target em P2)
-# ----------------------------------------------------------------------------
-# Cada target recebe um subset de artefatos via `publishes`.
-# Auto-publish é disparado pelas skills (/extract, /design, /plan).
-# Agent owns este espaço. PM só aplica label `sfw-approved` pra aprovar.
-#
-# Premissa: 1 space = 1 projeto (no Confluence). Multi-projeto no mesmo
-# space causa colisão de títulos — constraint do Confluence, não do SFW.
-# Se necessário, o user diferencia no Input (nomes únicos) e o Output
-# herda a unicidade via {scope} no naming.
-output:
-  targets:
-
-    # --- Target 1: Confluence (espelho de aprovação pro time) ---------------
-    - name: confluence-mirror
-
-      adapter: confluence
-
-      config:
-        space_key: ST
-        parent_page_id: "294931"  # page-mãe do Output no Confluence
-
-      # Whitelist de tipos que este target recebe.
-      # Tipos válidos: PRD, SDD, Progresso
-      # (tasks.md, docs/, projetos.yaml, specs/ ficam LOCAL ONLY —
-      #  ver §9.9 "Boundary publish vs local")
-      publishes: [PRD, SDD, Progresso]
-
-      # auto   — skill dispara publish automaticamente no fim
-      # manual — skill gera artefato local e pergunta se quer publicar
-      # off    — target ignorado (offline-first natural)
-      mode: auto
-
-      # Estratégia de conflict detection:
-      # version — compara version do backend com publish-log antes de update
-      # hash    — compara sha256 do conteúdo remoto com snapshot local
-      # none    — sobrescreve cego (NÃO recomendado; perde drift humano)
-      conflict_detection: version
-
-      # Mecanismo de aprovação do artefato publicado:
-      # label — PM aplica label na página Confluence pra marcar aprovado
-      # none  — sem aprovação formal (pipeline segue sem checar)
-      approval_mechanism: label
-      approval_label: "sfw-approved"
-
-    # --- Target 2: Filesystem mirror (opcional — time offline/backup) -------
-    # Descomente pra ativar. Útil pra testes E2E com FilesystemAdapter como
-    # mock natural — zero lib de mock, zero stub.
-    #
-    # - name: local-mirror
-    #   adapter: filesystem
-    #   config:
-    #     root_path: "./mirror"
-    #     glob: "**/*.md"
-    #   publishes: [PRD, SDD, Progresso]
-    #   mode: auto
-    #   conflict_detection: hash
-    #   approval_mechanism: none
-
-# ----------------------------------------------------------------------------
-# context_pages — páginas extras que o framework pode consultar (opcional)
-# ----------------------------------------------------------------------------
-# O /mcp descobre a árvore do projeto e sugere pages que podem ser úteis
-# como contexto durante /extract e /design (referências, decisões, etc.)
-#
-# context_pages:
-#   - id: "557057"
-#     title: "Referências"
-#     use_in: [extract, design]
-#   - id: "425998"
-#     title: "Decisões"
-#     use_in: [design]
+# ============================================================================
+# sfw.config.yml — Manifesto do projeto SFW
+# ============================================================================
+# Este arquivo define COMO o pipeline SFW fala com o mundo externo:
+# - De onde vêm os insumos do PM/PO (input)
+# - Pra onde vão os artefatos gerados (output.targets[])
+# - Como os nomes dos itens são formados (naming)
+#
+# É commitável (zero segredos). Credenciais ficam em .mcp.json gitignored
+# ou variáveis de ambiente exportadas ANTES de abrir o Claude Code.
+#
+# Gerado pelo CLI: `spec-first-claude init --name=X`
+#
+# Referências:
+# - Interface do adapter: .github/adapters/interface.md
+# - Adapters disponíveis: .github/adapters/registry.md
+# - Templating de nomes:  .github/adapters/naming.md
+# - Erros:                .github/adapters/errors.md
+# ============================================================================
+
+# ----------------------------------------------------------------------------
+# project — identidade do projeto
+# ----------------------------------------------------------------------------
+project:
+  name: "Meu Projeto"
+  # Page ID raiz do projeto no Confluence (o framework conhece o projeto inteiro)
+  # root_page_id: "65708"
+
+# ----------------------------------------------------------------------------
+# naming — templates de nome (aplicados pela engine em .github/adapters/naming.md)
+# ----------------------------------------------------------------------------
+# Placeholders suportados: {scope}, {type}
+#   {scope} = nome do item no Input (ex: "app_barbearia", "feat_login")
+#   {type}  = tipo do artefato (ex: "PRD", "TRD", "Progresso")
+# Qualquer outro placeholder → ValidationError no load do manifest.
+#
+# O usuário nomeia livremente os items no Input — o agent NÃO impõe naming.
+# Estes templates controlam apenas o que o agent GERA no Output.
+naming:
+  # Subpasta (ou page-mãe) criada no Output por scope
+  # Ex: "out_app_barbearia", "out_feat_login"
+  output_container: "out_{scope}"
+
+  # Nome do artefato DENTRO do container
+  # No Confluence: {scope} no nome evita colisão de títulos no space
+  # No filesystem: pode simplificar pra "{type}" (sem redundância de scope)
+  output_artifact: "{scope} - {type}"
+
+# ----------------------------------------------------------------------------
+# input — de onde vêm os insumos do PM/PO (single source no MVP)
+# ----------------------------------------------------------------------------
+# /load {scope} usa esta seção pra puxar o conteúdo pro filesystem local.
+# Dev nunca edita o backend de input — só lê. PM owns este espaço.
+#
+# O agent faz listChildren(parent_page_id) e busca o scope pelo nome.
+# Se o scope não existir no backend, /load falha com erro explícito.
+input:
+  # Chave do adapter no registry. MVP: "confluence" | "filesystem"
+  adapter: confluence
+
+  # Config passada pro adapter.validateConfig(). Campos obrigatórios/opcionais
+  # são documentados no arquivo do adapter (ex: .github/adapters/confluence.md).
+  config:
+    space_key: ST
+    parent_page_id: "360668"      # page-mãe que contém os scopes no Input
+    recursive: true               # desce na árvore de scopes
+    include_attachments: true     # baixa PNGs, PDFs, planilhas
+
+  # Cache local onde /load materializa os insumos
+  cache:
+    local_dir: "workspace/Input/"
+    log: ".ai/load-log.md"        # append-only: id, version, sha256, timestamp
+    incremental: true             # hash-based re-load (NOVO/MODIFICADO/INALTERADO)
+
+# ----------------------------------------------------------------------------
+# output — pra onde os artefatos vão (MVP: 1 target, multi-target em P2)
+# ----------------------------------------------------------------------------
+# Cada target recebe um subset de artefatos via `publishes`.
+# Auto-publish é disparado pelas skills (/extract, /design, /plan).
+# Agent owns este espaço. PM só aplica label `sfw-approved` pra aprovar.
+#
+# Premissa: 1 space = 1 projeto (no Confluence). Multi-projeto no mesmo
+# space causa colisão de títulos — constraint do Confluence, não do SFW.
+# Se necessário, o user diferencia no Input (nomes únicos) e o Output
+# herda a unicidade via {scope} no naming.
+output:
+  targets:
+
+    # --- Target 1: Confluence (espelho de aprovação pro time) ---------------
+    - name: confluence-mirror
+
+      adapter: confluence
+
+      config:
+        space_key: ST
+        parent_page_id: "294931"  # page-mãe do Output no Confluence
+
+      # Whitelist de tipos que este target recebe.
+      # Tipos válidos: PRD, TRD, Progresso
+      # (tasks.md, docs/, projetos.yaml, specs/ ficam LOCAL ONLY —
+      #  ver §9.9 "Boundary publish vs local")
+      publishes: [PRD, TRD, Progresso]
+
+      # auto   — skill dispara publish automaticamente no fim
+      # manual — skill gera artefato local e pergunta se quer publicar
+      # off    — target ignorado (offline-first natural)
+      mode: auto
+
+      # Estratégia de conflict detection:
+      # version — compara version do backend com publish-log antes de update
+      # hash    — compara sha256 do conteúdo remoto com snapshot local
+      # none    — sobrescreve cego (NÃO recomendado; perde drift humano)
+      conflict_detection: version
+
+      # Mecanismo de aprovação do artefato publicado:
+      # label — PM aplica label na página Confluence pra marcar aprovado
+      # none  — sem aprovação formal (pipeline segue sem checar)
+      approval_mechanism: label
+      approval_label: "sfw-approved"
+
+    # --- Target 2: Filesystem mirror (opcional — time offline/backup) -------
+    # Descomente pra ativar. Útil pra testes E2E com FilesystemAdapter como
+    # mock natural — zero lib de mock, zero stub.
+    #
+    # - name: local-mirror
+    #   adapter: filesystem
+    #   config:
+    #     root_path: "./mirror"
+    #     glob: "**/*.md"
+    #   publishes: [PRD, TRD, Progresso]
+    #   mode: auto
+    #   conflict_detection: hash
+    #   approval_mechanism: none
+
+# ----------------------------------------------------------------------------
+# context_pages — páginas extras que o framework pode consultar (opcional)
+# ----------------------------------------------------------------------------
+# O /mcp descobre a árvore do projeto e sugere pages que podem ser úteis
+# como contexto durante /extract e /design (referências, decisões, etc.)
+#
+# context_pages:
+#   - id: "557057"
+#     title: "Referências"
+#     use_in: [extract, design]
+#   - id: "425998"
+#     title: "Decisões"
+#     use_in: [design]

package/templates/.github/templates/feature/backlog-extraido.template.md

@@ -1,156 +0,0 @@
-# Roadmap de Produto — {{NOME}}
-
-<!--
-=============================================================================
-INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
-=============================================================================
-
-QUANDO USAR: Gerado pelo /sf-extract em scopes com first-run=true (bootstrap de projeto)
-quando insumos trazem mais produto do que cabe no PRD principal — outras features
-futuras que foram mencionadas mas não são o foco deste scope.
-
-COMO GERAR:
-1. Durante a extração, o Analyzer separa:
-   - Conteúdo do scope atual → PRD
-   - Produto adicional mencionado mas fora do scope atual → backlog (aqui)
-2. Em vez de listar features soltas, ORGANIZAR em fases de entrega:
-   a. Identificar entidades/funcionalidades nos insumos
-   b. Mapear dependências entre elas (ex: agendamento depende de cadastro)
-   c. Agrupar em fases por dependência + complexidade
-   d. Definir entregável por fase (o que o usuário pode usar ao final)
-   e. Priorizar: P1 (base/core), P2 (operacional), P3 (crescimento)
-3. Para cada item, rastrear o arquivo fonte
-4. Sugerir UMA feature única com nome descritivo (ex: feat_mvp, feat_produto)
-
-PRINCÍPIO: Entregáveis contínuos — cada fase entrega valor e pode ir pra produção.
-Nunca "tudo ou nada". Pequeno e constante.
-
-CRITÉRIOS DE FASEAMENTO:
-- Fase 1 sempre = cadastros base / fundação (sem isso nada funciona)
-- Cada fase depende das anteriores (sequencial)
-- Cada fase tem entregável testável pelo usuário
-- Máximo 4-5 fases (se precisa de mais, agrupar melhor)
-
-USO POSTERIOR:
-- O usuário roda `/sf-start <nome>` pra cada feature do backlog que decidir construir
-- O /sf-extract dessa feature gera PRD com as fases já sugeridas aqui como referência
-- O /sf-plan organiza tasks por fase de entrega × área
-
-=============================================================================
--->
-
-> Roadmap faseado de produto extraído dos insumos do setup.
-> Organizado por fases de entrega incrementais — cada fase entrega valor e pode ir pra produção.
-> Fonte de verdade para criação de features via `/feature`.
-
----
-
-## Feature sugerida: `{{FEATURE_NAME}}`
-
-> {{Descrição em 1-2 frases do produto completo}}
-
----
-
-## Fase 1 — {{Nome}} [P1 — Fundação]
-
-> **Entregável**: {{O que o usuário pode fazer/ver ao final desta fase}}
-> **Critério de done**: {{Como validar que a fase está pronta}}
-
-### Funcionalidades
-
-| # | Funcionalidade | Tipo | Descrição | Fonte |
-|---|---------------|------|-----------|-------|
-| 1 | | CRUD / Feature / Config | | {{arquivo}} |
-
-### Entidades envolvidas
-
-| Entidade | Campos principais | Fonte |
-|----------|-------------------|-------|
-| | | |
-
-### Regras de negócio
-
-| ID | Regra | Fonte |
-|----|-------|-------|
-| RN-001 | | {{arquivo}} |
-
-### Jornadas de usuário
-
-| # | Jornada | Atores | Fonte |
-|---|---------|--------|-------|
-| 1 | | | |
-
----
-
-## Fase 2 — {{Nome}} [P1 — Core Business]
-
-> **Entregável**: {{O que o usuário pode fazer/ver ao final desta fase}}
-> **Critério de done**: {{Como validar}}
-> **Depende de**: Fase 1
-
-### Funcionalidades
-
-| # | Funcionalidade | Tipo | Descrição | Fonte |
-|---|---------------|------|-----------|-------|
-| 1 | | | | |
-
-### Entidades envolvidas
-
-| Entidade | Campos principais | Fonte |
-|----------|-------------------|-------|
-| | | |
-
-### Regras de negócio
-
-| ID | Regra | Fonte |
-|----|-------|-------|
-| RN-NNN | | |
-
-### Jornadas de usuário
-
-| # | Jornada | Atores | Fonte |
-|---|---------|--------|-------|
-| 1 | | | |
-
----
-
-## Fase 3 — {{Nome}} [P2 — Operacional]
-
-> **Entregável**: {{...}}
-> **Critério de done**: {{...}}
-> **Depende de**: Fase 2
-
-<!-- Repetir estrutura -->
-
----
-
-## Fase 4 — {{Nome}} [P3 — Crescimento]
-
-> **Entregável**: {{...}}
-> **Critério de done**: {{...}}
-> **Depende de**: Fase 3
-
-<!-- Repetir estrutura -->
-
----
-
-## Visão geral das fases
-
-| Fase | Nome | Prioridade | Entregável | Depende de |
-|------|------|-----------|------------|------------|
-| 1 | | P1 | | — |
-| 2 | | P1 | | Fase 1 |
-| 3 | | P2 | | Fase 2 |
-| 4 | | P3 | | Fase 3 |
-
-## Telas/fluxos identificados (por fase)
-
-| # | Tela/Fluxo | Fase | Fonte |
-|---|-----------|------|-------|
-| 1 | | | |
-
----
-
-> **Próximo passo**: Criar a feature com `/feature {{FEATURE_NAME}}`
-> O /sf-extract vai gerar o PRD usando este roadmap como referência.
-> O /sf-plan vai organizar tasks por fase de entrega × área.