flriancu/claude-code-setup

Início de requisitos

O usuário resolve decisões explicitamente e de forma barata no início, e depois constrói em etapas revisadas. Uma construção única inclui suposições que ele terá que desfazer depois. Longa deliberação silenciosa antes de colocar qualquer coisa no papel também o incomoda ('não precisa de tentativa única, por que pensar tanto? vamos rascunhar um documento com fases'). Então coloque perguntas e um plano no papel rapidamente, e deixe-o guiar.

1. Recolha brevemente

• Leia o que foi fornecido: arquivos, pastas, links, imagens, conversas anteriores e notas de memória, o README do repositório. Anote o que já está decidido para não perguntar novamente.
• Se uma entrada ainda estiver faltando ('link a seguir', 'foto chegará depois'), inicie as perguntas mesmo assim e marque quais dependem dela.
• Ainda não escreva código nem altere arquivos. Não delibere longamente: as perguntas são a ferramenta de pensamento.

2. Faça perguntas numeradas

• Uma lista numerada, agrupada por tópico quando houver muitas. Cada pergunta é uma linha com as opções que você vê e sua recomendação padrão, por exemplo: 3. Local de instalação: C: ou D:? Recomendado: D:, pois C: está quase cheio.
• O usuário responde de forma concisa por número ('1. ambos 2. atualizar 3. ok'). Mapeie cada resposta de volta cuidadosamente. 'ok' ou 'concordo' aceita seu padrão; 'primeira' e 'última' referem-se à ordem das suas opções; um número pulado significa 'você decide, me diga o que escolheu'.
• Cubra o que importa para este esforço: objetivo e público-alvo; escopo e não-objetivos explícitos; entradas e saídas (formatos, locais); restrições (plataforma, ferramentas permitidas ou proibidas, licenças, uso offline, hardware); nível de qualidade e teste de aceitação ('como saberemos que funciona'); comportamento de falha (o que acontece quando cada parte falha a qualquer momento: uma falha, uma conexão perdida, um corte de energia, um nó entre vários caindo); fidelidade (o que nunca deve ser alterado); onde as coisas residem (repositório, caminhos, remoto); entrega (quem recebe o quê, com que frequência).
• Execute uma segunda rodada mais curta apenas para respostas que abriram novas perguntas. Pare de perguntar quando as incógnitas restantes tiverem padrões seguros e liste esses padrões.

3. Escreva o contrato: REQUIREMENTS.md

Coloque-o na raiz do projeto, criando a pasta se o projeto for novo. Mantenha-o simples, curto e datado:

# Requisitos do <Projeto>

Acordado em <AAAA-MM-DD>. Este arquivo é o contrato; alterações são registradas aqui com uma data.

## Objetivo
## Público-alvo e uso
## Escopo
## Não-objetivos
## Decisões
- D-01 <decisão> (<data>)
## Requisitos funcionais
- RF-01 ...
## Restrições e requisitos não funcionais
- RNF-01 ...
## Verificação
Uma linha por requisito: como é verificado e onde a evidência está armazenada.
| ID | Método (teste / inspeção / análise / demonstração) | Evidência (caso de teste, script, arquivo) |
## Perguntas em aberto

IDs estáveis (D-xx, RF-xx, RNF-xx) permitem que trabalhos posteriores, commits e relatórios os citem. Registre as respostas do usuário nos próprios termos deles; não os parafraseie para algo mais forte ou mais fraco.

Forneça a cada requisito um método de verificação e um local de evidência. Os quatro métodos são os padrões da engenharia de requisitos (ISO/IEC/IEEE 29148). Prefira um teste. Quando um requisito só puder ser verificado por inspeção ou análise ('sem chamadas diretas ao thread do SO', 'sobrecarga de agendamento abaixo de 100 microssegundos por nó'), escreva a verificação como um script que salve sua saída como evidência, para que a prova possa ser reexecutada em vez de reargumentada.

4. Escreva o plano: fases

Coloque-o ao lado dos requisitos em PLAN.md, ou em uma seção 'Fases' quando o projeto for pequeno. A Fase 0 geralmente é a configuração inicial, ou um piloto que prova a suposição mais arriscada primeiro. Para cada fase, dê o objetivo, os passos, a entrega, como é verificada e os IDs dos requisitos que atende. Mantenha as fases pequenas o suficiente para serem revisadas em uma só sessão, e diga que o plano será ajustado no caminho.

Em seguida, pare. Relate os dois arquivos em algumas linhas e recomende a primeira fase.

5. Execute sob demanda, uma fase de cada vez

• Execute apenas as fases que o usuário nomear ('execute fase 0', 'execute fases 0 e 1', 'vai').
• Ao final de cada fase, relate o que foi feito, a evidência de que funciona (comandos executados, saídas, resultados de teste), o que se desviou do plano e por quê, e o que vem a seguir. Marque a fase como concluída no plano.
• 'verificar progresso' significa: fase atual, o que está feito, o que está rodando, o que está bloqueado.
• Um novo desejo que mude o escopo vai para REQUIREMENTS.md com sua data antes de você construí-lo. Uma decisão revertida é registrada como reversão; a linha antiga permanece.
• Corrija bugs encontrados ao longo do caminho quando o usuário tiver autorizado; caso contrário, apenas os liste.
• Quando a última fase estiver concluída, ou quando o usuário pedir, execute uma passagem de lacunas: requisitos versus código, testes, documentação e evidências. Relate cada lacuna com seu ID de requisito, corrija-as uma a uma sob demanda e reexecute os scripts de evidência.
• Não faça commit ou push após cada passo. Proponha um commit quando uma fase estiver concluída; faça push apenas se solicitado.

Variantes

• Decisões sem código (uma compra, uma escolha de ferramenta): as mesmas perguntas, depois uma breve comparação com os critérios acordados em vez dos dois arquivos.
• Conteúdo de terceiros (o livro de um autor, dados de um cliente, gravações): adicione um requisito de fidelidade antecipadamente. Nada no conteúdo muda silenciosamente; cada alteração é proposta, marcada e reportada para aprovação.