canvas

Gera o mapa de Blueprints: um arquivo .canvas de JSON Canvas 1.0, a contraparte espacial do índice, aberto na visão Canvas do Obsidian.

Ele desenha Blueprints e as arestas entre eles. O Framework é a única coisa que ele nunca desenha.

Como cada coleção é desenhada

Do jeito que o Framework dela declara, na linha - **Canvas:** da coleção:

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.

Por que ausente não significa 'adivinhe'

O gerador não conhece nenhuma coleção pelo nome. Ele não consegue inferir que ## Intent é a seção de resumo de uma spec, porque no seu Framework isso pode ser ## Premise ou ## Question, ou nada. Declarar a seção é como você conta a ele.

Estruturalmente: cada coleção é o seu próprio grupo, e uma coleção agrupada aninha um grupo por subpasta.

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. Ele responde a 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 →

O que você escolhe

Quais coleções incluir. Documentos de nível superior não são mapeados.

O .canvas gerado é ele mesmo um documento de nível superior: registre-o em ## Top-Level no Framework.md.

O nome de arquivo padrão dele segue a convenção de nomes: blueprint-map.canvas em kebab-case, BlueprintMap.canvas em TitleCase, Blueprint Map.canvas em Title Case. Ele só escolhe o nome quando você não passa --out, então um canvas existente mantém o nome dele até você regenerar sem um.

Como ele roda

Um build-canvas.py faz o trabalho onde há shell disponível; em um host isolado ele emite o JSON à mão. Regenerável, e nunca bloqueia.