Migrate all repos into monorepo context folders

Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
      Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
      Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)

Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.

bahn/O2C-Harness/quality-gates.md

@@ -0,0 +1,115 @@
+# Quality Gates (Pflicht vor jedem Commit)
+
+## Reihenfolge vor dem Commit
+
+Alle Checks MÜSSEN lokal bestehen bevor committed wird:
+
+### 1. Linter (je nach Stack)
+
+```bash
+# Java
+./mvnw checkstyle:check
+
+# Python
+ruff check .
+ruff format --check .
+
+# Go
+golangci-lint run
+
+# Node/TypeScript
+npm run lint
+
+# Shell-Scripts
+shellcheck *.sh
+
+# YAML
+yamllint .
+
+# Dockerfile
+hadolint Dockerfile
+```
+
+### 2. Tests
+
+```bash
+# Java
+./mvnw test
+
+# Python
+pytest -v --cov --cov-fail-under=80
+
+# Go
+go test ./... -cover
+
+# Node
+npm test
+```
+
+### 3. Security-Scans
+
+```bash
+# Secrets im Code suchen
+gitleaks detect --source . --no-git
+
+# Dependency-Vulnerabilities (Filesystem)
+trivy fs --severity HIGH,CRITICAL .
+
+# Docker-Image scannen (wenn Dockerfile vorhanden)
+docker build -t app:scan .
+trivy image --severity HIGH,CRITICAL app:scan
+```
+
+### 4. Erst dann committen
+
+Nur wenn ALLE Checks grün sind:
+```bash
+git add -A
+git commit -m "feat(scope): beschreibung (#issue)"
+```
+
+## Bei Findings
+
+- **Linter-Fehler**: Sofort fixen
+- **Test-Failures**: Code korrigieren bis grün
+- **Trivy HIGH/CRITICAL**: Dependency updaten oder begründen (ADR)
+- **Gitleaks**: Secret entfernen, .gitignore anpassen
+
+## Verfügbare Tools im Container
+
+Alle vorinstalliert – keine Installation nötig:
+- `trivy` – Container/Filesystem/Dependency Scanner
+- `gitleaks` – Secret Detection
+- `golangci-lint` – Go Linter
+- `ruff` – Python Linter/Formatter
+- `hadolint` – Dockerfile Linter
+- `shellcheck` – Shell Script Linter
+- `yamllint` – YAML Linter
+
+## Renovate-MRs prüfen (vor Dependency-Änderungen)
+
+BEVOR du manuell Dependencies aktualisierst oder Vulnerabilities fixst:
+
+```bash
+# Offene Renovate-MRs im Projekt prüfen
+GITLAB_HOST=git.tech.rz.db.de glab mr list --author=renovate-bot --state=opened
+```
+
+Wenn Renovate bereits einen MR für die betroffene Dependency hat:
+1. **Nicht selbst fixen** – Renovate-MR nutzen
+2. Pipeline des Renovate-MR prüfen
+3. Bei grüner Pipeline: Approve + Merge
+4. Bei fehlgeschlagener Pipeline: Retry oder manuell fixen und in den Renovate-Branch pushen
+
+### Warum?
+
+- Renovate trackt Versionen zentral
+- Doppelte Updates führen zu Merge-Konflikten
+- Renovate erstellt saubere Changelogs
+- Renovate-MRs sind bereits getestet
+
+### Nur manuell fixen wenn:
+
+- Kein Renovate-MR existiert
+- Renovate-MR ist seit >7 Tagen offen und blockiert
+- Renovate kann die Vulnerability nicht lösen (z.B. Major-Version-Sprung nötig)