Evitar decisões isoladas
Registrar critérios para que novas páginas, grafos, menus e blocos sigam uma lógica comum.
Quadro de Regras do OLA
Este quadro registra regras institucionais para manter o OLA consistente como sistema de conhecimento em evolução. As regras nascem na Governança, orientam a Arquitetura, os Fundamentos e os padrões e são aplicadas nos templates, páginas concretas, mapas, domínios, trilhas e artefatos.
Regra como conhecimento
Cada regra funciona como decisão de modelagem: orienta vocabulário, estrutura, visual, navegação, classificação e coerência semântica.
Checklist de construção
Antes de publicar ou revisar uma página OLA, use este quadro como lista de verificação.
Problema resolvido: sem um quadro de regras, cada página poderia adotar navegação, layout, vocabulário, notação, privacidade e fechamento de ciclo de forma isolada. Este quadro transforma decisões recorrentes em critérios explícitos e reutilizáveis.
Onde este quadro nasce e como se propaga
Governança
Define regras e critérios. Este arquivo é a referência principal.
Arquitetura
Transforma regras em padrões de navegação, interface, grafos e estrutura.
Templates e páginas
Aplica e materializa as regras em HTML, conteúdo, experiência, vocabulário e artefatos.
Como este quadro aplica suas próprias regras
Esta seção explicita a aplicação das próprias regras de governança nesta página. Ela funciona como uma revisão interna de coerência entre regra declarada, layout, navegação, conteúdo e uso.
| Dimensão revisada | Regra aplicada | Como aparece nesta página | Status |
|---|---|---|---|
| Navegação | NAV-01, NAV-02, NAV-03 | Há breadcrumb físico, breadcrumb semântico, menu por categorias e páginas relacionadas no final. | Alinhado |
| Layout | LAY-01, LAY-02, LAY-05 | Cabeçalho identifica o sistema e a página; seções longas têm menu; tabelas largas possuem rolagem horizontal. | Alinhado |
| Conteúdo | CONT-03, CONT-04, CONT-07 | A página apresenta finalidade, análise, uso, checklist, próximas ações e páginas relacionadas separadas. | Alinhado |
| Notação | NOT-01, NOT-02 | A seção de notação registra regras para símbolos consolidados e referência para semantica_seta.html. |
Alinhado |
| Governança estrutural | CICLO-01, CICLO-03, CICLO-05 | O quadro atua como resumo consultável de regras derivadas de páginas explicativas e canônicas, incluindo a decisão sobre processos transversais. | Alinhado |
| Oportunidade de melhoria | LAY-02, NAV-03 | O menu superior estava ficando extenso. A versão revisada mantém os links, mas reconhece que uma futura versão pode usar menu recolhível. | A avaliar |
✓
Checklist de autoaplicação: a página mostra onde está, para que serve, como usar,
quais regras contém, quais ações ainda existem e quais páginas já servem de referência.
Regras de grafo
Critérios para grafos D3.js, redes semânticas, glossários em grafo e mapas OLA.
| ID | Regra | Objetivo | Aplicação | Critério de aceite |
|---|---|---|---|---|
| GRAFO-01 | Todo grafo deve ter finalidade explícita. | Evitar grafo decorativo ou confuso. | Mapa OLA, glossário, domínio. | Há seção “Como usar o mapa/grafo”. |
| GRAFO-02 | Arestas devem ter predicado. | Transformar conexão visual em relação semântica. | Grafos de conhecimento. | O usuário entende o que significa A → B. |
| GRAFO-03 | Grafo interativo deve ter descrição ao clicar. | Evitar dependência apenas da forma visual. | D3.js e grafos clicáveis. | Clicar no nó exibe descrição e relações. |
| GRAFO-04 | Grafos densos precisam de zoom e centralização. | Melhorar usabilidade em telas diferentes. | Glossários e redes maiores. | Há controles de centralizar e resetar zoom. |
| GRAFO-05 | Força deve evitar espalhamento excessivo. | Manter o grafo legível. | Simulações D3.js. | O grafo estabiliza sem ramos artificialmente soltos. |
| GRAFO-06 | Impressão deve ter versão estática. | Garantir leitura em A4. | Páginas com botão imprimir. | Existe alternativa estática, tabela ou SVG fixo. |
✓
Checklist: o grafo tem predicados, descrições, controles e alternativa de impressão?
Regras de layout
Critérios visuais e de experiência para páginas OLA consistentes.
| ID | Regra | Objetivo | Aplicação | Critério de aceite |
|---|---|---|---|---|
| LAY-01 | Cabeçalho deve identificar sistema e página. | Dar orientação e identidade. | Todas as páginas institucionais. | Usuário sabe onde está e como voltar. |
| LAY-02 | Seções longas devem ter apoio de navegação. | Reduzir carga cognitiva. | Páginas com muitas seções. | É possível saltar para partes principais. |
| LAY-03 | Botão voltar ao topo não deve cobrir conteúdo crítico. | Evitar conflito visual e funcional. | Páginas longas com QR Code ou rodapé. | Botão não bloqueia leitura, clique ou câmera. |
| LAY-04 | QR Code deve ficar livre de sobreposição. | Garantir leitura pela câmera. | Páginas publicadas com QR Code. | QR Code aparece inteiro e afastado de botões. |
| LAY-05 | Tabelas largas devem ter rolagem horizontal. | Evitar quebra ruim em telas pequenas. | Matrizes e checklists. | A tabela não estoura a tela. |
| LAY-06 | Modais devem fechar por botão, ESC e clique externo quando possível. | Melhorar acessibilidade. | Como ler, Glossário, Ajuda. | Usuário consegue fechar o modal sem ficar preso. |
✓
Checklist: cabeçalho, navegação, botões fixos, tabelas, modal e impressão estão coerentes?
Regras de conteúdo
Critérios para origem, análise, segurança, linguagem e rastreabilidade do conhecimento.
| ID | Regra | Objetivo | Aplicação | Critério de aceite |
|---|---|---|---|---|
| CONT-01 | Toda página derivada de entrada deve registrar origem. | Garantir rastreabilidade. | Artefatos derivados de análise. | Existe seção “Entrada do OLA”. |
| CONT-01A | Toda entrada no OLA deve ser classificada. Classificar quanto à natureza, finalidade, privacidade, possibilidade de publicação e potencial de transformação em artefato. | Evitar que perguntas, textos, problemas, contextos ou registros entrem no sistema sem critério de uso, exposição e evolução. | Perguntas, textos, problemas, contextos, objetivos, artefatos existentes, eventos e registros derivados de uso. | A entrada possui classificação mínima antes de gerar página, trilha, mapa, ficha, dashboard, regra ou outro artefato. |
| CONT-02 | Distinguir sugestão, análise e prescrição. | Evitar uso indevido. | Saúde, jurídico, financeiro, educação formal. | Há limites e validação profissional quando aplicável. |
| CONT-03 | Problema resolvido deve aparecer cedo. | Orientar leitura e reduzir ambiguidade. | Páginas-base e domínios. | Usuário entende a finalidade antes dos detalhes. |
| CONT-04 | Finalidade e análise devem ser diferenciadas. | Separar objetivo de interpretação. | Páginas institucionais. | Os dois blocos não repetem a mesma função. |
| CONT-05 | Níveis M0–M3 devem ser usados quando agregarem leitura. | Evitar formalismo excessivo. | Modais e páginas complexas. | M0–M3 ajuda a escolher profundidade. |
| CONT-06 | Próximos passos devem fechar o ciclo de uso. | Transformar conteúdo em ação orientada. | Domínios, saúde, aprendizagem e projetos. | A página orienta continuidade. |
| CONT-07 | Separar “Próximos passos” dos demais blocos recorrentes. “Próximos passos” deve indicar continuidade ou ação pendente. Links de consulta devem ir para “Páginas relacionadas”; resultados concluídos para “Artefatos criados”; problemas abertos para “Pendências”; mudanças realizadas para “Histórico de evolução”. | Evitar mistura entre tarefa, leitura, navegação, resultado concluído e histórico. | Páginas longas, índices, mapas, trilhas, registros de aprendizagem, governança, autor e domínios. | A página separa claramente o que há a fazer, o que já existe para leitura, o que foi criado, o que está pendente e o que pertence ao histórico. |
✓
Checklist: a página registra origem, distingue análise/sugestão/prescrição, explica finalidade e fecha com próximos passos?
Semântica dos blocos recorrentes de página
Esta regra complementa as regras de conteúdo e orienta o uso correto de blocos como Próximos passos, Próximas ações, Páginas relacionadas, Artefatos criados, Pendências, Recomendações e Histórico de evolução.
Regra curta: não usar “Próximos passos” como bloco genérico. Se o item ainda precisa ser feito, usar Próximas ações. Se já existe e serve para leitura, usar Páginas relacionadas. Se já foi produzido, usar Artefatos criados. Se ainda é problema aberto, usar Pendências. Se registra mudança já realizada, usar Histórico de evolução.
Próximas ações
O que ainda precisa ser feito, revisado, criado, atualizado ou validado.
Páginas relacionadas
Links para páginas já existentes que servem para consulta, leitura ou aprofundamento.
Artefatos criados
Páginas, modelos, mapas, trilhas, grafos, regras ou decisões já produzidas.
Pendências e histórico
Pendências guardam problemas ainda abertos; histórico registra mudanças já realizadas.
✓
Checklist: ao revisar uma página, verificar se “Próximos passos”
contém apenas continuidade/ação pendente ou se precisa ser desdobrado em
blocos mais precisos.
Referência detalhada: semantica_blocos_paginas_ola.html.
Regras de privacidade, LGPD e publicação responsável
Critérios para separar conhecimento público, registro pessoal, dado sensível, versão anonimizada e informação que deve permanecer fora do site público.
| ID | Regra | Objetivo | Aplicação | Critério de aceite |
|---|---|---|---|---|
| LGPD-01 | Todo artefato deve ser classificado antes de publicar, armazenar ou compartilhar. Usar os níveis: público, interno, restrito, sensível ou manual/fora do digital. | Evitar que página tecnicamente pronta seja publicada sem decisão de exposição. | Mapas, índices, dashboards, registros, trilhas, artigos, páginas de saúde e experimentos. | O artefato indica sua classificação ou foi revisado pela página classificacao_informacao_ola.html. |
| LGPD-02 | Distinguir conhecimento geral de registro pessoal. Conhecimento conceitual pode ser público; registro pessoal deve ser restrito ou sensível. | Preservar valor educativo sem expor dados pessoais. | Domínios de Saúde, Aprendizagem, Patrimônio, Projeto e registros de uso do OLA. | A página pública usa exemplos genéricos quando a origem for experiência pessoal. |
| LGPD-03 | Dados sensíveis não devem ser publicados. Exames, laudos, diagnósticos, prescrições, dados financeiros, jurídicos e familiares devem ficar fora do site público. | Proteger privacidade, segurança e dignidade das pessoas envolvidas. | Saúde, família, finanças, documentos pessoais, acompanhamento clínico e registros de terceiros. | Não há dado sensível identificável no HTML publicado. |
| LGPD-04 | Separar registro pessoal de interpretação profissional. O OLA pode organizar observações e perguntas, mas não deve apresentar diagnóstico, prescrição ou interpretação clínica como ato profissional. | Evitar confusão entre apoio cognitivo, registro pessoal e decisão técnica especializada. | Saúde, ergonomia, fisioterapia, Pilates, RPG, exames e acompanhamento de sintomas. | A página deixa claro se é registro, pergunta, orientação geral ou conteúdo a validar com profissional. |
| LGPD-05 | Publicar versão derivada, anonimizada ou generalizada quando houver valor educativo. Remover nomes, identificadores, datas críticas, exames e detalhes particulares. | Transformar experiência em patrimônio de conhecimento sem expor pessoas. | Estudos de caso, objetos de aprendizagem, mapas de domínio e páginas metodológicas. | A versão pública não permite identificar pessoa natural por meios razoáveis. |
| LGPD-06 | Em caso de dúvida, manter privado. A dúvida sobre exposição deve bloquear a publicação até revisão. | Aplicar prevenção como regra de governança. | Qualquer página com informação pessoal, sensível, familiar, financeira, jurídica ou estratégica. | A decisão final é: publicar, manter interno, anonimizar, arquivar, excluir ou manter fora do digital. |
✓
Checklist: a página foi classificada, não expõe dados sensíveis e possui decisão clara de publicação?
Regras de vocabulário e linguagem do OLA
Critérios para controlar o uso de termos estruturais, evitar inflação conceitual e manter coerência entre Fundamentos, Governança, Arquitetura, Domínios e páginas concretas.
| ID | Regra | Objetivo | Aplicação | Critério de aceite |
|---|---|---|---|---|
| VOC-01 | Sistema é o vocábulo integrador do OLA. Antes de criar nova área, página, dimensão, camada, eixo ou domínio, identificar qual papel o elemento cumpre no sistema OLA. | Evitar que páginas e conceitos sejam criados de forma isolada. | Fundamentos, Governança, Arquitetura, Domínios, mapas e índices. | A página explica sua função no sistema e suas relações principais. |
| VOC-02 | Dimensão, camada, eixo e nível não são sinônimos. Dimensão analisa; camada compõe; eixo orienta; nível gradua. | Reduzir ambiguidade conceitual. | Mapas, páginas de fundamentos, arquitetura e governança. | O termo usado responde corretamente à pergunta: aspecto, composição, direção ou grau? |
| VOC-03 | Não transformar qualquer aspecto em dimensão. Um termo só deve ser promovido a dimensão quando for estável, recorrente, transversal e diferente dos eixos já existentes. | Evitar crescimento descontrolado do conceito de dimensão. | Governança, fundamentos, arquitetura e páginas de organização. | O termo foi avaliado antes como aspecto, critério, entidade, processo, camada ou eixo. |
| VOC-04 | Vocábulos estruturais devem ter definição controlada. Termos como sistema, ecossistema, ambiente, contexto, projeto, design, método, abordagem e pesquisa devem ser usados com sentido explícito. | Manter unidade semântica do OLA. | fundamentos/vocabulario_ola.html, glossários, mapas e páginas institucionais. | O termo aparece com definição ou está coerente com o vocabulário controlado. |
| VOC-05 | Distinguir vocabulário, linguagem e método. Vocabulário nomeia; linguagem organiza o modo de uso; método orienta o caminho recorrente de produção. | Evitar mistura entre termos, explicação e sequência de trabalho. | Páginas de fundamentos, método OLA, templates e artefatos. | A página deixa claro se está nomeando, explicando ou conduzindo um processo. |
| VOC-06 | Termo novo deve ser testado antes de virar padrão. Um termo pode nascer em experimento, ser usado em páginas, amadurecer em Fundamentos e depois ser regulado pela Governança. | Permitir evolução sem perder controle. | Autor, laboratório, fundamentos e governança. | Há indicação se o termo é hipótese, uso consolidado ou vocabulário controlado. |
✓
Checklist: os termos estruturais usados na página estão definidos, classificados e coerentes com o vocabulário do OLA?
Regras de notação e semântica especializada
Critérios para símbolos e notações consolidadas do OLA.
| ID | Regra | Objetivo | Aplicação | Critério de aceite |
|---|---|---|---|---|
| NOT-01 | Notações consolidadas devem possuir página especializada. Quando uma notação passar a ser recorrente, ela deve possuir definição, significado, exemplos e contexto de uso. |
Evitar uso ambíguo de símbolos. | Fundamentos, grafos, modelos e mapas. | Existe página específica e referência cruzada. |
| NOT-02 | A seta → possui semântica controlada. A seta representa transformação, progressão, fluxo, dependência ou relação direcional explicitada. |
Evitar interpretações diferentes do mesmo símbolo. | Grafos, modelos, pipelines, trilhas e estruturas conceituais. | O significado da seta é consistente entre páginas. |
✓
Checklist: a página usa símbolos e setas com significado explícito?
Referência: fundamentos/semantica_seta.html e fundamentos/sistema_notacional_ola.html
Regras de classificação, interface e semântica
Critérios para diferenciar componente visual, elemento técnico, marcador semântico, categoria, faceta e palavra-chave no OLA.
| ID | Regra | Objetivo | Aplicação | Critério de aceite |
|---|---|---|---|---|
| CLASS-01 | Diferenciar componente visual, elemento técnico e marcador semântico.chip é selo visual de interface; tag HTML é elemento técnico; classe CSS é recurso de estilo; tag semântica é marcador leve de classificação. | Evitar confusão entre aparência, código e classificação do conhecimento. | Páginas com class="chip", class="tag", listas de tags, cards, índices e fichas classificatórias. | A página deixa claro quando um elemento é visual, técnico ou semântico. |
| CLASS-02 | class="chip" não significa tag de classificação.Chip é usado para orientação visual, como nível, estado, tipo de leitura ou destaque. | Impedir que nomes de classes CSS sejam interpretados como categorias conceituais. | Hero, chips M0–M3, selos de seção, destaques de leitura e estados visuais. | O uso de chip aparece como interface; tags semânticas aparecem como #tema ou em ficha classificatória. |
| CLASS-03 | Diferenciar categoria, faceta e palavra-chave. Categoria agrupa de modo mais estável; faceta classifica por dimensão combinável; palavra-chave apoia busca e recuperação. | Melhorar classificação, navegação, busca e governança dos artefatos. | Domínios, páginas estruturais, trilhas, mapas, dashboards e fichas classificatórias. | A página identifica categorias estáveis, facetas de classificação e palavras-chave quando necessário. |
| CLASS-04 | Formas de classificação devem ser escolhidas conforme a necessidade. Classificação agrupa; taxonomia hierarquiza; ontologia relaciona; tesauro padroniza termos; facetas permitem múltiplas leituras; tags associam; palavras-chave recuperam. | Evitar uso indistinto de classificação, taxonomia, ontologia, tesauro, tags e palavras-chave. | Domínio Áreas de Conhecimento, organização de domínios, vocabulário, mapas, grafos e páginas de governança. | A página explicita qual forma de classificação está usando e por quê. |
| CLASS-05 | Ficha classificatória deve ser usada em páginas estruturais quando agregar valor. A ficha pode registrar área de conhecimento, domínio, finalidade, nível OLA, tipo de artefato, público, status, tags e palavras-chave. | Aumentar rastreabilidade, recuperação e coerência entre páginas. | Páginas de domínio, mapas, organizações, taxonomias, ontologias e páginas comparativas. | A página possui ficha classificatória ou justifica sua ausência. |
| CLASS-06 | Regras classificatórias devem ser propagadas para vocabulário, interface e estrutura física. Quando uma distinção virar padrão, ela deve aparecer no quadro de regras, nos padrões de interface, na semântica da estrutura física e no vocabulário. | Transformar aprendizagem local em governança sistêmica. | formas_classificacao_conhecimento.html, padroes_interface_ola.html, semantica_estrutura_fisica.html, vocabulario_ola.html. | A regra está ligada às páginas relacionadas e ao ciclo de governança. |
✓
Checklist: a página diferencia claramente componente visual, tag HTML, classe CSS, tag semântica, categoria, faceta e palavra-chave?
Regras de estrutura conceitual e dimensões
Critérios para organizar dimensões, eixos, camadas, níveis e naturezas de processo sem transformar a estrutura física do OLA em uma árvore conceitual excessivamente abstrata.
| ID | Regra | Objetivo | Aplicação | Critério de aceite |
|---|---|---|---|---|
| CONC-01 | M0–M3 são níveis da dimensão abstração. São usados para leitura, modelagem, análise e governança do OLA. | Separar abstração conceitual de armazenamento físico. | Governança, arquitetura, fundamentos, mapas e páginas analíticas. | M0–M3 ajudam a interpretar a página, mas não obrigam a criação de pastas m0/, m1/, m2/ ou m3/. |
| CONC-02 | Níveis de abstração não determinam, por si só, a estrutura física. A organização física deve priorizar áreas estruturais, domínios, uso, manutenção, navegação e evolução. | Evitar pastas difíceis de manter. | estrutura_fisica_arquivos_pastas.html, organização de áreas e domínios. | A localização do arquivo é justificada por função, uso e manutenção, não apenas por nível conceitual. |
| CONC-03 | Diferenciar dimensões sistêmicas, dimensões de governança, eixos de área, naturezas de processo e critérios auxiliares. | Controlar o crescimento do vocabulário de análise. | Fundamentos, governança, arquitetura e mapas. | O termo é classificado antes de virar nova categoria estruturante. |
| CONC-04 | Dimensões sistêmicas descrevem manifestações do OLA. Exemplos: física, digital, semântica e transformacional. | Manter a visão do OLA como sistema em múltiplas manifestações. | Páginas institucionais, fundamentos e visão sistêmica. | A dimensão descreve uma manifestação transversal do sistema. |
| CONC-05 | Dimensões estruturantes da governança orientam decisão e controle. Exemplos: abstração, estrutura, atuação e evolução. | Organizar a governança sem confundir com pastas ou áreas. | Governança, quadro de regras e páginas de organização. | A dimensão orienta leitura, decisão, uso ou evolução do OLA. |
| CONC-06 | Áreas estruturantes podem ter eixos de análise próprios. Arquitetura, Fundamentos, Domínios e Aprendizagem podem usar eixos locais, sem que eles virem dimensões principais do OLA. | Permitir análise especializada sem inflação conceitual. | Mapas de áreas, organização de áreas e páginas âncora. | O eixo local é apresentado como eixo de análise da área, não como dimensão sistêmica. |
✓
Checklist: a página separa corretamente estrutura física, dimensão, camada, eixo, nível e critério?
Regras do Ciclo de Governança Estrutural
Critérios para conduzir a evolução de uma regra ou estrutura no OLA, do mapa conceitual até sua aplicação operacional.
| ID | Regra | Objetivo | Aplicação | Critério de aceite |
|---|---|---|---|---|
| CICLO-01 | Usar o ciclo Mapa → Organização → Índice → Regra Canônica → Quadro de Regras. | Conectar visão conceitual, organização operacional, acesso e normatização. | Governança, áreas estruturantes e domínios. | A mudança relevante aparece no mapa, na organização, no índice, na regra canônica e no quadro resumido quando aplicável. |
| CICLO-02 | O ciclo é cognitivo, organizacional, técnico e operacional. Ele apoia compreensão, decisão, materialização e execução recorrente. | Evitar que governança seja tratada apenas como documentação técnica. | Atualização de páginas, criação de áreas, revisão de padrões e publicação. | A mudança orienta entendimento, organização, implementação e uso prático. |
| CICLO-03 | Regra canônica deve ter página de explicação e resumo consultável. | Preservar profundidade sem perder acesso rápido. | estrutura_fisica_arquivos_pastas.html e quadro_regras_ola.html. | Existe explicação completa e regra resumida para consulta. |
| CICLO-04 | A pasta projeto/ registra o empreendimento evolutivo do OLA.Deve ser usada para visão, método, escopo, entregas, decisões, ciclo de vida, operação, manutenção, evolução e valor do próprio OLA. | Evitar confundir projeto/ com desenho técnico isolado, plano de tarefas ou gestão temporária de escopo fechado. | projeto/index_projeto.html, projeto/mapa_projeto.html, projeto/organizacao_projeto.html, projeto/ciclo_vida_solucao_ola.html e projeto/entregas_ola.html. | Conteúdos em projeto/ explicam a condução evolutiva do OLA e se conectam à governança, arquitetura, fundamentos, sistema, domínios e aprendizagem quando houver impacto. |
| CICLO-05 | A pasta processos/ registra os processos transversais do OLA.Deve ser usada para processos gerais que atravessam várias áreas, como entrada, análise, modelagem, criação de páginas, criação de pastas, publicação, avaliação e evolução. | Evitar que processos estruturais fiquem dispersos entre governanca/, arquitetura/, conhecimento/, dominios/ e projeto/. | processos/index_processos.html, processos/processo_central_ola.html, processos/processo_criacao_pasta_raiz.html e processos/processo_criacao_pagina_ola.html. | Um processo só fica em processos/ quando atravessa várias áreas do OLA; processos específicos ficam dentro da própria área ou domínio. |
✓
Checklist: a alteração conceitual foi traduzida em mapa, organização, índice, regra canônica e quadro de consulta?
Regras para processos transversais
Critérios para decidir quando um processo deve ficar na pasta raiz processos/ e quando deve permanecer dentro de uma área específica.
| ID | Regra | Objetivo | Aplicação | Critério de aceite |
|---|---|---|---|---|
| PROC-01 | Processos transversais ficam em processos/.Um processo é transversal quando orienta várias áreas do OLA e não pertence apenas a um domínio, página ou componente. | Dar lugar próprio aos modos de funcionamento recorrentes do OLA. | Entrada, análise, derivação, criação de página, criação de pasta raiz, publicação, avaliação, revisão e evolução. | O processo é usado por mais de uma área e possui impacto sobre governança, arquitetura, conhecimento, publicação ou evolução. |
| PROC-02 | Processos específicos ficam na área ou domínio de origem. Quando um processo pertence a um domínio específico, deve ficar dentro da estrutura desse domínio. | Evitar centralizar em processos/ aquilo que só faz sentido em um contexto particular. | dominios/doces_artesanais/processos/, dominios/saude/processos/ ou páginas equivalentes. | O processo específico possui contexto, vocabulário e aplicação próprios do domínio. |
| PROC-03 | Todo processo transversal deve ter entrada, transformação, saída e critério de uso. | Evitar páginas de processo apenas descritivas ou sem operacionalidade. | Páginas como processo_criacao_pasta_raiz.html, processo_criacao_pagina_ola.html e processo_evolucao_ola.html. | A página deixa claro o que entra, o que é feito, o que sai, quem usa e como verificar se o processo funcionou. |
| PROC-04 | Processo que cria estrutura deve atualizar a governança correspondente. Quando o processo cria pasta, página, índice, regra ou padrão, deve apontar quais páginas precisam ser atualizadas. | Fechar o ciclo entre ação operacional e regra de governança. | Criação de pasta raiz, criação de índice, revisão de domínio, publicação e refatoração de páginas. | A página do processo indica impactos em meta-arquitetura, quadro de regras, readme, portal, índices e páginas relacionadas quando aplicável. |
✓
Checklist: o processo é transversal, possui entrada-transformação-saída e indica quais áreas ou páginas são impactadas?
Checklist antes de publicar uma página OLA
Estrutura e navegação
✓
Há breadcrumb físico e semântico?
✓
As páginas relacionadas têm função semântica clara?
✓
O usuário consegue voltar ao hub ou domínio?
Conhecimento e conteúdo
✓
Existe problema resolvido?
✓
A origem da informação está registrada?
✓
A entrada foi classificada quanto à natureza, finalidade, privacidade, publicação e potencial de transformação?
✓
Há distinção entre análise, sugestão e validação?
✓
“Próximos passos” foi separado de páginas relacionadas, artefatos criados, pendências e histórico?
Privacidade e publicação
✓
O artefato foi classificado como público, interno, restrito, sensível ou manual?
✓
Dados pessoais ou sensíveis foram removidos, protegidos ou anonimizados?
✓
A página tem decisão clara de publicação ou bloqueio?
Grafo e visualização
✓
O grafo tem finalidade e explicação de uso?
✓
As arestas têm predicados?
✓
Há alternativa para impressão?
Interface e uso
✓
Modais funcionam e fecham corretamente?
✓
Botões fixos não cobrem conteúdo crítico?
✓
A página é legível no celular e na impressão?
Vocabulário e conceitos
✓
Os termos sistema, dimensão, camada, eixo e nível estão usados com precisão?
✓
Termos novos foram avaliados antes de virar padrão?
✓
A página evita criar dimensões sem critério?
Classificação e semântica
✓
A página diferencia chip, tag HTML, classe CSS, tag semântica, categoria, faceta e palavra-chave?
✓
As tags semânticas aparecem como marcadores de conteúdo, e não como classes CSS?
✓
Quando houver ficha classificatória, ela indica área, domínio, finalidade, nível, status, tags e palavras-chave?
Notação e símbolos
✓
Setas, linhas, chips, tags e símbolos possuem significado explícito?
✓
Quando a seta
→ aparece, é possível dizer o que muda?✓
Notações recorrentes possuem página especializada ou referência canônica?
Governança estrutural
✓
A mudança passou pelo ciclo Mapa → Organização → Índice → Regra → Quadro?
✓
A estrutura física foi separada da leitura M0–M3?
✓
A localização da página se justifica por uso, manutenção e navegação?
✓
Se a página estiver em
projeto/, ela trata o OLA como empreendimento evolutivo e não apenas como plano ou desenho técnico?✓
Se a página descreve um processo transversal, ela está registrada ou apontada em
processos/?Próximas ações de governança
Esta seção registra ações pendentes para integrar e propagar as regras deste quadro. Diferentemente de Páginas relacionadas, aqui entram tarefas reais a executar. Quando uma ação for concluída, ela deve sair desta seção e migrar para Artefatos criados, Páginas relacionadas ou Histórico de evolução, conforme o caso.
| Ação | Objetivo | Área impactada | Critério de conclusão |
|---|---|---|---|
| Propagar a regra CONT-07 para os templates do OLA. | Evitar que novas páginas misturem próximas ações, páginas relacionadas, artefatos criados e pendências. | Arquitetura, templates e páginas-base. | Os templates passam a separar blocos finais por função semântica. |
| Revisar páginas recentes da área Aprendiz. | Aplicar a distinção entre próximas ações, páginas relacionadas, artefatos criados e histórico. | aprendiz/ |
As páginas principais do Aprendiz deixam de usar “Próximos passos” como bloco genérico. |
| Atualizar padrões de interface, se necessário. | Registrar a separação dos blocos recorrentes como padrão visual e semântico. | governanca/padroes_interface_ola.html |
A página de padrões diferencia blocos de ação, navegação, histórico e pendência. |
| Conectar a regra ao sistema de navegação do OLA. | Relacionar a semântica dos blocos com orientação, leitura e continuidade. | arquitetura/sistema_navegacao_ola.html |
A navegação explica a diferença entre “para onde ir” e “o que fazer”. |
| Revisar páginas de domínio quando forem atualizadas. | Aplicar a regra gradualmente, sem necessidade de refatoração imediata de todo o site. | dominios/ |
Novas revisões de domínio passam a separar ações, links, artefatos e pendências. |
| Registrar ações concluídas em histórico de evolução. | Evitar que tarefas concluídas permaneçam como próximas ações. | Governança e páginas revisadas. | Ações concluídas são movidas para histórico, artefatos criados ou páginas relacionadas. |
| Atualizar o índice de processos com as novas regras de governança. | Garantir que processos/index_processos.html aponte para os processos transversais regulados por este quadro. |
processos/ e Governança. |
O índice de processos referencia processo_criacao_pasta_raiz.html e diferencia processos transversais de processos específicos. |
| Criar o processo de criação de pasta raiz. | Transformar a decisão sobre novas pastas da raiz em procedimento claro, verificável e reutilizável. | processos/, governanca/, readme.html e portal.html. |
A página processos/processo_criacao_pasta_raiz.html existe e aponta os impactos de atualização. |
| Avaliar menu recolhível para o quadro de regras. | Reduzir densidade do cabeçalho em telas pequenas, mantendo acesso às categorias. | Layout, navegação e responsividade. | O menu superior deixa de ocupar espaço excessivo em celular sem perder os atalhos principais. |
✓
Checklist: esta seção contém apenas ações pendentes ou recomendadas para execução?
Links de leitura e páginas já existentes devem permanecer em “Páginas relacionadas”.
Páginas relacionadas
Index de governança
Hub onde este quadro deve ser listado.
Índice do projeto
Entrada da área que registra o OLA como empreendimento evolutivo: visão, método, escopo, entregas, ciclo de vida e valor.
Índice de processos do OLA
Entrada da área que organiza processos transversais: entrada, análise, criação de página, criação de pasta raiz, publicação, avaliação e evolução.
Padrões de navegação
Página que traduz regras em padrões de interface e comportamento.
Template de artefato OLA
Modelo que deve aplicar regras de origem, grafo, jornada, relacionadas e segurança.
Vocabulário do OLA
Página de referência para sistema, dimensão, camada, eixo, nível, método, abordagem e pesquisa.
Estrutura física
Página canônica para separar estrutura física, áreas, domínios e níveis de abstração.
Classificação da informação
Define níveis de exposição: público, interno, restrito, sensível e manual/fora do digital.
Política de publicação
Decide o que pode ir para o site, o que deve ficar privado e o que precisa ser anonimizado.
LGPD e privacidade
Orienta tratamento de dados pessoais, dados sensíveis, anonimização e proteção de artefatos.
Formas de classificação
Referência para diferenciar classificação, taxonomia, ontologia, tesauro, tags, facetas, palavras-chave, chips e categorias.
Padrões de interface
Deve registrar que chip, card e outros nomes de classes CSS são componentes visuais, não categorias conceituais.
Semântica da estrutura física
Deve diferenciar nome técnico, nome visual, nome semântico e agrupamento estrutural.
Semântica da seta
Notação especializada consolidada para relações direcionais e transformações.
Semântica dos blocos de página
Define o uso correto de Próximos passos, Próximas ações, Páginas relacionadas, Artefatos criados, Pendências e Histórico de evolução.