Desenvolva um leitor RSS em um projeto novo com Spec Kit

Greenfield significa que não existe comportamento de aplicação a preservar. Não significa ausência de restrições. Você implementará somente o gerenciamento de assinaturas, não a busca remota de feeds nem um leitor de produção.

Resumo do laboratório

[!NOTE] O starter está intencionalmente incompleto; não substitua seu contrato.

Conceitos · Primeira tarefa · Lista de evidências · Redefinir

Objetivos de aprendizagem

• Separe governança, requisitos dos usuários, projeto técnico e execução.
• Use o esclarecimento para definir o comportamento de duplicatas e entradas inválidas.
• Selecione uma stack com base no mesmo contrato de aceitação.
• Valide uma implementação gerada com testes declarados previamente.

Antes de começar

Conclua a configuração do Spec Kit. Prepare 13-greenfield com o guia da unidade de trabalho. Implementação padrão: módulos ES no Node 24, sem pacotes nem rede. TypeScript, .NET, Python e Go são comparados abaixo; execute somente a stack escolhida.

Conceitos e casos de uso

Cenário do exercício

Uma pessoa leitora organiza assinaturas de feeds localmente. Ela pode adicionar uma URL HTTP(S) e listar assinaturas. Duplicatas, URLs malformadas e credenciais incorporadas devem ser rejeitadas. A aplicação não deve buscar o conteúdo da URL. URLs em example.test são fixtures intencionais.

Tarefa 1 - Revise a intenção das partes interessadas e a linha de base com falha

1. Leia StakeholderDocuments/ProjectGoals.md, AppFeatures.md e TechStack.md.

2. Inspecione contract.test.mjs sem alterar suas asserções.

3. Execute:

   node --test --test-concurrency=1 contract.test.mjs
   

4. A função inacabada createStore deve falhar com o erro documentado do exercício. Um erro de sintaxe, teste ausente ou runtime Node ausente não é a falha esperada.

5. Registre RSS-1 a RSS-4 e identifique o que está deliberadamente fora do contrato.

Tarefa 2 - Inicialize e estabeleça princípios

1. Registre a fixture intacta como linha de base local do Git.

2. Inicialize usando o layout de skills documentado na referência do Spec Kit.

3. Invoque:

   /speckit-constitution Use StakeholderDocuments/ProjectGoals.md.
   Require local deterministic tests, no remote feed fetches or credentials,
   explicit errors, immutable returned records, and bounded changes.
   

4. Revise .specify/memory/constitution.md. Os princípios devem ser acionáveis.

5. Não deixe o fluxo da constituição implementar a aplicação nem reescrever testes.

Tarefa 3 - Especifique e esclareça

/speckit-specify Use StakeholderDocuments/AppFeatures.md.
Build only add/list subscription behavior. Assign stable IDs, reject normalized
duplicates, accept only HTTP(S) without userinfo, and never fetch a submitted URL.
Map requirements to the supplied acceptance tests.

Depois, use /speckit-clarify para resolver estas perguntas:

• Espaços nas extremidades e fragmentos de URL são normalizados?
• Os nomes de host das URLs não diferenciam maiúsculas e minúsculas? O que acontece com a caixa dos caminhos?
• Adições com falha consomem IDs ou modificam o estado?
• O chamador recebe cópias mutáveis ou registros internos ativos?

O contrato fornecido responde a essas perguntas para a implementação padrão. Se uma parte interessada alterar o contrato, registre a aprovação antes de alterar tanto a especificação quanto os testes.

Tarefa 4 - Escolha uma stack e planeje

Exemplo para o caminho padrão:

/speckit-plan Use Node 24 ES modules and the built-in test runner. Implement
subscriptions.mjs only. Use URL parsing, retain IDs and insertion order, return
copies, and add no dependencies, persistence, or HTTP calls.

Separe “stack diferente” de “requisitos diferentes”. Uma interface é opcional até que o contrato de domínio passe; ela precisa de verificações separadas de teclado e comportamento de rede.

Tarefa 5 - Decomponha, implemente e faça convergir

1. Execute /speckit-tasks e depois /speckit-analyze.
2. Garanta que cada requisito RSS-1..4 tenha uma tarefa de implementação e uma verificação.
3. Execute /speckit-implement para um recorte revisado.
4. Execute novamente contract.test.mjs pessoalmente; inspecione o diff completo.
5. Execute /speckit-converge se estiver presente na integração com versão fixada. Verifique suas alegações de forma independente. Pare após duas tentativas de correção malsucedidas, não em um ciclo ilimitado.
6. Faça deliberadamente list() retornar registros internos. Confirme que RSS-4 falha e restaure o comportamento correto.

Verifique seu trabalho

• O resultado inicial com falha e o resultado final aprovado estão registrados.
• Cada requisito RSS está mapeado para especificação, plano, tarefa e verificação executada.
• Nenhum teste foi enfraquecido para aceitar comportamento incorreto.
• A validação de URL não faz solicitações remotas.
• As adaptações de stack estão identificadas como propostas ou executadas.

Solução de problemas

Use os nomes de skills gerados, não comandos com ponto copiados de outra versão. Não “corrija” um teste de URL inválida aceitando strings arbitrárias. Se o modelo adicionar um banco de dados ou um buscador de conteúdo, pare e reafirme as exclusões.

Prática independente

Implemente o mesmo contrato em uma segunda stack ou adicione a exclusão de assinaturas como uma nova especificação. Mantenha uma tabela de rastreabilidade mostrando quais verificações originais permanecem.

Restauração

Salve as evidências de falha/aprovação. Restaure somente as alterações de implementação na cópia descartável ou prepare uma nova cópia. Não execute a inicialização do Specify na raiz do currículo.

Referências oficiais

• Spec Kit v1.0.4
• Referência de integração
• Fluxo da constituição
• Planejamento de agentes