spec-first-copilot 0.2.0 → 0.4.0

package/templates/docs/_templates/estrutura/Modelo_Dados.template.md

@@ -1,99 +1,99 @@
-# Modelo de Dados
-
-> Schema completo, relações, índices, convenções de nomenclatura e estratégia de migrations.
-
----
-
-<!--
-=============================================================================
-INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
-=============================================================================
-
-ORIGEM: Gerado pelo /setup-projeto a partir do TRD §4.
-ATUALIZAÇÃO: /merge-delta a cada feature que adiciona/altera tabelas (Delta Specs do SDD §3 e §11).
-
-COMO GERAR:
-1. Ler TRD §4 (Modelo de Dados Base) — tabelas iniciais, convenções
-2. Gerar diagrama ER textual com TODAS as relações
-3. Para cada tabela: campos com tipos EXATOS (varchar(255), não "string")
-4. Convenções de nomenclatura são FIXAS após setup — não mudam por feature
-5. Estratégia de migrations deve ser concreta (ferramenta, naming, rollback)
-
-REGRAS:
-- Tipos devem ser do banco escolhido (PostgreSQL, MySQL, etc.), não genéricos
-- Toda FK deve ter ON DELETE/ON UPDATE definido
-- Índices precisam de justificativa (query que justifica)
-- Convenções definidas aqui são LEI — SDDs e tasks seguem à risca
-- Diagrama ER deve ser atualizado a cada merge-delta
-
-=============================================================================
--->
-
-## Diagrama ER
-
-```
-<!-- Representação textual do ER -->
-<!-- Formato: [tabela_a] 1---N [tabela_b] (campo_fk) -->
-```
-
-## Convenções de Nomenclatura
-
-| Elemento | Convenção | Exemplo |
-|----------|-----------|---------|
-| Tabelas | snake_case, plural | `clientes`, `pedidos` |
-| Colunas | snake_case | `nome_completo`, `criado_em` |
-| PKs | `id` (UUID ou SERIAL) | `id UUID PRIMARY KEY DEFAULT gen_random_uuid()` |
-| FKs | `{tabela_singular}_id` | `cliente_id`, `cidade_id` |
-| Índices | `idx_{tabela}_{colunas}` | `idx_clientes_cpf` |
-| Unique | `uq_{tabela}_{colunas}` | `uq_clientes_email` |
-| Timestamps | `criado_em`, `atualizado_em` | `TIMESTAMPTZ NOT NULL DEFAULT now()` |
-| Soft delete | `ativo` (boolean) | `ativo BOOLEAN DEFAULT true` |
-| Auditoria | `criado_por`, `atualizado_por` | `UUID REFERENCES usuarios(id)` |
-
-## Catálogo de Tabelas
-
-<!-- Repetir bloco para cada tabela -->
-
-### {{tabela}}
-
-> Descrição breve da tabela.
-
-| Coluna | Tipo | Nullable | Default | Constraint | Descrição |
-|--------|------|----------|---------|------------|-----------|
-|        |      |          |         |            |           |
-
-**Relações:**
-- `campo_id` → `tabela_ref(id)` — ON DELETE CASCADE / SET NULL / RESTRICT
-
-**Índices:**
-
-| Nome | Colunas | Tipo | Justificativa |
-|------|---------|------|---------------|
-|      |         | btree / unique / gin | <!-- Qual query justifica este índice? --> |
-
-## Estratégia de Migrations
-
-| Aspecto | Convenção |
-|---------|-----------|
-| Ferramenta | <!-- Ex: knex, prisma, flyway, alembic --> |
-| Nomenclatura | <!-- Ex: 001_create_tabela.sql, YYYYMMDD_descricao --> |
-| Rollback | <!-- Toda migration TEM rollback? Testado como? --> |
-| Execução | <!-- Sequencial? Transacional? --> |
-| Dados existentes | <!-- Como lidar com migrations em tabelas com dados? --> |
-
-## Regras Globais de Dados
-
-| Regra | Descrição |
-|-------|-----------|
-| Soft delete | <!-- Todas as tabelas usam? Quais exceções? --> |
-| Auditoria | <!-- criado_por/atualizado_por em todas? --> |
-| Timestamps | <!-- criado_em/atualizado_em obrigatórios? --> |
-| Encoding | <!-- UTF-8? Collation? --> |
-
----
-
-## Changelog
-
-| Data | Feature | Tipo | Descrição |
-|------|---------|------|-----------|
-|      |         |      |           |
+# Modelo de Dados
+
+> Schema completo, relações, índices, convenções de nomenclatura e estratégia de migrations.
+
+---
+
+<!--
+=============================================================================
+INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
+=============================================================================
+
+ORIGEM: Gerado pelo /setup-projeto a partir do TRD §4.
+ATUALIZAÇÃO: /merge-delta a cada feature que adiciona/altera tabelas (Delta Specs do SDD §3 e §11).
+
+COMO GERAR:
+1. Ler TRD §4 (Modelo de Dados Base) — tabelas iniciais, convenções
+2. Gerar diagrama ER textual com TODAS as relações
+3. Para cada tabela: campos com tipos EXATOS (varchar(255), não "string")
+4. Convenções de nomenclatura são FIXAS após setup — não mudam por feature
+5. Estratégia de migrations deve ser concreta (ferramenta, naming, rollback)
+
+REGRAS:
+- Tipos devem ser do banco escolhido (PostgreSQL, MySQL, etc.), não genéricos
+- Toda FK deve ter ON DELETE/ON UPDATE definido
+- Índices precisam de justificativa (query que justifica)
+- Convenções definidas aqui são LEI — SDDs e tasks seguem à risca
+- Diagrama ER deve ser atualizado a cada merge-delta
+
+=============================================================================
+-->
+
+## Diagrama ER
+
+```
+<!-- Representação textual do ER -->
+<!-- Formato: [tabela_a] 1---N [tabela_b] (campo_fk) -->
+```
+
+## Convenções de Nomenclatura
+
+| Elemento | Convenção | Exemplo |
+|----------|-----------|---------|
+| Tabelas | snake_case, plural | `clientes`, `pedidos` |
+| Colunas | snake_case | `nome_completo`, `criado_em` |
+| PKs | `id` (UUID ou SERIAL) | `id UUID PRIMARY KEY DEFAULT gen_random_uuid()` |
+| FKs | `{tabela_singular}_id` | `cliente_id`, `cidade_id` |
+| Índices | `idx_{tabela}_{colunas}` | `idx_clientes_cpf` |
+| Unique | `uq_{tabela}_{colunas}` | `uq_clientes_email` |
+| Timestamps | `criado_em`, `atualizado_em` | `TIMESTAMPTZ NOT NULL DEFAULT now()` |
+| Soft delete | `ativo` (boolean) | `ativo BOOLEAN DEFAULT true` |
+| Auditoria | `criado_por`, `atualizado_por` | `UUID REFERENCES usuarios(id)` |
+
+## Catálogo de Tabelas
+
+<!-- Repetir bloco para cada tabela -->
+
+### {{tabela}}
+
+> Descrição breve da tabela.
+
+| Coluna | Tipo | Nullable | Default | Constraint | Descrição |
+|--------|------|----------|---------|------------|-----------|
+|        |      |          |         |            |           |
+
+**Relações:**
+- `campo_id` → `tabela_ref(id)` — ON DELETE CASCADE / SET NULL / RESTRICT
+
+**Índices:**
+
+| Nome | Colunas | Tipo | Justificativa |
+|------|---------|------|---------------|
+|      |         | btree / unique / gin | <!-- Qual query justifica este índice? --> |
+
+## Estratégia de Migrations
+
+| Aspecto | Convenção |
+|---------|-----------|
+| Ferramenta | <!-- Ex: knex, prisma, flyway, alembic --> |
+| Nomenclatura | <!-- Ex: 001_create_tabela.sql, YYYYMMDD_descricao --> |
+| Rollback | <!-- Toda migration TEM rollback? Testado como? --> |
+| Execução | <!-- Sequencial? Transacional? --> |
+| Dados existentes | <!-- Como lidar com migrations em tabelas com dados? --> |
+
+## Regras Globais de Dados
+
+| Regra | Descrição |
+|-------|-----------|
+| Soft delete | <!-- Todas as tabelas usam? Quais exceções? --> |
+| Auditoria | <!-- criado_por/atualizado_por em todas? --> |
+| Timestamps | <!-- criado_em/atualizado_em obrigatórios? --> |
+| Encoding | <!-- UTF-8? Collation? --> |
+
+---
+
+## Changelog
+
+| Data | Feature | Tipo | Descrição |
+|------|---------|------|-----------|
+|      |         |      |           |

package/templates/docs/_templates/estrutura/Seguranca.template.md

@@ -1,138 +1,138 @@
-# Segurança
-
-> Autenticação, autorização, CORS, rate limiting, LGPD, auditoria e proteção de dados.
-
----
-
-<!--
-=============================================================================
-INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
-=============================================================================
-
-ORIGEM: Gerado pelo /setup-projeto a partir do TRD §7.
-ATUALIZAÇÃO: /merge-delta quando features adicionam permissões, dados pessoais ou políticas.
-
-COMO GERAR:
-1. Ler TRD §7 (Segurança) — autenticação, autorização, CORS, LGPD
-2. Autenticação: método, expiração, hash, refresh strategy
-3. Autorização: papéis e matriz de permissões (RBAC/ABAC)
-4. LGPD: mapear TODOS dados pessoais com base legal
-5. Auditoria: definir O QUE é logado, ONDE e POR QUANTO TEMPO
-
-REGRAS:
-- Matriz de permissões é DINÂMICA — cresce a cada feature (via merge-delta)
-- Dados pessoais da LGPD precisam de base legal ESPECÍFICA
-- Nunca armazenar senhas em texto plano (hash obrigatório)
-- Secrets nunca no código — sempre variáveis de ambiente
-- Rate limiting obrigatório em endpoints públicos (login, registro)
-- Auditoria obrigatória para operações destrutivas (delete, update de dados sensíveis)
-
-=============================================================================
--->
-
-## Autenticação
-
-| Aspecto | Implementação |
-|---------|--------------|
-| Método | <!-- JWT? Session? OAuth2? --> |
-| Expiração access token | <!-- Ex: 15min --> |
-| Refresh token | <!-- Existe? Expiração? Rotação? --> |
-| Hash de senha | <!-- bcrypt rounds? argon2? --> |
-| Header | <!-- Authorization: Bearer {token} --> |
-| Armazenamento (client) | <!-- httpOnly cookie? localStorage? --> |
-
-### Fluxo de autenticação
-
-```
-<!-- Descrever o fluxo: login → token → refresh → logout -->
-```
-
-## Autorização
-
-### Modelo
-
-| Aspecto | Decisão |
-|---------|---------|
-| Tipo | <!-- RBAC / ABAC / RBAC + ABAC --> |
-| Onde é verificado | <!-- Middleware? Decorator? Service? --> |
-| Granularidade | <!-- Por rota? Por recurso? Por campo? --> |
-
-### Papéis
-
-| Papel | Descrição | Herda de |
-|-------|-----------|----------|
-|       |           | <!-- Hierarquia: admin herda de user? --> |
-
-### Matriz de Permissões
-
-> Atualizada a cada feature via /merge-delta.
-
-| Recurso | Ação | {{role_1}} | {{role_2}} | {{role_N}} |
-|---------|------|------------|------------|------------|
-|         | criar | | | |
-|         | ler | | | |
-|         | editar | | | |
-|         | deletar | | | |
-
-## CORS
-
-| Aspecto | Configuração |
-|---------|-------------|
-| Allowed Origins | <!-- Configurável por ambiente --> |
-| Allowed Methods | `GET, POST, PUT, PATCH, DELETE` |
-| Allowed Headers | `Authorization, Content-Type` |
-| Credentials | <!-- true/false --> |
-| Max Age | <!-- Preflight cache em segundos --> |
-
-## Rate Limiting
-
-| Categoria | Limite | Janela | Resposta |
-|-----------|--------|--------|----------|
-| Login/Registro | <!-- Ex: 5 req --> | <!-- Ex: 15min --> | 429 + Retry-After |
-| API autenticada | <!-- Ex: 100 req --> | <!-- Ex: 1min --> | 429 + Retry-After |
-| API pública | <!-- Ex: 30 req --> | <!-- Ex: 1min --> | 429 + Retry-After |
-| Upload | <!-- Ex: 10 req --> | <!-- Ex: 1h --> | 429 + Retry-After |
-
-## LGPD / Privacidade
-
-### Dados pessoais coletados
-
-| Dado | Base legal | Finalidade | Retenção | Criptografado? |
-|------|-----------|------------|----------|----------------|
-|      | <!-- Consentimento / Contrato / Legítimo interesse / Obrigação legal --> | | | |
-
-### Direitos do titular
-
-| Direito | Implementação | Endpoint/Fluxo |
-|---------|--------------|----------------|
-| Acesso aos dados | | <!-- Como o usuário acessa? --> |
-| Correção | | |
-| Exclusão (right to be forgotten) | | <!-- Soft delete? Hard delete? Anonimização? --> |
-| Portabilidade | | <!-- Formato de exportação? --> |
-| Revogação de consentimento | | |
-
-## Auditoria
-
-| O que é logado | Quando | Onde armazena | Retenção |
-|----------------|--------|---------------|----------|
-| Login/Logout | sempre | | |
-| Alteração de dados sensíveis | sempre | | |
-| Operações destrutivas (DELETE) | sempre | | |
-| Falhas de autenticação | sempre | | |
-| Mudanças de permissão | sempre | | |
-
-## Proteção de Dados em Trânsito e Repouso
-
-| Aspecto | Implementação |
-|---------|--------------|
-| TLS | <!-- Versão mínima? --> |
-| Dados sensíveis em repouso | <!-- Criptografia? Quais campos? --> |
-| Backup | <!-- Criptografado? Frequência? --> |
-
----
-
-## Changelog
-
-| Data | Feature | Tipo | Descrição |
-|------|---------|------|-----------|
-|      |         |      |           |
+# Segurança
+
+> Autenticação, autorização, CORS, rate limiting, LGPD, auditoria e proteção de dados.
+
+---
+
+<!--
+=============================================================================
+INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
+=============================================================================
+
+ORIGEM: Gerado pelo /setup-projeto a partir do TRD §7.
+ATUALIZAÇÃO: /merge-delta quando features adicionam permissões, dados pessoais ou políticas.
+
+COMO GERAR:
+1. Ler TRD §7 (Segurança) — autenticação, autorização, CORS, LGPD
+2. Autenticação: método, expiração, hash, refresh strategy
+3. Autorização: papéis e matriz de permissões (RBAC/ABAC)
+4. LGPD: mapear TODOS dados pessoais com base legal
+5. Auditoria: definir O QUE é logado, ONDE e POR QUANTO TEMPO
+
+REGRAS:
+- Matriz de permissões é DINÂMICA — cresce a cada feature (via merge-delta)
+- Dados pessoais da LGPD precisam de base legal ESPECÍFICA
+- Nunca armazenar senhas em texto plano (hash obrigatório)
+- Secrets nunca no código — sempre variáveis de ambiente
+- Rate limiting obrigatório em endpoints públicos (login, registro)
+- Auditoria obrigatória para operações destrutivas (delete, update de dados sensíveis)
+
+=============================================================================
+-->
+
+## Autenticação
+
+| Aspecto | Implementação |
+|---------|--------------|
+| Método | <!-- JWT? Session? OAuth2? --> |
+| Expiração access token | <!-- Ex: 15min --> |
+| Refresh token | <!-- Existe? Expiração? Rotação? --> |
+| Hash de senha | <!-- bcrypt rounds? argon2? --> |
+| Header | <!-- Authorization: Bearer {token} --> |
+| Armazenamento (client) | <!-- httpOnly cookie? localStorage? --> |
+
+### Fluxo de autenticação
+
+```
+<!-- Descrever o fluxo: login → token → refresh → logout -->
+```
+
+## Autorização
+
+### Modelo
+
+| Aspecto | Decisão |
+|---------|---------|
+| Tipo | <!-- RBAC / ABAC / RBAC + ABAC --> |
+| Onde é verificado | <!-- Middleware? Decorator? Service? --> |
+| Granularidade | <!-- Por rota? Por recurso? Por campo? --> |
+
+### Papéis
+
+| Papel | Descrição | Herda de |
+|-------|-----------|----------|
+|       |           | <!-- Hierarquia: admin herda de user? --> |
+
+### Matriz de Permissões
+
+> Atualizada a cada feature via /merge-delta.
+
+| Recurso | Ação | {{role_1}} | {{role_2}} | {{role_N}} |
+|---------|------|------------|------------|------------|
+|         | criar | | | |
+|         | ler | | | |
+|         | editar | | | |
+|         | deletar | | | |
+
+## CORS
+
+| Aspecto | Configuração |
+|---------|-------------|
+| Allowed Origins | <!-- Configurável por ambiente --> |
+| Allowed Methods | `GET, POST, PUT, PATCH, DELETE` |
+| Allowed Headers | `Authorization, Content-Type` |
+| Credentials | <!-- true/false --> |
+| Max Age | <!-- Preflight cache em segundos --> |
+
+## Rate Limiting
+
+| Categoria | Limite | Janela | Resposta |
+|-----------|--------|--------|----------|
+| Login/Registro | <!-- Ex: 5 req --> | <!-- Ex: 15min --> | 429 + Retry-After |
+| API autenticada | <!-- Ex: 100 req --> | <!-- Ex: 1min --> | 429 + Retry-After |
+| API pública | <!-- Ex: 30 req --> | <!-- Ex: 1min --> | 429 + Retry-After |
+| Upload | <!-- Ex: 10 req --> | <!-- Ex: 1h --> | 429 + Retry-After |
+
+## LGPD / Privacidade
+
+### Dados pessoais coletados
+
+| Dado | Base legal | Finalidade | Retenção | Criptografado? |
+|------|-----------|------------|----------|----------------|
+|      | <!-- Consentimento / Contrato / Legítimo interesse / Obrigação legal --> | | | |
+
+### Direitos do titular
+
+| Direito | Implementação | Endpoint/Fluxo |
+|---------|--------------|----------------|
+| Acesso aos dados | | <!-- Como o usuário acessa? --> |
+| Correção | | |
+| Exclusão (right to be forgotten) | | <!-- Soft delete? Hard delete? Anonimização? --> |
+| Portabilidade | | <!-- Formato de exportação? --> |
+| Revogação de consentimento | | |
+
+## Auditoria
+
+| O que é logado | Quando | Onde armazena | Retenção |
+|----------------|--------|---------------|----------|
+| Login/Logout | sempre | | |
+| Alteração de dados sensíveis | sempre | | |
+| Operações destrutivas (DELETE) | sempre | | |
+| Falhas de autenticação | sempre | | |
+| Mudanças de permissão | sempre | | |
+
+## Proteção de Dados em Trânsito e Repouso
+
+| Aspecto | Implementação |
+|---------|--------------|
+| TLS | <!-- Versão mínima? --> |
+| Dados sensíveis em repouso | <!-- Criptografia? Quais campos? --> |
+| Backup | <!-- Criptografado? Frequência? --> |
+
+---
+
+## Changelog
+
+| Data | Feature | Tipo | Descrição |
+|------|---------|------|-----------|
+|      |         |      |           |

package/templates/docs/_templates/estrutura/Stack.template.md

@@ -1,78 +1,78 @@
-# Stack Tecnológica
-
-> Tecnologias escolhidas, versões fixadas, e alternativas descartadas com justificativa.
-
----
-
-<!--
-=============================================================================
-INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
-=============================================================================
-
-ORIGEM: Gerado pelo /setup-projeto a partir do TRD §2.
-ATUALIZAÇÃO: /merge-delta quando features introduzem novas tecnologias ou mudanças de stack (raro — deve gerar ADR).
-
-COMO GERAR:
-1. Ler TRD §2 (Stack e Tecnologias) — todas decisões de tech
-2. Preencher TODAS as camadas, mesmo que "a definir"
-3. Para cada tecnologia: versão EXATA (não "latest")
-4. Justificativa deve ser técnica, não "é popular"
-5. Alternativas descartadas: documentar POR QUE foram rejeitadas (evita rediscussão)
-
-REGRAS:
-- Versões devem ser fixadas (ex: "18.3.1", não "^18.0.0")
-- Cada biblioteca/pacote precisa de justificativa (evita bloat)
-- Alternativas descartadas previnem que o time rediscuta decisões já tomadas
-- Mudanças de stack DEVEM gerar ADR em ADRs.md
-- Camadas são dinâmicas — adicionar conforme necessidade (mobile, infra, etc.)
-
-=============================================================================
--->
-
-## Stack Principal
-
-| Camada | Tecnologia | Versão | Justificativa |
-|--------|-----------|--------|---------------|
-| Frontend | | | |
-| Backend | | | |
-| Banco de Dados | | | |
-| ORM/Query Builder | | | |
-| Autenticação | | | |
-| Testes | | | |
-| CI/CD | | | |
-
-<!-- Adicionar camadas conforme necessidade: Mobile, Cache, Fila, Monitoramento, etc. -->
-
-## Bibliotecas e Dependências
-
-<!-- Repetir seção para cada camada que tenha dependências relevantes -->
-
-### {{Camada}}
-
-| Pacote | Versão | Para quê | Alternativa descartada |
-|--------|--------|----------|----------------------|
-|        |        |          |                      |
-
-## Alternativas Descartadas
-
-> Decisões já tomadas. Se alguém perguntar "por que não usamos X?", a resposta está aqui.
-
-| Tecnologia escolhida | Alternativa considerada | Por que descartamos | Ref ADR |
-|----------------------|------------------------|---------------------|---------|
-|                      |                        |                     |         |
-
-## Convenções de Versionamento
-
-| Aspecto | Convenção |
-|---------|-----------|
-| Versionamento | <!-- Semver? Pinned? --> |
-| Lock files | <!-- package-lock.json? yarn.lock? --> |
-| Atualização | <!-- Dependabot? Manual? Periodicidade? --> |
-
----
-
-## Changelog
-
-| Data | Feature | Tipo | Descrição |
-|------|---------|------|-----------|
-|      |         |      |           |
+# Stack Tecnológica
+
+> Tecnologias escolhidas, versões fixadas, e alternativas descartadas com justificativa.
+
+---
+
+<!--
+=============================================================================
+INSTRUÇÕES PARA O AGENTE (não incluir no arquivo gerado)
+=============================================================================
+
+ORIGEM: Gerado pelo /setup-projeto a partir do TRD §2.
+ATUALIZAÇÃO: /merge-delta quando features introduzem novas tecnologias ou mudanças de stack (raro — deve gerar ADR).
+
+COMO GERAR:
+1. Ler TRD §2 (Stack e Tecnologias) — todas decisões de tech
+2. Preencher TODAS as camadas, mesmo que "a definir"
+3. Para cada tecnologia: versão EXATA (não "latest")
+4. Justificativa deve ser técnica, não "é popular"
+5. Alternativas descartadas: documentar POR QUE foram rejeitadas (evita rediscussão)
+
+REGRAS:
+- Versões devem ser fixadas (ex: "18.3.1", não "^18.0.0")
+- Cada biblioteca/pacote precisa de justificativa (evita bloat)
+- Alternativas descartadas previnem que o time rediscuta decisões já tomadas
+- Mudanças de stack DEVEM gerar ADR em ADRs.md
+- Camadas são dinâmicas — adicionar conforme necessidade (mobile, infra, etc.)
+
+=============================================================================
+-->
+
+## Stack Principal
+
+| Camada | Tecnologia | Versão | Justificativa |
+|--------|-----------|--------|---------------|
+| Frontend | | | |
+| Backend | | | |
+| Banco de Dados | | | |
+| ORM/Query Builder | | | |
+| Autenticação | | | |
+| Testes | | | |
+| CI/CD | | | |
+
+<!-- Adicionar camadas conforme necessidade: Mobile, Cache, Fila, Monitoramento, etc. -->
+
+## Bibliotecas e Dependências
+
+<!-- Repetir seção para cada camada que tenha dependências relevantes -->
+
+### {{Camada}}
+
+| Pacote | Versão | Para quê | Alternativa descartada |
+|--------|--------|----------|----------------------|
+|        |        |          |                      |
+
+## Alternativas Descartadas
+
+> Decisões já tomadas. Se alguém perguntar "por que não usamos X?", a resposta está aqui.
+
+| Tecnologia escolhida | Alternativa considerada | Por que descartamos | Ref ADR |
+|----------------------|------------------------|---------------------|---------|
+|                      |                        |                     |         |
+
+## Convenções de Versionamento
+
+| Aspecto | Convenção |
+|---------|-----------|
+| Versionamento | <!-- Semver? Pinned? --> |
+| Lock files | <!-- package-lock.json? yarn.lock? --> |
+| Atualização | <!-- Dependabot? Manual? Periodicidade? --> |
+
+---
+
+## Changelog
+
+| Data | Feature | Tipo | Descrição |
+|------|---------|------|-----------|
+|      |         |      |           |