rephase build phase doc, clarify provider/rule definition

Author: rickeylev

CONTRIBUTING.md

@@ -193,17 +193,21 @@ Some miscellanous style, idioms, and conventions we have are:
   `x.test`. The `.` is our convention to communicate that it's a generated
   target, and thus one should look for `name="x"` when searching for the
   definition.
-* The different build phases and interface/implementation pieces of rules should
-  be in different files. Stated another way: loading code for thing shouldn't
-  incur loading code that isn't relevant.
-  * Providers should be in their own files. This allows implementing a custom
-    rule that implements the provider without loading an existing
-    implementation.
-  * The repository phase shouldn't `load()` code that is only relevant to the
-    loading-phase or subsequent phases. Vice-versa, loading-phase code should
-    not load any repository-phase code.
-  * Generally, one rule per file. The goal is that defining an e.g. library
-    shouldn't incur loading all the code for binaries, tests, packaging, etc.
+* The different build phases shouldn't load code that defines objects that
+  aren't valid for their phase. e.g.
+  * The bzlmod phase shouldn't load code defining regular rules or providers.
+  * The repository phase shouldn't load code defining module extensions, regular
+    rules, or providers.
+  * The loading phase shouldn't load code defining module extensions or
+    repository rules.
+  * Loading utility libraries or generic code is OK, but should strive to load
+    code that is usable for its phase. e.g. loading-phase code shouldn't
+    load utility code that is predominately only usable to the bzlmod phase.
+* Providers should be in their own files. This allows implementing a custom rule
+  that implements the provider without loading a specific implementation.
+* One rule per file is preferred, but not required. The goal is that defining an
+  e.g. library shouldn't incur loading all the code for binaries, tests,
+  packaging, etc; things that may be niche or uncommonly used.
 * Separate files should be used to expose public APIs. This ensures our public
   API is well defined and prevents accidentally exposing a package-private
   symbol as a public symbol.