Padrão de Landing Pages — Sectors da Stack Koder

Visão Geral

Cada uma das 9 Áreas do ecossistema Koder (Foundation, Data Platform, Cloud Infrastructure, Observability, Intelligence, Developer Platform, Workspace, Industry Solutions, Brand & Presence) é subdividida em *ectors* Um Sector agrupa 1–N *ódulos*do monorepo que servem juntos um mesmo propósito.

Exemplos de Sectors:

Landings de Sector são uma *amada intermediária*entre as landings de Área (areas.kmd) e as landings de Produto (products.kmd). Elas existem pra contar a história do agrupamento — porque esses módulos estão juntos, o que eles compartilham, e como escolher entre eles.

Quando Criar uma Landing de Sector (e Quando NÃO)

*egra prática:*landing de Sector se justifica quando um visitante da Área precisa *scolher entre os módulos do Sector* Se não há escolha a fazer, a landing do módulo basta.

Hierarquia de Navegação

Toda landing de Sector participa de uma cadeia:

Koder (www.koder.dev)
  └─> Área  (foundation.koder.dev)
        └─> Sector  (linux.koder.dev)  ← esta landing
              └─> Módulo 1  (distro.koder.dev)
              └─> Módulo 2  (shell.koder.dev)
              └─> Módulo N  ...

A landing precisa deixar essa posição clara:

• *readcrumb no hero*ou navbar: Koder › Foundation › Koder Linux
• *ink de subida*pra Área-pai no header ou footer
• *iblings sectors*da mesma Área listados como nav lateral ou seção final

Estrutura do Arquivo

{sector}/site/
├── index.html       ← Landing de Sector (HTML monolítico inline)
├── icon.svg         ← Ícone do Sector (forma = conceito do agrupamento)
├── og-image.svg     ← Fonte da imagem OG (1200×630)
└── og-image.png     ← Imagem OG rasterizada

Para Sectors que *ão têm um módulo próprio*no monorepo e existem puramente como taxonomia (ex.: uma agrupação virtual), colocar em sites/{sector-slug}/ seguindo a convenção do que é feito para as landings de Área.

Para Sectors que *oincidem com um módulo flagship*(ex.: Koder Kompass = platform/kompass), a landing do módulo também serve como landing do Sector — nesse caso *ão se cria landing separada* o {sector}.koder.dev aponta pro mesmo diretório.

Head — Meta Tags e Setup

Meta Tags Obrigatórias

<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>{Sector} — {Tagline curta do agrupamento}</title>
<meta name="description" content="{1-2 frases sobre o que o Sector agrupa e por quê}">
<meta name="keywords" content="{slug dos módulos}, {área pai}, koder">

*omprimento máximo do <title>:*60 caracteres incluindo o separador — (3 chars). Browsers truncam a aba por volta de 55–60 chars; Google Search por volta de 55 chars. Exemplo dentro do limite: KDB — Multi-model database and storage (38 chars).

Open Graph + Twitter Card

Mesmas regras do products.kmd seção "Head". URL absoluta HTTPS para og:image (1200×630, PNG obrigatório).

Anti-Flash Script

Mesmo snippet do products.kmd e areas.kmd.

Favicon

<link rel="icon" type="image/svg+xml" href="icon.svg"> com o ícone do próprio Sector.

CSS — Design Tokens

*egra de reuso:*landings de Sector podem reaproveitar /ecosystem.css (o stylesheet compartilhado das landings de Área) pra manter coerência visual com a Área-pai. Acentos diferem:

• --ec (cor accent do Sector) herda a cor da Área-pai por padrão, mas pode ser override pra uma variante mais clara/saturada que identifique o Sector internamente
• Ícone SVG do Sector usa a mesma paleta, mas com forma distinta (cada Sector tem sua silhueta)

Se não usar /ecosystem.css, replicar os tokens padrão de produtos (--bg, --bg2, --bg3, --text, --text2, --text3, --accent, --accent2, --accent-light, --border, --card, --card-shadow, --gradient, --font, --mono) como definidos em products.kmd.

Seções Obrigatórias (em ordem)

1. Navbar

• Altura 64px, fixa no topo com backdrop-filter: blur(12px)
• Esquerda: .nav-brand com ícone SVG 32×32 + nome do Sector + breadcrumb Koder › {Área}
• Direita: .nav-links âncoras (#modules, #related, #about), theme toggle, botão "← Back to {Área}" pra subir na hierarquia
• *em*Login button (landings de Sector são navegacionais, não autentica ninguém)

2. Hero (coluna única, centralizado)

Diferente do products.kmd, o hero de Sector é *oluna única* não duas. A razão: não há um produto único a ilustrar, então não faz sentido um mockup/code block direita. O hero serve pra contextualizar o agrupamento.

Conteúdo:

• Eyebrow: {Área} · Sector N of M (ex.: "Foundation · Sector 2 of 7")
• H1: ícone SVG inline + nome do Sector com o mesmo span-gradient do products.kmd
• Tagline curta (1 frase, font-size ~1.5rem)
• Lead paragraph (23 frases, `-text2`) explicando o que o Sector agrupa e por que existe
• CTA: botão primário "See all modules →" com anchor pra #modules
• Background: radial-gradient sutil atrás com a cor accent do Sector

3. Modules Grid (#modules)

*eção mais importante*— é a razão pela qual o Sector existe.

• .section-header com h2 ("Modules" ou "{Sector} Modules") + subtitle
• Grid: grid-template-columns: repeat(auto-fit, minmax(300px, 1fr)) com gap: 20px
• Cada card de módulo mostra:
  • Ícone do módulo (SVG 48×48, canto superior esquerdo)
  • Nome do módulo (h3, font-weight 700)
  • 1-2 frases descrevendo o módulo
  • Lista de tags/features-chave (até 3 tags pequenas tipo .tag do products.kmd — reutilizar padrão)
  • Link "Visit →" apontando pra landing do módulo ({slug}.koder.dev) ou fallback pra platform.koder.dev/{slug} se o módulo ainda não tem landing dedicada
• Hover: border muda pra var(--accent), translateY(-2px), sombra

4. How These Work Together (#about — opcional mas recomendada)

Se os módulos do Sector se integram entre si de forma relevante, incluir uma seção explicando como. Formato livre: diagrama ASCII, bloco de código, ou lista alternada (igual .code-section do products.kmd).

5. Related Sectors (#related)

Grid horizontal ou vertical com *s outras Sectors da mesma Área*(excluindo a atual). Permite navegação lateral sem voltar à Área.

• Cards menores que o Modules Grid
• Cada card: ícone + nome do Sector + link pra {sector}.koder.dev
• Card da Sector atual NÃO aparece (só as siblings)

6. Back to Area CTA

Ao final da página, banner destacado (fundo var(--bg2) ou gradient suave) convidando o visitante a voltar pra Área-pai:

• H2: "Part of Koder {Área}"
• P: 1 frase descrevendo a Área
• Botão: "Explore {Área} →" apontando pra {área}.koder.dev

7. Footer

Igual ao products.kmd seção "Footer":

• border-top: 1px solid var(--border), padding: 40px 24px
• Flexbox: copyright esquerda + links direita
• Links do footer de Sector:
  • {Área} (sobe pra Área)
  • Koder (sobe pra raiz www.koder.dev)
  • Um link por módulo do Sector (opcional, se não poluir)

JavaScript — Comportamentos

Mínimo necessário: theme toggle + navbar scroll effect. Nada de filtros, acordeões ou busca — landings de Sector são enxutas por design.

OG Image

Mesmas regras do products.kmd. Conteúdo da thumb:

1. Ícone do Sector (canto esquerdo ou centralizado, ~30% da altura)
2. Nome do Sector em texto grande com gradient
3. Subtítulo: {Área} Sector · N modules
4. URL: {sector}.koder.dev discreta no canto

Responsividade

*egra:*toda landing de Sector deve funcionar sem problemas em dispositivos móveis. Isso é obrigatório — não opcional.

Breakpoints

• max-width: 768px: Navbar hamburger (breadcrumb completo pode ser ocultado, manter só ícone + nome do Sector), modules grid em 1-2 colunas, related sectors grid em 1 coluna
• max-width: 480px: Modules grid em 1 coluna, footer empilhado, padding lateral ≥ 16px

Regras obrigatórias

• Nenhum elemento deve causar *verflow horizontal*
• Breadcrumb longo (Koder › Foundation › Koder Linux) trunca ou some em mobile — nunca quebra o layout
• Modules grid (auto-fit, minmax(300px, 1fr)) — verificar que o minmax mínimo de 300px não força overflow em telas < 320px; se necessário, reduzir para minmax(260px, 1fr)
• Botões com área de toque mínima de *4×44px*
• Nenhum texto com fonte < 14px em mobile

Verificação obrigatória antes de deploy

1. *hrome DevTools → modo responsivo*→ testar em 375px, 390px e 768px
2. *em overflow horizontal* document.documentElement.scrollWidth === window.innerWidth
3. *avbar hamburger funcional*em 375px
4. *odules grid*em 1 coluna abaixo de 480px
5. *readcrumb*não vaza o layout em telas pequenas

Deploy

• Servir em https://{sector-slug}.koder.dev
• DNS A record no ClouDNS apontando pra 181.191.210.127
• Config em /etc/koder-jet/sites.toml na LXC s.k.lin
• HTTPS automático via koder-jet (ACME/Let's Encrypt)
• Quando o Sector *ão tiver*landing dedicada, criar redirect 301 do subdomínio do Sector pra landing do módulo único (via entrada redirect no sites.toml)

Referência Cruzada

• products.kmd — padrão das landings de módulo (os filhos do Sector)
• areas.kmd — padrão das landings de Área (a mãe do Sector)
• docs/stack/areas.md — fonte canônica das 9 Áreas e seus Sectors atuais
• sites/foundation/index.html — exemplo de como uma Área lista seus Sectors como cards clicáveis

Estado Atual (20260411)

Nenhum Sector tem landing dedicada hoje. Subdomínios de Sector como linux.koder.dev ou queues.koder.dev ainda não existem — os visitantes chegam nos módulos via landings de Área ou via platform.koder.dev. Essa spec normatiza o formato pra quando as primeiras landings de Sector forem criadas.