Soberanía de la Intención · Designio — Recursos

Plantilla maestra de EIS

Plantilla de una Especificación Ejecutable de Intenciones con sus cuatro elementos canónicos, en Markdown legible más bloque YAML máquina-procesable, ligados y firmados conjuntamente. Se usa cada lunes en el refinamiento del sprint.

Fase: Sprint semanal
Origen en el libro: cap. 1 y 2, pp. 24-27 y 70
Versión: 1.0
Fecha: 13 de junio de 2026

Descargar .md Descargar .yaml

Plantilla maestra de EIS

Plantilla de la Metodología Designio · «Soberanía de la Intención» (origen: cap. 1 y 2, pp. 24-27 y 70) · designio.dev

Qué es y cuándo se usa

La EIS (Especificación Ejecutable de Intenciones) es la unidad mínima de intención sobre la que gira toda la metodología: una especificación «lo bastante clara y estructurada como para que un agente de IA pueda ejecutarla sin malinterpretarla, y lo bastante legible como para que un humano pueda leerla, entenderla y auditarla» (p. 24). No describe el cómo técnico, sino el qué y el porqué del negocio.

Reglas de uso:

Una EIS gobierna una única intención. Un requisito de negocio complejo se descompone en varias EIS pequeñas e independientes, que se construyen, prueban y validan por separado.
Cada EIS se compone de cuatro elementos canónicos (p. 25): contexto técnico, restricciones de arquitectura, criterios de aceptación (intención dirigida por pruebas: cada criterio es a la vez una prueba que el resultado tiene que pasar) y definición de «hecho».
Las EIS se versionan: cada cambio en la intención del negocio queda registrado con su histórico.
Formato doble firmado conjuntamente (p. 26): la EIS se redacta en Markdown legible y se acompaña de un fichero máquina-procesable (p. ej. YAML, p. 70), ligados de modo que una sola firma cubra los dos. Lo innegociable no es el formato, es la ausencia de ambigüedad.

Esta plantilla dirige las sesiones de refinamiento con el Business Owner (lunes AM del sprint) para generar las «n» EIS atómicas de cada requisito.

EIS-[NUMERO] — [TITULO_DE_LA_INTENCION]

Versión: [VERSION] · Fecha: [FECHA] · Estado: [BORRADOR | CERTIFICADA | SATISFECHA] Requisito de origen: [ID_O_TEXTO_DEL_REQUISITO_DE_NEGOCIO]

Contexto técnico

Sitúa qué se va a hacer y sobre qué parte del sistema.

[QUE_DEBE_PODER_HACERSE, QUIEN_LO_HACE, Y_EN_QUE_MODULO_O_SERVICIO_RESIDEN_LOS_DATOS_O_LA_FUNCIONALIDAD]

Restricciones de arquitectura

Límites que la construcción no puede cruzar (heredan del ADN Arquitectónico y del MAP del proyecto).

[RESTRICCION_1: p. ej. la operación debe realizarse mediante la API REST del dominio]
[RESTRICCION_2: p. ej. no se permite lógica en el frontend más allá de la validación básica]
[RESTRICCION_3: p. ej. mantener compatibilidad con el modelo de datos existente]

Criterios de aceptación

Definen, de forma comprobable, cuándo la pieza está bien hecha. Cada criterio es una prueba.

Si [CONDICION_1], el sistema [COMPORTAMIENTO_ESPERADO_1].
Si [CONDICION_2], la operación [COMPORTAMIENTO_ESPERADO_2: p. ej. se rechaza].
Si [CONDICION_3], la operación [COMPORTAMIENTO_ESPERADO_3: p. ej. falla].

Definición de «hecho»

Qué tiene que existir para considerar la EIS completada.

[ENTREGABLE_1: p. ej. endpoint funcional y probado]
[ENTREGABLE_2: p. ej. validaciones implementadas]
[ENTREGABLE_3: p. ej. pruebas unitarias y de integración generadas y ejecutadas]
[ENTREGABLE_4: p. ej. documentación actualizada]

Firma

Rol	Nombre	Firma ✍	Fecha
Intent Director	[NOMBRE]	[FIRMA]	[FECHA]

Fichero acompañante máquina-procesable

Genera este YAML junto al Markdown y fírmalos conjuntamente (una sola firma cubre los dos).

eis:
  id: "EIS-[NUMERO]"
  titulo: "[TITULO_DE_LA_INTENCION]"
  version: "[VERSION]"
  fecha: "[FECHA_ISO]"
  estado: "[borrador | certificada | satisfecha]"
  requisito_origen: "[ID_DEL_REQUISITO]"
  contexto_tecnico: >
    [QUE_SE_VA_A_HACER_Y_SOBRE_QUE_PARTE_DEL_SISTEMA]
  restricciones_de_arquitectura:
    - "[RESTRICCION_1]"
    - "[RESTRICCION_2]"
    - "[RESTRICCION_3]"
  criterios_de_aceptacion:
    - id: "C1"
      criterio: "Si [CONDICION_1], el sistema [COMPORTAMIENTO_ESPERADO_1]."
    - id: "C2"
      criterio: "Si [CONDICION_2], la operación [COMPORTAMIENTO_ESPERADO_2]."
    - id: "C3"
      criterio: "Si [CONDICION_3], la operación [COMPORTAMIENTO_ESPERADO_3]."
  definicion_de_hecho:
    - "[ENTREGABLE_1]"
    - "[ENTREGABLE_2]"
    - "[ENTREGABLE_3]"
  firma:
    rol: "Intent Director"
    nombre: "[NOMBRE]"
    fecha: "[FECHA_ISO]"

Nota: la EIS Maestra

En la Fase 0 (proceso Manual-to-EIS), el Intent Director consolida los talleres en una EIS Maestra, que según el libro (p. 70) contiene estos apartados estructurados: Contexto de Misión (el «para qué» del proyecto, derivado del MVI), Restricciones de Dominio (lenguaje y reglas, derivados del Taller de DDD), Límites de Ejecución (anclajes y estándares) y Criterios de Aceptación de Negocio (qué debe ocurrir exactamente para que el Business Owner valide la entrega). La EIS Maestra la hace el Intent Director y la revisan el Delivery Lead y el Arquitecto.