d59c9934304e177d60d0dddc396c326d6c03eb69
7 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| 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 |
|||
| 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 |
|||
| 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 |
|||
| 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 |
|||
| 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 |
|||
| 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 |
|||
| d89ce06bb8 |
docs(builder): phase 8 — modules, architecture and reference
All checks were successful
PR checks / checks (pull_request) Successful in 1m13s
Twenty pages completing the tree section 10 planned: Modules (8), Architecture
(5) and Reference (7). Four decisions, D38-D41, recorded in PLAN.md section 10.
D39 is the one that shaped the phase. Section 1 forbids re-specifying a
contract, and a Reference section is exactly where that rule is most tempting to
break, so the line is drawn at names: every environment variable, config key,
installer command, visibility rung and canonical document is listed with one
terse line saying what it is FOR, while shapes, semantics and every "why" stay
in the canonical document.
That is only safe because the names are checked. checkReference.mjs compares six
enumerations against the repositories that own them, over the Gitea API, as set
comparisons in BOTH directions -- and the second direction is the one that earns
its keep, because a reference page does not usually rot by describing something
that vanished, it rots by quietly not mentioning what was added since.
The check went green on its first run, which is the least trustworthy possible
outcome, so it was verified by breaking it: seven mutations, all caught. The one
worth keeping is the visibility ladder REORDERED with its membership unchanged
-- it is a security boundary, and a set comparison alone would have passed it.
D41 turns plannedSidebar from a checklist into a checked invariant, and finding
out why was the phase's first defect: it had already drifted, because phase 7
added the Content page under D37 and never updated the list. Nothing failed,
because nothing read it. checkSidebar.mjs now asserts the two trees agree on
groups, labels and order -- order because the order of Getting started IS the
installation path.
Two more things the writing found. PLAN.md's page count was wrong and had been
since section 10 was written ("roughly 38, 37 planned" for a tree of forty).
And module.json's `mounts` and the SPA's paths are different mechanisms that no
single document stated plainly -- module-uo declares admin: ["/shard",
"/uo-link"] while its screen lives at /admin/uo/link, because API routes are
deliberately NOT namespaced while SPA routes are. That is precisely the
distinction the installer got wrong in v0.1.0, and it now has a named home.
D40: the docs link to /architecture/'s drawn diagrams rather than importing
them. Those components carry marketing chrome and depend on diagram.css, which
Starlight does not load; the docs use text diagrams, which paste into an issue.
npm run verify green: 40 pages across 5 groups agree with plannedSidebar, 2390
internal links resolve, 123 repository links point at a branch, 19 facts, 59
quickstart checks, 22 reference enumerations, astro check 0 errors, 36 tests.
Co-Authored-By: Claude <noreply@anthropic.com>
|
