@maka/maka-cli 5.145.0 → 5.146.0

package/bundle/typescript/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@maka/maka-cli",
-  "version": "5.145.0",
+  "version": "5.146.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-backlog-mcp.sub.cmd.js

@@ -70,9 +70,9 @@ import { UsageError } from '../../error.js';
  */
 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".
+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: backlog_advance(status: "ready-for-bench", commits: [sha]) -> backlog_draft_bench -> backlog_dry_run_bench (read the transcript it returns -- this is automated QA, not the reporter's confirmation, and needs no human) -> if the transcript demonstrates the fix, backlog_advance(status: "in-review", repro: <the same spec that just dry-ran clean>), which promotes the draft to a real bench AND notifies the reporter in one call. That is as far as automation goes: only the reporter can sign off or reject from here, in-game -- see "WHAT THIS SERVER DELIBERATELY DOES NOT EXPOSE" below for why that boundary is real and the bench-verification step is not.
 
-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.
+DO NOT PAUSE TO ASK PERMISSION for a routine step in that loop -- committing a clean, tested, single-purpose change, bumping a version, pushing, letting the release chain run, or dry-running a drafted bench. 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.
 
@@ -82,7 +82,7 @@ SWEEP THE FAMILY. If a root cause affects more than one open item (the same clam
 
 "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.
+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. NOTE THE DIFFERENCE FROM backlog_dry_run_bench: proving a bench SCRIPT replays correctly is a technical fact with no subjective side, and it needs no human -- it is not the same gate as the reporter deciding their own bug is gone, and must never be treated as though it were (that confusion cost a full stop the first time this loop ran for real).
 
 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) {
@@ -177,6 +177,7 @@ export function registerBacklogMcp(parent) {
         const { z } = await import('zod');
         const { ensureServiceSession } = await import('./sideQuest/utilities/service-account-auth.js');
         const { fetchBacklog, fetchBacklogItemById, patchBacklogItem, draftBacklogBench, postBacklogComment, BACKLOG_STATUSES, } = await import('./sideQuest/utilities/backlog.js');
+        const { dryRunRepro } = await import('./sideQuest/utilities/repro-launch.js');
         const statusEnum = BACKLOG_STATUSES;
         /** Every tool call goes through this: reuse the cached session, and
          *  on the first `expired` outcome, mint a fresh one and retry
@@ -236,29 +237,75 @@ export function registerBacklogMcp(parent) {
         }, async ({ itemId, text, kind, awaitingReporter }) => toolResult(await withSession(async (token) => ({
             outcome: await postBacklogComment(itemId, text, { kind, awaitingReporter }, token),
         }))));
+        // MIRRORS IRepro (types/repro.ts), LOOSELY. `steps` is the one field
+        // that actually matters to this tool and to `dryRunRepro` -- the
+        // server's own validateRepro is the real authority on the rest, so
+        // `fixture`'s rich nested shape (barrier/npcs/items/level/host) is
+        // passed through as an opaque object rather than re-declared here.
+        // Re-mirroring a shape this deep in a second place is exactly the
+        // kind of drift this codebase's own comments repeatedly warn about;
+        // letting the server validate it is the one copy that matters.
+        const reproSchema = z.object({
+            fixture: z.record(z.string(), z.unknown()).optional(),
+            steps: z.array(z.string()).min(1),
+            premise: z.string().optional(),
+            expect: z.string().optional(),
+            minVersion: z.string().optional(),
+            live: z.string().optional(),
+        });
         server.registerTool('backlog_advance', {
             title: 'Advance a backlog item (attach evidence / change status)',
-            description: `Move a backlog item's status and/or attach fix-commit evidence. This is the
-        actual resolution action -- it will be refused by the server (with a message explaining
-        why) if you try to enter "in-review" or "complete" without at least one commit attached,
-        or "complete" without the reporter's sign-off already on the item. This tool never signs
-        off or rejects a fix on the reporter's behalf -- only the person who filed the item can
-        do that, in-game.`,
+            description: `Move a backlog item's status, attach fix-commit evidence, and/or promote a
+        dry-run-verified bench (see backlog_dry_run_bench) from reproDraft to a real repro. This
+        is the actual resolution action -- it will be refused by the server (with a message
+        explaining why) if you try to enter "in-review" or "complete" without at least one commit
+        attached, or "complete" without the reporter's sign-off already on the item. This tool
+        never signs off or rejects a fix on the reporter's behalf -- only the person who filed the
+        item can do that, in-game.`,
             inputSchema: {
                 itemId: z.string(),
                 status: z.enum(statusEnum),
                 commits: z.array(z.string()).optional()
                     .describe('Fix-commit SHAs to attach (merged with whatever is already there).'),
+                repro: reproSchema.optional()
+                    .describe('Promote a bench to real: pass the exact spec that just dry-ran clean via backlog_dry_run_bench. Clears any pending reproDraft.'),
             },
-        }, async ({ itemId, status, commits }) => toolResult(await withSession((token) => patchBacklogItem(itemId, { status, commits }, token))));
+        }, async ({ itemId, status, commits, repro }) => toolResult(await withSession((token) => patchBacklogItem(itemId, { status, commits, repro }, token))));
         server.registerTool('backlog_draft_bench', {
             title: 'Draft an AI bench for a backlog item',
-            description: 'Ask the server to AI-draft a two-room repro bench for one item (lands in reproDraft, not repro -- a human has to dry-run and promote it separately via backlog_advance with a repro body). Costs a model call server-side.',
+            description: 'Ask the server to AI-draft a two-room repro bench for one item (lands in reproDraft, not repro -- dry-run it with backlog_dry_run_bench, then promote it with backlog_advance\'s repro param). Costs a model call server-side.',
             inputSchema: {
                 itemId: z.string(),
                 verbs: z.array(z.string()).optional().describe('The verbs available to reference in the bench steps.'),
             },
         }, async ({ itemId, verbs }) => toolResult(await withSession((token) => draftBacklogBench(itemId, token, verbs))));
+        server.registerTool('backlog_dry_run_bench', {
+            title: 'Dry-run a backlog item\'s bench, headlessly',
+            description: `Replay a backlog item's bench steps against a real boot of the game engine
+        -- no terminal, no login, no human -- and return the transcript (including dice/mechanics
+        lines). Proves the drafted bench (or an already-attached one) reproduces the reported
+        behavior BEFORE it is promoted or shown to the reporter. Prefers the item's pending
+        reproDraft; falls back to its attached repro if there is no draft. This is technical
+        verification, not the reporter's in-play confirmation -- reading the transcript and
+        judging whether it demonstrates the fix is exactly the kind of judgment call this tool
+        exists to let you make yourself.`,
+            inputSchema: { itemId: z.string() },
+        }, async ({ itemId }) => {
+            const result = await withSession((token) => fetchBacklogItemById(itemId, token));
+            if (result.outcome !== 'ok' || !result.item)
+                return toolResult(result);
+            const spec = result.item.reproDraft?.spec ?? result.item.repro;
+            if (!spec || !Array.isArray(spec.steps) || spec.steps.length === 0) {
+                return toolResult({ outcome: 'rejected', message: 'No reproDraft or repro on this item yet -- call backlog_draft_bench first.' });
+            }
+            try {
+                const { lines, warnings } = await dryRunRepro(spec);
+                return toolResult({ outcome: 'ok', transcript: lines.join('\n'), warnings });
+            }
+            catch (e) {
+                return toolResult({ outcome: 'rejected', message: `Dry run failed to boot: ${e.message}` });
+            }
+        });
         const transport = new StdioServerTransport();
         await server.connect(transport);
         console.error('[play:backlog:mcp] ready');

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@maka/maka-cli",
-  "version": "5.145.0",
+  "version": "5.146.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.",