Expose public module catalog discovery

README.md

@@ -40,6 +40,8 @@ The admin module owns the operator surfaces for module lifecycle management:
 - installed/enabled/desired module state
 - runtime activation and deactivation of installed modules
 - signed catalog install planning
+- automatic discovery from the signed public stable directory when no
+  deployment catalog override is configured
 - non-destructive uninstall planning, with explicit `destroy_data` retirement
   options where a module provides a retirement provider
 - installer preflight status, maintenance-mode blockers, migration/restart
@@ -52,6 +54,13 @@ admin UI records operator intent and queues or renders commands for the trusted
 installer process described in
 `/mnt/DATA/git/govoplan-core/docs/MODULE_ARCHITECTURE.md`.
 
+Catalog entries show whether the package is already installed and whether the
+directory advertises another version. Selecting an entry preserves its signed
+registry URLs and integrity evidence in the reviewed plan. The installer, not
+the browser or API request, downloads and verifies those artifacts. On a shared
+or Kubernetes deployment, the same plan requires a new immutable image
+composition instead of changing one running replica.
+
 The WebUI presents the lifecycle as five derived stages: plan, preflight,
 installer request, daemon execution, and run evidence. The projection resets
 when the saved plan changes and associates evidence only with an installer
@@ -80,6 +89,10 @@ User and group module visibility is configured through Views, where each WebUI
 module is represented by its root module surface. This keeps tenant operational
 state distinct from presentation preferences.
 
+Licensing remains a generic catalog/preset contract. Official open-source
+GovOPlaN directory entries carry no feature requirement; a license affects an
+entry only when that catalog explicitly declares `license_features`.
+
 ## Package Surfaces
 
 The admin UI intentionally exposes two different package concepts: