fix(c4): allow boundaries as relationship endpoints (#4864)

[filipsajdak]

Summary

A Rel (or BiRel/Rel_Back etc.) that referenced a boundary alias threw
C4 rel "<from>" -> "<to>" references an unknown shape, because the renderer's endpoint
lookup (getC4Shape) only searched the shape array and never the boundaries array.

Relating to/from a boundary is valid C4 (e.g. a system inside a boundary talking to an
external boundary), so this widens getC4Shape to fall back to boundaries. Boundaries already
carry the x/y/width/height geometry the renderer uses to compute relationship intersection
points (they are populated by drawInsideBoundary/drawBoundary before drawRels runs), so
no further changes to the geometry math are needed.

Resolves #4864.

Changes

• c4Db.ts: getC4Shape resolves boundary aliases as a fallback after shapes.
• c4Types.ts: new C4Element = C4Shape | C4Boundary alias (shapes and boundaries share the
  relationship-endpoint geometry) - avoids any type assertions.
• c4Renderer.ts: widen getIntersectPoint/getIntersectPoints/drawRels endpoint types to
  C4Element.
• Regression test in parser/c4Boundary.spec.ts.

Test

• pnpm vitest run packages/mermaid/src/diagrams/c4 - 127 passing (incl. the new test).
• Verified the previous behaviour threw references an unknown shape and now renders.

🎉 Fixes C4 relationship endpoints so boundary aliases resolve correctly. This removes the “references an unknown shape” error for Rel, BiRel, and Rel_* aliases.

🎉 Updates getC4Shape to resolve both shapes and boundaries. Generalizes renderer intersection logic with the shared C4Element type and adds boundary geometry support.

🎉 Adds database and Cypress regression coverage for relationships that target boundary aliases. Includes a changeset entry.

[changeset-bot]

🦋 Changeset detected

Latest commit: 6b79518

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

This PR includes changesets to release 1 package

Name	Type
mermaid	Patch

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

[netlify]

✅ Deploy Preview for mermaid-js ready!

Name	Link
🔨 Latest commit	6b79518
🔍 Latest deploy log	https://app.netlify.com/projects/mermaid-js/deploys/6a84130f41cd9022f293c7e3
😎 Deploy Preview	https://deploy-preview-7874--mermaid-js.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[pkg-pr-new]

Open in StackBlitz

@mermaid-js/examples

npm i https://pkg.pr.new/@mermaid-js/examples@7874

mermaid

npm i https://pkg.pr.new/mermaid@7874

@mermaid-js/layout-elk

npm i https://pkg.pr.new/@mermaid-js/layout-elk@7874

@mermaid-js/layout-tidy-tree

npm i https://pkg.pr.new/@mermaid-js/layout-tidy-tree@7874

@mermaid-js/mermaid-zenuml

npm i https://pkg.pr.new/@mermaid-js/mermaid-zenuml@7874

@mermaid-js/parser

npm i https://pkg.pr.new/@mermaid-js/parser@7874

@mermaid-js/tiny

npm i https://pkg.pr.new/@mermaid-js/tiny@7874

commit: 6b79518

[codecov]

Codecov Report

❌ Patch coverage is 44.44444% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 77.56%. Comparing base (3d521b1) to head (6b79518).
⚠️ Report is 54 commits behind head on develop.

Files with missing lines	Patch %	Lines
packages/mermaid/src/diagrams/c4/c4Renderer.ts	33.33%	10 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #7874      +/-   ##
===========================================
- Coverage    77.61%   77.56%   -0.05%     
===========================================
  Files          568      572       +4     
  Lines        74992    75290     +298     
  Branches     12690    12721      +31     
===========================================
+ Hits         58202    58402     +200     
- Misses       15796    15884      +88     
- Partials       994     1004      +10     

Flag	Coverage Δ
e2e	70.71% <83.33%> (+0.15%)	⬆️
unit	74.79% <38.88%> (-0.26%)	⬇️

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

Files with missing lines	Coverage Δ
packages/mermaid/src/diagrams/c4/c4Db.ts	63.40% <100.00%> (+0.10%)	⬆️
packages/mermaid/src/diagrams/c4/c4Renderer.ts	80.73% <33.33%> (-1.35%)	⬇️

... and 13 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.

[argos-ci]

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

Build	Status	Details	Updated (UTC)
default (Inspect)	👍 Approved by pbrolin47	1 changed	Aug 11, 2026, 2:41 PM

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

This PR enables C4 relationships to target boundary aliases. Alias lookup resolves shapes or boundaries, renderer endpoint geometry supports both types, and regression coverage validates parsing and rendering.

Changes

C4 boundary relation endpoint fix

Layer / File(s)	Summary
Boundary alias resolution and type contract packages/mermaid/src/diagrams/c4/c4Db.ts, packages/mermaid/src/diagrams/c4/c4Types.ts	getC4Shape falls back to boundaries, and C4Element represents shape or boundary endpoints.
Renderer intersection helpers use C4Element packages/mermaid/src/diagrams/c4/c4Renderer.ts	Boundary intersection geometry is assigned, relationship helpers accept both endpoint types, and unresolved-endpoint errors mention boundaries.
Regression coverage and release entry packages/mermaid/src/diagrams/c4/parser/c4Boundary.spec.ts, cypress/integration/rendering/c4/c4.spec.js, .changeset/c4-boundary-relation-endpoint.md	Tests boundary alias lookup and boundary-to-system rendering, while documenting the patch release.

Estimated code review effort: 2 (Simple) | ~15 minutes

Possibly related PRs

• mermaid-js/mermaid#7842: Updates C4 relationship endpoint geometry that this PR extends to boundaries.
• mermaid-js/mermaid#7883: Modifies C4 relationship rendering and endpoint handling.
• mermaid-js/mermaid#7991: Modifies C4 relationship intersection handling and boundary endpoint types.

Suggested labels: Graph: C4

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly and concisely describes the main fix: allowing C4 boundaries as relationship endpoints.
Description check	✅ Passed	The description explains the bug, implementation, tests, issue reference, and behavior change; missing template checklist items are non-critical.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.}

[coderabbitai]

🧹 Nitpick comments (1)

packages/mermaid/src/diagrams/c4/c4Renderer.ts (1)

535-539: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Error message no longer accurate.

Now that endpoints can resolve to boundaries too, the thrown message still says references an unknown shape even when a boundary alias is simply missing/misspelled. Consider wording it generically (e.g., "unknown shape or boundary") for clearer diagnostics.

✏️ Suggested tweak

-      throw new Error(`C4 rel "${rel.from}" -> "${rel.to}" references an unknown shape`);
+      throw new Error(`C4 rel "${rel.from}" -> "${rel.to}" references an unknown shape or boundary`);

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/mermaid/src/diagrams/c4/c4Renderer.ts` around lines 535 - 539, The
error text in c4Renderer’s relationship endpoint validation is now too specific
because rel.from and rel.to can resolve to either shapes or boundaries. Update
the throw in the getC4ShapeObj-based check so the message in c4Renderer refers
generically to an “unknown shape or boundary” instead of only an unknown shape,
while keeping the same validation logic for missing endpoints.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@packages/mermaid/src/diagrams/c4/c4Renderer.ts`:
- Around line 535-539: The error text in c4Renderer’s relationship endpoint
validation is now too specific because rel.from and rel.to can resolve to either
shapes or boundaries. Update the throw in the getC4ShapeObj-based check so the
message in c4Renderer refers generically to an “unknown shape or boundary”
instead of only an unknown shape, while keeping the same validation logic for
missing endpoints.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 0dd6831f-37a8-47bf-b0a1-24d727f30659

📥 Commits

Reviewing files that changed from the base of the PR and between 0d1ee0a and af09382.

📒 Files selected for processing (5)

• .changeset/c4-boundary-relation-endpoint.md
• packages/mermaid/src/diagrams/c4/c4Db.ts
• packages/mermaid/src/diagrams/c4/c4Renderer.ts
• packages/mermaid/src/diagrams/c4/c4Types.ts
• packages/mermaid/src/diagrams/c4/parser/c4Boundary.spec.ts

[filipsajdak]

Hi @knsv @sidharthv96 - friendly nudge on this one. CI is green; the only outstanding check is argos (visual-diff), which is still queued rather than failed. No merge conflicts, no open threads. Whenever you have a moment, a review would be very welcome.

The full staged plan for this C4 modernization effort - what's landed, what's open, and the recommended merge order - is kept up to date in #7849 if you'd like the full picture.

Thanks for your time!

[filipsajdak]

Re CodeRabbit's wording nitpick on the unresolved-endpoint error message ("unknown shape" -> "unknown shape or boundary"): already addressed, in a927a4309 (fix(c4): mention boundaries in the unknown-endpoint error message), which landed shortly after the review. No other feedback outstanding on this PR.

[filipsajdak]

The Argos build for this PR is stuck in "Build is queued" - and it is reproducible, not transient. The previous head's build sat queued for 9 days, and after refreshing the branch from develop today the new build (#7557) is stuck the same way, so I dug into the e2e logs.

Root cause (a detect-scope + parallel-upload interaction in .github/workflows/e2e.yml):

1. detect-scope correctly narrows this C4-only PR to the C4 specs, so the run produces just 30 screenshots -> 3 composite sheets ([argos-batch] 30 screenshots -> 3 sheets), which all land in a single leaf directory.
2. The upload step round-robins leaf directories into K=5 buckets and skips empty ones ([ ${#globs[@]} -eq 0 ] && continue), but every upload still declares --parallel-total "$K". This run performed exactly one upload ("Build created" appears once in the log) while promising Argos 5 shards, so the build waits forever for the other 4. A full-suite run (e.g. on feat(c4): migrate C4 element shapes to the unified shapes #7842: 3063 screenshots -> 272 sheets) fills all 5 buckets and finalizes fine, which is why only scope-reduced PRs hang.

Suggested fix: partition the globs into buckets first, drop the empty ones, and pass the actual bucket count as --parallel-total (equivalently K = min(5, <number of leaf dirs>)). Happy to send that as a small PR if you'd like - otherwise flagging it for you since this bites any PR whose scoped run has fewer than 5 screenshot directories.

cc @aloisklink @sidharthv96 (authors of the recent upload-batching changes)

[filipsajdak]

This just reproduced on #7972 (a cypress-spec-only PR): its scoped run produced 356 screenshots -> 30 sheets in a single leaf directory, so again exactly one upload ran against --parallel-total 5, and Argos build 7561 is now stuck in "Waiting for screenshots" the same way as this PR's build. Second confirmed case, so any scope-narrowed PR is affected - the offer to send the small workflow fix still stands.

[aloisklink]

Hi @filipsajdak, I've also got a fix for the stalling @argos-ci issue (see #7948), but I'm still waiting for another maintainer to review and merge that PR.

[filipsajdak]

Thanks @aloisklink - #7948 is a cleaner fix than my suggestion (reverting the on-by-default e2e scoping rather than patching --parallel-total), so I'll drop my offer and defer to it. Once #7948 lands it should unblock the stuck argos builds here and on #7970/#7972 too. Appreciate you picking it up!

[filipsajdak]

Merged current develop in to pick up @aloisklink's #7948, which landed on 28 July.

That should clear the Argos build that has been stuck at "Waiting for status to be reported - Build is queued" on this PR. The cause was the diagram-scoped e2e run: the upload step round-robins leaf screenshot directories into 5 buckets, skips the empty ones, but still declares --parallel-total 5, so a scope-reduced run (this PR narrowed to a single C4 shard) left Argos waiting forever for shards that were never coming. #7948 reverts scoping to off-by-default, so this run should fill the matrix and finalize normally.

No code change in this push - just the merge. The fix itself is unchanged: boundary aliases are accepted as Rel endpoints, with the unknown-endpoint error message mentioning boundaries.

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

packages/mermaid/src/diagrams/c4/c4Renderer.ts (1)

254-265: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Add a renderer-level regression assertion.

The supplied test only checks yy.getC4Shape(...); it does not exercise drawBoundary/drawRels, where boundary.intersect is installed and consumed. Add a render test for Rel(b1, SystemAA, ...) so geometry or coordinate regressions fail in CI.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/mermaid/src/diagrams/c4/c4Renderer.ts` around lines 254 - 265, Add a
renderer-level regression test that renders a C4 relationship using Rel(b1,
SystemAA, ...), exercising the drawBoundary/drawRels path where
boundary.intersect is installed and consumed. Assert the rendered relationship
geometry or output so coordinate regressions fail, rather than only testing
yy.getC4Shape(...).

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/mermaid/src/diagrams/c4/c4Renderer.ts`:
- Line 365: Update the missing-intersection error in getIntersectPoint to refer
to a “shape or boundary” or “C4 element” instead of “C4 shape,” matching the
C4Element parameter and preserving the existing error behavior.

---

Nitpick comments:
In `@packages/mermaid/src/diagrams/c4/c4Renderer.ts`:
- Around line 254-265: Add a renderer-level regression test that renders a C4
relationship using Rel(b1, SystemAA, ...), exercising the drawBoundary/drawRels
path where boundary.intersect is installed and consumed. Assert the rendered
relationship geometry or output so coordinate regressions fail, rather than only
testing yy.getC4Shape(...).

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 9dee5bc4-0b84-43f2-b633-fe4b4f67a73c

📥 Commits

Reviewing files that changed from the base of the PR and between a927a43 and de5c859.

📒 Files selected for processing (2)

• packages/mermaid/src/diagrams/c4/c4Renderer.ts
• packages/mermaid/src/diagrams/c4/c4Types.ts

[pbrolin47]

Hi @filipsajdak ,
Thanks for the recent work in this PR. Tried the local branch and rendered the digram in #4864 and it rendered as expected, which is all good:

After running a review, some feedback:

[sisyphos-bot]

---

What's Working Well

🎉 Root cause identified and addressed precisely. The fix is exactly where it needs to be: getC4Shape falls back to boundaries via ?? (not ||, which would miss falsy-but-valid boundary objects).
Clean and minimal.

🎉 C4Element type alias avoids type assertions. Using C4Shape | C4Boundary as a named type alias for the union is much cleaner than sprinkling as unknown as C4Shape casts. The renderer functions now
express their actual contract in the type signature.

🎉 boundary.intersect closure is placed correctly. It's assigned after boundary.x/y/width/height are set and before any subsequent code that might call drawRels. The closure captures the mutable
object by reference, so it reads the final geometry at call time — correct.

🎉 Center-point math is correct. intersect.rect expects center coordinates + dimensions; the conversion from C4's top-left origin is right: x: boundary.x + boundary.width / 2.

🎉 Excellent PR description. The summary explains the root cause, the fix, and the geometry reasoning clearly. The changeset is present, properly marked patch, and linked to the issue.

🎉 Regression test captures the fix. c4Boundary.spec.ts verifies that getC4Shape('b1') resolves a boundary alias after parsing, SystemAA still resolves as a shape, and missing returns undefined. All
three assertions are meaningful.

---

Things to Address

🟡 [important] Missing Cypress E2E test for the renderer path — c4Boundary.spec.ts covers the DB layer (getC4Shape lookup), but c4Renderer.ts now adds new rendering logic in drawBoundary (the
boundary.intersect closure). Per the project convention (CLAUDE.md (https://github.com/mermaid-js/mermaid/blob/develop/CLAUDE.md): "Any change that affects rendered SVG output. This is the primary
verification method for visual correctness"), a Cypress test is needed.

The test doesn't need to be elaborate — a minimal diagram with a boundary-to-shape Rel would be sufficient:

// cypress/integration/rendering/c4.spec.js
it('renders a Rel targeting a boundary alias', () => {
imgSnapshotTest(C4Context Container_Boundary(banking, "Internet Banking") { Container(spa, "SPA", "JavaScript", "Front-end") } System_Ext(email, "Email System", "External mail") Rel(banking, email, "Forwards alerts") );
});

This gives visual proof the relationship line renders and prevents future regressions — before this fix, that diagram would throw instead of rendering.

---

Minor Notes (non-blocking)

🟢 Unit test assertion could confirm boundary type. expect(yy.getC4Shape('b1')).toMatchObject({ alias: 'b1' }) verifies the alias is found, but doesn't prove it came from the boundaries array rather
than a shape. Adding type: { text: 'Container_Boundary' } (or similar boundary-specific field) would make the test intent explicit and prevent getC4Shape from silently finding a shape with the same
alias in future refactors.

🟢 C4Shape lacks a typed intersect? declaration. C4Boundary now has intersect?: (point: C4Point) => C4Point as a proper named field, but C4Shape only has it accessible through the [key: string]:
unknown index signature. For C4Element = C4Shape | C4Boundary, TypeScript resolves .intersect as unknown (since unknown from the shape side absorbs the union). Adding intersect?: (point: C4Point) =>
C4Point to C4Shape would make both sides of the union fully typed. (This is a pre-existing gap, not introduced by this PR — but since you're already touching these types, it would be a natural time
to close it.)

---

Security

No security concerns. The fix widens a lookup function and adds a geometry closure — no user-supplied text flows to new unsanitized paths. The alias field being found in boundaries vs. shapes
doesn't open any new injection surface.

---

[filipsajdak]

Thanks @pbrolin47 - and thanks especially for rendering the actual #4864 diagram rather than taking the unit tests' word for it.

🟡 Missing Cypress E2E test - added. C4.9 should render a relationship whose endpoint is a boundary, essentially your diagram:

C4Context
title Relationship to a boundary (#4864)

Container_Boundary(banking, "Internet Banking") {
  Container(spa, "SPA", "JavaScript", "Front-end")
}
System_Ext(email, "Email System", "External mail")

Rel(banking, email, "Forwards alerts")

You are right that this needed renderer-level coverage, and more so than the review knew: the boundary.intersect closure it exercises is not part of the original fix at all. It came in when I merged develop after #7842 landed - that PR made getIntersectPoint delegate to each shape's own intersect and throw when there is none, which is safe only while every endpoint is a unified-drawn shape. Boundaries are drawn by the legacy path and had none, so the two changes together would have thrown for exactly the case this PR adds. Before this test, nothing in CI would have caught that.

🟢 Unit assertion - strengthened, but a different way than suggested. type: { text: 'Container_Boundary' } would not actually discriminate: a boundary's type.text comes out as 'system', which is the same value a System(...) shape carries, and there is a standing TODO: Why is this 'system' instead of 'boundary'? about it a few lines up in that same spec. So it would have passed even if getC4Shape returned a shape.

Asserting object identity gets at what you actually wanted:

const boundary = yy.getBoundaries().find((b) => b.alias === 'b1');
expect(yy.getC4Shape('b1')).toBe(boundary);
expect(yy.getC4Shape('SystemAA')).toMatchObject({
  alias: 'SystemAA',
  typeC4Shape: { text: 'system' },
});

That proves the endpoint came from the boundaries array specifically, and the typeC4Shape assertion pins the shape lookup to the shape path.

🟢 C4Shape lacks a typed intersect? - this one is already the case, so nothing to change: C4Shape declares intersect?: (point: C4Point) => C4Point at c4Types.ts:59 (added by #7842), and I added the matching declaration to C4Boundary, now at line 91. Both sides of C4Element are fully typed - .intersect resolves to the function type, not unknown. I suspect the review was reading the pre-#7842 file.

127 c4 unit tests pass, tsc clean.

[filipsajdak]

Rebased onto current develop and tidied the history: 9 commits -> 1. The change itself is unchanged, and your review comments are untouched, @pbrolin47.

This one needed it more than the others. Five of those nine were Merge remote-tracking branch 'upstream/develop' commits, and - worse - the boundary intersect implementation was living inside one of those merge commits, where it was effectively invisible to review. It is now part of the single commit, described in the message.

The tree is byte-identical to the previous head: the commit was rebuilt from that exact tree rather than replayed, and git diff <old head> <new head> was empty before pushing. 127 c4 unit tests pass, tsc clean.

Still 6 files, +63/-6 - the db fallback, the C4Element union, the boundary rectangle intersect, and both tests.

[filipsajdak]

The Cypress test I added on 2026-08-01 was failing, and I should have caught that before saying it was done - I ran the unit suites but never checked the e2e result, so e2e (8) has been red since. Sorry for the noise, @pbrolin47. Fixed now, and rebased onto current develop.

It was my test, not the fix - but the reason is worth knowing, because it is a real bug in develop:

Lexical error on line 2. Unrecognized text.
...ship to a boundary (#4864)Container_Bo
-----------------------^

I had written title Relationship to a boundary (#4864). A # anywhere in a C4 title breaks parsing - it swallows the newline and the statements that follow. Verified through mermaid.parse(), which is the same path the rendering test uses:

title	result
title Relationship to a boundary	parses
title Relationship to a boundary (4864)	parses
title Relationship to a boundary #4864	lexical error
title Relationship to a boundary (#4864)	lexical error
title issue#4864	lexical error

Parentheses are fine; # is not. The cause is c4Diagram.jison:87, where the title token is "title"\s[^#\n;]+ - the character class excludes #, so the token stops there and the lexer is left on text that matches nothing. C4's comment syntax is %%, and this grammar has no # comment rule at all, so the exclusion looks vestigial.

That affects anyone writing title Sprint #3, so I filed it separately as #8030 rather than bundling a grammar change into this PR - it is unrelated to boundaries and predates this branch. Worth noting sequenceDiagram and journey carry the same character-class exclusion yet still parse a # title, so C4 is specifically the one that hard-fails; details and a per-diagram matrix are in the issue.

Here the #4864 was only decoration in a test title, so it is simply dropped. The test still does exactly what you asked for: renders a relationship whose endpoint is a boundary, which is the path that would have thrown before this fix.

Still one commit, 6 files, +87/-7. c4 unit suite 127/127, rendering-util 515 passing, tsc clean, now on top of develop@3d521b1ee (which includes the fastdom label-measurement change - no effect on the c4 suites).

[pbrolin47]

Hi @filipsajdak
Thanks for fixing the failing e2e, and I think it's a good praxis to handle found issues not directly related to a PR in a separate issue as you did with #8030.

[filipsajdak]

Thanks @pbrolin47.

For the record, all three points from your 2026-07-31 review are now addressed:

1. Cypress E2E for the renderer path: C4.9 in cypress/integration/rendering/c4/c4.spec.js, a Rel whose source is a boundary alias. Green.

2. Unit test proving the lookup really hit a boundary: done via object identity rather than a type field.

   const boundary = yy.getBoundaries().find((b) => b.alias === 'b1');
   expect(yy.getC4Shape('b1')).toBe(boundary);

   A same-alias shape cannot satisfy that.

3. Typed intersect? on both sides of C4Element: C4Shape picked one up in feat(c4): migrate C4 element shapes to the unified shapes #7842, so I added the matching declaration to C4Boundary. The field no longer resolves through the index signature.

CI is green, argos included. The netlify/mermaid-js/deploy-preview failure is not from this PR: deploy previews are failing repo-wide right now (same on #8031, #8032, #8034).

Anything else you would like changed before this goes in?

[pbrolin47]

Hi @filipsajdak
I think the PR LGTM, and agree the failing checks does not seem to relate to this PR. I want to discuss with other maintainers how-to proceed with this. It's on my agenda.

[filipsajdak]

Thanks! To save you time in that discussion, here is the evidence that the failing checks are repo-wide rather than from this PR.

All four failures here are Netlify: netlify/mermaid-js/deploy-preview plus its Header rules, Pages changed and Redirect rules sub-checks. Checking netlify/mermaid-js/deploy-preview on the most recent open PRs from other authors, just now:

PR	deploy-preview
#8047	FAILURE
#8046	FAILURE
#8045	FAILURE
#8044	FAILURE
#8038	FAILURE
#8034	FAILURE
#8032	FAILURE
#8031	FAILURE

Eight out of eight, none of them mine. It started around 2026-08-06: PRs from a few days earlier still show it green, so it looks like a Netlify-side or build-config change rather than anything in a diff.

Everything else on this PR is green, including argos and the full 8-shard e2e, and the diff touches no docs and nothing the Netlify build consumes.

Happy to open a separate issue for the Netlify breakage if that would help - it is affecting every open PR, so it is worth tracking on its own rather than per-PR.

[filipsajdak]

Force-pushed to remove the Co-Authored-By: Claude / Claude-Session: trailers from the commit message. Message-only rewrite - the tree is byte-identical, verified with git diff <old-tip> <new-tip> returning empty, so the fix itself is unchanged and any review you have already done still applies.

This was raised in review on #7859, citing the project's own rule against tagging commits as AI-authored. Since this repo merges rather than squashes, the message would land on develop verbatim, so it had to be corrected before merge rather than after.

Nothing else about the PR moved: same single commit, same diff, same tests.

[pbrolin47]

Hi @filipsajdak,
Sorry for the late response. Was OOO last week. Regarding the Netlify problems, after discussion with other maintainers I got advised to re-run the deployment without cache from lates branch commit, but I needed some permissions to be able to do that. Not this PR is all good