@battlegrid/mcp-server 31.2.65 → 31.2.67

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

@@ -9,8 +9,10 @@ The player configured an agent, pointed real money at it, and something did not
 to find out what, from the fields that actually say so — and then to say what would change it, in
 terms of levers that exist.
 
-Everything here is a **read**. You have no write path, and you do not acquire one by finding a
-problem: the fix runs through the flow that owns it, with that flow's own confirms.
+Everything you do here is a **read**. You have no write path, and you do not acquire one by finding
+a problem: the fix runs through the flow that owns it, with that flow's own confirms. The agent's
+draft tools are visible in this skill so that a risk-limit improvement can name its lever exactly
+(step 4) — never so that you call them from this arc.
 
 ## The five failures this flow exists to prevent
 
@@ -114,11 +116,14 @@ recommend.
 
 Present a ranked list. **Each item names the concrete thing that would apply it:**
 
-- a **strategy-rule** change → the `strategy-authoring` skill (its compile → review → confirm →
-  apply arc);
+- a **strategy-rule** change → the `strategy-authoring` skill, whose arc stages the change into
+  the strategy's draft, reads it back with its diff and impact, and commits only on the player's
+  confirming pick;
 - a **deployment or radar policy** change → the `radar-deployment` skill's tools, named;
-- a **risk-limit or budget** change → `agent-management`'s update verb, and note that it is a
-  **whole-object** write: the current limits are read and the complete object written back;
+- a **risk-limit or budget** change → `agent-management`'s draft: the complete TRADING_CONFIG
+  axis — a **whole-object** write, the current limits read and the complete object written back —
+  staged with `stage_agent_draft` and committed with `commit_agent_draft` once that flow's
+  confirmation is answered;
 - a **halt recovery** → the specific lever from step 3.
 
 An improvement with **no lever on this platform** is labelled as such, explicitly, and never
@@ -155,6 +160,10 @@ it is undetermined.
   one: route a rule change by naming the `strategy-authoring` skill, as step 4 does. The authoring
   tools are in a family this skill does not declare, and a skill body that names an unreachable tool
   — including in a negative — fails the registry's reachability check.
+- **Never call the agent's draft tools from this arc.** Step 4 names `stage_agent_draft` and
+  `commit_agent_draft` as the lever a risk-limit change takes; applying it activates
+  `agent-management`, whose arc stages the change, reads the draft back, states the radius and asks
+  before anything is committed.
 - Never diagnose from the agent's own prose or overlay text where a typed field exists.
 - Never present a gate-block count as a rate, a trend, or a percentage — report it as served.
 

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

@@ -5,8 +5,8 @@ description: Full-surface composition patterns for the strategy studio — valid
 
 # Strategy Studio — full-power composition patterns
 
-`strategy-authoring` owns the flow (evidence → locked spec → discover → compile → review →
-apply). This skill owns **what to compose**: a default build — a few platform sections, no
+`strategy-authoring` owns the flow (evidence → locked spec → discover → stage → review →
+commit). This skill owns **what to compose**: a default build — a few platform sections, no
 conditions, untouched weights — wastes the studio. The playbooks below are compiled in CI, so their
 shapes are binding in the sense that matters — they are checked, not merely asserted. Loose tokens
 elsewhere in this file are not covered by that gate, and vocabulary moves with deploys, so discovery
@@ -17,14 +17,15 @@ them.
 
 ## The full-power checklist
 
-Before compiling a CREATE, every "no" here is a decision to state, not an omission:
+Before committing a CREATE, every "no" here is a decision to state, not an omission:
 
 1. At least one **custom section** whose columns encode the thesis — not only platform modules.
 2. **Conditions** encode the entry logic: building blocks (`verdict: null`) + verdict carriers,
    and at least one `required: true` condition vetoing obvious disqualifiers **before any
    billing or LLM call**.
 3. **Every signal meant to score is named in `rules`** with a deliberate tier — unnamed signals
-   keep server defaults (typically Off). Verify in the compiled scorecard, never assume.
+   keep server defaults (Off on a CREATE). Verify against the rule rows the draft read serves,
+   never assume.
 4. **Gates** (`minAggregateScore`, `minRequiredCount`, `minAtrPct`) are computed against the
    chosen weight budget, not guessed.
 5. **Trade levels + position management** match the setup's geometry and holding period.
@@ -66,9 +67,10 @@ standard market-leader regime gate. Platform `sectionKey`s are their literal key
 (`includeMtfConfluence`). Custom `sectionKey`s are the **server's** to issue, and which of the two
 things you do depends on the operation: on a **CREATE, omit `sectionKey` entirely** — supplying one
 is refused, since a new strategy owns no custom sections yet; on an **UPDATE or RESTORE, send back
-the keys `get_strategy` returned** for the sections you are keeping. Either way you never invent
-one. To section-qualify a duplicated header, read the key from a preview's `conditionColumns` or
-from the qualified candidates a `CONDITION_COLUMN_AMBIGUOUS` refusal offers.
+the keys `get_strategy` returned** for the sections you are keeping, and omit it on a section you
+add. Either way you never invent one. To section-qualify a duplicated header, read the key from a
+preview's `conditionColumns` or from the qualified candidates a `CONDITION_COLUMN_AMBIGUOUS`
+refusal offers.
 
 **Event columns print only on their event.** `MACD_cross` and `EMA5_13` (Bullish/Bearish) carry a
 value on the crossing bar and are null on every other one, which reads as UNRESOLVED. Use an event
@@ -220,11 +222,12 @@ scan has on that coin, or free the coin.
 **The refusal lands where an agent meets a coin**: at the radar deploy (its preview, the builder's
 Save and the draft commit); at a manual entry request, as `CONDITION_UNREADABLE_ON_COIN`;
 and, for an agent already deployed or holding an open position or a pending manual request, at a
-strategy save (`compile_strategy_plan`, `apply_strategy_plan`, `restore_strategy`) or a rebind. A save
-is checked only on behalf of those agents: a strategy carries no lane of its own, so one with no agent
-the radar acts on is never checked, and the same strategy is legal, and reads session-field scalars
-correctly, on an arena agent. A refused compile issues no plan token, so nothing can stage that
-content.
+strategy commit (`commit_strategy_draft`, the builder's Save, `restore_strategy`) or a rebind (the
+agent draft's STRATEGY_BINDING commit). A commit is checked only on behalf of those agents: a
+strategy carries no lane of its own, so one with no agent the radar acts on is never checked, and
+the same strategy is legal, and reads session-field scalars correctly, on an arena agent. A draft
+may hold such content — staging never refuses a draft for being invalid — but its commit is
+refused, so it never reaches the agents.
 
 **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 over
@@ -247,11 +250,15 @@ anchor, or the author gates on something that admits most bars.
 
 ## Entry
 
-`{ trigger, levelOffsetAtrMultiple, validForBars }` — all three required on every CREATE, no
-defaults. This axis is replaced WHOLE on save, so an omitted key would silently revert an author's
-discipline rather than be refused. There is no level-source key: the level a level trigger rests at
-is DERIVED from the trigger and the trade's direction, never named. There is no confirm-timeframe
-key either: the bar whose close decides an entry is the strategy's OWN timeframe.
+`{ trigger, levelOffsetAtrMultiple, validForBars }` — the axis's keys, and the trigger decides
+which of them you send. `ON_CANDLE_CLOSE` is sent ALONE, as `{ "trigger": "ON_CANDLE_CLOSE" }`: a
+`levelOffsetAtrMultiple` or `validForBars` beside it is refused as an unrecognized key. A level
+trigger — `STOP_THROUGH_LEVEL` or `ON_RETEST` — sends both of them, no defaults. The axis is staged
+WHOLE, so a level trigger missing one is refused rather than half-kept. It is not required on every
+CREATE: a CREATE that stages no entry takes the platform's seed entry, so stage it whenever the
+setup names one. There is no level-source key: the level a level trigger rests at is DERIVED from
+the trigger and the trade's direction, never named. There is no confirm-timeframe 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 completed bar is read on the closed basis — every one-close
@@ -259,7 +266,7 @@ condition resolves on that bar and the scorecard reads its close — and a readi
 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
 from that close. A fourth value, `AT_SIGNAL`, is readable on strategies authored before this contract
-and is REFUSED on every save; there is no live-reading entry to author.
+and is REFUSED on every stage and save; there is no live-reading entry to author.
 
 - `ON_CANDLE_CLOSE` — the entry is taken AT the qualifying close, at market.
 - `STOP_THROUGH_LEVEL` — at the qualifying close a TRIGGER order rests past the Donchian channel's
@@ -285,10 +292,11 @@ correct side of the mark when the order is placed — a buy stop above it, a buy
 mirror for a sell — or the entry is refused rather than filled at the market; there is no limit on
 how far from the mark a level may rest.
 
-**The legality matrix runs one way.** All three keys are always present, so the question is never
-"is it set" but "is it set to something that MEANS anything under this trigger".
-`levelOffsetAtrMultiple` ≠ 0 and `validForBars` ≠ 4 are refused under a non-level trigger. Leave a
-dial at its inert value rather than setting one the platform will ignore.
+**The trigger decides the shape, so there is no inert dial to leave.** Under `ON_CANDLE_CLOSE` the
+two parameters do not exist on the input — the server stores its seed values for them — while a
+read (`get_strategy`) still shows all three keys. Switching a level trigger back to
+`ON_CANDLE_CLOSE` is staging `{ "trigger": "ON_CANDLE_CLOSE" }` alone; never copy the read's
+parameters back beside it.
 
 ## Report sections
 
@@ -301,7 +309,9 @@ author's value silently. On a CREATE, omit `sectionKey` — it is derived from t
 ## Signal rules
 
 `{ signalId, allocation, required, params }` — one entry per signal you want scoring.
-`allocation` is the tier (0–3) and `params` replaces canonical defaults only when present.
+`allocation` is the tier (0–3) and `params` replaces canonical defaults only when present. Staged
+into the draft's SIGNAL_RULES axis, every row is complete — `allocation` and `required` on each —
+and replaces the drafted row for its signal while every other row is kept.
 
 ## Signal weights and gate math
 
@@ -315,7 +325,7 @@ Weights are relative — build a pyramid: 1–2 Critical (thesis, usually `requi
 Important (independent confirmation, different modules), 1–3 Normal (context), rest Off so
 noise cannot dilute the average. Gate check: with 3/2/2/1 weights, Critical + one Important at
 score 1.0 → (3+2)/8 = 0.625, so a 0.6 gate means "thesis plus one confirmation".
-`simulate_aggregate_score` does this arithmetic from compiled values at review time.
+`simulate_aggregate_score` does this arithmetic from the draft's values at review time.
 `required: true` counts the signal toward `minRequiredCount` when triggered; at
 `allocation: 0` it is rejected (contract 34). `params` replace canonical defaults only when
 present — read `get_strategy_signal_definition({ signalId, timeframe })` before tuning (e.g.

package/skills/battlegrid-strategy-examples/references/playbooks.md

@@ -103,8 +103,8 @@ giveback 30 buffer 0.15; timeDecay ON aggressive (45/15, 15→60, stale 30).
 
 Discover → confirm headers (`get_strategy_column_contract`, or one `preview_strategy_report`
 whose `conditionColumns` lists every addressable header with operators and vocabulary) →
-calibrate literals against the previewed live values → compile once → review the compiled
-scorecard, condition outcomes, verdict tally, and `marketReadMarkers` (fix `unknown` /
-`ambiguous` markers) → apply per the strategy-authoring flow. Coin selection is call context,
-not strategy state: explicit tickers for focused work, `ranked` (with an optional category) for
-scanning books.
+calibrate literals against the previewed live values → stage the draft and fix what its
+diagnostics name → read it back and review the drafted rule rows, then the draft's own report
+preview — condition outcomes, verdict tally, and `marketReadMarkers` (fix `unknown` / `ambiguous`
+markers) → commit per the strategy-authoring flow. Coin selection is call context, not strategy
+state: explicit tickers for focused work, `ranked` (with an optional category) for scanning books.

package/skills/battlegrid-strategy-examples/references/recipes.md

@@ -5,7 +5,7 @@ coin-selection and discovery shapes an author reaches for while writing a payloa
 
 **Shapes are binding. Tokens are illustrations** — re-discover every metric, transform and parameter
 against the live tools (`list_strategy_categories`, `list_strategy_vocabulary`,
-`get_metric_construction_hints`, `get_strategy_column_contract`) before compiling. A recipe is a
+`get_metric_construction_hints`, `get_strategy_column_contract`) before staging. A recipe is a
 worked shape, never a substitute for discovery.
 
 Read `## Header grammar` and `## Conditions` in the skill body first: how a column's header is
@@ -89,7 +89,8 @@ thing a crowded-positioning playbook trades against.
 
 ## Coin selection
 
-`coinSelection` is required on every compile and is discriminated on `mode`:
+`coinSelection` is required on every `preview_strategy_report` call — it is the cohort the preview
+renders over, never strategy state — and is discriminated on `mode`:
 
 ```json
 { "mode": "ranked", "limit": 25, "category": "DEFI" }