Inventário do estado atual

Existir é diferente de funcionar

Você recebe uma pasta chamada projeto final. Dentro dela há arquivos, imagens e um README. O nome da pasta não comprova conclusão, assim como encontrar um arquivo de teste não comprova que ele passou. Inventariar é construir uma fotografia rastreável do que existe, do que foi examinado e do que permanece desconhecido.

O inventário relaciona artefatos, responsabilidades e observações. Artefato é um resultado identificável de trabalho, como um arquivo de dados, um módulo ou um registro de decisão. Runtime é o ambiente que executa o programa; neste projeto, usamos Node para a parte local e um navegador para a interface. A versão realmente utilizada deve ser registrada a partir da execução, sem copiar um número ilustrativo do livro.

Uma fotografia precisa de referência: qual cópia, qual revisão e em que ambiente foi examinada? Controle de versões pode identificar a revisão; uma soma de verificação pode identificar um arquivo recebido. Esses identificadores ajudam a conferir a origem, mas não demonstram que o conteúdo é seguro ou correto.

Inspeção antes de execução

• Preserve o material recebido e trabalhe numa cópia separada. Não apague o original para organizar a análise.
• Liste arquivos e examine README, package.json e o código relevante antes de executar comandos do projeto. Scripts podem realizar ações além do que seu nome sugere.
• Se houver ZIP, confira as entradas antes de extrair: destinos não devem escapar da pasta de trabalho nem substituir arquivos externos; examine links e evite executar conteúdo desconhecido.
• Identifique os caminhos oficiais e separe presença, inspeção textual e execução verificada.
• Depois de entender o pacote de estudo, registre node --version e execute os comandos oficiais necessários ao diagnóstico. Preserve os resultados reais, inclusive falhas.
• Relacione cada lacuna ao impacto na decisão seguinte. Um arquivo desconhecido não pode ser removido só por não ter finalidade evidente.

Inventário preenchido de um cenário

A tabela fornece observações hipotéticas para praticar a classificação. Não relata uma execução desta edição. Caminhos são relativos à pasta pratica; a revisão e a versão do runtime deverão receber os valores observados pelo aluno.

O arquivo de lock registra informações da instalação e da resolução do pacote, mesmo que esta oficina não use dependências externas. Sua presença não é uma aprovação das bibliotecas nem substitui a leitura dos scripts. O inventário evita transformar um nome técnico em selo de confiança.

Da lacuna à decisão

Suponha agora que o enunciado forneça um teste aprovado de seleção e uma falha ao iniciar o servidor. Podemos planejar a investigação do servidor sem reconstruir a seleção. Ainda não podemos dizer que o visitante consulta o catálogo: a capacidade depende da integração. Registre a falha com comando, revisão, ambiente e mensagem pertinente; mantenha o estado integrado como não demonstrado.

Condição para propor a alteração

O inventário é suficiente para uma mudança quando os artefatos afetados, as dependências importantes e as lacunas impeditivas estão identificados. Não é necessário conhecer cada byte para corrigir uma mensagem; é necessário conhecer o caminho dessa mensagem e os efeitos da alteração. Lacunas fora desse caminho podem permanecer registradas com justificativa.

Exercício com classificação

Recebemos as seguintes informações: data/casos.json foi localizado, npm test não foi executado e a página abriu, mas ninguém observou serviços inativos. Classifique a afirmação o catálogo está correto e escreva duas próximas verificações.

Referências para aprofundamento

Apoio: S07, Git Basics, seção Recording Changes to the Repository, para relacionar observações à revisão preservada; S14, documentação do comando npm ci, para entender instalação e scripts; e S19, opções de linha de comando do Node, para consultar a versão do runtime.