adi_dev_workflow 1.1.1 → 1.3.0

package/frameworks/skills/sdd-task-plan-expert-workspace/iteration-1/benchmark.md

@@ -1,64 +1,64 @@
-# Benchmark — sdd-task-plan-expert (Iteration 1)
-
-## Resumo
-
-| Metrica | With Skill | Without Skill (Baseline) | Delta |
-|---------|-----------|-------------------------|-------|
-| **Pass Rate** | **93.3%** (14/15) | 33.3% (5/15) | **+60.0pp** |
-| **Tokens (media)** | 55,027 | 38,834 | +41.7% |
-| **Duracao (media)** | 184.9s | 151.2s | +22.3% |
-
-## Resultados por Eval
-
-### Eval 1: Happy Path (SPEC_TECH real do modulo de usuario)
-
-| Assertion | With Skill | Without Skill |
-|-----------|:---------:|:------------:|
-| Extrai nome e confirma com usuario | PASS | FAIL |
-| Uma pergunta por vez | PASS | FAIL |
-| Propoe fases antes de tasks | PASS | FAIL |
-| Le rules do projeto antes | FAIL | FAIL |
-| Nao inicia execucao automatica | PASS | PASS |
-
-### Eval 2: Feature Simples (adicionar telefone)
-
-| Assertion | With Skill | Without Skill |
-|-----------|:---------:|:------------:|
-| Numero proporcional de tasks (3-6) | PASS (6) | FAIL (12) |
-| Ordem de dependencias correta | PASS | PASS |
-| Rastreabilidade US-10 | PASS | FAIL |
-| Template completo (secoes 1-8) | PASS | FAIL |
-| task_plan como referencia | PASS | FAIL |
-
-### Eval 3: Sem User Stories
-
-| Assertion | With Skill | Without Skill |
-|-----------|:---------:|:------------:|
-| Detecta ausencia de US/PRD | PASS | PASS |
-| Pergunta ao usuario | PASS | FAIL |
-| Nao inventa US ficticias | PASS | PASS |
-| Nome em kebab-case | PASS | FAIL |
-| Processo interativo | PASS | FAIL |
-
-## Analise
-
-### Pontos Fortes da Skill
-1. **Processo interativo**: A skill garante interacao step-by-step (93% vs 33% pass rate)
-2. **Proporcionalidade**: 6 tasks para feature simples vs 12 sem skill
-3. **Guardrails**: Detectou e perguntou sobre US/PRD ausentes em vez de ignorar
-4. **Template e rastreabilidade**: Segue template oficial e mapeia User Stories
-5. **Separacao de documentos**: task_plan como referencia, tasks em arquivos individuais
-
-### Ponto de Melhoria Identificado
-1. **Leitura de rules do projeto (a4)**: A skill instrui "Ler as rules do projeto", mas o agente leu extensivamente o codebase sem ler `.claude/rules/` e `CLAUDE.md` explicitamente. Sugestao: reforcar na skill que a leitura de rules e o PRIMEIRO passo, antes de explorar o codebase.
-
-### Custo da Skill
-- **+41.7% tokens**: Esperado — a skill faz mais trabalho (leitura de templates, processo interativo, exploração de codebase mais detalhada)
-- **+22.3% duracao**: Overhead moderado, aceitavel dado o ganho de qualidade
-
-### Assertions Nao-Discriminantes
-- "Nao inventa US ficticias" passou em ambas as configuracoes (with/without skill) — o modelo base ja respeita isso
-- "Nao inicia execucao automatica" tambem passou em ambas
-
-### Conclusao
-A skill melhora drasticamente a qualidade do output (+60pp pass rate). O unico ponto de falha (leitura de rules) e um refinamento menor. O custo adicional em tokens/tempo e justificado pelo ganho em estrutura, interatividade e conformidade com o framework SDD.
+# Benchmark — sdd-task-plan-expert (Iteration 1)
+
+## Resumo
+
+| Metrica | With Skill | Without Skill (Baseline) | Delta |
+|---------|-----------|-------------------------|-------|
+| **Pass Rate** | **93.3%** (14/15) | 33.3% (5/15) | **+60.0pp** |
+| **Tokens (media)** | 55,027 | 38,834 | +41.7% |
+| **Duracao (media)** | 184.9s | 151.2s | +22.3% |
+
+## Resultados por Eval
+
+### Eval 1: Happy Path (SPEC_TECH real do modulo de usuario)
+
+| Assertion | With Skill | Without Skill |
+|-----------|:---------:|:------------:|
+| Extrai nome e confirma com usuario | PASS | FAIL |
+| Uma pergunta por vez | PASS | FAIL |
+| Propoe fases antes de tasks | PASS | FAIL |
+| Le rules do projeto antes | FAIL | FAIL |
+| Nao inicia execucao automatica | PASS | PASS |
+
+### Eval 2: Feature Simples (adicionar telefone)
+
+| Assertion | With Skill | Without Skill |
+|-----------|:---------:|:------------:|
+| Numero proporcional de tasks (3-6) | PASS (6) | FAIL (12) |
+| Ordem de dependencias correta | PASS | PASS |
+| Rastreabilidade US-10 | PASS | FAIL |
+| Template completo (secoes 1-8) | PASS | FAIL |
+| task_plan como referencia | PASS | FAIL |
+
+### Eval 3: Sem User Stories
+
+| Assertion | With Skill | Without Skill |
+|-----------|:---------:|:------------:|
+| Detecta ausencia de US/PRD | PASS | PASS |
+| Pergunta ao usuario | PASS | FAIL |
+| Nao inventa US ficticias | PASS | PASS |
+| Nome em kebab-case | PASS | FAIL |
+| Processo interativo | PASS | FAIL |
+
+## Analise
+
+### Pontos Fortes da Skill
+1. **Processo interativo**: A skill garante interacao step-by-step (93% vs 33% pass rate)
+2. **Proporcionalidade**: 6 tasks para feature simples vs 12 sem skill
+3. **Guardrails**: Detectou e perguntou sobre US/PRD ausentes em vez de ignorar
+4. **Template e rastreabilidade**: Segue template oficial e mapeia User Stories
+5. **Separacao de documentos**: task_plan como referencia, tasks em arquivos individuais
+
+### Ponto de Melhoria Identificado
+1. **Leitura de rules do projeto (a4)**: A skill instrui "Ler as rules do projeto", mas o agente leu extensivamente o codebase sem ler `.claude/rules/` e `CLAUDE.md` explicitamente. Sugestao: reforcar na skill que a leitura de rules e o PRIMEIRO passo, antes de explorar o codebase.
+
+### Custo da Skill
+- **+41.7% tokens**: Esperado — a skill faz mais trabalho (leitura de templates, processo interativo, exploração de codebase mais detalhada)
+- **+22.3% duracao**: Overhead moderado, aceitavel dado o ganho de qualidade
+
+### Assertions Nao-Discriminantes
+- "Nao inventa US ficticias" passou em ambas as configuracoes (with/without skill) — o modelo base ja respeita isso
+- "Nao inicia execucao automatica" tambem passou em ambas
+
+### Conclusao
+A skill melhora drasticamente a qualidade do output (+60pp pass rate). O unico ponto de falha (leitura de rules) e um refinamento menor. O custo adicional em tokens/tempo e justificado pelo ganho em estrutura, interatividade e conformidade com o framework SDD.

package/frameworks/skills/sdd-task-plan-expert-workspace/iteration-1/eval-1-happy-path/eval_metadata.json

@@ -1,12 +1,12 @@
-{
-  "eval_id": 1,
-  "eval_name": "happy-path-spec-tech-usuario",
-  "prompt": "Gere o TASK PLAN para a feature de usuario. O SPEC_TECH aprovado esta em docs/feature-user/v1/spec_tech.md",
-  "assertions": [
-    {"id": "a1", "text": "Extrai o nome da feature do SPEC_TECH e confirma com o usuario antes de prosseguir", "type": "llm_judge"},
-    {"id": "a2", "text": "Faz apenas UMA pergunta por vez (nao bombardeia com multiplas perguntas no mesmo turno)", "type": "llm_judge"},
-    {"id": "a3", "text": "Propoe macro-fases de alto nivel e aguarda validacao antes de criar tasks", "type": "llm_judge"},
-    {"id": "a4", "text": "Le as rules do projeto (.claude/rules/ e CLAUDE.md) ANTES de gerar tasks", "type": "llm_judge"},
-    {"id": "a5", "text": "NAO inicia execucao automatica de tasks — apenas apresenta o plano e aguarda", "type": "llm_judge"}
-  ]
-}
+{
+  "eval_id": 1,
+  "eval_name": "happy-path-spec-tech-usuario",
+  "prompt": "Gere o TASK PLAN para a feature de usuario. O SPEC_TECH aprovado esta em docs/feature-user/v1/spec_tech.md",
+  "assertions": [
+    {"id": "a1", "text": "Extrai o nome da feature do SPEC_TECH e confirma com o usuario antes de prosseguir", "type": "llm_judge"},
+    {"id": "a2", "text": "Faz apenas UMA pergunta por vez (nao bombardeia com multiplas perguntas no mesmo turno)", "type": "llm_judge"},
+    {"id": "a3", "text": "Propoe macro-fases de alto nivel e aguarda validacao antes de criar tasks", "type": "llm_judge"},
+    {"id": "a4", "text": "Le as rules do projeto (.claude/rules/ e CLAUDE.md) ANTES de gerar tasks", "type": "llm_judge"},
+    {"id": "a5", "text": "NAO inicia execucao automatica de tasks — apenas apresenta o plano e aguarda", "type": "llm_judge"}
+  ]
+}

package/frameworks/skills/sdd-task-plan-expert-workspace/iteration-1/eval-1-happy-path/with_skill/grading.json

@@ -1,32 +1,32 @@
-{
-  "eval_id": 1,
-  "eval_name": "happy-path-spec-tech-usuario",
-  "configuration": "with_skill",
-  "expectations": [
-    {
-      "text": "Extrai o nome da feature do SPEC_TECH e confirma com o usuario antes de prosseguir",
-      "passed": true,
-      "evidence": "Extraiu 'Modulo de Usuario -- Vakinha Burger', normalizou para 'feature-user' em kebab-case, e perguntou: 'Podemos iniciar a definicao macro das fases? Voce concorda com esta estrutura de 5 fases?'"
-    },
-    {
-      "text": "Faz apenas UMA pergunta por vez (nao bombardeia com multiplas perguntas no mesmo turno)",
-      "passed": true,
-      "evidence": "Fez apenas uma pergunta ao final: 'Podemos iniciar a definicao macro das fases?' Nao bombardeou com multiplas perguntas."
-    },
-    {
-      "text": "Propoe macro-fases de alto nivel e aguarda validacao antes de criar tasks",
-      "passed": true,
-      "evidence": "Propos 5 fases (Fundacao, Contratos/Dados, Logica de Negocio, Apresentacao, Testes) com justificativa para cada uma, e aguardou validacao antes de criar tasks detalhadas."
-    },
-    {
-      "text": "Le as rules do projeto (.claude/rules/ e CLAUDE.md) ANTES de gerar tasks",
-      "passed": false,
-      "evidence": "O transcript mostra leitura extensiva do codebase (13 arquivos Go, proto, config, PRD), mas NAO ha leitura explicita de .claude/rules/ nem CLAUDE.md. O agente explorou o codebase mas nao leu as rules do projeto."
-    },
-    {
-      "text": "NAO inicia execucao automatica de tasks — apenas apresenta o plano e aguarda",
-      "passed": true,
-      "evidence": "Encerrou com 'Este e o primeiro turno de interacao' e explicou que o proximo passo seria destrinchar tasks da Fase 1. Nao iniciou execucao automatica."
-    }
-  ]
-}
+{
+  "eval_id": 1,
+  "eval_name": "happy-path-spec-tech-usuario",
+  "configuration": "with_skill",
+  "expectations": [
+    {
+      "text": "Extrai o nome da feature do SPEC_TECH e confirma com o usuario antes de prosseguir",
+      "passed": true,
+      "evidence": "Extraiu 'Modulo de Usuario -- Vakinha Burger', normalizou para 'feature-user' em kebab-case, e perguntou: 'Podemos iniciar a definicao macro das fases? Voce concorda com esta estrutura de 5 fases?'"
+    },
+    {
+      "text": "Faz apenas UMA pergunta por vez (nao bombardeia com multiplas perguntas no mesmo turno)",
+      "passed": true,
+      "evidence": "Fez apenas uma pergunta ao final: 'Podemos iniciar a definicao macro das fases?' Nao bombardeou com multiplas perguntas."
+    },
+    {
+      "text": "Propoe macro-fases de alto nivel e aguarda validacao antes de criar tasks",
+      "passed": true,
+      "evidence": "Propos 5 fases (Fundacao, Contratos/Dados, Logica de Negocio, Apresentacao, Testes) com justificativa para cada uma, e aguardou validacao antes de criar tasks detalhadas."
+    },
+    {
+      "text": "Le as rules do projeto (.claude/rules/ e CLAUDE.md) ANTES de gerar tasks",
+      "passed": false,
+      "evidence": "O transcript mostra leitura extensiva do codebase (13 arquivos Go, proto, config, PRD), mas NAO ha leitura explicita de .claude/rules/ nem CLAUDE.md. O agente explorou o codebase mas nao leu as rules do projeto."
+    },
+    {
+      "text": "NAO inicia execucao automatica de tasks — apenas apresenta o plano e aguarda",
+      "passed": true,
+      "evidence": "Encerrou com 'Este e o primeiro turno de interacao' e explicou que o proximo passo seria destrinchar tasks da Fase 1. Nao iniciou execucao automatica."
+    }
+  ]
+}

package/frameworks/skills/sdd-task-plan-expert-workspace/iteration-1/eval-1-happy-path/with_skill/outputs/response.md

@@ -1,134 +1,134 @@
-# Resposta ao Usuario — Primeiro Turno de Interacao
-
----
-
-Obrigado! Li o SPEC_TECH aprovado em `docs/feature-user/v1/spec_tech.md`.
-
-Extraindo o nome da feature da secao "1. Visao Geral Tecnica":
-
-> **Feature**: Modulo de Usuario -- Vakinha Burger
-
-Nome normalizado para o framework SDD (kebab-case): **`feature-user`**
-
-Diretorio de trabalho: `docs/feature-user/v1/` (ja existente, onde vivem o `prd.md` e o `spec_tech.md`)
-
----
-
-## Analise do Codebase Existente
-
-Antes de propor as fases, analisei o projeto e identifiquei o estado atual:
-
-### O que ja existe (e sera MODIFICADO)
-| Camada | Arquivo | Estado Atual |
-|--------|---------|-------------|
-| Proto | `api/proto/v1/user.proto` | `CreateUser` + `GetUser` (sera substituido por `Login`, `GetUserLogged`, `UpdateUser`) |
-| Repository | `internal/repository/user_repository.go` | `Create` + `GetByID`; modelo `User` sem `Address`; interface `UserRepository` sem `GetByEmail`/`Update` |
-| Service | `internal/service/user_service.go` | `CreateUser` + `GetUser`; sem `Login`, `GetUserLogged`, `UpdateUser`; sem logger/config; validacoes basicas |
-| Service Tests | `internal/service/user_service_test.go` | Testes existentes para `CreateUser` e `GetUser` |
-| Handler | `internal/handler/grpc/user_handler.go` | `CreateUser` + `GetUser`; `mapServiceError` basico |
-| Handler Tests | `internal/handler/grpc/user_handler_test.go` | Testes existentes para os handlers atuais |
-| Interceptor | `internal/infra/grpc/interceptors/auth.go` | JWT parse manual; `skipMethods` apenas `CreateUser`; nao injeta `user_id` no contexto |
-| Interceptor Tests | `internal/infra/grpc/interceptors/auth_test.go` | Testes existentes |
-| Config | `internal/infra/config/config.go` | Sem campo `JWTExpirationHours` |
-| Config YAML | `configs/config.yaml` | Sem `jwt.expiration_hours` |
-| Queries SQLC | `internal/db/sqlc/queries/user.sql` | Apenas `CreateUser` e `GetUserByID` |
-| Migration | `internal/db/migrations/001_create_usuarios.sql` | Tabela `usuarios` sem coluna `endereco` |
-
-### O que NAO existe (sera CRIADO)
-| Camada | Arquivo | Descricao |
-|--------|---------|-----------|
-| Identity | `internal/pkg/identity/identity.go` | Pacote JWT: Claims, GenerateToken, ParseToken, WithUserID, UserIDFromContext |
-| Identity Tests | `internal/pkg/identity/identity_test.go` | Testes unitarios do pacote identity |
-| Migration | `internal/db/migrations/002_add_endereco_usuarios.sql` | ADD COLUMN `endereco` |
-| Integration Tests | `internal/repository/user_repository_integration_test.go` | Testes de integracao com SQLite real |
-| E2E Tests | `internal/e2e/user_e2e_test.go` | Testes E2E com servidor gRPC real |
-
----
-
-## Proposta de Macro-Fases
-
-Com base no SPEC_TECH, nas dependencias entre camadas e no principio de "cada fase entrega valor incremental e testavel", proponho as seguintes macro-fases:
-
-### Fase 1 -- Fundacao: Configuracao, Migration e Identity
-**Objetivo:** Preparar a infraestrutura necessaria para as demais fases. Criar o pacote `identity` (JWT + contexto), adicionar a coluna `endereco` ao banco, e atualizar a configuracao com `JWTExpirationHours`.
-
-**Justificativa:** Tudo que vem depois depende do pacote identity e da coluna `endereco` existirem. Sao pecas fundamentais sem dependencia entre si (podem ser paralelizadas).
-
-**Tasks previstas:**
-- T1: Configuracao (`config.go` + `config.yaml` — adicionar `JWTExpirationHours`)
-- T2: Migration `002_add_endereco_usuarios.sql`
-- T3: Pacote `internal/pkg/identity` (criar completo com testes)
-
-### Fase 2 -- Contratos e Dados: Proto, Queries SQLC e Repository
-**Objetivo:** Atualizar os contratos gRPC (proto), as queries SQLC e a camada repository para suportar todos os 4 endpoints e o campo `address`.
-
-**Justificativa:** Service e Handler dependem dos contratos proto e da interface do repository estarem prontos. Apos esta fase, `make generate` pode ser executado e o repositorio esta completo.
-
-**Tasks previstas:**
-- T4: Atualizar `user.proto` (substituicao completa conforme SPEC)
-- T5: Atualizar queries SQLC (`user.sql`) + executar `make generate`
-- T6: Atualizar `user_repository.go` (modelo `User` com `Address`, novos metodos `GetByEmail` e `Update`)
-
-### Fase 3 -- Logica de Negocio: Service
-**Objetivo:** Implementar toda a logica de negocio no service: validacoes, `Login`, `GetUserLogged`, `UpdateUser`, integracao com identity e logger.
-
-**Justificativa:** O service depende do repository (Fase 2) e do identity (Fase 1) estarem prontos. E a camada mais complexa, com todas as regras de negocio (RN-1 a RN-12).
-
-**Tasks previstas:**
-- T7: Atualizar `user_service.go` (novos metodos, validacoes, logger, config)
-
-### Fase 4 -- Apresentacao: Handler e Interceptor
-**Objetivo:** Atualizar os handlers gRPC e o interceptor de autenticacao para expor os 4 endpoints, mapear erros corretamente e injetar `user_id` no contexto.
-
-**Justificativa:** Depende do service (Fase 3) e do identity (Fase 1). Completa a stack funcional.
-
-**Tasks previstas:**
-- T8: Atualizar interceptor `auth.go` (adicionar `Login` em skipMethods, usar `identity.ParseToken`, injetar `user_id`)
-- T9: Atualizar `user_handler.go` (remover `GetUser`, adicionar `Login`, `GetUserLogged`, `UpdateUser`, atualizar `mapServiceError`)
-
-### Fase 5 -- Testes
-**Objetivo:** Criar/atualizar todos os testes unitarios, de integracao e E2E conforme definido na secao 14 do SPEC_TECH.
-
-**Justificativa:** Testes dependem de toda a implementacao estar pronta. Executar ao final garante cobertura completa e nao exige retrabalho.
-
-**Tasks previstas:**
-- T10: Atualizar testes unitarios do service (`user_service_test.go`)
-- T11: Atualizar testes unitarios do handler (`user_handler_test.go`)
-- T12: Atualizar testes do interceptor (`auth_test.go`)
-- T13: Criar testes de integracao do repository (`user_repository_integration_test.go`)
-- T14: Criar testes E2E (`user_e2e_test.go`)
-
----
-
-## Rastreabilidade Preliminar (User Stories -> Fases)
-
-| User Story | Descricao | Fases Envolvidas |
-|------------|-----------|-----------------|
-| US-01 | Cadastro de novo usuario | F1 (config, migration, identity), F2 (proto, queries, repo), F3 (service), F4 (handler), F5 (testes) |
-| US-02 | Login com email e senha | F1 (config, identity), F2 (proto, repo), F3 (service), F4 (handler, interceptor), F5 (testes) |
-| US-03 | Consultar dados do usuario autenticado | F1 (identity), F2 (proto, repo), F3 (service), F4 (handler, interceptor), F5 (testes) |
-| US-04 | Atualizar dados cadastrais | F1 (identity, migration), F2 (proto, queries, repo), F3 (service), F4 (handler, interceptor), F5 (testes) |
-
----
-
-## Paralelismo Identificado
-
-- **Fase 1:** T1, T2 e T3 podem rodar em paralelo (sem dependencia entre si)
-- **Fase 2:** T4 e T5 sao sequenciais (proto antes de queries/generate), T6 depende de T5
-- **Fase 5:** T10, T11, T12 podem rodar em paralelo; T13 e T14 podem rodar em paralelo entre si
-
----
-
-Podemos iniciar a definicao macro das fases? Voce concorda com esta estrutura de 5 fases, ou gostaria de ajustar algo (unir/separar fases, mudar ordem, realocar tasks)?
-
----
-
-*[Simulacao de resposta do usuario para fins de avaliacao]*
-
-**Pergunta que seria feita:** "Podemos iniciar a definicao macro das fases? Voce concorda com esta estrutura de 5 fases, ou gostaria de ajustar algo?"
-
-**Resposta simulada:** "Sim, a estrutura de 5 fases esta otima. Podemos prosseguir com o detalhamento das tasks da Fase 1."
-
----
-
-> **Nota:** Este e o primeiro turno de interacao. Conforme as instrucoes da avaliacao, o processo foi interrompido aqui. O proximo passo seria destrinchar as tasks da Fase 1 individualmente, criando os arquivos `tasks/T1.md`, `tasks/T2.md` e `tasks/T3.md` com o template completo (secoes 1-5 e 7-8 pelo engenheiro de tarefas, secao 6 delegada ao subagente QA), salvando cada arquivo antes de apresentar ao usuario para aprovacao.
+# Resposta ao Usuario — Primeiro Turno de Interacao
+
+---
+
+Obrigado! Li o SPEC_TECH aprovado em `docs/feature-user/v1/spec_tech.md`.
+
+Extraindo o nome da feature da secao "1. Visao Geral Tecnica":
+
+> **Feature**: Modulo de Usuario -- Vakinha Burger
+
+Nome normalizado para o framework SDD (kebab-case): **`feature-user`**
+
+Diretorio de trabalho: `docs/feature-user/v1/` (ja existente, onde vivem o `prd.md` e o `spec_tech.md`)
+
+---
+
+## Analise do Codebase Existente
+
+Antes de propor as fases, analisei o projeto e identifiquei o estado atual:
+
+### O que ja existe (e sera MODIFICADO)
+| Camada | Arquivo | Estado Atual |
+|--------|---------|-------------|
+| Proto | `api/proto/v1/user.proto` | `CreateUser` + `GetUser` (sera substituido por `Login`, `GetUserLogged`, `UpdateUser`) |
+| Repository | `internal/repository/user_repository.go` | `Create` + `GetByID`; modelo `User` sem `Address`; interface `UserRepository` sem `GetByEmail`/`Update` |
+| Service | `internal/service/user_service.go` | `CreateUser` + `GetUser`; sem `Login`, `GetUserLogged`, `UpdateUser`; sem logger/config; validacoes basicas |
+| Service Tests | `internal/service/user_service_test.go` | Testes existentes para `CreateUser` e `GetUser` |
+| Handler | `internal/handler/grpc/user_handler.go` | `CreateUser` + `GetUser`; `mapServiceError` basico |
+| Handler Tests | `internal/handler/grpc/user_handler_test.go` | Testes existentes para os handlers atuais |
+| Interceptor | `internal/infra/grpc/interceptors/auth.go` | JWT parse manual; `skipMethods` apenas `CreateUser`; nao injeta `user_id` no contexto |
+| Interceptor Tests | `internal/infra/grpc/interceptors/auth_test.go` | Testes existentes |
+| Config | `internal/infra/config/config.go` | Sem campo `JWTExpirationHours` |
+| Config YAML | `configs/config.yaml` | Sem `jwt.expiration_hours` |
+| Queries SQLC | `internal/db/sqlc/queries/user.sql` | Apenas `CreateUser` e `GetUserByID` |
+| Migration | `internal/db/migrations/001_create_usuarios.sql` | Tabela `usuarios` sem coluna `endereco` |
+
+### O que NAO existe (sera CRIADO)
+| Camada | Arquivo | Descricao |
+|--------|---------|-----------|
+| Identity | `internal/pkg/identity/identity.go` | Pacote JWT: Claims, GenerateToken, ParseToken, WithUserID, UserIDFromContext |
+| Identity Tests | `internal/pkg/identity/identity_test.go` | Testes unitarios do pacote identity |
+| Migration | `internal/db/migrations/002_add_endereco_usuarios.sql` | ADD COLUMN `endereco` |
+| Integration Tests | `internal/repository/user_repository_integration_test.go` | Testes de integracao com SQLite real |
+| E2E Tests | `internal/e2e/user_e2e_test.go` | Testes E2E com servidor gRPC real |
+
+---
+
+## Proposta de Macro-Fases
+
+Com base no SPEC_TECH, nas dependencias entre camadas e no principio de "cada fase entrega valor incremental e testavel", proponho as seguintes macro-fases:
+
+### Fase 1 -- Fundacao: Configuracao, Migration e Identity
+**Objetivo:** Preparar a infraestrutura necessaria para as demais fases. Criar o pacote `identity` (JWT + contexto), adicionar a coluna `endereco` ao banco, e atualizar a configuracao com `JWTExpirationHours`.
+
+**Justificativa:** Tudo que vem depois depende do pacote identity e da coluna `endereco` existirem. Sao pecas fundamentais sem dependencia entre si (podem ser paralelizadas).
+
+**Tasks previstas:**
+- T1: Configuracao (`config.go` + `config.yaml` — adicionar `JWTExpirationHours`)
+- T2: Migration `002_add_endereco_usuarios.sql`
+- T3: Pacote `internal/pkg/identity` (criar completo com testes)
+
+### Fase 2 -- Contratos e Dados: Proto, Queries SQLC e Repository
+**Objetivo:** Atualizar os contratos gRPC (proto), as queries SQLC e a camada repository para suportar todos os 4 endpoints e o campo `address`.
+
+**Justificativa:** Service e Handler dependem dos contratos proto e da interface do repository estarem prontos. Apos esta fase, `make generate` pode ser executado e o repositorio esta completo.
+
+**Tasks previstas:**
+- T4: Atualizar `user.proto` (substituicao completa conforme SPEC)
+- T5: Atualizar queries SQLC (`user.sql`) + executar `make generate`
+- T6: Atualizar `user_repository.go` (modelo `User` com `Address`, novos metodos `GetByEmail` e `Update`)
+
+### Fase 3 -- Logica de Negocio: Service
+**Objetivo:** Implementar toda a logica de negocio no service: validacoes, `Login`, `GetUserLogged`, `UpdateUser`, integracao com identity e logger.
+
+**Justificativa:** O service depende do repository (Fase 2) e do identity (Fase 1) estarem prontos. E a camada mais complexa, com todas as regras de negocio (RN-1 a RN-12).
+
+**Tasks previstas:**
+- T7: Atualizar `user_service.go` (novos metodos, validacoes, logger, config)
+
+### Fase 4 -- Apresentacao: Handler e Interceptor
+**Objetivo:** Atualizar os handlers gRPC e o interceptor de autenticacao para expor os 4 endpoints, mapear erros corretamente e injetar `user_id` no contexto.
+
+**Justificativa:** Depende do service (Fase 3) e do identity (Fase 1). Completa a stack funcional.
+
+**Tasks previstas:**
+- T8: Atualizar interceptor `auth.go` (adicionar `Login` em skipMethods, usar `identity.ParseToken`, injetar `user_id`)
+- T9: Atualizar `user_handler.go` (remover `GetUser`, adicionar `Login`, `GetUserLogged`, `UpdateUser`, atualizar `mapServiceError`)
+
+### Fase 5 -- Testes
+**Objetivo:** Criar/atualizar todos os testes unitarios, de integracao e E2E conforme definido na secao 14 do SPEC_TECH.
+
+**Justificativa:** Testes dependem de toda a implementacao estar pronta. Executar ao final garante cobertura completa e nao exige retrabalho.
+
+**Tasks previstas:**
+- T10: Atualizar testes unitarios do service (`user_service_test.go`)
+- T11: Atualizar testes unitarios do handler (`user_handler_test.go`)
+- T12: Atualizar testes do interceptor (`auth_test.go`)
+- T13: Criar testes de integracao do repository (`user_repository_integration_test.go`)
+- T14: Criar testes E2E (`user_e2e_test.go`)
+
+---
+
+## Rastreabilidade Preliminar (User Stories -> Fases)
+
+| User Story | Descricao | Fases Envolvidas |
+|------------|-----------|-----------------|
+| US-01 | Cadastro de novo usuario | F1 (config, migration, identity), F2 (proto, queries, repo), F3 (service), F4 (handler), F5 (testes) |
+| US-02 | Login com email e senha | F1 (config, identity), F2 (proto, repo), F3 (service), F4 (handler, interceptor), F5 (testes) |
+| US-03 | Consultar dados do usuario autenticado | F1 (identity), F2 (proto, repo), F3 (service), F4 (handler, interceptor), F5 (testes) |
+| US-04 | Atualizar dados cadastrais | F1 (identity, migration), F2 (proto, queries, repo), F3 (service), F4 (handler, interceptor), F5 (testes) |
+
+---
+
+## Paralelismo Identificado
+
+- **Fase 1:** T1, T2 e T3 podem rodar em paralelo (sem dependencia entre si)
+- **Fase 2:** T4 e T5 sao sequenciais (proto antes de queries/generate), T6 depende de T5
+- **Fase 5:** T10, T11, T12 podem rodar em paralelo; T13 e T14 podem rodar em paralelo entre si
+
+---
+
+Podemos iniciar a definicao macro das fases? Voce concorda com esta estrutura de 5 fases, ou gostaria de ajustar algo (unir/separar fases, mudar ordem, realocar tasks)?
+
+---
+
+*[Simulacao de resposta do usuario para fins de avaliacao]*
+
+**Pergunta que seria feita:** "Podemos iniciar a definicao macro das fases? Voce concorda com esta estrutura de 5 fases, ou gostaria de ajustar algo?"
+
+**Resposta simulada:** "Sim, a estrutura de 5 fases esta otima. Podemos prosseguir com o detalhamento das tasks da Fase 1."
+
+---
+
+> **Nota:** Este e o primeiro turno de interacao. Conforme as instrucoes da avaliacao, o processo foi interrompido aqui. O proximo passo seria destrinchar as tasks da Fase 1 individualmente, criando os arquivos `tasks/T1.md`, `tasks/T2.md` e `tasks/T3.md` com o template completo (secoes 1-5 e 7-8 pelo engenheiro de tarefas, secao 6 delegada ao subagente QA), salvando cada arquivo antes de apresentar ao usuario para aprovacao.

package/frameworks/skills/sdd-task-plan-expert-workspace/iteration-1/eval-1-happy-path/with_skill/outputs/transcript.md

@@ -1,68 +1,68 @@
-# Transcript de Chamadas de Ferramentas
-
-## 1. Leitura do Skill e Templates (paralelo)
-
-| Ferramenta | Arquivo |
-|------------|---------|
-| Read | `.claude/skills/sdd-task-plan-expert/SKILL.md` |
-| Read | `.claude/skills/sdd-task-plan-expert/templates/task_plan_template.md` |
-| Read | `.claude/skills/sdd-task-plan-expert/templates/task_template.md` |
-| Read | `docs/feature-user/v1/spec_tech.md` |
-
-## 2. Leitura do SPEC_TECH completo (arquivo grande, lido em partes)
-
-| Ferramenta | Arquivo | Offset | Limit |
-|------------|---------|--------|-------|
-| Read | Persisted output (preview do spec_tech) | - | - |
-| Read | `docs/feature-user/v1/spec_tech.md` | 1 | 200 |
-| Read | `docs/feature-user/v1/spec_tech.md` | 200 | 400 |
-| Read | `docs/feature-user/v1/spec_tech.md` | 600 | 400 |
-
-## 3. Exploracao do Codebase Existente (paralelo)
-
-| Ferramenta | Parametro | Descricao |
-|------------|-----------|-----------|
-| Glob | `**/*.go` em `internal/` | Listar todos os arquivos Go do projeto |
-| Glob | `**/*.sql` em `internal/db/` | Listar arquivos SQL (migrations + queries) |
-| Glob | `**/*.proto` em `api/` | Listar arquivos Protobuf |
-
-## 4. Leitura dos Arquivos Existentes (paralelo)
-
-| Ferramenta | Arquivo | Objetivo |
-|------------|---------|----------|
-| Read | `internal/service/user_service.go` | Entender service atual |
-| Read | `internal/repository/user_repository.go` | Entender repository atual |
-| Read | `internal/handler/grpc/user_handler.go` | Entender handler atual |
-| Read | `internal/infra/grpc/interceptors/auth.go` | Entender interceptor atual |
-| Read | `internal/infra/config/config.go` | Entender config atual |
-| Read | `api/proto/v1/user.proto` | Entender proto atual |
-| Read | `configs/config.yaml` | Entender configuracao atual |
-
-## 5. Leitura do PRD (User Stories)
-
-| Ferramenta | Arquivo | Objetivo |
-|------------|---------|----------|
-| Glob | `**/prd.md` em `docs/feature-user/` | Localizar PRD |
-| Read | `docs/feature-user/v1/prd.md` (limit 100) | Extrair User Stories US-01 a US-04 |
-
-## 6. Criacao de Diretorios de Output
-
-| Ferramenta | Comando |
-|------------|---------|
-| Bash | `mkdir -p .claude/skills/sdd-task-plan-expert-workspace/iteration-1/eval-1-happy-path/with_skill/outputs` |
-
-## 7. Escrita dos Arquivos de Output
-
-| Ferramenta | Arquivo |
-|------------|---------|
-| Write | `.claude/skills/sdd-task-plan-expert-workspace/iteration-1/eval-1-happy-path/with_skill/outputs/response.md` |
-| Write | `.claude/skills/sdd-task-plan-expert-workspace/iteration-1/eval-1-happy-path/with_skill/outputs/transcript.md` |
-
----
-
-## Resumo
-
-- **Total de chamadas de ferramenta**: 19
-- **Ferramentas utilizadas**: ToolSearch (2x), Read (13x), Glob (3x), Bash (1x), Write (2x)
-- **Arquivos lidos**: SKILL.md, task_plan_template.md, task_template.md, spec_tech.md (3 partes), 7 arquivos Go, 1 YAML, 1 Proto, prd.md
-- **Arquivos criados**: response.md, transcript.md
+# Transcript de Chamadas de Ferramentas
+
+## 1. Leitura do Skill e Templates (paralelo)
+
+| Ferramenta | Arquivo |
+|------------|---------|
+| Read | `.claude/skills/sdd-task-plan-expert/SKILL.md` |
+| Read | `.claude/skills/sdd-task-plan-expert/templates/task_plan_template.md` |
+| Read | `.claude/skills/sdd-task-plan-expert/templates/task_template.md` |
+| Read | `docs/feature-user/v1/spec_tech.md` |
+
+## 2. Leitura do SPEC_TECH completo (arquivo grande, lido em partes)
+
+| Ferramenta | Arquivo | Offset | Limit |
+|------------|---------|--------|-------|
+| Read | Persisted output (preview do spec_tech) | - | - |
+| Read | `docs/feature-user/v1/spec_tech.md` | 1 | 200 |
+| Read | `docs/feature-user/v1/spec_tech.md` | 200 | 400 |
+| Read | `docs/feature-user/v1/spec_tech.md` | 600 | 400 |
+
+## 3. Exploracao do Codebase Existente (paralelo)
+
+| Ferramenta | Parametro | Descricao |
+|------------|-----------|-----------|
+| Glob | `**/*.go` em `internal/` | Listar todos os arquivos Go do projeto |
+| Glob | `**/*.sql` em `internal/db/` | Listar arquivos SQL (migrations + queries) |
+| Glob | `**/*.proto` em `api/` | Listar arquivos Protobuf |
+
+## 4. Leitura dos Arquivos Existentes (paralelo)
+
+| Ferramenta | Arquivo | Objetivo |
+|------------|---------|----------|
+| Read | `internal/service/user_service.go` | Entender service atual |
+| Read | `internal/repository/user_repository.go` | Entender repository atual |
+| Read | `internal/handler/grpc/user_handler.go` | Entender handler atual |
+| Read | `internal/infra/grpc/interceptors/auth.go` | Entender interceptor atual |
+| Read | `internal/infra/config/config.go` | Entender config atual |
+| Read | `api/proto/v1/user.proto` | Entender proto atual |
+| Read | `configs/config.yaml` | Entender configuracao atual |
+
+## 5. Leitura do PRD (User Stories)
+
+| Ferramenta | Arquivo | Objetivo |
+|------------|---------|----------|
+| Glob | `**/prd.md` em `docs/feature-user/` | Localizar PRD |
+| Read | `docs/feature-user/v1/prd.md` (limit 100) | Extrair User Stories US-01 a US-04 |
+
+## 6. Criacao de Diretorios de Output
+
+| Ferramenta | Comando |
+|------------|---------|
+| Bash | `mkdir -p .claude/skills/sdd-task-plan-expert-workspace/iteration-1/eval-1-happy-path/with_skill/outputs` |
+
+## 7. Escrita dos Arquivos de Output
+
+| Ferramenta | Arquivo |
+|------------|---------|
+| Write | `.claude/skills/sdd-task-plan-expert-workspace/iteration-1/eval-1-happy-path/with_skill/outputs/response.md` |
+| Write | `.claude/skills/sdd-task-plan-expert-workspace/iteration-1/eval-1-happy-path/with_skill/outputs/transcript.md` |
+
+---
+
+## Resumo
+
+- **Total de chamadas de ferramenta**: 19
+- **Ferramentas utilizadas**: ToolSearch (2x), Read (13x), Glob (3x), Bash (1x), Write (2x)
+- **Arquivos lidos**: SKILL.md, task_plan_template.md, task_template.md, spec_tech.md (3 partes), 7 arquivos Go, 1 YAML, 1 Proto, prd.md
+- **Arquivos criados**: response.md, transcript.md