nexarch/docs/API-22-PRUEFPROTOKOLL.md

API-22 – Modul-Endpunkt-Discovery – Prüfprotokoll

Geprüft auf Entwicklungshost 204, Build/Vet/Test lokal im Arbeitsverzeichnis der Ticket-Session. archivdms unberührt, Host 131 nicht angefasst.

Umsetzung

• Neues Paket internal/moduledirectory (Core): LoadFile(path) liest und validiert eine JSON-Konfigurationsdatei (Liste aus {"key", "base_url"}), Handler(modules) liefert sie unauthentifiziert als JSON aus.
• Response-Feldliste ist auf key/base_url beschränkt (Akzeptanzkriterium 3) — keine Zugangsdaten, keine internen Pfade, kein Bezug zu module_credentials/Provision/Authenticate.
• cmd/core/routes.go: registerModuleDirectoryRoute bindet GET /.well-known/nexarch-modules ein, bewusst außerhalb von svcauth.Require (unauthentifiziert, Ticket-Vorgabe für Clients, die nur die Server-Grundadresse kennen, z.B. INT-21).
• cmd/core/main.go: lädt die Konfigurationsdatei über neuen config.ModuleDirectoryPath (Env NEXARCH_MODULE_DIRECTORY_PATH), optional — fehlt der Pfad, liefert der Endpunkt eine leere Liste statt den Dienststart zu verhindern (keine bestehende Deployment-Konfiguration wird durch diese Kachel gebrochen).
• Keine Änderung an internal/moduleregistry (Credentials/Aktivierung bleiben unverändert), keine Änderung an web/portal oder INT-21 (Android-App) — beides laut Ticket explizit nicht Bestandteil.

Prüfungen

Prüfung 1 — Discovery-Aufruf liefert für ein bekanntes Modul die korrekte, tatsächlich erreichbare Adresse:

• TestHandler_ReturnsReachableAddress (internal/moduledirectory/directory_test.go): startet einen echten httptest.Server, trägt dessen URL als Modul ein, ruft den Discovery-Handler auf, parst die Antwort und führt anschließend einen echten http.Get gegen die zurückgegebene base_url aus — Roundtrip bestätigt Erreichbarkeit. Bestanden.

Prüfung 2 — neues Test-Modul nur über Konfiguration ergänzt, erscheint korrekt im Discovery-Ergebnis:

• TestLoadFile_ParsesModules: JSON-Datei mit einem bestehenden (dms) und einem neuen Test-Modul (neues_testmodul), rein über die Konfigurationsdatei ergänzt, kein Code geändert. Beide erscheinen korrekt im geladenen Ergebnis. Bestanden.
• TestModuleDirectoryRoute_IsUnauthenticated (cmd/core/routes_test.go): Route ohne jeden Token erreichbar, Handler wird aufgerufen. Bestanden.

Prüfung 3 — kein sicherheitsrelevanter Wert im Antwort-Payload (Positivliste erlaubter Felder):

• TestHandler_OnlyAllowlistedFieldsInPayload: parst die Antwort generisch (map[string]interface{}), prüft jedes Feld jedes Moduleintrags gegen die Positivliste {key, base_url} und durchsucht den rohen Payload zusätzlich nach den Begriffen secret, client_id, client_secret, password, token, internal_path, dsn. Bestanden.
• Zusätzlich: TestLoadFile_RejectsMissingFields/TestLoadFile_RejectsMissingFile (Robustheit der Konfigurationsquelle).

Build/Vet/Test

• go build ./... — grün.
• go vet ./internal/moduledirectory/... ./cmd/core/... — grün.
• go test ./internal/moduledirectory/... ./cmd/core/... -v — alle 7 Tests bestanden (5 in moduledirectory, 2 in cmd/core).

QA und Entscheidungen

• Entscheidung — Konfigurationsquelle: neue, kleine JSON-Datei server-seitig (Pfad über Env), analog zu web/portal/config/modules.json aus SHL-02, aber serverseitig gepflegt statt clientseitig — wie in der Ausgangslage des Tickets vorgeschlagen. internal/moduleregistry/modules-Tabelle hält keine Adressinformationen und wurde bewusst nicht erweitert, um den Datenbank-Registrierungspfad (API-02) von der reinen Adress-Konfiguration zu trennen.
• Entscheidung — Pfad optional statt Pflichtfeld: anders als die übrigen config.Load()-Felder ist NEXARCH_MODULE_DIRECTORY_PATH optional (leere Liste statt Fatal), damit bestehende Deployments ohne diese neue Datei weiterlaufen, bis eine echte Konfiguration gepflegt ist.
• 0 blockierende Iterationen.

Offen

• web/portal (SHL-02) migriert seine statische Konfiguration nicht auf diesen Endpunkt — laut Ticket ausdrücklich ein späteres, nicht ticketiertes Follow-up.
• INT-21 (Android-App) bleibt beim Zwei-Felder-Workaround — laut Ticket ausdrücklich nicht Bestandteil.
• Es existiert noch keine gepflegte Produktions-modules-directory.json auf den Zielhosts; das Anlegen/Pflegen dieser Datei ist Deployment-/Betriebsaufgabe, nicht Teil dieser Codeänderung.