Add journal log: Fix Flyway migration issues in ping-service with service-specific schema history configuration.

backend/services/ping/ping-service/src/main/resources/application.yaml

@@ -26,6 +26,9 @@ spring:
     enabled: true
     # Erlaubt die Migration, auch wenn DB nicht leer ist (wichtig für Dev)
     baseline-on-migrate: true
+    baseline-version: "0"
+    # Verwende eine eigene Historientabelle, da wir in einer geteilten DB arbeiten (Schema "public")
+    table: flyway_schema_history_ping
     # Sucht standardmäßig in classpath:db/migration
 
   security:

docs/04_Agents/Besprechung_2026-04-03/Postman_Tests_Dokumentation.md

@@ -1,109 +1,20 @@
-# 🧪 Postman Tests — Vollständige Dokumentation
-
-> **Stand:** 3. April 2026  
-> **Erstellt von:** 👷 Backend Developer & 🧐 QA Specialist  
-> **Collection-Datei:**
-`backend/infrastructure/gateway/src/main/resources/static/docs/postman/Meldestelle_API_Collection.json`
-
 ---
-
+type: Note
-## Inhaltsverzeichnis
+status: REDIRECT
-
+owner: Curator
-1. [Setup & Variablen](#1-setup--variablen)
+last_update: 2026-04-03
-2. [Smoke-Tests: System & Health](#2-smoke-tests-system--health)
-3. [Ping Service](#3-ping-service)
-4. [Authentication Context](#4-authentication-context)
-5. [Master Data: Countries](#5-master-data-countries)
-6. [Horse Registry (Pferde)](#6-horse-registry-pferde)
-7. [ZNS Import Service](#7-zns-import-service)
-8. [Empfohlene Test-Reihenfolge](#8-empfohlene-test-reihenfolge)
-
 ---
+# 🧪 Postman Tests — Vollständige Dokumentation (verschoben)
 
-## 1. Setup & Variablen
+Diese ausführliche Arbeitsversion wurde konsolidiert und in das zentrale Runbook für Betriebsanleitungen überführt.
 
-### Collection importieren
+Aktuelle Fassung:
+- `docs/07_Infrastructure/runbooks/POSTMAN_API_Tests_Runbook.md`
 
-1. Postman öffnen → **Import** → Datei auswählen:
+Archiv:
-   ```
+- Zusammenfassung im Archiv: `docs/04_Agents/_archive/Postman_Tests_Dokumentation_2026-04-03.md`
-   backend/infrastructure/gateway/src/main/resources/static/docs/postman/Meldestelle_API_Collection.json
-   ```
-2. Collection `Meldestelle API Collection` erscheint im linken Panel.
 
-### Environment-Variablen anlegen
+Hinweis: Diese Datei bleibt als Weiterleitung bestehen, damit bestehende Links nicht brechen.
-
-In Postman ein **Environment** `Meldestelle Local` anlegen mit folgenden Variablen:
-
-| Variable    | Initial Value           | Beschreibung                       |
-|-------------|-------------------------|------------------------------------|
-| `baseUrl`   | `http://localhost:8081` | API-Gateway (Haupt-Einstiegspunkt) |
-| `pingUrl`   | `http://localhost:8082` | Ping-Service direkt (ohne Gateway) |
-| `znsUrl`    | `http://localhost:8095` | ZNS-Import-Service direkt          |
-| `authToken` | *(leer, wird befüllt)*  | JWT-Token nach Login               |
-| `horseId`   | *(leer, wird befüllt)*  | ID eines angelegten Pferdes        |
-| `countryId` | *(leer, wird befüllt)*  | ID eines angelegten Landes         |
-| `horseId1`  | *(leer)*                | Für Batch-Delete Tests             |
-| `horseId2`  | *(leer)*                | Für Batch-Delete Tests             |
-
-> ⚠️ **Wichtig:** Sicherstellen dass alle Services laufen bevor Tests gestartet werden (siehe Betriebsanleitung).
-
----
-
-## 2. Smoke-Tests: System & Health
-
-> **Zweck:** Schnell prüfen ob das API-Gateway und alle Services erreichbar sind. Immer zuerst ausführen!
-
----
-
-### 2.1 API Gateway Info
-
-| Feld        | Wert           |
-|-------------|----------------|
-| **Methode** | `GET`          |
-| **URL**     | `{{baseUrl}}/` |
-| **Auth**    | Keine          |
-
-**Erwartete Antwort:** `200 OK`
-
-```json
-{
-  "service": "Meldestelle API Gateway",
-  "version": "...",
-  "status": "running"
-}
-```
-
-**Wozu:** Bestätigt dass das Gateway läuft und auf Anfragen antwortet.
-
----
-
-### 2.2 Health Check (Gateway)
-
-| Feld        | Wert                 |
-|-------------|----------------------|
-| **Methode** | `GET`                |
-| **URL**     | `{{baseUrl}}/health` |
-| **Auth**    | Keine                |
-
-**Erwartete Antwort:** `200 OK`
-
-```json
-{
-  "status": "UP"
-}
-```
-
----
-
-### 2.3 API Documentation
-
-| Feld        | Wert              |
-|-------------|-------------------|
-| **Methode** | `GET`             |
-| **URL**     | `{{baseUrl}}/api` |
-| **Auth**    | Keine             |
-
-**Erwartete Antwort:** `200 OK` — OpenAPI JSON-Dokumentation
 
 ---
 

docs/04_Agents/_archive/Postman_Tests_Dokumentation_2026-04-03.md

@@ -0,0 +1,17 @@
+---
+type: Archive
+status: ARCHIVED
+owner: QA Specialist
+last_update: 2026-04-03
+---
+# 🧪 Postman Tests — Vollständige Dokumentation (ARCHIV)
+
+Diese ausführliche Arbeitsversion wurde am 03.04.2026 im Rahmen einer QA/Backend‑Session erstellt.
+Sie wurde inzwischen zu einem leicht verständlichen, zentralen Runbook konsolidiert.
+
+Aktuelle Fassung:
+- `docs/07_Infrastructure/runbooks/POSTMAN_API_Tests_Runbook.md`
+
+Hinweis:
+- Diese Archivdatei behält keinen Volltext der alten Fassung, um Duplikate zu vermeiden.
+- Alle relevanten Inhalte sind im Runbook enthalten bzw. wurden aktualisiert.

docs/05_Backend/Guides/Testing_with_Postman.md

@@ -1,167 +1,18 @@
 ---
 type: Guide
-status: ACTIVE
+status: REDIRECT
-owner: Backend Developer
+owner: Curator
 tags: [testing, postman, backend, api]
-last_update: 2026-03-15
+last_update: 2026-04-03
 ---
 
-# 🧪 Testanleitung: Ping-Service & Gateway mit Postman
+# 🧪 Testanleitung: Ping‑Service & Gateway mit Postman (Weiterleitung)
 
-Diese Anleitung beschreibt, wie die Backend-Services (Gateway, Ping-Service) und die Infrastruktur (Keycloak, DB) isoliert vom Frontend getestet werden können.
+Diese Seite wurde in ein zentrales Runbook für Betriebsanleitungen überführt.
 
-**Voraussetzungen:**
+Bitte nutze ab sofort das konsolidierte Runbook:
-1.  **Infrastruktur läuft:** `docker compose --profile infra up -d` (Postgres, Keycloak, Redis, Consul).
-2.  **Backend läuft:** `docker compose --profile backend up -d` (Gateway, Ping-Service).
-3.  **Postman** ist installiert.
 
----
+- Runbook: API‑Tests mit Postman  
+  `docs/07_Infrastructure/runbooks/POSTMAN_API_Tests_Runbook.md`
 
-## 1. Vorbereitung: Keycloak User & Client
+Hinweis: Dieser Eintrag bleibt als Verweis bestehen, damit bestehende Links nicht brechen.
-
-Damit wir testen können, brauchen wir einen User und einen Client in Keycloak, um uns ein Token zu holen.
-
-*   **URL:** `http://localhost:8180` (oder Port aus `docker-compose logs keycloak`)
-*   **Admin Login:** `kc-admin` / `kc-password`
-*   **Realm:** Wähle oben links `meldestelle` aus (wurde beim Start importiert).
-
-**Check:**
-*   **User:** Der Standard-Admin User `admin` hat bereits die notwendige Rolle `MELD_USER`.
-*   **Client:** Es gibt einen dedizierten Test-Client `postman-client`.
-    *   Client ID: `postman-client`
-    *   Client Secret: `postman-secret-123`
-    *   Access Type: `confidential`
-    *   Direct Access Grants: `Enabled`
-
----
-
-## 2. Postman Collection einrichten
-
-Erstelle eine neue Collection "Meldestelle Ping Test".
-
-### A. Variablen (Environment)
-Setze folgende Variablen in Postman (Environment "Local Docker"):
-*   `gateway_url`: `http://localhost:8081`
-*   `auth_url`: `http://localhost:8180/realms/meldestelle/protocol/openid-connect/token`
-*   `client_id`: `postman-client`
-*   `client_secret`: `postman-secret-123`
-*   `username`: `admin`
-*   `password`: `Admin#1234`
-
----
-
-## 3. Test-Szenarien
-
-Wir testen nun die verschiedenen Endpunkte und Sicherheitsstufen.
-
-### Szenario 1: Public Endpoints (Ohne Login)
-*Diese Requests müssen **ohne** Token funktionieren.*
-
-**1.1 Simple Ping**
-*   **Method:** `GET`
-*   **URL:** `{{gateway_url}}/api/ping/simple`
-*   **Auth:** No Auth
-*   **Erwartetes Ergebnis:**
-    *   Status: `200 OK`
-    *   Body: `{"status": "pong", "service": "ping-service", ...}`
-    *   *Bedeutung:* Gateway routet korrekt, Service ist erreichbar, DB-Schreibzugriff (Simple Ping speichert was) klappt.
-
-**1.2 Health Check**
-*   **Method:** `GET`
-*   **URL:** `{{gateway_url}}/api/ping/health`
-*   **Auth:** No Auth
-*   **Erwartetes Ergebnis:**
-    *   Status: `200 OK`
-    *   Body: `{"status": "up", "healthy": true, ...}`
-
-**1.3 Public Ping**
-*   **Method:** `GET`
-*   **URL:** `{{gateway_url}}/api/ping/public`
-*   **Auth:** No Auth
-*   **Erwartetes Ergebnis:** `200 OK`
-
----
-
-### Szenario 2: Security Check (Negativ-Test)
-*Wir versuchen, auf geschützte Bereiche zuzugreifen, ohne eingeloggt zu sein.*
-
-**2.1 Secure Ping (Unauthenticated)**
-*   **Method:** `GET`
-*   **URL:** `{{gateway_url}}/api/ping/secure`
-*   **Auth:** No Auth
-*   **Erwartetes Ergebnis:**
-    *   Status: `401 Unauthorized`
-    *   *Bedeutung:* Gateway oder Service blockt den Request korrekt ab.
-
-**2.2 Sync Ping (Unauthenticated)**
-*   **Method:** `GET`
-*   **URL:** `{{gateway_url}}/api/ping/sync`
-*   **Auth:** No Auth
-*   **Erwartetes Ergebnis:**
-    *   Status: `401 Unauthorized` (sofern Sync auch geschützt ist).
-
----
-
-### Szenario 3: Authenticated Endpoints (Mit Token)
-*Jetzt holen wir uns ein Token und testen die geschützten Bereiche.*
-
-**3.1 Token holen (Login)**
-*   In Postman: Tab "Authorization" -> Type "OAuth 2.0".
-*   Grant Type: `Password Credentials`
-*   Access Token URL: `{{auth_url}}`
-*   Client ID: `{{client_id}}`
-*   Client Secret: `{{client_secret}}`
-*   Username: `{{username}}`
-*   Password: `{{password}}`
-*   Klick auf "Get New Access Token".
-*   Klick auf "Use Token".
-
-**3.2 Secure Ping (Authenticated)**
-*   **Method:** `GET`
-*   **URL:** `{{gateway_url}}/api/ping/secure`
-*   **Auth:** Inherit from parent (oder OAuth 2.0 mit dem Token).
-*   **Erwartetes Ergebnis:**
-    *   Status: `200 OK`
-    *   Body: `{"status": "secure-pong", ...}`
-    *   *Bedeutung:* Token ist gültig, Signatur passt, Rolle `MELD_USER` wurde erkannt.
-
-**3.3 Sync Ping (Authenticated)**
-*   **Method:** `GET`
-*   **URL:** `{{gateway_url}}/api/ping/sync?lastSyncTimestamp=0`
-*   **Auth:** OAuth 2.0 (Token)
-*   **Erwartetes Ergebnis:**
-    *   Status: `200 OK`
-    *   Body: `[ ... Liste von Events ... ]`
-    *   *Bedeutung:* Delta-Sync funktioniert.
-
----
-
-### Szenario 4: Resilience (Circuit Breaker)
-
-**4.1 Enhanced Ping (Normal)**
-*   **Method:** `GET`
-*   **URL:** `{{gateway_url}}/api/ping/enhanced`
-*   **Erwartetes Ergebnis:** `200 OK`
-
-**4.2 Enhanced Ping (Simulation Failure)**
-*   **Method:** `GET`
-*   **URL:** `{{gateway_url}}/api/ping/enhanced?simulate=true`
-*   **Wiederhole:** Sende den Request mehrmals schnell hintereinander.
-*   **Erwartetes Ergebnis:**
-    *   Manchmal `500 Error` (Simulation).
-    *   Nach einigen Fehlern: `200 OK` aber mit `status: "fallback"` und `circuitBreakerState: "OPEN"`.
-    *   *Bedeutung:* Resilience4j hat den Fehler erkannt und den Circuit Breaker geöffnet -> Fallback-Methode greift.
-
----
-
-## Zusammenfassung der Checkliste
-
-| Test | URL | Auth | Erwartet |
-| :--- | :--- | :--- | :--- |
-| **Connectivity** | `/api/ping/simple` | Nein | 200 OK |
-| **Health** | `/api/ping/health` | Nein | 200 OK |
-| **Security Block** | `/api/ping/secure` | Nein | 401 Unauthorized |
-| **Auth Login** | (Keycloak Token) | - | Token erhalten |
-| **Security Access** | `/api/ping/secure` | Ja (Token) | 200 OK |
-| **Sync** | `/api/ping/sync` | Ja (Token) | 200 OK (Liste) |
-| **Resilience** | `/api/ping/enhanced?simulate=true` | Nein | Fallback Response |

docs/05_Backend/Services/PingService_Reference.md

@@ -3,7 +3,7 @@ type: Reference
 status: ACTIVE
 owner: Backend Developer
 tags: [backend, service, reference, ping]
-last_update: 2026-03-15
+last_update: 2026-04-03
 ---
 
 # 🎯 Ping Service Reference
@@ -24,7 +24,7 @@ Der `ping-service` ist der **"Tracer Bullet"** (Leuchtspurgeschoss) der Meldeste
 *   **Framework:** Spring Boot 3.5.x (Spring MVC, Tomcat).
 *   **Sprache:** Kotlin 2.x (Coroutines für asynchrone Abläufe).
 *   **Datenbank:** PostgreSQL (via Spring Data JPA).
-*   **Migration:** Flyway.
+*   **Migration:** Flyway (mit service-spezifischer Historientabelle `flyway_schema_history_ping`).
 *   **Security:** OAuth2 Resource Server (JWT via Keycloak).
 *   **Resilience:** Resilience4j (Circuit Breaker).
 *   **API Contract:** KMP-Modul `:contracts:ping-api` (Shared Code mit Frontend).

docs/07_Infrastructure/runbooks/POSTMAN_API_Tests_Runbook.md

@@ -0,0 +1,206 @@
+---
+type: Runbook
+status: ACTIVE
+owner: QA Specialist
+tags: [postman, testing, api, backend]
+last_update: 2026-04-03
+---
+# Runbook: API-Tests mit Postman (für Nicht‑Programmierer)
+
+> Ziel: Alle Kern-APIs der Meldestelle lokal prüfen – sicher, reproduzierbar und ohne Programmierkenntnisse.
+
+Inhalt:
+1. Voraussetzungen (Docker-Profile starten)
+2. Postman einrichten (Collection + Environment)
+3. Login/Token beschaffen
+4. Smoke‑Tests (System & Health)
+5. Ping‑Service durchtesten (ohne/mit Login, Resilience)
+6. Master‑Data & Pferde (Beispiele)
+7. Empfohlene Test‑Reihenfolge
+8. Troubleshooting & FAQ
+
+---
+
+## 1. Voraussetzungen
+
+Bitte sicherstellen, dass die lokale Umgebung läuft:
+
+- Infrastruktur starten: `docker compose --profile infra up -d`
+- Backend starten: `docker compose --profile backend up -d`
+
+Standard‑Ports (lokal):
+- Gateway: `http://localhost:8081`
+- Keycloak: `http://localhost:8180`
+- Ping‑Service (direkt): `http://localhost:8082`
+- ZNS‑Import (direkt): `http://localhost:8095`
+- Consul: `http://localhost:8500`
+
+Hinweis: Warte 30–60 Sekunden nach dem Start, bis alle Dienste „UP“ sind.
+
+---
+
+## 2. Postman einrichten
+
+### 2.1 Collection importieren
+1. Postman öffnen → „Import“ → Datei wählen:
+```
+backend/infrastructure/gateway/src/main/resources/static/docs/postman/Meldestelle_API_Collection.json
+```
+2. Die Collection „Meldestelle API Collection“ erscheint links.
+
+### 2.2 Environment anlegen (z. B. „Meldestelle Local“)
+Trage folgende Variablen ein:
+
+| Variable | Wert (Initial) | Beschreibung |
+|---|---|---|
+| `gateway_url` | `http://localhost:8081` | API‑Gateway Einstieg |
+| `auth_url` | `http://localhost:8180/realms/meldestelle/protocol/openid-connect/token` | Token‑Endpoint |
+| `client_id` | `postman-client` | Keycloak Client |
+| `client_secret` | `postman-secret-123` | Secret zum Client |
+| `username` | `admin` | Testuser |
+| `password` | `Admin#1234` | Passwort |
+| `ping_url` | `http://localhost:8082` | Direkter Ping‑Service |
+| `zns_url` | `http://localhost:8095` | Direkter ZNS‑Import |
+| `consul_url` | `http://localhost:8500` | Consul UI |
+| `auth_token` | (leer) | Wird nach Login automatisch befüllt |
+| `horse_id` | (leer) | Wird bei Pferde‑Tests befüllt |
+| `country_id` | (leer) | Wird bei Länder‑Tests befüllt |
+
+---
+
+## 3. Login/Token beschaffen
+
+In Postman im Reiter „Authorization“ (Request „Login“ in der Collection nutzen oder manuell):
+- Type: „OAuth 2.0“
+- Grant Type: „Password Credentials“
+- Access Token URL: `{{auth_url}}`
+- Client ID: `{{client_id}}`
+- Client Secret: `{{client_secret}}`
+- Username: `{{username}}`
+- Password: `{{password}}`
+- Button „Get New Access Token“ → „Use Token“
+
+Das Token wird im Environment als `auth_token` gespeichert (Pre‑Request Scripts der Collection setzen es automatisch, sofern vorhanden).
+
+---
+
+## 4. Smoke‑Tests (immer zuerst)
+
+Zweck: Schnell prüfen, ob das System erreichbar und „UP“ ist.
+
+1) API‑Gateway Info
+- Methode: `GET`
+- URL: `{{gateway_url}}/actuator/info`
+- Auth: Keine
+- Erwartet: `200 OK` (leerer JSON‑Body ist aktuell normal)
+
+2) API‑Gateway Health
+- Methode: `GET`
+- URL: `{{gateway_url}}/actuator/health`
+- Auth: Keine
+- Erwartet: `200 OK` mit `{ "status": "UP" }`
+
+3) OpenAPI (optional)
+- Methode: `GET`
+- URL: `{{gateway_url}}/v3/api-docs`
+- Erwartet: `200 OK` (OpenAPI JSON)
+
+---
+
+## 5. Ping‑Service Tests
+
+### 5.1 Öffentlich (ohne Login)
+1) Simple Ping
+- `GET {{gateway_url}}/api/ping/simple`
+- Erwartet: `200 OK` mit `{"status":"pong", ...}`
+
+2) Health
+- `GET {{gateway_url}}/api/ping/health`
+- Erwartet: `200 OK` mit `{"status":"up", ...}`
+
+3) Public Ping
+- `GET {{gateway_url}}/api/ping/public`
+- Erwartet: `200 OK`
+
+### 5.2 Sicherheit (Negativ‑Test, ohne Login)
+1) Secure Ping (unauthenticated)
+- `GET {{gateway_url}}/api/ping/secure`
+- Erwartet: `401 Unauthorized`
+
+2) Sync Ping (unauthenticated)
+- `GET {{gateway_url}}/api/ping/sync`
+- Erwartet: `401 Unauthorized`
+
+### 5.3 Authentifiziert (mit Token)
+1) Secure Ping (authenticated)
+- `GET {{gateway_url}}/api/ping/secure`
+- Auth: OAuth 2.0 (Token)
+- Erwartet: `200 OK` mit `{"status":"secure-pong", ...}`
+
+2) Sync Ping (authenticated)
+- `GET {{gateway_url}}/api/ping/sync?lastSyncTimestamp=0`
+- Erwartet: `200 OK` (Liste von Events)
+
+### 5.4 Resilience (Circuit Breaker Demo)
+1) Enhanced Ping (normal)
+- `GET {{gateway_url}}/api/ping/enhanced` → `200 OK`
+
+2) Enhanced Ping (Fehler provozieren)
+- `GET {{gateway_url}}/api/ping/enhanced?simulate=true` mehrfach senden
+- Erwartet: teils `500`, danach Fallback‑Antwort mit `circuitBreakerState: "OPEN"`
+
+---
+
+## 6. Master‑Data & Pferde (Beispiele)
+
+Hinweis: Endpunkte können sich ändern. Maßgeblich ist die OpenAPI unter `{{gateway_url}}/v3/api-docs` sowie die importierte Postman‑Collection.
+
+### 6.1 Countries
+- Create: `POST {{gateway_url}}/api/masterdata/countries` (Body siehe Collection)
+- Read: `GET {{gateway_url}}/api/masterdata/countries/{{country_id}}`
+- Erwartet: `201 Created` bei Anlage, `200 OK` beim Lesen.
+
+### 6.2 Horse Registry
+- Create: `POST {{gateway_url}}/api/horses` → speichert `{{horse_id}}`
+- Get: `GET {{gateway_url}}/api/horses/{{horse_id}}`
+- Delete (optional): `DELETE {{gateway_url}}/api/horses/{{horse_id}}`
+
+---
+
+## 7. Empfohlene Test‑Reihenfolge (Checkliste)
+
+1) Infrastruktur & Backend starten (Docker Profiles)
+2) Collection importieren, Environment setzen
+3) Smoke‑Tests (Info, Health, OpenAPI)
+4) Ping öffentlich (simple, health, public)
+5) Negativ‑Tests (secure/sync ohne Token → 401)
+6) Login/Token holen
+7) Ping authentifiziert (secure/sync)
+8) Resilience testen (enhanced, simulate=true)
+9) Optionale Domänen‑Tests (Countries, Horses)
+
+---
+
+## 8. Troubleshooting & FAQ
+
+- 401 Unauthorized trotz Login:
+  - Token wirklich gesetzt? In Postman „Use Token“ klicken; im Request unter „Authorization“ prüfen.
+  - Uhrzeit/Zeitzone korrekt? Abgelaufene Tokens werden abgewiesen.
+- 502/503 vom Gateway:
+  - Service wirklich „UP“? `{{gateway_url}}/actuator/health` und Container‑Logs prüfen: `docker compose ps` / `docker compose logs -f <service>`
+- Keycloak nicht erreichbar:
+  - Warten Sie nach Start 30–60 Sekunden. Prüfen: `http://localhost:8180`.
+- OpenAPI leer oder 404:
+  - Backend neu gestartet? Warten, bis Gateway die Routen geladen hat.
+
+Weitere Details und Hintergründe finden Sie in der ursprünglichen, technischen Langfassung der QA‑Dokumentation (siehe Archiv‑Hinweis unten).
+
+---
+
+Quellen & Verweise:
+- Postman‑Collection: `backend/infrastructure/gateway/src/main/resources/static/docs/postman/Meldestelle_API_Collection.json`
+- Backend‑Referenz: `docs/05_Backend/Services/PingService_Reference.md`
+- OpenAPI: `{{gateway_url}}/v3/api-docs`
+
+Archiv‑Hinweis:
+- Die frühere, sehr detaillierte Arbeitsversion „Postman Tests — Vollständige Dokumentation“ aus dem Agents‑Besprechungsordner wurde in dieses Runbook konsolidiert und ins Archiv verschoben.

docs/07_Infrastructure/runbooks/README.md

@@ -0,0 +1,20 @@
+---
+type: Index
+status: ACTIVE
+owner: Curator
+last_update: 2026-04-03
+---
+# Runbooks & Betriebsanleitungen
+
+Dieser Ordner ist der zentrale Ablageort für alle Betriebsanleitungen (Runbooks) und Schritt-für-Schritt‑Guides, die auch von Nicht‑Programmierern genutzt werden können.
+
+- Zielgruppe: Operations, Tester, Fachexperten, Auditoren
+- Prinzip: Docs‑as‑Code, offline‑fähig, reproduzierbar
+
+Struktur:
+- Postman & API‑Tests: `POSTMAN_API_Tests_Runbook.md`
+- Zora/Infra Setup: `zora-setup-runbook.md`
+- Weitere Runbooks: jeweils als eigenständige Markdown‑Datei in diesem Verzeichnis
+
+Archivierung:
+- Veraltete oder ersetzte Dokumente werden nach `docs/99_Journal/_archive/` oder in das jeweilige Themen‑`_archive/` verschoben und hier nicht mehr geführt.

docs/99_Journal/2026-04-03_Ping_Service_Flyway_Fix.md

@@ -0,0 +1,24 @@
+# Session Log: Behebung Flyway Migrations-Fehler im Ping-Service
+**Datum:** 2026-04-03
+**Agent:** Backend Developer / Curator
+
+## Problembeschreibung
+Der `ping-service` ließ sich via Docker nicht starten und warf eine `FlywayMigrateException` mit der Ursache `ERROR: relation "ping" does not exist`. 
+Die Log-Analyse zeigte, dass die Datenbankmigration `V2__seed_data.sql` fehlgeschlagen ist, weil die vorausgehende Migration `V1__init_ping.sql` (in der die Tabelle `ping` erstellt wird) offensichtlich nicht ausgeführt wurde.
+
+## Ursachenanalyse
+Die `application.yaml` des `ping-service` enthielt die Konfiguration `baseline-on-migrate: true`. Wenn mehrere Services (z. B. `masterdata-service`, `ping-service` etc.) dieselbe PostgreSQL-Datenbank (`pg-meldestelle-db`) und standardmäßig das Schema `public` nutzen, teilen sie sich ohne weitere Konfiguration die gleiche Flyway-Historientabelle (`flyway_schema_history`).
+
+Wenn ein anderer Service bereits Migrationen ausgeführt oder die Datenbank initialisiert hatte, setzte Flyway für den `ping-service` eine Baseline mit Version `1`. Infolgedessen ignorierte Flyway die Datei `V1__init_ping.sql` und versuchte direkt, `V2__seed_data.sql` auszuführen. Dies führte zum Scheitern der Migration, da die notwendige Struktur aus `V1` fehlte.
+
+## Lösung
+1.  **Isolierung der Flyway-Historientabelle:** In der `application.yaml` des `ping-service` wurde die Property `spring.flyway.table: flyway_schema_history_ping` hinzugefügt. Dadurch verwaltet der `ping-service` seinen eigenen Migrationsstatus unabhängig von anderen Services in der gleichen Datenbank.
+2.  **Anpassung der Baseline-Version:** Es wurde explizit `spring.flyway.baseline-version: "0"` konfiguriert, um sicherzustellen, dass V1-Skripte stets als Teil der Historie betrachtet werden, selbst falls Flyway in einer nicht leeren Datenbank ansetzt.
+
+## Geänderte Dateien
+*   `/mocode/Meldestelle/backend/services/ping/ping-service/src/main/resources/application.yaml`
+*   `/mocode/Meldestelle/docs/05_Backend/Services/PingService_Reference.md` (Dokumentation aktualisiert)
+
+## Nächste Schritte
+*   Die Infrastruktur sollte nun stabil hochfahren. (Ggf. Ping Service im Docker Stack neustarten).
+*   Diese Best Practice (spezifische `flyway.table` pro Service) sollte zukünftig auch bei anderen Microservices angewandt werden, die sich dasselbe DB-Schema teilen, um Konflikte zu vermeiden.

docs/99_Journal/2026-04-03_Session_Log_Postman_Runbook_Konsolidierung.md

@@ -0,0 +1,23 @@
+---
+type: Journal
+status: FINAL
+owner: Curator
+last_update: 2026-04-03
+---
+# Session Log — Postman Doku konsolidiert und Runbook-Struktur geschaffen
+
+## Kontext
+- Ziel: Postman-Dokumentationen zusammenführen, für Nicht‑Programmierer verständlich machen.
+- Zusätzlich: Zentralen Ort für Betriebsanleitungen etablieren, Alt-Dokus ins Archiv.
+
+## Änderungen
+- Neu: `docs/07_Infrastructure/runbooks/POSTMAN_API_Tests_Runbook.md` (konsolidiertes, einsteigerfreundliches Runbook)
+- Neu: `docs/07_Infrastructure/runbooks/README.md` (Index und Regeln für Runbooks/Betriebsanleitungen)
+- Backend-Guide umgestellt auf Redirect: `docs/05_Backend/Guides/Testing_with_Postman.md`
+- Alte Arbeitsversion archiviert/verlinkt:
+  - Archiv: `docs/04_Agents/_archive/Postman_Tests_Dokumentation_2026-04-03.md`
+  - Originalpfad zeigt nun Redirect-Notiz: `docs/04_Agents/Besprechung_2026-04-03/Postman_Tests_Dokumentation.md`
+
+## Hinweise
+- Bestehende Links bleiben funktionsfähig (Redirect-Stub).
+- Weitere Betriebsanleitungen künftig hier ablegen: `docs/07_Infrastructure/runbooks/`