Eu estava invocando manualmente cada etapa no GitHub Spec Kit. Mesmo assim, acabei com um plano que incluía trabalho que eu não esperava fazer parte da feature.
Não era um agente executando uma sequência de forma autônoma. Eu invocava uma skill específica para cada etapa. Na primeira rodada de planejamento, revisei os resultados superficialmente e confiei nas decisões geradas. Quando cheguei ao plano e às tasks, encontrei interpretações equivocadas do problema e tasks fora do escopo que eu esperava.
A parte desconfortável é que eu estava presente o tempo todo. Decidir executar a próxima etapa não era o mesmo que entender e aceitar as decisões que ela recebia.
Preserve a descoberta, separe a decisão
Uma parte daquele primeiro plano incluía propostas de correção para possíveis problemas preexistentes. A resolução deles tinha virado trabalho da feature sem que a decisão de escopo fosse claramente trazida de volta para mim.
Isso ficou no plano e nas tasks. Não implementei o primeiro plano nem fiz aquelas alterações de código fora do escopo.
Criei tickets separados para preservar as descobertas e direcionei sua resolução para fora da feature. A expansão de escopo foi um dos vários problemas que me levaram a descartar o primeiro plano e recomeçar o planejamento do zero.
A distinção útil aqui não é entre uma descoberta boa e uma ruim. É entre descobrir algo que merece atenção e decidir que esta feature deve tratar disso.
Trate essas decisões separadamente:
- Avalie a descoberta: o que a sustenta e o que ainda precisa de confirmação?
- Decida o encaminhamento: resolver aqui, acompanhar separadamente ou rejeitar com uma justificativa.
- Aprove qualquer mudança no escopo da feature antes de tratá-la como uma obrigação de implementação.
Manter tudo na feature e descartar tudo que fica fora dela não são as únicas opções. No meu caso, tickets separados preservaram as descobertas sem manter sua resolução no plano da feature.
Acompanhar separadamente é uma decisão de escopo, não uma afirmação de que o problema foi resolvido.
O que mudou na segunda rodada
Na segunda rodada, controlei os inputs mais de perto, corrigi interpretações depois de cada etapa e direcionei as decisões ao longo do processo. Foi esse segundo plano que segui para a implementação.
A mudança foi no momento em que apliquei meu julgamento. Na primeira rodada, revisar o plano e as tasks revelou decisões que já tinham se acumulado. Na segunda, revisei e corrigi essas decisões etapa por etapa.
Essa forma de usar o workflow exige mais participação. Ela pede atenção durante o planejamento, não só quando a lista de tasks está pronta. O tradeoff a considerar é o esforço de revisão em relação ao quanto de interpretação você aceita deixar acumular antes de examinar.
Não transforme isso em uma exigência de aprovar cada frase. Concentre a revisão nas interpretações que mudam o problema, as restrições ou o trabalho que pertence à feature. Eu também precisava levar essa revisão mais a sério.
Onde eu colocaria o limite arquitetural
Para um workflow que precisa impor a aprovação, a recomendação vai além de uma leitura mais cuidadosa: coloque as transições de estado com consequências fora do julgamento do modelo. Isso é uma recomendação arquitetural, não uma capacidade que estou atribuindo ao Spec Kit na minha execução.
Deixe o modelo identificar questões e propor uma resposta. Exija uma decisão humana separada antes que uma expansão de escopo proposta se torne trabalho aceito para a feature. Faça o workflow ao redor impor essa distinção, em vez de pedir ao mesmo modelo que deduza se continuar significa aprovar.
Um checkpoint prático poderia perguntar:
- O que mudou na interpretação da feature?
- Quais descobertas introduzem trabalho fora do escopo atual?
- Quais adições foram explicitamente aceitas e quais pertencem a outro lugar?
Essas perguntas são uma sugestão de apoio à revisão, não a descrição de um mecanismo de aprovação que implementei.
Antes de iniciar a próxima etapa, revise a mudança de escopo — não apenas se o resultado parece completo.