Update _rules/0125.md

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

Author: dennisdoomen

_rules/0125.md

@@ -13,7 +13,7 @@ If sharing a tiny piece of logic between two separate modules would require:
 - Exposing internal types or contracts across a boundary.
 - Introducing a third project or package just to hold a few lines of code.
 
-…then duplicating the logic is often the simpler choice.
+...then duplicating the logic is often the simpler choice.
 
 ```csharp
 // In Module A
@@ -30,10 +30,7 @@ This applies primarily to:
 - 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. 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.
-
-**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. 
+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.