run-dmcp 0.2.0 → 0.4.0

package/README.md

@@ -12,23 +12,26 @@ holds full adjudication discretion over a world that only ever stores *now*.
 
 ## Status
 
-**0.1.1 — the foundation, not the thesis.** What ships today is the predecessor's engine plus four
-pieces of generic mechanism that were built for it and offered back to it:
+**0.3.0.** The base is the predecessor's engine plus four pieces of generic mechanism that were built
+for it and offered back to it:
 
 - **Atomicity** — `withTransaction()` wired into the multi-write operations that were running
   non-atomically.
 - **Declarative constraints** — resources can be declared `bounded` or `monotonic`, and the store
-  enforces it rather than trusting every caller. (`resolve_only` — every direct write rejected, so a
-  value can move only through an adjudicating call — exists in a downstream consumer and has not been
-  extracted here yet. It arrives with the resolve protocol; see [docs/DESIGN.md](docs/DESIGN.md) §5.2a.)
+  enforces it rather than trusting every caller. `resolve_only` — every direct write rejected, so a
+  value can move only through an adjudicating call — joined them alongside the resolve protocol, and
+  is enforced by a trigger rather than by a checker anyone has to remember to call; see
+  [docs/DESIGN.md](docs/DESIGN.md) §5.2a.
 - **Conserved resource sets** — a set of resources can be declared conserved, with an atomic transfer
   that never silently clamps.
 - **On-expiry consequences** — scheduled events and timers can carry a consequence that actually
   lands when they expire, rather than expiring into nothing.
 
-0.1.1 adds the packaging half of that: importing the library starts nothing, the database resolves to
-the consuming application rather than into `node_modules`, and a consumer can bring up its own tables
-through the migration hook below.
+0.1.1 added the packaging half of that: importing the library starts nothing, the database resolves
+to the consuming application rather than into `node_modules`, and a consumer can bring up its own
+tables through the migration hook below. 0.3.0 adds the consuming half — the entity/property spine is
+exported as library functions, so a consumer that deletes its own vendored copy has something to
+import rather than a server to make tool calls into.
 
 The timeline that gives this project its reason to exist — interval-versioned facts, `replay(t)`,
 irreversibility, timeline export, `changes_within` — is built, and every write of world state appends
@@ -56,14 +59,28 @@ schema comes up, where the database lives, and whether anything listens.
 
 **The package root is the core, and the tabletop surface is a layer above it.** Dice, combat,
 abilities, status effects, random tables and quests are genuinely game-shaped — an optional
-dependency, not part of the engine (see [docs/DESIGN.md](docs/DESIGN.md) §8). A consumer that only
-needs entities, facts, events and the timeline imports `run-dmcp` and calls `createCoreMcpServer`. A
-consumer that wants the full tabletop surface imports `run-dmcp/rpg` and calls `createMcpServer` —
-same name, same options, the whole assembly this package has always served:
+dependency, not part of the engine (see [docs/DESIGN.md](docs/DESIGN.md) §8).
+
+**Mechanism and assembly are separate entries, and importing one never loads the other** (since
+0.4.0). Four specifiers, two layers by two kinds:
+
+| | mechanism — functions, constants, types | assembly — builds a server |
+|---|---|---|
+| **core** | `run-dmcp` | `run-dmcp/server` → `createCoreMcpServer` |
+| **+ tabletop** | `run-dmcp/rpg` | `run-dmcp/rpg/server` → `createMcpServer` |
+
+Assembling a server means loading the MCP SDK, twenty-one register modules and (for the full
+assembly) the web UI. Wanting `createGame` or `LIMITS` does not, and until 0.4.0 both entries
+charged for it anyway: the core entry cost 97.4ms per process cold and costs 47.0ms now, which is
+below the MCP SDK's own 55.0ms, because without the assembly it no longer loads the SDK at all.
+
+A consumer that *does* build a server loads the SDK regardless, so it saves less than that
+difference suggests — measured with the SDK warm, importing both entries, 67.4ms → 38.0ms, about
+29ms per process. The functions did not change; their specifiers did.
 
 ```ts
 import { initializeSchema, type SchemaMigration } from "run-dmcp";
-import { createMcpServer } from "run-dmcp/rpg";
+import { createMcpServer } from "run-dmcp/rpg/server";
 
 const migrations: SchemaMigration[] = [
   {
@@ -93,6 +110,27 @@ The database lands in the consuming application: `DMCP_DB_PATH` if set, else an
 `~/.local/share/dmcp`, else `./data/games.db` relative to the working directory. Never inside the
 installed package.
 
+**The spine is importable, not only callable over a transport.** Games, locations, characters,
+factions, relationships, resources, secrets, items, notes, tags, time and timers are library
+functions first and MCP tools second, so a consumer reads and writes its own world directly and only
+serves the tools it actually wants an LLM to reach. That includes the constrained-write choke point:
+a number that moves through `updateResourceValue` is checked against its declared constraints and its
+history is `facts`, queryable with `valueHistory`.
+
+```ts
+import { createGame, createResource, updateResourceValue, valueHistory } from "run-dmcp";
+
+const game = createGame({ name: "The Granary", setting: "…", style: "…" });
+const grain = createResource({ gameId: game.id, ownerType: "game", name: "grain", value: 100 });
+
+updateResourceValue({ resourceId: grain.id, mode: "delta", value: -30, reason: "the winter ration" });
+valueHistory(grain.id, "value"); // → the transitions, with the reason each one carried
+```
+
+The annotations, input limits, error envelope and logger the engine's own tools are built from are
+exported too (`ANNOTATIONS`, `LIMITS`, `errors`, `createLogger`), so a consumer's own tools can
+refuse and bound the way these do instead of re-implementing it.
+
 ## Provenance
 
 This continues [DMCP](https://github.com/shawnrushefsky/dmcp) by Shawn Rushefsky (MIT), whose last

package/dist/bin/run-dmcp.js

@@ -18,7 +18,7 @@ import { startHttpServer } from "../http/server.js";
 // (design §8, issue #17). The application always served the full surface,
 // so it reaches for it here rather than the core-only `createCoreMcpServer`
 // in ../mcp-server.js.
-import { createMcpServer } from "../rpg/index.js";
+import { createMcpServer } from "../rpg/server.js";
 import { httpPortFromEnv, setHttpPort, webUiEnabled } from "../utils/webui.js";
 import { createLogger } from "../utils/logger.js";
 const log = createLogger("bin");

package/dist/db/schema.js

@@ -3,6 +3,49 @@ import { createLogger } from "../utils/logger.js";
 import { initializeTimelineSchema } from "../timeline/schema.js";
 import { initializeAdjudicationSchema } from "../timeline/adjudication.js";
 const log = createLogger("schema");
+/**
+ * Run one whole-table CHECK rebuild with foreign-key enforcement suspended,
+ * and verify afterwards that nothing was left dangling.
+ *
+ * SQLite cannot ALTER a CHECK, so widening one means rebuilding the table:
+ * copy the rows aside, DROP, CREATE with the new CHECK, copy back. Two
+ * migrations in this file do that, and both need the same two guarantees.
+ *
+ * ENFORCEMENT MUST BE OFF ACROSS THE DROP. With it on, `DROP TABLE` performs
+ * an implicit per-row DELETE first, precisely so that any ON DELETE action
+ * declared against that table fires as though each row had genuinely been
+ * deleted -- which for both of these tables means cascade-emptying the tables
+ * that reference them. Suspending it is what makes the drop a schema
+ * operation instead of a silent mass deletion. It is toggled out here rather
+ * than inside `withTransaction`, because `PRAGMA foreign_keys` is a
+ * documented no-op while a transaction is pending.
+ *
+ * AND IT MUST GO BACK ON WHEN THE REBUILD THROWS, which is why the restore is
+ * in a `finally` and why this is a shared function rather than two copies.
+ * Both call sites previously restored it on the success path only.
+ * `getDatabase()` caches one connection at module scope, so a rebuild that
+ * threw handed the rest of the process a handle with foreign keys still
+ * disabled -- and a disabled foreign key does not announce itself. It means
+ * every ON DELETE CASCADE in this schema quietly stops working: deleting a
+ * game orphans its characters, resources, locations and secrets instead of
+ * taking them with it, and nothing errors. The scenario is not exotic -- a
+ * staging table left behind by a rebuild that died partway is exactly what
+ * makes the next startup's `CREATE TABLE ..._staging` throw. Covered by
+ * `src/db/__tests__/foreignKeysRestored.test.ts`.
+ */
+function rebuildWithForeignKeysSuspended(db, label, rebuild) {
+    db.pragma("foreign_keys = OFF");
+    try {
+        withTransaction(rebuild);
+        const violations = db.pragma("foreign_key_check");
+        if (violations.length > 0) {
+            throw new Error(`${label} CHECK migration left dangling foreign keys: ` + JSON.stringify(violations));
+        }
+    }
+    finally {
+        db.pragma("foreign_keys = ON");
+    }
+}
 export function initializeSchema(options) {
     const db = getDatabase();
     // ============================================================================
@@ -203,12 +246,22 @@ export function initializeSchema(options) {
     )
   `);
     // Resources table (for tracking currency, reputation, counters, etc.)
-    db.exec(`
+    //
+    // `RESOURCES_DDL` is a shared constant, not a literal inlined here, for the
+    // same reason `RESOURCE_CONSTRAINTS_DDL` further down is one: the CHECK-
+    // rebuild migration immediately below needs this exact text executed in
+    // TWO places -- here, for a fresh database, and again inside the rebuild,
+    // for a database that still carries the OLD two-member CHECK. Sharing one
+    // JS string is what makes "a fresh database and a migrated database
+    // converge on byte-identical `sqlite_master.sql` for this table" true BY
+    // CONSTRUCTION rather than by two hand-written literals happening to agree
+    // today.
+    const RESOURCES_DDL = `
     CREATE TABLE IF NOT EXISTS resources (
       id TEXT PRIMARY KEY,
       game_id TEXT NOT NULL,
       owner_id TEXT,
-      owner_type TEXT NOT NULL CHECK (owner_type IN ('game', 'character')),
+      owner_type TEXT NOT NULL CHECK (owner_type IN ('game', 'character', 'faction', 'location')),
       name TEXT NOT NULL,
       description TEXT,
       category TEXT,
@@ -218,7 +271,115 @@ export function initializeSchema(options) {
       created_at TEXT NOT NULL,
       FOREIGN KEY (game_id) REFERENCES games(id) ON DELETE CASCADE
     )
-  `);
+  `;
+    db.exec(RESOURCES_DDL);
+    // Migration: widen `resources.owner_type` to admit 'faction' and
+    // 'location' alongside 'game' and 'character'. A resource owned by a
+    // faction or a location is generic mechanism -- the engine already has
+    // `factions` and `locations` tables; this just lets `resources` point at
+    // either the way it already points at a `game` or a `character` -- so it
+    // belongs here rather than behind a downstream application's own migration.
+    //
+    // SQLite cannot ALTER a CHECK constraint, so a database that already has
+    // `resources` rows under the OLD two-member CHECK needs the same full-
+    // table-rebuild recipe the `resource_constraints` CHECK-widening migration
+    // uses further down this function (see that block's comment for the
+    // detailed reasoning this one leans on): build a replacement table with
+    // the new CHECK, copy every row across, drop the old table, put the
+    // replacement in its place.
+    //
+    // DETECTION IS IDEMPOTENT AND LITERAL, not a guess: read this codebase's
+    // OWN generated DDL back out of `sqlite_master` and check whether it
+    // already contains the token 'faction' -- the same "a literal check for a
+    // token we defined in output we generated is fine" carve-out the
+    // `resource_constraints` migration's own comment cites (hard rule 4 in the
+    // downstream game's own engineering standards; this engine has no
+    // narrative-language rule of its own to point at, but the reasoning is the
+    // same: this is a substring check against SQL text THIS FUNCTION generated
+    // a few lines above, never against anything a player or a model wrote). A
+    // truly fresh database never takes the branch below: `RESOURCES_DDL`'s
+    // `CREATE TABLE IF NOT EXISTS` a few lines up already carries the widened
+    // CHECK, so by the time this runs, this database's own `resources` already
+    // contains 'faction'.
+    const resourcesDdl = db
+        .prepare(`SELECT sql FROM sqlite_master WHERE type = 'table' AND name = 'resources'`)
+        .get();
+    if (resourcesDdl && !resourcesDdl.sql.includes("faction")) {
+        // DROP THE PROJECTION TRIGGERS FIRST, UNCONDITIONALLY, IF THEY EXIST.
+        // `timeline_resources_ai`/`_au`/`_ad` are defined ON `resources` itself
+        // (`AFTER INSERT/UPDATE/DELETE ON resources`), so SQLite drops them
+        // automatically the moment `DROP TABLE resources` below runs -- but
+        // dropping them here too, explicitly, costs nothing and removes any
+        // dependence on that implicit behaviour being exactly right. They are
+        // unconditionally reinstalled, generated fresh off the rebuilt table's
+        // own `pragma_table_info`, by `installProjectionTriggers()`
+        // (`src/timeline/projection.ts`), which `initializeTimelineSchema()`
+        // calls LAST in this function -- see the comment on that call for why it
+        // runs after every migration above it, this one included.
+        db.exec(`DROP TRIGGER IF EXISTS timeline_resources_ai`);
+        db.exec(`DROP TRIGGER IF EXISTS timeline_resources_au`);
+        db.exec(`DROP TRIGGER IF EXISTS timeline_resources_ad`);
+        // Enforcement has to be suspended across the drop, and put back
+        // afterwards on every path -- see `rebuildWithForeignKeysSuspended`. Here
+        // the tables that would be cascade-emptied are `resource_history` and
+        // `resource_constraint_members`, both of which declare
+        // `FOREIGN KEY (resource_id) REFERENCES resources(id) ON DELETE CASCADE`.
+        rebuildWithForeignKeysSuspended(db, "resources.owner_type", () => {
+            // 1. Copy the OLD table's rows into a staging table under a temporary
+            //    name, already carrying the widened CHECK.
+            db.exec(`
+        CREATE TABLE resources_staging (
+          id TEXT PRIMARY KEY,
+          game_id TEXT NOT NULL,
+          owner_id TEXT,
+          owner_type TEXT NOT NULL CHECK (owner_type IN ('game', 'character', 'faction', 'location')),
+          name TEXT NOT NULL,
+          description TEXT,
+          category TEXT,
+          value REAL NOT NULL DEFAULT 0,
+          min_value REAL,
+          max_value REAL,
+          created_at TEXT NOT NULL
+        )
+      `);
+            db.exec(`
+        INSERT INTO resources_staging (id, game_id, owner_id, owner_type, name, description, category, value, min_value, max_value, created_at)
+        SELECT id, game_id, owner_id, owner_type, name, description, category, value, min_value, max_value, created_at FROM resources
+      `);
+            // 2. Drop the OLD table outright -- not renamed. Renaming it out of
+            //    the way first would rewrite `resource_history` and
+            //    `resource_constraint_members`'s own stored FOREIGN KEY clauses to
+            //    point at the temporary name (RENAME TO rewrites every OTHER
+            //    table's FK text that references the renamed table, regardless of
+            //    the `foreign_keys` pragma), leaving them permanently dangling
+            //    once that temporary table is dropped a few steps later. `DROP
+            //    TABLE`, unlike `RENAME TO`, does not rewrite other tables'
+            //    references -- there is nothing to rewrite them TO -- so this
+            //    recipe never renames the table other tables' foreign keys point
+            //    at; the FINAL name is produced by a genuine `CREATE TABLE`
+            //    instead, and `resource_history`/`resource_constraint_members`'s
+            //    FK text is never touched by anything in this block.
+            db.exec(`DROP TABLE resources`);
+            // 3. Recreate under the FINAL name using the exact same DDL text the
+            //    fresh-database path executed above -- `RESOURCES_DDL` itself, not
+            //    a second hand-copied literal -- so its stored SQL matches the
+            //    fresh-database path byte for byte.
+            db.exec(RESOURCES_DDL);
+            // 4. Copy every row back across from the staging table with an
+            //    EXPLICIT column list -- never SELECT * -- and drop the staging
+            //    table. Every id was copied verbatim, so `resource_history` and
+            //    `resource_constraint_members`'s own `FOREIGN KEY (resource_id)
+            //    REFERENCES resources(id)` -- never touched by any of the steps
+            //    above -- is satisfied by the replacement table throughout,
+            //    verified for real by the `PRAGMA foreign_key_check` below, not
+            //    merely assumed here.
+            db.exec(`
+        INSERT INTO resources (id, game_id, owner_id, owner_type, name, description, category, value, min_value, max_value, created_at)
+        SELECT id, game_id, owner_id, owner_type, name, description, category, value, min_value, max_value, created_at FROM resources_staging
+      `);
+            db.exec(`DROP TABLE resources_staging`);
+        });
+    }
     // Resource history table (tracks all changes) -- FROZEN, see the trigger
     // immediately below. Kept for existing rows only; nothing writes here any
     // more.
@@ -393,15 +554,12 @@ export function initializeSchema(options) {
         // means it is unconditionally reinstalled before this function returns
         // regardless -- this is that discipline paying for itself a second time.
         db.exec(`DROP TRIGGER IF EXISTS timeline_facts_resolve_only`);
-        // PRAGMA foreign_keys is a documented no-op when toggled inside a
-        // pending transaction, so it brackets withTransaction() below rather
-        // than living inside it -- set OFF here (before BEGIN), restored ON
-        // after COMMIT. connection.ts turns it ON for every connection at
-        // open (`getDatabase()`); this block is the one place in the codebase
-        // that deliberately, temporarily, undoes that, and it is responsible
-        // for putting it back.
-        db.pragma("foreign_keys = OFF");
-        withTransaction(() => {
+        // Enforcement has to be suspended across the drop, and put back
+        // afterwards on every path -- see `rebuildWithForeignKeysSuspended`. Here
+        // the table that would be cascade-emptied is `resource_constraint_members`,
+        // which declares
+        // `FOREIGN KEY (constraint_id) REFERENCES resource_constraints(id) ON DELETE CASCADE`.
+        rebuildWithForeignKeysSuspended(db, "resource_constraints (resolve_only, issue #13)", () => {
             // EMPIRICALLY MEASURED, NOT ASSUMED (see resolveOnly.test.ts, whose
             // FK-check assertion caught a real bug in an earlier version of this
             // block): `ALTER TABLE ... RENAME TO` does not just rename the table
@@ -501,12 +659,6 @@ export function initializeSchema(options) {
             //    below, not merely assumed here.
             db.exec(`DROP TABLE resource_constraints_staging`);
         });
-        const fkViolations = db.pragma("foreign_key_check");
-        if (fkViolations.length > 0) {
-            throw new Error(`resource_constraints CHECK migration (resolve_only, issue #13) left dangling foreign keys: ` +
-                JSON.stringify(fkViolations));
-        }
-        db.pragma("foreign_keys = ON");
     }
     // Members of a resource constraint. 'bounded' and 'monotonic' constraints
     // have exactly one member (the resource they govern); 'conserved'

package/dist/http/server.js

@@ -583,7 +583,28 @@ export function createHttpServer(_port = 3456) {
                 next();
                 return;
             }
-            res.sendFile(join(CLIENT_DIST, "index.html"));
+            // `dotfiles: "allow"` is load-bearing, and its absence was a real bug.
+            //
+            // res.sendFile() with no `root` option hands the WHOLE absolute path to
+            // `send`, whose `dotfiles` default is "ignore" -- so if ANY segment of
+            // the path this package is installed under begins with a dot, `send`
+            // refuses the file with NotFoundError and the error handler below turns
+            // that into a 500. Every client-side route breaks at once, while `/`
+            // keeps working (it is served by express.static above, which only
+            // dotfile-checks the REQUEST path, not its own root). That is a
+            // spectacularly confusing failure: the app is fine, the file is there,
+            // and the deep link 500s because of where the checkout happens to live.
+            //
+            // Installing under a dot directory is ordinary -- a worktree beneath
+            // `.claude/`, a deploy under `~/.local/share`, a CI checkout in a dotted
+            // cache path -- so this is not a hypothetical.
+            //
+            // Safe, because the dotfiles guard is protecting nothing here: this path
+            // is a server-controlled constant (CLIENT_DIST plus a literal file name)
+            // and no part of it comes from the request. The guard exists to stop a
+            // user-supplied path from reaching `.env` or `.git`; there is no
+            // user-supplied path in it.
+            res.sendFile(join(CLIENT_DIST, "index.html"), { dotfiles: "allow" });
         });
     }
     else {

package/dist/index.d.ts

@@ -1,4 +1,3 @@
-export { createCoreMcpServer, SERVER_NAME, SERVER_VERSION } from "./mcp-server.js";
 export { getDatabase, closeDatabase, withTransaction, getDatabasePath, getDataDir, resolveDataPathFrom, } from "./db/connection.js";
 export type { DataPathInputs } from "./db/connection.js";
 export { initializeSchema } from "./db/schema.js";
@@ -32,5 +31,38 @@ export { exportTimeline, importTimeline, exportTimelineToFile, importTimelineFro
 export type { TimelineExport, TimelineExportEntity, TimelineExportFact, TimelineExportEvent, TimelineExportClock, TimelineImportResult, } from "./timeline/export.js";
 export { ENTITY_KINDS } from "./timeline/kinds.js";
 export type { EntityKind } from "./timeline/kinds.js";
-export { DEFAULT_HTTP_PORT, httpPortFromEnv, webUiEnabled, setHttpPort, getWebUiBaseUrl, } from "./utils/webui.js";
+export { DEFAULT_HTTP_PORT, httpPortFromEnv, webUiEnabled, setHttpPort, getWebUiBaseUrl, getGameUrl, getCharacterUrl, getLocationUrl, } from "./utils/webui.js";
+export * from "./tools/game.js";
+export * from "./tools/world.js";
+export * from "./tools/character.js";
+export * from "./tools/faction.js";
+export * from "./tools/relationship.js";
+export * from "./tools/resource.js";
+export * from "./tools/constraint.js";
+export * from "./tools/inventory.js";
+export * from "./tools/secrets.js";
+export * from "./tools/narrative.js";
+export * from "./tools/notes.js";
+export * from "./tools/tags.js";
+export * from "./tools/time.js";
+export * from "./tools/timers.js";
+export * from "./tools/rules.js";
+export * from "./tools/pause.js";
+export * from "./tools/display.js";
+export * from "./tools/images.js";
+export * from "./tools/audio.js";
+export * from "./tools/image-prompt.js";
+export { gameEvents } from "./events/emitter.js";
+export type { GameEvent } from "./events/emitter.js";
+export { ANNOTATIONS, withAnnotations } from "./utils/tool-annotations.js";
+export { LIMITS, validatedSchemas, boundedString, boundedArray } from "./utils/validation.js";
+export { createError, formatErrorResponse, errors } from "./utils/errors.js";
+export type { AgentError } from "./utils/errors.js";
+export { createLogger } from "./utils/logger.js";
+export type { Logger } from "./utils/logger.js";
+export { verbositySchema, applyVerbosity, filterFields } from "./utils/verbosity.js";
+export type { VerbosityLevel } from "./utils/verbosity.js";
+export { safeJsonParse, safeJsonParseOrNull } from "./utils/json.js";
+export { successResponseSchema, textResultSchema, deletedResponseSchema, listResponseSchema, characterOutputSchema, characterStatusSchema, conditionModifyOutputSchema, tagModifyOutputSchema, } from "./utils/output-schemas.js";
+export { imageGenSchema, voiceSchema } from "./schemas/index.js";
 export type * from "./types/index.js";

package/dist/index.js

@@ -26,7 +26,13 @@
 // depending up into it. `src/__tests__/layerBoundary.test.ts` walks the
 // static import graph from this file and fails if anything under `src/rpg/`
 // is reachable from it.
-export { createCoreMcpServer, SERVER_NAME, SERVER_VERSION } from "./mcp-server.js";
+// The assembled core server is NOT here. It moved to "run-dmcp/server"
+// (src/server.ts) so that importing mechanism stops loading it: building a
+// server costs the MCP SDK and twenty-one register modules, and a consumer
+// reaching for `LIMITS` or `createGame` was paying for both -- 97.4ms per
+// process against 46.8ms without it, cold, at 0.3.0. Enforced by
+// src/__tests__/assemblyBoundary.test.ts, which walks this file's runtime
+// import graph and fails if the assembly is reachable from it again.
 // The database, and where it lives. The path resolves against the consuming
 // application (DMCP_DB_PATH, else an existing XDG data directory, else the
 // working directory) and never against this package's install location.
@@ -181,4 +187,82 @@ export { ENTITY_KINDS } from "./timeline/kinds.js";
 // ability and combat tools and is exported from "run-dmcp/rpg" instead
 // (src/rpg/index.ts), even though the file that implements it stays at
 // src/http/server.ts on disk.
-export { DEFAULT_HTTP_PORT, httpPortFromEnv, webUiEnabled, setHttpPort, getWebUiBaseUrl, } from "./utils/webui.js";
+export { DEFAULT_HTTP_PORT, httpPortFromEnv, webUiEnabled, setHttpPort, getWebUiBaseUrl, getGameUrl, getCharacterUrl, getLocationUrl, } from "./utils/webui.js";
+// ===========================================================================
+// The core's own tool modules, as library functions (design §8, §11 Phase 5).
+//
+// §8's layer table puts factions, relationships-with-history, secrets,
+// resources, locations and items in the CORE, and gives the reason: they are
+// "the client's spine. If these go up into the RPG layer, the client cannot
+// consume the package without dragging the RPG layer with it -- which defeats
+// the split." That reason is only satisfied if a consumer can actually IMPORT
+// them. Until this block, it could not: everything above is the timeline and
+// the database, and the only door to the spine was `createCoreMcpServer` --
+// the whole assembled server, which a consumer would then have to make tool
+// calls into, over a transport, to read its own tables.
+//
+// The layer ABOVE this one already got it right. src/rpg/index.ts ends with
+// six export-stars over its own tool modules, under a comment saying it is
+// using "the same shape core's index.ts uses for the timeline... a consumer
+// that wants to call combat/quest/table/status/ability/dice logic directly,
+// without going through an MCP tool call, can." The core never did
+//
+// (Those six are named here in prose rather than quoted as import lines on
+// purpose: layerBoundary.test.ts walks this file's import graph with a
+// deliberately syntactic scan for `from "<specifier>"`, and it cannot tell a
+// quoted example in a comment from a real edge. That is the guard being
+// conservative rather than clever, which is the right trade -- it fails loud
+// and names the chain. Do not teach it to strip comments; reword instead.)
+// the same for its own tools, which left the OPTIONAL layer more consumable
+// than the thing it is optional on top of. That is an oversight and not a
+// decision: §6's rule is "library functions first, MCP tools second", and the
+// narration-constraint and timeline-export blocks above both invoke it.
+//
+// This changes no behaviour and adds no dependency. Every module below is
+// ALREADY in this file's static import graph, reached through
+// ./mcp-server.js -> ./register/* -> ./tools/*, so src/__tests__/
+// layerBoundary.test.ts walks exactly the same file set before and after --
+// nothing under src/rpg/ becomes reachable, and none of the six tool modules
+// that moved up there is named here.
+export * from "./tools/game.js";
+export * from "./tools/world.js";
+export * from "./tools/character.js";
+export * from "./tools/faction.js";
+export * from "./tools/relationship.js";
+export * from "./tools/resource.js";
+export * from "./tools/constraint.js";
+export * from "./tools/inventory.js";
+export * from "./tools/secrets.js";
+export * from "./tools/narrative.js";
+export * from "./tools/notes.js";
+export * from "./tools/tags.js";
+export * from "./tools/time.js";
+export * from "./tools/timers.js";
+export * from "./tools/rules.js";
+export * from "./tools/pause.js";
+export * from "./tools/display.js";
+export * from "./tools/images.js";
+export * from "./tools/audio.js";
+export * from "./tools/image-prompt.js";
+// The event emitter the tool modules above write to. A consumer's own write
+// paths emit through the same singleton, so its tables and the engine's reach
+// one SSE subscriber rather than two competing ones.
+export { gameEvents } from "./events/emitter.js";
+// ===========================================================================
+// What a consumer needs to register tools OF ITS OWN onto the core server.
+//
+// A client keeps its own MCP surface -- that is the whole point of the split;
+// its mechanics are its own and the engine never learns their names. But a
+// tool it registers should refuse, bound and annotate the way the engine's do,
+// and today a client re-implements these or copies them and lets the copy
+// drift. Named one by one rather than star-exported: these modules contain
+// identifiers like `CREATE` and `UPDATE` that have no business in a package's
+// root namespace.
+export { ANNOTATIONS, withAnnotations } from "./utils/tool-annotations.js";
+export { LIMITS, validatedSchemas, boundedString, boundedArray } from "./utils/validation.js";
+export { createError, formatErrorResponse, errors } from "./utils/errors.js";
+export { createLogger } from "./utils/logger.js";
+export { verbositySchema, applyVerbosity, filterFields } from "./utils/verbosity.js";
+export { safeJsonParse, safeJsonParseOrNull } from "./utils/json.js";
+export { successResponseSchema, textResultSchema, deletedResponseSchema, listResponseSchema, characterOutputSchema, characterStatusSchema, conditionModifyOutputSchema, tagModifyOutputSchema, } from "./utils/output-schemas.js";
+export { imageGenSchema, voiceSchema } from "./schemas/index.js";

package/dist/mcp-server.d.ts

@@ -2,7 +2,7 @@ import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
 import { type Mechanic } from "./timeline/resolve.js";
 import { type RenderVocabulary } from "./timeline/render.js";
 export declare const SERVER_NAME = "dmcp";
-export declare const SERVER_VERSION = "0.2.0";
+export declare const SERVER_VERSION = "0.3.0";
 /**
  * Build an MCP server with every CORE tool, resource and prompt this engine
  * serves -- entities, facts, events, the timeline, and the entity/property

package/dist/mcp-server.js

@@ -41,7 +41,7 @@ import { registerRenderTools } from "./register/render.js";
 import { createResolver } from "./timeline/resolve.js";
 import { createStateRenderer } from "./timeline/render.js";
 export const SERVER_NAME = "dmcp";
-export const SERVER_VERSION = "0.2.0";
+export const SERVER_VERSION = "0.3.0";
 /**
  * Build an MCP server with every CORE tool, resource and prompt this engine
  * serves -- entities, facts, events, the timeline, and the entity/property

package/dist/register/resources.js

@@ -9,7 +9,7 @@ export function registerResourceTools(server) {
         description: "Create a new resource (currency, reputation, counter, etc.)",
         inputSchema: {
             gameId: z.string().max(100).describe("The game ID"),
-            ownerType: z.enum(["game", "character"]).describe("Owner type: 'game' for party/global resources, 'character' for personal resources"),
+            ownerType: z.enum(["game", "character", "faction", "location"]).describe("Owner type: 'game' for party/global resources, 'character' for personal resources, 'faction' or 'location' for resources owned by one of those entities"),
             ownerId: z.string().max(100).optional().describe("Character ID if ownerType is 'character' (omit for game-level resources)"),
             name: z.string().min(1).max(LIMITS.NAME_MAX).describe("Resource name (e.g., 'Gold', 'Sanity', 'Thieves Guild Reputation')"),
             description: z.string().max(LIMITS.DESCRIPTION_MAX).optional().describe("Resource description"),
@@ -105,7 +105,7 @@ export function registerResourceTools(server) {
         description: "List resources in a game",
         inputSchema: {
             gameId: z.string().max(100).describe("The game ID"),
-            ownerType: z.enum(["game", "character"]).optional().describe("Filter by owner type"),
+            ownerType: z.enum(["game", "character", "faction", "location"]).optional().describe("Filter by owner type"),
             ownerId: z.string().max(100).optional().describe("Filter by owner ID (for character resources)"),
             category: z.string().max(100).optional().describe("Filter by category"),
         },

package/dist/rpg/index.d.ts

@@ -1,26 +1,10 @@
 import type { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
-import type { Mechanic } from "../timeline/resolve.js";
-import type { RenderVocabulary } from "../timeline/render.js";
 /**
  * Register every RPG-layer tool, resource and prompt onto an existing
  * server. Combat brings dice with it (registerCombatTools registers both,
  * matching how the pre-split assembly registered them as one domain).
  */
 export declare function registerRpgTools(server: McpServer): void;
-/**
- * Build the FULL assembly: every core tool plus every RPG tool, resource and
- * prompt this engine has always served. Same name, same `{ mechanics?,
- * vocabulary? }` options as the pre-split `createMcpServer` in
- * src/mcp-server.ts -- this is that function, now composed from two layers
- * instead of one, so src/bin/run-dmcp.ts's zero-argument call site keeps
- * working unchanged and the registered tool/resource/prompt set is
- * unchanged too (src/__tests__/layerBoundary.test.ts asserts this exactly).
- */
-export declare function createMcpServer(options?: {
-    mechanics?: readonly Mechanic[];
-    vocabulary?: RenderVocabulary;
-}): McpServer;
-export { createHttpServer, startHttpServer } from "../http/server.js";
 export * from "./tools/dice.js";
 export * from "./tools/combat.js";
 export * from "./tools/ability.js";

package/dist/rpg/index.js

@@ -1,4 +1,3 @@
-import { createCoreMcpServer } from "../mcp-server.js";
 import { registerCombatTools } from "./register/combat.js";
 import { registerAbilityTools } from "./register/abilities.js";
 import { registerStatusTools } from "./register/status.js";
@@ -22,27 +21,10 @@ export function registerRpgTools(server) {
     registerRpgMcpResources(server); // game-quests, quest
     registerMcpPrompts(server); // Reusable prompt templates (game-master session library)
 }
-/**
- * Build the FULL assembly: every core tool plus every RPG tool, resource and
- * prompt this engine has always served. Same name, same `{ mechanics?,
- * vocabulary? }` options as the pre-split `createMcpServer` in
- * src/mcp-server.ts -- this is that function, now composed from two layers
- * instead of one, so src/bin/run-dmcp.ts's zero-argument call site keeps
- * working unchanged and the registered tool/resource/prompt set is
- * unchanged too (src/__tests__/layerBoundary.test.ts asserts this exactly).
- */
-export function createMcpServer(options) {
-    const server = createCoreMcpServer(options);
-    registerRpgTools(server);
-    return server;
-}
-// The web UI. An application opts into serving it; importing this never
-// does. It lives on disk at src/http/server.ts, not under src/rpg/ -- it
-// imports RPG tools (quest/ability/combat), which is why it cannot be
-// reachable from the core entry point, but its CLIENT_DIST path resolution
-// is depth-sensitive in both src/ and compiled dist/, so it stays put and
-// only its EXPORT moves up to this layer.
-export { createHttpServer, startHttpServer } from "../http/server.js";
+// `createMcpServer` and the web UI are NOT here. Both are assembly, and both
+// moved to "run-dmcp/rpg/server" (src/rpg/server.ts) so that importing the
+// layer's tool functions stops loading a server and an HTTP framework with
+// them.
 // The RPG tool modules, exported as library functions -- the same shape
 // core's index.ts uses for the timeline (replay, changesWithin, and so on):
 // a consumer that wants to call combat/quest/table/status/ability/dice logic

package/dist/rpg/server.d.ts

@@ -0,0 +1,16 @@
+import type { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
+import type { Mechanic } from "../timeline/resolve.js";
+import type { RenderVocabulary } from "../timeline/render.js";
+/**
+ * Build the FULL assembly: every core tool plus every RPG tool, resource and
+ * prompt this engine has always served. Same name and same `{ mechanics?,
+ * vocabulary? }` options as the pre-split `createMcpServer` in
+ * src/mcp-server.ts, so src/bin/run-dmcp.ts's zero-argument call site keeps
+ * working unchanged and the registered tool/resource/prompt set is unchanged
+ * too (src/__tests__/layerBoundary.test.ts asserts this exactly).
+ */
+export declare function createMcpServer(options?: {
+    mechanics?: readonly Mechanic[];
+    vocabulary?: RenderVocabulary;
+}): McpServer;
+export { createHttpServer, startHttpServer } from "../http/server.js";