Framework y Blueprint

Eidos gira sobre dos palabras. Ten estas claras y el resto del estándar encaja solo.

	Framework (el marco)	Blueprint (el plano)
Qué es	La forma	Una unidad, definida por completo
Es	Colecciones, shapes, flavors, roles, convención de nombres, Schema	Un archivo markdown: frontmatter más cuerpo
Vive en	_eidos/, oculto en la raíz	Una carpeta de colección
¿Portátil?	Sí: esta es la pieza que un equipo entrega a otro	No: es tu producto
Relación	Un Framework	Rige tantos Blueprints como quieras, en tantas raíces como quieras

El nombre

Eidos (εἶδος) viene de ἰδεῖν, ver: literalmente el aspecto de una cosa, su figura visible. Platón lo tomó para la Forma: el patrón al que una cosa se ajusta, que el ojo nunca capta y la mente sí. Aristóteles lo opuso a ὕλη, materia: la forma es lo que convierte un pedazo de algo en esa cosa concreta.

Los dos sentidos son estructurales aquí. El Framework es la forma; un Blueprint es lo que toma esa forma.

Una tercera palabra, con menos trabajo

raíz: la única carpeta en la que vive Eidos, con el Framework, las colecciones y cualquier documento de nivel superior. Se encuentra por el _eidos/ oculto que hay dentro, nunca por su nombre.

No forma parte del par de arriba porque nombra un lugar, no una idea. Hasta la 4.4.0 el árbol entero se llamaba definición; eso chocaba con lo que hace un Blueprint, así que la 4.4.1 lo eliminó y la 4.4.2 se decidió por root.

La raíz

Una carpeta, que puede llamarse como sea (Blueprints/ es solo el nombre por defecto que ofrece install), porque nada apunta a ella por ruta. Se encuentra por el _eidos/ oculto que hay dentro.

• DirectorioBlueprints/ la raíz

  • README.md el “empieza aquí” visible
  • Directorio_eidos/ el Framework

    • …
  • Directorioframes/ la colección de encuadre — declarada primero

    • index.md hoja generada
    • architecture.md uno por cada tipo de frame, en plano
  • Directoriospecs/ una colección de Blueprints

    • index.md hoja generada
    • Directorioplayback/ un nivel de subcarpetas, como mucho

      • resume-playback.md un Blueprint por archivo
  • roadmap.md un documento de nivel superior — opcional, tuyo

Varias raíces pueden convivir en un mismo repositorio. Se anidan como Blueprints/<nombre>/…, cada una con su propio _eidos/.

El Framework

El Framework está oculto igual que lo están .git y .obsidian: presente, manejable y apartado una vez que está fijado. Esa ubicación es deliberada: la raíz es plausiblemente un vault de Obsidian, y _eidos/ se sitúa junto a .obsidian/ sin competir con el contenido por la atención.

• Directorio_eidos/

  • Directorioshapes/ un archivo por flavor

    • spec.full.md el flavor por defecto de una colección
    • spec.micro.md un segundo flavor del mismo tipo
    • frame.architecture.md los flavors de la colección de encuadre
  • Directorioroles/ contratos de respuesta, versionados y ajustables por el equipo

    • framework-owner.md el que lleva toda semilla
    • developer.md el resto son propios del Framework
  • Framework.md índice + configuración: versión, nombres, colecciones, Schema
  • me.md el actor (personal, en gitignore)
  • .gitignore ignora me.md — el único archivo de aquí que no se versiona

Una carpeta sin _eidos/ no es una raíz.

Framework.md

El único archivo que describe la forma en lugar de un Blueprint concreto. Frontmatter para los datos que analiza el tooling; un cuerpo que indexa la raíz.

_eidos/Framework.md — frontmatter

---
eidos_version: 4.4.2      # the standard version this framework targets
naming: kebab-case        # kebab-case | TitleCase | Title Case; absent = kebab-case
---

El cuerpo lleva cuatro cosas:

## Top-Level: los documentos únicos de la raíz, con README primero. Los documentos de encuadre no están aquí; son una colección.

## Collections: un encabezado ### por cada una, declarando su hoja generada, sus flavors (con uno marcado por defecto), cómo debe dibujarla el canvas y su agrupación.

_eidos/Framework.md — a collection

### specs

The product's units, one per blueprint, grouped by domain.

- **Leaf:** [specs/index.md](../specs/index.md)
- **Flavors:**
  - [full](shapes/spec.full.md) — the complete spec shape (default).
  - [micro](shapes/spec.micro.md) — Intent, Open Questions, ACs, Out of Scope.
- **Canvas:** card from `## Intent`
- **Domains:** _(one bullet per domain as they accrue)_

## Schema: el contrato de propiedades, dividido en ### Eidos Core (las del estándar, reescritas por migrate; no las edites a mano) y ### Custom Properties (las tuyas). Más →

Pistas para el canvas

- **Canvas:** le dice a canvas cómo dibujar una colección: file para un nodo de archivo completo (la prosa se lee entera), card para un nodo que incrusta el Blueprint, o card from ## Section para incrustar una sección. Si falta, se dibuja una tarjeta simple: el generador no conoce ninguna colección por su nombre y no puede adivinar qué sección es el resumen.

Por qué importa la separación

Porque el Framework es la pieza que viaja.

Tus Blueprints son tu producto, y no le sirven a nadie más. Un Framework es forma sin contenido (colecciones, shapes, un esquema, roles) y es exactamente el artefacto que un equipo entrega a otro para que ambos escriban igual. Esa es toda la razón de ser de las semillas: son Frameworks que Eidos distribuye, e install copia uno en una raíz nueva.

También explica la convención que más sorprende:

La carpeta es dueña de su Framework

Los shapes y las propiedades viven en el _eidos/ de la raíz. Una skill lee el Framework desde la raíz, nunca desde una copia propia. No hay configuración global, y ninguna herramienta trae grabada una idea de cómo se llaman tus colecciones.

La validación se deriva de eso. 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 horneada en una herramienta.

Siguiente

• Colecciones y Blueprints
• Dar forma a tu Framework