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/response.md

@@ -1,1126 +0,0 @@
-# Resposta Completa — TASK PLAN: Adicionar Telefone ao Usuario
-
-## Simulacao do Fluxo Interativo
-
----
-
-### Passo 1: Receber e ler o SPEC_TECH
-
-SPEC_TECH recebido e lido com sucesso.
-
-### Passo 2: Extrair nome da feature
-
-Nome extraido da secao "1. Identificacao", campo "Feature/Projeto": **Adicionar Telefone ao Modulo de Usuario**
-
-Nome em kebab-case: `telefone-usuario`
-Diretorio: `docs/telefone-usuario/v1/`
-
-### Passo 3: Confirmar nome
-
-> **Pergunta que seria feita 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 4: Analise obrigatoria do projeto
-
-**Analise realizada do codebase:**
-
-1. **Migracao existente:** `internal/db/migrations/001_create_usuarios.sql` — tabela `usuarios` com colunas `id`, `nome`, `email`, `senha_hash`, `data_criacao`, `data_atualizacao`. NAO possui coluna `telefone`.
-2. **Queries SQLC:** `internal/db/sqlc/queries/user.sql` — queries `CreateUser` e `GetUserByID`. NAO inclui `telefone`.
-3. **Repository:** `internal/repository/user_repository.go` — struct `User` com campos `ID`, `Name`, `Email`, `PasswordHash`, `CreatedAt`, `UpdatedAt`. NAO possui `Phone`. Interface `UserRepository` com metodos `Create` e `GetByID`.
-4. **Service:** `internal/service/user_service.go` — struct `CreateUserInput` com `Name`, `Email`, `Password`. NAO possui `Phone`. Interface `UserService` com `CreateUser` e `GetUser`. NAO possui `UpdateUser`.
-5. **Handler:** `internal/handler/grpc/user_handler.go` — handler com `CreateUser` e `GetUser`. NAO possui `UpdateUser`.
-6. **Proto:** `api/proto/v1/user.proto` — messages `CreateUserRequest`, `CreateUserResponse`, `GetUserRequest`, `GetUserResponse`. NAO possui `UpdateUser` nem campo `phone`.
-7. **Testes existentes:** `user_service_test.go` (table-driven, testify/mock) e `user_handler_test.go` (testify/mock, gRPC status codes).
-8. **Padrao de DI:** Uber FX modules em cada pacote, composicao em `internal/infra/di/fx.go`.
-9. **Servidor gRPC:** `internal/infra/grpc/server.go` — registra `UserServiceServer`.
-
-**Observacao critica:** O SPEC_TECH menciona "UpdateUser" mas o endpoint `UpdateUser` NAO existe atualmente no projeto. Isso significa que a feature precisa CRIAR o endpoint UpdateUser completo (proto, handler, service, repository, queries SQLC, migracao).
-
-### Passo 5: Propor macro-fases
-
-> **Pergunta que seria feita ao usuario:**
-> "Analisei o codebase e identifiquei que o endpoint UpdateUser NAO existe atualmente. O SPEC_TECH menciona atualizar CreateUser e UpdateUser para incluir telefone. Proponho as seguintes macro-fases:
->
-> - **Fase 1 -- Preparacao / Banco de Dados**: Migracao para adicionar coluna `telefone` e atualizacao das queries SQLC
-> - **Fase 2 -- Implementacao Backend**: Atualizar repository, service e criar UpdateUser completo (repository + service) com campo phone
-> - **Fase 3 -- Interface gRPC**: Atualizar proto, handler CreateUser e criar handler UpdateUser com campo phone
-> - **Fase 4 -- Testes e Validacao**: Atualizar testes existentes e criar novos testes para o campo phone e endpoint UpdateUser
->
-> Podemos seguir com estas fases?"
-
-> **Resposta simulada do usuario:** "Sim, pode seguir. O UpdateUser faz parte do escopo, pode criar do zero."
-
-### Passo 6: Destrinchar tasks
-
-> **Pergunta que seria feita ao usuario:**
-> "Podemos destrinchar as tasks da Fase 1?"
-
-> **Resposta simulada do usuario:** "Sim."
-
-Apos analise detalhada do codebase e do SPEC_TECH, as tasks foram definidas conforme abaixo.
-
----
-
-## TASK PLAN (documento de referencia)
-
----
-
-# TASK PLAN -- Plano de Execucao das Tasks
-
-## 1. Identificacao
-- **Feature/Projeto**: Adicionar Telefone ao Modulo de Usuario
-- **Responsavel (Tech Lead)**: N/A (definido pelo time)
-- **Data**: 2026-03-07
-- **Status**: Rascunho
-- **SPEC Relacionado**: docs/feature-telefone-usuario/v1/spec_tech.md (inline no prompt)
-- **PRD Relacionado**: docs/feature-telefone-usuario/v1/prd.md
-
----
-
-## 2. Objetivo do Task Plan
-Adicionar o campo opcional `telefone` a tabela `usuarios` no banco de dados SQLite, expor esse campo nos endpoints gRPC `CreateUser` e `GetUser`, e criar o endpoint completo `UpdateUser` com suporte ao campo `phone`. Ao final, o usuario podera informar, visualizar e atualizar seu telefone via API gRPC.
-
----
-
-## 3. Macro-Fases (alto nivel)
-- **Fase 1 -- Preparacao / Banco de Dados**
-  - Objetivo: Adicionar coluna `telefone` ao schema e atualizar queries SQLC
-  - Tasks: T1, T2
-- **Fase 2 -- Implementacao Backend**
-  - Objetivo: Atualizar repository e service para suportar campo phone e criar UpdateUser
-  - Tasks: T3, T4
-- **Fase 3 -- Interface gRPC**
-  - Objetivo: Atualizar proto e handlers para expor campo phone e endpoint UpdateUser
-  - Tasks: T5, T6
-- **Fase 4 -- Testes e Validacao**
-  - Objetivo: Atualizar testes existentes e criar novos testes
-  - Tasks: (testes incluidos em cada task individual)
-
----
-
-## 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) | 1    | Nenhuma      | Sim (com T5)            | A Fazer |
-| T2  | Atualizar queries SQLC para incluir telefone    | [T2](tasks/T2.md) | 1    | T1           | Nao                     | A Fazer |
-| T3  | Atualizar repository com campo Phone            | [T3](tasks/T3.md) | 2    | T2           | Nao                     | A Fazer |
-| T4  | Atualizar service com campo Phone e UpdateUser  | [T4](tasks/T4.md) | 2    | T3           | Nao                     | A Fazer |
-| T5  | Atualizar proto com campo phone e UpdateUser    | [T5](tasks/T5.md) | 3    | Nenhuma      | Sim (com T1)            | A Fazer |
-| T6  | Atualizar handler com campo phone e UpdateUser  | [T6](tasks/T6.md) | 3    | T4, T5       | Nao                     | A Fazer |
-
----
-
-## 5. Rastreabilidade: User Stories -> Tasks
-
-| User Story (PRD) | Definicao Tecnica (SPEC)                                              | Tasks Relacionadas | Status  |
-| ---------------- | --------------------------------------------------------------------- | ------------------ | ------- |
-| US-10            | 3.1 Banco de Dados: ALTER TABLE adicionar coluna telefone             | T1                 | A Fazer |
-| US-10            | 3.2 SQLC: Atualizar queries CreateUser e UpdateUser                   | T2                 | A Fazer |
-| US-10            | 3.3 Repository: Adicionar campo Phone ao modelo User                 | T3                 | A Fazer |
-| US-10            | 3.4 Service: Aceitar campo phone, validacao 10-15 caracteres          | T4                 | A Fazer |
-| US-10            | 3.5/3.6 Handler/Proto: Adicionar campo phone nas mensagens e UpdateUser | T5, T6             | A Fazer |
-
-> Esta tabela garante que TODAS as user stories do PRD tem tasks correspondentes para implementacao.
-
----
-
-## 6. Dependencias Gerais
-
-- T1 (migracao) e T5 (proto) podem rodar em paralelo pois sao independentes
-- T2 depende de T1 (queries precisam da coluna no schema)
-- T3 depende de T2 (repository usa codigo gerado pelo SQLC)
-- T4 depende de T3 (service depende do repository)
-- T6 depende de T4 e T5 (handler depende do service e do proto gerado)
-- Apos T2 e T5, e necessario executar `make generate` (buf + sqlc) para regenerar codigo
-
-**Grafo de dependencias:**
-```
-T1 --> T2 --> T3 --> T4 --\
-                           --> T6
-T5 ----------------------------/
-```
-
----
-
-## 7. Criterios de Conclusao da Feature
-A feature sera considerada concluida quando:
-- [x] Coluna `telefone` existe na tabela `usuarios`
-- [ ] Queries SQLC incluem `telefone` em CreateUser, UpdateUser e GetUserByID
-- [ ] Modelo `User` no repository possui campo `Phone`
-- [ ] Service aceita e valida campo `phone` (10-15 caracteres quando informado)
-- [ ] Endpoint CreateUser aceita campo `phone` opcional
-- [ ] Endpoint UpdateUser criado e funcional com campo `phone`
-- [ ] Campo `phone` retornado no GetUser
-- [ ] Todos os testes existentes atualizados e passando
-- [ ] Novos testes para validacao de telefone criados e passando
-- [ ] Nenhum comportamento divergente do PRD
-- [ ] Todas as User Stories cobertas (tabela secao 5)
-
----
-
-## 8. Riscos & Mitigacoes
-- **Risco 1**: Migracao ALTER TABLE em SQLite pode ter limitacoes → Mitigacao: `ALTER TABLE ADD COLUMN` e suportado normalmente no SQLite para adicionar colunas
-- **Risco 2**: Queries SQLC existentes podem quebrar apos adicionar coluna → Mitigacao: Usar `SELECT *` ja existente nas queries garante que a nova coluna sera retornada automaticamente
-- **Risco 3**: Testes existentes podem falhar se mock nao incluir campo Phone → Mitigacao: Atualizar mocks e assertions em cada task que modifica interfaces
-
----
-
-## 9. Checklist Final
-- [x] Task Plan completo
-- [x] Tasks mapeadas
-- [x] Dependencias validadas
-- [x] Rastreabilidade User Stories -> Tasks preenchida
-- [x] Pronto para execucao paralela
-
----
----
-
-## TASKS INDIVIDUAIS
-
----
-
-# T1 -- Criar migracao para adicionar coluna telefone
-
-## 1. Identificacao
-- **ID**: T1
-- **Nome da Task**: Criar migracao para adicionar coluna telefone
-- **Responsavel**: N/A
-- **Status**: A Fazer
-- **Fase**: 1 -- Preparacao / Banco de Dados
-- **Dependencias**: Nenhuma
-- **User Stories Relacionadas**: US-10
-
----
-
-## 2. Objetivo da Task
-Criar arquivo de migracao SQL que adiciona a coluna `telefone` (TEXT, opcional) a tabela `usuarios`.
-
----
-
-## 3. Descricao Detalhada
-Criar um novo arquivo de migracao seguindo a convencao de nomenclatura do projeto:
-
-1. **Arquivo**: `internal/db/migrations/002_add_telefone_usuarios.sql`
-2. **Conteudo**: Instrucao `ALTER TABLE usuarios ADD COLUMN telefone TEXT;`
-3. A coluna e opcional (sem `NOT NULL`), pois o telefone nao e obrigatorio
-4. NAO editar a migracao existente `001_create_usuarios.sql` (regra de imutabilidade de migracoes)
-5. A migracao sera executada automaticamente no boot da aplicacao via golang-migrate
-
-**Observacao**: O projeto usa apenas migracoes `.sql` (sem separacao up/down em arquivos distintos com base no que existe). Seguir o mesmo padrao da migracao `001_create_usuarios.sql`.
-
----
-
-## 4. Aceite Tecnico (criterios objetivos)
-A task estara concluida quando:
-- [ ] Arquivo `002_add_telefone_usuarios.sql` criado em `internal/db/migrations/`
-- [ ] SQL contem `ALTER TABLE usuarios ADD COLUMN telefone TEXT;`
-- [ ] Coluna e opcional (sem NOT NULL)
-- [ ] Migracao 001 NAO foi editada
-- [ ] Nenhuma quebra nos fluxos existentes
-
----
-
-## 5. Arquivos Impactados
-
-### 5.1 Arquivos a Criar
-| Arquivo | Descricao |
-|---------|-----------|
-| `internal/db/migrations/002_add_telefone_usuarios.sql` | Migracao para adicionar coluna telefone |
-
-### 5.2 Arquivos a Modificar
-| Arquivo | Modificacao |
-|---------|------------|
-| Nenhum | N/A |
-
-### 5.3 Arquivos de Referencia
-| Arquivo | Motivo da Consulta |
-|---------|-------------------|
-| `internal/db/migrations/001_create_usuarios.sql` | Referencia de padrao de migracao existente |
-
----
-
-## 6. Testes
-
-### 6.1 Testes Unitarios
-N/A -- migracao SQL nao possui testes unitarios isolados.
-
-### 6.2 Testes de Integracao
-- [ ] Teste: Verificar que a migracao aplica corretamente e a coluna `telefone` existe na tabela `usuarios` apos execucao
-- [ ] Teste: Verificar que registros existentes na tabela `usuarios` continuam acessiveis apos a migracao (coluna `telefone` com valor NULL)
-
-### 6.3 Testes E2E
-N/A -- validacao sera feita indiretamente pelos testes das camadas superiores.
-
-### 6.4 Cenarios de Erro
-- [ ] Cenario: Migracao re-executada nao causa erro (idempotencia — verificar comportamento do golang-migrate)
-
----
-
-## 7. Notas / Observacoes
-- SQLite suporta `ALTER TABLE ADD COLUMN` normalmente
-- A coluna sera NULL para usuarios existentes, o que e o comportamento desejado (campo opcional)
-- O projeto usa um unico arquivo `.sql` por migracao (nao separa up/down em arquivos distintos), conforme padrao observado em `001_create_usuarios.sql`
-
----
-
-## 8. Checklist Final
-- [ ] Implementada conforme SPEC
-- [ ] Testes unitarios criados/atualizados
-- [ ] Testes de integracao criados/atualizados
-- [ ] Aceite tecnico atendido
-- [ ] Revisada
-- [ ] Integrada a branch principal
-
----
----
-
-# T2 -- Atualizar queries SQLC para incluir telefone
-
-## 1. Identificacao
-- **ID**: T2
-- **Nome da Task**: Atualizar queries SQLC para incluir telefone
-- **Responsavel**: N/A
-- **Status**: A Fazer
-- **Fase**: 1 -- Preparacao / Banco de Dados
-- **Dependencias**: T1
-- **User Stories Relacionadas**: US-10
-
----
-
-## 2. Objetivo da Task
-Atualizar as queries SQLC existentes para incluir a coluna `telefone` e criar a nova query `UpdateUser`. Apos editar, executar `make generate` para regenerar o codigo Go.
-
----
-
-## 3. Descricao Detalhada
-
-### 3.1 Atualizar query `CreateUser`
-No arquivo `internal/db/sqlc/queries/user.sql`, modificar a query `CreateUser` para incluir a coluna `telefone`:
-
-```sql
--- name: CreateUser :one
-INSERT INTO usuarios (id, nome, email, senha_hash, telefone, data_criacao, data_atualizacao)
-VALUES (?, ?, ?, ?, ?, ?, ?)
-RETURNING *;
-```
-
-### 3.2 Criar query `UpdateUser`
-Adicionar nova query `UpdateUser` ao arquivo `internal/db/sqlc/queries/user.sql`:
-
-```sql
--- name: UpdateUser :one
-UPDATE usuarios SET nome = ?, email = ?, telefone = ?, data_atualizacao = ?
-WHERE id = ?
-RETURNING *;
-```
-
-### 3.3 Query `GetUserByID`
-A query `GetUserByID` usa `SELECT *`, portanto ja retornara automaticamente a coluna `telefone`. NAO precisa ser alterada.
-
-### 3.4 Regenerar codigo
-Executar `make generate` (ou `sqlc generate` dentro de `internal/db/sqlc/`) para regenerar os arquivos Go em `internal/db/sqlc/`.
-
----
-
-## 4. Aceite Tecnico (criterios objetivos)
-A task estara concluida quando:
-- [ ] Query `CreateUser` inclui coluna `telefone`
-- [ ] Query `UpdateUser` criada com colunas `nome`, `email`, `telefone`, `data_atualizacao` e filtro por `id`
-- [ ] Query `GetUserByID` mantida inalterada (ja usa SELECT *)
-- [ ] `make generate` executado com sucesso
-- [ ] Codigo gerado em `internal/db/sqlc/` reflete as novas queries
-- [ ] Struct `CreateUserParams` gerada inclui campo `Telefone`
-- [ ] Struct `UpdateUserParams` gerada existe com campos corretos
-- [ ] Struct `Usuario` gerada inclui campo `Telefone`
-
----
-
-## 5. Arquivos Impactados
-
-### 5.1 Arquivos a Criar
-| Arquivo | Descricao |
-|---------|-----------|
-| Nenhum | N/A |
-
-### 5.2 Arquivos a Modificar
-| Arquivo | Modificacao |
-|---------|------------|
-| `internal/db/sqlc/queries/user.sql` | Adicionar coluna `telefone` ao CreateUser e criar query UpdateUser |
-
-### 5.3 Arquivos de Referencia
-| Arquivo | Motivo da Consulta |
-|---------|-------------------|
-| `internal/db/sqlc/sqlc.yaml` | Configuracao do SQLC para verificar engine e paths |
-| `internal/db/migrations/002_add_telefone_usuarios.sql` | Schema atualizado com coluna telefone |
-
----
-
-## 6. Testes
-
-### 6.1 Testes Unitarios
-N/A -- queries SQLC sao validadas na geracao e testadas via integracao.
-
-### 6.2 Testes de Integracao
-- [ ] Teste: Query `CreateUser` com campo `telefone` preenchido insere registro corretamente e retorna todos os campos incluindo `telefone`
-- [ ] Teste: Query `CreateUser` com campo `telefone` vazio (NULL) insere registro corretamente
-- [ ] Teste: Query `UpdateUser` atualiza `nome`, `email`, `telefone` e `data_atualizacao` corretamente
-- [ ] Teste: Query `UpdateUser` com `telefone` NULL atualiza corretamente
-- [ ] Teste: Query `GetUserByID` retorna campo `telefone` corretamente
-
-### 6.3 Testes E2E
-N/A -- coberto pelos testes de integracao e camadas superiores.
-
-### 6.4 Cenarios de Erro
-- [ ] Cenario: `UpdateUser` com ID inexistente retorna erro (sql.ErrNoRows)
-
----
-
-## 7. Notas / Observacoes
-- NAO editar arquivos em `internal/db/sqlc/` diretamente (sao gerados)
-- Apenas editar `internal/db/sqlc/queries/user.sql`
-- Apos editar, obrigatoriamente rodar `make generate`
-- O campo `telefone` no SQLite sera do tipo `sql.NullString` no codigo gerado (por ser nullable)
-
----
-
-## 8. Checklist Final
-- [ ] Implementada conforme SPEC
-- [ ] Testes unitarios criados/atualizados
-- [ ] Testes de integracao criados/atualizados
-- [ ] Aceite tecnico atendido
-- [ ] Revisada
-- [ ] Integrada a branch principal
-
----
----
-
-# T3 -- Atualizar repository com campo Phone e metodo Update
-
-## 1. Identificacao
-- **ID**: T3
-- **Nome da Task**: Atualizar repository com campo Phone e metodo Update
-- **Responsavel**: N/A
-- **Status**: A Fazer
-- **Fase**: 2 -- Implementacao Backend
-- **Dependencias**: T2
-- **User Stories Relacionadas**: US-10
-
----
-
-## 2. Objetivo da Task
-Adicionar campo `Phone` ao modelo `User` do repository, atualizar o mapeamento SQLC, adicionar metodo `Update` a interface `UserRepository` e implementa-lo.
-
----
-
-## 3. Descricao Detalhada
-
-### 3.1 Atualizar struct `User`
-Em `internal/repository/user_repository.go`, adicionar campo `Phone` a struct `User`:
-
-```go
-type User struct {
-    ID           string
-    Name         string
-    Email        string
-    PasswordHash string
-    Phone        string    // mapeado de 'telefone' no banco
-    CreatedAt    time.Time
-    UpdatedAt    time.Time
-}
-```
-
-### 3.2 Atualizar interface `UserRepository`
-Adicionar metodo `Update` a 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)
-}
-```
-
-### 3.3 Atualizar metodo `Create`
-Incluir campo `Telefone` nos params do SQLC:
-
-```go
-params := sqlc.CreateUserParams{
-    // ... campos existentes ...
-    Telefone: sql.NullString{String: user.Phone, Valid: user.Phone != ""},
-}
-```
-
-### 3.4 Implementar metodo `Update`
-Criar metodo `Update` na struct `sqlcUserRepository`:
-
-```go
-func (r *sqlcUserRepository) Update(ctx context.Context, user *User) (*User, error) {
-    params := sqlc.UpdateUserParams{
-        Nome:            user.Name,
-        Email:           user.Email,
-        Telefone:        sql.NullString{String: user.Phone, Valid: user.Phone != ""},
-        DataAtualizacao: user.UpdatedAt,
-        ID:              user.ID,
-    }
-    row, err := r.queries.UpdateUser(ctx, params)
-    if err != nil {
-        if err == sql.ErrNoRows {
-            return nil, fmt.Errorf("repository: usuario com id %q nao encontrado", user.ID)
-        }
-        return nil, fmt.Errorf("repository: falha ao atualizar usuario: %w", err)
-    }
-    return toUser(row), nil
-}
-```
-
-### 3.5 Atualizar funcao `toUser`
-Incluir mapeamento do campo `Telefone`:
-
-```go
-func toUser(u sqlc.Usuario) *User {
-    return &User{
-        // ... campos existentes ...
-        Phone: u.Telefone.String, // NullString -> string
-    }
-}
-```
-
----
-
-## 4. Aceite Tecnico (criterios objetivos)
-A task estara concluida quando:
-- [ ] Struct `User` possui campo `Phone string`
-- [ ] Interface `UserRepository` possui metodo `Update(ctx, *User) (*User, error)`
-- [ ] Metodo `Create` envia campo `Telefone` ao SQLC
-- [ ] Metodo `Update` implementado com mapeamento correto
-- [ ] Funcao `toUser` mapeia `Telefone` -> `Phone`
-- [ ] Tratamento de `sql.NullString` para campo nullable
-- [ ] Erros encapsulados com mensagens em portugues
-- [ ] Nenhuma quebra nos fluxos existentes
-
----
-
-## 5. Arquivos Impactados
-
-### 5.1 Arquivos a Criar
-| Arquivo | Descricao |
-|---------|-----------|
-| Nenhum | N/A |
-
-### 5.2 Arquivos a Modificar
-| Arquivo | Modificacao |
-|---------|------------|
-| `internal/repository/user_repository.go` | Adicionar campo Phone ao User, metodo Update a interface e implementacao, atualizar Create e toUser |
-
-### 5.3 Arquivos de Referencia
-| Arquivo | Motivo da Consulta |
-|---------|-------------------|
-| `internal/db/sqlc/` (codigo gerado) | Verificar structs e metodos gerados pelo SQLC |
-
----
-
-## 6. Testes
-
-### 6.1 Testes Unitarios
-N/A -- repository e testado via integracao (depende do banco).
-
-### 6.2 Testes de Integracao
-- [ ] Teste: `Create` com campo `Phone` preenchido persiste e retorna corretamente
-- [ ] Teste: `Create` com campo `Phone` vazio persiste com `telefone` NULL no banco
-- [ ] Teste: `Update` com campo `Phone` preenchido atualiza e retorna corretamente
-- [ ] Teste: `Update` com campo `Phone` vazio (limpar telefone) atualiza corretamente
-- [ ] Teste: `GetByID` retorna campo `Phone` corretamente
-- [ ] Teste: `Update` com ID inexistente retorna erro "usuario nao encontrado"
-
-### 6.3 Testes E2E
-N/A -- coberto pelos testes de integracao e testes do service.
-
-### 6.4 Cenarios de Erro
-- [ ] Cenario: `Update` com ID inexistente retorna erro adequado
-- [ ] Cenario: `Update` com email duplicado retorna erro de constraint
-
----
-
-## 7. Notas / Observacoes
-- O campo `telefone` no banco e nullable, portanto usar `sql.NullString` nos params SQLC
-- Na conversao de volta (`toUser`), converter `NullString.String` para string simples (vazio se NULL)
-- O import de `database/sql` ja existe no arquivo
-
----
-
-## 8. Checklist Final
-- [ ] Implementada conforme SPEC
-- [ ] Testes unitarios criados/atualizados
-- [ ] Testes de integracao criados/atualizados
-- [ ] Aceite tecnico atendido
-- [ ] Revisada
-- [ ] Integrada a branch principal
-
----
----
-
-# T4 -- Atualizar service com campo Phone, validacao e UpdateUser
-
-## 1. Identificacao
-- **ID**: T4
-- **Nome da Task**: Atualizar service com campo Phone, validacao e UpdateUser
-- **Responsavel**: N/A
-- **Status**: A Fazer
-- **Fase**: 2 -- Implementacao Backend
-- **Dependencias**: T3
-- **User Stories Relacionadas**: US-10
-
----
-
-## 2. Objetivo da Task
-Adicionar campo `Phone` ao `CreateUserInput`, criar `UpdateUserInput`, adicionar metodo `UpdateUser` a interface `UserService`, implementar validacao de telefone (10-15 caracteres quando informado) e implementar o metodo `UpdateUser`.
-
----
-
-## 3. Descricao Detalhada
-
-### 3.1 Atualizar `CreateUserInput`
-Adicionar campo `Phone` ao input de criacao:
-
-```go
-type CreateUserInput struct {
-    Name     string
-    Email    string
-    Password string
-    Phone    string // opcional
-}
-```
-
-### 3.2 Criar `UpdateUserInput`
-Criar nova struct de input para atualizacao:
-
-```go
-type UpdateUserInput struct {
-    ID    string
-    Name  string
-    Email string
-    Phone string // opcional
-}
-```
-
-### 3.3 Criar variavel de erro para telefone
-```go
-var ErrInvalidPhone = errors.New("telefone deve ter entre 10 e 15 caracteres")
-```
-
-### 3.4 Atualizar interface `UserService`
-Adicionar metodo `UpdateUser`:
-
-```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)
-}
-```
-
-### 3.5 Atualizar metodo `CreateUser`
-Adicionar validacao de telefone e passar campo Phone ao repository:
-
-```go
-func (s *userServiceImpl) CreateUser(ctx context.Context, input CreateUserInput) (*repository.User, error) {
-    // ... validacoes existentes ...
-
-    // Validacao de telefone (opcional)
-    if input.Phone != "" {
-        if len(input.Phone) < 10 || len(input.Phone) > 15 {
-            return nil, ErrInvalidPhone
-        }
-    }
-
-    // ... hash de senha ...
-
-    user := &repository.User{
-        // ... campos existentes ...
-        Phone: input.Phone,
-    }
-    return s.repo.Create(ctx, user)
-}
-```
-
-### 3.6 Implementar metodo `UpdateUser`
-```go
-func (s *userServiceImpl) UpdateUser(ctx context.Context, input UpdateUserInput) (*repository.User, error) {
-    if input.ID == "" {
-        return nil, errors.New("id e obrigatorio")
-    }
-    if input.Name == "" {
-        return nil, errors.New("nome e obrigatorio")
-    }
-    if input.Email == "" {
-        return nil, errors.New("email e obrigatorio")
-    }
-    if input.Phone != "" {
-        if len(input.Phone) < 10 || len(input.Phone) > 15 {
-            return nil, ErrInvalidPhone
-        }
-    }
-
-    now := time.Now()
-    user := &repository.User{
-        ID:        input.ID,
-        Name:      input.Name,
-        Email:     input.Email,
-        Phone:     input.Phone,
-        UpdatedAt: now,
-    }
-    return s.repo.Update(ctx, user)
-}
-```
-
----
-
-## 4. Aceite Tecnico (criterios objetivos)
-A task estara concluida quando:
-- [ ] `CreateUserInput` possui campo `Phone`
-- [ ] `UpdateUserInput` criado com campos `ID`, `Name`, `Email`, `Phone`
-- [ ] Interface `UserService` possui metodo `UpdateUser`
-- [ ] Validacao de telefone: se informado, entre 10 e 15 caracteres
-- [ ] Validacao de telefone: se vazio, aceito sem erro (campo opcional)
-- [ ] `ErrInvalidPhone` definido como variavel de erro exportada
-- [ ] `CreateUser` passa campo `Phone` ao repository
-- [ ] `UpdateUser` implementado com validacoes de nome, email, id e phone
-- [ ] Erros com mensagens em portugues
-- [ ] Nenhuma quebra nos fluxos existentes
-
----
-
-## 5. Arquivos Impactados
-
-### 5.1 Arquivos a Criar
-| Arquivo | Descricao |
-|---------|-----------|
-| Nenhum | N/A |
-
-### 5.2 Arquivos a Modificar
-| Arquivo | Modificacao |
-|---------|------------|
-| `internal/service/user_service.go` | Adicionar Phone ao CreateUserInput, criar UpdateUserInput, UpdateUser, validacao de telefone |
-
-### 5.3 Arquivos de Referencia
-| Arquivo | Motivo da Consulta |
-|---------|-------------------|
-| `internal/repository/user_repository.go` | Interface UserRepository e struct User atualizadas |
-
----
-
-## 6. Testes
-
-### 6.1 Testes Unitarios
-- [ ] Teste: `CreateUser` com phone valido (10 caracteres) cria usuario com sucesso
-- [ ] Teste: `CreateUser` com phone valido (15 caracteres) cria usuario com sucesso
-- [ ] Teste: `CreateUser` com phone vazio cria usuario com sucesso (campo opcional)
-- [ ] Teste: `CreateUser` com phone invalido (9 caracteres) retorna `ErrInvalidPhone`
-- [ ] Teste: `CreateUser` com phone invalido (16 caracteres) retorna `ErrInvalidPhone`
-- [ ] Teste: `UpdateUser` com dados validos atualiza usuario com sucesso
-- [ ] Teste: `UpdateUser` com phone valido atualiza com sucesso
-- [ ] Teste: `UpdateUser` com phone vazio atualiza com sucesso
-- [ ] Teste: `UpdateUser` com phone invalido retorna `ErrInvalidPhone`
-- [ ] Teste: `UpdateUser` com ID vazio retorna erro
-- [ ] Teste: `UpdateUser` com nome vazio retorna erro
-- [ ] Teste: `UpdateUser` com email vazio retorna erro
-- [ ] Teste: `UpdateUser` com erro do repository propaga erro
-
-### 6.2 Testes de Integracao
-N/A -- service e testado com mocks do repository (unitarios).
-
-### 6.3 Testes E2E
-N/A -- coberto pelos testes do handler.
-
-### 6.4 Cenarios de Erro
-- [ ] Cenario: Validacao de telefone com caracteres no limite inferior (10) e superior (15) -- boundary test
-- [ ] Cenario: Repository retorna erro na atualizacao (ex: usuario nao encontrado)
-
-### Testes existentes a modificar
-| Arquivo | Modificacao |
-|---------|------------|
-| `internal/service/user_service_test.go` | Atualizar mock `MockUserRepository` para incluir metodo `Update`. Atualizar testes de `CreateUser` para incluir campo `Phone` no `CreateUserInput`. Adicionar novos testes para `UpdateUser` e validacao de telefone. |
-
----
-
-## 7. Notas / Observacoes
-- O mock `MockUserRepository` no arquivo de testes precisa ser atualizado para incluir o metodo `Update`
-- Os testes existentes de `CreateUser` continuam validos, pois `Phone` e opcional (zero value "" e aceito)
-- Padrao table-driven deve ser usado para testes de validacao de telefone (conforme padrao existente)
-
----
-
-## 8. Checklist Final
-- [ ] Implementada conforme SPEC
-- [ ] Testes unitarios criados/atualizados
-- [ ] Testes de integracao criados/atualizados
-- [ ] Aceite tecnico atendido
-- [ ] Revisada
-- [ ] Integrada a branch principal
-
----
----
-
-# T5 -- Atualizar proto com campo phone e endpoint UpdateUser
-
-## 1. Identificacao
-- **ID**: T5
-- **Nome da Task**: Atualizar proto com campo phone e endpoint UpdateUser
-- **Responsavel**: N/A
-- **Status**: A Fazer
-- **Fase**: 3 -- Interface gRPC
-- **Dependencias**: Nenhuma
-- **User Stories Relacionadas**: US-10
-
----
-
-## 2. Objetivo da Task
-Atualizar o arquivo `api/proto/v1/user.proto` para adicionar campo `phone` nas mensagens existentes, criar mensagens `UpdateUserRequest`/`UpdateUserResponse` e adicionar RPC `UpdateUser` ao service. Executar `make generate` para regenerar codigo.
-
----
-
-## 3. Descricao Detalhada
-
-### 3.1 Adicionar campo `phone` ao `CreateUserRequest`
-```proto
-message CreateUserRequest {
-  string name = 1;
-  string email = 2;
-  string password = 3;
-  string phone = 4;  // opcional
-}
-```
-
-### 3.2 Adicionar campo `phone` ao `CreateUserResponse`
-```proto
-message CreateUserResponse {
-  string id = 1;
-  string name = 2;
-  string email = 3;
-  string created_at = 4;
-  string phone = 5;
-}
-```
-
-### 3.3 Adicionar campo `phone` ao `GetUserResponse`
-```proto
-message GetUserResponse {
-  string id = 1;
-  string name = 2;
-  string email = 3;
-  string created_at = 4;
-  string updated_at = 5;
-  string phone = 6;
-}
-```
-
-### 3.4 Criar mensagens `UpdateUserRequest` e `UpdateUserResponse`
-```proto
-message UpdateUserRequest {
-  string id = 1;
-  string name = 2;
-  string email = 3;
-  string phone = 4;
-}
-
-message UpdateUserResponse {
-  string id = 1;
-  string name = 2;
-  string email = 3;
-  string phone = 4;
-  string created_at = 5;
-  string updated_at = 6;
-}
-```
-
-### 3.5 Adicionar RPC `UpdateUser` ao service
-```proto
-service UserService {
-  rpc CreateUser(CreateUserRequest) returns (CreateUserResponse);
-  rpc GetUser(GetUserRequest) returns (GetUserResponse);
-  rpc UpdateUser(UpdateUserRequest) returns (UpdateUserResponse);
-}
-```
-
-### 3.6 Regenerar codigo
-Executar `make generate` (buf generate) para regenerar `gen/proto/v1/`.
-
----
-
-## 4. Aceite Tecnico (criterios objetivos)
-A task estara concluida quando:
-- [ ] Campo `phone` adicionado a `CreateUserRequest` (field number 4)
-- [ ] Campo `phone` adicionado a `CreateUserResponse` (field number 5)
-- [ ] Campo `phone` adicionado a `GetUserResponse` (field number 6)
-- [ ] Mensagens `UpdateUserRequest` e `UpdateUserResponse` criadas
-- [ ] RPC `UpdateUser` adicionado ao `UserService`
-- [ ] `make generate` executado com sucesso
-- [ ] Codigo gerado em `gen/proto/v1/` reflete as novas mensagens e RPC
-- [ ] Numeracao de campos nao reutiliza numeros existentes
-
----
-
-## 5. Arquivos Impactados
-
-### 5.1 Arquivos a Criar
-| Arquivo | Descricao |
-|---------|-----------|
-| Nenhum | N/A |
-
-### 5.2 Arquivos a Modificar
-| Arquivo | Modificacao |
-|---------|------------|
-| `api/proto/v1/user.proto` | Adicionar campo phone em messages existentes, criar UpdateUser request/response, adicionar RPC UpdateUser |
-
-### 5.3 Arquivos de Referencia
-| Arquivo | Motivo da Consulta |
-|---------|-------------------|
-| `buf.yaml` | Verificar regras de lint |
-| `buf.gen.yaml` | Verificar plugins de geracao |
-
----
-
-## 6. Testes
-
-### 6.1 Testes Unitarios
-N/A -- arquivo proto nao possui testes unitarios. Validacao e feita pelo buf lint.
-
-### 6.2 Testes de Integracao
-N/A -- coberto pelos testes do handler.
-
-### 6.3 Testes E2E
-N/A -- coberto pelos testes do handler.
-
-### 6.4 Cenarios de Erro
-- [ ] Cenario: `buf lint` passa sem erros apos modificacoes
-- [ ] Cenario: `make generate` compila sem erros
-
----
-
-## 7. Notas / Observacoes
-- Esta task pode rodar em paralelo com T1 (sao independentes)
-- NAO editar arquivos em `gen/` diretamente
-- Apenas editar `api/proto/v1/user.proto`
-- Apos editar, obrigatoriamente rodar `make generate`
-- Field numbers novos devem seguir sequencia existente sem reutilizar numeros
-
----
-
-## 8. Checklist Final
-- [ ] Implementada conforme SPEC
-- [ ] Testes unitarios criados/atualizados
-- [ ] Testes de integracao criados/atualizados
-- [ ] Aceite tecnico atendido
-- [ ] Revisada
-- [ ] Integrada a branch principal
-
----
----
-
-# T6 -- Atualizar handler com campo phone e endpoint UpdateUser
-
-## 1. Identificacao
-- **ID**: T6
-- **Nome da Task**: Atualizar handler com campo phone e endpoint UpdateUser
-- **Responsavel**: N/A
-- **Status**: A Fazer
-- **Fase**: 3 -- Interface gRPC
-- **Dependencias**: T4, T5
-- **User Stories Relacionadas**: US-10
-
----
-
-## 2. Objetivo da Task
-Atualizar o handler gRPC `CreateUser` para incluir campo `phone`, implementar handler `UpdateUser`, atualizar `GetUser` para retornar `phone`, e atualizar o mapeamento de erros para incluir validacao de telefone. Registrar o endpoint `UpdateUser` no servidor gRPC.
-
----
-
-## 3. Descricao Detalhada
-
-### 3.1 Atualizar handler `CreateUser`
-Em `internal/handler/grpc/user_handler.go`, incluir campo `Phone` no input e na response:
-
-```go
-func (h *UserHandler) CreateUser(ctx context.Context, req *pb.CreateUserRequest) (*pb.CreateUserResponse, error) {
-    input := service.CreateUserInput{
-        Name:     req.GetName(),
-        Email:    req.GetEmail(),
-        Password: req.GetPassword(),
-        Phone:    req.GetPhone(),
-    }
-    user, err := h.userService.CreateUser(ctx, input)
-    if err != nil {
-        return nil, mapServiceError(err)
-    }
-    return &pb.CreateUserResponse{
-        Id:        user.ID,
-        Name:      user.Name,
-        Email:     user.Email,
-        Phone:     user.Phone,
-        CreatedAt: user.CreatedAt.Format(time.RFC3339),
-    }, nil
-}
-```
-
-### 3.2 Atualizar handler `GetUser`
-Incluir campo `Phone` na response:
-
-```go
-return &pb.GetUserResponse{
-    // ... campos existentes ...
-    Phone: user.Phone,
-}, nil
-```
-
-### 3.3 Implementar handler `UpdateUser`
-```go
-func (h *UserHandler) UpdateUser(ctx context.Context, req *pb.UpdateUserRequest) (*pb.UpdateUserResponse, error) {
-    input := service.UpdateUserInput{
-        ID:    req.GetId(),
-        Name:  req.GetName(),
-        Email: req.GetEmail(),
-        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,
-        CreatedAt: user.CreatedAt.Format(time.RFC3339),
-        UpdatedAt: user.UpdatedAt.Format(time.RFC3339),
-    }, nil
-}
-```
-
-### 3.4 Atualizar `mapServiceError`
-Adicionar mapeamento para erro de telefone invalido (ja coberto pelo pattern "obrigatorio" existente, mas verificar se "deve ter entre" precisa de tratamento):
-
-O erro `ErrInvalidPhone` ("telefone deve ter entre 10 e 15 caracteres") deve ser mapeado para `codes.InvalidArgument`. Verificar se o pattern existente no `mapServiceError` cobre este caso. Se nao cobrir, adicionar verificacao.
-
-### 3.5 Configurar autenticacao
-Se `UpdateUser` deve ser protegido (requer autenticacao), NAO adicionar a `skip_methods` em `configs/config.yaml`. Se deve ser publico, adicionar. Conforme o SPEC_TECH, nao ha indicacao de que deva ser publico, entao sera protegido por padrao.
-
----
-
-## 4. Aceite Tecnico (criterios objetivos)
-A task estara concluida quando:
-- [ ] Handler `CreateUser` passa campo `Phone` ao service e retorna na response
-- [ ] Handler `GetUser` retorna campo `Phone` na response
-- [ ] Handler `UpdateUser` implementado e funcional
-- [ ] Mapeamento de erros atualizado para erro de telefone invalido
-- [ ] Nenhuma quebra nos fluxos existentes
-- [ ] Handler compila corretamente contra o proto gerado
-
----
-
-## 5. Arquivos Impactados
-
-### 5.1 Arquivos a Criar
-| Arquivo | Descricao |
-|---------|-----------|
-| Nenhum | N/A |
-
-### 5.2 Arquivos a Modificar
-| Arquivo | Modificacao |
-|---------|------------|
-| `internal/handler/grpc/user_handler.go` | Atualizar CreateUser, GetUser e criar UpdateUser com campo phone. Atualizar mapServiceError. |
-
-### 5.3 Arquivos de Referencia
-| Arquivo | Motivo da Consulta |
-|---------|-------------------|
-| `gen/proto/v1/` (codigo gerado) | Verificar interfaces e structs geradas pelo proto |
-| `internal/service/user_service.go` | Interface UserService atualizada |
-| `configs/config.yaml` | Verificar skip_methods para autenticacao |
-
----
-
-## 6. Testes
-
-### 6.1 Testes Unitarios
-- [ ] Teste: `CreateUser` com phone valido retorna response com campo phone preenchido
-- [ ] Teste: `CreateUser` com phone vazio retorna response com phone vazio
-- [ ] Teste: `CreateUser` com phone invalido retorna `codes.InvalidArgument`
-- [ ] Teste: `GetUser` retorna campo phone na response
-- [ ] Teste: `UpdateUser` com dados validos retorna response correta
-- [ ] Teste: `UpdateUser` com phone valido retorna response com phone preenchido
-- [ ] Teste: `UpdateUser` com phone vazio retorna response com phone vazio
-- [ ] Teste: `UpdateUser` com phone invalido retorna `codes.InvalidArgument`
-- [ ] Teste: `UpdateUser` com ID vazio retorna `codes.InvalidArgument`
-- [ ] Teste: `UpdateUser` com usuario nao encontrado retorna `codes.NotFound`
-- [ ] Teste: `UpdateUser` com erro interno retorna `codes.Internal`
-- [ ] Teste: `UpdateUser` mapeamento de response (todos os campos corretos)
-
-### 6.2 Testes de Integracao
-N/A -- handler e testado com mocks do service (unitarios).
-
-### 6.3 Testes E2E
-N/A -- para esta feature simples, os testes unitarios do handler cobrem o fluxo completo.
-
-### 6.4 Cenarios de Erro
-- [ ] Cenario: Erro de validacao de telefone mapeado corretamente para `codes.InvalidArgument`
-- [ ] Cenario: Erro "nao encontrado" do service mapeado para `codes.NotFound`
-- [ ] Cenario: Erro generico do service mapeado para `codes.Internal`
-
-### Testes existentes a modificar
-| Arquivo | Modificacao |
-|---------|------------|
-| `internal/handler/grpc/user_handler_test.go` | Atualizar mock `MockUserService` para incluir metodo `UpdateUser`. Atualizar testes de `CreateUser` para validar campo `Phone` na response. Atualizar testes de `GetUser` para validar campo `Phone` na response. Adicionar novos testes para handler `UpdateUser`. |
-
----
-
-## 7. Notas / Observacoes
-- O mock `MockUserService` no arquivo de testes precisa ser atualizado para incluir o metodo `UpdateUser`
-- Os testes existentes de `CreateUser` e `GetUser` precisam ser atualizados para incluir assertions do campo `Phone`
-- O handler `UserHandler` ja implementa `UnimplementedUserServiceServer`, entao `UpdateUser` sera automaticamente parte da interface apos regenerar o proto
-- Verificar se `mapServiceError` cobre o novo erro de telefone invalido
-
----
-
-## 8. Checklist Final
-- [ ] Implementada conforme SPEC
-- [ ] Testes unitarios criados/atualizados
-- [ ] Testes de integracao criados/atualizados
-- [ ] Aceite tecnico atendido
-- [ ] Revisada
-- [ ] Integrada a branch principal
-
----
----
-
-## Resumo Final
-
-### Arquivos que seriam salvos (simulacao -- nao salvos em docs/ conforme instrucoes do eval):
-```
-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
-```
-
-### Ordem de execucao recomendada:
-```
-Paralelo: T1 + T5
-         |
-         v
-       T2 (apos T1)
-         |
-         v
-       T3 (apos T2)
-         |
-         v
-       T4 (apos T3)
-         |
-         v
-       T6 (apos T4 + T5)
-```
-
-Task Plan aprovado para execucao? (sim/nao)