Specsfy 05 Tasks

Quebrar a especificação em tarefas

Preencha a seção 14. Tarefas de specs/specs/<NNNN>-<slug>/spec.md. O arquivo permanece a única fonte da verdade; cada tarefa precisa ser pequena, verificável, ordenada e ligada a IDs definidos nele.

Orquestrar a conversa

Ao concluir esta etapa ou detectar trabalho de outra etapa, anuncie Pendência detectada: <descrição> — ação: resolvendo nesta etapa e resolva-a quando pertencer ao próprio escopo. Quando houver troca de responsabilidade, anuncie Transição automática: $specsfy-05-tasks → $<destino> — motivo: <motivo> — resultado esperado: <resultado> e carregue imediatamente a skill de destino, sem pedir confirmação nem repetir o comando. Continue na mesma conversa. Depois de uma correção necessária a esta etapa, anuncie Retomada automática: $<destino> → $specsfy-05-tasks — pendência resolvida: <resultado> e retome-a imediatamente. Reavalie o estado após cada handoff para evitar ciclos. Não peça confirmação para o handoff; ações sensíveis continuam exigindo autorização específica.

Pré-condições

1. Leia a spec indicada em specs/specs/<NNNN>-<slug>/spec.md e exija Formato: Specsfy/2.0, Definition Gate: Passed e Status Defined, Planned ou Implementing. Aceite os dois últimos somente para replanejamento automático de uma pendência detectada em etapa posterior.
2. Execute a validação da especificação quando o gate ainda não estiver comprovado.
3. Inspecione o repositório para usar stack, comandos e caminhos reais. Em PHP, use Pest para TDD; em Node sem PHP, pergunte qual runner adotar e recomende Vitest antes de gerar caminhos ou comandos.
4. Execute o monitor antes de planejar:

python3 -B .agents/skills/specsfy-setup/scripts/monitor_context.py \
  --project .

Use os sinais de stack, aplicação, regras e persistência para planejar a documentação junto da mudança, sem inferir requisito novo. 5. Se faltar uma decisão que mude arquitetura, dados ou aceite, anuncie e retorne automaticamente para $specsfy-02-backlog. Depois da decisão, use $specsfy-update-spec quando a spec já tiver sido aprovada ou $specsfy-03-specify durante a definição inicial.

Gerar

Use .specsfy/templates/custom/Tasks.md como contrato quando existir e recorra a .specsfy/templates/Tasks.md caso contrário. Substitua somente o conteúdo das seções 14. Tarefas e 15. Ordem de execução em <raiz>/specs/specs/<NNNN>-<slug>/spec.md; preserve todas as outras seções.

• Se a spec estiver Planned ou Implementing, anuncie a pendência, reabra o Ato II e defina Status: Defined, Plan Gate: Pending e Delivery Gate: Pending antes de editar. Gate e evidência posteriores não permanecem válidos sobre o plano alterado.
• Em uma spec já Defined, defina Plan Gate: Pending e Delivery Gate: Pending antes de editar.
• Preserve IDs existentes ao atualizar; não renumere tarefas concluídas.
• Organize em setup mínimo, fundação indispensável, histórias em prioridade e fechamento.
• Mantenha histórias como fatias verticais independentemente demonstráveis.
• Para cada AC, crie uma tarefa [TEST] [TDD] distinta cujo desenho usa o Gherkin mantido na spec como referência. O conjunto dessas tarefas materializa pelo menos três casos TDD distintos para a feature inteira e para cada US, FR e NFR.
• Nunca crie tarefa para arquivo .feature ou step definition e nunca execute o Gherkin da spec.
• Em PHP, a tarefa TDD aponta para teste Pest e exige marcador SPECSFY; em Node, usa o runner confirmado pelo usuário e o script test:tdd.
• Faça cada tarefa [CODE] depender do predecessor TDD da mesma fatia com RED.
• Quando a fatia alterar manifests ou configuração estrutural, crie uma tarefa [DOC] para .specsfy/STACK.md. Quando alterar banco, schema, model persistente, tabela, campo, relação ou migration, crie uma tarefa [DOC] obrigatória para .specsfy/DATABASE.md.
• Para mudança de aplicação, inclua a revisão de PROJECT.md no fechamento da tarefa. Se não houver impacto material, exija justificativa na evidência em vez de criar conteúdo artificial.
• Faça toda tarefa [CODE] exigir a reconstrução independente de docs/ por $specsfy-documentator antes de EXECUTE, inclusive quando a documentação já existia antes da mudança.
• Quando uma convenção virar regra confirmada, crie tarefa [DOC] para .specsfy/RULES.md.
• Dê a cada tarefa um resultado único, caminho exato e critério verificável.
• Anexe a cada tarefa, exatamente nesta ordem, os itens PREP, EXECUTE, VERIFY, EVIDENCE e IMPROVE definidos no template Tasks.md resolvido.
• Escreva os itens como resultados específicos da tarefa, não como frases genéricas copiadas.
• Mantenha pai e itens abertos ao gerar tarefas; a skill de implementação atualiza um item imediatamente após sua evidência.
• O item IMPROVE deve registrar uma melhoria concreta aplicada ou declarar que nenhuma foi necessária com justificativa.
• Quando a spec declarar Evidence Contract: 1, cada tarefa [CODE] concluída deve conter um comentário specsfy:evidence JSON com task, refs, files e commands (run e exit). Gere o comentário dentro do bloco da tarefa; nunca em arquivo paralelo.
• Marque [P] somente quando tarefas não compartilham arquivos, estado mutável ou dependência.
• Declare dependências por ID; não dependa apenas da ordem visual.
• Cubra todo FR, NFR e AC aplicável. Não crie tarefa sem referência, exceto setup/polish claramente justificado.
• Não inclua exemplos genéricos nem placeholders.

Formato canônico:

- [ ] T001 [TEST] [TDD] [US-001] Derivar teste Pest do BDD da spec em tests/Feature/AuthTest.php — Refs: FR-002, AC-003 — Depends: none
- [ ] T002 [CODE] [US-001] Implementar validação em app/Services/AuthService.php — Refs: FR-002, AC-003 — Depends: T001

Tags permitidas após o ID: [P], [TEST], [TDD], [CODE], [DOC], [OPS] e [US-NNN].

Validar

Execute:

python3 .agents/skills/specsfy-05-tasks/scripts/validate_tasks.py specs/specs/<NNNN>-<slug>/spec.md --allow-draft

Corrija IDs duplicados, dependências inválidas/cíclicas, referências inexistentes, itens sem três cenários BDD, AC sem tarefa TDD distinta, plano sem três predecessores/casos TDD por feature/US/FR/NFR, código sem predecessor TDD, checklist ausente/fora de ordem, pai/itens incoerentes, progresso em tarefa bloqueada ou tarefas vagas. Faça no máximo três ciclos. No contrato de evidência, o mesmo validador também rejeita arquivo ausente, referência inválida, comando sem exit: 0 ou tarefa concluída sem evidence.

Quando a estrutura passar ainda com Plan Gate: Pending, chame automaticamente $specsfy-06-tdd-bdd no modo prepare. Ele usa o BDD da spec para materializar o predecessor TDD, observa RED e conclui somente essa tarefa de teste. Em seguida, retome automaticamente esta skill para:

1. execute novamente o validador com --allow-draft;
2. altere Plan Gate para Passed e defina Status: Planned;
3. registre o resultado em Gate do Ato II — Plano;
4. execute sem --allow-draft.

O modo estrito rejeita Plan Gate: Passed quando algum predecessor TDD de uma tarefa [CODE] continua aberto. Se a validação falhar, mantenha Status: Defined, Plan Gate: Failed, Delivery Gate: Pending e relate os bloqueios.

Relatar

Informe contagem total/por tipo, caminho crítico, oportunidades [P], cobertura de IDs e, quando o gate passar, anuncie e carregue automaticamente $specsfy-07-implement. Nunca crie tasks.md.

Especialistas sob demanda

Leia references/specialists.md ao decompor trabalho de tecnologia, dados, interface ou operação que demande checklist próprio.