- USER_SAFETY.md: section 5 becomes decisions S6-S10 (an account to report,
game-identity blocks allowed, staff cannot be blocked, a block only hides,
staff see hidden chat marked).
- DEMO_MODE.md: DM33-DM35 (visibly fake 1234567890-prefixed Steam and
Discord ids plus the org lead's own Steam id; Rust-themed invented names).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
- website/USER_SAFETY.md (new): report, block and hide on the website and
in the app, S1-S5 decided by the org lead, five questions open.
- android/PLAN.md: M8's three open items decided (keep the rating and add
report/block/hide; conservative data safety; UnifiedPush on specialUse
with restart on boot), the order to the cutover, and M21 (Teams and the
team forum in the app, planned, not scheduled).
- website/DEMO_MODE.md: DM32 and section 11, the demo content plan (two
seed passes; moderation, Teams/forum/reports, event history, Rust stats).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
The 12:00 UTC wipe on 2026-10-28 installed Module-Rust v0.6.3 (its first run
tagged v0.6.2 and failed to publish it). play-review walked 19/19, the seeded
events' actions came up enabled and Server greeting ran, and both Steam
unlinks answer 403 DEMO_LOCKED with the link kept.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
DM27 locks removing a Steam link on the demo (player route by demoLocks,
staff route in its handler); DM28 has seed:demo switch on the actions the
seeded events use; DM29 leaves SECRET_WORDS as is. The Chrome problem was
local to the walker's PC, and play-review is walked once the fixes land.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
Every lock through the API (87 checks), the console deny list at save on the
demo and at run on a local core, the three published logins in the browser,
the app on the public HTTPS address, and one wipe cycle restoring a changed
config, permission, NPC placement, event and hero draft. Lists what the walk
found: seeded events whose actions start disabled, the credential check
over-flagging, play-review not walked, the open Steam unlink, empty
moderation queues.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
The first restored wipes brought the default set's permissions back but
not its NPC profiles (the restored rig is marked managed, so a fresh site
adopts none and its first push empties them) or its chat titles (never
adopted). §7.1 records the exception, §7.3 the fixture's new npcs and chat
keys, step 5 of §7.3 the NPC push, §9.1 DM26, and §10 step 5 the default
set, the baseline, the restored wipes and the public URL (Cloudflare set to
DNS only so the app logs the real visitor).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
DEMO_MODE.md §3.3 gets the data: URI rule (a pasted image is an upload),
§9.1 records DM25, and §10 step 5 records the first wipes: the rig half
worked, and the seed loaded no module because the runner's chown of
modules/ and logs/ failed silently. BACKEND_DESIGN.md §5.1 mirrors the rule.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
DEMO_MODE.md follows website#227:
- §7.2: the baseline is captured with a power stop (quit saves), DM22; a
first wipe with no baseline only starts the rig; what the panel calls
were checked to do (synchronous decompress, binary-safe write); the
server identifier is now 6eb9d621.
- §7.3: MODULES comes from state/modules.env; MODULE_SOURCE_HOSTS seeds a
fresh database's allowlist; the exact seed:demo command.
- §7.5: where the bundle is recorded (state/bundle.json and the rig's own
rust-link/bundle.json) and which plugin files the wipe writes.
- §8: the deploy directory and the full .env contents.
- §9.1: DM22 (power stop), DM23 (/opt/demo.runicgateway.com, host mode),
DM24 (Module-Rust cut over now, v0.6.0).
- §10: step 5's files built and how each half was tested.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
DEMO_MODE.md: hero_layout joins the "Settings that reach a lock" row, a
paragraph under "Settings stay open" says what the hero editor does on the
demo, DM21 records the decision, and the step-5 walk checks it.
BACKEND_DESIGN.md: the protected-keys list in the demo section.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
- DM19: the app shows a refusal as one snackbar with the server's sentence;
lines that blame the role say the demo sentence; ErrorKind.DEMO_LOCKED for
load screens. §3.1 rewritten to match.
- DM20: the app shows the banner only; its strip names the site's sign-in page
for the passwords (§6).
- §10 step 4 built as Android-app#61.
- android/PLAN.md §7: the demo's refusal and strip.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
DEMO_MODE.md §10 step 3 is Integration-kit#17. The kit pins the sha
website#224 merged as. Chapter 2 gains a section on a public demo site,
covering demoLocks, ctx.demoMode and onDemoSeed. Chapter 5 covers
demoRefuses. Module-Rust's pin moves to the same sha in Module-Rust#63.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
DM18 (org lead, 2026-10-24): core's event save never asked a module
about a step's params, so the console-command deny list's save-time
refusal is a new core hook, demoRefuses(params), asked at create, save
and publish on the demo. MODULE_API 1.19.0.
- DEMO_MODE.md: §3.4 says where the save-time check lives; DM18 row;
step 2 marked built (website#224, Module-Rust#62) with the module's
bridge recognition and fail-closed rules; the Rust fixture section.
- MODULE_API.md: 1.19.0 in §1.1, the changelog, the registerEventActions
signature and the action rules.
- BACKEND_DESIGN.md §5.1: event steps on the demo.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
- DEMO_MODE.md: DM15 (onDemoSeed), DM16 (POST /auth/register locked), DM17
(sessions route locked outright on a demo account). It also covers the settings
keys that reach a Tier A lock, how demo accounts are recognised, failing
closed, the published logins, the toast, the seed's fixture shape and $env,
and the fact that there is no seeded team (Teams come from the rig's clans).
The §3.2 example drops the config-file POST that DM14 opened. Step 1 is
marked built.
- MODULE_API.md: 1.18.0. demoLocks in module.json, ctx.demoMode, and
api.onDemoSeed, which must upsert because it runs on every seed.
- BACKEND_DESIGN.md: §5.1 demo mode, and demo_state in the settings table.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
Visitors may read and change every plugin config except the bridge's: the
editor's save reloads through the bridge (with rollback, D178/D179), not
the console, and the wipe restores oxide/config. The RunicGateway plugin's
files are refused for reading as well as writing and left out of the file
list, because they hold credentials for talking to the sidecar directly.
Because the editor masks secret fields only in the form today, the demo
also redacts flagged values server-side, makes them read-only, refuses
raw-JSON saves, and leaves the sidecar URL out of the Servers admin view.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
DM11: console-command steps keep running on the demo except a deny list
(quit/restart, oxide.unload/reload, rcon.*, fps.limit, server.tickrate),
matched on the normalised first word (global. stripped, o. mapped to
oxide.) and enforced by the module at save and at run behind a new
ctx.demoMode.
DM12: "latest" follows the Rust bundle for the rig's plugins and sidecar,
the newest Module-Rust release on the same protocol (a new protocol field
in its install manifest, which core's installer ignores), and the website
main image. If nothing matches yet, the wipe keeps the previous set.
DM13: only settings stay open. The org lead created the Pterodactyl
subuser and added PTERODACTYL_CLIENT_KEY.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
The org lead's answers of 2026-10-23: demoLocks in module.json, settings
open, the rig open but reset each cycle through Pterodactyl, content open
with uploads locked hard, the Oxide rig as the demo's, a stand-in Steam
link, every 2 hours, files in website/, latest versions, and every lock at
the server route level.
Adds the rig reset (§7.1-7.2): the site's first sync imports what is on
the rig (D198, D244), so the rig is restored from a baseline archive
before the site relinks, and that first import is the reset. Adds the
hard upload rule (any multipart body refused). Three follow-ups: F1
console-command steps, F2 "latest" across the bundle, F3 reading of DM2.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
The design for website#222, before any code: one DEMO_MODE flag on the
normal image that locks destructive writes with a 403 DEMO_LOCKED, four
published static logins, no outbound mail/push/Discord, a banner with the
next reset time, and a scheduled wipe on the demo-site runner (drop the
volumes, redeploy, seed accounts + the rig link + content).
Tier A locks are listed route by route. Nine questions for the org lead
(module lock declaration, the rig, visitor content, rig sharing with
walks, the stand-in Steam link, cadence, where the files live, version).
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
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
- 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
- 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
- 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
- MODULE_API.md: 1.15.0, the failure envelope's retryAfterMs (clamped to
one to thirty minutes, one attempt, ignored beside retry: false), the
rule bullet and the registration line.
- EVENTS.md §F: the envelope rule and the flat delay as a default.
- STEAM_SIGNIN.md: its module contract moves to 1.16.0.
- PLAN_REDESIGNS: §14.3.15, the stage-2 record (six settled points, the
test-harness gap found on the way), and pointers from §9's summary and
§14.3.13.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
The org lead answered §13's and §14's questions on 2026-10-14:
D353 public feed with name and grid, staff adds the Steam id; D354 an
event can call a vanilla event, kept at teardown; D355 every world event
is a trigger; D356 Safecracker and Scavenger; D357 protocol 14; D358
BotReSpawn stays out; D359 the end walk waits for RaidableBases (against
the proposal), recorded in §9 too.
D360: Steam sign-in in the same manner as Google and Discord, kept on
the website's plan (D171). New website/STEAM_SIGNIN.md (OpenID 2.0
adapter, the build per repo, security, tests, Q1-Q4), indexed in the
README, linked from PLAN_REDESIGNS §15 and PLAN_FIXES §4.8, and on the
roadmap as the website milestone "Steam sign-in" (website#214).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
- website/MODULE_API.md: 1.14.0 in §1.1 and the changelog — `multiple: true`
with `max` on a string/int action param, the JSON-array value, a bare value
as a list of one, refused on a duration, a template input and a list
example; the catalog serves both keys; the editor's multi-select;
Module-uo unaffected. §2.4's registerEventActions line names it.
- website/EVENTS.md §F: the param that holds several values and its control.
- modules/rust/PLAN_REDESIGNS.md §12.10: built in website#213 and
Module-Rust#42, with the eight points settled in code, overrulable.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
The contract half of website feat/event-step-editor (Rust PLAN_REDESIGNS §2):
MODULE_API.md §1.1/§2.4 gain registerEventTemplates, a param's duration, a
lease's example and an option's note; EVENTS.md §F (the note), §I (what the
1.13.0 editor settled) and the API surface (the templates route, draftAhead).
PLAN_REDESIGNS §2.8 records the core half as built and the Module-uo proof.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
- website/MODULE_API.md: 1.12.0, an event action's optional
progress(): its envelope, its two answer shapes, and the rule that it
answers for one reader and never fails loudly.
- website/EVENTS.md §I: a live occurrence's progress lines.
- rust-link/PROTOCOL.md §17.3: map.live's RunicNPC rows (name, key,
boss, health, add) and the world layer's boss.
- runicnpc/PLAN.md: stage 8's design renamed live -> progress, and its
"Built" section, with the branches, the tests and the walk on both
rigs in the browser and on the emulator.
Also recorded in the plan: a core finding outside this stage. The
public page never shows a live run's phase label, because phaseLabel
looks phases up by id while specs key them by key.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
Walked on a core running Module-Rust#22 on website#209 against rust-oxide:
F8, F13/F14, F7, F5/F6 and the helper's state all pass. The expiry walk found
a run left cleanup-pending for ever when its last resource expires while it
runs; website#209 now settles it, and EVENTS.md §L says so.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
The spec for PLAN_FIXES §6 step 2, as built (D181-D185):
- PROTOCOL.md §19.4 world.expired's `what` and the website recording an
expiry (amends §15's "maps it to nothing"); §19.5 plugin.loaded /
plugin.unloaded with the permission diff; §19.6 the ZoneManager helper and
`zoneHelper` at hello; §19.7 what the tally counts (F1, F3, F4); §19.8 the
website (F7 hold, F5/F6 link fleet, F2 names).
- MODULE_API.md 1.11.0 and ctx.events.expired; EVENTS.md §L the `expired`
status, terminal and green, and `resource.expired`.
- rust-link/INSTALL.md: the helper in the tarball, by hand, and in doctor.
- PLAYER_WALK.md: events step 6 can pass now; a step-2 section whose rows 1-2
were walked on both rigs without a player and 3-9 need one.
- PLAN_FIXES §6: step 2 as built, with its PRs.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
- PLAN.md §31.5: what was built in website and Android-app, where the
build departed from §31.2, and the seven-step emulator walk.
- §31.6: what the walk found: the zoom lost twice (fixed), the tally a
stand-in cannot feed, the off-grid row the frame clamps, the "wiped
Dec 31, 1" header, the card that outlives its marker.
- §31.7: what is not proven (a real player, a counted tally, a UO site).
- Phase row 15 and the Android plan's M17 marked built and walked.
- EVENTS.md § API surface: the public calendar's run entries carry
runId (D125). BACKEND_DESIGN defers event routes to that table.
- PLAYER_WALK.md: the map and events on a phone, for the person-parts.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
MODULE_SYSTEM.md §2.5 and Part 3 record the org lead's rule from
2026-09-23: core's installer refuses a module whose id differs from the
one installed, with 409, and accepts only upgrades. MODULE_API.md's
registerTeamProvider section says why: a second provider fails that
module's whole load.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
Records the Asset Bridge `edge -> main` cutover: §16's 9b row, §17.15's four
org-lead decisions, and the `PARSER_VERSION` correction those forced through
§7, §10.4 and `SPAWN_ATLAS.md`.
## The number had to move, and the reason generalises
§10.4 wrote phase 7's canonical-read-order bump as `PARSER_VERSION` 4 -> 5.
`main` had meanwhile bumped 4 -> 5 for the `UniqueId` fix and RELEASED it as
v1.2.2. Same number, different derivation. An install that imported under
v1.2.2 stores 5, so a phase-7 build also declaring 5 is read as current by
`currentParser` and never re-reads -- the exact failure the constant exists to
prevent, reached through a merge instead of through forgetting to bump.
Two long-lived branches bumping one counter for different reasons is a defect
the counter cannot see; only the merge can. The docs now carry both meanings --
5 as main's released one, 6 as phase 7's -- rather than collapsing them.
## The cutover is five repos
`installer`'s `edge` carried 9a's `libgdiplus` `doctor` check, and
`SHARD_PREREQS.md` on `main` had been describing that check as existing since
phase 1. §16's 9b row named four repos and would have left an operator-facing
doc naming a check in no released binary.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4
The Asset Bridge's docs pass, and the acceptance walk that shaped it (v8.md §16
row 9a, §17.13-14). Phase 9 is three legs now: this one, the edge->main cutover,
and the site.
## INTEGRATION.md had stopped at 6 and contradicted itself
Its §2 said "the current version is 6" above examples already carrying
`X-UOLink-Version: 8`, there was no protocol-7 paragraph, and `assets.` appeared
zero times in 1,306 lines. It is the only document an integrator outside this org
has, so it is carried the whole way: the version block corrected, v7 (the event
plane's command half) and v8 (the asset plane) written, a §5 section for the five
routes, 425/422 in the status table, and a caveat that the asset plane is a
working set rather than a stream.
Protocol 7's absence is the Events workstream's debt rather than this one's, but
it cannot be stepped over on the way to 8.
## The operator-facing half
`UPGRADE_NOTES.md` gains the entry an operator reads when this ships: what
changed, the one required action on a Linux host, and the thing that will not
announce itself -- nothing here happens on a restart, so a patched client keeps
serving the old pictures until somebody presses a button.
`installer/INSTALL.md` gains libgdiplus as a prerequisite row and the `doctor`
row that checks it. The index rows for SPAWN_ATLAS and CLILOCS described the
workflows this protocol deleted; v8.md now has an index row of its own, and v7 is
marked as the released protocol.
## The walk
Wiped every asset row and every imported sprite, then walked it as a new
operator: 1,095 portraits in 3.18 s, 67,496 names in 1.42 s, 313 item pictures in
1.38 s, the atlas over the bridge in ~2.0 s, an Update with no drift answered in
0.99 s. Bestiary portraits are the right animals by eye; the marketplace shows
hued item art with cliloc names.
It found two defects (§17.14) and one cutover hazard: module-uo's `edge` is
behind its `main`, missing #35, so the walk measured 0 of 6,455 spawners carrying
a UniqueId. 9b's row says to sync before merging or the cutover ships a
regression.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4
v8.md section 12.2 records the admin surface as built: one page, Admin -> Client
Files, over the creature catalogue, item and land art, and the cliloc table --
one page because they come off one client install and change on one event. The
four decisions are written down, including the one that kept the phase to a
single repo: section 14's "activity view" is the last import's own summary
rather than a filtered feed, which would have needed a core activity filter, a
`ctx.activity.list` helper and a MODULE_API bump to re-read rows the panel can
keep itself.
The part worth reading twice is what the walk found. Two of the three defects
were DELETIONS, both predate phase 8, and neither was reachable by a test that
did not already suspect them:
* the body import diffing its manifest against every family's rows, so 313
item pictures were staged for deletion under a sentence that was wrong about
what had happened;
* an approved vanish unlinking the sprite and keeping the row, so the key came
back for review forever and the count never moved.
The rule they share is now stated: after phase 5, `shard_assets` is three
collections in one table, and every read of it that feeds a decision has to say
which one it means. Two of the three that did not were deletions.
CLILOCS.md and SPAWN_ATLAS.md now name the button that exists (Admin -> Client
Files) instead of the one they promised, and modules/uo/API.md records that a
`needsReview` reply carries each vanished key's picture.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4
10 said the shard would serve `tree/<label>` -> bytes. Measured against a stock
57.4 tree it cannot: Spawns/trammel.xml is 4.03 MB, the sidecar discards any
inbound line over 1 MiB, and that file as one base64 row is 5.4 MiB. It would be
dropped, time out, and be re-requested forever with no error in it anywhere --
and two files on a STOCK tree are in that state.
10.1 records the three carriages measured before anything was written, and why
the winner is not the smallest one: whole-file gzip is 1.21 MB against chunked
gzip's 1.26 MB and is bounded by nothing, so it works on every tree anyone would
test and fails on the first one nobody did. The chunk is the guarantee; the
compression is only the saving.
10.2: it is a `tree` family on assets.fetch, not 14's separate tree.* commands
-- phase 5's registry already owns the single slot, the envelope, the ceiling
and the mid-import guard, so reusing it left `link` with nothing to do for the
third phase running. Its CONSENT is its own, though: Bridge.TreeEnabled, because
declining to serve an EA-licensed client is not the same as declining to serve
the spawn files an operator wrote, and the atlas would have been the casualty.
10.3 records the two defects and which harness found which. An empty `catalog`
is not an absent one. And GZipStream writes nothing at all for zero bytes of
input, which stock ServUO's two empty decoration files walk straight into -- an
offline probe called that a success, because .NET's own decompressor reads an
empty stream as empty data and the declared length and hash both agree with it.
Only a live walk through a reader on another runtime disagreed.
10.4: one canonical read order, because the decoration index keeps the first
item id it sees and the two readers agreed by coincidence rather than by
construction. PARSER_VERSION 4 -> 5.
10.5 has the end-to-end numbers against a live shard. 17 gains the phase's three
decisions, including the one that departed from the recommendation: boot never
calls the shard, so an install on the bridge has no automatic refresh at all.
SPAWN_ATLAS.md is rewritten around the two sources and stops requiring a shared
filesystem. Protocol stays 8; EXTRACTOR_VERSION stays 3.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4
§16 planned deep animation keys and a bulk-fill switch. Measuring first changed
the phase: a complete one-direction animation set is 174,453 frames / 281.5 MB
(not the ~119,000 / ~117 MB §11 estimated), every frame carries its own centre
and 23,818 of 26,274 actions have frames of differing size — and the site
displays still pictures. So none of it was built (§11.2, org lead 2026-09-11);
`body/<id>/a<n>/f<k>` stays named in §5 and refused in practice.
§4.10 is what the walk found instead. A body's actions are a contiguous band and
the next body's begin immediately after, so one action past the ceiling is a real
record of another creature: 643 of 795 legacy bodies pass every check there and
452 are byte-identical to body+1's action 0. `Animations.GetAnimLength` is not
the ceiling — it disagrees with the index arithmetic on one body of this client,
by nine actions.
What shipped: the 73 bodies with no art at action 0 (a horse at `body/820/a23`),
the catalogue key carrying its action, the atlas join that reads it instead of
hardcoding `a0`, and the ceiling that makes the fallback walk safe. Catalogue
1,022 -> 1,095; EXTRACTOR_VERSION 2 -> 3; protocol stays 8.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4
