@battlegrid/mcp-server 31.2.64 → 31.2.66

package/README.md

@@ -24,6 +24,91 @@ Seeing package `31.x` alongside handshake `battlegrid@33.x` — the package **be
 
 **What this changes for you:** nothing about how you call anything. Upgrading the package no longer waits on a server deploy, and a server deploy no longer strands you on a package that names the wrong contract — reconnect and the announcement follows. **Contract breaking-change notes are no longer keyed to package versions**, since a contract move is no longer a release here; the v11-and-earlier notes below are kept as history, and the live vocabulary is always discovery.
 
+## Contract history — v85 (agents and strategies change only through their drafts)
+
+**Breaking at v85: seven tools are retired, and a surviving tool refuses an input it accepted at v84.**
+v85 is the contract on top of v84.
+
+Every agent and strategy is now created and changed the same way: stage the change into the
+entity's draft, read the draft back with its diff, diagnostics and impact, and commit exactly the
+draft version and the live revision that read returned.
+
+### Removed tools
+
+- **`compile_strategy_plan`, `stage_strategy_plan`, `apply_strategy_plan`, `update_strategy_signal_rule`,
+  `create_intelligence_agent`, `update_intelligence_agent`, `rebind_intelligence_agent`** are gone, with
+  no alias; a call gets an unknown-tool error. The replacements: `get_strategy_draft` →
+  `stage_strategy_draft` → `commit_strategy_draft` for a strategy (a signal rule is a row of the draft's
+  `SIGNAL_RULES` axis), and `stage_agent_draft` → `get_agent_draft` → `commit_agent_draft` for an agent
+  (a rebind is the draft's `STRATEGY_BINDING` axis).
+
+### Added tools
+
+- **`stage_strategy_draft { strategyId?, draftVersion, axes }`**, **`commit_strategy_draft`** and
+  **`commit_agent_draft`** (`{ <id>, draftVersion, expectedRevision }`, `expectedRevision` null for a
+  create). A commit publishes exactly the draft version and the live revision the caller read, is
+  idempotent on `{ id, draftVersion }`, and returns the kind's committer response plus the draft's
+  `draftVersion` after its clear (null when the commit emptied it).
+
+### Rejected input
+
+- **`archive_strategy` no longer takes `confirm`.** A request carrying it is refused with the
+  unknown-key error — a break on a surviving tool.
+- **`discard_agent_draft` and `discard_strategy_draft` take `draftVersion`** (the version
+  `get_<kind>_draft` returned) in place of `confirm`; `confirm` is refused as an unknown key, and a
+  version the draft moved past is refused `DRAFT_VERSION_MOVED`.
+- **`preview_strategy_report` takes `{ coinSelection, source }`.** The report fields move under
+  `source: { kind: 'FIELDS', … }`, and `source: { kind: 'DRAFT', strategyId, draftVersion }` previews the
+  owner's draft as a commit would compose it. A body with the fields at the top level is refused.
+- **A strategy's ENTRY axis is a union discriminated by `trigger`**: `{ trigger: 'ON_CANDLE_CLOSE' }`
+  alone, or a level trigger with `levelOffsetAtrMultiple` and `validForBars`. `ON_CANDLE_CLOSE` naming
+  either dial is refused, which the retired compile accepted; the server stamps the seed values.
+
+### Widened input
+
+- **`stage_agent_draft` accepts `STRATEGY_BINDING` on an edit draft**, where v84 refused it: a staged
+  binding commits as the agent's rebind. Its TRADING_CONFIG axis now describes each size preset as the
+  risk budget lost at the hard stop.
+
+### Reshaped output
+
+- **`fork_strategy` returns `{ strategyId, draftVersion }`** — the create draft it wrote, holding a copy
+  of the source — in place of `{ strategy }`. No strategy exists until that draft commits.
+- **`get_agent_draft` and `get_strategy_draft` gain `draftVersion`** (0 when no draft is held, beside a
+  null `draft`), **`committedRevision`, a per-axis `diff` against live, `diagnostics` and `impact`.**
+- **`stage_agent_draft` gains `diagnostics`**, the composed draft's errors and warnings.
+- **`discard_agent_draft` and `discard_strategy_draft` return `discarded: true` only**; a discard that
+  finds nothing is refused rather than answered `false`.
+
+### Widened enum
+
+- **Strategy draft axes gain `ORIGIN`**, the create-only axis a fork writes, on `list_strategy_drafts`
+  and every strategy draft read. A client switching exhaustively on a strategy draft axis must add the
+  branch.
+- **Error codes gain `DRAFT_VERSION_MOVED`** (details `draftVersion`, null when no draft is held) **and
+  `DRAFT_AXIS_CONTESTED`** (details `contestedAxes` and `draftVersion`), both 409.
+- **Refusal details gain `nextAct`.** Every draft-specific refusal, the revision `CONFLICT` and the
+  in-flight commit refusal carry `nextAct: 'get_draft'`; a commit's validation refusal carries
+  `nextAct: 'stage'`; every other refusal carries none. `details.expectedRevision` widens to
+  `number | null`.
+
+### Removed error code
+
+- **`PLAN_APPROVAL_NOT_FOUND`**, with the plan path that raised it.
+
+### Behaviour behind unchanged schemas
+
+- **`archive_strategy` and `restore_strategy` no longer refuse around the owner's unsaved draft**: they
+  re-base it onto the revision they write. `restore_strategy`'s description drops the compile route — a
+  repair is staged into the draft and committed, which restores the strategy.
+- **The `author-strategy` prompt** reads "Discover, stage, review, and commit a BattleGrid strategy
+  through its draft".
+- **The server's manifest records a description hash per tool** (manifest format 4), and the tool count
+  moves 142 → 138.
+
+A strict client that rejects unknown keys fails to parse `fork_strategy` and the draft reads at v85;
+list the tools again after the server deploys.
+
 ## Contract history — v84 (the hold moves from the condition to each clause and group)
 
 **Breaking at v84: a condition body accepted at v83 is refused, and condition evidence is reshaped.**
@@ -2077,8 +2162,8 @@ Retained for authors upgrading from 4.x. Everything below still describes the cu
 
 The v3 authoring contract below is unchanged and still current:
 
-- **Strict authoring envelopes.** `get_strategy_section_template`, `update_strategy_signal_rule`, `compile_strategy_plan`, and `apply_strategy_plan` publish one strict server-owned object, `{ request: canonicalPayload }`. In multi-account mode the proxy adds `account` **only** as a sibling of `request`, producing exactly `{ account, request }`; on a call it strips only `account` and forwards the unchanged `{ request }`. It never descends into, flattens, or reconstructs the nested request.
-- **`create_strategy` is retired.** Direct strategy creation no longer exists. Author strategies with the compile → review → apply workflow below, and bind them to agents at agent-creation time (`create_intelligence_agent({ …, strategyId })`). There is no alias, shim, or flat-payload fallback.
+- **Strict authoring envelopes.** `get_strategy_section_template` and every draft lifecycle tool (`stage_<kind>_draft`, `get_<kind>_draft`, `commit_<kind>_draft`, `discard_<kind>_draft`, `list_<kind>_drafts`) publish one strict server-owned object, `{ request: canonicalPayload }`. In multi-account mode the proxy adds `account` **only** as a sibling of `request`, producing exactly `{ account, request }`; on a call it strips only `account` and forwards the unchanged `{ request }`. It never descends into, flattens, or reconstructs the nested request.
+- **`create_strategy` is retired.** Direct strategy creation no longer exists. Author strategies through the strategy draft lifecycle below, and bind an agent to one through its draft's `STRATEGY_BINDING` axis. There is no alias, shim, or flat-payload fallback.
 - **Rediscover after deployment.** Publishing the package does **not** refresh a running proxy's cached capability snapshot. After the server cutover, restart/reconnect the proxy process and re-run `tools/list`, `prompts/list`, and `resources/list`.
 
 > Earlier majors: **v1.x** single/multi-account stdio proxy; **v2.0.0** moved the default `BATTLEGRID_API_URL` to the `/mcp` suffix; **v3.0.0** the strategy-authoring major; **v4.0.0** made `conditions` and `conditionVerdicts` required on the apply post-state; **v5.0.0** fused the conditions/verdicts split (section above). **v6.0.0** through **v11.0.0** were never published as separate package versions — they are absorbed by the v11 cutover at the top. See [Rediscovery & versioning](#rediscovery--versioning).
@@ -2250,7 +2335,7 @@ For the strict authoring tools, the multi-account input is exactly `{ account, r
 
 ```json
 {
-  "name": "compile_strategy_plan",
+  "name": "commit_strategy_draft",
   "inputSchema": {
     "type": "object",
     "properties": {
@@ -2260,11 +2345,14 @@ For the strict authoring tools, the multi-account input is exactly `{ account, r
         "description": "Which BattleGrid account to use for this action"
       },
       "request": {
-        "oneOf": [
-          { "properties": { "operation": { "const": "CREATE" } } },
-          { "properties": { "operation": { "const": "UPDATE" } } },
-          { "properties": { "operation": { "const": "RESTORE" } } }
-        ]
+        "type": "object",
+        "properties": {
+          "strategyId": { "type": "string", "format": "uuid" },
+          "draftVersion": { "type": "integer", "minimum": 1 },
+          "expectedRevision": { "anyOf": [{ "type": "integer", "minimum": 1 }, { "type": "null" }] }
+        },
+        "required": ["strategyId", "draftVersion", "expectedRevision"],
+        "additionalProperties": false
       }
     },
     "required": ["account", "request"],
@@ -2287,24 +2375,19 @@ Each account supports one active key at a time. Generating a new key automatical
 
 For paid games and autonomous wagering, enable **Server-Signed Wagers** in the MCP tab (`mcp:wager` scope). Strategy discovery and non-financial configuration writes only need `mcp:read`.
 
-## Strategy authoring (compile → review → apply)
+## Strategy and agent authoring (stage → read → commit)
 
-Strategies are authored through one strict, whole-plan workflow. **Compilation changes no strategy, agent or revision; `apply_strategy_plan` is the only write to the strategy itself** — but compile is not read-only either: it parks the plan its own apply reads, and each call mints a distinct record and token, so compile once per reviewed payload and never retry or parallelise it. Always review the exact returned plan before confirming.
+Strategies and intelligence agents change only through their drafts, with one tool family per kind (`<kind>` is `strategy` or `agent`): `stage_<kind>_draft`, `get_<kind>_draft`, `commit_<kind>_draft`, `discard_<kind>_draft` and `list_<kind>_drafts`. **A stage writes the player's unsaved draft and commits nothing; `commit_<kind>_draft` is the only write to the entity itself**, and it publishes exactly the draft the caller read.
 
-1. **Choose the operation and revision.** `list_strategies` (add `includeInactive:true` when preparing a RESTORE) and `get_strategy` return the current `revision`; thread it into the next revisioned call.
+1. **Choose the entity.** `list_strategies` (add `includeInactive:true` when repairing an archived strategy) and `get_strategy`, or `list_intelligence_agents` and `get_intelligence_agent`. `fork_strategy({ strategyId, sourceRevision })` copies a visible revision into a new create draft and returns its `strategyId` and `draftVersion`; it creates nothing.
 2. **Discover the report vocabulary live.** Walk `list_strategy_categories` → `list_strategy_vocabulary` → `get_metric_construction_hints` → `get_strategy_column_contract`, and use `get_strategy_section_template` / `preview_strategy_report`. Do not guess metric, transform, parameter, template, or enabled-timeframe facts — they are server-discovered.
-3. **Compile one complete plan.** Call `compile_strategy_plan({ request })` where the nested request is exactly one strict branch plus a bounded `coinSelection`, `intentSummary`, and `assumptions`:
-   - **CREATE** supplies the full new strategy.
-   - **UPDATE** supplies at least one changed axis and `expectedRevision`.
-   - **RESTORE** targets an owned inactive revision (with any repair axes).
-4. **Review before confirming.** Inspect the returned `approvedPlan` (complete post-state, proposed revision, diff, bound-agent impact, expiry) and `reviewContext` (column contracts, point-in-time report preview, open positions, quota/name admission). The plan token expires after five minutes; recompile after expiry or drift.
-5. **Apply the plan the server already holds.** After explicit user approval, call `apply_strategy_plan({ request: { planToken, confirm: true } })`. **There is no `plan` member** — one is rejected as an unknown key. The server keeps the plan its own compile approved and reads it back, so nothing is copied out of the compile response and nothing can be mistyped or truncated in transit. Forward `planToken` byte-for-byte exactly as received: it is an opaque signed value, never retyped, paraphrased or rebuilt from memory, and a mangled one addresses no approved plan and is refused. `PLAN_APPROVAL_NOT_FOUND` means no approved plan answers to this token — already applied, lapsed, or never issued — and the recovery is to compile again; so is `TOKEN_EXPIRED` once the five minutes run out. Any other refusal (quota, name collision, a bound agent that changed, a moved catalog) **leaves the plan applicable**: clear the cause and confirm again with the same token while it lives. Changed configuration propagates to every bound agent immediately.
-
-   The authored axes — including normalized `sections` and `conditions`, each condition carrying its own required, nullable `verdict` — belong on the **compile** request. Every derived field (`diff`, `viability`, `mismatches`, `signalRules`, `creationSeed`, `proposedRevision`, `bindingImpact`, `authoringCatalogDigest`, `reviewContext`) is re-derived server-side and rejected as an unknown key if resubmitted, and `conditionVerdicts` is rejected with a message naming its replacement — the verdict belongs on the condition.
+3. **Read the draft.** `get_<kind>_draft({ request: { <id> } })` returns the draft (or `null`), its `draftVersion` (0 when none is held), the live `committedRevision` (null for an entity not created yet), a per-axis `diff` against live, `diagnostics` and `impact`.
+4. **Stage the change.** `stage_<kind>_draft({ request: { <id>?, draftVersion, axes } })` names the version you read. Each axis is whole, except a strategy's `SIGNAL_RULES`, whose rows replace the drafted rows for the same signals and keep every other one. Omit the id to open a new create draft; the response carries the minted id. A stage that has written never refuses: the composed draft's errors and warnings come back as `diagnostics`. It is refused only when the version is one the draft never reached (`DRAFT_VERSION_MOVED`) or when the player's own form changed an axis you are staging after that version (`DRAFT_AXIS_CONTESTED`, naming `contestedAxes`).
+5. **Review with the player, then commit.** Read the draft again, show the player its diff and impact, and on their explicit word call `commit_<kind>_draft({ request: { <id>, draftVersion, expectedRevision } })` with exactly the two numbers that read returned — `expectedRevision: null` creates the entity at revision 1. A draft that moved is refused `DRAFT_VERSION_MOVED`, a moved revision `CONFLICT`, and an invalid draft with the same code its diagnostics carried; nothing is written. Each refusal's `details.nextAct` says what to do next (`get_draft` or `stage`). The commit is idempotent on `{ id, draftVersion }`: a retried commit replays its outcome. Changed strategy configuration propagates to every bound agent immediately; committing a draft of an archived strategy restores it.
 
-`update_strategy_signal_rule({ request })` is the thin, focused one-rule edit. In multi-account mode every one of these calls uses the `{ account, request }` sibling envelope.
+`discard_<kind>_draft({ request: { <id>, draftVersion } })` removes the draft at the version you read and never one that moved since. `preview_strategy_report({ coinSelection, source: { kind: 'DRAFT', strategyId, draftVersion } })` previews a draft as a commit would compose it. In multi-account mode the lifecycle tools use the `{ account, request }` sibling envelope; `preview_strategy_report` keeps its own flat input and takes `account` beside `coinSelection` and `source`.
 
-**Strategy-bound agents.** Bind a strategy to an intelligence agent at creation time — `create_intelligence_agent({ …, strategyId })` (discover `strategyId` via `list_strategies`). Rebinding via `update_intelligence_agent` requires `confirm:true`. There is no direct `create_strategy` operation.
+**Strategy-bound agents.** An agent binds to a strategy through its draft's `STRATEGY_BINDING` axis — on a create draft, or on an edit draft as a rebind that commits through the same `commit_agent_draft` (discover `strategyId` via `list_strategies`). The plan tools, `update_strategy_signal_rule` and the direct agent writers are retired, and so is `create_strategy`.
 
 ## Capabilities
 
@@ -2468,7 +2551,7 @@ you reach over MCP:
 | `battlegrid-arena-play` | Enter Market Grid sessions: find an open session, read its coin pool and live market context, compose a grid with real per-coin reasoning or have an agent generate it, submit, then read results and the reasoning journal |
 | `battlegrid-market-analysis` | Read the current crypto market — regime, funding and open interest, leaders and laggards, a deep-dive on any named coin — and close with the levels worth watching |
 | `battlegrid-radar-deployment` | Put agents on standing duty: per-coin Radar policies that fire on confirmed regime flips, and per-preset Arena deployment policies, previewed before they are written and un-deployed with the blast radius stated |
-| `battlegrid-strategy-authoring` | Build a strategy from a plain-English idea: gather evidence, lock the spec, compile against the platform grammar, review exactly what will run, apply only on confirmation. Also fork, tune, restore, archive, preview |
+| `battlegrid-strategy-authoring` | Build a strategy from a plain-English idea: gather evidence, lock the spec, stage it into the strategy's draft, review the diff, diagnostics and impact, commit only on confirmation. Also fork, tune, restore, archive, preview |
 | `battlegrid-strategy-doctor` | Diagnose an agent that is not doing what was expected — why it has not traded, why it stopped, whether it is healthy — from typed fields, then rank the fixes with the exact lever each needs |
 | `battlegrid-strategy-examples` | Full-surface composition patterns: custom report sections and header grammar, benchmark sections, condition trees with verdicts and enforcement gates, tiered signal weights and the aggregate gate math, routing gates, ATR trade levels, position management, plus validated desk-grade playbooks and TradingView process ports |
 | `battlegrid-trade-analysis` | Read your own trading position: where the money is, whether each agent is doing its job, what is open and how close it sits to its protections, and whether the automation is actually running |

package/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: battlegrid
-description: MCP skill for BattleGrid — play crypto prediction games (Market Grid), author trading strategies with the strict compile → review → apply workflow, and manage strategy-bound intelligence agents from AI agents.
+description: MCP skill for BattleGrid — play crypto prediction games (Market Grid), author trading strategies and intelligence agents through their drafts (stage → read the diff → commit on the player's word), and manage strategy-bound agents from AI agents.
 ---
 
 # BattleGrid
@@ -34,44 +34,47 @@ to connect and to know which one to open.
 
 ## Single-account vs multi-account request shape
 
-The strategy-authoring tools — `get_strategy_section_template`, `update_strategy_signal_rule`, `compile_strategy_plan`, `apply_strategy_plan` — use one strict server-owned envelope, `{ request: canonicalPayload }`.
+The draft lifecycle tools — `stage_<kind>_draft`, `get_<kind>_draft`, `commit_<kind>_draft`, `discard_<kind>_draft` and `list_<kind>_drafts` for the `strategy` and `agent` kinds — and `get_strategy_section_template` use one strict server-owned envelope, `{ request: canonicalPayload }`.
 
-- **Single account:** call them as the server publishes them, e.g. `compile_strategy_plan({ request })`.
+- **Single account:** call them as the server publishes them, e.g. `stage_strategy_draft({ request })`.
 - **Multiple accounts (proxy):** live discovery adds a sibling `account`, so the shape is exactly `{ account, request }`. Select the account in the outer field; keep `request` exactly as discovered. The proxy strips only `account` and forwards the unchanged `{ request }`.
 
 Never put `account` inside `request`, and never flatten request fields beside it. Other tools keep whatever input shape live discovery reports for them.
 
 ## Scopes
 
-- `mcp:read` — strategy discovery **and** non-financial configuration writes (author strategies, edit agents, customize signals). Treat it as configuration authority, not view-only.
+- `mcp:read` — strategy discovery **and** non-financial configuration writes (stage and commit strategy and agent drafts, customize signals). Treat it as configuration authority, not view-only.
 - `mcp:wager` — financial actions (submit paid entries, accept/cancel entry decisions, deployment policies). Enable **Server-Signed Wagers** in Profile → MCP to grant it. Pending entry decisions come from the conversational surface, which waits for approval; an agent deployed to a radar coin or a trading-enabled arena slot executes without one.
 
-## Author a strategy, and bind it to an agent
+## Author a strategy or an agent, and bind them
 
-**The arc lives in `battlegrid-strategy-authoring`** — activate it, and `battlegrid-strategy-examples`
-alongside it when the strategy goes beyond a bare template. Do not compose a plan from this document;
-it states only what the *proxy* adds to that arc.
+**The arc lives in `battlegrid-strategy-authoring` and `battlegrid-agent-management`** — activate the
+one you need, and `battlegrid-strategy-examples` alongside the first when the strategy goes beyond a
+bare template. Do not compose a draft from this document; it states only what the *proxy* adds to
+that arc.
 
-Three facts about transport, which are this skill's to state because they are about the wire rather
+Four facts about transport, which are this skill's to state because they are about the wire rather
 than about authoring:
 
 - **The envelope is `{ request }`, or `{ account, request }` on a multi-account proxy** (see above).
-  It applies to `get_strategy_section_template`, `update_strategy_signal_rule`,
-  `compile_strategy_plan`, `apply_strategy_plan` and `stage_strategy_plan`.
-- **`planToken` is opaque and is forwarded byte-for-byte.** Never retype, paraphrase, abbreviate or
-  rebuild it from memory — the proxy passes the bytes through unchanged, and a mangled token
-  addresses no approved plan and is refused. It lives five minutes.
-- **`apply_strategy_plan` carries no `plan` member.** One is rejected as an unknown key: the server
-  reads back the plan its own compile approved, so nothing is copied out of the compile response and
-  nothing can be truncated or half-reconstructed in transit. Send
-  `{ request: { planToken, confirm: true } }` and nothing else. **`stage_strategy_plan` is the same
-  shape with the token alone** — it puts the plan into the player's unsaved draft for them to review
-  in the builder, commits nothing, and leaves the token still applicable.
-
-Agents bind to a strategy at creation (`create_intelligence_agent({ …, modelId, strategyId })`);
-there is no direct strategy-creation tool. **`battlegrid-agent-management`** carries commissioning,
-reconfiguration, rebinding and intervention; **`battlegrid-radar-deployment`** carries putting an
-agent on standing duty; **`battlegrid-strategy-doctor`** carries diagnosing one that is not trading.
+  It applies to every draft lifecycle tool and to `get_strategy_section_template`.
+- **Every change goes through the entity's draft.** `stage_<kind>_draft({ request: { <id>?,
+  draftVersion, axes } })` writes proposed axes into the player's unsaved draft and commits nothing;
+  omit the id to open a new create draft, whose minted id the response carries.
+  `get_<kind>_draft({ request: { <id> } })` returns the draft, its `draftVersion`, the live
+  `committedRevision`, a per-axis `diff`, `diagnostics` and `impact`.
+- **A commit names exactly the two numbers that read returned.**
+  `commit_<kind>_draft({ request: { <id>, draftVersion, expectedRevision } })` — `expectedRevision`
+  is `null` for an entity not created yet. Commit only after the player has seen the diff and impact
+  and said yes. `discard_<kind>_draft({ request: { <id>, draftVersion } })` is the same fence.
+- **The proxy forwards numbers and `null` unchanged.** It never fills in a version, never retries a
+  refused call and never rebuilds a request: a `DRAFT_VERSION_MOVED`, `DRAFT_AXIS_CONTESTED` or
+  revision `CONFLICT` refusal carries `details.nextAct`, and the next act is the caller's.
+
+`fork_strategy` copies a revision into a new create draft and creates nothing until that draft is
+committed. An agent binds to a strategy through its draft's `STRATEGY_BINDING` axis, on a create or
+as a rebind. **`battlegrid-radar-deployment`** carries putting an agent on standing duty;
+**`battlegrid-strategy-doctor`** carries diagnosing one that is not trading.
 
 ## Play a game (Market Grid)
 
@@ -85,7 +88,7 @@ The `play-market-grid` prompt (discover via `prompts/list`) provides a guided en
 
 ## Retired operations
 
-`create_strategy` (and other legacy direct-authoring/agent-scoped rule tools) are **retired** — they are absent from discovery and cannot be invoked. Author strategies with compile → review → apply, edit rules with `update_strategy_signal_rule`, and bind strategies to agents at agent creation. Do not attempt flat legacy payloads; the server enforces a closed-world request root and the proxy never reconstructs them.
+`create_strategy`, the plan tools (`compile_strategy_plan`, `stage_strategy_plan`, `apply_strategy_plan`), `update_strategy_signal_rule`, and the direct agent writers (`create_intelligence_agent`, `update_intelligence_agent`, `rebind_intelligence_agent`) are **retired** — they are absent from discovery and cannot be invoked. Stage into the entity's draft, read it back, and commit the version you read; a signal rule is a row of the strategy draft's `SIGNAL_RULES` axis, and a strategy binding is the agent draft's `STRATEGY_BINDING` axis. Do not attempt flat legacy payloads; the server enforces a closed-world request root and the proxy never reconstructs them.
 
 ## Common errors
 
@@ -95,7 +98,9 @@ The `play-market-grid` prompt (discover via `prompts/list`) provides a guided en
 | `API key must start with "bg_live_"` | Invalid key format | Generate a new key at battlegrid.trade → Profile → MCP |
 | Authentication failed (401/403) | Key revoked/rotated | Generate a new key and **restart** the proxy (keys read once at startup) |
 | `"account" parameter is required` | Multi-account call missing `account` | Add the outer `account`; keep `request` unchanged |
-| Plan token expired / revision drift | >5 min since compile, or upstream changed | Recompile, review the fresh plan, then apply |
+| `DRAFT_VERSION_MOVED` | The draft changed after you read it, or no draft is held (`details.draftVersion` null) | Call `get_<kind>_draft` again and commit what it now holds |
+| `DRAFT_AXIS_CONTESTED` | The player changed `details.contestedAxes` in their open form after the version you staged against | Read the draft again and propose against what they now have |
+| `CONFLICT` on a commit | The live revision moved after the draft read | Read the draft again; commit at the new `committedRevision` |
 | Required at allocation Off | A rule flags `required` on a signal weighted `0` (contract 34) | Read `details.inertRequiredSignalIds`; per signal either raise `allocation` or set `required: false` |
-| Method not found | Calling a retired/unknown tool | Re-run `tools/list`; use the compile → review → apply flow |
+| Method not found | Calling a retired/unknown tool | Re-run `tools/list`; stage, read and commit through the entity's draft |
 | `Wager scope required` | `mcp:wager` not enabled | Enable Server-Signed Wagers in Profile → MCP |

package/dist/index.d.ts

@@ -49,7 +49,7 @@ import { type Implementation, type Prompt, type Resource } from '@modelcontextpr
  * being asked. Move it for a change to THIS package — a proxy fix, a dependency bump, a docs
  * correction. Never move it to track the server.
  */
-export declare const PACKAGE_VERSION = "31.2.64";
+export declare const PACKAGE_VERSION = "31.2.66";
 export declare const DEFAULT_URL = "https://mcp.battlegrid.trade/mcp";
 export interface EnvConfig {
     apiKeys: string[];

package/dist/index.js

@@ -52,7 +52,7 @@ import { ListToolsRequestSchema, CallToolRequestSchema, ListPromptsRequestSchema
  * being asked. Move it for a change to THIS package — a proxy fix, a dependency bump, a docs
  * correction. Never move it to track the server.
  */
-export const PACKAGE_VERSION = '31.2.64';
+export const PACKAGE_VERSION = '31.2.66';
 export const DEFAULT_URL = 'https://mcp.battlegrid.trade/mcp';
 const MAX_RETRIES = 3;
 const RETRY_DELAYS_MS = [2000, 4000, 8000];

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@battlegrid/mcp-server",
-  "version": "31.2.64",
+  "version": "31.2.66",
   "description": "BattleGrid MCP server — play crypto prediction games from AI agents",
   "type": "module",
   "main": "dist/index.js",

package/skills/EXPORT.json

@@ -1,16 +1,16 @@
 {
   "generator": "battlegrid-app/server/scripts/export-mcp-skills.mjs",
-  "contractVersion": "84.0.0",
+  "contractVersion": "85.0.0",
   "files": {
-    "battlegrid-agent-management/SKILL.md": "5ea8384ff76ccb9fdf00e4ec8b584f88fdba6d1c9d5679ce0b7380c23bfbaab1",
+    "battlegrid-agent-management/SKILL.md": "708a37732e822184f99e58fc96b87780e61155e792482fcd56ae56aa7064cd5b",
     "battlegrid-arena-play/SKILL.md": "4cfaa92a8d0dcaf477b227abd774e7aa8642c185d72108dfd401be0cf8aecd7f",
-    "battlegrid-market-analysis/SKILL.md": "22fde9c4eac0261c89a8056ab8b20b66fcbe1fd58447fa0ac84fd410b4d134d7",
+    "battlegrid-market-analysis/SKILL.md": "3a9943de9f482a8230fb2983efd2f2d8b8c17d49c242e49b68e7243c20c3aa7b",
     "battlegrid-radar-deployment/SKILL.md": "17301fa66f4b128154435462ffa967efcb3d016df671b03c485d0f8b840fc891",
-    "battlegrid-strategy-authoring/SKILL.md": "6aa3a04fd4f0624a671d70aead009f4943db1ffa34402e403b588dd998e828c9",
-    "battlegrid-strategy-doctor/SKILL.md": "a3446f24059be72ae797ba4e9669848d851ac3dc38675923fe3d307f557eb82f",
-    "battlegrid-strategy-examples/SKILL.md": "534c053e75021b6954e2365dbec4893ed9fc807a064a922f47f2d34a4e528221",
-    "battlegrid-strategy-examples/references/playbooks.md": "02168e3af35268a30fd156f3337d25fe15e6df67da1592f4cb4d31090be3f94f",
-    "battlegrid-strategy-examples/references/recipes.md": "53887daece17995543e7d3fe1bf2577fc41a6254c291acacde48d7de63853641",
+    "battlegrid-strategy-authoring/SKILL.md": "4c708dc90029e0b991c4c154d9c74a366a29c2d3a827b78936f2f344df3efeb4",
+    "battlegrid-strategy-doctor/SKILL.md": "14f20bff9e2b5a59d11634fe3615b1298d672d5e2eba06d3dc8698b571b3bee3",
+    "battlegrid-strategy-examples/SKILL.md": "3c11942f7327e00208d48a7a256faf83d80faf568bd0181b707657bace3c1ef9",
+    "battlegrid-strategy-examples/references/playbooks.md": "63aa07f3d55f97e53b2bf6401528807ab23bd093a4bbc37e598158249db24a59",
+    "battlegrid-strategy-examples/references/recipes.md": "61382acdd295fa159f055b787ba501f1c015f383f59a6714a973057f10de611f",
     "battlegrid-strategy-examples/references/tradingview-ports.md": "2b13adbc137178955edcca31b6ab40c01c745a932a0750b91db8820c736700bb",
     "battlegrid-trade-analysis/SKILL.md": "f5d817022ab912f00e9c17ffa720a7599f6e6fa4b806d873fe5e7520c51a8dcd",
     "battlegrid-trade-proposal/SKILL.md": "9bf7b7648fb009db118a3a428b15abf38df5ba56a2ef4c8a4eae3d979bdc8bcb"