Veja o modelo em uma entrega.

Do pedido amplo ao critério verificável

Pedido inicial: “melhorar a gestão de tarefas”. Primeiro esclareça o fluxo: quem cria, quem pode editar, quais dados persistem e como o usuário percebe o resultado.

REQ-TASK-01
Um usuário autenticado cria uma tarefa com título válido.
A tarefa fica associada ao seu contexto autorizado.
O autor recebe confirmação e consegue reabrir o detalhe.

Aceite:
- título vazio é rejeitado;
- outro contexto não lê a tarefa;
- após recarregar, os dados permanecem.

Divida sem perder o fluxo

• PKG-01: criação e consulta de tarefas. O objetivo é um fluxo completo verificável.
• Lote 1: regra de criação, autorização e persistência, com testes focados.
• Lote 2: formulário e detalhe consumindo o contrato; testar sucesso e erros.
• Fechamento: revisar consumidores, recarga, permissões, docs, check e rollback.

Registre o que falta sem mascarar o estado

Se a API e a UI existem, mas a autorização cruzada ainda falha, o requisito não está comprovado. Registre o estado parcial/divergente, a evidência, a pendência e o módulo responsável.

Requisito: REQ-TASK-01
Estado: Parcial
Evidência: criação e recarga verificadas com fixture controlada
Pendência: acesso entre contextos ainda precisa de correção
Módulo: tarefas / autorização
Próximo reteste: cenário permitido + cenário negado

Um ponto de partida para o assistente

Use como orientação inicial e adapte à tarefa. Referenciar arquivos não concede autorização para publicar, apagar dados ou mudar branches.

Leia PATHS.toml e PRD.md.
Inspecione a arquitetura e o estado do Git antes de alterar.
Quero implementar REQ-TASK-01 no fluxo de tarefas.
Consulte os documentos temáticos necessários para esse recorte.
Preserve convenções e separe UI, regra e infraestrutura.
Valide criação, persistência e autorização por contexto.
Atualize as evidências e informe o que foi realmente testado.
Não faça push, deploy ou exclusão de dados sem autorização.

Quando o trabalho é um bug

Reproduza a falha antes de propor uma causa. Diferencie hipótese de diagnóstico confirmado. Corrija no módulo responsável e reteste o mesmo cenário. Amplie os testes se a mudança afetar contratos, dados, permissões ou múltiplos consumidores.

Erros de adoção que o modelo procura evitar

• Copiar “concluído” de um projeto para outro.
• Criar documentos extensos que não apontam para código ou decisão real.
• Pedir à IA que invente paths, stacks ou comandos.
• Tratar deploy, uso em dispositivo e aceite como consequência automática do build.
• Remover validações para esconder falhas da implementação.