Folhas geradas
O Eidos tem exatamente duas visões derivadas. Elas compartilham três propriedades, e as propriedades importam mais do que as saídas:
- Regeneradas por inteiro. Nunca mescladas, nunca remendadas.
- Nada escrito à mão para preservar. Qualquer coisa que você digite em uma delas se perde.
- Elas anotam, nunca bloqueiam. Uma folha desatualizada é um incômodo, não uma falha.
O índice
Seção intitulada “O índice”Cada coleção carrega um index.md gerado na sua pasta, listando seus Blueprints
para que uma pessoa ou um agente possam navegar sem varrer a árvore.
# specs
<!-- index: specs (regenerated) -->
## playback- [Watch a Video](playback/watch-a-video.md) — play a video reliably, signed in or not, adapting to the connection.- [Resume Playback](playback/resume-playback.md) — returns a viewer to the exact second they stopped.
## channels- [Subscribe to a Channel](channels/subscribe-to-a-channel.md) — follow a channel and get its new uploads.Agrupado por subpastas quando a coleção as tem, em nível único quando não. Os
links são relativos à pasta da coleção. Reconstruído pela skill index.
O que faz o summary merecer mais atenção do que o tamanho dele sugere. É a
única coisa que a maioria dos leitores vai ver da maioria dos Blueprints: uma
linha simples dizendo o que isto é. Escreva-a como uma destilação da seção de
abertura, não como o título repetido.
Quando reconstruir
Seção intitulada “Quando reconstruir”Depois que Blueprints são acrescentados, renomeados, movidos ou removidos. A
skill index percorre as coleções declaradas pelo Framework, lê cada subpasta de
um nível e reescreve cada index.md por inteiro.
Ela traz um build-index.py que faz a varredura de forma determinística onde há
shell disponível, e recorre a fazer isso à mão em um host isolado.
O mapa de Blueprints
Seção intitulada “O mapa de Blueprints”A contraparte espacial: um arquivo .canvas do Obsidian (JSON Canvas
1.0), gerado pela skill canvas.
Cada coleção é desenhada do jeito que o seu Framework declara, em
- **Canvas:**:
| Declaração | Desenha como |
|---|---|
file |
Um nó de arquivo inteiro, para prosa feita para ser lida por completo, como um frame. |
card |
Um nó que embute o Blueprint. |
card from ## Section |
Um nó que embute só aquela seção. |
| (ausente) | Um cartão simples. |
Estruturalmente: cada coleção é o seu próprio grupo, e uma coleção agrupada aninha um grupo por subpasta. Diretórios viram nós de grupo aninhados.
Arestas
Seção intitulada “Arestas”Os links connects_to de cada Blueprint viram arestas dirigidas: este →
destino. Esse é o mapa intencional: o que você afirma que se relaciona com o
quê.
depends_on vem desligado por padrão e pode ser sobreposto em uma cor
distinta. É outra pergunta (dependência de implementação em vez de conexão
conceitual) e misturar as duas produz um diagrama que não significa nada.
A distinção →
Você escolhe quais coleções incluir. Documentos de nível superior não são mapeados.
É o mapa de Blueprints
Seção intitulada “É o mapa de Blueprints”Ele desenha Blueprints e as arestas entre eles. O Framework é a única coisa que ele nunca desenha, que é para o que o nome serve.
O .canvas gerado é ele mesmo um documento de nível superior, então registre-o
em ## Top-Level no Framework.md. O nome de arquivo padrão segue a convenção
de nomes: blueprint-map.canvas em kebab-case.
Nenhuma das duas bloqueia
Seção intitulada “Nenhuma das duas bloqueia”As duas folhas anotam. Um índice desatualizado ou um canvas ausente nunca é um erro que impeça algo, em linha com a portabilidade acima de prescrição do padrão.
Elas também são as duas baratas de regenerar e seguras de apagar, que é o teste de se algo pertence sequer a esta categoria. Se não pode ser reconstruído a partir dos Blueprints, não é uma folha: é conteúdo, e pertence a um arquivo que alguém possui.