feat(docs): phase 16 - the RunicNPC subgroup, its API carried in full and drift-checked

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

PLAN.md

@@ -237,7 +237,7 @@ Taken by the org lead (Colby Whitlock) on 2026-08-19. Recorded so they are not r
 
 **Decisions after D13 are recorded where they were taken**, in the section describing the phase that
 raised them, rather than appended here — a decision is only re-litigated when its reasoning is
-somewhere other than the thing it decided. The count of record is **seventy-one**:
+somewhere other than the thing it decided. The count of record is **seventy-four**:
 
 | # | Where | What it settled |
 |---|---|---|
@@ -259,6 +259,7 @@ somewhere other than the thing it decided. The count of record is **seventy-one*
 | D67 | §16, "One rule the phases need" | A screenshot belongs to its game: a capture tagged with a game may carry its words, beside the game's name |
 | D68–D69 | §16, "How phase 14 built it" | A game's real example on a core page is a tagged, labelled block; *Verify the whole stack* stays in Getting started, game-neutral (amending D60) |
 | D70–D71 | §16, "How phase 15 built it" | The Rust group is fifteen pages, one per admin screen where it can be; the Rust event kinds are checked against the module's own classification |
+| D72–D74 | §16, "How phase 16 built it" | The RunicNPC subgroup is eight pages with a shared profile-field reference; the API check compares signatures and every data shape's field names; the site's API page carries the current API only, with no decision numbers and no version history |
 
 ---
 
@@ -2172,6 +2173,94 @@ same day, each in its own repository's PR into `edge`:
   helpers**; the bundle ships three. The org lead approved a separate `docs` PR for these:
   `docs` #370.
 
+### How phase 16 built it
+
+Three decisions, taken by the org lead on 2026-10-22 before any page was written. The count of
+record is now **seventy-four**.
+
+**D72 — the RunicNPC subgroup is eight pages, one of them a shared profile-field reference.** D61
+named five topics. The subgroup sits at the end of the Rust group, nested, at
+`/docs/rust/runicnpc/`: *RunicNPC* (the overview), *Install RunicNPC*, *Commands*, *NPC profiles*,
+*NPC placements*, *Cost and caps*, *Profile fields* and *The API*. The site's two NPC screens get a
+page each, as the Rust group's screens do, and the cost warning and caps get their own page rather
+than a section of *Install*. ***Profile fields* is the one page every way of writing a profile
+links to**: the site's editor (whose sections it follows, with each field's label), `rnpc.profile
+set` (which takes the same JSON paths), the data file, and the API. So the API page shows calls,
+hooks, placements and routes, and links there for a profile's shape rather than repeating it. The
+alternatives were D61's five pages, and seven without the shared reference.
+
+**D73 — the API check compares signatures and field names.** D62 named calls, hooks and
+signatures. The check also compares the field names of every data shape `API.md` gives: a
+profile's fields, `RunicNpc_List`'s keys, a placement's keys, a route's keys, and the owners. A
+field added to the profile upstream turns this site red the same way a new call does. The
+alternative, calls and hooks only, would have let the largest and most-changed shape drift
+unnoticed.
+
+**D74 — the site's API page carries the current API only.** `API.md` explains itself with decision
+numbers (*D258, D269*) and plan stages, and tags each call with the API version that added it. The
+site page drops both. Decision numbers mean nothing to a plugin author outside this project — the
+reason `Module-Rust` #59 removed them from the admin screens — and the version history is
+`API.md`'s to keep. The page states the current API version, read from `platform.json`, and shows
+how to check it before calling. The alternatives were keeping the "since API n" tags, and copying
+`API.md` faithfully, decision numbers included.
+
+**The drift check is two sections of `checkReference.mjs`**, so the count of checks stays at
+twelve, as the plan said:
+
+- **Against `docs` `main:runicnpc/API.md`**, through the `contents` endpoint: the API version
+  against `platform.json`; all 24 calls by whole signature, parsed from their headings; all 10
+  hooks by signature, from their table; and the field names of the five shapes (D73). A profile
+  field cell that names two fields (`hurtByPlayers`, `hurtsPlayers`), or a bare name after a dotted
+  one (`phases[].damageDealt`, `aimCone`), is read the way a person reads it. And the page itself:
+  every call must have exactly one `<Signature call="…" />` on `api.mdx`, so "carried in full" is
+  held by the build, not by whoever last edited the page.
+- **Against `runicnpc-rust` `main:plugin/RunicNPC.cs`**: the console verbs it registers, the
+  permissions it registers (and that every command's permission is one of them), the `key=`
+  options `ParseOptions` accepts, and the JSON keys of its config classes. These are names on the
+  *Commands* and *Cost and caps* pages, and §12 has checked every name the Reference pages write
+  since phase 8. D62 did not ask for this half; it is the phase-15 precedent (the bridge plugin's
+  `RunicGateway.json` is read from its source the same way) applied to the two new pages that list
+  names.
+
+Signatures print from `src/data/runicnpc.mjs` through `src/components/Signature.astro`, which
+renders them with Starlight's `<Code>`, so the signature a reader copies is the one the check
+compared. Descriptions live beside them as short strings, written in the site's words, and
+`src/components/Ticks.astro` renders their backticks, bold and links — never HTML. Before the check
+was trusted, six drifts were planted: a parameter added to a call, a hook renamed, a `RunicNpc_List`
+key renamed, a profile field renamed, a command verb renamed, and one call's `<Signature>` removed
+from the page. All six failed, each naming the side it broke.
+
+**The sidebar check learned nested groups.** `checkSidebar.mjs` and `checkTerms.mjs` read both
+trees through `flatLabels()` in `sidebar.mjs`, which writes a nested page as `RunicNPC › Commands`.
+The plan's order, and its vocabulary, are held for a subgroup exactly as for a group.
+
+**Every admin screen was walked first** (D36), signed in as the walk admin on the walk site against
+both rigs: *Rust NPC profiles* (the servers with their RunicNPC version, API and last push; the
+profile list; the faction table; the editor opened on a new profile, through every section) and
+*Rust NPC placements* (the server picker, the map with its layers, a waiting placement whose
+profile had gone, and the cost warning above the list). Nothing was saved. Two claims were then
+checked in `Module-Rust`'s server before they were written: the push tick is 30 s with a
+quarter-hourly audit (`npcSync.js`), and saving a profile asks every covered server that answers
+for its kits.
+
+**What else changed.** The Rust overview's staff table links the two NPC screens to their pages,
+and its "In this group" table gains the subgroup. *Events, zones and rewards* links its *Place
+NPCs* step to the profiles page. The canonical documents gain `runicnpc/API.md`, `COMMANDS.md`,
+`INSTALL.md` and `PLAN.md` under Rust, and that page now names the API page as the one deliberate
+exception to "every page links out".
+
+**Findings outside this repository**, reported rather than fixed:
+
+- **The Rust bundle's Oxide floor is lower than RunicNPC's.** `v2/rust/current.json` says Oxide
+  2.0.7585, which is the bridge plugin's floor. But the bundle requires RunicNPC, whose own
+  `plugin.toml` says 2.0.7726 — and its comment notes that RunicNPC "has never run on" 7585. So
+  the installer will accept a server that RunicNPC has never been tried on. The site states both
+  numbers where each belongs (the Rust overview quotes the bundle's, the RunicNPC pages
+  RunicNPC's) and claims nothing about the gap.
+- **`API.md`'s profile table breaks in two places.** The `boss` rows and the `loot` rows each
+  follow a blank line with no header row, so Gitea renders them as plain text full of pipes rather
+  than as tables. The check parses them line by line and is not affected; a reader of `API.md` is.
+
 ---
 
 [api]: https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/website/MODULE_API.md