Extensibility — bundled features are optional

Tech USP: The framework itself is lean. Login, sessions, notifications, audit trail, files, jobs are bundled building blocks (@kumiko/bundled-features), not mandatory.

What’s built in

@kumiko/framework provides the primitives:

• defineFeature(name, (r) => …) — feature registration
• r.entity / r.relation / r.writeHandler / r.queryHandler / r.projection / …
• r.hook("preSave"|"postSave"|"validation"|…, …) — lifecycle
• r.requires / r.optionalRequires — feature dependencies
• r.extendsRegistrar — add your own registration methods (5 levels: schema, hooks, search, UI, register)
• r.systemScope — cross-tenant features
• r.toggleable — feature-toggle integration
• r.authClaims — JWT claims from features
• r.screen / r.nav — UI primitives

Building blocks are replaceable

@kumiko/bundled-features provides default implementations for common needs, all built as normal features:

• Login (email + password) — bring your own auth
• Tenant + user — schema replaceable for special requirements
• Delivery + channels (in-app, email, push) — channels are a plugin API
• Jobs (BullMQ) — register your own job runner
• Audit, feature toggles, rate limiting, secrets, file provider (S3)

Hello-World comes without all of that.

Architecture deep dive

• registrar-extensions — r.extendsRegistrar() 5-level API
• feature-principles — “everything is a feature”, decoupling
• feature-integration — 6 communication paths

Where this lands in the pitch

• Both markets: “No bloat, no force. Build with what you need”
• Counter-argument vs “framework lock-in”: “Even the auth module is just a feature, you can fork it”