Commit Graph

111 Commits

Author SHA1 Message Date
f38dec2ac4 Merge pull request 'ci(image): clean up after the image build and the deploy' (#50) from chore/ci-self-cleanup into main
All checks were successful
Build and publish the image / build (push) Successful in 1m37s
Build and publish the image / deploy (push) Successful in 10s
PR checks / checks (push) Successful in 2m42s
Reviewed-on: #50
2026-11-04 12:10:59 +00:00
080f9827b8 ci(image): clean up after the image build and the deploy
All checks were successful
PR checks / checks (pull_request) Successful in 3m41s
The build job runs docker on the runner host's daemon, so every run left
two tagged images behind for good. Remove this run's tags once they are
pushed and cap BuildKit's cache at 5 GB, always, never failing the job.

The deploy drops the dangling image its pull replaced on the rgcom host.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-11-02 11:20:50 -06:00
7ac19a791c Merge pull request 'fix(app): turn the APK download back on for v0.7.0' (#49) from fix/apk-serviceable into main
Some checks failed
Build and publish the image / build (push) Successful in 3m55s
Build and publish the image / deploy (push) Successful in 13s
PR checks / checks (push) Failing after 14m24s
Reviewed-on: #49
2026-10-31 05:38:36 +00:00
b8306dcdaf fix(app): turn the APK download back on for v0.7.0
All checks were successful
PR checks / checks (pull_request) Successful in 2m30s
platform.json's androidApk.serviceable goes to true. It was false because
v0.5.0's build did not work. v0.7.0's released APK (SHA256 matches
SHA256SUMS) was installed on an Android 16 emulator, connected to the
public demo and read its Rust servers, so /app/ links the download again.

The comment beside the flag now says when it was last checked and to set
it back to false when `asset` moves to a release nobody has run. PLAN.md
D29 gets a dated note.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-31 00:21:46 -05:00
08a4973bde Merge pull request 'feat(app): quote Android v0.7.0, with report, block and hide and account deletion' (#48) from fix/android-v0.7.0 into main
All checks were successful
PR checks / checks (push) Successful in 2m39s
Build and publish the image / build (push) Successful in 4m12s
Build and publish the image / deploy (push) Successful in 37s
Reviewed-on: #48
2026-10-30 23:09:29 +00:00
8b8896f54b feat(app): quote Android v0.7.0, with report, block and hide and account deletion
Some checks failed
PR checks / checks (pull_request) Failing after 3m28s
Android-app v0.7.0 released 2026-10-30 (M8's cutover). platform.json
quotes it and its APK; /app/ gains the two things it added for a member
(report/block/hide on chat lines, and deleting the account), and the
Moderation docs name the app's long press beside the site's menu.

androidApk.serviceable is left false: it records a person having run
the build, and nobody has run v0.7.0's release APK on a phone yet.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-30 18:08:14 -05:00
e5ec81b172 Merge pull request 'fix(facts): quote 2026-10-30's releases, and the moderation that 1.21.0 brought' (#47) from fix/platform-facts-2026-10-30 into main
All checks were successful
PR checks / checks (push) Successful in 4m4s
Build and publish the image / build (push) Successful in 5m1s
Build and publish the image / deploy (push) Successful in 1m7s
Reviewed-on: #47
2026-10-30 22:31:46 +00:00
e0b2885cd7 fix(facts): quote 2026-10-30's releases, and the moderation that 1.21.0 brought
All checks were successful
PR checks / checks (pull_request) Successful in 5m26s
check:facts went red on seven facts after the day's releases: Module API
1.21.0, Module-Rust v0.7.0 (coreApi ^1.21.0), Module-uo v1.4.1,
Rust-Plugins v0.3.1, and the Rust bundle 2026.10.30 (plugin v0.3.1).
platform.json now quotes them, verified 2026-10-30.

Re-reading the pages that quote them: Module API 1.21.0 is report, block
and hide, so the Moderation page's Reports section described a queue
that no longer exists (forum-only, and "handling a report never touches
the content"). It now covers chat-line reports, the report snapshot,
Hide for everyone from the queue, and what members do for themselves
(Hide for me, Block, Account -> Blocked). The Rust docs' Feed row names
the chat-line menu. The app's menu is not mentioned: the app release
that carries it (v0.7.0) has not shipped.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-30 17:30:39 -05:00
c1b38081f5 Merge pull request 'fix(legal): declare report, block and hide in the app's data safety' (#46) from fix/play-data-safety-user-safety into main
Some checks failed
Build and publish the image / build (push) Successful in 1m41s
Build and publish the image / deploy (push) Successful in 10s
PR checks / checks (push) Failing after 3m5s
Reviewed-on: #46
2026-10-30 16:05:05 +00:00
dff4232491 fix(legal): declare report, block and hide in the app's data safety
Some checks failed
PR checks / checks (pull_request) Failing after 3m21s
The app now sends reports, blocks and hides (USER_SAFETY.md step 4,
Android-app#64). A new app row, app-safety, declares them: App activity ->
Other user-generated content (the report's note) and Other actions (the
report, block and hide themselves), collected, not shared, required. Other
actions moves from "not collected" to collected in PLAY_DATA_SAFETY.md.

The deployment row for posted content now says a report keeps a copy of
what it reported, and that blocks and hides are kept on the account and
deleted with it (user_blocks and user_hidden_items cascade).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-30 11:02:56 -05:00
caab3476eb Merge pull request 'feat(legal): /delete-account/, the page Google Play is given (D85, D86)' (#45) from feat/delete-account-page into main
All checks were successful
PR checks / checks (push) Successful in 2m22s
Build and publish the image / build (push) Successful in 2m49s
Build and publish the image / deploy (push) Successful in 10s
Reviewed-on: #45
2026-10-30 06:42:54 +00:00
70b31302b7 fix(facts): quote Module API 1.20.0 and Module-uo v1.4.0
All checks were successful
PR checks / checks (pull_request) Successful in 2m34s
check:facts was red on main after account deletion's core and module
steps merged: core's MODULE_API is 1.20.0, Module-uo declares coreApi
^1.20.0, and Module-uo released v1.4.0. Every page reads these from
platform.json, and none needed rewording. Folded into this PR by the org
lead's choice.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-30 01:40:52 -05:00
094c606238 feat(legal): /delete-account/, the page Google Play is given (D85, D86)
Some checks failed
PR checks / checks (pull_request) Failing after -31s
Step 5 of docs/website/ACCOUNT_DELETION.md (§4.5). The page explains how
to delete an account on a community's site and in the app, what goes,
what stays and for how long, and who to ask when you cannot sign in. It
cannot delete anything, because we hold no account.

- The facts are one deployment row in collection.mjs (deletion.goes,
  .stays with a keep each, .staff), in the website's own words. /privacy
  section 3 renders it as prose, the page renders its lists, and
  PLAY_DATA_SAFETY.md prints them under the console's deletion questions.
- The app rows that a deletion touches (session, trust token, push,
  inbox snapshot) say so. The Data Safety notes now answer "yes" to
  account deletion and name the URL. lastUpdated is 2026-10-30.
- D85: linked from the footer's legal bar, /privacy sections 2 and 3,
  and /app/'s "Two ways to get it".
- D86: someone who cannot sign in is sent to their community's operator,
  never to us.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-30 01:25:48 -05:00
338cc6f3de Merge pull request 'fix(legal): declare what the app sends as collected, not shared (D84)' (#44) from fix/play-data-safety-collected into main
Some checks failed
PR checks / checks (push) Failing after -1m24s
Build and publish the image / build (push) Successful in 3m5s
Build and publish the image / deploy (push) Successful in 30s
Reviewed-on: #44
2026-10-29 22:30:29 +00:00
d6d5a70ed4 fix(legal): declare what the app sends as collected, not shared (D84)
All checks were successful
PR checks / checks (pull_request) Successful in 2m33s
Play counts data that leaves the device as collected, whoever runs the
server it lands on. The generated Data Safety notes answered "not
collected" because we run no server, which is true of /privacy and the
wrong answer to the form (org lead, 2026-10-29, Android PLAN.md M8).

An audit of the app's edge (every body, query and header in data/api/)
found more leaving the phone than section 2 listed. New rows: the
User-Agent, game-account links and creation, the Contact form, staff
posts and moderation, notification read state and preferences, search
text. The sign-in and trusted-device rows now say what is sent (the
credentials, the device's make and model).

- PlayMapping: a list of console types, plus required and purposes,
  checked against PLAY_DATA_TYPES / PLAY_PURPOSES (the first version
  filed "Other user-generated content" under Messages).
- The generator answers per data type, lists every type not collected,
  and answers the form's security questions.
- The premise test now asserts what is still true: nothing is shared.
- legal.lastUpdated moves to 2026-10-29 with /privacy.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-29 08:20:25 -05:00
04e8c14d1f Merge pull request 'fix(facts): quote Module-Rust v0.6.3' (#43) from fix/facts-module-rust-063 into main
Some checks failed
PR checks / checks (push) Successful in 2m44s
Build and publish the image / build (push) Failing after 1h35m32s
Build and publish the image / deploy (push) Has been skipped
Reviewed-on: #43
2026-10-29 11:59:52 +00:00
bda4662a89 fix(facts): quote Module-Rust v0.6.3
All checks were successful
PR checks / checks (pull_request) Successful in 9m11s
check:facts was red on main: platform.json said Module-Rust v0.6.0 and
releases/latest says v0.6.3. v0.6.1 and v0.6.3 are demo-only fixes (DM26,
DM27; there is no v0.6.2) and still require MODULE_API ^1.19.0, so no
page's prose changes. Every page that shows the version interpolates it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-29 05:48:51 -05:00
fcc1a06361 Merge pull request 'feat(demo): list the demo's sign-ins on /beta and link into it per game' (#42) from feat/demo-live into main
Some checks failed
Build and publish the image / build (push) Failing after 3m41s
Build and publish the image / deploy (push) Has been skipped
PR checks / checks (push) Failing after 4m37s
Reviewed-on: #42
2026-10-29 10:12:41 +00:00
769d213c80 feat(demo): list the demo's sign-ins on /beta and link into it per game
Some checks failed
PR checks / checks (pull_request) Failing after 2m16s
The public demo (demo.runicgateway.com) is live, so the site's demo slot
can be switched on. Two decisions of record, PLAN.md §15:

- D82: /beta reads the demo's GET /api/v1/public/settings demo.logins on
  the server, caches it for a minute, and lists the published sign-ins
  with the next wipe. If the demo does not answer, /beta links to its
  sign-in page instead. Gate two reads as in place.
- D83: a deep link into a game module's pages carries data-demo-game, and
  applyBrand.mjs fills it only for games in the new mounted demoGames
  list. The Rust features gain links into /rust and /rust/servers/demo.
  UO's stay hidden on a Rust demo.

The public-demo not-built entry is removed, because its resolvedBy was met.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-28 15:32:34 -05:00
8701126d64 Merge pull request 'fix(docker): pin Node 22.23.4 for the image and CI (Node2Shell)' (#41) from fix/node22-node2shell into main
All checks were successful
PR checks / checks (push) Successful in 3m41s
Build and publish the image / build (push) Successful in 3m53s
Build and publish the image / deploy (push) Successful in 24s
Reviewed-on: #41
2026-10-27 17:49:06 +00:00
e7bbc250a5 chore(facts): Module API 1.19.0, Module-Rust v0.6.0
All checks were successful
PR checks / checks (pull_request) Successful in 5m58s
checkFacts turned this PR red on drift from the demo-mode merges, not on
the Node change: website main is at MODULE_API 1.19.0, Module-Rust main
declares coreApi ^1.19.0, and Module-Rust released v0.6.0. Every page
reads the three values from platform.json; verifiedOn moves to today.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-27 12:37:48 -05:00
d59c993430 fix(docker): pin Node 22.23.4 for the image and CI (Node2Shell)
Some checks failed
PR checks / checks (pull_request) Failing after 2m24s
CVE-2026-111497 ("Node2Shell") is an out-of-bounds write in Node's
bundled Brotli decoder, fixed on 2026-10-21 in 22.23.4. The image used
the floating node:22-bookworm-slim tag, so a cached or stale base could
still carry an older 22.x. Pin the patched version in both stages and in
the PR checks.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-26 10:01:49 -05:00
9b11c5cb99 Merge pull request 'chore(site): weapon names in the Rust shots; Android-app v0.6.0 and Module-Rust v0.5.1' (#40) from chore/rust-weapon-shots-and-versions into main
All checks were successful
PR checks / checks (push) Successful in 2m15s
Build and publish the image / build (push) Successful in 1m54s
Build and publish the image / deploy (push) Successful in 50s
Reviewed-on: #40
2026-10-23 07:35:45 +00:00
06a8892895 chore(facts): Android-app v0.6.0 and Module-Rust v0.5.1
All checks were successful
PR checks / checks (pull_request) Successful in 2m28s
Both were released on 2026-10-23. Android-app v0.6.0 is the cutover that
ships the Rust screens and the app's core wording (M20), and its APK asset
is runic-gateway-0.6.0.apk. Module-Rust v0.5.1 brings the weapon names in
the feed. verifiedOn moves to 2026-10-23, and checkFacts agrees on all 41
facts.

androidApk.serviceable stays false. It records a person's confirmation
that the published APK works, and nobody has run v0.6.0 against a real
site yet. A smoke test of the signed APK on the emulator covered install,
launch, the HTTPS rule and one TLS round trip, but no Runic Gateway site
serves HTTPS locally.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-23 02:32:59 -05:00
a918e9248e feat(screens): retake the Rust feed shots with weapon names
rust-feed (web) and app-rust-server (phone) showed the prefab names the
module printed before Module-Rust#60 ("with ak47u entity"). Both were
retaken from the Rust demo running that fix, after re-running
mockRustDemo.mjs so the feed's times are fresh. They now read "with
Assault Rifle", "with Thompson", "with MP5A4".

The phone shot was taken with the emulator in Pacific/Honolulu so that no
row crosses midnight and picks up a date; the timezone was restored
afterwards. The real Oxide rig has nobody on, so the server reads 0 of
40 online, and app-rust-server's alt now says "how many players are
online" rather than "six".

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-23 02:06:19 -05:00
abf7dceb06 Merge pull request 'feat(site): phase 18 — the Rust screenshots, web and app' (#39) from feat/phase-18-screenshots into main
All checks were successful
PR checks / checks (push) Successful in 2m33s
Build and publish the image / build (push) Successful in 3m26s
Build and publish the image / deploy (push) Successful in 50s
Reviewed-on: #39
2026-10-23 03:09:15 +00:00
c47e9c1aa4 feat(site): phase 18 - the Rust screenshots, web and app
All checks were successful
PR checks / checks (pull_request) Successful in 2m55s
Nine captures tagged rust (D65): the server list, feed, leaderboard,
live map, permissions and the RunicNPC profile editor on the web, and a
server's feed, its map and the player's Rust account in the app, from
an Android-app edge debug build.

D80: every name in a capture is a role (admin, moderator, player...),
from this phase on. D81: the Rust demo's players are mock data written
by scripts/mockRustDemo.mjs; the server, its status, map, permission
groups and RunicNPC sync state are the real Oxide test server's. The
captions and /modules/rust/ and /app/ say which part is a demo cast.

seedDemo.mjs gains --game rust (server row with a weekly wipe, public
presence for the demo, two NPC profiles, a VIP group). captureScreens.mjs
gains a click list per screen. The homepage shows the Rust live map beside
the UO capture (D76); three Rust docs pages carry their screen.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-22 22:05:06 -05:00
4f38e29ad7 Merge pull request 'feat(site): phase 17 — per-game module pages, /runicnpc/, and checkTerms over the built site' (#38) from feat/phase-17-marketing into main
All checks were successful
PR checks / checks (push) Successful in 2m26s
Build and publish the image / build (push) Successful in 3m0s
Build and publish the image / deploy (push) Successful in 53s
Reviewed-on: #38
2026-10-23 01:26:01 +00:00
56473d4d51 feat(site): phase 17 - per-game module pages, /runicnpc/, and checkTerms over the built site
All checks were successful
PR checks / checks (pull_request) Successful in 2m37s
PLAN.md §16 phase 17, built on the org lead's answers of 2026-10-22,
recorded as D75-D79 (count of record 79).

- D75: core marketing pages describe what a game module adds in core's
  words. "Game intelligence" became "What a game module adds"; each
  game's own list moved to src/data/games/ and renders only on the new
  /modules/uo/ and /modules/rust/. /modules/ is a card per game.
- The page-side capability check is per game (assertGameCoverage), the
  item phase 13 moved here.
- D76: the homepage keeps its game screenshot, labelled. screens.mjs
  entries may carry `game` (D67); Screenshot.astro and the app grid
  print the game's name and mark the figure data-game.
- D77: /app/ describes the Rust screens (released the same day).
- D78: /runicnpc/, the standalone page, is in the header and footer;
  the narrow header was re-measured so five links keep two rows.
- D79: checkTerms.mjs --built reads every built page's visible text
  after the build; game routes and data-game elements allow their
  game's words. Proven against ten plants. Still the twelfth check.
- Re-read fixes: /architecture/'s "two machines is also the maximum",
  Discord "guild" on /integrations/, and collection.mjs against what
  Steam sign-in and the Rust module keep (PLAY_DATA_SAFETY.md
  regenerated; the Play answers are unchanged).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-22 20:10:51 -05:00
ec65b2d5aa Merge pull request 'feat(docs): phase 16 — the RunicNPC subgroup, its API carried in full and drift-checked' (#37) from feat/phase-16-runicnpc into main
All checks were successful
Build and publish the image / build (push) Successful in 2m32s
PR checks / checks (push) Successful in 2m52s
Build and publish the image / deploy (push) Successful in 34s
Reviewed-on: #37
2026-10-22 21:07:54 +00:00
297cc83db5 docs(plan): record the Oxide floor ruling and the API.md table fix
All checks were successful
PR checks / checks (pull_request) Successful in 8m36s
The bundle's Oxide 2.0.7585 is the original compatible version and stays
until the CI staging drill reports an issue (org lead, 2026-10-22). The
API.md table break is fixed in docs #371.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-22 16:02:40 -05:00
ecc556d7ac feat(docs): phase 16 - the RunicNPC subgroup, its API carried in full and drift-checked
All checks were successful
PR checks / checks (pull_request) Successful in 2m11s
PLAN.md §16 phase 16, with the org lead's D72-D74 (count of record 74).

- Eight pages nested in the Rust group at /docs/rust/runicnpc/ (D72): the
  overview, Install RunicNPC, Commands, NPC profiles, NPC placements, Cost and
  caps, Profile fields (the one field reference the editor, rnpc.profile set,
  the data file and the API all share) and The API.
- The API page carries every call, hook and data shape (D62), in the site's
  own words, with no decision numbers and no per-call version history (D74).
  Signatures print from src/data/runicnpc.mjs through Signature.astro.
- checkReference.mjs gains two sections. Against docs main:runicnpc/API.md:
  the API version, 24 call and 10 hook signatures, and the field names of the
  profile, RunicNpc_List rows, placements, routes and owners (D73), plus
  exactly one <Signature> per call on api.mdx. Against runicnpc-rust
  main:plugin/RunicNPC.cs: console verbs, permissions, place options and
  config keys. Six planted drifts all failed before it was trusted.
- checkSidebar and checkTerms read nested sidebar groups via flatLabels().
- The Rust overview, Events zones and rewards, and Canonical documents link
  the new pages; the canonical documents gain the four runicnpc/ docs.

Both NPC admin screens were walked on the walk site first (D36); nothing was
saved. npm run verify is green.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-22 15:49:07 -05:00
fe86fc369d Merge pull request 'docs(plan): phase 15's other-repository findings are fixed' (#36) from docs/phase-15-followup into main
All checks were successful
PR checks / checks (push) Successful in 2m42s
Build and publish the image / build (push) Successful in 3m23s
Build and publish the image / deploy (push) Successful in 31s
Reviewed-on: #36
2026-10-22 20:32:25 +00:00
9b28c95305 docs(plan): phase 15's other-repository findings are fixed
All checks were successful
PR checks / checks (pull_request) Successful in 2m42s
PLAN.md §16 recorded three phase-15 findings as reported rather than
fixed. The org lead asked for them fixed the same day: Module-Rust #59
(24 decision numbers in admin copy, and "1 player holds one") and
Rust-Plugins #45 (EventsEnabled's comment). The record now says so.

Reading every EventsEnabled check for that comment also showed the
switch applies at once when saved from the site's config editor, while
the bridge's other settings wait for its next reload. RunicGateway.json
now says that, and adds paying coins to what the switch stops.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-22 15:31:45 -05:00
aad3a37c09 Merge pull request 'feat(docs): phase 15 — the Rust group, its reference pages checked against their sources' (#35) from feat/phase-15-rust into main
All checks were successful
PR checks / checks (push) Successful in 2m17s
Build and publish the image / build (push) Successful in 3m41s
Build and publish the image / deploy (push) Successful in 33s
Reviewed-on: #35
2026-10-22 20:26:31 +00:00
75c8ffc07a feat(docs): phase 15 - the Rust group, its reference pages checked against their sources
All checks were successful
PR checks / checks (pull_request) Successful in 2m5s
PLAN.md §16 phase 15. A Rust group of fifteen pages after Ultima Online
(D70): the module, installing the bridge (installer, Pterodactyl egg, by
hand), connecting the site, verifying the bridge, linking Steam accounts,
permissions and groups, mod config, who sees who is online, events, zones
and rewards, optional plugins, the live map, troubleshooting, and three
reference pages - rust-link's sidecar.toml, the plugin's
RunicGateway.json, and the event kinds.

checkReference.mjs gains three Rust sections rather than a new check:
sidecar.toml keys and RUSTLINK_* overrides from Rust-Link config.rs,
RunicGateway.json from the plugin's PluginConfig, and the event kinds
in three classes against Module-Rust server/catalogue.js (D71). Every
admin screen was walked on the walk site before it was described (D36).

Core pages now hand off to the Rust group instead of linking out to the
docs repository. Three defects the re-read found here are fixed: the UO
/health sample's hard-coded protocol 4 (both games' samples now render
platform.json through <Code>), Authentication's missing Steam tab, and
two pages saying the site cannot reach EventsEnabled - false on Rust.

Installer v0.8.1 moved checkFacts red mid-phase; platform.json follows.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-22 15:23:07 -05:00
a100195e7b Merge pull request 'feat(docs): phase 14 — game-neutral core docs, an Ultima Online group, and checkTerms' (#34) from feat/phase-14-vocabulary into main
Some checks failed
Build and publish the image / build (push) Failing after -1m50s
Build and publish the image / deploy (push) Has been skipped
PR checks / checks (push) Successful in 8m56s
Reviewed-on: #34
2026-10-22 19:41:17 +00:00
4426d3e339 feat(docs): phase 14 - game-neutral core docs, an Ultima Online group, and checkTerms
All checks were successful
PR checks / checks (pull_request) Successful in 2m10s
PLAN.md §16, D63/D64, plus D67-D69 taken 2026-10-22.

- Core docs use core's words: a Team, a game server, the sidecar, the bridge
  plugin, the game module. Detail that belonged to Ultima Online moved into
  its pages rather than being dropped.
- New "Ultima Online" sidebar group (nine pages): an overview, Connect a
  ServUO shard, Verify the bridge, The shard connection, Client files,
  Troubleshooting, Bridge.cfg, sidecar.toml, Shard event catalog. Five moved
  URLs answer a real 301 (src/config/redirects.mjs, asserted by the served
  test).
- Getting started is game-neutral. "Connect your game server" keeps the old
  URL and hands off to each game; Rust links docs main:rust-link/INSTALL.md
  until phase 15. "Verify the whole stack" stays, neutral (D69).
- D68: GameExample.astro labels a game's real example on a core page with the
  game's name; checkTerms allows that game's words inside it.
- scripts/checkTerms.mjs, the twelfth check: 16 game words, docs pages and
  both sidebar trees, one allowlisted phrase (Discord's "Guild (server) ID").
  Wired into verify and pr-checks.yml.
- canonicalDocs grouped by game; the Rust group carries four documents.
- D67: the screenshot rule from #32 is adopted.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-22 08:54:37 -05:00
6046214d71 Merge pull request 'feat(facts): phase 13 — per-game facts, Rust and RunicNPC checked, main green again' (#33) from feat/phase-13-facts into main
All checks were successful
Build and publish the image / build (push) Successful in 2m27s
PR checks / checks (push) Successful in 2m50s
Build and publish the image / deploy (push) Successful in 37s
Reviewed-on: #33
2026-10-22 13:11:14 +00:00
9938e71e07 feat(facts): phase 13 - per-game facts, Rust and RunicNPC checked, main green again
All checks were successful
PR checks / checks (pull_request) Successful in 8m25s
platform.json drops the single protocol/bundle/capability list for a
`games` object (uo, rust) plus a `runicnpc` block. checkFacts.mjs loops
the protocol, plugin-protocol, capability and bundle checks over both
games, reads the schema-2 bundles at v2/<game>/current.json, checks each
module's coreApi, and reads RunicNPC's plugin.toml. 41 facts, up from 19;
clears the two that were red on main (Module API 1.17.0, installer
v0.8.0).

D66: the hero, footer and structured data show the Module API only; each
game's protocol and bundle go on that game's pages, and the docs landing
table splits into shared versions plus one column per game.

The re-read section 1 requires found, and this fixes:
- three hard-coded "1.6.0" Module API versions in the module docs
- module-lifecycle saying modules load alphabetically (the loader now
  refuses a second module, W19), and the install pages never mentioning
  the one-module rule
- "there is one module" in five places, now two modules both built
  inside this project; the Integration Kit keeps its draft banner
- the homepage diagram's ServUO/uo-link sub-labels (D63 wording now)

notBuilt drops `second-module` (resolved by Module-Rust's release) and
rewords `multi-module`.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-22 08:09:22 -05:00
2971b84d51 Merge pull request 'docs(plan): revision 4 — a second game, RunicNPC, and a vocabulary rule' (#32) from docs/second-game-plan into main
Some checks failed
PR checks / checks (push) Failing after 2m4s
Build and publish the image / build (push) Successful in 4m11s
Build and publish the image / deploy (push) Successful in 1m23s
Reviewed-on: #32
2026-10-22 12:59:55 +00:00
b1584043a3 docs(plan): revision 4 - a second game, RunicNPC, and a vocabulary rule
Some checks failed
PR checks / checks (pull_request) Failing after 1m52s
Adds PLAN.md section 16 with the org lead's six decisions of 2026-10-22
(D60-D65) and phases 13-18:

- D60 per-game sidebar groups (Ultima Online, Rust); core docs go
  game-neutral, moved pages keep redirects
- D61 RunicNPC as a subgroup inside Rust, plus a standalone /runicnpc/
- D62 the RunicNPC API carried in full, with a drift check against
  docs/runicnpc/API.md (a deliberate exception to section 1)
- D63 game names allowed outside game sections, game vocabulary not
- D64 checkTerms.mjs, a twelfth check, amending D53
- D65 Rust screenshots last, captured from the rigs

Also records what moved since the site's last fact check: Module API
1.17.0 and installer v0.8.0 (main is already red on both), Module-Rust
v0.5.0, the v2/rust bundle at protocol 14, and RunicNPC v1.0.0.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-22 07:17:09 -05:00
c3c347d237 Merge pull request 'docs(site): the Asset Bridge — protocol 8, a screen for client files, and pictures in the screenshots (Phase 9c)' (#31) from docs/asset-bridge-p9c into main
All checks were successful
PR checks / checks (push) Successful in 9m28s
Build and publish the image / build (push) Successful in 2m59s
Build and publish the image / deploy (push) Successful in 1m20s
Reviewed-on: #31
2026-09-15 12:11:16 +00:00
4e1ce2316a docs(site): the Asset Bridge — protocol 8, a screen for client files, and pictures in the screenshots (Phase 9c)
All checks were successful
PR checks / checks (pull_request) Successful in 1m41s
The last leg of the Asset Bridge (docs/link/v8.md §16, phase 9c). The cutover put
protocol 8 on `main` in every declaration site, which turned this repo red by
construction: `checkFacts.mjs` reads the protocol from `link`'s `main`.

Two checks were failing, and only one of them was expected.

**checkFacts (10)** — protocol 7 → 8 in all three reads (sidecar, overlay, bundle),
the bundle triple to 2026.09.15 / sidecar v2.3.0 / overlay v1.3.0, and the releases
to link v2.3.0, installer v0.2.0, Module-uo v1.3.0. `moduleApi` and the capability
list did not move: core's whole share of eight phases was a deletion.

**checkReference (9)** — nobody had planned for this one. `Bridge.cfg` grew nine keys
across phases 5, 6 and 7 and the reference page had gone on not mentioning them,
which is the failure mode that check exists for. They are listed as two new groups,
`Client assets` and `Spawn files`, because they are two separate consents.

## The prose the bridge changed

- **New page, Administration → Client files.** `Admin → Client files` is a screen an
  operator has to press a button on and the site had no page for it. It carries the
  rule nothing else states: **nothing here happens on a restart**, so a patched client
  keeps serving the old artwork until somebody says so.
- **Protocol versions** said the most recent bump touched five repositories and named
  `website`. Protocol 8 touched four and did not reach core — its absence is the
  interesting half, and the page now says why. The store-migration paragraph gains 8,
  which changed no line of the sidecar's store despite moving megabytes.
- **The bridge** said "two ways in". There are three: bulk reads go over the
  request/reply path in pages, one in flight at a time, and the reason they must not
  ride the event stream is structural rather than about speed.
- **Requirements** gains `libgdiplus` for Linux shard hosts, and the note that no game
  client has to be installed for any of this — a ServUO shard cannot boot without one.
- **Troubleshooting** gains the failure mode that did not exist before: a bestiary with
  no pictures, or items reading as numbers.
- **Maintenance** gains the button to press after patching a client, and **Verify the
  whole stack** the `doctor` check that landed with it.
- The spawn atlas and the marketplace both carry artwork now, so both capability
  descriptions say so, and `canonicalDocs` points at `link/v8.md`.

## Screenshots, retaken against the real thing

The atlas and marketplace shots predate the asset plane, so both were retaken on the
demo deployment against a real shard and a real sidecar, plus the new admin screen:
1,095 portraits imported in 2.1 s, 67,496 names in 1.4 s, 313 item pictures in 0.8 s.
Nothing here is a mock-up. The atlas shot moved 36px down its page because portraits
made the rows taller.

## One defect found on the way

`seedDemo.mjs` pinned the demo deployment at **protocol 4** with a comment explaining
a `module-uo` debt that has since been paid. Its default now comes from
`platform.json`, so the rig cannot drift two protocols behind the platform again.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4
2026-09-15 05:45:38 -05:00
73f664c38e Merge pull request 'docs(site): the Event System — the platform's facts, and two pages for it' (#30) from docs/events-system into main
All checks were successful
Build and publish the image / build (push) Successful in 4m14s
Build and publish the image / deploy (push) Successful in 42s
PR checks / checks (push) Successful in 8m22s
Reviewed-on: #30
2026-09-10 04:27:50 +00:00
e91e76bfa9 docs(site): the Event System — the platform's facts, and two pages for it
All checks were successful
PR checks / checks (pull_request) Successful in 9m34s
Phase 16c of the events plan: `runicgateway.com`'s half of the workstream, now
that `main` carries the engine, the module, the app and the bundle.

The checks were already red and named their own answers:

* `checkFacts` — nine values had moved. Protocol 5 → 7 in all three declaration
  sites, `moduleApi` 1.9.0 → 1.10.0, the bundle to 2026.09.10 with sidecar
  v2.2.0 and overlay v1.2.0, `link` v2.2.0, `Module-uo` v1.2.2.
* `checkReference` — twenty-seven `Bridge.cfg` keys the site listed nowhere: the
  events switch and its sweep, the ten caps, the oracle NPC, the two lease keys
  and the seven participation keys. They are five new groups rather than an
  appendix to an existing one, because `EventsEnabled` is a second consent
  switch and belongs beside its own ceilings.

Two pages, matching the treatment Teams has:

* **Scheduled events** (Administration) — where it is and who sees it, authoring
  and immutable versions, the switchboard that arrives off, caps as a condition
  on an `UPDATE` rather than a role check, the dry run, the run console, what an
  event owns versus what it borrows, generated cleanup, the shard's own switches,
  and what a player sees.
* **Events architecture** — the two sentences it turns on, what is a table and
  what deliberately is not, budgets in SQL, the ledger's two rules, at-most-once
  on a wire that can lose an answer, the three layers, and the four omissions.

And the rest of the surface:

* `/privacy` gains **`deploy-events`** — the participation ledger is personal
  data and no row named it. Scores and ranks against a module-opaque member key,
  linked to an account where one is linked; the diagnostic log swept after 90
  days on terminal runs only; the run, its steps and its participants not swept
  at all, because they are the record of what was done to a shared world.
  `deploy-game-data`'s citation moves from `link/v4.md` to `v7.md`.
* **Protocol versions** — the most recent bump touched *five* repositories, and
  the `website` row is the interesting one: core is normally out of a protocol
  bump's reach and this one reached it, because what changed was not a game noun
  but the shape of a thing core owns the ledger for. The store-migration
  paragraph now says four bumps' worth rather than two.
* Two capability entries, so `/`, `/features/` and `/modules/` stop omitting the
  subsystem — an Administration item, and an **Event calendar** under Community
  with `/site/events` as its deep link. Deliberately *not* `needsModule`: a bare
  core can author and run an event, and only the world verbs need a module.
* **`reference/event-catalog` is retitled "Shard event catalog"** and says what
  it is not. Two things in the docs were called an event catalog; the route is
  unchanged, so nothing outside this repository breaks.
* `canonicalDocs` gains `website/EVENTS.md` and moves `link/v4.md` → `v7.md`.

No screenshots. Capturing the events surfaces means standing the whole rig back
up — game server, sidecar, core, module, a published event with a live run — for
two or three images that no check requires, and the engagement workstream's own
site leg added none either.

`npm run verify` green end to end, including `checkReference` against the
protocol spec that only reached `docs` `main` in RunicGateway/docs#232 — the
seventh cutover step, which 16b had left on `edge`.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4
2026-09-09 22:04:27 -05:00
5f58a4cbf2 Merge pull request 'docs(site): /privacy tells the truth about engagement retention again' (#29) from docs/engagement-retention into main
All checks were successful
Build and publish the image / build (push) Successful in 1m22s
Build and publish the image / deploy (push) Successful in 11s
PR checks / checks (push) Successful in 1m32s
Reviewed-on: #29
2026-09-01 20:57:24 +00:00
82b55e3084 docs(site): /privacy tells the truth about engagement retention again
All checks were successful
PR checks / checks (pull_request) Successful in 1m23s
ENGAGEMENT.md Phase 14. The deploy-engagement entry in the collection
inventory said "Kept until the operator removes them; nothing here expires
on its own" and, in its detail, "the delivery log, the suppression list and
the per-person rate limits have no retention sweep, so they are as long as
the site is old". That was the true answer until Phase 14 landed a sweep,
and it is the kind of sentence a Play reviewer reads.

It now describes what the code does: a nightly sweep with an
operator-settable horizon per table (180 days for the delivery log, 30 for
the queue and the rate limits), and the two things that deliberately do NOT
expire — an item still waiting to be sent, because it is a message the site
still intends to deliver, and the suppression list, because ageing an entry
out would mean mailing an address that already bounced.

PLAY_DATA_SAFETY.md is unchanged and check:datasafety stays green:
deploy-engagement is deployment-scoped, and the Play answers are generated
from the app-scoped entries, because Play asks what the app collects rather
than what a self-hosted deployment keeps.

All ten checks green, 42 tests pass.

Co-Authored-By: Claude <noreply@anthropic.com>
2026-09-01 15:41:14 -05:00
a0af01026e Merge pull request 'docs(site): the engagement system — cutover 7 of 7 (edge → main)' (#28) from edge into main
All checks were successful
PR checks / checks (push) Successful in 1m38s
Build and publish the image / build (push) Successful in 3m30s
Build and publish the image / deploy (push) Successful in 27s
Reviewed-on: #28
2026-09-01 18:04:20 +00:00
5c6735bd1d Merge pull request 'chore(facts): protocol 5, Module API 1.9.0, and the 2026.09.01 bundle' (#27) from docs/platform-facts-protocol-5 into edge
All checks were successful
PR checks / checks (pull_request) Successful in 1m24s
Reviewed-on: #27
2026-09-01 17:45:16 +00:00