diff --git a/runicnpc/PLAN.md b/runicnpc/PLAN.md
index 5c6ff32..3602291 100644
--- a/runicnpc/PLAN.md
+++ b/runicnpc/PLAN.md
@@ -1739,6 +1739,40 @@ D318 (the drill week, the org lead's change) and D319 (the map).
   changing its seed for half an hour, which spoiled one round of the map measurements; they were found in the
   panel's activity log and measured again cleanly.
 
+**9c, the first drill that failed (2026-11-01, runicnpc-rust#20).** The drill's run 47, on Rust staging build
+26341433 (manifest 6731949433558131698), failed in five checks, and the harness then stopped. Three causes are
+found below; two checks are not explained yet (the last item).
+
+- **Rust added three fields to the swap's list (D232):** `BasePlayer.timeSinceAiming`, `BaseEntity.ServerPreProcessed`
+  and `BaseNetworkable.ignoreNetworkLod`, 55 fields now 58. They are on `edge` and ship to `main` at the forced
+  wipe on Thu 2026-11-05, after Rust's public update, so a server on public Rust never names fields it does not
+  have. The release is checked first by a Carbon boot on the updated Rust reporting `added=-`. The brain's list
+  is unchanged.
+- **The harness stopped without saying so (fixed in 0.7.4).** `place.set.each` was refused (the harness threw the
+  refusal away, so why is not known; RunicNPC refuses a roamer's spot off the navmesh, D219, and this was the one
+  spot in the harness not put on it), `place.spawned` failed, and the next line read the first of zero NPCs and
+  threw, which ended the coroutine silently: no `# done all`, so the drill waited its full 45 minutes. The run
+  itself had taken 10 minutes. Now `Place` puts its spots on the navmesh as every other group does,
+  `place.set.each` and `place.set.group` carry the refusal text, and a `place.spawned` failure takes back what
+  was set and ends the group. Any group that throws is now a FAIL line naming it
+  (`<group>.exception`), and the run goes on to `# done all`.
+- **The drill's rig kept data a fresh server would not have.** `s6.examples.fullCondition` failed on kits that an
+  older build had written: RunicNPC writes its example kits once, into Kits' own file (D284), and the drill
+  removed only the harness's files before a run. It now also deletes Kits' `kits_data.json` and RunicNPC's
+  `profiles`, `placements`, `routes` and `state` files, so `rust-staging` boots like a new server and the first
+  load writes the examples again at this Rust's durabilities (D324) and settles the Kits reload (D329). Files
+  only, never a directory the panel would create (§1.5); the `rnhrevolver` kit is added after RunicNPC's first
+  load, as before.
+- **The drill stops waiting when the harness has.** If the harness's file gets no new line for 5 minutes, the
+  finding reads "The harness stopped after `<last line>` (no output for 5 minutes; N pass, M fail so far)." The 45
+  minutes stays as the cap for a harness that is still writing. Whenever the harness did not finish, the tail of
+  the rig's `latest.log` goes into the issue under "Console, last lines", where an exception in a coroutine shows.
+- **Not explained yet:** `s5.fight.shootBack` (a neutral `t_roam` shot by a one-sidedly hostile profile did not
+  answer in 70 s, D268) and `s5.kit.heal` (healer at health 75 with both syringes unused). Neither left a line in
+  Oxide's log, and `s5.fight.factions` and `s5.fight.marked` passed, so the hurt path works. They are re-run on the
+  fixed harness with fresh data before anything in the plugin changes for them. That example kits written once
+  keep an older Rust's item condition on a real server is runicnpc-rust#21.
+
 **9d. The player walk (D312).** Both rigs are updated first (Rust, Oxide, Carbon) and their builds stated. One
 checklist, published as a page, for one session per rig. I prepare the rigs, the walk site and a linked test
 account; the org lead plays, and I watch the logs and record each row. It gathers every in-game check deferred so