Convenciones
EIDOS.md cierra con veintidós reglas. Aquí están agrupadas por lo que rigen, cada una con un puntero a la página que la explica. Cita lo que dice una regla, no su número; la numeración cambia entre versiones.
Qué se hace cumplir, y cómo
Sección titulada «Qué se hace cumplir, y cómo»- El frontmatter es el acuerdo; el cuerpo es guía. Las propiedades se comprueban. Las secciones se recomiendan.
- La validación la define el Framework. Una comprobación hace cumplir la tabla de propiedades de ese Framework (el marco), nada fijo en el código.
- Mostrar, nunca rechazar. Una propiedad ausente se añade con una nota; una sección ausente se ofrece. Nunca se rechaza el archivo. Un validador que rechaza archivos acaba esquivado. →
Dónde vive la forma
Sección titulada «Dónde vive la forma»- La raíz posee su Framework. Una herramienta lee el Framework de la raíz en la que está, nunca de una copia propia. →
- Todo lo que hay en la raíz está declarado. Cada carpeta y cada archivo tiene una entrada, y no se declara nada que no esté. →
- Una carpeta es de su dueño. Las reglas del estándar llegan hasta
@eidos/collectionsy no más allá; la carpeta de una herramienta es de esa herramienta, y una sin dueño es de la persona. → - Una región es de una herramienta, por nombre. Dentro es de la herramienta; fuera es de la persona. →
- La versión de Eidos es un hecho del Framework, en
eidos_version, nunca en un Blueprint (plano). →
Templates y colecciones
Sección titulada «Templates y colecciones»- Una familia de templates por colección, como variants. Lo que cambia es qué secciones aparecen; nunca su orden ni sus nombres. →
- Un template nombra su propia parte estable. Si cambia sustancialmente, pregúntate si es un Blueprint distinto. →
- Los non-goals cargan con más peso. Donde un template tiene una sección para lo que un Blueprint no hará, esa sección es la más fuerte. →
- Un template documenta sus propias convenciones. El estándar rige carpetas, templates (plantillas), variants (variantes) y propiedades; nunca una sección.
- La agrupación de una colección es suya. Cada subcarpeta es un grupo declarado; un grupo contiene Blueprints y nada más profundo. →
Propiedades
Sección titulada «Propiedades»- Cada propiedad tiene tipo, significado y dueño. El frontmatter se genera a partir de las requeridas, así que un Blueprint nuevo nace conforme. →
- Las etiquetas blandas son vistas, no estructura. Una propiedad de categoría rige el filtrado, nunca la estructura.
variantlleva la elección estructural. - Sin campos de seguimiento de trabajo. Nada de sprint, estimate ni assignee; tiende un puente a un gestor de tareas con un enlace. Intención, nunca progreso. →
Escritura
Sección titulada «Escritura»- Escríbelo como lo leería una persona. Si se lee como texto de relleno completado, remodélalo.
- Referencia los Blueprints con enlaces, no con nombres sueltos, tanto en la prosa como en las propiedades. →
- La prosa suelta se revisa en el sitio. Eso es revisión, no estado del trabajo.
- Un término declarado es la palabra. Un casi-acierto se señala, nunca se sustituye en silencio. →