Convenciones
EIDOS.md cierra con diecinueve convenciones estructurales. Allí son una lista
plana y numerada; aquí están agrupadas por lo que gobiernan, con enlaces a las
páginas que las explican.
Qué se impone, y cómo
Sección titulada «Qué se impone, y cómo»El frontmatter es el acuerdo; el cuerpo es orientación. Las propiedades se comprueban contra el Schema del Framework. Las secciones del cuerpo son estructura recomendada, no requisitos.
La validación la define el Framework. Una comprobación lee el Schema de ese Framework y lo aplica. El contrato es el Schema, no una regla grabada en una herramienta.
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 rechaces el archivo.
Dónde vive la forma
Sección titulada «Dónde vive la forma»La raíz 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, no desde una
copia propia.
→
Todo Framework declara una colección de encuadre. Su nombre, sus flavors y cuántos lleva son cosa del Framework. Obligatoria como declaración; nunca como barrera: un frame declarado y sin escribir es un hueco que sacar a la luz, no un fallo. →
Shapes y colecciones
Sección titulada «Shapes y colecciones»Una familia de shapes por colección, declarada como flavors. Lo que flexiona es qué secciones aparecen y qué flavor usa un Blueprint, nunca su orden ni sus nombres dentro de un flavor. El shape nunca se bifurca por categoría.
Un shape nombra su propia parte estable. Todo shape tiene una parte que se queda quieta y una parte que se mueve, y dice cuál es cuál. Si la parte estable cambia sustancialmente, pregúntate si esto no es otro Blueprint. →
Los no-objetivos son los que más pesan. Donde un shape declara una sección para lo que un Blueprint deliberadamente no va a hacer, esa sección es la más fuerte que tiene: es donde de verdad ocurre la gestión del alcance. Sigue sin ser una barrera dura. →
Un shape documenta sus propias convenciones. Los nombres de sección, su orden y significado, y cualquier etiquetado que pida un shape viven en el archivo del shape. El estándar gobierna colecciones, shapes, flavors y propiedades; nunca gobierna una sección.
La agrupación de una colección es cosa de la colección. Puede agrupar sus Blueprints un nivel y puede declarar una propiedad que nombre esa agrupación; el valor coincide entonces con la carpeta, y un valor desconocido avisa en lugar de bloquear.
Propiedades
Sección titulada «Propiedades»Las propiedades llevan un tipo y un significado. Toda propiedad declara su nombre, su tipo, a qué colecciones aplica y qué significa. El frontmatter se genera a partir del Schema, así que un Blueprint nuevo nace conforme.
Las etiquetas blandas son vistas, no estructura. Una etiqueta de categoría
que añade un Framework dirige vistas y filtrado, nunca estructura. Un valor fuera
de lista es válido. flavor lleva la elección estructural.
La versión de Eidos es un dato del Framework. Vive en Framework.md, nunca
como propiedad por Blueprint. Git guarda la historia; un Framework que quiera
propiedades de fecha las declara como cualquier otra.
→
Escritura
Sección titulada «Escritura»Escríbelo como lo leería una persona. Las secciones son un andamio para un Blueprint vivo, no un formulario en el que verter texto. Si un Blueprint se lee como una plantilla rellenada, remodélalo hasta que se lea como algo que escribió alguien.
Referencia otros Blueprints con enlaces, no con nombres sueltos, tanto en la
prosa como en las propiedades. El id de cada Blueprint sigue siendo su
identidad permanente, detrás del enlace.
La prosa suelta se revisa en el sitio. Un documento de nivel superior, y cualquier colección que un Framework marque como prosa suelta, registra lo que es cierto ahora y se espera que cambie. Eso es revisión, no estado del trabajo.
Quién hace qué
Sección titulada «Quién hace qué»Lee al actor antes de actuar. Lee _eidos/me.md y el contrato correspondiente
en _eidos/roles/, y responde como define ese rol. El principio de «las personas
primero» vale para todos los roles; solo cambia el modo. Un archivo en blanco o
ausente recurre por defecto a la facilitación completa.
→
Lo que solía estar aquí
Sección titulada «Lo que solía estar aquí»Cinco convenciones se eliminaron en la 4.4.2: reformuladas en otro sitio, no relajadas. Todas siguen valiendo; simplemente ya no se llevan como regla numerada:
| Eliminada | Ahora vive en |
|---|---|
El id es permanente |
La tabla del Schema |
| Los nombres visibles siguen la convención de nombres | Nombres |
Framework.md es el índice; README.md es la puerta |
Framework y Blueprint |
| Cada colección tiene un índice generado | Hojas generadas |
| Los documentos de nivel superior no tienen shape | Shapes y flavors |
También desapareció la vieja regla que exigía date_created y date_modified.
Le decía a los Frameworks cómo debían comportarse dos propiedades, mientras la
sección de Schema dice que Eidos no define ninguna propiedad personalizada. Un
Framework que ya las use no cambia nada: ahora simplemente es dueño de ellas por
completo.
Si solo recuerdas tres
Sección titulada «Si solo recuerdas tres»La persona escribe. Todo lo demás se deriva de eso.
Los no-objetivos son los que más pesan. Es donde de verdad se sostiene el alcance, y la primera sección que se vacía cuando nadie es dueño de la raíz.
Sin campos de seguimiento de trabajo. Es la línea entre un Blueprint que sigue siendo cierto y un ticket que se pudre.