Decisions

El plugin Decisions guarda lo que se decidió sobre los Blueprints (los planos) como registros propios: un archivo markdown por decisión en la carpeta decisions/ de la raíz, cada una tomada para los Blueprints y las tareas que nombra por sus ids permanentes. Una decisión no es un Blueprint ni una tarea: nunca es un elemento de colección, nunca se comprueba como tal, nunca está en el índice. Es pequeña, más cercana a un comentario que a una tarea: un título que dice lo que se decidió, un tipo, un estado, quién la registró y notas sobre el porqué. Un agente que decide algo por su cuenta mientras trabaja la registra como sí mismo, para que el dueño del framework la confirme. Desactivado por defecto; eidos plugin enable decisions lo activa y declara la carpeta.

En el navegador

• Decisions, una actividad en la barra de actividad con el recuento de decisiones sin confirmar en su icono: All decisions, Unconfirmed (la bandeja de entrada, con su recuento), Assigned to me (las decisiones sin confirmar que te han pasado, con su recuento), las vistas guardadas de la tabla en Decision views, By status, By type y los ajustes al pie.
• La tabla de Decisions: una fila por decisión con su tipo como icono antes del título y su id, su estado y su persona asignada cambiados en la fila, quién la registró, los Blueprints y los días de creación y de confirmación. Filtra por categoría, estado, tipo, persona asignada, Blueprint y quién la registró, con un cuadro de búsqueda al frente de los filtros como en toda tabla, y cualquier filtro se guarda como vista compartida o privada con Save as view. Un clic derecho en una fila abre su menú: Open, Open as a page, Confirm, Assign to me, Copy id, las salidas al archivo, y Delete.
• Una decisión se abre en un modal desde la tabla o desde un Blueprint, con Expand para su propia página, construida como el lector de una tarea: las propiedades editadas en su sitio, las notas en Reading y Editor, el archivo como Source, Confirm mientras está sin confirmar, y los hilos de Comments al pie.
• En el Home, Decisions assigned to you lista las decisiones sin confirmar que te han pasado, para que una que te toca confirmar o sobre la que te toca actuar se vea ahí; cuando se confirma o se aparta, sale de la tarjeta.
• New decision, desde la página o la actividad, pide el tipo y la decisión en una línea, luego crea el archivo y lo abre.
• En un Blueprint, cada región decisions:log se dibuja como la lista viva de las decisiones tomadas para él, con Confirm en una sin confirmar y Log a decision, que registra una para el Blueprint en el primer tipo de la sección. Decisions, una vista en la barra lateral auxiliar, lista las del Blueprint abierto.
• La página de ajustes del plugin tiene los estados (cada uno con su categoría y su color), el estado por defecto, los Decision types (un nombre, un título, un icono, un color y para qué sirve) y el tipo por defecto.

El archivo de decisión

Frontmatter: id (el id permanente de la decisión, D- y cuatro caracteres como el de una tarea es T-, dado cuando se crea y nunca cambiado), title (la decisión misma, en una línea), type (uno que declara la raíz), status, author (el alias del usuario de la raíz que la registró, el del propio agente cuando la registró un agente), assignee (los alias de los usuarios de la raíz a quienes se pasa, para confirmarla o actuar sobre ella), blueprints (los ids de los Blueprints para los que se tomó), tasks (los ids de las tareas del Backlog para las que se tomó), created, updated, confirmed (el día en que pasó a un estado confirmado) y confirmed_by (quién la llevó ahí), y cualquier propiedad que declare la raíz en los ajustes del plugin.

El cuerpo son las notas: por qué, qué más se sopesó, qué descarta. No tiene secciones que declare la raíz. El nombre del archivo sigue al título, y un comando toma una decisión por su id o por su nombre de archivo. Una decisión es un anfitrión de Comments al que se dirige por su id (decisions:D-…); un hilo sobre ella, y una @mención en el hilo, es como se le pregunta a alguien por ella.

Tipos y estados

types mantiene separadas las clases de decisión, para que una decisión de desarrollo que un agente tomó por su cuenta nunca se confunda con una de alcance o con una que zanjó una reunión. Cada uno es un nombre (el type de la decisión), un título, un icono y un color, y un significado. Una raíz empieza con tres:

• Development: cómo se construye, un enfoque, una biblioteca o una concesión elegida al construirlo. Un agente registra una que tomó por su cuenta. add la toma cuando no se da tipo (default_type).
• Scope: qué entra y qué queda fuera, un comportamiento prometido o descartado, un límite trazado.
• Meeting: lo que zanjó una reunión, registrado a partir de sus notas por quien las tenga.

statuses es la lista ordenada de la raíz, cada uno en una de tres categorías (status_categories): unconfirmed (esperando a quien decide: la bandeja de entrada), confirmed o closed (apartada sin confirmarse). Un estado sin nombrar es unconfirmed. Un estado que pasa a la categoría confirmed pone en confirmed el día y en confirmed_by quién la llevó ahí; salir de ella borra los dos. El predeterminado es Proposed, Confirmed, Rejected y Superseded, y una decisión nueva cae en default_status, Proposed. No hay prioridad.

Dónde muestra un Blueprint sus decisiones

En los ajustes del Framework (el marco), en Templates, cada sección de un template (la plantilla) tiene un tipo junto a su encabezado: Text, el predeterminado, Decisions o Tasks (donde el Backlog lista las tareas que sirven al Blueprint), cada uno ofrecido mientras su plugin está activo. Una sección Decisions nombra los tipos de decisión que muestra (ninguno es todos los tipos), conserva su intención (el significado de un tipo rellena una vacía) y cualquier contenido por defecto, y escribe una región al final de su cuerpo:

## Constraints & Decisions

<!-- decisions:log types=development,scope -->
<!-- /decisions:log -->

Un Blueprint creado a partir del template lleva la región bajo ese encabezado, y el plugin escribe en ella, tras cualquier cambio, cada decisión tomada para el Blueprint: cada una en la primera región que recoge su tipo, como una línea con su título enlazado a su archivo, su id, su estado y su autor, marcada una vez confirmada. Una decisión cuyo tipo solo recoge una sección que el Blueprint no tiene recibe esa sección, con su encabezado añadido en el orden del template; una cuyo tipo no recoge ninguna sección del template no aparece en ningún sitio del texto, solo en la vista Decisions junto al Blueprint. Un Blueprint sin decisiones y sin región no se toca. El vínculo vive en la decisión; nunca escribas dentro de la región.

En disco

• decisions/ (o cualquier carpeta declarada owned_by: "@decisions/records"): las decisiones, un archivo cada una. La raíz →
• .eidos/plugins/decisions/settings.yaml, compartido: statuses, status_categories, status_colors, default_status, types, default_type y properties. Las propiedades de decisión propias de la raíz se declaran aquí a mano por ahora.

Desde la terminal

eidos decisions                                     # every decision, grouped by category
eidos decisions --unconfirmed                       # the inbox; --status, --type, --blueprint, --task, --author, --assignee, --where key=value, --search, --json
eidos decisions add "Cache the index in memory" --type development --for @search --task T-4KQ7 --notes "Why, and what else was weighed" --as plato
eidos decisions show D-7M2P                         # a decision by its id, or by its file name
eidos decisions set D-7M2P --status Rejected        # --title, --type, --for, --task, --assignee, --notes, --property name=value
eidos decisions confirm D-7M2P D-9XQ4               # to the first confirmed status; --as
eidos decisions types                               # the types and what each is for; statuses lists the statuses
eidos decisions project                             # rewrite every decisions:log region that drifted; or one blueprint
eidos decisions remove D-7M2P                       # delete a decision, as the page's Delete does

Todo comando acepta --json. Una escritura se firma con --as <alias>, si no con EIDOS_USER, si no con el usuario que actúa, y el alias se guarda como el author de la decisión (o su confirmed_by); un alias que no es de nadie se rechaza con el eidos users add que lo crea. Cada escritura pone updated en la fecha de hoy.

Un agente registra una decisión que tomó él mismo en el momento en que la toma, como sí mismo, adjunta a los Blueprints y las tareas a los que afecta: se añade una vez con eidos users add "<Su nombre>" --alias <alias> --agent cuando eidos users no lo lista, y pasa --as <alias> en cada add. Nunca confirma, rechaza ni cambia el estado de una decisión que registró; eso lo hace el dueño.

Qué informa la comprobación

decisions/blueprint-missing (una decisión nombra un Blueprint que la raíz no tiene), decisions/task-missing (una tarea que el backlog no tiene), decisions/status-unknown, decisions/type-unknown, decisions/id-missing, decisions/id-duplicate (dos archivos con un mismo id) y decisions/region-stale (un Blueprint cuyas regiones decisions:log no son lo que sus decisiones escribirían; Project lo arregla). Desactivado de nuevo, la carpeta y sus decisiones se quedan donde están, y nada del plugin se ejecuta.