diff --git a/Repo-docs-MODULE-ARCHITECTURE.-.md b/Repo-docs-MODULE-ARCHITECTURE.-.md index 47de345..6e6e36a 100644 --- a/Repo-docs-MODULE-ARCHITECTURE.-.md +++ b/Repo-docs-MODULE-ARCHITECTURE.-.md @@ -1,4 +1,4 @@ - + > 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.