Diagramas (Mermaid)

Cómo funciona

Diagramas Mermaid. Una valla ```mermaid con un diagrama de flujo (flowchart/graph, en las cuatro direcciones), un diagrama de secuencia (sequenceDiagram) o un gráfico circular (pie) se dibuja como diagrama en el modo de lectura, en el archivo exportado y en las respuestas de Preguntar a las notas, que es de donde más vienen los diagramas. El dibujo sigue el tema de la nota (tinta, papel y acento), así que combina con el texto de alrededor en los dos temas. En la edición formateada —el modo predeterminado— el diagrama también aparece dibujado, con la barra del bloque encima (copiar, editar, eliminar). Editar abre una barra abajo con el código fuente: la nota queda bloqueada mientras está abierta y el dibujo se rehace mientras escribes; cerrar aplica (no hay guardar ni cancelar), Ctrl+Z deshace todo el cambio en un paso y vaciar el campo elimina el bloque. En el modo dividido, hacer clic en el diagrama lleva el cursor hasta la valla en el texto plano. En el editor de texto todo sigue siendo texto: pulsa Ctrl+E para ver el diagrama. Dentro de un elemento de lista, el diagrama —y también la estructura SMILES, la fórmula en bloque, [files] y ![[nota]]— queda como texto en la edición con formato y aparece dibujado en el modo de lectura: ahí el marcador del elemento no tendría cómo volver al archivo.

Los subgrafos (subgraph … end, incluso anidados) se dibujan como cajas con título, y las aristas cruzan el borde partiendo del nodo real; el id de un subgrafo también puede ser extremo de una arista (sub --> X). Se respetan los colores declarados por el autor: classDef, class, :::clase y style (relleno, borde, grosor, trazo discontinuo y color del texto). Para empezar, usa Insertar → Diagrama (Mermaid) en la barra de la nota: entra con un esqueleto listo del tipo que elijas. El menú ofrece los seis más usados directamente; Todos los diagramas… abre un selector con los 33, agrupados por su finalidad, con búsqueda (por nombre o por lo que el diagrama muestra) y la vista previa dibujada de cada uno — son 33 dibujos, y ver el dibujo decide más rápido que leer el nombre. El frontmatter del diagrama — el bloque entre --- antes de la primera línea — también se lee: el title se convierte en el título dibujado sobre el dibujo (un title en el cuerpo gana) y las claves de config que LightNote conoce llegan al diagrama (gitGraph.mainBranchName, gantt.displayMode y las de packet: bitsPerRow, bitOrder: descending — que refleja la fila — y showBits: false); lo que no conoce se ignora, sin rechazar la nota.

Secuencia, entidades, clases y estados

En el diagrama de secuencia valen participant/actor (con as), las formas de flecha (->>, -->>, -x, -)), la activación (+/- y activate/deactivate), las notas (Note left of/right of/over), los bloques loop/alt/else/opt/par y autonumber. Lo que todavía no se dibuja — otros tipos de diagrama — sigue apareciendo como bloque de código; direction dentro de un subgrafo y linkStyle se ignoran. La sintaxis de nodo de Mermaid v11 (A@{ shape: rounded, label: "texto" }) se lee, y el catálogo de formas de v11 se dibuja: doc, lin-doc, docs, tag-rect, win-pane, hourglass, bolt, flag, das… — cada una es el símbolo que dice su nombre, y ninguna se convierte en rectángulo, porque un rectángulo en lugar de un documento sería otro diagrama. Un nombre que Mermaid no tiene hace que el diagrama vuelva a ser bloque de código, con la línea señalada. El id de arista (A e1@--> B) y e1@{ animate: true } se aceptan y se ignoran: la animación no se dibuja. El participante tipado (participant DB@{ "type": "database" }) dibuja el símbolo UML sobre la calle — boundary, control, entity, database, queue y collections —, y el "alias" declarado ahí vale como el as.

El erDiagram también se dibuja: cada entidad se convierte en una caja con sus atributos y la cardinalidad aparece en los dos extremos de la relación (||--o{, }o--||, |o, |{); -- es relación identificadora y .. no identificadora. El alias p[Persona] nombra la caja sin cambiar el id que citan las relaciones. El subgraph … end también vale aquí: las entidades de dentro reciben una caja con título, los subgrafos anidan y el id de la caja puede ser extremo de una relación (CLIENTE ||--o{ Ventas : hace), uniéndose a la frontera en vez de a una entidad con ese nombre.

El classDiagram igual: caja de tres compartimentos (nombre, atributos y métodos, separados por el paréntesis del método), <<interface>> en línea propia, namespace como caja y las seis relaciones (<|--, *--, o--, -->, ..>, ..|>). Atención a la dirección: en A <|-- B el triángulo está en A — quien hereda es B. La cardinalidad entre comillas aparece en los dos extremos ("1" --> "*"). Los genéricos Lista~T~ aparecen como Lista<T>, también en los miembros. La interfaz piruleta (bar ()-- foo) dibuja el círculo encima de la caja del lado en que está el () — y solo ahí —, con la relación tocando el círculo; los namespace también anidan, y tras el } interno una clase vuelve al namespace de fuera.

El stateDiagram-v2 dibuja la máquina de estados: [*] es el inicio (disco lleno) y el fin (disco con anillo), state X { … } se convierte en caja, <<fork>>/<<join>> en barra y <<choice>> en rombo. El -- dentro de un estado compuesto separa las regiones concurrentes, marcadas con una línea discontinua.

Línea de tiempo, recorrido, cuadrantes y Gantt

La timeline también se dibuja: cada período se convierte en una columna de la línea de tiempo, con sus eventos apilados debajo, y section agrupa las eras en franjas de color. Valen las dos grafías para varios eventos — dos puntos en la misma línea (2004 : Facebook : Google) y continuación en la línea siguiente (: otro evento) —, y aquí cualquier línea que no sea title, section o direction es texto libre. direction TD (línea de tiempo vertical) todavía no se dibuja y mantiene el bloque de código.

El journey (recorrido del usuario) también se dibuja: cada tarea se convierte en una caja sobre el eje del recorrido, y la puntuación de 1 a 5 desplaza su cara hacia arriba o hacia abajo — es el perfil que forman lo que el diagrama existe para mostrar. section agrupa las fases y los actores se vuelven marcadores de color en la tarea, con la leyenda a la izquierda. Aquí la gramática es estricta (Tarea: puntuación: Actor, Actor), a diferencia de la del timeline: sin el par nombre/puntuación no hay dónde poner la cara, así que una línea malformada — o una puntuación fuera de 1 a 5 — rechaza el diagrama, señalando la línea.

Y el quadrantChart dibuja el plano de los cuatro cuadrantes: x-axis e y-axis nombran los extremos de cada eje (el lado derecho del --> es opcional), quadrant-1 a quadrant-4 etiquetan las regiones y cada punto entra como Nombre: [x, y], con x e y de 0 a 1. Atención a la numeración: es la del plano cartesiano, no la de la lectura — quadrant-1 es el de arriba a la derecha, y desde ahí se avanza en sentido antihorario; y = 1 queda arriba. El color y el radio de un punto pueden venir directos (P: [0.5, 0.5] radius: 10, color: #109060) o por clase (P:::clase más classDef), y el estilo directo gana a la clase. Una coordenada fuera de 0 a 1 rechaza el diagrama señalando la línea en vez de recortarse — es la posición en el plano, y recortarla pondría el punto en un cuadrante que no escribiste.

El gantt dibuja el cronograma: dateFormat indica el formato de las fechas que escribes (por omisión YYYY-MM-DD) y axisFormat el de las etiquetas del eje (%d/%m); section agrupa las tareas en franjas. Cada tarea es Texto : marcas, id, inicio, fin — las marcas done, active, crit y milestone van primero y se pueden combinar, el inicio es una fecha o after otroId, y el fin es una fecha, una duración (5d, 2w, 3h, 45m) o until otroId. Con un solo campo, la tarea empieza donde terminó la anterior.

El after puede citar una tarea declarada más abajo en la nota; en cambio, un id que no existe en ninguna parte — o una dependencia circular — rechaza el diagrama señalando la línea, en vez de poner la barra en el día de hoy. El excludes weekends (o excludes monday, o una fecha) empuja el fin de cada tarea por los días excluidos, y por eso cambia la longitud de las barras; includes 2026-03-07 gana al fin de semana, para decir que ese sábado sí se trabaja. El hito (milestone) aparece como un rombo, y todayMarker off quita la línea del día de hoy. El displayMode compact apila varias tareas en la misma fila, y aquí una tarea solo comparte la fila cuando nada de lo que ocupa toca lo que ya está allí — la etiqueta incluida. El marcador vert (Apertura : vert, v1, 20:15, 0m) dibuja el instante como una línea vertical que cruza todo el gráfico, sin ocupar ninguna fila, y su etiqueta sale bajo el eje. El dateFormat X (o x) lee la fecha como tiempo Unix en segundos (o milisegundos), y en el eje el %s/%Q la escribe de vuelta. Un tickInterval que Mermaid no conoce (1decade) se ignora en silencio, como allí, y el eje vuelve al automático.

Mapa mental, requisitos, Git y C4

En el mindmap la jerarquía viene de la indentación: el nivel de un elemento es la columna en la que empieza su texto, sin llaves ni flechas (el tabulador vale hasta la siguiente parada de 4, como en un editor). El primer elemento es la raíz — un segundo elemento en su columna sería una segunda raíz, y entonces el diagrama se rechaza señalando la línea. Cada elemento puede declarar su forma: [cuadrado], (redondeado), ((círculo)), {{hexágono}}, ))explosión(( y )nube(; sin delimitador sale redondeado. El ::icon(...) y el :::clase se reconocen y se ignoran (no empaquetamos la fuente de iconos, y la clase se refiere a un CSS externo que aquí no existe). El dibujo es de dos lados — la raíz en el centro, las ramas repartidas a izquierda y derecha —, cada rama con un color propio que heredan sus descendientes, y el grosor de la rama baja con la profundidad.

Es un árbol, no una simulación de fuerzas como en mermaid: en un mapa mental la jerarquía es el contenido, así que debe leerse en la posición — y, como el dibujo se rehace al cambiar de tema, un trazado que convergiera desde posiciones aleatorias reorganizaría el mapa entero cada vez.

El treeView (treeView-beta) dibuja el árbol de carpetas de un proyecto, y acepta las dos grafías: la sangría (lo que se escribe) y los propios caracteres del comando tree (├──, │, └──), que es lo que permite pegar la salida del terminal directamente en la nota — allí la sangría no sirve, porque │ y un espacio ocupan la misma columna y solo el primero dice que la rama sigue. La barra final marca la carpeta (src/), un nombre con espacios va entre comillas, el ## texto cuelga un comentario al final de la línea y el :::highlight resalta el nombre. El icon(...) se reconoce y se ignora, como el ::icon() del mapa mental: los paquetes de iconos vienen de Iconify por JavaScript, y ni el propio Mermaid los dibuja por defecto.

El ishikawa (ishikawa-beta) dibuja la espina de pescado de un análisis de causas: el primer elemento es el EFECTO (la cabeza, a la derecha), el nivel siguiente son las categorías (las espinas) y los dos de dentro son las causas y las subcausas. Son tres niveles, y un cuarto rechaza el diagrama señalando la línea — no existe en Mermaid. Las espinas alternan arriba y abajo del eje, que es lo que permite que dos categorías vecinas quepan sin que el texto de una caiga sobre el de la otra, y el orden en que escribes las causas se lee de arriba abajo en ambos lados.

El venn (venn-beta) dibuja conjuntos que se cruzan: set A["Deseable"] declara uno, union A,B["Se puede construir"] nombra la región común (la unión se llama por los conjuntos que cruza) y text A1["React"], justo debajo de uno de ellos, pone un elemento dentro de esa región. Son hasta tres conjuntos, y el cuarto rechaza el diagrama señalando la línea: con cuatro círculos no hay disposición que produzca todas las regiones, y dibujar uno "casi correcto" ocultaría una que declaraste. El :número tras la etiqueta (set A["Alpha"]:20) escala el círculo — el área sigue al número — y no las intersecciones: un Venn con intersección proporcional es otro diagrama (Euler), que exige optimización numérica. El style A fill:#ff6b6b pinta un conjunto, y con coma (style A,B color:#333) vale para la unión de esos conjuntos.

El cynefin (cynefin-beta) dibuja el marco de Snowden para clasificar decisiones: los cinco dominios tienen nombre fijo — complex, complicated, chaotic, clear y confusion — y posición fija (los cuatro cuadrantes, con la confusión en el medio); lo que eliges es lo que va dentro de cada uno. Cada elemento va entre comillas, uno por línea, y complex --> complicated : "Patrón identificado" dibuja la transición entre dos dominios. Un nombre fuera de los cinco rechaza el diagrama señalando la línea y diciendo cuáles existen. La frontera entre clear y chaotic sale ondulada: en el modelo es un precipicio, y la forma lo dice — aquí la onda es siempre la misma, para que la nota no cambie de dibujo en cada apertura.

El swimlane (swimlane-beta) dibuja un proceso en franjas, una por responsable: la sintaxis es la del diagrama de flujo (las mismas formas, flechas, etiquetas y classDef), y cada subgraph deja de ser una caja para convertirse en un carril. Todo nodo debe estar dentro de uno — un nodo suelto rechaza el diagrama, porque no habría cómo decir de quién es la tarea — y un carril dentro de otro también rechaza. Con LR los carriles son filas y el flujo va a la derecha; con TB son columnas y el flujo baja. La posición a lo largo del flujo sale del camino más largo hasta cada tarea, y la franja es la del dueño: una tarea nunca sale de su carril, aunque eso hiciera el dibujo más compacto.

El agentflow (agentflow-beta) dibuja un flujo con agentes de IA, y es otro vocabulario para el diagrama de flujo: las flechas son las mismas, flow id["Nombre"] … end hace el papel de subgraph (y anida), global … end guarda lo que todos los agentes consultan y connector id["Nombre"] declara un sistema externo. Lo que cambia de verdad es la forma, que dice el papel de cada paso: @{ shape: input }, task, tool (llamada a herramienta), decision, refdoc (documento de referencia) y action (acción final). Conecta el documento con -.-, sin flecha: se consulta, no es un paso del flujo. Las claves que describen al agente por escrito (instruction, params, returns, connectorRef, protocol, endpoint) se leen y se ignoran en el dibujo. Estos nombres de forma solo valen aquí: en un flowchart rechazan, porque allí Mermaid tampoco los tiene.

El usecase (usecase-beta) dibuja el diagrama de casos de uso de UML: lo que se declara con actor se convierte en el muñeco, y todo lo demás es un caso de uso, dibujado como elipse — esa es la distinción que el tipo existe para mostrar. El caso de uso puede venir como Id("Etiqueta"), Id[Etiqueta], solo Id o solo el texto entre comillas; el systemBoundary "Nombre" … end es la frontera del sistema y note for X "texto" cuelga una nota. Las relaciones son las de UML: --> asocia, --|> es generalización (el triángulo hueco queda en el general) y A ..> : include B — con el destino después de los dos puntos — dibuja el « include » punteado, y vale igual para extend. Lo que describe al actor sin cambiar el dibujo (type, business, icon) se lee y se ignora, y el <<Estereotipo>> entra en la etiqueta. El nodo json aún no se dibuja y mantiene el bloque de código: es un bloque de varias líneas con el árbol del dato dentro, y ahí el JSON sigue legible como texto.

El wardley (wardley-beta) dibuja un mapa de Wardley: un plano cuyo eje vertical es la visibilidad para el usuario (arriba está lo que él ve) y cuyo eje horizontal es la evolución, de Genesis a Commodity.

Atención al orden del par: component Té [0.63, 0.81] es [visibilidad, evolución] — el primer número es el eje vertical, y leído al revés el mapa se sigue dibujando y pasa a decir otra estrategia. El anchor es el usuario arriba, A -> B une la cadena (el nombre puede llevar espacios, con o sin comillas), A +> B es flujo (más grueso; +<> en ambos sentidos y +'texto'> con etiqueta) y evolve Hervidor 0.62 dibuja la flecha punteada hasta donde la pieza debe llegar. También valen evolution (cambia las etapas del eje), size, (build)/(buy)/(outsource)/(market), (inertia) (la barra de resistencia), label [dx, dy], pipeline X { … }, note, accelerator/deaccelerator y las annotation numeradas con la leyenda de annotations.

El eventmodeling dibuja un event modeling: una línea de tiempo en tres carriles — la pantalla arriba, el comando (y el modelo de lectura) en medio, el evento abajo. Cada línea es tf 02 cmd AñadirArtículo: el número es el instante (la columna) y la palabra del medio es el tipo, que elige el carril — ui, cmd/command, pcr/processor, rmo/readmodel, view y evt/event (las formas largas valen igual). El carril no se declara: es el método. El rf (resetframe) abre una rebanada nueva, con un divisor punteado — es donde la historia vuelve a empezar. El esquema del cuadro va entre llaves ({ descripcion: string }) o por referencia ([[Datos]]) a un bloque data Datos { … }, que puede venir después; y ->> 02 ->> 03 une el cuadro a los instantes que lo alimentan, citando el número.

El railroad (railroad-ebnf-beta, -abnf-beta, -peg-beta o railroad-beta) dibuja una gramática como vías de tren: cada regla es un camino que se sigue con el dedo, y lo que se puede escribir es lo que se puede recorrer. La regla es nombre = expresión ; (o nombre <- … ; en PEG) y puede ocupar varias líneas: se cierra en el ;. El texto entre comillas es terminal (cápsula) y el nombre suelto es otra regla (rectángulo); | (o /) es elección, ? opcional, + uno o más, * cero o más, y ( ), [ ] y { } agrupan, hacen opcional y repiten. El ABNF pone la repetición antes (1*( ALPHA / "-" ), *DIGIT), el PEG acepta los predicados !x y &x — que van en la etiqueta, porque no consumen entrada — y railroad-beta acepta la grafía de funciones (sequence(choice(terminal("+"), …))). Los cuatro caen en el mismo dibujo: el desvío por arriba es lo opcional y el bucle por abajo, con la flecha hacia atrás, es la repetición.

El requirementDiagram dibuja requisitos y elementos como cajas de compartimentos: el tipo declarado (requirement, functionalRequirement, performanceRequirement, interfaceRequirement, physicalRequirement, designConstraint) aparece entre comillas angulares encima del nombre, y los campos id, text, risk y verifymethod se convierten en filas — en un element, type y docref. Las relaciones (satisfies, traces, derives, verifies, refines, copies, contains) se escriben a - satisfies -> b o en la forma espejada b <- satisfies - a, y en esta el primer nombre es el destino. Solo contains es línea continua, con el símbolo del lado de quien contiene; las demás son discontinuas con la flecha en el destino. Un nombre con espacio va entre comillas.

El gitGraph dibuja el historial de un repositorio: cada commit avanza en el tiempo, branch nombre abre un carril nuevo y pasa a trabajar en él (como git switch -c), checkout vuelve a otro y merge une los dos. Los atributos llevan dos puntos: commit id: "texto" tag: "v1" type: HIGHLIGHT (también REVERSE), y branch nombre order: 2 cambia el orden de los carriles; cherry-pick id: "…" exige el id de un commit que exista. La forma dice el tipo — disco lleno en el commit común, cuadrado en el destacado, círculo con X en el revertido, anillo doble en el merge y círculo cortado en el cherry-pick —, porque en un tema donde dos tonos de la paleta se parecen solo la forma los separa. LR: (predeterminado), TB: y BT: giran el eje del tiempo. Un checkout/merge de una rama que no existe rechaza el diagrama señalando la línea, en lugar de crear un carril que no pediste.

La familia C4 (C4Context, C4Container, C4Component, C4Dynamic y C4Deployment) también se dibuja, y en ella todo es macro: no hay ninguna flecha en la sintaxis. Cada elemento se convierte en una caja con el tipo entre comillas angulares, el nombre en negrita y la descripción debajo: Person(alias, "Nombre", "Descripción"), System, Container, Component y las variantes Db, Queue y _Ext. En Container y Component el tercer argumento es la TECNOLOGÍA (Container(app, "App", "C++/Qt", "lo que hace")); en los demás ya es la descripción. Las fronteras (Boundary, Enterprise_Boundary, System_Boundary, Container_Boundary y el Node de C4Deployment) abren llave y se convierten en una caja con título, anidadas incluso. El enlace es Rel(a, b, "etiqueta", "tecnología"); BiRel pone flecha en los dos extremos y Rel_Back apunta hacia atrás. El C4Dynamic numera las relaciones en el orden en que aparecen. Las pistas de posición (Rel_U, Rel_D, Rel_L, Rel_R) y los Update…Style se aceptan y se ignoran: la disposición sale del mismo layout que los demás diagramas y el color sale del tema de la nota. Una relación que cita un alias no declarado rechaza el diagrama señalando la línea, en lugar de inventar una caja que no escribiste.

Tablero, gráficos y paquete

En el kanban la indentación es la sintaxis, con dos niveles: el de fuera es el carril y el de dentro es la tarjeta (id[Etiqueta], o solo el texto). El @{ ticket: LN-9, assigned: 'ana', priority: 'High' } tras la tarjeta no entra en su texto: el ticket y el responsable van a un pie propio, y la prioridad (Very High, High, Low, Very Low) se convierte en el color de la franja del borde izquierdo, en una escala de cálido a frío. Todos los carriles terminan en la misma línea, y un carril sin tarjetas sigue apareciendo: es lo que muestra la columna vacía. Este es un tablero dibujado, para explicar un flujo dentro de una nota; el tablero en el que se trabaja, con tarjetas que se arrastran, es el panel Tareas de la propia aplicación.

El xychart (xychart-beta) dibuja barras y líneas sobre dos ejes: x-axis "Título" [ene, feb, mar] da las categorías —un nombre con espacio o coma va entre comillas—, y-axis "Título" 0 --> 100 fija la escala y cada bar [10, 40, 90] o line [20, 30, 80] añade una serie, con un valor por categoría, en el orden en que fueron declaradas. Una serie con más o menos valores rechaza el diagrama señalando la línea: las barras se deslizarían a otras categorías y el gráfico pasaría a afirmar otra cosa. Sin y-axis, la escala sale de los datos y empieza en cero cuando estos no bajan de ahí —empezar en el menor valor exagera la diferencia entre las barras, y nadie eligió eso—; con el rango declarado, un valor fuera de él se rechaza en vez de desbordar el plano.

El x-axis también acepta un rango continuo (0 --> 100), y sin él las categorías son los índices. Dos series de barras aparecen una al lado de la otra, y no superpuestas como en mermaid: superpuestas, la de atrás desaparece. El xychart-beta horizontal todavía no se dibuja y mantiene el bloque de código, porque dibujarlo en vertical entregaría el gráfico transpuesto. Una serie puede tener nombre (bar "Abiertos" [10, 40], line "Cerrados" [20, 30]): los nombres forman una leyenda sobre el plano, con la misma forma de la serie — barra llena, línea con punto —, porque solo el color no las separa. Y en una serie de línea el valor puede llevar etiqueta ([540 "PaLM", 65]), dibujada encima del punto; en las barras la etiqueta se ignora, como en Mermaid.

El radar (radar-beta) dibuja el perfil de una o más curvas sobre ejes que salen del centro: axis a["Etiqueta"], b, c declara los ejes —la línea puede repetirse— y curve x["Nombre"]{80, 60, 90} da un valor por eje, en el orden en que fueron declarados; la forma con nombre ({a: 80, c: 90, b: 60}) también vale. Atención al sentido: el primer eje apunta hacia arriba y el giro es horario. max y min fijan la escala —sin max sale del mayor valor leído— y un valor fuera de ella rechaza el diagrama señalando la línea, en vez de recortarse; ticks cambia el número de anillos, graticule circle los vuelve redondos y showLegend false quita la leyenda. Una curva con más o menos valores que ejes también se rechaza: no sería un dibujo incompleto, sino otro dibujo.

El packet (packet-beta) dibuja el mapa de bits de un paquete: cada campo es 0-15: "Etiqueta", y el rango es cerrado en ambos extremos —0-15 son dieciséis bits—. Un solo bit se escribe 4: "Etiqueta", y la forma relativa +16: "Etiqueta" toma los dieciséis siguientes, para no tener que recontar todo al insertar un campo en medio. Los campos deben ser contiguos: un hueco o un solapamiento rechaza el diagrama señalando la línea, porque cualquiera de los dos desplazaría en silencio todo lo que viene después. La fila tiene 32 bits, y un campo que cruza el salto aparece en las dos, con la etiqueta en la parte más ancha; los números sobre la cuadrícula marcan dónde empieza cada campo, más el último bit de cada fila.

Cuadrícula, áreas, arquitectura, flujo y ZenUML

El block (block-beta) dibuja una cuadrícula de cajas, y en ella la posición es el orden en que las escribiste: columns 3 fija cuántas columnas tiene la cuadrícula —sin él, todo queda en una sola fila—, cada caja acepta las mismas formas del diagrama de flujo (a["Etiqueta"], b(("círculo")), c{"rombo"}), a:2 hace que la caja ocupe dos columnas y space (o space:2) deja un hueco. El block:id … end anida una cuadrícula dentro de otra, con su propio columns, y se convierte en una caja alrededor. Las flechas son las del diagrama de flujo (a --> b, con etiqueta en a -- "texto" --> b), pero aquí solo citan bloques ya declarados: una flecha a un nombre que no existe rechaza el diagrama señalando la línea, en vez de inventar una caja en una celda que no escribiste. El hueco entre columnas crece hasta que quepa la etiqueta de la flecha, para que no toque la caja vecina. La flecha de bloque (a<["Ida"]>(right)) es una caja con forma de flecha: las direcciones van entre paréntesis (right, left, up, down, o x para las dos horizontales e y para las dos verticales) y se combinan ((x, down)); una dirección inventada rechaza el diagrama señalando la línea, en vez de convertirse en una flecha cualquiera.

El treemap (treemap-beta) dibuja un mapa de áreas: cada rectángulo tiene un área proporcional a su valor, y la indentación anida, con profundidad libre. La hoja declara el valor ("Nombre": 12) y la sección no declara nada —su valor es la suma de los hijos, y un total propio permitiría un rectángulo que miente sobre sus propias partes, así que eso rechaza el diagrama señalando la línea—. Un nombre con espacio o dos puntos va entre comillas; classDef y :::clase dan color. La disposición es la squarified, que mantiene los rectángulos cerca del cuadrado: cortar siempre en el mismo eje produciría tiras que no se comparan a ojo, y comparar áreas es lo único que hace este tipo. La etiqueta y el valor solo aparecen cuando caben enteros dentro del rectángulo: cortados por el borde no informarían nada.

El architecture (architecture-beta) dibuja servicios y los enlaces entre ellos: service api(server)[API] declara un componente, group nube(cloud)[Nube] abre una frontera, el sufijo in nube mete el servicio dentro de ella (los grupos se anidan) y junction j crea una esquina para doblar un enlace.

El lado del enlace es lo que decide la posición: a:R -- L:b toca la derecha de a con la izquierda de b, es decir, pone b a la derecha de a; valen L, R, T y B, y la punta aparece del lado del < o del > (-->, <-->, o -- sin punta). El sufijo {group} en un extremo manda la línea a la frontera del grupo, en lugar de la caja de dentro. Los iconos son los cinco que Mermaid trae incorporados —cloud, database, disk, internet y server—, y cualquier otro nombre rechaza el diagrama señalando la línea y diciendo cuáles existen. Los demás (logos:aws-lambda y parecidos) vienen de Iconify y solo aparecen donde quien publica la página registra el paquete por JavaScript, cosa que ni GitHub hace: aceptarlos aquí daría un dibujo que no se repite en ningún otro sitio. El align row a b c (o align column) pone los miembros citados en la misma fila — o en la misma columna —, y un nombre que no existe rechaza el diagrama señalando la línea, en vez de dejar la disposición como estaba sin decir por qué.

El sankey (sankey-beta) dibuja un diagrama de flujo en el que el grosor de la cinta es el valor: el cuerpo no tiene ninguna flecha — es un CSV de tres columnas (origen,destino,valor), un enlace por línea, y repetir un nombre en los dos extremos es lo que encadena el flujo. Una etiqueta con coma va entre comillas, y una comilla dentro de ella se escribe duplicada ("Costo ""fijo"""); el mismo par origen/destino repetido se suma. La barra de un nodo tiene la altura del mayor entre lo que entra y lo que sale, para que las cintas de salida de un nodo que distribuye más de lo que recibe no se desborden. Las columnas salen del camino más largo hasta cada nodo, y lo que no tiene salida va a la última columna. Un valor menor o igual a cero, un enlace de un nodo a sí mismo y un ciclo rechazan el diagrama señalando la línea — en un ciclo no existe camino más largo, y cortar un enlace para poder dibujar mostraría un flujo que no escribiste. Aquí no hay title: el cuerpo es CSV puro, y aceptarlo dibujaría bien en LightNote y daría error de sintaxis en Mermaid.

El zenuml es otra sintaxis para el mismo dibujo — un diagrama de secuencia — escrita como código en vez de flechas. La llamada síncrona nombra solo el destino (Tienda.registrar(item)) y el remitente es el bloque que la envuelve: dentro de Tienda.registrar() { Stock.reservar() }, quien llama a Stock es la Tienda. En el nivel exterior quien llama es el iniciador — @Starter(Ana) lo nombra, y sin él entra un User con monigote, que solo aparece si alguna llamada lo necesita. El mensaje asíncrono es A->B: texto (punta abierta, nadie espera) y A->B.metodo() es la llamada síncrona con el remitente escrito a mano. {} anida, return x vuelve a quien hizo la llamada que lo envuelve (un if en medio no cambia eso), x = A.m() es la otra grafía de la misma respuesta, new A(args) crea y // comentario se vuelve una nota encima del mensaje siguiente. Los bloques son if/else if/else, while/for/forEach/loop, opt, par y try/catch/finally — y } else { continúa el mismo marco, con un divisor, en vez de abrir otro. @Actor dibuja el monigote; los demás anotadores (@Database, @Boundary…) se vuelven estereotipo en la etiqueta («Database» Stock), porque sus iconos no se dibujan aquí — el nombre sigue apareciendo, que es lo que importa. Un nombre con espacio va entre comillas.

Atención a dónde va a parar este bloque: en Mermaid el zenuml es un diagrama externo que la página debe registrar por JavaScript — GitHub no lo hace, así que la misma nota que dibuja aquí allí aparece como bloque de código.

Y cuando LightNote no puede leer un diagrama, dice por qué y en qué línea, justo debajo del bloque — un tipo que aún no dibujamos no genera aviso, porque ahí no hay nada mal en lo que escribiste.