# 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.