Records where the Play Console stands (7 of 11 setup tasks done), the
org lead's three decisions of 2026-10-23 (reuse the release keystore as
Play's app-signing key; CI publishes each v* tag to the internal track;
demo.runicgateway.com on the Oxide rig is the review and beta site,
website#222), what Play needs that the app lacks (target API 36, an AAB,
the upload step), the order of work, and three open questions (content
rating vs. no report/block, the data-safety premise, the dataSync push
service).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
Android-app#58 implements M20: the string split, the core rewording, the
StringVocabularyTest guard and weapon names. It also records three things
beyond the plan:
- Moderation and the support queue are gated on the shard capability now
(org lead's decision, 2026-10-23);
- the guard declares src/main/res as a Test input, so Gradle can't skip it;
- an open finding: every 503 renders as "the game server is offline",
including core's maintenance-mode 503.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
android/PLAN.md M20: the app's core screens (connect, sign-in, errors,
notifications, the push channel) stop saying "shard"; the UO screens keep
their words. Strings split by owner into strings.xml / strings_uo.xml /
strings_rust.xml with a unit-test guard using runicgateway.com's word
list, and RustFeed prints Module-Rust's new weaponName. Lands in edge
before the release that first ships the Rust screens. Org lead's
decisions of 2026-10-23.
modules/rust/PLAN.md section 36: weapons by name in the feed
(Module-Rust#60) - weaponName added at read from a table of the game's
own names for 53 ranged weapons, stripped prefab name otherwise.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
The profile field table had a blank line before the `boss` row and another
before the `loot` row. Each started a header-less block, which Gitea renders as
plain text full of pipes instead of as table rows. Removing the two blank lines
puts all three runs back in one table. No row changed.
Found by runicgateway.com phase 16 (runicgateway.com#37).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
INTEGRATION.md predated the installer: it said there was no installer
support for Rust, showed protocol-1 samples throughout, listed the uMod
Clans plugin as expected (D47 says it is deliberately not used) and
PopupNotifications as needed (optional, D141), and never mentioned
Carbon or RunicNPC. It now points at INSTALL.md for setting a server up,
takes its pieces from one bundle, and shows protocol 14's samples,
including /health's untyped_frames and --print-config's current shape.
INSTALL.md's component table and by-hand step named two of the plugin's
helpers; the release ships three. RunicGatewayRaids.cs (D204) is now
named in both.
Found while writing the runicgateway.com Rust docs (its PLAN.md §16,
phase 15).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
A's two test grants deleted and revoked on both rigs. The Oxide rig loses the
walk owner, RgKitProbe and RgWalk, and gets RaidableBases' config back from
the walk's backup, followed by a restart (N2). The Steam key is left to the
org lead.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
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
Stage 5 of PLAN_LAST_FIXES (docs#366).
- OPERATING.md: a RaidableBases section. Change its config with a
restart, never a reload (N2); switching to the free edition rewrites
a paid pack's profiles (N1).
- PLAN_REDESIGNS 14.3.4: no manual retry for Dangerous Treasures (Q39,
W20); 11.4: which hook rbevent setowner raises (W23); 9.1 status.
- PLAYER_WALK: rows 2.2, 2.8 and 2.9, Before you start item 8 (BetterChat
and the four title rules), Carbon's share trimmed to 2.11 (W22, W23).
- PROTOCOL: 20.5 world.error already-out (W3), 20.12 the rollback's log
is RaidableBases' own (W9) and setowner's two hooks (W23).
- Core, from website#219: MODULE_SYSTEM 2.5 and MODULE_API 4.2 (one
module at boot, W19), MODULE_API and EVENTS L (a resource's until read
at reconcile, W1), EVENTS D/I/K and BACKEND_DESIGN (a draft's dry run
carried by fingerprint, W5), EVENTS observability (W2's words).
- PLAN_LAST_FIXES: status, Q37-Q40 answers, 7 updated, 8 what was built.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
The end walk's in-game pass ran on 2026-10-21. PLAN_LAST_FIXES.md records
what it passed and what it found, and puts every fix still open in one
list in building order: W1-W20 and N1 from the passes without a player,
plus the in-game pass's W21 (a reward's message is never pushed to the
game), W22 and W23 (walk and protocol docs that expect the wrong thing)
and N2 (reloading RaidableBases breaks it). It also asks Q37-Q40, lists
the rows still owed with a second player, and the clean-up after the
walk. PLAN_REDESIGNS and the README point to it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
PLAYER_WALK.md gains one section covering every row still owed after the
end walk's four passes (PLAN_REDESIGNS §9.1), plus Steam sign-in's live
walk (STEAM_SIGNIN §6). Steam comes first because linking A's Steam
account is also what makes A a linked Rust player (D392) for the reward
rows. Rows that already passed are left out. B-only rows and the phone
are split into their own parts, and AutoDoors 3.3.12 replaces
NightVision as the perk plugin.
PLAN_REDESIGNS §9.1 and STEAM_SIGNIN §8 point to the new section.
STEAM_SIGNIN §8 also records Module-Rust#53, the core pin moved to
#218's merge.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
STEAM_SIGNIN.md gains its Built section (section 8) and status;
MODULE_API.md records 1.17.0 (ctx.identities.list, onIdentityLinking,
onIdentityLinked); BACKEND_DESIGN.md gains the auth_providers /
user_identities shapes, the identities route with ?id=, and the Steam
security notes in section 6; PLAN_REDESIGNS section 15 notes the build.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
The org lead answered STEAM_SIGNIN.md's Q1-Q4 on 2026-10-19 and ruled on
the conflict they raise together:
- D392 a Steam account linked on the site is a linked Rust player (Q1)
- D393 unlinking Steam removes only the sign-in identity (Q2)
- D394 Steam needs a Steam Web API key to be enabled (Q3)
- D395 Steam never signs anybody up (Q4)
- D396 a Steam link whose id is another account's Rust link is refused
The build section follows: the key is required, the identity row keeps the
persona name and avatar, and MODULE_API 1.17.0 adds a pre-link check (which
can only refuse) and a linked hook, with no unlink hook. PLAN_REDESIGNS
tables the three decisions Module-Rust builds to and points §15 at them.
The build goes on the website's edge and ships in the cutover in progress.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
The fourth pass (2026-10-19) ran every row left that needs no player:
Carbon's halves of Economics, Backpacks, §12.9 and §13; the last hit
differing from the blow; the balance limit; a lost answer for a payment
and for console commands; a for-good grant deleted; a Module-uo event in
the editor; Dangerous Treasures after a hotload; a Guarded Crate timing
out; Server settings' ZLevels line; Carbon's config reload and console
probe.
Findings W15-W20, W19 the real one: Module-uo and Module-Rust cannot
share a site (both fill admin.users.detail). Two rows not reachable
(NpcSpawn guards ignore NPC damage; W20). The player list is updated.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
PLAN_REDESIGNS gains §9.1: the three no-player passes of the end walk
(2026-10-16 to 2026-10-19), what passed, findings W1-W14 and N1 (W4 the
one real bug), and what is still owed with and without a player. A row
that has passed is not walked again (the org lead, 2026-10-19).
PLAN.md: runicgateway.com moves out of phase 19 into a new phase 20,
a game-agnostic rewrite that adds the Rust module (org lead,
2026-10-19). Phase 19 notes Module-Rust's early cutover in 9e.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
- rust-link/PROTOCOL.md §20.12: RaidableBases — hello's raidableBases, the
five raid.* events, the tally's raidsCompleted, map.live's raids layer (and
its §17.3 row), raid.spawn and raid.check with their refusals, the raids
helper, the profiles in the configuration editor, the sidecar's two
forwards and the website's step, feed, map layer and Warlord.
- modules/rust/PLAN_REDESIGNS.md: D391 (the editor's spot check is advice
through core), §11.4.6 (what was built, the rig tests on both rigs, the
Oxide rig's RaidableBases fault that a restart cleared, twelve points
settled in code, the end walk's rows), and the order of work.
- website/MODULE_API.md, EVENTS.md: 1.16.0, a dry run's detail.warnings.
- website/STEAM_SIGNIN.md: its contract moves to 1.17.0.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
The org lead took the proposed option for all four, 2026-10-16:
- D387: spot spawns take the helper's route on both editions when the helper
is installed; the paid SpawnRandomBase only without it.
- D388: the area check refuses for buildings, deployables, raid bases,
players and water; rocks and cliffs are a warning (amends D208).
- D389: "in water" is refused unless the profile has a seabed chance above 0
or allows floating bases (amends D208).
- D390: lockouts dropped from the feed; paid purchase and admin-lock lines
added, name only for the presence audience (amends D202).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
The current paid copy arrived on 2026-10-16: RaidableBases 3.2.2, the same
version as uMod's free edition, with the tier-3 base pack. Spiked on both rigs
(Rust 25902425, Oxide 2.0.7830, Carbon 2.0.262).
- The 3.0.5 drift was old against new; what is still paid-only is listed.
- Difficulties are operator data (name + level per profile); an invented one
was listed and spawned. D386: every name is read from the plugin.
- The private SpawnRandomBase(base, pos, level, type, free) is reachable by
Call on both frameworks; it runs no area check at a given position.
- Paid RaidableType inserts Purchased at 3: bind by name.
- An unload fires Completed for every live base (owner 0, no raiders).
- The helper's internals all hold on both rigs; PvP must be set on the base
after OpenEvent (the config's Convert switches win over the profile copy).
- Grid: 666 s / 507 s after a plugin load on the 6000 map; rb.reloadprofiles
is refused meanwhile.
- Routes per part, and Q33-Q36 for the org lead.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
- rust-link/PROTOCOL.md §20.11: command.run in its three shapes (once with a
stored teardown, per online recipient with {steamid}/{name}, teardownOf),
the at-most-once key file, the frame budget, command.ran / command.error
and their reasons, how unknown-command is told (the game's log line, not
Run's return), POST /commands/run, and the website side.
- modules/rust/PLAN_REDESIGNS.md: D385 (the bridge keeps a step's teardown
with its key, asked during the build), §16.10 the build record (three
spike findings, the rig run, twelve settled-in-code points), a D385 walk
row in §16.9, pointers from the status paragraph, §9 and §10.
- website/EVENTS.md: an action can be text the module cannot read: what
core already bounds, and the two things a module copying it needs (a
failed step's revert has only the key; `multiple` drops duplicates).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
- PLAN_REDESIGNS §16: two Module-Rust actions within the event system
as it stands. `rust.command.run` runs typed console commands once on
one server, with optional teardown commands; `rust.command.reward`
runs them once per recipient from the run's tally, with {steamid}
and {name} filled in by the bridge. Both irreversible, both behind
an "I am sure" toggle, priced in a new `rust.commands` budget.
- The wire: a `command.run` frame and POST /commands/run, joining the
unreleased protocol 14; an at-most-once key file in the bridge;
`unknown-command` stops a step at the first "not found".
- D382 (the item), D383 (offline recipients skipped, not held),
D384 (no allowlist: a free text box). Settled-and-overrulable
points, the build order (one stage, before RaidableBases), and the
walk rows, which join the end walk.
- Pointers in the status paragraph, the summary table, §9 and §10.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
- EVENTS.md §E "Starting a run from a trigger": `starts`, the third
emit subscriber, the four rules (verified, one at a time, cooldown,
no event.*), the run's origin, and what is deliberately not in it.
§D: event_runs.origin and a twelfth table, event_trigger_starts.
API surface: triggerStarts on GET /admin/events/:id, origin on the
run console.
- BACKEND_DESIGN.md: event_runs.origin and event_trigger_starts.
- PLAN_REDESIGNS §14.3.21: stage 9 as built, eight settled-in-code
points, tests and the Module-uo proof; pointers in §9, §14.3.11 and
§14.3.12. This ends the §14.3 build.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
The org lead does not want Server Rewards. D381 records it and amends
D350, D369, D375 and D377; §14.3.7 becomes a dropped note, the wire
table loses points.*, the tally's points and the sidecar's /points/*
routes, and stage 8 of §14.3.11 is struck. Nothing had been built.
§14.2.1's test findings stay as a record.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
PROTOCOL.md §20.10: hello's integrations.zLevels, and nothing more
(D374). PLAN_REDESIGNS §14.3.20 records the build, two points settled in
code, the tests and the rig check; pointers from §9's summary and
§14.3.6.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
