adi_dev_workflow 1.3.0 → 1.4.0

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

@@ -1,131 +0,0 @@
-# Transcript de Tools Chamadas — Eval 2: Spec Simples (with_skill)
-
-## Data: 2026-03-07
-
----
-
-## 1. Leitura do Skill e Templates
-
-### Tool: Read (3 chamadas em paralelo)
-1. **Read** `.claude/skills/sdd-task-plan-expert/SKILL.md`
-   - Resultado: Skill completo lido (384 linhas). Contém instrucoes do framework SDD para geracao de TASK PLAN, processo interativo, guardrails, templates e regras.
-
-2. **Read** `.claude/skills/sdd-task-plan-expert/templates/task_plan_template.md`
-   - Resultado: Template do task_plan.md lido (84 linhas). Contém 9 secoes: Identificacao, Objetivo, Macro-Fases, Lista de Tasks, Rastreabilidade, Dependencias, Criterios de Conclusao, Riscos, Checklist.
-
-3. **Read** `.claude/skills/sdd-task-plan-expert/templates/task_template.md`
-   - Resultado: Template da task individual lido (90 linhas). Contém 8 secoes: Identificacao, Objetivo, Descricao Detalhada, Aceite Tecnico, Arquivos Impactados, Testes, Notas, Checklist.
-
----
-
-## 2. Exploracao do Codebase — Estrutura de Arquivos
-
-### Tool: Glob (4 chamadas em paralelo)
-1. **Glob** `internal/**/*.go` — Encontrados 17 arquivos Go no projeto
-2. **Glob** `internal/db/migrations/*.sql` — Encontrado 1 arquivo: `001_create_usuarios.sql`
-3. **Glob** `internal/db/queries/*.sql` — Nenhum arquivo encontrado (queries estao em `internal/db/sqlc/queries/`)
-4. **Glob** `api/proto/**/*.proto` — Encontrado 1 arquivo: `api/proto/v1/user.proto`
-
----
-
-## 3. Leitura dos Arquivos do Projeto (7 chamadas em paralelo)
-
-### Tool: Read
-1. **Read** `internal/db/migrations/001_create_usuarios.sql`
-   - Resultado: Schema da tabela `usuarios` com colunas: id, nome, email, senha_hash, data_criacao, data_atualizacao. NAO possui coluna `telefone`.
-
-2. **Read** `internal/repository/user_repository.go`
-   - Resultado: Struct User (sem Phone), interface UserRepository (Create, GetByID), implementacao sqlcUserRepository, funcao toUser. Modulo FX.
-
-3. **Read** `internal/service/user_service.go`
-   - Resultado: CreateUserInput (sem Phone), interface UserService (CreateUser, GetUser — SEM UpdateUser), implementacao userServiceImpl. Modulo FX.
-
-4. **Read** `internal/handler/grpc/user_handler.go`
-   - Resultado: UserHandler com CreateUser e GetUser (SEM UpdateUser). Funcao mapServiceError. NAO retorna campo phone.
-
-5. **Read** `api/proto/v1/user.proto`
-   - Resultado: Messages CreateUserRequest (3 campos), CreateUserResponse (4 campos), GetUserRequest, GetUserResponse (5 campos). Service com CreateUser e GetUser. SEM UpdateUser. SEM campo phone.
-
-6. **Read** `internal/service/user_service_test.go`
-   - Resultado: MockUserRepository (Create, GetByID — sem Update). Testes table-driven com testify/mock. 10 testes cobrindo CreateUser e GetUser.
-
-7. **Read** `internal/handler/grpc/user_handler_test.go`
-   - Resultado: MockUserService (CreateUser, GetUser — sem UpdateUser). 11 testes cobrindo handler CreateUser e GetUser com gRPC status codes.
-
----
-
-## 4. Leitura das Queries SQLC e Configuracao
-
-### Tool: Glob (2 chamadas em paralelo)
-1. **Glob** `internal/db/**/*.sql` — Encontrados: `001_create_usuarios.sql` e `internal/db/sqlc/queries/user.sql`
-2. **Glob** `internal/db/sqlc/*` — Encontrado: `internal/db/sqlc/sqlc.yaml`
-
-### Tool: Read (4 chamadas em paralelo)
-1. **Read** `internal/db/sqlc/queries/user.sql`
-   - Resultado: 2 queries — CreateUser (INSERT com 6 colunas, sem telefone) e GetUserByID (SELECT * por id).
-
-2. **Read** `internal/db/sqlc/sqlc.yaml`
-   - Resultado: Configuracao SQLC v2, engine sqlite, queries em `queries/`, schema em `../migrations/`.
-
-3. **Read** `internal/infra/grpc/server.go`
-   - Resultado: Struct Params com fx.In, NewGRPCServer registra UserServiceServer. Modulo FX com lifecycle hooks.
-
-4. **Read** `internal/infra/di/fx.go`
-   - Resultado: AppModule compoe config, logger, database, repository, service, grpchandler, grpcserver.
-
----
-
-## 5. Leitura do Handler FX
-
-### Tool: Read
-1. **Read** `internal/handler/grpc/fx.go`
-   - Resultado: Modulo FX que provê NewUserHandler como pb.UserServiceServer via fx.Annotate/fx.As.
-
----
-
-## 6. Verificacao da Skill QA
-
-### Tool: Glob
-1. **Glob** `.claude/skills/sdd-qa-expert/**/*`
-   - Resultado: 3 arquivos encontrados — SKILL.md, task_tests_template.md, test_strategy_template.md. Skill QA disponivel para subagente.
-
----
-
-## 7. Criacao do Diretorio de Output
-
-### Tool: Bash
-1. **Bash** `mkdir -p ".claude/skills/sdd-task-plan-expert-workspace/iteration-1/eval-2-spec-simples/with_skill/outputs"`
-   - Resultado: Diretorio criado com sucesso.
-
----
-
-## 8. Escrita dos Arquivos de Saida
-
-### Tool: Write
-1. **Write** `.claude/skills/sdd-task-plan-expert-workspace/iteration-1/eval-2-spec-simples/with_skill/outputs/response.md`
-   - Resultado: Resposta completa com TASK PLAN + 6 tasks individuais.
-
-2. **Write** `.claude/skills/sdd-task-plan-expert-workspace/iteration-1/eval-2-spec-simples/with_skill/outputs/transcript.md`
-   - Resultado: Este transcript.
-
----
-
-## Resumo de Chamadas
-
-| Tool   | Quantidade | Descricao                                      |
-|--------|:----------:|-------------------------------------------------|
-| Read   | 14         | Leitura de skill, templates e arquivos do projeto |
-| Glob   | 7          | Busca de arquivos no codebase                   |
-| Bash   | 1          | Criacao de diretorio de output                  |
-| Write  | 2          | Escrita dos arquivos de saida                   |
-| **Total** | **24**  |                                                 |
-
----
-
-## Observacoes sobre o Processo
-
-1. **Analise do projeto foi feita ANTES de planejar tasks** (conforme regra do skill "PONTO CRITICO: Analise Obrigatoria do Projeto")
-2. **Descoberta critica**: O SPEC_TECH menciona UpdateUser, mas o endpoint NAO existe no codebase. Isso foi identificado na analise e impactou o escopo das tasks.
-3. **Subagente QA**: Em uma execucao real, a secao 6 de cada task seria delegada a um subagente QA via ferramenta `Task`. Nesta simulacao (eval), a secao 6 foi preenchida diretamente com base nos padroes de teste observados no projeto.
-4. **Paralelismo identificado**: T1 e T5 podem rodar em paralelo (migracao e proto sao independentes).
-5. **Separacao de documentos respeitada**: O task_plan.md contem apenas referencia/indice; o detalhamento esta nas tasks individuais.

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

@@ -1,5 +0,0 @@
-{
-  "total_tokens": 60596,
-  "duration_ms": 286579,
-  "total_duration_seconds": 286.6
-}

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

@@ -1,32 +0,0 @@
-{
-  "eval_id": 2,
-  "eval_name": "spec-tech-simples-alteracao-pontual",
-  "configuration": "without_skill",
-  "expectations": [
-    {
-      "text": "Gera um numero proporcional de tasks (entre 3 e 6) — nao over-engineers com tasks demais para uma alteracao simples",
-      "passed": false,
-      "evidence": "Gerou 12 tasks para uma feature simples de adicionar um campo. Over-engineered com tasks separadas para 'regenerar codigo SQLC' (TASK-3), 'regenerar codigo Proto' (TASK-7), e 'configurar UpdateUser como rota protegida' (TASK-9) que poderiam ser subtasks."
-    },
-    {
-      "text": "Respeita a ordem de dependencias das camadas (migracao > SQLC > repository > service > handler > proto)",
-      "passed": true,
-      "evidence": "Grafo de dependencias mostra TASK-1(migracao)->TASK-2(SQLC)->TASK-3(generate)->TASK-4(repo)->TASK-5(service)->TASK-8(handler). Proto em paralelo (TASK-6). Ordem correta."
-    },
-    {
-      "text": "Mapeia a US-10 na tabela de rastreabilidade do task_plan",
-      "passed": false,
-      "evidence": "Nao ha tabela de rastreabilidade mapeando US-10 para tasks. A US-10 nao e mencionada no task plan."
-    },
-    {
-      "text": "Cada task segue o template completo (secoes 1-8) ou marca secoes N/A com justificativa",
-      "passed": false,
-      "evidence": "Tasks usam formato ad-hoc (Camada, Arquivo, Descricao, Criterio de aceite, Dependencias) em vez do template oficial com secoes 1-8 (Identificacao, Objetivo, Descricao Detalhada, Aceite Tecnico, Arquivos Impactados, Testes, Notas, Checklist)."
-    },
-    {
-      "text": "Salva task_plan.md como documento de REFERENCIA (sem corpo detalhado de tasks dentro dele)",
-      "passed": false,
-      "evidence": "Todo o conteudo detalhado das tasks esta inline no mesmo documento. Nao ha separacao entre task_plan (referencia) e tasks individuais."
-    }
-  ]
-}

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

@@ -1,452 +0,0 @@
-# TASK PLAN — Adicionar Telefone ao Usuario v1
-
-## 1. Identificacao
-
-| Campo | Valor |
-|-------|-------|
-| **Feature** | Adicionar Telefone ao Modulo de Usuario |
-| **Versao** | v1 |
-| **Data** | 2026-03-07 |
-| **SPEC_TECH** | docs/feature-telefone-usuario/v1/spec_tech.md |
-| **Branch base** | user-feature |
-
-## 2. Resumo
-
-Adicionar o campo opcional `telefone` na tabela `usuarios` e propagar a mudanca por todas as camadas: migracao SQL, queries SQLC, repository, service, proto e handler gRPC. Inclui validacao opcional (10-15 caracteres quando informado) e testes unitarios.
-
-## 3. Tarefas
-
-### TASK-1: Criar migracao SQL para adicionar coluna telefone
-
-**Camada:** Banco de Dados
-**Arquivo a criar:** `internal/db/migrations/002_add_telefone_usuarios.sql`
-**Descricao:**
-Criar nova migracao com `ALTER TABLE usuarios ADD COLUMN telefone TEXT;`. Conforme regra de imutabilidade, nao editar a migracao 001 existente.
-
-**Conteudo esperado:**
-```sql
-ALTER TABLE usuarios ADD COLUMN telefone TEXT;
-```
-
-**Criterio de aceite:**
-- Arquivo criado em `internal/db/migrations/002_add_telefone_usuarios.sql`
-- Migracao 001 inalterada
-- Coluna `telefone` do tipo `TEXT` (nullable/opcional)
-
-**Dependencias:** Nenhuma
-
----
-
-### TASK-2: Atualizar queries SQLC para incluir telefone
-
-**Camada:** SQLC Queries
-**Arquivo a editar:** `internal/db/sqlc/queries/user.sql`
-**Descricao:**
-Adicionar a coluna `telefone` na query `CreateUser` (INSERT e parametros) e criar uma nova query `UpdateUser` que permita atualizar nome e telefone.
-
-**Alteracoes esperadas:**
-
-Query `CreateUser` atualizada:
-```sql
--- name: CreateUser :one
-INSERT INTO usuarios (id, nome, email, senha_hash, telefone, data_criacao, data_atualizacao)
-VALUES (?, ?, ?, ?, ?, ?, ?)
-RETURNING *;
-```
-
-Nova query `UpdateUser`:
-```sql
--- name: UpdateUser :one
-UPDATE usuarios SET nome = ?, telefone = ?, data_atualizacao = ?
-WHERE id = ?
-RETURNING *;
-```
-
-**Criterio de aceite:**
-- Query `CreateUser` inclui coluna `telefone`
-- Nova query `UpdateUser` criada
-- Executar `make generate` (ou `make sqlc`) apos a edicao para regenerar codigo
-
-**Dependencias:** TASK-1
-
----
-
-### TASK-3: Regenerar codigo SQLC
-
-**Camada:** Codigo Gerado
-**Descricao:**
-Executar `make generate` para que o SQLC regenere os arquivos Go em `internal/db/sqlc/` com a nova coluna `telefone` e a nova query `UpdateUser`.
-
-**Comando:**
-```bash
-make generate
-```
-
-**Criterio de aceite:**
-- Struct `Usuario` gerada inclui campo `Telefone`
-- Struct `CreateUserParams` inclui campo `Telefone`
-- Struct `UpdateUserParams` gerada
-- Funcao `UpdateUser` gerada em queries
-
-**Dependencias:** TASK-1, TASK-2
-
----
-
-### TASK-4: Atualizar modelo e repository do usuario
-
-**Camada:** Repository
-**Arquivo a editar:** `internal/repository/user_repository.go`
-**Descricao:**
-Adicionar campo `Phone` ao modelo `User`. Atualizar o mapeamento na funcao `toUser` para converter `telefone` (banco) para `Phone` (Go). Atualizar `Create` para passar `telefone` nos parametros SQLC. Adicionar metodo `Update` na interface e implementacao.
-
-**Alteracoes esperadas:**
-
-1. Adicionar campo na struct:
-```go
-type User struct {
-    ID           string
-    Name         string
-    Email        string
-    PasswordHash string
-    Phone        string    // novo campo
-    CreatedAt    time.Time
-    UpdatedAt    time.Time
-}
-```
-
-2. Atualizar interface:
-```go
-type UserRepository interface {
-    Create(ctx context.Context, user *User) (*User, error)
-    GetByID(ctx context.Context, id string) (*User, error)
-    Update(ctx context.Context, user *User) (*User, error)  // novo metodo
-}
-```
-
-3. Atualizar `Create` para incluir `Telefone` nos params SQLC
-4. Implementar metodo `Update` usando `r.queries.UpdateUser`
-5. Atualizar funcao `toUser` para mapear `Telefone` -> `Phone`
-
-**Criterio de aceite:**
-- Campo `Phone` presente no modelo `User`
-- Mapeamento `Telefone` <-> `Phone` funcional em `toUser`
-- Metodo `Update` implementado
-- `Create` passa `telefone` para o SQLC
-
-**Dependencias:** TASK-3
-
----
-
-### TASK-5: Atualizar service do usuario
-
-**Camada:** Service
-**Arquivo a editar:** `internal/service/user_service.go`
-**Descricao:**
-Adicionar campo `Phone` ao `CreateUserInput`. Criar struct `UpdateUserInput`. Adicionar metodo `UpdateUser` na interface e implementacao. Implementar validacao: se `phone` informado, deve ter entre 10 e 15 caracteres.
-
-**Alteracoes esperadas:**
-
-1. Atualizar input de criacao:
-```go
-type CreateUserInput struct {
-    Name     string
-    Email    string
-    Password string
-    Phone    string  // novo, opcional
-}
-```
-
-2. Criar input de atualizacao:
-```go
-type UpdateUserInput struct {
-    ID    string
-    Name  string
-    Phone string  // opcional
-}
-```
-
-3. Atualizar interface:
-```go
-type UserService interface {
-    CreateUser(ctx context.Context, input CreateUserInput) (*repository.User, error)
-    GetUser(ctx context.Context, id string) (*repository.User, error)
-    UpdateUser(ctx context.Context, input UpdateUserInput) (*repository.User, error)  // novo
-}
-```
-
-4. Adicionar validacao de telefone (reutilizavel em Create e Update):
-```go
-func validatePhone(phone string) error {
-    if phone != "" && (len(phone) < 10 || len(phone) > 15) {
-        return errors.New("telefone deve ter entre 10 e 15 caracteres")
-    }
-    return nil
-}
-```
-
-5. Chamar `validatePhone` em `CreateUser` e `UpdateUser`
-6. Passar `Phone` para `repository.User` em `CreateUser`
-7. Implementar `UpdateUser` com busca por ID + chamada ao repo
-
-**Criterio de aceite:**
-- Campo `Phone` aceito em `CreateUser`
-- Metodo `UpdateUser` implementado
-- Validacao de telefone (10-15 chars) funcional
-- Telefone vazio e aceito (campo opcional)
-
-**Dependencias:** TASK-4
-
----
-
-### TASK-6: Atualizar definicao Proto
-
-**Camada:** Proto/gRPC
-**Arquivo a editar:** `api/proto/v1/user.proto`
-**Descricao:**
-Adicionar campo `string phone` nas mensagens `CreateUserRequest`, `CreateUserResponse`, `GetUserResponse`. Criar mensagens `UpdateUserRequest` e `UpdateUserResponse`. Adicionar RPC `UpdateUser` ao service.
-
-**Alteracoes esperadas:**
-
-1. Adicionar `string phone = 4;` em `CreateUserRequest`
-2. Adicionar `string phone = 4;` em `CreateUserResponse` (apos `email`, ajustar numeracao de `created_at` para 5)
-3. Adicionar `string phone = 4;` em `GetUserResponse` (apos `email`, ajustar numeracao: `phone=4`, `created_at=5`, `updated_at=6`)
-
-> **ATENCAO:** A numeracao dos campos existentes NAO pode ser alterada sem quebrar compatibilidade. Verificar a numeracao atual antes de definir os novos numeros. Dado que `CreateUserResponse` ja usa campos 1-4 e `GetUserResponse` usa 1-5, o campo `phone` deve usar o proximo numero disponivel em cada mensagem.
-
-Numeracao correta baseada no proto atual:
-- `CreateUserRequest`: `string phone = 4;` (campos existentes: 1=name, 2=email, 3=password)
-- `CreateUserResponse`: `string phone = 5;` (campos existentes: 1=id, 2=name, 3=email, 4=created_at)
-- `GetUserResponse`: `string phone = 6;` (campos existentes: 1=id, 2=name, 3=email, 4=created_at, 5=updated_at)
-
-4. Criar mensagens novas:
-```proto
-message UpdateUserRequest {
-  string id = 1;
-  string name = 2;
-  string phone = 3;
-}
-
-message UpdateUserResponse {
-  string id = 1;
-  string name = 2;
-  string email = 3;
-  string phone = 4;
-  string updated_at = 5;
-}
-```
-
-5. Adicionar ao service:
-```proto
-rpc UpdateUser(UpdateUserRequest) returns (UpdateUserResponse);
-```
-
-**Criterio de aceite:**
-- Campo `phone` adicionado nas mensagens existentes com numeracao correta
-- Mensagens `UpdateUserRequest`/`UpdateUserResponse` criadas
-- RPC `UpdateUser` registrado no service
-- Numeracao de campos existentes NAO alterada
-
-**Dependencias:** Nenhuma (pode ser feita em paralelo com TASK-1 a TASK-5)
-
----
-
-### TASK-7: Regenerar codigo Proto
-
-**Camada:** Codigo Gerado
-**Descricao:**
-Executar `make generate` (buf generate) para regenerar o codigo Go em `gen/proto/v1/`.
-
-**Comando:**
-```bash
-make generate
-```
-
-**Criterio de aceite:**
-- Structs Go geradas incluem campo `Phone`
-- Interface `UserServiceServer` inclui metodo `UpdateUser`
-- Compilacao sem erros
-
-**Dependencias:** TASK-6
-
----
-
-### TASK-8: Atualizar handler gRPC do usuario
-
-**Camada:** Handler
-**Arquivo a editar:** `internal/handler/grpc/user_handler.go`
-**Descricao:**
-Atualizar `CreateUser` para passar `Phone` do request para o service input e incluir `phone` na response. Implementar metodo `UpdateUser`. Atualizar `GetUser` para incluir `phone` na response.
-
-**Alteracoes esperadas:**
-
-1. Em `CreateUser`:
-   - Adicionar `Phone: req.GetPhone()` ao `CreateUserInput`
-   - Adicionar `Phone: user.Phone` na response
-
-2. Em `GetUser`:
-   - Adicionar `Phone: user.Phone` na response
-
-3. Novo metodo `UpdateUser`:
-```go
-func (h *UserHandler) UpdateUser(ctx context.Context, req *pb.UpdateUserRequest) (*pb.UpdateUserResponse, error) {
-    input := service.UpdateUserInput{
-        ID:    req.GetId(),
-        Name:  req.GetName(),
-        Phone: req.GetPhone(),
-    }
-    user, err := h.userService.UpdateUser(ctx, input)
-    if err != nil {
-        return nil, mapServiceError(err)
-    }
-    return &pb.UpdateUserResponse{
-        Id:        user.ID,
-        Name:      user.Name,
-        Email:     user.Email,
-        Phone:     user.Phone,
-        UpdatedAt: user.UpdatedAt.Format(time.RFC3339),
-    }, nil
-}
-```
-
-**Criterio de aceite:**
-- `CreateUser` repassa e retorna `phone`
-- `GetUser` retorna `phone`
-- `UpdateUser` implementado e funcional
-- Erros mapeados corretamente
-
-**Dependencias:** TASK-5, TASK-7
-
----
-
-### TASK-9: Configurar UpdateUser como rota protegida
-
-**Camada:** Configuracao
-**Arquivo a verificar:** `configs/config.yaml`
-**Descricao:**
-Verificar que `UpdateUser` NAO esta em `skip_methods` (ou seja, requer autenticacao). Apenas `CreateUser` deve ser publico. Se necessario, nenhuma alteracao e necessaria, apenas confirmar.
-
-**Criterio de aceite:**
-- `UpdateUser` exige autenticacao (Bearer token)
-- Nenhuma rota protegida acidentalmente exposta
-
-**Dependencias:** TASK-8
-
----
-
-### TASK-10: Atualizar testes unitarios do service
-
-**Camada:** Testes
-**Arquivo a editar:** `internal/service/user_service_test.go`
-**Descricao:**
-Atualizar mock do repository para incluir metodo `Update`. Adicionar testes para:
-
-1. `TestCreateUser_WithPhone_Success` — criacao com telefone valido
-2. `TestCreateUser_WithInvalidPhone_TooShort` — telefone com menos de 10 chars
-3. `TestCreateUser_WithInvalidPhone_TooLong` — telefone com mais de 15 chars
-4. `TestCreateUser_WithEmptyPhone_Success` — telefone vazio (opcional)
-5. `TestUpdateUser_Success` — atualizacao com dados validos
-6. `TestUpdateUser_WithPhone_Success` — atualizacao com telefone valido
-7. `TestUpdateUser_InvalidPhone` — telefone invalido na atualizacao
-8. `TestUpdateUser_NotFound` — usuario nao encontrado
-
-**Criterio de aceite:**
-- Mock atualizado com metodo `Update`
-- Todos os cenarios de telefone cobertos (valido, vazio, curto, longo)
-- Testes de `UpdateUser` adicionados
-- Todos os testes passam: `CGO_ENABLED=1 go test ./internal/service/... -v`
-
-**Dependencias:** TASK-5
-
----
-
-### TASK-11: Atualizar testes unitarios do handler
-
-**Camada:** Testes
-**Arquivo a editar:** `internal/handler/grpc/user_handler_test.go`
-**Descricao:**
-Atualizar mock do service para incluir metodo `UpdateUser`. Adicionar testes para:
-
-1. `TestUserHandler_CreateUser_WithPhone` — verifica que phone e repassado e retornado
-2. `TestUserHandler_GetUser_WithPhone` — verifica que phone e retornado
-3. `TestUserHandler_UpdateUser_Success` — atualizacao com sucesso
-4. `TestUserHandler_UpdateUser_NotFound` — usuario nao encontrado
-5. `TestUserHandler_UpdateUser_InvalidPhone` — telefone invalido
-
-**Criterio de aceite:**
-- Mock atualizado com metodo `UpdateUser`
-- Testes de phone no CreateUser e GetUser
-- Testes de UpdateUser cobrindo sucesso e erros
-- Todos os testes passam: `CGO_ENABLED=1 go test ./internal/handler/grpc/... -v`
-
-**Dependencias:** TASK-8
-
----
-
-### TASK-12: Teste de integracao e validacao final
-
-**Camada:** Validacao
-**Descricao:**
-Executar build e suite completa de testes para garantir que tudo funciona junto.
-
-**Comandos:**
-```bash
-make build
-make test
-```
-
-**Criterio de aceite:**
-- Build compila sem erros
-- Todos os testes passam
-- Nenhuma regressao nos testes existentes
-
-**Dependencias:** TASK-10, TASK-11
-
----
-
-## 4. Grafo de Dependencias
-
-```
-TASK-1 (migracao SQL)
-  └─> TASK-2 (queries SQLC)
-        └─> TASK-3 (make generate - SQLC)
-              └─> TASK-4 (repository)
-                    └─> TASK-5 (service)
-                          ├─> TASK-8 (handler) [+ TASK-7]
-                          └─> TASK-10 (testes service)
-
-TASK-6 (proto) [paralelo com TASK-1..5]
-  └─> TASK-7 (make generate - proto)
-        └─> TASK-8 (handler)
-              ├─> TASK-9 (config auth)
-              └─> TASK-11 (testes handler)
-
-TASK-10 + TASK-11
-  └─> TASK-12 (validacao final)
-```
-
-## 5. Ordem de Execucao Sugerida
-
-| Fase | Tasks | Descricao |
-|------|-------|-----------|
-| **Fase 1** | TASK-1, TASK-6 | Migracao SQL + Proto (paralelo) |
-| **Fase 2** | TASK-2 | Queries SQLC |
-| **Fase 3** | TASK-3, TASK-7 | Regenerar codigo (SQLC + Proto) — executar `make generate` uma unica vez |
-| **Fase 4** | TASK-4 | Repository |
-| **Fase 5** | TASK-5 | Service |
-| **Fase 6** | TASK-8, TASK-9 | Handler + Config |
-| **Fase 7** | TASK-10, TASK-11 | Testes (paralelo) |
-| **Fase 8** | TASK-12 | Validacao final |
-
-## 6. Riscos e Observacoes
-
-1. **Numeracao Proto:** A numeracao dos campos proto existentes NAO pode ser alterada. O campo `phone` deve usar o proximo numero livre em cada mensagem. Isso e critico para compatibilidade.
-
-2. **Migracao imutavel:** A migracao 001 NAO deve ser editada. Sempre criar nova migracao (002).
-
-3. **Codigo gerado:** Nunca editar arquivos em `gen/` ou `internal/db/sqlc/*.go`. Sempre editar os fontes (`.proto`, `.sql`) e rodar `make generate`.
-
-4. **Campo opcional:** O campo `telefone` e `TEXT` nullable no SQLite. No Go, o SQLC pode gerar como `sql.NullString` — verificar apos geracao e ajustar mapeamento no repository conforme necessario.
-
-5. **UpdateUser e novo:** O proto atual nao tem `UpdateUser`. E necessario criar o RPC, mensagens e implementar em todas as camadas. A SPEC_TECH menciona "UpdateUser" mas o codebase atual nao possui esse endpoint.
-
-6. **`make generate`:** Os comandos `make generate` das TASK-3 e TASK-7 podem ser executados em uma unica chamada se o Makefile gerar tanto SQLC quanto Proto.