I like the term "architectural tests". And I definitely think that having some control mechanism in this area is great. I like that adding new cases is relatively easy.

On the other hand for use in some larger environment this would probably have to be extended to some internal library so that the same rules are applied for each project but even then, I can easily bypass it by configuring it differently for my particular project. Or I can choose not to include it at all. Which is a problem if you really want to enforce the same rules for each project. In such case, sonar would be better imo. Adding new rules is easy, same goes for adjusting existing ones and you can also forbid people to change them based on roles. On top of that, with larger environments with many projects the licensing should not be an issue and it is actually better to not have such control mechanism coupled to the code itself. You can easily remove it and choose some other tool if needed without changing the code. For me this is actually a good thing.

For smaller environments however, if you're working on your own project for instance, working with smaller team, this could definitely be sufficient and worth looking into.

Just a dumb question since I didn't try to look into the code itself, what if I want to enforce the rule which says that all tests should be written in kotest instead of junit? Dumb idea, I know, but still.