feat: admin accounts, god mode, OLC commands like dig/room, 'inline' objects changed to 'local' objects

1 files changed, 12 insertions, 12 deletions

diff --git a/building_guide/objects.md b/building_guide/objects.md
index 37b8e23..d8761ae 100644
--- a/building_guide/objects.md
+++ b/building_guide/objects.md
@@ -16,8 +16,8 @@ and is still required there.)
 - **Generic, shared objects** (rocks, trees, altars, stations) use a semantic name and live
   flat in `data/objects/` — e.g. `data/objects/copper_rock.yaml`.
 - **Room-specific one-offs** (signs, set-dressing, scenery for a single room): if they are
-  description-only (the passive subset), prefer defining them **inline in the room** (see
-  [Inline objects](#inline-objects-defined-in-the-room) below). If a one-off needs
+   description-only (the passive subset), prefer defining them **locally in the room** (see
+   [Local objects](#local-objects-defined-in-the-room) below). If a one-off needs
   interactable behavior (`gather`/`talk`/`use`/etc.) it must be a file — prefix it with the
   room number and place it in `data/objects/unique/`, e.g. `data/objects/unique/1002_sign.yaml`
   (ID `1002_sign`, referenced from room `1002`).
@@ -27,20 +27,20 @@ need no changes to room references when a file is moved. They do **not** namespa
 filename stem must be globally unique across all of `data/objects/`. Use `hidden: true` for
 signage/scenery so it doesn't appear in room listings.
 
-### Inline objects (defined in the room)
+### Local objects (defined in the room)
 
 Room-specific **description / scenery** objects can be defined directly inside the room's
 `objects:` list instead of as separate files in `data/objects/unique/`. An entry in the list
-is treated as **inline** when it carries a `name:` (or any other content field —
+is treated as **local** when it carries a `name:` (or any other content field —
 `description`, `aliases`, `inroom_description`, `color`, `hidden`, `on_look`). An entry with
 only `- id: <file>` is a plain **reference** to a file object, as before. `id:` is reserved
-for references; **inline objects do not take an `id:`** — their identity comes from the name.
+for references; **local objects do not take an `id:`** — their identity comes from the name.
 
 ```yaml
 # in data/rooms/intro/1001.yaml
 objects:
   - id: workbench            # reference: resolves to data/objects/workbench.yaml
-  - name: window             # inline: identity derived from the name, no file
+  - name: window             # local: identity derived from the name, no file
     hidden: true
     description: "A thick trim with rounded bolt heads frames the tiny window."
   - name: sign
@@ -55,26 +55,26 @@ objects:
 
 - **Identity comes from `name`.** Internally the object's id is the name, normalized
   (lowercased, surrounding/redundant spaces trimmed, spaces kept — `"Instrument Panel"` →
-  `instrument panel`). You never write an `id:`; doing so on an inline entry is ignored and
+  `instrument panel`). You never write an `id:`; doing so on a local entry is ignored and
   warned about at startup.
 - **Identity is room-scoped.** Two different rooms may each have an object named `sign`
   without conflict — no room-number prefixing needed (unlike the old `data/objects/unique/`
   files).
 - **Each object in a room must have a unique name.** Two *distinct* objects in the same room
-  with the same exact name — whether both inline, both file references, or one of each — is a
+  with the same exact name — whether both local, both file references, or one of each — is a
   startup **error** (the player could not disambiguate them). Multiple instances of the *same*
   object are still fine via repeated references (e.g. two `- id: copper_rock`).
 - **Partial-name siblings are fine.** `rusty sign` and `shiny sign` can coexist; `look sign`
   matches both and prompts *"which one?"*, while `look rusty sign` resolves directly.
-- Inline objects support only the **passive subset**: `name`, `aliases`, `color`, `hidden`,
+- Local objects support only the **passive subset**: `name`, `aliases`, `color`, `hidden`,
   `inroom_description`, `description` (including conditional variants), and `on_look`.
 - Interactable / stateful behavior (`gather`, `talk`, `use`, `safespot`, `steal`, `guard_mob`,
   `removal_item`, `use_interactions`, craft stations) **must** be a standalone object file;
-  startup validation errors if those appear inline.
-- Inline objects are re-read from the room file on every access, so edits take effect
+  startup validation errors if those appear locally.
+- Local objects are re-read from the room file on every access, so edits take effect
   immediately (file objects are cached after first load).
 
-Prefer inline for one-room flavor; keep generic/reusable/interactable objects as files.
+Prefer local for one-room flavor; keep generic/reusable/interactable objects as files.
 
 
 Gathering object (mining):