{"owner":"mermaid-js","repo":"mermaid","hasSkills":true,"totalSkillsCount":76,"totalTokensCount":177618,"categories":["plugin-manifest","anthropic-skill"],"hasMcp":false,"mcpConfig":null,"found":["packages/examples/README.md","packages/mermaid-layout-elk/README.md","packages/mermaid-layout-tidy-tree/README.md","packages/mermaid-local-editor/README.md","packages/mermaid-zenuml/README.md","packages/mermaid/src/docs/adding-new-shape.md","packages/mermaid/src/docs/community/contributing.md","packages/mermaid/src/docs/community/e2e-tests.md","packages/mermaid/src/docs/community/intro.md","packages/mermaid/src/docs/community/layout-makers-guide.md","packages/mermaid/src/docs/community/new-diagram-jison.md","packages/mermaid/src/docs/community/new-diagram.md","packages/mermaid/src/docs/community/questions-and-suggestions.md","packages/mermaid/src/docs/community/security.md","packages/mermaid/src/docs/config/8.6.0_docs.md","packages/mermaid/src/docs/config/accessibility.md","packages/mermaid/src/docs/config/configuration.md","packages/mermaid/src/docs/config/directives.md","packages/mermaid/src/docs/config/faq.md","packages/mermaid/src/docs/config/icons.md","packages/mermaid/src/docs/config/layouts.md","packages/mermaid/src/docs/config/math.md","packages/mermaid/src/docs/config/mermaidCLI.md","packages/mermaid/src/docs/config/theming.md","packages/mermaid/src/docs/config/tidy-tree.md","packages/mermaid/src/docs/config/usage.md","packages/mermaid/src/docs/ecosystem/integrations-community.md","packages/mermaid/src/docs/ecosystem/integrations-create.md","packages/mermaid/src/docs/ecosystem/mermaid-chart.md","packages/mermaid/src/docs/ecosystem/tutorials.md","packages/mermaid/src/docs/index.md","packages/mermaid/src/docs/intro/examples.md","packages/mermaid/src/docs/intro/getting-started.md","packages/mermaid/src/docs/intro/index.md","packages/mermaid/src/docs/intro/syntax-reference.md","packages/mermaid/src/docs/news/announcements.md","packages/mermaid/src/docs/news/blog.md","packages/mermaid/src/docs/package.json","packages/mermaid/src/docs/public/manifest.json","packages/mermaid/src/docs/syntax/agentflow.md","packages/mermaid/src/docs/syntax/architecture.md","packages/mermaid/src/docs/syntax/block.md","packages/mermaid/src/docs/syntax/c4.md","packages/mermaid/src/docs/syntax/classDiagram.md","packages/mermaid/src/docs/syntax/cynefin.md","packages/mermaid/src/docs/syntax/entityRelationshipDiagram.md","packages/mermaid/src/docs/syntax/eventmodeling.md","packages/mermaid/src/docs/syntax/examples.md","packages/mermaid/src/docs/syntax/flowchart.md","packages/mermaid/src/docs/syntax/gantt.md","packages/mermaid/src/docs/syntax/gitgraph.md","packages/mermaid/src/docs/syntax/ishikawa.md","packages/mermaid/src/docs/syntax/kanban.md","packages/mermaid/src/docs/syntax/mindmap.md","packages/mermaid/src/docs/syntax/packet.md","packages/mermaid/src/docs/syntax/pie.md","packages/mermaid/src/docs/syntax/quadrantChart.md","packages/mermaid/src/docs/syntax/radar.md","packages/mermaid/src/docs/syntax/railroad.md","packages/mermaid/src/docs/syntax/requirementDiagram.md","packages/mermaid/src/docs/syntax/sankey.md","packages/mermaid/src/docs/syntax/sequenceDiagram.md","packages/mermaid/src/docs/syntax/stateDiagram.md","packages/mermaid/src/docs/syntax/swimlanes.md","packages/mermaid/src/docs/syntax/timeline.md","packages/mermaid/src/docs/syntax/treeView.md","packages/mermaid/src/docs/syntax/treemap.md","packages/mermaid/src/docs/syntax/usecase.md","packages/mermaid/src/docs/syntax/userJourney.md","packages/mermaid/src/docs/syntax/venn.md","packages/mermaid/src/docs/syntax/wardley.md","packages/mermaid/src/docs/syntax/xyChart.md","packages/mermaid/src/docs/syntax/zenuml.md","packages/mermaid/src/docs/tsconfig.json","packages/parser/README.md","packages/tiny/README.md"],"skills":{"packages/examples/README.md":"","packages/mermaid-layout-elk/README.md":"","packages/mermaid-layout-tidy-tree/README.md":"","packages/mermaid-local-editor/README.md":"","packages/mermaid-zenuml/README.md":"","packages/mermaid/src/docs/adding-new-shape.md":"# Custom SVG Shapes Library\n\nThis library provides a collection of custom SVG shapes, utilities, and helpers for generating diagram components. The shapes are designed to be used within an SVG container and include a variety of common and complex shapes.\n\n## Overview\n\n## Shape Helpers and Utilities\n\nBefore starting with shape creation, it's essential to familiarize yourself with the utilities provided in the `utils.ts` file from `packages/mermaid/src/rendering-util/rendering-elements/shapes/util.js`. These utilities are designed to assist with various aspects of SVG shape manipulation and ensure consistent and accurate rendering.\n\n## Available Utilities\n\n### 1. `labelHelper`\n\n- **Purpose**: This function creates and inserts labels inside SVG shapes.\n- **Features**:\n - Handles both HTML labels and plain text.\n - Calculates the bounding box dimensions of the label.\n - Ensures proper positioning of labels within shapes.\n\n### 2. `updateNodeBounds`\n\n- **Purpose**: Updates the bounding box dimensions (width and height) of a node.\n- **Usage**:\n - Adjusts the size of the node to fit the content or shape.\n - Useful for ensuring that shapes resize appropriately based on their content.\n\n### 3. `insertPolygonShape`\n\n- **Purpose**: Inserts a polygon shape into an SVG container.\n- **Features**:\n - Handles the creation and insertion of complex polygonal shapes.\n - Configures the shape's appearance and positioning within the SVG container.\n\n### 4. `getNodeClasses`\n\n- **Purpose**: Returns the appropriate CSS classes for a node based on its configuration.\n- **Usage**:\n - Dynamically applies CSS classes to nodes for styling purposes.\n - Ensures that nodes adhere to the desired design and theme.\n\n### 5. `createPathFromPoints`\n\n- **Purpose**: Generates an SVG path string from an array of points.\n- **Usage**:\n - Converts a list of points into a smooth path.\n - Useful for creating custom shapes or paths within the SVG.\n\n### 6. `generateFullSineWavePoints`\n\n- **Purpose**: Generates points for a sine wave, useful for creating wavy-edged shapes.\n- **Usage**:\n - Facilitates the creation of shapes with wavy or sine-wave edges.\n - Can be used to add decorative or dynamic edges to shapes.\n\n## Getting Started\n\nTo utilize these utilities, simply import them from the `utils.ts` file into your shape creation script. These helpers will streamline the process of building and customizing SVG shapes, ensuring consistent results across your projects.\n\n```typescript\nimport {\n labelHelper,\n updateNodeBounds,\n insertPolygonShape,\n getNodeClasses,\n createPathFromPoints,\n generateFullSineWavePoints,\n} from './utils.ts';\n```\n\n## Example Usage\n\nHere’s a basic example of how you might use some of these utilities:\n\n```typescript\nimport { labelHelper, insertPolygonShape } from './utils.ts';\n\nconst svgContainer = document.getElementById('svgContainer');\n\n// Insert a polygon shape\ninsertPolygonShape(svgContainer /* shape-specific parameters */);\n\n// Create and insert a label inside the shape\nlabelHelper(svgContainer /* label-specific parameters */);\n```\n\n## Adding New Shapes\n\n### 1. Create the Shape Function\n\nTo add a new shape:\n\n- **Create the shape function**: Create a new file of name of the shape and export a function in the `shapes` directory that generates your shape. The file and function should follow the pattern used in existing shapes and return an SVG element.\n\n- **Example**:\n\n ```typescript\n import { Node, RenderOptions } from '../../types.ts';\n\n export const myNewShape = async (\n parent: SVGAElement,\n node: Node,\n renderOptions: RenderOptions\n ) => {\n // Create your shape here\n const shape = parent.insert('g').attr('class', 'my-new-shape');\n // Add other elements or styles as needed\n return shape;\n };\n ```\n\n### 2. Register the Shape\n\n- **Register the shape**: Add your shape to the `shapes` object in the [main shapes module](../rendering-util/rendering-elements/shapes.ts). This allows your shape to be recognized and used within the system.\n\n- **Example**:\n\n ```typescript\n import { myNewShape } from './shapes/myNewShape';\n\n const shapes = {\n ...,\n {\n semanticName: 'My Shape',\n name: 'Shape Name',\n shortName: '',\n description: '',\n aliases: ['', '', '', ''],\n handler: myNewShape,\n },\n };\n ```\n\n# Shape Intersection Algorithms\n\nThis contains algorithms and utilities for calculating intersection points for various shapes in SVG. Arrow intersection points are crucial for accurately determining where arrows connect with shapes. Ensuring precise intersection points enhances the clarity and accuracy of flowcharts and diagrams.\n\n## Shape Intersection Functions\n\n### 1. `Ellipse`\n\nCalculates the intersection points for an ellipse.\n\n**Usage**:\n\n```javascript\nimport intersectEllipse from './intersect-ellipse.js';\n\nconst intersection = intersectEllipse(node, rx, ry, point);\n```\n\n- **Parameters**:\n - `node`: The SVG node element.\n - `rx`: The x-radius of the ellipse.\n - `ry`: The y-radius of the ellipse.\n - `point`: The point from which the intersection is calculated.\n\n### 2. `intersectRect`\n\nCalculates the intersection points for a rectangle.\n\n**Usage**:\n\n```javascript\nimport intersectRect from './intersect-rect.js';\n\nconst intersection = intersectRect(node, point);\n```\n\n- **Parameters**:\n - `node`: The SVG node element.\n - `point`: The point from which the intersection is calculated.\n\n### 3. `intersectPolygon`\n\nCalculates the intersection points for a polygon.\n\n**Usage**:\n\n```javascript\nimport intersectPolygon from './intersect-polygon.js';\n\nconst intersection = intersectPolygon(node, polyPoints, point);\n```\n\n- **Parameters**:\n - `node`: The SVG node element.\n - `polyPoints`: Array of points defining the polygon.\n - `point`: The point from which the intersection is calculated.\n\n## Cypress Tests\n\nTo ensure the robustness of the flowchart shapes, there are implementation of comprehensive Cypress test cases in `newShapes.spec.ts` file. These tests cover various aspects such as:\n\n- **Shapes**: Testing new shapes like `bowTieRect`, `waveRectangle`, `trapezoidalPentagon`, etc.\n- **Looks**: Verifying shapes under different visual styles (`classic` and `handDrawn`).\n- **Directions**: Ensuring correct rendering in all flow directions of arrows :\n - `TB` `(Top -> Bottom)`\n - `BT` `(Bottom -> Top)`\n - `LR` `(Left -> Right)`\n - `RL` `(Right -> Left)`\n- **Labels**: Testing shapes with different labels, including:\n - No labels\n - Short labels\n - Very long labels\n - Markdown with `htmlLabels:true` and `htmlLabels:false`\n- **Styles**: Applying custom styles to shapes and verifying correct rendering.\n- **Class Definitions**: Using `classDef` to apply custom classes and testing their impact.\n\n### Running the Tests\n\nTo run the Cypress tests, follow these steps:\n\n1. Ensure you have all dependencies installed by running:\n ```bash\n pnpm install\n ```\n2. Start the Cypress test runner:\n\n ```bash\n cypress open --env updateSnapshots=true\n\n ```\n\n3. Select the test suite from the Cypress interface to run all the flowchart shape tests.\n","packages/mermaid/src/docs/community/contributing.md":"# Mermaid Contributing Guide\n\nYou decided to take part in the development? Welcome!\n\nWe are trying to make our guidelines for you as explicit and detailed as possible.\n\n## Initial Setup\n\nInitial setup consists of 3 main steps:\n\n```mermaid-nocode\nflowchart LR\n source --> requirements --> setup\n\n source[Get the Source Code]\n requirements[Install the Requirements]\n setup[Install Packages]\n```\n\n### Get the Source Code\n\nIn GitHub, you first [**fork a mermaid repository**](https://github.com/mermaid-js/mermaid/fork) when you are going to make changes and submit pull requests.\n\nThen you **clone** a copy to your local development machine (e.g. where you code) to make a copy with all the files to work with.\n\n```tip\n[Here is a GitHub document that gives an overview of the process](https://docs.github.com/en/get-started/quickstart/fork-a-repo).\n```\n\n```bash\ngit clone git@github.com/your-fork/mermaid\n```\n\nOnce you have cloned the repository onto your development machine, change into the `mermaid` project folder (the top level directory of the mermaid project repository)\n\n```bash\ncd mermaid\n```\n\n### Install Requirements\n\nWe support **development within Docker** environment along with **host setup**. You may choose it up to your preferences.\n\n**Host**\n\nThese are the tools we use for working with the code and documentation:\n\n- [Node.js](https://nodejs.org/en/).\n- [pnpm](https://pnpm.io/) package manager.\n\nThe following commands must be sufficient enough to start with:\n\n```bash\ncurl -fsSL https://get.pnpm.io/install.sh | sh -\npnpm env use --global 20\n```\n\nYou may also need to reload `.shrc` or `.bashrc` afterwards.\n\n**Docker**\n\n[Install Docker](https://docs.docker.com/engine/install/). And that is pretty much all you need.\n\nOptionally, to run GUI (Cypress) within Docker you will also need an X11 server installed.\nYou might already have it installed, so check this by running:\n\n```bash\necho $DISPLAY\n```\n\nIf the `$DISPLAY` variable is not empty, then an X11 server is running. Otherwise you may need to install one.\n\n### Install Packages\n\n**Host**\n\nInstall packages:\n\n```bash\npnpm install\n```\n\n**Docker**\n\nFor development using Docker there is a self-documented `run` bash script, which provides convenient aliases for `docker compose` commands.\n\nMake sure that `./run` script is executable:\n\n```bash\nchmod +x run\n```\n\n```tip\nTo get detailed help simply type `./run` or `./run help`.\n\nIt also has short _Development quick start guide_ embedded.\n```\n\nThen install packages:\n\n```bash\n./run pnpm install\n```\n\n### Verify Everything Works\n\nThis step is optional, but it helps to make sure that everything in development branch was OK before you started making any changes.\n\nYou can run the `test` script to verify that pnpm is working _and_ that the repository has been cloned correctly:\n\n**Host**\n\n```bash\npnpm test\n```\n\n**Docker**\n\n```bash\n./run pnpm test\n```\n\nThe `test` script and others are in the top-level `package.json` file.\n\nAll tests should run successfully without any errors or failures.\n\n```note\nYou might see _lint_ or _formatting_ warnings. Those are ok during this step.\n```\n\n## Workflow\n\nContributing process is very simple and straightforward:\n\n```mermaid-nocode\n flowchart LR\n\n branch --> changes --> submit\n branch[Checkout a New Branch]\n changes[Make Changes]\n submit[Submit a PR]\n```\n\nMermaid uses a [Git Flow](https://guides.github.com/introduction/flow/)–inspired approach to branching.\n\nDevelopment is done in the `develop` branch.\n\n```mermaid-nocode\n---\nconfig:\n gitGraph:\n mainBranchName: develop\n---\ngitGraph LR:\n commit\n commit\n branch \"docs/2910_update-guidelines\" order: 1\n commit\n commit\n commit\n checkout develop\n merge \"docs/2910_update-guidelines\"\n commit\n```\n\nTo prepare a new version for release the maintainers create a `release/vX.X.X` branch from `develop` for testing. Once the release happens we add a tag to the `release` branch and merge it with `master`. The live product and on-line documentation are what is in the `master` branch.\n\n## Checkout a New Branch\n\n```tip\nAll new work should be based on the `develop` branch.\n```\n\nMake sure you have the most up-to-date version of the `develop` branch.\n\nCheck out the `develop` branch, then `fetch` or `pull` to update it:\n\n```bash\ngit checkout develop\ngit fetch # or `git pull`\n```\n\nCreate a new branch for your work:\n\n```bash\ngit checkout -b docs/2910_update-contributing-guidelines\n```\n\nWe use the following naming convention for branches:\n\n```txt\n[feature | bug | chore | docs]/[issue number]_[short-description]\n```\n\nYou can always check current [configuration of labelling and branch prefixes](https://github.com/mermaid-js/mermaid/blob/develop/.github/pr-labeler.yml)\n\n- The first part is the **type** of change: a `feature`, `bug`, `chore`, `docs`\n- followed by a **slash** (`/`),which helps to group like types together in many git tools\n- followed by the **issue number**, e.g. `2910`\n- followed by an **underscore** (`_`)\n- followed by a **short description** with dashes (`-`) or underscores (`_`) instead of spaces\n\n```mermaid-nocode\nflowchart LR\n feature --> slash\n bug --> slash\n chore --> slash\n docs --> slash\n slash --> 2945 --> underscore\n slash --> 1123 --> underscore\n underscore --> short_description_1\n underscore --> short_description_2\n\n underscore[\"_\"]\n slash[\"/\"]\n\n short_description_1[\"state-diagram-new-arrow-florbs\"]\n short_description_2[\"fix_random_ugly_red_text\"]\n```\n\nIf your work is specific to a single diagram type, it is a good idea to put the diagram type at the start of the description. This will help us keep release notes organized by a diagram type.\n\n```note\nA new feature described in issue 2945 that adds a new arrow type called 'florbs' to state diagrams\n\n`feature/2945_state-diagram-new-arrow-florbs`\n```\n\n```tip\nA bug described in issue 1123 that causes random ugly red text in multiple diagram types\n\n`bug/1123_fix_random_ugly_red_text`\n```\n\n## Contributing Code\n\nCode is the heart of every software project. We strive to make it better. Who if not us?\n\n### Where is the Code Located?\n\nThe core of Mermaid is located under `packages/mermaid/src`.\n\n### Building Mermaid Locally\n\n**Host**\n\n```bash\npnpm run build\n```\n\n**Docker**\n\n```bash\n./run build\n```\n\nThis will build the Mermaid library and the documentation site.\n\n### Running Mermaid Locally\n\n**Host**\n\n```bash\npnpm run dev\n```\n\n**Docker**\n\n```bash\n./run dev\n```\n\nAfter starting the dev server open in your browser.\n\nNow you are ready to make your changes!\n\nNote: By default, the Mermaid service will run on port 9000. To use a different port, change the environment variable `MERMAID_PORT` in the file `.env`. You should only need to do this if you are using port 9000 to run other projects.\n\n### Make Changes\n\nHave a look at . There is a list of demos that can be used to see and test your changes.\n\nIf you need a specific diagram, you can duplicate the `example.html` file in `/demos/dev` and add your own mermaid code to your copy.\n\nThat will be served at .\nAfter making code changes, the dev server will rebuild the mermaid library and automatically reload the page.\n\nEdit files in `packages/mermaid/src` as required.\n\n### Write Tests\n\nTests ensure that each function, module, or part of code does what it says it will do. This is critically important when other changes are made to ensure that existing code is not broken (no regression).\n\nJust as important, the tests act as _specifications:_ they specify what the code does (or should do).\nWhenever someone is new to a section of code, they should be able to read the tests to get a thorough understanding of what it does and why.\n\nIf you are fixing a bug, you should add tests to ensure that your code has actually fixed the bug, to specify/describe what the code is doing, and to ensure the bug doesn't happen again.\n(If there had been a test for the situation, the bug never would have happened in the first place.)\nYou may need to change existing tests if they were inaccurate.\n\nIf you are adding a feature, you will definitely need to add tests. Depending on the size of your feature, you may need to add integration tests.\n\n#### Unit Tests\n\nUnit tests are tests that test a single function or module. They are the easiest to write and the fastest to run.\n\nUnit tests are mandatory for all code except the layout tests. (The layouts are tested with integration tests.)\n\nWe use [Vitest](https://vitest.dev) to run unit tests.\n\n**Host**\n\nYou can use the following command to run the unit tests:\n\n```sh\npnpm test\n```\n\nWhen writing new tests, it's easier to have the tests automatically run as you make changes. You can do this by running the following command:\n\n```sh\npnpm test:watch\n```\n\n**Docker**\n\nWhen using Docker prepend your command with `./run`:\n\n```sh\n./run pnpm test\n```\n\n##### Testing the DOM\n\nOne can use `jsdomIt` to test any part of Mermaid that interacts with the DOM, as long as it is not related to the layout.\n\nThe function `jsdomIt` ([developed in utils.ts](../../tests/util.ts)) overrides `it` from `vitest`, and creates a pseudo-browser environment that works almost like the real deal for the duration of the test. It uses JSDOM to create a DOM, and adds objects `window` and `document` to `global` to mock the browser environment.\n\n> [!NOTE]\n> The layout cannot work in `jsdomIt` tests because JSDOM has no rendering engine, hence the pseudo-browser environment.\n\nExample :\n\n```typescript\nimport { ensureNodeFromSelector, jsdomIt } from './tests/util.js';\n\njsdomIt('should add element \"thing\" in the SVG', ({ svg }) => {\n // Code in this block runs in a pseudo-browser environment\n addThing(svg); // The svg item is the D3 selection of the SVG node\n const svgNode = ensureNodeFromSelector('svg'); // Retrieve the DOM node using the DOM API\n expect(svgNode.querySelector('thing')).not.toBeNull(); // Test the structure of the SVG\n});\n```\n\nThey can be used to test any method that interacts with the DOM, including for testing renderers. For renderers, additional integration testing is necessary to test the layout though.\n\n#### Integration / End-to-End (E2E) Tests\n\nThese test the rendering and visual appearance of the diagrams.\n\nThis ensures that the rendering of that feature in the E2E will be reviewed in the release process going forward. Less chance that it breaks!\n\nTo start working with the E2E tests:\n\n**Host**\n\n- Run `pnpm dev` to start the dev server\n- Start **Cypress** by running `pnpm cypress:open`\n\n**Docker**\n\n- Enable local connections for x11 server `xhost +local:`\n- Run `./run pnpm dev` to start the dev server\n- Start **Cypress** by running `./run pnpm cypress:open --project .`\n\nThe rendering tests are very straightforward to create. There is a function `imgSnapshotTest`, which takes a diagram in text form and the mermaid options, and it renders that diagram in Cypress.\n\nWhen running in CI it will take a snapshot of the rendered diagram and compare it with the snapshot from last build and flag it for review if it differs. When the changes in PR only apply to specific diagrams, only the rendering tests for those diagrams will be run in CI. If a change is not related to a specific diagram, the full test-suite will be run.\n\nThis is what a rendering test looks like:\n\n```js\nit('should render forks and joins', () => {\n imgSnapshotTest(\n `\n stateDiagram\n state fork_state <<fork>>\n [*] --> fork_state\n fork_state --> State2\n fork_state --> State3\n\n state join_state <<join>>\n State2 --> join_state\n State3 --> join_state\n join_state --> State4\n State4 --> [*]\n `,\n { logLevel: 0 }\n );\n});\n```\n\n\n\n\n### Update Documentation\n\n```tip\nOur documentation is managed in `packages/mermaid/src/docs`. Details on how to edit is in the [documentation section](#contributing-documentation)\n```\n\nIf the users have no way to know that things have changed, then you haven't really _fixed_ anything for the users; you've just added to making Mermaid feel broken.\nLikewise, if users don't know that there is a new feature that you've implemented, it will forever remain unknown and unused.\n\nThe documentation has to be updated for users to know that things have been changed and added!\nIf you are adding a new feature, add `(v+)` in the title or description. It will be replaced automatically with the current version number when the release happens.\n\neg: `# Feature Name (v+)`\n\nWe know it can sometimes be hard to code _and_ write user documentation.\n\nCreate another issue specifically for the documentation.\nYou will need to help with the PR, but definitely ask for help if you feel stuck.\nWhen it feels hard to write stuff out, explaining it to someone and having that person ask you clarifying questions can often be 80% of the work!\n\nWhen in doubt, write up and submit what you can. It can be clarified and refined later. (With documentation, something is better than nothing!)\n\n## Contributing Documentation\n\nIf it is not in the documentation, it's like it never happened. Wouldn't that be sad? With all the effort that was put into the feature?\n\n### Where is the Documentation Located?\n\n```warning\nDO NOT CHANGE FILES IN `/docs`\n\nThe `docs` folder will be automatically generated when committing to `packages/mermaid/src/docs` and **should not** be edited manually.\n```\n\nDocumentation is located in the [`packages/mermaid/src/docs`](https://github.com/mermaid-js/mermaid/tree/develop/packages/mermaid/src/docs) folder. Just pick the right section and start typing.\n\nThe contents of [mermaid.js.org](https://mermaid.js.org/) are based on the docs from the `master` branch. Updates committed to the `master` branch are reflected in the [Mermaid Docs](https://mermaid.js.org/) once published.\n\n```mermaid\nflowchart LR\n classDef default fill:#fff,color:black,stroke:black\n\n source[\"Edit /packages/mermaid/src/docs\"] -- automatic processing--> published[\"View /docs which will be published on Official Website\"]\n```\n\n### Running the Documentation Website Locally\n\n**[The mermaid documentation site](https://mermaid.js.org/) is powered by [Vitepress](https://vitepress.vuejs.org/).**\n\nStart development server for the documentation site\n\n**Host**\n\n```bash\npnpm --filter mermaid run docs:dev\n```\n\nor\n\n```bash\ncd packages/mermaid\npnpm docs:dev\n```\n\n**Docker**\n\n```bash\n./run docs:dev\n```\n\nOpen [http://localhost:3333/](http://localhost:3333/) in your browser.\n\n### Formatting\n\nThe documentation is written in Markdown. To get acquainted with its syntax [see the GitHub Markdown help page](https://help.github.com/en/github/writing-on-github/basic-writing-and-formatting-syntax).\n\nYou can use `note`, `tip`, `warning` and `danger` in triple backticks to add a note, tip, warning or danger box.\n\n```danger\nDo not use vitepress specific markdown syntax `::: warning` as it will not be processed correctly.\n```\n\nHere are a few examples:\n\n````markdown\n```note\nThis is a note\n```\n\n```tip\nThis is a tip\n```\n\n```warning\nThis is a warning\n```\n\n```danger\nThis is a danger alert\n```\n````\n\n```note\nThis is a note\n```\n\n```tip\nThis is a tip\n```\n\n```warning\nThis is a warning\n```\n\n```danger\nThis is a danger alert\n```\n\n### Navigation\n\nIf you want to propose changes to how the documentation is _organized_, such as adding a new section or re-arranging or renaming a section, you must update the **sidebar navigation**, which is defined in [the vitepress config](../.vitepress/config.ts). The same goes for **topbar**.\n\n### Build Docs\n\nThe content of `/docs` folder is built with GitHub Actions.\n\n```warning\nSo as to allow automatic compilation of documentation pages you have to enable GitHub Actions on your fork first\n```\n\n## Submit your pull request\n\n````note\nDo not forget to push your changes\n\n```bash\ngit push -u origin docs/2910_update-guidelines\n```\n````\n\nWe make all changes via Pull Requests (PRs). Open a new one.\n\nRight now we are not following any strict rules about naming PRs. Give it a representative title and short description. There is also a [pull request template](https://github.com/mermaid-js/mermaid/blob/develop/.github/pull_request_template.md) which will help you with it.\n\nIn case in its description contains a [magic comment](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) your PR will be automatically attached to the issue:\n\n```markdown\nResolves #\n```\n\n## Congratulations\n\nYou have successfully submitted your improvements! What is next?\n\n- PRs will be reviewed by active maintainers, who will provide feedback and request changes as needed.\n- The maintainers will request a review from _knsv_, if necessary.\n- Once the PR is approved, the maintainers will merge the PR into the `develop` branch.\n- When a release is ready, the `release/x.x.x` branch will be created, extensively tested and knsv will be in charge of the release process.\n\nThanks for you help!\n\n\n","packages/mermaid/src/docs/community/e2e-tests.md":"# E2E Test Suite: Tiers, Folders, and CI\n\nThis is a contributor-facing manual for the `e2e/` test suite's tier structure — why it exists, how it's organized, which flags/labels control it, and how to work with it locally.\n\n## Why this exists\n\nBefore this restructuring, every PR ran the entire e2e suite — every diagram, every theme variant, every look/handdrawn combination — on every push. That's thorough, but it's expensive in two ways that scale badly as the suite grows:\n\n- **CI time.** A full run takes significantly longer than most PRs actually need. Most changes touch one diagram type; waiting on a full 8-shard run to validate a one-line fix is slow feedback for no real benefit.\n- **Argos quota.** Every full run captures and uploads a screenshot for every diagram fixture, whether or not that fixture has anything to do with the change under review. Visual-regression services bill (or rate-limit) by build/screenshot volume, so an oversized \"safety net\" run on every push burns through quota fast.\n\nThe fix is to split fixtures and specs into **tiers** — a small, fast, curated set that runs on every PR by default, and larger, slower sets reserved for less frequent, higher-confidence checks (nightly, and before a release-bound merge).\n\n**Measured impact** (from a real before/after comparison on this fork, on 2026-09-24 — pulled directly from GitHub Actions run history for PR #7; treat this as a dated example, not a live-updating stat):\n\n| | Full suite (pre-tiering) | `pr-check`-tier only |\n| ----------------------------- | ------------------------ | -------------------- |\n| Shards | 8 | 2 |\n| Per-shard time | ~15–18 min | ~6–8 min |\n| Total wall-clock | ~31 min | ~8 min |\n| Total compute (shard-minutes) | ~128 | ~14 |\n\nRoughly a **4x reduction in wall-clock time** and **~90% less total CI compute** for the common case — a PR that only needs the `pr-check` tier to validate its change. That tracks with the underlying fixture split: as of 2026-09-24, `pr-check` covered about 15% of all `.mmd` fixtures (312 of 2,136 — `nightly-check` held 1,375, `visual-check` held 449). These counts will grow over time; the proportions are the durable part.\n\n## Directory layout\n\nTwo parallel trees hold the suite's content:\n\n```mermaid\nflowchart TD\n subgraph diagrams[\"e2e/diagrams//\"]\n direction LR\n d_pr[\"pr-check/
*.mmd fixtures\"]\n d_nightly[\"nightly-check/
*.mmd fixtures\"]\n d_visual[\"visual-check/
*.mmd fixtures\"]\n end\n subgraph rendering[\"e2e/rendering//\"]\n direction LR\n r_pr[\"pr-check/
*.spec.ts\"]\n r_nightly[\"nightly-check/
*.spec.ts\"]\n r_visual[\"visual-check/
*.spec.ts\"]\n end\n runner[\"e2e/rendering/mmd-snapshots.spec.ts
(global fixture runner)\"]\n diagrams -->|discovered & rendered by| runner\n```\n\n- **`e2e/diagrams///*.mmd`** — static Mermaid source fixtures. Each one is just a diagram (optionally with YAML frontmatter setting `config`/`title`/a `description`). They aren't run directly; a single global spec, `e2e/rendering/mmd-snapshots.spec.ts`, discovers every `.mmd` file under `e2e/diagrams/`, registers one Playwright test per fixture (grouped into `describe` blocks mirroring the folder path), and renders it. This is where the large majority of diagram-rendering coverage lives — no test-writing required, just add a `.mmd` file in the right tier folder.\n- **`e2e/rendering///*.spec.{js,ts}`** — hand-written Playwright specs, for anything a static fixture can't express: DOM/CSS assertions, `.click()` interactions, directive-vs-`initialize()` precedence checks, multi-diagram array tests, custom `mermaid.initialize()` config, and similar. If your test needs to assert on rendered output beyond \"did it render without erroring,\" it belongs here instead of as a fixture.\n- **`e2e/other//*.spec.{js,ts}`** — cross-cutting specs that aren't about any single diagram type (XSS/security tests, GHSA regression tests, `iife`/embed tests, page-interaction tests, external-diagram loading). Only `pr-check/` is populated today.\n- **`e2e/helpers/`** — shared test infrastructure: `util.ts` (the `imgSnapshotTest`/`renderGraph`/`verifyScreenshot` helpers every spec uses) and `mmd-snapshots.ts` (fixture discovery/metadata for the global runner).\n\nNot every `//` directory has content yet — some are intentionally empty, left in place as containers for tests that haven't been written. An empty tier folder isn't stray or safe to delete; it's scaffolding for the layout above, matching a diagram type or tier that's expected to gain coverage later.\n\n### The three tiers\n\n| Tier | Intent | Runs on |\n| --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |\n| `pr-check` | Small, curated, fast smoke set — one or two representative fixtures per feature, not an exhaustive sweep. | Every PR (see below), plus a `develop` merge, plus every nightly run. |\n| `nightly-check` | Bulk/comprehensive coverage — most of the fixture volume lives here. | Once every 24h, plus a `master`-bound PR/merge (alongside `pr-check`). |\n| `visual-check` | Theme/look (`classic`/`neo`/`handDrawn`)/layout/direction combinatorial sweeps — the same diagram rendered across every variant. Pixel/appearance content, not parse-only. | Not part of any automated CI gate. Reviewed manually via Applitools as a release-process step (`e2e-applitools.yml`, `workflow_dispatch`-only). |\n\nA fixture or spec's tier is purely a function of which subfolder it lives in — there's no separate registry or config file to update.\n\nIf you're new to this structure, here's how to decide where a new test belongs:\n\n- **Adding a new diagram feature or syntax?** Add one small `pr-check` fixture covering the happy path — this is what every PR runs, so it catches an obvious regression immediately. If the feature has several meaningfully different shapes/variants/edge cases worth covering, add those as additional fixtures under `nightly-check` instead of piling them all into `pr-check` — `pr-check` is meant to stay small and fast, not become exhaustive.\n- **Fixing a rendering bug?** Add a `pr-check` fixture that reproduces the bug (the minimal diagram that triggered it), so this exact regression is caught on every future PR. Only drop it into `nightly-check` instead if it's a narrow, rarely-hit edge case where running it on every PR isn't worth the extra time.\n- **Backfilling broad coverage for something that already works** (e.g. every node-shape × edge-type combination, a sweep of config options)? That bulk volume belongs in `nightly-check` — it's comprehensive by design and only needs to run once a day, not on every push.\n- **Testing a purely visual/appearance difference** — how a diagram looks under a different theme, `handDrawn` look, layout direction, or similar, where the underlying structure/parsing is unaffected? That's `visual-check`. It's pixel/appearance content reviewed by a human via Applitools, not something an automated parse-only assertion can usefully judge.\n- **Does your test need to assert on something beyond \"did it render without erroring\"?** — a DOM/CSS assertion, a `.click()` interaction, directive-vs-`initialize()` precedence, a multi-diagram array, custom `mermaid.initialize()` config — that can't be expressed as a static `.mmd` fixture. Write a hand-written spec instead, under `e2e/rendering///*.spec.{js,ts}` if it's about one specific diagram type, or `e2e/other//*.spec.{js,ts}` if it's cross-cutting (security/XSS, embed/`iife`, page interactions, external-diagram loading, and similar). The same tier logic above still applies to these — a fast smoke-test spec goes in `pr-check`, a more exhaustive one in `nightly-check`.\n\nWhen in doubt, default to `pr-check` for anything a feature's author would want caught immediately, and move broader/slower coverage to `nightly-check`.\n\n## How CI decides what to run\n\n```mermaid\nflowchart TD\n start{\"What triggered this run?\"}\n start -->|\"PR → develop\"| pr_label{\"'run pr tests'
label set?\"}\n start -->|\"PR → master\"| release_label{\"'run release test'
label set?\"}\n start -->|\"Push to develop
(e.g. a PR merge)\"| push_develop[\"pr-check tier only\"]\n start -->|\"Push to master\"| push_master[\"pr-check + nightly-check tiers\"]\n start -->|\"Scheduled (daily) or
manual 'simulated nightly'\"| nightly_run[\"pr-check + nightly-check tiers\"]\n\n pr_label -->|yes, or PR just opened| pr_scoped[\"pr-check tier only\"]\n pr_label -->|no| blocked1[\"e2e skipped —
required check fails\"]\n\n release_label -->|yes, or PR just opened| gated[\"pr-check + nightly-check tiers
(visual-check excluded — see Applitools)\"]\n release_label -->|no| blocked2[\"e2e skipped —
required check fails\"]\n```\n\nBoth labels — `run pr tests` and `run release test` — default to **on**: a small automation job adds them to every freshly-opened PR (targeting `develop` and `master` respectively). Removing the label before a later push causes e2e to be skipped for that push, which is treated as a **failure** of the required status check (not a silent pass) — merging is still possible via a repo admin's branch-protection bypass, but it's not a default-open door.\n\nNote that `run release test` — despite its name — does **not** gate the `visual-check` tier. `visual-check` is theme/look/layout/direction combinatorial sweeps: pixel/appearance content that's better judged by a human during the manual Applitools pass (`e2e-applitools.yml`) than by an automated parse-only check here. The label name is a holdover from before this tier split; renaming it is tracked separately and out of scope for this doc.\n\nThis label-gating logic, and the nightly/scheduled workflow, are **upstream-only** — every branch of this logic is guarded by a check that it's running on `mermaid-js/mermaid`, not a fork. On a fork, e2e.yml falls back to its original full-suite/diff-based-scoping behavior, and the nightly workflow's own job is a no-op (there's no Argos project/credentials there to make screenshot capture worthwhile).\n\n## Flags and environment variables\n\n| Name | Where | Effect |\n| ------------------------------------------- | ----------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `MERMAID_E2E_FIXTURE_TIER` | env var, read by `mmd-snapshots.spec.ts` | Comma-separated tier list (e.g. `pr-check`, or `pr-check,nightly-check`) that narrows which `.mmd` fixtures get registered. Unset = every tier. |\n| `run pr tests` | GitHub PR label | Gates whether a `develop`-bound PR's e2e run happens at all (scoped to `pr-check` tier when present). Defaults on for new PRs. |\n| `run release test` | GitHub PR label | Same, for `master`-bound PRs (scoped to `pr-check`+`nightly-check` — `visual-check` excluded, see above). Defaults on for new PRs. |\n| `E2E_SCOPE_BY_DIAGRAM` | repo variable | Kill-switch for the (separate, older) diagram-diff-based scoping used outside the tier-gating paths. Set to `'false'` to force the full suite unconditionally. |\n| `RUN_VISUAL_TEST` | computed CI env var | Controls whether screenshots get captured for Argos upload. Only ever true on the real upstream repo — never on this fork. |\n| `USE_APPLI` | env var | Switches screenshot verification to Applitools instead of the Argos/local-snapshot path. Common in personal dev shells — remember to override it (`USE_APPLI=`) when you specifically want the Argos code path locally. |\n| `SCREENSHOT_DIR` | env var | Overrides where Argos-mode screenshots get written locally. Defaults to `e2e/screenshots`. |\n| `GROUP_ARGOS_IMAGES` / `group_argos_images` | computed CI env var / `workflow_dispatch` input | Whether screenshots get composited into per-folder \"sheets\" before Argos upload, versus uploaded individually. |\n| `MERMAID_DEV_EXPLORER_ROOT` | env var, read by `.esbuild/server.ts` | Which `.mmd` root the local Dev Explorer (`/dev` route) serves. Defaults to `e2e` (the whole tree — fixtures, platform diagrams, everything). |\n| `MERMAID_PORT` / `MERMAID_DEV_PORT` | env var | Overrides the dev server port Playwright/the dev server use. |\n| `E2E_COVERAGE` | env var | Switches the dev server to the coverage-instrumented build, and enables native V8 coverage collection during a Playwright run. |\n\n## Working with tiers locally\n\n**Run only the `pr-check` tier** (mirrors what a PR's CI actually runs):\n\n```bash\nMERMAID_E2E_FIXTURE_TIER=pr-check pnpm exec playwright test e2e/rendering/mmd-snapshots.spec.ts $(node scripts/e2e-tier-scope.mjs pr-check | tr ',' ' ')\n```\n\n**Run a \"simulated nightly\" (`pr-check`+`nightly-check`)** without waiting for the schedule:\n\n```bash\ngh workflow run \"Nightly E2E\" --repo mermaid-js/mermaid\n# or purely locally, no CI involved:\nMERMAID_E2E_FIXTURE_TIER=pr-check,nightly-check pnpm exec playwright test e2e/rendering/mmd-snapshots.spec.ts $(node scripts/e2e-tier-scope.mjs pr-check nightly-check | tr ',' ' ')\n```\n\n**See what a fixture would look like in Argos**, without needing real Argos credentials or touching any baseline: capture screenshots locally with `RUN_VISUAL_TEST=true` (remembering to clear `USE_APPLI` if it's set in your shell), then either browse `e2e/screenshots/` directly, or run `pnpm run screenshots:sheets` to composite them the same way CI does before upload.\n\n**Run a release test against Applitools**: start the local dev server first (`pnpm dev`, in its own terminal) — the suite is large enough that it's worth having it already warm rather than waiting on Playwright's own `webServer` auto-start/cold build on the first request. Neither of these is something you'd run as part of routine local development — they're only used when preparing a release:\n\n```bash\n# Core release check: pr-check + nightly-check tiers, against the \"release-baseline\" Applitools branch.\npnpm playwright:release-test\n\n# Extended release check: the visual-check tier (theme/look/layout combinatorial sweeps),\n# against its own separate \"release-baseline-extended\" Applitools branch.\npnpm playwright:release-test:extended\n```\n\nBoth scripts set `USE_APPLI=true`, so every screenshot is verified against Applitools instead of the Argos/local-snapshot path, and both pin `APPLITOOLS_BRANCH` to a fixed, long-lived branch name rather than letting the SDK derive one from the current git branch — so re-running either script, from whatever branch you're on, keeps comparing against the same accumulated baseline. The two scripts use separate baseline branches deliberately: the core and extended checks differ enough in scope and cadence that mixing both into one branch would make the Applitools review history harder to read.\n\n## Diagrams and screenshots\n\nThe Dev Explorer (`/dev` route) — browse `.mmd` fixtures under the configured `MERMAID_DEV_EXPLORER_ROOT` and preview them rendered:\n\n![Dev Explorer root view, showing the top-level e2e folder listing](img/dev-explorer.png)\n\n> 📸 **Placeholder — add screenshots here:**\n>\n> - The GitHub PR \"Checks\" tab, side by side: a `develop`-bound PR showing the scoped 2-shard `pr-check`-tier run, versus a `master`-bound PR showing the scoped 4-shard `pr-check`+`nightly-check` run (`visual-check` excluded).\n> - The \"Nightly E2E\" entry in the Actions tab, filtered, showing a recent scheduled run's result.\n\nThe flowcharts above (directory layout, CI decision flow) are Mermaid diagrams — edit them the same way you'd edit any diagram in this repo. If you add more diagrams to this doc, prefer Mermaid over static images where the content is structural/flow-based (it stays accurate as the suite evolves, and — fittingly for this repo — is easy for any contributor to update in a plain-text diff).\n","packages/mermaid/src/docs/community/intro.md":"# Getting Started\n\nSo you want to help? That's great!\n\n![Image of happy people jumping with excitement](https://media.giphy.com/media/BlVnrxJgTGsUw/giphy.gif)\n\nHere are a few things to get you started on the right path.\n\n## How can I help?\n\n```mermaid-nocode\nmindmap\n root)Contributing(\n Development\n Solving issues\n Adding new diagrams\n Handling pull requests\n Updating tooling\n Testing\n Verification of fixed issues\n Regression testing in connection with releases\n Testing pull requests\n Management\n Coordinating the work\n Classification and monitoring of incoming issues\n```\n\n## Join the Development\n\n```tip\n**Check out our** [**detailed contribution guide**](./contributing.md).\n```\n\nWhere to start:\n\n- You could start getting some knowledge of the code base by working on [these \"good first issues\"](https://github.com/mermaid-js/mermaid/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3A%22Good+first+issue%21%22+).\n- You could jump right in and help us fix any of [these bugs](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Type%3A+Bug+%2F+Error%22++label%3A%22Contributor+needed%22+)!\n- You could help write and [improve the documentation](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Area%3A+Documentation%22).\n- You could work on a new feature! [These](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Area%3A+Development%22+label%3A%22Type%3A+Enhancement%22+label%3A%22Status%3A+Approved%22+) are some ideas!\n- You could confirm the bugs in [these issues](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Status%3A+Triage%22++label%3A%22Type%3A+Bug+%2F+Error%22).\n\n[You can join our Discord server if you want closer contact!](https://discord.gg/sKeNQX4Wtj)\n\n## A Question Or a Suggestion?\n\n```tip\n**Have a look at** [**how to open an issue**](./questions-and-suggestions.md).\n```\n\nIf you have faced a vulnerability [report it to us](./security.md).\n\n## Last Words\n\nDon't get daunted if it is hard in the beginning. We have a great community with only encouraging words. So, if you get stuck, ask for help and hints in the Slack forum. If you want to show off something good, show it off there.\n\n[You can join our Discord server if you want closer contact!](https://discord.gg/sKeNQX4Wtj)\n\n![Image of superhero wishing you good luck](https://media.giphy.com/media/l49JHz7kJvl6MCj3G/giphy.gif)\n","packages/mermaid/src/docs/community/layout-makers-guide.md":"# The Layout Maker's Guide 🗺️\n\nA layout algorithm decides where nodes sit and how edges get from one to the next. Shapes, themes, markers, and labels are already handled by the shared rendering code.\n\nWhich means you never touch the DOM. You are handed a graph whose nodes already know how big they are, and you hand back numbers: a center point for every node, a list of points for every edge. Drawing the shapes, painting the strokes, placing the arrowheads, fitting the viewBox — all of that is somebody else's code working from your numbers. You are solving a geometry problem, not a rendering one, which is exactly why a layout can be tested without a browser.\n\nThis guide covers layouts that live inside the Mermaid package, next to `dagre` and the others. The last section explains how to ship the same code as a standalone npm package instead.\n\nTwo layouts in the tree are worth reading alongside it. `dagre` is the default and the oldest. `swimlanes` is the newest, and it is the one that follows the conventions described here, so most of the examples point at it.\n\n## What a layout receives and what it must produce\n\nEvery layout is handed the same structure, `LayoutData`, regardless of which diagram type produced it:\n\n```ts\ninterface LayoutData {\n nodes: Node[];\n edges: Edge[];\n config: MermaidConfig;\n diagramId?: string;\n}\n```\n\n`runLayoutCore`, the stage that holds your algorithm, writes these fields and no others:\n\n| Field | On | Meaning |\n| --------------------------- | ---- | -------------------------------------------------------------------------- |\n| `node.x`, `node.y` | Node | Center of the node, in layout space |\n| `node.width`, `node.height` | Node | Arrive measured for leaf nodes — leave those alone; you set them on groups |\n| `edge.points` | Edge | Polyline from source boundary to target boundary, at least 2 points |\n| `edge.x`, `edge.y` | Edge | Anchor for the edge label, when the edge has one |\n\nOne stage is allowed to do more. `prepareLayout` runs before measurement and may rebuild the graph — replace `data4Layout.nodes` and `data4Layout.edges`, add the synthetic nodes an edge label needs, drop what your algorithm handles another way. \"These fields and no others\" is a rule about `runLayoutCore`, where the graph is settled and only geometry moves.\n\n### Layout space\n\nPositions are centers. `node.x, node.y` is the middle of the node's box, so its left edge is `x - width / 2` and its top edge is `y - height / 2`. Layout libraries disagree about this — some report a node's top-left corner, some measure y upward from a bottom-left origin — so if you are wrapping one, convert its output in `runLayoutCore` rather than leaving the renderer to guess. Dagre and ELK both report centers, which is why the built-in layouts pass them straight through.\n\nBeyond that, layout space is a plain plane: x grows to the right, y grows downward. There is no fixed origin and no requirement that coordinates be positive. The renderer takes the bounding box of everything you produced and translates it into the SVG viewBox, so a layout centered on (0, 0) and a layout starting at (0, 0) render identically. Do not spend a pass normalizing coordinates; it is undone immediately.\n\n`Node` and `Edge` carry a good deal more than this, all of it defined in `rendering-util/types.ts`. Read the types there rather than working from what a debugger happens to show you: shape, label geometry, styling, and port information all travel on the same objects, and most of it belongs to the renderer rather than to you.\n\nTwo structural fields are your input, not your output. `node.isGroup` marks a subgraph container, and `node.parentId` names the group a node belongs to. Read them, never rewrite them.\n\nLeaf sizes arrive already measured, and they are not yours to compute. The renderer inserts every leaf node into the SVG, calls `getBBox()`, and writes `width` and `height` back before your algorithm runs, so a leaf whose size you recalculate or overwrite will have its label spill out of its shape at render time. Read them; treat them as fixed.\n\nGroups are the exception, and the only place you do set a size. A group's extent is a consequence of where you put its children, so nothing can measure it up front — every node with `isGroup` set needs a `width` and `height` from you, big enough to enclose its members and the title band. See [Groups](#groups).\n\nThat one measuring pass is the only step in the whole pipeline that touches the DOM, which is what makes everything after it testable in Node.\n\n## The five stages\n\nLayouts are built by calling `createCommonLayoutRenderer` from `rendering-util/layout-algorithms/common/index.ts`. It gives you five hooks, runs them in order, and handles painting:\n\n```ts\nexport const render = createCommonLayoutRenderer({\n prepareLayout, // reshape LayoutData before measuring\n measureLayout, // DOM: insert elements, read sizes (has a default)\n runLayoutCore, // your algorithm, no DOM allowed\n paintLayout, // escape hatch: take over painting entirely\n afterPaint, // touch up after paths exist\n paintOptions, // tweak the standard painter\n});\n```\n\nOnly `runLayoutCore` is required. The swimlanes layout is a complete example in twenty lines:\n\n```ts\nimport { createCommonLayoutRenderer } from '../common/index.js';\nimport { applySwimlaneLineJumps } from './adjustLayout.js';\nimport { prepareLayoutForSwimlanes } from './helpers.js';\nimport { createEdgeLabelNodes } from './edgeLabelNodes.js';\nimport { runSwimlaneLayoutCore } from './layoutCore.js';\n\nfunction prepareSwimlaneLayout(data4Layout: LayoutData): void {\n prepareLayoutForSwimlanes(data4Layout);\n\n const transformedData = createEdgeLabelNodes(data4Layout);\n data4Layout.nodes = transformedData.nodes;\n data4Layout.edges = transformedData.edges;\n}\n\nexport const render = createCommonLayoutRenderer({\n prepareLayout: prepareSwimlaneLayout,\n runLayoutCore: runSwimlaneLayoutCore,\n afterPaint: applySwimlaneLineJumps,\n});\n```\n\n### Keep the core free of the DOM\n\n`runLayoutCore` must be a pure function of `LayoutData`. No `document`, no `getBBox`, no d3 selections.\n\nThe reason is testing. Node sizes get measured in a browser once and saved to a file. A test then loads those sizes, hands them to `runLayoutCore`, and gets back the same coordinates the browser would have produced, without opening a browser at all. That only holds while the core stays free of the DOM. The moment it reaches for `document`, it can only run inside a real page, and any test around it is exercising a different code path than the one your users hit.\n\nSo write the core as one exported function, and have both the browser and your tests call that same function.\n\n## A minimal layout\n\nThe examples from here on build a layout called `grid`. No such layout ships with Mermaid. It stands in for whatever you are writing, and the code below is what you would write to create it.\n\nPut the algorithm in `packages/mermaid/src/rendering-util/layout-algorithms//`. This one arranges leaf nodes in a grid and connects them with straight lines:\n\n```ts\n// layout-algorithms/grid/layoutCore.ts\nimport type { LayoutData } from '../../types.js';\n\nconst GAP = 60;\n\n/** DOM-free: positions come from measured sizes only. */\nexport function runGridLayoutCore(data4Layout: LayoutData): void {\n const leaves = data4Layout.nodes.filter((node) => !node.isGroup);\n const columns = Math.ceil(Math.sqrt(leaves.length));\n const cell = Math.max(...leaves.map((n) => Math.max(n.width ?? 0, n.height ?? 0))) + GAP;\n\n leaves.forEach((node, i) => {\n node.x = (i % columns) * cell;\n node.y = Math.floor(i / columns) * cell;\n });\n\n const byId = new Map(data4Layout.nodes.map((node) => [node.id, node]));\n for (const edge of data4Layout.edges) {\n const from = byId.get(edge.start ?? '');\n const to = byId.get(edge.end ?? '');\n if (!from || !to) {\n continue;\n }\n edge.points = [\n { x: from.x ?? 0, y: from.y ?? 0 },\n { x: to.x ?? 0, y: to.y ?? 0 },\n ];\n }\n}\n```\n\n```ts\n// layout-algorithms/grid/index.ts\nimport { createCommonLayoutRenderer } from '../common/index.js';\nimport { runGridLayoutCore } from './layoutCore.js';\n\nexport const render = createCommonLayoutRenderer({ runLayoutCore: runGridLayoutCore });\n```\n\nThat renders. It is also wrong in most of the ways a layout can be wrong.\n\n## Registering the layout\n\nThe layouts that ship with Mermaid are listed in `registerDefaultLayoutLoaders()` in `packages/mermaid/src/rendering-util/render.ts`. Add one entry for yours:\n\n```ts\nregisterLayoutLoaders([\n { name: 'dagre', loader: async () => await import('./layout-algorithms/dagre/index.js') },\n { name: 'swimlane', loader: async () => await import('./layout-algorithms/swimlanes/index.js') },\n // your new layout\n { name: 'grid', loader: async () => await import('./layout-algorithms/grid/index.js') },\n]);\n```\n\nThe loader is lazy, so the code only downloads when a diagram asks for it. `cose-bilkent` is registered the same way but wrapped in a check on `includeLargeFeatures`, which is how a layout stays out of the tiny build. Users then select the layout by the name you registered:\n\n```text\n---\nconfig:\n layout: grid\n---\nflowchart TB\n A --> B\n```\n\n## Groups, labels, and edges\n\n### Groups\n\nA group node carries `isGroup: true`, and its members carry `parentId` pointing at it. Groups nest. Your algorithm owns the group's `x`, `y`, `width`, and `height`, and the frame must enclose every descendant with room for the title. Groups also have an optional `groupTitleRect` describing the header band. Edges routed through that band collide with the title text.\n\nThe standard painter draws a group as a cluster and everything else as a node. Override that with `paintOptions.isCluster` when your layout has its own idea of which nodes are containers.\n\n### Edge labels\n\nLabels need space reserved before positions are decided, otherwise they land on top of edges and nodes. The approach that works is to split each labelled edge into `start → label → end` around a temporary node, let the algorithm place that node like any other, then fold it back into an overlay label. Swimlanes does this in `createEdgeLabelNodes`, called from its `prepareLayout` hook so the dummy node is measured as real text along with everything else.\n\nInvent a third mechanism and your labels will not be checked by the validator, because the validator reads the label geometry this pattern produces.\n\n### Edge endpoints and markers\n\nEdge paths must start and end on the boundary of their nodes, not at the center and not floating in space. By default the painter recomputes the endpoint by intersecting the path with the node shape, which will quietly bend the last segment of a carefully routed edge. Layouts that route to exact ports should turn that off with `paintOptions.skipIntersect`.\n\nArrowheads occupy roughly the last ten pixels of the final segment. A bend inside that stretch puts a corner underneath the arrowhead, and the validator calls it: the constant is `EPS_FINAL_APPROACH`, and it is 10.\n\n### Self-loops and parallel edges\n\nAn edge with `start === end` has no direction to follow and needs its own route, usually a small rectangle off one side of the node. Parallel edges between the same pair need to be separated by hand, or they render as one line. Fixtures for both live in `e2e/platform/dev-diagrams/layout-tests/` as `self-loop.mmd`, `self-loop-2.mmd`, `self-loop-multi.mmd`, and `identical-edges.mmd`.\n\n## Validating the result\n\n`validateLayout` in `layout-algorithms/layout-utils/validateLayout.ts` is the shared judge of layout quality. It takes finished `LayoutData` and returns a verdict plus a score:\n\n```ts\nimport { validateLayout } from '../layout-utils/validateLayout.js';\n\nconst result = validateLayout(layout);\n// result.ok → boolean, false when any hard constraint is broken\n// result.issues → what broke, with node/edge ids and details\n// result.score → 0 to 1000; exactly 0 whenever ok is false\n// result.breakdown → crossings, per-edge bend penalties, point histogram\n```\n\n### Hard constraints\n\n`ok` is false if any issue is present, and the score drops to zero. These are the failures worth knowing about before you write your router:\n\n| Issue | What it means |\n| --------------------------------------------------------------- | ----------------------------------------------------- |\n| `node-overlap` | Two nodes occupy the same space |\n| `edge-intersects-node`, `edge-intersects-obstacle` | A path crosses a node it does not connect to |\n| `edge-intersects-group-title` | A path runs through a subgraph's title band |\n| `edge-endpoint-detached-from-node`, `edge-endpoint-inside-node` | An endpoint misses the boundary |\n| `edge-non-orthogonal` | A segment is neither horizontal nor vertical |\n| `edge-missing-points` | Fewer than two points on an edge |\n| `edge-shared-subpath`, `edge-parallel-segment-too-close` | Two edges overlap or run too close to tell apart |\n| `edge-shared-attachment-point`, `edge-same-port-departure` | Two edges leave a node from the same spot |\n| `edge-bend-near-endpoint`, `edge-bend-overlaps-arrowhead` | A corner sits under the arrowhead or against the node |\n| `edge-border-hugging`, `node-border-hugging` | Geometry runs along a border instead of clear of it |\n| `edge-label-overlaps-node`, `edge-label-overlaps-foreign-edge` | A label lands on top of something else |\n| `edge-label-off-edge` | A label sits away from the edge it belongs to |\n\nThe tolerances are named constants at the top of `validateLayout.ts`, and two of them explain most first-time surprises: `EPS_FINAL_APPROACH` is 10, the stretch near an endpoint where a bend is not allowed, and `EPS_SHARED_ATTACH` is 3, how close two edges may attach to the same node before they count as sharing a point. The tests assert relative ordering rather than exact magnitudes, so treat the numbers as current rather than fixed.\n\nSome checks assume orthogonal routing. A layout with curved or diagonal edges will trip `edge-non-orthogonal` on every edge, so either route orthogonally or work out which subset of the validator applies to you before treating its score as a target.\n\n### The score\n\nWhen `ok` is true the score starts at 1000 and comes down. Bends are counted per edge from the polyline point count, and crossings are counted once globally:\n\n| Polyline points | Bends | Penalty |\n| --------------- | ----- | ------------------- |\n| 2 | 0 | 0 |\n| 3 | 1 | 0 |\n| 4 | 2 | 5 |\n| 5 | 3 | 12 |\n| 6 | 4 | 30 |\n| 7 or more | 5+ | 30 × 2^(points − 6) |\n\nEach crossing costs 3. The curve is deliberately steep at the top end: one seven-bend edge costs more than twenty crossings, because a path nobody can follow is worse than a tidy diagram with intersections.\n\nThe score does not scale with diagram size. A small graph reaches 1000; a large one rarely will, so compare a fixture against its own history rather than against another fixture.\n\n`result.breakdown.edges` is sorted worst-first, which makes it the fastest way to find what is dragging a layout down.\n\n### One thing that looks useful and is not\n\n`layout-utils` also holds `scoreLayout`, which computes softer metrics: aspect ratio, average bends per edge, rank faithfulness, neighborhood preservation, straight-edge ratio. Sitting next to `validateLayout`, it looks like the quality half of a matched pair.\n\nIt is not wired into anything. Nothing in the layout pipeline calls it, no fixture spec calls it, and its only caller is its own unit test. Its `symmetryScore` is an unfinished placeholder that always returns `NaN`. Treat `validateLayout` as the only judge, and leave `scoreLayout` alone unless you are deliberately picking up that unfinished work.\n\nA third level is planned and not built. `compareLayoutSnapshot()` would diff a layout's structure against a stored baseline to catch regressions that stay inside the validator's tolerances. There is no such function today, so nothing depends on it.\n\n## Testing with DDLT\n\nDOM-Decoupled Layout Testing runs your algorithm in Node against sizes captured once from a real browser. Tests come back in seconds and give the same answer every time, and because the browser and the tests call the same core function, a fix in one is a fix in the other.\n\n### Tests must run the browser's code path\n\nThe model is `parse → measure → run layout → paint`, and the third step has to be a single function. Tests swap out the measuring; the browser does it for real. What runs in between must be identical.\n\nThat sounds obvious, and it is where this gets broken most often. A test-only layout entry point sitting alongside the browser's is a bug even when the two look like they do the same thing. This has bitten this repo more than once, and the shape is always the same. The browser entry wrapped the edge pipeline in a degeneracy check and a direction-violation check, with a fallback and a reroute branch hanging off them. The test backend called the pipeline directly and skipped all of that. Fixtures came back valid, the browser took the fallback, and the fallback drew a polyline straight through the interior of a node. The validator would have caught it. The test harness never saw it.\n\nSo when you wire up a test backend, find the function the browser actually calls and trace it end to end. If it needs the DOM, lift its DOM-free body into a helper and call that helper from both sides rather than reimplementing the sequence. Never point the test at a primitive that the browser wraps in checks, fallbacks, mirror branches, or second passes: the test has to include all of it.\n\nThere is a cheap way to prove the seam is real. Change the browser orchestration, add a fallback or switch a default, and the test result for the same fixture should move. If it does not, the test is running around your change. Fix the seam rather than relaxing the test.\n\nWhen a fixture passes in Node but looks broken on screen, run `validateLayout` on both, on the same fixture, and compare the issues. Different issues mean different pipelines. Put the two call chains side by side, look for pre-passes, the main call, and post-passes, and the first place they diverge is the seam.\n\n### Fixtures\n\nA fixture is a pair of files under `e2e/platform/dev-diagrams/layout-tests/`:\n\n```text\nlayout-tests/\n simple-graph.mmd ← real Mermaid source, parsed by the real parser\n simple-graph.sizes.json ← node dimensions captured from a browser render\n ddlt-manifest.json ← per-fixture overrides\n```\n\nThe `.mmd` file goes through the actual parser, so fixtures exercise the same `LayoutData` a user's diagram produces. The `.sizes.json` file holds one entry per leaf node and one per edge label, plus freshness metadata:\n\n```json\n{\n \"metadata\": {\n \"captureVersion\": 1,\n \"sourceSha256\": \"…\",\n \"capturedAt\": \"2026-02-09T10:00:00Z\",\n \"capturedFrom\": \"theme=default&look=classic\"\n },\n \"nodes\": [{ \"id\": \"A\", \"width\": 62, \"height\": 39 }]\n}\n```\n\n`sourceSha256` is a hash of the `.mmd` file. Edit the diagram without recapturing and the test fails with a stale-fixture error instead of silently laying out with wrong sizes.\n\n`ddlt-manifest.json` gives a fixture a profile, which decides the backend it runs through, and can mark it `allowLevel1Failure` when a known failure is tracked in its own dedicated spec.\n\n### Capturing sizes\n\nThere is a button for this. Start the dev server with `pnpm dev`, open the explorer at `/dev/`, and pick your diagram out of the file tree, which is rooted at the same `dev-diagrams` folder the fixtures live in. Switch to the Code tab and click **Save sizes**, sitting next to Save.\n\nIt does the whole job. Unsaved edits to the diagram are written first, the diagram re-renders with size capture switched on, and the measurements go to `.sizes.json` beside the `.mmd`. The hash and the capture version are filled in for you, so the fixture passes the freshness check the moment it lands.\n\nThe button is only enabled for layouts that can produce capture data, and it explains itself through a tooltip when it is greyed out.\n\nIf you need to capture from somewhere other than the explorer, the same machinery is reachable from the console:\n\n```js\nwindow.mermaidCaptureSizes = true;\n// render the diagram, then:\ncopy(JSON.stringify(window.mermaidLastCapturedSizes.sizes, null, 2));\n```\n\nWritten by hand this way, the metadata block is yours to fill in. The capture module is dynamically imported only when that flag is set, so it never reaches a production bundle either way.\n\nRecapture when the diagram source changes or when a shape's real dimensions change. Do not recapture to make a failing test pass. The fixture is the before-picture, and rewriting it erases the regression you were trying to catch.\n\n### Parse the diagram, do not hand-build the graph\n\nIt is tempting to skip the parser and write the `LayoutData` for a test by hand. Resist it. Hand-built graphs drift from what the parser emits, usually in the identifiers, and once the ids differ the test is scoring a graph the browser never lays out.\n\nThe ids follow rules worth knowing, because fixture entries are matched against them:\n\n| Entity | Id |\n| ----------------- | ------------------------------------------------------------------ |\n| Content node | The unquoted name from the diagram source, such as `A` or `E` |\n| Unquoted subgraph | The subgraph text, kept as written |\n| Quoted subgraph | `subGraph`, numbered by a counter that ticks on every subgraph |\n| Edge | `L___`, the counter separating parallel edges |\n| Edge label node | `edge-label---` |\n\nThe harness does the parsing for you. `parseMmdFileToLayoutData` strips frontmatter and directives, runs the real detector and parser, and stamps the direction the way the flowchart renderer does. `parseApplySizesAndLayout` goes further and applies the captured sizes and runs a backend. Reach for those before writing your own.\n\nIf you do drive the parser yourself, two calls come first: `addDiagrams()` to register the diagram types, and `preprocessDiagram()` to handle frontmatter before `Diagram.fromText()` sees it. Skipping either produces failures that look like parser bugs and are not.\n\nWhichever route you take, fail loudly when a fixture entry has no matching parser-produced node. A silent miss leaves a node at its default size, and the layout you then measure is not the layout anyone will see.\n\n### Writing a spec\n\nLoad the fixture, run your backend, assert on the result:\n\n```ts\nimport { describe, it, expect, beforeAll } from 'vitest';\nimport { loadDdltFixture } from '../ddlt/index.js';\nimport { validateLayout } from '../layout-utils/validateLayout.js';\n\ndescribe('swimlanes, 1-simple', () => {\n let layout: LayoutData;\n beforeAll(async () => {\n layout = await loadDdltFixture('swimlanes/1-simple', { backendId: 'swimlanes' });\n });\n\n it('produces a valid layout', () => {\n const result = validateLayout(layout);\n expect(result.issues.map((i) => i.type)).toEqual([]);\n expect(result.score).toBeGreaterThan(900);\n });\n});\n```\n\nPass `backendId` explicitly. The default is a backend that is not present on `develop`, so a call without it throws rather than silently doing something reasonable. Your own layout needs an entry in `ddlt/backends.ts` before a fixture can run through it.\n\n`ddlt/index.ts` also exports `baselineDdltSpec(name)`, a one-liner that asserts the universal invariants: finite coordinates, at least two points per edge, no segment through an unrelated node, endpoints on boundaries. It hardcodes the same absent default backend and has no callers, so read it for the invariants it checks rather than calling it as it stands.\n\nThree shapes of test cover most needs. A tiny inline geometry test, where you build a handful of nodes by hand and check one routing rule, is right for a unit of the algorithm. A fixture-backed test on realistic sizes is right for a regression you can point at. A full source-to-layout run through the parser is right for anything a user reported. Match the surrounding folder: `swimlanes/query-process.ddlt.spec.ts` is the fullest worked example in the tree, and `layout-utils/validateLayout.spec.ts` and `ddlt/aggregateValidate.spec.ts` show the smaller shapes.\n\n### The sweep\n\n`ddlt/layout-fixtures.ddlt.spec.ts` discovers fixture pairs, runs them, and asserts validity across the board. It also emits an aggregate report, the number that tells you whether a change helped overall rather than on the one diagram you were staring at:\n\n```bash\n# The sweep, with the aggregate report\npnpm exec vitest run \\\n packages/mermaid/src/rendering-util/layout-algorithms/ddlt/layout-fixtures.ddlt.spec.ts\n\n# Just the aggregate line\npnpm exec vitest run \\\n packages/mermaid/src/rendering-util/layout-algorithms/ddlt/layout-fixtures.ddlt.spec.ts \\\n 2>&1 | grep 'DDLT-AGG'\n\n# One fixture while iterating\npnpm exec vitest run -t \"1-simple\" \\\n packages/mermaid/src/rendering-util/layout-algorithms/ddlt/\n```\n\nThe report gives `total`, `avg`, `min`, and `invalid`, then one row per fixture with its score and issue types. Read it as a work queue: the lowest row is where the next improvement is. `ORTHO_TEST_DEBUG=1` in front of the command turns the layout logger from `fatal` up to `debug`, which helps when a row fails for reasons the report does not explain.\n\nThe sweep as written filters to the `swimlanes` profile and holds that profile's total against a floor. Adding a layout means adding its profile to the manifest and its own aggregate assertion, not assuming the existing one will pick your fixtures up.\n\n## The cases that break layouts\n\nA layout that handles a chain of boxes tells you almost nothing. The cases below are where engines actually fail, roughly in the order yours will fail them. Every one has a diagram in `layout-tests` already, so there is nothing to write before you can find out.\n\nMost of them are source only. The folder holds around 45 diagrams and about 15 have captured sizes, and the sweep discovers fixtures by looking for `.sizes.json` files and pairing each with its sibling `.mmd`. A diagram with no sizes file is not being tested by anything, however tricky it looks. Check before assuming a case is covered, and if the sizes are missing, open the diagram in the explorer and press Save sizes. That one click is the difference between a diagram sitting in a folder and a case the sweep will defend.\n\n### Self-loops\n\nAn edge whose source and target are the same node has no direction to travel in, and code that computes a route from two distinct positions tends to produce a zero-length path, a division by zero, or a dot. The route has to be manufactured: a small loop off one side, clear of the node and of anything the node's other edges are doing.\n\n`self-loop.mmd` is the single-node case, and the only one of the three with sizes captured. `self-loop-2.mmd` and `self-loop-multi.mmd` are harsher, putting a self-loop on all four nodes of a cycle, so every loop competes for space with real edges already using those sides.\n\n### Subgraphs\n\nThis is the long tail, and it is where most of the work is. A subgraph is a node that contains other nodes, so every edge endpoint now has two possible meanings and every frame is an obstacle that also has to move as its contents move.\n\n| Case | Fixture |\n| ------------------------------------- | --------------------------------------------------------- |\n| A subgraph standing on its own | `decoupled-subgraph.mmd` |\n| Edge into a subgraph | `edge-to-subgraph.mmd` |\n| Edge into a node inside a subgraph | `edge-to-node-in-subgraph.mmd` |\n| Edge out of a subgraph | `edge-from-subgraph.mmd` |\n| Edge from inside out to a plain node | `subgraph-variation.mmd`, `subgraph-variation-2.mmd` |\n| Between two sibling subgraphs | `nested-sg-outgoing-2.mmd`, `nested-incoming.mmd` |\n| Inside one subgraph to inside another | `nested-sg-outgoing-2.mmd`, `nested-subgraphs-2.mmd` |\n| Nested subgraphs | `nested-subgraphs.mmd`, `nested-subgraphs-3.mmd` |\n| Edges crossing several nesting levels | `nested-sb-edges-in-out.mmd`, `nested-outgoing-edges.mmd` |\n| Subgraph titles competing for space | `subgraph-labels.mmd` and its two variants |\n\nWork down that list in order. Each row assumes the ones above it. Only the first two rows have captured sizes today, so everything below them is a diagram you can open in the browser rather than a test that will tell you when you break it.\n\nTwo failures recur. An edge that ends on a subgraph should stop at the frame rather than diving through to a member, and an edge that ends on a member has to cross the frame without clipping the title band. The other is sizing: a frame has to enclose everything inside it including the labels, and it has to keep doing so after a later pass nudges a member.\n\n### Parallel edges\n\nTwo edges between the same pair of nodes are one edge as far as most routing code is concerned, because both get the same endpoints and the same optimal path, so they land exactly on top of each other and the diagram silently loses information. They have to be separated deliberately.\n\n`identical-edges.mmd` is the minimal case. `multiple-edges.mmd` adds a reverse edge to the bundle, so the fix cannot just fan edges out by index and ignore direction. `identical-edges-in-subgraph.mmd` puts a bundle in each direction inside a frame, where the room to fan out is bounded.\n\n### Busy nodes\n\nA node with more than four edges cannot give each one its own side. Ports have to share sides, share sides in an order that does not cross, and stay far enough apart to be told apart. Engines that assign one edge per side degrade sharply here, usually into a knot right against the node.\n\n`edge-types.mmd` piles several edges onto a single node with a different arrow type on each. `Company.mmd` and `Company-simp.mmd` are the realistic version of the same problem, and both have sizes captured.\n\n### Combinations, and both directions\n\nThese interact, and the combinations are worse than the parts. A self-loop on a busy node inside a nested subgraph exercises all four at once, which is why the larger fixtures are worth keeping even though a failure in one is harder to diagnose. `deploy-pipeline.mmd`, `life-choices.mmd`, and `project-sox2.mmd` are the closest thing here to diagrams a user would actually write.\n\nRun the ones that matter in `TB` and `LR` both. Layout code tends to grow an implicit assumption about which way the graph flows, and the second direction is where that assumption surfaces.\n\n## Before you invent something\n\nGraph drawing has a long research record, and most of what a layout engine needs has been studied for decades. Orthogonal routing, compaction, port and side constraints, layered pipelines, crossing minimisation: none of these are new problems, and reading up on one is usually faster than deriving a heuristic and discovering its failure modes one fixture at a time.\n\nThe vocabulary gap is worth knowing about, because it makes searching harder than it needs to be. What this codebase calls a jog, the literature calls a bend. A port window is a pin or a side constraint. A rail is a track or a channel. A group is a compound vertex.\n\nWhen you knowingly diverge from what the established approach recommends, write down why in the pull request, along with how you checked that the divergence works.\n\n## Watching it in the browser while the tests run\n\nThe sweep tells you a score dropped. It does not tell you the diagram now looks like a plate of spaghetti. Keep a browser open next to the test run.\n\n```bash\npnpm dev\n```\n\nDo not assume the address. The port is derived from the path of the checkout, so every worktree and every clone gets its own and you can run several dev servers side by side without them fighting over 9000. The server prints its URL as it starts, before the build output scrolls past. `MERMAID_DEV_PORT` pins it if you want a fixed one.\n\nOpen `/dev/` and you get the explorer: the fixture tree on one side, the diagram on the other, a code tab for editing the source, and a layout picker for comparing your algorithm against the others on the same input. It reloads when you change the source, so an edit to your algorithm redraws the diagram without you touching the browser.\n\nFor a diagram that is not in the fixture tree, copy the standalone page template instead:\n\n```bash\ncp demos/dev/example.html demos/dev/grid.html\n```\n\nThat lands at `/dev/grid.html` on the same server. Put the diagram in the page and name your layout in the frontmatter:\n\n```html\n
\n---\nconfig:\n  layout: grid\n---\nflowchart TB\n  A --> B\n  B --> C\n
\n```\n\nA workflow that holds up over a long session:\n\n1. Run the sweep in one terminal, filtered to the fixture you are working on.\n2. Keep that same fixture open in the browser.\n3. Make one change and watch both. The score says whether it helped, and the picture says whether the score was measuring the right thing.\n4. Before committing, run the full sweep and confirm the aggregate did not drop.\n\nThe two disagree more often than you would expect, and the disagreement is informative. A score that improves while the diagram gets worse means the validator is blind to something, and that gap is worth writing down.\n\nUse the browser to check what the tests cannot see: text that overflows its shape, arrowheads pointing the wrong way, subgraph frames cutting through labels.\n\n## Performance on large diagrams\n\nA layout that is pleasant on ten nodes can be unusable on a thousand, and the difference does not show up in the fixture sweep — DDLT fixtures are small on purpose, so they say nothing about how your algorithm scales. There is a separate corpus for that.\n\n### The corpus\n\n`e2e/platform/dev-diagrams/performance/flowcharts/` holds fifteen real flowcharts, anonymized and grouped by size:\n\n```text\nperformance/flowcharts/\n medium1.mmd … medium5.mmd ← ~45-50 KB of source each\n large1.mmd … large5.mmd ← ~70-75 KB\n huge1.mmd … huge5.mmd ← 120-240 KB\n baseline.json ← a captured profiler run, for comparison\n```\n\nThe buckets are by source size, and node count does not follow it. `huge1.mmd` is around 2400 nodes with barely fifty edges; `huge2.mmd` is a few hundred nodes with over a thousand edges; `huge3.mmd` is a hundred nodes buried in `classDef` declarations. That spread is deliberate. These are real diagrams people drew, so the shapes that break layout algorithms in practice — one node with sixty edges, deeply nested subgraphs, a long thin chain, a wide flat fan — appear in the proportions they actually occur rather than the ones a generator would produce. Several carry frontmatter config, `handDrawn` look, and HTML labels, so they exercise the measuring pass as well as the layout.\n\n### Running the profiler\n\nProfiling lives in the same dev explorer as everything else in the previous section.\n\n1. `pnpm dev`, then open `/dev/` at the URL the server printed.\n2. Select `performance/flowcharts` in the file tree.\n3. In the Profiler panel, tick the layouts to compare, set the scope to **Folder**, choose the number of iterations, and press **Run profile**.\n\nEach layout is warmed up once and discarded, then every diagram is rendered `iterations` times per layout, with the fastest and slowest run of each series dropped before averaging. The score is total milliseconds across the set, lower is better. **Copy JSON** puts the whole run on the clipboard in the same shape as `baseline.json`.\n\nOne rough edge: the profiler's layout checkboxes come from a hardcoded list in `.esbuild/dev-explorer/diagram-viewer.ts` (`ALL_LAYOUTS`). A new layout will not appear there until you add it, even after it is registered with Mermaid.\n\n### Reading the table\n\nThe row you care about is rarely the total. Rendering is broken into phases, and only one of them is yours:\n\n| Phase | What it covers |\n| ----------- | ----------------------------------------------------------- |\n| `parse` | Diagram text to db |\n| `prepare` | Building `LayoutData`, including your `prepareLayout` |\n| `measure` | DOM insertion and `getBBox` / `getBoundingClientRect` |\n| `layout` | The layout call, split into `↳ lib (external)` and `↳ ours` |\n| `paint` | Drawing nodes and edges from your coordinates |\n| `serialize` | SVG to string |\n\n`↳ ours (wrapper)` is your code; `↳ lib (external)` is the third-party library underneath, if you wrap one. A layout that is slow because ELK is slow and a layout that is slow because of your own pass are the same number in the `layout` row and completely different problems one row down.\n\n`huge3.mmd` makes the point: 1410 ms in `parse` against 1.5 ms in `layout`. Its total is dominated by something you cannot fix from a layout algorithm, and reading totals would send you optimizing the wrong file.\n\nWatch `measure` too. It is not your phase, but it is downstream of `prepareLayout` — every synthetic node you add for an edge label is another element inserted into the DOM and measured, so a `prepareLayout` that is generous with helper nodes shows up as someone else's regression.\n\n### Comparing against the baseline\n\n`baseline.json` is a captured run over the same folder — dagre and elk, ten iterations, `theme=redux`, `look=neo`, with the capture date in the file.\n\nTreat the absolute numbers as a record of one machine on one day, not a threshold. They will not reproduce on your hardware, and a CI runner would not reproduce them either. What does carry over is the shape: the relative cost of the phases, which diagrams are layout-dominated and which are parse-dominated, and the ratio between the layouts. Profile your layout in the same run as dagre and elk and compare within that run.\n\n### What actually goes wrong\n\nIn practice the regressions are algorithmic, not micro-optimizations:\n\n- A pass over every pair of nodes. Fine at 50 nodes, 1.4 million comparisons at 1200.\n- `edges.filter((e) => e.start === node.id)` inside a loop over nodes — O(V·E) hidden behind two readable lines. Build the adjacency map once, before the loop.\n- Rebuilding a lookup inside an iterative refinement step, so an O(V) cost becomes O(V) per iteration.\n- Recursing into subgraphs without memoizing, and revisiting the same subtree once per ancestor.\n\nProfile before you optimize. Run the corpus, find the diagram where your `↳ ours` row is worst, and read that one — the corpus is small enough that the answer is usually one diagram and one loop.\n\n## Shipping as a separate package\n\nAn external layout uses the same `render` signature. Instead of editing the built-in registry, export a loader array and let the consumer register it:\n\n```ts\nimport type { LayoutLoaderDefinition } from 'mermaid';\n\nconst loader = async () => await import('./render.js');\n\nconst layouts: LayoutLoaderDefinition[] = [{ name: 'grid', loader, algorithm: 'grid.compact' }];\n\nexport default layouts;\n```\n\n```js\nimport mermaid from 'mermaid';\nimport layouts from 'my-mermaid-layout';\n\nmermaid.registerLayoutLoaders(layouts);\n```\n\nThe `algorithm` field is passed back to your renderer through `options`, which lets one package register several named variants that share an implementation.\n\nPackage it separately when the layout pulls in a large dependency. Everything else belongs in the main package, where it gets covered by the fixture sweep.\n\n## Checklist\n\n- [ ] `runLayoutCore` is one exported function with no DOM access\n- [ ] The browser and the tests call that same function\n- [ ] Group frames enclose their members and leave the title band clear\n- [ ] Edge labels reserve space before positions are decided\n- [ ] Edge endpoints land on node boundaries\n- [ ] Self-loops and parallel edges have routes\n- [ ] `validateLayout` returns `ok: true` on your fixtures\n- [ ] Fixtures exist, with captured sizes, for the cases the algorithm was written to handle\n- [ ] Your backend is registered in `ddlt/backends.ts` and your profile in `ddlt-manifest.json`\n- [ ] The sweep passes and the aggregate score has not dropped\n- [ ] `.mmd` fixtures under `e2e/diagrams/` cover the layout visually, since layout changes are rendering changes\n- [ ] The layout has been profiled against `performance/flowcharts/`, and the `↳ ours` row is understood\n","packages/mermaid/src/docs/community/new-diagram-jison.md":"# Adding a New Diagram/Chart (Deprecated) 📊\n\n```warning\nJISON grammars are deprecated in mermaid. Please use Langium instead. See [New Diagram](./new-diagram.md) for more information.\n\n**New diagrams with JISON grammars will not be accepted.**\n```\n\n### Step 1: Grammar & Parsing\n\n#### Grammar\n\nThis would be to define a JISON grammar for the new diagram type. That should start with a way to identify that the text in the mermaid tag is a diagram of that type. Create a new folder under diagrams for your new diagram type and a parser folder in it. This leads us to step 2.\n\nFor instance:\n\n- the flowchart starts with the keyword _graph_\n- the sequence diagram starts with the keyword _sequenceDiagram_\n\n#### Store data found during parsing\n\nThere are some jison specific sub steps here where the parser stores the data encountered when parsing the diagram, this data is later used by the renderer. You can during the parsing call an object provided to the parser by the user of the parser. This object can be called during parsing for storing data.\n\n```jison\nstatement\n\t: 'participant' actor { $$='actor'; }\n\t| signal { $$='signal'; }\n\t| note_statement { $$='note'; }\n\t| 'title' message { yy.setTitle($2); }\n\t;\n```\n\nIn the extract of the grammar above, it is defined that a call to the setTitle method in the data object will be done when parsing and the title keyword is encountered.\n\n```note\nMake sure that the `parseError` function for the parser is defined and calling `mermaid.parseError`. This way a common way of detecting parse errors is provided for the end-user.\n```\n\nFor more info look at the example diagram type:\n\nThe `yy` object has the following function:\n\n```javascript\nexports.parseError = function (err, hash) {\n mermaid.parseError(err, hash);\n};\n```\n\nwhen parsing the `yy` object is initialized as per below:\n\n```javascript\nconst parser = exampleParser.parser;\nparser.yy = db;\n```\n\n### Step 2: Rendering\n\nWrite a renderer that given the data found during parsing renders the diagram. To look at an example look at sequenceRenderer.js rather than the flowchart renderer as this is a more generic example.\n\nPlace the renderer in the diagram folder.\n\n### Step 3: Detection of the new diagram type\n\nThe second thing to do is to add the capability to detect the new diagram to type to the detectType in `diagram-api/detectType.ts`. The detection should return a key for the new diagram type.\n[This key will be used to as the aria roledescription](#aria-roledescription), so it should be a word that clearly describes the diagram type.\nFor example, if your new diagram uses a UML deployment diagram, a good key would be \"UMLDeploymentDiagram\" because assistive technologies such as a screen reader\nwould voice that as \"U-M-L Deployment diagram.\" Another good key would be \"deploymentDiagram\" because that would be voiced as \"Deployment Diagram.\" A bad key would be \"deployment\" because that would not sufficiently describe the diagram.\n\nNote that the diagram type key does not have to be the same as the diagram keyword chosen for the [grammar](#grammar), but it is helpful if they are the same.\n\n### Step 4: The final piece - triggering the rendering\n\nAt this point when mermaid is trying to render the diagram, it will detect it as being of the new type but there will be no match when trying to render the diagram. To fix this add a new case in the switch statement in main.js:init this should match the diagram type returned from step #2. The code in this new case statement should call the renderer for the diagram type with the data found by the parser as an argument.\n\n## Usage of the parser as a separate module\n\n### Setup\n\n```javascript\nconst graph = require('./graphDb');\nconst flow = require('./parser/flow');\nflow.parser.yy = graph;\n```\n\n### Parsing\n\n```javascript\nflow.parser.parse(text);\n```\n\n### Data extraction\n\n```javascript\ngraph.getDirection();\ngraph.getVertices();\ngraph.getEdges();\n```\n\nThe parser is also exposed in the mermaid api by calling:\n\n```javascript\nconst parser = mermaid.getParser();\n```\n\nNote that the parse needs a graph object to store the data as per:\n\n```javascript\nflow.parser.yy = graph;\n```\n\nLook at `graphDb.js` for more details on that object.\n\n## Layout\n\nIf you are using a dagre based layout, please use flowchart-v2 as a template and by doing that you will be using dagre-wrapper instead of dagreD3 which we are migrating away from.\n\n### Common parts of a diagram\n\nThere are a few features that are common between the different types of diagrams. We try to standardize the diagrams that work as similar as possible for the end user. The commonalities are:\n\n- Directives, a way of modifying the diagram configuration from within the diagram code.\n- Accessibility, a way for an author to provide additional information like titles and descriptions to people accessing a text with diagrams using a screen reader.\n- Themes, there is a common way to modify the styling of diagrams in Mermaid.\n- Comments should follow mermaid standards\n\nHere are some pointers on how to handle these different areas.\n\n## Accessibility\n\nMermaid automatically adds the following accessibility information for the diagram SVG HTML element:\n\n- aria-roledescription\n- accessible title\n- accessible description\n\n### aria-roledescription\n\nThe aria-roledescription is automatically set to [the diagram type](#step-3--detection-of-the-new-diagram-type) and inserted into the SVG element.\n\nSee [the definition of aria-roledescription](https://www.w3.org/TR/wai-aria-1.1/#aria-roledescription) in [the Accessible Rich Internet Applications W3 standard.](https://www.w3.org/WAI/standards-guidelines/aria/)\n\n### accessible title and description\n\nThe syntax for accessible titles and descriptions is described in [the Accessibility documentation section.](../config/accessibility.md)\n\nAs a design goal, the jison syntax should be similar between the diagrams.\n\n```jison\n\n* lexical grammar */\n%lex\n%x acc_title\n%x acc_descr\n%x acc_descr_multiline\n\n%%\naccTitle\\s*\":\"\\s* { this.begin(\"acc_title\");return 'acc_title'; }\n(?!\\n|;|#)*[^\\n]* { this.popState(); return \"acc_title_value\"; }\naccDescr\\s*\":\"\\s* { this.begin(\"acc_descr\");return 'acc_descr'; }\n(?!\\n|;|#)*[^\\n]* { this.popState(); return \"acc_descr_value\"; }\naccDescr\\s*\"{\"\\s* { this.begin(\"acc_descr_multiline\");}\n[\\}] { this.popState(); }\n[^\\}]* return \"acc_descr_multiline_value\";\n\nstatement\n : acc_title acc_title_value { $$=$2.trim();yy.setTitle($$); }\n | acc_descr acc_descr_value { $$=$2.trim();yy.setAccDescription($$); }\n | acc_descr_multiline_value { $$=$1.trim();yy.setAccDescription($$); }\n\n```\n\nThe functions for setting title and description are provided by a common module. This is the import from flowDb.js:\n\n```\nimport {\n setAccTitle,\n getAccTitle,\n getAccDescription,\n setAccDescription,\n clear as commonClear,\n} from '../../commonDb';\n```\n\nThe accessibility title and description are inserted into the SVG element in the `render` function in mermaidAPI.\n\n## Theming\n\nMermaid supports themes and has an integrated theming engine. You can read more about how the themes can be used [in the docs](../config/theming.md).\n\nWhen adding themes to a diagram it comes down to a few important locations in the code.\n\nThe entry point for the styling engine is in **src/styles.js**. The getStyles function will be called by Mermaid when the styles are being applied to the diagram.\n\nThis function will in turn call a function _your diagram should provide_ returning the css for the new diagram. The diagram specific, also which is commonly also called getStyles and located in the folder for your diagram under src/diagrams and should be named styles.js. The getStyles function will be called with the theme options as an argument like in the following example:\n\n```js\nconst getStyles = (options) =>\n `\n .line {\n stroke-width: 1;\n stroke: ${options.lineColor};\n stroke-dasharray: 2;\n }\n // ...\n `;\n```\n\nNote that you need to provide your function to the main getStyles by adding it into the themes object in **src/styles.js** like in the xyzDiagram in the provided example:\n\n```js\nconst themes = {\n flowchart,\n 'flowchart-v2': flowchart,\n sequence,\n xyzDiagram,\n //...\n};\n```\n\nThe actual options and values for the colors are defined in **src/theme/theme-[xyz].js**. If you provide the options your diagram needs in the existing theme files then the theming will work smoothly without hiccups.\n","packages/mermaid/src/docs/community/new-diagram.md":"# Adding a New Diagram/Chart 📊\n\nA diagram type in Mermaid is a plugin. You write a parser, a database, a renderer, and a styles\nfunction, register them under an id, and Mermaid handles detection, lazy loading, theming, and\nsanitization for you.\n\nThe use case diagram is the reference implementation for new work. When this guide says \"look at\nusecase\", the files are in `packages/mermaid/src/diagrams/usecase/`. Read them alongside these\nsteps: they are short, and they show the current conventions rather than the historical ones that\nolder diagrams still carry.\n\n## What a diagram is made of\n\nEach diagram exports a `DiagramDefinition` (`diagram-api/types.ts`) from a single entry file. The\nwhole of `usecaseDiagram.ts` is this:\n\n```ts\nimport type { DiagramDefinition } from '../../diagram-api/types.js';\nimport { parser } from './parser/usecase.chevrotain.js';\nimport { db } from './usecaseDb.js';\nimport { renderer } from './usecaseRenderer.js';\nimport styles from './styles.js';\n\nexport const diagram: DiagramDefinition = {\n parser,\n db,\n renderer,\n styles,\n};\n```\n\n| Part | What it does |\n| -------- | ------------------------------------------------------------------------------ |\n| parser | Turns diagram text into calls on the db. Fails with a useful message otherwise |\n| db | Holds the parsed model and hands it to the renderer |\n| renderer | Draws the SVG from what the db holds |\n| styles | Maps theme variables to CSS for your diagram |\n| detector | A regex test that recognizes your diagram's first line. Lives in its own file |\n\nTwo rules apply to everything in your folder:\n\nYour diagram must be self-contained. Never import from another diagram's folder. You may import\nfrom `diagrams/common/` and from `rendering-util/`, and that is the whole list. Cross-diagram\nimports create coupling that breaks unrelated diagrams later, so a reviewer will block on this.\n\nYour db must not carry state from one render into the next. `Diagram.fromText()` reads `db` off\nthe registered definition and calls `db.clear?.()` before parsing, and there are two supported\nways to satisfy that.\n\nA getter, which builds a new db on every read, so each render gets its own:\n\n```ts\nexport const diagram: DiagramDefinition = {\n parser,\n get db() {\n return new TreeMapDB();\n },\n renderer,\n styles,\n};\n```\n\nOr one shared db whose `clear()` resets every field it owns, plus the shared accessibility state\nin `diagrams/common/commonDb.ts`:\n\n```ts\nexport const diagram: DiagramDefinition = { parser, db, renderer, styles };\n```\n\nPrefer the getter in a new diagram. Isolation is then structural — a field added later cannot be\nforgotten in `clear()`, which is the way the shared form goes wrong. The use case diagram used as\nthe reference here takes the shared form, and pays for it by keeping every mutable field on one\n`state` object that `clear()` replaces wholesale, rather than resetting fields one by one.\n\nEither way the rule underneath is the same: all mutable state lives on the db, never in module\nscope. Module-level state survives `clear()` in both forms, and two diagrams of the same type on\none page will leak into each other.\n\n## Step 1: Grammar and parsing\n\nNew diagram grammars should use [Chevrotain](https://chevrotain.io/docs/), co-located with the\ndiagram itself under `packages/mermaid/src/diagrams//parser/`. The use case diagram is\nthe reference implementation: a lexer, a `CstParser`, and a CST visitor that builds the diagram\nmodel, sharing `diagrams/common/parser/runChevrotainParse.ts` to run the lexer/parser pair and\nreport failures with source positions.\n\nKeeping the grammar next to the diagram mirrors the existing JISON layout, so a diagram stays\nself-contained and the parser does not have to be released from a separate package.\n\nSeveral existing diagrams (architecture, gitGraph, info, packet, pie, radar, treemap) instead use\n[Langium](https://langium.org/docs/reference/grammar-language/) grammars in `packages/parser`, and\nolder diagrams use JISON. Both remain supported, so modify them in place for bug fixes rather than\nrewriting, but neither is the target for new work. These PRs show the Langium approach:\n\n- https://github.com/mermaid-js/mermaid/pull/4839\n- https://github.com/mermaid-js/mermaid/pull/4751\n\nWhichever you use, invalid input has to produce a parse error with a line and column, never a\nstack trace. Mermaid runs inside other people's pages, and a thrown exception there is a broken\npage rather than a broken diagram.\n\n## Step 2: The database\n\nThe db collects what the parser found and exposes getters for the renderer. Look at\n`usecaseDb.ts`. Alongside your own accessors, re-export the shared title and accessibility setters\nfrom `diagrams/common/commonDb.ts` so that authors get the same `title`, `accTitle`, and\n`accDescr` syntax they get everywhere else:\n\n```js\nimport {\n setAccTitle,\n getAccTitle,\n getAccDescription,\n setAccDescription,\n setDiagramTitle,\n getDiagramTitle,\n clear as commonClear,\n} from '../common/commonDb.js';\n```\n\nYour own `clear()` should call `commonClear()` as well as resetting your own fields.\n\n## Step 3: The renderer\n\nWrite a renderer that draws the diagram from what the db holds. `usecaseRenderer.ts` is a good\nstarting point, and `sequenceRenderer.js` is a more generic older example than the flowchart\nrenderer. The renderer belongs in your diagram folder.\n\nTwo things are easy to miss and both get flagged in review.\n\nApply the configured padding and hand the sizing to the shared helper, so your diagram scales like\nevery other diagram instead of rendering at some unrelated size:\n\n```ts\nimport { setupViewPortForSVG } from '../../rendering-util/setupViewPortForSVG.js';\n\nsetupViewPortForSVG(svg, padding, 'usecaseDiagram', config.useMaxWidth);\n```\n\nSupport hand-drawn mode if your drawing approach allows it. The config carries a `look`, and\ndiagrams check it directly:\n\n```ts\nconst isHandDrawn = look === 'handDrawn';\n```\n\nIf a third party library makes hand-drawn output impossible, that is an acceptable answer, but say\nso in your diagram's documentation page so users are not left guessing.\n\n## Step 4: Detection and registration\n\nDetection lives in its own file next to the diagram, not in `detectType.ts`. A detector is a\nregex test plus a lazy loader, and it exports an `ExternalDiagramDefinition`:\n\n```ts\nconst id = 'usecase';\n\nconst detector: DiagramDetector = (txt) => {\n return /^\\s*usecase-beta(?:\\s|$)/.test(txt);\n};\n\nconst loader: DiagramLoader = async () => {\n const { diagram } = await import('./usecaseDiagram.js');\n return { id, diagram };\n};\n\nexport const usecase: ExternalDiagramDefinition = { id, detector, loader };\n```\n\nThen import it in `diagram-api/diagram-orchestration.ts` and add it to the\n`registerLazyLoadedDiagrams(...)` call. Order matters there: the first detector that returns true\nwins, so a loose pattern placed early will swallow other diagrams. The loader is what keeps\nMermaid's bundle small, because your diagram is only fetched once someone writes one.\n\n[The id becomes the aria roledescription](#aria-roledescription), so pick a word that describes\nthe diagram out loud. For a UML deployment diagram, \"UMLDeploymentDiagram\" works, because a screen\nreader voices it as \"U-M-L Deployment diagram\", and so does \"deploymentDiagram\". \"deployment\" on\nits own does not say enough.\n\nThe id does not have to match the keyword you chose in the\n[grammar](#step-1-grammar-and-parsing), though it helps when they agree.\n\n## Step 5: Theming\n\nMermaid has an integrated theming engine, described in more detail [in the docs](../config/theming.md).\n\nYour diagram provides a `getStyles` function in `styles.ts` in your diagram folder. It is called\nwith the resolved theme options and returns CSS:\n\n```js\nconst getStyles = (options) =>\n `\n .line {\n stroke-width: 1;\n stroke: ${options.lineColor};\n stroke-dasharray: 2;\n }\n // ...\n `;\n```\n\nThere is nothing to wire up by hand. `registerDiagram()` passes your `styles` to\n`addStylesForDiagram()`, and the styling engine picks it up from there.\n\nEvery color must come from `options`. A hardcoded hex value looks fine in the default theme and\nthen breaks in dark mode, so reviewers treat hardcoded colors as a defect. The values themselves\nare defined in the theme files under `src/themes/`; if your diagram needs a variable that does not\nexist yet, add it there so all five themes define it.\n\n## Step 6: Configuration\n\nIf your diagram has options, add them to `src/schemas/config.schema.yaml`, both as an entry in the\nlist of diagram config keys and as its own config block. Then regenerate the types:\n\n```bash\npnpm run --filter mermaid types:build-config\n```\n\nNever edit `config.type.ts` by hand. It is generated, CI verifies it against the schema, and a\nmanual edit is a blocking review finding.\n\n## Accessibility\n\nMermaid automatically adds the following accessibility information for the diagram SVG HTML element:\n\n- aria-roledescription\n- accessible title\n- accessible description\n\n### aria-roledescription\n\nThe aria-roledescription is automatically set to\n[the diagram type](#step-4-detection-and-registration) and inserted into the SVG element.\n\nSee [the definition of aria-roledescription](https://www.w3.org/TR/wai-aria-1.1/#aria-roledescription) in [the Accessible Rich Internet Applications W3 standard.](https://www.w3.org/WAI/standards-guidelines/aria/)\n\n### accessible title and description\n\nThe syntax for accessible titles and descriptions is described in [the Accessibility documentation section.](../config/accessibility.md)\n\nYou get both for free once your db re-exports the setters shown in\n[Step 2](#step-2-the-database). The values are inserted into the SVG element in the `render`\nfunction in mermaidAPI.\n\n## Step 7: Tests\n\nA new diagram without tests will not be merged. There are three kinds, and none of them takes long.\n\nUnit tests for the parser and db go next to the code as `*.spec.ts`. Cover the syntax you\ndocumented, and cover invalid input too: a diagram that accepts nonsense silently is worse than\none that rejects it. Run them with `vitest run packages/mermaid/src/diagrams/`.\n\nVisual regression tests come from `.mmd` fixtures. Put one file per scenario in\n`e2e/diagrams//`, and that is the whole job:\n`e2e/rendering/mmd-snapshots.spec.ts` walks that directory, renders each fixture, and snapshots\nit, grouping the results by folder. Screenshot names must be unique across the whole tree, and the\nrun fails fast if two fixtures collide. `e2e/sheet-order.json` holds the ordering. Run the suite\nwith `pnpm e2e`. Cover realistic diagrams rather than one minimal smoke test, and include a\nfixture per theme if your styling is at all involved.\n\nA documentation test keeps your examples honest. `usecase.docs.spec.ts` reads the published\n`syntax/usecase.md`, extracts every ` ```mermaid-example ` block, and parses it. Copy that pattern\nand your documentation cannot drift into examples that no longer work.\n\n## Step 8: Documentation, demos, and examples\n\nWrite your syntax page as `packages/mermaid/src/docs/syntax/.md`. Edit only the files\nunder `src/docs/`; the top-level `/docs` folder is generated and your changes there will be\noverwritten. Mark the version with the placeholder, as `usecase.md` does with\n`# Use case diagrams (12.0.0+)`, and the release process substitutes the real\nnumber.\n\nAdd the page to the sidebar in `.vitepress/config.ts` under `sidebarSyntax()`. A page with no\nsidebar entry is reachable only by URL, which in practice means nobody reads it.\n\nAdd a demo page at `demos/.html` and link it from `demos/index.html`, following any\nof the existing demos.\n\nAdd at least one entry to the `@mermaid-js/examples` package, which is what tools like\nmermaid.live use to help people get started. Duplicate an existing file such as\n`packages/examples/src/examples/flowchart.ts`, adapt it, then import it in\n`packages/examples/src/index.ts` and add it to the `examples` array. Mark one example as the\ndefault, and add more to show off individual features.\n\nIf your syntax introduces new keywords, add them to `.cspell/mermaid-terms.txt`. The pre-commit\nhook runs CSpell and will otherwise reject the commit.\n\n## Step 9: Changeset and pull request\n\nRun `pnpm changeset`, choose the `mermaid` package and a `minor` bump, and write a description\nprefixed with `feat:`.\n\nOpen the PR against `develop` and link the issue it resolves. New diagram types are large by\nnature, and that is fine, but keep unrelated refactors out of the same branch.\n\n## Reviewer's checklist\n\nThis is what a reviewer checks. Going through it yourself first is the fastest way to a short\nreview.\n\n- [ ] Parser uses Chevrotain, co-located under `diagrams//parser/`\n- [ ] Invalid input produces a parse error with position, not a crash\n- [ ] `DiagramDefinition` exports parser, db, renderer, and styles\n- [ ] Detector in its own file, registered in `diagram-orchestration.ts`, ordered so it does not shadow other diagrams\n- [ ] Diagram id reads well as an aria roledescription\n- [ ] db holds no module-level state and `clear()` resets everything, including `commonClear()`\n- [ ] No imports from other diagrams' folders\n- [ ] Renderer applies padding and `useMaxWidth` through `setupViewPortForSVG`\n- [ ] Handdrawn mode implemented, or its absence documented\n- [ ] `styles.ts` takes theme options, with no hardcoded colors\n- [ ] Config options added to `config.schema.yaml` and `config.type.ts` regenerated, never hand-edited\n- [ ] Accessibility setters re-exported from `common/commonDb.ts`\n- [ ] Unit tests for parser and db, covering invalid input\n- [ ] `.mmd` fixtures in `e2e/diagrams//` for visual regression\n- [ ] Documentation examples covered by a docs spec\n- [ ] Syntax page under `src/docs/syntax/`, with `MERMAID_RELEASE_VERSION` and a sidebar entry\n- [ ] Demo page and `demos/index.html` link\n- [ ] Example added to `@mermaid-js/examples`, one marked default\n- [ ] New keywords added to `.cspell/mermaid-terms.txt`\n- [ ] Changeset created (`minor`, `feat:`)\n- [ ] PR targets `develop` and links its issue\n","packages/mermaid/src/docs/community/questions-and-suggestions.md":"# Questions or Suggestions?\n\n## Search for Existing Issue\n\nFirst search to see if someone has already asked (and hopefully been answered) or suggested the same thing.\n\n- [Search in Discussions](https://github.com/orgs/mermaid-js/discussions)\n- [Search in Issues (Open & Closed)](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue)\n\nIf you find an open issue or discussion thread that is similar to your question but isn't answered, you can let us know that you are also interested in it.\nUse the GitHub reactions to add a thumbs-up to the issue or discussion thread, or append to the issue if needed.\n\nThis helps the team know the relative interest in something and helps them set priorities and assignments.\n\n## Add a new Issue\n\nYou have not found anything that already addresses your request, or maybe you have come up with the new idea? Feel free to open a new issue or discussion.\n\nLog in to [GitHub.com](https://www.github.com), and use [GitHub issue tracker of the mermaid-js repository](https://github.com/mermaid-js/mermaid/issues). Press [issue, select the appropriate template](https://github.com/mermaid-js/mermaid/issues/new/choose) and describe your problem.\n","packages/mermaid/src/docs/community/security.md":"# Security\n\nThe Mermaid team takes the security of Mermaid and the applications that use Mermaid seriously. This page describes how to report any vulnerabilities you may find, and lists best practices to minimize the risk of introducing a vulnerability.\n\n## Reporting vulnerabilities\n\nTo report a vulnerability, please e-mail with a description of the issue, the steps you took to create the issue, affected versions, and if known, mitigations for the issue.\n\nWe aim to reply within three working days, probably much sooner.\n\nYou should expect a close collaboration as we work to resolve the issue you have reported. Please reach out to again if you do not receive prompt attention and regular updates.\n\nYou may also reach out to the team via our public Discord chat channels; however, please make sure to e-mail when reporting an issue, and avoid revealing information about vulnerabilities in public as that could that could put users at risk.\n\n## Best practices\n\nKeep current with the latest Mermaid releases. We regularly update Mermaid, and these updates may fix security defects discovered in previous versions. Check the Mermaid release notes for security-related updates.\n\nKeep your application’s dependencies up to date. Make sure you upgrade your package dependencies to keep the dependencies up to date. Avoid pinning to specific versions for your dependencies and, if you do, make sure you check periodically to see if your dependencies have had security updates, and update the pin accordingly.\n\n## Configuring DomPurify\n\nBy default Mermaid uses a baseline [DOMPurify](https://github.com/cure53/DOMPurify) config. It is possible to override the options passed to DOMPurify by adding a `dompurifyConfig` key to the Mermaid options. This could potentially break the output of Mermaid so use this with caution.\n","packages/mermaid/src/docs/config/8.6.0_docs.md":"# Version 8.6.0 Changes\n\n## [New Mermaid Live-Editor Beta](https://mermaid-js.github.io/docs/mermaid-live-editor-beta/#/edit/eyJjb2RlIjoiJSV7aW5pdDoge1widGhlbWVcIjogXCJmb3Jlc3RcIiwgXCJsb2dMZXZlbFwiOiAxIH19JSVcbmdyYXBoIFREXG4gIEFbQ2hyaXN0bWFzXSAtLT58R2V0IG1vbmV5fCBCKEdvIHNob3BwaW5nKVxuICBCIC0tPiBDe0xldCBtZSB0aGlua31cbiAgQyAtLT58T25lfCBEW0xhcHRvcF1cbiAgQyAtLT58VHdvfCBFW2lQaG9uZV1cbiAgQyAtLT58VGhyZWV8IEZbZmE6ZmEtY2FyIENhcl1cblx0XHQiLCJtZXJtYWlkIjp7InRoZW1lIjoiZGFyayJ9fQ)\n\n## [CDN](https://www.jsdelivr.com/package/npm/mermaid)\n\nWith version 8.6.0 comes the release of directives for mermaid, a new system for modifying configurations, with the aim of establishing centralized, sane defaults and simple implementation.\n\n`directives` allow for a single-use overwriting of `config`, as it has been discussed in [Configurations](../config/configuration.md).\nThis allows site Diagram Authors to instantiate temporary modifications to `config` through the use of [Directives](directives.md), which are parsed before rendering diagram definitions. This allows the Diagram Authors to alter the appearance of the diagrams.\n\n**A likely application for this is in the creation of diagrams/charts inside company/organizational webpages, that rely on mermaid for diagram and chart rendering.**\n\nthe `init` directive is the main method of configuration for Site and Current Levels.\n\nThe three levels of are Configuration, Global, Site and Current.\n\n| Level of Configuration | Description |\n| ---------------------- | ----------------------------------- |\n| Global Configuration | Default Mermaid Configurations |\n| Site Configuration | Configurations made by site owner |\n| Current Configuration | Configurations made by Implementors |\n\n# Limits to Modifying Configurations\n\n**secure Array**\n\n| Parameter | Description | Type | Required | Values |\n| --------- | ------------------------------------------------ | ----- | -------- | -------------- |\n| secure | Array of parameters excluded from init directive | Array | Required | Any parameters |\n\nThe modifiable parts of the Configuration are limited by the secure array, which is an array of immutable parameters, this array can be expanded by site owners.\n\n**Notes**: secure arrays work like nesting dolls, with the Global Configurations’ secure array holding the default and immutable list of immutable parameters, or the smallest doll, to which site owners may add to, but implementors may not modify it.\n\n# Secure Arrays\n\nSite owners can add to the **secure** array using this command:\nmermaidAPI.initialize( { startOnLoad: true, secure: ['parameter1', 'parameter2'] } );\n\nDefault values for the `secure array` consists of: ['secure', 'securityLevel', 'startOnLoad', 'maxTextSize']. These default values are immutable.\n\nImplementors can only modify configurations using directives, and cannot change the `secure` array.\n\n# Modifying Configurations and directives:\n\nThe Two types of directives: are `init` (or `initialize`) and `wrap`.\n\n```note\nAll directives are enclosed in `%%{ }%%`\n```\n\nOlder versions of mermaid will not parse directives because `%%` will comment out the directive. This makes the update backwards-compatible.\n\n# Init\n\n`init`, or `initialize`: this directive gives the user the ability to overwrite and change the values for any configuration parameters not set in the secure array.\n\n| Parameter | Description | Type | Required | Values |\n| --------- | ----------------------- | --------- | -------- | ----------------------------------------------- |\n| init | modifies configurations | Directive | Optional | Any parameters not included in the secure array |\n\n```note\ninit would be an argument-directive: `%%{init: { **insert argument here**}}%%`\n\nThe json object that is passed as {**argument** } must be valid, quoted json or it will be ignored.\n**for example**:\n\n`%%{init: {\"theme\": \"default\", \"logLevel\": 1 }}%%`\n\nConfigurations that are passed through init cannot change the parameters in a secure array at a higher level. In the event of a collision, mermaid will give priority to secure arrays and parse the request without changing the values of those parameters in conflict.\n\nWhen deployed within code, init is called before the graph/diagram description.\n```\n\n**for example**:\n\n```mermaid-example\n%%{init: {\"theme\": \"default\", \"logLevel\": 1 }}%%\n graph LR\n a-->b\n b-->c\n c-->d\n d-->e\n e-->f\n f-->g\n g-->\n```\n\n# Wrap\n\n| Parameter | Description | Type | Required | Values |\n| --------- | ----------------------------- | --------- | -------- | ---------- |\n| wrap | a callable text-wrap function | Directive | Optional | %%{wrap}%% |\n\n```note\nWrap is a function that is currently only deployable for sequence diagrams.\n\n`Wrap respects a manually added
, so if the user wants to break up their text, they have full control over line breaks by adding
tags.`\n\nIt is a non-argument directive and can be executed thusly:\n\n`%%{wrap}%%` .\n```\n\n**An example of text wrapping in a sequence diagram**:\n\n![Image showing wrapped text](img/wrapped text.png)\n\n# Resetting Configurations:\n\nThere are two more functions in the mermaidAPI that can be called by site owners: **reset** and **globalReset**.\n\n**reset**: resets the configuration to whatever the last configuration was. This can be done to undo more recent changes set from the last mermaidAPI.initialize({...}) configuration.\n\n**globalReset** will reset both the current configuration AND the site configuration back to the global defaults.\n\n**Notes**: Both `reset` and `globalReset` are only available to site owners, and as such implementors have to edit their configs using `init`.\n\n# Additional Utils to mermaid\n\n• **memoize**: simple caching for computationally expensive functions, reducing rendering time by about 90%.\n\n• **assignWithDepth** - an improvement on previous functions with config.js and `Object.assign`. The purpose of this function is to provide a sane mechanism for merging objects, similar to `object.assign`, but with depth.\n\nExample of **assignWithDepth**:\n\n![Image showing assignWithDepth](img/assignWithDepth.png)\n\nExample of **object.Assign**:\n\n![Image showing object.assign without depth](img/object.assign without depth.png)\n\n• **calculateTextDimensions**, **calculateTextWidth**， and **calculateTextHeight** - for measuring text dimensions, width and height.\n\n**Notes**: For more information on usage, parameters, and return info for these new functions take a look at the jsdocs for them in the utils package.\n\n# New API Requests Introduced in Version 8.6.0\n\n## setSiteConfig\n\n| Function | Description | Type | Values | Parameters | Returns |\n| --------------- | ------------------------------------- | ----------- | --------------------------------------- | ---------- | ---------- |\n| `setSiteConfig` | Sets the siteConfig to desired values | Put Request | Any Values, except ones in secure array | conf | siteConfig |\n\n```note\nSets the siteConfig. The siteConfig is a protected configuration for repeat use. Calls to reset() will reset\nthe currentConfig to siteConfig. Calls to reset(configApi.defaultConfig) will reset siteConfig and currentConfig\nto the defaultConfig\nNote: currentConfig is set in this function。\nDefault value: will mirror Global Config\n```\n\n## getSiteConfig\n\n| Function | Description | Type | Values |\n| --------------- | --------------------------------------------------- | ----------- | ---------------------------------- |\n| `getSiteConfig` | Returns the current `siteConfig` base configuration | Get Request | Returns Any Values in `siteConfig` |\n\n```note\nReturns any values in siteConfig.\n```\n\n## setConfig\n\n| Function | Description | Type | Values | Parameters | Returns |\n| ----------- | ------------------------------------------ | ----------- | --------------------------------- | ---------- | ---------------------------------------------- |\n| `setConfig` | Sets the `currentConfig` to desired values | Put Request | Any Values, those in secure array | conf | `currentConfig` merged with the sanitized conf |\n\n```note\nSets the currentConfig. The parameter conf is sanitized based on the siteConfig.secure keys. Any\nvalues found in conf with key found in siteConfig.secure will be replaced with the corresponding\nsiteConfig value.\n```\n\n## getConfig\n\n| Function | Description | Type | Return Values |\n| ----------- | --------------------------- | ----------- | ------------------------------- |\n| `getConfig` | Obtains the `currentConfig` | Get Request | Any Values from `currentConfig` |\n\n```note\nReturns any values in currentConfig.\n```\n\n## sanitize\n\n| Function | Description | Type | Values |\n| ---------- | ---------------------------------------- | -------------- | ------ |\n| `sanitize` | Sets the `siteConfig` to desired values. | Put Request(?) | None |\n\n```note\nmodifies options in-place\nEnsures options parameter does not attempt to override siteConfig secure keys.\n```\n\n## reset\n\n| Function | Description | Type | Required | Values | Parameter |\n| -------- | ------------------------------ | ----------- | -------- | ------ | --------- |\n| `reset` | Resets `currentConfig` to conf | Put Request | Required | None | conf |\n\n## conf\n\n| Parameter | Description | Type | Required | Values |\n| --------- | ------------------------------------------------------------ | ---------- | -------- | -------------------------------------------- |\n| `conf` | base set of values, which `currentConfig` could be reset to. | Dictionary | Required | Any Values, with respect to the secure Array |\n\n```note\ndefault: current siteConfig (optional, default `getSiteConfig()`)\n```\n\n## For more information, read [Setup](./setup/README.md).\n","packages/mermaid/src/docs/config/accessibility.md":"# Accessibility Options\n\n## Accessibility\n\nNow with Mermaid library in much wider use, we have started to work towards more accessible features, based on the feedback from the community.\n\nAdding accessibility means that the rich information communicated by visual diagrams can be made available to those using assistive technologies (and of course to search engines).\n[Read more about Accessible Rich Internet Applications and the W3 standards.](https://www.w3.org/WAI/standards-guidelines/aria/)\n\nMermaid will automatically insert the [aria-roledescription](#aria-roledescription) and, if provided in the diagram text by the diagram author, the [accessible title and description.](#accessible-title-and-description)\n\n### aria-roledescription\n\nThe [aria-roledescription](https://www.w3.org/TR/wai-aria-1.1/#aria-roledescription) for the SVG HTML element is set to the diagram type key. (Note this may be slightly different than the keyword used for the diagram in the diagram text.)\n\nFor example: The diagram type key for a state diagram is \"stateDiagram\". Here (a part of) the HTML of the SVG tag that shows the automatically inserted aria-roledescription set to \"stateDiagram\". _(Note that some of the SVG attributes and the SVG contents are omitted for clarity.):_\n\n```html\n\n```\n\n### Accessible Title and Description\n\nSupport for accessible titles and descriptions is available for all diagrams/chart types. We have tried to keep the same keywords and format for all diagrams so that it is easy to understand and maintain.\n\nThe accessible title and description will add `` and `<desc>` elements within the SVG element and the [aria-labelledby](https://www.w3.org/TR/wai-aria/#aria-labelledby) and [aria-describedby](https://www.w3.org/TR/wai-aria/#aria-describedby) attributes in the SVG tag.\n\nHere is HTML that is generated, showing that the SVG element is labelled by the accessible title (id = `chart-title-mermaid-1668725057758`)\nand described by the accessible description (id = `chart-desc-mermaid-1668725057758` );\nand the accessible title element (text = \"This is the accessible title\")\nand the accessible description element (text = \"This is an accessible description\").\n\n_(Note that some of the SVG attributes and the SVG contents are omitted for clarity.)_\n\n```html\n<svg\n aria-labelledby=\"chart-title-mermaid-1668725057758\"\n aria-describedby=\"chart-desc-mermaid-1668725057758\"\n xmlns=\"http://www.w3.org/2000/svg\"\n width=\"100%\"\n id=\"mermaid-1668725057758\"\n>\n <title id=\"chart-title-mermaid-1668725057758\">This is the accessible title\n This is an accessible description\n\n```\n\nDetails for the syntax follow.\n\n#### accessible title\n\nThe **accessible title** is specified with the **accTitle** _keyword_, followed by a colon (`:`), and the string value for the title.\nThe string value ends at the end of the line. (It can only be a single line.)\n\nEx: `accTitle: This is a single line title`\n\nSee [the accTitle and accDescr usage examples](#acctitle-and-accdescr-usage-examples) for how this can be used in a diagram and the resulting HTML generated.\n\n#### accessible description\n\nAn accessible description can be 1 line long (a single line) or many lines long.\n\nThe **single line accessible description** is specified with the **accDescr** _keyword_, followed by a colon (`:`), followed by the string value for the description.\n\nEx: `accDescr: This is a single line description.`\n\nA **multiple line accessible description** _does not have a colon (`:`) after the accDescr keyword_ and is surrounded by curly brackets (`{}`).\n\nEx:\n\n```markdown\naccDescr {\nThis is a multiple line accessible description.\nIt does not have a colon and is surrounded by curly brackets.\n}\n```\n\nSee [the accTitle and accDescr usage examples](#acctitle-and-accdescr-usage-examples) for how this can be used in a diagram and the resulting HTML generated.\n\n#### accTitle and accDescr Usage Examples\n\n- Flowchart with the accessible title \"Big Decisions\" and the single-line accessible description \"Bob's Burgers process for making big decisions\"\n\n```mermaid-example\n graph LR\n accTitle: Big Decisions\n accDescr: Bob's Burgers process for making big decisions\n A[Identify Big Decision] --> B{Make Big Decision}\n B --> D[Be done]\n```\n\nHere is the HTML generated for the SVG element: _(Note that some of the SVG attributes and the SVG contents are omitted for clarity.):_\n\n```html\n\n Big decisions\n Bob's Burgers process for making big decisions\n\n```\n\n- Flowchart with the accessible title \"Bob's Burger's Making Big Decisions\" and the multiple line accessible description \"The official Bob's Burgers corporate processes that are used\n for making very, very big decisions.\n This is actually a very simple flow: identify the big decision and then make the big decision.\"\n\n```mermaid-example\n graph LR\n accTitle: Bob's Burger's Making Big Decisions\n accDescr {\n The official Bob's Burgers corporate processes that are used\n for making very, very big decisions.\n This is actually a very simple flow: identify the big decision and then make the big decision.\n }\n A[Identify Big Decision] --> B{Make Big Decision}\n B --> D[Be done]\n```\n\nHere is the HTML generated for the SVG element: _(Note that some of the SVG attributes and the SVG contents are omitted for clarity.):_\n\n```html\n\n Big decisions\n \n The official Bob's Burgers corporate processes that are used for making very, very big\n decisions. This is actually a very simple flow: identify the big decision and then make the big\n decision.\n \n\n```\n\n#### Sample Code Snippets for other diagram types\n\n##### Class Diagram\n\n```mermaid-example\n classDiagram\n accTitle: My Class Diagram\n accDescr: My Class Diagram Description\n\n Vehicle <|-- Car\n```\n\n##### Entity Relationship Diagram\n\n```mermaid-example\n erDiagram\n accTitle: My Entity Relationship Diagram\n accDescr: My Entity Relationship Diagram Description\n\n CUSTOMER ||--o{ ORDER : places\n ORDER ||--|{ LINE-ITEM : contains\n CUSTOMER }|..|{ DELIVERY-ADDRESS : uses\n\n```\n\n##### Gantt Chart\n\n```mermaid-example\n gantt\n accTitle: My Gantt Chart Accessibility Title\n accDescr: My Gantt Chart Accessibility Description\n\n title A Gantt Diagram\n dateFormat YYYY-MM-DD\n section Section\n A task :a1, 2014-01-01, 30d\n Another task :after a1 , 20d\n section Another\n Task in sec :2014-01-12 , 12d\n another task : 24d\n\n```\n\n##### GitGraph\n\n```mermaid-example\n gitGraph\n accTitle: My GitGraph Accessibility Title\n accDescr: My GitGraph Accessibility Description\n\n commit\n commit\n branch develop\n checkout develop\n commit\n commit\n checkout main\n merge develop\n commit\n commit\n\n```\n\n##### Pie Chart\n\n```mermaid-example\n pie\n accTitle: My Pie Chart Accessibility Title\n accDescr: My Pie Chart Accessibility Description\n\n title Key elements in Product X\n \"Calcium\" : 42.96\n \"Potassium\" : 50.05\n \"Magnesium\" : 10.01\n \"Iron\" : 5\n\n```\n\n##### Requirement Diagram\n\n```mermaid-example\n requirementDiagram\n accTitle: My Requirement Diagram\n accDescr: My Requirement Diagram Description\n\n requirement test_req {\n id: 1\n text: the test text.\n risk: high\n verifymethod: test\n }\n\n element test_entity {\n type: simulation\n }\n\n test_entity - satisfies -> test_req\n\n```\n\n##### Sequence Diagram\n\n```mermaid-example\n sequenceDiagram\n accTitle: My Sequence Diagram\n accDescr: My Sequence Diagram Description\n\n Alice->>John: Hello John, how are you?\n John-->>Alice: Great!\n Alice-)John: See you later!\n```\n\n##### State Diagram\n\n```mermaid-example\n stateDiagram\n accTitle: My State Diagram\n accDescr: My State Diagram Description\n\n s1 --> s2\n\n```\n\n##### User Journey Diagram\n\n```mermaid-example\n journey\n accTitle: My User Journey Diagram\n accDescr: My User Journey Diagram Description\n\n title My working day\n section Go to work\n Make tea: 5: Me\n Go upstairs: 3: Me\n Do work: 1: Me, Cat\n section Go home\n Go downstairs: 5: Me\n Sit down: 5: Me\n\n```\n","packages/mermaid/src/docs/config/configuration.md":"# Configuration\n\nWhen mermaid starts, configuration is extracted to determine a configuration to be used for a diagram. There are 3 sources for configuration:\n\n- The default configuration\n- Overrides at the site level are set by the initialize call, and will be applied to all diagrams in the site/app. The term for this is the **siteConfig**.\n- Frontmatter (v10.5.0+) - diagram authors can update selected configuration parameters in the frontmatter of the diagram. These are applied to the render config.\n- Directives (Deprecated by Frontmatter) - diagram authors can update selected configuration parameters directly in the diagram code via directives. These are applied to the render config.\n\n**The render config** is configuration that is used when rendering by applying these configurations.\n\n## Frontmatter config\n\nThe entire mermaid configuration (except the secure configs) can be overridden by the diagram author in the frontmatter of the diagram. The frontmatter is a YAML block at the top of the diagram.\n\n```mermaid-example\n---\ntitle: Hello Title\nconfig:\n theme: base\n themeVariables:\n primaryColor: \"#00ff00\"\n---\nflowchart\n\tHello --> World\n\n```\n\n## Theme configuration\n\n## Starting mermaid\n\n```mermaid\nsequenceDiagram\n\tSite->>mermaid: initialize\n\tSite->>mermaid: content loaded\n\tmermaid->>mermaidAPI: init\n```\n\n## Initialize\n\nThe initialize call is applied **only once**. It is called by the site integrator in order to override the default configuration at a site level.\n\n## configApi.reset\n\nThis method resets the configuration for a diagram to the overall site configuration, which is the configuration provided by the site integrator. Before each rendering of a diagram, reset is called at the very beginning.\n","packages/mermaid/src/docs/config/directives.md":"# Directives\n\n```warning\nDirectives are deprecated from v10.5.0. Please use the `config` key in frontmatter to pass configuration. See [Configuration](./configuration.md) for more details.\n```\n\n## Directives\n\nDirectives give a diagram author the capability to alter the appearance of a diagram before rendering by changing the applied configuration.\n\nThe significance of having directives is that you have them available while writing the diagram, and can modify the default global and diagram-specific configurations. So, directives are applied on top of the default configuration. The beauty of directives is that you can use them to alter configuration settings for a specific diagram, i.e. at an individual level.\n\nWhile directives allow you to change most of the default configuration settings, there are some that are not available, for security reasons. Also, you have the _option to define the set of configurations_ that you wish to allow diagram authors to override with directives.\n\n## Types of Directives options\n\nMermaid basically supports two types of configuration options to be overridden by directives.\n\n1. _General/Top Level configurations_ : These are the configurations that are available and applied to all the diagram. **Some of the most important top-level** configurations are:\n - theme\n - fontFamily\n - logLevel\n - securityLevel\n - startOnLoad\n - secure\n\n2. _Diagram-specific configurations_ : These are the configurations that are available and applied to a specific diagram. For each diagram there are specific configuration that will alter how that particular diagram looks and behaves.\n For example, `mirrorActors` is a configuration that is specific to the `SequenceDiagram` and alters whether the actors are mirrored or not. So this config is available only for the `SequenceDiagram` type.\n\n**NOTE:** Not all configuration options are listed here. To get hold of all the configuration options, please refer to the [defaultConfig.ts](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/defaultConfig.ts) in the source code.\n\n```note\nWe plan to publish a complete list of top-level configurations & diagram-specific configurations with their possible values in the docs soon.\n```\n\n## Declaring directives\n\nNow that we have defined the types of configurations that are available, we can learn how to declare directives.\nA directive always starts and ends with `%%` signs with directive text in between, like `%% {directive_text} %%`.\n\nHere the structure of a directive text is like a nested key-value pair map or a JSON object with root being _init_. Where all the general configurations are defined in the top level, and all the diagram specific configurations are defined one level deeper with diagram type as key/root for that section.\n\nThe following code snippet shows the structure of a directive:\n\n```\n%%{\n init: {\n \"theme\": \"dark\",\n \"fontFamily\": \"monospace\",\n \"logLevel\": \"info\",\n \"htmlLabels\": true,\n \"flowchart\": {\n \"curve\": \"linear\"\n },\n \"sequence\": {\n \"mirrorActors\": true\n }\n }\n}%%\n```\n\nYou can also define the directives in a single line, like this:\n\n```\n%%{init: { **insert configuration options here** } }%%\n```\n\nFor example, the following code snippet:\n\n```\n%%{init: { \"sequence\": { \"mirrorActors\":false }}}%%\n```\n\n**Notes:**\nThe JSON object that is passed as {**argument**} must be valid key value pairs and encased in quotation marks or it will be ignored.\nValid Key Value pairs can be found in config.\n\nExample with a simple graph:\n\n```mermaid-example\n%%{init: { 'logLevel': 'debug', 'theme': 'dark' } }%%\ngraph LR\nA-->B\n```\n\nHere the directive declaration will set the `logLevel` to `debug` and the `theme` to `dark` for a rendered mermaid diagram, changing the appearance of the diagram itself.\n\nNote: You can use 'init' or 'initialize' as both are acceptable as init directives. Also note that `%%init%%` and `%%initialize%%` directives will be grouped together after they are parsed.\n\n```mermaid-example\n%%{init: { 'logLevel': 'debug', 'theme': 'forest' } }%%\n%%{initialize: { 'logLevel': 'fatal', \"theme\":'dark', 'startOnLoad': true } }%%\n...\n```\n\nFor example, parsing the above generates a single `%%init%%` JSON object below, combining the two directives and carrying over the last value given for `loglevel`:\n\n```json\n{\n \"logLevel\": \"fatal\",\n \"theme\": \"dark\",\n \"startOnLoad\": true\n}\n```\n\nThis will then be sent to `mermaid.initialize(...)` for rendering.\n\n## Directive Examples\n\nNow that the concept of directives has been explained, let us see some more examples of directive usage:\n\n### Changing theme via directive\n\nThe following code snippet changes `theme` to `forest`:\n\n`%%{init: { \"theme\": \"forest\" } }%%`\n\nPossible theme values are: `default`, `base`, `dark`, `forest` and `neutral`.\nDefault Value is `default`.\n\nExample:\n\n```mermaid-example\n%%{init: { \"theme\": \"forest\" } }%%\ngraph TD\nA(Forest) --> B[/Another/]\nA --> C[End]\n subgraph section\n B\n C\n end\n\n```\n\n### Changing fontFamily via directive\n\nThe following code snippet changes fontFamily to Trebuchet MS, Verdana, Arial, Sans-Serif:\n\n`%%{init: { \"fontFamily\": \"Trebuchet MS, Verdana, Arial, Sans-Serif\" } }%%`\n\nExample:\n\n```mermaid-example\n%%{init: { \"fontFamily\": \"Trebuchet MS, Verdana, Arial, Sans-Serif\" } }%%\ngraph TD\nA(Forest) --> B[/Another/]\nA --> C[End]\n subgraph section\n B\n C\n end\n\n```\n\n### Changing logLevel via directive\n\nThe following code snippet changes `logLevel` to `2`:\n\n`%%{init: { \"logLevel\": 2 } }%%`\n\nPossible `logLevel` values are:\n\n- `1` for _debug_,\n- `2` for _info_\n- `3` for _warn_\n- `4` for _error_\n- `5` for _only fatal errors_\n\nDefault Value is `5`.\n\nExample:\n\n```mermaid-example\n%%{init: { \"logLevel\": 2 } }%%\ngraph TD\nA(Forest) --> B[/Another/]\nA --> C[End]\n subgraph section\n B\n C\n end\n```\n\n### Changing flowchart config via directive\n\nSome common flowchart configurations are:\n\n- ~~_htmlLabels_~~: Deprecated, [prefer setting this at the root level](/config/schema-docs/config#htmllabels).\n- _curve_: linear/curve\n- _diagramPadding_: number\n- _useMaxWidth_: number\n\nFor a complete list of flowchart configurations, see [defaultConfig.ts](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/defaultConfig.ts) in the source code.\n_Soon we plan to publish a complete list of all diagram-specific configurations updated in the docs._\n\nThe following code snippet changes flowchart config:\n\n```\n%%{init: { \"htmlLabels\": true, \"flowchart\": { \"curve\": \"linear\" } } }%%\n```\n\nHere we are overriding only the flowchart config, and not the general config, setting `htmlLabels` to `true` and `curve` to `linear`.\n\n```warning\n**Deprecated:** `flowchart.htmlLabels` has been deprecated from (v11.12.3+). Use the global `htmlLabels` configuration instead. For example, instead of `\"flowchart\": { \"htmlLabels\": true }`, use `\"htmlLabels\": true` at the top level.\n```\n\n```mermaid-example\n%%{init: { \"flowchart\": { \"htmlLabels\": true, \"curve\": \"linear\" } } }%%\ngraph TD\nA(Forest) --> B[/Another/]\nA --> C[End]\n subgraph section\n B\n C\n end\n```\n\n### Changing Sequence diagram config via directive\n\nSome common sequence diagram configurations are:\n\n- _width_: number\n- _height_: number\n- _messageAlign_: left, center, right\n- _mirrorActors_: boolean\n- _useMaxWidth_: boolean\n- _rightAngles_: boolean\n- _showSequenceNumbers_: boolean\n- _wrap_: boolean\n\nFor a complete list of sequence diagram configurations, see [defaultConfig.ts](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/defaultConfig.ts) in the source code.\n_Soon we plan to publish a complete list of all diagram-specific configurations updated in the docs._\n\nSo, `wrap` by default has a value of `false` for sequence diagrams.\n\nLet us see an example:\n\n```mermaid-example\nsequenceDiagram\n\nAlice->Bob: Hello Bob, how are you?\nBob->Alice: Fine, how did your mother like the book I suggested? And did you catch the new book about alien invasion?\nAlice->Bob: Good.\nBob->Alice: Cool\n```\n\nNow let us enable wrap for sequence diagrams.\n\nThe following code snippet changes sequence diagram config for `wrap` to `true`:\n\n`%%{init: { \"sequence\": { \"wrap\": true} } }%%`\n\nBy applying that snippet to the diagram above, `wrap` will be enabled:\n\n```mermaid-example\n%%{init: { \"sequence\": { \"wrap\": true, \"width\":300 } } }%%\nsequenceDiagram\nAlice->Bob: Hello Bob, how are you?\nBob->Alice: Fine, how did your mother like the book I suggested? And did you catch the new book about alien invasion?\nAlice->Bob: Good.\nBob->Alice: Cool\n```\n","packages/mermaid/src/docs/config/faq.md":"# Frequently Asked Questions\n\n1. [How to add title to flowchart?](https://github.com/mermaid-js/mermaid/issues/1433#issuecomment-1991554712)\n1. [How to specify custom CSS file?](https://github.com/mermaidjs/mermaid.cli/pull/24#issuecomment-373402785)\n1. [How to fix tooltip misplacement issue?](https://github.com/mermaid-js/mermaid/issues/542#issuecomment-3343564621)\n1. [How to specify gantt diagram xAxis format?](https://github.com/mermaid-js/mermaid/issues/269#issuecomment-373229136)\n1. [How to bind an event?](https://github.com/mermaid-js/mermaid/issues/372)\n1. [How to add newline in the text?](https://github.com/mermaid-js/mermaid/issues/384#issuecomment-281339381)\n1. [How to have special characters in link text?](https://github.com/mermaid-js/mermaid/issues/407#issuecomment-329944735)\n1. [How to change Flowchart curve style?](https://github.com/mermaid-js/mermaid/issues/580#issuecomment-373929046)\n1. [How to create a Flowchart end-Node that says \"End\"](https://github.com/mermaid-js/mermaid/issues/1444#issuecomment-639528897)\n","packages/mermaid/src/docs/config/icons.md":"# Registering icon pack in mermaid\n\nThe icon packs available can be found at [icones.js.org](https://icones.js.org/).\nWe use the name defined when registering the icon pack, to override the prefix field of the iconify pack. This allows the user to use shorter names for the icons. It also allows us to load a particular pack only when it is used in a diagram.\n\nUsing JSON file directly from CDN:\n\n```js\nimport mermaid from 'CDN/mermaid.esm.mjs';\nmermaid.registerIconPacks([\n {\n name: 'logos',\n loader: () =>\n fetch('https://unpkg.com/@iconify-json/logos@1/icons.json').then((res) => res.json()),\n },\n]);\n```\n\nUsing packages and a bundler:\n\n```bash\nnpm install @iconify-json/logos@1\n```\n\nWith lazy loading\n\n```js\nimport mermaid from 'mermaid';\n\nmermaid.registerIconPacks([\n {\n name: 'logos',\n loader: () => import('@iconify-json/logos').then((module) => module.icons),\n },\n]);\n```\n\nWithout lazy loading\n\n```js\nimport mermaid from 'mermaid';\nimport { icons } from '@iconify-json/logos';\nmermaid.registerIconPacks([\n {\n name: icons.prefix, // To use the prefix defined in the icon pack\n icons,\n },\n]);\n```\n","packages/mermaid/src/docs/config/layouts.md":"# Layouts\n\nThis page lists the available layout algorithms supported in Mermaid diagrams.\n\n## ELK is bundled and default from v12.0.0\n\nBefore v12.0.0, ELK shipped as a separate `@mermaid-js/layout-elk` package that\neach site had to install and register. It is now part of `mermaid` itself and\nregistered automatically, so `layout: elk` works with no setup — and it is the\n**default**, replacing Dagre.\n\n`elk` is the new default layout for these diagrams:\n\n- Flowchart\n- State\n- Class\n- Entity relationship\n- Requirement\n- Use case\n- Agentflow\n\nTo go back to the previous layout, use `layout: dagre`.\n\nThe main `mermaid` package always includes ELK. If you want Mermaid without it,\nuse the [tiny build](./usage.md#elk-and-the-tiny-build), which omits ELK along\nwith some diagram types. `@mermaid-js/layout-elk` is still published so the tiny\nbuild can opt back in.\n\n## Supported Layouts\n\n- **elk** (default): [ELK (Eclipse Layout Kernel)](https://www.eclipse.org/elk/). Bundled with Mermaid; no setup required. Specific ELK algorithms can be selected as `elk.stress`, `elk.force`, `elk.mrtree`, `elk.sporeOverlap`, `elk.box`, and `elk.rectpacking`.\n- **dagre**: Dagre layout for layered graphs\n- **cose-bilkent**: Cose Bilkent layout for force-directed graphs\n- **tidy-tree**: Tidy tree layout for hierarchical diagrams, from the [`@mermaid-js/layout-tidy-tree`](https://www.npmjs.com/package/@mermaid-js/layout-tidy-tree) package [Tidy Tree Configuration](/config/tidy-tree)\n\nMindmaps are the one diagram type not laid out with ELK by default; they use\ncose-bilkent unless you ask for something else.\n\nThe **tiny** build omits ELK to stay small, and falls back to Dagre for\ndiagrams that request it. See\n[ELK and the tiny build](./usage.md#elk-and-the-tiny-build) for how to register\n`@mermaid-js/layout-elk` there if you want ELK anyway.\n\n## How to Use\n\nSince `elk` is the default, a diagram needs no configuration to use it. To pick\na different layout, set it in your diagram's YAML config or initialization\noptions. For example:\n\n```mermaid\n---\nconfig:\n layout: dagre\n---\ngraph TD;\n A-->B;\n B-->C;\n```\n","packages/mermaid/src/docs/config/math.md":"# Math Configuration (v10.9.0+)\n\nMermaid supports rendering mathematical expressions through the [KaTeX](https://katex.org/) typesetter.\n\n## Usage\n\nTo render math within a diagram, surround the mathematical expression with the `$$` delimiter.\n\nNote that at the moment, the only supported diagrams are below:\n\n### Flowcharts\n\n```mermaid-example\n graph LR\n A[\"$$x^2$$\"] -->|\"$$\\sqrt{x+3}$$\"| B(\"$$\\frac{1}{2}$$\")\n A -->|\"$$\\overbrace{a+b+c}^{\\text{note}}$$\"| C(\"$$\\pi r^2$$\")\n B --> D(\"$$x = \\begin{cases} a &\\text{if } b \\\\ c &\\text{if } d \\end{cases}$$\")\n C --> E(\"$$x(t)=c_1\\begin{bmatrix}-\\cos{t}+\\sin{t}\\\\ 2\\cos{t} \\end{bmatrix}e^{2t}$$\")\n```\n\n### Sequence\n\n```mermaid-example\nsequenceDiagram\n autonumber\n participant 1 as $$\\alpha$$\n participant 2 as $$\\beta$$\n 1->>2: Solve: $$\\sqrt{2+2}$$\n 2-->>1: Answer: $$2$$\n Note right of 2: $$\\sqrt{2+2}=\\sqrt{4}=2$$\n```\n\n## Legacy Support\n\nBy default, MathML is used for rendering mathematical expressions. If you have users on [unsupported browsers](https://caniuse.com/?search=mathml), `legacyMathML` can be set in the config to fall back to CSS rendering. Note that **you must provide KaTeX's stylesheets on your own** as they do not come bundled with Mermaid.\n\nExample with legacy mode enabled (the latest version of KaTeX's stylesheet can be found on their [docs](https://katex.org/docs/browser.html)):\n\n```html\n\n\n\n \n \n \n \n\n \n \n \n\n```\n\n## Handling Rendering Differences\n\nDue to differences between default fonts across operating systems and browser's MathML implementations, inconsistent results can be seen across platforms. If having consistent results are important, or the most optimal rendered results are desired, `forceLegacyMathML` can be enabled in the config.\n\nThis option will always use KaTeX's stylesheet instead of only when MathML is not supported (as with `legacyMathML`). Note that only `forceLegacyMathML` needs to be set.\n\nIf including KaTeX's stylesheet is not a concern, enabling this option is recommended to avoid scenarios where no MathML implementation within a browser provides the desired output (as seen below).\n\n![Image showing differences between Browsers](img/mathMLDifferences.png)\n","packages/mermaid/src/docs/config/mermaidCLI.md":"# mermaid CLI\n\nmermaid CLI has been moved to [mermaid-cli](https://github.com/mermaid-js/mermaid-cli). Please read its documentation instead.\n","packages/mermaid/src/docs/config/theming.md":"# Theme Configuration\n\nDynamic and integrated theme configuration was introduced in Mermaid version 8.7.0.\n\nThemes can now be customized at the site-wide level, or on individual Mermaid diagrams. For site-wide theme customization, the `initialize` call is used. For diagram specific customization, frontmatter config is used.\n\n## Available Themes\n\n1. [**redux-color**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-redux-color.js) - The default theme for the diagram types listed under [Per-diagram defaults](#per-diagram-defaults). It pairs the `redux` geometry and typography with a categorical colour palette, so entities, actors, branches, classes, subgraph containers and chart series each get their own colour.\n\n2. [**redux-dark-color**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-redux-dark-color.js) - The dark counterpart of `redux-color`.\n\n3. [**redux**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-redux.js) - The same geometry and typography as `redux-color`, but monochrome. Use this when you want the colour to carry meaning you assign yourself rather than being cycled per item.\n\n4. [**redux-dark**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-redux-dark.js) - The dark counterpart of `redux`.\n\n5. [**default**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-default.js) - The long-standing Mermaid look, and still the default for every diagram type not listed under [Per-diagram defaults](#per-diagram-defaults).\n\n6. [**neutral**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-neutral.js) - This theme is great for black-and-white documents that will be printed.\n\n7. [**dark**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-dark.js) - This theme goes well with dark-colored elements or dark-mode. To use the dark theme (which changes the theme of the schema itself) with dark-mode (which sets the background), set `darkMode` to `true` in your config.\n\n8. [**forest**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-forest.js) - This theme contains shades of green.\n\n9. [**neo**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-neo.js) - A flatter, softer look, intended to be paired with `look: neo`.\n\n10. [**neo-dark**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-neo-dark.js) - The dark counterpart of `neo`.\n\n11. [**base**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-base.js) - This is the only theme that can be modified. Use this theme as the base for customizations.\n\n## Per-diagram defaults\n\nNot every diagram type defaults to the same theme and look. Since v12.0.0\nthese do, to the `redux-color` theme and the `neo` look. The name on the left is the **config key** — what you write to\nscope a setting to that diagram, which is not always the keyword the diagram starts with:\n\n| Config key | Diagram |\n| ------------- | -------------------- |\n| `agentflow` | `agentflow-beta` |\n| `flowchart` | `flowchart` |\n| `swimlane` | `swimlane-beta` |\n| `class` | `classDiagram` |\n| `er` | `erDiagram` |\n| `requirement` | `requirementDiagram` |\n| `sequence` | `sequenceDiagram` |\n| `state` | `stateDiagram` |\n| `usecase` | `usecase-beta` |\n| `venn` | `venn-beta` |\n\nEvery other diagram type defaults to the `default` theme and the `classic` look.\n\n`layout` works the same way. Only `swimlane` overrides it, to `swimlane`; everything else\nuses the global default, `dagre`.\n\nThese are only defaults, and the most specific thing you say wins. Highest priority first:\n\n1. The diagram's own frontmatter or `%%{init}%%` directive.\n2. What you passed to `mermaid.initialize()`.\n3. The diagram type's default, above.\n4. The global default (`theme: default`, `look: classic`, `layout: dagre`).\n\nA layout that is not registered in the running build falls back to `dagre`, with a warning\nin the console. `elk` ships as a separate package you register yourself, and `cose-bilkent`\nis only bundled into builds that include the large features, so naming either as a default\ndoes not require every build to carry it.\n\nWithin each of the first two you can also scope a value to one diagram type, and the\nscoped value wins over the global one you set alongside it. `theme`, `look` and `layout`\ncan all be set this way:\n\n```javascript\nmermaid.initialize({\n look: 'classic', // everything is classic...\n flowchart: { look: 'handDrawn' }, // ...except flowcharts\n er: { theme: 'neutral' },\n});\n```\n\nThe same works in frontmatter, for one diagram:\n\n```yaml\n---\nconfig:\n flowchart:\n look: handDrawn\n---\n```\n\n### Going back to the previous appearance\n\nThe nine types above changed appearance when these became their defaults. To draw one the\nway Mermaid drew it before, name the previous theme and look in its front matter:\n\n```yaml\n---\nconfig:\n theme: default\n look: classic\n---\n```\n\nFor every diagram on a page, pass the same two keys to `mermaid.initialize()`:\n\n```javascript\nmermaid.initialize({ theme: 'default', look: 'classic' });\n```\n\n## Site-wide Theme\n\nTo customize themes site-wide, call the `initialize` method on the `mermaid`.\n\nExample of `initialize` call setting `theme` to `base`:\n\n```javascript\nmermaid.initialize({\n securityLevel: 'loose',\n theme: 'base',\n});\n```\n\n## Diagram-specific Themes\n\nTo customize the theme of an individual diagram, use frontmatter config.\n\nExample of frontmatter config setting the `theme` to `forest`:\n\n```mermaid-example\n---\nconfig:\n theme: 'forest'\n---\n graph TD\n a --> b\n```\n\n> **Reminder**: the only theme that can be customized is the `base` theme. The following section covers how to use `themeVariables` for customizations.\n\n## Customizing Themes with `themeVariables`\n\nTo make a custom theme, modify `themeVariables` via frontmatter config.\n\nYou will need to use the [base](#available-themes) theme as it is the only modifiable theme.\n\n| Parameter | Description | Type | Properties |\n| -------------- | ---------------------------------- | ------ | ----------------------------------------------------------------------------------- |\n| themeVariables | Modifiable with frontmatter config | Object | `primaryColor`, `primaryTextColor`, `lineColor` ([see full list](#theme-variables)) |\n\nExample of modifying `themeVariables` using frontmatter config:\n\n```mermaid-example\n---\nconfig:\n theme: 'base'\n themeVariables:\n primaryColor: '#BB2528'\n primaryTextColor: '#fff'\n primaryBorderColor: '#7C0000'\n lineColor: '#F8B229'\n secondaryColor: '#006100'\n tertiaryColor: '#fff'\n---\n graph TD\n A[Christmas] -->|Get money| B(Go shopping)\n B --> C{Let me think}\n B --> G[/Another/]\n C ==>|One| D[Laptop]\n C -->|Two| E[iPhone]\n C -->|Three| F[fa:fa-car Car]\n subgraph section\n C\n D\n E\n F\n G\n end\n```\n\n## Color and Color Calculation\n\nTo ensure diagram readability, the default value of certain variables is calculated or derived from other variables. For example, `primaryBorderColor` is derived from the `primaryColor` variable. So if the `primaryColor` variable is customized, Mermaid will adjust `primaryBorderColor` automatically. Adjustments can mean a color inversion, a hue change, a darkening/lightening by 10%, etc.\n\nThe theming engine will only recognize hex colors and not color names. So, the value `#ff0000` will work, but `red` will not.\n\n## Theme Variables\n\n| Variable | Default value | Description |\n| -------------------- | ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |\n| darkMode | false | Affects how derived colors are calculated. Set value to `true` for dark mode. |\n| background | #f4f4f4 | Used to calculate color for items that should either be background colored or contrasting to the background |\n| fontFamily | trebuchet ms, verdana, arial | Font family for diagram text |\n| fontSize | 16px | Font size in pixels |\n| primaryColor | #fff4dd | Color to be used as background in nodes, other colors will be derived from this |\n| primaryTextColor | calculated from darkMode #ddd/#333 | Color to be used as text color in nodes using `primaryColor` |\n| secondaryColor | calculated from primaryColor | |\n| primaryBorderColor | calculated from primaryColor | Color to be used as border in nodes using `primaryColor` |\n| secondaryBorderColor | calculated from secondaryColor | Color to be used as border in nodes using `secondaryColor` |\n| secondaryTextColor | calculated from secondaryColor | Color to be used as text color in nodes using `secondaryColor` |\n| tertiaryColor | calculated from primaryColor | |\n| tertiaryBorderColor | calculated from tertiaryColor | Color to be used as border in nodes using `tertiaryColor` |\n| tertiaryTextColor | calculated from tertiaryColor | Color to be used as text color in nodes using `tertiaryColor` |\n| noteBkgColor | #fff5ad | Color used as background in notes |\n| noteTextColor | #333 | Text color in note rectangles |\n| noteBorderColor | calculated from noteBkgColor | Border color in note rectangles |\n| lineColor | calculated from background | |\n| textColor | calculated from primaryTextColor | Text in diagram over the background for instance text on labels and on signals in sequence diagram or the title in Gantt diagram |\n| mainBkg | calculated from primaryColor | Background in flowchart objects like rects/circles, class diagram classes, sequence diagram etc |\n| errorBkgColor | tertiaryColor | Color for syntax error message |\n| errorTextColor | tertiaryTextColor | Color for syntax error message |\n\n## Flowchart Variables\n\n| Variable | Default value | Description |\n| ------------------- | ------------------------------ | --------------------------- |\n| nodeBorder | primaryBorderColor | Node Border Color |\n| clusterBkg | tertiaryColor | Background in subgraphs |\n| clusterBorder | tertiaryBorderColor | Cluster Border Color |\n| defaultLinkColor | lineColor | Link Color |\n| titleColor | tertiaryTextColor | Title Color |\n| edgeLabelBackground | calculated from secondaryColor | |\n| nodeTextColor | primaryTextColor | Color for text inside Nodes |\n\n## Sequence Diagram Variables\n\n| Variable | Default value | Description |\n| --------------------- | ------------------------------ | --------------------------- |\n| actorBkg | mainBkg | Actor Background Color |\n| actorBorder | primaryBorderColor | Actor Border Color |\n| actorTextColor | primaryTextColor | Actor Text Color |\n| actorLineColor | actorBorder | Actor Line Color |\n| signalColor | textColor | Signal Color |\n| signalTextColor | textColor | Signal Text Color |\n| labelBoxBkgColor | actorBkg | Label Box Background Color |\n| labelBoxBorderColor | actorBorder | Label Box Border Color |\n| labelTextColor | actorTextColor | Label Text Color |\n| loopTextColor | actorTextColor | Loop Text Color |\n| activationBorderColor | calculated from secondaryColor | Activation Border Color |\n| activationBkgColor | secondaryColor | Activation Background Color |\n| sequenceNumberColor | calculated from lineColor | Sequence Number Color |\n\n## Pie Diagram Variables\n\n| Variable | Default value | Description |\n| ------------------- | ------------------------------ | ------------------------------------------ |\n| pie1 | primaryColor | Fill for 1st section in pie diagram |\n| pie2 | secondaryColor | Fill for 2nd section in pie diagram |\n| pie3 | calculated from tertiary | Fill for 3rd section in pie diagram |\n| pie4 | calculated from primaryColor | Fill for 4th section in pie diagram |\n| pie5 | calculated from secondaryColor | Fill for 5th section in pie diagram |\n| pie6 | calculated from tertiaryColor | Fill for 6th section in pie diagram |\n| pie7 | calculated from primaryColor | Fill for 7th section in pie diagram |\n| pie8 | calculated from primaryColor | Fill for 8th section in pie diagram |\n| pie9 | calculated from primaryColor | Fill for 9th section in pie diagram |\n| pie10 | calculated from primaryColor | Fill for 10th section in pie diagram |\n| pie11 | calculated from primaryColor | Fill for 11th section in pie diagram |\n| pie12 | calculated from primaryColor | Fill for 12th section in pie diagram |\n| pieTitleTextSize | 25px | Title text size |\n| pieTitleTextColor | taskTextDarkColor | Title text color |\n| pieSectionTextSize | 17px | Text size of individual section labels |\n| pieSectionTextColor | textColor | Text color of individual section labels |\n| pieLegendTextSize | 17px | Text size of labels in diagram legend |\n| pieLegendTextColor | taskTextDarkColor | Text color of labels in diagram legend |\n| pieStrokeColor | black | Border color of individual pie sections |\n| pieStrokeWidth | 2px | Border width of individual pie sections |\n| pieOuterStrokeWidth | 2px | Border width of pie diagram's outer circle |\n| pieOuterStrokeColor | black | Border color of pie diagram's outer circle |\n| pieOpacity | 0.7 | Opacity of individual pie sections |\n\n## State Colors\n\n| Variable | Default value | Description |\n| ------------- | ---------------- | -------------------------------------------- |\n| labelColor | primaryTextColor | |\n| altBackground | tertiaryColor | Used for background in deep composite states |\n\n## Class Colors\n\n| Variable | Default value | Description |\n| --------- | ------------- | ------------------------------- |\n| classText | textColor | Color of Text in class diagrams |\n\n## User Journey Colors\n\n| Variable | Default value | Description |\n| --------- | ------------------------------ | --------------------------------------- |\n| fillType0 | primaryColor | Fill for 1st section in journey diagram |\n| fillType1 | secondaryColor | Fill for 2nd section in journey diagram |\n| fillType2 | calculated from primaryColor | Fill for 3rd section in journey diagram |\n| fillType3 | calculated from secondaryColor | Fill for 4th section in journey diagram |\n| fillType4 | calculated from primaryColor | Fill for 5th section in journey diagram |\n| fillType5 | calculated from secondaryColor | Fill for 6th section in journey diagram |\n| fillType6 | calculated from primaryColor | Fill for 7th section in journey diagram |\n| fillType7 | calculated from secondaryColor | Fill for 8th section in journey diagram |\n","packages/mermaid/src/docs/config/tidy-tree.md":"# Tidy-tree Layout\n\nThe **tidy-tree** layout arranges nodes in a hierarchical, tree-like structure. It is especially useful for diagrams where parent-child relationships are important, such as mindmaps.\n\n## Features\n\n- Organizes nodes in a tidy, non-overlapping tree\n- Ideal for mindmaps and hierarchical data\n- Automatically adjusts spacing for readability\n\n## Example Usage\n\n```mermaid-example\n---\nconfig:\n layout: tidy-tree\n---\nmindmap\nroot((mindmap is a long thing))\n A\n B\n C\n D\n```\n\n```mermaid-example\n---\nconfig:\n layout: tidy-tree\n---\nmindmap\nroot((mindmap))\n Origins\n Long history\n ::icon(fa fa-book)\n Popularisation\n British popular psychology author Tony Buzan\n Research\n On effectiveness
and features\n On Automatic creation\n Uses\n Creative techniques\n Strategic planning\n Argument mapping\n```\n\n## Note\n\n- Currently, tidy-tree is primarily supported for mindmap diagrams.\n","packages/mermaid/src/docs/config/usage.md":"# Usage\n\nMermaid is a JavaScript tool that makes use of a Markdown based syntax to render customizable diagrams, charts and visualizations.\n\nDiagrams can be re-rendered/modified by modifying their descriptions.\n\n### CDN\n\n[https://www.jsdelivr.com/package/npm/mermaid](https://www.jsdelivr.com/package/npm/mermaid)\n\nPlease note that you can switch versions through the dropdown box at the top right.\n\n## Using mermaid\n\nFor the majority of users, Using the [Live Editor](https://mermaid.live/) would be sufficient, however you may also opt to deploy mermaid as a dependency or using the [Mermaid API](./setup/README.md).\n\nWe have compiled some Video [Tutorials](../ecosystem/tutorials.md) on how to use the Mermaid Live Editor.\n\n### Installing and Hosting Mermaid on a Webpage\n\n**Using the npm package:**\n\nRequirements:\n\n- Node.js >= 22.12.0\n\n### Supported browsers and runtimes\n\nMermaid v12.0.0+'s published bundles target ES2024 and are aimed to support Safari 17.4 or later.\n\nWe run linting for Chromium 121 and Firefox 123 support as well, but unlike Safari 17.4, we don't commit to supporting these outdated versions.\n\nOlder browsers may work too, or you may need to polyfill/transpile mermaid to support them.\n\n```bash\n# NPM\nnpm install mermaid\n# Yarn\nyarn add mermaid\n# PNPM\npnpm add mermaid\n```\n\n**Hosting mermaid on a web page:**\n\n> Note: This topic is explored in greater depth in the [User Guide for Beginners](../intro/getting-started.md)\n\nThe easiest way to integrate mermaid on a web page requires two elements:\n\n- A graph definition, inside `
` tags labeled `class=mermaid`.\n\nExample:\n\n```html\n
\n    graph LR\n    A --- B\n    B-->C[fa:fa-ban forbidden]\n    B-->D(fa:fa-spinner);\n
\n```\n\n- The mermaid js script. Added using a `script` tag as an ESM import.\n\nExample:\n\n```html\n\n```\n\n**Following these directions, mermaid starts at page load and (when the page has loaded) it will locate the graph definitions inside the `pre` tags with `class=\"mermaid\"` and return diagrams in SVG form, following given definitions.**\n\n### Fonts\n\nMermaid currently uses a few different default `fontFamily` settings, based on\nthe diagram type and the given theme.\n\nThe current preferred fonts are:\n\n- Recursive Variable (open-source font, since v11.15.0)\n- Open Sans (open-source font)\n- Arial ([Restrictive License](https://en.wikipedia.org/wiki/TrueType_core_fonts_for_the_Web))\n- Trebuchet MS ([Restrictive License](https://en.wikipedia.org/wiki/TrueType_core_fonts_for_the_Web))\n\nFor a consistent look, we recommend you supply these as web fonts, when possible,\ne.g. like:\n\n```html\n/@fontsource/open-sans@5/400.css\" />\n/@fontsource/open-sans@5/400-italic.css\" />\n/@fontsource-variable/recursive@5/index.css\" />\n```\n\n## Simple full example:\n\n```html\n\n\n  /@fontsource/open-sans@5/400.css\" />\n  /@fontsource/open-sans@5/400-italic.css\" />\n  /@fontsource-variable/recursive@5/index.css\" />\n\n\n  \n    
\n  graph LR\n      A --- B\n      B-->C[fa:fa-ban forbidden]\n      B-->D(fa:fa-spinner);\n    
\n    \n  \n\n```\n\n## Notes:\n\nAn id attribute is also added to mermaid tags without one.\n\nMermaid can load multiple diagrams, in the same page.\n\n> Try it out, save this code as HTML and load it using any browser.\n> (Except Internet Explorer, please don't use Internet Explorer.)\n\n## Tiny Mermaid\n\nWe offer a smaller version of Mermaid that's approximately half the size of the full library. This tiny version doesn't include Mindmap Diagrams, Architecture Diagrams, KaTeX rendering, lazy loading, or the ELK layout engine.\n\nIf you need a more lightweight version without these features, you can use [Mermaid Tiny](https://github.com/mermaid-js/mermaid/tree/develop/packages/tiny).\n\n### ELK and the tiny build\n\nThe tiny build has never included ELK, and still doesn't — it is a large dependency and staying small is the point of that build. Diagrams that ask for an ELK layout here fall back to Dagre and still render; nothing breaks, they are simply laid out by Dagre.\n\nWhat changed in v12.0.0 is the main package, not this one: ELK used to be an opt-in `@mermaid-js/layout-elk` install, and is now bundled with `mermaid` and used by default. So **if you want a Mermaid without ELK, the tiny build is the way to get one** — it is no longer simply a matter of not installing the layout package.\n\nIf you want the tiny build _and_ ELK, register `@mermaid-js/layout-elk` alongside it. That package continues to be published for exactly this case:\n\n```html\n\n\n```\n\nRegistering the package also makes the named ELK algorithms available — `elk.stress`, `elk.force`, `elk.mrtree`, `elk.sporeOverlap`, `elk.box` and `elk.rectpacking`. On a normal `mermaid` build you do not need this package at all: registering it is harmless but redundant, since the same layouts are already built in.\n\n## Enabling Click Event and Tags in Nodes\n\nA `securityLevel` configuration has to first be cleared. `securityLevel` sets the level of trust for the parsed diagrams and limits click functionality. This was introduced in version 8.2 as a security improvement, aimed at preventing malicious use.\n\n**It is the site owner's responsibility to discriminate between trustworthy and untrustworthy user-bases and we encourage the use of discretion.**\n\n## securityLevel\n\n| Parameter     | Description                       | Type   | Required | Values                                     |\n| ------------- | --------------------------------- | ------ | -------- | ------------------------------------------ |\n| securityLevel | Level of trust for parsed diagram | String | Optional | 'sandbox', 'strict', 'loose', 'antiscript' |\n\nValues:\n\n- **strict**: (**default**) HTML tags in the text are encoded and click functionality is disabled.\n- **antiscript**: HTML tags in text are allowed (only script elements are removed) and click functionality is enabled.\n- **loose**: HTML tags in text are allowed and click functionality is enabled.\n- **sandbox**: With this security level, all rendering takes place in a sandboxed iframe. This prevents any JavaScript from running in the context. This may hinder interactive functionality of the diagram, like scripts, popups in the sequence diagram, links to other tabs or targets, etc.\n\n```note\nThis changes the default behaviour of mermaid so that after upgrade to 8.2, unless the `securityLevel` is not changed, tags in flowcharts are encoded as tags and clicking is disabled.\n**sandbox** security level is still in the beta version.\n```\n\n**If you are taking responsibility for the diagram source security you can set the `securityLevel` to a value of your choosing. This allows clicks and tags are allowed.**\n\n**To change `securityLevel`, you have to call `mermaid.initialize`:**\n\n```javascript\nmermaid.initialize({\n  securityLevel: 'loose',\n});\n```\n\n### Labels out of bounds\n\nIf you use dynamically loaded fonts that are loaded through CSS, such as fonts, mermaid should wait for the whole page to load (dom + assets, particularly the fonts file).\n\n```javascript\n$(document).ready(function () {\n  mermaid.initialize();\n});\n```\n\nNot doing so will most likely result in mermaid rendering graphs that have labels out of bounds. The default integration in mermaid uses the window.load event to start rendering.\n\nIf your page has other fonts in its body those might be used instead of the mermaid font. Specifying the font in your styling is a workaround for this.\n\n```css\npre.mermaid {\n  font-family: 'trebuchet ms', verdana, arial;\n}\n```\n\n### Using `mermaid.run`\n\nmermaid.run was added in v10 and is the preferred way of handling more complex integration.\nBy default, `mermaid.run` will be called when the document is ready, rendering all elements with `class=\"mermaid\"`.\n\nYou can customize that behavior by calling `await mermaid.run()`.\n\n`mermaid.initialize({startOnLoad: false})` will prevent `mermaid.run` from being called automatically after load.\n\nRender all elements with querySelector \".someOtherClass\"\n\n```js\nmermaid.initialize({ startOnLoad: false });\nawait mermaid.run({\n  querySelector: '.someOtherClass',\n});\n```\n\nRender all elements passed as an array\n\n```js\nmermaid.initialize({ startOnLoad: false });\nawait mermaid.run({\n  nodes: [document.getElementById('someId'), document.getElementById('anotherId')],\n});\nawait mermaid.run({\n  nodes: document.querySelectorAll('.yetAnotherClass'),\n});\n```\n\nRender all `.mermaid` elements while suppressing any error\n\n```js\nmermaid.initialize({ startOnLoad: false });\nawait mermaid.run({\n  suppressErrors: true,\n});\n```\n\n### Calling `mermaid.init` - Deprecated\n\n```warning\nmermaid.init is deprecated in v10 and will be removed in a future release. Please use mermaid.run instead.\n```\n\nBy default, `mermaid.init` will be called when the document is ready, finding all elements with\n`class=\"mermaid\"`. If you are adding content after mermaid is loaded, or otherwise need\nfiner-grained control of this behavior, you can call `init` yourself with:\n\n- a configuration object\n- some nodes, as\n  - a node\n  - an array-like of nodes\n  - or W3C selector that will find your nodes\n\nExample:\n\n```javascript\nmermaid.init({ noteMargin: 10 }, '.someOtherClass');\n```\n\nOr with no config object, and a jQuery selection:\n\n```javascript\nmermaid.init(undefined, $('#someId .yetAnotherClass'));\n```\n\n## Usage with webpack\n\nmermaid fully supports webpack. Here is a [working demo](https://github.com/mermaidjs/mermaid-webpack-demo).\n\n## API usage\n\nThe main idea of the API is to be able to call a render function with the graph definition as a string. The render function will render the graph and call a callback with the resulting SVG code. With this approach it is up to the site creator to fetch the graph definition from the site (perhaps from a textarea), render it and place the graph somewhere in the site.\n\nThe example below shows an example of how this could be used. The example just logs the resulting SVG to the JavaScript console.\n\n```html\n\n```\n\nTo determine the type of diagram present in a given text, you can utilize the `mermaid.detectType` function, as demonstrated in the example below.\n\n```html\n\n```\n\n### Binding events\n\nSometimes the generated graph also has defined interactions like tooltip and click events. When using the API one must\nadd those events after the graph has been inserted into the DOM.\n\nThe example code below is an extract of what mermaid does when using the API. The example shows how it is possible to\nbind events to an SVG when using the API for rendering.\n\n```javascript\n// Example of using the bindFunctions\nconst drawDiagram = async function () {\n  element = document.querySelector('#graphDiv');\n  const graphDefinition = 'graph TB\\na-->b';\n  const { svg, bindFunctions } = await mermaid.render('graphDiv', graphDefinition);\n  element.innerHTML = svg;\n  // This can also be written as `bindFunctions?.(element);` using the `?` shorthand.\n  if (bindFunctions) {\n    bindFunctions(element);\n  }\n};\n```\n\n1. The graph is generated using the render call.\n2. After generation the render function calls the provided callback function, in this case it's called insertSvg.\n3. The callback function is called with two parameters, the SVG code of the generated graph and a function. This function binds events to the SVG **after** it is inserted into the DOM.\n4. Insert the SVG code into the DOM for presentation.\n5. Call the binding function that binds the events.\n\n## Example of a marked renderer\n\nThis is the renderer used for transforming the documentation from Markdown to html with mermaid diagrams in the html.\n\n```javascript\nconst renderer = new marked.Renderer();\nrenderer.code = function (code, language) {\n  if (code.match(/^sequenceDiagram/) || code.match(/^graph/)) {\n    return '
' + code + '
';\n  } else {\n    return '
' + code + '
';\n  }\n};\n```\n\nAnother example in CoffeeScript that also includes the mermaid script tag in the generated markup.\n\n```coffee\nmarked = require 'marked'\n\nmodule.exports = (options) ->\n  hasMermaid = false\n  renderer = new marked.Renderer()\n  renderer.defaultCode = renderer.code\n  renderer.code = (code, language) ->\n    if language is 'mermaid'\n      html = ''\n      if not hasMermaid\n        hasMermaid = true\n        html += ''\n      html + '
'+code+'
'\n    else\n      @defaultCode(code, language)\n\n  renderer\n```\n\n## Advanced usage\n\n### Syntax validation without rendering\n\nThe `mermaid.parse(text, parseOptions)` function validates graph definitions without rendering a graph.\n\nThe function `mermaid.parse(text, parseOptions)`, takes a text string as an argument and returns `{ diagramType: string }` if the definition follows mermaid's syntax.\n\nIf the definition is invalid, the function returns `false` if `parseOptions.suppressErrors` is set to `true`. Otherwise, it throws an error.\n\nThe parseError function will be called when the parse function throws an error. It will not be called if `parseOptions.suppressErrors` is set to `true`.\n\nIt is possible to override this function in order to handle the error in an application-specific way.\n\nThe code-example below in meta code illustrates how this could work:\n\n```javascript\nmermaid.parseError = function (err, hash) {\n  displayErrorInGui(err);\n};\n\nconst textFieldUpdated = async function () {\n  const textStr = getTextFromFormField('code');\n\n  if (await mermaid.parse(textStr)) {\n    reRender(textStr);\n  }\n};\n\nbindEventHandler('change', 'code', textFieldUpdated);\n```\n\n## Configuration\n\nYou can pass the required configuration to the `mermaid.initialize` call. This is the preferred way of configuring mermaid.\nThe list of configuration objects are described [in the mermaidAPI documentation](./setup/README.md).\n\n```html\n\n```\n\n```note\nThis is the preferred way of configuring mermaid.\n```\n\n### The following methods are deprecated and are kept only for backwards compatibility.\n\n## Using the mermaid object\n\nIt is possible to set some configuration via the mermaid object. The two parameters that are supported using this\napproach are:\n\n- mermaid.startOnLoad\n- mermaid.htmlLabels\n\n```javascript\nmermaid.startOnLoad = true;\n```\n\n```warning\nThis way of setting the configuration is deprecated. Instead the preferred way is to use the initialize method. This functionality is only kept for backwards compatibility.\n```\n\n\n","packages/mermaid/src/docs/ecosystem/integrations-community.md":"# Integrations\n\n## Official integration\n\n### Mermaid Chart\n\nMermaid Chart is built by the team behind Mermaid JS.\n\nFor more details, visit the [Mermaid Chart page](./mermaid-chart.md), or visit the [Mermaid Chart website](https://mermaid.ai) .\n\n## Community integrations\n\nWe're excited about the growth of the Mermaid community, and the number of plugins and integrations that have been created by the community.\n\nSee the list below of community plugins and integrations created with Mermaid.\n\n```note\nA ✅ indicates Native support for Mermaid on the respective platform.\n```\n\nTo add an integration to this list, see the [Integrations - create page](./integrations-create.md).\n\n### Productivity tools\n\n- [Atlassian Products](https://www.atlassian.com)\n  - [Mermaid for Confluence](https://marketplace.atlassian.com/apps/1224722/mermaid-for-confluence?hosting=cloud&tab=overview)\n  - [Mermaid Integration for Confluence](https://marketplace.atlassian.com/apps/1222792/mermaid-integration-for-confluence?hosting=cloud&tab=overview)\n  - [Mermaid Charts & Diagrams for Confluence](https://marketplace.atlassian.com/apps/1222572/)\n  - [Mermaid Diagrams for Confluence](https://marketplace.atlassian.com/apps/1226945/mermaid-diagrams-for-confluence?hosting=cloud&tab=overview)\n  - [Mermaid Live Editor for Confluence Cloud](https://marketplace.atlassian.com/apps/1231571/mermaid-live-editor-for-confluence?hosting=cloud&tab=overview)\n  - [Mermaid Macro for Confluence](https://marketplace.atlassian.com/apps/1231150/mermaid-macro-for-confluence?hosting=cloud&tab=overview)\n  - [Mermaid Plugin for Confluence](https://marketplace.atlassian.com/apps/1214124/mermaid-plugin-for-confluence?hosting=server&tab=overview)\n  - [EliteSoft Mermaid Charts and Diagrams](https://marketplace.atlassian.com/apps/1227286/elitesoft-mermaid-charts-and-diagrams?hosting=cloud&tab=overview)\n  - [Auto convert diagrams in Jira](https://github.com/coddingtonbear/jirafs-mermaid)\n  - [Mermaid Charts & Diagrams for Jira](https://marketplace.atlassian.com/apps/1224537/)\n  - [Mermaid for Jira Cloud - Draw UML diagrams easily](https://marketplace.atlassian.com/apps/1223053/mermaid-for-jira-cloud-draw-uml-diagrams-easily?hosting=cloud&tab=overview)\n  - [CloudScript.io Mermaid Addon](https://marketplace.atlassian.com/apps/1219878/cloudscript-io-mermaid-addon?hosting=cloud&tab=overview)\n  - [Mermaid plus for Confluence](https://marketplace.atlassian.com/apps/1236814/mermaid-plus-for-confluence?hosting=cloud&tab=overview)\n- [Azure Devops](https://learn.microsoft.com/en-us/azure/devops/project/wiki/markdown-guidance?view=azure-devops#add-mermaid-diagrams-to-a-wiki-page) ✅\n- [Deepdwn](https://billiam.itch.io/deepdwn) ✅\n- [Doctave](https://www.doctave.com/) ✅\n  - [Mermaid in Markdown code blocks](https://docs.doctave.com/components/mermaid) ✅\n- [Forgejo](https://forgejo.org/) ✅\n- [GitBook](https://gitbook.com)\n  - [Mermaid Plugin](https://github.com/JozoVilcek/gitbook-plugin-mermaid)\n  - [Markdown with Mermaid CLI](https://github.com/miao1007/gitbook-plugin-mermaid-cli)\n- [Gitea](https://gitea.io) ✅\n- [GitHub](https://github.com) ✅\n  - [Using code blocks](https://github.blog/2022-02-14-include-diagrams-markdown-files-mermaid/) ✅\n  - [GitHub action: Compile mermaid to image](https://github.com/neenjaw/compile-mermaid-markdown-action)\n  - [GitHub Writer](https://github.com/ckeditor/github-writer)\n  - [SVG diagram generator](https://github.com/SimonKenyonShepard/mermaidjs-github-svg-generator)\n- [GitLab](https://docs.gitlab.com/ee/user/markdown.html#diagrams-and-flowcharts) ✅\n- [GNU Octave](https://octave.org/) ✅\n  - [octave_mermaid_js](https://github.com/CNOCTAVE/octave_mermaid_js) ✅\n- [HackMD](https://hackmd.io/c/tutorials/%2F%40docs%2Fflowchart-en#Create-more-complex-flowcharts) ✅\n- [JetBrains IDEs](https://www.jetbrains.com)\n  - [Mermaid Plugin](https://plugins.jetbrains.com/plugin/20146-mermaid)\n  - [Mermaid Studio](https://plugins.jetbrains.com/plugin/29870-mermaid-studio)\n- [MonsterWriter](https://www.monsterwriter.com/) ✅\n- [Joplin](https://joplinapp.org) ✅\n- [LiveBook](https://livebook.dev) ✅\n- [Slidev](https://sli.dev) ✅\n- [Tuleap](https://docs.tuleap.org/user-guide/writing-in-tuleap.html#graphs) ✅\n- [Mermaid Flow Visual Editor](https://www.mermaidflow.app) ✅\n- [Mermaid Studio by webtoolz](https://webtoolz.dev/mermaid) - Browser-based Mermaid editor with live preview, curated themes, and PNG/SVG export\n- [Mermerd](https://github.com/KarnerTh/mermerd)\n- [Slab](https://slab.com) ✅\n- [Swimm](https://docs.swimm.io/features/diagrams-and-charts) ✅\n- [NotesHub](https://noteshub.app) ✅\n- [Notion](https://notion.so) ✅\n- [Observable](https://observablehq.com/@observablehq/mermaid) ✅\n- [Obsidian](https://help.obsidian.md/Editing+and+formatting/Advanced+formatting+syntax#Diagram) ✅\n- [Outline](https://docs.getoutline.com/s/guide/doc/diagrams-KQiKoT4wzK) ✅\n- [Redmine](https://redmine.org)\n  - [Mermaid Macro](https://redmine.org/plugins/redmine_mermaid_macro)\n  - [Markdown for mermaid plugin](https://github.com/jamieh-mongolian/markdown-for-mermaid-plugin)\n  - [redmine-mermaid](https://github.com/styz/redmine_mermaid)\n- Visual Studio Code [Polyglot Interactive Notebooks](https://github.com/dotnet/interactive#net-interactive)\n- [Microsoft Loop](https://loop.cloud.microsoft) ✅\n\n### LLM integrations\n\nLLM integrations to create mermaid diagrams using AI from text descriptions.\n\n- [HueHive - Create mermaid diagrams with text](https://huehive.co/tools/diagrams)\n- [MCP Server Mermaid](https://github.com/hustcc/mcp-mermaid) - Generate mermaid diagram and chart with AI MCP dynamically.\n- [Mermaid Studio](https://mermaidstudio.dev) - Leverage Mermaid Studio's code intelligence and diagram generation capabilities via MCP to create high-quality diagrams (requires a [JetBrains IDE](https://jetbrains.com/ides)) using your favorite coding agent.\n\n### CRM/ERP\n\nCustomer Relationship Management/Enterprise Resource Planning\n\n- [coreBOS](https://blog.corebos.org/blog/december2019)\n\n### Blogging\n\nBlogging frameworks and platforms\n\n- [Hexo](https://hexo.io)\n  - [hexo-filter-mermaid-diagrams](https://github.com/webappdevelp/hexo-filter-mermaid-diagrams)\n  - [hexo-tag-mermaid](https://github.com/JameChou/hexo-tag-mermaid)\n  - [hexo-mermaid-diagrams](https://github.com/mslxl/hexo-mermaid-diagrams)\n- [Nextra](https://nextra.site/)\n  - [Mermaid](https://nextra.site/docs/guide/mermaid)\n- [WordPress](https://wordpress.org)\n  - [MerPRess](https://wordpress.org/plugins/merpress/)\n  - [WP Documentation](https://wordpress.org/themes/wp-documentation/)\n\n### CMS/ECM\n\nContent Management Systems/Enterprise Content Management\n\n- [ApostropheCMS](https://apostrophecms.com/)\n  - [Extension for Mermaid.js](https://github.com/BoDonkey/mermaid-extension)\n- [Drupal](https://drupal.org/)\n  - [Mermaid Diagram Field module](https://www.drupal.org/project/mermaid_diagram_field)\n- [Grav CMS](https://getgrav.org/)\n  - [Mermaid Diagrams Plugin](https://github.com/DanielFlaum/grav-plugin-mermaid-diagrams)\n  - [GitLab Markdown Adapter](https://github.com/Goutte/grav-plugin-gitlab-markdown-adapter)\n- [Tiki Wiki CMS Groupware](https://tiki.org)\n  - [Tracker Entity Relationship Diagram](https://doc.tiki.org/Tracker-Entity-Relationship-Diagram)\n- [VitePress](https://vitepress.vuejs.org/)\n  - [Plugin for Mermaid.js](https://emersonbottero.github.io/vitepress-plugin-mermaid/)\n- [VuePress](https://vuepress.vuejs.org/)\n  - [Plugin for Mermaid.js](https://github.com/eFrane/vuepress-plugin-mermaidjs)\n\n### Communication\n\nCommunication tools and platforms\n\n- [Discourse](https://discourse.org)\n  - [Mermaid Plugin](https://github.com/pnewell/discourse-mermaid)\n- [Mattermost](https://mattermost.com/)\n  - [Mermaid Plugin](https://github.com/SpikeTings/Mermaid)\n- [NodeBB](https://nodebb.org)\n  - [Mermaid Parser Plugin](https://www.npmjs.com/package/nodebb-plugin-mermaid)\n- [phpBB](https://phpbb.com)\n  - [phpbb-ext-mermaid](https://github.com/AlfredoRamos/phpbb-ext-mermaid)\n- [Slack](https://slack.com)\n  - [Mermaid Preview](https://mermaid-preview.com)\n\n### Wikis\n\n- [DokuWiki](https://dokuwiki.org)\n  - [ComboStrap](https://combostrap.com/utility/create-diagram-with-mermaid-vh3ab9yj)\n  - [Mermaid Plugin](https://www.dokuwiki.org/plugin:mermaid)\n- [Foswiki](https://foswiki.org)\n  - [Mermaid Plugin](https://foswiki.org/Extensions/MermaidPlugin)\n- [MediaWiki](https://www.mediawiki.org)\n  - [Flex Diagrams Extension](https://www.mediawiki.org/wiki/Extension:Flex_Diagrams)\n  - [Mermaid Extension](https://www.mediawiki.org/wiki/Extension:Mermaid)\n- [PmWiki](https://www.pmwiki.org)\n  - [MermaidJs Cookbook recipe](https://www.pmwiki.org/wiki/Cookbook/MermaidJs)\n- [Semantic Media Wiki](https://www.semantic-mediawiki.org)\n  - [Mermaid Plugin](https://github.com/SemanticMediaWiki/Mermaid)\n- [TiddlyWiki](https://tiddlywiki.com/)\n  - [mermaid-tw5: wrapper for Mermaid Live](https://github.com/efurlanm/mermaid-tw5)\n  - [tw5-mermaid: plugin for managing Mermaid.js tiddlers](https://github.com/jasonmhoule/tw5-mermaid)\n\n### Editor Plugins\n\n- Atom _(Atom has been [archived.](https://github.blog/2022-06-08-sunsetting-atom/))_\n  - [Markdown Preview Enhanced](https://github.com/shd101wyy/markdown-preview-enhanced)\n  - [Atom Mermaid](https://github.com/y-takey/atom-mermaid)\n  - [Language Mermaid Syntax Highlighter](https://github.com/ytisf/language-mermaid)\n- [Astah](https://astah.net)\n  - [Export to Mermaid](https://github.com/Avens666/Astah_Jude_UML_export_to_Markdown-mermaid-Plantuml-)\n- [Brackets](https://brackets.io/)\n  - [Mermaid Preview](https://github.com/AlanHohn/mermaid-preview)\n- [CKEditor](https://github.com/ckeditor/ckeditor5)\n  - [CKEditor 5 Mermaid plugin](https://github.com/ckeditor/ckeditor5-mermaid)\n- [Draw.io](https://draw.io)\n  - [Mermaid Plugin](https://github.com/nopeslide/drawio_mermaid_plugin)\n- [GNU Emacs](https://www.gnu.org/software/emacs/)\n  - [Major mode for .mmd files](https://github.com/abrochard/mermaid-mode)\n  - [Org-Mode integration](https://github.com/arnm/ob-mermaid)\n- [GNU Nano](https://www.nano-editor.org/)\n  - [Nano Mermaid](https://github.com/Yash-Singh1/nano-mermaid)\n- [Google docs](https://docs.google.com/)\n  - [Mermaid plugin for google docs](https://workspace.google.com/marketplace/app/mermaid/636321283856)\n- [Inkdrop](https://www.inkdrop.app)\n  - [Mermaid Plugin](https://github.com/inkdropapp/inkdrop-mermaid)\n- [IntelliJ Idea](https://www.jetbrains.com/idea/)\n  - [Mermaid Visualizer](https://plugins.jetbrains.com/plugin/30432-mermaid-visualizer)\n- [Light Table](http://lighttable.com/)\n  - [Mermaid Plugin](https://github.com/cldwalker/Mermaid)\n- [Markdown-It](https://github.com/markdown-it/markdown-it)\n  - [Textual UML Parser](https://github.com/manastalukdar/markdown-it-textual-uml)\n  - [Mermaid Plugin](https://github.com/tylingsoft/markdown-it-mermaid)\n  - [md-it-mermaid](https://github.com/iamcco/md-it-mermaid)\n  - [markdown-it-mermaid-less](https://github.com/searKing/markdown-it-mermaid-less)\n- [Podlite](https://github.com/zag/podlite-desktop)\n  - [=Diagram block](https://github.com/zag/podlite/tree/main/packages/podlite-diagrams)\n- [Standard Notes](https://standardnotes.com/)\n  - [Mermaid Extension](https://github.com/nienow/sn-mermaid)\n- [VS Code](https://code.visualstudio.com/)\n  - [Mermaid Editor](https://marketplace.visualstudio.com/items?itemName=tomoyukim.vscode-mermaid-editor)\n  - [Mermaid Export](https://marketplace.visualstudio.com/items?itemName=Gruntfuggly.mermaid-export)\n  - [Markdown PDF](https://marketplace.visualstudio.com/items?itemName=yzane.markdown-pdf)\n  - [Markdown Preview Mermaid Support](https://marketplace.visualstudio.com/items?itemName=bierner.markdown-mermaid)\n  - [Markdown Preview Enhanced](https://marketplace.visualstudio.com/items?itemName=shd101wyy.markdown-preview-enhanced)\n  - [Mermaid Preview](https://marketplace.visualstudio.com/items?itemName=vstirbu.vscode-mermaid-preview)\n  - [Preview](https://marketplace.visualstudio.com/items?itemName=searKing.preview-vscode)\n  - [Preview Sequence Diagrams](https://marketplace.visualstudio.com/items?itemName=arichika.previewseqdiag-vscode)\n  - [Mermaid Markdown Syntax Highlighting](https://marketplace.visualstudio.com/items?itemName=bpruitt-goddard.mermaid-markdown-syntax-highlighting)\n- [Vim](https://www.vim.org)\n  - [Vim Diagram Syntax](https://github.com/zhaozg/vim-diagram)\n  - [Official Vim Syntax and ft plugin](https://github.com/craigmac/vim-mermaid)\n- [Zed](https://zed.dev)\n  - [zed-mermaid](https://github.com/gabeidx/zed-mermaid)\n\n### Document Generation\n\n- [Astro](https://astro.build/)\n  - [Adding diagrams to your Astro site with MermaidJS and Playwright](https://agramont.net/blog/diagraming-with-mermaidjs-astro/)\n- [Codedoc](https://codedoc.cc/)\n  - [codedoc-mermaid-plugin](https://www.npmjs.com/package/codedoc-mermaid-plugin)\n- [Docsy Hugo Theme](https://www.docsy.dev/docs/content/diagrams-and-formulae/) ✅\n- [Docusaurus](https://docusaurus.io/docs/markdown-features/diagrams) ✅\n- [Gatsby](https://www.gatsbyjs.com/)\n  - [gatsby-remark-mermaid](https://github.com/remcohaszing/gatsby-remark-mermaid)\n- [Jekyll](https://jekyllrb.com/)\n  - [jekyll-mermaid](https://rubygems.org/gems/jekyll-mermaid)\n  - [jekyll-mermaid-diagrams](https://github.com/fuzhibo/jekyll-mermaid-diagrams)\n- [JSDoc](https://jsdoc.app/)\n  - [jsdoc-mermaid](https://github.com/Jellyvision/jsdoc-mermaid)\n- [Madness](https://madness.dannyb.co/)\n- [mdBook](https://rust-lang.github.io/mdBook/index.html)\n  - [mdbook-mermaid](https://github.com/badboy/mdbook-mermaid)\n- [MkDocs](https://www.mkdocs.org)\n  - [mkdocs-mermaid2-plugin](https://github.com/fralau/mkdocs-mermaid2-plugin)\n  - [mkdocs-material](https://github.com/squidfunk/mkdocs-material), check the [docs](https://squidfunk.github.io/mkdocs-material/reference/diagrams/)\n- [Quarto](https://quarto.org/) ✅\n- [rehype](https://github.com/rehypejs/rehype)\n  - [rehype-mermaid](https://github.com/remcohaszing/rehype-mermaid)\n- [remark](https://remark.js.org/)\n  - [remark-mermaidjs](https://github.com/remcohaszing/remark-mermaidjs)\n- [Sphinx](https://www.sphinx-doc.org/en/master/)\n  - [sphinxcontrib-mermaid](https://github.com/mgaitan/sphinxcontrib-mermaid)\n- [Type Doc](https://typedoc.org/)\n  - [typedoc-plugin-mermaid](https://www.npmjs.com/package/typedoc-plugin-mermaid)\n- [Typora](https://support.typora.io/Draw-Diagrams-With-Markdown/#mermaid) ✅\n- [Unison programming language](https://www.unison-lang.org/docs/usage-topics/documentation/) ✅\n\n### Browser Extensions\n\n| Name                     | Chrome Web Store                                                                                            | Firefox Add-ons                                                                | Opera                                                                          | Edge                                                                                                                         | Source/Repository                                                                                    |\n| ------------------------ | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |\n| GitHub + Mermaid         | -                                                                                                           | [🦊🔗](https://addons.mozilla.org/firefox/addon/github-mermaid/)               | -                                                                              | -                                                                                                                            | [🐙🔗](https://github.com/BackMarket/github-mermaid-extension)                                       |\n| Asciidoctor Live Preview | [🎡🔗](https://chromewebstore.google.com/detail/asciidoctorjs-live-previe/iaalpfgpbocpdfblpnhhgllgbdbchmia) | -                                                                              | -                                                                              | [🌀🔗](https://microsoftedge.microsoft.com/addons/detail/asciidoctorjs-live-previ/pefkelkanablhjdekgdahplkccnbdggd?hl=en-US) | -                                                                                                    |\n| Diagram Tab              | -                                                                                                           | -                                                                              | -                                                                              | -                                                                                                                            | [🐙🔗](https://github.com/khafast/diagramtab)                                                        |\n| Markdown Diagrams        | [🎡🔗](https://chromewebstore.google.com/detail/markdown-diagrams/pmoglnmodacnbbofbgcagndelmgaclel)         | [🦊🔗](https://addons.mozilla.org/en-US/firefox/addon/markdown-diagrams/)      | -                                                                              | [🌀🔗](https://microsoftedge.microsoft.com/addons/detail/markdown-diagrams/hceenoomhhdkjjijnmlclkpenkapfihe)                 | [🐙🔗](https://github.com/marcozaccari/markdown-diagrams-browser-extension/tree/master/doc/examples) |\n| Markdown Viewer          | -                                                                                                           | [🦊🔗](https://addons.mozilla.org/en-US/firefox/addon/markdown-viewer-chrome/) | -                                                                              | -                                                                                                                            | [🐙🔗](https://github.com/simov/markdown-viewer)                                                     |\n| Extensions for Mermaid   | -                                                                                                           | -                                                                              | [🔴🔗](https://addons.opera.com/en/extensions/details/extensions-for-mermaid/) | -                                                                                                                            | [🐙🔗](https://github.com/Stefan-S/mermaid-extension)                                                |\n| Chrome Diagrammer        | [🎡🔗](https://chromewebstore.google.com/detail/chrome-diagrammer/bkpbgjmkomfoakfklcjeoegkklgjnnpk)         | -                                                                              | -                                                                              | -                                                                                                                            | -                                                                                                    |\n| Mermaid Diagrams         | [🎡🔗](https://chromewebstore.google.com/detail/mermaid-diagrams/phfcghedmopjadpojhmmaffjmfiakfil)          | -                                                                              | -                                                                              | -                                                                                                                            | -                                                                                                    |\n| Monkeys                  | [🎡🔗](https://chromewebstore.google.com/detail/monkeys-mermaid-for-githu/cplfdpoajbclbgphaphphcldamfkjlgi) | -                                                                              | -                                                                              | -                                                                                                                            | -                                                                                                    |\n| Mermaid Previewer        | [🎡🔗](https://chromewebstore.google.com/detail/mermaid-previewer/oidjnlhbegipkcklbdfnbkikplpghfdl)         | -                                                                              | -                                                                              | -                                                                                                                            | -                                                                                                    |\n| Tachi Code               | [🎡🔗](https://chromewebstore.google.com/detail/tachi-code/acoecgiamdjjkhmdodcfdfanfnagamjf)                | [🦊🔗](https://addons.mozilla.org/en-US/firefox/addon/tachi-code/)             | -                                                                              | [🌀🔗](https://microsoftedge.microsoft.com/addons/detail/tachi-code/mombmlijgpfamkenkmggobjimompbpji)                        | -                                                                                                    |\n\n### Other\n\n- [Bisheng](https://www.npmjs.com/package/bisheng)\n  - [bisheng-plugin-mermaid](https://github.com/yct21/bisheng-plugin-mermaid)\n- [Blazorade Mermaid: Render Mermaid diagrams in Blazor applications](https://github.com/Blazorade/Blazorade-Mermaid/wiki)\n- [Codemia: A tool to practice system design problems](https://codemia.io) ✅\n- [ExDoc](https://github.com/elixir-lang/ex_doc)\n  - [Rendering Mermaid graphs](https://github.com/elixir-lang/ex_doc#rendering-mermaid-graphs)\n- [MarkChart: Preview Mermaid diagrams on macOS](https://markchart.app/)\n- [mermaid-isomorphic](https://github.com/remcohaszing/mermaid-isomorphic)\n- [mermaid-server: Generate diagrams using a HTTP request](https://github.com/TomWright/mermaid-server)\n- [NiceGUI: Let any browser be the frontend of your Python code](https://nicegui.io) ✅\n  - [ui.mermaid(...)](https://nicegui.io/documentation/mermaid)\n- [Reveal.js](https://github.com/hakimel/reveal.js)\n  - [reveal.js-mermaid-plugin](https://github.com/ludwick/reveal.js-mermaid-plugin)\n- [Reveal CK](https://github.com/jedcn/reveal-ck)\n  - [reveal-ck-mermaid-plugin](https://github.com/tmtm/reveal-ck-mermaid-plugin)\n- [SchemaCrawler - Generate Mermaid diagrams from your database](https://dev.to/sualeh/how-to-generate-mermaid-diagrams-for-your-database-33bn)\n- [Schema3D](https://schema3d.com) - Browser-only 3D visualizer for Mermaid ER diagrams (also SQL / DrawDB); shareable URL, no live DB\n- [speccharts: Turn your test suites into specification diagrams](https://github.com/arnaudrenaud/speccharts)\n- [termaid: Render Mermaid diagrams as Unicode art in the terminal](https://github.com/fasouto/termaid)\n- [Vitepress Plugin](https://github.com/sametcn99/vitepress-mermaid-renderer)\n\n\n","packages/mermaid/src/docs/ecosystem/integrations-create.md":"# Integrations - create\n\n## Recommendations\n\nBelow are recommendations for creating plugins and integrations with Mermaid.\n\n### File Extension\n\nApplications that support Mermaid files [SHOULD](https://datatracker.ietf.org/doc/html/rfc2119#section-3) use `.mermaid` or `.mmd` file extensions.\n\n### MIME Type\n\nThe recommended [MIME type](https://www.iana.org/assignments/media-types/media-types.xhtml) for Mermaid media is [`text/vnd.mermaid`](https://www.iana.org/assignments/media-types/application/vnd.mermaid).\n\n## Showcase\n\n### Mermaid Discord workspace\n\nWe would love to see what you create with Mermaid. Please share your creations with us in our [Discord](https://discord.gg/sKeNQX4Wtj) server [#showcase](https://discord.com/channels/1079455296289788015/1079502635054399649) channel.\n\n### Add to Mermaid Ecosystem\n\nIf you have a plugin or integration that you'd like to add to our [Community integrations](/ecosystem/integrations-community) list, please [open a pull request](https://github.com/mermaid-js/mermaid).\n","packages/mermaid/src/docs/ecosystem/mermaid-chart.md":"# Mermaid Chart\n\nThe Future of Diagramming & Visual Collaboration\n\nTry the Ultimate AI, Mermaid, and Visual Diagramming Suite by creating an account at [Mermaid Chart](https://mermaid.ai/app/sign-up).\n\n
\n\n\"Mermaid Chart\n\n## About\n\n[Mermaid Chart](https://mermaid.ai) was born out of the Mermaid open source project and was founded by Knut Sveidqvist together with Open Core Ventures. The lead developers from Mermaid have joined the company and there is a strong connection between the project we all love and Mermaid Chart. Mermaid Chart brings resources to the open source development of Mermaid and makes it possible to work with Mermaid professionally.\n\n## Features\n\n- **Editor** - A web based editor for creating and editing Mermaid diagrams.\n\n- **Mermaid AI** - Use our embedded AI Chat to generate diagrams from natural language descriptions.\n\n- **Whiteboard** - A virtual whiteboard for creating and editing Mermaid diagrams.\n\n- **Plugins** - A plugin system for extending the functionality of Mermaid.\n\n  Official Mermaid Chart plugins:\n  - [Mermaid Chart GPT](https://chatgpt.com/g/g-684cc36f30208191b21383b88650a45d-mermaid-chart-diagrams-and-charts)\n  - [Confluence](https://marketplace.atlassian.com/apps/1234056/mermaid-chart-for-confluence?hosting=cloud&tab=overview)\n  - [Jira](https://marketplace.atlassian.com/apps/1234810/mermaid-chart-for-jira?tab=overview&hosting=cloud)\n  - [Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=MermaidChart.vscode-mermaid-chart)\n  - [JetBrains IDE](https://plugins.jetbrains.com/plugin/23043-mermaid-chart)\n  - [Google Docs](https://gsuite.google.com/marketplace/app/mermaidchart/947683068472)\n  - [Microsoft PowerPoint and Word](https://appsource.microsoft.com/en-us/product/office/WA200006214?tab=Overview)\n\n  Visit our [Plugins](https://mermaid.ai/plugins) page for more information.\n\n- **Collaboration** - A web based collaboration feature for multi-user editing on Mermaid diagrams in real-time (Pro and Enterprise plans).\n\n- **Comments** - Enhance collaboration by adding comments to diagrams.\n\n- **Presentations** - A presentation mode for viewing Mermaid diagrams in a slideshow format.\n\n## Plans\n\n- **Basic** - A free plan that includes three diagrams and limited AI usage.\n\n- **Plus** - A paid plan that includes unlimited diagrams, scalable AI usage, and centralized billing for small teams.\n\n- **Premium** - A paid plan for larger teams that need massive AI or diagram usage along with team collaboration, knowledge management, and security features like SSO.\n\n- **Enterprise** - A paid plan for enterprise use that includes all Premium features, custom contracts, support, and more.\n\nTo learn more, visit our [Pricing](https://mermaid.ai/pricing) page.\n\nSign up for a free account on the [Mermaid](https://mermaid.ai/app/sign-up) website and trial paid features at any time for 7 days free.\n\n## Mermaid JS contributions\n\nFirst time contributors are eligible for a free Premium tier account for 1 year.\n","packages/mermaid/src/docs/ecosystem/tutorials.md":"# Tutorials\n\nThis is a list of publicly available Tutorials for using Mermaid.JS and is intended as a basic introduction for the use of the Live Editor for generating diagrams, and deploying Mermaid.JS through HTML.\n\n**Note that these tutorials might display an older interface, but the usage of the live-editor will largely be the same.**\n\nFor most purposes, you can use the [Live Editor](https://mermaid.live), to quickly and easily render a diagram.\n\n## Live-Editor Tutorials\n\nThe definitions that can be generated the Live-Editor are also backwards-compatible as of version 8.7.0.\n\n[Chris Chinchilla: Hands on - Text-based diagrams with Mermaid](https://www.youtube.com/watch?v=4_LdV1cs2sA)\n\n[GitLab Unfiltered: How to Create Mermaid Diagrams](https://www.youtube.com/watch?v=SQ9QmuTHuSI&t=438s)\n\n[GitLab Unfiltered: Emilie adds a mermaid diagram to the handbook](https://www.youtube.com/watch?v=5RQqht3NNSE)\n\n[World of Zero: I Learn How To Build Flowcharts and Signal Diagram's in Mermaid.JS](https://www.youtube.com/watch?v=7_2IroEs6Is&t=207s)\n\n[Eddie Jaoude: Can you code your diagrams?](https://www.youtube.com/watch?v=9HZzKkAqrX8)\n\n## Mermaid with OpenAI\n\n[Elle Neal: Mind Mapping with AI: An Accessible Approach for Neurodiverse Learners Tutorial:](https://medium.com/@elle.neal_71064/mind-mapping-with-ai-an-accessible-approach-for-neurodiverse-learners-1a74767359ff)\n\n## Mermaid with HTML\n\nExamples are provided in [Getting Started](../intro/getting-started.md)\n\n**CodePen Examples:**\n\nhttps://codepen.io/CarlBoneri/pen/BQwZzq\n\nhttps://codepen.io/tdkn/pen/vZxQzd\n\nhttps://codepen.io/janzeteachesit/pen/OWWZKN\n\n## Mermaid with Text Area\n\nhttps://codepen.io/Ryuno-Ki/pen/LNxwgR\n\n## Mermaid in open source docs\n\n[K8s.io Diagram Guide](https://kubernetes.io/docs/contribute/style/diagram-guide/)\n\n[K8s.dev blog: Improve your documentation with Mermaid.js diagrams](https://www.kubernetes.dev/blog/2021/12/01/improve-your-documentation-with-mermaid.js-diagrams/)\n\n## Jupyter / Python Integration with mermaid-js\n\nHere's an example of Python integration with mermaid-js which uses the mermaid.ink service, that displays the graph in a Jupyter notebook and save it as _.png_ image with the stated resolution (in this example, `dpi=1200`).\n\n```python\nimport base64\nimport io, requests\nfrom IPython.display import Image, display\nfrom PIL import Image as im\nimport matplotlib.pyplot as plt\n\ndef mm(graph):\n    graphbytes = graph.encode(\"utf8\")\n    base64_bytes = base64.urlsafe_b64encode(graphbytes)\n    base64_string = base64_bytes.decode(\"ascii\")\n    img = im.open(io.BytesIO(requests.get('https://mermaid.ink/img/' + base64_string).content))\n    plt.imshow(img)\n    plt.axis('off') # allow to hide axis\n    plt.savefig('image.png', dpi=1200)\n\nmm(\"\"\"\ngraph LR;\n    A--> B & C & D\n    B--> A & E\n    C--> A & E\n    D--> A & E\n    E--> B & C & D\n\"\"\")\n```\n\n**Output**\n\n![Example graph of the Python integration](img/python-mermaid-integration.png)\n\n\n","packages/mermaid/src/docs/index.md":"---\nlayout: home\nsidebar: false\n\ntitle: Mermaid\ntitleTemplate: Diagramming and charting tool\nhero:\n  name: Mermaid.js now lives\n  text: at mermaid.ai\n  tagline: One home for the open-source library and the platform built around it. More resources for the project, a clearer path for contributors, and a team committed to keeping Mermaid open, always.\n\n  image:\n    light: /hero-chart.svg\n    dark: /hero-chart-dark.svg\n    alt: Mermaid diagram\n  actions:\n    - theme: brand\n      text: Try Editor\n      link: https://mermaid.live/edit\n      target: _blank\n      rel: external\n    - theme: alt\n      text: Get started\n      link: https://mermaid.ai/open-source/intro/\n\nfeatures:\n  - icon:\n      src: /1-Callout-Easy.svg\n    title: Easy to use\n    details: Easily create diagrams and charts with the Mermaid Live Editor.\n    link: https://mermaid.live/\n  - icon:\n      src: /2-Callout-Integrations.svg\n    title: Integrations available\n    details: Use Mermaid with your favorite applications, check out the integrations list.\n    link: ../../ecosystem/integrations-community.md\n  - icon:\n      src: /3-Callout-Awards.svg\n    title: Award winning\n    details: 2019 JavaScript Open Source Award winner for \"The Most Exciting Use of Technology\".\n    link: https://osawards.com/javascript/2019\n---\n","packages/mermaid/src/docs/intro/examples.md":"## Diagram Types\n\n### [Flowchart](../syntax/flowchart.md?id=flowcharts-basic-syntax)\n\n```mermaid-example\ngraph TD;\n    A-->B;\n    A-->C;\n    B-->D;\n    C-->D;\n```\n\n### [Sequence diagram](../syntax/sequenceDiagram.md)\n\n```mermaid-example\nsequenceDiagram\n    participant Alice\n    participant Bob\n    Alice->>John: Hello John, how are you?\n    loop HealthCheck\n        John->>John: Fight against hypochondria\n    end\n    Note right of John: Rational thoughts 
prevail!\n    John-->>Alice: Great!\n    John->>Bob: How about you?\n    Bob-->>John: Jolly good!\n```\n\n### [Use case diagram](../syntax/usecase.md)\n\n```mermaid-example\nusecase-beta\ndirection LR\nactor Customer\nCheckout(\"Place order\")\nCustomer --> Checkout\n```\n\n### [Gantt diagram](../syntax/gantt.md)\n\n```mermaid-example\ngantt\ndateFormat  YYYY-MM-DD\ntitle Adding GANTT diagram to mermaid\nexcludes weekdays 2014-01-10\n\nsection A section\nCompleted task            :done,    des1, 2014-01-06,2014-01-08\nActive task               :active,  des2, 2014-01-09, 3d\nFuture task               :         des3, after des2, 5d\nFuture task2               :         des4, after des3, 5d\n```\n\n### [Class diagram](../syntax/classDiagram.md)\n\n```mermaid-example\nclassDiagram\nClass01 <|-- AveryLongClass : Cool\nClass03 *-- Class04\nClass05 o-- Class06\nClass07 .. Class08\nClass09 --> C2 : Where am i?\nClass09 --* C3\nClass09 --|> Class07\nClass07 : equals()\nClass07 : Object[] elementData\nClass01 : size()\nClass01 : int chimp\nClass01 : int gorilla\nClass08 <--> C2: Cool label\n```\n\n### [Git graph](../syntax/gitgraph.md)\n\n```mermaid-example\n    gitGraph\n       commit\n       commit\n       branch develop\n       commit\n       commit\n       commit\n       checkout main\n       commit\n       commit\n```\n\n### [Entity Relationship Diagram - :exclamation: experimental](../syntax/entityRelationshipDiagram.md)\n\n```mermaid-example\nerDiagram\n    CUSTOMER ||--o{ ORDER : places\n    ORDER ||--|{ LINE-ITEM : contains\n    CUSTOMER }|..|{ DELIVERY-ADDRESS : uses\n\n```\n\n### [User Journey Diagram](../syntax/userJourney.md)\n\n```mermaid-example\njourney\n    title My working day\n    section Go to work\n      Make tea: 5: Me\n      Go upstairs: 3: Me\n      Do work: 1: Me, Cat\n    section Go home\n      Go downstairs: 5: Me\n      Sit down: 5: Me\n```\n\n### [Quadrant Chart](../syntax/quadrantChart.md)\n\n```mermaid-example\nquadrantChart\n    title Reach and engagement of campaigns\n    x-axis Low Reach --> High Reach\n    y-axis Low Engagement --> High Engagement\n    quadrant-1 We should expand\n    quadrant-2 Need to promote\n    quadrant-3 Re-evaluate\n    quadrant-4 May be improved\n    Campaign A: [0.3, 0.6]\n    Campaign B: [0.45, 0.23]\n    Campaign C: [0.57, 0.69]\n    Campaign D: [0.78, 0.34]\n    Campaign E: [0.40, 0.34]\n    Campaign F: [0.35, 0.78]\n```\n\n### [XY Chart](../syntax/xyChart.md)\n\n```mermaid-example\nxychart-beta\n    title \"Sales Revenue\"\n    x-axis [jan, feb, mar, apr, may, jun, jul, aug, sep, oct, nov, dec]\n    y-axis \"Revenue (in $)\" 4000 --> 11000\n    bar [5000, 6000, 7500, 8200, 9500, 10500, 11000, 10200, 9200, 8500, 7000, 6000]\n    line [5000, 6000, 7500, 8200, 9500, 10500, 11000, 10200, 9200, 8500, 7000, 6000]\n```\n","packages/mermaid/src/docs/intro/getting-started.md":"---\noutline: 'deep' # shows all h3 headings in outline in Vitepress\n---\n\n# Mermaid User Guide\n\n## Mermaid is composed of three parts\n\n1. Deployment\n2. Syntax\n3. Configuration\n\nThis section talks about the different ways to **deploy** Mermaid.\n\nIf you are a beginner:\n\n- Check out the [Diagram Syntax](syntax-reference.md) page\n- Check out the [Tutorials](../ecosystem/tutorials.md) page\n\n## Ways to use Mermaid\n\n1. [Using the Mermaid Live Editor](getting-started.md#_1-using-the-mermaid-live-editor)\n2. [Using the Mermaid Chart Editor](getting-started.md#_2-using-the-mermaid-chart-editor)\n3. [Using Mermaid Plugins and Integrations](getting-started.md#_3-using-mermaid-plugins)\n4. [Calling the Mermaid JavaScript API](getting-started.md#_4-calling-the-mermaid-javascript-api)\n5. [Adding Mermaid as a dependency](getting-started.md#_5-adding-mermaid-as-a-dependency)\n\nTo learn more, visit the [Usage](../config/usage.md) page.\n\n## 1. Using the Mermaid Live Editor\n\nAvailable at the [Mermaid Live Editor](https://mermaid.live) website.\n\n### Features\n\n
\n\n#### • Diagram Code\n\nIn the `Code` panel, write or edit Mermaid code, and instantly `Preview` the rendered result in the diagram panel.\n\nHere is an example of Mermaid code and its rendered result:\n\n```mermaid-example\ngraph TD\n    A[Enter Chart Definition] --> B(Preview)\n    B --> C{decide}\n    C --> D[Keep]\n    C --> E[Edit Definition]\n    E --> B\n    D --> F[Save Image and Code]\n    F --> B\n```\n\n
\n\n#### • Configurations\n\nConfiguration options are available in the `Configuration` panel. The options are applied to the diagram in the `Preview` panel.\n\nTo learn more, visit the [Configuration Reference](../config/setup/README.md) page\n\n![Code,Config and Preview](./img/Code-Preview-Config.png)\n\n
\n\n#### • Editing History\n\nYour code will be autosaved and appear in the `Timeline` tab of the `History` section. Edits are saved every minute and only the last 30 edits are viewable.\n\nAlternatively, you can manually save code by clicking on the `Save` icon from the `History` section.\n\n```note\nHistory is stored in the browser storage only.\n```\n\n
\n\n#### • Saving a diagram\n\nThere are multiple ways of saving your diagram from the `Actions` section:\n\n- export PNG\n- export SVG\n- export as Markdown\n\n![Flowchart](./img/Live-Editor-Choices.png)\n\n
\n\n#### • Editing your diagrams\n\nTo edit your diagram, you can copy paste existing Mermaid diagram code into the `Code` section of the `Live Editor`.\n\nOr:\n\n- create a new diagram from scratch\n- use a Sample Diagram from the `Sample Diagrams` section\n\n
\n\n#### • Loading from Gists\n\nThe Gist you create should have a `code.mmd` file and optionally a `config.json`, similar to this [example](https://gist.github.com/sidharthv96/6268a23e673a533dcb198f241fd7012a).\n\n```note\nTo learn about Gists, visit the GitHub documentation page on [Creating gists](https://docs.github.com/en/get-started/writing-on-github/editing-and-sharing-content-with-gists/creating-gists).\n```\n\nOnce you have created a Gist, copy paste the Gist URL into the respective field in the `Actions` section and click on the `Load Gist` button.\n\nHere is an example of a Gist being loaded into the Editor:\n\n\n\nAnd, here is the diagram view from the above example:\n\n\n\n## 2. Using the Mermaid Chart Editor\n\nAvailable at the [Mermaid Chart](https://mermaid.ai/) website.\n\nMermaid Chart is a web-based diagram editor that allows you to create and edit diagrams in your browser. It is built by the team behind Mermaid.\n\nFeatures include:\n\n- AI diagramming\n- Collaboration & multi-user editing\n- Storage\n- and more\n\nTo learn more, visit the [Mermaid Chart page](/ecosystem/mermaid-chart.html) in the Ecosystem section of the documentation.\n\nOr go to the [Mermaid Chart website](https://mermaid.ai/app/sign-up) to sign up for a Free account.\n\n## 3. Using Mermaid Plugins\n\n### Mermaid Plugins\n\nYou can generate Mermaid diagrams from within popular applications using plug-ins.\n\nFor a list of Mermaid Plugins and Integrations, visit the [Integrations page](../ecosystem/integrations-community.md).\n\n### Mermaid Chart Plugins\n\nMermaid Chart plugins are available for:\n\n- [ChatGPT](https://mermaid.ai/docs/plugins/mermaid-chart-gpt)\n- [JetBrains IDE](https://mermaid.ai/docs/plugins/jetbrains-ide)\n- [Microsoft PowerPoint](https://mermaid.ai/docs/plugins/microsoft-powerpoint)\n- [Microsoft Word](https://mermaid.ai/docs/plugins/microsoft-word)\n- [Visual Studio Code](https://mermaid.ai/docs/plugins/visual-studio-code)\n\nTo learn more, visit the [Mermaid Chart Plugins](https://mermaid.ai/plugins) page.\n\n### Native Mermaid Support\n\nFor apps that support markdown (e.g. [GitHub](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-diagrams) and [GitLab](https://handbook.gitlab.com/handbook/tools-and-tips/mermaid/)), you can add Mermaid diagrams by making a `mermaid` code block.\n\n````markdown\nThe following code-block will be rendered as a Mermaid diagram:\n\n```mermaid\nflowchart LR\n  A --> B\n```\n````\n\n## 4. Calling the Mermaid JavaScript API\n\nThis method can be used with any common web server like `Apache`, `IIS`, `Nginx`, and `Node Express`.\n\nYou will also need a text editing tool like `Notepad++` to generate an `html` file. It is then deployed by a web browser, i.e. `Firefox`, `Chrome`, `Safari`.\n\n```note\nInternet Explorer is not supported.\n```\n\nThe API works by pulling rendering instructions from the source `mermaid.js` in order to render diagrams on the page.\n\n### Requirements for the Mermaid API\n\nWhen writing the `html` file, we give two instructions inside the `html code` to the `web browser`:\n\na. The Mermaid code for the diagram we want to create.\n\nb. The importing of the Mermaid library through the `mermaid.esm.mjs` or `mermaid.esm.min.mjs`, and the `mermaid.initialize()` call, which dictates the appearance of diagrams and also starts the rendering process.\n\n#### Examples\n\n- This is an example of an embedded Mermaid diagram definition inside a `
`:\n\n```html\n\n  Here is a mermaid diagram:\n  
\n        graph TD\n        A[Client] --> B[Load Balancer]\n        B --> C[Server01]\n        B --> D[Server02]\n  
\n\n```\n\n```note\nEvery Mermaid chart/graph/diagram definition should have separate `
` tags.\n```\n\n- This is an example of a Mermaid import and the `mermaid.initialize()` call.\n\n```note\nA `mermaid.initialize()` call takes all the definitions contained within `
` tags and renders them into diagrams.\n```\n\n```html\n\n  \n\n```\n\n```note\nRendering in Mermaid is initialized by the `mermaid.initialize()` call. However, doing the opposite lets you control when it starts looking for `
` tags inside the web page with `mermaid.initialize()`. This is useful when you think that not all `
` tags may have loaded on the execution of `mermaid.esm.min.mjs` file.\n```\n\n`startOnLoad` is one of the parameters that can be defined by `mermaid.initialize()`\n\n| Parameter   | Description                       | Type    | Values      |\n| ----------- | --------------------------------- | ------- | ----------- |\n| startOnLoad | Toggle for Rendering upon loading | Boolean | true, false |\n\nIn this example, the `mermaidAPI` is being called through the `CDN`:\n\n```html\n\n  \n    Here is one mermaid diagram:\n    
\n            graph TD\n            A[Client] --> B[Load Balancer]\n            B --> C[Server1]\n            B --> D[Server2]\n    
\n\n    And here is another:\n    
\n            graph TD\n            A[Client] -->|tcp_123| B\n            B(Load Balancer)\n            B -->|tcp_456| C[Server1]\n            B -->|tcp_456| D[Server2]\n    
\n\n    \n  \n\n```\n\nIn this example, `mermaid.js` is referenced in `src` as a separate JavaScript file:\n\n```html\n\n  \n    \n  \n  \n    
\n            graph LR\n            A --- B\n            B-->C[fa:fa-ban forbidden]\n            B-->D(fa:fa-spinner);\n    
\n    
\n            graph TD\n            A[Client] --> B[Load Balancer]\n            B --> C[Server1]\n            B --> D[Server2]\n    
\n    \n  \n\n```\n\n##### Custom fonts\n\nMermaid comes with some default recommended fonts that you can setup on your\npage as well.\n\nSee [Usage § Fonts](../config/usage.md#fonts) for full details.\n\n```html\n\n  \n    /@fontsource/open-sans@5/400.css\" />\n    /@fontsource/open-sans@5/400-italic.css\" />\n    /@fontsource-variable/recursive@5/index.css\" />\n  \n  \n    Here is one mermaid diagram using the `redux-dark` theme:\n\n    
\n      ---\n      config:\n        theme: redux-dark\n      ---\n      flowchart\n            A[Client] --> B[Load Balancer]\n            B --> C[Server1]\n            B --> D[Server2]\n    
\n\n    \n  \n\n```\n\n## 5. Adding Mermaid as a dependency\n\nBelow are the steps for adding Mermaid as a dependency:\n\n1. Install [Node.js](https://nodejs.org/) v20 or higher (LTS recommended).\n\n```note\nTo learn more about downloading and installing `Node.js` and `npm`, visit the [npm Docs website](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm).\n```\n\n2. Add Mermaid using your preferred package manager:\n\n   **npm**\n\n   `npm install mermaid`\n\n   **yarn**\n\n   `yarn add mermaid`\n\n   **pnpm**\n\n   `pnpm add mermaid`\n\n3. To add Mermaid as a dev dependency instead, append the dev flag:\n\n   **npm:** `npm install --save-dev mermaid`\n\n   **yarn:** `yarn add --dev mermaid`\n\n   **pnpm:** `pnpm add --save-dev mermaid`\n\n## Closing note\n\n```note\nComments from Knut Sveidqvist, creator of Mermaid:\n\n- In early versions of Mermaid, the `\n```\n\n**Doing so commands the mermaid parser to look for the `
` or `
` tags with `class=\"mermaid\"`. From these tags, mermaid tries to read the diagram/chart definitions and render them into SVG charts.**\n\n**Examples can be found in** [Other examples](../syntax/examples.md)\n\n## Sibling projects\n\n- [Mermaid Live Editor](https://github.com/mermaid-js/mermaid-live-editor)\n- [Mermaid CLI](https://github.com/mermaid-js/mermaid-cli)\n- [Mermaid Tiny](https://github.com/mermaid-js/mermaid/tree/develop/packages/tiny)\n- [Mermaid Webpack Demo](https://github.com/mermaidjs/mermaid-webpack-demo)\n- [Mermaid Parcel Demo](https://github.com/mermaidjs/mermaid-parcel-demo)\n\n## Request for Assistance\n\nThings are piling up and I have a hard time keeping up. It would be great if we could form a core team of developers to cooperate\nwith the future development of mermaid.\n\nAs part of this team you would get write access to the repository and would\nrepresent the project when answering questions and issues.\n\nTogether we could continue the work with things like:\n\n- Adding more types of diagrams like mindmaps, ert diagrams, etc.\n- Improving existing diagrams\n\nDon't hesitate to contact me if you want to get involved!\n\n## Contributors\n\n
\n\n[![Good first issue](https://img.shields.io/github/labels/mermaid-js/mermaid/Good%20first%20issue%21)](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Good+first+issue%21%22)\n[![Contributors](https://img.shields.io/github/contributors/mermaid-js/mermaid)](https://github.com/mermaid-js/mermaid/graphs/contributors)\n[![Commits](https://img.shields.io/github/commit-activity/m/mermaid-js/mermaid)](https://github.com/mermaid-js/mermaid/graphs/contributors)\n\n
\n\nMermaid is a growing community and is always accepting new contributors. There's a lot of different ways to help out and we're always looking for extra hands! Look at [this issue](https://github.com/mermaid-js/mermaid/issues/866) if you want to know where to start helping out.\n\nDetailed information about how to contribute can be found in the [contribution guideline](../community/contributing.md).\n\n### Requirements\n\n- [volta](https://volta.sh/) to manage node versions.\n- [Node.js](https://nodejs.org/en/). `volta install node`\n- [pnpm](https://pnpm.io/) package manager. `volta install pnpm`\n\n### Development Installation\n\n```bash\ngit clone git@github.com:mermaid-js/mermaid.git\ncd mermaid\n# npx is required for first install as volta support for pnpm is not added yet.\nnpx pnpm install\npnpm test\n```\n\n### Lint\n\n```sh\npnpm lint\n```\n\nWe use [eslint](https://eslint.org/).\nWe recommend you to install [editor plugins](https://eslint.org/docs/user-guide/integrations) to get real time lint result.\n\n### Test\n\n```sh\npnpm test\n```\n\nManual test in browser: open `dist/index.html`\n\n### Release\n\nFor those who have the permission to do so:\n\nUpdate version number in `package.json`.\n\n```sh\nnpm publish\n```\n\nThe above command generates files into the `dist` folder and publishes them to [npmjs.com](https://www.npmjs.com/).\n\n## Security and safe diagrams\n\nFor public sites, it can be precarious to retrieve text from users on the internet, storing that content for presentation in a browser at a later stage. The reason is that the user content can contain embedded malicious scripts that will run when the data is presented. For Mermaid this is a risk, specially as mermaid diagrams contain many characters that are used in html which makes the standard sanitation unusable as it also breaks the diagrams. We still make an effort to sanitize the incoming code and keep refining the process but it is hard to guarantee that there are no loop holes.\n\nAs an extra level of security for sites with external users we are happy to introduce a new security level in which the diagram is rendered in a sandboxed iframe preventing JavaScript in the code from being executed. This is a great step forward for better security.\n\n_Unfortunately you cannot have a cake and eat it at the same time which in this case means that some of the interactive functionality gets blocked along with the possible malicious code._\n\n## Reporting vulnerabilities\n\nTo report a vulnerability, please e-mail security@mermaid.live with a description of the issue, the steps you took to create the issue, affected versions, and if known, mitigations for the issue.\n\n## Appreciation\n\nA quick note from Knut Sveidqvist:\n\n> _Many thanks to the [d3](https://d3js.org/) and [dagre-d3](https://github.com/cpettitt/dagre-d3) projects for providing the graphical layout and drawing libraries!_\n>\n> _Thanks also to the [js-sequence-diagram](https://bramp.github.io/js-sequence-diagrams) project for usage of the grammar for the sequence diagrams. Thanks to Jessica Peter for inspiration and starting point for gantt rendering._\n>\n> _Thank you to [Tyler Long](https://github.com/tylerlong) who has been a collaborator since April 2017._\n>\n> _Thank you to the ever-growing list of [contributors](https://github.com/mermaid-js/mermaid/graphs/contributors) that brought the project this far!_\n\n---\n\n_Mermaid was created by Knut Sveidqvist for easier documentation._\n\n\n","packages/mermaid/src/docs/intro/syntax-reference.md":"# Diagram Syntax\n\nMermaid's syntax is used to create diagrams. You'll find that it is not too tricky and can be learned in a day. The next sections dive deep into the syntax of each diagram type.\n\nSyntax, together with Deployment and Configuration constitute the whole of Mermaid.\n\nDiagram Examples can be found in the [Mermaid Live Editor](https://mermaid.live), it is also a great practice area.\n\n## Syntax Structure\n\nOne would notice that all **Diagrams definitions begin** with a declaration of the **diagram type**, followed by the definitions of the diagram and its contents. This declaration notifies the parser which kind of diagram the code is supposed to generate. The only exception to this a [Frontmatter](#frontmatter-for-diagram-code) configuration.\n\nLine comments can ignore anything on the line after '%% '.\n\nUnknown words and misspellings will break a diagram, while parameters silently fail.\n\n**Example** : The code below is for an Entity Relationship Diagram, specified by the `erDiagram` declaration. What follows is the definition of the different `Entities` represented in it.\n\n```mermaid-example\nerDiagram\n          CUSTOMER }|..|{ DELIVERY-ADDRESS : has\n          CUSTOMER ||--o{ ORDER : places\n          CUSTOMER ||--o{ INVOICE : \"liable for\"\n          DELIVERY-ADDRESS ||--o{ ORDER : receives\n          INVOICE ||--|{ ORDER : covers\n          ORDER ||--|{ ORDER-ITEM : includes\n          PRODUCT-CATEGORY ||--|{ PRODUCT : contains\n          PRODUCT ||--o{ ORDER-ITEM : \"ordered in\"\n```\n\nThe [Getting Started](./getting-started.md) section can also provide some practical examples of mermaid syntax.\n\n## Diagram Breaking\n\nOne should **beware the use of some words or symbols** that can break diagrams. These words or symbols are few and often only affect specific types of diagrams. The table below will continuously be updated.\n\n| Diagram Breakers                                                                     | Reason                                                                  | Solution                                          |\n| ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------- | ------------------------------------------------- |\n| **Comments**                                                                         |                                                                         |                                                   |\n| [`%%{``}%%`](https://github.com/mermaid-js/mermaid/issues/1968)                      | Similar to [Directives](../config/directives.md) confuses the renderer. | In comments using `%%`, avoid using \"{}\".         |\n| **Flow-Charts**                                                                      |                                                                         |                                                   |\n| 'end'                                                                                | The word \"End\" can cause Flowcharts and Sequence diagrams to break      | Wrap them in quotation marks to prevent breakage. |\n| [Nodes inside Nodes](../syntax/flowchart.md?id=special-characters-that-break-syntax) | Mermaid gets confused with nested shapes                                | wrap them in quotation marks to prevent breaking  |\n\n## Mermaid Live Editor\n\nNow, that you've seen what you should not add to your diagrams, you can play around with them in the [Mermaid Live Editor](https://mermaid.live).\n\n## Configuration\n\nConfiguration is the third part of Mermaid, after deployment and syntax. It deals with the different ways that Mermaid can be customized across different deployments.\n\nIf you are interested in altering and customizing your Mermaid Diagrams, you will find the methods and values available for [Configuration](../config/setup/README.md) here. It includes themes.\nThis section will introduce the different methods of configuring the behaviors and appearances of Mermaid Diagrams.\nThe following are the most commonly used methods, and they are all tied to Mermaid [Deployment](./getting-started.md) methods.\n\n### Configuration Section in the [Live Editor](https://mermaid.live).\n\nHere you can edit certain values to change the behavior and appearance of the diagram.\n\nEach of these techniques are functionally equivalent, but better for different deployments.\n\n### [The initialize() call](./getting-started.md#_4-calling-the-mermaid-javascript-api)\n\nUsed when Mermaid is called via an API, or through a `\n```\n\n```mermaid\nclassDiagram\n    class Class01\n    class Class02\n    callback Class01 \"callbackFunction\" \"Callback tooltip\"\n    link Class02 \"https://www.github.com\" \"This is a link\"\n    class Class03\n    class Class04\n    click Class03 call callbackFunction() \"Callback tooltip\"\n    click Class04 href \"https://www.github.com\" \"This is a link\"\n```\n\n> **Success** The tooltip functionality and the ability to link to urls are available from version 0.5.2.\n\nBeginner's tip—a full example using interactive links in an HTML page:\n\n```html\n\n  
\n    classDiagram\n    Animal <|-- Duck\n    Animal <|-- Fish\n    Animal <|-- Zebra\n    Animal : +int age\n    Animal : +String gender\n    Animal: +isMammal()\n    Animal: +mate()\n    class Duck{\n      +String beakColor\n      +swim()\n      +quack()\n      }\n    class Fish{\n      -int sizeInFeet\n      -canEat()\n      }\n    class Zebra{\n      +bool is_wild\n      +run()\n      }\n\n      callback Duck \"callback\" \"Tooltip\"\n      link Zebra \"https://www.github.com\" \"This is a link\"\n  
\n\n  \n\n```\n\n## Styling\n\n### Styling a node\n\nIt is possible to apply specific styles such as a thicker border or a different background color to an individual node using the `style` keyword.\n\nNote that notes and namespaces cannot be styled individually but do support themes.\n\n```mermaid-example\nclassDiagram\n  class Animal\n  class Mineral\n  style Animal fill:#f9f,stroke:#333,stroke-width:4px\n  style Mineral fill:#bbf,stroke:#f66,stroke-width:2px,color:#fff,stroke-dasharray: 5 5\n```\n\n#### Classes\n\nMore convenient than defining the style every time is to define a class of styles and attach this class to the nodes that\nshould have a different look.\n\nA class definition looks like the example below:\n\n```\nclassDef className fill:#f9f,stroke:#333,stroke-width:4px;\n```\n\nAlso, it is possible to define style to multiple classes in one statement:\n\n```\nclassDef firstClassName,secondClassName font-size:12pt;\n```\n\nAttachment of a class to a node is done as per below:\n\n```\ncssClass \"nodeId1\" className;\n```\n\nIt is also possible to attach a class to a list of nodes in one statement:\n\n```\ncssClass \"nodeId1,nodeId2\" className;\n```\n\nA shorter form of adding a class is to attach the classname to the node using the `:::` operator:\n\n```mermaid-example\nclassDiagram\n    class Animal:::someclass\n    classDef someclass fill:#f96\n```\n\nOr:\n\n```mermaid-example\nclassDiagram\n    class Animal:::someclass {\n        -int sizeInFeet\n        -canEat()\n    }\n    classDef someclass fill:#f96\n```\n\n### Default class\n\nIf a class is named default it will be applied to all nodes. Specific styles and classes should be defined afterwards to override the applied default styling.\n\n```\nclassDef default fill:#f9f,stroke:#333,stroke-width:4px;\n```\n\n```mermaid-example\nclassDiagram\n  class Animal:::pink\n  class Mineral\n\n  classDef default fill:#f96,color:red\n  classDef pink color:#f9f\n```\n\n### CSS Classes\n\nIt is also possible to predefine classes in CSS styles that can be applied from the graph definition as in the example\nbelow:\n\n**Example style**\n\n```html\n\n```\n\n**Example definition**\n\n```mermaid-example\nclassDiagram\n    class Animal:::styleClass\n```\n\n> cssClasses cannot be added using this shorthand method at the same time as a relation statement.\n\n## Configuration\n\n### Members Box\n\nIt is possible to hide the empty members box of a class node.\n\nThis is done by changing the **hideEmptyMembersBox** value of the class diagram configuration. For more information on how to edit the Mermaid configuration see the [configuration page.](https://mermaid.js.org/config/configuration.html)\n\n### Possible configuration parameters:\n\n| Parameter           | Description                                                  | Default value |\n| ------------------- | ------------------------------------------------------------ | ------------- |\n| hideEmptyMembersBox | Hides the empty members box of a class node when set to true | false         |\n\n```mermaid-example\n---\n  config:\n    class:\n      hideEmptyMembersBox: true\n---\nclassDiagram\n  class Duck\n```\n","packages/mermaid/src/docs/syntax/cynefin.md":"# Cynefin Framework Diagram (v11.16.0+)\n\n> The Cynefin framework is a sense-making framework created by [Dave Snowden](https://en.wikipedia.org/wiki/Dave_Snowden) that categorizes problems into five complexity domains. It helps teams match their response to the nature of the situation they are facing. The name is Welsh for \"place\" or \"habitat\".\n\nYou can read more at [The Cynefin Co](https://thecynefin.co/about-us/about-cynefin-framework).\n\n## Introduction\n\nThe Cynefin framework divides the world into five domains, each with its own decision-making approach:\n\n- **Clear** (formerly Obvious/Simple): Cause and effect are obvious. Sense → Categorise → Respond. Apply **best practices**.\n- **Complicated**: Cause and effect require analysis or expertise. Sense → Analyse → Respond. Apply **good practices**.\n- **Complex**: Cause and effect can only be deduced in retrospect. Probe → Sense → Respond. Apply **emergent practices**.\n- **Chaotic**: No perceivable cause and effect. Act → Sense → Respond. Apply **novel practices**.\n- **Confusion** (or Disorder): You do not know which domain you are in. The goal is to move items out of this state into one of the other four.\n\nThe signature visual feature is the wavy, organic boundary between the ordered (Clear, Complicated) and unordered (Complex, Chaotic) halves, and the \"cliff\" between Clear and Chaotic representing the risk of complacency leading to crisis.\n\n## Syntax\n\nA Cynefin diagram is declared with `cynefin-beta` followed by domain blocks and optional transitions.\n\n```md\ncynefin-beta\ntitle Optional Diagram Title\n\ncomplex\n\"Item label\"\n\"Another item\"\n\ncomplicated\n\"Expert analysis needed\"\n\nclear\n\"Known procedure\"\n\nchaotic\n\"Crisis response\"\n\nconfusion\n\"Item of unknown domain\"\n\ncomplex --> complicated : \"Pattern identified\"\nclear --> chaotic : \"Complacency\"\n```\n\n### Keywords\n\n| Keyword        | Meaning                                                                |\n| -------------- | ---------------------------------------------------------------------- |\n| `cynefin-beta` | Diagram type declaration (required, first line after any front matter) |\n| `title`        | Optional diagram title                                                 |\n| `complex`      | Opens the Complex domain block                                         |\n| `complicated`  | Opens the Complicated domain block                                     |\n| `clear`        | Opens the Clear domain block                                           |\n| `chaotic`      | Opens the Chaotic domain block                                         |\n| `confusion`    | Opens the Confusion / Disorder domain block                            |\n| `-->`          | Declares a transition from one domain to another                       |\n\n### Items\n\nItems are quoted string labels placed on their own lines inside a domain block. Each item renders as a text badge within the domain region.\n\n```\ncomplex\n  \"Investigate root cause\"\n  \"Run chaos experiment\"\n```\n\nKeep per-domain item lists short — the quadrants have fixed layout and long lists can visually overflow their boxes. The confusion ellipse caps at three items and shows a `+N more` badge; the four quadrant domains do not clip, so prefer a handful of items each.\n\n### Transitions\n\nTransitions represent movement of items between domains over time. They are declared at the top level using `-->` between two domain names, with an optional label.\n\n```\ncomplex --> complicated : \"Pattern identified\"\nclear --> chaotic : \"Complacency\"\nchaotic --> complex : \"Stabilized\"\n```\n\nCommon transitions:\n\n- **Complex → Complicated**: An emerging pattern has become understood and can now be analyzed.\n- **Chaotic → Complex**: A crisis has been stabilized enough to begin probing.\n- **Clear → Chaotic**: Complacency or over-constraint has led to collapse (the \"cliff\").\n- **Complicated → Clear**: Analysis has codified a solution into a standard practice.\n\n## Examples\n\n### Basic example\n\n```mermaid-example\ncynefin-beta\n  title Incident Response\n\n  complex\n    \"Investigate root cause\"\n    \"Run chaos experiment\"\n\n  complicated\n    \"Analyze performance data\"\n    \"Expert review needed\"\n\n  clear\n    \"Restart service\"\n    \"Apply known fix\"\n\n  chaotic\n    \"Page on-call immediately\"\n\n  confusion\n    \"Unknown failure mode\"\n```\n\n### With transitions\n\n```mermaid-example\ncynefin-beta\n  title Strategy Categorization\n\n  complex\n    \"Market research\"\n\n  complicated\n    \"Competitive analysis\"\n\n  clear\n    \"Standard pricing\"\n\n  chaotic\n    \"Crisis management\"\n\n  complex --> complicated : \"Pattern identified\"\n  complicated --> clear : \"Best practice codified\"\n  clear --> chaotic : \"Complacency\"\n  chaotic --> complex : \"Stabilized\"\n```\n\n### Empty framework\n\nThe domains themselves render even with no items, useful as a teaching or worksheet template.\n\n```mermaid-example\ncynefin-beta\n  title Cynefin Framework\n\n  complex\n  complicated\n  clear\n  chaotic\n```\n\n## Configuration\n\nCynefin diagrams accept the following configuration under the `cynefin` key in the mermaid config:\n\n| Option                   | Type    | Default | Description                                                                                                                                                                                                                  |\n| ------------------------ | ------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `width`                  | number  | `800`   | Width of the diagram in pixels                                                                                                                                                                                               |\n| `height`                 | number  | `600`   | Height of the diagram in pixels                                                                                                                                                                                              |\n| `padding`                | number  | `40`    | Padding around the diagram                                                                                                                                                                                                   |\n| `showDomainDescriptions` | boolean | `true`  | Show decision model and practice type subtitles per domain                                                                                                                                                                   |\n| `boundaryAmplitude`      | number  | `8`     | Waviness amplitude of domain boundaries in pixels (set to `0` for straight lines)                                                                                                                                            |\n| `seed`                   | number  | `0`     | Deterministic seed for boundary waviness. `0` (default) hashes the diagram's SVG id so each diagram looks unique. Set any non-zero number to lock the waviness across renders — required for stable visual regression tests. |\n\nExample:\n\n```\n---\nconfig:\n  cynefin:\n    width: 1000\n    showDomainDescriptions: false\n---\ncynefin-beta\n  complex\n    \"Adaptive work\"\n```\n\n## Theming\n\nCynefin diagrams use the following theme variables, which can be overridden via `themeVariables.cynefin`:\n\n| Variable         | Description                                      |\n| ---------------- | ------------------------------------------------ |\n| `complexBg`      | Background color for the Complex domain          |\n| `complicatedBg`  | Background color for the Complicated domain      |\n| `clearBg`        | Background color for the Clear domain            |\n| `chaoticBg`      | Background color for the Chaotic domain          |\n| `confusionBg`    | Background color for the Confusion center region |\n| `boundaryColor`  | Color of the wavy domain boundaries              |\n| `boundaryWidth`  | Stroke width of the boundaries                   |\n| `cliffColor`     | Color of the Clear/Chaotic cliff                 |\n| `cliffWidth`     | Stroke width of the cliff                        |\n| `arrowColor`     | Color of transition arrows                       |\n| `arrowWidth`     | Stroke width of transition arrows                |\n| `labelColor`     | Color of domain name labels                      |\n| `textColor`      | Color of item and subtitle text                  |\n| `domainFontSize` | Font size of domain name labels                  |\n| `itemFontSize`   | Font size of item badges and subtitles           |\n\n## Notes\n\n- Domain names are fixed keywords. Only `complex`, `complicated`, `clear`, `chaotic`, and `confusion` are recognized.\n- Domains can be declared in any order; their position in the diagram is always the same (Complex top-left, Complicated top-right, Chaotic bottom-left, Clear bottom-right, Confusion center).\n- The `confusion` domain has a compact center ellipse. Up to 3 items are shown inside it; if more are provided a `+N more` overflow badge is displayed. In practice, the confusion domain should contain very few items — its purpose is to surface unknowns so they can be moved to one of the four main domains.\n- Self-loop transitions (e.g. `complex --> complex`) are silently ignored. Transitions must connect two different domains.\n- Handdrawn mode is not currently supported.\n- The wavy boundary rendering is deterministic: the same input always produces the same diagram, so diffs are stable across builds.\n\n## Accessibility\n\nCynefin diagrams support the standard mermaid accessibility directives:\n\n```\ncynefin-beta\n  accTitle: Cynefin framework for software delivery decisions\n  accDescr: A Cynefin map categorizing software tasks by complexity domain\n\n  complex\n    \"New feature discovery\"\n```\n","packages/mermaid/src/docs/syntax/entityRelationshipDiagram.md":"# Entity Relationship Diagrams\n\n> An entity–relationship model (or ER model) describes interrelated things of interest in a specific domain of knowledge. A basic ER model is composed of entity types (which classify the things of interest) and specifies relationships that can exist between entities (instances of those entity types) [Wikipedia](https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model).\n\nNote that practitioners of ER modelling almost always refer to _entity types_ simply as _entities_. For example the `CUSTOMER` entity _type_ would be referred to simply as the `CUSTOMER` entity. This is so common it would be inadvisable to do anything else, but technically an entity is an abstract _instance_ of an entity type, and this is what an ER diagram shows - abstract instances, and the relationships between them. This is why entities are always named using singular nouns.\n\nMermaid can render ER diagrams\n\n```mermaid-example\n---\ntitle: Order example\n---\nerDiagram\n    CUSTOMER ||--o{ ORDER : places\n    ORDER ||--|{ LINE-ITEM : contains\n    CUSTOMER }|..|{ DELIVERY-ADDRESS : uses\n```\n\nEntity names are often capitalised, although there is no accepted standard on this, and it is not required in Mermaid.\n\nRelationships between entities are represented by lines with end markers representing cardinality. Mermaid uses the most popular crow's foot notation. The crow's foot intuitively conveys the possibility of many instances of the entity that it connects to.\n\nER diagrams can be used for various purposes, ranging from abstract logical models devoid of any implementation details, through to physical models of relational database tables. It can be useful to include attribute definitions on ER diagrams to aid comprehension of the purpose and meaning of entities. These do not necessarily need to be exhaustive; often a small subset of attributes is enough. Mermaid allows them to be defined in terms of their _type_ and _name_.\n\n```mermaid-example\nerDiagram\n    CUSTOMER ||--o{ ORDER : places\n    CUSTOMER {\n        string name\n        string custNumber\n        string sector\n    }\n    ORDER ||--|{ LINE-ITEM : contains\n    ORDER {\n        int orderNumber\n        string deliveryAddress\n    }\n    LINE-ITEM {\n        string productCode\n        int quantity\n        float pricePerUnit\n    }\n```\n\nWhen including attributes on ER diagrams, you must decide whether to include foreign keys as attributes. This probably depends on how closely you are trying to represent relational table structures. If your diagram is a _logical_ model which is not meant to imply a relational implementation, then it is better to leave these out because the associative relationships already convey the way that entities are associated. For example, a JSON data structure can implement a one-to-many relationship without the need for foreign key properties, using arrays. Similarly an object-oriented programming language may use pointers or references to collections. Even for models that are intended for relational implementation, you might decide that inclusion of foreign key attributes duplicates information already portrayed by the relationships, and does not add meaning to entities. Ultimately, it's your choice.\n\n## Default theme, look and layout (v12.0.0+)\n\nEntity relationship diagrams use the `redux-color` theme and the `neo` look by default, and are laid out by [ELK](https://www.eclipse.org/elk/) rather than Dagre. Not every diagram type\ndoes — see [Per-diagram defaults](../config/theming.md#per-diagram-defaults) for the list and\nfor the order in which Mermaid decides.\n\nThe same diagram, drawn both ways:\n\n### With the defaults\n\n```mermaid-example\nerDiagram\n  CUSTOMER ||--o{ ORDER : places\n  ORDER ||--|{ LINE_ITEM : contains\n  PRODUCT ||--o{ LINE_ITEM : \"appears in\"\n  CUSTOMER {\n    string name\n    string email\n  }\n  ORDER {\n    int id\n    date placedAt\n  }\n  LINE_ITEM {\n    int quantity\n    float price\n  }\n  PRODUCT {\n    string sku\n    string title\n  }\n```\n\n### The previous appearance\n\nBoth are only defaults, so anything you set yourself wins. Naming the previous theme and look\nin a diagram's front matter draws it the way Mermaid did before:\n\n```mermaid-example\n---\nconfig:\n  theme: default\n  look: classic\n  layout: dagre\n---\nerDiagram\n  CUSTOMER ||--o{ ORDER : places\n  ORDER ||--|{ LINE_ITEM : contains\n  PRODUCT ||--o{ LINE_ITEM : \"appears in\"\n  CUSTOMER {\n    string name\n    string email\n  }\n  ORDER {\n    int id\n    date placedAt\n  }\n  LINE_ITEM {\n    int quantity\n    float price\n  }\n  PRODUCT {\n    string sku\n    string title\n  }\n```\n\nPassing the same three keys to `mermaid.initialize()` does it for every diagram on the page,\nand scoping the theme and look to one diagram type — `mermaid.initialize({ layout: 'dagre', er: { theme: 'default', look: 'classic' } })` —\ndoes it for that type alone. `layout` is a top-level option, so it applies to every diagram.\n\n## Syntax\n\n### Entities and Relationships\n\nMermaid syntax for ER diagrams is compatible with PlantUML, with an extension to label the relationship. Each statement consists of the following parts:\n\n```\n     [  : ]\n```\n\nWhere:\n\n- `first-entity` is the name of an entity. Names support any unicode characters and can include spaces if surrounded by double quotes (e.g. \"name with space\").\n- `relationship` describes the way that both entities inter-relate. See below.\n- `second-entity` is the name of the other entity.\n- `relationship-label` describes the relationship from the perspective of the first entity.\n\nFor example:\n\n```\n    PROPERTY ||--|{ ROOM : contains\n```\n\nThis statement can be read as _a property contains one or more rooms, and a room is part of one and only one property_. You can see that the label here is from the first entity's perspective: a property contains a room, but a room does not contain a property. When considered from the perspective of the second entity, the equivalent label is usually very easy to infer. (Some ER diagrams label relationships from both perspectives, but this is not supported here, and is usually superfluous).\n\nOnly the `first-entity` part of a statement is mandatory. This makes it possible to show an entity with no relationships, which can be useful during iterative construction of diagrams. If any other parts of a statement are specified, then all parts are mandatory.\n\n#### Unicode text\n\nEntity names, relationships, and attributes all support unicode text.\n\n```mermaid-example\nerDiagram\n    \"This ❤ Unicode\"\n```\n\n#### Markdown formatting\n\nMarkdown formatting and text is also supported.\n\n```mermaid-example\nerDiagram\n    \"This **is** _Markdown_\"\n```\n\n### Relationship Syntax\n\nThe `relationship` part of each statement can be broken down into three sub-components:\n\n- the cardinality of the first entity with respect to the second\n- whether the relationship confers identity on a 'child' entity\n- the cardinality of the second entity with respect to the first\n\nCardinality is a property that describes how many elements of another entity can be related to the entity in question. In the above example a `PROPERTY` can have one or more `ROOM` instances associated to it, whereas a `ROOM` can only be associated with one `PROPERTY`. In each cardinality marker there are two characters. The outermost character represents a maximum value, and the innermost character represents a minimum value. The table below summarises possible cardinalities.\n\n| Value (left) | Value (right) | Meaning                       |\n| :----------: | :-----------: | ----------------------------- |\n|    `\\|o`     |     `o\\|`     | Zero or one                   |\n|    `\\|\\|`    |    `\\|\\|`     | Exactly one                   |\n|     `}o`     |     `o{`      | Zero or more (no upper limit) |\n|    `}\\|`     |     `\\|{`     | One or more (no upper limit)  |\n\n**Aliases**\n\n| Value (left) | Value (right) | Alias for    |\n| :----------: | :-----------: | ------------ |\n| one or zero  |  one or zero  | Zero or one  |\n| zero or one  |  zero or one  | Zero or one  |\n| one or more  |  one or more  | One or more  |\n| one or many  |  one or many  | One or more  |\n|   many(1)    |    many(1)    | One or more  |\n|      1+      |      1+       | One or more  |\n| zero or more | zero or more  | Zero or more |\n| zero or many | zero or many  | Zero or more |\n|   many(0)    |    many(0)    | Zero or more |\n|      0+      |      0+       | Zero or more |\n|   only one   |   only one    | Exactly one  |\n|      1       |       1       | Exactly one  |\n\n### Identification\n\nRelationships may be classified as either _identifying_ or _non-identifying_ and these are rendered with either solid or dashed lines respectively. This is relevant when one of the entities in question cannot have independent existence without the other. For example a firm that insures people to drive cars might need to store data on `NAMED-DRIVER`s. In modelling this we might start out by observing that a `CAR` can be driven by many `PERSON` instances, and a `PERSON` can drive many `CAR`s - both entities can exist without the other, so this is a non-identifying relationship that we might specify in Mermaid as: `PERSON }|..|{ CAR : \"driver\"`. Note the two dots in the middle of the relationship that will result in a dashed line being drawn between the two entities. But when this many-to-many relationship is resolved into two one-to-many relationships, we observe that a `NAMED-DRIVER` cannot exist without both a `PERSON` and a `CAR` - the relationships become identifying and would be specified using hyphens, which translate to a solid line:\n\n| Value |     Alias for     |\n| :---: | :---------------: |\n|  --   |   _identifying_   |\n|  ..   | _non-identifying_ |\n\n**Aliases**\n\n|     Value     |     Alias for     |\n| :-----------: | :---------------: |\n|      to       |   _identifying_   |\n| optionally to | _non-identifying_ |\n\n```mermaid-example\nerDiagram\n    CAR ||--o{ NAMED-DRIVER : allows\n    PERSON }o..o{ NAMED-DRIVER : is\n```\n\n```mermaid-example\nerDiagram\n    CAR 1 to zero or more NAMED-DRIVER : allows\n    PERSON many(0) optionally to 0+ NAMED-DRIVER : is\n```\n\n### Attributes\n\nAttributes can be defined for entities by specifying the entity name followed by a block containing multiple `type name` pairs, where a block is delimited by an opening `{` and a closing `}`. The attributes are rendered inside the entity boxes. For example:\n\n```mermaid-example\nerDiagram\n    CAR ||--o{ NAMED-DRIVER : allows\n    CAR {\n        string registrationNumber\n        string make\n        string model\n    }\n    PERSON ||--o{ NAMED-DRIVER : is\n    PERSON {\n        string firstName\n        string lastName\n        int age\n    }\n```\n\nThe `type` values must begin with an alphabetic character and may contain digits, hyphens, underscores, parentheses and square brackets. The `name` values follow a similar format to `type`, but may start with an asterisk as another option to indicate an attribute is a primary key. Other than that, there are no restrictions, and there is no implicit set of valid data types.\n\n#### Optional attribute types (v11.16.0+)\n\nAttribute `type` values may end with `?` to indicate an optional or nullable type.\n\n```mermaid-example\nerDiagram\n    PERSON {\n        string firstName\n        string? middleName\n        string lastName\n    }\n```\n\n### Entity Name Aliases\n\nAn alias can be added to an entity using square brackets. If provided, the alias will be showed in the diagram instead of the entity name. Alias names follow all of the same rules as entity names.\n\n```mermaid-example\nerDiagram\n    p[Person] {\n        string firstName\n        string lastName\n    }\n    a[\"Customer Account\"] {\n        string email\n    }\n    p ||--o| a : has\n```\n\n#### Attribute Keys and Comments\n\nAttributes may also have a `key` or comment defined. Keys can be `PK`, `FK` or `UK`, for Primary Key, Foreign Key or Unique Key (markdown formatting and unicode is not supported for keys). To specify multiple key constraints on a single attribute, separate them with a comma (e.g., `PK, FK`). A `comment` is defined by double quotes at the end of an attribute. Comments themselves cannot have double-quote characters in them.\n\n```mermaid-example\nerDiagram\n    CAR ||--o{ NAMED-DRIVER : allows\n    CAR {\n        string registrationNumber PK\n        string make\n        string model\n        string[] parts\n    }\n    PERSON ||--o{ NAMED-DRIVER : is\n    PERSON {\n        string driversLicense PK \"The license #\"\n        string(99) firstName \"Only 99 characters are allowed\"\n        string lastName\n        string phone UK\n        int age\n    }\n    NAMED-DRIVER {\n        string carRegistrationNumber PK, FK\n        string driverLicence PK, FK\n    }\n    MANUFACTURER only one to zero or more CAR : makes\n```\n\n### Direction\n\nThe direction statement declares the direction of the diagram.\n\nThis declares that the diagram is oriented from top to bottom (`TB`). This can be reversed to be oriented from bottom to top (`BT`).\n\n```mermaid-example\nerDiagram\n    direction TB\n    CUSTOMER ||--o{ ORDER : places\n    CUSTOMER {\n        string name\n        string custNumber\n        string sector\n    }\n    ORDER ||--|{ LINE-ITEM : contains\n    ORDER {\n        int orderNumber\n        string deliveryAddress\n    }\n    LINE-ITEM {\n        string productCode\n        int quantity\n        float pricePerUnit\n    }\n```\n\nThis declares that the diagram is oriented from left to right (`LR`). This can be reversed to be oriented from right to left (`RL`).\n\n```mermaid-example\nerDiagram\n    direction LR\n    CUSTOMER ||--o{ ORDER : places\n    CUSTOMER {\n        string name\n        string custNumber\n        string sector\n    }\n    ORDER ||--|{ LINE-ITEM : contains\n    ORDER {\n        int orderNumber\n        string deliveryAddress\n    }\n    LINE-ITEM {\n        string productCode\n        int quantity\n        float pricePerUnit\n    }\n```\n\nPossible diagram orientations are:\n\n- TB - Top to bottom\n- BT - Bottom to top\n- RL - Right to left\n- LR - Left to right\n\n### Subgraphs (v11.17.0+)\n\nSubgraphs allow grouping entities into logical sections within an ER diagram. They are useful for organizing\ncomplex diagrams and improving readability.\n\nSubgraphs can contain entities, relationships, and even other subgraphs (nested subgraphs).\n\n```\nsubgraph title\n    graph definition\nend\n```\n\nAn example below:\n\n```mermaid-example\nerDiagram\n    subgraph title1\n        CUSTOMER\n        CUSTOMER {\n            string name\n            string custNumber\n            string sector\n        }\n    end\n    subgraph title2\n        CAR ||--o{ NAMED-DRIVER : allows\n        subgraph title3\n            PERSON\n            PERSON {\n                string firstName\n                string lastName\n                int age\n            }\n        end\n    end\n```\n\nA subgraph always has an `id`, and optionally a `title`.\n\nIf the subgraph name is a single word, it is used as both id and title:\n\n```mermaid-example\nerDiagram\n    subgraph title1\n        CUSTOMER\n    end\n```\n\nIf the subgraph identifier contains more than one word, it must be written in `quotes`. In this case, the quoted value is used both as the id and the title.\n\n```mermaid-example\nerDiagram\n    subgraph \"Customer Domain\"\n        CUSTOMER\n    end\n```\n\nYou can also set an explicit id for the subgraph.\n\n```mermaid-example\nerDiagram\n    subgraph id1 [title 1]\n        CUSTOMER\n    end\n```\n\n````note\nSubgraphs are always referenced by their id, never by their title.\n\nThis is important when defining relationships involving subgraphs.\n\n**If a subgraph id contains spaces, it must be referenced using quotes:**\n\n```\"Customer Domain\" ||--o{ ORDER : contains```\n````\n\n#### Relationships involving subgraphs\n\nIt is also possible to define relationships to and from subgraphs.\n\n```mermaid-example\nerDiagram\n    subgraph title1\n        A1 ||--|| A2 : links\n    end\n\n    subgraph title2\n        B1 ||--|| B2 : links\n    end\n\n    subgraph title3\n        C1 ||--|| C2 : links\n    end\n\n    title1 ||--|| title2 : links\n    title2 ||--|| title3 : links\n    title2 ||--|| C2 : links\n```\n\n#### Direction in subgraphs\n\nA subgraph can define its own layout direction.\n\n```mermaid-example\nerDiagram\n    direction LR\n    subgraph TOP\n        direction TB\n        subgraph B1\n            direction RL\n            I1 ||--|| F1 : links\n        end\n        subgraph B2\n            direction BT\n            I2 ||--|| F2 : links\n        end\n    end\n    A ||--|| TOP : links\n    TOP ||--|| B : links\n    B1 ||--|| B2 : links\n```\n\n### Styling a node\n\nIt is possible to apply specific styles such as a thicker border or a different background color to a node.\n\n```mermaid-example\nerDiagram\n    id1||--||id2 : label\n    style id1 fill:#f9f,stroke:#333,stroke-width:4px\n    style id2 fill:#bbf,stroke:#f66,stroke-width:2px,color:#fff,stroke-dasharray: 5 5\n```\n\nIt is also possible to attach styles to a list of nodes in one statement:\n\n```\n    style nodeId1,nodeId2 styleList\n```\n\n#### Classes\n\nMore convenient than defining the style every time is to define a class of styles and attach this class to the nodes that\nshould have a different look.\n\nA class definition looks like the example below:\n\n```\n    classDef className fill:#f9f,stroke:#333,stroke-width:4px\n```\n\nIt is also possible to define multiple classes in one statement:\n\n```\n    classDef firstClassName,secondClassName font-size:12pt\n```\n\nAttachment of a class to a node is done as per below:\n\n```\n    class nodeId1 className\n```\n\nIt is also possible to attach a class to a list of nodes in one statement:\n\n```\n    class nodeId1,nodeId2 className\n```\n\nMultiple classes can be attached at the same time as well:\n\n```\n    class nodeId1,nodeId2 className1,className2\n```\n\nA shorter form of adding a class is to attach the classname to the node using the `:::`operator as per below:\n\n```mermaid-example\nerDiagram\n    direction TB\n    CAR:::someclass {\n        string registrationNumber\n        string make\n        string model\n    }\n    PERSON:::someclass {\n        string firstName\n        string lastName\n        int age\n    }\n    HOUSE:::someclass\n\n    classDef someclass fill:#f96\n```\n\nThis form can be used when declaring relationships between entities:\n\n```mermaid-example\nerDiagram\n    CAR {\n        string registrationNumber\n        string make\n        string model\n    }\n    PERSON {\n        string firstName\n        string lastName\n        int age\n    }\n    PERSON:::foo ||--|| CAR : owns\n    PERSON o{--|| HOUSE:::bar : has\n\n    classDef foo stroke:#f00\n    classDef bar stroke:#0f0\n    classDef foobar stroke:#00f\n```\n\nSimilar to the class statement, the shorthand syntax can also apply multiple classes at once:\n\n```\n    nodeId:::className1,className2\n```\n\n### Default class\n\nIf a class is named default it will be assigned to all classes without specific class definitions.\n\n```\n    classDef default fill:#f9f,stroke:#333,stroke-width:4px;\n```\n\n> **Note:** Custom styles from style or other class statements take priority and will overwrite the default styles. (e.g. The `default` class gives nodes a background color of pink but the `blue` class will give that node a background color of blue if applied.)\n\n```mermaid-example\nerDiagram\n    CAR {\n        string registrationNumber\n        string make\n        string model\n    }\n    PERSON {\n        string firstName\n        string lastName\n        int age\n    }\n    PERSON:::foo ||--|| CAR : owns\n    PERSON o{--|| HOUSE:::bar : has\n\n    classDef default fill:#f9f,stroke-width:4px\n    classDef foo stroke:#f00\n    classDef bar stroke:#0f0\n    classDef foobar stroke:#00f\n```\n\n## Configuration\n\n### Layout\n\nThe layout of the diagram is handled by [`render()`](../config/setup/mermaid/interfaces/Mermaid.md#render). The default layout is the ELK (Eclipse Layout Kernel) layout, which suits larger and more-complex diagrams. For more information, see [Customizing ELK Layout](../intro/syntax-reference.md#customizing-elk-layout).\n\nTo use the classic Dagre layout instead, set it in your YAML frontmatter's `config`:\n\n```yaml\n---\nconfig:\n  layout: dagre\n---\n```\n\nYour Mermaid code should be similar to the following:\n\n```mermaid-example\n---\ntitle: Order example\nconfig:\n    layout: dagre\n---\nerDiagram\n    CUSTOMER ||--o{ ORDER : places\n    ORDER ||--|{ LINE-ITEM : contains\n    CUSTOMER }|..|{ DELIVERY-ADDRESS : uses\n```\n\n\n","packages/mermaid/src/docs/syntax/eventmodeling.md":"# Event Modeling Diagram (v11.15.0+)\n\n## Introduction\n\n> **Event Modeling** (EM) is a method of describing systems using an example of how information has changed within them over time. Event Modeling specifically omits transient details and looks at what the information flow is and what the user sees at any particular point in time.\n\nYou can read more at [Event Modeling web page](https://eventmodeling.org/).\n\nEvent Modeling diagram is composed of a few main entities:\n\n- Trigger - UI and Processor\n- Command\n- View / Read Model\n- Event\n\nEntities are organized in swimlanes forming a timeline usually based on the following patterns:\n\n- State View\n- State Change\n- Translation\n- Automation\n\nYou can find more details in the [cheat sheet](https://eventmodeling.org/posts/event-modeling-cheatsheet/).\n\nThe purpose of the Domain Specific Language (DSL) supporting the drawing of the Event Modeling diagram is the rapid creation. Relations among the entities are inferred by default, so the distraction while you design is limited. Further detail to the entities can be added gradually.\n\nThe grammar for the DSL is also maintained in a [separate project](https://github.com/lgazo/event-modeling-dsl) with the intention to provide also different types of output, VS Code (and potentially other) IDEs, etc.\n\n## Basic Syntax\n\nThe DSL supports two types of syntaxes - compact and relaxed one. Both will be mentioned in the examples and both can be used interchangeably.\n\n### Timeline\n\nThe timeline is the key part of the diagram and it is composed of **Time Frame** definitions. Speedy Time Frame typing is the key of the compact notation. For compact notation you type the `tf` token. For the relaxed notation you type `timeframe` token.\n\n```md\neventmodeling\n\ntf 01 ui CartUI\ntf 02 cmd AddItem\ntf 03 evt ItemAdded\n```\n\nrendering to\n\n```mermaid\neventmodeling\n\ntf 01 ui CartUI\ntf 02 cmd AddItem\ntf 03 evt ItemAdded\n```\n\nEach Time Frame is referenced by a **unique number** in order to distinguish one from another and also to be able to reference it when needed. Depending on the complexity of the diagram it should be enough to have just two digit number or more. Imagine you are typing a BASIC program on your ZX Spectrum always starting with a two digit number, but the order of the numbers does not matter, just the uniqueness in the whole timeline.\n\nReusing a number for another Time Frame or Reset Frame produces an error. Give each frame its own number before referring to it with `->>`.\n\nThe Time Frame also contains an **Entity Identifier**, e.g. in case of `01` Time Frame it is `CartUI`. One Entity Identifier can be used multiple times in the timeline for example when you want to express invocations of the same event in different points in time.\n\nRelaxed notation would look like this:\n\n```md\neventmodeling\n\ntimeframe 01 ui CartUI\ntimeframe 02 command AddItem\ntimeframe 03 event ItemAdded\n```\n\n### Inline data\n\nIt is possible to provide data examples for individual Time Frames. An Inline Data is wrapped in curly brackets on the same line as the Time Frame.\n\nCompact version:\n\n```mermaid-example\neventmodeling\n\ntf 01 ui CartUI\ntf 02 cmd AddItem { description: string }\ntf 03 evt ItemAdded { description: string }\n```\n\nRelaxed version:\n\n```mermaid-example\neventmodeling\n\ntimeframe 01 ui CartUI\ntimeframe 02 command AddItem { description: string }\ntimeframe 03 event ItemAdded { description: string }\n```\n\n### Data block\n\nIf you need to provide more complex data description, you can define the **Data Block** separately. Data Block is referenced from a Time Frame by providing the identifier inside of double-square brackets `[[identifier]]`, similar to wiki links convention in Markdown.\n\nIn case the same entity is repeated you need to uniquely identify the data blocks, therefore the Data Block identifier is suffixed with a number.\n\nCompact version:\n\n```mermaid-example\neventmodeling\n\ntf 01 ui CartUI\ntf 02 cmd AddItem [[AddItem01]]\ntf 03 evt ItemAdded [[ItemAdded]]\ntf 04 cmd AddItem [[AddItem02]]\ntf 05 evt ItemAdded [[ItemAdded]]\n\ndata AddItem01 {\n  description: 'john'\n  image: 'avatar_john'\n  price: 20.4\n}\n\ndata AddItem02 {\n  description: 'jack'\n  image: 'avatar_jack'\n  price: 12.5\n}\n\ndata ItemAdded {\n  description: string\n  image: string\n  price: number\n}\n```\n\nRelaxed version:\n\n```mermaid-example\neventmodeling\n\ntimeframe 01 ui CartUI\ntimeframe 02 command AddItem [[AddItem01]]\ntimeframe 03 event ItemAdded [[ItemAdded]]\ntimeframe 04 command AddItem [[AddItem02]]\ntimeframe 05 event ItemAdded [[ItemAdded]]\n\ndata AddItem01 {\n  description: 'john'\n  image: 'avatar_john'\n  price: 20.4\n}\n\ndata AddItem02 {\n  description: 'jack'\n  image: 'avatar_jack'\n  price: 12.5\n}\n\ndata ItemAdded {\n  description: string\n  image: string\n  price: number\n}\n```\n\n### Resetting the flow\n\nBy default the diagram builds the relations based on the inference. But modeling a more complex business flow requires to break such inference from time to time. For that you can use a different type of Time Frame called **Reset Frame**. It is represented by a `rf` / `resetframe` token.\n\nA reset frame stops the inferred relation from the preceding frame. You can still connect it to a specific earlier frame with `->>`.\n\nCompact version:\n\n```mermaid-example\neventmodeling\n\ntf 01 ui CartUI\ntf 02 cmd AddItem\ntf 03 evt ItemAdded\n\nrf 04 evt External.InventoryChanged\ntf 05 pcr InventoryProcessor\ntf 06 cmd ChangeInventory\ntf 07 evt Cart.InventoryChanged\n```\n\nRelaxed version:\n\n```mermaid-example\neventmodeling\n\ntimeframe 01 ui CartUI\ntimeframe 02 command AddItem\ntimeframe 03 event ItemAdded\n\nresetframe 04 event External.InventoryChanged\ntimeframe 05 processor InventoryProcessor\ntimeframe 06 command ChangeInventory\ntimeframe 07 event Cart.InventoryChanged\n```\n\nFor example, this read model receives input from `ItemAdded` without inferring a relation from `OtherUI`:\n\n```mermaid-example\neventmodeling\n\ntf 01 evt ItemAdded\ntf 02 ui OtherUI\nrf 03 rmo CartItems ->> 01\n```\n\n### Multiple relations\n\nThere are situations where you need to specify multiple relations for an entity. For example when a **Read Model** is built of multiple **Events**. You can use `->>` token for that.\n\n```mermaid-example\neventmodeling\n\nrf 02 evt CartCreated\nrf 03 evt ItemAdded\nrf 04 evt ItemRemoved\nrf 05 evt CartCleared\ntf 01 rmo CartUI ->> 02 ->> 03 ->> 04 ->> 05\n```\n\n## Event Modeling patterns\n\nThis chapter briefly summarizes each Event Modeling pattern.\n\n### State Change\n\n```mermaid-example\neventmodeling\n\ntf 01 ui CartUI\ntf 02 cmd AddItem\ntf 03 evt ItemAdded\n```\n\n### State View\n\n```mermaid-example\neventmodeling\n\ntf 03 evt ItemAdded\ntf 02 rmo CartItems\ntf 04 ui CartUI\n```\n\n### Translation\n\n```mermaid-example\neventmodeling\n\ntf 03 evt External.InventoryChanged\ntf 02 pcr InventoryProcessor\ntf 04 cmd ChangeInventory\ntf 05 evt Cart.InventoryChanged\n```\n\n## Details of the Syntax\n\n### Entity types\n\nEntity type is determined by the third column in the Time Frame grammar.\n\nCompact version:\n\n```md\ntf 01 pcr InventoryProcessor\n```\n\nRelaxed version:\n\n```md\ntimeframe 01 processor InventoryProcessor\n```\n\nEntities are assigned to default swimlanes unless a **Namespace** is specified in the Entity Identifier.\n\nThere are the following types available:\n\n- `ui`: UI - belongs to UI/Automation swimlane\n- `pcr` / `processor`: Processor - belongs to UI/Automation swimlane\n- `cmd` / `command`: Command - belongs to Command/Read Model swimlane\n- `rmo` / `readmodel`: Read Model - belongs to Command/Read Model swimlane\n- `evt` / `event`: Event - belongs to Events swimlane\n\n### Swimlanes and Namespaces\n\nThere are three basic **Swimlanes** inferred from the Entity Type.\n\n- UI/Automation\n- Command/Read Model\n- Events\n\nAs your diagram grows and you explore the depths of a particular software system, you want to categorize your Entities as well. In order to do that, you can use **Namespace** identifier as part of the Entity Identifier.\n\n```md\nInventory.InventoryChanged\n```\n\n**Namespace** is the first part before the `.` of the Entity Identifier. Each combination of the Namespace and Entity type forms new Swimlane. The order how they are specified in the text definition specifies the order of the Swimlanes in the diagram.\n\n```mermaid-example\neventmodeling\n\nrf 01 evt Inventory.InventoryChanged\nrf 02 evt External.InventoryChanged\n```\n\n### Data block data types\n\nA **Data** is always wrapped in curly brackets. It can be prepended by a data type in backticks. The pattern applies for **Inline Data** as well as for **Data Block**.\n\n```md\ntf 01 rmo UserAdded `json`{ \"name\": \"foo\" }\n```\n\nor for Data Block\n\n```md\ndata UserAdded01 `json`{\n\"name\": \"foo\"\n}\n```\n\n```warning\nThere is no special treatment in the diagram renderer at the moment for a specific data type.\n```\n\nSupported types are:\n\n- `json`\n- `jsobj`\n- `figma`\n- `salt`\n- `uri`\n- `md`\n- `html`\n- `text`\n","packages/mermaid/src/docs/syntax/examples.md":"# Examples\n\nThis page contains a collection of examples of diagrams and charts that can be created through mermaid and its myriad applications.\n\n**If you wish to learn how to support mermaid on your webpage, read the [Beginner's Guide](../config/usage.md?id=usage).**\n\n**If you wish to learn about mermaid's syntax, Read the [Diagram Syntax](../syntax/flowchart.md?id=flowcharts-basic-syntax) section.**\n\n## Basic Pie Chart\n\n```mermaid-example\npie title NETFLIX\n         \"Time spent looking for movie\" : 90\n         \"Time spent watching it\" : 10\n```\n\n```mermaid-example\npie title What Voldemort doesn't have?\n         \"FRIENDS\" : 2\n         \"FAMILY\" : 3\n         \"NOSE\" : 45\n```\n\n## Basic sequence diagram\n\n```mermaid-example\nsequenceDiagram\n    Alice ->> Bob: Hello Bob, how are you?\n    Bob-->>John: How about you John?\n    Bob--x Alice: I am good thanks!\n    Bob-x John: I am good thanks!\n    Note right of John: Bob thinks a long
long time, so long
that the text does
not fit on a row.\n\n    Bob-->Alice: Checking with John...\n    Alice->John: Yes... John, how are you?\n```\n\n## Basic flowchart\n\n```mermaid-example\ngraph LR\n    A[Square Rect] -- Link text --> B((Circle))\n    A --> C(Round Rect)\n    B --> D{Rhombus}\n    C --> D\n```\n\n## Larger flowchart with some styling\n\n```mermaid-example\ngraph TB\n    sq[Square shape] --> ci((Circle shape))\n\n    subgraph A\n        od>Odd shape]-- Two line
edge comment --> ro\n        di{Diamond with 
 line break} -.-> ro(Rounded
square
shape)\n        di==>ro2(Rounded square shape)\n    end\n\n    %% Notice that no text in shape are added here instead that is appended further down\n    e --> od3>Really long text with linebreak
in an Odd shape]\n\n    %% Comments after double percent signs\n    e((Inner / circle
and some odd 
special characters)) --> f(,.?!+-*ز)\n\n    cyr[Cyrillic]-->cyr2((Circle shape Начало));\n\n     classDef green fill:#9f6,stroke:#333,stroke-width:2px;\n     classDef orange fill:#f96,stroke:#333,stroke-width:4px;\n     class sq,e green\n     class di orange\n```\n\n## SequenceDiagram: Loops, alt and opt\n\n```mermaid-example\nsequenceDiagram\n    loop Daily query\n        Alice->>Bob: Hello Bob, how are you?\n        alt is sick\n            Bob->>Alice: Not so good :(\n        else is well\n            Bob->>Alice: Feeling fresh like a daisy\n        end\n\n        opt Extra response\n            Bob->>Alice: Thanks for asking\n        end\n    end\n```\n\n## SequenceDiagram: Message to self in loop\n\n```mermaid-example\nsequenceDiagram\n    participant Alice\n    participant Bob\n    Alice->>John: Hello John, how are you?\n    loop HealthCheck\n        John->>John: Fight against hypochondria\n    end\n    Note right of John: Rational thoughts
prevail...\n    John-->>Alice: Great!\n    John->>Bob: How about you?\n    Bob-->>John: Jolly good!\n```\n\n## Sequence Diagram: Blogging app service communication\n\n```mermaid-example\nsequenceDiagram\n    participant web as Web Browser\n    participant blog as Blog Service\n    participant account as Account Service\n    participant mail as Mail Service\n    participant db as Storage\n\n    Note over web,db: The user must be logged in to submit blog posts\n    web->>+account: Logs in using credentials\n    account->>db: Query stored accounts\n    db->>account: Respond with query result\n\n    alt Credentials not found\n        account->>web: Invalid credentials\n    else Credentials found\n        account->>-web: Successfully logged in\n\n        Note over web,db: When the user is authenticated, they can now submit new posts\n        web->>+blog: Submit new post\n        blog->>db: Store post data\n\n        par Notifications\n            blog--)mail: Send mail to blog subscribers\n            blog--)db: Store in-site notifications\n        and Response\n            blog-->>-web: Successfully posted\n        end\n    end\n\n```\n\n## A commit flow diagram.\n\n```mermaid-example\ngitGraph:\n    commit \"Ashish\"\n    branch newbranch\n    checkout newbranch\n    commit id:\"1111\"\n    commit tag:\"test\"\n    checkout main\n    commit type: HIGHLIGHT\n    commit\n    merge newbranch\n    commit\n    branch b2\n    commit\n```\n\n\n","packages/mermaid/src/docs/syntax/flowchart.md":"---\ntitle: Flowcharts Syntax\n---\n\n# Flowcharts - Basic Syntax\n\nFlowcharts are composed of **nodes** (geometric shapes) and **edges** (arrows or lines). The Mermaid code defines how nodes and edges are made and accommodates different arrow types, multi-directional arrows, and any linking to and from subgraphs.\n\n```warning\nIf you are using the word \"end\" in a Flowchart node, capitalize the entire word or any of the letters (e.g., \"End\" or \"END\"), or apply this [workaround](https://github.com/mermaid-js/mermaid/issues/1444#issuecomment-639528897). Typing \"end\" in all lowercase letters will break the Flowchart.\n```\n\n```warning\nIf you are using the letter \"o\" or \"x\" as the first letter in a connecting Flowchart node, add a space before the letter or capitalize the letter (e.g., \"dev--- ops\", \"dev---Ops\").\n\nTyping \"A---oB\" will create a [circle edge](#circle-edge-example).\n\nTyping \"A---xB\" will create a [cross edge](#cross-edge-example).\n```\n\n### A node (default)\n\n```mermaid-example\n---\ntitle: Node\n---\nflowchart LR\n    id\n```\n\n```note\nThe id is what is displayed in the box.\n```\n\n```tip\nInstead of `flowchart` one can also use `graph`.\n```\n\n### A node with text\n\nIt is also possible to set text in the box that differs from the id. If this is done several times, it is the last text\nfound for the node that will be used. Also if you define edges for the node later on, you can omit text definitions. The\none previously defined will be used when rendering the box.\n\n```mermaid-example\n---\ntitle: Node with text\n---\nflowchart LR\n    id1[This is the text in the box]\n```\n\n#### Unicode text\n\nUse `\"` to enclose the unicode text.\n\n```mermaid-example\nflowchart LR\n    id[\"This ❤ Unicode\"]\n```\n\n#### Markdown formatting\n\nUse double quotes and backticks \"\\` text \\`\" to enclose the markdown text.\n\n```mermaid-example\n---\nconfig:\n  htmlLabels: false\n---\nflowchart LR\n    markdown[\"`This **is** _Markdown_`\"]\n    newLines[\"`Line1\n    Line 2\n    Line 3`\"]\n    markdown --> newLines\n```\n\n### Direction\n\nThis statement declares the direction of the Flowchart.\n\nThis declares the flowchart is oriented from top to bottom (`TD` or `TB`).\n\n```mermaid-example\nflowchart TD\n    Start --> Stop\n```\n\nThis declares the flowchart is oriented from left to right (`LR`).\n\n```mermaid-example\nflowchart LR\n    Start --> Stop\n```\n\nPossible FlowChart orientations are:\n\n- TB - Top to bottom\n- TD - Top-down/ same as top to bottom\n- BT - Bottom to top\n- RL - Right to left\n- LR - Left to right\n\n## Default theme, look and layout (v12.0.0+)\n\nFlowcharts use the `redux-color` theme and the `neo` look by default, and are laid out by [ELK](https://www.eclipse.org/elk/) rather than Dagre. Not every diagram type\ndoes — see [Per-diagram defaults](../config/theming.md#per-diagram-defaults) for the list and\nfor the order in which Mermaid decides.\n\nThe same diagram, drawn both ways:\n\n### With the defaults\n\n```mermaid-example\nflowchart LR\n  subgraph Client\n    UI[Web app]\n    Cache[(Local cache)]\n  end\n  subgraph Services\n    API[API gateway]\n    Auth[Auth service]\n    Orders[Order service]\n  end\n  subgraph Storage\n    DB[(Orders DB)]\n  end\n  UI --> API\n  UI --> Cache\n  API --> Auth\n  API --> Orders\n  Orders --> DB\n  Auth -. token .-> UI\n```\n\n### The previous appearance\n\nBoth are only defaults, so anything you set yourself wins. Naming the previous theme and look\nin a diagram's front matter draws it the way Mermaid did before:\n\n```mermaid-example\n---\nconfig:\n  theme: default\n  look: classic\n  layout: dagre\n---\nflowchart LR\n  subgraph Client\n    UI[Web app]\n    Cache[(Local cache)]\n  end\n  subgraph Services\n    API[API gateway]\n    Auth[Auth service]\n    Orders[Order service]\n  end\n  subgraph Storage\n    DB[(Orders DB)]\n  end\n  UI --> API\n  UI --> Cache\n  API --> Auth\n  API --> Orders\n  Orders --> DB\n  Auth -. token .-> UI\n```\n\nPassing the same three keys to `mermaid.initialize()` does it for every diagram on the page,\nand scoping the theme and look to one diagram type — `mermaid.initialize({ layout: 'dagre', flowchart: { theme: 'default', look: 'classic' } })` —\ndoes it for that type alone. `layout` is a top-level option, so it applies to every diagram.\n\n## Node shapes\n\n### A node with round edges\n\n```mermaid-example\nflowchart LR\n    id1(This is the text in the box)\n```\n\n### A stadium-shaped node\n\n```mermaid-example\nflowchart LR\n    id1([This is the text in the box])\n```\n\n### A node in a subroutine shape\n\n```mermaid-example\nflowchart LR\n    id1[[This is the text in the box]]\n```\n\n### A node in a cylindrical shape\n\n```mermaid-example\nflowchart LR\n    id1[(Database)]\n```\n\n### A node in the form of a circle\n\n```mermaid-example\nflowchart LR\n    id1((This is the text in the circle))\n```\n\n### A node in an asymmetric shape\n\n```mermaid-example\nflowchart LR\n    id1>This is the text in the box]\n```\n\nCurrently only the shape above is possible and not its mirror. _This might change with future releases._\n\n### A node (rhombus)\n\n```mermaid-example\nflowchart LR\n    id1{This is the text in the box}\n```\n\n### A hexagon node\n\n```mermaid-example\nflowchart LR\n    id1{{This is the text in the box}}\n```\n\n### Parallelogram\n\n```mermaid-example\nflowchart TD\n    id1[/This is the text in the box/]\n```\n\n### Parallelogram alt\n\n```mermaid-example\nflowchart TD\n    id1[\\This is the text in the box\\]\n```\n\n### Trapezoid\n\n```mermaid-example\nflowchart TD\n    A[/Christmas\\]\n```\n\n### Trapezoid alt\n\n```mermaid-example\nflowchart TD\n    B[\\Go shopping/]\n```\n\n### Double circle\n\n```mermaid-example\nflowchart TD\n    id1(((This is the text in the circle)))\n```\n\n## Expanded Node Shapes in Mermaid Flowcharts (v11.3.0+)\n\nMermaid introduces 30 new shapes to enhance the flexibility and precision of flowchart creation. These new shapes provide more options to represent processes, decisions, events, data storage visually, and other elements within your flowcharts, improving clarity and semantic meaning.\n\nNew Syntax for Shape Definition\n\nMermaid now supports a general syntax for defining shape types to accommodate the growing number of shapes. This syntax allows you to assign specific shapes to nodes using a clear and flexible format:\n\n```\nA@{ shape: rect }\n```\n\nThis syntax creates a node A as a rectangle. It renders in the same way as `A[\"A\"]`, or `A`.\n\n### Complete List of New Shapes\n\nBelow is a comprehensive list of the newly introduced shapes and their corresponding semantic meanings, short names, and aliases:\n\n\n\n### Example Flowchart with New Shapes\n\nHere’s an example flowchart that utilizes some of the newly introduced shapes:\n\n```mermaid-example\nflowchart RL\n    A@{ shape: manual-file, label: \"File Handling\"}\n    B@{ shape: manual-input, label: \"User Input\"}\n    C@{ shape: docs, label: \"Multiple Documents\"}\n    D@{ shape: procs, label: \"Process Automation\"}\n    E@{ shape: paper-tape, label: \"Paper Records\"}\n```\n\n### Process\n\n```mermaid-example\nflowchart TD\n    A@{ shape: rect, label: \"This is a process\" }\n```\n\n### Event\n\n```mermaid-example\nflowchart TD\n    A@{ shape: rounded, label: \"This is an event\" }\n```\n\n### Terminal Point (Stadium)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: stadium, label: \"Terminal point\" }\n```\n\n### Subprocess\n\n```mermaid-example\nflowchart TD\n    A@{ shape: subproc, label: \"This is a subprocess\" }\n```\n\n### Database (Cylinder)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: cyl, label: \"Database\" }\n```\n\n### Start (Circle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: circle, label: \"Start\" }\n```\n\n### Odd\n\n```mermaid-example\nflowchart TD\n    A@{ shape: odd, label: \"Odd shape\" }\n```\n\n### Decision (Diamond)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: diamond, label: \"Decision\" }\n```\n\n### Prepare Conditional (Hexagon)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: hex, label: \"Prepare conditional\" }\n```\n\n### Data Input/Output (Lean Right)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: lean-r, label: \"Input/Output\" }\n```\n\n### Data Input/Output (Lean Left)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: lean-l, label: \"Output/Input\" }\n```\n\n### Datastore (Top and bottom border)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: datastore, label: \"Datastore\" }\n```\n\n### Priority Action (Trapezoid Base Bottom)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: trap-b, label: \"Priority action\" }\n```\n\n### Manual Operation (Trapezoid Base Top)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: trap-t, label: \"Manual operation\" }\n```\n\n### Stop (Double Circle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: dbl-circ, label: \"Stop\" }\n```\n\n### Text Block\n\n```mermaid-example\nflowchart TD\n    A@{ shape: text, label: \"This is a text block\" }\n```\n\n### Card (Notched Rectangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: notch-rect, label: \"Card\" }\n```\n\n### Lined/Shaded Process\n\n```mermaid-example\nflowchart TD\n    A@{ shape: lin-rect, label: \"Lined process\" }\n```\n\n### Start (Small Circle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: sm-circ, label: \"Small start\" }\n```\n\n### Stop (Framed Circle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: framed-circle, label: \"Stop\" }\n```\n\n### Fork/Join (Long Rectangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: fork, label: \"Fork or Join\" }\n```\n\n### Collate (Hourglass)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: hourglass, label: \"Collate\" }\n```\n\n### Comment (Curly Brace)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: comment, label: \"Comment\" }\n```\n\n### Comment Right (Curly Brace Right)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: brace-r, label: \"Comment\" }\n```\n\n### Comment with braces on both sides\n\n```mermaid-example\nflowchart TD\n    A@{ shape: braces, label: \"Comment\" }\n```\n\n### Com Link (Lightning Bolt)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: bolt, label: \"Communication link\" }\n```\n\n### Document\n\n```mermaid-example\nflowchart TD\n    A@{ shape: doc, label: \"Document\" }\n```\n\n### Delay (Half-Rounded Rectangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: delay, label: \"Delay\" }\n```\n\n### Direct Access Storage (Horizontal Cylinder)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: das, label: \"Direct access storage\" }\n```\n\n### Disk Storage (Lined Cylinder)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: lin-cyl, label: \"Disk storage\" }\n```\n\n### Display (Curved Trapezoid)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: curv-trap, label: \"Display\" }\n```\n\n### Divided Process (Divided Rectangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: div-rect, label: \"Divided process\" }\n```\n\n### Extract (Small Triangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: tri, label: \"Extract\" }\n```\n\n### Internal Storage (Window Pane)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: win-pane, label: \"Internal storage\" }\n```\n\n### Junction (Filled Circle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: f-circ, label: \"Junction\" }\n```\n\n### Lined Document\n\n```mermaid-example\nflowchart TD\n    A@{ shape: lin-doc, label: \"Lined document\" }\n```\n\n### Loop Limit (Notched Pentagon)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: notch-pent, label: \"Loop limit\" }\n```\n\n### Manual File (Flipped Triangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: flip-tri, label: \"Manual file\" }\n```\n\n### Manual Input (Sloped Rectangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: sl-rect, label: \"Manual input\" }\n```\n\n### Multi-Document (Stacked Document)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: docs, label: \"Multiple documents\" }\n```\n\n### Multi-Process (Stacked Rectangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: processes, label: \"Multiple processes\" }\n```\n\n### Paper Tape (Flag)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: flag, label: \"Paper tape\" }\n```\n\n### Stored Data (Bow Tie Rectangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: bow-rect, label: \"Stored data\" }\n```\n\n### Summary (Crossed Circle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: cross-circ, label: \"Summary\" }\n```\n\n### Tagged Document\n\n```mermaid-example\nflowchart TD\n    A@{ shape: tag-doc, label: \"Tagged document\" }\n```\n\n### Tagged Process (Tagged Rectangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: tag-rect, label: \"Tagged process\" }\n```\n\n## Special shapes in Mermaid Flowcharts (v11.3.0+)\n\nMermaid also introduces 2 special shapes to enhance your flowcharts: **icon** and **image**. These shapes allow you to include icons and images directly within your flowcharts, providing more visual context and clarity.\n\n### Icon Shape\n\nYou can use the `icon` shape to include an icon in your flowchart. To use icons, you need to register the icon pack first. Follow the instructions to [add custom icons](../config/icons.md). The syntax for defining an icon shape is as follows:\n\n```mermaid-example\nflowchart TD\n    A@{ icon: \"fa:user\", form: \"square\", label: \"User Icon\", pos: \"t\", h: 60 }\n```\n\n#### Parameters\n\n- **icon**: The name of the icon from the registered icon pack.\n- **form**: Specifies the background shape of the icon. If not defined there will be no background to icon. Options include:\n  - `square`\n  - `circle`\n  - `rounded`\n- **label**: The text label associated with the icon. This can be any string. If not defined, no label will be displayed.\n- **pos**: The position of the label. If not defined label will default to bottom of icon. Possible values are:\n  - `t`\n  - `b`\n- **h**: The height of the icon. If not defined this will default to 48 which is minimum.\n\n### Image Shape\n\nYou can use the `image` shape to include an image in your flowchart. The syntax for defining an image shape is as follows:\n\n```\nflowchart TD\n    A@{ img: \"https://example.com/image.png\", label: \"Image Label\", pos: \"t\", w: 60, h: 60, constraint: \"off\" }\n```\n\n#### Parameters\n\n- **img**: The URL of the image to be displayed.\n- **label**: The text label associated with the image. This can be any string. If not defined, no label will be displayed.\n- **pos**: The position of the label. If not defined, the label will default to the bottom of the image. Possible values are:\n  - `t`\n  - `b`\n- **w**: The width of the image. If not defined, this will default to the natural width of the image.\n- **h**: The height of the image. If not defined, this will default to the natural height of the image.\n- **constraint**: Determines if the image should constrain the node size. This setting also ensures the image maintains its original aspect ratio, adjusting the width (`w`) accordingly to the height (`h`). If not defined, this will default to `off` Possible values are:\n  - `on`\n  - `off`\n\nIf you want to resize an image, but keep the same aspect ratio, set `h`, and set `constraint: on` to constrain the aspect ratio. E.g.\n\n```mermaid\nflowchart TD\n  %% My image with a constrained aspect ratio\n  A@{ img: \"https://mermaid.js.org/favicon.svg\", label: \"My example image label\", pos: \"t\", h: 60, constraint: \"on\" }\n```\n\n## Links between nodes\n\nNodes can be connected with links/edges. It is possible to have different types of links or attach a text string to a link.\n\n### A link with arrow head\n\n```mermaid-example\nflowchart LR\n    A-->B\n```\n\n### An open link\n\n```mermaid-example\nflowchart LR\n    A --- B\n```\n\n### Text on links\n\n```mermaid-example\nflowchart LR\n    A-- This is the text! ---B\n```\n\nor\n\n```mermaid-example\nflowchart LR\n    A---|This is the text|B\n```\n\n### A link with arrow head and text\n\n```mermaid-example\nflowchart LR\n    A-->|text|B\n```\n\nor\n\n```mermaid-example\nflowchart LR\n    A-- text -->B\n```\n\n### Dotted link\n\n```mermaid-example\nflowchart LR\n   A-.->B;\n```\n\n### Dotted link with text\n\n```mermaid-example\nflowchart LR\n   A-. text .-> B\n```\n\n### Thick link\n\n```mermaid-example\nflowchart LR\n   A ==> B\n```\n\n### Thick link with text\n\n```mermaid-example\nflowchart LR\n   A == text ==> B\n```\n\n### An invisible link\n\nThis can be a useful tool in some instances where you want to alter the default positioning of a node.\n\n```mermaid-example\nflowchart LR\n    A ~~~ B\n```\n\n### Chaining of links\n\nIt is possible declare many links in the same line as per below:\n\n```mermaid-example\nflowchart LR\n   A -- text --> B -- text2 --> C\n```\n\nIt is also possible to declare multiple nodes links in the same line as per below:\n\n```mermaid-example\nflowchart LR\n   a --> b & c--> d\n```\n\nYou can then describe dependencies in a very expressive way. Like the one-liner below:\n\n```mermaid-example\nflowchart TB\n    A & B--> C & D\n```\n\nIf you describe the same diagram using the basic syntax, it will take four lines. A\nword of warning, one could go overboard with this making the flowchart harder to read in\nmarkdown form. The Swedish word `lagom` comes to mind. It means, not too much and not too little.\nThis goes for expressive syntaxes as well.\n\n```mermaid\nflowchart TB\n    A --> C\n    A --> D\n    B --> C\n    B --> D\n```\n\n### Attaching an ID to Edges\n\nMermaid now supports assigning IDs to edges, similar to how IDs and metadata can be attached to nodes. This feature lays the groundwork for more advanced styling, classes, and animation capabilities on edges.\n\n**Syntax:**\n\nTo give an edge an ID, prepend the edge syntax with the ID followed by an `@` character. For example:\n\n```mermaid\nflowchart LR\n  A e1@--> B\n```\n\nIn this example, `e1` is the ID of the edge connecting `A` to `B`. You can then use this ID in later definitions or style statements, just like with nodes.\n\n### Turning an Animation On\n\nOnce you have assigned an ID to an edge, you can turn on animations for that edge by defining the edge’s properties:\n\n```mermaid\nflowchart LR\n  A e1@==> B\n  e1@{ animate: true }\n```\n\nThis tells Mermaid that the edge `e1` should be animated.\n\n### Selecting Type of Animation\n\nIn the initial version, two animation speeds are supported: `fast` and `slow`. Selecting a specific animation type is a shorthand for enabling animation and setting the animation speed in one go.\n\n**Examples:**\n\n```mermaid\nflowchart LR\n  A e1@--> B\n  e1@{ animation: fast }\n```\n\nThis is equivalent to `{ animate: true, animation: fast }`.\n\n### Using classDef Statements for Animations\n\nYou can also animate edges by assigning a class to them and then defining animation properties in a `classDef` statement. For example:\n\n```mermaid\nflowchart LR\n  A e1@--> B\n  classDef animate stroke-dasharray: 9,5,stroke-dashoffset: 900,animation: dash 25s linear infinite;\n  class e1 animate\n```\n\nIn this snippet:\n\n- `e1@-->` creates an edge with ID `e1`.\n- `classDef animate` defines a class named `animate` with styling and animation properties.\n- `class e1 animate` applies the `animate` class to the edge `e1`.\n\n**Note on Escaping Commas:**\nWhen setting the `stroke-dasharray` property, remember to escape commas as `\\,` since commas are used as delimiters in Mermaid’s style definitions.\n\n## New arrow types\n\nThere are new types of arrows supported:\n\n- circle edge\n- cross edge\n\n### Circle edge example\n\n```mermaid-example\nflowchart LR\n    A --o B\n```\n\n### Cross edge example\n\n```mermaid-example\nflowchart LR\n    A --x B\n```\n\n## Multi directional arrows\n\nThere is the possibility to use multidirectional arrows.\n\n```mermaid-example\nflowchart LR\n    A o--o B\n    B <--> C\n    C x--x D\n```\n\n### Minimum length of a link\n\nEach node in the flowchart is ultimately assigned to a rank in the rendered\ngraph, i.e. to a vertical or horizontal level (depending on the flowchart\norientation), based on the nodes to which it is linked. By default, links\ncan span any number of ranks, but you can ask for any link to be longer\nthan the others by adding extra dashes in the link definition.\n\nIn the following example, two extra dashes are added in the link from node _B_\nto node _E_, so that it spans two more ranks than regular links:\n\n```mermaid-example\nflowchart TD\n    A[Start] --> B{Is it?}\n    B -->|Yes| C[OK]\n    C --> D[Rethink]\n    D --> B\n    B ---->|No| E[End]\n```\n\n> **Note** Links may still be made longer than the requested number of ranks\n> by the rendering engine to accommodate other requests.\n\nWhen the link label is written in the middle of the link, the extra dashes must\nbe added on the right side of the link. The following example is equivalent to\nthe previous one:\n\n```mermaid-example\nflowchart TD\n    A[Start] --> B{Is it?}\n    B -- Yes --> C[OK]\n    C --> D[Rethink]\n    D --> B\n    B -- No ----> E[End]\n```\n\nFor dotted or thick links, the characters to add are equals signs or dots,\nas summed up in the following table:\n\n| Length            |   1    |    2    |    3     |\n| ----------------- | :----: | :-----: | :------: |\n| Normal            | `---`  | `----`  | `-----`  |\n| Normal with arrow | `-->`  | `--->`  | `---->`  |\n| Thick             | `===`  | `====`  | `=====`  |\n| Thick with arrow  | `==>`  | `===>`  | `====>`  |\n| Dotted            | `-.-`  | `-..-`  | `-...-`  |\n| Dotted with arrow | `-.->` | `-..->` | `-...->` |\n\n## Special characters that break syntax\n\nIt is possible to put text within quotes in order to render more troublesome characters. As in the example below:\n\n```mermaid-example\nflowchart LR\n    id1[\"This is the (text) in the box\"]\n```\n\n### Entity codes to escape characters\n\nIt is possible to escape characters using the syntax exemplified here.\n\n```mermaid-example\n    flowchart LR\n        A[\"A double quote:#quot;\"] --> B[\"A dec char:#9829;\"]\n```\n\nNumbers given are base 10, so `#` can be encoded as `#35;`. It is also supported to use HTML character names.\n\n## Subgraphs\n\n```\nsubgraph title\n    graph definition\nend\n```\n\nAn example below:\n\n```mermaid-example\nflowchart TB\n    c1-->a2\n    subgraph one\n    a1-->a2\n    end\n    subgraph two\n    b1-->b2\n    end\n    subgraph three\n    c1-->c2\n    end\n```\n\nYou can also set an explicit id for the subgraph.\n\n```mermaid-example\nflowchart TB\n    c1-->a2\n    subgraph ide1 [one]\n    a1-->a2\n    end\n```\n\n### flowcharts\n\nWith the graphtype flowchart it is also possible to set edges to and from subgraphs as in the flowchart below.\n\n```mermaid-example\nflowchart TB\n    c1-->a2\n    subgraph one\n    a1-->a2\n    end\n    subgraph two\n    b1-->b2\n    end\n    subgraph three\n    c1-->c2\n    end\n    one --> two\n    three --> two\n    two --> c2\n```\n\n### Direction in subgraphs\n\nWith the graphtype flowcharts you can use the direction statement to set the direction which the subgraph will render like in this example.\n\n```mermaid-example\nflowchart LR\n  subgraph TOP\n    direction TB\n    subgraph B1\n        direction RL\n        i1 -->f1\n    end\n    subgraph B2\n        direction BT\n        i2 -->f2\n    end\n  end\n  A --> TOP --> B\n  B1 --> B2\n```\n\n#### Limitation\n\nIf any of a subgraph's nodes are linked to the outside, subgraph direction will be ignored. Instead the subgraph will inherit the direction of the parent graph:\n\n```mermaid-example\nflowchart LR\n    subgraph subgraph1\n        direction TB\n        top1[top] --> bottom1[bottom]\n    end\n    subgraph subgraph2\n        direction TB\n        top2[top] --> bottom2[bottom]\n    end\n    %% ^ These subgraphs are identical, except for the links to them:\n\n    %% Link *to* subgraph1: subgraph1 direction is maintained\n    outside --> subgraph1\n    %% Link *within* subgraph2:\n    %% subgraph2 inherits the direction of the top-level graph (LR)\n    outside ---> top2\n```\n\n### Collapsible subgraphs (v11.17.0+)\n\nA subgraph can be collapsed into a single compact node by attaching the metadata\n`@{ view: collapsed }` to its id. This is useful for hiding the internals of a\ngroup while still showing how it connects to the rest of the diagram.\n\n```mermaid-example\nflowchart TD\n    Start --> one\n    subgraph one [My Group]\n        A --> B\n        B --> C\n    end\n    one --> End\n    one@{ view: collapsed }\n```\n\nThe metadata is attached with the existing `id@{ ... }` statement syntax, where\n`id` is the subgraph id (use `subgraph id [Title]` to give a subgraph an explicit\nid). When a subgraph is collapsed:\n\n- Its internal nodes are hidden and it is drawn as a single node carrying the\n  subgraph's title.\n- Edges that cross the subgraph boundary are **redirected to the collapsed node**.\n- Edges that are entirely internal to the collapsed subgraph are dropped (they\n  would otherwise become self-loops on the collapsed node).\n- For nested subgraphs, a collapse resolves to the **outermost** collapsed\n  ancestor, so an edge pointing at a deeply nested node lands on the outermost\n  collapsed group.\n\n`view: expanded` is the default and renders the subgraph normally, so omitting the\nmetadata (or setting `view: expanded`) keeps the existing behavior.\n\n## Markdown Strings\n\nThe \"Markdown Strings\" feature enhances flowcharts and mind maps by offering a more versatile string type, which supports text formatting options such as bold and italics, and automatically wraps text within labels.\n\n```mermaid-example\n---\nconfig:\n  htmlLabels: false\n---\nflowchart LR\nsubgraph \"One\"\n  a(\"`The **cat**\n  in the hat`\") -- \"edge label\" --> b{{\"`The **dog** in the hog`\"}}\nend\nsubgraph \"`**Two**`\"\n  c(\"`The **cat**\n  in the hat`\") -- \"`Bold **edge label**`\" --> d(\"The dog in the hog\")\nend\n```\n\nFormatting:\n\n- For bold text, use double asterisks (`**`) before and after the text.\n- For italics, use single asterisks (`*`) before and after the text.\n- With traditional strings, you needed to add `
` tags for text to wrap in nodes. However, markdown strings automatically wrap text when it becomes too long and allows you to start a new line by simply using a newline character instead of a `
` tag.\n\nThis feature is applicable to node labels, edge labels, and subgraph labels.\n\nThe auto wrapping can be disabled by using\n\n```\n---\nconfig:\n  markdownAutoWrap: false\n---\ngraph LR\n```\n\n## Interaction\n\nIt is possible to bind a click event to a node, the click can lead to either a javascript callback or to a link which will be opened in a new browser tab.\n\n```note\nThis functionality is disabled when using `securityLevel='strict'` and enabled when using `securityLevel='loose'`.\n```\n\n```\nclick nodeId callback\nclick nodeId call callback()\n```\n\n- nodeId is the id of the node\n- callback is the name of a javascript function defined on the page displaying the graph, the function will be called with the nodeId as parameter.\n\nExamples of tooltip usage below:\n\n```html\n\n```\n\nThe tooltip text is surrounded in double quotes. The styles of the tooltip are set by the class `.mermaidTooltip`.\n\n```mermaid-example\nflowchart LR\n    A-->B\n    B-->C\n    C-->D\n    click A callback \"Tooltip for a callback\"\n    click B \"https://www.github.com\" \"This is a tooltip for a link\"\n    click C call callback() \"Tooltip for a callback\"\n    click D href \"https://www.github.com\" \"This is a tooltip for a link\"\n```\n\n> **Success** The tooltip functionality and the ability to link to urls are available from version 0.5.2.\n\n?> Due to limitations with how Docsify handles JavaScript callback functions, an alternate working demo for the above code can be viewed at [this jsfiddle](https://jsfiddle.net/yk4h7qou/2/).\n\nLinks are opened in the same browser tab/window by default. It is possible to change this by adding a link target to the click definition (`_self`, `_blank`, `_parent` and `_top` are supported):\n\n```mermaid-example\nflowchart LR\n    A-->B\n    B-->C\n    C-->D\n    D-->E\n    click A \"https://www.github.com\" _blank\n    click B \"https://www.github.com\" \"Open this in a new tab\" _blank\n    click C href \"https://www.github.com\" _blank\n    click D href \"https://www.github.com\" \"Open this in a new tab\" _blank\n```\n\nBeginner's tip—a full example using interactive links in a html context:\n\n```html\n\n  
\n    flowchart LR\n        A-->B\n        B-->C\n        C-->D\n        click A callback \"Tooltip\"\n        click B \"https://www.github.com\" \"This is a link\"\n        click C call callback() \"Tooltip\"\n        click D href \"https://www.github.com\" \"This is a link\"\n  
\n\n  \n\n```\n\n### Comments\n\nComments can be entered within a flow diagram, which will be ignored by the parser. Comments need to be on their own line, and must be prefaced with `%%` (double percent signs). Any text after the start of the comment to the next newline will be treated as a comment, including any flow syntax\n\n```mermaid\nflowchart LR\n%% this is a comment A -- text --> B{node}\n   A -- text --> B -- text2 --> C\n```\n\n## Styling and classes\n\n### Styling links\n\nIt is possible to style links. For instance, you might want to style a link that is going backwards in the flow. As links\nhave no ids in the same way as nodes, some other way of deciding what style the links should be attached to is required.\nInstead of ids, the order number of when the link was defined in the graph is used, or use default to apply to all links.\nIn the example below the style defined in the linkStyle statement will belong to the fourth link in the graph:\n\n```\nlinkStyle 3 stroke:#ff3,stroke-width:4px,color:red;\n```\n\nIt is also possible to add style to multiple links in a single statement, by separating link numbers with commas:\n\n```\nlinkStyle 1,2,7 color:blue;\n```\n\n### Styling line curves\n\nIt is possible to style the type of curve used for lines between items, if the default method does not meet your needs.\nAvailable curve styles include `basis`, `bumpX`, `bumpY`, `cardinal`, `catmullRom`, `linear`, `monotoneX`, `monotoneY`,\n`natural`, `step`, `stepAfter`, and `stepBefore`.\n\nFor a full list of available curves, including an explanation of custom curves, refer to\nthe [Shapes](https://d3js.org/d3-shape/curve) documentation in the [d3-shape](https://github.com/d3/d3-shape/) project.\n\nLine styling can be achieved in two ways:\n\n1. Change the curve style of all the lines\n2. Change the curve style of a particular line\n\n#### Diagram level curve style\n\nIn this example, a left-to-right graph uses the `stepBefore` curve style:\n\n```\n---\nconfig:\n  flowchart:\n    curve: stepBefore\n---\ngraph LR\n```\n\n#### Edge level curve style using Edge IDs (v11.10.0+)\n\nYou can assign IDs to [edges](#attaching-an-id-to-edges). After assigning an ID you can modify the line style by modifying the edge's `curve` property using the following syntax:\n\n```mermaid\nflowchart LR\n    A e1@==> B\n    A e2@--> C\n    e1@{ curve: linear }\n    e2@{ curve: natural }\n```\n\n```info\nAny edge curve style modified at the edge level overrides the diagram level style.\n```\n\n```info\nIf the same edge is modified multiple times the last modification will be rendered.\n```\n\n### Styling a node\n\nIt is possible to apply specific styles such as a thicker border or a different background color to a node.\n\n```mermaid-example\nflowchart LR\n    id1(Start)-->id2(Stop)\n    style id1 fill:#f9f,stroke:#333,stroke-width:4px\n    style id2 fill:#bbf,stroke:#f66,stroke-width:2px,color:#fff,stroke-dasharray: 5 5\n```\n\n#### Classes\n\nMore convenient than defining the style every time is to define a class of styles and attach this class to the nodes that\nshould have a different look.\n\nA class definition looks like the example below:\n\n```\n    classDef className fill:#f9f,stroke:#333,stroke-width:4px;\n```\n\nAlso, it is possible to define style to multiple classes in one statement:\n\n```\n    classDef firstClassName,secondClassName font-size:12pt;\n```\n\nAttachment of a class to a node is done as per below:\n\n```\n    class nodeId1 className;\n```\n\nIt is also possible to attach a class to a list of nodes in one statement:\n\n```\n    class nodeId1,nodeId2 className;\n```\n\nA shorter form of adding a class is to attach the classname to the node using the `:::`operator as per below:\n\n```mermaid-example\nflowchart LR\n    A:::someclass --> B\n    classDef someclass fill:#f96\n```\n\nThis form can be used when declaring multiple links between nodes:\n\n```mermaid-example\nflowchart LR\n    A:::foo & B:::bar --> C:::foobar\n    classDef foo stroke:#f00\n    classDef bar stroke:#0f0\n    classDef foobar stroke:#00f\n```\n\n### CSS classes\n\n> **Note:** Applying styles to Mermaid nodes via external CSS (e.g., `.cssClass > rect { fill: ... }`) does **not** work reliably. Mermaid's internal styles are injected with `!important` and scoped to the SVG element ID, giving them higher specificity than external CSS rules. External CSS will be silently overridden.\n>\n> The recommended approach is to use the `classDef` syntax shown in the [Classes](#classes) section above, which works correctly and is the intended styling mechanism.\n>\n> If external CSS is strictly required, every property must use `!important` to override Mermaid's styles — but this is not recommended.\n\n**Working approach — use `classDef` instead:**\n\n```mermaid-example\nflowchart LR\n    A:::myStyle --> B\n    classDef myStyle fill:#ff0000,stroke:#ffff00,stroke-width:4px\n```\n\n### Default class\n\nIf a class is named default it will be assigned to all classes without specific class definitions.\n\n```\n    classDef default fill:#f9f,stroke:#333,stroke-width:4px;\n```\n\n## Basic support for fontawesome\n\nIt is possible to add icons from fontawesome.\n\nThe icons are accessed via the syntax fa:#icon class name#.\n\n```mermaid-example\nflowchart TD\n    B[\"fa:fa-twitter for peace\"]\n    B-->C[fa:fa-ban forbidden]\n    B-->D(fa:fa-spinner)\n    B-->E(A fa:fa-camera-retro perhaps?)\n```\n\nThere are two ways to display these FontAwesome icons:\n\n### Register FontAwesome icon packs (v11.7.0+)\n\nYou can register your own FontAwesome icon pack following the [\"Registering icon packs\" instructions](../config/icons.md).\n\nSupported prefixes: `fa`, `fab`, `fas`, `far`, `fal`, `fad`.\n\n```note\nNote that it will fall back to FontAwesome CSS if FontAwesome packs are not registered.\n```\n\n### Register FontAwesome CSS\n\nMermaid supports Font Awesome if the CSS is included on the website.\nMermaid does not have any restriction on the version of Font Awesome that can be used.\n\nPlease refer the [Official Font Awesome Documentation](https://fontawesome.com/start) on how to include it in your website.\n\nAdding this snippet in the `` would add support for Font Awesome v6.5.1\n\n```html\n\n```\n\n### Custom icons\n\nIt is possible to use custom icons served from Font Awesome as long as the website imports the corresponding kit.\n\nNote that this is currently a paid feature from Font Awesome.\n\nFor custom icons, you need to use the `fak` prefix.\n\n**Example**\n\n```\nflowchart TD\n    B[fa:fa-twitter] %% standard icon\n    B-->E(fak:fa-custom-icon-name) %% custom icon\n```\n\nAnd trying to render it\n\n```mermaid-example\nflowchart TD\n    B[\"fa:fa-twitter for peace\"]\n    B-->C[\"fab:fa-truck-bold a custom icon\"]\n```\n\n## Graph declarations with spaces between vertices and link and without semicolon\n\n- In graph declarations, the statements also can now end without a semicolon. After release 0.2.16, ending a graph statement with semicolon is just optional. So the below graph declaration is also valid along with the old declarations of the graph.\n\n- A single space is allowed between vertices and the link. However there should not be any space between a vertex and its text and a link and its text. The old syntax of graph declaration will also work and hence this new feature is optional and is introduced to improve readability.\n\nBelow is the new declaration of the graph edges which is also valid along with the old declaration of the graph edges.\n\n```mermaid-example\nflowchart LR\n    A[Hard edge] -->|Link text| B(Round edge)\n    B --> C{Decision}\n    C -->|One| D[Result one]\n    C -->|Two| E[Result two]\n```\n\n## Configuration\n\n### Renderer\n\nThe layout of the diagram is done with the layout algorithm. The default is\n[ELK](https://www.eclipse.org/elk/), which handles larger and more complex\ndiagrams well and is bundled with Mermaid.\n\nTo use the classic Dagre layout instead:\n\n```\nconfig:\n  layout: dagre\n```\n\nThe `flowchart-elk` diagram type still works, but is no longer needed — it\npredates `layout` and selected what is now the default.\n\nThe `defaultRenderer` option of the `flowchart`, `class` and `state` config\nsections was removed in v12. It named a rendering engine at a time when there\nwas more than one; all of its values had come to mean the same renderer, and\nits `elk` value only ever set `layout: elk` on your behalf. Use `layout`\ndirectly.\n\n### Width\n\nIt is possible to adjust the width of the rendered flowchart.\n\nThis is done by defining **mermaid.flowchartConfig** or by the CLI to use a JSON file with the configuration. How to use the CLI is described in the mermaidCLI page.\nmermaid.flowchartConfig can be set to a JSON string with config parameters or the corresponding object.\n\n```javascript\nmermaid.flowchartConfig = {\n    width: 100%\n}\n```\n\n\n","packages/mermaid/src/docs/syntax/gantt.md":"# Gantt diagrams\n\n> A Gantt chart is a type of bar chart, first developed by Karol Adamiecki in 1896, and independently by Henry Gantt in the 1910s, that illustrates a project schedule and the amount of time it would take for any one project to finish. Gantt charts illustrate number of days between the start and finish dates of the terminal elements and summary elements of a project.\n\n## A note to users\n\nGantt Charts will record each scheduled task as one continuous bar that extends from the left to the right. The x axis represents time and the y records the different tasks and the order in which they are to be completed.\n\nIt is important to remember that when a date, day, or collection of dates specific to a task are \"excluded\", the Gantt Chart will accommodate those changes by extending an equal number of days, towards the right, not by creating a gap inside the task.\nAs shown here ![](./img/Gantt-excluded-days-within.png)\n\nHowever, if the excluded dates are between two tasks that are set to start consecutively, the excluded dates will be skipped graphically and left blank, and the following task will begin after the end of the excluded dates.\nAs shown here ![](./img/Gantt-long-weekend-look.png)\n\nA Gantt chart is useful for tracking the amount of time it would take before a project is finished, but it can also be used to graphically represent \"non-working days\", with a few tweaks.\n\nMermaid can render Gantt diagrams as SVG, PNG or a MarkDown link that can be pasted into docs.\n\n```mermaid-example\ngantt\n    title A Gantt Diagram\n    dateFormat YYYY-MM-DD\n    section Section\n        A task          :a1, 2014-01-01, 30d\n        Another task    :after a1, 20d\n    section Another\n        Task in Another :2014-01-12, 12d\n        another task    :24d\n```\n\n## Syntax\n\n```mermaid-example\ngantt\n    dateFormat  YYYY-MM-DD\n    title       Adding GANTT diagram functionality to mermaid\n    excludes    weekends\n    %% (`excludes` accepts specific dates in YYYY-MM-DD format, days of the week (\"sunday\") or \"weekends\", but not the word \"weekdays\".)\n\n    section A section\n    Completed task            :done,    des1, 2014-01-06,2014-01-08\n    Active task               :active,  des2, 2014-01-09, 3d\n    Future task               :         des3, after des2, 5d\n    Future task2              :         des4, after des3, 5d\n\n    section Critical tasks\n    Completed task in the critical line :crit, done, 2014-01-06,24h\n    Implement parser and jison          :crit, done, after des1, 2d\n    Create tests for parser             :crit, active, 3d\n    Future task in critical line        :crit, 5d\n    Create tests for renderer           :2d\n    Add to mermaid                      :until isadded\n    Functionality added                 :milestone, isadded, 2014-01-25, 0d\n\n    section Documentation\n    Describe gantt syntax               :active, a1, after des1, 3d\n    Add gantt diagram to demo page      :after a1  , 20h\n    Add another diagram to demo page    :doc1, after a1  , 48h\n\n    section Last section\n    Describe gantt syntax               :after doc1, 3d\n    Add gantt diagram to demo page      :20h\n    Add another diagram to demo page    :48h\n```\n\nTasks are by default sequential. A task start date defaults to the end date of the preceding task.\n\nA colon, `:`, separates the task title from its metadata.\nMetadata items are separated by a comma, `,`. Valid tags are `active`, `done`, `crit`, and `milestone`. Tags are optional, but if used, they must be specified first.\nAfter processing the tags, the remaining metadata items are interpreted as follows:\n\n1. If a single item is specified, it determines when the task ends. It can either be a specific date/time or a duration. If a duration is specified, it is added to the start date of the task to determine the end date of the task, taking into account any exclusions.\n2. If two items are specified, the last item is interpreted as in the previous case. The first item can either specify an explicit start date/time (in the format specified by `dateFormat`) or reference another task using `after  [[otherTaskID2 [otherTaskID3]]...]`. In the latter case, the start date of the task will be set according to the latest end date of any referenced task.\n3. If three items are specified, the last two will be interpreted as in the previous case. The first item will denote the ID of the task, which can be referenced using the `later ` syntax.\n\n| Metadata syntax                                      | Start date                                          | End date                                              | ID       |\n| ---------------------------------------------------- | --------------------------------------------------- | ----------------------------------------------------- | -------- |\n| `, , `                   | `startdate` as interpreted using `dateformat`       | `endDate` as interpreted using `dateformat`           | `taskID` |\n| `, , `                    | `startdate` as interpreted using `dateformat`       | Start date + `length`                                 | `taskID` |\n| `, after , `           | End date of previously specified task `otherTaskID` | `endDate` as interpreted using `dateformat`           | `taskID` |\n| `, after , `            | End date of previously specified task `otherTaskID` | Start date + `length`                                 | `taskID` |\n| `, , until `         | `startdate` as interpreted using `dateformat`       | Start date of previously specified task `otherTaskID` | `taskID` |\n| `, after , until ` | End date of previously specified task `otherTaskID` | Start date of previously specified task `otherTaskID` | `taskID` |\n| `, `                             | `startdate` as interpreted using `dateformat`       | `enddate` as interpreted using `dateformat`           | n/a      |\n| `, `                              | `startdate` as interpreted using `dateformat`       | Start date + `length`                                 | n/a      |\n| `after , `                     | End date of previously specified task `otherTaskID` | `enddate` as interpreted using `dateformat`           | n/a      |\n| `after , `                      | End date of previously specified task `otherTaskID` | Start date + `length`                                 | n/a      |\n| `, until `                   | `startdate` as interpreted using `dateformat`       | Start date of previously specified task `otherTaskID` | n/a      |\n| `after , until `           | End date of previously specified task `otherTaskID` | Start date of previously specified task `otherTaskID` | n/a      |\n| ``                                          | End date of preceding task                          | `enddate` as interpreted using `dateformat`           | n/a      |\n| ``                                           | End date of preceding task                          | Start date + `length`                                 | n/a      |\n| `until `                                | End date of preceding task                          | Start date of previously specified task `otherTaskID` | n/a      |\n\n```note\nSupport for keyword `until` was added in (v10.9.0+). This can be used to define a task which is running until some other specific task or milestone starts.\n```\n\n#### Duration format\n\nWhen specifying a ``, use a number followed by one of these unit suffixes:\n\n| Unit         | Suffix | Example |\n| ------------ | ------ | ------- |\n| Milliseconds | `ms`   | `500ms` |\n| Seconds      | `s`    | `30s`   |\n| Minutes      | `m`    | `30m`   |\n| Hours        | `h`    | `4h`    |\n| Days         | `d`    | `3d`    |\n| Weeks        | `w`    | `2w`    |\n| Months       | `M`    | `1M`    |\n| Years        | `y`    | `1y`    |\n\nDecimal values are also supported (e.g., `1.5d`). Invalid duration tokens (e.g., `3dX`) will be ignored and the task will default to zero duration.\n\nFor simplicity, the table does not show the use of multiple tasks listed with the `after` keyword. Here is an example of how to use it and how it's interpreted:\n\n```mermaid-example\ngantt\n    apple :a, 2017-07-20, 1w\n    banana :crit, b, 2017-07-23, 1d\n    cherry :active, c, after b a, 1d\n    kiwi   :d, 2017-07-20, until b c\n```\n\n### Title\n\nThe `title` is an _optional_ string to be displayed at the top of the Gantt chart to describe the chart as a whole.\n\n### Excludes\n\nThe `excludes` is an _optional_ attribute that accepts specific dates in YYYY-MM-DD format, days of the week (\"sunday\") or \"weekends\", but not the word \"weekdays\".\nThese date will be marked on the graph, and be excluded from the duration calculation of tasks. Meaning that if there are excluded dates during a task interval, the number of 'skipped' days will be added to the end of the task to ensure the duration is as specified in the code.\n\nMultiple `excludes` lines are supported and their tokens are concatenated, so long exclusion lists can be split across grouped lines with comments:\n\n```\ngantt\n    dateFormat DD-MM-YYYY\n    excludes weekends\n    %% week 7 is winter break\n    excludes 10-02-2025 11-02-2025 12-02-2025 13-02-2025 14-02-2025\n    %% workers holiday 1 maj\n    excludes 01-05-2025\n```\n\n#### Weekend (v\\11.0.0+)\n\nWhen excluding weekends, it is possible to configure the weekends to be either Friday and Saturday or Saturday and Sunday. By default weekends are Saturday and Sunday.\nTo define the weekend start day, there is an _optional_ attribute `weekend` that can be added in a new line followed by either `friday` or `saturday`.\n\n```mermaid-example\ngantt\n    title A Gantt Diagram Excluding Fri - Sat weekends\n    dateFormat YYYY-MM-DD\n    excludes weekends\n    weekend friday\n    section Section\n        A task          :a1, 2024-01-01, 30d\n        Another task    :after a1, 20d\n```\n\n### Section statements\n\nYou can divide the chart into various sections, for example to separate different parts of a project like development and documentation.\n\nTo do so, start a line with the `section` keyword and give it a name. (Note that unlike with the [title for the entire chart](#title), this name is _required_.\n\n### Milestones\n\nYou can add milestones to the diagrams. Milestones differ from tasks as they represent a single instant in time and are identified by the keyword `milestone`. Below is an example on how to use milestones. As you may notice, the exact location of the milestone is determined by the initial date for the milestone and the \"duration\" of the task this way: _initial date_+_duration_/2.\n\n```mermaid-example\ngantt\n    dateFormat HH:mm\n    axisFormat %H:%M\n    Initial milestone : milestone, m1, 17:49, 2m\n    Task A : 10m\n    Task B : 5m\n    Final milestone : milestone, m2, 18:08, 4m\n```\n\n### Vertical Markers\n\nThe `vert` keyword lets you add vertical lines to your Gantt chart, making it easy to highlight important dates like deadlines, events, or checkpoints. These markers extend across the entire chart and are positioned based on the date you provide. Unlike milestones, vertical markers don’t take up a row. They’re purely visual reference points that help break up the timeline and make important moments easier to spot.\n\n```mermaid-example\ngantt\n    dateFormat HH:mm\n    axisFormat %H:%M\n    Initial vert : vert, v1, 17:30, 2m\n    Task A : 3m\n    Task B : 8m\n    Final vert : vert, v2, 17:58, 4m\n```\n\n## Setting dates\n\n`dateFormat` defines the format of the date **input** of your gantt elements. How these dates are represented in the rendered chart **output** are defined by `axisFormat`.\n\n### Input date format\n\nThe default input date format is `YYYY-MM-DD`. You can define your custom `dateFormat`.\n\n```markdown\ndateFormat YYYY-MM-DD\n```\n\nThe following formatting options are supported:\n\n| Input      | Example        | Description                                            |\n| ---------- | -------------- | ------------------------------------------------------ |\n| `YYYY`     | 2014           | 4 digit year                                           |\n| `YY`       | 14             | 2 digit year                                           |\n| `Q`        | 1..4           | Quarter of year. Sets month to first month in quarter. |\n| `M MM`     | 1..12          | Month number                                           |\n| `MMM MMMM` | January..Dec   | Month name in locale set by `dayjs.locale()`           |\n| `D DD`     | 1..31          | Day of month                                           |\n| `Do`       | 1st..31st      | Day of month with ordinal                              |\n| `DDD DDDD` | 1..365         | Day of year                                            |\n| `X`        | 1410715640.579 | Unix timestamp                                         |\n| `x`        | 1410715640579  | Unix ms timestamp                                      |\n| `H HH`     | 0..23          | 24 hour time                                           |\n| `h hh`     | 1..12          | 12 hour time used with `a A`.                          |\n| `a A`      | am pm          | Post or ante meridiem                                  |\n| `m mm`     | 0..59          | Minutes                                                |\n| `s ss`     | 0..59          | Seconds                                                |\n| `S`        | 0..9           | Tenths of a second                                     |\n| `SS`       | 0..99          | Hundreds of a second                                   |\n| `SSS`      | 0..999         | Thousandths of a second                                |\n| `Z ZZ`     | +12:00         | Offset from UTC as +-HH:mm, +-HHmm, or Z               |\n\nMore info in: https://day.js.org/docs/en/parse/string-format/\n\n### Output date format on the axis\n\nThe default output date format is `YYYY-MM-DD`. You can define your custom `axisFormat`, like `2020-Q1` for the first quarter of the year 2020.\n\n```markdown\naxisFormat %Y-%m-%d\n```\n\nThe following formatting strings are supported:\n\n| Format | Definition                                                                                |\n| ------ | ----------------------------------------------------------------------------------------- |\n| %a     | abbreviated weekday name                                                                  |\n| %A     | full weekday name                                                                         |\n| %b     | abbreviated month name                                                                    |\n| %B     | full month name                                                                           |\n| %c     | date and time, as \"%a %b %e %H:%M:%S %Y\"                                                  |\n| %d     | zero-padded day of the month as a decimal number [01,31]                                  |\n| %e     | space-padded day of the month as a decimal number [ 1,31]; equivalent to %\\_d             |\n| %H     | hour (24-hour clock) as a decimal number [00,23]                                          |\n| %I     | hour (12-hour clock) as a decimal number [01,12]                                          |\n| %j     | day of the year as a decimal number [001,366]                                             |\n| %m     | month as a decimal number [01,12]                                                         |\n| %M     | minute as a decimal number [00,59]                                                        |\n| %L     | milliseconds as a decimal number [000, 999]                                               |\n| %p     | either AM or PM                                                                           |\n| %S     | second as a decimal number [00,61]                                                        |\n| %U     | week number of the year (Sunday as the first day of the week) as a decimal number [00,53] |\n| %w     | weekday as a decimal number [0(Sunday),6]                                                 |\n| %W     | week number of the year (Monday as the first day of the week) as a decimal number [00,53] |\n| %x     | date, as \"%m/%d/%Y\"                                                                       |\n| %X     | time, as \"%H:%M:%S\"                                                                       |\n| %y     | year without century as a decimal number [00,99]                                          |\n| %Y     | year with century as a decimal number                                                     |\n| %Z     | time zone offset, such as \"-0700\"                                                         |\n| %%     | a literal \"%\" character                                                                   |\n\nMore info in: [https://github.com/d3/d3-time-format/tree/v4.0.0#locale_format](https://github.com/d3/d3-time-format/tree/v4.0.0#locale_format)\n\n### Axis ticks (v10.3.0+)\n\nThe default output ticks are auto. You can custom your `tickInterval`, like `1day` or `1week`.\n\n```markdown\ntickInterval 1day\n```\n\nThe pattern is:\n\n```javascript\n/^([1-9][0-9]*)(millisecond|second|minute|hour|day|week|month)$/;\n```\n\nMore info in: [https://github.com/d3/d3-time#interval_every](https://github.com/d3/d3-time#interval_every)\n\nWeek-based `tickInterval`s start the week on sunday by default. If you wish to specify another weekday on which the `tickInterval` should start, use the `weekday` option:\n\n```mermaid-example\ngantt\n  tickInterval 1week\n  weekday monday\n```\n\n```warning\n`millisecond` and `second` support was added in v10.3.0\n```\n\n## Output in compact mode\n\nThe compact mode allows you to display multiple tasks in the same row. Compact mode can be enabled for a gantt chart by setting the display mode of the graph via preceding YAML settings.\n\n```mermaid-example\n---\ndisplayMode: compact\n---\ngantt\n    title A Gantt Diagram\n    dateFormat  YYYY-MM-DD\n\n    section Section\n    A task           :a1, 2014-01-01, 30d\n    Another task     :a2, 2014-01-20, 25d\n    Another one      :a3, 2014-02-10, 20d\n```\n\n## Comments\n\nComments can be entered within a gantt chart, which will be ignored by the parser. Comments need to be on their own line and must be prefaced with `%%` (double percent signs). Any text after the start of the comment to the next newline will be treated as a comment, including any diagram syntax.\n\n```mermaid\ngantt\n    title A Gantt Diagram\n    %% This is a comment\n    dateFormat YYYY-MM-DD\n    section Section\n        A task          :a1, 2014-01-01, 30d\n        Another task    :after a1, 20d\n    section Another\n        Task in Another :2014-01-12, 12d\n        another task    :24d\n```\n\n## Styling\n\nStyling of the Gantt diagram is done by defining a number of CSS classes. During rendering, these classes are extracted from the file located at src/diagrams/gantt/styles.js\n\n### Classes used\n\n| Class                 | Description                                                            |\n| --------------------- | ---------------------------------------------------------------------- |\n| grid.tick             | Styling for the Grid Lines                                             |\n| grid.path             | Styling for the Grid's borders                                         |\n| .taskText             | Task Text Styling                                                      |\n| .taskTextOutsideRight | Styling for Task Text that exceeds the activity bar towards the right. |\n| .taskTextOutsideLeft  | Styling for Task Text that exceeds the activity bar, towards the left. |\n| todayMarker           | Toggle and Styling for the \"Today Marker\"                              |\n\n### Sample stylesheet\n\n```css\n.grid .tick {\n  stroke: lightgrey;\n  opacity: 0.3;\n  shape-rendering: crispEdges;\n}\n.grid path {\n  stroke-width: 0;\n}\n\n#tag {\n  color: white;\n  background: #fa283d;\n  width: 150px;\n  position: absolute;\n  display: none;\n  padding: 3px 6px;\n  margin-left: -80px;\n  font-size: 11px;\n}\n\n#tag:before {\n  border: solid transparent;\n  content: ' ';\n  height: 0;\n  left: 50%;\n  margin-left: -5px;\n  position: absolute;\n  width: 0;\n  border-width: 10px;\n  border-bottom-color: #fa283d;\n  top: -20px;\n}\n.taskText {\n  fill: white;\n  text-anchor: middle;\n}\n.taskTextOutsideRight {\n  fill: black;\n  text-anchor: start;\n}\n.taskTextOutsideLeft {\n  fill: black;\n  text-anchor: end;\n}\n```\n\n## Today marker\n\nYou can style or hide the marker for the current date. To style it, add a value for the `todayMarker` key.\n\n```\ntodayMarker stroke-width:5px,stroke:#0f0,opacity:0.5\n```\n\nTo hide the marker, set `todayMarker` to `off`.\n\n```\ntodayMarker off\n```\n\n## Configuration\n\nIt is possible to adjust the margins for rendering the gantt diagram.\n\nThis is done by defining the `ganttConfig` part of the configuration object.\nHow to use the CLI is described in the [mermaidCLI](../config/mermaidCLI.md) page.\n\nmermaid.ganttConfig can be set to a JSON string with config parameters or the corresponding object.\n\n```javascript\nmermaid.ganttConfig = {\n  titleTopMargin: 25, // Margin top for the text over the diagram\n  barHeight: 20, // The height of the bars in the graph\n  barGap: 4, // The margin between the different activities in the gantt diagram\n  topPadding: 75, // Margin between title and gantt diagram and between axis and gantt diagram.\n  rightPadding: 75, // The space allocated for the section name to the right of the activities\n  leftPadding: 75, // The space allocated for the section name to the left of the activities\n  gridLineStartPadding: 10, // Vertical starting position of the grid lines\n  fontSize: 12, // Font size\n  sectionFontSize: 24, // Font size for sections\n  numberSectionStyles: 1, // The number of alternating section styles\n  axisFormat: '%d/%m', // Date/time format of the axis\n  tickInterval: '1week', // Axis ticks\n  topAxis: true, // When this flag is set, date labels will be added to the top of the chart\n  displayMode: 'compact', // Turns compact mode on\n  weekday: 'sunday', // On which day a week-based interval should start\n};\n```\n\n### Possible configuration params:\n\n| Param           | Description                                                                                                                                | Default value |\n| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | ------------- |\n| mirrorActor     | Turns on/off the rendering of actors below the diagram as well as above it                                                                 | false         |\n| bottomMarginAdj | Adjusts how far down the graph ended. Wide borders styles with css could generate unwanted clipping which is why this config param exists. | 1             |\n\n## Interaction\n\nIt is possible to bind a click event to a task. The click can lead to either a javascript callback or to a link which will be opened in the current browser tab. **Note**: This functionality is disabled when using `securityLevel='strict'` and enabled when using `securityLevel='loose'`.\n\n```\nclick taskId call callback(arguments)\nclick taskId href URL\n```\n\n- taskId is the id of the task\n- callback is the name of a javascript function defined on the page displaying the graph, the function will be called with the taskId as the parameter if no other arguments are specified.\n\nBeginner's tip—a full example using interactive links in an HTML context:\n\n```html\n\n  
\n    gantt\n      dateFormat  YYYY-MM-DD\n\n      section Clickable\n      Visit mermaidjs         :active, cl1, 2014-01-07, 3d\n      Print arguments         :cl2, after cl1, 3d\n      Print task              :cl3, after cl2, 3d\n\n      click cl1 href \"https://mermaidjs.github.io/\"\n      click cl2 call printArguments(\"test1\", \"test2\", test3)\n      click cl3 call printTask()\n  
\n\n  \n\n```\n\n## Examples\n\n### Bar chart (using gantt chart)\n\n```mermaid-example\ngantt\n    title Git Issues - days since last update\n    dateFormat X\n    axisFormat %s\n    section Issue19062\n    71   : 0, 71\n    section Issue19401\n    36   : 0, 36\n    section Issue193\n    34   : 0, 34\n    section Issue7441\n    9    : 0, 9\n    section Issue1300\n    5    : 0, 5\n```\n\n### Timeline (with comments, CSS, config in frontmatter)\n\n```mermaid-example\n---\n    # Frontmatter config, YAML comments\n    title: Ignored if specified in chart\n    displayMode: compact     #gantt specific setting but works at this level too\n    config:\n#        theme: forest\n#        themeCSS: \" #item36 { fill: CadetBlue } \"\n        themeCSS: \" // YAML supports multiline strings using a newline markers: \\n\n            #item36 { fill: CadetBlue }       \\n\n\n            // Custom marker workaround CSS from forum (below)    \\n\n            rect[id^=workaround] { height: calc(100% - 50px) ; transform: translate(9px, 25px); y: 0; width: 1.5px; stroke: none; fill: red; }   \\n\n            text[id^=workaround] { fill: red; y: 100%; font-size: 15px;}\n        \"\n        gantt:\n            useWidth: 400\n            rightPadding: 0\n            topAxis: true  #false\n            numberSectionStyles: 2\n---\ngantt\n    title Timeline - Gantt Sampler\n    dateFormat YYYY\n    axisFormat %y\n    %% this next line doesn't recognise 'decade' or 'year', but will silently ignore\n    tickInterval 1decade\n\n    section Issue19062\n    71   :            item71, 1900, 1930\n    section Issue19401\n    36   :            item36, 1913, 1935\n    section Issue1300\n    94   :            item94, 1910, 1915\n    5    :            item5,  1920, 1925\n    0    : milestone, item0,  1918, 1s\n    9    : vert,              1906, 1s   %% not yet official\n    64   : workaround,        1923, 1s   %% custom CSS object https://github.com/mermaid-js/mermaid/issues/3250\n```\n\n\n","packages/mermaid/src/docs/syntax/gitgraph.md":"# GitGraph Diagrams\n\n> A Git Graph is a pictorial representation of git commits and git actions(commands) on various branches.\n\nThese kind of diagram are particularly helpful to developers and devops teams to share their Git branching strategies. For example, it makes it easier to visualize how git flow works.\n\nMermaid can render Git diagrams\n\n```mermaid-example\n---\ntitle: Example Git diagram\n---\ngitGraph\n   commit\n   commit\n   branch develop\n   checkout develop\n   commit\n   commit\n   checkout main\n   merge develop\n   commit\n   commit\n```\n\nIn Mermaid, we support the basic git operations like:\n\n- _commit_ : Representing a new commit on the current branch.\n- _branch_ : To create & switch to a new branch, setting it as the current branch.\n- _checkout_ : To checking out an existing branch and setting it as the current branch.\n- _merge_ : To merge an existing branch onto the current branch.\n\nWith the help of these key git commands, you will be able to draw a gitgraph in Mermaid very easily and quickly.\nEntity names are often capitalized, although there is no accepted standard on this, and it is not required in Mermaid.\n\n**NOTE**: `checkout` and `switch` can be used interchangeably.\n\n## Syntax\n\nMermaid syntax for a gitgraph is very straight-forward and simple. It follows a declarative-approach, where each commit is drawn on the timeline in the diagram, in order of its occurrences/presence in code. Basically, it follows the insertion order for each command.\n\nFirst thing you do is to declare your diagram type using the **gitgraph** keyword. This `gitgraph` keyword, tells Mermaid that you wish to draw a gitgraph, and parse the diagram code accordingly.\n\nEach gitgraph, is initialized with **_main_** branch. So unless you create a different branch, by-default the commits will go to the main branch. This is driven with how git works, where in the beginning you always start with the main branch (formerly called as **_master_** branch). And by-default, `main` branch is set as your **_current branch_**.\n\nYou make use of **_commit_** keyword to register a commit on the current branch. Let see how this works:\n\nA simple gitgraph showing three commits on the default (**_main_**) branch:\n\n```mermaid-example\n    gitGraph\n       commit\n       commit\n       commit\n```\n\nIf you look closely at the previous example, you can see the default branch `main` along with three commits. Also, notice that by default each commit has been given a unique & random ID. What if you wanted to give your own custom ID to a commit? Yes, it is possible to do that with Mermaid.\n\n### Adding custom commit id\n\nFor a given commit you may specify a custom ID at the time of declaring it using the `id` attribute, followed by `:` and your custom value within a `\"\"` quote. For example: `commit id: \"your_custom_id\"`\n\nLet us see how this works with the help of the following diagram:\n\n```mermaid-example\n    gitGraph\n       commit id: \"Alpha\"\n       commit id: \"Beta\"\n       commit id: \"Gamma\"\n```\n\nIn this example, we have given our custom IDs to the commits.\n\n### Modifying commit type\n\nIn Mermaid, a commit can be of three type, which render a bit different in the diagram. These types are:\n\n- `NORMAL` : Default commit type. Represented by a solid circle in the diagram\n- `REVERSE` : To emphasize a commit as a reverse commit. Represented by a crossed solid circle in the diagram.\n- `HIGHLIGHT` : To highlight a particular commit in the diagram. Represented by a filled rectangle in the diagram.\n\nFor a given commit you may specify its type at the time of declaring it using the `type` attribute, followed by `:` and the required type option discussed above. For example: `commit type: HIGHLIGHT`\n\nNOTE: If no commit type is specified, `NORMAL` is picked as default.\n\nLet us see how these different commit type look with the help of the following diagram:\n\n```mermaid-example\n    gitGraph\n       commit id: \"Normal\"\n       commit\n       commit id: \"Reverse\" type: REVERSE\n       commit\n       commit id: \"Highlight\" type: HIGHLIGHT\n       commit\n```\n\nIn this example, we have specified different types to each commit. Also, see how we have included both `id` and `type` together at the time of declaring our commits.\n\n### Adding Tags\n\nFor a given commit you may decorate it as a **tag**, similar to the concept of tags or release version in git world.\nYou can attach a custom tag at the time of declaring a commit using the `tag` attribute, followed by `:` and your custom value within `\"\"` quote. For example: `commit tag: \"your_custom_tag\"`\n\nLet us see how this works with the help of the following diagram:\n\n```mermaid-example\n    gitGraph\n       commit\n       commit id: \"Normal\" tag: \"v1.0.0\"\n       commit\n       commit id: \"Reverse\" type: REVERSE tag: \"RC_1\"\n       commit\n       commit id: \"Highlight\" type: HIGHLIGHT tag: \"8.8.4\"\n       commit\n```\n\nIn this example, we have given custom tags to the commits. Also, see how we have combined all these attributes in a single commit declaration. You can mix-match these attributes as you like.\n\n### Create a new branch\n\nIn Mermaid, in-order to create a new branch, you make use of the `branch` keyword. You also need to provide a name of the new branch. The name has to be unique and cannot be that of an existing branch. A branch name that could be confused for a keyword must be quoted within `\"\"`. Usage examples: `branch develop`, `branch \"cherry-pick\"`\n\nWhen Mermaid, reads the `branch` keyword, it creates a new branch and sets it as the current branch. Equivalent to you creating a new branch and checking it out in Git world.\n\nLet see this in an example:\n\n```mermaid-example\n    gitGraph\n       commit\n       commit\n       branch develop\n       commit\n       commit\n       commit\n```\n\nIn this example, see how we started with default `main` branch, and pushed two commits on that.\nThen we created the `develop` branch, and all commits afterwards are put on the `develop` branch as it became the current branch.\n\n### Checking out an existing branch\n\nIn Mermaid, in order to switch to an existing branch, you make use of the `checkout` keyword. You also need to provide a name of an existing branch. If no branch is found with the given name, it will result in console error. Usage example: `checkout develop`\n\nWhen Mermaid, reads the `checkout` keyword, it finds the given branch and sets it as the current branch. Equivalent to checking out a branch in the Git world.\n\nLet see modify our previous example:\n\n```mermaid-example\n    gitGraph\n       commit\n       commit\n       branch develop\n       commit\n       commit\n       commit\n       checkout main\n       commit\n       commit\n```\n\nIn this example, see how we started with default `main` branch, and pushed two commits on that.\nThen we created the `develop` branch, and all three commits afterwards are put on the `develop` branch as it became the current branch.\nAfter this we made use of the `checkout` keyword to set the current branch as `main`, and all commit that follow are registered against the current branch, i.e. `main`.\n\n### Merging two branches\n\nIn Mermaid, in order to merge or join to an existing branch, you make use of the `merge` keyword. You also need to provide the name of an existing branch to merge from. If no branch is found with the given name, it will result in console error. Also, you can only merge two separate branches, and cannot merge a branch with itself. In such case an error is throw.\n\nUsage example: `merge develop`\n\nWhen Mermaid, reads the `merge` keyword, it finds the given branch and its head commit (the last commit on that branch), and joins it with the head commit on the **current branch**. Each merge results in a **_merge commit_**, represented in the diagram with **filled double circle**.\n\nLet us modify our previous example to merge our two branches:\n\n```mermaid-example\n    gitGraph\n       commit\n       commit\n       branch develop\n       commit\n       commit\n       commit\n       checkout main\n       commit\n       commit\n       merge develop\n       commit\n       commit\n```\n\nIn this example, see how we started with default `main` branch, and pushed two commits on that.\nThen we created the `develop` branch, and all three commits afterwards are put on the `develop` branch as it became the current branch.\nAfter this we made use of the `checkout` keyword to set the current branch as `main`, and all commits that follow are registered against the current branch, i.e. `main`.\nAfter this we merge the `develop` branch onto the current branch `main`, resulting in a merge commit.\nSince the current branch at this point is still `main`, the last two commits are registered against that.\n\nYou can also decorate your merge with similar attributes as you did for the commit using:\n\n- `id`--> To override the default ID with custom ID\n- `tag`--> To add a custom tag to your merge commit\n- `type`--> To override the default shape of merge commit. Here you can use other commit type mentioned earlier.\n\nAnd you can choose to use none, some or all of these attributes together.\nFor example: `merge develop id: \"my_custom_id\" tag: \"my_custom_tag\" type: REVERSE`\n\nLet us see how this works with the help of the following diagram:\n\n```mermaid-example\n    gitGraph\n       commit id: \"1\"\n       commit id: \"2\"\n       branch nice_feature\n       checkout nice_feature\n       commit id: \"3\"\n       checkout main\n       commit id: \"4\"\n       checkout nice_feature\n       branch very_nice_feature\n       checkout very_nice_feature\n       commit id: \"5\"\n       checkout main\n       commit id: \"6\"\n       checkout nice_feature\n       commit id: \"7\"\n       checkout main\n       merge nice_feature id: \"customID\" tag: \"customTag\" type: REVERSE\n       checkout very_nice_feature\n       commit id: \"8\"\n       checkout main\n       commit id: \"9\"\n```\n\n### Cherry Pick commit from another branch\n\nSimilar to how 'git' allows you to cherry-pick a commit from **another branch** onto the **current** branch, Mermaid also supports this functionality. You can also cherry-pick a commit from another branch using the `cherry-pick` keyword.\n\nTo use the `cherry-pick` keyword, you must specify the id using the `id` attribute, followed by `:` and your desired commit id within a `\"\"` quote. For example:\n\n`cherry-pick id: \"your_custom_id\"`\n\nHere, a new commit representing the cherry-pick is created on the current branch, and is visually highlighted in the diagram with a **cherry** and a tag depicting the commit id from which it is cherry-picked from.\n\nA few important rules to note here are:\n\n1. You need to provide the `id` for an existing commit to be cherry-picked. If given commit id does not exist it will result in an error. For this, make use of the `commit id:$value` format of declaring commits. See the examples from above.\n2. The given commit must not exist on the current branch. The cherry-picked commit must always be a different branch than the current branch.\n3. Current branch must have at least one commit, before you can cherry-pick, otherwise it will cause an error is throw.\n4. When cherry-picking a merge commit, providing a parent commit ID is mandatory. If the parent attribute is omitted or an invalid parent commit ID is provided, an error will be thrown.\n5. The specified parent commit must be an immediate parent of the merge commit being cherry-picked.\n\nLet see an example:\n\n```mermaid-example\n    gitGraph\n        commit id: \"ZERO\"\n        branch develop\n        branch release\n        commit id:\"A\"\n        checkout main\n        commit id:\"ONE\"\n        checkout develop\n        commit id:\"B\"\n        checkout main\n        merge develop id:\"MERGE\"\n        commit id:\"TWO\"\n        checkout release\n        cherry-pick id:\"MERGE\" parent:\"B\"\n        commit id:\"THREE\"\n        checkout develop\n        commit id:\"C\"\n```\n\n## GitGraph specific configuration options\n\nIn Mermaid, you have the option to configure the gitgraph diagram. You can configure the following options:\n\n- `showBranches` : Boolean, default is `true`. If set to `false`, the branches are not shown in the diagram.\n- `showCommitLabel` : Boolean, default is `true`. If set to `false`, the commit labels are not shown in the diagram.\n- `mainBranchName` : String, default is `main`. The name of the default/root branch.\n- `mainBranchOrder` : Position of the main branch in the list of branches. default is `0`, meaning, by default `main` branch is the first in the order.\n- `parallelCommits`: Boolean, default is `false`. If set to `true`, commits x distance away from the parent are shown at the same level in the diagram.\n\nLet's look at them one by one.\n\n## Hiding Branch names and lines\n\nSometimes you may want to hide the branch names and lines from the diagram. You can do this by using the `showBranches` keyword. By default its value is `true`. You can set it to `false` using directives.\n\nUsage example:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'base'\n  gitGraph:\n    showBranches: false\n---\n      gitGraph\n        commit\n        branch hotfix\n        checkout hotfix\n        commit\n        branch develop\n        checkout develop\n        commit id:\"ash\" tag:\"abc\"\n        branch featureB\n        checkout featureB\n        commit type:HIGHLIGHT\n        checkout main\n        checkout hotfix\n        commit type:NORMAL\n        checkout develop\n        commit type:REVERSE\n        checkout featureB\n        commit\n        checkout main\n        merge hotfix\n        checkout featureB\n        commit\n        checkout develop\n        branch featureA\n        commit\n        checkout develop\n        merge hotfix\n        checkout featureA\n        commit\n        checkout featureB\n        commit\n        checkout develop\n        merge featureA\n        branch release\n        checkout release\n        commit\n        checkout main\n        commit\n        checkout release\n        merge main\n        checkout develop\n        merge release\n```\n\n## Commit labels Layout: Rotated or Horizontal\n\nMermaid supports two types of commit labels layout. The default layout is **rotated**, which means the labels are placed below the commit circle, rotated at 45 degrees for better readability. This is particularly useful for commits with long labels.\n\nThe other option is **horizontal**, which means the labels are placed below the commit circle centred horizontally, and are not rotated. This is particularly useful for commits with short labels.\n\nYou can change the layout of the commit labels by using the `rotateCommitLabel` keyword in the directive. It defaults to `true`, which means the commit labels are rotated.\n\nUsage example: Rotated commit labels\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'base'\n  gitGraph:\n    rotateCommitLabel: true\n---\ngitGraph\n  commit id: \"feat(api): ...\"\n  commit id: \"a\"\n  commit id: \"b\"\n  commit id: \"fix(client): .extra long label..\"\n  branch c2\n  commit id: \"feat(modules): ...\"\n  commit id: \"test(client): ...\"\n  checkout main\n  commit id: \"fix(api): ...\"\n  commit id: \"ci: ...\"\n  branch b1\n  commit\n  branch b2\n  commit\n```\n\nUsage example: Horizontal commit labels\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'base'\n  gitGraph:\n    rotateCommitLabel: false\n---\ngitGraph\n  commit id: \"feat(api): ...\"\n  commit id: \"a\"\n  commit id: \"b\"\n  commit id: \"fix(client): .extra long label..\"\n  branch c2\n  commit id: \"feat(modules): ...\"\n  commit id: \"test(client): ...\"\n  checkout main\n  commit id: \"fix(api): ...\"\n  commit id: \"ci: ...\"\n  branch b1\n  commit\n  branch b2\n  commit\n```\n\n## Hiding commit labels\n\nSometimes you may want to hide the commit labels from the diagram. You can do this by using the `showCommitLabel` keyword. By default its value is `true`. You can set it to `false` using directives.\n\nUsage example:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'base'\n  gitGraph:\n    showBranches: false\n    showCommitLabel: false\n---\n      gitGraph\n        commit\n        branch hotfix\n        checkout hotfix\n        commit\n        branch develop\n        checkout develop\n        commit id:\"ash\"\n        branch featureB\n        checkout featureB\n        commit type:HIGHLIGHT\n        checkout main\n        checkout hotfix\n        commit type:NORMAL\n        checkout develop\n        commit type:REVERSE\n        checkout featureB\n        commit\n        checkout main\n        merge hotfix\n        checkout featureB\n        commit\n        checkout develop\n        branch featureA\n        commit\n        checkout develop\n        merge hotfix\n        checkout featureA\n        commit\n        checkout featureB\n        commit\n        checkout develop\n        merge featureA\n        branch release\n        checkout release\n        commit\n        checkout main\n        commit\n        checkout release\n        merge main\n        checkout develop\n        merge release\n```\n\n## Customizing main branch name\n\nSometimes you may want to customize the name of the main/default branch. You can do this by using the `mainBranchName` keyword. By default its value is `main`. You can set it to any string using directives.\n\nUsage example:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'base'\n  gitGraph:\n    showBranches: true\n    showCommitLabel: true\n    mainBranchName: 'MetroLine1'\n---\n      gitGraph\n        commit id:\"NewYork\"\n        commit id:\"Dallas\"\n        branch MetroLine2\n        commit id:\"LosAngeles\"\n        commit id:\"Chicago\"\n        commit id:\"Houston\"\n        branch MetroLine3\n        commit id:\"Phoenix\"\n        commit type: HIGHLIGHT id:\"Denver\"\n        commit id:\"Boston\"\n        checkout MetroLine1\n        commit id:\"Atlanta\"\n        merge MetroLine3\n        commit id:\"Miami\"\n        commit id:\"Washington\"\n        merge MetroLine2 tag:\"MY JUNCTION\"\n        commit id:\"Boston\"\n        commit id:\"Detroit\"\n        commit type:REVERSE id:\"SanFrancisco\"\n```\n\nLook at the imaginary railroad map created using Mermaid. Here, we have changed the default main branch name to `MetroLine1`.\n\n## Customizing branch ordering\n\nIn Mermaid, by default the branches are shown in the order of their definition or appearance in the diagram code.\n\nSometimes you may want to customize the order of the branches. You can do this by using the `order` keyword next the branch definition. You can set it to a positive number.\n\nMermaid follows the given precedence order of the `order` keyword.\n\n- Main branch is always shown first as it has default order value of `0`. (unless its order is modified and changed from `0` using the `mainBranchOrder` keyword in the config)\n- Next, All branches without an `order` are shown in the order of their appearance in the diagram code.\n- Next, All branches with an `order` are shown in the order of their `order` value.\n\nTo fully control the order of all the branches, you must define `order` for all the branches.\n\nUsage example:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'base'\n  gitGraph:\n    showBranches: true\n    showCommitLabel: true\n---\n      gitGraph\n      commit\n      branch test1 order: 3\n      branch test2 order: 2\n      branch test3 order: 1\n\n```\n\nLook at the diagram, all the branches are following the order defined.\n\nUsage example:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'base'\n  gitGraph:\n    showBranches: true\n    showCommitLabel: true\n    mainBranchOrder: 2\n---\n      gitGraph\n      commit\n      branch test1 order: 3\n      branch test2\n      branch test3\n      branch test4 order: 1\n\n```\n\nLook at the diagram, here, all the branches without a specified order are drawn in their order of definition.\nThen, `test4` branch is drawn because the order of `1`.\nThen, `main` branch is drawn because the order of `2`.\nAnd, lastly `test1`is drawn because the order of `3`.\n\nNOTE: Because we have overridden the `mainBranchOrder` to `2`, the `main` branch is not drawn in the beginning, instead follows the ordering.\n\nHere, we have changed the default main branch name to `MetroLine1`.\n\n## Orientation (v10.3.0+)\n\nMermaid supports three graph orientations: **Left-to-Right** (default), **Top-to-Bottom**, and **Bottom-to-Top**.\n\nYou can set this with either `LR:` (for [**Left-to-Right**](#left-to-right-default-lr)), `TB:` (for [**Top-to-Bottom**](#top-to-bottom-tb)) or `BT:` (for [**Bottom-to-Top**](#bottom-to-top-bt)) after `gitGraph`.\n\n### Left to Right (default, `LR:`)\n\nIn Mermaid, the default orientation is for commits to run from left to right and for branches to be stacked on top of one another.\n\nHowever, you can set this explicitly with `LR:` after `gitGraph`.\n\nUsage example:\n\n```mermaid-example\n    gitGraph LR:\n       commit\n       commit\n       branch develop\n       commit\n       commit\n       checkout main\n       commit\n       commit\n       merge develop\n       commit\n       commit\n```\n\n### Top to Bottom (`TB:`)\n\nIn `TB` (**Top-to-Bottom**) orientation, the commits run from top to bottom of the graph and branches are arranged side-by-side.\n\nTo orient the graph this way, you need to add `TB:` after gitGraph.\n\nUsage example:\n\n```mermaid-example\n    gitGraph TB:\n       commit\n       commit\n       branch develop\n       commit\n       commit\n       checkout main\n       commit\n       commit\n       merge develop\n       commit\n       commit\n```\n\n### Bottom to Top (`BT:`) (v11.0.0+)\n\nIn `BT` (**Bottom-to-Top**) orientation, the commits run from bottom to top of the graph and branches are arranged side-by-side.\n\nTo orient the graph this way, you need to add `BT:` after gitGraph.\n\nUsage example:\n\n```mermaid-example\n    gitGraph BT:\n       commit\n       commit\n       branch develop\n       commit\n       commit\n       checkout main\n       commit\n       commit\n       merge develop\n       commit\n       commit\n```\n\n## Parallel commits (v10.8.0+)\n\nCommits in Mermaid display temporal information in gitgraph by default. For example if two commits are one commit away from its parent, the commit that was made earlier is rendered closer to its parent. You can turn this off by enabling the `parallelCommits` flag.\n\n### Temporal Commits (default, `parallelCommits: false`)\n\n```mermaid-example\n---\nconfig:\n  gitGraph:\n    parallelCommits: false\n---\ngitGraph:\n  commit\n  branch develop\n  commit\n  commit\n  checkout main\n  commit\n  commit\n```\n\n### Parallel commits (`parallelCommits: true`)\n\n```mermaid-example\n---\nconfig:\n  gitGraph:\n    parallelCommits: true\n---\ngitGraph:\n  commit\n  branch develop\n  commit\n  commit\n  checkout main\n  commit\n  commit\n```\n\n## Themes\n\nMermaid supports a bunch of pre-defined themes which you can use to find the right one for you. PS: you can actually override an existing theme's variable to get your own custom theme going. Learn more about [theming your diagram](../config/theming.md).\n\nThe following are the different pre-defined theme options:\n\n- `redux-color` (the default)\n- `redux-dark-color`\n- `redux`\n- `redux-dark`\n- `default`\n- `neutral`\n- `dark`\n- `forest`\n- `neo`\n- `neo-dark`\n- `base`\n\n**NOTE**: To change theme you can either use the `initialize` call or _directives_. Learn more about [directives](../config/directives.md)\nLet's put a few of them to use, and see how our sample diagram looks in different themes:\n\n### Base Theme\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'base'\n---\n      gitGraph\n        commit\n        branch hotfix\n        checkout hotfix\n        commit\n        branch develop\n        checkout develop\n        commit id:\"ash\" tag:\"abc\"\n        branch featureB\n        checkout featureB\n        commit type:HIGHLIGHT\n        checkout main\n        checkout hotfix\n        commit type:NORMAL\n        checkout develop\n        commit type:REVERSE\n        checkout featureB\n        commit\n        checkout main\n        merge hotfix\n        checkout featureB\n        commit\n        checkout develop\n        branch featureA\n        commit\n        checkout develop\n        merge hotfix\n        checkout featureA\n        commit\n        checkout featureB\n        commit\n        checkout develop\n        merge featureA\n        branch release\n        checkout release\n        commit\n        checkout main\n        commit\n        checkout release\n        merge main\n        checkout develop\n        merge release\n```\n\n### Forest Theme\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'forest'\n---\n      gitGraph\n        commit\n        branch hotfix\n        checkout hotfix\n        commit\n        branch develop\n        checkout develop\n        commit id:\"ash\" tag:\"abc\"\n        branch featureB\n        checkout featureB\n        commit type:HIGHLIGHT\n        checkout main\n        checkout hotfix\n        commit type:NORMAL\n        checkout develop\n        commit type:REVERSE\n        checkout featureB\n        commit\n        checkout main\n        merge hotfix\n        checkout featureB\n        commit\n        checkout develop\n        branch featureA\n        commit\n        checkout develop\n        merge hotfix\n        checkout featureA\n        commit\n        checkout featureB\n        commit\n        checkout develop\n        merge featureA\n        branch release\n        checkout release\n        commit\n        checkout main\n        commit\n        checkout release\n        merge main\n        checkout develop\n        merge release\n```\n\n### The `default` Theme\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n---\n      gitGraph\n        commit type:HIGHLIGHT\n        branch hotfix\n        checkout hotfix\n        commit\n        branch develop\n        checkout develop\n        commit id:\"ash\" tag:\"abc\"\n        branch featureB\n        checkout featureB\n        commit type:HIGHLIGHT\n        checkout main\n        checkout hotfix\n        commit type:NORMAL\n        checkout develop\n        commit type:REVERSE\n        checkout featureB\n        commit\n        checkout main\n        merge hotfix\n        checkout featureB\n        commit\n        checkout develop\n        branch featureA\n        commit\n        checkout develop\n        merge hotfix\n        checkout featureA\n        commit\n        checkout featureB\n        commit\n        checkout develop\n        merge featureA\n        branch release\n        checkout release\n        commit\n        checkout main\n        commit\n        checkout release\n        merge main\n        checkout develop\n        merge release\n```\n\n### Dark Theme\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'dark'\n---\n      gitGraph\n        commit\n        branch hotfix\n        checkout hotfix\n        commit\n        branch develop\n        checkout develop\n        commit id:\"ash\" tag:\"abc\"\n        branch featureB\n        checkout featureB\n        commit type:HIGHLIGHT\n        checkout main\n        checkout hotfix\n        commit type:NORMAL\n        checkout develop\n        commit type:REVERSE\n        checkout featureB\n        commit\n        checkout main\n        merge hotfix\n        checkout featureB\n        commit\n        checkout develop\n        branch featureA\n        commit\n        checkout develop\n        merge hotfix\n        checkout featureA\n        commit\n        checkout featureB\n        commit\n        checkout develop\n        merge featureA\n        branch release\n        checkout release\n        commit\n        checkout main\n        commit\n        checkout release\n        merge main\n        checkout develop\n        merge release\n```\n\n### Neutral Theme\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'neutral'\n---\n      gitGraph\n        commit\n        branch hotfix\n        checkout hotfix\n        commit\n        branch develop\n        checkout develop\n        commit id:\"ash\" tag:\"abc\"\n        branch featureB\n        checkout featureB\n        commit type:HIGHLIGHT\n        checkout main\n        checkout hotfix\n        commit type:NORMAL\n        checkout develop\n        commit type:REVERSE\n        checkout featureB\n        commit\n        checkout main\n        merge hotfix\n        checkout featureB\n        commit\n        checkout develop\n        branch featureA\n        commit\n        checkout develop\n        merge hotfix\n        checkout featureA\n        commit\n        checkout featureB\n        commit\n        checkout develop\n        merge featureA\n        branch release\n        checkout release\n        commit\n        checkout main\n        commit\n        checkout release\n        merge main\n        checkout develop\n        merge release\n```\n\n## Customize using Theme Variables\n\nMermaid allows you to customize your diagram using theme variables which govern the look and feel of various elements of the diagram.\n\nFor understanding let us take a sample diagram with theme `default`, the default values of the theme variables is picked automatically from the theme. Later on we will see how to override the default values of the theme variables.\n\nSee how the `default` theme is used to set the colors for the branches:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n---\n       gitGraph\n       commit\n       branch develop\n       commit tag:\"v1.0.0\"\n       commit\n       checkout main\n       commit type: HIGHLIGHT\n       commit\n       merge develop\n       commit\n       branch featureA\n       commit\n```\n\n> #### IMPORTANT:\n>\n> Mermaid supports the theme variables to override the default values for **up to 8 branches**, i.e., you can set the color/styling of up to 8 branches using theme variables. After this threshold of 8 branches, the theme variables are reused in the cyclic manner, i.e. the 9th branch will use the color/styling of the 1st branch, or the branch at index position '8' will use the color/styling of the branch at index position '0'.\n> _More on this in the next section. See examples on **Customizing branch label colors** below_\n\n### Customizing branch colors\n\nYou can customize the branch colors using the `git0` to `git7` theme variables. Mermaid allows you to set the colors for up-to 8 branches, where `git0` variable will drive the value of the first branch, `git1` will drive the value of the second branch and so on.\n\nNOTE: Default values for these theme variables are picked from the selected theme. If you want to override the default values, you can use the `initialize` call to add your custom theme variable values.\n\nExample:\n\nNow let's override the default values for the `git0` to `git3` variables:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n  themeVariables:\n      'git0': '#ff0000'\n      'git1': '#00ff00'\n      'git2': '#0000ff'\n      'git3': '#ff00ff'\n      'git4': '#00ffff'\n      'git5': '#ffff00'\n      'git6': '#ff00ff'\n      'git7': '#00ffff'\n---\n       gitGraph\n       commit\n       branch develop\n       commit tag:\"v1.0.0\"\n       commit\n       checkout main\n       commit type: HIGHLIGHT\n       commit\n       merge develop\n       commit\n       branch featureA\n       commit\n\n```\n\nSee how the branch colors are changed to the values specified in the theme variables.\n\n### Customizing branch label colors\n\nYou can customize the branch label colors using the `gitBranchLabel0` to `gitBranchLabel7` theme variables. Mermaid allows you to set the colors for up-to 8 branches, where `gitBranchLabel0` variable will drive the value of the first branch label, `gitBranchLabel1` will drive the value of the second branch label and so on.\n\nLets see how the `default` theme is used to set the colors for the branch labels:\n\nNow let's override the default values for the `gitBranchLabel0` to `gitBranchLabel2` variables:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n  themeVariables:\n    'gitBranchLabel0': '#ffffff'\n    'gitBranchLabel1': '#ffffff'\n    'gitBranchLabel2': '#ffffff'\n    'gitBranchLabel3': '#ffffff'\n    'gitBranchLabel4': '#ffffff'\n    'gitBranchLabel5': '#ffffff'\n    'gitBranchLabel6': '#ffffff'\n    'gitBranchLabel7': '#ffffff'\n    'gitBranchLabel8': '#ffffff'\n    'gitBranchLabel9': '#ffffff'\n---\n  gitGraph\n    checkout main\n    branch branch1\n    branch branch2\n    branch branch3\n    branch branch4\n    branch branch5\n    branch branch6\n    branch branch7\n    branch branch8\n    branch branch9\n    checkout branch1\n    commit\n```\n\nHere, you can see that `branch8` and `branch9` colors and the styles are being picked from branch at index position `0` (`main`) and `1`(`branch1`) respectively, i.e., **branch themeVariables are repeated cyclically**.\n\n### Customizing Commit colors\n\nYou can customize commit using the `commitLabelColor` and `commitLabelBackground` theme variables for changes in the commit label color and background color respectively.\n\nExample:\nNow let's override the default values for the `commitLabelColor` to `commitLabelBackground` variables:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n  themeVariables:\n    commitLabelColor: '#ff0000'\n    commitLabelBackground: '#00ff00'\n---\n       gitGraph\n       commit\n       branch develop\n       commit tag:\"v1.0.0\"\n       commit\n       checkout main\n       commit type: HIGHLIGHT\n       commit\n       merge develop\n       commit\n       branch featureA\n       commit\n\n```\n\nSee how the commit label color and background color are changed to the values specified in the theme variables.\n\n### Customizing Commit Label Font Size\n\nYou can customize commit using the `commitLabelFontSize` theme variables for changing in the font size of the commit label .\n\nExample:\nNow let's override the default values for the `commitLabelFontSize` variable:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n  themeVariables:\n    commitLabelColor: '#ff0000'\n    commitLabelBackground: '#00ff00'\n    commitLabelFontSize: '16px'\n---\n       gitGraph\n       commit\n       branch develop\n       commit tag:\"v1.0.0\"\n       commit\n       checkout main\n       commit type: HIGHLIGHT\n       commit\n       merge develop\n       commit\n       branch featureA\n       commit\n\n```\n\nSee how the commit label font size changed.\n\n### Customizing Tag Label Font Size\n\nYou can customize commit using the `tagLabelFontSize` theme variables for changing in the font size of the tag label .\n\nExample:\nNow let's override the default values for the `tagLabelFontSize` variable:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n  themeVariables:\n    commitLabelColor: '#ff0000'\n    commitLabelBackground: '#00ff00'\n    tagLabelFontSize: '16px'\n---\n       gitGraph\n       commit\n       branch develop\n       commit tag:\"v1.0.0\"\n       commit\n       checkout main\n       commit type: HIGHLIGHT\n       commit\n       merge develop\n       commit\n       branch featureA\n       commit\n\n```\n\nSee how the tag label font size changed.\n\n### Customizing Tag colors\n\nYou can customize tag using the `tagLabelColor`,`tagLabelBackground` and `tagLabelBorder` theme variables for changes in the tag label color,tag label background color and tag label border respectively.\nExample:\nNow let's override the default values for the `tagLabelColor`, `tagLabelBackground` and to `tagLabelBorder` variables:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n  themeVariables:\n    tagLabelColor: '#ff0000'\n    tagLabelBackground: '#00ff00'\n    tagLabelBorder: '#0000ff'\n---\n       gitGraph\n       commit\n       branch develop\n       commit tag:\"v1.0.0\"\n       commit\n       checkout main\n       commit type: HIGHLIGHT\n       commit\n       merge develop\n       commit\n       branch featureA\n       commit\n\n```\n\nSee how the tag colors are changed to the values specified in the theme variables.\n\n### Customizing Highlight commit colors\n\nYou can customize the highlight commit colors in relation to the branch it is on using the `gitInv0` to `gitInv7` theme variables. Mermaid allows you to set the colors for up-to 8 branches specific highlight commit, where `gitInv0` variable will drive the value of the first branch's highlight commits, `gitInv1` will drive the value of the second branch's highlight commit label and so on.\n\nExample:\n\nNow let's override the default values for the `git0` to `git3` variables:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n  themeVariables:\n    'gitInv0': '#ff0000'\n---\n       gitGraph\n       commit\n       branch develop\n       commit tag:\"v1.0.0\"\n       commit\n       checkout main\n       commit type: HIGHLIGHT\n       commit\n       merge develop\n       commit\n       branch featureA\n       commit\n\n```\n\nSee how the highlighted commit color on the first branch is changed to the value specified in the theme variable `gitInv0`.\n","packages/mermaid/src/docs/syntax/ishikawa.md":"# Ishikawa diagram (v11.12.3+)\n\nIshikawa diagrams are used to represent causes of a specific event (or a problem).\nThey are also known as fishbone diagrams, herringbone diagrams or cause-and-effect diagrams.\nThe diagram resembles a fish skeleton, with the main problem at the head and the causes branching off from the spine.\n\n```warning\nThis is a new diagram type in Mermaid. Its syntax may evolve in future versions.\n```\n\n## Syntax\n\n```mermaid\nishikawa-beta\n    Blurry Photo\n    Process\n        Out of focus\n        Shutter speed too slow\n        Protective film not removed\n        Beautification filter applied\n    User\n        Shaky hands\n    Equipment\n        LENS\n            Inappropriate lens\n            Damaged lens\n            Dirty lens\n        SENSOR\n            Damaged sensor\n            Dirty sensor\n    Environment\n        Subject moved too quickly\n        Too dark\n```\n\n- The first line is the event (problem) of the diagram.\n- Subsequent lines are causes of the event.\n- \"Fishbone\" structure is indicated by indentation.\n","packages/mermaid/src/docs/syntax/kanban.md":"# Mermaid Kanban Diagram Documentation\n\nMermaid’s Kanban diagram allows you to create visual representations of tasks moving through different stages of a workflow. This guide explains how to use the Kanban diagram syntax, based on the provided example.\n\n## Overview\n\nA Kanban diagram in Mermaid starts with the kanban keyword, followed by the definition of columns (stages) and tasks within those columns.\n\n```mermaid-example\nkanban\n  column1[Column Title]\n    task1[Task Description]\n```\n\n## Defining Columns\n\nColumns represent the different stages in your workflow, such as “Todo,” “In Progress,” “Done,” etc. Each column is defined using a unique identifier and a title enclosed in square brackets.\n\n**Syntax:**\n\n```\ncolumnId[Column Title]\n```\n\n- columnId: A unique identifier for the column.\n- [Column Title]: The title displayed on the column header.\n\nLike this `id1[Todo]`\n\n## Adding Tasks to Columns\n\nTasks are listed under their respective columns with an indentation. Each task also has a unique identifier and a description enclosed in square brackets.\n\n**Syntax:**\n\n```\ntaskId[Task Description]\n```\n\n    •\ttaskId: A unique identifier for the task.\n    •\t[Task Description]: The description of the task.\n\n**Example:**\n\n```\ndocs[Create Documentation]\n```\n\n## Adding Metadata to Tasks\n\nYou can include additional metadata for each task using the @{ ... } syntax. Metadata can contain key-value pairs like assigned, ticket, priority, etc. This will be rendered added to the rendering of the node.\n\n## Supported Metadata Keys\n\n    •\tassigned: Specifies who is responsible for the task.\n    •\tticket: Links the task to a ticket or issue number.\n    •\tpriority: Indicates the urgency of the task. Allowed values: 'Very High', 'High', 'Low' and 'Very Low'\n\n```mermaid-example\nkanban\ntodo[Todo]\n  id3[Update Database Function]@{ ticket: MC-2037, assigned: 'knsv', priority: 'High' }\n```\n\n## Configuration Options\n\nYou can customize the Kanban diagram using a configuration block at the beginning of your markdown file. This is useful for setting global settings like a base URL for tickets. Currently there is one configuration option for kanban diagrams `ticketBaseUrl`. This can be set as in the following example:\n\n```yaml\n---\nconfig:\n  kanban:\n    ticketBaseUrl: 'https://yourproject.atlassian.net/browse/#TICKET#'\n---\n```\n\nWhen the kanban item has an assigned ticket number the ticket number in the diagram will have a link to an external system where the ticket is defined. The `ticketBaseUrl` sets the base URL to the external system and #TICKET# is replaced with the ticket value from task metadata to create a valid link.\n\n## Full Example\n\nBelow is the full Kanban diagram based on the provided example:\n\n```mermaid-example\n---\nconfig:\n  kanban:\n    ticketBaseUrl: 'https://mermaidchart.atlassian.net/browse/#TICKET#'\n---\nkanban\n  Todo\n    [Create Documentation]\n    docs[Create Blog about the new diagram]\n  [In progress]\n    id6[Create renderer so that it works in all cases. We also add some extra text here for testing purposes. And some more just for the extra flare.]\n  id9[Ready for deploy]\n    id8[Design grammar]@{ assigned: 'knsv' }\n  id10[Ready for test]\n    id4[Create parsing tests]@{ ticket: MC-2038, assigned: 'K.Sveidqvist', priority: 'High' }\n    id66[last item]@{ priority: 'Very Low', assigned: 'knsv' }\n  id11[Done]\n    id5[define getData]\n    id2[Title of diagram is more than 100 chars when user duplicates diagram with 100 char]@{ ticket: MC-2036, priority: 'Very High'}\n    id3[Update DB function]@{ ticket: MC-2037, assigned: knsv, priority: 'High' }\n\n  id12[Can't reproduce]\n    id3[Weird flickering in Firefox]\n```\n\nIn conclusion, creating a Kanban diagram in Mermaid is a straightforward process that effectively visualizes your workflow. Start by using the kanban keyword to initiate the diagram. Define your columns with unique identifiers and titles to represent different stages of your project. Under each column, list your tasks—also with unique identifiers—and provide detailed descriptions as needed. Remember that proper indentation is crucial; tasks must be indented under their parent columns to maintain the correct structure.\n\nYou can enhance your diagram by adding optional metadata to tasks using the @{ ... } syntax, which allows you to include additional context such as assignee, ticket numbers, and priority levels. For further customization, utilize the configuration block at the top of your file to set global options like ticketBaseUrl for linking tickets directly from your diagram.\n\nBy adhering to these guidelines—ensuring unique identifiers, proper indentation, and utilizing metadata and configuration options—you can create a comprehensive and customized Kanban board that effectively maps out your project’s workflow using Mermaid.\n","packages/mermaid/src/docs/syntax/mindmap.md":"# Mindmap\n\n> Mindmap: This is an experimental diagram for now. The syntax and properties can change in future releases. The syntax is stable except for the icon integration which is the experimental part.\n\n\"A mind map is a diagram used to visually organize information into a hierarchy, showing relationships among pieces of the whole. It is often created around a single concept, drawn as an image in the center of a blank page, to which associated representations of ideas such as images, words and parts of words are added. Major ideas are connected directly to the central concept, and other ideas branch out from those major ideas.\" Wikipedia\n\n### An example of a mindmap.\n\n```mermaid\nmindmap\n  root((mindmap))\n    Origins\n      Long history\n      ::icon(fa fa-book)\n      Popularisation\n        British popular psychology author Tony Buzan\n    Research\n      On effectiveness
and features\n      On Automatic creation\n        Uses\n            Creative techniques\n            Strategic planning\n            Argument mapping\n    Tools\n      Pen and paper\n      Mermaid\n\n```\n\n## Syntax\n\nThe syntax for creating Mindmaps is simple and relies on indentation for setting the levels in the hierarchy.\n\nIn the following example you can see how there are 3 different levels. One with starting at the left of the text and another level with two rows starting at the same column, defining the node A. At the end there is one more level where the text is indented further than the previous lines defining the nodes B and C.\n\n```\nmindmap\n    Root\n        A\n            B\n            C\n```\n\nIn summary is a simple text outline where there is one node at the root level called `Root` which has one child `A`. `A` in turn has two children `B`and `C`. In the diagram below we can see this rendered as a mindmap.\n\n```mermaid\nmindmap\nRoot\n    A\n      B\n      C\n```\n\nIn this way we can use a text outline to generate a hierarchical mindmap.\n\n## Different shapes\n\nMermaid mindmaps can show nodes using different shapes. When specifying a shape for a node the syntax is similar to flowchart nodes, with an id followed by the shape definition and with the text within the shape delimiters. Where possible we try/will try to keep the same shapes as for flowcharts, even though they are not all supported from the start.\n\nMindmap can show the following shapes:\n\n### Square\n\n```mermaid-example\nmindmap\n    id[I am a square]\n```\n\n### Rounded square\n\n```mermaid-example\nmindmap\n    id(I am a rounded square)\n```\n\n### Circle\n\n```mermaid-example\nmindmap\n    id((I am a circle))\n```\n\n### Bang\n\n```mermaid-example\nmindmap\n    id))I am a bang((\n```\n\n### Cloud\n\n```mermaid-example\nmindmap\n    id)I am a cloud(\n```\n\n### Hexagon\n\n```mermaid-example\nmindmap\n    id{{I am a hexagon}}\n```\n\n### Default\n\n```mermaid-example\nmindmap\n    I am the default shape\n```\n\nMore shapes will be added, beginning with the shapes available in flowcharts.\n\n## Coloring by depth (v12.2.0+)\n\nBy default, mindmaps use a different color for each top-level branch. Descendants inherit their branch's color. Set `mindmap.colorBy` to `depth` to give all nodes at the same hierarchy level the same color, across every branch:\n\n```mermaid-example\n---\nconfig:\n  mindmap:\n    colorBy: depth\n---\nmindmap\n  root((mindmap))\n    origins{{Origins}}\n      history[Long history]\n        Popularisation\n        British popular psychology author Tony Buzan\n    research{{Research}}\n      uses[Uses]\n        Creative techniques\n```\n\nDepth counts parent-child relationships, not spaces: the root has depth 0, its children have depth 1, and their children have depth 2. Uneven indentation does not change the color of nodes that share a depth.\n\nWith the classic look, the root uses `git0` for its background and `gitBranchLabel0` for its label (`redux` themes color HTML labels with `nodeBorder` instead). Depths 1 through 11 use `cScale1` through `cScale11` for backgrounds and `cScaleLabel1` through `cScaleLabel11` for labels. Deeper levels repeat those eleven colors. Each edge uses the `cScale` color of its child node.\n\nTo choose the color of each level, set those variables with the `base` theme and pick contrasting background and label colors. The `neo` look colors the root label with `cScaleLabel0`, so set it too. In the `neo` look, also set `useGradient: false`, because otherwise `base` paints every node with `mainBkg`:\n\n```mermaid-example\n---\nconfig:\n  theme: base\n  mindmap:\n    colorBy: depth\n  themeVariables:\n    git0: '#374151'\n    gitBranchLabel0: '#ffffff'\n    cScaleLabel0: '#ffffff'\n    cScale1: '#bfdbfe'\n    cScaleLabel1: '#172554'\n    cScale2: '#bbf7d0'\n    cScaleLabel2: '#14532d'\n    cScale3: '#fde68a'\n    cScaleLabel3: '#451a03'\n---\nmindmap\n  root((mindmap))\n    origins{{Origins}}\n      history[Long history]\n        Popularisation\n        British popular psychology author Tony Buzan\n    research{{Research}}\n      uses[Uses]\n        Creative techniques\n```\n\nDepth mode uses the same theme styles as branch coloring and only changes which nodes share a color. In the `neo` look, some themes use one background for every node in both modes:\n\n- Themes with `useGradient` enabled paint every node, including the root, with `mainBkg`. It is on by default in `base`, `dark`, `forest`, `neo`, `neo-dark` and `neutral`. Set `themeVariables.useGradient: false` to show depth colors on node backgrounds.\n- `neutral`, `redux` and `redux-dark` paint every node below the root with `mainBkg` even without the gradient, and use one label color for all of them.\n\nIn the `neo` look, the root label uses `cScaleLabel0` (`cScaleLabel1` in `neutral`, `nodeBorder` in `redux` themes). Edges keep their depth colors, except in `neo-dark` and the `redux` themes.\n\nSet `mindmap.colorBy` to `branch` (the default) to restore branch coloring.\n\n# Icons and classes\n\n## Icons\n\nAs with flowcharts you can add icons to your nodes but with an updated syntax. The styling for the font based icons are added during the integration so that they are available for the web page. _This is not something a diagram author can do but has to be done with the site administrator or the integrator_. Once the icon fonts are in place you add them to the mind map nodes using the `::icon()` syntax. You place the classes for the icon within the parenthesis like in the following example where icons for material design and [Font Awesome 5](https://fontawesome.com/v5/search?o=r&m=free) are displayed. The intention is that this approach should be used for all diagrams supporting icons. **Experimental feature:** This wider scope is also the reason Mindmaps are experimental as this syntax and approach could change.\n\n```mermaid-example\nmindmap\n    Root\n        A\n        ::icon(fa fa-book)\n        B(B)\n        ::icon(mdi mdi-skull-outline)\n```\n\n## Classes\n\nAgain the syntax for adding classes is similar to flowcharts. You can add classes using a triple colon following a number of css classes separated by space. In the following example one of the nodes has two custom classes attached urgent turning the background red and the text white and large increasing the font size:\n\n```mermaid-example\nmindmap\n    Root\n        A[A]\n        :::urgent large\n        B(B)\n        C\n```\n\n_These classes need to be supplied by the site administrator._\n\n## Unclear indentation\n\nThe actual indentation does not really matter only compared with the previous rows. If we take the previous example and disrupt it a little we can see how the calculations are performed. Let us start with placing C with a smaller indentation than `B` but larger then `A`.\n\n```\nmindmap\n    Root\n        A\n            B\n          C\n```\n\nThis outline is unclear as `B` clearly is a child of `A` but when we move on to `C` the clarity is lost. `C` is neither a child of `B` with a higher indentation nor does it have the same indentation as `B`. The only thing that is clear is that the first node with smaller indentation, indicating a parent, is A. Then Mermaid relies on this known truth and compensates for the unclear indentation and selects `A` as a parent of `C` leading till the same diagram with `B` and `C` as siblings.\n\n```mermaid\nmindmap\nRoot\n    A\n        B\n      C\n```\n\n## Markdown Strings\n\nThe \"Markdown Strings\" feature enhances mind maps by offering a more versatile string type, which supports text formatting options such as bold and italics, and automatically wraps text within labels.\n\n```mermaid-example\nmindmap\n    id1[\"`**Root** with\na second line\nUnicode works too: 🤓`\"]\n      id2[\"`The dog in **the** hog... a *very long text* that wraps to a new line`\"]\n      id3[Regular labels still works]\n```\n\nFormatting:\n\n- For bold text, use double asterisks \\*\\* before and after the text.\n- For italics, use single asterisks \\* before and after the text.\n- With traditional strings, you needed to add 
 tags for text to wrap in nodes. However, markdown strings automatically wrap text when it becomes too long and allows you to start a new line by simply using a newline character instead of a 
 tag.\n\n## Integrating with your library/website.\n\nMindmap uses the experimental lazy loading & async rendering features which could change in the future. From version 9.4.0 this diagram is included in mermaid but use lazy loading in order to keep the size of mermaid down. This is important in order to be able to add additional diagrams going forward.\n\nYou can still use the pre 9.4.0 method to add mermaid with mindmaps to a web page:\n\n```html\n\n```\n\nFrom version 9.4.0 you can simplify this code to:\n\n```html\n\n```\n\nYou can also refer the [implementation in the live editor](https://github.com/mermaid-js/mermaid-live-editor/blob/develop/src/lib/util/mermaid.ts) to see how the async loading is done.\n\n\n\n## Layouts\n\nMermaid also supports a Tidy Tree layout for mindmaps.\n\n```\n---\nconfig:\n  layout: tidy-tree\n---\nmindmap\nroot((mindmap is a long thing))\n  A\n  B\n  C\n  D\n```\n\nInstructions to add and register tidy-tree layout are present in [Tidy Tree Configuration](/config/tidy-tree)\n","packages/mermaid/src/docs/syntax/packet.md":"# Packet Diagram (v11.0.0+)\n\n## Introduction\n\nA packet diagram is a visual representation used to illustrate the structure and contents of a network packet. Network packets are the fundamental units of data transferred over a network.\n\n## Usage\n\nThis diagram type is particularly useful for developers, network engineers, educators, and students who require a clear and concise way to represent the structure of network packets.\n\n## Syntax\n\n```\npacket\nstart: \"Block name\" %% Single-bit block\nstart-end: \"Block name\" %% Multi-bit blocks\n... More Fields ...\n```\n\n### Bits Syntax (v11.7.0+)\n\nUsing start and end bit counts can be difficult, especially when modifying a design. For this we add a bit count field, which starts from the end of the previous field automagically. Use `+` to set the number of bits, thus:\n\n```\npacket\n+1: \"Block name\" %% Single-bit block\n+8: \"Block name\" %% 8-bit block\n9-15: \"Manually set start and end, it's fine to mix and match\"\n... More Fields ...\n```\n\n## Examples\n\n```mermaid-example\n---\ntitle: \"TCP Packet\"\n---\npacket\n0-15: \"Source Port\"\n16-31: \"Destination Port\"\n32-63: \"Sequence Number\"\n64-95: \"Acknowledgment Number\"\n96-99: \"Data Offset\"\n100-105: \"Reserved\"\n106: \"URG\"\n107: \"ACK\"\n108: \"PSH\"\n109: \"RST\"\n110: \"SYN\"\n111: \"FIN\"\n112-127: \"Window\"\n128-143: \"Checksum\"\n144-159: \"Urgent Pointer\"\n160-191: \"(Options and Padding)\"\n192-255: \"Data (variable length)\"\n```\n\n```mermaid-example\npacket\ntitle UDP Packet\n+16: \"Source Port\"\n+16: \"Destination Port\"\n32-47: \"Length\"\n48-63: \"Checksum\"\n64-95: \"Data (variable length)\"\n```\n\n## Details of Syntax\n\n- **Ranges**: Each line after the title represents a different field in the packet. The range (e.g., `0-15`) indicates the bit positions in the packet.\n- **Field Description**: A brief description of what the field represents, enclosed in quotes.\n\n### Bit Numbering Order (v12.0.0+)\n\nRows are numbered from their lowest bit on the left up to their highest bit on the right, which suits network packets. Hardware registers are conventionally drawn the other way round, with the most significant bit on the left and bit 0 on the right. Set `bitOrder: descending` to mirror every row:\n\n```mermaid-example\n---\nconfig:\n  packet:\n    showBits: true\n    bitOrder: descending\n    bitsPerRow: 16\n---\npacket\n0-7: \"DATA\"\n8-11: \"TYPE\"\n12: \"EN\"\n13-15: \"RESERVED\"\n```\n\nOnly the drawing is mirrored. Fields are still declared lowest bit first (`0-7`, never `7-0`) and keep their width, so the same diagram can be switched between the two conventions by changing `bitOrder` alone.\n\nEach row is mirrored on its own, so a packet wider than `bitsPerRow` reads as a stack of words that each run from their highest bit down to their lowest: with the default `bitsPerRow: 32`, the second row runs from bit 63 down to bit 32, not down to bit 0. A row that is not completely filled is padded on the left, keeping its lowest bit flush against the right edge.\n\n## Configuration\n\nPlease refer to the [configuration](/config/schema-docs/config-defs-packet-diagram-config.html) guide for details.\n\n\n","packages/mermaid/src/docs/syntax/pie.md":"","packages/mermaid/src/docs/syntax/quadrantChart.md":"","packages/mermaid/src/docs/syntax/radar.md":"","packages/mermaid/src/docs/syntax/railroad.md":"","packages/mermaid/src/docs/syntax/requirementDiagram.md":"","packages/mermaid/src/docs/syntax/sankey.md":"","packages/mermaid/src/docs/syntax/sequenceDiagram.md":"","packages/mermaid/src/docs/syntax/stateDiagram.md":"","packages/mermaid/src/docs/syntax/swimlanes.md":"","packages/mermaid/src/docs/syntax/timeline.md":"","packages/mermaid/src/docs/syntax/treeView.md":"","packages/mermaid/src/docs/syntax/treemap.md":"","packages/mermaid/src/docs/syntax/usecase.md":"","packages/mermaid/src/docs/syntax/userJourney.md":"","packages/mermaid/src/docs/syntax/venn.md":"","packages/mermaid/src/docs/syntax/wardley.md":"","packages/mermaid/src/docs/syntax/xyChart.md":"","packages/mermaid/src/docs/syntax/zenuml.md":"","packages/mermaid/src/docs/tsconfig.json":"","packages/parser/README.md":"","packages/tiny/README.md":""},"files":{"packages/examples/README.md":"","packages/mermaid-layout-elk/README.md":"","packages/mermaid-layout-tidy-tree/README.md":"","packages/mermaid-local-editor/README.md":"","packages/mermaid-zenuml/README.md":"","packages/mermaid/src/docs/adding-new-shape.md":"# Custom SVG Shapes Library\n\nThis library provides a collection of custom SVG shapes, utilities, and helpers for generating diagram components. The shapes are designed to be used within an SVG container and include a variety of common and complex shapes.\n\n## Overview\n\n## Shape Helpers and Utilities\n\nBefore starting with shape creation, it's essential to familiarize yourself with the utilities provided in the `utils.ts` file from `packages/mermaid/src/rendering-util/rendering-elements/shapes/util.js`. These utilities are designed to assist with various aspects of SVG shape manipulation and ensure consistent and accurate rendering.\n\n## Available Utilities\n\n### 1. `labelHelper`\n\n- **Purpose**: This function creates and inserts labels inside SVG shapes.\n- **Features**:\n  - Handles both HTML labels and plain text.\n  - Calculates the bounding box dimensions of the label.\n  - Ensures proper positioning of labels within shapes.\n\n### 2. `updateNodeBounds`\n\n- **Purpose**: Updates the bounding box dimensions (width and height) of a node.\n- **Usage**:\n  - Adjusts the size of the node to fit the content or shape.\n  - Useful for ensuring that shapes resize appropriately based on their content.\n\n### 3. `insertPolygonShape`\n\n- **Purpose**: Inserts a polygon shape into an SVG container.\n- **Features**:\n  - Handles the creation and insertion of complex polygonal shapes.\n  - Configures the shape's appearance and positioning within the SVG container.\n\n### 4. `getNodeClasses`\n\n- **Purpose**: Returns the appropriate CSS classes for a node based on its configuration.\n- **Usage**:\n  - Dynamically applies CSS classes to nodes for styling purposes.\n  - Ensures that nodes adhere to the desired design and theme.\n\n### 5. `createPathFromPoints`\n\n- **Purpose**: Generates an SVG path string from an array of points.\n- **Usage**:\n  - Converts a list of points into a smooth path.\n  - Useful for creating custom shapes or paths within the SVG.\n\n### 6. `generateFullSineWavePoints`\n\n- **Purpose**: Generates points for a sine wave, useful for creating wavy-edged shapes.\n- **Usage**:\n  - Facilitates the creation of shapes with wavy or sine-wave edges.\n  - Can be used to add decorative or dynamic edges to shapes.\n\n## Getting Started\n\nTo utilize these utilities, simply import them from the `utils.ts` file into your shape creation script. These helpers will streamline the process of building and customizing SVG shapes, ensuring consistent results across your projects.\n\n```typescript\nimport {\n  labelHelper,\n  updateNodeBounds,\n  insertPolygonShape,\n  getNodeClasses,\n  createPathFromPoints,\n  generateFullSineWavePoints,\n} from './utils.ts';\n```\n\n## Example Usage\n\nHere’s a basic example of how you might use some of these utilities:\n\n```typescript\nimport { labelHelper, insertPolygonShape } from './utils.ts';\n\nconst svgContainer = document.getElementById('svgContainer');\n\n// Insert a polygon shape\ninsertPolygonShape(svgContainer /* shape-specific parameters */);\n\n// Create and insert a label inside the shape\nlabelHelper(svgContainer /* label-specific parameters */);\n```\n\n## Adding New Shapes\n\n### 1. Create the Shape Function\n\nTo add a new shape:\n\n- **Create the shape function**: Create a new file of name of the shape and export a function in the `shapes` directory that generates your shape. The file and function should follow the pattern used in existing shapes and return an SVG element.\n\n- **Example**:\n\n  ```typescript\n  import { Node, RenderOptions } from '../../types.ts';\n\n  export const myNewShape = async (\n    parent: SVGAElement,\n    node: Node,\n    renderOptions: RenderOptions\n  ) => {\n    // Create your shape here\n    const shape = parent.insert('g').attr('class', 'my-new-shape');\n    // Add other elements or styles as needed\n    return shape;\n  };\n  ```\n\n### 2. Register the Shape\n\n- **Register the shape**: Add your shape to the `shapes` object in the [main shapes module](../rendering-util/rendering-elements/shapes.ts). This allows your shape to be recognized and used within the system.\n\n- **Example**:\n\n  ```typescript\n  import { myNewShape } from './shapes/myNewShape';\n\n  const shapes = {\n    ...,\n    {\n      semanticName: 'My Shape',\n      name: 'Shape Name',\n      shortName: '',\n      description: '',\n      aliases: ['', '', '', ''],\n      handler: myNewShape,\n    },\n  };\n  ```\n\n# Shape Intersection Algorithms\n\nThis contains algorithms and utilities for calculating intersection points for various shapes in SVG. Arrow intersection points are crucial for accurately determining where arrows connect with shapes. Ensuring precise intersection points enhances the clarity and accuracy of flowcharts and diagrams.\n\n## Shape Intersection Functions\n\n### 1. `Ellipse`\n\nCalculates the intersection points for an ellipse.\n\n**Usage**:\n\n```javascript\nimport intersectEllipse from './intersect-ellipse.js';\n\nconst intersection = intersectEllipse(node, rx, ry, point);\n```\n\n- **Parameters**:\n  - `node`: The SVG node element.\n  - `rx`: The x-radius of the ellipse.\n  - `ry`: The y-radius of the ellipse.\n  - `point`: The point from which the intersection is calculated.\n\n### 2. `intersectRect`\n\nCalculates the intersection points for a rectangle.\n\n**Usage**:\n\n```javascript\nimport intersectRect from './intersect-rect.js';\n\nconst intersection = intersectRect(node, point);\n```\n\n- **Parameters**:\n  - `node`: The SVG node element.\n  - `point`: The point from which the intersection is calculated.\n\n### 3. `intersectPolygon`\n\nCalculates the intersection points for a polygon.\n\n**Usage**:\n\n```javascript\nimport intersectPolygon from './intersect-polygon.js';\n\nconst intersection = intersectPolygon(node, polyPoints, point);\n```\n\n- **Parameters**:\n  - `node`: The SVG node element.\n  - `polyPoints`: Array of points defining the polygon.\n  - `point`: The point from which the intersection is calculated.\n\n## Cypress Tests\n\nTo ensure the robustness of the flowchart shapes, there are implementation of comprehensive Cypress test cases in `newShapes.spec.ts` file. These tests cover various aspects such as:\n\n- **Shapes**: Testing new shapes like `bowTieRect`, `waveRectangle`, `trapezoidalPentagon`, etc.\n- **Looks**: Verifying shapes under different visual styles (`classic` and `handDrawn`).\n- **Directions**: Ensuring correct rendering in all flow directions of arrows :\n  - `TB` `(Top -> Bottom)`\n  - `BT` `(Bottom -> Top)`\n  - `LR` `(Left -> Right)`\n  - `RL` `(Right -> Left)`\n- **Labels**: Testing shapes with different labels, including:\n  - No labels\n  - Short labels\n  - Very long labels\n  - Markdown with `htmlLabels:true` and `htmlLabels:false`\n- **Styles**: Applying custom styles to shapes and verifying correct rendering.\n- **Class Definitions**: Using `classDef` to apply custom classes and testing their impact.\n\n### Running the Tests\n\nTo run the Cypress tests, follow these steps:\n\n1. Ensure you have all dependencies installed by running:\n   ```bash\n   pnpm install\n   ```\n2. Start the Cypress test runner:\n\n   ```bash\n   cypress open --env updateSnapshots=true\n\n   ```\n\n3. Select the test suite from the Cypress interface to run all the flowchart shape tests.\n","packages/mermaid/src/docs/community/contributing.md":"# Mermaid Contributing Guide\n\nYou decided to take part in the development? Welcome!\n\nWe are trying to make our guidelines for you as explicit and detailed as possible.\n\n## Initial Setup\n\nInitial setup consists of 3 main steps:\n\n```mermaid-nocode\nflowchart LR\n  source --> requirements --> setup\n\n  source[Get the Source Code]\n  requirements[Install the Requirements]\n  setup[Install Packages]\n```\n\n### Get the Source Code\n\nIn GitHub, you first [**fork a mermaid repository**](https://github.com/mermaid-js/mermaid/fork) when you are going to make changes and submit pull requests.\n\nThen you **clone** a copy to your local development machine (e.g. where you code) to make a copy with all the files to work with.\n\n```tip\n[Here is a GitHub document that gives an overview of the process](https://docs.github.com/en/get-started/quickstart/fork-a-repo).\n```\n\n```bash\ngit clone git@github.com/your-fork/mermaid\n```\n\nOnce you have cloned the repository onto your development machine, change into the `mermaid` project folder (the top level directory of the mermaid project repository)\n\n```bash\ncd mermaid\n```\n\n### Install Requirements\n\nWe support **development within Docker** environment along with **host setup**. You may choose it up to your preferences.\n\n**Host**\n\nThese are the tools we use for working with the code and documentation:\n\n- [Node.js](https://nodejs.org/en/).\n- [pnpm](https://pnpm.io/) package manager.\n\nThe following commands must be sufficient enough to start with:\n\n```bash\ncurl -fsSL https://get.pnpm.io/install.sh | sh -\npnpm env use --global 20\n```\n\nYou may also need to reload `.shrc` or `.bashrc` afterwards.\n\n**Docker**\n\n[Install Docker](https://docs.docker.com/engine/install/). And that is pretty much all you need.\n\nOptionally, to run GUI (Cypress) within Docker you will also need an X11 server installed.\nYou might already have it installed, so check this by running:\n\n```bash\necho $DISPLAY\n```\n\nIf the `$DISPLAY` variable is not empty, then an X11 server is running. Otherwise you may need to install one.\n\n### Install Packages\n\n**Host**\n\nInstall packages:\n\n```bash\npnpm install\n```\n\n**Docker**\n\nFor development using Docker there is a self-documented `run` bash script, which provides convenient aliases for `docker compose` commands.\n\nMake sure that `./run` script is executable:\n\n```bash\nchmod +x run\n```\n\n```tip\nTo get detailed help simply type `./run` or `./run help`.\n\nIt also has short _Development quick start guide_ embedded.\n```\n\nThen install packages:\n\n```bash\n./run pnpm install\n```\n\n### Verify Everything Works\n\nThis step is optional, but it helps to make sure that everything in development branch was OK before you started making any changes.\n\nYou can run the `test` script to verify that pnpm is working _and_ that the repository has been cloned correctly:\n\n**Host**\n\n```bash\npnpm test\n```\n\n**Docker**\n\n```bash\n./run pnpm test\n```\n\nThe `test` script and others are in the top-level `package.json` file.\n\nAll tests should run successfully without any errors or failures.\n\n```note\nYou might see _lint_ or _formatting_ warnings. Those are ok during this step.\n```\n\n## Workflow\n\nContributing process is very simple and straightforward:\n\n```mermaid-nocode\n  flowchart LR\n\n  branch --> changes --> submit\n  branch[Checkout a New Branch]\n  changes[Make Changes]\n  submit[Submit a PR]\n```\n\nMermaid uses a [Git Flow](https://guides.github.com/introduction/flow/)–inspired approach to branching.\n\nDevelopment is done in the `develop` branch.\n\n```mermaid-nocode\n---\nconfig:\n  gitGraph:\n    mainBranchName: develop\n---\ngitGraph LR:\n  commit\n  commit\n  branch \"docs/2910_update-guidelines\" order: 1\n  commit\n  commit\n  commit\n  checkout develop\n  merge \"docs/2910_update-guidelines\"\n  commit\n```\n\nTo prepare a new version for release the maintainers create a `release/vX.X.X` branch from `develop` for testing. Once the release happens we add a tag to the `release` branch and merge it with `master`. The live product and on-line documentation are what is in the `master` branch.\n\n## Checkout a New Branch\n\n```tip\nAll new work should be based on the `develop` branch.\n```\n\nMake sure you have the most up-to-date version of the `develop` branch.\n\nCheck out the `develop` branch, then `fetch` or `pull` to update it:\n\n```bash\ngit checkout develop\ngit fetch # or `git pull`\n```\n\nCreate a new branch for your work:\n\n```bash\ngit checkout -b docs/2910_update-contributing-guidelines\n```\n\nWe use the following naming convention for branches:\n\n```txt\n[feature | bug | chore | docs]/[issue number]_[short-description]\n```\n\nYou can always check current [configuration of labelling and branch prefixes](https://github.com/mermaid-js/mermaid/blob/develop/.github/pr-labeler.yml)\n\n- The first part is the **type** of change: a `feature`, `bug`, `chore`, `docs`\n- followed by a **slash** (`/`),which helps to group like types together in many git tools\n- followed by the **issue number**, e.g. `2910`\n- followed by an **underscore** (`_`)\n- followed by a **short description** with dashes (`-`) or underscores (`_`) instead of spaces\n\n```mermaid-nocode\nflowchart LR\n  feature --> slash\n  bug --> slash\n  chore --> slash\n  docs --> slash\n  slash --> 2945 --> underscore\n  slash --> 1123 --> underscore\n  underscore --> short_description_1\n  underscore --> short_description_2\n\n  underscore[\"_\"]\n  slash[\"/\"]\n\n  short_description_1[\"state-diagram-new-arrow-florbs\"]\n  short_description_2[\"fix_random_ugly_red_text\"]\n```\n\nIf your work is specific to a single diagram type, it is a good idea to put the diagram type at the start of the description. This will help us keep release notes organized by a diagram type.\n\n```note\nA new feature described in issue 2945 that adds a new arrow type called 'florbs' to state diagrams\n\n`feature/2945_state-diagram-new-arrow-florbs`\n```\n\n```tip\nA bug described in issue 1123 that causes random ugly red text in multiple diagram types\n\n`bug/1123_fix_random_ugly_red_text`\n```\n\n## Contributing Code\n\nCode is the heart of every software project. We strive to make it better. Who if not us?\n\n### Where is the Code Located?\n\nThe core of Mermaid is located under `packages/mermaid/src`.\n\n### Building Mermaid Locally\n\n**Host**\n\n```bash\npnpm run build\n```\n\n**Docker**\n\n```bash\n./run build\n```\n\nThis will build the Mermaid library and the documentation site.\n\n### Running Mermaid Locally\n\n**Host**\n\n```bash\npnpm run dev\n```\n\n**Docker**\n\n```bash\n./run dev\n```\n\nAfter starting the dev server open  in your browser.\n\nNow you are ready to make your changes!\n\nNote: By default, the Mermaid service will run on port 9000. To use a different port, change the environment variable `MERMAID_PORT` in the file `.env`. You should only need to do this if you are using port 9000 to run other projects.\n\n### Make Changes\n\nHave a look at . There is a list of demos that can be used to see and test your changes.\n\nIf you need a specific diagram, you can duplicate the `example.html` file in `/demos/dev` and add your own mermaid code to your copy.\n\nThat will be served at .\nAfter making code changes, the dev server will rebuild the mermaid library and automatically reload the page.\n\nEdit files in `packages/mermaid/src` as required.\n\n### Write Tests\n\nTests ensure that each function, module, or part of code does what it says it will do. This is critically important when other changes are made to ensure that existing code is not broken (no regression).\n\nJust as important, the tests act as _specifications:_ they specify what the code does (or should do).\nWhenever someone is new to a section of code, they should be able to read the tests to get a thorough understanding of what it does and why.\n\nIf you are fixing a bug, you should add tests to ensure that your code has actually fixed the bug, to specify/describe what the code is doing, and to ensure the bug doesn't happen again.\n(If there had been a test for the situation, the bug never would have happened in the first place.)\nYou may need to change existing tests if they were inaccurate.\n\nIf you are adding a feature, you will definitely need to add tests. Depending on the size of your feature, you may need to add integration tests.\n\n#### Unit Tests\n\nUnit tests are tests that test a single function or module. They are the easiest to write and the fastest to run.\n\nUnit tests are mandatory for all code except the layout tests. (The layouts are tested with integration tests.)\n\nWe use [Vitest](https://vitest.dev) to run unit tests.\n\n**Host**\n\nYou can use the following command to run the unit tests:\n\n```sh\npnpm test\n```\n\nWhen writing new tests, it's easier to have the tests automatically run as you make changes. You can do this by running the following command:\n\n```sh\npnpm test:watch\n```\n\n**Docker**\n\nWhen using Docker prepend your command with `./run`:\n\n```sh\n./run pnpm test\n```\n\n##### Testing the DOM\n\nOne can use `jsdomIt` to test any part of Mermaid that interacts with the DOM, as long as it is not related to the layout.\n\nThe function `jsdomIt` ([developed in utils.ts](../../tests/util.ts)) overrides `it` from `vitest`, and creates a pseudo-browser environment that works almost like the real deal for the duration of the test. It uses JSDOM to create a DOM, and adds objects `window` and `document` to `global` to mock the browser environment.\n\n> [!NOTE]\n> The layout cannot work in `jsdomIt` tests because JSDOM has no rendering engine, hence the pseudo-browser environment.\n\nExample :\n\n```typescript\nimport { ensureNodeFromSelector, jsdomIt } from './tests/util.js';\n\njsdomIt('should add element \"thing\" in the SVG', ({ svg }) => {\n  // Code in this block runs in a pseudo-browser environment\n  addThing(svg); // The svg item is the D3 selection of the SVG node\n  const svgNode = ensureNodeFromSelector('svg'); // Retrieve the DOM node using the DOM API\n  expect(svgNode.querySelector('thing')).not.toBeNull(); // Test the structure of the SVG\n});\n```\n\nThey can be used to test any method that interacts with the DOM, including for testing renderers. For renderers, additional integration testing is necessary to test the layout though.\n\n#### Integration / End-to-End (E2E) Tests\n\nThese test the rendering and visual appearance of the diagrams.\n\nThis ensures that the rendering of that feature in the E2E will be reviewed in the release process going forward. Less chance that it breaks!\n\nTo start working with the E2E tests:\n\n**Host**\n\n- Run `pnpm dev` to start the dev server\n- Start **Cypress** by running `pnpm cypress:open`\n\n**Docker**\n\n- Enable local connections for x11 server `xhost +local:`\n- Run `./run pnpm dev` to start the dev server\n- Start **Cypress** by running `./run pnpm cypress:open --project .`\n\nThe rendering tests are very straightforward to create. There is a function `imgSnapshotTest`, which takes a diagram in text form and the mermaid options, and it renders that diagram in Cypress.\n\nWhen running in CI it will take a snapshot of the rendered diagram and compare it with the snapshot from last build and flag it for review if it differs. When the changes in PR only apply to specific diagrams, only the rendering tests for those diagrams will be run in CI. If a change is not related to a specific diagram, the full test-suite will be run.\n\nThis is what a rendering test looks like:\n\n```js\nit('should render forks and joins', () => {\n  imgSnapshotTest(\n    `\n    stateDiagram\n    state fork_state <<fork>>\n      [*] --> fork_state\n      fork_state --> State2\n      fork_state --> State3\n\n      state join_state <<join>>\n      State2 --> join_state\n      State3 --> join_state\n      join_state --> State4\n      State4 --> [*]\n    `,\n    { logLevel: 0 }\n  );\n});\n```\n\n\n\n\n### Update Documentation\n\n```tip\nOur documentation is managed in `packages/mermaid/src/docs`. Details on how to edit is in the [documentation section](#contributing-documentation)\n```\n\nIf the users have no way to know that things have changed, then you haven't really _fixed_ anything for the users; you've just added to making Mermaid feel broken.\nLikewise, if users don't know that there is a new feature that you've implemented, it will forever remain unknown and unused.\n\nThe documentation has to be updated for users to know that things have been changed and added!\nIf you are adding a new feature, add `(v+)` in the title or description. It will be replaced automatically with the current version number when the release happens.\n\neg: `# Feature Name (v+)`\n\nWe know it can sometimes be hard to code _and_ write user documentation.\n\nCreate another issue specifically for the documentation.\nYou will need to help with the PR, but definitely ask for help if you feel stuck.\nWhen it feels hard to write stuff out, explaining it to someone and having that person ask you clarifying questions can often be 80% of the work!\n\nWhen in doubt, write up and submit what you can. It can be clarified and refined later. (With documentation, something is better than nothing!)\n\n## Contributing Documentation\n\nIf it is not in the documentation, it's like it never happened. Wouldn't that be sad? With all the effort that was put into the feature?\n\n### Where is the Documentation Located?\n\n```warning\nDO NOT CHANGE FILES IN `/docs`\n\nThe `docs` folder will be automatically generated when committing to `packages/mermaid/src/docs` and **should not** be edited manually.\n```\n\nDocumentation is located in the [`packages/mermaid/src/docs`](https://github.com/mermaid-js/mermaid/tree/develop/packages/mermaid/src/docs) folder. Just pick the right section and start typing.\n\nThe contents of [mermaid.js.org](https://mermaid.js.org/) are based on the docs from the `master` branch. Updates committed to the `master` branch are reflected in the [Mermaid Docs](https://mermaid.js.org/) once published.\n\n```mermaid\nflowchart LR\n  classDef default fill:#fff,color:black,stroke:black\n\n  source[\"Edit /packages/mermaid/src/docs\"] -- automatic processing--> published[\"View /docs which will be published on Official Website\"]\n```\n\n### Running the Documentation Website Locally\n\n**[The mermaid documentation site](https://mermaid.js.org/) is powered by [Vitepress](https://vitepress.vuejs.org/).**\n\nStart development server for the documentation site\n\n**Host**\n\n```bash\npnpm --filter mermaid run docs:dev\n```\n\nor\n\n```bash\ncd packages/mermaid\npnpm docs:dev\n```\n\n**Docker**\n\n```bash\n./run docs:dev\n```\n\nOpen [http://localhost:3333/](http://localhost:3333/) in your browser.\n\n### Formatting\n\nThe documentation is written in Markdown. To get acquainted with its syntax [see the GitHub Markdown help page](https://help.github.com/en/github/writing-on-github/basic-writing-and-formatting-syntax).\n\nYou can use `note`, `tip`, `warning` and `danger` in triple backticks to add a note, tip, warning or danger box.\n\n```danger\nDo not use vitepress specific markdown syntax `::: warning` as it will not be processed correctly.\n```\n\nHere are a few examples:\n\n````markdown\n```note\nThis is a note\n```\n\n```tip\nThis is a tip\n```\n\n```warning\nThis is a warning\n```\n\n```danger\nThis is a danger alert\n```\n````\n\n```note\nThis is a note\n```\n\n```tip\nThis is a tip\n```\n\n```warning\nThis is a warning\n```\n\n```danger\nThis is a danger alert\n```\n\n### Navigation\n\nIf you want to propose changes to how the documentation is _organized_, such as adding a new section or re-arranging or renaming a section, you must update the **sidebar navigation**, which is defined in [the vitepress config](../.vitepress/config.ts). The same goes for **topbar**.\n\n### Build Docs\n\nThe content of `/docs` folder is built with GitHub Actions.\n\n```warning\nSo as to allow automatic compilation of documentation pages you have to enable GitHub Actions on your fork first\n```\n\n## Submit your pull request\n\n````note\nDo not forget to push your changes\n\n```bash\ngit push -u origin docs/2910_update-guidelines\n```\n````\n\nWe make all changes via Pull Requests (PRs). Open a new one.\n\nRight now we are not following any strict rules about naming PRs. Give it a representative title and short description. There is also a [pull request template](https://github.com/mermaid-js/mermaid/blob/develop/.github/pull_request_template.md) which will help you with it.\n\nIn case in its description contains a [magic comment](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) your PR will be automatically attached to the issue:\n\n```markdown\nResolves #\n```\n\n## Congratulations\n\nYou have successfully submitted your improvements! What is next?\n\n- PRs will be reviewed by active maintainers, who will provide feedback and request changes as needed.\n- The maintainers will request a review from _knsv_, if necessary.\n- Once the PR is approved, the maintainers will merge the PR into the `develop` branch.\n- When a release is ready, the `release/x.x.x` branch will be created, extensively tested and knsv will be in charge of the release process.\n\nThanks for you help!\n\n\n","packages/mermaid/src/docs/community/e2e-tests.md":"# E2E Test Suite: Tiers, Folders, and CI\n\nThis is a contributor-facing manual for the `e2e/` test suite's tier structure — why it exists, how it's organized, which flags/labels control it, and how to work with it locally.\n\n## Why this exists\n\nBefore this restructuring, every PR ran the entire e2e suite — every diagram, every theme variant, every look/handdrawn combination — on every push. That's thorough, but it's expensive in two ways that scale badly as the suite grows:\n\n- **CI time.** A full run takes significantly longer than most PRs actually need. Most changes touch one diagram type; waiting on a full 8-shard run to validate a one-line fix is slow feedback for no real benefit.\n- **Argos quota.** Every full run captures and uploads a screenshot for every diagram fixture, whether or not that fixture has anything to do with the change under review. Visual-regression services bill (or rate-limit) by build/screenshot volume, so an oversized \"safety net\" run on every push burns through quota fast.\n\nThe fix is to split fixtures and specs into **tiers** — a small, fast, curated set that runs on every PR by default, and larger, slower sets reserved for less frequent, higher-confidence checks (nightly, and before a release-bound merge).\n\n**Measured impact** (from a real before/after comparison on this fork, on 2026-09-24 — pulled directly from GitHub Actions run history for PR #7; treat this as a dated example, not a live-updating stat):\n\n|                               | Full suite (pre-tiering) | `pr-check`-tier only |\n| ----------------------------- | ------------------------ | -------------------- |\n| Shards                        | 8                        | 2                    |\n| Per-shard time                | ~15–18 min               | ~6–8 min             |\n| Total wall-clock              | ~31 min                  | ~8 min               |\n| Total compute (shard-minutes) | ~128                     | ~14                  |\n\nRoughly a **4x reduction in wall-clock time** and **~90% less total CI compute** for the common case — a PR that only needs the `pr-check` tier to validate its change. That tracks with the underlying fixture split: as of 2026-09-24, `pr-check` covered about 15% of all `.mmd` fixtures (312 of 2,136 — `nightly-check` held 1,375, `visual-check` held 449). These counts will grow over time; the proportions are the durable part.\n\n## Directory layout\n\nTwo parallel trees hold the suite's content:\n\n```mermaid\nflowchart TD\n  subgraph diagrams[\"e2e/diagrams//\"]\n    direction LR\n    d_pr[\"pr-check/
*.mmd fixtures\"]\n    d_nightly[\"nightly-check/
*.mmd fixtures\"]\n    d_visual[\"visual-check/
*.mmd fixtures\"]\n  end\n  subgraph rendering[\"e2e/rendering//\"]\n    direction LR\n    r_pr[\"pr-check/
*.spec.ts\"]\n    r_nightly[\"nightly-check/
*.spec.ts\"]\n    r_visual[\"visual-check/
*.spec.ts\"]\n  end\n  runner[\"e2e/rendering/mmd-snapshots.spec.ts
(global fixture runner)\"]\n  diagrams -->|discovered & rendered by| runner\n```\n\n- **`e2e/diagrams///*.mmd`** — static Mermaid source fixtures. Each one is just a diagram (optionally with YAML frontmatter setting `config`/`title`/a `description`). They aren't run directly; a single global spec, `e2e/rendering/mmd-snapshots.spec.ts`, discovers every `.mmd` file under `e2e/diagrams/`, registers one Playwright test per fixture (grouped into `describe` blocks mirroring the folder path), and renders it. This is where the large majority of diagram-rendering coverage lives — no test-writing required, just add a `.mmd` file in the right tier folder.\n- **`e2e/rendering///*.spec.{js,ts}`** — hand-written Playwright specs, for anything a static fixture can't express: DOM/CSS assertions, `.click()` interactions, directive-vs-`initialize()` precedence checks, multi-diagram array tests, custom `mermaid.initialize()` config, and similar. If your test needs to assert on rendered output beyond \"did it render without erroring,\" it belongs here instead of as a fixture.\n- **`e2e/other//*.spec.{js,ts}`** — cross-cutting specs that aren't about any single diagram type (XSS/security tests, GHSA regression tests, `iife`/embed tests, page-interaction tests, external-diagram loading). Only `pr-check/` is populated today.\n- **`e2e/helpers/`** — shared test infrastructure: `util.ts` (the `imgSnapshotTest`/`renderGraph`/`verifyScreenshot` helpers every spec uses) and `mmd-snapshots.ts` (fixture discovery/metadata for the global runner).\n\nNot every `//` directory has content yet — some are intentionally empty, left in place as containers for tests that haven't been written. An empty tier folder isn't stray or safe to delete; it's scaffolding for the layout above, matching a diagram type or tier that's expected to gain coverage later.\n\n### The three tiers\n\n| Tier            | Intent                                                                                                                                                                     | Runs on                                                                                                                                         |\n| --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |\n| `pr-check`      | Small, curated, fast smoke set — one or two representative fixtures per feature, not an exhaustive sweep.                                                                  | Every PR (see below), plus a `develop` merge, plus every nightly run.                                                                           |\n| `nightly-check` | Bulk/comprehensive coverage — most of the fixture volume lives here.                                                                                                       | Once every 24h, plus a `master`-bound PR/merge (alongside `pr-check`).                                                                          |\n| `visual-check`  | Theme/look (`classic`/`neo`/`handDrawn`)/layout/direction combinatorial sweeps — the same diagram rendered across every variant. Pixel/appearance content, not parse-only. | Not part of any automated CI gate. Reviewed manually via Applitools as a release-process step (`e2e-applitools.yml`, `workflow_dispatch`-only). |\n\nA fixture or spec's tier is purely a function of which subfolder it lives in — there's no separate registry or config file to update.\n\nIf you're new to this structure, here's how to decide where a new test belongs:\n\n- **Adding a new diagram feature or syntax?** Add one small `pr-check` fixture covering the happy path — this is what every PR runs, so it catches an obvious regression immediately. If the feature has several meaningfully different shapes/variants/edge cases worth covering, add those as additional fixtures under `nightly-check` instead of piling them all into `pr-check` — `pr-check` is meant to stay small and fast, not become exhaustive.\n- **Fixing a rendering bug?** Add a `pr-check` fixture that reproduces the bug (the minimal diagram that triggered it), so this exact regression is caught on every future PR. Only drop it into `nightly-check` instead if it's a narrow, rarely-hit edge case where running it on every PR isn't worth the extra time.\n- **Backfilling broad coverage for something that already works** (e.g. every node-shape × edge-type combination, a sweep of config options)? That bulk volume belongs in `nightly-check` — it's comprehensive by design and only needs to run once a day, not on every push.\n- **Testing a purely visual/appearance difference** — how a diagram looks under a different theme, `handDrawn` look, layout direction, or similar, where the underlying structure/parsing is unaffected? That's `visual-check`. It's pixel/appearance content reviewed by a human via Applitools, not something an automated parse-only assertion can usefully judge.\n- **Does your test need to assert on something beyond \"did it render without erroring\"?** — a DOM/CSS assertion, a `.click()` interaction, directive-vs-`initialize()` precedence, a multi-diagram array, custom `mermaid.initialize()` config — that can't be expressed as a static `.mmd` fixture. Write a hand-written spec instead, under `e2e/rendering///*.spec.{js,ts}` if it's about one specific diagram type, or `e2e/other//*.spec.{js,ts}` if it's cross-cutting (security/XSS, embed/`iife`, page interactions, external-diagram loading, and similar). The same tier logic above still applies to these — a fast smoke-test spec goes in `pr-check`, a more exhaustive one in `nightly-check`.\n\nWhen in doubt, default to `pr-check` for anything a feature's author would want caught immediately, and move broader/slower coverage to `nightly-check`.\n\n## How CI decides what to run\n\n```mermaid\nflowchart TD\n  start{\"What triggered this run?\"}\n  start -->|\"PR → develop\"| pr_label{\"'run pr tests'
label set?\"}\n  start -->|\"PR → master\"| release_label{\"'run release test'
label set?\"}\n  start -->|\"Push to develop
(e.g. a PR merge)\"| push_develop[\"pr-check tier only\"]\n  start -->|\"Push to master\"| push_master[\"pr-check + nightly-check tiers\"]\n  start -->|\"Scheduled (daily) or
manual 'simulated nightly'\"| nightly_run[\"pr-check + nightly-check tiers\"]\n\n  pr_label -->|yes, or PR just opened| pr_scoped[\"pr-check tier only\"]\n  pr_label -->|no| blocked1[\"e2e skipped —
required check fails\"]\n\n  release_label -->|yes, or PR just opened| gated[\"pr-check + nightly-check tiers
(visual-check excluded — see Applitools)\"]\n  release_label -->|no| blocked2[\"e2e skipped —
required check fails\"]\n```\n\nBoth labels — `run pr tests` and `run release test` — default to **on**: a small automation job adds them to every freshly-opened PR (targeting `develop` and `master` respectively). Removing the label before a later push causes e2e to be skipped for that push, which is treated as a **failure** of the required status check (not a silent pass) — merging is still possible via a repo admin's branch-protection bypass, but it's not a default-open door.\n\nNote that `run release test` — despite its name — does **not** gate the `visual-check` tier. `visual-check` is theme/look/layout/direction combinatorial sweeps: pixel/appearance content that's better judged by a human during the manual Applitools pass (`e2e-applitools.yml`) than by an automated parse-only check here. The label name is a holdover from before this tier split; renaming it is tracked separately and out of scope for this doc.\n\nThis label-gating logic, and the nightly/scheduled workflow, are **upstream-only** — every branch of this logic is guarded by a check that it's running on `mermaid-js/mermaid`, not a fork. On a fork, e2e.yml falls back to its original full-suite/diff-based-scoping behavior, and the nightly workflow's own job is a no-op (there's no Argos project/credentials there to make screenshot capture worthwhile).\n\n## Flags and environment variables\n\n| Name                                        | Where                                           | Effect                                                                                                                                                                                                                  |\n| ------------------------------------------- | ----------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `MERMAID_E2E_FIXTURE_TIER`                  | env var, read by `mmd-snapshots.spec.ts`        | Comma-separated tier list (e.g. `pr-check`, or `pr-check,nightly-check`) that narrows which `.mmd` fixtures get registered. Unset = every tier.                                                                         |\n| `run pr tests`                              | GitHub PR label                                 | Gates whether a `develop`-bound PR's e2e run happens at all (scoped to `pr-check` tier when present). Defaults on for new PRs.                                                                                          |\n| `run release test`                          | GitHub PR label                                 | Same, for `master`-bound PRs (scoped to `pr-check`+`nightly-check` — `visual-check` excluded, see above). Defaults on for new PRs.                                                                                      |\n| `E2E_SCOPE_BY_DIAGRAM`                      | repo variable                                   | Kill-switch for the (separate, older) diagram-diff-based scoping used outside the tier-gating paths. Set to `'false'` to force the full suite unconditionally.                                                          |\n| `RUN_VISUAL_TEST`                           | computed CI env var                             | Controls whether screenshots get captured for Argos upload. Only ever true on the real upstream repo — never on this fork.                                                                                              |\n| `USE_APPLI`                                 | env var                                         | Switches screenshot verification to Applitools instead of the Argos/local-snapshot path. Common in personal dev shells — remember to override it (`USE_APPLI=`) when you specifically want the Argos code path locally. |\n| `SCREENSHOT_DIR`                            | env var                                         | Overrides where Argos-mode screenshots get written locally. Defaults to `e2e/screenshots`.                                                                                                                              |\n| `GROUP_ARGOS_IMAGES` / `group_argos_images` | computed CI env var / `workflow_dispatch` input | Whether screenshots get composited into per-folder \"sheets\" before Argos upload, versus uploaded individually.                                                                                                          |\n| `MERMAID_DEV_EXPLORER_ROOT`                 | env var, read by `.esbuild/server.ts`           | Which `.mmd` root the local Dev Explorer (`/dev` route) serves. Defaults to `e2e` (the whole tree — fixtures, platform diagrams, everything).                                                                           |\n| `MERMAID_PORT` / `MERMAID_DEV_PORT`         | env var                                         | Overrides the dev server port Playwright/the dev server use.                                                                                                                                                            |\n| `E2E_COVERAGE`                              | env var                                         | Switches the dev server to the coverage-instrumented build, and enables native V8 coverage collection during a Playwright run.                                                                                          |\n\n## Working with tiers locally\n\n**Run only the `pr-check` tier** (mirrors what a PR's CI actually runs):\n\n```bash\nMERMAID_E2E_FIXTURE_TIER=pr-check pnpm exec playwright test e2e/rendering/mmd-snapshots.spec.ts $(node scripts/e2e-tier-scope.mjs pr-check | tr ',' ' ')\n```\n\n**Run a \"simulated nightly\" (`pr-check`+`nightly-check`)** without waiting for the schedule:\n\n```bash\ngh workflow run \"Nightly E2E\" --repo mermaid-js/mermaid\n# or purely locally, no CI involved:\nMERMAID_E2E_FIXTURE_TIER=pr-check,nightly-check pnpm exec playwright test e2e/rendering/mmd-snapshots.spec.ts $(node scripts/e2e-tier-scope.mjs pr-check nightly-check | tr ',' ' ')\n```\n\n**See what a fixture would look like in Argos**, without needing real Argos credentials or touching any baseline: capture screenshots locally with `RUN_VISUAL_TEST=true` (remembering to clear `USE_APPLI` if it's set in your shell), then either browse `e2e/screenshots/` directly, or run `pnpm run screenshots:sheets` to composite them the same way CI does before upload.\n\n**Run a release test against Applitools**: start the local dev server first (`pnpm dev`, in its own terminal) — the suite is large enough that it's worth having it already warm rather than waiting on Playwright's own `webServer` auto-start/cold build on the first request. Neither of these is something you'd run as part of routine local development — they're only used when preparing a release:\n\n```bash\n# Core release check: pr-check + nightly-check tiers, against the \"release-baseline\" Applitools branch.\npnpm playwright:release-test\n\n# Extended release check: the visual-check tier (theme/look/layout combinatorial sweeps),\n# against its own separate \"release-baseline-extended\" Applitools branch.\npnpm playwright:release-test:extended\n```\n\nBoth scripts set `USE_APPLI=true`, so every screenshot is verified against Applitools instead of the Argos/local-snapshot path, and both pin `APPLITOOLS_BRANCH` to a fixed, long-lived branch name rather than letting the SDK derive one from the current git branch — so re-running either script, from whatever branch you're on, keeps comparing against the same accumulated baseline. The two scripts use separate baseline branches deliberately: the core and extended checks differ enough in scope and cadence that mixing both into one branch would make the Applitools review history harder to read.\n\n## Diagrams and screenshots\n\nThe Dev Explorer (`/dev` route) — browse `.mmd` fixtures under the configured `MERMAID_DEV_EXPLORER_ROOT` and preview them rendered:\n\n![Dev Explorer root view, showing the top-level e2e folder listing](img/dev-explorer.png)\n\n> 📸 **Placeholder — add screenshots here:**\n>\n> - The GitHub PR \"Checks\" tab, side by side: a `develop`-bound PR showing the scoped 2-shard `pr-check`-tier run, versus a `master`-bound PR showing the scoped 4-shard `pr-check`+`nightly-check` run (`visual-check` excluded).\n> - The \"Nightly E2E\" entry in the Actions tab, filtered, showing a recent scheduled run's result.\n\nThe flowcharts above (directory layout, CI decision flow) are Mermaid diagrams — edit them the same way you'd edit any diagram in this repo. If you add more diagrams to this doc, prefer Mermaid over static images where the content is structural/flow-based (it stays accurate as the suite evolves, and — fittingly for this repo — is easy for any contributor to update in a plain-text diff).\n","packages/mermaid/src/docs/community/intro.md":"# Getting Started\n\nSo you want to help? That's great!\n\n![Image of happy people jumping with excitement](https://media.giphy.com/media/BlVnrxJgTGsUw/giphy.gif)\n\nHere are a few things to get you started on the right path.\n\n## How can I help?\n\n```mermaid-nocode\nmindmap\n  root)Contributing(\n    Development\n      Solving issues\n      Adding new diagrams\n      Handling pull requests\n      Updating tooling\n    Testing\n      Verification of fixed issues\n      Regression testing in connection with releases\n      Testing pull requests\n    Management\n      Coordinating the work\n      Classification and monitoring of incoming issues\n```\n\n## Join the Development\n\n```tip\n**Check out our** [**detailed contribution guide**](./contributing.md).\n```\n\nWhere to start:\n\n- You could start getting some knowledge of the code base by working on [these \"good first issues\"](https://github.com/mermaid-js/mermaid/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3A%22Good+first+issue%21%22+).\n- You could jump right in and help us fix any of [these bugs](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Type%3A+Bug+%2F+Error%22++label%3A%22Contributor+needed%22+)!\n- You could help write and [improve the documentation](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Area%3A+Documentation%22).\n- You could work on a new feature! [These](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Area%3A+Development%22+label%3A%22Type%3A+Enhancement%22+label%3A%22Status%3A+Approved%22+) are some ideas!\n- You could confirm the bugs in [these issues](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Status%3A+Triage%22++label%3A%22Type%3A+Bug+%2F+Error%22).\n\n[You can join our Discord server if you want closer contact!](https://discord.gg/sKeNQX4Wtj)\n\n## A Question Or a Suggestion?\n\n```tip\n**Have a look at** [**how to open an issue**](./questions-and-suggestions.md).\n```\n\nIf you have faced a vulnerability [report it to us](./security.md).\n\n## Last Words\n\nDon't get daunted if it is hard in the beginning. We have a great community with only encouraging words. So, if you get stuck, ask for help and hints in the Slack forum. If you want to show off something good, show it off there.\n\n[You can join our Discord server if you want closer contact!](https://discord.gg/sKeNQX4Wtj)\n\n![Image of superhero wishing you good luck](https://media.giphy.com/media/l49JHz7kJvl6MCj3G/giphy.gif)\n","packages/mermaid/src/docs/community/layout-makers-guide.md":"# The Layout Maker's Guide 🗺️\n\nA layout algorithm decides where nodes sit and how edges get from one to the next. Shapes, themes, markers, and labels are already handled by the shared rendering code.\n\nWhich means you never touch the DOM. You are handed a graph whose nodes already know how big they are, and you hand back numbers: a center point for every node, a list of points for every edge. Drawing the shapes, painting the strokes, placing the arrowheads, fitting the viewBox — all of that is somebody else's code working from your numbers. You are solving a geometry problem, not a rendering one, which is exactly why a layout can be tested without a browser.\n\nThis guide covers layouts that live inside the Mermaid package, next to `dagre` and the others. The last section explains how to ship the same code as a standalone npm package instead.\n\nTwo layouts in the tree are worth reading alongside it. `dagre` is the default and the oldest. `swimlanes` is the newest, and it is the one that follows the conventions described here, so most of the examples point at it.\n\n## What a layout receives and what it must produce\n\nEvery layout is handed the same structure, `LayoutData`, regardless of which diagram type produced it:\n\n```ts\ninterface LayoutData {\n  nodes: Node[];\n  edges: Edge[];\n  config: MermaidConfig;\n  diagramId?: string;\n}\n```\n\n`runLayoutCore`, the stage that holds your algorithm, writes these fields and no others:\n\n| Field                       | On   | Meaning                                                                    |\n| --------------------------- | ---- | -------------------------------------------------------------------------- |\n| `node.x`, `node.y`          | Node | Center of the node, in layout space                                        |\n| `node.width`, `node.height` | Node | Arrive measured for leaf nodes — leave those alone; you set them on groups |\n| `edge.points`               | Edge | Polyline from source boundary to target boundary, at least 2 points        |\n| `edge.x`, `edge.y`          | Edge | Anchor for the edge label, when the edge has one                           |\n\nOne stage is allowed to do more. `prepareLayout` runs before measurement and may rebuild the graph — replace `data4Layout.nodes` and `data4Layout.edges`, add the synthetic nodes an edge label needs, drop what your algorithm handles another way. \"These fields and no others\" is a rule about `runLayoutCore`, where the graph is settled and only geometry moves.\n\n### Layout space\n\nPositions are centers. `node.x, node.y` is the middle of the node's box, so its left edge is `x - width / 2` and its top edge is `y - height / 2`. Layout libraries disagree about this — some report a node's top-left corner, some measure y upward from a bottom-left origin — so if you are wrapping one, convert its output in `runLayoutCore` rather than leaving the renderer to guess. Dagre and ELK both report centers, which is why the built-in layouts pass them straight through.\n\nBeyond that, layout space is a plain plane: x grows to the right, y grows downward. There is no fixed origin and no requirement that coordinates be positive. The renderer takes the bounding box of everything you produced and translates it into the SVG viewBox, so a layout centered on (0, 0) and a layout starting at (0, 0) render identically. Do not spend a pass normalizing coordinates; it is undone immediately.\n\n`Node` and `Edge` carry a good deal more than this, all of it defined in `rendering-util/types.ts`. Read the types there rather than working from what a debugger happens to show you: shape, label geometry, styling, and port information all travel on the same objects, and most of it belongs to the renderer rather than to you.\n\nTwo structural fields are your input, not your output. `node.isGroup` marks a subgraph container, and `node.parentId` names the group a node belongs to. Read them, never rewrite them.\n\nLeaf sizes arrive already measured, and they are not yours to compute. The renderer inserts every leaf node into the SVG, calls `getBBox()`, and writes `width` and `height` back before your algorithm runs, so a leaf whose size you recalculate or overwrite will have its label spill out of its shape at render time. Read them; treat them as fixed.\n\nGroups are the exception, and the only place you do set a size. A group's extent is a consequence of where you put its children, so nothing can measure it up front — every node with `isGroup` set needs a `width` and `height` from you, big enough to enclose its members and the title band. See [Groups](#groups).\n\nThat one measuring pass is the only step in the whole pipeline that touches the DOM, which is what makes everything after it testable in Node.\n\n## The five stages\n\nLayouts are built by calling `createCommonLayoutRenderer` from `rendering-util/layout-algorithms/common/index.ts`. It gives you five hooks, runs them in order, and handles painting:\n\n```ts\nexport const render = createCommonLayoutRenderer({\n  prepareLayout, // reshape LayoutData before measuring\n  measureLayout, // DOM: insert elements, read sizes (has a default)\n  runLayoutCore, // your algorithm, no DOM allowed\n  paintLayout, // escape hatch: take over painting entirely\n  afterPaint, // touch up after paths exist\n  paintOptions, // tweak the standard painter\n});\n```\n\nOnly `runLayoutCore` is required. The swimlanes layout is a complete example in twenty lines:\n\n```ts\nimport { createCommonLayoutRenderer } from '../common/index.js';\nimport { applySwimlaneLineJumps } from './adjustLayout.js';\nimport { prepareLayoutForSwimlanes } from './helpers.js';\nimport { createEdgeLabelNodes } from './edgeLabelNodes.js';\nimport { runSwimlaneLayoutCore } from './layoutCore.js';\n\nfunction prepareSwimlaneLayout(data4Layout: LayoutData): void {\n  prepareLayoutForSwimlanes(data4Layout);\n\n  const transformedData = createEdgeLabelNodes(data4Layout);\n  data4Layout.nodes = transformedData.nodes;\n  data4Layout.edges = transformedData.edges;\n}\n\nexport const render = createCommonLayoutRenderer({\n  prepareLayout: prepareSwimlaneLayout,\n  runLayoutCore: runSwimlaneLayoutCore,\n  afterPaint: applySwimlaneLineJumps,\n});\n```\n\n### Keep the core free of the DOM\n\n`runLayoutCore` must be a pure function of `LayoutData`. No `document`, no `getBBox`, no d3 selections.\n\nThe reason is testing. Node sizes get measured in a browser once and saved to a file. A test then loads those sizes, hands them to `runLayoutCore`, and gets back the same coordinates the browser would have produced, without opening a browser at all. That only holds while the core stays free of the DOM. The moment it reaches for `document`, it can only run inside a real page, and any test around it is exercising a different code path than the one your users hit.\n\nSo write the core as one exported function, and have both the browser and your tests call that same function.\n\n## A minimal layout\n\nThe examples from here on build a layout called `grid`. No such layout ships with Mermaid. It stands in for whatever you are writing, and the code below is what you would write to create it.\n\nPut the algorithm in `packages/mermaid/src/rendering-util/layout-algorithms//`. This one arranges leaf nodes in a grid and connects them with straight lines:\n\n```ts\n// layout-algorithms/grid/layoutCore.ts\nimport type { LayoutData } from '../../types.js';\n\nconst GAP = 60;\n\n/** DOM-free: positions come from measured sizes only. */\nexport function runGridLayoutCore(data4Layout: LayoutData): void {\n  const leaves = data4Layout.nodes.filter((node) => !node.isGroup);\n  const columns = Math.ceil(Math.sqrt(leaves.length));\n  const cell = Math.max(...leaves.map((n) => Math.max(n.width ?? 0, n.height ?? 0))) + GAP;\n\n  leaves.forEach((node, i) => {\n    node.x = (i % columns) * cell;\n    node.y = Math.floor(i / columns) * cell;\n  });\n\n  const byId = new Map(data4Layout.nodes.map((node) => [node.id, node]));\n  for (const edge of data4Layout.edges) {\n    const from = byId.get(edge.start ?? '');\n    const to = byId.get(edge.end ?? '');\n    if (!from || !to) {\n      continue;\n    }\n    edge.points = [\n      { x: from.x ?? 0, y: from.y ?? 0 },\n      { x: to.x ?? 0, y: to.y ?? 0 },\n    ];\n  }\n}\n```\n\n```ts\n// layout-algorithms/grid/index.ts\nimport { createCommonLayoutRenderer } from '../common/index.js';\nimport { runGridLayoutCore } from './layoutCore.js';\n\nexport const render = createCommonLayoutRenderer({ runLayoutCore: runGridLayoutCore });\n```\n\nThat renders. It is also wrong in most of the ways a layout can be wrong.\n\n## Registering the layout\n\nThe layouts that ship with Mermaid are listed in `registerDefaultLayoutLoaders()` in `packages/mermaid/src/rendering-util/render.ts`. Add one entry for yours:\n\n```ts\nregisterLayoutLoaders([\n  { name: 'dagre', loader: async () => await import('./layout-algorithms/dagre/index.js') },\n  { name: 'swimlane', loader: async () => await import('./layout-algorithms/swimlanes/index.js') },\n  // your new layout\n  { name: 'grid', loader: async () => await import('./layout-algorithms/grid/index.js') },\n]);\n```\n\nThe loader is lazy, so the code only downloads when a diagram asks for it. `cose-bilkent` is registered the same way but wrapped in a check on `includeLargeFeatures`, which is how a layout stays out of the tiny build. Users then select the layout by the name you registered:\n\n```text\n---\nconfig:\n  layout: grid\n---\nflowchart TB\n  A --> B\n```\n\n## Groups, labels, and edges\n\n### Groups\n\nA group node carries `isGroup: true`, and its members carry `parentId` pointing at it. Groups nest. Your algorithm owns the group's `x`, `y`, `width`, and `height`, and the frame must enclose every descendant with room for the title. Groups also have an optional `groupTitleRect` describing the header band. Edges routed through that band collide with the title text.\n\nThe standard painter draws a group as a cluster and everything else as a node. Override that with `paintOptions.isCluster` when your layout has its own idea of which nodes are containers.\n\n### Edge labels\n\nLabels need space reserved before positions are decided, otherwise they land on top of edges and nodes. The approach that works is to split each labelled edge into `start → label → end` around a temporary node, let the algorithm place that node like any other, then fold it back into an overlay label. Swimlanes does this in `createEdgeLabelNodes`, called from its `prepareLayout` hook so the dummy node is measured as real text along with everything else.\n\nInvent a third mechanism and your labels will not be checked by the validator, because the validator reads the label geometry this pattern produces.\n\n### Edge endpoints and markers\n\nEdge paths must start and end on the boundary of their nodes, not at the center and not floating in space. By default the painter recomputes the endpoint by intersecting the path with the node shape, which will quietly bend the last segment of a carefully routed edge. Layouts that route to exact ports should turn that off with `paintOptions.skipIntersect`.\n\nArrowheads occupy roughly the last ten pixels of the final segment. A bend inside that stretch puts a corner underneath the arrowhead, and the validator calls it: the constant is `EPS_FINAL_APPROACH`, and it is 10.\n\n### Self-loops and parallel edges\n\nAn edge with `start === end` has no direction to follow and needs its own route, usually a small rectangle off one side of the node. Parallel edges between the same pair need to be separated by hand, or they render as one line. Fixtures for both live in `e2e/platform/dev-diagrams/layout-tests/` as `self-loop.mmd`, `self-loop-2.mmd`, `self-loop-multi.mmd`, and `identical-edges.mmd`.\n\n## Validating the result\n\n`validateLayout` in `layout-algorithms/layout-utils/validateLayout.ts` is the shared judge of layout quality. It takes finished `LayoutData` and returns a verdict plus a score:\n\n```ts\nimport { validateLayout } from '../layout-utils/validateLayout.js';\n\nconst result = validateLayout(layout);\n// result.ok        → boolean, false when any hard constraint is broken\n// result.issues    → what broke, with node/edge ids and details\n// result.score     → 0 to 1000; exactly 0 whenever ok is false\n// result.breakdown → crossings, per-edge bend penalties, point histogram\n```\n\n### Hard constraints\n\n`ok` is false if any issue is present, and the score drops to zero. These are the failures worth knowing about before you write your router:\n\n| Issue                                                           | What it means                                         |\n| --------------------------------------------------------------- | ----------------------------------------------------- |\n| `node-overlap`                                                  | Two nodes occupy the same space                       |\n| `edge-intersects-node`, `edge-intersects-obstacle`              | A path crosses a node it does not connect to          |\n| `edge-intersects-group-title`                                   | A path runs through a subgraph's title band           |\n| `edge-endpoint-detached-from-node`, `edge-endpoint-inside-node` | An endpoint misses the boundary                       |\n| `edge-non-orthogonal`                                           | A segment is neither horizontal nor vertical          |\n| `edge-missing-points`                                           | Fewer than two points on an edge                      |\n| `edge-shared-subpath`, `edge-parallel-segment-too-close`        | Two edges overlap or run too close to tell apart      |\n| `edge-shared-attachment-point`, `edge-same-port-departure`      | Two edges leave a node from the same spot             |\n| `edge-bend-near-endpoint`, `edge-bend-overlaps-arrowhead`       | A corner sits under the arrowhead or against the node |\n| `edge-border-hugging`, `node-border-hugging`                    | Geometry runs along a border instead of clear of it   |\n| `edge-label-overlaps-node`, `edge-label-overlaps-foreign-edge`  | A label lands on top of something else                |\n| `edge-label-off-edge`                                           | A label sits away from the edge it belongs to         |\n\nThe tolerances are named constants at the top of `validateLayout.ts`, and two of them explain most first-time surprises: `EPS_FINAL_APPROACH` is 10, the stretch near an endpoint where a bend is not allowed, and `EPS_SHARED_ATTACH` is 3, how close two edges may attach to the same node before they count as sharing a point. The tests assert relative ordering rather than exact magnitudes, so treat the numbers as current rather than fixed.\n\nSome checks assume orthogonal routing. A layout with curved or diagonal edges will trip `edge-non-orthogonal` on every edge, so either route orthogonally or work out which subset of the validator applies to you before treating its score as a target.\n\n### The score\n\nWhen `ok` is true the score starts at 1000 and comes down. Bends are counted per edge from the polyline point count, and crossings are counted once globally:\n\n| Polyline points | Bends | Penalty             |\n| --------------- | ----- | ------------------- |\n| 2               | 0     | 0                   |\n| 3               | 1     | 0                   |\n| 4               | 2     | 5                   |\n| 5               | 3     | 12                  |\n| 6               | 4     | 30                  |\n| 7 or more       | 5+    | 30 × 2^(points − 6) |\n\nEach crossing costs 3. The curve is deliberately steep at the top end: one seven-bend edge costs more than twenty crossings, because a path nobody can follow is worse than a tidy diagram with intersections.\n\nThe score does not scale with diagram size. A small graph reaches 1000; a large one rarely will, so compare a fixture against its own history rather than against another fixture.\n\n`result.breakdown.edges` is sorted worst-first, which makes it the fastest way to find what is dragging a layout down.\n\n### One thing that looks useful and is not\n\n`layout-utils` also holds `scoreLayout`, which computes softer metrics: aspect ratio, average bends per edge, rank faithfulness, neighborhood preservation, straight-edge ratio. Sitting next to `validateLayout`, it looks like the quality half of a matched pair.\n\nIt is not wired into anything. Nothing in the layout pipeline calls it, no fixture spec calls it, and its only caller is its own unit test. Its `symmetryScore` is an unfinished placeholder that always returns `NaN`. Treat `validateLayout` as the only judge, and leave `scoreLayout` alone unless you are deliberately picking up that unfinished work.\n\nA third level is planned and not built. `compareLayoutSnapshot()` would diff a layout's structure against a stored baseline to catch regressions that stay inside the validator's tolerances. There is no such function today, so nothing depends on it.\n\n## Testing with DDLT\n\nDOM-Decoupled Layout Testing runs your algorithm in Node against sizes captured once from a real browser. Tests come back in seconds and give the same answer every time, and because the browser and the tests call the same core function, a fix in one is a fix in the other.\n\n### Tests must run the browser's code path\n\nThe model is `parse → measure → run layout → paint`, and the third step has to be a single function. Tests swap out the measuring; the browser does it for real. What runs in between must be identical.\n\nThat sounds obvious, and it is where this gets broken most often. A test-only layout entry point sitting alongside the browser's is a bug even when the two look like they do the same thing. This has bitten this repo more than once, and the shape is always the same. The browser entry wrapped the edge pipeline in a degeneracy check and a direction-violation check, with a fallback and a reroute branch hanging off them. The test backend called the pipeline directly and skipped all of that. Fixtures came back valid, the browser took the fallback, and the fallback drew a polyline straight through the interior of a node. The validator would have caught it. The test harness never saw it.\n\nSo when you wire up a test backend, find the function the browser actually calls and trace it end to end. If it needs the DOM, lift its DOM-free body into a helper and call that helper from both sides rather than reimplementing the sequence. Never point the test at a primitive that the browser wraps in checks, fallbacks, mirror branches, or second passes: the test has to include all of it.\n\nThere is a cheap way to prove the seam is real. Change the browser orchestration, add a fallback or switch a default, and the test result for the same fixture should move. If it does not, the test is running around your change. Fix the seam rather than relaxing the test.\n\nWhen a fixture passes in Node but looks broken on screen, run `validateLayout` on both, on the same fixture, and compare the issues. Different issues mean different pipelines. Put the two call chains side by side, look for pre-passes, the main call, and post-passes, and the first place they diverge is the seam.\n\n### Fixtures\n\nA fixture is a pair of files under `e2e/platform/dev-diagrams/layout-tests/`:\n\n```text\nlayout-tests/\n  simple-graph.mmd          ← real Mermaid source, parsed by the real parser\n  simple-graph.sizes.json   ← node dimensions captured from a browser render\n  ddlt-manifest.json        ← per-fixture overrides\n```\n\nThe `.mmd` file goes through the actual parser, so fixtures exercise the same `LayoutData` a user's diagram produces. The `.sizes.json` file holds one entry per leaf node and one per edge label, plus freshness metadata:\n\n```json\n{\n  \"metadata\": {\n    \"captureVersion\": 1,\n    \"sourceSha256\": \"…\",\n    \"capturedAt\": \"2026-02-09T10:00:00Z\",\n    \"capturedFrom\": \"theme=default&look=classic\"\n  },\n  \"nodes\": [{ \"id\": \"A\", \"width\": 62, \"height\": 39 }]\n}\n```\n\n`sourceSha256` is a hash of the `.mmd` file. Edit the diagram without recapturing and the test fails with a stale-fixture error instead of silently laying out with wrong sizes.\n\n`ddlt-manifest.json` gives a fixture a profile, which decides the backend it runs through, and can mark it `allowLevel1Failure` when a known failure is tracked in its own dedicated spec.\n\n### Capturing sizes\n\nThere is a button for this. Start the dev server with `pnpm dev`, open the explorer at `/dev/`, and pick your diagram out of the file tree, which is rooted at the same `dev-diagrams` folder the fixtures live in. Switch to the Code tab and click **Save sizes**, sitting next to Save.\n\nIt does the whole job. Unsaved edits to the diagram are written first, the diagram re-renders with size capture switched on, and the measurements go to `.sizes.json` beside the `.mmd`. The hash and the capture version are filled in for you, so the fixture passes the freshness check the moment it lands.\n\nThe button is only enabled for layouts that can produce capture data, and it explains itself through a tooltip when it is greyed out.\n\nIf you need to capture from somewhere other than the explorer, the same machinery is reachable from the console:\n\n```js\nwindow.mermaidCaptureSizes = true;\n// render the diagram, then:\ncopy(JSON.stringify(window.mermaidLastCapturedSizes.sizes, null, 2));\n```\n\nWritten by hand this way, the metadata block is yours to fill in. The capture module is dynamically imported only when that flag is set, so it never reaches a production bundle either way.\n\nRecapture when the diagram source changes or when a shape's real dimensions change. Do not recapture to make a failing test pass. The fixture is the before-picture, and rewriting it erases the regression you were trying to catch.\n\n### Parse the diagram, do not hand-build the graph\n\nIt is tempting to skip the parser and write the `LayoutData` for a test by hand. Resist it. Hand-built graphs drift from what the parser emits, usually in the identifiers, and once the ids differ the test is scoring a graph the browser never lays out.\n\nThe ids follow rules worth knowing, because fixture entries are matched against them:\n\n| Entity            | Id                                                                 |\n| ----------------- | ------------------------------------------------------------------ |\n| Content node      | The unquoted name from the diagram source, such as `A` or `E`      |\n| Unquoted subgraph | The subgraph text, kept as written                                 |\n| Quoted subgraph   | `subGraph`, numbered by a counter that ticks on every subgraph  |\n| Edge              | `L___`, the counter separating parallel edges |\n| Edge label node   | `edge-label---`                                |\n\nThe harness does the parsing for you. `parseMmdFileToLayoutData` strips frontmatter and directives, runs the real detector and parser, and stamps the direction the way the flowchart renderer does. `parseApplySizesAndLayout` goes further and applies the captured sizes and runs a backend. Reach for those before writing your own.\n\nIf you do drive the parser yourself, two calls come first: `addDiagrams()` to register the diagram types, and `preprocessDiagram()` to handle frontmatter before `Diagram.fromText()` sees it. Skipping either produces failures that look like parser bugs and are not.\n\nWhichever route you take, fail loudly when a fixture entry has no matching parser-produced node. A silent miss leaves a node at its default size, and the layout you then measure is not the layout anyone will see.\n\n### Writing a spec\n\nLoad the fixture, run your backend, assert on the result:\n\n```ts\nimport { describe, it, expect, beforeAll } from 'vitest';\nimport { loadDdltFixture } from '../ddlt/index.js';\nimport { validateLayout } from '../layout-utils/validateLayout.js';\n\ndescribe('swimlanes, 1-simple', () => {\n  let layout: LayoutData;\n  beforeAll(async () => {\n    layout = await loadDdltFixture('swimlanes/1-simple', { backendId: 'swimlanes' });\n  });\n\n  it('produces a valid layout', () => {\n    const result = validateLayout(layout);\n    expect(result.issues.map((i) => i.type)).toEqual([]);\n    expect(result.score).toBeGreaterThan(900);\n  });\n});\n```\n\nPass `backendId` explicitly. The default is a backend that is not present on `develop`, so a call without it throws rather than silently doing something reasonable. Your own layout needs an entry in `ddlt/backends.ts` before a fixture can run through it.\n\n`ddlt/index.ts` also exports `baselineDdltSpec(name)`, a one-liner that asserts the universal invariants: finite coordinates, at least two points per edge, no segment through an unrelated node, endpoints on boundaries. It hardcodes the same absent default backend and has no callers, so read it for the invariants it checks rather than calling it as it stands.\n\nThree shapes of test cover most needs. A tiny inline geometry test, where you build a handful of nodes by hand and check one routing rule, is right for a unit of the algorithm. A fixture-backed test on realistic sizes is right for a regression you can point at. A full source-to-layout run through the parser is right for anything a user reported. Match the surrounding folder: `swimlanes/query-process.ddlt.spec.ts` is the fullest worked example in the tree, and `layout-utils/validateLayout.spec.ts` and `ddlt/aggregateValidate.spec.ts` show the smaller shapes.\n\n### The sweep\n\n`ddlt/layout-fixtures.ddlt.spec.ts` discovers fixture pairs, runs them, and asserts validity across the board. It also emits an aggregate report, the number that tells you whether a change helped overall rather than on the one diagram you were staring at:\n\n```bash\n# The sweep, with the aggregate report\npnpm exec vitest run \\\n  packages/mermaid/src/rendering-util/layout-algorithms/ddlt/layout-fixtures.ddlt.spec.ts\n\n# Just the aggregate line\npnpm exec vitest run \\\n  packages/mermaid/src/rendering-util/layout-algorithms/ddlt/layout-fixtures.ddlt.spec.ts \\\n  2>&1 | grep 'DDLT-AGG'\n\n# One fixture while iterating\npnpm exec vitest run -t \"1-simple\" \\\n  packages/mermaid/src/rendering-util/layout-algorithms/ddlt/\n```\n\nThe report gives `total`, `avg`, `min`, and `invalid`, then one row per fixture with its score and issue types. Read it as a work queue: the lowest row is where the next improvement is. `ORTHO_TEST_DEBUG=1` in front of the command turns the layout logger from `fatal` up to `debug`, which helps when a row fails for reasons the report does not explain.\n\nThe sweep as written filters to the `swimlanes` profile and holds that profile's total against a floor. Adding a layout means adding its profile to the manifest and its own aggregate assertion, not assuming the existing one will pick your fixtures up.\n\n## The cases that break layouts\n\nA layout that handles a chain of boxes tells you almost nothing. The cases below are where engines actually fail, roughly in the order yours will fail them. Every one has a diagram in `layout-tests` already, so there is nothing to write before you can find out.\n\nMost of them are source only. The folder holds around 45 diagrams and about 15 have captured sizes, and the sweep discovers fixtures by looking for `.sizes.json` files and pairing each with its sibling `.mmd`. A diagram with no sizes file is not being tested by anything, however tricky it looks. Check before assuming a case is covered, and if the sizes are missing, open the diagram in the explorer and press Save sizes. That one click is the difference between a diagram sitting in a folder and a case the sweep will defend.\n\n### Self-loops\n\nAn edge whose source and target are the same node has no direction to travel in, and code that computes a route from two distinct positions tends to produce a zero-length path, a division by zero, or a dot. The route has to be manufactured: a small loop off one side, clear of the node and of anything the node's other edges are doing.\n\n`self-loop.mmd` is the single-node case, and the only one of the three with sizes captured. `self-loop-2.mmd` and `self-loop-multi.mmd` are harsher, putting a self-loop on all four nodes of a cycle, so every loop competes for space with real edges already using those sides.\n\n### Subgraphs\n\nThis is the long tail, and it is where most of the work is. A subgraph is a node that contains other nodes, so every edge endpoint now has two possible meanings and every frame is an obstacle that also has to move as its contents move.\n\n| Case                                  | Fixture                                                   |\n| ------------------------------------- | --------------------------------------------------------- |\n| A subgraph standing on its own        | `decoupled-subgraph.mmd`                                  |\n| Edge into a subgraph                  | `edge-to-subgraph.mmd`                                    |\n| Edge into a node inside a subgraph    | `edge-to-node-in-subgraph.mmd`                            |\n| Edge out of a subgraph                | `edge-from-subgraph.mmd`                                  |\n| Edge from inside out to a plain node  | `subgraph-variation.mmd`, `subgraph-variation-2.mmd`      |\n| Between two sibling subgraphs         | `nested-sg-outgoing-2.mmd`, `nested-incoming.mmd`         |\n| Inside one subgraph to inside another | `nested-sg-outgoing-2.mmd`, `nested-subgraphs-2.mmd`      |\n| Nested subgraphs                      | `nested-subgraphs.mmd`, `nested-subgraphs-3.mmd`          |\n| Edges crossing several nesting levels | `nested-sb-edges-in-out.mmd`, `nested-outgoing-edges.mmd` |\n| Subgraph titles competing for space   | `subgraph-labels.mmd` and its two variants                |\n\nWork down that list in order. Each row assumes the ones above it. Only the first two rows have captured sizes today, so everything below them is a diagram you can open in the browser rather than a test that will tell you when you break it.\n\nTwo failures recur. An edge that ends on a subgraph should stop at the frame rather than diving through to a member, and an edge that ends on a member has to cross the frame without clipping the title band. The other is sizing: a frame has to enclose everything inside it including the labels, and it has to keep doing so after a later pass nudges a member.\n\n### Parallel edges\n\nTwo edges between the same pair of nodes are one edge as far as most routing code is concerned, because both get the same endpoints and the same optimal path, so they land exactly on top of each other and the diagram silently loses information. They have to be separated deliberately.\n\n`identical-edges.mmd` is the minimal case. `multiple-edges.mmd` adds a reverse edge to the bundle, so the fix cannot just fan edges out by index and ignore direction. `identical-edges-in-subgraph.mmd` puts a bundle in each direction inside a frame, where the room to fan out is bounded.\n\n### Busy nodes\n\nA node with more than four edges cannot give each one its own side. Ports have to share sides, share sides in an order that does not cross, and stay far enough apart to be told apart. Engines that assign one edge per side degrade sharply here, usually into a knot right against the node.\n\n`edge-types.mmd` piles several edges onto a single node with a different arrow type on each. `Company.mmd` and `Company-simp.mmd` are the realistic version of the same problem, and both have sizes captured.\n\n### Combinations, and both directions\n\nThese interact, and the combinations are worse than the parts. A self-loop on a busy node inside a nested subgraph exercises all four at once, which is why the larger fixtures are worth keeping even though a failure in one is harder to diagnose. `deploy-pipeline.mmd`, `life-choices.mmd`, and `project-sox2.mmd` are the closest thing here to diagrams a user would actually write.\n\nRun the ones that matter in `TB` and `LR` both. Layout code tends to grow an implicit assumption about which way the graph flows, and the second direction is where that assumption surfaces.\n\n## Before you invent something\n\nGraph drawing has a long research record, and most of what a layout engine needs has been studied for decades. Orthogonal routing, compaction, port and side constraints, layered pipelines, crossing minimisation: none of these are new problems, and reading up on one is usually faster than deriving a heuristic and discovering its failure modes one fixture at a time.\n\nThe vocabulary gap is worth knowing about, because it makes searching harder than it needs to be. What this codebase calls a jog, the literature calls a bend. A port window is a pin or a side constraint. A rail is a track or a channel. A group is a compound vertex.\n\nWhen you knowingly diverge from what the established approach recommends, write down why in the pull request, along with how you checked that the divergence works.\n\n## Watching it in the browser while the tests run\n\nThe sweep tells you a score dropped. It does not tell you the diagram now looks like a plate of spaghetti. Keep a browser open next to the test run.\n\n```bash\npnpm dev\n```\n\nDo not assume the address. The port is derived from the path of the checkout, so every worktree and every clone gets its own and you can run several dev servers side by side without them fighting over 9000. The server prints its URL as it starts, before the build output scrolls past. `MERMAID_DEV_PORT` pins it if you want a fixed one.\n\nOpen `/dev/` and you get the explorer: the fixture tree on one side, the diagram on the other, a code tab for editing the source, and a layout picker for comparing your algorithm against the others on the same input. It reloads when you change the source, so an edit to your algorithm redraws the diagram without you touching the browser.\n\nFor a diagram that is not in the fixture tree, copy the standalone page template instead:\n\n```bash\ncp demos/dev/example.html demos/dev/grid.html\n```\n\nThat lands at `/dev/grid.html` on the same server. Put the diagram in the page and name your layout in the frontmatter:\n\n```html\n
\n---\nconfig:\n  layout: grid\n---\nflowchart TB\n  A --> B\n  B --> C\n
\n```\n\nA workflow that holds up over a long session:\n\n1. Run the sweep in one terminal, filtered to the fixture you are working on.\n2. Keep that same fixture open in the browser.\n3. Make one change and watch both. The score says whether it helped, and the picture says whether the score was measuring the right thing.\n4. Before committing, run the full sweep and confirm the aggregate did not drop.\n\nThe two disagree more often than you would expect, and the disagreement is informative. A score that improves while the diagram gets worse means the validator is blind to something, and that gap is worth writing down.\n\nUse the browser to check what the tests cannot see: text that overflows its shape, arrowheads pointing the wrong way, subgraph frames cutting through labels.\n\n## Performance on large diagrams\n\nA layout that is pleasant on ten nodes can be unusable on a thousand, and the difference does not show up in the fixture sweep — DDLT fixtures are small on purpose, so they say nothing about how your algorithm scales. There is a separate corpus for that.\n\n### The corpus\n\n`e2e/platform/dev-diagrams/performance/flowcharts/` holds fifteen real flowcharts, anonymized and grouped by size:\n\n```text\nperformance/flowcharts/\n  medium1.mmd … medium5.mmd   ← ~45-50 KB of source each\n  large1.mmd  … large5.mmd    ← ~70-75 KB\n  huge1.mmd   … huge5.mmd     ← 120-240 KB\n  baseline.json               ← a captured profiler run, for comparison\n```\n\nThe buckets are by source size, and node count does not follow it. `huge1.mmd` is around 2400 nodes with barely fifty edges; `huge2.mmd` is a few hundred nodes with over a thousand edges; `huge3.mmd` is a hundred nodes buried in `classDef` declarations. That spread is deliberate. These are real diagrams people drew, so the shapes that break layout algorithms in practice — one node with sixty edges, deeply nested subgraphs, a long thin chain, a wide flat fan — appear in the proportions they actually occur rather than the ones a generator would produce. Several carry frontmatter config, `handDrawn` look, and HTML labels, so they exercise the measuring pass as well as the layout.\n\n### Running the profiler\n\nProfiling lives in the same dev explorer as everything else in the previous section.\n\n1. `pnpm dev`, then open `/dev/` at the URL the server printed.\n2. Select `performance/flowcharts` in the file tree.\n3. In the Profiler panel, tick the layouts to compare, set the scope to **Folder**, choose the number of iterations, and press **Run profile**.\n\nEach layout is warmed up once and discarded, then every diagram is rendered `iterations` times per layout, with the fastest and slowest run of each series dropped before averaging. The score is total milliseconds across the set, lower is better. **Copy JSON** puts the whole run on the clipboard in the same shape as `baseline.json`.\n\nOne rough edge: the profiler's layout checkboxes come from a hardcoded list in `.esbuild/dev-explorer/diagram-viewer.ts` (`ALL_LAYOUTS`). A new layout will not appear there until you add it, even after it is registered with Mermaid.\n\n### Reading the table\n\nThe row you care about is rarely the total. Rendering is broken into phases, and only one of them is yours:\n\n| Phase       | What it covers                                              |\n| ----------- | ----------------------------------------------------------- |\n| `parse`     | Diagram text to db                                          |\n| `prepare`   | Building `LayoutData`, including your `prepareLayout`       |\n| `measure`   | DOM insertion and `getBBox` / `getBoundingClientRect`       |\n| `layout`    | The layout call, split into `↳ lib (external)` and `↳ ours` |\n| `paint`     | Drawing nodes and edges from your coordinates               |\n| `serialize` | SVG to string                                               |\n\n`↳ ours (wrapper)` is your code; `↳ lib (external)` is the third-party library underneath, if you wrap one. A layout that is slow because ELK is slow and a layout that is slow because of your own pass are the same number in the `layout` row and completely different problems one row down.\n\n`huge3.mmd` makes the point: 1410 ms in `parse` against 1.5 ms in `layout`. Its total is dominated by something you cannot fix from a layout algorithm, and reading totals would send you optimizing the wrong file.\n\nWatch `measure` too. It is not your phase, but it is downstream of `prepareLayout` — every synthetic node you add for an edge label is another element inserted into the DOM and measured, so a `prepareLayout` that is generous with helper nodes shows up as someone else's regression.\n\n### Comparing against the baseline\n\n`baseline.json` is a captured run over the same folder — dagre and elk, ten iterations, `theme=redux`, `look=neo`, with the capture date in the file.\n\nTreat the absolute numbers as a record of one machine on one day, not a threshold. They will not reproduce on your hardware, and a CI runner would not reproduce them either. What does carry over is the shape: the relative cost of the phases, which diagrams are layout-dominated and which are parse-dominated, and the ratio between the layouts. Profile your layout in the same run as dagre and elk and compare within that run.\n\n### What actually goes wrong\n\nIn practice the regressions are algorithmic, not micro-optimizations:\n\n- A pass over every pair of nodes. Fine at 50 nodes, 1.4 million comparisons at 1200.\n- `edges.filter((e) => e.start === node.id)` inside a loop over nodes — O(V·E) hidden behind two readable lines. Build the adjacency map once, before the loop.\n- Rebuilding a lookup inside an iterative refinement step, so an O(V) cost becomes O(V) per iteration.\n- Recursing into subgraphs without memoizing, and revisiting the same subtree once per ancestor.\n\nProfile before you optimize. Run the corpus, find the diagram where your `↳ ours` row is worst, and read that one — the corpus is small enough that the answer is usually one diagram and one loop.\n\n## Shipping as a separate package\n\nAn external layout uses the same `render` signature. Instead of editing the built-in registry, export a loader array and let the consumer register it:\n\n```ts\nimport type { LayoutLoaderDefinition } from 'mermaid';\n\nconst loader = async () => await import('./render.js');\n\nconst layouts: LayoutLoaderDefinition[] = [{ name: 'grid', loader, algorithm: 'grid.compact' }];\n\nexport default layouts;\n```\n\n```js\nimport mermaid from 'mermaid';\nimport layouts from 'my-mermaid-layout';\n\nmermaid.registerLayoutLoaders(layouts);\n```\n\nThe `algorithm` field is passed back to your renderer through `options`, which lets one package register several named variants that share an implementation.\n\nPackage it separately when the layout pulls in a large dependency. Everything else belongs in the main package, where it gets covered by the fixture sweep.\n\n## Checklist\n\n- [ ] `runLayoutCore` is one exported function with no DOM access\n- [ ] The browser and the tests call that same function\n- [ ] Group frames enclose their members and leave the title band clear\n- [ ] Edge labels reserve space before positions are decided\n- [ ] Edge endpoints land on node boundaries\n- [ ] Self-loops and parallel edges have routes\n- [ ] `validateLayout` returns `ok: true` on your fixtures\n- [ ] Fixtures exist, with captured sizes, for the cases the algorithm was written to handle\n- [ ] Your backend is registered in `ddlt/backends.ts` and your profile in `ddlt-manifest.json`\n- [ ] The sweep passes and the aggregate score has not dropped\n- [ ] `.mmd` fixtures under `e2e/diagrams/` cover the layout visually, since layout changes are rendering changes\n- [ ] The layout has been profiled against `performance/flowcharts/`, and the `↳ ours` row is understood\n","packages/mermaid/src/docs/community/new-diagram-jison.md":"# Adding a New Diagram/Chart (Deprecated) 📊\n\n```warning\nJISON grammars are deprecated in mermaid. Please use Langium instead. See [New Diagram](./new-diagram.md) for more information.\n\n**New diagrams with JISON grammars will not be accepted.**\n```\n\n### Step 1: Grammar & Parsing\n\n#### Grammar\n\nThis would be to define a JISON grammar for the new diagram type. That should start with a way to identify that the text in the mermaid tag is a diagram of that type. Create a new folder under diagrams for your new diagram type and a parser folder in it. This leads us to step 2.\n\nFor instance:\n\n- the flowchart starts with the keyword _graph_\n- the sequence diagram starts with the keyword _sequenceDiagram_\n\n#### Store data found during parsing\n\nThere are some jison specific sub steps here where the parser stores the data encountered when parsing the diagram, this data is later used by the renderer. You can during the parsing call an object provided to the parser by the user of the parser. This object can be called during parsing for storing data.\n\n```jison\nstatement\n\t: 'participant' actor  { $$='actor'; }\n\t| signal               { $$='signal'; }\n\t| note_statement       { $$='note';  }\n\t| 'title' message      { yy.setTitle($2);  }\n\t;\n```\n\nIn the extract of the grammar above, it is defined that a call to the setTitle method in the data object will be done when parsing and the title keyword is encountered.\n\n```note\nMake sure that the `parseError` function for the parser is defined and calling `mermaid.parseError`. This way a common way of detecting parse errors is provided for the end-user.\n```\n\nFor more info look at the example diagram type:\n\nThe `yy` object has the following function:\n\n```javascript\nexports.parseError = function (err, hash) {\n  mermaid.parseError(err, hash);\n};\n```\n\nwhen parsing the `yy` object is initialized as per below:\n\n```javascript\nconst parser = exampleParser.parser;\nparser.yy = db;\n```\n\n### Step 2: Rendering\n\nWrite a renderer that given the data found during parsing renders the diagram. To look at an example look at sequenceRenderer.js rather than the flowchart renderer as this is a more generic example.\n\nPlace the renderer in the diagram folder.\n\n### Step 3: Detection of the new diagram type\n\nThe second thing to do is to add the capability to detect the new diagram to type to the detectType in `diagram-api/detectType.ts`. The detection should return a key for the new diagram type.\n[This key will be used to as the aria roledescription](#aria-roledescription), so it should be a word that clearly describes the diagram type.\nFor example, if your new diagram uses a UML deployment diagram, a good key would be \"UMLDeploymentDiagram\" because assistive technologies such as a screen reader\nwould voice that as \"U-M-L Deployment diagram.\" Another good key would be \"deploymentDiagram\" because that would be voiced as \"Deployment Diagram.\" A bad key would be \"deployment\" because that would not sufficiently describe the diagram.\n\nNote that the diagram type key does not have to be the same as the diagram keyword chosen for the [grammar](#grammar), but it is helpful if they are the same.\n\n### Step 4: The final piece - triggering the rendering\n\nAt this point when mermaid is trying to render the diagram, it will detect it as being of the new type but there will be no match when trying to render the diagram. To fix this add a new case in the switch statement in main.js:init this should match the diagram type returned from step #2. The code in this new case statement should call the renderer for the diagram type with the data found by the parser as an argument.\n\n## Usage of the parser as a separate module\n\n### Setup\n\n```javascript\nconst graph = require('./graphDb');\nconst flow = require('./parser/flow');\nflow.parser.yy = graph;\n```\n\n### Parsing\n\n```javascript\nflow.parser.parse(text);\n```\n\n### Data extraction\n\n```javascript\ngraph.getDirection();\ngraph.getVertices();\ngraph.getEdges();\n```\n\nThe parser is also exposed in the mermaid api by calling:\n\n```javascript\nconst parser = mermaid.getParser();\n```\n\nNote that the parse needs a graph object to store the data as per:\n\n```javascript\nflow.parser.yy = graph;\n```\n\nLook at `graphDb.js` for more details on that object.\n\n## Layout\n\nIf you are using a dagre based layout, please use flowchart-v2 as a template and by doing that you will be using dagre-wrapper instead of dagreD3 which we are migrating away from.\n\n### Common parts of a diagram\n\nThere are a few features that are common between the different types of diagrams. We try to standardize the diagrams that work as similar as possible for the end user. The commonalities are:\n\n- Directives, a way of modifying the diagram configuration from within the diagram code.\n- Accessibility, a way for an author to provide additional information like titles and descriptions to people accessing a text with diagrams using a screen reader.\n- Themes, there is a common way to modify the styling of diagrams in Mermaid.\n- Comments should follow mermaid standards\n\nHere are some pointers on how to handle these different areas.\n\n## Accessibility\n\nMermaid automatically adds the following accessibility information for the diagram SVG HTML element:\n\n- aria-roledescription\n- accessible title\n- accessible description\n\n### aria-roledescription\n\nThe aria-roledescription is automatically set to [the diagram type](#step-3--detection-of-the-new-diagram-type) and inserted into the SVG element.\n\nSee [the definition of aria-roledescription](https://www.w3.org/TR/wai-aria-1.1/#aria-roledescription) in [the Accessible Rich Internet Applications W3 standard.](https://www.w3.org/WAI/standards-guidelines/aria/)\n\n### accessible title and description\n\nThe syntax for accessible titles and descriptions is described in [the Accessibility documentation section.](../config/accessibility.md)\n\nAs a design goal, the jison syntax should be similar between the diagrams.\n\n```jison\n\n* lexical grammar */\n%lex\n%x acc_title\n%x acc_descr\n%x acc_descr_multiline\n\n%%\naccTitle\\s*\":\"\\s*                                { this.begin(\"acc_title\");return 'acc_title'; }\n(?!\\n|;|#)*[^\\n]*                     { this.popState(); return \"acc_title_value\"; }\naccDescr\\s*\":\"\\s*                                { this.begin(\"acc_descr\");return 'acc_descr'; }\n(?!\\n|;|#)*[^\\n]*                     { this.popState(); return \"acc_descr_value\"; }\naccDescr\\s*\"{\"\\s*                                { this.begin(\"acc_descr_multiline\");}\n[\\}]                        { this.popState(); }\n[^\\}]*                      return \"acc_descr_multiline_value\";\n\nstatement\n    : acc_title acc_title_value  { $$=$2.trim();yy.setTitle($$); }\n    | acc_descr acc_descr_value  { $$=$2.trim();yy.setAccDescription($$); }\n    | acc_descr_multiline_value { $$=$1.trim();yy.setAccDescription($$); }\n\n```\n\nThe functions for setting title and description are provided by a common module. This is the import from flowDb.js:\n\n```\nimport {\n  setAccTitle,\n  getAccTitle,\n  getAccDescription,\n  setAccDescription,\n  clear as commonClear,\n} from '../../commonDb';\n```\n\nThe accessibility title and description are inserted into the SVG element in the `render` function in mermaidAPI.\n\n## Theming\n\nMermaid supports themes and has an integrated theming engine. You can read more about how the themes can be used [in the docs](../config/theming.md).\n\nWhen adding themes to a diagram it comes down to a few important locations in the code.\n\nThe entry point for the styling engine is in **src/styles.js**. The getStyles function will be called by Mermaid when the styles are being applied to the diagram.\n\nThis function will in turn call a function _your diagram should provide_ returning the css for the new diagram. The diagram specific, also which is commonly also called getStyles and located in the folder for your diagram under src/diagrams and should be named styles.js. The getStyles function will be called with the theme options as an argument like in the following example:\n\n```js\nconst getStyles = (options) =>\n  `\n    .line {\n      stroke-width: 1;\n      stroke: ${options.lineColor};\n      stroke-dasharray: 2;\n    }\n    // ...\n    `;\n```\n\nNote that you need to provide your function to the main getStyles by adding it into the themes object in **src/styles.js** like in the xyzDiagram in the provided example:\n\n```js\nconst themes = {\n  flowchart,\n  'flowchart-v2': flowchart,\n  sequence,\n  xyzDiagram,\n  //...\n};\n```\n\nThe actual options and values for the colors are defined in **src/theme/theme-[xyz].js**. If you provide the options your diagram needs in the existing theme files then the theming will work smoothly without hiccups.\n","packages/mermaid/src/docs/community/new-diagram.md":"# Adding a New Diagram/Chart 📊\n\nA diagram type in Mermaid is a plugin. You write a parser, a database, a renderer, and a styles\nfunction, register them under an id, and Mermaid handles detection, lazy loading, theming, and\nsanitization for you.\n\nThe use case diagram is the reference implementation for new work. When this guide says \"look at\nusecase\", the files are in `packages/mermaid/src/diagrams/usecase/`. Read them alongside these\nsteps: they are short, and they show the current conventions rather than the historical ones that\nolder diagrams still carry.\n\n## What a diagram is made of\n\nEach diagram exports a `DiagramDefinition` (`diagram-api/types.ts`) from a single entry file. The\nwhole of `usecaseDiagram.ts` is this:\n\n```ts\nimport type { DiagramDefinition } from '../../diagram-api/types.js';\nimport { parser } from './parser/usecase.chevrotain.js';\nimport { db } from './usecaseDb.js';\nimport { renderer } from './usecaseRenderer.js';\nimport styles from './styles.js';\n\nexport const diagram: DiagramDefinition = {\n  parser,\n  db,\n  renderer,\n  styles,\n};\n```\n\n| Part     | What it does                                                                   |\n| -------- | ------------------------------------------------------------------------------ |\n| parser   | Turns diagram text into calls on the db. Fails with a useful message otherwise |\n| db       | Holds the parsed model and hands it to the renderer                            |\n| renderer | Draws the SVG from what the db holds                                           |\n| styles   | Maps theme variables to CSS for your diagram                                   |\n| detector | A regex test that recognizes your diagram's first line. Lives in its own file  |\n\nTwo rules apply to everything in your folder:\n\nYour diagram must be self-contained. Never import from another diagram's folder. You may import\nfrom `diagrams/common/` and from `rendering-util/`, and that is the whole list. Cross-diagram\nimports create coupling that breaks unrelated diagrams later, so a reviewer will block on this.\n\nYour db must not carry state from one render into the next. `Diagram.fromText()` reads `db` off\nthe registered definition and calls `db.clear?.()` before parsing, and there are two supported\nways to satisfy that.\n\nA getter, which builds a new db on every read, so each render gets its own:\n\n```ts\nexport const diagram: DiagramDefinition = {\n  parser,\n  get db() {\n    return new TreeMapDB();\n  },\n  renderer,\n  styles,\n};\n```\n\nOr one shared db whose `clear()` resets every field it owns, plus the shared accessibility state\nin `diagrams/common/commonDb.ts`:\n\n```ts\nexport const diagram: DiagramDefinition = { parser, db, renderer, styles };\n```\n\nPrefer the getter in a new diagram. Isolation is then structural — a field added later cannot be\nforgotten in `clear()`, which is the way the shared form goes wrong. The use case diagram used as\nthe reference here takes the shared form, and pays for it by keeping every mutable field on one\n`state` object that `clear()` replaces wholesale, rather than resetting fields one by one.\n\nEither way the rule underneath is the same: all mutable state lives on the db, never in module\nscope. Module-level state survives `clear()` in both forms, and two diagrams of the same type on\none page will leak into each other.\n\n## Step 1: Grammar and parsing\n\nNew diagram grammars should use [Chevrotain](https://chevrotain.io/docs/), co-located with the\ndiagram itself under `packages/mermaid/src/diagrams//parser/`. The use case diagram is\nthe reference implementation: a lexer, a `CstParser`, and a CST visitor that builds the diagram\nmodel, sharing `diagrams/common/parser/runChevrotainParse.ts` to run the lexer/parser pair and\nreport failures with source positions.\n\nKeeping the grammar next to the diagram mirrors the existing JISON layout, so a diagram stays\nself-contained and the parser does not have to be released from a separate package.\n\nSeveral existing diagrams (architecture, gitGraph, info, packet, pie, radar, treemap) instead use\n[Langium](https://langium.org/docs/reference/grammar-language/) grammars in `packages/parser`, and\nolder diagrams use JISON. Both remain supported, so modify them in place for bug fixes rather than\nrewriting, but neither is the target for new work. These PRs show the Langium approach:\n\n- https://github.com/mermaid-js/mermaid/pull/4839\n- https://github.com/mermaid-js/mermaid/pull/4751\n\nWhichever you use, invalid input has to produce a parse error with a line and column, never a\nstack trace. Mermaid runs inside other people's pages, and a thrown exception there is a broken\npage rather than a broken diagram.\n\n## Step 2: The database\n\nThe db collects what the parser found and exposes getters for the renderer. Look at\n`usecaseDb.ts`. Alongside your own accessors, re-export the shared title and accessibility setters\nfrom `diagrams/common/commonDb.ts` so that authors get the same `title`, `accTitle`, and\n`accDescr` syntax they get everywhere else:\n\n```js\nimport {\n  setAccTitle,\n  getAccTitle,\n  getAccDescription,\n  setAccDescription,\n  setDiagramTitle,\n  getDiagramTitle,\n  clear as commonClear,\n} from '../common/commonDb.js';\n```\n\nYour own `clear()` should call `commonClear()` as well as resetting your own fields.\n\n## Step 3: The renderer\n\nWrite a renderer that draws the diagram from what the db holds. `usecaseRenderer.ts` is a good\nstarting point, and `sequenceRenderer.js` is a more generic older example than the flowchart\nrenderer. The renderer belongs in your diagram folder.\n\nTwo things are easy to miss and both get flagged in review.\n\nApply the configured padding and hand the sizing to the shared helper, so your diagram scales like\nevery other diagram instead of rendering at some unrelated size:\n\n```ts\nimport { setupViewPortForSVG } from '../../rendering-util/setupViewPortForSVG.js';\n\nsetupViewPortForSVG(svg, padding, 'usecaseDiagram', config.useMaxWidth);\n```\n\nSupport hand-drawn mode if your drawing approach allows it. The config carries a `look`, and\ndiagrams check it directly:\n\n```ts\nconst isHandDrawn = look === 'handDrawn';\n```\n\nIf a third party library makes hand-drawn output impossible, that is an acceptable answer, but say\nso in your diagram's documentation page so users are not left guessing.\n\n## Step 4: Detection and registration\n\nDetection lives in its own file next to the diagram, not in `detectType.ts`. A detector is a\nregex test plus a lazy loader, and it exports an `ExternalDiagramDefinition`:\n\n```ts\nconst id = 'usecase';\n\nconst detector: DiagramDetector = (txt) => {\n  return /^\\s*usecase-beta(?:\\s|$)/.test(txt);\n};\n\nconst loader: DiagramLoader = async () => {\n  const { diagram } = await import('./usecaseDiagram.js');\n  return { id, diagram };\n};\n\nexport const usecase: ExternalDiagramDefinition = { id, detector, loader };\n```\n\nThen import it in `diagram-api/diagram-orchestration.ts` and add it to the\n`registerLazyLoadedDiagrams(...)` call. Order matters there: the first detector that returns true\nwins, so a loose pattern placed early will swallow other diagrams. The loader is what keeps\nMermaid's bundle small, because your diagram is only fetched once someone writes one.\n\n[The id becomes the aria roledescription](#aria-roledescription), so pick a word that describes\nthe diagram out loud. For a UML deployment diagram, \"UMLDeploymentDiagram\" works, because a screen\nreader voices it as \"U-M-L Deployment diagram\", and so does \"deploymentDiagram\". \"deployment\" on\nits own does not say enough.\n\nThe id does not have to match the keyword you chose in the\n[grammar](#step-1-grammar-and-parsing), though it helps when they agree.\n\n## Step 5: Theming\n\nMermaid has an integrated theming engine, described in more detail [in the docs](../config/theming.md).\n\nYour diagram provides a `getStyles` function in `styles.ts` in your diagram folder. It is called\nwith the resolved theme options and returns CSS:\n\n```js\nconst getStyles = (options) =>\n  `\n    .line {\n      stroke-width: 1;\n      stroke: ${options.lineColor};\n      stroke-dasharray: 2;\n    }\n    // ...\n    `;\n```\n\nThere is nothing to wire up by hand. `registerDiagram()` passes your `styles` to\n`addStylesForDiagram()`, and the styling engine picks it up from there.\n\nEvery color must come from `options`. A hardcoded hex value looks fine in the default theme and\nthen breaks in dark mode, so reviewers treat hardcoded colors as a defect. The values themselves\nare defined in the theme files under `src/themes/`; if your diagram needs a variable that does not\nexist yet, add it there so all five themes define it.\n\n## Step 6: Configuration\n\nIf your diagram has options, add them to `src/schemas/config.schema.yaml`, both as an entry in the\nlist of diagram config keys and as its own config block. Then regenerate the types:\n\n```bash\npnpm run --filter mermaid types:build-config\n```\n\nNever edit `config.type.ts` by hand. It is generated, CI verifies it against the schema, and a\nmanual edit is a blocking review finding.\n\n## Accessibility\n\nMermaid automatically adds the following accessibility information for the diagram SVG HTML element:\n\n- aria-roledescription\n- accessible title\n- accessible description\n\n### aria-roledescription\n\nThe aria-roledescription is automatically set to\n[the diagram type](#step-4-detection-and-registration) and inserted into the SVG element.\n\nSee [the definition of aria-roledescription](https://www.w3.org/TR/wai-aria-1.1/#aria-roledescription) in [the Accessible Rich Internet Applications W3 standard.](https://www.w3.org/WAI/standards-guidelines/aria/)\n\n### accessible title and description\n\nThe syntax for accessible titles and descriptions is described in [the Accessibility documentation section.](../config/accessibility.md)\n\nYou get both for free once your db re-exports the setters shown in\n[Step 2](#step-2-the-database). The values are inserted into the SVG element in the `render`\nfunction in mermaidAPI.\n\n## Step 7: Tests\n\nA new diagram without tests will not be merged. There are three kinds, and none of them takes long.\n\nUnit tests for the parser and db go next to the code as `*.spec.ts`. Cover the syntax you\ndocumented, and cover invalid input too: a diagram that accepts nonsense silently is worse than\none that rejects it. Run them with `vitest run packages/mermaid/src/diagrams/`.\n\nVisual regression tests come from `.mmd` fixtures. Put one file per scenario in\n`e2e/diagrams//`, and that is the whole job:\n`e2e/rendering/mmd-snapshots.spec.ts` walks that directory, renders each fixture, and snapshots\nit, grouping the results by folder. Screenshot names must be unique across the whole tree, and the\nrun fails fast if two fixtures collide. `e2e/sheet-order.json` holds the ordering. Run the suite\nwith `pnpm e2e`. Cover realistic diagrams rather than one minimal smoke test, and include a\nfixture per theme if your styling is at all involved.\n\nA documentation test keeps your examples honest. `usecase.docs.spec.ts` reads the published\n`syntax/usecase.md`, extracts every ` ```mermaid-example ` block, and parses it. Copy that pattern\nand your documentation cannot drift into examples that no longer work.\n\n## Step 8: Documentation, demos, and examples\n\nWrite your syntax page as `packages/mermaid/src/docs/syntax/.md`. Edit only the files\nunder `src/docs/`; the top-level `/docs` folder is generated and your changes there will be\noverwritten. Mark the version with the placeholder, as `usecase.md` does with\n`# Use case diagrams (12.0.0+)`, and the release process substitutes the real\nnumber.\n\nAdd the page to the sidebar in `.vitepress/config.ts` under `sidebarSyntax()`. A page with no\nsidebar entry is reachable only by URL, which in practice means nobody reads it.\n\nAdd a demo page at `demos/.html` and link it from `demos/index.html`, following any\nof the existing demos.\n\nAdd at least one entry to the `@mermaid-js/examples` package, which is what tools like\nmermaid.live use to help people get started. Duplicate an existing file such as\n`packages/examples/src/examples/flowchart.ts`, adapt it, then import it in\n`packages/examples/src/index.ts` and add it to the `examples` array. Mark one example as the\ndefault, and add more to show off individual features.\n\nIf your syntax introduces new keywords, add them to `.cspell/mermaid-terms.txt`. The pre-commit\nhook runs CSpell and will otherwise reject the commit.\n\n## Step 9: Changeset and pull request\n\nRun `pnpm changeset`, choose the `mermaid` package and a `minor` bump, and write a description\nprefixed with `feat:`.\n\nOpen the PR against `develop` and link the issue it resolves. New diagram types are large by\nnature, and that is fine, but keep unrelated refactors out of the same branch.\n\n## Reviewer's checklist\n\nThis is what a reviewer checks. Going through it yourself first is the fastest way to a short\nreview.\n\n- [ ] Parser uses Chevrotain, co-located under `diagrams//parser/`\n- [ ] Invalid input produces a parse error with position, not a crash\n- [ ] `DiagramDefinition` exports parser, db, renderer, and styles\n- [ ] Detector in its own file, registered in `diagram-orchestration.ts`, ordered so it does not shadow other diagrams\n- [ ] Diagram id reads well as an aria roledescription\n- [ ] db holds no module-level state and `clear()` resets everything, including `commonClear()`\n- [ ] No imports from other diagrams' folders\n- [ ] Renderer applies padding and `useMaxWidth` through `setupViewPortForSVG`\n- [ ] Handdrawn mode implemented, or its absence documented\n- [ ] `styles.ts` takes theme options, with no hardcoded colors\n- [ ] Config options added to `config.schema.yaml` and `config.type.ts` regenerated, never hand-edited\n- [ ] Accessibility setters re-exported from `common/commonDb.ts`\n- [ ] Unit tests for parser and db, covering invalid input\n- [ ] `.mmd` fixtures in `e2e/diagrams//` for visual regression\n- [ ] Documentation examples covered by a docs spec\n- [ ] Syntax page under `src/docs/syntax/`, with `MERMAID_RELEASE_VERSION` and a sidebar entry\n- [ ] Demo page and `demos/index.html` link\n- [ ] Example added to `@mermaid-js/examples`, one marked default\n- [ ] New keywords added to `.cspell/mermaid-terms.txt`\n- [ ] Changeset created (`minor`, `feat:`)\n- [ ] PR targets `develop` and links its issue\n","packages/mermaid/src/docs/community/questions-and-suggestions.md":"# Questions or Suggestions?\n\n## Search for Existing Issue\n\nFirst search to see if someone has already asked (and hopefully been answered) or suggested the same thing.\n\n- [Search in Discussions](https://github.com/orgs/mermaid-js/discussions)\n- [Search in Issues (Open & Closed)](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue)\n\nIf you find an open issue or discussion thread that is similar to your question but isn't answered, you can let us know that you are also interested in it.\nUse the GitHub reactions to add a thumbs-up to the issue or discussion thread, or append to the issue if needed.\n\nThis helps the team know the relative interest in something and helps them set priorities and assignments.\n\n## Add a new Issue\n\nYou have not found anything that already addresses your request, or maybe you have come up with the new idea? Feel free to open a new issue or discussion.\n\nLog in to [GitHub.com](https://www.github.com), and use [GitHub issue tracker of the mermaid-js repository](https://github.com/mermaid-js/mermaid/issues). Press [issue, select the appropriate template](https://github.com/mermaid-js/mermaid/issues/new/choose) and describe your problem.\n","packages/mermaid/src/docs/community/security.md":"# Security\n\nThe Mermaid team takes the security of Mermaid and the applications that use Mermaid seriously. This page describes how to report any vulnerabilities you may find, and lists best practices to minimize the risk of introducing a vulnerability.\n\n## Reporting vulnerabilities\n\nTo report a vulnerability, please e-mail  with a description of the issue, the steps you took to create the issue, affected versions, and if known, mitigations for the issue.\n\nWe aim to reply within three working days, probably much sooner.\n\nYou should expect a close collaboration as we work to resolve the issue you have reported. Please reach out to  again if you do not receive prompt attention and regular updates.\n\nYou may also reach out to the team via our public Discord chat channels; however, please make sure to e-mail  when reporting an issue, and avoid revealing information about vulnerabilities in public as that could that could put users at risk.\n\n## Best practices\n\nKeep current with the latest Mermaid releases. We regularly update Mermaid, and these updates may fix security defects discovered in previous versions. Check the Mermaid release notes for security-related updates.\n\nKeep your application’s dependencies up to date. Make sure you upgrade your package dependencies to keep the dependencies up to date. Avoid pinning to specific versions for your dependencies and, if you do, make sure you check periodically to see if your dependencies have had security updates, and update the pin accordingly.\n\n## Configuring DomPurify\n\nBy default Mermaid uses a baseline [DOMPurify](https://github.com/cure53/DOMPurify) config. It is possible to override the options passed to DOMPurify by adding a `dompurifyConfig` key to the Mermaid options. This could potentially break the output of Mermaid so use this with caution.\n","packages/mermaid/src/docs/config/8.6.0_docs.md":"# Version 8.6.0 Changes\n\n## [New Mermaid Live-Editor Beta](https://mermaid-js.github.io/docs/mermaid-live-editor-beta/#/edit/eyJjb2RlIjoiJSV7aW5pdDoge1widGhlbWVcIjogXCJmb3Jlc3RcIiwgXCJsb2dMZXZlbFwiOiAxIH19JSVcbmdyYXBoIFREXG4gIEFbQ2hyaXN0bWFzXSAtLT58R2V0IG1vbmV5fCBCKEdvIHNob3BwaW5nKVxuICBCIC0tPiBDe0xldCBtZSB0aGlua31cbiAgQyAtLT58T25lfCBEW0xhcHRvcF1cbiAgQyAtLT58VHdvfCBFW2lQaG9uZV1cbiAgQyAtLT58VGhyZWV8IEZbZmE6ZmEtY2FyIENhcl1cblx0XHQiLCJtZXJtYWlkIjp7InRoZW1lIjoiZGFyayJ9fQ)\n\n## [CDN](https://www.jsdelivr.com/package/npm/mermaid)\n\nWith version 8.6.0 comes the release of directives for mermaid, a new system for modifying configurations, with the aim of establishing centralized, sane defaults and simple implementation.\n\n`directives` allow for a single-use overwriting of `config`, as it has been discussed in [Configurations](../config/configuration.md).\nThis allows site Diagram Authors to instantiate temporary modifications to `config` through the use of [Directives](directives.md), which are parsed before rendering diagram definitions. This allows the Diagram Authors to alter the appearance of the diagrams.\n\n**A likely application for this is in the creation of diagrams/charts inside company/organizational webpages, that rely on mermaid for diagram and chart rendering.**\n\nthe `init` directive is the main method of configuration for Site and Current Levels.\n\nThe three levels of are Configuration, Global, Site and Current.\n\n| Level of Configuration | Description                         |\n| ---------------------- | ----------------------------------- |\n| Global Configuration   | Default Mermaid Configurations      |\n| Site Configuration     | Configurations made by site owner   |\n| Current Configuration  | Configurations made by Implementors |\n\n# Limits to Modifying Configurations\n\n**secure Array**\n\n| Parameter | Description                                      | Type  | Required | Values         |\n| --------- | ------------------------------------------------ | ----- | -------- | -------------- |\n| secure    | Array of parameters excluded from init directive | Array | Required | Any parameters |\n\nThe modifiable parts of the Configuration are limited by the secure array, which is an array of immutable parameters, this array can be expanded by site owners.\n\n**Notes**: secure arrays work like nesting dolls, with the Global Configurations’ secure array holding the default and immutable list of immutable parameters, or the smallest doll, to which site owners may add to, but implementors may not modify it.\n\n# Secure Arrays\n\nSite owners can add to the **secure** array using this command:\nmermaidAPI.initialize( { startOnLoad: true, secure: ['parameter1', 'parameter2'] } );\n\nDefault values for the `secure array` consists of: ['secure', 'securityLevel', 'startOnLoad', 'maxTextSize']. These default values are immutable.\n\nImplementors can only modify configurations using directives, and cannot change the `secure` array.\n\n# Modifying Configurations and directives:\n\nThe Two types of directives: are `init` (or `initialize`) and `wrap`.\n\n```note\nAll directives are enclosed in `%%{ }%%`\n```\n\nOlder versions of mermaid will not parse directives because `%%` will comment out the directive. This makes the update backwards-compatible.\n\n# Init\n\n`init`, or `initialize`: this directive gives the user the ability to overwrite and change the values for any configuration parameters not set in the secure array.\n\n| Parameter | Description             | Type      | Required | Values                                          |\n| --------- | ----------------------- | --------- | -------- | ----------------------------------------------- |\n| init      | modifies configurations | Directive | Optional | Any parameters not included in the secure array |\n\n```note\ninit would be an argument-directive: `%%{init: { **insert argument here**}}%%`\n\nThe json object that is passed as {**argument** } must be valid, quoted json or it will be ignored.\n**for example**:\n\n`%%{init: {\"theme\": \"default\", \"logLevel\": 1 }}%%`\n\nConfigurations that are passed through init cannot change the parameters in a secure array at a higher level. In the event of a collision, mermaid will give priority to secure arrays and parse the request without changing the values of those parameters in conflict.\n\nWhen deployed within code, init is called before the graph/diagram description.\n```\n\n**for example**:\n\n```mermaid-example\n%%{init: {\"theme\": \"default\", \"logLevel\": 1 }}%%\n graph LR\n  a-->b\n  b-->c\n  c-->d\n  d-->e\n  e-->f\n  f-->g\n  g-->\n```\n\n# Wrap\n\n| Parameter | Description                   | Type      | Required | Values     |\n| --------- | ----------------------------- | --------- | -------- | ---------- |\n| wrap      | a callable text-wrap function | Directive | Optional | %%{wrap}%% |\n\n```note\nWrap is a function that is currently only deployable for sequence diagrams.\n\n`Wrap respects a manually added 
, so if the user wants to break up their text, they have full control over line breaks by adding 
 tags.`\n\nIt is a non-argument directive and can be executed thusly:\n\n`%%{wrap}%%` .\n```\n\n**An example of text wrapping in a sequence diagram**:\n\n![Image showing wrapped text](img/wrapped text.png)\n\n# Resetting Configurations:\n\nThere are two more functions in the mermaidAPI that can be called by site owners: **reset** and **globalReset**.\n\n**reset**: resets the configuration to whatever the last configuration was. This can be done to undo more recent changes set from the last mermaidAPI.initialize({...}) configuration.\n\n**globalReset** will reset both the current configuration AND the site configuration back to the global defaults.\n\n**Notes**: Both `reset` and `globalReset` are only available to site owners, and as such implementors have to edit their configs using `init`.\n\n# Additional Utils to mermaid\n\n• **memoize**: simple caching for computationally expensive functions, reducing rendering time by about 90%.\n\n• **assignWithDepth** - an improvement on previous functions with config.js and `Object.assign`. The purpose of this function is to provide a sane mechanism for merging objects, similar to `object.assign`, but with depth.\n\nExample of **assignWithDepth**:\n\n![Image showing assignWithDepth](img/assignWithDepth.png)\n\nExample of **object.Assign**:\n\n![Image showing object.assign without depth](img/object.assign without depth.png)\n\n• **calculateTextDimensions**, **calculateTextWidth**， and **calculateTextHeight** - for measuring text dimensions, width and height.\n\n**Notes**: For more information on usage, parameters, and return info for these new functions take a look at the jsdocs for them in the utils package.\n\n# New API Requests Introduced in Version 8.6.0\n\n## setSiteConfig\n\n| Function        | Description                           | Type        | Values                                  | Parameters | Returns    |\n| --------------- | ------------------------------------- | ----------- | --------------------------------------- | ---------- | ---------- |\n| `setSiteConfig` | Sets the siteConfig to desired values | Put Request | Any Values, except ones in secure array | conf       | siteConfig |\n\n```note\nSets the siteConfig. The siteConfig is a protected configuration for repeat use. Calls to reset() will reset\nthe currentConfig to siteConfig. Calls to reset(configApi.defaultConfig) will reset siteConfig and currentConfig\nto the defaultConfig\nNote: currentConfig is set in this function。\nDefault value: will mirror Global Config\n```\n\n## getSiteConfig\n\n| Function        | Description                                         | Type        | Values                             |\n| --------------- | --------------------------------------------------- | ----------- | ---------------------------------- |\n| `getSiteConfig` | Returns the current `siteConfig` base configuration | Get Request | Returns Any Values in `siteConfig` |\n\n```note\nReturns any values in siteConfig.\n```\n\n## setConfig\n\n| Function    | Description                                | Type        | Values                            | Parameters | Returns                                        |\n| ----------- | ------------------------------------------ | ----------- | --------------------------------- | ---------- | ---------------------------------------------- |\n| `setConfig` | Sets the `currentConfig` to desired values | Put Request | Any Values, those in secure array | conf       | `currentConfig` merged with the sanitized conf |\n\n```note\nSets the currentConfig. The parameter conf is sanitized based on the siteConfig.secure keys. Any\nvalues found in conf with key found in siteConfig.secure will be replaced with the corresponding\nsiteConfig value.\n```\n\n## getConfig\n\n| Function    | Description                 | Type        | Return Values                   |\n| ----------- | --------------------------- | ----------- | ------------------------------- |\n| `getConfig` | Obtains the `currentConfig` | Get Request | Any Values from `currentConfig` |\n\n```note\nReturns any values in currentConfig.\n```\n\n## sanitize\n\n| Function   | Description                              | Type           | Values |\n| ---------- | ---------------------------------------- | -------------- | ------ |\n| `sanitize` | Sets the `siteConfig` to desired values. | Put Request(?) | None   |\n\n```note\nmodifies options in-place\nEnsures options parameter does not attempt to override siteConfig secure keys.\n```\n\n## reset\n\n| Function | Description                    | Type        | Required | Values | Parameter |\n| -------- | ------------------------------ | ----------- | -------- | ------ | --------- |\n| `reset`  | Resets `currentConfig` to conf | Put Request | Required | None   | conf      |\n\n## conf\n\n| Parameter | Description                                                  | Type       | Required | Values                                       |\n| --------- | ------------------------------------------------------------ | ---------- | -------- | -------------------------------------------- |\n| `conf`    | base set of values, which `currentConfig` could be reset to. | Dictionary | Required | Any Values, with respect to the secure Array |\n\n```note\ndefault: current siteConfig (optional, default `getSiteConfig()`)\n```\n\n## For more information, read [Setup](./setup/README.md).\n","packages/mermaid/src/docs/config/accessibility.md":"# Accessibility Options\n\n## Accessibility\n\nNow with Mermaid library in much wider use, we have started to work towards more accessible features, based on the feedback from the community.\n\nAdding accessibility means that the rich information communicated by visual diagrams can be made available to those using assistive technologies (and of course to search engines).\n[Read more about Accessible Rich Internet Applications and the W3 standards.](https://www.w3.org/WAI/standards-guidelines/aria/)\n\nMermaid will automatically insert the [aria-roledescription](#aria-roledescription) and, if provided in the diagram text by the diagram author, the [accessible title and description.](#accessible-title-and-description)\n\n### aria-roledescription\n\nThe [aria-roledescription](https://www.w3.org/TR/wai-aria-1.1/#aria-roledescription) for the SVG HTML element is set to the diagram type key. (Note this may be slightly different than the keyword used for the diagram in the diagram text.)\n\nFor example: The diagram type key for a state diagram is \"stateDiagram\". Here (a part of) the HTML of the SVG tag that shows the automatically inserted aria-roledescription set to \"stateDiagram\". _(Note that some of the SVG attributes and the SVG contents are omitted for clarity.):_\n\n```html\n\n```\n\n### Accessible Title and Description\n\nSupport for accessible titles and descriptions is available for all diagrams/chart types. We have tried to keep the same keywords and format for all diagrams so that it is easy to understand and maintain.\n\nThe accessible title and description will add `` and `<desc>` elements within the SVG element and the [aria-labelledby](https://www.w3.org/TR/wai-aria/#aria-labelledby) and [aria-describedby](https://www.w3.org/TR/wai-aria/#aria-describedby) attributes in the SVG tag.\n\nHere is HTML that is generated, showing that the SVG element is labelled by the accessible title (id = `chart-title-mermaid-1668725057758`)\nand described by the accessible description (id = `chart-desc-mermaid-1668725057758` );\nand the accessible title element (text = \"This is the accessible title\")\nand the accessible description element (text = \"This is an accessible description\").\n\n_(Note that some of the SVG attributes and the SVG contents are omitted for clarity.)_\n\n```html\n<svg\n  aria-labelledby=\"chart-title-mermaid-1668725057758\"\n  aria-describedby=\"chart-desc-mermaid-1668725057758\"\n  xmlns=\"http://www.w3.org/2000/svg\"\n  width=\"100%\"\n  id=\"mermaid-1668725057758\"\n>\n  <title id=\"chart-title-mermaid-1668725057758\">This is the accessible title\n  This is an accessible description\n\n```\n\nDetails for the syntax follow.\n\n#### accessible title\n\nThe **accessible title** is specified with the **accTitle** _keyword_, followed by a colon (`:`), and the string value for the title.\nThe string value ends at the end of the line. (It can only be a single line.)\n\nEx: `accTitle: This is a single line title`\n\nSee [the accTitle and accDescr usage examples](#acctitle-and-accdescr-usage-examples) for how this can be used in a diagram and the resulting HTML generated.\n\n#### accessible description\n\nAn accessible description can be 1 line long (a single line) or many lines long.\n\nThe **single line accessible description** is specified with the **accDescr** _keyword_, followed by a colon (`:`), followed by the string value for the description.\n\nEx: `accDescr: This is a single line description.`\n\nA **multiple line accessible description** _does not have a colon (`:`) after the accDescr keyword_ and is surrounded by curly brackets (`{}`).\n\nEx:\n\n```markdown\naccDescr {\nThis is a multiple line accessible description.\nIt does not have a colon and is surrounded by curly brackets.\n}\n```\n\nSee [the accTitle and accDescr usage examples](#acctitle-and-accdescr-usage-examples) for how this can be used in a diagram and the resulting HTML generated.\n\n#### accTitle and accDescr Usage Examples\n\n- Flowchart with the accessible title \"Big Decisions\" and the single-line accessible description \"Bob's Burgers process for making big decisions\"\n\n```mermaid-example\n  graph LR\n      accTitle: Big Decisions\n      accDescr: Bob's Burgers process for making big decisions\n      A[Identify Big Decision] --> B{Make Big Decision}\n      B --> D[Be done]\n```\n\nHere is the HTML generated for the SVG element: _(Note that some of the SVG attributes and the SVG contents are omitted for clarity.):_\n\n```html\n\n  Big decisions\n  Bob's Burgers process for making big decisions\n\n```\n\n- Flowchart with the accessible title \"Bob's Burger's Making Big Decisions\" and the multiple line accessible description \"The official Bob's Burgers corporate processes that are used\n  for making very, very big decisions.\n  This is actually a very simple flow: identify the big decision and then make the big decision.\"\n\n```mermaid-example\n  graph LR\n      accTitle: Bob's Burger's Making Big Decisions\n      accDescr {\n        The official Bob's Burgers corporate processes that are used\n        for making very, very big decisions.\n        This is actually a very simple flow: identify the big decision and then make the big decision.\n         }\n      A[Identify Big Decision] --> B{Make Big Decision}\n      B --> D[Be done]\n```\n\nHere is the HTML generated for the SVG element: _(Note that some of the SVG attributes and the SVG contents are omitted for clarity.):_\n\n```html\n\n  Big decisions\n  \n    The official Bob's Burgers corporate processes that are used for making very, very big\n    decisions. This is actually a very simple flow: identify the big decision and then make the big\n    decision.\n  \n\n```\n\n#### Sample Code Snippets for other diagram types\n\n##### Class Diagram\n\n```mermaid-example\n   classDiagram\n      accTitle: My Class Diagram\n      accDescr: My Class Diagram Description\n\n      Vehicle <|-- Car\n```\n\n##### Entity Relationship Diagram\n\n```mermaid-example\n   erDiagram\n      accTitle: My Entity Relationship Diagram\n      accDescr: My Entity Relationship Diagram Description\n\n    CUSTOMER ||--o{ ORDER : places\n    ORDER ||--|{ LINE-ITEM : contains\n    CUSTOMER }|..|{ DELIVERY-ADDRESS : uses\n\n```\n\n##### Gantt Chart\n\n```mermaid-example\n   gantt\n      accTitle: My Gantt Chart Accessibility Title\n      accDescr: My Gantt Chart Accessibility Description\n\n    title A Gantt Diagram\n    dateFormat  YYYY-MM-DD\n    section Section\n    A task           :a1, 2014-01-01, 30d\n    Another task     :after a1  , 20d\n    section Another\n    Task in sec      :2014-01-12  , 12d\n    another task      : 24d\n\n```\n\n##### GitGraph\n\n```mermaid-example\n  gitGraph\n      accTitle: My GitGraph Accessibility Title\n      accDescr: My GitGraph Accessibility Description\n\n     commit\n     commit\n     branch develop\n     checkout develop\n     commit\n     commit\n     checkout main\n     merge develop\n     commit\n     commit\n\n```\n\n##### Pie Chart\n\n```mermaid-example\n   pie\n      accTitle: My Pie Chart Accessibility Title\n      accDescr: My Pie Chart Accessibility Description\n\n    title Key elements in Product X\n    \"Calcium\" : 42.96\n    \"Potassium\" : 50.05\n    \"Magnesium\" : 10.01\n    \"Iron\" :  5\n\n```\n\n##### Requirement Diagram\n\n```mermaid-example\n  requirementDiagram\n      accTitle: My Requirement Diagram\n      accDescr: My Requirement Diagram Description\n\n       requirement test_req {\n  id: 1\n  text: the test text.\n  risk: high\n  verifymethod: test\n  }\n\n  element test_entity {\n  type: simulation\n  }\n\n  test_entity - satisfies -> test_req\n\n```\n\n##### Sequence Diagram\n\n```mermaid-example\n   sequenceDiagram\n      accTitle: My Sequence Diagram\n      accDescr: My Sequence Diagram Description\n\n      Alice->>John: Hello John, how are you?\n      John-->>Alice: Great!\n      Alice-)John: See you later!\n```\n\n##### State Diagram\n\n```mermaid-example\n   stateDiagram\n      accTitle: My State Diagram\n      accDescr: My State Diagram Description\n\n       s1 --> s2\n\n```\n\n##### User Journey Diagram\n\n```mermaid-example\n  journey\n      accTitle: My User Journey Diagram\n      accDescr: My User Journey Diagram Description\n\n      title My working day\n      section Go to work\n        Make tea: 5: Me\n        Go upstairs: 3: Me\n        Do work: 1: Me, Cat\n      section Go home\n        Go downstairs: 5: Me\n        Sit down: 5: Me\n\n```\n","packages/mermaid/src/docs/config/configuration.md":"# Configuration\n\nWhen mermaid starts, configuration is extracted to determine a configuration to be used for a diagram. There are 3 sources for configuration:\n\n- The default configuration\n- Overrides at the site level are set by the initialize call, and will be applied to all diagrams in the site/app. The term for this is the **siteConfig**.\n- Frontmatter (v10.5.0+) - diagram authors can update selected configuration parameters in the frontmatter of the diagram. These are applied to the render config.\n- Directives (Deprecated by Frontmatter) - diagram authors can update selected configuration parameters directly in the diagram code via directives. These are applied to the render config.\n\n**The render config** is configuration that is used when rendering by applying these configurations.\n\n## Frontmatter config\n\nThe entire mermaid configuration (except the secure configs) can be overridden by the diagram author in the frontmatter of the diagram. The frontmatter is a YAML block at the top of the diagram.\n\n```mermaid-example\n---\ntitle: Hello Title\nconfig:\n  theme: base\n  themeVariables:\n    primaryColor: \"#00ff00\"\n---\nflowchart\n\tHello --> World\n\n```\n\n## Theme configuration\n\n## Starting mermaid\n\n```mermaid\nsequenceDiagram\n\tSite->>mermaid: initialize\n\tSite->>mermaid: content loaded\n\tmermaid->>mermaidAPI: init\n```\n\n## Initialize\n\nThe initialize call is applied **only once**. It is called by the site integrator in order to override the default configuration at a site level.\n\n## configApi.reset\n\nThis method resets the configuration for a diagram to the overall site configuration, which is the configuration provided by the site integrator. Before each rendering of a diagram, reset is called at the very beginning.\n","packages/mermaid/src/docs/config/directives.md":"# Directives\n\n```warning\nDirectives are deprecated from v10.5.0. Please use the `config` key in frontmatter to pass configuration. See [Configuration](./configuration.md) for more details.\n```\n\n## Directives\n\nDirectives give a diagram author the capability to alter the appearance of a diagram before rendering by changing the applied configuration.\n\nThe significance of having directives is that you have them available while writing the diagram, and can modify the default global and diagram-specific configurations. So, directives are applied on top of the default configuration. The beauty of directives is that you can use them to alter configuration settings for a specific diagram, i.e. at an individual level.\n\nWhile directives allow you to change most of the default configuration settings, there are some that are not available, for security reasons. Also, you have the _option to define the set of configurations_ that you wish to allow diagram authors to override with directives.\n\n## Types of Directives options\n\nMermaid basically supports two types of configuration options to be overridden by directives.\n\n1. _General/Top Level configurations_ : These are the configurations that are available and applied to all the diagram. **Some of the most important top-level** configurations are:\n   - theme\n   - fontFamily\n   - logLevel\n   - securityLevel\n   - startOnLoad\n   - secure\n\n2. _Diagram-specific configurations_ : These are the configurations that are available and applied to a specific diagram. For each diagram there are specific configuration that will alter how that particular diagram looks and behaves.\n   For example, `mirrorActors` is a configuration that is specific to the `SequenceDiagram` and alters whether the actors are mirrored or not. So this config is available only for the `SequenceDiagram` type.\n\n**NOTE:** Not all configuration options are listed here. To get hold of all the configuration options, please refer to the [defaultConfig.ts](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/defaultConfig.ts) in the source code.\n\n```note\nWe plan to publish a complete list of top-level configurations & diagram-specific configurations with their possible values in the docs soon.\n```\n\n## Declaring directives\n\nNow that we have defined the types of configurations that are available, we can learn how to declare directives.\nA directive always starts and ends with `%%` signs with directive text in between, like `%% {directive_text} %%`.\n\nHere the structure of a directive text is like a nested key-value pair map or a JSON object with root being _init_. Where all the general configurations are defined in the top level, and all the diagram specific configurations are defined one level deeper with diagram type as key/root for that section.\n\nThe following code snippet shows the structure of a directive:\n\n```\n%%{\n  init: {\n    \"theme\": \"dark\",\n    \"fontFamily\": \"monospace\",\n    \"logLevel\": \"info\",\n    \"htmlLabels\": true,\n    \"flowchart\": {\n      \"curve\": \"linear\"\n    },\n    \"sequence\": {\n      \"mirrorActors\": true\n    }\n  }\n}%%\n```\n\nYou can also define the directives in a single line, like this:\n\n```\n%%{init: { **insert configuration options here** } }%%\n```\n\nFor example, the following code snippet:\n\n```\n%%{init: { \"sequence\": { \"mirrorActors\":false }}}%%\n```\n\n**Notes:**\nThe JSON object that is passed as {**argument**} must be valid key value pairs and encased in quotation marks or it will be ignored.\nValid Key Value pairs can be found in config.\n\nExample with a simple graph:\n\n```mermaid-example\n%%{init: { 'logLevel': 'debug', 'theme': 'dark' } }%%\ngraph LR\nA-->B\n```\n\nHere the directive declaration will set the `logLevel` to `debug` and the `theme` to `dark` for a rendered mermaid diagram, changing the appearance of the diagram itself.\n\nNote: You can use 'init' or 'initialize' as both are acceptable as init directives. Also note that `%%init%%` and `%%initialize%%` directives will be grouped together after they are parsed.\n\n```mermaid-example\n%%{init: { 'logLevel': 'debug', 'theme': 'forest' } }%%\n%%{initialize: { 'logLevel': 'fatal', \"theme\":'dark', 'startOnLoad': true } }%%\n...\n```\n\nFor example, parsing the above generates a single `%%init%%` JSON object below, combining the two directives and carrying over the last value given for `loglevel`:\n\n```json\n{\n  \"logLevel\": \"fatal\",\n  \"theme\": \"dark\",\n  \"startOnLoad\": true\n}\n```\n\nThis will then be sent to `mermaid.initialize(...)` for rendering.\n\n## Directive Examples\n\nNow that the concept of directives has been explained, let us see some more examples of directive usage:\n\n### Changing theme via directive\n\nThe following code snippet changes `theme` to `forest`:\n\n`%%{init: { \"theme\": \"forest\" } }%%`\n\nPossible theme values are: `default`, `base`, `dark`, `forest` and `neutral`.\nDefault Value is `default`.\n\nExample:\n\n```mermaid-example\n%%{init: { \"theme\": \"forest\" } }%%\ngraph TD\nA(Forest) --> B[/Another/]\nA --> C[End]\n  subgraph section\n  B\n  C\n  end\n\n```\n\n### Changing fontFamily via directive\n\nThe following code snippet changes fontFamily to Trebuchet MS, Verdana, Arial, Sans-Serif:\n\n`%%{init: { \"fontFamily\": \"Trebuchet MS, Verdana, Arial, Sans-Serif\" } }%%`\n\nExample:\n\n```mermaid-example\n%%{init: { \"fontFamily\": \"Trebuchet MS, Verdana, Arial, Sans-Serif\" } }%%\ngraph TD\nA(Forest) --> B[/Another/]\nA --> C[End]\n  subgraph section\n  B\n  C\n  end\n\n```\n\n### Changing logLevel via directive\n\nThe following code snippet changes `logLevel` to `2`:\n\n`%%{init: { \"logLevel\": 2 } }%%`\n\nPossible `logLevel` values are:\n\n- `1` for _debug_,\n- `2` for _info_\n- `3` for _warn_\n- `4` for _error_\n- `5` for _only fatal errors_\n\nDefault Value is `5`.\n\nExample:\n\n```mermaid-example\n%%{init: { \"logLevel\": 2 } }%%\ngraph TD\nA(Forest) --> B[/Another/]\nA --> C[End]\n  subgraph section\n  B\n  C\n  end\n```\n\n### Changing flowchart config via directive\n\nSome common flowchart configurations are:\n\n- ~~_htmlLabels_~~: Deprecated, [prefer setting this at the root level](/config/schema-docs/config#htmllabels).\n- _curve_: linear/curve\n- _diagramPadding_: number\n- _useMaxWidth_: number\n\nFor a complete list of flowchart configurations, see [defaultConfig.ts](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/defaultConfig.ts) in the source code.\n_Soon we plan to publish a complete list of all diagram-specific configurations updated in the docs._\n\nThe following code snippet changes flowchart config:\n\n```\n%%{init: { \"htmlLabels\": true, \"flowchart\": { \"curve\": \"linear\" } } }%%\n```\n\nHere we are overriding only the flowchart config, and not the general config, setting `htmlLabels` to `true` and `curve` to `linear`.\n\n```warning\n**Deprecated:** `flowchart.htmlLabels` has been deprecated from (v11.12.3+). Use the global `htmlLabels` configuration instead. For example, instead of `\"flowchart\": { \"htmlLabels\": true }`, use `\"htmlLabels\": true` at the top level.\n```\n\n```mermaid-example\n%%{init: { \"flowchart\": { \"htmlLabels\": true, \"curve\": \"linear\" } } }%%\ngraph TD\nA(Forest) --> B[/Another/]\nA --> C[End]\n  subgraph section\n  B\n  C\n  end\n```\n\n### Changing Sequence diagram config via directive\n\nSome common sequence diagram configurations are:\n\n- _width_: number\n- _height_: number\n- _messageAlign_: left, center, right\n- _mirrorActors_: boolean\n- _useMaxWidth_: boolean\n- _rightAngles_: boolean\n- _showSequenceNumbers_: boolean\n- _wrap_: boolean\n\nFor a complete list of sequence diagram configurations, see [defaultConfig.ts](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/defaultConfig.ts) in the source code.\n_Soon we plan to publish a complete list of all diagram-specific configurations updated in the docs._\n\nSo, `wrap` by default has a value of `false` for sequence diagrams.\n\nLet us see an example:\n\n```mermaid-example\nsequenceDiagram\n\nAlice->Bob: Hello Bob, how are you?\nBob->Alice: Fine, how did your mother like the book I suggested? And did you catch the new book about alien invasion?\nAlice->Bob: Good.\nBob->Alice: Cool\n```\n\nNow let us enable wrap for sequence diagrams.\n\nThe following code snippet changes sequence diagram config for `wrap` to `true`:\n\n`%%{init: { \"sequence\": { \"wrap\": true} } }%%`\n\nBy applying that snippet to the diagram above, `wrap` will be enabled:\n\n```mermaid-example\n%%{init: { \"sequence\": { \"wrap\": true, \"width\":300 } } }%%\nsequenceDiagram\nAlice->Bob: Hello Bob, how are you?\nBob->Alice: Fine, how did your mother like the book I suggested? And did you catch the new book about alien invasion?\nAlice->Bob: Good.\nBob->Alice: Cool\n```\n","packages/mermaid/src/docs/config/faq.md":"# Frequently Asked Questions\n\n1. [How to add title to flowchart?](https://github.com/mermaid-js/mermaid/issues/1433#issuecomment-1991554712)\n1. [How to specify custom CSS file?](https://github.com/mermaidjs/mermaid.cli/pull/24#issuecomment-373402785)\n1. [How to fix tooltip misplacement issue?](https://github.com/mermaid-js/mermaid/issues/542#issuecomment-3343564621)\n1. [How to specify gantt diagram xAxis format?](https://github.com/mermaid-js/mermaid/issues/269#issuecomment-373229136)\n1. [How to bind an event?](https://github.com/mermaid-js/mermaid/issues/372)\n1. [How to add newline in the text?](https://github.com/mermaid-js/mermaid/issues/384#issuecomment-281339381)\n1. [How to have special characters in link text?](https://github.com/mermaid-js/mermaid/issues/407#issuecomment-329944735)\n1. [How to change Flowchart curve style?](https://github.com/mermaid-js/mermaid/issues/580#issuecomment-373929046)\n1. [How to create a Flowchart end-Node that says \"End\"](https://github.com/mermaid-js/mermaid/issues/1444#issuecomment-639528897)\n","packages/mermaid/src/docs/config/icons.md":"# Registering icon pack in mermaid\n\nThe icon packs available can be found at [icones.js.org](https://icones.js.org/).\nWe use the name defined when registering the icon pack, to override the prefix field of the iconify pack. This allows the user to use shorter names for the icons. It also allows us to load a particular pack only when it is used in a diagram.\n\nUsing JSON file directly from CDN:\n\n```js\nimport mermaid from 'CDN/mermaid.esm.mjs';\nmermaid.registerIconPacks([\n  {\n    name: 'logos',\n    loader: () =>\n      fetch('https://unpkg.com/@iconify-json/logos@1/icons.json').then((res) => res.json()),\n  },\n]);\n```\n\nUsing packages and a bundler:\n\n```bash\nnpm install @iconify-json/logos@1\n```\n\nWith lazy loading\n\n```js\nimport mermaid from 'mermaid';\n\nmermaid.registerIconPacks([\n  {\n    name: 'logos',\n    loader: () => import('@iconify-json/logos').then((module) => module.icons),\n  },\n]);\n```\n\nWithout lazy loading\n\n```js\nimport mermaid from 'mermaid';\nimport { icons } from '@iconify-json/logos';\nmermaid.registerIconPacks([\n  {\n    name: icons.prefix, // To use the prefix defined in the icon pack\n    icons,\n  },\n]);\n```\n","packages/mermaid/src/docs/config/layouts.md":"# Layouts\n\nThis page lists the available layout algorithms supported in Mermaid diagrams.\n\n## ELK is bundled and default from v12.0.0\n\nBefore v12.0.0, ELK shipped as a separate `@mermaid-js/layout-elk` package that\neach site had to install and register. It is now part of `mermaid` itself and\nregistered automatically, so `layout: elk` works with no setup — and it is the\n**default**, replacing Dagre.\n\n`elk` is the new default layout for these diagrams:\n\n- Flowchart\n- State\n- Class\n- Entity relationship\n- Requirement\n- Use case\n- Agentflow\n\nTo go back to the previous layout, use `layout: dagre`.\n\nThe main `mermaid` package always includes ELK. If you want Mermaid without it,\nuse the [tiny build](./usage.md#elk-and-the-tiny-build), which omits ELK along\nwith some diagram types. `@mermaid-js/layout-elk` is still published so the tiny\nbuild can opt back in.\n\n## Supported Layouts\n\n- **elk** (default): [ELK (Eclipse Layout Kernel)](https://www.eclipse.org/elk/). Bundled with Mermaid; no setup required. Specific ELK algorithms can be selected as `elk.stress`, `elk.force`, `elk.mrtree`, `elk.sporeOverlap`, `elk.box`, and `elk.rectpacking`.\n- **dagre**: Dagre layout for layered graphs\n- **cose-bilkent**: Cose Bilkent layout for force-directed graphs\n- **tidy-tree**: Tidy tree layout for hierarchical diagrams, from the [`@mermaid-js/layout-tidy-tree`](https://www.npmjs.com/package/@mermaid-js/layout-tidy-tree) package [Tidy Tree Configuration](/config/tidy-tree)\n\nMindmaps are the one diagram type not laid out with ELK by default; they use\ncose-bilkent unless you ask for something else.\n\nThe **tiny** build omits ELK to stay small, and falls back to Dagre for\ndiagrams that request it. See\n[ELK and the tiny build](./usage.md#elk-and-the-tiny-build) for how to register\n`@mermaid-js/layout-elk` there if you want ELK anyway.\n\n## How to Use\n\nSince `elk` is the default, a diagram needs no configuration to use it. To pick\na different layout, set it in your diagram's YAML config or initialization\noptions. For example:\n\n```mermaid\n---\nconfig:\n  layout: dagre\n---\ngraph TD;\n  A-->B;\n  B-->C;\n```\n","packages/mermaid/src/docs/config/math.md":"# Math Configuration (v10.9.0+)\n\nMermaid supports rendering mathematical expressions through the [KaTeX](https://katex.org/) typesetter.\n\n## Usage\n\nTo render math within a diagram, surround the mathematical expression with the `$$` delimiter.\n\nNote that at the moment, the only supported diagrams are below:\n\n### Flowcharts\n\n```mermaid-example\n graph LR\n      A[\"$$x^2$$\"] -->|\"$$\\sqrt{x+3}$$\"| B(\"$$\\frac{1}{2}$$\")\n      A -->|\"$$\\overbrace{a+b+c}^{\\text{note}}$$\"| C(\"$$\\pi r^2$$\")\n      B --> D(\"$$x = \\begin{cases} a &\\text{if } b \\\\ c &\\text{if } d \\end{cases}$$\")\n      C --> E(\"$$x(t)=c_1\\begin{bmatrix}-\\cos{t}+\\sin{t}\\\\ 2\\cos{t} \\end{bmatrix}e^{2t}$$\")\n```\n\n### Sequence\n\n```mermaid-example\nsequenceDiagram\n    autonumber\n    participant 1 as $$\\alpha$$\n    participant 2 as $$\\beta$$\n    1->>2: Solve: $$\\sqrt{2+2}$$\n    2-->>1: Answer: $$2$$\n    Note right of 2: $$\\sqrt{2+2}=\\sqrt{4}=2$$\n```\n\n## Legacy Support\n\nBy default, MathML is used for rendering mathematical expressions. If you have users on [unsupported browsers](https://caniuse.com/?search=mathml), `legacyMathML` can be set in the config to fall back to CSS rendering. Note that **you must provide KaTeX's stylesheets on your own** as they do not come bundled with Mermaid.\n\nExample with legacy mode enabled (the latest version of KaTeX's stylesheet can be found on their [docs](https://katex.org/docs/browser.html)):\n\n```html\n\n\n\n  \n    \n    \n  \n\n  \n    \n  \n\n```\n\n## Handling Rendering Differences\n\nDue to differences between default fonts across operating systems and browser's MathML implementations, inconsistent results can be seen across platforms. If having consistent results are important, or the most optimal rendered results are desired, `forceLegacyMathML` can be enabled in the config.\n\nThis option will always use KaTeX's stylesheet instead of only when MathML is not supported (as with `legacyMathML`). Note that only `forceLegacyMathML` needs to be set.\n\nIf including KaTeX's stylesheet is not a concern, enabling this option is recommended to avoid scenarios where no MathML implementation within a browser provides the desired output (as seen below).\n\n![Image showing differences between Browsers](img/mathMLDifferences.png)\n","packages/mermaid/src/docs/config/mermaidCLI.md":"# mermaid CLI\n\nmermaid CLI has been moved to [mermaid-cli](https://github.com/mermaid-js/mermaid-cli). Please read its documentation instead.\n","packages/mermaid/src/docs/config/theming.md":"# Theme Configuration\n\nDynamic and integrated theme configuration was introduced in Mermaid version 8.7.0.\n\nThemes can now be customized at the site-wide level, or on individual Mermaid diagrams. For site-wide theme customization, the `initialize` call is used. For diagram specific customization, frontmatter config is used.\n\n## Available Themes\n\n1.  [**redux-color**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-redux-color.js) - The default theme for the diagram types listed under [Per-diagram defaults](#per-diagram-defaults). It pairs the `redux` geometry and typography with a categorical colour palette, so entities, actors, branches, classes, subgraph containers and chart series each get their own colour.\n\n2.  [**redux-dark-color**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-redux-dark-color.js) - The dark counterpart of `redux-color`.\n\n3.  [**redux**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-redux.js) - The same geometry and typography as `redux-color`, but monochrome. Use this when you want the colour to carry meaning you assign yourself rather than being cycled per item.\n\n4.  [**redux-dark**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-redux-dark.js) - The dark counterpart of `redux`.\n\n5.  [**default**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-default.js) - The long-standing Mermaid look, and still the default for every diagram type not listed under [Per-diagram defaults](#per-diagram-defaults).\n\n6.  [**neutral**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-neutral.js) - This theme is great for black-and-white documents that will be printed.\n\n7.  [**dark**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-dark.js) - This theme goes well with dark-colored elements or dark-mode. To use the dark theme (which changes the theme of the schema itself) with dark-mode (which sets the background), set `darkMode` to `true` in your config.\n\n8.  [**forest**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-forest.js) - This theme contains shades of green.\n\n9.  [**neo**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-neo.js) - A flatter, softer look, intended to be paired with `look: neo`.\n\n10. [**neo-dark**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-neo-dark.js) - The dark counterpart of `neo`.\n\n11. [**base**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-base.js) - This is the only theme that can be modified. Use this theme as the base for customizations.\n\n## Per-diagram defaults\n\nNot every diagram type defaults to the same theme and look. Since v12.0.0\nthese do, to the `redux-color` theme and the `neo` look. The name on the left is the **config key** — what you write to\nscope a setting to that diagram, which is not always the keyword the diagram starts with:\n\n| Config key    | Diagram              |\n| ------------- | -------------------- |\n| `agentflow`   | `agentflow-beta`     |\n| `flowchart`   | `flowchart`          |\n| `swimlane`    | `swimlane-beta`      |\n| `class`       | `classDiagram`       |\n| `er`          | `erDiagram`          |\n| `requirement` | `requirementDiagram` |\n| `sequence`    | `sequenceDiagram`    |\n| `state`       | `stateDiagram`       |\n| `usecase`     | `usecase-beta`       |\n| `venn`        | `venn-beta`          |\n\nEvery other diagram type defaults to the `default` theme and the `classic` look.\n\n`layout` works the same way. Only `swimlane` overrides it, to `swimlane`; everything else\nuses the global default, `dagre`.\n\nThese are only defaults, and the most specific thing you say wins. Highest priority first:\n\n1.  The diagram's own frontmatter or `%%{init}%%` directive.\n2.  What you passed to `mermaid.initialize()`.\n3.  The diagram type's default, above.\n4.  The global default (`theme: default`, `look: classic`, `layout: dagre`).\n\nA layout that is not registered in the running build falls back to `dagre`, with a warning\nin the console. `elk` ships as a separate package you register yourself, and `cose-bilkent`\nis only bundled into builds that include the large features, so naming either as a default\ndoes not require every build to carry it.\n\nWithin each of the first two you can also scope a value to one diagram type, and the\nscoped value wins over the global one you set alongside it. `theme`, `look` and `layout`\ncan all be set this way:\n\n```javascript\nmermaid.initialize({\n  look: 'classic', // everything is classic...\n  flowchart: { look: 'handDrawn' }, // ...except flowcharts\n  er: { theme: 'neutral' },\n});\n```\n\nThe same works in frontmatter, for one diagram:\n\n```yaml\n---\nconfig:\n  flowchart:\n    look: handDrawn\n---\n```\n\n### Going back to the previous appearance\n\nThe nine types above changed appearance when these became their defaults. To draw one the\nway Mermaid drew it before, name the previous theme and look in its front matter:\n\n```yaml\n---\nconfig:\n  theme: default\n  look: classic\n---\n```\n\nFor every diagram on a page, pass the same two keys to `mermaid.initialize()`:\n\n```javascript\nmermaid.initialize({ theme: 'default', look: 'classic' });\n```\n\n## Site-wide Theme\n\nTo customize themes site-wide, call the `initialize` method on the `mermaid`.\n\nExample of `initialize` call setting `theme` to `base`:\n\n```javascript\nmermaid.initialize({\n  securityLevel: 'loose',\n  theme: 'base',\n});\n```\n\n## Diagram-specific Themes\n\nTo customize the theme of an individual diagram, use frontmatter config.\n\nExample of frontmatter config setting the `theme` to `forest`:\n\n```mermaid-example\n---\nconfig:\n  theme: 'forest'\n---\n  graph TD\n    a --> b\n```\n\n> **Reminder**: the only theme that can be customized is the `base` theme. The following section covers how to use `themeVariables` for customizations.\n\n## Customizing Themes with `themeVariables`\n\nTo make a custom theme, modify `themeVariables` via frontmatter config.\n\nYou will need to use the [base](#available-themes) theme as it is the only modifiable theme.\n\n| Parameter      | Description                        | Type   | Properties                                                                          |\n| -------------- | ---------------------------------- | ------ | ----------------------------------------------------------------------------------- |\n| themeVariables | Modifiable with frontmatter config | Object | `primaryColor`, `primaryTextColor`, `lineColor` ([see full list](#theme-variables)) |\n\nExample of modifying `themeVariables` using frontmatter config:\n\n```mermaid-example\n---\nconfig:\n  theme: 'base'\n  themeVariables:\n    primaryColor: '#BB2528'\n    primaryTextColor: '#fff'\n    primaryBorderColor: '#7C0000'\n    lineColor: '#F8B229'\n    secondaryColor: '#006100'\n    tertiaryColor: '#fff'\n---\n        graph TD\n          A[Christmas] -->|Get money| B(Go shopping)\n          B --> C{Let me think}\n          B --> G[/Another/]\n          C ==>|One| D[Laptop]\n          C -->|Two| E[iPhone]\n          C -->|Three| F[fa:fa-car Car]\n          subgraph section\n            C\n            D\n            E\n            F\n            G\n          end\n```\n\n## Color and Color Calculation\n\nTo ensure diagram readability, the default value of certain variables is calculated or derived from other variables. For example, `primaryBorderColor` is derived from the `primaryColor` variable. So if the `primaryColor` variable is customized, Mermaid will adjust `primaryBorderColor` automatically. Adjustments can mean a color inversion, a hue change, a darkening/lightening by 10%, etc.\n\nThe theming engine will only recognize hex colors and not color names. So, the value `#ff0000` will work, but `red` will not.\n\n## Theme Variables\n\n| Variable             | Default value                      | Description                                                                                                                      |\n| -------------------- | ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |\n| darkMode             | false                              | Affects how derived colors are calculated. Set value to `true` for dark mode.                                                    |\n| background           | #f4f4f4                            | Used to calculate color for items that should either be background colored or contrasting to the background                      |\n| fontFamily           | trebuchet ms, verdana, arial       | Font family for diagram text                                                                                                     |\n| fontSize             | 16px                               | Font size in pixels                                                                                                              |\n| primaryColor         | #fff4dd                            | Color to be used as background in nodes, other colors will be derived from this                                                  |\n| primaryTextColor     | calculated from darkMode #ddd/#333 | Color to be used as text color in nodes using `primaryColor`                                                                     |\n| secondaryColor       | calculated from primaryColor       |                                                                                                                                  |\n| primaryBorderColor   | calculated from primaryColor       | Color to be used as border in nodes using `primaryColor`                                                                         |\n| secondaryBorderColor | calculated from secondaryColor     | Color to be used as border in nodes using `secondaryColor`                                                                       |\n| secondaryTextColor   | calculated from secondaryColor     | Color to be used as text color in nodes using `secondaryColor`                                                                   |\n| tertiaryColor        | calculated from primaryColor       |                                                                                                                                  |\n| tertiaryBorderColor  | calculated from tertiaryColor      | Color to be used as border in nodes using `tertiaryColor`                                                                        |\n| tertiaryTextColor    | calculated from tertiaryColor      | Color to be used as text color in nodes using `tertiaryColor`                                                                    |\n| noteBkgColor         | #fff5ad                            | Color used as background in notes                                                                                                |\n| noteTextColor        | #333                               | Text color in note rectangles                                                                                                    |\n| noteBorderColor      | calculated from noteBkgColor       | Border color in note rectangles                                                                                                  |\n| lineColor            | calculated from background         |                                                                                                                                  |\n| textColor            | calculated from primaryTextColor   | Text in diagram over the background for instance text on labels and on signals in sequence diagram or the title in Gantt diagram |\n| mainBkg              | calculated from primaryColor       | Background in flowchart objects like rects/circles, class diagram classes, sequence diagram etc                                  |\n| errorBkgColor        | tertiaryColor                      | Color for syntax error message                                                                                                   |\n| errorTextColor       | tertiaryTextColor                  | Color for syntax error message                                                                                                   |\n\n## Flowchart Variables\n\n| Variable            | Default value                  | Description                 |\n| ------------------- | ------------------------------ | --------------------------- |\n| nodeBorder          | primaryBorderColor             | Node Border Color           |\n| clusterBkg          | tertiaryColor                  | Background in subgraphs     |\n| clusterBorder       | tertiaryBorderColor            | Cluster Border Color        |\n| defaultLinkColor    | lineColor                      | Link Color                  |\n| titleColor          | tertiaryTextColor              | Title Color                 |\n| edgeLabelBackground | calculated from secondaryColor |                             |\n| nodeTextColor       | primaryTextColor               | Color for text inside Nodes |\n\n## Sequence Diagram Variables\n\n| Variable              | Default value                  | Description                 |\n| --------------------- | ------------------------------ | --------------------------- |\n| actorBkg              | mainBkg                        | Actor Background Color      |\n| actorBorder           | primaryBorderColor             | Actor Border Color          |\n| actorTextColor        | primaryTextColor               | Actor Text Color            |\n| actorLineColor        | actorBorder                    | Actor Line Color            |\n| signalColor           | textColor                      | Signal Color                |\n| signalTextColor       | textColor                      | Signal Text Color           |\n| labelBoxBkgColor      | actorBkg                       | Label Box Background Color  |\n| labelBoxBorderColor   | actorBorder                    | Label Box Border Color      |\n| labelTextColor        | actorTextColor                 | Label Text Color            |\n| loopTextColor         | actorTextColor                 | Loop Text Color             |\n| activationBorderColor | calculated from secondaryColor | Activation Border Color     |\n| activationBkgColor    | secondaryColor                 | Activation Background Color |\n| sequenceNumberColor   | calculated from lineColor      | Sequence Number Color       |\n\n## Pie Diagram Variables\n\n| Variable            | Default value                  | Description                                |\n| ------------------- | ------------------------------ | ------------------------------------------ |\n| pie1                | primaryColor                   | Fill for 1st section in pie diagram        |\n| pie2                | secondaryColor                 | Fill for 2nd section in pie diagram        |\n| pie3                | calculated from tertiary       | Fill for 3rd section in pie diagram        |\n| pie4                | calculated from primaryColor   | Fill for 4th section in pie diagram        |\n| pie5                | calculated from secondaryColor | Fill for 5th section in pie diagram        |\n| pie6                | calculated from tertiaryColor  | Fill for 6th section in pie diagram        |\n| pie7                | calculated from primaryColor   | Fill for 7th section in pie diagram        |\n| pie8                | calculated from primaryColor   | Fill for 8th section in pie diagram        |\n| pie9                | calculated from primaryColor   | Fill for 9th section in pie diagram        |\n| pie10               | calculated from primaryColor   | Fill for 10th section in pie diagram       |\n| pie11               | calculated from primaryColor   | Fill for 11th section in pie diagram       |\n| pie12               | calculated from primaryColor   | Fill for 12th section in pie diagram       |\n| pieTitleTextSize    | 25px                           | Title text size                            |\n| pieTitleTextColor   | taskTextDarkColor              | Title text color                           |\n| pieSectionTextSize  | 17px                           | Text size of individual section labels     |\n| pieSectionTextColor | textColor                      | Text color of individual section labels    |\n| pieLegendTextSize   | 17px                           | Text size of labels in diagram legend      |\n| pieLegendTextColor  | taskTextDarkColor              | Text color of labels in diagram legend     |\n| pieStrokeColor      | black                          | Border color of individual pie sections    |\n| pieStrokeWidth      | 2px                            | Border width of individual pie sections    |\n| pieOuterStrokeWidth | 2px                            | Border width of pie diagram's outer circle |\n| pieOuterStrokeColor | black                          | Border color of pie diagram's outer circle |\n| pieOpacity          | 0.7                            | Opacity of individual pie sections         |\n\n## State Colors\n\n| Variable      | Default value    | Description                                  |\n| ------------- | ---------------- | -------------------------------------------- |\n| labelColor    | primaryTextColor |                                              |\n| altBackground | tertiaryColor    | Used for background in deep composite states |\n\n## Class Colors\n\n| Variable  | Default value | Description                     |\n| --------- | ------------- | ------------------------------- |\n| classText | textColor     | Color of Text in class diagrams |\n\n## User Journey Colors\n\n| Variable  | Default value                  | Description                             |\n| --------- | ------------------------------ | --------------------------------------- |\n| fillType0 | primaryColor                   | Fill for 1st section in journey diagram |\n| fillType1 | secondaryColor                 | Fill for 2nd section in journey diagram |\n| fillType2 | calculated from primaryColor   | Fill for 3rd section in journey diagram |\n| fillType3 | calculated from secondaryColor | Fill for 4th section in journey diagram |\n| fillType4 | calculated from primaryColor   | Fill for 5th section in journey diagram |\n| fillType5 | calculated from secondaryColor | Fill for 6th section in journey diagram |\n| fillType6 | calculated from primaryColor   | Fill for 7th section in journey diagram |\n| fillType7 | calculated from secondaryColor | Fill for 8th section in journey diagram |\n","packages/mermaid/src/docs/config/tidy-tree.md":"# Tidy-tree Layout\n\nThe **tidy-tree** layout arranges nodes in a hierarchical, tree-like structure. It is especially useful for diagrams where parent-child relationships are important, such as mindmaps.\n\n## Features\n\n- Organizes nodes in a tidy, non-overlapping tree\n- Ideal for mindmaps and hierarchical data\n- Automatically adjusts spacing for readability\n\n## Example Usage\n\n```mermaid-example\n---\nconfig:\n  layout: tidy-tree\n---\nmindmap\nroot((mindmap is a long thing))\n  A\n  B\n  C\n  D\n```\n\n```mermaid-example\n---\nconfig:\n  layout: tidy-tree\n---\nmindmap\nroot((mindmap))\n    Origins\n      Long history\n      ::icon(fa fa-book)\n      Popularisation\n        British popular psychology author Tony Buzan\n    Research\n      On effectiveness
and features\n      On Automatic creation\n        Uses\n            Creative techniques\n            Strategic planning\n            Argument mapping\n```\n\n## Note\n\n- Currently, tidy-tree is primarily supported for mindmap diagrams.\n","packages/mermaid/src/docs/config/usage.md":"# Usage\n\nMermaid is a JavaScript tool that makes use of a Markdown based syntax to render customizable diagrams, charts and visualizations.\n\nDiagrams can be re-rendered/modified by modifying their descriptions.\n\n### CDN\n\n[https://www.jsdelivr.com/package/npm/mermaid](https://www.jsdelivr.com/package/npm/mermaid)\n\nPlease note that you can switch versions through the dropdown box at the top right.\n\n## Using mermaid\n\nFor the majority of users, Using the [Live Editor](https://mermaid.live/) would be sufficient, however you may also opt to deploy mermaid as a dependency or using the [Mermaid API](./setup/README.md).\n\nWe have compiled some Video [Tutorials](../ecosystem/tutorials.md) on how to use the Mermaid Live Editor.\n\n### Installing and Hosting Mermaid on a Webpage\n\n**Using the npm package:**\n\nRequirements:\n\n- Node.js >= 22.12.0\n\n### Supported browsers and runtimes\n\nMermaid v12.0.0+'s published bundles target ES2024 and are aimed to support Safari 17.4 or later.\n\nWe run linting for Chromium 121 and Firefox 123 support as well, but unlike Safari 17.4, we don't commit to supporting these outdated versions.\n\nOlder browsers may work too, or you may need to polyfill/transpile mermaid to support them.\n\n```bash\n# NPM\nnpm install mermaid\n# Yarn\nyarn add mermaid\n# PNPM\npnpm add mermaid\n```\n\n**Hosting mermaid on a web page:**\n\n> Note: This topic is explored in greater depth in the [User Guide for Beginners](../intro/getting-started.md)\n\nThe easiest way to integrate mermaid on a web page requires two elements:\n\n- A graph definition, inside `
` tags labeled `class=mermaid`.\n\nExample:\n\n```html\n
\n    graph LR\n    A --- B\n    B-->C[fa:fa-ban forbidden]\n    B-->D(fa:fa-spinner);\n
\n```\n\n- The mermaid js script. Added using a `script` tag as an ESM import.\n\nExample:\n\n```html\n\n```\n\n**Following these directions, mermaid starts at page load and (when the page has loaded) it will locate the graph definitions inside the `pre` tags with `class=\"mermaid\"` and return diagrams in SVG form, following given definitions.**\n\n### Fonts\n\nMermaid currently uses a few different default `fontFamily` settings, based on\nthe diagram type and the given theme.\n\nThe current preferred fonts are:\n\n- Recursive Variable (open-source font, since v11.15.0)\n- Open Sans (open-source font)\n- Arial ([Restrictive License](https://en.wikipedia.org/wiki/TrueType_core_fonts_for_the_Web))\n- Trebuchet MS ([Restrictive License](https://en.wikipedia.org/wiki/TrueType_core_fonts_for_the_Web))\n\nFor a consistent look, we recommend you supply these as web fonts, when possible,\ne.g. like:\n\n```html\n/@fontsource/open-sans@5/400.css\" />\n/@fontsource/open-sans@5/400-italic.css\" />\n/@fontsource-variable/recursive@5/index.css\" />\n```\n\n## Simple full example:\n\n```html\n\n\n  /@fontsource/open-sans@5/400.css\" />\n  /@fontsource/open-sans@5/400-italic.css\" />\n  /@fontsource-variable/recursive@5/index.css\" />\n\n\n  \n    
\n  graph LR\n      A --- B\n      B-->C[fa:fa-ban forbidden]\n      B-->D(fa:fa-spinner);\n    
\n    \n  \n\n```\n\n## Notes:\n\nAn id attribute is also added to mermaid tags without one.\n\nMermaid can load multiple diagrams, in the same page.\n\n> Try it out, save this code as HTML and load it using any browser.\n> (Except Internet Explorer, please don't use Internet Explorer.)\n\n## Tiny Mermaid\n\nWe offer a smaller version of Mermaid that's approximately half the size of the full library. This tiny version doesn't include Mindmap Diagrams, Architecture Diagrams, KaTeX rendering, lazy loading, or the ELK layout engine.\n\nIf you need a more lightweight version without these features, you can use [Mermaid Tiny](https://github.com/mermaid-js/mermaid/tree/develop/packages/tiny).\n\n### ELK and the tiny build\n\nThe tiny build has never included ELK, and still doesn't — it is a large dependency and staying small is the point of that build. Diagrams that ask for an ELK layout here fall back to Dagre and still render; nothing breaks, they are simply laid out by Dagre.\n\nWhat changed in v12.0.0 is the main package, not this one: ELK used to be an opt-in `@mermaid-js/layout-elk` install, and is now bundled with `mermaid` and used by default. So **if you want a Mermaid without ELK, the tiny build is the way to get one** — it is no longer simply a matter of not installing the layout package.\n\nIf you want the tiny build _and_ ELK, register `@mermaid-js/layout-elk` alongside it. That package continues to be published for exactly this case:\n\n```html\n\n\n```\n\nRegistering the package also makes the named ELK algorithms available — `elk.stress`, `elk.force`, `elk.mrtree`, `elk.sporeOverlap`, `elk.box` and `elk.rectpacking`. On a normal `mermaid` build you do not need this package at all: registering it is harmless but redundant, since the same layouts are already built in.\n\n## Enabling Click Event and Tags in Nodes\n\nA `securityLevel` configuration has to first be cleared. `securityLevel` sets the level of trust for the parsed diagrams and limits click functionality. This was introduced in version 8.2 as a security improvement, aimed at preventing malicious use.\n\n**It is the site owner's responsibility to discriminate between trustworthy and untrustworthy user-bases and we encourage the use of discretion.**\n\n## securityLevel\n\n| Parameter     | Description                       | Type   | Required | Values                                     |\n| ------------- | --------------------------------- | ------ | -------- | ------------------------------------------ |\n| securityLevel | Level of trust for parsed diagram | String | Optional | 'sandbox', 'strict', 'loose', 'antiscript' |\n\nValues:\n\n- **strict**: (**default**) HTML tags in the text are encoded and click functionality is disabled.\n- **antiscript**: HTML tags in text are allowed (only script elements are removed) and click functionality is enabled.\n- **loose**: HTML tags in text are allowed and click functionality is enabled.\n- **sandbox**: With this security level, all rendering takes place in a sandboxed iframe. This prevents any JavaScript from running in the context. This may hinder interactive functionality of the diagram, like scripts, popups in the sequence diagram, links to other tabs or targets, etc.\n\n```note\nThis changes the default behaviour of mermaid so that after upgrade to 8.2, unless the `securityLevel` is not changed, tags in flowcharts are encoded as tags and clicking is disabled.\n**sandbox** security level is still in the beta version.\n```\n\n**If you are taking responsibility for the diagram source security you can set the `securityLevel` to a value of your choosing. This allows clicks and tags are allowed.**\n\n**To change `securityLevel`, you have to call `mermaid.initialize`:**\n\n```javascript\nmermaid.initialize({\n  securityLevel: 'loose',\n});\n```\n\n### Labels out of bounds\n\nIf you use dynamically loaded fonts that are loaded through CSS, such as fonts, mermaid should wait for the whole page to load (dom + assets, particularly the fonts file).\n\n```javascript\n$(document).ready(function () {\n  mermaid.initialize();\n});\n```\n\nNot doing so will most likely result in mermaid rendering graphs that have labels out of bounds. The default integration in mermaid uses the window.load event to start rendering.\n\nIf your page has other fonts in its body those might be used instead of the mermaid font. Specifying the font in your styling is a workaround for this.\n\n```css\npre.mermaid {\n  font-family: 'trebuchet ms', verdana, arial;\n}\n```\n\n### Using `mermaid.run`\n\nmermaid.run was added in v10 and is the preferred way of handling more complex integration.\nBy default, `mermaid.run` will be called when the document is ready, rendering all elements with `class=\"mermaid\"`.\n\nYou can customize that behavior by calling `await mermaid.run()`.\n\n`mermaid.initialize({startOnLoad: false})` will prevent `mermaid.run` from being called automatically after load.\n\nRender all elements with querySelector \".someOtherClass\"\n\n```js\nmermaid.initialize({ startOnLoad: false });\nawait mermaid.run({\n  querySelector: '.someOtherClass',\n});\n```\n\nRender all elements passed as an array\n\n```js\nmermaid.initialize({ startOnLoad: false });\nawait mermaid.run({\n  nodes: [document.getElementById('someId'), document.getElementById('anotherId')],\n});\nawait mermaid.run({\n  nodes: document.querySelectorAll('.yetAnotherClass'),\n});\n```\n\nRender all `.mermaid` elements while suppressing any error\n\n```js\nmermaid.initialize({ startOnLoad: false });\nawait mermaid.run({\n  suppressErrors: true,\n});\n```\n\n### Calling `mermaid.init` - Deprecated\n\n```warning\nmermaid.init is deprecated in v10 and will be removed in a future release. Please use mermaid.run instead.\n```\n\nBy default, `mermaid.init` will be called when the document is ready, finding all elements with\n`class=\"mermaid\"`. If you are adding content after mermaid is loaded, or otherwise need\nfiner-grained control of this behavior, you can call `init` yourself with:\n\n- a configuration object\n- some nodes, as\n  - a node\n  - an array-like of nodes\n  - or W3C selector that will find your nodes\n\nExample:\n\n```javascript\nmermaid.init({ noteMargin: 10 }, '.someOtherClass');\n```\n\nOr with no config object, and a jQuery selection:\n\n```javascript\nmermaid.init(undefined, $('#someId .yetAnotherClass'));\n```\n\n## Usage with webpack\n\nmermaid fully supports webpack. Here is a [working demo](https://github.com/mermaidjs/mermaid-webpack-demo).\n\n## API usage\n\nThe main idea of the API is to be able to call a render function with the graph definition as a string. The render function will render the graph and call a callback with the resulting SVG code. With this approach it is up to the site creator to fetch the graph definition from the site (perhaps from a textarea), render it and place the graph somewhere in the site.\n\nThe example below shows an example of how this could be used. The example just logs the resulting SVG to the JavaScript console.\n\n```html\n\n```\n\nTo determine the type of diagram present in a given text, you can utilize the `mermaid.detectType` function, as demonstrated in the example below.\n\n```html\n\n```\n\n### Binding events\n\nSometimes the generated graph also has defined interactions like tooltip and click events. When using the API one must\nadd those events after the graph has been inserted into the DOM.\n\nThe example code below is an extract of what mermaid does when using the API. The example shows how it is possible to\nbind events to an SVG when using the API for rendering.\n\n```javascript\n// Example of using the bindFunctions\nconst drawDiagram = async function () {\n  element = document.querySelector('#graphDiv');\n  const graphDefinition = 'graph TB\\na-->b';\n  const { svg, bindFunctions } = await mermaid.render('graphDiv', graphDefinition);\n  element.innerHTML = svg;\n  // This can also be written as `bindFunctions?.(element);` using the `?` shorthand.\n  if (bindFunctions) {\n    bindFunctions(element);\n  }\n};\n```\n\n1. The graph is generated using the render call.\n2. After generation the render function calls the provided callback function, in this case it's called insertSvg.\n3. The callback function is called with two parameters, the SVG code of the generated graph and a function. This function binds events to the SVG **after** it is inserted into the DOM.\n4. Insert the SVG code into the DOM for presentation.\n5. Call the binding function that binds the events.\n\n## Example of a marked renderer\n\nThis is the renderer used for transforming the documentation from Markdown to html with mermaid diagrams in the html.\n\n```javascript\nconst renderer = new marked.Renderer();\nrenderer.code = function (code, language) {\n  if (code.match(/^sequenceDiagram/) || code.match(/^graph/)) {\n    return '
' + code + '
';\n  } else {\n    return '
' + code + '
';\n  }\n};\n```\n\nAnother example in CoffeeScript that also includes the mermaid script tag in the generated markup.\n\n```coffee\nmarked = require 'marked'\n\nmodule.exports = (options) ->\n  hasMermaid = false\n  renderer = new marked.Renderer()\n  renderer.defaultCode = renderer.code\n  renderer.code = (code, language) ->\n    if language is 'mermaid'\n      html = ''\n      if not hasMermaid\n        hasMermaid = true\n        html += ''\n      html + '
'+code+'
'\n    else\n      @defaultCode(code, language)\n\n  renderer\n```\n\n## Advanced usage\n\n### Syntax validation without rendering\n\nThe `mermaid.parse(text, parseOptions)` function validates graph definitions without rendering a graph.\n\nThe function `mermaid.parse(text, parseOptions)`, takes a text string as an argument and returns `{ diagramType: string }` if the definition follows mermaid's syntax.\n\nIf the definition is invalid, the function returns `false` if `parseOptions.suppressErrors` is set to `true`. Otherwise, it throws an error.\n\nThe parseError function will be called when the parse function throws an error. It will not be called if `parseOptions.suppressErrors` is set to `true`.\n\nIt is possible to override this function in order to handle the error in an application-specific way.\n\nThe code-example below in meta code illustrates how this could work:\n\n```javascript\nmermaid.parseError = function (err, hash) {\n  displayErrorInGui(err);\n};\n\nconst textFieldUpdated = async function () {\n  const textStr = getTextFromFormField('code');\n\n  if (await mermaid.parse(textStr)) {\n    reRender(textStr);\n  }\n};\n\nbindEventHandler('change', 'code', textFieldUpdated);\n```\n\n## Configuration\n\nYou can pass the required configuration to the `mermaid.initialize` call. This is the preferred way of configuring mermaid.\nThe list of configuration objects are described [in the mermaidAPI documentation](./setup/README.md).\n\n```html\n\n```\n\n```note\nThis is the preferred way of configuring mermaid.\n```\n\n### The following methods are deprecated and are kept only for backwards compatibility.\n\n## Using the mermaid object\n\nIt is possible to set some configuration via the mermaid object. The two parameters that are supported using this\napproach are:\n\n- mermaid.startOnLoad\n- mermaid.htmlLabels\n\n```javascript\nmermaid.startOnLoad = true;\n```\n\n```warning\nThis way of setting the configuration is deprecated. Instead the preferred way is to use the initialize method. This functionality is only kept for backwards compatibility.\n```\n\n\n","packages/mermaid/src/docs/ecosystem/integrations-community.md":"# Integrations\n\n## Official integration\n\n### Mermaid Chart\n\nMermaid Chart is built by the team behind Mermaid JS.\n\nFor more details, visit the [Mermaid Chart page](./mermaid-chart.md), or visit the [Mermaid Chart website](https://mermaid.ai) .\n\n## Community integrations\n\nWe're excited about the growth of the Mermaid community, and the number of plugins and integrations that have been created by the community.\n\nSee the list below of community plugins and integrations created with Mermaid.\n\n```note\nA ✅ indicates Native support for Mermaid on the respective platform.\n```\n\nTo add an integration to this list, see the [Integrations - create page](./integrations-create.md).\n\n### Productivity tools\n\n- [Atlassian Products](https://www.atlassian.com)\n  - [Mermaid for Confluence](https://marketplace.atlassian.com/apps/1224722/mermaid-for-confluence?hosting=cloud&tab=overview)\n  - [Mermaid Integration for Confluence](https://marketplace.atlassian.com/apps/1222792/mermaid-integration-for-confluence?hosting=cloud&tab=overview)\n  - [Mermaid Charts & Diagrams for Confluence](https://marketplace.atlassian.com/apps/1222572/)\n  - [Mermaid Diagrams for Confluence](https://marketplace.atlassian.com/apps/1226945/mermaid-diagrams-for-confluence?hosting=cloud&tab=overview)\n  - [Mermaid Live Editor for Confluence Cloud](https://marketplace.atlassian.com/apps/1231571/mermaid-live-editor-for-confluence?hosting=cloud&tab=overview)\n  - [Mermaid Macro for Confluence](https://marketplace.atlassian.com/apps/1231150/mermaid-macro-for-confluence?hosting=cloud&tab=overview)\n  - [Mermaid Plugin for Confluence](https://marketplace.atlassian.com/apps/1214124/mermaid-plugin-for-confluence?hosting=server&tab=overview)\n  - [EliteSoft Mermaid Charts and Diagrams](https://marketplace.atlassian.com/apps/1227286/elitesoft-mermaid-charts-and-diagrams?hosting=cloud&tab=overview)\n  - [Auto convert diagrams in Jira](https://github.com/coddingtonbear/jirafs-mermaid)\n  - [Mermaid Charts & Diagrams for Jira](https://marketplace.atlassian.com/apps/1224537/)\n  - [Mermaid for Jira Cloud - Draw UML diagrams easily](https://marketplace.atlassian.com/apps/1223053/mermaid-for-jira-cloud-draw-uml-diagrams-easily?hosting=cloud&tab=overview)\n  - [CloudScript.io Mermaid Addon](https://marketplace.atlassian.com/apps/1219878/cloudscript-io-mermaid-addon?hosting=cloud&tab=overview)\n  - [Mermaid plus for Confluence](https://marketplace.atlassian.com/apps/1236814/mermaid-plus-for-confluence?hosting=cloud&tab=overview)\n- [Azure Devops](https://learn.microsoft.com/en-us/azure/devops/project/wiki/markdown-guidance?view=azure-devops#add-mermaid-diagrams-to-a-wiki-page) ✅\n- [Deepdwn](https://billiam.itch.io/deepdwn) ✅\n- [Doctave](https://www.doctave.com/) ✅\n  - [Mermaid in Markdown code blocks](https://docs.doctave.com/components/mermaid) ✅\n- [Forgejo](https://forgejo.org/) ✅\n- [GitBook](https://gitbook.com)\n  - [Mermaid Plugin](https://github.com/JozoVilcek/gitbook-plugin-mermaid)\n  - [Markdown with Mermaid CLI](https://github.com/miao1007/gitbook-plugin-mermaid-cli)\n- [Gitea](https://gitea.io) ✅\n- [GitHub](https://github.com) ✅\n  - [Using code blocks](https://github.blog/2022-02-14-include-diagrams-markdown-files-mermaid/) ✅\n  - [GitHub action: Compile mermaid to image](https://github.com/neenjaw/compile-mermaid-markdown-action)\n  - [GitHub Writer](https://github.com/ckeditor/github-writer)\n  - [SVG diagram generator](https://github.com/SimonKenyonShepard/mermaidjs-github-svg-generator)\n- [GitLab](https://docs.gitlab.com/ee/user/markdown.html#diagrams-and-flowcharts) ✅\n- [GNU Octave](https://octave.org/) ✅\n  - [octave_mermaid_js](https://github.com/CNOCTAVE/octave_mermaid_js) ✅\n- [HackMD](https://hackmd.io/c/tutorials/%2F%40docs%2Fflowchart-en#Create-more-complex-flowcharts) ✅\n- [JetBrains IDEs](https://www.jetbrains.com)\n  - [Mermaid Plugin](https://plugins.jetbrains.com/plugin/20146-mermaid)\n  - [Mermaid Studio](https://plugins.jetbrains.com/plugin/29870-mermaid-studio)\n- [MonsterWriter](https://www.monsterwriter.com/) ✅\n- [Joplin](https://joplinapp.org) ✅\n- [LiveBook](https://livebook.dev) ✅\n- [Slidev](https://sli.dev) ✅\n- [Tuleap](https://docs.tuleap.org/user-guide/writing-in-tuleap.html#graphs) ✅\n- [Mermaid Flow Visual Editor](https://www.mermaidflow.app) ✅\n- [Mermaid Studio by webtoolz](https://webtoolz.dev/mermaid) - Browser-based Mermaid editor with live preview, curated themes, and PNG/SVG export\n- [Mermerd](https://github.com/KarnerTh/mermerd)\n- [Slab](https://slab.com) ✅\n- [Swimm](https://docs.swimm.io/features/diagrams-and-charts) ✅\n- [NotesHub](https://noteshub.app) ✅\n- [Notion](https://notion.so) ✅\n- [Observable](https://observablehq.com/@observablehq/mermaid) ✅\n- [Obsidian](https://help.obsidian.md/Editing+and+formatting/Advanced+formatting+syntax#Diagram) ✅\n- [Outline](https://docs.getoutline.com/s/guide/doc/diagrams-KQiKoT4wzK) ✅\n- [Redmine](https://redmine.org)\n  - [Mermaid Macro](https://redmine.org/plugins/redmine_mermaid_macro)\n  - [Markdown for mermaid plugin](https://github.com/jamieh-mongolian/markdown-for-mermaid-plugin)\n  - [redmine-mermaid](https://github.com/styz/redmine_mermaid)\n- Visual Studio Code [Polyglot Interactive Notebooks](https://github.com/dotnet/interactive#net-interactive)\n- [Microsoft Loop](https://loop.cloud.microsoft) ✅\n\n### LLM integrations\n\nLLM integrations to create mermaid diagrams using AI from text descriptions.\n\n- [HueHive - Create mermaid diagrams with text](https://huehive.co/tools/diagrams)\n- [MCP Server Mermaid](https://github.com/hustcc/mcp-mermaid) - Generate mermaid diagram and chart with AI MCP dynamically.\n- [Mermaid Studio](https://mermaidstudio.dev) - Leverage Mermaid Studio's code intelligence and diagram generation capabilities via MCP to create high-quality diagrams (requires a [JetBrains IDE](https://jetbrains.com/ides)) using your favorite coding agent.\n\n### CRM/ERP\n\nCustomer Relationship Management/Enterprise Resource Planning\n\n- [coreBOS](https://blog.corebos.org/blog/december2019)\n\n### Blogging\n\nBlogging frameworks and platforms\n\n- [Hexo](https://hexo.io)\n  - [hexo-filter-mermaid-diagrams](https://github.com/webappdevelp/hexo-filter-mermaid-diagrams)\n  - [hexo-tag-mermaid](https://github.com/JameChou/hexo-tag-mermaid)\n  - [hexo-mermaid-diagrams](https://github.com/mslxl/hexo-mermaid-diagrams)\n- [Nextra](https://nextra.site/)\n  - [Mermaid](https://nextra.site/docs/guide/mermaid)\n- [WordPress](https://wordpress.org)\n  - [MerPRess](https://wordpress.org/plugins/merpress/)\n  - [WP Documentation](https://wordpress.org/themes/wp-documentation/)\n\n### CMS/ECM\n\nContent Management Systems/Enterprise Content Management\n\n- [ApostropheCMS](https://apostrophecms.com/)\n  - [Extension for Mermaid.js](https://github.com/BoDonkey/mermaid-extension)\n- [Drupal](https://drupal.org/)\n  - [Mermaid Diagram Field module](https://www.drupal.org/project/mermaid_diagram_field)\n- [Grav CMS](https://getgrav.org/)\n  - [Mermaid Diagrams Plugin](https://github.com/DanielFlaum/grav-plugin-mermaid-diagrams)\n  - [GitLab Markdown Adapter](https://github.com/Goutte/grav-plugin-gitlab-markdown-adapter)\n- [Tiki Wiki CMS Groupware](https://tiki.org)\n  - [Tracker Entity Relationship Diagram](https://doc.tiki.org/Tracker-Entity-Relationship-Diagram)\n- [VitePress](https://vitepress.vuejs.org/)\n  - [Plugin for Mermaid.js](https://emersonbottero.github.io/vitepress-plugin-mermaid/)\n- [VuePress](https://vuepress.vuejs.org/)\n  - [Plugin for Mermaid.js](https://github.com/eFrane/vuepress-plugin-mermaidjs)\n\n### Communication\n\nCommunication tools and platforms\n\n- [Discourse](https://discourse.org)\n  - [Mermaid Plugin](https://github.com/pnewell/discourse-mermaid)\n- [Mattermost](https://mattermost.com/)\n  - [Mermaid Plugin](https://github.com/SpikeTings/Mermaid)\n- [NodeBB](https://nodebb.org)\n  - [Mermaid Parser Plugin](https://www.npmjs.com/package/nodebb-plugin-mermaid)\n- [phpBB](https://phpbb.com)\n  - [phpbb-ext-mermaid](https://github.com/AlfredoRamos/phpbb-ext-mermaid)\n- [Slack](https://slack.com)\n  - [Mermaid Preview](https://mermaid-preview.com)\n\n### Wikis\n\n- [DokuWiki](https://dokuwiki.org)\n  - [ComboStrap](https://combostrap.com/utility/create-diagram-with-mermaid-vh3ab9yj)\n  - [Mermaid Plugin](https://www.dokuwiki.org/plugin:mermaid)\n- [Foswiki](https://foswiki.org)\n  - [Mermaid Plugin](https://foswiki.org/Extensions/MermaidPlugin)\n- [MediaWiki](https://www.mediawiki.org)\n  - [Flex Diagrams Extension](https://www.mediawiki.org/wiki/Extension:Flex_Diagrams)\n  - [Mermaid Extension](https://www.mediawiki.org/wiki/Extension:Mermaid)\n- [PmWiki](https://www.pmwiki.org)\n  - [MermaidJs Cookbook recipe](https://www.pmwiki.org/wiki/Cookbook/MermaidJs)\n- [Semantic Media Wiki](https://www.semantic-mediawiki.org)\n  - [Mermaid Plugin](https://github.com/SemanticMediaWiki/Mermaid)\n- [TiddlyWiki](https://tiddlywiki.com/)\n  - [mermaid-tw5: wrapper for Mermaid Live](https://github.com/efurlanm/mermaid-tw5)\n  - [tw5-mermaid: plugin for managing Mermaid.js tiddlers](https://github.com/jasonmhoule/tw5-mermaid)\n\n### Editor Plugins\n\n- Atom _(Atom has been [archived.](https://github.blog/2022-06-08-sunsetting-atom/))_\n  - [Markdown Preview Enhanced](https://github.com/shd101wyy/markdown-preview-enhanced)\n  - [Atom Mermaid](https://github.com/y-takey/atom-mermaid)\n  - [Language Mermaid Syntax Highlighter](https://github.com/ytisf/language-mermaid)\n- [Astah](https://astah.net)\n  - [Export to Mermaid](https://github.com/Avens666/Astah_Jude_UML_export_to_Markdown-mermaid-Plantuml-)\n- [Brackets](https://brackets.io/)\n  - [Mermaid Preview](https://github.com/AlanHohn/mermaid-preview)\n- [CKEditor](https://github.com/ckeditor/ckeditor5)\n  - [CKEditor 5 Mermaid plugin](https://github.com/ckeditor/ckeditor5-mermaid)\n- [Draw.io](https://draw.io)\n  - [Mermaid Plugin](https://github.com/nopeslide/drawio_mermaid_plugin)\n- [GNU Emacs](https://www.gnu.org/software/emacs/)\n  - [Major mode for .mmd files](https://github.com/abrochard/mermaid-mode)\n  - [Org-Mode integration](https://github.com/arnm/ob-mermaid)\n- [GNU Nano](https://www.nano-editor.org/)\n  - [Nano Mermaid](https://github.com/Yash-Singh1/nano-mermaid)\n- [Google docs](https://docs.google.com/)\n  - [Mermaid plugin for google docs](https://workspace.google.com/marketplace/app/mermaid/636321283856)\n- [Inkdrop](https://www.inkdrop.app)\n  - [Mermaid Plugin](https://github.com/inkdropapp/inkdrop-mermaid)\n- [IntelliJ Idea](https://www.jetbrains.com/idea/)\n  - [Mermaid Visualizer](https://plugins.jetbrains.com/plugin/30432-mermaid-visualizer)\n- [Light Table](http://lighttable.com/)\n  - [Mermaid Plugin](https://github.com/cldwalker/Mermaid)\n- [Markdown-It](https://github.com/markdown-it/markdown-it)\n  - [Textual UML Parser](https://github.com/manastalukdar/markdown-it-textual-uml)\n  - [Mermaid Plugin](https://github.com/tylingsoft/markdown-it-mermaid)\n  - [md-it-mermaid](https://github.com/iamcco/md-it-mermaid)\n  - [markdown-it-mermaid-less](https://github.com/searKing/markdown-it-mermaid-less)\n- [Podlite](https://github.com/zag/podlite-desktop)\n  - [=Diagram block](https://github.com/zag/podlite/tree/main/packages/podlite-diagrams)\n- [Standard Notes](https://standardnotes.com/)\n  - [Mermaid Extension](https://github.com/nienow/sn-mermaid)\n- [VS Code](https://code.visualstudio.com/)\n  - [Mermaid Editor](https://marketplace.visualstudio.com/items?itemName=tomoyukim.vscode-mermaid-editor)\n  - [Mermaid Export](https://marketplace.visualstudio.com/items?itemName=Gruntfuggly.mermaid-export)\n  - [Markdown PDF](https://marketplace.visualstudio.com/items?itemName=yzane.markdown-pdf)\n  - [Markdown Preview Mermaid Support](https://marketplace.visualstudio.com/items?itemName=bierner.markdown-mermaid)\n  - [Markdown Preview Enhanced](https://marketplace.visualstudio.com/items?itemName=shd101wyy.markdown-preview-enhanced)\n  - [Mermaid Preview](https://marketplace.visualstudio.com/items?itemName=vstirbu.vscode-mermaid-preview)\n  - [Preview](https://marketplace.visualstudio.com/items?itemName=searKing.preview-vscode)\n  - [Preview Sequence Diagrams](https://marketplace.visualstudio.com/items?itemName=arichika.previewseqdiag-vscode)\n  - [Mermaid Markdown Syntax Highlighting](https://marketplace.visualstudio.com/items?itemName=bpruitt-goddard.mermaid-markdown-syntax-highlighting)\n- [Vim](https://www.vim.org)\n  - [Vim Diagram Syntax](https://github.com/zhaozg/vim-diagram)\n  - [Official Vim Syntax and ft plugin](https://github.com/craigmac/vim-mermaid)\n- [Zed](https://zed.dev)\n  - [zed-mermaid](https://github.com/gabeidx/zed-mermaid)\n\n### Document Generation\n\n- [Astro](https://astro.build/)\n  - [Adding diagrams to your Astro site with MermaidJS and Playwright](https://agramont.net/blog/diagraming-with-mermaidjs-astro/)\n- [Codedoc](https://codedoc.cc/)\n  - [codedoc-mermaid-plugin](https://www.npmjs.com/package/codedoc-mermaid-plugin)\n- [Docsy Hugo Theme](https://www.docsy.dev/docs/content/diagrams-and-formulae/) ✅\n- [Docusaurus](https://docusaurus.io/docs/markdown-features/diagrams) ✅\n- [Gatsby](https://www.gatsbyjs.com/)\n  - [gatsby-remark-mermaid](https://github.com/remcohaszing/gatsby-remark-mermaid)\n- [Jekyll](https://jekyllrb.com/)\n  - [jekyll-mermaid](https://rubygems.org/gems/jekyll-mermaid)\n  - [jekyll-mermaid-diagrams](https://github.com/fuzhibo/jekyll-mermaid-diagrams)\n- [JSDoc](https://jsdoc.app/)\n  - [jsdoc-mermaid](https://github.com/Jellyvision/jsdoc-mermaid)\n- [Madness](https://madness.dannyb.co/)\n- [mdBook](https://rust-lang.github.io/mdBook/index.html)\n  - [mdbook-mermaid](https://github.com/badboy/mdbook-mermaid)\n- [MkDocs](https://www.mkdocs.org)\n  - [mkdocs-mermaid2-plugin](https://github.com/fralau/mkdocs-mermaid2-plugin)\n  - [mkdocs-material](https://github.com/squidfunk/mkdocs-material), check the [docs](https://squidfunk.github.io/mkdocs-material/reference/diagrams/)\n- [Quarto](https://quarto.org/) ✅\n- [rehype](https://github.com/rehypejs/rehype)\n  - [rehype-mermaid](https://github.com/remcohaszing/rehype-mermaid)\n- [remark](https://remark.js.org/)\n  - [remark-mermaidjs](https://github.com/remcohaszing/remark-mermaidjs)\n- [Sphinx](https://www.sphinx-doc.org/en/master/)\n  - [sphinxcontrib-mermaid](https://github.com/mgaitan/sphinxcontrib-mermaid)\n- [Type Doc](https://typedoc.org/)\n  - [typedoc-plugin-mermaid](https://www.npmjs.com/package/typedoc-plugin-mermaid)\n- [Typora](https://support.typora.io/Draw-Diagrams-With-Markdown/#mermaid) ✅\n- [Unison programming language](https://www.unison-lang.org/docs/usage-topics/documentation/) ✅\n\n### Browser Extensions\n\n| Name                     | Chrome Web Store                                                                                            | Firefox Add-ons                                                                | Opera                                                                          | Edge                                                                                                                         | Source/Repository                                                                                    |\n| ------------------------ | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |\n| GitHub + Mermaid         | -                                                                                                           | [🦊🔗](https://addons.mozilla.org/firefox/addon/github-mermaid/)               | -                                                                              | -                                                                                                                            | [🐙🔗](https://github.com/BackMarket/github-mermaid-extension)                                       |\n| Asciidoctor Live Preview | [🎡🔗](https://chromewebstore.google.com/detail/asciidoctorjs-live-previe/iaalpfgpbocpdfblpnhhgllgbdbchmia) | -                                                                              | -                                                                              | [🌀🔗](https://microsoftedge.microsoft.com/addons/detail/asciidoctorjs-live-previ/pefkelkanablhjdekgdahplkccnbdggd?hl=en-US) | -                                                                                                    |\n| Diagram Tab              | -                                                                                                           | -                                                                              | -                                                                              | -                                                                                                                            | [🐙🔗](https://github.com/khafast/diagramtab)                                                        |\n| Markdown Diagrams        | [🎡🔗](https://chromewebstore.google.com/detail/markdown-diagrams/pmoglnmodacnbbofbgcagndelmgaclel)         | [🦊🔗](https://addons.mozilla.org/en-US/firefox/addon/markdown-diagrams/)      | -                                                                              | [🌀🔗](https://microsoftedge.microsoft.com/addons/detail/markdown-diagrams/hceenoomhhdkjjijnmlclkpenkapfihe)                 | [🐙🔗](https://github.com/marcozaccari/markdown-diagrams-browser-extension/tree/master/doc/examples) |\n| Markdown Viewer          | -                                                                                                           | [🦊🔗](https://addons.mozilla.org/en-US/firefox/addon/markdown-viewer-chrome/) | -                                                                              | -                                                                                                                            | [🐙🔗](https://github.com/simov/markdown-viewer)                                                     |\n| Extensions for Mermaid   | -                                                                                                           | -                                                                              | [🔴🔗](https://addons.opera.com/en/extensions/details/extensions-for-mermaid/) | -                                                                                                                            | [🐙🔗](https://github.com/Stefan-S/mermaid-extension)                                                |\n| Chrome Diagrammer        | [🎡🔗](https://chromewebstore.google.com/detail/chrome-diagrammer/bkpbgjmkomfoakfklcjeoegkklgjnnpk)         | -                                                                              | -                                                                              | -                                                                                                                            | -                                                                                                    |\n| Mermaid Diagrams         | [🎡🔗](https://chromewebstore.google.com/detail/mermaid-diagrams/phfcghedmopjadpojhmmaffjmfiakfil)          | -                                                                              | -                                                                              | -                                                                                                                            | -                                                                                                    |\n| Monkeys                  | [🎡🔗](https://chromewebstore.google.com/detail/monkeys-mermaid-for-githu/cplfdpoajbclbgphaphphcldamfkjlgi) | -                                                                              | -                                                                              | -                                                                                                                            | -                                                                                                    |\n| Mermaid Previewer        | [🎡🔗](https://chromewebstore.google.com/detail/mermaid-previewer/oidjnlhbegipkcklbdfnbkikplpghfdl)         | -                                                                              | -                                                                              | -                                                                                                                            | -                                                                                                    |\n| Tachi Code               | [🎡🔗](https://chromewebstore.google.com/detail/tachi-code/acoecgiamdjjkhmdodcfdfanfnagamjf)                | [🦊🔗](https://addons.mozilla.org/en-US/firefox/addon/tachi-code/)             | -                                                                              | [🌀🔗](https://microsoftedge.microsoft.com/addons/detail/tachi-code/mombmlijgpfamkenkmggobjimompbpji)                        | -                                                                                                    |\n\n### Other\n\n- [Bisheng](https://www.npmjs.com/package/bisheng)\n  - [bisheng-plugin-mermaid](https://github.com/yct21/bisheng-plugin-mermaid)\n- [Blazorade Mermaid: Render Mermaid diagrams in Blazor applications](https://github.com/Blazorade/Blazorade-Mermaid/wiki)\n- [Codemia: A tool to practice system design problems](https://codemia.io) ✅\n- [ExDoc](https://github.com/elixir-lang/ex_doc)\n  - [Rendering Mermaid graphs](https://github.com/elixir-lang/ex_doc#rendering-mermaid-graphs)\n- [MarkChart: Preview Mermaid diagrams on macOS](https://markchart.app/)\n- [mermaid-isomorphic](https://github.com/remcohaszing/mermaid-isomorphic)\n- [mermaid-server: Generate diagrams using a HTTP request](https://github.com/TomWright/mermaid-server)\n- [NiceGUI: Let any browser be the frontend of your Python code](https://nicegui.io) ✅\n  - [ui.mermaid(...)](https://nicegui.io/documentation/mermaid)\n- [Reveal.js](https://github.com/hakimel/reveal.js)\n  - [reveal.js-mermaid-plugin](https://github.com/ludwick/reveal.js-mermaid-plugin)\n- [Reveal CK](https://github.com/jedcn/reveal-ck)\n  - [reveal-ck-mermaid-plugin](https://github.com/tmtm/reveal-ck-mermaid-plugin)\n- [SchemaCrawler - Generate Mermaid diagrams from your database](https://dev.to/sualeh/how-to-generate-mermaid-diagrams-for-your-database-33bn)\n- [Schema3D](https://schema3d.com) - Browser-only 3D visualizer for Mermaid ER diagrams (also SQL / DrawDB); shareable URL, no live DB\n- [speccharts: Turn your test suites into specification diagrams](https://github.com/arnaudrenaud/speccharts)\n- [termaid: Render Mermaid diagrams as Unicode art in the terminal](https://github.com/fasouto/termaid)\n- [Vitepress Plugin](https://github.com/sametcn99/vitepress-mermaid-renderer)\n\n\n","packages/mermaid/src/docs/ecosystem/integrations-create.md":"# Integrations - create\n\n## Recommendations\n\nBelow are recommendations for creating plugins and integrations with Mermaid.\n\n### File Extension\n\nApplications that support Mermaid files [SHOULD](https://datatracker.ietf.org/doc/html/rfc2119#section-3) use `.mermaid` or `.mmd` file extensions.\n\n### MIME Type\n\nThe recommended [MIME type](https://www.iana.org/assignments/media-types/media-types.xhtml) for Mermaid media is [`text/vnd.mermaid`](https://www.iana.org/assignments/media-types/application/vnd.mermaid).\n\n## Showcase\n\n### Mermaid Discord workspace\n\nWe would love to see what you create with Mermaid. Please share your creations with us in our [Discord](https://discord.gg/sKeNQX4Wtj) server [#showcase](https://discord.com/channels/1079455296289788015/1079502635054399649) channel.\n\n### Add to Mermaid Ecosystem\n\nIf you have a plugin or integration that you'd like to add to our [Community integrations](/ecosystem/integrations-community) list, please [open a pull request](https://github.com/mermaid-js/mermaid).\n","packages/mermaid/src/docs/ecosystem/mermaid-chart.md":"# Mermaid Chart\n\nThe Future of Diagramming & Visual Collaboration\n\nTry the Ultimate AI, Mermaid, and Visual Diagramming Suite by creating an account at [Mermaid Chart](https://mermaid.ai/app/sign-up).\n\n
\n\n\"Mermaid Chart\n\n## About\n\n[Mermaid Chart](https://mermaid.ai) was born out of the Mermaid open source project and was founded by Knut Sveidqvist together with Open Core Ventures. The lead developers from Mermaid have joined the company and there is a strong connection between the project we all love and Mermaid Chart. Mermaid Chart brings resources to the open source development of Mermaid and makes it possible to work with Mermaid professionally.\n\n## Features\n\n- **Editor** - A web based editor for creating and editing Mermaid diagrams.\n\n- **Mermaid AI** - Use our embedded AI Chat to generate diagrams from natural language descriptions.\n\n- **Whiteboard** - A virtual whiteboard for creating and editing Mermaid diagrams.\n\n- **Plugins** - A plugin system for extending the functionality of Mermaid.\n\n  Official Mermaid Chart plugins:\n  - [Mermaid Chart GPT](https://chatgpt.com/g/g-684cc36f30208191b21383b88650a45d-mermaid-chart-diagrams-and-charts)\n  - [Confluence](https://marketplace.atlassian.com/apps/1234056/mermaid-chart-for-confluence?hosting=cloud&tab=overview)\n  - [Jira](https://marketplace.atlassian.com/apps/1234810/mermaid-chart-for-jira?tab=overview&hosting=cloud)\n  - [Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=MermaidChart.vscode-mermaid-chart)\n  - [JetBrains IDE](https://plugins.jetbrains.com/plugin/23043-mermaid-chart)\n  - [Google Docs](https://gsuite.google.com/marketplace/app/mermaidchart/947683068472)\n  - [Microsoft PowerPoint and Word](https://appsource.microsoft.com/en-us/product/office/WA200006214?tab=Overview)\n\n  Visit our [Plugins](https://mermaid.ai/plugins) page for more information.\n\n- **Collaboration** - A web based collaboration feature for multi-user editing on Mermaid diagrams in real-time (Pro and Enterprise plans).\n\n- **Comments** - Enhance collaboration by adding comments to diagrams.\n\n- **Presentations** - A presentation mode for viewing Mermaid diagrams in a slideshow format.\n\n## Plans\n\n- **Basic** - A free plan that includes three diagrams and limited AI usage.\n\n- **Plus** - A paid plan that includes unlimited diagrams, scalable AI usage, and centralized billing for small teams.\n\n- **Premium** - A paid plan for larger teams that need massive AI or diagram usage along with team collaboration, knowledge management, and security features like SSO.\n\n- **Enterprise** - A paid plan for enterprise use that includes all Premium features, custom contracts, support, and more.\n\nTo learn more, visit our [Pricing](https://mermaid.ai/pricing) page.\n\nSign up for a free account on the [Mermaid](https://mermaid.ai/app/sign-up) website and trial paid features at any time for 7 days free.\n\n## Mermaid JS contributions\n\nFirst time contributors are eligible for a free Premium tier account for 1 year.\n","packages/mermaid/src/docs/ecosystem/tutorials.md":"# Tutorials\n\nThis is a list of publicly available Tutorials for using Mermaid.JS and is intended as a basic introduction for the use of the Live Editor for generating diagrams, and deploying Mermaid.JS through HTML.\n\n**Note that these tutorials might display an older interface, but the usage of the live-editor will largely be the same.**\n\nFor most purposes, you can use the [Live Editor](https://mermaid.live), to quickly and easily render a diagram.\n\n## Live-Editor Tutorials\n\nThe definitions that can be generated the Live-Editor are also backwards-compatible as of version 8.7.0.\n\n[Chris Chinchilla: Hands on - Text-based diagrams with Mermaid](https://www.youtube.com/watch?v=4_LdV1cs2sA)\n\n[GitLab Unfiltered: How to Create Mermaid Diagrams](https://www.youtube.com/watch?v=SQ9QmuTHuSI&t=438s)\n\n[GitLab Unfiltered: Emilie adds a mermaid diagram to the handbook](https://www.youtube.com/watch?v=5RQqht3NNSE)\n\n[World of Zero: I Learn How To Build Flowcharts and Signal Diagram's in Mermaid.JS](https://www.youtube.com/watch?v=7_2IroEs6Is&t=207s)\n\n[Eddie Jaoude: Can you code your diagrams?](https://www.youtube.com/watch?v=9HZzKkAqrX8)\n\n## Mermaid with OpenAI\n\n[Elle Neal: Mind Mapping with AI: An Accessible Approach for Neurodiverse Learners Tutorial:](https://medium.com/@elle.neal_71064/mind-mapping-with-ai-an-accessible-approach-for-neurodiverse-learners-1a74767359ff)\n\n## Mermaid with HTML\n\nExamples are provided in [Getting Started](../intro/getting-started.md)\n\n**CodePen Examples:**\n\nhttps://codepen.io/CarlBoneri/pen/BQwZzq\n\nhttps://codepen.io/tdkn/pen/vZxQzd\n\nhttps://codepen.io/janzeteachesit/pen/OWWZKN\n\n## Mermaid with Text Area\n\nhttps://codepen.io/Ryuno-Ki/pen/LNxwgR\n\n## Mermaid in open source docs\n\n[K8s.io Diagram Guide](https://kubernetes.io/docs/contribute/style/diagram-guide/)\n\n[K8s.dev blog: Improve your documentation with Mermaid.js diagrams](https://www.kubernetes.dev/blog/2021/12/01/improve-your-documentation-with-mermaid.js-diagrams/)\n\n## Jupyter / Python Integration with mermaid-js\n\nHere's an example of Python integration with mermaid-js which uses the mermaid.ink service, that displays the graph in a Jupyter notebook and save it as _.png_ image with the stated resolution (in this example, `dpi=1200`).\n\n```python\nimport base64\nimport io, requests\nfrom IPython.display import Image, display\nfrom PIL import Image as im\nimport matplotlib.pyplot as plt\n\ndef mm(graph):\n    graphbytes = graph.encode(\"utf8\")\n    base64_bytes = base64.urlsafe_b64encode(graphbytes)\n    base64_string = base64_bytes.decode(\"ascii\")\n    img = im.open(io.BytesIO(requests.get('https://mermaid.ink/img/' + base64_string).content))\n    plt.imshow(img)\n    plt.axis('off') # allow to hide axis\n    plt.savefig('image.png', dpi=1200)\n\nmm(\"\"\"\ngraph LR;\n    A--> B & C & D\n    B--> A & E\n    C--> A & E\n    D--> A & E\n    E--> B & C & D\n\"\"\")\n```\n\n**Output**\n\n![Example graph of the Python integration](img/python-mermaid-integration.png)\n\n\n","packages/mermaid/src/docs/index.md":"---\nlayout: home\nsidebar: false\n\ntitle: Mermaid\ntitleTemplate: Diagramming and charting tool\nhero:\n  name: Mermaid.js now lives\n  text: at mermaid.ai\n  tagline: One home for the open-source library and the platform built around it. More resources for the project, a clearer path for contributors, and a team committed to keeping Mermaid open, always.\n\n  image:\n    light: /hero-chart.svg\n    dark: /hero-chart-dark.svg\n    alt: Mermaid diagram\n  actions:\n    - theme: brand\n      text: Try Editor\n      link: https://mermaid.live/edit\n      target: _blank\n      rel: external\n    - theme: alt\n      text: Get started\n      link: https://mermaid.ai/open-source/intro/\n\nfeatures:\n  - icon:\n      src: /1-Callout-Easy.svg\n    title: Easy to use\n    details: Easily create diagrams and charts with the Mermaid Live Editor.\n    link: https://mermaid.live/\n  - icon:\n      src: /2-Callout-Integrations.svg\n    title: Integrations available\n    details: Use Mermaid with your favorite applications, check out the integrations list.\n    link: ../../ecosystem/integrations-community.md\n  - icon:\n      src: /3-Callout-Awards.svg\n    title: Award winning\n    details: 2019 JavaScript Open Source Award winner for \"The Most Exciting Use of Technology\".\n    link: https://osawards.com/javascript/2019\n---\n","packages/mermaid/src/docs/intro/examples.md":"## Diagram Types\n\n### [Flowchart](../syntax/flowchart.md?id=flowcharts-basic-syntax)\n\n```mermaid-example\ngraph TD;\n    A-->B;\n    A-->C;\n    B-->D;\n    C-->D;\n```\n\n### [Sequence diagram](../syntax/sequenceDiagram.md)\n\n```mermaid-example\nsequenceDiagram\n    participant Alice\n    participant Bob\n    Alice->>John: Hello John, how are you?\n    loop HealthCheck\n        John->>John: Fight against hypochondria\n    end\n    Note right of John: Rational thoughts 
prevail!\n    John-->>Alice: Great!\n    John->>Bob: How about you?\n    Bob-->>John: Jolly good!\n```\n\n### [Use case diagram](../syntax/usecase.md)\n\n```mermaid-example\nusecase-beta\ndirection LR\nactor Customer\nCheckout(\"Place order\")\nCustomer --> Checkout\n```\n\n### [Gantt diagram](../syntax/gantt.md)\n\n```mermaid-example\ngantt\ndateFormat  YYYY-MM-DD\ntitle Adding GANTT diagram to mermaid\nexcludes weekdays 2014-01-10\n\nsection A section\nCompleted task            :done,    des1, 2014-01-06,2014-01-08\nActive task               :active,  des2, 2014-01-09, 3d\nFuture task               :         des3, after des2, 5d\nFuture task2               :         des4, after des3, 5d\n```\n\n### [Class diagram](../syntax/classDiagram.md)\n\n```mermaid-example\nclassDiagram\nClass01 <|-- AveryLongClass : Cool\nClass03 *-- Class04\nClass05 o-- Class06\nClass07 .. Class08\nClass09 --> C2 : Where am i?\nClass09 --* C3\nClass09 --|> Class07\nClass07 : equals()\nClass07 : Object[] elementData\nClass01 : size()\nClass01 : int chimp\nClass01 : int gorilla\nClass08 <--> C2: Cool label\n```\n\n### [Git graph](../syntax/gitgraph.md)\n\n```mermaid-example\n    gitGraph\n       commit\n       commit\n       branch develop\n       commit\n       commit\n       commit\n       checkout main\n       commit\n       commit\n```\n\n### [Entity Relationship Diagram - :exclamation: experimental](../syntax/entityRelationshipDiagram.md)\n\n```mermaid-example\nerDiagram\n    CUSTOMER ||--o{ ORDER : places\n    ORDER ||--|{ LINE-ITEM : contains\n    CUSTOMER }|..|{ DELIVERY-ADDRESS : uses\n\n```\n\n### [User Journey Diagram](../syntax/userJourney.md)\n\n```mermaid-example\njourney\n    title My working day\n    section Go to work\n      Make tea: 5: Me\n      Go upstairs: 3: Me\n      Do work: 1: Me, Cat\n    section Go home\n      Go downstairs: 5: Me\n      Sit down: 5: Me\n```\n\n### [Quadrant Chart](../syntax/quadrantChart.md)\n\n```mermaid-example\nquadrantChart\n    title Reach and engagement of campaigns\n    x-axis Low Reach --> High Reach\n    y-axis Low Engagement --> High Engagement\n    quadrant-1 We should expand\n    quadrant-2 Need to promote\n    quadrant-3 Re-evaluate\n    quadrant-4 May be improved\n    Campaign A: [0.3, 0.6]\n    Campaign B: [0.45, 0.23]\n    Campaign C: [0.57, 0.69]\n    Campaign D: [0.78, 0.34]\n    Campaign E: [0.40, 0.34]\n    Campaign F: [0.35, 0.78]\n```\n\n### [XY Chart](../syntax/xyChart.md)\n\n```mermaid-example\nxychart-beta\n    title \"Sales Revenue\"\n    x-axis [jan, feb, mar, apr, may, jun, jul, aug, sep, oct, nov, dec]\n    y-axis \"Revenue (in $)\" 4000 --> 11000\n    bar [5000, 6000, 7500, 8200, 9500, 10500, 11000, 10200, 9200, 8500, 7000, 6000]\n    line [5000, 6000, 7500, 8200, 9500, 10500, 11000, 10200, 9200, 8500, 7000, 6000]\n```\n","packages/mermaid/src/docs/intro/getting-started.md":"---\noutline: 'deep' # shows all h3 headings in outline in Vitepress\n---\n\n# Mermaid User Guide\n\n## Mermaid is composed of three parts\n\n1. Deployment\n2. Syntax\n3. Configuration\n\nThis section talks about the different ways to **deploy** Mermaid.\n\nIf you are a beginner:\n\n- Check out the [Diagram Syntax](syntax-reference.md) page\n- Check out the [Tutorials](../ecosystem/tutorials.md) page\n\n## Ways to use Mermaid\n\n1. [Using the Mermaid Live Editor](getting-started.md#_1-using-the-mermaid-live-editor)\n2. [Using the Mermaid Chart Editor](getting-started.md#_2-using-the-mermaid-chart-editor)\n3. [Using Mermaid Plugins and Integrations](getting-started.md#_3-using-mermaid-plugins)\n4. [Calling the Mermaid JavaScript API](getting-started.md#_4-calling-the-mermaid-javascript-api)\n5. [Adding Mermaid as a dependency](getting-started.md#_5-adding-mermaid-as-a-dependency)\n\nTo learn more, visit the [Usage](../config/usage.md) page.\n\n## 1. Using the Mermaid Live Editor\n\nAvailable at the [Mermaid Live Editor](https://mermaid.live) website.\n\n### Features\n\n
\n\n#### • Diagram Code\n\nIn the `Code` panel, write or edit Mermaid code, and instantly `Preview` the rendered result in the diagram panel.\n\nHere is an example of Mermaid code and its rendered result:\n\n```mermaid-example\ngraph TD\n    A[Enter Chart Definition] --> B(Preview)\n    B --> C{decide}\n    C --> D[Keep]\n    C --> E[Edit Definition]\n    E --> B\n    D --> F[Save Image and Code]\n    F --> B\n```\n\n
\n\n#### • Configurations\n\nConfiguration options are available in the `Configuration` panel. The options are applied to the diagram in the `Preview` panel.\n\nTo learn more, visit the [Configuration Reference](../config/setup/README.md) page\n\n![Code,Config and Preview](./img/Code-Preview-Config.png)\n\n
\n\n#### • Editing History\n\nYour code will be autosaved and appear in the `Timeline` tab of the `History` section. Edits are saved every minute and only the last 30 edits are viewable.\n\nAlternatively, you can manually save code by clicking on the `Save` icon from the `History` section.\n\n```note\nHistory is stored in the browser storage only.\n```\n\n
\n\n#### • Saving a diagram\n\nThere are multiple ways of saving your diagram from the `Actions` section:\n\n- export PNG\n- export SVG\n- export as Markdown\n\n![Flowchart](./img/Live-Editor-Choices.png)\n\n
\n\n#### • Editing your diagrams\n\nTo edit your diagram, you can copy paste existing Mermaid diagram code into the `Code` section of the `Live Editor`.\n\nOr:\n\n- create a new diagram from scratch\n- use a Sample Diagram from the `Sample Diagrams` section\n\n
\n\n#### • Loading from Gists\n\nThe Gist you create should have a `code.mmd` file and optionally a `config.json`, similar to this [example](https://gist.github.com/sidharthv96/6268a23e673a533dcb198f241fd7012a).\n\n```note\nTo learn about Gists, visit the GitHub documentation page on [Creating gists](https://docs.github.com/en/get-started/writing-on-github/editing-and-sharing-content-with-gists/creating-gists).\n```\n\nOnce you have created a Gist, copy paste the Gist URL into the respective field in the `Actions` section and click on the `Load Gist` button.\n\nHere is an example of a Gist being loaded into the Editor:\n\n\n\nAnd, here is the diagram view from the above example:\n\n\n\n## 2. Using the Mermaid Chart Editor\n\nAvailable at the [Mermaid Chart](https://mermaid.ai/) website.\n\nMermaid Chart is a web-based diagram editor that allows you to create and edit diagrams in your browser. It is built by the team behind Mermaid.\n\nFeatures include:\n\n- AI diagramming\n- Collaboration & multi-user editing\n- Storage\n- and more\n\nTo learn more, visit the [Mermaid Chart page](/ecosystem/mermaid-chart.html) in the Ecosystem section of the documentation.\n\nOr go to the [Mermaid Chart website](https://mermaid.ai/app/sign-up) to sign up for a Free account.\n\n## 3. Using Mermaid Plugins\n\n### Mermaid Plugins\n\nYou can generate Mermaid diagrams from within popular applications using plug-ins.\n\nFor a list of Mermaid Plugins and Integrations, visit the [Integrations page](../ecosystem/integrations-community.md).\n\n### Mermaid Chart Plugins\n\nMermaid Chart plugins are available for:\n\n- [ChatGPT](https://mermaid.ai/docs/plugins/mermaid-chart-gpt)\n- [JetBrains IDE](https://mermaid.ai/docs/plugins/jetbrains-ide)\n- [Microsoft PowerPoint](https://mermaid.ai/docs/plugins/microsoft-powerpoint)\n- [Microsoft Word](https://mermaid.ai/docs/plugins/microsoft-word)\n- [Visual Studio Code](https://mermaid.ai/docs/plugins/visual-studio-code)\n\nTo learn more, visit the [Mermaid Chart Plugins](https://mermaid.ai/plugins) page.\n\n### Native Mermaid Support\n\nFor apps that support markdown (e.g. [GitHub](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-diagrams) and [GitLab](https://handbook.gitlab.com/handbook/tools-and-tips/mermaid/)), you can add Mermaid diagrams by making a `mermaid` code block.\n\n````markdown\nThe following code-block will be rendered as a Mermaid diagram:\n\n```mermaid\nflowchart LR\n  A --> B\n```\n````\n\n## 4. Calling the Mermaid JavaScript API\n\nThis method can be used with any common web server like `Apache`, `IIS`, `Nginx`, and `Node Express`.\n\nYou will also need a text editing tool like `Notepad++` to generate an `html` file. It is then deployed by a web browser, i.e. `Firefox`, `Chrome`, `Safari`.\n\n```note\nInternet Explorer is not supported.\n```\n\nThe API works by pulling rendering instructions from the source `mermaid.js` in order to render diagrams on the page.\n\n### Requirements for the Mermaid API\n\nWhen writing the `html` file, we give two instructions inside the `html code` to the `web browser`:\n\na. The Mermaid code for the diagram we want to create.\n\nb. The importing of the Mermaid library through the `mermaid.esm.mjs` or `mermaid.esm.min.mjs`, and the `mermaid.initialize()` call, which dictates the appearance of diagrams and also starts the rendering process.\n\n#### Examples\n\n- This is an example of an embedded Mermaid diagram definition inside a `
`:\n\n```html\n\n  Here is a mermaid diagram:\n  
\n        graph TD\n        A[Client] --> B[Load Balancer]\n        B --> C[Server01]\n        B --> D[Server02]\n  
\n\n```\n\n```note\nEvery Mermaid chart/graph/diagram definition should have separate `
` tags.\n```\n\n- This is an example of a Mermaid import and the `mermaid.initialize()` call.\n\n```note\nA `mermaid.initialize()` call takes all the definitions contained within `
` tags and renders them into diagrams.\n```\n\n```html\n\n  \n\n```\n\n```note\nRendering in Mermaid is initialized by the `mermaid.initialize()` call. However, doing the opposite lets you control when it starts looking for `
` tags inside the web page with `mermaid.initialize()`. This is useful when you think that not all `
` tags may have loaded on the execution of `mermaid.esm.min.mjs` file.\n```\n\n`startOnLoad` is one of the parameters that can be defined by `mermaid.initialize()`\n\n| Parameter   | Description                       | Type    | Values      |\n| ----------- | --------------------------------- | ------- | ----------- |\n| startOnLoad | Toggle for Rendering upon loading | Boolean | true, false |\n\nIn this example, the `mermaidAPI` is being called through the `CDN`:\n\n```html\n\n  \n    Here is one mermaid diagram:\n    
\n            graph TD\n            A[Client] --> B[Load Balancer]\n            B --> C[Server1]\n            B --> D[Server2]\n    
\n\n    And here is another:\n    
\n            graph TD\n            A[Client] -->|tcp_123| B\n            B(Load Balancer)\n            B -->|tcp_456| C[Server1]\n            B -->|tcp_456| D[Server2]\n    
\n\n    \n  \n\n```\n\nIn this example, `mermaid.js` is referenced in `src` as a separate JavaScript file:\n\n```html\n\n  \n    \n  \n  \n    
\n            graph LR\n            A --- B\n            B-->C[fa:fa-ban forbidden]\n            B-->D(fa:fa-spinner);\n    
\n    
\n            graph TD\n            A[Client] --> B[Load Balancer]\n            B --> C[Server1]\n            B --> D[Server2]\n    
\n    \n  \n\n```\n\n##### Custom fonts\n\nMermaid comes with some default recommended fonts that you can setup on your\npage as well.\n\nSee [Usage § Fonts](../config/usage.md#fonts) for full details.\n\n```html\n\n  \n    /@fontsource/open-sans@5/400.css\" />\n    /@fontsource/open-sans@5/400-italic.css\" />\n    /@fontsource-variable/recursive@5/index.css\" />\n  \n  \n    Here is one mermaid diagram using the `redux-dark` theme:\n\n    
\n      ---\n      config:\n        theme: redux-dark\n      ---\n      flowchart\n            A[Client] --> B[Load Balancer]\n            B --> C[Server1]\n            B --> D[Server2]\n    
\n\n    \n  \n\n```\n\n## 5. Adding Mermaid as a dependency\n\nBelow are the steps for adding Mermaid as a dependency:\n\n1. Install [Node.js](https://nodejs.org/) v20 or higher (LTS recommended).\n\n```note\nTo learn more about downloading and installing `Node.js` and `npm`, visit the [npm Docs website](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm).\n```\n\n2. Add Mermaid using your preferred package manager:\n\n   **npm**\n\n   `npm install mermaid`\n\n   **yarn**\n\n   `yarn add mermaid`\n\n   **pnpm**\n\n   `pnpm add mermaid`\n\n3. To add Mermaid as a dev dependency instead, append the dev flag:\n\n   **npm:** `npm install --save-dev mermaid`\n\n   **yarn:** `yarn add --dev mermaid`\n\n   **pnpm:** `pnpm add --save-dev mermaid`\n\n## Closing note\n\n```note\nComments from Knut Sveidqvist, creator of Mermaid:\n\n- In early versions of Mermaid, the `\n```\n\n**Doing so commands the mermaid parser to look for the `
` or `
` tags with `class=\"mermaid\"`. From these tags, mermaid tries to read the diagram/chart definitions and render them into SVG charts.**\n\n**Examples can be found in** [Other examples](../syntax/examples.md)\n\n## Sibling projects\n\n- [Mermaid Live Editor](https://github.com/mermaid-js/mermaid-live-editor)\n- [Mermaid CLI](https://github.com/mermaid-js/mermaid-cli)\n- [Mermaid Tiny](https://github.com/mermaid-js/mermaid/tree/develop/packages/tiny)\n- [Mermaid Webpack Demo](https://github.com/mermaidjs/mermaid-webpack-demo)\n- [Mermaid Parcel Demo](https://github.com/mermaidjs/mermaid-parcel-demo)\n\n## Request for Assistance\n\nThings are piling up and I have a hard time keeping up. It would be great if we could form a core team of developers to cooperate\nwith the future development of mermaid.\n\nAs part of this team you would get write access to the repository and would\nrepresent the project when answering questions and issues.\n\nTogether we could continue the work with things like:\n\n- Adding more types of diagrams like mindmaps, ert diagrams, etc.\n- Improving existing diagrams\n\nDon't hesitate to contact me if you want to get involved!\n\n## Contributors\n\n
\n\n[![Good first issue](https://img.shields.io/github/labels/mermaid-js/mermaid/Good%20first%20issue%21)](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Good+first+issue%21%22)\n[![Contributors](https://img.shields.io/github/contributors/mermaid-js/mermaid)](https://github.com/mermaid-js/mermaid/graphs/contributors)\n[![Commits](https://img.shields.io/github/commit-activity/m/mermaid-js/mermaid)](https://github.com/mermaid-js/mermaid/graphs/contributors)\n\n
\n\nMermaid is a growing community and is always accepting new contributors. There's a lot of different ways to help out and we're always looking for extra hands! Look at [this issue](https://github.com/mermaid-js/mermaid/issues/866) if you want to know where to start helping out.\n\nDetailed information about how to contribute can be found in the [contribution guideline](../community/contributing.md).\n\n### Requirements\n\n- [volta](https://volta.sh/) to manage node versions.\n- [Node.js](https://nodejs.org/en/). `volta install node`\n- [pnpm](https://pnpm.io/) package manager. `volta install pnpm`\n\n### Development Installation\n\n```bash\ngit clone git@github.com:mermaid-js/mermaid.git\ncd mermaid\n# npx is required for first install as volta support for pnpm is not added yet.\nnpx pnpm install\npnpm test\n```\n\n### Lint\n\n```sh\npnpm lint\n```\n\nWe use [eslint](https://eslint.org/).\nWe recommend you to install [editor plugins](https://eslint.org/docs/user-guide/integrations) to get real time lint result.\n\n### Test\n\n```sh\npnpm test\n```\n\nManual test in browser: open `dist/index.html`\n\n### Release\n\nFor those who have the permission to do so:\n\nUpdate version number in `package.json`.\n\n```sh\nnpm publish\n```\n\nThe above command generates files into the `dist` folder and publishes them to [npmjs.com](https://www.npmjs.com/).\n\n## Security and safe diagrams\n\nFor public sites, it can be precarious to retrieve text from users on the internet, storing that content for presentation in a browser at a later stage. The reason is that the user content can contain embedded malicious scripts that will run when the data is presented. For Mermaid this is a risk, specially as mermaid diagrams contain many characters that are used in html which makes the standard sanitation unusable as it also breaks the diagrams. We still make an effort to sanitize the incoming code and keep refining the process but it is hard to guarantee that there are no loop holes.\n\nAs an extra level of security for sites with external users we are happy to introduce a new security level in which the diagram is rendered in a sandboxed iframe preventing JavaScript in the code from being executed. This is a great step forward for better security.\n\n_Unfortunately you cannot have a cake and eat it at the same time which in this case means that some of the interactive functionality gets blocked along with the possible malicious code._\n\n## Reporting vulnerabilities\n\nTo report a vulnerability, please e-mail security@mermaid.live with a description of the issue, the steps you took to create the issue, affected versions, and if known, mitigations for the issue.\n\n## Appreciation\n\nA quick note from Knut Sveidqvist:\n\n> _Many thanks to the [d3](https://d3js.org/) and [dagre-d3](https://github.com/cpettitt/dagre-d3) projects for providing the graphical layout and drawing libraries!_\n>\n> _Thanks also to the [js-sequence-diagram](https://bramp.github.io/js-sequence-diagrams) project for usage of the grammar for the sequence diagrams. Thanks to Jessica Peter for inspiration and starting point for gantt rendering._\n>\n> _Thank you to [Tyler Long](https://github.com/tylerlong) who has been a collaborator since April 2017._\n>\n> _Thank you to the ever-growing list of [contributors](https://github.com/mermaid-js/mermaid/graphs/contributors) that brought the project this far!_\n\n---\n\n_Mermaid was created by Knut Sveidqvist for easier documentation._\n\n\n","packages/mermaid/src/docs/intro/syntax-reference.md":"# Diagram Syntax\n\nMermaid's syntax is used to create diagrams. You'll find that it is not too tricky and can be learned in a day. The next sections dive deep into the syntax of each diagram type.\n\nSyntax, together with Deployment and Configuration constitute the whole of Mermaid.\n\nDiagram Examples can be found in the [Mermaid Live Editor](https://mermaid.live), it is also a great practice area.\n\n## Syntax Structure\n\nOne would notice that all **Diagrams definitions begin** with a declaration of the **diagram type**, followed by the definitions of the diagram and its contents. This declaration notifies the parser which kind of diagram the code is supposed to generate. The only exception to this a [Frontmatter](#frontmatter-for-diagram-code) configuration.\n\nLine comments can ignore anything on the line after '%% '.\n\nUnknown words and misspellings will break a diagram, while parameters silently fail.\n\n**Example** : The code below is for an Entity Relationship Diagram, specified by the `erDiagram` declaration. What follows is the definition of the different `Entities` represented in it.\n\n```mermaid-example\nerDiagram\n          CUSTOMER }|..|{ DELIVERY-ADDRESS : has\n          CUSTOMER ||--o{ ORDER : places\n          CUSTOMER ||--o{ INVOICE : \"liable for\"\n          DELIVERY-ADDRESS ||--o{ ORDER : receives\n          INVOICE ||--|{ ORDER : covers\n          ORDER ||--|{ ORDER-ITEM : includes\n          PRODUCT-CATEGORY ||--|{ PRODUCT : contains\n          PRODUCT ||--o{ ORDER-ITEM : \"ordered in\"\n```\n\nThe [Getting Started](./getting-started.md) section can also provide some practical examples of mermaid syntax.\n\n## Diagram Breaking\n\nOne should **beware the use of some words or symbols** that can break diagrams. These words or symbols are few and often only affect specific types of diagrams. The table below will continuously be updated.\n\n| Diagram Breakers                                                                     | Reason                                                                  | Solution                                          |\n| ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------- | ------------------------------------------------- |\n| **Comments**                                                                         |                                                                         |                                                   |\n| [`%%{``}%%`](https://github.com/mermaid-js/mermaid/issues/1968)                      | Similar to [Directives](../config/directives.md) confuses the renderer. | In comments using `%%`, avoid using \"{}\".         |\n| **Flow-Charts**                                                                      |                                                                         |                                                   |\n| 'end'                                                                                | The word \"End\" can cause Flowcharts and Sequence diagrams to break      | Wrap them in quotation marks to prevent breakage. |\n| [Nodes inside Nodes](../syntax/flowchart.md?id=special-characters-that-break-syntax) | Mermaid gets confused with nested shapes                                | wrap them in quotation marks to prevent breaking  |\n\n## Mermaid Live Editor\n\nNow, that you've seen what you should not add to your diagrams, you can play around with them in the [Mermaid Live Editor](https://mermaid.live).\n\n## Configuration\n\nConfiguration is the third part of Mermaid, after deployment and syntax. It deals with the different ways that Mermaid can be customized across different deployments.\n\nIf you are interested in altering and customizing your Mermaid Diagrams, you will find the methods and values available for [Configuration](../config/setup/README.md) here. It includes themes.\nThis section will introduce the different methods of configuring the behaviors and appearances of Mermaid Diagrams.\nThe following are the most commonly used methods, and they are all tied to Mermaid [Deployment](./getting-started.md) methods.\n\n### Configuration Section in the [Live Editor](https://mermaid.live).\n\nHere you can edit certain values to change the behavior and appearance of the diagram.\n\nEach of these techniques are functionally equivalent, but better for different deployments.\n\n### [The initialize() call](./getting-started.md#_4-calling-the-mermaid-javascript-api)\n\nUsed when Mermaid is called via an API, or through a `\n```\n\n```mermaid\nclassDiagram\n    class Class01\n    class Class02\n    callback Class01 \"callbackFunction\" \"Callback tooltip\"\n    link Class02 \"https://www.github.com\" \"This is a link\"\n    class Class03\n    class Class04\n    click Class03 call callbackFunction() \"Callback tooltip\"\n    click Class04 href \"https://www.github.com\" \"This is a link\"\n```\n\n> **Success** The tooltip functionality and the ability to link to urls are available from version 0.5.2.\n\nBeginner's tip—a full example using interactive links in an HTML page:\n\n```html\n\n  
\n    classDiagram\n    Animal <|-- Duck\n    Animal <|-- Fish\n    Animal <|-- Zebra\n    Animal : +int age\n    Animal : +String gender\n    Animal: +isMammal()\n    Animal: +mate()\n    class Duck{\n      +String beakColor\n      +swim()\n      +quack()\n      }\n    class Fish{\n      -int sizeInFeet\n      -canEat()\n      }\n    class Zebra{\n      +bool is_wild\n      +run()\n      }\n\n      callback Duck \"callback\" \"Tooltip\"\n      link Zebra \"https://www.github.com\" \"This is a link\"\n  
\n\n  \n\n```\n\n## Styling\n\n### Styling a node\n\nIt is possible to apply specific styles such as a thicker border or a different background color to an individual node using the `style` keyword.\n\nNote that notes and namespaces cannot be styled individually but do support themes.\n\n```mermaid-example\nclassDiagram\n  class Animal\n  class Mineral\n  style Animal fill:#f9f,stroke:#333,stroke-width:4px\n  style Mineral fill:#bbf,stroke:#f66,stroke-width:2px,color:#fff,stroke-dasharray: 5 5\n```\n\n#### Classes\n\nMore convenient than defining the style every time is to define a class of styles and attach this class to the nodes that\nshould have a different look.\n\nA class definition looks like the example below:\n\n```\nclassDef className fill:#f9f,stroke:#333,stroke-width:4px;\n```\n\nAlso, it is possible to define style to multiple classes in one statement:\n\n```\nclassDef firstClassName,secondClassName font-size:12pt;\n```\n\nAttachment of a class to a node is done as per below:\n\n```\ncssClass \"nodeId1\" className;\n```\n\nIt is also possible to attach a class to a list of nodes in one statement:\n\n```\ncssClass \"nodeId1,nodeId2\" className;\n```\n\nA shorter form of adding a class is to attach the classname to the node using the `:::` operator:\n\n```mermaid-example\nclassDiagram\n    class Animal:::someclass\n    classDef someclass fill:#f96\n```\n\nOr:\n\n```mermaid-example\nclassDiagram\n    class Animal:::someclass {\n        -int sizeInFeet\n        -canEat()\n    }\n    classDef someclass fill:#f96\n```\n\n### Default class\n\nIf a class is named default it will be applied to all nodes. Specific styles and classes should be defined afterwards to override the applied default styling.\n\n```\nclassDef default fill:#f9f,stroke:#333,stroke-width:4px;\n```\n\n```mermaid-example\nclassDiagram\n  class Animal:::pink\n  class Mineral\n\n  classDef default fill:#f96,color:red\n  classDef pink color:#f9f\n```\n\n### CSS Classes\n\nIt is also possible to predefine classes in CSS styles that can be applied from the graph definition as in the example\nbelow:\n\n**Example style**\n\n```html\n\n```\n\n**Example definition**\n\n```mermaid-example\nclassDiagram\n    class Animal:::styleClass\n```\n\n> cssClasses cannot be added using this shorthand method at the same time as a relation statement.\n\n## Configuration\n\n### Members Box\n\nIt is possible to hide the empty members box of a class node.\n\nThis is done by changing the **hideEmptyMembersBox** value of the class diagram configuration. For more information on how to edit the Mermaid configuration see the [configuration page.](https://mermaid.js.org/config/configuration.html)\n\n### Possible configuration parameters:\n\n| Parameter           | Description                                                  | Default value |\n| ------------------- | ------------------------------------------------------------ | ------------- |\n| hideEmptyMembersBox | Hides the empty members box of a class node when set to true | false         |\n\n```mermaid-example\n---\n  config:\n    class:\n      hideEmptyMembersBox: true\n---\nclassDiagram\n  class Duck\n```\n","packages/mermaid/src/docs/syntax/cynefin.md":"# Cynefin Framework Diagram (v11.16.0+)\n\n> The Cynefin framework is a sense-making framework created by [Dave Snowden](https://en.wikipedia.org/wiki/Dave_Snowden) that categorizes problems into five complexity domains. It helps teams match their response to the nature of the situation they are facing. The name is Welsh for \"place\" or \"habitat\".\n\nYou can read more at [The Cynefin Co](https://thecynefin.co/about-us/about-cynefin-framework).\n\n## Introduction\n\nThe Cynefin framework divides the world into five domains, each with its own decision-making approach:\n\n- **Clear** (formerly Obvious/Simple): Cause and effect are obvious. Sense → Categorise → Respond. Apply **best practices**.\n- **Complicated**: Cause and effect require analysis or expertise. Sense → Analyse → Respond. Apply **good practices**.\n- **Complex**: Cause and effect can only be deduced in retrospect. Probe → Sense → Respond. Apply **emergent practices**.\n- **Chaotic**: No perceivable cause and effect. Act → Sense → Respond. Apply **novel practices**.\n- **Confusion** (or Disorder): You do not know which domain you are in. The goal is to move items out of this state into one of the other four.\n\nThe signature visual feature is the wavy, organic boundary between the ordered (Clear, Complicated) and unordered (Complex, Chaotic) halves, and the \"cliff\" between Clear and Chaotic representing the risk of complacency leading to crisis.\n\n## Syntax\n\nA Cynefin diagram is declared with `cynefin-beta` followed by domain blocks and optional transitions.\n\n```md\ncynefin-beta\ntitle Optional Diagram Title\n\ncomplex\n\"Item label\"\n\"Another item\"\n\ncomplicated\n\"Expert analysis needed\"\n\nclear\n\"Known procedure\"\n\nchaotic\n\"Crisis response\"\n\nconfusion\n\"Item of unknown domain\"\n\ncomplex --> complicated : \"Pattern identified\"\nclear --> chaotic : \"Complacency\"\n```\n\n### Keywords\n\n| Keyword        | Meaning                                                                |\n| -------------- | ---------------------------------------------------------------------- |\n| `cynefin-beta` | Diagram type declaration (required, first line after any front matter) |\n| `title`        | Optional diagram title                                                 |\n| `complex`      | Opens the Complex domain block                                         |\n| `complicated`  | Opens the Complicated domain block                                     |\n| `clear`        | Opens the Clear domain block                                           |\n| `chaotic`      | Opens the Chaotic domain block                                         |\n| `confusion`    | Opens the Confusion / Disorder domain block                            |\n| `-->`          | Declares a transition from one domain to another                       |\n\n### Items\n\nItems are quoted string labels placed on their own lines inside a domain block. Each item renders as a text badge within the domain region.\n\n```\ncomplex\n  \"Investigate root cause\"\n  \"Run chaos experiment\"\n```\n\nKeep per-domain item lists short — the quadrants have fixed layout and long lists can visually overflow their boxes. The confusion ellipse caps at three items and shows a `+N more` badge; the four quadrant domains do not clip, so prefer a handful of items each.\n\n### Transitions\n\nTransitions represent movement of items between domains over time. They are declared at the top level using `-->` between two domain names, with an optional label.\n\n```\ncomplex --> complicated : \"Pattern identified\"\nclear --> chaotic : \"Complacency\"\nchaotic --> complex : \"Stabilized\"\n```\n\nCommon transitions:\n\n- **Complex → Complicated**: An emerging pattern has become understood and can now be analyzed.\n- **Chaotic → Complex**: A crisis has been stabilized enough to begin probing.\n- **Clear → Chaotic**: Complacency or over-constraint has led to collapse (the \"cliff\").\n- **Complicated → Clear**: Analysis has codified a solution into a standard practice.\n\n## Examples\n\n### Basic example\n\n```mermaid-example\ncynefin-beta\n  title Incident Response\n\n  complex\n    \"Investigate root cause\"\n    \"Run chaos experiment\"\n\n  complicated\n    \"Analyze performance data\"\n    \"Expert review needed\"\n\n  clear\n    \"Restart service\"\n    \"Apply known fix\"\n\n  chaotic\n    \"Page on-call immediately\"\n\n  confusion\n    \"Unknown failure mode\"\n```\n\n### With transitions\n\n```mermaid-example\ncynefin-beta\n  title Strategy Categorization\n\n  complex\n    \"Market research\"\n\n  complicated\n    \"Competitive analysis\"\n\n  clear\n    \"Standard pricing\"\n\n  chaotic\n    \"Crisis management\"\n\n  complex --> complicated : \"Pattern identified\"\n  complicated --> clear : \"Best practice codified\"\n  clear --> chaotic : \"Complacency\"\n  chaotic --> complex : \"Stabilized\"\n```\n\n### Empty framework\n\nThe domains themselves render even with no items, useful as a teaching or worksheet template.\n\n```mermaid-example\ncynefin-beta\n  title Cynefin Framework\n\n  complex\n  complicated\n  clear\n  chaotic\n```\n\n## Configuration\n\nCynefin diagrams accept the following configuration under the `cynefin` key in the mermaid config:\n\n| Option                   | Type    | Default | Description                                                                                                                                                                                                                  |\n| ------------------------ | ------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `width`                  | number  | `800`   | Width of the diagram in pixels                                                                                                                                                                                               |\n| `height`                 | number  | `600`   | Height of the diagram in pixels                                                                                                                                                                                              |\n| `padding`                | number  | `40`    | Padding around the diagram                                                                                                                                                                                                   |\n| `showDomainDescriptions` | boolean | `true`  | Show decision model and practice type subtitles per domain                                                                                                                                                                   |\n| `boundaryAmplitude`      | number  | `8`     | Waviness amplitude of domain boundaries in pixels (set to `0` for straight lines)                                                                                                                                            |\n| `seed`                   | number  | `0`     | Deterministic seed for boundary waviness. `0` (default) hashes the diagram's SVG id so each diagram looks unique. Set any non-zero number to lock the waviness across renders — required for stable visual regression tests. |\n\nExample:\n\n```\n---\nconfig:\n  cynefin:\n    width: 1000\n    showDomainDescriptions: false\n---\ncynefin-beta\n  complex\n    \"Adaptive work\"\n```\n\n## Theming\n\nCynefin diagrams use the following theme variables, which can be overridden via `themeVariables.cynefin`:\n\n| Variable         | Description                                      |\n| ---------------- | ------------------------------------------------ |\n| `complexBg`      | Background color for the Complex domain          |\n| `complicatedBg`  | Background color for the Complicated domain      |\n| `clearBg`        | Background color for the Clear domain            |\n| `chaoticBg`      | Background color for the Chaotic domain          |\n| `confusionBg`    | Background color for the Confusion center region |\n| `boundaryColor`  | Color of the wavy domain boundaries              |\n| `boundaryWidth`  | Stroke width of the boundaries                   |\n| `cliffColor`     | Color of the Clear/Chaotic cliff                 |\n| `cliffWidth`     | Stroke width of the cliff                        |\n| `arrowColor`     | Color of transition arrows                       |\n| `arrowWidth`     | Stroke width of transition arrows                |\n| `labelColor`     | Color of domain name labels                      |\n| `textColor`      | Color of item and subtitle text                  |\n| `domainFontSize` | Font size of domain name labels                  |\n| `itemFontSize`   | Font size of item badges and subtitles           |\n\n## Notes\n\n- Domain names are fixed keywords. Only `complex`, `complicated`, `clear`, `chaotic`, and `confusion` are recognized.\n- Domains can be declared in any order; their position in the diagram is always the same (Complex top-left, Complicated top-right, Chaotic bottom-left, Clear bottom-right, Confusion center).\n- The `confusion` domain has a compact center ellipse. Up to 3 items are shown inside it; if more are provided a `+N more` overflow badge is displayed. In practice, the confusion domain should contain very few items — its purpose is to surface unknowns so they can be moved to one of the four main domains.\n- Self-loop transitions (e.g. `complex --> complex`) are silently ignored. Transitions must connect two different domains.\n- Handdrawn mode is not currently supported.\n- The wavy boundary rendering is deterministic: the same input always produces the same diagram, so diffs are stable across builds.\n\n## Accessibility\n\nCynefin diagrams support the standard mermaid accessibility directives:\n\n```\ncynefin-beta\n  accTitle: Cynefin framework for software delivery decisions\n  accDescr: A Cynefin map categorizing software tasks by complexity domain\n\n  complex\n    \"New feature discovery\"\n```\n","packages/mermaid/src/docs/syntax/entityRelationshipDiagram.md":"# Entity Relationship Diagrams\n\n> An entity–relationship model (or ER model) describes interrelated things of interest in a specific domain of knowledge. A basic ER model is composed of entity types (which classify the things of interest) and specifies relationships that can exist between entities (instances of those entity types) [Wikipedia](https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model).\n\nNote that practitioners of ER modelling almost always refer to _entity types_ simply as _entities_. For example the `CUSTOMER` entity _type_ would be referred to simply as the `CUSTOMER` entity. This is so common it would be inadvisable to do anything else, but technically an entity is an abstract _instance_ of an entity type, and this is what an ER diagram shows - abstract instances, and the relationships between them. This is why entities are always named using singular nouns.\n\nMermaid can render ER diagrams\n\n```mermaid-example\n---\ntitle: Order example\n---\nerDiagram\n    CUSTOMER ||--o{ ORDER : places\n    ORDER ||--|{ LINE-ITEM : contains\n    CUSTOMER }|..|{ DELIVERY-ADDRESS : uses\n```\n\nEntity names are often capitalised, although there is no accepted standard on this, and it is not required in Mermaid.\n\nRelationships between entities are represented by lines with end markers representing cardinality. Mermaid uses the most popular crow's foot notation. The crow's foot intuitively conveys the possibility of many instances of the entity that it connects to.\n\nER diagrams can be used for various purposes, ranging from abstract logical models devoid of any implementation details, through to physical models of relational database tables. It can be useful to include attribute definitions on ER diagrams to aid comprehension of the purpose and meaning of entities. These do not necessarily need to be exhaustive; often a small subset of attributes is enough. Mermaid allows them to be defined in terms of their _type_ and _name_.\n\n```mermaid-example\nerDiagram\n    CUSTOMER ||--o{ ORDER : places\n    CUSTOMER {\n        string name\n        string custNumber\n        string sector\n    }\n    ORDER ||--|{ LINE-ITEM : contains\n    ORDER {\n        int orderNumber\n        string deliveryAddress\n    }\n    LINE-ITEM {\n        string productCode\n        int quantity\n        float pricePerUnit\n    }\n```\n\nWhen including attributes on ER diagrams, you must decide whether to include foreign keys as attributes. This probably depends on how closely you are trying to represent relational table structures. If your diagram is a _logical_ model which is not meant to imply a relational implementation, then it is better to leave these out because the associative relationships already convey the way that entities are associated. For example, a JSON data structure can implement a one-to-many relationship without the need for foreign key properties, using arrays. Similarly an object-oriented programming language may use pointers or references to collections. Even for models that are intended for relational implementation, you might decide that inclusion of foreign key attributes duplicates information already portrayed by the relationships, and does not add meaning to entities. Ultimately, it's your choice.\n\n## Default theme, look and layout (v12.0.0+)\n\nEntity relationship diagrams use the `redux-color` theme and the `neo` look by default, and are laid out by [ELK](https://www.eclipse.org/elk/) rather than Dagre. Not every diagram type\ndoes — see [Per-diagram defaults](../config/theming.md#per-diagram-defaults) for the list and\nfor the order in which Mermaid decides.\n\nThe same diagram, drawn both ways:\n\n### With the defaults\n\n```mermaid-example\nerDiagram\n  CUSTOMER ||--o{ ORDER : places\n  ORDER ||--|{ LINE_ITEM : contains\n  PRODUCT ||--o{ LINE_ITEM : \"appears in\"\n  CUSTOMER {\n    string name\n    string email\n  }\n  ORDER {\n    int id\n    date placedAt\n  }\n  LINE_ITEM {\n    int quantity\n    float price\n  }\n  PRODUCT {\n    string sku\n    string title\n  }\n```\n\n### The previous appearance\n\nBoth are only defaults, so anything you set yourself wins. Naming the previous theme and look\nin a diagram's front matter draws it the way Mermaid did before:\n\n```mermaid-example\n---\nconfig:\n  theme: default\n  look: classic\n  layout: dagre\n---\nerDiagram\n  CUSTOMER ||--o{ ORDER : places\n  ORDER ||--|{ LINE_ITEM : contains\n  PRODUCT ||--o{ LINE_ITEM : \"appears in\"\n  CUSTOMER {\n    string name\n    string email\n  }\n  ORDER {\n    int id\n    date placedAt\n  }\n  LINE_ITEM {\n    int quantity\n    float price\n  }\n  PRODUCT {\n    string sku\n    string title\n  }\n```\n\nPassing the same three keys to `mermaid.initialize()` does it for every diagram on the page,\nand scoping the theme and look to one diagram type — `mermaid.initialize({ layout: 'dagre', er: { theme: 'default', look: 'classic' } })` —\ndoes it for that type alone. `layout` is a top-level option, so it applies to every diagram.\n\n## Syntax\n\n### Entities and Relationships\n\nMermaid syntax for ER diagrams is compatible with PlantUML, with an extension to label the relationship. Each statement consists of the following parts:\n\n```\n     [  : ]\n```\n\nWhere:\n\n- `first-entity` is the name of an entity. Names support any unicode characters and can include spaces if surrounded by double quotes (e.g. \"name with space\").\n- `relationship` describes the way that both entities inter-relate. See below.\n- `second-entity` is the name of the other entity.\n- `relationship-label` describes the relationship from the perspective of the first entity.\n\nFor example:\n\n```\n    PROPERTY ||--|{ ROOM : contains\n```\n\nThis statement can be read as _a property contains one or more rooms, and a room is part of one and only one property_. You can see that the label here is from the first entity's perspective: a property contains a room, but a room does not contain a property. When considered from the perspective of the second entity, the equivalent label is usually very easy to infer. (Some ER diagrams label relationships from both perspectives, but this is not supported here, and is usually superfluous).\n\nOnly the `first-entity` part of a statement is mandatory. This makes it possible to show an entity with no relationships, which can be useful during iterative construction of diagrams. If any other parts of a statement are specified, then all parts are mandatory.\n\n#### Unicode text\n\nEntity names, relationships, and attributes all support unicode text.\n\n```mermaid-example\nerDiagram\n    \"This ❤ Unicode\"\n```\n\n#### Markdown formatting\n\nMarkdown formatting and text is also supported.\n\n```mermaid-example\nerDiagram\n    \"This **is** _Markdown_\"\n```\n\n### Relationship Syntax\n\nThe `relationship` part of each statement can be broken down into three sub-components:\n\n- the cardinality of the first entity with respect to the second\n- whether the relationship confers identity on a 'child' entity\n- the cardinality of the second entity with respect to the first\n\nCardinality is a property that describes how many elements of another entity can be related to the entity in question. In the above example a `PROPERTY` can have one or more `ROOM` instances associated to it, whereas a `ROOM` can only be associated with one `PROPERTY`. In each cardinality marker there are two characters. The outermost character represents a maximum value, and the innermost character represents a minimum value. The table below summarises possible cardinalities.\n\n| Value (left) | Value (right) | Meaning                       |\n| :----------: | :-----------: | ----------------------------- |\n|    `\\|o`     |     `o\\|`     | Zero or one                   |\n|    `\\|\\|`    |    `\\|\\|`     | Exactly one                   |\n|     `}o`     |     `o{`      | Zero or more (no upper limit) |\n|    `}\\|`     |     `\\|{`     | One or more (no upper limit)  |\n\n**Aliases**\n\n| Value (left) | Value (right) | Alias for    |\n| :----------: | :-----------: | ------------ |\n| one or zero  |  one or zero  | Zero or one  |\n| zero or one  |  zero or one  | Zero or one  |\n| one or more  |  one or more  | One or more  |\n| one or many  |  one or many  | One or more  |\n|   many(1)    |    many(1)    | One or more  |\n|      1+      |      1+       | One or more  |\n| zero or more | zero or more  | Zero or more |\n| zero or many | zero or many  | Zero or more |\n|   many(0)    |    many(0)    | Zero or more |\n|      0+      |      0+       | Zero or more |\n|   only one   |   only one    | Exactly one  |\n|      1       |       1       | Exactly one  |\n\n### Identification\n\nRelationships may be classified as either _identifying_ or _non-identifying_ and these are rendered with either solid or dashed lines respectively. This is relevant when one of the entities in question cannot have independent existence without the other. For example a firm that insures people to drive cars might need to store data on `NAMED-DRIVER`s. In modelling this we might start out by observing that a `CAR` can be driven by many `PERSON` instances, and a `PERSON` can drive many `CAR`s - both entities can exist without the other, so this is a non-identifying relationship that we might specify in Mermaid as: `PERSON }|..|{ CAR : \"driver\"`. Note the two dots in the middle of the relationship that will result in a dashed line being drawn between the two entities. But when this many-to-many relationship is resolved into two one-to-many relationships, we observe that a `NAMED-DRIVER` cannot exist without both a `PERSON` and a `CAR` - the relationships become identifying and would be specified using hyphens, which translate to a solid line:\n\n| Value |     Alias for     |\n| :---: | :---------------: |\n|  --   |   _identifying_   |\n|  ..   | _non-identifying_ |\n\n**Aliases**\n\n|     Value     |     Alias for     |\n| :-----------: | :---------------: |\n|      to       |   _identifying_   |\n| optionally to | _non-identifying_ |\n\n```mermaid-example\nerDiagram\n    CAR ||--o{ NAMED-DRIVER : allows\n    PERSON }o..o{ NAMED-DRIVER : is\n```\n\n```mermaid-example\nerDiagram\n    CAR 1 to zero or more NAMED-DRIVER : allows\n    PERSON many(0) optionally to 0+ NAMED-DRIVER : is\n```\n\n### Attributes\n\nAttributes can be defined for entities by specifying the entity name followed by a block containing multiple `type name` pairs, where a block is delimited by an opening `{` and a closing `}`. The attributes are rendered inside the entity boxes. For example:\n\n```mermaid-example\nerDiagram\n    CAR ||--o{ NAMED-DRIVER : allows\n    CAR {\n        string registrationNumber\n        string make\n        string model\n    }\n    PERSON ||--o{ NAMED-DRIVER : is\n    PERSON {\n        string firstName\n        string lastName\n        int age\n    }\n```\n\nThe `type` values must begin with an alphabetic character and may contain digits, hyphens, underscores, parentheses and square brackets. The `name` values follow a similar format to `type`, but may start with an asterisk as another option to indicate an attribute is a primary key. Other than that, there are no restrictions, and there is no implicit set of valid data types.\n\n#### Optional attribute types (v11.16.0+)\n\nAttribute `type` values may end with `?` to indicate an optional or nullable type.\n\n```mermaid-example\nerDiagram\n    PERSON {\n        string firstName\n        string? middleName\n        string lastName\n    }\n```\n\n### Entity Name Aliases\n\nAn alias can be added to an entity using square brackets. If provided, the alias will be showed in the diagram instead of the entity name. Alias names follow all of the same rules as entity names.\n\n```mermaid-example\nerDiagram\n    p[Person] {\n        string firstName\n        string lastName\n    }\n    a[\"Customer Account\"] {\n        string email\n    }\n    p ||--o| a : has\n```\n\n#### Attribute Keys and Comments\n\nAttributes may also have a `key` or comment defined. Keys can be `PK`, `FK` or `UK`, for Primary Key, Foreign Key or Unique Key (markdown formatting and unicode is not supported for keys). To specify multiple key constraints on a single attribute, separate them with a comma (e.g., `PK, FK`). A `comment` is defined by double quotes at the end of an attribute. Comments themselves cannot have double-quote characters in them.\n\n```mermaid-example\nerDiagram\n    CAR ||--o{ NAMED-DRIVER : allows\n    CAR {\n        string registrationNumber PK\n        string make\n        string model\n        string[] parts\n    }\n    PERSON ||--o{ NAMED-DRIVER : is\n    PERSON {\n        string driversLicense PK \"The license #\"\n        string(99) firstName \"Only 99 characters are allowed\"\n        string lastName\n        string phone UK\n        int age\n    }\n    NAMED-DRIVER {\n        string carRegistrationNumber PK, FK\n        string driverLicence PK, FK\n    }\n    MANUFACTURER only one to zero or more CAR : makes\n```\n\n### Direction\n\nThe direction statement declares the direction of the diagram.\n\nThis declares that the diagram is oriented from top to bottom (`TB`). This can be reversed to be oriented from bottom to top (`BT`).\n\n```mermaid-example\nerDiagram\n    direction TB\n    CUSTOMER ||--o{ ORDER : places\n    CUSTOMER {\n        string name\n        string custNumber\n        string sector\n    }\n    ORDER ||--|{ LINE-ITEM : contains\n    ORDER {\n        int orderNumber\n        string deliveryAddress\n    }\n    LINE-ITEM {\n        string productCode\n        int quantity\n        float pricePerUnit\n    }\n```\n\nThis declares that the diagram is oriented from left to right (`LR`). This can be reversed to be oriented from right to left (`RL`).\n\n```mermaid-example\nerDiagram\n    direction LR\n    CUSTOMER ||--o{ ORDER : places\n    CUSTOMER {\n        string name\n        string custNumber\n        string sector\n    }\n    ORDER ||--|{ LINE-ITEM : contains\n    ORDER {\n        int orderNumber\n        string deliveryAddress\n    }\n    LINE-ITEM {\n        string productCode\n        int quantity\n        float pricePerUnit\n    }\n```\n\nPossible diagram orientations are:\n\n- TB - Top to bottom\n- BT - Bottom to top\n- RL - Right to left\n- LR - Left to right\n\n### Subgraphs (v11.17.0+)\n\nSubgraphs allow grouping entities into logical sections within an ER diagram. They are useful for organizing\ncomplex diagrams and improving readability.\n\nSubgraphs can contain entities, relationships, and even other subgraphs (nested subgraphs).\n\n```\nsubgraph title\n    graph definition\nend\n```\n\nAn example below:\n\n```mermaid-example\nerDiagram\n    subgraph title1\n        CUSTOMER\n        CUSTOMER {\n            string name\n            string custNumber\n            string sector\n        }\n    end\n    subgraph title2\n        CAR ||--o{ NAMED-DRIVER : allows\n        subgraph title3\n            PERSON\n            PERSON {\n                string firstName\n                string lastName\n                int age\n            }\n        end\n    end\n```\n\nA subgraph always has an `id`, and optionally a `title`.\n\nIf the subgraph name is a single word, it is used as both id and title:\n\n```mermaid-example\nerDiagram\n    subgraph title1\n        CUSTOMER\n    end\n```\n\nIf the subgraph identifier contains more than one word, it must be written in `quotes`. In this case, the quoted value is used both as the id and the title.\n\n```mermaid-example\nerDiagram\n    subgraph \"Customer Domain\"\n        CUSTOMER\n    end\n```\n\nYou can also set an explicit id for the subgraph.\n\n```mermaid-example\nerDiagram\n    subgraph id1 [title 1]\n        CUSTOMER\n    end\n```\n\n````note\nSubgraphs are always referenced by their id, never by their title.\n\nThis is important when defining relationships involving subgraphs.\n\n**If a subgraph id contains spaces, it must be referenced using quotes:**\n\n```\"Customer Domain\" ||--o{ ORDER : contains```\n````\n\n#### Relationships involving subgraphs\n\nIt is also possible to define relationships to and from subgraphs.\n\n```mermaid-example\nerDiagram\n    subgraph title1\n        A1 ||--|| A2 : links\n    end\n\n    subgraph title2\n        B1 ||--|| B2 : links\n    end\n\n    subgraph title3\n        C1 ||--|| C2 : links\n    end\n\n    title1 ||--|| title2 : links\n    title2 ||--|| title3 : links\n    title2 ||--|| C2 : links\n```\n\n#### Direction in subgraphs\n\nA subgraph can define its own layout direction.\n\n```mermaid-example\nerDiagram\n    direction LR\n    subgraph TOP\n        direction TB\n        subgraph B1\n            direction RL\n            I1 ||--|| F1 : links\n        end\n        subgraph B2\n            direction BT\n            I2 ||--|| F2 : links\n        end\n    end\n    A ||--|| TOP : links\n    TOP ||--|| B : links\n    B1 ||--|| B2 : links\n```\n\n### Styling a node\n\nIt is possible to apply specific styles such as a thicker border or a different background color to a node.\n\n```mermaid-example\nerDiagram\n    id1||--||id2 : label\n    style id1 fill:#f9f,stroke:#333,stroke-width:4px\n    style id2 fill:#bbf,stroke:#f66,stroke-width:2px,color:#fff,stroke-dasharray: 5 5\n```\n\nIt is also possible to attach styles to a list of nodes in one statement:\n\n```\n    style nodeId1,nodeId2 styleList\n```\n\n#### Classes\n\nMore convenient than defining the style every time is to define a class of styles and attach this class to the nodes that\nshould have a different look.\n\nA class definition looks like the example below:\n\n```\n    classDef className fill:#f9f,stroke:#333,stroke-width:4px\n```\n\nIt is also possible to define multiple classes in one statement:\n\n```\n    classDef firstClassName,secondClassName font-size:12pt\n```\n\nAttachment of a class to a node is done as per below:\n\n```\n    class nodeId1 className\n```\n\nIt is also possible to attach a class to a list of nodes in one statement:\n\n```\n    class nodeId1,nodeId2 className\n```\n\nMultiple classes can be attached at the same time as well:\n\n```\n    class nodeId1,nodeId2 className1,className2\n```\n\nA shorter form of adding a class is to attach the classname to the node using the `:::`operator as per below:\n\n```mermaid-example\nerDiagram\n    direction TB\n    CAR:::someclass {\n        string registrationNumber\n        string make\n        string model\n    }\n    PERSON:::someclass {\n        string firstName\n        string lastName\n        int age\n    }\n    HOUSE:::someclass\n\n    classDef someclass fill:#f96\n```\n\nThis form can be used when declaring relationships between entities:\n\n```mermaid-example\nerDiagram\n    CAR {\n        string registrationNumber\n        string make\n        string model\n    }\n    PERSON {\n        string firstName\n        string lastName\n        int age\n    }\n    PERSON:::foo ||--|| CAR : owns\n    PERSON o{--|| HOUSE:::bar : has\n\n    classDef foo stroke:#f00\n    classDef bar stroke:#0f0\n    classDef foobar stroke:#00f\n```\n\nSimilar to the class statement, the shorthand syntax can also apply multiple classes at once:\n\n```\n    nodeId:::className1,className2\n```\n\n### Default class\n\nIf a class is named default it will be assigned to all classes without specific class definitions.\n\n```\n    classDef default fill:#f9f,stroke:#333,stroke-width:4px;\n```\n\n> **Note:** Custom styles from style or other class statements take priority and will overwrite the default styles. (e.g. The `default` class gives nodes a background color of pink but the `blue` class will give that node a background color of blue if applied.)\n\n```mermaid-example\nerDiagram\n    CAR {\n        string registrationNumber\n        string make\n        string model\n    }\n    PERSON {\n        string firstName\n        string lastName\n        int age\n    }\n    PERSON:::foo ||--|| CAR : owns\n    PERSON o{--|| HOUSE:::bar : has\n\n    classDef default fill:#f9f,stroke-width:4px\n    classDef foo stroke:#f00\n    classDef bar stroke:#0f0\n    classDef foobar stroke:#00f\n```\n\n## Configuration\n\n### Layout\n\nThe layout of the diagram is handled by [`render()`](../config/setup/mermaid/interfaces/Mermaid.md#render). The default layout is the ELK (Eclipse Layout Kernel) layout, which suits larger and more-complex diagrams. For more information, see [Customizing ELK Layout](../intro/syntax-reference.md#customizing-elk-layout).\n\nTo use the classic Dagre layout instead, set it in your YAML frontmatter's `config`:\n\n```yaml\n---\nconfig:\n  layout: dagre\n---\n```\n\nYour Mermaid code should be similar to the following:\n\n```mermaid-example\n---\ntitle: Order example\nconfig:\n    layout: dagre\n---\nerDiagram\n    CUSTOMER ||--o{ ORDER : places\n    ORDER ||--|{ LINE-ITEM : contains\n    CUSTOMER }|..|{ DELIVERY-ADDRESS : uses\n```\n\n\n","packages/mermaid/src/docs/syntax/eventmodeling.md":"# Event Modeling Diagram (v11.15.0+)\n\n## Introduction\n\n> **Event Modeling** (EM) is a method of describing systems using an example of how information has changed within them over time. Event Modeling specifically omits transient details and looks at what the information flow is and what the user sees at any particular point in time.\n\nYou can read more at [Event Modeling web page](https://eventmodeling.org/).\n\nEvent Modeling diagram is composed of a few main entities:\n\n- Trigger - UI and Processor\n- Command\n- View / Read Model\n- Event\n\nEntities are organized in swimlanes forming a timeline usually based on the following patterns:\n\n- State View\n- State Change\n- Translation\n- Automation\n\nYou can find more details in the [cheat sheet](https://eventmodeling.org/posts/event-modeling-cheatsheet/).\n\nThe purpose of the Domain Specific Language (DSL) supporting the drawing of the Event Modeling diagram is the rapid creation. Relations among the entities are inferred by default, so the distraction while you design is limited. Further detail to the entities can be added gradually.\n\nThe grammar for the DSL is also maintained in a [separate project](https://github.com/lgazo/event-modeling-dsl) with the intention to provide also different types of output, VS Code (and potentially other) IDEs, etc.\n\n## Basic Syntax\n\nThe DSL supports two types of syntaxes - compact and relaxed one. Both will be mentioned in the examples and both can be used interchangeably.\n\n### Timeline\n\nThe timeline is the key part of the diagram and it is composed of **Time Frame** definitions. Speedy Time Frame typing is the key of the compact notation. For compact notation you type the `tf` token. For the relaxed notation you type `timeframe` token.\n\n```md\neventmodeling\n\ntf 01 ui CartUI\ntf 02 cmd AddItem\ntf 03 evt ItemAdded\n```\n\nrendering to\n\n```mermaid\neventmodeling\n\ntf 01 ui CartUI\ntf 02 cmd AddItem\ntf 03 evt ItemAdded\n```\n\nEach Time Frame is referenced by a **unique number** in order to distinguish one from another and also to be able to reference it when needed. Depending on the complexity of the diagram it should be enough to have just two digit number or more. Imagine you are typing a BASIC program on your ZX Spectrum always starting with a two digit number, but the order of the numbers does not matter, just the uniqueness in the whole timeline.\n\nReusing a number for another Time Frame or Reset Frame produces an error. Give each frame its own number before referring to it with `->>`.\n\nThe Time Frame also contains an **Entity Identifier**, e.g. in case of `01` Time Frame it is `CartUI`. One Entity Identifier can be used multiple times in the timeline for example when you want to express invocations of the same event in different points in time.\n\nRelaxed notation would look like this:\n\n```md\neventmodeling\n\ntimeframe 01 ui CartUI\ntimeframe 02 command AddItem\ntimeframe 03 event ItemAdded\n```\n\n### Inline data\n\nIt is possible to provide data examples for individual Time Frames. An Inline Data is wrapped in curly brackets on the same line as the Time Frame.\n\nCompact version:\n\n```mermaid-example\neventmodeling\n\ntf 01 ui CartUI\ntf 02 cmd AddItem { description: string }\ntf 03 evt ItemAdded { description: string }\n```\n\nRelaxed version:\n\n```mermaid-example\neventmodeling\n\ntimeframe 01 ui CartUI\ntimeframe 02 command AddItem { description: string }\ntimeframe 03 event ItemAdded { description: string }\n```\n\n### Data block\n\nIf you need to provide more complex data description, you can define the **Data Block** separately. Data Block is referenced from a Time Frame by providing the identifier inside of double-square brackets `[[identifier]]`, similar to wiki links convention in Markdown.\n\nIn case the same entity is repeated you need to uniquely identify the data blocks, therefore the Data Block identifier is suffixed with a number.\n\nCompact version:\n\n```mermaid-example\neventmodeling\n\ntf 01 ui CartUI\ntf 02 cmd AddItem [[AddItem01]]\ntf 03 evt ItemAdded [[ItemAdded]]\ntf 04 cmd AddItem [[AddItem02]]\ntf 05 evt ItemAdded [[ItemAdded]]\n\ndata AddItem01 {\n  description: 'john'\n  image: 'avatar_john'\n  price: 20.4\n}\n\ndata AddItem02 {\n  description: 'jack'\n  image: 'avatar_jack'\n  price: 12.5\n}\n\ndata ItemAdded {\n  description: string\n  image: string\n  price: number\n}\n```\n\nRelaxed version:\n\n```mermaid-example\neventmodeling\n\ntimeframe 01 ui CartUI\ntimeframe 02 command AddItem [[AddItem01]]\ntimeframe 03 event ItemAdded [[ItemAdded]]\ntimeframe 04 command AddItem [[AddItem02]]\ntimeframe 05 event ItemAdded [[ItemAdded]]\n\ndata AddItem01 {\n  description: 'john'\n  image: 'avatar_john'\n  price: 20.4\n}\n\ndata AddItem02 {\n  description: 'jack'\n  image: 'avatar_jack'\n  price: 12.5\n}\n\ndata ItemAdded {\n  description: string\n  image: string\n  price: number\n}\n```\n\n### Resetting the flow\n\nBy default the diagram builds the relations based on the inference. But modeling a more complex business flow requires to break such inference from time to time. For that you can use a different type of Time Frame called **Reset Frame**. It is represented by a `rf` / `resetframe` token.\n\nA reset frame stops the inferred relation from the preceding frame. You can still connect it to a specific earlier frame with `->>`.\n\nCompact version:\n\n```mermaid-example\neventmodeling\n\ntf 01 ui CartUI\ntf 02 cmd AddItem\ntf 03 evt ItemAdded\n\nrf 04 evt External.InventoryChanged\ntf 05 pcr InventoryProcessor\ntf 06 cmd ChangeInventory\ntf 07 evt Cart.InventoryChanged\n```\n\nRelaxed version:\n\n```mermaid-example\neventmodeling\n\ntimeframe 01 ui CartUI\ntimeframe 02 command AddItem\ntimeframe 03 event ItemAdded\n\nresetframe 04 event External.InventoryChanged\ntimeframe 05 processor InventoryProcessor\ntimeframe 06 command ChangeInventory\ntimeframe 07 event Cart.InventoryChanged\n```\n\nFor example, this read model receives input from `ItemAdded` without inferring a relation from `OtherUI`:\n\n```mermaid-example\neventmodeling\n\ntf 01 evt ItemAdded\ntf 02 ui OtherUI\nrf 03 rmo CartItems ->> 01\n```\n\n### Multiple relations\n\nThere are situations where you need to specify multiple relations for an entity. For example when a **Read Model** is built of multiple **Events**. You can use `->>` token for that.\n\n```mermaid-example\neventmodeling\n\nrf 02 evt CartCreated\nrf 03 evt ItemAdded\nrf 04 evt ItemRemoved\nrf 05 evt CartCleared\ntf 01 rmo CartUI ->> 02 ->> 03 ->> 04 ->> 05\n```\n\n## Event Modeling patterns\n\nThis chapter briefly summarizes each Event Modeling pattern.\n\n### State Change\n\n```mermaid-example\neventmodeling\n\ntf 01 ui CartUI\ntf 02 cmd AddItem\ntf 03 evt ItemAdded\n```\n\n### State View\n\n```mermaid-example\neventmodeling\n\ntf 03 evt ItemAdded\ntf 02 rmo CartItems\ntf 04 ui CartUI\n```\n\n### Translation\n\n```mermaid-example\neventmodeling\n\ntf 03 evt External.InventoryChanged\ntf 02 pcr InventoryProcessor\ntf 04 cmd ChangeInventory\ntf 05 evt Cart.InventoryChanged\n```\n\n## Details of the Syntax\n\n### Entity types\n\nEntity type is determined by the third column in the Time Frame grammar.\n\nCompact version:\n\n```md\ntf 01 pcr InventoryProcessor\n```\n\nRelaxed version:\n\n```md\ntimeframe 01 processor InventoryProcessor\n```\n\nEntities are assigned to default swimlanes unless a **Namespace** is specified in the Entity Identifier.\n\nThere are the following types available:\n\n- `ui`: UI - belongs to UI/Automation swimlane\n- `pcr` / `processor`: Processor - belongs to UI/Automation swimlane\n- `cmd` / `command`: Command - belongs to Command/Read Model swimlane\n- `rmo` / `readmodel`: Read Model - belongs to Command/Read Model swimlane\n- `evt` / `event`: Event - belongs to Events swimlane\n\n### Swimlanes and Namespaces\n\nThere are three basic **Swimlanes** inferred from the Entity Type.\n\n- UI/Automation\n- Command/Read Model\n- Events\n\nAs your diagram grows and you explore the depths of a particular software system, you want to categorize your Entities as well. In order to do that, you can use **Namespace** identifier as part of the Entity Identifier.\n\n```md\nInventory.InventoryChanged\n```\n\n**Namespace** is the first part before the `.` of the Entity Identifier. Each combination of the Namespace and Entity type forms new Swimlane. The order how they are specified in the text definition specifies the order of the Swimlanes in the diagram.\n\n```mermaid-example\neventmodeling\n\nrf 01 evt Inventory.InventoryChanged\nrf 02 evt External.InventoryChanged\n```\n\n### Data block data types\n\nA **Data** is always wrapped in curly brackets. It can be prepended by a data type in backticks. The pattern applies for **Inline Data** as well as for **Data Block**.\n\n```md\ntf 01 rmo UserAdded `json`{ \"name\": \"foo\" }\n```\n\nor for Data Block\n\n```md\ndata UserAdded01 `json`{\n\"name\": \"foo\"\n}\n```\n\n```warning\nThere is no special treatment in the diagram renderer at the moment for a specific data type.\n```\n\nSupported types are:\n\n- `json`\n- `jsobj`\n- `figma`\n- `salt`\n- `uri`\n- `md`\n- `html`\n- `text`\n","packages/mermaid/src/docs/syntax/examples.md":"# Examples\n\nThis page contains a collection of examples of diagrams and charts that can be created through mermaid and its myriad applications.\n\n**If you wish to learn how to support mermaid on your webpage, read the [Beginner's Guide](../config/usage.md?id=usage).**\n\n**If you wish to learn about mermaid's syntax, Read the [Diagram Syntax](../syntax/flowchart.md?id=flowcharts-basic-syntax) section.**\n\n## Basic Pie Chart\n\n```mermaid-example\npie title NETFLIX\n         \"Time spent looking for movie\" : 90\n         \"Time spent watching it\" : 10\n```\n\n```mermaid-example\npie title What Voldemort doesn't have?\n         \"FRIENDS\" : 2\n         \"FAMILY\" : 3\n         \"NOSE\" : 45\n```\n\n## Basic sequence diagram\n\n```mermaid-example\nsequenceDiagram\n    Alice ->> Bob: Hello Bob, how are you?\n    Bob-->>John: How about you John?\n    Bob--x Alice: I am good thanks!\n    Bob-x John: I am good thanks!\n    Note right of John: Bob thinks a long
long time, so long
that the text does
not fit on a row.\n\n    Bob-->Alice: Checking with John...\n    Alice->John: Yes... John, how are you?\n```\n\n## Basic flowchart\n\n```mermaid-example\ngraph LR\n    A[Square Rect] -- Link text --> B((Circle))\n    A --> C(Round Rect)\n    B --> D{Rhombus}\n    C --> D\n```\n\n## Larger flowchart with some styling\n\n```mermaid-example\ngraph TB\n    sq[Square shape] --> ci((Circle shape))\n\n    subgraph A\n        od>Odd shape]-- Two line
edge comment --> ro\n        di{Diamond with 
 line break} -.-> ro(Rounded
square
shape)\n        di==>ro2(Rounded square shape)\n    end\n\n    %% Notice that no text in shape are added here instead that is appended further down\n    e --> od3>Really long text with linebreak
in an Odd shape]\n\n    %% Comments after double percent signs\n    e((Inner / circle
and some odd 
special characters)) --> f(,.?!+-*ز)\n\n    cyr[Cyrillic]-->cyr2((Circle shape Начало));\n\n     classDef green fill:#9f6,stroke:#333,stroke-width:2px;\n     classDef orange fill:#f96,stroke:#333,stroke-width:4px;\n     class sq,e green\n     class di orange\n```\n\n## SequenceDiagram: Loops, alt and opt\n\n```mermaid-example\nsequenceDiagram\n    loop Daily query\n        Alice->>Bob: Hello Bob, how are you?\n        alt is sick\n            Bob->>Alice: Not so good :(\n        else is well\n            Bob->>Alice: Feeling fresh like a daisy\n        end\n\n        opt Extra response\n            Bob->>Alice: Thanks for asking\n        end\n    end\n```\n\n## SequenceDiagram: Message to self in loop\n\n```mermaid-example\nsequenceDiagram\n    participant Alice\n    participant Bob\n    Alice->>John: Hello John, how are you?\n    loop HealthCheck\n        John->>John: Fight against hypochondria\n    end\n    Note right of John: Rational thoughts
prevail...\n    John-->>Alice: Great!\n    John->>Bob: How about you?\n    Bob-->>John: Jolly good!\n```\n\n## Sequence Diagram: Blogging app service communication\n\n```mermaid-example\nsequenceDiagram\n    participant web as Web Browser\n    participant blog as Blog Service\n    participant account as Account Service\n    participant mail as Mail Service\n    participant db as Storage\n\n    Note over web,db: The user must be logged in to submit blog posts\n    web->>+account: Logs in using credentials\n    account->>db: Query stored accounts\n    db->>account: Respond with query result\n\n    alt Credentials not found\n        account->>web: Invalid credentials\n    else Credentials found\n        account->>-web: Successfully logged in\n\n        Note over web,db: When the user is authenticated, they can now submit new posts\n        web->>+blog: Submit new post\n        blog->>db: Store post data\n\n        par Notifications\n            blog--)mail: Send mail to blog subscribers\n            blog--)db: Store in-site notifications\n        and Response\n            blog-->>-web: Successfully posted\n        end\n    end\n\n```\n\n## A commit flow diagram.\n\n```mermaid-example\ngitGraph:\n    commit \"Ashish\"\n    branch newbranch\n    checkout newbranch\n    commit id:\"1111\"\n    commit tag:\"test\"\n    checkout main\n    commit type: HIGHLIGHT\n    commit\n    merge newbranch\n    commit\n    branch b2\n    commit\n```\n\n\n","packages/mermaid/src/docs/syntax/flowchart.md":"---\ntitle: Flowcharts Syntax\n---\n\n# Flowcharts - Basic Syntax\n\nFlowcharts are composed of **nodes** (geometric shapes) and **edges** (arrows or lines). The Mermaid code defines how nodes and edges are made and accommodates different arrow types, multi-directional arrows, and any linking to and from subgraphs.\n\n```warning\nIf you are using the word \"end\" in a Flowchart node, capitalize the entire word or any of the letters (e.g., \"End\" or \"END\"), or apply this [workaround](https://github.com/mermaid-js/mermaid/issues/1444#issuecomment-639528897). Typing \"end\" in all lowercase letters will break the Flowchart.\n```\n\n```warning\nIf you are using the letter \"o\" or \"x\" as the first letter in a connecting Flowchart node, add a space before the letter or capitalize the letter (e.g., \"dev--- ops\", \"dev---Ops\").\n\nTyping \"A---oB\" will create a [circle edge](#circle-edge-example).\n\nTyping \"A---xB\" will create a [cross edge](#cross-edge-example).\n```\n\n### A node (default)\n\n```mermaid-example\n---\ntitle: Node\n---\nflowchart LR\n    id\n```\n\n```note\nThe id is what is displayed in the box.\n```\n\n```tip\nInstead of `flowchart` one can also use `graph`.\n```\n\n### A node with text\n\nIt is also possible to set text in the box that differs from the id. If this is done several times, it is the last text\nfound for the node that will be used. Also if you define edges for the node later on, you can omit text definitions. The\none previously defined will be used when rendering the box.\n\n```mermaid-example\n---\ntitle: Node with text\n---\nflowchart LR\n    id1[This is the text in the box]\n```\n\n#### Unicode text\n\nUse `\"` to enclose the unicode text.\n\n```mermaid-example\nflowchart LR\n    id[\"This ❤ Unicode\"]\n```\n\n#### Markdown formatting\n\nUse double quotes and backticks \"\\` text \\`\" to enclose the markdown text.\n\n```mermaid-example\n---\nconfig:\n  htmlLabels: false\n---\nflowchart LR\n    markdown[\"`This **is** _Markdown_`\"]\n    newLines[\"`Line1\n    Line 2\n    Line 3`\"]\n    markdown --> newLines\n```\n\n### Direction\n\nThis statement declares the direction of the Flowchart.\n\nThis declares the flowchart is oriented from top to bottom (`TD` or `TB`).\n\n```mermaid-example\nflowchart TD\n    Start --> Stop\n```\n\nThis declares the flowchart is oriented from left to right (`LR`).\n\n```mermaid-example\nflowchart LR\n    Start --> Stop\n```\n\nPossible FlowChart orientations are:\n\n- TB - Top to bottom\n- TD - Top-down/ same as top to bottom\n- BT - Bottom to top\n- RL - Right to left\n- LR - Left to right\n\n## Default theme, look and layout (v12.0.0+)\n\nFlowcharts use the `redux-color` theme and the `neo` look by default, and are laid out by [ELK](https://www.eclipse.org/elk/) rather than Dagre. Not every diagram type\ndoes — see [Per-diagram defaults](../config/theming.md#per-diagram-defaults) for the list and\nfor the order in which Mermaid decides.\n\nThe same diagram, drawn both ways:\n\n### With the defaults\n\n```mermaid-example\nflowchart LR\n  subgraph Client\n    UI[Web app]\n    Cache[(Local cache)]\n  end\n  subgraph Services\n    API[API gateway]\n    Auth[Auth service]\n    Orders[Order service]\n  end\n  subgraph Storage\n    DB[(Orders DB)]\n  end\n  UI --> API\n  UI --> Cache\n  API --> Auth\n  API --> Orders\n  Orders --> DB\n  Auth -. token .-> UI\n```\n\n### The previous appearance\n\nBoth are only defaults, so anything you set yourself wins. Naming the previous theme and look\nin a diagram's front matter draws it the way Mermaid did before:\n\n```mermaid-example\n---\nconfig:\n  theme: default\n  look: classic\n  layout: dagre\n---\nflowchart LR\n  subgraph Client\n    UI[Web app]\n    Cache[(Local cache)]\n  end\n  subgraph Services\n    API[API gateway]\n    Auth[Auth service]\n    Orders[Order service]\n  end\n  subgraph Storage\n    DB[(Orders DB)]\n  end\n  UI --> API\n  UI --> Cache\n  API --> Auth\n  API --> Orders\n  Orders --> DB\n  Auth -. token .-> UI\n```\n\nPassing the same three keys to `mermaid.initialize()` does it for every diagram on the page,\nand scoping the theme and look to one diagram type — `mermaid.initialize({ layout: 'dagre', flowchart: { theme: 'default', look: 'classic' } })` —\ndoes it for that type alone. `layout` is a top-level option, so it applies to every diagram.\n\n## Node shapes\n\n### A node with round edges\n\n```mermaid-example\nflowchart LR\n    id1(This is the text in the box)\n```\n\n### A stadium-shaped node\n\n```mermaid-example\nflowchart LR\n    id1([This is the text in the box])\n```\n\n### A node in a subroutine shape\n\n```mermaid-example\nflowchart LR\n    id1[[This is the text in the box]]\n```\n\n### A node in a cylindrical shape\n\n```mermaid-example\nflowchart LR\n    id1[(Database)]\n```\n\n### A node in the form of a circle\n\n```mermaid-example\nflowchart LR\n    id1((This is the text in the circle))\n```\n\n### A node in an asymmetric shape\n\n```mermaid-example\nflowchart LR\n    id1>This is the text in the box]\n```\n\nCurrently only the shape above is possible and not its mirror. _This might change with future releases._\n\n### A node (rhombus)\n\n```mermaid-example\nflowchart LR\n    id1{This is the text in the box}\n```\n\n### A hexagon node\n\n```mermaid-example\nflowchart LR\n    id1{{This is the text in the box}}\n```\n\n### Parallelogram\n\n```mermaid-example\nflowchart TD\n    id1[/This is the text in the box/]\n```\n\n### Parallelogram alt\n\n```mermaid-example\nflowchart TD\n    id1[\\This is the text in the box\\]\n```\n\n### Trapezoid\n\n```mermaid-example\nflowchart TD\n    A[/Christmas\\]\n```\n\n### Trapezoid alt\n\n```mermaid-example\nflowchart TD\n    B[\\Go shopping/]\n```\n\n### Double circle\n\n```mermaid-example\nflowchart TD\n    id1(((This is the text in the circle)))\n```\n\n## Expanded Node Shapes in Mermaid Flowcharts (v11.3.0+)\n\nMermaid introduces 30 new shapes to enhance the flexibility and precision of flowchart creation. These new shapes provide more options to represent processes, decisions, events, data storage visually, and other elements within your flowcharts, improving clarity and semantic meaning.\n\nNew Syntax for Shape Definition\n\nMermaid now supports a general syntax for defining shape types to accommodate the growing number of shapes. This syntax allows you to assign specific shapes to nodes using a clear and flexible format:\n\n```\nA@{ shape: rect }\n```\n\nThis syntax creates a node A as a rectangle. It renders in the same way as `A[\"A\"]`, or `A`.\n\n### Complete List of New Shapes\n\nBelow is a comprehensive list of the newly introduced shapes and their corresponding semantic meanings, short names, and aliases:\n\n\n\n### Example Flowchart with New Shapes\n\nHere’s an example flowchart that utilizes some of the newly introduced shapes:\n\n```mermaid-example\nflowchart RL\n    A@{ shape: manual-file, label: \"File Handling\"}\n    B@{ shape: manual-input, label: \"User Input\"}\n    C@{ shape: docs, label: \"Multiple Documents\"}\n    D@{ shape: procs, label: \"Process Automation\"}\n    E@{ shape: paper-tape, label: \"Paper Records\"}\n```\n\n### Process\n\n```mermaid-example\nflowchart TD\n    A@{ shape: rect, label: \"This is a process\" }\n```\n\n### Event\n\n```mermaid-example\nflowchart TD\n    A@{ shape: rounded, label: \"This is an event\" }\n```\n\n### Terminal Point (Stadium)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: stadium, label: \"Terminal point\" }\n```\n\n### Subprocess\n\n```mermaid-example\nflowchart TD\n    A@{ shape: subproc, label: \"This is a subprocess\" }\n```\n\n### Database (Cylinder)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: cyl, label: \"Database\" }\n```\n\n### Start (Circle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: circle, label: \"Start\" }\n```\n\n### Odd\n\n```mermaid-example\nflowchart TD\n    A@{ shape: odd, label: \"Odd shape\" }\n```\n\n### Decision (Diamond)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: diamond, label: \"Decision\" }\n```\n\n### Prepare Conditional (Hexagon)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: hex, label: \"Prepare conditional\" }\n```\n\n### Data Input/Output (Lean Right)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: lean-r, label: \"Input/Output\" }\n```\n\n### Data Input/Output (Lean Left)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: lean-l, label: \"Output/Input\" }\n```\n\n### Datastore (Top and bottom border)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: datastore, label: \"Datastore\" }\n```\n\n### Priority Action (Trapezoid Base Bottom)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: trap-b, label: \"Priority action\" }\n```\n\n### Manual Operation (Trapezoid Base Top)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: trap-t, label: \"Manual operation\" }\n```\n\n### Stop (Double Circle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: dbl-circ, label: \"Stop\" }\n```\n\n### Text Block\n\n```mermaid-example\nflowchart TD\n    A@{ shape: text, label: \"This is a text block\" }\n```\n\n### Card (Notched Rectangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: notch-rect, label: \"Card\" }\n```\n\n### Lined/Shaded Process\n\n```mermaid-example\nflowchart TD\n    A@{ shape: lin-rect, label: \"Lined process\" }\n```\n\n### Start (Small Circle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: sm-circ, label: \"Small start\" }\n```\n\n### Stop (Framed Circle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: framed-circle, label: \"Stop\" }\n```\n\n### Fork/Join (Long Rectangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: fork, label: \"Fork or Join\" }\n```\n\n### Collate (Hourglass)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: hourglass, label: \"Collate\" }\n```\n\n### Comment (Curly Brace)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: comment, label: \"Comment\" }\n```\n\n### Comment Right (Curly Brace Right)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: brace-r, label: \"Comment\" }\n```\n\n### Comment with braces on both sides\n\n```mermaid-example\nflowchart TD\n    A@{ shape: braces, label: \"Comment\" }\n```\n\n### Com Link (Lightning Bolt)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: bolt, label: \"Communication link\" }\n```\n\n### Document\n\n```mermaid-example\nflowchart TD\n    A@{ shape: doc, label: \"Document\" }\n```\n\n### Delay (Half-Rounded Rectangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: delay, label: \"Delay\" }\n```\n\n### Direct Access Storage (Horizontal Cylinder)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: das, label: \"Direct access storage\" }\n```\n\n### Disk Storage (Lined Cylinder)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: lin-cyl, label: \"Disk storage\" }\n```\n\n### Display (Curved Trapezoid)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: curv-trap, label: \"Display\" }\n```\n\n### Divided Process (Divided Rectangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: div-rect, label: \"Divided process\" }\n```\n\n### Extract (Small Triangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: tri, label: \"Extract\" }\n```\n\n### Internal Storage (Window Pane)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: win-pane, label: \"Internal storage\" }\n```\n\n### Junction (Filled Circle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: f-circ, label: \"Junction\" }\n```\n\n### Lined Document\n\n```mermaid-example\nflowchart TD\n    A@{ shape: lin-doc, label: \"Lined document\" }\n```\n\n### Loop Limit (Notched Pentagon)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: notch-pent, label: \"Loop limit\" }\n```\n\n### Manual File (Flipped Triangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: flip-tri, label: \"Manual file\" }\n```\n\n### Manual Input (Sloped Rectangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: sl-rect, label: \"Manual input\" }\n```\n\n### Multi-Document (Stacked Document)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: docs, label: \"Multiple documents\" }\n```\n\n### Multi-Process (Stacked Rectangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: processes, label: \"Multiple processes\" }\n```\n\n### Paper Tape (Flag)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: flag, label: \"Paper tape\" }\n```\n\n### Stored Data (Bow Tie Rectangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: bow-rect, label: \"Stored data\" }\n```\n\n### Summary (Crossed Circle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: cross-circ, label: \"Summary\" }\n```\n\n### Tagged Document\n\n```mermaid-example\nflowchart TD\n    A@{ shape: tag-doc, label: \"Tagged document\" }\n```\n\n### Tagged Process (Tagged Rectangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: tag-rect, label: \"Tagged process\" }\n```\n\n## Special shapes in Mermaid Flowcharts (v11.3.0+)\n\nMermaid also introduces 2 special shapes to enhance your flowcharts: **icon** and **image**. These shapes allow you to include icons and images directly within your flowcharts, providing more visual context and clarity.\n\n### Icon Shape\n\nYou can use the `icon` shape to include an icon in your flowchart. To use icons, you need to register the icon pack first. Follow the instructions to [add custom icons](../config/icons.md). The syntax for defining an icon shape is as follows:\n\n```mermaid-example\nflowchart TD\n    A@{ icon: \"fa:user\", form: \"square\", label: \"User Icon\", pos: \"t\", h: 60 }\n```\n\n#### Parameters\n\n- **icon**: The name of the icon from the registered icon pack.\n- **form**: Specifies the background shape of the icon. If not defined there will be no background to icon. Options include:\n  - `square`\n  - `circle`\n  - `rounded`\n- **label**: The text label associated with the icon. This can be any string. If not defined, no label will be displayed.\n- **pos**: The position of the label. If not defined label will default to bottom of icon. Possible values are:\n  - `t`\n  - `b`\n- **h**: The height of the icon. If not defined this will default to 48 which is minimum.\n\n### Image Shape\n\nYou can use the `image` shape to include an image in your flowchart. The syntax for defining an image shape is as follows:\n\n```\nflowchart TD\n    A@{ img: \"https://example.com/image.png\", label: \"Image Label\", pos: \"t\", w: 60, h: 60, constraint: \"off\" }\n```\n\n#### Parameters\n\n- **img**: The URL of the image to be displayed.\n- **label**: The text label associated with the image. This can be any string. If not defined, no label will be displayed.\n- **pos**: The position of the label. If not defined, the label will default to the bottom of the image. Possible values are:\n  - `t`\n  - `b`\n- **w**: The width of the image. If not defined, this will default to the natural width of the image.\n- **h**: The height of the image. If not defined, this will default to the natural height of the image.\n- **constraint**: Determines if the image should constrain the node size. This setting also ensures the image maintains its original aspect ratio, adjusting the width (`w`) accordingly to the height (`h`). If not defined, this will default to `off` Possible values are:\n  - `on`\n  - `off`\n\nIf you want to resize an image, but keep the same aspect ratio, set `h`, and set `constraint: on` to constrain the aspect ratio. E.g.\n\n```mermaid\nflowchart TD\n  %% My image with a constrained aspect ratio\n  A@{ img: \"https://mermaid.js.org/favicon.svg\", label: \"My example image label\", pos: \"t\", h: 60, constraint: \"on\" }\n```\n\n## Links between nodes\n\nNodes can be connected with links/edges. It is possible to have different types of links or attach a text string to a link.\n\n### A link with arrow head\n\n```mermaid-example\nflowchart LR\n    A-->B\n```\n\n### An open link\n\n```mermaid-example\nflowchart LR\n    A --- B\n```\n\n### Text on links\n\n```mermaid-example\nflowchart LR\n    A-- This is the text! ---B\n```\n\nor\n\n```mermaid-example\nflowchart LR\n    A---|This is the text|B\n```\n\n### A link with arrow head and text\n\n```mermaid-example\nflowchart LR\n    A-->|text|B\n```\n\nor\n\n```mermaid-example\nflowchart LR\n    A-- text -->B\n```\n\n### Dotted link\n\n```mermaid-example\nflowchart LR\n   A-.->B;\n```\n\n### Dotted link with text\n\n```mermaid-example\nflowchart LR\n   A-. text .-> B\n```\n\n### Thick link\n\n```mermaid-example\nflowchart LR\n   A ==> B\n```\n\n### Thick link with text\n\n```mermaid-example\nflowchart LR\n   A == text ==> B\n```\n\n### An invisible link\n\nThis can be a useful tool in some instances where you want to alter the default positioning of a node.\n\n```mermaid-example\nflowchart LR\n    A ~~~ B\n```\n\n### Chaining of links\n\nIt is possible declare many links in the same line as per below:\n\n```mermaid-example\nflowchart LR\n   A -- text --> B -- text2 --> C\n```\n\nIt is also possible to declare multiple nodes links in the same line as per below:\n\n```mermaid-example\nflowchart LR\n   a --> b & c--> d\n```\n\nYou can then describe dependencies in a very expressive way. Like the one-liner below:\n\n```mermaid-example\nflowchart TB\n    A & B--> C & D\n```\n\nIf you describe the same diagram using the basic syntax, it will take four lines. A\nword of warning, one could go overboard with this making the flowchart harder to read in\nmarkdown form. The Swedish word `lagom` comes to mind. It means, not too much and not too little.\nThis goes for expressive syntaxes as well.\n\n```mermaid\nflowchart TB\n    A --> C\n    A --> D\n    B --> C\n    B --> D\n```\n\n### Attaching an ID to Edges\n\nMermaid now supports assigning IDs to edges, similar to how IDs and metadata can be attached to nodes. This feature lays the groundwork for more advanced styling, classes, and animation capabilities on edges.\n\n**Syntax:**\n\nTo give an edge an ID, prepend the edge syntax with the ID followed by an `@` character. For example:\n\n```mermaid\nflowchart LR\n  A e1@--> B\n```\n\nIn this example, `e1` is the ID of the edge connecting `A` to `B`. You can then use this ID in later definitions or style statements, just like with nodes.\n\n### Turning an Animation On\n\nOnce you have assigned an ID to an edge, you can turn on animations for that edge by defining the edge’s properties:\n\n```mermaid\nflowchart LR\n  A e1@==> B\n  e1@{ animate: true }\n```\n\nThis tells Mermaid that the edge `e1` should be animated.\n\n### Selecting Type of Animation\n\nIn the initial version, two animation speeds are supported: `fast` and `slow`. Selecting a specific animation type is a shorthand for enabling animation and setting the animation speed in one go.\n\n**Examples:**\n\n```mermaid\nflowchart LR\n  A e1@--> B\n  e1@{ animation: fast }\n```\n\nThis is equivalent to `{ animate: true, animation: fast }`.\n\n### Using classDef Statements for Animations\n\nYou can also animate edges by assigning a class to them and then defining animation properties in a `classDef` statement. For example:\n\n```mermaid\nflowchart LR\n  A e1@--> B\n  classDef animate stroke-dasharray: 9,5,stroke-dashoffset: 900,animation: dash 25s linear infinite;\n  class e1 animate\n```\n\nIn this snippet:\n\n- `e1@-->` creates an edge with ID `e1`.\n- `classDef animate` defines a class named `animate` with styling and animation properties.\n- `class e1 animate` applies the `animate` class to the edge `e1`.\n\n**Note on Escaping Commas:**\nWhen setting the `stroke-dasharray` property, remember to escape commas as `\\,` since commas are used as delimiters in Mermaid’s style definitions.\n\n## New arrow types\n\nThere are new types of arrows supported:\n\n- circle edge\n- cross edge\n\n### Circle edge example\n\n```mermaid-example\nflowchart LR\n    A --o B\n```\n\n### Cross edge example\n\n```mermaid-example\nflowchart LR\n    A --x B\n```\n\n## Multi directional arrows\n\nThere is the possibility to use multidirectional arrows.\n\n```mermaid-example\nflowchart LR\n    A o--o B\n    B <--> C\n    C x--x D\n```\n\n### Minimum length of a link\n\nEach node in the flowchart is ultimately assigned to a rank in the rendered\ngraph, i.e. to a vertical or horizontal level (depending on the flowchart\norientation), based on the nodes to which it is linked. By default, links\ncan span any number of ranks, but you can ask for any link to be longer\nthan the others by adding extra dashes in the link definition.\n\nIn the following example, two extra dashes are added in the link from node _B_\nto node _E_, so that it spans two more ranks than regular links:\n\n```mermaid-example\nflowchart TD\n    A[Start] --> B{Is it?}\n    B -->|Yes| C[OK]\n    C --> D[Rethink]\n    D --> B\n    B ---->|No| E[End]\n```\n\n> **Note** Links may still be made longer than the requested number of ranks\n> by the rendering engine to accommodate other requests.\n\nWhen the link label is written in the middle of the link, the extra dashes must\nbe added on the right side of the link. The following example is equivalent to\nthe previous one:\n\n```mermaid-example\nflowchart TD\n    A[Start] --> B{Is it?}\n    B -- Yes --> C[OK]\n    C --> D[Rethink]\n    D --> B\n    B -- No ----> E[End]\n```\n\nFor dotted or thick links, the characters to add are equals signs or dots,\nas summed up in the following table:\n\n| Length            |   1    |    2    |    3     |\n| ----------------- | :----: | :-----: | :------: |\n| Normal            | `---`  | `----`  | `-----`  |\n| Normal with arrow | `-->`  | `--->`  | `---->`  |\n| Thick             | `===`  | `====`  | `=====`  |\n| Thick with arrow  | `==>`  | `===>`  | `====>`  |\n| Dotted            | `-.-`  | `-..-`  | `-...-`  |\n| Dotted with arrow | `-.->` | `-..->` | `-...->` |\n\n## Special characters that break syntax\n\nIt is possible to put text within quotes in order to render more troublesome characters. As in the example below:\n\n```mermaid-example\nflowchart LR\n    id1[\"This is the (text) in the box\"]\n```\n\n### Entity codes to escape characters\n\nIt is possible to escape characters using the syntax exemplified here.\n\n```mermaid-example\n    flowchart LR\n        A[\"A double quote:#quot;\"] --> B[\"A dec char:#9829;\"]\n```\n\nNumbers given are base 10, so `#` can be encoded as `#35;`. It is also supported to use HTML character names.\n\n## Subgraphs\n\n```\nsubgraph title\n    graph definition\nend\n```\n\nAn example below:\n\n```mermaid-example\nflowchart TB\n    c1-->a2\n    subgraph one\n    a1-->a2\n    end\n    subgraph two\n    b1-->b2\n    end\n    subgraph three\n    c1-->c2\n    end\n```\n\nYou can also set an explicit id for the subgraph.\n\n```mermaid-example\nflowchart TB\n    c1-->a2\n    subgraph ide1 [one]\n    a1-->a2\n    end\n```\n\n### flowcharts\n\nWith the graphtype flowchart it is also possible to set edges to and from subgraphs as in the flowchart below.\n\n```mermaid-example\nflowchart TB\n    c1-->a2\n    subgraph one\n    a1-->a2\n    end\n    subgraph two\n    b1-->b2\n    end\n    subgraph three\n    c1-->c2\n    end\n    one --> two\n    three --> two\n    two --> c2\n```\n\n### Direction in subgraphs\n\nWith the graphtype flowcharts you can use the direction statement to set the direction which the subgraph will render like in this example.\n\n```mermaid-example\nflowchart LR\n  subgraph TOP\n    direction TB\n    subgraph B1\n        direction RL\n        i1 -->f1\n    end\n    subgraph B2\n        direction BT\n        i2 -->f2\n    end\n  end\n  A --> TOP --> B\n  B1 --> B2\n```\n\n#### Limitation\n\nIf any of a subgraph's nodes are linked to the outside, subgraph direction will be ignored. Instead the subgraph will inherit the direction of the parent graph:\n\n```mermaid-example\nflowchart LR\n    subgraph subgraph1\n        direction TB\n        top1[top] --> bottom1[bottom]\n    end\n    subgraph subgraph2\n        direction TB\n        top2[top] --> bottom2[bottom]\n    end\n    %% ^ These subgraphs are identical, except for the links to them:\n\n    %% Link *to* subgraph1: subgraph1 direction is maintained\n    outside --> subgraph1\n    %% Link *within* subgraph2:\n    %% subgraph2 inherits the direction of the top-level graph (LR)\n    outside ---> top2\n```\n\n### Collapsible subgraphs (v11.17.0+)\n\nA subgraph can be collapsed into a single compact node by attaching the metadata\n`@{ view: collapsed }` to its id. This is useful for hiding the internals of a\ngroup while still showing how it connects to the rest of the diagram.\n\n```mermaid-example\nflowchart TD\n    Start --> one\n    subgraph one [My Group]\n        A --> B\n        B --> C\n    end\n    one --> End\n    one@{ view: collapsed }\n```\n\nThe metadata is attached with the existing `id@{ ... }` statement syntax, where\n`id` is the subgraph id (use `subgraph id [Title]` to give a subgraph an explicit\nid). When a subgraph is collapsed:\n\n- Its internal nodes are hidden and it is drawn as a single node carrying the\n  subgraph's title.\n- Edges that cross the subgraph boundary are **redirected to the collapsed node**.\n- Edges that are entirely internal to the collapsed subgraph are dropped (they\n  would otherwise become self-loops on the collapsed node).\n- For nested subgraphs, a collapse resolves to the **outermost** collapsed\n  ancestor, so an edge pointing at a deeply nested node lands on the outermost\n  collapsed group.\n\n`view: expanded` is the default and renders the subgraph normally, so omitting the\nmetadata (or setting `view: expanded`) keeps the existing behavior.\n\n## Markdown Strings\n\nThe \"Markdown Strings\" feature enhances flowcharts and mind maps by offering a more versatile string type, which supports text formatting options such as bold and italics, and automatically wraps text within labels.\n\n```mermaid-example\n---\nconfig:\n  htmlLabels: false\n---\nflowchart LR\nsubgraph \"One\"\n  a(\"`The **cat**\n  in the hat`\") -- \"edge label\" --> b{{\"`The **dog** in the hog`\"}}\nend\nsubgraph \"`**Two**`\"\n  c(\"`The **cat**\n  in the hat`\") -- \"`Bold **edge label**`\" --> d(\"The dog in the hog\")\nend\n```\n\nFormatting:\n\n- For bold text, use double asterisks (`**`) before and after the text.\n- For italics, use single asterisks (`*`) before and after the text.\n- With traditional strings, you needed to add `
` tags for text to wrap in nodes. However, markdown strings automatically wrap text when it becomes too long and allows you to start a new line by simply using a newline character instead of a `
` tag.\n\nThis feature is applicable to node labels, edge labels, and subgraph labels.\n\nThe auto wrapping can be disabled by using\n\n```\n---\nconfig:\n  markdownAutoWrap: false\n---\ngraph LR\n```\n\n## Interaction\n\nIt is possible to bind a click event to a node, the click can lead to either a javascript callback or to a link which will be opened in a new browser tab.\n\n```note\nThis functionality is disabled when using `securityLevel='strict'` and enabled when using `securityLevel='loose'`.\n```\n\n```\nclick nodeId callback\nclick nodeId call callback()\n```\n\n- nodeId is the id of the node\n- callback is the name of a javascript function defined on the page displaying the graph, the function will be called with the nodeId as parameter.\n\nExamples of tooltip usage below:\n\n```html\n\n```\n\nThe tooltip text is surrounded in double quotes. The styles of the tooltip are set by the class `.mermaidTooltip`.\n\n```mermaid-example\nflowchart LR\n    A-->B\n    B-->C\n    C-->D\n    click A callback \"Tooltip for a callback\"\n    click B \"https://www.github.com\" \"This is a tooltip for a link\"\n    click C call callback() \"Tooltip for a callback\"\n    click D href \"https://www.github.com\" \"This is a tooltip for a link\"\n```\n\n> **Success** The tooltip functionality and the ability to link to urls are available from version 0.5.2.\n\n?> Due to limitations with how Docsify handles JavaScript callback functions, an alternate working demo for the above code can be viewed at [this jsfiddle](https://jsfiddle.net/yk4h7qou/2/).\n\nLinks are opened in the same browser tab/window by default. It is possible to change this by adding a link target to the click definition (`_self`, `_blank`, `_parent` and `_top` are supported):\n\n```mermaid-example\nflowchart LR\n    A-->B\n    B-->C\n    C-->D\n    D-->E\n    click A \"https://www.github.com\" _blank\n    click B \"https://www.github.com\" \"Open this in a new tab\" _blank\n    click C href \"https://www.github.com\" _blank\n    click D href \"https://www.github.com\" \"Open this in a new tab\" _blank\n```\n\nBeginner's tip—a full example using interactive links in a html context:\n\n```html\n\n  
\n    flowchart LR\n        A-->B\n        B-->C\n        C-->D\n        click A callback \"Tooltip\"\n        click B \"https://www.github.com\" \"This is a link\"\n        click C call callback() \"Tooltip\"\n        click D href \"https://www.github.com\" \"This is a link\"\n  
\n\n  \n\n```\n\n### Comments\n\nComments can be entered within a flow diagram, which will be ignored by the parser. Comments need to be on their own line, and must be prefaced with `%%` (double percent signs). Any text after the start of the comment to the next newline will be treated as a comment, including any flow syntax\n\n```mermaid\nflowchart LR\n%% this is a comment A -- text --> B{node}\n   A -- text --> B -- text2 --> C\n```\n\n## Styling and classes\n\n### Styling links\n\nIt is possible to style links. For instance, you might want to style a link that is going backwards in the flow. As links\nhave no ids in the same way as nodes, some other way of deciding what style the links should be attached to is required.\nInstead of ids, the order number of when the link was defined in the graph is used, or use default to apply to all links.\nIn the example below the style defined in the linkStyle statement will belong to the fourth link in the graph:\n\n```\nlinkStyle 3 stroke:#ff3,stroke-width:4px,color:red;\n```\n\nIt is also possible to add style to multiple links in a single statement, by separating link numbers with commas:\n\n```\nlinkStyle 1,2,7 color:blue;\n```\n\n### Styling line curves\n\nIt is possible to style the type of curve used for lines between items, if the default method does not meet your needs.\nAvailable curve styles include `basis`, `bumpX`, `bumpY`, `cardinal`, `catmullRom`, `linear`, `monotoneX`, `monotoneY`,\n`natural`, `step`, `stepAfter`, and `stepBefore`.\n\nFor a full list of available curves, including an explanation of custom curves, refer to\nthe [Shapes](https://d3js.org/d3-shape/curve) documentation in the [d3-shape](https://github.com/d3/d3-shape/) project.\n\nLine styling can be achieved in two ways:\n\n1. Change the curve style of all the lines\n2. Change the curve style of a particular line\n\n#### Diagram level curve style\n\nIn this example, a left-to-right graph uses the `stepBefore` curve style:\n\n```\n---\nconfig:\n  flowchart:\n    curve: stepBefore\n---\ngraph LR\n```\n\n#### Edge level curve style using Edge IDs (v11.10.0+)\n\nYou can assign IDs to [edges](#attaching-an-id-to-edges). After assigning an ID you can modify the line style by modifying the edge's `curve` property using the following syntax:\n\n```mermaid\nflowchart LR\n    A e1@==> B\n    A e2@--> C\n    e1@{ curve: linear }\n    e2@{ curve: natural }\n```\n\n```info\nAny edge curve style modified at the edge level overrides the diagram level style.\n```\n\n```info\nIf the same edge is modified multiple times the last modification will be rendered.\n```\n\n### Styling a node\n\nIt is possible to apply specific styles such as a thicker border or a different background color to a node.\n\n```mermaid-example\nflowchart LR\n    id1(Start)-->id2(Stop)\n    style id1 fill:#f9f,stroke:#333,stroke-width:4px\n    style id2 fill:#bbf,stroke:#f66,stroke-width:2px,color:#fff,stroke-dasharray: 5 5\n```\n\n#### Classes\n\nMore convenient than defining the style every time is to define a class of styles and attach this class to the nodes that\nshould have a different look.\n\nA class definition looks like the example below:\n\n```\n    classDef className fill:#f9f,stroke:#333,stroke-width:4px;\n```\n\nAlso, it is possible to define style to multiple classes in one statement:\n\n```\n    classDef firstClassName,secondClassName font-size:12pt;\n```\n\nAttachment of a class to a node is done as per below:\n\n```\n    class nodeId1 className;\n```\n\nIt is also possible to attach a class to a list of nodes in one statement:\n\n```\n    class nodeId1,nodeId2 className;\n```\n\nA shorter form of adding a class is to attach the classname to the node using the `:::`operator as per below:\n\n```mermaid-example\nflowchart LR\n    A:::someclass --> B\n    classDef someclass fill:#f96\n```\n\nThis form can be used when declaring multiple links between nodes:\n\n```mermaid-example\nflowchart LR\n    A:::foo & B:::bar --> C:::foobar\n    classDef foo stroke:#f00\n    classDef bar stroke:#0f0\n    classDef foobar stroke:#00f\n```\n\n### CSS classes\n\n> **Note:** Applying styles to Mermaid nodes via external CSS (e.g., `.cssClass > rect { fill: ... }`) does **not** work reliably. Mermaid's internal styles are injected with `!important` and scoped to the SVG element ID, giving them higher specificity than external CSS rules. External CSS will be silently overridden.\n>\n> The recommended approach is to use the `classDef` syntax shown in the [Classes](#classes) section above, which works correctly and is the intended styling mechanism.\n>\n> If external CSS is strictly required, every property must use `!important` to override Mermaid's styles — but this is not recommended.\n\n**Working approach — use `classDef` instead:**\n\n```mermaid-example\nflowchart LR\n    A:::myStyle --> B\n    classDef myStyle fill:#ff0000,stroke:#ffff00,stroke-width:4px\n```\n\n### Default class\n\nIf a class is named default it will be assigned to all classes without specific class definitions.\n\n```\n    classDef default fill:#f9f,stroke:#333,stroke-width:4px;\n```\n\n## Basic support for fontawesome\n\nIt is possible to add icons from fontawesome.\n\nThe icons are accessed via the syntax fa:#icon class name#.\n\n```mermaid-example\nflowchart TD\n    B[\"fa:fa-twitter for peace\"]\n    B-->C[fa:fa-ban forbidden]\n    B-->D(fa:fa-spinner)\n    B-->E(A fa:fa-camera-retro perhaps?)\n```\n\nThere are two ways to display these FontAwesome icons:\n\n### Register FontAwesome icon packs (v11.7.0+)\n\nYou can register your own FontAwesome icon pack following the [\"Registering icon packs\" instructions](../config/icons.md).\n\nSupported prefixes: `fa`, `fab`, `fas`, `far`, `fal`, `fad`.\n\n```note\nNote that it will fall back to FontAwesome CSS if FontAwesome packs are not registered.\n```\n\n### Register FontAwesome CSS\n\nMermaid supports Font Awesome if the CSS is included on the website.\nMermaid does not have any restriction on the version of Font Awesome that can be used.\n\nPlease refer the [Official Font Awesome Documentation](https://fontawesome.com/start) on how to include it in your website.\n\nAdding this snippet in the `` would add support for Font Awesome v6.5.1\n\n```html\n\n```\n\n### Custom icons\n\nIt is possible to use custom icons served from Font Awesome as long as the website imports the corresponding kit.\n\nNote that this is currently a paid feature from Font Awesome.\n\nFor custom icons, you need to use the `fak` prefix.\n\n**Example**\n\n```\nflowchart TD\n    B[fa:fa-twitter] %% standard icon\n    B-->E(fak:fa-custom-icon-name) %% custom icon\n```\n\nAnd trying to render it\n\n```mermaid-example\nflowchart TD\n    B[\"fa:fa-twitter for peace\"]\n    B-->C[\"fab:fa-truck-bold a custom icon\"]\n```\n\n## Graph declarations with spaces between vertices and link and without semicolon\n\n- In graph declarations, the statements also can now end without a semicolon. After release 0.2.16, ending a graph statement with semicolon is just optional. So the below graph declaration is also valid along with the old declarations of the graph.\n\n- A single space is allowed between vertices and the link. However there should not be any space between a vertex and its text and a link and its text. The old syntax of graph declaration will also work and hence this new feature is optional and is introduced to improve readability.\n\nBelow is the new declaration of the graph edges which is also valid along with the old declaration of the graph edges.\n\n```mermaid-example\nflowchart LR\n    A[Hard edge] -->|Link text| B(Round edge)\n    B --> C{Decision}\n    C -->|One| D[Result one]\n    C -->|Two| E[Result two]\n```\n\n## Configuration\n\n### Renderer\n\nThe layout of the diagram is done with the layout algorithm. The default is\n[ELK](https://www.eclipse.org/elk/), which handles larger and more complex\ndiagrams well and is bundled with Mermaid.\n\nTo use the classic Dagre layout instead:\n\n```\nconfig:\n  layout: dagre\n```\n\nThe `flowchart-elk` diagram type still works, but is no longer needed — it\npredates `layout` and selected what is now the default.\n\nThe `defaultRenderer` option of the `flowchart`, `class` and `state` config\nsections was removed in v12. It named a rendering engine at a time when there\nwas more than one; all of its values had come to mean the same renderer, and\nits `elk` value only ever set `layout: elk` on your behalf. Use `layout`\ndirectly.\n\n### Width\n\nIt is possible to adjust the width of the rendered flowchart.\n\nThis is done by defining **mermaid.flowchartConfig** or by the CLI to use a JSON file with the configuration. How to use the CLI is described in the mermaidCLI page.\nmermaid.flowchartConfig can be set to a JSON string with config parameters or the corresponding object.\n\n```javascript\nmermaid.flowchartConfig = {\n    width: 100%\n}\n```\n\n\n","packages/mermaid/src/docs/syntax/gantt.md":"# Gantt diagrams\n\n> A Gantt chart is a type of bar chart, first developed by Karol Adamiecki in 1896, and independently by Henry Gantt in the 1910s, that illustrates a project schedule and the amount of time it would take for any one project to finish. Gantt charts illustrate number of days between the start and finish dates of the terminal elements and summary elements of a project.\n\n## A note to users\n\nGantt Charts will record each scheduled task as one continuous bar that extends from the left to the right. The x axis represents time and the y records the different tasks and the order in which they are to be completed.\n\nIt is important to remember that when a date, day, or collection of dates specific to a task are \"excluded\", the Gantt Chart will accommodate those changes by extending an equal number of days, towards the right, not by creating a gap inside the task.\nAs shown here ![](./img/Gantt-excluded-days-within.png)\n\nHowever, if the excluded dates are between two tasks that are set to start consecutively, the excluded dates will be skipped graphically and left blank, and the following task will begin after the end of the excluded dates.\nAs shown here ![](./img/Gantt-long-weekend-look.png)\n\nA Gantt chart is useful for tracking the amount of time it would take before a project is finished, but it can also be used to graphically represent \"non-working days\", with a few tweaks.\n\nMermaid can render Gantt diagrams as SVG, PNG or a MarkDown link that can be pasted into docs.\n\n```mermaid-example\ngantt\n    title A Gantt Diagram\n    dateFormat YYYY-MM-DD\n    section Section\n        A task          :a1, 2014-01-01, 30d\n        Another task    :after a1, 20d\n    section Another\n        Task in Another :2014-01-12, 12d\n        another task    :24d\n```\n\n## Syntax\n\n```mermaid-example\ngantt\n    dateFormat  YYYY-MM-DD\n    title       Adding GANTT diagram functionality to mermaid\n    excludes    weekends\n    %% (`excludes` accepts specific dates in YYYY-MM-DD format, days of the week (\"sunday\") or \"weekends\", but not the word \"weekdays\".)\n\n    section A section\n    Completed task            :done,    des1, 2014-01-06,2014-01-08\n    Active task               :active,  des2, 2014-01-09, 3d\n    Future task               :         des3, after des2, 5d\n    Future task2              :         des4, after des3, 5d\n\n    section Critical tasks\n    Completed task in the critical line :crit, done, 2014-01-06,24h\n    Implement parser and jison          :crit, done, after des1, 2d\n    Create tests for parser             :crit, active, 3d\n    Future task in critical line        :crit, 5d\n    Create tests for renderer           :2d\n    Add to mermaid                      :until isadded\n    Functionality added                 :milestone, isadded, 2014-01-25, 0d\n\n    section Documentation\n    Describe gantt syntax               :active, a1, after des1, 3d\n    Add gantt diagram to demo page      :after a1  , 20h\n    Add another diagram to demo page    :doc1, after a1  , 48h\n\n    section Last section\n    Describe gantt syntax               :after doc1, 3d\n    Add gantt diagram to demo page      :20h\n    Add another diagram to demo page    :48h\n```\n\nTasks are by default sequential. A task start date defaults to the end date of the preceding task.\n\nA colon, `:`, separates the task title from its metadata.\nMetadata items are separated by a comma, `,`. Valid tags are `active`, `done`, `crit`, and `milestone`. Tags are optional, but if used, they must be specified first.\nAfter processing the tags, the remaining metadata items are interpreted as follows:\n\n1. If a single item is specified, it determines when the task ends. It can either be a specific date/time or a duration. If a duration is specified, it is added to the start date of the task to determine the end date of the task, taking into account any exclusions.\n2. If two items are specified, the last item is interpreted as in the previous case. The first item can either specify an explicit start date/time (in the format specified by `dateFormat`) or reference another task using `after  [[otherTaskID2 [otherTaskID3]]...]`. In the latter case, the start date of the task will be set according to the latest end date of any referenced task.\n3. If three items are specified, the last two will be interpreted as in the previous case. The first item will denote the ID of the task, which can be referenced using the `later ` syntax.\n\n| Metadata syntax                                      | Start date                                          | End date                                              | ID       |\n| ---------------------------------------------------- | --------------------------------------------------- | ----------------------------------------------------- | -------- |\n| `, , `                   | `startdate` as interpreted using `dateformat`       | `endDate` as interpreted using `dateformat`           | `taskID` |\n| `, , `                    | `startdate` as interpreted using `dateformat`       | Start date + `length`                                 | `taskID` |\n| `, after , `           | End date of previously specified task `otherTaskID` | `endDate` as interpreted using `dateformat`           | `taskID` |\n| `, after , `            | End date of previously specified task `otherTaskID` | Start date + `length`                                 | `taskID` |\n| `, , until `         | `startdate` as interpreted using `dateformat`       | Start date of previously specified task `otherTaskID` | `taskID` |\n| `, after , until ` | End date of previously specified task `otherTaskID` | Start date of previously specified task `otherTaskID` | `taskID` |\n| `, `                             | `startdate` as interpreted using `dateformat`       | `enddate` as interpreted using `dateformat`           | n/a      |\n| `, `                              | `startdate` as interpreted using `dateformat`       | Start date + `length`                                 | n/a      |\n| `after , `                     | End date of previously specified task `otherTaskID` | `enddate` as interpreted using `dateformat`           | n/a      |\n| `after , `                      | End date of previously specified task `otherTaskID` | Start date + `length`                                 | n/a      |\n| `, until `                   | `startdate` as interpreted using `dateformat`       | Start date of previously specified task `otherTaskID` | n/a      |\n| `after , until `           | End date of previously specified task `otherTaskID` | Start date of previously specified task `otherTaskID` | n/a      |\n| ``                                          | End date of preceding task                          | `enddate` as interpreted using `dateformat`           | n/a      |\n| ``                                           | End date of preceding task                          | Start date + `length`                                 | n/a      |\n| `until `                                | End date of preceding task                          | Start date of previously specified task `otherTaskID` | n/a      |\n\n```note\nSupport for keyword `until` was added in (v10.9.0+). This can be used to define a task which is running until some other specific task or milestone starts.\n```\n\n#### Duration format\n\nWhen specifying a ``, use a number followed by one of these unit suffixes:\n\n| Unit         | Suffix | Example |\n| ------------ | ------ | ------- |\n| Milliseconds | `ms`   | `500ms` |\n| Seconds      | `s`    | `30s`   |\n| Minutes      | `m`    | `30m`   |\n| Hours        | `h`    | `4h`    |\n| Days         | `d`    | `3d`    |\n| Weeks        | `w`    | `2w`    |\n| Months       | `M`    | `1M`    |\n| Years        | `y`    | `1y`    |\n\nDecimal values are also supported (e.g., `1.5d`). Invalid duration tokens (e.g., `3dX`) will be ignored and the task will default to zero duration.\n\nFor simplicity, the table does not show the use of multiple tasks listed with the `after` keyword. Here is an example of how to use it and how it's interpreted:\n\n```mermaid-example\ngantt\n    apple :a, 2017-07-20, 1w\n    banana :crit, b, 2017-07-23, 1d\n    cherry :active, c, after b a, 1d\n    kiwi   :d, 2017-07-20, until b c\n```\n\n### Title\n\nThe `title` is an _optional_ string to be displayed at the top of the Gantt chart to describe the chart as a whole.\n\n### Excludes\n\nThe `excludes` is an _optional_ attribute that accepts specific dates in YYYY-MM-DD format, days of the week (\"sunday\") or \"weekends\", but not the word \"weekdays\".\nThese date will be marked on the graph, and be excluded from the duration calculation of tasks. Meaning that if there are excluded dates during a task interval, the number of 'skipped' days will be added to the end of the task to ensure the duration is as specified in the code.\n\nMultiple `excludes` lines are supported and their tokens are concatenated, so long exclusion lists can be split across grouped lines with comments:\n\n```\ngantt\n    dateFormat DD-MM-YYYY\n    excludes weekends\n    %% week 7 is winter break\n    excludes 10-02-2025 11-02-2025 12-02-2025 13-02-2025 14-02-2025\n    %% workers holiday 1 maj\n    excludes 01-05-2025\n```\n\n#### Weekend (v\\11.0.0+)\n\nWhen excluding weekends, it is possible to configure the weekends to be either Friday and Saturday or Saturday and Sunday. By default weekends are Saturday and Sunday.\nTo define the weekend start day, there is an _optional_ attribute `weekend` that can be added in a new line followed by either `friday` or `saturday`.\n\n```mermaid-example\ngantt\n    title A Gantt Diagram Excluding Fri - Sat weekends\n    dateFormat YYYY-MM-DD\n    excludes weekends\n    weekend friday\n    section Section\n        A task          :a1, 2024-01-01, 30d\n        Another task    :after a1, 20d\n```\n\n### Section statements\n\nYou can divide the chart into various sections, for example to separate different parts of a project like development and documentation.\n\nTo do so, start a line with the `section` keyword and give it a name. (Note that unlike with the [title for the entire chart](#title), this name is _required_.\n\n### Milestones\n\nYou can add milestones to the diagrams. Milestones differ from tasks as they represent a single instant in time and are identified by the keyword `milestone`. Below is an example on how to use milestones. As you may notice, the exact location of the milestone is determined by the initial date for the milestone and the \"duration\" of the task this way: _initial date_+_duration_/2.\n\n```mermaid-example\ngantt\n    dateFormat HH:mm\n    axisFormat %H:%M\n    Initial milestone : milestone, m1, 17:49, 2m\n    Task A : 10m\n    Task B : 5m\n    Final milestone : milestone, m2, 18:08, 4m\n```\n\n### Vertical Markers\n\nThe `vert` keyword lets you add vertical lines to your Gantt chart, making it easy to highlight important dates like deadlines, events, or checkpoints. These markers extend across the entire chart and are positioned based on the date you provide. Unlike milestones, vertical markers don’t take up a row. They’re purely visual reference points that help break up the timeline and make important moments easier to spot.\n\n```mermaid-example\ngantt\n    dateFormat HH:mm\n    axisFormat %H:%M\n    Initial vert : vert, v1, 17:30, 2m\n    Task A : 3m\n    Task B : 8m\n    Final vert : vert, v2, 17:58, 4m\n```\n\n## Setting dates\n\n`dateFormat` defines the format of the date **input** of your gantt elements. How these dates are represented in the rendered chart **output** are defined by `axisFormat`.\n\n### Input date format\n\nThe default input date format is `YYYY-MM-DD`. You can define your custom `dateFormat`.\n\n```markdown\ndateFormat YYYY-MM-DD\n```\n\nThe following formatting options are supported:\n\n| Input      | Example        | Description                                            |\n| ---------- | -------------- | ------------------------------------------------------ |\n| `YYYY`     | 2014           | 4 digit year                                           |\n| `YY`       | 14             | 2 digit year                                           |\n| `Q`        | 1..4           | Quarter of year. Sets month to first month in quarter. |\n| `M MM`     | 1..12          | Month number                                           |\n| `MMM MMMM` | January..Dec   | Month name in locale set by `dayjs.locale()`           |\n| `D DD`     | 1..31          | Day of month                                           |\n| `Do`       | 1st..31st      | Day of month with ordinal                              |\n| `DDD DDDD` | 1..365         | Day of year                                            |\n| `X`        | 1410715640.579 | Unix timestamp                                         |\n| `x`        | 1410715640579  | Unix ms timestamp                                      |\n| `H HH`     | 0..23          | 24 hour time                                           |\n| `h hh`     | 1..12          | 12 hour time used with `a A`.                          |\n| `a A`      | am pm          | Post or ante meridiem                                  |\n| `m mm`     | 0..59          | Minutes                                                |\n| `s ss`     | 0..59          | Seconds                                                |\n| `S`        | 0..9           | Tenths of a second                                     |\n| `SS`       | 0..99          | Hundreds of a second                                   |\n| `SSS`      | 0..999         | Thousandths of a second                                |\n| `Z ZZ`     | +12:00         | Offset from UTC as +-HH:mm, +-HHmm, or Z               |\n\nMore info in: https://day.js.org/docs/en/parse/string-format/\n\n### Output date format on the axis\n\nThe default output date format is `YYYY-MM-DD`. You can define your custom `axisFormat`, like `2020-Q1` for the first quarter of the year 2020.\n\n```markdown\naxisFormat %Y-%m-%d\n```\n\nThe following formatting strings are supported:\n\n| Format | Definition                                                                                |\n| ------ | ----------------------------------------------------------------------------------------- |\n| %a     | abbreviated weekday name                                                                  |\n| %A     | full weekday name                                                                         |\n| %b     | abbreviated month name                                                                    |\n| %B     | full month name                                                                           |\n| %c     | date and time, as \"%a %b %e %H:%M:%S %Y\"                                                  |\n| %d     | zero-padded day of the month as a decimal number [01,31]                                  |\n| %e     | space-padded day of the month as a decimal number [ 1,31]; equivalent to %\\_d             |\n| %H     | hour (24-hour clock) as a decimal number [00,23]                                          |\n| %I     | hour (12-hour clock) as a decimal number [01,12]                                          |\n| %j     | day of the year as a decimal number [001,366]                                             |\n| %m     | month as a decimal number [01,12]                                                         |\n| %M     | minute as a decimal number [00,59]                                                        |\n| %L     | milliseconds as a decimal number [000, 999]                                               |\n| %p     | either AM or PM                                                                           |\n| %S     | second as a decimal number [00,61]                                                        |\n| %U     | week number of the year (Sunday as the first day of the week) as a decimal number [00,53] |\n| %w     | weekday as a decimal number [0(Sunday),6]                                                 |\n| %W     | week number of the year (Monday as the first day of the week) as a decimal number [00,53] |\n| %x     | date, as \"%m/%d/%Y\"                                                                       |\n| %X     | time, as \"%H:%M:%S\"                                                                       |\n| %y     | year without century as a decimal number [00,99]                                          |\n| %Y     | year with century as a decimal number                                                     |\n| %Z     | time zone offset, such as \"-0700\"                                                         |\n| %%     | a literal \"%\" character                                                                   |\n\nMore info in: [https://github.com/d3/d3-time-format/tree/v4.0.0#locale_format](https://github.com/d3/d3-time-format/tree/v4.0.0#locale_format)\n\n### Axis ticks (v10.3.0+)\n\nThe default output ticks are auto. You can custom your `tickInterval`, like `1day` or `1week`.\n\n```markdown\ntickInterval 1day\n```\n\nThe pattern is:\n\n```javascript\n/^([1-9][0-9]*)(millisecond|second|minute|hour|day|week|month)$/;\n```\n\nMore info in: [https://github.com/d3/d3-time#interval_every](https://github.com/d3/d3-time#interval_every)\n\nWeek-based `tickInterval`s start the week on sunday by default. If you wish to specify another weekday on which the `tickInterval` should start, use the `weekday` option:\n\n```mermaid-example\ngantt\n  tickInterval 1week\n  weekday monday\n```\n\n```warning\n`millisecond` and `second` support was added in v10.3.0\n```\n\n## Output in compact mode\n\nThe compact mode allows you to display multiple tasks in the same row. Compact mode can be enabled for a gantt chart by setting the display mode of the graph via preceding YAML settings.\n\n```mermaid-example\n---\ndisplayMode: compact\n---\ngantt\n    title A Gantt Diagram\n    dateFormat  YYYY-MM-DD\n\n    section Section\n    A task           :a1, 2014-01-01, 30d\n    Another task     :a2, 2014-01-20, 25d\n    Another one      :a3, 2014-02-10, 20d\n```\n\n## Comments\n\nComments can be entered within a gantt chart, which will be ignored by the parser. Comments need to be on their own line and must be prefaced with `%%` (double percent signs). Any text after the start of the comment to the next newline will be treated as a comment, including any diagram syntax.\n\n```mermaid\ngantt\n    title A Gantt Diagram\n    %% This is a comment\n    dateFormat YYYY-MM-DD\n    section Section\n        A task          :a1, 2014-01-01, 30d\n        Another task    :after a1, 20d\n    section Another\n        Task in Another :2014-01-12, 12d\n        another task    :24d\n```\n\n## Styling\n\nStyling of the Gantt diagram is done by defining a number of CSS classes. During rendering, these classes are extracted from the file located at src/diagrams/gantt/styles.js\n\n### Classes used\n\n| Class                 | Description                                                            |\n| --------------------- | ---------------------------------------------------------------------- |\n| grid.tick             | Styling for the Grid Lines                                             |\n| grid.path             | Styling for the Grid's borders                                         |\n| .taskText             | Task Text Styling                                                      |\n| .taskTextOutsideRight | Styling for Task Text that exceeds the activity bar towards the right. |\n| .taskTextOutsideLeft  | Styling for Task Text that exceeds the activity bar, towards the left. |\n| todayMarker           | Toggle and Styling for the \"Today Marker\"                              |\n\n### Sample stylesheet\n\n```css\n.grid .tick {\n  stroke: lightgrey;\n  opacity: 0.3;\n  shape-rendering: crispEdges;\n}\n.grid path {\n  stroke-width: 0;\n}\n\n#tag {\n  color: white;\n  background: #fa283d;\n  width: 150px;\n  position: absolute;\n  display: none;\n  padding: 3px 6px;\n  margin-left: -80px;\n  font-size: 11px;\n}\n\n#tag:before {\n  border: solid transparent;\n  content: ' ';\n  height: 0;\n  left: 50%;\n  margin-left: -5px;\n  position: absolute;\n  width: 0;\n  border-width: 10px;\n  border-bottom-color: #fa283d;\n  top: -20px;\n}\n.taskText {\n  fill: white;\n  text-anchor: middle;\n}\n.taskTextOutsideRight {\n  fill: black;\n  text-anchor: start;\n}\n.taskTextOutsideLeft {\n  fill: black;\n  text-anchor: end;\n}\n```\n\n## Today marker\n\nYou can style or hide the marker for the current date. To style it, add a value for the `todayMarker` key.\n\n```\ntodayMarker stroke-width:5px,stroke:#0f0,opacity:0.5\n```\n\nTo hide the marker, set `todayMarker` to `off`.\n\n```\ntodayMarker off\n```\n\n## Configuration\n\nIt is possible to adjust the margins for rendering the gantt diagram.\n\nThis is done by defining the `ganttConfig` part of the configuration object.\nHow to use the CLI is described in the [mermaidCLI](../config/mermaidCLI.md) page.\n\nmermaid.ganttConfig can be set to a JSON string with config parameters or the corresponding object.\n\n```javascript\nmermaid.ganttConfig = {\n  titleTopMargin: 25, // Margin top for the text over the diagram\n  barHeight: 20, // The height of the bars in the graph\n  barGap: 4, // The margin between the different activities in the gantt diagram\n  topPadding: 75, // Margin between title and gantt diagram and between axis and gantt diagram.\n  rightPadding: 75, // The space allocated for the section name to the right of the activities\n  leftPadding: 75, // The space allocated for the section name to the left of the activities\n  gridLineStartPadding: 10, // Vertical starting position of the grid lines\n  fontSize: 12, // Font size\n  sectionFontSize: 24, // Font size for sections\n  numberSectionStyles: 1, // The number of alternating section styles\n  axisFormat: '%d/%m', // Date/time format of the axis\n  tickInterval: '1week', // Axis ticks\n  topAxis: true, // When this flag is set, date labels will be added to the top of the chart\n  displayMode: 'compact', // Turns compact mode on\n  weekday: 'sunday', // On which day a week-based interval should start\n};\n```\n\n### Possible configuration params:\n\n| Param           | Description                                                                                                                                | Default value |\n| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | ------------- |\n| mirrorActor     | Turns on/off the rendering of actors below the diagram as well as above it                                                                 | false         |\n| bottomMarginAdj | Adjusts how far down the graph ended. Wide borders styles with css could generate unwanted clipping which is why this config param exists. | 1             |\n\n## Interaction\n\nIt is possible to bind a click event to a task. The click can lead to either a javascript callback or to a link which will be opened in the current browser tab. **Note**: This functionality is disabled when using `securityLevel='strict'` and enabled when using `securityLevel='loose'`.\n\n```\nclick taskId call callback(arguments)\nclick taskId href URL\n```\n\n- taskId is the id of the task\n- callback is the name of a javascript function defined on the page displaying the graph, the function will be called with the taskId as the parameter if no other arguments are specified.\n\nBeginner's tip—a full example using interactive links in an HTML context:\n\n```html\n\n  
\n    gantt\n      dateFormat  YYYY-MM-DD\n\n      section Clickable\n      Visit mermaidjs         :active, cl1, 2014-01-07, 3d\n      Print arguments         :cl2, after cl1, 3d\n      Print task              :cl3, after cl2, 3d\n\n      click cl1 href \"https://mermaidjs.github.io/\"\n      click cl2 call printArguments(\"test1\", \"test2\", test3)\n      click cl3 call printTask()\n  
\n\n  \n\n```\n\n## Examples\n\n### Bar chart (using gantt chart)\n\n```mermaid-example\ngantt\n    title Git Issues - days since last update\n    dateFormat X\n    axisFormat %s\n    section Issue19062\n    71   : 0, 71\n    section Issue19401\n    36   : 0, 36\n    section Issue193\n    34   : 0, 34\n    section Issue7441\n    9    : 0, 9\n    section Issue1300\n    5    : 0, 5\n```\n\n### Timeline (with comments, CSS, config in frontmatter)\n\n```mermaid-example\n---\n    # Frontmatter config, YAML comments\n    title: Ignored if specified in chart\n    displayMode: compact     #gantt specific setting but works at this level too\n    config:\n#        theme: forest\n#        themeCSS: \" #item36 { fill: CadetBlue } \"\n        themeCSS: \" // YAML supports multiline strings using a newline markers: \\n\n            #item36 { fill: CadetBlue }       \\n\n\n            // Custom marker workaround CSS from forum (below)    \\n\n            rect[id^=workaround] { height: calc(100% - 50px) ; transform: translate(9px, 25px); y: 0; width: 1.5px; stroke: none; fill: red; }   \\n\n            text[id^=workaround] { fill: red; y: 100%; font-size: 15px;}\n        \"\n        gantt:\n            useWidth: 400\n            rightPadding: 0\n            topAxis: true  #false\n            numberSectionStyles: 2\n---\ngantt\n    title Timeline - Gantt Sampler\n    dateFormat YYYY\n    axisFormat %y\n    %% this next line doesn't recognise 'decade' or 'year', but will silently ignore\n    tickInterval 1decade\n\n    section Issue19062\n    71   :            item71, 1900, 1930\n    section Issue19401\n    36   :            item36, 1913, 1935\n    section Issue1300\n    94   :            item94, 1910, 1915\n    5    :            item5,  1920, 1925\n    0    : milestone, item0,  1918, 1s\n    9    : vert,              1906, 1s   %% not yet official\n    64   : workaround,        1923, 1s   %% custom CSS object https://github.com/mermaid-js/mermaid/issues/3250\n```\n\n\n","packages/mermaid/src/docs/syntax/gitgraph.md":"# GitGraph Diagrams\n\n> A Git Graph is a pictorial representation of git commits and git actions(commands) on various branches.\n\nThese kind of diagram are particularly helpful to developers and devops teams to share their Git branching strategies. For example, it makes it easier to visualize how git flow works.\n\nMermaid can render Git diagrams\n\n```mermaid-example\n---\ntitle: Example Git diagram\n---\ngitGraph\n   commit\n   commit\n   branch develop\n   checkout develop\n   commit\n   commit\n   checkout main\n   merge develop\n   commit\n   commit\n```\n\nIn Mermaid, we support the basic git operations like:\n\n- _commit_ : Representing a new commit on the current branch.\n- _branch_ : To create & switch to a new branch, setting it as the current branch.\n- _checkout_ : To checking out an existing branch and setting it as the current branch.\n- _merge_ : To merge an existing branch onto the current branch.\n\nWith the help of these key git commands, you will be able to draw a gitgraph in Mermaid very easily and quickly.\nEntity names are often capitalized, although there is no accepted standard on this, and it is not required in Mermaid.\n\n**NOTE**: `checkout` and `switch` can be used interchangeably.\n\n## Syntax\n\nMermaid syntax for a gitgraph is very straight-forward and simple. It follows a declarative-approach, where each commit is drawn on the timeline in the diagram, in order of its occurrences/presence in code. Basically, it follows the insertion order for each command.\n\nFirst thing you do is to declare your diagram type using the **gitgraph** keyword. This `gitgraph` keyword, tells Mermaid that you wish to draw a gitgraph, and parse the diagram code accordingly.\n\nEach gitgraph, is initialized with **_main_** branch. So unless you create a different branch, by-default the commits will go to the main branch. This is driven with how git works, where in the beginning you always start with the main branch (formerly called as **_master_** branch). And by-default, `main` branch is set as your **_current branch_**.\n\nYou make use of **_commit_** keyword to register a commit on the current branch. Let see how this works:\n\nA simple gitgraph showing three commits on the default (**_main_**) branch:\n\n```mermaid-example\n    gitGraph\n       commit\n       commit\n       commit\n```\n\nIf you look closely at the previous example, you can see the default branch `main` along with three commits. Also, notice that by default each commit has been given a unique & random ID. What if you wanted to give your own custom ID to a commit? Yes, it is possible to do that with Mermaid.\n\n### Adding custom commit id\n\nFor a given commit you may specify a custom ID at the time of declaring it using the `id` attribute, followed by `:` and your custom value within a `\"\"` quote. For example: `commit id: \"your_custom_id\"`\n\nLet us see how this works with the help of the following diagram:\n\n```mermaid-example\n    gitGraph\n       commit id: \"Alpha\"\n       commit id: \"Beta\"\n       commit id: \"Gamma\"\n```\n\nIn this example, we have given our custom IDs to the commits.\n\n### Modifying commit type\n\nIn Mermaid, a commit can be of three type, which render a bit different in the diagram. These types are:\n\n- `NORMAL` : Default commit type. Represented by a solid circle in the diagram\n- `REVERSE` : To emphasize a commit as a reverse commit. Represented by a crossed solid circle in the diagram.\n- `HIGHLIGHT` : To highlight a particular commit in the diagram. Represented by a filled rectangle in the diagram.\n\nFor a given commit you may specify its type at the time of declaring it using the `type` attribute, followed by `:` and the required type option discussed above. For example: `commit type: HIGHLIGHT`\n\nNOTE: If no commit type is specified, `NORMAL` is picked as default.\n\nLet us see how these different commit type look with the help of the following diagram:\n\n```mermaid-example\n    gitGraph\n       commit id: \"Normal\"\n       commit\n       commit id: \"Reverse\" type: REVERSE\n       commit\n       commit id: \"Highlight\" type: HIGHLIGHT\n       commit\n```\n\nIn this example, we have specified different types to each commit. Also, see how we have included both `id` and `type` together at the time of declaring our commits.\n\n### Adding Tags\n\nFor a given commit you may decorate it as a **tag**, similar to the concept of tags or release version in git world.\nYou can attach a custom tag at the time of declaring a commit using the `tag` attribute, followed by `:` and your custom value within `\"\"` quote. For example: `commit tag: \"your_custom_tag\"`\n\nLet us see how this works with the help of the following diagram:\n\n```mermaid-example\n    gitGraph\n       commit\n       commit id: \"Normal\" tag: \"v1.0.0\"\n       commit\n       commit id: \"Reverse\" type: REVERSE tag: \"RC_1\"\n       commit\n       commit id: \"Highlight\" type: HIGHLIGHT tag: \"8.8.4\"\n       commit\n```\n\nIn this example, we have given custom tags to the commits. Also, see how we have combined all these attributes in a single commit declaration. You can mix-match these attributes as you like.\n\n### Create a new branch\n\nIn Mermaid, in-order to create a new branch, you make use of the `branch` keyword. You also need to provide a name of the new branch. The name has to be unique and cannot be that of an existing branch. A branch name that could be confused for a keyword must be quoted within `\"\"`. Usage examples: `branch develop`, `branch \"cherry-pick\"`\n\nWhen Mermaid, reads the `branch` keyword, it creates a new branch and sets it as the current branch. Equivalent to you creating a new branch and checking it out in Git world.\n\nLet see this in an example:\n\n```mermaid-example\n    gitGraph\n       commit\n       commit\n       branch develop\n       commit\n       commit\n       commit\n```\n\nIn this example, see how we started with default `main` branch, and pushed two commits on that.\nThen we created the `develop` branch, and all commits afterwards are put on the `develop` branch as it became the current branch.\n\n### Checking out an existing branch\n\nIn Mermaid, in order to switch to an existing branch, you make use of the `checkout` keyword. You also need to provide a name of an existing branch. If no branch is found with the given name, it will result in console error. Usage example: `checkout develop`\n\nWhen Mermaid, reads the `checkout` keyword, it finds the given branch and sets it as the current branch. Equivalent to checking out a branch in the Git world.\n\nLet see modify our previous example:\n\n```mermaid-example\n    gitGraph\n       commit\n       commit\n       branch develop\n       commit\n       commit\n       commit\n       checkout main\n       commit\n       commit\n```\n\nIn this example, see how we started with default `main` branch, and pushed two commits on that.\nThen we created the `develop` branch, and all three commits afterwards are put on the `develop` branch as it became the current branch.\nAfter this we made use of the `checkout` keyword to set the current branch as `main`, and all commit that follow are registered against the current branch, i.e. `main`.\n\n### Merging two branches\n\nIn Mermaid, in order to merge or join to an existing branch, you make use of the `merge` keyword. You also need to provide the name of an existing branch to merge from. If no branch is found with the given name, it will result in console error. Also, you can only merge two separate branches, and cannot merge a branch with itself. In such case an error is throw.\n\nUsage example: `merge develop`\n\nWhen Mermaid, reads the `merge` keyword, it finds the given branch and its head commit (the last commit on that branch), and joins it with the head commit on the **current branch**. Each merge results in a **_merge commit_**, represented in the diagram with **filled double circle**.\n\nLet us modify our previous example to merge our two branches:\n\n```mermaid-example\n    gitGraph\n       commit\n       commit\n       branch develop\n       commit\n       commit\n       commit\n       checkout main\n       commit\n       commit\n       merge develop\n       commit\n       commit\n```\n\nIn this example, see how we started with default `main` branch, and pushed two commits on that.\nThen we created the `develop` branch, and all three commits afterwards are put on the `develop` branch as it became the current branch.\nAfter this we made use of the `checkout` keyword to set the current branch as `main`, and all commits that follow are registered against the current branch, i.e. `main`.\nAfter this we merge the `develop` branch onto the current branch `main`, resulting in a merge commit.\nSince the current branch at this point is still `main`, the last two commits are registered against that.\n\nYou can also decorate your merge with similar attributes as you did for the commit using:\n\n- `id`--> To override the default ID with custom ID\n- `tag`--> To add a custom tag to your merge commit\n- `type`--> To override the default shape of merge commit. Here you can use other commit type mentioned earlier.\n\nAnd you can choose to use none, some or all of these attributes together.\nFor example: `merge develop id: \"my_custom_id\" tag: \"my_custom_tag\" type: REVERSE`\n\nLet us see how this works with the help of the following diagram:\n\n```mermaid-example\n    gitGraph\n       commit id: \"1\"\n       commit id: \"2\"\n       branch nice_feature\n       checkout nice_feature\n       commit id: \"3\"\n       checkout main\n       commit id: \"4\"\n       checkout nice_feature\n       branch very_nice_feature\n       checkout very_nice_feature\n       commit id: \"5\"\n       checkout main\n       commit id: \"6\"\n       checkout nice_feature\n       commit id: \"7\"\n       checkout main\n       merge nice_feature id: \"customID\" tag: \"customTag\" type: REVERSE\n       checkout very_nice_feature\n       commit id: \"8\"\n       checkout main\n       commit id: \"9\"\n```\n\n### Cherry Pick commit from another branch\n\nSimilar to how 'git' allows you to cherry-pick a commit from **another branch** onto the **current** branch, Mermaid also supports this functionality. You can also cherry-pick a commit from another branch using the `cherry-pick` keyword.\n\nTo use the `cherry-pick` keyword, you must specify the id using the `id` attribute, followed by `:` and your desired commit id within a `\"\"` quote. For example:\n\n`cherry-pick id: \"your_custom_id\"`\n\nHere, a new commit representing the cherry-pick is created on the current branch, and is visually highlighted in the diagram with a **cherry** and a tag depicting the commit id from which it is cherry-picked from.\n\nA few important rules to note here are:\n\n1. You need to provide the `id` for an existing commit to be cherry-picked. If given commit id does not exist it will result in an error. For this, make use of the `commit id:$value` format of declaring commits. See the examples from above.\n2. The given commit must not exist on the current branch. The cherry-picked commit must always be a different branch than the current branch.\n3. Current branch must have at least one commit, before you can cherry-pick, otherwise it will cause an error is throw.\n4. When cherry-picking a merge commit, providing a parent commit ID is mandatory. If the parent attribute is omitted or an invalid parent commit ID is provided, an error will be thrown.\n5. The specified parent commit must be an immediate parent of the merge commit being cherry-picked.\n\nLet see an example:\n\n```mermaid-example\n    gitGraph\n        commit id: \"ZERO\"\n        branch develop\n        branch release\n        commit id:\"A\"\n        checkout main\n        commit id:\"ONE\"\n        checkout develop\n        commit id:\"B\"\n        checkout main\n        merge develop id:\"MERGE\"\n        commit id:\"TWO\"\n        checkout release\n        cherry-pick id:\"MERGE\" parent:\"B\"\n        commit id:\"THREE\"\n        checkout develop\n        commit id:\"C\"\n```\n\n## GitGraph specific configuration options\n\nIn Mermaid, you have the option to configure the gitgraph diagram. You can configure the following options:\n\n- `showBranches` : Boolean, default is `true`. If set to `false`, the branches are not shown in the diagram.\n- `showCommitLabel` : Boolean, default is `true`. If set to `false`, the commit labels are not shown in the diagram.\n- `mainBranchName` : String, default is `main`. The name of the default/root branch.\n- `mainBranchOrder` : Position of the main branch in the list of branches. default is `0`, meaning, by default `main` branch is the first in the order.\n- `parallelCommits`: Boolean, default is `false`. If set to `true`, commits x distance away from the parent are shown at the same level in the diagram.\n\nLet's look at them one by one.\n\n## Hiding Branch names and lines\n\nSometimes you may want to hide the branch names and lines from the diagram. You can do this by using the `showBranches` keyword. By default its value is `true`. You can set it to `false` using directives.\n\nUsage example:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'base'\n  gitGraph:\n    showBranches: false\n---\n      gitGraph\n        commit\n        branch hotfix\n        checkout hotfix\n        commit\n        branch develop\n        checkout develop\n        commit id:\"ash\" tag:\"abc\"\n        branch featureB\n        checkout featureB\n        commit type:HIGHLIGHT\n        checkout main\n        checkout hotfix\n        commit type:NORMAL\n        checkout develop\n        commit type:REVERSE\n        checkout featureB\n        commit\n        checkout main\n        merge hotfix\n        checkout featureB\n        commit\n        checkout develop\n        branch featureA\n        commit\n        checkout develop\n        merge hotfix\n        checkout featureA\n        commit\n        checkout featureB\n        commit\n        checkout develop\n        merge featureA\n        branch release\n        checkout release\n        commit\n        checkout main\n        commit\n        checkout release\n        merge main\n        checkout develop\n        merge release\n```\n\n## Commit labels Layout: Rotated or Horizontal\n\nMermaid supports two types of commit labels layout. The default layout is **rotated**, which means the labels are placed below the commit circle, rotated at 45 degrees for better readability. This is particularly useful for commits with long labels.\n\nThe other option is **horizontal**, which means the labels are placed below the commit circle centred horizontally, and are not rotated. This is particularly useful for commits with short labels.\n\nYou can change the layout of the commit labels by using the `rotateCommitLabel` keyword in the directive. It defaults to `true`, which means the commit labels are rotated.\n\nUsage example: Rotated commit labels\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'base'\n  gitGraph:\n    rotateCommitLabel: true\n---\ngitGraph\n  commit id: \"feat(api): ...\"\n  commit id: \"a\"\n  commit id: \"b\"\n  commit id: \"fix(client): .extra long label..\"\n  branch c2\n  commit id: \"feat(modules): ...\"\n  commit id: \"test(client): ...\"\n  checkout main\n  commit id: \"fix(api): ...\"\n  commit id: \"ci: ...\"\n  branch b1\n  commit\n  branch b2\n  commit\n```\n\nUsage example: Horizontal commit labels\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'base'\n  gitGraph:\n    rotateCommitLabel: false\n---\ngitGraph\n  commit id: \"feat(api): ...\"\n  commit id: \"a\"\n  commit id: \"b\"\n  commit id: \"fix(client): .extra long label..\"\n  branch c2\n  commit id: \"feat(modules): ...\"\n  commit id: \"test(client): ...\"\n  checkout main\n  commit id: \"fix(api): ...\"\n  commit id: \"ci: ...\"\n  branch b1\n  commit\n  branch b2\n  commit\n```\n\n## Hiding commit labels\n\nSometimes you may want to hide the commit labels from the diagram. You can do this by using the `showCommitLabel` keyword. By default its value is `true`. You can set it to `false` using directives.\n\nUsage example:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'base'\n  gitGraph:\n    showBranches: false\n    showCommitLabel: false\n---\n      gitGraph\n        commit\n        branch hotfix\n        checkout hotfix\n        commit\n        branch develop\n        checkout develop\n        commit id:\"ash\"\n        branch featureB\n        checkout featureB\n        commit type:HIGHLIGHT\n        checkout main\n        checkout hotfix\n        commit type:NORMAL\n        checkout develop\n        commit type:REVERSE\n        checkout featureB\n        commit\n        checkout main\n        merge hotfix\n        checkout featureB\n        commit\n        checkout develop\n        branch featureA\n        commit\n        checkout develop\n        merge hotfix\n        checkout featureA\n        commit\n        checkout featureB\n        commit\n        checkout develop\n        merge featureA\n        branch release\n        checkout release\n        commit\n        checkout main\n        commit\n        checkout release\n        merge main\n        checkout develop\n        merge release\n```\n\n## Customizing main branch name\n\nSometimes you may want to customize the name of the main/default branch. You can do this by using the `mainBranchName` keyword. By default its value is `main`. You can set it to any string using directives.\n\nUsage example:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'base'\n  gitGraph:\n    showBranches: true\n    showCommitLabel: true\n    mainBranchName: 'MetroLine1'\n---\n      gitGraph\n        commit id:\"NewYork\"\n        commit id:\"Dallas\"\n        branch MetroLine2\n        commit id:\"LosAngeles\"\n        commit id:\"Chicago\"\n        commit id:\"Houston\"\n        branch MetroLine3\n        commit id:\"Phoenix\"\n        commit type: HIGHLIGHT id:\"Denver\"\n        commit id:\"Boston\"\n        checkout MetroLine1\n        commit id:\"Atlanta\"\n        merge MetroLine3\n        commit id:\"Miami\"\n        commit id:\"Washington\"\n        merge MetroLine2 tag:\"MY JUNCTION\"\n        commit id:\"Boston\"\n        commit id:\"Detroit\"\n        commit type:REVERSE id:\"SanFrancisco\"\n```\n\nLook at the imaginary railroad map created using Mermaid. Here, we have changed the default main branch name to `MetroLine1`.\n\n## Customizing branch ordering\n\nIn Mermaid, by default the branches are shown in the order of their definition or appearance in the diagram code.\n\nSometimes you may want to customize the order of the branches. You can do this by using the `order` keyword next the branch definition. You can set it to a positive number.\n\nMermaid follows the given precedence order of the `order` keyword.\n\n- Main branch is always shown first as it has default order value of `0`. (unless its order is modified and changed from `0` using the `mainBranchOrder` keyword in the config)\n- Next, All branches without an `order` are shown in the order of their appearance in the diagram code.\n- Next, All branches with an `order` are shown in the order of their `order` value.\n\nTo fully control the order of all the branches, you must define `order` for all the branches.\n\nUsage example:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'base'\n  gitGraph:\n    showBranches: true\n    showCommitLabel: true\n---\n      gitGraph\n      commit\n      branch test1 order: 3\n      branch test2 order: 2\n      branch test3 order: 1\n\n```\n\nLook at the diagram, all the branches are following the order defined.\n\nUsage example:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'base'\n  gitGraph:\n    showBranches: true\n    showCommitLabel: true\n    mainBranchOrder: 2\n---\n      gitGraph\n      commit\n      branch test1 order: 3\n      branch test2\n      branch test3\n      branch test4 order: 1\n\n```\n\nLook at the diagram, here, all the branches without a specified order are drawn in their order of definition.\nThen, `test4` branch is drawn because the order of `1`.\nThen, `main` branch is drawn because the order of `2`.\nAnd, lastly `test1`is drawn because the order of `3`.\n\nNOTE: Because we have overridden the `mainBranchOrder` to `2`, the `main` branch is not drawn in the beginning, instead follows the ordering.\n\nHere, we have changed the default main branch name to `MetroLine1`.\n\n## Orientation (v10.3.0+)\n\nMermaid supports three graph orientations: **Left-to-Right** (default), **Top-to-Bottom**, and **Bottom-to-Top**.\n\nYou can set this with either `LR:` (for [**Left-to-Right**](#left-to-right-default-lr)), `TB:` (for [**Top-to-Bottom**](#top-to-bottom-tb)) or `BT:` (for [**Bottom-to-Top**](#bottom-to-top-bt)) after `gitGraph`.\n\n### Left to Right (default, `LR:`)\n\nIn Mermaid, the default orientation is for commits to run from left to right and for branches to be stacked on top of one another.\n\nHowever, you can set this explicitly with `LR:` after `gitGraph`.\n\nUsage example:\n\n```mermaid-example\n    gitGraph LR:\n       commit\n       commit\n       branch develop\n       commit\n       commit\n       checkout main\n       commit\n       commit\n       merge develop\n       commit\n       commit\n```\n\n### Top to Bottom (`TB:`)\n\nIn `TB` (**Top-to-Bottom**) orientation, the commits run from top to bottom of the graph and branches are arranged side-by-side.\n\nTo orient the graph this way, you need to add `TB:` after gitGraph.\n\nUsage example:\n\n```mermaid-example\n    gitGraph TB:\n       commit\n       commit\n       branch develop\n       commit\n       commit\n       checkout main\n       commit\n       commit\n       merge develop\n       commit\n       commit\n```\n\n### Bottom to Top (`BT:`) (v11.0.0+)\n\nIn `BT` (**Bottom-to-Top**) orientation, the commits run from bottom to top of the graph and branches are arranged side-by-side.\n\nTo orient the graph this way, you need to add `BT:` after gitGraph.\n\nUsage example:\n\n```mermaid-example\n    gitGraph BT:\n       commit\n       commit\n       branch develop\n       commit\n       commit\n       checkout main\n       commit\n       commit\n       merge develop\n       commit\n       commit\n```\n\n## Parallel commits (v10.8.0+)\n\nCommits in Mermaid display temporal information in gitgraph by default. For example if two commits are one commit away from its parent, the commit that was made earlier is rendered closer to its parent. You can turn this off by enabling the `parallelCommits` flag.\n\n### Temporal Commits (default, `parallelCommits: false`)\n\n```mermaid-example\n---\nconfig:\n  gitGraph:\n    parallelCommits: false\n---\ngitGraph:\n  commit\n  branch develop\n  commit\n  commit\n  checkout main\n  commit\n  commit\n```\n\n### Parallel commits (`parallelCommits: true`)\n\n```mermaid-example\n---\nconfig:\n  gitGraph:\n    parallelCommits: true\n---\ngitGraph:\n  commit\n  branch develop\n  commit\n  commit\n  checkout main\n  commit\n  commit\n```\n\n## Themes\n\nMermaid supports a bunch of pre-defined themes which you can use to find the right one for you. PS: you can actually override an existing theme's variable to get your own custom theme going. Learn more about [theming your diagram](../config/theming.md).\n\nThe following are the different pre-defined theme options:\n\n- `redux-color` (the default)\n- `redux-dark-color`\n- `redux`\n- `redux-dark`\n- `default`\n- `neutral`\n- `dark`\n- `forest`\n- `neo`\n- `neo-dark`\n- `base`\n\n**NOTE**: To change theme you can either use the `initialize` call or _directives_. Learn more about [directives](../config/directives.md)\nLet's put a few of them to use, and see how our sample diagram looks in different themes:\n\n### Base Theme\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'base'\n---\n      gitGraph\n        commit\n        branch hotfix\n        checkout hotfix\n        commit\n        branch develop\n        checkout develop\n        commit id:\"ash\" tag:\"abc\"\n        branch featureB\n        checkout featureB\n        commit type:HIGHLIGHT\n        checkout main\n        checkout hotfix\n        commit type:NORMAL\n        checkout develop\n        commit type:REVERSE\n        checkout featureB\n        commit\n        checkout main\n        merge hotfix\n        checkout featureB\n        commit\n        checkout develop\n        branch featureA\n        commit\n        checkout develop\n        merge hotfix\n        checkout featureA\n        commit\n        checkout featureB\n        commit\n        checkout develop\n        merge featureA\n        branch release\n        checkout release\n        commit\n        checkout main\n        commit\n        checkout release\n        merge main\n        checkout develop\n        merge release\n```\n\n### Forest Theme\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'forest'\n---\n      gitGraph\n        commit\n        branch hotfix\n        checkout hotfix\n        commit\n        branch develop\n        checkout develop\n        commit id:\"ash\" tag:\"abc\"\n        branch featureB\n        checkout featureB\n        commit type:HIGHLIGHT\n        checkout main\n        checkout hotfix\n        commit type:NORMAL\n        checkout develop\n        commit type:REVERSE\n        checkout featureB\n        commit\n        checkout main\n        merge hotfix\n        checkout featureB\n        commit\n        checkout develop\n        branch featureA\n        commit\n        checkout develop\n        merge hotfix\n        checkout featureA\n        commit\n        checkout featureB\n        commit\n        checkout develop\n        merge featureA\n        branch release\n        checkout release\n        commit\n        checkout main\n        commit\n        checkout release\n        merge main\n        checkout develop\n        merge release\n```\n\n### The `default` Theme\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n---\n      gitGraph\n        commit type:HIGHLIGHT\n        branch hotfix\n        checkout hotfix\n        commit\n        branch develop\n        checkout develop\n        commit id:\"ash\" tag:\"abc\"\n        branch featureB\n        checkout featureB\n        commit type:HIGHLIGHT\n        checkout main\n        checkout hotfix\n        commit type:NORMAL\n        checkout develop\n        commit type:REVERSE\n        checkout featureB\n        commit\n        checkout main\n        merge hotfix\n        checkout featureB\n        commit\n        checkout develop\n        branch featureA\n        commit\n        checkout develop\n        merge hotfix\n        checkout featureA\n        commit\n        checkout featureB\n        commit\n        checkout develop\n        merge featureA\n        branch release\n        checkout release\n        commit\n        checkout main\n        commit\n        checkout release\n        merge main\n        checkout develop\n        merge release\n```\n\n### Dark Theme\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'dark'\n---\n      gitGraph\n        commit\n        branch hotfix\n        checkout hotfix\n        commit\n        branch develop\n        checkout develop\n        commit id:\"ash\" tag:\"abc\"\n        branch featureB\n        checkout featureB\n        commit type:HIGHLIGHT\n        checkout main\n        checkout hotfix\n        commit type:NORMAL\n        checkout develop\n        commit type:REVERSE\n        checkout featureB\n        commit\n        checkout main\n        merge hotfix\n        checkout featureB\n        commit\n        checkout develop\n        branch featureA\n        commit\n        checkout develop\n        merge hotfix\n        checkout featureA\n        commit\n        checkout featureB\n        commit\n        checkout develop\n        merge featureA\n        branch release\n        checkout release\n        commit\n        checkout main\n        commit\n        checkout release\n        merge main\n        checkout develop\n        merge release\n```\n\n### Neutral Theme\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'neutral'\n---\n      gitGraph\n        commit\n        branch hotfix\n        checkout hotfix\n        commit\n        branch develop\n        checkout develop\n        commit id:\"ash\" tag:\"abc\"\n        branch featureB\n        checkout featureB\n        commit type:HIGHLIGHT\n        checkout main\n        checkout hotfix\n        commit type:NORMAL\n        checkout develop\n        commit type:REVERSE\n        checkout featureB\n        commit\n        checkout main\n        merge hotfix\n        checkout featureB\n        commit\n        checkout develop\n        branch featureA\n        commit\n        checkout develop\n        merge hotfix\n        checkout featureA\n        commit\n        checkout featureB\n        commit\n        checkout develop\n        merge featureA\n        branch release\n        checkout release\n        commit\n        checkout main\n        commit\n        checkout release\n        merge main\n        checkout develop\n        merge release\n```\n\n## Customize using Theme Variables\n\nMermaid allows you to customize your diagram using theme variables which govern the look and feel of various elements of the diagram.\n\nFor understanding let us take a sample diagram with theme `default`, the default values of the theme variables is picked automatically from the theme. Later on we will see how to override the default values of the theme variables.\n\nSee how the `default` theme is used to set the colors for the branches:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n---\n       gitGraph\n       commit\n       branch develop\n       commit tag:\"v1.0.0\"\n       commit\n       checkout main\n       commit type: HIGHLIGHT\n       commit\n       merge develop\n       commit\n       branch featureA\n       commit\n```\n\n> #### IMPORTANT:\n>\n> Mermaid supports the theme variables to override the default values for **up to 8 branches**, i.e., you can set the color/styling of up to 8 branches using theme variables. After this threshold of 8 branches, the theme variables are reused in the cyclic manner, i.e. the 9th branch will use the color/styling of the 1st branch, or the branch at index position '8' will use the color/styling of the branch at index position '0'.\n> _More on this in the next section. See examples on **Customizing branch label colors** below_\n\n### Customizing branch colors\n\nYou can customize the branch colors using the `git0` to `git7` theme variables. Mermaid allows you to set the colors for up-to 8 branches, where `git0` variable will drive the value of the first branch, `git1` will drive the value of the second branch and so on.\n\nNOTE: Default values for these theme variables are picked from the selected theme. If you want to override the default values, you can use the `initialize` call to add your custom theme variable values.\n\nExample:\n\nNow let's override the default values for the `git0` to `git3` variables:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n  themeVariables:\n      'git0': '#ff0000'\n      'git1': '#00ff00'\n      'git2': '#0000ff'\n      'git3': '#ff00ff'\n      'git4': '#00ffff'\n      'git5': '#ffff00'\n      'git6': '#ff00ff'\n      'git7': '#00ffff'\n---\n       gitGraph\n       commit\n       branch develop\n       commit tag:\"v1.0.0\"\n       commit\n       checkout main\n       commit type: HIGHLIGHT\n       commit\n       merge develop\n       commit\n       branch featureA\n       commit\n\n```\n\nSee how the branch colors are changed to the values specified in the theme variables.\n\n### Customizing branch label colors\n\nYou can customize the branch label colors using the `gitBranchLabel0` to `gitBranchLabel7` theme variables. Mermaid allows you to set the colors for up-to 8 branches, where `gitBranchLabel0` variable will drive the value of the first branch label, `gitBranchLabel1` will drive the value of the second branch label and so on.\n\nLets see how the `default` theme is used to set the colors for the branch labels:\n\nNow let's override the default values for the `gitBranchLabel0` to `gitBranchLabel2` variables:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n  themeVariables:\n    'gitBranchLabel0': '#ffffff'\n    'gitBranchLabel1': '#ffffff'\n    'gitBranchLabel2': '#ffffff'\n    'gitBranchLabel3': '#ffffff'\n    'gitBranchLabel4': '#ffffff'\n    'gitBranchLabel5': '#ffffff'\n    'gitBranchLabel6': '#ffffff'\n    'gitBranchLabel7': '#ffffff'\n    'gitBranchLabel8': '#ffffff'\n    'gitBranchLabel9': '#ffffff'\n---\n  gitGraph\n    checkout main\n    branch branch1\n    branch branch2\n    branch branch3\n    branch branch4\n    branch branch5\n    branch branch6\n    branch branch7\n    branch branch8\n    branch branch9\n    checkout branch1\n    commit\n```\n\nHere, you can see that `branch8` and `branch9` colors and the styles are being picked from branch at index position `0` (`main`) and `1`(`branch1`) respectively, i.e., **branch themeVariables are repeated cyclically**.\n\n### Customizing Commit colors\n\nYou can customize commit using the `commitLabelColor` and `commitLabelBackground` theme variables for changes in the commit label color and background color respectively.\n\nExample:\nNow let's override the default values for the `commitLabelColor` to `commitLabelBackground` variables:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n  themeVariables:\n    commitLabelColor: '#ff0000'\n    commitLabelBackground: '#00ff00'\n---\n       gitGraph\n       commit\n       branch develop\n       commit tag:\"v1.0.0\"\n       commit\n       checkout main\n       commit type: HIGHLIGHT\n       commit\n       merge develop\n       commit\n       branch featureA\n       commit\n\n```\n\nSee how the commit label color and background color are changed to the values specified in the theme variables.\n\n### Customizing Commit Label Font Size\n\nYou can customize commit using the `commitLabelFontSize` theme variables for changing in the font size of the commit label .\n\nExample:\nNow let's override the default values for the `commitLabelFontSize` variable:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n  themeVariables:\n    commitLabelColor: '#ff0000'\n    commitLabelBackground: '#00ff00'\n    commitLabelFontSize: '16px'\n---\n       gitGraph\n       commit\n       branch develop\n       commit tag:\"v1.0.0\"\n       commit\n       checkout main\n       commit type: HIGHLIGHT\n       commit\n       merge develop\n       commit\n       branch featureA\n       commit\n\n```\n\nSee how the commit label font size changed.\n\n### Customizing Tag Label Font Size\n\nYou can customize commit using the `tagLabelFontSize` theme variables for changing in the font size of the tag label .\n\nExample:\nNow let's override the default values for the `tagLabelFontSize` variable:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n  themeVariables:\n    commitLabelColor: '#ff0000'\n    commitLabelBackground: '#00ff00'\n    tagLabelFontSize: '16px'\n---\n       gitGraph\n       commit\n       branch develop\n       commit tag:\"v1.0.0\"\n       commit\n       checkout main\n       commit type: HIGHLIGHT\n       commit\n       merge develop\n       commit\n       branch featureA\n       commit\n\n```\n\nSee how the tag label font size changed.\n\n### Customizing Tag colors\n\nYou can customize tag using the `tagLabelColor`,`tagLabelBackground` and `tagLabelBorder` theme variables for changes in the tag label color,tag label background color and tag label border respectively.\nExample:\nNow let's override the default values for the `tagLabelColor`, `tagLabelBackground` and to `tagLabelBorder` variables:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n  themeVariables:\n    tagLabelColor: '#ff0000'\n    tagLabelBackground: '#00ff00'\n    tagLabelBorder: '#0000ff'\n---\n       gitGraph\n       commit\n       branch develop\n       commit tag:\"v1.0.0\"\n       commit\n       checkout main\n       commit type: HIGHLIGHT\n       commit\n       merge develop\n       commit\n       branch featureA\n       commit\n\n```\n\nSee how the tag colors are changed to the values specified in the theme variables.\n\n### Customizing Highlight commit colors\n\nYou can customize the highlight commit colors in relation to the branch it is on using the `gitInv0` to `gitInv7` theme variables. Mermaid allows you to set the colors for up-to 8 branches specific highlight commit, where `gitInv0` variable will drive the value of the first branch's highlight commits, `gitInv1` will drive the value of the second branch's highlight commit label and so on.\n\nExample:\n\nNow let's override the default values for the `git0` to `git3` variables:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n  themeVariables:\n    'gitInv0': '#ff0000'\n---\n       gitGraph\n       commit\n       branch develop\n       commit tag:\"v1.0.0\"\n       commit\n       checkout main\n       commit type: HIGHLIGHT\n       commit\n       merge develop\n       commit\n       branch featureA\n       commit\n\n```\n\nSee how the highlighted commit color on the first branch is changed to the value specified in the theme variable `gitInv0`.\n","packages/mermaid/src/docs/syntax/ishikawa.md":"# Ishikawa diagram (v11.12.3+)\n\nIshikawa diagrams are used to represent causes of a specific event (or a problem).\nThey are also known as fishbone diagrams, herringbone diagrams or cause-and-effect diagrams.\nThe diagram resembles a fish skeleton, with the main problem at the head and the causes branching off from the spine.\n\n```warning\nThis is a new diagram type in Mermaid. Its syntax may evolve in future versions.\n```\n\n## Syntax\n\n```mermaid\nishikawa-beta\n    Blurry Photo\n    Process\n        Out of focus\n        Shutter speed too slow\n        Protective film not removed\n        Beautification filter applied\n    User\n        Shaky hands\n    Equipment\n        LENS\n            Inappropriate lens\n            Damaged lens\n            Dirty lens\n        SENSOR\n            Damaged sensor\n            Dirty sensor\n    Environment\n        Subject moved too quickly\n        Too dark\n```\n\n- The first line is the event (problem) of the diagram.\n- Subsequent lines are causes of the event.\n- \"Fishbone\" structure is indicated by indentation.\n","packages/mermaid/src/docs/syntax/kanban.md":"# Mermaid Kanban Diagram Documentation\n\nMermaid’s Kanban diagram allows you to create visual representations of tasks moving through different stages of a workflow. This guide explains how to use the Kanban diagram syntax, based on the provided example.\n\n## Overview\n\nA Kanban diagram in Mermaid starts with the kanban keyword, followed by the definition of columns (stages) and tasks within those columns.\n\n```mermaid-example\nkanban\n  column1[Column Title]\n    task1[Task Description]\n```\n\n## Defining Columns\n\nColumns represent the different stages in your workflow, such as “Todo,” “In Progress,” “Done,” etc. Each column is defined using a unique identifier and a title enclosed in square brackets.\n\n**Syntax:**\n\n```\ncolumnId[Column Title]\n```\n\n- columnId: A unique identifier for the column.\n- [Column Title]: The title displayed on the column header.\n\nLike this `id1[Todo]`\n\n## Adding Tasks to Columns\n\nTasks are listed under their respective columns with an indentation. Each task also has a unique identifier and a description enclosed in square brackets.\n\n**Syntax:**\n\n```\ntaskId[Task Description]\n```\n\n    •\ttaskId: A unique identifier for the task.\n    •\t[Task Description]: The description of the task.\n\n**Example:**\n\n```\ndocs[Create Documentation]\n```\n\n## Adding Metadata to Tasks\n\nYou can include additional metadata for each task using the @{ ... } syntax. Metadata can contain key-value pairs like assigned, ticket, priority, etc. This will be rendered added to the rendering of the node.\n\n## Supported Metadata Keys\n\n    •\tassigned: Specifies who is responsible for the task.\n    •\tticket: Links the task to a ticket or issue number.\n    •\tpriority: Indicates the urgency of the task. Allowed values: 'Very High', 'High', 'Low' and 'Very Low'\n\n```mermaid-example\nkanban\ntodo[Todo]\n  id3[Update Database Function]@{ ticket: MC-2037, assigned: 'knsv', priority: 'High' }\n```\n\n## Configuration Options\n\nYou can customize the Kanban diagram using a configuration block at the beginning of your markdown file. This is useful for setting global settings like a base URL for tickets. Currently there is one configuration option for kanban diagrams `ticketBaseUrl`. This can be set as in the following example:\n\n```yaml\n---\nconfig:\n  kanban:\n    ticketBaseUrl: 'https://yourproject.atlassian.net/browse/#TICKET#'\n---\n```\n\nWhen the kanban item has an assigned ticket number the ticket number in the diagram will have a link to an external system where the ticket is defined. The `ticketBaseUrl` sets the base URL to the external system and #TICKET# is replaced with the ticket value from task metadata to create a valid link.\n\n## Full Example\n\nBelow is the full Kanban diagram based on the provided example:\n\n```mermaid-example\n---\nconfig:\n  kanban:\n    ticketBaseUrl: 'https://mermaidchart.atlassian.net/browse/#TICKET#'\n---\nkanban\n  Todo\n    [Create Documentation]\n    docs[Create Blog about the new diagram]\n  [In progress]\n    id6[Create renderer so that it works in all cases. We also add some extra text here for testing purposes. And some more just for the extra flare.]\n  id9[Ready for deploy]\n    id8[Design grammar]@{ assigned: 'knsv' }\n  id10[Ready for test]\n    id4[Create parsing tests]@{ ticket: MC-2038, assigned: 'K.Sveidqvist', priority: 'High' }\n    id66[last item]@{ priority: 'Very Low', assigned: 'knsv' }\n  id11[Done]\n    id5[define getData]\n    id2[Title of diagram is more than 100 chars when user duplicates diagram with 100 char]@{ ticket: MC-2036, priority: 'Very High'}\n    id3[Update DB function]@{ ticket: MC-2037, assigned: knsv, priority: 'High' }\n\n  id12[Can't reproduce]\n    id3[Weird flickering in Firefox]\n```\n\nIn conclusion, creating a Kanban diagram in Mermaid is a straightforward process that effectively visualizes your workflow. Start by using the kanban keyword to initiate the diagram. Define your columns with unique identifiers and titles to represent different stages of your project. Under each column, list your tasks—also with unique identifiers—and provide detailed descriptions as needed. Remember that proper indentation is crucial; tasks must be indented under their parent columns to maintain the correct structure.\n\nYou can enhance your diagram by adding optional metadata to tasks using the @{ ... } syntax, which allows you to include additional context such as assignee, ticket numbers, and priority levels. For further customization, utilize the configuration block at the top of your file to set global options like ticketBaseUrl for linking tickets directly from your diagram.\n\nBy adhering to these guidelines—ensuring unique identifiers, proper indentation, and utilizing metadata and configuration options—you can create a comprehensive and customized Kanban board that effectively maps out your project’s workflow using Mermaid.\n","packages/mermaid/src/docs/syntax/mindmap.md":"# Mindmap\n\n> Mindmap: This is an experimental diagram for now. The syntax and properties can change in future releases. The syntax is stable except for the icon integration which is the experimental part.\n\n\"A mind map is a diagram used to visually organize information into a hierarchy, showing relationships among pieces of the whole. It is often created around a single concept, drawn as an image in the center of a blank page, to which associated representations of ideas such as images, words and parts of words are added. Major ideas are connected directly to the central concept, and other ideas branch out from those major ideas.\" Wikipedia\n\n### An example of a mindmap.\n\n```mermaid\nmindmap\n  root((mindmap))\n    Origins\n      Long history\n      ::icon(fa fa-book)\n      Popularisation\n        British popular psychology author Tony Buzan\n    Research\n      On effectiveness
and features\n      On Automatic creation\n        Uses\n            Creative techniques\n            Strategic planning\n            Argument mapping\n    Tools\n      Pen and paper\n      Mermaid\n\n```\n\n## Syntax\n\nThe syntax for creating Mindmaps is simple and relies on indentation for setting the levels in the hierarchy.\n\nIn the following example you can see how there are 3 different levels. One with starting at the left of the text and another level with two rows starting at the same column, defining the node A. At the end there is one more level where the text is indented further than the previous lines defining the nodes B and C.\n\n```\nmindmap\n    Root\n        A\n            B\n            C\n```\n\nIn summary is a simple text outline where there is one node at the root level called `Root` which has one child `A`. `A` in turn has two children `B`and `C`. In the diagram below we can see this rendered as a mindmap.\n\n```mermaid\nmindmap\nRoot\n    A\n      B\n      C\n```\n\nIn this way we can use a text outline to generate a hierarchical mindmap.\n\n## Different shapes\n\nMermaid mindmaps can show nodes using different shapes. When specifying a shape for a node the syntax is similar to flowchart nodes, with an id followed by the shape definition and with the text within the shape delimiters. Where possible we try/will try to keep the same shapes as for flowcharts, even though they are not all supported from the start.\n\nMindmap can show the following shapes:\n\n### Square\n\n```mermaid-example\nmindmap\n    id[I am a square]\n```\n\n### Rounded square\n\n```mermaid-example\nmindmap\n    id(I am a rounded square)\n```\n\n### Circle\n\n```mermaid-example\nmindmap\n    id((I am a circle))\n```\n\n### Bang\n\n```mermaid-example\nmindmap\n    id))I am a bang((\n```\n\n### Cloud\n\n```mermaid-example\nmindmap\n    id)I am a cloud(\n```\n\n### Hexagon\n\n```mermaid-example\nmindmap\n    id{{I am a hexagon}}\n```\n\n### Default\n\n```mermaid-example\nmindmap\n    I am the default shape\n```\n\nMore shapes will be added, beginning with the shapes available in flowcharts.\n\n## Coloring by depth (v12.2.0+)\n\nBy default, mindmaps use a different color for each top-level branch. Descendants inherit their branch's color. Set `mindmap.colorBy` to `depth` to give all nodes at the same hierarchy level the same color, across every branch:\n\n```mermaid-example\n---\nconfig:\n  mindmap:\n    colorBy: depth\n---\nmindmap\n  root((mindmap))\n    origins{{Origins}}\n      history[Long history]\n        Popularisation\n        British popular psychology author Tony Buzan\n    research{{Research}}\n      uses[Uses]\n        Creative techniques\n```\n\nDepth counts parent-child relationships, not spaces: the root has depth 0, its children have depth 1, and their children have depth 2. Uneven indentation does not change the color of nodes that share a depth.\n\nWith the classic look, the root uses `git0` for its background and `gitBranchLabel0` for its label (`redux` themes color HTML labels with `nodeBorder` instead). Depths 1 through 11 use `cScale1` through `cScale11` for backgrounds and `cScaleLabel1` through `cScaleLabel11` for labels. Deeper levels repeat those eleven colors. Each edge uses the `cScale` color of its child node.\n\nTo choose the color of each level, set those variables with the `base` theme and pick contrasting background and label colors. The `neo` look colors the root label with `cScaleLabel0`, so set it too. In the `neo` look, also set `useGradient: false`, because otherwise `base` paints every node with `mainBkg`:\n\n```mermaid-example\n---\nconfig:\n  theme: base\n  mindmap:\n    colorBy: depth\n  themeVariables:\n    git0: '#374151'\n    gitBranchLabel0: '#ffffff'\n    cScaleLabel0: '#ffffff'\n    cScale1: '#bfdbfe'\n    cScaleLabel1: '#172554'\n    cScale2: '#bbf7d0'\n    cScaleLabel2: '#14532d'\n    cScale3: '#fde68a'\n    cScaleLabel3: '#451a03'\n---\nmindmap\n  root((mindmap))\n    origins{{Origins}}\n      history[Long history]\n        Popularisation\n        British popular psychology author Tony Buzan\n    research{{Research}}\n      uses[Uses]\n        Creative techniques\n```\n\nDepth mode uses the same theme styles as branch coloring and only changes which nodes share a color. In the `neo` look, some themes use one background for every node in both modes:\n\n- Themes with `useGradient` enabled paint every node, including the root, with `mainBkg`. It is on by default in `base`, `dark`, `forest`, `neo`, `neo-dark` and `neutral`. Set `themeVariables.useGradient: false` to show depth colors on node backgrounds.\n- `neutral`, `redux` and `redux-dark` paint every node below the root with `mainBkg` even without the gradient, and use one label color for all of them.\n\nIn the `neo` look, the root label uses `cScaleLabel0` (`cScaleLabel1` in `neutral`, `nodeBorder` in `redux` themes). Edges keep their depth colors, except in `neo-dark` and the `redux` themes.\n\nSet `mindmap.colorBy` to `branch` (the default) to restore branch coloring.\n\n# Icons and classes\n\n## Icons\n\nAs with flowcharts you can add icons to your nodes but with an updated syntax. The styling for the font based icons are added during the integration so that they are available for the web page. _This is not something a diagram author can do but has to be done with the site administrator or the integrator_. Once the icon fonts are in place you add them to the mind map nodes using the `::icon()` syntax. You place the classes for the icon within the parenthesis like in the following example where icons for material design and [Font Awesome 5](https://fontawesome.com/v5/search?o=r&m=free) are displayed. The intention is that this approach should be used for all diagrams supporting icons. **Experimental feature:** This wider scope is also the reason Mindmaps are experimental as this syntax and approach could change.\n\n```mermaid-example\nmindmap\n    Root\n        A\n        ::icon(fa fa-book)\n        B(B)\n        ::icon(mdi mdi-skull-outline)\n```\n\n## Classes\n\nAgain the syntax for adding classes is similar to flowcharts. You can add classes using a triple colon following a number of css classes separated by space. In the following example one of the nodes has two custom classes attached urgent turning the background red and the text white and large increasing the font size:\n\n```mermaid-example\nmindmap\n    Root\n        A[A]\n        :::urgent large\n        B(B)\n        C\n```\n\n_These classes need to be supplied by the site administrator._\n\n## Unclear indentation\n\nThe actual indentation does not really matter only compared with the previous rows. If we take the previous example and disrupt it a little we can see how the calculations are performed. Let us start with placing C with a smaller indentation than `B` but larger then `A`.\n\n```\nmindmap\n    Root\n        A\n            B\n          C\n```\n\nThis outline is unclear as `B` clearly is a child of `A` but when we move on to `C` the clarity is lost. `C` is neither a child of `B` with a higher indentation nor does it have the same indentation as `B`. The only thing that is clear is that the first node with smaller indentation, indicating a parent, is A. Then Mermaid relies on this known truth and compensates for the unclear indentation and selects `A` as a parent of `C` leading till the same diagram with `B` and `C` as siblings.\n\n```mermaid\nmindmap\nRoot\n    A\n        B\n      C\n```\n\n## Markdown Strings\n\nThe \"Markdown Strings\" feature enhances mind maps by offering a more versatile string type, which supports text formatting options such as bold and italics, and automatically wraps text within labels.\n\n```mermaid-example\nmindmap\n    id1[\"`**Root** with\na second line\nUnicode works too: 🤓`\"]\n      id2[\"`The dog in **the** hog... a *very long text* that wraps to a new line`\"]\n      id3[Regular labels still works]\n```\n\nFormatting:\n\n- For bold text, use double asterisks \\*\\* before and after the text.\n- For italics, use single asterisks \\* before and after the text.\n- With traditional strings, you needed to add 
 tags for text to wrap in nodes. However, markdown strings automatically wrap text when it becomes too long and allows you to start a new line by simply using a newline character instead of a 
 tag.\n\n## Integrating with your library/website.\n\nMindmap uses the experimental lazy loading & async rendering features which could change in the future. From version 9.4.0 this diagram is included in mermaid but use lazy loading in order to keep the size of mermaid down. This is important in order to be able to add additional diagrams going forward.\n\nYou can still use the pre 9.4.0 method to add mermaid with mindmaps to a web page:\n\n```html\n\n```\n\nFrom version 9.4.0 you can simplify this code to:\n\n```html\n\n```\n\nYou can also refer the [implementation in the live editor](https://github.com/mermaid-js/mermaid-live-editor/blob/develop/src/lib/util/mermaid.ts) to see how the async loading is done.\n\n\n\n## Layouts\n\nMermaid also supports a Tidy Tree layout for mindmaps.\n\n```\n---\nconfig:\n  layout: tidy-tree\n---\nmindmap\nroot((mindmap is a long thing))\n  A\n  B\n  C\n  D\n```\n\nInstructions to add and register tidy-tree layout are present in [Tidy Tree Configuration](/config/tidy-tree)\n","packages/mermaid/src/docs/syntax/packet.md":"# Packet Diagram (v11.0.0+)\n\n## Introduction\n\nA packet diagram is a visual representation used to illustrate the structure and contents of a network packet. Network packets are the fundamental units of data transferred over a network.\n\n## Usage\n\nThis diagram type is particularly useful for developers, network engineers, educators, and students who require a clear and concise way to represent the structure of network packets.\n\n## Syntax\n\n```\npacket\nstart: \"Block name\" %% Single-bit block\nstart-end: \"Block name\" %% Multi-bit blocks\n... More Fields ...\n```\n\n### Bits Syntax (v11.7.0+)\n\nUsing start and end bit counts can be difficult, especially when modifying a design. For this we add a bit count field, which starts from the end of the previous field automagically. Use `+` to set the number of bits, thus:\n\n```\npacket\n+1: \"Block name\" %% Single-bit block\n+8: \"Block name\" %% 8-bit block\n9-15: \"Manually set start and end, it's fine to mix and match\"\n... More Fields ...\n```\n\n## Examples\n\n```mermaid-example\n---\ntitle: \"TCP Packet\"\n---\npacket\n0-15: \"Source Port\"\n16-31: \"Destination Port\"\n32-63: \"Sequence Number\"\n64-95: \"Acknowledgment Number\"\n96-99: \"Data Offset\"\n100-105: \"Reserved\"\n106: \"URG\"\n107: \"ACK\"\n108: \"PSH\"\n109: \"RST\"\n110: \"SYN\"\n111: \"FIN\"\n112-127: \"Window\"\n128-143: \"Checksum\"\n144-159: \"Urgent Pointer\"\n160-191: \"(Options and Padding)\"\n192-255: \"Data (variable length)\"\n```\n\n```mermaid-example\npacket\ntitle UDP Packet\n+16: \"Source Port\"\n+16: \"Destination Port\"\n32-47: \"Length\"\n48-63: \"Checksum\"\n64-95: \"Data (variable length)\"\n```\n\n## Details of Syntax\n\n- **Ranges**: Each line after the title represents a different field in the packet. The range (e.g., `0-15`) indicates the bit positions in the packet.\n- **Field Description**: A brief description of what the field represents, enclosed in quotes.\n\n### Bit Numbering Order (v12.0.0+)\n\nRows are numbered from their lowest bit on the left up to their highest bit on the right, which suits network packets. Hardware registers are conventionally drawn the other way round, with the most significant bit on the left and bit 0 on the right. Set `bitOrder: descending` to mirror every row:\n\n```mermaid-example\n---\nconfig:\n  packet:\n    showBits: true\n    bitOrder: descending\n    bitsPerRow: 16\n---\npacket\n0-7: \"DATA\"\n8-11: \"TYPE\"\n12: \"EN\"\n13-15: \"RESERVED\"\n```\n\nOnly the drawing is mirrored. Fields are still declared lowest bit first (`0-7`, never `7-0`) and keep their width, so the same diagram can be switched between the two conventions by changing `bitOrder` alone.\n\nEach row is mirrored on its own, so a packet wider than `bitsPerRow` reads as a stack of words that each run from their highest bit down to their lowest: with the default `bitsPerRow: 32`, the second row runs from bit 63 down to bit 32, not down to bit 0. A row that is not completely filled is padded on the left, keeping its lowest bit flush against the right edge.\n\n## Configuration\n\nPlease refer to the [configuration](/config/schema-docs/config-defs-packet-diagram-config.html) guide for details.\n\n\n","packages/mermaid/src/docs/syntax/pie.md":"","packages/mermaid/src/docs/syntax/quadrantChart.md":"","packages/mermaid/src/docs/syntax/radar.md":"","packages/mermaid/src/docs/syntax/railroad.md":"","packages/mermaid/src/docs/syntax/requirementDiagram.md":"","packages/mermaid/src/docs/syntax/sankey.md":"","packages/mermaid/src/docs/syntax/sequenceDiagram.md":"","packages/mermaid/src/docs/syntax/stateDiagram.md":"","packages/mermaid/src/docs/syntax/swimlanes.md":"","packages/mermaid/src/docs/syntax/timeline.md":"","packages/mermaid/src/docs/syntax/treeView.md":"","packages/mermaid/src/docs/syntax/treemap.md":"","packages/mermaid/src/docs/syntax/usecase.md":"","packages/mermaid/src/docs/syntax/userJourney.md":"","packages/mermaid/src/docs/syntax/venn.md":"","packages/mermaid/src/docs/syntax/wardley.md":"","packages/mermaid/src/docs/syntax/xyChart.md":"","packages/mermaid/src/docs/syntax/zenuml.md":"","packages/mermaid/src/docs/tsconfig.json":"","packages/parser/README.md":"","packages/tiny/README.md":""},"items":[{"name":"adding-new-shape.md","path":"packages/mermaid/src/docs/adding-new-shape.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/adding-new-shape.md","title":"Docs Skill","category":"anthropic-skill","format":"markdown","content":"# Custom SVG Shapes Library\n\nThis library provides a collection of custom SVG shapes, utilities, and helpers for generating diagram components. The shapes are designed to be used within an SVG container and include a variety of common and complex shapes.\n\n## Overview\n\n## Shape Helpers and Utilities\n\nBefore starting with shape creation, it's essential to familiarize yourself with the utilities provided in the `utils.ts` file from `packages/mermaid/src/rendering-util/rendering-elements/shapes/util.js`. These utilities are designed to assist with various aspects of SVG shape manipulation and ensure consistent and accurate rendering.\n\n## Available Utilities\n\n### 1. `labelHelper`\n\n- **Purpose**: This function creates and inserts labels inside SVG shapes.\n- **Features**:\n  - Handles both HTML labels and plain text.\n  - Calculates the bounding box dimensions of the label.\n  - Ensures proper positioning of labels within shapes.\n\n### 2. `updateNodeBounds`\n\n- **Purpose**: Updates the bounding box dimensions (width and height) of a node.\n- **Usage**:\n  - Adjusts the size of the node to fit the content or shape.\n  - Useful for ensuring that shapes resize appropriately based on their content.\n\n### 3. `insertPolygonShape`\n\n- **Purpose**: Inserts a polygon shape into an SVG container.\n- **Features**:\n  - Handles the creation and insertion of complex polygonal shapes.\n  - Configures the shape's appearance and positioning within the SVG container.\n\n### 4. `getNodeClasses`\n\n- **Purpose**: Returns the appropriate CSS classes for a node based on its configuration.\n- **Usage**:\n  - Dynamically applies CSS classes to nodes for styling purposes.\n  - Ensures that nodes adhere to the desired design and theme.\n\n### 5. `createPathFromPoints`\n\n- **Purpose**: Generates an SVG path string from an array of points.\n- **Usage**:\n  - Converts a list of points into a smooth path.\n  - Useful for creating custom shapes or paths within the SVG.\n\n### 6. `generateFullSineWavePoints`\n\n- **Purpose**: Generates points for a sine wave, useful for creating wavy-edged shapes.\n- **Usage**:\n  - Facilitates the creation of shapes with wavy or sine-wave edges.\n  - Can be used to add decorative or dynamic edges to shapes.\n\n## Getting Started\n\nTo utilize these utilities, simply import them from the `utils.ts` file into your shape creation script. These helpers will streamline the process of building and customizing SVG shapes, ensuring consistent results across your projects.\n\n```typescript\nimport {\n  labelHelper,\n  updateNodeBounds,\n  insertPolygonShape,\n  getNodeClasses,\n  createPathFromPoints,\n  generateFullSineWavePoints,\n} from './utils.ts';\n```\n\n## Example Usage\n\nHere’s a basic example of how you might use some of these utilities:\n\n```typescript\nimport { labelHelper, insertPolygonShape } from './utils.ts';\n\nconst svgContainer = document.getElementById('svgContainer');\n\n// Insert a polygon shape\ninsertPolygonShape(svgContainer /* shape-specific parameters */);\n\n// Create and insert a label inside the shape\nlabelHelper(svgContainer /* label-specific parameters */);\n```\n\n## Adding New Shapes\n\n### 1. Create the Shape Function\n\nTo add a new shape:\n\n- **Create the shape function**: Create a new file of name of the shape and export a function in the `shapes` directory that generates your shape. The file and function should follow the pattern used in existing shapes and return an SVG element.\n\n- **Example**:\n\n  ```typescript\n  import { Node, RenderOptions } from '../../types.ts';\n\n  export const myNewShape = async (\n    parent: SVGAElement,\n    node: Node,\n    renderOptions: RenderOptions\n  ) => {\n    // Create your shape here\n    const shape = parent.insert('g').attr('class', 'my-new-shape');\n    // Add other elements or styles as needed\n    return shape;\n  };\n  ```\n\n### 2. Register the Shape\n\n- **Register the shape**: Add your shape to the `shapes` object in the [main shapes module](../rendering-util/rendering-elements/shapes.ts). This allows your shape to be recognized and used within the system.\n\n- **Example**:\n\n  ```typescript\n  import { myNewShape } from './shapes/myNewShape';\n\n  const shapes = {\n    ...,\n    {\n      semanticName: 'My Shape',\n      name: 'Shape Name',\n      shortName: '',\n      description: '',\n      aliases: ['', '', '', ''],\n      handler: myNewShape,\n    },\n  };\n  ```\n\n# Shape Intersection Algorithms\n\nThis contains algorithms and utilities for calculating intersection points for various shapes in SVG. Arrow intersection points are crucial for accurately determining where arrows connect with shapes. Ensuring precise intersection points enhances the clarity and accuracy of flowcharts and diagrams.\n\n## Shape Intersection Functions\n\n### 1. `Ellipse`\n\nCalculates the intersection points for an ellipse.\n\n**Usage**:\n\n```javascript\nimport intersectEllipse from './intersect-ellipse.js';\n\nconst intersection = intersectEllipse(node, rx, ry, point);\n```\n\n- **Parameters**:\n  - `node`: The SVG node element.\n  - `rx`: The x-radius of the ellipse.\n  - `ry`: The y-radius of the ellipse.\n  - `point`: The point from which the intersection is calculated.\n\n### 2. `intersectRect`\n\nCalculates the intersection points for a rectangle.\n\n**Usage**:\n\n```javascript\nimport intersectRect from './intersect-rect.js';\n\nconst intersection = intersectRect(node, point);\n```\n\n- **Parameters**:\n  - `node`: The SVG node element.\n  - `point`: The point from which the intersection is calculated.\n\n### 3. `intersectPolygon`\n\nCalculates the intersection points for a polygon.\n\n**Usage**:\n\n```javascript\nimport intersectPolygon from './intersect-polygon.js';\n\nconst intersection = intersectPolygon(node, polyPoints, point);\n```\n\n- **Parameters**:\n  - `node`: The SVG node element.\n  - `polyPoints`: Array of points defining the polygon.\n  - `point`: The point from which the intersection is calculated.\n\n## Cypress Tests\n\nTo ensure the robustness of the flowchart shapes, there are implementation of comprehensive Cypress test cases in `newShapes.spec.ts` file. These tests cover various aspects such as:\n\n- **Shapes**: Testing new shapes like `bowTieRect`, `waveRectangle`, `trapezoidalPentagon`, etc.\n- **Looks**: Verifying shapes under different visual styles (`classic` and `handDrawn`).\n- **Directions**: Ensuring correct rendering in all flow directions of arrows :\n  - `TB` `(Top -> Bottom)`\n  - `BT` `(Bottom -> Top)`\n  - `LR` `(Left -> Right)`\n  - `RL` `(Right -> Left)`\n- **Labels**: Testing shapes with different labels, including:\n  - No labels\n  - Short labels\n  - Very long labels\n  - Markdown with `htmlLabels:true` and `htmlLabels:false`\n- **Styles**: Applying custom styles to shapes and verifying correct rendering.\n- **Class Definitions**: Using `classDef` to apply custom classes and testing their impact.\n\n### Running the Tests\n\nTo run the Cypress tests, follow these steps:\n\n1. Ensure you have all dependencies installed by running:\n   ```bash\n   pnpm install\n   ```\n2. Start the Cypress test runner:\n\n   ```bash\n   cypress open --env updateSnapshots=true\n\n   ```\n\n3. Select the test suite from the Cypress interface to run all the flowchart shape tests.\n","isInternal":false,"tokens":1598,"sizeBytes":7184},{"name":"contributing.md","path":"packages/mermaid/src/docs/community/contributing.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/community/contributing.md","title":"Community Skill","category":"anthropic-skill","format":"markdown","content":"# Mermaid Contributing Guide\n\nYou decided to take part in the development? Welcome!\n\nWe are trying to make our guidelines for you as explicit and detailed as possible.\n\n## Initial Setup\n\nInitial setup consists of 3 main steps:\n\n```mermaid-nocode\nflowchart LR\n  source --> requirements --> setup\n\n  source[Get the Source Code]\n  requirements[Install the Requirements]\n  setup[Install Packages]\n```\n\n### Get the Source Code\n\nIn GitHub, you first [**fork a mermaid repository**](https://github.com/mermaid-js/mermaid/fork) when you are going to make changes and submit pull requests.\n\nThen you **clone** a copy to your local development machine (e.g. where you code) to make a copy with all the files to work with.\n\n```tip\n[Here is a GitHub document that gives an overview of the process](https://docs.github.com/en/get-started/quickstart/fork-a-repo).\n```\n\n```bash\ngit clone git@github.com/your-fork/mermaid\n```\n\nOnce you have cloned the repository onto your development machine, change into the `mermaid` project folder (the top level directory of the mermaid project repository)\n\n```bash\ncd mermaid\n```\n\n### Install Requirements\n\nWe support **development within Docker** environment along with **host setup**. You may choose it up to your preferences.\n\n**Host**\n\nThese are the tools we use for working with the code and documentation:\n\n- [Node.js](https://nodejs.org/en/).\n- [pnpm](https://pnpm.io/) package manager.\n\nThe following commands must be sufficient enough to start with:\n\n```bash\ncurl -fsSL https://get.pnpm.io/install.sh | sh -\npnpm env use --global 20\n```\n\nYou may also need to reload `.shrc` or `.bashrc` afterwards.\n\n**Docker**\n\n[Install Docker](https://docs.docker.com/engine/install/). And that is pretty much all you need.\n\nOptionally, to run GUI (Cypress) within Docker you will also need an X11 server installed.\nYou might already have it installed, so check this by running:\n\n```bash\necho $DISPLAY\n```\n\nIf the `$DISPLAY` variable is not empty, then an X11 server is running. Otherwise you may need to install one.\n\n### Install Packages\n\n**Host**\n\nInstall packages:\n\n```bash\npnpm install\n```\n\n**Docker**\n\nFor development using Docker there is a self-documented `run` bash script, which provides convenient aliases for `docker compose` commands.\n\nMake sure that `./run` script is executable:\n\n```bash\nchmod +x run\n```\n\n```tip\nTo get detailed help simply type `./run` or `./run help`.\n\nIt also has short _Development quick start guide_ embedded.\n```\n\nThen install packages:\n\n```bash\n./run pnpm install\n```\n\n### Verify Everything Works\n\nThis step is optional, but it helps to make sure that everything in development branch was OK before you started making any changes.\n\nYou can run the `test` script to verify that pnpm is working _and_ that the repository has been cloned correctly:\n\n**Host**\n\n```bash\npnpm test\n```\n\n**Docker**\n\n```bash\n./run pnpm test\n```\n\nThe `test` script and others are in the top-level `package.json` file.\n\nAll tests should run successfully without any errors or failures.\n\n```note\nYou might see _lint_ or _formatting_ warnings. Those are ok during this step.\n```\n\n## Workflow\n\nContributing process is very simple and straightforward:\n\n```mermaid-nocode\n  flowchart LR\n\n  branch --> changes --> submit\n  branch[Checkout a New Branch]\n  changes[Make Changes]\n  submit[Submit a PR]\n```\n\nMermaid uses a [Git Flow](https://guides.github.com/introduction/flow/)–inspired approach to branching.\n\nDevelopment is done in the `develop` branch.\n\n```mermaid-nocode\n---\nconfig:\n  gitGraph:\n    mainBranchName: develop\n---\ngitGraph LR:\n  commit\n  commit\n  branch \"docs/2910_update-guidelines\" order: 1\n  commit\n  commit\n  commit\n  checkout develop\n  merge \"docs/2910_update-guidelines\"\n  commit\n```\n\nTo prepare a new version for release the maintainers create a `release/vX.X.X` branch from `develop` for testing. Once the release happens we add a tag to the `release` branch and merge it with `master`. The live product and on-line documentation are what is in the `master` branch.\n\n## Checkout a New Branch\n\n```tip\nAll new work should be based on the `develop` branch.\n```\n\nMake sure you have the most up-to-date version of the `develop` branch.\n\nCheck out the `develop` branch, then `fetch` or `pull` to update it:\n\n```bash\ngit checkout develop\ngit fetch # or `git pull`\n```\n\nCreate a new branch for your work:\n\n```bash\ngit checkout -b docs/2910_update-contributing-guidelines\n```\n\nWe use the following naming convention for branches:\n\n```txt\n[feature | bug | chore | docs]/[issue number]_[short-description]\n```\n\nYou can always check current [configuration of labelling and branch prefixes](https://github.com/mermaid-js/mermaid/blob/develop/.github/pr-labeler.yml)\n\n- The first part is the **type** of change: a `feature`, `bug`, `chore`, `docs`\n- followed by a **slash** (`/`),which helps to group like types together in many git tools\n- followed by the **issue number**, e.g. `2910`\n- followed by an **underscore** (`_`)\n- followed by a **short description** with dashes (`-`) or underscores (`_`) instead of spaces\n\n```mermaid-nocode\nflowchart LR\n  feature --> slash\n  bug --> slash\n  chore --> slash\n  docs --> slash\n  slash --> 2945 --> underscore\n  slash --> 1123 --> underscore\n  underscore --> short_description_1\n  underscore --> short_description_2\n\n  underscore[\"_\"]\n  slash[\"/\"]\n\n  short_description_1[\"state-diagram-new-arrow-florbs\"]\n  short_description_2[\"fix_random_ugly_red_text\"]\n```\n\nIf your work is specific to a single diagram type, it is a good idea to put the diagram type at the start of the description. This will help us keep release notes organized by a diagram type.\n\n```note\nA new feature described in issue 2945 that adds a new arrow type called 'florbs' to state diagrams\n\n`feature/2945_state-diagram-new-arrow-florbs`\n```\n\n```tip\nA bug described in issue 1123 that causes random ugly red text in multiple diagram types\n\n`bug/1123_fix_random_ugly_red_text`\n```\n\n## Contributing Code\n\nCode is the heart of every software project. We strive to make it better. Who if not us?\n\n### Where is the Code Located?\n\nThe core of Mermaid is located under `packages/mermaid/src`.\n\n### Building Mermaid Locally\n\n**Host**\n\n```bash\npnpm run build\n```\n\n**Docker**\n\n```bash\n./run build\n```\n\nThis will build the Mermaid library and the documentation site.\n\n### Running Mermaid Locally\n\n**Host**\n\n```bash\npnpm run dev\n```\n\n**Docker**\n\n```bash\n./run dev\n```\n\nAfter starting the dev server open  in your browser.\n\nNow you are ready to make your changes!\n\nNote: By default, the Mermaid service will run on port 9000. To use a different port, change the environment variable `MERMAID_PORT` in the file `.env`. You should only need to do this if you are using port 9000 to run other projects.\n\n### Make Changes\n\nHave a look at . There is a list of demos that can be used to see and test your changes.\n\nIf you need a specific diagram, you can duplicate the `example.html` file in `/demos/dev` and add your own mermaid code to your copy.\n\nThat will be served at .\nAfter making code changes, the dev server will rebuild the mermaid library and automatically reload the page.\n\nEdit files in `packages/mermaid/src` as required.\n\n### Write Tests\n\nTests ensure that each function, module, or part of code does what it says it will do. This is critically important when other changes are made to ensure that existing code is not broken (no regression).\n\nJust as important, the tests act as _specifications:_ they specify what the code does (or should do).\nWhenever someone is new to a section of code, they should be able to read the tests to get a thorough understanding of what it does and why.\n\nIf you are fixing a bug, you should add tests to ensure that your code has actually fixed the bug, to specify/describe what the code is doing, and to ensure the bug doesn't happen again.\n(If there had been a test for the situation, the bug never would have happened in the first place.)\nYou may need to change existing tests if they were inaccurate.\n\nIf you are adding a feature, you will definitely need to add tests. Depending on the size of your feature, you may need to add integration tests.\n\n#### Unit Tests\n\nUnit tests are tests that test a single function or module. They are the easiest to write and the fastest to run.\n\nUnit tests are mandatory for all code except the layout tests. (The layouts are tested with integration tests.)\n\nWe use [Vitest](https://vitest.dev) to run unit tests.\n\n**Host**\n\nYou can use the following command to run the unit tests:\n\n```sh\npnpm test\n```\n\nWhen writing new tests, it's easier to have the tests automatically run as you make changes. You can do this by running the following command:\n\n```sh\npnpm test:watch\n```\n\n**Docker**\n\nWhen using Docker prepend your command with `./run`:\n\n```sh\n./run pnpm test\n```\n\n##### Testing the DOM\n\nOne can use `jsdomIt` to test any part of Mermaid that interacts with the DOM, as long as it is not related to the layout.\n\nThe function `jsdomIt` ([developed in utils.ts](../../tests/util.ts)) overrides `it` from `vitest`, and creates a pseudo-browser environment that works almost like the real deal for the duration of the test. It uses JSDOM to create a DOM, and adds objects `window` and `document` to `global` to mock the browser environment.\n\n> [!NOTE]\n> The layout cannot work in `jsdomIt` tests because JSDOM has no rendering engine, hence the pseudo-browser environment.\n\nExample :\n\n```typescript\nimport { ensureNodeFromSelector, jsdomIt } from './tests/util.js';\n\njsdomIt('should add element \"thing\" in the SVG', ({ svg }) => {\n  // Code in this block runs in a pseudo-browser environment\n  addThing(svg); // The svg item is the D3 selection of the SVG node\n  const svgNode = ensureNodeFromSelector('svg'); // Retrieve the DOM node using the DOM API\n  expect(svgNode.querySelector('thing')).not.toBeNull(); // Test the structure of the SVG\n});\n```\n\nThey can be used to test any method that interacts with the DOM, including for testing renderers. For renderers, additional integration testing is necessary to test the layout though.\n\n#### Integration / End-to-End (E2E) Tests\n\nThese test the rendering and visual appearance of the diagrams.\n\nThis ensures that the rendering of that feature in the E2E will be reviewed in the release process going forward. Less chance that it breaks!\n\nTo start working with the E2E tests:\n\n**Host**\n\n- Run `pnpm dev` to start the dev server\n- Start **Cypress** by running `pnpm cypress:open`\n\n**Docker**\n\n- Enable local connections for x11 server `xhost +local:`\n- Run `./run pnpm dev` to start the dev server\n- Start **Cypress** by running `./run pnpm cypress:open --project .`\n\nThe rendering tests are very straightforward to create. There is a function `imgSnapshotTest`, which takes a diagram in text form and the mermaid options, and it renders that diagram in Cypress.\n\nWhen running in CI it will take a snapshot of the rendered diagram and compare it with the snapshot from last build and flag it for review if it differs. When the changes in PR only apply to specific diagrams, only the rendering tests for those diagrams will be run in CI. If a change is not related to a specific diagram, the full test-suite will be run.\n\nThis is what a rendering test looks like:\n\n```js\nit('should render forks and joins', () => {\n  imgSnapshotTest(\n    `\n    stateDiagram\n    state fork_state <<fork>>\n      [*] --> fork_state\n      fork_state --> State2\n      fork_state --> State3\n\n      state join_state <<join>>\n      State2 --> join_state\n      State3 --> join_state\n      join_state --> State4\n      State4 --> [*]\n    `,\n    { logLevel: 0 }\n  );\n});\n```\n\n\n\n\n### Update Documentation\n\n```tip\nOur documentation is managed in `packages/mermaid/src/docs`. Details on how to edit is in the [documentation section](#contributing-documentation)\n```\n\nIf the users have no way to know that things have changed, then you haven't really _fixed_ anything for the users; you've just added to making Mermaid feel broken.\nLikewise, if users don't know that there is a new feature that you've implemented, it will forever remain unknown and unused.\n\nThe documentation has to be updated for users to know that things have been changed and added!\nIf you are adding a new feature, add `(v+)` in the title or description. It will be replaced automatically with the current version number when the release happens.\n\neg: `# Feature Name (v+)`\n\nWe know it can sometimes be hard to code _and_ write user documentation.\n\nCreate another issue specifically for the documentation.\nYou will need to help with the PR, but definitely ask for help if you feel stuck.\nWhen it feels hard to write stuff out, explaining it to someone and having that person ask you clarifying questions can often be 80% of the work!\n\nWhen in doubt, write up and submit what you can. It can be clarified and refined later. (With documentation, something is better than nothing!)\n\n## Contributing Documentation\n\nIf it is not in the documentation, it's like it never happened. Wouldn't that be sad? With all the effort that was put into the feature?\n\n### Where is the Documentation Located?\n\n```warning\nDO NOT CHANGE FILES IN `/docs`\n\nThe `docs` folder will be automatically generated when committing to `packages/mermaid/src/docs` and **should not** be edited manually.\n```\n\nDocumentation is located in the [`packages/mermaid/src/docs`](https://github.com/mermaid-js/mermaid/tree/develop/packages/mermaid/src/docs) folder. Just pick the right section and start typing.\n\nThe contents of [mermaid.js.org](https://mermaid.js.org/) are based on the docs from the `master` branch. Updates committed to the `master` branch are reflected in the [Mermaid Docs](https://mermaid.js.org/) once published.\n\n```mermaid\nflowchart LR\n  classDef default fill:#fff,color:black,stroke:black\n\n  source[\"Edit /packages/mermaid/src/docs\"] -- automatic processing--> published[\"View /docs which will be published on Official Website\"]\n```\n\n### Running the Documentation Website Locally\n\n**[The mermaid documentation site](https://mermaid.js.org/) is powered by [Vitepress](https://vitepress.vuejs.org/).**\n\nStart development server for the documentation site\n\n**Host**\n\n```bash\npnpm --filter mermaid run docs:dev\n```\n\nor\n\n```bash\ncd packages/mermaid\npnpm docs:dev\n```\n\n**Docker**\n\n```bash\n./run docs:dev\n```\n\nOpen [http://localhost:3333/](http://localhost:3333/) in your browser.\n\n### Formatting\n\nThe documentation is written in Markdown. To get acquainted with its syntax [see the GitHub Markdown help page](https://help.github.com/en/github/writing-on-github/basic-writing-and-formatting-syntax).\n\nYou can use `note`, `tip`, `warning` and `danger` in triple backticks to add a note, tip, warning or danger box.\n\n```danger\nDo not use vitepress specific markdown syntax `::: warning` as it will not be processed correctly.\n```\n\nHere are a few examples:\n\n````markdown\n```note\nThis is a note\n```\n\n```tip\nThis is a tip\n```\n\n```warning\nThis is a warning\n```\n\n```danger\nThis is a danger alert\n```\n````\n\n```note\nThis is a note\n```\n\n```tip\nThis is a tip\n```\n\n```warning\nThis is a warning\n```\n\n```danger\nThis is a danger alert\n```\n\n### Navigation\n\nIf you want to propose changes to how the documentation is _organized_, such as adding a new section or re-arranging or renaming a section, you must update the **sidebar navigation**, which is defined in [the vitepress config](../.vitepress/config.ts). The same goes for **topbar**.\n\n### Build Docs\n\nThe content of `/docs` folder is built with GitHub Actions.\n\n```warning\nSo as to allow automatic compilation of documentation pages you have to enable GitHub Actions on your fork first\n```\n\n## Submit your pull request\n\n````note\nDo not forget to push your changes\n\n```bash\ngit push -u origin docs/2910_update-guidelines\n```\n````\n\nWe make all changes via Pull Requests (PRs). Open a new one.\n\nRight now we are not following any strict rules about naming PRs. Give it a representative title and short description. There is also a [pull request template](https://github.com/mermaid-js/mermaid/blob/develop/.github/pull_request_template.md) which will help you with it.\n\nIn case in its description contains a [magic comment](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) your PR will be automatically attached to the issue:\n\n```markdown\nResolves #\n```\n\n## Congratulations\n\nYou have successfully submitted your improvements! What is next?\n\n- PRs will be reviewed by active maintainers, who will provide feedback and request changes as needed.\n- The maintainers will request a review from _knsv_, if necessary.\n- Once the PR is approved, the maintainers will merge the PR into the `develop` branch.\n- When a release is ready, the `release/x.x.x` branch will be created, extensively tested and knsv will be in charge of the release process.\n\nThanks for you help!\n\n\n","isInternal":false,"tokens":4129,"sizeBytes":17186},{"name":"e2e-tests.md","path":"packages/mermaid/src/docs/community/e2e-tests.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/community/e2e-tests.md","title":"Community Skill","category":"anthropic-skill","format":"markdown","content":"# E2E Test Suite: Tiers, Folders, and CI\n\nThis is a contributor-facing manual for the `e2e/` test suite's tier structure — why it exists, how it's organized, which flags/labels control it, and how to work with it locally.\n\n## Why this exists\n\nBefore this restructuring, every PR ran the entire e2e suite — every diagram, every theme variant, every look/handdrawn combination — on every push. That's thorough, but it's expensive in two ways that scale badly as the suite grows:\n\n- **CI time.** A full run takes significantly longer than most PRs actually need. Most changes touch one diagram type; waiting on a full 8-shard run to validate a one-line fix is slow feedback for no real benefit.\n- **Argos quota.** Every full run captures and uploads a screenshot for every diagram fixture, whether or not that fixture has anything to do with the change under review. Visual-regression services bill (or rate-limit) by build/screenshot volume, so an oversized \"safety net\" run on every push burns through quota fast.\n\nThe fix is to split fixtures and specs into **tiers** — a small, fast, curated set that runs on every PR by default, and larger, slower sets reserved for less frequent, higher-confidence checks (nightly, and before a release-bound merge).\n\n**Measured impact** (from a real before/after comparison on this fork, on 2026-09-24 — pulled directly from GitHub Actions run history for PR #7; treat this as a dated example, not a live-updating stat):\n\n|                               | Full suite (pre-tiering) | `pr-check`-tier only |\n| ----------------------------- | ------------------------ | -------------------- |\n| Shards                        | 8                        | 2                    |\n| Per-shard time                | ~15–18 min               | ~6–8 min             |\n| Total wall-clock              | ~31 min                  | ~8 min               |\n| Total compute (shard-minutes) | ~128                     | ~14                  |\n\nRoughly a **4x reduction in wall-clock time** and **~90% less total CI compute** for the common case — a PR that only needs the `pr-check` tier to validate its change. That tracks with the underlying fixture split: as of 2026-09-24, `pr-check` covered about 15% of all `.mmd` fixtures (312 of 2,136 — `nightly-check` held 1,375, `visual-check` held 449). These counts will grow over time; the proportions are the durable part.\n\n## Directory layout\n\nTwo parallel trees hold the suite's content:\n\n```mermaid\nflowchart TD\n  subgraph diagrams[\"e2e/diagrams//\"]\n    direction LR\n    d_pr[\"pr-check/
*.mmd fixtures\"]\n    d_nightly[\"nightly-check/
*.mmd fixtures\"]\n    d_visual[\"visual-check/
*.mmd fixtures\"]\n  end\n  subgraph rendering[\"e2e/rendering//\"]\n    direction LR\n    r_pr[\"pr-check/
*.spec.ts\"]\n    r_nightly[\"nightly-check/
*.spec.ts\"]\n    r_visual[\"visual-check/
*.spec.ts\"]\n  end\n  runner[\"e2e/rendering/mmd-snapshots.spec.ts
(global fixture runner)\"]\n  diagrams -->|discovered & rendered by| runner\n```\n\n- **`e2e/diagrams///*.mmd`** — static Mermaid source fixtures. Each one is just a diagram (optionally with YAML frontmatter setting `config`/`title`/a `description`). They aren't run directly; a single global spec, `e2e/rendering/mmd-snapshots.spec.ts`, discovers every `.mmd` file under `e2e/diagrams/`, registers one Playwright test per fixture (grouped into `describe` blocks mirroring the folder path), and renders it. This is where the large majority of diagram-rendering coverage lives — no test-writing required, just add a `.mmd` file in the right tier folder.\n- **`e2e/rendering///*.spec.{js,ts}`** — hand-written Playwright specs, for anything a static fixture can't express: DOM/CSS assertions, `.click()` interactions, directive-vs-`initialize()` precedence checks, multi-diagram array tests, custom `mermaid.initialize()` config, and similar. If your test needs to assert on rendered output beyond \"did it render without erroring,\" it belongs here instead of as a fixture.\n- **`e2e/other//*.spec.{js,ts}`** — cross-cutting specs that aren't about any single diagram type (XSS/security tests, GHSA regression tests, `iife`/embed tests, page-interaction tests, external-diagram loading). Only `pr-check/` is populated today.\n- **`e2e/helpers/`** — shared test infrastructure: `util.ts` (the `imgSnapshotTest`/`renderGraph`/`verifyScreenshot` helpers every spec uses) and `mmd-snapshots.ts` (fixture discovery/metadata for the global runner).\n\nNot every `//` directory has content yet — some are intentionally empty, left in place as containers for tests that haven't been written. An empty tier folder isn't stray or safe to delete; it's scaffolding for the layout above, matching a diagram type or tier that's expected to gain coverage later.\n\n### The three tiers\n\n| Tier            | Intent                                                                                                                                                                     | Runs on                                                                                                                                         |\n| --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |\n| `pr-check`      | Small, curated, fast smoke set — one or two representative fixtures per feature, not an exhaustive sweep.                                                                  | Every PR (see below), plus a `develop` merge, plus every nightly run.                                                                           |\n| `nightly-check` | Bulk/comprehensive coverage — most of the fixture volume lives here.                                                                                                       | Once every 24h, plus a `master`-bound PR/merge (alongside `pr-check`).                                                                          |\n| `visual-check`  | Theme/look (`classic`/`neo`/`handDrawn`)/layout/direction combinatorial sweeps — the same diagram rendered across every variant. Pixel/appearance content, not parse-only. | Not part of any automated CI gate. Reviewed manually via Applitools as a release-process step (`e2e-applitools.yml`, `workflow_dispatch`-only). |\n\nA fixture or spec's tier is purely a function of which subfolder it lives in — there's no separate registry or config file to update.\n\nIf you're new to this structure, here's how to decide where a new test belongs:\n\n- **Adding a new diagram feature or syntax?** Add one small `pr-check` fixture covering the happy path — this is what every PR runs, so it catches an obvious regression immediately. If the feature has several meaningfully different shapes/variants/edge cases worth covering, add those as additional fixtures under `nightly-check` instead of piling them all into `pr-check` — `pr-check` is meant to stay small and fast, not become exhaustive.\n- **Fixing a rendering bug?** Add a `pr-check` fixture that reproduces the bug (the minimal diagram that triggered it), so this exact regression is caught on every future PR. Only drop it into `nightly-check` instead if it's a narrow, rarely-hit edge case where running it on every PR isn't worth the extra time.\n- **Backfilling broad coverage for something that already works** (e.g. every node-shape × edge-type combination, a sweep of config options)? That bulk volume belongs in `nightly-check` — it's comprehensive by design and only needs to run once a day, not on every push.\n- **Testing a purely visual/appearance difference** — how a diagram looks under a different theme, `handDrawn` look, layout direction, or similar, where the underlying structure/parsing is unaffected? That's `visual-check`. It's pixel/appearance content reviewed by a human via Applitools, not something an automated parse-only assertion can usefully judge.\n- **Does your test need to assert on something beyond \"did it render without erroring\"?** — a DOM/CSS assertion, a `.click()` interaction, directive-vs-`initialize()` precedence, a multi-diagram array, custom `mermaid.initialize()` config — that can't be expressed as a static `.mmd` fixture. Write a hand-written spec instead, under `e2e/rendering///*.spec.{js,ts}` if it's about one specific diagram type, or `e2e/other//*.spec.{js,ts}` if it's cross-cutting (security/XSS, embed/`iife`, page interactions, external-diagram loading, and similar). The same tier logic above still applies to these — a fast smoke-test spec goes in `pr-check`, a more exhaustive one in `nightly-check`.\n\nWhen in doubt, default to `pr-check` for anything a feature's author would want caught immediately, and move broader/slower coverage to `nightly-check`.\n\n## How CI decides what to run\n\n```mermaid\nflowchart TD\n  start{\"What triggered this run?\"}\n  start -->|\"PR → develop\"| pr_label{\"'run pr tests'
label set?\"}\n  start -->|\"PR → master\"| release_label{\"'run release test'
label set?\"}\n  start -->|\"Push to develop
(e.g. a PR merge)\"| push_develop[\"pr-check tier only\"]\n  start -->|\"Push to master\"| push_master[\"pr-check + nightly-check tiers\"]\n  start -->|\"Scheduled (daily) or
manual 'simulated nightly'\"| nightly_run[\"pr-check + nightly-check tiers\"]\n\n  pr_label -->|yes, or PR just opened| pr_scoped[\"pr-check tier only\"]\n  pr_label -->|no| blocked1[\"e2e skipped —
required check fails\"]\n\n  release_label -->|yes, or PR just opened| gated[\"pr-check + nightly-check tiers
(visual-check excluded — see Applitools)\"]\n  release_label -->|no| blocked2[\"e2e skipped —
required check fails\"]\n```\n\nBoth labels — `run pr tests` and `run release test` — default to **on**: a small automation job adds them to every freshly-opened PR (targeting `develop` and `master` respectively). Removing the label before a later push causes e2e to be skipped for that push, which is treated as a **failure** of the required status check (not a silent pass) — merging is still possible via a repo admin's branch-protection bypass, but it's not a default-open door.\n\nNote that `run release test` — despite its name — does **not** gate the `visual-check` tier. `visual-check` is theme/look/layout/direction combinatorial sweeps: pixel/appearance content that's better judged by a human during the manual Applitools pass (`e2e-applitools.yml`) than by an automated parse-only check here. The label name is a holdover from before this tier split; renaming it is tracked separately and out of scope for this doc.\n\nThis label-gating logic, and the nightly/scheduled workflow, are **upstream-only** — every branch of this logic is guarded by a check that it's running on `mermaid-js/mermaid`, not a fork. On a fork, e2e.yml falls back to its original full-suite/diff-based-scoping behavior, and the nightly workflow's own job is a no-op (there's no Argos project/credentials there to make screenshot capture worthwhile).\n\n## Flags and environment variables\n\n| Name                                        | Where                                           | Effect                                                                                                                                                                                                                  |\n| ------------------------------------------- | ----------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `MERMAID_E2E_FIXTURE_TIER`                  | env var, read by `mmd-snapshots.spec.ts`        | Comma-separated tier list (e.g. `pr-check`, or `pr-check,nightly-check`) that narrows which `.mmd` fixtures get registered. Unset = every tier.                                                                         |\n| `run pr tests`                              | GitHub PR label                                 | Gates whether a `develop`-bound PR's e2e run happens at all (scoped to `pr-check` tier when present). Defaults on for new PRs.                                                                                          |\n| `run release test`                          | GitHub PR label                                 | Same, for `master`-bound PRs (scoped to `pr-check`+`nightly-check` — `visual-check` excluded, see above). Defaults on for new PRs.                                                                                      |\n| `E2E_SCOPE_BY_DIAGRAM`                      | repo variable                                   | Kill-switch for the (separate, older) diagram-diff-based scoping used outside the tier-gating paths. Set to `'false'` to force the full suite unconditionally.                                                          |\n| `RUN_VISUAL_TEST`                           | computed CI env var                             | Controls whether screenshots get captured for Argos upload. Only ever true on the real upstream repo — never on this fork.                                                                                              |\n| `USE_APPLI`                                 | env var                                         | Switches screenshot verification to Applitools instead of the Argos/local-snapshot path. Common in personal dev shells — remember to override it (`USE_APPLI=`) when you specifically want the Argos code path locally. |\n| `SCREENSHOT_DIR`                            | env var                                         | Overrides where Argos-mode screenshots get written locally. Defaults to `e2e/screenshots`.                                                                                                                              |\n| `GROUP_ARGOS_IMAGES` / `group_argos_images` | computed CI env var / `workflow_dispatch` input | Whether screenshots get composited into per-folder \"sheets\" before Argos upload, versus uploaded individually.                                                                                                          |\n| `MERMAID_DEV_EXPLORER_ROOT`                 | env var, read by `.esbuild/server.ts`           | Which `.mmd` root the local Dev Explorer (`/dev` route) serves. Defaults to `e2e` (the whole tree — fixtures, platform diagrams, everything).                                                                           |\n| `MERMAID_PORT` / `MERMAID_DEV_PORT`         | env var                                         | Overrides the dev server port Playwright/the dev server use.                                                                                                                                                            |\n| `E2E_COVERAGE`                              | env var                                         | Switches the dev server to the coverage-instrumented build, and enables native V8 coverage collection during a Playwright run.                                                                                          |\n\n## Working with tiers locally\n\n**Run only the `pr-check` tier** (mirrors what a PR's CI actually runs):\n\n```bash\nMERMAID_E2E_FIXTURE_TIER=pr-check pnpm exec playwright test e2e/rendering/mmd-snapshots.spec.ts $(node scripts/e2e-tier-scope.mjs pr-check | tr ',' ' ')\n```\n\n**Run a \"simulated nightly\" (`pr-check`+`nightly-check`)** without waiting for the schedule:\n\n```bash\ngh workflow run \"Nightly E2E\" --repo mermaid-js/mermaid\n# or purely locally, no CI involved:\nMERMAID_E2E_FIXTURE_TIER=pr-check,nightly-check pnpm exec playwright test e2e/rendering/mmd-snapshots.spec.ts $(node scripts/e2e-tier-scope.mjs pr-check nightly-check | tr ',' ' ')\n```\n\n**See what a fixture would look like in Argos**, without needing real Argos credentials or touching any baseline: capture screenshots locally with `RUN_VISUAL_TEST=true` (remembering to clear `USE_APPLI` if it's set in your shell), then either browse `e2e/screenshots/` directly, or run `pnpm run screenshots:sheets` to composite them the same way CI does before upload.\n\n**Run a release test against Applitools**: start the local dev server first (`pnpm dev`, in its own terminal) — the suite is large enough that it's worth having it already warm rather than waiting on Playwright's own `webServer` auto-start/cold build on the first request. Neither of these is something you'd run as part of routine local development — they're only used when preparing a release:\n\n```bash\n# Core release check: pr-check + nightly-check tiers, against the \"release-baseline\" Applitools branch.\npnpm playwright:release-test\n\n# Extended release check: the visual-check tier (theme/look/layout combinatorial sweeps),\n# against its own separate \"release-baseline-extended\" Applitools branch.\npnpm playwright:release-test:extended\n```\n\nBoth scripts set `USE_APPLI=true`, so every screenshot is verified against Applitools instead of the Argos/local-snapshot path, and both pin `APPLITOOLS_BRANCH` to a fixed, long-lived branch name rather than letting the SDK derive one from the current git branch — so re-running either script, from whatever branch you're on, keeps comparing against the same accumulated baseline. The two scripts use separate baseline branches deliberately: the core and extended checks differ enough in scope and cadence that mixing both into one branch would make the Applitools review history harder to read.\n\n## Diagrams and screenshots\n\nThe Dev Explorer (`/dev` route) — browse `.mmd` fixtures under the configured `MERMAID_DEV_EXPLORER_ROOT` and preview them rendered:\n\n![Dev Explorer root view, showing the top-level e2e folder listing](img/dev-explorer.png)\n\n> 📸 **Placeholder — add screenshots here:**\n>\n> - The GitHub PR \"Checks\" tab, side by side: a `develop`-bound PR showing the scoped 2-shard `pr-check`-tier run, versus a `master`-bound PR showing the scoped 4-shard `pr-check`+`nightly-check` run (`visual-check` excluded).\n> - The \"Nightly E2E\" entry in the Actions tab, filtered, showing a recent scheduled run's result.\n\nThe flowcharts above (directory layout, CI decision flow) are Mermaid diagrams — edit them the same way you'd edit any diagram in this repo. If you add more diagrams to this doc, prefer Mermaid over static images where the content is structural/flow-based (it stays accurate as the suite evolves, and — fittingly for this repo — is easy for any contributor to update in a plain-text diff).\n","isInternal":false,"tokens":3939,"sizeBytes":18835},{"name":"intro.md","path":"packages/mermaid/src/docs/community/intro.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/community/intro.md","title":"Community Skill","category":"anthropic-skill","format":"markdown","content":"# Getting Started\n\nSo you want to help? That's great!\n\n![Image of happy people jumping with excitement](https://media.giphy.com/media/BlVnrxJgTGsUw/giphy.gif)\n\nHere are a few things to get you started on the right path.\n\n## How can I help?\n\n```mermaid-nocode\nmindmap\n  root)Contributing(\n    Development\n      Solving issues\n      Adding new diagrams\n      Handling pull requests\n      Updating tooling\n    Testing\n      Verification of fixed issues\n      Regression testing in connection with releases\n      Testing pull requests\n    Management\n      Coordinating the work\n      Classification and monitoring of incoming issues\n```\n\n## Join the Development\n\n```tip\n**Check out our** [**detailed contribution guide**](./contributing.md).\n```\n\nWhere to start:\n\n- You could start getting some knowledge of the code base by working on [these \"good first issues\"](https://github.com/mermaid-js/mermaid/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3A%22Good+first+issue%21%22+).\n- You could jump right in and help us fix any of [these bugs](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Type%3A+Bug+%2F+Error%22++label%3A%22Contributor+needed%22+)!\n- You could help write and [improve the documentation](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Area%3A+Documentation%22).\n- You could work on a new feature! [These](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Area%3A+Development%22+label%3A%22Type%3A+Enhancement%22+label%3A%22Status%3A+Approved%22+) are some ideas!\n- You could confirm the bugs in [these issues](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Status%3A+Triage%22++label%3A%22Type%3A+Bug+%2F+Error%22).\n\n[You can join our Discord server if you want closer contact!](https://discord.gg/sKeNQX4Wtj)\n\n## A Question Or a Suggestion?\n\n```tip\n**Have a look at** [**how to open an issue**](./questions-and-suggestions.md).\n```\n\nIf you have faced a vulnerability [report it to us](./security.md).\n\n## Last Words\n\nDon't get daunted if it is hard in the beginning. We have a great community with only encouraging words. So, if you get stuck, ask for help and hints in the Slack forum. If you want to show off something good, show it off there.\n\n[You can join our Discord server if you want closer contact!](https://discord.gg/sKeNQX4Wtj)\n\n![Image of superhero wishing you good luck](https://media.giphy.com/media/l49JHz7kJvl6MCj3G/giphy.gif)\n","isInternal":false,"tokens":734,"sizeBytes":2488},{"name":"layout-makers-guide.md","path":"packages/mermaid/src/docs/community/layout-makers-guide.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/community/layout-makers-guide.md","title":"Community Skill","category":"anthropic-skill","format":"markdown","content":"# The Layout Maker's Guide 🗺️\n\nA layout algorithm decides where nodes sit and how edges get from one to the next. Shapes, themes, markers, and labels are already handled by the shared rendering code.\n\nWhich means you never touch the DOM. You are handed a graph whose nodes already know how big they are, and you hand back numbers: a center point for every node, a list of points for every edge. Drawing the shapes, painting the strokes, placing the arrowheads, fitting the viewBox — all of that is somebody else's code working from your numbers. You are solving a geometry problem, not a rendering one, which is exactly why a layout can be tested without a browser.\n\nThis guide covers layouts that live inside the Mermaid package, next to `dagre` and the others. The last section explains how to ship the same code as a standalone npm package instead.\n\nTwo layouts in the tree are worth reading alongside it. `dagre` is the default and the oldest. `swimlanes` is the newest, and it is the one that follows the conventions described here, so most of the examples point at it.\n\n## What a layout receives and what it must produce\n\nEvery layout is handed the same structure, `LayoutData`, regardless of which diagram type produced it:\n\n```ts\ninterface LayoutData {\n  nodes: Node[];\n  edges: Edge[];\n  config: MermaidConfig;\n  diagramId?: string;\n}\n```\n\n`runLayoutCore`, the stage that holds your algorithm, writes these fields and no others:\n\n| Field                       | On   | Meaning                                                                    |\n| --------------------------- | ---- | -------------------------------------------------------------------------- |\n| `node.x`, `node.y`          | Node | Center of the node, in layout space                                        |\n| `node.width`, `node.height` | Node | Arrive measured for leaf nodes — leave those alone; you set them on groups |\n| `edge.points`               | Edge | Polyline from source boundary to target boundary, at least 2 points        |\n| `edge.x`, `edge.y`          | Edge | Anchor for the edge label, when the edge has one                           |\n\nOne stage is allowed to do more. `prepareLayout` runs before measurement and may rebuild the graph — replace `data4Layout.nodes` and `data4Layout.edges`, add the synthetic nodes an edge label needs, drop what your algorithm handles another way. \"These fields and no others\" is a rule about `runLayoutCore`, where the graph is settled and only geometry moves.\n\n### Layout space\n\nPositions are centers. `node.x, node.y` is the middle of the node's box, so its left edge is `x - width / 2` and its top edge is `y - height / 2`. Layout libraries disagree about this — some report a node's top-left corner, some measure y upward from a bottom-left origin — so if you are wrapping one, convert its output in `runLayoutCore` rather than leaving the renderer to guess. Dagre and ELK both report centers, which is why the built-in layouts pass them straight through.\n\nBeyond that, layout space is a plain plane: x grows to the right, y grows downward. There is no fixed origin and no requirement that coordinates be positive. The renderer takes the bounding box of everything you produced and translates it into the SVG viewBox, so a layout centered on (0, 0) and a layout starting at (0, 0) render identically. Do not spend a pass normalizing coordinates; it is undone immediately.\n\n`Node` and `Edge` carry a good deal more than this, all of it defined in `rendering-util/types.ts`. Read the types there rather than working from what a debugger happens to show you: shape, label geometry, styling, and port information all travel on the same objects, and most of it belongs to the renderer rather than to you.\n\nTwo structural fields are your input, not your output. `node.isGroup` marks a subgraph container, and `node.parentId` names the group a node belongs to. Read them, never rewrite them.\n\nLeaf sizes arrive already measured, and they are not yours to compute. The renderer inserts every leaf node into the SVG, calls `getBBox()`, and writes `width` and `height` back before your algorithm runs, so a leaf whose size you recalculate or overwrite will have its label spill out of its shape at render time. Read them; treat them as fixed.\n\nGroups are the exception, and the only place you do set a size. A group's extent is a consequence of where you put its children, so nothing can measure it up front — every node with `isGroup` set needs a `width` and `height` from you, big enough to enclose its members and the title band. See [Groups](#groups).\n\nThat one measuring pass is the only step in the whole pipeline that touches the DOM, which is what makes everything after it testable in Node.\n\n## The five stages\n\nLayouts are built by calling `createCommonLayoutRenderer` from `rendering-util/layout-algorithms/common/index.ts`. It gives you five hooks, runs them in order, and handles painting:\n\n```ts\nexport const render = createCommonLayoutRenderer({\n  prepareLayout, // reshape LayoutData before measuring\n  measureLayout, // DOM: insert elements, read sizes (has a default)\n  runLayoutCore, // your algorithm, no DOM allowed\n  paintLayout, // escape hatch: take over painting entirely\n  afterPaint, // touch up after paths exist\n  paintOptions, // tweak the standard painter\n});\n```\n\nOnly `runLayoutCore` is required. The swimlanes layout is a complete example in twenty lines:\n\n```ts\nimport { createCommonLayoutRenderer } from '../common/index.js';\nimport { applySwimlaneLineJumps } from './adjustLayout.js';\nimport { prepareLayoutForSwimlanes } from './helpers.js';\nimport { createEdgeLabelNodes } from './edgeLabelNodes.js';\nimport { runSwimlaneLayoutCore } from './layoutCore.js';\n\nfunction prepareSwimlaneLayout(data4Layout: LayoutData): void {\n  prepareLayoutForSwimlanes(data4Layout);\n\n  const transformedData = createEdgeLabelNodes(data4Layout);\n  data4Layout.nodes = transformedData.nodes;\n  data4Layout.edges = transformedData.edges;\n}\n\nexport const render = createCommonLayoutRenderer({\n  prepareLayout: prepareSwimlaneLayout,\n  runLayoutCore: runSwimlaneLayoutCore,\n  afterPaint: applySwimlaneLineJumps,\n});\n```\n\n### Keep the core free of the DOM\n\n`runLayoutCore` must be a pure function of `LayoutData`. No `document`, no `getBBox`, no d3 selections.\n\nThe reason is testing. Node sizes get measured in a browser once and saved to a file. A test then loads those sizes, hands them to `runLayoutCore`, and gets back the same coordinates the browser would have produced, without opening a browser at all. That only holds while the core stays free of the DOM. The moment it reaches for `document`, it can only run inside a real page, and any test around it is exercising a different code path than the one your users hit.\n\nSo write the core as one exported function, and have both the browser and your tests call that same function.\n\n## A minimal layout\n\nThe examples from here on build a layout called `grid`. No such layout ships with Mermaid. It stands in for whatever you are writing, and the code below is what you would write to create it.\n\nPut the algorithm in `packages/mermaid/src/rendering-util/layout-algorithms//`. This one arranges leaf nodes in a grid and connects them with straight lines:\n\n```ts\n// layout-algorithms/grid/layoutCore.ts\nimport type { LayoutData } from '../../types.js';\n\nconst GAP = 60;\n\n/** DOM-free: positions come from measured sizes only. */\nexport function runGridLayoutCore(data4Layout: LayoutData): void {\n  const leaves = data4Layout.nodes.filter((node) => !node.isGroup);\n  const columns = Math.ceil(Math.sqrt(leaves.length));\n  const cell = Math.max(...leaves.map((n) => Math.max(n.width ?? 0, n.height ?? 0))) + GAP;\n\n  leaves.forEach((node, i) => {\n    node.x = (i % columns) * cell;\n    node.y = Math.floor(i / columns) * cell;\n  });\n\n  const byId = new Map(data4Layout.nodes.map((node) => [node.id, node]));\n  for (const edge of data4Layout.edges) {\n    const from = byId.get(edge.start ?? '');\n    const to = byId.get(edge.end ?? '');\n    if (!from || !to) {\n      continue;\n    }\n    edge.points = [\n      { x: from.x ?? 0, y: from.y ?? 0 },\n      { x: to.x ?? 0, y: to.y ?? 0 },\n    ];\n  }\n}\n```\n\n```ts\n// layout-algorithms/grid/index.ts\nimport { createCommonLayoutRenderer } from '../common/index.js';\nimport { runGridLayoutCore } from './layoutCore.js';\n\nexport const render = createCommonLayoutRenderer({ runLayoutCore: runGridLayoutCore });\n```\n\nThat renders. It is also wrong in most of the ways a layout can be wrong.\n\n## Registering the layout\n\nThe layouts that ship with Mermaid are listed in `registerDefaultLayoutLoaders()` in `packages/mermaid/src/rendering-util/render.ts`. Add one entry for yours:\n\n```ts\nregisterLayoutLoaders([\n  { name: 'dagre', loader: async () => await import('./layout-algorithms/dagre/index.js') },\n  { name: 'swimlane', loader: async () => await import('./layout-algorithms/swimlanes/index.js') },\n  // your new layout\n  { name: 'grid', loader: async () => await import('./layout-algorithms/grid/index.js') },\n]);\n```\n\nThe loader is lazy, so the code only downloads when a diagram asks for it. `cose-bilkent` is registered the same way but wrapped in a check on `includeLargeFeatures`, which is how a layout stays out of the tiny build. Users then select the layout by the name you registered:\n\n```text\n---\nconfig:\n  layout: grid\n---\nflowchart TB\n  A --> B\n```\n\n## Groups, labels, and edges\n\n### Groups\n\nA group node carries `isGroup: true`, and its members carry `parentId` pointing at it. Groups nest. Your algorithm owns the group's `x`, `y`, `width`, and `height`, and the frame must enclose every descendant with room for the title. Groups also have an optional `groupTitleRect` describing the header band. Edges routed through that band collide with the title text.\n\nThe standard painter draws a group as a cluster and everything else as a node. Override that with `paintOptions.isCluster` when your layout has its own idea of which nodes are containers.\n\n### Edge labels\n\nLabels need space reserved before positions are decided, otherwise they land on top of edges and nodes. The approach that works is to split each labelled edge into `start → label → end` around a temporary node, let the algorithm place that node like any other, then fold it back into an overlay label. Swimlanes does this in `createEdgeLabelNodes`, called from its `prepareLayout` hook so the dummy node is measured as real text along with everything else.\n\nInvent a third mechanism and your labels will not be checked by the validator, because the validator reads the label geometry this pattern produces.\n\n### Edge endpoints and markers\n\nEdge paths must start and end on the boundary of their nodes, not at the center and not floating in space. By default the painter recomputes the endpoint by intersecting the path with the node shape, which will quietly bend the last segment of a carefully routed edge. Layouts that route to exact ports should turn that off with `paintOptions.skipIntersect`.\n\nArrowheads occupy roughly the last ten pixels of the final segment. A bend inside that stretch puts a corner underneath the arrowhead, and the validator calls it: the constant is `EPS_FINAL_APPROACH`, and it is 10.\n\n### Self-loops and parallel edges\n\nAn edge with `start === end` has no direction to follow and needs its own route, usually a small rectangle off one side of the node. Parallel edges between the same pair need to be separated by hand, or they render as one line. Fixtures for both live in `e2e/platform/dev-diagrams/layout-tests/` as `self-loop.mmd`, `self-loop-2.mmd`, `self-loop-multi.mmd`, and `identical-edges.mmd`.\n\n## Validating the result\n\n`validateLayout` in `layout-algorithms/layout-utils/validateLayout.ts` is the shared judge of layout quality. It takes finished `LayoutData` and returns a verdict plus a score:\n\n```ts\nimport { validateLayout } from '../layout-utils/validateLayout.js';\n\nconst result = validateLayout(layout);\n// result.ok        → boolean, false when any hard constraint is broken\n// result.issues    → what broke, with node/edge ids and details\n// result.score     → 0 to 1000; exactly 0 whenever ok is false\n// result.breakdown → crossings, per-edge bend penalties, point histogram\n```\n\n### Hard constraints\n\n`ok` is false if any issue is present, and the score drops to zero. These are the failures worth knowing about before you write your router:\n\n| Issue                                                           | What it means                                         |\n| --------------------------------------------------------------- | ----------------------------------------------------- |\n| `node-overlap`                                                  | Two nodes occupy the same space                       |\n| `edge-intersects-node`, `edge-intersects-obstacle`              | A path crosses a node it does not connect to          |\n| `edge-intersects-group-title`                                   | A path runs through a subgraph's title band           |\n| `edge-endpoint-detached-from-node`, `edge-endpoint-inside-node` | An endpoint misses the boundary                       |\n| `edge-non-orthogonal`                                           | A segment is neither horizontal nor vertical          |\n| `edge-missing-points`                                           | Fewer than two points on an edge                      |\n| `edge-shared-subpath`, `edge-parallel-segment-too-close`        | Two edges overlap or run too close to tell apart      |\n| `edge-shared-attachment-point`, `edge-same-port-departure`      | Two edges leave a node from the same spot             |\n| `edge-bend-near-endpoint`, `edge-bend-overlaps-arrowhead`       | A corner sits under the arrowhead or against the node |\n| `edge-border-hugging`, `node-border-hugging`                    | Geometry runs along a border instead of clear of it   |\n| `edge-label-overlaps-node`, `edge-label-overlaps-foreign-edge`  | A label lands on top of something else                |\n| `edge-label-off-edge`                                           | A label sits away from the edge it belongs to         |\n\nThe tolerances are named constants at the top of `validateLayout.ts`, and two of them explain most first-time surprises: `EPS_FINAL_APPROACH` is 10, the stretch near an endpoint where a bend is not allowed, and `EPS_SHARED_ATTACH` is 3, how close two edges may attach to the same node before they count as sharing a point. The tests assert relative ordering rather than exact magnitudes, so treat the numbers as current rather than fixed.\n\nSome checks assume orthogonal routing. A layout with curved or diagonal edges will trip `edge-non-orthogonal` on every edge, so either route orthogonally or work out which subset of the validator applies to you before treating its score as a target.\n\n### The score\n\nWhen `ok` is true the score starts at 1000 and comes down. Bends are counted per edge from the polyline point count, and crossings are counted once globally:\n\n| Polyline points | Bends | Penalty             |\n| --------------- | ----- | ------------------- |\n| 2               | 0     | 0                   |\n| 3               | 1     | 0                   |\n| 4               | 2     | 5                   |\n| 5               | 3     | 12                  |\n| 6               | 4     | 30                  |\n| 7 or more       | 5+    | 30 × 2^(points − 6) |\n\nEach crossing costs 3. The curve is deliberately steep at the top end: one seven-bend edge costs more than twenty crossings, because a path nobody can follow is worse than a tidy diagram with intersections.\n\nThe score does not scale with diagram size. A small graph reaches 1000; a large one rarely will, so compare a fixture against its own history rather than against another fixture.\n\n`result.breakdown.edges` is sorted worst-first, which makes it the fastest way to find what is dragging a layout down.\n\n### One thing that looks useful and is not\n\n`layout-utils` also holds `scoreLayout`, which computes softer metrics: aspect ratio, average bends per edge, rank faithfulness, neighborhood preservation, straight-edge ratio. Sitting next to `validateLayout`, it looks like the quality half of a matched pair.\n\nIt is not wired into anything. Nothing in the layout pipeline calls it, no fixture spec calls it, and its only caller is its own unit test. Its `symmetryScore` is an unfinished placeholder that always returns `NaN`. Treat `validateLayout` as the only judge, and leave `scoreLayout` alone unless you are deliberately picking up that unfinished work.\n\nA third level is planned and not built. `compareLayoutSnapshot()` would diff a layout's structure against a stored baseline to catch regressions that stay inside the validator's tolerances. There is no such function today, so nothing depends on it.\n\n## Testing with DDLT\n\nDOM-Decoupled Layout Testing runs your algorithm in Node against sizes captured once from a real browser. Tests come back in seconds and give the same answer every time, and because the browser and the tests call the same core function, a fix in one is a fix in the other.\n\n### Tests must run the browser's code path\n\nThe model is `parse → measure → run layout → paint`, and the third step has to be a single function. Tests swap out the measuring; the browser does it for real. What runs in between must be identical.\n\nThat sounds obvious, and it is where this gets broken most often. A test-only layout entry point sitting alongside the browser's is a bug even when the two look like they do the same thing. This has bitten this repo more than once, and the shape is always the same. The browser entry wrapped the edge pipeline in a degeneracy check and a direction-violation check, with a fallback and a reroute branch hanging off them. The test backend called the pipeline directly and skipped all of that. Fixtures came back valid, the browser took the fallback, and the fallback drew a polyline straight through the interior of a node. The validator would have caught it. The test harness never saw it.\n\nSo when you wire up a test backend, find the function the browser actually calls and trace it end to end. If it needs the DOM, lift its DOM-free body into a helper and call that helper from both sides rather than reimplementing the sequence. Never point the test at a primitive that the browser wraps in checks, fallbacks, mirror branches, or second passes: the test has to include all of it.\n\nThere is a cheap way to prove the seam is real. Change the browser orchestration, add a fallback or switch a default, and the test result for the same fixture should move. If it does not, the test is running around your change. Fix the seam rather than relaxing the test.\n\nWhen a fixture passes in Node but looks broken on screen, run `validateLayout` on both, on the same fixture, and compare the issues. Different issues mean different pipelines. Put the two call chains side by side, look for pre-passes, the main call, and post-passes, and the first place they diverge is the seam.\n\n### Fixtures\n\nA fixture is a pair of files under `e2e/platform/dev-diagrams/layout-tests/`:\n\n```text\nlayout-tests/\n  simple-graph.mmd          ← real Mermaid source, parsed by the real parser\n  simple-graph.sizes.json   ← node dimensions captured from a browser render\n  ddlt-manifest.json        ← per-fixture overrides\n```\n\nThe `.mmd` file goes through the actual parser, so fixtures exercise the same `LayoutData` a user's diagram produces. The `.sizes.json` file holds one entry per leaf node and one per edge label, plus freshness metadata:\n\n```json\n{\n  \"metadata\": {\n    \"captureVersion\": 1,\n    \"sourceSha256\": \"…\",\n    \"capturedAt\": \"2026-02-09T10:00:00Z\",\n    \"capturedFrom\": \"theme=default&look=classic\"\n  },\n  \"nodes\": [{ \"id\": \"A\", \"width\": 62, \"height\": 39 }]\n}\n```\n\n`sourceSha256` is a hash of the `.mmd` file. Edit the diagram without recapturing and the test fails with a stale-fixture error instead of silently laying out with wrong sizes.\n\n`ddlt-manifest.json` gives a fixture a profile, which decides the backend it runs through, and can mark it `allowLevel1Failure` when a known failure is tracked in its own dedicated spec.\n\n### Capturing sizes\n\nThere is a button for this. Start the dev server with `pnpm dev`, open the explorer at `/dev/`, and pick your diagram out of the file tree, which is rooted at the same `dev-diagrams` folder the fixtures live in. Switch to the Code tab and click **Save sizes**, sitting next to Save.\n\nIt does the whole job. Unsaved edits to the diagram are written first, the diagram re-renders with size capture switched on, and the measurements go to `.sizes.json` beside the `.mmd`. The hash and the capture version are filled in for you, so the fixture passes the freshness check the moment it lands.\n\nThe button is only enabled for layouts that can produce capture data, and it explains itself through a tooltip when it is greyed out.\n\nIf you need to capture from somewhere other than the explorer, the same machinery is reachable from the console:\n\n```js\nwindow.mermaidCaptureSizes = true;\n// render the diagram, then:\ncopy(JSON.stringify(window.mermaidLastCapturedSizes.sizes, null, 2));\n```\n\nWritten by hand this way, the metadata block is yours to fill in. The capture module is dynamically imported only when that flag is set, so it never reaches a production bundle either way.\n\nRecapture when the diagram source changes or when a shape's real dimensions change. Do not recapture to make a failing test pass. The fixture is the before-picture, and rewriting it erases the regression you were trying to catch.\n\n### Parse the diagram, do not hand-build the graph\n\nIt is tempting to skip the parser and write the `LayoutData` for a test by hand. Resist it. Hand-built graphs drift from what the parser emits, usually in the identifiers, and once the ids differ the test is scoring a graph the browser never lays out.\n\nThe ids follow rules worth knowing, because fixture entries are matched against them:\n\n| Entity            | Id                                                                 |\n| ----------------- | ------------------------------------------------------------------ |\n| Content node      | The unquoted name from the diagram source, such as `A` or `E`      |\n| Unquoted subgraph | The subgraph text, kept as written                                 |\n| Quoted subgraph   | `subGraph`, numbered by a counter that ticks on every subgraph  |\n| Edge              | `L___`, the counter separating parallel edges |\n| Edge label node   | `edge-label---`                                |\n\nThe harness does the parsing for you. `parseMmdFileToLayoutData` strips frontmatter and directives, runs the real detector and parser, and stamps the direction the way the flowchart renderer does. `parseApplySizesAndLayout` goes further and applies the captured sizes and runs a backend. Reach for those before writing your own.\n\nIf you do drive the parser yourself, two calls come first: `addDiagrams()` to register the diagram types, and `preprocessDiagram()` to handle frontmatter before `Diagram.fromText()` sees it. Skipping either produces failures that look like parser bugs and are not.\n\nWhichever route you take, fail loudly when a fixture entry has no matching parser-produced node. A silent miss leaves a node at its default size, and the layout you then measure is not the layout anyone will see.\n\n### Writing a spec\n\nLoad the fixture, run your backend, assert on the result:\n\n```ts\nimport { describe, it, expect, beforeAll } from 'vitest';\nimport { loadDdltFixture } from '../ddlt/index.js';\nimport { validateLayout } from '../layout-utils/validateLayout.js';\n\ndescribe('swimlanes, 1-simple', () => {\n  let layout: LayoutData;\n  beforeAll(async () => {\n    layout = await loadDdltFixture('swimlanes/1-simple', { backendId: 'swimlanes' });\n  });\n\n  it('produces a valid layout', () => {\n    const result = validateLayout(layout);\n    expect(result.issues.map((i) => i.type)).toEqual([]);\n    expect(result.score).toBeGreaterThan(900);\n  });\n});\n```\n\nPass `backendId` explicitly. The default is a backend that is not present on `develop`, so a call without it throws rather than silently doing something reasonable. Your own layout needs an entry in `ddlt/backends.ts` before a fixture can run through it.\n\n`ddlt/index.ts` also exports `baselineDdltSpec(name)`, a one-liner that asserts the universal invariants: finite coordinates, at least two points per edge, no segment through an unrelated node, endpoints on boundaries. It hardcodes the same absent default backend and has no callers, so read it for the invariants it checks rather than calling it as it stands.\n\nThree shapes of test cover most needs. A tiny inline geometry test, where you build a handful of nodes by hand and check one routing rule, is right for a unit of the algorithm. A fixture-backed test on realistic sizes is right for a regression you can point at. A full source-to-layout run through the parser is right for anything a user reported. Match the surrounding folder: `swimlanes/query-process.ddlt.spec.ts` is the fullest worked example in the tree, and `layout-utils/validateLayout.spec.ts` and `ddlt/aggregateValidate.spec.ts` show the smaller shapes.\n\n### The sweep\n\n`ddlt/layout-fixtures.ddlt.spec.ts` discovers fixture pairs, runs them, and asserts validity across the board. It also emits an aggregate report, the number that tells you whether a change helped overall rather than on the one diagram you were staring at:\n\n```bash\n# The sweep, with the aggregate report\npnpm exec vitest run \\\n  packages/mermaid/src/rendering-util/layout-algorithms/ddlt/layout-fixtures.ddlt.spec.ts\n\n# Just the aggregate line\npnpm exec vitest run \\\n  packages/mermaid/src/rendering-util/layout-algorithms/ddlt/layout-fixtures.ddlt.spec.ts \\\n  2>&1 | grep 'DDLT-AGG'\n\n# One fixture while iterating\npnpm exec vitest run -t \"1-simple\" \\\n  packages/mermaid/src/rendering-util/layout-algorithms/ddlt/\n```\n\nThe report gives `total`, `avg`, `min`, and `invalid`, then one row per fixture with its score and issue types. Read it as a work queue: the lowest row is where the next improvement is. `ORTHO_TEST_DEBUG=1` in front of the command turns the layout logger from `fatal` up to `debug`, which helps when a row fails for reasons the report does not explain.\n\nThe sweep as written filters to the `swimlanes` profile and holds that profile's total against a floor. Adding a layout means adding its profile to the manifest and its own aggregate assertion, not assuming the existing one will pick your fixtures up.\n\n## The cases that break layouts\n\nA layout that handles a chain of boxes tells you almost nothing. The cases below are where engines actually fail, roughly in the order yours will fail them. Every one has a diagram in `layout-tests` already, so there is nothing to write before you can find out.\n\nMost of them are source only. The folder holds around 45 diagrams and about 15 have captured sizes, and the sweep discovers fixtures by looking for `.sizes.json` files and pairing each with its sibling `.mmd`. A diagram with no sizes file is not being tested by anything, however tricky it looks. Check before assuming a case is covered, and if the sizes are missing, open the diagram in the explorer and press Save sizes. That one click is the difference between a diagram sitting in a folder and a case the sweep will defend.\n\n### Self-loops\n\nAn edge whose source and target are the same node has no direction to travel in, and code that computes a route from two distinct positions tends to produce a zero-length path, a division by zero, or a dot. The route has to be manufactured: a small loop off one side, clear of the node and of anything the node's other edges are doing.\n\n`self-loop.mmd` is the single-node case, and the only one of the three with sizes captured. `self-loop-2.mmd` and `self-loop-multi.mmd` are harsher, putting a self-loop on all four nodes of a cycle, so every loop competes for space with real edges already using those sides.\n\n### Subgraphs\n\nThis is the long tail, and it is where most of the work is. A subgraph is a node that contains other nodes, so every edge endpoint now has two possible meanings and every frame is an obstacle that also has to move as its contents move.\n\n| Case                                  | Fixture                                                   |\n| ------------------------------------- | --------------------------------------------------------- |\n| A subgraph standing on its own        | `decoupled-subgraph.mmd`                                  |\n| Edge into a subgraph                  | `edge-to-subgraph.mmd`                                    |\n| Edge into a node inside a subgraph    | `edge-to-node-in-subgraph.mmd`                            |\n| Edge out of a subgraph                | `edge-from-subgraph.mmd`                                  |\n| Edge from inside out to a plain node  | `subgraph-variation.mmd`, `subgraph-variation-2.mmd`      |\n| Between two sibling subgraphs         | `nested-sg-outgoing-2.mmd`, `nested-incoming.mmd`         |\n| Inside one subgraph to inside another | `nested-sg-outgoing-2.mmd`, `nested-subgraphs-2.mmd`      |\n| Nested subgraphs                      | `nested-subgraphs.mmd`, `nested-subgraphs-3.mmd`          |\n| Edges crossing several nesting levels | `nested-sb-edges-in-out.mmd`, `nested-outgoing-edges.mmd` |\n| Subgraph titles competing for space   | `subgraph-labels.mmd` and its two variants                |\n\nWork down that list in order. Each row assumes the ones above it. Only the first two rows have captured sizes today, so everything below them is a diagram you can open in the browser rather than a test that will tell you when you break it.\n\nTwo failures recur. An edge that ends on a subgraph should stop at the frame rather than diving through to a member, and an edge that ends on a member has to cross the frame without clipping the title band. The other is sizing: a frame has to enclose everything inside it including the labels, and it has to keep doing so after a later pass nudges a member.\n\n### Parallel edges\n\nTwo edges between the same pair of nodes are one edge as far as most routing code is concerned, because both get the same endpoints and the same optimal path, so they land exactly on top of each other and the diagram silently loses information. They have to be separated deliberately.\n\n`identical-edges.mmd` is the minimal case. `multiple-edges.mmd` adds a reverse edge to the bundle, so the fix cannot just fan edges out by index and ignore direction. `identical-edges-in-subgraph.mmd` puts a bundle in each direction inside a frame, where the room to fan out is bounded.\n\n### Busy nodes\n\nA node with more than four edges cannot give each one its own side. Ports have to share sides, share sides in an order that does not cross, and stay far enough apart to be told apart. Engines that assign one edge per side degrade sharply here, usually into a knot right against the node.\n\n`edge-types.mmd` piles several edges onto a single node with a different arrow type on each. `Company.mmd` and `Company-simp.mmd` are the realistic version of the same problem, and both have sizes captured.\n\n### Combinations, and both directions\n\nThese interact, and the combinations are worse than the parts. A self-loop on a busy node inside a nested subgraph exercises all four at once, which is why the larger fixtures are worth keeping even though a failure in one is harder to diagnose. `deploy-pipeline.mmd`, `life-choices.mmd`, and `project-sox2.mmd` are the closest thing here to diagrams a user would actually write.\n\nRun the ones that matter in `TB` and `LR` both. Layout code tends to grow an implicit assumption about which way the graph flows, and the second direction is where that assumption surfaces.\n\n## Before you invent something\n\nGraph drawing has a long research record, and most of what a layout engine needs has been studied for decades. Orthogonal routing, compaction, port and side constraints, layered pipelines, crossing minimisation: none of these are new problems, and reading up on one is usually faster than deriving a heuristic and discovering its failure modes one fixture at a time.\n\nThe vocabulary gap is worth knowing about, because it makes searching harder than it needs to be. What this codebase calls a jog, the literature calls a bend. A port window is a pin or a side constraint. A rail is a track or a channel. A group is a compound vertex.\n\nWhen you knowingly diverge from what the established approach recommends, write down why in the pull request, along with how you checked that the divergence works.\n\n## Watching it in the browser while the tests run\n\nThe sweep tells you a score dropped. It does not tell you the diagram now looks like a plate of spaghetti. Keep a browser open next to the test run.\n\n```bash\npnpm dev\n```\n\nDo not assume the address. The port is derived from the path of the checkout, so every worktree and every clone gets its own and you can run several dev servers side by side without them fighting over 9000. The server prints its URL as it starts, before the build output scrolls past. `MERMAID_DEV_PORT` pins it if you want a fixed one.\n\nOpen `/dev/` and you get the explorer: the fixture tree on one side, the diagram on the other, a code tab for editing the source, and a layout picker for comparing your algorithm against the others on the same input. It reloads when you change the source, so an edit to your algorithm redraws the diagram without you touching the browser.\n\nFor a diagram that is not in the fixture tree, copy the standalone page template instead:\n\n```bash\ncp demos/dev/example.html demos/dev/grid.html\n```\n\nThat lands at `/dev/grid.html` on the same server. Put the diagram in the page and name your layout in the frontmatter:\n\n```html\n
\n---\nconfig:\n  layout: grid\n---\nflowchart TB\n  A --> B\n  B --> C\n
\n```\n\nA workflow that holds up over a long session:\n\n1. Run the sweep in one terminal, filtered to the fixture you are working on.\n2. Keep that same fixture open in the browser.\n3. Make one change and watch both. The score says whether it helped, and the picture says whether the score was measuring the right thing.\n4. Before committing, run the full sweep and confirm the aggregate did not drop.\n\nThe two disagree more often than you would expect, and the disagreement is informative. A score that improves while the diagram gets worse means the validator is blind to something, and that gap is worth writing down.\n\nUse the browser to check what the tests cannot see: text that overflows its shape, arrowheads pointing the wrong way, subgraph frames cutting through labels.\n\n## Performance on large diagrams\n\nA layout that is pleasant on ten nodes can be unusable on a thousand, and the difference does not show up in the fixture sweep — DDLT fixtures are small on purpose, so they say nothing about how your algorithm scales. There is a separate corpus for that.\n\n### The corpus\n\n`e2e/platform/dev-diagrams/performance/flowcharts/` holds fifteen real flowcharts, anonymized and grouped by size:\n\n```text\nperformance/flowcharts/\n  medium1.mmd … medium5.mmd   ← ~45-50 KB of source each\n  large1.mmd  … large5.mmd    ← ~70-75 KB\n  huge1.mmd   … huge5.mmd     ← 120-240 KB\n  baseline.json               ← a captured profiler run, for comparison\n```\n\nThe buckets are by source size, and node count does not follow it. `huge1.mmd` is around 2400 nodes with barely fifty edges; `huge2.mmd` is a few hundred nodes with over a thousand edges; `huge3.mmd` is a hundred nodes buried in `classDef` declarations. That spread is deliberate. These are real diagrams people drew, so the shapes that break layout algorithms in practice — one node with sixty edges, deeply nested subgraphs, a long thin chain, a wide flat fan — appear in the proportions they actually occur rather than the ones a generator would produce. Several carry frontmatter config, `handDrawn` look, and HTML labels, so they exercise the measuring pass as well as the layout.\n\n### Running the profiler\n\nProfiling lives in the same dev explorer as everything else in the previous section.\n\n1. `pnpm dev`, then open `/dev/` at the URL the server printed.\n2. Select `performance/flowcharts` in the file tree.\n3. In the Profiler panel, tick the layouts to compare, set the scope to **Folder**, choose the number of iterations, and press **Run profile**.\n\nEach layout is warmed up once and discarded, then every diagram is rendered `iterations` times per layout, with the fastest and slowest run of each series dropped before averaging. The score is total milliseconds across the set, lower is better. **Copy JSON** puts the whole run on the clipboard in the same shape as `baseline.json`.\n\nOne rough edge: the profiler's layout checkboxes come from a hardcoded list in `.esbuild/dev-explorer/diagram-viewer.ts` (`ALL_LAYOUTS`). A new layout will not appear there until you add it, even after it is registered with Mermaid.\n\n### Reading the table\n\nThe row you care about is rarely the total. Rendering is broken into phases, and only one of them is yours:\n\n| Phase       | What it covers                                              |\n| ----------- | ----------------------------------------------------------- |\n| `parse`     | Diagram text to db                                          |\n| `prepare`   | Building `LayoutData`, including your `prepareLayout`       |\n| `measure`   | DOM insertion and `getBBox` / `getBoundingClientRect`       |\n| `layout`    | The layout call, split into `↳ lib (external)` and `↳ ours` |\n| `paint`     | Drawing nodes and edges from your coordinates               |\n| `serialize` | SVG to string                                               |\n\n`↳ ours (wrapper)` is your code; `↳ lib (external)` is the third-party library underneath, if you wrap one. A layout that is slow because ELK is slow and a layout that is slow because of your own pass are the same number in the `layout` row and completely different problems one row down.\n\n`huge3.mmd` makes the point: 1410 ms in `parse` against 1.5 ms in `layout`. Its total is dominated by something you cannot fix from a layout algorithm, and reading totals would send you optimizing the wrong file.\n\nWatch `measure` too. It is not your phase, but it is downstream of `prepareLayout` — every synthetic node you add for an edge label is another element inserted into the DOM and measured, so a `prepareLayout` that is generous with helper nodes shows up as someone else's regression.\n\n### Comparing against the baseline\n\n`baseline.json` is a captured run over the same folder — dagre and elk, ten iterations, `theme=redux`, `look=neo`, with the capture date in the file.\n\nTreat the absolute numbers as a record of one machine on one day, not a threshold. They will not reproduce on your hardware, and a CI runner would not reproduce them either. What does carry over is the shape: the relative cost of the phases, which diagrams are layout-dominated and which are parse-dominated, and the ratio between the layouts. Profile your layout in the same run as dagre and elk and compare within that run.\n\n### What actually goes wrong\n\nIn practice the regressions are algorithmic, not micro-optimizations:\n\n- A pass over every pair of nodes. Fine at 50 nodes, 1.4 million comparisons at 1200.\n- `edges.filter((e) => e.start === node.id)` inside a loop over nodes — O(V·E) hidden behind two readable lines. Build the adjacency map once, before the loop.\n- Rebuilding a lookup inside an iterative refinement step, so an O(V) cost becomes O(V) per iteration.\n- Recursing into subgraphs without memoizing, and revisiting the same subtree once per ancestor.\n\nProfile before you optimize. Run the corpus, find the diagram where your `↳ ours` row is worst, and read that one — the corpus is small enough that the answer is usually one diagram and one loop.\n\n## Shipping as a separate package\n\nAn external layout uses the same `render` signature. Instead of editing the built-in registry, export a loader array and let the consumer register it:\n\n```ts\nimport type { LayoutLoaderDefinition } from 'mermaid';\n\nconst loader = async () => await import('./render.js');\n\nconst layouts: LayoutLoaderDefinition[] = [{ name: 'grid', loader, algorithm: 'grid.compact' }];\n\nexport default layouts;\n```\n\n```js\nimport mermaid from 'mermaid';\nimport layouts from 'my-mermaid-layout';\n\nmermaid.registerLayoutLoaders(layouts);\n```\n\nThe `algorithm` field is passed back to your renderer through `options`, which lets one package register several named variants that share an implementation.\n\nPackage it separately when the layout pulls in a large dependency. Everything else belongs in the main package, where it gets covered by the fixture sweep.\n\n## Checklist\n\n- [ ] `runLayoutCore` is one exported function with no DOM access\n- [ ] The browser and the tests call that same function\n- [ ] Group frames enclose their members and leave the title band clear\n- [ ] Edge labels reserve space before positions are decided\n- [ ] Edge endpoints land on node boundaries\n- [ ] Self-loops and parallel edges have routes\n- [ ] `validateLayout` returns `ok: true` on your fixtures\n- [ ] Fixtures exist, with captured sizes, for the cases the algorithm was written to handle\n- [ ] Your backend is registered in `ddlt/backends.ts` and your profile in `ddlt-manifest.json`\n- [ ] The sweep passes and the aggregate score has not dropped\n- [ ] `.mmd` fixtures under `e2e/diagrams/` cover the layout visually, since layout changes are rendering changes\n- [ ] The layout has been profiled against `performance/flowcharts/`, and the `↳ ours` row is understood\n","isInternal":false,"tokens":9321,"sizeBytes":41830},{"name":"new-diagram-jison.md","path":"packages/mermaid/src/docs/community/new-diagram-jison.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/community/new-diagram-jison.md","title":"Community Skill","category":"anthropic-skill","format":"markdown","content":"# Adding a New Diagram/Chart (Deprecated) 📊\n\n```warning\nJISON grammars are deprecated in mermaid. Please use Langium instead. See [New Diagram](./new-diagram.md) for more information.\n\n**New diagrams with JISON grammars will not be accepted.**\n```\n\n### Step 1: Grammar & Parsing\n\n#### Grammar\n\nThis would be to define a JISON grammar for the new diagram type. That should start with a way to identify that the text in the mermaid tag is a diagram of that type. Create a new folder under diagrams for your new diagram type and a parser folder in it. This leads us to step 2.\n\nFor instance:\n\n- the flowchart starts with the keyword _graph_\n- the sequence diagram starts with the keyword _sequenceDiagram_\n\n#### Store data found during parsing\n\nThere are some jison specific sub steps here where the parser stores the data encountered when parsing the diagram, this data is later used by the renderer. You can during the parsing call an object provided to the parser by the user of the parser. This object can be called during parsing for storing data.\n\n```jison\nstatement\n\t: 'participant' actor  { $$='actor'; }\n\t| signal               { $$='signal'; }\n\t| note_statement       { $$='note';  }\n\t| 'title' message      { yy.setTitle($2);  }\n\t;\n```\n\nIn the extract of the grammar above, it is defined that a call to the setTitle method in the data object will be done when parsing and the title keyword is encountered.\n\n```note\nMake sure that the `parseError` function for the parser is defined and calling `mermaid.parseError`. This way a common way of detecting parse errors is provided for the end-user.\n```\n\nFor more info look at the example diagram type:\n\nThe `yy` object has the following function:\n\n```javascript\nexports.parseError = function (err, hash) {\n  mermaid.parseError(err, hash);\n};\n```\n\nwhen parsing the `yy` object is initialized as per below:\n\n```javascript\nconst parser = exampleParser.parser;\nparser.yy = db;\n```\n\n### Step 2: Rendering\n\nWrite a renderer that given the data found during parsing renders the diagram. To look at an example look at sequenceRenderer.js rather than the flowchart renderer as this is a more generic example.\n\nPlace the renderer in the diagram folder.\n\n### Step 3: Detection of the new diagram type\n\nThe second thing to do is to add the capability to detect the new diagram to type to the detectType in `diagram-api/detectType.ts`. The detection should return a key for the new diagram type.\n[This key will be used to as the aria roledescription](#aria-roledescription), so it should be a word that clearly describes the diagram type.\nFor example, if your new diagram uses a UML deployment diagram, a good key would be \"UMLDeploymentDiagram\" because assistive technologies such as a screen reader\nwould voice that as \"U-M-L Deployment diagram.\" Another good key would be \"deploymentDiagram\" because that would be voiced as \"Deployment Diagram.\" A bad key would be \"deployment\" because that would not sufficiently describe the diagram.\n\nNote that the diagram type key does not have to be the same as the diagram keyword chosen for the [grammar](#grammar), but it is helpful if they are the same.\n\n### Step 4: The final piece - triggering the rendering\n\nAt this point when mermaid is trying to render the diagram, it will detect it as being of the new type but there will be no match when trying to render the diagram. To fix this add a new case in the switch statement in main.js:init this should match the diagram type returned from step #2. The code in this new case statement should call the renderer for the diagram type with the data found by the parser as an argument.\n\n## Usage of the parser as a separate module\n\n### Setup\n\n```javascript\nconst graph = require('./graphDb');\nconst flow = require('./parser/flow');\nflow.parser.yy = graph;\n```\n\n### Parsing\n\n```javascript\nflow.parser.parse(text);\n```\n\n### Data extraction\n\n```javascript\ngraph.getDirection();\ngraph.getVertices();\ngraph.getEdges();\n```\n\nThe parser is also exposed in the mermaid api by calling:\n\n```javascript\nconst parser = mermaid.getParser();\n```\n\nNote that the parse needs a graph object to store the data as per:\n\n```javascript\nflow.parser.yy = graph;\n```\n\nLook at `graphDb.js` for more details on that object.\n\n## Layout\n\nIf you are using a dagre based layout, please use flowchart-v2 as a template and by doing that you will be using dagre-wrapper instead of dagreD3 which we are migrating away from.\n\n### Common parts of a diagram\n\nThere are a few features that are common between the different types of diagrams. We try to standardize the diagrams that work as similar as possible for the end user. The commonalities are:\n\n- Directives, a way of modifying the diagram configuration from within the diagram code.\n- Accessibility, a way for an author to provide additional information like titles and descriptions to people accessing a text with diagrams using a screen reader.\n- Themes, there is a common way to modify the styling of diagrams in Mermaid.\n- Comments should follow mermaid standards\n\nHere are some pointers on how to handle these different areas.\n\n## Accessibility\n\nMermaid automatically adds the following accessibility information for the diagram SVG HTML element:\n\n- aria-roledescription\n- accessible title\n- accessible description\n\n### aria-roledescription\n\nThe aria-roledescription is automatically set to [the diagram type](#step-3--detection-of-the-new-diagram-type) and inserted into the SVG element.\n\nSee [the definition of aria-roledescription](https://www.w3.org/TR/wai-aria-1.1/#aria-roledescription) in [the Accessible Rich Internet Applications W3 standard.](https://www.w3.org/WAI/standards-guidelines/aria/)\n\n### accessible title and description\n\nThe syntax for accessible titles and descriptions is described in [the Accessibility documentation section.](../config/accessibility.md)\n\nAs a design goal, the jison syntax should be similar between the diagrams.\n\n```jison\n\n* lexical grammar */\n%lex\n%x acc_title\n%x acc_descr\n%x acc_descr_multiline\n\n%%\naccTitle\\s*\":\"\\s*                                { this.begin(\"acc_title\");return 'acc_title'; }\n(?!\\n|;|#)*[^\\n]*                     { this.popState(); return \"acc_title_value\"; }\naccDescr\\s*\":\"\\s*                                { this.begin(\"acc_descr\");return 'acc_descr'; }\n(?!\\n|;|#)*[^\\n]*                     { this.popState(); return \"acc_descr_value\"; }\naccDescr\\s*\"{\"\\s*                                { this.begin(\"acc_descr_multiline\");}\n[\\}]                        { this.popState(); }\n[^\\}]*                      return \"acc_descr_multiline_value\";\n\nstatement\n    : acc_title acc_title_value  { $$=$2.trim();yy.setTitle($$); }\n    | acc_descr acc_descr_value  { $$=$2.trim();yy.setAccDescription($$); }\n    | acc_descr_multiline_value { $$=$1.trim();yy.setAccDescription($$); }\n\n```\n\nThe functions for setting title and description are provided by a common module. This is the import from flowDb.js:\n\n```\nimport {\n  setAccTitle,\n  getAccTitle,\n  getAccDescription,\n  setAccDescription,\n  clear as commonClear,\n} from '../../commonDb';\n```\n\nThe accessibility title and description are inserted into the SVG element in the `render` function in mermaidAPI.\n\n## Theming\n\nMermaid supports themes and has an integrated theming engine. You can read more about how the themes can be used [in the docs](../config/theming.md).\n\nWhen adding themes to a diagram it comes down to a few important locations in the code.\n\nThe entry point for the styling engine is in **src/styles.js**. The getStyles function will be called by Mermaid when the styles are being applied to the diagram.\n\nThis function will in turn call a function _your diagram should provide_ returning the css for the new diagram. The diagram specific, also which is commonly also called getStyles and located in the folder for your diagram under src/diagrams and should be named styles.js. The getStyles function will be called with the theme options as an argument like in the following example:\n\n```js\nconst getStyles = (options) =>\n  `\n    .line {\n      stroke-width: 1;\n      stroke: ${options.lineColor};\n      stroke-dasharray: 2;\n    }\n    // ...\n    `;\n```\n\nNote that you need to provide your function to the main getStyles by adding it into the themes object in **src/styles.js** like in the xyzDiagram in the provided example:\n\n```js\nconst themes = {\n  flowchart,\n  'flowchart-v2': flowchart,\n  sequence,\n  xyzDiagram,\n  //...\n};\n```\n\nThe actual options and values for the colors are defined in **src/theme/theme-[xyz].js**. If you provide the options your diagram needs in the existing theme files then the theming will work smoothly without hiccups.\n","isInternal":false,"tokens":1962,"sizeBytes":8700},{"name":"new-diagram.md","path":"packages/mermaid/src/docs/community/new-diagram.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/community/new-diagram.md","title":"Community Skill","category":"anthropic-skill","format":"markdown","content":"# Adding a New Diagram/Chart 📊\n\nA diagram type in Mermaid is a plugin. You write a parser, a database, a renderer, and a styles\nfunction, register them under an id, and Mermaid handles detection, lazy loading, theming, and\nsanitization for you.\n\nThe use case diagram is the reference implementation for new work. When this guide says \"look at\nusecase\", the files are in `packages/mermaid/src/diagrams/usecase/`. Read them alongside these\nsteps: they are short, and they show the current conventions rather than the historical ones that\nolder diagrams still carry.\n\n## What a diagram is made of\n\nEach diagram exports a `DiagramDefinition` (`diagram-api/types.ts`) from a single entry file. The\nwhole of `usecaseDiagram.ts` is this:\n\n```ts\nimport type { DiagramDefinition } from '../../diagram-api/types.js';\nimport { parser } from './parser/usecase.chevrotain.js';\nimport { db } from './usecaseDb.js';\nimport { renderer } from './usecaseRenderer.js';\nimport styles from './styles.js';\n\nexport const diagram: DiagramDefinition = {\n  parser,\n  db,\n  renderer,\n  styles,\n};\n```\n\n| Part     | What it does                                                                   |\n| -------- | ------------------------------------------------------------------------------ |\n| parser   | Turns diagram text into calls on the db. Fails with a useful message otherwise |\n| db       | Holds the parsed model and hands it to the renderer                            |\n| renderer | Draws the SVG from what the db holds                                           |\n| styles   | Maps theme variables to CSS for your diagram                                   |\n| detector | A regex test that recognizes your diagram's first line. Lives in its own file  |\n\nTwo rules apply to everything in your folder:\n\nYour diagram must be self-contained. Never import from another diagram's folder. You may import\nfrom `diagrams/common/` and from `rendering-util/`, and that is the whole list. Cross-diagram\nimports create coupling that breaks unrelated diagrams later, so a reviewer will block on this.\n\nYour db must not carry state from one render into the next. `Diagram.fromText()` reads `db` off\nthe registered definition and calls `db.clear?.()` before parsing, and there are two supported\nways to satisfy that.\n\nA getter, which builds a new db on every read, so each render gets its own:\n\n```ts\nexport const diagram: DiagramDefinition = {\n  parser,\n  get db() {\n    return new TreeMapDB();\n  },\n  renderer,\n  styles,\n};\n```\n\nOr one shared db whose `clear()` resets every field it owns, plus the shared accessibility state\nin `diagrams/common/commonDb.ts`:\n\n```ts\nexport const diagram: DiagramDefinition = { parser, db, renderer, styles };\n```\n\nPrefer the getter in a new diagram. Isolation is then structural — a field added later cannot be\nforgotten in `clear()`, which is the way the shared form goes wrong. The use case diagram used as\nthe reference here takes the shared form, and pays for it by keeping every mutable field on one\n`state` object that `clear()` replaces wholesale, rather than resetting fields one by one.\n\nEither way the rule underneath is the same: all mutable state lives on the db, never in module\nscope. Module-level state survives `clear()` in both forms, and two diagrams of the same type on\none page will leak into each other.\n\n## Step 1: Grammar and parsing\n\nNew diagram grammars should use [Chevrotain](https://chevrotain.io/docs/), co-located with the\ndiagram itself under `packages/mermaid/src/diagrams//parser/`. The use case diagram is\nthe reference implementation: a lexer, a `CstParser`, and a CST visitor that builds the diagram\nmodel, sharing `diagrams/common/parser/runChevrotainParse.ts` to run the lexer/parser pair and\nreport failures with source positions.\n\nKeeping the grammar next to the diagram mirrors the existing JISON layout, so a diagram stays\nself-contained and the parser does not have to be released from a separate package.\n\nSeveral existing diagrams (architecture, gitGraph, info, packet, pie, radar, treemap) instead use\n[Langium](https://langium.org/docs/reference/grammar-language/) grammars in `packages/parser`, and\nolder diagrams use JISON. Both remain supported, so modify them in place for bug fixes rather than\nrewriting, but neither is the target for new work. These PRs show the Langium approach:\n\n- https://github.com/mermaid-js/mermaid/pull/4839\n- https://github.com/mermaid-js/mermaid/pull/4751\n\nWhichever you use, invalid input has to produce a parse error with a line and column, never a\nstack trace. Mermaid runs inside other people's pages, and a thrown exception there is a broken\npage rather than a broken diagram.\n\n## Step 2: The database\n\nThe db collects what the parser found and exposes getters for the renderer. Look at\n`usecaseDb.ts`. Alongside your own accessors, re-export the shared title and accessibility setters\nfrom `diagrams/common/commonDb.ts` so that authors get the same `title`, `accTitle`, and\n`accDescr` syntax they get everywhere else:\n\n```js\nimport {\n  setAccTitle,\n  getAccTitle,\n  getAccDescription,\n  setAccDescription,\n  setDiagramTitle,\n  getDiagramTitle,\n  clear as commonClear,\n} from '../common/commonDb.js';\n```\n\nYour own `clear()` should call `commonClear()` as well as resetting your own fields.\n\n## Step 3: The renderer\n\nWrite a renderer that draws the diagram from what the db holds. `usecaseRenderer.ts` is a good\nstarting point, and `sequenceRenderer.js` is a more generic older example than the flowchart\nrenderer. The renderer belongs in your diagram folder.\n\nTwo things are easy to miss and both get flagged in review.\n\nApply the configured padding and hand the sizing to the shared helper, so your diagram scales like\nevery other diagram instead of rendering at some unrelated size:\n\n```ts\nimport { setupViewPortForSVG } from '../../rendering-util/setupViewPortForSVG.js';\n\nsetupViewPortForSVG(svg, padding, 'usecaseDiagram', config.useMaxWidth);\n```\n\nSupport hand-drawn mode if your drawing approach allows it. The config carries a `look`, and\ndiagrams check it directly:\n\n```ts\nconst isHandDrawn = look === 'handDrawn';\n```\n\nIf a third party library makes hand-drawn output impossible, that is an acceptable answer, but say\nso in your diagram's documentation page so users are not left guessing.\n\n## Step 4: Detection and registration\n\nDetection lives in its own file next to the diagram, not in `detectType.ts`. A detector is a\nregex test plus a lazy loader, and it exports an `ExternalDiagramDefinition`:\n\n```ts\nconst id = 'usecase';\n\nconst detector: DiagramDetector = (txt) => {\n  return /^\\s*usecase-beta(?:\\s|$)/.test(txt);\n};\n\nconst loader: DiagramLoader = async () => {\n  const { diagram } = await import('./usecaseDiagram.js');\n  return { id, diagram };\n};\n\nexport const usecase: ExternalDiagramDefinition = { id, detector, loader };\n```\n\nThen import it in `diagram-api/diagram-orchestration.ts` and add it to the\n`registerLazyLoadedDiagrams(...)` call. Order matters there: the first detector that returns true\nwins, so a loose pattern placed early will swallow other diagrams. The loader is what keeps\nMermaid's bundle small, because your diagram is only fetched once someone writes one.\n\n[The id becomes the aria roledescription](#aria-roledescription), so pick a word that describes\nthe diagram out loud. For a UML deployment diagram, \"UMLDeploymentDiagram\" works, because a screen\nreader voices it as \"U-M-L Deployment diagram\", and so does \"deploymentDiagram\". \"deployment\" on\nits own does not say enough.\n\nThe id does not have to match the keyword you chose in the\n[grammar](#step-1-grammar-and-parsing), though it helps when they agree.\n\n## Step 5: Theming\n\nMermaid has an integrated theming engine, described in more detail [in the docs](../config/theming.md).\n\nYour diagram provides a `getStyles` function in `styles.ts` in your diagram folder. It is called\nwith the resolved theme options and returns CSS:\n\n```js\nconst getStyles = (options) =>\n  `\n    .line {\n      stroke-width: 1;\n      stroke: ${options.lineColor};\n      stroke-dasharray: 2;\n    }\n    // ...\n    `;\n```\n\nThere is nothing to wire up by hand. `registerDiagram()` passes your `styles` to\n`addStylesForDiagram()`, and the styling engine picks it up from there.\n\nEvery color must come from `options`. A hardcoded hex value looks fine in the default theme and\nthen breaks in dark mode, so reviewers treat hardcoded colors as a defect. The values themselves\nare defined in the theme files under `src/themes/`; if your diagram needs a variable that does not\nexist yet, add it there so all five themes define it.\n\n## Step 6: Configuration\n\nIf your diagram has options, add them to `src/schemas/config.schema.yaml`, both as an entry in the\nlist of diagram config keys and as its own config block. Then regenerate the types:\n\n```bash\npnpm run --filter mermaid types:build-config\n```\n\nNever edit `config.type.ts` by hand. It is generated, CI verifies it against the schema, and a\nmanual edit is a blocking review finding.\n\n## Accessibility\n\nMermaid automatically adds the following accessibility information for the diagram SVG HTML element:\n\n- aria-roledescription\n- accessible title\n- accessible description\n\n### aria-roledescription\n\nThe aria-roledescription is automatically set to\n[the diagram type](#step-4-detection-and-registration) and inserted into the SVG element.\n\nSee [the definition of aria-roledescription](https://www.w3.org/TR/wai-aria-1.1/#aria-roledescription) in [the Accessible Rich Internet Applications W3 standard.](https://www.w3.org/WAI/standards-guidelines/aria/)\n\n### accessible title and description\n\nThe syntax for accessible titles and descriptions is described in [the Accessibility documentation section.](../config/accessibility.md)\n\nYou get both for free once your db re-exports the setters shown in\n[Step 2](#step-2-the-database). The values are inserted into the SVG element in the `render`\nfunction in mermaidAPI.\n\n## Step 7: Tests\n\nA new diagram without tests will not be merged. There are three kinds, and none of them takes long.\n\nUnit tests for the parser and db go next to the code as `*.spec.ts`. Cover the syntax you\ndocumented, and cover invalid input too: a diagram that accepts nonsense silently is worse than\none that rejects it. Run them with `vitest run packages/mermaid/src/diagrams/`.\n\nVisual regression tests come from `.mmd` fixtures. Put one file per scenario in\n`e2e/diagrams//`, and that is the whole job:\n`e2e/rendering/mmd-snapshots.spec.ts` walks that directory, renders each fixture, and snapshots\nit, grouping the results by folder. Screenshot names must be unique across the whole tree, and the\nrun fails fast if two fixtures collide. `e2e/sheet-order.json` holds the ordering. Run the suite\nwith `pnpm e2e`. Cover realistic diagrams rather than one minimal smoke test, and include a\nfixture per theme if your styling is at all involved.\n\nA documentation test keeps your examples honest. `usecase.docs.spec.ts` reads the published\n`syntax/usecase.md`, extracts every ` ```mermaid-example ` block, and parses it. Copy that pattern\nand your documentation cannot drift into examples that no longer work.\n\n## Step 8: Documentation, demos, and examples\n\nWrite your syntax page as `packages/mermaid/src/docs/syntax/.md`. Edit only the files\nunder `src/docs/`; the top-level `/docs` folder is generated and your changes there will be\noverwritten. Mark the version with the placeholder, as `usecase.md` does with\n`# Use case diagrams (12.0.0+)`, and the release process substitutes the real\nnumber.\n\nAdd the page to the sidebar in `.vitepress/config.ts` under `sidebarSyntax()`. A page with no\nsidebar entry is reachable only by URL, which in practice means nobody reads it.\n\nAdd a demo page at `demos/.html` and link it from `demos/index.html`, following any\nof the existing demos.\n\nAdd at least one entry to the `@mermaid-js/examples` package, which is what tools like\nmermaid.live use to help people get started. Duplicate an existing file such as\n`packages/examples/src/examples/flowchart.ts`, adapt it, then import it in\n`packages/examples/src/index.ts` and add it to the `examples` array. Mark one example as the\ndefault, and add more to show off individual features.\n\nIf your syntax introduces new keywords, add them to `.cspell/mermaid-terms.txt`. The pre-commit\nhook runs CSpell and will otherwise reject the commit.\n\n## Step 9: Changeset and pull request\n\nRun `pnpm changeset`, choose the `mermaid` package and a `minor` bump, and write a description\nprefixed with `feat:`.\n\nOpen the PR against `develop` and link the issue it resolves. New diagram types are large by\nnature, and that is fine, but keep unrelated refactors out of the same branch.\n\n## Reviewer's checklist\n\nThis is what a reviewer checks. Going through it yourself first is the fastest way to a short\nreview.\n\n- [ ] Parser uses Chevrotain, co-located under `diagrams//parser/`\n- [ ] Invalid input produces a parse error with position, not a crash\n- [ ] `DiagramDefinition` exports parser, db, renderer, and styles\n- [ ] Detector in its own file, registered in `diagram-orchestration.ts`, ordered so it does not shadow other diagrams\n- [ ] Diagram id reads well as an aria roledescription\n- [ ] db holds no module-level state and `clear()` resets everything, including `commonClear()`\n- [ ] No imports from other diagrams' folders\n- [ ] Renderer applies padding and `useMaxWidth` through `setupViewPortForSVG`\n- [ ] Handdrawn mode implemented, or its absence documented\n- [ ] `styles.ts` takes theme options, with no hardcoded colors\n- [ ] Config options added to `config.schema.yaml` and `config.type.ts` regenerated, never hand-edited\n- [ ] Accessibility setters re-exported from `common/commonDb.ts`\n- [ ] Unit tests for parser and db, covering invalid input\n- [ ] `.mmd` fixtures in `e2e/diagrams//` for visual regression\n- [ ] Documentation examples covered by a docs spec\n- [ ] Syntax page under `src/docs/syntax/`, with `MERMAID_RELEASE_VERSION` and a sidebar entry\n- [ ] Demo page and `demos/index.html` link\n- [ ] Example added to `@mermaid-js/examples`, one marked default\n- [ ] New keywords added to `.cspell/mermaid-terms.txt`\n- [ ] Changeset created (`minor`, `feat:`)\n- [ ] PR targets `develop` and links its issue\n","isInternal":false,"tokens":3361,"sizeBytes":14295},{"name":"questions-and-suggestions.md","path":"packages/mermaid/src/docs/community/questions-and-suggestions.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/community/questions-and-suggestions.md","title":"Community Skill","category":"anthropic-skill","format":"markdown","content":"# Questions or Suggestions?\n\n## Search for Existing Issue\n\nFirst search to see if someone has already asked (and hopefully been answered) or suggested the same thing.\n\n- [Search in Discussions](https://github.com/orgs/mermaid-js/discussions)\n- [Search in Issues (Open & Closed)](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue)\n\nIf you find an open issue or discussion thread that is similar to your question but isn't answered, you can let us know that you are also interested in it.\nUse the GitHub reactions to add a thumbs-up to the issue or discussion thread, or append to the issue if needed.\n\nThis helps the team know the relative interest in something and helps them set priorities and assignments.\n\n## Add a new Issue\n\nYou have not found anything that already addresses your request, or maybe you have come up with the new idea? Feel free to open a new issue or discussion.\n\nLog in to [GitHub.com](https://www.github.com), and use [GitHub issue tracker of the mermaid-js repository](https://github.com/mermaid-js/mermaid/issues). Press [issue, select the appropriate template](https://github.com/mermaid-js/mermaid/issues/new/choose) and describe your problem.\n","isInternal":false,"tokens":263,"sizeBytes":1179},{"name":"security.md","path":"packages/mermaid/src/docs/community/security.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/community/security.md","title":"Community Skill","category":"anthropic-skill","format":"markdown","content":"# Security\n\nThe Mermaid team takes the security of Mermaid and the applications that use Mermaid seriously. This page describes how to report any vulnerabilities you may find, and lists best practices to minimize the risk of introducing a vulnerability.\n\n## Reporting vulnerabilities\n\nTo report a vulnerability, please e-mail  with a description of the issue, the steps you took to create the issue, affected versions, and if known, mitigations for the issue.\n\nWe aim to reply within three working days, probably much sooner.\n\nYou should expect a close collaboration as we work to resolve the issue you have reported. Please reach out to  again if you do not receive prompt attention and regular updates.\n\nYou may also reach out to the team via our public Discord chat channels; however, please make sure to e-mail  when reporting an issue, and avoid revealing information about vulnerabilities in public as that could that could put users at risk.\n\n## Best practices\n\nKeep current with the latest Mermaid releases. We regularly update Mermaid, and these updates may fix security defects discovered in previous versions. Check the Mermaid release notes for security-related updates.\n\nKeep your application’s dependencies up to date. Make sure you upgrade your package dependencies to keep the dependencies up to date. Avoid pinning to specific versions for your dependencies and, if you do, make sure you check periodically to see if your dependencies have had security updates, and update the pin accordingly.\n\n## Configuring DomPurify\n\nBy default Mermaid uses a baseline [DOMPurify](https://github.com/cure53/DOMPurify) config. It is possible to override the options passed to DOMPurify by adding a `dompurifyConfig` key to the Mermaid options. This could potentially break the output of Mermaid so use this with caution.\n","isInternal":false,"tokens":382,"sizeBytes":1895},{"name":"8.6.0_docs.md","path":"packages/mermaid/src/docs/config/8.6.0_docs.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/config/8.6.0_docs.md","title":"Config Skill","category":"anthropic-skill","format":"markdown","content":"# Version 8.6.0 Changes\n\n## [New Mermaid Live-Editor Beta](https://mermaid-js.github.io/docs/mermaid-live-editor-beta/#/edit/eyJjb2RlIjoiJSV7aW5pdDoge1widGhlbWVcIjogXCJmb3Jlc3RcIiwgXCJsb2dMZXZlbFwiOiAxIH19JSVcbmdyYXBoIFREXG4gIEFbQ2hyaXN0bWFzXSAtLT58R2V0IG1vbmV5fCBCKEdvIHNob3BwaW5nKVxuICBCIC0tPiBDe0xldCBtZSB0aGlua31cbiAgQyAtLT58T25lfCBEW0xhcHRvcF1cbiAgQyAtLT58VHdvfCBFW2lQaG9uZV1cbiAgQyAtLT58VGhyZWV8IEZbZmE6ZmEtY2FyIENhcl1cblx0XHQiLCJtZXJtYWlkIjp7InRoZW1lIjoiZGFyayJ9fQ)\n\n## [CDN](https://www.jsdelivr.com/package/npm/mermaid)\n\nWith version 8.6.0 comes the release of directives for mermaid, a new system for modifying configurations, with the aim of establishing centralized, sane defaults and simple implementation.\n\n`directives` allow for a single-use overwriting of `config`, as it has been discussed in [Configurations](../config/configuration.md).\nThis allows site Diagram Authors to instantiate temporary modifications to `config` through the use of [Directives](directives.md), which are parsed before rendering diagram definitions. This allows the Diagram Authors to alter the appearance of the diagrams.\n\n**A likely application for this is in the creation of diagrams/charts inside company/organizational webpages, that rely on mermaid for diagram and chart rendering.**\n\nthe `init` directive is the main method of configuration for Site and Current Levels.\n\nThe three levels of are Configuration, Global, Site and Current.\n\n| Level of Configuration | Description                         |\n| ---------------------- | ----------------------------------- |\n| Global Configuration   | Default Mermaid Configurations      |\n| Site Configuration     | Configurations made by site owner   |\n| Current Configuration  | Configurations made by Implementors |\n\n# Limits to Modifying Configurations\n\n**secure Array**\n\n| Parameter | Description                                      | Type  | Required | Values         |\n| --------- | ------------------------------------------------ | ----- | -------- | -------------- |\n| secure    | Array of parameters excluded from init directive | Array | Required | Any parameters |\n\nThe modifiable parts of the Configuration are limited by the secure array, which is an array of immutable parameters, this array can be expanded by site owners.\n\n**Notes**: secure arrays work like nesting dolls, with the Global Configurations’ secure array holding the default and immutable list of immutable parameters, or the smallest doll, to which site owners may add to, but implementors may not modify it.\n\n# Secure Arrays\n\nSite owners can add to the **secure** array using this command:\nmermaidAPI.initialize( { startOnLoad: true, secure: ['parameter1', 'parameter2'] } );\n\nDefault values for the `secure array` consists of: ['secure', 'securityLevel', 'startOnLoad', 'maxTextSize']. These default values are immutable.\n\nImplementors can only modify configurations using directives, and cannot change the `secure` array.\n\n# Modifying Configurations and directives:\n\nThe Two types of directives: are `init` (or `initialize`) and `wrap`.\n\n```note\nAll directives are enclosed in `%%{ }%%`\n```\n\nOlder versions of mermaid will not parse directives because `%%` will comment out the directive. This makes the update backwards-compatible.\n\n# Init\n\n`init`, or `initialize`: this directive gives the user the ability to overwrite and change the values for any configuration parameters not set in the secure array.\n\n| Parameter | Description             | Type      | Required | Values                                          |\n| --------- | ----------------------- | --------- | -------- | ----------------------------------------------- |\n| init      | modifies configurations | Directive | Optional | Any parameters not included in the secure array |\n\n```note\ninit would be an argument-directive: `%%{init: { **insert argument here**}}%%`\n\nThe json object that is passed as {**argument** } must be valid, quoted json or it will be ignored.\n**for example**:\n\n`%%{init: {\"theme\": \"default\", \"logLevel\": 1 }}%%`\n\nConfigurations that are passed through init cannot change the parameters in a secure array at a higher level. In the event of a collision, mermaid will give priority to secure arrays and parse the request without changing the values of those parameters in conflict.\n\nWhen deployed within code, init is called before the graph/diagram description.\n```\n\n**for example**:\n\n```mermaid-example\n%%{init: {\"theme\": \"default\", \"logLevel\": 1 }}%%\n graph LR\n  a-->b\n  b-->c\n  c-->d\n  d-->e\n  e-->f\n  f-->g\n  g-->\n```\n\n# Wrap\n\n| Parameter | Description                   | Type      | Required | Values     |\n| --------- | ----------------------------- | --------- | -------- | ---------- |\n| wrap      | a callable text-wrap function | Directive | Optional | %%{wrap}%% |\n\n```note\nWrap is a function that is currently only deployable for sequence diagrams.\n\n`Wrap respects a manually added 
, so if the user wants to break up their text, they have full control over line breaks by adding 
 tags.`\n\nIt is a non-argument directive and can be executed thusly:\n\n`%%{wrap}%%` .\n```\n\n**An example of text wrapping in a sequence diagram**:\n\n![Image showing wrapped text](img/wrapped text.png)\n\n# Resetting Configurations:\n\nThere are two more functions in the mermaidAPI that can be called by site owners: **reset** and **globalReset**.\n\n**reset**: resets the configuration to whatever the last configuration was. This can be done to undo more recent changes set from the last mermaidAPI.initialize({...}) configuration.\n\n**globalReset** will reset both the current configuration AND the site configuration back to the global defaults.\n\n**Notes**: Both `reset` and `globalReset` are only available to site owners, and as such implementors have to edit their configs using `init`.\n\n# Additional Utils to mermaid\n\n• **memoize**: simple caching for computationally expensive functions, reducing rendering time by about 90%.\n\n• **assignWithDepth** - an improvement on previous functions with config.js and `Object.assign`. The purpose of this function is to provide a sane mechanism for merging objects, similar to `object.assign`, but with depth.\n\nExample of **assignWithDepth**:\n\n![Image showing assignWithDepth](img/assignWithDepth.png)\n\nExample of **object.Assign**:\n\n![Image showing object.assign without depth](img/object.assign without depth.png)\n\n• **calculateTextDimensions**, **calculateTextWidth**， and **calculateTextHeight** - for measuring text dimensions, width and height.\n\n**Notes**: For more information on usage, parameters, and return info for these new functions take a look at the jsdocs for them in the utils package.\n\n# New API Requests Introduced in Version 8.6.0\n\n## setSiteConfig\n\n| Function        | Description                           | Type        | Values                                  | Parameters | Returns    |\n| --------------- | ------------------------------------- | ----------- | --------------------------------------- | ---------- | ---------- |\n| `setSiteConfig` | Sets the siteConfig to desired values | Put Request | Any Values, except ones in secure array | conf       | siteConfig |\n\n```note\nSets the siteConfig. The siteConfig is a protected configuration for repeat use. Calls to reset() will reset\nthe currentConfig to siteConfig. Calls to reset(configApi.defaultConfig) will reset siteConfig and currentConfig\nto the defaultConfig\nNote: currentConfig is set in this function。\nDefault value: will mirror Global Config\n```\n\n## getSiteConfig\n\n| Function        | Description                                         | Type        | Values                             |\n| --------------- | --------------------------------------------------- | ----------- | ---------------------------------- |\n| `getSiteConfig` | Returns the current `siteConfig` base configuration | Get Request | Returns Any Values in `siteConfig` |\n\n```note\nReturns any values in siteConfig.\n```\n\n## setConfig\n\n| Function    | Description                                | Type        | Values                            | Parameters | Returns                                        |\n| ----------- | ------------------------------------------ | ----------- | --------------------------------- | ---------- | ---------------------------------------------- |\n| `setConfig` | Sets the `currentConfig` to desired values | Put Request | Any Values, those in secure array | conf       | `currentConfig` merged with the sanitized conf |\n\n```note\nSets the currentConfig. The parameter conf is sanitized based on the siteConfig.secure keys. Any\nvalues found in conf with key found in siteConfig.secure will be replaced with the corresponding\nsiteConfig value.\n```\n\n## getConfig\n\n| Function    | Description                 | Type        | Return Values                   |\n| ----------- | --------------------------- | ----------- | ------------------------------- |\n| `getConfig` | Obtains the `currentConfig` | Get Request | Any Values from `currentConfig` |\n\n```note\nReturns any values in currentConfig.\n```\n\n## sanitize\n\n| Function   | Description                              | Type           | Values |\n| ---------- | ---------------------------------------- | -------------- | ------ |\n| `sanitize` | Sets the `siteConfig` to desired values. | Put Request(?) | None   |\n\n```note\nmodifies options in-place\nEnsures options parameter does not attempt to override siteConfig secure keys.\n```\n\n## reset\n\n| Function | Description                    | Type        | Required | Values | Parameter |\n| -------- | ------------------------------ | ----------- | -------- | ------ | --------- |\n| `reset`  | Resets `currentConfig` to conf | Put Request | Required | None   | conf      |\n\n## conf\n\n| Parameter | Description                                                  | Type       | Required | Values                                       |\n| --------- | ------------------------------------------------------------ | ---------- | -------- | -------------------------------------------- |\n| `conf`    | base set of values, which `currentConfig` could be reset to. | Dictionary | Required | Any Values, with respect to the secure Array |\n\n```note\ndefault: current siteConfig (optional, default `getSiteConfig()`)\n```\n\n## For more information, read [Setup](./setup/README.md).\n","isInternal":false,"tokens":2216,"sizeBytes":10316},{"name":"accessibility.md","path":"packages/mermaid/src/docs/config/accessibility.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/config/accessibility.md","title":"Config Skill","category":"anthropic-skill","format":"markdown","content":"# Accessibility Options\n\n## Accessibility\n\nNow with Mermaid library in much wider use, we have started to work towards more accessible features, based on the feedback from the community.\n\nAdding accessibility means that the rich information communicated by visual diagrams can be made available to those using assistive technologies (and of course to search engines).\n[Read more about Accessible Rich Internet Applications and the W3 standards.](https://www.w3.org/WAI/standards-guidelines/aria/)\n\nMermaid will automatically insert the [aria-roledescription](#aria-roledescription) and, if provided in the diagram text by the diagram author, the [accessible title and description.](#accessible-title-and-description)\n\n### aria-roledescription\n\nThe [aria-roledescription](https://www.w3.org/TR/wai-aria-1.1/#aria-roledescription) for the SVG HTML element is set to the diagram type key. (Note this may be slightly different than the keyword used for the diagram in the diagram text.)\n\nFor example: The diagram type key for a state diagram is \"stateDiagram\". Here (a part of) the HTML of the SVG tag that shows the automatically inserted aria-roledescription set to \"stateDiagram\". _(Note that some of the SVG attributes and the SVG contents are omitted for clarity.):_\n\n```html\n\n```\n\n### Accessible Title and Description\n\nSupport for accessible titles and descriptions is available for all diagrams/chart types. We have tried to keep the same keywords and format for all diagrams so that it is easy to understand and maintain.\n\nThe accessible title and description will add `` and `<desc>` elements within the SVG element and the [aria-labelledby](https://www.w3.org/TR/wai-aria/#aria-labelledby) and [aria-describedby](https://www.w3.org/TR/wai-aria/#aria-describedby) attributes in the SVG tag.\n\nHere is HTML that is generated, showing that the SVG element is labelled by the accessible title (id = `chart-title-mermaid-1668725057758`)\nand described by the accessible description (id = `chart-desc-mermaid-1668725057758` );\nand the accessible title element (text = \"This is the accessible title\")\nand the accessible description element (text = \"This is an accessible description\").\n\n_(Note that some of the SVG attributes and the SVG contents are omitted for clarity.)_\n\n```html\n<svg\n  aria-labelledby=\"chart-title-mermaid-1668725057758\"\n  aria-describedby=\"chart-desc-mermaid-1668725057758\"\n  xmlns=\"http://www.w3.org/2000/svg\"\n  width=\"100%\"\n  id=\"mermaid-1668725057758\"\n>\n  <title id=\"chart-title-mermaid-1668725057758\">This is the accessible title\n  This is an accessible description\n\n```\n\nDetails for the syntax follow.\n\n#### accessible title\n\nThe **accessible title** is specified with the **accTitle** _keyword_, followed by a colon (`:`), and the string value for the title.\nThe string value ends at the end of the line. (It can only be a single line.)\n\nEx: `accTitle: This is a single line title`\n\nSee [the accTitle and accDescr usage examples](#acctitle-and-accdescr-usage-examples) for how this can be used in a diagram and the resulting HTML generated.\n\n#### accessible description\n\nAn accessible description can be 1 line long (a single line) or many lines long.\n\nThe **single line accessible description** is specified with the **accDescr** _keyword_, followed by a colon (`:`), followed by the string value for the description.\n\nEx: `accDescr: This is a single line description.`\n\nA **multiple line accessible description** _does not have a colon (`:`) after the accDescr keyword_ and is surrounded by curly brackets (`{}`).\n\nEx:\n\n```markdown\naccDescr {\nThis is a multiple line accessible description.\nIt does not have a colon and is surrounded by curly brackets.\n}\n```\n\nSee [the accTitle and accDescr usage examples](#acctitle-and-accdescr-usage-examples) for how this can be used in a diagram and the resulting HTML generated.\n\n#### accTitle and accDescr Usage Examples\n\n- Flowchart with the accessible title \"Big Decisions\" and the single-line accessible description \"Bob's Burgers process for making big decisions\"\n\n```mermaid-example\n  graph LR\n      accTitle: Big Decisions\n      accDescr: Bob's Burgers process for making big decisions\n      A[Identify Big Decision] --> B{Make Big Decision}\n      B --> D[Be done]\n```\n\nHere is the HTML generated for the SVG element: _(Note that some of the SVG attributes and the SVG contents are omitted for clarity.):_\n\n```html\n\n  Big decisions\n  Bob's Burgers process for making big decisions\n\n```\n\n- Flowchart with the accessible title \"Bob's Burger's Making Big Decisions\" and the multiple line accessible description \"The official Bob's Burgers corporate processes that are used\n  for making very, very big decisions.\n  This is actually a very simple flow: identify the big decision and then make the big decision.\"\n\n```mermaid-example\n  graph LR\n      accTitle: Bob's Burger's Making Big Decisions\n      accDescr {\n        The official Bob's Burgers corporate processes that are used\n        for making very, very big decisions.\n        This is actually a very simple flow: identify the big decision and then make the big decision.\n         }\n      A[Identify Big Decision] --> B{Make Big Decision}\n      B --> D[Be done]\n```\n\nHere is the HTML generated for the SVG element: _(Note that some of the SVG attributes and the SVG contents are omitted for clarity.):_\n\n```html\n\n  Big decisions\n  \n    The official Bob's Burgers corporate processes that are used for making very, very big\n    decisions. This is actually a very simple flow: identify the big decision and then make the big\n    decision.\n  \n\n```\n\n#### Sample Code Snippets for other diagram types\n\n##### Class Diagram\n\n```mermaid-example\n   classDiagram\n      accTitle: My Class Diagram\n      accDescr: My Class Diagram Description\n\n      Vehicle <|-- Car\n```\n\n##### Entity Relationship Diagram\n\n```mermaid-example\n   erDiagram\n      accTitle: My Entity Relationship Diagram\n      accDescr: My Entity Relationship Diagram Description\n\n    CUSTOMER ||--o{ ORDER : places\n    ORDER ||--|{ LINE-ITEM : contains\n    CUSTOMER }|..|{ DELIVERY-ADDRESS : uses\n\n```\n\n##### Gantt Chart\n\n```mermaid-example\n   gantt\n      accTitle: My Gantt Chart Accessibility Title\n      accDescr: My Gantt Chart Accessibility Description\n\n    title A Gantt Diagram\n    dateFormat  YYYY-MM-DD\n    section Section\n    A task           :a1, 2014-01-01, 30d\n    Another task     :after a1  , 20d\n    section Another\n    Task in sec      :2014-01-12  , 12d\n    another task      : 24d\n\n```\n\n##### GitGraph\n\n```mermaid-example\n  gitGraph\n      accTitle: My GitGraph Accessibility Title\n      accDescr: My GitGraph Accessibility Description\n\n     commit\n     commit\n     branch develop\n     checkout develop\n     commit\n     commit\n     checkout main\n     merge develop\n     commit\n     commit\n\n```\n\n##### Pie Chart\n\n```mermaid-example\n   pie\n      accTitle: My Pie Chart Accessibility Title\n      accDescr: My Pie Chart Accessibility Description\n\n    title Key elements in Product X\n    \"Calcium\" : 42.96\n    \"Potassium\" : 50.05\n    \"Magnesium\" : 10.01\n    \"Iron\" :  5\n\n```\n\n##### Requirement Diagram\n\n```mermaid-example\n  requirementDiagram\n      accTitle: My Requirement Diagram\n      accDescr: My Requirement Diagram Description\n\n       requirement test_req {\n  id: 1\n  text: the test text.\n  risk: high\n  verifymethod: test\n  }\n\n  element test_entity {\n  type: simulation\n  }\n\n  test_entity - satisfies -> test_req\n\n```\n\n##### Sequence Diagram\n\n```mermaid-example\n   sequenceDiagram\n      accTitle: My Sequence Diagram\n      accDescr: My Sequence Diagram Description\n\n      Alice->>John: Hello John, how are you?\n      John-->>Alice: Great!\n      Alice-)John: See you later!\n```\n\n##### State Diagram\n\n```mermaid-example\n   stateDiagram\n      accTitle: My State Diagram\n      accDescr: My State Diagram Description\n\n       s1 --> s2\n\n```\n\n##### User Journey Diagram\n\n```mermaid-example\n  journey\n      accTitle: My User Journey Diagram\n      accDescr: My User Journey Diagram Description\n\n      title My working day\n      section Go to work\n        Make tea: 5: Me\n        Go upstairs: 3: Me\n        Do work: 1: Me, Cat\n      section Go home\n        Go downstairs: 5: Me\n        Sit down: 5: Me\n\n```\n","isInternal":false,"tokens":2253,"sizeBytes":9060},{"name":"configuration.md","path":"packages/mermaid/src/docs/config/configuration.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/config/configuration.md","title":"Config Skill","category":"anthropic-skill","format":"markdown","content":"# Configuration\n\nWhen mermaid starts, configuration is extracted to determine a configuration to be used for a diagram. There are 3 sources for configuration:\n\n- The default configuration\n- Overrides at the site level are set by the initialize call, and will be applied to all diagrams in the site/app. The term for this is the **siteConfig**.\n- Frontmatter (v10.5.0+) - diagram authors can update selected configuration parameters in the frontmatter of the diagram. These are applied to the render config.\n- Directives (Deprecated by Frontmatter) - diagram authors can update selected configuration parameters directly in the diagram code via directives. These are applied to the render config.\n\n**The render config** is configuration that is used when rendering by applying these configurations.\n\n## Frontmatter config\n\nThe entire mermaid configuration (except the secure configs) can be overridden by the diagram author in the frontmatter of the diagram. The frontmatter is a YAML block at the top of the diagram.\n\n```mermaid-example\n---\ntitle: Hello Title\nconfig:\n  theme: base\n  themeVariables:\n    primaryColor: \"#00ff00\"\n---\nflowchart\n\tHello --> World\n\n```\n\n## Theme configuration\n\n## Starting mermaid\n\n```mermaid\nsequenceDiagram\n\tSite->>mermaid: initialize\n\tSite->>mermaid: content loaded\n\tmermaid->>mermaidAPI: init\n```\n\n## Initialize\n\nThe initialize call is applied **only once**. It is called by the site integrator in order to override the default configuration at a site level.\n\n## configApi.reset\n\nThis method resets the configuration for a diagram to the overall site configuration, which is the configuration provided by the site integrator. Before each rendering of a diagram, reset is called at the very beginning.\n","isInternal":false,"tokens":369,"sizeBytes":1733},{"name":"directives.md","path":"packages/mermaid/src/docs/config/directives.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/config/directives.md","title":"Config Skill","category":"anthropic-skill","format":"markdown","content":"# Directives\n\n```warning\nDirectives are deprecated from v10.5.0. Please use the `config` key in frontmatter to pass configuration. See [Configuration](./configuration.md) for more details.\n```\n\n## Directives\n\nDirectives give a diagram author the capability to alter the appearance of a diagram before rendering by changing the applied configuration.\n\nThe significance of having directives is that you have them available while writing the diagram, and can modify the default global and diagram-specific configurations. So, directives are applied on top of the default configuration. The beauty of directives is that you can use them to alter configuration settings for a specific diagram, i.e. at an individual level.\n\nWhile directives allow you to change most of the default configuration settings, there are some that are not available, for security reasons. Also, you have the _option to define the set of configurations_ that you wish to allow diagram authors to override with directives.\n\n## Types of Directives options\n\nMermaid basically supports two types of configuration options to be overridden by directives.\n\n1. _General/Top Level configurations_ : These are the configurations that are available and applied to all the diagram. **Some of the most important top-level** configurations are:\n   - theme\n   - fontFamily\n   - logLevel\n   - securityLevel\n   - startOnLoad\n   - secure\n\n2. _Diagram-specific configurations_ : These are the configurations that are available and applied to a specific diagram. For each diagram there are specific configuration that will alter how that particular diagram looks and behaves.\n   For example, `mirrorActors` is a configuration that is specific to the `SequenceDiagram` and alters whether the actors are mirrored or not. So this config is available only for the `SequenceDiagram` type.\n\n**NOTE:** Not all configuration options are listed here. To get hold of all the configuration options, please refer to the [defaultConfig.ts](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/defaultConfig.ts) in the source code.\n\n```note\nWe plan to publish a complete list of top-level configurations & diagram-specific configurations with their possible values in the docs soon.\n```\n\n## Declaring directives\n\nNow that we have defined the types of configurations that are available, we can learn how to declare directives.\nA directive always starts and ends with `%%` signs with directive text in between, like `%% {directive_text} %%`.\n\nHere the structure of a directive text is like a nested key-value pair map or a JSON object with root being _init_. Where all the general configurations are defined in the top level, and all the diagram specific configurations are defined one level deeper with diagram type as key/root for that section.\n\nThe following code snippet shows the structure of a directive:\n\n```\n%%{\n  init: {\n    \"theme\": \"dark\",\n    \"fontFamily\": \"monospace\",\n    \"logLevel\": \"info\",\n    \"htmlLabels\": true,\n    \"flowchart\": {\n      \"curve\": \"linear\"\n    },\n    \"sequence\": {\n      \"mirrorActors\": true\n    }\n  }\n}%%\n```\n\nYou can also define the directives in a single line, like this:\n\n```\n%%{init: { **insert configuration options here** } }%%\n```\n\nFor example, the following code snippet:\n\n```\n%%{init: { \"sequence\": { \"mirrorActors\":false }}}%%\n```\n\n**Notes:**\nThe JSON object that is passed as {**argument**} must be valid key value pairs and encased in quotation marks or it will be ignored.\nValid Key Value pairs can be found in config.\n\nExample with a simple graph:\n\n```mermaid-example\n%%{init: { 'logLevel': 'debug', 'theme': 'dark' } }%%\ngraph LR\nA-->B\n```\n\nHere the directive declaration will set the `logLevel` to `debug` and the `theme` to `dark` for a rendered mermaid diagram, changing the appearance of the diagram itself.\n\nNote: You can use 'init' or 'initialize' as both are acceptable as init directives. Also note that `%%init%%` and `%%initialize%%` directives will be grouped together after they are parsed.\n\n```mermaid-example\n%%{init: { 'logLevel': 'debug', 'theme': 'forest' } }%%\n%%{initialize: { 'logLevel': 'fatal', \"theme\":'dark', 'startOnLoad': true } }%%\n...\n```\n\nFor example, parsing the above generates a single `%%init%%` JSON object below, combining the two directives and carrying over the last value given for `loglevel`:\n\n```json\n{\n  \"logLevel\": \"fatal\",\n  \"theme\": \"dark\",\n  \"startOnLoad\": true\n}\n```\n\nThis will then be sent to `mermaid.initialize(...)` for rendering.\n\n## Directive Examples\n\nNow that the concept of directives has been explained, let us see some more examples of directive usage:\n\n### Changing theme via directive\n\nThe following code snippet changes `theme` to `forest`:\n\n`%%{init: { \"theme\": \"forest\" } }%%`\n\nPossible theme values are: `default`, `base`, `dark`, `forest` and `neutral`.\nDefault Value is `default`.\n\nExample:\n\n```mermaid-example\n%%{init: { \"theme\": \"forest\" } }%%\ngraph TD\nA(Forest) --> B[/Another/]\nA --> C[End]\n  subgraph section\n  B\n  C\n  end\n\n```\n\n### Changing fontFamily via directive\n\nThe following code snippet changes fontFamily to Trebuchet MS, Verdana, Arial, Sans-Serif:\n\n`%%{init: { \"fontFamily\": \"Trebuchet MS, Verdana, Arial, Sans-Serif\" } }%%`\n\nExample:\n\n```mermaid-example\n%%{init: { \"fontFamily\": \"Trebuchet MS, Verdana, Arial, Sans-Serif\" } }%%\ngraph TD\nA(Forest) --> B[/Another/]\nA --> C[End]\n  subgraph section\n  B\n  C\n  end\n\n```\n\n### Changing logLevel via directive\n\nThe following code snippet changes `logLevel` to `2`:\n\n`%%{init: { \"logLevel\": 2 } }%%`\n\nPossible `logLevel` values are:\n\n- `1` for _debug_,\n- `2` for _info_\n- `3` for _warn_\n- `4` for _error_\n- `5` for _only fatal errors_\n\nDefault Value is `5`.\n\nExample:\n\n```mermaid-example\n%%{init: { \"logLevel\": 2 } }%%\ngraph TD\nA(Forest) --> B[/Another/]\nA --> C[End]\n  subgraph section\n  B\n  C\n  end\n```\n\n### Changing flowchart config via directive\n\nSome common flowchart configurations are:\n\n- ~~_htmlLabels_~~: Deprecated, [prefer setting this at the root level](/config/schema-docs/config#htmllabels).\n- _curve_: linear/curve\n- _diagramPadding_: number\n- _useMaxWidth_: number\n\nFor a complete list of flowchart configurations, see [defaultConfig.ts](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/defaultConfig.ts) in the source code.\n_Soon we plan to publish a complete list of all diagram-specific configurations updated in the docs._\n\nThe following code snippet changes flowchart config:\n\n```\n%%{init: { \"htmlLabels\": true, \"flowchart\": { \"curve\": \"linear\" } } }%%\n```\n\nHere we are overriding only the flowchart config, and not the general config, setting `htmlLabels` to `true` and `curve` to `linear`.\n\n```warning\n**Deprecated:** `flowchart.htmlLabels` has been deprecated from (v11.12.3+). Use the global `htmlLabels` configuration instead. For example, instead of `\"flowchart\": { \"htmlLabels\": true }`, use `\"htmlLabels\": true` at the top level.\n```\n\n```mermaid-example\n%%{init: { \"flowchart\": { \"htmlLabels\": true, \"curve\": \"linear\" } } }%%\ngraph TD\nA(Forest) --> B[/Another/]\nA --> C[End]\n  subgraph section\n  B\n  C\n  end\n```\n\n### Changing Sequence diagram config via directive\n\nSome common sequence diagram configurations are:\n\n- _width_: number\n- _height_: number\n- _messageAlign_: left, center, right\n- _mirrorActors_: boolean\n- _useMaxWidth_: boolean\n- _rightAngles_: boolean\n- _showSequenceNumbers_: boolean\n- _wrap_: boolean\n\nFor a complete list of sequence diagram configurations, see [defaultConfig.ts](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/defaultConfig.ts) in the source code.\n_Soon we plan to publish a complete list of all diagram-specific configurations updated in the docs._\n\nSo, `wrap` by default has a value of `false` for sequence diagrams.\n\nLet us see an example:\n\n```mermaid-example\nsequenceDiagram\n\nAlice->Bob: Hello Bob, how are you?\nBob->Alice: Fine, how did your mother like the book I suggested? And did you catch the new book about alien invasion?\nAlice->Bob: Good.\nBob->Alice: Cool\n```\n\nNow let us enable wrap for sequence diagrams.\n\nThe following code snippet changes sequence diagram config for `wrap` to `true`:\n\n`%%{init: { \"sequence\": { \"wrap\": true} } }%%`\n\nBy applying that snippet to the diagram above, `wrap` will be enabled:\n\n```mermaid-example\n%%{init: { \"sequence\": { \"wrap\": true, \"width\":300 } } }%%\nsequenceDiagram\nAlice->Bob: Hello Bob, how are you?\nBob->Alice: Fine, how did your mother like the book I suggested? And did you catch the new book about alien invasion?\nAlice->Bob: Good.\nBob->Alice: Cool\n```\n","isInternal":false,"tokens":2130,"sizeBytes":8547},{"name":"faq.md","path":"packages/mermaid/src/docs/config/faq.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/config/faq.md","title":"Config Skill","category":"anthropic-skill","format":"markdown","content":"# Frequently Asked Questions\n\n1. [How to add title to flowchart?](https://github.com/mermaid-js/mermaid/issues/1433#issuecomment-1991554712)\n1. [How to specify custom CSS file?](https://github.com/mermaidjs/mermaid.cli/pull/24#issuecomment-373402785)\n1. [How to fix tooltip misplacement issue?](https://github.com/mermaid-js/mermaid/issues/542#issuecomment-3343564621)\n1. [How to specify gantt diagram xAxis format?](https://github.com/mermaid-js/mermaid/issues/269#issuecomment-373229136)\n1. [How to bind an event?](https://github.com/mermaid-js/mermaid/issues/372)\n1. [How to add newline in the text?](https://github.com/mermaid-js/mermaid/issues/384#issuecomment-281339381)\n1. [How to have special characters in link text?](https://github.com/mermaid-js/mermaid/issues/407#issuecomment-329944735)\n1. [How to change Flowchart curve style?](https://github.com/mermaid-js/mermaid/issues/580#issuecomment-373929046)\n1. [How to create a Flowchart end-Node that says \"End\"](https://github.com/mermaid-js/mermaid/issues/1444#issuecomment-639528897)\n","isInternal":false,"tokens":314,"sizeBytes":1045},{"name":"icons.md","path":"packages/mermaid/src/docs/config/icons.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/config/icons.md","title":"Config Skill","category":"anthropic-skill","format":"markdown","content":"# Registering icon pack in mermaid\n\nThe icon packs available can be found at [icones.js.org](https://icones.js.org/).\nWe use the name defined when registering the icon pack, to override the prefix field of the iconify pack. This allows the user to use shorter names for the icons. It also allows us to load a particular pack only when it is used in a diagram.\n\nUsing JSON file directly from CDN:\n\n```js\nimport mermaid from 'CDN/mermaid.esm.mjs';\nmermaid.registerIconPacks([\n  {\n    name: 'logos',\n    loader: () =>\n      fetch('https://unpkg.com/@iconify-json/logos@1/icons.json').then((res) => res.json()),\n  },\n]);\n```\n\nUsing packages and a bundler:\n\n```bash\nnpm install @iconify-json/logos@1\n```\n\nWith lazy loading\n\n```js\nimport mermaid from 'mermaid';\n\nmermaid.registerIconPacks([\n  {\n    name: 'logos',\n    loader: () => import('@iconify-json/logos').then((module) => module.icons),\n  },\n]);\n```\n\nWithout lazy loading\n\n```js\nimport mermaid from 'mermaid';\nimport { icons } from '@iconify-json/logos';\nmermaid.registerIconPacks([\n  {\n    name: icons.prefix, // To use the prefix defined in the icon pack\n    icons,\n  },\n]);\n```\n","isInternal":false,"tokens":302,"sizeBytes":1132},{"name":"layouts.md","path":"packages/mermaid/src/docs/config/layouts.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/config/layouts.md","title":"Config Skill","category":"anthropic-skill","format":"markdown","content":"# Layouts\n\nThis page lists the available layout algorithms supported in Mermaid diagrams.\n\n## ELK is bundled and default from v12.0.0\n\nBefore v12.0.0, ELK shipped as a separate `@mermaid-js/layout-elk` package that\neach site had to install and register. It is now part of `mermaid` itself and\nregistered automatically, so `layout: elk` works with no setup — and it is the\n**default**, replacing Dagre.\n\n`elk` is the new default layout for these diagrams:\n\n- Flowchart\n- State\n- Class\n- Entity relationship\n- Requirement\n- Use case\n- Agentflow\n\nTo go back to the previous layout, use `layout: dagre`.\n\nThe main `mermaid` package always includes ELK. If you want Mermaid without it,\nuse the [tiny build](./usage.md#elk-and-the-tiny-build), which omits ELK along\nwith some diagram types. `@mermaid-js/layout-elk` is still published so the tiny\nbuild can opt back in.\n\n## Supported Layouts\n\n- **elk** (default): [ELK (Eclipse Layout Kernel)](https://www.eclipse.org/elk/). Bundled with Mermaid; no setup required. Specific ELK algorithms can be selected as `elk.stress`, `elk.force`, `elk.mrtree`, `elk.sporeOverlap`, `elk.box`, and `elk.rectpacking`.\n- **dagre**: Dagre layout for layered graphs\n- **cose-bilkent**: Cose Bilkent layout for force-directed graphs\n- **tidy-tree**: Tidy tree layout for hierarchical diagrams, from the [`@mermaid-js/layout-tidy-tree`](https://www.npmjs.com/package/@mermaid-js/layout-tidy-tree) package [Tidy Tree Configuration](/config/tidy-tree)\n\nMindmaps are the one diagram type not laid out with ELK by default; they use\ncose-bilkent unless you ask for something else.\n\nThe **tiny** build omits ELK to stay small, and falls back to Dagre for\ndiagrams that request it. See\n[ELK and the tiny build](./usage.md#elk-and-the-tiny-build) for how to register\n`@mermaid-js/layout-elk` there if you want ELK anyway.\n\n## How to Use\n\nSince `elk` is the default, a diagram needs no configuration to use it. To pick\na different layout, set it in your diagram's YAML config or initialization\noptions. For example:\n\n```mermaid\n---\nconfig:\n  layout: dagre\n---\ngraph TD;\n  A-->B;\n  B-->C;\n```\n","isInternal":false,"tokens":580,"sizeBytes":2110},{"name":"math.md","path":"packages/mermaid/src/docs/config/math.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/config/math.md","title":"Config Skill","category":"anthropic-skill","format":"markdown","content":"# Math Configuration (v10.9.0+)\n\nMermaid supports rendering mathematical expressions through the [KaTeX](https://katex.org/) typesetter.\n\n## Usage\n\nTo render math within a diagram, surround the mathematical expression with the `$$` delimiter.\n\nNote that at the moment, the only supported diagrams are below:\n\n### Flowcharts\n\n```mermaid-example\n graph LR\n      A[\"$$x^2$$\"] -->|\"$$\\sqrt{x+3}$$\"| B(\"$$\\frac{1}{2}$$\")\n      A -->|\"$$\\overbrace{a+b+c}^{\\text{note}}$$\"| C(\"$$\\pi r^2$$\")\n      B --> D(\"$$x = \\begin{cases} a &\\text{if } b \\\\ c &\\text{if } d \\end{cases}$$\")\n      C --> E(\"$$x(t)=c_1\\begin{bmatrix}-\\cos{t}+\\sin{t}\\\\ 2\\cos{t} \\end{bmatrix}e^{2t}$$\")\n```\n\n### Sequence\n\n```mermaid-example\nsequenceDiagram\n    autonumber\n    participant 1 as $$\\alpha$$\n    participant 2 as $$\\beta$$\n    1->>2: Solve: $$\\sqrt{2+2}$$\n    2-->>1: Answer: $$2$$\n    Note right of 2: $$\\sqrt{2+2}=\\sqrt{4}=2$$\n```\n\n## Legacy Support\n\nBy default, MathML is used for rendering mathematical expressions. If you have users on [unsupported browsers](https://caniuse.com/?search=mathml), `legacyMathML` can be set in the config to fall back to CSS rendering. Note that **you must provide KaTeX's stylesheets on your own** as they do not come bundled with Mermaid.\n\nExample with legacy mode enabled (the latest version of KaTeX's stylesheet can be found on their [docs](https://katex.org/docs/browser.html)):\n\n```html\n\n\n\n  \n    \n    \n  \n\n  \n    \n  \n\n```\n\n## Handling Rendering Differences\n\nDue to differences between default fonts across operating systems and browser's MathML implementations, inconsistent results can be seen across platforms. If having consistent results are important, or the most optimal rendered results are desired, `forceLegacyMathML` can be enabled in the config.\n\nThis option will always use KaTeX's stylesheet instead of only when MathML is not supported (as with `legacyMathML`). Note that only `forceLegacyMathML` needs to be set.\n\nIf including KaTeX's stylesheet is not a concern, enabling this option is recommended to avoid scenarios where no MathML implementation within a browser provides the desired output (as seen below).\n\n![Image showing differences between Browsers](img/mathMLDifferences.png)\n","isInternal":false,"tokens":744,"sizeBytes":2803},{"name":"mermaidCLI.md","path":"packages/mermaid/src/docs/config/mermaidCLI.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/config/mermaidCLI.md","title":"Config Skill","category":"anthropic-skill","format":"markdown","content":"# mermaid CLI\n\nmermaid CLI has been moved to [mermaid-cli](https://github.com/mermaid-js/mermaid-cli). Please read its documentation instead.\n","isInternal":false,"tokens":36,"sizeBytes":142},{"name":"theming.md","path":"packages/mermaid/src/docs/config/theming.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/config/theming.md","title":"Config Skill","category":"anthropic-skill","format":"markdown","content":"# Theme Configuration\n\nDynamic and integrated theme configuration was introduced in Mermaid version 8.7.0.\n\nThemes can now be customized at the site-wide level, or on individual Mermaid diagrams. For site-wide theme customization, the `initialize` call is used. For diagram specific customization, frontmatter config is used.\n\n## Available Themes\n\n1.  [**redux-color**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-redux-color.js) - The default theme for the diagram types listed under [Per-diagram defaults](#per-diagram-defaults). It pairs the `redux` geometry and typography with a categorical colour palette, so entities, actors, branches, classes, subgraph containers and chart series each get their own colour.\n\n2.  [**redux-dark-color**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-redux-dark-color.js) - The dark counterpart of `redux-color`.\n\n3.  [**redux**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-redux.js) - The same geometry and typography as `redux-color`, but monochrome. Use this when you want the colour to carry meaning you assign yourself rather than being cycled per item.\n\n4.  [**redux-dark**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-redux-dark.js) - The dark counterpart of `redux`.\n\n5.  [**default**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-default.js) - The long-standing Mermaid look, and still the default for every diagram type not listed under [Per-diagram defaults](#per-diagram-defaults).\n\n6.  [**neutral**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-neutral.js) - This theme is great for black-and-white documents that will be printed.\n\n7.  [**dark**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-dark.js) - This theme goes well with dark-colored elements or dark-mode. To use the dark theme (which changes the theme of the schema itself) with dark-mode (which sets the background), set `darkMode` to `true` in your config.\n\n8.  [**forest**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-forest.js) - This theme contains shades of green.\n\n9.  [**neo**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-neo.js) - A flatter, softer look, intended to be paired with `look: neo`.\n\n10. [**neo-dark**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-neo-dark.js) - The dark counterpart of `neo`.\n\n11. [**base**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-base.js) - This is the only theme that can be modified. Use this theme as the base for customizations.\n\n## Per-diagram defaults\n\nNot every diagram type defaults to the same theme and look. Since v12.0.0\nthese do, to the `redux-color` theme and the `neo` look. The name on the left is the **config key** — what you write to\nscope a setting to that diagram, which is not always the keyword the diagram starts with:\n\n| Config key    | Diagram              |\n| ------------- | -------------------- |\n| `agentflow`   | `agentflow-beta`     |\n| `flowchart`   | `flowchart`          |\n| `swimlane`    | `swimlane-beta`      |\n| `class`       | `classDiagram`       |\n| `er`          | `erDiagram`          |\n| `requirement` | `requirementDiagram` |\n| `sequence`    | `sequenceDiagram`    |\n| `state`       | `stateDiagram`       |\n| `usecase`     | `usecase-beta`       |\n| `venn`        | `venn-beta`          |\n\nEvery other diagram type defaults to the `default` theme and the `classic` look.\n\n`layout` works the same way. Only `swimlane` overrides it, to `swimlane`; everything else\nuses the global default, `dagre`.\n\nThese are only defaults, and the most specific thing you say wins. Highest priority first:\n\n1.  The diagram's own frontmatter or `%%{init}%%` directive.\n2.  What you passed to `mermaid.initialize()`.\n3.  The diagram type's default, above.\n4.  The global default (`theme: default`, `look: classic`, `layout: dagre`).\n\nA layout that is not registered in the running build falls back to `dagre`, with a warning\nin the console. `elk` ships as a separate package you register yourself, and `cose-bilkent`\nis only bundled into builds that include the large features, so naming either as a default\ndoes not require every build to carry it.\n\nWithin each of the first two you can also scope a value to one diagram type, and the\nscoped value wins over the global one you set alongside it. `theme`, `look` and `layout`\ncan all be set this way:\n\n```javascript\nmermaid.initialize({\n  look: 'classic', // everything is classic...\n  flowchart: { look: 'handDrawn' }, // ...except flowcharts\n  er: { theme: 'neutral' },\n});\n```\n\nThe same works in frontmatter, for one diagram:\n\n```yaml\n---\nconfig:\n  flowchart:\n    look: handDrawn\n---\n```\n\n### Going back to the previous appearance\n\nThe nine types above changed appearance when these became their defaults. To draw one the\nway Mermaid drew it before, name the previous theme and look in its front matter:\n\n```yaml\n---\nconfig:\n  theme: default\n  look: classic\n---\n```\n\nFor every diagram on a page, pass the same two keys to `mermaid.initialize()`:\n\n```javascript\nmermaid.initialize({ theme: 'default', look: 'classic' });\n```\n\n## Site-wide Theme\n\nTo customize themes site-wide, call the `initialize` method on the `mermaid`.\n\nExample of `initialize` call setting `theme` to `base`:\n\n```javascript\nmermaid.initialize({\n  securityLevel: 'loose',\n  theme: 'base',\n});\n```\n\n## Diagram-specific Themes\n\nTo customize the theme of an individual diagram, use frontmatter config.\n\nExample of frontmatter config setting the `theme` to `forest`:\n\n```mermaid-example\n---\nconfig:\n  theme: 'forest'\n---\n  graph TD\n    a --> b\n```\n\n> **Reminder**: the only theme that can be customized is the `base` theme. The following section covers how to use `themeVariables` for customizations.\n\n## Customizing Themes with `themeVariables`\n\nTo make a custom theme, modify `themeVariables` via frontmatter config.\n\nYou will need to use the [base](#available-themes) theme as it is the only modifiable theme.\n\n| Parameter      | Description                        | Type   | Properties                                                                          |\n| -------------- | ---------------------------------- | ------ | ----------------------------------------------------------------------------------- |\n| themeVariables | Modifiable with frontmatter config | Object | `primaryColor`, `primaryTextColor`, `lineColor` ([see full list](#theme-variables)) |\n\nExample of modifying `themeVariables` using frontmatter config:\n\n```mermaid-example\n---\nconfig:\n  theme: 'base'\n  themeVariables:\n    primaryColor: '#BB2528'\n    primaryTextColor: '#fff'\n    primaryBorderColor: '#7C0000'\n    lineColor: '#F8B229'\n    secondaryColor: '#006100'\n    tertiaryColor: '#fff'\n---\n        graph TD\n          A[Christmas] -->|Get money| B(Go shopping)\n          B --> C{Let me think}\n          B --> G[/Another/]\n          C ==>|One| D[Laptop]\n          C -->|Two| E[iPhone]\n          C -->|Three| F[fa:fa-car Car]\n          subgraph section\n            C\n            D\n            E\n            F\n            G\n          end\n```\n\n## Color and Color Calculation\n\nTo ensure diagram readability, the default value of certain variables is calculated or derived from other variables. For example, `primaryBorderColor` is derived from the `primaryColor` variable. So if the `primaryColor` variable is customized, Mermaid will adjust `primaryBorderColor` automatically. Adjustments can mean a color inversion, a hue change, a darkening/lightening by 10%, etc.\n\nThe theming engine will only recognize hex colors and not color names. So, the value `#ff0000` will work, but `red` will not.\n\n## Theme Variables\n\n| Variable             | Default value                      | Description                                                                                                                      |\n| -------------------- | ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |\n| darkMode             | false                              | Affects how derived colors are calculated. Set value to `true` for dark mode.                                                    |\n| background           | #f4f4f4                            | Used to calculate color for items that should either be background colored or contrasting to the background                      |\n| fontFamily           | trebuchet ms, verdana, arial       | Font family for diagram text                                                                                                     |\n| fontSize             | 16px                               | Font size in pixels                                                                                                              |\n| primaryColor         | #fff4dd                            | Color to be used as background in nodes, other colors will be derived from this                                                  |\n| primaryTextColor     | calculated from darkMode #ddd/#333 | Color to be used as text color in nodes using `primaryColor`                                                                     |\n| secondaryColor       | calculated from primaryColor       |                                                                                                                                  |\n| primaryBorderColor   | calculated from primaryColor       | Color to be used as border in nodes using `primaryColor`                                                                         |\n| secondaryBorderColor | calculated from secondaryColor     | Color to be used as border in nodes using `secondaryColor`                                                                       |\n| secondaryTextColor   | calculated from secondaryColor     | Color to be used as text color in nodes using `secondaryColor`                                                                   |\n| tertiaryColor        | calculated from primaryColor       |                                                                                                                                  |\n| tertiaryBorderColor  | calculated from tertiaryColor      | Color to be used as border in nodes using `tertiaryColor`                                                                        |\n| tertiaryTextColor    | calculated from tertiaryColor      | Color to be used as text color in nodes using `tertiaryColor`                                                                    |\n| noteBkgColor         | #fff5ad                            | Color used as background in notes                                                                                                |\n| noteTextColor        | #333                               | Text color in note rectangles                                                                                                    |\n| noteBorderColor      | calculated from noteBkgColor       | Border color in note rectangles                                                                                                  |\n| lineColor            | calculated from background         |                                                                                                                                  |\n| textColor            | calculated from primaryTextColor   | Text in diagram over the background for instance text on labels and on signals in sequence diagram or the title in Gantt diagram |\n| mainBkg              | calculated from primaryColor       | Background in flowchart objects like rects/circles, class diagram classes, sequence diagram etc                                  |\n| errorBkgColor        | tertiaryColor                      | Color for syntax error message                                                                                                   |\n| errorTextColor       | tertiaryTextColor                  | Color for syntax error message                                                                                                   |\n\n## Flowchart Variables\n\n| Variable            | Default value                  | Description                 |\n| ------------------- | ------------------------------ | --------------------------- |\n| nodeBorder          | primaryBorderColor             | Node Border Color           |\n| clusterBkg          | tertiaryColor                  | Background in subgraphs     |\n| clusterBorder       | tertiaryBorderColor            | Cluster Border Color        |\n| defaultLinkColor    | lineColor                      | Link Color                  |\n| titleColor          | tertiaryTextColor              | Title Color                 |\n| edgeLabelBackground | calculated from secondaryColor |                             |\n| nodeTextColor       | primaryTextColor               | Color for text inside Nodes |\n\n## Sequence Diagram Variables\n\n| Variable              | Default value                  | Description                 |\n| --------------------- | ------------------------------ | --------------------------- |\n| actorBkg              | mainBkg                        | Actor Background Color      |\n| actorBorder           | primaryBorderColor             | Actor Border Color          |\n| actorTextColor        | primaryTextColor               | Actor Text Color            |\n| actorLineColor        | actorBorder                    | Actor Line Color            |\n| signalColor           | textColor                      | Signal Color                |\n| signalTextColor       | textColor                      | Signal Text Color           |\n| labelBoxBkgColor      | actorBkg                       | Label Box Background Color  |\n| labelBoxBorderColor   | actorBorder                    | Label Box Border Color      |\n| labelTextColor        | actorTextColor                 | Label Text Color            |\n| loopTextColor         | actorTextColor                 | Loop Text Color             |\n| activationBorderColor | calculated from secondaryColor | Activation Border Color     |\n| activationBkgColor    | secondaryColor                 | Activation Background Color |\n| sequenceNumberColor   | calculated from lineColor      | Sequence Number Color       |\n\n## Pie Diagram Variables\n\n| Variable            | Default value                  | Description                                |\n| ------------------- | ------------------------------ | ------------------------------------------ |\n| pie1                | primaryColor                   | Fill for 1st section in pie diagram        |\n| pie2                | secondaryColor                 | Fill for 2nd section in pie diagram        |\n| pie3                | calculated from tertiary       | Fill for 3rd section in pie diagram        |\n| pie4                | calculated from primaryColor   | Fill for 4th section in pie diagram        |\n| pie5                | calculated from secondaryColor | Fill for 5th section in pie diagram        |\n| pie6                | calculated from tertiaryColor  | Fill for 6th section in pie diagram        |\n| pie7                | calculated from primaryColor   | Fill for 7th section in pie diagram        |\n| pie8                | calculated from primaryColor   | Fill for 8th section in pie diagram        |\n| pie9                | calculated from primaryColor   | Fill for 9th section in pie diagram        |\n| pie10               | calculated from primaryColor   | Fill for 10th section in pie diagram       |\n| pie11               | calculated from primaryColor   | Fill for 11th section in pie diagram       |\n| pie12               | calculated from primaryColor   | Fill for 12th section in pie diagram       |\n| pieTitleTextSize    | 25px                           | Title text size                            |\n| pieTitleTextColor   | taskTextDarkColor              | Title text color                           |\n| pieSectionTextSize  | 17px                           | Text size of individual section labels     |\n| pieSectionTextColor | textColor                      | Text color of individual section labels    |\n| pieLegendTextSize   | 17px                           | Text size of labels in diagram legend      |\n| pieLegendTextColor  | taskTextDarkColor              | Text color of labels in diagram legend     |\n| pieStrokeColor      | black                          | Border color of individual pie sections    |\n| pieStrokeWidth      | 2px                            | Border width of individual pie sections    |\n| pieOuterStrokeWidth | 2px                            | Border width of pie diagram's outer circle |\n| pieOuterStrokeColor | black                          | Border color of pie diagram's outer circle |\n| pieOpacity          | 0.7                            | Opacity of individual pie sections         |\n\n## State Colors\n\n| Variable      | Default value    | Description                                  |\n| ------------- | ---------------- | -------------------------------------------- |\n| labelColor    | primaryTextColor |                                              |\n| altBackground | tertiaryColor    | Used for background in deep composite states |\n\n## Class Colors\n\n| Variable  | Default value | Description                     |\n| --------- | ------------- | ------------------------------- |\n| classText | textColor     | Color of Text in class diagrams |\n\n## User Journey Colors\n\n| Variable  | Default value                  | Description                             |\n| --------- | ------------------------------ | --------------------------------------- |\n| fillType0 | primaryColor                   | Fill for 1st section in journey diagram |\n| fillType1 | secondaryColor                 | Fill for 2nd section in journey diagram |\n| fillType2 | calculated from primaryColor   | Fill for 3rd section in journey diagram |\n| fillType3 | calculated from secondaryColor | Fill for 4th section in journey diagram |\n| fillType4 | calculated from primaryColor   | Fill for 5th section in journey diagram |\n| fillType5 | calculated from secondaryColor | Fill for 6th section in journey diagram |\n| fillType6 | calculated from primaryColor   | Fill for 7th section in journey diagram |\n| fillType7 | calculated from secondaryColor | Fill for 8th section in journey diagram |\n","isInternal":false,"tokens":3544,"sizeBytes":18613},{"name":"tidy-tree.md","path":"packages/mermaid/src/docs/config/tidy-tree.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/config/tidy-tree.md","title":"Config Skill","category":"anthropic-skill","format":"markdown","content":"# Tidy-tree Layout\n\nThe **tidy-tree** layout arranges nodes in a hierarchical, tree-like structure. It is especially useful for diagrams where parent-child relationships are important, such as mindmaps.\n\n## Features\n\n- Organizes nodes in a tidy, non-overlapping tree\n- Ideal for mindmaps and hierarchical data\n- Automatically adjusts spacing for readability\n\n## Example Usage\n\n```mermaid-example\n---\nconfig:\n  layout: tidy-tree\n---\nmindmap\nroot((mindmap is a long thing))\n  A\n  B\n  C\n  D\n```\n\n```mermaid-example\n---\nconfig:\n  layout: tidy-tree\n---\nmindmap\nroot((mindmap))\n    Origins\n      Long history\n      ::icon(fa fa-book)\n      Popularisation\n        British popular psychology author Tony Buzan\n    Research\n      On effectiveness
and features\n      On Automatic creation\n        Uses\n            Creative techniques\n            Strategic planning\n            Argument mapping\n```\n\n## Note\n\n- Currently, tidy-tree is primarily supported for mindmap diagrams.\n","isInternal":false,"tokens":220,"sizeBytes":970},{"name":"usage.md","path":"packages/mermaid/src/docs/config/usage.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/config/usage.md","title":"Config Skill","category":"anthropic-skill","format":"markdown","content":"# Usage\n\nMermaid is a JavaScript tool that makes use of a Markdown based syntax to render customizable diagrams, charts and visualizations.\n\nDiagrams can be re-rendered/modified by modifying their descriptions.\n\n### CDN\n\n[https://www.jsdelivr.com/package/npm/mermaid](https://www.jsdelivr.com/package/npm/mermaid)\n\nPlease note that you can switch versions through the dropdown box at the top right.\n\n## Using mermaid\n\nFor the majority of users, Using the [Live Editor](https://mermaid.live/) would be sufficient, however you may also opt to deploy mermaid as a dependency or using the [Mermaid API](./setup/README.md).\n\nWe have compiled some Video [Tutorials](../ecosystem/tutorials.md) on how to use the Mermaid Live Editor.\n\n### Installing and Hosting Mermaid on a Webpage\n\n**Using the npm package:**\n\nRequirements:\n\n- Node.js >= 22.12.0\n\n### Supported browsers and runtimes\n\nMermaid v12.0.0+'s published bundles target ES2024 and are aimed to support Safari 17.4 or later.\n\nWe run linting for Chromium 121 and Firefox 123 support as well, but unlike Safari 17.4, we don't commit to supporting these outdated versions.\n\nOlder browsers may work too, or you may need to polyfill/transpile mermaid to support them.\n\n```bash\n# NPM\nnpm install mermaid\n# Yarn\nyarn add mermaid\n# PNPM\npnpm add mermaid\n```\n\n**Hosting mermaid on a web page:**\n\n> Note: This topic is explored in greater depth in the [User Guide for Beginners](../intro/getting-started.md)\n\nThe easiest way to integrate mermaid on a web page requires two elements:\n\n- A graph definition, inside `
` tags labeled `class=mermaid`.\n\nExample:\n\n```html\n
\n    graph LR\n    A --- B\n    B-->C[fa:fa-ban forbidden]\n    B-->D(fa:fa-spinner);\n
\n```\n\n- The mermaid js script. Added using a `script` tag as an ESM import.\n\nExample:\n\n```html\n\n```\n\n**Following these directions, mermaid starts at page load and (when the page has loaded) it will locate the graph definitions inside the `pre` tags with `class=\"mermaid\"` and return diagrams in SVG form, following given definitions.**\n\n### Fonts\n\nMermaid currently uses a few different default `fontFamily` settings, based on\nthe diagram type and the given theme.\n\nThe current preferred fonts are:\n\n- Recursive Variable (open-source font, since v11.15.0)\n- Open Sans (open-source font)\n- Arial ([Restrictive License](https://en.wikipedia.org/wiki/TrueType_core_fonts_for_the_Web))\n- Trebuchet MS ([Restrictive License](https://en.wikipedia.org/wiki/TrueType_core_fonts_for_the_Web))\n\nFor a consistent look, we recommend you supply these as web fonts, when possible,\ne.g. like:\n\n```html\n/@fontsource/open-sans@5/400.css\" />\n/@fontsource/open-sans@5/400-italic.css\" />\n/@fontsource-variable/recursive@5/index.css\" />\n```\n\n## Simple full example:\n\n```html\n\n\n  /@fontsource/open-sans@5/400.css\" />\n  /@fontsource/open-sans@5/400-italic.css\" />\n  /@fontsource-variable/recursive@5/index.css\" />\n\n\n  \n    
\n  graph LR\n      A --- B\n      B-->C[fa:fa-ban forbidden]\n      B-->D(fa:fa-spinner);\n    
\n    \n  \n\n```\n\n## Notes:\n\nAn id attribute is also added to mermaid tags without one.\n\nMermaid can load multiple diagrams, in the same page.\n\n> Try it out, save this code as HTML and load it using any browser.\n> (Except Internet Explorer, please don't use Internet Explorer.)\n\n## Tiny Mermaid\n\nWe offer a smaller version of Mermaid that's approximately half the size of the full library. This tiny version doesn't include Mindmap Diagrams, Architecture Diagrams, KaTeX rendering, lazy loading, or the ELK layout engine.\n\nIf you need a more lightweight version without these features, you can use [Mermaid Tiny](https://github.com/mermaid-js/mermaid/tree/develop/packages/tiny).\n\n### ELK and the tiny build\n\nThe tiny build has never included ELK, and still doesn't — it is a large dependency and staying small is the point of that build. Diagrams that ask for an ELK layout here fall back to Dagre and still render; nothing breaks, they are simply laid out by Dagre.\n\nWhat changed in v12.0.0 is the main package, not this one: ELK used to be an opt-in `@mermaid-js/layout-elk` install, and is now bundled with `mermaid` and used by default. So **if you want a Mermaid without ELK, the tiny build is the way to get one** — it is no longer simply a matter of not installing the layout package.\n\nIf you want the tiny build _and_ ELK, register `@mermaid-js/layout-elk` alongside it. That package continues to be published for exactly this case:\n\n```html\n\n\n```\n\nRegistering the package also makes the named ELK algorithms available — `elk.stress`, `elk.force`, `elk.mrtree`, `elk.sporeOverlap`, `elk.box` and `elk.rectpacking`. On a normal `mermaid` build you do not need this package at all: registering it is harmless but redundant, since the same layouts are already built in.\n\n## Enabling Click Event and Tags in Nodes\n\nA `securityLevel` configuration has to first be cleared. `securityLevel` sets the level of trust for the parsed diagrams and limits click functionality. This was introduced in version 8.2 as a security improvement, aimed at preventing malicious use.\n\n**It is the site owner's responsibility to discriminate between trustworthy and untrustworthy user-bases and we encourage the use of discretion.**\n\n## securityLevel\n\n| Parameter     | Description                       | Type   | Required | Values                                     |\n| ------------- | --------------------------------- | ------ | -------- | ------------------------------------------ |\n| securityLevel | Level of trust for parsed diagram | String | Optional | 'sandbox', 'strict', 'loose', 'antiscript' |\n\nValues:\n\n- **strict**: (**default**) HTML tags in the text are encoded and click functionality is disabled.\n- **antiscript**: HTML tags in text are allowed (only script elements are removed) and click functionality is enabled.\n- **loose**: HTML tags in text are allowed and click functionality is enabled.\n- **sandbox**: With this security level, all rendering takes place in a sandboxed iframe. This prevents any JavaScript from running in the context. This may hinder interactive functionality of the diagram, like scripts, popups in the sequence diagram, links to other tabs or targets, etc.\n\n```note\nThis changes the default behaviour of mermaid so that after upgrade to 8.2, unless the `securityLevel` is not changed, tags in flowcharts are encoded as tags and clicking is disabled.\n**sandbox** security level is still in the beta version.\n```\n\n**If you are taking responsibility for the diagram source security you can set the `securityLevel` to a value of your choosing. This allows clicks and tags are allowed.**\n\n**To change `securityLevel`, you have to call `mermaid.initialize`:**\n\n```javascript\nmermaid.initialize({\n  securityLevel: 'loose',\n});\n```\n\n### Labels out of bounds\n\nIf you use dynamically loaded fonts that are loaded through CSS, such as fonts, mermaid should wait for the whole page to load (dom + assets, particularly the fonts file).\n\n```javascript\n$(document).ready(function () {\n  mermaid.initialize();\n});\n```\n\nNot doing so will most likely result in mermaid rendering graphs that have labels out of bounds. The default integration in mermaid uses the window.load event to start rendering.\n\nIf your page has other fonts in its body those might be used instead of the mermaid font. Specifying the font in your styling is a workaround for this.\n\n```css\npre.mermaid {\n  font-family: 'trebuchet ms', verdana, arial;\n}\n```\n\n### Using `mermaid.run`\n\nmermaid.run was added in v10 and is the preferred way of handling more complex integration.\nBy default, `mermaid.run` will be called when the document is ready, rendering all elements with `class=\"mermaid\"`.\n\nYou can customize that behavior by calling `await mermaid.run()`.\n\n`mermaid.initialize({startOnLoad: false})` will prevent `mermaid.run` from being called automatically after load.\n\nRender all elements with querySelector \".someOtherClass\"\n\n```js\nmermaid.initialize({ startOnLoad: false });\nawait mermaid.run({\n  querySelector: '.someOtherClass',\n});\n```\n\nRender all elements passed as an array\n\n```js\nmermaid.initialize({ startOnLoad: false });\nawait mermaid.run({\n  nodes: [document.getElementById('someId'), document.getElementById('anotherId')],\n});\nawait mermaid.run({\n  nodes: document.querySelectorAll('.yetAnotherClass'),\n});\n```\n\nRender all `.mermaid` elements while suppressing any error\n\n```js\nmermaid.initialize({ startOnLoad: false });\nawait mermaid.run({\n  suppressErrors: true,\n});\n```\n\n### Calling `mermaid.init` - Deprecated\n\n```warning\nmermaid.init is deprecated in v10 and will be removed in a future release. Please use mermaid.run instead.\n```\n\nBy default, `mermaid.init` will be called when the document is ready, finding all elements with\n`class=\"mermaid\"`. If you are adding content after mermaid is loaded, or otherwise need\nfiner-grained control of this behavior, you can call `init` yourself with:\n\n- a configuration object\n- some nodes, as\n  - a node\n  - an array-like of nodes\n  - or W3C selector that will find your nodes\n\nExample:\n\n```javascript\nmermaid.init({ noteMargin: 10 }, '.someOtherClass');\n```\n\nOr with no config object, and a jQuery selection:\n\n```javascript\nmermaid.init(undefined, $('#someId .yetAnotherClass'));\n```\n\n## Usage with webpack\n\nmermaid fully supports webpack. Here is a [working demo](https://github.com/mermaidjs/mermaid-webpack-demo).\n\n## API usage\n\nThe main idea of the API is to be able to call a render function with the graph definition as a string. The render function will render the graph and call a callback with the resulting SVG code. With this approach it is up to the site creator to fetch the graph definition from the site (perhaps from a textarea), render it and place the graph somewhere in the site.\n\nThe example below shows an example of how this could be used. The example just logs the resulting SVG to the JavaScript console.\n\n```html\n\n```\n\nTo determine the type of diagram present in a given text, you can utilize the `mermaid.detectType` function, as demonstrated in the example below.\n\n```html\n\n```\n\n### Binding events\n\nSometimes the generated graph also has defined interactions like tooltip and click events. When using the API one must\nadd those events after the graph has been inserted into the DOM.\n\nThe example code below is an extract of what mermaid does when using the API. The example shows how it is possible to\nbind events to an SVG when using the API for rendering.\n\n```javascript\n// Example of using the bindFunctions\nconst drawDiagram = async function () {\n  element = document.querySelector('#graphDiv');\n  const graphDefinition = 'graph TB\\na-->b';\n  const { svg, bindFunctions } = await mermaid.render('graphDiv', graphDefinition);\n  element.innerHTML = svg;\n  // This can also be written as `bindFunctions?.(element);` using the `?` shorthand.\n  if (bindFunctions) {\n    bindFunctions(element);\n  }\n};\n```\n\n1. The graph is generated using the render call.\n2. After generation the render function calls the provided callback function, in this case it's called insertSvg.\n3. The callback function is called with two parameters, the SVG code of the generated graph and a function. This function binds events to the SVG **after** it is inserted into the DOM.\n4. Insert the SVG code into the DOM for presentation.\n5. Call the binding function that binds the events.\n\n## Example of a marked renderer\n\nThis is the renderer used for transforming the documentation from Markdown to html with mermaid diagrams in the html.\n\n```javascript\nconst renderer = new marked.Renderer();\nrenderer.code = function (code, language) {\n  if (code.match(/^sequenceDiagram/) || code.match(/^graph/)) {\n    return '
' + code + '
';\n  } else {\n    return '
' + code + '
';\n  }\n};\n```\n\nAnother example in CoffeeScript that also includes the mermaid script tag in the generated markup.\n\n```coffee\nmarked = require 'marked'\n\nmodule.exports = (options) ->\n  hasMermaid = false\n  renderer = new marked.Renderer()\n  renderer.defaultCode = renderer.code\n  renderer.code = (code, language) ->\n    if language is 'mermaid'\n      html = ''\n      if not hasMermaid\n        hasMermaid = true\n        html += ''\n      html + '
'+code+'
'\n    else\n      @defaultCode(code, language)\n\n  renderer\n```\n\n## Advanced usage\n\n### Syntax validation without rendering\n\nThe `mermaid.parse(text, parseOptions)` function validates graph definitions without rendering a graph.\n\nThe function `mermaid.parse(text, parseOptions)`, takes a text string as an argument and returns `{ diagramType: string }` if the definition follows mermaid's syntax.\n\nIf the definition is invalid, the function returns `false` if `parseOptions.suppressErrors` is set to `true`. Otherwise, it throws an error.\n\nThe parseError function will be called when the parse function throws an error. It will not be called if `parseOptions.suppressErrors` is set to `true`.\n\nIt is possible to override this function in order to handle the error in an application-specific way.\n\nThe code-example below in meta code illustrates how this could work:\n\n```javascript\nmermaid.parseError = function (err, hash) {\n  displayErrorInGui(err);\n};\n\nconst textFieldUpdated = async function () {\n  const textStr = getTextFromFormField('code');\n\n  if (await mermaid.parse(textStr)) {\n    reRender(textStr);\n  }\n};\n\nbindEventHandler('change', 'code', textFieldUpdated);\n```\n\n## Configuration\n\nYou can pass the required configuration to the `mermaid.initialize` call. This is the preferred way of configuring mermaid.\nThe list of configuration objects are described [in the mermaidAPI documentation](./setup/README.md).\n\n```html\n\n```\n\n```note\nThis is the preferred way of configuring mermaid.\n```\n\n### The following methods are deprecated and are kept only for backwards compatibility.\n\n## Using the mermaid object\n\nIt is possible to set some configuration via the mermaid object. The two parameters that are supported using this\napproach are:\n\n- mermaid.startOnLoad\n- mermaid.htmlLabels\n\n```javascript\nmermaid.startOnLoad = true;\n```\n\n```warning\nThis way of setting the configuration is deprecated. Instead the preferred way is to use the initialize method. This functionality is only kept for backwards compatibility.\n```\n\n\n","isInternal":false,"tokens":3896,"sizeBytes":16462},{"name":"integrations-community.md","path":"packages/mermaid/src/docs/ecosystem/integrations-community.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/ecosystem/integrations-community.md","title":"Ecosystem Skill","category":"anthropic-skill","format":"markdown","content":"# Integrations\n\n## Official integration\n\n### Mermaid Chart\n\nMermaid Chart is built by the team behind Mermaid JS.\n\nFor more details, visit the [Mermaid Chart page](./mermaid-chart.md), or visit the [Mermaid Chart website](https://mermaid.ai) .\n\n## Community integrations\n\nWe're excited about the growth of the Mermaid community, and the number of plugins and integrations that have been created by the community.\n\nSee the list below of community plugins and integrations created with Mermaid.\n\n```note\nA ✅ indicates Native support for Mermaid on the respective platform.\n```\n\nTo add an integration to this list, see the [Integrations - create page](./integrations-create.md).\n\n### Productivity tools\n\n- [Atlassian Products](https://www.atlassian.com)\n  - [Mermaid for Confluence](https://marketplace.atlassian.com/apps/1224722/mermaid-for-confluence?hosting=cloud&tab=overview)\n  - [Mermaid Integration for Confluence](https://marketplace.atlassian.com/apps/1222792/mermaid-integration-for-confluence?hosting=cloud&tab=overview)\n  - [Mermaid Charts & Diagrams for Confluence](https://marketplace.atlassian.com/apps/1222572/)\n  - [Mermaid Diagrams for Confluence](https://marketplace.atlassian.com/apps/1226945/mermaid-diagrams-for-confluence?hosting=cloud&tab=overview)\n  - [Mermaid Live Editor for Confluence Cloud](https://marketplace.atlassian.com/apps/1231571/mermaid-live-editor-for-confluence?hosting=cloud&tab=overview)\n  - [Mermaid Macro for Confluence](https://marketplace.atlassian.com/apps/1231150/mermaid-macro-for-confluence?hosting=cloud&tab=overview)\n  - [Mermaid Plugin for Confluence](https://marketplace.atlassian.com/apps/1214124/mermaid-plugin-for-confluence?hosting=server&tab=overview)\n  - [EliteSoft Mermaid Charts and Diagrams](https://marketplace.atlassian.com/apps/1227286/elitesoft-mermaid-charts-and-diagrams?hosting=cloud&tab=overview)\n  - [Auto convert diagrams in Jira](https://github.com/coddingtonbear/jirafs-mermaid)\n  - [Mermaid Charts & Diagrams for Jira](https://marketplace.atlassian.com/apps/1224537/)\n  - [Mermaid for Jira Cloud - Draw UML diagrams easily](https://marketplace.atlassian.com/apps/1223053/mermaid-for-jira-cloud-draw-uml-diagrams-easily?hosting=cloud&tab=overview)\n  - [CloudScript.io Mermaid Addon](https://marketplace.atlassian.com/apps/1219878/cloudscript-io-mermaid-addon?hosting=cloud&tab=overview)\n  - [Mermaid plus for Confluence](https://marketplace.atlassian.com/apps/1236814/mermaid-plus-for-confluence?hosting=cloud&tab=overview)\n- [Azure Devops](https://learn.microsoft.com/en-us/azure/devops/project/wiki/markdown-guidance?view=azure-devops#add-mermaid-diagrams-to-a-wiki-page) ✅\n- [Deepdwn](https://billiam.itch.io/deepdwn) ✅\n- [Doctave](https://www.doctave.com/) ✅\n  - [Mermaid in Markdown code blocks](https://docs.doctave.com/components/mermaid) ✅\n- [Forgejo](https://forgejo.org/) ✅\n- [GitBook](https://gitbook.com)\n  - [Mermaid Plugin](https://github.com/JozoVilcek/gitbook-plugin-mermaid)\n  - [Markdown with Mermaid CLI](https://github.com/miao1007/gitbook-plugin-mermaid-cli)\n- [Gitea](https://gitea.io) ✅\n- [GitHub](https://github.com) ✅\n  - [Using code blocks](https://github.blog/2022-02-14-include-diagrams-markdown-files-mermaid/) ✅\n  - [GitHub action: Compile mermaid to image](https://github.com/neenjaw/compile-mermaid-markdown-action)\n  - [GitHub Writer](https://github.com/ckeditor/github-writer)\n  - [SVG diagram generator](https://github.com/SimonKenyonShepard/mermaidjs-github-svg-generator)\n- [GitLab](https://docs.gitlab.com/ee/user/markdown.html#diagrams-and-flowcharts) ✅\n- [GNU Octave](https://octave.org/) ✅\n  - [octave_mermaid_js](https://github.com/CNOCTAVE/octave_mermaid_js) ✅\n- [HackMD](https://hackmd.io/c/tutorials/%2F%40docs%2Fflowchart-en#Create-more-complex-flowcharts) ✅\n- [JetBrains IDEs](https://www.jetbrains.com)\n  - [Mermaid Plugin](https://plugins.jetbrains.com/plugin/20146-mermaid)\n  - [Mermaid Studio](https://plugins.jetbrains.com/plugin/29870-mermaid-studio)\n- [MonsterWriter](https://www.monsterwriter.com/) ✅\n- [Joplin](https://joplinapp.org) ✅\n- [LiveBook](https://livebook.dev) ✅\n- [Slidev](https://sli.dev) ✅\n- [Tuleap](https://docs.tuleap.org/user-guide/writing-in-tuleap.html#graphs) ✅\n- [Mermaid Flow Visual Editor](https://www.mermaidflow.app) ✅\n- [Mermaid Studio by webtoolz](https://webtoolz.dev/mermaid) - Browser-based Mermaid editor with live preview, curated themes, and PNG/SVG export\n- [Mermerd](https://github.com/KarnerTh/mermerd)\n- [Slab](https://slab.com) ✅\n- [Swimm](https://docs.swimm.io/features/diagrams-and-charts) ✅\n- [NotesHub](https://noteshub.app) ✅\n- [Notion](https://notion.so) ✅\n- [Observable](https://observablehq.com/@observablehq/mermaid) ✅\n- [Obsidian](https://help.obsidian.md/Editing+and+formatting/Advanced+formatting+syntax#Diagram) ✅\n- [Outline](https://docs.getoutline.com/s/guide/doc/diagrams-KQiKoT4wzK) ✅\n- [Redmine](https://redmine.org)\n  - [Mermaid Macro](https://redmine.org/plugins/redmine_mermaid_macro)\n  - [Markdown for mermaid plugin](https://github.com/jamieh-mongolian/markdown-for-mermaid-plugin)\n  - [redmine-mermaid](https://github.com/styz/redmine_mermaid)\n- Visual Studio Code [Polyglot Interactive Notebooks](https://github.com/dotnet/interactive#net-interactive)\n- [Microsoft Loop](https://loop.cloud.microsoft) ✅\n\n### LLM integrations\n\nLLM integrations to create mermaid diagrams using AI from text descriptions.\n\n- [HueHive - Create mermaid diagrams with text](https://huehive.co/tools/diagrams)\n- [MCP Server Mermaid](https://github.com/hustcc/mcp-mermaid) - Generate mermaid diagram and chart with AI MCP dynamically.\n- [Mermaid Studio](https://mermaidstudio.dev) - Leverage Mermaid Studio's code intelligence and diagram generation capabilities via MCP to create high-quality diagrams (requires a [JetBrains IDE](https://jetbrains.com/ides)) using your favorite coding agent.\n\n### CRM/ERP\n\nCustomer Relationship Management/Enterprise Resource Planning\n\n- [coreBOS](https://blog.corebos.org/blog/december2019)\n\n### Blogging\n\nBlogging frameworks and platforms\n\n- [Hexo](https://hexo.io)\n  - [hexo-filter-mermaid-diagrams](https://github.com/webappdevelp/hexo-filter-mermaid-diagrams)\n  - [hexo-tag-mermaid](https://github.com/JameChou/hexo-tag-mermaid)\n  - [hexo-mermaid-diagrams](https://github.com/mslxl/hexo-mermaid-diagrams)\n- [Nextra](https://nextra.site/)\n  - [Mermaid](https://nextra.site/docs/guide/mermaid)\n- [WordPress](https://wordpress.org)\n  - [MerPRess](https://wordpress.org/plugins/merpress/)\n  - [WP Documentation](https://wordpress.org/themes/wp-documentation/)\n\n### CMS/ECM\n\nContent Management Systems/Enterprise Content Management\n\n- [ApostropheCMS](https://apostrophecms.com/)\n  - [Extension for Mermaid.js](https://github.com/BoDonkey/mermaid-extension)\n- [Drupal](https://drupal.org/)\n  - [Mermaid Diagram Field module](https://www.drupal.org/project/mermaid_diagram_field)\n- [Grav CMS](https://getgrav.org/)\n  - [Mermaid Diagrams Plugin](https://github.com/DanielFlaum/grav-plugin-mermaid-diagrams)\n  - [GitLab Markdown Adapter](https://github.com/Goutte/grav-plugin-gitlab-markdown-adapter)\n- [Tiki Wiki CMS Groupware](https://tiki.org)\n  - [Tracker Entity Relationship Diagram](https://doc.tiki.org/Tracker-Entity-Relationship-Diagram)\n- [VitePress](https://vitepress.vuejs.org/)\n  - [Plugin for Mermaid.js](https://emersonbottero.github.io/vitepress-plugin-mermaid/)\n- [VuePress](https://vuepress.vuejs.org/)\n  - [Plugin for Mermaid.js](https://github.com/eFrane/vuepress-plugin-mermaidjs)\n\n### Communication\n\nCommunication tools and platforms\n\n- [Discourse](https://discourse.org)\n  - [Mermaid Plugin](https://github.com/pnewell/discourse-mermaid)\n- [Mattermost](https://mattermost.com/)\n  - [Mermaid Plugin](https://github.com/SpikeTings/Mermaid)\n- [NodeBB](https://nodebb.org)\n  - [Mermaid Parser Plugin](https://www.npmjs.com/package/nodebb-plugin-mermaid)\n- [phpBB](https://phpbb.com)\n  - [phpbb-ext-mermaid](https://github.com/AlfredoRamos/phpbb-ext-mermaid)\n- [Slack](https://slack.com)\n  - [Mermaid Preview](https://mermaid-preview.com)\n\n### Wikis\n\n- [DokuWiki](https://dokuwiki.org)\n  - [ComboStrap](https://combostrap.com/utility/create-diagram-with-mermaid-vh3ab9yj)\n  - [Mermaid Plugin](https://www.dokuwiki.org/plugin:mermaid)\n- [Foswiki](https://foswiki.org)\n  - [Mermaid Plugin](https://foswiki.org/Extensions/MermaidPlugin)\n- [MediaWiki](https://www.mediawiki.org)\n  - [Flex Diagrams Extension](https://www.mediawiki.org/wiki/Extension:Flex_Diagrams)\n  - [Mermaid Extension](https://www.mediawiki.org/wiki/Extension:Mermaid)\n- [PmWiki](https://www.pmwiki.org)\n  - [MermaidJs Cookbook recipe](https://www.pmwiki.org/wiki/Cookbook/MermaidJs)\n- [Semantic Media Wiki](https://www.semantic-mediawiki.org)\n  - [Mermaid Plugin](https://github.com/SemanticMediaWiki/Mermaid)\n- [TiddlyWiki](https://tiddlywiki.com/)\n  - [mermaid-tw5: wrapper for Mermaid Live](https://github.com/efurlanm/mermaid-tw5)\n  - [tw5-mermaid: plugin for managing Mermaid.js tiddlers](https://github.com/jasonmhoule/tw5-mermaid)\n\n### Editor Plugins\n\n- Atom _(Atom has been [archived.](https://github.blog/2022-06-08-sunsetting-atom/))_\n  - [Markdown Preview Enhanced](https://github.com/shd101wyy/markdown-preview-enhanced)\n  - [Atom Mermaid](https://github.com/y-takey/atom-mermaid)\n  - [Language Mermaid Syntax Highlighter](https://github.com/ytisf/language-mermaid)\n- [Astah](https://astah.net)\n  - [Export to Mermaid](https://github.com/Avens666/Astah_Jude_UML_export_to_Markdown-mermaid-Plantuml-)\n- [Brackets](https://brackets.io/)\n  - [Mermaid Preview](https://github.com/AlanHohn/mermaid-preview)\n- [CKEditor](https://github.com/ckeditor/ckeditor5)\n  - [CKEditor 5 Mermaid plugin](https://github.com/ckeditor/ckeditor5-mermaid)\n- [Draw.io](https://draw.io)\n  - [Mermaid Plugin](https://github.com/nopeslide/drawio_mermaid_plugin)\n- [GNU Emacs](https://www.gnu.org/software/emacs/)\n  - [Major mode for .mmd files](https://github.com/abrochard/mermaid-mode)\n  - [Org-Mode integration](https://github.com/arnm/ob-mermaid)\n- [GNU Nano](https://www.nano-editor.org/)\n  - [Nano Mermaid](https://github.com/Yash-Singh1/nano-mermaid)\n- [Google docs](https://docs.google.com/)\n  - [Mermaid plugin for google docs](https://workspace.google.com/marketplace/app/mermaid/636321283856)\n- [Inkdrop](https://www.inkdrop.app)\n  - [Mermaid Plugin](https://github.com/inkdropapp/inkdrop-mermaid)\n- [IntelliJ Idea](https://www.jetbrains.com/idea/)\n  - [Mermaid Visualizer](https://plugins.jetbrains.com/plugin/30432-mermaid-visualizer)\n- [Light Table](http://lighttable.com/)\n  - [Mermaid Plugin](https://github.com/cldwalker/Mermaid)\n- [Markdown-It](https://github.com/markdown-it/markdown-it)\n  - [Textual UML Parser](https://github.com/manastalukdar/markdown-it-textual-uml)\n  - [Mermaid Plugin](https://github.com/tylingsoft/markdown-it-mermaid)\n  - [md-it-mermaid](https://github.com/iamcco/md-it-mermaid)\n  - [markdown-it-mermaid-less](https://github.com/searKing/markdown-it-mermaid-less)\n- [Podlite](https://github.com/zag/podlite-desktop)\n  - [=Diagram block](https://github.com/zag/podlite/tree/main/packages/podlite-diagrams)\n- [Standard Notes](https://standardnotes.com/)\n  - [Mermaid Extension](https://github.com/nienow/sn-mermaid)\n- [VS Code](https://code.visualstudio.com/)\n  - [Mermaid Editor](https://marketplace.visualstudio.com/items?itemName=tomoyukim.vscode-mermaid-editor)\n  - [Mermaid Export](https://marketplace.visualstudio.com/items?itemName=Gruntfuggly.mermaid-export)\n  - [Markdown PDF](https://marketplace.visualstudio.com/items?itemName=yzane.markdown-pdf)\n  - [Markdown Preview Mermaid Support](https://marketplace.visualstudio.com/items?itemName=bierner.markdown-mermaid)\n  - [Markdown Preview Enhanced](https://marketplace.visualstudio.com/items?itemName=shd101wyy.markdown-preview-enhanced)\n  - [Mermaid Preview](https://marketplace.visualstudio.com/items?itemName=vstirbu.vscode-mermaid-preview)\n  - [Preview](https://marketplace.visualstudio.com/items?itemName=searKing.preview-vscode)\n  - [Preview Sequence Diagrams](https://marketplace.visualstudio.com/items?itemName=arichika.previewseqdiag-vscode)\n  - [Mermaid Markdown Syntax Highlighting](https://marketplace.visualstudio.com/items?itemName=bpruitt-goddard.mermaid-markdown-syntax-highlighting)\n- [Vim](https://www.vim.org)\n  - [Vim Diagram Syntax](https://github.com/zhaozg/vim-diagram)\n  - [Official Vim Syntax and ft plugin](https://github.com/craigmac/vim-mermaid)\n- [Zed](https://zed.dev)\n  - [zed-mermaid](https://github.com/gabeidx/zed-mermaid)\n\n### Document Generation\n\n- [Astro](https://astro.build/)\n  - [Adding diagrams to your Astro site with MermaidJS and Playwright](https://agramont.net/blog/diagraming-with-mermaidjs-astro/)\n- [Codedoc](https://codedoc.cc/)\n  - [codedoc-mermaid-plugin](https://www.npmjs.com/package/codedoc-mermaid-plugin)\n- [Docsy Hugo Theme](https://www.docsy.dev/docs/content/diagrams-and-formulae/) ✅\n- [Docusaurus](https://docusaurus.io/docs/markdown-features/diagrams) ✅\n- [Gatsby](https://www.gatsbyjs.com/)\n  - [gatsby-remark-mermaid](https://github.com/remcohaszing/gatsby-remark-mermaid)\n- [Jekyll](https://jekyllrb.com/)\n  - [jekyll-mermaid](https://rubygems.org/gems/jekyll-mermaid)\n  - [jekyll-mermaid-diagrams](https://github.com/fuzhibo/jekyll-mermaid-diagrams)\n- [JSDoc](https://jsdoc.app/)\n  - [jsdoc-mermaid](https://github.com/Jellyvision/jsdoc-mermaid)\n- [Madness](https://madness.dannyb.co/)\n- [mdBook](https://rust-lang.github.io/mdBook/index.html)\n  - [mdbook-mermaid](https://github.com/badboy/mdbook-mermaid)\n- [MkDocs](https://www.mkdocs.org)\n  - [mkdocs-mermaid2-plugin](https://github.com/fralau/mkdocs-mermaid2-plugin)\n  - [mkdocs-material](https://github.com/squidfunk/mkdocs-material), check the [docs](https://squidfunk.github.io/mkdocs-material/reference/diagrams/)\n- [Quarto](https://quarto.org/) ✅\n- [rehype](https://github.com/rehypejs/rehype)\n  - [rehype-mermaid](https://github.com/remcohaszing/rehype-mermaid)\n- [remark](https://remark.js.org/)\n  - [remark-mermaidjs](https://github.com/remcohaszing/remark-mermaidjs)\n- [Sphinx](https://www.sphinx-doc.org/en/master/)\n  - [sphinxcontrib-mermaid](https://github.com/mgaitan/sphinxcontrib-mermaid)\n- [Type Doc](https://typedoc.org/)\n  - [typedoc-plugin-mermaid](https://www.npmjs.com/package/typedoc-plugin-mermaid)\n- [Typora](https://support.typora.io/Draw-Diagrams-With-Markdown/#mermaid) ✅\n- [Unison programming language](https://www.unison-lang.org/docs/usage-topics/documentation/) ✅\n\n### Browser Extensions\n\n| Name                     | Chrome Web Store                                                                                            | Firefox Add-ons                                                                | Opera                                                                          | Edge                                                                                                                         | Source/Repository                                                                                    |\n| ------------------------ | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |\n| GitHub + Mermaid         | -                                                                                                           | [🦊🔗](https://addons.mozilla.org/firefox/addon/github-mermaid/)               | -                                                                              | -                                                                                                                            | [🐙🔗](https://github.com/BackMarket/github-mermaid-extension)                                       |\n| Asciidoctor Live Preview | [🎡🔗](https://chromewebstore.google.com/detail/asciidoctorjs-live-previe/iaalpfgpbocpdfblpnhhgllgbdbchmia) | -                                                                              | -                                                                              | [🌀🔗](https://microsoftedge.microsoft.com/addons/detail/asciidoctorjs-live-previ/pefkelkanablhjdekgdahplkccnbdggd?hl=en-US) | -                                                                                                    |\n| Diagram Tab              | -                                                                                                           | -                                                                              | -                                                                              | -                                                                                                                            | [🐙🔗](https://github.com/khafast/diagramtab)                                                        |\n| Markdown Diagrams        | [🎡🔗](https://chromewebstore.google.com/detail/markdown-diagrams/pmoglnmodacnbbofbgcagndelmgaclel)         | [🦊🔗](https://addons.mozilla.org/en-US/firefox/addon/markdown-diagrams/)      | -                                                                              | [🌀🔗](https://microsoftedge.microsoft.com/addons/detail/markdown-diagrams/hceenoomhhdkjjijnmlclkpenkapfihe)                 | [🐙🔗](https://github.com/marcozaccari/markdown-diagrams-browser-extension/tree/master/doc/examples) |\n| Markdown Viewer          | -                                                                                                           | [🦊🔗](https://addons.mozilla.org/en-US/firefox/addon/markdown-viewer-chrome/) | -                                                                              | -                                                                                                                            | [🐙🔗](https://github.com/simov/markdown-viewer)                                                     |\n| Extensions for Mermaid   | -                                                                                                           | -                                                                              | [🔴🔗](https://addons.opera.com/en/extensions/details/extensions-for-mermaid/) | -                                                                                                                            | [🐙🔗](https://github.com/Stefan-S/mermaid-extension)                                                |\n| Chrome Diagrammer        | [🎡🔗](https://chromewebstore.google.com/detail/chrome-diagrammer/bkpbgjmkomfoakfklcjeoegkklgjnnpk)         | -                                                                              | -                                                                              | -                                                                                                                            | -                                                                                                    |\n| Mermaid Diagrams         | [🎡🔗](https://chromewebstore.google.com/detail/mermaid-diagrams/phfcghedmopjadpojhmmaffjmfiakfil)          | -                                                                              | -                                                                              | -                                                                                                                            | -                                                                                                    |\n| Monkeys                  | [🎡🔗](https://chromewebstore.google.com/detail/monkeys-mermaid-for-githu/cplfdpoajbclbgphaphphcldamfkjlgi) | -                                                                              | -                                                                              | -                                                                                                                            | -                                                                                                    |\n| Mermaid Previewer        | [🎡🔗](https://chromewebstore.google.com/detail/mermaid-previewer/oidjnlhbegipkcklbdfnbkikplpghfdl)         | -                                                                              | -                                                                              | -                                                                                                                            | -                                                                                                    |\n| Tachi Code               | [🎡🔗](https://chromewebstore.google.com/detail/tachi-code/acoecgiamdjjkhmdodcfdfanfnagamjf)                | [🦊🔗](https://addons.mozilla.org/en-US/firefox/addon/tachi-code/)             | -                                                                              | [🌀🔗](https://microsoftedge.microsoft.com/addons/detail/tachi-code/mombmlijgpfamkenkmggobjimompbpji)                        | -                                                                                                    |\n\n### Other\n\n- [Bisheng](https://www.npmjs.com/package/bisheng)\n  - [bisheng-plugin-mermaid](https://github.com/yct21/bisheng-plugin-mermaid)\n- [Blazorade Mermaid: Render Mermaid diagrams in Blazor applications](https://github.com/Blazorade/Blazorade-Mermaid/wiki)\n- [Codemia: A tool to practice system design problems](https://codemia.io) ✅\n- [ExDoc](https://github.com/elixir-lang/ex_doc)\n  - [Rendering Mermaid graphs](https://github.com/elixir-lang/ex_doc#rendering-mermaid-graphs)\n- [MarkChart: Preview Mermaid diagrams on macOS](https://markchart.app/)\n- [mermaid-isomorphic](https://github.com/remcohaszing/mermaid-isomorphic)\n- [mermaid-server: Generate diagrams using a HTTP request](https://github.com/TomWright/mermaid-server)\n- [NiceGUI: Let any browser be the frontend of your Python code](https://nicegui.io) ✅\n  - [ui.mermaid(...)](https://nicegui.io/documentation/mermaid)\n- [Reveal.js](https://github.com/hakimel/reveal.js)\n  - [reveal.js-mermaid-plugin](https://github.com/ludwick/reveal.js-mermaid-plugin)\n- [Reveal CK](https://github.com/jedcn/reveal-ck)\n  - [reveal-ck-mermaid-plugin](https://github.com/tmtm/reveal-ck-mermaid-plugin)\n- [SchemaCrawler - Generate Mermaid diagrams from your database](https://dev.to/sualeh/how-to-generate-mermaid-diagrams-for-your-database-33bn)\n- [Schema3D](https://schema3d.com) - Browser-only 3D visualizer for Mermaid ER diagrams (also SQL / DrawDB); shareable URL, no live DB\n- [speccharts: Turn your test suites into specification diagrams](https://github.com/arnaudrenaud/speccharts)\n- [termaid: Render Mermaid diagrams as Unicode art in the terminal](https://github.com/fasouto/termaid)\n- [Vitepress Plugin](https://github.com/sametcn99/vitepress-mermaid-renderer)\n\n\n","isInternal":false,"tokens":5710,"sizeBytes":23329},{"name":"integrations-create.md","path":"packages/mermaid/src/docs/ecosystem/integrations-create.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/ecosystem/integrations-create.md","title":"Ecosystem Skill","category":"anthropic-skill","format":"markdown","content":"# Integrations - create\n\n## Recommendations\n\nBelow are recommendations for creating plugins and integrations with Mermaid.\n\n### File Extension\n\nApplications that support Mermaid files [SHOULD](https://datatracker.ietf.org/doc/html/rfc2119#section-3) use `.mermaid` or `.mmd` file extensions.\n\n### MIME Type\n\nThe recommended [MIME type](https://www.iana.org/assignments/media-types/media-types.xhtml) for Mermaid media is [`text/vnd.mermaid`](https://www.iana.org/assignments/media-types/application/vnd.mermaid).\n\n## Showcase\n\n### Mermaid Discord workspace\n\nWe would love to see what you create with Mermaid. Please share your creations with us in our [Discord](https://discord.gg/sKeNQX4Wtj) server [#showcase](https://discord.com/channels/1079455296289788015/1079502635054399649) channel.\n\n### Add to Mermaid Ecosystem\n\nIf you have a plugin or integration that you'd like to add to our [Community integrations](/ecosystem/integrations-community) list, please [open a pull request](https://github.com/mermaid-js/mermaid).\n","isInternal":false,"tokens":255,"sizeBytes":1023},{"name":"mermaid-chart.md","path":"packages/mermaid/src/docs/ecosystem/mermaid-chart.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/ecosystem/mermaid-chart.md","title":"Ecosystem Skill","category":"anthropic-skill","format":"markdown","content":"# Mermaid Chart\n\nThe Future of Diagramming & Visual Collaboration\n\nTry the Ultimate AI, Mermaid, and Visual Diagramming Suite by creating an account at [Mermaid Chart](https://mermaid.ai/app/sign-up).\n\n
\n\n\"Mermaid Chart\n\n## About\n\n[Mermaid Chart](https://mermaid.ai) was born out of the Mermaid open source project and was founded by Knut Sveidqvist together with Open Core Ventures. The lead developers from Mermaid have joined the company and there is a strong connection between the project we all love and Mermaid Chart. Mermaid Chart brings resources to the open source development of Mermaid and makes it possible to work with Mermaid professionally.\n\n## Features\n\n- **Editor** - A web based editor for creating and editing Mermaid diagrams.\n\n- **Mermaid AI** - Use our embedded AI Chat to generate diagrams from natural language descriptions.\n\n- **Whiteboard** - A virtual whiteboard for creating and editing Mermaid diagrams.\n\n- **Plugins** - A plugin system for extending the functionality of Mermaid.\n\n  Official Mermaid Chart plugins:\n  - [Mermaid Chart GPT](https://chatgpt.com/g/g-684cc36f30208191b21383b88650a45d-mermaid-chart-diagrams-and-charts)\n  - [Confluence](https://marketplace.atlassian.com/apps/1234056/mermaid-chart-for-confluence?hosting=cloud&tab=overview)\n  - [Jira](https://marketplace.atlassian.com/apps/1234810/mermaid-chart-for-jira?tab=overview&hosting=cloud)\n  - [Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=MermaidChart.vscode-mermaid-chart)\n  - [JetBrains IDE](https://plugins.jetbrains.com/plugin/23043-mermaid-chart)\n  - [Google Docs](https://gsuite.google.com/marketplace/app/mermaidchart/947683068472)\n  - [Microsoft PowerPoint and Word](https://appsource.microsoft.com/en-us/product/office/WA200006214?tab=Overview)\n\n  Visit our [Plugins](https://mermaid.ai/plugins) page for more information.\n\n- **Collaboration** - A web based collaboration feature for multi-user editing on Mermaid diagrams in real-time (Pro and Enterprise plans).\n\n- **Comments** - Enhance collaboration by adding comments to diagrams.\n\n- **Presentations** - A presentation mode for viewing Mermaid diagrams in a slideshow format.\n\n## Plans\n\n- **Basic** - A free plan that includes three diagrams and limited AI usage.\n\n- **Plus** - A paid plan that includes unlimited diagrams, scalable AI usage, and centralized billing for small teams.\n\n- **Premium** - A paid plan for larger teams that need massive AI or diagram usage along with team collaboration, knowledge management, and security features like SSO.\n\n- **Enterprise** - A paid plan for enterprise use that includes all Premium features, custom contracts, support, and more.\n\nTo learn more, visit our [Pricing](https://mermaid.ai/pricing) page.\n\nSign up for a free account on the [Mermaid](https://mermaid.ai/app/sign-up) website and trial paid features at any time for 7 days free.\n\n## Mermaid JS contributions\n\nFirst time contributors are eligible for a free Premium tier account for 1 year.\n","isInternal":false,"tokens":835,"sizeBytes":3410},{"name":"tutorials.md","path":"packages/mermaid/src/docs/ecosystem/tutorials.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/ecosystem/tutorials.md","title":"Ecosystem Skill","category":"anthropic-skill","format":"markdown","content":"# Tutorials\n\nThis is a list of publicly available Tutorials for using Mermaid.JS and is intended as a basic introduction for the use of the Live Editor for generating diagrams, and deploying Mermaid.JS through HTML.\n\n**Note that these tutorials might display an older interface, but the usage of the live-editor will largely be the same.**\n\nFor most purposes, you can use the [Live Editor](https://mermaid.live), to quickly and easily render a diagram.\n\n## Live-Editor Tutorials\n\nThe definitions that can be generated the Live-Editor are also backwards-compatible as of version 8.7.0.\n\n[Chris Chinchilla: Hands on - Text-based diagrams with Mermaid](https://www.youtube.com/watch?v=4_LdV1cs2sA)\n\n[GitLab Unfiltered: How to Create Mermaid Diagrams](https://www.youtube.com/watch?v=SQ9QmuTHuSI&t=438s)\n\n[GitLab Unfiltered: Emilie adds a mermaid diagram to the handbook](https://www.youtube.com/watch?v=5RQqht3NNSE)\n\n[World of Zero: I Learn How To Build Flowcharts and Signal Diagram's in Mermaid.JS](https://www.youtube.com/watch?v=7_2IroEs6Is&t=207s)\n\n[Eddie Jaoude: Can you code your diagrams?](https://www.youtube.com/watch?v=9HZzKkAqrX8)\n\n## Mermaid with OpenAI\n\n[Elle Neal: Mind Mapping with AI: An Accessible Approach for Neurodiverse Learners Tutorial:](https://medium.com/@elle.neal_71064/mind-mapping-with-ai-an-accessible-approach-for-neurodiverse-learners-1a74767359ff)\n\n## Mermaid with HTML\n\nExamples are provided in [Getting Started](../intro/getting-started.md)\n\n**CodePen Examples:**\n\nhttps://codepen.io/CarlBoneri/pen/BQwZzq\n\nhttps://codepen.io/tdkn/pen/vZxQzd\n\nhttps://codepen.io/janzeteachesit/pen/OWWZKN\n\n## Mermaid with Text Area\n\nhttps://codepen.io/Ryuno-Ki/pen/LNxwgR\n\n## Mermaid in open source docs\n\n[K8s.io Diagram Guide](https://kubernetes.io/docs/contribute/style/diagram-guide/)\n\n[K8s.dev blog: Improve your documentation with Mermaid.js diagrams](https://www.kubernetes.dev/blog/2021/12/01/improve-your-documentation-with-mermaid.js-diagrams/)\n\n## Jupyter / Python Integration with mermaid-js\n\nHere's an example of Python integration with mermaid-js which uses the mermaid.ink service, that displays the graph in a Jupyter notebook and save it as _.png_ image with the stated resolution (in this example, `dpi=1200`).\n\n```python\nimport base64\nimport io, requests\nfrom IPython.display import Image, display\nfrom PIL import Image as im\nimport matplotlib.pyplot as plt\n\ndef mm(graph):\n    graphbytes = graph.encode(\"utf8\")\n    base64_bytes = base64.urlsafe_b64encode(graphbytes)\n    base64_string = base64_bytes.decode(\"ascii\")\n    img = im.open(io.BytesIO(requests.get('https://mermaid.ink/img/' + base64_string).content))\n    plt.imshow(img)\n    plt.axis('off') # allow to hide axis\n    plt.savefig('image.png', dpi=1200)\n\nmm(\"\"\"\ngraph LR;\n    A--> B & C & D\n    B--> A & E\n    C--> A & E\n    D--> A & E\n    E--> B & C & D\n\"\"\")\n```\n\n**Output**\n\n![Example graph of the Python integration](img/python-mermaid-integration.png)\n\n\n","isInternal":false,"tokens":837,"sizeBytes":3026},{"name":"index.md","path":"packages/mermaid/src/docs/index.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/index.md","title":"Docs Skill","category":"anthropic-skill","format":"markdown","content":"---\nlayout: home\nsidebar: false\n\ntitle: Mermaid\ntitleTemplate: Diagramming and charting tool\nhero:\n  name: Mermaid.js now lives\n  text: at mermaid.ai\n  tagline: One home for the open-source library and the platform built around it. More resources for the project, a clearer path for contributors, and a team committed to keeping Mermaid open, always.\n\n  image:\n    light: /hero-chart.svg\n    dark: /hero-chart-dark.svg\n    alt: Mermaid diagram\n  actions:\n    - theme: brand\n      text: Try Editor\n      link: https://mermaid.live/edit\n      target: _blank\n      rel: external\n    - theme: alt\n      text: Get started\n      link: https://mermaid.ai/open-source/intro/\n\nfeatures:\n  - icon:\n      src: /1-Callout-Easy.svg\n    title: Easy to use\n    details: Easily create diagrams and charts with the Mermaid Live Editor.\n    link: https://mermaid.live/\n  - icon:\n      src: /2-Callout-Integrations.svg\n    title: Integrations available\n    details: Use Mermaid with your favorite applications, check out the integrations list.\n    link: ../../ecosystem/integrations-community.md\n  - icon:\n      src: /3-Callout-Awards.svg\n    title: Award winning\n    details: 2019 JavaScript Open Source Award winner for \"The Most Exciting Use of Technology\".\n    link: https://osawards.com/javascript/2019\n---\n","frontmatter":{"layout":"home","sidebar":false,"title":"Mermaid","titleTemplate":"Diagramming and charting tool","hero":{"name":"Mermaid.js now lives","text":"at mermaid.ai","tagline":"One home for the open-source library and the platform built around it. More resources for the project, a clearer path for contributors, and a team committed to keeping Mermaid open, always.","image":{"light":"/hero-chart.svg","dark":"/hero-chart-dark.svg","alt":"Mermaid diagram"},"actions":[{"theme":"brand","text":"Try Editor","link":"https://mermaid.live/edit","target":"_blank","rel":"external"},{"theme":"alt","text":"Get started","link":"https://mermaid.ai/open-source/intro/"}]},"features":[{"icon":{"src":"/1-Callout-Easy.svg"},"title":"Easy to use","details":"Easily create diagrams and charts with the Mermaid Live Editor.","link":"https://mermaid.live/"},{"icon":{"src":"/2-Callout-Integrations.svg"},"title":"Integrations available","details":"Use Mermaid with your favorite applications, check out the integrations list.","link":"../../ecosystem/integrations-community.md"},{"icon":{"src":"/3-Callout-Awards.svg"},"title":"Award winning","details":"2019 JavaScript Open Source Award winner for \"The Most Exciting Use of Technology\".","link":"https://osawards.com/javascript/2019"}]},"isInternal":false,"tokens":380,"sizeBytes":1450},{"name":"examples.md","path":"packages/mermaid/src/docs/intro/examples.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/intro/examples.md","title":"Intro Skill","category":"anthropic-skill","format":"markdown","content":"## Diagram Types\n\n### [Flowchart](../syntax/flowchart.md?id=flowcharts-basic-syntax)\n\n```mermaid-example\ngraph TD;\n    A-->B;\n    A-->C;\n    B-->D;\n    C-->D;\n```\n\n### [Sequence diagram](../syntax/sequenceDiagram.md)\n\n```mermaid-example\nsequenceDiagram\n    participant Alice\n    participant Bob\n    Alice->>John: Hello John, how are you?\n    loop HealthCheck\n        John->>John: Fight against hypochondria\n    end\n    Note right of John: Rational thoughts 
prevail!\n    John-->>Alice: Great!\n    John->>Bob: How about you?\n    Bob-->>John: Jolly good!\n```\n\n### [Use case diagram](../syntax/usecase.md)\n\n```mermaid-example\nusecase-beta\ndirection LR\nactor Customer\nCheckout(\"Place order\")\nCustomer --> Checkout\n```\n\n### [Gantt diagram](../syntax/gantt.md)\n\n```mermaid-example\ngantt\ndateFormat  YYYY-MM-DD\ntitle Adding GANTT diagram to mermaid\nexcludes weekdays 2014-01-10\n\nsection A section\nCompleted task            :done,    des1, 2014-01-06,2014-01-08\nActive task               :active,  des2, 2014-01-09, 3d\nFuture task               :         des3, after des2, 5d\nFuture task2               :         des4, after des3, 5d\n```\n\n### [Class diagram](../syntax/classDiagram.md)\n\n```mermaid-example\nclassDiagram\nClass01 <|-- AveryLongClass : Cool\nClass03 *-- Class04\nClass05 o-- Class06\nClass07 .. Class08\nClass09 --> C2 : Where am i?\nClass09 --* C3\nClass09 --|> Class07\nClass07 : equals()\nClass07 : Object[] elementData\nClass01 : size()\nClass01 : int chimp\nClass01 : int gorilla\nClass08 <--> C2: Cool label\n```\n\n### [Git graph](../syntax/gitgraph.md)\n\n```mermaid-example\n    gitGraph\n       commit\n       commit\n       branch develop\n       commit\n       commit\n       commit\n       checkout main\n       commit\n       commit\n```\n\n### [Entity Relationship Diagram - :exclamation: experimental](../syntax/entityRelationshipDiagram.md)\n\n```mermaid-example\nerDiagram\n    CUSTOMER ||--o{ ORDER : places\n    ORDER ||--|{ LINE-ITEM : contains\n    CUSTOMER }|..|{ DELIVERY-ADDRESS : uses\n\n```\n\n### [User Journey Diagram](../syntax/userJourney.md)\n\n```mermaid-example\njourney\n    title My working day\n    section Go to work\n      Make tea: 5: Me\n      Go upstairs: 3: Me\n      Do work: 1: Me, Cat\n    section Go home\n      Go downstairs: 5: Me\n      Sit down: 5: Me\n```\n\n### [Quadrant Chart](../syntax/quadrantChart.md)\n\n```mermaid-example\nquadrantChart\n    title Reach and engagement of campaigns\n    x-axis Low Reach --> High Reach\n    y-axis Low Engagement --> High Engagement\n    quadrant-1 We should expand\n    quadrant-2 Need to promote\n    quadrant-3 Re-evaluate\n    quadrant-4 May be improved\n    Campaign A: [0.3, 0.6]\n    Campaign B: [0.45, 0.23]\n    Campaign C: [0.57, 0.69]\n    Campaign D: [0.78, 0.34]\n    Campaign E: [0.40, 0.34]\n    Campaign F: [0.35, 0.78]\n```\n\n### [XY Chart](../syntax/xyChart.md)\n\n```mermaid-example\nxychart-beta\n    title \"Sales Revenue\"\n    x-axis [jan, feb, mar, apr, may, jun, jul, aug, sep, oct, nov, dec]\n    y-axis \"Revenue (in $)\" 4000 --> 11000\n    bar [5000, 6000, 7500, 8200, 9500, 10500, 11000, 10200, 9200, 8500, 7000, 6000]\n    line [5000, 6000, 7500, 8200, 9500, 10500, 11000, 10200, 9200, 8500, 7000, 6000]\n```\n","isInternal":false,"tokens":995,"sizeBytes":3157},{"name":"getting-started.md","path":"packages/mermaid/src/docs/intro/getting-started.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/intro/getting-started.md","title":"Intro Skill","category":"anthropic-skill","format":"markdown","content":"---\noutline: 'deep' # shows all h3 headings in outline in Vitepress\n---\n\n# Mermaid User Guide\n\n## Mermaid is composed of three parts\n\n1. Deployment\n2. Syntax\n3. Configuration\n\nThis section talks about the different ways to **deploy** Mermaid.\n\nIf you are a beginner:\n\n- Check out the [Diagram Syntax](syntax-reference.md) page\n- Check out the [Tutorials](../ecosystem/tutorials.md) page\n\n## Ways to use Mermaid\n\n1. [Using the Mermaid Live Editor](getting-started.md#_1-using-the-mermaid-live-editor)\n2. [Using the Mermaid Chart Editor](getting-started.md#_2-using-the-mermaid-chart-editor)\n3. [Using Mermaid Plugins and Integrations](getting-started.md#_3-using-mermaid-plugins)\n4. [Calling the Mermaid JavaScript API](getting-started.md#_4-calling-the-mermaid-javascript-api)\n5. [Adding Mermaid as a dependency](getting-started.md#_5-adding-mermaid-as-a-dependency)\n\nTo learn more, visit the [Usage](../config/usage.md) page.\n\n## 1. Using the Mermaid Live Editor\n\nAvailable at the [Mermaid Live Editor](https://mermaid.live) website.\n\n### Features\n\n
\n\n#### • Diagram Code\n\nIn the `Code` panel, write or edit Mermaid code, and instantly `Preview` the rendered result in the diagram panel.\n\nHere is an example of Mermaid code and its rendered result:\n\n```mermaid-example\ngraph TD\n    A[Enter Chart Definition] --> B(Preview)\n    B --> C{decide}\n    C --> D[Keep]\n    C --> E[Edit Definition]\n    E --> B\n    D --> F[Save Image and Code]\n    F --> B\n```\n\n
\n\n#### • Configurations\n\nConfiguration options are available in the `Configuration` panel. The options are applied to the diagram in the `Preview` panel.\n\nTo learn more, visit the [Configuration Reference](../config/setup/README.md) page\n\n![Code,Config and Preview](./img/Code-Preview-Config.png)\n\n
\n\n#### • Editing History\n\nYour code will be autosaved and appear in the `Timeline` tab of the `History` section. Edits are saved every minute and only the last 30 edits are viewable.\n\nAlternatively, you can manually save code by clicking on the `Save` icon from the `History` section.\n\n```note\nHistory is stored in the browser storage only.\n```\n\n
\n\n#### • Saving a diagram\n\nThere are multiple ways of saving your diagram from the `Actions` section:\n\n- export PNG\n- export SVG\n- export as Markdown\n\n![Flowchart](./img/Live-Editor-Choices.png)\n\n
\n\n#### • Editing your diagrams\n\nTo edit your diagram, you can copy paste existing Mermaid diagram code into the `Code` section of the `Live Editor`.\n\nOr:\n\n- create a new diagram from scratch\n- use a Sample Diagram from the `Sample Diagrams` section\n\n
\n\n#### • Loading from Gists\n\nThe Gist you create should have a `code.mmd` file and optionally a `config.json`, similar to this [example](https://gist.github.com/sidharthv96/6268a23e673a533dcb198f241fd7012a).\n\n```note\nTo learn about Gists, visit the GitHub documentation page on [Creating gists](https://docs.github.com/en/get-started/writing-on-github/editing-and-sharing-content-with-gists/creating-gists).\n```\n\nOnce you have created a Gist, copy paste the Gist URL into the respective field in the `Actions` section and click on the `Load Gist` button.\n\nHere is an example of a Gist being loaded into the Editor:\n\n\n\nAnd, here is the diagram view from the above example:\n\n\n\n## 2. Using the Mermaid Chart Editor\n\nAvailable at the [Mermaid Chart](https://mermaid.ai/) website.\n\nMermaid Chart is a web-based diagram editor that allows you to create and edit diagrams in your browser. It is built by the team behind Mermaid.\n\nFeatures include:\n\n- AI diagramming\n- Collaboration & multi-user editing\n- Storage\n- and more\n\nTo learn more, visit the [Mermaid Chart page](/ecosystem/mermaid-chart.html) in the Ecosystem section of the documentation.\n\nOr go to the [Mermaid Chart website](https://mermaid.ai/app/sign-up) to sign up for a Free account.\n\n## 3. Using Mermaid Plugins\n\n### Mermaid Plugins\n\nYou can generate Mermaid diagrams from within popular applications using plug-ins.\n\nFor a list of Mermaid Plugins and Integrations, visit the [Integrations page](../ecosystem/integrations-community.md).\n\n### Mermaid Chart Plugins\n\nMermaid Chart plugins are available for:\n\n- [ChatGPT](https://mermaid.ai/docs/plugins/mermaid-chart-gpt)\n- [JetBrains IDE](https://mermaid.ai/docs/plugins/jetbrains-ide)\n- [Microsoft PowerPoint](https://mermaid.ai/docs/plugins/microsoft-powerpoint)\n- [Microsoft Word](https://mermaid.ai/docs/plugins/microsoft-word)\n- [Visual Studio Code](https://mermaid.ai/docs/plugins/visual-studio-code)\n\nTo learn more, visit the [Mermaid Chart Plugins](https://mermaid.ai/plugins) page.\n\n### Native Mermaid Support\n\nFor apps that support markdown (e.g. [GitHub](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-diagrams) and [GitLab](https://handbook.gitlab.com/handbook/tools-and-tips/mermaid/)), you can add Mermaid diagrams by making a `mermaid` code block.\n\n````markdown\nThe following code-block will be rendered as a Mermaid diagram:\n\n```mermaid\nflowchart LR\n  A --> B\n```\n````\n\n## 4. Calling the Mermaid JavaScript API\n\nThis method can be used with any common web server like `Apache`, `IIS`, `Nginx`, and `Node Express`.\n\nYou will also need a text editing tool like `Notepad++` to generate an `html` file. It is then deployed by a web browser, i.e. `Firefox`, `Chrome`, `Safari`.\n\n```note\nInternet Explorer is not supported.\n```\n\nThe API works by pulling rendering instructions from the source `mermaid.js` in order to render diagrams on the page.\n\n### Requirements for the Mermaid API\n\nWhen writing the `html` file, we give two instructions inside the `html code` to the `web browser`:\n\na. The Mermaid code for the diagram we want to create.\n\nb. The importing of the Mermaid library through the `mermaid.esm.mjs` or `mermaid.esm.min.mjs`, and the `mermaid.initialize()` call, which dictates the appearance of diagrams and also starts the rendering process.\n\n#### Examples\n\n- This is an example of an embedded Mermaid diagram definition inside a `
`:\n\n```html\n\n  Here is a mermaid diagram:\n  
\n        graph TD\n        A[Client] --> B[Load Balancer]\n        B --> C[Server01]\n        B --> D[Server02]\n  
\n\n```\n\n```note\nEvery Mermaid chart/graph/diagram definition should have separate `
` tags.\n```\n\n- This is an example of a Mermaid import and the `mermaid.initialize()` call.\n\n```note\nA `mermaid.initialize()` call takes all the definitions contained within `
` tags and renders them into diagrams.\n```\n\n```html\n\n  \n\n```\n\n```note\nRendering in Mermaid is initialized by the `mermaid.initialize()` call. However, doing the opposite lets you control when it starts looking for `
` tags inside the web page with `mermaid.initialize()`. This is useful when you think that not all `
` tags may have loaded on the execution of `mermaid.esm.min.mjs` file.\n```\n\n`startOnLoad` is one of the parameters that can be defined by `mermaid.initialize()`\n\n| Parameter   | Description                       | Type    | Values      |\n| ----------- | --------------------------------- | ------- | ----------- |\n| startOnLoad | Toggle for Rendering upon loading | Boolean | true, false |\n\nIn this example, the `mermaidAPI` is being called through the `CDN`:\n\n```html\n\n  \n    Here is one mermaid diagram:\n    
\n            graph TD\n            A[Client] --> B[Load Balancer]\n            B --> C[Server1]\n            B --> D[Server2]\n    
\n\n    And here is another:\n    
\n            graph TD\n            A[Client] -->|tcp_123| B\n            B(Load Balancer)\n            B -->|tcp_456| C[Server1]\n            B -->|tcp_456| D[Server2]\n    
\n\n    \n  \n\n```\n\nIn this example, `mermaid.js` is referenced in `src` as a separate JavaScript file:\n\n```html\n\n  \n    \n  \n  \n    
\n            graph LR\n            A --- B\n            B-->C[fa:fa-ban forbidden]\n            B-->D(fa:fa-spinner);\n    
\n    
\n            graph TD\n            A[Client] --> B[Load Balancer]\n            B --> C[Server1]\n            B --> D[Server2]\n    
\n    \n  \n\n```\n\n##### Custom fonts\n\nMermaid comes with some default recommended fonts that you can setup on your\npage as well.\n\nSee [Usage § Fonts](../config/usage.md#fonts) for full details.\n\n```html\n\n  \n    /@fontsource/open-sans@5/400.css\" />\n    /@fontsource/open-sans@5/400-italic.css\" />\n    /@fontsource-variable/recursive@5/index.css\" />\n  \n  \n    Here is one mermaid diagram using the `redux-dark` theme:\n\n    
\n      ---\n      config:\n        theme: redux-dark\n      ---\n      flowchart\n            A[Client] --> B[Load Balancer]\n            B --> C[Server1]\n            B --> D[Server2]\n    
\n\n    \n  \n\n```\n\n## 5. Adding Mermaid as a dependency\n\nBelow are the steps for adding Mermaid as a dependency:\n\n1. Install [Node.js](https://nodejs.org/) v20 or higher (LTS recommended).\n\n```note\nTo learn more about downloading and installing `Node.js` and `npm`, visit the [npm Docs website](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm).\n```\n\n2. Add Mermaid using your preferred package manager:\n\n   **npm**\n\n   `npm install mermaid`\n\n   **yarn**\n\n   `yarn add mermaid`\n\n   **pnpm**\n\n   `pnpm add mermaid`\n\n3. To add Mermaid as a dev dependency instead, append the dev flag:\n\n   **npm:** `npm install --save-dev mermaid`\n\n   **yarn:** `yarn add --dev mermaid`\n\n   **pnpm:** `pnpm add --save-dev mermaid`\n\n## Closing note\n\n```note\nComments from Knut Sveidqvist, creator of Mermaid:\n\n- In early versions of Mermaid, the `\n```\n\n**Doing so commands the mermaid parser to look for the `
` or `
` tags with `class=\"mermaid\"`. From these tags, mermaid tries to read the diagram/chart definitions and render them into SVG charts.**\n\n**Examples can be found in** [Other examples](../syntax/examples.md)\n\n## Sibling projects\n\n- [Mermaid Live Editor](https://github.com/mermaid-js/mermaid-live-editor)\n- [Mermaid CLI](https://github.com/mermaid-js/mermaid-cli)\n- [Mermaid Tiny](https://github.com/mermaid-js/mermaid/tree/develop/packages/tiny)\n- [Mermaid Webpack Demo](https://github.com/mermaidjs/mermaid-webpack-demo)\n- [Mermaid Parcel Demo](https://github.com/mermaidjs/mermaid-parcel-demo)\n\n## Request for Assistance\n\nThings are piling up and I have a hard time keeping up. It would be great if we could form a core team of developers to cooperate\nwith the future development of mermaid.\n\nAs part of this team you would get write access to the repository and would\nrepresent the project when answering questions and issues.\n\nTogether we could continue the work with things like:\n\n- Adding more types of diagrams like mindmaps, ert diagrams, etc.\n- Improving existing diagrams\n\nDon't hesitate to contact me if you want to get involved!\n\n## Contributors\n\n
\n\n[![Good first issue](https://img.shields.io/github/labels/mermaid-js/mermaid/Good%20first%20issue%21)](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Good+first+issue%21%22)\n[![Contributors](https://img.shields.io/github/contributors/mermaid-js/mermaid)](https://github.com/mermaid-js/mermaid/graphs/contributors)\n[![Commits](https://img.shields.io/github/commit-activity/m/mermaid-js/mermaid)](https://github.com/mermaid-js/mermaid/graphs/contributors)\n\n
\n\nMermaid is a growing community and is always accepting new contributors. There's a lot of different ways to help out and we're always looking for extra hands! Look at [this issue](https://github.com/mermaid-js/mermaid/issues/866) if you want to know where to start helping out.\n\nDetailed information about how to contribute can be found in the [contribution guideline](../community/contributing.md).\n\n### Requirements\n\n- [volta](https://volta.sh/) to manage node versions.\n- [Node.js](https://nodejs.org/en/). `volta install node`\n- [pnpm](https://pnpm.io/) package manager. `volta install pnpm`\n\n### Development Installation\n\n```bash\ngit clone git@github.com:mermaid-js/mermaid.git\ncd mermaid\n# npx is required for first install as volta support for pnpm is not added yet.\nnpx pnpm install\npnpm test\n```\n\n### Lint\n\n```sh\npnpm lint\n```\n\nWe use [eslint](https://eslint.org/).\nWe recommend you to install [editor plugins](https://eslint.org/docs/user-guide/integrations) to get real time lint result.\n\n### Test\n\n```sh\npnpm test\n```\n\nManual test in browser: open `dist/index.html`\n\n### Release\n\nFor those who have the permission to do so:\n\nUpdate version number in `package.json`.\n\n```sh\nnpm publish\n```\n\nThe above command generates files into the `dist` folder and publishes them to [npmjs.com](https://www.npmjs.com/).\n\n## Security and safe diagrams\n\nFor public sites, it can be precarious to retrieve text from users on the internet, storing that content for presentation in a browser at a later stage. The reason is that the user content can contain embedded malicious scripts that will run when the data is presented. For Mermaid this is a risk, specially as mermaid diagrams contain many characters that are used in html which makes the standard sanitation unusable as it also breaks the diagrams. We still make an effort to sanitize the incoming code and keep refining the process but it is hard to guarantee that there are no loop holes.\n\nAs an extra level of security for sites with external users we are happy to introduce a new security level in which the diagram is rendered in a sandboxed iframe preventing JavaScript in the code from being executed. This is a great step forward for better security.\n\n_Unfortunately you cannot have a cake and eat it at the same time which in this case means that some of the interactive functionality gets blocked along with the possible malicious code._\n\n## Reporting vulnerabilities\n\nTo report a vulnerability, please e-mail security@mermaid.live with a description of the issue, the steps you took to create the issue, affected versions, and if known, mitigations for the issue.\n\n## Appreciation\n\nA quick note from Knut Sveidqvist:\n\n> _Many thanks to the [d3](https://d3js.org/) and [dagre-d3](https://github.com/cpettitt/dagre-d3) projects for providing the graphical layout and drawing libraries!_\n>\n> _Thanks also to the [js-sequence-diagram](https://bramp.github.io/js-sequence-diagrams) project for usage of the grammar for the sequence diagrams. Thanks to Jessica Peter for inspiration and starting point for gantt rendering._\n>\n> _Thank you to [Tyler Long](https://github.com/tylerlong) who has been a collaborator since April 2017._\n>\n> _Thank you to the ever-growing list of [contributors](https://github.com/mermaid-js/mermaid/graphs/contributors) that brought the project this far!_\n\n---\n\n_Mermaid was created by Knut Sveidqvist for easier documentation._\n\n\n","isInternal":false,"tokens":4872,"sizeBytes":14093},{"name":"syntax-reference.md","path":"packages/mermaid/src/docs/intro/syntax-reference.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/intro/syntax-reference.md","title":"Intro Skill","category":"anthropic-skill","format":"markdown","content":"# Diagram Syntax\n\nMermaid's syntax is used to create diagrams. You'll find that it is not too tricky and can be learned in a day. The next sections dive deep into the syntax of each diagram type.\n\nSyntax, together with Deployment and Configuration constitute the whole of Mermaid.\n\nDiagram Examples can be found in the [Mermaid Live Editor](https://mermaid.live), it is also a great practice area.\n\n## Syntax Structure\n\nOne would notice that all **Diagrams definitions begin** with a declaration of the **diagram type**, followed by the definitions of the diagram and its contents. This declaration notifies the parser which kind of diagram the code is supposed to generate. The only exception to this a [Frontmatter](#frontmatter-for-diagram-code) configuration.\n\nLine comments can ignore anything on the line after '%% '.\n\nUnknown words and misspellings will break a diagram, while parameters silently fail.\n\n**Example** : The code below is for an Entity Relationship Diagram, specified by the `erDiagram` declaration. What follows is the definition of the different `Entities` represented in it.\n\n```mermaid-example\nerDiagram\n          CUSTOMER }|..|{ DELIVERY-ADDRESS : has\n          CUSTOMER ||--o{ ORDER : places\n          CUSTOMER ||--o{ INVOICE : \"liable for\"\n          DELIVERY-ADDRESS ||--o{ ORDER : receives\n          INVOICE ||--|{ ORDER : covers\n          ORDER ||--|{ ORDER-ITEM : includes\n          PRODUCT-CATEGORY ||--|{ PRODUCT : contains\n          PRODUCT ||--o{ ORDER-ITEM : \"ordered in\"\n```\n\nThe [Getting Started](./getting-started.md) section can also provide some practical examples of mermaid syntax.\n\n## Diagram Breaking\n\nOne should **beware the use of some words or symbols** that can break diagrams. These words or symbols are few and often only affect specific types of diagrams. The table below will continuously be updated.\n\n| Diagram Breakers                                                                     | Reason                                                                  | Solution                                          |\n| ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------- | ------------------------------------------------- |\n| **Comments**                                                                         |                                                                         |                                                   |\n| [`%%{``}%%`](https://github.com/mermaid-js/mermaid/issues/1968)                      | Similar to [Directives](../config/directives.md) confuses the renderer. | In comments using `%%`, avoid using \"{}\".         |\n| **Flow-Charts**                                                                      |                                                                         |                                                   |\n| 'end'                                                                                | The word \"End\" can cause Flowcharts and Sequence diagrams to break      | Wrap them in quotation marks to prevent breakage. |\n| [Nodes inside Nodes](../syntax/flowchart.md?id=special-characters-that-break-syntax) | Mermaid gets confused with nested shapes                                | wrap them in quotation marks to prevent breaking  |\n\n## Mermaid Live Editor\n\nNow, that you've seen what you should not add to your diagrams, you can play around with them in the [Mermaid Live Editor](https://mermaid.live).\n\n## Configuration\n\nConfiguration is the third part of Mermaid, after deployment and syntax. It deals with the different ways that Mermaid can be customized across different deployments.\n\nIf you are interested in altering and customizing your Mermaid Diagrams, you will find the methods and values available for [Configuration](../config/setup/README.md) here. It includes themes.\nThis section will introduce the different methods of configuring the behaviors and appearances of Mermaid Diagrams.\nThe following are the most commonly used methods, and they are all tied to Mermaid [Deployment](./getting-started.md) methods.\n\n### Configuration Section in the [Live Editor](https://mermaid.live).\n\nHere you can edit certain values to change the behavior and appearance of the diagram.\n\nEach of these techniques are functionally equivalent, but better for different deployments.\n\n### [The initialize() call](./getting-started.md#_4-calling-the-mermaid-javascript-api)\n\nUsed when Mermaid is called via an API, or through a `\n```\n\n```mermaid\nclassDiagram\n    class Class01\n    class Class02\n    callback Class01 \"callbackFunction\" \"Callback tooltip\"\n    link Class02 \"https://www.github.com\" \"This is a link\"\n    class Class03\n    class Class04\n    click Class03 call callbackFunction() \"Callback tooltip\"\n    click Class04 href \"https://www.github.com\" \"This is a link\"\n```\n\n> **Success** The tooltip functionality and the ability to link to urls are available from version 0.5.2.\n\nBeginner's tip—a full example using interactive links in an HTML page:\n\n```html\n\n  
\n    classDiagram\n    Animal <|-- Duck\n    Animal <|-- Fish\n    Animal <|-- Zebra\n    Animal : +int age\n    Animal : +String gender\n    Animal: +isMammal()\n    Animal: +mate()\n    class Duck{\n      +String beakColor\n      +swim()\n      +quack()\n      }\n    class Fish{\n      -int sizeInFeet\n      -canEat()\n      }\n    class Zebra{\n      +bool is_wild\n      +run()\n      }\n\n      callback Duck \"callback\" \"Tooltip\"\n      link Zebra \"https://www.github.com\" \"This is a link\"\n  
\n\n  \n\n```\n\n## Styling\n\n### Styling a node\n\nIt is possible to apply specific styles such as a thicker border or a different background color to an individual node using the `style` keyword.\n\nNote that notes and namespaces cannot be styled individually but do support themes.\n\n```mermaid-example\nclassDiagram\n  class Animal\n  class Mineral\n  style Animal fill:#f9f,stroke:#333,stroke-width:4px\n  style Mineral fill:#bbf,stroke:#f66,stroke-width:2px,color:#fff,stroke-dasharray: 5 5\n```\n\n#### Classes\n\nMore convenient than defining the style every time is to define a class of styles and attach this class to the nodes that\nshould have a different look.\n\nA class definition looks like the example below:\n\n```\nclassDef className fill:#f9f,stroke:#333,stroke-width:4px;\n```\n\nAlso, it is possible to define style to multiple classes in one statement:\n\n```\nclassDef firstClassName,secondClassName font-size:12pt;\n```\n\nAttachment of a class to a node is done as per below:\n\n```\ncssClass \"nodeId1\" className;\n```\n\nIt is also possible to attach a class to a list of nodes in one statement:\n\n```\ncssClass \"nodeId1,nodeId2\" className;\n```\n\nA shorter form of adding a class is to attach the classname to the node using the `:::` operator:\n\n```mermaid-example\nclassDiagram\n    class Animal:::someclass\n    classDef someclass fill:#f96\n```\n\nOr:\n\n```mermaid-example\nclassDiagram\n    class Animal:::someclass {\n        -int sizeInFeet\n        -canEat()\n    }\n    classDef someclass fill:#f96\n```\n\n### Default class\n\nIf a class is named default it will be applied to all nodes. Specific styles and classes should be defined afterwards to override the applied default styling.\n\n```\nclassDef default fill:#f9f,stroke:#333,stroke-width:4px;\n```\n\n```mermaid-example\nclassDiagram\n  class Animal:::pink\n  class Mineral\n\n  classDef default fill:#f96,color:red\n  classDef pink color:#f9f\n```\n\n### CSS Classes\n\nIt is also possible to predefine classes in CSS styles that can be applied from the graph definition as in the example\nbelow:\n\n**Example style**\n\n```html\n\n```\n\n**Example definition**\n\n```mermaid-example\nclassDiagram\n    class Animal:::styleClass\n```\n\n> cssClasses cannot be added using this shorthand method at the same time as a relation statement.\n\n## Configuration\n\n### Members Box\n\nIt is possible to hide the empty members box of a class node.\n\nThis is done by changing the **hideEmptyMembersBox** value of the class diagram configuration. For more information on how to edit the Mermaid configuration see the [configuration page.](https://mermaid.js.org/config/configuration.html)\n\n### Possible configuration parameters:\n\n| Parameter           | Description                                                  | Default value |\n| ------------------- | ------------------------------------------------------------ | ------------- |\n| hideEmptyMembersBox | Hides the empty members box of a class node when set to true | false         |\n\n```mermaid-example\n---\n  config:\n    class:\n      hideEmptyMembersBox: true\n---\nclassDiagram\n  class Duck\n```\n","isInternal":false,"tokens":5495,"sizeBytes":22996},{"name":"cynefin.md","path":"packages/mermaid/src/docs/syntax/cynefin.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/cynefin.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"# Cynefin Framework Diagram (v11.16.0+)\n\n> The Cynefin framework is a sense-making framework created by [Dave Snowden](https://en.wikipedia.org/wiki/Dave_Snowden) that categorizes problems into five complexity domains. It helps teams match their response to the nature of the situation they are facing. The name is Welsh for \"place\" or \"habitat\".\n\nYou can read more at [The Cynefin Co](https://thecynefin.co/about-us/about-cynefin-framework).\n\n## Introduction\n\nThe Cynefin framework divides the world into five domains, each with its own decision-making approach:\n\n- **Clear** (formerly Obvious/Simple): Cause and effect are obvious. Sense → Categorise → Respond. Apply **best practices**.\n- **Complicated**: Cause and effect require analysis or expertise. Sense → Analyse → Respond. Apply **good practices**.\n- **Complex**: Cause and effect can only be deduced in retrospect. Probe → Sense → Respond. Apply **emergent practices**.\n- **Chaotic**: No perceivable cause and effect. Act → Sense → Respond. Apply **novel practices**.\n- **Confusion** (or Disorder): You do not know which domain you are in. The goal is to move items out of this state into one of the other four.\n\nThe signature visual feature is the wavy, organic boundary between the ordered (Clear, Complicated) and unordered (Complex, Chaotic) halves, and the \"cliff\" between Clear and Chaotic representing the risk of complacency leading to crisis.\n\n## Syntax\n\nA Cynefin diagram is declared with `cynefin-beta` followed by domain blocks and optional transitions.\n\n```md\ncynefin-beta\ntitle Optional Diagram Title\n\ncomplex\n\"Item label\"\n\"Another item\"\n\ncomplicated\n\"Expert analysis needed\"\n\nclear\n\"Known procedure\"\n\nchaotic\n\"Crisis response\"\n\nconfusion\n\"Item of unknown domain\"\n\ncomplex --> complicated : \"Pattern identified\"\nclear --> chaotic : \"Complacency\"\n```\n\n### Keywords\n\n| Keyword        | Meaning                                                                |\n| -------------- | ---------------------------------------------------------------------- |\n| `cynefin-beta` | Diagram type declaration (required, first line after any front matter) |\n| `title`        | Optional diagram title                                                 |\n| `complex`      | Opens the Complex domain block                                         |\n| `complicated`  | Opens the Complicated domain block                                     |\n| `clear`        | Opens the Clear domain block                                           |\n| `chaotic`      | Opens the Chaotic domain block                                         |\n| `confusion`    | Opens the Confusion / Disorder domain block                            |\n| `-->`          | Declares a transition from one domain to another                       |\n\n### Items\n\nItems are quoted string labels placed on their own lines inside a domain block. Each item renders as a text badge within the domain region.\n\n```\ncomplex\n  \"Investigate root cause\"\n  \"Run chaos experiment\"\n```\n\nKeep per-domain item lists short — the quadrants have fixed layout and long lists can visually overflow their boxes. The confusion ellipse caps at three items and shows a `+N more` badge; the four quadrant domains do not clip, so prefer a handful of items each.\n\n### Transitions\n\nTransitions represent movement of items between domains over time. They are declared at the top level using `-->` between two domain names, with an optional label.\n\n```\ncomplex --> complicated : \"Pattern identified\"\nclear --> chaotic : \"Complacency\"\nchaotic --> complex : \"Stabilized\"\n```\n\nCommon transitions:\n\n- **Complex → Complicated**: An emerging pattern has become understood and can now be analyzed.\n- **Chaotic → Complex**: A crisis has been stabilized enough to begin probing.\n- **Clear → Chaotic**: Complacency or over-constraint has led to collapse (the \"cliff\").\n- **Complicated → Clear**: Analysis has codified a solution into a standard practice.\n\n## Examples\n\n### Basic example\n\n```mermaid-example\ncynefin-beta\n  title Incident Response\n\n  complex\n    \"Investigate root cause\"\n    \"Run chaos experiment\"\n\n  complicated\n    \"Analyze performance data\"\n    \"Expert review needed\"\n\n  clear\n    \"Restart service\"\n    \"Apply known fix\"\n\n  chaotic\n    \"Page on-call immediately\"\n\n  confusion\n    \"Unknown failure mode\"\n```\n\n### With transitions\n\n```mermaid-example\ncynefin-beta\n  title Strategy Categorization\n\n  complex\n    \"Market research\"\n\n  complicated\n    \"Competitive analysis\"\n\n  clear\n    \"Standard pricing\"\n\n  chaotic\n    \"Crisis management\"\n\n  complex --> complicated : \"Pattern identified\"\n  complicated --> clear : \"Best practice codified\"\n  clear --> chaotic : \"Complacency\"\n  chaotic --> complex : \"Stabilized\"\n```\n\n### Empty framework\n\nThe domains themselves render even with no items, useful as a teaching or worksheet template.\n\n```mermaid-example\ncynefin-beta\n  title Cynefin Framework\n\n  complex\n  complicated\n  clear\n  chaotic\n```\n\n## Configuration\n\nCynefin diagrams accept the following configuration under the `cynefin` key in the mermaid config:\n\n| Option                   | Type    | Default | Description                                                                                                                                                                                                                  |\n| ------------------------ | ------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `width`                  | number  | `800`   | Width of the diagram in pixels                                                                                                                                                                                               |\n| `height`                 | number  | `600`   | Height of the diagram in pixels                                                                                                                                                                                              |\n| `padding`                | number  | `40`    | Padding around the diagram                                                                                                                                                                                                   |\n| `showDomainDescriptions` | boolean | `true`  | Show decision model and practice type subtitles per domain                                                                                                                                                                   |\n| `boundaryAmplitude`      | number  | `8`     | Waviness amplitude of domain boundaries in pixels (set to `0` for straight lines)                                                                                                                                            |\n| `seed`                   | number  | `0`     | Deterministic seed for boundary waviness. `0` (default) hashes the diagram's SVG id so each diagram looks unique. Set any non-zero number to lock the waviness across renders — required for stable visual regression tests. |\n\nExample:\n\n```\n---\nconfig:\n  cynefin:\n    width: 1000\n    showDomainDescriptions: false\n---\ncynefin-beta\n  complex\n    \"Adaptive work\"\n```\n\n## Theming\n\nCynefin diagrams use the following theme variables, which can be overridden via `themeVariables.cynefin`:\n\n| Variable         | Description                                      |\n| ---------------- | ------------------------------------------------ |\n| `complexBg`      | Background color for the Complex domain          |\n| `complicatedBg`  | Background color for the Complicated domain      |\n| `clearBg`        | Background color for the Clear domain            |\n| `chaoticBg`      | Background color for the Chaotic domain          |\n| `confusionBg`    | Background color for the Confusion center region |\n| `boundaryColor`  | Color of the wavy domain boundaries              |\n| `boundaryWidth`  | Stroke width of the boundaries                   |\n| `cliffColor`     | Color of the Clear/Chaotic cliff                 |\n| `cliffWidth`     | Stroke width of the cliff                        |\n| `arrowColor`     | Color of transition arrows                       |\n| `arrowWidth`     | Stroke width of transition arrows                |\n| `labelColor`     | Color of domain name labels                      |\n| `textColor`      | Color of item and subtitle text                  |\n| `domainFontSize` | Font size of domain name labels                  |\n| `itemFontSize`   | Font size of item badges and subtitles           |\n\n## Notes\n\n- Domain names are fixed keywords. Only `complex`, `complicated`, `clear`, `chaotic`, and `confusion` are recognized.\n- Domains can be declared in any order; their position in the diagram is always the same (Complex top-left, Complicated top-right, Chaotic bottom-left, Clear bottom-right, Confusion center).\n- The `confusion` domain has a compact center ellipse. Up to 3 items are shown inside it; if more are provided a `+N more` overflow badge is displayed. In practice, the confusion domain should contain very few items — its purpose is to surface unknowns so they can be moved to one of the four main domains.\n- Self-loop transitions (e.g. `complex --> complex`) are silently ignored. Transitions must connect two different domains.\n- Handdrawn mode is not currently supported.\n- The wavy boundary rendering is deterministic: the same input always produces the same diagram, so diffs are stable across builds.\n\n## Accessibility\n\nCynefin diagrams support the standard mermaid accessibility directives:\n\n```\ncynefin-beta\n  accTitle: Cynefin framework for software delivery decisions\n  accDescr: A Cynefin map categorizing software tasks by complexity domain\n\n  complex\n    \"New feature discovery\"\n```\n","isInternal":false,"tokens":1883,"sizeBytes":9947},{"name":"entityRelationshipDiagram.md","path":"packages/mermaid/src/docs/syntax/entityRelationshipDiagram.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/entityRelationshipDiagram.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"# Entity Relationship Diagrams\n\n> An entity–relationship model (or ER model) describes interrelated things of interest in a specific domain of knowledge. A basic ER model is composed of entity types (which classify the things of interest) and specifies relationships that can exist between entities (instances of those entity types) [Wikipedia](https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model).\n\nNote that practitioners of ER modelling almost always refer to _entity types_ simply as _entities_. For example the `CUSTOMER` entity _type_ would be referred to simply as the `CUSTOMER` entity. This is so common it would be inadvisable to do anything else, but technically an entity is an abstract _instance_ of an entity type, and this is what an ER diagram shows - abstract instances, and the relationships between them. This is why entities are always named using singular nouns.\n\nMermaid can render ER diagrams\n\n```mermaid-example\n---\ntitle: Order example\n---\nerDiagram\n    CUSTOMER ||--o{ ORDER : places\n    ORDER ||--|{ LINE-ITEM : contains\n    CUSTOMER }|..|{ DELIVERY-ADDRESS : uses\n```\n\nEntity names are often capitalised, although there is no accepted standard on this, and it is not required in Mermaid.\n\nRelationships between entities are represented by lines with end markers representing cardinality. Mermaid uses the most popular crow's foot notation. The crow's foot intuitively conveys the possibility of many instances of the entity that it connects to.\n\nER diagrams can be used for various purposes, ranging from abstract logical models devoid of any implementation details, through to physical models of relational database tables. It can be useful to include attribute definitions on ER diagrams to aid comprehension of the purpose and meaning of entities. These do not necessarily need to be exhaustive; often a small subset of attributes is enough. Mermaid allows them to be defined in terms of their _type_ and _name_.\n\n```mermaid-example\nerDiagram\n    CUSTOMER ||--o{ ORDER : places\n    CUSTOMER {\n        string name\n        string custNumber\n        string sector\n    }\n    ORDER ||--|{ LINE-ITEM : contains\n    ORDER {\n        int orderNumber\n        string deliveryAddress\n    }\n    LINE-ITEM {\n        string productCode\n        int quantity\n        float pricePerUnit\n    }\n```\n\nWhen including attributes on ER diagrams, you must decide whether to include foreign keys as attributes. This probably depends on how closely you are trying to represent relational table structures. If your diagram is a _logical_ model which is not meant to imply a relational implementation, then it is better to leave these out because the associative relationships already convey the way that entities are associated. For example, a JSON data structure can implement a one-to-many relationship without the need for foreign key properties, using arrays. Similarly an object-oriented programming language may use pointers or references to collections. Even for models that are intended for relational implementation, you might decide that inclusion of foreign key attributes duplicates information already portrayed by the relationships, and does not add meaning to entities. Ultimately, it's your choice.\n\n## Default theme, look and layout (v12.0.0+)\n\nEntity relationship diagrams use the `redux-color` theme and the `neo` look by default, and are laid out by [ELK](https://www.eclipse.org/elk/) rather than Dagre. Not every diagram type\ndoes — see [Per-diagram defaults](../config/theming.md#per-diagram-defaults) for the list and\nfor the order in which Mermaid decides.\n\nThe same diagram, drawn both ways:\n\n### With the defaults\n\n```mermaid-example\nerDiagram\n  CUSTOMER ||--o{ ORDER : places\n  ORDER ||--|{ LINE_ITEM : contains\n  PRODUCT ||--o{ LINE_ITEM : \"appears in\"\n  CUSTOMER {\n    string name\n    string email\n  }\n  ORDER {\n    int id\n    date placedAt\n  }\n  LINE_ITEM {\n    int quantity\n    float price\n  }\n  PRODUCT {\n    string sku\n    string title\n  }\n```\n\n### The previous appearance\n\nBoth are only defaults, so anything you set yourself wins. Naming the previous theme and look\nin a diagram's front matter draws it the way Mermaid did before:\n\n```mermaid-example\n---\nconfig:\n  theme: default\n  look: classic\n  layout: dagre\n---\nerDiagram\n  CUSTOMER ||--o{ ORDER : places\n  ORDER ||--|{ LINE_ITEM : contains\n  PRODUCT ||--o{ LINE_ITEM : \"appears in\"\n  CUSTOMER {\n    string name\n    string email\n  }\n  ORDER {\n    int id\n    date placedAt\n  }\n  LINE_ITEM {\n    int quantity\n    float price\n  }\n  PRODUCT {\n    string sku\n    string title\n  }\n```\n\nPassing the same three keys to `mermaid.initialize()` does it for every diagram on the page,\nand scoping the theme and look to one diagram type — `mermaid.initialize({ layout: 'dagre', er: { theme: 'default', look: 'classic' } })` —\ndoes it for that type alone. `layout` is a top-level option, so it applies to every diagram.\n\n## Syntax\n\n### Entities and Relationships\n\nMermaid syntax for ER diagrams is compatible with PlantUML, with an extension to label the relationship. Each statement consists of the following parts:\n\n```\n     [  : ]\n```\n\nWhere:\n\n- `first-entity` is the name of an entity. Names support any unicode characters and can include spaces if surrounded by double quotes (e.g. \"name with space\").\n- `relationship` describes the way that both entities inter-relate. See below.\n- `second-entity` is the name of the other entity.\n- `relationship-label` describes the relationship from the perspective of the first entity.\n\nFor example:\n\n```\n    PROPERTY ||--|{ ROOM : contains\n```\n\nThis statement can be read as _a property contains one or more rooms, and a room is part of one and only one property_. You can see that the label here is from the first entity's perspective: a property contains a room, but a room does not contain a property. When considered from the perspective of the second entity, the equivalent label is usually very easy to infer. (Some ER diagrams label relationships from both perspectives, but this is not supported here, and is usually superfluous).\n\nOnly the `first-entity` part of a statement is mandatory. This makes it possible to show an entity with no relationships, which can be useful during iterative construction of diagrams. If any other parts of a statement are specified, then all parts are mandatory.\n\n#### Unicode text\n\nEntity names, relationships, and attributes all support unicode text.\n\n```mermaid-example\nerDiagram\n    \"This ❤ Unicode\"\n```\n\n#### Markdown formatting\n\nMarkdown formatting and text is also supported.\n\n```mermaid-example\nerDiagram\n    \"This **is** _Markdown_\"\n```\n\n### Relationship Syntax\n\nThe `relationship` part of each statement can be broken down into three sub-components:\n\n- the cardinality of the first entity with respect to the second\n- whether the relationship confers identity on a 'child' entity\n- the cardinality of the second entity with respect to the first\n\nCardinality is a property that describes how many elements of another entity can be related to the entity in question. In the above example a `PROPERTY` can have one or more `ROOM` instances associated to it, whereas a `ROOM` can only be associated with one `PROPERTY`. In each cardinality marker there are two characters. The outermost character represents a maximum value, and the innermost character represents a minimum value. The table below summarises possible cardinalities.\n\n| Value (left) | Value (right) | Meaning                       |\n| :----------: | :-----------: | ----------------------------- |\n|    `\\|o`     |     `o\\|`     | Zero or one                   |\n|    `\\|\\|`    |    `\\|\\|`     | Exactly one                   |\n|     `}o`     |     `o{`      | Zero or more (no upper limit) |\n|    `}\\|`     |     `\\|{`     | One or more (no upper limit)  |\n\n**Aliases**\n\n| Value (left) | Value (right) | Alias for    |\n| :----------: | :-----------: | ------------ |\n| one or zero  |  one or zero  | Zero or one  |\n| zero or one  |  zero or one  | Zero or one  |\n| one or more  |  one or more  | One or more  |\n| one or many  |  one or many  | One or more  |\n|   many(1)    |    many(1)    | One or more  |\n|      1+      |      1+       | One or more  |\n| zero or more | zero or more  | Zero or more |\n| zero or many | zero or many  | Zero or more |\n|   many(0)    |    many(0)    | Zero or more |\n|      0+      |      0+       | Zero or more |\n|   only one   |   only one    | Exactly one  |\n|      1       |       1       | Exactly one  |\n\n### Identification\n\nRelationships may be classified as either _identifying_ or _non-identifying_ and these are rendered with either solid or dashed lines respectively. This is relevant when one of the entities in question cannot have independent existence without the other. For example a firm that insures people to drive cars might need to store data on `NAMED-DRIVER`s. In modelling this we might start out by observing that a `CAR` can be driven by many `PERSON` instances, and a `PERSON` can drive many `CAR`s - both entities can exist without the other, so this is a non-identifying relationship that we might specify in Mermaid as: `PERSON }|..|{ CAR : \"driver\"`. Note the two dots in the middle of the relationship that will result in a dashed line being drawn between the two entities. But when this many-to-many relationship is resolved into two one-to-many relationships, we observe that a `NAMED-DRIVER` cannot exist without both a `PERSON` and a `CAR` - the relationships become identifying and would be specified using hyphens, which translate to a solid line:\n\n| Value |     Alias for     |\n| :---: | :---------------: |\n|  --   |   _identifying_   |\n|  ..   | _non-identifying_ |\n\n**Aliases**\n\n|     Value     |     Alias for     |\n| :-----------: | :---------------: |\n|      to       |   _identifying_   |\n| optionally to | _non-identifying_ |\n\n```mermaid-example\nerDiagram\n    CAR ||--o{ NAMED-DRIVER : allows\n    PERSON }o..o{ NAMED-DRIVER : is\n```\n\n```mermaid-example\nerDiagram\n    CAR 1 to zero or more NAMED-DRIVER : allows\n    PERSON many(0) optionally to 0+ NAMED-DRIVER : is\n```\n\n### Attributes\n\nAttributes can be defined for entities by specifying the entity name followed by a block containing multiple `type name` pairs, where a block is delimited by an opening `{` and a closing `}`. The attributes are rendered inside the entity boxes. For example:\n\n```mermaid-example\nerDiagram\n    CAR ||--o{ NAMED-DRIVER : allows\n    CAR {\n        string registrationNumber\n        string make\n        string model\n    }\n    PERSON ||--o{ NAMED-DRIVER : is\n    PERSON {\n        string firstName\n        string lastName\n        int age\n    }\n```\n\nThe `type` values must begin with an alphabetic character and may contain digits, hyphens, underscores, parentheses and square brackets. The `name` values follow a similar format to `type`, but may start with an asterisk as another option to indicate an attribute is a primary key. Other than that, there are no restrictions, and there is no implicit set of valid data types.\n\n#### Optional attribute types (v11.16.0+)\n\nAttribute `type` values may end with `?` to indicate an optional or nullable type.\n\n```mermaid-example\nerDiagram\n    PERSON {\n        string firstName\n        string? middleName\n        string lastName\n    }\n```\n\n### Entity Name Aliases\n\nAn alias can be added to an entity using square brackets. If provided, the alias will be showed in the diagram instead of the entity name. Alias names follow all of the same rules as entity names.\n\n```mermaid-example\nerDiagram\n    p[Person] {\n        string firstName\n        string lastName\n    }\n    a[\"Customer Account\"] {\n        string email\n    }\n    p ||--o| a : has\n```\n\n#### Attribute Keys and Comments\n\nAttributes may also have a `key` or comment defined. Keys can be `PK`, `FK` or `UK`, for Primary Key, Foreign Key or Unique Key (markdown formatting and unicode is not supported for keys). To specify multiple key constraints on a single attribute, separate them with a comma (e.g., `PK, FK`). A `comment` is defined by double quotes at the end of an attribute. Comments themselves cannot have double-quote characters in them.\n\n```mermaid-example\nerDiagram\n    CAR ||--o{ NAMED-DRIVER : allows\n    CAR {\n        string registrationNumber PK\n        string make\n        string model\n        string[] parts\n    }\n    PERSON ||--o{ NAMED-DRIVER : is\n    PERSON {\n        string driversLicense PK \"The license #\"\n        string(99) firstName \"Only 99 characters are allowed\"\n        string lastName\n        string phone UK\n        int age\n    }\n    NAMED-DRIVER {\n        string carRegistrationNumber PK, FK\n        string driverLicence PK, FK\n    }\n    MANUFACTURER only one to zero or more CAR : makes\n```\n\n### Direction\n\nThe direction statement declares the direction of the diagram.\n\nThis declares that the diagram is oriented from top to bottom (`TB`). This can be reversed to be oriented from bottom to top (`BT`).\n\n```mermaid-example\nerDiagram\n    direction TB\n    CUSTOMER ||--o{ ORDER : places\n    CUSTOMER {\n        string name\n        string custNumber\n        string sector\n    }\n    ORDER ||--|{ LINE-ITEM : contains\n    ORDER {\n        int orderNumber\n        string deliveryAddress\n    }\n    LINE-ITEM {\n        string productCode\n        int quantity\n        float pricePerUnit\n    }\n```\n\nThis declares that the diagram is oriented from left to right (`LR`). This can be reversed to be oriented from right to left (`RL`).\n\n```mermaid-example\nerDiagram\n    direction LR\n    CUSTOMER ||--o{ ORDER : places\n    CUSTOMER {\n        string name\n        string custNumber\n        string sector\n    }\n    ORDER ||--|{ LINE-ITEM : contains\n    ORDER {\n        int orderNumber\n        string deliveryAddress\n    }\n    LINE-ITEM {\n        string productCode\n        int quantity\n        float pricePerUnit\n    }\n```\n\nPossible diagram orientations are:\n\n- TB - Top to bottom\n- BT - Bottom to top\n- RL - Right to left\n- LR - Left to right\n\n### Subgraphs (v11.17.0+)\n\nSubgraphs allow grouping entities into logical sections within an ER diagram. They are useful for organizing\ncomplex diagrams and improving readability.\n\nSubgraphs can contain entities, relationships, and even other subgraphs (nested subgraphs).\n\n```\nsubgraph title\n    graph definition\nend\n```\n\nAn example below:\n\n```mermaid-example\nerDiagram\n    subgraph title1\n        CUSTOMER\n        CUSTOMER {\n            string name\n            string custNumber\n            string sector\n        }\n    end\n    subgraph title2\n        CAR ||--o{ NAMED-DRIVER : allows\n        subgraph title3\n            PERSON\n            PERSON {\n                string firstName\n                string lastName\n                int age\n            }\n        end\n    end\n```\n\nA subgraph always has an `id`, and optionally a `title`.\n\nIf the subgraph name is a single word, it is used as both id and title:\n\n```mermaid-example\nerDiagram\n    subgraph title1\n        CUSTOMER\n    end\n```\n\nIf the subgraph identifier contains more than one word, it must be written in `quotes`. In this case, the quoted value is used both as the id and the title.\n\n```mermaid-example\nerDiagram\n    subgraph \"Customer Domain\"\n        CUSTOMER\n    end\n```\n\nYou can also set an explicit id for the subgraph.\n\n```mermaid-example\nerDiagram\n    subgraph id1 [title 1]\n        CUSTOMER\n    end\n```\n\n````note\nSubgraphs are always referenced by their id, never by their title.\n\nThis is important when defining relationships involving subgraphs.\n\n**If a subgraph id contains spaces, it must be referenced using quotes:**\n\n```\"Customer Domain\" ||--o{ ORDER : contains```\n````\n\n#### Relationships involving subgraphs\n\nIt is also possible to define relationships to and from subgraphs.\n\n```mermaid-example\nerDiagram\n    subgraph title1\n        A1 ||--|| A2 : links\n    end\n\n    subgraph title2\n        B1 ||--|| B2 : links\n    end\n\n    subgraph title3\n        C1 ||--|| C2 : links\n    end\n\n    title1 ||--|| title2 : links\n    title2 ||--|| title3 : links\n    title2 ||--|| C2 : links\n```\n\n#### Direction in subgraphs\n\nA subgraph can define its own layout direction.\n\n```mermaid-example\nerDiagram\n    direction LR\n    subgraph TOP\n        direction TB\n        subgraph B1\n            direction RL\n            I1 ||--|| F1 : links\n        end\n        subgraph B2\n            direction BT\n            I2 ||--|| F2 : links\n        end\n    end\n    A ||--|| TOP : links\n    TOP ||--|| B : links\n    B1 ||--|| B2 : links\n```\n\n### Styling a node\n\nIt is possible to apply specific styles such as a thicker border or a different background color to a node.\n\n```mermaid-example\nerDiagram\n    id1||--||id2 : label\n    style id1 fill:#f9f,stroke:#333,stroke-width:4px\n    style id2 fill:#bbf,stroke:#f66,stroke-width:2px,color:#fff,stroke-dasharray: 5 5\n```\n\nIt is also possible to attach styles to a list of nodes in one statement:\n\n```\n    style nodeId1,nodeId2 styleList\n```\n\n#### Classes\n\nMore convenient than defining the style every time is to define a class of styles and attach this class to the nodes that\nshould have a different look.\n\nA class definition looks like the example below:\n\n```\n    classDef className fill:#f9f,stroke:#333,stroke-width:4px\n```\n\nIt is also possible to define multiple classes in one statement:\n\n```\n    classDef firstClassName,secondClassName font-size:12pt\n```\n\nAttachment of a class to a node is done as per below:\n\n```\n    class nodeId1 className\n```\n\nIt is also possible to attach a class to a list of nodes in one statement:\n\n```\n    class nodeId1,nodeId2 className\n```\n\nMultiple classes can be attached at the same time as well:\n\n```\n    class nodeId1,nodeId2 className1,className2\n```\n\nA shorter form of adding a class is to attach the classname to the node using the `:::`operator as per below:\n\n```mermaid-example\nerDiagram\n    direction TB\n    CAR:::someclass {\n        string registrationNumber\n        string make\n        string model\n    }\n    PERSON:::someclass {\n        string firstName\n        string lastName\n        int age\n    }\n    HOUSE:::someclass\n\n    classDef someclass fill:#f96\n```\n\nThis form can be used when declaring relationships between entities:\n\n```mermaid-example\nerDiagram\n    CAR {\n        string registrationNumber\n        string make\n        string model\n    }\n    PERSON {\n        string firstName\n        string lastName\n        int age\n    }\n    PERSON:::foo ||--|| CAR : owns\n    PERSON o{--|| HOUSE:::bar : has\n\n    classDef foo stroke:#f00\n    classDef bar stroke:#0f0\n    classDef foobar stroke:#00f\n```\n\nSimilar to the class statement, the shorthand syntax can also apply multiple classes at once:\n\n```\n    nodeId:::className1,className2\n```\n\n### Default class\n\nIf a class is named default it will be assigned to all classes without specific class definitions.\n\n```\n    classDef default fill:#f9f,stroke:#333,stroke-width:4px;\n```\n\n> **Note:** Custom styles from style or other class statements take priority and will overwrite the default styles. (e.g. The `default` class gives nodes a background color of pink but the `blue` class will give that node a background color of blue if applied.)\n\n```mermaid-example\nerDiagram\n    CAR {\n        string registrationNumber\n        string make\n        string model\n    }\n    PERSON {\n        string firstName\n        string lastName\n        int age\n    }\n    PERSON:::foo ||--|| CAR : owns\n    PERSON o{--|| HOUSE:::bar : has\n\n    classDef default fill:#f9f,stroke-width:4px\n    classDef foo stroke:#f00\n    classDef bar stroke:#0f0\n    classDef foobar stroke:#00f\n```\n\n## Configuration\n\n### Layout\n\nThe layout of the diagram is handled by [`render()`](../config/setup/mermaid/interfaces/Mermaid.md#render). The default layout is the ELK (Eclipse Layout Kernel) layout, which suits larger and more-complex diagrams. For more information, see [Customizing ELK Layout](../intro/syntax-reference.md#customizing-elk-layout).\n\nTo use the classic Dagre layout instead, set it in your YAML frontmatter's `config`:\n\n```yaml\n---\nconfig:\n  layout: dagre\n---\n```\n\nYour Mermaid code should be similar to the following:\n\n```mermaid-example\n---\ntitle: Order example\nconfig:\n    layout: dagre\n---\nerDiagram\n    CUSTOMER ||--o{ ORDER : places\n    ORDER ||--|{ LINE-ITEM : contains\n    CUSTOMER }|..|{ DELIVERY-ADDRESS : uses\n```\n\n\n","isInternal":false,"tokens":4885,"sizeBytes":20370},{"name":"eventmodeling.md","path":"packages/mermaid/src/docs/syntax/eventmodeling.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/eventmodeling.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"# Event Modeling Diagram (v11.15.0+)\n\n## Introduction\n\n> **Event Modeling** (EM) is a method of describing systems using an example of how information has changed within them over time. Event Modeling specifically omits transient details and looks at what the information flow is and what the user sees at any particular point in time.\n\nYou can read more at [Event Modeling web page](https://eventmodeling.org/).\n\nEvent Modeling diagram is composed of a few main entities:\n\n- Trigger - UI and Processor\n- Command\n- View / Read Model\n- Event\n\nEntities are organized in swimlanes forming a timeline usually based on the following patterns:\n\n- State View\n- State Change\n- Translation\n- Automation\n\nYou can find more details in the [cheat sheet](https://eventmodeling.org/posts/event-modeling-cheatsheet/).\n\nThe purpose of the Domain Specific Language (DSL) supporting the drawing of the Event Modeling diagram is the rapid creation. Relations among the entities are inferred by default, so the distraction while you design is limited. Further detail to the entities can be added gradually.\n\nThe grammar for the DSL is also maintained in a [separate project](https://github.com/lgazo/event-modeling-dsl) with the intention to provide also different types of output, VS Code (and potentially other) IDEs, etc.\n\n## Basic Syntax\n\nThe DSL supports two types of syntaxes - compact and relaxed one. Both will be mentioned in the examples and both can be used interchangeably.\n\n### Timeline\n\nThe timeline is the key part of the diagram and it is composed of **Time Frame** definitions. Speedy Time Frame typing is the key of the compact notation. For compact notation you type the `tf` token. For the relaxed notation you type `timeframe` token.\n\n```md\neventmodeling\n\ntf 01 ui CartUI\ntf 02 cmd AddItem\ntf 03 evt ItemAdded\n```\n\nrendering to\n\n```mermaid\neventmodeling\n\ntf 01 ui CartUI\ntf 02 cmd AddItem\ntf 03 evt ItemAdded\n```\n\nEach Time Frame is referenced by a **unique number** in order to distinguish one from another and also to be able to reference it when needed. Depending on the complexity of the diagram it should be enough to have just two digit number or more. Imagine you are typing a BASIC program on your ZX Spectrum always starting with a two digit number, but the order of the numbers does not matter, just the uniqueness in the whole timeline.\n\nReusing a number for another Time Frame or Reset Frame produces an error. Give each frame its own number before referring to it with `->>`.\n\nThe Time Frame also contains an **Entity Identifier**, e.g. in case of `01` Time Frame it is `CartUI`. One Entity Identifier can be used multiple times in the timeline for example when you want to express invocations of the same event in different points in time.\n\nRelaxed notation would look like this:\n\n```md\neventmodeling\n\ntimeframe 01 ui CartUI\ntimeframe 02 command AddItem\ntimeframe 03 event ItemAdded\n```\n\n### Inline data\n\nIt is possible to provide data examples for individual Time Frames. An Inline Data is wrapped in curly brackets on the same line as the Time Frame.\n\nCompact version:\n\n```mermaid-example\neventmodeling\n\ntf 01 ui CartUI\ntf 02 cmd AddItem { description: string }\ntf 03 evt ItemAdded { description: string }\n```\n\nRelaxed version:\n\n```mermaid-example\neventmodeling\n\ntimeframe 01 ui CartUI\ntimeframe 02 command AddItem { description: string }\ntimeframe 03 event ItemAdded { description: string }\n```\n\n### Data block\n\nIf you need to provide more complex data description, you can define the **Data Block** separately. Data Block is referenced from a Time Frame by providing the identifier inside of double-square brackets `[[identifier]]`, similar to wiki links convention in Markdown.\n\nIn case the same entity is repeated you need to uniquely identify the data blocks, therefore the Data Block identifier is suffixed with a number.\n\nCompact version:\n\n```mermaid-example\neventmodeling\n\ntf 01 ui CartUI\ntf 02 cmd AddItem [[AddItem01]]\ntf 03 evt ItemAdded [[ItemAdded]]\ntf 04 cmd AddItem [[AddItem02]]\ntf 05 evt ItemAdded [[ItemAdded]]\n\ndata AddItem01 {\n  description: 'john'\n  image: 'avatar_john'\n  price: 20.4\n}\n\ndata AddItem02 {\n  description: 'jack'\n  image: 'avatar_jack'\n  price: 12.5\n}\n\ndata ItemAdded {\n  description: string\n  image: string\n  price: number\n}\n```\n\nRelaxed version:\n\n```mermaid-example\neventmodeling\n\ntimeframe 01 ui CartUI\ntimeframe 02 command AddItem [[AddItem01]]\ntimeframe 03 event ItemAdded [[ItemAdded]]\ntimeframe 04 command AddItem [[AddItem02]]\ntimeframe 05 event ItemAdded [[ItemAdded]]\n\ndata AddItem01 {\n  description: 'john'\n  image: 'avatar_john'\n  price: 20.4\n}\n\ndata AddItem02 {\n  description: 'jack'\n  image: 'avatar_jack'\n  price: 12.5\n}\n\ndata ItemAdded {\n  description: string\n  image: string\n  price: number\n}\n```\n\n### Resetting the flow\n\nBy default the diagram builds the relations based on the inference. But modeling a more complex business flow requires to break such inference from time to time. For that you can use a different type of Time Frame called **Reset Frame**. It is represented by a `rf` / `resetframe` token.\n\nA reset frame stops the inferred relation from the preceding frame. You can still connect it to a specific earlier frame with `->>`.\n\nCompact version:\n\n```mermaid-example\neventmodeling\n\ntf 01 ui CartUI\ntf 02 cmd AddItem\ntf 03 evt ItemAdded\n\nrf 04 evt External.InventoryChanged\ntf 05 pcr InventoryProcessor\ntf 06 cmd ChangeInventory\ntf 07 evt Cart.InventoryChanged\n```\n\nRelaxed version:\n\n```mermaid-example\neventmodeling\n\ntimeframe 01 ui CartUI\ntimeframe 02 command AddItem\ntimeframe 03 event ItemAdded\n\nresetframe 04 event External.InventoryChanged\ntimeframe 05 processor InventoryProcessor\ntimeframe 06 command ChangeInventory\ntimeframe 07 event Cart.InventoryChanged\n```\n\nFor example, this read model receives input from `ItemAdded` without inferring a relation from `OtherUI`:\n\n```mermaid-example\neventmodeling\n\ntf 01 evt ItemAdded\ntf 02 ui OtherUI\nrf 03 rmo CartItems ->> 01\n```\n\n### Multiple relations\n\nThere are situations where you need to specify multiple relations for an entity. For example when a **Read Model** is built of multiple **Events**. You can use `->>` token for that.\n\n```mermaid-example\neventmodeling\n\nrf 02 evt CartCreated\nrf 03 evt ItemAdded\nrf 04 evt ItemRemoved\nrf 05 evt CartCleared\ntf 01 rmo CartUI ->> 02 ->> 03 ->> 04 ->> 05\n```\n\n## Event Modeling patterns\n\nThis chapter briefly summarizes each Event Modeling pattern.\n\n### State Change\n\n```mermaid-example\neventmodeling\n\ntf 01 ui CartUI\ntf 02 cmd AddItem\ntf 03 evt ItemAdded\n```\n\n### State View\n\n```mermaid-example\neventmodeling\n\ntf 03 evt ItemAdded\ntf 02 rmo CartItems\ntf 04 ui CartUI\n```\n\n### Translation\n\n```mermaid-example\neventmodeling\n\ntf 03 evt External.InventoryChanged\ntf 02 pcr InventoryProcessor\ntf 04 cmd ChangeInventory\ntf 05 evt Cart.InventoryChanged\n```\n\n## Details of the Syntax\n\n### Entity types\n\nEntity type is determined by the third column in the Time Frame grammar.\n\nCompact version:\n\n```md\ntf 01 pcr InventoryProcessor\n```\n\nRelaxed version:\n\n```md\ntimeframe 01 processor InventoryProcessor\n```\n\nEntities are assigned to default swimlanes unless a **Namespace** is specified in the Entity Identifier.\n\nThere are the following types available:\n\n- `ui`: UI - belongs to UI/Automation swimlane\n- `pcr` / `processor`: Processor - belongs to UI/Automation swimlane\n- `cmd` / `command`: Command - belongs to Command/Read Model swimlane\n- `rmo` / `readmodel`: Read Model - belongs to Command/Read Model swimlane\n- `evt` / `event`: Event - belongs to Events swimlane\n\n### Swimlanes and Namespaces\n\nThere are three basic **Swimlanes** inferred from the Entity Type.\n\n- UI/Automation\n- Command/Read Model\n- Events\n\nAs your diagram grows and you explore the depths of a particular software system, you want to categorize your Entities as well. In order to do that, you can use **Namespace** identifier as part of the Entity Identifier.\n\n```md\nInventory.InventoryChanged\n```\n\n**Namespace** is the first part before the `.` of the Entity Identifier. Each combination of the Namespace and Entity type forms new Swimlane. The order how they are specified in the text definition specifies the order of the Swimlanes in the diagram.\n\n```mermaid-example\neventmodeling\n\nrf 01 evt Inventory.InventoryChanged\nrf 02 evt External.InventoryChanged\n```\n\n### Data block data types\n\nA **Data** is always wrapped in curly brackets. It can be prepended by a data type in backticks. The pattern applies for **Inline Data** as well as for **Data Block**.\n\n```md\ntf 01 rmo UserAdded `json`{ \"name\": \"foo\" }\n```\n\nor for Data Block\n\n```md\ndata UserAdded01 `json`{\n\"name\": \"foo\"\n}\n```\n\n```warning\nThere is no special treatment in the diagram renderer at the moment for a specific data type.\n```\n\nSupported types are:\n\n- `json`\n- `jsobj`\n- `figma`\n- `salt`\n- `uri`\n- `md`\n- `html`\n- `text`\n","isInternal":false,"tokens":2171,"sizeBytes":8837},{"name":"examples.md","path":"packages/mermaid/src/docs/syntax/examples.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/examples.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"# Examples\n\nThis page contains a collection of examples of diagrams and charts that can be created through mermaid and its myriad applications.\n\n**If you wish to learn how to support mermaid on your webpage, read the [Beginner's Guide](../config/usage.md?id=usage).**\n\n**If you wish to learn about mermaid's syntax, Read the [Diagram Syntax](../syntax/flowchart.md?id=flowcharts-basic-syntax) section.**\n\n## Basic Pie Chart\n\n```mermaid-example\npie title NETFLIX\n         \"Time spent looking for movie\" : 90\n         \"Time spent watching it\" : 10\n```\n\n```mermaid-example\npie title What Voldemort doesn't have?\n         \"FRIENDS\" : 2\n         \"FAMILY\" : 3\n         \"NOSE\" : 45\n```\n\n## Basic sequence diagram\n\n```mermaid-example\nsequenceDiagram\n    Alice ->> Bob: Hello Bob, how are you?\n    Bob-->>John: How about you John?\n    Bob--x Alice: I am good thanks!\n    Bob-x John: I am good thanks!\n    Note right of John: Bob thinks a long
long time, so long
that the text does
not fit on a row.\n\n    Bob-->Alice: Checking with John...\n    Alice->John: Yes... John, how are you?\n```\n\n## Basic flowchart\n\n```mermaid-example\ngraph LR\n    A[Square Rect] -- Link text --> B((Circle))\n    A --> C(Round Rect)\n    B --> D{Rhombus}\n    C --> D\n```\n\n## Larger flowchart with some styling\n\n```mermaid-example\ngraph TB\n    sq[Square shape] --> ci((Circle shape))\n\n    subgraph A\n        od>Odd shape]-- Two line
edge comment --> ro\n        di{Diamond with 
 line break} -.-> ro(Rounded
square
shape)\n        di==>ro2(Rounded square shape)\n    end\n\n    %% Notice that no text in shape are added here instead that is appended further down\n    e --> od3>Really long text with linebreak
in an Odd shape]\n\n    %% Comments after double percent signs\n    e((Inner / circle
and some odd 
special characters)) --> f(,.?!+-*ز)\n\n    cyr[Cyrillic]-->cyr2((Circle shape Начало));\n\n     classDef green fill:#9f6,stroke:#333,stroke-width:2px;\n     classDef orange fill:#f96,stroke:#333,stroke-width:4px;\n     class sq,e green\n     class di orange\n```\n\n## SequenceDiagram: Loops, alt and opt\n\n```mermaid-example\nsequenceDiagram\n    loop Daily query\n        Alice->>Bob: Hello Bob, how are you?\n        alt is sick\n            Bob->>Alice: Not so good :(\n        else is well\n            Bob->>Alice: Feeling fresh like a daisy\n        end\n\n        opt Extra response\n            Bob->>Alice: Thanks for asking\n        end\n    end\n```\n\n## SequenceDiagram: Message to self in loop\n\n```mermaid-example\nsequenceDiagram\n    participant Alice\n    participant Bob\n    Alice->>John: Hello John, how are you?\n    loop HealthCheck\n        John->>John: Fight against hypochondria\n    end\n    Note right of John: Rational thoughts
prevail...\n    John-->>Alice: Great!\n    John->>Bob: How about you?\n    Bob-->>John: Jolly good!\n```\n\n## Sequence Diagram: Blogging app service communication\n\n```mermaid-example\nsequenceDiagram\n    participant web as Web Browser\n    participant blog as Blog Service\n    participant account as Account Service\n    participant mail as Mail Service\n    participant db as Storage\n\n    Note over web,db: The user must be logged in to submit blog posts\n    web->>+account: Logs in using credentials\n    account->>db: Query stored accounts\n    db->>account: Respond with query result\n\n    alt Credentials not found\n        account->>web: Invalid credentials\n    else Credentials found\n        account->>-web: Successfully logged in\n\n        Note over web,db: When the user is authenticated, they can now submit new posts\n        web->>+blog: Submit new post\n        blog->>db: Store post data\n\n        par Notifications\n            blog--)mail: Send mail to blog subscribers\n            blog--)db: Store in-site notifications\n        and Response\n            blog-->>-web: Successfully posted\n        end\n    end\n\n```\n\n## A commit flow diagram.\n\n```mermaid-example\ngitGraph:\n    commit \"Ashish\"\n    branch newbranch\n    checkout newbranch\n    commit id:\"1111\"\n    commit tag:\"test\"\n    checkout main\n    commit type: HIGHLIGHT\n    commit\n    merge newbranch\n    commit\n    branch b2\n    commit\n```\n\n\n","isInternal":false,"tokens":1074,"sizeBytes":4167},{"name":"flowchart.md","path":"packages/mermaid/src/docs/syntax/flowchart.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/flowchart.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"---\ntitle: Flowcharts Syntax\n---\n\n# Flowcharts - Basic Syntax\n\nFlowcharts are composed of **nodes** (geometric shapes) and **edges** (arrows or lines). The Mermaid code defines how nodes and edges are made and accommodates different arrow types, multi-directional arrows, and any linking to and from subgraphs.\n\n```warning\nIf you are using the word \"end\" in a Flowchart node, capitalize the entire word or any of the letters (e.g., \"End\" or \"END\"), or apply this [workaround](https://github.com/mermaid-js/mermaid/issues/1444#issuecomment-639528897). Typing \"end\" in all lowercase letters will break the Flowchart.\n```\n\n```warning\nIf you are using the letter \"o\" or \"x\" as the first letter in a connecting Flowchart node, add a space before the letter or capitalize the letter (e.g., \"dev--- ops\", \"dev---Ops\").\n\nTyping \"A---oB\" will create a [circle edge](#circle-edge-example).\n\nTyping \"A---xB\" will create a [cross edge](#cross-edge-example).\n```\n\n### A node (default)\n\n```mermaid-example\n---\ntitle: Node\n---\nflowchart LR\n    id\n```\n\n```note\nThe id is what is displayed in the box.\n```\n\n```tip\nInstead of `flowchart` one can also use `graph`.\n```\n\n### A node with text\n\nIt is also possible to set text in the box that differs from the id. If this is done several times, it is the last text\nfound for the node that will be used. Also if you define edges for the node later on, you can omit text definitions. The\none previously defined will be used when rendering the box.\n\n```mermaid-example\n---\ntitle: Node with text\n---\nflowchart LR\n    id1[This is the text in the box]\n```\n\n#### Unicode text\n\nUse `\"` to enclose the unicode text.\n\n```mermaid-example\nflowchart LR\n    id[\"This ❤ Unicode\"]\n```\n\n#### Markdown formatting\n\nUse double quotes and backticks \"\\` text \\`\" to enclose the markdown text.\n\n```mermaid-example\n---\nconfig:\n  htmlLabels: false\n---\nflowchart LR\n    markdown[\"`This **is** _Markdown_`\"]\n    newLines[\"`Line1\n    Line 2\n    Line 3`\"]\n    markdown --> newLines\n```\n\n### Direction\n\nThis statement declares the direction of the Flowchart.\n\nThis declares the flowchart is oriented from top to bottom (`TD` or `TB`).\n\n```mermaid-example\nflowchart TD\n    Start --> Stop\n```\n\nThis declares the flowchart is oriented from left to right (`LR`).\n\n```mermaid-example\nflowchart LR\n    Start --> Stop\n```\n\nPossible FlowChart orientations are:\n\n- TB - Top to bottom\n- TD - Top-down/ same as top to bottom\n- BT - Bottom to top\n- RL - Right to left\n- LR - Left to right\n\n## Default theme, look and layout (v12.0.0+)\n\nFlowcharts use the `redux-color` theme and the `neo` look by default, and are laid out by [ELK](https://www.eclipse.org/elk/) rather than Dagre. Not every diagram type\ndoes — see [Per-diagram defaults](../config/theming.md#per-diagram-defaults) for the list and\nfor the order in which Mermaid decides.\n\nThe same diagram, drawn both ways:\n\n### With the defaults\n\n```mermaid-example\nflowchart LR\n  subgraph Client\n    UI[Web app]\n    Cache[(Local cache)]\n  end\n  subgraph Services\n    API[API gateway]\n    Auth[Auth service]\n    Orders[Order service]\n  end\n  subgraph Storage\n    DB[(Orders DB)]\n  end\n  UI --> API\n  UI --> Cache\n  API --> Auth\n  API --> Orders\n  Orders --> DB\n  Auth -. token .-> UI\n```\n\n### The previous appearance\n\nBoth are only defaults, so anything you set yourself wins. Naming the previous theme and look\nin a diagram's front matter draws it the way Mermaid did before:\n\n```mermaid-example\n---\nconfig:\n  theme: default\n  look: classic\n  layout: dagre\n---\nflowchart LR\n  subgraph Client\n    UI[Web app]\n    Cache[(Local cache)]\n  end\n  subgraph Services\n    API[API gateway]\n    Auth[Auth service]\n    Orders[Order service]\n  end\n  subgraph Storage\n    DB[(Orders DB)]\n  end\n  UI --> API\n  UI --> Cache\n  API --> Auth\n  API --> Orders\n  Orders --> DB\n  Auth -. token .-> UI\n```\n\nPassing the same three keys to `mermaid.initialize()` does it for every diagram on the page,\nand scoping the theme and look to one diagram type — `mermaid.initialize({ layout: 'dagre', flowchart: { theme: 'default', look: 'classic' } })` —\ndoes it for that type alone. `layout` is a top-level option, so it applies to every diagram.\n\n## Node shapes\n\n### A node with round edges\n\n```mermaid-example\nflowchart LR\n    id1(This is the text in the box)\n```\n\n### A stadium-shaped node\n\n```mermaid-example\nflowchart LR\n    id1([This is the text in the box])\n```\n\n### A node in a subroutine shape\n\n```mermaid-example\nflowchart LR\n    id1[[This is the text in the box]]\n```\n\n### A node in a cylindrical shape\n\n```mermaid-example\nflowchart LR\n    id1[(Database)]\n```\n\n### A node in the form of a circle\n\n```mermaid-example\nflowchart LR\n    id1((This is the text in the circle))\n```\n\n### A node in an asymmetric shape\n\n```mermaid-example\nflowchart LR\n    id1>This is the text in the box]\n```\n\nCurrently only the shape above is possible and not its mirror. _This might change with future releases._\n\n### A node (rhombus)\n\n```mermaid-example\nflowchart LR\n    id1{This is the text in the box}\n```\n\n### A hexagon node\n\n```mermaid-example\nflowchart LR\n    id1{{This is the text in the box}}\n```\n\n### Parallelogram\n\n```mermaid-example\nflowchart TD\n    id1[/This is the text in the box/]\n```\n\n### Parallelogram alt\n\n```mermaid-example\nflowchart TD\n    id1[\\This is the text in the box\\]\n```\n\n### Trapezoid\n\n```mermaid-example\nflowchart TD\n    A[/Christmas\\]\n```\n\n### Trapezoid alt\n\n```mermaid-example\nflowchart TD\n    B[\\Go shopping/]\n```\n\n### Double circle\n\n```mermaid-example\nflowchart TD\n    id1(((This is the text in the circle)))\n```\n\n## Expanded Node Shapes in Mermaid Flowcharts (v11.3.0+)\n\nMermaid introduces 30 new shapes to enhance the flexibility and precision of flowchart creation. These new shapes provide more options to represent processes, decisions, events, data storage visually, and other elements within your flowcharts, improving clarity and semantic meaning.\n\nNew Syntax for Shape Definition\n\nMermaid now supports a general syntax for defining shape types to accommodate the growing number of shapes. This syntax allows you to assign specific shapes to nodes using a clear and flexible format:\n\n```\nA@{ shape: rect }\n```\n\nThis syntax creates a node A as a rectangle. It renders in the same way as `A[\"A\"]`, or `A`.\n\n### Complete List of New Shapes\n\nBelow is a comprehensive list of the newly introduced shapes and their corresponding semantic meanings, short names, and aliases:\n\n\n\n### Example Flowchart with New Shapes\n\nHere’s an example flowchart that utilizes some of the newly introduced shapes:\n\n```mermaid-example\nflowchart RL\n    A@{ shape: manual-file, label: \"File Handling\"}\n    B@{ shape: manual-input, label: \"User Input\"}\n    C@{ shape: docs, label: \"Multiple Documents\"}\n    D@{ shape: procs, label: \"Process Automation\"}\n    E@{ shape: paper-tape, label: \"Paper Records\"}\n```\n\n### Process\n\n```mermaid-example\nflowchart TD\n    A@{ shape: rect, label: \"This is a process\" }\n```\n\n### Event\n\n```mermaid-example\nflowchart TD\n    A@{ shape: rounded, label: \"This is an event\" }\n```\n\n### Terminal Point (Stadium)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: stadium, label: \"Terminal point\" }\n```\n\n### Subprocess\n\n```mermaid-example\nflowchart TD\n    A@{ shape: subproc, label: \"This is a subprocess\" }\n```\n\n### Database (Cylinder)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: cyl, label: \"Database\" }\n```\n\n### Start (Circle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: circle, label: \"Start\" }\n```\n\n### Odd\n\n```mermaid-example\nflowchart TD\n    A@{ shape: odd, label: \"Odd shape\" }\n```\n\n### Decision (Diamond)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: diamond, label: \"Decision\" }\n```\n\n### Prepare Conditional (Hexagon)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: hex, label: \"Prepare conditional\" }\n```\n\n### Data Input/Output (Lean Right)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: lean-r, label: \"Input/Output\" }\n```\n\n### Data Input/Output (Lean Left)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: lean-l, label: \"Output/Input\" }\n```\n\n### Datastore (Top and bottom border)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: datastore, label: \"Datastore\" }\n```\n\n### Priority Action (Trapezoid Base Bottom)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: trap-b, label: \"Priority action\" }\n```\n\n### Manual Operation (Trapezoid Base Top)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: trap-t, label: \"Manual operation\" }\n```\n\n### Stop (Double Circle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: dbl-circ, label: \"Stop\" }\n```\n\n### Text Block\n\n```mermaid-example\nflowchart TD\n    A@{ shape: text, label: \"This is a text block\" }\n```\n\n### Card (Notched Rectangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: notch-rect, label: \"Card\" }\n```\n\n### Lined/Shaded Process\n\n```mermaid-example\nflowchart TD\n    A@{ shape: lin-rect, label: \"Lined process\" }\n```\n\n### Start (Small Circle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: sm-circ, label: \"Small start\" }\n```\n\n### Stop (Framed Circle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: framed-circle, label: \"Stop\" }\n```\n\n### Fork/Join (Long Rectangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: fork, label: \"Fork or Join\" }\n```\n\n### Collate (Hourglass)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: hourglass, label: \"Collate\" }\n```\n\n### Comment (Curly Brace)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: comment, label: \"Comment\" }\n```\n\n### Comment Right (Curly Brace Right)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: brace-r, label: \"Comment\" }\n```\n\n### Comment with braces on both sides\n\n```mermaid-example\nflowchart TD\n    A@{ shape: braces, label: \"Comment\" }\n```\n\n### Com Link (Lightning Bolt)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: bolt, label: \"Communication link\" }\n```\n\n### Document\n\n```mermaid-example\nflowchart TD\n    A@{ shape: doc, label: \"Document\" }\n```\n\n### Delay (Half-Rounded Rectangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: delay, label: \"Delay\" }\n```\n\n### Direct Access Storage (Horizontal Cylinder)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: das, label: \"Direct access storage\" }\n```\n\n### Disk Storage (Lined Cylinder)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: lin-cyl, label: \"Disk storage\" }\n```\n\n### Display (Curved Trapezoid)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: curv-trap, label: \"Display\" }\n```\n\n### Divided Process (Divided Rectangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: div-rect, label: \"Divided process\" }\n```\n\n### Extract (Small Triangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: tri, label: \"Extract\" }\n```\n\n### Internal Storage (Window Pane)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: win-pane, label: \"Internal storage\" }\n```\n\n### Junction (Filled Circle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: f-circ, label: \"Junction\" }\n```\n\n### Lined Document\n\n```mermaid-example\nflowchart TD\n    A@{ shape: lin-doc, label: \"Lined document\" }\n```\n\n### Loop Limit (Notched Pentagon)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: notch-pent, label: \"Loop limit\" }\n```\n\n### Manual File (Flipped Triangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: flip-tri, label: \"Manual file\" }\n```\n\n### Manual Input (Sloped Rectangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: sl-rect, label: \"Manual input\" }\n```\n\n### Multi-Document (Stacked Document)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: docs, label: \"Multiple documents\" }\n```\n\n### Multi-Process (Stacked Rectangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: processes, label: \"Multiple processes\" }\n```\n\n### Paper Tape (Flag)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: flag, label: \"Paper tape\" }\n```\n\n### Stored Data (Bow Tie Rectangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: bow-rect, label: \"Stored data\" }\n```\n\n### Summary (Crossed Circle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: cross-circ, label: \"Summary\" }\n```\n\n### Tagged Document\n\n```mermaid-example\nflowchart TD\n    A@{ shape: tag-doc, label: \"Tagged document\" }\n```\n\n### Tagged Process (Tagged Rectangle)\n\n```mermaid-example\nflowchart TD\n    A@{ shape: tag-rect, label: \"Tagged process\" }\n```\n\n## Special shapes in Mermaid Flowcharts (v11.3.0+)\n\nMermaid also introduces 2 special shapes to enhance your flowcharts: **icon** and **image**. These shapes allow you to include icons and images directly within your flowcharts, providing more visual context and clarity.\n\n### Icon Shape\n\nYou can use the `icon` shape to include an icon in your flowchart. To use icons, you need to register the icon pack first. Follow the instructions to [add custom icons](../config/icons.md). The syntax for defining an icon shape is as follows:\n\n```mermaid-example\nflowchart TD\n    A@{ icon: \"fa:user\", form: \"square\", label: \"User Icon\", pos: \"t\", h: 60 }\n```\n\n#### Parameters\n\n- **icon**: The name of the icon from the registered icon pack.\n- **form**: Specifies the background shape of the icon. If not defined there will be no background to icon. Options include:\n  - `square`\n  - `circle`\n  - `rounded`\n- **label**: The text label associated with the icon. This can be any string. If not defined, no label will be displayed.\n- **pos**: The position of the label. If not defined label will default to bottom of icon. Possible values are:\n  - `t`\n  - `b`\n- **h**: The height of the icon. If not defined this will default to 48 which is minimum.\n\n### Image Shape\n\nYou can use the `image` shape to include an image in your flowchart. The syntax for defining an image shape is as follows:\n\n```\nflowchart TD\n    A@{ img: \"https://example.com/image.png\", label: \"Image Label\", pos: \"t\", w: 60, h: 60, constraint: \"off\" }\n```\n\n#### Parameters\n\n- **img**: The URL of the image to be displayed.\n- **label**: The text label associated with the image. This can be any string. If not defined, no label will be displayed.\n- **pos**: The position of the label. If not defined, the label will default to the bottom of the image. Possible values are:\n  - `t`\n  - `b`\n- **w**: The width of the image. If not defined, this will default to the natural width of the image.\n- **h**: The height of the image. If not defined, this will default to the natural height of the image.\n- **constraint**: Determines if the image should constrain the node size. This setting also ensures the image maintains its original aspect ratio, adjusting the width (`w`) accordingly to the height (`h`). If not defined, this will default to `off` Possible values are:\n  - `on`\n  - `off`\n\nIf you want to resize an image, but keep the same aspect ratio, set `h`, and set `constraint: on` to constrain the aspect ratio. E.g.\n\n```mermaid\nflowchart TD\n  %% My image with a constrained aspect ratio\n  A@{ img: \"https://mermaid.js.org/favicon.svg\", label: \"My example image label\", pos: \"t\", h: 60, constraint: \"on\" }\n```\n\n## Links between nodes\n\nNodes can be connected with links/edges. It is possible to have different types of links or attach a text string to a link.\n\n### A link with arrow head\n\n```mermaid-example\nflowchart LR\n    A-->B\n```\n\n### An open link\n\n```mermaid-example\nflowchart LR\n    A --- B\n```\n\n### Text on links\n\n```mermaid-example\nflowchart LR\n    A-- This is the text! ---B\n```\n\nor\n\n```mermaid-example\nflowchart LR\n    A---|This is the text|B\n```\n\n### A link with arrow head and text\n\n```mermaid-example\nflowchart LR\n    A-->|text|B\n```\n\nor\n\n```mermaid-example\nflowchart LR\n    A-- text -->B\n```\n\n### Dotted link\n\n```mermaid-example\nflowchart LR\n   A-.->B;\n```\n\n### Dotted link with text\n\n```mermaid-example\nflowchart LR\n   A-. text .-> B\n```\n\n### Thick link\n\n```mermaid-example\nflowchart LR\n   A ==> B\n```\n\n### Thick link with text\n\n```mermaid-example\nflowchart LR\n   A == text ==> B\n```\n\n### An invisible link\n\nThis can be a useful tool in some instances where you want to alter the default positioning of a node.\n\n```mermaid-example\nflowchart LR\n    A ~~~ B\n```\n\n### Chaining of links\n\nIt is possible declare many links in the same line as per below:\n\n```mermaid-example\nflowchart LR\n   A -- text --> B -- text2 --> C\n```\n\nIt is also possible to declare multiple nodes links in the same line as per below:\n\n```mermaid-example\nflowchart LR\n   a --> b & c--> d\n```\n\nYou can then describe dependencies in a very expressive way. Like the one-liner below:\n\n```mermaid-example\nflowchart TB\n    A & B--> C & D\n```\n\nIf you describe the same diagram using the basic syntax, it will take four lines. A\nword of warning, one could go overboard with this making the flowchart harder to read in\nmarkdown form. The Swedish word `lagom` comes to mind. It means, not too much and not too little.\nThis goes for expressive syntaxes as well.\n\n```mermaid\nflowchart TB\n    A --> C\n    A --> D\n    B --> C\n    B --> D\n```\n\n### Attaching an ID to Edges\n\nMermaid now supports assigning IDs to edges, similar to how IDs and metadata can be attached to nodes. This feature lays the groundwork for more advanced styling, classes, and animation capabilities on edges.\n\n**Syntax:**\n\nTo give an edge an ID, prepend the edge syntax with the ID followed by an `@` character. For example:\n\n```mermaid\nflowchart LR\n  A e1@--> B\n```\n\nIn this example, `e1` is the ID of the edge connecting `A` to `B`. You can then use this ID in later definitions or style statements, just like with nodes.\n\n### Turning an Animation On\n\nOnce you have assigned an ID to an edge, you can turn on animations for that edge by defining the edge’s properties:\n\n```mermaid\nflowchart LR\n  A e1@==> B\n  e1@{ animate: true }\n```\n\nThis tells Mermaid that the edge `e1` should be animated.\n\n### Selecting Type of Animation\n\nIn the initial version, two animation speeds are supported: `fast` and `slow`. Selecting a specific animation type is a shorthand for enabling animation and setting the animation speed in one go.\n\n**Examples:**\n\n```mermaid\nflowchart LR\n  A e1@--> B\n  e1@{ animation: fast }\n```\n\nThis is equivalent to `{ animate: true, animation: fast }`.\n\n### Using classDef Statements for Animations\n\nYou can also animate edges by assigning a class to them and then defining animation properties in a `classDef` statement. For example:\n\n```mermaid\nflowchart LR\n  A e1@--> B\n  classDef animate stroke-dasharray: 9,5,stroke-dashoffset: 900,animation: dash 25s linear infinite;\n  class e1 animate\n```\n\nIn this snippet:\n\n- `e1@-->` creates an edge with ID `e1`.\n- `classDef animate` defines a class named `animate` with styling and animation properties.\n- `class e1 animate` applies the `animate` class to the edge `e1`.\n\n**Note on Escaping Commas:**\nWhen setting the `stroke-dasharray` property, remember to escape commas as `\\,` since commas are used as delimiters in Mermaid’s style definitions.\n\n## New arrow types\n\nThere are new types of arrows supported:\n\n- circle edge\n- cross edge\n\n### Circle edge example\n\n```mermaid-example\nflowchart LR\n    A --o B\n```\n\n### Cross edge example\n\n```mermaid-example\nflowchart LR\n    A --x B\n```\n\n## Multi directional arrows\n\nThere is the possibility to use multidirectional arrows.\n\n```mermaid-example\nflowchart LR\n    A o--o B\n    B <--> C\n    C x--x D\n```\n\n### Minimum length of a link\n\nEach node in the flowchart is ultimately assigned to a rank in the rendered\ngraph, i.e. to a vertical or horizontal level (depending on the flowchart\norientation), based on the nodes to which it is linked. By default, links\ncan span any number of ranks, but you can ask for any link to be longer\nthan the others by adding extra dashes in the link definition.\n\nIn the following example, two extra dashes are added in the link from node _B_\nto node _E_, so that it spans two more ranks than regular links:\n\n```mermaid-example\nflowchart TD\n    A[Start] --> B{Is it?}\n    B -->|Yes| C[OK]\n    C --> D[Rethink]\n    D --> B\n    B ---->|No| E[End]\n```\n\n> **Note** Links may still be made longer than the requested number of ranks\n> by the rendering engine to accommodate other requests.\n\nWhen the link label is written in the middle of the link, the extra dashes must\nbe added on the right side of the link. The following example is equivalent to\nthe previous one:\n\n```mermaid-example\nflowchart TD\n    A[Start] --> B{Is it?}\n    B -- Yes --> C[OK]\n    C --> D[Rethink]\n    D --> B\n    B -- No ----> E[End]\n```\n\nFor dotted or thick links, the characters to add are equals signs or dots,\nas summed up in the following table:\n\n| Length            |   1    |    2    |    3     |\n| ----------------- | :----: | :-----: | :------: |\n| Normal            | `---`  | `----`  | `-----`  |\n| Normal with arrow | `-->`  | `--->`  | `---->`  |\n| Thick             | `===`  | `====`  | `=====`  |\n| Thick with arrow  | `==>`  | `===>`  | `====>`  |\n| Dotted            | `-.-`  | `-..-`  | `-...-`  |\n| Dotted with arrow | `-.->` | `-..->` | `-...->` |\n\n## Special characters that break syntax\n\nIt is possible to put text within quotes in order to render more troublesome characters. As in the example below:\n\n```mermaid-example\nflowchart LR\n    id1[\"This is the (text) in the box\"]\n```\n\n### Entity codes to escape characters\n\nIt is possible to escape characters using the syntax exemplified here.\n\n```mermaid-example\n    flowchart LR\n        A[\"A double quote:#quot;\"] --> B[\"A dec char:#9829;\"]\n```\n\nNumbers given are base 10, so `#` can be encoded as `#35;`. It is also supported to use HTML character names.\n\n## Subgraphs\n\n```\nsubgraph title\n    graph definition\nend\n```\n\nAn example below:\n\n```mermaid-example\nflowchart TB\n    c1-->a2\n    subgraph one\n    a1-->a2\n    end\n    subgraph two\n    b1-->b2\n    end\n    subgraph three\n    c1-->c2\n    end\n```\n\nYou can also set an explicit id for the subgraph.\n\n```mermaid-example\nflowchart TB\n    c1-->a2\n    subgraph ide1 [one]\n    a1-->a2\n    end\n```\n\n### flowcharts\n\nWith the graphtype flowchart it is also possible to set edges to and from subgraphs as in the flowchart below.\n\n```mermaid-example\nflowchart TB\n    c1-->a2\n    subgraph one\n    a1-->a2\n    end\n    subgraph two\n    b1-->b2\n    end\n    subgraph three\n    c1-->c2\n    end\n    one --> two\n    three --> two\n    two --> c2\n```\n\n### Direction in subgraphs\n\nWith the graphtype flowcharts you can use the direction statement to set the direction which the subgraph will render like in this example.\n\n```mermaid-example\nflowchart LR\n  subgraph TOP\n    direction TB\n    subgraph B1\n        direction RL\n        i1 -->f1\n    end\n    subgraph B2\n        direction BT\n        i2 -->f2\n    end\n  end\n  A --> TOP --> B\n  B1 --> B2\n```\n\n#### Limitation\n\nIf any of a subgraph's nodes are linked to the outside, subgraph direction will be ignored. Instead the subgraph will inherit the direction of the parent graph:\n\n```mermaid-example\nflowchart LR\n    subgraph subgraph1\n        direction TB\n        top1[top] --> bottom1[bottom]\n    end\n    subgraph subgraph2\n        direction TB\n        top2[top] --> bottom2[bottom]\n    end\n    %% ^ These subgraphs are identical, except for the links to them:\n\n    %% Link *to* subgraph1: subgraph1 direction is maintained\n    outside --> subgraph1\n    %% Link *within* subgraph2:\n    %% subgraph2 inherits the direction of the top-level graph (LR)\n    outside ---> top2\n```\n\n### Collapsible subgraphs (v11.17.0+)\n\nA subgraph can be collapsed into a single compact node by attaching the metadata\n`@{ view: collapsed }` to its id. This is useful for hiding the internals of a\ngroup while still showing how it connects to the rest of the diagram.\n\n```mermaid-example\nflowchart TD\n    Start --> one\n    subgraph one [My Group]\n        A --> B\n        B --> C\n    end\n    one --> End\n    one@{ view: collapsed }\n```\n\nThe metadata is attached with the existing `id@{ ... }` statement syntax, where\n`id` is the subgraph id (use `subgraph id [Title]` to give a subgraph an explicit\nid). When a subgraph is collapsed:\n\n- Its internal nodes are hidden and it is drawn as a single node carrying the\n  subgraph's title.\n- Edges that cross the subgraph boundary are **redirected to the collapsed node**.\n- Edges that are entirely internal to the collapsed subgraph are dropped (they\n  would otherwise become self-loops on the collapsed node).\n- For nested subgraphs, a collapse resolves to the **outermost** collapsed\n  ancestor, so an edge pointing at a deeply nested node lands on the outermost\n  collapsed group.\n\n`view: expanded` is the default and renders the subgraph normally, so omitting the\nmetadata (or setting `view: expanded`) keeps the existing behavior.\n\n## Markdown Strings\n\nThe \"Markdown Strings\" feature enhances flowcharts and mind maps by offering a more versatile string type, which supports text formatting options such as bold and italics, and automatically wraps text within labels.\n\n```mermaid-example\n---\nconfig:\n  htmlLabels: false\n---\nflowchart LR\nsubgraph \"One\"\n  a(\"`The **cat**\n  in the hat`\") -- \"edge label\" --> b{{\"`The **dog** in the hog`\"}}\nend\nsubgraph \"`**Two**`\"\n  c(\"`The **cat**\n  in the hat`\") -- \"`Bold **edge label**`\" --> d(\"The dog in the hog\")\nend\n```\n\nFormatting:\n\n- For bold text, use double asterisks (`**`) before and after the text.\n- For italics, use single asterisks (`*`) before and after the text.\n- With traditional strings, you needed to add `
` tags for text to wrap in nodes. However, markdown strings automatically wrap text when it becomes too long and allows you to start a new line by simply using a newline character instead of a `
` tag.\n\nThis feature is applicable to node labels, edge labels, and subgraph labels.\n\nThe auto wrapping can be disabled by using\n\n```\n---\nconfig:\n  markdownAutoWrap: false\n---\ngraph LR\n```\n\n## Interaction\n\nIt is possible to bind a click event to a node, the click can lead to either a javascript callback or to a link which will be opened in a new browser tab.\n\n```note\nThis functionality is disabled when using `securityLevel='strict'` and enabled when using `securityLevel='loose'`.\n```\n\n```\nclick nodeId callback\nclick nodeId call callback()\n```\n\n- nodeId is the id of the node\n- callback is the name of a javascript function defined on the page displaying the graph, the function will be called with the nodeId as parameter.\n\nExamples of tooltip usage below:\n\n```html\n\n```\n\nThe tooltip text is surrounded in double quotes. The styles of the tooltip are set by the class `.mermaidTooltip`.\n\n```mermaid-example\nflowchart LR\n    A-->B\n    B-->C\n    C-->D\n    click A callback \"Tooltip for a callback\"\n    click B \"https://www.github.com\" \"This is a tooltip for a link\"\n    click C call callback() \"Tooltip for a callback\"\n    click D href \"https://www.github.com\" \"This is a tooltip for a link\"\n```\n\n> **Success** The tooltip functionality and the ability to link to urls are available from version 0.5.2.\n\n?> Due to limitations with how Docsify handles JavaScript callback functions, an alternate working demo for the above code can be viewed at [this jsfiddle](https://jsfiddle.net/yk4h7qou/2/).\n\nLinks are opened in the same browser tab/window by default. It is possible to change this by adding a link target to the click definition (`_self`, `_blank`, `_parent` and `_top` are supported):\n\n```mermaid-example\nflowchart LR\n    A-->B\n    B-->C\n    C-->D\n    D-->E\n    click A \"https://www.github.com\" _blank\n    click B \"https://www.github.com\" \"Open this in a new tab\" _blank\n    click C href \"https://www.github.com\" _blank\n    click D href \"https://www.github.com\" \"Open this in a new tab\" _blank\n```\n\nBeginner's tip—a full example using interactive links in a html context:\n\n```html\n\n  
\n    flowchart LR\n        A-->B\n        B-->C\n        C-->D\n        click A callback \"Tooltip\"\n        click B \"https://www.github.com\" \"This is a link\"\n        click C call callback() \"Tooltip\"\n        click D href \"https://www.github.com\" \"This is a link\"\n  
\n\n  \n\n```\n\n### Comments\n\nComments can be entered within a flow diagram, which will be ignored by the parser. Comments need to be on their own line, and must be prefaced with `%%` (double percent signs). Any text after the start of the comment to the next newline will be treated as a comment, including any flow syntax\n\n```mermaid\nflowchart LR\n%% this is a comment A -- text --> B{node}\n   A -- text --> B -- text2 --> C\n```\n\n## Styling and classes\n\n### Styling links\n\nIt is possible to style links. For instance, you might want to style a link that is going backwards in the flow. As links\nhave no ids in the same way as nodes, some other way of deciding what style the links should be attached to is required.\nInstead of ids, the order number of when the link was defined in the graph is used, or use default to apply to all links.\nIn the example below the style defined in the linkStyle statement will belong to the fourth link in the graph:\n\n```\nlinkStyle 3 stroke:#ff3,stroke-width:4px,color:red;\n```\n\nIt is also possible to add style to multiple links in a single statement, by separating link numbers with commas:\n\n```\nlinkStyle 1,2,7 color:blue;\n```\n\n### Styling line curves\n\nIt is possible to style the type of curve used for lines between items, if the default method does not meet your needs.\nAvailable curve styles include `basis`, `bumpX`, `bumpY`, `cardinal`, `catmullRom`, `linear`, `monotoneX`, `monotoneY`,\n`natural`, `step`, `stepAfter`, and `stepBefore`.\n\nFor a full list of available curves, including an explanation of custom curves, refer to\nthe [Shapes](https://d3js.org/d3-shape/curve) documentation in the [d3-shape](https://github.com/d3/d3-shape/) project.\n\nLine styling can be achieved in two ways:\n\n1. Change the curve style of all the lines\n2. Change the curve style of a particular line\n\n#### Diagram level curve style\n\nIn this example, a left-to-right graph uses the `stepBefore` curve style:\n\n```\n---\nconfig:\n  flowchart:\n    curve: stepBefore\n---\ngraph LR\n```\n\n#### Edge level curve style using Edge IDs (v11.10.0+)\n\nYou can assign IDs to [edges](#attaching-an-id-to-edges). After assigning an ID you can modify the line style by modifying the edge's `curve` property using the following syntax:\n\n```mermaid\nflowchart LR\n    A e1@==> B\n    A e2@--> C\n    e1@{ curve: linear }\n    e2@{ curve: natural }\n```\n\n```info\nAny edge curve style modified at the edge level overrides the diagram level style.\n```\n\n```info\nIf the same edge is modified multiple times the last modification will be rendered.\n```\n\n### Styling a node\n\nIt is possible to apply specific styles such as a thicker border or a different background color to a node.\n\n```mermaid-example\nflowchart LR\n    id1(Start)-->id2(Stop)\n    style id1 fill:#f9f,stroke:#333,stroke-width:4px\n    style id2 fill:#bbf,stroke:#f66,stroke-width:2px,color:#fff,stroke-dasharray: 5 5\n```\n\n#### Classes\n\nMore convenient than defining the style every time is to define a class of styles and attach this class to the nodes that\nshould have a different look.\n\nA class definition looks like the example below:\n\n```\n    classDef className fill:#f9f,stroke:#333,stroke-width:4px;\n```\n\nAlso, it is possible to define style to multiple classes in one statement:\n\n```\n    classDef firstClassName,secondClassName font-size:12pt;\n```\n\nAttachment of a class to a node is done as per below:\n\n```\n    class nodeId1 className;\n```\n\nIt is also possible to attach a class to a list of nodes in one statement:\n\n```\n    class nodeId1,nodeId2 className;\n```\n\nA shorter form of adding a class is to attach the classname to the node using the `:::`operator as per below:\n\n```mermaid-example\nflowchart LR\n    A:::someclass --> B\n    classDef someclass fill:#f96\n```\n\nThis form can be used when declaring multiple links between nodes:\n\n```mermaid-example\nflowchart LR\n    A:::foo & B:::bar --> C:::foobar\n    classDef foo stroke:#f00\n    classDef bar stroke:#0f0\n    classDef foobar stroke:#00f\n```\n\n### CSS classes\n\n> **Note:** Applying styles to Mermaid nodes via external CSS (e.g., `.cssClass > rect { fill: ... }`) does **not** work reliably. Mermaid's internal styles are injected with `!important` and scoped to the SVG element ID, giving them higher specificity than external CSS rules. External CSS will be silently overridden.\n>\n> The recommended approach is to use the `classDef` syntax shown in the [Classes](#classes) section above, which works correctly and is the intended styling mechanism.\n>\n> If external CSS is strictly required, every property must use `!important` to override Mermaid's styles — but this is not recommended.\n\n**Working approach — use `classDef` instead:**\n\n```mermaid-example\nflowchart LR\n    A:::myStyle --> B\n    classDef myStyle fill:#ff0000,stroke:#ffff00,stroke-width:4px\n```\n\n### Default class\n\nIf a class is named default it will be assigned to all classes without specific class definitions.\n\n```\n    classDef default fill:#f9f,stroke:#333,stroke-width:4px;\n```\n\n## Basic support for fontawesome\n\nIt is possible to add icons from fontawesome.\n\nThe icons are accessed via the syntax fa:#icon class name#.\n\n```mermaid-example\nflowchart TD\n    B[\"fa:fa-twitter for peace\"]\n    B-->C[fa:fa-ban forbidden]\n    B-->D(fa:fa-spinner)\n    B-->E(A fa:fa-camera-retro perhaps?)\n```\n\nThere are two ways to display these FontAwesome icons:\n\n### Register FontAwesome icon packs (v11.7.0+)\n\nYou can register your own FontAwesome icon pack following the [\"Registering icon packs\" instructions](../config/icons.md).\n\nSupported prefixes: `fa`, `fab`, `fas`, `far`, `fal`, `fad`.\n\n```note\nNote that it will fall back to FontAwesome CSS if FontAwesome packs are not registered.\n```\n\n### Register FontAwesome CSS\n\nMermaid supports Font Awesome if the CSS is included on the website.\nMermaid does not have any restriction on the version of Font Awesome that can be used.\n\nPlease refer the [Official Font Awesome Documentation](https://fontawesome.com/start) on how to include it in your website.\n\nAdding this snippet in the `` would add support for Font Awesome v6.5.1\n\n```html\n\n```\n\n### Custom icons\n\nIt is possible to use custom icons served from Font Awesome as long as the website imports the corresponding kit.\n\nNote that this is currently a paid feature from Font Awesome.\n\nFor custom icons, you need to use the `fak` prefix.\n\n**Example**\n\n```\nflowchart TD\n    B[fa:fa-twitter] %% standard icon\n    B-->E(fak:fa-custom-icon-name) %% custom icon\n```\n\nAnd trying to render it\n\n```mermaid-example\nflowchart TD\n    B[\"fa:fa-twitter for peace\"]\n    B-->C[\"fab:fa-truck-bold a custom icon\"]\n```\n\n## Graph declarations with spaces between vertices and link and without semicolon\n\n- In graph declarations, the statements also can now end without a semicolon. After release 0.2.16, ending a graph statement with semicolon is just optional. So the below graph declaration is also valid along with the old declarations of the graph.\n\n- A single space is allowed between vertices and the link. However there should not be any space between a vertex and its text and a link and its text. The old syntax of graph declaration will also work and hence this new feature is optional and is introduced to improve readability.\n\nBelow is the new declaration of the graph edges which is also valid along with the old declaration of the graph edges.\n\n```mermaid-example\nflowchart LR\n    A[Hard edge] -->|Link text| B(Round edge)\n    B --> C{Decision}\n    C -->|One| D[Result one]\n    C -->|Two| E[Result two]\n```\n\n## Configuration\n\n### Renderer\n\nThe layout of the diagram is done with the layout algorithm. The default is\n[ELK](https://www.eclipse.org/elk/), which handles larger and more complex\ndiagrams well and is bundled with Mermaid.\n\nTo use the classic Dagre layout instead:\n\n```\nconfig:\n  layout: dagre\n```\n\nThe `flowchart-elk` diagram type still works, but is no longer needed — it\npredates `layout` and selected what is now the default.\n\nThe `defaultRenderer` option of the `flowchart`, `class` and `state` config\nsections was removed in v12. It named a rendering engine at a time when there\nwas more than one; all of its values had come to mean the same renderer, and\nits `elk` value only ever set `layout: elk` on your behalf. Use `layout`\ndirectly.\n\n### Width\n\nIt is possible to adjust the width of the rendered flowchart.\n\nThis is done by defining **mermaid.flowchartConfig** or by the CLI to use a JSON file with the configuration. How to use the CLI is described in the mermaidCLI page.\nmermaid.flowchartConfig can be set to a JSON string with config parameters or the corresponding object.\n\n```javascript\nmermaid.flowchartConfig = {\n    width: 100%\n}\n```\n\n\n","frontmatter":{"title":"Flowcharts Syntax"},"isInternal":false,"tokens":9756,"sizeBytes":36849},{"name":"gantt.md","path":"packages/mermaid/src/docs/syntax/gantt.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/gantt.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"# Gantt diagrams\n\n> A Gantt chart is a type of bar chart, first developed by Karol Adamiecki in 1896, and independently by Henry Gantt in the 1910s, that illustrates a project schedule and the amount of time it would take for any one project to finish. Gantt charts illustrate number of days between the start and finish dates of the terminal elements and summary elements of a project.\n\n## A note to users\n\nGantt Charts will record each scheduled task as one continuous bar that extends from the left to the right. The x axis represents time and the y records the different tasks and the order in which they are to be completed.\n\nIt is important to remember that when a date, day, or collection of dates specific to a task are \"excluded\", the Gantt Chart will accommodate those changes by extending an equal number of days, towards the right, not by creating a gap inside the task.\nAs shown here ![](./img/Gantt-excluded-days-within.png)\n\nHowever, if the excluded dates are between two tasks that are set to start consecutively, the excluded dates will be skipped graphically and left blank, and the following task will begin after the end of the excluded dates.\nAs shown here ![](./img/Gantt-long-weekend-look.png)\n\nA Gantt chart is useful for tracking the amount of time it would take before a project is finished, but it can also be used to graphically represent \"non-working days\", with a few tweaks.\n\nMermaid can render Gantt diagrams as SVG, PNG or a MarkDown link that can be pasted into docs.\n\n```mermaid-example\ngantt\n    title A Gantt Diagram\n    dateFormat YYYY-MM-DD\n    section Section\n        A task          :a1, 2014-01-01, 30d\n        Another task    :after a1, 20d\n    section Another\n        Task in Another :2014-01-12, 12d\n        another task    :24d\n```\n\n## Syntax\n\n```mermaid-example\ngantt\n    dateFormat  YYYY-MM-DD\n    title       Adding GANTT diagram functionality to mermaid\n    excludes    weekends\n    %% (`excludes` accepts specific dates in YYYY-MM-DD format, days of the week (\"sunday\") or \"weekends\", but not the word \"weekdays\".)\n\n    section A section\n    Completed task            :done,    des1, 2014-01-06,2014-01-08\n    Active task               :active,  des2, 2014-01-09, 3d\n    Future task               :         des3, after des2, 5d\n    Future task2              :         des4, after des3, 5d\n\n    section Critical tasks\n    Completed task in the critical line :crit, done, 2014-01-06,24h\n    Implement parser and jison          :crit, done, after des1, 2d\n    Create tests for parser             :crit, active, 3d\n    Future task in critical line        :crit, 5d\n    Create tests for renderer           :2d\n    Add to mermaid                      :until isadded\n    Functionality added                 :milestone, isadded, 2014-01-25, 0d\n\n    section Documentation\n    Describe gantt syntax               :active, a1, after des1, 3d\n    Add gantt diagram to demo page      :after a1  , 20h\n    Add another diagram to demo page    :doc1, after a1  , 48h\n\n    section Last section\n    Describe gantt syntax               :after doc1, 3d\n    Add gantt diagram to demo page      :20h\n    Add another diagram to demo page    :48h\n```\n\nTasks are by default sequential. A task start date defaults to the end date of the preceding task.\n\nA colon, `:`, separates the task title from its metadata.\nMetadata items are separated by a comma, `,`. Valid tags are `active`, `done`, `crit`, and `milestone`. Tags are optional, but if used, they must be specified first.\nAfter processing the tags, the remaining metadata items are interpreted as follows:\n\n1. If a single item is specified, it determines when the task ends. It can either be a specific date/time or a duration. If a duration is specified, it is added to the start date of the task to determine the end date of the task, taking into account any exclusions.\n2. If two items are specified, the last item is interpreted as in the previous case. The first item can either specify an explicit start date/time (in the format specified by `dateFormat`) or reference another task using `after  [[otherTaskID2 [otherTaskID3]]...]`. In the latter case, the start date of the task will be set according to the latest end date of any referenced task.\n3. If three items are specified, the last two will be interpreted as in the previous case. The first item will denote the ID of the task, which can be referenced using the `later ` syntax.\n\n| Metadata syntax                                      | Start date                                          | End date                                              | ID       |\n| ---------------------------------------------------- | --------------------------------------------------- | ----------------------------------------------------- | -------- |\n| `, , `                   | `startdate` as interpreted using `dateformat`       | `endDate` as interpreted using `dateformat`           | `taskID` |\n| `, , `                    | `startdate` as interpreted using `dateformat`       | Start date + `length`                                 | `taskID` |\n| `, after , `           | End date of previously specified task `otherTaskID` | `endDate` as interpreted using `dateformat`           | `taskID` |\n| `, after , `            | End date of previously specified task `otherTaskID` | Start date + `length`                                 | `taskID` |\n| `, , until `         | `startdate` as interpreted using `dateformat`       | Start date of previously specified task `otherTaskID` | `taskID` |\n| `, after , until ` | End date of previously specified task `otherTaskID` | Start date of previously specified task `otherTaskID` | `taskID` |\n| `, `                             | `startdate` as interpreted using `dateformat`       | `enddate` as interpreted using `dateformat`           | n/a      |\n| `, `                              | `startdate` as interpreted using `dateformat`       | Start date + `length`                                 | n/a      |\n| `after , `                     | End date of previously specified task `otherTaskID` | `enddate` as interpreted using `dateformat`           | n/a      |\n| `after , `                      | End date of previously specified task `otherTaskID` | Start date + `length`                                 | n/a      |\n| `, until `                   | `startdate` as interpreted using `dateformat`       | Start date of previously specified task `otherTaskID` | n/a      |\n| `after , until `           | End date of previously specified task `otherTaskID` | Start date of previously specified task `otherTaskID` | n/a      |\n| ``                                          | End date of preceding task                          | `enddate` as interpreted using `dateformat`           | n/a      |\n| ``                                           | End date of preceding task                          | Start date + `length`                                 | n/a      |\n| `until `                                | End date of preceding task                          | Start date of previously specified task `otherTaskID` | n/a      |\n\n```note\nSupport for keyword `until` was added in (v10.9.0+). This can be used to define a task which is running until some other specific task or milestone starts.\n```\n\n#### Duration format\n\nWhen specifying a ``, use a number followed by one of these unit suffixes:\n\n| Unit         | Suffix | Example |\n| ------------ | ------ | ------- |\n| Milliseconds | `ms`   | `500ms` |\n| Seconds      | `s`    | `30s`   |\n| Minutes      | `m`    | `30m`   |\n| Hours        | `h`    | `4h`    |\n| Days         | `d`    | `3d`    |\n| Weeks        | `w`    | `2w`    |\n| Months       | `M`    | `1M`    |\n| Years        | `y`    | `1y`    |\n\nDecimal values are also supported (e.g., `1.5d`). Invalid duration tokens (e.g., `3dX`) will be ignored and the task will default to zero duration.\n\nFor simplicity, the table does not show the use of multiple tasks listed with the `after` keyword. Here is an example of how to use it and how it's interpreted:\n\n```mermaid-example\ngantt\n    apple :a, 2017-07-20, 1w\n    banana :crit, b, 2017-07-23, 1d\n    cherry :active, c, after b a, 1d\n    kiwi   :d, 2017-07-20, until b c\n```\n\n### Title\n\nThe `title` is an _optional_ string to be displayed at the top of the Gantt chart to describe the chart as a whole.\n\n### Excludes\n\nThe `excludes` is an _optional_ attribute that accepts specific dates in YYYY-MM-DD format, days of the week (\"sunday\") or \"weekends\", but not the word \"weekdays\".\nThese date will be marked on the graph, and be excluded from the duration calculation of tasks. Meaning that if there are excluded dates during a task interval, the number of 'skipped' days will be added to the end of the task to ensure the duration is as specified in the code.\n\nMultiple `excludes` lines are supported and their tokens are concatenated, so long exclusion lists can be split across grouped lines with comments:\n\n```\ngantt\n    dateFormat DD-MM-YYYY\n    excludes weekends\n    %% week 7 is winter break\n    excludes 10-02-2025 11-02-2025 12-02-2025 13-02-2025 14-02-2025\n    %% workers holiday 1 maj\n    excludes 01-05-2025\n```\n\n#### Weekend (v\\11.0.0+)\n\nWhen excluding weekends, it is possible to configure the weekends to be either Friday and Saturday or Saturday and Sunday. By default weekends are Saturday and Sunday.\nTo define the weekend start day, there is an _optional_ attribute `weekend` that can be added in a new line followed by either `friday` or `saturday`.\n\n```mermaid-example\ngantt\n    title A Gantt Diagram Excluding Fri - Sat weekends\n    dateFormat YYYY-MM-DD\n    excludes weekends\n    weekend friday\n    section Section\n        A task          :a1, 2024-01-01, 30d\n        Another task    :after a1, 20d\n```\n\n### Section statements\n\nYou can divide the chart into various sections, for example to separate different parts of a project like development and documentation.\n\nTo do so, start a line with the `section` keyword and give it a name. (Note that unlike with the [title for the entire chart](#title), this name is _required_.\n\n### Milestones\n\nYou can add milestones to the diagrams. Milestones differ from tasks as they represent a single instant in time and are identified by the keyword `milestone`. Below is an example on how to use milestones. As you may notice, the exact location of the milestone is determined by the initial date for the milestone and the \"duration\" of the task this way: _initial date_+_duration_/2.\n\n```mermaid-example\ngantt\n    dateFormat HH:mm\n    axisFormat %H:%M\n    Initial milestone : milestone, m1, 17:49, 2m\n    Task A : 10m\n    Task B : 5m\n    Final milestone : milestone, m2, 18:08, 4m\n```\n\n### Vertical Markers\n\nThe `vert` keyword lets you add vertical lines to your Gantt chart, making it easy to highlight important dates like deadlines, events, or checkpoints. These markers extend across the entire chart and are positioned based on the date you provide. Unlike milestones, vertical markers don’t take up a row. They’re purely visual reference points that help break up the timeline and make important moments easier to spot.\n\n```mermaid-example\ngantt\n    dateFormat HH:mm\n    axisFormat %H:%M\n    Initial vert : vert, v1, 17:30, 2m\n    Task A : 3m\n    Task B : 8m\n    Final vert : vert, v2, 17:58, 4m\n```\n\n## Setting dates\n\n`dateFormat` defines the format of the date **input** of your gantt elements. How these dates are represented in the rendered chart **output** are defined by `axisFormat`.\n\n### Input date format\n\nThe default input date format is `YYYY-MM-DD`. You can define your custom `dateFormat`.\n\n```markdown\ndateFormat YYYY-MM-DD\n```\n\nThe following formatting options are supported:\n\n| Input      | Example        | Description                                            |\n| ---------- | -------------- | ------------------------------------------------------ |\n| `YYYY`     | 2014           | 4 digit year                                           |\n| `YY`       | 14             | 2 digit year                                           |\n| `Q`        | 1..4           | Quarter of year. Sets month to first month in quarter. |\n| `M MM`     | 1..12          | Month number                                           |\n| `MMM MMMM` | January..Dec   | Month name in locale set by `dayjs.locale()`           |\n| `D DD`     | 1..31          | Day of month                                           |\n| `Do`       | 1st..31st      | Day of month with ordinal                              |\n| `DDD DDDD` | 1..365         | Day of year                                            |\n| `X`        | 1410715640.579 | Unix timestamp                                         |\n| `x`        | 1410715640579  | Unix ms timestamp                                      |\n| `H HH`     | 0..23          | 24 hour time                                           |\n| `h hh`     | 1..12          | 12 hour time used with `a A`.                          |\n| `a A`      | am pm          | Post or ante meridiem                                  |\n| `m mm`     | 0..59          | Minutes                                                |\n| `s ss`     | 0..59          | Seconds                                                |\n| `S`        | 0..9           | Tenths of a second                                     |\n| `SS`       | 0..99          | Hundreds of a second                                   |\n| `SSS`      | 0..999         | Thousandths of a second                                |\n| `Z ZZ`     | +12:00         | Offset from UTC as +-HH:mm, +-HHmm, or Z               |\n\nMore info in: https://day.js.org/docs/en/parse/string-format/\n\n### Output date format on the axis\n\nThe default output date format is `YYYY-MM-DD`. You can define your custom `axisFormat`, like `2020-Q1` for the first quarter of the year 2020.\n\n```markdown\naxisFormat %Y-%m-%d\n```\n\nThe following formatting strings are supported:\n\n| Format | Definition                                                                                |\n| ------ | ----------------------------------------------------------------------------------------- |\n| %a     | abbreviated weekday name                                                                  |\n| %A     | full weekday name                                                                         |\n| %b     | abbreviated month name                                                                    |\n| %B     | full month name                                                                           |\n| %c     | date and time, as \"%a %b %e %H:%M:%S %Y\"                                                  |\n| %d     | zero-padded day of the month as a decimal number [01,31]                                  |\n| %e     | space-padded day of the month as a decimal number [ 1,31]; equivalent to %\\_d             |\n| %H     | hour (24-hour clock) as a decimal number [00,23]                                          |\n| %I     | hour (12-hour clock) as a decimal number [01,12]                                          |\n| %j     | day of the year as a decimal number [001,366]                                             |\n| %m     | month as a decimal number [01,12]                                                         |\n| %M     | minute as a decimal number [00,59]                                                        |\n| %L     | milliseconds as a decimal number [000, 999]                                               |\n| %p     | either AM or PM                                                                           |\n| %S     | second as a decimal number [00,61]                                                        |\n| %U     | week number of the year (Sunday as the first day of the week) as a decimal number [00,53] |\n| %w     | weekday as a decimal number [0(Sunday),6]                                                 |\n| %W     | week number of the year (Monday as the first day of the week) as a decimal number [00,53] |\n| %x     | date, as \"%m/%d/%Y\"                                                                       |\n| %X     | time, as \"%H:%M:%S\"                                                                       |\n| %y     | year without century as a decimal number [00,99]                                          |\n| %Y     | year with century as a decimal number                                                     |\n| %Z     | time zone offset, such as \"-0700\"                                                         |\n| %%     | a literal \"%\" character                                                                   |\n\nMore info in: [https://github.com/d3/d3-time-format/tree/v4.0.0#locale_format](https://github.com/d3/d3-time-format/tree/v4.0.0#locale_format)\n\n### Axis ticks (v10.3.0+)\n\nThe default output ticks are auto. You can custom your `tickInterval`, like `1day` or `1week`.\n\n```markdown\ntickInterval 1day\n```\n\nThe pattern is:\n\n```javascript\n/^([1-9][0-9]*)(millisecond|second|minute|hour|day|week|month)$/;\n```\n\nMore info in: [https://github.com/d3/d3-time#interval_every](https://github.com/d3/d3-time#interval_every)\n\nWeek-based `tickInterval`s start the week on sunday by default. If you wish to specify another weekday on which the `tickInterval` should start, use the `weekday` option:\n\n```mermaid-example\ngantt\n  tickInterval 1week\n  weekday monday\n```\n\n```warning\n`millisecond` and `second` support was added in v10.3.0\n```\n\n## Output in compact mode\n\nThe compact mode allows you to display multiple tasks in the same row. Compact mode can be enabled for a gantt chart by setting the display mode of the graph via preceding YAML settings.\n\n```mermaid-example\n---\ndisplayMode: compact\n---\ngantt\n    title A Gantt Diagram\n    dateFormat  YYYY-MM-DD\n\n    section Section\n    A task           :a1, 2014-01-01, 30d\n    Another task     :a2, 2014-01-20, 25d\n    Another one      :a3, 2014-02-10, 20d\n```\n\n## Comments\n\nComments can be entered within a gantt chart, which will be ignored by the parser. Comments need to be on their own line and must be prefaced with `%%` (double percent signs). Any text after the start of the comment to the next newline will be treated as a comment, including any diagram syntax.\n\n```mermaid\ngantt\n    title A Gantt Diagram\n    %% This is a comment\n    dateFormat YYYY-MM-DD\n    section Section\n        A task          :a1, 2014-01-01, 30d\n        Another task    :after a1, 20d\n    section Another\n        Task in Another :2014-01-12, 12d\n        another task    :24d\n```\n\n## Styling\n\nStyling of the Gantt diagram is done by defining a number of CSS classes. During rendering, these classes are extracted from the file located at src/diagrams/gantt/styles.js\n\n### Classes used\n\n| Class                 | Description                                                            |\n| --------------------- | ---------------------------------------------------------------------- |\n| grid.tick             | Styling for the Grid Lines                                             |\n| grid.path             | Styling for the Grid's borders                                         |\n| .taskText             | Task Text Styling                                                      |\n| .taskTextOutsideRight | Styling for Task Text that exceeds the activity bar towards the right. |\n| .taskTextOutsideLeft  | Styling for Task Text that exceeds the activity bar, towards the left. |\n| todayMarker           | Toggle and Styling for the \"Today Marker\"                              |\n\n### Sample stylesheet\n\n```css\n.grid .tick {\n  stroke: lightgrey;\n  opacity: 0.3;\n  shape-rendering: crispEdges;\n}\n.grid path {\n  stroke-width: 0;\n}\n\n#tag {\n  color: white;\n  background: #fa283d;\n  width: 150px;\n  position: absolute;\n  display: none;\n  padding: 3px 6px;\n  margin-left: -80px;\n  font-size: 11px;\n}\n\n#tag:before {\n  border: solid transparent;\n  content: ' ';\n  height: 0;\n  left: 50%;\n  margin-left: -5px;\n  position: absolute;\n  width: 0;\n  border-width: 10px;\n  border-bottom-color: #fa283d;\n  top: -20px;\n}\n.taskText {\n  fill: white;\n  text-anchor: middle;\n}\n.taskTextOutsideRight {\n  fill: black;\n  text-anchor: start;\n}\n.taskTextOutsideLeft {\n  fill: black;\n  text-anchor: end;\n}\n```\n\n## Today marker\n\nYou can style or hide the marker for the current date. To style it, add a value for the `todayMarker` key.\n\n```\ntodayMarker stroke-width:5px,stroke:#0f0,opacity:0.5\n```\n\nTo hide the marker, set `todayMarker` to `off`.\n\n```\ntodayMarker off\n```\n\n## Configuration\n\nIt is possible to adjust the margins for rendering the gantt diagram.\n\nThis is done by defining the `ganttConfig` part of the configuration object.\nHow to use the CLI is described in the [mermaidCLI](../config/mermaidCLI.md) page.\n\nmermaid.ganttConfig can be set to a JSON string with config parameters or the corresponding object.\n\n```javascript\nmermaid.ganttConfig = {\n  titleTopMargin: 25, // Margin top for the text over the diagram\n  barHeight: 20, // The height of the bars in the graph\n  barGap: 4, // The margin between the different activities in the gantt diagram\n  topPadding: 75, // Margin between title and gantt diagram and between axis and gantt diagram.\n  rightPadding: 75, // The space allocated for the section name to the right of the activities\n  leftPadding: 75, // The space allocated for the section name to the left of the activities\n  gridLineStartPadding: 10, // Vertical starting position of the grid lines\n  fontSize: 12, // Font size\n  sectionFontSize: 24, // Font size for sections\n  numberSectionStyles: 1, // The number of alternating section styles\n  axisFormat: '%d/%m', // Date/time format of the axis\n  tickInterval: '1week', // Axis ticks\n  topAxis: true, // When this flag is set, date labels will be added to the top of the chart\n  displayMode: 'compact', // Turns compact mode on\n  weekday: 'sunday', // On which day a week-based interval should start\n};\n```\n\n### Possible configuration params:\n\n| Param           | Description                                                                                                                                | Default value |\n| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | ------------- |\n| mirrorActor     | Turns on/off the rendering of actors below the diagram as well as above it                                                                 | false         |\n| bottomMarginAdj | Adjusts how far down the graph ended. Wide borders styles with css could generate unwanted clipping which is why this config param exists. | 1             |\n\n## Interaction\n\nIt is possible to bind a click event to a task. The click can lead to either a javascript callback or to a link which will be opened in the current browser tab. **Note**: This functionality is disabled when using `securityLevel='strict'` and enabled when using `securityLevel='loose'`.\n\n```\nclick taskId call callback(arguments)\nclick taskId href URL\n```\n\n- taskId is the id of the task\n- callback is the name of a javascript function defined on the page displaying the graph, the function will be called with the taskId as the parameter if no other arguments are specified.\n\nBeginner's tip—a full example using interactive links in an HTML context:\n\n```html\n\n  
\n    gantt\n      dateFormat  YYYY-MM-DD\n\n      section Clickable\n      Visit mermaidjs         :active, cl1, 2014-01-07, 3d\n      Print arguments         :cl2, after cl1, 3d\n      Print task              :cl3, after cl2, 3d\n\n      click cl1 href \"https://mermaidjs.github.io/\"\n      click cl2 call printArguments(\"test1\", \"test2\", test3)\n      click cl3 call printTask()\n  
\n\n  \n\n```\n\n## Examples\n\n### Bar chart (using gantt chart)\n\n```mermaid-example\ngantt\n    title Git Issues - days since last update\n    dateFormat X\n    axisFormat %s\n    section Issue19062\n    71   : 0, 71\n    section Issue19401\n    36   : 0, 36\n    section Issue193\n    34   : 0, 34\n    section Issue7441\n    9    : 0, 9\n    section Issue1300\n    5    : 0, 5\n```\n\n### Timeline (with comments, CSS, config in frontmatter)\n\n```mermaid-example\n---\n    # Frontmatter config, YAML comments\n    title: Ignored if specified in chart\n    displayMode: compact     #gantt specific setting but works at this level too\n    config:\n#        theme: forest\n#        themeCSS: \" #item36 { fill: CadetBlue } \"\n        themeCSS: \" // YAML supports multiline strings using a newline markers: \\n\n            #item36 { fill: CadetBlue }       \\n\n\n            // Custom marker workaround CSS from forum (below)    \\n\n            rect[id^=workaround] { height: calc(100% - 50px) ; transform: translate(9px, 25px); y: 0; width: 1.5px; stroke: none; fill: red; }   \\n\n            text[id^=workaround] { fill: red; y: 100%; font-size: 15px;}\n        \"\n        gantt:\n            useWidth: 400\n            rightPadding: 0\n            topAxis: true  #false\n            numberSectionStyles: 2\n---\ngantt\n    title Timeline - Gantt Sampler\n    dateFormat YYYY\n    axisFormat %y\n    %% this next line doesn't recognise 'decade' or 'year', but will silently ignore\n    tickInterval 1decade\n\n    section Issue19062\n    71   :            item71, 1900, 1930\n    section Issue19401\n    36   :            item36, 1913, 1935\n    section Issue1300\n    94   :            item94, 1910, 1915\n    5    :            item5,  1920, 1925\n    0    : milestone, item0,  1918, 1s\n    9    : vert,              1906, 1s   %% not yet official\n    64   : workaround,        1923, 1s   %% custom CSS object https://github.com/mermaid-js/mermaid/issues/3250\n```\n\n\n","isInternal":false,"tokens":6288,"sizeBytes":26391},{"name":"gitgraph.md","path":"packages/mermaid/src/docs/syntax/gitgraph.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/gitgraph.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"# GitGraph Diagrams\n\n> A Git Graph is a pictorial representation of git commits and git actions(commands) on various branches.\n\nThese kind of diagram are particularly helpful to developers and devops teams to share their Git branching strategies. For example, it makes it easier to visualize how git flow works.\n\nMermaid can render Git diagrams\n\n```mermaid-example\n---\ntitle: Example Git diagram\n---\ngitGraph\n   commit\n   commit\n   branch develop\n   checkout develop\n   commit\n   commit\n   checkout main\n   merge develop\n   commit\n   commit\n```\n\nIn Mermaid, we support the basic git operations like:\n\n- _commit_ : Representing a new commit on the current branch.\n- _branch_ : To create & switch to a new branch, setting it as the current branch.\n- _checkout_ : To checking out an existing branch and setting it as the current branch.\n- _merge_ : To merge an existing branch onto the current branch.\n\nWith the help of these key git commands, you will be able to draw a gitgraph in Mermaid very easily and quickly.\nEntity names are often capitalized, although there is no accepted standard on this, and it is not required in Mermaid.\n\n**NOTE**: `checkout` and `switch` can be used interchangeably.\n\n## Syntax\n\nMermaid syntax for a gitgraph is very straight-forward and simple. It follows a declarative-approach, where each commit is drawn on the timeline in the diagram, in order of its occurrences/presence in code. Basically, it follows the insertion order for each command.\n\nFirst thing you do is to declare your diagram type using the **gitgraph** keyword. This `gitgraph` keyword, tells Mermaid that you wish to draw a gitgraph, and parse the diagram code accordingly.\n\nEach gitgraph, is initialized with **_main_** branch. So unless you create a different branch, by-default the commits will go to the main branch. This is driven with how git works, where in the beginning you always start with the main branch (formerly called as **_master_** branch). And by-default, `main` branch is set as your **_current branch_**.\n\nYou make use of **_commit_** keyword to register a commit on the current branch. Let see how this works:\n\nA simple gitgraph showing three commits on the default (**_main_**) branch:\n\n```mermaid-example\n    gitGraph\n       commit\n       commit\n       commit\n```\n\nIf you look closely at the previous example, you can see the default branch `main` along with three commits. Also, notice that by default each commit has been given a unique & random ID. What if you wanted to give your own custom ID to a commit? Yes, it is possible to do that with Mermaid.\n\n### Adding custom commit id\n\nFor a given commit you may specify a custom ID at the time of declaring it using the `id` attribute, followed by `:` and your custom value within a `\"\"` quote. For example: `commit id: \"your_custom_id\"`\n\nLet us see how this works with the help of the following diagram:\n\n```mermaid-example\n    gitGraph\n       commit id: \"Alpha\"\n       commit id: \"Beta\"\n       commit id: \"Gamma\"\n```\n\nIn this example, we have given our custom IDs to the commits.\n\n### Modifying commit type\n\nIn Mermaid, a commit can be of three type, which render a bit different in the diagram. These types are:\n\n- `NORMAL` : Default commit type. Represented by a solid circle in the diagram\n- `REVERSE` : To emphasize a commit as a reverse commit. Represented by a crossed solid circle in the diagram.\n- `HIGHLIGHT` : To highlight a particular commit in the diagram. Represented by a filled rectangle in the diagram.\n\nFor a given commit you may specify its type at the time of declaring it using the `type` attribute, followed by `:` and the required type option discussed above. For example: `commit type: HIGHLIGHT`\n\nNOTE: If no commit type is specified, `NORMAL` is picked as default.\n\nLet us see how these different commit type look with the help of the following diagram:\n\n```mermaid-example\n    gitGraph\n       commit id: \"Normal\"\n       commit\n       commit id: \"Reverse\" type: REVERSE\n       commit\n       commit id: \"Highlight\" type: HIGHLIGHT\n       commit\n```\n\nIn this example, we have specified different types to each commit. Also, see how we have included both `id` and `type` together at the time of declaring our commits.\n\n### Adding Tags\n\nFor a given commit you may decorate it as a **tag**, similar to the concept of tags or release version in git world.\nYou can attach a custom tag at the time of declaring a commit using the `tag` attribute, followed by `:` and your custom value within `\"\"` quote. For example: `commit tag: \"your_custom_tag\"`\n\nLet us see how this works with the help of the following diagram:\n\n```mermaid-example\n    gitGraph\n       commit\n       commit id: \"Normal\" tag: \"v1.0.0\"\n       commit\n       commit id: \"Reverse\" type: REVERSE tag: \"RC_1\"\n       commit\n       commit id: \"Highlight\" type: HIGHLIGHT tag: \"8.8.4\"\n       commit\n```\n\nIn this example, we have given custom tags to the commits. Also, see how we have combined all these attributes in a single commit declaration. You can mix-match these attributes as you like.\n\n### Create a new branch\n\nIn Mermaid, in-order to create a new branch, you make use of the `branch` keyword. You also need to provide a name of the new branch. The name has to be unique and cannot be that of an existing branch. A branch name that could be confused for a keyword must be quoted within `\"\"`. Usage examples: `branch develop`, `branch \"cherry-pick\"`\n\nWhen Mermaid, reads the `branch` keyword, it creates a new branch and sets it as the current branch. Equivalent to you creating a new branch and checking it out in Git world.\n\nLet see this in an example:\n\n```mermaid-example\n    gitGraph\n       commit\n       commit\n       branch develop\n       commit\n       commit\n       commit\n```\n\nIn this example, see how we started with default `main` branch, and pushed two commits on that.\nThen we created the `develop` branch, and all commits afterwards are put on the `develop` branch as it became the current branch.\n\n### Checking out an existing branch\n\nIn Mermaid, in order to switch to an existing branch, you make use of the `checkout` keyword. You also need to provide a name of an existing branch. If no branch is found with the given name, it will result in console error. Usage example: `checkout develop`\n\nWhen Mermaid, reads the `checkout` keyword, it finds the given branch and sets it as the current branch. Equivalent to checking out a branch in the Git world.\n\nLet see modify our previous example:\n\n```mermaid-example\n    gitGraph\n       commit\n       commit\n       branch develop\n       commit\n       commit\n       commit\n       checkout main\n       commit\n       commit\n```\n\nIn this example, see how we started with default `main` branch, and pushed two commits on that.\nThen we created the `develop` branch, and all three commits afterwards are put on the `develop` branch as it became the current branch.\nAfter this we made use of the `checkout` keyword to set the current branch as `main`, and all commit that follow are registered against the current branch, i.e. `main`.\n\n### Merging two branches\n\nIn Mermaid, in order to merge or join to an existing branch, you make use of the `merge` keyword. You also need to provide the name of an existing branch to merge from. If no branch is found with the given name, it will result in console error. Also, you can only merge two separate branches, and cannot merge a branch with itself. In such case an error is throw.\n\nUsage example: `merge develop`\n\nWhen Mermaid, reads the `merge` keyword, it finds the given branch and its head commit (the last commit on that branch), and joins it with the head commit on the **current branch**. Each merge results in a **_merge commit_**, represented in the diagram with **filled double circle**.\n\nLet us modify our previous example to merge our two branches:\n\n```mermaid-example\n    gitGraph\n       commit\n       commit\n       branch develop\n       commit\n       commit\n       commit\n       checkout main\n       commit\n       commit\n       merge develop\n       commit\n       commit\n```\n\nIn this example, see how we started with default `main` branch, and pushed two commits on that.\nThen we created the `develop` branch, and all three commits afterwards are put on the `develop` branch as it became the current branch.\nAfter this we made use of the `checkout` keyword to set the current branch as `main`, and all commits that follow are registered against the current branch, i.e. `main`.\nAfter this we merge the `develop` branch onto the current branch `main`, resulting in a merge commit.\nSince the current branch at this point is still `main`, the last two commits are registered against that.\n\nYou can also decorate your merge with similar attributes as you did for the commit using:\n\n- `id`--> To override the default ID with custom ID\n- `tag`--> To add a custom tag to your merge commit\n- `type`--> To override the default shape of merge commit. Here you can use other commit type mentioned earlier.\n\nAnd you can choose to use none, some or all of these attributes together.\nFor example: `merge develop id: \"my_custom_id\" tag: \"my_custom_tag\" type: REVERSE`\n\nLet us see how this works with the help of the following diagram:\n\n```mermaid-example\n    gitGraph\n       commit id: \"1\"\n       commit id: \"2\"\n       branch nice_feature\n       checkout nice_feature\n       commit id: \"3\"\n       checkout main\n       commit id: \"4\"\n       checkout nice_feature\n       branch very_nice_feature\n       checkout very_nice_feature\n       commit id: \"5\"\n       checkout main\n       commit id: \"6\"\n       checkout nice_feature\n       commit id: \"7\"\n       checkout main\n       merge nice_feature id: \"customID\" tag: \"customTag\" type: REVERSE\n       checkout very_nice_feature\n       commit id: \"8\"\n       checkout main\n       commit id: \"9\"\n```\n\n### Cherry Pick commit from another branch\n\nSimilar to how 'git' allows you to cherry-pick a commit from **another branch** onto the **current** branch, Mermaid also supports this functionality. You can also cherry-pick a commit from another branch using the `cherry-pick` keyword.\n\nTo use the `cherry-pick` keyword, you must specify the id using the `id` attribute, followed by `:` and your desired commit id within a `\"\"` quote. For example:\n\n`cherry-pick id: \"your_custom_id\"`\n\nHere, a new commit representing the cherry-pick is created on the current branch, and is visually highlighted in the diagram with a **cherry** and a tag depicting the commit id from which it is cherry-picked from.\n\nA few important rules to note here are:\n\n1. You need to provide the `id` for an existing commit to be cherry-picked. If given commit id does not exist it will result in an error. For this, make use of the `commit id:$value` format of declaring commits. See the examples from above.\n2. The given commit must not exist on the current branch. The cherry-picked commit must always be a different branch than the current branch.\n3. Current branch must have at least one commit, before you can cherry-pick, otherwise it will cause an error is throw.\n4. When cherry-picking a merge commit, providing a parent commit ID is mandatory. If the parent attribute is omitted or an invalid parent commit ID is provided, an error will be thrown.\n5. The specified parent commit must be an immediate parent of the merge commit being cherry-picked.\n\nLet see an example:\n\n```mermaid-example\n    gitGraph\n        commit id: \"ZERO\"\n        branch develop\n        branch release\n        commit id:\"A\"\n        checkout main\n        commit id:\"ONE\"\n        checkout develop\n        commit id:\"B\"\n        checkout main\n        merge develop id:\"MERGE\"\n        commit id:\"TWO\"\n        checkout release\n        cherry-pick id:\"MERGE\" parent:\"B\"\n        commit id:\"THREE\"\n        checkout develop\n        commit id:\"C\"\n```\n\n## GitGraph specific configuration options\n\nIn Mermaid, you have the option to configure the gitgraph diagram. You can configure the following options:\n\n- `showBranches` : Boolean, default is `true`. If set to `false`, the branches are not shown in the diagram.\n- `showCommitLabel` : Boolean, default is `true`. If set to `false`, the commit labels are not shown in the diagram.\n- `mainBranchName` : String, default is `main`. The name of the default/root branch.\n- `mainBranchOrder` : Position of the main branch in the list of branches. default is `0`, meaning, by default `main` branch is the first in the order.\n- `parallelCommits`: Boolean, default is `false`. If set to `true`, commits x distance away from the parent are shown at the same level in the diagram.\n\nLet's look at them one by one.\n\n## Hiding Branch names and lines\n\nSometimes you may want to hide the branch names and lines from the diagram. You can do this by using the `showBranches` keyword. By default its value is `true`. You can set it to `false` using directives.\n\nUsage example:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'base'\n  gitGraph:\n    showBranches: false\n---\n      gitGraph\n        commit\n        branch hotfix\n        checkout hotfix\n        commit\n        branch develop\n        checkout develop\n        commit id:\"ash\" tag:\"abc\"\n        branch featureB\n        checkout featureB\n        commit type:HIGHLIGHT\n        checkout main\n        checkout hotfix\n        commit type:NORMAL\n        checkout develop\n        commit type:REVERSE\n        checkout featureB\n        commit\n        checkout main\n        merge hotfix\n        checkout featureB\n        commit\n        checkout develop\n        branch featureA\n        commit\n        checkout develop\n        merge hotfix\n        checkout featureA\n        commit\n        checkout featureB\n        commit\n        checkout develop\n        merge featureA\n        branch release\n        checkout release\n        commit\n        checkout main\n        commit\n        checkout release\n        merge main\n        checkout develop\n        merge release\n```\n\n## Commit labels Layout: Rotated or Horizontal\n\nMermaid supports two types of commit labels layout. The default layout is **rotated**, which means the labels are placed below the commit circle, rotated at 45 degrees for better readability. This is particularly useful for commits with long labels.\n\nThe other option is **horizontal**, which means the labels are placed below the commit circle centred horizontally, and are not rotated. This is particularly useful for commits with short labels.\n\nYou can change the layout of the commit labels by using the `rotateCommitLabel` keyword in the directive. It defaults to `true`, which means the commit labels are rotated.\n\nUsage example: Rotated commit labels\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'base'\n  gitGraph:\n    rotateCommitLabel: true\n---\ngitGraph\n  commit id: \"feat(api): ...\"\n  commit id: \"a\"\n  commit id: \"b\"\n  commit id: \"fix(client): .extra long label..\"\n  branch c2\n  commit id: \"feat(modules): ...\"\n  commit id: \"test(client): ...\"\n  checkout main\n  commit id: \"fix(api): ...\"\n  commit id: \"ci: ...\"\n  branch b1\n  commit\n  branch b2\n  commit\n```\n\nUsage example: Horizontal commit labels\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'base'\n  gitGraph:\n    rotateCommitLabel: false\n---\ngitGraph\n  commit id: \"feat(api): ...\"\n  commit id: \"a\"\n  commit id: \"b\"\n  commit id: \"fix(client): .extra long label..\"\n  branch c2\n  commit id: \"feat(modules): ...\"\n  commit id: \"test(client): ...\"\n  checkout main\n  commit id: \"fix(api): ...\"\n  commit id: \"ci: ...\"\n  branch b1\n  commit\n  branch b2\n  commit\n```\n\n## Hiding commit labels\n\nSometimes you may want to hide the commit labels from the diagram. You can do this by using the `showCommitLabel` keyword. By default its value is `true`. You can set it to `false` using directives.\n\nUsage example:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'base'\n  gitGraph:\n    showBranches: false\n    showCommitLabel: false\n---\n      gitGraph\n        commit\n        branch hotfix\n        checkout hotfix\n        commit\n        branch develop\n        checkout develop\n        commit id:\"ash\"\n        branch featureB\n        checkout featureB\n        commit type:HIGHLIGHT\n        checkout main\n        checkout hotfix\n        commit type:NORMAL\n        checkout develop\n        commit type:REVERSE\n        checkout featureB\n        commit\n        checkout main\n        merge hotfix\n        checkout featureB\n        commit\n        checkout develop\n        branch featureA\n        commit\n        checkout develop\n        merge hotfix\n        checkout featureA\n        commit\n        checkout featureB\n        commit\n        checkout develop\n        merge featureA\n        branch release\n        checkout release\n        commit\n        checkout main\n        commit\n        checkout release\n        merge main\n        checkout develop\n        merge release\n```\n\n## Customizing main branch name\n\nSometimes you may want to customize the name of the main/default branch. You can do this by using the `mainBranchName` keyword. By default its value is `main`. You can set it to any string using directives.\n\nUsage example:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'base'\n  gitGraph:\n    showBranches: true\n    showCommitLabel: true\n    mainBranchName: 'MetroLine1'\n---\n      gitGraph\n        commit id:\"NewYork\"\n        commit id:\"Dallas\"\n        branch MetroLine2\n        commit id:\"LosAngeles\"\n        commit id:\"Chicago\"\n        commit id:\"Houston\"\n        branch MetroLine3\n        commit id:\"Phoenix\"\n        commit type: HIGHLIGHT id:\"Denver\"\n        commit id:\"Boston\"\n        checkout MetroLine1\n        commit id:\"Atlanta\"\n        merge MetroLine3\n        commit id:\"Miami\"\n        commit id:\"Washington\"\n        merge MetroLine2 tag:\"MY JUNCTION\"\n        commit id:\"Boston\"\n        commit id:\"Detroit\"\n        commit type:REVERSE id:\"SanFrancisco\"\n```\n\nLook at the imaginary railroad map created using Mermaid. Here, we have changed the default main branch name to `MetroLine1`.\n\n## Customizing branch ordering\n\nIn Mermaid, by default the branches are shown in the order of their definition or appearance in the diagram code.\n\nSometimes you may want to customize the order of the branches. You can do this by using the `order` keyword next the branch definition. You can set it to a positive number.\n\nMermaid follows the given precedence order of the `order` keyword.\n\n- Main branch is always shown first as it has default order value of `0`. (unless its order is modified and changed from `0` using the `mainBranchOrder` keyword in the config)\n- Next, All branches without an `order` are shown in the order of their appearance in the diagram code.\n- Next, All branches with an `order` are shown in the order of their `order` value.\n\nTo fully control the order of all the branches, you must define `order` for all the branches.\n\nUsage example:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'base'\n  gitGraph:\n    showBranches: true\n    showCommitLabel: true\n---\n      gitGraph\n      commit\n      branch test1 order: 3\n      branch test2 order: 2\n      branch test3 order: 1\n\n```\n\nLook at the diagram, all the branches are following the order defined.\n\nUsage example:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'base'\n  gitGraph:\n    showBranches: true\n    showCommitLabel: true\n    mainBranchOrder: 2\n---\n      gitGraph\n      commit\n      branch test1 order: 3\n      branch test2\n      branch test3\n      branch test4 order: 1\n\n```\n\nLook at the diagram, here, all the branches without a specified order are drawn in their order of definition.\nThen, `test4` branch is drawn because the order of `1`.\nThen, `main` branch is drawn because the order of `2`.\nAnd, lastly `test1`is drawn because the order of `3`.\n\nNOTE: Because we have overridden the `mainBranchOrder` to `2`, the `main` branch is not drawn in the beginning, instead follows the ordering.\n\nHere, we have changed the default main branch name to `MetroLine1`.\n\n## Orientation (v10.3.0+)\n\nMermaid supports three graph orientations: **Left-to-Right** (default), **Top-to-Bottom**, and **Bottom-to-Top**.\n\nYou can set this with either `LR:` (for [**Left-to-Right**](#left-to-right-default-lr)), `TB:` (for [**Top-to-Bottom**](#top-to-bottom-tb)) or `BT:` (for [**Bottom-to-Top**](#bottom-to-top-bt)) after `gitGraph`.\n\n### Left to Right (default, `LR:`)\n\nIn Mermaid, the default orientation is for commits to run from left to right and for branches to be stacked on top of one another.\n\nHowever, you can set this explicitly with `LR:` after `gitGraph`.\n\nUsage example:\n\n```mermaid-example\n    gitGraph LR:\n       commit\n       commit\n       branch develop\n       commit\n       commit\n       checkout main\n       commit\n       commit\n       merge develop\n       commit\n       commit\n```\n\n### Top to Bottom (`TB:`)\n\nIn `TB` (**Top-to-Bottom**) orientation, the commits run from top to bottom of the graph and branches are arranged side-by-side.\n\nTo orient the graph this way, you need to add `TB:` after gitGraph.\n\nUsage example:\n\n```mermaid-example\n    gitGraph TB:\n       commit\n       commit\n       branch develop\n       commit\n       commit\n       checkout main\n       commit\n       commit\n       merge develop\n       commit\n       commit\n```\n\n### Bottom to Top (`BT:`) (v11.0.0+)\n\nIn `BT` (**Bottom-to-Top**) orientation, the commits run from bottom to top of the graph and branches are arranged side-by-side.\n\nTo orient the graph this way, you need to add `BT:` after gitGraph.\n\nUsage example:\n\n```mermaid-example\n    gitGraph BT:\n       commit\n       commit\n       branch develop\n       commit\n       commit\n       checkout main\n       commit\n       commit\n       merge develop\n       commit\n       commit\n```\n\n## Parallel commits (v10.8.0+)\n\nCommits in Mermaid display temporal information in gitgraph by default. For example if two commits are one commit away from its parent, the commit that was made earlier is rendered closer to its parent. You can turn this off by enabling the `parallelCommits` flag.\n\n### Temporal Commits (default, `parallelCommits: false`)\n\n```mermaid-example\n---\nconfig:\n  gitGraph:\n    parallelCommits: false\n---\ngitGraph:\n  commit\n  branch develop\n  commit\n  commit\n  checkout main\n  commit\n  commit\n```\n\n### Parallel commits (`parallelCommits: true`)\n\n```mermaid-example\n---\nconfig:\n  gitGraph:\n    parallelCommits: true\n---\ngitGraph:\n  commit\n  branch develop\n  commit\n  commit\n  checkout main\n  commit\n  commit\n```\n\n## Themes\n\nMermaid supports a bunch of pre-defined themes which you can use to find the right one for you. PS: you can actually override an existing theme's variable to get your own custom theme going. Learn more about [theming your diagram](../config/theming.md).\n\nThe following are the different pre-defined theme options:\n\n- `redux-color` (the default)\n- `redux-dark-color`\n- `redux`\n- `redux-dark`\n- `default`\n- `neutral`\n- `dark`\n- `forest`\n- `neo`\n- `neo-dark`\n- `base`\n\n**NOTE**: To change theme you can either use the `initialize` call or _directives_. Learn more about [directives](../config/directives.md)\nLet's put a few of them to use, and see how our sample diagram looks in different themes:\n\n### Base Theme\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'base'\n---\n      gitGraph\n        commit\n        branch hotfix\n        checkout hotfix\n        commit\n        branch develop\n        checkout develop\n        commit id:\"ash\" tag:\"abc\"\n        branch featureB\n        checkout featureB\n        commit type:HIGHLIGHT\n        checkout main\n        checkout hotfix\n        commit type:NORMAL\n        checkout develop\n        commit type:REVERSE\n        checkout featureB\n        commit\n        checkout main\n        merge hotfix\n        checkout featureB\n        commit\n        checkout develop\n        branch featureA\n        commit\n        checkout develop\n        merge hotfix\n        checkout featureA\n        commit\n        checkout featureB\n        commit\n        checkout develop\n        merge featureA\n        branch release\n        checkout release\n        commit\n        checkout main\n        commit\n        checkout release\n        merge main\n        checkout develop\n        merge release\n```\n\n### Forest Theme\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'forest'\n---\n      gitGraph\n        commit\n        branch hotfix\n        checkout hotfix\n        commit\n        branch develop\n        checkout develop\n        commit id:\"ash\" tag:\"abc\"\n        branch featureB\n        checkout featureB\n        commit type:HIGHLIGHT\n        checkout main\n        checkout hotfix\n        commit type:NORMAL\n        checkout develop\n        commit type:REVERSE\n        checkout featureB\n        commit\n        checkout main\n        merge hotfix\n        checkout featureB\n        commit\n        checkout develop\n        branch featureA\n        commit\n        checkout develop\n        merge hotfix\n        checkout featureA\n        commit\n        checkout featureB\n        commit\n        checkout develop\n        merge featureA\n        branch release\n        checkout release\n        commit\n        checkout main\n        commit\n        checkout release\n        merge main\n        checkout develop\n        merge release\n```\n\n### The `default` Theme\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n---\n      gitGraph\n        commit type:HIGHLIGHT\n        branch hotfix\n        checkout hotfix\n        commit\n        branch develop\n        checkout develop\n        commit id:\"ash\" tag:\"abc\"\n        branch featureB\n        checkout featureB\n        commit type:HIGHLIGHT\n        checkout main\n        checkout hotfix\n        commit type:NORMAL\n        checkout develop\n        commit type:REVERSE\n        checkout featureB\n        commit\n        checkout main\n        merge hotfix\n        checkout featureB\n        commit\n        checkout develop\n        branch featureA\n        commit\n        checkout develop\n        merge hotfix\n        checkout featureA\n        commit\n        checkout featureB\n        commit\n        checkout develop\n        merge featureA\n        branch release\n        checkout release\n        commit\n        checkout main\n        commit\n        checkout release\n        merge main\n        checkout develop\n        merge release\n```\n\n### Dark Theme\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'dark'\n---\n      gitGraph\n        commit\n        branch hotfix\n        checkout hotfix\n        commit\n        branch develop\n        checkout develop\n        commit id:\"ash\" tag:\"abc\"\n        branch featureB\n        checkout featureB\n        commit type:HIGHLIGHT\n        checkout main\n        checkout hotfix\n        commit type:NORMAL\n        checkout develop\n        commit type:REVERSE\n        checkout featureB\n        commit\n        checkout main\n        merge hotfix\n        checkout featureB\n        commit\n        checkout develop\n        branch featureA\n        commit\n        checkout develop\n        merge hotfix\n        checkout featureA\n        commit\n        checkout featureB\n        commit\n        checkout develop\n        merge featureA\n        branch release\n        checkout release\n        commit\n        checkout main\n        commit\n        checkout release\n        merge main\n        checkout develop\n        merge release\n```\n\n### Neutral Theme\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'neutral'\n---\n      gitGraph\n        commit\n        branch hotfix\n        checkout hotfix\n        commit\n        branch develop\n        checkout develop\n        commit id:\"ash\" tag:\"abc\"\n        branch featureB\n        checkout featureB\n        commit type:HIGHLIGHT\n        checkout main\n        checkout hotfix\n        commit type:NORMAL\n        checkout develop\n        commit type:REVERSE\n        checkout featureB\n        commit\n        checkout main\n        merge hotfix\n        checkout featureB\n        commit\n        checkout develop\n        branch featureA\n        commit\n        checkout develop\n        merge hotfix\n        checkout featureA\n        commit\n        checkout featureB\n        commit\n        checkout develop\n        merge featureA\n        branch release\n        checkout release\n        commit\n        checkout main\n        commit\n        checkout release\n        merge main\n        checkout develop\n        merge release\n```\n\n## Customize using Theme Variables\n\nMermaid allows you to customize your diagram using theme variables which govern the look and feel of various elements of the diagram.\n\nFor understanding let us take a sample diagram with theme `default`, the default values of the theme variables is picked automatically from the theme. Later on we will see how to override the default values of the theme variables.\n\nSee how the `default` theme is used to set the colors for the branches:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n---\n       gitGraph\n       commit\n       branch develop\n       commit tag:\"v1.0.0\"\n       commit\n       checkout main\n       commit type: HIGHLIGHT\n       commit\n       merge develop\n       commit\n       branch featureA\n       commit\n```\n\n> #### IMPORTANT:\n>\n> Mermaid supports the theme variables to override the default values for **up to 8 branches**, i.e., you can set the color/styling of up to 8 branches using theme variables. After this threshold of 8 branches, the theme variables are reused in the cyclic manner, i.e. the 9th branch will use the color/styling of the 1st branch, or the branch at index position '8' will use the color/styling of the branch at index position '0'.\n> _More on this in the next section. See examples on **Customizing branch label colors** below_\n\n### Customizing branch colors\n\nYou can customize the branch colors using the `git0` to `git7` theme variables. Mermaid allows you to set the colors for up-to 8 branches, where `git0` variable will drive the value of the first branch, `git1` will drive the value of the second branch and so on.\n\nNOTE: Default values for these theme variables are picked from the selected theme. If you want to override the default values, you can use the `initialize` call to add your custom theme variable values.\n\nExample:\n\nNow let's override the default values for the `git0` to `git3` variables:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n  themeVariables:\n      'git0': '#ff0000'\n      'git1': '#00ff00'\n      'git2': '#0000ff'\n      'git3': '#ff00ff'\n      'git4': '#00ffff'\n      'git5': '#ffff00'\n      'git6': '#ff00ff'\n      'git7': '#00ffff'\n---\n       gitGraph\n       commit\n       branch develop\n       commit tag:\"v1.0.0\"\n       commit\n       checkout main\n       commit type: HIGHLIGHT\n       commit\n       merge develop\n       commit\n       branch featureA\n       commit\n\n```\n\nSee how the branch colors are changed to the values specified in the theme variables.\n\n### Customizing branch label colors\n\nYou can customize the branch label colors using the `gitBranchLabel0` to `gitBranchLabel7` theme variables. Mermaid allows you to set the colors for up-to 8 branches, where `gitBranchLabel0` variable will drive the value of the first branch label, `gitBranchLabel1` will drive the value of the second branch label and so on.\n\nLets see how the `default` theme is used to set the colors for the branch labels:\n\nNow let's override the default values for the `gitBranchLabel0` to `gitBranchLabel2` variables:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n  themeVariables:\n    'gitBranchLabel0': '#ffffff'\n    'gitBranchLabel1': '#ffffff'\n    'gitBranchLabel2': '#ffffff'\n    'gitBranchLabel3': '#ffffff'\n    'gitBranchLabel4': '#ffffff'\n    'gitBranchLabel5': '#ffffff'\n    'gitBranchLabel6': '#ffffff'\n    'gitBranchLabel7': '#ffffff'\n    'gitBranchLabel8': '#ffffff'\n    'gitBranchLabel9': '#ffffff'\n---\n  gitGraph\n    checkout main\n    branch branch1\n    branch branch2\n    branch branch3\n    branch branch4\n    branch branch5\n    branch branch6\n    branch branch7\n    branch branch8\n    branch branch9\n    checkout branch1\n    commit\n```\n\nHere, you can see that `branch8` and `branch9` colors and the styles are being picked from branch at index position `0` (`main`) and `1`(`branch1`) respectively, i.e., **branch themeVariables are repeated cyclically**.\n\n### Customizing Commit colors\n\nYou can customize commit using the `commitLabelColor` and `commitLabelBackground` theme variables for changes in the commit label color and background color respectively.\n\nExample:\nNow let's override the default values for the `commitLabelColor` to `commitLabelBackground` variables:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n  themeVariables:\n    commitLabelColor: '#ff0000'\n    commitLabelBackground: '#00ff00'\n---\n       gitGraph\n       commit\n       branch develop\n       commit tag:\"v1.0.0\"\n       commit\n       checkout main\n       commit type: HIGHLIGHT\n       commit\n       merge develop\n       commit\n       branch featureA\n       commit\n\n```\n\nSee how the commit label color and background color are changed to the values specified in the theme variables.\n\n### Customizing Commit Label Font Size\n\nYou can customize commit using the `commitLabelFontSize` theme variables for changing in the font size of the commit label .\n\nExample:\nNow let's override the default values for the `commitLabelFontSize` variable:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n  themeVariables:\n    commitLabelColor: '#ff0000'\n    commitLabelBackground: '#00ff00'\n    commitLabelFontSize: '16px'\n---\n       gitGraph\n       commit\n       branch develop\n       commit tag:\"v1.0.0\"\n       commit\n       checkout main\n       commit type: HIGHLIGHT\n       commit\n       merge develop\n       commit\n       branch featureA\n       commit\n\n```\n\nSee how the commit label font size changed.\n\n### Customizing Tag Label Font Size\n\nYou can customize commit using the `tagLabelFontSize` theme variables for changing in the font size of the tag label .\n\nExample:\nNow let's override the default values for the `tagLabelFontSize` variable:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n  themeVariables:\n    commitLabelColor: '#ff0000'\n    commitLabelBackground: '#00ff00'\n    tagLabelFontSize: '16px'\n---\n       gitGraph\n       commit\n       branch develop\n       commit tag:\"v1.0.0\"\n       commit\n       checkout main\n       commit type: HIGHLIGHT\n       commit\n       merge develop\n       commit\n       branch featureA\n       commit\n\n```\n\nSee how the tag label font size changed.\n\n### Customizing Tag colors\n\nYou can customize tag using the `tagLabelColor`,`tagLabelBackground` and `tagLabelBorder` theme variables for changes in the tag label color,tag label background color and tag label border respectively.\nExample:\nNow let's override the default values for the `tagLabelColor`, `tagLabelBackground` and to `tagLabelBorder` variables:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n  themeVariables:\n    tagLabelColor: '#ff0000'\n    tagLabelBackground: '#00ff00'\n    tagLabelBorder: '#0000ff'\n---\n       gitGraph\n       commit\n       branch develop\n       commit tag:\"v1.0.0\"\n       commit\n       checkout main\n       commit type: HIGHLIGHT\n       commit\n       merge develop\n       commit\n       branch featureA\n       commit\n\n```\n\nSee how the tag colors are changed to the values specified in the theme variables.\n\n### Customizing Highlight commit colors\n\nYou can customize the highlight commit colors in relation to the branch it is on using the `gitInv0` to `gitInv7` theme variables. Mermaid allows you to set the colors for up-to 8 branches specific highlight commit, where `gitInv0` variable will drive the value of the first branch's highlight commits, `gitInv1` will drive the value of the second branch's highlight commit label and so on.\n\nExample:\n\nNow let's override the default values for the `git0` to `git3` variables:\n\n```mermaid-example\n---\nconfig:\n  logLevel: 'debug'\n  theme: 'default'\n  themeVariables:\n    'gitInv0': '#ff0000'\n---\n       gitGraph\n       commit\n       branch develop\n       commit tag:\"v1.0.0\"\n       commit\n       checkout main\n       commit type: HIGHLIGHT\n       commit\n       merge develop\n       commit\n       branch featureA\n       commit\n\n```\n\nSee how the highlighted commit color on the first branch is changed to the value specified in the theme variable `gitInv0`.\n","isInternal":false,"tokens":8456,"sizeBytes":36351},{"name":"ishikawa.md","path":"packages/mermaid/src/docs/syntax/ishikawa.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/ishikawa.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"# Ishikawa diagram (v11.12.3+)\n\nIshikawa diagrams are used to represent causes of a specific event (or a problem).\nThey are also known as fishbone diagrams, herringbone diagrams or cause-and-effect diagrams.\nThe diagram resembles a fish skeleton, with the main problem at the head and the causes branching off from the spine.\n\n```warning\nThis is a new diagram type in Mermaid. Its syntax may evolve in future versions.\n```\n\n## Syntax\n\n```mermaid\nishikawa-beta\n    Blurry Photo\n    Process\n        Out of focus\n        Shutter speed too slow\n        Protective film not removed\n        Beautification filter applied\n    User\n        Shaky hands\n    Equipment\n        LENS\n            Inappropriate lens\n            Damaged lens\n            Dirty lens\n        SENSOR\n            Damaged sensor\n            Dirty sensor\n    Environment\n        Subject moved too quickly\n        Too dark\n```\n\n- The first line is the event (problem) of the diagram.\n- Subsequent lines are causes of the event.\n- \"Fishbone\" structure is indicated by indentation.\n","isInternal":false,"tokens":233,"sizeBytes":1041},{"name":"kanban.md","path":"packages/mermaid/src/docs/syntax/kanban.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/kanban.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"# Mermaid Kanban Diagram Documentation\n\nMermaid’s Kanban diagram allows you to create visual representations of tasks moving through different stages of a workflow. This guide explains how to use the Kanban diagram syntax, based on the provided example.\n\n## Overview\n\nA Kanban diagram in Mermaid starts with the kanban keyword, followed by the definition of columns (stages) and tasks within those columns.\n\n```mermaid-example\nkanban\n  column1[Column Title]\n    task1[Task Description]\n```\n\n## Defining Columns\n\nColumns represent the different stages in your workflow, such as “Todo,” “In Progress,” “Done,” etc. Each column is defined using a unique identifier and a title enclosed in square brackets.\n\n**Syntax:**\n\n```\ncolumnId[Column Title]\n```\n\n- columnId: A unique identifier for the column.\n- [Column Title]: The title displayed on the column header.\n\nLike this `id1[Todo]`\n\n## Adding Tasks to Columns\n\nTasks are listed under their respective columns with an indentation. Each task also has a unique identifier and a description enclosed in square brackets.\n\n**Syntax:**\n\n```\ntaskId[Task Description]\n```\n\n    •\ttaskId: A unique identifier for the task.\n    •\t[Task Description]: The description of the task.\n\n**Example:**\n\n```\ndocs[Create Documentation]\n```\n\n## Adding Metadata to Tasks\n\nYou can include additional metadata for each task using the @{ ... } syntax. Metadata can contain key-value pairs like assigned, ticket, priority, etc. This will be rendered added to the rendering of the node.\n\n## Supported Metadata Keys\n\n    •\tassigned: Specifies who is responsible for the task.\n    •\tticket: Links the task to a ticket or issue number.\n    •\tpriority: Indicates the urgency of the task. Allowed values: 'Very High', 'High', 'Low' and 'Very Low'\n\n```mermaid-example\nkanban\ntodo[Todo]\n  id3[Update Database Function]@{ ticket: MC-2037, assigned: 'knsv', priority: 'High' }\n```\n\n## Configuration Options\n\nYou can customize the Kanban diagram using a configuration block at the beginning of your markdown file. This is useful for setting global settings like a base URL for tickets. Currently there is one configuration option for kanban diagrams `ticketBaseUrl`. This can be set as in the following example:\n\n```yaml\n---\nconfig:\n  kanban:\n    ticketBaseUrl: 'https://yourproject.atlassian.net/browse/#TICKET#'\n---\n```\n\nWhen the kanban item has an assigned ticket number the ticket number in the diagram will have a link to an external system where the ticket is defined. The `ticketBaseUrl` sets the base URL to the external system and #TICKET# is replaced with the ticket value from task metadata to create a valid link.\n\n## Full Example\n\nBelow is the full Kanban diagram based on the provided example:\n\n```mermaid-example\n---\nconfig:\n  kanban:\n    ticketBaseUrl: 'https://mermaidchart.atlassian.net/browse/#TICKET#'\n---\nkanban\n  Todo\n    [Create Documentation]\n    docs[Create Blog about the new diagram]\n  [In progress]\n    id6[Create renderer so that it works in all cases. We also add some extra text here for testing purposes. And some more just for the extra flare.]\n  id9[Ready for deploy]\n    id8[Design grammar]@{ assigned: 'knsv' }\n  id10[Ready for test]\n    id4[Create parsing tests]@{ ticket: MC-2038, assigned: 'K.Sveidqvist', priority: 'High' }\n    id66[last item]@{ priority: 'Very Low', assigned: 'knsv' }\n  id11[Done]\n    id5[define getData]\n    id2[Title of diagram is more than 100 chars when user duplicates diagram with 100 char]@{ ticket: MC-2036, priority: 'Very High'}\n    id3[Update DB function]@{ ticket: MC-2037, assigned: knsv, priority: 'High' }\n\n  id12[Can't reproduce]\n    id3[Weird flickering in Firefox]\n```\n\nIn conclusion, creating a Kanban diagram in Mermaid is a straightforward process that effectively visualizes your workflow. Start by using the kanban keyword to initiate the diagram. Define your columns with unique identifiers and titles to represent different stages of your project. Under each column, list your tasks—also with unique identifiers—and provide detailed descriptions as needed. Remember that proper indentation is crucial; tasks must be indented under their parent columns to maintain the correct structure.\n\nYou can enhance your diagram by adding optional metadata to tasks using the @{ ... } syntax, which allows you to include additional context such as assignee, ticket numbers, and priority levels. For further customization, utilize the configuration block at the top of your file to set global options like ticketBaseUrl for linking tickets directly from your diagram.\n\nBy adhering to these guidelines—ensuring unique identifiers, proper indentation, and utilizing metadata and configuration options—you can create a comprehensive and customized Kanban board that effectively maps out your project’s workflow using Mermaid.\n","isInternal":false,"tokens":1086,"sizeBytes":4836},{"name":"mindmap.md","path":"packages/mermaid/src/docs/syntax/mindmap.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/mindmap.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"# Mindmap\n\n> Mindmap: This is an experimental diagram for now. The syntax and properties can change in future releases. The syntax is stable except for the icon integration which is the experimental part.\n\n\"A mind map is a diagram used to visually organize information into a hierarchy, showing relationships among pieces of the whole. It is often created around a single concept, drawn as an image in the center of a blank page, to which associated representations of ideas such as images, words and parts of words are added. Major ideas are connected directly to the central concept, and other ideas branch out from those major ideas.\" Wikipedia\n\n### An example of a mindmap.\n\n```mermaid\nmindmap\n  root((mindmap))\n    Origins\n      Long history\n      ::icon(fa fa-book)\n      Popularisation\n        British popular psychology author Tony Buzan\n    Research\n      On effectiveness
and features\n      On Automatic creation\n        Uses\n            Creative techniques\n            Strategic planning\n            Argument mapping\n    Tools\n      Pen and paper\n      Mermaid\n\n```\n\n## Syntax\n\nThe syntax for creating Mindmaps is simple and relies on indentation for setting the levels in the hierarchy.\n\nIn the following example you can see how there are 3 different levels. One with starting at the left of the text and another level with two rows starting at the same column, defining the node A. At the end there is one more level where the text is indented further than the previous lines defining the nodes B and C.\n\n```\nmindmap\n    Root\n        A\n            B\n            C\n```\n\nIn summary is a simple text outline where there is one node at the root level called `Root` which has one child `A`. `A` in turn has two children `B`and `C`. In the diagram below we can see this rendered as a mindmap.\n\n```mermaid\nmindmap\nRoot\n    A\n      B\n      C\n```\n\nIn this way we can use a text outline to generate a hierarchical mindmap.\n\n## Different shapes\n\nMermaid mindmaps can show nodes using different shapes. When specifying a shape for a node the syntax is similar to flowchart nodes, with an id followed by the shape definition and with the text within the shape delimiters. Where possible we try/will try to keep the same shapes as for flowcharts, even though they are not all supported from the start.\n\nMindmap can show the following shapes:\n\n### Square\n\n```mermaid-example\nmindmap\n    id[I am a square]\n```\n\n### Rounded square\n\n```mermaid-example\nmindmap\n    id(I am a rounded square)\n```\n\n### Circle\n\n```mermaid-example\nmindmap\n    id((I am a circle))\n```\n\n### Bang\n\n```mermaid-example\nmindmap\n    id))I am a bang((\n```\n\n### Cloud\n\n```mermaid-example\nmindmap\n    id)I am a cloud(\n```\n\n### Hexagon\n\n```mermaid-example\nmindmap\n    id{{I am a hexagon}}\n```\n\n### Default\n\n```mermaid-example\nmindmap\n    I am the default shape\n```\n\nMore shapes will be added, beginning with the shapes available in flowcharts.\n\n## Coloring by depth (v12.2.0+)\n\nBy default, mindmaps use a different color for each top-level branch. Descendants inherit their branch's color. Set `mindmap.colorBy` to `depth` to give all nodes at the same hierarchy level the same color, across every branch:\n\n```mermaid-example\n---\nconfig:\n  mindmap:\n    colorBy: depth\n---\nmindmap\n  root((mindmap))\n    origins{{Origins}}\n      history[Long history]\n        Popularisation\n        British popular psychology author Tony Buzan\n    research{{Research}}\n      uses[Uses]\n        Creative techniques\n```\n\nDepth counts parent-child relationships, not spaces: the root has depth 0, its children have depth 1, and their children have depth 2. Uneven indentation does not change the color of nodes that share a depth.\n\nWith the classic look, the root uses `git0` for its background and `gitBranchLabel0` for its label (`redux` themes color HTML labels with `nodeBorder` instead). Depths 1 through 11 use `cScale1` through `cScale11` for backgrounds and `cScaleLabel1` through `cScaleLabel11` for labels. Deeper levels repeat those eleven colors. Each edge uses the `cScale` color of its child node.\n\nTo choose the color of each level, set those variables with the `base` theme and pick contrasting background and label colors. The `neo` look colors the root label with `cScaleLabel0`, so set it too. In the `neo` look, also set `useGradient: false`, because otherwise `base` paints every node with `mainBkg`:\n\n```mermaid-example\n---\nconfig:\n  theme: base\n  mindmap:\n    colorBy: depth\n  themeVariables:\n    git0: '#374151'\n    gitBranchLabel0: '#ffffff'\n    cScaleLabel0: '#ffffff'\n    cScale1: '#bfdbfe'\n    cScaleLabel1: '#172554'\n    cScale2: '#bbf7d0'\n    cScaleLabel2: '#14532d'\n    cScale3: '#fde68a'\n    cScaleLabel3: '#451a03'\n---\nmindmap\n  root((mindmap))\n    origins{{Origins}}\n      history[Long history]\n        Popularisation\n        British popular psychology author Tony Buzan\n    research{{Research}}\n      uses[Uses]\n        Creative techniques\n```\n\nDepth mode uses the same theme styles as branch coloring and only changes which nodes share a color. In the `neo` look, some themes use one background for every node in both modes:\n\n- Themes with `useGradient` enabled paint every node, including the root, with `mainBkg`. It is on by default in `base`, `dark`, `forest`, `neo`, `neo-dark` and `neutral`. Set `themeVariables.useGradient: false` to show depth colors on node backgrounds.\n- `neutral`, `redux` and `redux-dark` paint every node below the root with `mainBkg` even without the gradient, and use one label color for all of them.\n\nIn the `neo` look, the root label uses `cScaleLabel0` (`cScaleLabel1` in `neutral`, `nodeBorder` in `redux` themes). Edges keep their depth colors, except in `neo-dark` and the `redux` themes.\n\nSet `mindmap.colorBy` to `branch` (the default) to restore branch coloring.\n\n# Icons and classes\n\n## Icons\n\nAs with flowcharts you can add icons to your nodes but with an updated syntax. The styling for the font based icons are added during the integration so that they are available for the web page. _This is not something a diagram author can do but has to be done with the site administrator or the integrator_. Once the icon fonts are in place you add them to the mind map nodes using the `::icon()` syntax. You place the classes for the icon within the parenthesis like in the following example where icons for material design and [Font Awesome 5](https://fontawesome.com/v5/search?o=r&m=free) are displayed. The intention is that this approach should be used for all diagrams supporting icons. **Experimental feature:** This wider scope is also the reason Mindmaps are experimental as this syntax and approach could change.\n\n```mermaid-example\nmindmap\n    Root\n        A\n        ::icon(fa fa-book)\n        B(B)\n        ::icon(mdi mdi-skull-outline)\n```\n\n## Classes\n\nAgain the syntax for adding classes is similar to flowcharts. You can add classes using a triple colon following a number of css classes separated by space. In the following example one of the nodes has two custom classes attached urgent turning the background red and the text white and large increasing the font size:\n\n```mermaid-example\nmindmap\n    Root\n        A[A]\n        :::urgent large\n        B(B)\n        C\n```\n\n_These classes need to be supplied by the site administrator._\n\n## Unclear indentation\n\nThe actual indentation does not really matter only compared with the previous rows. If we take the previous example and disrupt it a little we can see how the calculations are performed. Let us start with placing C with a smaller indentation than `B` but larger then `A`.\n\n```\nmindmap\n    Root\n        A\n            B\n          C\n```\n\nThis outline is unclear as `B` clearly is a child of `A` but when we move on to `C` the clarity is lost. `C` is neither a child of `B` with a higher indentation nor does it have the same indentation as `B`. The only thing that is clear is that the first node with smaller indentation, indicating a parent, is A. Then Mermaid relies on this known truth and compensates for the unclear indentation and selects `A` as a parent of `C` leading till the same diagram with `B` and `C` as siblings.\n\n```mermaid\nmindmap\nRoot\n    A\n        B\n      C\n```\n\n## Markdown Strings\n\nThe \"Markdown Strings\" feature enhances mind maps by offering a more versatile string type, which supports text formatting options such as bold and italics, and automatically wraps text within labels.\n\n```mermaid-example\nmindmap\n    id1[\"`**Root** with\na second line\nUnicode works too: 🤓`\"]\n      id2[\"`The dog in **the** hog... a *very long text* that wraps to a new line`\"]\n      id3[Regular labels still works]\n```\n\nFormatting:\n\n- For bold text, use double asterisks \\*\\* before and after the text.\n- For italics, use single asterisks \\* before and after the text.\n- With traditional strings, you needed to add 
 tags for text to wrap in nodes. However, markdown strings automatically wrap text when it becomes too long and allows you to start a new line by simply using a newline character instead of a 
 tag.\n\n## Integrating with your library/website.\n\nMindmap uses the experimental lazy loading & async rendering features which could change in the future. From version 9.4.0 this diagram is included in mermaid but use lazy loading in order to keep the size of mermaid down. This is important in order to be able to add additional diagrams going forward.\n\nYou can still use the pre 9.4.0 method to add mermaid with mindmaps to a web page:\n\n```html\n\n```\n\nFrom version 9.4.0 you can simplify this code to:\n\n```html\n\n```\n\nYou can also refer the [implementation in the live editor](https://github.com/mermaid-js/mermaid-live-editor/blob/develop/src/lib/util/mermaid.ts) to see how the async loading is done.\n\n\n\n## Layouts\n\nMermaid also supports a Tidy Tree layout for mindmaps.\n\n```\n---\nconfig:\n  layout: tidy-tree\n---\nmindmap\nroot((mindmap is a long thing))\n  A\n  B\n  C\n  D\n```\n\nInstructions to add and register tidy-tree layout are present in [Tidy Tree Configuration](/config/tidy-tree)\n","isInternal":false,"tokens":2540,"sizeBytes":10425},{"name":"packet.md","path":"packages/mermaid/src/docs/syntax/packet.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/packet.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"# Packet Diagram (v11.0.0+)\n\n## Introduction\n\nA packet diagram is a visual representation used to illustrate the structure and contents of a network packet. Network packets are the fundamental units of data transferred over a network.\n\n## Usage\n\nThis diagram type is particularly useful for developers, network engineers, educators, and students who require a clear and concise way to represent the structure of network packets.\n\n## Syntax\n\n```\npacket\nstart: \"Block name\" %% Single-bit block\nstart-end: \"Block name\" %% Multi-bit blocks\n... More Fields ...\n```\n\n### Bits Syntax (v11.7.0+)\n\nUsing start and end bit counts can be difficult, especially when modifying a design. For this we add a bit count field, which starts from the end of the previous field automagically. Use `+` to set the number of bits, thus:\n\n```\npacket\n+1: \"Block name\" %% Single-bit block\n+8: \"Block name\" %% 8-bit block\n9-15: \"Manually set start and end, it's fine to mix and match\"\n... More Fields ...\n```\n\n## Examples\n\n```mermaid-example\n---\ntitle: \"TCP Packet\"\n---\npacket\n0-15: \"Source Port\"\n16-31: \"Destination Port\"\n32-63: \"Sequence Number\"\n64-95: \"Acknowledgment Number\"\n96-99: \"Data Offset\"\n100-105: \"Reserved\"\n106: \"URG\"\n107: \"ACK\"\n108: \"PSH\"\n109: \"RST\"\n110: \"SYN\"\n111: \"FIN\"\n112-127: \"Window\"\n128-143: \"Checksum\"\n144-159: \"Urgent Pointer\"\n160-191: \"(Options and Padding)\"\n192-255: \"Data (variable length)\"\n```\n\n```mermaid-example\npacket\ntitle UDP Packet\n+16: \"Source Port\"\n+16: \"Destination Port\"\n32-47: \"Length\"\n48-63: \"Checksum\"\n64-95: \"Data (variable length)\"\n```\n\n## Details of Syntax\n\n- **Ranges**: Each line after the title represents a different field in the packet. The range (e.g., `0-15`) indicates the bit positions in the packet.\n- **Field Description**: A brief description of what the field represents, enclosed in quotes.\n\n### Bit Numbering Order (v12.0.0+)\n\nRows are numbered from their lowest bit on the left up to their highest bit on the right, which suits network packets. Hardware registers are conventionally drawn the other way round, with the most significant bit on the left and bit 0 on the right. Set `bitOrder: descending` to mirror every row:\n\n```mermaid-example\n---\nconfig:\n  packet:\n    showBits: true\n    bitOrder: descending\n    bitsPerRow: 16\n---\npacket\n0-7: \"DATA\"\n8-11: \"TYPE\"\n12: \"EN\"\n13-15: \"RESERVED\"\n```\n\nOnly the drawing is mirrored. Fields are still declared lowest bit first (`0-7`, never `7-0`) and keep their width, so the same diagram can be switched between the two conventions by changing `bitOrder` alone.\n\nEach row is mirrored on its own, so a packet wider than `bitsPerRow` reads as a stack of words that each run from their highest bit down to their lowest: with the default `bitsPerRow: 32`, the second row runs from bit 63 down to bit 32, not down to bit 0. A row that is not completely filled is padded on the left, keeping its lowest bit flush against the right edge.\n\n## Configuration\n\nPlease refer to the [configuration](/config/schema-docs/config-defs-packet-diagram-config.html) guide for details.\n\n\n","isInternal":false,"tokens":1090,"sizeBytes":4237},{"name":"pie.md","path":"packages/mermaid/src/docs/syntax/pie.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/pie.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":789,"sizeBytes":3249},{"name":"quadrantChart.md","path":"packages/mermaid/src/docs/syntax/quadrantChart.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/quadrantChart.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2318,"sizeBytes":10545},{"name":"radar.md","path":"packages/mermaid/src/docs/syntax/radar.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/radar.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1774,"sizeBytes":6620},{"name":"railroad.md","path":"packages/mermaid/src/docs/syntax/railroad.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/railroad.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2956,"sizeBytes":11494},{"name":"requirementDiagram.md","path":"packages/mermaid/src/docs/syntax/requirementDiagram.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/requirementDiagram.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2183,"sizeBytes":9400},{"name":"sankey.md","path":"packages/mermaid/src/docs/syntax/sankey.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/sankey.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1870,"sizeBytes":6580},{"name":"sequenceDiagram.md","path":"packages/mermaid/src/docs/syntax/sequenceDiagram.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/sequenceDiagram.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":6328,"sizeBytes":27262},{"name":"stateDiagram.md","path":"packages/mermaid/src/docs/syntax/stateDiagram.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/stateDiagram.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3299,"sizeBytes":13233},{"name":"swimlanes.md","path":"packages/mermaid/src/docs/syntax/swimlanes.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/swimlanes.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"title":"Swimlanes Diagram Syntax","outline":"deep"},"isInternal":false,"tokens":2265,"sizeBytes":9121},{"name":"timeline.md","path":"packages/mermaid/src/docs/syntax/timeline.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/timeline.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2826,"sizeBytes":11710},{"name":"treemap.md","path":"packages/mermaid/src/docs/syntax/treemap.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/treemap.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"","frontmatter":{"title":"Treemap Diagram Syntax","outline":"deep"},"isInternal":false,"tokens":1734,"sizeBytes":7379},{"name":"treeView.md","path":"packages/mermaid/src/docs/syntax/treeView.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/treeView.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1921,"sizeBytes":8784},{"name":"usecase.md","path":"packages/mermaid/src/docs/syntax/usecase.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/usecase.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":5953,"sizeBytes":26049},{"name":"userJourney.md","path":"packages/mermaid/src/docs/syntax/userJourney.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/userJourney.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":197,"sizeBytes":804},{"name":"venn.md","path":"packages/mermaid/src/docs/syntax/venn.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/venn.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":980,"sizeBytes":3507},{"name":"wardley.md","path":"packages/mermaid/src/docs/syntax/wardley.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/wardley.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":3189,"sizeBytes":11109},{"name":"xyChart.md","path":"packages/mermaid/src/docs/syntax/xyChart.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/xyChart.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":2819,"sizeBytes":11391},{"name":"zenuml.md","path":"packages/mermaid/src/docs/syntax/zenuml.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/syntax/zenuml.md","title":"Syntax Skill","category":"anthropic-skill","format":"markdown","content":"","isInternal":false,"tokens":1560,"sizeBytes":6149},{"name":"tsconfig.json","path":"packages/mermaid/src/docs/tsconfig.json","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid/src/docs/tsconfig.json","title":"Docs Skill","category":"anthropic-skill","format":"json","content":"","frontmatter":{"$schema":"https://json.schemastore.org/tsconfig","extends":["../../../../tsconfig.json"],"compilerOptions":{"noEmit":true},"include":["./**/*.ts","./.vitepress/**/*.ts"]},"isInternal":false,"tokens":62,"sizeBytes":200},{"name":"README.md","path":"packages/examples/README.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/examples/README.md","title":"examples Documentation","category":"plugin-manifest","format":"markdown","content":"","isInternal":false,"tokens":351,"sizeBytes":1525},{"name":"README.md","path":"packages/mermaid-layout-elk/README.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid-layout-elk/README.md","title":"mermaid-layout-elk Documentation","category":"plugin-manifest","format":"markdown","content":"","isInternal":false,"tokens":606,"sizeBytes":2339},{"name":"README.md","path":"packages/mermaid-layout-tidy-tree/README.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid-layout-tidy-tree/README.md","title":"mermaid-layout-tidy-tree Documentation","category":"plugin-manifest","format":"markdown","content":"","isInternal":false,"tokens":437,"sizeBytes":1691},{"name":"README.md","path":"packages/mermaid-local-editor/README.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid-local-editor/README.md","title":"mermaid-local-editor Documentation","category":"plugin-manifest","format":"markdown","content":"","isInternal":false,"tokens":297,"sizeBytes":1156},{"name":"README.md","path":"packages/mermaid-zenuml/README.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/mermaid-zenuml/README.md","title":"mermaid-zenuml Documentation","category":"plugin-manifest","format":"markdown","content":"","isInternal":false,"tokens":1905,"sizeBytes":7489},{"name":"README.md","path":"packages/parser/README.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/parser/README.md","title":"parser Documentation","category":"plugin-manifest","format":"markdown","content":"","isInternal":false,"tokens":377,"sizeBytes":1563},{"name":"README.md","path":"packages/tiny/README.md","rawUrl":"https://raw.githubusercontent.com/mermaid-js/mermaid/HEAD/packages/tiny/README.md","title":"tiny Documentation","category":"plugin-manifest","format":"markdown","content":"","isInternal":false,"tokens":312,"sizeBytes":1291}],"systemPromptSnippet":"\n\n# Custom SVG Shapes Library\n\nThis library provides a collection of custom SVG shapes, utilities, and helpers for generating diagram components. The shapes are designed to be used within an SVG container and include a variety of common and complex shapes.\n\n## Overview\n\n## Shape Helpers and Utilities\n\nBefore starting with shape creation, it's essential to familiarize yourself with the utilities provided in the `utils.ts` file from `packages/mermaid/src/rendering-util/rendering-elements/shapes/util.js`. These utilities are designed to assist with various aspects of SVG shape manipulation and ensure consistent and accurate rendering.\n\n## Available Utilities\n\n### 1. `labelHelper`\n\n- **Purpose**: This function creates and inserts labels inside SVG shapes.\n- **Features**:\n  - Handles both HTML labels and plain text.\n  - Calculates the bounding box dimensions of the label.\n  - Ensures proper positioning of labels within shapes.\n\n### 2. `updateNodeBounds`\n\n- **Purpose**: Updates the bounding box dimensions (width and height) of a node.\n- **Usage**:\n  - Adjusts the size of the node to fit the content or shape.\n  - Useful for ensuring that shapes resize appropriately based on their content.\n\n### 3. `insertPolygonShape`\n\n- **Purpose**: Inserts a polygon shape into an SVG container.\n- **Features**:\n  - Handles the creation and insertion of complex polygonal shapes.\n  - Configures the shape's appearance and positioning within the SVG container.\n\n### 4. `getNodeClasses`\n\n- **Purpose**: Returns the appropriate CSS classes for a node based on its configuration.\n- **Usage**:\n  - Dynamically applies CSS classes to nodes for styling purposes.\n  - Ensures that nodes adhere to the desired design and theme.\n\n### 5. `createPathFromPoints`\n\n- **Purpose**: Generates an SVG path string from an array of points.\n- **Usage**:\n  - Converts a list of points into a smooth path.\n  - Useful for creating custom shapes or paths within the SVG.\n\n### 6. `generateFullSineWavePoints`\n\n- **Purpose**: Generates points for a sine wave, useful for creating wavy-edged shapes.\n- **Usage**:\n  - Facilitates the creation of shapes with wavy or sine-wave edges.\n  - Can be used to add decorative or dynamic edges to shapes.\n\n## Getting Started\n\nTo utilize these utilities, simply import them from the `utils.ts` file into your shape creation script. These helpers will streamline the process of building and customizing SVG shapes, ensuring consistent results across your projects.\n\n```typescript\nimport {\n  labelHelper,\n  updateNodeBounds,\n  insertPolygonShape,\n  getNodeClasses,\n  createPathFromPoints,\n  generateFullSineWavePoints,\n} from './utils.ts';\n```\n\n## Example Usage\n\nHere’s a basic example of how you might use some of these utilities:\n\n```typescript\nimport { labelHelper, insertPolygonShape } from './utils.ts';\n\nconst svgContainer = document.getElementById('svgContainer');\n\n// Insert a polygon shape\ninsertPolygonShape(svgContainer /* shape-specific parameters */);\n\n// Create and insert a label inside the shape\nlabelHelper(svgContainer /* label-specific parameters */);\n```\n\n## Adding New Shapes\n\n### 1. Create the Shape Function\n\nTo add a new shape:\n\n- **Create the shape function**: Create a new file of name of the shape and export a function in the `shapes` directory that generates your shape. The file and function should follow the pattern used in existing shapes and return an SVG element.\n\n- **Example**:\n\n  ```typescript\n  import { Node, RenderOptions } from '../../types.ts';\n\n  export const myNewShape = async (\n    parent: SVGAElement,\n    node: Node,\n    renderOptions: RenderOptions\n  ) => {\n    // Create your shape here\n    const shape = parent.insert('g').attr('class', 'my-new-shape');\n    // Add other elements or styles as needed\n    return shape;\n  };\n  ```\n\n### 2. Register the Shape\n\n- **Register the shape**: Add your shape to the `shapes` object in the [main shapes module](../rendering-util/rendering-elements/shapes.ts). This allows your shape to be recognized and used within the system.\n\n- **Example**:\n\n  ```typescript\n  import { myNewShape } from './shapes/myNewShape';\n\n  const shapes = {\n    ...,\n    {\n      semanticName: 'My Shape',\n      name: 'Shape Name',\n      shortName: '',\n      description: '',\n      aliases: ['', '', '', ''],\n      handler: myNewShape,\n    },\n  };\n  ```\n\n# Shape Intersection Algorithms\n\nThis contains algorithms and utilities for calculating intersection points for various shapes in SVG. Arrow intersection points are crucial for accurately determining where arrows connect with shapes. Ensuring precise intersection points enhances the clarity and accuracy of flowcharts and diagrams.\n\n## Shape Intersection Functions\n\n### 1. `Ellipse`\n\nCalculates the intersection points for an ellipse.\n\n**Usage**:\n\n```javascript\nimport intersectEllipse from './intersect-ellipse.js';\n\nconst intersection = intersectEllipse(node, rx, ry, point);\n```\n\n- **Parameters**:\n  - `node`: The SVG node element.\n  - `rx`: The x-radius of the ellipse.\n  - `ry`: The y-radius of the ellipse.\n  - `point`: The point from which the intersection is calculated.\n\n### 2. `intersectRect`\n\nCalculates the intersection points for a rectangle.\n\n**Usage**:\n\n```javascript\nimport intersectRect from './intersect-rect.js';\n\nconst intersection = intersectRect(node, point);\n```\n\n- **Parameters**:\n  - `node`: The SVG node element.\n  - `point`: The point from which the intersection is calculated.\n\n### 3. `intersectPolygon`\n\nCalculates the intersection points for a polygon.\n\n**Usage**:\n\n```javascript\nimport intersectPolygon from './intersect-polygon.js';\n\nconst intersection = intersectPolygon(node, polyPoints, point);\n```\n\n- **Parameters**:\n  - `node`: The SVG node element.\n  - `polyPoints`: Array of points defining the polygon.\n  - `point`: The point from which the intersection is calculated.\n\n## Cypress Tests\n\nTo ensure the robustness of the flowchart shapes, there are implementation of comprehensive Cypress test cases in `newShapes.spec.ts` file. These tests cover various aspects such as:\n\n- **Shapes**: Testing new shapes like `bowTieRect`, `waveRectangle`, `trapezoidalPentagon`, etc.\n- **Looks**: Verifying shapes under different visual styles (`classic` and `handDrawn`).\n- **Directions**: Ensuring correct rendering in all flow directions of arrows :\n  - `TB` `(Top -> Bottom)`\n  - `BT` `(Bottom -> Top)`\n  - `LR` `(Left -> Right)`\n  - `RL` `(Right -> Left)`\n- **Labels**: Testing shapes with different labels, including:\n  - No labels\n  - Short labels\n  - Very long labels\n  - Markdown with `htmlLabels:true` and `htmlLabels:false`\n- **Styles**: Applying custom styles to shapes and verifying correct rendering.\n- **Class Definitions**: Using `classDef` to apply custom classes and testing their impact.\n\n### Running the Tests\n\nTo run the Cypress tests, follow these steps:\n\n1. Ensure you have all dependencies installed by running:\n   ```bash\n   pnpm install\n   ```\n2. Start the Cypress test runner:\n\n   ```bash\n   cypress open --env updateSnapshots=true\n\n   ```\n\n3. Select the test suite from the Cypress interface to run all the flowchart shape tests.\n\n\n# Mermaid Contributing Guide\n\nYou decided to take part in the development? Welcome!\n\nWe are trying to make our guidelines for you as explicit and detailed as possible.\n\n## Initial Setup\n\nInitial setup consists of 3 main steps:\n\n```mermaid-nocode\nflowchart LR\n  source --> requirements --> setup\n\n  source[Get the Source Code]\n  requirements[Install the Requirements]\n  setup[Install Packages]\n```\n\n### Get the Source Code\n\nIn GitHub, you first [**fork a mermaid repository**](https://github.com/mermaid-js/mermaid/fork) when you are going to make changes and submit pull requests.\n\nThen you **clone** a copy to your local development machine (e.g. where you code) to make a copy with all the files to work with.\n\n```tip\n[Here is a GitHub document that gives an overview of the process](https://docs.github.com/en/get-started/quickstart/fork-a-repo).\n```\n\n```bash\ngit clone git@github.com/your-fork/mermaid\n```\n\nOnce you have cloned the repository onto your development machine, change into the `mermaid` project folder (the top level directory of the mermaid project repository)\n\n```bash\ncd mermaid\n```\n\n### Install Requirements\n\nWe support **development within Docker** environment along with **host setup**. You may choose it up to your preferences.\n\n**Host**\n\nThese are the tools we use for working with the code and documentation:\n\n- [Node.js](https://nodejs.org/en/).\n- [pnpm](https://pnpm.io/) package manager.\n\nThe following commands must be sufficient enough to start with:\n\n```bash\ncurl -fsSL https://get.pnpm.io/install.sh | sh -\npnpm env use --global 20\n```\n\nYou may also need to reload `.shrc` or `.bashrc` afterwards.\n\n**Docker**\n\n[Install Docker](https://docs.docker.com/engine/install/). And that is pretty much all you need.\n\nOptionally, to run GUI (Cypress) within Docker you will also need an X11 server installed.\nYou might already have it installed, so check this by running:\n\n```bash\necho $DISPLAY\n```\n\nIf the `$DISPLAY` variable is not empty, then an X11 server is running. Otherwise you may need to install one.\n\n### Install Packages\n\n**Host**\n\nInstall packages:\n\n```bash\npnpm install\n```\n\n**Docker**\n\nFor development using Docker there is a self-documented `run` bash script, which provides convenient aliases for `docker compose` commands.\n\nMake sure that `./run` script is executable:\n\n```bash\nchmod +x run\n```\n\n```tip\nTo get detailed help simply type `./run` or `./run help`.\n\nIt also has short _Development quick start guide_ embedded.\n```\n\nThen install packages:\n\n```bash\n./run pnpm install\n```\n\n### Verify Everything Works\n\nThis step is optional, but it helps to make sure that everything in development branch was OK before you started making any changes.\n\nYou can run the `test` script to verify that pnpm is working _and_ that the repository has been cloned correctly:\n\n**Host**\n\n```bash\npnpm test\n```\n\n**Docker**\n\n```bash\n./run pnpm test\n```\n\nThe `test` script and others are in the top-level `package.json` file.\n\nAll tests should run successfully without any errors or failures.\n\n```note\nYou might see _lint_ or _formatting_ warnings. Those are ok during this step.\n```\n\n## Workflow\n\nContributing process is very simple and straightforward:\n\n```mermaid-nocode\n  flowchart LR\n\n  branch --> changes --> submit\n  branch[Checkout a New Branch]\n  changes[Make Changes]\n  submit[Submit a PR]\n```\n\nMermaid uses a [Git Flow](https://guides.github.com/introduction/flow/)–inspired approach to branching.\n\nDevelopment is done in the `develop` branch.\n\n```mermaid-nocode\n---\nconfig:\n  gitGraph:\n    mainBranchName: develop\n---\ngitGraph LR:\n  commit\n  commit\n  branch \"docs/2910_update-guidelines\" order: 1\n  commit\n  commit\n  commit\n  checkout develop\n  merge \"docs/2910_update-guidelines\"\n  commit\n```\n\nTo prepare a new version for release the maintainers create a `release/vX.X.X` branch from `develop` for testing. Once the release happens we add a tag to the `release` branch and merge it with `master`. The live product and on-line documentation are what is in the `master` branch.\n\n## Checkout a New Branch\n\n```tip\nAll new work should be based on the `develop` branch.\n```\n\nMake sure you have the most up-to-date version of the `develop` branch.\n\nCheck out the `develop` branch, then `fetch` or `pull` to update it:\n\n```bash\ngit checkout develop\ngit fetch # or `git pull`\n```\n\nCreate a new branch for your work:\n\n```bash\ngit checkout -b docs/2910_update-contributing-guidelines\n```\n\nWe use the following naming convention for branches:\n\n```txt\n[feature | bug | chore | docs]/[issue number]_[short-description]\n```\n\nYou can always check current [configuration of labelling and branch prefixes](https://github.com/mermaid-js/mermaid/blob/develop/.github/pr-labeler.yml)\n\n- The first part is the **type** of change: a `feature`, `bug`, `chore`, `docs`\n- followed by a **slash** (`/`),which helps to group like types together in many git tools\n- followed by the **issue number**, e.g. `2910`\n- followed by an **underscore** (`_`)\n- followed by a **short description** with dashes (`-`) or underscores (`_`) instead of spaces\n\n```mermaid-nocode\nflowchart LR\n  feature --> slash\n  bug --> slash\n  chore --> slash\n  docs --> slash\n  slash --> 2945 --> underscore\n  slash --> 1123 --> underscore\n  underscore --> short_description_1\n  underscore --> short_description_2\n\n  underscore[\"_\"]\n  slash[\"/\"]\n\n  short_description_1[\"state-diagram-new-arrow-florbs\"]\n  short_description_2[\"fix_random_ugly_red_text\"]\n```\n\nIf your work is specific to a single diagram type, it is a good idea to put the diagram type at the start of the description. This will help us keep release notes organized by a diagram type.\n\n```note\nA new feature described in issue 2945 that adds a new arrow type called 'florbs' to state diagrams\n\n`feature/2945_state-diagram-new-arrow-florbs`\n```\n\n```tip\nA bug described in issue 1123 that causes random ugly red text in multiple diagram types\n\n`bug/1123_fix_random_ugly_red_text`\n```\n\n## Contributing Code\n\nCode is the heart of every software project. We strive to make it better. Who if not us?\n\n### Where is the Code Located?\n\nThe core of Mermaid is located under `packages/mermaid/src`.\n\n### Building Mermaid Locally\n\n**Host**\n\n```bash\npnpm run build\n```\n\n**Docker**\n\n```bash\n./run build\n```\n\nThis will build the Mermaid library and the documentation site.\n\n### Running Mermaid Locally\n\n**Host**\n\n```bash\npnpm run dev\n```\n\n**Docker**\n\n```bash\n./run dev\n```\n\nAfter starting the dev server open  in your browser.\n\nNow you are ready to make your changes!\n\nNote: By default, the Mermaid service will run on port 9000. To use a different port, change the environment variable `MERMAID_PORT` in the file `.env`. You should only need to do this if you are using port 9000 to run other projects.\n\n### Make Changes\n\nHave a look at . There is a list of demos that can be used to see and test your changes.\n\nIf you need a specific diagram, you can duplicate the `example.html` file in `/demos/dev` and add your own mermaid code to your copy.\n\nThat will be served at .\nAfter making code changes, the dev server will rebuild the mermaid library and automatically reload the page.\n\nEdit files in `packages/mermaid/src` as required.\n\n### Write Tests\n\nTests ensure that each function, module, or part of code does what it says it will do. This is critically important when other changes are made to ensure that existing code is not broken (no regression).\n\nJust as important, the tests act as _specifications:_ they specify what the code does (or should do).\nWhenever someone is new to a section of code, they should be able to read the tests to get a thorough understanding of what it does and why.\n\nIf you are fixing a bug, you should add tests to ensure that your code has actually fixed the bug, to specify/describe what the code is doing, and to ensure the bug doesn't happen again.\n(If there had been a test for the situation, the bug never would have happened in the first place.)\nYou may need to change existing tests if they were inaccurate.\n\nIf you are adding a feature, you will definitely need to add tests. Depending on the size of your feature, you may need to add integration tests.\n\n#### Unit Tests\n\nUnit tests are tests that test a single function or module. They are the easiest to write and the fastest to run.\n\nUnit tests are mandatory for all code except the layout tests. (The layouts are tested with integration tests.)\n\nWe use [Vitest](https://vitest.dev) to run unit tests.\n\n**Host**\n\nYou can use the following command to run the unit tests:\n\n```sh\npnpm test\n```\n\nWhen writing new tests, it's easier to have the tests automatically run as you make changes. You can do this by running the following command:\n\n```sh\npnpm test:watch\n```\n\n**Docker**\n\nWhen using Docker prepend your command with `./run`:\n\n```sh\n./run pnpm test\n```\n\n##### Testing the DOM\n\nOne can use `jsdomIt` to test any part of Mermaid that interacts with the DOM, as long as it is not related to the layout.\n\nThe function `jsdomIt` ([developed in utils.ts](../../tests/util.ts)) overrides `it` from `vitest`, and creates a pseudo-browser environment that works almost like the real deal for the duration of the test. It uses JSDOM to create a DOM, and adds objects `window` and `document` to `global` to mock the browser environment.\n\n> [!NOTE]\n> The layout cannot work in `jsdomIt` tests because JSDOM has no rendering engine, hence the pseudo-browser environment.\n\nExample :\n\n```typescript\nimport { ensureNodeFromSelector, jsdomIt } from './tests/util.js';\n\njsdomIt('should add element \"thing\" in the SVG', ({ svg }) => {\n  // Code in this block runs in a pseudo-browser environment\n  addThing(svg); // The svg item is the D3 selection of the SVG node\n  const svgNode = ensureNodeFromSelector('svg'); // Retrieve the DOM node using the DOM API\n  expect(svgNode.querySelector('thing')).not.toBeNull(); // Test the structure of the SVG\n});\n```\n\nThey can be used to test any method that interacts with the DOM, including for testing renderers. For renderers, additional integration testing is necessary to test the layout though.\n\n#### Integration / End-to-End (E2E) Tests\n\nThese test the rendering and visual appearance of the diagrams.\n\nThis ensures that the rendering of that feature in the E2E will be reviewed in the release process going forward. Less chance that it breaks!\n\nTo start working with the E2E tests:\n\n**Host**\n\n- Run `pnpm dev` to start the dev server\n- Start **Cypress** by running `pnpm cypress:open`\n\n**Docker**\n\n- Enable local connections for x11 server `xhost +local:`\n- Run `./run pnpm dev` to start the dev server\n- Start **Cypress** by running `./run pnpm cypress:open --project .`\n\nThe rendering tests are very straightforward to create. There is a function `imgSnapshotTest`, which takes a diagram in text form and the mermaid options, and it renders that diagram in Cypress.\n\nWhen running in CI it will take a snapshot of the rendered diagram and compare it with the snapshot from last build and flag it for review if it differs. When the changes in PR only apply to specific diagrams, only the rendering tests for those diagrams will be run in CI. If a change is not related to a specific diagram, the full test-suite will be run.\n\nThis is what a rendering test looks like:\n\n```js\nit('should render forks and joins', () => {\n  imgSnapshotTest(\n    `\n    stateDiagram\n    state fork_state <<fork>>\n      [*] --> fork_state\n      fork_state --> State2\n      fork_state --> State3\n\n      state join_state <<join>>\n      State2 --> join_state\n      State3 --> join_state\n      join_state --> State4\n      State4 --> [*]\n    `,\n    { logLevel: 0 }\n  );\n});\n```\n\n\n\n\n### Update Documentation\n\n```tip\nOur documentation is managed in `packages/mermaid/src/docs`. Details on how to edit is in the [documentation section](#contributing-documentation)\n```\n\nIf the users have no way to know that things have changed, then you haven't really _fixed_ anything for the users; you've just added to making Mermaid feel broken.\nLikewise, if users don't know that there is a new feature that you've implemented, it will forever remain unknown and unused.\n\nThe documentation has to be updated for users to know that things have been changed and added!\nIf you are adding a new feature, add `(v+)` in the title or description. It will be replaced automatically with the current version number when the release happens.\n\neg: `# Feature Name (v+)`\n\nWe know it can sometimes be hard to code _and_ write user documentation.\n\nCreate another issue specifically for the documentation.\nYou will need to help with the PR, but definitely ask for help if you feel stuck.\nWhen it feels hard to write stuff out, explaining it to someone and having that person ask you clarifying questions can often be 80% of the work!\n\nWhen in doubt, write up and submit what you can. It can be clarified and refined later. (With documentation, something is better than nothing!)\n\n## Contributing Documentation\n\nIf it is not in the documentation, it's like it never happened. Wouldn't that be sad? With all the effort that was put into the feature?\n\n### Where is the Documentation Located?\n\n```warning\nDO NOT CHANGE FILES IN `/docs`\n\nThe `docs` folder will be automatically generated when committing to `packages/mermaid/src/docs` and **should not** be edited manually.\n```\n\nDocumentation is located in the [`packages/mermaid/src/docs`](https://github.com/mermaid-js/mermaid/tree/develop/packages/mermaid/src/docs) folder. Just pick the right section and start typing.\n\nThe contents of [mermaid.js.org](https://mermaid.js.org/) are based on the docs from the `master` branch. Updates committed to the `master` branch are reflected in the [Mermaid Docs](https://mermaid.js.org/) once published.\n\n```mermaid\nflowchart LR\n  classDef default fill:#fff,color:black,stroke:black\n\n  source[\"Edit /packages/mermaid/src/docs\"] -- automatic processing--> published[\"View /docs which will be published on Official Website\"]\n```\n\n### Running the Documentation Website Locally\n\n**[The mermaid documentation site](https://mermaid.js.org/) is powered by [Vitepress](https://vitepress.vuejs.org/).**\n\nStart development server for the documentation site\n\n**Host**\n\n```bash\npnpm --filter mermaid run docs:dev\n```\n\nor\n\n```bash\ncd packages/mermaid\npnpm docs:dev\n```\n\n**Docker**\n\n```bash\n./run docs:dev\n```\n\nOpen [http://localhost:3333/](http://localhost:3333/) in your browser.\n\n### Formatting\n\nThe documentation is written in Markdown. To get acquainted with its syntax [see the GitHub Markdown help page](https://help.github.com/en/github/writing-on-github/basic-writing-and-formatting-syntax).\n\nYou can use `note`, `tip`, `warning` and `danger` in triple backticks to add a note, tip, warning or danger box.\n\n```danger\nDo not use vitepress specific markdown syntax `::: warning` as it will not be processed correctly.\n```\n\nHere are a few examples:\n\n````markdown\n```note\nThis is a note\n```\n\n```tip\nThis is a tip\n```\n\n```warning\nThis is a warning\n```\n\n```danger\nThis is a danger alert\n```\n````\n\n```note\nThis is a note\n```\n\n```tip\nThis is a tip\n```\n\n```warning\nThis is a warning\n```\n\n```danger\nThis is a danger alert\n```\n\n### Navigation\n\nIf you want to propose changes to how the documentation is _organized_, such as adding a new section or re-arranging or renaming a section, you must update the **sidebar navigation**, which is defined in [the vitepress config](../.vitepress/config.ts). The same goes for **topbar**.\n\n### Build Docs\n\nThe content of `/docs` folder is built with GitHub Actions.\n\n```warning\nSo as to allow automatic compilation of documentation pages you have to enable GitHub Actions on your fork first\n```\n\n## Submit your pull request\n\n````note\nDo not forget to push your changes\n\n```bash\ngit push -u origin docs/2910_update-guidelines\n```\n````\n\nWe make all changes via Pull Requests (PRs). Open a new one.\n\nRight now we are not following any strict rules about naming PRs. Give it a representative title and short description. There is also a [pull request template](https://github.com/mermaid-js/mermaid/blob/develop/.github/pull_request_template.md) which will help you with it.\n\nIn case in its description contains a [magic comment](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) your PR will be automatically attached to the issue:\n\n```markdown\nResolves #\n```\n\n## Congratulations\n\nYou have successfully submitted your improvements! What is next?\n\n- PRs will be reviewed by active maintainers, who will provide feedback and request changes as needed.\n- The maintainers will request a review from _knsv_, if necessary.\n- Once the PR is approved, the maintainers will merge the PR into the `develop` branch.\n- When a release is ready, the `release/x.x.x` branch will be created, extensively tested and knsv will be in charge of the release process.\n\nThanks for you help!\n\n\n\n\n# E2E Test Suite: Tiers, Folders, and CI\n\nThis is a contributor-facing manual for the `e2e/` test suite's tier structure — why it exists, how it's organized, which flags/labels control it, and how to work with it locally.\n\n## Why this exists\n\nBefore this restructuring, every PR ran the entire e2e suite — every diagram, every theme variant, every look/handdrawn combination — on every push. That's thorough, but it's expensive in two ways that scale badly as the suite grows:\n\n- **CI time.** A full run takes significantly longer than most PRs actually need. Most changes touch one diagram type; waiting on a full 8-shard run to validate a one-line fix is slow feedback for no real benefit.\n- **Argos quota.** Every full run captures and uploads a screenshot for every diagram fixture, whether or not that fixture has anything to do with the change under review. Visual-regression services bill (or rate-limit) by build/screenshot volume, so an oversized \"safety net\" run on every push burns through quota fast.\n\nThe fix is to split fixtures and specs into **tiers** — a small, fast, curated set that runs on every PR by default, and larger, slower sets reserved for less frequent, higher-confidence checks (nightly, and before a release-bound merge).\n\n**Measured impact** (from a real before/after comparison on this fork, on 2026-09-24 — pulled directly from GitHub Actions run history for PR #7; treat this as a dated example, not a live-updating stat):\n\n|                               | Full suite (pre-tiering) | `pr-check`-tier only |\n| ----------------------------- | ------------------------ | -------------------- |\n| Shards                        | 8                        | 2                    |\n| Per-shard time                | ~15–18 min               | ~6–8 min             |\n| Total wall-clock              | ~31 min                  | ~8 min               |\n| Total compute (shard-minutes) | ~128                     | ~14                  |\n\nRoughly a **4x reduction in wall-clock time** and **~90% less total CI compute** for the common case — a PR that only needs the `pr-check` tier to validate its change. That tracks with the underlying fixture split: as of 2026-09-24, `pr-check` covered about 15% of all `.mmd` fixtures (312 of 2,136 — `nightly-check` held 1,375, `visual-check` held 449). These counts will grow over time; the proportions are the durable part.\n\n## Directory layout\n\nTwo parallel trees hold the suite's content:\n\n```mermaid\nflowchart TD\n  subgraph diagrams[\"e2e/diagrams//\"]\n    direction LR\n    d_pr[\"pr-check/
*.mmd fixtures\"]\n    d_nightly[\"nightly-check/
*.mmd fixtures\"]\n    d_visual[\"visual-check/
*.mmd fixtures\"]\n  end\n  subgraph rendering[\"e2e/rendering//\"]\n    direction LR\n    r_pr[\"pr-check/
*.spec.ts\"]\n    r_nightly[\"nightly-check/
*.spec.ts\"]\n    r_visual[\"visual-check/
*.spec.ts\"]\n  end\n  runner[\"e2e/rendering/mmd-snapshots.spec.ts
(global fixture runner)\"]\n  diagrams -->|discovered & rendered by| runner\n```\n\n- **`e2e/diagrams///*.mmd`** — static Mermaid source fixtures. Each one is just a diagram (optionally with YAML frontmatter setting `config`/`title`/a `description`). They aren't run directly; a single global spec, `e2e/rendering/mmd-snapshots.spec.ts`, discovers every `.mmd` file under `e2e/diagrams/`, registers one Playwright test per fixture (grouped into `describe` blocks mirroring the folder path), and renders it. This is where the large majority of diagram-rendering coverage lives — no test-writing required, just add a `.mmd` file in the right tier folder.\n- **`e2e/rendering///*.spec.{js,ts}`** — hand-written Playwright specs, for anything a static fixture can't express: DOM/CSS assertions, `.click()` interactions, directive-vs-`initialize()` precedence checks, multi-diagram array tests, custom `mermaid.initialize()` config, and similar. If your test needs to assert on rendered output beyond \"did it render without erroring,\" it belongs here instead of as a fixture.\n- **`e2e/other//*.spec.{js,ts}`** — cross-cutting specs that aren't about any single diagram type (XSS/security tests, GHSA regression tests, `iife`/embed tests, page-interaction tests, external-diagram loading). Only `pr-check/` is populated today.\n- **`e2e/helpers/`** — shared test infrastructure: `util.ts` (the `imgSnapshotTest`/`renderGraph`/`verifyScreenshot` helpers every spec uses) and `mmd-snapshots.ts` (fixture discovery/metadata for the global runner).\n\nNot every `//` directory has content yet — some are intentionally empty, left in place as containers for tests that haven't been written. An empty tier folder isn't stray or safe to delete; it's scaffolding for the layout above, matching a diagram type or tier that's expected to gain coverage later.\n\n### The three tiers\n\n| Tier            | Intent                                                                                                                                                                     | Runs on                                                                                                                                         |\n| --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |\n| `pr-check`      | Small, curated, fast smoke set — one or two representative fixtures per feature, not an exhaustive sweep.                                                                  | Every PR (see below), plus a `develop` merge, plus every nightly run.                                                                           |\n| `nightly-check` | Bulk/comprehensive coverage — most of the fixture volume lives here.                                                                                                       | Once every 24h, plus a `master`-bound PR/merge (alongside `pr-check`).                                                                          |\n| `visual-check`  | Theme/look (`classic`/`neo`/`handDrawn`)/layout/direction combinatorial sweeps — the same diagram rendered across every variant. Pixel/appearance content, not parse-only. | Not part of any automated CI gate. Reviewed manually via Applitools as a release-process step (`e2e-applitools.yml`, `workflow_dispatch`-only). |\n\nA fixture or spec's tier is purely a function of which subfolder it lives in — there's no separate registry or config file to update.\n\nIf you're new to this structure, here's how to decide where a new test belongs:\n\n- **Adding a new diagram feature or syntax?** Add one small `pr-check` fixture covering the happy path — this is what every PR runs, so it catches an obvious regression immediately. If the feature has several meaningfully different shapes/variants/edge cases worth covering, add those as additional fixtures under `nightly-check` instead of piling them all into `pr-check` — `pr-check` is meant to stay small and fast, not become exhaustive.\n- **Fixing a rendering bug?** Add a `pr-check` fixture that reproduces the bug (the minimal diagram that triggered it), so this exact regression is caught on every future PR. Only drop it into `nightly-check` instead if it's a narrow, rarely-hit edge case where running it on every PR isn't worth the extra time.\n- **Backfilling broad coverage for something that already works** (e.g. every node-shape × edge-type combination, a sweep of config options)? That bulk volume belongs in `nightly-check` — it's comprehensive by design and only needs to run once a day, not on every push.\n- **Testing a purely visual/appearance difference** — how a diagram looks under a different theme, `handDrawn` look, layout direction, or similar, where the underlying structure/parsing is unaffected? That's `visual-check`. It's pixel/appearance content reviewed by a human via Applitools, not something an automated parse-only assertion can usefully judge.\n- **Does your test need to assert on something beyond \"did it render without erroring\"?** — a DOM/CSS assertion, a `.click()` interaction, directive-vs-`initialize()` precedence, a multi-diagram array, custom `mermaid.initialize()` config — that can't be expressed as a static `.mmd` fixture. Write a hand-written spec instead, under `e2e/rendering///*.spec.{js,ts}` if it's about one specific diagram type, or `e2e/other//*.spec.{js,ts}` if it's cross-cutting (security/XSS, embed/`iife`, page interactions, external-diagram loading, and similar). The same tier logic above still applies to these — a fast smoke-test spec goes in `pr-check`, a more exhaustive one in `nightly-check`.\n\nWhen in doubt, default to `pr-check` for anything a feature's author would want caught immediately, and move broader/slower coverage to `nightly-check`.\n\n## How CI decides what to run\n\n```mermaid\nflowchart TD\n  start{\"What triggered this run?\"}\n  start -->|\"PR → develop\"| pr_label{\"'run pr tests'
label set?\"}\n  start -->|\"PR → master\"| release_label{\"'run release test'
label set?\"}\n  start -->|\"Push to develop
(e.g. a PR merge)\"| push_develop[\"pr-check tier only\"]\n  start -->|\"Push to master\"| push_master[\"pr-check + nightly-check tiers\"]\n  start -->|\"Scheduled (daily) or
manual 'simulated nightly'\"| nightly_run[\"pr-check + nightly-check tiers\"]\n\n  pr_label -->|yes, or PR just opened| pr_scoped[\"pr-check tier only\"]\n  pr_label -->|no| blocked1[\"e2e skipped —
required check fails\"]\n\n  release_label -->|yes, or PR just opened| gated[\"pr-check + nightly-check tiers
(visual-check excluded — see Applitools)\"]\n  release_label -->|no| blocked2[\"e2e skipped —
required check fails\"]\n```\n\nBoth labels — `run pr tests` and `run release test` — default to **on**: a small automation job adds them to every freshly-opened PR (targeting `develop` and `master` respectively). Removing the label before a later push causes e2e to be skipped for that push, which is treated as a **failure** of the required status check (not a silent pass) — merging is still possible via a repo admin's branch-protection bypass, but it's not a default-open door.\n\nNote that `run release test` — despite its name — does **not** gate the `visual-check` tier. `visual-check` is theme/look/layout/direction combinatorial sweeps: pixel/appearance content that's better judged by a human during the manual Applitools pass (`e2e-applitools.yml`) than by an automated parse-only check here. The label name is a holdover from before this tier split; renaming it is tracked separately and out of scope for this doc.\n\nThis label-gating logic, and the nightly/scheduled workflow, are **upstream-only** — every branch of this logic is guarded by a check that it's running on `mermaid-js/mermaid`, not a fork. On a fork, e2e.yml falls back to its original full-suite/diff-based-scoping behavior, and the nightly workflow's own job is a no-op (there's no Argos project/credentials there to make screenshot capture worthwhile).\n\n## Flags and environment variables\n\n| Name                                        | Where                                           | Effect                                                                                                                                                                                                                  |\n| ------------------------------------------- | ----------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `MERMAID_E2E_FIXTURE_TIER`                  | env var, read by `mmd-snapshots.spec.ts`        | Comma-separated tier list (e.g. `pr-check`, or `pr-check,nightly-check`) that narrows which `.mmd` fixtures get registered. Unset = every tier.                                                                         |\n| `run pr tests`                              | GitHub PR label                                 | Gates whether a `develop`-bound PR's e2e run happens at all (scoped to `pr-check` tier when present). Defaults on for new PRs.                                                                                          |\n| `run release test`                          | GitHub PR label                                 | Same, for `master`-bound PRs (scoped to `pr-check`+`nightly-check` — `visual-check` excluded, see above). Defaults on for new PRs.                                                                                      |\n| `E2E_SCOPE_BY_DIAGRAM`                      | repo variable                                   | Kill-switch for the (separate, older) diagram-diff-based scoping used outside the tier-gating paths. Set to `'false'` to force the full suite unconditionally.                                                          |\n| `RUN_VISUAL_TEST`                           | computed CI env var                             | Controls whether screenshots get captured for Argos upload. Only ever true on the real upstream repo — never on this fork.                                                                                              |\n| `USE_APPLI`                                 | env var                                         | Switches screenshot verification to Applitools instead of the Argos/local-snapshot path. Common in personal dev shells — remember to override it (`USE_APPLI=`) when you specifically want the Argos code path locally. |\n| `SCREENSHOT_DIR`                            | env var                                         | Overrides where Argos-mode screenshots get written locally. Defaults to `e2e/screenshots`.                                                                                                                              |\n| `GROUP_ARGOS_IMAGES` / `group_argos_images` | computed CI env var / `workflow_dispatch` input | Whether screenshots get composited into per-folder \"sheets\" before Argos upload, versus uploaded individually.                                                                                                          |\n| `MERMAID_DEV_EXPLORER_ROOT`                 | env var, read by `.esbuild/server.ts`           | Which `.mmd` root the local Dev Explorer (`/dev` route) serves. Defaults to `e2e` (the whole tree — fixtures, platform diagrams, everything).                                                                           |\n| `MERMAID_PORT` / `MERMAID_DEV_PORT`         | env var                                         | Overrides the dev server port Playwright/the dev server use.                                                                                                                                                            |\n| `E2E_COVERAGE`                              | env var                                         | Switches the dev server to the coverage-instrumented build, and enables native V8 coverage collection during a Playwright run.                                                                                          |\n\n## Working with tiers locally\n\n**Run only the `pr-check` tier** (mirrors what a PR's CI actually runs):\n\n```bash\nMERMAID_E2E_FIXTURE_TIER=pr-check pnpm exec playwright test e2e/rendering/mmd-snapshots.spec.ts $(node scripts/e2e-tier-scope.mjs pr-check | tr ',' ' ')\n```\n\n**Run a \"simulated nightly\" (`pr-check`+`nightly-check`)** without waiting for the schedule:\n\n```bash\ngh workflow run \"Nightly E2E\" --repo mermaid-js/mermaid\n# or purely locally, no CI involved:\nMERMAID_E2E_FIXTURE_TIER=pr-check,nightly-check pnpm exec playwright test e2e/rendering/mmd-snapshots.spec.ts $(node scripts/e2e-tier-scope.mjs pr-check nightly-check | tr ',' ' ')\n```\n\n**See what a fixture would look like in Argos**, without needing real Argos credentials or touching any baseline: capture screenshots locally with `RUN_VISUAL_TEST=true` (remembering to clear `USE_APPLI` if it's set in your shell), then either browse `e2e/screenshots/` directly, or run `pnpm run screenshots:sheets` to composite them the same way CI does before upload.\n\n**Run a release test against Applitools**: start the local dev server first (`pnpm dev`, in its own terminal) — the suite is large enough that it's worth having it already warm rather than waiting on Playwright's own `webServer` auto-start/cold build on the first request. Neither of these is something you'd run as part of routine local development — they're only used when preparing a release:\n\n```bash\n# Core release check: pr-check + nightly-check tiers, against the \"release-baseline\" Applitools branch.\npnpm playwright:release-test\n\n# Extended release check: the visual-check tier (theme/look/layout combinatorial sweeps),\n# against its own separate \"release-baseline-extended\" Applitools branch.\npnpm playwright:release-test:extended\n```\n\nBoth scripts set `USE_APPLI=true`, so every screenshot is verified against Applitools instead of the Argos/local-snapshot path, and both pin `APPLITOOLS_BRANCH` to a fixed, long-lived branch name rather than letting the SDK derive one from the current git branch — so re-running either script, from whatever branch you're on, keeps comparing against the same accumulated baseline. The two scripts use separate baseline branches deliberately: the core and extended checks differ enough in scope and cadence that mixing both into one branch would make the Applitools review history harder to read.\n\n## Diagrams and screenshots\n\nThe Dev Explorer (`/dev` route) — browse `.mmd` fixtures under the configured `MERMAID_DEV_EXPLORER_ROOT` and preview them rendered:\n\n![Dev Explorer root view, showing the top-level e2e folder listing](img/dev-explorer.png)\n\n> 📸 **Placeholder — add screenshots here:**\n>\n> - The GitHub PR \"Checks\" tab, side by side: a `develop`-bound PR showing the scoped 2-shard `pr-check`-tier run, versus a `master`-bound PR showing the scoped 4-shard `pr-check`+`nightly-check` run (`visual-check` excluded).\n> - The \"Nightly E2E\" entry in the Actions tab, filtered, showing a recent scheduled run's result.\n\nThe flowcharts above (directory layout, CI decision flow) are Mermaid diagrams — edit them the same way you'd edit any diagram in this repo. If you add more diagrams to this doc, prefer Mermaid over static images where the content is structural/flow-based (it stays accurate as the suite evolves, and — fittingly for this repo — is easy for any contributor to update in a plain-text diff).\n\n\n# Getting Started\n\nSo you want to help? That's great!\n\n![Image of happy people jumping with excitement](https://media.giphy.com/media/BlVnrxJgTGsUw/giphy.gif)\n\nHere are a few things to get you started on the right path.\n\n## How can I help?\n\n```mermaid-nocode\nmindmap\n  root)Contributing(\n    Development\n      Solving issues\n      Adding new diagrams\n      Handling pull requests\n      Updating tooling\n    Testing\n      Verification of fixed issues\n      Regression testing in connection with releases\n      Testing pull requests\n    Management\n      Coordinating the work\n      Classification and monitoring of incoming issues\n```\n\n## Join the Development\n\n```tip\n**Check out our** [**detailed contribution guide**](./contributing.md).\n```\n\nWhere to start:\n\n- You could start getting some knowledge of the code base by working on [these \"good first issues\"](https://github.com/mermaid-js/mermaid/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3A%22Good+first+issue%21%22+).\n- You could jump right in and help us fix any of [these bugs](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Type%3A+Bug+%2F+Error%22++label%3A%22Contributor+needed%22+)!\n- You could help write and [improve the documentation](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Area%3A+Documentation%22).\n- You could work on a new feature! [These](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Area%3A+Development%22+label%3A%22Type%3A+Enhancement%22+label%3A%22Status%3A+Approved%22+) are some ideas!\n- You could confirm the bugs in [these issues](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Status%3A+Triage%22++label%3A%22Type%3A+Bug+%2F+Error%22).\n\n[You can join our Discord server if you want closer contact!](https://discord.gg/sKeNQX4Wtj)\n\n## A Question Or a Suggestion?\n\n```tip\n**Have a look at** [**how to open an issue**](./questions-and-suggestions.md).\n```\n\nIf you have faced a vulnerability [report it to us](./security.md).\n\n## Last Words\n\nDon't get daunted if it is hard in the beginning. We have a great community with only encouraging words. So, if you get stuck, ask for help and hints in the Slack forum. If you want to show off something good, show it off there.\n\n[You can join our Discord server if you want closer contact!](https://discord.gg/sKeNQX4Wtj)\n\n![Image of superhero wishing you good luck](https://media.giphy.com/media/l49JHz7kJvl6MCj3G/giphy.gif)\n\n\n# The Layout Maker's Guide 🗺️\n\nA layout algorithm decides where nodes sit and how edges get from one to the next. Shapes, themes, markers, and labels are already handled by the shared rendering code.\n\nWhich means you never touch the DOM. You are handed a graph whose nodes already know how big they are, and you hand back numbers: a center point for every node, a list of points for every edge. Drawing the shapes, painting the strokes, placing the arrowheads, fitting the viewBox — all of that is somebody else's code working from your numbers. You are solving a geometry problem, not a rendering one, which is exactly why a layout can be tested without a browser.\n\nThis guide covers layouts that live inside the Mermaid package, next to `dagre` and the others. The last section explains how to ship the same code as a standalone npm package instead.\n\nTwo layouts in the tree are worth reading alongside it. `dagre` is the default and the oldest. `swimlanes` is the newest, and it is the one that follows the conventions described here, so most of the examples point at it.\n\n## What a layout receives and what it must produce\n\nEvery layout is handed the same structure, `LayoutData`, regardless of which diagram type produced it:\n\n```ts\ninterface LayoutData {\n  nodes: Node[];\n  edges: Edge[];\n  config: MermaidConfig;\n  diagramId?: string;\n}\n```\n\n`runLayoutCore`, the stage that holds your algorithm, writes these fields and no others:\n\n| Field                       | On   | Meaning                                                                    |\n| --------------------------- | ---- | -------------------------------------------------------------------------- |\n| `node.x`, `node.y`          | Node | Center of the node, in layout space                                        |\n| `node.width`, `node.height` | Node | Arrive measured for leaf nodes — leave those alone; you set them on groups |\n| `edge.points`               | Edge | Polyline from source boundary to target boundary, at least 2 points        |\n| `edge.x`, `edge.y`          | Edge | Anchor for the edge label, when the edge has one                           |\n\nOne stage is allowed to do more. `prepareLayout` runs before measurement and may rebuild the graph — replace `data4Layout.nodes` and `data4Layout.edges`, add the synthetic nodes an edge label needs, drop what your algorithm handles another way. \"These fields and no others\" is a rule about `runLayoutCore`, where the graph is settled and only geometry moves.\n\n### Layout space\n\nPositions are centers. `node.x, node.y` is the middle of the node's box, so its left edge is `x - width / 2` and its top edge is `y - height / 2`. Layout libraries disagree about this — some report a node's top-left corner, some measure y upward from a bottom-left origin — so if you are wrapping one, convert its output in `runLayoutCore` rather than leaving the renderer to guess. Dagre and ELK both report centers, which is why the built-in layouts pass them straight through.\n\nBeyond that, layout space is a plain plane: x grows to the right, y grows downward. There is no fixed origin and no requirement that coordinates be positive. The renderer takes the bounding box of everything you produced and translates it into the SVG viewBox, so a layout centered on (0, 0) and a layout starting at (0, 0) render identically. Do not spend a pass normalizing coordinates; it is undone immediately.\n\n`Node` and `Edge` carry a good deal more than this, all of it defined in `rendering-util/types.ts`. Read the types there rather than working from what a debugger happens to show you: shape, label geometry, styling, and port information all travel on the same objects, and most of it belongs to the renderer rather than to you.\n\nTwo structural fields are your input, not your output. `node.isGroup` marks a subgraph container, and `node.parentId` names the group a node belongs to. Read them, never rewrite them.\n\nLeaf sizes arrive already measured, and they are not yours to compute. The renderer inserts every leaf node into the SVG, calls `getBBox()`, and writes `width` and `height` back before your algorithm runs, so a leaf whose size you recalculate or overwrite will have its label spill out of its shape at render time. Read them; treat them as fixed.\n\nGroups are the exception, and the only place you do set a size. A group's extent is a consequence of where you put its children, so nothing can measure it up front — every node with `isGroup` set needs a `width` and `height` from you, big enough to enclose its members and the title band. See [Groups](#groups).\n\nThat one measuring pass is the only step in the whole pipeline that touches the DOM, which is what makes everything after it testable in Node.\n\n## The five stages\n\nLayouts are built by calling `createCommonLayoutRenderer` from `rendering-util/layout-algorithms/common/index.ts`. It gives you five hooks, runs them in order, and handles painting:\n\n```ts\nexport const render = createCommonLayoutRenderer({\n  prepareLayout, // reshape LayoutData before measuring\n  measureLayout, // DOM: insert elements, read sizes (has a default)\n  runLayoutCore, // your algorithm, no DOM allowed\n  paintLayout, // escape hatch: take over painting entirely\n  afterPaint, // touch up after paths exist\n  paintOptions, // tweak the standard painter\n});\n```\n\nOnly `runLayoutCore` is required. The swimlanes layout is a complete example in twenty lines:\n\n```ts\nimport { createCommonLayoutRenderer } from '../common/index.js';\nimport { applySwimlaneLineJumps } from './adjustLayout.js';\nimport { prepareLayoutForSwimlanes } from './helpers.js';\nimport { createEdgeLabelNodes } from './edgeLabelNodes.js';\nimport { runSwimlaneLayoutCore } from './layoutCore.js';\n\nfunction prepareSwimlaneLayout(data4Layout: LayoutData): void {\n  prepareLayoutForSwimlanes(data4Layout);\n\n  const transformedData = createEdgeLabelNodes(data4Layout);\n  data4Layout.nodes = transformedData.nodes;\n  data4Layout.edges = transformedData.edges;\n}\n\nexport const render = createCommonLayoutRenderer({\n  prepareLayout: prepareSwimlaneLayout,\n  runLayoutCore: runSwimlaneLayoutCore,\n  afterPaint: applySwimlaneLineJumps,\n});\n```\n\n### Keep the core free of the DOM\n\n`runLayoutCore` must be a pure function of `LayoutData`. No `document`, no `getBBox`, no d3 selections.\n\nThe reason is testing. Node sizes get measured in a browser once and saved to a file. A test then loads those sizes, hands them to `runLayoutCore`, and gets back the same coordinates the browser would have produced, without opening a browser at all. That only holds while the core stays free of the DOM. The moment it reaches for `document`, it can only run inside a real page, and any test around it is exercising a different code path than the one your users hit.\n\nSo write the core as one exported function, and have both the browser and your tests call that same function.\n\n## A minimal layout\n\nThe examples from here on build a layout called `grid`. No such layout ships with Mermaid. It stands in for whatever you are writing, and the code below is what you would write to create it.\n\nPut the algorithm in `packages/mermaid/src/rendering-util/layout-algorithms//`. This one arranges leaf nodes in a grid and connects them with straight lines:\n\n```ts\n// layout-algorithms/grid/layoutCore.ts\nimport type { LayoutData } from '../../types.js';\n\nconst GAP = 60;\n\n/** DOM-free: positions come from measured sizes only. */\nexport function runGridLayoutCore(data4Layout: LayoutData): void {\n  const leaves = data4Layout.nodes.filter((node) => !node.isGroup);\n  const columns = Math.ceil(Math.sqrt(leaves.length));\n  const cell = Math.max(...leaves.map((n) => Math.max(n.width ?? 0, n.height ?? 0))) + GAP;\n\n  leaves.forEach((node, i) => {\n    node.x = (i % columns) * cell;\n    node.y = Math.floor(i / columns) * cell;\n  });\n\n  const byId = new Map(data4Layout.nodes.map((node) => [node.id, node]));\n  for (const edge of data4Layout.edges) {\n    const from = byId.get(edge.start ?? '');\n    const to = byId.get(edge.end ?? '');\n    if (!from || !to) {\n      continue;\n    }\n    edge.points = [\n      { x: from.x ?? 0, y: from.y ?? 0 },\n      { x: to.x ?? 0, y: to.y ?? 0 },\n    ];\n  }\n}\n```\n\n```ts\n// layout-algorithms/grid/index.ts\nimport { createCommonLayoutRenderer } from '../common/index.js';\nimport { runGridLayoutCore } from './layoutCore.js';\n\nexport const render = createCommonLayoutRenderer({ runLayoutCore: runGridLayoutCore });\n```\n\nThat renders. It is also wrong in most of the ways a layout can be wrong.\n\n## Registering the layout\n\nThe layouts that ship with Mermaid are listed in `registerDefaultLayoutLoaders()` in `packages/mermaid/src/rendering-util/render.ts`. Add one entry for yours:\n\n```ts\nregisterLayoutLoaders([\n  { name: 'dagre', loader: async () => await import('./layout-algorithms/dagre/index.js') },\n  { name: 'swimlane', loader: async () => await import('./layout-algorithms/swimlanes/index.js') },\n  // your new layout\n  { name: 'grid', loader: async () => await import('./layout-algorithms/grid/index.js') },\n]);\n```\n\nThe loader is lazy, so the code only downloads when a diagram asks for it. `cose-bilkent` is registered the same way but wrapped in a check on `includeLargeFeatures`, which is how a layout stays out of the tiny build. Users then select the layout by the name you registered:\n\n```text\n---\nconfig:\n  layout: grid\n---\nflowchart TB\n  A --> B\n```\n\n## Groups, labels, and edges\n\n### Groups\n\nA group node carries `isGroup: true`, and its members carry `parentId` pointing at it. Groups nest. Your algorithm owns the group's `x`, `y`, `width`, and `height`, and the frame must enclose every descendant with room for the title. Groups also have an optional `groupTitleRect` describing the header band. Edges routed through that band collide with the title text.\n\nThe standard painter draws a group as a cluster and everything else as a node. Override that with `paintOptions.isCluster` when your layout has its own idea of which nodes are containers.\n\n### Edge labels\n\nLabels need space reserved before positions are decided, otherwise they land on top of edges and nodes. The approach that works is to split each labelled edge into `start → label → end` around a temporary node, let the algorithm place that node like any other, then fold it back into an overlay label. Swimlanes does this in `createEdgeLabelNodes`, called from its `prepareLayout` hook so the dummy node is measured as real text along with everything else.\n\nInvent a third mechanism and your labels will not be checked by the validator, because the validator reads the label geometry this pattern produces.\n\n### Edge endpoints and markers\n\nEdge paths must start and end on the boundary of their nodes, not at the center and not floating in space. By default the painter recomputes the endpoint by intersecting the path with the node shape, which will quietly bend the last segment of a carefully routed edge. Layouts that route to exact ports should turn that off with `paintOptions.skipIntersect`.\n\nArrowheads occupy roughly the last ten pixels of the final segment. A bend inside that stretch puts a corner underneath the arrowhead, and the validator calls it: the constant is `EPS_FINAL_APPROACH`, and it is 10.\n\n### Self-loops and parallel edges\n\nAn edge with `start === end` has no direction to follow and needs its own route, usually a small rectangle off one side of the node. Parallel edges between the same pair need to be separated by hand, or they render as one line. Fixtures for both live in `e2e/platform/dev-diagrams/layout-tests/` as `self-loop.mmd`, `self-loop-2.mmd`, `self-loop-multi.mmd`, and `identical-edges.mmd`.\n\n## Validating the result\n\n`validateLayout` in `layout-algorithms/layout-utils/validateLayout.ts` is the shared judge of layout quality. It takes finished `LayoutData` and returns a verdict plus a score:\n\n```ts\nimport { validateLayout } from '../layout-utils/validateLayout.js';\n\nconst result = validateLayout(layout);\n// result.ok        → boolean, false when any hard constraint is broken\n// result.issues    → what broke, with node/edge ids and details\n// result.score     → 0 to 1000; exactly 0 whenever ok is false\n// result.breakdown → crossings, per-edge bend penalties, point histogram\n```\n\n### Hard constraints\n\n`ok` is false if any issue is present, and the score drops to zero. These are the failures worth knowing about before you write your router:\n\n| Issue                                                           | What it means                                         |\n| --------------------------------------------------------------- | ----------------------------------------------------- |\n| `node-overlap`                                                  | Two nodes occupy the same space                       |\n| `edge-intersects-node`, `edge-intersects-obstacle`              | A path crosses a node it does not connect to          |\n| `edge-intersects-group-title`                                   | A path runs through a subgraph's title band           |\n| `edge-endpoint-detached-from-node`, `edge-endpoint-inside-node` | An endpoint misses the boundary                       |\n| `edge-non-orthogonal`                                           | A segment is neither horizontal nor vertical          |\n| `edge-missing-points`                                           | Fewer than two points on an edge                      |\n| `edge-shared-subpath`, `edge-parallel-segment-too-close`        | Two edges overlap or run too close to tell apart      |\n| `edge-shared-attachment-point`, `edge-same-port-departure`      | Two edges leave a node from the same spot             |\n| `edge-bend-near-endpoint`, `edge-bend-overlaps-arrowhead`       | A corner sits under the arrowhead or against the node |\n| `edge-border-hugging`, `node-border-hugging`                    | Geometry runs along a border instead of clear of it   |\n| `edge-label-overlaps-node`, `edge-label-overlaps-foreign-edge`  | A label lands on top of something else                |\n| `edge-label-off-edge`                                           | A label sits away from the edge it belongs to         |\n\nThe tolerances are named constants at the top of `validateLayout.ts`, and two of them explain most first-time surprises: `EPS_FINAL_APPROACH` is 10, the stretch near an endpoint where a bend is not allowed, and `EPS_SHARED_ATTACH` is 3, how close two edges may attach to the same node before they count as sharing a point. The tests assert relative ordering rather than exact magnitudes, so treat the numbers as current rather than fixed.\n\nSome checks assume orthogonal routing. A layout with curved or diagonal edges will trip `edge-non-orthogonal` on every edge, so either route orthogonally or work out which subset of the validator applies to you before treating its score as a target.\n\n### The score\n\nWhen `ok` is true the score starts at 1000 and comes down. Bends are counted per edge from the polyline point count, and crossings are counted once globally:\n\n| Polyline points | Bends | Penalty             |\n| --------------- | ----- | ------------------- |\n| 2               | 0     | 0                   |\n| 3               | 1     | 0                   |\n| 4               | 2     | 5                   |\n| 5               | 3     | 12                  |\n| 6               | 4     | 30                  |\n| 7 or more       | 5+    | 30 × 2^(points − 6) |\n\nEach crossing costs 3. The curve is deliberately steep at the top end: one seven-bend edge costs more than twenty crossings, because a path nobody can follow is worse than a tidy diagram with intersections.\n\nThe score does not scale with diagram size. A small graph reaches 1000; a large one rarely will, so compare a fixture against its own history rather than against another fixture.\n\n`result.breakdown.edges` is sorted worst-first, which makes it the fastest way to find what is dragging a layout down.\n\n### One thing that looks useful and is not\n\n`layout-utils` also holds `scoreLayout`, which computes softer metrics: aspect ratio, average bends per edge, rank faithfulness, neighborhood preservation, straight-edge ratio. Sitting next to `validateLayout`, it looks like the quality half of a matched pair.\n\nIt is not wired into anything. Nothing in the layout pipeline calls it, no fixture spec calls it, and its only caller is its own unit test. Its `symmetryScore` is an unfinished placeholder that always returns `NaN`. Treat `validateLayout` as the only judge, and leave `scoreLayout` alone unless you are deliberately picking up that unfinished work.\n\nA third level is planned and not built. `compareLayoutSnapshot()` would diff a layout's structure against a stored baseline to catch regressions that stay inside the validator's tolerances. There is no such function today, so nothing depends on it.\n\n## Testing with DDLT\n\nDOM-Decoupled Layout Testing runs your algorithm in Node against sizes captured once from a real browser. Tests come back in seconds and give the same answer every time, and because the browser and the tests call the same core function, a fix in one is a fix in the other.\n\n### Tests must run the browser's code path\n\nThe model is `parse → measure → run layout → paint`, and the third step has to be a single function. Tests swap out the measuring; the browser does it for real. What runs in between must be identical.\n\nThat sounds obvious, and it is where this gets broken most often. A test-only layout entry point sitting alongside the browser's is a bug even when the two look like they do the same thing. This has bitten this repo more than once, and the shape is always the same. The browser entry wrapped the edge pipeline in a degeneracy check and a direction-violation check, with a fallback and a reroute branch hanging off them. The test backend called the pipeline directly and skipped all of that. Fixtures came back valid, the browser took the fallback, and the fallback drew a polyline straight through the interior of a node. The validator would have caught it. The test harness never saw it.\n\nSo when you wire up a test backend, find the function the browser actually calls and trace it end to end. If it needs the DOM, lift its DOM-free body into a helper and call that helper from both sides rather than reimplementing the sequence. Never point the test at a primitive that the browser wraps in checks, fallbacks, mirror branches, or second passes: the test has to include all of it.\n\nThere is a cheap way to prove the seam is real. Change the browser orchestration, add a fallback or switch a default, and the test result for the same fixture should move. If it does not, the test is running around your change. Fix the seam rather than relaxing the test.\n\nWhen a fixture passes in Node but looks broken on screen, run `validateLayout` on both, on the same fixture, and compare the issues. Different issues mean different pipelines. Put the two call chains side by side, look for pre-passes, the main call, and post-passes, and the first place they diverge is the seam.\n\n### Fixtures\n\nA fixture is a pair of files under `e2e/platform/dev-diagrams/layout-tests/`:\n\n```text\nlayout-tests/\n  simple-graph.mmd          ← real Mermaid source, parsed by the real parser\n  simple-graph.sizes.json   ← node dimensions captured from a browser render\n  ddlt-manifest.json        ← per-fixture overrides\n```\n\nThe `.mmd` file goes through the actual parser, so fixtures exercise the same `LayoutData` a user's diagram produces. The `.sizes.json` file holds one entry per leaf node and one per edge label, plus freshness metadata:\n\n```json\n{\n  \"metadata\": {\n    \"captureVersion\": 1,\n    \"sourceSha256\": \"…\",\n    \"capturedAt\": \"2026-02-09T10:00:00Z\",\n    \"capturedFrom\": \"theme=default&look=classic\"\n  },\n  \"nodes\": [{ \"id\": \"A\", \"width\": 62, \"height\": 39 }]\n}\n```\n\n`sourceSha256` is a hash of the `.mmd` file. Edit the diagram without recapturing and the test fails with a stale-fixture error instead of silently laying out with wrong sizes.\n\n`ddlt-manifest.json` gives a fixture a profile, which decides the backend it runs through, and can mark it `allowLevel1Failure` when a known failure is tracked in its own dedicated spec.\n\n### Capturing sizes\n\nThere is a button for this. Start the dev server with `pnpm dev`, open the explorer at `/dev/`, and pick your diagram out of the file tree, which is rooted at the same `dev-diagrams` folder the fixtures live in. Switch to the Code tab and click **Save sizes**, sitting next to Save.\n\nIt does the whole job. Unsaved edits to the diagram are written first, the diagram re-renders with size capture switched on, and the measurements go to `.sizes.json` beside the `.mmd`. The hash and the capture version are filled in for you, so the fixture passes the freshness check the moment it lands.\n\nThe button is only enabled for layouts that can produce capture data, and it explains itself through a tooltip when it is greyed out.\n\nIf you need to capture from somewhere other than the explorer, the same machinery is reachable from the console:\n\n```js\nwindow.mermaidCaptureSizes = true;\n// render the diagram, then:\ncopy(JSON.stringify(window.mermaidLastCapturedSizes.sizes, null, 2));\n```\n\nWritten by hand this way, the metadata block is yours to fill in. The capture module is dynamically imported only when that flag is set, so it never reaches a production bundle either way.\n\nRecapture when the diagram source changes or when a shape's real dimensions change. Do not recapture to make a failing test pass. The fixture is the before-picture, and rewriting it erases the regression you were trying to catch.\n\n### Parse the diagram, do not hand-build the graph\n\nIt is tempting to skip the parser and write the `LayoutData` for a test by hand. Resist it. Hand-built graphs drift from what the parser emits, usually in the identifiers, and once the ids differ the test is scoring a graph the browser never lays out.\n\nThe ids follow rules worth knowing, because fixture entries are matched against them:\n\n| Entity            | Id                                                                 |\n| ----------------- | ------------------------------------------------------------------ |\n| Content node      | The unquoted name from the diagram source, such as `A` or `E`      |\n| Unquoted subgraph | The subgraph text, kept as written                                 |\n| Quoted subgraph   | `subGraph`, numbered by a counter that ticks on every subgraph  |\n| Edge              | `L___`, the counter separating parallel edges |\n| Edge label node   | `edge-label---`                                |\n\nThe harness does the parsing for you. `parseMmdFileToLayoutData` strips frontmatter and directives, runs the real detector and parser, and stamps the direction the way the flowchart renderer does. `parseApplySizesAndLayout` goes further and applies the captured sizes and runs a backend. Reach for those before writing your own.\n\nIf you do drive the parser yourself, two calls come first: `addDiagrams()` to register the diagram types, and `preprocessDiagram()` to handle frontmatter before `Diagram.fromText()` sees it. Skipping either produces failures that look like parser bugs and are not.\n\nWhichever route you take, fail loudly when a fixture entry has no matching parser-produced node. A silent miss leaves a node at its default size, and the layout you then measure is not the layout anyone will see.\n\n### Writing a spec\n\nLoad the fixture, run your backend, assert on the result:\n\n```ts\nimport { describe, it, expect, beforeAll } from 'vitest';\nimport { loadDdltFixture } from '../ddlt/index.js';\nimport { validateLayout } from '../layout-utils/validateLayout.js';\n\ndescribe('swimlanes, 1-simple', () => {\n  let layout: LayoutData;\n  beforeAll(async () => {\n    layout = await loadDdltFixture('swimlanes/1-simple', { backendId: 'swimlanes' });\n  });\n\n  it('produces a valid layout', () => {\n    const result = validateLayout(layout);\n    expect(result.issues.map((i) => i.type)).toEqual([]);\n    expect(result.score).toBeGreaterThan(900);\n  });\n});\n```\n\nPass `backendId` explicitly. The default is a backend that is not present on `develop`, so a call without it throws rather than silently doing something reasonable. Your own layout needs an entry in `ddlt/backends.ts` before a fixture can run through it.\n\n`ddlt/index.ts` also exports `baselineDdltSpec(name)`, a one-liner that asserts the universal invariants: finite coordinates, at least two points per edge, no segment through an unrelated node, endpoints on boundaries. It hardcodes the same absent default backend and has no callers, so read it for the invariants it checks rather than calling it as it stands.\n\nThree shapes of test cover most needs. A tiny inline geometry test, where you build a handful of nodes by hand and check one routing rule, is right for a unit of the algorithm. A fixture-backed test on realistic sizes is right for a regression you can point at. A full source-to-layout run through the parser is right for anything a user reported. Match the surrounding folder: `swimlanes/query-process.ddlt.spec.ts` is the fullest worked example in the tree, and `layout-utils/validateLayout.spec.ts` and `ddlt/aggregateValidate.spec.ts` show the smaller shapes.\n\n### The sweep\n\n`ddlt/layout-fixtures.ddlt.spec.ts` discovers fixture pairs, runs them, and asserts validity across the board. It also emits an aggregate report, the number that tells you whether a change helped overall rather than on the one diagram you were staring at:\n\n```bash\n# The sweep, with the aggregate report\npnpm exec vitest run \\\n  packages/mermaid/src/rendering-util/layout-algorithms/ddlt/layout-fixtures.ddlt.spec.ts\n\n# Just the aggregate line\npnpm exec vitest run \\\n  packages/mermaid/src/rendering-util/layout-algorithms/ddlt/layout-fixtures.ddlt.spec.ts \\\n  2>&1 | grep 'DDLT-AGG'\n\n# One fixture while iterating\npnpm exec vitest run -t \"1-simple\" \\\n  packages/mermaid/src/rendering-util/layout-algorithms/ddlt/\n```\n\nThe report gives `total`, `avg`, `min`, and `invalid`, then one row per fixture with its score and issue types. Read it as a work queue: the lowest row is where the next improvement is. `ORTHO_TEST_DEBUG=1` in front of the command turns the layout logger from `fatal` up to `debug`, which helps when a row fails for reasons the report does not explain.\n\nThe sweep as written filters to the `swimlanes` profile and holds that profile's total against a floor. Adding a layout means adding its profile to the manifest and its own aggregate assertion, not assuming the existing one will pick your fixtures up.\n\n## The cases that break layouts\n\nA layout that handles a chain of boxes tells you almost nothing. The cases below are where engines actually fail, roughly in the order yours will fail them. Every one has a diagram in `layout-tests` already, so there is nothing to write before you can find out.\n\nMost of them are source only. The folder holds around 45 diagrams and about 15 have captured sizes, and the sweep discovers fixtures by looking for `.sizes.json` files and pairing each with its sibling `.mmd`. A diagram with no sizes file is not being tested by anything, however tricky it looks. Check before assuming a case is covered, and if the sizes are missing, open the diagram in the explorer and press Save sizes. That one click is the difference between a diagram sitting in a folder and a case the sweep will defend.\n\n### Self-loops\n\nAn edge whose source and target are the same node has no direction to travel in, and code that computes a route from two distinct positions tends to produce a zero-length path, a division by zero, or a dot. The route has to be manufactured: a small loop off one side, clear of the node and of anything the node's other edges are doing.\n\n`self-loop.mmd` is the single-node case, and the only one of the three with sizes captured. `self-loop-2.mmd` and `self-loop-multi.mmd` are harsher, putting a self-loop on all four nodes of a cycle, so every loop competes for space with real edges already using those sides.\n\n### Subgraphs\n\nThis is the long tail, and it is where most of the work is. A subgraph is a node that contains other nodes, so every edge endpoint now has two possible meanings and every frame is an obstacle that also has to move as its contents move.\n\n| Case                                  | Fixture                                                   |\n| ------------------------------------- | --------------------------------------------------------- |\n| A subgraph standing on its own        | `decoupled-subgraph.mmd`                                  |\n| Edge into a subgraph                  | `edge-to-subgraph.mmd`                                    |\n| Edge into a node inside a subgraph    | `edge-to-node-in-subgraph.mmd`                            |\n| Edge out of a subgraph                | `edge-from-subgraph.mmd`                                  |\n| Edge from inside out to a plain node  | `subgraph-variation.mmd`, `subgraph-variation-2.mmd`      |\n| Between two sibling subgraphs         | `nested-sg-outgoing-2.mmd`, `nested-incoming.mmd`         |\n| Inside one subgraph to inside another | `nested-sg-outgoing-2.mmd`, `nested-subgraphs-2.mmd`      |\n| Nested subgraphs                      | `nested-subgraphs.mmd`, `nested-subgraphs-3.mmd`          |\n| Edges crossing several nesting levels | `nested-sb-edges-in-out.mmd`, `nested-outgoing-edges.mmd` |\n| Subgraph titles competing for space   | `subgraph-labels.mmd` and its two variants                |\n\nWork down that list in order. Each row assumes the ones above it. Only the first two rows have captured sizes today, so everything below them is a diagram you can open in the browser rather than a test that will tell you when you break it.\n\nTwo failures recur. An edge that ends on a subgraph should stop at the frame rather than diving through to a member, and an edge that ends on a member has to cross the frame without clipping the title band. The other is sizing: a frame has to enclose everything inside it including the labels, and it has to keep doing so after a later pass nudges a member.\n\n### Parallel edges\n\nTwo edges between the same pair of nodes are one edge as far as most routing code is concerned, because both get the same endpoints and the same optimal path, so they land exactly on top of each other and the diagram silently loses information. They have to be separated deliberately.\n\n`identical-edges.mmd` is the minimal case. `multiple-edges.mmd` adds a reverse edge to the bundle, so the fix cannot just fan edges out by index and ignore direction. `identical-edges-in-subgraph.mmd` puts a bundle in each direction inside a frame, where the room to fan out is bounded.\n\n### Busy nodes\n\nA node with more than four edges cannot give each one its own side. Ports have to share sides, share sides in an order that does not cross, and stay far enough apart to be told apart. Engines that assign one edge per side degrade sharply here, usually into a knot right against the node.\n\n`edge-types.mmd` piles several edges onto a single node with a different arrow type on each. `Company.mmd` and `Company-simp.mmd` are the realistic version of the same problem, and both have sizes captured.\n\n### Combinations, and both directions\n\nThese interact, and the combinations are worse than the parts. A self-loop on a busy node inside a nested subgraph exercises all four at once, which is why the larger fixtures are worth keeping even though a failure in one is harder to diagnose. `deploy-pipeline.mmd`, `life-choices.mmd`, and `project-sox2.mmd` are the closest thing here to diagrams a user would actually write.\n\nRun the ones that matter in `TB` and `LR` both. Layout code tends to grow an implicit assumption about which way the graph flows, and the second direction is where that assumption surfaces.\n\n## Before you invent something\n\nGraph drawing has a long research record, and most of what a layout engine needs has been studied for decades. Orthogonal routing, compaction, port and side constraints, layered pipelines, crossing minimisation: none of these are new problems, and reading up on one is usually faster than deriving a heuristic and discovering its failure modes one fixture at a time.\n\nThe vocabulary gap is worth knowing about, because it makes searching harder than it needs to be. What this codebase calls a jog, the literature calls a bend. A port window is a pin or a side constraint. A rail is a track or a channel. A group is a compound vertex.\n\nWhen you knowingly diverge from what the established approach recommends, write down why in the pull request, along with how you checked that the divergence works.\n\n## Watching it in the browser while the tests run\n\nThe sweep tells you a score dropped. It does not tell you the diagram now looks like a plate of spaghetti. Keep a browser open next to the test run.\n\n```bash\npnpm dev\n```\n\nDo not assume the address. The port is derived from the path of the checkout, so every worktree and every clone gets its own and you can run several dev servers side by side without them fighting over 9000. The server prints its URL as it starts, before the build output scrolls past. `MERMAID_DEV_PORT` pins it if you want a fixed one.\n\nOpen `/dev/` and you get the explorer: the fixture tree on one side, the diagram on the other, a code tab for editing the source, and a layout picker for comparing your algorithm against the others on the same input. It reloads when you change the source, so an edit to your algorithm redraws the diagram without you touching the browser.\n\nFor a diagram that is not in the fixture tree, copy the standalone page template instead:\n\n```bash\ncp demos/dev/example.html demos/dev/grid.html\n```\n\nThat lands at `/dev/grid.html` on the same server. Put the diagram in the page and name your layout in the frontmatter:\n\n```html\n
\n---\nconfig:\n  layout: grid\n---\nflowchart TB\n  A --> B\n  B --> C\n
\n```\n\nA workflow that holds up over a long session:\n\n1. Run the sweep in one terminal, filtered to the fixture you are working on.\n2. Keep that same fixture open in the browser.\n3. Make one change and watch both. The score says whether it helped, and the picture says whether the score was measuring the right thing.\n4. Before committing, run the full sweep and confirm the aggregate did not drop.\n\nThe two disagree more often than you would expect, and the disagreement is informative. A score that improves while the diagram gets worse means the validator is blind to something, and that gap is worth writing down.\n\nUse the browser to check what the tests cannot see: text that overflows its shape, arrowheads pointing the wrong way, subgraph frames cutting through labels.\n\n## Performance on large diagrams\n\nA layout that is pleasant on ten nodes can be unusable on a thousand, and the difference does not show up in the fixture sweep — DDLT fixtures are small on purpose, so they say nothing about how your algorithm scales. There is a separate corpus for that.\n\n### The corpus\n\n`e2e/platform/dev-diagrams/performance/flowcharts/` holds fifteen real flowcharts, anonymized and grouped by size:\n\n```text\nperformance/flowcharts/\n  medium1.mmd … medium5.mmd   ← ~45-50 KB of source each\n  large1.mmd  … large5.mmd    ← ~70-75 KB\n  huge1.mmd   … huge5.mmd     ← 120-240 KB\n  baseline.json               ← a captured profiler run, for comparison\n```\n\nThe buckets are by source size, and node count does not follow it. `huge1.mmd` is around 2400 nodes with barely fifty edges; `huge2.mmd` is a few hundred nodes with over a thousand edges; `huge3.mmd` is a hundred nodes buried in `classDef` declarations. That spread is deliberate. These are real diagrams people drew, so the shapes that break layout algorithms in practice — one node with sixty edges, deeply nested subgraphs, a long thin chain, a wide flat fan — appear in the proportions they actually occur rather than the ones a generator would produce. Several carry frontmatter config, `handDrawn` look, and HTML labels, so they exercise the measuring pass as well as the layout.\n\n### Running the profiler\n\nProfiling lives in the same dev explorer as everything else in the previous section.\n\n1. `pnpm dev`, then open `/dev/` at the URL the server printed.\n2. Select `performance/flowcharts` in the file tree.\n3. In the Profiler panel, tick the layouts to compare, set the scope to **Folder**, choose the number of iterations, and press **Run profile**.\n\nEach layout is warmed up once and discarded, then every diagram is rendered `iterations` times per layout, with the fastest and slowest run of each series dropped before averaging. The score is total milliseconds across the set, lower is better. **Copy JSON** puts the whole run on the clipboard in the same shape as `baseline.json`.\n\nOne rough edge: the profiler's layout checkboxes come from a hardcoded list in `.esbuild/dev-explorer/diagram-viewer.ts` (`ALL_LAYOUTS`). A new layout will not appear there until you add it, even after it is registered with Mermaid.\n\n### Reading the table\n\nThe row you care about is rarely the total. Rendering is broken into phases, and only one of them is yours:\n\n| Phase       | What it covers                                              |\n| ----------- | ----------------------------------------------------------- |\n| `parse`     | Diagram text to db                                          |\n| `prepare`   | Building `LayoutData`, including your `prepareLayout`       |\n| `measure`   | DOM insertion and `getBBox` / `getBoundingClientRect`       |\n| `layout`    | The layout call, split into `↳ lib (external)` and `↳ ours` |\n| `paint`     | Drawing nodes and edges from your coordinates               |\n| `serialize` | SVG to string                                               |\n\n`↳ ours (wrapper)` is your code; `↳ lib (external)` is the third-party library underneath, if you wrap one. A layout that is slow because ELK is slow and a layout that is slow because of your own pass are the same number in the `layout` row and completely different problems one row down.\n\n`huge3.mmd` makes the point: 1410 ms in `parse` against 1.5 ms in `layout`. Its total is dominated by something you cannot fix from a layout algorithm, and reading totals would send you optimizing the wrong file.\n\nWatch `measure` too. It is not your phase, but it is downstream of `prepareLayout` — every synthetic node you add for an edge label is another element inserted into the DOM and measured, so a `prepareLayout` that is generous with helper nodes shows up as someone else's regression.\n\n### Comparing against the baseline\n\n`baseline.json` is a captured run over the same folder — dagre and elk, ten iterations, `theme=redux`, `look=neo`, with the capture date in the file.\n\nTreat the absolute numbers as a record of one machine on one day, not a threshold. They will not reproduce on your hardware, and a CI runner would not reproduce them either. What does carry over is the shape: the relative cost of the phases, which diagrams are layout-dominated and which are parse-dominated, and the ratio between the layouts. Profile your layout in the same run as dagre and elk and compare within that run.\n\n### What actually goes wrong\n\nIn practice the regressions are algorithmic, not micro-optimizations:\n\n- A pass over every pair of nodes. Fine at 50 nodes, 1.4 million comparisons at 1200.\n- `edges.filter((e) => e.start === node.id)` inside a loop over nodes — O(V·E) hidden behind two readable lines. Build the adjacency map once, before the loop.\n- Rebuilding a lookup inside an iterative refinement step, so an O(V) cost becomes O(V) per iteration.\n- Recursing into subgraphs without memoizing, and revisiting the same subtree once per ancestor.\n\nProfile before you optimize. Run the corpus, find the diagram where your `↳ ours` row is worst, and read that one — the corpus is small enough that the answer is usually one diagram and one loop.\n\n## Shipping as a separate package\n\nAn external layout uses the same `render` signature. Instead of editing the built-in registry, export a loader array and let the consumer register it:\n\n```ts\nimport type { LayoutLoaderDefinition } from 'mermaid';\n\nconst loader = async () => await import('./render.js');\n\nconst layouts: LayoutLoaderDefinition[] = [{ name: 'grid', loader, algorithm: 'grid.compact' }];\n\nexport default layouts;\n```\n\n```js\nimport mermaid from 'mermaid';\nimport layouts from 'my-mermaid-layout';\n\nmermaid.registerLayoutLoaders(layouts);\n```\n\nThe `algorithm` field is passed back to your renderer through `options`, which lets one package register several named variants that share an implementation.\n\nPackage it separately when the layout pulls in a large dependency. Everything else belongs in the main package, where it gets covered by the fixture sweep.\n\n## Checklist\n\n- [ ] `runLayoutCore` is one exported function with no DOM access\n- [ ] The browser and the tests call that same function\n- [ ] Group frames enclose their members and leave the title band clear\n- [ ] Edge labels reserve space before positions are decided\n- [ ] Edge endpoints land on node boundaries\n- [ ] Self-loops and parallel edges have routes\n- [ ] `validateLayout` returns `ok: true` on your fixtures\n- [ ] Fixtures exist, with captured sizes, for the cases the algorithm was written to handle\n- [ ] Your backend is registered in `ddlt/backends.ts` and your profile in `ddlt-manifest.json`\n- [ ] The sweep passes and the aggregate score has not dropped\n- [ ] `.mmd` fixtures under `e2e/diagrams/` cover the layout visually, since layout changes are rendering changes\n- [ ] The layout has been profiled against `performance/flowcharts/`, and the `↳ ours` row is understood\n\n\n# Adding a New Diagram/Chart (Deprecated) 📊\n\n```warning\nJISON grammars are deprecated in mermaid. Please use Langium instead. See [New Diagram](./new-diagram.md) for more information.\n\n**New diagrams with JISON grammars will not be accepted.**\n```\n\n### Step 1: Grammar & Parsing\n\n#### Grammar\n\nThis would be to define a JISON grammar for the new diagram type. That should start with a way to identify that the text in the mermaid tag is a diagram of that type. Create a new folder under diagrams for your new diagram type and a parser folder in it. This leads us to step 2.\n\nFor instance:\n\n- the flowchart starts with the keyword _graph_\n- the sequence diagram starts with the keyword _sequenceDiagram_\n\n#### Store data found during parsing\n\nThere are some jison specific sub steps here where the parser stores the data encountered when parsing the diagram, this data is later used by the renderer. You can during the parsing call an object provided to the parser by the user of the parser. This object can be called during parsing for storing data.\n\n```jison\nstatement\n\t: 'participant' actor  { $$='actor'; }\n\t| signal               { $$='signal'; }\n\t| note_statement       { $$='note';  }\n\t| 'title' message      { yy.setTitle($2);  }\n\t;\n```\n\nIn the extract of the grammar above, it is defined that a call to the setTitle method in the data object will be done when parsing and the title keyword is encountered.\n\n```note\nMake sure that the `parseError` function for the parser is defined and calling `mermaid.parseError`. This way a common way of detecting parse errors is provided for the end-user.\n```\n\nFor more info look at the example diagram type:\n\nThe `yy` object has the following function:\n\n```javascript\nexports.parseError = function (err, hash) {\n  mermaid.parseError(err, hash);\n};\n```\n\nwhen parsing the `yy` object is initialized as per below:\n\n```javascript\nconst parser = exampleParser.parser;\nparser.yy = db;\n```\n\n### Step 2: Rendering\n\nWrite a renderer that given the data found during parsing renders the diagram. To look at an example look at sequenceRenderer.js rather than the flowchart renderer as this is a more generic example.\n\nPlace the renderer in the diagram folder.\n\n### Step 3: Detection of the new diagram type\n\nThe second thing to do is to add the capability to detect the new diagram to type to the detectType in `diagram-api/detectType.ts`. The detection should return a key for the new diagram type.\n[This key will be used to as the aria roledescription](#aria-roledescription), so it should be a word that clearly describes the diagram type.\nFor example, if your new diagram uses a UML deployment diagram, a good key would be \"UMLDeploymentDiagram\" because assistive technologies such as a screen reader\nwould voice that as \"U-M-L Deployment diagram.\" Another good key would be \"deploymentDiagram\" because that would be voiced as \"Deployment Diagram.\" A bad key would be \"deployment\" because that would not sufficiently describe the diagram.\n\nNote that the diagram type key does not have to be the same as the diagram keyword chosen for the [grammar](#grammar), but it is helpful if they are the same.\n\n### Step 4: The final piece - triggering the rendering\n\nAt this point when mermaid is trying to render the diagram, it will detect it as being of the new type but there will be no match when trying to render the diagram. To fix this add a new case in the switch statement in main.js:init this should match the diagram type returned from step #2. The code in this new case statement should call the renderer for the diagram type with the data found by the parser as an argument.\n\n## Usage of the parser as a separate module\n\n### Setup\n\n```javascript\nconst graph = require('./graphDb');\nconst flow = require('./parser/flow');\nflow.parser.yy = graph;\n```\n\n### Parsing\n\n```javascript\nflow.parser.parse(text);\n```\n\n### Data extraction\n\n```javascript\ngraph.getDirection();\ngraph.getVertices();\ngraph.getEdges();\n```\n\nThe parser is also exposed in the mermaid api by calling:\n\n```javascript\nconst parser = mermaid.getParser();\n```\n\nNote that the parse needs a graph object to store the data as per:\n\n```javascript\nflow.parser.yy = graph;\n```\n\nLook at `graphDb.js` for more details on that object.\n\n## Layout\n\nIf you are using a dagre based layout, please use flowchart-v2 as a template and by doing that you will be using dagre-wrapper instead of dagreD3 which we are migrating away from.\n\n### Common parts of a diagram\n\nThere are a few features that are common between the different types of diagrams. We try to standardize the diagrams that work as similar as possible for the end user. The commonalities are:\n\n- Directives, a way of modifying the diagram configuration from within the diagram code.\n- Accessibility, a way for an author to provide additional information like titles and descriptions to people accessing a text with diagrams using a screen reader.\n- Themes, there is a common way to modify the styling of diagrams in Mermaid.\n- Comments should follow mermaid standards\n\nHere are some pointers on how to handle these different areas.\n\n## Accessibility\n\nMermaid automatically adds the following accessibility information for the diagram SVG HTML element:\n\n- aria-roledescription\n- accessible title\n- accessible description\n\n### aria-roledescription\n\nThe aria-roledescription is automatically set to [the diagram type](#step-3--detection-of-the-new-diagram-type) and inserted into the SVG element.\n\nSee [the definition of aria-roledescription](https://www.w3.org/TR/wai-aria-1.1/#aria-roledescription) in [the Accessible Rich Internet Applications W3 standard.](https://www.w3.org/WAI/standards-guidelines/aria/)\n\n### accessible title and description\n\nThe syntax for accessible titles and descriptions is described in [the Accessibility documentation section.](../config/accessibility.md)\n\nAs a design goal, the jison syntax should be similar between the diagrams.\n\n```jison\n\n* lexical grammar */\n%lex\n%x acc_title\n%x acc_descr\n%x acc_descr_multiline\n\n%%\naccTitle\\s*\":\"\\s*                                { this.begin(\"acc_title\");return 'acc_title'; }\n(?!\\n|;|#)*[^\\n]*                     { this.popState(); return \"acc_title_value\"; }\naccDescr\\s*\":\"\\s*                                { this.begin(\"acc_descr\");return 'acc_descr'; }\n(?!\\n|;|#)*[^\\n]*                     { this.popState(); return \"acc_descr_value\"; }\naccDescr\\s*\"{\"\\s*                                { this.begin(\"acc_descr_multiline\");}\n[\\}]                        { this.popState(); }\n[^\\}]*                      return \"acc_descr_multiline_value\";\n\nstatement\n    : acc_title acc_title_value  { $$=$2.trim();yy.setTitle($$); }\n    | acc_descr acc_descr_value  { $$=$2.trim();yy.setAccDescription($$); }\n    | acc_descr_multiline_value { $$=$1.trim();yy.setAccDescription($$); }\n\n```\n\nThe functions for setting title and description are provided by a common module. This is the import from flowDb.js:\n\n```\nimport {\n  setAccTitle,\n  getAccTitle,\n  getAccDescription,\n  setAccDescription,\n  clear as commonClear,\n} from '../../commonDb';\n```\n\nThe accessibility title and description are inserted into the SVG element in the `render` function in mermaidAPI.\n\n## Theming\n\nMermaid supports themes and has an integrated theming engine. You can read more about how the themes can be used [in the docs](../config/theming.md).\n\nWhen adding themes to a diagram it comes down to a few important locations in the code.\n\nThe entry point for the styling engine is in **src/styles.js**. The getStyles function will be called by Mermaid when the styles are being applied to the diagram.\n\nThis function will in turn call a function _your diagram should provide_ returning the css for the new diagram. The diagram specific, also which is commonly also called getStyles and located in the folder for your diagram under src/diagrams and should be named styles.js. The getStyles function will be called with the theme options as an argument like in the following example:\n\n```js\nconst getStyles = (options) =>\n  `\n    .line {\n      stroke-width: 1;\n      stroke: ${options.lineColor};\n      stroke-dasharray: 2;\n    }\n    // ...\n    `;\n```\n\nNote that you need to provide your function to the main getStyles by adding it into the themes object in **src/styles.js** like in the xyzDiagram in the provided example:\n\n```js\nconst themes = {\n  flowchart,\n  'flowchart-v2': flowchart,\n  sequence,\n  xyzDiagram,\n  //...\n};\n```\n\nThe actual options and values for the colors are defined in **src/theme/theme-[xyz].js**. If you provide the options your diagram needs in the existing theme files then the theming will work smoothly without hiccups.\n\n\n# Adding a New Diagram/Chart 📊\n\nA diagram type in Mermaid is a plugin. You write a parser, a database, a renderer, and a styles\nfunction, register them under an id, and Mermaid handles detection, lazy loading, theming, and\nsanitization for you.\n\nThe use case diagram is the reference implementation for new work. When this guide says \"look at\nusecase\", the files are in `packages/mermaid/src/diagrams/usecase/`. Read them alongside these\nsteps: they are short, and they show the current conventions rather than the historical ones that\nolder diagrams still carry.\n\n## What a diagram is made of\n\nEach diagram exports a `DiagramDefinition` (`diagram-api/types.ts`) from a single entry file. The\nwhole of `usecaseDiagram.ts` is this:\n\n```ts\nimport type { DiagramDefinition } from '../../diagram-api/types.js';\nimport { parser } from './parser/usecase.chevrotain.js';\nimport { db } from './usecaseDb.js';\nimport { renderer } from './usecaseRenderer.js';\nimport styles from './styles.js';\n\nexport const diagram: DiagramDefinition = {\n  parser,\n  db,\n  renderer,\n  styles,\n};\n```\n\n| Part     | What it does                                                                   |\n| -------- | ------------------------------------------------------------------------------ |\n| parser   | Turns diagram text into calls on the db. Fails with a useful message otherwise |\n| db       | Holds the parsed model and hands it to the renderer                            |\n| renderer | Draws the SVG from what the db holds                                           |\n| styles   | Maps theme variables to CSS for your diagram                                   |\n| detector | A regex test that recognizes your diagram's first line. Lives in its own file  |\n\nTwo rules apply to everything in your folder:\n\nYour diagram must be self-contained. Never import from another diagram's folder. You may import\nfrom `diagrams/common/` and from `rendering-util/`, and that is the whole list. Cross-diagram\nimports create coupling that breaks unrelated diagrams later, so a reviewer will block on this.\n\nYour db must not carry state from one render into the next. `Diagram.fromText()` reads `db` off\nthe registered definition and calls `db.clear?.()` before parsing, and there are two supported\nways to satisfy that.\n\nA getter, which builds a new db on every read, so each render gets its own:\n\n```ts\nexport const diagram: DiagramDefinition = {\n  parser,\n  get db() {\n    return new TreeMapDB();\n  },\n  renderer,\n  styles,\n};\n```\n\nOr one shared db whose `clear()` resets every field it owns, plus the shared accessibility state\nin `diagrams/common/commonDb.ts`:\n\n```ts\nexport const diagram: DiagramDefinition = { parser, db, renderer, styles };\n```\n\nPrefer the getter in a new diagram. Isolation is then structural — a field added later cannot be\nforgotten in `clear()`, which is the way the shared form goes wrong. The use case diagram used as\nthe reference here takes the shared form, and pays for it by keeping every mutable field on one\n`state` object that `clear()` replaces wholesale, rather than resetting fields one by one.\n\nEither way the rule underneath is the same: all mutable state lives on the db, never in module\nscope. Module-level state survives `clear()` in both forms, and two diagrams of the same type on\none page will leak into each other.\n\n## Step 1: Grammar and parsing\n\nNew diagram grammars should use [Chevrotain](https://chevrotain.io/docs/), co-located with the\ndiagram itself under `packages/mermaid/src/diagrams//parser/`. The use case diagram is\nthe reference implementation: a lexer, a `CstParser`, and a CST visitor that builds the diagram\nmodel, sharing `diagrams/common/parser/runChevrotainParse.ts` to run the lexer/parser pair and\nreport failures with source positions.\n\nKeeping the grammar next to the diagram mirrors the existing JISON layout, so a diagram stays\nself-contained and the parser does not have to be released from a separate package.\n\nSeveral existing diagrams (architecture, gitGraph, info, packet, pie, radar, treemap) instead use\n[Langium](https://langium.org/docs/reference/grammar-language/) grammars in `packages/parser`, and\nolder diagrams use JISON. Both remain supported, so modify them in place for bug fixes rather than\nrewriting, but neither is the target for new work. These PRs show the Langium approach:\n\n- https://github.com/mermaid-js/mermaid/pull/4839\n- https://github.com/mermaid-js/mermaid/pull/4751\n\nWhichever you use, invalid input has to produce a parse error with a line and column, never a\nstack trace. Mermaid runs inside other people's pages, and a thrown exception there is a broken\npage rather than a broken diagram.\n\n## Step 2: The database\n\nThe db collects what the parser found and exposes getters for the renderer. Look at\n`usecaseDb.ts`. Alongside your own accessors, re-export the shared title and accessibility setters\nfrom `diagrams/common/commonDb.ts` so that authors get the same `title`, `accTitle`, and\n`accDescr` syntax they get everywhere else:\n\n```js\nimport {\n  setAccTitle,\n  getAccTitle,\n  getAccDescription,\n  setAccDescription,\n  setDiagramTitle,\n  getDiagramTitle,\n  clear as commonClear,\n} from '../common/commonDb.js';\n```\n\nYour own `clear()` should call `commonClear()` as well as resetting your own fields.\n\n## Step 3: The renderer\n\nWrite a renderer that draws the diagram from what the db holds. `usecaseRenderer.ts` is a good\nstarting point, and `sequenceRenderer.js` is a more generic older example than the flowchart\nrenderer. The renderer belongs in your diagram folder.\n\nTwo things are easy to miss and both get flagged in review.\n\nApply the configured padding and hand the sizing to the shared helper, so your diagram scales like\nevery other diagram instead of rendering at some unrelated size:\n\n```ts\nimport { setupViewPortForSVG } from '../../rendering-util/setupViewPortForSVG.js';\n\nsetupViewPortForSVG(svg, padding, 'usecaseDiagram', config.useMaxWidth);\n```\n\nSupport hand-drawn mode if your drawing approach allows it. The config carries a `look`, and\ndiagrams check it directly:\n\n```ts\nconst isHandDrawn = look === 'handDrawn';\n```\n\nIf a third party library makes hand-drawn output impossible, that is an acceptable answer, but say\nso in your diagram's documentation page so users are not left guessing.\n\n## Step 4: Detection and registration\n\nDetection lives in its own file next to the diagram, not in `detectType.ts`. A detector is a\nregex test plus a lazy loader, and it exports an `ExternalDiagramDefinition`:\n\n```ts\nconst id = 'usecase';\n\nconst detector: DiagramDetector = (txt) => {\n  return /^\\s*usecase-beta(?:\\s|$)/.test(txt);\n};\n\nconst loader: DiagramLoader = async () => {\n  const { diagram } = await import('./usecaseDiagram.js');\n  return { id, diagram };\n};\n\nexport const usecase: ExternalDiagramDefinition = { id, detector, loader };\n```\n\nThen import it in `diagram-api/diagram-orchestration.ts` and add it to the\n`registerLazyLoadedDiagrams(...)` call. Order matters there: the first detector that returns true\nwins, so a loose pattern placed early will swallow other diagrams. The loader is what keeps\nMermaid's bundle small, because your diagram is only fetched once someone writes one.\n\n[The id becomes the aria roledescription](#aria-roledescription), so pick a word that describes\nthe diagram out loud. For a UML deployment diagram, \"UMLDeploymentDiagram\" works, because a screen\nreader voices it as \"U-M-L Deployment diagram\", and so does \"deploymentDiagram\". \"deployment\" on\nits own does not say enough.\n\nThe id does not have to match the keyword you chose in the\n[grammar](#step-1-grammar-and-parsing), though it helps when they agree.\n\n## Step 5: Theming\n\nMermaid has an integrated theming engine, described in more detail [in the docs](../config/theming.md).\n\nYour diagram provides a `getStyles` function in `styles.ts` in your diagram folder. It is called\nwith the resolved theme options and returns CSS:\n\n```js\nconst getStyles = (options) =>\n  `\n    .line {\n      stroke-width: 1;\n      stroke: ${options.lineColor};\n      stroke-dasharray: 2;\n    }\n    // ...\n    `;\n```\n\nThere is nothing to wire up by hand. `registerDiagram()` passes your `styles` to\n`addStylesForDiagram()`, and the styling engine picks it up from there.\n\nEvery color must come from `options`. A hardcoded hex value looks fine in the default theme and\nthen breaks in dark mode, so reviewers treat hardcoded colors as a defect. The values themselves\nare defined in the theme files under `src/themes/`; if your diagram needs a variable that does not\nexist yet, add it there so all five themes define it.\n\n## Step 6: Configuration\n\nIf your diagram has options, add them to `src/schemas/config.schema.yaml`, both as an entry in the\nlist of diagram config keys and as its own config block. Then regenerate the types:\n\n```bash\npnpm run --filter mermaid types:build-config\n```\n\nNever edit `config.type.ts` by hand. It is generated, CI verifies it against the schema, and a\nmanual edit is a blocking review finding.\n\n## Accessibility\n\nMermaid automatically adds the following accessibility information for the diagram SVG HTML element:\n\n- aria-roledescription\n- accessible title\n- accessible description\n\n### aria-roledescription\n\nThe aria-roledescription is automatically set to\n[the diagram type](#step-4-detection-and-registration) and inserted into the SVG element.\n\nSee [the definition of aria-roledescription](https://www.w3.org/TR/wai-aria-1.1/#aria-roledescription) in [the Accessible Rich Internet Applications W3 standard.](https://www.w3.org/WAI/standards-guidelines/aria/)\n\n### accessible title and description\n\nThe syntax for accessible titles and descriptions is described in [the Accessibility documentation section.](../config/accessibility.md)\n\nYou get both for free once your db re-exports the setters shown in\n[Step 2](#step-2-the-database). The values are inserted into the SVG element in the `render`\nfunction in mermaidAPI.\n\n## Step 7: Tests\n\nA new diagram without tests will not be merged. There are three kinds, and none of them takes long.\n\nUnit tests for the parser and db go next to the code as `*.spec.ts`. Cover the syntax you\ndocumented, and cover invalid input too: a diagram that accepts nonsense silently is worse than\none that rejects it. Run them with `vitest run packages/mermaid/src/diagrams/`.\n\nVisual regression tests come from `.mmd` fixtures. Put one file per scenario in\n`e2e/diagrams//`, and that is the whole job:\n`e2e/rendering/mmd-snapshots.spec.ts` walks that directory, renders each fixture, and snapshots\nit, grouping the results by folder. Screenshot names must be unique across the whole tree, and the\nrun fails fast if two fixtures collide. `e2e/sheet-order.json` holds the ordering. Run the suite\nwith `pnpm e2e`. Cover realistic diagrams rather than one minimal smoke test, and include a\nfixture per theme if your styling is at all involved.\n\nA documentation test keeps your examples honest. `usecase.docs.spec.ts` reads the published\n`syntax/usecase.md`, extracts every ` ```mermaid-example ` block, and parses it. Copy that pattern\nand your documentation cannot drift into examples that no longer work.\n\n## Step 8: Documentation, demos, and examples\n\nWrite your syntax page as `packages/mermaid/src/docs/syntax/.md`. Edit only the files\nunder `src/docs/`; the top-level `/docs` folder is generated and your changes there will be\noverwritten. Mark the version with the placeholder, as `usecase.md` does with\n`# Use case diagrams (12.0.0+)`, and the release process substitutes the real\nnumber.\n\nAdd the page to the sidebar in `.vitepress/config.ts` under `sidebarSyntax()`. A page with no\nsidebar entry is reachable only by URL, which in practice means nobody reads it.\n\nAdd a demo page at `demos/.html` and link it from `demos/index.html`, following any\nof the existing demos.\n\nAdd at least one entry to the `@mermaid-js/examples` package, which is what tools like\nmermaid.live use to help people get started. Duplicate an existing file such as\n`packages/examples/src/examples/flowchart.ts`, adapt it, then import it in\n`packages/examples/src/index.ts` and add it to the `examples` array. Mark one example as the\ndefault, and add more to show off individual features.\n\nIf your syntax introduces new keywords, add them to `.cspell/mermaid-terms.txt`. The pre-commit\nhook runs CSpell and will otherwise reject the commit.\n\n## Step 9: Changeset and pull request\n\nRun `pnpm changeset`, choose the `mermaid` package and a `minor` bump, and write a description\nprefixed with `feat:`.\n\nOpen the PR against `develop` and link the issue it resolves. New diagram types are large by\nnature, and that is fine, but keep unrelated refactors out of the same branch.\n\n## Reviewer's checklist\n\nThis is what a reviewer checks. Going through it yourself first is the fastest way to a short\nreview.\n\n- [ ] Parser uses Chevrotain, co-located under `diagrams//parser/`\n- [ ] Invalid input produces a parse error with position, not a crash\n- [ ] `DiagramDefinition` exports parser, db, renderer, and styles\n- [ ] Detector in its own file, registered in `diagram-orchestration.ts`, ordered so it does not shadow other diagrams\n- [ ] Diagram id reads well as an aria roledescription\n- [ ] db holds no module-level state and `clear()` resets everything, including `commonClear()`\n- [ ] No imports from other diagrams' folders\n- [ ] Renderer applies padding and `useMaxWidth` through `setupViewPortForSVG`\n- [ ] Handdrawn mode implemented, or its absence documented\n- [ ] `styles.ts` takes theme options, with no hardcoded colors\n- [ ] Config options added to `config.schema.yaml` and `config.type.ts` regenerated, never hand-edited\n- [ ] Accessibility setters re-exported from `common/commonDb.ts`\n- [ ] Unit tests for parser and db, covering invalid input\n- [ ] `.mmd` fixtures in `e2e/diagrams//` for visual regression\n- [ ] Documentation examples covered by a docs spec\n- [ ] Syntax page under `src/docs/syntax/`, with `MERMAID_RELEASE_VERSION` and a sidebar entry\n- [ ] Demo page and `demos/index.html` link\n- [ ] Example added to `@mermaid-js/examples`, one marked default\n- [ ] New keywords added to `.cspell/mermaid-terms.txt`\n- [ ] Changeset created (`minor`, `feat:`)\n- [ ] PR targets `develop` and links its issue\n\n\n# Questions or Suggestions?\n\n## Search for Existing Issue\n\nFirst search to see if someone has already asked (and hopefully been answered) or suggested the same thing.\n\n- [Search in Discussions](https://github.com/orgs/mermaid-js/discussions)\n- [Search in Issues (Open & Closed)](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue)\n\nIf you find an open issue or discussion thread that is similar to your question but isn't answered, you can let us know that you are also interested in it.\nUse the GitHub reactions to add a thumbs-up to the issue or discussion thread, or append to the issue if needed.\n\nThis helps the team know the relative interest in something and helps them set priorities and assignments.\n\n## Add a new Issue\n\nYou have not found anything that already addresses your request, or maybe you have come up with the new idea? Feel free to open a new issue or discussion.\n\nLog in to [GitHub.com](https://www.github.com), and use [GitHub issue tracker of the mermaid-js repository](https://github.com/mermaid-js/mermaid/issues). Press [issue, select the appropriate template](https://github.com/mermaid-js/mermaid/issues/new/choose) and describe your problem.\n\n\n# Security\n\nThe Mermaid team takes the security of Mermaid and the applications that use Mermaid seriously. This page describes how to report any vulnerabilities you may find, and lists best practices to minimize the risk of introducing a vulnerability.\n\n## Reporting vulnerabilities\n\nTo report a vulnerability, please e-mail  with a description of the issue, the steps you took to create the issue, affected versions, and if known, mitigations for the issue.\n\nWe aim to reply within three working days, probably much sooner.\n\nYou should expect a close collaboration as we work to resolve the issue you have reported. Please reach out to  again if you do not receive prompt attention and regular updates.\n\nYou may also reach out to the team via our public Discord chat channels; however, please make sure to e-mail  when reporting an issue, and avoid revealing information about vulnerabilities in public as that could that could put users at risk.\n\n## Best practices\n\nKeep current with the latest Mermaid releases. We regularly update Mermaid, and these updates may fix security defects discovered in previous versions. Check the Mermaid release notes for security-related updates.\n\nKeep your application’s dependencies up to date. Make sure you upgrade your package dependencies to keep the dependencies up to date. Avoid pinning to specific versions for your dependencies and, if you do, make sure you check periodically to see if your dependencies have had security updates, and update the pin accordingly.\n\n## Configuring DomPurify\n\nBy default Mermaid uses a baseline [DOMPurify](https://github.com/cure53/DOMPurify) config. It is possible to override the options passed to DOMPurify by adding a `dompurifyConfig` key to the Mermaid options. This could potentially break the output of Mermaid so use this with caution.\n\n\n# Version 8.6.0 Changes\n\n## [New Mermaid Live-Editor Beta](https://mermaid-js.github.io/docs/mermaid-live-editor-beta/#/edit/eyJjb2RlIjoiJSV7aW5pdDoge1widGhlbWVcIjogXCJmb3Jlc3RcIiwgXCJsb2dMZXZlbFwiOiAxIH19JSVcbmdyYXBoIFREXG4gIEFbQ2hyaXN0bWFzXSAtLT58R2V0IG1vbmV5fCBCKEdvIHNob3BwaW5nKVxuICBCIC0tPiBDe0xldCBtZSB0aGlua31cbiAgQyAtLT58T25lfCBEW0xhcHRvcF1cbiAgQyAtLT58VHdvfCBFW2lQaG9uZV1cbiAgQyAtLT58VGhyZWV8IEZbZmE6ZmEtY2FyIENhcl1cblx0XHQiLCJtZXJtYWlkIjp7InRoZW1lIjoiZGFyayJ9fQ)\n\n## [CDN](https://www.jsdelivr.com/package/npm/mermaid)\n\nWith version 8.6.0 comes the release of directives for mermaid, a new system for modifying configurations, with the aim of establishing centralized, sane defaults and simple implementation.\n\n`directives` allow for a single-use overwriting of `config`, as it has been discussed in [Configurations](../config/configuration.md).\nThis allows site Diagram Authors to instantiate temporary modifications to `config` through the use of [Directives](directives.md), which are parsed before rendering diagram definitions. This allows the Diagram Authors to alter the appearance of the diagrams.\n\n**A likely application for this is in the creation of diagrams/charts inside company/organizational webpages, that rely on mermaid for diagram and chart rendering.**\n\nthe `init` directive is the main method of configuration for Site and Current Levels.\n\nThe three levels of are Configuration, Global, Site and Current.\n\n| Level of Configuration | Description                         |\n| ---------------------- | ----------------------------------- |\n| Global Configuration   | Default Mermaid Configurations      |\n| Site Configuration     | Configurations made by site owner   |\n| Current Configuration  | Configurations made by Implementors |\n\n# Limits to Modifying Configurations\n\n**secure Array**\n\n| Parameter | Description                                      | Type  | Required | Values         |\n| --------- | ------------------------------------------------ | ----- | -------- | -------------- |\n| secure    | Array of parameters excluded from init directive | Array | Required | Any parameters |\n\nThe modifiable parts of the Configuration are limited by the secure array, which is an array of immutable parameters, this array can be expanded by site owners.\n\n**Notes**: secure arrays work like nesting dolls, with the Global Configurations’ secure array holding the default and immutable list of immutable parameters, or the smallest doll, to which site owners may add to, but implementors may not modify it.\n\n# Secure Arrays\n\nSite owners can add to the **secure** array using this command:\nmermaidAPI.initialize( { startOnLoad: true, secure: ['parameter1', 'parameter2'] } );\n\nDefault values for the `secure array` consists of: ['secure', 'securityLevel', 'startOnLoad', 'maxTextSize']. These default values are immutable.\n\nImplementors can only modify configurations using directives, and cannot change the `secure` array.\n\n# Modifying Configurations and directives:\n\nThe Two types of directives: are `init` (or `initialize`) and `wrap`.\n\n```note\nAll directives are enclosed in `%%{ }%%`\n```\n\nOlder versions of mermaid will not parse directives because `%%` will comment out the directive. This makes the update backwards-compatible.\n\n# Init\n\n`init`, or `initialize`: this directive gives the user the ability to overwrite and change the values for any configuration parameters not set in the secure array.\n\n| Parameter | Description             | Type      | Required | Values                                          |\n| --------- | ----------------------- | --------- | -------- | ----------------------------------------------- |\n| init      | modifies configurations | Directive | Optional | Any parameters not included in the secure array |\n\n```note\ninit would be an argument-directive: `%%{init: { **insert argument here**}}%%`\n\nThe json object that is passed as {**argument** } must be valid, quoted json or it will be ignored.\n**for example**:\n\n`%%{init: {\"theme\": \"default\", \"logLevel\": 1 }}%%`\n\nConfigurations that are passed through init cannot change the parameters in a secure array at a higher level. In the event of a collision, mermaid will give priority to secure arrays and parse the request without changing the values of those parameters in conflict.\n\nWhen deployed within code, init is called before the graph/diagram description.\n```\n\n**for example**:\n\n```mermaid-example\n%%{init: {\"theme\": \"default\", \"logLevel\": 1 }}%%\n graph LR\n  a-->b\n  b-->c\n  c-->d\n  d-->e\n  e-->f\n  f-->g\n  g-->\n```\n\n# Wrap\n\n| Parameter | Description                   | Type      | Required | Values     |\n| --------- | ----------------------------- | --------- | -------- | ---------- |\n| wrap      | a callable text-wrap function | Directive | Optional | %%{wrap}%% |\n\n```note\nWrap is a function that is currently only deployable for sequence diagrams.\n\n`Wrap respects a manually added 
, so if the user wants to break up their text, they have full control over line breaks by adding 
 tags.`\n\nIt is a non-argument directive and can be executed thusly:\n\n`%%{wrap}%%` .\n```\n\n**An example of text wrapping in a sequence diagram**:\n\n![Image showing wrapped text](img/wrapped text.png)\n\n# Resetting Configurations:\n\nThere are two more functions in the mermaidAPI that can be called by site owners: **reset** and **globalReset**.\n\n**reset**: resets the configuration to whatever the last configuration was. This can be done to undo more recent changes set from the last mermaidAPI.initialize({...}) configuration.\n\n**globalReset** will reset both the current configuration AND the site configuration back to the global defaults.\n\n**Notes**: Both `reset` and `globalReset` are only available to site owners, and as such implementors have to edit their configs using `init`.\n\n# Additional Utils to mermaid\n\n• **memoize**: simple caching for computationally expensive functions, reducing rendering time by about 90%.\n\n• **assignWithDepth** - an improvement on previous functions with config.js and `Object.assign`. The purpose of this function is to provide a sane mechanism for merging objects, similar to `object.assign`, but with depth.\n\nExample of **assignWithDepth**:\n\n![Image showing assignWithDepth](img/assignWithDepth.png)\n\nExample of **object.Assign**:\n\n![Image showing object.assign without depth](img/object.assign without depth.png)\n\n• **calculateTextDimensions**, **calculateTextWidth**， and **calculateTextHeight** - for measuring text dimensions, width and height.\n\n**Notes**: For more information on usage, parameters, and return info for these new functions take a look at the jsdocs for them in the utils package.\n\n# New API Requests Introduced in Version 8.6.0\n\n## setSiteConfig\n\n| Function        | Description                           | Type        | Values                                  | Parameters | Returns    |\n| --------------- | ------------------------------------- | ----------- | --------------------------------------- | ---------- | ---------- |\n| `setSiteConfig` | Sets the siteConfig to desired values | Put Request | Any Values, except ones in secure array | conf       | siteConfig |\n\n```note\nSets the siteConfig. The siteConfig is a protected configuration for repeat use. Calls to reset() will reset\nthe currentConfig to siteConfig. Calls to reset(configApi.defaultConfig) will reset siteConfig and currentConfig\nto the defaultConfig\nNote: currentConfig is set in this function。\nDefault value: will mirror Global Config\n```\n\n## getSiteConfig\n\n| Function        | Description                                         | Type        | Values                             |\n| --------------- | --------------------------------------------------- | ----------- | ---------------------------------- |\n| `getSiteConfig` | Returns the current `siteConfig` base configuration | Get Request | Returns Any Values in `siteConfig` |\n\n```note\nReturns any values in siteConfig.\n```\n\n## setConfig\n\n| Function    | Description                                | Type        | Values                            | Parameters | Returns                                        |\n| ----------- | ------------------------------------------ | ----------- | --------------------------------- | ---------- | ---------------------------------------------- |\n| `setConfig` | Sets the `currentConfig` to desired values | Put Request | Any Values, those in secure array | conf       | `currentConfig` merged with the sanitized conf |\n\n```note\nSets the currentConfig. The parameter conf is sanitized based on the siteConfig.secure keys. Any\nvalues found in conf with key found in siteConfig.secure will be replaced with the corresponding\nsiteConfig value.\n```\n\n## getConfig\n\n| Function    | Description                 | Type        | Return Values                   |\n| ----------- | --------------------------- | ----------- | ------------------------------- |\n| `getConfig` | Obtains the `currentConfig` | Get Request | Any Values from `currentConfig` |\n\n```note\nReturns any values in currentConfig.\n```\n\n## sanitize\n\n| Function   | Description                              | Type           | Values |\n| ---------- | ---------------------------------------- | -------------- | ------ |\n| `sanitize` | Sets the `siteConfig` to desired values. | Put Request(?) | None   |\n\n```note\nmodifies options in-place\nEnsures options parameter does not attempt to override siteConfig secure keys.\n```\n\n## reset\n\n| Function | Description                    | Type        | Required | Values | Parameter |\n| -------- | ------------------------------ | ----------- | -------- | ------ | --------- |\n| `reset`  | Resets `currentConfig` to conf | Put Request | Required | None   | conf      |\n\n## conf\n\n| Parameter | Description                                                  | Type       | Required | Values                                       |\n| --------- | ------------------------------------------------------------ | ---------- | -------- | -------------------------------------------- |\n| `conf`    | base set of values, which `currentConfig` could be reset to. | Dictionary | Required | Any Values, with respect to the secure Array |\n\n```note\ndefault: current siteConfig (optional, default `getSiteConfig()`)\n```\n\n## For more information, read [Setup](./setup/README.md).\n\n\n# Accessibility Options\n\n## Accessibility\n\nNow with Mermaid library in much wider use, we have started to work towards more accessible features, based on the feedback from the community.\n\nAdding accessibility means that the rich information communicated by visual diagrams can be made available to those using assistive technologies (and of course to search engines).\n[Read more about Accessible Rich Internet Applications and the W3 standards.](https://www.w3.org/WAI/standards-guidelines/aria/)\n\nMermaid will automatically insert the [aria-roledescription](#aria-roledescription) and, if provided in the diagram text by the diagram author, the [accessible title and description.](#accessible-title-and-description)\n\n### aria-roledescription\n\nThe [aria-roledescription](https://www.w3.org/TR/wai-aria-1.1/#aria-roledescription) for the SVG HTML element is set to the diagram type key. (Note this may be slightly different than the keyword used for the diagram in the diagram text.)\n\nFor example: The diagram type key for a state diagram is \"stateDiagram\". Here (a part of) the HTML of the SVG tag that shows the automatically inserted aria-roledescription set to \"stateDiagram\". _(Note that some of the SVG attributes and the SVG contents are omitted for clarity.):_\n\n```html\n\n```\n\n### Accessible Title and Description\n\nSupport for accessible titles and descriptions is available for all diagrams/chart types. We have tried to keep the same keywords and format for all diagrams so that it is easy to understand and maintain.\n\nThe accessible title and description will add `` and `<desc>` elements within the SVG element and the [aria-labelledby](https://www.w3.org/TR/wai-aria/#aria-labelledby) and [aria-describedby](https://www.w3.org/TR/wai-aria/#aria-describedby) attributes in the SVG tag.\n\nHere is HTML that is generated, showing that the SVG element is labelled by the accessible title (id = `chart-title-mermaid-1668725057758`)\nand described by the accessible description (id = `chart-desc-mermaid-1668725057758` );\nand the accessible title element (text = \"This is the accessible title\")\nand the accessible description element (text = \"This is an accessible description\").\n\n_(Note that some of the SVG attributes and the SVG contents are omitted for clarity.)_\n\n```html\n<svg\n  aria-labelledby=\"chart-title-mermaid-1668725057758\"\n  aria-describedby=\"chart-desc-mermaid-1668725057758\"\n  xmlns=\"http://www.w3.org/2000/svg\"\n  width=\"100%\"\n  id=\"mermaid-1668725057758\"\n>\n  <title id=\"chart-title-mermaid-1668725057758\">This is the accessible title\n  This is an accessible description\n\n```\n\nDetails for the syntax follow.\n\n#### accessible title\n\nThe **accessible title** is specified with the **accTitle** _keyword_, followed by a colon (`:`), and the string value for the title.\nThe string value ends at the end of the line. (It can only be a single line.)\n\nEx: `accTitle: This is a single line title`\n\nSee [the accTitle and accDescr usage examples](#acctitle-and-accdescr-usage-examples) for how this can be used in a diagram and the resulting HTML generated.\n\n#### accessible description\n\nAn accessible description can be 1 line long (a single line) or many lines long.\n\nThe **single line accessible description** is specified with the **accDescr** _keyword_, followed by a colon (`:`), followed by the string value for the description.\n\nEx: `accDescr: This is a single line description.`\n\nA **multiple line accessible description** _does not have a colon (`:`) after the accDescr keyword_ and is surrounded by curly brackets (`{}`).\n\nEx:\n\n```markdown\naccDescr {\nThis is a multiple line accessible description.\nIt does not have a colon and is surrounded by curly brackets.\n}\n```\n\nSee [the accTitle and accDescr usage examples](#acctitle-and-accdescr-usage-examples) for how this can be used in a diagram and the resulting HTML generated.\n\n#### accTitle and accDescr Usage Examples\n\n- Flowchart with the accessible title \"Big Decisions\" and the single-line accessible description \"Bob's Burgers process for making big decisions\"\n\n```mermaid-example\n  graph LR\n      accTitle: Big Decisions\n      accDescr: Bob's Burgers process for making big decisions\n      A[Identify Big Decision] --> B{Make Big Decision}\n      B --> D[Be done]\n```\n\nHere is the HTML generated for the SVG element: _(Note that some of the SVG attributes and the SVG contents are omitted for clarity.):_\n\n```html\n\n  Big decisions\n  Bob's Burgers process for making big decisions\n\n```\n\n- Flowchart with the accessible title \"Bob's Burger's Making Big Decisions\" and the multiple line accessible description \"The official Bob's Burgers corporate processes that are used\n  for making very, very big decisions.\n  This is actually a very simple flow: identify the big decision and then make the big decision.\"\n\n```mermaid-example\n  graph LR\n      accTitle: Bob's Burger's Making Big Decisions\n      accDescr {\n        The official Bob's Burgers corporate processes that are used\n        for making very, very big decisions.\n        This is actually a very simple flow: identify the big decision and then make the big decision.\n         }\n      A[Identify Big Decision] --> B{Make Big Decision}\n      B --> D[Be done]\n```\n\nHere is the HTML generated for the SVG element: _(Note that some of the SVG attributes and the SVG contents are omitted for clarity.):_\n\n```html\n\n  Big decisions\n  \n    The official Bob's Burgers corporate processes that are used for making very, very big\n    decisions. This is actually a very simple flow: identify the big decision and then make the big\n    decision.\n  \n\n```\n\n#### Sample Code Snippets for other diagram types\n\n##### Class Diagram\n\n```mermaid-example\n   classDiagram\n      accTitle: My Class Diagram\n      accDescr: My Class Diagram Description\n\n      Vehicle <|-- Car\n```\n\n##### Entity Relationship Diagram\n\n```mermaid-example\n   erDiagram\n      accTitle: My Entity Relationship Diagram\n      accDescr: My Entity Relationship Diagram Description\n\n    CUSTOMER ||--o{ ORDER : places\n    ORDER ||--|{ LINE-ITEM : contains\n    CUSTOMER }|..|{ DELIVERY-ADDRESS : uses\n\n```\n\n##### Gantt Chart\n\n```mermaid-example\n   gantt\n      accTitle: My Gantt Chart Accessibility Title\n      accDescr: My Gantt Chart Accessibility Description\n\n    title A Gantt Diagram\n    dateFormat  YYYY-MM-DD\n    section Section\n    A task           :a1, 2014-01-01, 30d\n    Another task     :after a1  , 20d\n    section Another\n    Task in sec      :2014-01-12  , 12d\n    another task      : 24d\n\n```\n\n##### GitGraph\n\n```mermaid-example\n  gitGraph\n      accTitle: My GitGraph Accessibility Title\n      accDescr: My GitGraph Accessibility Description\n\n     commit\n     commit\n     branch develop\n     checkout develop\n     commit\n     commit\n     checkout main\n     merge develop\n     commit\n     commit\n\n```\n\n##### Pie Chart\n\n```mermaid-example\n   pie\n      accTitle: My Pie Chart Accessibility Title\n      accDescr: My Pie Chart Accessibility Description\n\n    title Key elements in Product X\n    \"Calcium\" : 42.96\n    \"Potassium\" : 50.05\n    \"Magnesium\" : 10.01\n    \"Iron\" :  5\n\n```\n\n##### Requirement Diagram\n\n```mermaid-example\n  requirementDiagram\n      accTitle: My Requirement Diagram\n      accDescr: My Requirement Diagram Description\n\n       requirement test_req {\n  id: 1\n  text: the test text.\n  risk: high\n  verifymethod: test\n  }\n\n  element test_entity {\n  type: simulation\n  }\n\n  test_entity - satisfies -> test_req\n\n```\n\n##### Sequence Diagram\n\n```mermaid-example\n   sequenceDiagram\n      accTitle: My Sequence Diagram\n      accDescr: My Sequence Diagram Description\n\n      Alice->>John: Hello John, how are you?\n      John-->>Alice: Great!\n      Alice-)John: See you later!\n```\n\n##### State Diagram\n\n```mermaid-example\n   stateDiagram\n      accTitle: My State Diagram\n      accDescr: My State Diagram Description\n\n       s1 --> s2\n\n```\n\n##### User Journey Diagram\n\n```mermaid-example\n  journey\n      accTitle: My User Journey Diagram\n      accDescr: My User Journey Diagram Description\n\n      title My working day\n      section Go to work\n        Make tea: 5: Me\n        Go upstairs: 3: Me\n        Do work: 1: Me, Cat\n      section Go home\n        Go downstairs: 5: Me\n        Sit down: 5: Me\n\n```\n\n\n# Configuration\n\nWhen mermaid starts, configuration is extracted to determine a configuration to be used for a diagram. There are 3 sources for configuration:\n\n- The default configuration\n- Overrides at the site level are set by the initialize call, and will be applied to all diagrams in the site/app. The term for this is the **siteConfig**.\n- Frontmatter (v10.5.0+) - diagram authors can update selected configuration parameters in the frontmatter of the diagram. These are applied to the render config.\n- Directives (Deprecated by Frontmatter) - diagram authors can update selected configuration parameters directly in the diagram code via directives. These are applied to the render config.\n\n**The render config** is configuration that is used when rendering by applying these configurations.\n\n## Frontmatter config\n\nThe entire mermaid configuration (except the secure configs) can be overridden by the diagram author in the frontmatter of the diagram. The frontmatter is a YAML block at the top of the diagram.\n\n```mermaid-example\n---\ntitle: Hello Title\nconfig:\n  theme: base\n  themeVariables:\n    primaryColor: \"#00ff00\"\n---\nflowchart\n\tHello --> World\n\n```\n\n## Theme configuration\n\n## Starting mermaid\n\n```mermaid\nsequenceDiagram\n\tSite->>mermaid: initialize\n\tSite->>mermaid: content loaded\n\tmermaid->>mermaidAPI: init\n```\n\n## Initialize\n\nThe initialize call is applied **only once**. It is called by the site integrator in order to override the default configuration at a site level.\n\n## configApi.reset\n\nThis method resets the configuration for a diagram to the overall site configuration, which is the configuration provided by the site integrator. Before each rendering of a diagram, reset is called at the very beginning.\n\n\n# Directives\n\n```warning\nDirectives are deprecated from v10.5.0. Please use the `config` key in frontmatter to pass configuration. See [Configuration](./configuration.md) for more details.\n```\n\n## Directives\n\nDirectives give a diagram author the capability to alter the appearance of a diagram before rendering by changing the applied configuration.\n\nThe significance of having directives is that you have them available while writing the diagram, and can modify the default global and diagram-specific configurations. So, directives are applied on top of the default configuration. The beauty of directives is that you can use them to alter configuration settings for a specific diagram, i.e. at an individual level.\n\nWhile directives allow you to change most of the default configuration settings, there are some that are not available, for security reasons. Also, you have the _option to define the set of configurations_ that you wish to allow diagram authors to override with directives.\n\n## Types of Directives options\n\nMermaid basically supports two types of configuration options to be overridden by directives.\n\n1. _General/Top Level configurations_ : These are the configurations that are available and applied to all the diagram. **Some of the most important top-level** configurations are:\n   - theme\n   - fontFamily\n   - logLevel\n   - securityLevel\n   - startOnLoad\n   - secure\n\n2. _Diagram-specific configurations_ : These are the configurations that are available and applied to a specific diagram. For each diagram there are specific configuration that will alter how that particular diagram looks and behaves.\n   For example, `mirrorActors` is a configuration that is specific to the `SequenceDiagram` and alters whether the actors are mirrored or not. So this config is available only for the `SequenceDiagram` type.\n\n**NOTE:** Not all configuration options are listed here. To get hold of all the configuration options, please refer to the [defaultConfig.ts](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/defaultConfig.ts) in the source code.\n\n```note\nWe plan to publish a complete list of top-level configurations & diagram-specific configurations with their possible values in the docs soon.\n```\n\n## Declaring directives\n\nNow that we have defined the types of configurations that are available, we can learn how to declare directives.\nA directive always starts and ends with `%%` signs with directive text in between, like `%% {directive_text} %%`.\n\nHere the structure of a directive text is like a nested key-value pair map or a JSON object with root being _init_. Where all the general configurations are defined in the top level, and all the diagram specific configurations are defined one level deeper with diagram type as key/root for that section.\n\nThe following code snippet shows the structure of a directive:\n\n```\n%%{\n  init: {\n    \"theme\": \"dark\",\n    \"fontFamily\": \"monospace\",\n    \"logLevel\": \"info\",\n    \"htmlLabels\": true,\n    \"flowchart\": {\n      \"curve\": \"linear\"\n    },\n    \"sequence\": {\n      \"mirrorActors\": true\n    }\n  }\n}%%\n```\n\nYou can also define the directives in a single line, like this:\n\n```\n%%{init: { **insert configuration options here** } }%%\n```\n\nFor example, the following code snippet:\n\n```\n%%{init: { \"sequence\": { \"mirrorActors\":false }}}%%\n```\n\n**Notes:**\nThe JSON object that is passed as {**argument**} must be valid key value pairs and encased in quotation marks or it will be ignored.\nValid Key Value pairs can be found in config.\n\nExample with a simple graph:\n\n```mermaid-example\n%%{init: { 'logLevel': 'debug', 'theme': 'dark' } }%%\ngraph LR\nA-->B\n```\n\nHere the directive declaration will set the `logLevel` to `debug` and the `theme` to `dark` for a rendered mermaid diagram, changing the appearance of the diagram itself.\n\nNote: You can use 'init' or 'initialize' as both are acceptable as init directives. Also note that `%%init%%` and `%%initialize%%` directives will be grouped together after they are parsed.\n\n```mermaid-example\n%%{init: { 'logLevel': 'debug', 'theme': 'forest' } }%%\n%%{initialize: { 'logLevel': 'fatal', \"theme\":'dark', 'startOnLoad': true } }%%\n...\n```\n\nFor example, parsing the above generates a single `%%init%%` JSON object below, combining the two directives and carrying over the last value given for `loglevel`:\n\n```json\n{\n  \"logLevel\": \"fatal\",\n  \"theme\": \"dark\",\n  \"startOnLoad\": true\n}\n```\n\nThis will then be sent to `mermaid.initialize(...)` for rendering.\n\n## Directive Examples\n\nNow that the concept of directives has been explained, let us see some more examples of directive usage:\n\n### Changing theme via directive\n\nThe following code snippet changes `theme` to `forest`:\n\n`%%{init: { \"theme\": \"forest\" } }%%`\n\nPossible theme values are: `default`, `base`, `dark`, `forest` and `neutral`.\nDefault Value is `default`.\n\nExample:\n\n```mermaid-example\n%%{init: { \"theme\": \"forest\" } }%%\ngraph TD\nA(Forest) --> B[/Another/]\nA --> C[End]\n  subgraph section\n  B\n  C\n  end\n\n```\n\n### Changing fontFamily via directive\n\nThe following code snippet changes fontFamily to Trebuchet MS, Verdana, Arial, Sans-Serif:\n\n`%%{init: { \"fontFamily\": \"Trebuchet MS, Verdana, Arial, Sans-Serif\" } }%%`\n\nExample:\n\n```mermaid-example\n%%{init: { \"fontFamily\": \"Trebuchet MS, Verdana, Arial, Sans-Serif\" } }%%\ngraph TD\nA(Forest) --> B[/Another/]\nA --> C[End]\n  subgraph section\n  B\n  C\n  end\n\n```\n\n### Changing logLevel via directive\n\nThe following code snippet changes `logLevel` to `2`:\n\n`%%{init: { \"logLevel\": 2 } }%%`\n\nPossible `logLevel` values are:\n\n- `1` for _debug_,\n- `2` for _info_\n- `3` for _warn_\n- `4` for _error_\n- `5` for _only fatal errors_\n\nDefault Value is `5`.\n\nExample:\n\n```mermaid-example\n%%{init: { \"logLevel\": 2 } }%%\ngraph TD\nA(Forest) --> B[/Another/]\nA --> C[End]\n  subgraph section\n  B\n  C\n  end\n```\n\n### Changing flowchart config via directive\n\nSome common flowchart configurations are:\n\n- ~~_htmlLabels_~~: Deprecated, [prefer setting this at the root level](/config/schema-docs/config#htmllabels).\n- _curve_: linear/curve\n- _diagramPadding_: number\n- _useMaxWidth_: number\n\nFor a complete list of flowchart configurations, see [defaultConfig.ts](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/defaultConfig.ts) in the source code.\n_Soon we plan to publish a complete list of all diagram-specific configurations updated in the docs._\n\nThe following code snippet changes flowchart config:\n\n```\n%%{init: { \"htmlLabels\": true, \"flowchart\": { \"curve\": \"linear\" } } }%%\n```\n\nHere we are overriding only the flowchart config, and not the general config, setting `htmlLabels` to `true` and `curve` to `linear`.\n\n```warning\n**Deprecated:** `flowchart.htmlLabels` has been deprecated from (v11.12.3+). Use the global `htmlLabels` configuration instead. For example, instead of `\"flowchart\": { \"htmlLabels\": true }`, use `\"htmlLabels\": true` at the top level.\n```\n\n```mermaid-example\n%%{init: { \"flowchart\": { \"htmlLabels\": true, \"curve\": \"linear\" } } }%%\ngraph TD\nA(Forest) --> B[/Another/]\nA --> C[End]\n  subgraph section\n  B\n  C\n  end\n```\n\n### Changing Sequence diagram config via directive\n\nSome common sequence diagram configurations are:\n\n- _width_: number\n- _height_: number\n- _messageAlign_: left, center, right\n- _mirrorActors_: boolean\n- _useMaxWidth_: boolean\n- _rightAngles_: boolean\n- _showSequenceNumbers_: boolean\n- _wrap_: boolean\n\nFor a complete list of sequence diagram configurations, see [defaultConfig.ts](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/defaultConfig.ts) in the source code.\n_Soon we plan to publish a complete list of all diagram-specific configurations updated in the docs._\n\nSo, `wrap` by default has a value of `false` for sequence diagrams.\n\nLet us see an example:\n\n```mermaid-example\nsequenceDiagram\n\nAlice->Bob: Hello Bob, how are you?\nBob->Alice: Fine, how did your mother like the book I suggested? And did you catch the new book about alien invasion?\nAlice->Bob: Good.\nBob->Alice: Cool\n```\n\nNow let us enable wrap for sequence diagrams.\n\nThe following code snippet changes sequence diagram config for `wrap` to `true`:\n\n`%%{init: { \"sequence\": { \"wrap\": true} } }%%`\n\nBy applying that snippet to the diagram above, `wrap` will be enabled:\n\n```mermaid-example\n%%{init: { \"sequence\": { \"wrap\": true, \"width\":300 } } }%%\nsequenceDiagram\nAlice->Bob: Hello Bob, how are you?\nBob->Alice: Fine, how did your mother like the book I suggested? And did you catch the new book about alien invasion?\nAlice->Bob: Good.\nBob->Alice: Cool\n```\n\n\n# Frequently Asked Questions\n\n1. [How to add title to flowchart?](https://github.com/mermaid-js/mermaid/issues/1433#issuecomment-1991554712)\n1. [How to specify custom CSS file?](https://github.com/mermaidjs/mermaid.cli/pull/24#issuecomment-373402785)\n1. [How to fix tooltip misplacement issue?](https://github.com/mermaid-js/mermaid/issues/542#issuecomment-3343564621)\n1. [How to specify gantt diagram xAxis format?](https://github.com/mermaid-js/mermaid/issues/269#issuecomment-373229136)\n1. [How to bind an event?](https://github.com/mermaid-js/mermaid/issues/372)\n1. [How to add newline in the text?](https://github.com/mermaid-js/mermaid/issues/384#issuecomment-281339381)\n1. [How to have special characters in link text?](https://github.com/mermaid-js/mermaid/issues/407#issuecomment-329944735)\n1. [How to change Flowchart curve style?](https://github.com/mermaid-js/mermaid/issues/580#issuecomment-373929046)\n1. [How to create a Flowchart end-Node that says \"End\"](https://github.com/mermaid-js/mermaid/issues/1444#issuecomment-639528897)\n\n\n# Registering icon pack in mermaid\n\nThe icon packs available can be found at [icones.js.org](https://icones.js.org/).\nWe use the name defined when registering the icon pack, to override the prefix field of the iconify pack. This allows the user to use shorter names for the icons. It also allows us to load a particular pack only when it is used in a diagram.\n\nUsing JSON file directly from CDN:\n\n```js\nimport mermaid from 'CDN/mermaid.esm.mjs';\nmermaid.registerIconPacks([\n  {\n    name: 'logos',\n    loader: () =>\n      fetch('https://unpkg.com/@iconify-json/logos@1/icons.json').then((res) => res.json()),\n  },\n]);\n```\n\nUsing packages and a bundler:\n\n```bash\nnpm install @iconify-json/logos@1\n```\n\nWith lazy loading\n\n```js\nimport mermaid from 'mermaid';\n\nmermaid.registerIconPacks([\n  {\n    name: 'logos',\n    loader: () => import('@iconify-json/logos').then((module) => module.icons),\n  },\n]);\n```\n\nWithout lazy loading\n\n```js\nimport mermaid from 'mermaid';\nimport { icons } from '@iconify-json/logos';\nmermaid.registerIconPacks([\n  {\n    name: icons.prefix, // To use the prefix defined in the icon pack\n    icons,\n  },\n]);\n```\n\n\n# Layouts\n\nThis page lists the available layout algorithms supported in Mermaid diagrams.\n\n## ELK is bundled and default from v12.0.0\n\nBefore v12.0.0, ELK shipped as a separate `@mermaid-js/layout-elk` package that\neach site had to install and register. It is now part of `mermaid` itself and\nregistered automatically, so `layout: elk` works with no setup — and it is the\n**default**, replacing Dagre.\n\n`elk` is the new default layout for these diagrams:\n\n- Flowchart\n- State\n- Class\n- Entity relationship\n- Requirement\n- Use case\n- Agentflow\n\nTo go back to the previous layout, use `layout: dagre`.\n\nThe main `mermaid` package always includes ELK. If you want Mermaid without it,\nuse the [tiny build](./usage.md#elk-and-the-tiny-build), which omits ELK along\nwith some diagram types. `@mermaid-js/layout-elk` is still published so the tiny\nbuild can opt back in.\n\n## Supported Layouts\n\n- **elk** (default): [ELK (Eclipse Layout Kernel)](https://www.eclipse.org/elk/). Bundled with Mermaid; no setup required. Specific ELK algorithms can be selected as `elk.stress`, `elk.force`, `elk.mrtree`, `elk.sporeOverlap`, `elk.box`, and `elk.rectpacking`.\n- **dagre**: Dagre layout for layered graphs\n- **cose-bilkent**: Cose Bilkent layout for force-directed graphs\n- **tidy-tree**: Tidy tree layout for hierarchical diagrams, from the [`@mermaid-js/layout-tidy-tree`](https://www.npmjs.com/package/@mermaid-js/layout-tidy-tree) package [Tidy Tree Configuration](/config/tidy-tree)\n\nMindmaps are the one diagram type not laid out with ELK by default; they use\ncose-bilkent unless you ask for something else.\n\nThe **tiny** build omits ELK to stay small, and falls back to Dagre for\ndiagrams that request it. See\n[ELK and the tiny build](./usage.md#elk-and-the-tiny-build) for how to register\n`@mermaid-js/layout-elk` there if you want ELK anyway.\n\n## How to Use\n\nSince `elk` is the default, a diagram needs no configuration to use it. To pick\na different layout, set it in your diagram's YAML config or initialization\noptions. For example:\n\n```mermaid\n---\nconfig:\n  layout: dagre\n---\ngraph TD;\n  A-->B;\n  B-->C;\n```\n\n\n# Math Configuration (v10.9.0+)\n\nMermaid supports rendering mathematical expressions through the [KaTeX](https://katex.org/) typesetter.\n\n## Usage\n\nTo render math within a diagram, surround the mathematical expression with the `$$` delimiter.\n\nNote that at the moment, the only supported diagrams are below:\n\n### Flowcharts\n\n```mermaid-example\n graph LR\n      A[\"$$x^2$$\"] -->|\"$$\\sqrt{x+3}$$\"| B(\"$$\\frac{1}{2}$$\")\n      A -->|\"$$\\overbrace{a+b+c}^{\\text{note}}$$\"| C(\"$$\\pi r^2$$\")\n      B --> D(\"$$x = \\begin{cases} a &\\text{if } b \\\\ c &\\text{if } d \\end{cases}$$\")\n      C --> E(\"$$x(t)=c_1\\begin{bmatrix}-\\cos{t}+\\sin{t}\\\\ 2\\cos{t} \\end{bmatrix}e^{2t}$$\")\n```\n\n### Sequence\n\n```mermaid-example\nsequenceDiagram\n    autonumber\n    participant 1 as $$\\alpha$$\n    participant 2 as $$\\beta$$\n    1->>2: Solve: $$\\sqrt{2+2}$$\n    2-->>1: Answer: $$2$$\n    Note right of 2: $$\\sqrt{2+2}=\\sqrt{4}=2$$\n```\n\n## Legacy Support\n\nBy default, MathML is used for rendering mathematical expressions. If you have users on [unsupported browsers](https://caniuse.com/?search=mathml), `legacyMathML` can be set in the config to fall back to CSS rendering. Note that **you must provide KaTeX's stylesheets on your own** as they do not come bundled with Mermaid.\n\nExample with legacy mode enabled (the latest version of KaTeX's stylesheet can be found on their [docs](https://katex.org/docs/browser.html)):\n\n```html\n\n\n\n  \n    \n    \n  \n\n  \n    \n  \n\n```\n\n## Handling Rendering Differences\n\nDue to differences between default fonts across operating systems and browser's MathML implementations, inconsistent results can be seen across platforms. If having consistent results are important, or the most optimal rendered results are desired, `forceLegacyMathML` can be enabled in the config.\n\nThis option will always use KaTeX's stylesheet instead of only when MathML is not supported (as with `legacyMathML`). Note that only `forceLegacyMathML` needs to be set.\n\nIf including KaTeX's stylesheet is not a concern, enabling this option is recommended to avoid scenarios where no MathML implementation within a browser provides the desired output (as seen below).\n\n![Image showing differences between Browsers](img/mathMLDifferences.png)\n\n\n# mermaid CLI\n\nmermaid CLI has been moved to [mermaid-cli](https://github.com/mermaid-js/mermaid-cli). Please read its documentation instead.\n\n\n# Theme Configuration\n\nDynamic and integrated theme configuration was introduced in Mermaid version 8.7.0.\n\nThemes can now be customized at the site-wide level, or on individual Mermaid diagrams. For site-wide theme customization, the `initialize` call is used. For diagram specific customization, frontmatter config is used.\n\n## Available Themes\n\n1.  [**redux-color**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-redux-color.js) - The default theme for the diagram types listed under [Per-diagram defaults](#per-diagram-defaults). It pairs the `redux` geometry and typography with a categorical colour palette, so entities, actors, branches, classes, subgraph containers and chart series each get their own colour.\n\n2.  [**redux-dark-color**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-redux-dark-color.js) - The dark counterpart of `redux-color`.\n\n3.  [**redux**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-redux.js) - The same geometry and typography as `redux-color`, but monochrome. Use this when you want the colour to carry meaning you assign yourself rather than being cycled per item.\n\n4.  [**redux-dark**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-redux-dark.js) - The dark counterpart of `redux`.\n\n5.  [**default**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-default.js) - The long-standing Mermaid look, and still the default for every diagram type not listed under [Per-diagram defaults](#per-diagram-defaults).\n\n6.  [**neutral**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-neutral.js) - This theme is great for black-and-white documents that will be printed.\n\n7.  [**dark**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-dark.js) - This theme goes well with dark-colored elements or dark-mode. To use the dark theme (which changes the theme of the schema itself) with dark-mode (which sets the background), set `darkMode` to `true` in your config.\n\n8.  [**forest**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-forest.js) - This theme contains shades of green.\n\n9.  [**neo**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-neo.js) - A flatter, softer look, intended to be paired with `look: neo`.\n\n10. [**neo-dark**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-neo-dark.js) - The dark counterpart of `neo`.\n\n11. [**base**](https://github.com/mermaid-js/mermaid/blob/develop/packages/mermaid/src/themes/theme-base.js) - This is the only theme that can be modified. Use this theme as the base for customizations.\n\n## Per-diagram defaults\n\nNot every diagram type defaults to the same theme and look. Since v12.0.0\nthese do, to the `redux-color` theme and the `neo` look. The name on the left is the **config key** — what you write to\nscope a setting to that diagram, which is not always the keyword the diagram starts with:\n\n| Config key    | Diagram              |\n| ------------- | -------------------- |\n| `agentflow`   | `agentflow-beta`     |\n| `flowchart`   | `flowchart`          |\n| `swimlane`    | `swimlane-beta`      |\n| `class`       | `classDiagram`       |\n| `er`          | `erDiagram`          |\n| `requirement` | `requirementDiagram` |\n| `sequence`    | `sequenceDiagram`    |\n| `state`       | `stateDiagram`       |\n| `usecase`     | `usecase-beta`       |\n| `venn`        | `venn-beta`          |\n\nEvery other diagram type defaults to the `default` theme and the `classic` look.\n\n`layout` works the same way. Only `swimlane` overrides it, to `swimlane`; everything else\nuses the global default, `dagre`.\n\nThese are only defaults, and the most specific thing you say wins. Highest priority first:\n\n1.  The diagram's own frontmatter or `%%{init}%%` directive.\n2.  What you passed to `mermaid.initialize()`.\n3.  The diagram type's default, above.\n4.  The global default (`theme: default`, `look: classic`, `layout: dagre`).\n\nA layout that is not registered in the running build falls back to `dagre`, with a warning\nin the console. `elk` ships as a separate package you register yourself, and `cose-bilkent`\nis only bundled into builds that include the large features, so naming either as a default\ndoes not require every build to carry it.\n\nWithin each of the first two you can also scope a value to one diagram type, and the\nscoped value wins over the global one you set alongside it. `theme`, `look` and `layout`\ncan all be set this way:\n\n```javascript\nmermaid.initialize({\n  look: 'classic', // everything is classic...\n  flowchart: { look: 'handDrawn' }, // ...except flowcharts\n  er: { theme: 'neutral' },\n});\n```\n\nThe same works in frontmatter, for one diagram:\n\n```yaml\n---\nconfig:\n  flowchart:\n    look: handDrawn\n---\n```\n\n### Going back to the previous appearance\n\nThe nine types above changed appearance when these became their defaults. To draw one the\nway Mermaid drew it before, name the previous theme and look in its front matter:\n\n```yaml\n---\nconfig:\n  theme: default\n  look: classic\n---\n```\n\nFor every diagram on a page, pass the same two keys to `mermaid.initialize()`:\n\n```javascript\nmermaid.initialize({ theme: 'default', look: 'classic' });\n```\n\n## Site-wide Theme\n\nTo customize themes site-wide, call the `initialize` method on the `mermaid`.\n\nExample of `initialize` call setting `theme` to `base`:\n\n```javascript\nmermaid.initialize({\n  securityLevel: 'loose',\n  theme: 'base',\n});\n```\n\n## Diagram-specific Themes\n\nTo customize the theme of an individual diagram, use frontmatter config.\n\nExample of frontmatter config setting the `theme` to `forest`:\n\n```mermaid-example\n---\nconfig:\n  theme: 'forest'\n---\n  graph TD\n    a --> b\n```\n\n> **Reminder**: the only theme that can be customized is the `base` theme. The following section covers how to use `themeVariables` for customizations.\n\n## Customizing Themes with `themeVariables`\n\nTo make a custom theme, modify `themeVariables` via frontmatter config.\n\nYou will need to use the [base](#available-themes) theme as it is the only modifiable theme.\n\n| Parameter      | Description                        | Type   | Properties                                                                          |\n| -------------- | ---------------------------------- | ------ | ----------------------------------------------------------------------------------- |\n| themeVariables | Modifiable with frontmatter config | Object | `primaryColor`, `primaryTextColor`, `lineColor` ([see full list](#theme-variables)) |\n\nExample of modifying `themeVariables` using frontmatter config:\n\n```mermaid-example\n---\nconfig:\n  theme: 'base'\n  themeVariables:\n    primaryColor: '#BB2528'\n    primaryTextColor: '#fff'\n    primaryBorderColor: '#7C0000'\n    lineColor: '#F8B229'\n    secondaryColor: '#006100'\n    tertiaryColor: '#fff'\n---\n        graph TD\n          A[Christmas] -->|Get money| B(Go shopping)\n          B --> C{Let me think}\n          B --> G[/Another/]\n          C ==>|One| D[Laptop]\n          C -->|Two| E[iPhone]\n          C -->|Three| F[fa:fa-car Car]\n          subgraph section\n            C\n            D\n            E\n            F\n            G\n          end\n```\n\n## Color and Color Calculation\n\nTo ensure diagram readability, the default value of certain variables is calculated or derived from other variables. For example, `primaryBorderColor` is derived from the `primaryColor` variable. So if the `primaryColor` variable is customized, Mermaid will adjust `primaryBorderColor` automatically. Adjustments can mean a color inversion, a hue change, a darkening/lightening by 10%, etc.\n\nThe theming engine will only recognize hex colors and not color names. So, the value `#ff0000` will work, but `red` will not.\n\n## Theme Variables\n\n| Variable             | Default value                      | Description                                                                                                                      |\n| -------------------- | ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |\n| darkMode             | false                              | Affects how derived colors are calculated. Set value to `true` for dark mode.                                                    |\n| background           | #f4f4f4                            | Used to calculate color for items that should either be background colored or contrasting to the background                      |\n| fontFamily           | trebuchet ms, verdana, arial       | Font family for diagram text                                                                                                     |\n| fontSize             | 16px                               | Font size in pixels                                                                                                              |\n| primaryColor         | #fff4dd                            | Color to be used as background in nodes, other colors will be derived from this                                                  |\n| primaryTextColor     | calculated from darkMode #ddd/#333 | Color to be used as text color in nodes using `primaryColor`                                                                     |\n| secondaryColor       | calculated from primaryColor       |                                                                                                                                  |\n| primaryBorderColor   | calculated from primaryColor       | Color to be used as border in nodes using `primaryColor`                                                                         |\n| secondaryBorderColor | calculated from secondaryColor     | Color to be used as border in nodes using `secondaryColor`                                                                       |\n| secondaryTextColor   | calculated from secondaryColor     | Color to be used as text color in nodes using `secondaryColor`                                                                   |\n| tertiaryColor        | calculated from primaryColor       |                                                                                                                                  |\n| tertiaryBorderColor  | calculated from tertiaryColor      | Color to be used as border in nodes using `tertiaryColor`                                                                        |\n| tertiaryTextColor    | calculated from tertiaryColor      | Color to be used as text color in nodes using `tertiaryColor`                                                                    |\n| noteBkgColor         | #fff5ad                            | Color used as background in notes                                                                                                |\n| noteTextColor        | #333                               | Text color in note rectangles                                                                                                    |\n| noteBorderColor      | calculated from noteBkgColor       | Border color in note rectangles                                                                                                  |\n| lineColor            | calculated from background         |                                                                                                                                  |\n| textColor            | calculated from primaryTextColor   | Text in diagram over the background for instance text on labels and on signals in sequence diagram or the title in Gantt diagram |\n| mainBkg              | calculated from primaryColor       | Background in flowchart objects like rects/circles, class diagram classes, sequence diagram etc                                  |\n| errorBkgColor        | tertiaryColor                      | Color for syntax error message                                                                                                   |\n| errorTextColor       | tertiaryTextColor                  | Color for syntax error message                                                                                                   |\n\n## Flowchart Variables\n\n| Variable            | Default value                  | Description                 |\n| ------------------- | ------------------------------ | --------------------------- |\n| nodeBorder          | primaryBorderColor             | Node Border Color           |\n| clusterBkg          | tertiaryColor                  | Background in subgraphs     |\n| clusterBorder       | tertiaryBorderColor            | Cluster Border Color        |\n| defaultLinkColor    | lineColor                      | Link Color                  |\n| titleColor          | tertiaryTextColor              | Title Color                 |\n| edgeLabelBackground | calculated from secondaryColor |                             |\n| nodeTextColor       | primaryTextColor               | Color for text inside Nodes |\n\n## Sequence Diagram Variables\n\n| Variable              | Default value                  | Description                 |\n| --------------------- | ------------------------------ | --------------------------- |\n| actorBkg              | mainBkg                        | Actor Background Color      |\n| actorBorder           | primaryBorderColor             | Actor Border Color          |\n| actorTextColor        | primaryTextColor               | Actor Text Color            |\n| actorLineColor        | actorBorder                    | Actor Line Color            |\n| signalColor           | textColor                      | Signal Color                |\n| signalTextColor       | textColor                      | Signal Text Color           |\n| labelBoxBkgColor      | actorBkg                       | Label Box Background Color  |\n| labelBoxBorderColor   | actorBorder                    | Label Box Border Color      |\n| labelTextColor        | actorTextColor                 | Label Text Color            |\n| loopTextColor         | actorTextColor                 | Loop Text Color             |\n| activationBorderColor | calculated from secondaryColor | Activation Border Color     |\n| activationBkgColor    | secondaryColor                 | Activation Background Color |\n| sequenceNumberColor   | calculated from lineColor      | Sequence Number Color       |\n\n## Pie Diagram Variables\n\n| Variable            | Default value                  | Description                                |\n| ------------------- | ------------------------------ | ------------------------------------------ |\n| pie1                | primaryColor                   | Fill for 1st section in pie diagram        |\n| pie2                | secondaryColor                 | Fill for 2nd section in pie diagram        |\n| pie3                | calculated from tertiary       | Fill for 3rd section in pie diagram        |\n| pie4                | calculated from primaryColor   | Fill for 4th section in pie diagram        |\n| pie5                | calculated from secondaryColor | Fill for 5th section in pie diagram        |\n| pie6                | calculated from tertiaryColor  | Fill for 6th section in pie diagram        |\n| pie7                | calculated from primaryColor   | Fill for 7th section in pie diagram        |\n| pie8                | calculated from primaryColor   | Fill for 8th section in pie diagram        |\n| pie9                | calculated from primaryColor   | Fill for 9th section in pie diagram        |\n| pie10               | calculated from primaryColor   | Fill for 10th section in pie diagram       |\n| pie11               | calculated from primaryColor   | Fill for 11th section in pie diagram       |\n| pie12               | calculated from primaryColor   | Fill for 12th section in pie diagram       |\n| pieTitleTextSize    | 25px                           | Title text size                            |\n| pieTitleTextColor   | taskTextDarkColor              | Title text color                           |\n| pieSectionTextSize  | 17px                           | Text size of individual section labels     |\n| pieSectionTextColor | textColor                      | Text color of individual section labels    |\n| pieLegendTextSize   | 17px                           | Text size of labels in diagram legend      |\n| pieLegendTextColor  | taskTextDarkColor              | Text color of labels in diagram legend     |\n| pieStrokeColor      | black                          | Border color of individual pie sections    |\n| pieStrokeWidth      | 2px                            | Border width of individual pie sections    |\n| pieOuterStrokeWidth | 2px                            | Border width of pie diagram's outer circle |\n| pieOuterStrokeColor | black                          | Border color of pie diagram's outer circle |\n| pieOpacity          | 0.7                            | Opacity of individual pie sections         |\n\n## State Colors\n\n| Variable      | Default value    | Description                                  |\n| ------------- | ---------------- | -------------------------------------------- |\n| labelColor    | primaryTextColor |                                              |\n| altBackground | tertiaryColor    | Used for background in deep composite states |\n\n## Class Colors\n\n| Variable  | Default value | Description                     |\n| --------- | ------------- | ------------------------------- |\n| classText | textColor     | Color of Text in class diagrams |\n\n## User Journey Colors\n\n| Variable  | Default value                  | Description                             |\n| --------- | ------------------------------ | --------------------------------------- |\n| fillType0 | primaryColor                   | Fill for 1st section in journey diagram |\n| fillType1 | secondaryColor                 | Fill for 2nd section in journey diagram |\n| fillType2 | calculated from primaryColor   | Fill for 3rd section in journey diagram |\n| fillType3 | calculated from secondaryColor | Fill for 4th section in journey diagram |\n| fillType4 | calculated from primaryColor   | Fill for 5th section in journey diagram |\n| fillType5 | calculated from secondaryColor | Fill for 6th section in journey diagram |\n| fillType6 | calculated from primaryColor   | Fill for 7th section in journey diagram |\n| fillType7 | calculated from secondaryColor | Fill for 8th section in journey diagram |\n\n\n# Tidy-tree Layout\n\nThe **tidy-tree** layout arranges nodes in a hierarchical, tree-like structure. It is especially useful for diagrams where parent-child relationships are important, such as mindmaps.\n\n## Features\n\n- Organizes nodes in a tidy, non-overlapping tree\n- Ideal for mindmaps and hierarchical data\n- Automatically adjusts spacing for readability\n\n## Example Usage\n\n```mermaid-example\n---\nconfig:\n  layout: tidy-tree\n---\nmindmap\nroot((mindmap is a long thing))\n  A\n  B\n  C\n  D\n```\n\n```mermaid-example\n---\nconfig:\n  layout: tidy-tree\n---\nmindmap\nroot((mindmap))\n    Origins\n      Long history\n      ::icon(fa fa-book)\n      Popularisation\n        British popular psychology author Tony Buzan\n    Research\n      On effectiveness
and features\n      On Automatic creation\n        Uses\n            Creative techniques\n            Strategic planning\n            Argument mapping\n```\n\n## Note\n\n- Currently, tidy-tree is primarily supported for mindmap diagrams.\n\n\n# Usage\n\nMermaid is a JavaScript tool that makes use of a Markdown based syntax to render customizable diagrams, charts and visualizations.\n\nDiagrams can be re-rendered/modified by modifying their descriptions.\n\n### CDN\n\n[https://www.jsdelivr.com/package/npm/mermaid](https://www.jsdelivr.com/package/npm/mermaid)\n\nPlease note that you can switch versions through the dropdown box at the top right.\n\n## Using mermaid\n\nFor the majority of users, Using the [Live Editor](https://mermaid.live/) would be sufficient, however you may also opt to deploy mermaid as a dependency or using the [Mermaid API](./setup/README.md).\n\nWe have compiled some Video [Tutorials](../ecosystem/tutorials.md) on how to use the Mermaid Live Editor.\n\n### Installing and Hosting Mermaid on a Webpage\n\n**Using the npm package:**\n\nRequirements:\n\n- Node.js >= 22.12.0\n\n### Supported browsers and runtimes\n\nMermaid v12.0.0+'s published bundles target ES2024 and are aimed to support Safari 17.4 or later.\n\nWe run linting for Chromium 121 and Firefox 123 support as well, but unlike Safari 17.4, we don't commit to supporting these outdated versions.\n\nOlder browsers may work too, or you may need to polyfill/transpile mermaid to support them.\n\n```bash\n# NPM\nnpm install mermaid\n# Yarn\nyarn add mermaid\n# PNPM\npnpm add mermaid\n```\n\n**Hosting mermaid on a web page:**\n\n> Note: This topic is explored in greater depth in the [User Guide for Beginners](../intro/getting-started.md)\n\nThe easiest way to integrate mermaid on a web page requires two elements:\n\n- A graph definition, inside `
` tags labeled `class=mermaid`.\n\nExample:\n\n```html\n
\n    graph LR\n    A --- B\n    B-->C[fa:fa-ban forbidden]\n    B-->D(fa:fa-spinner);\n
\n```\n\n- The mermaid js script. Added using a `script` tag as an ESM import.\n\nExample:\n\n```html\n\n```\n\n**Following these directions, mermaid starts at page load and (when the page has loaded) it will locate the graph definitions inside the `pre` tags with `class=\"mermaid\"` and return diagrams in SVG form, following given definitions.**\n\n### Fonts\n\nMermaid currently uses a few different default `fontFamily` settings, based on\nthe diagram type and the given theme.\n\nThe current preferred fonts are:\n\n- Recursive Variable (open-source font, since v11.15.0)\n- Open Sans (open-source font)\n- Arial ([Restrictive License](https://en.wikipedia.org/wiki/TrueType_core_fonts_for_the_Web))\n- Trebuchet MS ([Restrictive License](https://en.wikipedia.org/wiki/TrueType_core_fonts_for_the_Web))\n\nFor a consistent look, we recommend you supply these as web fonts, when possible,\ne.g. like:\n\n```html\n/@fontsource/open-sans@5/400.css\" />\n/@fontsource/open-sans@5/400-italic.css\" />\n/@fontsource-variable/recursive@5/index.css\" />\n```\n\n## Simple full example:\n\n```html\n\n\n  /@fontsource/open-sans@5/400.css\" />\n  /@fontsource/open-sans@5/400-italic.css\" />\n  /@fontsource-variable/recursive@5/index.css\" />\n\n\n  \n    
\n  graph LR\n      A --- B\n      B-->C[fa:fa-ban forbidden]\n      B-->D(fa:fa-spinner);\n    
\n    \n  \n\n```\n\n## Notes:\n\nAn id attribute is also added to mermaid tags without one.\n\nMermaid can load multiple diagrams, in the same page.\n\n> Try it out, save this code as HTML and load it using any browser.\n> (Except Internet Explorer, please don't use Internet Explorer.)\n\n## Tiny Mermaid\n\nWe offer a smaller version of Mermaid that's approximately half the size of the full library. This tiny version doesn't include Mindmap Diagrams, Architecture Diagrams, KaTeX rendering, lazy loading, or the ELK layout engine.\n\nIf you need a more lightweight version without these features, you can use [Mermaid Tiny](https://github.com/mermaid-js/mermaid/tree/develop/packages/tiny).\n\n### ELK and the tiny build\n\nThe tiny build has never included ELK, and still doesn't — it is a large dependency and staying small is the point of that build. Diagrams that ask for an ELK layout here fall back to Dagre and still render; nothing breaks, they are simply laid out by Dagre.\n\nWhat changed in v12.0.0 is the main package, not this one: ELK used to be an opt-in `@mermaid-js/layout-elk` install, and is now bundled with `mermaid` and used by default. So **if you want a Mermaid without ELK, the tiny build is the way to get one** — it is no longer simply a matter of not installing the layout package.\n\nIf you want the tiny build _and_ ELK, register `@mermaid-js/layout-elk` alongside it. That package continues to be published for exactly this case:\n\n```html\n\n\n```\n\nRegistering the package also makes the named ELK algorithms available — `elk.stress`, `elk.force`, `elk.mrtree`, `elk.sporeOverlap`, `elk.box` and `elk.rectpacking`. On a normal `mermaid` build you do not need this package at all: registering it is harmless but redundant, since the same layouts are already built in.\n\n## Enabling Click Event and Tags in Nodes\n\nA `securityLevel` configuration has to first be cleared. `securityLevel` sets the level of trust for the parsed diagrams and limits click functionality. This was introduced in version 8.2 as a security improvement, aimed at preventing malicious use.\n\n**It is the site owner's responsibility to discriminate between trustworthy and untrustworthy user-bases and we encourage the use of discretion.**\n\n## securityLevel\n\n| Parameter     | Description                       | Type   | Required | Values                                     |\n| ------------- | --------------------------------- | ------ | -------- | ------------------------------------------ |\n| securityLevel | Level of trust for parsed diagram | String | Optional | 'sandbox', 'strict', 'loose', 'antiscript' |\n\nValues:\n\n- **strict**: (**default**) HTML tags in the text are encoded and click functionality is disabled.\n- **antiscript**: HTML tags in text are allowed (only script elements are removed) and click functionality is enabled.\n- **loose**: HTML tags in text are allowed and click functionality is enabled.\n- **sandbox**: With this security level, all rendering takes place in a sandboxed iframe. This prevents any JavaScript from running in the context. This may hinder interactive functionality of the diagram, like scripts, popups in the sequence diagram, links to other tabs or targets, etc.\n\n```note\nThis changes the default behaviour of mermaid so that after upgrade to 8.2, unless the `securityLevel` is not changed, tags in flowcharts are encoded as tags and clicking is disabled.\n**sandbox** security level is still in the beta version.\n```\n\n**If you are taking responsibility for the diagram source security you can set the `securityLevel` to a value of your choosing. This allows clicks and tags are allowed.**\n\n**To change `securityLevel`, you have to call `mermaid.initialize`:**\n\n```javascript\nmermaid.initialize({\n  securityLevel: 'loose',\n});\n```\n\n### Labels out of bounds\n\nIf you use dynamically loaded fonts that are loaded through CSS, such as fonts, mermaid should wait for the whole page to load (dom + assets, particularly the fonts file).\n\n```javascript\n$(document).ready(function () {\n  mermaid.initialize();\n});\n```\n\nNot doing so will most likely result in mermaid rendering graphs that have labels out of bounds. The default integration in mermaid uses the window.load event to start rendering.\n\nIf your page has other fonts in its body those might be used instead of the mermaid font. Specifying the font in your styling is a workaround for this.\n\n```css\npre.mermaid {\n  font-family: 'trebuchet ms', verdana, arial;\n}\n```\n\n### Using `mermaid.run`\n\nmermaid.run was added in v10 and is the preferred way of handling more complex integration.\nBy default, `mermaid.run` will be called when the document is ready, rendering all elements with `class=\"mermaid\"`.\n\nYou can customize that behavior by calling `await mermaid.run()`.\n\n`mermaid.initialize({startOnLoad: false})` will prevent `mermaid.run` from being called automatically after load.\n\nRender all elements with querySelector \".someOtherClass\"\n\n```js\nmermaid.initialize({ startOnLoad: false });\nawait mermaid.run({\n  querySelector: '.someOtherClass',\n});\n```\n\nRender all elements passed as an array\n\n```js\nmermaid.initialize({ startOnLoad: false });\nawait mermaid.run({\n  nodes: [document.getElementById('someId'), document.getElementById('anotherId')],\n});\nawait mermaid.run({\n  nodes: document.querySelectorAll('.yetAnotherClass'),\n});\n```\n\nRender all `.mermaid` elements while suppressing any error\n\n```js\nmermaid.initialize({ startOnLoad: false });\nawait mermaid.run({\n  suppressErrors: true,\n});\n```\n\n### Calling `mermaid.init` - Deprecated\n\n```warning\nmermaid.init is deprecated in v10 and will be removed in a future release. Please use mermaid.run instead.\n```\n\nBy default, `mermaid.init` will be called when the document is ready, finding all elements with\n`class=\"mermaid\"`. If you are adding content after mermaid is loaded, or otherwise need\nfiner-grained control of this behavior, you can call `init` yourself with:\n\n- a configuration object\n- some nodes, as\n  - a node\n  - an array-like of nodes\n  - or W3C selector that will find your nodes\n\nExample:\n\n```javascript\nmermaid.init({ noteMargin: 10 }, '.someOtherClass');\n```\n\nOr with no config object, and a jQuery selection:\n\n```javascript\nmermaid.init(undefined, $('#someId .yetAnotherClass'));\n```\n\n## Usage with webpack\n\nmermaid fully supports webpack. Here is a [working demo](https://github.com/mermaidjs/mermaid-webpack-demo).\n\n## API usage\n\nThe main idea of the API is to be able to call a render function with the graph definition as a string. The render function will render the graph and call a callback with the resulting SVG code. With this approach it is up to the site creator to fetch the graph definition from the site (perhaps from a textarea), render it and place the graph somewhere in the site.\n\nThe example below shows an example of how this could be used. The example just logs the resulting SVG to the JavaScript console.\n\n```html\n\n```\n\nTo determine the type of diagram present in a given text, you can utilize the `mermaid.detectType` function, as demonstrated in the example below.\n\n```html\n\n```\n\n### Binding events\n\nSometimes the generated graph also has defined interactions like tooltip and click events. When using the API one must\nadd those events after the graph has been inserted into the DOM.\n\nThe example code below is an extract of what mermaid does when using the API. The example shows how it is possible to\nbind events to an SVG when using the API for rendering.\n\n```javascript\n// Example of using the bindFunctions\nconst drawDiagram = async function () {\n  element = document.querySelector('#graphDiv');\n  const graphDefinition = 'graph TB\\na-->b';\n  const { svg, bindFunctions } = await mermaid.render('graphDiv', graphDefinition);\n  element.innerHTML = svg;\n  // This can also be written as `bindFunctions?.(element);` using the `?` shorthand.\n  if (bindFunctions) {\n    bindFunctions(element);\n  }\n};\n```\n\n1. The graph is generated using the render call.\n2. After generation the render function calls the provided callback function, in this case it's called insertSvg.\n3. The callback function is called with two parameters, the SVG code of the generated graph and a function. This function binds events to the SVG **after** it is inserted into the DOM.\n4. Insert the SVG code into the DOM for presentation.\n5. Call the binding function that binds the events.\n\n## Example of a marked renderer\n\nThis is the renderer used for transforming the documentation from Markdown to html with mermaid diagrams in the html.\n\n```javascript\nconst renderer = new marked.Renderer();\nrenderer.code = function (code, language) {\n  if (code.match(/^sequenceDiagram/) || code.match(/^graph/)) {\n    return '
' + code + '
';\n  } else {\n    return '
' + code + '
';\n  }\n};\n```\n\nAnother example in CoffeeScript that also includes the mermaid script tag in the generated markup.\n\n```coffee\nmarked = require 'marked'\n\nmodule.exports = (options) ->\n  hasMermaid = false\n  renderer = new marked.Renderer()\n  renderer.defaultCode = renderer.code\n  renderer.code = (code, language) ->\n    if language is 'mermaid'\n      html = ''\n      if not hasMermaid\n        hasMermaid = true\n        html += ''\n      html + '
'+code+'
'\n    else\n      @defaultCode(code, language)\n\n  renderer\n```\n\n## Advanced usage\n\n### Syntax validation without rendering\n\nThe `mermaid.parse(text, parseOptions)` function validates graph definitions without rendering a graph.\n\nThe function `mermaid.parse(text, parseOptions)`, takes a text string as an argument and returns `{ diagramType: string }` if the definition follows mermaid's syntax.\n\nIf the definition is invalid, the function returns `false` if `parseOptions.suppressErrors` is set to `true`. Otherwise, it throws an error.\n\nThe parseError function will be called when the parse function throws an error. It will not be called if `parseOptions.suppressErrors` is set to `true`.\n\nIt is possible to override this function in order to handle the error in an application-specific way.\n\nThe code-example below in meta code illustrates how this could work:\n\n```javascript\nmermaid.parseError = function (err, hash) {\n  displayErrorInGui(err);\n};\n\nconst textFieldUpdated = async function () {\n  const textStr = getTextFromFormField('code');\n\n  if (await mermaid.parse(textStr)) {\n    reRender(textStr);\n  }\n};\n\nbindEventHandler('change', 'code', textFieldUpdated);\n```\n\n## Configuration\n\nYou can pass the required configuration to the `mermaid.initialize` call. This is the preferred way of configuring mermaid.\nThe list of configuration objects are described [in the mermaidAPI documentation](./setup/README.md).\n\n```html\n\n```\n\n```note\nThis is the preferred way of configuring mermaid.\n```\n\n### The following methods are deprecated and are kept only for backwards compatibility.\n\n## Using the mermaid object\n\nIt is possible to set some configuration via the mermaid object. The two parameters that are supported using this\napproach are:\n\n- mermaid.startOnLoad\n- mermaid.htmlLabels\n\n```javascript\nmermaid.startOnLoad = true;\n```\n\n```warning\nThis way of setting the configuration is deprecated. Instead the preferred way is to use the initialize method. This functionality is only kept for backwards compatibility.\n```\n\n\n\n\n# Integrations\n\n## Official integration\n\n### Mermaid Chart\n\nMermaid Chart is built by the team behind Mermaid JS.\n\nFor more details, visit the [Mermaid Chart page](./mermaid-chart.md), or visit the [Mermaid Chart website](https://mermaid.ai) .\n\n## Community integrations\n\nWe're excited about the growth of the Mermaid community, and the number of plugins and integrations that have been created by the community.\n\nSee the list below of community plugins and integrations created with Mermaid.\n\n```note\nA ✅ indicates Native support for Mermaid on the respective platform.\n```\n\nTo add an integration to this list, see the [Integrations - create page](./integrations-create.md).\n\n### Productivity tools\n\n- [Atlassian Products](https://www.atlassian.com)\n  - [Mermaid for Confluence](https://marketplace.atlassian.com/apps/1224722/mermaid-for-confluence?hosting=cloud&tab=overview)\n  - [Mermaid Integration for Confluence](https://marketplace.atlassian.com/apps/1222792/mermaid-integration-for-confluence?hosting=cloud&tab=overview)\n  - [Mermaid Charts & Diagrams for Confluence](https://marketplace.atlassian.com/apps/1222572/)\n  - [Mermaid Diagrams for Confluence](https://marketplace.atlassian.com/apps/1226945/mermaid-diagrams-for-confluence?hosting=cloud&tab=overview)\n  - [Mermaid Live Editor for Confluence Cloud](https://marketplace.atlassian.com/apps/1231571/mermaid-live-editor-for-confluence?hosting=cloud&tab=overview)\n  - [Mermaid Macro for Confluence](https://marketplace.atlassian.com/apps/1231150/mermaid-macro-for-confluence?hosting=cloud&tab=overview)\n  - [Mermaid Plugin for Confluence](https://marketplace.atlassian.com/apps/1214124/mermaid-plugin-for-confluence?hosting=server&tab=overview)\n  - [EliteSoft Mermaid Charts and Diagrams](https://marketplace.atlassian.com/apps/1227286/elitesoft-mermaid-charts-and-diagrams?hosting=cloud&tab=overview)\n  - [Auto convert diagrams in Jira](https://github.com/coddingtonbear/jirafs-mermaid)\n  - [Mermaid Charts & Diagrams for Jira](https://marketplace.atlassian.com/apps/1224537/)\n  - [Mermaid for Jira Cloud - Draw UML diagrams easily](https://marketplace.atlassian.com/apps/1223053/mermaid-for-jira-cloud-draw-uml-diagrams-easily?hosting=cloud&tab=overview)\n  - [CloudScript.io Mermaid Addon](https://marketplace.atlassian.com/apps/1219878/cloudscript-io-mermaid-addon?hosting=cloud&tab=overview)\n  - [Mermaid plus for Confluence](https://marketplace.atlassian.com/apps/1236814/mermaid-plus-for-confluence?hosting=cloud&tab=overview)\n- [Azure Devops](https://learn.microsoft.com/en-us/azure/devops/project/wiki/markdown-guidance?view=azure-devops#add-mermaid-diagrams-to-a-wiki-page) ✅\n- [Deepdwn](https://billiam.itch.io/deepdwn) ✅\n- [Doctave](https://www.doctave.com/) ✅\n  - [Mermaid in Markdown code blocks](https://docs.doctave.com/components/mermaid) ✅\n- [Forgejo](https://forgejo.org/) ✅\n- [GitBook](https://gitbook.com)\n  - [Mermaid Plugin](https://github.com/JozoVilcek/gitbook-plugin-mermaid)\n  - [Markdown with Mermaid CLI](https://github.com/miao1007/gitbook-plugin-mermaid-cli)\n- [Gitea](https://gitea.io) ✅\n- [GitHub](https://github.com) ✅\n  - [Using code blocks](https://github.blog/2022-02-14-include-diagrams-markdown-files-mermaid/) ✅\n  - [GitHub action: Compile mermaid to image](https://github.com/neenjaw/compile-mermaid-markdown-action)\n  - [GitHub Writer](https://github.com/ckeditor/github-writer)\n  - [SVG diagram generator](https://github.com/SimonKenyonShepard/mermaidjs-github-svg-generator)\n- [GitLab](https://docs.gitlab.com/ee/user/markdown.html#diagrams-and-flowcharts) ✅\n- [GNU Octave](https://octave.org/) ✅\n  - [octave_mermaid_js](https://github.com/CNOCTAVE/octave_mermaid_js) ✅\n- [HackMD](https://hackmd.io/c/tutorials/%2F%40docs%2Fflowchart-en#Create-more-complex-flowcharts) ✅\n- [JetBrains IDEs](https://www.jetbrains.com)\n  - [Mermaid Plugin](https://plugins.jetbrains.com/plugin/20146-mermaid)\n  - [Mermaid Studio](https://plugins.jetbrains.com/plugin/29870-mermaid-studio)\n- [MonsterWriter](https://www.monsterwriter.com/) ✅\n- [Joplin](https://joplinapp.org) ✅\n- [LiveBook](https://livebook.dev) ✅\n- [Slidev](https://sli.dev) ✅\n- [Tuleap](https://docs.tuleap.org/user-guide/writing-in-tuleap.html#graphs) ✅\n- [Mermaid Flow Visual Editor](https://www.mermaidflow.app) ✅\n- [Mermaid Studio by webtoolz](https://webtoolz.dev/mermaid) - Browser-based Mermaid editor with live preview, curated themes, and PNG/SVG export\n- [Mermerd](https://github.com/KarnerTh/mermerd)\n- [Slab](https://slab.com) ✅\n- [Swimm](https://docs.swimm.io/features/diagrams-and-charts) ✅\n- [NotesHub](https://noteshub.app) ✅\n- [Notion](https://notion.so) ✅\n- [Observable](https://observablehq.com/@observablehq/mermaid) ✅\n- [Obsidian](https://help.obsidian.md/Editing+and+formatting/Advanced+formatting+syntax#Diagram) ✅\n- [Outline](https://docs.getoutline.com/s/guide/doc/diagrams-KQiKoT4wzK) ✅\n- [Redmine](https://redmine.org)\n  - [Mermaid Macro](https://redmine.org/plugins/redmine_mermaid_macro)\n  - [Markdown for mermaid plugin](https://github.com/jamieh-mongolian/markdown-for-mermaid-plugin)\n  - [redmine-mermaid](https://github.com/styz/redmine_mermaid)\n- Visual Studio Code [Polyglot Interactive Notebooks](https://github.com/dotnet/interactive#net-interactive)\n- [Microsoft Loop](https://loop.cloud.microsoft) ✅\n\n### LLM integrations\n\nLLM integrations to create mermaid diagrams using AI from text descriptions.\n\n- [HueHive - Create mermaid diagrams with text](https://huehive.co/tools/diagrams)\n- [MCP Server Mermaid](https://github.com/hustcc/mcp-mermaid) - Generate mermaid diagram and chart with AI MCP dynamically.\n- [Mermaid Studio](https://mermaidstudio.dev) - Leverage Mermaid Studio's code intelligence and diagram generation capabilities via MCP to create high-quality diagrams (requires a [JetBrains IDE](https://jetbrains.com/ides)) using your favorite coding agent.\n\n### CRM/ERP\n\nCustomer Relationship Management/Enterprise Resource Planning\n\n- [coreBOS](https://blog.corebos.org/blog/december2019)\n\n### Blogging\n\nBlogging frameworks and platforms\n\n- [Hexo](https://hexo.io)\n  - [hexo-filter-mermaid-diagrams](https://github.com/webappdevelp/hexo-filter-mermaid-diagrams)\n  - [hexo-tag-mermaid](https://github.com/JameChou/hexo-tag-mermaid)\n  - [hexo-mermaid-diagrams](https://github.com/mslxl/hexo-mermaid-diagrams)\n- [Nextra](https://nextra.site/)\n  - [Mermaid](https://nextra.site/docs/guide/mermaid)\n- [WordPress](https://wordpress.org)\n  - [MerPRess](https://wordpress.org/plugins/merpress/)\n  - [WP Documentation](https://wordpress.org/themes/wp-documentation/)\n\n### CMS/ECM\n\nContent Management Systems/Enterprise Content Management\n\n- [ApostropheCMS](https://apostrophecms.com/)\n  - [Extension for Mermaid.js](https://github.com/BoDonkey/mermaid-extension)\n- [Drupal](https://drupal.org/)\n  - [Mermaid Diagram Field module](https://www.drupal.org/project/mermaid_diagram_field)\n- [Grav CMS](https://getgrav.org/)\n  - [Mermaid Diagrams Plugin](https://github.com/DanielFlaum/grav-plugin-mermaid-diagrams)\n  - [GitLab Markdown Adapter](https://github.com/Goutte/grav-plugin-gitlab-markdown-adapter)\n- [Tiki Wiki CMS Groupware](https://tiki.org)\n  - [Tracker Entity Relationship Diagram](https://doc.tiki.org/Tracker-Entity-Relationship-Diagram)\n- [VitePress](https://vitepress.vuejs.org/)\n  - [Plugin for Mermaid.js](https://emersonbottero.github.io/vitepress-plugin-mermaid/)\n- [VuePress](https://vuepress.vuejs.org/)\n  - [Plugin for Mermaid.js](https://github.com/eFrane/vuepress-plugin-mermaidjs)\n\n### Communication\n\nCommunication tools and platforms\n\n- [Discourse](https://discourse.org)\n  - [Mermaid Plugin](https://github.com/pnewell/discourse-mermaid)\n- [Mattermost](https://mattermost.com/)\n  - [Mermaid Plugin](https://github.com/SpikeTings/Mermaid)\n- [NodeBB](https://nodebb.org)\n  - [Mermaid Parser Plugin](https://www.npmjs.com/package/nodebb-plugin-mermaid)\n- [phpBB](https://phpbb.com)\n  - [phpbb-ext-mermaid](https://github.com/AlfredoRamos/phpbb-ext-mermaid)\n- [Slack](https://slack.com)\n  - [Mermaid Preview](https://mermaid-preview.com)\n\n### Wikis\n\n- [DokuWiki](https://dokuwiki.org)\n  - [ComboStrap](https://combostrap.com/utility/create-diagram-with-mermaid-vh3ab9yj)\n  - [Mermaid Plugin](https://www.dokuwiki.org/plugin:mermaid)\n- [Foswiki](https://foswiki.org)\n  - [Mermaid Plugin](https://foswiki.org/Extensions/MermaidPlugin)\n- [MediaWiki](https://www.mediawiki.org)\n  - [Flex Diagrams Extension](https://www.mediawiki.org/wiki/Extension:Flex_Diagrams)\n  - [Mermaid Extension](https://www.mediawiki.org/wiki/Extension:Mermaid)\n- [PmWiki](https://www.pmwiki.org)\n  - [MermaidJs Cookbook recipe](https://www.pmwiki.org/wiki/Cookbook/MermaidJs)\n- [Semantic Media Wiki](https://www.semantic-mediawiki.org)\n  - [Mermaid Plugin](https://github.com/SemanticMediaWiki/Mermaid)\n- [TiddlyWiki](https://tiddlywiki.com/)\n  - [mermaid-tw5: wrapper for Mermaid Live](https://github.com/efurlanm/mermaid-tw5)\n  - [tw5-mermaid: plugin for managing Mermaid.js tiddlers](https://github.com/jasonmhoule/tw5-mermaid)\n\n### Editor Plugins\n\n- Atom _(Atom has been [archived.](https://github.blog/2022-06-08-sunsetting-atom/))_\n  - [Markdown Preview Enhanced](https://github.com/shd101wyy/markdown-preview-enhanced)\n  - [Atom Mermaid](https://github.com/y-takey/atom-mermaid)\n  - [Language Mermaid Syntax Highlighter](https://github.com/ytisf/language-mermaid)\n- [Astah](https://astah.net)\n  - [Export to Mermaid](https://github.com/Avens666/Astah_Jude_UML_export_to_Markdown-mermaid-Plantuml-)\n- [Brackets](https://brackets.io/)\n  - [Mermaid Preview](https://github.com/AlanHohn/mermaid-preview)\n- [CKEditor](https://github.com/ckeditor/ckeditor5)\n  - [CKEditor 5 Mermaid plugin](https://github.com/ckeditor/ckeditor5-mermaid)\n- [Draw.io](https://draw.io)\n  - [Mermaid Plugin](https://github.com/nopeslide/drawio_mermaid_plugin)\n- [GNU Emacs](https://www.gnu.org/software/emacs/)\n  - [Major mode for .mmd files](https://github.com/abrochard/mermaid-mode)\n  - [Org-Mode integration](https://github.com/arnm/ob-mermaid)\n- [GNU Nano](https://www.nano-editor.org/)\n  - [Nano Mermaid](https://github.com/Yash-Singh1/nano-mermaid)\n- [Google docs](https://docs.google.com/)\n  - [Mermaid plugin for google docs](https://workspace.google.com/marketplace/app/mermaid/636321283856)\n- [Inkdrop](https://www.inkdrop.app)\n  - [Mermaid Plugin](https://github.com/inkdropapp/inkdrop-mermaid)\n- [IntelliJ Idea](https://www.jetbrains.com/idea/)\n  - [Mermaid Visualizer](https://plugins.jetbrains.com/plugin/30432-mermaid-visualizer)\n- [Light Table](http://lighttable.com/)\n  - [Mermaid Plugin](https://github.com/cldwalker/Mermaid)\n- [Markdown-It](https://github.com/markdown-it/markdown-it)\n  - [Textual UML Parser](https://github.com/manastalukdar/markdown-it-textual-uml)\n  - [Mermaid Plugin](https://github.com/tylingsoft/markdown-it-mermaid)\n  - [md-it-mermaid](https://github.com/iamcco/md-it-mermaid)\n  - [markdown-it-mermaid-less](https://github.com/searKing/markdown-it-mermaid-less)\n- [Podlite](https://github.com/zag/podlite-desktop)\n  - [=Diagram block](https://github.com/zag/podlite/tree/main/packages/podlite-diagrams)\n- [Standard Notes](https://standardnotes.com/)\n  - [Mermaid Extension](https://github.com/nienow/sn-mermaid)\n- [VS Code](https://code.visualstudio.com/)\n  - [Mermaid Editor](https://marketplace.visualstudio.com/items?itemName=tomoyukim.vscode-mermaid-editor)\n  - [Mermaid Export](https://marketplace.visualstudio.com/items?itemName=Gruntfuggly.mermaid-export)\n  - [Markdown PDF](https://marketplace.visualstudio.com/items?itemName=yzane.markdown-pdf)\n  - [Markdown Preview Mermaid Support](https://marketplace.visualstudio.com/items?itemName=bierner.markdown-mermaid)\n  - [Markdown Preview Enhanced](https://marketplace.visualstudio.com/items?itemName=shd101wyy.markdown-preview-enhanced)\n  - [Mermaid Preview](https://marketplace.visualstudio.com/items?itemName=vstirbu.vscode-mermaid-preview)\n  - [Preview](https://marketplace.visualstudio.com/items?itemName=searKing.preview-vscode)\n  - [Preview Sequence Diagrams](https://marketplace.visualstudio.com/items?itemName=arichika.previewseqdiag-vscode)\n  - [Mermaid Markdown Syntax Highlighting](https://marketplace.visualstudio.com/items?itemName=bpruitt-goddard.mermaid-markdown-syntax-highlighting)\n- [Vim](https://www.vim.org)\n  - [Vim Diagram Syntax](https://github.com/zhaozg/vim-diagram)\n  - [Official Vim Syntax and ft plugin](https://github.com/craigmac/vim-mermaid)\n- [Zed](https://zed.dev)\n  - [zed-mermaid](https://github.com/gabeidx/zed-mermaid)\n\n### Document Generation\n\n- [Astro](https://astro.build/)\n  - [Adding diagrams to your Astro site with MermaidJS and Playwright](https://agramont.net/blog/diagraming-with-mermaidjs-astro/)\n- [Codedoc](https://codedoc.cc/)\n  - [codedoc-mermaid-plugin](https://www.npmjs.com/package/codedoc-mermaid-plugin)\n- [Docsy Hugo Theme](https://www.docsy.dev/docs/content/diagrams-and-formulae/) ✅\n- [Docusaurus](https://docusaurus.io/docs/markdown-features/diagrams) ✅\n- [Gatsby](https://www.gatsbyjs.com/)\n  - [gatsby-remark-mermaid](https://github.com/remcohaszing/gatsby-remark-mermaid)\n- [Jekyll](https://jekyllrb.com/)\n  - [jekyll-mermaid](https://rubygems.org/gems/jekyll-mermaid)\n  - [jekyll-mermaid-diagrams](https://github.com/fuzhibo/jekyll-mermaid-diagrams)\n- [JSDoc](https://jsdoc.app/)\n  - [jsdoc-mermaid](https://github.com/Jellyvision/jsdoc-mermaid)\n- [Madness](https://madness.dannyb.co/)\n- [mdBook](https://rust-lang.github.io/mdBook/index.html)\n  - [mdbook-mermaid](https://github.com/badboy/mdbook-mermaid)\n- [MkDocs](https://www.mkdocs.org)\n  - [mkdocs-mermaid2-plugin](https://github.com/fralau/mkdocs-mermaid2-plugin)\n  - [mkdocs-material](https://github.com/squidfunk/mkdocs-material), check the [docs](https://squidfunk.github.io/mkdocs-material/reference/diagrams/)\n- [Quarto](https://quarto.org/) ✅\n- [rehype](https://github.com/rehypejs/rehype)\n  - [rehype-mermaid](https://github.com/remcohaszing/rehype-mermaid)\n- [remark](https://remark.js.org/)\n  - [remark-mermaidjs](https://github.com/remcohaszing/remark-mermaidjs)\n- [Sphinx](https://www.sphinx-doc.org/en/master/)\n  - [sphinxcontrib-mermaid](https://github.com/mgaitan/sphinxcontrib-mermaid)\n- [Type Doc](https://typedoc.org/)\n  - [typedoc-plugin-mermaid](https://www.npmjs.com/package/typedoc-plugin-mermaid)\n- [Typora](https://support.typora.io/Draw-Diagrams-With-Markdown/#mermaid) ✅\n- [Unison programming language](https://www.unison-lang.org/docs/usage-topics/documentation/) ✅\n\n### Browser Extensions\n\n| Name                     | Chrome Web Store                                                                                            | Firefox Add-ons                                                                | Opera                                                                          | Edge                                                                                                                         | Source/Repository                                                                                    |\n| ------------------------ | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |\n| GitHub + Mermaid         | -                                                                                                           | [🦊🔗](https://addons.mozilla.org/firefox/addon/github-mermaid/)               | -                                                                              | -                                                                                                                            | [🐙🔗](https://github.com/BackMarket/github-mermaid-extension)                                       |\n| Asciidoctor Live Preview | [🎡🔗](https://chromewebstore.google.com/detail/asciidoctorjs-live-previe/iaalpfgpbocpdfblpnhhgllgbdbchmia) | -                                                                              | -                                                                              | [🌀🔗](https://microsoftedge.microsoft.com/addons/detail/asciidoctorjs-live-previ/pefkelkanablhjdekgdahplkccnbdggd?hl=en-US) | -                                                                                                    |\n| Diagram Tab              | -                                                                                                           | -                                                                              | -                                                                              | -                                                                                                                            | [🐙🔗](https://github.com/khafast/diagramtab)                                                        |\n| Markdown Diagrams        | [🎡🔗](https://chromewebstore.google.com/detail/markdown-diagrams/pmoglnmodacnbbofbgcagndelmgaclel)         | [🦊🔗](https://addons.mozilla.org/en-US/firefox/addon/markdown-diagrams/)      | -                                                                              | [🌀🔗](https://microsoftedge.microsoft.com/addons/detail/markdown-diagrams/hceenoomhhdkjjijnmlclkpenkapfihe)                 | [🐙🔗](https://github.com/marcozaccari/markdown-diagrams-browser-extension/tree/master/doc/examples) |\n| Markdown Viewer          | -                                                                                                           | [🦊🔗](https://addons.mozilla.org/en-US/firefox/addon/markdown-viewer-chrome/) | -                                                                              | -                                                                                                                            | [🐙🔗](https://github.com/simov/markdown-viewer)                                                     |\n| Extensions for Mermaid   | -                                                                                                           | -                                                                              | [🔴🔗](https://addons.opera.com/en/extensions/details/extensions-for-mermaid/) | -                                                                                                                            | [🐙🔗](https://github.com/Stefan-S/mermaid-extension)                                                |\n| Chrome Diagrammer        | [🎡🔗](https://chromewebstore.google.com/detail/chrome-diagrammer/bkpbgjmkomfoakfklcjeoegkklgjnnpk)         | -                                                                              | -                                                                              | -                                                                                                                            | -                                                                                                    |\n| Mermaid Diagrams         | [🎡🔗](https://chromewebstore.google.com/detail/mermaid-diagrams/phfcghedmopjadpojhmmaffjmfiakfil)          | -                                                                              | -                                                                              | -                                                                                                                            | -                                                                                                    |\n| Monkeys                  | [🎡🔗](https://chromewebstore.google.com/detail/monkeys-mermaid-for-githu/cplfdpoajbclbgphaphphcldamfkjlgi) | -                                                                              | -                                                                              | -                                                                                                                            | -                                                                                                    |\n| Mermaid Previewer        | [🎡🔗](https://chromewebstore.google.com/detail/mermaid-previewer/oidjnlhbegipkcklbdfnbkikplpghfdl)         | -                                                                              | -                                                                              | -                                                                                                                            | -                                                                                                    |\n| Tachi Code               | [🎡🔗](https://chromewebstore.google.com/detail/tachi-code/acoecgiamdjjkhmdodcfdfanfnagamjf)                | [🦊🔗](https://addons.mozilla.org/en-US/firefox/addon/tachi-code/)             | -                                                                              | [🌀🔗](https://microsoftedge.microsoft.com/addons/detail/tachi-code/mombmlijgpfamkenkmggobjimompbpji)                        | -                                                                                                    |\n\n### Other\n\n- [Bisheng](https://www.npmjs.com/package/bisheng)\n  - [bisheng-plugin-mermaid](https://github.com/yct21/bisheng-plugin-mermaid)\n- [Blazorade Mermaid: Render Mermaid diagrams in Blazor applications](https://github.com/Blazorade/Blazorade-Mermaid/wiki)\n- [Codemia: A tool to practice system design problems](https://codemia.io) ✅\n- [ExDoc](https://github.com/elixir-lang/ex_doc)\n  - [Rendering Mermaid graphs](https://github.com/elixir-lang/ex_doc#rendering-mermaid-graphs)\n- [MarkChart: Preview Mermaid diagrams on macOS](https://markchart.app/)\n- [mermaid-isomorphic](https://github.com/remcohaszing/mermaid-isomorphic)\n- [mermaid-server: Generate diagrams using a HTTP request](https://github.com/TomWright/mermaid-server)\n- [NiceGUI: Let any browser be the frontend of your Python code](https://nicegui.io) ✅\n  - [ui.mermaid(...)](https://nicegui.io/documentation/mermaid)\n- [Reveal.js](https://github.com/hakimel/reveal.js)\n  - [reveal.js-mermaid-plugin](https://github.com/ludwick/reveal.js-mermaid-plugin)\n- [Reveal CK](https://github.com/jedcn/reveal-ck)\n  - [reveal-ck-mermaid-plugin](https://github.com/tmtm/reveal-ck-mermaid-plugin)\n- [SchemaCrawler - Generate Mermaid diagrams from your database](https://dev.to/sualeh/how-to-generate-mermaid-diagrams-for-your-database-33bn)\n- [Schema3D](https://schema3d.com) - Browser-only 3D visualizer for Mermaid ER diagrams (also SQL / DrawDB); shareable URL, no live DB\n- [speccharts: Turn your test suites into specification diagrams](https://github.com/arnaudrenaud/speccharts)\n- [termaid: Render Mermaid diagrams as Unicode art in the terminal](https://github.com/fasouto/termaid)\n- [Vitepress Plugin](https://github.com/sametcn99/vitepress-mermaid-renderer)\n\n\n\n\n# Integrations - create\n\n## Recommendations\n\nBelow are recommendations for creating plugins and integrations with Mermaid.\n\n### File Extension\n\nApplications that support Mermaid files [SHOULD](https://datatracker.ietf.org/doc/html/rfc2119#section-3) use `.mermaid` or `.mmd` file extensions.\n\n### MIME Type\n\nThe recommended [MIME type](https://www.iana.org/assignments/media-types/media-types.xhtml) for Mermaid media is [`text/vnd.mermaid`](https://www.iana.org/assignments/media-types/application/vnd.mermaid).\n\n## Showcase\n\n### Mermaid Discord workspace\n\nWe would love to see what you create with Mermaid. Please share your creations with us in our [Discord](https://discord.gg/sKeNQX4Wtj) server [#showcase](https://discord.com/channels/1079455296289788015/1079502635054399649) channel.\n\n### Add to Mermaid Ecosystem\n\nIf you have a plugin or integration that you'd like to add to our [Community integrations](/ecosystem/integrations-community) list, please [open a pull request](https://github.com/mermaid-js/mermaid).\n\n\n# Mermaid Chart\n\nThe Future of Diagramming & Visual Collaboration\n\nTry the Ultimate AI, Mermaid, and Visual Diagramming Suite by creating an account at [Mermaid Chart](https://mermaid.ai/app/sign-up).\n\n
\n\n\"Mermaid Chart\n\n## About\n\n[Mermaid Chart](https://mermaid.ai) was born out of the Mermaid open source project and was founded by Knut Sveidqvist together with Open Core Ventures. The lead developers from Mermaid have joined the company and there is a strong connection between the project we all love and Mermaid Chart. Mermaid Chart brings resources to the open source development of Mermaid and makes it possible to work with Mermaid professionally.\n\n## Features\n\n- **Editor** - A web based editor for creating and editing Mermaid diagrams.\n\n- **Mermaid AI** - Use our embedded AI Chat to generate diagrams from natural language descriptions.\n\n- **Whiteboard** - A virtual whiteboard for creating and editing Mermaid diagrams.\n\n- **Plugins** - A plugin system for extending the functionality of Mermaid.\n\n  Official Mermaid Chart plugins:\n  - [Mermaid Chart GPT](https://chatgpt.com/g/g-684cc36f30208191b21383b88650a45d-mermaid-chart-diagrams-and-charts)\n  - [Confluence](https://marketplace.atlassian.com/apps/1234056/mermaid-chart-for-confluence?hosting=cloud&tab=overview)\n  - [Jira](https://marketplace.atlassian.com/apps/1234810/mermaid-chart-for-jira?tab=overview&hosting=cloud)\n  - [Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=MermaidChart.vscode-mermaid-chart)\n  - [JetBrains IDE](https://plugins.jetbrains.com/plugin/23043-mermaid-chart)\n  - [Google Docs](https://gsuite.google.com/marketplace/app/mermaidchart/947683068472)\n  - [Microsoft PowerPoint and Word](https://appsource.microsoft.com/en-us/product/office/WA200006214?tab=Overview)\n\n  Visit our [Plugins](https://mermaid.ai/plugins) page for more information.\n\n- **Collaboration** - A web based collaboration feature for multi-user editing on Mermaid diagrams in real-time (Pro and Enterprise plans).\n\n- **Comments** - Enhance collaboration by adding comments to diagrams.\n\n- **Presentations** - A presentation mode for viewing Mermaid diagrams in a slideshow format.\n\n## Plans\n\n- **Basic** - A free plan that includes three diagrams and limited AI usage.\n\n- **Plus** - A paid plan that includes unlimited diagrams, scalable AI usage, and centralized billing for small teams.\n\n- **Premium** - A paid plan for larger teams that need massive AI or diagram usage along with team collaboration, knowledge management, and security features like SSO.\n\n- **Enterprise** - A paid plan for enterprise use that includes all Premium features, custom contracts, support, and more.\n\nTo learn more, visit our [Pricing](https://mermaid.ai/pricing) page.\n\nSign up for a free account on the [Mermaid](https://mermaid.ai/app/sign-up) website and trial paid features at any time for 7 days free.\n\n## Mermaid JS contributions\n\nFirst time contributors are eligible for a free Premium tier account for 1 year.\n\n\n# Tutorials\n\nThis is a list of publicly available Tutorials for using Mermaid.JS and is intended as a basic introduction for the use of the Live Editor for generating diagrams, and deploying Mermaid.JS through HTML.\n\n**Note that these tutorials might display an older interface, but the usage of the live-editor will largely be the same.**\n\nFor most purposes, you can use the [Live Editor](https://mermaid.live), to quickly and easily render a diagram.\n\n## Live-Editor Tutorials\n\nThe definitions that can be generated the Live-Editor are also backwards-compatible as of version 8.7.0.\n\n[Chris Chinchilla: Hands on - Text-based diagrams with Mermaid](https://www.youtube.com/watch?v=4_LdV1cs2sA)\n\n[GitLab Unfiltered: How to Create Mermaid Diagrams](https://www.youtube.com/watch?v=SQ9QmuTHuSI&t=438s)\n\n[GitLab Unfiltered: Emilie adds a mermaid diagram to the handbook](https://www.youtube.com/watch?v=5RQqht3NNSE)\n\n[World of Zero: I Learn How To Build Flowcharts and Signal Diagram's in Mermaid.JS](https://www.youtube.com/watch?v=7_2IroEs6Is&t=207s)\n\n[Eddie Jaoude: Can you code your diagrams?](https://www.youtube.com/watch?v=9HZzKkAqrX8)\n\n## Mermaid with OpenAI\n\n[Elle Neal: Mind Mapping with AI: An Accessible Approach for Neurodiverse Learners Tutorial:](https://medium.com/@elle.neal_71064/mind-mapping-with-ai-an-accessible-approach-for-neurodiverse-learners-1a74767359ff)\n\n## Mermaid with HTML\n\nExamples are provided in [Getting Started](../intro/getting-started.md)\n\n**CodePen Examples:**\n\nhttps://codepen.io/CarlBoneri/pen/BQwZzq\n\nhttps://codepen.io/tdkn/pen/vZxQzd\n\nhttps://codepen.io/janzeteachesit/pen/OWWZKN\n\n## Mermaid with Text Area\n\nhttps://codepen.io/Ryuno-Ki/pen/LNxwgR\n\n## Mermaid in open source docs\n\n[K8s.io Diagram Guide](https://kubernetes.io/docs/contribute/style/diagram-guide/)\n\n[K8s.dev blog: Improve your documentation with Mermaid.js diagrams](https://www.kubernetes.dev/blog/2021/12/01/improve-your-documentation-with-mermaid.js-diagrams/)\n\n## Jupyter / Python Integration with mermaid-js\n\nHere's an example of Python integration with mermaid-js which uses the mermaid.ink service, that displays the graph in a Jupyter notebook and save it as _.png_ image with the stated resolution (in this example, `dpi=1200`).\n\n```python\nimport base64\nimport io, requests\nfrom IPython.display import Image, display\nfrom PIL import Image as im\nimport matplotlib.pyplot as plt\n\ndef mm(graph):\n    graphbytes = graph.encode(\"utf8\")\n    base64_bytes = base64.urlsafe_b64encode(graphbytes)\n    base64_string = base64_bytes.decode(\"ascii\")\n    img = im.open(io.BytesIO(requests.get('https://mermaid.ink/img/' + base64_string).content))\n    plt.imshow(img)\n    plt.axis('off') # allow to hide axis\n    plt.savefig('image.png', dpi=1200)\n\nmm(\"\"\"\ngraph LR;\n    A--> B & C & D\n    B--> A & E\n    C--> A & E\n    D--> A & E\n    E--> B & C & D\n\"\"\")\n```\n\n**Output**\n\n![Example graph of the Python integration](img/python-mermaid-integration.png)\n\n\n\n\n---\nlayout: home\nsidebar: false\n\ntitle: Mermaid\ntitleTemplate: Diagramming and charting tool\nhero:\n  name: Mermaid.js now lives\n  text: at mermaid.ai\n  tagline: One home for the open-source library and the platform built around it. More resources for the project, a clearer path for contributors, and a team committed to keeping Mermaid open, always.\n\n  image:\n    light: /hero-chart.svg\n    dark: /hero-chart-dark.svg\n    alt: Mermaid diagram\n  actions:\n    - theme: brand\n      text: Try Editor\n      link: https://mermaid.live/edit\n      target: _blank\n      rel: external\n    - theme: alt\n      text: Get started\n      link: https://mermaid.ai/open-source/intro/\n\nfeatures:\n  - icon:\n      src: /1-Callout-Easy.svg\n    title: Easy to use\n    details: Easily create diagrams and charts with the Mermaid Live Editor.\n    link: https://mermaid.live/\n  - icon:\n      src: /2-Callout-Integrations.svg\n    title: Integrations available\n    details: Use Mermaid with your favorite applications, check out the integrations list.\n    link: ../../ecosystem/integrations-community.md\n  - icon:\n      src: /3-Callout-Awards.svg\n    title: Award winning\n    details: 2019 JavaScript Open Source Award winner for \"The Most Exciting Use of Technology\".\n    link: https://osawards.com/javascript/2019\n---\n\n\n## Diagram Types\n\n### [Flowchart](../syntax/flowchart.md?id=flowcharts-basic-syntax)\n\n```mermaid-example\ngraph TD;\n    A-->B;\n    A-->C;\n    B-->D;\n    C-->D;\n```\n\n### [Sequence diagram](../syntax/sequenceDiagram.md)\n\n```mermaid-example\nsequenceDiagram\n    participant Alice\n    participant Bob\n    Alice->>John: Hello John, how are you?\n    loop HealthCheck\n        John->>John: Fight against hypochondria\n    end\n    Note right of John: Rational thoughts 
prevail!\n    John-->>Alice: Great!\n    John->>Bob: How about you?\n    Bob-->>John: Jolly good!\n```\n\n### [Use case diagram](../syntax/usecase.md)\n\n```mermaid-example\nusecase-beta\ndirection LR\nactor Customer\nCheckout(\"Place order\")\nCustomer --> Checkout\n```\n\n### [Gantt diagram](../syntax/gantt.md)\n\n```mermaid-example\ngantt\ndateFormat  YYYY-MM-DD\ntitle Adding GANTT diagram to mermaid\nexcludes weekdays 2014-01-10\n\nsection A section\nCompleted task            :done,    des1, 2014-01-06,2014-01-08\nActive task               :active,  des2, 2014-01-09, 3d\nFuture task               :         des3, after des2, 5d\nFuture task2               :         des4, after des3, 5d\n```\n\n### [Class diagram](../syntax/classDiagram.md)\n\n```mermaid-example\nclassDiagram\nClass01 <|-- AveryLongClass : Cool\nClass03 *-- Class04\nClass05 o-- Class06\nClass07 .. Class08\nClass09 --> C2 : Where am i?\nClass09 --* C3\nClass09 --|> Class07\nClass07 : equals()\nClass07 : Object[] elementData\nClass01 : size()\nClass01 : int chimp\nClass01 : int gorilla\nClass08 <--> C2: Cool label\n```\n\n### [Git graph](../syntax/gitgraph.md)\n\n```mermaid-example\n    gitGraph\n       commit\n       commit\n       branch develop\n       commit\n       commit\n       commit\n       checkout main\n       commit\n       commit\n```\n\n### [Entity Relationship Diagram - :exclamation: experimental](../syntax/entityRelationshipDiagram.md)\n\n```mermaid-example\nerDiagram\n    CUSTOMER ||--o{ ORDER : places\n    ORDER ||--|{ LINE-ITEM : contains\n    CUSTOMER }|..|{ DELIVERY-ADDRESS : uses\n\n```\n\n### [User Journey Diagram](../syntax/userJourney.md)\n\n```mermaid-example\njourney\n    title My working day\n    section Go to work\n      Make tea: 5: Me\n      Go upstairs: 3: Me\n      Do work: 1: Me, Cat\n    section Go home\n      Go downstairs: 5: Me\n      Sit down: 5: Me\n```\n\n### [Quadrant Chart](../syntax/quadrantChart.md)\n\n```mermaid-example\nquadrantChart\n    title Reach and engagement of campaigns\n    x-axis Low Reach --> High Reach\n    y-axis Low Engagement --> High Engagement\n    quadrant-1 We should expand\n    quadrant-2 Need to promote\n    quadrant-3 Re-evaluate\n    quadrant-4 May be improved\n    Campaign A: [0.3, 0.6]\n    Campaign B: [0.45, 0.23]\n    Campaign C: [0.57, 0.69]\n    Campaign D: [0.78, 0.34]\n    Campaign E: [0.40, 0.34]\n    Campaign F: [0.35, 0.78]\n```\n\n### [XY Chart](../syntax/xyChart.md)\n\n```mermaid-example\nxychart-beta\n    title \"Sales Revenue\"\n    x-axis [jan, feb, mar, apr, may, jun, jul, aug, sep, oct, nov, dec]\n    y-axis \"Revenue (in $)\" 4000 --> 11000\n    bar [5000, 6000, 7500, 8200, 9500, 10500, 11000, 10200, 9200, 8500, 7000, 6000]\n    line [5000, 6000, 7500, 8200, 9500, 10500, 11000, 10200, 9200, 8500, 7000, 6000]\n```\n\n\n---\noutline: 'deep' # shows all h3 headings in outline in Vitepress\n---\n\n# Mermaid User Guide\n\n## Mermaid is composed of three parts\n\n1. Deployment\n2. Syntax\n3. Configuration\n\nThis section talks about the different ways to **deploy** Mermaid.\n\nIf you are a beginner:\n\n- Check out the [Diagram Syntax](syntax-reference.md) page\n- Check out the [Tutorials](../ecosystem/tutorials.md) page\n\n## Ways to use Mermaid\n\n1. [Using the Mermaid Live Editor](getting-started.md#_1-using-the-mermaid-live-editor)\n2. [Using the Mermaid Chart Editor](getting-started.md#_2-using-the-mermaid-chart-editor)\n3. [Using Mermaid Plugins and Integrations](getting-started.md#_3-using-mermaid-plugins)\n4. [Calling the Mermaid JavaScript API](getting-started.md#_4-calling-the-mermaid-javascript-api)\n5. [Adding Mermaid as a dependency](getting-started.md#_5-adding-mermaid-as-a-dependency)\n\nTo learn more, visit the [Usage](../config/usage.md) page.\n\n## 1. Using the Mermaid Live Editor\n\nAvailable at the [Mermaid Live Editor](https://mermaid.live) website.\n\n### Features\n\n
\n\n#### • Diagram Code\n\nIn the `Code` panel, write or edit Mermaid code, and instantly `Preview` the rendered result in the diagram panel.\n\nHere is an example of Mermaid code and its rendered result:\n\n```mermaid-example\ngraph TD\n    A[Enter Chart Definition] --> B(Preview)\n    B --> C{decide}\n    C --> D[Keep]\n    C --> E[Edit Definition]\n    E --> B\n    D --> F[Save Image and Code]\n    F --> B\n```\n\n
\n\n#### • Configurations\n\nConfiguration options are available in the `Configuration` panel. The options are applied to the diagram in the `Preview` panel.\n\nTo learn more, visit the [Configuration Reference](../config/setup/README.md) page\n\n![Code,Config and Preview](./img/Code-Preview-Config.png)\n\n
\n\n#### • Editing History\n\nYour code will be autosaved and appear in the `Timeline` tab of the `History` section. Edits are saved every minute and only the last 30 edits are viewable.\n\nAlternatively, you can manually save code by clicking on the `Save` icon from the `History` section.\n\n```note\nHistory is stored in the browser storage only.\n```\n\n
\n\n#### • Saving a diagram\n\nThere are multiple ways of saving your diagram from the `Actions` section:\n\n- export PNG\n- export SVG\n- export as Markdown\n\n![Flowchart](./img/Live-Editor-Choices.png)\n\n
\n\n#### • Editing your diagrams\n\nTo edit your diagram, you can copy paste existing Mermaid diagram code into the `Code` section of the `Live Editor`.\n\nOr:\n\n- create a new diagram from scratch\n- use a Sample Diagram from the `Sample Diagrams` section\n\n
\n\n#### • Loading from Gists\n\nThe Gist you create should have a `code.mmd` file and optionally a `config.json`, similar to this [example](https://gist.github.com/sidharthv96/6268a23e673a533dcb198f241fd7012a).\n\n```note\nTo learn about Gists, visit the GitHub documentation page on [Creating gists](https://docs.github.com/en/get-started/writing-on-github/editing-and-sharing-content-with-gists/creating-gists).\n```\n\nOnce you have created a Gist, copy paste the Gist URL into the respective field in the `Actions` section and click on the `Load Gist` button.\n\nHere is an example of a Gist being loaded into the Editor:\n\n\n\nAnd, here is the diagram view from the above example:\n\n\n\n## 2. Using the Mermaid Chart Editor\n\nAvailable at the [Mermaid Chart](https://mermaid.ai/) website.\n\nMermaid Chart is a web-based diagram editor that allows you to create and edit diagrams in your browser. It is built by the team behind Mermaid.\n\nFeatures include:\n\n- AI diagramming\n- Collaboration & multi-user editing\n- Storage\n- and more\n\nTo learn more, visit the [Mermaid Chart page](/ecosystem/mermaid-chart.html) in the Ecosystem section of the documentation.\n\nOr go to the [Mermaid Chart website](https://mermaid.ai/app/sign-up) to sign up for a Free account.\n\n## 3. Using Mermaid Plugins\n\n### Mermaid Plugins\n\nYou can generate Mermaid diagrams from within popular applications using plug-ins.\n\nFor a list of Mermaid Plugins and Integrations, visit the [Integrations page](../ecosystem/integrations-community.md).\n\n### Mermaid Chart Plugins\n\nMermaid Chart plugins are available for:\n\n- [ChatGPT](https://mermaid.ai/docs/plugins/mermaid-chart-gpt)\n- [JetBrains IDE](https://mermaid.ai/docs/plugins/jetbrains-ide)\n- [Microsoft PowerPoint](https://mermaid.ai/docs/plugins/microsoft-powerpoint)\n- [Microsoft Word](https://mermaid.ai/docs/plugins/microsoft-word)\n- [Visual Studio Code](https://mermaid.ai/docs/plugins/visual-studio-code)\n\nTo learn more, visit the [Mermaid Chart Plugins](https://mermaid.ai/plugins) page.\n\n### Native Mermaid Support\n\nFor apps that support markdown (e.g. [GitHub](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-diagrams) and [GitLab](https://handbook.gitlab.com/handbook/tools-and-tips/mermaid/)), you can add Mermaid diagrams by making a `mermaid` code block.\n\n````markdown\nThe following code-block will be rendered as a Mermaid diagram:\n\n```mermaid\nflowchart LR\n  A --> B\n```\n````\n\n## 4. Calling the Mermaid JavaScript API\n\nThis method can be used with any common web server like `Apache`, `IIS`, `Nginx`, and `Node Express`.\n\nYou will also need a text editing tool like `Notepad++` to generate an `html` file. It is then deployed by a web browser, i.e. `Firefox`, `Chrome`, `Safari`.\n\n```note\nInternet Explorer is not supported.\n```\n\nThe API works by pulling rendering instructions from the source `mermaid.js` in order to render diagrams on the page.\n\n### Requirements for the Mermaid API\n\nWhen writing the `html` file, we give two instructions inside the `html code` to the `web browser`:\n\na. The Mermaid code for the diagram we want to create.\n\nb. The importing of the Mermaid library through the `mermaid.esm.mjs` or `mermaid.esm.min.mjs`, and the `mermaid.initialize()` call, which dictates the appearance of diagrams and also starts the rendering process.\n\n#### Examples\n\n- This is an example of an embedded Mermaid diagram definition inside a `
`:\n\n```html\n\n  Here is a mermaid diagram:\n  
\n        graph TD\n        A[Client] --> B[Load Balancer]\n        B --> C[Server01]\n        B --> D[Server02]\n  
\n\n```\n\n```note\nEvery Mermaid chart/graph/diagram definition should have separate `
` tags.\n```\n\n- This is an example of a Mermaid import and the `mermaid.initialize()` call.\n\n```note\nA `mermaid.initialize()` call takes all the definitions contained within `
` tags and renders them into diagrams.\n```\n\n```html\n\n  \n\n```\n\n```note\nRendering in Mermaid is initialized by the `mermaid.initialize()` call. However, doing the opposite lets you control when it starts looking for `
` tags inside the web page with `mermaid.initialize()`. This is useful when you think that not all `
` tags may have loaded on the execution of `mermaid.esm.min.mjs` file.\n```\n\n`startOnLoad` is one of the parameters that can be defined by `mermaid.initialize()`\n\n| Parameter   | Description                       | Type    | Values      |\n| ----------- | --------------------------------- | ------- | ----------- |\n| startOnLoad | Toggle for Rendering upon loading | Boolean | true, false |\n\nIn this example, the `mermaidAPI` is being called through the `CDN`:\n\n```html\n\n  \n    Here is one mermaid diagram:\n    
\n            graph TD\n            A[Client] --> B[Load Balancer]\n            B --> C[Server1]\n            B --> D[Server2]\n    
\n\n    And here is another:\n    
\n            graph TD\n            A[Client] -->|tcp_123| B\n            B(Load Balancer)\n            B -->|tcp_456| C[Server1]\n            B -->|tcp_456| D[Server2]\n    
\n\n    \n  \n\n```\n\nIn this example, `mermaid.js` is referenced in `src` as a separate JavaScript file:\n\n```html\n\n  \n    \n  \n  \n    
\n            graph LR\n            A --- B\n            B-->C[fa:fa-ban forbidden]\n            B-->D(fa:fa-spinner);\n    
\n    
\n            graph TD\n            A[Client] --> B[Load Balancer]\n            B --> C[Server1]\n            B --> D[Server2]\n    
\n    \n  \n\n```\n\n##### Custom fonts\n\nMermaid comes with some default recommended fonts that you can setup on your\npage as well.\n\nSee [Usage § Fonts](../config/usage.md#fonts) for full details.\n\n```html\n\n  \n    /@fontsource/open-sans@5/400.css\" />\n    /@fontsource/open-sans@5/400-italic.css\" />\n    /@fontsource-variable/recursive@5/index.css\" />\n  \n  \n    Here is one mermaid diagram using the `redux-dark` theme:\n\n    
\n      ---\n      config:\n        theme: redux-dark\n      ---\n      flowchart\n            A[Client] --> B[Load Balancer]\n            B --> C[Server1]\n            B --> D[Server2]\n    
\n\n    \n  \n\n```\n\n## 5. Adding Mermaid as a dependency\n\nBelow are the steps for adding Mermaid as a dependency:\n\n1. Install [Node.js](https://nodejs.org/) v20 or higher (LTS recommended).\n\n```note\nTo learn more about downloading and installing `Node.js` and `npm`, visit the [npm Docs website](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm).\n```\n\n2. Add Mermaid using your preferred package manager:\n\n   **npm**\n\n   `npm install mermaid`\n\n   **yarn**\n\n   `yarn add mermaid`\n\n   **pnpm**\n\n   `pnpm add mermaid`\n\n3. To add Mermaid as a dev dependency instead, append the dev flag:\n\n   **npm:** `npm install --save-dev mermaid`\n\n   **yarn:** `yarn add --dev mermaid`\n\n   **pnpm:** `pnpm add --save-dev mermaid`\n\n## Closing note\n\n```note\nComments from Knut Sveidqvist, creator of Mermaid:\n\n- In early versions of Mermaid, the `\n```\n\n**Doing so commands the mermaid parser to look for the `
` or `
` tags with `class=\"mermaid\"`. From these tags, mermaid tries to read the diagram/chart definitions and render them into SVG charts.**\n\n**Examples can be found in** [Other examples](../syntax/examples.md)\n\n## Sibling projects\n\n- [Mermaid Live Editor](https://github.com/mermaid-js/mermaid-live-editor)\n- [Mermaid CLI](https://github.com/mermaid-js/mermaid-cli)\n- [Mermaid Tiny](https://github.com/mermaid-js/mermaid/tree/develop/packages/tiny)\n- [Mermaid Webpack Demo](https://github.com/mermaidjs/mermaid-webpack-demo)\n- [Mermaid Parcel Demo](https://github.com/mermaidjs/mermaid-parcel-demo)\n\n## Request for Assistance\n\nThings are piling up and I have a hard time keeping up. It would be great if we could form a core team of developers to cooperate\nwith the future development of mermaid.\n\nAs part of this team you would get write access to the repository and would\nrepresent the project when answering questions and issues.\n\nTogether we could continue the work with things like:\n\n- Adding more types of diagrams like mindmaps, ert diagrams, etc.\n- Improving existing diagrams\n\nDon't hesitate to contact me if you want to get involved!\n\n## Contributors\n\n
\n\n[![Good first issue](https://img.shields.io/github/labels/mermaid-js/mermaid/Good%20first%20issue%21)](https://github.com/mermaid-js/mermaid/issues?q=is%3Aissue+is%3Aopen+label%3A%22Good+first+issue%21%22)\n[![Contributors](https://img.shields.io/github/contributors/mermaid-js/mermaid)](https://github.com/mermaid-js/mermaid/graphs/contributors)\n[![Commits](https://img.shields.io/github/commit-activity/m/mermaid-js/mermaid)](https://github.com/mermaid-js/mermaid/graphs/contributors)\n\n
\n\nMermaid is a growing community and is always accepting new contributors. There's a lot of different ways to help out and we're always looking for extra hands! Look at [this issue](https://github.com/mermaid-js/mermaid/issues/866) if you want to know where to start helping out.\n\nDetailed information about how to contribute can be found in the [contribution guideline](../community/contributing.md).\n\n### Requirements\n\n- [volta](https://volta.sh/) to manage node versions.\n- [Node.js](https://nodejs.org/en/). `volta install node`\n- [pnpm](https://pnpm.io/) package manager. `volta install pnpm`\n\n### Development Installation\n\n```bash\ngit clone git@github.com:mermaid-js/mermaid.git\ncd mermaid\n# npx is required for first install as volta support for pnpm is not added yet.\nnpx pnpm install\npnpm test\n```\n\n### Lint\n\n```sh\npnpm lint\n```\n\nWe use [eslint](https://eslint.org/).\nWe recommend you to install [editor plugins](https://eslint.org/docs/user-guide/integrations) to get real time lint result.\n\n### Test\n\n```sh\npnpm test\n```\n\nManual test in browser: open `dist/index.html`\n\n### Release\n\nFor those who have the permission to do so:\n\nUpdate version number in `package.json`.\n\n```sh\nnpm publish\n```\n\nThe above command generates files into the `dist` folder and publishes them to [npmjs.com](https://www.npmjs.com/).\n\n## Security and safe diagrams\n\nFor public sites, it can be precarious to retrieve text from users on the internet, storing that content for presentation in a browser at a later stage. The reason is that the user content can contain embedded malicious scripts that will run when the data is presented. For Mermaid this is a risk, specially as mermaid diagrams contain many characters that are used in html which makes the standard sanitation unusable as it also breaks the diagrams. We still make an effort to sanitize the incoming code and keep refining the process but it is hard to guarantee that there are no loop holes.\n\nAs an extra level of security for sites with external users we are happy to introduce a new security level in which the diagram is rendered in a sandboxed iframe preventing JavaScript in the code from being executed. This is a great step forward for better security.\n\n_Unfortunately you cannot have a cake and eat it at the same time which in this case means that some of the interactive functionality gets blocked along with the possible malicious code._\n\n## Reporting vulnerabilities\n\nTo report a vulnerability, please e-mail security@mermaid.live with a description of the issue, the steps you took to create the issue, affected versions, and if known, mitigations for the issue.\n\n## Appreciation\n\nA quick note from Knut Sveidqvist:\n\n> _Many thanks to the [d3](https://d3js.org/) and [dagre-d3](https://github.com/cpettitt/dagre-d3) projects for providing the graphical layout and drawing libraries!_\n>\n> _Thanks also to the [js-sequence-diagram](https://bramp.github.io/js-sequence-diagrams) project for usage of the grammar for the sequence diagrams. Thanks to Jessica Peter for inspiration and starting point for gantt rendering._\n>\n> _Thank you to [Tyler Long](https://github.com/tylerlong) who has been a collaborator since April 2017._\n>\n> _Thank you to the ever-growing list of [contributors](https://github.com/mermaid-js/mermaid/graphs/contributors) that brought the project this far!_\n\n---\n\n_Mermaid was created by Knut Sveidqvist for easier documentation._\n\n\n\n\n# Diagram Syntax\n\nMermaid's syntax is used to create diagrams. You'll find that it is not too tricky and can be learned in a day. The next sections dive deep into the syntax of each diagram type.\n\nSyntax, together with Deployment and Configuration constitute the whole of Mermaid.\n\nDiagram Examples can be found in the [Mermaid Live Editor](https://mermaid.live), it is also a great practice area.\n\n## Syntax Structure\n\nOne would notice that all **Diagrams definitions begin** with a declaration of the **diagram type**, followed by the definitions of the diagram and its contents. This declaration notifies the parser which kind of diagram the code is supposed to generate. The only exception to this a [Frontmatter](#frontmatter-for-diagram-code) configuration.\n\nLine comments can ignore anything on the line after '%% '.\n\nUnknown words and misspellings will break a diagram, while parameters silently fail.\n\n**Example** : The code below is for an Entity Relationship Diagram, specified by the `erDiagram` declaration. What follows is the definition of the different `Entities` represented in it.\n\n```mermaid-example\nerDiagram\n          CUSTOMER }|..|{ DELIVERY-ADDRESS : has\n          CUSTOMER ||--o{ ORDER : places\n          CUSTOMER ||--o{ INVOICE : \"liable for\"\n          DELIVERY-ADDRESS ||--o{ ORDER : receives\n          INVOICE ||--|{ ORDER : covers\n          ORDER ||--|{ ORDER-ITEM : includes\n          PRODUCT-CATEGORY ||--|{ PRODUCT : contains\n          PRODUCT ||--o{ ORDER-ITEM : \"ordered in\"\n```\n\nThe [Getting Started](./getting-started.md) section can also provide some practical examples of mermaid syntax.\n\n## Diagram Breaking\n\nOne should **beware the use of some words or symbols** that can break diagrams. These words or symbols are few and often only affect specific types of diagrams. The table below will continuously be updated.\n\n| Diagram Breakers                                                                     | Reason                                                                  | Solution                                          |\n| ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------- | ------------------------------------------------- |\n| **Comments**                                                                         |                                                                         |                                                   |\n| [`%%{``}%%`](https://github.com/mermaid-js/mermaid/issues/1968)                      | Similar to [Directives](../config/directives.md) confuses the renderer. | In comments using `%%`, avoid using \"{}\".         |\n| **Flow-Charts**                                                                      |                                                                         |                                                   |\n| 'end'                                                                                | The word \"End\" can cause Flowcharts and Sequence diagrams to break      | Wrap them in quotation marks to prevent breakage. |\n| [Nodes inside Nodes](../syntax/flowchart.md?id=special-characters-that-break-syntax) | Mermaid gets confused with nested shapes                                | wrap them in quotation marks to prevent breaking  |\n\n## Mermaid Live Editor\n\nNow, that you've seen what you should not add to your diagrams, you can play around with them in the [Mermaid Live Editor](https://mermaid.live).\n\n## Configuration\n\nConfiguration is the third part of Mermaid, after deployment and syntax. It deals with the different ways that Mermaid can be customized across different deployments.\n\nIf you are interested in altering and customizing your Mermaid Diagrams, you will find the methods and values available for [Configuration](../config/setup/README.md) here. It includes themes.\nThis section will introduce the different methods of configuring the behaviors and appearances of Mermaid Diagrams.\nThe following are the most commonly used methods, and they are all tied to Mermaid [Deployment](./getting-started.md) methods.\n\n### Configuration Section in the [Live Editor](https://mermaid.live).\n\nHere you can edit certain values to change the behavior and appearance of the diagram.\n\nEach of these techniques are functionally equivalent, but better for different deployments.\n\n### [The initialize() call](./getting-started.md#_4-calling-the-mermaid-javascript-api)\n\nUsed when Mermaid is called via an API, or through a `