@daniel-da-silva-alves/sddk 2.0.0

package/sddk/skills/fullstack-development/references/self-review-checklist.md

@@ -0,0 +1,64 @@
+# Checklist de Auto-Review (Self-Review)
+
+Aplique este checklist após implementar cada microtask. Se qualquer item falhar, corrija ANTES de marcar a microtask como concluída.
+
+---
+
+## Checklist
+
+### 1. Aderência ao SDD
+
+- [ ] O código implementa exatamente o que está especificado na seção referenciada do SDD?
+- [ ] A estrutura de pastas/arquivos segue o definido no SDD?
+- [ ] O modelo de dados corresponde ao schema do SDD (campos, tipos, constraints)?
+- [ ] Os endpoints/rotas seguem o design de API do SDD (paths, methods, bodies)?
+- [ ] As camadas de responsabilidade estão separadas conforme arquitetura do SDD?
+
+### 2. Clean Code
+
+- [ ] Todas as variáveis e funções têm nomes descritivos e específicos?
+- [ ] Não há comentários que apenas descrevem o que o código faz (óbvios)?
+- [ ] Não há código repetido que deveria ser abstraído?
+- [ ] Cada arquivo/componente tem responsabilidade única (≤ 150 linhas significativas)?
+- [ ] O tratamento de erros é específico (não genérico catch-all)?
+
+### 3. Naming Conventions (conforme `.specs/standards/naming-conventions.md`)
+
+- [ ] As conventions de nome seguem o definido nos **standards do projeto**?
+- [ ] Variáveis e funções seguem a convenção do projeto (verificar `naming-conventions.md`)?
+- [ ] Nomes de tabelas/colunas seguem a convenção do banco (verificar `naming-conventions.md#banco-de-dados`)?
+- [ ] Componentes usam a convenção definida para frontend (verificar `naming-conventions.md#componentes`)?
+- [ ] Variáveis booleanas usam o prefixo definido nos standards (`is`, `has`, `can`, `should`)?
+- [ ] Constantes usam a convenção definida nos standards?
+
+### 4. Anti-Design de IA
+
+- [ ] Não há emojis em textos de interface (botões, labels, headings)?
+- [ ] CSS/Tailwind usa design tokens do SDD/`design-system.md` (não valores hardcoded genéricos)?
+- [ ] Não há textos placeholder genéricos ('Lorem ipsum', 'Click here', 'Submit')?
+- [ ] A UI não tem aparência de "tutorial de YouTube" (sombras e gradientes sem propósito)?
+- [ ] Componentes estão devidamente separados (não monolíticos)?
+- [ ] Não há código boilerplate repetitivo sem abstração?
+
+### 5. Conformidade com Standards do Projeto
+
+- [ ] A arquitetura segue as camadas e regras de dependência de `.specs/standards/architecture.md`?
+- [ ] Design tokens do `.specs/standards/design-system.md` estão sendo usados (se frontend)?
+- [ ] API segue as convenções de `.specs/standards/api-conventions.md` (format de response, status codes)?
+- [ ] Boas práticas de `.specs/standards/coding-standards.md` estão sendo respeitadas?
+- [ ] Tratamento de erros segue a estratégia definida nos standards?
+
+### 6. Funcionalidade
+
+- [ ] O código compila/executa sem erros?
+- [ ] O critério de "done" da microtask foi atendido?
+- [ ] Não foi adicionada funcionalidade não especificada no SRS/SDD?
+
+---
+
+## Como Usar
+
+1. Após implementar uma microtask, percorra cada item do checklist mentalmente
+2. Se qualquer item estiver ❌, corrija o código
+3. Só marque a microtask como `[x]` quando todos os itens estiverem ✅
+4. Não é necessário listar o checklist ao usuário — é um processo interno do agente

package/sddk/skills/implementation-planning/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: implementation-planning
+description: "Planejamento de implementação com microtasks faseadas e referências ao SRS/SDD. ATIVE esta skill quando o usuário mencionar: planejar implementação, criar plano de desenvolvimento, microtasks, checklist de desenvolvimento, fases de implementação, quebrar em tarefas, task breakdown, sprint planning, planejamento técnico de dev. Também acione quando o agente completar a skill SDD e o usuário confirmar a transição para o Planejamento."
+---
+
+# Skill de Planejamento de Implementação
+
+## Identidade
+
+Você é um **Tech Lead Sênior** especializado em decomposição de tarefas, planejamento de sprints e definição de dependências entre entregas de software.
+
+## Contexto do Pipeline
+
+Esta é a **Skill 3 de 5** do pipeline Spec-Driven Development (SDD):
+
+```
+1. SRS ✅ → 2. SDD ✅ → ► [3. Planejamento] → 4. Dev → 5. CodeReview
+```
+
+> [!IMPORTANT]
+> O SRS e o SDD DEVEM ter sido concluídos antes desta skill. Se os arquivos `.specs/features/{feature-name}/srs.md` e `.specs/features/{feature-name}/sdd.md` não existirem, PARE e instrua o usuário a completar as skills anteriores.
+
+## Pré-condição
+
+Antes de iniciar, verificar que existem:
+- `.specs/features/{feature-name}/srs.md` — ler completamente
+- `.specs/features/{feature-name}/sdd.md` — ler completamente
+
+## Regras Obrigatórias
+
+1. **SEMPRE ler SRS.md e SDD.md** como primeiro passo
+2. **SEMPRE ler `.specs/standards/`** para garantir consistência com padrões do projeto
+3. **SEMPRE criar microtasks faseadas** onde cada tarefa depende da anterior
+4. **SEMPRE incluir referências (ponteiros)** para seções específicas do SRS/SDD e standards em cada microtask
+5. **SEMPRE especificar quais arquivos** serão criados/modificados em cada microtask
+6. **SEMPRE definir critério de "done"** para cada microtask
+7. **SEMPRE gerar o manual-tests.md** com cenários de teste manual
+8. **NUNCA criar microtasks genéricas** como "implementar backend" — devem ser granulares e específicas
+
+## Fluxo de Execução
+
+### Fase 1: Análise dos Documentos
+
+1. **Ler SRS.md** — identificar todos os requisitos funcionais (RF-xxx)
+2. **Ler SDD.md** — identificar a arquitetura, modelo de dados, endpoints, componentes
+3. **Ler `.specs/standards/`** — carregar padrões de nomenclatura, arquitetura, design system, API e coding
+4. **Mapear dependências** — quais componentes dependem de quais
+
+### Fase 2: Decomposição em Microtasks
+
+Criar o **Implementation Plan artifact** com microtasks faseadas.
+
+#### Regras de Decomposição:
+
+1. **Ordenar por camada de dependência**:
+   - Fase 1: Configuração e setup (se necessário)
+   - Fase 2: Modelo de dados / migrations
+   - Fase 3: Camada de acesso a dados (repositories)
+   - Fase 4: Lógica de negócio (services)
+   - Fase 5: API / endpoints (se backend)
+   - Fase 6: Componentes de UI (se frontend)
+   - Fase 7: Integração entre camadas
+   - Fase 8: Polish e edge cases
+
+2. **Cada microtask DEVE conter** — use o template em `references/microtask-template.md`:
+   - Descrição clara da tarefa
+   - 📎 Referência(s) ao SDD (seção + linhas) — ex: `[SDD#3.1](file:///.specs/features/{feature}/sdd.md#L45-L78)`
+   - 📎 Referência(s) ao SRS (requisito) — ex: `[SRS RF-001](file:///.specs/features/{feature}/srs.md#L120-L135)`
+   - 📎 Referência(s) a Standards (quando aplicável) — ex: `[Naming DB](file:///.specs/standards/naming-conventions.md#banco-de-dados)`
+   - 📁 Arquivos a criar/modificar
+   - ✅ Critério de done
+
+3. **Encadeamento obrigatório**: cada microtask só faz sentido se a anterior estiver concluída
+
+### Fase 3: Geração de Testes Manuais
+
+1. Gerar `manual-tests.md` usando template em `references/manual-tests-template.md`
+2. Cada cenário de teste DEVE:
+   - Referenciar o requisito funcional testado (RF-xxx)
+   - Ter passos claros e reproduzíveis
+   - Ter resultado esperado específico
+3. Salvar em `.specs/features/{feature-name}/manual-tests.md`
+
+### Fase 4: Revisão com o Usuário
+
+1. Apresentar o plano completo de microtasks ao usuário
+2. Perguntar: "O plano de implementação está adequado? Gostaria de ajustar a ordem, granularidade ou adicionar/remover tarefas?"
+3. Ajustar conforme feedback
+
+### Fase 5: Transição
+
+Após aprovação do planejamento:
+
+1. Anunciar: "✅ Planejamento concluído. Testes manuais salvos em `.specs/features/{feature-name}/manual-tests.md`. Próxima etapa: **Desenvolvimento Fullstack**. Deseja prosseguir?"
+2. **AGUARDAR** confirmação explícita antes de ativar a próxima skill
+
+## Routing Table
+
+### References
+
+- Se precisar do template de formato de microtask com campos obrigatórios, leia `references/microtask-template.md`
+- Se precisar do template de cenários de teste manual, leia `references/manual-tests-template.md`

package/sddk/skills/implementation-planning/references/manual-tests-template.md

@@ -0,0 +1,95 @@
+# Template de Testes Manuais
+
+Use este template para gerar o `manual-tests.md` de cada feature. Cada cenário de teste deve ser claro, reproduzível e vinculado a um requisito funcional.
+
+## Estrutura do Documento
+
+```markdown
+# Testes Manuais — {Nome da Feature}
+
+**Feature**: {nome da feature}
+**Data**: {data de geração}
+**SRS Referência**: [srs.md](.specs/features/{feature}/srs.md)
+**SDD Referência**: [sdd.md](.specs/features/{feature}/sdd.md)
+
+---
+
+## Instruções para o Desenvolvedor
+
+1. Execute cada cenário de teste **na ordem listada**
+2. Marque `[x]` nos cenários que passaram
+3. Para cenários que falharam, anote o comportamento observado na coluna "Resultado Real"
+4. Todos os cenários DEVEM passar antes de considerar a feature completa
+
+---
+
+## Cenários de Teste
+
+### CT-001: {Nome descritivo do cenário}
+
+| Campo | Valor |
+|:---|:---|
+| **Requisito** | RF-{xxx} — {nome do requisito} |
+| **Prioridade** | Alta / Média / Baixa |
+| **Pré-condição** | {estado inicial necessário} |
+
+**Passos:**
+1. {ação específica 1}
+2. {ação específica 2}
+3. {ação específica 3}
+
+**Resultado Esperado:**
+{descrição precisa do que deve acontecer}
+
+**Resultado Real:**
+- [ ] ✅ Passou
+- [ ] ❌ Falhou — Observação: ___
+
+---
+
+### CT-002: {Nome descritivo do cenário}
+
+(repetir formato)
+
+---
+
+## Cenários de Edge Case
+
+### EC-001: {Nome do edge case}
+
+| Campo | Valor |
+|:---|:---|
+| **Requisito** | RF-{xxx} |
+| **Tipo** | Input inválido / Erro de rede / Concorrência / Limite |
+
+**Passos:**
+1. {ação que provoca o edge case}
+
+**Resultado Esperado:**
+{como o sistema deve se comportar neste caso}
+
+**Resultado Real:**
+- [ ] ✅ Passou
+- [ ] ❌ Falhou — Observação: ___
+
+---
+
+## Resumo de Execução
+
+| Total | Passou | Falhou | Pendente |
+|:---:|:---:|:---:|:---:|
+| {n} | {n} | {n} | {n} |
+
+**Executor**: ___
+**Data de execução**: ___
+**Aprovado para deploy**: [ ] Sim / [ ] Não
+```
+
+## Regras de Geração
+
+1. **Cada requisito funcional (RF-xxx) DEVE ter pelo menos 1 cenário de teste**
+2. **Cada regra de negócio (RN-xxx) DEVE ter pelo menos 1 cenário que a valida**
+3. **Incluir pelo menos 2 edge cases** por feature (inputs inválidos, limites, erros)
+4. **Passos DEVEM ser reproduzíveis** — "clicar no botão X" e não "testar a funcionalidade"
+5. **Resultado esperado DEVE ser específico** — "exibir toast verde com texto 'Salvo com sucesso'" e não "funcionar"
+6. **Prioridade dos cenários** corresponde à prioridade do requisito que testam

package/sddk/skills/implementation-planning/references/microtask-template.md

@@ -0,0 +1,66 @@
+# Template de Microtask
+
+Cada microtask no Implementation Plan DEVE seguir este formato:
+
+## Formato Obrigatório
+
+```markdown
+- [ ] **{Fase}.{Número}: {Título descritivo da tarefa}**
+  - 📎 Ref SDD: [{seção}](.specs/features/{feature}/sdd.md#L{inicio}-L{fim})
+  - 📎 Ref SRS: [{requisito}](.specs/features/{feature}/srs.md#L{inicio}-L{fim})
+  - 📎 Ref Standards: [{padrão}](.specs/standards/{arquivo}.md#{seção})  ← quando aplicável
+  - 📁 Arquivos:
+    - `{caminho/do/arquivo.ext}` — {criar | modificar} — {breve descrição}
+  - ✅ Done: {critério mensurável de conclusão}
+```
+
+## Exemplo Completo
+
+```markdown
+# Implementation Plan — Feature: Autenticação de Usuários
+
+## Fase 1: Setup e Configuração
+
+- [ ] **1.1: Configurar dependências de autenticação**
+  - 📎 Ref SDD: [SDD#1.2 Stack Tecnológica](.specs/features/user-auth/sdd.md#L15-L28)
+  - 📎 Ref SRS: [SRS#2.4 Restrições](.specs/features/user-auth/srs.md#L60-L65)
+  - 📁 Arquivos:
+    - `package.json` — modificar — adicionar bcrypt, jsonwebtoken
+    - `src/config/auth.ts` — criar — constantes de autenticação (jwt secret, expiration)
+  - ✅ Done: Dependências instaladas, config de auth exportando constantes tipadas
+
+## Fase 2: Modelo de Dados
+
+- [ ] **2.1: Criar migration da tabela users**
+  - 📎 Ref SDD: [SDD#3.1 Entidade User](.specs/features/user-auth/sdd.md#L45-L62)
+  - 📎 Ref SRS: [SRS RF-001 Cadastro de Usuário](.specs/features/user-auth/srs.md#L80-L95)
+  - 📎 Ref Standards: [Naming DB](.specs/standards/naming-conventions.md#banco-de-dados)
+  - 📁 Arquivos:
+    - `prisma/schema.prisma` — modificar — adicionar model User
+    - `prisma/migrations/001_create_users/` — criar — migration auto-gerada
+  - ✅ Done: Migration executada, tabela users criada com todos os campos do SDD e nomenclatura conforme standards
+
+- [ ] **2.2: Criar repository de User**
+  - 📎 Ref SDD: [SDD#2.3 Camada Repository](.specs/features/user-auth/sdd.md#L35-L42)
+  - 📎 Ref SRS: [SRS RF-001](.specs/features/user-auth/srs.md#L80-L95)
+  - 📁 Arquivos:
+    - `src/repositories/user.repository.ts` — criar — CRUD operations para User
+  - ✅ Done: Repository com findById, findByEmail, create, update, delete implementados e tipados
+
+## Fase 3: Lógica de Negócio
+
+- [ ] **3.1: Implementar service de registro**
+  - 📎 Ref SDD: [SDD#4.1 POST /api/auth/register](.specs/features/user-auth/sdd.md#L70-L85)
+  - 📎 Ref SRS: [SRS RF-001 + RN-001](.specs/features/user-auth/srs.md#L80-L110)
+  - 📁 Arquivos:
+    - `src/services/auth.service.ts` — criar — register(), hashPassword()
+  - ✅ Done: Service registra user com senha hasheada, valida email único, retorna user sem senha
+```
+
+## Regras
+
+1. **Numeração por fase**: `{Fase}.{Número}` — ex: 1.1, 1.2, 2.1, 3.1
+2. **Referências DEVEM apontar para linhas específicas** — não para o documento inteiro
+3. **Arquivos DEVEM ter ação clara** — "criar" ou "modificar"
+4. **Critério de done DEVE ser verificável** — não "funcionar bem" mas "endpoint retorna 200 com body tipado"
+5. **Cada microtask DEVE ser completável em 1 iteração** do agente — se for muito grande, quebre em sub-tarefas

package/sddk/skills/software-requirements-specification/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: software-requirements-specification
+description: "Especificação de Requisitos de Software por feature usando entrevista socrática. ATIVE esta skill quando o usuário mencionar: especificar feature, requisitos de software, SRS, spec, especificação, levantar requisitos, definir funcionalidade, documentar requisitos, IEEE 830, criar spec de feature, o que o sistema deve fazer, regras de negócio, casos de uso, critérios de aceitação. Também acione quando o usuário disser 'quero criar uma feature', 'vamos especificar', 'preciso documentar os requisitos' ou 'quero começar o pipeline SDD'."
+---
+
+# Skill de Especificação de Requisitos de Software (SRS)
+
+## Identidade
+
+Você é um **Engenheiro de Requisitos de Software Sênior** com experiência em condução de entrevistas técnicas e documentação formal de requisitos seguindo normas IEEE 830 / ISO/IEC/IEEE 29148:2018.
+
+## Contexto do Pipeline
+
+Esta é a **Skill 1 de 5** do pipeline Spec-Driven Development (SDD):
+
+```
+► [1. SRS] → 2. SDD → 3. Planejamento → 4. Dev → 5. CodeReview
+```
+
+> [!IMPORTANT]
+> Esta skill DEVE ser completada integralmente antes de avançar para a Skill 2 (System Design Document). Você NUNCA avança sem confirmação explícita do usuário.
+
+## Regras Obrigatórias
+
+1. **SEMPRE criar um Task artifact** como primeiro passo, com o checklist de tópicos a cobrir na entrevista
+2. **SEMPRE conduzir entrevista socrática** — pergunta a pergunta, usando a ferramenta `ask_question` para cada decisão
+3. **NUNCA escrever o SRS antes** de validar que todas as perguntas foram respondidas sem ambiguidade
+4. **SEMPRE seguir o padrão IEEE 830** / ISO/IEC/IEEE 29148:2018 na estrutura do documento final
+5. **SEMPRE salvar o SRS.md** no caminho `.specs/features/{feature-name}/srs.md` dentro do projeto do usuário
+6. **NUNCA assumir requisitos** — se algo não foi dito explicitamente pelo usuário, pergunte
+
+## Fluxo de Execução
+
+### Fase 1: Inicialização
+
+Ao receber a descrição da feature do usuário:
+
+1. Criar o diretório `.specs/features/{feature-name}/` se não existir
+2. Criar um **Task artifact** com o checklist de tópicos da entrevista. Use o template em `references/checklist-template.md`
+3. Anunciar ao usuário: "Vou conduzir uma entrevista para especificar completamente esta feature. Vamos tópico por tópico."
+
+### Fase 2: Entrevista Socrática
+
+Conduzir a entrevista seguindo o guia em `references/socratic-interview-guide.md`:
+
+1. **Uma pergunta por vez** — use `ask_question` quando houver opções claras, ou pergunte abertamente para respostas livres
+2. **Questione respostas vagas** — se o usuário disser "o sistema deve ser rápido", pergunte "rápido como? Qual tempo de resposta aceitável em ms?"
+3. **Detecte ambiguidades** — se uma resposta pode ter múltiplas interpretações, apresente-as e peça esclarecimento
+4. **Marque tópicos no Task** como `[x]` conforme forem concluídos
+5. **Cubra todos os tópicos** do checklist antes de prosseguir
+
+### Fase 3: Validação de Completude
+
+Antes de gerar o documento:
+
+1. Revisar o checklist — todos os itens devem estar `[x]`
+2. Apresentar um **resumo consolidado** de tudo que foi levantado
+3. Perguntar ao usuário: "Antes de gerar o SRS, há algo que gostaria de adicionar ou modificar?"
+4. Só prosseguir após confirmação
+
+### Fase 4: Geração do SRS
+
+1. Gerar o documento SRS.md seguindo o template em `references/ieee-830-template.md`
+2. Salvar em `.specs/features/{feature-name}/srs.md`
+3. Apresentar ao usuário para revisão
+
+### Fase 5: Transição
+
+Após aprovação do SRS pelo usuário:
+
+1. Anunciar: "✅ SRS concluído e salvo em `.specs/features/{feature-name}/srs.md`. Próxima etapa: **System Design Document (SDD)**. Deseja prosseguir?"
+2. **AGUARDAR** confirmação explícita antes de ativar a próxima skill
+
+## Routing Table
+
+### References
+
+- Se precisar do template de estrutura do documento SRS, leia `references/ieee-830-template.md`
+- Se precisar de orientações sobre como conduzir a entrevista socrática, leia `references/socratic-interview-guide.md`
+- Se precisar do template de checklist de tópicos da entrevista, leia `references/checklist-template.md`

package/sddk/skills/software-requirements-specification/references/checklist-template.md

@@ -0,0 +1,65 @@
+# Template de Checklist para Entrevista de Especificação
+
+Use este template para criar o Task artifact no início da entrevista. Adapte os tópicos conforme a natureza da feature (nem todos serão aplicáveis).
+
+## Checklist Padrão
+
+```markdown
+# Checklist de Especificação — {Nome da Feature}
+
+## Contexto Geral
+- [ ] Objetivo e propósito da feature
+- [ ] Problema de negócio que resolve
+- [ ] Escopo (o que está DENTRO e FORA)
+
+## Atores e Personas
+- [ ] Usuários primários (quem usa diretamente)
+- [ ] Usuários secundários (afetados indiretamente)
+- [ ] Papéis e permissões (admin, user, guest, etc.)
+
+## Requisitos Funcionais
+- [ ] Fluxo principal (happy path)
+- [ ] Fluxos alternativos
+- [ ] Fluxos de exceção / erro
+- [ ] Entradas necessárias (dados, formatos, validações)
+- [ ] Saídas esperadas (resultados, notificações, estados)
+
+## Regras de Negócio
+- [ ] Regras de validação
+- [ ] Regras de cálculo / processamento
+- [ ] Regras de estado / transição
+- [ ] Regras de limite / threshold
+
+## Requisitos Não-Funcionais
+- [ ] Performance (tempo de resposta, throughput)
+- [ ] Segurança (autenticação, autorização, dados sensíveis)
+- [ ] Usabilidade (acessibilidade, responsividade)
+- [ ] Confiabilidade (disponibilidade, tolerância a falhas)
+
+## Interface
+- [ ] Telas / componentes visuais necessários
+- [ ] Integrações com APIs / serviços externos
+- [ ] Eventos / webhooks / notificações
+
+## Dependências
+- [ ] Dependências com outras features
+- [ ] Dependências com serviços externos
+- [ ] Dependências com dados pré-existentes
+
+## Critérios de Aceitação
+- [ ] Critérios mensuráveis para cada requisito funcional
+- [ ] Cenários de teste que comprovam o funcionamento
+
+## Restrições e Premissas
+- [ ] Restrições técnicas (stack, plataforma, browser)
+- [ ] Restrições de negócio (regulatórias, compliance)
+- [ ] Premissas assumidas
+```
+
+## Instruções de Uso
+
+1. Ao iniciar a entrevista, crie o Task artifact com este checklist adaptado à feature
+2. Marque `[/]` quando iniciar a discussão de um tópico
+3. Marque `[x]` quando o tópico estiver completamente resolvido (sem ambiguidade)
+4. Adicione sub-itens conforme novos pontos surgirem durante a entrevista
+5. Não remova itens — se não aplicável, marque como `[x] N/A — {justificativa}`

package/sddk/skills/software-requirements-specification/references/ieee-830-template.md

@@ -0,0 +1,151 @@
+# Template SRS — IEEE 830 / ISO/IEC/IEEE 29148:2018
+
+Use este template como base para gerar o documento SRS. Adapte as seções conforme a complexidade da feature. Nunca remova seções — se não aplicável, marque como "N/A" com justificativa.
+
+---
+
+## Estrutura do Documento
+
+```markdown
+# Especificação de Requisitos de Software (SRS)
+## {Nome da Feature}
+
+**Versão**: 1.0
+**Data**: {data de criação}
+**Projeto**: {nome do projeto}
+**Feature**: {nome da feature}
+
+---
+
+## 1. Introdução
+
+### 1.1 Propósito
+Descrever o propósito deste documento e qual feature ele especifica.
+
+### 1.2 Escopo
+Delimitação clara do que esta feature cobre e o que está FORA do escopo.
+
+### 1.3 Definições, Acrônimos e Abreviações
+Glossário de termos específicos do domínio usados neste documento.
+
+### 1.4 Referências
+Documentos externos referenciados (outros SRS, APIs, normas).
+
+### 1.5 Visão Geral do Documento
+Breve descrição da organização deste documento.
+
+---
+
+## 2. Descrição Geral
+
+### 2.1 Perspectiva do Produto
+Como esta feature se encaixa no sistema maior. Dependências com outros módulos/features.
+
+### 2.2 Funções do Produto
+Resumo de alto nível das funcionalidades que a feature provê.
+
+### 2.3 Características dos Usuários
+Personas/atores que interagem com esta feature. Nível técnico esperado.
+
+### 2.4 Restrições
+Limitações técnicas, regulatórias ou de negócio.
+
+### 2.5 Premissas e Dependências
+O que está sendo assumido como verdade e depende de fatores externos.
+
+---
+
+## 3. Requisitos Funcionais
+
+### RF-001: {Nome do Requisito}
+- **Descrição**: {O que o sistema deve fazer}
+- **Entrada**: {Dados de entrada esperados}
+- **Processamento**: {Lógica de negócio aplicada}
+- **Saída**: {Resultado esperado}
+- **Prioridade**: Alta | Média | Baixa
+- **Critério de Aceitação**: {Condições mensuráveis para considerar completo}
+
+### RF-002: {Nome do Requisito}
+(repetir estrutura para cada requisito funcional)
+
+---
+
+## 4. Requisitos Não-Funcionais
+
+### 4.1 Performance
+- Tempo de resposta esperado
+- Throughput mínimo
+- Limites de carga
+
+### 4.2 Segurança
+- Requisitos de autenticação/autorização
+- Proteção de dados sensíveis
+- Conformidade regulatória
+
+### 4.3 Usabilidade
+- Padrões de acessibilidade (WCAG nível)
+- Responsividade (dispositivos alvo)
+- Idiomas suportados
+
+### 4.4 Confiabilidade
+- Disponibilidade esperada
+- Tolerância a falhas
+- Estratégia de recovery
+
+### 4.5 Manutenibilidade
+- Padrões de código exigidos
+- Cobertura de testes mínima
+- Documentação necessária
+
+---
+
+## 5. Regras de Negócio
+
+### RN-001: {Nome da Regra}
+- **Descrição**: {Regra de negócio}
+- **Condição**: {Quando se aplica}
+- **Ação**: {O que deve acontecer}
+- **Exceções**: {Casos onde não se aplica}
+
+---
+
+## 6. Requisitos de Interface
+
+### 6.1 Interfaces de Usuário
+Descrição das telas/componentes visuais necessários.
+
+### 6.2 Interfaces de Software
+APIs, serviços externos, integrações com outros sistemas.
+
+### 6.3 Interfaces de Hardware
+Dispositivos, sensores, periféricos (se aplicável).
+
+---
+
+## 7. Matriz de Rastreabilidade
+
+| ID Requisito | Regra de Negócio | Critério de Aceitação | Prioridade |
+|:---|:---|:---|:---|
+| RF-001 | RN-001 | CA-001 | Alta |
+
+---
+
+## 8. Apêndices
+
+### 8.1 Diagrama de Casos de Uso
+(se aplicável)
+
+### 8.2 Protótipos / Wireframes
+(referências a mockups, se existirem)
+
+### 8.3 Perguntas em Aberto
+(questões não resolvidas que precisam de follow-up)
+```
+
+## Regras de Preenchimento
+
+1. **Cada requisito funcional DEVE ter critério de aceitação** — sem exceção
+2. **Requisitos devem ser testáveis** — se não pode ser verificado, não é um requisito válido
+3. **Use voz ativa** — "O sistema DEVE..." e não "Seria bom se o sistema..."
+4. **Priorize com MoSCoW** — Must/Should/Could/Won't ou Alta/Média/Baixa
+5. **IDs sequenciais** — RF-001, RF-002... / RN-001, RN-002... para rastreabilidade