I have been thinking a lot about how Vix.cpp should grow without becoming another heavy C system. One mistake I want to avoid is putting every useful library directly inside Vix Core. It would feel convenient at the beginning, but after some time the core would become harder to maintain, harder to release, and harder to trust. A runtime should not become a container for every idea we have. That is why I decided to keep a clear separation. Vix will remain the runtime and developer toolkit: build, run, packages, project structure, modules, developer workflow. Rix will be the official public library layer around Vix, available through the registry and usable independently: ``` vix add rix/json vix add rix/http vix add rix/sqlite ``` For me, this is the right direction because it protects the stability of Vix while still allowing the ecosystem to grow. Rix can evolve faster, receive new libraries, improve existing ones, and serve application developers without forcing every change into the Vix core. This is not a migration away from Vix. It is a cleaner architecture around it. The goal is simple: keep Vix stable, keep the ecosystem useful, and make the separation obvious for developers. Core belongs to Vix. Reusable application libraries belong to Rix. That gives us a system that is easier to understand, easier to maintain, and easier to evolve over time.