The CMS moves out and Phlo becomes installable

Two things land together: the CMS splits into a package of its own, and the engine gains Composer support. That pairing is the point where Phlo stops being one codebase and starts being a platform.

The CMS grew inside the engine, which is understandable and eventually wrong. An admin interface is opinionated in ways a language runtime must not be: it decides what a list looks like, how a form is laid out, what a permission means. Every app inherits those opinions whether or not it wants an admin, and every change to them is a change to the engine.

Splitting it makes both halves honest. The engine keeps what is genuinely universal, the model layer and the field types, and the CMS becomes a thing you install when you want an admin. That is a relationship any product layer can have: mount it, extend what needs extending, leave the rest.

Composer support in the same breath is what makes that practical. A package needs a way to arrive, and this is also where the engine's own stance on dependencies is set: installable through Composer, and requiring nothing through Composer. Zero dependencies is not an aesthetic preference; it is what lets an app audit its entire tree in an afternoon.

The autoloader stays lazy, so an app that installs no packages never pays for one.