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.
2026-06-30 20:39:52 +02:00
parent 2f2b295531
commit a5f8fb49ab
1717 changed files with 447332 additions and 0 deletions
@@ -0,0 +1,70 @@
+# Powers
+
+Dieser Ordner enthält **Kiro Powers**: gebündeltes Dokumentations-/Workflow-Wissen,
+das Kiro bei passenden Anfragen automatisch aktiviert.
+
+> Was ist eine Power? Eine Power verpackt Wissen (`POWER.md`), optionale
+> Workflow-Guides (`steering/*.md`) und optional MCP-Server. Kiro lädt die
+> Detail-Instruktionen erst bei Bedarf („on-demand") — das hält den Kontext schlank.
+
+## Enthaltene Powers
+
+| Power | Zweck | Aktiviert bei Themen wie |
+|-------|-------|--------------------------|
+| [`db-openshift-deploy`](db-openshift-deploy/) | Manuelles Deployment: Docker → Artifactory → OpenShift (`oc`) | openshift, oc, dbcs, artifactory, image pull |
+| [`db-pipeship-onboarding`](db-pipeship-onboarding/) | Repo mit pipeship aufsetzen (CI/CD bis Prod, K8s, Trivy, Renovate) | pipeship, gitlab ci, deploy_k8s_generic, cdaas |
+| [`db-dxp-platform`](db-dxp-platform/) | Nachschlagewerk DXP-Ökosystem (pipeship, CDaaS, Portal, Compliance) | dxp, developer portal, crossplane, flux, tenant |
+| [`db-scm-info-compliance`](db-scm-info-compliance/) | `scm-info.yaml` erstellen/validieren + Compliance-Checks | scm-info, compliance suite, beam id, sbom |
+
+Jede Power liegt in einem eigenen Ordner mit einer `POWER.md` (Pflicht); manche
+haben zusätzlich `steering/`-Dateien für vertiefende Workflows.
+
+```
+powers/
+├── README.md                       # diese Datei
+├── db-openshift-deploy/
+│   └── POWER.md
+├── db-pipeship-onboarding/
+│   ├── POWER.md
+│   └── steering/
+│       └── repo-typen.md
+├── db-dxp-platform/
+│   └── POWER.md
+└── db-scm-info-compliance/
+    └── POWER.md
+```
+
+## Installation (lokal testen)
+
+Powers werden über die **Powers-UI** in Kiro installiert:
+
+1. **Powers-Panel öffnen**: Powers-Icon in der Kiro-Sidebar — oder Command Palette →
+   *„Powers"* — oder Kiro bitten: „Open the powers configuration".
+2. **„Add Custom Power"** klicken.
+3. **„Local Directory"** wählen.
+4. **Absoluten Pfad** zum gewünschten Power-Ordner einfügen, z. B.:
+   ```
+   <PFAD-ZUM-REPO>/powers/db-pipeship-onboarding
+   ```
+   (Pro Power einmal — der Pfad zeigt auf den Ordner, der die `POWER.md` enthält.)
+5. **„Add"** klicken. Die Power erscheint unter *Installed Powers* (Status „Active").
+
+> **Wichtig:** Der Pfad muss **auf den einzelnen Power-Ordner** zeigen (mit `POWER.md`
+> direkt darin), **nicht** auf `powers/`.
+
+## Teamweite Verteilung
+
+Da dieses Repo ein Git-Repo ist, können die Powers auch als **Repository-Quelle** in
+Kiro hinterlegt werden — dann installiert das Team sie direkt aus Git statt über lokale
+Pfade. In der Powers-UI eine Custom-Repository-Quelle mit der Repo-URL und dem Pfad
+`powers/<power-name>` hinzufügen.
+
+## Eigene Power hinzufügen
+
+1. Neuen Ordner `powers/<name>/` anlegen.
+2. `POWER.md` mit Frontmatter (Name, Beschreibung, Keywords) + Inhalt erstellen.
+3. Optional `steering/*.md` für vertiefende Workflows ergänzen.
+4. Diese Tabelle oben aktualisieren, committen, pushen.
+
+Mehr zum Bauen eigener Powers: https://kiro.dev/docs/powers/ — sowie die offizielle
+Power **„Build a Power"** (`power-builder`) in der Kiro-Powers-Registry.
@@ -0,0 +1,100 @@
+---
+name: "db-dxp-platform"
+displayName: "DB DXP Platform Guide"
+description: "Nachschlagewerk zum DB Developer Experience Platform (DXP) Ökosystem: pipeship, CDaaS GitLab Runner, Developer Portal (Tenants, GitOps/Flux, Crossplane), Compliance Suite und DBCS/Kubernetes-Integration. Erklärt, was die Bausteine sind und wie sie zusammenspielen."
+keywords: ["dxp", "developer portal", "pipeship", "cdaas", "compliance suite", "dbcs", "backstage", "crossplane", "flux gitops", "tenant"]
+author: "einfachbahn-lab"
+---
+
+# DB DXP Platform Guide
+
+## Overview
+
+Diese Knowledge-Base-Power erklärt das Ökosystem der **Developer Experience Platform (DXP)**
+der DB Systel (Teil von *build IT*). Sie beantwortet Fragen wie „Was ist pipeship/CDaaS?",
+„Wofür brauche ich einen Tenant?", „Wie hängen Developer Portal, GitOps und Crossplane
+zusammen?". Für die konkrete Repo-Initialisierung mit pipeship siehe die Power
+**DB pipeship Onboarding**.
+
+## Die Bausteine
+
+| Produkt | Zweck |
+|---------|-------|
+| **pipeship** | Pipeline-as-a-Service: fertige, DB-konforme GitLab-CI/CD-Pipeline-Module (per `include` aus Artifactory) |
+| **CDaaS** | Continuous-Delivery-as-a-Service: gehärtete GitLab Runner (Shared, Base/Multi-Tenant, selfhosted für AWS/k8s/OpenShift) |
+| **Developer Portal** | Self-Service-Oberfläche (Backstage) für Tenants, Templates, Integrationen, Status, Compliance |
+| **Compliance Suite** | Scannt Repos auf Secrets, Schwachstellen, Lizenzen; erstellt SBOMs |
+| **DBCS** | DB Container Services: OpenShift-Cluster + KAS (Kubernetes-as-a-Service) |
+
+Gemeinsame Tool-Basis: **GitLab, Artifactory, CDaaS, OpenShift (DBCS)**.
+
+## Zentrale URLs
+- Developer Portal: https://db.de/dxp · https://dp.dxc.comp.db.de
+- pipeship: https://db.de/pipeship
+- CDaaS: https://db.de/cdaas
+- DBCS: https://db.de/dbcs
+- Compliance Findings: https://dp.dxc.comp.db.de/compliance/repositories
+- Kubernetes-UI Headlamp: https://headlamp.dxc.comp.db.de
+- GitLab: https://git.tech.rz.db.de · Artifactory: https://bahnhub.tech.rz.db.de
+- Digitalshop: https://dbdigitalshop.service-now.com/digitalshop
+
+## Kernkonzepte
+
+### DXP Mandant (Tenant)
+Logische Einheit im Developer Portal, die alle Ressourcen einer **Anwendung** bündelt
+(nicht teamorientiert). Verwaltet Rollen, Kostenstellen, Integrationen zentral; Repos erben
+die Konfiguration. Jeder Tenant erhält den K8s-Namespace `p-{tenant-name}-tenant` mit
+AGE-Key, Metadata/Environment-Ressourcen, ServiceAccount/RoleBinding und Crossplane-XRs.
+Bestellung einmalig kostenfrei im Digitalshop (kostenpflichtig nur deployte Ressourcen).
+
+### Provisionierung: Crossplane + FluxCD (GitOps)
+- Zielzustand liegt als YAML im **GitOps-Repo** (`tenant-information`).
+- **Flux** reconciled asynchron (kein direkter Effekt beim Push wie bei Pipelines).
+- **Crossplane** provisioniert die Ressourcen (DBMC-Datenbanken, DBCS-Namespaces, Artifactory).
+- **Software-Templates** (Backstage Scaffolder) scaffolden komplette App-Repos inkl.
+  pipeship-Pipeline, K8s-Namespace, DB und CDaaS-Runner.
+
+```mermaid
+flowchart TB
+    DP[Developer Portal<br/>Backstage] -->|Tenant + Templates| GR[GitOps-Repo<br/>tenant-information]
+    GR -->|Flux reconcile| CP[Crossplane]
+    CP --> NS[K8s-Namespace DBCS]
+    CP --> DB[(DBMC-Datenbank)]
+    CP --> AF[Artifactory-Registries]
+```
+
+### Rollen (Least Privilege)
+`managers` (fachlich, entscheiden über Zugriff/Metadata), `owners` (technisch, Integrationen),
+`developers` (i. d. R. Lese-, je Integration Schreibrechte), `readers` (nur einsehen).
+Pro Rolle wird automatisch eine **ACAT-Gruppe im BKU AD** erzeugt. Besteller wird Manager.
+
+### CDaaS Runner-Varianten
+- **Shared Agent**: geteilte GitLab Shared Runner (Fair-Use, nur kleine Pipelines), Tag `cdaas-shared-agent`.
+- **Base Runner (Beta)**: zentral, mandantenfähig, Pay-per-Use; Tags z. B. `build-base-runner`, `prod-base-runner`. Sicherheit über **Cred&Gator** (Berechtigung an Pipeline gebunden, nicht an Runner).
+- **Selfhosted Agents**: Helm (k8s/OpenShift) oder CDK-Library (AWS), im eigenen Namespace/Account.
+
+### Compliance Suite (Scanner)
+- **Secrets (Betterleaks)**, **Dependencies (Syft+Grype)**, **DB Compliance** (Projekteinstellungen, README/LICENSE/scm-info.yaml), **Licenses (Grant)**.
+- Wöchentliche Scans (Di/Do/Sa 18:00), Dependency-Checks alle 12 h. SBOM bei jedem Scan.
+- Basisscans kostenlos; Ergebnisse im Developer Portal.
+
+### DBCS/Kubernetes-Integration
+- Namespaces (OpenShift „Projects") werden als `Project`-Ressource (`kas.dp.db.de/v1alpha1`) im GitOps-Repo beschrieben.
+- `pipeshipSupport: true` legt automatisch Secrets an (`artifactory-stage/-read/-release`, `docker-pull-secret`, `gitlab-user`/`gitlab-test-user`).
+- **OpenShift unterstützt keine Wildcards** in docker-pull-secrets → Registries explizit in `customDockerRepos` deklarieren.
+- Cluster-Inspektion für Advanced User über **Headlamp** (SSO) oder das Kubernetes-Plugin im Portal.
+
+## Häufige Fragen
+- **„pipeship oder CDaaS?"** — pipeship liefert die Pipeline-Logik (Jobs/Module), CDaaS die Runner, auf denen sie läuft. pipeship baut auf CDaaS auf.
+- **„Brauche ich einen Tenant?"** — Für GitOps-Provisionierung (DBMC/DBCS) und pipeship-Onboarding ja. Nur um Compliance-Findings zu sehen: nein.
+- **„Wo liegt was?"** — Grundkonfiguration im Portal-UI; Infrastruktur-YAML im GitOps-Repo; Schnellstart über Software-Templates.
+
+## Best Practices
+- Updates zeitnah (Empfehlung ≤ 14 Tage), automatisiert via **Renovate** → bleibt compliant.
+- Gruppennamen GitLab = Artifactory-Team-Name, nur Kleinbuchstaben/Zahlen.
+- Vor `pipeshipSupport: true` vorhandene Secrets (`pipeship-secrets`, age/GPG-Keys) sichern — werden überschrieben.
+
+## Weiterführend
+Vollständige Wissensbasis im Repo `einfachbahn-lab/doku/deployment-doku`, Datei
+`docs/08-dxp-plattform.md`. Doku-Quellen (DB-Login nötig): `git.tech.rz.db.de/pipeship/docs/docs-as-code`,
+`.../devex-core/buildit-docu`, `.../cdaas/documentation`.
@@ -0,0 +1,130 @@
+---
+name: "db-openshift-deploy"
+displayName: "DB OpenShift Deploy"
+description: "Manuelles Deployment im DB-Konzern: Docker-Image bauen, ins Artifactory (jFrog/bahnhub) pushen und auf einem OpenShift-Cluster (DBCS) per oc deployen. Inklusive Secrets, Image-Pull-Secret und Troubleshooting."
+keywords: ["openshift", "oc cli", "dbcs", "artifactory", "bahnhub", "docker image", "kubernetes deployment", "image pull secret", "imagepullbackoff"]
+author: "einfachbahn-lab"
+---
+
+# DB OpenShift Deploy
+
+## Overview
+
+Diese Power bündelt das Wissen, um eine containerisierte Anwendung im DB-Konzern
+**manuell** auf einem OpenShift-Cluster (DB Container Services, DBCS) zu betreiben:
+Image mit Docker bauen, ins **Artifactory** (`bahnhub.tech.rz.db.de`) pushen und mit
+`oc apply` deployen. Ideal für Prototypen, Labs und kleine Services. Für den
+standardisierten, compliance-konformen Weg siehe die Power **DB pipeship Onboarding**.
+
+## Onboarding
+
+### Voraussetzungen
+- **DeBi-Account** (SSO für Git, Artifactory, OpenShift). Für GitLab ist zusätzlich eine Bestellung im Digitalshop nötig.
+- **Docker Desktop** (Image-Build)
+- **`oc` CLI** (OpenShift-Client; aus der Console: `?` → *Command Line Tools*)
+- Ein **Docker-Repo im Artifactory** (einmalig über Self-Service https://bass.tech.db.de/welcome beantragen)
+- **Artifactory-API-Key**: https://bahnhub.tech.rz.db.de → Profil → *Edit Profile* → API Key
+
+### Wichtige Links
+- Artifactory Self-Service: https://bass.tech.db.de/welcome
+- jFrog Artifactory: https://bahnhub.tech.rz.db.de/ui/packages
+- GitLab: https://git.tech.rz.db.de/
+- OpenShift Console (Beispiel): https://console-openshift-console.apps.dbcs-riga.comp.db.de/
+
+## Key Concepts
+
+| Begriff | Bedeutung |
+|---------|-----------|
+| Image | Unveränderliches Paket aus App + Abhängigkeiten + Laufzeit |
+| Registry | Image-Speicher — hier Artifactory `bahnhub.tech.rz.db.de` |
+| OpenShift | Enterprise-Kubernetes von Red Hat (= k8s + Console, `oc`, `Route`, strenge SCC) |
+| Deployment | Beschreibt den Pod (Image, Env, Ressourcen, Health-Checks) |
+| Service | Cluster-interne stabile Adresse |
+| Route | OpenShift-Objekt: HTTPS-Zugang von außen (TLS-Termination) |
+| PVC | Persistenter Speicher, überlebt Pod-Neustarts |
+
+## Common Workflows
+
+### 1. Image bauen + pushen
+**Immer `--platform linux/amd64`** (auch auf Apple Silicon), Base-Images aus dem
+Artifactory-Mirror (kein Docker-Hub-Direktzugriff im Cluster).
+
+```bash
+docker login einfachbahnlab-docker-stage-local.bahnhub.tech.rz.db.de   # User=DeBi, Pass=API-Key
+docker build --platform linux/amd64 \
+  -t einfachbahnlab-docker-stage-local.bahnhub.tech.rz.db.de/api-viewer:0.8.0 .
+docker push einfachbahnlab-docker-stage-local.bahnhub.tech.rz.db.de/api-viewer:0.8.0
+```
+
+### 2. Erst-Setup im Namespace
+```bash
+# Am Cluster anmelden (öffnet SSO im Browser)
+oc login https://api.dbcs-riga.comp.db.de:6443
+
+# Image-Pull-Secret (sonst ImagePullBackOff)
+oc create secret docker-registry artifactory-pull -n einfachbahn-dev \
+  --docker-server=einfachbahnlab-docker-stage-local.bahnhub.tech.rz.db.de \
+  --docker-username=DEIN_USER --docker-password=DEIN_API_KEY
+
+# App-Secret (vertrauliche Werte)
+oc create secret generic babedas-api-viewer -n einfachbahn-dev \
+  --from-literal=AUTH_USER=... --from-literal=AUTH_PASS=...
+```
+
+### 3. Deployen
+Manifeste mit Platzhaltern `<NAMESPACE>`, `<REGISTRY>`, `<TAG>` ersetzen und anwenden
+(Reihenfolge: pvc → deployment → service → route):
+```bash
+for m in k8s/pvc.yaml k8s/deployment.yaml k8s/service.yaml k8s/route.yaml; do
+  sed -e "s|<NAMESPACE>|einfachbahn-dev|g" \
+      -e "s|<REGISTRY>|einfachbahnlab-docker-stage-local.bahnhub.tech.rz.db.de|g" \
+      -e "s|<TAG>|0.8.0|g" "$m" | oc apply -f -
+done
+oc rollout status deployment/api-viewer -n einfachbahn-dev
+```
+
+### 4. Betrieb / Diagnose
+```bash
+oc get pods -n einfachbahn-dev -l app=api-viewer
+oc logs -f deployment/api-viewer -n einfachbahn-dev | grep -v "GET /"
+oc exec -it deployment/api-viewer -n einfachbahn-dev -- sh
+oc set env deployment/api-viewer -n einfachbahn-dev FETCH_ON_START=true
+oc delete pod -l app=api-viewer -n einfachbahn-dev   # Neustart nach Secret-Änderung
+```
+
+## OpenShift-Besonderheiten (wichtig)
+- **Non-root**: Container laufen mit zufälliger UID. Schreib-Verzeichnisse weltbeschreibbar machen (`chmod 777 /app/data`), unter `/app` statt `/`.
+- **`restricted` SCC**: `privileged: false`, `runAsNonRoot: true`. Kein Docker-in-Docker.
+- **Kein Internet**: Images nur aus Artifactory-Mirror (`docker-hub-remote.bahnhub.tech.rz.db.de`).
+- **`Route` statt `Ingress`** für externen HTTPS-Zugang.
+
+## Troubleshooting
+
+### Pod: `ImagePullBackOff`
+Image-Pull-Secret `artifactory-pull` fehlt/falsch, oder Image-Tag existiert nicht. Secret neu anlegen, Tag prüfen.
+
+### Pod: `CreateContainerConfigError`
+App-Secret fehlt oder ein referenzierter Key existiert nicht.
+
+### `exec format error` / sofortiger Crash
+Falsche Architektur — mit `--platform linux/amd64` neu bauen.
+
+### `docker push` → `unauthorized` / `denied`
+Nicht eingeloggt (`docker login`) oder kein Push-Recht/Repo fehlt (Self-Service prüfen).
+
+### 502 Bad Gateway
+Pod noch nicht `ready` — Logs prüfen, warten.
+
+### Daten weg nach Redeploy
+PVC prüfen: `oc get pvc -n einfachbahn-dev` (sollte erhalten bleiben).
+
+## Best Practices
+- Feste, semantische Tags (`0.8.0`), kein `latest` für Deployments → nachvollziehbare Rollbacks.
+- Health-Checks (`livenessProbe`/`readinessProbe` auf `/health`) im Deployment.
+- Keine Secrets im Image oder Git — immer als OpenShift-Secret.
+- PVC niemals beim Aufräumen mitlöschen, wenn Daten erhalten bleiben sollen.
+
+## Weiterführend
+Vollständige Doku, Scripts (`build-and-push.sh`, `deploy.sh`, `create-secret.sh`) und
+k8s-Manifest-Templates im Repo `einfachbahn-lab/doku/deployment-doku` (`docs/01`–`docs/07`,
+`scripts/`, `k8s/`).
@@ -0,0 +1,133 @@
+---
+name: "db-pipeship-onboarding"
+displayName: "DB pipeship Onboarding"
+description: "Schritt-für-Schritt-Anleitung, um ein GitLab-Repo im DB-Konzern mit pipeship aufzusetzen: Group- und Project-Onboarding, deploy_k8s_generic nach OpenShift/DBCS, CI/CD-Secrets (SOPS/age), Trivy-Container-Security, Container-Annotations und Renovate-Updates."
+keywords: ["pipeship", "gitlab ci", "deploy_k8s_generic", "cdaas", "renovate", "sops age", "trivy", "dbcs onboarding", "cloud native buildpacks"]
+author: "einfachbahn-lab"
+---
+
+# DB pipeship Onboarding
+
+## Overview
+
+Diese Power führt durch das Aufsetzen eines **Code-Repos** mit **pipeship**
+(Pipeline-as-a-Service der DB Systel): vom Group-/Project-Onboarding über das
+pipeship-Produkt `deploy_k8s_generic` (Build → Test → Deploy nach OpenShift/DBCS)
+bis zu CI/CD-Secrets, Container-Security (Trivy) und automatischen Updates via Renovate.
+Ergebnis ist eine vollautomatische, **compliance-konforme** CI/CD-Pipeline.
+
+Für das Hintergrundwissen zum Ökosystem siehe die Power **DB DXP Platform Guide**.
+Für `scm-info.yaml`-Details die Power **DB scm-info & Compliance**.
+
+## Onboarding (Voraussetzungen)
+- Zugriff auf GitLab (`git.tech.rz.db.de`), Artifactory (`bahnhub`), Cloud-/K8s-Provider
+- **DXP Mandant** (Digitalshop), GitLab-Gruppe via **GroupTrust** verbunden, GitOps-Repo (`tenant-information`)
+- **pipeship CLI**: `brew tap dbsystel/pipeship https://git.tech.rz.db.de/pipeship/toolbox/homebrew.git && brew install pipeship-cli`
+- Zusätzlich `kubectl`, `oc`, `sops`, `age` → prüfen mit `pipeship dependency`
+
+> Schnellster Weg: Im Developer Portal das Software-Template **„DBCS project with CDaaS agent"**
+> (`dbcs-with-cdaas`) bzw. ein kombiniertes Template, das Repo + Pipeline + Namespace + Runner erzeugt.
+
+## Prinzipien von pipeship
+- **Reference instead of copy**: Pipelines per GitLab `include` einbinden (kein Copy&Paste).
+- **Update at your own pace**: Updates kommen als Merge Requests (Renovate).
+- **Convention over Configuration**: Standard-Pipeline pro Use-Case, anpassbar.
+- Baut auf GitLab Auto DevOps + Buildpacks auf.
+
+## Onboarding-Fluss
+
+```
+GROUP-ONBOARDING (einmal pro Top-Level-GitLab-Gruppe)
+  Artifactory-Registries (BASS) · CDaaS-Runner · (SonarQube) · CI/CD-Secrets → "pipeship it!"
+PROJECT-ONBOARDING (pro Repo)
+  Compliance herstellen · Include injizieren · Renovate einrichten
+```
+
+## Common Workflows
+
+### 1. Basis-Compliance herstellen
+- `scm-info.yaml` (Endung **`.yaml`**, schema-valide, Beam-ID), `README.md`, `LICENSE` → Template `init-app-general`
+- Default-Branch schützen: `Settings ➞ Repository ➞ Protected Branches`
+- Tags per Wildcard `*.*` schützen (Format `major.minor`, z. B. `1.2`)
+
+### 2. K8s-Namespace + CDaaS-Runner (GitOps)
+Template `dbcs-with-cdaas` → MR ins `tenant-information`-Repo. Mit `pipeshipSupport: true`
+werden alle nötigen Secrets automatisch im Namespace angelegt:
+```yaml
+apiVersion: kas.dp.db.de/v1alpha1
+kind: Project
+metadata:
+  name: myapp-prod
+  namespace: p-<tenant>-tenant
+spec:
+  cluster: riga            # prag für prod
+  environment: prod
+  pipeshipSupport: true
+  customDockerRepos:        # OpenShift kennt keine Wildcards
+    - "myteam-docker-release-local.bahnhub.tech.rz.db.de"
+```
+
+### 3. CI/CD-Secrets verschlüsseln (falls nötig)
+Secrets **nie im Klartext** in GitLab (ADR-18). age-/PGP-Keys liegen im Namespace (K8s) bzw. KMS (AWS).
+Lokal mit **SOPS + age** verschlüsseln, verschlüsselt committen — pipeship entschlüsselt zur Laufzeit
+und exportiert als Umgebungsvariablen. (Beim CDaaS Shared Agent stattdessen `secrets.yaml` mit GPG-`PGP MESSAGE` und Tag `cdaas-shared-agent`.)
+
+### 4. pipeship-Pipeline injizieren
+Template **pipeship Pipeline Onboarding** → Vendor `pipeship`, Produkt **`deploy_k8s_generic`**,
+Release-Channel (z. B. `resolved/release` oder `baserunner/release`), Zielprojekt → MR mergen.
+Ergebnis `.gitlab-ci.yml`:
+```yaml
+---
+include:
+  - https://bahnhub.tech.rz.db.de/artifactory/pipeship-generic-release-local/release/products/deploy_k8s_generic/<version>.yaml
+variables:
+  DK8G_K8S_TAG: "kubernetes"
+  DK8S_HELM_REMOTE_VALUES: |
+    https://bahnhub.tech.rz.db.de/artifactory/pipeship-generic-release-local/values-library/1.1.119/tmp-volume.yaml
+run_unit_tests:
+  image: <image-mit-test-framework>
+  script:
+    - <test-script>
+```
+**Build-Verhalten:** Dockerfile vorhanden → wird genutzt; kein Dockerfile → **Cloud Native Buildpacks** (ADR-23).
+Image wird in Artifactory promoted und in die K8s-Stages deployt.
+
+### 5. Container-Security & Compliance
+- **pipeship-Images** werden vom pipeship-Team per **Trivy/AquaSec** gescannt → du bist compliant, **solange du aktuell hältst** (≤ 14 Tage, Renovate).
+- **Eigene/überschriebene Images** → Risikobewertung liegt bei dir (selbst scannen/Restrisikodeklaration).
+- **SBOM**: Job `generate_image_sbom_syft`; Compliance Suite scannt Dependencies/Lizenzen.
+- **read-only securityContext** per Default (Schreibpfade als Volume mounten).
+- **Annotations** (Beam-ID, Contacts) automatisch aus `scm-info.yaml` (`GA_REFERENCE_ID`, `GA_CONTACT`).
+
+### 6. Updates aktivieren (Renovate)
+Template **pipeship Renovate Starter** + Preset:
+```json
+{ "extends": ["local>renovate/renovate-presets:pipeship", "local>renovate/renovate-presets:pipeship-group"] }
+```
+Release-Channels (über Include-URL bestimmt): `canary`, `release`, `resolved/...`, `baserunner/...`.
+
+## Definition of Done (Code-Repo)
+- [ ] `scm-info.yaml` (.yaml, valide, Beam-ID), `README.md`, `LICENSE`
+- [ ] Default-Branch + Tags (`*.*`) protected
+- [ ] DXP Mandant + GitLab-Gruppe (GroupTrust) + GitOps-Repo
+- [ ] Artifactory-Registries (Naming-Konvention), CDaaS-Runner
+- [ ] DBCS-Namespace mit `pipeshipSupport: true`
+- [ ] `.gitlab-ci.yml` mit `deploy_k8s_generic` + Unit-Test-Job
+- [ ] CI/CD-Secrets verschlüsselt (age/SOPS/KMS), nichts im Klartext
+- [ ] read-only securityContext + Container-Annotations
+- [ ] SBOM-Job aktiv, Findings geprüft
+- [ ] Renovate-Preset aktiv
+
+## Available Steering Files
+- **repo-typen** – Setup-Matrix für Code / Doku / Architektur / Konzept-Repos (welche Bausteine wann nötig sind, inkl. `deploy_pages_generic` für Doku/Architektur).
+
+## Troubleshooting
+- **Pipeline triggert nicht** → Tag matcht nicht das geschützte Wildcard (`*.*`, Format `major.minor`).
+- **Include nicht auflösbar** → Registry-Naming/Anonymous-Scope prüfen; Channel-URL korrekt?
+- **`pipeship dependency` schlägt fehl** → `sops`/`age`/`kubectl`/`oc` nachinstallieren.
+- **Secret im Pipeline-Log sichtbar** → entschlüsselte env-Vars nie ungefiltert ausgeben.
+- **Renovate erkennt Updates nicht** → pipeship-Preset (Regex-Manager) fehlt.
+
+## Weiterführend
+Vollständiger Praxis-Guide im Repo `einfachbahn-lab/doku/deployment-doku`, Datei
+`docs/09-pipeship-setup-guide.md` (Teil A–D).
@@ -0,0 +1,64 @@
+# Repo-Typen — Setup-Matrix (Code / Doku / Architektur / Konzept)
+
+Die **Basis-Compliance** gilt laut DB-Vorgabe für **alle** Repo-Typen. Pipeline-/
+Runtime-Bausteine kommen je nach Typ hinzu. Diese Typisierung ist eine Empfehlung;
+die DB-Doku kennt formal nur „Code-Repos" (mit Pipeline) und „Doku-/Pages-Repos".
+
+## Pflicht-Basis für JEDES Repo
+Prüft die Compliance Suite unabhängig vom Typ:
+- `scm-info.yaml` (`.yaml`, schema-valide) → Template `init-app-general`
+- `README.md`, `LICENSE`
+- Protected default branch (repräsentiert prod)
+- Korrekte Sichtbarkeit (visibility) gemäß Schutzbedarf
+- Secret-Scan (Betterleaks) — keine Klartext-Secrets
+- Dependency-/Lizenz-Scan (Syft+Grype / Grant), SBOM
+
+## Vergleichsmatrix
+
+| Baustein | Code | Doku | Architektur | Konzept |
+|----------|:---:|:---:|:---:|:---:|
+| scm-info / README / LICENSE | ✅ | ✅ | ✅ | ✅ |
+| Protected branch + tags (`*.*`) | ✅ | ✅ (branch) | ✅ (branch) | ✅ (branch) |
+| Compliance-Suite-Scans | ✅ | ✅ | ✅ | ✅ |
+| pipeship-Pipeline | ✅ `deploy_k8s_generic`/`release_oci_image` | ✅ `deploy_pages_generic` | ➖/✅ wenn publiziert | ➖ |
+| CDaaS Runner | ✅ eigener/Base | ✅ `cdaas-shared-agent` | ✅ shared | ➖ |
+| Kubernetes-Namespace (DBCS) | ✅ | ➖ | ➖ | ➖ |
+| Container-Build + Trivy/AquaSec | ✅ | ➖ | ➖ | ➖ |
+| CI/CD-Secrets (age/SOPS/KMS) | ✅ falls nötig | ➖ | ➖ | ➖ |
+| Container-Annotations + read-only ctx | ✅ | ➖ | ➖ | ➖ |
+| SonarQube (optional) | ✅ | ➖ | ➖ | ➖ |
+| Renovate | ✅ | ✅ | ✅ | ➖ |
+| Linkchecker | ➖ | ✅ | ✅ | ➖ |
+
+Legende: ✅ empfohlen/nötig · ➖ i. d. R. nicht nötig
+
+## Pro Typ konkret
+
+### Code-Repo (Anwendung/Service)
+Vollständige CI/CD bis Prod, K8s, Container-Security. → vollständige Anleitung im POWER.md
+(`deploy_k8s_generic`, K8s-Namespace, CI/CD-Secrets, Trivy, Annotations, Renovate, optional SonarQube).
+
+### Doku-Repo (docs-as-code)
+Markdown/Static-Site auf GitLab Pages: Produkt **`deploy_pages_generic`** mit eigenem
+`build_website`-Job (Hugo/MkDocs/Docusaurus), Tag `cdaas-shared-agent`, **Linkchecker** inklusive,
+Renovate. **Kein** K8s/Container/Trivy/Secrets.
+```yaml
+build_website:
+  image: docker-hub-remote.bahnhub.tech.rz.db.de/monachus/hugo@sha256:...
+  variables:
+    HUGO_BASEURL: "${BW_ENV_URL}"
+  script:
+    - hugo   # Output muss unter ${BW_OUTPUT_DIR} (Default public) liegen
+```
+
+### Architektur-Repo (ADRs, arc42, C4, Diagrams-as-Code)
+Basis-Compliance + Inhalte (Markdown/PlantUML/Mermaid/Structurizr). Wenn publiziert → wie Doku-Repo
+via `deploy_pages_generic`. Sonst reicht Basis-Compliance + Markdown-Lint. Kein Container/K8s/Trivy.
+
+### Konzept-Repo (Fachkonzepte, Specs)
+Nur Basis-Compliance (meist alles). Optional `deploy_pages_generic`. `confidentiality` in scm-info
+ggf. höher setzen und Repo-Sichtbarkeit anpassen (Konzepte oft vertraulicher).
+
+## Minimaler Init-Vergleich
+- **Doku/Architektur (publiziert):** Basis-Compliance + `.gitlab-ci.yml` mit `deploy_pages_generic` + Renovate. Kein K8s/Secrets/Trivy.
+- **Konzept (nicht publiziert):** nur Basis-Compliance. Optional `deploy_pages_generic`.
@@ -0,0 +1,106 @@
+---
+name: "db-scm-info-compliance"
+displayName: "DB scm-info and Compliance"
+description: "Erstellt und validiert die scm-info.yaml für DB-GitLab-Repos und erklärt die Checks der DXP Compliance Suite (Secrets, Dependencies, Lizenzen, DB Compliance). Liefert eine Compliance-Checkliste, damit ein Repo konform zur DB-Vorgabe Source-Control-Management ist."
+keywords: ["scm-info.yaml", "compliance suite", "betterleaks", "beam id", "dbisl lizenz", "sbom", "syft grype", "source control management", "vmp export"]
+author: "einfachbahn-lab"
+---
+
+# DB scm-info and Compliance
+
+## Overview
+
+Diese Power hilft, ein DB-GitLab-Repo **compliant** zu machen: die Pflichtdatei
+`scm-info.yaml` korrekt zu erstellen/validieren und die Checks der **DXP Compliance Suite**
+(Secrets, Dependencies, Lizenzen, DB Compliance) zu verstehen und zu bestehen. Grundlage ist
+die DB-Vorgabe „Source-Control- und Software-Repositories".
+
+## scm-info.yaml — harte Regeln
+- **Dateiendung muss `.yaml` sein** — `.yml` wird **nicht** akzeptiert.
+- Liegt im **Repo-Root**.
+- Wird gegen das **scm-info JSON Schema** validiert (`git.tech.rz.db.de/db-inner-source/scm-info-json-schema`).
+- Am einfachsten per Developer-Portal-Template **`init-app-general`** erzeugen (legt scm-info.yaml + README + LICENSE an).
+
+## Vorlagen
+
+### Minimal
+```yaml
+version: v3
+license: LicenseRef-DBISL
+contacts: DEINE_EMAIL_ADRESSE
+confidentiality: internal
+reference-ids: none
+```
+
+### Erweitert (pipeship-Kontext)
+```yaml
+---
+version: v3
+license: DBISL
+contacts: team@deutschebahn.com
+confidentiality: internal
+reference-ids: A-123456          # eure echte Beam-ID
+custom:
+    production-branch: main
+    integrity: normal
+    availability: normal
+    confidentiality: normal
+    it-service-id: itaps-service-id-1
+```
+
+## Felder
+| Feld | Zweck |
+|------|-------|
+| `version` | Schema-Version (z. B. `v3`) |
+| `license` | Lizenz (`DBISL`/`LicenseRef-DBISL`), geprüft gegen Open-Source-Lizenzkompass |
+| `contacts` | Kontakt(e) — von pipeship als Container-Annotation `GA_CONTACT` genutzt |
+| `confidentiality` | Vertraulichkeitsstufe (z. B. `internal`) |
+| `reference-ids` | **Beam-/Referenz-ID** (Pflicht) — pipeship-Annotation `GA_REFERENCE_ID` |
+| `custom.production-branch` | Produktions-Branch (z. B. `main`) |
+| `custom.integrity/availability/confidentiality` | Schutzbedarf |
+| `custom.it-service-id` | ITAPS-Service-ID |
+
+## Warum sie wichtig ist
+- Verknüpfung mit **Beam/LeanIX** (Anwendungskontext)
+- Bessere Erreichbarkeit über Kontaktdaten
+- **VMP-Export** von Security-Findings nur mit gültiger **Beam ID** möglich
+- Compliance-Pflicht — fehlt sie, entstehen Findings
+- pipeship liefert daraus automatisch die Container-Annotations
+
+## Compliance Suite — die Scanner
+| Scanner | Prüft |
+|---------|-------|
+| **Secrets (Betterleaks)** | Passwörter/API-Keys in Code, Job-Logs, Artefakten |
+| **Dependencies (Syft + Grype)** | Syft erstellt SBOM, Grype scannt auf bekannte Schwachstellen |
+| **DB Compliance** | Sichtbarkeit, protected Branches, Existenz README/LICENSE/scm-info.yaml + Schema-Validierung |
+| **Licenses (Grant)** | Lizenzkonformität gemäß DB Open-Source-Lizenzkompass |
+
+- Wöchentliche Scans (Di/Do/Sa 18:00), Dependency-Checks alle 12 h, SBOM je Scan.
+- Findings im Developer Portal: https://dp.dxc.comp.db.de/compliance/repositories
+- Sichtbarkeit: GitLab-Rolle ≥ `Developer`. Kein DXP Mandant nötig, nur um Findings zu sehen.
+
+## Compliance-Checkliste (vor erstem Release)
+- [ ] `scm-info.yaml` vorhanden, Endung `.yaml`, schema-valide
+- [ ] `reference-ids` = echte Beam-ID gesetzt
+- [ ] `license` korrekt (DBISL o. zulässige Open-Source-Lizenz)
+- [ ] `contacts` gesetzt (Erreichbarkeit + Container-Annotation)
+- [ ] `README.md` und `LICENSE` vorhanden
+- [ ] Default-Branch protected; Sichtbarkeit gemäß Schutzbedarf
+- [ ] keine Klartext-Secrets im Repo/Logs/Artefakten (Betterleaks grün)
+- [ ] Dependency-/Lizenz-Findings gesichtet und behandelt
+- [ ] (Container) SBOM-Job aktiv, Images aktuell gehalten (≤ 14 Tage / Renovate)
+
+## Best Practices
+- `confidentiality` und Repo-Sichtbarkeit am tatsächlichen Schutzbedarf ausrichten.
+- Beam-ID früh setzen — ohne sie kein VMP-Export der Findings.
+- Secrets nie im Klartext; verschlüsselt mit SOPS/age committen.
+- Findings nicht ignorieren — patchen/mitigieren oder Restrisiko dokumentieren.
+
+## Troubleshooting
+- **Finding „scm-info invalid"** → Endung `.yaml`? Pflichtfelder (`version`, `reference-ids`) gesetzt? Gegen Schema prüfen.
+- **VMP-Export geht nicht** → gültige Beam-ID in `reference-ids` fehlt.
+- **Secret-Finding trotz Verschlüsselung** → false positive dokumentieren oder Wert wirklich entfernen/rotieren.
+
+## Weiterführend
+Repo `einfachbahn-lab/doku/deployment-doku`: `docs/09-pipeship-setup-guide.md` (Teil B) und
+`docs/08-dxp-plattform.md` (Kap. 4, Compliance Suite).