Add AI workspace reviews

architecture/api-strategy-v0.1.md

@@ -0,0 +1,47 @@
+# API Strategy v0.1
+
+## Grundprinzip
+
+Hosting-Backoffice ist API-first aufgebaut.
+
+Alle Module und spätere Erweiterungen sollen über definierte API- und Service-Schnittstellen kommunizieren.
+
+## API-Typ
+
+V1: REST API
+
+Später möglich:
+- GraphQL
+- interne Service-Bus-Strukturen
+- Webhooks
+
+## API-Bereiche
+
+- Kunden
+- Verträge
+- Domains
+- Hostingpakete
+- Rechnungen
+- Tickets
+- Dokumente
+- Server
+- Integrationen
+
+## API-Sicherheit
+
+Alle API-Zugriffe benötigen:
+- Authentifizierung
+- Rechteprüfung
+- Auditierbarkeit
+- Rate-Limiting
+- Logging
+
+## Versionierung
+
+Beispiel:
+- /api/v1/
+- /api/v2/
+
+## WordPress-Plugin
+
+Das spätere WordPress-Plugin nutzt ausschließlich die REST API. Keine direkte Datenbankkopplung.

architecture/api-strategy-v0.2.md

@@ -0,0 +1,91 @@
+# API Strategy v0.2
+
+## Zweck
+Dieses Dokument konkretisiert API-first nach dem Architekturreview.
+
+## Kurz erklärt
+API-first bedeutet:
+
+```text
+Die Schnittstelle wird als Vertrag geplant,
+nicht nachträglich aus Controllern abgeleitet.
+```
+
+## Entscheidung
+V1 verwendet REST API mit OpenAPI 3.x als Spezifikation.
+
+## OpenAPI
+OpenAPI ist eine maschinenlesbare Beschreibung der API.
+
+Sie definiert:
+
+- Endpoints
+- Datenformate
+- Auth
+- Fehler
+- Parameter
+- Responses
+
+## API-Konventionen
+
+### Versionierung
+
+```text
+/api/v1/
+```
+
+### Pagination
+Cursor Pagination wird bevorzugt.
+
+### Fehlerformat
+Problem Details nach RFC 7807 wird als Zielmodell verwendet.
+
+### Idempotenz
+Für kritische POST-Vorgänge wird ein Idempotency-Key vorbereitet.
+
+Idempotenz bedeutet:
+
+```text
+Ein Vorgang kann mehrfach gesendet werden,
+ohne mehrfach ausgeführt zu werden.
+```
+
+### Filtering
+
+```text
+filter[status]=active
+filter[customer_id]=123
+```
+
+### Sorting
+
+```text
+sort=-created_at
+```
+
+## Auth
+V1 nutzt Laravel Sanctum gemäß ADR 0006.
+
+## Long Running Jobs
+Lange Vorgänge laufen asynchron.
+
+Beispiele:
+
+- große Importe
+- Syncs
+- spätere Migrationen
+
+Sie erhalten Job-Status-Endpunkte.
+
+## Webhooks
+Webhooks sind nicht V1-Pflicht, werden aber architektonisch vorbereitet.
+
+Webhook bedeutet:
+
+```text
+Das System informiert andere Systeme automatisch,
+wenn ein Ereignis passiert.
+```
+
+## Nächster Schritt
+OpenAPI-Stub für V1 erstellen.

architecture/core-architecture-v0.1.md

@@ -0,0 +1,44 @@
+# Core Architecture v0.1
+
+## Grundarchitektur
+
+Hosting-Backoffice basiert auf einem modularen Standalone-Core mit REST API.
+
+Die Plattform soll modular erweiterbar, kundenzentriert, API-first, mandantenfähig vorbereitbar, sicher und verständlich sein.
+
+## Technologischer Ansatz
+
+- Backend: Laravel
+- API: REST API
+- Datenbank: MariaDB oder PostgreSQL
+- Frontend: Laravel Blade oder später Vue/Nuxt
+- Integrationen: modular angebunden, niemals direkt im Core verdrahten
+
+## Architekturprinzip
+
+Der Core enthält ausschließlich zentrale Datenobjekte und Kernlogik.
+
+Externe Systeme werden über Module/Integrationen angebunden.
+
+## Core-Module
+
+- Benutzer & Rechte
+- Kunden
+- Verträge
+- Produkte
+- Domains
+- Hostingpakete
+- Server
+- Dokumente
+- Audit-Logs
+- Benachrichtigungen
+- API
+- Einstellungen
+
+## Integrationsprinzip
+
+Der Core kennt keine direkte Anbieterlogik.
+
+Nicht: Customer → direkt Lexware
+
+Sondern: Customer → Billing Interface → Lexware Modul

architecture/core-architecture-v0.2.md

@@ -0,0 +1,72 @@
+# Core Architecture v0.2
+
+## Zweck
+Dieses Dokument ersetzt die bisherige Core-Definition aus v0.1.
+
+## Wichtigste Änderung
+Der Core wird deutlich verkleinert.
+
+In v0.1 war der Core zu groß und enthielt zu viele Fachdomänen.
+
+## Core enthält nur noch
+
+- Identity
+- Authentication
+- Tenant Context
+- RBAC / Policies
+- Audit Base
+- Module Registry
+- Settings Base
+- Event Routing
+- API Base
+- System Health
+
+## Core enthält nicht
+
+- Kundenfachlogik
+- Vertragsfachlogik
+- Produktfachlogik
+- Domainfachlogik
+- Hostingfachlogik
+- Billingfachlogik
+- Ticketfachlogik
+- Dokumentenarchivfachlogik
+- Integrationslogik
+
+## Service-Module
+
+- Customers
+- Contracts
+- Products
+- Domains
+- Hosting
+- Billing
+- Tickets
+- Documents
+- Notifications
+
+## Integrationsmodule
+
+- KeyHelp
+- 1blu
+- Lexware
+- Invoice Ninja
+- SMTP/Transactional Mail später
+- Payment-Adapter später
+
+## Grundregel
+
+Wenn ein Bereich fachliche Geschäftslogik enthält, gehört er nicht in den Core.
+
+## Kommunikation
+
+Module kommunizieren über:
+
+- Service Contracts
+- Events
+- API-Schichten
+- External References
+
+## Ziel
+
+Der Core soll stabil bleiben, auch wenn Fachmodule wachsen oder ersetzt werden.

architecture/data-model-v0.1.md

@@ -0,0 +1,96 @@
+# Data Model v0.1
+
+## Grundprinzip
+
+Hosting-Backoffice ist kundenzentriert aufgebaut.
+
+Der Kunde ist das zentrale Objekt.
+
+## Hauptobjekte
+
+### Kunde
+- Stammdaten
+- Ansprechpartner
+- Kontaktdaten
+- Kundennummer
+- Status
+- Historie
+
+### Vertrag
+- Vertragsnummer
+- Laufzeiten
+- Kündigungsstatus
+- Abrechnungsmodell
+- Produktreferenzen
+
+### Produkt
+- Produktname
+- Beschreibung
+- Preis
+- Abrechnungsintervall
+- Status
+
+### Domain
+- Domainname
+- TLD
+- Registrar
+- Registrar-Account
+- Laufzeiten
+- Status
+
+### Registrar-Account
+- Anbieter
+- Accountbeschreibung
+- Zugangsdaten/API-Referenzen
+- Status
+
+### Hostingpaket
+- Paketname
+- Serverzuordnung
+- Ressourcen
+- Status
+
+### Server
+- Hostname
+- Rolle
+- Provider
+- KeyHelp-Referenz
+- Status
+
+### Rechnung
+- Rechnungsnummer
+- Rechnungsdatum
+- Betrag
+- Zahlungsstatus
+- externes System
+
+### Zahlung
+- Zahlungsart
+- Status
+- externe Referenzen
+- Gebührenregeln später möglich
+
+### Ticket
+- Status
+- Priorität
+- Verlauf
+- interne Notizen
+
+### Dokument
+- Datei
+- Hashes
+- Archivinformationen
+- Referenzen
+
+### Audit-Log
+- Benutzer
+- Aktion
+- Zeitstempel
+- Objektbezug
+- Änderungshistorie
+
+## Mandantenfähigkeit
+
+Von Anfang an vorbereiten:
+- organisation_id
+- tenant_id

architecture/data-model-v0.2-direction.md

@@ -0,0 +1,78 @@
+# Data Model v0.2 — Korrekturrichtung
+
+## Zweck
+Dieses Dokument beschreibt die Richtung für das überarbeitete Datenmodell v0.2.
+
+## Hauptänderungen gegenüber v0.1
+
+- `organisation_id` wird entfernt bzw. nicht standardmäßig verwendet
+- `tenant_id` wird zentrale Mandantenreferenz
+- anbieter-spezifische Felder werden entfernt
+- External References werden eingeführt
+- Kunde wird in Customer / Party / Address / ContactPoint aufgeteilt
+- Billing wird eigene Domäne
+- Core wird fachlich verkleinert
+
+## Zentrale Tabellenbereiche
+
+### Core
+- tenants
+- users
+- roles
+- permissions
+- module_registry
+- audit_logs
+- settings
+- external_references
+- secrets_references
+
+### Customer Module
+- customers
+- parties
+- addresses
+- contact_points
+- customer_contacts
+
+### Contract Module
+- contracts
+- contract_items
+- contract_status_history
+
+### Product Module
+- products
+- product_prices
+- product_tax_metadata
+
+### Domain Module
+- domains
+- domain_status_history
+- registrar_accounts
+
+### Hosting Module
+- hosting_packages
+- servers
+- hosting_assignments
+- hosting_status_history
+
+### Billing Module
+- invoice_references
+- payment_references
+- billing_accounts
+- payment_methods
+
+### Ticket Module
+- tickets
+- ticket_messages
+- ticket_notes
+- ticket_status_history
+
+### Document Module
+- documents
+- document_hashes
+- document_links
+
+## Wichtig
+Dieses Dokument ist noch kein vollständiges ER-Modell.
+
+Nächster Schritt:
+- ER-Modell mit Beziehungen und Kardinalitäten erstellen.

architecture/deployment-strategy-v0.1.md

@@ -0,0 +1,32 @@
+# Deployment Strategy v0.1
+
+## Grundprinzip
+
+Hosting-Backoffice soll sicher, reproduzierbar und verständlich installiert werden können.
+
+## V1-Ansatz
+
+- Laravel-Anwendung
+- Webserver mit PHP
+- MariaDB oder PostgreSQL
+- Composer
+- Queue optional
+- Cron/Scheduler
+
+## Später möglich
+
+- Docker-Deployment
+- SaaS-Variante
+- Installer
+- Update-System
+- Systemchecks
+
+## Sicherheitsprinzip
+
+Produktivsysteme dürfen nicht direkt durch KI-Agenten verändert werden.
+
+Änderungen laufen über:
+- Entwicklungsumgebung
+- Tests
+- Review
+- kontrolliertes Deployment

architecture/gobd-archive-strategy-v0.1.md

@@ -0,0 +1,41 @@
+# GoBD & Archive Strategy v0.1
+
+## Grundprinzip
+
+Dokumente und relevante Änderungen sollen nachvollziehbar und revisionsfreundlich gespeichert werden.
+
+## Ziele
+
+Das System soll:
+- PDFs archivieren
+- Änderungen nachvollziehbar machen
+- Auditinformationen speichern
+- Dokumente referenzieren
+- Hash-Prüfungen ermöglichen
+
+## Dokumenttypen
+
+- Rechnungen
+- Vertragsdokumente
+- Anhänge
+- Supportdokumente
+- Importdateien
+
+## V1
+
+- PDFs speichern
+- Hashes speichern
+- Audit-Logs schreiben
+- Archivmetadaten speichern
+
+## Später möglich
+
+- WORM-Speicher
+- S3 Object Lock
+- externe Archivsysteme
+- Langzeitarchivierung
+- Signaturprüfungen
+
+## Wichtig
+
+Hosting-Backoffice ist zunächst kein vollständiges DMS oder Buchhaltungssystem.

architecture/hosting-strategy-v0.1.md

@@ -0,0 +1,51 @@
+# Hosting Strategy v0.1
+
+## Grundprinzip
+
+Hosting-Backoffice ist kundenzentriert aufgebaut.
+
+Server, Domains und Hostingpakete werden zentral verwaltet.
+
+## Hostingbereiche
+
+### Hostingpakete
+- Zuordnung zu Kunden
+- Zuordnung zu Servern
+- Status
+- Ressourcen später möglich
+
+### Domains
+- Registrar-Zuordnung
+- Laufzeiten
+- Status
+- Kundenzuordnung
+
+### Server
+- zentrale Serverobjekte
+- Rollen später möglich
+- KeyHelp-Referenzen
+
+## V1
+
+Unterstützt:
+- KeyHelp
+- 1blu Business
+
+## Registrarstrategie
+
+V1:
+- Import
+- manuelle Zuordnung
+- mehrere Accounts
+
+Später:
+- API-Synchronisation
+- mehrere Registrare
+- TLD-Regeln
+- Registrarrouting
+
+## Nicht Teil von V1
+
+- automatische Provisionierung
+- VM-Orchestrierung
+- Cloudmanagement

architecture/integration-adapter-pattern-v0.1.md

@@ -0,0 +1,38 @@
+# Integration Adapter Pattern v0.1
+
+## Grundprinzip
+
+Externe Anbieter werden über Adapter angebunden.
+
+Der Core kennt keine direkte Anbieterlogik.
+
+## Beispiel
+
+Nicht:
+- Kunde → direkt Lexware
+
+Sondern:
+- Kunde → Billing Interface → Lexware Adapter
+
+## Adapterbereiche
+
+- Billing Adapter
+- Registrar Adapter
+- Hosting Panel Adapter
+- Payment Reference Adapter
+- Notification Adapter
+
+## Vorteile
+
+- Anbieter austauschbar
+- Core bleibt stabil
+- Module sind testbar
+- spätere Erweiterungen werden einfacher
+
+## Anforderungen an Adapter
+
+- definierte Interfaces
+- Fehlerbehandlung
+- Logging
+- Auditierbarkeit bei kritischen Aktionen
+- sichere Speicherung von Zugangsdaten

architecture/logging-monitoring-strategy-v0.1.md

@@ -0,0 +1,34 @@
+# Logging & Monitoring Strategy v0.1
+
+## Grundprinzip
+
+Alle wichtigen Aktionen sollen nachvollziehbar sein.
+
+Das System soll Fehler erkennen, Änderungen protokollieren und Systemzustände überwachen können.
+
+## Logging
+
+Geplant:
+- Login-Logs
+- API-Logs
+- Import-Logs
+- Fehler-Logs
+- Ticketaktionen
+- Benutzeraktionen
+
+## Audit-Logs
+
+Audit-Logs sind getrennt von technischen Logs.
+
+Sie dienen Nachvollziehbarkeit, Compliance und Archivierung.
+
+## Monitoring später
+
+- Serverstatus
+- API-Status
+- Integrationsstatus
+- Benachrichtigungen
+
+## Sicherheitsprinzip
+
+Logs dürfen nicht manipulierbar sein und müssen nachvollziehbar, filterbar und geschützt gespeichert werden.

architecture/module-structure-v0.2.md

@@ -0,0 +1,65 @@
+# Module Structure v0.2
+
+## Zweck
+Dieses Dokument ersetzt die Modulstruktur v0.1 als verbindliche Modulübersicht.
+
+## Core
+- Identity
+- Authentication
+- Tenancy
+- RBAC
+- Audit Base
+- Module Registry
+- Settings Base
+- Event Routing
+- API Base
+
+## Service-Module
+
+### Customers
+Kunden, Parteien, Adressen, Kontakte.
+
+### Contracts
+Verträge, Laufzeiten, Vertragspositionen.
+
+### Products
+Produkte, Leistungen, Preise, Steuer-Metadaten.
+
+### Domains
+Domains, TLD, Status, Registrar-Zuordnung.
+
+### Hosting
+Hostingpakete, Server, Zuordnungen.
+
+### Billing
+Rechnungsreferenzen, Zahlungsreferenzen, externe Billing-Konten.
+
+### Tickets
+Tickets, Antworten, interne Notizen, Status.
+
+### Documents
+PDFs, Anhänge, Hashes, Dokumentenverknüpfungen.
+
+### Notifications
+Benachrichtigungsrouting und spätere Kanäle.
+
+## Integrationsmodule
+
+### KeyHelp Adapter
+Verbindung zu KeyHelp.
+
+### 1blu Adapter
+Import und spätere Synchronisation.
+
+### Lexware Adapter
+Billing-Referenzen und spätere Synchronisation.
+
+### Invoice Ninja Adapter
+Alternative Billing-Anbindung.
+
+## Nicht V1
+- AI Assistant
+- WordPress Plugin
+- Customer Portal
+- Plesk/cPanel
+- Cloud Provisioning

architecture/multi-tenancy-strategy-v0.1.md

@@ -0,0 +1,30 @@
+# Multi-Tenancy Strategy v0.1
+
+## Grundprinzip
+
+Mandantenfähigkeit wird von Anfang an architektonisch vorbereitet.
+
+V1 bleibt zunächst einfach nutzbar, spätere Multi-Tenant- und Resellerstrukturen sollen jedoch möglich bleiben.
+
+## Ziele
+
+Das System soll später ermöglichen:
+- mehrere Organisationen
+- Reseller
+- getrennte Kundenbereiche
+- Datenisolation
+- Rechteisolation
+
+## Architekturprinzip
+
+Alle zentralen Objekte sollen vorbereitet sein für:
+- organisation_id
+- tenant_id
+
+## V1
+
+V1 arbeitet zunächst primär als Single-Tenant-System. Die Datenstruktur bleibt vorbereitet.
+
+## Sicherheitsprinzip
+
+Mandanten dürfen niemals auf fremde Daten zugreifen können.

architecture/notification-strategy-v0.1.md

@@ -0,0 +1,29 @@
+# Notification Strategy v0.1
+
+## Grundprinzip
+
+Benachrichtigungen sollen Kunden und Administratoren über relevante Ereignisse informieren.
+
+## V1-Benachrichtigungen
+
+- Ticket erstellt
+- Ticket beantwortet
+- Rechnungsstatus geändert
+- Domainlaufzeit-Hinweis später
+- Import abgeschlossen
+- kritische Systemereignisse
+
+## Kanäle
+
+V1:
+- E-Mail
+- interne Systemmeldungen
+
+Später:
+- Webhooks
+- Kundenportal-Benachrichtigungen
+- optionale Messenger-/Push-Systeme
+
+## Architektur
+
+Benachrichtigungen sollen über ein zentrales Notification-System laufen, nicht direkt aus einzelnen Modulen heraus hart verdrahtet werden.

architecture/payment-policy-v0.1.md

@@ -0,0 +1,28 @@
+# Payment Policy v0.1
+
+## Grundprinzip
+
+Hosting-Backoffice ist kein Payment-Service-Provider und kein Banking-System.
+
+Das System verwaltet Zahlungsarten, Status, Hinweise und externe Referenzen.
+
+## Zahlungsarten V1
+
+- Rechnung
+- Überweisung
+- Lastschrift
+- PayPal
+- Wero
+
+## Gebührenregeln
+
+Später sollen Zahlungsarten mit Regeln versehen werden können:
+- bevorzugte Zahlungsart
+- Hinweistext
+- mögliche Zusatzgebühr
+- rechtlicher Hinweis
+- Aktivierung je Kunde oder Produkt
+
+## Rechtlicher Hinweis
+
+Gebühren für Zahlungsarten müssen rechtlich geprüft werden. Die Software soll Konfiguration ermöglichen, aber keine pauschalen rechtlichen Annahmen hart einbauen.

architecture/security-and-rights-v0.1.md

@@ -0,0 +1,49 @@
+# Security & Rights Model v0.1
+
+## Grundprinzip
+
+Hosting-Backoffice ist ein kundenzentriertes System mit sensiblen Daten.
+
+Sicherheit, Nachvollziehbarkeit und Rechtekontrolle haben hohe Priorität.
+
+## Benutzerrollen V1
+
+### Superadmin
+Vollzugriff auf Systemeinstellungen, Module, Benutzer, Server, Integrationen und Auditdaten.
+
+### Administrator
+Zugriff auf Kunden, Verträge, Domains, Tickets, Rechnungsreferenzen und Hostingpakete.
+
+### Support-Mitarbeiter
+Zugriff auf Tickets, Kundeninformationen und Hostingstatus. Kein Zugriff auf kritische Einstellungen.
+
+### Kunde
+Zugriff ausschließlich auf eigene Verträge, Domains, Rechnungen, Tickets und Dokumente.
+
+## API-Sicherheit
+
+- Authentifizierung
+- Rechteprüfung
+- Auditierung
+- Tokenbasierte API
+- später OAuth/Sanctum möglich
+
+## Audit-Logs
+
+Alle kritischen Aktionen sollen protokolliert werden.
+
+Beispiele:
+- Loginversuche
+- Änderungen
+- Löschungen
+- Ticketaktionen
+- Domainänderungen
+- Benutzerrechte
+- Importvorgänge
+
+## Mandantenfähigkeit
+
+- tenant_id / organisation_id
+- Datenisolation
+- Rechteisolation
+- spätere Resellerfähigkeit

architecture/security-and-rights-v0.2.md

@@ -0,0 +1,47 @@
+# Security & Rights Model v0.2
+
+## Zweck
+Dieses Dokument ergänzt das Sicherheitsmodell um konkrete Entscheidungen aus den ADRs.
+
+## Zentrale Sicherheitsentscheidungen
+
+- tenant_id als Mandantenkontext
+- PostgreSQL als Datenbank
+- Laravel Sanctum als Auth-Basis
+- Secrets nicht in Fachtabellen speichern
+- Audit-Logs append-only
+- API-Zugriffe auditierbar
+- Plugin-Scopes später minimal halten
+
+## Rollen V1
+
+### Superadmin
+Systemweiter Zugriff, aber alle mandantenübergreifenden Aktionen werden auditierbar.
+
+### Tenant Admin
+Verwaltet den eigenen Mandanten.
+
+### Staff / Support
+Bearbeitet Kunden, Tickets und operative Daten innerhalb eines Mandanten.
+
+### Kunde
+Nicht V1, erst Customer Portal V2.
+
+## Tenant-Isolation
+Alle mandantenbezogenen Daten benötigen:
+
+- tenant_id
+- Policy-Prüfung
+- Query-Scope
+- Tests gegen Tenant-Leaks
+
+## Secrets
+Secrets werden nur über einen Secret-Service gelesen/geschrieben.
+
+## Audit
+Kritische Aktionen werden in Audit-Logs erfasst.
+
+## Offene Punkte
+- genaue MFA-Pflicht
+- Impersonation-Regeln
+- RLS-Umsetzung im Detail