Linter

The Linter plugin keeps a root’s markdown in one form: rules the root agrees on, run on every markdown file the CLI writes, and reported by eidos check for the files that drifted anyway. The frontmatter block, every region a tool owns, and every fenced code block are left byte for byte; the rules change form, never meaning. On by default, writing the rules with their defaults the first time it runs; eidos plugin disable linter switches it off.

The rules

Each is a shared setting, so every machine and agent applies the same:

Rule	Default	What it does
trailing-whitespace	on	Spaces and tabs at a line’s end removed; hard-breaks (off) keeps a two-space hard break
final-newline	on	Exactly one newline ends the file
blank-lines	on	Consecutive blank lines collapse to one, and none open the file
heading-blank-lines, code-blank-lines	on	A blank line before and after every heading and every fenced block
single-h1	on	One # heading; a second is demoted to ##
heading-levels	on	No level skipped
heading-punctuation	on	A trailing ., ,, ;, or : removed from a heading
list-marker	-	One marker for every unordered list: -, *, +, or off
ordered-lists	ascending	1. 2. 3., or one for 1. 1. 1., or off
emphasis-style	_	_emphasis_, or *, or off; an intraword underscore is never touched
strong-style	**	**strong**, or __, or off
bare-urls	on	A bare http URL is wrapped in <>
tabs	on	A tab in prose becomes four spaces

The defaults are what the standard’s seeds write.

What runs when

With the plugin on, every markdown file the CLI writes passes through the rules that are on, and a blueprint’s frontmatter takes the on-save rules: a blueprint or a top-level doc saved from the page, eidos property set, a plugin’s write through the host (Comments’ projection). A write that bypasses the CLI (your editor, git) is not linted, which is what the check is for. A task file is the Backlog’s own write and is not linted in this build. Nothing is linted on read.

On save

The on-save rules are the Linter’s. Each names a Date or Date & time property and sets it to today or to the time whenever a blueprint is saved: from the page, with eidos property set, or by a plugin’s write through the host. A save from the Source view is tidied and keeps the values you wrote. A rule on a property no block of the Properties table declares is skipped, and the check reports it as linter/on-save-property. With the plugin off, nothing is stamped. A root whose rules are still in .eidos/plugins/eidosmd/settings.yaml, where they were kept before, keeps them working, and the first change on the Linter’s page moves them.

In the browser

The plugin’s page under Settings holds the on-save rules under On save, then lists the files that drifted under Drift, with Lint every file, above the form of the rules. Each linter/<rule> finding in Health Check and on a blueprint carries Lint as its fix.

On disk

• .eidos/plugins/linter/settings.yaml, shared: one key per rule, written with the defaults the first time the plugin is on and edited on its page, and on_save, the on-save rules as { property, set: today | now }.

From the shell

eidos linter                        # each file the rules would change, with the rules; or clean
eidos linter Blueprints/specs       # some paths; --json
eidos linter --fix                  # write the linted text and nothing else

--fix runs no on-save rule, so a whitespace fix never bumps a date.

What the check reports

linter/<rule> as a warning for each file and rule the rules would still change, once per file and rule.