`granularity` ist die eine Option, die der Typ liest. Sie nimmt `split` — den
Standard — oder `flat`, und der Unterschied reicht weiter als die Seitenzahl.

```ts
{
  type: 'changelog',
  path: 'CHANGELOG.md',
  label: 'Changelog',
  options: { granularity: 'flat' }
}
```

## `split` — eine Seite pro Release

Der Standard, und wofür eine Release-Historie da ist. Jedes Release wird zu einer
eigenen Seite unter einer generierten Übersicht, was vier Dinge kauft, die eine
einzelne Seite nicht haben kann:

- einen **Deep Link** auf ein Release, und auf eine Gruppe darin;
- einen **Suchtreffer**, der das Release ist und nicht die ganze Datei;
- einen **Feed-Eintrag** pro Release, sobald
  [`feed.path`](/reference/changelog/section) die Sektion benennt;
- einen **`llms.txt`-Eintrag** pro Release, sodass ein Modell, das fragt, was sich
  in `2.1.0` geändert hat, dieses Release bekommt und nicht vierhundert Kilobyte
  Historie.

Die Übersicht ist eine Zeitleiste — jedes Release, neueste zuerst, mit seinem
Datum und den Arten von Änderung daneben, filterbar nach diesen Arten. Die
Einträge selbst bleiben auf den Release-Seiten: Sie auf der Übersicht zu
wiederholen würde das ganze Changelog doppelt in den Suchindex, in
`llms-full.txt` und in den Feed legen.

Getrennte Seiten rendern in einem **eigenen Layout**: die Releases in der
Seitenleiste, eine auf ein Maß begrenzte Lesespalte und eine Inhaltsspalte, die
die Gruppen listet. Siehe [Komponenten](/reference/changelog/components).

## `flat` — die Datei, wie sie ist

Eine Seite, die die Datei hält, wie sie geschrieben wurde. Für ein Projekt, das
sein Changelog einfach gezeigt haben will.

Ein flaches Changelog ist eine **gewöhnliche Doku-Seite** und behält das
Doku-Gerüst — die Prosa-Seitenleiste, den Brotkrumenpfad und ein
Inhaltsverzeichnis, das die Releases listet, was eine lange Datei genau will.
Deshalb wird die Layout-Frage aus den Optionen der Deklaration beantwortet und
nicht vom Typ festgelegt: Derselbe Typ erzeugt zwei verschiedene Dinge.

Nichts wird umgeschrieben außer dem Titel. Das eigene `# Changelog` der Datei
geht, weil die Seite ihre Überschrift aus `title` zieht und ein zweites `<h1>` im
Körper sowohl ein Duplikat als auch ein Barrierefreiheits-Befund ist. Jede
Release-Überschrift bleibt genau dort, wo das Release-Werkzeug sie hingeschrieben
hat — was „unverändert“ heißen muss, sonst ist der Modus nicht die Notluke, für
die es ihn gibt.

## Wozu greifen

| Du willst                                                       | Nimm    |
| :--------------------------------------------------------------- | :------ |
| Eine Release-Historie, durch die Leser navigieren und verlinken   | `split` |
| Einen Feed, oder Einträge pro Release in `llms.txt`               | `split` |
| Die Datei gezeigt wie geschrieben, ohne erfundene URLs            | `flat`  |

::callout{type="warning" title="Eine falsch geschriebene Option lässt den Build scheitern"}
`granularty`, oder eine Granularität, die keine der beiden ist, hält den Build an
und nennt den Schlüssel oder Wert, den er nicht erkannt hat. Ein Zeichen neben dem
Schlüssel, der funktioniert, ist eine Site, die still den Standard bekommt statt
dessen, was sie konfiguriert hat, und der Build ist der letzte Ort, der das sagen
kann.
::