fix(release): prepare aligned 0.1.45 composition and guarded candidate sequencing

docs/operations/RELEASE_CONSOLE.md

@@ -221,6 +221,9 @@ Repository capabilities are frozen into each plan unit (`python-package`,
 `core-release-bundle`, and the universal `git-source`) and determine which
 steps appear. Internally aligned version changes are rendered deterministically
 from recognized TOML, JSON, lockfile, manifest, and package declarations.
+The manifest may use a literal version or a top-level literal `MODULE_VERSION`;
+the latter is updated without rewriting independently versioned interfaces.
+Computed or missing version declarations fail before any metadata is written.
 Pre-existing dirty worktrees remain visible but have no commit executor; the
 console never absorbs unrelated operator changes.
 
@@ -232,6 +235,17 @@ runs a receipt-bound alignment gate before exposing any atomic branch/tag push.
 A failed step stops later steps while preserving prior receipts for explicit
 retry or reconciliation.
 
+Local module candidate creation deliberately does not require those candidates
+to be resolved already in Core's release lock: their annotated tags are inputs
+to the next lock-generation step. The internal tag helper applies this ordering
+only when no Core repository is selected and remote publication is disabled.
+Module version/lock consistency, manifest validity, clean/non-behind worktrees,
+and local/remote tag immutability checks still apply. Core candidate tagging
+continues to validate its own complete bundle, and every remote-publication
+preview and execution requires the selected modules to match Core's release
+input and resolved lock. A local candidate is therefore not publication
+approval; a stale Core lock blocks publication without changing remote refs.
+
 The browser likewise retains the request identifier for an uncertain
 resume/retry/reconciliation response and replays it after reload. A successful
 replay selects the returned run state. Transport and server failures retain the
@@ -515,8 +529,9 @@ updated catalog, and keep the published keyring healthy.
 
 When a selected module exposes a WebUI package, its requested version must also
 match Core's `webui/package.release.json` input and the resolved
-`package-lock.release.json` entry. The source-tag preflight, selective plan, and
-catalog-candidate writer all enforce this composition boundary. Pins for modules
+`package-lock.release.json` entry. The source-publication preflight, selective
+plan, and catalog-candidate writer all enforce this composition boundary;
+module-only local candidate tags use the staged order described above. Pins for modules
 that are not part of the selective release remain unchanged.
 
 Release integration also enforces repository and composition version alignment