Decisions

The Decisions plugin keeps what was decided about the blueprints as records of their own: one markdown file per decision in the root’s decisions/ folder, each made for the blueprints and tasks it names by their permanent ids. A decision is not a blueprint and not a task: never a collection item, never checked as one, never in the index. It is small, closer to a comment than to a task: a title that says what was decided, a type, a status, who logged it, and notes on why. An agent that decides something on its own while working logs it as itself, for the framework owner to confirm. Off by default; eidos plugin enable decisions switches it on and declares the folder.

In the browser

• Decisions, an activity in the Activity Bar with the count of unconfirmed decisions on its icon: All decisions, Unconfirmed (the inbox, with its count), Assigned to me (the unconfirmed decisions handed to you, with their count), the table’s saved views under Decision views, By status, By type, and the settings at its foot.
• The Decisions table: a row per decision with its type as an icon before the title and its id, its status and its assignee changed in the row, who logged it, the blueprints, and the days created and confirmed. It filters by category, status, type, assignee, blueprint, and who logged it, with a search box leading the filters as on every table, and any filter is kept as a shared or private view with Save as view. A right-click on a row opens its menu: Open, Open as a page, Confirm, Assign to me, Copy id, the ways out to the file, and Delete.
• A decision opens in a modal from the table or a blueprint, with Expand for its own page, built as a task’s reader is: the properties edited in place, the notes in Reading and Editor, the file as Source, Confirm while it is unconfirmed, and Comments’ threads at the foot.
• On the Home, Decisions assigned to you lists the unconfirmed decisions handed to you, so one passed to you to confirm or to act on is seen there; once it is confirmed or set aside it leaves the card.
• New decision, from the page or the activity, asks for the type and the decision in a line, then makes the file and opens it.
• In a blueprint, each decisions:log region is drawn as the live list of the decisions made for it, with Confirm on an unconfirmed one and Log a decision, which logs one for the blueprint in the section’s first type. Decisions, a view in the Auxiliary Sidebar, lists the open blueprint’s.
• The plugin’s settings page holds the statuses (each with its category and colour), the default status, the Decision types (a name, title, icon, colour, and what it is for), and the default type.

The decision file

Frontmatter: id (the decision’s permanent id, D- and four characters as a task’s is T-, given when it is made and never changed), title (the decision itself, in a line), type (one the root declares), status, author (the alias of the root user who logged it, an agent’s own when an agent logged it), assignee (the aliases of the root users it is handed to, to confirm it or to act on it), blueprints (the ids of the blueprints it was made for), tasks (the ids of the Backlog tasks it was made for), created, updated, confirmed (the day it crossed into a confirmed status) and confirmed_by (who took it there), and any property the root declares in the plugin’s settings.

The body is the notes: why, what else was weighed, what it rules out. It has no sections the root declares. The file name follows the title, and a command takes a decision by its id or its file name. A decision is a Comments host addressed by its id (decisions:D-…); a thread on it, and an @mention in the thread, is how someone is asked about it.

Types and statuses

types keeps kinds of decision apart, so a development decision an agent made on its own is never mistaken for a scope decision or one a meeting settled. Each is a name (the decision’s type), a title, an icon and a colour, and a meaning. A root starts with three:

• Development: how it is built, an approach, a library, or a trade-off chosen while building it. An agent logs one it made on its own. add takes it when no type is given (default_type).
• Scope: what is in and what is out, a behavior promised or dropped, a boundary drawn.
• Meeting: what a meeting settled, logged from its notes by whoever has them.

statuses is the root’s ordered list, each in one of three categories (status_categories): unconfirmed (waiting on whoever decides: the inbox), confirmed, or closed (set aside without being confirmed). A status not named is unconfirmed. A status crossing into the confirmed category stamps confirmed with the day and confirmed_by with who took it there; leaving it clears both. The default is Proposed, Confirmed, Rejected, and Superseded, with a new decision landing in default_status, Proposed. There is no priority.

Where a blueprint shows its decisions

In Framework Settings → Templates, each section of a template has a type beside its heading: Text, the default, Decisions, or Tasks (where the Backlog lists the tasks that serve the blueprint), each offered while its plugin is on. A Decisions section names the decision types it shows (none is every type), keeps its intent (a type’s meaning fills an empty one) and any default content, and writes a region at the end of its body:

## Constraints & Decisions

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

A blueprint made from the template carries the region under that heading, and the plugin writes into it, after any change, every decision made for the blueprint: each in the first region that collects its type, as a line with its title linked to its file, its id, its status, and its author, ticked once confirmed. A decision whose type only a section the blueprint lacks collects gets that section, its heading added in the template’s order; one whose type no section of the template collects shows nowhere in the text, only in the Decisions view beside the blueprint. A blueprint with no decision and no region is not touched. The link lives on the decision; never type into the region.

On disk

• decisions/ (or any folder declared owned_by: "@decisions/records"): the decisions, one file each. The root →
• .eidos/plugins/decisions/settings.yaml, shared: statuses, status_categories, status_colors, default_status, types, default_type, and properties. The root’s own decision properties are declared here by hand for now.

From the shell

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

Every command takes --json. A write is signed with --as <alias>, else EIDOS_USER, else the acting user, and the alias is kept as the decision’s author (or its confirmed_by); an alias that is nobody is refused with the eidos users add that creates it. Every write stamps updated.

An agent logs a decision it made itself as it makes it, as itself, attached to the blueprints and tasks it concerns: it adds itself once with eidos users add "<Its name>" --alias <alias> --agent when eidos users does not list it, and passes --as <alias> on every add. It never confirms, rejects, or changes the status of a decision it logged; the owner does that.

What the check reports

decisions/blueprint-missing (a decision names a blueprint the root does not have), decisions/task-missing (a task the backlog does not have), decisions/status-unknown, decisions/type-unknown, decisions/id-missing, decisions/id-duplicate (two files holding one id), and decisions/region-stale (a blueprint whose decisions:log regions are not what its decisions would write; Project fixes it). Off again, the folder and its decisions stay where they are, and nothing of the plugin runs.