![KALINA](assets/logo-platte.png) # 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.** ![Vorschau: Deckblatt aus der Vorlage, Prompt in der Shell, Token in der Fußlinie](assets/vorschau.png) ``` 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 ```bash git clone 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 └─ ❯ ``` ![Der Prompt in einem Terminal mit CI-Palette](assets/vorschau-shell.png) > **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. ```bash 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-` 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`](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: ```bash 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. ![Ptyxis unter Wayland mit der CI-Palette](assets/vorschau-ptyxis.png) 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//skills/import` mit `{"source": ""}`). 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`](docs/aenderungen.md): Issue im Repo → Branch `ci/` → PR → Review → Merge → `CHANGELOG.md` ergänzen. Wer die CI in einem Projekt „schnell anders" braucht, ändert das Projekt, nicht die CI.