# Kanban-Refresh-Analyse

## Befund

Der Workspace-Code in `src/screens/swarm2/swarm2-kanban-board.tsx` lädt Kanban-Daten über `GET /api/swarm-kanban` und verwendet `refetchInterval: 5_000`. Der Server-Endpunkt im Workspace ruft seinerseits die Kanban-Quelle ab. Dadurch kann jede spätere Abfrage die Darstellung erneut überschreiben.

## Korrektur

Der externe Adapter ist jetzt der öffentliche lokale Front-Proxy auf `127.0.0.1:5099`. Er behandelt ausschließlich `GET /api/swarm-kanban`: Quelle ist der unveränderte Hermes-Dashboard-Board-Endpunkt, die Antwort wird mit der externen Mapping-Datei transformiert und mit `Cache-Control: no-store, no-cache, must-revalidate`, `Pragma: no-cache` und `Expires: 0` ausgeliefert. Alle übrigen Workspace-Anfragen werden an den Workspace auf `127.0.0.1:5100` weitergeleitet.

## Technischer Nachweis

Vier öffentliche GET-Abrufe bei 0, 10, 30 und 60 Sekunden enthielten jeweils 35 Karten, 35 eindeutige IDs und dieselbe Verteilung: `running 13`, `ready 7`, `scheduled 1`, `blocked 4`, `triage 5`, `done 2`, `todo 3`.

Es wurde kein zweiter Datenkanal für Kanban im Workspace-Quellcode gefunden. WebSocket/SSE und Browser-Storage sind nicht als Kanban-Datenquelle belegt. Eine echte Browser-Netzwerk-/Langzeitabnahme konnte wegen eines Fehlers beim Start der Browser-Laufzeit nicht durchgeführt werden; daher wird kein vollständiger Erfolg behauptet.

## Datenintegrität

Die produktive Datenbank blieb unverändert. SHA-256 nach den Tests: `70eed208f89e3203057be7ed0d781d811d4e541cba87bd3168c6eaa1879d169d`.

Das 90-Karten-Backup wurde nicht verwendet.