Perfil Estruturado

Coordenar dados mudanças e responsabilidades

O Perfil Estruturado torna explícitos os contratos e os controles que permitem a pessoas diferentes alterar um sistema sem depender de memória individual. Pipeline é uma sequência definida de verificações e tarefas. Schema é o contrato da forma de um dado. Observabilidade, neste contexto de estudo, significa conseguir relacionar um resultado visível ao estado e às ações que o produziram. Os termos não exigem automaticamente serviços externos ou uma plataforma complexa.

A Oficina Caracol continua sem cadastro, banco externo ou dados pessoais. Podemos aumentar a disciplina de mudança sem fingir que construímos uma aplicação empresarial. Os papéis de autor, revisor e operador usados neste capítulo pertencem ao processo do exercício. Eles não representam contas ou permissões implementadas na interface. Se uma pessoa acumular papéis, o registro precisa dizer isso; não haverá revisão independente por simples troca de rótulo.

Caso trabalhado do contrato de dados

A mudança proposta é acrescentar um caso público. Cada registro deve conter exatamente id, titulo, descricao e ativo, com três strings não vazias e um booleano; os IDs são únicos. O exemplo a seguir é entrada didática válida. A conferência efetiva usa o validador do pacote.

{"id":"oc-exemplo","titulo":"Revisão de catálogo","descricao":"Serviço fictício para aprender validação.","ativo":true}

Se o autor escrever ativo como a string "true", a entrada viola o contrato mesmo que o texto pareça convincente. Se acrescentar um campo chamado contato, a propriedade extra também será rejeitada. O esquema deliberadamente estrito torna a divergência observável e mantém o exercício sem dados pessoais. Não contorne o validador apenas para fazer uma mudança passar.

Procedimento estruturado

• Defina o impacto da alteração e quais requisitos e consumidores podem ser afetados. Acrescentar conteúdo válido difere de mudar a forma dos objetos.
• Registre a decisão de contrato. Se houver mudança incompatível, identifique como os consumidores serão adaptados antes de publicar outra forma de dado.
• Mantenha a validação automática no caminho de entrega. No projeto, npm run validate verifica sintaxe, dados e testes; a execução real precisa ser registrada.
• Faça o caminho integrado: o servidor lê os dados, a resposta pública contém apenas os campos autorizados e a interface apresenta o estado correspondente.
• Separe aprovação de conteúdo, evidência técnica e decisão de liberação. Uma pessoa pode executar mais de uma etapa, mas cada resultado precisa continuar reconhecível.

Métricas que respondem a perguntas

Uma métrica é uma medida escolhida para orientar uma decisão. Para este caso, pergunte quantos registros inválidos foram identificados na proposta, quais verificações obrigatórias falharam e se a tarefa pública foi concluída. Contar linhas de código não responde a essas perguntas. Uma execução sem erro não comprova preferência do usuário, disponibilidade prolongada nem segurança para produção. A interpretação acompanha o número; não nasce do painel.

Erros e reparos específicos

• Criar um painel de administração antes de definir quem pode publicar amplia o escopo e deixa o compromisso ambíguo. Reparo: manter neste exercício a alteração por arquivo e documentar a aprovação do conteúdo.
• Alterar o contrato e só depois procurar consumidores produz falhas de integração. Reparo: mapear servidor, navegador e testes antes da mudança e validar o conjunto.
• Guardar somente a frase tudo passou impede investigação. Reparo: registrar comandos, contexto, resultados e artefatos de saída, distinguindo cada execução.

Evoluir as expectativas de teste

Os testes entregues conferem os identificadores públicos previstos para a versão de exemplo. Ao adicionar um novo caso ativo, amplie explicitamente o escopo para atualizar as expectativas de tests/catalogo.test.mjs e tests/servidor.test.mjs. Inclua o novo identificador no resultado esperado e mantenha a verificação de que o inativo continua oculto. Essa atualização acompanha uma mudança legítima de requisito; apagar a asserção de exclusão eliminaria uma proteção necessária.

Gate e exercício resolvido

Avance quando o contrato estiver explícito, a proposta de conteúdo estiver autorizada no cenário real, as verificações aplicáveis estiverem aprovadas e a integração pública preservar os requisitos. M5 exige verificações aplicáveis aprovadas ou exceção explícita não impeditiva; M6 requer a integração comprovada, não apenas um plano.

Exercício: há dois registros com o mesmo id, um campo email extra e a informação de que o navegador abriu. O revisor pede liberação. Qual é sua decisão?