Add AI workspace reviews
This commit is contained in:
@@ -0,0 +1,168 @@
|
||||
# Offene Fragen vor Entwicklungsbeginn
|
||||
|
||||
**Stand:** 15. Mai 2026
|
||||
**Reviewer:** Claude
|
||||
**Bezug:** Hosting-Backoffice v0.1 (vollständiger Basisbestand)
|
||||
|
||||
Diese Fragen müssen vor Beginn der V1-Implementierung beantwortet sein. Sie sind nach Themenbereich gruppiert. Innerhalb jedes Bereichs sind sie nach Dringlichkeit geordnet.
|
||||
|
||||
---
|
||||
|
||||
## 1. Mandantenfähigkeit
|
||||
|
||||
1. Welches Tenancy-Modell gilt für V1: Shared Database mit `tenant_id`-Scope, Schema-pro-Tenant, oder Database-pro-Tenant?
|
||||
2. Was bedeutet `organisation_id` zusätzlich zu `tenant_id`? Sind beide Synonyme (eines streichen) oder Hierarchieebenen (dann mit ER-Modell zeigen)?
|
||||
3. Wie wird Tenant-Isolation technisch erzwungen? Eloquent Global Scope, Policy-Layer, Row-Level Security in Postgres, Connection-Switching, oder Kombination?
|
||||
4. Wie viele Subjektebenen hat das Berechtigungsmodell? Plattformbetreiber → Mandant → Endkunde, oder mit Reseller-Zwischenebene?
|
||||
5. Wie sieht der Tenant-Lifecycle aus: Provisioning, Suspend, Termination, Datenexport, Offboarding?
|
||||
6. Wie wird Cross-Tenant-Datenzugriff für Plattform-Admins technisch geregelt (Impersonation, Read-only-Bypass, Audit-Pflicht)?
|
||||
7. Wie wird beim Wechsel von V1 (Single-Tenant) zu V2/V3 (Multi-Tenant) der erste Mandant migriert?
|
||||
8. Gibt es Cross-Tenant-Ressourcen (gemeinsame Templates, Knowledge Base, Module Registry), und wie sind sie modelliert?
|
||||
|
||||
---
|
||||
|
||||
## 2. Datenmodell
|
||||
|
||||
1. Wie sieht das vollständige ER-Modell mit Beziehungen und Kardinalitäten aus?
|
||||
2. Welche Statusmaschinen existieren für Vertrag, Domain, Hostingpaket, Ticket, Rechnung, und welche Übergänge sind erlaubt?
|
||||
3. Wie werden Nummernkreise pro Mandant verwaltet (lückenlos, GoBD-konform, separat für Kunde/Vertrag/Rechnung)?
|
||||
4. Wird `Kunde` in Party/Address/ContactPoint aufgespalten, oder als monolithisches Objekt gehalten?
|
||||
5. Wie wird B2B vs. B2C unterschieden im Datenmodell?
|
||||
6. Wie wird das Spannungsfeld Soft-Delete / GoBD-Retention / DSGVO-Löschung technisch aufgelöst? Tombstone-Modell mit Pseudonymisierung?
|
||||
7. Wie werden externe Referenzen modelliert (generisches Pattern statt anbieter-spezifischer Felder im Core)?
|
||||
8. Wie ist das Audit-Log-Schema, und wie wird Unveränderbarkeit garantiert (Hash-Chain, Append-only-DB, externes Sink)?
|
||||
9. Werden Verträge versioniert (Vertragsversion, Änderungshistorie)?
|
||||
10. Wie werden Subscriptions/Laufzeiten modelliert (Vertrag.Laufzeit reicht nicht für Up-/Downgrade und Pro-rata)?
|
||||
11. Wie wird die Many-to-many-Beziehung Vertrag↔Produkt, Vertrag↔Domain, Vertrag↔Hostingpaket modelliert?
|
||||
12. Wie ist das Asset-/Dokument-Modell (Hashes, Content-Addressing, Versionen, Storage-Backend-Abstraktion)?
|
||||
|
||||
---
|
||||
|
||||
## 3. API
|
||||
|
||||
1. Welcher Auth-Stack: Sanctum Personal Access Tokens, Sanctum SPA-Mode, Passport/OAuth2, oder Kombination je Client-Typ?
|
||||
2. Gibt es OpenAPI 3.x als verbindliche Spec, und ist die Implementierung spec-first?
|
||||
3. Welches Error-Modell wird verwendet (Problem Details RFC 7807 empfohlen)?
|
||||
4. Welche Pagination-Strategie: Offset, Cursor, Page?
|
||||
5. Welche Idempotenz-Strategie für nicht-idempotente Operationen (Domain-Registrierung, Rechnungsanlage)?
|
||||
6. Wie sieht das Filtering-/Sorting-Schema aus?
|
||||
7. Wie wird API-Versionierung über `/api/v1/` hinaus gehandhabt (Deprecation, Sunset, Compatibility)?
|
||||
8. Gibt es Webhooks/Outbound Events? Welches Format, welche Signaturen, welche Delivery-Garantien?
|
||||
9. Wie werden Rate-Limits pro Mandant skaliert (nicht nur pro IP/Token)?
|
||||
10. Welche Endpoints sind read-only, welche schreibend, und wie ist das in der Auth-Scope-Logik abgebildet?
|
||||
11. Wie werden Long-Running-Operations modelliert (Domain-Imports, große Synchronisationen) – synchron, asynchron mit Job-Status-Endpoint, oder via Webhook-Callback?
|
||||
|
||||
---
|
||||
|
||||
## 4. Core- und Modulgrenzen
|
||||
|
||||
1. Was gehört verbindlich in den Core, was in Service-Module, was in Integrationsmodule? (Aktuelle Liste in `module-structure-v0.1.md` ist unvollständig.)
|
||||
2. Wo lebt Billing architektonisch? Im Core (Daten heute dort), als Service-Modul, als Adapter-Verbund?
|
||||
3. Wo lebt das Customer Portal? Service-Modul oder eigenes UI-Modul?
|
||||
4. Wie ist ein Modul technisch verpackt – Composer-Package, in-app Namespace, Nwidart-Modul, anderes?
|
||||
5. Wie kommunizieren Module untereinander: Events, Service-Contracts, beides?
|
||||
6. Wie wird die Modul↔Core-API versioniert? Wie deklariert ein Modul seine Core-API-Mindestversion?
|
||||
7. Was passiert bei Modul-Deinstallation mit existierenden Datenreferenzen?
|
||||
8. Wie sind Modul-Migrationen mit Core-Migrationen verzahnt?
|
||||
9. Wer ist „Owner" jeder Entität (Aggregate Root)? Insbesondere: Wer besitzt `Rechnung` – Billing-Modul oder Core?
|
||||
10. Wie wird ein generisches External-Reference-Pattern eingeführt, ohne die heutigen anbieter-spezifischen Felder zu zementieren?
|
||||
|
||||
---
|
||||
|
||||
## 5. Sicherheit und Compliance
|
||||
|
||||
1. Wie werden Registrar-/Provider-API-Credentials gespeichert? Externer Vault, eigenes Verschlüsselungsschema, KMS, HSM?
|
||||
2. Wer ist GoBD-Verantwortlicher für Rechnungen – Hosting-Backoffice oder das externe Billing-System (Lexware/Invoice Ninja)?
|
||||
3. Falls Hosting-Backoffice GoBD-Verantwortlicher ist: Welcher Mechanismus garantiert Unveränderbarkeit nach Festschreibung?
|
||||
4. Wie wird DSGVO-Auskunft pro Endkunde umgesetzt (vollständiger Datenexport in maschinenlesbarer Form)?
|
||||
5. Wie wird DSGVO-Löschung pro Endkunde umgesetzt, ohne GoBD-Retention zu verletzen (Pseudonymisierung)?
|
||||
6. Wer ist Auftragsverarbeiter zwischen Plattformbetreiber und Mandant (DPA)? Wie ist die Beziehung Mandant↔Endkunde geregelt?
|
||||
7. Welche Subprozessoren werden eingesetzt (insbesondere KI-Provider, Mail-Versand, Hosting-Region, Backup-Region)?
|
||||
8. Wo werden Audit-Logs gespeichert, und wie wird ihre Integrität garantiert?
|
||||
9. Welche Authentication-Faktoren werden unterstützt (Password, 2FA, WebAuthn)? Pflicht für Admins?
|
||||
10. Welche Session-Strategie (Lifetime, Idle-Timeout, Refresh, Revocation)?
|
||||
11. Wie wird Datenresidenz garantiert („europäisch" auf welcher Ebene: Hosting, DB, Backup, Subprozessoren)?
|
||||
12. Wer haftet bei kompromittierten Registrar-Credentials? Welche technischen Maßnahmen reduzieren das Risiko?
|
||||
13. Welche AGB-/Widerrufs-Mechanismen werden bei Customer Portal benötigt?
|
||||
14. Ist BFSG/Barrierefreiheit für das Customer Portal relevant (EU-Verordnung seit 28.06.2025)?
|
||||
|
||||
---
|
||||
|
||||
## 6. Integrationen
|
||||
|
||||
1. Wie ist der formale Adapter-Contract definiert (Interface-Methoden, Fehler-Schema, Auth, Idempotenz)?
|
||||
2. Wie werden Adapter-Fehler behandelt (Retry, Backoff, Circuit Breaker, Dead Letter)?
|
||||
3. Wie wird inkonsistenter Zustand zwischen Core und externem System aufgelöst (Reconciliation, manueller Eingriff)?
|
||||
4. Wie werden Adapter-Konfigurationen pro Mandant verwaltet (Mandant A nutzt Lexware, Mandant B Invoice Ninja)?
|
||||
5. Was ist die Bedeutung von „Zahlungsart PayPal/Wero": reine Statusanzeige oder echte Integration?
|
||||
6. Wie wird SEPA-Lastschrift modelliert (Mandate, UMR, Pre-Notification, IBAN-Verschlüsselung)?
|
||||
7. Welche Steuer-/MwSt-Logik liegt im System, welche im Billing-Adapter?
|
||||
8. Was passiert bei Modul-Updates eines Adapters mit nicht-rückwärtskompatiblen Änderungen?
|
||||
9. Wie wird Mail-Versand (SMTP/Transactional) als eigene Integration gehandhabt? Welcher Anbieter? SPF/DKIM/DMARC-Strategie?
|
||||
|
||||
---
|
||||
|
||||
## 7. WordPress-Plugin
|
||||
|
||||
1. Welche Auth-Brücke zwischen WordPress und Hosting-Backoffice? OAuth2 Client Credentials? App-Token pro Mandant? Endkunden-Delegation?
|
||||
2. Speichert das Plugin Daten lokal in WordPress (Sync-Risiko) oder ist es reiner API-Konsument?
|
||||
3. Wie wird WP-User-Identität auf Backoffice-User-Identität gemappt?
|
||||
4. Wie ist das Plugin-Update-Lifecycle (eigener Auto-Updater, WordPress.org-Repository, privates Repo)?
|
||||
5. Welche API-Scopes erhält das Plugin? Was passiert bei kompromittierter WP-Site?
|
||||
6. Wer ist Mandant aus Sicht der API, wenn ein WP-User klickt – der WP-Site-Betreiber oder der endgültige Endkunde?
|
||||
7. Welche Caching-/Stale-Data-Strategie hat das Plugin gegenüber der API?
|
||||
|
||||
---
|
||||
|
||||
## 8. KI-Assistent
|
||||
|
||||
1. Bleibt KI in V1 oder rückt es in V2 (Empfehlung: V2)?
|
||||
2. Welcher KI-Provider? OpenAI, Anthropic, Mistral, lokal?
|
||||
3. Wenn US-basierter Provider: DPA, SCC, Drittlandtransfer-Risikobewertung?
|
||||
4. Welche Daten gehen an die KI – Inhalte oder nur Metadaten? Auf welcher Datenklassifikation basiert das?
|
||||
5. Wie wird Endkunden-Zustimmung eingeholt, falls Support-Tickets KI-verarbeitet werden?
|
||||
6. Wie werden Halluzinationen kontrolliert (Mensch-im-Loop, Confidence-Schwellen, Quellen-Citation)?
|
||||
7. Wer haftet bei falschen KI-Vorschlägen (insbesondere bei Rechnungs-/Vertragsdaten)?
|
||||
8. Wie wird KI-Output protokolliert und auditiert?
|
||||
|
||||
---
|
||||
|
||||
## 9. V1-Scope
|
||||
|
||||
1. Endgültige V1-Kundenzahl: 1–50 oder 1–500? (Empfehlung: 1–50, Roadmap-Wert)
|
||||
2. Kundenportal in V1 oder V2? (Empfehlung: V2)
|
||||
3. KI-Assistent in V1 oder V2? (Empfehlung: V2)
|
||||
4. SEPA-Lastschrift in V1 oder V2? (Empfehlung: V2 oder vollständiges Modell jetzt)
|
||||
5. PayPal/Wero in V1: reine Anzeige oder Integration?
|
||||
6. Welche Mahnwesen-Funktionalität ist V1-Minimum (Status „überfällig" + manuelle Mail)?
|
||||
7. Welche Tax-/MwSt-Funktionalität ist V1-Minimum?
|
||||
8. Welche DSGVO-Funktionen sind V1-Pflicht (Auskunft, Löschung, Datenportabilität)?
|
||||
9. Welche Backup-/Restore-Funktion ist V1-Pflicht?
|
||||
|
||||
---
|
||||
|
||||
## 10. Deployment und Operations
|
||||
|
||||
1. Self-hosted-only oder SaaS-Variante geplant? Welcher Mix?
|
||||
2. Welche PHP-Version? Welche Laravel-Version?
|
||||
3. Welcher Queue-Driver in V1 (Database, Redis)?
|
||||
4. Welche Backup-Strategie pro Mandant?
|
||||
5. Welche Disaster-Recovery-Strategie?
|
||||
6. Welche Logging-/Monitoring-Tools (Sentry, Loki, Grafana, Telemetry-Provider)?
|
||||
7. Welcher CI/CD-Stack?
|
||||
8. Welche Update-/Migration-Strategie auf Kundensystemen (bei Self-hosted)?
|
||||
9. Welche Update-Strategie für Module unabhängig vom Core?
|
||||
|
||||
---
|
||||
|
||||
## 11. Lizenz und Geschäftsmodell
|
||||
|
||||
1. Welche Open-Source-Lizenz, oder Closed-Source?
|
||||
2. Welche kommerzielle Lizenz für Mandanten?
|
||||
3. Werden Module einzeln verkauft, oder als Bundle?
|
||||
4. Wer darf Module von Drittanbietern entwickeln und verteilen?
|
||||
5. Wie wird das Versprechen „europäisch" geschäftlich umgesetzt (Hosting-Region, Subprozessoren, Vertragsrecht)?
|
||||
|
||||
---
|
||||
|
||||
Diese Liste ist nicht vollständig, aber priorisiert. Die Punkte unter 1, 2, 4 und 5 sind harte Blocker für Codebeginn. Die übrigen können in v0.2 oder begleitend zur ersten Implementierungsphase entschieden werden.
|
||||
Reference in New Issue
Block a user