Framework e Blueprint

O Eidos gira sobre duas palavras. Entenda estas e o resto do padrão se encaixa sozinho.

	Framework (a estrutura)	Blueprint (o plano)
O que é	A forma	Uma unidade, definida por completo
É	Coleções, shapes, flavors, papéis, convenção de nomes, Schema	Um arquivo markdown: frontmatter mais corpo
Vive em	_eidos/, oculto na raiz	Uma pasta de coleção
Portátil?	Sim: esta é a peça que um time entrega a outro	Não: é o seu produto
Relação	Um Framework	Rege quantos Blueprints você quiser, em quantas raízes você quiser

O nome

Eidos (εἶδος) vem de ἰδεῖν, ver: literalmente a aparência de uma coisa, sua figura visível. Platão o tomou para a Forma: o padrão ao qual uma coisa se ajusta, que o olho nunca capta e a mente sim. Aristóteles o opôs a ὕλη, matéria: a forma é o que torna um pedaço de algo aquela coisa em particular.

Os dois sentidos são estruturais aqui. O Framework é a forma; um Blueprint é o que toma essa forma.

Uma terceira palavra, com menos trabalho

raiz: a única pasta em que o Eidos vive, contendo o Framework, as coleções e quaisquer documentos de nível superior. Ela é encontrada pelo _eidos/ oculto que há dentro dela, nunca pelo nome.

Ela não faz parte do par acima porque nomeia um lugar, não uma ideia. Até a 4.4.0 a árvore inteira se chamava definição; isso colidia com o que um Blueprint faz, então a 4.4.1 abandonou o termo e a 4.4.2 se decidiu por root.

A raiz

Uma pasta, que pode ter qualquer nome (Blueprints/ é apenas o padrão que o install oferece), porque nada aponta para ela por caminho. Ela é encontrada pelo _eidos/ oculto que há dentro.

• DirectoryBlueprints/ a raiz

  • README.md o “comece aqui” visível
  • Directory_eidos/ o Framework

    • …
  • Directoryframes/ a coleção de enquadramento — declarada primeiro

    • index.md folha gerada
    • architecture.md um por tipo de frame, em nível único
  • Directoryspecs/ uma coleção de Blueprints

    • index.md folha gerada
    • Directoryplayback/ um nível de subpastas, no máximo

      • resume-playback.md um Blueprint por arquivo
  • roadmap.md um documento de nível superior — opcional, seu

Várias raízes podem conviver em um mesmo repositório. Elas se aninham como Blueprints/<nome>/…, cada uma com o seu próprio _eidos/.

O Framework

O Framework fica oculto do mesmo jeito que .git e .obsidian ficam: presente, gerenciável e fora do caminho depois de definido. Essa localização é deliberada: a raiz é plausivelmente um vault do Obsidian, e _eidos/ fica ao lado de .obsidian/ sem competir com o conteúdo pela atenção.

• Directory_eidos/

  • Directoryshapes/ um arquivo por flavor

    • spec.full.md o flavor padrão de uma coleção
    • spec.micro.md um segundo flavor do mesmo tipo
    • frame.architecture.md os flavors da coleção de enquadramento
  • Directoryroles/ contratos de resposta, versionados e ajustáveis pelo time

    • framework-owner.md o que toda semente carrega
    • developer.md o resto é do próprio Framework
  • Framework.md índice + configuração: versão, nomes, coleções, Schema
  • me.md o ator (pessoal, no gitignore)
  • .gitignore ignora me.md — o único arquivo daqui que não é versionado

Uma pasta sem _eidos/ não é uma raiz.

Framework.md

O único arquivo que descreve a forma em vez de um Blueprint específico. Frontmatter para os fatos que o tooling analisa; um corpo que indexa a raiz.

_eidos/Framework.md — frontmatter

---
eidos_version: 4.4.2      # the standard version this framework targets
naming: kebab-case        # kebab-case | TitleCase | Title Case; absent = kebab-case
---

O corpo carrega quatro coisas:

## Top-Level: os documentos únicos da raiz, com README primeiro. Os documentos de enquadramento não estão aqui; eles são uma coleção.

## Collections: um título ### para cada uma, declarando sua folha gerada, seus flavors (com um marcado como padrão), como o canvas deve desenhá-la e o seu agrupamento.

_eidos/Framework.md — a collection

### specs

The product's units, one per blueprint, grouped by domain.

- **Leaf:** [specs/index.md](../specs/index.md)
- **Flavors:**
  - [full](shapes/spec.full.md) — the complete spec shape (default).
  - [micro](shapes/spec.micro.md) — Intent, Open Questions, ACs, Out of Scope.
- **Canvas:** card from `## Intent`
- **Domains:** _(one bullet per domain as they accrue)_

## Schema: o contrato de propriedades, dividido em ### Eidos Core (as do padrão, reescritas pelo migrate; não as edite à mão) e ### Custom Properties (as suas). Mais →

Dicas para o canvas

- **Canvas:** diz ao canvas como desenhar uma coleção: file para um nó de arquivo inteiro (a prosa é lida por completo), card para um nó que embute o Blueprint, ou card from ## Section para embutir uma seção. Se estiver ausente, desenha-se um cartão simples: o gerador não conhece nenhuma coleção pelo nome e não pode adivinhar qual seção é o resumo.

Por que a separação importa

Porque o Framework é a peça que viaja.

Os seus Blueprints são o seu produto, e não servem para mais ninguém. Um Framework é forma sem conteúdo (coleções, shapes, um esquema, papéis) e é exatamente o artefato que um time entrega a outro para que ambos escrevam do mesmo jeito. Essa é toda a razão de as sementes existirem: são Frameworks que o Eidos distribui, e o install copia um deles para uma raiz nova.

Isso também explica a convenção que mais surpreende:

A pasta é dona do seu Framework

Os shapes e as propriedades vivem no _eidos/ da raiz. Uma skill lê o Framework a partir da raiz, nunca de uma cópia própria. Não existe configuração global, e nenhuma ferramenta traz gravada uma ideia de como as suas coleções se chamam.

A validação decorre disso. 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 assada dentro de uma ferramenta.

A seguir

• Coleções e Blueprints
• Dando forma ao seu Framework