Baseline standards: design, SOP, CI policy

ci/ci_policy.md

@@ -0,0 +1,168 @@
+# CI_POLICY.md
+
+## Zweck
+Diese CI‑Policy definiert **verbindliche Regeln für Continuous Integration** in allen Projekten, die den wlkns‑Standards folgen.
+
+CI ist hier kein Komfort‑Feature, sondern ein **Qualitäts‑ und Sicherheits‑Gate**.
+
+Wenn die CI rot ist, ist das Ergebnis **nicht auslieferbar**. Diskussion zwecklos.
+
+---
+
+## Grundhaltung
+
+- CI ersetzt kein Denken
+- CI erzwingt Mindestqualität
+- CI ist reproduzierbar
+- CI ist deterministisch
+
+Eine Pipeline darf **nichts tun**, was lokal nicht ebenfalls prüfbar ist.
+
+---
+
+## Single Source of Truth
+
+Die fachliche Prüflogik liegt **nicht** in der CI‑Pipeline selbst.
+
+**Regel:**
+> Alles, was die CI prüft, muss lokal über definierte Befehle prüfbar sein.
+
+Bevorzugt:
+- `make check`
+- `make test`
+- `make lint`
+
+Die CI ruft diese Targets lediglich auf.
+
+---
+
+## Mindest‑Stages (verpflichtend)
+
+Jede Pipeline besteht mindestens aus folgenden Stages:
+
+1. **Preflight / Validation**
+2. **Lint / Static Checks**
+3. **Tests**
+4. **Build**
+
+Optional (projektspezifisch):
+- Security‑Scans
+- Image‑Scans
+- Deployment
+
+---
+
+## Stage 1 – Preflight
+
+Ziel:
+- Validierung der Projektstruktur
+- Prüfung der Voraussetzungen
+
+Typische Checks:
+- benötigte Dateien vorhanden
+- `.env.example` vollständig
+- keine Secrets im Repository
+- Tool‑Versionen kompatibel
+
+Fehlschlag ⇒ sofortiger Abbruch.
+
+---
+
+## Stage 2 – Lint / Static Checks
+
+Ziel:
+- einheitlicher Stil
+- frühe Fehlererkennung
+
+Regeln:
+- Linter sind Pflicht
+- Projekt‑spezifische Regeln sind erlaubt
+- Warnungen dürfen **nicht** ignoriert werden
+
+Ein Projekt ohne Linter gilt als unvollständig.
+
+---
+
+## Stage 3 – Tests
+
+Ziel:
+- funktionale Korrektheit
+- Schutz vor Regressionen
+
+Regeln:
+- automatisiert
+- reproduzierbar
+- ohne Seiteneffekte
+
+Keine Tests bedeutet:
+- kein Merge
+- kein Release
+
+---
+
+## Stage 4 – Build
+
+Ziel:
+- verifizierbare Artefakte
+
+Regeln:
+- Build muss lokal reproduzierbar sein
+- bei Containern: Image baubar
+- kein Push bei Fehlschlag
+
+Ein erfolgreicher Build bestätigt **technische Lieferfähigkeit**.
+
+---
+
+## Merge‑ & Release‑Regeln
+
+- Merges nur bei grüner Pipeline
+- Releases nur aus validierten Commits
+- kein Bypass der CI
+
+**Regel:**
+> Ein Commit ohne grüne CI existiert nicht.
+
+---
+
+## Tool‑Neutralität
+
+Diese Policy ist bewusst **CI‑System‑agnostisch**.
+
+Unterstützte Umgebungen (Beispiele):
+- GitHub Actions
+- Gitea Actions
+- GitLab CI
+
+Die Regeln bleiben identisch – nur die Syntax ändert sich.
+
+---
+
+## Verhältnis zu SOPs
+
+Diese CI‑Policy ergänzt die bestehenden SOPs.
+
+Beispiel:
+- Container‑SOP definiert `make check`
+- CI ruft exakt dieses Target auf
+
+Keine doppelte Logik. Keine Abweichungen.
+
+---
+
+## Anti‑Patterns
+
+- CI mit Projekt‑spezifischer Logik
+- Checks nur in der CI, nicht lokal
+- manuelles Überspringen von Stages
+- „temporär deaktivierte“ Tests
+
+Wenn die CI im Weg ist, ist das Problem **nicht** die CI.
+
+---
+
+## Status
+
+Version: **v1.0 (Baseline)**
+
+Änderungen an dieser Policy sind selten, bewusst und versioniert vorzunehmen.