adi_dev_workflow 1.3.0 → 1.4.0

package/frameworks/skills/sdd-task-plan-expert-workspace/iteration-1/eval-2-spec-simples/without_skill/outputs/transcript.md

@@ -1,78 +0,0 @@
-# Transcript — Tool Calls for Task Plan Generation
-
-## Objetivo
-Gerar um TASK PLAN para a feature "Adicionar Telefone ao Usuario v1" baseado no SPEC_TECH aprovado.
-
-## Ferramentas Utilizadas
-
-### 1. ToolSearch — Carregar ferramentas
-- **Query:** `select:Read,Glob,Bash,Write`
-- **Resultado:** 4 ferramentas carregadas com sucesso
-
-### 2. Glob (6 chamadas em paralelo) — Descobrir arquivos relevantes
-- `internal/db/migrations/*.sql` → Encontrou: `001_create_usuarios.sql`
-- `internal/db/queries/*.sql` → Nenhum resultado (caminho incorreto)
-- `internal/repository/user*.go` → Encontrou: `user_repository.go`
-- `internal/service/user*.go` → Encontrou: `user_service.go`, `user_service_test.go`
-- `internal/handler/grpc/user*.go` → Encontrou: `user_handler.go`, `user_handler_test.go`
-- `api/proto/v1/user*.proto` → Encontrou: `user.proto`
-
-### 3. Read (7 chamadas em paralelo) — Ler conteudo dos arquivos
-- `internal/db/migrations/001_create_usuarios.sql` — Schema atual da tabela usuarios
-- `api/proto/v1/user.proto` — Definicao proto atual (CreateUser, GetUser)
-- `internal/repository/user_repository.go` — Repository com modelo User e interface
-- `internal/service/user_service.go` — Service com CreateUserInput e validacoes
-- `internal/handler/grpc/user_handler.go` — Handler gRPC com mapeamento de erros
-- `internal/service/user_service_test.go` — Testes do service (mock + table-driven)
-- `internal/handler/grpc/user_handler_test.go` — Testes do handler
-
-### 4. Glob (3 chamadas em paralelo) — Buscar queries SQLC e config
-- `**/sqlc.yaml` → Encontrou: `internal/db/sqlc/sqlc.yaml`
-- `**/queries/*.sql` → Encontrou: `internal/db/sqlc/queries/user.sql`
-- `**/sqlc/**` → Confirmou estrutura do diretorio
-
-### 5. Read (2 chamadas em paralelo) — Ler queries SQLC e configuracao
-- `internal/db/sqlc/queries/user.sql` — Queries CreateUser e GetUserByID
-- `internal/db/sqlc/sqlc.yaml` — Configuracao SQLC (engine sqlite)
-
-### 6. Glob (3 chamadas em paralelo) — Verificar codigo gerado e FX
-- `gen/**/*.go` → Nenhum resultado (codigo gerado nao commitado)
-- `internal/handler/grpc/fx.go` → Encontrado
-- `internal/infra/grpc/server.go` → Encontrado
-
-### 7. Bash — Listar diretorio SQLC
-- Comando: `ls -la internal/db/sqlc/`
-- Resultado: Apenas `queries/` e `sqlc.yaml` (sem Go gerado)
-
-### 8. Read (2 chamadas em paralelo) — Ler FX e server
-- `internal/handler/grpc/fx.go` — Modulo FX do handler (registra UserServiceServer)
-- `internal/infra/grpc/server.go` — Servidor gRPC (registra UserService, auth interceptor)
-
-### 9. Bash — Verificar diretorio de output
-- Verificou existencia do diretorio workspace
-
-### 10. Bash — Criar diretorio de output
-- Criou `without_skill/outputs/`
-
-### 11. Write — Salvar response.md
-- Task Plan completo com 12 tasks
-
-### 12. Write — Salvar transcript.md
-- Este arquivo
-
-## Resumo de Descobertas
-
-| Aspecto | Situacao Atual |
-|---------|----------------|
-| **Migracao** | 1 arquivo (001), sem down migration |
-| **SQLC queries** | 2 queries (CreateUser, GetUserByID) |
-| **SQLC gerado** | Nao presente no repo (nao commitado) |
-| **Proto** | 2 RPCs (CreateUser, GetUser), sem UpdateUser |
-| **Proto gerado** | Nao presente no repo (nao commitado) |
-| **Repository** | Interface com Create e GetByID, sem Update |
-| **Service** | Interface com CreateUser e GetUser, sem UpdateUser |
-| **Handler** | Implementa CreateUser e GetUser |
-| **Testes service** | 11 testes (validacao, hash, UUID, erros) |
-| **Testes handler** | 12 testes (sucesso, erros, mapeamento) |
-
-Conclusao: A feature requer adicoes em todas as camadas + criacao do endpoint UpdateUser que nao existe.

package/frameworks/skills/sdd-task-plan-expert-workspace/iteration-1/eval-2-spec-simples/without_skill/timing.json

@@ -1,5 +0,0 @@
-{
-  "total_tokens": 41818,
-  "duration_ms": 167600,
-  "total_duration_seconds": 167.6
-}

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

@@ -1,12 +0,0 @@
-{
-  "eval_id": 3,
-  "eval_name": "spec-tech-sem-user-stories-explicitas",
-  "prompt": "Gere o TASK PLAN para esta feature. Segue o SPEC_TECH aprovado:\n\n---\n# SPEC_TECH — Cache de Cardapio v1\n\n## 1. Identificacao\n| Campo | Valor |\n|-------|-------|\n| **Feature/Projeto** | Cache de Cardapio em Memoria |\n| **Versao** | v1 |\n| **Data** | 2026-03-07 |\n\n## 2. Resumo Tecnico\nImplementar cache in-memory (sync.Map) para o cardapio de produtos, evitando queries repetidas ao SQLite. TTL configuravel via config.yaml.\n\n## 3. Definicoes Tecnicas\n\n### 3.1 Novo Pacote\n- `internal/infra/cache/` com interface `Cache[K, V]` e implementacao `InMemoryCache`\n- TTL configuravel via `cache.ttl_seconds` no config.yaml\n- Invalidacao manual via metodo `Invalidate(key)`\n\n### 3.2 Service\n- ProductService passa a consultar cache antes do repository\n- Cache miss: busca no repository e popula cache\n- Operacoes de escrita (Create, Update, Delete) invalidam a entrada correspondente\n\n### 3.3 Config\n- Novo campo `cache.ttl_seconds` (padrao: 300)\n\n### 3.4 DI\n- Registrar modulo cache no FX\n---",
-  "assertions": [
-    {"id": "c1", "text": "Detecta a ausencia de User Stories (US-XX) e PRD referenciado no SPEC_TECH", "type": "llm_judge"},
-    {"id": "c2", "text": "PERGUNTA ao usuario sobre User Stories / PRD em vez de inventar ou ignorar", "type": "llm_judge"},
-    {"id": "c3", "text": "NAO inventa User Stories ficticias (guardrail: nunca invente informacoes)", "type": "llm_judge"},
-    {"id": "c4", "text": "Extrai corretamente o nome da feature como 'cache-de-cardapio' ou similar em kebab-case", "type": "llm_judge"},
-    {"id": "c5", "text": "Segue o processo interativo (uma pergunta por vez, confirma nome antes de prosseguir)", "type": "llm_judge"}
-  ]
-}

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

@@ -1,32 +0,0 @@
-{
-  "eval_id": 3,
-  "eval_name": "spec-tech-sem-user-stories-explicitas",
-  "configuration": "with_skill",
-  "expectations": [
-    {
-      "text": "Detecta a ausencia de User Stories (US-XX) e PRD referenciado no SPEC_TECH",
-      "passed": true,
-      "evidence": "Secao 3 explicita: 'O SPEC_TECH fornecido nao contem User Stories (US-XX) e nao referencia nenhum PRD.' Tambem identificou a dependencia critica do modulo de Produto inexistente."
-    },
-    {
-      "text": "PERGUNTA ao usuario sobre User Stories / PRD em vez de inventar ou ignorar",
-      "passed": true,
-      "evidence": "Formulou pergunta clara com 2 opcoes: (1) usuario fornece PRD/US ou (2) seguir sem, com rastreabilidade N/A. Aguarda resposta antes de avancar."
-    },
-    {
-      "text": "NAO inventa User Stories ficticias (guardrail: nunca invente informacoes)",
-      "passed": true,
-      "evidence": "Nenhuma User Story ficticia foi inventada. A resposta explicitamente identifica a ausencia e pergunta ao usuario."
-    },
-    {
-      "text": "Extrai corretamente o nome da feature como 'cache-de-cardapio' ou similar em kebab-case",
-      "passed": true,
-      "evidence": "Extraiu 'Cache de Cardapio em Memoria' e normalizou para 'cache-de-cardapio' em kebab-case."
-    },
-    {
-      "text": "Segue o processo interativo (uma pergunta por vez, confirma nome antes de prosseguir)",
-      "passed": true,
-      "evidence": "Seguiu sequencia: (1) extraiu nome, (2) perguntou sobre US/PRD ausentes, (3) perguntou sobre dependencia do modulo Produto. Indicou que confirmacao do nome e inicio das fases aguardam respostas anteriores."
-    }
-  ]
-}

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

@@ -1,101 +0,0 @@
-# Resposta do Task Plan Expert — Interacao Inicial
-
-## 1. Extração do Nome da Feature
-
-Identifiquei o nome da feature na secao "1. Identificacao" do SPEC_TECH:
-
-- **Feature/Projeto**: Cache de Cardapio em Memoria
-- **Nome normalizado (kebab-case)**: `cache-de-cardapio`
-- **Versao**: v1
-- **Diretorio de saida**: `docs/cache-de-cardapio/v1/`
-
----
-
-## 2. Analise Obrigatoria do Projeto (Codebase)
-
-Antes de planejar qualquer task, explorei o codebase e identifiquei o seguinte:
-
-### O que JA existe no projeto:
-| Elemento | Status | Localizacao |
-|----------|--------|-------------|
-| Estrutura Clean Architecture (handler/service/repository) | Existe | `internal/` |
-| Injecao de dependencia via Uber FX | Existe | `internal/infra/di/fx.go` |
-| Config via Viper + `config.yaml` | Existe | `internal/infra/config/config.go`, `configs/config.yaml` |
-| User module completo (handler, service, repo, tests) | Existe | `internal/handler/grpc/`, `internal/service/`, `internal/repository/` |
-| SQLC para queries tipadas | Existe | `internal/db/sqlc/` |
-| Migracao de usuarios | Existe | `internal/db/migrations/001_create_usuarios.sql` |
-| Testes com testify/mock (table-driven) | Existe | `internal/service/user_service_test.go` |
-| gRPC server com interceptors | Existe | `internal/infra/grpc/server.go` |
-
-### O que NAO existe (precisa ser criado):
-| Elemento | Status |
-|----------|--------|
-| Modulo de Produto (Product) — service, repository, handler, proto, migration, queries | **NAO existe** |
-| Pacote de cache (`internal/infra/cache/`) | **NAO existe** |
-| Campo `cache.ttl_seconds` no config | **NAO existe** |
-| Tabela `produtos` no banco | **NAO existe** |
-
-### Observacao Critica
-
-O SPEC_TECH fala em "cache de cardapio de produtos" e menciona que o `ProductService` passara a consultar o cache antes do repository. Porem, **nao existe nenhum modulo de Produto no projeto**. Nao ha proto, migration, queries SQLC, repository, service ou handler de produtos.
-
-Isso significa que o TASK PLAN precisara incluir tasks para criar o modulo de Produto completo OU o SPEC_TECH assume que esse modulo ja existe/sera criado em outra feature. Essa duvida sera direcionada ao usuario (veja secao 3).
-
----
-
-## 3. Ponto de Atencao — User Stories e PRD Ausentes
-
-O SPEC_TECH fornecido **nao contem User Stories (US-XX)** e **nao referencia nenhum PRD**.
-
-No framework SDD, o TASK PLAN inclui uma **tabela de rastreabilidade obrigatoria** que mapeia User Stories do PRD para definicoes tecnicas do SPEC_TECH e para tasks correspondentes (Guardrail #8: "Rastreabilidade obrigatoria — toda User Story do PRD deve ter pelo menos uma task correspondente").
-
-**Pergunta que faria ao usuario:**
-
-> O SPEC_TECH fornecido nao contem User Stories (US-XX) e nao referencia um PRD. No framework SDD, a rastreabilidade User Stories -> Tasks e obrigatoria no TASK PLAN.
->
-> Temos duas opcoes:
->
-> 1. **Voce fornece o PRD ou as User Stories** relacionadas a esta feature, e eu incluo a rastreabilidade completa no TASK PLAN.
-> 2. **Seguimos sem PRD/User Stories**, e a secao de rastreabilidade do TASK PLAN sera preenchida com "N/A — SPEC_TECH fornecido sem PRD/User Stories associadas". Neste caso, a rastreabilidade sera feita apenas entre definicoes tecnicas do SPEC e tasks.
->
-> Qual opcao prefere?
-
----
-
-## 4. Ponto de Atencao — Dependencia do Modulo de Produto
-
-Alem da questao de User Stories, identifiquei uma dependencia critica:
-
-**Pergunta que faria ao usuario (apos resposta da pergunta anterior):**
-
-> O SPEC_TECH menciona que o `ProductService` passara a consultar o cache antes do repository, e que operacoes de escrita (Create, Update, Delete) invalidarao entradas do cache. Porem, **nao existe nenhum modulo de Produto no codebase atual** — nao ha proto, migration, queries, repository, service ou handler de produtos.
->
-> Duas opcoes:
->
-> 1. **O escopo deste TASK PLAN inclui a criacao do modulo de Produto completo** (migration, queries SQLC, repository, service, handler gRPC, proto) alem do cache. Isso aumenta significativamente o numero de tasks.
-> 2. **O modulo de Produto sera criado em outra feature/SPEC_TECH**, e este TASK PLAN assume que ele ja existira quando as tasks forem executadas. Neste caso, incluo apenas as tasks de cache + integracao com o ProductService.
->
-> Qual abordagem seguir?
-
----
-
-## 5. Confirmacao do Nome e Inicio
-
-Apos as respostas acima, a proxima interacao seria:
-
-> Obrigado! Vamos iniciar o TASK PLAN para **Cache de Cardapio em Memoria (v1)**. Podemos iniciar a definicao macro das fases?
-
----
-
-## Resumo da Interacao Inicial
-
-| Etapa | Status |
-|-------|--------|
-| Leitura do SPEC_TECH | Concluido |
-| Extracao do nome da feature | Concluido: `cache-de-cardapio` |
-| Analise do codebase | Concluido |
-| Identificacao de User Stories/PRD ausentes | Concluido — pergunta formulada |
-| Identificacao de dependencia critica (modulo Produto) | Concluido — pergunta formulada |
-| Confirmacao do nome e inicio das fases | Aguardando respostas anteriores |
-
-**Proximo passo**: Aguardar respostas do usuario para as duas perguntas acima antes de avancar para a definicao macro das fases.

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

@@ -1,133 +0,0 @@
-# Transcript — Tools Called
-
-## Eval: eval-3-sem-user-stories (with_skill)
-## Data: 2026-03-07
-
----
-
-### 1. Read — Skill file e templates (paralelo)
-
-**Ferramentas chamadas em paralelo:**
-
-1. `Read` — `.claude/skills/sdd-task-plan-expert/SKILL.md`
-   - **Motivo**: Ler as instrucoes completas da skill para seguir o processo definido.
-   - **Resultado**: Skill carregada com sucesso. Contem processo interativo, guardrails, templates, regras de rastreabilidade e estrutura de arquivos.
-
-2. `Read` — `.claude/skills/sdd-task-plan-expert/templates/task_plan_template.md`
-   - **Motivo**: Ler o template do TASK PLAN para saber a estrutura esperada.
-   - **Resultado**: Template contem secoes: Identificacao, Objetivo, Macro-Fases, Lista de Tasks, Rastreabilidade US->Tasks, Dependencias, Criterios de Conclusao, Riscos, Checklist.
-
-3. `Read` — `.claude/skills/sdd-task-plan-expert/templates/task_template.md`
-   - **Motivo**: Ler o template da task individual para saber a estrutura detalhada.
-   - **Resultado**: Template contem secoes: Identificacao, Objetivo, Descricao Detalhada, Aceite Tecnico, Arquivos Impactados, Testes, Notas, Checklist.
-
----
-
-### 2. Glob — Explorar estrutura do codebase (paralelo)
-
-**Ferramentas chamadas em paralelo:**
-
-1. `Glob` — `internal/**/*.go`
-   - **Motivo**: Mapear todos os arquivos Go do projeto para entender a arquitetura existente.
-   - **Resultado**: 17 arquivos encontrados cobrindo handler, service, repository, infra (config, database, di, grpc, logger).
-
-2. `Glob` — `configs/*.yaml`
-   - **Motivo**: Verificar arquivos de configuracao existentes.
-   - **Resultado**: 1 arquivo: `configs/config.yaml`.
-
-3. `Glob` — `internal/db/migrations/*.sql`
-   - **Motivo**: Verificar migracoes existentes.
-   - **Resultado**: 1 arquivo: `001_create_usuarios.sql`.
-
-4. `Glob` — `internal/db/queries/*.sql`
-   - **Motivo**: Verificar queries SQLC existentes.
-   - **Resultado**: Nenhum arquivo encontrado (queries podem estar em outro local ou ainda nao existem como arquivos separados).
-
----
-
-### 3. Read — Arquivos-chave do codebase (paralelo)
-
-**Ferramentas chamadas em paralelo:**
-
-1. `Read` — `configs/config.yaml`
-   - **Motivo**: Verificar estrutura atual da configuracao (onde `cache.ttl_seconds` sera adicionado).
-   - **Resultado**: Config tem campos grpc, database, jwt, log. NAO tem campo cache.
-
-2. `Read` — `internal/infra/config/config.go`
-   - **Motivo**: Verificar struct Config e como novos campos sao adicionados.
-   - **Resultado**: Struct Config com campos GRPCHost, GRPCPort, DatabasePath, JWTSecret, LogLevel. Usa Viper com env prefix APP_.
-
-3. `Read` — `internal/infra/di/fx.go`
-   - **Motivo**: Verificar composicao de modulos FX existente.
-   - **Resultado**: AppModule compoe: config, logger, database, repository, service, grpchandler, grpcserver. NAO tem modulo cache.
-
-4. `Read` — `internal/service/user_service.go`
-   - **Motivo**: Entender padrao de service existente como referencia.
-   - **Resultado**: Padrao: interface publica, struct privada, construtor, modulo FX inline.
-
-5. `Read` — `internal/repository/user_repository.go`
-   - **Motivo**: Entender padrao de repository existente como referencia.
-   - **Resultado**: Padrao: struct de dominio, interface, implementacao com SQLC, mapeamento PT->EN, modulo FX.
-
-6. `Read` — `internal/infra/grpc/server.go`
-   - **Motivo**: Entender como handlers sao registrados no server gRPC.
-   - **Resultado**: Server recebe handlers via FX params, registra com `pb.RegisterXxxServiceServer`.
-
----
-
-### 4. Grep — Verificar existencia de modulo Produto e cache (paralelo)
-
-**Ferramentas chamadas em paralelo:**
-
-1. `Grep` — pattern `product|produto|cardapio|cache` em `*.go`
-   - **Motivo**: Verificar se existe qualquer codigo relacionado a produto ou cache.
-   - **Resultado**: Apenas 1 match em logger.go (falso positivo). NAO existe modulo de produto nem cache.
-
-2. `Grep` — pattern `product|produto|cardapio` em `*.proto`
-   - **Motivo**: Verificar se existe proto de produto.
-   - **Resultado**: Nenhum match. NAO existe proto de produto.
-
-3. `Glob` — `internal/infra/cache/**/*`
-   - **Motivo**: Verificar se pacote cache ja existe.
-   - **Resultado**: Nenhum arquivo. Pacote NAO existe.
-
-4. `Read` — `internal/service/user_service_test.go`
-   - **Motivo**: Entender padrao de testes existente (framework, mocks, table-driven).
-   - **Resultado**: Usa testify/mock, table-driven tests, MockUserRepository inline, assertNotCalled, assertNumberOfCalls.
-
----
-
-### 5. Bash — Criar diretorio de output
-
-1. `Bash` — `mkdir -p .../outputs`
-   - **Motivo**: Criar estrutura de diretorios para salvar os arquivos de saida do eval.
-   - **Resultado**: Diretorio criado com sucesso.
-
----
-
-### 6. Write — Salvar response.md
-
-1. `Write` — `.../outputs/response.md`
-   - **Motivo**: Salvar a resposta completa da interacao inicial.
-   - **Resultado**: Arquivo criado com: extracao do nome, analise do codebase, pergunta sobre US/PRD ausentes, pergunta sobre dependencia do modulo Produto, confirmacao pendente.
-
----
-
-### 7. Write — Salvar transcript.md
-
-1. `Write` — `.../outputs/transcript.md`
-   - **Motivo**: Salvar o registro de todas as ferramentas chamadas.
-   - **Resultado**: Este arquivo.
-
----
-
-## Resumo
-
-| Ferramenta | Quantidade de chamadas | Motivo geral |
-|------------|----------------------|--------------|
-| Read | 9 | Skill, templates, arquivos do codebase |
-| Glob | 4 | Explorar estrutura do projeto |
-| Grep | 3 | Verificar existencia de produto/cache |
-| Bash | 1 | Criar diretorios de output |
-| Write | 2 | Salvar response.md e transcript.md |
-| **Total** | **19** | |

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

@@ -1,5 +0,0 @@
-{
-  "total_tokens": 43263,
-  "duration_ms": 129986,
-  "total_duration_seconds": 130.0
-}

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

@@ -1,32 +0,0 @@
-{
-  "eval_id": 3,
-  "eval_name": "spec-tech-sem-user-stories-explicitas",
-  "configuration": "without_skill",
-  "expectations": [
-    {
-      "text": "Detecta a ausencia de User Stories (US-XX) e PRD referenciado no SPEC_TECH",
-      "passed": true,
-      "evidence": "Secao 2 'Observacoes Preliminares' nota: 'O SPEC_TECH nao referencia User Stories nem PRD.' Tambem detectou que o modulo Product nao existe."
-    },
-    {
-      "text": "PERGUNTA ao usuario sobre User Stories / PRD em vez de inventar ou ignorar",
-      "passed": false,
-      "evidence": "Nao perguntou ao usuario. Apenas notou a ausencia como observacao e prosseguiu gerando o plano completo com 5 tasks sem interacao."
-    },
-    {
-      "text": "NAO inventa User Stories ficticias (guardrail: nunca invente informacoes)",
-      "passed": true,
-      "evidence": "Nao inventou User Stories. Derivou criterios diretamente do SPEC_TECH."
-    },
-    {
-      "text": "Extrai corretamente o nome da feature como 'cache-de-cardapio' ou similar em kebab-case",
-      "passed": false,
-      "evidence": "Usou 'Cache de Cardapio em Memoria' como titulo mas nao normalizou para kebab-case. Nenhuma convencao de nomenclatura aplicada."
-    },
-    {
-      "text": "Segue o processo interativo (uma pergunta por vez, confirma nome antes de prosseguir)",
-      "passed": false,
-      "evidence": "Nenhum processo interativo. Gerou o plano completo em um unico turno sem perguntas ao usuario."
-    }
-  ]
-}

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

@@ -1,248 +0,0 @@
-# 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