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 Sectors. Um Sector agrupa 1–N módulos do monorepo que servem juntos um mesmo propósito.

Exemplos de Sectors:

Área	Sector	Módulos agrupados
Foundation	Koder Linux	linux/distro, linux/shell, linux/x, linux/keyboard, linux/kolide
Foundation	Koder Kompass	platform/kompass + sub-módulos platform/crm, platform/desk
Data Platform	Queues	data/mq, platform/q
Observability	Logging	observe/log, platform/log
Intelligence	AI Runtime	ai/runtime, ai/gateway, ai/guard

Landings de Sector são uma camada 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)

Cenário	Landing de Sector?	Alternativa
Sector com ≥ 2 módulos de peso equivalente (ex.: Koder Linux com distro + shell + keyboard)	Sim — landing própria	—
Sector com ≥ 2 módulos, mas um é claramente o flagship e os outros são satélites	Opcional	Landing do flagship serve como "de facto" do Sector, com seção "Related" listando os satélites
Sector com 1 único módulo	Não	O subdomínio do Sector redireciona HTTP 301 pra landing do módulo único
Sector ainda em planejamento (nenhum módulo implementado)	Não	Marcar como "upcoming" no card da Área, sem subdomínio próprio

Regra prática: landing de Sector se justifica quando um visitante da Área precisa escolher 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:

• Breadcrumb no hero ou navbar: Koder › Foundation › Koder Linux
• Link de subida pra Área-pai no header ou footer
• Siblings 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 nã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 coincidem com um módulo flagship (ex.: Koder Kompass = platform/kompass), a landing do módulo também serve como landing do Sector — nesse caso nã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">

Comprimento 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

Regra 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
• Sem 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 é coluna ú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 (2-3 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)

Seçã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 as 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

Regra: 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 overflow 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 44×44px
• Nenhum texto com fonte < 14px em mobile

Verificação obrigatória antes de deploy

1. Chrome DevTools → modo responsivo → testar em 375px, 390px e 768px
2. Sem overflow horizontal: document.documentElement.scrollWidth === window.innerWidth
3. Navbar hamburger funcional em 375px
4. Modules grid em 1 coluna abaixo de 480px
5. Breadcrumb 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 nã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 (2026-04-11)

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.