refactor: simplifcation, change how rooms are stored in player yaml, remove legacy code

1 files changed, 28 insertions, 25 deletions

diff --git a/building_guide/rooms.md b/building_guide/rooms.md
index 719c09e..25c6f5f 100644
--- a/building_guide/rooms.md
+++ b/building_guide/rooms.md
@@ -355,14 +355,15 @@ validation reports invalid definitions, and game lookup refuses invalid room
 casino configurations. Raw file editing is not a validated save endpoint.
 
 - IDs must be nonempty, have no surrounding whitespace, and be unique across
-  the room's tables and machines (including legacy slots table entries).
-- Supported table games are `blackjack` and `baccarat`; machines use `slots`
+  the room's tables and machines.
+- Supported table games are `blackjack` and `baccarat`; slots are machines only
+  and must be declared under `casino_machines`. A `slots` entry under
+  `casino_tables` is rejected. Machines use `slots`
   with the optional variant `huff_and_even_more_puff`. A machine variant is
   registered in Go (`slotVariants` in `internal/casino/registry.go`); naming an
   unregistered variant is a validation error.
 - A multiplayer table is addressed by its game name (`play blackjack`), so a
-  room may host only one table per game; a legacy slots table still collides
-  with a slots machine.
+  room may host only one table per game.
 - A machine is addressed by its `variant` when one is declared, so a room may
   host several variants of one game, each reached by its own variant name. A
   bare game name addresses a machine only when it is the sole machine of that
@@ -607,31 +608,33 @@ mobs:
 
 ---
 
-### Room flag triggers
+### Flag triggers
 
-A room that needs to react when a flag changes uses the `on_flag_change:` / `on_global_flag_change:`
-blocks (these replace the old `triggers:` block). Each entry watches one flag, runs a `steps`
-sequence when that flag changes, and resolves broadcasts/spawns against the room. See
+A trigger that reacts to a flag change is a **file-backed trigger**, not a room field. Put it
+under `data/triggers/player_flag/` (watch a player flag with `on_player_flag:`) or
+`data/triggers/global_flag/` (watch a global flag with `on_global_flag:`). Each file holds one
+trigger, the filename stem is its id, and the trigger must set exactly one of those two keys —
+a file with neither is a startup ERROR because it is loaded but can never fire. See
 `triggers.md` for the full reference.
 
 ```yaml
-on_flag_change:
-  - on_player_flag: lever_pulled
-    condition:
-      room: 1001                   # opt-in: only fires if the player is in this room
-    steps:
-      - wait: 5
-        messages: ["The cabin shakes as the small craft touches down"]
-      - wait: 5
-        messages: ["The pistons hiss as the rear staircase opens"]
-      - set_player_flags:
-          1001_touchdown: true
-```
-
-Flag triggers listen **globally** — they fire regardless of where the flag is set. The old
-room `triggers:` block was implicitly room-scoped; migration injects `condition: { room:
-<id> }` to preserve that. Delete the `room` condition to make the trigger fire wherever the
-player is. For server-wide events use global trigger files in `data/triggers/` instead.
+# data/triggers/player_flag/1001_touchdown.yaml
+on_player_flag: lever_pulled
+condition:
+  room: 1001                   # opt-in: only fires if the player is in this room
+steps:
+  - wait: 5
+    messages: ["The cabin shakes as the small craft touches down"]
+  - wait: 5
+    messages: ["The pistons hiss as the rear staircase opens"]
+  - set_player_flags:
+      1001_touchdown: true
+```
+
+Flag triggers listen **globally** — they fire regardless of where the flag is set. Add
+`condition: { room: <id> }` to scope one to the room it belongs to; delete that condition to
+let it fire wherever the player is. Room files support only `on_enter`, `on_exit`, and exit
+`on_traverse` trigger blocks; there is no room-level `on_flag_change:` field.
 
 ---