Complete guided release console workflow

docs/RELEASE_CONSOLE.md

@@ -22,10 +22,17 @@ effects can be verified safely:
 - freeze a selective plan as a durable, resumable local release run
 - durably preflight a creation-time-bound repository, create its annotated tag,
   and publish its branch/tag pair atomically
+- deterministically update recognized package/manifest version declarations and
+  commit only the receipt-bound metadata paths
+- order selected module providers before consumers, create module tags before
+  Core, regenerate Core's selected WebUI release lock, and re-run alignment
+  before any remote push
 - build selected Python wheels and generate a private, signed, receipt-bound
   catalog candidate
 - publish that exact candidate through a verified website commit and immutable
   tag after explicit confirmation
+- install selected candidate wheels into a private no-network/no-dependency
+  target and verify their installed metadata against the frozen plan
 
 Start it from the meta repository:
 
@@ -79,21 +86,23 @@ from the saved-run selector. Problems in unselected repositories remain visible
 as workspace notices but do not lock an unrelated release; the selective plan
 is the authority for blockers in the selected repository set.
 
-Installation verification remains an explicit unavailable phase after a
-durable run completes. It is currently enforced by release-integration CI,
-rather than being presented as a successful local-console step. This prevents
-the guide from treating source publication as proof that the published package
-can be installed and started.
+Installation verification is an explicit durable step after catalog
+publication. It verifies the exact candidate receipt, installs every selected
+Python wheel into a temporary target with network and dependency resolution
+disabled, and compares installed names and versions with the frozen plan.
+Deployment startup, database upgrades, and module-combination smoke tests remain
+release-integration CI gates; the console does not represent its local wheel
+check as a production deployment.
 
 `Build Plan` also returns structured release-gate findings for each selected
 repository. The plan names the recommended next action and gives an explicit
 remediation for source-version, lockfile, Core WebUI composition, Git state, and
-worktree findings. A target version that has not yet been applied consistently
-to the selected source tree is therefore explained before the source-tag
-preflight rather than appearing only as an error after the operator tries to
-tag. `source_preflight_ready` means that the plan-visible source gates pass; the
-non-mutating `Preview Tag + Publish` remains mandatory for remote, manifest, and
-immutable-tag checks.
+worktree findings. A target version that differs from internally consistent
+source metadata becomes a bounded `UPDATE` step. Unsupported, missing, or
+internally inconsistent declarations remain a blocker with exact remediation.
+`source_preflight_ready` means that plan-visible source gates pass or have a
+bounded deterministic mutation; the non-mutating `Preview Tag + Publish`
+remains mandatory for remote, manifest, and immutable-tag checks.
 
 ## Durable release runs
 
@@ -103,11 +112,12 @@ requires the plan to resolve exactly the requested repositories and target
 versions; the browser cannot submit or replace the plan snapshot. The input and
 plan are then immutable and covered by a canonical SHA-256 integrity digest.
 Every executable repository step also carries its creation-time full HEAD,
-branch, worktree state, target tag, and a SHA-256 over both the fetch and push
-URLs of `origin`. Both URLs must exactly equal the remote registered in
-`repositories.json`; a changed HEAD, branch, worktree, remote, or push URL
-requires a new run rather than silently retargeting the frozen compatibility
-decision.
+branch, target tag, a SHA-256 over both the fetch and push URLs of `origin`, and
+a SHA-256 over bounded dirty-path names and bytes. Both URLs must exactly equal
+the remote registered in `repositories.json`; a changed HEAD, branch, worktree,
+remote, push URL, or metadata byte requires a new run or explicit
+interrupted-step reconciliation rather than silently retargeting the frozen
+compatibility decision.
 The complete record also has a checksum so a valid-looking manual edit to its
 mutable state fails closed. File permissions remain the authority boundary;
 these digests detect accidental or manual corruption, not an attacker who can
@@ -195,24 +205,32 @@ retry. The UI keeps unavailable controls visible and disabled.
 
 Supported executors durably claim the step before invoking an effect. Exact
 attempt replays return the recorded outcome and never invoke the executor a
-second time. Successful repository preflight, tag, and push steps persist a
-bounded repository-state receipt. Tag reconciliation independently requires an
+second time. Successful repository preflight, version, commit, Core-bundle,
+tag, and push steps persist a bounded repository-state receipt. Version
+reconciliation requires aligned declarations in the same commit; commit
+reconciliation requires the expected single-parent release commit and only
+recognized metadata paths. Tag reconciliation independently requires an
 annotated local tag at the frozen HEAD; push reconciliation additionally
 requires both the remote annotated tag object and remote branch to match.
 Catalog generation persists
 only its server-issued opaque candidate ID and canonical catalog SHA-256, then
 re-resolves and re-hashes that private candidate before publication.
 
-The safe baseline is intentionally narrower than the complete dry-run plan.
-Dirty worktrees and version changes still show commit/version steps, but those
-steps have no durable executor because the frozen run does not bind the exact
-proposed file content. A run selecting Core together with one or more modules
-begins with a disabled dependency-ordering barrier: local module tags, Core
-release-lock regeneration/commit, Core tagging, alignment verification, and
-pushes need an explicit DAG executor before that composition can mutate.
-Operators must prepare and review those changes outside the console and create
-a new run from the resulting clean HEAD. The console never skips these steps or
-claims an end-to-end release succeeded.
+Repository capabilities are frozen into each plan unit (`python-package`,
+`webui-package`, `module-manifest`, `database-migrations`, `documentation`,
+`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.
+Pre-existing dirty worktrees remain visible but have no commit executor; the
+console never absorbs unrelated operator changes.
+
+For mixed releases, module interface providers are ordered before consumers
+and Core is tagged last. The durable sequence creates and commits module
+metadata, creates local module tags, updates Core's selected WebUI references,
+regenerates the release lock against those local tags, commits/tags Core, and
+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.
 
 The browser likewise retains the request identifier for an uncertain
 resume/retry/reconciliation response and replays it after reload. A successful