fix(flowchart): accept encoded inline edge labels

[buger]

What

• accept HTML-entity encoded inline pipe labels in the --|...|--> form
• keep raw square brackets inside inline edge labels invalid with FL-EDGE-LABEL-BRACKET
• add a new invalid repro for bracketed + quoted inline edge labels
• add a valid fixture for the entity-encoded form produced by autofix
• regenerate flowchart preview docs and rendered output

Verification

• npm run build
• node scripts/test-errors.js flowchart
• node scripts/test-fixes.js
• node scripts/compare-linters.js flowchart
• node scripts/generate-previews.js flowchart

[probelabs]

This PR fixes a parsing issue in flowcharts where inline edge labels containing square brackets ([]) were not accepted. The change allows these labels to be correctly parsed by handling them as HTML-entity encoded values (e.g., [ and ]).

This is achieved by updating the linkTextInline rule in the flowchart parser to recognize a broader set of tokens, enabling the correct parsing of HTML entities within edge labels. The PR also introduces an autofix capability that automatically converts invalid bracketed labels into the correct encoded format.

Files Changed Analysis

The changes are primarily focused on the flowchart parser and its associated test fixtures:

• src/diagrams/flowchart/parser.ts: The core logic change, expanding the linkTextInline parsing rule to accept more characters and HTML entities.
• scripts/test-fixes.js: A new test case is added to validate the autofix functionality for edge labels with brackets.
• Test Fixtures: New valid (edge-label-brackets-encoded-quotes.mmd) and invalid (edge-label-brackets-with-quotes.mmd) diagram fixtures have been added to test-fixtures/flowchart/ to cover this specific case. The corresponding documentation (VALID_DIAGRAMS.md, INVALID_DIAGRAMS.md), expected error lists, and rendered SVG output have been updated accordingly.

Architecture & Impact Assessment

• What this PR accomplishes: It resolves a bug that prevented the use of square brackets in flowchart edge labels like -->|label["key"]|-->. This enhances compatibility and expressiveness for flowchart diagrams.

• Key technical changes introduced: The Chevrotain parser's rule for linkTextInline is modified to accept additional tokens (Pipe, ColorValue, Ampersand, Semicolon, and various punctuation marks). This allows the lexer and parser to handle HTML-encoded entities gracefully within edge labels.

• Affected system components: The change is scoped to the flowchart diagram parser. Users creating or editing flowcharts with complex edge labels will see improved parsing and a helpful autofix suggestion for invalid syntax.

Visualization of the Fix

graph TD
    subgraph "Before"
        A["Input: --|label["key"]|-->"] --> B{Flowchart Parser};
        B --> C["Error: Invalid Token"];
    end
    subgraph "After (This PR)"
        D["Input: --|label["key"]|-->"] --> E{Autofix};
        E --> F["Encoded: --|label["key"]|-->"];
        F --> G{Flowchart Parser};
        G --> H["Success: Parsed Correctly"];
    end

Loading

Scope Discovery & Context Expansion

The impact of this PR is confined to the flowchart diagramming feature. The changes in src/diagrams/flowchart/parser.ts are specific to this diagram type and do not affect other diagram parsers. The addition of test cases and documentation updates ensures that this new behavior is well-defined and verified. The autofix feature is a key part of the solution, providing a seamless experience for users who encounter this issue.

Metadata

• Review Effort: 2 / 5
• Primary Label: bug

---

Powered by Visor from Probelabs

Last updated: 2026-05-04T10:36:06.724Z | Triggered by: pr_opened | Commit: 88867cd

💡 TIP: You can chat with Visor using /visor ask <your question>

[probelabs]

\n\n

Architecture Issues (1)

Severity	Location	Issue
🟡 Warning	src/diagrams/flowchart/parser.ts:502-515	The list of allowed tokens in the `linkTextInline` rule is growing significantly by adding many new token types to the `OR` clause. While this is a pragmatic way to support more characters in inline edge labels (like those needed for HTML entities), it follows a pattern that may become difficult to maintain. Each time a new character is needed, it's added to this list, making the rule less cohesive and harder to reason about over time. The rule is becoming a collection of miscellaneous tokens rather than representing a clear grammatical concept. 💡 Suggestion For future modifications, consider a more scalable architectural approach. This could involve defining a more generic token in the lexer that covers a wider range of non-structural characters, rather than adding many specific tokens to this parser rule. This would centralize the logic for allowed characters in the lexer and simplify the parser grammar. For the current change, the approach is acceptable as a targeted fix.

✅ Performance Check Passed

No performance issues found – changes LGTM.

✅ Quality Check Passed

No quality issues found – changes LGTM.

---

Powered by Visor from Probelabs

Last updated: 2026-05-04T10:35:55.447Z | Triggered by: pr_opened | Commit: 88867cd

💡 TIP: You can chat with Visor using /visor ask <your question>