Plugins

Beyond scaffolding, checking, and indexing, everything the CLI does is a plugin: a named tool behind one contract, with its own folder under .eidos/plugins/<name>/, switched on per root. Nine ship in the package.

The premise

Eidos is not another markdown editor. It facilitates one thing: the definition of a product, the root of blueprints, which is the source of truth for what the product is. Everything else the tooling does serves that truth and is subordinate to it. A canvas draws it; a comment discusses it; a task serves it; a version names a commit of it. None of them becomes a second definition beside it.

Two rules follow:

Every plugin lives in its own workspace, .eidos/plugins/<name>/, or in a root folder declared as its own. Switching one off leaves the definition exactly as it was.
Every plugin is built for this lifecycle, not for general use. Anyone who wants a whiteboard or a task board for its own sake opens another tool.

What ships

Plugin	Facilitates	On by default	Keeps it in
Canvas	Drawing the definition: pages of sketches and blueprints, styled by the framework’s properties	yes	`.eidos/plugins/canvas/<id>.yaml`
Git	Reading its history: a blueprint’s commits and a diff viewer, Source control (what changed under the root, a commit of it), the identity that signs a comment, the recorded versions, `git mv` and `git rm` behind every rename and delete	where the root is a repository	the viewer command in its `local.yaml`
Comments	Discussing it: threads on a blueprint, a doc, a canvas page, or a task, anchored to a heading or an item and projected into the file as readable text	yes	`.eidos/plugins/comments/threads/<id>.yaml`, a `comments:threads` region while the file has threads
Backlog	The work that serves it: tasks with statuses, columns, types, milestones, and drafts, on a board and in a table, never inside a blueprint	no	a `backlog/` folder the plugin owns, settings in its folder
Decisions	What was decided about it: decisions with types and statuses, confirmed from an inbox and listed in the blueprints they were made for	no	a `decisions/` folder the plugin owns, settings in its folder
Assets	The files that are not markdown: images, PDFs, anything, listed, linked to blueprints and tasks, embedded or linked from the editor	no	the root’s `assets/` folder, an index in its folder
Linter	Keeping the markdown in one form: rules the root sets, applied on every save and reported by the check	yes	`.eidos/plugins/linter/settings.yaml`
Terminal	Your own shell in the Panel, started in the root	no	nothing on disk
Plato	A conversation with the coding agent you already run (Claude Code, Codex, or any command speaking ACP), what the page has open carried as context	yes	`.eidos/plugins/plato/conversations/`, private ones under `local/`

Each has a page of its own in this section: what it adds to the browser, what it keeps on disk, its commands, and what the check reports for it. The browser → · Plugin commands →

The switch

A plugin is on or off per root: plugins.<name>: true | false in the CLI’s settings.yaml, shared with the root, with the same line in the private local.yaml overriding it. eidos plugin lists them, eidos plugin enable|disable <name> writes the switch, eidos plugin set <name> <setting> <value> writes one of its settings to the file its scope names, eidos setup offers them as a menu, and the browser’s Plugins page has one switch and one settings form per plugin. Off, a plugin registers nothing: no command, route, finding, view, or region; its folder and files stay where they are for the day it comes back.

eidos instructions <plugin> prints a plugin’s guide while it is on, and a plugin that has something to say to an agent says it in AGENTS.md under the Eidos nudge.

Where a plugin keeps things

The standard gives a tool one name and four places to use it:

Its folder, .eidos/plugins/<name>/, committed with the framework: settings.yaml for what the root decides, local.yaml and local/ for what is private, one person’s and never committed (the root’s .eidos/.gitignore carries both). The CLI’s own folder is eidosmd/: the plugin switches, strictness, users, the tag prefix, the versions, and the shared drafts travel with the root; the theme, the editor, the workbench’s layout, and the private drafts stay on the machine.
Its root folders, declared under folders with owned_by: "@<name>/<kind>" (Backlog’s backlog/, Assets’ assets/). What such a folder holds and what is checked inside are the tool’s to say; the standard reads none of it. The root →
Its properties, properties.tools.<name> in Framework.yaml, and a key named for itself on any property row (canvas styles a node by a property’s value). Properties →
Its regions,  to  inside a markdown file: a span the tool owns and rewrites wholesale (Comments’ threads at the foot of a blueprint, an image Assets embedded). Regions →

The standard reads none of it, eidos check never faults it, and eidos migrate carries it across untouched.