Diagramas (Mermaid)

Como funciona

Diagramas Mermaid. Uma cerca ```mermaid com um fluxograma (flowchart/graph, nas quatro direções), um diagrama de sequência (sequenceDiagram) ou um gráfico de pizza (pie) é desenhada como diagrama no modo de leitura, no arquivo exportado e nas respostas do Perguntar às notas — que é de onde os diagramas mais vêm. O desenho segue o tema da nota (tinta, papel e acento), então ele combina com o texto em volta nos dois temas. Na edição formatada — o modo padrão — o diagrama também aparece desenhado, com a barra do bloco por cima (copiar, editar, apagar). O editar abre uma barra embaixo com a fonte: a nota fica travada enquanto ela está aberta e o desenho se refaz enquanto você digita; fechar aplica (não há salvar nem cancelar), Ctrl+Z desfaz a alteração inteira num passo e esvaziar o campo remove o bloco. No modo dividido, clicar no diagrama leva o cursor até a cerca no texto cru. No editor de texto tudo continua sendo texto: use Ctrl+E para ver o diagrama. Dentro de um item de lista, o diagrama — e também a estrutura SMILES, a fórmula em bloco, o [files] e o ![[nota]] — fica como texto na edição formatada e aparece desenhado no modo de leitura: ali o marcador do item não teria como voltar ao arquivo.

Subgrafos (subgraph … end, inclusive aninhados) viram caixas com título, e as arestas atravessam a borda a partir do nó de verdade; o id de um subgrafo também pode ser ponta de aresta (sub --> X). As cores declaradas pelo autor valem: classDef, class, :::classe e style (preenchimento, borda, espessura, tracejado e cor do texto). Para começar, use Inserir → Diagrama (Mermaid) na barra da nota: ele entra com um esqueleto pronto do tipo escolhido. O menu traz os seis mais usados direto; Todos os diagramas… abre um seletor com os 33, agrupados pelo que servem, com busca (pelo nome ou pelo que o diagrama mostra) e a prévia desenhada de cada um — são 33 desenhos, e ver o desenho decide mais rápido que ler o nome. O frontmatter do diagrama — o bloco entre --- antes da primeira linha — também é lido: o title vira o título desenhado acima do desenho (um title no corpo vence) e as chaves de config que o LightNote conhece chegam ao diagrama (gitGraph.mainBranchName, gantt.displayMode, e as do packet: bitsPerRow, bitOrder: descending — que espelha a fileira — e showBits: false); o que ele não conhece é ignorado, sem recusar a nota.

Sequência, entidades, classes e estados

No diagrama de sequência valem participant/actor (com as), as formas de seta (->>, -->>, -x, -)), a ativação (+/- e activate/deactivate), as notas (Note left of/right of/over), os blocos loop/alt/else/opt/par e o autonumber. O que ainda não é desenhado — outros tipos de diagrama — continua aparecendo como bloco de código, colorido como hoje; direction dentro de um subgrafo e linkStyle são ignorados. A sintaxe de nó do Mermaid v11 (A@{ shape: rounded, label: "texto" }) é lida, e o catálogo de formas do v11 é desenhado: doc, lin-doc, docs, tag-rect, win-pane, hourglass, bolt, flag, das… — cada uma é o símbolo que o nome diz, e nenhuma vira retângulo, porque um retângulo no lugar de um documento seria outro diagrama. Um nome que o Mermaid não tem faz o diagrama voltar a ser bloco de código, com a linha apontada. O id de aresta (A e1@--> B) e o e1@{ animate: true } são aceitos e ignorados: a animação não é desenhada. O participante tipado (participant DB@{ "type": "database" }) desenha o símbolo da UML acima da raia — boundary, control, entity, database, queue e collections —, e o "alias" declarado ali vale como o as.

O erDiagram também é desenhado: cada entidade vira uma caixa com os atributos e a cardinalidade aparece nas duas pontas da relação (||--o{, }o--||, |o, |{); -- é relação identificante e .. não-identificante. O apelido p[Pessoa] nomeia a caixa sem trocar o id que as relações citam. O subgraph … end também vale aqui: as entidades de dentro ganham uma caixa com título, os subgrafos aninham e o id da caixa pode ser ponta de relação (CLIENTE ||--o{ Vendas : faz), ligando à fronteira em vez de a uma entidade com aquele nome.

O classDiagram idem: caixa de três compartimentos (nome, atributos e métodos, separados pelo parêntese do método), <<interface>> em linha própria, namespace como caixa e as seis relações (<|--, *--, o--, -->, ..>, ..|>). Atenção à direção: em A <|-- B o triângulo fica em A — quem herda é B. A cardinalidade entre aspas aparece nas duas pontas ("1" --> "*"). Os genéricos Lista~T~ aparecem como Lista<T>, nos membros também. A interface pirulito (bar ()-- foo) desenha o círculo no alto da caixa do lado em que o () está — e só nele —, com a relação encostando no círculo; os namespace também aninham, e depois do } interno uma classe volta ao namespace de fora.

O stateDiagram-v2 desenha a máquina de estados: [*] é o início (disco cheio) e o fim (disco com anel), state X { … } vira caixa, <<fork>>/<<join>> viram barra e <<choice>> um losango. O -- dentro de um estado composto separa as regiões concorrentes, marcadas por um traço tracejado.

Linha do tempo, jornada, quadrantes e Gantt

A timeline também é desenhada: cada período vira uma coluna da linha do tempo, com os eventos empilhados abaixo dele, e section agrupa as eras em faixas coloridas. Valem as duas grafias de vários eventos — dois-pontos na mesma linha (2004 : Facebook : Google) e continuação na linha seguinte (: outro evento) —, e aqui qualquer linha que não seja title, section ou direction é texto livre. O direction TD (linha do tempo na vertical) ainda não é desenhado e mantém o bloco de código.

O journey (jornada do usuário) também é desenhado: cada tarefa vira uma caixa no eixo da jornada, e a nota de 1 a 5 desloca o rosto para cima ou para baixo — é o perfil formado por eles que o diagrama existe para mostrar. O section agrupa as fases e os atores viram marcadores coloridos na tarefa, com a legenda à esquerda. Aqui a gramática é estrita (Tarefa: nota: Ator, Ator), ao contrário da do timeline: sem o par nome/nota não há onde pôr o rosto, então a linha malformada — ou a nota fora de 1 a 5 — recusa o diagrama, apontando a linha.

E o quadrantChart desenha o plano dos quatro quadrantes: x-axis e y-axis nomeiam as pontas de cada eixo (o lado direito do --> é opcional), quadrant-1 a quadrant-4 rotulam as regiões e cada ponto entra como Nome: [x, y], com x e y de 0 a 1. Atenção à numeração: ela é a do plano cartesiano, e não a da leitura — quadrant-1 é o de cima à direita, e dali se anda no sentido anti-horário; o y = 1 fica no topo. Cor e raio de um ponto podem vir direto (P: [0.5, 0.5] radius: 10, color: #109060) ou por classe (P:::classe mais classDef), e o estilo direto vence a classe. Coordenada fora de 0 a 1 recusa o diagrama apontando a linha, em vez de ser aparada — ela é a posição no plano, e aparar poria o ponto num quadrante que você não escreveu.

O gantt desenha o cronograma: dateFormat diz o formato das datas que você escreve (padrão YYYY-MM-DD) e axisFormat o dos rótulos do eixo (%d/%m); section agrupa as tarefas em faixas. Cada tarefa é Texto : marcadores, id, início, fim — os marcadores done, active, crit e milestone vêm primeiro e podem se combinar, o início é uma data ou after outroId, e o fim é uma data, uma duração (5d, 2w, 3h, 45m) ou until outroId. Com um campo só, a tarefa começa onde a anterior terminou.

O after pode citar uma tarefa declarada mais adiante na nota; já um id que não existe em lugar nenhum — ou uma dependência circular — recusa o diagrama apontando a linha, em vez de jogar a barra no dia de hoje. O excludes weekends (ou excludes monday, ou uma data) empurra o fim de cada tarefa pelos dias excluídos, e por isso muda o comprimento das barras; includes 2026-03-07 vence o fim de semana, para dizer que naquele sábado se trabalha. O marco (milestone) aparece como losango, e todayMarker off tira a linha do dia de hoje. O displayMode compact empilha várias tarefas na mesma linha, e aqui uma tarefa só divide a linha quando nada do que ela ocupa encosta no que já está lá — o rótulo inclusive. O marcador vert (Abertura : vert, v1, 20:15, 0m) desenha o instante como uma linha vertical que atravessa o gráfico, sem ocupar linha nenhuma, e o rótulo dele sai sob o eixo. O dateFormat X (ou x) lê a data como tempo Unix em segundos (ou milissegundos), e no eixo o %s/%Q a escreve de volta. Um tickInterval que o Mermaid não conhece (1decade) é ignorado em silêncio, como lá, e o eixo volta ao automático.

Mapa mental, requisitos, Git e C4

No mindmap a hierarquia vem da indentação: o nível de um item é a coluna em que o texto dele começa, sem chaves nem setas (o tabulador vale até a próxima parada de 4, como num editor). O primeiro item é a raiz — um segundo item na coluna dela seria uma segunda raiz, e aí o diagrama é recusado com a linha apontada. Cada item pode declarar a forma: [quadrado], (arredondado), ((círculo)), {{hexágono}}, ))explosão(( e )nuvem(; sem delimitador sai arredondado. O ::icon(...) e o :::classe são reconhecidos e ignorados (não empacotamos a fonte de ícones, e a classe se refere a um CSS externo que não existe aqui). O desenho é de dois lados — a raiz no centro, os ramos repartidos à esquerda e à direita —, cada ramo com uma cor própria que os descendentes herdam, e a espessura do galho cai com a profundidade.

Ele é uma árvore, e não uma simulação de forças como no mermaid: num mapa mental a hierarquia é o conteúdo, então ela precisa se ler na posição — e, como o desenho é refeito ao trocar o tema, um layout que convergisse de posições aleatórias reorganizaria o mapa inteiro a cada troca.

O treeView (treeView-beta) desenha a árvore de pastas de um projeto, e aceita as duas grafias: o recuo (o que se digita) e os próprios caracteres do comando tree (├──, │, └──), que é o que deixa colar a saída do terminal direto na nota — ali o recuo não serve, porque │ e espaço ocupam a mesma coluna e só o primeiro diz que o ramo continua. A barra final marca a pasta (src/), um nome com espaço vai entre aspas, o ## texto pendura um comentário no fim da linha e o :::highlight destaca o nome. O icon(...) é reconhecido e ignorado, como o ::icon() do mapa mental: os pacotes de ícones vêm do Iconify por JavaScript, e nem o próprio Mermaid os desenha por padrão.

O ishikawa (ishikawa-beta) desenha a espinha de peixe de uma análise de causa: o primeiro item é o EFEITO (a cabeça, à direita), o nivel seguinte são as categorias (os ossos) e os dois de dentro são as causas e as sub-causas. São três degraus, e um quarto nível recusa o diagrama apontando a linha — ele não existe no Mermaid. Os ossos alternam acima e abaixo da espinha, que é o que deixa duas categorias vizinhas caberem sem o texto de uma cair sobre o da outra, e a ordem em que você escreve as causas é a de cima para baixo nos dois lados.

O venn (venn-beta) desenha conjuntos que se cruzam: set A["Desejável"] declara um, union A,B["Dá para construir"] nomeia a região comum (a união se chama pelos conjuntos que ela cruza) e text A1["React"], logo abaixo de um deles, põe um item dentro daquela região. São até três conjuntos, e o quarto recusa o diagrama apontando a linha: com quatro círculos não existe arranjo que produza todas as regiões, e desenhar "quase certo" esconderia uma que você declarou. O :número depois do rótulo (set A["Alpha"]:20) escala o círculo — a área vai com o número —, e não as interseções: um Venn com interseção proporcional é outro diagrama (Euler), que exige otimização numérica. O style A fill:#ff6b6b pinta um conjunto, e com vírgula (style A,B color:#333) vale para a união daqueles conjuntos.

O cynefin (cynefin-beta) desenha o quadro de Snowden para classificar decisões: os cinco domínios têm nome fixo — complex, complicated, chaotic, clear e confusion — e posição fixa (os quatro quadrantes, com a confusão no meio); o que você escolhe é o que vai dentro de cada um. Cada item vai entre aspas, numa linha, e complex --> complicated : "Padrão identificado" desenha a transição entre dois domínios. Um nome fora dos cinco recusa o diagrama apontando a linha e dizendo quais existem. A fronteira entre clear e chaotic sai ondulada: no modelo ela é um precipício, e a forma diz isso — aqui a onda é sempre a mesma, para a nota não mudar de desenho a cada abertura.

O swimlane (swimlane-beta) desenha um processo em faixas, uma por responsável: a sintaxe é a do fluxograma (as mesmas formas, setas, rótulos e classDef), e cada subgraph deixa de ser uma caixa para virar uma raia. Todo nó precisa estar dentro de uma — um nó solto recusa o diagrama, porque não haveria como dizer de quem é a tarefa — e raia dentro de raia também recusa. Com LR as raias são linhas e o fluxo anda para a direita; com TB elas são colunas e o fluxo desce. A posição ao longo do fluxo sai do caminho mais longo até cada tarefa, e a faixa é a do dono: uma tarefa nunca sai da raia dela, mesmo quando isso deixaria o desenho mais compacto.

O agentflow (agentflow-beta) desenha um fluxo com agentes de IA, e é outro vocabulário para o fluxograma: as setas são as mesmas, o flow id["Nome"] … end faz o papel do subgraph (e aninha), o global … end guarda o que todos os agentes consultam e o connector id["Nome"] declara um sistema de fora. O que muda de verdade é a forma, que diz o papel de cada passo: @{ shape: input } (entrada), task (tarefa), tool (chamada de ferramenta), decision (decisão), refdoc (documento de referência) e action (ação final). Ligue o documento com -.-, sem seta: ele é consultado, não é um passo do fluxo. As chaves que descrevem o agente por escrito (instruction, params, returns, connectorRef, protocol, endpoint) são lidas e ignoradas no desenho. Estes nomes de forma só valem aqui — num flowchart eles recusam, porque lá o Mermaid também não os tem.

O usecase (usecase-beta) desenha o diagrama de casos de uso da UML: quem se declara com actor vira o boneco, e todo o resto é um caso de uso, desenhado como elipse — é essa a distinção que o tipo existe para mostrar. O caso de uso pode vir como Id("Rótulo"), Id[Rótulo], só Id ou só o texto entre aspas; o systemBoundary "Nome" … end é a fronteira do sistema e o note for X "texto" pendura uma nota. As relações são as da UML: --> associa, --|> é generalização (o triângulo vazado fica em quem é geral) e o A ..> : include B — com o alvo depois do dois-pontos — desenha o « include » pontilhado, valendo também para extend. O que descreve o ator sem mudar o desenho (type, business, icon) é lido e ignorado, e o <<Estereótipo>> entra no rótulo. O nó json ainda não é desenhado e mantém o bloco de código: ele é um bloco de várias linhas com a árvore do dado dentro, e ali o JSON continua legível como texto.

O wardley (wardley-beta) desenha um mapa de Wardley: um plano em que o eixo vertical é a visibilidade para o usuário (o topo é quem ele vê) e o horizontal é a evolução, de Genesis a Commodity.

Atenção à ordem do par: component Chá [0.63, 0.81] é [visibilidade, evolução] — o primeiro número é o eixo vertical, e lido ao contrário o mapa continua desenhando e passa a dizer outra estratégia. O anchor é o usuário no alto, A -> B liga a cadeia (o nome pode ter espaço, com ou sem aspas), A +> B é fluxo (mais grosso; +<> nos dois sentidos e +'texto'> com rótulo) e evolve Chaleira 0.62 desenha a seta tracejada até onde a peça deve chegar. Valem ainda evolution (troca os rótulos do eixo), size, (build)/(buy)/(outsource)/(market), (inertia) (a barra de resistência), label [dx, dy], pipeline X { … }, note, accelerator/deaccelerator e as annotation numeradas com a legenda do annotations.

O eventmodeling desenha um event modeling: uma linha do tempo em três raias — a tela em cima, o comando (e o modelo de leitura) no meio, o evento embaixo. Cada linha é tf 02 cmd AdicionarItem: o número é o instante (a coluna) e a palavra do meio é o tipo, que escolhe a raia — ui, cmd/command, pcr/processor, rmo/readmodel, view e evt/event (as formas longas valem igual). A raia não se declara: ela é o método. O rf (resetframe) abre uma fatia nova, com um divisor tracejado — é onde a história recomeça. O esquema do quadro vai entre chaves ({ descricao: string }) ou por referência ([[Dados]]) a um bloco data Dados { … }, que pode vir depois; e ->> 02 ->> 03 liga o quadro aos instantes que o alimentam, citando o número.

O railroad (railroad-ebnf-beta, -abnf-beta, -peg-beta ou railroad-beta) desenha uma gramática como trilhos de trem: cada regra vira um caminho que se segue com o dedo, e o que dá para escrever é o que dá para percorrer. A regra é nome = expressão ; (ou nome <- … ; no PEG) e pode ocupar várias linhas — ela se fecha no ;. O texto entre aspas é terminal (desenhado como cápsula) e o nome solto é outra regra (retângulo); | (ou /) é escolha, ? opcional, + um ou mais, * zero ou mais, e ( ), [ ] e { } agrupam, opcionam e repetem. O ABNF põe a repetição antes (1*( ALPHA / "-" ), *DIGIT), o PEG aceita os predicados !x e &x — que vão no rótulo, porque não consomem entrada — e o railroad-beta aceita a grafia de funções (sequence(choice(terminal("+"), …))). Os quatro caem no mesmo desenho: o desvio por cima é o opcional e o laço por baixo, com a seta apontando para trás, é a repetição.

O requirementDiagram desenha requisitos e elementos como caixas de compartimentos: o tipo declarado (requirement, functionalRequirement, performanceRequirement, interfaceRequirement, physicalRequirement, designConstraint) aparece entre guilhemes acima do nome, e os campos id, text, risk e verifymethod viram linhas — no element, type e docref. As relações (satisfies, traces, derives, verifies, refines, copies, contains) escrevem-se a - satisfies -> b ou na forma espelhada b <- satisfies - a, e nesta o primeiro nome é o destino. Só o contains é linha cheia, com o símbolo do lado de quem contém; as demais são tracejadas com a seta no destino. Um nome com espaço vai entre aspas.

O gitGraph desenha o histórico de um repositório: cada commit avança no tempo, branch nome abre uma faixa nova e passa a trabalhar nela (como git switch -c), checkout volta para outra e merge junta as duas. Os atributos vão com dois-pontos: commit id: "texto" tag: "v1" type: HIGHLIGHT (também REVERSE), e branch nome order: 2 muda a ordem das faixas; cherry-pick id: "…" exige o id de um commit que exista. A forma diz o tipo — disco cheio no commit comum, quadrado no destacado, círculo com X no revertido, anel duplo no merge e círculo cortado no cherry-pick —, porque num tema em que dois tons da paleta ficam parecidos só a forma os separa. LR: (padrão), TB: e BT: giram o eixo do tempo. Um checkout/merge de branch que não existe recusa o diagrama apontando a linha, em vez de criar uma faixa que você não pediu.

A família C4 (C4Context, C4Container, C4Component, C4Dynamic e C4Deployment) também é desenhada, e nela tudo é macro — não há seta nenhuma na sintaxe. Cada elemento vira uma caixa com o tipo entre guilhemes, o nome em negrito e a descrição embaixo: Person(alias, "Nome", "Descrição"), System, Container, Component e as variantes Db, Queue e _Ext. No Container e no Component o terceiro argumento é a TECNOLOGIA (Container(app, "App", "C++/Qt", "o que ele faz")), e nos demais ele já é a descrição. As fronteiras (Boundary, Enterprise_Boundary, System_Boundary, Container_Boundary e o Node do C4Deployment) abrem chave e viram caixa com título, aninhadas inclusive. A ligação é Rel(a, b, "rótulo", "tecnologia"); BiRel põe seta nas duas pontas e Rel_Back aponta para trás. O C4Dynamic numera as relações na ordem em que aparecem. As dicas de posição (Rel_U, Rel_D, Rel_L, Rel_R) e os Update…Style são aceitos e ignorados — quem escolhe o arranjo é o mesmo layout dos outros diagramas, e a cor sai do tema da nota. Uma relação que cita um alias não declarado recusa o diagrama apontando a linha, em vez de inventar uma caixa que você não escreveu.

Quadro, gráficos e pacote

No kanban a indentação é a sintaxe, com dois níveis: o de fora é a raia e o de dentro é o cartão (id[Rótulo], ou só o texto). O @{ ticket: LN-9, assigned: 'ana', priority: 'High' } depois do cartão não entra no texto dele: o ticket e o responsável vão para um rodapé próprio e a prioridade (Very High, High, Low, Very Low) vira a cor da tarja na borda esquerda, numa escala do quente ao frio. As raias terminam todas na mesma linha, e uma raia sem cartão continua aparecendo — é ela que mostra a coluna vazia. Este é um quadro desenhado, para explicar um fluxo dentro de uma nota; o quadro em que se trabalha, com cartões que se arrastam, é o painel Tarefas do próprio app.

O xychart (xychart-beta) desenha barras e linhas sobre dois eixos: x-axis "Título" [jan, fev, mar] dá as categorias — um nome com espaço ou vírgula vai entre aspas —, y-axis "Título" 0 --> 100 fixa a escala e cada bar [10, 40, 90] ou line [20, 30, 80] acrescenta uma série, com um valor por categoria, na ordem em que elas foram declaradas. Uma série com valores a mais ou a menos recusa o diagrama apontando a linha: as barras deslizariam para outras categorias e o gráfico passaria a afirmar outra coisa. Sem y-axis, a escala sai dos dados e começa no zero quando eles não descem abaixo dele — começar no menor valor exagera a diferença entre as barras, e ninguém escolheu isso; com a faixa declarada, um valor fora dela recusa em vez de estourar o plano.

O x-axis também aceita uma faixa contínua (0 --> 100), e sem ele as categorias são os índices. Duas séries de barras aparecem lado a lado, e não sobrepostas como no mermaid — sobrepostas, a de trás some. O xychart-beta horizontal ainda não é desenhado e mantém o bloco de código, porque desenhá-lo na vertical entregaria o gráfico transposto. Uma série pode ter nome (bar "Abertos" [10, 40], line "Fechados" [20, 30]): os nomes viram uma legenda acima do plano, com a mesma forma da série — barra cheia, linha com ponto —, porque só a cor não as separa. E numa série de linha o valor pode vir com rótulo ([540 "PaLM", 65]), desenhado acima do ponto; nas barras o rótulo é ignorado, como no Mermaid.

O radar (radar-beta) desenha o perfil de uma ou mais curvas sobre eixos que saem do centro: axis a["Rótulo"], b, c declara os eixos — e a linha pode se repetir —, e curve x["Nome"]{80, 60, 90} dá um valor por eixo, na ordem em que eles foram declarados; a grafia nomeada ({a: 80, c: 90, b: 60}) também vale. Atenção ao sentido: o primeiro eixo aponta para cima e a volta é horária. O max e o min fixam a escala — sem max ela sai do maior valor lido —, e um valor fora dela recusa o diagrama apontando a linha, em vez de ser aparado; ticks muda o número de anéis, graticule circle os deixa redondos e showLegend false tira a legenda. Uma curva com valores a mais ou a menos que os eixos também recusa: ela não seria um desenho incompleto, e sim outro desenho.

O packet (packet-beta) desenha o mapa de bits de um pacote: cada campo é 0-15: "Rótulo", e a faixa é fechada nos dois extremos — 0-15 são dezesseis bits. Um bit só se escreve 4: "Rótulo", e a forma relativa +16: "Rótulo" pega os próximos dezesseis, para você não ter de recontar tudo ao inserir um campo no meio. Os campos precisam ser contíguos: um vão ou uma sobreposição recusa o diagrama apontando a linha, porque qualquer um dos dois deslocaria em silêncio tudo o que vem depois. A fileira tem 32 bits, e um campo que cruza a virada aparece nas duas, com o rótulo na parte mais larga; os números acima da grade marcam onde cada campo começa, mais o último bit de cada fileira.

Grade, áreas, arquitetura, fluxo e ZenUML

O block (block-beta) desenha uma grade de caixas, e nela a posição é a ordem em que você escreveu: columns 3 fixa quantas colunas a grade tem — sem ele, tudo fica numa fileira só —, cada caixa aceita as mesmas formas do fluxograma (a["Rótulo"], b(("círculo")), c{"losango"}), a:2 faz a caixa ocupar duas colunas e space (ou space:2) deixa um buraco. O block:id … end aninha uma grade dentro de outra, com columns próprio, e vira uma caixa em volta. As setas são as do fluxograma (a --> b, com rótulo em a -- "texto" --> b), mas aqui elas só citam blocos já declarados: uma seta para um nome que não existe recusa o diagrama apontando a linha, em vez de inventar uma caixa numa célula que você não escreveu. A folga entre as colunas cresce até caber o rótulo da seta, para ele não encostar na caixa vizinha. A seta de bloco (a<["Ida"]>(right)) é uma caixa em forma de seta: as direções vão entre parênteses (right, left, up, down, ou x para as duas horizontais e y para as duas verticais) e se combinam ((x, down)); uma direção inventada recusa o diagrama apontando a linha, em vez de virar uma seta qualquer.

O treemap (treemap-beta) desenha um mapa de áreas: cada retângulo tem área proporcional ao valor, e a indentação aninha, com profundidade livre. A folha declara o valor ("Nome": 12) e a seção não declara nada — o valor dela é a soma dos filhos, e um total próprio permitiria um retângulo que mente sobre as próprias partes, então isso recusa o diagrama apontando a linha. Um nome com espaço ou dois-pontos vai entre aspas; classDef e :::classe dão cor. O arranjo é o squarified, que mantém os retângulos perto do quadrado — fatiar sempre no mesmo eixo produziria tiras que não se comparam a olho, e comparar áreas é a única coisa que este tipo faz. O rótulo e o valor só aparecem quando cabem inteiros dentro do retângulo: cortados pela borda, não informariam nada.

O architecture (architecture-beta) desenha serviços e as ligações entre eles: service api(server)[API] declara um componente, group nuvem(cloud)[Nuvem] abre uma fronteira, o sufixo in nuvem põe o serviço dentro dela (grupos aninham) e junction j cria um canto para dobrar uma ligação.

O lado da ligação é o que decide a posição: a:R -- L:b encosta a direita de a na esquerda de b, ou seja, põe b à direita de a; valem L, R, T e B, e a ponta aparece do lado do < ou do > (-->, <-->, ou -- sem ponta nenhuma). O sufixo {group} numa ponta manda a linha para a fronteira do grupo, em vez da caixa de dentro. Os ícones são os cinco que o Mermaid embute — cloud, database, disk, internet e server —, e qualquer outro nome recusa o diagrama apontando a linha e dizendo quais existem. Os demais (logos:aws-lambda e parecidos) vêm do Iconify e só aparecem onde quem publica a página registra o pacote por JavaScript, o que nem o GitHub faz: aceitá-los aqui entregaria um desenho que não se repete em nenhum outro lugar. O align row a b c (ou align column) põe os membros citados na mesma fileira — ou na mesma coluna —, e um nome que não existe recusa o diagrama apontando a linha, em vez de deixar o arranjo como estava sem dizer por quê.

O sankey (sankey-beta) desenha um diagrama de fluxo, em que a espessura da fita é o valor: o corpo não tem seta nenhuma — é um CSV de três colunas (origem,destino,valor), uma ligação por linha, e é repetir um nome nas duas pontas que encadeia o fluxo. Um rótulo com vírgula vai entre aspas, e uma aspa dentro dele se escreve duplicada ("Custo ""fixo"""); o mesmo par origem/destino repetido soma. A barra de um nó tem a altura do maior entre o que entra e o que sai, para as fitas de saída de um nó que distribui mais do que recebe não vazarem pela borda. As colunas saem do caminho mais longo até cada nó, e quem não tem saída vai para a última coluna. Valor menor ou igual a zero, ligação de um nó para ele mesmo e ciclo recusam o diagrama apontando a linha — num ciclo não existe caminho mais longo, e cortar uma ligação para poder desenhar mostraria um fluxo que você não escreveu. Aqui não há title: o corpo é CSV puro, e aceitá-lo desenharia bem no LightNote e daria erro de sintaxe no Mermaid.

O zenuml é outra sintaxe para o mesmo desenho — um diagrama de sequência —, escrita como código em vez de setas. A chamada síncrona nomeia só o destino (Loja.registrar(item)) e o remetente é o bloco que a envolve: dentro de Loja.registrar() { Estoque.reservar() }, quem chama o Estoque é a Loja. No nível de fora quem chama é o iniciador — @Starter(Ana) o nomeia, e sem ele entra um User com boneco, que só aparece se alguma chamada precisar dele. A mensagem assíncrona é A->B: texto (ponta aberta, ninguém espera) e A->B.metodo() é a chamada síncrona com o remetente dito à mão. O {} aninha, return x volta para quem chamou a chamada que o envolve (um if no meio não muda isso), x = A.m() é a outra grafia da mesma resposta, new A(args) cria e // comentário vira uma nota acima da mensagem seguinte. Os blocos são if/else if/else, while/for/forEach/loop, opt, par e try/catch/finally — e } else { continua o mesmo quadro, com um divisor, em vez de abrir outro. O @Actor desenha o boneco; os outros anotadores (@Database, @Boundary…) viram estereótipo no rótulo («Database» Estoque), porque os ícones deles não são desenhados aqui — o nome continua aparecendo, que é o que importa. Um nome com espaço vai entre aspas.

Atenção onde este bloco vai parar: no Mermaid o zenuml é um diagrama externo, que a página precisa registrar por JavaScript — o GitHub não faz isso, então a mesma nota que desenha aqui aparece lá como bloco de código.

E quando o LightNote não consegue ler um diagrama, ele diz por quê e em que linha, logo abaixo do bloco — tipo que ainda não desenhamos não gera aviso, porque ali não há nada errado no que você escreveu.