Skip to main content
Check publication, Config selection, proxy resolution, and player acceptance separately. The Portal provides inspection and Stage selection; it does not orchestrate fleet restarts or immediately replace packs for connected players.

​
Operator acceptance procedure

1

Capture the current state

Record environment, Config version, channel/pin, and proxy target fingerprints. Verify the available release matches the runtime Minecraft/format contract.
2

Make one guarded change

Use the Portal confirmation or Forge API with the current expected version. A 409 requires a fresh read and review.
3

Check Config and proxy convergence

Read the new document/version and inspect each target proxy’s source, current/fallback snapshot, and resolved publication. A write response alone is insufficient.
4

Check a connected player

Remain connected during selection. There must be no immediate broadcast, forced disconnect, or fleet restart from this operation.
5

Switch or reconnect

Change backend server or reconnect. Check that the selected PackSet is offered/applied. Downloads from the Minecraft cache can complete quickly.
6

Verify rollback and final state

Repeat with an older compatible release, then restore the intended channel/pin. Check proxy and player behavior again.
For NPC/map acceptance, also verify authored placement, labels, the navigator click action, collision, and viewer-private hover behavior with two players. Those checks belong to the map/scene host and are not replaced by PackSet counters.

​
Deployment settings

Enable mutations only after all target runtimes understand release pins, have the expected compatibility contract, and pass selection/rollback/concurrency/next-connection acceptance. Reads can be available with writes disabled. Config must validate bearer identity and authorize the exact document writer. Keep the service private and preserve the deployment’s network isolation policy. Token rotation must continue working without copying long-lived credentials into a file or log.

​
Troubleshooting matrix

​
Compatibility and rollback

The current Stage selector accepts release pins only for Minecraft 26.3 / format 97. Historical 26.2 / format 88 releases can be inspected but cannot serve as a compatible rollback target for that runtime. A pin is immutable selection. Switching back to Edge/Stable clears it. A rollback creates a new Config document version, preserves the immutable CDN history, and is adopted at the next server connection. It is not a server-process rollback.

​
Recorded Stage acceptance

On October 14, 2026, the implementation chat recorded completed backend/runtime acceptance for compatible pins 1.1.0 and 1.0.0, stale-version rejection, incompatible release rejection, and convergence of both Java proxies without restarts. The user confirmed the live Portal/player walkthrough: no immediate update, application after switch/reconnect, rollback, and restoration to Edge/no pin. The recorded final Config version was 10 with selector writes enabled. This is dated acceptance evidence, not a live-state assertion. Re-read the current deployment before operating it. The implementation masterplan also records a user-approved exception: Core NetworkPolicy enforcement remained off, and the separate failed 95% isolation acceptance bound was not waived. Completion of the feature checklist does not establish network-isolation acceptance or Production selector support.

​
Implementation sources

Verified against the main-branch source on October 14, 2026.