RunicGateway/docs
3
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

docs(rust-link): the events player walk, and the permission walk's protocol-9 note

Browse Source 
PLAYER_WALK.md gains the events walk: the checks phases 12 and 13a left for a
person on the rig (a kit unlocking under a group-permission lease, standing
in a zone, a zone surviving a restart, looting and killing what an event
placed, a zone expiring around a player, and spawn.max_* with players on).
The permission walk now says it can only pass on protocol 9, because the
phase-7 owner bug made its steps 1-3 impossible on Oxide until then.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
This commit is contained in:
claude
2026-09-24 04:09:52 -05:00
parent 9c46b06172
commit c385de7155
1 changed files with 52 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

52
rust-link/PLAYER_WALK.md
View File

@@ -175,6 +175,15 @@ this phase has two specific things to confirm there rather than assume:
the website and nothing else; a hand edit is reported rather than undone; and a wipe costs the the website and nothing else; a hand edit is reported rather than undone; and a wipe costs the
operator nothing. operator nothing.
> **Run this walk on protocol 9 or later — before that, steps 1–3 could not pass on Oxide.** From
> phase 7 until phase 13a the plugin granted with itself as the *owner*, and Oxide silently ignores a
> grant whose owner did not register the permission — which is every permission this walk uses. The
> site showed the server **in sync** and `oxide.show` showed **nothing**; the phase 13a walk
> reproduced exactly that before fixing it ([PLAN.md §28.6](../modules/rust/PLAN.md), step 6). Since
> protocol 9 the plugin reads every grant back, and one that did not land is listed on the
> permissions screen as *sent and not found in the game's permission store* instead of being counted.
> If you see that warning on this walk, it is a finding.
## The configuration walk (protocol 5, phase 7b) ## The configuration walk (protocol 5, phase 7b)
Added 2026-09-22. The website half was walked end to end against a real sidecar and a stand-in Added 2026-09-22. The website half was walked end to end against a real sidecar and a stand-in
@@ -240,3 +249,46 @@ same three minutes as the identity walk above, done on the phone instead of in a
**What counts as a pass:** a player links an account from the phone without touching a browser, and **What counts as a pass:** a player links an account from the phone without touching a browser, and
the screen never claims an entitlement is in the game when the site has not confirmed it there. the screen never claims an entitlement is in the game when the site has not confirmed it there.
## The events walk (phases 12 and 13a)
Added 2026-09-24. Everything an event does to a server — the leases (protocol 8) and the world verbs
(protocol 9) — was walked through real core on both rigs, and every effect was checked in the game
with a console probe ([PLAN.md](../modules/rust/PLAN.md) §27.5 and §28.6). What a probe cannot do is
**be a player**: stand in a zone, open a crate, get shot at, or see a kit unlock in the menu. That is
this walk. It is §27.7's and §28.8's "not proven" lists, done by a person.
**Before you start:**
1. **Kits installed on the rig** (`umod.org/plugins/Kits.cs`, into `oxide/plugins/` or
`carbon/plugins/`) with at least one kit whose `RequiredPermission` is set — step 1 needs it, and
neither rig has had Kits yet.
2. **`EventsEnabled` on** — Admin → Rust mod config → `RunicGateway.json`. It takes effect at once.
3. **The four event verbs switched on** in Admin → Events → Actions: `core.lease`, `rust.zone.open`,
`rust.crate.place`, `rust.npc.place`.
4. **A non-admin Steam account for steps 1 and 6.** Kits applies its gate to an admin too, so step 1
works on the owner's account; ZoneManager's flags do not (§12.5), which is why step 6 wants the
second account.
Each step is an event you author in Admin → Events, publish, and start by hand. A monument is picked
from the dropdown (it lists this map's monuments by name and grid square); stand near it before you
start the run.
| # | Author this, start it, then | You should see |
|---|---|---|
| 1 | **A `core.lease` on `rust.group.permission`**: target `<server>/default/<the kit's RequiredPermission>`, value `true`, 10 minutes. Open the kit menu before and after starting it | The kit goes from **locked** to **available** when the step runs, and back to locked when the run ends or its ten minutes pass — whichever comes first. Redeem it once while it is open: the items stay in your inventory after it locks again, which is correct (the lease borrowed the *right*, not the loot) |
| 2 | **`rust.zone.open`** at a monument you are standing next to, radius 30, 15 minutes, a name you will recognise. Walk in and out of it | The zone is there: `zone.list`/ZoneManager's own `/zone list` at the console shows it with your name, and `rg.hooks` shows `OnEnterZone`/`OnExitZone` counted (13b subscribes to them; they fire either way). Walking in and out is the check a console could not make — §28.8's first item |
| 3 | **Leave step 2's run going and restart the server.** Rejoin and walk back into the zone | The zone is **back** after the restart, at the same place, with the same name — re-created from the bridge's own record, because ZoneManager forgets temporary zones. On the site the run's zone row still reads `confirmed` |
| 4 | **`rust.crate.place`**: `crate.hackable` ×1 and `crate.elite` ×3 at the same monument, spread 8. Loot one elite crate empty; start the hack on the locked crate. Then cancel the run | The crates are there and lootable, the hack timer runs. At teardown the untouched crates vanish, and the looted one is simply **gone** already — its row reads `reverted` all the same (§15.2: reverting something a player took is a success) |
| 5 | **`rust.npc.place`**: `npc.scientist` ×3 at the monument. Kill one; let the others see you | They are hostile and fight. The one you killed is just gone; at teardown the survivors vanish mid-fight. Every row reads `reverted`. If an NPC spawned **inside a wall or fell through the ground**, note the monument — some offsets land off the navmesh, and that is a finding about where to put things, not a bug to hide |
| 6 | **On the non-admin account**: a zone for 3 minutes. Stand inside it when the three minutes run out | The zone disappears around you **without anybody on the website doing anything** — the game keeps the deadline (D96). The sidecar's `/events?kind=world.expired` shows the frame |
| 7 | **If players can be arranged, a `core.lease` on `spawn.max_rate`** — these two scalars are left out of the catalogue today because they only matter with people online (§27.5) | With several players on, the population system's spawn rate moves (`spawn.report`) while the lease holds and returns after. If it does, the two `spawn.max_*` keys can be added to the allowlist; if nothing moves even with players, they stay out |
**Run steps 1–5 on both frameworks.** One thing is specific to Carbon: ZoneManager was only installed
on the Carbon rig on 2026-09-24, for the 13a walk — step 2 is the first time a *player* has stood in
a zone there.
**What counts as a pass:** a player sees what the event did and sees it stop — the kit locks again,
the zone goes, the crates and NPCs vanish — with no website action beyond starting and cancelling the
run; a restart in the middle keeps the zone; and nothing a player took or killed shows up as a
failure on the run console.