adi_dev_workflow 1.0.0 → 1.1.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "adi_dev_workflow",
-  "version": "1.0.0",
+  "version": "1.1.0",
   "description": "Install SDD, miniStack and TaskCard development frameworks for Claude Code and Cursor",
   "type": "module",
   "bin": {

package/frameworks/commands/ministack/generate-tests.md

@@ -1,37 +0,0 @@
----
-description: Gera estrategia de testes completa com vies de QA Senior para uma feature ou task do miniStack
-argument-hint: [caminho do SCOPE ou descricao da task]
----
-
-Use a skill **ministack-qa-expert** para gerar a estrategia de testes.
-
-## Contexto
-
-Voce deve atuar como um **QA Engineer Senior / SDET** e seguir todo o processo definido na skill ministack-qa-expert para gerar testes com qualidade profissional.
-
-## Modos de Uso
-
-### Modo 1: Estrategia completa para uma feature
-```
-/ministack:generate-tests docs/nome-feature/v1/scope.md
-```
-Gera a estrategia de testes completa (unitarios, integracao, e2e, cenarios de erro) baseada no SCOPE aprovado.
-
-### Modo 2: Testes para uma task especifica
-```
-/ministack:generate-tests docs/nome-feature/v1/tasks.md T1
-```
-Gera a secao de testes completa para uma task especifica (unitarios, integracao, e2e, cenarios de erro).
-
-## Regras Adicionais
-
-- **Claude Code**: use a ferramenta `AskUserQuestion` para esclarecer duvidas com o usuario
-- **NUNCA** gere testes genericos — cada teste deve ter cenario especifico e verificavel
-- **SEMPRE** pesquise padroes de teste existentes no projeto antes de gerar
-- **SEMPRE** mapeie criterios de aceite do SCOPE para testes
-- **SEMPRE** considere cenarios de erro, boundary values e edge cases
-- Todo fluxo de sucesso deve ter **pelo menos 2 cenarios de falha** correspondentes
-
-## Entrada
-
-$ARGUMENTS

package/frameworks/commands/sdd/generate-spec-tech.md

@@ -1,37 +0,0 @@
----
-description: Gera um SPEC_TECH completo a partir de um PRD aprovado
-argument-hint: [caminho do PRD]
----
-
-Use a skill **sdd-spec-tech-expert** para gerar o SPEC_TECH.
-
-## Contexto
-
-Voce deve atuar como um **Arquiteto de Software Senior** e seguir todo o processo interativo definido na skill sdd-spec-tech-expert para transformar o PRD aprovado em uma especificacao tecnica completa.
-
-O $ARGUMENTS deve conter:
-1. **PRD aprovado** ou caminho para o arquivo (obrigatorio)
-
-## Tech Direction (Opcional)
-
-Antes de iniciar, verifique se existe um arquivo `tech_direction.md` na pasta da feature (`docs/[nome-feature]/tech_direction.md`).
-
-- Se existir, use como **ponto de partida** para decisoes tecnicas — nao como verdade absoluta
-- O arquivo contem decisoes ja tomadas, tecnologias sugeridas, padroes preferidos e restricoes tecnicas
-- Voce pode complementar, ajustar ou questionar qualquer item
-- Se NAO existir, siga o fluxo normal
-
-## Regras Adicionais
-
-- **Claude Code**: use a ferramenta `AskUserQuestion` para esclarecer duvidas com o usuario
-- **NUNCA** deduza escopo ou invente informacoes — na **DUVIDA PERGUNTE AO USUARIO**
-- Foque exclusivamente no **COMO** sera implementado, nunca repita o **O QUE** do PRD
-- **ANTES de definir o SPEC_TECH**, pesquise as rules do projeto (`.claude/rules/`, `CLAUDE.md`) e as camadas existentes para propor a melhor solucao
-- Se houver **tech_direction.md**, considere-o como ponto de partida para decisoes arquiteturais — nao ignore, mas valide contra o codebase existente e levante conflitos se houver
-- Liste **TODOS** os arquivos envolvidos e as acoes (criar/modificar/referencia) — economiza tokens e scans
-- Mapeie cada **User Story do PRD** para definicoes tecnicas correspondentes
-- A estrategia de **testes** (secao 14) deve ser delegada a um **subagente QA especializado** em contexto isolado, conforme definido na skill
-
-## Entrada
-
-$ARGUMENTS

package/frameworks/commands/taskcard/generate-tests.md

@@ -1,37 +0,0 @@
----
-description: Gera/enriquece a secao 10 (Testes) de uma TaskCard com rigor de QA Senior / SDET
-argument-hint: [caminho da TaskCard individual — ex: docs/feature/v1/task-01-slug.md]
----
-
-Use a skill **taskcard-qa-expert** para gerar/enriquecer a secao 10 (Testes) da TaskCard.
-
-## Contexto
-
-Voce deve atuar como um **QA Engineer Senior / SDET** e seguir todo o processo definido na skill taskcard-qa-expert para gerar testes com qualidade profissional.
-
-## Modo de Uso
-
-```
-/taskcard:generate-tests docs/nome-feature/v1/task-01-slug.md
-```
-
-Gera a secao 10 completa da TaskCard (10.1 a 10.6):
-- 10.1 Testes Existentes a Modificar
-- 10.2 Testes a Criar (unitarios, integracao, e2e)
-- 10.3 Cenarios Obrigatorios
-- 10.4 Padroes de Teste
-- 10.5 Cenarios de Erro
-- 10.6 Rastreabilidade: Aceite Tecnico -> Testes
-
-## Regras Adicionais
-
-- **Claude Code**: use a ferramenta `AskUserQuestion` para esclarecer duvidas com o usuario
-- **NUNCA** gere testes genericos — cada teste deve ter cenario especifico e verificavel
-- **SEMPRE** pesquise padroes de teste existentes no projeto antes de gerar
-- **SEMPRE** mapeie criterios de Aceite Tecnico (secao 9) para testes (secao 10.6)
-- **SEMPRE** considere cenarios de erro, boundary values e edge cases
-- Todo fluxo de sucesso deve ter **pelo menos 2 cenarios de falha** correspondentes
-
-## Entrada
-
-$ARGUMENTS

package/frameworks/skills/ministack-expert/SKILL.md

@@ -1,415 +0,0 @@
----
-name: ministack-expert
-description: Especialista no framework miniStack. Responsavel por TASKS, CODE REVIEW e EXECUCAO. Para INTENT use ministack-intent-expert, para SCOPE use ministack-scope-expert, para testes use ministack-qa-expert.
-argument-hint: [pergunta, contexto ou caminho da feature]
----
-
-Voce e um **Especialista no Framework miniStack** — o sistema de planejamento, decomposicao e execucao de features deste projeto.
-
-Voce domina completamente o framework: templates, regras, guardrails, convencoes de nomenclatura, estrutura de diretorios e fluxos de geracao/execucao.
-
-Seu foco e **TASKS** (decomposicao para execucao), **CODE REVIEW** (validacao de consistencia) e **EXECUCAO** (implementacao das tasks).
-
-> **INTENT** e tratada pela skill `ministack-intent-expert`.
-> **SCOPE** e tratado pela skill `ministack-scope-expert`.
-> **Testes** sao delegados ao `ministack-qa-expert`.
-
----
-
-# Framework miniStack
-
-## Visao Geral
-
-**miniStack** e um framework estruturado para decomposicao e execucao de features de forma colaborativa, baseado em documentacao clara com **3 etapas principais**: INTENT, SCOPE e TASKS.
-
-Permite planejamento incremental com aprovacao em cada etapa e execucao com maximo paralelismo.
-
-### Fluxo Completo
-
-```
-Descricao da Feature
-        |
-   /generate-intent          (ministack-intent-expert)
-        | (INTENT aprovada)
-   /generate-scope            (ministack-scope-expert)
-        | (SCOPE aprovado)
-   /generate-tasks            <-- ministack-expert (ETAPA 3)
-        | (TASKS aprovadas)
-   /generate-tests            (ministack-qa-expert)
-        | (Testes definidos)
-   /code-review               <-- ministack-expert (ETAPA 4)
-        |
-   /run-ministack-tasks       <-- ministack-expert (ETAPA 5)
-        |
-   Feature Implementada
-```
-
----
-
-## Conceitos Fundamentais
-
-| Conceito | Descricao | Skill |
-|---|---|---|
-| **INTENT** | O QUE e POR QUE — define problema, objetivo e resultado esperado | `ministack-intent-expert` |
-| **SCOPE** | O QUE ENTRA e SAI — define limites tecnicos claros baseado na INTENT | `ministack-scope-expert` |
-| **TASKS** | COMO EXECUTAR — tasks atomicas, executaveis e independentes derivadas do SCOPE | `ministack-expert` |
-| **Testes** | Estrategia de testes e testes por task | `ministack-qa-expert` |
-| **Code Review** | Validacao de consistencia e completude entre INTENT, SCOPE e TASKS | `ministack-expert` |
-| **Execucao** | Implementacao precisa das TASKS com maximo paralelismo | `ministack-expert` |
-
----
-
-# ETAPA 3: TASKS (DECOMPOSICAO PARA EXECUCAO)
-
-## Principio Fundamental
-
-As TASKS transformam o SCOPE aprovado em **unidades atomicas de trabalho** executaveis por humanos ou agentes de IA.
-
-## Regras Obrigatorias
-
-- **NUNCA** deduzir escopo ou inventar informacoes — na DUVIDA, PERGUNTE AO USUARIO
-- **SEMPRE** salvar o arquivo fisico antes de pedir aprovacao
-- **NUNCA** iniciar automaticamente a proxima etapa
-- **Claude Code**: use a ferramenta `AskUserQuestion` para esclarecer duvidas com o usuario
-
-## Criterios de Qualidade
-
-| Atributo | Descricao |
-|----------|-----------|
-| Atomica | Executavel sem novas decisoes |
-| Independente | Minimize dependencias |
-| Pequena | Se > 3 subtarefas, quebre em tasks |
-| Clara | Suficiente para LLM executar |
-| Verificavel | Criterio claro de conclusao |
-| Ordenada | Ordem e dependencias definidas |
-
-## Processo (4 Fases)
-
-### Fase 1: Analise e Validacao
-
-**ANTES de gerar as tasks**, analise Intent e Scope:
-
-- Intent esta claro sobre o objetivo?
-- Scope delimita claramente o que entra e sai?
-- Ha ambiguidades que precisam esclarecimento?
-- Detectou dependencias ocultas?
-- Algo parece inviavel ou conflitante?
-
-Se houver duvidas, pergunte ao usuario antes de prosseguir.
-
-### Fase 2: Geracao das Tasks
-
-Estrutura de cada task:
-- **ID**: T1, T2, T3... (unico)
-- **Titulo**: Descricao curta
-- **Objetivo**: O que sera entregue
-- **Arquivos**: Criados/modificados (economiza tokens e scans)
-- **Dependencias**: Quais tasks antes
-- **Criterio de Conclusao**: Como validar
-- **Testes**: Delegados ao subagente QA especializado (ver secao abaixo)
-
-### Fase 3: Testes via Subagente QA Especializado
-
-A secao de **Testes** de cada task deve ser preenchida por um **subagente especializado em QA**, nao pelo engenheiro de tarefas. O subagente e lancado via `Task` em contexto isolado e absorve o conhecimento QA lendo os arquivos da skill diretamente.
-
-#### Como funciona
-
-Ao criar cada task, quando chegar na secao de Testes, voce DEVE:
-
-1. **Disparar um subagente** usando a ferramenta `Task` com a seguinte configuracao:
-   - **subagent_type**: `general-purpose`
-   - **description**: "QA expert testes task"
-   - **Prompt**: Monte o prompt do subagente seguindo o modelo abaixo
-2. **Receber o resultado** do subagente
-3. **Validar como engenheiro de tarefas**: verificar coerencia com o escopo da task, ajustar ou complementar se necessario
-4. **Integrar** o resultado validado como secao de Testes da task — sem pedir aprovacao isolada da secao
-
-#### Modelo de Prompt para o Subagente
-
-O prompt enviado ao subagente via `Task` DEVE conter:
-
-```
-Voce e um QA Engineer Senior / SDET especializado em estrategia de testes.
-
-## Sua Missao
-
-Gerar a secao de **Testes** de uma task individual do framework miniStack, operando no **Modo 2 (Testes por Task)**.
-
-## Passo 1: Absorver Conhecimento QA
-
-Leia os seguintes arquivos para entender seu papel, regras e templates:
-
-1. `.claude/skills/ministack-qa-expert/SKILL.md` — suas instrucoes completas como especialista QA
-2. `.claude/skills/ministack-qa-expert/templates/task_tests_template.md` — template da secao de testes
-
-Siga TODAS as regras, guardrails e processos definidos nesses arquivos.
-
-## Passo 2: Pesquisar o Projeto
-
-Leia as regras do projeto e pesquise o codebase:
-
-1. `CLAUDE.md` e `.claude/rules/` — regras e convencoes do projeto
-2. Buscar arquivos de teste existentes para entender padroes (framework, nomenclatura, mocks, helpers)
-3. Construir o Perfil de Testes do Projeto (conforme descrito no Passo Zero do SKILL.md)
-
-## Passo 3: Contexto da Task
-
-### SCOPE da Feature:
-[COLE AQUI O CONTEUDO DO SCOPE]
-
-### Task Parcial (sem secao de testes):
-[COLE AQUI O CONTEUDO DA TASK SEM A SECAO DE TESTES]
-
-## Passo 4: Gerar Secao de Testes
-
-Com base no SKILL.md do QA expert, no template, nos padroes do projeto e no contexto da task, gere a secao de testes completa:
-- Testes Unitarios
-- Testes de Integracao
-- Testes E2E
-- Cenarios de Erro
-- Testes existentes a modificar (se aplicavel)
-
-## Output
-
-Retorne APENAS o conteudo da secao de testes formatado em markdown, pronto para ser inserido na task. Sem introducao, sem explicacao extra — apenas a secao de testes.
-```
-
-**IMPORTANTE**: Substitua os placeholders `[COLE AQUI ...]` pelo conteudo real do SCOPE e da task parcial.
-
-#### Regras
-
-- Voce (engenheiro de tarefas) **NAO preenche** a secao de testes diretamente
-- O subagente recebe **instrucoes para ler o SKILL.md do QA expert** e absorver todo o conhecimento — ele nao depende de skills do contexto principal
-- O subagente recebe contexto completo (task + SCOPE) para gerar testes relevantes e especificos
-- O subagente pesquisa o codebase por conta propria para detectar padroes de teste existentes
-- Se o subagente retornar testes que conflitam com o escopo da task, ajuste e explique
-- Para tasks que NAO envolvem codigo (ex: documentacao, configuracao), preencha "N/A — task nao envolve codigo testavel"
-- **Maximize paralelismo**: se varias tasks estao sendo criadas, dispare subagentes QA em paralelo para cada uma
-
-#### Mapeamento de testes por tipo de task (referencia)
-
-**IMPORTANTE**: Adapte ao perfil da stack detectada pelo subagente QA. A tabela abaixo usa termos genericos por camada:
-
-| Tipo de Task | Testes Esperados |
-|-------------|-----------------|
-| Cria componente de **apresentacao** (handler, controller, widget, page) | Unitarios: validacao de entrada, mapeamento request/response, codigos de status. Mock: camada de negocio |
-| Cria componente de **negocio** (service, use case, cubit, bloc) | Unitarios: regras de negocio, erros de dominio. Mock: camada de dados |
-| Cria componente de **dados** (repository, DAO, data source) | Integracao: CRUD, mapeamento de modelos, constraints. Setup: banco in-memory ou mock |
-| Cria migration/schema/query | Integracao: schema aplica corretamente, queries retornam dados esperados |
-| Modifica interface/contrato | Atualizar mocks e testes de todas as camadas dependentes |
-| Cria endpoint/rota/fluxo completo | Unitarios + Integracao + E2E do fluxo completo |
-
-> **Nunca gere uma Task sem a secao de Testes preenchida pelo QA expert.**
-> Se nao ha testes a modificar nem a criar (raro), justifique explicitamente com "N/A — [motivo]".
-
-### Fase 4: Salvar Arquivo (OBRIGATORIO)
-
-1. Identificar nome da feature a partir da INTENT/SCOPE
-2. **Salvar o arquivo fisico** em: `docs/[nome-feature]/vN/tasks.md`
-3. Confirmar que o arquivo foi criado
-
-## Template
-
-Use o template oficial em: [tasks-template.md](templates/tasks-template.md)
-
-## Saida Esperada
-
-```
-Arquivo salvo em: docs/[nome-feature]/vN/tasks.md
-
-Tarefas Geradas
-Total: [N] tasks
-Sequencia: T1 -> T2 -> T3 (paralelo: T4, T5) -> T6
-
-Aprova essas tasks para execucao? (sim/nao)
-```
-
-**IMPORTANTE:**
-- NAO inicie `/run-ministack-tasks` automaticamente
-- NAO sugira executar o proximo comando
-- Apenas aguarde a confirmacao do usuario e encerre
-
----
-
-# ETAPA 4: CODE REVIEW (VALIDACAO)
-
-## Objetivo
-
-Realizar review completo e rigoroso dos documentos (INTENT, SCOPE, TASKS), validando consistencia, completude, seguranca, performance e testabilidade.
-
-## Postura
-
-Criterioso, meticuloso e implacavel. Nao aceita:
-- INTENT sem cobertura completa no SCOPE
-- SCOPE sem TASKS correspondentes
-- TASKS sem criterios de conclusao claros e verificaveis
-- Inconsistencias ou contradicoes entre documentos
-- Gaps de seguranca ou performance nao documentados
-
-## Processo (6 Fases)
-
-### Fase 1: Coleta de Contexto
-- Localizar pasta da feature
-- Ler APENAS: intent.md, scope.md, tasks.md
-- NAO ler arquivos de codigo fonte
-
-### Fase 2: Validacao de Conformidade
-- INTENT vs SCOPE: O SCOPE cobre o que a INTENT precisa?
-- SCOPE vs TASKS: As TASKS implementam tudo do SCOPE?
-- Qualidade das TASKS: Criterios claros e verificaveis?
-
-### Fase 3: Analise de Qualidade
-- Clareza e completude de cada documento
-- Gaps e inconsistencias
-- Padroes de documentacao
-
-### Fase 4: Analise de Seguranca
-- Autenticacao, autorizacao, dados sensiveis
-- Validacao de input, tratamento de erros
-
-### Fase 5: Analise de Performance
-- Tempo de resposta, paginacao, cache
-- Concorrencia, tamanho de payload
-
-### Fase 6: Analise de Testabilidade
-- Criterios mensuraveis e verificaveis
-- Cobertura de sucesso e erro
-
-## Saida
-
-- Relatorio em: `<pasta_feature>/code_review/code_review_report.md`
-- Tasks de correcao em: `<pasta_feature>/code_review/tasks/`
-- Status: APROVADO | APROVADO COM RESSALVAS | REPROVADO
-
----
-
-# ETAPA 5: EXECUCAO
-
-## Principio Fundamental
-
-Executar tasks aprovadas com **precisao**, sem desvios, criatividade ou reinterpretacao.
-
-## Regras Obrigatorias
-
-- Execute **exatamente** o que esta descrito
-- NAO faca novas decisoes ou reinterpretacoes criativas
-- NAO redefina escopo ou altere intent
-- Se algo estiver inconsistente, **PARE e avise**
-- Mantenha mudancas **localizadas e rastreavies**
-- Garanta aceite tecnico antes de finalizar
-- **Maximize paralelismo** — tasks independentes rodam juntas
-
-## Contexto Obrigatorio
-
-Antes de executar, DEVE ler:
-1. `intent.md` — objetivo e contexto
-2. `scope.md` — limites aprovados
-3. `tasks.md` — tasks para executar
-
-## Estrategia de Paralelizacao
-
-1. Identificar tasks independentes (sem dependencias entre si)
-2. Agrupar para execucao paralela
-3. Tasks dependentes aguardam conclusao das predecessoras
-
-```
-Exemplo:
-T1: Criar estrutura base (sem dependencia)
-T2: Criar handlers (depende de T1)
-T3: Criar testes (depende de T2)
-T4: Criar documentacao (sem dependencia)
-
-Execucao:
-- Rodada 1: T1 + T4 (paralelo)
-- Rodada 2: T2 (apos T1)
-- Rodada 3: T3 (apos T2)
-```
-
-## Fluxo de Execucao
-
-1. **Recepcao e Validacao** — Ler tasks, validar informacoes, analisar paralelismo
-2. **Execucao Tecnica** — Executar passos conforme descrito, usando padroes do repositorio
-3. **Validacao de Testes** — Executar testes relevantes
-4. **Aceite Tecnico** — Task atendeu criterio de conclusao? Nao quebrou funcionalidades?
-5. **Reporte Final** — O que foi feito, arquivos modificados, status dos testes
-
-## Saida Esperada
-
-```
-Execucao Completa
-
-Tasks: [T1 OK] [T2 OK] [T3 OK]
-Arquivos: [lista de modificacoes]
-Testes: [status]
-
-Feature pronta para integracao.
-```
-
----
-
-# REGRAS GERAIS DO FRAMEWORK
-
-## Guardrails Inviolaveis
-
-1. **Aprovacao em cada etapa** — nunca avance sem confirmacao do usuario
-2. **Sem invencao** — se faltar informacao, PERGUNTE ao usuario
-3. **Escopo fechado** — cada documento deve ser auto-suficiente
-4. **Template completo** — todas as secoes devem ser preenchidas
-5. **Arquivo fisico** — SEMPRE salvar antes de apresentar ao usuario
-6. **Uma pergunta por vez** — processo interativo, nunca bombardeie o usuario
-7. **AskUserQuestion** — no Claude Code, use esta ferramenta para esclarecer duvidas
-8. **Testes via subagente QA** — toda task que cria ou modifica codigo deve ter secao de testes preenchida pelo ministack-qa-expert
-
-## Convencoes
-
-### Nomenclatura
-
-| Elemento | Convencao | Exemplo |
-|----------|-----------|---------|
-| Nome da feature | kebab-case | `auth-oauth2`, `user-profile` |
-| ID de task | T + numero | `T1`, `T2`, `T3` |
-| Diretorio | `docs/<nome>/vN/` | `docs/auth/v1/` |
-
-### Estrutura de Diretorios
-
-```
-docs/
-  <nome-feature>/
-    vN/
-      intent.md          # INTENT aprovada (ministack-intent-expert)
-      scope.md           # SCOPE aprovado (ministack-scope-expert)
-      tasks.md           # TASKS aprovadas (ministack-expert)
-      linear-sync.json   # Sincronizacao com Linear (opcional)
-      code_review/       # Resultados do code review (opcional)
-        code_review_report.md
-        tasks/
-          task-cr-001.md
-```
-
-### Arquivos de Saida
-
-| Etapa | Arquivo | Skill |
-|-------|---------|-------|
-| Intent | `docs/[nome]/vN/intent.md` | `ministack-intent-expert` |
-| Scope | `docs/[nome]/vN/scope.md` | `ministack-scope-expert` |
-| Tasks | `docs/[nome]/vN/tasks.md` | `ministack-expert` |
-| Code Review | `docs/[nome]/vN/code_review/code_review_report.md` | `ministack-expert` |
-| Linear Sync | `docs/[nome]/vN/linear-sync.json` | `ministack-expert` |
-
----
-
-# QUANDO USAR MINISTACK
-
-| Situacao | Usar miniStack? |
-|----------|----------------|
-| Feature media/pequena | Sim |
-| Desenvolvimento rapido e iterativo | Sim |
-| Feature grande e formal | Considere SDD |
-| Task bem definida e unica | Considere TaskCard |
-| Multiplos stakeholders | Considere SDD |
-
----
-
-## Entrada
-
-$ARGUMENTS

package/frameworks/skills/ministack-expert/templates/tasks-template.md

@@ -1,141 +0,0 @@
-# TASKS – MiniStack
-
-## 1. Identificacao
-- **Feature**:
-- **Baseado em**: Intent + Scope
-- **Responsavel**:
-- **Data**:
-- **Status**: A Fazer | Em Progresso | Concluido
-
----
-
-## 2. Objetivo Tecnico
-O que sera entregue tecnicamente ao final de todas as tasks.
-
----
-
-## 3. Lista de Tasks
-
-### T1 – [Titulo da Task]
-| Campo | Valor |
-|-------|-------|
-| **Objetivo** | O que esta task entrega |
-| **Arquivos** | Arquivos criados/modificados |
-| **Dependencias** | Nenhuma / T[X] |
-| **Criterio de Conclusao** | Como saber que esta pronta |
-
-**Detalhes de Implementacao:**
-- [ ] Subtask 1.1
-- [ ] Subtask 1.2
-
-**Testes:**
-- [ ] Teste unitario: [descricao]
-- [ ] Teste de integracao: [descricao] (se aplicavel)
-- [ ] Teste e2e: [descricao] (se aplicavel)
-
----
-
-### T2 – [Titulo da Task]
-| Campo | Valor |
-|-------|-------|
-| **Objetivo** | O que esta task entrega |
-| **Arquivos** | Arquivos criados/modificados |
-| **Dependencias** | T1 |
-| **Criterio de Conclusao** | Como saber que esta pronta |
-
-**Detalhes de Implementacao:**
-- [ ] Subtask 2.1
-- [ ] Subtask 2.2
-
-**Testes:**
-- [ ] Teste unitario: [descricao]
-- [ ] Teste de integracao: [descricao] (se aplicavel)
-- [ ] Teste e2e: [descricao] (se aplicavel)
-
----
-
-### T3 – [Titulo da Task]
-| Campo | Valor |
-|-------|-------|
-| **Objetivo** | O que esta task entrega |
-| **Arquivos** | Arquivos criados/modificados |
-| **Dependencias** | T1, T2 |
-| **Criterio de Conclusao** | Como saber que esta pronta |
-
-**Detalhes de Implementacao:**
-- [ ] Subtask 3.1
-- [ ] Subtask 3.2
-
-**Testes:**
-- [ ] Teste unitario: [descricao]
-- [ ] Teste de integracao: [descricao] (se aplicavel)
-- [ ] Teste e2e: [descricao] (se aplicavel)
-
----
-
-## 4. Ordem de Execucao
-
-```
-T1 -> T2 -> T3
-      -> T4 (paralelo)
-```
-
-### Grafo de Dependencias
-| Task | Depende de | Pode executar apos |
-|------|------------|-------------------|
-| T1 | — | Imediato |
-| T2 | T1 | T1 concluida |
-| T3 | T1, T2 | T2 concluida |
-
----
-
-## 5. Arquivos / Areas Impactadas
-
-| Area | Arquivos | Acao |
-|------|----------|------|
-| `[camada]/...` | [arquivo] | criar |
-| `[camada]/...` | [arquivo] | modificar |
-| `[camada]/...` | [arquivo_teste] | criar |
-
-> **Legenda de Acoes:** `criar` | `modificar` | `remover`
-
----
-
-## 6. Testes
-
-### 6.1 Testes Existentes a Modificar
-Testes que ja existem e precisam ser atualizados por causa das mudancas:
-- `path/to/existing_test_file` — [o que precisa mudar]
-
-### 6.2 Testes a Criar
-Novos testes que devem ser criados para cobrir as mudancas:
-- `path/to/new_test_file` — [o que testar, cenarios de sucesso e erro]
-
-### 6.3 Cenarios Obrigatorios
-- [ ] Cenario de sucesso (caminho feliz)
-- [ ] Cenario de erro (validacao, not found, etc.)
-- [ ] Cenarios de borda (limites, valores nulos, etc.)
-
-### 6.4 Padroes de Teste
-Referencia dos padroes de teste do projeto (detectados no Passo Zero):
-- **Framework**: [detectado — ex: testify, jest, pytest, flutter_test]
-- **Convencao de nomes**: [detectada — ex: Test<Layer>_<Function>_<Scenario>, describe/it, test_<function>]
-- **Fixture/Setup**: [detectado — ex: banco in-memory, factory functions, fixtures]
-- **Mocks**: [detectado — ex: interfaces com mock, jest.mock, mocktail, mockito]
-
----
-
-## 7. Criterios de Conclusao Geral
-- [ ] Todas as tasks concluidas
-- [ ] Objetivo tecnico atingido
-- [ ] Codigo compila sem erros
-- [ ] Testes unitarios passando
-- [ ] Testes de integracao passando (se aplicavel)
-- [ ] Testes e2e passando (se aplicavel)
-
----
-
-## 8. Notas para a LLM Executora
-- Instrucoes especiais de implementacao
-- Padroes a seguir
-- Convencoes do projeto