← all epics

Building the Game — one site, the Builder, and the building blocks

repo: land-of-lor (site/, builder/, game/director for content schemas, tools/) — one repo since 2026-09-03 · depends on: world-map-and-portalsground-typeselement-tableserver-architecture

Where this stands (2026-09-13)

Signed off by Kris on 2026-09-04 as a line in the sand (APK v26, the web build on /play): one repo and spellgrove.com, the Builder’s read side and hub pages, sign-in and roles, publish with staging and the database canonical, Ask an agent, and Dirt with its inventory and card. The Builder was rebuilt for the 2026-09-13 security audit — three least-privilege database roles, and authored content parsed as data rather than executed. Ideas held, not tasks: other people editing their own Areas (was 006), which needs Kris’s call on how a player gets a named Area first; and a per-Area item limit, noted in game/world/client/items/README.md. No open issues. Past task files (to 2026-09-13): workshop/historic-docs/epics/building-the-game/tasks/.

What this is

Kris, 2026-09-03, by voice and then in conversation: one central, live view of the game’s building blocks — the element table, the same 64 as ground types, the creatures, the world map, and each Area with its properties — with the existing editors linked together and zero duplication of data so nothing can drift. Then the ask grew into its real shape:

• The site is the view. Public and view-only for everyone; editable by Kris when signed in with his game account; later editable in specific parts (their own Areas) by other players, using the game’s own accounts to decide who may edit what.
• From every section, hand an agent a task via the AI Task Runner, with that section’s context (which files, which epic, the current values) already in the prompt. “This is the real launching pad for building the game.”
• One repo, one site. The workspace repo merged into land-of-lor (workshop/ and site/); the site moved off the task-runner host onto the game droplet at spellgrove.com; the old host redirects.
• The Builder is separate from the game. The admin/authoring API is its own service (builder/), its own process, port, path (/builder/) and database. The game’s director learns nothing about it; duplicating a little code between them is the price of the game standing alone one day, and it is worth paying.
• The database is canonical for authored content; the .json/.js files in the repo are snapshots that every publish always writes. A staging game stack exists, the app gets a hidden dev option to point at it, and every publish shows two tick boxes — Staging and Live — both on by default, remembered per editor afterwards, and says plainly what goes where.
• Nothing here may preclude later finessing of creature properties, ground types or Area properties through the same view: the content endpoints return whole objects, the editors bind by field name.

The architecture in short:

spellgrove.com  (Caddy on the droplet, auto-TLS)
  /            the static site, built on the droplet from site/ by lor-site-build.timer
  /director/   the game (unchanged; lor-server.cocreations.com.au keeps working alongside)
  /builder/    the Builder — admin API, own process, own database lor_builder
staging.spellgrove.com/director/   the staging game stack

The blocks and where each one lives

The local hub (tools/hub-ui/, npm run editor in game/director) already shows all five from their canonical files on one page; it is the offline mirror of what the Builder will serve.

The one exception to “the Builder serves everything”

The public world map stays the director’s /director/world-map.json. Fogging private Areas, dropping hidden portals and adding only the caller’s own home are game rules the in-game map already depends on; the Builder must not re-implement them. The Builder’s world.json is the authoring view — the full graph for a signed-in admin.

Agent kickoff is browser-side

Kris’s call (the Moment pipeline pattern): the signed-in admin pastes their task-runner API key once into the site (localStorage, never sent to the Builder) and the “Ask an agent” panel speaks MCP straight to kris.ai-task-runner.com. The Builder only serves the section’s prompt frame. No remote-code-execution credential lives on the droplet; non-admin users never see the panel.

Sequence

001 migration + domain → 002 the Builder’s read side and the hub pages → 003 sign-in → 004 publish with staging → 005 ask an agent → 006 other people’s areas. 007 is Kris’s own half-finished ask (Dirt and natural occurrence), waiting on the rest of his sentence.

Supersedes

workspace-dashboard/003 (authenticated control surface) and /004 (task kickoff) — their intent lands here as 003 and 005. server-architecture/018 (the spellgrove.com domain) — the domain is live as of 001; moving the game client’s base URL onto it is still that task.

Deliverables (2)

• #24 — The Game World on the site, and the Builder behind it (2026-09-04)
• #23 — One repo, one site — spellgrove.com (2026-09-03)

Work on this epic

The granular work is GitHub Issues, one label per epic: epic:building-the-game (private repository — sign-in required). The dated Where this stands section above names the open ones. The task files that carried this epic until 2026-09-13 are kept in the repo: task files to 2026-09-13 .

Also available as raw markdown.