Linter

O plugin Linter mantém o markdown de uma raiz em uma só forma: regras que a raiz combina, rodadas em cada arquivo markdown que a CLI escreve, e relatadas pelo eidos check para os arquivos que derivaram mesmo assim. O bloco de frontmatter, toda região que uma ferramenta possui e todo bloco de código cercado são deixados byte a byte; as regras mudam a forma, nunca o significado. Ligado por padrão, escreve as regras com os seus padrões na primeira vez que roda; eidos plugin disable linter o desliga.

As regras

Cada uma é uma configuração partilhada, então toda máquina e todo agente aplica o mesmo:

Regra	Padrão	O que faz
trailing-whitespace	ligada	Espaços e tabulações no fim de uma linha removidos; hard-breaks (desligada) mantém uma quebra dura de dois espaços
final-newline	ligada	Exatamente uma quebra de linha termina o arquivo
blank-lines	ligada	Linhas em branco consecutivas colapsam em uma, e nenhuma abre o arquivo
heading-blank-lines, code-blank-lines	ligadas	Uma linha em branco antes e depois de cada título e de cada bloco cercado
single-h1	ligada	Um título #; um segundo é rebaixado a ##
heading-levels	ligada	Nenhum nível pulado
heading-punctuation	ligada	Um ., ,, ; ou : final removido de um título
list-marker	-	Um marcador para toda lista não ordenada: -, *, + ou off
ordered-lists	ascending	1. 2. 3., ou one para 1. 1. 1., ou off
emphasis-style	_	_ênfase_, ou *, ou off; um underscore dentro de uma palavra nunca é tocado
strong-style	**	**negrito**, ou __, ou off
bare-urls	ligada	Uma URL http solta é envolvida em <>
tabs	ligada	Uma tabulação na prosa vira quatro espaços

Os padrões são o que as sementes do padrão escrevem.

O que roda e quando

Com o plugin ligado, todo arquivo markdown que a CLI escreve passa pelas regras ligadas, e o frontmatter de um Blueprint (plano) toma as regras ao salvar: um Blueprint (plano) ou um documento de nível superior salvo pela página, eidos property set, a escrita de um plugin através do anfitrião (a projeção do Comments). Uma escrita que contorna a CLI (o seu editor, o git) não passa pelo linter, que é para isso que a verificação serve. Um arquivo de tarefa é uma escrita própria do Backlog e não passa pelo linter nesta versão. Nada passa pelo linter na leitura.

Ao salvar

As regras ao salvar são do Linter. Cada uma nomeia uma propriedade do tipo Date ou Date & time e a põe na data de hoje ou na hora sempre que um Blueprint (plano) é salvo: pela página, com eidos property set ou pela escrita de um plugin através do anfitrião. Um salvamento pela visão Source é arrumado e mantém os valores que você escreveu. Uma regra sobre uma propriedade que nenhum bloco da tabela de Properties declara é pulada, e a verificação a relata como linter/on-save-property. Com o plugin desligado, nada é carimbado. Uma raiz cujas regras ainda estão em .eidos/plugins/eidosmd/settings.yaml, onde ficavam antes, continua a aplicá-las, e a primeira mudança na página do Linter as move.

No navegador

A página do plugin sob Settings traz as regras ao salvar sob On save, e depois lista os arquivos que derivaram sob Drift, com Lint every file, acima do formulário das regras. Cada achado linter/<rule> no Health Check e em um Blueprint carrega Lint como sua correção.

Em disco

• .eidos/plugins/linter/settings.yaml, partilhado: uma chave por regra, escrita com os padrões na primeira vez que o plugin está ligado e editada na sua página, e on_save, as regras ao salvar como { property, set: today | now }.

A partir do 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 não roda nenhuma regra ao salvar, então uma correção de espaço nunca muda uma data.

O que a verificação relata

linter/<rule> como aviso para cada arquivo e regra que as regras ainda mudariam, uma vez por arquivo e regra.