WorldOfGonz Railway release operations

Routine releases use the existing private GitHub repository nielsjensby/WorldOfGonz and its main branch. Railway production follows main through its GitHub deployment trigger and waits for GitHub Actions before deploying. A fixed commit pin must not be added during ordinary releases, because it stops later branch updates from deploying automatically.

Authorized project scope

The user requested unattended Railway operation on November 3, 2026. This covers normal WorldOfGonz releases and monitoring within the existing production service. Keep all artwork originals, selected finals, approved references, both Citadel outer hamlets and persistent saves. Deployment does not grant artwork approval or erase any role, context, fidelity, performance or lifecycle gate.

Project: c88ac6fe-13c0-45de-94c6-50fc23f819fd. Service: e6b2d196-f7c7-42aa-a700-966133aabef2. Production environment: 8b8d7edc-5214-4921-bd77-d67e5d0dfd8b. Keep the existing /data volume and its contents intact.

Routine release sequence

1. Prepare a focused commit, preserving unrelated worktree changes. Run applicable asset checks, native preservation comparisons and wiki generation/checks. Keep the large catalog JSON compact and check every prospective Git blob against GitHub's 100 MiB file limit before publishing. JSON compaction must preserve every parsed field and record, source approval, artwork hash and pending gate; verify the semantic digest and update the current root/checksum evidence. Never substitute an LFS pointer for a runtime JSON registry or alter artist bytes to satisfy this textual metadata limit.
2. Publish the prepared branch and inspect its CI result. Advance main with an expected-head lease so concurrent work is preserved.
3. Let Railway's GitHub trigger handle deployment. Wait for CI is enabled: failed workflows prevent production promotion according to Railway's documented check-suite rules. Do not use a fixed source commit or an extra manual accept-deploy step for ordinary branch releases.
4. Inspect the actual deployment status and build/runtime logs through the connected Railway tools. Distinguish WAITING, BUILDING, DEPLOYING and SUCCESS. Never restart a healthy service or duplicate a build merely to test access.
5. After SUCCESS, verify public health, exact catalog and selected image bytes, inventory membership and relevant desktop/phone Atlas views. Only then record the release as live.
6. Retire the current transaction's temporary inputs after preservation checks. Keep compact findings, hashes, final verification and bounded decisive witnesses. Stream or compare raw browser buffers in memory. Follow the final-asset-release-20261102 storage policy; never rebuild retired QA mirrors.

Authentication and operational tools

Connected access was rechecked on 2026-11-05T12:12:27.474Z using service configuration, production health and build/runtime logs. All calls succeeded without user assistance; production remained online with one healthy replica, CI-gated main deployment, no commit pin or pending changes and the existing /data mount. This read-only access check did not deploy or restart the service.

The connected Railway plugin already has the app-specific Allow all actions permission. Its OAuth session supports normal reads and configuration writes without another login. The installed railway.exe is blocked by Windows application control; do not weaken Windows controls or depend on this binary for routine releases.

For every resumed release, first use the connected tools to verify authentication, the exact project/service/environment, the main source with Wait for CI, the current deployment and the existing /data mount. Check GitHub main and CI against the intended commit. Read logs and resume any deployment already in progress. The standing routine-release authorization is also recorded in AGENTS.md, so ordinary publication, deployment and live verification do not need another approval request. Do not create a throwaway deployment just to test access.

If the local CLI token has expired while connected calls work, continue through the connected tools and the existing GitHub trigger. If the connected account itself loses access, report the actual authentication or permission error; session expiry cannot be prevented by this runbook. Keep credentials in the existing credential stores and never copy them into project files or release receipts.

The latest connected access check read production configuration, environment health, the current deployment and build/runtime logs without a CLI login. GitHub main and successful CI both match live commit e296e0fceda049982d976e3dbbf46890e1410c1c. The latestConnectedCheck field in railway-access-20261103.json records the verification.

The project-scoped scripts/railway-project-access.cjs helper can inspect and idempotently configure this service's GitHub trigger and source policy through Railway's documented API. It reads the existing user-level Railway OAuth session in memory and never copies credentials into this repository, logs or CI. It has no delete, billing, volume or restart operation. Its local access token may expire; use the connected Railway tools for normal monitoring. The persistent GitHub trigger does not depend on that local CLI token.

The helper's configuration-only source update uses skipDeploys=true. Its only allowed target is this project, service, production environment, repository and main branch. Wait for CI must remain enabled. Sensitive or destructive infrastructure changes require their own task authorization and applicable platform checks.

Verified configuration and evidence

The November 3 setup found no GitHub trigger and source pinned to 61e9d03. It created the production-only main trigger with Wait for CI and removed that pin without requesting a deployment or restart. Fresh API reads verified the trigger and source policy, and a full environment-configuration comparison verified that other settings were unchanged. The configuration receipt is railway-access-20261103.json; the end-to-end release result is recorded separately after actual execution.

Official references: GitHub auto-deploys, Railway API, Railway MCP.

<!-- latest-unattended-access -->

The latest unattended release completed on 2026-11-05T12:11:42.830Z. Commit e296e0fceda049982d976e3dbbf46890e1410c1c deployed automatically as a0877dfa-6abe-4356-b78a-e0e34eb2f7c4 after successful branch/main CI. Fresh connected Railway calls on 2026-11-05T12:12:27.474Z verified main with Wait for CI enabled, no commit pin, no staged or pending work, one healthy replica and the unchanged 50,000 MB /data volume. Build and runtime logs are readable without a local CLI login.

Live checks passed the 9,217-member catalog/inventory, 5 exact native image identities including both Citadel hamlets, 6 painted desktop/phone Atlas views, 10 wiki pages and 7 unchanged runtime/manifest files, with zero browser errors. Closeout cleared 2 matching evidence leases. 1 native artist study was added; no original artist file changed and no source admission or production-world appearance frame was added. See the live checks ../art-direction/keep-lodge-native-matte-20261105/live-verification.json and release closeout ../art-direction/keep-lodge-native-matte-20261105/closeout.json.

Future routine releases use AGENTS.md standing authorization and the connected session. Do not ask again for routine publication or deployment approval, or require a CLI login while connected access works. Publish focused verified changes with an expected-head lease, let the CI-gated GitHub trigger deploy, resume an existing build and verify actual live results before closeout. Do not create a duplicate deployment or restart to test access. Connected-account revocation or provider-required reauthentication may require reconnection; local CLI expiry alone does not. Access receipts contain no credentials.

<!-- /latest-unattended-access -->

<!-- railway-snapshot-failure-recovery-20261105 -->

If a terminal failed deployment has no reusable image, first inspect its logs and Railway diagnosis and verify the previous release is healthy. A source-upload/snapshot failure is distinct from an application-build or healthcheck failure. When the connected redeploy tool reports canRedeploy=false, preserve the failed attempt and use a focused operational-evidence commit through the existing CI-gated main trigger to request a fresh build of the same verified asset data. Do not create a new service, pin a commit, restart the healthy release, change the volume or weaken checks merely to recover a snapshot. Resume an active attempt instead of creating a duplicate. The November 5 failed attempt 4c8215bb-653e-45ad-9862-7e26336e0ac0 has source-upload/unpack logs and an infrastructure diagnosis; its exact low-level cause is not visible. The previous 416f674 release remained online. Failure evidence and recovery scope.