Erweiterbarkeit — Bausteine sind optional

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

Was eingebaut ist

@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

@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

• registrar-extensions — r.extendsRegistrar() 5-Ebenen-API
• 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”