Core-First-Architektur
PayCal Core enthält die kanonische Domain- und Controller-Logik: Berechnungen, Validierung, Berechtigungen, Lifecycle-Richtlinien und gemeinsame API-Verträge.
Core bleibt absichtlich erweiterungsagnostisch. Integrationspunkte sind über Bridge-Verträge isoliert, damit Core-Dienste unabhängig von runtime-spezifischen Paketen getestet werden können.
Grundlegende Erweiterungen in diesem Repository
Dieses Repository liefert grundlegende Erweiterungsimplementierungen, die Standardverhalten für Erweiterungsnähte bereitstellen. Sie dienen als öffentliche Referenzpakete und sichere Defaults für selbst gehostete Bereitstellungen.
- billing-provider: Basishooks für Abrechnungsfunktionen und Modusauswahl
- earnings-ytd: Baseline für YTD-Darstellung und Earnings-Hooks
- organization-signals: Basishooks für Organisationssignale
Modell für Drittanbieter-Erweiterungen
Drittanbieter können mit diesem Repository eigene Erweiterungspakete erstellen und pflegen. Das erwartete Modell ist:
- Core-Logik möglichst unverändert lassen
- Benutzerdefiniertes Verhalten in Erweiterungspaketen implementieren
- Eigene Pakete über dokumentierte Bootstrap- und Hook-Nähte anbinden
- Core-Verträge bewahren, damit Upgrades beherrschbar bleiben
So sind wettbewerbs- und vertikalspezifische Bereitstellungen möglich, ohne langfristige Forks der Core-Domäne zu erzwingen.
Differenzierung von paycal.app
Die kanonische Plattform https://paycal.app betreibt private Erweiterungsvarianten auf derselben Core- und Basis-Erweiterungsarchitektur.
Diese privaten Varianten sind eine bewusste Differenzierungsschicht für von PayCal betriebene Umgebungen. Sie können Workflows, Capability-Verhalten und UI-spezifische Integrationen anpassen und gleichzeitig mit derselben Core-Architektur kompatibel bleiben.
- Core-Logik bleibt gemeinsam und prüfbar
- Öffentliche/basische Erweiterungen bleiben im Repository verfügbar
- Private Erweiterungen liefern die kanonische Plattformdifferenzierung
Transparenz-Zusagen
- Core-Verträge sind an Erweiterungsnähten dokumentiert und getestet
- Bridge-Grenzen sind explizit, damit Kopplung auffindbar bleibt
- Erweiterungsverhalten kann sich weiterentwickeln, ohne Core-Dienste zu destabilisieren
- Selbst gehostete Nutzer können alternative Erweiterungsstrategien bauen