Unit-site templates

Specification

1. One template per page type, chosen by the type the CMS sends (window 4) and never by the address: home, section index (index), catalogue front page (product_index), quantity, axis (instrument type, brand, family), segment, industry, application, topic or service (standard), rubric index, publication, product, contact and search. A type the table does not know is drawn as a topic: its body. The table lives in packages/site/src/templates/registry.ts.
2. Every template has the same regions, in this order: head (PageHead: breadcrumbs from the tree, eyebrow, title, summary, the main action and the partner's attribution when the content is a partner's), body (the sections in the editor's order), derived rails (what the axes and the relations give), the ecosystem narrative (on service, segment, industry and application pages, and on the home with the AKRIBIS One module) and the closing (the index's own call, window 3, or the voice's: «Talk to a specialist»).
3. The home follows akribis.info's order: hero (the body's first hero block), solutions (the rest of the body), services and units, segments with their industries and applications, the ecosystem, contact, the Expertise hub (its rubrics, the upcoming events and the latest news from window 10), quick access, applications and instrumentation (its axes and the featured instruments). Each block appears only when there is data for it.
4. Catalogue front page: the axes on top (each value with its count of instruments) and the full portfolio, paginated, with window 1's facets. Quantity: its instruments, the industries and applications where it appears, and its notes (window 8 by category). Axis: its instruments (a family by its own facet) and the crossings with the other axes; a brand shows its logo and its relation with AKRIBIS. Segment: its industries and applications, the services and the notes, with no grid: a segment groups, it does not classify. Industry and application: their relations, the instruments of their category, their notes and their segment.
5. A facet combination is a query on the written page: one value per axis, combined with AND, noindex, follow, with the canonical and the alternates on the page without the query; the pages keep the query. An option that gives nothing is not offered.
6. The navigation and the footer come from the same tree: Instrumentation opens its axes as columns with counts (an axis without pages does not appear) and the full portfolio; Segments opens each segment with its industries and applications, plus all industries and all applications; the footer has five columns (contact, categories, services, Expertise, about) above the group block.
7. Every page carries the cache tags the CMS purges: the department's, page: of the page (a bare page: on the home) and of the segments index, whose panel window 3 builds in one request, product: of every instrument any grid shows, category:, rubric: and resource:. Every grid also publishes its ItemList in JSON-LD, beside BreadcrumbList, Product, Event or Article.
8. A product with an options tree (window 7) carries the configurator as a section of its page: the groups, exclusions live, the rules on request and before adding, the order code both ways, services and accessories apart. The browser asks the site itself for the tree (/configurator/<id>.json), which asks the CMS with the key; what is configured joins the quote list with its full summary and reaches the CRM that way.
9. A CMS site's sitemap is built on request: /sitemap-index.xml with its parts for pages (the tree, the shared ones, the site's own), products (window 6) and publications (window 8), each address with its alternates in the three languages, cached and tagged; robots.txt names it and can carry the site's per-bot policy. The entry at / picks the language by the cookie the switch writes, then the browser, then the country.
10. Search (window 11) lives at a translated address (/es/buscar/, /en/search/, /pt/buscar/), groups its results into pages, instruments and publications, and is not indexed.
11. The proof (packages/cms-proof) is checked against a local CMS with an example of every type (mock/cms.mjs): pnpm --filter @akribis/cms-proof check:mock starts the CMS and the Worker, checks that each address is drawn by its type's template and runs the live check over the three languages.

To re-reason

• Sections three levels deep or more are not in the navigation model: their breadcrumbs are asked of window 4.
• The configurator keeps its draft per product in the browser and the quote list lives for the visit: what is configured and not sent is lost when the tab closes.

Evidence to audit

• 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

Delivers

• The templates in packages/site/src/templates/ (one per type, with their loaders in load.ts and their shared regions)
• the navigation model and the five-column footer derived from the tree
• the local test CMS with an example of every type and its live check.

Decision

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