PLAN_LAST_FIXES gains §8.1, stage 6 as built: the merge order, the five
releases (website main 6890a74, Rust-Plugins v0.3.0, Rust-Link v0.3.0,
installer v0.8.0, Module-Rust v0.5.0) and bundle 2026.10.22, the one
harmless red release run, the installer and the egg proved over scratch
roots, the rigs on the released files, and the walk site on v0.5.0. Its
status, §7 and §8's table follow. PLAN_REDESIGNS, rust-link/INSTALL.md and
STEAM_SIGNIN.md now name protocol 14 and the cutover as shipped.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
# `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.
