Modelos do site de unidade

Especificação

1. Um modelo por tipo de página, escolhido pelo tipo que o CMS envia (janela 4) e nunca pelo endereço: início, índice de seção (index), capa do catálogo (product_index), grandeza, eixo (tipo de instrumento, marca, família), segmento, indústria, aplicação, tópico ou serviço (standard), índice de rubrica, publicação, produto, contato e busca. Um tipo que a tabela não conhece é desenhado como tópico: seu corpo. A tabela vive em packages/site/src/templates/registry.ts.
2. Todo modelo tem as mesmas regiões, nesta ordem: cabeçalho (PageHead: trilha da árvore, sobretítulo, título, linha fina, a ação principal e a atribuição do parceiro quando o conteúdo é de um parceiro), corpo (as seções na ordem do redator), trilhos derivados (o que os eixos e as relações dão), a narrativa do ecossistema (nas páginas de serviço, segmento, indústria e aplicação, e no início com o módulo da AKRIBIS One) e o fechamento (a chamada própria do índice, janela 3, ou a da voz: «Falar com um especialista»).
3. O início segue a ordem de akribis.info: capa (o primeiro bloco hero do corpo), soluções (o resto do corpo), serviços e unidades, segmentos com suas indústrias e aplicações, o ecossistema, contato, o hub de Expertise (suas rubricas, os próximos eventos e as últimas novidades da janela 10), acesso direto, aplicações e instrumentação (seus eixos e os instrumentos em destaque). Cada bloco aparece só quando há dados.
4. Capa do catálogo: os eixos em cima (cada valor com sua quantidade de instrumentos) e o portfólio completo, paginado, com as facetas da janela 1. Grandeza: seus instrumentos, as indústrias e aplicações onde aparece e suas notas (janela 8 por categoria). Eixo: seus instrumentos (a família, pela sua própria faceta) e os cruzamentos com os outros eixos; a marca mostra seu logotipo e sua relação com a AKRIBIS. Segmento: suas indústrias e aplicações, os serviços e as notas, sem grade: um segmento agrupa, não classifica. Indústria e aplicação: suas relações, os instrumentos de sua categoria, suas notas e seu segmento.
5. Um cruzamento de facetas é uma consulta sobre a página escrita: um valor por eixo, combinados com E, noindex, follow, com o canonical e os alternates na página sem a consulta; a paginação mantém a consulta. Uma opção que dá zero não é oferecida.
6. A navegação e o rodapé saem da mesma árvore: Instrumentação abre seus eixos como colunas com quantidades (um eixo sem páginas não aparece) e o portfólio completo; Segmentos abre cada segmento com suas indústrias e aplicações, mais todas as indústrias e todas as aplicações; o rodapé tem cinco colunas (contato, categorias, serviços, Expertise, sobre) acima do bloco de grupo.
7. Cada página leva as etiquetas de cache que o CMS purga: a do departamento, page: da página (page: sozinho no início) e do índice de segmentos, cujo painel a janela 3 monta em um pedido, product: de cada instrumento que qualquer grade mostra, category:, rubric: e resource:. Cada grade publica também seu ItemList em JSON-LD, junto a BreadcrumbList, Product, Event ou Article.
8. Um produto com árvore de opções (janela 7) leva o configurador como seção da sua página: os grupos, as exclusões ao vivo, as regras sob pedido e antes de adicionar, o código de pedido nos dois sentidos, serviços e acessórios à parte. O navegador pede a árvore ao próprio site (/configurator/<id>.json), que a pede ao CMS com a chave; o configurado entra na lista de cotação com seu resumo completo e chega assim ao CRM.
9. O sitemap de um site CMS é montado na visita: /sitemap-index.xml com suas partes de páginas (a árvore, as compartilhadas, as próprias do site), produtos (janela 6) e publicações (janela 8), cada endereço com suas alternativas nos três idiomas, em cache e com etiquetas; o robots.txt o nomeia e pode levar a política por robô do site. A entrada / escolhe o idioma pelo cookie que o seletor escreve, depois o navegador, depois o país.
10. A busca (janela 11) vive em um endereço traduzido (/es/buscar/, /en/search/, /pt/buscar/), agrupa os resultados em páginas, instrumentos e publicações, e não é indexada.
11. O projeto de prova (packages/cms-proof) é verificado contra um CMS local com um exemplo de cada tipo (mock/cms.mjs): pnpm --filter @akribis/cms-proof check:mock sobe o CMS e o Worker, verifica que cada endereço seja desenhado pelo modelo do seu tipo e roda a verificação ao vivo nos três idiomas.

Para repensar

• As seções de nível três ou mais da árvore não estão no modelo de navegação: suas trilhas são pedidas à janela 4.
• O configurador guarda seu rascunho por produto no navegador e a lista de cotação vive durante a visita: o configurado e não enviado se perde ao fechar a aba.

Evidência para auditar

• akribis.info docs/19-arquitectura-de-informacion.md §§2-6 (signed 2026-10-06) and decision 24; docs/18-paridad.md rows 2-6, 13-16, 20-21, 34
• PIM-de-Akribis-One cms/CONTRACT.md, windows 1, 3, 4, 5, 10 and 11 and the ten body blocks (2026-10-06); holds and manufacturer on every card, window 3's items, the family facet, ?category=a,b,c and the home's page: tag (2026-10-07, PR #3); windows 6 and 7
• akribis.info docs/18-paridad.md rows 9, 18, 19 and 36 and its list of package debts (2026-10-07): the sitemap, the language cookie, the command-line tools and the configurator moved into the package
• packages/cms-proof/mock/check.mjs against the built proof: every template drawn by its type, zero violations over the three languages

Entrega

• Os modelos em packages/site/src/templates/ (um por tipo, com seus carregadores em load.ts e suas regiões compartilhadas)
• o modelo de navegação e o rodapé em cinco colunas derivados da árvore
• o CMS local de teste com um exemplo de cada tipo e sua verificação ao vivo.

Decisão

• ADR-0035 Render each site's own layer from the CMS's windows inside the site package, cached at the edge by tag Proposta
• ADR-0036 Build every unit site from one information architecture: the tree, the axes and the relations Aceita