Backlog

The Backlog plugin keeps the work that realizes a blueprint beside the definition: one markdown file per task in the root’s backlog/ folder, each serving the blueprints it names by their permanent id, or none, on a board whose statuses and columns the root defines. A task is not a blueprint: never a collection item, never checked as one, never in the index. A task dies when the work ships; the blueprint stays. Off by default; eidos plugin enable backlog switches it on and declares the folder.

In the browser

Board: one column per configured column, a card per task with its type as an icon before the title, its id, its priority as an icon in its colour, and the root’s own properties it holds, dragged between columns to write the column’s first status. A column shows at most seven cards at its full height, fewer when the window has no room for seven, and scrolls within itself past them, its head and its count of every card staying in view, and a card dragged near its top or bottom scrolls it; the number is Column height on the Kanban tab (column_cards, 0 for every card). A task in a Done status not updated for more days than Hide done tasks on the Kanban tab (hide_done_days, empty by default, so none is hidden) is left off the board and out of its filters, its column saying how many it hides; it still lists in the tables, Attached tasks, and eidos backlog. The Backlog table has a column for status, priority, assignee, milestone, each of the root’s own properties, the blueprints, and the day updated, and the Drafts for status, the blueprints, and the day updated, until the Task properties tab puts a property On table or off it, in both at once. Backlog lists every task in a backlog status with Promote onto the board. Both filter by status, priority, assignee, type, milestone, and blueprint, and by any property of the root’s switched to Filter; the table sorts by any column, and status, priority, and assignee edit in the row. A Milestones table sits beside them, filtered the same way by the milestone properties switched to Filter. A search box leads the filters on the board, the Backlog table, the Drafts, and the Milestones, as on every table: it keeps the tasks holding every word typed, in any case, in the id, the title, or a value the row shows other than its dates, so T-4KQ7 finds that task and the tasks naming it as their parent or a dependency. The board’s filters, the Backlog table’s, and the Drafts’ are in the page’s address (/p/backlog?sprint=Sprint+12&assignee=plato, the search as q), so a filtered board can be bookmarked, shared, and reloaded; By status, By type, and My work keep their own addresses. Once filtered, the board, the Backlog table, and the Drafts offer Save as view, and a view saved is listed in the activity under Board, All tasks, or Drafts; My work, the statuses, and the types are the views every root starts with. Saved views →
A task opens in a modal from the board, the table, or a blueprint’s attached tasks, with Expand for its own page, and follows the task by its id when its file is renamed, from the page or from outside: properties typed by kind (a calendar for a date), the criteria ticked into the file, each section a card in the editor, the file as text, Comments’ threads at the foot, and Delete in every mode. A right-click on a row of the Backlog table or the Drafts, or on a card on the board, opens the task’s menu: Open, Open as a page, Assign to me (whoever you act as, beside anyone already on it), Copy id, the ways out to the file, and Delete.
New task, from the pages, the activity, or a blueprint’s attached tasks, asks for the task’s type and title before anything is made (with more than one type, none is taken until one is picked), then makes the file, or a draft of it, and opens it, where the rest is filled in.
Export, from the ⋮ at the top right of the Backlog table: Export this view… writes the tasks the table shows, in its order, and Export all tasks… every task in the folder, as one CSV file or an Excel workbook. A dialog asks for the Format (CSV to start, or Excel: a sheet whose first row, the fields’ names, stays in view and filters) and which fields: every property of the format and every one the root declares, each checked to start, and Content apart and unchecked: the task’s whole body, every section and its comment threads, the only way comments leave with a task. eidos backlog export does the same from the shell.
Backlog, an activity in the Activity Bar with the count of your open tasks, listing them by column, and My work: the open tasks assigned to you. Each status has a category, as in Jira: To Do, In Progress, or Done, set beside the status on the Settings tab (status_categories). A task in a Done status is finished and never shows in My work or the open counts, and a Done status is drawn green. A status left unset takes its category from where it sits: the backlog and the first column are To Do, the columns after it In Progress, and a status listed after every column’s (a Done kept off the board), or else the last column, is Done.
Attached tasks, a view in the Auxiliary Sidebar: the tasks serving the open blueprint, the count of open ones on its tab, and a way to start one for it or to attach one already written (Attach existing, which finds a task by its title or id among those not serving the blueprint yet). The editor’s block menu offers a task the same way.
The plugin’s settings page holds the statuses, columns, priorities (each with an icon and a colour, Jira’s from its place until one is chosen: up and red above the middle, equals and orange at it, down and blue below), milestones, a Task types tab (every field of a type and its sections labelled), and a Task properties tab. A task’s properties and a milestone’s are declared as the framework’s are: a card each, changed in the same form (the types a task property applies to ticked as checkboxes, its options added one at a time and put in order), placed in the order the reader shows them, and switched to Filter to be a dropdown over the board and the tables, or On table to be a column of the Backlog table and the Drafts. Beside Filter, Only show actively used in filters narrows that dropdown to the values an open task holds (one whose status is not in the Done category; for a milestone’s property, a milestone with an open task or none yet), so a sprint whose tasks are all Done drops out of the filter while it stays declared and on its tasks. The built-in properties a person sets take an Order there too, the order a task’s properties and New task show them in, the root’s own after them, and those a table can hold take On table (builtin_properties).

The task file

Frontmatter: id (the task’s permanent id, T- and four characters as a blueprint’s is B-, given when the task is made and never changed), title, type (one the root declares; absent means default), status, assignee (aliases from the root’s users), milestone, priority, dependencies (other tasks, by id), parent (a task, by id), created, updated, blueprints (the ids of the blueprints the task serves; none is fine), at (section and item: a place in the first of them, by content), and any property the root declares in the plugin’s settings. Labels are not the format’s: a root that wants them declares a labels List property with its options.

The body is the sections the task’s type declares, every one optional: by default ## Description, ## Acceptance Criteria (a checklist of - [ ] #1 … lines), ## Implementation Plan, and ## Implementation Notes; a root may add its own (References or Modified Files as links, Definition of Done as a checklist, Final Summary as text). Each sits inside a region of the plugin’s own,  … , rewritten whole when the section is set; anything else in the file is kept as found, so editing a task by hand is fine.

The file name follows the title, and the id never enters it: a title change renames the file, and its threads follow. A command takes a task by its id or its name. A task written before ids gets one from the check’s Assign id or eidos backlog ids. A template’s Tasks section is where a blueprint lists the tasks that serve it: in Framework Settings → Templates, each section has a type beside its heading, Text by default or Tasks while the Backlog is on, and a Tasks section holds a  region. In a blueprint of that template the plugin writes the tasks there after any change, adding the section’s heading in the template’s order where the blueprint lacks it, and takes out a list written anywhere else, such as the foot of an older body. A template with no Tasks section shows no tasks in the text; they still list in Attached tasks. The link lives on the task; never type into the region.

Types, statuses, and columns

types is the kinds of task the root works in, each a name, a title, an icon and a colour, and the sections its body holds: a template per kind, as a collection has variants. A root starts with one, default. statuses is the root’s ordered list; columns maps each board column to one or more statuses; a status in no column is a backlog status, listed on the Backlog page and never on the board. The default is Jira’s: Intake, To Do, In Progress, In Review, Done, with Intake on the backlog. A new task lands in default_status.

Drafts

A draft is a task not yet in the folder: the same file, kept under .eidos/plugins/backlog/drafts/ (shared with the root) or .eidos/plugins/backlog/local/drafts/ (private, never committed), in no list until it publishes, though show and set reach it by its name as they do a task. A draft has no threads and is projected nowhere.

On disk

backlog/ (or any folder declared owned_by: "@backlog/tasks"): the tasks, one file each. The root →
.eidos/plugins/backlog/settings.yaml, shared: types, sections, statuses, columns, default_status, priorities, priority_icons, priority_colors, column_cards, hide_done_days, milestones, milestone_properties, properties, and builtin_properties.
.eidos/plugins/backlog/drafts/ and local/drafts/: the drafts.

From the shell

eidos backlog                                       # every task, grouped by column
eidos backlog --status "In Progress" --assignee ada # --column, --milestone, --blueprint, --type, --where key=value, --json
eidos backlog --search "login page"                 # every word, in any case, in the id, the title, or a value the row shows
eidos backlog drafts --search T-4KQ7                # a draft by the task id it holds
eidos backlog add "Rate limit the login form" --for @login --type bug --criterion "Locks after five tries"
eidos backlog show T-4KQ7                            # a task by its id, or by its file name
eidos backlog set rate-limit-the-login-form --status "In Progress"
eidos backlog set rate-limit-the-login-form --body implementation-notes="Tried a sliding window first."
eidos backlog check rate-limit-the-login-form 1     # tick criterion #1; --undo, --in <section>
eidos backlog promote <task>                        # from the backlog onto the board
eidos backlog remove T-4KQ7                          # delete a task, as the page's Delete does
eidos backlog export --assignee ada --field id --field title --content --out tasks.csv  # the tasks the filters keep; --json
eidos backlog export --out tasks.xlsx                # an Excel workbook, every task and every field
eidos backlog types                                 # the types; sections [--type] lists a type's sections
eidos backlog configure:property add labels --type List --filter   # a task property; set|remove, properties lists them
eidos backlog configure:type add bug --icon bug --color red --section "Steps:checklist"  # a task type; set|remove
eidos backlog add "Old task" --property labels=finance,feature --created 2025-03-01 --updated 2025-04-02  # an import
eidos backlog draft "An idea" --private             # drafts, draft:move <draft> shared|private, publish <draft>
eidos backlog project                               # rewrite every backlog:tasks region that drifted
eidos backlog ids                                   # ids for tasks written before them, and references moved onto ids

set sets one thing per option: --type, --status, --title, --assignee, --milestone, --priority, --for, --section, --item, --dependency, --parent, --property name=value, --description, or --body key=text for one declared section.

--property is typed by the property’s declaration: a List takes its items comma-separated or the flag repeated, a Number a number, a Checkbox on or off. Every write stamps updated with today; --created and --updated on add and set give the dates instead, so an import keeps the ones it came with. configure:property and configure:type write the task properties and task types to the plugin’s settings.yaml as its page does, one entry at a time; --dry-run prints the entry and writes nothing.

To take a task as an agent: read its blueprints, set the status to the working column’s, do the work in the blueprint or the code, tick the criteria as they are met, write what you learned under Implementation Notes, and set the status to the last column’s. Never write a task’s name into a blueprint.

What the check reports

backlog/blueprint-missing (a task names a blueprint the root does not have), backlog/status-unknown, backlog/type-unknown, backlog/dependency-missing (a dependency the backlog does not have), backlog/id-missing (a task written before ids; Assign id fixes it), backlog/id-duplicate (two files holding one id), backlog/reference-by-name (a dependency or parent still written as a file name; Use ids fixes it), and backlog/region-stale (a blueprint’s backlog:tasks region that is not what the tasks would write; Project fixes it). Off again, the folder and its tasks stay where they are, still declared, and nothing of the plugin shows.