Gesamtprojekt: Nachtrag 26 -- Workflow ENG-04, Connect ENG-05, AI ENG-04/05 gemergt, Restliste bestaetigt

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/GESAMTPROJEKT-PRUEFPROTOKOLL.md

@@ -659,3 +659,28 @@ Head jetzt `1b170a3`, gepusht auf `integration/gesamtprojekt`, PR #104 aktualisi
 12. Skalierungs-Benchmark (FDN-26) lief mit 3.000 statt der ursprünglich genannten 50.000–200.000 Dokumenten (Host-Ressourcen).
 
 **Bewusst nicht angefasst:** `migration-kanban` — reale Übernahme aus den Altsystemen archivmail/archivdms zu einem echten Stichtag, braucht echte Exportdaten und menschliche Freigaben je Mandant, kein Entwicklungsvorhaben.
+
+## Nachtrag 26: ENG-04/ENG-05-Bausteine (Workflow, Connect, AI), vollständige Restliste
+
+Merge von #153 (Workflow ENG-04, Instanz-Historie & Nachvollziehbarkeit), #154 (Connect ENG-05, Fehlerbehandlung & Retry, baut auf ENG-03 auf), #155 (AI ENG-04, Modellverwaltung je Tenant) und #156 (AI ENG-05, Inferenz-Queue, Branch tatsächlich `feature/eng-05-inferenz-queue`, nicht `…-ai-…`) in `integration/gesamtprojekt`, nacheinander.
+
+### Konflikt
+
+AI ENG-04 und ENG-05 brachten unabhängig voneinander je eine eigenständige Kopie von `ai/internal/migrate`, `ai/internal/testdb` und Änderungen an `ai/go.mod`/`ai/go.sum` mit (Go-Module teilen keine `internal/`-Pakete, beide Forks haben das DMS-Muster separat kopiert). `migrate.go`/`testdb.go` waren bis auf einen Kommentar textidentisch — automatisch zusammengeführt bzw. eine Seite behalten. `go.mod` hatte einen echten Versionskonflikt (`pgx/v5 v5.11.0` gegen `v5.9.2`) — höhere Version behalten, danach `go mod tidy` auf 204 ausgeführt: das dabei erzeugte `go.sum` war byteidentisch mit der beim Konfliktlösen provisorisch behaltenen Fassung.
+
+### Prüfungen auf 204 (Wegwerf-Cluster, `archivdms` unberührt)
+
+- Vorab: keine verwaisten Ports/Prozesse von vorherigen Läufen (nur die dauerhaften Sidecars `nexarch-dms-kosit` :8610, `verapdf-sidecar` :8612, sowie der unabhängige `archivdms`-Dienst).
+- `ai/`, `workflow/`, `connect/`: je `go build ./...`, `go vet ./...`, `gofmt -l` sauber nach dem Konfliktlösen und `go mod tidy`.
+- `go test -count=1 ./...` je Modul MIT `TEST_TENANT_DSN` gesetzt, alle Pakete `ok`, keine stillen Skips: `ai/internal/{modelconfig,provider,provider/ollama,provider/openai,queue}`, `workflow/internal/{moduleadapter,processdef,statemachine}`, `connect/internal/{credential,fieldmapping,registry,syncjob}`.
+- Bestehende vier Module (`/`, `dms/`, `archive/`, `mail/`): unverändert. `dms/` voller `go test ./...` 0 FAIL.
+- `scripts/e2e-core-dms.sh`: 10/10 PASS (u. a. RBAC-10-Modulaktivierung, Core-Ausfall-Cache, abgelaufenes Token — 37 s Testlaufzeit dafür ist erwartet).
+- `scripts/gesamt-token-smoke.sh` (per `setsid nohup … < /dev/null`, vollständig von der SSH-Sitzung gelöst): **45/45 bestanden, 0 Fehler, Rückbau-Snapshot IDENTISCH.**
+
+### Push
+
+Merge-Commits `0a38847`..`65cc397`, Head jetzt auf `integration/gesamtprojekt` nach Push aktuell. Kein Merge nach `main`.
+
+### Restliste — unverändert gegenüber Nachtrag 25
+
+Die priorisierte Restliste aus Nachtrag 25 gilt unverändert weiter. Punkt 7 (AI/Workflow/Connect: nur Grundlagen, kein HTTP-Dienst) ist inhaltlich weiter offen — dieser Nachtrag hat die Bibliotheksebene vertieft (Modellverwaltung, Inferenz-Queue, Instanz-Historie, Retry-Logik), aber noch keinen der drei Module nach außen als laufenden Dienst exponiert.