Kalina
9e594e2f76
README beschreibt jetzt shell/ und den Ein-Zeilen-Aufruf ohne Token; Farbregel (Rot nur als Grafik, #E0454F fuer Text) steht dort, wo sie gelesen wird. SKILL.md auf 1.3.0 mit Abschnitt Shell/Terminal. CHANGELOG ohne Maschinen- und Hostnamen (Inhaltsregel). install.sh holt prompt.zsh bei Pipe-Aufruf ueber KALINA_CI_RAW. docs/aenderungen.md: Shell-Rollout per Skript nachziehen.
44 lines
2.3 KiB
Markdown
44 lines
2.3 KiB
Markdown
# Ä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.
|
|
- **Maschinen mit Shell-Prompt:** `shell/install.sh` erneut ausführen (idempotent, sichert
|
|
jede Datei) — nicht die Dateien einzeln nachziehen, sonst laufen die Fassungen auseinander.
|
|
|
|
## 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.
|