Publish complete signed module catalogs

docs/PACKAGE_REGISTRY_RELEASES.md

@@ -136,31 +136,38 @@ allow the same least-privilege credential to serve every module workflow.
 
 ## Exact release consumption
 
-`tools/release/generate-release-package-set.py` translates the reviewed Git
-source refs in `requirements-release.txt` into an exact registry package set.
-It resolves each version tag to its commit and verifies the package metadata in
-that tag.
+`tools/release/generate-release-package-set.py` supports two explicit package
+profiles. `base` translates the reviewed roots in `requirements-release.txt`;
+`full` reads the exact `govoplan[full]` dependency set from the developer
+meta-package. Both profiles resolve every version tag to its commit and verify
+the package metadata from that exact Git tree. The official module directory
+and immutable runtime distribution use `full`, so every publicly released
+module can be discovered without rebuilding the application image.
 
 `tools/release/resolve-package-artifacts.py` then downloads exactly those wheel
 and WebUI versions from Gitea. It reads the identity embedded in every wheel and
 npm tarball, rejects missing, duplicate, unexpected, or oversized artifacts,
-and writes `package-artifacts.lock.json` with SHA-256 values and npm integrity
-values. Credentials are accepted only through environment variables and are
+and writes `package-artifacts.lock.json` with credential-free HTTPS download
+URLs, SHA-256 values, and npm registry integrity values. The resolver verifies
+that the bytes downloaded by `npm pack` match the registry's own integrity
+record. Credentials are accepted only through environment variables and are
 never written to the lock. Python resolution ignores ambient pip configuration
 and extra indexes for GovOPlaN roots, preventing an internal package name from
 being selected from an undeclared registry.
 
-The runtime distribution workflow uses the verified wheelhouse directly and
-installs module WebUI tarballs only after matching them to the lock. It publishes
-the package set, package lock, and hash-locked requirements as release assets.
+The runtime distribution workflow uses the verified full-profile wheelhouse
+directly and installs every selected module WebUI tarball only after matching
+it to the lock. It publishes the package set, package lock, and hash-locked
+requirements as release assets.
 The WebUI installer receives the absolute runtime-build interpreter path so its
 directory changes cannot escape the isolated release environment.
 Gitea 1.24 dispatches this workflow from a branch, but that branch is only the
 workflow implementation. The job fetches and peels the protected `v<version>`
-tag explicitly, then binds both the signed distribution source and the Gitea
-release assets to that exact commit. A post-tag workflow repair can therefore
-retry publication without relabelling the later branch commit as released
-source.
+tag explicitly and materializes both `requirements-release.txt` and the
+developer meta-package from that Git tree. It then binds the signed distribution
+source and Gitea release assets to the same exact commit. A post-tag workflow
+repair can therefore retry publication without changing the released package
+composition or relabelling the later branch commit as released source.
 The package-lock SHA-256 is part of the signed distribution manifest. Runtime
 finalization also requires the lock's package versions and hashes to match the
 wheel composition embedded in the images. OCI assembly remains network-free
@@ -170,6 +177,44 @@ The source refs remain in the module catalog for source provenance and release
 planning. Production installation consumes the signed runtime images rather
 than invoking `pip`, `npm`, or Git on the target host.
 
+## Public module directory
+
+`tools/release/publish-release-catalog.sh` resolves the selected package set and
+registry lock before it creates a catalog. Catalog entries are synthesized from
+the exact tagged module manifests, never from a hand-maintained module list or
+the current workspace. Each entry binds its Python wheel and optional WebUI
+tarball to the registry URL, filename, size, SHA-256, package identity, source
+tag, and source commit before the complete catalog is signed.
+
+Official GovOPlaN modules are open-source directory entries and do not require
+license entitlements. The generic `license_features` contract remains available
+for third-party package directories, support/configuration packages, or future
+deployment-specific presets. A catalog entry is gated only when that entry
+explicitly declares such features.
+
+Core carries the public stable catalog URL and its independently pinned trust
+anchor. In the absence of an operator-configured catalog, Admin discovers the
+official directory automatically. Selecting an entry creates a reviewed
+install/update plan; the trusted installer downloads the exact signed artifacts
+into a private digest cache, verifies size and hash, and installs only from that
+cache. A saved plan is rejected if any package ref, artifact identity, catalog
+channel, sequence, or signing-key identity differs from the currently validated
+catalog.
+
+Package lifecycle and availability are intentionally separate:
+
+- install, update, and uninstall change the instance-wide package composition;
+- enable and disable change the active instance runtime graph;
+- tenant module entitlements define unavailable, available, and forced modules;
+- group/user presentation is governed through Views and Policy; and
+- enabling a capability module does not opt data into that capability.
+
+Single-process or single-host installations may execute a supervised package
+plan locally. Shared-state and Kubernetes profiles reject node-local package
+mutation: operators compose and roll out a new signed full-profile runtime image
+instead. This prevents replicas from drifting while retaining the same Admin
+catalog and preflight experience.
+
 ## Developer meta-package
 
 `packages/govoplan-meta` builds the optional `govoplan` package. Its default