ADR-0007: Motor de Layout de Site Dinâmico e Seções TOML | Wiki
ADR-0007: Motor de Layout de Site Dinâmico e Seções TOML
Este documento especifica a decisão de design sobre o motor de layout dinâmico para páginas institucionais complexas do gerador de sites estáticos gbr_ssg, focado na orquestração de seções baseadas em dados declarados.
1. Contexto e Motivação
O gerador estático do Gleam-BR requer a renderização de páginas institucionais do tipo "Site" com conteúdo flexível e modular (Hero, Features, Perfis, etc.) em contraste ao conteúdo de texto corrido típico (Wiki/Blog). Para manter os princípios de *Sistemas Lúcidos* e *Arquitetura Sustentável*, a responsabilidade de gerenciar componentes visuais complexos deve ser abstraída e desacoplada do corpo markdown (que permanecerá enxuto ou não-utilizado nessas páginas). Dessa forma, empoderamos os redatores a construírem suas landing pages estritamente através do frontmatter declarativo.
2. Decisão Arquitetural
Optamos por utilizar **"Arrays de Tabelas" ([[sections]])** da especificação TOML no Frontmatter como estrutura de dados primária para a configuração e orquestração de seções visuais dinâmicas.
Premissas técnicas adotadas:
1. **O Componente Proxy (layout_site.gleam):**
Este arquivo atuará unicamente como um iterador genérico. Ele inspecionará a chave "type" contida em cada entrada da matriz meta.sections (ex: hero, feature_grid) e delegará a renderização ao seu respectivo componente.
2. *Subcomponentes Desacoplados:*
Cada "Seção" corresponderá a um arquivo Lustre isolado no diretório components/. Eles serão inteiramente responsáveis por traduzir os campos de dados do TOML em marcação HTML semântica com suporte Tailwind CSS.
3. *Conversão de Tipos e Segurança:*
Os dados vindos do TOML passarão por extrações via tom e serão empacotados em um tipo nativo Option(List(Dict(String, String))). Essa flexibilização da tipagem, inerente à extração dinâmica de metadados, exigirá que a renderização do layout utilize mecanismos fail-soft (result.unwrap) em caso de omissão de chaves específicas.
3. Requisitos EARS
*Requisitos Ubíquos (Ubiquitous Requirements)*
- *UBQ-01 (Decodificação de Seções Genéricas):* O decodificador TOML do core (ssg_core) DEVE extrair as matrizes dinâmicas definidas pela tabela [[sections]], convertendo seus pares chave-valor estritamente para o formato estrutural Option(List(Dict(String, String))) a ser anexado em PageMetadata.
- *UBQ-02 (Tolerância a Falhas de Tipagem Dinâmica):* Todo componente da interface (ex. hero) DEVE resgatar chaves através da aplicação robusta de fallback padrão (result.unwrap(dict.get(section, "title"), "Sem Título")), garantindo que nenhuma ausência acidental de metadados rompa o ciclo de renderização completo do SSG.