@maka/maka-cli 5.143.1 → 5.145.0

package/bundle/typescript/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@maka/maka-cli",
-  "version": "5.143.1",
+  "version": "5.145.0",
   "type": "module",
   "summary": "A command line tool for scaffolding Meteor 3.x applications using either React.",
   "description": "A command line tool for scaffolding Meteor 3.x applications using React.",

package/bundle/typescript/src/commands/game/sideQuest/factories/scene-chunks.js

@@ -3,6 +3,7 @@ import { spreadStationedNpcs } from './npc-spread.js';
 import { Logger } from '../utilities/logger.js';
 import { catalogAugmentations } from '../utilities/catalog.js';
 import { isOutdoorsPlace } from '../utilities/outdoors.js';
+import { clampDeviceKind } from '../utilities/affordances.js';
 /**
  * CHUNKED scene generation (see SceneSeedGenerator.generate for the
  * pipeline that drives this module). One monolithic whole-scene completion
@@ -2176,10 +2177,11 @@ export function assembleScene(skeleton, details, playerName) {
             ? detail.guardsExit.toLowerCase()
             : undefined;
         const footprint = guardsExit && detail?.footprint && VALID_FOOTPRINTS.has(detail.footprint) ? detail.footprint : undefined;
-        // KIND CLAMPS, never throws. A device whose kind we cannot read is
-        // still a device, and rejecting a whole draft over one word is a
-        // worse outcome than a panel where the model meant something else.
-        const kind = device.kind === 'lock' || device.kind === 'ward' ? device.kind : 'panel';
+        // KIND CLAMPS, never throws -- see clampDeviceKind's own doc for
+        // why, and for the incident (a "tunnel grate" clamped to `panel`
+        // and rendered hack-only) that put a name/description-aware
+        // fallback here instead of a blind default to `panel`.
+        const kind = clampDeviceKind(device.kind, device.name, detail?.description ?? device.concept);
         // A CODE ONLY BELONGS ON A PANEL -- enforced here as well as in the
         // prompt, because the prompt is advice and this is not. You cannot
         // talk at a mechanical lock.

package/bundle/typescript/src/commands/game/sideQuest/factories/scene-seed-generator.js

@@ -4,6 +4,7 @@ import { AI } from '../../../../tools/ai/ai.class.js';
 import { Player } from '../models/player.js';
 import { Room } from '../models/room.js';
 import { Logger } from '../utilities/logger.js';
+import { clampDeviceKind } from '../utilities/affordances.js';
 import { GenerationCapture } from '../utilities/generation-capture.js';
 import { fetchCanonContext } from '../utilities/canon-lore.js';
 import { SceneSynthesizer } from './scene-factory.js';
@@ -681,17 +682,23 @@ export class SceneSeedGenerator {
      * This used to throw on an unrecognised bypassType. A kind we cannot
      * read is still a device, and rejecting a whole draft -- 20-40s of
      * generation -- over one misspelled word is a worse outcome than a
-     * panel where the model meant something else. assembleScene does the
-     * same clamp; this one catches a seed that reached us another way.
+     * guess where the model meant something else. assembleScene does the
+     * same clamp (via the same clampDeviceKind helper, so the two cannot
+     * drift); this one catches a seed that reached us another way.
+     *
+     * THE GUESS IS NAME/DESCRIPTION-AWARE, not a blind "panel" (fixed
+     * 2026-09-08, backlog 2uNPnc4L6jHaYEtnN / tuku6Z5XTtmNemkzd): a
+     * "tunnel grate" clamped to `panel` rendered as a hack-only "sealed
+     * SYSTEM", which is backwards for a physical mechanism.
      */
     static clampDeviceKinds(candidate) {
-        const allowed = new Set(['lock', 'panel', 'ward']);
         for (const room of candidate.rooms ?? []) {
             for (const device of room.devices ?? []) {
-                if (device.kind && !allowed.has(device.kind)) {
-                    Logger.getInstance().write(`scene-seed-generator: device "${device.name}" had kind "${device.kind}"; clamped to "panel".`);
-                    device.kind = 'panel';
+                const clamped = clampDeviceKind(device.kind, device.name, device.description);
+                if (device.kind && device.kind !== clamped) {
+                    Logger.getInstance().write(`scene-seed-generator: device "${device.name}" had kind "${device.kind}"; clamped to "${clamped}".`);
                 }
+                device.kind = clamped;
             }
         }
     }

package/bundle/typescript/src/commands/game/sideQuest/utilities/affordances.js

@@ -33,4 +33,44 @@ export const AFFORDANCE_FLAVOR = {
 export function verbsFor(kind) {
     return AFFORDANCE_FLAVOR[kind]?.verbs ?? [];
 }
+/** WARD-SOUNDING NAMES, checked first: a magical barrier is rare and
+ *  specific enough here that missing one costs less than a false
+ *  positive stealing a genuine lock from `lock`. */
+const WARD_HINTS = ['ward', 'seal', 'rune', 'glyph', 'weave', 'astral', 'spell', 'enchant', 'mystic'];
+/** PHYSICAL-MECHANISM NAMES, checked second -- the actual fix
+ *  (backlog 2uNPnc4L6jHaYEtnN / tuku6Z5XTtmNemkzd, 2026-09-08). A
+ *  device that reads as a mechanism now falls back to `lock`
+ *  (pick/breach) instead of `panel` (hack): defaulting a "tunnel
+ *  grate" to panel had the game insist a metal grate was "a sealed
+ *  SYSTEM", which is exactly backwards for a physical object. */
+const LOCK_HINTS = [
+    'grate', 'gate', 'hatch', 'grille', 'grill', 'padlock', 'deadbolt',
+    'bolt', 'latch', 'mechanism', 'portcullis', 'chain', 'valve', 'hinge',
+    'tumbler', 'maglock', 'lock', 'vault', 'safe', 'cage', 'shutter',
+    'manhole', 'trapdoor', 'hasp',
+];
+/**
+ * THE ONE KIND CLAMP, shared by both scene-chunks.ts's assembleScene and
+ * scene-seed-generator.ts's clampDeviceKinds so the fallback cannot
+ * drift between them the way a bare "default to panel" already had.
+ *
+ * NEVER THROWS -- deliberately, and for the reason both call sites'
+ * own comments already gave before this existed: a kind the model got
+ * wrong is still a device, and rejecting a whole generated scene over
+ * one word costs the player a 20-40s regeneration for a mistake this
+ * heuristic can approximate better. This only changes WHAT the
+ * fallback guesses when the raw kind isn't one of the three real
+ * ones -- from a blind `panel` to a look at the device's own name and
+ * description first.
+ */
+export function clampDeviceKind(rawKind, name, description) {
+    if (rawKind === 'lock' || rawKind === 'panel' || rawKind === 'ward')
+        return rawKind;
+    const text = `${name} ${description ?? ''}`.toLowerCase();
+    if (WARD_HINTS.some(hint => text.includes(hint)))
+        return 'ward';
+    if (LOCK_HINTS.some(hint => text.includes(hint)))
+        return 'lock';
+    return 'panel';
+}
 //# sourceMappingURL=affordances.js.map

package/bundle/typescript/src/commands/game/sideQuest-backlog-mcp.sub.cmd.js

@@ -2,6 +2,89 @@ import fs from 'fs';
 import path from 'path';
 import { Command } from '../../command.js';
 import { UsageError } from '../../error.js';
+/**
+ * `maka play:backlog:mcp` -- an MCP server exposing the game-backlog
+ * admin actions as tools, so an AI agent can drive backlog resolution
+ * directly (list items, read one, attach evidence, advance status,
+ * request an AI-drafted bench) with a human approving the consequential
+ * calls through the MCP client's own tool-permission UI.
+ *
+ * SCOPED HERE, NOT AT THE CLI'S TOP LEVEL (user ruling 2026-09-08). A
+ * command whose only job is game-backlog administration does not belong
+ * as a generic top-level command just because an unrelated, unbuilt stub
+ * (`maka ai:mcp`) already claimed that shape in .claude/mcp.json -- that
+ * stub is left alone. This lives under the feature it actually serves,
+ * registered as a CHILD of `play:backlog` (see registerBacklogMcp below
+ * and its call site in sideQuest-backlog.sub.cmd.ts).
+ *
+ * RUNS AS THE M2M SERVICE ACCOUNT, NEVER A HUMAN'S SESSION. Every tool
+ * below is a thin wrapper over the exact same REST routes
+ * game-backlog-v1-rest-api.ts already exposes to the web board and the
+ * human CLI -- so every role check, evidence gate and audit log line
+ * those routes already enforce applies here unchanged. Nothing is
+ * bypassed or reimplemented; this command only adds a way to call them.
+ *
+ * STDOUT IS THE PROTOCOL, NOT A LOG (the one hard constraint worth
+ * repeating). StdioServerTransport owns process.stdout for the MCP
+ * JSON-RPC stream once connected -- anything else written there
+ * (including Log.* from this codebase's own logger, which writes via
+ * console.log) corrupts every message after it. Diagnostics in this
+ * file go to console.error (stderr) only, and Log is not imported here
+ * at all, on purpose.
+ *
+ * SECRETS COME FROM THE MAKA-CLI.COM PROJECT'S OWN CONFIG.
+ *
+ * `--site <path>` IS THE REAL ANSWER, NOT `cwd` (corrected 2026-09-08,
+ * after `cwd` alone shipped broken). The first cut relied entirely on
+ * `this.cfg.getAppConfigPath(env)` against `process.cwd()` -- the same
+ * mechanism `maka env:get` uses -- on the theory that an MCP client's
+ * server config setting `cwd` to a maka-cli.com checkout would make
+ * that resolve correctly. It does not, at least not for a server
+ * registered in Claude Code's GLOBAL config (~/.claude.json): the
+ * process spawns with the session's own working directory regardless
+ * of a `cwd` field there, `mustBeInMakaProject` fails immediately
+ * ("No maka project config file found"), and the process exits before
+ * the MCP handshake completes -- which surfaces to the client as a
+ * bare "Connection closed", not a readable error. `--site` sidesteps
+ * the whole question of what a given MCP client's `cwd` support
+ * actually is: the checkout path is a literal argument, not inferred
+ * from where the process happened to start.
+ *
+ * `cwd` STILL WORKS AS A CONVENIENCE, for a terminal or a client that
+ * does set it correctly (a project-scoped `.claude/mcp.json`, say):
+ * omitting `--site` falls back to the original cwd-based resolution.
+ * `mustBeInMakaProject` is OFF at the framework level either way --
+ * this command does its own check so both paths get the same clear
+ * error instead of the framework's for one and a hand-rolled one for
+ * the other.
+ *
+ * AUTHZERO_SECRET never leaves this lookup either way: it is used
+ * once, in-process, to mint an Auth0 token, and is never logged or
+ * forwarded anywhere.
+ */
+/**
+ * WHAT A CONNECTING SESSION IS TOLD, surfaced at MCP connection time.
+ * This is the loop as it actually runs, corrected in-session against
+ * real friction on the first item worked through it (2026-09-08/09) --
+ * not a policy written in advance of ever using the tool.
+ */
+const MCP_SERVER_INSTRUCTIONS = `This server exposes the game-backlog admin actions as tools. Every tool is a thin wrapper over the same REST routes the human web board and CLI already use -- role checks, evidence gates, and audit logging all apply exactly as they do for a human admin. Nothing here bypasses them.
+
+THE LOOP IS NEARLY AUTOMATED BY DESIGN -- that is the whole reason this server exists instead of a human doing this work by hand. For each item: read it in full (backlog_get), find the root cause in the relevant repo (maka-cli-src for the CLI/game engine, maka-cli.com for the site/backend -- see sources-1/CLAUDE.md for which repo owns what), fix it, write/run tests, build, lint, typecheck -- then commit, version-bump (maka-cli-src releases go through the full chain: push -> build -> publish -> GitHub release + site pin -> the pin auto-deploys the site; maka-cli.com-only changes need either the next pin or a manual "gh workflow run deploy.yml"), and once the fix is committed AND actually deployed live, call backlog_advance with the commit sha(s) to move the item to "ready-for-bench".
+
+DO NOT PAUSE TO ASK PERMISSION for a routine step in that loop -- committing a clean, tested, single-purpose change, bumping a version, pushing, or letting the release chain run. That is exactly the friction this tooling was built to remove. Reserve a real stop for a production-only action with no easy rollback, or a failure that genuinely needs human judgment to interpret.
+
+DESIGN DECISIONS THAT COME UP WHILE FIXING ARE NOT A STOP EITHER. Make the call, then record the decision and its reasoning as a backlog_comment (kind: "note") on the item itself -- that comment is the durable record a later reviewer or the reporter can read; a live question to the human is the thing this loop exists to avoid. Only escalate a design question directly to the human when the choice changes externally-visible behavior in a way nobody could reconstruct from the code and the note.
+
+SR5 CANON FIDELITY IS NOT OPTIONAL for anything in the side-quest game (see maka-cli-src/CLAUDE.md, "ALWAYS FOLLOW THE SHADOWRUN RULES"): a deviation from the rules is a defect, full stop -- check the shadowrun-rag MCP tool (ask_shadowrun_rules) rather than reasoning from memory, including when this item's own vetting text claims to summarize the rules; it has been wrong before. "The excerpt didn't mention X" is not "X doesn't exist."
+
+SWEEP THE FAMILY. If a root cause affects more than one open item (the same clamp, the same missing check, the same divergent code path), fix all of them in one pass and add a backlog_comment cross-referencing the shared cause on every affected item -- fixing one twin and leaving the other broken reproduces the same report one layer down.
+
+"ready-for-bench" MEANS COMMITTED *AND* DEPLOYED, not just committed -- a bench built against undeployed code would replay the old bug and report the fix as failed. Don't advance to ready-for-bench before confirming the deploy actually succeeded.
+
+WHAT THIS SERVER DELIBERATELY DOES NOT EXPOSE, and why: signoff/reject/close are the reporter's own verbs -- only the person who hit the bug can confirm it is actually gone in play, and an AI closing its own fix would be exactly the self-certification this project's design already rejects for human admins. grant/revoke/delete/top-priority are rarer, higher-blast-radius actions left to a human directly.
+
+A "failed" vetting state means the automated vetting pipeline itself errored (no lore-search hits, or the model call failed) -- it is NOT a judgment that the item lacks merit. Treat those items as needing your own diagnosis from scratch, same as any other open item.`;
 export function registerBacklogMcp(parent) {
     return Command.create({
         name: 'mcp',
@@ -117,7 +200,16 @@ export function registerBacklogMcp(parent) {
                 isError: value.outcome !== 'ok',
             };
         }
-        const server = new McpServer({ name: 'maka-play-backlog', version: '1.0.0' });
+        // SERVER INSTRUCTIONS -- surfaced by MCP clients at connection time
+        // as priority context, which is the point: this ships the workflow
+        // WITH the tool, for whichever Claude session connects, rather than
+        // depending on one session's own accumulated memory of how this is
+        // supposed to run. Written and revised in-session (2026-09-08/09)
+        // after the first real item exposed exactly the friction it warns
+        // against -- see MCP_SERVER_INSTRUCTIONS's own history if this ever
+        // needs updating again: keep it a record of what actually went
+        // wrong, not a wishlist.
+        const server = new McpServer({ name: 'maka-play-backlog', version: '1.0.0' }, { instructions: MCP_SERVER_INSTRUCTIONS });
         server.registerTool('backlog_list', {
             title: 'List backlog items',
             description: 'List game-backlog items, optionally filtered by status. Closed (complete) items are excluded unless a status is given explicitly.',

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@maka/maka-cli",
-  "version": "5.143.1",
+  "version": "5.145.0",
   "type": "module",
   "summary": "A command line tool for scaffolding Meteor 3.x applications using either React.",
   "description": "A command line tool for scaffolding Meteor 3.x applications using React.",