# `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)`. |
> **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;
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.