Prepare and verify develop → main production release readiness

Utilities reload verified — 2026-10-23

PAR-519 source was located in MCCitiesNetwork/NexoUtilities. Provider PR #1 repairs reload; Hibernia PR #100, stacked on #99, enables the regression and updates evidence. The unmodified source fails the denied-purchase assertion (stock 8 → 4). The corrected provider passes two full local provider-profile runs: 6 tests / 0 failures / 0 errors / 0 skips each, 78.60s / 85.15s, identical runtime manifests and unchanged source. Evidence: 20261023T195518Z-3673512 at Hibernia 75cede463dc2a91af1d236682413768ae395616d; documentation-only commit follows it. Corrected Utilities 3.0.0 source 597c395fd244d689aa14a92068377c80bb314550, JAR SHA-256 5b45eea19785c26c6894bc2ca359a9118dda7463e5cea8c98611ef2bafb10a05. Select by hash/source, since the version label is unchanged. Both PRs are open; the shared installed artifact was not replaced. Final frozen-release and manual/client acceptance remain separate.

Implementation stack — 2026-10-23

Code/documentation prerequisites are in an ordered PR stack: #97 (PAR-512 V40 blocker report) → #98 (PAR-520 runtime artifact evidence and CI for stacked bases) → #99 (PAR-511 V42 cutover runbook). The full combined Gradle build and seven evidence-tooling tests pass. Final live runner smoke verification passed twice: 8 payment/disband tests per run, zero failures/skips, 63.41s / 55.93s, identical runtime artifacts and unchanged source at 798830b7. These PRs do not certify production state or execute the cutover.

PAR-519 now has a verified provider fix and enabled regression in the fourth stack PR #100, with companion provider PR #1; see the update above. PAR-510 already has production manifest generation in .github/scripts/release-metadata.mjs and plugin-release.yml; no duplicate manifest generator is needed. Its remaining freeze/artifact-selection work and PAR-513–518 operational work remain tracked separately.

Work breakdown

Existing release work is tracked under this issue: PAR-250 (production compatibility cleanup), PAR-499 → PAR-502 (acceptance), PAR-496 (provider/client parity), PAR-8 (menu acceptance), PAR-318 (firm-owner repair), PAR-159 (Explorer rollout observation), and PAR-235 (historical sale backfill, separately schedulable).

New discrete work:

• PAR-510 — Freeze release scope and record the production artifact manifest
• PAR-511 — Update the production cutover runbook and release PR for V42
• PAR-512 — Verify per-tenant production schema history and migration preflight
• PAR-513 — Plan V40 name-collision remediation and preserve SYSTEM wallet routing
• PAR-514 — Rehearse the production migration and restore on representative snapshots
• PAR-515 — Prepare API signing-secret rotation and Explorer SERVICE-token renewal
• PAR-516 — Schedule the release window and verify production rollout holds
• PAR-517 — Execute the coordinated production schema and application cutover
• PAR-518 — Verify production smoke tests, invariants and release stability
• PAR-519 — Repair Utilities shop-restriction reload and re-enable its acceptance test (under PAR-496)
• PAR-520 — Run final release acceptance profiles twice and reconcile remaining gaps (under PAR-502)

Execution order: freeze scope/artifacts and establish preflight → approve remediation and rehearse upgrade/restore → reconcile final acceptance and publish the corrected runbook/credential plan → establish window and rollout hold → cutover → production verification and scheduled data follow-through. PAR-250 coordinates current deployment state with the rollout hold. PAR-235 and PAR-159 retain their documented post-release/rollout scope; parentage alone does not make historical backfill a pre-merge blocker.

Goal

Make the Hibernia Economy develop → main release ready for a coordinated production cutover, with a frozen revision, validated migration plan, explicit acceptance decisions, and recorded recovery procedures.

Release PR: https://github.com/ParadauxIO/hibernia-economy/pull/2

Readiness assessment on 2026-10-23: develop f7e915ef2756429ac17bdbbe9853edef0ca91a3f has passing CI, including live-server integration, migrations, JVM, Explorer and CodeQL checks. This establishes CI readiness, not production-state verification. No production inspection or mutation was performed for this assessment.

This issue coordinates existing work; do not reimplement completed fixes or treat every open backlog item as a release blocker.

Before merge

• Freeze the release scope and record the final SHA. Decide whether shop-owner display PR #87 is included. Explicitly include or defer open tax PRs #51/#52 and dependency PR #46; they are not automatic blockers.
• Update PR #2 and the release runbook to describe the actual release. The runbook still describes V16–V36, while the assessed develop includes V42. Record the selected runtime and complete plugin/image/configuration versions.
• Resolve PAR-250 with deployment evidence: inspect the actual production Explorer image, compatibility views, schema history and automatic-promotion configuration for each tenant. Current V18 already drops account_access/account_group_access compatibility views; reconcile the older manual-drop instructions. Do not remove a compatibility view while the serving application still depends on it.
• Run read-only Flyway Info/checksum validation and data preflight for every production tenant. Record actual starting versions; do not assume V15 or blindly repair history.
• Run the global-name collision inventory and agree dispositions before migration. V40 rejects conflicting/blank names. If SYSTEM label renames are necessary, preserve and verify original routing identities using the documented pre-V40 V42 preparation procedure before any rename. Do not guess identities or renumber migration history.
• Rehearse the full intended upgrade through V42 and restore procedure on an isolated representative snapshot. Record elapsed time, required capacity, schema results, money/access invariants and rollback evidence.
• Reconcile remaining acceptance under PAR-502 / PAR-499 / PAR-496 against the final release tree. Obtain a corrected Utilities artifact and enable/retest the known reload regression, or explicitly record an agreed release disposition. Complete required Java/Bedrock, graphical Nexo/resource-pack, provider/protection, lifecycle, permission, scheduled-job and menu acceptance; give each remaining gap an owner and explicit disposition.
• Run applicable final acceptance profiles twice from clean state, preserving exact revisions, runtime/artifact versions, results and named skips. Latest ownership/disband fixes have focused passing evidence; earlier full acceptance pairs predate those changes. Green CI alone does not cover all external-provider/manual acceptance.
• Build the complete release bundle from the frozen SHA and retain prior compatible jars, immutable image tags and configuration/secret versions.
• Agree the maintenance window and notify API users that tokens must be reissued. Confirm ownership of deployment, migration, verification and rollback.

Cutover checklist

• Hold automatic production image rollout/sync before merging. Verify the hold covers every affected tenant sharing the images.
• Merge the release PR and require the relevant production build/publication jobs to succeed while rollout remains held.
• Stop affected game servers, REST, Explorer and other database writers; verify quiescence.
• Take and verify coordinated backups covering databases and relevant worlds/plugin files, including triggers and recovery evidence. Retain a tested restore point.
• Perform the reviewed preparation/remediation and migrations per tenant. Require all expected migrations successful and no unexpected pending/checksum failures before starting new code.
• Deploy matching plugin bundles, images and configuration. Coordinate the shared signing-secret rotation and per-tenant Explorer SERVICE-token renewal.
• Verify schema, money invariants, player/access counts, REST/Explorer health, login and authorization, token invalidation/reissue, /balance, payment, ChestShop purchase and firm sales. Confirm clean plugin startup and no SQL errors.
• Record go/no-go and rollback decisions. After destructive schema changes, rollback requires a consistent database restore and matching artifacts/configuration; a jar-only rollback is insufficient.

Follow-through

• Recheck firm/account ownership and apply the release-compatible repair where required (PAR-318). Verify the mismatch count and access state after deployment.
• Give historical sale-ledger backfill PAR-235 a scheduled disposition: representative clone query-plan/match-rate/spot-check validation followed by separately authorized production execution. Tooling is merged; the backfill has not thereby been executed. This may be scheduled after release if explicitly agreed.
• Retain backups through the agreed stability period and attach deployment/acceptance receipts. Update existing issues only when their own completion criteria are met.

Scope boundaries

The broader Minecraft 26.3 platform project is separate. Verify the runtime and integrations needed by this economy release without importing its entire backlog. TreasuryIngest is retired; do not reopen its removed acceptance cases. Already completed real-login and ownership/disband fixes are not outstanding implementation work.

Issue creation does not authorize production mutations, migrations or deployment. Record operational evidence without credentials, tokens, dumps or private wallet mappings.

References

• Release runbook: https://github.com/ParadauxIO/hibernia-economy/blob/develop/wiki/release-runbook.md
• SYSTEM wallet preparation: https://github.com/ParadauxIO/hibernia-economy/blob/develop/wiki/system-wallet-routing.md
• Name inventory: https://github.com/ParadauxIO/hibernia-economy/blob/develop/ops/name-collision-inventory.sql
• Current acceptance evidence: https://github.com/ParadauxIO/hibernia-economy/blob/develop/integration-tests/acceptance/par-502.md
• Production compatibility cleanup: https://app.taskl.ie/w/paradaux/issues/PAR-250
• Acceptance: https://app.taskl.ie/w/paradaux/issues/PAR-502 · https://app.taskl.ie/w/paradaux/issues/PAR-499 · https://app.taskl.ie/w/paradaux/issues/PAR-496
• Data follow-through: https://app.taskl.ie/w/paradaux/issues/PAR-318 · https://app.taskl.ie/w/paradaux/issues/PAR-235

Done when

The frozen release has per-tenant preflight and rehearsal evidence, required acceptance is passed or explicitly dispositioned, production cutover and smoke checks are recorded, recovery artifacts are retained, and any deferred follow-up has a named owner and linked task.