AV0125: Consider duplicating simple logic across modules to reduce coupling by dennisdoomen · Pull Request #369 · dennisdoomen/CSharpGuidelines

dennisdoomen · 2026-03-25T14:11:36Z

This PR updates guideline AV1580.

It was split out of #298 so the change can be reviewed independently.

Files:

_rules/1580.md

Part of the replacement for #298.

Split from #298. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

bkoelman · 2026-04-14T02:16:24Z

+**Note:** 
+Taking a dependency on a source-only package like [Reflectify](https://github.com/dennisdoomen/reflectify?tab=readme-ov-file#readme) or [Pathy](https://github.com/dennisdoomen/pathy?tab=readme-ov-file#readme), or putting your utility code in a source-only package also avoids coordinated updates. But duplication may still be the safer choice. 


I'm not sure if this is good practice for reducing duplication. Source-only packages are typically used to trade a runtime dependency for a dev-only dependency. Just linking in shared files is an option, too. Or using git submodules. There are many ways to share code. So perhaps leave this note out entirely?

I'm trying to promote using those kinds of packages, as they've proven to be very useful in many of my client projects.

If I read the full rule, it basically states to avoid duplicating code. However, if small, duplication is better than introducing a dependency. Then why would we advice to introduce a (source-only package) dependency at the end?

While there are use cases for doing so, it seems to contradict the purpose of this rule. I suppose it could be added to 1578, which is about organizing dependencies. Though I should note that promoting personal projects in the rule definitions makes this repo feel like an advertisement rather than independent guidance.

If I read the full rule, it basically states to avoid duplicating code. However, if small, duplication is better than introducing a dependency. Then why would we advice to introduce a (source-only package) dependency at the end?

I'm going to merge this in the paragraph "For complex or domain-critical logic" that mentions using a shared library. I'll also mention a shared file as an option. I don't think it makes sense to add that to AV1578.

Source-only packages are typically used to trade a runtime dependency for a dev-only dependency.

It's a huge distinction. A source-only package doesn't come with the pains of conflicting dependencies like a binary package has.

Though I should note that promoting personal projects in the rule definitions makes this repo feel like an advertisement rather than independent guidance.

This repo is part of my profile, so it is not independent guidance. It's my perspective on high-quality code, complemented with your excellent and critical eye.

If I read the full rule, it basically states to avoid duplicating code. However, if small, duplication is better than introducing a dependency. Then why would we advice to introduce a (source-only package) dependency at the end?

I'm going to merge this in the paragraph "For complex or domain-critical logic" that mentions using a shared library. I'll also mention a shared file as an option. I don't think it makes sense to add that to AV1578.

Sounds reasonable.

Source-only packages are typically used to trade a runtime dependency for a dev-only dependency.

It's a huge distinction. A source-only package doesn't come with the pains of conflicting dependencies like a binary package has.

Yes, that's a good point.

Though I should note that promoting personal projects in the rule definitions makes this repo feel like an advertisement rather than independent guidance.

This repo is part of my profile, so it is not independent guidance. It's my perspective on high-quality code, complemented with your excellent and critical eye.

Thanks for the compliment. Independent guidance wasn't the right wording. I'm just pointing out that (the appearance of) advertising in rules may be perceived negatively by external users who have an interest in this project. It's a sensitive topic, given the history of SponsorLink and various OSS projects going commercial. So I'd say better safe than sorry, as the "sorry" later isn't generally accepted (trust was already broken). On the other hand, if you need it for personal reasons, that's your choice. Something to consider.

Co-authored-by: Bart Koelman <10324372+bkoelman@users.noreply.github.com>

Copilot

Pull request overview

This PR updates the AV0125 guideline text to better explain when DRY should (and should not) be applied across module/service boundaries, emphasizing that small duplication can be preferable to creating hard-to-manage coupling.

Changes:

Rewords AV0125 title and expands the guidance around “DRY within boundaries” vs. cross-boundary coupling.
Adds a concrete example and a checklist of situations where duplication is the simpler choice.
Adds references to “source-only packages” and external example repositories.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

 ---
 rule_id: 0125
 rule_category: general
-title: Don't Repeat Yourself (DRY) within boundaries
+title: Don't Repeat Yourself (DRY), but only within boundaries
 severity: 1


 severity: 1
 ---
-Avoid duplicating logic, knowledge or decisions within a component, service or [bounded context](https://martinfowler.com/bliki/BoundedContext.html). When the same logic exists in multiple places, a change in requirements requires multiple edits, and inconsistencies creep in over time. Use the [Rule of Three](https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming)) as a practical guide: refactor duplication after the third occurrence.
+Avoid duplicating logic, knowledge or decisions within a component, service or [bounded context](https://martinfowler.com/bliki/BoundedContext.html). When the same logic exists in multiple places, a change in requirements requires multiple edits, and inconsistencies creep in over time. 


+private static bool IsValidEmail(string value)
+    => value.Contains('@') && value.Contains('.');
+
+// In Module B — a small duplication is fine here
+private static bool IsValidEmail(string value)
+    => value.Contains('@') && value.Contains('.');


+- Logic that is stable and unlikely to change frequently.
+- Logic that doesn't carry domain meaning that must remain consistent.
+
+For complex or domain-critical logic that must be consistent everywhere, a shared library is still the right choice. But always consider the [Rule of Three](https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming)) as a practical guide: refactor duplication after the third occurrence and you've identified a real pattern. Also consider a source-only package as it avoids the binary dependencies normal packages have. Check out [Reflectify](https://github.com/dennisdoomen/reflectify?tab=readme-ov-file#readme) or [Pathy](https://github.com/dennisdoomen/pathy?tab=readme-ov-file#readme) for practical examples of that.


+- Logic that is stable and unlikely to change frequently.
+- Logic that doesn't carry domain meaning that must remain consistent.
+
+For complex or domain-critical logic that must be consistent everywhere, a shared library is still the right choice. But always consider the [Rule of Three](https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming)) as a practical guide: refactor duplication after the third occurrence and you've identified a real pattern. Also consider a source-only package as it avoids the binary dependencies normal packages have. Check out [Reflectify](https://github.com/dennisdoomen/reflectify?tab=readme-ov-file#readme) or [Pathy](https://github.com/dennisdoomen/pathy?tab=readme-ov-file#readme) for practical examples of that.


+For complex or domain-critical logic that must be consistent everywhere, a shared library is still the right choice. But always consider the [Rule of Three](https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming)) as a practical guide: refactor duplication after the third occurrence and you've identified a real pattern. Also consider a source-only package as it avoids the binary dependencies normal packages have. Check out [Reflectify](https://github.com/dennisdoomen/reflectify?tab=readme-ov-file#readme) or [Pathy](https://github.com/dennisdoomen/pathy?tab=readme-ov-file#readme) for practical examples of that.

 **Exception:**  
 Duplication in tests is often beneficial as it will make the tests easier to understand without the need to dig into all kinds of shared helper methods. 


* Make sure the site works properly with Ruby 3.1 * Add AV0100: Understand the boundaries of your codebase (#300) * Add AV0105: Use design patterns to communicate intent (#301) * Add AV0110: Prefer composition over class inheritance (#302) * Add AV0110 guideline Split from #298. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update _rules/0110.md Co-authored-by: Bart Koelman <10324372+bkoelman@users.noreply.github.com> --------- Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Bart Koelman <10324372+bkoelman@users.noreply.github.com> * Add AV0112: Apply the Principle of Least Surprise (#303) * Add AV0115 guideline (#304) Split from #298. Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Add AV0120: You Ain't Gonna Need It (YAGNI) (#305) * Add AV0120 guideline Split from #298. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update _rules/0120.md Co-authored-by: Bart Koelman <10324372+bkoelman@users.noreply.github.com> * Update _rules/0120.md Co-authored-by: Bart Koelman <10324372+bkoelman@users.noreply.github.com> * Update _rules/0120.md Co-authored-by: Bart Koelman <10324372+bkoelman@users.noreply.github.com> --------- Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Bart Koelman <10324372+bkoelman@users.noreply.github.com> * Add AV0125: Don't Repeat Yourself (DRY) within boundaries (#306) * Update explanation of code boundaries and coupling Clarified the reasoning for preventing unnecessary coupling between components. * Add AV0135 guideline (#308) Split from #298. Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Add AV1582 guideline (#318) Split from #298. Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Add AV1608 guideline (#323) Split from #298. Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Add AV1610 guideline (#324) Split from #298. Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update AV1708 guideline (#372) Split from #298. Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update AV1562 guideline (#368) Split from #298. Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update AV1800 guideline (#375) Split from #298. Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update AV1521 guideline (#361) Split from #298. Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update AV1520 guideline (#360) Split from #298. Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update AV1140 guideline (#356) Split from #298. Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Remove AV1530: Don't change a loop variable inside a `for` loop or a collection in a `foreach` loop (#363) * Update AV1530 guideline Split from #298. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Address review comments on AV1530: update title and add foreach collection example Co-authored-by: dennisdoomen <572734+dennisdoomen@users.noreply.github.com> Agent-Logs-Url: https://github.com/dennisdoomen/CSharpGuidelines/sessions/983488b6-53b6-4360-876c-4576219b2d4f * Remove AV1530 rule file entirely Co-authored-by: dennisdoomen <572734+dennisdoomen@users.noreply.github.com> Agent-Logs-Url: https://github.com/dennisdoomen/CSharpGuidelines/sessions/0ce85de6-5278-491a-87c7-607ef017b67b --------- Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: dennisdoomen <572734+dennisdoomen@users.noreply.github.com> * Update AV1250 guideline (#358) Split from #298. Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update AV1115 guideline (#352) Split from #298. Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update AV1025 guideline (#351) Split from #298. Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update AV1020 guideline (#350) Split from #298. Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update AV1011 guideline (#348) Split from #298. Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update AV1010 guideline (#347) Split from #298. Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update AV1003 guideline (#345) Split from #298. Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Add AV1618 guideline (#326) Split from #298. Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Add AV1615: Prefer inline literals over constant variables in tests (#325) * Add AV1615 guideline Split from #298. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update _rules/1615.md Co-authored-by: Bart Koelman <10324372+bkoelman@users.noreply.github.com> --------- Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Bart Koelman <10324372+bkoelman@users.noreply.github.com> * Update AV1835 guideline (#378) Split from #298. Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update AV1825 guideline (#377) Split from #298. Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update AV1000: A class or interface should have a single purpose (#344) * Update AV1000 guideline Split from #298. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update _rules/1000.md Co-authored-by: Bart Koelman <10324372+bkoelman@users.noreply.github.com> --------- Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Bart Koelman <10324372+bkoelman@users.noreply.github.com> * Remove AV2235 guideline (#342) Split from #298. Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Add AV1602: Postfix test classes with `Specs` instead of `Tests` (#321) * Add AV1602 guideline Split from #298. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Rename nested class Order_placement to OrderPlacement Renamed nested class for better readability. --------- Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Add AV1605: Test behavior, not implementation details (#322) * Add AV1605 guideline Split from #298. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update _rules/1605.md Co-authored-by: Bart Koelman <10324372+bkoelman@users.noreply.github.com> --------- Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Bart Koelman <10324372+bkoelman@users.noreply.github.com> * Add General Guidelines page (#385) Split from #298. Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Add Testability Guidelines page (#386) Split from #298. Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update Links & Articles page (#387) * Update C ov er An dS ty le s page (#384) * Update AV2400 guideline (#382) * Split minor site updates from PR 298 (#383) * Add AV1600 guideline (#320) * Add AV1578 guideline (#317) * Update AV1706: Don't use abbreviations (#371) * Update AV1701 guideline (#370) * Update AV1755: Only use `Async` or `TaskAsync` as a suffix when a method has both synchronous and asynchronous versions (#374) * Clarify suffix usage for Async methods (#393) Follow-up for #374, to align with the replacement of "version" with "variant". * Update AV2305: Document all `public`, `protected` and `internal` types and members (#381) * Update AV2202: Prefer language syntax over explicit calls to underlying implementations (#379) * Update AV1820: Only use `async` for I/O-bound or long-running activities (#376) * Remove AV1580 guideline (#392) * AV0125: Consider duplicating simple logic across modules to reduce coupling (#369) * Update AV1554 guideline (#367) * Update AV1553 guideline (#366) * Update AV1546 guideline (#365) * Update AV1545: Don't use an `if`-`else` construct instead of a simple (conditional) assignment (#364) * Update AV1523 guideline (#362) * Update AV1500: Methods should not exceed 15 statements (#359) * Remove AV1230 guideline (#357) * Update AV1137: Keep parameters as specific and narrow as possible (#355) * Update AV1130: Return interfaces to unchangeable collections (#354) * Update AV1125: Don't expose stateful objects through static members (#353) * Update AV1013: Don't cast a base class to one of its derived classes (#349) * Add LSP example with polymorphism to AV1011 (#396) * Update AV1004: Use an interface rather than a base class to support multiple implementations (#346) * Remove AV2307 guideline (#343) * Remove AV2221 guideline (#341) * Remove AV2201 guideline (#339) * Remove AV1738 guideline (#338) Split from #298. Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Remove AV1737 guideline (#337) * Remove AV1568 guideline (#336) * Remove AV1532: Avoid nested loops (#334) * Remove AV1525 guideline (#333) * Remove AV1510 guideline (#332) * Remove AV1220 guideline (#331) * Add AV2308: Document what a member tries to do, not what it does or how it does it (#330) * Add AV2225: Use deconstruction to simplify variable assignments (#329) * Add AV1622: Test concrete implementations as part of a larger integration scope (#328) * Add AV1622 guideline Split from #298. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update _rules/1622.md Co-authored-by: Bart Koelman <10324372+bkoelman@users.noreply.github.com> --------- Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Bart Koelman <10324372+bkoelman@users.noreply.github.com> * Add AV1620: Test reusable components separately from their consumers (#327) * Add AV1585: Make properties required when they must be set during initialization (#319) * Add AV1155: Use the `field` keyword in auto-properties when additional logic is needed (#316) * Add AV1150: Avoid local functions (#315) * Add AV1145: Use extension members to add behavior without modifying the original type (#314) * Add AV1035: Use primary constructors when they improve readability (#313) * Add AV1032: Consider a delegate instead of an interface with a single method (#312) * Add AV1030: Know when to use a record and when to use a class (#311) * Add AV1002: Only pass things to a constructor that most or all members need (#309) * Remove AV2207 guideline (#340) * Add AV0130: Apply the three pillars of object-oriented programming (#307) * Fix c# fencing to use csharp in assertion-comparison.html Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Remove severity field from all rules The severity rating is no longer used. This removes: - The severity front matter field from all 130 rule files - The severity icon <img> from the rule-category layout - The unused severity images (1.png, 2.png, 3.png) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Dennis Doomen <dennis.doomen@greenchoice.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Bart Koelman <10324372+bkoelman@users.noreply.github.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: dennisdoomen <572734+dennisdoomen@users.noreply.github.com>

dennisdoomen mentioned this pull request Mar 25, 2026

Update C# Coding Guidelines to v14 #298

Closed

bkoelman reviewed Mar 29, 2026

View reviewed changes

Comment thread _rules/1580.md

dennisdoomen changed the title ~~Update AV1580: Consider duplicating simple logic across modules to reduce coupling~~ AV1581: Consider duplicating simple logic across modules to reduce coupling Apr 12, 2026

Update AV1580 guideline

149b8cf

Split from #298. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dennisdoomen force-pushed the copilot/pr298-update-av1580 branch from ea0b1a0 to 149b8cf Compare April 12, 2026 07:07

Remove AV1580 change from PR 298

438150b

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

dennisdoomen changed the title ~~AV1581: Consider duplicating simple logic across modules to reduce coupling~~ AV0125: Consider duplicating simple logic across modules to reduce coupling Apr 12, 2026

dennisdoomen added the refined label Apr 12, 2026

dennisdoomen requested a review from bkoelman April 12, 2026 07:12

bkoelman reviewed Apr 14, 2026

View reviewed changes

Update _rules/0125.md

1fd4511

Co-authored-by: Bart Koelman <10324372+bkoelman@users.noreply.github.com>

Copilot AI review requested due to automatic review settings May 9, 2026 10:14

dennisdoomen force-pushed the copilot/pr298-update-av1580 branch from 6386aaf to 1fd4511 Compare May 9, 2026 10:14

dennisdoomen merged commit 26a6c20 into develop May 9, 2026
2 checks passed

dennisdoomen deleted the copilot/pr298-update-av1580 branch May 9, 2026 10:14

Copilot started reviewing on behalf of dennisdoomen May 9, 2026 10:14 View session

Copilot AI reviewed May 9, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

AV0125: Consider duplicating simple logic across modules to reduce coupling#369

AV0125: Consider duplicating simple logic across modules to reduce coupling#369
dennisdoomen merged 3 commits into
developfrom
copilot/pr298-update-av1580

dennisdoomen commented Mar 25, 2026

Uh oh!

Uh oh!

Uh oh!

bkoelman Apr 14, 2026

Uh oh!

dennisdoomen Apr 14, 2026

Uh oh!

bkoelman Apr 14, 2026

Uh oh!

dennisdoomen Apr 16, 2026

Uh oh!

bkoelman Apr 16, 2026

Uh oh!

Uh oh!

Copilot AI left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

		Note:
		Taking a dependency on a source-only package like [Reflectify](https://github.com/dennisdoomen/reflectify?tab=readme-ov-file#readme) or [Pathy](https://github.com/dennisdoomen/pathy?tab=readme-ov-file#readme), or putting your utility code in a source-only package also avoids coordinated updates. But duplication may still be the safer choice.

Conversation

dennisdoomen commented Mar 25, 2026

Uh oh!

Uh oh!

Uh oh!

bkoelman Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

dennisdoomen Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

bkoelman Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

dennisdoomen Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

bkoelman Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants