The Browser

eidos browser                       # http://127.0.0.1:6180, this machine only
eidos browser --port 7000 --no-open

Nothing in the page that is not a command

Every write runs the same code as new, check, index, or a plugin’s command. The files stay the truth: the server watches the root and the page refreshes when a file changes on disk, so an agent editing beside you shows up as it works. A view with unsaved edits is never overwritten; it asks whether to refresh or keep yours.

The workbench

The frame is VS Code’s. A command center across the top opens the palette: empty, it lists what you opened recently and matches blueprints, docs, drafts, tasks, canvases, and asset files by title, id, and path as you type (T-A7GJ finds the task, B-5KFM the blueprint), and what you pick opens on its own page, not in the reader over a table; > lists every command the host and each plugin registered, with its key. ⌘P or / opens it, ⇧⌘P opens it on the commands (the keys are a preference: VS Code’s, /, or ⌘K). Back and forward arrows sit beside it.

/ opens on the Home: the health check’s findings first, errors before warnings; what the plugins put there (the tasks assigned to you and the board by column, from the Backlog); then the root’s blueprints by collection, with its documents and drafts counted. The Home’s head is the root’s name: the product it defines (eidos setup --product, or the pencil beside it), else the repository it sits in. The browser’s tab carries the same name.

An Activity Bar at the left edge holds a house for the Home first, then one icon per view in the Primary Sidebar: the Root view first (the top-level docs, the drafts, one entry per collection, each plugin’s group), then each plugin’s activity in the order you set (Canvas, Comments, Backlog, Source control, Assets, Settings); the person you act as and a gear sit at its foot. An Auxiliary Sidebar at the right edge and a Panel under the main area are rows of tabs a plugin fills (a blueprint’s history, its attached tasks and assets, Plato, the Terminal), hidden until shown. Every sector shows, hides, and resizes as VS Code’s do (⌘B, ⌥⌘B, ⌘J, a drag on its edge), and all of it is remembered per person in local.yaml. Where a plugin puts a view is only where it starts: drag its icon or its tab onto another sector (Plato into the Panel, the Terminal into the Primary Sidebar), or right-click it for Move to, and it stays there on every root until you move it back or run Reset View Locations.

Search, first among the activities until you drag it elsewhere, is the command center’s search kept open in the Primary Sidebar (⇧⌘F): what matches by title first, then every mention in the text with the match marked. Tabs, in the desktop app (a browser has tabs of its own): pages open as tabs above the main area. A page opens in the tab showing, ⌘-click a link or press + for a tab of its own, pin a tab to keep its page, and close one with its ×, a middle click, or its menu; close the last and the main area stays empty until you open a page. The tabs open are remembered for each root. Focus mode, under Preferences → Workbench, draws one page at a time instead. Find in File (⌘F) finds text in the page or file open, every match marked, with Enter and ⇧Enter to step through them.

Collections as tables

Each collection is a table: one row per blueprint, the properties that apply to it as columns, sortable from the header, with a search box, a column picker, and a filter per property flagged as one; a property also switched to Only show actively used in filters offers only the values a blueprint in the collection holds. A filter holding a value says so, on every page that has filters: its button names the filter and the value in the accent, and its × puts it back. A dropdown of ten options or more, a filter’s or a field’s, opens on a search: type part of a value to narrow the list, then pick it with the arrows and Enter. A grouped collection nests rows under their groups. A dot at a row’s end marks a blueprint the check has something to say about. N starts a new blueprint; every table the page ships sorts the same way, with its filters on the left. Every table has the same search box first among its filters (a collection’s, the Backlog’s table, board, drafts, and milestones, the blueprint drafts, the assets, the hot keys, Vocabulary, Versions): it keeps the rows holding every word you type, in any case and any order, in the id, the title, or a value the row shows, and its × empties it. On the Backlog’s board, table, and drafts, a collection’s table, and the assets, the filters (the search among them as q) are in the page’s address, so a filtered table can be bookmarked, shared, reloaded, and reached again with back and forward; changing one adds no step to the history. The other tables hold theirs while the page is open.

Saved views

Once the Backlog’s board, table, or drafts, or a collection’s table, is filtered, Save as view in the ⋮ beside its search keeps the page’s filters and its sort under a name: Private, yours alone in local.yaml and never committed, or Shared, in .eidos/plugins/eidosmd/views.yaml and committed with the root, so the whole team sees it. The view is listed at once in the Primary Sidebar in a group of its page’s views (Board views, Task views, and Draft views in the Backlog, a collection’s after the Collections), a private one with the struck eye, and opens that page as it was saved; its address is the page’s with view=<id> (/p/backlog?view=V-7K2M&assignee=plato), and the sort sits beside the filters as sort=<column>, - before the column for the other way. Change the filters or the sort of a view you opened and the ⋮ offers Update view for it or Save as new view; right-click a view, or its ⋯, to rename it, Make private or Make shared it (it keeps its id, so a page open on it stays on it), or delete it. The Backlog’s My work, By status, and By type are the views every root starts with. eidos views →

Click a row for the reader over the table: properties on the left, the body on the right with its contents rail, findings and comments underneath. Esc returns to the table; Expand opens the blueprint as its own page. A top-level doc, a draft, a task, and an asset open in the same shape. Right-click a row, here or in any table that lists things (the drafts, the Backlog’s tasks and milestones, the assets), for its actions: the ways in first, its id or path to copy, the ways out to the file, and the one that removes it last, asked once.

Reading, Editor, Source

A reader’s page opens on a bar that stays put as you scroll: the way back and the blueprint’s id (specs / B-5KFM; a task’s parents and its own id, Backlog / T-PARENT / T-TASK), with Save and Discard on its right while you edit (Delete, Find in file, and Move blueprint to…, which moves the file to another group of its collection with every link following, are in the ⋮); the title under it with the path below, the id and the path each copied from a link that shows on hover.

The reader has Obsidian’s three modes, picked in the ⋮ beside the title (the one in use ticked) and carried from page to page for the session (a Default view preference says which it starts in). Reading shows the rendered page. Editor is a markdown editor with the page rendered as you write: the block under the caret shows its syntax, every other block is drawn; a + handle on a block, or / at an empty one, opens a menu of blocks (headings, lists, a task list, a quote, code, a table, a rule, and what the plugins offer: an image or a file from Assets, a task from Backlog); ¶ turns a block into another kind; a pasted image lands in the asset folder and in the text. Source is the file as text.

In every mode the properties edit in place as typed fields the way Obsidian shows them: a dropdown where a property has options, chips for a list, a checkbox, a calendar for a date; a declared property the file lacks is one click away, listed by its name (never the id a file carries, which the bar shows), and one a tool owns is shown locked. Save writes the file in the house style, applies the Linter’s on-save rules, and runs the check on it. Leaving an editor with changes saves them first: another mode, a link, or a closed modal goes once the file has them. When the file will not take them, the error says why, and a link or a closed modal asks whether to keep editing or leave without them. The same menu opens the file in the external editor you named under Preferences or shows it in Finder.

A code block fenced with a language (```ts, ```yaml, ```bash, and the rest of Shiki’s grammars) is coloured in the theme’s colours in Reading, in the editor’s drawn blocks, and wherever else the page shows markdown; an untagged block stays plain. A block fenced as mermaid is drawn as its diagram in the page’s colours and font, and redrawn when the theme or the light and dark side changes. The file keeps the text: in the editor a click on the diagram opens it, Diagram in the block menu puts one in, and a block that does not parse shows its text with Mermaid’s error under it. Export to PDF…, in the ⋮ of a blueprint, a document, a draft, or a task, writes the one file open as a PDF, with or without its title and properties, at the page size, orientation, margin, and scale you pick; the desktop app asks where to save it, and a browser opens the print dialog on it.

Drafts

A blueprint can be started before it belongs to a collection: Save as draft on the New blueprint form keeps the file with the CLI, shared with the root or private, in no index or check until Publish moves it into its collection under new’s rules. Drafts have a group in the Root view and a page of their own. eidos draft →

Settings

The gear opens Settings as a sidebar view: Eidos (the overview, the standard, the agent guides), Framework (the framework document as forms: Root, Folders, Templates, Properties, Vocabulary, Roles, Me, each page a draft until Save to Framework), Eidosmd (Health Check with the check’s findings and their fixes, and a Settings tab for strictness and the section rules; Preferences, Users, Plugins, Versions), and one page per plugin that is on, with its switch, its settings, and its guide.

• Users: the people who work in the root (name, @alias, role, email, and an Agent switch for an AI agent that comments as itself), kept in settings.yaml; eidos users lists them and eidos users add adds one. Acting as picks who this machine signs comments as. Attribution, not authentication.
• Plugins: every plugin with its switch, its description, and its settings as a form; a setting marked private is yours alone. Plugins →
• Preferences: the look, laid out as Obsidian’s Appearance: the base color scheme (Adapt to system, Light, or Dark), an accent color, a theme (Default, one included with Eidos such as Catppuccin, AnuPpuccin, Nord, Gruvbox, Tokyo Night, or Things, or your own, made in the theme editor with the light side beside the dark, imported from a CSS file or an Obsidian vault, and exported as one CSS file), the interface, text, and monospace fonts, the size of the reading and editing text, and Ctrl and the scroll wheel to change it; then the language (English, Spanish, or Portuguese, or the one your browser asks for), the default view, the page width (Fixed or Fluid, also Change default page width to in the palette), the palette’s keys, the corner notifications appear in (top right by default), the external editor, whether release notes show after an update, and the order of the sidebar’s groups and activities.
• What’s new: every release with its headline and a one-sentence summary, and a page for each one, its entries grouped as New, Improved, Changed, and Fixed, from the Releases page. After an update the page opens the new release’s page once, listing any releases you skipped; What’s New in the palette lists them all, Show Release Notes opens the one you are on, and the Home ends on it.

Everything the browser remembers is YAML in .eidos/plugins/eidosmd/: settings.yaml and the shared views’ views.yaml travel with the root, local.yaml is yours and gitignored (as is a local/ folder beside it). Nothing is kept in the browser or a database.

The Registry

Registry, under Eidosmd in Settings and in the palette, is the Registry inside the page: every framework published there and the three bundled with Eidos, as a table of name and description, category, collections, and installs in the last 30 days, with a category filter and a search on the left. A row opens the framework over the table (Expand for its own page, /registry/@owner/name): its collections with each variant’s template as the file it is, its roles, top-level documents, properties, and README, each piece marked as this root has it: not at all, the same, or differently.

Include in this root is eidos install for the root you are in. What the root lacks is checked, a piece it holds differently is yours to pick, and a property comes with its collection or with Everything this root lacks (--all). The plan shows what is written and what is already here, and each conflict asks Keep current or Accept incoming before anything is written; the button names how many pieces it includes. What lands is exactly what eidos install <package> --collection … --on-conflict … --yes writes: the index rewritten, the check run, the provenance recorded, and the one install-count request sent. Each piece the root lacks also has an Include of its own, which opens the same plan with only that piece ticked, as eidos install <package> --variant … takes one. eidos install →

When the Registry cannot be reached, the bundled frameworks are listed alone and included from the copy inside the CLI, and nothing is sent, as with --offline. A README is shown with its HTML as text and its images as links, so the page still loads nothing from outside.

Canvas

An activity of its own, listing every canvas with its pages. A canvas is a whiteboard of pages where a node is a sketch (an idea that is not a blueprint yet), a blueprint (drawn live from its file), a sticky, or free text, with flows between them, frames around regions, and comment threads pinned to anything. A sketch is promoted into a blueprint through the same scaffold as eidos new and keeps its place. Nodes are styled by the framework’s own properties. A page exports as PNG, SVG, or JSON Canvas for Obsidian.

Navigating the canvas → is the manual: every tool, gesture, shortcut, and the file on disk.

How it is built

A Preact app shipped in the package as static files, served by Node’s own http module with a JSON API under /api/ (a plugin’s routes under /api/plugins/<name>/), bound to the loopback interface only. No external resources, so it works offline. Search uses SQLite full text on Node 22 (node:sqlite, nothing to compile) and an in-memory scan on Node 20.