adi_dev_workflow 1.1.1 → 1.3.0

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

@@ -1,248 +1,248 @@
-# TASK PLAN -- Cache de Cardapio v1
-
-## 1. Identificacao
-
-| Campo              | Valor                          |
-|--------------------|--------------------------------|
-| **Feature/Projeto** | Cache de Cardapio em Memoria  |
-| **Versao**          | v1                            |
-| **Data**            | 2026-03-07                    |
-| **SPEC_TECH**       | Cache de Cardapio v1          |
-| **Branch base**     | user-feature                  |
-
----
-
-## 2. Observacoes Preliminares
-
-O SPEC_TECH nao referencia User Stories nem PRD. Isso implica que:
-- Nao ha criterios de aceitacao formais vindos de um PRD.
-- Os criterios de aceitacao serao derivados diretamente das definicoes tecnicas do SPEC_TECH.
-- Nao ha modulo de Product/Produto implementado no codebase atual. A API possui apenas o modulo User. Portanto, **antes de implementar o cache do cardapio, e necessario que o modulo Product (repository, service, handler, proto, migrations, queries SQLC) ja exista**. Este task plan assume que o modulo Product sera implementado como pre-requisito ou em paralelo.
-
----
-
-## 3. Pre-requisitos
-
-Antes de iniciar as tasks deste plano, os seguintes itens devem estar prontos:
-
-| # | Pre-requisito | Status |
-|---|---------------|--------|
-| P1 | Modulo Product completo (proto, migration, queries SQLC, repository, service, handler) | Pendente -- nao existe no codebase |
-| P2 | Queries SQLC para produtos geradas (`make sqlc`) | Pendente |
-| P3 | Proto de produto gerado (`make proto`) | Pendente |
-
-> **Nota:** Se o modulo Product nao existir, as Tasks 4 e 5 nao podem ser implementadas. As Tasks 1-3 (infraestrutura de cache) sao independentes e podem ser feitas antes.
-
----
-
-## 4. Tasks
-
-### Task 1 -- Adicionar configuracao de cache ao config.yaml e struct Config
-
-**Objetivo:** Expor o campo `cache.ttl_seconds` na configuracao da aplicacao.
-
-**Arquivos afetados:**
-- `configs/config.yaml`
-- `internal/infra/config/config.go`
-- `internal/infra/config/config_test.go`
-
-**Subtasks:**
-
-| # | Descricao | Detalhe |
-|---|-----------|---------|
-| 1.1 | Adicionar secao `cache` ao `configs/config.yaml` | Adicionar `cache.ttl_seconds: 300` (valor padrao) |
-| 1.2 | Adicionar campo `CacheTTLSeconds int` na struct `Config` | Em `internal/infra/config/config.go` |
-| 1.3 | Popular o campo via Viper | `v.GetInt("cache.ttl_seconds")` com fallback para 300 se nao configurado |
-| 1.4 | Adicionar teste unitario | Verificar que o valor padrao e 300 e que override via env (`APP_CACHE_TTL_SECONDS`) funciona |
-
-**Criterios de aceite:**
-- `Config.CacheTTLSeconds` retorna 300 quando nao configurado.
-- `Config.CacheTTLSeconds` respeita valor do YAML e override via variavel de ambiente.
-- Testes passam.
-
-**Estimativa:** P (pequena)
-
----
-
-### Task 2 -- Criar pacote de cache generico
-
-**Objetivo:** Implementar `internal/infra/cache/` com interface generica `Cache[K, V]` e implementacao `InMemoryCache` usando `sync.Map`.
-
-**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
-
-**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 | Implementar `InMemoryCache[K, V]` | Usar `sync.Map` internamente. Cada entrada armazena o valor e o timestamp de insercao. No `Get`, verificar se `time.Since(timestamp) > ttl`; se sim, deletar e retornar `false`. |
-| 2.3 | Construtor `NewInMemoryCache[K, V](ttl time.Duration) *InMemoryCache[K, V]` | Recebe TTL como parametro |
-| 2.4 | Escrever testes unitarios | Testar: Get/Set basico, expiricao por TTL, Invalidate de chave unica, InvalidateAll |
-| 2.5 | Criar modulo FX (`fx.go`) | Nao registrar provider generico diretamente -- o modulo FX servira como ponto de importacao. A instanciacao concreta sera feita no service ou via factory (ver Task 4). |
-
-**Decisoes tecnicas:**
-- `sync.Map` e thread-safe e adequado para cenarios read-heavy (cache de cardapio).
-- Cada entry no map sera um struct `cacheEntry[V]{ value V, createdAt time.Time }`.
-- A verificacao de TTL e lazy (no momento do `Get`), sem goroutine de limpeza periodica em v1.
-
-**Criterios de aceite:**
-- Interface `Cache[K, V]` definida e exportada.
-- `InMemoryCache` implementa a interface corretamente.
-- TTL e respeitado: itens expirados nao sao retornados por `Get`.
-- `Invalidate` remove entrada especifica; `InvalidateAll` limpa todo o cache.
-- Testes passam com cobertura dos cenarios listados.
-
-**Estimativa:** M (media)
-
----
-
-### Task 3 -- Registrar modulo cache no FX (DI)
-
-**Objetivo:** Integrar o modulo de cache na composicao de dependencias da aplicacao.
-
-**Arquivos afetados:**
-- `internal/infra/di/fx.go`
-- `internal/infra/cache/fx.go` (criado na Task 2)
-
-**Subtasks:**
-
-| # | Descricao | Detalhe |
-|---|-----------|---------|
-| 3.1 | Criar factory function para cache de produtos | `NewProductCache(cfg *config.Config) *InMemoryCache[string, *repository.Product]` -- usa `cfg.CacheTTLSeconds` para definir o TTL |
-| 3.2 | Registrar no modulo FX do cache | `fx.Provide(NewProductCache)` |
-| 3.3 | Adicionar `cache.Module` ao `AppModule()` em `internal/infra/di/fx.go` | Posicionar entre `config.Module` e `repository.Module` na lista de modulos |
-| 3.4 | Atualizar teste de DI | Verificar que `fx.ValidateApp` passa com o novo modulo |
-
-**Dependencias:** Task 1 (config), Task 2 (pacote cache), Pre-requisito P1 (modulo Product -- para o tipo `repository.Product`)
-
-**Criterios de aceite:**
-- `cache.Module` esta registrado em `AppModule()`.
-- Aplicacao inicializa sem erros com o novo modulo.
-- Teste de validacao FX passa.
-
-**Estimativa:** P (pequena)
-
----
-
-### Task 4 -- Integrar cache no ProductService
-
-**Objetivo:** Modificar o `ProductService` para consultar cache antes do repository, e invalidar cache em operacoes de escrita.
-
-**Arquivos afetados:**
-- `internal/service/product_service.go` (a ser criado no pre-requisito ou modificado se ja existir)
-- `internal/service/product_service_test.go`
-
-**Subtasks:**
-
-| # | Descricao | Detalhe |
-|---|-----------|---------|
-| 4.1 | Adicionar dependencia de cache ao `productService` | Novo campo `cache cache.Cache[string, *repository.Product]` na struct |
-| 4.2 | Atualizar construtor `NewProductService` | Receber `*InMemoryCache[string, *repository.Product]` como parametro |
-| 4.3 | Implementar cache-aside no `GetProduct` | 1) Consultar `cache.Get(id)`. 2) Se hit, retornar direto. 3) Se miss, buscar no repository, chamar `cache.Set(id, product)`, retornar. |
-| 4.4 | Invalidar cache em `CreateProduct` | Apos insert no repository, chamar `cache.Invalidate(id)` (ou nao popular para evitar inconsistencia) |
-| 4.5 | Invalidar cache em `UpdateProduct` | Apos update no repository, chamar `cache.Invalidate(id)` |
-| 4.6 | Invalidar cache em `DeleteProduct` | Apos delete no repository, chamar `cache.Invalidate(id)` |
-| 4.7 | Adicionar logs de cache hit/miss | `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 | Escrever testes unitarios | Testar: cache hit retorna sem chamar repo, cache miss chama repo e popula cache, create/update/delete invalidam cache |
-
-**Dependencias:** Task 2 (pacote cache), Task 3 (DI), Pre-requisito P1 (modulo Product)
-
-**Criterios de aceite:**
-- `GetProduct` retorna do cache quando disponivel (sem query ao banco).
-- `GetProduct` busca do repository em cache miss e popula o cache.
-- `CreateProduct`, `UpdateProduct`, `DeleteProduct` invalidam a entrada correspondente no cache.
-- Logs de debug indicam hit/miss.
-- Testes unitarios com mock de cache e mock de repository passam.
-- Nenhuma regressao nos testes existentes.
-
-**Estimativa:** M (media)
-
----
-
-### Task 5 -- Testes de integracao e validacao final
-
-**Objetivo:** Garantir que o fluxo completo funciona end-to-end e que o cache se comporta corretamente sob uso real.
-
-**Arquivos afetados:**
-- `internal/service/product_service_test.go` (testes adicionais)
-
-**Subtasks:**
-
-| # | Descricao | Detalhe |
-|---|-----------|---------|
-| 5.1 | Teste de cenario completo | Criar produto -> Get (cache miss, popula) -> Get novamente (cache hit) -> Update (invalida) -> Get (cache miss novamente) |
-| 5.2 | Teste de expiracao por TTL | Criar produto -> Get (popula cache com TTL curto) -> esperar expiracao -> Get (cache miss) |
-| 5.3 | Teste de concorrencia | Multiplas goroutines fazendo Get simultaneo no mesmo produto -- garantir que nao ha race condition |
-| 5.4 | Rodar `make test` completo | Garantir que nenhum teste existente quebrou |
-| 5.5 | Rodar `make build` | Garantir que a compilacao passa |
-
-**Dependencias:** Tasks 1-4 completas
-
-**Criterios de aceite:**
-- Todos os cenarios de teste passam.
-- `go test -race ./internal/...` nao detecta race conditions.
-- `make build` e `make test` passam sem erros.
-
-**Estimativa:** M (media)
-
----
-
-## 5. Ordem de Execucao e Dependencias
-
-```
-Task 1 (Config) ─────┐
-                      ├──> Task 3 (DI) ──> Task 4 (Service) ──> Task 5 (Validacao)
-Task 2 (Cache pkg) ──┘
-```
-
-- Tasks 1 e 2 podem ser executadas **em paralelo**.
-- Task 3 depende de Tasks 1 e 2.
-- Task 4 depende de Task 3 e do pre-requisito P1 (modulo Product).
-- Task 5 depende de Task 4.
-
----
-
-## 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.
-
----
-
-## 7. Riscos e Consideracoes
-
-| # | Risco | Mitigacao |
-|---|-------|-----------|
-| R1 | Modulo Product nao existe no codebase -- bloqueia Tasks 3-5 | Implementar modulo Product antes ou em paralelo. Tasks 1-2 sao independentes. |
-| R2 | `sync.Map` nao suporta generics nativamente (usa `any` internamente) | Wrapper tipado com type assertions no `InMemoryCache`. Testes garantem type safety. |
-| R3 | Lazy expiration pode acumular entradas expiradas em memoria | Aceitavel em v1 para um cardapio pequeno. Em v2, considerar goroutine de limpeza periodica. |
-| R4 | Cache pode servir dados stale em cenarios de escrita concorrente | Invalidacao sincrona no mesmo request de escrita mitiga isso. TTL garante convergencia eventual. |
-| R5 | Sem metricas de cache (hit rate, tamanho) | Fora de escopo em v1. Considerar para v2. |
-
----
-
-## 8. Arquivos Criados/Modificados (Resumo)
-
-### Novos arquivos:
-- `internal/infra/cache/cache.go`
-- `internal/infra/cache/cache_test.go`
-- `internal/infra/cache/fx.go`
-
-### Arquivos modificados:
-- `configs/config.yaml` -- adicionar secao `cache`
-- `internal/infra/config/config.go` -- adicionar campo `CacheTTLSeconds`
-- `internal/infra/config/config_test.go` -- testes do novo campo
-- `internal/infra/di/fx.go` -- registrar `cache.Module`
-- `internal/infra/di/fx_test.go` -- atualizar teste de validacao
-- `internal/service/product_service.go` -- integrar cache (requer que o arquivo exista)
-- `internal/service/product_service_test.go` -- testes de cache no service
+# TASK PLAN -- Cache de Cardapio v1
+
+## 1. Identificacao
+
+| Campo              | Valor                          |
+|--------------------|--------------------------------|
+| **Feature/Projeto** | Cache de Cardapio em Memoria  |
+| **Versao**          | v1                            |
+| **Data**            | 2026-03-07                    |
+| **SPEC_TECH**       | Cache de Cardapio v1          |
+| **Branch base**     | user-feature                  |
+
+---
+
+## 2. Observacoes Preliminares
+
+O SPEC_TECH nao referencia User Stories nem PRD. Isso implica que:
+- Nao ha criterios de aceitacao formais vindos de um PRD.
+- Os criterios de aceitacao serao derivados diretamente das definicoes tecnicas do SPEC_TECH.
+- Nao ha modulo de Product/Produto implementado no codebase atual. A API possui apenas o modulo User. Portanto, **antes de implementar o cache do cardapio, e necessario que o modulo Product (repository, service, handler, proto, migrations, queries SQLC) ja exista**. Este task plan assume que o modulo Product sera implementado como pre-requisito ou em paralelo.
+
+---
+
+## 3. Pre-requisitos
+
+Antes de iniciar as tasks deste plano, os seguintes itens devem estar prontos:
+
+| # | Pre-requisito | Status |
+|---|---------------|--------|
+| P1 | Modulo Product completo (proto, migration, queries SQLC, repository, service, handler) | Pendente -- nao existe no codebase |
+| P2 | Queries SQLC para produtos geradas (`make sqlc`) | Pendente |
+| P3 | Proto de produto gerado (`make proto`) | Pendente |
+
+> **Nota:** Se o modulo Product nao existir, as Tasks 4 e 5 nao podem ser implementadas. As Tasks 1-3 (infraestrutura de cache) sao independentes e podem ser feitas antes.
+
+---
+
+## 4. Tasks
+
+### Task 1 -- Adicionar configuracao de cache ao config.yaml e struct Config
+
+**Objetivo:** Expor o campo `cache.ttl_seconds` na configuracao da aplicacao.
+
+**Arquivos afetados:**
+- `configs/config.yaml`
+- `internal/infra/config/config.go`
+- `internal/infra/config/config_test.go`
+
+**Subtasks:**
+
+| # | Descricao | Detalhe |
+|---|-----------|---------|
+| 1.1 | Adicionar secao `cache` ao `configs/config.yaml` | Adicionar `cache.ttl_seconds: 300` (valor padrao) |
+| 1.2 | Adicionar campo `CacheTTLSeconds int` na struct `Config` | Em `internal/infra/config/config.go` |
+| 1.3 | Popular o campo via Viper | `v.GetInt("cache.ttl_seconds")` com fallback para 300 se nao configurado |
+| 1.4 | Adicionar teste unitario | Verificar que o valor padrao e 300 e que override via env (`APP_CACHE_TTL_SECONDS`) funciona |
+
+**Criterios de aceite:**
+- `Config.CacheTTLSeconds` retorna 300 quando nao configurado.
+- `Config.CacheTTLSeconds` respeita valor do YAML e override via variavel de ambiente.
+- Testes passam.
+
+**Estimativa:** P (pequena)
+
+---
+
+### Task 2 -- Criar pacote de cache generico
+
+**Objetivo:** Implementar `internal/infra/cache/` com interface generica `Cache[K, V]` e implementacao `InMemoryCache` usando `sync.Map`.
+
+**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
+
+**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 | Implementar `InMemoryCache[K, V]` | Usar `sync.Map` internamente. Cada entrada armazena o valor e o timestamp de insercao. No `Get`, verificar se `time.Since(timestamp) > ttl`; se sim, deletar e retornar `false`. |
+| 2.3 | Construtor `NewInMemoryCache[K, V](ttl time.Duration) *InMemoryCache[K, V]` | Recebe TTL como parametro |
+| 2.4 | Escrever testes unitarios | Testar: Get/Set basico, expiricao por TTL, Invalidate de chave unica, InvalidateAll |
+| 2.5 | Criar modulo FX (`fx.go`) | Nao registrar provider generico diretamente -- o modulo FX servira como ponto de importacao. A instanciacao concreta sera feita no service ou via factory (ver Task 4). |
+
+**Decisoes tecnicas:**
+- `sync.Map` e thread-safe e adequado para cenarios read-heavy (cache de cardapio).
+- Cada entry no map sera um struct `cacheEntry[V]{ value V, createdAt time.Time }`.
+- A verificacao de TTL e lazy (no momento do `Get`), sem goroutine de limpeza periodica em v1.
+
+**Criterios de aceite:**
+- Interface `Cache[K, V]` definida e exportada.
+- `InMemoryCache` implementa a interface corretamente.
+- TTL e respeitado: itens expirados nao sao retornados por `Get`.
+- `Invalidate` remove entrada especifica; `InvalidateAll` limpa todo o cache.
+- Testes passam com cobertura dos cenarios listados.
+
+**Estimativa:** M (media)
+
+---
+
+### Task 3 -- Registrar modulo cache no FX (DI)
+
+**Objetivo:** Integrar o modulo de cache na composicao de dependencias da aplicacao.
+
+**Arquivos afetados:**
+- `internal/infra/di/fx.go`
+- `internal/infra/cache/fx.go` (criado na Task 2)
+
+**Subtasks:**
+
+| # | Descricao | Detalhe |
+|---|-----------|---------|
+| 3.1 | Criar factory function para cache de produtos | `NewProductCache(cfg *config.Config) *InMemoryCache[string, *repository.Product]` -- usa `cfg.CacheTTLSeconds` para definir o TTL |
+| 3.2 | Registrar no modulo FX do cache | `fx.Provide(NewProductCache)` |
+| 3.3 | Adicionar `cache.Module` ao `AppModule()` em `internal/infra/di/fx.go` | Posicionar entre `config.Module` e `repository.Module` na lista de modulos |
+| 3.4 | Atualizar teste de DI | Verificar que `fx.ValidateApp` passa com o novo modulo |
+
+**Dependencias:** Task 1 (config), Task 2 (pacote cache), Pre-requisito P1 (modulo Product -- para o tipo `repository.Product`)
+
+**Criterios de aceite:**
+- `cache.Module` esta registrado em `AppModule()`.
+- Aplicacao inicializa sem erros com o novo modulo.
+- Teste de validacao FX passa.
+
+**Estimativa:** P (pequena)
+
+---
+
+### Task 4 -- Integrar cache no ProductService
+
+**Objetivo:** Modificar o `ProductService` para consultar cache antes do repository, e invalidar cache em operacoes de escrita.
+
+**Arquivos afetados:**
+- `internal/service/product_service.go` (a ser criado no pre-requisito ou modificado se ja existir)
+- `internal/service/product_service_test.go`
+
+**Subtasks:**
+
+| # | Descricao | Detalhe |
+|---|-----------|---------|
+| 4.1 | Adicionar dependencia de cache ao `productService` | Novo campo `cache cache.Cache[string, *repository.Product]` na struct |
+| 4.2 | Atualizar construtor `NewProductService` | Receber `*InMemoryCache[string, *repository.Product]` como parametro |
+| 4.3 | Implementar cache-aside no `GetProduct` | 1) Consultar `cache.Get(id)`. 2) Se hit, retornar direto. 3) Se miss, buscar no repository, chamar `cache.Set(id, product)`, retornar. |
+| 4.4 | Invalidar cache em `CreateProduct` | Apos insert no repository, chamar `cache.Invalidate(id)` (ou nao popular para evitar inconsistencia) |
+| 4.5 | Invalidar cache em `UpdateProduct` | Apos update no repository, chamar `cache.Invalidate(id)` |
+| 4.6 | Invalidar cache em `DeleteProduct` | Apos delete no repository, chamar `cache.Invalidate(id)` |
+| 4.7 | Adicionar logs de cache hit/miss | `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 | Escrever testes unitarios | Testar: cache hit retorna sem chamar repo, cache miss chama repo e popula cache, create/update/delete invalidam cache |
+
+**Dependencias:** Task 2 (pacote cache), Task 3 (DI), Pre-requisito P1 (modulo Product)
+
+**Criterios de aceite:**
+- `GetProduct` retorna do cache quando disponivel (sem query ao banco).
+- `GetProduct` busca do repository em cache miss e popula o cache.
+- `CreateProduct`, `UpdateProduct`, `DeleteProduct` invalidam a entrada correspondente no cache.
+- Logs de debug indicam hit/miss.
+- Testes unitarios com mock de cache e mock de repository passam.
+- Nenhuma regressao nos testes existentes.
+
+**Estimativa:** M (media)
+
+---
+
+### Task 5 -- Testes de integracao e validacao final
+
+**Objetivo:** Garantir que o fluxo completo funciona end-to-end e que o cache se comporta corretamente sob uso real.
+
+**Arquivos afetados:**
+- `internal/service/product_service_test.go` (testes adicionais)
+
+**Subtasks:**
+
+| # | Descricao | Detalhe |
+|---|-----------|---------|
+| 5.1 | Teste de cenario completo | Criar produto -> Get (cache miss, popula) -> Get novamente (cache hit) -> Update (invalida) -> Get (cache miss novamente) |
+| 5.2 | Teste de expiracao por TTL | Criar produto -> Get (popula cache com TTL curto) -> esperar expiracao -> Get (cache miss) |
+| 5.3 | Teste de concorrencia | Multiplas goroutines fazendo Get simultaneo no mesmo produto -- garantir que nao ha race condition |
+| 5.4 | Rodar `make test` completo | Garantir que nenhum teste existente quebrou |
+| 5.5 | Rodar `make build` | Garantir que a compilacao passa |
+
+**Dependencias:** Tasks 1-4 completas
+
+**Criterios de aceite:**
+- Todos os cenarios de teste passam.
+- `go test -race ./internal/...` nao detecta race conditions.
+- `make build` e `make test` passam sem erros.
+
+**Estimativa:** M (media)
+
+---
+
+## 5. Ordem de Execucao e Dependencias
+
+```
+Task 1 (Config) ─────┐
+                      ├──> Task 3 (DI) ──> Task 4 (Service) ──> Task 5 (Validacao)
+Task 2 (Cache pkg) ──┘
+```
+
+- Tasks 1 e 2 podem ser executadas **em paralelo**.
+- Task 3 depende de Tasks 1 e 2.
+- Task 4 depende de Task 3 e do pre-requisito P1 (modulo Product).
+- Task 5 depende de Task 4.
+
+---
+
+## 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.
+
+---
+
+## 7. Riscos e Consideracoes
+
+| # | Risco | Mitigacao |
+|---|-------|-----------|
+| R1 | Modulo Product nao existe no codebase -- bloqueia Tasks 3-5 | Implementar modulo Product antes ou em paralelo. Tasks 1-2 sao independentes. |
+| R2 | `sync.Map` nao suporta generics nativamente (usa `any` internamente) | Wrapper tipado com type assertions no `InMemoryCache`. Testes garantem type safety. |
+| R3 | Lazy expiration pode acumular entradas expiradas em memoria | Aceitavel em v1 para um cardapio pequeno. Em v2, considerar goroutine de limpeza periodica. |
+| R4 | Cache pode servir dados stale em cenarios de escrita concorrente | Invalidacao sincrona no mesmo request de escrita mitiga isso. TTL garante convergencia eventual. |
+| R5 | Sem metricas de cache (hit rate, tamanho) | Fora de escopo em v1. Considerar para v2. |
+
+---
+
+## 8. Arquivos Criados/Modificados (Resumo)
+
+### Novos arquivos:
+- `internal/infra/cache/cache.go`
+- `internal/infra/cache/cache_test.go`
+- `internal/infra/cache/fx.go`
+
+### Arquivos modificados:
+- `configs/config.yaml` -- adicionar secao `cache`
+- `internal/infra/config/config.go` -- adicionar campo `CacheTTLSeconds`
+- `internal/infra/config/config_test.go` -- testes do novo campo
+- `internal/infra/di/fx.go` -- registrar `cache.Module`
+- `internal/infra/di/fx_test.go` -- atualizar teste de validacao
+- `internal/service/product_service.go` -- integrar cache (requer que o arquivo exista)
+- `internal/service/product_service_test.go` -- testes de cache no service

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

@@ -1,49 +1,49 @@
-# Transcript -- Task Plan Generation (Cache de Cardapio v1, without_skill)
-
-## Ferramentas chamadas
-
-### 1. ToolSearch (select:Bash,Read,Glob,Write)
-- **Motivo:** Carregar ferramentas necessarias para explorar o codebase e gerar os arquivos de saida.
-
-### 2. Glob (3 chamadas em paralelo)
-- `internal/**/*.go` -- Listar todos os arquivos Go do projeto para entender a estrutura.
-- `configs/*.yaml` -- Localizar arquivo de configuracao.
-- `internal/db/migrations/*.sql` -- Listar migracoes existentes.
-
-**Resultado:** Identificou que o projeto possui apenas o modulo User (repository, service, handler). Nao ha modulo Product.
-
-### 3. Read (5 chamadas em paralelo)
-- `configs/config.yaml` -- Entender configuracao atual (grpc, database, jwt, log). Nao ha secao cache.
-- `internal/infra/config/config.go` -- Entender struct Config e como Viper mapeia campos. Campo `CacheTTLSeconds` nao existe.
-- `internal/infra/di/fx.go` -- Entender composicao DI. Modulos: config, logger, database, repository, service, handlers, grpc.
-- `internal/service/user_service.go` -- Entender padrao do service layer (interface + impl privada + modulo FX).
-- `internal/repository/user_repository.go` -- Entender padrao do repository (interface + SQLC + mapeamento pt->en + modulo FX).
-
-### 4. ToolSearch (select:Grep)
-- **Motivo:** Carregar ferramenta de busca para verificar existencia de codigo de Product.
-
-### 5. Grep (product|Product|produto|Produto em arquivos .go)
-- **Resultado:** Nenhuma referencia significativa a Product/Produto no codigo Go. Confirmou que o modulo Product nao existe.
-
-### 6. Read (2 chamadas em paralelo)
-- `internal/infra/grpc/server.go` -- Entender como handlers sao registrados no servidor gRPC.
-- `internal/service/user_service_test.go` -- Entender padrao de testes (table-driven, mocks com testify).
-
-### 7. Bash (mkdir)
-- Criar diretorio de saida: `.claude/skills/sdd-task-plan-expert-workspace/iteration-1/eval-3-sem-user-stories/without_skill/outputs/`
-
-### 8. Write (response.md)
-- Gerar o Task Plan completo com 5 tasks, pre-requisitos, dependencias, riscos e estimativas.
-
-### 9. Write (transcript.md)
-- Gerar este arquivo de transcript.
-
-## Decisoes tomadas
-
-1. **Modulo Product como pre-requisito:** O SPEC_TECH menciona "cardapio de produtos" e "ProductService", mas nenhum codigo de Product existe. Decidi documentar isso como pre-requisito bloqueante (P1) em vez de incluir a criacao do modulo Product inteiro no task plan, pois esta fora do escopo do SPEC_TECH.
-
-2. **Sem User Stories / PRD:** O SPEC_TECH nao referencia User Stories nem PRD. Derivei criterios de aceite diretamente das definicoes tecnicas do SPEC_TECH. Registrei essa observacao na secao 2 do task plan.
-
-3. **Generics em Go:** O SPEC_TECH pede `Cache[K, V]` generico. Go 1.24 suporta generics, entao a interface e implementacao usam type parameters. Porem `sync.Map` usa `any` internamente, entao o wrapper tipado faz type assertions.
-
-4. **Lazy expiration:** Decidi por verificacao de TTL no momento do `Get` (sem goroutine de cleanup), conforme adequado para v1 de um cardapio pequeno.
+# Transcript -- Task Plan Generation (Cache de Cardapio v1, without_skill)
+
+## Ferramentas chamadas
+
+### 1. ToolSearch (select:Bash,Read,Glob,Write)
+- **Motivo:** Carregar ferramentas necessarias para explorar o codebase e gerar os arquivos de saida.
+
+### 2. Glob (3 chamadas em paralelo)
+- `internal/**/*.go` -- Listar todos os arquivos Go do projeto para entender a estrutura.
+- `configs/*.yaml` -- Localizar arquivo de configuracao.
+- `internal/db/migrations/*.sql` -- Listar migracoes existentes.
+
+**Resultado:** Identificou que o projeto possui apenas o modulo User (repository, service, handler). Nao ha modulo Product.
+
+### 3. Read (5 chamadas em paralelo)
+- `configs/config.yaml` -- Entender configuracao atual (grpc, database, jwt, log). Nao ha secao cache.
+- `internal/infra/config/config.go` -- Entender struct Config e como Viper mapeia campos. Campo `CacheTTLSeconds` nao existe.
+- `internal/infra/di/fx.go` -- Entender composicao DI. Modulos: config, logger, database, repository, service, handlers, grpc.
+- `internal/service/user_service.go` -- Entender padrao do service layer (interface + impl privada + modulo FX).
+- `internal/repository/user_repository.go` -- Entender padrao do repository (interface + SQLC + mapeamento pt->en + modulo FX).
+
+### 4. ToolSearch (select:Grep)
+- **Motivo:** Carregar ferramenta de busca para verificar existencia de codigo de Product.
+
+### 5. Grep (product|Product|produto|Produto em arquivos .go)
+- **Resultado:** Nenhuma referencia significativa a Product/Produto no codigo Go. Confirmou que o modulo Product nao existe.
+
+### 6. Read (2 chamadas em paralelo)
+- `internal/infra/grpc/server.go` -- Entender como handlers sao registrados no servidor gRPC.
+- `internal/service/user_service_test.go` -- Entender padrao de testes (table-driven, mocks com testify).
+
+### 7. Bash (mkdir)
+- Criar diretorio de saida: `.claude/skills/sdd-task-plan-expert-workspace/iteration-1/eval-3-sem-user-stories/without_skill/outputs/`
+
+### 8. Write (response.md)
+- Gerar o Task Plan completo com 5 tasks, pre-requisitos, dependencias, riscos e estimativas.
+
+### 9. Write (transcript.md)
+- Gerar este arquivo de transcript.
+
+## Decisoes tomadas
+
+1. **Modulo Product como pre-requisito:** O SPEC_TECH menciona "cardapio de produtos" e "ProductService", mas nenhum codigo de Product existe. Decidi documentar isso como pre-requisito bloqueante (P1) em vez de incluir a criacao do modulo Product inteiro no task plan, pois esta fora do escopo do SPEC_TECH.
+
+2. **Sem User Stories / PRD:** O SPEC_TECH nao referencia User Stories nem PRD. Derivei criterios de aceite diretamente das definicoes tecnicas do SPEC_TECH. Registrei essa observacao na secao 2 do task plan.
+
+3. **Generics em Go:** O SPEC_TECH pede `Cache[K, V]` generico. Go 1.24 suporta generics, entao a interface e implementacao usam type parameters. Porem `sync.Map` usa `any` internamente, entao o wrapper tipado faz type assertions.
+
+4. **Lazy expiration:** Decidi por verificacao de TTL no momento do `Get` (sem goroutine de cleanup), conforme adequado para v1 de um cardapio pequeno.

package/frameworks/skills/sdd-task-plan-expert-workspace/iteration-1/eval-3-sem-user-stories/without_skill/timing.json

@@ -1,5 +1,5 @@
-{
-  "total_tokens": 34322,
-  "duration_ms": 144659,
-  "total_duration_seconds": 144.7
-}
+{
+  "total_tokens": 34322,
+  "duration_ms": 144659,
+  "total_duration_seconds": 144.7
+}