Schema

El Schema (el esquema) es todo el contrato de propiedades del Framework: las propiedades centrales que Eidos exige, más lo que añada el Framework. Vive en un solo sitio, ## Schema en _eidos/Framework.md, y el frontmatter se genera a partir de él, así que un Blueprint nuevo nace conforme.

Cada propiedad declara cuatro cosas:

Campo	Significado
Name	La clave del frontmatter.
Type	Uno de Text, List, Number, Checkbox, Date, Date & time.
Applies To	all, o una lista de colecciones.
Meaning	Para qué sirve, en una frase.

Por qué esos seis tipos

Son el conjunto que usa Obsidian, así que el frontmatter se renderiza de forma nativa en un vault. Cualquier cosa que quiera más estructura que uno de ellos pertenece al cuerpo, no a una propiedad.

El alcance de Applies To

Esta es la parte que hace trabajo de verdad. El frontmatter se genera por Blueprint a partir de las propiedades que aplican a su colección, así que una propiedad acotada nunca aterriza donde no tiene sentido.

domain es una propiedad exclusiva de specs en la semilla software. Un frame nunca recibe una, porque un frame no se agrupa por dominio, y eso lo impone la generación, no pedirle a la gente que se acuerde.

El núcleo

Presente en todo Blueprint, y la totalidad de lo que exige el estándar:

Nombre	Tipo	Significado
id	Text	Identidad estable, única, en kebab-case. Se asigna una vez, nunca se renombra. Las referencias apuntan a ella.
title	Text	Nombre legible por humanos.
summary	Text	Una línea llana: qué es este Blueprint. La fuente del listado de index.md de la colección; si falta, el índice lo señala.
flavor	Text	Qué flavor sigue este Blueprint. Si falta, el por defecto de la colección.
connects_to	List	Blueprints con los que este conecta en el canvas, cada uno un enlace, dibujado como arista dirigida.

Cinco propiedades. Ese es el contrato obligatorio entero.

`id` es permanente

Estable, único, en kebab-case, asignado una vez y nunca renombrado. Renombra title con libertad: es la etiqueta humana. El id es la identidad de la que cuelgan los enlaces, las referencias y la historia.

No edites a mano el bloque del núcleo

### Eidos Core en Framework.md es el bloque del estándar. migrate lo reescribe en un cambio de versión. Tus propiedades van bajo ### Custom Properties.

Eidos no define ninguna propiedad personalizada

Un status de ciclo de vida, fechas, una agrupación, una lista de dependencias: todo eso es elección del Framework, no del estándar. Cada semilla hace su propio conjunto.

La semilla software trae estas, y todas y cada una son tuyas para conservar, acotar o eliminar:

Nombre	Tipo	Applies To	Significado
status	Text	all	Draft / Intake / In Progress / Done / Archived / Deprecated. Un valor fuera de lista avisa.
date_created	Date	all	YYYY-MM-DD. El día en que se escribió el Blueprint por primera vez. Se fija una vez.
date_modified	Date	all	YYYY-MM-DD. El día en que se cambió por última vez.
tags	List	all	Etiquetas libres.
domain	Text	specs	La agrupación, coincidiendo con la subcarpeta del Blueprint. Un valor desconocido avisa.
depends_on	List	specs	Blueprints que este necesita, cada uno un enlace markdown. Una dependencia de implementación, no una arista del canvas.
type	Text	specs	Etiqueta de categoría abierta y blanda: feature, capability, integration. Dirige vistas, nunca estructura.

Añade una con configure, que presiona por las cuatro cosas (Name, Type, Applies To y Meaning) y luego la rellena retroactivamente en los Blueprints a los que aplica.

Tres convenciones de propiedades que conviene interiorizar

Las etiquetas blandas son vistas, no estructura

type es el ejemplo: una etiqueta de categoría dirige vistas y filtrado, nunca estructura. Un valor fuera de lista es válido.

Si una etiqueta empieza a cambiar qué secciones tiene un Blueprint, ya no es una etiqueta: es un flavor, y flavor es la propiedad que lleva la elección estructural.

El valor de una agrupación coincide con su carpeta

Si una colección declara una propiedad que nombra su agrupación, el valor coincide exactamente con la subcarpeta, según la convención de nombres del Framework. Un valor desconocido avisa en lugar de bloquear: las agrupaciones se acumulan con el tiempo, y el validador es el sitio equivocado para litigarlas.

Sin campos de seguimiento de trabajo

En la que vale la pena negarse. Nada de sprint, estimate ni assignee. Conecta con tu gestor de tareas mediante un enlace. Por qué →

connects_to frente a depends_on

Dos propiedades de lista de enlaces que se parecen y significan cosas distintas. Vale la pena acertar, porque solo una de ellas dibuja.

connects_to es central. Es el mapa intencional: qué afirmas que se relaciona con qué, para una persona que lee la raíz espacialmente. canvas dibuja cada entrada como una arista dirigida.

depends_on es una propiedad propia de la semilla software. Es una dependencia de implementación: qué necesita esto para poder construirse. No es una arista del canvas, aunque canvas puede superponerla en un color distinto si se lo pides.

La distinción es intención frente a mecanismo. Dos Blueprints pueden depender técnicamente el uno del otro sin tener nada que decirse conceptualmente, y lo contrario pasa igual de a menudo.

Fechas e historia

La versión de Eidos es un dato del Framework, en Framework.md. Nunca es una propiedad por Blueprint.

Las fechas tampoco son asunto del estándar. Hasta la 4.4.1 mandaba cómo se comportan date_created y date_modified; la 4.4.2 lo eliminó, porque encajaba mal junto a una sección de Schema que declara que Eidos no define ninguna propiedad personalizada. Un Framework que quiera propiedades de fecha las declara como cualquier otra, y es dueño de lo que significan.

Por qué el estándar puede permitirse no meterse

Git guarda la historia completa: de eso se trata vivir en un repositorio, y es la razón de que Eidos nunca reinvente un registro de auditoría en el frontmatter. La semilla software sigue trayendo las dos propiedades de fecha; simplemente ahora son elección suya, no una regla.

Validación

La validación la define el Framework. Una comprobación lee el Schema de ese Framework y lo aplica: las propiedades centrales más las personalizadas acotadas a la colección del Blueprint. El contrato es el Schema, no una regla grabada en una herramienta.

Y la postura es portabilidad antes que prescripción. Una propiedad central que falta se saca a la luz y se añade con una nota sobre el porqué. Una sección que falta se anota y se ofrece. Nunca se rechaza el archivo.

La salida de la validación es una revisión sobre la que actúa una persona, no una barrera que la detiene.

Siguiente

• Frames
• Dar forma a tu Framework: añadir una propiedad y rellenarla retroactivamente.