Comandos reproduzíveis

O comando como contrato de execução

Um comando reproduzível informa onde executar, o que precisa existir, qual ação realiza, como reconhecer sucesso e o que fazer quando falha. Seu nome isolado não basta. npm run validate, por exemplo, depende de um script definido no pacote. Escrever esse nome numa documentação sem fornecer a implementação transforma uma instrução em promessa vazia.

O código de saída comunica o resultado de um processo ao sistema que o iniciou. Para as verificações deste pacote, zero indica conclusão bem-sucedida e um valor diferente de zero indica falha. A saída textual explica o diagnóstico. Não procure apenas uma palavra tranquilizadora no meio do log: examine o resultado final e a consequência para os critérios.

Alguns comandos permanecem em execução. npm start inicia o servidor local e normalmente continua ocupando o terminal até ser encerrado. Não devemos exigir que ele termine com zero para declarar que o servidor está atendendo. A evidência adequada inclui resposta no endereço previsto e comportamento observado; a ausência de uma mensagem de erro não comprova o fluxo.

Contrato preenchido dos comandos oficiais

Esses contratos pertencem ao pacote entregue. Snapshot significa uma cópia de referência para o exercício de recuperação; restore reaplica essa referência apenas no sandbox. Os nomes não autorizam usá-los em produção. O alcance técnico do comando deve corresponder à documentação, e seu resultado precisa ser conferido em vez de presumido.

Execução desde uma entrada conhecida

node --version
npm ci
npm test
npm run validate
npm start

Abra primeiro o terminal dentro da pasta pratica, conforme o README. Execute um comando por vez, examine o resultado e trate a falha antes de continuar como se houvesse aprovação. Com o servidor ativo, abra o endereço local indicado e confirme a listagem. Para encerrar o servidor no terminal, use Ctrl+C. Uma porta ocupada ou um comando executado na pasta errada deve produzir investigação da causa, não alteração aleatória no código.

O registro deve identificar diretório, comando, ambiente, versão do projeto, saída e conclusão. Para um teste automatizado reprovado, conserve qual cenário falhou e seu resultado. Para teclado e feedback acessível, acrescente passos e observações manuais; nenhum comando da tabela transforma essas verificações em conformidade automática. S19, documentação do test runner e da interface de linha de comando do Node, explica o mecanismo usado pelo pacote.

Procedimento de diagnóstico

• Confira se está no diretório que contém o package.json do projeto e se os arquivos esperados estão presentes.
• Leia a primeira causa relevante e o resultado final, sem apagar o diagnóstico antes de compreendê-lo.
• Diferencie ambiente, instalação, sintaxe, dado, teste e comportamento integrado.
• Corrija a causa com escopo explícito; execute novamente a verificação afetada e as regressões necessárias.
• Registre tentativas e limites. Saída esperada num exemplo não deve ser apresentada como saída observada.

Erros e reparos

Exercício com dados e solução

Dados: a pessoa abre o terminal na pasta pai de pratica e recebe falha ao executar npm run validate. Depois entra em pratica, instala de modo coerente, executa os testes e encontra um cenário reprovado: um registro inativo aparece na lista pública. Quais são os dois problemas e qual o próximo gate?

Leitura relacionada

Consultar S14, descrição de npm ci, S19, test runner e linha de comando do Node, e S13, orientação de remoção de dados sensíveis. Um registro de execução não deve criar uma exposição para demonstrar que funciona.