diff --git a/modules/rust/PLAN_LAST_FIXES.md b/modules/rust/PLAN_LAST_FIXES.md index dbdf4ee..903c797 100644 --- a/modules/rust/PLAN_LAST_FIXES.md +++ b/modules/rust/PLAN_LAST_FIXES.md @@ -1,8 +1,9 @@ # `module-rust` — the last fixes before the cutover -**Status:** **stages 1–5 done, 2026-10-22.** Every fix in §3 is built, and §8 names the PR for each. The -questions in §5 were answered on 2026-10-21, and the stage 4 decisions on 2026-10-22. Stage 6, the release and -the cutover, waits for the org lead's go, and §7's clean-up comes after it. Written 2026-10-21 after the end +**Status:** **all six stages done, 2026-10-22.** Every fix in §3 is built, and §8 names the PR for each. The +questions in §5 were answered on 2026-10-21, and the stage 4 decisions on 2026-10-22. **Stage 6 released +protocol 14 and cut the Rust repositories and website over to `main` the same day (§8.1).** §7's clean-up comes +next, on the org lead's go. Written 2026-10-21 after the end walk's in-game pass, as a plan. It continues [`PLAN_REDESIGNS.md`](PLAN_REDESIGNS.md) §9.1, which lists W1–W20 and N1 from the passes without a player. This document adds what the in-game pass found and puts everything in one list, in the order it should be built. @@ -177,8 +178,7 @@ site, so neither is in this list: - **Walk site:** remove A's test grants (`backpacks.use` on Oxide; the `backpacks.use` given on Carbon). - **Steam:** rotate the Steam Web API key, which was pasted into the chat that ran the walk, and put the new one in Admin → Auth → Steam. -- **The rigs' bridge:** both rigs still run stage 3's branch (Rust-Plugins#43), now merged to `edge`. The release - puts the released bridge on them. +- **The rigs' bridge:** done in stage 6 (§8.1). Both rigs run the released files of bundle 2026.10.22. - **W21** landed in stage 1 (Module-Rust#54), so the walk site's hand patch is no longer needed. --- @@ -194,3 +194,64 @@ One PR per repo per stage, each merged into `edge` (the Rust repos and website) | 3, the bridge (2026-10-21) | Rust-Plugins#43 | W3 (`world.error` `already-out`), W9 (RaidableBases' own log lines since the write), W12 (`raid.ended` carries `id`, and `runId` and `key` for a run's base). No protocol bump, because PROTOCOL already listed W12's fields. Walked on both rigs | | 4, core (2026-10-22) | website#219, Module-Rust#56 | **W19**: one module per site at boot (Q37). W1: a zone reports `until`, and a reconcile files a resource gone past it as `expired`. W5: a draft's passing dry run carries over by spec fingerprint. W2: *"Phase p1: steps done, waiting to advance"*. No MODULE_API bump. Walked on the walk site | | 5, docs (2026-10-22) | docs#367 | N1 and N2 in OPERATING.md. W20 in PLAN_REDESIGNS §14.3.4 (Q39). W22 and W23 in PLAYER_WALK, PROTOCOL §20.12 and PLAN_REDESIGNS §11.4. The wire changes stages 2–3 made without a doc edit (PROTOCOL §20.5's `already-out`, §20.12's rollback log). Stage 4's core docs: MODULE_SYSTEM §2.5, MODULE_API §4.2 and the resource `until`, EVENTS §D, §I, §K and §L, and BACKEND_DESIGN's three new columns | +| 6, the release and the cutover (2026-10-22) | website#220, Rust-Plugins#44, Rust-Link#32, installer#42, Module-Rust#57, Module-Rust#58, this document's PR | `edge` → `main` in five repositories, and core re-pinned to `main` in Module-Rust. Protocol 14 released: bundle **2026.10.22**, Module-Rust **v0.5.0** (§8.1) | + +### 8.1 Stage 6, as built (2026-10-22) + +Before anything merged, the org lead answered two questions. The Integration Kit's re-pin to core 1.17.0 is a +separate PR after this stage. The rigs move to the released bridge in this stage. The installer cannot run inside +a Pterodactyl server, because the panel offers no shell. So the org lead chose to upload the bundle's exact files +and restart, and to prove the installer itself over scratch roots. + +- **The order:** website first, because Module-Rust's `coreApi` is `^1.17.0` and 1.17.0 was only on website's + `edge`. Next came Module-Rust's re-pin, then the three bridge-side repositories together, then the bundle. Module-Rust + went last, after the bundle had composed. On 2026-10-09 the module was out eleven minutes before its bundle; + this time the order held. +- **The PRs:** website#220, Rust-Plugins#44, Rust-Link#32 and installer#42 (`edge` → `main`). Module-Rust#57 moved + `ci/core-ref.json` from website's `edge` sha `9a1654f` to the `main` sha `6890a74`. Module-Rust#58 + (`edge` → `main`). RunicNPC had nothing new and stays at v1.0.0. **No merge deleted `edge` this time.** +- **The releases, each checked against its own `SHA256SUMS`:** + + | Repository | Release | What was checked beyond the checksums | + |---|---|---| + | website | `main` at `6890a74` | MODULE_API 1.17.0. The image build and deploy passed. | + | Rust-Plugins | **v0.3.0** | Manifest: protocol 14, `runicnpc_api` 6, Oxide 2.0.7585, Carbon 2.0.259. Each of its four files matches its manifest hash, the new `RunicGatewayRaids.cs` among them. | + | Rust-Link | **v0.3.0** | Both sidecar binaries, the launcher and the egg JSON. The Linux binary answers `0.3.0 (protocol 14)`. | + | installer | **v0.8.0** | `--version` answers 0.8.0. | + | Module-Rust | **v0.5.0** | Manifest `rust` 0.5.0, `coreApi` ^1.17.0, the client chunk built in. The release JSON's sha256 is the tarball's. | + +- **The bundle:** `v2/rust/current.json` moved from 2026.10.09 (protocol 13) to **2026.10.22**: protocol 14, + Rust-Link v0.3.0, Rust-Plugins v0.3.0 and RunicNPC v1.0.0. Each hash in it equals the one in its release's + `SHA256SUMS`, RunicNPC's included. It composed in run 201. Run 200 came between the plugin's release and the + sidecar's, and Gate 1 refused the pair, as it did on 2026-10-09. +- **One red run, harmless:** Rust-Link's push-triggered release (run 39) waited for a runner. Meanwhile compose + run 200 dispatched the same workflow (run 40), which released v0.3.0 first. Run 39 had computed v0.3.0 as well. It + pushed the same tag as a no-op and got `409` from `POST /releases`. The step stops on any 4xx before uploading, + so v0.3.0's assets and `SHA256SUMS` were unchanged afterwards. The release engine works as designed. Only the + red mark remains. +- **The installer and the egg from the real bundle**, in the egg's own installer image + (`ghcr.io/ptero-eggs/installers:debian`), over a scratch Oxide root and a scratch Carbon root, with nothing + bypassed: + - Installer v0.8.0 `install --game rust` resolved 2026.10.22. It placed the bridge, the three helpers and + RunicNPC v1.0.0, each identical to its release, and a sidecar at the bundle's hash that answers + `0.3.0 (protocol 14)`. `doctor` passed the record, the plugin, the helpers, RunicNPC, the plugin config and + "2026.10.22 is current". It failed the service and the sidecar, as a relocated state directory always does. + It warned that Kits and ZoneManager are missing, which a scratch root lacks. + - The bridge section of Rust-Link v0.3.0's egg placed the same files, the sidecar and launcher at mode 755 with + the bundle's hashes, and the banner. It wrote `rust-link/bundle.json` as 2026.10.22, protocol 14, RunicNPC + v1.0.0 (`api` 6). +- **The rigs**, on Rust 25902425, Oxide 2.0.7830 and Carbon 2.0.262 (each the latest that day). Each world was + saved and the server stopped. The bundle's exact files went up through the panel's file API: the four plugin + files from the v0.3.0 tarball, `RunicNPC.cs` from v1.0.0, the v0.3.0 sidecar and the launcher. Their sizes were + checked against the release, and then each server was started. Both load Runic Gateway v0.3.0 at protocol 14, the three + helpers and RunicNPC v1.0.0 with no compile errors, and both sidecars answer `/health` at protocol 14 with the + plugin connected. Before this, the rigs ran stage 3's hand copy. It was the same code but for the version + stamps and CRLF line endings. **`rust-link/bundle.json` on the rigs still says 2026.09.26.5**: only the egg's + install writes it, and the rigs were not reinstalled. +- **The walk site:** core on website `main` (`6890a74`). Module-Rust v0.5.0 was installed through Admin → Modules + from its release URL (`module-rust-0.5.0.json`, sha256 checked, `replaced`), then restarted through the same + screen's restart route. It came back `started` at 0.5.0, and both rigs read online at protocol 14 on Admin → Rust + → Servers. +- **Not done:** a panel reinstall from the released egg. The panel's egg 25 is from 2026-09-26, and the panel has + no API for writing an egg, so testing the released egg by reinstall still needs someone to import + `egg-rust-runicgateway.json` by hand (as on 2026-10-09). diff --git a/modules/rust/PLAN_REDESIGNS.md b/modules/rust/PLAN_REDESIGNS.md index 70dfc01..147dd0e 100644 --- a/modules/rust/PLAN_REDESIGNS.md +++ b/modules/rust/PLAN_REDESIGNS.md @@ -15,7 +15,8 @@ D342–D346), planned and built the same day. On 2026-10-14 RaidableBases was de theirs and the ones still owed by §3 and §5 — happens together at the end (D331, §9).** **The end walk's rows that need no player ran on 2026-10-16 and 2026-10-19, and all of them are done (§9.1)**: W1–W20 and N1 found, W4 and W19 the real ones. **The in-game pass ran on 2026-10-21** and found W21–W23 and N2. **All of them were fixed -by 2026-10-22** ([`PLAN_LAST_FIXES.md`](PLAN_LAST_FIXES.md)); the protocol 14 release and the cutover come next. +by 2026-10-22** ([`PLAN_LAST_FIXES.md`](PLAN_LAST_FIXES.md)). **Protocol 14 was released and the cutover +landed the same day** (PLAN_LAST_FIXES §8.1): bundle 2026.10.22 and Module-Rust v0.5.0. This is a companion to [`PLAN_FIXES.md`](PLAN_FIXES.md) and [`PLAN.md`](PLAN.md). Where they disagree, this document is later and wins. Its decisions continue PLAN_FIXES' numbering at **D188**. @@ -37,7 +38,8 @@ document is later and wins. Its decisions continue PLAN_FIXES' numbering at **D1 **Protocol.** §1, §3, §4 and §5 joined **protocol 13**, which shipped on 2026-10-09 with RunicNPC v1.0.0 (bundle 2026.10.09). The wire changes still to come, §2's and §11's, **open protocol 14** on `edge` and are -released together once, after the end-of-plan walk (D332, §7). +released together once, after the end-of-plan walk (D332, §7). **Protocol 14 shipped on 2026-10-22** (bundle +2026.10.22: Rust-Link v0.3.0, Rust-Plugins v0.3.0, RunicNPC v1.0.0; Module-Rust v0.5.0). **Core.** §2 is mostly core's editor, which is game-agnostic and serves Module-uo too. Its contract additions are **MODULE_API 1.12.0 → 1.13.0**, additions only (§8; 1.12.0 went to Events' `progress()`, diff --git a/rust-link/INSTALL.md b/rust-link/INSTALL.md index a6d2a0c..29f7185 100644 --- a/rust-link/INSTALL.md +++ b/rust-link/INSTALL.md @@ -37,9 +37,10 @@ There are three ways to set a server up. They produce the same result: - **The website has the Rust module**, and you are an administrator on it. Servers are added at **Admin → Rust → Servers** (`/admin/rust/servers`). -> **The released pieces speak protocol 13 together** (2026-10-09): Module-Rust v0.4.0 on the site, and -> the bundle 2026.10.09 on the server (Rust-Link v0.2.0, Rust-Plugins v0.2.0, RunicNPC v1.0.0). A site -> on Module-Rust v0.3.0 or older speaks protocol 2 and answers `409`: update the module first. +> **The released pieces speak protocol 14 together** (2026-10-22): Module-Rust v0.5.0 on the site, which +> needs core MODULE_API 1.17.0, and the bundle 2026.10.22 on the server (Rust-Link v0.3.0, Rust-Plugins +> v0.3.0, RunicNPC v1.0.0). A site on Module-Rust v0.4.0 speaks protocol 13 and answers `409`: update the +> module first. --- diff --git a/website/STEAM_SIGNIN.md b/website/STEAM_SIGNIN.md index 2fd8659..0f86d02 100644 --- a/website/STEAM_SIGNIN.md +++ b/website/STEAM_SIGNIN.md @@ -1,7 +1,8 @@ # Sign in with Steam — plan > **Status: plan, written 2026-10-14; its questions answered 2026-10-19 (§7, D392–D396); built 2026-10-19 on -> the website's and Module-Rust's `edge` (§8).** It ships in the cutover in progress (the org lead, 2026-10-19). +> the website's and Module-Rust's `edge` (§8), and shipped to `main` in the cutover on 2026-10-22** (website#220, +> MODULE_API 1.17.0; Module-Rust v0.5.0). > The live walk with a real Steam account (§6) is owed. > It is the website's own plan for Steam sign-in, as Rust's > [`PLAN_FIXES.md`](../modules/rust/PLAN_FIXES.md) D171 set out (§4.8 there), and it is on the roadmap as the @@ -146,7 +147,7 @@ The org lead answered Q1–Q4 and ruled on the case Q1 and Q2 raised together. T ## 8. Built (2026-10-19) -On the `edge` branches of the cutover in progress, as §4 laid out: +On the `edge` branches of the cutover, which reached `main` on 2026-10-22, as §4 laid out: - **Core (`website`):** `steam.provider.js` does §3's checks and the `check_authentication` POST; `registry.js` makes Steam a built-in (priority 3) whose only requirement is the Web API key;