Convenções
O EIDOS.md fecha com vinte e duas regras. Aqui estão agrupadas pelo que regem, cada uma com um ponteiro para a página que a explica. Cite o que uma regra diz, não o seu número; a numeração muda entre versões.
O que é imposto, e como
Seção intitulada “O que é imposto, e como”- O frontmatter é o acordo; o corpo é orientação. Propriedades são verificadas. Seções são recomendadas.
- A validação é definida pelo Framework. Uma verificação impõe a tabela de propriedades daquele Framework (a estrutura), nada fixo no código.
- Trazer à tona, nunca recusar. Uma propriedade faltando é adicionada com uma nota; uma seção faltando é oferecida. Nunca recuse o arquivo. Um validador que recusa arquivos é contornado. →
Onde a forma vive
Seção intitulada “Onde a forma vive”- A raiz possui o seu Framework. Uma ferramenta lê o Framework da raiz em que está, nunca de uma cópia própria. →
- Tudo na raiz é declarado. Toda pasta e todo arquivo tem uma entrada, e nada é declarado que não esteja lá. →
- Uma pasta é do seu dono. As regras do padrão alcançam
@eidos/collectionse nada além; a pasta de uma ferramenta é daquela ferramenta, e uma sem dono é da pessoa. → - Uma região é de uma ferramenta, pelo nome. Dentro é da ferramenta; fora é da pessoa. →
- A versão do Eidos é um fato do Framework, em
eidos_version, nunca em um Blueprint (plano). →
Templates e coleções
Seção intitulada “Templates e coleções”- Uma família de templates por coleção, como variants. O que muda é quais seções aparecem; nunca a ordem ou os nomes. →
- Um template nomeia a própria parte estável. Se ela muda substancialmente, pergunte se este é um Blueprint diferente. →
- Os non-goals carregam o maior peso. Onde um template tem uma seção para o que um Blueprint não fará, essa seção é a mais forte. →
- Um template documenta as próprias convenções. O padrão rege pastas, templates (modelos), variants (variantes) e propriedades; nunca uma seção.
- O agrupamento de uma coleção é dela. Toda subpasta é um grupo declarado; um grupo contém Blueprints e nada mais fundo. →
Propriedades
Seção intitulada “Propriedades”- Toda propriedade tem um tipo, um significado e um dono. O frontmatter é gerado a partir das obrigatórias, então um Blueprint novo nasce conforme. →
- Rótulos leves são visões, não estrutura. Uma propriedade de categoria rege a filtragem, nunca a estrutura.
variantcarrega a escolha estrutural. - Sem campos de acompanhamento de trabalho. Nada de sprint, estimate ou assignee; faça a ponte para um gerenciador de tarefas com um link. Intenção, nunca progresso. →
Escrita
Seção intitulada “Escrita”- Escreva como uma pessoa leria. Se se lê como texto de enchimento preenchido, remodele.
- Referencie Blueprints com links, não com nomes soltos, tanto na prosa quanto nas propriedades. →
- Prosa solta é revisada no lugar. Isso é revisão, não status de trabalho.
- Um termo declarado é a palavra. Um quase acerto é sinalizado, nunca trocado em silêncio. →