kalina-ci/README.md

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
└─ ❯

zsh ist Pflicht. Der Prompt ist ein zsh-Modul; in bash passiert nichts. Das Skript installiert zsh selbst — apt-get, dnf, pacman, zypper oder apk, je nach System. Fehlt der Paketmanager oder verlangt sudo ein Passwort, bricht der Shell-Teil ab, nennt den genauen Befehl und lässt ~/.zshrc unangetastet: lieber kein Prompt als ein stummer. Danach einmal neu einloggen (oder exec zsh), sonst greift die Login-Shell-Änderung nicht.

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. Schalter: --shell-only, --terminal-only, --no-chsh. Details und die Fallen beim Ausrollen stehen in shell/README.md.

Ubuntu 26 und Wayland

Ubuntu 26.04 bringt GNOME 50 und damit Ptyxis als Standard-Terminal: Wayland-nativ, ohne X11-Rueckfall. Der Prompt laeuft dort unveraendert (zsh ist in Ubuntu dabei), die Palette kommt als Datei ins Benutzerverzeichnis — kein sudo, kein Paket, kein Kompilieren:

mkdir -p ~/.local/share/org.gnome.Ptyxis/palettes
curl -fsSLo ~/.local/share/org.gnome.Ptyxis/palettes/KalinaCI.palette \
  https://gitea.m-m.bio/mm/kalina-ci/raw/branch/main/shell/palettes/KalinaCI.palette

Danach in Ptyxis: Einstellungen → Aussehen → Palette „Kalina CI" (gegebenenfalls „Alle Paletten anzeigen"). install.sh macht beides — Datei ablegen und die Palette am Profil eintragen (dconf-Schluessel org.gnome.Ptyxis.Profile:…/palette), samt DejaVu Sans Mono 12. Gibt es noch kein Profil, sagt es das und nennt den Weg von Hand.

Gemessen an einem echten Wayland-Screenshot (Ptyxis 50.1, VTE 0.84): 74,9 % der Flaeche #0B0F14, 11,9 % Titelbar #0E131A, ANSI-Rot und -Gruen innerhalb 2/255 der Vorgabe.

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.