OLA
Regras da Estrutura da Raiz do OLAGovernança · Estrutura da raiz · Regras
Governança · Estrutura da raiz · Regras

Regras da Estrutura da Raiz do OLA

Página de governança que registra a decisão de manter a raiz do OLA como mapa institucional e deslocar demandas e entregas para categorias internas de trabalho.

OLARaizGovernançaArquitetura

Finalidade

Registrar a regra oficial de organização da raiz do OLA, deixando claro quais áreas podem aparecer no primeiro nível e como tratar demandas, entregas, arquivos temporários e material histórico.

Decisão principal: a raiz do OLA não deve ter demandas/ nem entregas/ como áreas principais. Demanda e entrega passam a ser categorias internas de trabalho.

Problema resolvido

Antes

demandas/ e entregas/ na raiz pareciam áreas permanentes do sistema.

Agora

A raiz passa a representar a estrutura institucional do OLA.

Resultado

Demandas e entregas ficam dentro da área onde o trabalho acontece.

Regra principal da raiz

A raiz deve conter apenas áreas estruturais, de uso, de aprendizagem, de produção, de suporte, de recursos e de evolução. Ela não deve virar um depósito operacional de demandas e entregas.

SituaçãoRegraExemplo
Demanda geral de evolução do OLARegistrar dentro de projeto/demandas_entregas/projeto/demandas_entregas/camada_publica_descoberta_ola/
Demanda ligada a um domínioRegistrar dentro do domínio correspondentedominios/gestao/fabrica_brownie/demanda/
Entrega ligada a um domínioRegistrar junto da demanda ou na mesma área do domíniodominios/gestao/fabrica_brownie/entrega/
Demanda pessoal do autorRegistrar dentro de autor/autor/demandas_autor/pendencias/

Estrutura recomendada

A árvore abaixo é a visão de governança para a raiz. Ela acrescenta processos/, documentacao/, dados/ e historico_rascunho/ porque essas pastas aparecem na estrutura atual e possuem função clara.

/ raiz
├── Núcleo central - estrutural
│   ├── index.html
│   ├── portal.html
│   ├── readme.html
│   ├── sobre_autor.html
│   │
│   ├── fundamentos/
│   ├── arquitetura/
│   ├── conhecimento/
│   ├── projeto/
│   ├── sistema/
│   ├── ecossistema/
│   ├── governanca/
│   ├── processos/
│   └── documentacao/
│
├── Uso / produção / aprendizagem
│   ├── visitante/
│   ├── aprendiz/
│   ├── autor/
│   │   └── lab/
│   ├── aprendizagem/
│   ├── dominios/
│   └── artigo/
│
└── Suporte / recursos / evolução
    ├── base/
    ├── dados/
    ├── ferramentas/
    ├── referencias/
    ├── assets/
    ├── legado/
    └── historico_rascunho/

Regras específicas

ItemTratamento recomendadoJustificativa
processos/Manter na raiz, no núcleo estrutural.Processos descrevem a operação conceitual e funcional do OLA.
documentacao/Manter na raiz, no núcleo estrutural.Formaliza, explica e registra o sistema.
dados/Manter em suporte, recursos e evolução.Sustenta busca, índices e futuras automações.
historico_rascunho/Manter temporariamente em suporte/evolução ou migrar gradualmente para legado/.Preserva memória, rascunhos e material anterior.
lab/Preferencialmente ficar dentro de autor/.Laboratório é atividade de experimentação do autor.
publico/Reavaliar se vira visitante/ ou se permanece como publicação.Há sobreposição semântica entre público, visitante e publicação.
_avaliar/Tratar como área temporária de triagem.Não deve ser área institucional da raiz definitiva.
assets/Pode existir globalmente na raiz e localmente dentro de uma área responsável.Recursos compartilhados por múltiplas áreas ficam em /assets/; recursos específicos de uma área ficam em <area>/assets/, preservando proximidade com o contexto de uso e responsabilidade predominante.

Assets globais × assets locais

A pasta assets/ pode existir em dois escopos físicos diferentes. O critério de localização é o alcance de uso do recurso e a responsabilidade predominante da área.

Asset global

Recurso compartilhado por múltiplas áreas, páginas ou componentes do OLA/LAC.

Destino: /assets/

Asset local

Recurso utilizado predominantemente pelas páginas de uma área específica.

Destino: <area>/assets/

Regra de escopo: manter o recurso no assets/ local enquanto seu uso for específico da área. Se passar a ser reutilizado transversalmente, avaliar sua migração para /assets/, preservando e atualizando as referências.

Exemplo aplicado à área Conhecimento

conhecimento/
├── index_conhecimento.html
├── tecnologias_lac.html
└── assets/
    └── knowgrama_tecnologias_lac.png

Nesse exemplo, tecnologias_lac.html é a página de conhecimento e knowgrama_tecnologias_lac.png é um recurso visual específico dessa área. O fato de a imagem ser um Knowgrama descreve sua natureza semântica; sua localização em assets/ descreve sua função física como recurso da página.

Importante: uma subpasta local assets/ não constitui nova área-raiz nem altera a classificação institucional da área que a contém.

Orientação de migração

A migração deve ser gradual. Primeiro registrar a decisão, depois atualizar índices e links, depois mover fisicamente as pastas somente quando houver segurança de que os links principais foram ajustados. O mesmo princípio vale para assets: ao mover um recurso entre <area>/assets/ e /assets/, revisar todas as referências relativas antes de remover a localização anterior.

Regra prática: não apagar demandas/ e entregas/ de imediato. Criar uma transição com páginas de redirecionamento ou aviso, se essas pastas já tiverem links em uso.

Páginas relacionadas