# API-11 – Prüfprotokoll: Wiederanlauf-Nachsynchronisierungs-Endpunkt starten (API-06 als laufender Dienst)

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

## Reines Wiring, keine neue Logik

`git diff --stat internal/resync/ internal/audit/ internal/usage/ internal/moduleregistry/`
liefert KEINEN Diff gegenüber den jeweiligen Ticket-Ständen. `API-11`
fügt ausschließlich `cmd/resync-api/main.go` hinzu — inklusive eines
kleinen `auditAdapter`, der `resync.AuditRecorder` (einzelne Felder)
auf `audit.Log.Record` (Event-Struct) abbildet. Das ist reine
Signatur-Anpassung, keine neue Geschäftslogik.

## Root Cause (dokumentiert)

`cmd/core/main.go` ist seit TEN-01 minimal geblieben (nur `/healthz`,
`/internal/tenants`) — kein späteres Ticket (RBAC-02, CFG-02, API-06,
...) wurde je dort zentral eingehängt. Jedes Modul entstand auf einer
eigenen, unabhängigen Feature-Branch-Kette. API-11 folgt dem in dieser
Session etablierten Muster (RBAC-06, CFG-05, RET-09): ein eigener,
kleiner HTTP-Dienst statt eines zentralen `cmd/core`-Umbaus.

## Umsetzung

- `cmd/resync-api/main.go` – startet `internal/resync.Handler` mit
  echten Produktions-Implementierungen: `moduleregistry.Registry`
  (Auth), `audit.Log` (über `auditAdapter`), `usage.Store`.
- `deploy/systemd/nexarch-resync-api.service.tmpl`.

## Prüfungen

| # | Prüfung | Ergebnis |
|---|---|---|
| 1 | Dienst startet und bleibt stabil (systemctl status aktiv) | **bestanden** – real auf 131: `nexarch-resync-api.service` aktiv, `Restart=on-failure` |
| 2 | Realer POST /internal/resync/usage von einem externen Testclient gegen den laufenden Dienst liefert die erwartete Verarbeitung | **bestanden** – real per `curl`: mit echtem, über `moduleregistry.Registry.Provision` ausgestelltem Service-Credential (`X-Nexarch-Client-Id`/`X-Nexarch-Client-Secret`) liefert der Aufruf `{"applied":1}`, `usage_counters` zeigt real den erhöhten Zähler; mit falschem Credential 401. Testdaten (Modul, Credential, Zähler-Zeile) anschließend entfernt |
| 3 | Code-Review: keine Änderung an internal/resync/ selbst, nur main.go+systemd neu | **bestanden** – `git diff --stat` bestätigt: `internal/resync/`, `internal/audit/`, `internal/usage/`, `internal/moduleregistry/` unverändert gegenüber ihren jeweiligen Ticket-Ständen |

## Echte Verdrahtung auf 192.168.1.131

- `resync-api` gebaut nach `/opt/nexarch-core/bin/`,
  `/etc/nexarch/resync-api.env` (0600), `nexarch-resync-api.service`
  installiert/aktiviert.
- Reale Rechtevergabe-Lücke gefunden und behoben (gleiches Muster wie
  bei den vorherigen Wrapper-Diensten): `modules`, `module_credentials`,
  `audit_events`, `feature_flags`, `usage_counters`,
  `resync_audit_buffer`, `resync_usage_buffer` gehörten `postgres`,
  `nexarch_core` hatte keine Rechte — `GRANT` nachgezogen und über
  `information_schema.role_table_grants` verifiziert, bevor der
  End-zu-Ende-Test erneut lief.
- Zusätzliche reale Erkenntnis: `usage_counters.tenant_id` ist `UUID`,
  nicht der Tenant-Slug (String) — beim ersten Testversuch mit `"acme"`
  scheiterte der Insert intern, `UsageHandler` meldete `applied:0` statt
  eines Fehlers (stiller Fehlschlag pro Delta, so von API-06 selbst so
  entworfen: "Aufrufer entfernt aus seinem Puffer nur bestätigt
  übernommene Deltas" — kein API-11-Defekt, sondern korrektes,
  bestehendes API-06-Verhalten). Mit echter UUID als `tenant_slug`-Wert
  lieferte der Aufruf real `applied:1`.

## Build/Test-Ergebnis (192.168.1.131)

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

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

## Gesamtergebnis

**Bestanden.** API-06 ist jetzt ein real laufender, über systemd
verwalteter Dienst. Modul-Clients wie DMS' `storage.HTTPUsageReporter`
(RET-06/DOC-16-Umfeld) können sich jetzt real gegen einen laufenden
Endpunkt verdrahten, statt gegen unverdrahteten Go-Code zu testen.