Frontmatter

Todos os campos de frontmatter que uma página aceita, todos opcionais — título, descrição, barra lateral, SEO, pesquisa e os demais, com o que cada um controla.

Todas as páginas aceitam o frontmatter a seguir. Todos os campos são opcionais.

Barra lateral

sidebar:
  label: Install
  order: 2
  icon: download
  badge: New
  hidden: false

SEO

seo:
  title: Install Blume
  description: Install Blume and scaffold your first project.
  image: /og/install.png
  canonical: https://acme.com/install
  noindex: false

Pesquisa

search:
  exclude: false
  tags: [api]

Changelog

As entradas de changelog (type: changelog) aceitam um objeto changelog opcional para metadados mais ricos de feed e exibição:

type: changelog
changelog:
  version: 1.2.0
  date: 2026-06-20
  category: Features

date pode ficar aqui ou no nível superior — ambos alimentam o feed RSS do changelog. Consulte Changelog para a página de linha do tempo gerada e o feed.

Chaves personalizadas

Qualquer chave fora desta referência faz a build falhar, então erros de digitação são detectados cedo. Projetos que carregam seus próprios metadados podem incluir chaves extras via frontmatter.extend em blume.config.ts, cada uma validada por um schema fornecido pelo projeto:

import { defineConfig } from "blume";
import { z } from "zod";

export default defineConfig({
  frontmatter: {
    extend: {
      owner: z.string(),
      reviewedAt: z.coerce.date().optional(),
    },
  },
});

---
title: Install
owner: "@sam"
reviewedAt: 2026-06-20
---

Os schemas são aceitos pela interface Standard Schema, então Zod (qualquer que seja a versão instalada pelo seu projeto), Valibot e ArkType funcionam. Toda chave declarada é validada em cada página — inclusive as ausentes — de modo que um schema obrigatório impõe a chave em todo o site; marque-a como .optional() para validar apenas onde estiver presente. Todas as demais chaves permanecem estritamente validadas, e os campos integrados não podem ser redeclarados.

Chaves por tipo

Para exigir chaves apenas em um tipo de conteúdo — o status de uma RFC, a severity de um relatório de incidente — declare-as em content.types, organizadas pelo type do frontmatter ao qual se aplicam:

import { defineConfig } from "blume";
import { z } from "zod";

export default defineConfig({
  content: {
    types: {
      rfc: {
        frontmatter: {
          domain: z.string(),
          status: z.enum(["draft", "review", "enforced"]),
        },
      },
    },
  },
});

---
title: OpenAPI request schemas
type: rfc
domain: architecture
status: enforced
---

As chaves por tipo seguem as mesmas regras de validação de extend, restritas às páginas cujo type resolvido corresponda — incluindo páginas que não definem nenhum type, quando a declaração é para content.defaultType. Uma chave pertence a uma única declaração, no site inteiro ou por tipo, nunca às duas. E uma chave declarada apenas para outro tipo continua desconhecida nos demais, então um status perdido numa página de doc comum ainda faz a build falhar.

Uma página que falha na validação faz blume build falhar com um diagnóstico nomeando o arquivo e a chave. Com --no-strict, a build é bem-sucedida mesmo assim e as páginas com falha são removidas da saída — o resumo da build informa quantas.

Os schemas são exportados de blume/schema para ferramentas de edição e migração.