feat: who, global chat, removed redundant YAML IDs

17 files changed, 58 insertions, 67 deletions

diff --git a/building_guide/bank.md b/building_guide/bank.md
index 0a5ec88..ec03a5a 100644
--- a/building_guide/bank.md
+++ b/building_guide/bank.md
@@ -6,10 +6,9 @@ The bank system allows players to store items permanently, freeing up inventory
 
 ### bank_booth
 
-A bank terminal that players can interact with. Has no special behavior — the `bank` command checks for any `bank_booth` object in the room.
+A bank terminal that players can interact with. Has no special behavior — the `bank` command checks for any `bank_booth` object in the room. (**The filename is the ID** — `bank_booth.yaml` → `bank_booth`; no `id:` field.)
 
 ```yaml
-id: bank_booth
 name: bank booth
 color: "226"
 description: "..."
diff --git a/building_guide/behaviors.md b/building_guide/behaviors.md
index 22e97fe..438e859 100644
--- a/building_guide/behaviors.md
+++ b/building_guide/behaviors.md
@@ -3,11 +3,12 @@
 Behaviors are **inline configs** placed directly inside object YAML (`gather:`, `talk:`,
 `use:`, `safespot:`) or mob YAML (`talk:`). Each section below shows the keys you can use under each behavior type.
 
+The examples below are object/mob files; remember **the filename is the ID** — don't include an `id:` field (see `objects.md` / `mobs.md`).
+
 ### Gather (mining, fishing, woodcutting)
 
 Mining — per-drop depletion on a rock object:
 ```yaml
-id: copper_rock
 name: copper rock
 color: "178"
 gather:
@@ -41,7 +42,6 @@ index to match its display color. Gradients also work: `{g:196,82}text{/}`.
 
 Non-depleting gather (fishing on a fishing spot object):
 ```yaml
-id: bait_fishing_spot
 name: fishing spot
 gather:
     skill: fishing
@@ -66,7 +66,6 @@ gather:
 
 Woodcutting with shared depletion and bird's nests:
 ```yaml
-id: oak_tree
 name: oak tree
 color: "113"
 gather:
@@ -95,7 +94,6 @@ gather:
 
 Regular tree — always depletes on first gather, no shared timer, no nests:
 ```yaml
-id: tree
 name: tree
 gather:
     skill: woodcutting
@@ -189,7 +187,6 @@ Talk configs go under the `talk:` key on objects or mobs. Full conversation with
 conditions, actions, and player flag tracking:
 
 ```yaml
-id: guard
 name: Guard
 talk:
     nodes:
@@ -308,7 +305,6 @@ When the player leaves the shop, they return to the talk node's options.
 
 Full example — General Store:
 ```yaml
-id: general_store_clerk
 name: General Store Clerk
 talk:
     nodes:
@@ -346,7 +342,6 @@ Entries with no `item` field are bare interactions triggered by "use"
 or "push"/"pull":
 
 ```yaml
-id: iron_gate
 name: iron gate
 hidden: true
 description: "A heavy iron gate set into the north wall."
@@ -363,7 +358,6 @@ use_interactions:
 
 Item-specific interaction:
 ```yaml
-id: bookshelf
 name: bookshelf
 use_interactions:
   - item: dusty_tome
@@ -378,7 +372,6 @@ use_interactions:
 Use configs go under the `use:` key on objects (e.g. furnaces, ranges):
 
 ```yaml
-id: furnace
 name: furnace
 color: "208"
 use:
diff --git a/building_guide/construction.md b/building_guide/construction.md
index d9c991a..81e4249 100644
--- a/building_guide/construction.md
+++ b/building_guide/construction.md
@@ -2,6 +2,8 @@
 
 The Construction skill allows players to process logs into planks and assemble planks into furniture at a workbench. Higher-tier logs produce more valuable planks and furniture.
 
+> **Filenames are IDs.** The item/object YAML shown below have no `id:` field — each file's name is its ID (e.g. `construct_oak_planks.yaml` → `construct_oak_planks`). See `items.md` / `objects.md`.
+
 ## Skill
 
 - Skill name: `construction`
@@ -24,7 +26,6 @@ The Construction skill allows players to process logs into planks and assemble p
 The primary construction station. Placed in rooms to enable construction.
 
 ```yaml
-id: workbench
 name: workbench
 color: "172"
 description: "A sturdy wooden workbench..."
@@ -36,7 +37,6 @@ inroom_description: "A workbench stands against the wall..."
 A terminal that shows registered homeowners and lets them enter their house. Handled entirely in Go code (`internal/game/cmd_estate_directory.go`), not via YAML behaviors.
 
 ```yaml
-id: estate_directory
 name: Estate Directory
 color: "39"
 description: "A holographic terminal displaying property records..."
@@ -52,7 +52,6 @@ When a player looks at the directory, it scans `data/players/characters/*.yaml`
 Required tool for cutting logs into planks at the workbench.
 
 ```yaml
-id: saw
 name: saw
 tool_type: saw
 value: 30
@@ -87,7 +86,6 @@ All recipes use `type: construction` and `station: [workbench]`. Log-to-plank re
 
 Example plank recipe:
 ```yaml
-id: construct_oak_planks
 type: construction
 level: 15
 xp: 10
@@ -103,7 +101,6 @@ message: "You saw the oak logs into sturdy oak planks."
 
 Example furniture recipe:
 ```yaml
-id: construct_wooden_table
 type: construction
 level: 6
 xp: 25
@@ -123,7 +120,6 @@ message: "You build a sturdy wooden table."
 Located in room 16 (Construction Site). Talk behavior sells a house plot for 10 credits via `cost` + `set_player_flags`. Sets `owns_house_local_neighborhood: "local_neighborhood"` on purchase.
 
 ```yaml
-id: estate_broker
 name: estate broker
 talk:
     nodes:
@@ -170,7 +166,6 @@ Player houses are real YAML rooms stored in `data/rooms/player_housing/`. Each h
 
 House room files follow the same format as world rooms:
 ```yaml
-id: 200
 name: "Player House: Entrance Hall"
 description: "..."
 exits:
diff --git a/building_guide/courses.md b/building_guide/courses.md
index 491e2bd..e11f909 100644
--- a/building_guide/courses.md
+++ b/building_guide/courses.md
@@ -2,10 +2,11 @@
 
 Agility courses are defined in `data/courses/<id>.yaml`. Each course defines a sequence of obstacle rooms, each with a specific verb the player must type to advance. Obstacle rooms themselves are standard room YAML files (typically in `data/rooms/agility/`).
 
+**The filename is the ID** (`vent_shaft.yaml` → `vent_shaft`); the loader derives it from the filename. Do not put an `id:` field in the file — it is ignored.
+
 ### Course YAML
 
 ```yaml
-id: "vent_shaft"
 name: "Ventilation Shaft Course"
 required_level: 1
 start_room: 200
@@ -79,7 +80,6 @@ Completing all obstacles in a course increments a lap counter stored as a player
 Each obstacle room should have an `on_enter` message telling the player which verb to use, and a `down` exit back to the course hub:
 
 ```yaml
-id: 201
 name: "Ventilation Shaft - Corroded Wall"
 description: "A towering wall of corroded ventilation panels..."
 on_enter:
@@ -93,7 +93,6 @@ exits:
 The hub room (e.g. room 200) links to the first obstacle of each course:
 
 ```yaml
-id: 200
 name: "Agility Training Grounds"
 exits:
   south: 17
diff --git a/building_guide/doors.md b/building_guide/doors.md
index 1e9fb7a..3756a13 100644
--- a/building_guide/doors.md
+++ b/building_guide/doors.md
@@ -1,12 +1,13 @@
 ## Global vs Player State: Door Examples
 
+> **Filenames are IDs.** Object and room YAML below carry no `id:` field — the filename is the ID (e.g. `door_button.yaml` → `door_button`). A nested `- id:` under a room's `objects:` list is a *reference* and stays.
+
 ### Example A: Door with a button in another room (GLOBAL)
 
 A button in room 3 opens a door in room 7. Anyone can press it. Once pressed, the door is open for everyone.
 
 **Button object** (`data/objects/door_button.yaml`):
 ```yaml
-id: door_button
 name: stone button
 hidden: true
 use_interactions:
@@ -21,7 +22,6 @@ use_interactions:
 
 **Room 3** — contains the button:
 ```yaml
-id: 3
 name: "Button Chamber"
 description: "A small stone chamber. A button protrudes from the east wall."
 exits:
@@ -32,7 +32,6 @@ objects:
 
 **Room 7** — contains the door:
 ```yaml
-id: 7
 name: "Hidden Passage"
 description: "A dusty corridor. A heavy stone door blocks the way north."
 exits:
@@ -54,7 +53,6 @@ A locked door that only opens for a player carrying the key. Each player must fi
 
 **Key item** (`data/items/rusty_key.yaml`):
 ```yaml
-id: rusty_key
 name: rusty key
 description: "An old iron key, still functional."
 value: 0
@@ -63,7 +61,6 @@ stackable: false
 
 **Room 5** — locked door:
 ```yaml
-id: 5
 name: "Locked Storage"
 description: "A small storage room. The way east is blocked by a locked iron door."
 exits:
@@ -80,7 +77,6 @@ objects:
 
 **Room 6** — the other side (no key needed to exit):
 ```yaml
-id: 6
 name: "Storage Closet"
 description: "Shelves of dusty crates."
 exits:
diff --git a/building_guide/drops.md b/building_guide/drops.md
index e5a17ff..f71f712 100644
--- a/building_guide/drops.md
+++ b/building_guide/drops.md
@@ -1,9 +1,12 @@
 ## Drop Tables
 
+**The filename is the ID.** A drop table is looked up by its filename stem
+(`gem_table.yaml` → `gem_table`); reference it from behaviors/mobs by that name. Do not put
+an `id:` field in the file — it is ignored.
+
 Shared drop tables can be referenced by multiple behaviors:
 ```yaml
 # data/drops/gem_table.yaml
-id: gem_table
 drops:
   - item_id: uncut_sapphire
     weight: 47
@@ -18,7 +21,6 @@ drops:
 Bird's nest drop table:
 ```yaml
 # data/drops/birds_nest_drop.yaml
-id: birds_nest_drop
 drops:
   - item_id: credits
     weight: 50
diff --git a/building_guide/hacking.md b/building_guide/hacking.md
index 8927b3e..c17d11a 100644
--- a/building_guide/hacking.md
+++ b/building_guide/hacking.md
@@ -2,10 +2,11 @@
 
 Hacking minigames are played by jacking into terminal objects. Terminals are YAML objects that are registered in Go's `terminalDefs` map.
 
+**The filename is the ID** (`terminal_basic.yaml` → `terminal_basic`); like all objects, the loader derives the ID from the filename — don't add an `id:` field (see `objects.md`).
+
 ### Terminal Object YAML
 
 ```yaml
-id: terminal_basic
 name: basic terminal
 color: "40"
 description: "A battered terminal with a cracked screen. {40}[Level 1 Hacking]{/}"
diff --git a/building_guide/hazards.md b/building_guide/hazards.md
index 453ca18..26fdccc 100644
--- a/building_guide/hazards.md
+++ b/building_guide/hazards.md
@@ -13,8 +13,9 @@ define a hazard once in `data/hazards/<id>.yaml`, then reference it from any num
 of rooms with `hazard: <id>` (see `rooms.md`). This makes one hazard reusable
 across a whole area and lets a future `examine` command resolve it by name.
 
+**The filename is the ID** (`solar_radiation.yaml` → reference it as `hazard: solar_radiation`); the loader derives it from the filename. Do not put an `id:` field in the file — it is ignored.
+
 ```yaml
-id: solar_radiation
 name: scorching solar radiation
 description: "Unfiltered sunlight pours through a gap in the dome, burning exposed skin."
 attack_type: science          # stab/slash/crush/ranged/science — picks player defense + protect tech
diff --git a/building_guide/hidden_objects.md b/building_guide/hidden_objects.md
index e79c026..65940d6 100644
--- a/building_guide/hidden_objects.md
+++ b/building_guide/hidden_objects.md
@@ -2,9 +2,10 @@
 
 Objects with `hidden: true` don't appear in the room's object listing. Players discover them by reading room descriptions or trying commands. The object is still fully interactable — `push gate`, `look gate`, etc.
 
+**The filename is the ID** (`secret_lever.yaml` → `secret_lever`); don't add an `id:` field (see `objects.md`).
+
 ```yaml
 # data/objects/secret_lever.yaml
-id: secret_lever
 name: stone lever
 hidden: true
 description: "A cleverly concealed lever behind a loose stone."
@@ -30,7 +31,6 @@ By default an object matches its `name` (word-prefix matching) and the words in
 its `id`. Add `aliases` to accept extra names:
 
 ```yaml
-id: 1002_shuttle
 name: landing craft        # matches "landing", "craft", "landing craft"
 aliases: [shuttle, ship]   # also matches "shuttle" and "ship"
 hidden: true
@@ -53,7 +53,6 @@ same shared object can appear only while a player's flags warrant it (e.g. durin
 an intro) and vanish on return visits.
 
 ```yaml
-id: 1002_crowd
 name: crowd of people
 aliases: [people, crowd, passengers]
 hidden: true
diff --git a/building_guide/items.md b/building_guide/items.md
index 52bfa7d..658acb9 100644
--- a/building_guide/items.md
+++ b/building_guide/items.md
@@ -1,7 +1,11 @@
 ## Items
 
+**The filename is the ID.** An item is looked up by its filename stem
+(`bronze_pickaxe.yaml` → `bronze_pickaxe`); the loader derives `ItemDef.ID` from it. Do not
+put an `id:` field in the file — it is ignored. Anything that references this item (drop
+tables, craft `consume`, room `item_spawns`) uses that filename.
+
 ```yaml
-id: bronze_pickaxe
 name: bronze pickaxe
 color: "178"                   # xterm-256 color index (0-255)
 aliases: ["pick", "pickaxe"]
@@ -85,7 +89,6 @@ Standard tiers: bronze/iron (none), steel (5), black (10), mithril (20), adamant
 Arrows and bolts use `ranged_strength` for damage. Accuracy comes from the bow:
 
 ```yaml
-id: iron_arrow
 name: iron arrow
 stackable: true
 equip_slot: ammo
@@ -107,7 +110,6 @@ In ANSI mode, extended colors (16-255) automatically downgrade to the nearest AN
 
 Key item (quest token, not equippable):
 ```yaml
-id: pass_stub
 name: pass stub
 description: "A crumpled slip of paper stamped with the guard's seal."
 value: 0
@@ -119,7 +121,6 @@ stackable: false
 ## Firemaking
 
 ```yaml
-id: logs
 name: logs
 fire_level: 1         # firemaking level required
 fire_xp: 40           # XP for burning/stoking
@@ -129,7 +130,6 @@ burn_ticks: 24        # how long the fire burns
 ## Food / Healing
 
 ```yaml
-id: bread
 name: bread
 color: "222"
 description: "A fresh loaf of bread, still warm from the oven."
@@ -143,7 +143,6 @@ eat_message: "You eat the bread. Warm and satisfying."
 Define what items combine to make this item. Used by the `use` command. Combinations run through the production system — players are prompted "How many?" and the action loops with a timer.
 
 ```yaml
-id: bread_dough
 name: bread dough
 color: "222"
 ticks: 2
diff --git a/building_guide/mobs.md b/building_guide/mobs.md
index c1f9332..88e80ce 100644
--- a/building_guide/mobs.md
+++ b/building_guide/mobs.md
@@ -1,8 +1,11 @@
 ## Mobs
 
+**The filename is the ID.** A mob is looked up by its filename stem (`goblin.yaml` →
+`goblin`), and the loader derives `MobDef.ID` from it. Do not put an `id:` field in the file
+— it is ignored. Rooms reference mobs by that filename.
+
 Basic combat mob with per-type defense bonuses:
 ```yaml
-id: "man"
 name: "man"
 description: "A shabby-looking man."
 attack: 1
@@ -39,7 +42,6 @@ combat_descriptions:
 Mobs with `aggressive: true` auto-attack players entering their room (1-tick delay). Only aggros if the player's combat level is at most double the mob's combat level. Checked on room enter and login.
 
 ```yaml
-id: goblin
 name: goblin
 aggressive: true              # attacks players on sight
 attack: 1
@@ -77,7 +79,6 @@ ranged_defense: 3
 
 Mob with talk behavior — can be talked to via `talk:` inline config:
 ```yaml
-id: "guard"
 name: "Guard"
 talk:                           # inline talk config (no separate behavior file)
     nodes:
@@ -116,7 +117,6 @@ is per-instance in the room YAML (see Rooms > Mobs section above).
 Mobs can be stealable via the `steal` command. On failure, the mob turns hostile and attacks.
 
 ```yaml
-id: farmer
 name: Farmer
 steal_table: farmer_steal       # Drop table for steal loot
 steal_level: 10                 # Required thieving level
@@ -136,7 +136,6 @@ steal_speed: 4                  # Ticks per steal attempt
 Assassin (Slayer) mobs restrict combat by assassin level and introduce finishing blows and protective equipment:
 
 ```yaml
-id: slug
 name: slug
 assassin_level: 1              # required assassin level to attack
 finishing_blow: salt           # item required to kill (mob stays at 1 HP otherwise)
@@ -155,7 +154,6 @@ drops:
 
 Damage-without mobs deal 1.5x damage unless the player has the specified item equipped:
 ```yaml
-id: drone
 name: drone
 assassin_level: 15
 damage_without: insulated_gloves   # 1.5x damage without this item equipped
@@ -180,7 +178,6 @@ Mobs without these fields work normally (assassin_level defaults to 0, finishing
 A task mob is a non-violent "worksite" — build a solar panel, survey flora, prospect a rock — that reuses the entire combat engine. Set `kind: task`. Mechanically its `hp` is a hidden work pool that drains to 0 to **complete** the work; the player sees a progress bar filling toward 100%. A task mob **never attacks back** — the danger (if any) comes from a room `hazard:` (see `hazards.md`). Use the `work` command (or `attack`) on it.
 
 ```yaml
-id: solar_panel_frame
 name: solar panel frame
 kind: task                     # "" / "combat" (default) or "task"
 verb: assemble                 # flavor verb shown in messages (default: "work on")
diff --git a/building_guide/objects.md b/building_guide/objects.md
index 427968a..110eb56 100644
--- a/building_guide/objects.md
+++ b/building_guide/objects.md
@@ -4,9 +4,28 @@ Objects interact with the world through **inline behavior configs** under
 `gather:`, `talk:`, or `use:` keys. There is no separate behavior
 directory — everything goes directly in the object's YAML.
 
+### Naming & file organization
+
+**The filename is the ID.** An object is looked up by its filename stem
+(`copper_rock.yaml` → `copper_rock`), and the loader derives `ObjectDef.ID` from that
+filename. Rooms reference the object by this bare ID regardless of which folder the file
+lives in. **Do not put an `id:` field in the file** — it is ignored. (A nested `- id:` under
+a room's `objects:` list is a different thing: a *reference* to an object by its filename,
+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) are prefixed
+  with the room number and placed in `data/objects/unique/` — e.g.
+  `data/objects/unique/1001_sign.yaml` (ID `1001_sign`, referenced from room `1001`).
+
+Loading walks `data/objects/` recursively, so subdirectories are purely organizational and
+need no changes to room references when a file is moved. They do **not** namespace IDs: every
+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.
+
 Gathering object (mining):
 ```yaml
-id: copper_rock
 name: copper rock
 color: "178"                   # xterm-256 color index (0-255)
 gather:
@@ -37,7 +56,6 @@ gather:
 
 Tree object (woodcutting with shared depletion):
 ```yaml
-id: oak_tree
 name: oak tree
 color: "113"
 gather:
@@ -70,7 +88,6 @@ ANSI color.
 
 Object interaction (gate, lever — uses `use_interactions:` key):
 ```yaml
-id: iron_gate
 name: iron gate
 hidden: true
 description: "A heavy iron gate set into the north wall."
@@ -87,14 +104,12 @@ use_interactions:
 
 Decorative object (no behavior keys — just a name/description):
 ```yaml
-id: lumby_fountain
 name: town fountain
 description: "Clear water sparkles in the sunlight."
 ```
 
 Talk object (NPC conversations — uses `talk:` key):
 ```yaml
-id: tool_shed
 name: Tool Shed
 description: "A small shed with an open window."
 talk:
@@ -121,7 +136,6 @@ Entries are checked top-to-bottom; the first match with a passing condition wins
 
 Simple message (no action):
 ```yaml
-id: anvil
 name: anvil
 use_interactions:
   - item_id: silver_bar
@@ -132,7 +146,6 @@ use_interactions:
 
 Puzzle interaction (take item, set flag):
 ```yaml
-id: crystal_slot
 name: crystal slot
 use_interactions:
   - item_id: crystal_key
@@ -201,7 +214,6 @@ use_interactions:
 Objects can be stealable via the `steal` command. These use the same drop table system as mobs and searches.
 
 ```yaml
-id: market_stall
 name: Market Stall
 description: "A wooden stall piled with food and sundries."
 steal_table: market_stall_steal
@@ -234,7 +246,6 @@ crouch behind them and attack with ranged or science weapons. Melee attacks forc
 out of cover.
 
 ```yaml
-id: rock_outcrop
 name: rock outcrop
 color: "248"
 hidden: true
diff --git a/building_guide/quests.md b/building_guide/quests.md
index b5f18fa..a764f8e 100644
--- a/building_guide/quests.md
+++ b/building_guide/quests.md
@@ -1,8 +1,9 @@
 ## Complete Quest Example: "Clear the Rats"
 
+> **Filenames are IDs.** Every mob/object/room file below has no `id:` field — its filename is its ID (e.g. `quest_giver.yaml` → `quest_giver`). Nested `- id:` under a room's `objects:`/`mobs:` are references and stay.
+
 ### 1. Quest giver mob (`data/mobs/quest_giver.yaml`)
 ```yaml
-id: "quest_giver"
 name: "Elder"
 unique: true
 protected: true
@@ -57,7 +58,6 @@ Talk configs are inline on the mob under the `talk:` key. No separate behavior f
 
 ### 2. Rat mobs (`data/mobs/rat.yaml`)
 ```yaml
-id: "rat"
 name: "giant rat"
 attack: 2
 strength: 1
@@ -72,7 +72,6 @@ drops:
 
 ### 3. Cellar room (`data/rooms/20.yaml`)
 ```yaml
-id: 20
 name: "Cellar"
 description: "A damp, dark cellar. The floor scuttles with movement."
 exits:
@@ -87,7 +86,6 @@ mobs:
 
 ### 4. Room 1 with quest giver (`data/rooms/1.yaml`)
 ```yaml
-id: 1
 name: "Town Square"
 description: "Cobblestone paths lead in all directions. The Elder stands near the fountain."
 exits:
diff --git a/building_guide/recipes.md b/building_guide/recipes.md
index 450ded9..43b1cf4 100644
--- a/building_guide/recipes.md
+++ b/building_guide/recipes.md
@@ -2,7 +2,7 @@
 
 ## Crafting
 
-Crafting information lives on the **output item's YAML file** via the `craft:` block. There is no separate recipe directory. To find out how to make `bronze_dagger`, open `data/items/equipment/bronze_dagger.yaml` and look for the `craft:` block.
+Crafting information lives on the **output item's YAML file** via the `craft:` block. There is no separate recipe directory. To find out how to make `bronze_dagger`, open `data/items/equipment/bronze_dagger.yaml` and look for the `craft:` block. (The item's **filename is its ID** — `bronze_dagger.yaml` → `bronze_dagger`; there is no `id:` field. `consume`/output entries reference items by filename.)
 
 ### Craft YAML Reference
 
@@ -257,7 +257,6 @@ craft:
 Items with `heal_value` and `eat_message` can be consumed via the `eat` command.
 
 ```yaml
-id: bread
 name: bread
 color: "222"
 description: "A fresh loaf of bread, still warm from the oven."
diff --git a/building_guide/rooms.md b/building_guide/rooms.md
index 735a6b4..e1408c5 100644
--- a/building_guide/rooms.md
+++ b/building_guide/rooms.md
@@ -1,8 +1,12 @@
 ## Rooms
 
+**The filename is the ID.** A room's numeric filename is its ID (`1.yaml` → room `1`); the
+loader derives it from the filename. Do not put an `id:` field in the file — it is ignored.
+Exits and other rooms reference a room by that number. (A nested `- id:` under `objects:` or
+`mobs:` is a *reference* to an object/mob by its filename, and is still required.)
+
 Minimal room:
 ```yaml
-id: 1
 name: "Town Square"
 description: "Cobblestone paths lead in all directions. A fountain gurgles peacefully."
 exits:
@@ -186,7 +190,6 @@ A room can reference a shared hazard by ID. The hazard rolls an attack against
 everyone in the room every few ticks using the combat formulas (see `hazards.md`).
 
 ```yaml
-id: 99999181
 name: "Exposed Solar Array"
 hazard: solar_radiation        # ID of a data/hazards/<id>.yaml definition
 exits:
diff --git a/building_guide/wandering_mobs.md b/building_guide/wandering_mobs.md
index 8d49ed9..7e2bfb6 100644
--- a/building_guide/wandering_mobs.md
+++ b/building_guide/wandering_mobs.md
@@ -1,6 +1,6 @@
 ## Wandering Mobs
 
-Mob wandering is configured per-instance in the room YAML, not on the mob definition:
+Mob wandering is configured per-instance in the room YAML, not on the mob definition. (`- id: man` here references the mob whose **filename** is `man.yaml`.)
 ```yaml
 # In a room:
 mobs:
diff --git a/building_guide/wandering_objects.md b/building_guide/wandering_objects.md
index f1f91c5..a181218 100644
--- a/building_guide/wandering_objects.md
+++ b/building_guide/wandering_objects.md
@@ -1,9 +1,8 @@
 ## Wandering Objects
 
-Fishing spots that move between rooms:
+Fishing spots that move between rooms (**the filename is the ID** — `fishing_spot.yaml` → `fishing_spot`, no `id:` field):
 ```yaml
 # data/objects/fishing_spot.yaml
-id: fishing_spot
 name: fishing spot
 gather:
     skill: fishing