@battlegrid/mcp-server 31.2.7 → 31.2.8

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -24,7 +24,7 @@ Seeing package `31.x` alongside handshake `battlegrid@33.x` — the package **be
24
24
 
25
25
  **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.
26
26
 
27
- ## Contract history — v37 → v49.5
27
+ ## Contract history — v37 → v51
28
28
 
29
29
  Eleven majors reached authors while this section stopped at v36. That gap is the mechanism, not an
30
30
  oversight: since v31 a contract move needs no release here, so nothing forced a note to be written —
@@ -32,11 +32,43 @@ and the documentation ships inside the tarball, so a note written but unpublishe
32
32
  Both halves are now closed by a rule keyed to the *served* contract rather than to a release of this
33
33
  package.
34
34
 
35
+ **50.0.0 and 51.0.0 arrived late, and the reason is worth naming.** The re-vendoring errand that
36
+ used to carry these notes is now a generated export
37
+ (`battlegrid-app/server/scripts/export-mcp-skills.mjs`), and it owns three paths — `skills/`,
38
+ `skills/EXPORT.json`, and the vendored digest. It deliberately does not touch this file. So the
39
+ digest kept arriving on time while the note stopped travelling with it, and this section sat at
40
+ v49.5 against a served contract of 51.0.0. Nothing a client could observe was wrong; what was
41
+ missing was the sentence telling them so. **A contract move still needs a human-authored entry
42
+ here, and the export lane will not remind you.**
43
+
35
44
  ### Accepted again — input that was rejected now compiles
36
45
 
37
46
  Nothing to migrate. This is the one direction that cannot break a client: a body the server used to
38
47
  refuse is now stored. Listed because a client that special-cased the refusal can delete that branch.
39
48
 
49
+ - **A signal rule patch no longer forces you to restate `allocation` and `required`** (51.0.0,
50
+ `fix-signal-rule-patch-semantics`). On `update_strategy_signal_rule`, and on the `rules` element
51
+ of `compile_strategy_plan`, both fields become optional and join `params` under ONE omission
52
+ rule: **an omitted mutable field preserves the stored value for that signal.** "Raise this
53
+ signal's weight" is now expressible.
54
+
55
+ ```jsonc
56
+ { "strategyId": "…", "expectedRevision": 7, "signalId": "volume_surge",
57
+ "allocation": 3 } // `required` and `params` keep exactly what is stored
58
+ ```
59
+
60
+ **Every existing client keeps working** — a complete payload is still a valid patch — so this is
61
+ listed for what you can now STOP sending. Before it, both fields were mandatory on every rule
62
+ surface, so a caller that had not first read the current rule had to invent a value it was never
63
+ asked about. That is not hypothetical: revision 5 of a production strategy flipped `required`
64
+ false → true unasked while moving a weight 2 → 3, turning a scoring signal into a **mandatory
65
+ gate** — which changes whether the agent takes trades at all.
66
+
67
+ One boundary on the newly legal ground, and it breaks nothing: a patch carrying **no** mutable
68
+ field is refused — *"A rule patch must change something: supply at least one of allocation,
69
+ required or params."* — rather than minting a no-op revision. Under 50.0.0 that request could not
70
+ be formed at all, so nothing that used to work is now refused.
71
+
40
72
  - **An arming trigger no longer constrains its required conditions' clock** (49.4.0,
41
73
  `restore-arming-trigger-authoring`). `compile_strategy_plan`, `apply_strategy_plan` and
42
74
  `fork_strategy` accept a strategy whose entry trigger is `ON_CANDLE_CLOSE`, `STOP_THROUGH_LEVEL`
@@ -55,6 +87,14 @@ refuse is now stored. Listed because a client that special-cased the refusal can
55
87
 
56
88
  ### Changed meaning, unchanged shape
57
89
 
90
+ - **`blocksScanGate` reads `true` for a class it did not** (50.0.0, `own-scan-served-set-once`), on
91
+ `preview_radar_resolution`. Blocking is now derived from the lane's **served set** rather than
92
+ switched over the reach reason, so a `FEED`-reason refusal on an operand no reader in the lane
93
+ serves BLOCKS instead of deferring. No field changes shape, and a client that already renders the
94
+ key renders the new answer — but a client that treated `blocksScanGate: false` as "this will
95
+ resolve once data arrives" now sees a deployment that will not fire. Nothing in the payload tells
96
+ you this moved.
97
+
58
98
  - **Three tools serve different values for identical input** (47.3.0, `derive-scan-fetch-from-report`).
59
99
  The radar scan leg now derives its timeframe fetch from the strategy's **report** rather than the
60
100
  on-duty agent's three perception rungs, so a required condition addressing an absolute timeframe
@@ -72,6 +112,44 @@ refuse is now stored. Listed because a client that special-cased the refusal can
72
112
 
73
113
  ### Rejected input — something you author is no longer accepted
74
114
 
115
+ - **`update_strategy_signal_rule` requires `confirm: true` when the strategy has bound agents**
116
+ (51.0.0, `fix-signal-rule-patch-semantics`). The write re-materializes scoring configuration onto
117
+ every bound agent immediately — including agents holding open USDC positions — and until now
118
+ nothing on the server asked. A rule edit on a strategy with one or more bound agents is refused
119
+ without the flag, and the message names the count. An edit on a strategy with **nothing bound is
120
+ unaffected**, and so is every path through the web editor.
121
+
122
+ **Send `confirm: true`.** That is the whole migration, and `confirm` is published on the input
123
+ schema — but nothing in the schema says WHEN it becomes mandatory, because the condition is the
124
+ bound-agent count rather than the shape of your body. The refusal rides the existing
125
+ `VALIDATION_ERROR` code, so a client that omits it discovers the rule at the refusal.
126
+
127
+ Why it moved to the server: the guard existed, but only as served prose the calling model could
128
+ decline — and did, twice in production on 2026-08-24. `archive_strategy` and
129
+ `rebind_intelligence_agent` have taken a server-enforced `confirm` all along; single-rule tuning
130
+ was the outlier among its own siblings, and it is the one that writes to scoring.
131
+
132
+ - **A radar deployment is refused when its strategy reads a session-field scalar** (50.0.0,
133
+ `own-scan-served-set-once`). `upsert_radar_deployment` refuses a deployment whose slot agents'
134
+ bound strategy carries a condition reading one of five SESSION-FIELD scalars — `fieldPlayers`,
135
+ `fieldUpBias`, `fieldBiasDir`, `captConc`, `picksSpread` — with
136
+ `CONDITION_OPERAND_UNSERVED_IN_LANE`. A body accepted under 49.5.0 is refused under 50.0.0
137
+ without one byte of it changing.
138
+
139
+ **Why a refusal and not a warning.** Those five describe a game SESSION, and radar runs outside a
140
+ session at BOTH its stages — so such a condition can never resolve there. The deployment formed
141
+ no fire edge and the agent did nothing on that coin, silently, forever. The refusal converts a
142
+ permanent silence into an error at the moment you author it.
143
+
144
+ **Migrate** by moving the clause to a scalar radar reads — the Market Breadth or Reference Pairs
145
+ families, which are market-wide reads with no session dimension — or by binding the strategy to
146
+ an arena agent instead. The error carries both halves: `allowedDomain` enumerates every servable
147
+ header, and the message names the sections.
148
+
149
+ **Strategy authoring is untouched by this bump.** The same strategy is legal, and reads those
150
+ scalars correctly, on an arena agent — which is why the refusal is on the DEPLOYMENT and not on
151
+ `compile_strategy_plan` / `apply_strategy_plan`.
152
+
75
153
  - **A benchmark-bound section no longer accepts crowd metrics or rank transforms** (49.0.0,
76
154
  `fix-benchmark-legality-save-path`). On a custom section carrying a non-null `benchmarkTicker`, a
77
155
  column whose metric is enrichment-stage (the `CROWD_*` family, `FLOW_ALIGN`, `SMART_RETAIL`,
@@ -179,6 +257,22 @@ refuse is now stored. Listed because a client that special-cased the refusal can
179
257
 
180
258
  ### Reshaped output — the same call returns a different shape
181
259
 
260
+ - **`update_strategy_signal_rule` gains its own response envelope** (51.0.0,
261
+ `fix-signal-rule-patch-semantics`). It no longer shares `{ strategy }` with its siblings. The
262
+ response is `{ strategy, ruleChanges }`, where `ruleChanges` is the server's own before/after
263
+ pair for the edited signal — `[{ signalId, before, after }]`, each side a full rule object. It is
264
+ `null` when the mutation changed no rule, **never `[]`**.
265
+
266
+ **Report the change from that pair, not from memory.** The planner always computed the diff and
267
+ the tool discarded it, so a caller narrating what it just did had only its own recollection of
268
+ the before-value. One production edit shipped a wrong receipt on top of a wrong write that way,
269
+ and the write was unreconstructable from the audit trail afterwards.
270
+
271
+ Additive, but published on a `.strict()` shape — a decoder pinned to the old two-key object
272
+ rejects the new key. `fork_strategy`, `archive_strategy` and `restore_strategy` keep the shared
273
+ `StrategyResponseSchema` and publish exactly what they did; it was deliberately NOT widened for
274
+ them, so this reshape reaches one tool only.
275
+
182
276
  - **An entry void now names the gate that refused it** (49.5.0,
183
277
  `fix-arming-trigger-clock-authority`), on `get_radar_activity_summary`. In the cause rollup, the
184
278
  `ENTRY_VOID` group's `gateCode` widens from always-`null` to `QualificationGateCode | null`: a
package/dist/index.d.ts CHANGED
@@ -49,7 +49,7 @@ import { type Implementation, type Prompt, type Resource } from '@modelcontextpr
49
49
  * being asked. Move it for a change to THIS package — a proxy fix, a dependency bump, a docs
50
50
  * correction. Never move it to track the server.
51
51
  */
52
- export declare const PACKAGE_VERSION = "31.2.7";
52
+ export declare const PACKAGE_VERSION = "31.2.8";
53
53
  export declare const DEFAULT_URL = "https://mcp.battlegrid.trade/mcp";
54
54
  export interface EnvConfig {
55
55
  apiKeys: string[];
package/dist/index.js CHANGED
@@ -52,7 +52,7 @@ import { ListToolsRequestSchema, CallToolRequestSchema, ListPromptsRequestSchema
52
52
  * being asked. Move it for a change to THIS package — a proxy fix, a dependency bump, a docs
53
53
  * correction. Never move it to track the server.
54
54
  */
55
- export const PACKAGE_VERSION = '31.2.7';
55
+ export const PACKAGE_VERSION = '31.2.8';
56
56
  export const DEFAULT_URL = 'https://mcp.battlegrid.trade/mcp';
57
57
  const MAX_RETRIES = 3;
58
58
  const RETRY_DELAYS_MS = [2000, 4000, 8000];
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@battlegrid/mcp-server",
3
- "version": "31.2.7",
3
+ "version": "31.2.8",
4
4
  "description": "BattleGrid MCP server — play crypto prediction games from AI agents",
5
5
  "type": "module",
6
6
  "main": "dist/index.js",