Fonte única de verdade

Autoridade por assunto

Há um preço no arquivo de dados, outro numa planilha e outro escrito diretamente na página. Qual deve orientar a correção? A fonte única de verdade é uma regra de autoridade para um domínio de informação. Domínio, neste contexto, é um assunto delimitado: requisitos, registros de catálogo, decisão arquitetural ou resultado de execução.

Não se trata de reunir tudo num arquivo enorme. Requisitos explicam o que o produto deve fazer; dados fornecem os registros; código realiza transformações; evidências mostram o que foi observado. São autoridades distintas para perguntas distintas. A implementação atual não pode revogar silenciosamente um requisito só porque já funciona de outra maneira.

Cópias podem ser necessárias. O navegador recebe uma representação pública dos casos e a usa para desenhar cartões. Essa representação é derivada: não deve virar um segundo cadastro editado manualmente. Uma cópia precisa de origem reconhecível e de uma política de atualização.

Mapa preenchido da Oficina Caracol

A tabela distribui autoridade sem afirmar que cada documento está sempre atualizado. Se a documentação de um contrato diverge do código, existe uma inconsistência a resolver; o mapa aponta os responsáveis e as verificações necessárias, não elimina a investigação.

Um conflito resolvido sem esconder a mudança

Considere este cenário fornecido: data/casos.json registra Oficina de testes como ativa; a página mostra um cartão antigo marcado como indisponível. A pessoa responsável pelo conteúdo confirma que o registro oficial está correto. A correção deve remover a cópia manual da interface e fazê-la consumir a saída pública. Alterar o JSON para combinar com o cartão apenas faria a origem imitar uma cópia desatualizada.

Há outro conflito possível: o dado marca um serviço como inativo e a resposta pública o revela. Nesse caso, a origem não precisa ser corrigida para ativo. É a transformação que contradiz REQ-002. Identificar a pergunta é essencial: estamos investigando o estado do serviço ou o cumprimento da regra de publicação?

• Liste os assuntos que precisam de uma autoridade.
• Aponte a origem e quem pode alterá-la.
• Identifique cópias e consumidores que dependem dela.
• Defina como detectar inconsistências e quem decide o conflito.
• Ao mudar a origem ou o contrato, atualize as derivações e repita as verificações afetadas.

Dados públicos não são o arquivo inteiro

O contrato real do módulo usa registros com id, titulo, descricao e ativo. A função listarAtivos devolve somente os campos públicos id, titulo e descricao dos serviços ativos. A fonte pode conter serviços inativos para manter o acervo didático, mas eles não precisam chegar ao navegador. A seleção deve acontecer antes da resposta pública; esconder cartões com CSS não protege um dado já entregue.

Condição de avanço e exercício

Uma mudança de informação pode avançar quando a origem legítima, o responsável e as derivações afetadas estão identificados. Ao encerrar, confirme que a interface representa a fonte através da regra correta. Não basta eliminar diferenças visuais: é preciso preservar a finalidade de cada domínio.

Exercício: o JSON mantém c02 inativo; um cartão escrito no HTML mostra c02; o README afirma que a página usa a API. Indique três perguntas de investigação e a correção mais provável, sem assumir que o README já prova o funcionamento.

Referências para aprofundamento

Consulte S01, Software Configuration Management, para identificação e controle da configuração; e S07, Git Basics, para preservar o histórico das alterações. O mapa de autoridades é a decisão local desta oficina.