spec-first-copilot 0.7.0-beta.1 → 0.7.0

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

@@ -1,125 +1,125 @@
-# Scenarios — {{NOME}}
-
-> Critérios de aceite + fluxos + estados de UI. Fonte de verdade para o Reviewer.
-> Gerado pelo /sf-design a partir de PRD + TRD. NUNCA editado manualmente.
-
----
-
-<!--
-=============================================================================
-INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
-=============================================================================
-
-ORIGEM: /sf-design — projeção combinada:
-- PRD §3 Jornadas → Fluxos Happy Path
-- PRD §8 Cenários de Sucesso/Erro → Fluxos de Erro e Edge Cases
-- PRD §7 Telas/Fluxos UI → UI / Componentes (high-level)
-- PRD §5 RNs + §6 Validações de Domínio → Critérios de Aceite (Given/When/Then)
-- TRD §3 §Área-Frontend → detalhes de estados de UI (loading/empty/error/success)
-- TRD §8 Estratégia de Testes → Estratégia de Testes
-Critérios de Aceite ficam aqui (especiarias derivadas de RNs + jornadas).
-
-ATUALIZAÇÃO: Sempre regenerado junto com os specs. NUNCA editado manualmente.
-
-REGRA DE OURO: Se algo aqui diverge de PRD ou TRD, os docs source vencem.
-Re-rode /sf-design.
-
-TERMINOLOGIA (dois níveis de pré-condição):
-- PRÉ-CONDIÇÕES GLOBAIS (seção no topo): estado que aplica a TODOS os cenários abaixo.
-  Ex: "sistema populado com seed", "usuário X existe em papel Y".
-- PRÉ-CONDIÇÃO DO CA (dentro do CA): estado ADICIONAL específico daquele CA.
-  Ex: "produto com estoque = 0" em CA que testa venda sem estoque.
-
-REGRAS DE PREENCHIMENTO:
-- 1 CA = 1 regra de negócio testável (não agrupar múltiplas regras num CA)
-- Cada CA DEVE ter um teste mapeado — sem teste = CA inválido
-- Fluxos de erro têm seção própria — não esconder em "Caminhos de erro" do happy path
-- Cada linha de "Fluxos de Erro" referencia o CA correspondente (coluna Ref CA)
-- Feature sem frontend: seção UI/Componentes = "N/A — backend-only"
-- Pré-condição = estado do banco/sistema, não input do usuário (input fica no When)
-- Estratégia de testes NÃO redefine frameworks — referencia docs/architecture.md
-
-PARA O REVIEWER:
-- Validar que cada CA-NNN tem teste executável correspondente
-- Usar esta tabela de estados como checklist de UI
-- Fluxos de erro são obrigatórios no happy path test suite (não opcionais)
-
-=============================================================================
--->
-
-## Pré-condições Globais
-
-<!-- Estado do sistema ANTES de executar os cenários abaixo. Aplicam a TODOS.
-Exemplos: quais registros precisam existir no banco, qual papel está autenticado,
-quais flags de feature estão ativas. Se não houver: "Estado limpo — sem pré-condições." -->
-
-| Condição | Valor esperado |
-|----------|---------------|
-|          |               |
-
-## Fluxos — Happy Path
-
-<!-- 1 fluxo por entregável principal. Formato linear: quem faz o quê e qual resultado.
-Nível suficiente para coder implementar e reviewer validar — sem narrativa extra. -->
-
-### Fluxo: {{nome}}
-
-| Passo | Ator | Ação / Request | Resultado / Response |
-|-------|------|---------------|----------------------|
-| 1 | | | |
-| 2 | | | |
-
-## Fluxos — Erro e Edge Cases
-
-<!-- Desvios do happy path. Cada linha = 1 scenario testável.
-Não omitir: são obrigatórios nos testes de integração.
-Ref CA aponta pro CA detalhado abaixo que cobre este erro. -->
-
-| Cenário | Pré-condição | Ação | Resposta esperada | HTTP / Código | Ref CA |
-|---------|-------------|------|-------------------|---------------|--------|
-|         |             |      |                   |               |        |
-
-## UI / Componentes
-
-<!-- Se backend-only: escrever "N/A — feature sem frontend." e pular esta seção. -->
-
-### {{componente}}
-
-| Estado | Gatilho | O que exibe | Dado / Mensagem |
-|--------|---------|-------------|-----------------|
-| loading | | skeleton / spinner | — |
-| empty | | | |
-| error | | mensagem de erro | código ou texto |
-| success | | | |
-
-## Critérios de Aceite
-
-<!-- 1 CA = 1 regra de negócio testável. Given/When/Then em 1 linha cada.
-Pré-condição = estado do sistema ADICIONAL às pré-condições globais (não repetir). -->
-
-### CA-001: {{título da regra — imperativo curto}}
-
-- **Pré-condição**: <!-- estado adicional às globais. Ex: "produto com estoque = 0" -->
-- **Given**: <!-- contexto do ator -->
-- **When**: <!-- ação executada -->
-- **Then**: <!-- resultado observável e verificável -->
-- **Teste**: `unit|integration|e2e` — `caminho/do/arquivo_test.ext`
-
-### CA-002: {{título}}
-
-- **Pré-condição**:
-- **Given**:
-- **When**:
-- **Then**:
-- **Teste**:
-
-## Estratégia de Testes
-
-<!-- NÃO redefinir frameworks — usar os definidos em docs/architecture.md.
-Descrever escopo e cobertura esperada para esta feature. -->
-
-| Nível | Escopo nesta feature | Quando roda | Responsável |
-|-------|----------------------|-------------|-------------|
-| Unit | lógica de negócio isolada (serviços, validadores) | por task | coder |
-| Integration | fluxo request → DB → response | por fase | coder |
-| E2E | CAs críticos end-to-end | por feature | coder (escreve) + reviewer (valida) |
+# Scenarios — {{NOME}}
+
+> Critérios de aceite + fluxos + estados de UI. Fonte de verdade para o Reviewer.
+> Gerado pelo /sf-design a partir de PRD + TRD. NUNCA editado manualmente.
+
+---
+
+<!--
+=============================================================================
+INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
+=============================================================================
+
+ORIGEM: /sf-design — projeção combinada:
+- PRD §3 Jornadas → Fluxos Happy Path
+- PRD §8 Cenários de Sucesso/Erro → Fluxos de Erro e Edge Cases
+- PRD §7 Telas/Fluxos UI → UI / Componentes (high-level)
+- PRD §5 RNs + §6 Validações de Domínio → Critérios de Aceite (Given/When/Then)
+- TRD §3 §Área-Frontend → detalhes de estados de UI (loading/empty/error/success)
+- TRD §8 Estratégia de Testes → Estratégia de Testes
+Critérios de Aceite ficam aqui (especiarias derivadas de RNs + jornadas).
+
+ATUALIZAÇÃO: Sempre regenerado junto com os specs. NUNCA editado manualmente.
+
+REGRA DE OURO: Se algo aqui diverge de PRD ou TRD, os docs source vencem.
+Re-rode /sf-design.
+
+TERMINOLOGIA (dois níveis de pré-condição):
+- PRÉ-CONDIÇÕES GLOBAIS (seção no topo): estado que aplica a TODOS os cenários abaixo.
+  Ex: "sistema populado com seed", "usuário X existe em papel Y".
+- PRÉ-CONDIÇÃO DO CA (dentro do CA): estado ADICIONAL específico daquele CA.
+  Ex: "produto com estoque = 0" em CA que testa venda sem estoque.
+
+REGRAS DE PREENCHIMENTO:
+- 1 CA = 1 regra de negócio testável (não agrupar múltiplas regras num CA)
+- Cada CA DEVE ter um teste mapeado — sem teste = CA inválido
+- Fluxos de erro têm seção própria — não esconder em "Caminhos de erro" do happy path
+- Cada linha de "Fluxos de Erro" referencia o CA correspondente (coluna Ref CA)
+- Feature sem frontend: seção UI/Componentes = "N/A — backend-only"
+- Pré-condição = estado do banco/sistema, não input do usuário (input fica no When)
+- Estratégia de testes NÃO redefine frameworks — referencia docs/architecture.md
+
+PARA O REVIEWER:
+- Validar que cada CA-NNN tem teste executável correspondente
+- Usar esta tabela de estados como checklist de UI
+- Fluxos de erro são obrigatórios no happy path test suite (não opcionais)
+
+=============================================================================
+-->
+
+## Pré-condições Globais
+
+<!-- Estado do sistema ANTES de executar os cenários abaixo. Aplicam a TODOS.
+Exemplos: quais registros precisam existir no banco, qual papel está autenticado,
+quais flags de feature estão ativas. Se não houver: "Estado limpo — sem pré-condições." -->
+
+| Condição | Valor esperado |
+|----------|---------------|
+|          |               |
+
+## Fluxos — Happy Path
+
+<!-- 1 fluxo por entregável principal. Formato linear: quem faz o quê e qual resultado.
+Nível suficiente para coder implementar e reviewer validar — sem narrativa extra. -->
+
+### Fluxo: {{nome}}
+
+| Passo | Ator | Ação / Request | Resultado / Response |
+|-------|------|---------------|----------------------|
+| 1 | | | |
+| 2 | | | |
+
+## Fluxos — Erro e Edge Cases
+
+<!-- Desvios do happy path. Cada linha = 1 scenario testável.
+Não omitir: são obrigatórios nos testes de integração.
+Ref CA aponta pro CA detalhado abaixo que cobre este erro. -->
+
+| Cenário | Pré-condição | Ação | Resposta esperada | HTTP / Código | Ref CA |
+|---------|-------------|------|-------------------|---------------|--------|
+|         |             |      |                   |               |        |
+
+## UI / Componentes
+
+<!-- Se backend-only: escrever "N/A — feature sem frontend." e pular esta seção. -->
+
+### {{componente}}
+
+| Estado | Gatilho | O que exibe | Dado / Mensagem |
+|--------|---------|-------------|-----------------|
+| loading | | skeleton / spinner | — |
+| empty | | | |
+| error | | mensagem de erro | código ou texto |
+| success | | | |
+
+## Critérios de Aceite
+
+<!-- 1 CA = 1 regra de negócio testável. Given/When/Then em 1 linha cada.
+Pré-condição = estado do sistema ADICIONAL às pré-condições globais (não repetir). -->
+
+### CA-001: {{título da regra — imperativo curto}}
+
+- **Pré-condição**: <!-- estado adicional às globais. Ex: "produto com estoque = 0" -->
+- **Given**: <!-- contexto do ator -->
+- **When**: <!-- ação executada -->
+- **Then**: <!-- resultado observável e verificável -->
+- **Teste**: `unit|integration|e2e` — `caminho/do/arquivo_test.ext`
+
+### CA-002: {{título}}
+
+- **Pré-condição**:
+- **Given**:
+- **When**:
+- **Then**:
+- **Teste**:
+
+## Estratégia de Testes
+
+<!-- NÃO redefinir frameworks — usar os definidos em docs/architecture.md.
+Descrever escopo e cobertura esperada para esta feature. -->
+
+| Nível | Escopo nesta feature | Quando roda | Responsável |
+|-------|----------------------|-------------|-------------|
+| Unit | lógica de negócio isolada (serviços, validadores) | por task | coder |
+| Integration | fluxo request → DB → response | por fase | coder |
+| E2E | CAs críticos end-to-end | por feature | coder (escreve) + reviewer (valida) |

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

@@ -1,65 +1,65 @@
-# 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}
-
-- [ ] 
-- [ ] 
-- [ ] 
+# 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