Propiedades

La tabla de propiedades es todo el contrato de propiedades del Framework (el marco), bajo properties en Framework.yaml. El frontmatter se genera a partir de ella, así que un Blueprint (plano) nuevo nace conforme.

Cada propiedad declara:

Campo	Significado
name	La clave del frontmatter
type	`Text`, `List`, `Number`, `Checkbox`, `Date` o `Date & time`: el conjunto que Obsidian renderiza de forma nativa
applies_to	`all`, o una lista de colecciones
required	Ausente significa `false`
options	Solo cuando el valor es uno de un conjunto cerrado: los valores permitidos, en orden
meaning	Para qué sirve, en una frase

Cualquier cosa que quiera más estructura que uno de los seis tipos pertenece al cuerpo.

Alcance, requerido, opciones

applies_to es lo que impide que una propiedad caiga donde no tiene sentido. domain aplica solo a specs en la semilla software, así que un frame (encuadre) nunca recibe una.

required pone la propiedad en cada Blueprint nuevo y convierte una ausente o en blanco en un hueco que la comprobación anota. Una propiedad opcional se escribe cuando tiene valor; su ausencia nunca es un hueco. Opta por opcional por defecto, y exige solo lo que cada Blueprint deba responder.

options cierra un valor Text (o los elementos de una List) a un conjunto declarado, comparado exactamente. Un valor fuera de la lista se muestra con la lista al lado, nunca se rechaza ni se sustituye en silencio. El orden es el orden en que van los valores, así que un ciclo de vida se lee de la primera etapa a la última y un desplegable lo conserva. No lleva ningún valor por defecto. Dos propiedades nunca llevan options: variant, cuyo conjunto son las variants (variantes) de la colección, y una propiedad de agrupación, cuyo conjunto son sus grupos.

El núcleo

Todo lo que el estándar declara:

Nombre	Tipo	Requerida	Significado
`id`	Text	sí	Identidad estable y única, en cualquier forma. Se asigna una vez, no cambia nunca
`title`	Text	sí	Nombre legible. Renómbralo con libertad; `id` se queda quieto
`summary`	Text	no	Una línea: qué es este Blueprint. Alimenta el índice; ausente, el índice lo señala
`variant`	Text	no	Qué variant sigue este Blueprint. Ausente significa la predeterminada de la colección

Eidos no define propiedades personalizadas

Estado, fechas, agrupación, dependencias: todo es elección del Framework. La semilla software trae estas, y todas son tuyas para conservarlas, acotarlas o quitarlas:

Nombre	Tipo	Aplica a	Significado
`status`	Text	all	Etapa del ciclo de vida. Opciones: Draft, Intake, In Progress, Done, Archived, Deprecated
`date_created`, `date_modified`	Date	all	`YYYY-MM-DD`
`tags`	List	all	Etiquetas libres
`domain`	Text	specs	El grupo, coincidiendo con la subcarpeta. La única propiedad que la semilla requiere
`depends_on`	List	specs	Blueprints que este necesita, cada uno un enlace markdown
`type`	Text	specs	Etiqueta blanda: feature, capability, integration. Rige vistas, nunca estructura

Añade una con eidos configure:property add. Dar forma a tu Framework →

Tres convenciones

Las etiquetas blandas son vistas, no estructura. Una propiedad de categoría rige el filtrado, nunca qué secciones tiene un Blueprint. Si empieza a hacerlo, es una variant.

Un valor de agrupación coincide con su carpeta. Exactamente, en la convención de nombres. Un valor desconocido avisa.

Sin campos de seguimiento de trabajo. Nada de sprint, estimate ni assignee. Enlaza con tu gestor de tareas. Por qué →

Las fechas y el historial tampoco son asunto del estándar: git guarda el historial completo, y por eso Eidos nunca reinventa un registro de auditoría en el frontmatter. La versión de Eidos es un hecho del Framework, en eidos_version, nunca en un Blueprint.

Vocabulary

Junto a las propiedades, el Framework declara su vocabulary (vocabulario): una entrada por cada palabra con la que se describe el producto a propósito, con lo que means (significa), lo que not es (los casi-aciertos y por qué), y see para el Blueprint que la define por completo. Eidos no declara ninguna; cada semilla trae la lista vacía. Donde un término está declarado, los Blueprints lo usan; un casi-acierto se señala (term-near-miss), nunca se sustituye en silencio.

Validación

La validación la define el Framework. Una comprobación lee la tabla de ese Framework y la hace cumplir. Mostrar, nunca rechazar. Una propiedad requerida ausente se informa; una sección ausente se ofrece; el archivo nunca se rechaza. La salida es una revisión sobre la que actúa una persona.

En la CLI: eidos new genera el frontmatter; eidos property set cambia un valor, tipado; eidos check valida contra cada bloque. En el navegador, una propiedad con opciones es un desplegable.