docs(runicnpc): stage 6 spike questions answered, D283-D284

D283: RunicNPC keeps "// Requires: Kits"; a Kits reload reloads it and
its spawned NPCs are lost, so operators are told not to reload Kits
during an event. D284: the four example kits are written only on the
first install, behind a flag, and never restored or overwritten.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

runicnpc/PLAN.md

@@ -10,7 +10,8 @@ design answered 2026-09-30** (D243–D252, §0), **built and walked 2026-09-30**
 design answered 2026-09-30 and 2026-10-01** (D253–D266, §0), **its spike measured 2026-10-01** on both rigs (§9),
 and **its build's own questions answered 2026-10-01** (D267–D272). **Stage 5 built and tested 2026-10-01, walked on the
 site 2026-10-05** on both rigs (§9); its API is [API.md](API.md) version 4. **Stage 6's design answered
-2026-10-05** (D273–D282, §0).
+2026-10-05** (D273–D282, §0), **its spike measured 2026-10-05** on both rigs, and **its two questions answered the
+same day** (D283, D284, §9).
 
 RunicNPC is Runic Gateway's own NPC plugin for Rust servers, in its own repository,
 [`RunicGateway/runicnpc-rust`](https://gitea.whitlocktech.com/RunicGateway/runicnpc-rust). It runs on Oxide and
@@ -102,6 +103,8 @@ architectural or design decision is implemented.
 | **D280** | **RunicNPC ships four example profiles, each with a kit that works on a fresh server:** a raider (roamer), a camp guard (guard), a sniper (sentry) and a boss (the "Juggernaut", with phases). Kits has no API that creates a kit, so **RunicNPC writes its example kits into Kits' own data file** and reloads Kits. Warden is not one of them (stage 6). | A profile with no kit wearing its Rust prefab's own gear (relaxing D217); item lists for the examples only; no examples; templates on the site that leave the kits to the admin. |
 | **D281** | **NPCs say no greet, hurt or kill lines.** A profile talks only through press E on a passive NPC (D278) and a boss's announcements (D277) (stage 6). | Lines on any profile; on passive NPCs and bosses only. |
 | **D282** | **Stage 6 is one stage, opening with a spike on both rigs, walked once end to end**, as stages 4 and 5 were (D248, D253) (stage 6). | 6a (bosses) and 6b (passive NPCs), each walked and merged before the next. |
+| **D283** | **RunicNPC keeps `// Requires: Kits`.** A Kits reload reloads RunicNPC too, on both frameworks, and the NPCs it had spawned are lost (placements respawn; an event's do not). The operator documentation says not to reload Kits while an event runs (stage 6 spike, finding 6). | Kits still required, but checked in RunicNPC's own code, so its NPCs survive a Kits reload. |
+| **D284** | **RunicNPC writes its four example kits only on its first install**, recorded by a flag in its data. A kit the admin deletes or edits is never brought back or overwritten. The kits are `rnpc_raider`, `rnpc_campguard`, `rnpc_sniper` and `rnpc_juggernaut`, each needing a permission nobody is granted (stage 6). | On every load, for any example kit that is missing; only on an admin's command. |
 
 **Borrowing, not copying.** NpcSpawn states no licence at all, so its source grants us nothing and is read only as a
 description of *what* can be done in Rust. HumanNPC is MIT on uMod, which is GPL-compatible, but §1.2 rules out its
@@ -1213,30 +1216,27 @@ around it, each point snapped to the navmesh.
 - **One recovery trap on Carbon.** Unloading Kits and RunicNPC by hand with `c.unload`, then `c.load`, left both
   "requested for compilation" and never loaded. `c.reload` did the same. A restart of the server cleared it.
 
-**What the answers leave open, for the org lead:**
+**What the answers left open, and the org lead's answers (2026-10-05):**
 
-1. **Should a Kits reload stop taking RunicNPC down?** For example: an event has placed 8 raiders, and an admin
-   edits a Kits kit and reloads Kits. Today all 8 vanish at once on both frameworks, and the event cannot get them
-   back. The choices:
-   - **Drop `// Requires: Kits` (proposed).** RunicNPC stays loaded through a Kits reload, and its NPCs keep the
-     gear they already have. For the 1–15 s that Kits is away, a spawn is refused with a warning. When Kits comes
-     back, RunicNPC checks the profiles' kits again. D217 still holds: with Kits not installed at all, RunicNPC
-     refuses every profile and says why.
-   - **Keep it**, and document "never reload Kits while an event runs".
-2. **When are the example kits written (D280)?** For example: an admin installs RunicNPC, and its four kits are
-   written once and Kits reloads. Later the admin deletes `rnpc_raider`, or edits `rnpc_juggernaut`. What happens
-   at the next restart?
-   - **Only on the first install (proposed).** A flag in RunicNPC's data records that they were written, so a kit
-     the admin deleted stays deleted and an edit is never overwritten.
-   - **On every load, for any example kit that is missing.**
-   - **Only while the example profile that uses it still exists.**
+1. **Should a Kits reload stop taking RunicNPC down? → D283: no. The `// Requires: Kits` line stays.** A Kits
+   reload keeps reloading RunicNPC on both frameworks. For example, an event has placed 8 raiders and an admin
+   reloads Kits: all 8 vanish, the event cannot get them back, and placements respawn about 5 s later. The
+   operator documentation (stage 9) says not to reload Kits while an event runs.
+   - The other choice was RunicNPC checking for Kits in its own code, which would have kept its NPCs through a
+     reload.
+2. **When are the example kits written (D280)? → D284: only on the first install.** A flag in RunicNPC's data
+   records that they were written. A kit the admin later deletes stays deleted, and an edit is never overwritten.
+   - The other choices were every load (restoring any missing example kit), or only on an admin's command.
 
-   Proposed with it:
-   - the kits are named `rnpc_raider`, `rnpc_campguard`, `rnpc_sniper` and `rnpc_juggernaut`;
-   - they carry `RequiredPermission: runicnpc.examplekits`, which nobody is granted, so no player can claim one by
-     name (`IsHidden` alone does not stop that);
-   - on Oxide the one-time reload takes RunicNPC down and back once (finding 6) unless question 1 drops the
-     `Requires` line, so the kits are written before RunicNPC spawns anything.
+What this adds to the build (D283, D284):
+
+- **The kits are named `rnpc_raider`, `rnpc_campguard`, `rnpc_sniper` and `rnpc_juggernaut`.**
+- **Each carries `RequiredPermission: runicnpc.examplekits`**, which nobody is granted, so no player can claim one
+  by typing its name (`IsHidden` alone does not stop that). RunicNPC's `GiveKit` call ignores the permission.
+- **The first install runs in this order:** write the kits, set the flag, reload Kits.
+  - Because of D283, the reload takes RunicNPC down and back once.
+  - On that second load the flag is already set, so nothing is written twice and nothing loops.
+  - RunicNPC writes the kits before it spawns anything, so no NPC is lost to that reload.
 
 **What this sets for the build, with nothing to decide:**