adi_dev_workflow 1.1.1 → 1.3.0

package/frameworks/skills/sdd-tech-spec-expert/templates/spec_tech_template.md

@@ -1,290 +1,290 @@
-# SPEC_TECH -- Especificação Técnica
-
-## 1. Identificação
-- **Feature/Projeto**:
-- **Autor**:
-- **Data**:
-- **Versão**:
-- **Status**: Draft | Refinando | Aprovado
-- **PRD Relacionado**:
-
----
-
-## 2. Resumo Técnico da Solução
-
-(Visão geral do COMO será implementado. Descreva em 3-5 linhas a abordagem técnica escolhida, as principais decisões arquiteturais e o resultado técnico esperado.)
-
----
-
-## 3. Arquitetura da Solução
-
-### 3.1 Visão Geral
-(Diagrama ou descrição da arquitetura geral da solução. Como os componentes se conectam.)
-
-### 3.2 Componentes/Módulos
-(Lista de componentes envolvidos com descrição da responsabilidade de cada um.)
-
-| Componente | Responsabilidade | Camada |
-|------------|-----------------|--------|
-|            |                 |        |
-
-### 3.3 Interações entre componentes
-(Descreva como os componentes se comunicam. Fluxo de dados entre camadas.)
-
----
-
-## 4. Estruturas de Dados
-
-### 4.1 Models / DTOs
-(Structs, tipos e modelos de domínio que serão criados ou modificados.)
-
-### 4.2 Entidades de Banco de Dados
-(Tabelas, colunas, índices, constraints. Inclua SQL de migrações quando aplicável.)
-
-### 4.3 Schemas adicionais
-(Protocol Buffers, mensagens gRPC, schemas de validação ou outros formatos de dados.)
-
----
-
-## 5. Regras Técnicas de Negócio
-
-(Implementação técnica das regras definidas no PRD. Cada regra do PRD deve ter uma definição técnica correspondente.)
-
-### 5.1 Mapeamento de User Stories para Definições Técnicas
-
-| User Story (PRD) | Definição Técnica | Componentes Envolvidos |
-|------------------|-------------------|----------------------|
-| US-01            |                   |                      |
-| US-02            |                   |                      |
-
-<!-- LLM-ONLY: Cada user story do PRD deve ter pelo menos uma definicao tecnica correspondente. Isso garante rastreabilidade completa entre o PRD e a especificacao tecnica. -->
-
----
-
-## 6. Fluxos Técnicos
-
-### 6.1 Fluxo Principal (técnico)
-(Sequência de chamadas, processamento e respostas do fluxo principal. Descreva camada por camada.)
-
-### 6.2 Fluxos Alternativos
-(Variações do fluxo principal: dados opcionais, caminhos condicionais, etc.)
-
-### 6.3 Tratamento de Erros
-(Como erros serão tratados em cada camada. Mapeamento de erros de negócio para códigos de status.)
-
-| Erro de Negócio | Código de Status | Mensagem | Camada de Origem |
-|----------------|-----------------|----------|-----------------|
-|                |                 |          |                 |
-
----
-
-## 7. APIs / Endpoints
-
-### 7.1 Endpoints Backend
-
-| Ação | Método | Rota | Payload | Resposta Esperada |
-|------|--------|------|---------|-------------------|
-|      |        |      |         |                   |
-
-### 7.2 Erros e Códigos de Status
-
-| Código | Situação | Mensagem |
-|--------|----------|----------|
-|        |          |          |
-
----
-
-## 8. Frontend / Mobile
-
-### 8.1 Telas
-(Telas envolvidas, layouts e componentes visuais.)
-
-### 8.2 Estados e Gerência de Estado
-(Gerenciamento de estado: loading, success, error, empty. Solução de state management.)
-
-### 8.3 Navegação
-(Fluxo de navegação entre telas. Rotas e parâmetros.)
-
-### 8.4 Validações
-(Validações de formulário, campos obrigatórios, máscaras, limites.)
-
-### 8.5 Comportamentos específicos
-(Animações, transições, comportamentos offline, responsividade.)
-
----
-
-## 9. Banco Local / Cache
-
-### 9.1 Estrutura de Tabelas
-(Tabelas locais, colunas, tipos. Diferentes do banco remoto se aplicável.)
-
-### 9.2 Estratégia de Sincronização
-(Como dados locais sincronizam com o backend. Conflitos, prioridade, frequência.)
-
-### 9.3 Estratégia de Versionamento
-(Como lidar com mudanças de schema local. Migrações locais, rollback.)
-
----
-
-## 10. Dependências Técnicas
-
-| Tipo | Nome | Versão | Motivo |
-|------|------|--------|--------|
-| Pacote |    |        |        |
-| Biblioteca | | |    |
-| Ferramenta | | |    |
-| SDK |        |        |        |
-
----
-
-## 11. Requisitos Não Funcionais (COMO serão atendidos)
-
-### Segurança
-(Autenticação, autorização, criptografia, validação de input, sanitização.)
-
-### Performance
-(Metas de tempo de resposta, paginação, índices, cache, otimizações.)
-
-### Escalabilidade
-(Limites conhecidos, estratégia de crescimento, gargalos potenciais.)
-
-### Observabilidade
-(Logs estruturados, métricas, alertas, tracing distribuído.)
-
-### Resiliência
-(Tratamento de falhas, retry, circuit breaker, graceful degradation.)
-
----
-
-## 12. Critérios Técnicos de Aceite
-
-- [ ] Implementação cobre todas as regras do PRD
-- [ ] Estruturas de dados criadas e funcionais
-- [ ] Fluxos técnicos implementados e testados
-- [ ] API funcionando conforme especificado
-- [ ] Erros tratados em todas as camadas
-- [ ] Logs/monitoramento implementados
-- [ ] Validações aplicadas (input, negócio, dados)
-- [ ] Código segue padrões e convenções do projeto
-
----
-
-## 13. Riscos Técnicos
-
-| Risco | Probabilidade | Impacto | Mitigação |
-|-------|--------------|---------|-----------|
-|       |              |         |           |
-
----
-
-## 14. Estratégia de Testes
-
-> **Resumo**: X casos de teste | Unitários: Y | Integração: Z | E2E: W
-> **Padrão**: [framework de teste, padrão de mock, convenção de nomes]
-
-### Rastreabilidade: Critérios de Aceite → Testes
-
-| CA (PRD) | Descrição Resumida | Testes |
-|----------|-------------------|--------|
-| CA-01    | (descrição curta do CA no PRD) | CT-01, CT-10, CT-20, CT-30 |
-| CA-02    | (descrição curta do CA no PRD) | CT-02, CT-22 |
-
-<!-- LLM-ONLY: Cada CA-XX do PRD deve ter pelo menos um teste correspondente. Esta tabela deve ser preenchida PRIMEIRO — guia toda a estrategia. -->
-
----
-
-### 14.1 Testes Unitários
-
-<!-- LLM-ONLY: Coluna "Objetivo": Descreva em 1 frase O QUE o teste valida e POR QUE importa. Use o padrao: Verbo + comportamento especifico + condicao. Exemplo: "Verificar que apenas categorias com ativo=1 sao retornadas, ordenadas pelo campo 'ordem'". NAO repita o nome do teste — o objetivo deve dar contexto que o nome sozinho nao da. -->
-
-#### Service: [NomeService] (`arquivo_test.go`)
-
-Mock: [interfaces mockadas]
-
-| CT | Teste | CA | Objetivo | Input | Expected | Mock |
-|----|-------|----|----------|-------|----------|------|
-| CT-01 | TestMetodo_Sucesso | CA-01 | Verificar que [comportamento esperado] quando [condição do cenário] | dados válidos | resultado esperado | repo retorna dados |
-| CT-02 | TestMetodo_ErroValidacao | CA-03 | Verificar que [erro específico] é retornado quando [condição inválida] | dados inválidos | ErrEspecifico | — |
-
-#### Apresentação: [NomeHandler] (`arquivo_test.go`)
-
-Mock: [interfaces mockadas]
-
-| CT | Teste | CA | Objetivo | Input | Expected | Mock |
-|----|-------|----|----------|-------|----------|------|
-| CT-10 | TestHandler_Sucesso | CA-01 | Verificar que handler converte [modelo domínio] para [formato response] corretamente | request válido | response proto | service retorna sucesso |
-
-### 14.2 Testes de Integração
-
-#### [CamadaA + CamadaB] (`arquivo_test.go`)
-
-Setup: [banco in-memory, migrações, fixtures]
-
-| CT | Teste | CA | Objetivo | Fluxo | Validação |
-|----|-------|----|----------|-------|-----------|
-| CT-20 | TestIntegracao_CRUD | CA-01 | Verificar que dados persistidos são recuperados integralmente via [camada] | Create → Get | dados consistentes |
-| CT-22 | TestIntegracao_Unique | CA-02 | Verificar que constraint unique impede duplicação de [campo] | Insert duplicado | erro constraint |
-
-### 14.3 Testes End-to-End (E2E)
-
-#### Fluxo: [Nome do Fluxo Crítico] (CT-30)
-- **CA**: CA-01, CA-03, CA-06
-- **Objetivo**: (1 frase descrevendo o que este fluxo E2E valida de ponta a ponta)
-- **Pré-condições**: (estado inicial do sistema)
-- **Passos**:
-  1. Cliente envia request X
-  2. Sistema processa e retorna Y
-  3. Verificar estado do banco
-- **Validações**: (assertions sobre dados e estado final)
-
-### 14.4 Cenários de Erro
-
-| Cenário | CA | Objetivo | Trigger | Código/Status | Log Esperado |
-|---------|----|----------|---------|---------------|-------------|
-| Dados duplicados | CA-02 | Verificar que [constraint] impede [operação] e retorna erro adequado | Insert duplicado | [erro conflito] | "registro já existe..." |
-| Recurso inexistente | CA-05 | Verificar que acesso a [recurso] inexistente retorna [código] sem expor dados internos | ID não encontrado | [erro not found] | "não encontrado..." |
-
----
-
-## 15. Arquivos Envolvidos e Ações
-
-### 15.1 Arquivos a Criar
-
-| Arquivo | Descrição | Camada |
-|---------|-----------|--------|
-|         |           |        |
-
-### 15.2 Arquivos a Modificar
-
-| Arquivo | Modificação | Motivo |
-|---------|------------|--------|
-|         |            |        |
-
-### 15.3 Arquivos de Referência (somente leitura)
-
-| Arquivo | Motivo da Consulta |
-|---------|-------------------|
-|         |                   |
-
-<!-- LLM-ONLY: Esta secao economiza tokens e scans durante a implementacao, pois lista exatamente quais arquivos serao impactados. -->
-
----
-
-## 16. Checklist Final
-
-- [ ] SPEC_TECH cobre todo o PRD
-- [ ] Resumo técnico claro e objetivo (seção 2)
-- [ ] Arquitetura definida com componentes e interações (seção 3)
-- [ ] Estruturas de dados definidas (seção 4)
-- [ ] User Stories mapeadas para definições técnicas (seção 5.1)
-- [ ] Fluxos técnicos descritos com tratamento de erros (seção 6)
-- [ ] Endpoints mapeados com payloads e respostas (seção 7)
-- [ ] Telas e fluxos de frontend/mobile definidos (seção 8)
-- [ ] Banco local/cache especificado se aplicável (seção 9)
-- [ ] Dependências técnicas listadas (seção 10)
-- [ ] Requisitos não funcionais endereçados (seção 11)
-- [ ] Critérios técnicos de aceite definidos (seção 12)
-- [ ] Riscos técnicos identificados com mitigações (seção 13)
-- [ ] Estratégia de testes definida com rastreabilidade CA→testes no topo (seção 14)
-- [ ] Arquivos envolvidos listados — criar, modificar, referência (seção 15)
-- [ ] Pronto para geração das TASKS
+# SPEC_TECH -- Especificação Técnica
+
+## 1. Identificação
+- **Feature/Projeto**:
+- **Autor**:
+- **Data**:
+- **Versão**:
+- **Status**: Draft | Refinando | Aprovado
+- **PRD Relacionado**:
+
+---
+
+## 2. Resumo Técnico da Solução
+
+(Visão geral do COMO será implementado. Descreva em 3-5 linhas a abordagem técnica escolhida, as principais decisões arquiteturais e o resultado técnico esperado.)
+
+---
+
+## 3. Arquitetura da Solução
+
+### 3.1 Visão Geral
+(Diagrama ou descrição da arquitetura geral da solução. Como os componentes se conectam.)
+
+### 3.2 Componentes/Módulos
+(Lista de componentes envolvidos com descrição da responsabilidade de cada um.)
+
+| Componente | Responsabilidade | Camada |
+|------------|-----------------|--------|
+|            |                 |        |
+
+### 3.3 Interações entre componentes
+(Descreva como os componentes se comunicam. Fluxo de dados entre camadas.)
+
+---
+
+## 4. Estruturas de Dados
+
+### 4.1 Models / DTOs
+(Structs, tipos e modelos de domínio que serão criados ou modificados.)
+
+### 4.2 Entidades de Banco de Dados
+(Tabelas, colunas, índices, constraints. Inclua SQL de migrações quando aplicável.)
+
+### 4.3 Schemas adicionais
+(Protocol Buffers, mensagens gRPC, schemas de validação ou outros formatos de dados.)
+
+---
+
+## 5. Regras Técnicas de Negócio
+
+(Implementação técnica das regras definidas no PRD. Cada regra do PRD deve ter uma definição técnica correspondente.)
+
+### 5.1 Mapeamento de User Stories para Definições Técnicas
+
+| User Story (PRD) | Definição Técnica | Componentes Envolvidos |
+|------------------|-------------------|----------------------|
+| US-01            |                   |                      |
+| US-02            |                   |                      |
+
+<!-- LLM-ONLY: Cada user story do PRD deve ter pelo menos uma definicao tecnica correspondente. Isso garante rastreabilidade completa entre o PRD e a especificacao tecnica. -->
+
+---
+
+## 6. Fluxos Técnicos
+
+### 6.1 Fluxo Principal (técnico)
+(Sequência de chamadas, processamento e respostas do fluxo principal. Descreva camada por camada.)
+
+### 6.2 Fluxos Alternativos
+(Variações do fluxo principal: dados opcionais, caminhos condicionais, etc.)
+
+### 6.3 Tratamento de Erros
+(Como erros serão tratados em cada camada. Mapeamento de erros de negócio para códigos de status.)
+
+| Erro de Negócio | Código de Status | Mensagem | Camada de Origem |
+|----------------|-----------------|----------|-----------------|
+|                |                 |          |                 |
+
+---
+
+## 7. APIs / Endpoints
+
+### 7.1 Endpoints Backend
+
+| Ação | Método | Rota | Payload | Resposta Esperada |
+|------|--------|------|---------|-------------------|
+|      |        |      |         |                   |
+
+### 7.2 Erros e Códigos de Status
+
+| Código | Situação | Mensagem |
+|--------|----------|----------|
+|        |          |          |
+
+---
+
+## 8. Frontend / Mobile
+
+### 8.1 Telas
+(Telas envolvidas, layouts e componentes visuais.)
+
+### 8.2 Estados e Gerência de Estado
+(Gerenciamento de estado: loading, success, error, empty. Solução de state management.)
+
+### 8.3 Navegação
+(Fluxo de navegação entre telas. Rotas e parâmetros.)
+
+### 8.4 Validações
+(Validações de formulário, campos obrigatórios, máscaras, limites.)
+
+### 8.5 Comportamentos específicos
+(Animações, transições, comportamentos offline, responsividade.)
+
+---
+
+## 9. Banco Local / Cache
+
+### 9.1 Estrutura de Tabelas
+(Tabelas locais, colunas, tipos. Diferentes do banco remoto se aplicável.)
+
+### 9.2 Estratégia de Sincronização
+(Como dados locais sincronizam com o backend. Conflitos, prioridade, frequência.)
+
+### 9.3 Estratégia de Versionamento
+(Como lidar com mudanças de schema local. Migrações locais, rollback.)
+
+---
+
+## 10. Dependências Técnicas
+
+| Tipo | Nome | Versão | Motivo |
+|------|------|--------|--------|
+| Pacote |    |        |        |
+| Biblioteca | | |    |
+| Ferramenta | | |    |
+| SDK |        |        |        |
+
+---
+
+## 11. Requisitos Não Funcionais (COMO serão atendidos)
+
+### Segurança
+(Autenticação, autorização, criptografia, validação de input, sanitização.)
+
+### Performance
+(Metas de tempo de resposta, paginação, índices, cache, otimizações.)
+
+### Escalabilidade
+(Limites conhecidos, estratégia de crescimento, gargalos potenciais.)
+
+### Observabilidade
+(Logs estruturados, métricas, alertas, tracing distribuído.)
+
+### Resiliência
+(Tratamento de falhas, retry, circuit breaker, graceful degradation.)
+
+---
+
+## 12. Critérios Técnicos de Aceite
+
+- [ ] Implementação cobre todas as regras do PRD
+- [ ] Estruturas de dados criadas e funcionais
+- [ ] Fluxos técnicos implementados e testados
+- [ ] API funcionando conforme especificado
+- [ ] Erros tratados em todas as camadas
+- [ ] Logs/monitoramento implementados
+- [ ] Validações aplicadas (input, negócio, dados)
+- [ ] Código segue padrões e convenções do projeto
+
+---
+
+## 13. Riscos Técnicos
+
+| Risco | Probabilidade | Impacto | Mitigação |
+|-------|--------------|---------|-----------|
+|       |              |         |           |
+
+---
+
+## 14. Estratégia de Testes
+
+> **Resumo**: X casos de teste | Unitários: Y | Integração: Z | E2E: W
+> **Padrão**: [framework de teste, padrão de mock, convenção de nomes]
+
+### Rastreabilidade: Critérios de Aceite → Testes
+
+| CA (PRD) | Descrição Resumida | Testes |
+|----------|-------------------|--------|
+| CA-01    | (descrição curta do CA no PRD) | CT-01, CT-10, CT-20, CT-30 |
+| CA-02    | (descrição curta do CA no PRD) | CT-02, CT-22 |
+
+<!-- LLM-ONLY: Cada CA-XX do PRD deve ter pelo menos um teste correspondente. Esta tabela deve ser preenchida PRIMEIRO — guia toda a estrategia. -->
+
+---
+
+### 14.1 Testes Unitários
+
+<!-- LLM-ONLY: Coluna "Objetivo": Descreva em 1 frase O QUE o teste valida e POR QUE importa. Use o padrao: Verbo + comportamento especifico + condicao. Exemplo: "Verificar que apenas categorias com ativo=1 sao retornadas, ordenadas pelo campo 'ordem'". NAO repita o nome do teste — o objetivo deve dar contexto que o nome sozinho nao da. -->
+
+#### Service: [NomeService] (`arquivo_test.go`)
+
+Mock: [interfaces mockadas]
+
+| CT | Teste | CA | Objetivo | Input | Expected | Mock |
+|----|-------|----|----------|-------|----------|------|
+| CT-01 | TestMetodo_Sucesso | CA-01 | Verificar que [comportamento esperado] quando [condição do cenário] | dados válidos | resultado esperado | repo retorna dados |
+| CT-02 | TestMetodo_ErroValidacao | CA-03 | Verificar que [erro específico] é retornado quando [condição inválida] | dados inválidos | ErrEspecifico | — |
+
+#### Apresentação: [NomeHandler] (`arquivo_test.go`)
+
+Mock: [interfaces mockadas]
+
+| CT | Teste | CA | Objetivo | Input | Expected | Mock |
+|----|-------|----|----------|-------|----------|------|
+| CT-10 | TestHandler_Sucesso | CA-01 | Verificar que handler converte [modelo domínio] para [formato response] corretamente | request válido | response proto | service retorna sucesso |
+
+### 14.2 Testes de Integração
+
+#### [CamadaA + CamadaB] (`arquivo_test.go`)
+
+Setup: [banco in-memory, migrações, fixtures]
+
+| CT | Teste | CA | Objetivo | Fluxo | Validação |
+|----|-------|----|----------|-------|-----------|
+| CT-20 | TestIntegracao_CRUD | CA-01 | Verificar que dados persistidos são recuperados integralmente via [camada] | Create → Get | dados consistentes |
+| CT-22 | TestIntegracao_Unique | CA-02 | Verificar que constraint unique impede duplicação de [campo] | Insert duplicado | erro constraint |
+
+### 14.3 Testes End-to-End (E2E)
+
+#### Fluxo: [Nome do Fluxo Crítico] (CT-30)
+- **CA**: CA-01, CA-03, CA-06
+- **Objetivo**: (1 frase descrevendo o que este fluxo E2E valida de ponta a ponta)
+- **Pré-condições**: (estado inicial do sistema)
+- **Passos**:
+  1. Cliente envia request X
+  2. Sistema processa e retorna Y
+  3. Verificar estado do banco
+- **Validações**: (assertions sobre dados e estado final)
+
+### 14.4 Cenários de Erro
+
+| Cenário | CA | Objetivo | Trigger | Código/Status | Log Esperado |
+|---------|----|----------|---------|---------------|-------------|
+| Dados duplicados | CA-02 | Verificar que [constraint] impede [operação] e retorna erro adequado | Insert duplicado | [erro conflito] | "registro já existe..." |
+| Recurso inexistente | CA-05 | Verificar que acesso a [recurso] inexistente retorna [código] sem expor dados internos | ID não encontrado | [erro not found] | "não encontrado..." |
+
+---
+
+## 15. Arquivos Envolvidos e Ações
+
+### 15.1 Arquivos a Criar
+
+| Arquivo | Descrição | Camada |
+|---------|-----------|--------|
+|         |           |        |
+
+### 15.2 Arquivos a Modificar
+
+| Arquivo | Modificação | Motivo |
+|---------|------------|--------|
+|         |            |        |
+
+### 15.3 Arquivos de Referência (somente leitura)
+
+| Arquivo | Motivo da Consulta |
+|---------|-------------------|
+|         |                   |
+
+<!-- LLM-ONLY: Esta secao economiza tokens e scans durante a implementacao, pois lista exatamente quais arquivos serao impactados. -->
+
+---
+
+## 16. Checklist Final
+
+- [ ] SPEC_TECH cobre todo o PRD
+- [ ] Resumo técnico claro e objetivo (seção 2)
+- [ ] Arquitetura definida com componentes e interações (seção 3)
+- [ ] Estruturas de dados definidas (seção 4)
+- [ ] User Stories mapeadas para definições técnicas (seção 5.1)
+- [ ] Fluxos técnicos descritos com tratamento de erros (seção 6)
+- [ ] Endpoints mapeados com payloads e respostas (seção 7)
+- [ ] Telas e fluxos de frontend/mobile definidos (seção 8)
+- [ ] Banco local/cache especificado se aplicável (seção 9)
+- [ ] Dependências técnicas listadas (seção 10)
+- [ ] Requisitos não funcionais endereçados (seção 11)
+- [ ] Critérios técnicos de aceite definidos (seção 12)
+- [ ] Riscos técnicos identificados com mitigações (seção 13)
+- [ ] Estratégia de testes definida com rastreabilidade CA→testes no topo (seção 14)
+- [ ] Arquivos envolvidos listados — criar, modificar, referência (seção 15)
+- [ ] Pronto para geração das TASKS

package/frameworks/skills/sdd-tech-spec-expert/templates/tech_direction-template.md

@@ -1,23 +1,23 @@
-# TECH DIRECTION (Opcional)
-
-> Direcionamento técnico inicial para a feature. Serve como ponto de partida para o SPEC_TECH, não como decisão final.
-> O Arquiteto (tech-spec-expert) pode complementar, ajustar ou questionar qualquer item aqui.
-
-## Decisões técnicas já tomadas
-- (ex: Usar JWT com refresh token para autenticação)
-- (ex: Criar gateway separado para integração externa)
-
-## Tecnologias/Libs sugeridas
-- (ex: biblioteca X para integração com serviço Y)
-- (ex: framework Z para testes)
-
-## Padrões ou abordagens preferidas
-- (ex: Seguir o pattern Gateway já usado no projeto)
-- (ex: Implementar como CQRS)
-
-## Restrições técnicas
-- (ex: Precisa ser stateless para rodar em k8s)
-- (ex: Não temos message broker disponível)
-
-## Observações
-- (qualquer contexto técnico relevante que o arquiteto deve considerar)
+# TECH DIRECTION (Opcional)
+
+> Direcionamento técnico inicial para a feature. Serve como ponto de partida para o SPEC_TECH, não como decisão final.
+> O Arquiteto (tech-spec-expert) pode complementar, ajustar ou questionar qualquer item aqui.
+
+## Decisões técnicas já tomadas
+- (ex: Usar JWT com refresh token para autenticação)
+- (ex: Criar gateway separado para integração externa)
+
+## Tecnologias/Libs sugeridas
+- (ex: biblioteca X para integração com serviço Y)
+- (ex: framework Z para testes)
+
+## Padrões ou abordagens preferidas
+- (ex: Seguir o pattern Gateway já usado no projeto)
+- (ex: Implementar como CQRS)
+
+## Restrições técnicas
+- (ex: Precisa ser stateless para rodar em k8s)
+- (ex: Não temos message broker disponível)
+
+## Observações
+- (qualquer contexto técnico relevante que o arquiteto deve considerar)