feat(ci): add golden file targets and checklist schema (#486, #497)

Golden targets: make golden-diff shows color diff if simulation output
changed, make golden-update regenerates and stages for review.

Checklist schema: JSON Schema for 7 condition types evaluable from
ObserverSnapshot. Per-room YAML checklists for 3 Gauntlet rooms plus
cross-room checks. Validation script + make checklist-validate/generate.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs/DEVOPS.md

@@ -88,6 +88,24 @@ Regenerate both after any protocol change. Commit the updated fixtures alongside
 - **`gdscript_generated_fixtures_deserialize` fails:** Fixtures in `server/tests/fixtures/gdscript/` are stale or corrupted. Re-run `make fixtures-client` and commit the updated files.
 - **Fixture staleness in `make pre-pr`:** Protocol changed but fixtures were not regenerated. Run `make fixtures && make fixtures-client`, then commit both `client/tests/fixtures/` and `server/tests/fixtures/gdscript/`.
 
+### Golden File Management
+
+```bash
+make golden-diff        # Show diff if golden file output has changed
+make golden-update      # Regenerate golden file and stage for commit
+```
+
+The golden file (`server/tests/golden/proof_room_tick_10.json`) is a committed snapshot of ObserverSnapshot output after a deterministic 10-tick replay. It catches unintentional changes to simulation output.
+
+**Workflow after intentional simulation changes:**
+
+1. Run `make golden-diff` to see what changed
+2. Review the diff — confirm changes are expected
+3. Run `make golden-update` to regenerate and stage the new golden file
+4. Commit the updated golden file alongside your simulation change
+
+`golden-diff` exits 1 if the golden file has changed (useful in scripts). `golden-update` regenerates the file and runs `git add` but does not commit — the developer reviews and commits manually.
+
 ### Lint
 
 ```bash
@@ -149,6 +167,19 @@ make validate-content     # Validate content YAML against JSON schemas
 make check-fact-ids       # Check fact_id references against knowledge catalogs
 ```
 
+### Gauntlet Checklists
+
+```bash
+make checklist-validate   # Validate checklist YAML against schema (standalone)
+make checklist-generate   # Validate + print per-room condition summary
+```
+
+Checklists live at `content/gauntlet/rooms/{room_id}/checklist.yaml` (per-room) and `content/gauntlet/cross_room_checks.yaml` (cross-room). Each condition is evaluable from an `ObserverSnapshot`.
+
+7 condition types: `player_near`, `player_facing`, `entity_present`, `entity_absent`, `expected_monologue`, `expected_dialogue`, `expected_interaction_verb`.
+
+Schema: `content/_schema/checklist.schema.json`. The checklist format feeds into #503 (client auto-checklist progress tracking).
+
 `check-fact-ids` operates in two modes:
 - **Advisory** — when knowledge catalogs (`content/global/knowledge/*.yaml`) have no fact definitions yet: lists referenced fact_ids and exits cleanly.
 - **Enforcing** — when catalogs are populated: fails on any `fact_id` reference that doesn't match a canonical definition.