Versioning

Three things version separately, all with Semantic Versioning.

	The standard	The CLI	The Claude plugin
Current	5.8.0	0.18.0	5.8.0
Lives in	EIDOS.md, Buildable’s repository	The eidos binary, from the install script	The plugin beside the standard
A project records it as	eidos_version in Framework.yaml	a pin, when it has one, in .eidos/plugins/eidosmd/cli.yaml	not recorded
Moves when	the text of EIDOS.md moves	the tool ships	any plugin release ships
History	versions/	Releases	CHANGELOG.md

The tooling moves far more often than the standard. Each CLI and plugin release names the standard it carries; Standard: unchanged means your projects need nothing.

Which version am I on?

eidos framework          # the project's eidos_version
eidos --version          # the CLI, and the standard it carries
eidos version list       # the CLI versions on this machine, the one this folder runs and why, and the latest

eidos check reports a project on an older standard once, as a warning, and works with it as it stands. The framework in front of the tool is the operative contract either way.

Choosing the CLI version

Several versions of the CLI can sit side by side on one machine, and a project can pin the one everybody runs in it:

eidos version pin <version>     # this project runs <version>, written to .eidos/plugins/eidosmd/cli.yaml
eidos version use <version>     # your default everywhere else
eidos version update            # move the eidos on your PATH to the latest release

A command runs as EIDOS_USE_VERSION when it is set (for one shell or one CI job), else the project’s pin, else your default, else the eidos on your PATH. A version that is not on the machine yet is fetched once, checked against its published checksum. Commit cli.yaml and every teammate and every pipeline in the project runs the same CLI. Nothing moves anyone to a newer version unasked.

eidos version is the CLI’s own versions. A project’s versions, the names you give a commit of it, are eidos git version. Versions →

Migrating

Each release of the standard is frozen in versions/ under its full number. A migration goes directly from any source version to any target by diffing the two snapshots: v1.0.0 to v5.5.0 is one hop, not many.

eidos migrate --dry-run     # the moves it would make
eidos migrate

eidos migrate makes the mechanical part of the hop: renames what moved, rewrites the standard’s properties.core block, sets eidos_version, and carries every plugin folder and region across untouched. It reports what only the owner can decide and does not do it. Your own properties under properties.custom are never touched.

What each hop moves, what stays, and what needs a person is in versions/MIGRATIONS.md. The migrate skill walks the judgment calls with you. Skills →