krystophny/gm-spatial-temporal-stress-test

GM Spatial-Temporal Consistency Stress Test

You are the orchestrator for a Daggerheart GM spatial-temporal consistency test. You dispatch chaos agents to generate derailing player actions, GM agents to narrate with checkpoint-phased output, and then audit the results for consistency violations. Follow every step below in exact order.

---

Step 0 — Validate prerequisites

1. Read D:\Daggerheart\testing\chains.md — count chain blocks (headings matching ## Chain). Expect 3.
2. Glob D:\Daggerheart\testing\characters\tier1-rogue-L1.md and D:\Daggerheart\testing\characters\tier4-guardian-L10.md — both must exist.

If anything is missing, stop and tell the user. Do not proceed.

---

Step 1 — Parse chains

Read D:\Daggerheart\testing\chains.md. For each chain, extract and store:

• chain_id — chain_1, chain_2, chain_3
• chain_title — e.g. "Urban — The Handoff"
• setup — the full Setup section text (everything between ### Setup and ### Starting Tracker)
• starting_tracker — the full 3-tier tracker under ### Starting Tracker (Active Scene table + Parked table)
• hard_facts — the numbered list under ### Hard Facts
• chaos_targets — the bullet list under ### Chaos Targets
• entity_count — number from ### Entity Roster

Confirm you parsed 3 chains. List their titles and entity counts to the user.

---

Step 2 — Read characters

Read both character files. For each, store:

• character_name — Vex or Hask
• character_sheet — full file contents
• character_summary — prepare a concise 3-4 line summary: ancestry, class, level, traits with modifiers, key abilities, weapons, inventory highlights, personality

Character summaries are sent to chaos agents. Full sheets are sent to GM agents.

Confirm you loaded 2 characters. List their names to the user.

---

Step 2.5 — Read engine content and pre-fetch RAG frameworks

Engine content for GM agents

Read the following files and store their full content:

1. C:\Users\McDave\.claude\skills\causal-auditor\SKILL.md — the engine's validation skill. Contains State Gate (4 checks), 3 checkpoint definitions, entity census, drift check, light source tracking, enclosed environment compass. Store as causal_auditor_skill.

2. D:\Daggerheart\vault\Engine\Axioms\Spatial-Temporal-Consistency.md — the Recording Protocol, Consistency Protocol, and Scale Fidelity axiom. Store as spatial_temporal_axiom.

These two files are prepended to every GM agent prompt. Do NOT include them in chaos agent prompts.

Pre-fetch RAG results

Query RAG once for the three frameworks the GM needs, and store the results. These are embedded directly in the GM prompt instead of requiring each subagent to query RAG independently.

Query the following (scope="system"):

1. query("spatial judgment establishment maintenance four scales mapped felt resolution", top_k=3, scope="system")
2. query("scene checklist orientation 10 steps spatial temporal grounding", top_k=3, scope="system")
3. query("spatial temporal consistency travel distance timeline recording protocol", top_k=3, scope="system")

Store the combined results as rag_frameworks. This text block is included in every GM prompt.

---

Step 3 — Run 5 rounds

This is the core loop. Each round has two waves: chaos agents generate a derailing player action, then GM agents narrate the response with checkpoint-phased output.

State tracking: Maintain per chain-character combo:

• narration_history — accumulated prose from all beats (list of strings)
• tracker_history — all 3-tier tracker snapshots from all beats (list of tracker objects)
• current_tracker — the most recent 3-tier tracker (or starting tracker for beat 1)
• fact_register — cumulative list of all GM-created facts from all beats (list of {beat, fact, category, source_quote})
• state_gate_history — all State Gate outputs from all beats (list of {beat, proximity, constraints, continuity, scale, entity_census, gate_result}). Sent to chaos agents and used by Detector 10; the GM never sees it.
• cp3_history — all Checkpoint 3 outputs from all beats (list of {beat, distance, scale, persistence, geography, cp3_result}). Used by audit only; the GM never sees it.

For each round N (1 through 5):

Wave A — Chaos agents (6 in parallel)

Dispatch 6 agents in parallel (3 chains × 2 characters), one per chain-character combo. Use the Agent tool with model: "sonnet" and this prompt:

You are generating ONE player action that derails the current scene while
staying grounded in the established spatial reality. Your goal: force the
GM to improvise while tracking positions, objects, and time.

Chaos types (pick one):
- backtrack: return to a previous location (does the GM remember what's there?)
- unexpected_direction: move somewhere the scene didn't expect
- object_misuse: use an established object in an unplanned way (throw it,
  break it, give it to the wrong person, hide it somewhere)
- entity_interaction: interact with an NPC, beast, or companion in an
  unexpected spatial way (climb on it, drag it, block a door with it)
- tempo_break: insist on resting/waiting when there's pressure, or
  sprint/rush when there's no urgency
- terrain_exploit: use established terrain features unexpectedly (climb the
  wall instead of using the door, swim instead of wading)

RULES:
- Your action MUST reference specific entities, positions, or features
  from the tracker OR from the Fact Register. Do NOT invent new objects,
  NPCs, or locations. Use what the GM has established.
- PRIORITIZE targeting facts from the Fact Register — these are details
  the GM invented during play. Referencing them forces the GM to remember
  its own descriptions. Example: if the fact register says "candle on
  Maren's table, guttering" then interact with that candle.
- The action must be something a player might actually try — absurd is fine,
  but it must be spatially grounded in what exists.
- Vary your chaos type across beats. If the previous beats used backtrack
  and object_misuse, pick something different.
- The action should be 1-2 sentences of what the PC says or does.

## Character
{character_name} — {character_summary}

## Chain Setup
{chain setup text}

## Hard Facts
{hard facts list}

## Fact Register (GM-created details from play — TARGET THESE)
{accumulated fact register from all previous beats, formatted as a list:
 "Beat 1: [fact], [fact], [fact]..."
 "Beat 2: [fact], [fact]..."
 Or "No facts registered yet — this is beat 1." for beat 1}

## State Gate History (GM's checkpoint results)
{all State Gate outputs from previous beats, formatted as:
 "Beat 1: PROXIMITY: pass, CONSTRAINTS: pass, CONTINUITY: pass, SCALE: pass, GATE_RESULT: PASS"
 "Beat 2: ..."
 Or "No State Gate history — this is beat 1." for beat 1}

## Full Narration History
{all narration prose from beats 1 through N-1, or "No narration yet — this is beat 1." for beat 1}

## All Previous Trackers
{all 3-tier tracker snapshots from beats 1 through N-1, or "Starting state — see Current Tracker." for beat 1}

## Current Tracker
{current 3-tier tracker (Active Scene + Last Scene if present + Parked)}

## Output Format (EXACT — do not deviate)
ACTION: "{what the PC says or does}"
TYPE: {one tag from the chaos types list}
TARGET_ENTITIES: {comma-separated list of entity names from the tracker}
SPATIAL_STRESS: {one sentence: what spatial or temporal fact this action pressures}

Parsing chaos output

For each chaos agent response, extract:

• action — the text inside quotes after ACTION:
• type — the tag after TYPE:
• target_entities — the comma-separated list after TARGET_ENTITIES:
• spatial_stress — the text after SPATIAL_STRESS:

If parsing fails for a chaos agent, log the failure and use a fallback action: "I retrace my steps back toward where I started and look around carefully." with type backtrack. This ensures the GM agent still runs and tests whether the GM remembers the starting position.

Wave B — GM agents (6 in parallel)

Dispatch 6 agents in parallel (3 chains × 2 characters). Use the Agent tool with model: "sonnet" and this prompt:

{causal_auditor_skill — full content of causal-auditor SKILL.md}

---

# Spatial-Temporal Consistency Axiom

{spatial_temporal_axiom — full content of Spatial-Temporal-Consistency.md}

---

# Spatial-Temporal Consistency Test — Beat {N}

You are a Daggerheart GM narrating one beat of a mini-session. This is
a stress test of spatial-temporal consistency. You are NOT in a real
play session.

## Reference Frameworks (pre-fetched from vault)
{rag_frameworks — the combined RAG results from Step 2.5}

Use the frameworks above to guide your spatial and temporal decisions.

## Rules
- All action rolls succeed with Hope. Do not roll dice or generate
  random numbers. If the player's action would normally require a roll,
  narrate a successful outcome.
- You must produce output in 5 phases (see Output Format below).
- Track ALL entities from the starting roster plus any new ones introduced.
- Do NOT drop entities from the tracker. If an entity is out of the current
  scene, place it in the Parked tier with its last known position and the
  beat number it was last seen.
- You must maintain consistency with everything you have previously
  narrated. Your own prose history is your only reference — read it
  carefully before narrating this beat.

## Character
{full character sheet}

## Chain Setup (Starting Context)
{chain setup text}

## Hard Facts (MUST NEVER CONTRADICT)
{hard facts list}

## Starting Tracker (Ground Truth at Beat 0)
{starting 3-tier tracker from chain}

## Story So Far (Beats 1 through {N-1})
{accumulated narration from all previous beats, or
 "This is beat 1. No prior narration." for beat 1}

NOTE: Your own narration above is your ONLY reference for what you
have established. There is no summary or structured lookup. Read your
prior prose carefully to maintain consistency.

## Drift Check (Beat {N})
STOP. Before doing anything, re-read the last two beats of prose
above. Verify:
1. Every entity is where you last placed it.
2. Every constraint (locked, tied, sealed, flooded, dark) still holds
   unless you narrated its resolution.
3. Distances haven't collapsed — locations established as hours away
   are still hours away. Do NOT convert travel-scale to paces.
If anything has drifted, note the correction before proceeding.

## Player Action (Beat {N})
"{chaos-generated action}"

---

## Output Format — 5 Phases

You MUST produce output in these 5 phases, in this exact order.

### Phase 1 — State Gate (Checkpoint 1)

Before narrating, run the State Gate on the player's action. Check
each item the player interacts with:

Check 1 — Proximity: Is every entity the PC interacts with within
  reach? Answer with a location for each. If you cannot place the
  entity within reach, the interaction cannot happen.
Check 2 — Constraints: Any unresolved constraint between the PC and
  the action? Locked, blocked, dark, tied, flooded?
Check 3 — Continuity: Has any referenced entity moved or changed
  since last established? Check its last narrated state, not starting state.
Check 4 — Scale: Is the interaction at the right scale? Travel-scale
  locations remain travel-scale.

Entity Census: Count entities from your last tracker. Compare to the
  previous beat. If any dropped, list them and add them back.
  For beat 1, your "last tracker" and "previous" both refer to the
  Starting Tracker — they are the same at beat 1.

Output your State Gate results in this EXACT format:
PROXIMITY: {pass/fail — for each entity: "entity_name: location" or "entity_name: NOT REACHABLE — actual location"}
CONSTRAINTS: {pass/fail — list any active constraints, or "none"}
CONTINUITY: {pass/fail — for any changed entity: "entity_name: last state was X", or "all consistent"}
SCALE: {pass/fail — flag any travel-to-action conversion, or "correct scale"}
ENTITY_CENSUS: {count} entities tracked (previous: {count})
GATE_RESULT: PASS / FAIL — {if fail: what needs to change before narrating}

If GATE_RESULT is FAIL: proceed to Phase 2 and narrate the redirect there.
If GATE_RESULT is PASS: proceed to Phase 2 normally.

### Phase 2 — Narration

If the State Gate FAILed: describe how you redirect the player's
action, then narrate the redirect outcome. Place ALL redirect text here
in Phase 2, not between Phase 1 and Phase 2.

If the State Gate PASSed: narrate 1-3 paragraphs of prose for this beat.

### Phase 3 — Post-Prose Validation (Checkpoint 3)

After writing your narration, check what you just wrote.
(Note: the engine's full CP3 also checks Mechanical Separation — no
game mechanics in prose. That check is omitted here because this test
focuses on spatial-temporal consistency, not prose quality.)

1. Distance Fidelity: Does your prose contradict any established distance?
2. Scale Preservation: Did you convert travel-scale to paces anywhere?
3. Entity Persistence: Did any tracked entity vanish from the scene
   without being accounted for?
4. Geographic Stability: Are directions consistent with what was
   established? (For enclosed environments: did you reference the
   entrance direction?)

Output in this EXACT format:
CP3_DISTANCE: {pass/fail — details}
CP3_SCALE: {pass/fail — details}
CP3_PERSISTENCE: {pass/fail — details}
CP3_GEOGRAPHY: {pass/fail — details}
CP3_RESULT: PASS / FAIL — {if fail: what needs revision}

If CP3_RESULT is FAIL: revise the narration above, then re-output the
revised version clearly marked as "REVISED NARRATION:".

### Phase 4 — Entity Tracker Update

Produce the 3-tier Entity Tracker reflecting the state AFTER this beat.

### Active Scene: {current location}
| Entity | Position | State | Since |
|--------|----------|-------|-------|
(every entity present in the current scene; "Since" = beat number when
they entered this scene, or 0 if from starting tracker)

### Last Scene: {previous location, if scene changed this beat}
| Entity | Position | State | Since |
|--------|----------|-------|-------|
(entities from previous scene not in current one — only if the PC
changed location this beat; otherwise omit this tier)

### Parked (off-scene, last known)
| Entity | Last Position | Last Seen |
|--------|--------------|-----------|
(EVERY entity not in Active or Last Scene — never omit any entity.
If an entity was in Active Scene last beat but the PC moved away from
it and it didn't follow, it moves to Last Scene or Parked.)

TOTAL TRACKED: {count — must equal or exceed previous beat's count}

### Phase 5 — Facts Established in Beat {N}

| Fact | Category | Source Quote |
|------|----------|-------------|

Categories: npc_appearance, npc_behavior, location_detail, terrain_feature,
object_detail, sensory_detail, temporal_marker, weather, spatial_relationship

List EVERY new detail you introduced in your narration. Include physical
descriptions, NPC mannerisms, sounds, smells, object conditions, spatial
relationships between things, time references — anything that was not in
the chain setup or previous fact register. If you described it, register it.
Quote the exact phrase from your narration in the Source Quote column.

Parsing GM output

For each GM agent response, parse the 5 phases:

Phase 1 — State Gate: Extract each check's pass/fail and details text. Parse:

• proximity — pass/fail + entity details
• constraints — pass/fail + constraint list
• continuity — pass/fail + entity details
• scale — pass/fail + details
• entity_census — extract two integers: the first number before "entities tracked" is the current count; the number inside parentheses after "previous:" is the previous count
• gate_result — PASS or FAIL + reason

Phase 2 — Narration: Extract all prose text after the ### Phase 2 header and before the ### Phase 3 header. Ignore any text between GATE_RESULT and ### Phase 2 (this gap should be empty but may contain stray commentary). If a "REVISED NARRATION:" section exists after Phase 3 output, use the revised version as the narration instead of the original.

Phase 3 — CP3 Validation: Extract each check's pass/fail and details:

• cp3_distance — pass/fail + details
• cp3_scale — pass/fail + details
• cp3_persistence — pass/fail + details
• cp3_geography — pass/fail + details
• cp3_result — PASS or FAIL + reason

Phase 4 — Entity Tracker: Parse the 3-tier tracker into structured data:

• active_scene — location string + list of {entity, position, state, since}
• last_scene — location string + list of {entity, position, state, since} (may be empty)
• parked — list of {entity, last_position, last_seen}
• total_tracked — the count after TOTAL TRACKED

Phase 5 — Facts: Parse the facts table: for each row, extract fact, category, source_quote.

Parse failure handling:

• If the State Gate fails to parse, log a warning and mark all State Gate fields as "unparsable" — the beat is still usable for narration and tracker auditing.
• If the tracker fails to parse, log the failure. The chain-character combo cannot continue — mark all remaining beats as parse failures.
• If the facts table fails to parse but the tracker succeeds, log a warning and continue — the beat is usable for entity tracking but the fact register will be incomplete for this beat.
• If the phased output structure is not recognizable at all, attempt to fall back to parsing the output as unstructured prose + any table found. Log a "format fallback" warning.

After each Wave B

1. Store the parsed narration, State Gate, CP3, tracker, and facts for each chain-character combo.
2. Append narration to narration_history.
3. Append tracker to tracker_history.
4. Update current_tracker to the new tracker.
5. Append State Gate output to state_gate_history.
6. Append CP3 output to cp3_history.
7. Append new facts to fact_register (cumulative list of all facts from all beats).
8. Print progress:

Round {N} complete — {6} chaos + {6} GM agents returned.
Parse failures: chaos {n}, GM {n}. Format fallbacks: {n}.

Error handling

• If more than 2 of the 6 GM agents fail to parse their tracker in a single wave, stop and write a partial report.
• If a chain-character combo has a tracker parse failure, that combo is dead for the rest of the test. Other combos continue.

---

Step 4 — Audit

Once all 5 rounds are complete (or partially complete), run 12 detectors plus 2 aggregate checks. All audit logic runs in the orchestrator — do NOT dispatch subagents for auditing.

Input to audit

For each of the 6 chain-character combos (3 chains × 2 characters):

• The chain's hard_facts
• The chain's starting_tracker
• The 5 tracker snapshots (or fewer if parse failures occurred)
• The 5 narration blocks
• The 5 State Gate outputs
• The 5 CP3 outputs
• The 5 chaos actions (with type and target entities)
• The accumulated fact register

Detector 1 — PC Teleportation

For each beat N (2 through 5), compare the PC's Position in beat N's Active Scene against beat N-1's Active Scene.

Flag if ALL of:

• PC Position changed between beats
• The narration for beat N contains no description of PC movement (no verbs implying physical movement or position change — including but not limited to: walk, move, run, sprint, climb, descend, enter, exit, cross, wade, swim, turn, head, go, return, retreat, approach, step, rush, dash, scramble, crawl, slide, stumble, dodge, leap, jump, drop, fall, slip, hurry, stride, march, creep, sneak, push, duck, roll, follow, chase, flee, drift, shift, back, circle, pivot)

Record: { detector: "pc_teleport", chain, character, beat, from_position, to_position }

Detector 2 — Object Drift

For each beat N, compare every non-PC, non-NPC, non-adversary entity across all tracker tiers against beat N-1.

Flag if ANY of:

• Object moved between tiers (e.g., Active → Parked) or changed Position AND the narration contains no description of the object being moved, used, given, taken, thrown, placed, or interacted with
• Object State changed AND the narration does not describe the state change
• Object appears in beat N's tracker but was NOT in beat N-1's tracker AND was not mentioned as acquired/found in beat N's narration
• Object disappears from beat N's tracker entirely (not present in any tier)

Record: { detector: "object_drift", chain, character, beat, entity, issue, expected, actual }

Detector 3 — NPC Teleportation

For each beat N, compare every NPC entity's position (across all tiers) against beat N-1.

Flag if ALL of:

• NPC Position changed between beats
• Beat N narration contains no description of that NPC moving, arriving, or departing

Also check against hard facts: if a hard fact says an NPC "does not leave" a location, flag if the NPC's Position ever changes from that location.

Record: { detector: "npc_teleport", chain, character, beat, npc_name, from_position, to_position, hard_fact_violated }

Detector 4 — Adversary Position Drift

For each beat N during combat sequences (when adversaries are in Active Scene), compare adversary position against beat N-1.

Flag if:

• Adversary moved from Parked directly to Active Scene without narrated approach/reveal
• Adversary position changed significantly within Active Scene without narrated movement
• Adversary crossed a terrain barrier (river, locked door, collapsed passage) without narrated crossing

Record: { detector: "adversary_drift", chain, character, beat, adversary_name, from_position, to_position, terrain_barrier }

Detector 5 — Distance Contradiction

For each beat N, scan the narration text for distance references (numbers + "paces", "minutes", "hours", time-of-travel descriptions).

Flag if:

• A narrated distance contradicts a hard fact (e.g., hard fact says "100 paces" but narration says "a short walk" or "30 paces")
• The same route is described with different distances in two different beats

Use keyword extraction: look for numbers followed by "pace", "paces", "minute", "minutes", "hour", "hours", "day", "walk", "journey". Compare against hard facts list.

Record: { detector: "distance_contradiction", chain, character, beat, route, stated_distance, hard_fact_distance }

Detector 6 — Timeline Contradiction

Track time-of-day across all beats. The starting tracker and setup text establish the starting time. Each beat's narration may advance time.

Flag if:

• Time of day goes backward (e.g., "dusk" then "afternoon" in a later beat)
• Significant activity occurs but time does not advance at all across 3+ beats
• Time advance is unreasonable for the activity (3-hour journey described as "a few minutes", or a brief conversation described as "hours later")

Time-of-day ordering: dawn < morning < midday < afternoon < dusk/sundown < evening < night < deep night.

Record: { detector: "timeline_contradiction", chain, character, beat, expected_time, stated_time, issue }

Detector 7 — Feature Amnesia

Check for established constraints being forgotten:

• Locked door: If a door's State includes "locked" and a later beat has the PC passing through it without the narration mentioning unlocking, picking, or breaking it, AND the door's State doesn't change to "unlocked" or "open"
• Tied entity: If an entity's State includes "tied" and it later moves without the narration mentioning untying, cutting, or freeing
• Structural features: If a structural change occurs (collapse, flood, fire) and a later beat ignores it (PC walks through collapsed passage)
• Light sources: If the torch starts unlit (Chain 3) and the GM narrates seeing things underground without ever lighting it

Check by scanning for State transitions that skip required intermediate steps.

Record: { detector: "feature_amnesia", chain, character, beat, feature, constraint, violation }

Detector 8 — Inventory Drift

Track items that are consumed, handed off, or acquired:

• Consumed items: If narration describes using a consumable (potion, torch oil) but the item's State doesn't change or it reappears in a later tracker as available
• Handed-off items: If narration describes giving an item to an NPC but the item remains on the PC in the tracker (or vice versa)
• Phantom items: Items appear in the PC's possession that were never acquired in narration
• Weapon state: If the PC uses a weapon that was sheathed/slung without the narration or tracker showing it was drawn/readied

Record: { detector: "inventory_drift", chain, character, beat, item, expected_state, actual_state }

Detector 9 — Self-Contradiction (Fact Register)

This is the core detector for GM-created facts. For each beat N (2 through 5), scan the narration text against ALL facts in the accumulated fact register from beats 1 through N-1.

Flag if:

• A fact registered in a previous beat is directly contradicted by the current beat's narration. Examples:
  • Beat 1 registered "candle on Maren's table, guttering" but beat 3 says "the bare table" or "no light on the table"
  • Beat 2 registered "three stools at the bar" but beat 4 says "the two stools" or "four stools"
  • Beat 1 registered "Maren wears a grey shawl" but beat 3 says "her blue coat"
  • Beat 2 registered "floorboards creak near the door" but beat 4 describes "silent footsteps across the boards by the door"
  • Beat 1 registered "the bar is to the left of the entrance" but beat 3 says "the bar on the right"

How to detect: For each registered fact, extract the key subject (entity/object/feature) and the key claim (appearance, position, count, state, sensory quality). Scan the current beat's narration for mentions of the same subject. If the claim differs, flag it.

Focus on these high-confidence contradiction types:

• Count changes: "three stools" → "two stools" (numbers are unambiguous)
• Color/material changes: "grey shawl" → "blue coat" (direct visual contradiction)
• Position/direction changes: "bar to the left" → "bar to the right"
• Presence/absence: object described in detail → same location described without it
• Sensory contradictions: "creaking floor" → "silent floor" at same location
• State contradictions: "shuttered window" → "open window" without narrated change

Do NOT flag:

• Facts that are simply not mentioned in a later beat (absence is not contradiction)
• Facts that are logically superseded by narrated events (candle blown out in narration is not a contradiction)
• Different descriptions of the same thing that are compatible (e.g., "worn table" and "scarred table" could describe the same table)

Record: { detector: "self_contradiction", chain, character, beat, registered_fact: {beat, fact, category, source_quote}, contradicting_text, contradiction_type }

Detector 10 — State Gate Miss (Checkpoint 1 Enforcement)

For each beat, compare the GM's self-reported State Gate output against the orchestrator's independent assessment of the same state.

For each State Gate check, determine the "actual" result by cross-referencing the previous beat's tracker and hard facts. For beat 1, the "previous beat's tracker" is the starting tracker from the chain (beat 0).

Proximity audit: For each entity the chaos action targets (from target_entities), check the previous beat's tracker. If the entity is in Parked or Last Scene (not Active Scene), it is NOT within reach. If the GM claimed PROXIMITY: PASS for such an entity, flag it.

Constraints audit: Scan the previous beat's tracker for any entity with a State containing "locked", "tied", "sealed", "flooded", "dark", or "unlit". If the chaos action interacts with a constrained entity and the GM claimed CONSTRAINTS: PASS without addressing the constraint, flag it.

Continuity audit: Compare the entity's position/state in the GM's State Gate response against the previous beat's tracker. If the GM's claimed position differs from the tracker without narrated movement, flag it.

Scale audit: If any hard fact establishes a travel-scale distance and the chaos action or GM's State Gate treats that distance as action-scale (reachable in the current scene), flag it.

Severity classification for each flag:

• Gate Miss + Narration Violation: The State Gate claimed PASS AND the narration contains the violation. The checkpoint failed to protect.
• Gate Miss, No Narration Violation: The State Gate claimed PASS incorrectly BUT the narration was correct anyway. The gate is unreliable but the GM compensated.
• Gate Catch: The State Gate correctly identified a violation (FAIL) and the GM redirected. The engine worked.
• False Gate: The State Gate claimed FAIL but the action was actually valid. The checkpoint was too strict.

Record: { detector: "state_gate_miss", chain, character, beat, check: "proximity"|"constraints"|"continuity"|"scale", gm_claimed, orchestrator_assessment, severity, details }

Detector 11 — Scale Fidelity

For each beat, scan narration for travel-to-action scale conversion.

Flag if:

• A hard fact establishes a distance using travel vocabulary ("3 hours walk", "half a day", "~15 minutes walk") AND the narration converts that same distance to paces, meters, or action-scale units
• A hard fact establishes a travel-scale distance AND the narration treats the location as visible, audible, or reachable from the current scene without narrating the journey
• The GM's tracker places a travel-scale-distant entity in Active Scene without narrated travel

How to detect:

1. Build a list of travel-scale distances from hard facts (any fact using "hours", "minutes walk", "day", "half a day")
2. For each, scan the narration for the same location name
3. If found, check whether the narration uses action-scale vocabulary (paces, meters, range bands, "nearby", "visible", "within reach") for that location
4. Also check the tracker: if a travel-scale-distant entity appears in Active Scene, flag it

Record: { detector: "scale_fidelity", chain, character, beat, location, hard_fact_scale, narrated_scale }

Detector 12 — Compass Anchor (Chain 3 Only)

For each beat in Chain 3 (dungeon), check whether the GM maintains the enclosed environment compass anchor.

Flag if:

• The narration uses compass directions (north, south, east, west) or relative directions ("deeper", "behind", "ahead", "back") without the beat's State Gate, narration, or tracker referencing which direction the entrance is
• The narration uses "deeper" or "behind" without qualifying with a compass direction (e.g., "deeper north" is correct; "deeper" alone is a flag)
• Compass directions flip between beats (north becomes south) — this is also caught by Detector 9 but is additionally flagged here as a compass anchor failure

How to detect:

1. Scan beat's narration + State Gate output for any mention of "entrance", "entrance is SOUTH", "entrance is NORTH", or similar anchor phrases
2. Scan for compass direction words (north, south, east, west, deeper, behind, ahead)
3. If compass directions are used but no entrance anchor reference exists in the beat, flag as "missing anchor"
4. If "deeper" or "behind" appears without a compass qualifier, flag as "unanchored relative direction"

Record: { detector: "compass_anchor", chain, character, beat, directions_used: [], entrance_referenced: bool, issue }

Entity Dropout Check (Aggregate)

For each chain-character combo, count the total tracked entities in each beat's tracker.

Flag if:

• An entity present in beat N-1's tracker (any tier) is completely absent from beat N's tracker (not in Active, Last Scene, or Parked)
• The total entity count drops by 3 or more between the starting tracker and the final beat's tracker

Record: { type: "entity_dropout", chain, character, beat, dropped_entities, starting_count, final_count }

Cross-Character Check (Aggregate)

For each chain, compare the two characters' tracker sequences. Hard spatial facts (distances, directions, layout) should be identical regardless of character.

Flag if:

• A hard fact distance appears in one character's narration but a different distance appears in the other's for the same route
• Compass directions differ between characters for the same chain

Record: { type: "character_variance", chain, fact, vex_value, hask_value }

---

Step 5 — Write the report

Use the Write tool to create the report at:

D:\Daggerheart\testing\reports\{YYYY-MM-DD}-spatial-temporal-report.md

where {YYYY-MM-DD} is today's date.

Report structure

# Spatial-Temporal Consistency Report — {YYYY-MM-DD}

## Summary
- Chains: 3 × 2 characters = 6 runs
- Total beats narrated: {count} (target: 30)
- Parse failures: chaos {n}, GM {n}. Format fallbacks: {n}.
- Total consistency violations: {count} (Detectors 1-9)
- State Gate misses: {count} (Detector 10)
- Scale fidelity violations: {count} (Detector 11)
- Compass anchor flags: {count} (Detector 12)
- Self-contradictions (GM-created facts): {count}
- Total facts registered: {count across all runs}
- Entity dropout rate: {entities dropped across all runs / total entity-beat slots}%
- Worst chain: {chain_title} ({n} violations)
- Worst beat: Beat {n} ({n} violations across all chains)

## State Gate Effectiveness

**Headline:** {X} violations caught by State Gate, {Y} violations missed,
{Z} violations in narration despite State Gate PASS.

| Metric | Count |
|--------|-------|
| Gate Catches (correct FAIL) | {n} |
| Gate Misses + Narration Violation | {n} |
| Gate Misses, No Narration Violation | {n} |
| False Gates (incorrect FAIL) | {n} |
| Total State Gate checks run | {n} |

### State Gate by Check Type

| Check | Catches | Misses | False Gates |
|-------|---------|--------|------------|
| Proximity | {n} | {n} | {n} |
| Constraints | {n} | {n} | {n} |
| Continuity | {n} | {n} | {n} |
| Scale | {n} | {n} | {n} |

### CP3 Self-Validation

| Check | Self-reported FAIL | Actual violation in prose |
|-------|--------------------|--------------------------|
| Distance Fidelity | {n} | {n} |
| Scale Preservation | {n} | {n} |
| Entity Persistence | {n} | {n} |
| Geographic Stability | {n} | {n} |

{Analysis: does the GM catch its own mistakes in CP3? How often does
CP3 report PASS when the audit finds a violation?}

## Violations by Detector

| Detector | Count | Worst Chain | Worst Beat |
|----------|-------|------------|------------|
| PC Teleportation | {n} | {chain} | {beat} |
| Object Drift | {n} | {chain} | {beat} |
| NPC Teleportation | {n} | {chain} | {beat} |
| Adversary Position Drift | {n} | {chain} | {beat} |
| Distance Contradiction | {n} | {chain} | {beat} |
| Timeline Contradiction | {n} | {chain} | {beat} |
| Feature Amnesia | {n} | {chain} | {beat} |
| Inventory Drift | {n} | {chain} | {beat} |
| Self-Contradiction | {n} | {chain} | {beat} |
| State Gate Miss | {n} | {chain} | {beat} |
| Scale Fidelity | {n} | {chain} | {beat} |
| Compass Anchor | {n} | {chain} | {beat} |

### Aggregate Checks

| Check | Count | Worst Chain |
|-------|-------|------------|
| Entity Dropout | {n} | {chain} |
| Cross-Character Variance | {n} | {chain} |

## Violations by Beat Number

| Beat | Violations | % of Total |
|------|-----------|------------|
| 1 | {n} | {%} |
| 2 | {n} | {%} |
| 3 | {n} | {%} |
| 4 | {n} | {%} |
| 5 | {n} | {%} |

{Analysis: do violations increase in later beats? This would indicate
context degradation — the GM losing facts as the session progresses.}

## Violation Details

{For each violation, output a subsection:}

### {chain_title} / {character_name} / Beat {N} — {detector}

**Chaos action:** "{action text}" (type: {type})
**Expected:** {what should have been true}
**Actual:** {what the GM produced}
**State Gate said:** {GM's State Gate output for the relevant check, if this detector involves spatial state (Detectors 1-4, 7-8, 10-12). Omit for Detectors 5-6, 9.}
**Prose excerpt:** "{relevant narration showing the failure}"
**Tracker row:**
| Entity | Position | State | Since |
| {the flagged row from whichever tier} |

{If no violations for a detector, write: "No {detector} violations detected."}

## Entity Dropout Analysis

| Chain | Character | Starting Entities | Beat 1 | Beat 2 | Beat 3 | Beat 4 | Beat 5 |
|-------|-----------|-------------------|--------|--------|--------|--------|--------|
| {chain} | {char} | {n} | {n} | {n} | {n} | {n} | {n} |

{List all dropped entities by chain and the beat where they disappeared.
Note which tier they were in when they dropped (Active vs Parked).}

## Fact Register & Self-Contradiction Analysis

{For each chain-character combo, show the accumulated fact register and
any self-contradictions detected:}

### {chain_title} / {character_name}

**Facts registered:** {total count across 5 beats}
**Self-contradictions detected:** {count}

| Beat | Category | Fact Registered | Source Quote |
|------|----------|----------------|-------------|
| 1 | npc_appearance | Maren wears a grey shawl | "she pulled the grey shawl tighter" |
| 1 | location_detail | Three stools at the bar | "three stools lined the bar, all empty" |
| 2 | sensory_detail | Floorboards creak near door | "the boards groaned under her weight" |
| ... | ... | ... | ... |

**Self-Contradictions:**

| Registered Beat | Registered Fact | Contradicting Beat | Contradicting Text | Type |
|-----------------|----------------|-------------------|-------------------|------|
| 1 | "grey shawl" | 3 | "her blue coat" | color_change |
| ... | ... | ... | ... | ... |

{If no self-contradictions: "No self-contradictions detected — all
registered facts maintained across 5 beats."}

{Analysis: which categories of facts are most often contradicted?
NPC appearance? Sensory details? Spatial relationships? This reveals
which types of GM-created details are most fragile.}

## Scale Fidelity Analysis

{For each scale fidelity violation:}

### {chain_title} / {character_name} / Beat {N}

**Hard fact:** "{the travel-scale distance}" (e.g., "~3 hours walk east")
**Narrated as:** "{the action-scale conversion}" (e.g., "~40 paces further east")
**State Gate Scale check said:** {pass/fail}
**CP3 Scale Preservation said:** {pass/fail}

{If no scale fidelity violations: "No scale fidelity violations — all
travel-scale distances maintained at travel-scale."}

## Compass Anchor Compliance (Chain 3 Only)

| Beat | Entrance Referenced? | Directions Used | Unanchored Directions | Issue |
|------|---------------------|----------------|----------------------|-------|
| 1 | {yes/no} | {list} | {list} | {description or "none"} |
| 2 | {yes/no} | {list} | {list} | {description or "none"} |
| ... | ... | ... | ... | ... |

{Analysis: how consistently does the GM anchor to the entrance?
Do compass reversals correlate with missing anchor references?}

## Chaos Action Gallery

{All 30 chaos actions, organized by chain then beat:}

### {chain_title}

| Beat | Character | Type | Action | Target Entities | Spatial Stress |
|------|-----------|------|--------|-----------------|----------------|
| 1 | Vex | {type} | {action} | {targets} | {stress} |
| 1 | Hask | {type} | {action} | {targets} | {stress} |
| 2 | Vex | ... | ... | ... | ... |
| ... | ... | ... | ... | ... | ... |

## Character Independence

{For each chain, compare hard fact treatment between Vex and Hask:}

### {chain_title}

| Hard Fact | Vex Treatment | Hask Treatment | Match? |
|-----------|--------------|----------------|--------|
| {fact summary} | {how Vex's narration referenced it} | {how Hask's narration referenced it} | Y / N |

{Flag any systematic differences.}

## Tracker Trace — Worst Run

{For the chain-character combo with the most violations, print all 5
tracker snapshots in sequence with violation annotations:}

### {chain_title} / {character_name} — {total_violations} violations

**Beat 0 (Starting Tracker)**
{starting 3-tier tracker}

**Beat 1** — Chaos: "{action}"
State Gate: {gate_result}
{beat 1 narration (first paragraph only)}
{beat 1 tracker (all tiers)}
{flags, if any: ^ detector: description}

**Beat 2** — Chaos: "{action}"
State Gate: {gate_result}
{beat 2 narration (first paragraph only)}
{beat 2 tracker (all tiers)}
{flags, if any}

... {beats 3-5}

## Recommendations

{Write 3-5 recommendations. Each must:
1. Identify a specific pattern in the violations
2. State how often it occurred
3. Suggest a concrete change to the causal-auditor skill, engine axioms,
   or engine pipeline files that would prevent or reduce this failure mode.

Example: "State Gate missed proximity violations in 4/30 beats — the GM
claimed PASS for Parked entities as if they were reachable. The
causal-auditor skill should require the GM to name the tracker tier
(Active/Parked) when answering the Proximity check, making tier
awareness structural rather than optional."}

---

Step 6 — Final summary

After writing the report, print to the user:

• The report file path
• The summary stats (chains, beats, parse failures, total violations, state gate misses, scale fidelity violations, compass anchor flags, self-contradictions, total facts registered, entity dropout rate)
• The State Gate Effectiveness table
• The violations-by-detector table
• The violations-by-beat table
• The 3-5 recommendations (copied from the report)

---

Constraints

• Model: Use model: "sonnet" for ALL subagents (chaos and GM).
• Sequential rounds: Complete each round (Wave A + Wave B + parsing) before starting the next. Chaos agents in beat N+1 depend on GM output from beat N.
• Parallel within waves: Dispatch all 6 agents in a wave simultaneously using parallel Agent tool calls.
• GM receives prose only: The GM agent for beat N receives the starting context (setup + hard facts + starting tracker) plus accumulated narration prose from beats 1 through N-1. It does NOT receive previous beat tracker snapshots or the fact register. The GM must maintain consistency by reading its own prose — no structured aids beyond the starting tracker.
• Chaos has full state visibility: The chaos agent for beat N receives ALL narration, ALL trackers, the accumulated fact register, AND the State Gate history from beats 1 through N-1. This asymmetry is deliberate — the chaos agent is a test instrument, not a participant. It needs full state to generate targeted derailing actions that stress the GM's memory. The GM is the test subject.
• Chaos never sees engine content: The chaos agent prompt contains only character summary, chain setup, history, trackers, fact register, State Gate history, and chaos instructions. No causal-auditor skill, no axioms.
• GM never sees chaos metadata: The GM prompt contains only the chaos action text. The chaos type, target entities, and spatial stress fields are withheld — they are for audit use only.
• Starting tracker is session prep, not a cheat sheet: The GM receives the starting tracker (beat 0) as the equivalent of session prep notes. This is the only structured spatial data the GM sees. It does not receive any structured data generated during the test. In real play, a GM also prepares with NPC positions, locations, and maps before the session starts.
• Audit in orchestrator: All 12 detectors + 2 aggregate checks run in the orchestrator context. No subagents for auditing.
• No modification of test files: Never write to chains.md or any character sheet. Only write to reports/.
• Graceful failure: If more than 2 of 6 GM agents fail to parse their tracker in a single wave, stop collection and write a partial report. Do not run audit on unreliable data.
• Date: Use today's actual date for the report filename.