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	no (on in a root made before it turned off, which keeps it)	`.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
AI Agent	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/agent/conversations/`, local 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 local local.yaml overriding it. A new root writes every switch as it is made, each at the default in the table; a root made earlier names no switch for one it never set and keeps the default it was made under, so Canvas stays on there. 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 local, on one machine 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 local 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.

A plugin’s users

A plugin may run users of its own, as the AI Agent runs @agent. It registers each through the host, host.user({ name, alias, role, agent, access, accessHint }), and the user is listed as the plugin’s by eidos users and on the Users page while the plugin is on: its name, alias, and role are the plugin’s and read-only there, it has no email and no access select, and it cannot be removed. Whether it may change the framework is the plugin’s answer, editor or none, asked each time it matters, so it follows a setting of the plugin’s; a root that marks no person an editor leaves everyone one, plugin users included. Nothing is written until the plugin keeps the user, the first time it signs something: then it goes into settings.yaml marked plugin: <name>, so what it signed stays readable once the plugin is off.