Convenções

O EIDOS.md fecha com dezenove convenções estruturais. Lá elas são uma lista plana e numerada; aqui estão agrupadas pelo que regem, com links para as páginas que as explicam.

O que é imposto, e como

O frontmatter é o acordo; o corpo é orientação. As propriedades são verificadas contra o Schema do Framework. As seções do corpo são estrutura recomendada, não requisitos.

A validação é definida pelo Framework. Uma verificação lê o Schema daquele Framework e o aplica. O contrato é o Schema, não uma regra gravada em uma ferramenta.

Portabilidade acima de prescrição. Uma propriedade central que falta é trazida à tona e acrescentada com uma nota sobre o porquê; uma seção que falta é anotada e oferecida. Nunca recuse o arquivo.

Onde a forma mora

A raiz é dona do seu Framework. Os shapes e as propriedades vivem no _eidos/ da raiz. Uma skill lê o Framework a partir da raiz, não de uma cópia própria. →

Todo Framework declara uma coleção de enquadramento. O nome dela, os flavors dela e quantos ela carrega são do próprio Framework. Obrigatória como declaração; nunca como barreira: um frame declarado e não escrito é uma lacuna a trazer à tona, não uma falha. →

Shapes e coleções

Uma família de shapes por coleção, declarada como flavors. O que flexiona é quais seções aparecem e qual flavor um Blueprint usa, nunca a ordem ou os nomes delas dentro de um flavor. O shape nunca é bifurcado por categoria.

Um shape nomeia a sua própria parte estável. Todo shape tem uma parte que fica parada e uma parte que se move, e diz qual é qual. Se a parte estável mudar substancialmente, pergunte se isto não é outro Blueprint. →

Os não-objetivos são os que mais pesam. Onde um shape declara uma seção para o que um Blueprint deliberadamente não vai fazer, essa seção é a mais forte que ele tem: é onde a gestão de escopo de fato acontece. Continua não sendo uma barreira dura. →

Um shape documenta as suas próprias convenções. Os nomes das seções, a ordem e o significado delas, e qualquer rotulagem que um shape peça vivem no arquivo do shape. O padrão rege coleções, shapes, flavors e propriedades; ele nunca rege uma seção.

O agrupamento de uma coleção é da própria coleção. Ela pode agrupar os seus Blueprints em um nível e pode declarar uma propriedade que nomeie esse agrupamento; o valor então coincide com a pasta, e um valor desconhecido avisa em vez de bloquear.

Propriedades

As propriedades carregam um tipo e um significado. Toda propriedade declara o nome dela, o tipo, a quais coleções se aplica e o que significa. O frontmatter é gerado a partir do Schema, então um Blueprint novo nasce em conformidade.

Rótulos leves são visões, não estrutura. Um rótulo de categoria que um Framework acrescenta dirige visões e filtragem, nunca estrutura. Um valor fora da lista é válido. flavor carrega a escolha estrutural.

A versão do Eidos é um fato do Framework. Ela vive no Framework.md, nunca como propriedade por Blueprint. O git guarda o histórico; um Framework que queira propriedades de data as declara como qualquer outra. →

Escrita

Escreva como uma pessoa leria. As seções são um andaime para um Blueprint vivo, não um formulário em que despejar texto. Se um Blueprint se lê como um modelo preenchido, remodele-o até que se leia como algo que alguém escreveu.

Referencie outros Blueprints com links, não com nomes soltos, tanto na prosa quanto nas propriedades. O id de cada Blueprint continua sendo a identidade permanente dele, atrás do link.

Prosa solta é revisada no lugar. Um documento de nível superior, e qualquer coleção que um Framework marque como prosa solta, registra o que é verdade agora e espera-se que mude. Isso é revisão, não status de trabalho.

Quem faz o quê

Leia o ator antes de agir. Leia _eidos/me.md e o contrato correspondente em _eidos/roles/, e responda como aquele papel define. O princípio de “pessoas primeiro” vale para todos os papéis; só o modo muda. Um arquivo em branco ou ausente recorre por padrão à facilitação completa. →

O que costumava estar aqui

Cinco convenções foram removidas na 4.4.2: reformuladas em outro lugar, não afrouxadas. Todas continuam valendo; elas apenas não são mais carregadas como regra numerada:

Removida	Agora mora em
O `id` é permanente	A tabela do Schema
Nomes visíveis seguem a convenção de nomes	Nomes
`Framework.md` é o índice; `README.md` é a porta	Framework e Blueprint
Cada coleção tem um índice gerado	Folhas geradas
Documentos de nível superior não têm shape	Shapes e flavors

A velha regra que exigia date_created e date_modified também caiu. Ela dizia aos Frameworks como duas propriedades deviam se comportar, enquanto a seção de Schema diz que o Eidos não define nenhuma propriedade personalizada. Um Framework que já as usa não muda nada: agora ele simplesmente é dono delas por completo.

Se você só lembrar de três

A pessoa escreve. Todo o resto decorre disso.

Os não-objetivos são os que mais pesam. É onde o escopo de fato se sustenta, e a primeira seção a esvaziar quando ninguém é dono da raiz.

Sem campos de acompanhamento de trabalho. É a linha entre um Blueprint que continua verdadeiro e um ticket que apodrece.