Pipeline C • Evolução do Sistema (Governança)

Processo repetível para transformar necessidade/feedback em mudança controlada do OLA — com análise de impacto, decisão, implementação, testes, publicação de versão e registro (rastreabilidade).
↩︎ Hub de Processos ↩︎ Portal Interno ↩︎ Governança

Finalidade, entradas e saídas

Este pipeline mantém o OLA evoluindo sem perder organização: cada mudança importante vira decisão registrada e versão controlada.

Finalidade
Evoluir o sistema com segurança: priorizar, decidir, implementar e publicar mudanças mantendo histórico e rastreabilidade.
Entrada (gatilhos comuns)
Feedback do aprendiz • bug • melhoria visual • nova necessidade • entropia estrutural • novo padrão/contrato • mudança de diretórios.
Saída (artefatos)
Decisão registrada • item no portfólio (WIP) • mudança implementada • teste realizado • versão publicada • atualização do Portal.
Critério de qualidade
Impacto conhecido • risco controlado • versão rastreável • rollback possível • consistência com padrões e axiomas. 
Detectar → Analisar impacto → Decidir → Planejar → Implementar → Testar → Publicar versão → Registrar
Regra prática: mudança que afeta navegação, estrutura, padrões ou processos do OLA deve virar decisão (registrada).
Onde fica na estrutura
/governanca concentra o Pipeline C: /governanca/portfolio (prioridades/WIP), /governanca/projeto (execução), decisoes_log (registro), /legado (histórico/versões).
Atalhos práticos
WIP → escolher a próxima mudança • Registro → documentar decisões • Portal → refletir a mudança para navegação do usuário.
Ver os 8 passos do pipeline ↓ Análise de impacto e risco (modelo rápido) ↓ Artefatos e caminhos (onde salvar) ↓
Dica: para mudanças pequenas, o registro pode ser curto (nível 1). Para mudanças estruturais, use nível 2.

Passos do Pipeline C (8 etapas)

Um ciclo simples de governança: identificar, decidir, executar e registrar — sem burocracia, mas com rastreabilidade.

1) Detectar necessidade (sinal)

Entrada: sinal

Capturar o que motivou a mudança: bug, feedback, melhoria, reorganização, novo padrão.

Entradas

  • Feedback do uso real
  • Problema recorrente
  • Nova decisão de arquitetura

Saídas

  • Descrição do sinal
  • Link/print/evidência

2) Analisar impacto (o que muda e quem afeta)

Saída: impacto

Mapear páginas afetadas, risco de quebrar links, impacto em navegação e consistência visual.

Entradas

  • Descrição da necessidade
  • Estrutura de pastas atual

Saídas

  • Lista de afetados (páginas/pastas)
  • Risco (baixo/médio/alto)

3) Decidir (registrar o “sim” e o “por quê”)

Saída: decisão

Escolher a alternativa e registrar: motivação, critérios, impacto e caminho.

Entradas

  • Análise de impacto
  • Alternativas

Saídas

  • Registro no log
  • Nível 1 ou Nível 2

4) Planejar (o que fazer, em que ordem)

Saída: plano

Criar um plano curto: tarefas, ordem, verificação, rollback (se necessário).

Entradas

  • Decisão
  • Lista de afetados

Saídas

  • Itens no WIP
  • Ordem de execução

5) Implementar (mudar com cuidado)

Saída: mudança

Executar as alterações: HTML/CSS/JS, links, breadcrumbs, estrutura, padrões.

Entradas

  • Plano
  • Base do padrão OLA

Saídas

  • Arquivos alterados
  • Versão incrementada (se aplicável)

6) Testar (não quebrar o que já funcionava)

Saída: teste

Checar links, breadcrumbs, tema, responsividade, console, páginas críticas (home/portal/índices).

Entradas

  • Arquivos alterados
  • Checklist de teste

Saídas

  • Status (OK/pendências)
  • Correções rápidas

7) Publicar versão (promover e refletir no Portal)

Saída: versão

Publicar e atualizar entradas: portal.html, índices, links, cards, e (se necessário) legado/histórico.

Entradas

  • Teste ok
  • Padrões atualizados

Saídas

  • Nova versão ativa
  • Portal atualizado

8) Registrar (rastreabilidade e aprendizado do sistema)

Saída: histórico

Fechar o ciclo: registrar o que foi feito, por quê, e qual o efeito. Se virou padrão, promover para /arquitetura.

Entradas

  • Versão publicada
  • Resultados do teste

Saídas

  • Entrada no log de decisões
  • Atualização do WIP (feito)

Análise de impacto e risco (modelo rápido)

Use isso para decidir se o registro é nível 1 (curto) ou nível 2 (completo), e para evitar quebrar o portal.

Perguntas mínimas (check)

Impacto em navegação

Vai quebrar links/breadcrumbs? Afeta Home/Portal/Índices?

Impacto em padrão visual

Muda CSS global, tema, componentes? Afeta muitas páginas?

Impacto em estrutura

Mexe em pastas, nomes de arquivos, redirecionamentos, legado?

Risco e rollback

É fácil voltar? Existe versão anterior salva? Há plano de fallback?

Heurística: se afetar “porta de entrada” (index/portal) ou estrutura de pastas, trate como impacto alto.

Nível 1 vs Nível 2 (registro)

Nível 1 (curto):
- O que mudou
- Por quê
- Onde (arquivos/pastas)
- Resultado do teste (ok)

Nível 2 (completo):
- Contexto + necessidade
- Alternativas consideradas
- Critérios e trade-offs
- Impacto (páginas afetadas)
- Plano + testes
- Decisão final + rastreio
Dica: mudanças que viram “padrão” do OLA (arquitetura/contratos/componentes) quase sempre pedem Nível 2.

Artefatos e caminhos (onde salvar)

Uma estrutura prática para fazer o Pipeline C funcionar no dia a dia.

Estrutura recomendada

/governanca/
  index_governanca.html

  /portfolio/
    /wip/                (backlog/itens em andamento)
    index_portfolio.html

  /projeto/              (execução das mudanças)
    index_projeto.html

  decisoes_log.md        (ou .html)
  riscos.html            (opcional)

/legado/                 (versões antigas / histórico)
  index_legado.html
Essencial: toda decisão que muda estrutura, navegação ou padrão precisa deixar rastro em decisoes_log.

O que atualizar quando publicar

Portal
Atualizar cards/links para refletir a mudança “ativa”.
Índices
Atualizar índices (governança, arquitetura, aprendiz, autor) se o conteúdo mudou de lugar.
Breadcrumbs
Conferir caminhos relativos/absolutos após mover arquivos.
Legado
Se houve troca de “versão ativa”, guardar a anterior e apontar o histórico.
Regra prática: sempre teste Home + Portal + 1 página de cada grande pasta (autor/aprendiz/arquitetura/governança).