Política Integrada de Mudanças dos Artefatos do LAC

1. Finalidade e princípio

Estabelecer um procedimento proporcional, verificável e governado por pessoas para controlar mudanças nos artefatos do LAC, preservando coerência entre finalidade, requisitos, planejamento, modelos, implementação e evidências.

Regra central: toda mudança deve identificar o artefato de referência, avaliar os artefatos relacionados e registrar a decisão. Revisar impacto não significa alterar todos os documentos.

Esta política é uma proposta v1.0, sujeita à aprovação humana; sua existência como arquivo não equivale à homologação nem à publicação no site.

2. Abrangência e precedência

Aplicável, como referência inicial, aos cinco documentos da Engenharia da Página Web do LAC, listados abaixo. Poderá ser estendida a outros domínios após validação. Não substitui regras de integridade física, versionamento, ambientes, publicação ou segurança já adotadas no LAC; conflitos deverão ser registrados e resolvidos pela governança responsável.

Autoridade da informação: cada documento é a fonte principal de suas próprias decisões. A política controla como as mudanças são avaliadas; não redefine o conteúdo técnico desses documentos.

3. Critérios transversais para atualizar

Necessidade

Nova demanda, lacuna, defeito, evidência ou mudança de contexto justifica a alteração?

Responsabilidade

Qual artefato é fonte principal da informação e quem decide sobre ela?

Impacto

Quais requisitos, modelos, testes, links, papéis e versões podem ser afetados?

Consistência

Há contradição entre propósito, requisitos, plano, método e contrato?

Rastreabilidade

É possível seguir a origem, a decisão, os arquivos e as evidências?

Validação

Como demonstrar que a mudança atende aos critérios de aceitação?

Classes de mudança: editorial (forma sem alteração de significado), corretiva (erro ou não conformidade), evolutiva (novo conteúdo ou capacidade), estrutural (fronteiras, modelos, processos ou contratos) e urgente (risco que exige contenção imediata). A classe orienta a profundidade da análise; não dispensa o registro.

4. Critérios específicos por documento

Artefato	Informação sob sua responsabilidade	Gatilho de atualização	Exemplo que normalmente não exige atualização
Brief	Finalidade, público, problema, escopo, limites e resultados esperados	Mudança de propósito, público, escopo, pressupostos, fontes essenciais ou compromisso de aceitação	Mudança interna de tecnologia sem alterar finalidade e escopo
Plano de Elaboração	Abordagem, etapas, responsáveis, dependências, riscos, entregáveis e marcos	Alteração de sequência, esforço, prioridades, riscos, recursos, entregáveis, responsáveis ou controles	Correção textual sem efeito no trabalho
Especificação de Requisitos	Requisitos identificados, critérios verificáveis, prioridade e rastreabilidade	Inclusão, alteração, retirada, conflito, não conformidade ou mudança de critério de aceitação	Refatoração técnica que preserve requisitos e comportamento contratado
Engenharia da Página Web	Método, conceitos, categorias, arquiteturas, processos e modelos	Mudança de conceito, princípio, processo, classificação, arquitetura, definição dos modelos ou fluxo metodológico	Replanejamento isolado de uma página que não altere o método
Contrato dos Cinco Modelos	Responsabilidades, entradas, saídas, invariantes, interfaces e validações dos modelos	Mudança de fronteira, artefato obrigatório, relação, invariante, exceção ou critério de validação	Nova aplicação que cumpra integralmente o contrato vigente

A coluna “não exige” presume análise de impacto sem alteração material do compromisso registrado. Mudanças aparentemente técnicas podem exigir revisão se afetarem acessibilidade, privacidade, segurança, desempenho ou outro requisito.

5. Matriz de impacto orientativa

R = revisão obrigatória; C = revisão condicional, conforme efeito comprovado; — = revisão normalmente dispensável. “Revisão” é a análise; apenas resultados que mudem a informação exigem edição.

Evento	Brief	Plano	Requisitos	Engenharia	Contrato
Mudança de finalidade	R	R	R	C	C
Mudança de escopo	R	R	R	C	C
Novo requisito	C	C	R	C	C
Nova prioridade ou etapa	—	R	C	—	—
Novo conceito ou princípio	C	C	C	R	C
Mudança de modelo	C	R	C	R	R
Mudança de invariante ou validação	C	R	R	R	R
Correção de implementação	—	C	C	C	C
Teste não conforme	C	R	R	C	C

Se o evento não estiver previsto na matriz, o responsável deve classificar a mudança, justificar a análise e registrar a decisão. Não tratar “—” como autorização para ignorar efeitos conhecidos.

6. Processo integrado de controle

Solicitar: registrar demanda, origem, motivo e evidências.
Classificar: definir tipo, urgência e alcance.
Identificar a referência: localizar o documento que responde pela informação.
Analisar impacto: aplicar matriz, conferir relações, requisitos, modelos, testes, links e governança.
Decidir: aprovar, rejeitar, adiar ou pedir complementação, com justificativa humana.
Executar: editar os artefatos necessários, preservar versões e registrar decisões.
Verificar e validar: testar consistência, rastreabilidade, integridade dos links e critérios aplicáveis.
Publicar e acompanhar: somente após aprovação, conferir ambiente de destino e registrar o resultado.

Urgências: uma contenção pode preceder a revisão completa quando houver risco relevante; a regularização documental, a análise de impacto e a validação continuam obrigatórias antes do encerramento.

7. Registro mínimo de mudança

Campo	Conteúdo mínimo
ID e data	Identificador único e abertura da solicitação
Origem e justificativa	Quem solicitou, necessidade, problema e evidência
Classificação	Editorial, corretiva, evolutiva, estrutural ou urgente
Artefato principal	Fonte da informação afetada
Impacto	Lista de artefatos revisados e decisão por artefato: alterar / não alterar + motivo
Decisão e responsável	Aprovada, rejeitada, adiada ou em complementação; responsável humano e data
Execução	Versões anterior e nova, arquivos alterados, dependências
Evidências	Verificações, testes, não conformidades e aceitação
Publicação	Ambiente, data, URL verificada ou pendência explícita
Situação	Proposta, em análise, aprovada, implementada, validada, publicada, encerrada ou rejeitada

Exemplo de identificação: MC-PW-2026-001. O código é uma convenção proposta; deve ser alinhado às regras gerais de identificação do LAC.

8. Papéis, aprovação e versionamento

Solicitante: apresenta a necessidade e suas evidências.
Responsável pelo artefato: avalia e propõe a alteração, incluindo impacto.
Revisores: verificam coerência, qualidade, requisitos e relações afetadas.
Autoridade de aprovação humana: decide sobre mudanças e autoriza a publicação; a designação concreta depende da governança do LAC.
IA: pode apoiar análise, comparação e verificação, mas não homologa mudanças nem substitui aprovação humana.

Versionamento: registrar revisão, data, motivo, decisão e arquivos envolvidos. Uma mudança de significado, contrato ou interface exige versão identificável; correções editoriais podem usar revisão menor, conforme a política geral de versões que estiver vigente.

9. Implantação inicial na Engenharia da Página Web

Registrar a política na pasta /governanca/politicas/ como proposta v1.0.
Incluir links de referência nos cinco documentos e no índice da Página Web, sem declarar homologação.
Revisar o Brief e a Especificação de Requisitos, verificando lacunas e critérios de aceitação.
Atualizar o Plano para incorporar a atualização dos cinco modelos e sua validação.
Atualizar Engenharia da Página Web e Contrato dos Cinco Modelos, com rastreabilidade e evidências.
Submeter a política e a integração aos responsáveis pela governança; depois conferir publicação e links no site.

Condição de conclusão: documento aprovado, registro de mudança preenchido, impacto analisado, links verificados no ambiente publicado e evidências preservadas. Nenhuma dessas condições é presumida pelo simples fornecimento deste HTML.