Acotar con no-objetivos

Eidos le da este estatus a exactamente una sección. Vale la pena entender por qué, porque es también la sección más fácil de dejar vacía.

Por qué los no-objetivos hacen el trabajo

Una lista de lo que algo hace no tiene límite. Siempre hay otro comportamiento que podrías añadir, y nada en la lista te dice dónde parar. Dos personas pueden leer el mismo conjunto de criterios de aceptación y discrepar sobre si una funcionalidad está dentro del alcance, porque los criterios no dicen nada sobre la frontera.

Una lista de lo que algo no va a hacer es una decisión. Tiene autor, fecha y diff. Se puede señalar en una revisión. Responde a la pregunta que de verdad cuesta dinero seis meses después: «espera, ¿esto no cubría X?».

Fíjate en el no-objetivo de la spec de ejemplo:

## Out of Scope

- Cross-account resume. A shared TV is one device, not one person.

Esa sola línea hace tres cosas que ninguna lista de comportamientos puede. Evita que una petición de funcionalidad plausible se trate como un error. Registra el razonamiento, para que la siguiente persona pueda ver si el razonamiento sigue valiendo. Y termina una discusión antes de que ocurra, por escrito y con un responsable asociado.

Escríbela la segunda

El instinto es escribir los no-objetivos al final, cuando el Blueprint está por lo demás completo. Eso es al revés, y produce secciones vacías.

Escríbela justo después de la sección de apertura:

Intent: por qué existe esto, y quién tiene el problema.
Out of Scope: qué no va a hacer deliberadamente.
Todo lo demás.

La razón es que los no-objetivos son más difíciles de ver una vez que has escrito los comportamientos. Para entonces llevas rato pensando en términos de lo que la cosa hace, y la frontera se ha vuelto invisible. Escríbela mientras la forma del problema sigue a la vista.

Qué va dentro

Funcionalidades adyacentes que descartaste deliberadamente, con el motivo.
Casos que has decidido no cubrir: un tipo de usuario, un dispositivo, una configuración regional.
Cosas que un lector razonable asumiría incluidas. Estas son las valiosas.
Fronteras con otros Blueprints, idealmente como enlace: «El ranking es problema de Search Results, no de este.»

Qué no

«No en la v1.» Eso es un calendario, no una decisión de alcance, y es seguimiento de trabajo, que se pudre. Si de verdad está fuera, dilo y di por qué. Si de verdad es para más adelante, va en un documento de nivel superior tipo Roadmap.

«Estaría bien tenerlo.» O está prometido o no lo está. Los no-objetivos son para el no.

Cosas que nadie asumiría jamás. Una lista de cien no-objetivos se lee como nerviosismo y esconde los tres que importan.

Sigue sin ser una barrera dura

La convención termina con una matización que importa: sigue sin ser una barrera dura.

Un Blueprint con la sección de no-objetivos vacía se saca a la luz, se señala la primera entre las secciones que faltan y se ofrece, no se rechaza. Eso es portabilidad antes que prescripción aplicándose a la sección que más le importa al estándar. Eidos se da cuenta; no bloquea tu commit.

Que es el diseño correcto. Un validador que rechaza archivos acaba esquivado, y un validador esquivado no señala nada.

Dónde la conserva un flavor más ligero

Mira lo que conserva el flavor más pequeño de la semilla software:

`spec.micro` conserva	`spec.micro` descarta
Intent	Implementation Notes
Assumptions	Las subcategorías de AC
Open Questions	Dependencies
Behaviors & Acceptance Criteria	Testing
Out of Scope	Constraints & Decisions

Testing y Dependencies pueden esperar a que la unidad se asiente. El alcance no, así que micro lleva Out of Scope incluso en su versión más pequeña. Cuando diseñes tu propio flavor ligero, mantén la misma regla: la sección de no-objetivos nunca es la que recortas.

Cuando decir que no es el trabajo de alguien

Los no-objetivos son el punto donde el rol de Framework Owner deja de ser organizativo y pasa a ser estructural. Añadir un comportamiento es una decisión que cualquiera puede defender; sacar uno del alcance requiere autoridad.

Una raíz sin dueño claro acumulará comportamientos y perderá no-objetivos, porque nadie se siente con derecho a escribir los segundos. Ese es el modo de fallo que hay que vigilar, y aparece en el diff antes que en el producto.

Dar forma a tu Framework
Roles y el actor: quién decide.