Erweiterbarkeit: Bausteine sind optional

Tech-USP: Das Framework selbst ist schlank. Login, Sessions, Benachrichtigungen, Änderungsprotokoll, Dateien, Jobs sind mitgelieferte Bausteine (@cosmicdrift/kumiko-bundled-features), keine Pflicht.

Was eingebaut ist

@cosmicdrift/kumiko-framework bietet die Primitiven:

• defineFeature(name, (r) => …): Feature-Registrierung
• r.entity / r.relation / r.writeHandler / r.queryHandler / r.projection / …
• r.hook("preSave"|"postSave"|"validation"|…, …): Lifecycle
• r.requires / r.optionalRequires: Feature-Dependencies
• r.extendsRegistrar: eigene Registrierungs-Methoden hinzufügen (5 Ebenen: Schema, Hooks, Search, UI, Register)
• r.systemScope: Cross-Tenant-Features
• r.toggleable: Feature-Toggle-Integration
• r.authClaims: JWT-Claims aus Features
• r.screen / r.nav: UI-Primitiven (M1 done)

Bausteine sind ersetzbar

@cosmicdrift/kumiko-bundled-features bietet Default-Implementierungen für gängige Bedürfnisse, alle als normale Features gebaut:

• Login (E-Mail + Passwort): Eigene Auth einbaubar
• Tenant + User: Schema austauschbar bei besonderen Anforderungen
• Delivery + Channels (in-app, E-Mail, Push): Channels sind Plugin-API
• Jobs (BullMQ): Eigener Job-Runner registrierbar
• Änderungsprotokoll, Feature-Toggles, Rate-Limiting, Secrets, Datei-Provider (S3)

Hello-World kommt ohne all das aus.

Architektur-Tiefendoku

• feature-principles: „Alles ist ein Feature”, Entkopplung
• feature-integration: 6 Kommunikations-Pfade
• ../../uebersicht.md Features-Section: Status aller bundled-features

Wo das im Pitch landet

• Beide Märkte: „Kein Bloat, kein Zwang. Ihr baut mit dem was Ihr braucht”
• Anti-Argument gegen „Framework-Lock-in”: „Auch das Auth-Modul ist nur ein Feature, könnt Ihr forken”