[knsv-bot]

Use case diagrams took a single flat colour for everything. They now take colour from the kind of element.

What changed

Actors, use cases and system boundaries each read their own pair of theme variables — usecaseActorBkg/usecaseActorBorder, usecaseBkg/usecaseBorder, usecaseBoundaryBkg/usecaseBoundaryBorder — and usecaseIncludeLine/usecaseExtendLine separate the two dashed relationship kinds by hue rather than by dash pattern alone.

Why role and not rotation

In a use case diagram the shape already says what an element is — stick figure, ellipse, frame — so cycling hue across ellipses adds a second encoding carrying no information. More practically, colour keyed to type is invariant under editing: inserting one use case in the middle leaves every other element's colour alone, so diffs, documentation screenshots and visual baselines stay stable.

The palette cycle is still available as usecase.colorScheme: 'rotate', handing each element a slot from borderColorArray/bkgColorArray the way ER entities and class boxes are coloured. classDef and style keep overriding both.

Backwards compatibility

Every fallback ends at the value the stylesheet used before these tokens existed, so a theme that sets none of them renders exactly as it did. redux-color and redux-dark-color set them; no other theme changes. Only the colour themes carry a palette, so role and rotate render identically everywhere else.

Shared rendering code

Two shared shapes now stamp a colour slot — clusters.js for boundaries and squareRect.ts for a use case written in the [Rect] form. clusters.js stamps unconditionally, as it already did; a diagram opts in by emitting the matching [data-color-id] rules in its own stylesheet, which is how the existing slot-coloured diagrams already work.

squareRect stamps only where a slot was actually assigned. It backs the plain rect for the whole library, so an unconditional stamp would hand color-0 to every note, JSON table and classDb interface node — inert only for as long as no stylesheet emitting [data-color-id] … rect rules renders a bare rect, and er/styles.ts already emits that selector shape. Guarding on the slot keeps the invariant inside the one file instead of spread across the diagrams' stylesheets. Behaviour is unchanged: flowDb assigns on subgraphs, classDb on class nodes, erDb on entities — none reach this shape — while a [Rect] use case does get one and keeps its colour.

Tests

• 458 unit tests pass across the usecase, palette and colour-gate suites, including two new specs (usecaseRoleColors.spec.ts, usecase-colorIndex.spec.ts)
• e2e covers all seven themes on a diagram with no inline styles, so every colour comes from a theme variable — plus the rotate scheme on both colour themes, redux-dark-color included
• types:verify-config clean; config.type.ts regenerated from the schema

Based on claude/redux-color-default-theme rather than develop, since that is where the colour themes live.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 49ad80a1-c474-47e7-92c1-0b5de15a4978

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[changeset-bot]

🦋 Changeset detected

Latest commit: 550394a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
mermaid	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.78%. Comparing base (c76974d) to head (550394a).
⚠️ Report is 9 commits behind head on claude/redux-color-default-theme.

Additional details and impacted files

@@                         Coverage Diff                          @@
##           claude/redux-color-default-theme    #8178      +/-   ##
====================================================================
+ Coverage                             79.74%   79.78%   +0.03%     
====================================================================
  Files                                   617      617              
  Lines                                 84426    84580     +154     
  Branches                              15919    15942      +23     
====================================================================
+ Hits                                  67327    67481     +154     
  Misses                                16077    16077              
  Partials                               1022     1022              

Flag	Coverage Δ
e2e	74.00% <93.65%> (+0.04%)	⬆️
unit	77.21% <100.00%> (+0.04%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
packages/mermaid/src/diagrams/usecase/styles.ts	100.00% <100.00%> (ø)
packages/mermaid/src/diagrams/usecase/usecaseDb.ts	98.66% <100.00%> (+0.01%)	⬆️
.../src/rendering-util/rendering-elements/clusters.js	73.50% <100.00%> (+0.11%)	⬆️
...ering-util/rendering-elements/shapes/squareRect.ts	100.00% <100.00%> (ø)
...ing-util/rendering-elements/shapes/usecaseActor.ts	97.02% <100.00%> (+0.06%)	⬆️
...-util/rendering-elements/shapes/usecaseBusiness.ts	96.70% <100.00%> (+0.15%)	⬆️
...g-util/rendering-elements/shapes/usecaseEllipse.ts	88.23% <100.00%> (+1.00%)	⬆️
packages/mermaid/src/schemas/config.schema.yaml	100.00% <ø> (ø)
packages/mermaid/src/themes/theme-redux-color.js	97.87% <100.00%> (+0.06%)	⬆️
...kages/mermaid/src/themes/theme-redux-dark-color.js	97.99% <100.00%> (+0.05%)	⬆️

... and 5 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ashishjain0512]

[sisyphus-bot]

Thanks for this — it's a genuinely well-argued change. The "why role and not rotation" reasoning in the PR body isn't just post-hoc justification; it's encoded in the tests, which is exactly the right place for it. I verified the whole thing locally and it holds up.

What I checked

• 458/458 tests pass across the usecase, palette and colour-gate suites — matching the number in your description exactly.
• 2761 tests pass across flowchart, class, er, requirement and rendering-util — no regressions from the two shared-code changes.
• config.type.ts verified in sync with config.schema.yaml; docs.mts --verify clean, so docs/syntax/usecase.md really is generated.
• tsc --noEmit clean. eslint clean on all changed files (the nine warnings in clusters.js are pre-existing and not on your lines).

Security

An XSS/injection pass found no issues. Specifically confirmed:

• Every one of the four look interpolation sites in usecase/styles.ts routes through safeLook() — no raw ${options.look} survives. That matters, because look is reachable from diagram text via frontmatter and config.sanitize lets braces and quotes through.
• data-color-id is always color-${number}, written via .attr(). The new colorIndex values in usecaseDb.ts are integer counters, never derived from labels or ids.
• Palette and role-token values interpolated into declarations are the same risk class er/styles.ts and class/styles.js already carry on the base branch, and are contained by config.sanitize plus compileCSS's #svgId namespacing. Not widened here.
• No DOMPurify config changes, no new dangerous sinks.

What's working well

🎉 The tests assert on emitted selectors, not pixels. usecaseRoleColors.spec.ts catches the neo-specificity failure — a [Rect] use case silently keeping nodeBorder while its ellipse siblings take the role colour — which would be invisible in any theme where the two colours are close. That's the right call, and the docstring says so.

🎉 The backwards-compatibility story is airtight and pinned. Every chain in roleColors() (styles.ts:47-56) terminates at the exact value the stylesheet used before, and the neutral test asserts usecaseBorder is undefined and that the CSS still contains mainBkg/nodeBorder. That's the assertion that makes "no other theme changes" a fact rather than a claim.

🎉 Two counters, with the reasoning written down. usecase-colorIndex.spec.ts pins that inserting an actor cannot shift a boundary's slot. Separating the container cycle from the leaf cycle is the non-obvious part, and it's both justified and tested.

🎉 The handDrawn split. Working out that roughjs draws an outline path plus a hachure fill path indistinguishable in CSS — and that stroking both collapses a hollow actor into a disc — is the kind of thing usually discovered from a bad screenshot after merge. Gating on [data-look] and testing both directions is the right shape.

Things to address

🟡 [important] squareRect.ts:26 — the unconditional stamp in a very widely shared shape.

squareRect backs the rect shape for the whole library, so this makes a cross-file invariant load-bearing: "no other stylesheet that emits slot rules renders nodes through this shape." I checked, and it's true today — flowchart's slot rules are scoped to .cluster / .collapsed-group, and class's to .outer-path / .divider. But it's closer to the edge than the comment suggests:

• classDb.ts:837 builds interfaceNode with shape: 'rect', isGroup: false — that already flows through squareRect and now carries data-color-id="color-0" on the redux themes. It's inert only because class's selectors happen not to match a bare rect.
• er/styles.ts:55 emits [data-look][data-color-id="color-N"].node rect { stroke; fill }. That selector would match a squareRect node the moment ER (or anything reusing that pattern) gave a non-group node shape: 'rect'.

There's a one-line fix that removes the cross-diagram reasoning entirely — guard on the slot actually having been assigned:

if (node.colorIndex !== undefined) {
  const { theme, themeVariables } = getConfig();
  stampColorSlot(shapeSvg, node.colorIndex, theme, themeVariables.borderColorArray);
}

I verified this is behaviour-preserving: flowDb.ts:1231/1247 sets colorIndex on subgraphs only, classDb.ts:785 on class nodes only, erDb.ts:426 on entities only — none of which reach squareRect. Use case [Rect] nodes do get one (usecaseDb.ts:373), so they keep stamping. It'd also stop notes and JSON tables picking up a spurious color-0, which styles.ts:71-73 currently has to work around by scoping every selector to a usecase- class.

Happy to be told the unconditional form is the deliberate house style here — clusters.js does the same — in which case a pointer to that convention in the comment would be enough.

🟢 [nit] config.schema.yaml:2882 and .changeset/usecase-role-colors.md overstate the boundary tokens.

Both say role reads usecaseBoundaryBkg/usecaseBoundaryBorder. On the two themes that actually set those tokens, the slot rules in genColor ([data-look][data-color-id].system-boundary rect.boundary-body, specificity 0,4,1) outrank the role rule (.system-boundary rect.boundary-body, 0,2,1), so neither token ever paints there — theme-redux-color.js:96-97 sets two values that can't render. The .system-boundary-package-tab selector is 0,1,0, so it loses too.

Your user-facing docs get this exactly right — the table says "when not numbered" and there's a whole paragraph on the exception. It's just the schema description (which lands in the config.type.ts JSDoc and the published JSON schema) and the changeset (which becomes release-notes text) that carry the unqualified version. Worth a clause matching the docs page.

🟢 [nit] styles.ts:262/263/270 call safeLook(options.look) three times, while isHandDrawn at line 193 already derives from a fourth call. A single const look = safeLook(options.look) at the top of getStyles would read better and guarantee the four can't drift.

💡 [suggestion] RULES_PER_SLOT.usecase = 5 in paletteCssGeneration.spec.ts pins the exact block count. Your comment explains why exact beats greaterThan, and I agree — just noting it'll need a bump on every rule added or removed, which is easy to mistake for a real failure. A one-line "if you added a rule block, bump this" would save the next person a minute.

Note on merge order

Based on claude/redux-color-default-theme rather than develop, as you flagged — worth making sure that lands first, since isColorTheme, safeLook and stampColorSlot all come from there.

Nothing here is blocking. The squareRect guard is the one I'd like to see either applied or explicitly waved off; everything else is polish. Nice work.

[knsv-bot]

Applied the squareRect guard — 550394ad2.

You were right that it's closer to the edge than the comment claimed, and the classDb.ts:837 interface node is the case that made it concrete: a non-group shape: 'rect' already flowing through squareRect and picking up color-0 on the redux themes, inert only because class's selectors happen not to match a bare rect. That's an invariant living across two files with nothing holding it, so it now stamps only when a slot was assigned:

if (node.colorIndex !== undefined) {
  const { theme, themeVariables } = getConfig();
  stampColorSlot(shapeSvg, node.colorIndex, theme, themeVariables.borderColorArray);
}

Also in the commit:

• A spec pinning it. squareRect.spec.ts asserts a slotless node stays unstamped on redux-color, an assigned slot still stamps, and neither stamps on a palette-less theme. Verified it fails on the old code with expected 'color-0' to be null — the exact spurious stamp you described.
• Fixed a comment the guard made stale. usecase/styles.ts justified scoping every slot selector to a usecase- class by saying notes and JSON tables are stamped color-0. They no longer are, and the scoping now reads as narrowing rather than as the thing making the rules miss.
• PR body corrected. It claimed both shared shapes stamp unconditionally; only clusters.js does now, and the reasoning for the split is written out.

Left clusters.js unconditional — its callers are containers, and the diagrams reaching it without a slot (state, block, class namespaces) are genuinely inert there.

Verification: 565 tests pass across the usecase and shape suites; 6121 across usecase, palette, common, rendering-util, class, er and flowchart. tsc --noEmit and eslint clean.

The three nits are untouched for now — say the word if you want the schema/changeset boundary-token clause, the single safeLook call, or the RULES_PER_SLOT note in this PR rather than a follow-up.

[ashishjain0512]

[sisyphus-bot]

Approved. The squareRect guard in 550394ad2 resolves the one thing I'd flagged as needing a decision, and it's a better fix than the one-liner I suggested.

Re-verified on 550394ad2

• 461/461 usecase + palette + colour-gate + shape tests pass (458 before, plus your three new ones).
• 2755 tests pass across flowchart, class, er, requirement and rendering-util — no regression from the guard.
• tsc --noEmit clean; eslint clean on all three touched files.
• The new spec earns its place. I reverted the guard on a scratch copy and re-ran squareRect.spec.ts: it fails with expected 'color-0' to be null, exactly as you described. That's the assertion doing real work, not restating the implementation.

🎉 You went further than the ask on two counts, and both were the right call. Adding the spec turns "this is safe today" into something the test suite holds — which was the actual complaint, since the problem was never the behaviour but that nothing was pinning it. And catching that the guard invalidated the justification in styles.ts:67-70 is the part that usually gets missed: a comment explaining why selectors are scoped, resting on a fallback that no longer happens, would have quietly misled the next reader. Rewriting it so the scoping reads as narrowing rather than as load-bearing is exactly right.

Leaving clusters.js unconditional is fine by me — the stamp there sits inside usecaseSystemBoundary, so it never sees a non-usecase container in the first place. Narrower than your justification needed to be.

On the three nits

Your call entirely, and none of them hold up the merge. If you only do one, I'd do the changeset clause — that text becomes release-notes copy, and as written it tells users usecaseBoundaryBkg/usecaseBoundaryBorder apply under role when on the two themes that ship those tokens the slot rules outrank them and they never paint. It's a one-clause edit, and the wording already exists on your docs page ("when not numbered"). The schema description carries the same claim into the generated config.type.ts JSDoc, so it's the same edit twice.

The single safeLook call and the RULES_PER_SLOT note are genuine polish — happy to see them in a follow-up or dropped.

Nice work on this one. The reasoning is documented where it needs to be, the tests assert on the things that fail silently, and the backwards-compatibility story is pinned rather than asserted.

[argos-ci]

The latest updates on your projects. Learn more about Argos notifications ↗︎

Build	Status	Details	Updated (UTC)
default (Inspect)	⚠️ Changes detected (Review)	276 changed, 1 added	Aug 31, 2026, 11:20 AM