Colecciones y Blueprints
Colecciones
Sección titulada «Colecciones»Una colección es una carpeta en la raíz que contiene Blueprints (planos) de un mismo tipo que comparten un template (plantilla) de cuerpo. El Framework (el marco) declara cada una bajo folders con owned_by: "@eidos/collections", el único tipo de carpeta que el estándar posee. Eidos no nombra ninguna: specs, chapters, investigations, decisions son todas palabras de tu Framework.
Una colección es plana o agrupada. Agrupada, guarda sus Blueprints en un nivel de subcarpetas, cada una un grupo declarado, y un grupo contiene Blueprints y nada más profundo. También puede declarar una propiedad que nombre la agrupación (domain en la semilla software). El valor coincide exactamente con el nombre de la carpeta; un valor desconocido avisa en lugar de bloquear.
Directoriospecs/
Directorioplayback/ un grupo
- watch-a-video.md
- resume-playback.md
Directoriochannels/
- subscribe-to-a-channel.md
Un archivo dentro de una colección que no sea markdown no es un Blueprint. Los archivos que enlazan los Blueprints van en una carpeta tuya en la raíz, declarada sin dueño (las semillas traen una llamada assets), o en una carpeta que una herramienta posee y guarda por ti.
Blueprints
Sección titulada «Blueprints»Un Blueprint es un archivo markdown que define una unidad por completo. Dos partes:
---id: resume-playback ← frontmatter: the agreementtitle: Resume Playbacksummary: Returns a viewer to the exact second they stopped.status: In Progressdomain: playback---
# Resume Playback ← body: the template
## Intent…El frontmatter es el acuerdo; el cuerpo es guía. Las propiedades se comprueban contra la tabla de propiedades del Framework. Las secciones del cuerpo son recomendadas: una que falte se anota y se ofrece, nunca se rechaza.
El frontmatter se genera a partir de las propiedades que aplican a la colección del Blueprint, así que un Blueprint nuevo nace conforme y una propiedad acotada a una colección nunca cae en otra.
Un Blueprint, una unidad
Sección titulada «Un Blueprint, una unidad»La pregunta difícil siempre es «¿esto es un Blueprint o dos?». La prueba vive en el template: un template nombra su propia parte estable. En la semilla software es ## Intent. Si el porqué cambia sustancialmente, tienes un Blueprint nuevo. Si solo cambian los comportamientos, tienes una edición.
Los Blueprints no son tareas
Sección titulada «Los Blueprints no son tareas»Sin campos de seguimiento de trabajo. Nada de sprint, estimate ni assignee. Añádelos y un Blueprint se convierte en una tarea y se pudre. Enlaza con un gestor de tareas en su lugar. Lo mismo vale en el cuerpo: cómo pretendes construir algo es intención; por dónde vas es seguimiento de trabajo. Por qué →
Referenciar otros Blueprints
Sección titulada «Referenciar otros Blueprints»Enlaces, no nombres sueltos, tanto en la prosa como en las propiedades. El id es la identidad permanente detrás del enlace.
depends_on: - "[Watch a Video](../playback/watch-a-video.md)"Entrecomilla un enlace en YAML: un [ inicial empieza una lista si no. Si el destino todavía no tiene Blueprint, nómbralo llanamente en lugar de fabricar un enlace.
Las dos maneras en que un Blueprint sale mal
Sección titulada «Las dos maneras en que un Blueprint sale mal»Se lee como un formulario. Todas las secciones presentes, ninguna con un juicio dentro. Si un Blueprint se lee como texto de relleno completado, remodélalo hasta que se lea como si lo hubiera escrito alguien. Deja fuera una sección cuando no aplique.
No tiene non-goals. ## Out of Scope es donde se sostiene el alcance, y la primera sección que se vacía cuando nadie es dueño de la raíz. Por qué →
En la CLI: eidos list y eidos show <id> leen; eidos new <collection> "<Title>" levanta la estructura; eidos check informa de un Blueprint cuyo grupo y carpeta no coinciden.