Interaction spec: what a developer can build from.

Your Three.js bridge document (section 04) already lists camera, lights, assets, and interaction hitboxes. That document is a prompt. Paste it into Codex with a request for a runnable scaffold.

Build a single-file Three.js scene from the spec below. Use
Three.js r160 via ESM CDN; no build step. Requirements:

Scene
- Camera: perspective, 50° fov, positioned per spec's camera brief.
- Lights: one hemisphere (sky→ground) + one directional with shadow.
- Ground: plane, 20x20, receives shadow.
- Placeholder geometry for each named asset in the spec; use named
  meshes (mesh.name = "monitor", "chart", "door", etc.) so we can
  target them by name later.

Interaction
- Raycaster on click. Emit a CustomEvent on window with type
  "game:interact" and detail { meshName, worldPoint }.
- No game logic in this file — the scene only emits events.

Devex
- Export a single init(container) function.
- Log every emitted event to console with timestamp.
- If a mesh name isn't recognized, log "unmapped:" + name, do not throw.

[PASTE THREE.JS BRIDGE DOC FROM SPEC]

Your state machine (section 02) is a table: states, events, transitions, guards. Codex translates that table into a runtime in one pass. Ask for plain JS, no dependencies; that way you or your developer can read the whole thing before running it.

Generate a minimal state-machine runtime in plain JS (no XState, no
dependencies). API:

  const sm = createMachine({
    initial: "triage",
    states: {
      triage: { on: { SUBMIT: "feedback" } },
      feedback: { on: { NEXT: "triage", END_SHIFT: "debrief" } },
      debrief: { on: { RETRY: "triage" } },
    },
    guards: { /* optional named fns returning boolean */ },
  });

  sm.send("SUBMIT");          // transitions if allowed
  sm.state                    // current state name
  sm.onTransition(fn)         // fn({ from, to, event })
  sm.can("SUBMIT")            // boolean

Requirements:
- ~80 lines, readable, no cleverness.
- Throws if sent an event not defined on current state (opt-out flag
  allowMissing: true).
- Ships with unit tests (10+ cases) using plain console.assert.

Generate my game's machine as a second file, populated from this
transitions table:

[PASTE TRANSITIONS TABLE]

A common failure in an event map is forgotten cells — events that never emit a response, or response types that appear in one event's row but not in a parallel event's row. Codex can read your table and list gaps before a developer does.

Here is my event→feedback map as a markdown table. Audit it and
output:

1. Events with no response at all.
2. Events whose "response kind" column uses a kind that doesn't
   appear in the legend of my S4 taxonomy.
3. Events that emit consequence feedback but don't specify what
   world state changes.
4. Pairs of events that look parallel but whose response schemas
   differ (e.g., one logs to telemetry, the sibling doesn't).

Don't propose fixes. Just list the gaps so I can decide each.