init: KALINA CI 1.0.0 - Marke, Satzvorlage, Vorlagen, Stempel, CLI

Zusammenfuehrung der bisher verstreuten CI (Markendoku + Open-WebUI-Skill) in ein
versioniertes Repository. Neu: tools/kalina-pdf (build/stamp/check/tokens),
tokens.json, docs/aenderungen.md als verbindlicher Aenderungsweg.

docs/aenderungen.md

@@ -0,0 +1,41 @@
+# Änderungen an der CI
+
+Die CI ist eine Vorlage mit vielen Nutzern (Menschen, Hermes, Paperclip-Agenten). Wer sie
+ändern will, ändert deshalb **eine Quelle** und nicht sieben Projekte.
+
+## Der Weg (verbindlich)
+
+1. **Issue im Repo** — was ist falsch, wo tritt es auf, welches Dokument zeigt es?
+   Ein Screenshot/Raster oder ein Seitenzahl-Füllgrad ist ein besserer Beleg als ein
+   Adjektiv.
+2. **Branch** `ci/<thema>` vom aktuellen `main`.
+3. **Änderung + Beleg**: betroffene Datei, ein gebautes Beispiel-PDF (nicht committen,
+   nur beschreiben oder als Kommentar) und `tools/kalina-pdf check` für das Beispiel.
+4. **PR** gegen `main`, im PR-Text: Issue-Referenz, Vorher/Nachher, geprüfte Seiten.
+5. **Review** durch `mm` oder das Agenten-Konto `kalina`. Bei Farben, Geometrie und
+   Marke gilt: nur mit Sichtprüfung eines gerasterten PDFs.
+6. **Merge** → `CHANGELOG.md` im selben PR ergänzen (Datum, was, warum).
+
+## Was danach passiert
+
+- **Hermes/Arbeitskopien:** `git -C <klon> pull --ff-only` (die CLI liest aus der Kopie).
+- **Paperclip-Skill:** `GET .../skills/<id>/update-status` zeigt, ob `main` weiter ist;
+  `POST .../skills/<id>/install-update` zieht die neue Fassung. Der Skill merkt sich
+  `ref` und `trackingRef`, ein Update ist damit nachvollziehbar statt „irgendwann".
+- **Bereits ausgelieferte PDFs** werden nicht rückwirkend geändert. Ein Neubau braucht
+  die Quelle (HTML) oder ein `kalina-pdf stamp` auf das alte PDF.
+
+## Was NICHT über die CI läuft
+
+- Projektspezifische Layouts (Deckblatttext, Kapitelstruktur, Anhänge). Die CI liefert
+  Satz und Marke, nicht den Inhalt.
+- Interne Verdrahtung: Hostnamen, Pfade, Schlüssel. Dafür gibt es die Betriebsdoku des
+  jeweiligen Systems.
+- Schnellschüsse wie „im Projekt die Farbe überschreiben". Wenn die CI nicht passt, ist
+  das ein Issue, kein lokaler `!important`.
+
+## Wenn es schnell gehen muss
+
+Notfall (ein Termin, ein Dokument): Änderung im Projekt, **im selben Tag** ein Issue mit
+der Abweichung und dem Grund. Eine Abweichung ohne Issue ist eine stille zweite CI — und
+die kostet beim nächsten Dokument mehr Zeit, als sie gespart hat.