# API-12 – Prüfprotokoll: KEK-Bezugsdienst starten (API-10 als laufender Dienst)

Voraussetzung API-10 – bereits Fertig, hier UNVERÄNDERT.

## Reines Wiring, keine neue Logik

`git diff --stat internal/kek/ internal/moduleregistry/ internal/tenant/`
liefert KEINEN Diff. `cmd/kek-api/main.go` setzt ausschließlich
bestehende Konstruktoren zusammen; `tenantResolverAdapter` bildet nur
`tenant.Registry.GetBySlug` auf `kek.TenantResolver` ab (Signatur-
Anpassung, kein neuer Fachcode).

## Umsetzung

- `cmd/kek-api/main.go` – `POST /internal/kek/tenant?tenant=<slug>`,
  authentifiziert über dasselbe Service-Credential-Verfahren wie jeder
  andere Modul-Core-Aufruf (API-02), zusätzlich Tenant-Aktivierungs-
  prüfung (identisches Muster wie in `internal/kek.Handler` bereits
  vorgesehen).
- `deploy/systemd/nexarch-kek-api.service.tmpl`.

## Prüfungen

| # | Prüfung | Ergebnis |
|---|---|---|
| 1 | Dienst startet und bleibt stabil (systemctl status aktiv) | **bestanden** – real auf 131: `nexarch-kek-api.service` aktiv |
| 2 | Realer Aufruf mit gültigem Service-Credential liefert den erwarteten Tenant-KEK, ohne/mit falschem Credential wird abgelehnt | **bestanden** – real per `curl`: echtes Modul registriert+provisioniert, echter Tenant-KEK über `kek.Store.CreateForTenant` erzeugt (Klartext-Hex zum Vergleich notiert) — Aufruf mit korrektem Credential liefert exakt denselben KEK (Base64-dekodiert übereinstimmend mit dem erzeugten Hex-Wert verifiziert); Aufruf mit falschem Credential → 403 |
| 3 | Code-Review: keine Änderung an internal/kek/ selbst, nur main.go+systemd neu | **bestanden** – `git diff --stat` bestätigt: `internal/kek/`, `internal/moduleregistry/`, `internal/tenant/` unverändert |

## Echte Verdrahtung auf 192.168.1.131

- `kek-api` gebaut nach `/opt/nexarch-core/bin/`,
  `/etc/nexarch/kek-api.env` (0600, echter zufälliger 32-Byte-
  Master-Key), Dienst installiert/aktiviert.
- Reale Grant-Lücke gefunden und behoben (gleiches Muster wie zuvor):
  `nexarch_core` hatte keine Rechte auf `tenant_keks` — `GRANT`
  nachgezogen und über `information_schema.role_table_grants`
  verifiziert.
- End-zu-Ende-Beweis: echtes Modul registriert, Service-Credential
  provisioniert, echter Tenant + Tenant-KEK real erzeugt, `curl` gegen
  den laufenden Dienst liefert exakt diesen KEK zurück (Byte-für-Byte
  verglichen), falsches Credential real abgelehnt. Testdaten
  anschließend entfernt.

## Build/Test-Ergebnis (192.168.1.131)

```
go build ./...  -> clean
go vet ./...    -> clean
golangci-lint run ./cmd/kek-api/...  -> 0 issues
```

Keine neuen Go-Tests nötig (kein neuer Fachcode außer main.go/Adapter,
die eigentliche Logik ist bereits durch API-10s eigene Tests
abgedeckt).

## Gesamtergebnis

**Bestanden.** API-10 ist jetzt ein real laufender, über systemd
verwalteter Dienst — Voraussetzung für Mail ARC-02 und künftig DMS
FDN-09-Nachnutzung.