Propriedades

A tabela de propriedades é todo o contrato de propriedades do Framework (a estrutura), sob properties no Framework.yaml. O frontmatter é gerado a partir dela, então um Blueprint (plano) novo nasce conforme.

Toda propriedade declara:

Campo	Significado
name	A chave do frontmatter
type	`Text`, `List`, `Number`, `Checkbox`, `Date` ou `Date & time`: o conjunto que o Obsidian renderiza nativamente
applies_to	`all`, ou uma lista de coleções
required	Ausente significa `false`
options	Só quando o valor é um de um conjunto fechado: os valores permitidos, em ordem
meaning	Para que serve, em uma frase

Qualquer coisa que queira mais estrutura do que um dos seis tipos pertence ao corpo.

Escopo, obrigatória, opções

applies_to é o que impede uma propriedade de cair onde não faz sentido. domain se aplica só a specs na semente software, então um frame (enquadramento) nunca recebe uma.

required põe a propriedade em todo Blueprint novo e faz de uma faltando ou em branco uma lacuna que a verificação anota. Uma propriedade opcional é escrita quando tem valor; a ausência dela nunca é uma lacuna. Prefira opcional por padrão, e exija só o que todo Blueprint precisa responder.

options fecha um valor Text (ou os elementos de uma List) a um conjunto declarado, comparado exatamente. Um valor fora da lista é trazido à tona com a lista ao lado, nunca recusado e nunca trocado em silêncio. A ordem é a ordem em que os valores valem, então um ciclo de vida se lê da primeira etapa à última e um dropdown a mantém. Nenhum padrão vai junto. Duas propriedades nunca carregam options: variant, cujo conjunto são as variants (variantes) da coleção, e uma propriedade de agrupamento, cujo conjunto são os seus grupos.

O núcleo

Tudo o que o padrão declara:

Nome	Tipo	Obrigatória	Significado
`id`	Text	sim	Identidade estável e única, em qualquer forma. Atribuída uma vez, nunca mudada
`title`	Text	sim	Nome legível. Renomeie à vontade; `id` fica parado
`summary`	Text	não	Uma linha: o que é este Blueprint. Alimenta o índice; ausente, o índice sinaliza
`variant`	Text	não	Qual variant este Blueprint segue. Ausente significa a padrão da coleção

O Eidos não define propriedades personalizadas

Status, datas, agrupamento, dependências: tudo escolha do Framework. A semente software traz estas, e cada uma é sua para manter, restringir ou descartar:

Nome	Tipo	Aplica-se a	Significado
`status`	Text	all	Etapa do ciclo de vida. Opções: Draft, Intake, In Progress, Done, Archived, Deprecated
`date_created`, `date_modified`	Date	all	`YYYY-MM-DD`
`tags`	List	all	Tags livres
`domain`	Text	specs	O grupo, batendo com a subpasta. A única propriedade que a semente exige
`depends_on`	List	specs	Blueprints de que este precisa, cada um um link markdown
`type`	Text	specs	Rótulo leve: feature, capability, integration. Rege visões, nunca estrutura

Adicione uma com eidos configure:property add. Moldando o seu Framework →

Três convenções

Rótulos leves são visões, não estrutura. Uma propriedade de categoria rege a filtragem, nunca quais seções um Blueprint tem. Se começar a reger, é uma variant.

Um valor de agrupamento bate com a sua pasta. Exatamente, na convenção de nomes. Um valor desconhecido avisa.

Sem campos de acompanhamento de trabalho. Nada de sprint, estimate ou assignee. Linke para o seu gerenciador de tarefas. Por quê →

Datas e histórico também não são assunto do padrão: o git guarda o histórico completo, e é por isso que o Eidos nunca reinventa uma trilha de auditoria no frontmatter. A versão do Eidos é um fato do Framework, em eidos_version, nunca em um Blueprint.

Vocabulary

Ao lado das propriedades, o Framework declara o seu vocabulary (vocabulário): uma entrada por palavra com que o produto é descrito de propósito, com o que ela means (significa), o que ela not é (os quase acertos e por quê), e see para o Blueprint que a define por completo. O Eidos não declara nenhuma; toda semente traz a lista vazia. Onde um termo está declarado, os Blueprints o usam; um quase acerto é sinalizado (term-near-miss), nunca trocado em silêncio.

Validação

A validação é definida pelo Framework. Uma verificação lê a tabela daquele Framework e a faz valer. Trazer à tona, nunca recusar. Uma propriedade obrigatória faltando é relatada; uma seção faltando é oferecida; o arquivo nunca é rejeitado. A saída é uma revisão sobre a qual uma pessoa age.

Na CLI: eidos new gera o frontmatter; eidos property set muda um valor, tipado; eidos check valida contra todo bloco. No navegador, uma propriedade com opções é um dropdown.