Frames

Un frame (el encuadre) es un Blueprint que describe la cosa entera en lugar de una unidad de ella. Los frames fijan aquello contra lo que se juzga cualquier otro Blueprint, y viven en la colección de encuadre.

Todo Framework declara una colección de encuadre, y la declara primero.

Por qué es obligatoria

Es lo único estructural en lo que Eidos insiste más allá de las cinco propiedades centrales:

Todo Framework declara una colección de encuadre. Su nombre, sus flavors y cuántos frames lleva son cosa del Framework: un Framework necesita encuadre, no un conjunto concreto de frames.

El razonamiento es que los Blueprints carecen de sentido si no hay nada contra lo que juzgarlos. «¿Debería existir esta spec?» es incontestable si algo no dice ya a quién sirve el producto y qué intenta conseguir. Sin frames, una raíz se convierte en un montón de Blueprints razonables por separado y sin dirección común, que es justo el modo de fallo que Eidos existe para evitar.

Qué encuadran las semillas

Las tres semillas muestran el mismo requisito respondido de tres maneras distintas:

Semilla	Sus frames
`software`	architecture · audience · criteria · market
`book`	premise · reader · voice · market
`research`	question · prior work · method · ethics

Fíjate en que no son las mismas cuatro ideas renombradas. Un programa de investigación necesita encuadrar la ética; un libro no. Un libro necesita encuadrar la voz; el software no. Tu Framework debería encuadrar aquello contra lo que de verdad se juzga tu trabajo, y si eso son tres cosas o seis, ese es el número correcto.

Qué aspecto tiene un frame

Cada tipo de frame tiene su propio archivo de flavor, frame.<kind>.md. De la semilla software:

# {{title}}

## Shape

## Components

## Data and flow

## Boundaries and dependencies

Prosa suelta bajo encabezados estables. Un frame registra lo que es cierto ahora, y se revisa cada vez que ese juicio cambia. Nadie debería sentir que necesita predecir el futuro para escribir uno.

Los frames son Blueprints, no documentos de nivel superior

Esto despista, así que vale la pena ser tajante.

	Frame	Documento de nivel superior
Dónde	En la colección de encuadre	En la raíz
Shape	Sigue uno	No tiene
Frontmatter	Contrato completo	Libre
¿Validado?	Sí	No
Listado en `Framework.md` bajo	`## Collections`	`## Top-Level`
¿Repetido?	Sí, uno por tipo	No, es único

Los dos son prosa suelta, revisada en el sitio. La diferencia es la repetición: un shape se gana su sitio siendo estampado otra vez, y un documento escrito una sola vez no necesita molde.

Rellénalos primero

La forma más común de equivocarse con Eidos es saltarse los frames e ir directo a escribir Blueprints, porque los Blueprints se sienten como progreso y los frames como preámbulo.

Rellena los frames primero. Lleva una tarde, casi toda de discusión, y la discusión es el valor: descubres que dos personas llevan construyendo hacia públicos distintos antes de que ninguna escriba una spec que dé uno por supuesto.

Luego, cuando escribas un Blueprint, tienes algo concreto contra lo que contrastarlo: ¿esto sirve al público que describe el frame de Audience? ¿Encaja en el presupuesto y el calendario que fija el frame de Criteria? Si la respuesta es no, has encontrado algo que vale la pena saber antes de empezar el trabajo.

En el canvas

La semilla software declara - **Canvas:** file para su colección de encuadre: cada frame se dibuja como un nodo de archivo completo en lugar de como tarjeta, porque un frame es prosa pensada para leerse entera. Los Blueprints de una colección de specs se dibujan como tarjetas a partir de una sección, porque esos se ojean. Más sobre el canvas →