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

docs(runicnpc): stage 8 built and walked; MODULE_API 1.12.0 progress(), map.live's RunicNPC rows

Browse Source 
- 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
This commit is contained in:
claude
2026-10-06 08:23:21 -05:00
parent 6a87ce4d23
commit 941e4ae6e5
4 changed files with 112 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

53
runicnpc/PLAN.md
View File

@@ -1489,14 +1489,14 @@ in the Android app.
**The design (D305).**
- **Core: `MODULE_API` 1.12.0, one optional function on an event action, `live`.**
- While a run is live, core calls `live` for each step whose action declares one, with the step's ledgered refs and
the viewer (signed in or not, staff or not). The answer is `null`, `{ label, left, of }` or `{ label, percent }`.
- Core puts the answers in the public run as `live`, in step order, and renders them as text it does not
- **Core: `MODULE_API` 1.12.0, one optional function on an event action, `progress`.**
- While a run is live, core calls `progress` for each step whose action declares one, with the step's ledgered refs and
the reader as `{ userId }` (the module re-reads the account, as its own pages do). The answer is `null`, `{ label, left, of }` or `{ label, percent }`.
- Core puts the answers in the public run as `progress`, in step order, and renders them as text it does not
interpret: "Bandits: 3 of 8 left", "The Juggernaut: 62%". The app does the same from the same field.
- A call has a deadline and never throws into the page: a module that is slow or down gives no line, not an error.
The answers are cached per run for a few seconds, so a busy page does not reach the game once per reader.
- **This is an addition, so it is a minor bump.** Module-uo declares `^1.10.0` and registers no action with `live`,
- **This is an addition, so it is a minor bump.** Module-uo declares `^1.10.0` and registers no action with `progress`,
so its pages and actions are unchanged. The integration kit's pin (an equality check) goes red on the bump by
design, until the kit is read again and the pin moved.
- **The bridge (protocol 13, still unreleased): `map.live`'s rows for RunicNPC.**
@@ -1508,15 +1508,54 @@ in the Android app.
there, and the site's map drops it (D303).
- **Module-Rust.**
- The map: a marker's tooltip is its name and its event's title; a boss is bigger (D303).
- `rust.npc.place`'s `live`: the step's NPCs still standing, of the count it placed, labelled with the profile's
- `rust.npc.place`'s `progress`: the step's NPCs still standing, of the count it placed, labelled with the profile's
name; a boss step answers its health instead (D304).
- Each follows the map's events layer visibility, so a page never tells a viewer what the map would hide.
- **The app.** The map's markers as the site's. The event screen renders the run's `live` lines.
- **The app.** The map's markers as the site's. The event screen renders the run's `progress` lines.
- **Docs.**
- `website/MODULE_API.md` 1.12.0 and `website/EVENTS.md` §I.
- `rust-link/PROTOCOL.md` §17.3.
- The integration kit, read again and its pin moved.
**Built (2026-10-06), five branches and this one.**
| Piece | Branch | What it does |
|---|---|---|
| Core | `website` `feat/events-action-progress` (website#210) | MODULE_API 1.12.0: an action's optional `progress()`, asked per step of a live run with a 2 s deadline and a 5 s cache per run and reader; the public live occurrence's `progress`; the event page renders it and re-reads it every 15 s while live. Named `progress` rather than `live`: the public occurrence already has a boolean `live` |
| The bridge | `Rust-Plugins` `feat/runicnpc-stage8` | `map.live`'s RunicNPC rows (§17.3): `name`, `key`, `boss` and `health`; a boss's adds with `add: true`; a boss outside any event in the world layer |
| The site | `Module-Rust` `feat/runicnpc-stage8` | `rust.npc.place`'s `progress` (D304), behind the map's events-layer visibility; the map's names, event titles (from core's public calendar), bigger bosses and adds (D303); a boss's health removed from what a viewer is sent |
| The app | `Android-app` `feat/runicnpc-stage8` | The same markers and card (the event's title from the run resolver's calendar read); the event screen's progress lines, re-read every 15 s while live |
| Docs | this branch | `website/MODULE_API.md` 1.12.0, `website/EVENTS.md` §I, `rust-link/PROTOCOL.md` §17.3 |
**Tested.**
- **Core:** 2077 server tests and 401 client tests pass. The route-manifest checks fail on this machine's `main` too, because modules are installed locally; with no modules, as in CI, they pass.
- **Module-Rust:** 503 server and 73 client tests, and every `check:*` script.
- **The app:** 743 unit tests, `lintDebug` and `assembleDebug`.
- **Builds:** checked against the latest first: Rust 2634.289.1 (buildid 25681086), Oxide 2.0.7801, Carbon 2.0.262.
**Walked, 2026-10-06.** In the browser, signed in as the walk admin, and on the emulator (`s22_ultra`). A probe plugin
stood in for a player.
| Row | Result |
|---|---|
| An event authored in the editor (3 bandits; the Walk Juggernaut) on Oxide: its public page said "Bandit: 3 of 3 left" and "Walk Juggernaut: 100%" | pass |
| A bandit killed and the boss hurt: the open page moved to "2 of 3 left" and "59%" without a reload | pass |
| The boss below 50% summoned two adds: the bandit line still counted only the step's own, and the map listed the adds with `add: true` | pass |
| The web map: "Bandit · Stage 8 walk — the harbour raid", the boss bigger and in its own colour as "Walk Juggernaut (boss) · …", each add as "(a boss's add)"; the core calendar read once | pass |
| A boss placed from the placements page outside any event: in the world layer as `kind: boss` with its name; the placement's ordinary bandits not on the map (D302) | pass |
| The map's events layer set to staff only: a signed-out reader's page had no lines and its map no events layer; the admin's still had both. Set back to everyone | pass |
| Carbon: 2 guards and the Carbon Juggernaut: "Carbon Guard: 2 of 2 left" → "1 of 2 left", "100%" → "69%" | pass |
| The app: the event screen's two lines, moving to "1 of 3 left" while open; the map's bigger bosses; a world boss's card "Walk Juggernaut (boss)"; an add's card naming its event with Open event | pass |
**Found while walking, not in this stage:** the public event page never shows a live run's phase label. Core's
`phaseLabel` looks phases up by `id`, but a spec's phases carry `key` (`events/spec.js`), so the page says "Under way"
for every event the editor authors. It has done so since Events Phase 14a; its test used an `id` fixture. A one-line
fix in `eventPublic.model.js`, raised with the org lead rather than folded into website#210.
**Still to do when website#210 merges:** the integration kit's `ci/core-ref.json` pin moves to that sha, and its
`coreApi` with it, after the kit is read again for 1.12.0.
### Stage 9 — Hardening and release
- **Performance to the budget stage 1 measured:** 100 NPCs on a 6000 map without the frame time crossing it.