Versionado

Dos cosas se versionan por separado, ambas con versionado semántico. Confundirlas es la fuente de confusión más común, así que vale la pena ser preciso.

	El estándar	El plugin
Vive en	EIDOS.md	.claude-plugin/plugin.json
Una raíz lo registra como	eidos_version en _eidos/Framework.md	—
Se mueve cuando	se mueve el texto de EIDOS.md	sale cualquier versión, incluida una corrección en una skill
Lo ve	migrate	/plugin install y las comprobaciones de actualización
Copias congeladas	versions/	CHANGELOG.md

Empezaron en el mismo número y se han separado, porque el tooling cambia mucho más a menudo que el estándar.

Leer una nota de versión

CHANGELOG.md registra qué estándar llevaba cada versión del plugin. Una nota que dice Standard: unchanged significa que tus raíces no necesitan nada: solo se movieron las skills.

Qué significan los números para el estándar

• Mayor: cambios que rompen.
• Menor: añadidos retrocompatibles.
• Parche: aclaraciones.

Al etiquetar, EIDOS.md se copia tal cual a versions/ con su nombre semver completo. Eso es lo que hace posible la sección siguiente.

Las migraciones no son secuenciales

Esta es la parte que sorprende, y es una decisión de diseño deliberada.

migrate va directamente de cualquier versión de origen a cualquier destino, comparando las dos instantáneas congeladas de versions/. De la v1.0.0 a la v4.4.2 es un salto, no cuatro. No hay una cadena de actualizaciones secuenciales que ejecutar en orden, ni ninguna versión en la que tengas que parar por el camino.

Los saltos desarrollados están registrados en versions/MIGRATIONS.md.

Las herramientas pueden rechazar una versión no soportada.

Qué toca la migración

migrate reescribe el bloque ### Eidos Core de tu Framework.md y sube eidos_version. Ese bloque es del estándar, que es la razón de que se desaconseje editarlo a mano: tus propias propiedades viven bajo ### Custom Properties y no se tocan nunca.

Los números actuales

	Versión
El estándar	4.4.2
El plugin que lo distribuye	4.5.2

La diferencia es la separación funcionando como se pretende: el tooling ha sacado versiones que el estándar no necesitaba.

4.4.1 → 4.4.2

Una pasada de claridad sobre el vocabulario y las reglas. Pon eidos_version: 4.4.2; nada en disco tiene que moverse.

root vuelve a ser un término declarado. La única carpeta en la que vive Eidos (con el Framework, las colecciones y cualquier documento de nivel superior) encontrada por su _eidos/ y nunca por su nombre. La 4.4.1 retiró «definición» y dejó el concepto sin nombre, así que el estándar recurría a «una carpeta Eidos» en un centenar de sitios. La palabra ya hacía el trabajo; ahora está en el vocabulario.

shape y flavor dejan de definirse mutuamente. Un shape es una plantilla de cuerpo, un archivo en _eidos/shapes/. Los shapes de una colección son variantes de una misma familia, y cada variante es un flavor. Ninguno de los dos conceptos se movió: la tabla simplemente dejó de dar vueltas.

frame ya no se lee como «caduca». Decía «suelto, de un momento dado», lo que encajaba mal junto a un estándar cuya afirmación entera es que un Blueprint es independiente del tiempo y del estado. Un frame es lo que es la cosa entera, tomada entera en lugar de unidad a unidad, revisada cuando ese juicio cambia. Nada sobre cómo funcionan los frames se ha movido.

Las reglas pasan de 24 a 19, y se renumeran

Cinco reformulaban una sección anterior y se eliminaron, no se relajaron. Si citas reglas de Eidos por número en algún sitio, vuelve a comprobarlas: eso es lo único de esta versión que puede quedar obsoleto. Qué se movió a dónde →

La vieja regla sobre fechas se fue con ellas. Exigía cómo se comportan date_created y date_modified, mientras la sección de Schema dice que Eidos no define ninguna propiedad personalizada y que las fechas son elección de un Framework. Conserva la mitad que obliga (la versión de Eidos es un dato del Framework, en Framework.md) y deja las fechas al Framework que las declare. Un Framework que ya use esas propiedades no cambia nada; ahora simplemente es dueño de ellas por completo.

El canvas es el mapa de Blueprints. Dibuja Blueprints y sus aristas connects_to; el Framework es lo único que nunca dibuja. canvas escribe blueprint-map.canvas a partir de ahora, y solo cuando no pasas --out, así que un framework-map.canvas existente conserva su nombre hasta que lo regeneres sin uno. Si dejas que se renombre, actualiza su punto en ## Top-Level.

Por raíz

1. Pon eidos_version: 4.4.2 en _eidos/Framework.md, y actualiza la nota de versión de su bloque ## Schema. Esa es toda la migración obligatoria.
2. Opcionalmente regenera el canvas para que tome el nombre nuevo, y arregla su punto en ## Top-Level si lo haces.
3. Opcionalmente refresca la prosa de la semilla en _eidos/, que todavía dice «Framework Map» donde el estándar dice ahora «Blueprint Map». Cosmético: nada lee esas palabras.

Nada más se mueve. Ninguna propiedad, ninguna sección de cuerpo, ningún nombre de archivo, ninguna colección.

4.4.0 → 4.4.1

Una versión de vocabulario. Pon eidos_version: 4.4.1; nada en disco tiene que moverse. Tres cambios, todos en el texto del estándar:

item pasa a ser blueprint. Lo mismo que fue siempre: un archivo markdown dentro de una colección, que define una unidad por completo. Ninguna propiedad, carpeta o nombre de archivo llevó nunca la palabra, así que nada de lo que lee un agente o un script cambia.

definition se retira, sin sustituto. Nombraba la carpeta entera, pero chocaba con lo que hace un Blueprint (un Blueprint define una unidad) y el sentido cotidiano de la palabra es una entrada de diccionario, no un árbol de carpetas. Eidos gira ahora sobre dos palabras: Framework y Blueprint. Donde el estándar necesita nombrar la carpeta, dice «una carpeta Eidos» o «la raíz». (La 4.4.2 se decidió por root como término declarado; ver arriba.)

El nombre de raíz por defecto es Blueprints/, en plural, porque contiene muchos. Solo es el valor por defecto que ofrece install; la raíz puede seguir llamándose como sea, y nada apunta a ella por ruta.

Por raíz

1. Pon eidos_version: 4.4.1 en _eidos/Framework.md, y actualiza la nota de versión de su bloque ## Schema. Esa es toda la migración obligatoria.
2. Opcionalmente refresca la prosa de la semilla en _eidos/. Las líneas de introducción de Framework.md, los archivos de shape y roles/*.md dicen «item» y «definition» donde el estándar dice ahora «blueprint». Puramente cosmético (nada lee esas palabras), así que solo vale la pena donde nadie haya editado el texto desde que lo escribió install.
3. Deja en paz un rol o un shape editado a mano salvo que lo pida su dueño. Sus palabras son suyas.
4. Renombrar la raíz es opcional. Un Blueprint/ existente funciona exactamente igual que antes; renómbralo solo si el dueño quiere el plural, y entonces es un simple renombrado de carpeta sin nada que apunte a ella que arreglar.

Nada más se mueve. Ninguna propiedad, ninguna sección de cuerpo, ningún nombre de archivo, ninguna colección.

4.3.2 → 4.4.0

El movimiento más reciente en el estándar, y una buena ilustración de lo pequeño que puede ser un cambio en él.

El salto anterior. La 4.4.0 cambió un valor por defecto. kebab-case es ahora lo que recomienda el estándar y lo que significa una clave naming ausente; hasta la 4.3.2 una clave ausente significaba Title Case. Una raíz que ya lleva la clave no se ve afectada (la clave manda en las dos versiones y solo se movió el valor de reserva), así que para casi todo el mundo la migración entera es: sube eidos_version y para.

Para una raíz sin clave naming, zánjala en lugar de dejar que decida el valor por defecto:

Lee la convención de los archivos. El árbol ya responde a la pregunta. Una carpeta de colección o un nombre de archivo de Blueprint con un espacio significa Title Case; sin espacios y con mayúsculas (WatchAVideo.md) significa TitleCase; en minúscula y con guiones (watch-a-video.md) significa kebab-case. Comprueba un par de colecciones en lugar de un archivo, y si discrepan, eso es una inconsistencia real que sacar a la luz, no algo que promediar.

Confírmala con el dueño y luego escríbela en _eidos/Framework.md. Declara lo que dicen los archivos y lo que estás a punto de registrar. Registrar lo que la raíz ya hace no es un cambio en ella.

Adoptar kebab-case es una pasada aparte y deliberada

Nunca la mezcles con la subida de versión. Renombra cada carpeta de colección, subcarpeta y archivo de Blueprint, reescribe cada enlace y pasa a minúscula el valor de cada propiedad de agrupación para que coincida con su carpeta (domain: Channels → domain: channels). Hazlo cuando el dueño lo quiera, no porque se movió el valor por defecto.

Dos notas menores de la misma versión:

• El nombre de archivo por defecto del canvas sigue la convención: blueprint-map.canvas en kebab-case, BlueprintMap.canvas en TitleCase, Blueprint Map.canvas en Title Case. La skill canvas solo elige el nombre cuando no pasas --out, así que un canvas existente conserva su nombre hasta que lo regeneres sin uno. Si acaba renombrado, actualiza su punto en ## Top-Level.
• README.md se nombra ahora como excepción junto a _eidos/: conserva el nombre que toda herramienta ya busca, sea cual sea la convención. Nada que cambiar: esto pone por escrito lo que ya hacía cada carpeta.

Nada más se mueve. Ningún shape, ningún rol, ninguna propiedad del Schema, ninguna sección de cuerpo.

Las dos carpetas de ejemplo en examples/ se convirtieron a kebab-case en esa versión, por si quieres leer un diff desarrollado.

¿En qué versión estoy?

Lee eidos_version en el _eidos/Framework.md de tu raíz. Esa es la versión a la que se ajusta tu raíz, no la que resulte que tenga el plugin, ni lo que diga ninguna propiedad por Blueprint, porque no la hay.

Siguiente

• Convenciones
• Skills: migrate en contexto.