12 Commits

Include renames

Author	SHA1	Message	Date
patrickandClaude Sonnet 5.5	7515b8db4d	refactor: weitere identische Pakete nach common/ (svcauth, auditclient, tenantregistryclient, policyclient, httpharden, loadtest, httpclient) ... Nur Pakete, deren Code ohne Kommentare/Importpfade byte-gleich ist: - httpclient: ai, connect (Root behaelt eigene Kopie wegen strengerem Waechtertest) - svcauth: archive, ai, workflow - auditclient: ai, connect, archive - tenantregistryclient: dms, ai, workflow (archive weicht ab, bleibt) - policyclient: mail, connect (dms weicht ab, bleibt) - httpharden: Root, archive (dms weicht ab, bleibt) - loadtest: mail, ai (archive, connect weichen ab, bleiben) go.mod (require + replace) fuer ai, connect, workflow; Pflichttest-Gates von ai/workflow und CI-Pfadfilter um common/ erweitert, damit die sicherheitskritischen Pakete (svcauth, tenantregistryclient) weiter gegated werden. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>	2026-10-27 14:06:07 +01:00
patrickandClaude Sonnet 5	d5b526db0e	Merge: main in OPS-12 einarbeiten, Konflikt in internal/config/config.go aufgeloest ... PR #217 (OPS-12) war nicht mergefaehig: additiver Konflikt in Config{} -- main hatte inzwischen ModuleDirectoryPath ergaenzt, OPS-12 ergaenzt unabhaengig davon TenantRuntimeDSNTemplate. Beide Felder behalten, keine inhaltliche Aenderung an der eigentlichen OPS-12-Logik. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-17 16:20:35 +02:00
patrickandClaude Sonnet 5	b2bd1c4c1a	API-22: modul endpunkt discovery ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-28 04:56:41 +00:00
patrickandClaude Sonnet 5	02038866a9	OPS-12: systemd haertung und db rollentrennung (F-15) ... 10 bisher ungehaertete Archive-Backup/Reconcile/Scrub-Oneshot-Vorlagen (deploy/systemd/) bekommen die etablierten Sandbox-Direktiven (NoNewPrivileges, ProtectSystem=strict, ProtectHome, PrivateTmp, ggf. ReadWritePaths). Drei Vorlagen ohne Dateisystemzugriff (reconcile, retention-notify, scrub) bekommen bewusst keine ReadWritePaths, begruendet dokumentiert (S3-kompatible Storage-Abstraktion statt lokaler Pfade). Neue, getrennte Postgres-Laufzeit-Rolle (nexarch_tenant_runtime, OHNE CREATEDB) statt der bisher gemeinsam genutzten CREATEDB-Rolle fuer NEXARCH_TENANT_DSN_TEMPLATE. Provisioner.Provision() berechtigt die neue Rolle je frisch angelegter Tenant-DB (GRANT CONNECT + Schema- Rechte inkl. Default-Privileges), Tenant.DBDSN wird jetzt mit dieser Rolle statt der CREATEDB-Rolle gebaut. Neue Umgebungsvariable NEXARCH_TENANT_RUNTIME_DSN_TEMPLATE, deploy/install.sh legt die Rolle automatisch an. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-26 22:34:51 +02:00
ClaudeandClaude Sonnet 5	f07fe4c596	INT-14: fehlenden Core-Endpunkt GET /tenants/{slug} ergaenzen ... DMS' und Archives internal/tenantregistryclient (INT-14) riefen bereits GET /tenants/{slug} mit X-Service-Token gegen Core auf, aber Core registrierte diese Route nirgends -- jeder Aufruf schlug mit 404 fehl. Beim Rollout-131-Versuch entdeckt. Neuer Handler tenant.ConfirmHandler nutzt die bestehende Registry.GetBySlug, dieselbe svcauth.Require-Absicherung wie TEN-12s Import-Verzeichnis-Routen (kein neues Auth-Schema). 200 mit Slug/Status bei bekanntem Mandanten, 404 bei unbekanntem, 500 nur bei echtem DB-Fehler -- der bestehende Client wertet ausschliesslich den Statuscode aus. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-26 01:36:46 +02:00
patrickandClaude Sonnet 5	637998a322	TEN-12: import-verzeichnisse-je-tenant-in-der-registry-fuehren ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-23 00:17:27 +02:00
patrickandClaude Sonnet 5	9aa69d3801	TEN-13/LIC-07: Dienst-Token fuer interne Admin-Endpunkte, Loopback-Standard, CORS-Ursprungsliste, Proxy in den Admin-Oberflaechen (QA-15 F-01..F-03) ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-22 00:49:27 +02:00
patrickandClaude Sonnet 5	4fc361b462	TEN-09: registry-h-rtung-zugriffsschutz ... Haertet die Control-Plane-Registry als eigene Schutzzone: - Dedizierte Postgres-Rolle nexarch_registry (ohne CREATEDB) fuer NEXARCH_REGISTRY_DSN, getrennt von der Provisioning-Rolle nexarch_core (deploy/install.sh). Neu angelegte Tenant-Datenbanken entziehen PUBLIC explizit das CONNECT-Recht (internal/tenant/provisioner.go), damit die Registry-Rolle unter keinen Umstaenden Zugriff auf eine Tenant-Datenbank erhaelt (Akzeptanzkriterium 1). - Auditierte Zugriffsmethoden (*AsActor) fuer Superadmin-Konten (internal/user.SuperadminStore) und Verbindungsinformationen (internal/tenant.Registry) — jeder lesende/schreibende Zugriff erzeugt einen Audit-Event mit Akteur und Zeitstempel, verdrahtet in internal/tenantadmin (TEN-05-Konsole) und cmd/core (Akzeptanzkriterium 2). - Betriebsanleitung docs/TEN-09-REGISTRY-BETRIEB.md dokumentiert Rollentrennung und den auf den Core-Dienst beschraenkten Netzwerkzugriff (pg_hba.conf, listen_addresses, Firewall-Default-Policy), abgesichert durch internal/opsdocs/registry_hardening_test.go (Akzeptanzkriterium 3). Automatisierte Tests je Akzeptanzkriterium: internal/tenant/isolation_test.go (negativer Zugriffstest), internal/audit/wiring_test.go (TestWiring_SuperadminReadIsAudited, TestWiring_RegistryConnectionInfoReadIsAudited), internal/opsdocs/registry_hardening_test.go. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QPsyieCYwvbUBsnN598SbP	2026-09-17 01:37:40 +02:00
sysopsandClaude Sonnet 5	5915a4e7b1	TEN-02: tenant-onboarding-api-self-service ... OnboardingService.Onboard: ein API-Aufruf legt Tenant (via bestehendem Provisioner) UND ersten Administrator-Account (via IAM-01 TenantUserStore) an. CREATE DATABASE erlaubt keine echte cross-database Transaktion, daher Saga-Kompensation: schlaegt die Admin-Anlage nach erfolgreichem Provisioning fehl, wird der Tenant per neuem Provisioner.Deprovision wieder vollstaendig entfernt (Registry.Delete + DB-Drop). Provisioner.Provision mappt Duplikat-Faelle (42P04 duplicate_database und den bei echt parallelen CREATE DATABASE moeglichen 23505-Unique-Konflikt auf pg_database) jetzt auf ErrTenantExists statt einer rohen Postgres-Fehlermeldung. Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS): 1. Onboarding-Vorgang zweimal parallel mit gleichem Slug ausgeloest — TestOnboarding_RejectsDuplicateSlugConcurrently: genau ein Erfolg, kein Doppel-Tenant, zweiter Aufruf bekommt ErrTenantExists. PASS. 2. Fehleingaben (leere Pflichtfelder, ungueltige E-Mail, ungueltiger Slug) — TestOnboarding_ValidationErrors deckt alle vier Faelle mit klaren Fehlern ab, bevor irgendein DB-Zugriff stattfindet. PASS. 3. Erfolgreicher Durchlauf von zweiter Person end-to-end nachvollzogen — NICHT durchgefuehrt (keine zweite Person in dieser Session verfuegbar). Offen. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-27 18:16:54 +02:00
sysopsandClaude Sonnet 5	e4793303fc	IAM-01: benutzer-datenmodell-crud ... Benutzer-Datenmodell + CRUD fuer Tenant-User (tenant-scoped, keine tenant_id-Spalte noetig, Tenant ergibt sich aus der DB-Verbindung, Modell C) und getrennt dafuer SuperadminStore fuer mandantenuebergreifende Konten in der Registry-DB — First-Class-Typ statt tenant_id-NULL-Sonderfall im Tenant-User-Code (bekannter archivdms-Fehler vermieden). E-Mail-Eindeutigkeit: tenant-scoped fuer normale Benutzer (UNIQUE-Constraint gilt nur innerhalb der jeweiligen Tenant-DB), global fuer Superadmins (eine Registry-DB, ein UNIQUE-Constraint). Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS): 1. CRUD automatisiert getestet inkl. Negativfaellen — TestTenantUserStore_CRUD deckt doppelte E-Mail (ErrEmailTaken) und unbekannte ID ab. PASS. 2. Superadmin-Anlage ohne Tenant-Kontext — TestSuperadminStore_CreateWithoutTenantContext: SuperadminStore.Create hat syntaktisch keinen Tenant-Parameter, kein if-Zweig fuer "kein Tenant" im Code. PASS. 3. Datenmodell von zweiter Person gegen Dokumentation geprueft — NICHT durchgefuehrt (keine zweite Person in dieser Session verfuegbar). Offen. Tenant-User-Handler ist im Code vorhanden, aber in cmd/core/main.go noch nicht geroutet — braucht Connection-Routing pro Mandant (TEN-06), das nicht Teil dieser Kachel ist. Nur der Superadmin-Endpunkt ist verdrahtet. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-27 17:57:49 +02:00
sysopsandClaude Sonnet 5	8da9c67d08	TEN-01: tenant-registry-datenbank-provisioning ... Registry-DB (nur Tenant-Metadaten), Provisioning-Routine legt pro Mandant eine physisch isolierte Postgres-DB an und registriert sie transaktional (Rollback der DB bei fehlgeschlagener Registrierung). Schlanker HTTP-Handler als Schnittstellen-Vorbereitung fuer API-01/TEN-02, kein eigenes REST-Grundgerüst. Pruefungen: 1. Migration up/down geschrieben (0001_tenant_registry.{up,down}.sql) — nicht gegen echte DB ausgefuehrt, da auf dieser Maschine kein Go/Postgres-Test- Setup verfuegbar ist. Offen zur Ausfuehrung. 2. Integrationstest TestProvision_CreatesIsolatedDatabases geschrieben (zwei Mandanten, prueft unterschiedliche db_name und current_database()) — ebenfalls nicht ausgefuehrt, guarded per TEST_ADMIN_DSN env var. Offen. 3. Slug-Validierung (unit test TestValidateSlug) deckt SQL-Injection-Versuch im Datenbanknamen ab — ebenfalls nicht lokal ausgefuehrt, da kein Go Compiler auf dieser Maschine vorhanden ist. Offen. Alle drei Pruefungen sind vorbereitet, aber NICHT durchgefuehrt worden — zaehlen laut Vorgabe als offen bis auf einer Maschine mit Go+Postgres verifiziert. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-27 17:40:35 +02:00
sysops	c895a67c4b	core: initial Go module skeleton (config, db pool, tenant registry migration)	2026-08-27 17:27:59 +02:00