Templates y variants

Un template es el cuerpo

Un template (la plantilla) son las secciones que lleva un Blueprint (el plano): en orden, bajo nombres fijos, cada una con su guía. Solo el cuerpo; el frontmatter se genera a partir de la tabla de propiedades, y un template que lleve alguno es un fallo.

Un archivo por template en .eidos/templates/, llamado <unit>.<variant>.md: la palabra para uno de los Blueprints de la colección, después la variant (la variante).

• Directorio.eidos/templates/

  • spec.full.md
  • spec.micro.md
  • frame.architecture.md
  • frame.audience.md

Variants

Los templates de una colección son variants de una misma familia. Una es la predeterminada. Lo que cambia entre ellas es qué secciones aparecen, nunca su orden ni sus nombres.

Las dos variants de spec de la semilla software:

spec.micro	spec.full
## Intent	## Intent
### Assumptions	### Assumptions
	### Implementation Notes
## Open Questions	## Open Questions
## Behaviors & Acceptance Criteria	## Behaviors & Acceptance Criteria
	### Functional · ### Performance · ### Design · ### External interface · ### Quality attributes
## Out of Scope	## Out of Scope
	## Dependencies · ## Testing · ## Constraints & Decisions

micro es la spec más pequeña que merece escribirse: por qué existe, qué vas a obtener, qué no hará. Las pruebas y las dependencias pueden esperar; el alcance no.

Un Blueprint en una variant que no es la predeterminada lo dice en el frontmatter, variant: micro. Ausente significa la predeterminada. La validación comprueba un Blueprint contra la variant que nombra, así que una variant más ligera nunca se señala por secciones que solo tiene una más completa.

Hacer crecer un Blueprint

1. Escríbelo como micro al principio, cuando hay más pregunta que respuesta.
2. Añade las secciones más completas a medida que se ganen su sitio: una dependencia real, una decisión tomada de verdad.
3. Pon variant: full (o quita la propiedad) cuando haya crecido hasta ahí.

Déjala fuera, no la dejes vacía

Una spec full con cinco encabezados vacíos es peor que una spec micro completa, porque da a entender que consideraste cosas que no consideraste. Omite una sección que no aplique.

Dos convenciones

Una familia de templates por colección. Si la mitad de tus specs necesita secciones distintas, eso es una variant o una colección distinta, nunca un segundo template colado en la misma.

Un template documenta sus propias convenciones. Los nombres de las secciones, su orden y cualquier etiquetado viven en el archivo del template. El estándar rige colecciones, templates, variants y propiedades; nunca rige una sección. Por eso ## Intent no aparece en ningún sitio de EIDOS.md: es la palabra de la semilla software.

Cómo es un archivo de template

.eidos/templates/spec.micro.md

# {{title}}

## Intent

_Why this exists: the problem and who has it. This is the stable part: if Intent
changes substantially, you probably have a different spec._

### Assumptions

_What you're taking as given, not yet confirmed._

## Open Questions

_What you don't yet know and still need answered._

## Behaviors & Acceptance Criteria

_What it does, as observable outcomes. Label each **AC1:**, **AC2:**, …_

- **AC1:** <!-- the first observable outcome -->

## Out of Scope

_Explicit non-goals. The first thing to write, not the last._

{{title}} es el único marcador. Las líneas en cursiva son guía que se borra al rellenar cada sección.

Los documentos de nivel superior no tienen template

Un documento de nivel superior (una Visión, una Hoja de ruta) es único: se escribe una vez, se revisa en el sitio. Sin template, sin variants, sin validación. Un template se gana su sitio estampándose otra vez.

En la CLI: eidos new --variant <name> renderiza el cuerpo desde ese template; eidos check informa de las secciones que declara y al cuerpo le faltan.

Siguiente

• Propiedades
• Dar forma a tu Framework