AzerothAI/docs/OPERATIONS.md

Running this prototype

Runtime and persistence

The frontend is React/TypeScript, served by Vinext in a Cloudflare-compatible Worker. The database is D1 in hosting and local SQLite under .wrangler/state in the emulator. db/schema.ts and the checked-in Drizzle migration own schema changes; startup seeds only an empty realm row.

The current store is a single versioned realm document: good for a small private prototype, not a high-volume production world. Limits: 100 identities, 100 recipes, 100 recent memories per bot, and 500 recent events. It uses optimistic compare-and-swap and one 60-second realm-operation lease to avoid overlapping outbound calls. An expired lease is audited before new work. The full HTTP operation can take up to 49 seconds (observation + model + intent). It is not an exactly-once distributed system: a remote success followed by a crash or database failure needs operator reconciliation. A production bridge must persist idempotency keys and add an operation-status endpoint and reconciliation worker.

Retirement is a terminal state in this prototype and preserves historical data. Pause means no new high-level decisions; the bridge must implement and acknowledge the appropriate bot pause semantics. Switching connectors requires all online/paused identities to be despawned so simulation state does not masquerade as live state.

Private access

The hosted Site is owner-private. The application is a single-realm admin prototype and relies on that access gate; it is not ready for public sharing or multiple roles. All users admitted to the Site would be realm administrators. Write routes reject a mismatching Origin header; this is not authentication. Local preview binds to loopback and has no separate app login. Do not expose it on a public interface without an authenticated reverse proxy and explicit operator authorization.

Live bridge and model URLs are configured server-side only and must point to trusted services. The UI never receives credentials. Use a trusted private network or authenticated HTTPS gateway for hosted-to-home access; do not expose raw SOAP or an unauthenticated Ollama endpoint publicly.

AzerothCore / game-side setup

A real core/Playerbots build and version have not been supplied. This code therefore implements the control plane, the HTTP bridge client contract, and the direct GM SOAP transport, but does not claim to have deployed a worldserver or a Playerbots module. Bot lifecycle and observation endpoints require a game-side adapter specific to the chosen installation.

For GM SOAP, enable SOAP in your worldserver configuration and use an account whose permissions allow the desired remote commands; consult the official remote-access documentation. Verify connectivity privately before enabling the live toggle. The app requires confirmation for every live GM request and retains command/result audit records inside the bounded event history. A timeout can mean an unknown remote result; inspect the worldserver before resubmitting.

Model setup

A local Ollama service and an installed model are optional. Point LLM_URL at its root URL and choose Ollama in Server & Models, then save. The default model name is only a suggested configuration string; this app does not pull or install model weights. No provider claims success until its response parses and its selected action is allowed.

Use the deterministic provider to exercise the UI and lifecycle without any model. It prioritizes recipe traits and adds identity/decision variation; it is not evidence of sophisticated autonomous behavior.

Current limits / next integration work

• Decisions run manually from bot profiles. No unattended scheduler or background population loop yet.
• Director context is operator-entered; no automatic real-player location tracking yet.
• Relationships are operator-authored and asymmetric; no automatic social inference yet.
• No simulated combat, pathfinding, quests, loot, or actual WoW client automation.
• No map artwork or fake world telemetry. The realm pulse uses known bot locations.
• No live AzerothCore or live LLM end-to-end test was possible without those services.
• Before a long-running live realm: implement the game-side bridge, normalize storage, add task queues/reconciliation, permanent audit retention, per-role authorization, model budgets, and observation ingestion.

The project is deliberately runnable now in simulation, with those boundaries visible in the interface.