# Arbeitsauftrag 030 – Herkunft des fehlerhaften Healthchecks von `hermes-kanban-adapter`

**Modus:** Read-only  
**Datum:** 2026-08-12  
**Scope:** Nur Herkunftsanalyse des Healthchecks für `hermes-kanban-adapter`

## 1. Quelle des Healthchecks

### Gefundene Definition

- **Datei:** `/opt/struktur/hermes-ui-auswahl/compose.yaml`
- **Zeile:** 57
- **Exakter Healthcheck:**

```yaml
healthcheck:
  test: ["CMD-SHELL", "node -e \"fetch(http://127.0.0.1:5099/health).then(r=>{if(!r.ok)process.exit(1)})\""]
  interval: 30s
  timeout: 5s
  retries: 5
  start_period: 5s
```

### Zusätzliche Bestätigung

Die referenzierte Backup-Datei enthält an derselben Stelle denselben Healthcheck:

- **Datei:** `/opt/struktur/backups/hermes-ui-auswahl-reset-20260812_135820/compose.yaml`
- **Zeilen:** 24–29
- **Exakter Healthcheck:**

```yaml
healthcheck:
  test: ["CMD-SHELL", "curl -fsS http://127.0.0.1:5099/ >/dev/null"]
  interval: 30s
  timeout: 5s
  retries: 5
  start_period: 30s
```

Wichtig: Diese Backup-Datei gehört zum **Workspace-Service**, nicht zum Kanban-Adapter, und zeigt, dass der Kanban-Adapter-Healthcheck **nicht** aus dem Workspace-Backup stammt, sondern separat in der aktiven Compose-Datei definiert wurde.

---

## 2. Nachweis

### Direktnachweis in der Compose-Datei

`docker compose -f /opt/struktur/hermes-ui-auswahl/compose.yaml config` zeigt den fehlerhaften Healthcheck für `hermes-kanban-adapter` in der aufgelösten Compose-Konfiguration:

```text
27:        - node -e "fetch(http://127.0.0.1:5099/health).then(r=>{if(!r.ok)process.exit(1)})"
```

### Direktnachweis im laufenden Container

`docker inspect hermes-kanban-adapter --format '{{json .Config.Healthcheck}}'` liefert:

```json
{
  "Test":["CMD-SHELL","node -e \"fetch(http://127.0.0.1:5099/health).then(r=>{if(!r.ok)process.exit(1)})\""],
  "Interval":30000000000,
  "Timeout":5000000000,
  "StartPeriod":5000000000,
  "Retries":5
}
```

Das beweist, dass die fehlerhafte Definition aus der laufenden Container-Konfiguration stammt und nicht erst zur Laufzeit im Container erzeugt wurde.

### Gegenprobe gegen das Image

`docker image inspect ghcr.io/outsourc-e/hermes-workspace:latest --format '{{json .Config.Healthcheck}} ...'` zeigt für das Image **einen anderen, korrekten Healthcheck**:

```json
{"Test":["CMD-SHELL","curl -fsS http://127.0.0.1:3000/ >/dev/null || exit 1"],"Interval":30000000000,"Timeout":5000000000,"StartPeriod":20000000000,"Retries":3}
```

Damit ist belegt:
- Das **Image** enthält **nicht** den fehlerhaften Kanban-Healthcheck.
- Der fehlerhafte Healthcheck stammt aus der **lokalen Compose-Konfiguration**.

---

## 3. Verantwortliche Datei

**Verantwortliche Datei:** `/opt/struktur/hermes-ui-auswahl/compose.yaml`

Dort definiert der Service `hermes-kanban-adapter` den syntaktisch fehlerhaften Healthcheck.

### Herkunft
- **Herkunft:** lokal gepflegte Compose-Datei
- **Nicht aus Image-Metadaten**
- **Nicht aus dem Dockerfile des Images**
- **Nicht aus dem Entrypoint**
- **Nicht aus einem Healthcheck-Skript**
- **Nicht aus einer generierten Runtime-Datei**

---

## 4. Weitere betroffene Stellen

### Derselbe fehlerhafte Healthcheck an weiteren Stellen?

**Gefunden:** Nein, nach der gezielten Suche ist der fehlerhafte String nur an **einer Stelle** sichtbar:

- `/opt/struktur/hermes-ui-auswahl/compose.yaml:57`

### Gleiches Image, anderer Healthcheck?

Ja. Das Image `ghcr.io/outsourc-e/hermes-workspace:latest` besitzt **einen eigenen, korrekten Image-Healthcheck**:

- `curl -fsS http://127.0.0.1:3000/ >/dev/null || exit 1`

Das zeigt eine Trennung zwischen:
- **Image-Standard-Healthcheck** und
- **Compose-überschriebener Healthcheck-Definition**

### Weitere Container mit demselben fehlerhaften Healthcheck?

**Nein, nicht gefunden.**

Die Prüfung ergab keinen zweiten Container, der exakt denselben fehlerhaften `fetch(http://127.0.0.1:5099/health)`-Healthcheck verwendet.

---

## 5. Lokal geändert oder bereits Bestandteil des Images?

**Ergebnis:** lokal geändert / lokal definiert, **nicht** Bestandteil des Images.

Begründung:
1. Das Image-Metadatum enthält einen anderen Healthcheck.
2. Die aktive Compose-Datei enthält die fehlerhafte Definition.
3. Der laufende Container trägt genau diese fehlerhafte Definition in `.Config.Healthcheck`.

Damit ist die Ursache eindeutig: **die Compose-Datei überschreibt den Image-Healthcheck lokal**.

---

## 6. Auswirkungen

### Ist der Fehler auf `hermes-kanban-adapter` beschränkt?

**Ja, nachweislich auf diesen Container beschränkt.**

Die gezielte Suche nach der fehlerhaften Healthcheck-Definition hat keinen zweiten Container mit derselben Definition gefunden.

### Kann dieser Fehler andere Symptome erklären?

Nur sehr eingeschränkt:

- **Nicht geeignet als primäre Erklärung** für Dashboardfehler, Workspacefehler, Cronprobleme, KI & Automation oder YouTube Research.
- **Geeignet als Erklärung** dafür, dass **nur der Gesundheitsstatus des Kanban-Adapters** auf `unhealthy` steht.
- **Eher Folge-/Anzeigeproblem**, nicht Ursache eines allgemeinen Systemausfalls.

---

## 7. Empfehlung für genau EINE Reparaturmaßnahme

**Eine einzige Reparaturmaßnahme:**
Die fehlerhafte Healthcheck-Zeile in `/opt/struktur/hermes-ui-auswahl/compose.yaml` gezielt korrigieren, damit die URL im `node -e`-Ausdruck als String gequotet wird.

Beispiel der beabsichtigten Korrektur:

```bash
node -e "fetch('http://127.0.0.1:5099/health').then(r=>{if(!r.ok)process.exit(1)})"
```

---

## Kurzfazit

Die fehlerhafte Healthcheck-Definition für `hermes-kanban-adapter` stammt **aus der lokalen Compose-Datei** `/opt/struktur/hermes-ui-auswahl/compose.yaml` und **nicht** aus dem Image. Sie ist derzeit nur für diesen einen Container nachweisbar.

**Arbeitsauftrag 030 erledigt.**