adi_dev_workflow 1.1.1 → 1.3.0

package/frameworks/skills/sdd-task-plan-expert-workspace/iteration-2/eval-3-sem-user-stories/without_skill/outputs/response.md

@@ -1,249 +1,249 @@
-# TASK PLAN -- Cache de Cardapio v1
-
-## 1. Identificacao
-
-| Campo | Valor |
-|-------|-------|
-| **Feature/Projeto** | Cache de Cardapio em Memoria |
-| **Versao** | v1 |
-| **Data** | 2026-03-08 |
-| **SPEC_TECH** | Cache de Cardapio v1 |
-| **Branch base** | user-feature |
-
----
-
-## 2. Observacoes Preliminares
-
-O SPEC_TECH fornecido nao referencia User Stories nem PRD. Consequencias praticas:
-
-- Os criterios de aceite de cada task serao derivados exclusivamente das definicoes tecnicas do SPEC_TECH.
-- Nao ha requisitos funcionais de negocio formalizados (ex: "como garcom, quero ver o cardapio rapidamente"). A motivacao implicita e performance: evitar queries repetidas ao SQLite para leitura do cardapio.
-- **O codebase atual nao possui modulo de Product/Produto.** Apenas o modulo User esta implementado. O SPEC_TECH menciona "ProductService" como ponto de integracao do cache, portanto o modulo Product deve existir antes das tasks de integracao. Este task plan trata isso como pre-requisito explicito.
-
----
-
-## 3. Pre-requisitos
-
-| # | Pre-requisito | Justificativa | Status |
-|---|---------------|---------------|--------|
-| P1 | Modulo Product completo (proto, migration, queries SQLC, repository, service, handler gRPC) | O cache sera integrado ao ProductService que ainda nao existe | Pendente |
-| P2 | Codigo SQLC gerado para produtos (`make sqlc`) | Repository de produtos depende do codigo gerado | Pendente |
-| P3 | Codigo Proto gerado para produtos (`make proto`) | Handler gRPC de produtos depende do codigo gerado | Pendente |
-
-> Tasks 1 e 2 (infraestrutura de cache e config) sao independentes dos pre-requisitos e podem ser iniciadas imediatamente. Tasks 3 a 5 dependem de P1.
-
----
-
-## 4. Tasks
-
-### Task 1 -- Configuracao de cache (config.yaml + struct Config)
-
-**Objetivo:** Tornar o TTL do cache configuravel via `config.yaml` e variaveis de ambiente.
-
-**Arquivos afetados:**
-- `configs/config.yaml` (modificar)
-- `internal/infra/config/config.go` (modificar)
-
-**Subtasks:**
-
-| # | Descricao | Detalhe |
-|---|-----------|---------|
-| 1.1 | Adicionar secao `cache` ao config.yaml | `cache:` com `ttl_seconds: 300` |
-| 1.2 | Adicionar campo `CacheTTLSeconds int` na struct `Config` | Em `internal/infra/config/config.go` |
-| 1.3 | Popular o campo no construtor `NewConfig` | `CacheTTLSeconds: v.GetInt("cache.ttl_seconds")`. Se valor for 0 (nao configurado), aplicar fallback para 300 |
-| 1.4 | Teste unitario | Verificar valor padrao 300, override via YAML e override via env var `APP_CACHE_TTL_SECONDS` |
-
-**Criterios de aceite:**
-- `Config.CacheTTLSeconds` retorna 300 quando a secao `cache` nao esta presente no YAML.
-- Override via YAML e via variavel de ambiente funciona corretamente.
-- Testes passam com `CGO_ENABLED=1 go test ./internal/infra/config/...`.
-
-**Estimativa:** P (pequena)
-
----
-
-### Task 2 -- Pacote de cache generico com sync.Map
-
-**Objetivo:** Criar `internal/infra/cache/` com interface generica e implementacao in-memory com TTL.
-
-**Arquivos a criar:**
-- `internal/infra/cache/cache.go` -- interface e implementacao
-- `internal/infra/cache/cache_test.go` -- testes unitarios
-- `internal/infra/cache/fx.go` -- modulo FX (placeholder)
-
-**Subtasks:**
-
-| # | Descricao | Detalhe |
-|---|-----------|---------|
-| 2.1 | Definir interface `Cache[K comparable, V any]` | Metodos: `Get(key K) (V, bool)`, `Set(key K, value V)`, `Invalidate(key K)`, `InvalidateAll()` |
-| 2.2 | Definir struct interna `cacheEntry[V any]` | Campos: `value V`, `createdAt time.Time` |
-| 2.3 | Implementar `InMemoryCache[K, V]` | Usar `sync.Map` como storage. No `Get`, verificar `time.Since(entry.createdAt) > ttl`; se expirado, deletar e retornar zero value + false |
-| 2.4 | Construtor `NewInMemoryCache[K, V](ttl time.Duration) Cache[K, V]` | Retornar ponteiro para InMemoryCache |
-| 2.5 | Testes unitarios | Cenarios: Get/Set basico, expiracao por TTL (usar TTL de 50ms + time.Sleep), Invalidate chave unica, InvalidateAll, Get de chave inexistente |
-| 2.6 | Modulo FX | Criar `fx.go` com modulo vazio por enquanto; a factory concreta sera adicionada na Task 3 |
-
-**Decisoes tecnicas:**
-- `sync.Map` e thread-safe e otimizado para leitura frequente, adequado para cache de cardapio.
-- Verificacao de TTL e lazy (no `Get`), sem goroutine de limpeza. Aceitavel em v1 para cardapio com poucos itens.
-- Generics do Go 1.24 permitem type safety sem type assertions manuais.
-
-**Criterios de aceite:**
-- Interface `Cache[K, V]` exportada e documentada.
-- `InMemoryCache` implementa todos os metodos da interface.
-- Itens expirados nao sao retornados por `Get`.
-- `Invalidate` remove entrada especifica; `InvalidateAll` limpa tudo.
-- Testes passam, incluindo cenario de expiracao.
-
-**Estimativa:** M (media)
-
----
-
-### Task 3 -- Registro do cache no sistema de DI (Uber FX)
-
-**Objetivo:** Criar factory function para cache de produtos e registrar no grafo de dependencias.
-
-**Arquivos afetados:**
-- `internal/infra/cache/fx.go` (modificar -- criado na Task 2)
-- `internal/infra/di/fx.go` (modificar)
-
-**Subtasks:**
-
-| # | Descricao | Detalhe |
-|---|-----------|---------|
-| 3.1 | Criar factory `NewProductCache` | `func NewProductCache(cfg *config.Config) Cache[string, *repository.Product]` -- converte `cfg.CacheTTLSeconds` para `time.Duration` e chama `NewInMemoryCache` |
-| 3.2 | Registrar provider no modulo FX | `fx.Provide(NewProductCache)` dentro de `cache.Module` |
-| 3.3 | Importar `cache.Module` em `internal/infra/di/fx.go` | Posicionar apos `config.Module` e antes de `repository.Module` |
-| 3.4 | Verificar inicializacao | Rodar `fx.ValidateApp` ou iniciar a aplicacao para confirmar que o grafo resolve sem erros |
-
-**Dependencias:** Task 1, Task 2, Pre-requisito P1 (tipo `repository.Product` deve existir)
-
-**Criterios de aceite:**
-- `cache.Module` registrado em `AppModule()`.
-- Aplicacao inicializa sem erros de resolucao de dependencias.
-- Factory usa o TTL do config (nao hardcoded).
-
-**Estimativa:** P (pequena)
-
----
-
-### Task 4 -- Integracao do cache no ProductService
-
-**Objetivo:** Implementar padrao cache-aside no ProductService: consultar cache antes do repository nas leituras, e invalidar cache nas escritas.
-
-**Arquivos afetados:**
-- `internal/service/product_service.go` (modificar)
-- `internal/service/product_service_test.go` (modificar)
-
-**Subtasks:**
-
-| # | Descricao | Detalhe |
-|---|-----------|---------|
-| 4.1 | Adicionar campo `cache` na struct do service | `cache cache.Cache[string, *repository.Product]` |
-| 4.2 | Atualizar construtor `NewProductService` | Adicionar parametro `cache cache.Cache[string, *repository.Product]` |
-| 4.3 | Implementar cache-aside no `GetProduct` (ou `GetProductByID`) | 1) `cache.Get(id)` -- se hit, logar e retornar. 2) Se miss, `repo.GetByID(id)`, `cache.Set(id, product)`, retornar. |
-| 4.4 | Invalidar cache no `CreateProduct` | Apos criacao no repository com sucesso, **nao popular o cache** (evita inconsistencia com listagens). |
-| 4.5 | Invalidar cache no `UpdateProduct` | `cache.Invalidate(id)` apos update no repository |
-| 4.6 | Invalidar cache no `DeleteProduct` | `cache.Invalidate(id)` apos delete no repository |
-| 4.7 | Adicionar logs de cache | `s.logger.Debug("cache hit para produto", zap.String("id", id))` e `s.logger.Debug("cache miss para produto", zap.String("id", id))` |
-| 4.8 | Testes unitarios com mock de cache | Cenarios: (a) cache hit -- repo nao e chamado, (b) cache miss -- repo e chamado e cache e populado, (c) create/update/delete invalidam cache |
-
-**Dependencias:** Task 3, Pre-requisito P1
-
-**Criterios de aceite:**
-- `GetProduct` retorna do cache em cache hit sem chamar o repository.
-- `GetProduct` busca do repository em cache miss, popula o cache, e retorna.
-- Operacoes de escrita (`Create`, `Update`, `Delete`) invalidam a entrada correspondente.
-- Logs de debug indicam hit/miss.
-- Testes unitarios passam com mocks para cache e repository.
-- Nenhuma regressao nos testes existentes do modulo.
-
-**Estimativa:** M (media)
-
----
-
-### Task 5 -- Testes de integracao e validacao final
-
-**Objetivo:** Validar o comportamento end-to-end do cache, incluindo TTL, concorrencia e ausencia de regressoes.
-
-**Arquivos afetados:**
-- `internal/service/product_service_test.go` (adicionar testes)
-
-**Subtasks:**
-
-| # | Descricao | Detalhe |
-|---|-----------|---------|
-| 5.1 | Teste de fluxo completo | Create -> Get (miss, popula) -> Get (hit) -> Update (invalida) -> Get (miss novamente) |
-| 5.2 | Teste de expiracao por TTL | Set com TTL curto (100ms) -> Get (hit) -> Sleep(150ms) -> Get (miss) |
-| 5.3 | Teste de concorrencia (race detection) | Multiplas goroutines fazendo Get/Set simultaneo; rodar com `-race` |
-| 5.4 | Rodar suite completa | `make test` -- todos os testes do projeto devem passar |
-| 5.5 | Validar build | `make build` deve compilar sem erros |
-
-**Dependencias:** Tasks 1 a 4 completas
-
-**Criterios de aceite:**
-- Todos os cenarios de teste passam.
-- `CGO_ENABLED=1 go test -race ./internal/...` nao detecta race conditions.
-- `make build` e `make test` passam sem erros.
-
-**Estimativa:** M (media)
-
----
-
-## 5. Grafo de Dependencias
-
-```
-Task 1 (Config) ─────┐
-                      ├──> Task 3 (DI) ──> Task 4 (Service) ──> Task 5 (Validacao)
-Task 2 (Cache pkg) ──┘
-```
-
-- **Paralelizaveis:** Tasks 1 e 2 (sem dependencia entre si).
-- **Sequenciais:** Task 3 depende de 1 + 2. Task 4 depende de 3. Task 5 depende de 4.
-- **Bloqueio externo:** Tasks 3, 4 e 5 dependem do pre-requisito P1 (modulo Product).
-
----
-
-## 6. Resumo de Estimativas
-
-| Task | Descricao | Estimativa | Dependencias |
-|------|-----------|------------|--------------|
-| 1 | Config de cache | P (pequena) | Nenhuma |
-| 2 | Pacote cache generico | M (media) | Nenhuma |
-| 3 | Registro no FX (DI) | P (pequena) | Tasks 1, 2 + P1 |
-| 4 | Integracao no ProductService | M (media) | Task 3 + P1 |
-| 5 | Testes e validacao | M (media) | Task 4 |
-
-**Esforco total estimado:** 1.5 a 2 dias de desenvolvimento (assumindo P1 ja resolvido).
-
----
-
-## 7. Riscos e Mitigacoes
-
-| # | Risco | Impacto | Mitigacao |
-|---|-------|---------|-----------|
-| R1 | Modulo Product nao existe -- bloqueia Tasks 3-5 | Alto | Tasks 1 e 2 sao independentes e podem avancar. Priorizar implementacao do modulo Product. |
-| R2 | `sync.Map` usa `any` internamente, exigindo type assertions | Baixo | Wrapper generico (`InMemoryCache[K, V]`) encapsula as assertions. Testes garantem type safety. |
-| R3 | Lazy expiration pode acumular entradas expiradas em memoria | Baixo | Cardapio tem poucos itens (dezenas). Aceitavel em v1. Considerar cleanup periodico em v2. |
-| R4 | Dados stale em escrita concorrente (ex: dois updates simultaneos) | Baixo | Invalidacao sincrona no fluxo de escrita. TTL de 300s garante convergencia eventual. |
-| R5 | Ausencia de metricas (hit rate, tamanho do cache) | Baixo | Fora de escopo em v1. Logs de debug permitem analise manual. Considerar metricas em v2. |
-| R6 | Sem PRD/User Stories -- criterios de aceite podem nao cobrir expectativas do negocio | Medio | Criterios derivados do SPEC_TECH. Validar com stakeholders se ha requisitos funcionais adicionais. |
-
----
-
-## 8. Arquivos Criados e Modificados
-
-### Novos arquivos:
-| Arquivo | Task |
-|---------|------|
-| `internal/infra/cache/cache.go` | Task 2 |
-| `internal/infra/cache/cache_test.go` | Task 2 |
-| `internal/infra/cache/fx.go` | Tasks 2, 3 |
-
-### Arquivos modificados:
-| Arquivo | Task | Alteracao |
-|---------|------|-----------|
-| `configs/config.yaml` | Task 1 | Adicionar secao `cache` |
-| `internal/infra/config/config.go` | Task 1 | Adicionar campo `CacheTTLSeconds` |
-| `internal/infra/di/fx.go` | Task 3 | Importar e registrar `cache.Module` |
-| `internal/service/product_service.go` | Task 4 | Adicionar dependencia de cache e logica cache-aside |
-| `internal/service/product_service_test.go` | Tasks 4, 5 | Testes de cache hit/miss, TTL, concorrencia |
+# TASK PLAN -- Cache de Cardapio v1
+
+## 1. Identificacao
+
+| Campo | Valor |
+|-------|-------|
+| **Feature/Projeto** | Cache de Cardapio em Memoria |
+| **Versao** | v1 |
+| **Data** | 2026-03-08 |
+| **SPEC_TECH** | Cache de Cardapio v1 |
+| **Branch base** | user-feature |
+
+---
+
+## 2. Observacoes Preliminares
+
+O SPEC_TECH fornecido nao referencia User Stories nem PRD. Consequencias praticas:
+
+- Os criterios de aceite de cada task serao derivados exclusivamente das definicoes tecnicas do SPEC_TECH.
+- Nao ha requisitos funcionais de negocio formalizados (ex: "como garcom, quero ver o cardapio rapidamente"). A motivacao implicita e performance: evitar queries repetidas ao SQLite para leitura do cardapio.
+- **O codebase atual nao possui modulo de Product/Produto.** Apenas o modulo User esta implementado. O SPEC_TECH menciona "ProductService" como ponto de integracao do cache, portanto o modulo Product deve existir antes das tasks de integracao. Este task plan trata isso como pre-requisito explicito.
+
+---
+
+## 3. Pre-requisitos
+
+| # | Pre-requisito | Justificativa | Status |
+|---|---------------|---------------|--------|
+| P1 | Modulo Product completo (proto, migration, queries SQLC, repository, service, handler gRPC) | O cache sera integrado ao ProductService que ainda nao existe | Pendente |
+| P2 | Codigo SQLC gerado para produtos (`make sqlc`) | Repository de produtos depende do codigo gerado | Pendente |
+| P3 | Codigo Proto gerado para produtos (`make proto`) | Handler gRPC de produtos depende do codigo gerado | Pendente |
+
+> Tasks 1 e 2 (infraestrutura de cache e config) sao independentes dos pre-requisitos e podem ser iniciadas imediatamente. Tasks 3 a 5 dependem de P1.
+
+---
+
+## 4. Tasks
+
+### Task 1 -- Configuracao de cache (config.yaml + struct Config)
+
+**Objetivo:** Tornar o TTL do cache configuravel via `config.yaml` e variaveis de ambiente.
+
+**Arquivos afetados:**
+- `configs/config.yaml` (modificar)
+- `internal/infra/config/config.go` (modificar)
+
+**Subtasks:**
+
+| # | Descricao | Detalhe |
+|---|-----------|---------|
+| 1.1 | Adicionar secao `cache` ao config.yaml | `cache:` com `ttl_seconds: 300` |
+| 1.2 | Adicionar campo `CacheTTLSeconds int` na struct `Config` | Em `internal/infra/config/config.go` |
+| 1.3 | Popular o campo no construtor `NewConfig` | `CacheTTLSeconds: v.GetInt("cache.ttl_seconds")`. Se valor for 0 (nao configurado), aplicar fallback para 300 |
+| 1.4 | Teste unitario | Verificar valor padrao 300, override via YAML e override via env var `APP_CACHE_TTL_SECONDS` |
+
+**Criterios de aceite:**
+- `Config.CacheTTLSeconds` retorna 300 quando a secao `cache` nao esta presente no YAML.
+- Override via YAML e via variavel de ambiente funciona corretamente.
+- Testes passam com `CGO_ENABLED=1 go test ./internal/infra/config/...`.
+
+**Estimativa:** P (pequena)
+
+---
+
+### Task 2 -- Pacote de cache generico com sync.Map
+
+**Objetivo:** Criar `internal/infra/cache/` com interface generica e implementacao in-memory com TTL.
+
+**Arquivos a criar:**
+- `internal/infra/cache/cache.go` -- interface e implementacao
+- `internal/infra/cache/cache_test.go` -- testes unitarios
+- `internal/infra/cache/fx.go` -- modulo FX (placeholder)
+
+**Subtasks:**
+
+| # | Descricao | Detalhe |
+|---|-----------|---------|
+| 2.1 | Definir interface `Cache[K comparable, V any]` | Metodos: `Get(key K) (V, bool)`, `Set(key K, value V)`, `Invalidate(key K)`, `InvalidateAll()` |
+| 2.2 | Definir struct interna `cacheEntry[V any]` | Campos: `value V`, `createdAt time.Time` |
+| 2.3 | Implementar `InMemoryCache[K, V]` | Usar `sync.Map` como storage. No `Get`, verificar `time.Since(entry.createdAt) > ttl`; se expirado, deletar e retornar zero value + false |
+| 2.4 | Construtor `NewInMemoryCache[K, V](ttl time.Duration) Cache[K, V]` | Retornar ponteiro para InMemoryCache |
+| 2.5 | Testes unitarios | Cenarios: Get/Set basico, expiracao por TTL (usar TTL de 50ms + time.Sleep), Invalidate chave unica, InvalidateAll, Get de chave inexistente |
+| 2.6 | Modulo FX | Criar `fx.go` com modulo vazio por enquanto; a factory concreta sera adicionada na Task 3 |
+
+**Decisoes tecnicas:**
+- `sync.Map` e thread-safe e otimizado para leitura frequente, adequado para cache de cardapio.
+- Verificacao de TTL e lazy (no `Get`), sem goroutine de limpeza. Aceitavel em v1 para cardapio com poucos itens.
+- Generics do Go 1.24 permitem type safety sem type assertions manuais.
+
+**Criterios de aceite:**
+- Interface `Cache[K, V]` exportada e documentada.
+- `InMemoryCache` implementa todos os metodos da interface.
+- Itens expirados nao sao retornados por `Get`.
+- `Invalidate` remove entrada especifica; `InvalidateAll` limpa tudo.
+- Testes passam, incluindo cenario de expiracao.
+
+**Estimativa:** M (media)
+
+---
+
+### Task 3 -- Registro do cache no sistema de DI (Uber FX)
+
+**Objetivo:** Criar factory function para cache de produtos e registrar no grafo de dependencias.
+
+**Arquivos afetados:**
+- `internal/infra/cache/fx.go` (modificar -- criado na Task 2)
+- `internal/infra/di/fx.go` (modificar)
+
+**Subtasks:**
+
+| # | Descricao | Detalhe |
+|---|-----------|---------|
+| 3.1 | Criar factory `NewProductCache` | `func NewProductCache(cfg *config.Config) Cache[string, *repository.Product]` -- converte `cfg.CacheTTLSeconds` para `time.Duration` e chama `NewInMemoryCache` |
+| 3.2 | Registrar provider no modulo FX | `fx.Provide(NewProductCache)` dentro de `cache.Module` |
+| 3.3 | Importar `cache.Module` em `internal/infra/di/fx.go` | Posicionar apos `config.Module` e antes de `repository.Module` |
+| 3.4 | Verificar inicializacao | Rodar `fx.ValidateApp` ou iniciar a aplicacao para confirmar que o grafo resolve sem erros |
+
+**Dependencias:** Task 1, Task 2, Pre-requisito P1 (tipo `repository.Product` deve existir)
+
+**Criterios de aceite:**
+- `cache.Module` registrado em `AppModule()`.
+- Aplicacao inicializa sem erros de resolucao de dependencias.
+- Factory usa o TTL do config (nao hardcoded).
+
+**Estimativa:** P (pequena)
+
+---
+
+### Task 4 -- Integracao do cache no ProductService
+
+**Objetivo:** Implementar padrao cache-aside no ProductService: consultar cache antes do repository nas leituras, e invalidar cache nas escritas.
+
+**Arquivos afetados:**
+- `internal/service/product_service.go` (modificar)
+- `internal/service/product_service_test.go` (modificar)
+
+**Subtasks:**
+
+| # | Descricao | Detalhe |
+|---|-----------|---------|
+| 4.1 | Adicionar campo `cache` na struct do service | `cache cache.Cache[string, *repository.Product]` |
+| 4.2 | Atualizar construtor `NewProductService` | Adicionar parametro `cache cache.Cache[string, *repository.Product]` |
+| 4.3 | Implementar cache-aside no `GetProduct` (ou `GetProductByID`) | 1) `cache.Get(id)` -- se hit, logar e retornar. 2) Se miss, `repo.GetByID(id)`, `cache.Set(id, product)`, retornar. |
+| 4.4 | Invalidar cache no `CreateProduct` | Apos criacao no repository com sucesso, **nao popular o cache** (evita inconsistencia com listagens). |
+| 4.5 | Invalidar cache no `UpdateProduct` | `cache.Invalidate(id)` apos update no repository |
+| 4.6 | Invalidar cache no `DeleteProduct` | `cache.Invalidate(id)` apos delete no repository |
+| 4.7 | Adicionar logs de cache | `s.logger.Debug("cache hit para produto", zap.String("id", id))` e `s.logger.Debug("cache miss para produto", zap.String("id", id))` |
+| 4.8 | Testes unitarios com mock de cache | Cenarios: (a) cache hit -- repo nao e chamado, (b) cache miss -- repo e chamado e cache e populado, (c) create/update/delete invalidam cache |
+
+**Dependencias:** Task 3, Pre-requisito P1
+
+**Criterios de aceite:**
+- `GetProduct` retorna do cache em cache hit sem chamar o repository.
+- `GetProduct` busca do repository em cache miss, popula o cache, e retorna.
+- Operacoes de escrita (`Create`, `Update`, `Delete`) invalidam a entrada correspondente.
+- Logs de debug indicam hit/miss.
+- Testes unitarios passam com mocks para cache e repository.
+- Nenhuma regressao nos testes existentes do modulo.
+
+**Estimativa:** M (media)
+
+---
+
+### Task 5 -- Testes de integracao e validacao final
+
+**Objetivo:** Validar o comportamento end-to-end do cache, incluindo TTL, concorrencia e ausencia de regressoes.
+
+**Arquivos afetados:**
+- `internal/service/product_service_test.go` (adicionar testes)
+
+**Subtasks:**
+
+| # | Descricao | Detalhe |
+|---|-----------|---------|
+| 5.1 | Teste de fluxo completo | Create -> Get (miss, popula) -> Get (hit) -> Update (invalida) -> Get (miss novamente) |
+| 5.2 | Teste de expiracao por TTL | Set com TTL curto (100ms) -> Get (hit) -> Sleep(150ms) -> Get (miss) |
+| 5.3 | Teste de concorrencia (race detection) | Multiplas goroutines fazendo Get/Set simultaneo; rodar com `-race` |
+| 5.4 | Rodar suite completa | `make test` -- todos os testes do projeto devem passar |
+| 5.5 | Validar build | `make build` deve compilar sem erros |
+
+**Dependencias:** Tasks 1 a 4 completas
+
+**Criterios de aceite:**
+- Todos os cenarios de teste passam.
+- `CGO_ENABLED=1 go test -race ./internal/...` nao detecta race conditions.
+- `make build` e `make test` passam sem erros.
+
+**Estimativa:** M (media)
+
+---
+
+## 5. Grafo de Dependencias
+
+```
+Task 1 (Config) ─────┐
+                      ├──> Task 3 (DI) ──> Task 4 (Service) ──> Task 5 (Validacao)
+Task 2 (Cache pkg) ──┘
+```
+
+- **Paralelizaveis:** Tasks 1 e 2 (sem dependencia entre si).
+- **Sequenciais:** Task 3 depende de 1 + 2. Task 4 depende de 3. Task 5 depende de 4.
+- **Bloqueio externo:** Tasks 3, 4 e 5 dependem do pre-requisito P1 (modulo Product).
+
+---
+
+## 6. Resumo de Estimativas
+
+| Task | Descricao | Estimativa | Dependencias |
+|------|-----------|------------|--------------|
+| 1 | Config de cache | P (pequena) | Nenhuma |
+| 2 | Pacote cache generico | M (media) | Nenhuma |
+| 3 | Registro no FX (DI) | P (pequena) | Tasks 1, 2 + P1 |
+| 4 | Integracao no ProductService | M (media) | Task 3 + P1 |
+| 5 | Testes e validacao | M (media) | Task 4 |
+
+**Esforco total estimado:** 1.5 a 2 dias de desenvolvimento (assumindo P1 ja resolvido).
+
+---
+
+## 7. Riscos e Mitigacoes
+
+| # | Risco | Impacto | Mitigacao |
+|---|-------|---------|-----------|
+| R1 | Modulo Product nao existe -- bloqueia Tasks 3-5 | Alto | Tasks 1 e 2 sao independentes e podem avancar. Priorizar implementacao do modulo Product. |
+| R2 | `sync.Map` usa `any` internamente, exigindo type assertions | Baixo | Wrapper generico (`InMemoryCache[K, V]`) encapsula as assertions. Testes garantem type safety. |
+| R3 | Lazy expiration pode acumular entradas expiradas em memoria | Baixo | Cardapio tem poucos itens (dezenas). Aceitavel em v1. Considerar cleanup periodico em v2. |
+| R4 | Dados stale em escrita concorrente (ex: dois updates simultaneos) | Baixo | Invalidacao sincrona no fluxo de escrita. TTL de 300s garante convergencia eventual. |
+| R5 | Ausencia de metricas (hit rate, tamanho do cache) | Baixo | Fora de escopo em v1. Logs de debug permitem analise manual. Considerar metricas em v2. |
+| R6 | Sem PRD/User Stories -- criterios de aceite podem nao cobrir expectativas do negocio | Medio | Criterios derivados do SPEC_TECH. Validar com stakeholders se ha requisitos funcionais adicionais. |
+
+---
+
+## 8. Arquivos Criados e Modificados
+
+### Novos arquivos:
+| Arquivo | Task |
+|---------|------|
+| `internal/infra/cache/cache.go` | Task 2 |
+| `internal/infra/cache/cache_test.go` | Task 2 |
+| `internal/infra/cache/fx.go` | Tasks 2, 3 |
+
+### Arquivos modificados:
+| Arquivo | Task | Alteracao |
+|---------|------|-----------|
+| `configs/config.yaml` | Task 1 | Adicionar secao `cache` |
+| `internal/infra/config/config.go` | Task 1 | Adicionar campo `CacheTTLSeconds` |
+| `internal/infra/di/fx.go` | Task 3 | Importar e registrar `cache.Module` |
+| `internal/service/product_service.go` | Task 4 | Adicionar dependencia de cache e logica cache-aside |
+| `internal/service/product_service_test.go` | Tasks 4, 5 | Testes de cache hit/miss, TTL, concorrencia |