[alexanderlinne]

Fixes #468
Fixes #208

Why

Slice patterns were matched by string surgery: everything after the first (* was replaced with (**)., so every pattern behaved as if it ended in a greedy capture.

• (*) and (**) selected the same slices.
• (*), (*).., (*).(*) and (*)..(*) all produced the same nine slices.
• A trailing literal such as (**).Service.. matched nothing.
• Alternation and wildcards were ignored outright.

The exporter compensated with RemovePatternInappropriateSlices, which dropped every slice with at least as many dots as the pattern had (*) groups, so a diagram showed fewer slices than the rule checked.

What changes

Matching. The pattern is converted to a regular expression, ported from ArchUnit's PackageMatcher:

Token	Meaning
(*)	captures exactly one segment
(**)	captures one or more segments
(A|B)	captures one of the alternatives
*	matches one segment without capturing it
..	matches zero or more segments
[A|B]	matches one of the alternatives

.. deviates from ArchUnit on purpose. ArchUnit's expression for it can match the empty string in the middle of a segment (App.(*)..(*) on App.Single would capture Singl and e), so it is expanded depending on where it sits and always consumes the separating dot. The method documents why.

Malformed patterns are rejected by Matching/MatchingWithPackages when the rule is defined, instead of on the first type that happens to be checked.

This is what fixes both issues:

• Slices don't differentiate between (*) and (**) making top-level cycle checks impossible #468: (*) no longer behaves like (**). With …MultipleSubnamespaces.(*), Slice2.Service used to be a slice of its own in rules, which the exporter then hid from diagrams with RemovePatternInappropriateSlices. Now there are exactly three slices, one per top-level namespace, each holding only the types directly in it, so a diagram shows what the rule checks. The diagram symptoms, such as Slice1 drawn as an empty package in focus mode, are already gone with Nest slices in packages via GenerationOptions, deprecate MatchingWithPackages #513.

• Slice matching does not group classes of subnamespaces into the correct slice #208: Matching("Module.(*)..") now folds Module.Two.InnerNamespace into the Two slice, so the cycle is found. Matching("Module.(*)"), as written in the issue, now leaves InnerNamespace out entirely, as ArchUnit does, instead of giving it a slice of its own. A new test on the SubnamespaceCircle fixture pins this.

Several capture groups. Every capture group now captures a part of the slice, so a pattern with several groups gives slices with several parts. #515 already defined how those are identified, named and frozen:

Pattern	Namespace	Slice
App.(*).(*)	App.Orders.Http	Slice Orders - Http
App.(*).Service.(*)	App.Orders.Service.Http	Slice Orders - Http
App.(*)..(*)	App.Orders.Web.Http	Slice Orders - Http
App.(*).*.(*)	App.Orders.Web.Http	Slice Orders - Http

The pattern text between the groups only selects types, so all four are the same slice.

Nested diagrams need nothing from the pattern: slices with several parts nest at their types' common namespace like any other (#513). Focus mode and LimitDependencies, which use that namespace too, need no change either. They apply to slices with several parts as they are.

(*).(*) and (*)..(*) no longer draw the same diagram:

• (*).(*) needs exactly two segments, so the top-level SliceN classes belong to no slice any more, and the package arrows that came from them are gone.
• (*)..(*) also picks up the Inner namespaces. The slice Slice3 - Inner holds the types of Group1.Inner and Group2.Inner, so it sits in Slice3.

Only the types decide where a slice sits: Slice Slice3 - Inner sits at Slice3.Group1.Inner for (*).Group1.(*), and at Slice3 for (*).*.(*), whose Inner slice spans both groups. Before, both patterns drew the same diagram as (*).(*) above:

Where names no longer say where a slice lives, focus mode and LimitDependencies still work, as they go by namespaces. With …MultipleSubnamespaces..(*), the slices Group1, Group2, Inner and Slice3 all lie in Slice3, so focusing on …Slice3 focuses all four. LimitDependencies drops Group1 → Slice3 and Service → Slice3, because those slices lie at depths 4, 2 and 3, although none of the names has a dot. New snapshots pin both.

Removed. A (*) capture can no longer contain a dot, so RemovePatternInappropriateSlices can't remove anything any more. It is removed, along with the CountOfAsteriskInPattern it consumed.

Docs. The XML documentation of SliceRuleInitializer and SliceIdentifier describes the pattern syntax and the multi-capture naming. The guide's "Slice Rules" section gains:

• the pattern token table and the validation rules,
• the multi-capture naming rules,
• where a nested slice is drawn.

Section 5.4 describes repeated (*) groups.

Breaking changes

• (*) matches exactly one namespace segment, so Matching("App.(*)") leaves out every type below App.<X>.<Y> instead of giving it a slice of its own. Use App.(*).. to fold those types into their top-level slice, or App.(**) to keep one slice per namespace.
• (**).. now also includes the types directly in the captured namespace.
• Rules can therefore report different violations, and slice names in failure messages and frozen-rule stores change along with the slices. Rules with several capture groups have to be re-frozen once.
• Slice.CountOfAsteriskInPattern, SliceIdentifier.CountOfAsteriskInPattern and the countOfAsteriskInPattern parameter of SliceIdentifier.Of are removed.

How the images were made

Both images render the .verified.txt snapshots at #515 and at this PR, on the MultipleSubnamespaces fixture; the "before" side of image 2 is the same diagram as that of image 1. They were rendered with PlantUML 1.2025.4 and Graphviz, with the remote !include of C4-PlantUML replaced by PlantUML's bundled copy (!include <C4/C4_Container>).

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.48%. Comparing base (54bb0ea) to head (f702e73).

Additional details and impacted files

@@                     Coverage Diff                      @@
##           identify-slices-by-captures     #516   +/-   ##
============================================================
  Coverage                        86.48%   86.48%           
============================================================
  Files                              261      261           
  Lines                            12676    12679    +3     
  Branches                          1232     1231    -1     
============================================================
+ Hits                             10963    10966    +3     
  Misses                            1366     1366           
  Partials                           347      347           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.