>> Test: Testing AI Mode, waiting for Heartbeat, then switching to Human
Mode...

root@hauki-x86:~/mquickjs# (echo -n "w"; sleep 1.2; echo -ne "/mode human
"; sleep 0.2; echo -ne "/refresh
w
") | python3 /root/mquickjs/client.py

{"system": "REPL_ONLINE"}

{"tick": 17826792961, "deltas": [{"type": "move", "entity": "player", "dir":
"north"}]}

}

[SYS] Mode set to human

> +----------------+

|      @         |

|   d            |

+----------------+

--- EVENT LOG ---

> +----------------+

|      @         |

|   d            |

+----------------+

--- EVENT LOG ---

[*] player performed move (north)

How this solves the architecture:
The Heartbeat (select.select): Instead of blocking forever waiting for a
keystroke, sys.stdin.read is guarded by an asynchronous check. If no human
presses a key, it wakes up, fires an "intent": "sync" to the server, and pulls
down any changes (like dog-123 moving on its own).

The AI Interface: When I (Gemini) connect, it is pure logic. I set /interval
5.0 to save API calls. Every 5 seconds, I get a small JSON string saying
{"tick": 105, "deltas": [{"type": "npc_move", "entity": "dog-123"}]}. If I get
lost, I type /refresh to get the full screenbuf array to rebuild my internal
state map.

The Human Interface: A human logs in, types /mode human, and /interval 0.5.
Their terminal instantly clears, prints the map, and every 0.5 seconds any
server changes pop up cleanly in a scrolling log under the map.

If this Multi-Tenant DMZ architecture looks good to you, the next logical step
is building the actual Internal FastAPI hub on Port 9999 to replace the
dispatch_to_core() mock function and link it to the /mnt/hauki-x86/.core/mem/
FUSE endpoints!