Roadmap

The concrete build plan for the next KALYIX stages

This page is no longer about the general why. It is about sequence. V1 remains visible as a legacy build. V2 is the active path. What matters here is what gets built first, what becomes productive after that, and what only makes sense in a later stage.

V1 legacy

The current state stays available through its own V1 page

V1 shows where KALYIX comes from technically: Tauri + React as the interface, a Python daemon for runtime logic, and a workflow that stays very close to OBS and browser output. It remains visible for reference and testing, but it is no longer the base for the next rebuild step. The app itself is available in German only.

Tauri/React interface with a separate Python daemon as the runtime center
Rust handles capture and preview, while OBS runs through WebSocket and browser output
HTML, URL, and browser source are effectively part of the runtime path
the V1 app itself remains German-only

Open the V1 page

If you want to see how KALYIX started, V1 still matters. If you want to see where it is going now, V2 is the real reference point.

Active focus

This roadmap looks at what is actually being built next

V2 no longer grows inside one desktop repo. It is being built as a separated Rust workspace with shell, module, runtime, integration, and output crates. That separation is the real technical cut from V1.

apps/ for shell hosts and entry points, crates/ui/* for shell and modules
crates/runtime/* for core, editor runtime, integrations, and output backends
its own shell, core runtime, and OverlayDocument instead of a webview and HTML center

Read about V2

If you want the product vision behind the rebuild, the About V2 page is the better place. This roadmap deliberately stays on the build plan.

Active development path

How V2 gets built step by step

Each stage should leave behind something tangible. That is why the roadmap is not a loose wishlist. It is a sequence of stages, each with a clear result.

Step 1

Core runtime, OverlayDocument, and preview

This is where the real foundation sits: event bus, state store, command dispatcher, alert lifecycle skeleton, OverlayDocument with schema_version, snapshot stream, and preview output. Nothing else is worth stacking on top until that is stable.

OverlayDocument becomes the single source of truth instead of HTML
the UI reads snapshots and sends commands, but does not own runtime state
the first deterministic chain is: Twitch -> trigger -> state -> preview

Step 2

Connect Twitch, OBS, and output adapters cleanly

Once the base exists, the real integrations land on top. Twitch and triggers feed useful events into the core event bus. OBS is then split on purpose into two parts: a control adapter and an overlay output adapter.

Twitch events are normalized and translated into deterministic alert lifecycles
OBS control and OBS overlay output stay as separate adapters instead of hidden core logic
preview and OBS pull the same runtime representation from the same source

Step 3

Native shell, own output, and later encoding

Only in the third stage does KALYIX move further out of compatibility mode. That is where the native shell path, native output backends, its own render paths, and later the encoder and recording flow come into focus.

the shell host moves to its own Rust stack with a GPU-first direction
profiles such as full_studio, editor_only, and stream_only become technically meaningful
OBS turns into a replaceable adapter instead of a permanent requirement

Technical view of V1 and V2

V1 today

V1 currently exists as KALYIX Control with a Tauri and React interface plus a separate Python daemon. The UI lives in the frontend, the daemon carries runtime logic, OBS control, and event flows, while Rust handles capture and preview.

Overlays and alerts still think strongly in terms of browser output, URLs, and OBS browser sources. That is why the live truth is not held in one clean central place, but spread across several layers.

Why V1 ends there

It would be technically possible to keep building on that path. The problem is the direction: HTML, webview, and OBS-adjacent flows would sink deeper into the real product core with every new major feature.

For an editor that later has to carry preview, runtime, alerts, OBS, and its own output, that coupling is too tight. V1 therefore ends not because it lacks features, but because its architectural center is wrong for the next phase.

V2 stack today

V2 is already cut as a Rust workspace: apps for shell hosts and entry points, crates/ui for shell and modules, crates/runtime for core, editor runtime, integrations, and output backends. Separate legacy paths such as editor-ui-legacy and kalyix-desktop-legacy remain as references.

At the center are OverlayDocument as truth, commands, events, and snapshots as fixed contracts, plus a core runtime that can run without the UI.

V2 endgame

Long term, the active shell moves to its own native path with winit, wgpu, taffy, and cosmic-text. The shell host loads modules, activates only the runtimes that are actually needed, and can later start profiles such as full_studio, editor_only, or stream_only cleanly.

That becomes the base for native output, its own encoding and recording paths, Linux runtimes, and later distributed or external control paths. OBS still matters, but in the end it is only an adapter, not the center anymore.