Sync Repo-docs-MODULE-ARCHITECTURE from project files

Repo-docs-MODULE-ARCHITECTURE.-.md

@@ -1,4 +1,4 @@
-<!-- codex-wiki-sync:0e9ea4738aad52fd7f810ccb -->
+<!-- codex-wiki-sync:0f7bb6be739af735cbaade1b -->
 
 > Mirrored from `/mnt/DATA/git/govoplan-core/docs/MODULE_ARCHITECTURE.md`.
 > Origin: `repository`.
@@ -89,6 +89,14 @@ Known access-related capability names are defined in
 direct reads of access/tenant ORM models when they need labels, group
 membership, default access provisioning, or tenant metadata.
 
+Cross-module feature contracts live under focused kernel contract modules. For
+example, `govoplan_core.core.campaigns` defines
+`campaigns.mailPolicyContext` and `campaigns.access`. The campaign module
+registers these capabilities so mail can resolve campaign owner/policy context
+and files can validate campaign file-share access without importing campaign ORM
+models. Keep these contracts small DTO/protocol surfaces and register concrete
+behavior from the owning module.
+
 ## Module Responsibilities
 
 A module owns one bounded feature area. A module can include both backend and WebUI code in the same repository so feature behavior and frontend integration evolve together.
@@ -221,6 +229,8 @@ Rules:
 
 - Use core module metadata to check whether another module is installed.
 - Use backend APIs/events/service contracts for runtime cooperation.
+- If a sibling module needs owner-specific data, expose a narrow DTO/protocol
+  capability from the owning module instead of importing its ORM models.
 - Keep UI integration declarative where possible: nav items, route contributions, context actions, and explicit extension points.
 - Avoid direct imports from one feature module into another feature module unless the imported package is a published API contract designed for that purpose. UI components should be promoted to core instead.