adi_dev_workflow 1.1.0 → 1.2.0

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

@@ -1,1087 +0,0 @@
-# Simulacao Completa do Fluxo TASK PLAN — Adicionar Telefone ao Usuario
-
----
-
-## Passo 1: Receber SPEC_TECH e Extrair Nome
-
-**Nome extraido da secao "1. Identificacao":** Adicionar Telefone ao Modulo de Usuario
-
-**Pergunta que eu faria ao usuario:**
-
-> Obrigado! Vamos iniciar o TASK PLAN para **Adicionar Telefone ao Modulo de Usuario**. Podemos iniciar a definicao macro das fases?
-
-**Resposta simulada do usuario:** Sim, pode iniciar.
-
----
-
-## Passo 2: Analise Obrigatoria do Projeto (Resumo)
-
-### Rules Lidas
-- `CLAUDE.md` — arquitetura em camadas, comandos, convencoes
-- `.claude/rules/code-conventions.md` — codigo em ingles, banco/logs/erros em portugues
-- `.claude/rules/database.md` — SQLite WAL, migracoes imutaveis, nomenclatura PT-BR
-- `.claude/rules/fx-di.md` — Uber FX para DI
-- `.claude/rules/grpc.md` — handlers, mapeamento de erros, registro de handlers
-- `.claude/rules/protobuf.md` — Buf, convencoes de go_package, mensagens
-- `.claude/rules/repository.md` — interface + impl nao exportada, UUID no repo, mapeamento PT->EN
-- `.claude/rules/service.md` — validacao, logging, erros exportados
-- `.claude/rules/sqlc.md` — queries editaveis em `internal/db/sqlc/queries/`, codigo gerado NAO editar
-
-### Codebase Explorado — O que ja existe
-
-| Camada | Arquivo | Estado Atual |
-|--------|---------|-------------|
-| Migration 1 | `internal/db/migrations/001_create_usuarios.sql` | Tabela `usuarios` com id, nome, email, senha_hash, data_criacao, data_atualizacao |
-| Migration 2 | `internal/db/migrations/002_add_endereco_usuarios.sql` | `ALTER TABLE usuarios ADD COLUMN endereco TEXT NOT NULL DEFAULT ''` |
-| SQLC Queries | `internal/db/sqlc/queries/user.sql` | CreateUser, GetUserByID, GetUserByEmail, UpdateUser — **sem coluna `telefone`** |
-| SQLC Config | `internal/db/sqlc/sqlc.yaml` | Engine SQLite, queries em `queries/`, schema em `../migrations/` |
-| Repository | `internal/repository/user_repository.go` | Struct `User` com campos ID, Name, Email, PasswordHash, Address, CreatedAt, UpdatedAt. Interface com Create, GetByID, GetByEmail, Update. Mapeamento via `toUser()` |
-| Service | `internal/service/user_service.go` | `CreateUserInput` com Name, Email, Password, Address. `UpdateUserInput` com Name*, Email*, Address*, NewPassword*, CurrentPassword*. Validacoes e regras de negocio |
-| Handler | `internal/handler/grpc/user_handler.go` | Handlers CreateUser, Login, GetUserLogged, UpdateUser. Funcao `domainUserToProto()` e `mapServiceError()` |
-| Handler FX | `internal/handler/grpc/fx.go` | Registra UserHandler como pb.UserServiceServer |
-| Proto | `api/proto/v1/user.proto` | Mensagem User com id(1), name(2), email(3), address(4), created_at(5), updated_at(6). CreateUserRequest com name(1), email(2), password(3), address(4). UpdateUserRequest com optional name(1), email(2), address(3), new_password(4), current_password(5) |
-| gRPC Server | `internal/infra/grpc/server.go` | Registra UserServiceServer |
-| Testes Service | `internal/service/user_service_test.go` | Testes table-driven com mock de UserRepository via testify/mock |
-| Testes Handler | `internal/handler/grpc/user_handler_test.go` | Mock de UserService, testes de todos os endpoints |
-| Testes Repository | `internal/repository/user_repository_integration_test.go` | Testes de integracao com SQLite in-memory |
-
-### Descobertas Importantes para o Planejamento
-
-1. **Proxima migracao sera `003_add_telefone_usuarios.sql`** (sequencial apos 002)
-2. **Queries SQLC precisam ser atualizadas** em `internal/db/sqlc/queries/user.sql` — depois rodar `make sqlc`
-3. **Repository struct `User`** precisa de novo campo `Phone string`
-4. **Service `CreateUserInput`** e `UpdateUserInput`** precisam de campo `Phone`
-5. **Proto `user.proto`**: campo `phone` sera field number `7` na mensagem `User`, `5` em `CreateUserRequest`, e `6` em `UpdateUserRequest`
-6. **Mock de repository** em `user_service_test.go` precisa do campo `Phone`
-7. **Mock de service** em `user_handler_test.go` precisa do campo `Phone` no input
-8. **Nenhum campo `telefone` existe atualmente** em qualquer camada — tudo precisa ser criado do zero
-9. **Arquivo `configs/config.yaml`** nao precisa de alteracao (nao ha skip_methods novo)
-10. **Nota sobre nomenclatura de migracao**: o projeto usa `001_create_usuarios.sql` sem `.up.sql`/`.down.sql` — apenas arquivo unico
-
----
-
-## Passo 3: Proposta de Fases
-
-**Pergunta que eu faria ao usuario:**
-
-> Com base na analise do SPEC_TECH e do codebase, proponho as seguintes macro-fases:
->
-> **Fase 1 — Banco de Dados e Queries (Fundacao)**
-> - Nova migracao para adicionar coluna `telefone`
-> - Atualizar queries SQLC para incluir `telefone`
-> - Executar `make sqlc` para regenerar codigo
->
-> **Fase 2 — Camadas de Negocio (Repository + Service)**
-> - Adicionar campo `Phone` ao modelo e mapeamento no repository
-> - Adicionar campo `Phone` nos inputs do service e validacao
->
-> **Fase 3 — Interface gRPC (Proto + Handler)**
-> - Atualizar `user.proto` com campo `phone`
-> - Executar `make proto` para regenerar
-> - Atualizar handler para mapear campo `phone`
->
-> **Fase 4 — Testes**
-> - Atualizar testes existentes em todas as camadas
-> - Adicionar testes especificos para o campo telefone
->
-> Podemos prosseguir com esta estrutura de fases?
-
-**Resposta simulada do usuario:** Sim, aprovado. Pode destrinchar as tasks.
-
----
-
-## Passo 4: Destrinchar Tasks — Fase por Fase
-
-### Pergunta Fase 1:
-
-> Podemos destrinchar as tasks da Fase 1 — Banco de Dados e Queries?
-
-**Resposta simulada:** Sim.
-
-### Pergunta Fase 2:
-
-> Podemos destrinchar as tasks da Fase 2 — Camadas de Negocio?
-
-**Resposta simulada:** Sim.
-
-### Pergunta Fase 3:
-
-> Podemos destrinchar as tasks da Fase 3 — Interface gRPC?
-
-**Resposta simulada:** Sim.
-
-### Pergunta Fase 4:
-
-> Podemos destrinchar as tasks da Fase 4 — Testes?
-
-**Resposta simulada:** Sim.
-
----
-
-## Passo 5: Tasks Individuais (conteudo completo)
-
-Abaixo estao as tasks completas que seriam salvas em `docs/telefone-usuario/v1/tasks/TN.md`:
-
----
-
-# T1.md — Criar migracao para adicionar coluna telefone
-
-## 1. Identificacao
-- **ID**: T1
-- **Nome da Task**: Criar migracao para adicionar coluna telefone na tabela usuarios
-- **Responsavel**: —
-- **Status**: A Fazer
-- **Fase**: Fase 1 — Banco de Dados e Queries
-- **Dependencias**: Nenhuma
-- **User Stories Relacionadas**: US-10
-
----
-
-## 2. Objetivo da Task
-Criar nova migracao SQL que adiciona a coluna `telefone` (TEXT, opcional/nullable) a tabela `usuarios`.
-
----
-
-## 3. Descricao Detalhada
-
-Criar o arquivo `internal/db/migrations/003_add_telefone_usuarios.sql` com o seguinte conteudo:
-
-```sql
-ALTER TABLE usuarios ADD COLUMN telefone TEXT;
-```
-
-**Decisoes tecnicas:**
-- A coluna `telefone` e `TEXT` sem `NOT NULL`, tornando-a opcional (nullable)
-- Seguir o padrao do projeto: nome do arquivo sequencial (`003_`), descritivo, sem `.up.sql`/`.down.sql` (projeto usa arquivo unico de migracao)
-- Coluna em portugues conforme convencao do projeto (`telefone`, nao `phone`)
-- Sem valor DEFAULT, pois o campo e opcional e usuarios existentes terao `NULL`
-
-**IMPORTANTE**: Nao editar migracoes existentes (001, 002). Apenas criar nova.
-
----
-
-## 4. Aceite Tecnico (criterios objetivos)
-- [ ] Arquivo `003_add_telefone_usuarios.sql` criado em `internal/db/migrations/`
-- [ ] SQL sintaticamente correto para SQLite
-- [ ] Coluna `telefone` e TEXT nullable (sem NOT NULL)
-- [ ] Migracao nao altera tabelas existentes alem de adicionar a coluna
-- [ ] Migracao aplica sem erro em banco limpo (junto com 001 e 002)
-- [ ] Nenhuma migracao existente foi editada
-
----
-
-## 5. Arquivos Impactados
-
-### 5.1 Arquivos a Criar
-| Arquivo | Descricao |
-|---------|-----------|
-| `internal/db/migrations/003_add_telefone_usuarios.sql` | Migracao ALTER TABLE para adicionar coluna telefone |
-
-### 5.2 Arquivos a Modificar
-| Arquivo | Modificacao |
-|---------|------------|
-| Nenhum | — |
-
-### 5.3 Arquivos de Referencia
-| Arquivo | Motivo da Consulta |
-|---------|-------------------|
-| `internal/db/migrations/001_create_usuarios.sql` | Referencia de schema existente |
-| `internal/db/migrations/002_add_endereco_usuarios.sql` | Referencia de padrao de ALTER TABLE no projeto |
-
----
-
-## 6. Testes
-
-### 6.1 Testes Unitarios
-- N/A — migracao SQL nao possui logica testavel unitariamente
-
-### 6.2 Testes de Integracao
-- [ ] Teste: verificar que a coluna `telefone` existe na tabela `usuarios` apos migracao (PRAGMA table_info) — adicionar em `internal/repository/user_repository_integration_test.go` seguindo o padrao de `TestRunMigrations_TableSchema_IncludesEndereco`
-- [ ] Teste: verificar que a coluna `telefone` aceita NULL (inserir usuario sem telefone e consultar)
-- [ ] Teste: verificar que a coluna `telefone` aceita valor TEXT (inserir usuario com telefone e consultar)
-
-### 6.3 Testes E2E
-- N/A — sera coberto nas tasks de camadas superiores
-
-### 6.4 Cenarios de Erro
-- [ ] Cenario: migracao aplicada em banco que ja tem a coluna (idempotencia via golang-migrate)
-
----
-
-## 7. Notas / Observacoes
-- O padrao do projeto para migracoes usa arquivo unico (sem separacao up/down), conforme observado em `001_create_usuarios.sql` e `002_add_endereco_usuarios.sql`
-- A migracao 002 usou `NOT NULL DEFAULT ''` para `endereco` (campo obrigatorio). Para `telefone` o SPEC define como opcional, portanto `TEXT` sem `NOT NULL`
-
----
-
-## 8. Checklist Final
-- [ ] Implementada conforme SPEC
-- [ ] Testes de integracao criados/atualizados
-- [ ] Aceite tecnico atendido
-- [ ] Revisada
-- [ ] Integrada a branch principal
-
----
----
-
-# T2.md — Atualizar queries SQLC para incluir coluna telefone
-
-## 1. Identificacao
-- **ID**: T2
-- **Nome da Task**: Atualizar queries SQLC para incluir coluna telefone
-- **Responsavel**: —
-- **Status**: A Fazer
-- **Fase**: Fase 1 — Banco de Dados e Queries
-- **Dependencias**: T1
-- **User Stories Relacionadas**: US-10
-
----
-
-## 2. Objetivo da Task
-Atualizar as queries `CreateUser` e `UpdateUser` no arquivo de queries SQLC para incluir a coluna `telefone`, e regenerar o codigo SQLC.
-
----
-
-## 3. Descricao Detalhada
-
-Editar o arquivo `internal/db/sqlc/queries/user.sql`:
-
-**Query `CreateUser`** — adicionar `telefone` na lista de colunas e valores:
-```sql
--- name: CreateUser :one
-INSERT INTO usuarios (id, nome, email, senha_hash, endereco, telefone, data_criacao, data_atualizacao)
-VALUES (?, ?, ?, ?, ?, ?, ?, ?)
-RETURNING *;
-```
-
-**Query `UpdateUser`** — adicionar `telefone` no SET:
-```sql
--- name: UpdateUser :one
-UPDATE usuarios
-SET nome             = ?,
-    email            = ?,
-    senha_hash       = ?,
-    endereco         = ?,
-    telefone         = ?,
-    data_atualizacao = ?
-WHERE id = ?
-RETURNING *;
-```
-
-**Queries `GetUserByID` e `GetUserByEmail`** — usam `SELECT *`, portanto ja incluirao `telefone` automaticamente apos a migracao. Nao precisam de alteracao.
-
-Apos editar, executar `make sqlc` para regenerar o codigo em `internal/db/sqlc/`.
-
-**IMPORTANTE**: NAO editar arquivos em `internal/db/sqlc/` diretamente — apenas os arquivos em `internal/db/sqlc/queries/`.
-
----
-
-## 4. Aceite Tecnico (criterios objetivos)
-- [ ] Query `CreateUser` inclui coluna `telefone` e parametro correspondente
-- [ ] Query `UpdateUser` inclui `telefone` no SET
-- [ ] `make sqlc` executa sem erros
-- [ ] Struct `Usuario` gerada em `internal/db/sqlc/` contém campo `Telefone`
-- [ ] Params `CreateUserParams` inclui campo `Telefone`
-- [ ] Params `UpdateUserParams` inclui campo `Telefone`
-- [ ] Queries SELECT continuam funcionando (retornando `telefone`)
-
----
-
-## 5. Arquivos Impactados
-
-### 5.1 Arquivos a Criar
-| Arquivo | Descricao |
-|---------|-----------|
-| Nenhum | — |
-
-### 5.2 Arquivos a Modificar
-| Arquivo | Modificacao |
-|---------|------------|
-| `internal/db/sqlc/queries/user.sql` | Adicionar `telefone` nas queries CreateUser e UpdateUser |
-
-### 5.3 Arquivos de Referencia
-| Arquivo | Motivo da Consulta |
-|---------|-------------------|
-| `internal/db/sqlc/sqlc.yaml` | Verificar configuracao SQLC (engine, paths) |
-| `internal/db/migrations/003_add_telefone_usuarios.sql` | Verificar tipo da coluna (TEXT nullable) |
-
----
-
-## 6. Testes
-
-### 6.1 Testes Unitarios
-- N/A — queries SQL e codigo gerado SQLC nao possuem logica testavel unitariamente
-
-### 6.2 Testes de Integracao
-- [ ] Teste: `CreateUser` com campo `telefone` preenchido retorna valor correto — sera coberto na task T3/T4 (repository)
-- [ ] Teste: `CreateUser` com campo `telefone` NULL funciona corretamente — sera coberto na task T3/T4
-- [ ] Teste: `UpdateUser` com campo `telefone` atualiza valor corretamente — sera coberto na task T3/T4
-
-### 6.3 Testes E2E
-- N/A
-
-### 6.4 Cenarios de Erro
-- [ ] Cenario: `make sqlc` gera codigo sem erros de compilacao (validar com `make build`)
-
----
-
-## 7. Notas / Observacoes
-- O tipo do campo `Telefone` no codigo gerado sera `sql.NullString` pois a coluna e nullable
-- As queries SELECT usam `SELECT *` e portanto capturarao a coluna automaticamente
-- Executar `make sqlc` e obrigatorio apos editar queries — o codigo gerado em `internal/db/sqlc/` sera atualizado automaticamente
-
----
-
-## 8. Checklist Final
-- [ ] Implementada conforme SPEC
-- [ ] Codigo SQLC regenerado com sucesso
-- [ ] Aceite tecnico atendido
-- [ ] Revisada
-- [ ] Integrada a branch principal
-
----
----
-
-# T3.md — Adicionar campo Phone ao repository e atualizar mapeamento
-
-## 1. Identificacao
-- **ID**: T3
-- **Nome da Task**: Adicionar campo Phone ao modelo User do repository e atualizar mapeamento
-- **Responsavel**: —
-- **Status**: A Fazer
-- **Fase**: Fase 2 — Camadas de Negocio
-- **Dependencias**: T2
-- **User Stories Relacionadas**: US-10
-
----
-
-## 2. Objetivo da Task
-Adicionar o campo `Phone` (opcional, ponteiro `*string`) ao modelo `User` do repository, e atualizar as funcoes `Create`, `Update` e `toUser` para mapear `telefone` (banco) para `Phone` (Go).
-
----
-
-## 3. Descricao Detalhada
-
-Editar `internal/repository/user_repository.go`:
-
-**1. Adicionar campo na struct `User`:**
-```go
-type User struct {
-    ID           string
-    Name         string
-    Email        string
-    PasswordHash string
-    Address      string
-    Phone        *string    // novo campo - ponteiro pois e opcional (nullable no banco)
-    CreatedAt    time.Time
-    UpdatedAt    time.Time
-}
-```
-
-**2. Atualizar funcao `Create`** — mapear `Phone` para `Telefone` nos params SQLC:
-```go
-params := sqlc.CreateUserParams{
-    // ... campos existentes ...
-    Telefone: toNullString(user.Phone),
-    // ...
-}
-```
-
-**3. Atualizar funcao `Update`** — mapear `Phone` para `Telefone` nos params SQLC:
-```go
-params := sqlc.UpdateUserParams{
-    // ... campos existentes ...
-    Telefone: toNullString(user.Phone),
-    // ...
-}
-```
-
-**4. Atualizar funcao `toUser`** — mapear `Telefone` (sqlc) para `Phone` (dominio):
-```go
-func toUser(u sqlc.Usuario) *User {
-    return &User{
-        // ... campos existentes ...
-        Phone: fromNullString(u.Telefone),
-        // ...
-    }
-}
-```
-
-**5. Criar funcoes helper** para conversao `*string` <-> `sql.NullString`:
-```go
-func toNullString(s *string) sql.NullString {
-    if s == nil {
-        return sql.NullString{}
-    }
-    return sql.NullString{String: *s, Valid: true}
-}
-
-func fromNullString(ns sql.NullString) *string {
-    if !ns.Valid {
-        return nil
-    }
-    return &ns.String
-}
-```
-
-**Decisoes tecnicas:**
-- `Phone` e `*string` (ponteiro) no modelo de dominio para representar campo nullable
-- Funcoes helper `toNullString`/`fromNullString` para converter entre `*string` e `sql.NullString`
-- Mapeamento: `telefone` (coluna banco, portugues) -> `Phone` (struct Go, ingles)
-
----
-
-## 4. Aceite Tecnico (criterios objetivos)
-- [ ] Struct `User` possui campo `Phone *string`
-- [ ] Funcao `Create` mapeia `Phone` para `Telefone` no SQLC params
-- [ ] Funcao `Update` mapeia `Phone` para `Telefone` no SQLC params
-- [ ] Funcao `toUser` mapeia `Telefone` (sqlc) para `Phone` (dominio)
-- [ ] Funcoes helper `toNullString`/`fromNullString` implementadas
-- [ ] Codigo compila sem erros (`make build`)
-- [ ] Fluxos existentes (sem telefone) continuam funcionando — campo e opcional
-
----
-
-## 5. Arquivos Impactados
-
-### 5.1 Arquivos a Criar
-| Arquivo | Descricao |
-|---------|-----------|
-| Nenhum | — |
-
-### 5.2 Arquivos a Modificar
-| Arquivo | Modificacao |
-|---------|------------|
-| `internal/repository/user_repository.go` | Adicionar campo Phone a struct User, atualizar Create, Update, toUser, adicionar helpers |
-
-### 5.3 Arquivos de Referencia
-| Arquivo | Motivo da Consulta |
-|---------|-------------------|
-| `internal/db/sqlc/` (codigo gerado) | Verificar nomes dos campos gerados (Telefone, sql.NullString) |
-
----
-
-## 6. Testes
-
-### 6.1 Testes Unitarios
-- N/A — repository nao possui logica testavel unitariamente (depende de banco)
-
-### 6.2 Testes de Integracao
-Atualizar `internal/repository/user_repository_integration_test.go`:
-
-- [ ] Teste: `TestUserRepository_Create_WithPhone` — criar usuario com telefone e verificar que o valor e persistido e retornado
-- [ ] Teste: `TestUserRepository_Create_WithoutPhone` — criar usuario sem telefone (nil) e verificar que `Phone` retorna nil
-- [ ] Teste: `TestUserRepository_Update_Phone` — atualizar telefone de usuario existente e verificar
-- [ ] Teste: `TestUserRepository_Update_PhoneToNil` — limpar telefone (setar nil) e verificar
-- [ ] Teste: atualizar `createTestUser` para incluir campo `Phone` (pode ser nil por padrao)
-- [ ] Teste: verificar que testes existentes continuam passando (campo `Phone` nil por padrao)
-
-### 6.3 Testes E2E
-- N/A
-
-### 6.4 Cenarios de Erro
-- [ ] Cenario: criar usuario com `Phone` nil nao gera erro
-- [ ] Cenario: update com `Phone` nil nao sobrescreve valor existente indevidamente (depende da logica do service, mas repository deve aceitar nil)
-
----
-
-## 7. Notas / Observacoes
-- O campo `Telefone` no codigo gerado pelo SQLC sera `sql.NullString` porque a coluna e nullable no banco
-- Os helpers `toNullString`/`fromNullString` podem ser reutilizados por outros campos opcionais no futuro
-- O helper `createTestUser` nos testes de integracao precisa ser atualizado para incluir `Phone` (pode ser `nil` para manter compatibilidade)
-
----
-
-## 8. Checklist Final
-- [ ] Implementada conforme SPEC
-- [ ] Testes de integracao criados/atualizados
-- [ ] Aceite tecnico atendido
-- [ ] Revisada
-- [ ] Integrada a branch principal
-
----
----
-
-# T4.md — Adicionar campo Phone ao service com validacao
-
-## 1. Identificacao
-- **ID**: T4
-- **Nome da Task**: Adicionar campo Phone ao service com validacao
-- **Responsavel**: —
-- **Status**: A Fazer
-- **Fase**: Fase 2 — Camadas de Negocio
-- **Dependencias**: T3
-- **User Stories Relacionadas**: US-10
-
----
-
-## 2. Objetivo da Task
-Adicionar o campo `Phone` (opcional) nos inputs `CreateUserInput` e `UpdateUserInput` do service, implementar validacao de tamanho (10 a 15 caracteres) e integrar com o repository.
-
----
-
-## 3. Descricao Detalhada
-
-Editar `internal/service/user_service.go`:
-
-**1. Adicionar erro de validacao:**
-```go
-var (
-    // ... erros existentes ...
-    ErrInvalidPhone = errors.New("telefone deve ter entre 10 e 15 caracteres")
-)
-```
-
-**2. Adicionar campo em `CreateUserInput`:**
-```go
-type CreateUserInput struct {
-    Name     string
-    Email    string
-    Password string
-    Address  string
-    Phone    *string  // opcional
-}
-```
-
-**3. Adicionar campo em `UpdateUserInput`:**
-```go
-type UpdateUserInput struct {
-    Name            *string
-    Email           *string
-    Address         *string
-    Phone           *string  // opcional
-    NewPassword     *string
-    CurrentPassword *string
-}
-```
-
-**4. Adicionar validacao em `CreateUser`:**
-Apos as validacoes existentes, antes de criar o usuario:
-```go
-if input.Phone != nil {
-    if len(*input.Phone) < 10 || len(*input.Phone) > 15 {
-        return nil, ErrInvalidPhone
-    }
-}
-```
-
-E mapear para o repository:
-```go
-user := &repository.User{
-    // ... campos existentes ...
-    Phone: input.Phone,
-    // ...
-}
-```
-
-**5. Adicionar validacao e mapeamento em `UpdateUser`:**
-Na secao de campos opcionais:
-```go
-if input.Phone != nil {
-    if len(*input.Phone) < 10 || len(*input.Phone) > 15 {
-        return nil, ErrInvalidPhone
-    }
-    currentUser.Phone = input.Phone
-}
-```
-
-E atualizar a verificacao de "nenhum campo":
-```go
-if input.Name == nil && input.Email == nil && input.Address == nil && input.Phone == nil && input.NewPassword == nil {
-    return nil, ErrNoFieldsToUpdate
-}
-```
-
----
-
-## 4. Aceite Tecnico (criterios objetivos)
-- [ ] `CreateUserInput` possui campo `Phone *string`
-- [ ] `UpdateUserInput` possui campo `Phone *string`
-- [ ] Erro `ErrInvalidPhone` exportado com mensagem em portugues
-- [ ] Validacao: se `Phone` informado, deve ter entre 10 e 15 caracteres
-- [ ] Validacao: `Phone` nil e aceito sem erro (campo opcional)
-- [ ] `CreateUser` mapeia `Phone` para `repository.User`
-- [ ] `UpdateUser` mapeia `Phone` para `currentUser` quando informado
-- [ ] `UpdateUser` aceita `Phone` como campo unico para update (verificacao de "nenhum campo")
-- [ ] Codigo compila sem erros
-
----
-
-## 5. Arquivos Impactados
-
-### 5.1 Arquivos a Criar
-| Arquivo | Descricao |
-|---------|-----------|
-| Nenhum | — |
-
-### 5.2 Arquivos a Modificar
-| Arquivo | Modificacao |
-|---------|------------|
-| `internal/service/user_service.go` | Adicionar ErrInvalidPhone, campo Phone nos inputs, validacao e mapeamento |
-
-### 5.3 Arquivos de Referencia
-| Arquivo | Motivo da Consulta |
-|---------|-------------------|
-| `internal/repository/user_repository.go` | Verificar struct User com campo Phone |
-
----
-
-## 6. Testes
-
-### 6.1 Testes Unitarios
-Atualizar `internal/service/user_service_test.go`:
-
-**Testes novos:**
-- [ ] Teste: `TestCreateUser_WithPhone_Success` — criar usuario com telefone valido (ex: "11987654321", 11 chars)
-- [ ] Teste: `TestCreateUser_WithoutPhone_Success` — criar usuario sem telefone (nil) — validar que nao gera erro
-- [ ] Teste: `TestCreateUser_PhoneTooShort` — telefone com 9 caracteres retorna `ErrInvalidPhone`
-- [ ] Teste: `TestCreateUser_PhoneTooLong` — telefone com 16 caracteres retorna `ErrInvalidPhone`
-- [ ] Teste: `TestCreateUser_PhoneExactly10Chars` — limite inferior aceito
-- [ ] Teste: `TestCreateUser_PhoneExactly15Chars` — limite superior aceito
-- [ ] Teste: `TestUpdateUser_PhoneOnly` — atualizar apenas telefone com sucesso
-- [ ] Teste: `TestUpdateUser_PhoneInvalid` — telefone invalido retorna `ErrInvalidPhone`
-- [ ] Teste: `TestUpdateUser_PhoneWithOtherFields` — atualizar telefone junto com outros campos
-
-**Testes existentes a atualizar:**
-- [ ] Atualizar `MockUserRepository` se necessario (interface nao muda, mas `User` struct ganha campo)
-- [ ] Atualizar `returnUser` em testes existentes para incluir `Phone` (pode ser nil)
-- [ ] Garantir que testes existentes continuam passando
-
-### 6.2 Testes de Integracao
-- N/A — coberto pelos testes unitarios com mock
-
-### 6.3 Testes E2E
-- N/A
-
-### 6.4 Cenarios de Erro
-- [ ] Cenario: telefone com 9 caracteres -> `ErrInvalidPhone`
-- [ ] Cenario: telefone com 16 caracteres -> `ErrInvalidPhone`
-- [ ] Cenario: telefone vazio string ("") -> `ErrInvalidPhone` (len < 10)
-- [ ] Cenario: telefone nil -> aceito sem erro
-
----
-
-## 7. Notas / Observacoes
-- A validacao de telefone e simples: apenas tamanho entre 10 e 15 chars, conforme SPEC
-- Nao ha validacao de formato (apenas digitos, por exemplo) — se necessario, criar US separada
-- O campo `Phone` no `UpdateUserInput` participa da verificacao de "nenhum campo para atualizar"
-
----
-
-## 8. Checklist Final
-- [ ] Implementada conforme SPEC
-- [ ] Testes unitarios criados/atualizados
-- [ ] Aceite tecnico atendido
-- [ ] Revisada
-- [ ] Integrada a branch principal
-
----
----
-
-# T5.md — Atualizar proto e handler gRPC para incluir campo phone
-
-## 1. Identificacao
-- **ID**: T5
-- **Nome da Task**: Atualizar proto e handler gRPC para incluir campo phone
-- **Responsavel**: —
-- **Status**: A Fazer
-- **Fase**: Fase 3 — Interface gRPC
-- **Dependencias**: T4
-- **User Stories Relacionadas**: US-10
-
----
-
-## 2. Objetivo da Task
-Adicionar campo `phone` nas mensagens proto (User, CreateUserRequest, UpdateUserRequest), regenerar codigo, e atualizar o handler gRPC para mapear o campo.
-
----
-
-## 3. Descricao Detalhada
-
-### 3.1 Atualizar Proto
-
-Editar `api/proto/v1/user.proto`:
-
-**Mensagem `User`** — adicionar campo `phone` com field number 7:
-```proto
-message User {
-  string id         = 1;
-  string name       = 2;
-  string email      = 3;
-  string address    = 4;
-  string created_at = 5;
-  string updated_at = 6;
-  optional string phone = 7;
-}
-```
-
-**Mensagem `CreateUserRequest`** — adicionar campo `phone` com field number 5:
-```proto
-message CreateUserRequest {
-  string name     = 1;
-  string email    = 2;
-  string password = 3;
-  string address  = 4;
-  optional string phone = 5;
-}
-```
-
-**Mensagem `UpdateUserRequest`** — adicionar campo `phone` com field number 6:
-```proto
-message UpdateUserRequest {
-  optional string name             = 1;
-  optional string email            = 2;
-  optional string address          = 3;
-  optional string new_password     = 4;
-  optional string current_password = 5;
-  optional string phone            = 6;
-}
-```
-
-Executar `make proto` (ou `buf generate`) para regenerar codigo em `gen/`.
-
-### 3.2 Atualizar Handler
-
-Editar `internal/handler/grpc/user_handler.go`:
-
-**Funcao `CreateUser`** — mapear `Phone` do request para input:
-```go
-input := service.CreateUserInput{
-    Name:     req.GetName(),
-    Email:    req.GetEmail(),
-    Password: req.GetPassword(),
-    Address:  req.GetAddress(),
-    Phone:    req.Phone,   // optional -> *string
-}
-```
-
-**Funcao `UpdateUser`** — adicionar mapeamento de phone:
-```go
-if req.Phone != nil {
-    input.Phone = req.Phone
-}
-```
-
-**Funcao `domainUserToProto`** — mapear `Phone` para proto:
-```go
-func domainUserToProto(user *repository.User) *pb.User {
-    return &pb.User{
-        // ... campos existentes ...
-        Phone: user.Phone,
-    }
-}
-```
-
-**Funcao `mapServiceError`** — adicionar mapeamento de `ErrInvalidPhone`:
-```go
-case errors.Is(err, service.ErrInvalidPhone):
-    return status.Errorf(codes.InvalidArgument, "%v", err)
-```
-Adicionar na clausula `switch` junto com os outros erros de `InvalidArgument`.
-
----
-
-## 4. Aceite Tecnico (criterios objetivos)
-- [ ] Proto `user.proto` inclui campo `phone` em User (field 7), CreateUserRequest (field 5), UpdateUserRequest (field 6)
-- [ ] `make proto` executa sem erros
-- [ ] Handler `CreateUser` mapeia `Phone` do request para service input
-- [ ] Handler `UpdateUser` mapeia `Phone` do request para service input
-- [ ] Funcao `domainUserToProto` mapeia `Phone` do dominio para proto
-- [ ] `mapServiceError` trata `ErrInvalidPhone` como `InvalidArgument`
-- [ ] Codigo compila sem erros (`make build`)
-- [ ] Endpoint `CreateUser` aceita e persiste telefone
-- [ ] Endpoint `UpdateUser` aceita e atualiza telefone
-- [ ] Endpoint `GetUserLogged` retorna telefone
-
----
-
-## 5. Arquivos Impactados
-
-### 5.1 Arquivos a Criar
-| Arquivo | Descricao |
-|---------|-----------|
-| Nenhum | — |
-
-### 5.2 Arquivos a Modificar
-| Arquivo | Modificacao |
-|---------|------------|
-| `api/proto/v1/user.proto` | Adicionar campo `phone` em User, CreateUserRequest, UpdateUserRequest |
-| `internal/handler/grpc/user_handler.go` | Mapear campo Phone em CreateUser, UpdateUser, domainUserToProto, mapServiceError |
-
-### 5.3 Arquivos de Referencia
-| Arquivo | Motivo da Consulta |
-|---------|-------------------|
-| `gen/proto/v1/` (codigo gerado) | Verificar nomes de campos gerados apos `make proto` |
-| `internal/service/user_service.go` | Verificar nomes dos campos nos inputs e erro ErrInvalidPhone |
-
----
-
-## 6. Testes
-
-### 6.1 Testes Unitarios
-Atualizar `internal/handler/grpc/user_handler_test.go`:
-
-**Testes novos:**
-- [ ] Teste: `TestUserHandler_CreateUser_WithPhone` — enviar CreateUserRequest com phone e verificar que o input service recebe o valor
-- [ ] Teste: `TestUserHandler_CreateUser_WithoutPhone` — enviar sem phone e verificar que funciona normalmente
-- [ ] Teste: `TestUserHandler_CreateUser_InvalidPhone` — service retorna `ErrInvalidPhone`, verificar que handler retorna `InvalidArgument`
-- [ ] Teste: `TestUserHandler_UpdateUser_PhoneOnly` — atualizar apenas telefone via gRPC
-- [ ] Teste: `TestUserHandler_UpdateUser_InvalidPhone` — telefone invalido retorna `InvalidArgument`
-- [ ] Teste: `TestUserHandler_GetUserLogged_ReturnsPhone` — verificar que GetUserLogged retorna o campo phone no proto
-- [ ] Teste: atualizar `TestDomainUserToProto` para verificar campo `Phone`
-- [ ] Teste: atualizar `TestMapServiceError_AllErrors` para incluir `ErrInvalidPhone`
-
-**Testes existentes a atualizar:**
-- [ ] Atualizar `MockUserService` se a interface mudou (adicionar `Phone` nos inputs)
-- [ ] Atualizar testes existentes de CreateUser para incluir `Phone` no input (pode ser nil)
-- [ ] Atualizar testes existentes de UpdateUser para incluir `Phone` no input (pode ser nil)
-- [ ] Garantir que todos os testes existentes continuam passando
-
-### 6.2 Testes de Integracao
-- N/A
-
-### 6.3 Testes E2E
-- N/A — testes do handler com mock cobrem a integracao proto<->service
-
-### 6.4 Cenarios de Erro
-- [ ] Cenario: `ErrInvalidPhone` -> gRPC `InvalidArgument`
-- [ ] Cenario: phone nil no request -> nao gera erro
-- [ ] Cenario: phone vazio no UpdateUser -> nao inclui no input (req.Phone seria nil)
-
----
-
-## 7. Notas / Observacoes
-- O campo `optional string phone` no proto gera `*string` no Go, o que e compativel com o tipo `*string` no service e repository
-- Os field numbers escolhidos (7 para User, 5 para CreateUserRequest, 6 para UpdateUserRequest) sao os proximos disponiveis em cada mensagem
-- `make proto` deve ser executado ANTES de compilar o handler, pois o handler depende do codigo gerado
-- A mensagem `CreateUserResponse` e `LoginResponse` NAO incluem phone (conforme estrutura atual do proto — elas retornam campos especificos, nao a mensagem User)
-
----
-
-## 8. Checklist Final
-- [ ] Implementada conforme SPEC
-- [ ] Testes unitarios criados/atualizados
-- [ ] Aceite tecnico atendido
-- [ ] Revisada
-- [ ] Integrada a branch principal
-
----
----
-
-# T6.md — Validacao cruzada e testes end-to-end da feature completa
-
-## 1. Identificacao
-- **ID**: T6
-- **Nome da Task**: Validacao cruzada e testes end-to-end da feature completa
-- **Responsavel**: —
-- **Status**: A Fazer
-- **Fase**: Fase 4 — Testes e Validacao
-- **Dependencias**: T5
-- **User Stories Relacionadas**: US-10
-
----
-
-## 2. Objetivo da Task
-Garantir que toda a stack funciona de ponta a ponta: migracao aplica, queries funcionam, repository persiste e recupera, service valida, handler expoe via gRPC. Executar todos os testes existentes e validar que nenhum fluxo existente foi quebrado.
-
----
-
-## 3. Descricao Detalhada
-
-**1. Executar suite completa de testes:**
-```bash
-make test
-```
-Verificar que TODOS os testes passam — tanto os novos quanto os existentes.
-
-**2. Executar build completo:**
-```bash
-make build
-```
-Verificar que nao ha erros de compilacao.
-
-**3. Validar cenarios manualmente (se aplicavel):**
-- Subir servidor com `make run`
-- Testar via grpcurl ou cliente gRPC:
-  - CreateUser com telefone
-  - CreateUser sem telefone
-  - UpdateUser adicionando telefone
-  - UpdateUser removendo telefone (setar vazio / nil)
-  - GetUserLogged retornando telefone
-  - CreateUser com telefone invalido (< 10 chars)
-
-**4. Verificar que testes de regressao passam:**
-- Testes de service (unitarios com mock)
-- Testes de handler (unitarios com mock)
-- Testes de repository (integracao com SQLite)
-
----
-
-## 4. Aceite Tecnico (criterios objetivos)
-- [ ] `make test` passa sem falhas
-- [ ] `make build` compila sem erros
-- [ ] Nenhum teste existente quebrado
-- [ ] Novos testes (de T3, T4, T5) incluidos e passando
-- [ ] Campo `phone` flui corretamente de gRPC request -> handler -> service -> repository -> banco -> retorno
-
----
-
-## 5. Arquivos Impactados
-
-### 5.1 Arquivos a Criar
-| Arquivo | Descricao |
-|---------|-----------|
-| Nenhum | — |
-
-### 5.2 Arquivos a Modificar
-| Arquivo | Modificacao |
-|---------|------------|
-| Nenhum | Task de validacao — apenas execucao de testes |
-
-### 5.3 Arquivos de Referencia
-| Arquivo | Motivo da Consulta |
-|---------|-------------------|
-| Todos os arquivos de teste | Verificar que passam |
-| `Makefile` | Verificar comandos make test, make build |
-
----
-
-## 6. Testes
-
-### 6.1 Testes Unitarios
-- [ ] Executar `CGO_ENABLED=1 go test ./internal/service/... -v` — todos devem passar
-- [ ] Executar `CGO_ENABLED=1 go test ./internal/handler/grpc/... -v` — todos devem passar
-
-### 6.2 Testes de Integracao
-- [ ] Executar `CGO_ENABLED=1 go test ./internal/repository/... -v` — todos devem passar
-
-### 6.3 Testes E2E
-- [ ] (Opcional) Teste manual via grpcurl: CreateUser com phone, GetUserLogged retorna phone
-
-### 6.4 Cenarios de Erro
-- [ ] Cenario: nenhum teste existente quebrado (regressao zero)
-
----
-
-## 7. Notas / Observacoes
-- Esta task e de validacao final — nao cria codigo novo
-- Se algum teste falhar, a correcao deve ser feita na task correspondente (T1-T5)
-- O objetivo e garantir integridade antes de considerar a feature completa
-
----
-
-## 8. Checklist Final
-- [ ] `make test` sem falhas
-- [ ] `make build` sem erros
-- [ ] Aceite tecnico atendido
-- [ ] Revisada
-- [ ] Integrada a branch principal
-
----
----
-
-# task_plan.md — Documento de Referencia
-
-# TASK PLAN -- Adicionar Telefone ao Modulo de Usuario
-
-## 1. Identificacao
-- **Feature/Projeto**: Adicionar Telefone ao Modulo de Usuario
-- **Responsavel (Tech Lead)**: —
-- **Data**: 2026-03-08
-- **Status**: Rascunho
-- **SPEC Relacionado**: docs/feature-telefone-usuario/v1/spec_tech.md (referencia inline no SPEC_TECH fornecido)
-- **PRD Relacionado**: docs/feature-telefone-usuario/v1/prd.md
-
----
-
-## 2. Objetivo do Task Plan
-Adicionar o campo `telefone` (opcional) ao modulo de usuario em todas as camadas da aplicacao: banco de dados, queries SQLC, repository, service (com validacao de 10-15 caracteres), proto e handler gRPC. Ao final, o campo telefone estara disponivel nos endpoints CreateUser, UpdateUser e GetUserLogged.
-
----
-
-## 3. Macro-Fases (alto nivel)
-- **Fase 1 -- Banco de Dados e Queries**
-  - Objetivo: Criar a infraestrutura de dados para suportar o campo telefone
-  - Tasks: T1, T2
-- **Fase 2 -- Camadas de Negocio (Repository + Service)**
-  - Objetivo: Integrar o campo telefone nas camadas de dominio com mapeamento e validacao
-  - Tasks: T3, T4
-- **Fase 3 -- Interface gRPC (Proto + Handler)**
-  - Objetivo: Expor o campo telefone via API gRPC
-  - Tasks: T5
-- **Fase 4 -- Testes e Validacao**
-  - Objetivo: Garantir integridade da feature e regressao zero
-  - Tasks: T6
-
----
-
-## 4. Lista de Tasks (visao macro)
-| ID  | Nome da Task | Arquivo | Fase | Dependencias | Pode Rodar em Paralelo? | Status |
-| --- | ------------ | ------- | ---- | ------------ | ----------------------- | ------ |
-| T1 | Criar migracao para adicionar coluna telefone | [T1](tasks/T1.md) | Fase 1 | Nenhuma | Sim (inicio) | A Fazer |
-| T2 | Atualizar queries SQLC para incluir coluna telefone | [T2](tasks/T2.md) | Fase 1 | T1 | Nao | A Fazer |
-| T3 | Adicionar campo Phone ao repository e atualizar mapeamento | [T3](tasks/T3.md) | Fase 2 | T2 | Nao | A Fazer |
-| T4 | Adicionar campo Phone ao service com validacao | [T4](tasks/T4.md) | Fase 2 | T3 | Nao | A Fazer |
-| T5 | Atualizar proto e handler gRPC para incluir campo phone | [T5](tasks/T5.md) | Fase 3 | T4 | Nao | A Fazer |
-| T6 | Validacao cruzada e testes end-to-end da feature completa | [T6](tasks/T6.md) | Fase 4 | T5 | Nao | A Fazer |
-
----
-
-## 5. Rastreabilidade: User Stories -> Tasks
-
-| User Story (PRD) | Definicao Tecnica (SPEC) | Tasks Relacionadas | Status |
-| ---------------- | ------------------------ | ------------------ | ------ |
-| US-10: Informar telefone para receber SMS | 3.1 Banco (migracao), 3.2 SQLC (queries), 3.3 Repository (campo Phone), 3.4 Service (validacao), 3.5 Handler (mapeamento), 3.6 Proto (campo phone) | T1, T2, T3, T4, T5, T6 | A Fazer |
-
-> Todas as user stories do SPEC_TECH foram decompostas em tasks.
-
----
-
-## 6. Dependencias Gerais
-
-- **Cadeia sequencial**: T1 -> T2 -> T3 -> T4 -> T5 -> T6
-- As tasks sao sequenciais pois cada camada depende da anterior (banco -> SQLC -> repository -> service -> handler)
-- **Ferramentas externas necessarias**: `buf` (proto), `sqlc` (queries) — devem estar instaladas
-- **Prerequisito**: `CGO_ENABLED=1` para compilacao (dependencia go-sqlite3)
-- Nao ha dependencia de tasks de outras features
-- Nao ha paralelismo possivel nesta feature (cadeia linear de dependencias por camada)
-
----
-
-## 7. Criterios de Conclusao da Feature
-A feature sera considerada concluida quando:
-- [x] Todas as tasks estiverem completas (T1-T6)
-- [ ] Testes validados (`make test` sem falhas)
-- [ ] Criterios tecnicos do SPEC atendidos (campo telefone opcional, validacao 10-15 chars)
-- [ ] Nenhum comportamento divergente do PRD
-- [ ] Todas as User Stories cobertas (US-10)
-- [ ] Build aprovado (`make build` sem erros)
-
----
-
-## 8. Riscos & Mitigacoes
-- **Risco**: Migracao SQLite com ALTER TABLE pode ter limitacoes -> **Mitigacao**: ALTER TABLE ADD COLUMN e suportado sem restricoes no SQLite
-- **Risco**: Campo `telefone` nullable gera `sql.NullString` no SQLC, adicionando complexidade -> **Mitigacao**: Funcoes helper `toNullString`/`fromNullString` encapsulam a conversao
-- **Risco**: Testes existentes quebram por mudanca na struct User -> **Mitigacao**: Campo `Phone` e ponteiro (`*string`), valor zero e nil, testes existentes nao precisam setar
-
----
-
-## 9. Checklist Final
-- [x] Task Plan completo
-- [x] Tasks mapeadas (T1-T6)
-- [x] Dependencias validadas (cadeia sequencial)
-- [x] Rastreabilidade User Stories -> Tasks preenchida (US-10 -> T1-T6)
-- [x] Pronto para execucao
-
----
-
-Arquivos que seriam salvos:
-- `docs/telefone-usuario/v1/task_plan.md`
-- `docs/telefone-usuario/v1/tasks/T1.md`
-- `docs/telefone-usuario/v1/tasks/T2.md`
-- `docs/telefone-usuario/v1/tasks/T3.md`
-- `docs/telefone-usuario/v1/tasks/T4.md`
-- `docs/telefone-usuario/v1/tasks/T5.md`
-- `docs/telefone-usuario/v1/tasks/T6.md`
-
-Task Plan aprovado para execucao? (sim/nao)