Regras de Integridade entre Pastas e Arquivos do LAC
Esta página registra regras para manter a coerência entre pastas, arquivos, páginas índice, relacionamentos, versões, ambientes e estados de trabalho do LAC. Ela complementa a regra da estrutura da raiz e a classificação das áreas-raiz.
Breadcrumb físico e semântico
Finalidade × Análise
Finalidade
Definir regras práticas para evitar perda de coerência estrutural no LAC à medida que novas páginas, pastas, demandas, entregas, versões e artefatos forem criados.
A página ajuda a decidir onde colocar arquivos, como nomeá-los, como relacioná-los e quando migrá-los para produção, histórico ou legado.
Análise
O LAC cresce por aprendizagem, experimentação e produção contínua. Sem regras de integridade, a raiz e as subpastas podem acumular arquivos soltos, nomes inconsistentes, páginas órfãs, versões duplicadas e links quebrados.
A integridade estrutural não impede a evolução; ela organiza a evolução para que o conhecimento continue recuperável.
Problema resolvido
Como manter a organização do LAC coerente quando novas páginas e pastas são criadas em ciclos sucessivos de demanda, entrega, revisão, homologação, produção e legado?
Risco
Arquivos podem ser criados na pasta errada, com nomes ambíguos ou sem vínculo com páginas índice.
Regra
Cada arquivo deve ter função, localização, nome, estado e relacionamento explícitos.
Resultado
O LAC permanece navegável, auditável, publicável e evolutivo.
O que é integridade estrutural no LAC
Integridade estrutural é a coerência entre a função do conteúdo, sua pasta de localização, seu nome de arquivo, suas relações com outras páginas e seu estado de uso no ciclo de vida do LAC.
Arquivo íntegro no LAC
├── tem finalidade clara
├── está na pasta coerente
├── segue padrão de nomeação
├── é acessível por página índice ou página relacionada
├── aponta para referências importantes
├── possui ambiente definido: desenvolvimento, homologação ou produção
├── possui estado de ciclo de vida definido: rascunho, em revisão, homologado, vigente, substituído, histórico ou legado
└── pode ser encontrado, entendido, revisado e mantido1. Regra de integridade de localização
A localização de um arquivo deve ser definida pela função predominante do conteúdo.
| Função predominante | Local recomendado | Critério |
|---|---|---|
| Definir identidade, propósito fundador, visão, compromissos constitutivos e vocabulário canônico do LAC. | fundacao/ | É o alicerce constitutivo e a referência terminológica canônica do LAC; pertence ao núcleo central. Arquivo de referência: fundacao/vocabulario_lac.html. |
| Explicar conceitos, princípios, modelos, pressupostos ou realizar estudos e aprofundamentos sobre o vocabulário. | fundamentos/ | É base de explicação e fundamentação conceitual; não substitui nem duplica o vocabulário canônico da Fundação. |
| Descrever estrutura, organização, componentes, fluxos, mapas e funcionamento. | arquitetura/ | É desenho estrutural ou funcional. |
| Definir regra, decisão, critério, classificação, publicação, manutenção ou controle. | governanca/ | É norma de organização ou decisão. |
| Planejar evolução, versões, prioridades, demandas e entregas transversais. | projeto/ | É gestão do desenvolvimento do LAC. |
| Modelar o LAC como sistema, estados, fronteiras, elementos e relações. | sistema/ | É modelagem sistêmica. |
| Contextualizar o LAC em relação a pessoas, instituições, IA, web e sociedade. | ecossistema/ | É contexto ampliado. |
| Organizar experiência de quem chega pela primeira vez. | visitante/ | É entrada pública por persona. |
| Organizar trilhas, objetos, práticas, avaliação e processo educacional. | aprendizagem/ | É processo de aprendizagem. |
| Aplicar conhecimento a uma área específica. | dominios/ | É domínio de conhecimento ou aplicação. |
| Produção autoral, laboratório, notas, experimentos e pendências pessoais. | autor/ | É atividade do autor como produtor/curador. |
| CSS, JavaScript, imagens, ícones, logos e componentes técnicos. | assets/ | É recurso técnico reutilizável. |
| Versões antigas, páginas substituídas, rascunhos preservados. | legado/ ou historico_rascunho/ | É memória ou material não canônico. |
2. Regra de integridade de nomeação
O nome do arquivo deve permitir identificação, recuperação e manutenção.
Padrão recomendado
- usar letras minúsculas;
- não usar espaços;
- não usar acentos;
- usar underline entre palavras;
- evitar nomes como
final,novo,teste2em produção.
Exemplos
Preferir:
regras_estrutura_raiz_lac.html
estrutura_fisica_lac.html
classificacao_e_criterios_areas_raiz_lac.html
Regras da Raiz Final.html, estrutura-raiz-nova2.html, classificação áreas raiz.html.3. Regra de páginas índice
Toda pasta estrutural relevante deve ter uma página de entrada.
governanca/index_governanca.html
arquitetura/index_arquitetura.html
fundamentos/index_fundamentos.html
dominios/index_dominios.html
projeto/index_projeto.html
aprendizagem/index_aprendizagem.html
visitante/index_visitante.html
autor/index_autor.html4. Regra de integridade de relacionamento
Páginas relacionadas devem se apontar mutuamente quando formam uma decisão, regra, estrutura ou fluxo.
Relacionamento mínimo
Uma página estrutural deve ter:
- breadcrumb físico e semântico;
- links para páginas relacionadas;
- referência à página índice da pasta;
- links de retorno quando alterar uma regra existente.
Exemplo
governanca/regras/regras_estrutura_raiz_lac.html
↔ governanca/arquitetura/estrutura_fisica_lac.html
↔ governanca/arquitetura/classificacao_e_criterios_areas_raiz_lac.html
↔ governanca/regras/regras_integridade_pastas_arquivos_lac.html5. Regra para demandas e entregas
Demandas e entregas são categorias internas de trabalho já organizadas no projeto e nas áreas responsáveis.
| Caso | Local recomendado | Exemplo |
|---|---|---|
| Demanda transversal do LAC. | projeto/demandas_entregas/ | projeto/demandas_entregas/camada_publica_descoberta_lac/ |
| Demanda ligada a domínio de conhecimento. | dominios/<dominio>/<tema>/demanda/ | dominios/gestao/fabrica_brownie/demanda/ |
| Entrega ligada a domínio de conhecimento. | dominios/<dominio>/<tema>/entrega/ | dominios/gestao/fabrica_brownie/entrega/ |
| Demanda pessoal do autor. | autor/demandas_autor/ | autor/demandas_autor/pendencias/ |
projeto/demandas_entregas/, com função, estado e relacionamentos explícitos.6. Regra para desenvolvimento, homologação e produção
A integridade depende também do ambiente onde o arquivo está.
Desenvolvimento
Fica no computador local. É onde se cria, testa, ajusta, experimenta e reorganiza.
Homologação
Pode existir no provedor para teste externo controlado, antes de produção.
Produção
Fica no provedor como versão publicada, revisada, acessível e coerente com a estrutura.
7. Regra para legado, histórico e rascunhos
Arquivos substituídos não devem ficar misturados com arquivos canônicos.
legado/
Preserva versões antigas, páginas substituídas e materiais históricos que não são mais a versão vigente.
historico_rascunho/
Preserva rascunhos, materiais em transição ou versões intermediárias ainda úteis para consulta.
Checklist antes de criar, mover ou publicar arquivos
| Verificação | Pergunta de controle | Status |
|---|---|---|
| Função | A finalidade do arquivo está clara? | verificar |
| Localização | A pasta escolhida corresponde à função predominante? | verificar |
| Nomeação | O nome está em minúsculas, sem acentos, sem espaços e com underline? | verificar |
| Índice | A pasta possui página índice ou a página está acessível por outra entrada? | verificar |
| Relacionamentos | A página aponta para páginas relacionadas e recebe links de retorno quando necessário? | verificar |
| Ambiente | O arquivo está no ambiente correto: desenvolvimento, homologação ou produção? | verificar |
| Estado | O estado do ciclo de vida está definido: rascunho, em revisão, homologado, vigente, substituído, histórico ou legado? | verificar |
| Substituição | Se substituiu outro arquivo, o anterior foi enviado ao legado ou histórico? | verificar |
| Publicação | O arquivo está pronto para ir ao provedor de produção? | verificar |
Exemplos de decisão de localização
| Novo conteúdo | Onde colocar | Motivo |
|---|---|---|
| Regra de redirecionamento entre páginas antigas e novas. | governanca/regras_redirecionamento_lac.html | É regra de governança e manutenção. |
| Descrição da estrutura física da raiz. | governanca/arquitetura/estrutura_fisica_lac.html | É arquitetura estrutural. |
| Classificação semântica das pastas da raiz. | governanca/arquitetura/classificacao_e_criterios_areas_raiz_lac.html | É critério de classificação e governança. |
| Demanda da camada pública de descoberta. | projeto/demandas_entregas/camada_publica_descoberta_lac/ | É demanda transversal do projeto LAC. |
| Experiência de custos da fábrica de brownie. | dominios/gestao/fabrica_brownie/ | É aplicação em domínio de gestão. |
| Notas pessoais do autor durante uma observação de aprendizagem. | autor/ ou autor/demandas_autor/ | É produção/registro autoral. |
Páginas relacionadas
Governança
governanca/index_governanca.html
e criar link cruzado a partir de regras_estrutura_raiz_lac.html.
Fundação — alicerce do LAC
fundacao/ é uma área permanente do núcleo central — estrutural. Sua função é registrar os alicerces constitutivos do LAC: identidade, propósito fundador, visão e compromissos que sustentam sua existência e orientam sua continuidade.
Distinção e critério de localização
fundacao/ responde: em que o LAC se apoia para existir? fundamentos/ responde: quais conceitos, princípios, teorias e pressupostos sustentam sua compreensão e prática?
Arquivos que definem os alicerces constitutivos pertencem a fundacao/; explicações de conceitos e bases teóricas pertencem a fundamentos/. Aplicar a função predominante, manter relações recíprocas e evitar duplicações. A área deve ter página de entrada, finalidade, conteúdo, relações e estado explícitos; recomenda-se fundacao/index_fundacao.html.
Decisão de organização: inclusão de fundacao/ no núcleo central, conforme definição do autor em 14/10/2026. A jornada apresenta a mesma classificação.
Coerência com a jornada da organização física
Jornada pelos conceitos e critérios da organização física do LAC explica os conceitos, os três grupos e os critérios destas regras. A jornada não altera a estrutura normativa. Alterações de áreas e agrupamentos devem ser registradas na governança e refletidas no mapa.
Grupos são categorias de organização, não pastas intermediárias nem etapas de processo. Pasta, conteúdo e processo são conceitos distintos. O laboratório tem destino preferencial em autor/lab/. Itens em transição permanecem identificados até migração governada.
Reconciliação com a raiz observada em 14/10/2026
A captura registra 32 itens: aprendiz/, aprendizagem/, arquitetura/, artigo/, assets/, autor/, aviso.html, base/, conhecimento/, dados/, documentacao/, dominios/, ecossistema/, editorial/, ferramentas/, fundacao/, fundamentos/, governanca/, historico/, homologacao/, index.html, lab/, legado/, mapa_site.html, portal.html, privado/, processos/, projeto/, publico/, referencias/, sistema/, visitante/. Todos são apresentados na jornada. Presença física não implica aprovação normativa. A árvore recomendada e o inventário atual devem permanecer distinguíveis.
Casos a examinar: historico/ versus legado/ e historico_rascunho/; homologacao/ como pasta versus ambiente; aviso.html e sua finalidade; editorial/ e privado/ com responsabilidade e publicação explícitas. lab/ permanece observado na raiz e com destino preferencial autor/lab/; publico/ permanece em reavaliação. Não executar fusão ou migração apenas pelo nome.
A árvore recomendada não substitui um inventário físico verificado. Novas áreas, como editorial/, devem ter classificação e decisão explícitas antes de inclusão normativa.
Regras da raiz · Regras de integridade · Índice da governança