@battlegrid/mcp-server 31.2.26 → 31.2.28

package/README.md

@@ -24,6 +24,62 @@ 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 — v61
+
+One part to read first: **the per-condition evidence clock is gone**, and what replaced it is not a
+rename. Which bar a condition reads is now decided by the surface asking — a decision reads completed
+strategy bars, a display read shows the forming one — and by each candle column's own Confirmed /
+Developing selector. `closes` survives and changes meaning. The canonical record for every contract
+move is `docs/architecture/MCP_CONTRACT_HISTORY.md` in `battlegrid-app`; the served version is what
+the handshake announces.
+
+### Rejected input — something you author is no longer accepted
+
+- **A condition entry carrying `clock` is REFUSED** (61.0.0, `read-higher-timeframes-per-column`).
+  The authoring schemas are `.strict()`, so `compile_strategy_plan`, `apply_strategy_plan`,
+  `fork_strategy` and the HTTP save alike fail the body with the unknown-key error. There is no
+  replacement key to send: the decision instant belongs to the caller, not to the condition. Two
+  input hashes move, `compile_strategy_plan`'s and `preview_strategy_report`'s — the two tools that
+  accept a condition entry.
+
+- **`closes` stays mandatory and means something new.** It is now *held for N completed strategy
+  bars* (1–5). Above `1` it is legal only over a header a completed bar actually moves, at or above
+  the strategy timeframe, never over a developing read, and only where the condition carries a clause
+  of its own — a referenced condition resolves once and contributes the same answer to every bar, so
+  a hold reached only through a reference would count reads that never happened.
+
+### Changed shape — what you receive moves
+
+- **`ConditionOutcome.closeClock` becomes `hold`, and it is NON-NULL for every condition.** A
+  one-close condition reads `0 or 1 of 1` rather than serving an absence, so a client no longer
+  branches on whether the reading exists. The count is taken from completed strategy bars whatever
+  basis the surface evaluated on.
+
+- **`ReportConditionColumnDTO.closeClockReadable` becomes `closesReadable`, beside a new
+  `developingRead`.** The first answers whether a condition addressing that header may hold more than
+  one completed bar; the second states whether the header reads the bar still in progress at the
+  decision instant. Both are server-supplied — derive neither. Eight output hashes move, covering
+  every tool that serves a strategy's conditions or a report's addressable columns.
+
+### Wider input — nothing you send today breaks
+
+- **The `bars` selector is declared on eleven candle-series transforms, not four.** `value`,
+  `classifyZone`, `classifyState`, `distance`, `spread`, `crossDetect` and `bandTouch` join
+  `trajectory`, `aggregate`, `efficiency` and `maxShare`. It carries **no default value**, because
+  the default is a rule rather than a constant: Confirmed (`"closed"`) above the strategy timeframe,
+  and at or below it the series as the frame carries it. The resolved answer is served per column on
+  `effectiveParameters.bars` — `null` where discovery has no anchor to resolve a rung against.
+
+- **A higher-timeframe level is measured from the current strategy-bar price.** Distances and the
+  candle label classifiers compare against the frame's current price rather than the higher-timeframe
+  bar's own close, which could be a full higher-timeframe bar stale. A distance chained into a series
+  keeps every slot on its own bar's close.
+
+### Vocabulary
+
+`domains.conditionClock` is removed; `domains.columnBars: ["all", "closed"]` takes its place, and
+`axes.condition` loses `clock`. `toolCount` stays 117.
+
 ## Contract history — v60
 
 One release train, four numbers, and two parts to read first: **`propose_entry_decision` no longer

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.26";
+export declare const PACKAGE_VERSION = "31.2.28";
 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.26';
+export const PACKAGE_VERSION = '31.2.28';
 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.26",
+  "version": "31.2.28",
   "description": "BattleGrid MCP server — play crypto prediction games from AI agents",
   "type": "module",
   "main": "dist/index.js",

package/skills/EXPORT.json

@@ -1,18 +1,18 @@
 {
   "generator": "battlegrid-app/server/scripts/export-mcp-skills.mjs",
-  "contractVersion": "60.3.0",
+  "contractVersion": "61.0.1",
   "files": {
     "battlegrid-agent-management/SKILL.md": "b6ea75b3d838c1dbaaf3984d7e99a11c81686de2c1a1910c35699ee7e70dafa5",
     "battlegrid-arena-play/SKILL.md": "03fa153bf82be18bf5ed01e3ba12e2cd9f99a81b08d903a77b52169e7519a182",
     "battlegrid-market-analysis/SKILL.md": "22fde9c4eac0261c89a8056ab8b20b66fcbe1fd58447fa0ac84fd410b4d134d7",
     "battlegrid-radar-deployment/SKILL.md": "d2a012b154e1e529db19529bd7c3d75d069f4e410d5804add51165f0f0902b2e",
-    "battlegrid-strategy-authoring/SKILL.md": "ea2593ea9d6d2feb9910e285e4b132eb36001164b9d6551cc206531afad3f552",
+    "battlegrid-strategy-authoring/SKILL.md": "93e1c9709079a4e9c968597ac572b4b62f5b0e68c01f9e9947db7e2ba304dcdf",
     "battlegrid-strategy-doctor/SKILL.md": "9ab3f79128ec81d3e90167c3f1ea4bd6f6b570290e5ebe2bf855195263c58239",
-    "battlegrid-strategy-examples/SKILL.md": "263c3b865ea85e56ac420611a7070360d65be6f2faee071329880e49a6101eda",
+    "battlegrid-strategy-examples/SKILL.md": "17e8cf8040813622bd5b82165c7af82e03287fee1f6aac974e0b6c584580dd27",
     "battlegrid-strategy-examples/references/playbooks.md": "35c543c090d00ba19e4bcf0a80502afac7a4954643fc535de0b24381c91ecbf4",
     "battlegrid-strategy-examples/references/recipes.md": "53887daece17995543e7d3fe1bf2577fc41a6254c291acacde48d7de63853641",
     "battlegrid-strategy-examples/references/tradingview-ports.md": "2b13adbc137178955edcca31b6ab40c01c745a932a0750b91db8820c736700bb",
     "battlegrid-trade-analysis/SKILL.md": "32573a67e55d735e6ee4e36b3b48c815694102704bc453c4d1c13db39551b3da",
-    "battlegrid-trade-proposal/SKILL.md": "503ed705d4f9823e21846afe5a10f35d7d6e35933c4bdd1d5b4fd923eb9d674d"
+    "battlegrid-trade-proposal/SKILL.md": "0d8ffecd493f7916d352cee3d22aee5812c3790592b100d3f9802c75ca1180c0"
   }
 }

package/skills/battlegrid-strategy-authoring/SKILL.md

@@ -104,9 +104,9 @@ question you would otherwise guess — and a refusal you would otherwise earn:
   `levelOffsetAtrMultiple`, `validForBars`. Every trigger is decided at the close of the strategy's
   OWN bar, so there is no confirm-timeframe key; for the level triggers the level itself is derived
   from the trigger and the trade's direction, never named. A multi-bar hold belongs to the condition
-  that needs it (`clock: CLOSE` with its own `closes`), not to this axis. The `strategy-examples`
-  skill carries the vocabulary and the one-directional legality matrix; a CREATE without it is
-  refused outright.
+  that needs it (its own `closes`, counted in completed strategy bars), not to this axis. The
+  `strategy-examples` skill carries the vocabulary, the hold's legality and the per-column
+  Confirmed / Developing read; a CREATE without it is refused outright.
 - `get_strategy_column_contract` → `outputs[].conditionOperators`. An empty array means that
   rendered header has no comparison semantics and cannot appear in a condition clause at all.
   Legality is per rendered header, not per column: a trajectory's slot header and its `_trend`

package/skills/battlegrid-strategy-examples/SKILL.md

@@ -86,8 +86,9 @@ against a literal; neither of those shapes is what a previous-session level need
 
 ## Conditions
 
-`{ conditionKey, name, definition, verdict, required, exit, clock, closes }` — all eight
-required, no defaults. Clauses: numeric/rank headers take `lt|lte|gte|gt|between`;
+`{ conditionKey, name, definition, verdict, required, exit, closes }` — all seven
+required, no defaults. A `clock` key is REFUSED: the per-condition evidence clock was retired in
+contract `61.0.0`. Clauses: numeric/rank headers take `lt|lte|gte|gt|between`;
 classification/direction headers take `is|in` with the served vocabulary. Groups:
 `ALL | ANY | NOT | N_OF` (with `n`), depth ≤ 2. `conditionRef` composes named conditions (no
 cycles; forward refs legal). `sectionKey: null` is sugar for a report-unique header only.
@@ -103,30 +104,53 @@ before billing. And the RESOLVED verdict binds entry DIRECTION: `UP` admits long
 setups block and from the `decide_trade` contract, not merely discouraged in them. A strategy that
 declares no verdict-carrying condition resolves `null` and constrains nothing.
 
-A verdict carrier must read a SETTLED bar wherever one is available to it — `clock: "CLOSE"`
-whenever every column in its CLOSURE accepts a closed frame. The closure is what it reads directly
-plus everything reached through `conditionRef`, transitively: a referenced condition contributes what
-IT reads, never the clock it happens to declare, so moving a clause into a building block and leaving
-that block `LIVE` does not make a settled bar unavailable to the carrier. Where no closed frame moves
-some operand in the closure (a published regime label, an open-interest regime, a published rolling
-change), `LIVE` stays legal at any depth: there is no settled bar to take.
-
-Evaluation is three-valued: UNRESOLVED never collapses to FALSE; forming-bar reads are provisional.
-
-**The evidence clock.** `clock: "LIVE"` reads the forming bar; `clock: "CLOSE"` reads settled
-bars, and `closes` is how many consecutive closed bars must read TRUE (1–5) — always `1` under
-LIVE, which has exactly one frame. A CLOSE clock is legal **only** over a header resolved from
-this coin's own candle series at offset 0. Frame-inert operands are refused
-(`CONDITION_CLOCK_OPERAND_ILLEGAL`): perp-payload scalars, published rolling changes, ranks, zone
-entities, MDS regime labels, enrichment metrics, session scalars, and any clause authored at a
-non-zero offset. A closed frame cannot move them, so "held for N closes" would describe reads
-that never happened. A frame-inert operand anywhere in a condition's closure simply keeps that
-condition on `LIVE`, and that is legal — splitting the clause into its own condition and
-`conditionRef`-ing it does NOT buy the referencing condition a CLOSE clock, because a `CLOSE`
-condition may not reference a `LIVE` one (`CONDITION_CLOCK_REFERENCE_ILLEGAL`) and availability walks
-into the referenced closure anyway. **Worked liquidity floor:** `LIQUID_FLOOR` is `LIVE` because
-`vol24hUsd` is a bundle scalar, and a condition that references it is `LIVE` too. Reach for a split to
-keep a condition's MEANING separable, not to change its clock.
+A verdict carrier must read no DEVELOPING bar. A verdict is refused over any closure that reads a
+column selecting Developing above the strategy timeframe (`CONDITION_VERDICT_READ_ILLEGAL`). The
+closure is what the condition reads directly plus everything reached through `conditionRef`,
+transitively: a referenced condition contributes what IT reads, so moving the clause into a building
+block does not launder it. A closure whose candle columns all read Confirmed — or whose operands no
+bar moves at all, such as a published regime label, an open-interest regime or a published rolling
+change — admits a verdict at every decision, because a decision reads the completed strategy bar and
+a level is compared against that bar's close.
+
+Evaluation is three-valued: UNRESOLVED never collapses to FALSE; a developing read is provisional,
+and so is any reading taken on the display lane's forming bar.
+
+**Every condition is decided at the strategy bar's close.** There is no per-condition clock. Which
+bar a condition reads is decided by the surface asking — a decision (the radar's close decision, the
+compose that takes the trade, the exit sweep) reads completed strategy bars; a display read shows the
+forming one and decides nothing — and by each candle column's own Confirmed / Developing selector.
+
+**The hold count.** `closes` is how many consecutive COMPLETED strategy bars must read TRUE (1–5). A
+hold counts the same completed bars whichever surface asks, so a held condition reads them on the
+display lane too. Above `1` it is legal **only** where a completed bar changes the reading: over a
+header resolved from this coin's own candle series, at offset 0, at or above the strategy timeframe,
+read Confirmed. Everything else is refused (`CONDITION_HOLD_OPERAND_ILLEGAL`) — perp-payload scalars,
+published rolling changes, ranks, zone entities, MDS regime labels, enrichment metrics, session
+scalars, a non-zero offset, a column BELOW the strategy timeframe (the retained lower series cannot
+reach an earlier strategy close), and a developing read (the bar in progress exists on the newest
+frame only). A hold also needs a clause of the condition's OWN
+(`CONDITION_HOLD_ILLEGAL`): a referenced condition is resolved once and contributes the same answer
+to every frame, so a hold that moves with the bar only through a reference would count reads that
+never happened. **Worked liquidity floor:** `LIQUID_FLOOR` holds one close because `vol24hUsd` is a
+bundle scalar. Reach for a split to keep a condition's MEANING separable, not to buy it a hold.
+
+**Confirmed / Developing, per candle column.** Every transform whose home is the coin's candle series
+carries `bars`: `"closed"` is Confirmed — the newest bar completed at the strategy close — and
+`"all"` is Developing, the higher-timeframe bar still in progress at that close, which REPAINTS until
+it completes. Left unset the default is a rule, not a value: Confirmed for a column ABOVE the
+strategy timeframe, and at or below it the series as the frame carries it. At or below the strategy
+timeframe the choice therefore sets only what the live lane shows — no bar is in progress at the
+anchor's own close — so Developing there is legal and changes no decision. A condition reading a
+developing bar is single-frame: it holds one close, carries no verdict and cannot take the `exit`
+role. The resolved answer for a column is served on `effectiveParameters.bars`.
+
+**A higher-timeframe level is measured from the current strategy-bar price.** The distance to a `4h`
+Donchian band, and every candle label classifier (`MA_ALIGN`, `PRICE_ZONE`, `BB_TOUCH`), compares
+against the frame's current price — the strategy bar's close under a decision, the live mark on
+display — not against the higher-timeframe bar's own close, which is up to one higher-timeframe bar
+stale. A distance CHAINED into a series transform keeps every slot on its own bar's close, so one
+series carries one reference basis.
 
 **The lane a strategy is deployed to.** Report-level scalars split by LANE, and the split is not a
 quality of the header — it is which reader runs. Market breadth and the reference pairs are ordinary
@@ -138,10 +162,12 @@ can read instead. The refusal lands at DEPLOY rather than at save, because a str
 of its own: the same strategy is legal, and reads those scalars correctly, on an arena agent.
 
 **The exit role.** `exit: true` makes a settled TRUE reading close open positions its verdict
-opposes — UP exits SHORTs, DOWN exits LONGs, a NEITHER or `null` verdict exits both. Legal only
-under `clock: "CLOSE"`: a LIVE reading is the forming bar, and an exit fired on one is an
-intrabar exit. Orthogonal to `required` — the two act on disjoint lifecycles, pre-entry versus
-open — so a condition may carry both, either, or neither.
+opposes — UP exits SHORTs, DOWN exits LONGs, a NEITHER or `null` verdict exits both. Legal only over
+a closure every operand of which a completed bar MOVES (`CONDITION_EXIT_READ_ILLEGAL`), which rules
+out a developing read — a bar in progress is the forming bar, and an exit fired on one is an intrabar
+exit — and rules out a frame-inert operand, which could never fire. Orthogonal to `required` — the
+two act on disjoint lifecycles, pre-entry versus open — so a condition may carry both, either, or
+neither.
 
 **A state column is not a flip event.** `ST_DIR` reads the same on every bar of a trend, so
 `ST_DIR is "bullish"` is a regime filter and never an entry signal. The flip needs an event column
@@ -163,7 +189,7 @@ is DERIVED from the trigger and the trade's direction, never named. There is no
 key either: the bar whose close decides an entry is the strategy's OWN timeframe.
 
 **Every trigger is decided at the close of the strategy's own bar — there are three, and the close
-is the only entry clock.** The newest settled bar is read on the closed basis — every `LIVE`-clocked
+is the only entry clock.** The newest completed bar is read on the closed basis — every one-close
 condition resolves on that bar and the scorecard reads its close — and a reading that still qualifies
 fires at that close. A bar that does not qualify decides nothing and is not revisited. The fill lands
 at the next tick, and the platform refuses it if the market has already run past its own drift budget
@@ -180,8 +206,8 @@ and is REFUSED on every save; there is no live-reading entry to author.
   short) by the offset, waiting for a return to it. Not filling is a correct outcome, not a
   failure; no unrecovered break in memory means no setup, never a fallback level.
 
-**A multi-bar hold belongs to the CONDITION that needs it.** Declare `clock: CLOSE` with that
-condition's own `closes` — the entry axis counts no bars, and there is no displacement band: the
+**A multi-bar hold belongs to the CONDITION that needs it.** Declare that condition's own `closes` —
+the entry axis counts no bars, and there is no displacement band: the
 platform's entry-deviation gate measures the live mark against the decided close and refuses a fill
 that drifted past the budget in either direction.
 

package/skills/battlegrid-trade-proposal/SKILL.md

@@ -31,6 +31,15 @@ re-sorts a list, re-derives a verdict, or approves on the player's behalf.
 
 ## 2. Queue the request
 
+**In a conversation the Agent Toolbox hosts, this section does not apply: name the coin and stop.**
+The player presses **Request a trade** in the trade lane beside you and the same queued request is
+registered from there, free and without a model turn; your job is to say which coin is worth
+requesting and what the gates read, and to leave the press to them. `propose_entry_decision` and
+`cancel_entry_request` are refused from such a conversation as tool errors, so calling one spends an
+op of your budget and queues nothing. The refusal is **host-wide** — every tool that writes is
+refused there, which is why no other skill carries a paragraph of its own — and every read in this
+flow stays available.
+
 - `propose_entry_decision` **only** on the coins the player named, or on the top qualifying row
   when they asked for the best fit. One coin per call.
 - **The call does not decide.** It registers a request against the agent's next strategy-bar close
@@ -62,6 +71,13 @@ re-sorts a list, re-derives a verdict, or approves on the player's behalf.
 
 ## 4. When the answer arrives — approve or decline only on the player's word
 
+**In a conversation the Agent Toolbox hosts, the approval is not yours to send.** The decided close
+lands on the trade card in the lane beside you, carrying the player's own Accept and Decline;
+`accept_entry_decision` and `cancel_entry_decision` are refused there as tool errors, so calling one
+spends an op and moves nothing. Read the card back to them — the direction, the levels, the
+conviction, the expiry — and say what you would do, which is the whole of your part. What you have
+to work from is whatever the player attaches from a card: its rendered readings, nothing more.
+
 - A decided close produces one of: a PROPOSED decision awaiting approval; a no-trade with the
   reason and the next coins worth asking about; a close that did not qualify; a window that passed
   with no sweep; or a bar the agent's own radar deployment decided first and traded in full.