Schema

O Schema (o esquema) é todo o contrato de propriedades do Framework: as propriedades centrais que o Eidos exige, mais o que o Framework acrescentar. Ele vive em um só lugar, ## Schema no _eidos/Framework.md, e o frontmatter é gerado a partir dele, então um Blueprint novo nasce em conformidade.

Cada propriedade declara quatro coisas:

Campo	Significado
Name	A chave do frontmatter.
Type	Um entre Text, List, Number, Checkbox, Date, Date & time.
Applies To	all, ou uma lista de coleções.
Meaning	Para que serve, em uma frase.

Por que esses seis tipos

São o conjunto que o Obsidian usa, então o frontmatter é renderizado nativamente em um vault. Qualquer coisa que queira mais estrutura do que um deles pertence ao corpo, não a uma propriedade.

O alcance de Applies To

Esta é a parte que faz trabalho de verdade. O frontmatter é gerado por Blueprint a partir das propriedades que se aplicam à coleção dele, então uma propriedade restrita nunca aterrissa onde não faz sentido.

domain é uma propriedade exclusiva de specs na semente software. Um frame nunca recebe uma, porque um frame não é agrupado por domínio, e isso é imposto pela geração, não por pedir que as pessoas se lembrem.

O núcleo

Presente em todo Blueprint, e a totalidade do que o padrão exige:

Nome	Tipo	Significado
id	Text	Identidade estável, única, em kebab-case. Atribuída uma vez, nunca renomeada. As referências apontam para ela.
title	Text	Nome legível por humanos.
summary	Text	Uma linha simples: o que este Blueprint é. A fonte da listagem do index.md da coleção; se faltar, o índice sinaliza.
flavor	Text	Qual flavor este Blueprint segue. Ausente = o padrão da coleção.
connects_to	List	Blueprints aos quais este se conecta no canvas, cada um um link, desenhado como aresta dirigida.

Cinco propriedades. Esse é o contrato obrigatório inteiro.

`id` é permanente

Estável, único, em kebab-case, atribuído uma vez e nunca renomeado. Renomeie title à vontade: é o rótulo humano. O id é a identidade da qual pendem os links, as referências e o histórico.

Não edite o bloco do núcleo à mão

### Eidos Core no Framework.md é o bloco do padrão. O migrate o reescreve numa mudança de versão. As suas propriedades vão sob ### Custom Properties.

O Eidos não define nenhuma propriedade personalizada

Um status de ciclo de vida, datas, um agrupamento, uma lista de dependências: tudo isso é escolha de um Framework, não do padrão. Cada semente faz o seu próprio conjunto.

A semente software traz estas, e cada uma delas é sua para manter, restringir ou descartar:

Nome	Tipo	Applies To	Significado
status	Text	all	Draft / Intake / In Progress / Done / Archived / Deprecated. Um valor fora da lista avisa.
date_created	Date	all	YYYY-MM-DD. O dia em que o Blueprint foi escrito pela primeira vez. Definido uma vez.
date_modified	Date	all	YYYY-MM-DD. O dia em que foi alterado pela última vez.
tags	List	all	Tags livres.
domain	Text	specs	O agrupamento, coincidindo com a subpasta do Blueprint. Um valor desconhecido avisa.
depends_on	List	specs	Blueprints de que este precisa, cada um um link markdown. Uma dependência de implementação, não uma aresta do canvas.
type	Text	specs	Rótulo de categoria aberto e leve: feature, capability, integration. Dirige visões, nunca estrutura.

Acrescente uma com o configure, que pressiona pelas quatro coisas (Name, Type, Applies To e Meaning) e depois a preenche retroativamente nos Blueprints a que ela se aplica.

Três convenções de propriedades que vale internalizar

Rótulos leves são visões, não estrutura

type é o exemplo: um rótulo de categoria dirige visões e filtragem, nunca estrutura. Um valor fora da lista é válido.

Se um rótulo começa a mudar quais seções um Blueprint tem, ele já não é um rótulo: é um flavor, e flavor é a propriedade que carrega a escolha estrutural.

O valor de um agrupamento coincide com a pasta dele

Se uma coleção declara uma propriedade que nomeia o seu agrupamento, o valor coincide exatamente com a subpasta, segundo a convenção de nomes do Framework. Um valor desconhecido avisa em vez de bloquear: os agrupamentos se acumulam com o tempo, e o validador é o lugar errado para litigá-los.

Sem campos de acompanhamento de trabalho

Aquela em que vale a pena se recusar. Nada de sprint, estimate ou assignee. Conecte com o seu rastreador por meio de um link. Por quê →

connects_to versus depends_on

Duas propriedades de lista de links que se parecem e significam coisas diferentes. Vale acertar, porque só uma delas desenha.

connects_to é central. É o mapa intencional: o que você afirma que se relaciona com o quê, para uma pessoa que lê a raiz espacialmente. O canvas desenha cada entrada como uma aresta dirigida.

depends_on é uma propriedade da própria semente software. É uma dependência de implementação: o que isto precisa para poder ser construído. Não é uma aresta do canvas, embora o canvas possa sobrepô-la em uma cor distinta se você pedir.

A distinção é intenção versus mecanismo. Dois Blueprints podem depender tecnicamente um do outro sem ter nada a dizer um ao outro conceitualmente, e o contrário acontece com a mesma frequência.

Datas e histórico

A versão do Eidos é um fato do Framework, no Framework.md. Ela nunca é uma propriedade por Blueprint.

Datas também não são assunto do padrão. Até a 4.4.1 ele determinava como date_created e date_modified se comportam; a 4.4.2 abandonou isso, porque ficava mal ao lado de uma seção de Schema declarando que o Eidos não define nenhuma propriedade personalizada. Um Framework que queira propriedades de data as declara como qualquer outra, e é dono do que elas significam.

Por que o padrão pode se dar ao luxo de ficar de fora

O git guarda o histórico completo: é disso que se trata viver em um repositório, e é a razão de o Eidos nunca reinventar uma trilha de auditoria no frontmatter. A semente software continua trazendo as duas propriedades de data; elas apenas são escolha dela agora, não uma regra.

Validação

A validação é definida pelo Framework. Uma verificação lê o Schema daquele Framework e o aplica: as propriedades centrais mais as personalizadas restritas à coleção do Blueprint. O contrato é o Schema, não uma regra gravada em uma ferramenta.

E a postura é 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 se recusa o arquivo.

A saída da validação é uma revisão sobre a qual uma pessoa age, não uma barreira que a impede.

A seguir

• Frames
• Dando forma ao seu Framework: acrescentar uma propriedade e preenchê-la retroativamente.