Repository navigation
Choose the end-to-end KELD experience to make real next #312
Description
Activity
Resolution
Choose the KELD-native vertical slice as the next product proof.
The next end-to-end experience should be:
system webview UI →
window.keld/ renderer bridge → authenticated KIPC → Rust host authorization → one real native capability → result back to the rendererThe first native capability should reuse the existing retained filesystem broker rather than inventing a new service.
Why this wins
- It proves KELD itself is a usable desktop framework, not only a runtime prototype.
- It connects several pieces that already exist but are currently isolated: native webview, Bun supervision, authenticated KIPC, guard enforcement, and the filesystem broker.
- It exposes KELD's core architectural differentiation in one observable workflow: JavaScript/TypeScript app code with native capability mediated by a Rust-owned authority boundary.
- It creates the foundation that a later Electron migration proof needs. Doing migration first would force compatibility work on top of a renderer/native path that is not yet generally live.
- Distribution remains important, but it is an enabling concern rather than the product proof itself. A smoother install path should support this slice once its required runtime boundary is clear.
Decision
Primary sequence: KELD-native vertical slice → Electron migration proof → broader developer distribution polish.
This does not authorize broad native APIs, full Electron compatibility, or unrelated framework expansion. The slice stays bounded to the smallest capability needed to demonstrate the architecture honestly.
Parent map: https://github.com/gyldlab/keld/issues/311
Question
What single end-to-end KELD product experience should exist next so a developer can understand the thesis, see real functionality, and distinguish working product from roadmap without requiring framework completeness?