KALINA CI

Corporate Identity der KALINA als versioniertes Artefakt: eine Satzvorlage (CSS), drei Dokumentvorlagen, die Marke als SVG, ein Stempel-Skript für fremde PDFs, eine CLI, die alle drei Wege bedient — und seit 1.3.0 dieselbe Farbwelt für Shell und Terminal. Ein Dokument, das nach KALINA aussehen soll, nimmt diese Dateien — keine nachgebauten Farben, kein selbst gezeichnetes Logo.

css/kalina-ci.css          Satzvorlage: @page A4, Kopfleiste, Tabellen, Plakette, Fußlinie
templates/                 report.html · page.html · bild-mit-prompt.html
assets/                    Marke als SVG (mark · wordmark · combined · favicon) + Vorschaubilder
scripts/stamp_existing_pdf.py   fremdes PDF mit Deckblatt/Marke/Fußzeile versehen
shell/install.sh           Shell-Prompt und Terminal-Palette auf einer Maschine einrichten
shell/prompt.zsh           zsh-Prompt als eigenständiges Modul (kein oh-my-zsh, kein p10k)
tools/kalina-pdf           CLI: build · stamp · check · tokens
tokens.json                Farben, Schriften, Geometrie, Zonen (maschinenlesbar)
SKILL.md                   Einstiegspunkt für Agenten (Frontmatter + Regeln + Fallen)
docs/aenderungen.md        der verbindliche Änderungsweg

Schnellstart

git clone <dieses-repo> kalina-ci && cd kalina-ci

cp templates/report.html bericht.html        # «Platzhalter» füllen
tools/kalina-pdf build bericht.html --stamp --titel "Angebot 2026-17"

tools/kalina-pdf stamp fremd.pdf -o fremd-kalina.pdf --titel "Rechnung 4711"
tools/kalina-pdf check bericht.pdf --raster raster/

Voraussetzungen: weasyprint (Layout), pymupdf (Messung/Raster), matplotlib + pypdf (Stempel), pdftoppm optional für Sichtprüfung.

Farben

Ink #0B0F14 · Bone #F5F5EF · Kalina-Rot #C1121F · Steel #3A4250 · Muted #8A94A2

Kalina-Rot hat auf Ink nur 3,09:1 Kontrast und ist deshalb Grafik, nicht Text. Für Text auf Ink gilt #E0454F (4,70:1) — dieselbe Entscheidung wie im VS-Code-Theme und im Prompt.

Shell und Terminal

Die CI endet nicht am Papier. shell/ bringt denselben Satz in die Shell: zweizeiliger Prompt, Terminal-Palette, ein Skript für beides.

┌─ kalina  ~/kalina-ci · main ✚1 ✎2 · 4.2s
└─ ❯

curl -fsSLo install.sh https://gitea.m-m.bio/mm/kalina-ci/raw/branch/main/shell/install.sh
bash install.sh --dry-run   # zeigt, was passieren würde
bash install.sh             # führt es aus

Kein Token nötig — das Repo ist öffentlich lesbar. Das Skript ist idempotent, sichert jede Datei nach .vor-kalina-ci-<stempel> und erkennt foot, qterminal, xfce4-terminal und xterm; zsh installiert es über den vorhandenen Paketmanager. Schalter: --shell-only, --terminal-only, --no-chsh. Details und die Fallen beim Ausrollen stehen in shell/README.md.

Wie Agenten das nutzen

Zwei Wege, gleicher Inhalt:

1. Als Skill importiert (Paperclip: POST /api/companies/<id>/skills/import mit {"source": "<URL dieses Repos>"}). Der Import liest SKILL.md und alle Dateien darunter, hält ref und trackingRef fest und meldet Aktualisierungen über update-status.
2. Als Arbeitskopie (Hermes, Skripte, Cron): Repo klonen, tools/kalina-pdf aus der Kopie aufrufen. Die CLI findet CSS, Vorlagen und Stempel relativ zu sich selbst.

Zugriff

Das Repo ist öffentlich lesbar — nicht aus Bequemlichkeit: der Skill-Import der Paperclip-Instanz holt Bäume und Rohdateien ohne Authentifizierung, ein privates Repo wäre dort nicht importierbar. Deshalb gilt die Inhaltsregel:

Keine internen Hostnamen, keine IP-Adressen, keine Zugangsschlüssel, keine Kundeninhalte. Interne Verdrahtung gehört in die jeweilige Betriebsdoku, nicht hierher.

Schreibzugriff haben mm (Owner) und das Agenten-Konto kalina (Collaborator, write). Weitere Agenten werden als Collaborator mit write aufgenommen — die CI ist kein Diskussionsgegenstand, sondern eine Vorlage, die Agenten anwenden.

Änderungen

Nicht ad hoc. Der Weg steht in docs/aenderungen.md: Issue im Repo → Branch ci/<thema> → PR → Review → Merge → CHANGELOG.md ergänzen. Wer die CI in einem Projekt „schnell anders" braucht, ändert das Projekt, nicht die CI.