bantamkit-mcp 0.34.3 → 0.35.0

package/README.md

@@ -5,7 +5,7 @@ store, JSON Schema validation and shift-work tools. Install it from **npm** with
 command, connect it to **Claude Code**, **Claude Desktop**, **Cursor** or **GitHub Copilot in VS
 Code**, and every later launch starts **offline**. No Python, `pip`, `uv`, `pipx` or venv.
 
-It serves the same twelve tools, `bantamkit_status` prompt and two resource templates as the
+It serves the same fourteen tools, `bantamkit_status` prompt and two resource templates as the
 Python server on **PyPI** (`pip install "bantamkit[mcp]"`), and reads and writes the same memory
 store. The two are compared frame by frame: 8,130 conformance cases on 2026-09-15, with every
 intentional difference written down as a ruling.
@@ -50,9 +50,9 @@ npx -y bantamkit-mcp@latest --install claude   # or claude-desktop, copilot, cur
 From 0.34.0 this runs `npm install --prefix ~/.bantamkit/mcp` once (Windows:
 `%USERPROFILE%\.bantamkit\mcp`, not measured) and records
 `<the node that ran it> ~/.bantamkit/mcp/node_modules/bantamkit-mcp/dist/cli.js`, both absolute.
-No later launch needs npx, the registry or your PATH. Measured from the published 0.34.0:
-install exit 0 in 8.14 s; the recorded command then served 12 tools in 0.09 s with the network
-cut.
+No later launch needs npx, the registry or your PATH. Measured from the published 0.34.0
+(served-tools: dated — the surface was twelve then): install exit 0 in 8.14 s; the recorded
+command then served 12 tools in 0.09 s with the network cut.
 
 - **`@latest` matters:** without it npx may reuse an older cached resolve.
 - **It skips npm when the kept install already reports this version or a newer one.** It never
@@ -235,10 +235,15 @@ startup. In Claude Code: `/mcp` → reconnect. In Claude Desktop: a full restart
 **Verify with `bantamkit_status`, not the install log.** It reports the version and the
 `build_id` of *the code that is answering you*:
 
+*(A capture from 0.30.0. The version and build-digest bytes are left as a dated transcript
+rather than hand-edited to a number nobody ran; **line 3 is the exception and tracks the
+surface**, for the reason `docs/status.md` gives — the tool count is a live claim this repo
+gates against a running server, and a marker would only hide it from that gate.)*
+
 ```
 bantamkit Active 🟢
 version 0.30.0, build sha256:4441619d…
-serving 12 tools, 1 prompt, 2 resource templates
+serving 14 tools, 1 prompt, 2 resource templates
 ```
 
 A version that moved and a `build_id` that did not means you are reading a config, not a process.

package/assets/tools/shiftwork_plan.json

@@ -0,0 +1,25 @@
+{
+  "name": "shiftwork_plan",
+  "description": "Shift-work plan: read-only batch view of a checkpoint — which units its `depends_on` graph permits to run in parallel. Answers `{\"result\": \"plan\", \"batches\", \"ready\", \"sequence\", \"width\", \"cursor\"}`: `ready` is `batches[0]`, the units dispatchable right now, and `width` is the largest batch length, the widest fan-out. Units with status `done` or `dropped` are satisfied — dropped from the graph, and edges pointing at them treated as already resolved; `todo`, `in_progress` and `blocked` stay in it. Every unit has priority 0, because the checkpoint schema has no priority field, so order inside a batch is `plan.units` order. Same refusal sentences as `work_plan` for a duplicate id, an unknown dependency or a cycle, and the same refusals `shiftwork_status` gives for a checkpoint it cannot read. It reports what the dependency graph permits; it does not move the cursor, which is echoed unchanged so the single-pointer contract and the batch view can be read side by side. An orchestrator stays responsible for what it actually dispatches: `depends_on` encodes logical order, not file contention. Never mutates.",
+  "surfaces": [
+    "mcp"
+  ],
+  "parameters": {
+    "properties": {
+      "checkpoint": {
+        "title": "Checkpoint",
+        "type": "string"
+      }
+    },
+    "required": [
+      "checkpoint"
+    ],
+    "type": "object",
+    "title": "shiftwork_planArguments"
+  },
+  "output_schema": {
+    "type": "object",
+    "additionalProperties": true,
+    "title": "shiftwork_planDictOutput"
+  }
+}

package/assets/tools/work_plan.json

@@ -0,0 +1,49 @@
+{
+  "name": "work_plan",
+  "description": "Work plan: turn a dependency graph into the batches that may run in parallel. Takes `nodes`, each `{id, depends_on, priority}` — `priority` defaults to 0 — and answers `{\"result\": \"plan\", \"batches\", \"sequence\", \"width\"}`: batch k holds every node whose dependencies all appear in batches below k, `sequence` is those batches flattened in order, and `width` is the largest batch length — the widest fan-out, which is the number an orchestrator needs to decide whether it can afford the batch. Order inside a batch is priority descending, then the order the nodes were given; both halves are contract, because determinism inside a batch is what two implementations are held to. Empty `nodes` is an ANSWER, not a refusal: no batches, no sequence, width 0. Three refusals, checked in this order and one sentence each: `duplicate node id <id>`, `node <id> depends on <dep>, which no node declares`, and `the graph has a cycle: <a> -> <b> -> <a>`. It reports what the graph permits and decides nothing about what may actually be dispatched together — `depends_on` encodes logical order, not file contention, so a batch this tool calls parallel may still hold work that writes one file. Pure computation over the nodes it was handed: it opens no file and takes no path. Never mutates.",
+  "surfaces": [
+    "mcp"
+  ],
+  "parameters": {
+    "properties": {
+      "nodes": {
+        "title": "Nodes",
+        "type": "array",
+        "items": {
+          "type": "object",
+          "properties": {
+            "id": {
+              "type": "string",
+              "description": "The node's identifier, unique across `nodes`"
+            },
+            "depends_on": {
+              "type": "array",
+              "items": {
+                "type": "string"
+              },
+              "description": "Ids this node waits for; every one of them must be declared by some node"
+            },
+            "priority": {
+              "type": "integer",
+              "description": "Tie-break inside a batch, descending. Optional; 0 when absent"
+            }
+          },
+          "required": [
+            "id",
+            "depends_on"
+          ]
+        }
+      }
+    },
+    "required": [
+      "nodes"
+    ],
+    "type": "object",
+    "title": "work_planArguments"
+  },
+  "output_schema": {
+    "type": "object",
+    "additionalProperties": true,
+    "title": "work_planDictOutput"
+  }
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "bantamkit-mcp",
-  "version": "0.34.3",
+  "version": "0.35.0",
   "description": "Memory MCP server for Claude Code, Cursor, VS Code Copilot and Claude Desktop: per-person memory, JSON Schema validation, shift-work tools. Pure Node; install once with npx, run offline.",
   "keywords": [
     "mcp",