@battlegrid/mcp-server 32.0.11 → 32.0.16

package/README.md

@@ -38,6 +38,27 @@ 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 — v122 (only an officer's own turn records a review)
+
+**Breaking at v122: two officer review tools leave the catalog you discover.** v122 is the contract on top of v121.
+Reconnect the proxy, or restart it, so discovery reads the new catalog.
+
+### Removed tools — something you called is gone
+
+- **`get_officer_review_context` and `submit_officer_review`** are published only to a Strategy Officer's own turn,
+  which runs on BattleGrid's server. A call naming either through this proxy is answered as an unknown tool. A second
+  opinion on an officer's review is your own reading, never a record.
+
+### Added tool and fields
+
+- **`run_officer({ officerId })`** runs one of your officers now, as its schedule would, and answers before any
+  review starts: `QUEUED` with `agentCount`, `NOTHING_TO_REVIEW` (nothing queued or billed) or `ALREADY_QUEUED`. It
+  follows `commanderAccess` from `get_account_state`, not `llmAccess`.
+- **`pendingRun`** on each officer `list_officers` and `get_officer` serve: `{ state, queuedAt }` while a run is
+  waiting or running, otherwise null. **`presets`** on `list_officers`: the starting points a new officer is
+  staged from.
+- The **Officers** workflow routes from `list_officers` to the `battlegrid-officers` skill.
+
 ## Contract history — v120 (the readiness ladder is three milestones)
 
 **Breaking at v120: `get_onboarding_requirements` reshapes its rungs and re-specifies its counts.** v120 is the
@@ -3903,12 +3924,12 @@ Install the BattleGrid skills for AI agent instructions:
 npx skills add playbattlegrid/battlegrid-mcp
 ```
 
-Nine skills ship from this repo, all inside the npm tarball (`SKILL.md`, `skills/`).
+The skills ship from this repo, all inside the npm tarball (`SKILL.md`, `skills/`).
 
 **`battlegrid`** (repo root) is the connection skill and is authored here: how to connect, the
 `{ account, request }` envelope, the two scopes, and where to go for everything else.
 
-The nine `skills/battlegrid-*` are **exported from BattleGrid's server repository** — they are the
+The `skills/battlegrid-*` are **exported from BattleGrid's server repository** — they are the
 same instructions BattleGrid's own in-app Commander runs on, which is why they name the same tools
 you reach over MCP:
 
@@ -3916,6 +3937,7 @@ you reach over MCP:
 |---|---|
 | `battlegrid-agent-management` | Commission and govern intelligence agents: interview and create one against a committed strategy and an approved model, change configuration and risk limits, rebind, halt, resume, archive, and act on live positions |
 | `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-officers` | Set up and govern Strategy Officers: create or change one through its draft, run one now, read when each runs and what is waiting, and apply, push or dismiss the proposals its reviews carry — never writing a review |
 | `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, stage it into the strategy's draft, review the diff, diagnostics and impact, commit only on confirmation. Also fork, tune, restore, archive, preview |

package/SKILL.md

@@ -7,10 +7,10 @@ description: MCP skill for BattleGrid — play crypto prediction games (Market G
 
 BattleGrid is a real-time cryptocurrency prediction gaming and trading platform. This MCP server gives AI agents access to play games, author trading strategies, and run strategy-bound intelligence agents.
 
-## The other nine skills
+## The other skills
 
 This skill covers **connection**: how to reach BattleGrid, the `account` argument, and what each scope
-grants. Everything about *using* the platform lives in the nine skills installed beside it, exported
+grants. Everything about *using* the platform lives in the skills installed beside it, exported
 from BattleGrid's own server so they name exactly the tools you reach here:
 
 | For | Activate |
@@ -24,8 +24,13 @@ from BattleGrid's own server so they name exactly the tools you reach here:
 | Reading your own position, agents, and open trades | `battlegrid-trade-analysis` |
 | Finding and staging a trade for one of your agents — scan its coins, propose on one, approve or decline on your word | `battlegrid-trade-proposal` |
 | Working out why an agent has not traded or has stopped | `battlegrid-strategy-doctor` |
+| Setting up a Strategy Officer, running it now, and applying, pushing or dismissing what it proposes | `battlegrid-officers` |
 
-Those nine carry the working arcs and the exact contracts. What follows here is the minimum needed
+`battlegrid-strategy-officer` is not one to activate: it is the review procedure a Strategy Officer runs on
+BattleGrid's own server, whose review tools no external client is published, and the next skills export removes it.
+To work with officers, activate `battlegrid-officers`.
+
+Those skills carry the working arcs and the exact contracts. What follows here is the minimum needed
 to connect and to know which one to open.
 
 ## Discover the live surface first

package/dist/index.d.ts

@@ -47,7 +47,7 @@ import { Client, StreamableHTTPClientTransport } from '@modelcontextprotocol/cli
  * 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 = "32.0.11";
+export declare const PACKAGE_VERSION = "32.0.16";
 export declare const DEFAULT_URL = "https://mcp.battlegrid.trade/mcp";
 export interface EnvConfig {
     apiKeys: string[];

package/dist/index.js

@@ -49,7 +49,7 @@ import { Client, SdkHttpError, StreamableHTTPClientTransport } from '@modelconte
  * 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 = '32.0.11';
+export const PACKAGE_VERSION = '32.0.16';
 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": "32.0.11",
+  "version": "32.0.16",
   "description": "BattleGrid MCP server — play crypto prediction games from AI agents",
   "type": "module",
   "main": "dist/index.js",

package/skills/EXPORT.json

@@ -1,22 +1,26 @@
 {
   "generator": "battlegrid-app/server/scripts/export-mcp-skills.mjs",
-  "contractVersion": "113.0.0",
+  "contractVersion": "121.2.0",
   "files": {
-    "battlegrid-agent-management/SKILL.md": "9dc151c32c3578d06e8895c6752d7a64959bff6a6681a01d62ab65e1ea1590d1",
+    "battlegrid-agent-management/SKILL.md": "09e5cbf241e2ba8f672e8292d40b3a50ee875f9b838003b95ee51928c5dbdf2e",
     "battlegrid-agent-management/references/agent-stage-examples.md": "dffcc353d61dfc7b5bb6a2b3077fc6bf8c760a34c287cafb3b59b99306f24195",
+    "battlegrid-agent-management/references/officer-stage-examples.md": "a5a42792a8aa8f4af8cbf424d7c9aadbaa23df382ce17691a40a8d0e5447db63",
     "battlegrid-arena-play/SKILL.md": "2e37970a66b8738ffbc445a23da90651c1f41b56ce4eef551582ab123517ef74",
     "battlegrid-arena-play/references/entry-stage-examples.md": "0223f3743171ff213e943789d27590b2f65648398e85e10cd24938d5eb6af665",
     "battlegrid-market-analysis/SKILL.md": "fcbe98e30e1edce39bb170c224cdf20181934f62b5f3a26b293787c70eeb6229",
-    "battlegrid-radar-deployment/SKILL.md": "dfe8f354ac3dd426eedeac1ec080ac518e9c8cbfefdd26036afa61f80c08295c",
+    "battlegrid-radar-deployment/SKILL.md": "cf6664f51f92d40acce21a46f4fb078d9afe46c99c4f4b603bf002e73d4c5a23",
     "battlegrid-radar-deployment/references/arena-stage-examples.md": "d27cfed1f4663f267c4a7ecebe4a6e65a450fc74bd14ce8987fb61af5bbf2ca5",
-    "battlegrid-radar-deployment/references/radar-stage-examples.md": "e3805f5c1b243135a7f25fb3a8cc6093dd242f8ad67b7e6b242bbdefa58a0735",
+    "battlegrid-radar-deployment/references/radar-stage-examples.md": "13fc3f55d91d3da9754e1ed7fb27493b7b7ba4d40a6a7e8d1ee0365f90ea10de",
     "battlegrid-strategy-authoring/SKILL.md": "39cfa46b1f640e6800edb7e85a8f2c4b6b8786cddf71bb8244d172a44fc11d75",
     "battlegrid-strategy-authoring/references/strategy-stage-examples.md": "f10ecdc91f3660a708eee7a7bacefce2acbb46c9cf7e0ac1454bd54f839f39fd",
     "battlegrid-strategy-doctor/SKILL.md": "e34e055b0cc9b355bc1adeb5d49d464eaa0756ca3f48dc89ca2ccdda94e1311f",
-    "battlegrid-strategy-examples/SKILL.md": "597ddacdfc00955fcfd5a1afcc40b5ea72a0f658acbbebc8264afeecc46d2306",
-    "battlegrid-strategy-examples/references/playbooks.md": "2309eb7e8324f563c5b1b51e05da931b37c542484135a2be749eff6ef78aa40f",
-    "battlegrid-strategy-examples/references/recipes.md": "635e03d163100f6de37cda1f6cc12928d5d36aa0ea883bf44fc72f17cbf3e98e",
+    "battlegrid-strategy-examples/SKILL.md": "5e0d3244ed0592b8af933c0925346b6bd3bbaeef6c7acb35329925a026e7cd05",
+    "battlegrid-strategy-examples/references/playbooks.md": "275352be43652ca0fd36a35981ea7ffcfabdc4f9b33293826656ee500d3795e9",
+    "battlegrid-strategy-examples/references/recipes.md": "806aae0b4842408f6e6ed3e108293073f4f31d1c27fa419ad57df9e1134f23e7",
     "battlegrid-strategy-examples/references/tradingview-ports.md": "9eaa926cbe8606c6a09f91007a0606042afbfdc50173a5b13ae9336d2e9e9b08",
+    "battlegrid-strategy-officer/SKILL.md": "2c28ec4afa632b0f69b84b6d309f77d811d0d7452c1dbebce011b22044563780",
+    "battlegrid-strategy-officer/references/figures.md": "e9591e4f4edb9fc54066527ecd862aeef18badc96eaa924f14bd7da326eab541",
+    "battlegrid-strategy-officer/references/proposal-shapes.md": "20c9acd2b20e7920ed7ac9aa096604d91625b1d5b6438aa1ded7f6b63ecc9a22",
     "battlegrid-trade-analysis/SKILL.md": "3f927b4f9796178526fa1673a2043c5f14358c39aa955de33192ea58641f18fb",
     "battlegrid-trade-proposal/SKILL.md": "e761fc6bddc0d1db79fcb90046d03a18439562c8658de726ec286830edd6369b"
   }

package/skills/battlegrid-agent-management/SKILL.md

@@ -37,7 +37,7 @@ step named beside it before doing anything else.
 which strategy an agent is bound to is the agent's own STRATEGY_BINDING axis (step 4).
 `stage_strategy_draft`, `commit_strategy_draft`, `discard_strategy_draft`, `fork_strategy`,
 `archive_strategy`, `restore_strategy`, `save_report_section` and `remove_saved_report_section` are
-**not**, even though activating this skill makes them visible in the conversation.
+**not**, even though this skill's tools put them in view in the conversation.
 
 When the work is a strategy change, activate `strategy-authoring` and let its arc run — its
 evidence, spec-lock, stage-review and confirm rules bind from that point. Do not drive a strategy
@@ -266,6 +266,40 @@ These tools carry no consent gate on either door: they are ownership-gated and b
 in chat and through an external MCP client. Your confirm is interaction, never authorization —
 never describe it as a permission check, and never add one of your own.
 
+### 8. Strategy Officers: configure one like an agent
+
+A Strategy Officer is a platform review the player schedules: on its hour it reads each in-scope agent's
+record and records at most one proposal per agent for the player to apply or dismiss. It writes no draft
+and commits nothing. Setting one up is configuration, and every run it schedules is billed to the
+player's LLM credit — so it goes through its own draft, exactly as an agent does.
+
+- **Read first.** `list_officers` for the roster (each officer's schedule, scope, last and next run),
+  `list_officer_drafts` for setups part-way through, `get_officer_draft` for one draft.
+- **Create.** `stage_officer_draft` with **no** `officerId` and `draftVersion: 0` mints a new create
+  draft; every later call names the minted id. Stage only what the player asked for — every axis the
+  draft does not hold starts at its default (name "Strategy Officer", the catalog's default model, no
+  instructions, `DAILY` at 03:00 UTC, all active agents, all three levers). "Add an officer that
+  reviews my agents every morning at six and focuses on stops" is `NAME`, `SCHEDULE`
+  `{ cadence: 'DAILY', hourUtc: 6, weekdayUtc: null }` and `INSTRUCTIONS` `{ focusText }` in the
+  player's words — and ask which timezone "six" means before converting it to a UTC hour. Worked
+  inputs: `references/officer-stage-examples.md`.
+- **Presets are starting points, staged as ordinary axes.** When the player names one — an exits
+  officer (levers `strategy`), a regime officer (`radar-deployment`), a rails officer (`agent`) or a
+  general one (all three) — stage its `NAME`, `INSTRUCTIONS` and `SCOPE`; the officer remembers no
+  preset.
+- **Axes are whole.** `SCHEDULE` carries `cadence`, `hourUtc` and `weekdayUtc` (`0` Sunday … `6`
+  Saturday, for `WEEKLY` only, otherwise null); `SCOPE` carries both `agents` (`'ALL'` or agent ids
+  from `list_intelligence_agents`) and `levers`. `INSTRUCTIONS` are the player's brief in their own
+  words: at most 2,000 characters, naming no tool and no id — the commit refuses either.
+- **Show, then commit on the player's word.** Read `get_officer_draft` and show the diff, the
+  diagnostics and the impact — `nextRunAt` is when it first runs, and a create's `admission` says
+  how many officers the player holds against the limit and how many more it admits (`officersRemaining`). Commit with `commit_officer_draft` naming
+  exactly the `draftVersion` and `committedRevision` the read returned, and only when the player says
+  so. A cadence of `OFF` keeps the setup and runs nothing.
+- An officer's reviews and their Apply, Push and Dismiss live on the Officers page's inbox; they are not
+  this flow's. In the app, the player sets an officer up in its own console, where this conversation may be
+  docked beside the form — stage into the officer it is scoped to.
+
 ## When a write's outcome is unknown
 
 An interrupted or timed-out write may have landed.

package/skills/battlegrid-agent-management/references/officer-stage-examples.md

@@ -0,0 +1,77 @@
+# Strategy Officer stage examples
+
+Complete `stage_officer_draft` inputs. Each is checked in CI against the live stage schema and the setup rules a
+commit applies without a repository read. Its shape is current.
+
+Every `<UPPER_SNAKE>` value is a placeholder. Replace it with the id a read returned:
+
+- `<OFFICER_ID>` comes from `list_officers` or the draft you are editing.
+- `<AGENT_ID>` and `<OTHER_AGENT_ID>` come from `list_intelligence_agents`.
+- `<MODEL_ID>` is the row's `modelId` from `list_approved_models`.
+
+Never send a placeholder as written, and never invent an id. `draftVersion` is the version `get_officer_draft`
+returned: 0 when there was no draft, and for a new create draft. Each axis you send is written whole, and an axis
+you omit keeps the value the draft already has, the officer's current value, or for a new officer its default.
+
+## Add an officer that reviews every morning at six and focuses on stops
+
+Omit `officerId` to open a create draft. The response carries the minted id, which every later call names. Convert
+the player's "six" to a UTC hour only after asking which timezone they mean; this example is 06:00 UTC.
+
+```json stage_officer_draft
+{
+  "draftVersion": 0,
+  "axes": {
+    "NAME": { "name": "Morning Stops Officer" },
+    "SCHEDULE": { "cadence": "DAILY", "hourUtc": 6, "weekdayUtc": null },
+    "INSTRUCTIONS": { "focusText": "Focus on stops: premature stop-outs and what price did after each exit." }
+  }
+}
+```
+
+## Start from the regime preset, weekly on Monday
+
+A preset is staged as ordinary axes: its name, its brief and its scope.
+
+```json stage_officer_draft
+{
+  "draftVersion": 0,
+  "axes": {
+    "NAME": { "name": "Regime Officer" },
+    "INSTRUCTIONS": {
+      "focusText": "Read the record by the regime each decision was scored against. Where a regime with a ready sample loses and the others win, propose a regime condition on the Radar rule that routes the agent."
+    },
+    "SCOPE": { "agents": "ALL", "levers": ["radar-deployment"] },
+    "SCHEDULE": { "cadence": "WEEKLY", "hourUtc": 7, "weekdayUtc": 1 }
+  }
+}
+```
+
+## Narrow an existing officer to two agents and the rails lever
+
+SCOPE is sent whole: both the agents and the levers, even when only one changes.
+
+```json stage_officer_draft
+{
+  "officerId": "<OFFICER_ID>",
+  "draftVersion": 0,
+  "axes": {
+    "SCOPE": { "agents": ["<AGENT_ID>", "<OTHER_AGENT_ID>"], "levers": ["agent"] }
+  }
+}
+```
+
+## Change the model and pause the officer
+
+A cadence of OFF keeps the setup and runs nothing.
+
+```json stage_officer_draft
+{
+  "officerId": "<OFFICER_ID>",
+  "draftVersion": 0,
+  "axes": {
+    "MODEL": { "modelId": "<MODEL_ID>" },
+    "SCHEDULE": { "cadence": "OFF", "hourUtc": 3, "weekdayUtc": null }
+  }
+}
+```

package/skills/battlegrid-radar-deployment/SKILL.md

@@ -107,7 +107,12 @@ is test-routing a regime. Never carry a fact from a radar conversation into it,
    Do not confirm a draft whose diagnostics carry an error: stage a fix.
 3. `preview_radar_resolution({ coinId, request: { kind: "DRAFT", draftVersion } })` at the version that
    read returned. It composes the draft over the deployed policy **exactly as the commit will write it**,
-   and refuses a draft no longer at that version with `DRAFT_VERSION_MOVED`.
+   and refuses a draft no longer at that version with `DRAFT_VERSION_MOVED`. Its `ruleCloseCoverage`
+   counts, for each hours rule, the closes of its agent's `strategyTimeframe` bar the rule's hours let
+   it decide through `windowEndAt`. Before asking the player to commit, name every rule whose
+   `decidableCloses` is 0: its agent's timeframe, the served `windowEndAt`, and that it is this rule's
+   hours alone that hold no close — not the agent, which still decides closes it is on duty for through
+   another rule or the default. Never tell the player the agent will not trade.
 
 To try a slot set without touching the draft, preview `{ kind: "SLOTS", slots }` — it resolves
 explicit slots and nothing can commit it.
@@ -122,6 +127,19 @@ from what the player asked for:
 | only in named hours and days | a rule with an hours condition |
 | in named regimes during named hours | a rule with one hours condition and one regime condition |
 
+When the player names an exchange session — New York, the New York open, London, the London open,
+the London–New York overlap, Tokyo, the Tokyo open — call `get_radar_market_hours` and stage that session's `hours`
+exactly as served, merged with any other session they name; never work session hours out yourself,
+because New York and London shift with daylight saving on their own dates and the overlap changes
+shape on each of those dates. The three opens are one hour wide, so they suit agents on 1h bars or
+faster. The days stay the player's choice. Tell the player the staged hours are UTC, that an hour is
+on duty from :00 through :59, and, when the session carries a `nextShift`, the date its hours change
+and that the rule keeps the hours it was given.
+
+Session closes are not presets. Asked for "the New York close" or any other session close, stage only
+the hours the player names, or raise flattening before the session ends as a separate idea — never
+work a close window out yourself.
+
 When the ask maps to no single row, or a refusal rules out the construction the player asked for,
 ask the player which construction they mean, naming the rows that fit — never stage one they did not
 choose. Complete stage payloads for every row are in `references/radar-stage-examples.md`.
@@ -352,8 +370,9 @@ Four reads, cheapest first. Stop as soon as the player's question is answered.
    refused it and nothing was traded. It is the only history of not-qualifying closes: the journal
    writes no row for one, and `resolvesNow` keeps only each agent's last decision — the one
    `reading.lastClose` (step 1) carries; this read holds every decision before it. Narrow with
-   `agentId`; page back by passing the response's `nextBefore` as `before`, and stop when
-   `nextBefore` is null — that is the end of the history. A bar still
+   `agentId`. Each record carries its whole evidence, so keep `limit` small; page back by passing
+   the response's `nextCursor` as `cursor`, and stop when `nextCursor` is null — that is the end of
+   the history. A bar still
    waiting inside its window has no record yet (`resolvesNow` shows its `closeDecision.state` as
    `DEFERRED`), and records are kept 90 days.
 4. **`get_radar_activity`** only for what steps 2 and 3 cannot do: more rows than its ten, a

package/skills/battlegrid-radar-deployment/references/radar-stage-examples.md

@@ -56,7 +56,10 @@ regime condition is the regime-reading floor, and must be a level one of the sel
 
 ## On duty only in named hours and days
 
-Hours are UTC, 0–23. Days run 0 (Sunday) to 6. Each is listed once.
+Hours are UTC, 0–23. Days run 0 (Sunday) to 6. Each is listed once. For a named exchange session —
+including the London and Tokyo opens and the London–New York overlap — stage the `hours` `get_radar_market_hours`
+serves for it rather than a set of your own; the example below is a shape, not a session. No session
+close is served: a close is staged only as hours the player names.
 
 ```json stage_radar_deployment_draft
 {

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

@@ -78,10 +78,10 @@ add. Either way you never invent one. To section-qualify a duplicated header, re
 `CONDITION_COLUMN_AMBIGUOUS` refusal offers.
 
 **Event columns print only on their event.** `MACDhist_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
+value on the crossing bar and are null on every other one, and a null reads FALSE. Use an event
 column as a TRIGGER inside a carrier, and pair it with a persistent state — a spread sign,
-`MAalign` — for regime. A condition that treats an event column as a standing state is unresolved on
-nearly every bar, which is a gate that never gates.
+`MAalign` — for regime. A condition that treats an event column as a standing state reads FALSE on
+nearly every bar, so it is TRUE only on the crossing bar itself.
 
 **The previous-session levels are TIMELESS.** `PDH`, `PDL`, `PDO` and the seven floor pivots
 (`pivotP`, `pivotR1`–`R3`, `pivotS1`–`S3`) read the session profile, not a candle rung, so they take
@@ -228,9 +228,12 @@ column selecting Developing above the strategy timeframe (`CONDITION_VERDICT_REA
 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.
+bar moves at all, such as a published regime label or a funding rate — admits a verdict at every
+decision, because a decision reads the completed strategy bar and a level is compared against that
+bar's close. A change over a horizon above the strategy timeframe — `chg4h` or `chg24h` on a `1h`
+strategy, and `oiRegime`, which reads the `1h` change, below `1h` — is a developing read whatever its
+selector: its bar is still in progress at the close, so it carries no verdict. Read a horizon at or
+below the strategy timeframe instead, or a Confirmed `CLOSE_CHANGE` on the higher timeframe.
 
 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.
@@ -266,10 +269,11 @@ the served domain is refused (`CONDITION_HOLD_ILLEGAL`, the domain in `allowedDo
 a header admits only Once:
 
 - `NOT_REWINDABLE` — the value is stored for the current bar only (session and universe scalars,
-  ranks, zone entities, enrichment metrics, published rolling changes). **Worked liquidity floor:**
+  ranks, zone entities, enrichment metrics, a change at or below the strategy timeframe). **Worked liquidity floor:**
   `LIQUID_FLOOR` holds Once because `vol24hUsd` is a bundle scalar.
-- `DEVELOPING` — the column reads the bar still forming. **Developing columns cannot be held**; set
-  the column Confirmed to count closes.
+- `DEVELOPING` — the column reads a bar still forming: a Developing candle column above the strategy
+  timeframe, or a change over a horizon above it. **Developing columns cannot be held**; set a candle
+  column Confirmed to count closes, or read a change at or below the strategy timeframe.
 - `OFFSET` — the column already reads an earlier bar; remove the offset to count closes.
 - `BAR_STATE` — the header describes only the bar being decided.
 - `HISTORY` — not enough history is stored on that timeframe to count more than one close.
@@ -300,8 +304,10 @@ anchor's own close — so Developing there is legal and changes no decision. A c
 developing bar is single-frame: its clause holds Once (a Developing column cannot be held), it
 carries no verdict and it cannot be an exit rule. One exception overrides both the stored value and the default: a column reading a metric with
 no live value (itself, or a `spread` operand) reads completed bars at every rung, because the forming
-bar publishes nothing for it. The resolved answer for a column is served on
-`effectiveParameters.bars`, and it states that exception.
+bar publishes nothing for it. A change (`chg5m` … `chg24h`, and `oiRegime`'s `1h` change) carries its
+horizon in the metric, so above the strategy timeframe it is Developing at every rung and under every
+selector. The resolved answer for a column is served on `effectiveParameters.bars`, and it states both
+exceptions.
 
 **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

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

@@ -36,11 +36,14 @@ anything failing {LIQUID_FLOOR}."
 Custom `Positioning`: `FUNDING_RATE value`→`rate`, `aggregate w24`→`rate_mean24`,
 `FUNDING_ANN value`→`ann`, `OI_CHG value`→`oiChg`, `OI_PX_REGIME value`→`oiRegime` (vocab:
 new longs / new shorts / short covering / long liquidation), `MARK spread ORACLE`→
-`mark_oracle_spread`, `RSI14 value`, `CHG_24H value`→`chg24h`; plus `includeCvd`. Conditions:
+`mark_oracle_spread`, `RSI14 value`, `CLOSE_CHANGE value @ {abs: 1d}`→`closeChg_1d` (Confirmed, the
+default above the strategy timeframe); plus `includeCvd`. Conditions:
 `NO_LIQUIDATION_TAPE` required NOT-veto (`NOT [oiRegime is "long liquidation"]`);
 `CROWDED_LONGS` building block (`ann gte 25` + `oiChg gte 3` + `oiRegime is "new longs"`);
-`FADE_SHORT` verdict DOWN (ref + `RSI14 gte 65` + `chg24h gte 5`); mirrored `SQUEEZED_SHORTS`
-/ `SQUEEZE_LONG` verdict UP. Levels 1.0–2.5 ATR, RR 1.5, ATR floor 0.5%. PM: BE 0.8R, no trail, timeDecay ON (120/60, 10→40, stale 25).
+`FADE_SHORT` verdict DOWN (ref + `RSI14 gte 65` + `closeChg_1d gte 5`); mirrored `SQUEEZED_SHORTS`
+/ `SQUEEZE_LONG` verdict UP (`closeChg_1d lte -5`). The confirmation is the prior completed UTC day's
+move, not today's: today's (`chg24h`) is a 1d bar still in progress at every 1h close, a developing
+read no verdict may carry. Levels 1.0–2.5 ATR, RR 1.5, ATR floor 0.5%. PM: BE 0.8R, no trail, timeDecay ON (120/60, 10→40, stale 25).
 
 ### 3 · Relative-Strength Rotation with a Benchmark Gate — 4h cross-sectional
 

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

@@ -46,7 +46,7 @@ and is null otherwise:
 
 An event column is a trigger inside a carrier, never a standing state; pair it with a persistent
 state for regime. The skill body's `## Header grammar` states that rule and is the authority on it —
-a condition that reads a `crossDetect` column as a state is UNRESOLVED on nearly every bar.
+a condition that reads a `crossDetect` column as a state reads FALSE on nearly every bar, because a null reads FALSE.
 
 ## Board-relative rank recipes
 

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

@@ -0,0 +1,226 @@
+---
+name: battlegrid-strategy-officer
+description: Run one Strategy Officer's review of one agent — read the officer's own setup, the agent's served review figures and the current market read, cite every finding to a named figure with its readiness and population, choose at most one lever inside the officer's scope, and record the review with a complete proposal for the owner to apply, push or dismiss, or with no lever and the reason. It never writes a draft. Activate whenever a turn opens with a Strategy Officer brief naming an officer and an agent, or when the player asks one of their Strategy Officers to review an agent now.
+---
+
+# Strategy Officer
+
+You are one of the owner's Strategy Officers, reviewing one of their agents against its own record. The
+owner set you up with a name, a brief, a schedule and a scope; the brief opening this turn names you and the
+agent. Your job is to say, from the figures the platform serves, where this playbook wins and where it loses,
+and — when a ready figure supports it — to propose the one change that would move that figure most.
+
+Everything you do here is a **read**, and one record. You read the officer setup, the agent's record and the
+market; you write exactly one thing, the review, through `submit_officer_review`. You have no draft tool and
+you do not need one: a proposal lives on the review record, and the owner's working copy changes only when
+the owner presses Push or Apply on the card. Nothing you submit reaches a live strategy, agent or Radar
+deployment on its own.
+
+Most runs are scheduled. **No one is reading this turn as it happens**, and no one will answer a question:
+the review record is your whole output.
+
+## The six failures this flow exists to prevent
+
+1. **Diagnosing from prose.** *Cue: reaching for a journal entry, a thought log line or the agent's overlay
+   text to explain a result.* The figures exist; cite them. → step 3.
+2. **A rate from a handful.** *Cue: a percentage over three trades.* A figure that reads `INSUFFICIENT_DATA`
+   has no rate, mean or median to state, and no lever rests on it. → step 3.
+3. **A lever from the market alone.** *Cue: "the market is volatile now, so…".* The market read places a
+   finding in context; every lever rests on a figure of the agent's own record. → step 4.
+4. **Two levers, or half an axis.** *Cue: two good ideas, or one changed field sent alone.* One lever per run,
+   one axis, sent whole. → step 5.
+5. **A private write path.** *Cue: wanting to "just stage it".* You submit a proposal; the owner pushes or
+   applies it. → the negatives.
+6. **Ending on a question.** *Cue: "shall I…?".* A scheduled run has no one to answer. → step 7.
+
+## Sequence
+
+### 0. When the player asks in the conversation
+
+A scheduled brief names the officer and the agent. When the player asks instead ("have my officer review my
+agent"), resolve both first: `list_officers` for the officer — none means telling them to add one from the
+Officers page and stopping there; one is the officer; several, take the one the ask names, else the one
+whose `scope.agents` covers the agent, else ask which. The agent is the one the ask names, read with
+`list_intelligence_agents`. Then run the sequence below exactly as a scheduled run would.
+
+### 1. Read your own setup first
+
+`get_officer` with the officer id the brief names. Its `focusText` is the owner's standing brief for every
+review you run — "weigh exits over entries" decides which figures you lead with and which lever you prefer
+when two are supported. Its `scope` bounds you: `scope.levers` is the set of draft kinds you may propose for
+(`strategy`, `agent`, `radar-deployment`), and `scope.agents` is `ALL` or the agent ids you review. An agent
+outside `scope.agents` gets a review with lever `NONE`, reason `AGENT_OUT_OF_SCOPE`, and nothing else.
+
+The brief carries the same instructions verbatim; where the two differ, the setup `get_officer` returns is
+the current one.
+
+### 2. Read the review context — the guards' inputs
+
+`get_officer_review_context` with the officer id and the agent id. It serves:
+
+- `lastReviewAt` — your latest review of this agent, or null when you never reviewed it;
+- `closedDecisionsSince` — the agent's closed decisions since then. **Zero means nothing new to review**:
+  submit lever `NONE`, reason `NO_NEW_DECISIONS`, with one finding that says so, and stop;
+- `strategyId` and `strategyOwnedByOwner` — **false means the owner did not author the strategy the agent
+  runs** (a public or library strategy). There is no strategy lever for this agent: see step 5;
+- `targets` — the lever targets your scope allows, each with its `kind`, its `targetId` (the strategy id,
+  the agent id, or the coin id a Radar deployment is keyed by) and the `committedRevision` a proposal names
+  as its `baseRevision`.
+
+### 3. Read the record, and state findings as figures
+
+Five reads, every one keyed by the agent id:
+
+- **`get_agent_review_analytics`** — the review read: the `overall` figure set, and the same figures sliced
+  by the regime recorded at decision (`regime`), by UTC hour (`hourOfDay`) and weekday (`weekday`), by coin
+  (`coin`, with fees), by cited condition (`condition`), LLM spend against result (`llm`), the rail refusals
+  (`railRefusals`) and the current halt (`halt`).
+- **`get_agent_decision_quality`** — entries versus skips at each horizon, exit quality (premature stops,
+  what price did after the exit), the verdict mix and exit efficiency.
+- **`get_agent_cost_economics`** — realized gross, fees and net per close outcome, and the winners costs
+  turned into losers.
+- **`get_agent_entry_discipline`** — what confirmation cost (the confirmation tax), fast stop-outs and
+  adverse-first excursions. It takes a window: pass the review read's `windowStartAt` and `windowEndAt`.
+- **`get_agent_conviction_calibration`** — win rate by conviction band, so a band that wins no more often than
+  a lower one reads as one.
+
+Then state each finding as a **named figure** from the closed list in `references/figures.md`: its figure id,
+the slice it was read over (a regime, an hour, a weekday, a coin, a cited condition, or the whole window), the
+value exactly as served with its readiness and population, and one sentence in the figure's display
+vocabulary. "Stopped too early in 9 of 20 forced exits (45%)", not "the stops are too tight". A regime is named
+by its display name ("Bear Ranging"), never its stored value; a verdict, a close outcome, a rail refusal and a
+halt reason the same way.
+
+- **Readiness is the gate.** A figure reading `INSUFFICIENT_DATA` is reported as its counts and "too few to
+  report a rate", with its sample size — never as a rate, a mean, a median or a trend, and never as the
+  ground for a lever.
+- **Counts and sums are observations.** Decisions, closed trades, realized net, fees and LLM spend are
+  reportable at any sample; a rate over the same rows is not.
+- **A mark is quoted as a mark.** A `STOPPED_EARLY` verdict means the original target printed within 24 hours
+  of the stop. Say that; never state a profit the trade "would have made". The skip side of entries-versus-skips
+  is a recorded forward return, not money the agent left on the table.
+- **Never compute a figure the reads do not serve.** Quote served values; compare two served values only by
+  naming both.
+
+If a read fails or returns nothing for what you need, that figure is **UNDETERMINED**: name the read you could
+not use, and lean on nothing from it. Never turn an absent read into a clean finding.
+
+### 4. Place the record against the current market
+
+Read the market for the agent's main coins — the coin rows of the review read with the most decisions:
+`get_regime_snapshot` for each, at the agent's regime timeframe (on `get_intelligence_agent`), and
+`get_market_context` for the context the agent itself reads. Use it to place a finding: "this playbook's
+Bear Ranging record is the losing one, and BTC reads Bear Ranging now". **A market read is context, never a
+lever**: with no ready figure of the agent's own record behind it, the review records the market context and
+lever `NONE`, reason `INSUFFICIENT_DATA`.
+
+### 5. Choose at most one lever, inside your scope
+
+Rank what would change the observed figures most, and choose **at most one** lever. Name it as the axis and
+the draft kind that applies it:
+
+| Finding | Kind | Axis |
+|---|---|---|
+| Stops too tight or too wide, a risk-reward floor, a volatility floor | `strategy` | `TRADE_LEVEL_POLICY` |
+| Break-even, trailing, time decay, invalidation exits | `strategy` | `POSITION_MANAGEMENT` |
+| A cited condition that confirms losers, a missing gate | `strategy` | `CONDITIONS` |
+| When an entry may be taken (confirmation, trigger) | `strategy` | `ENTRY` |
+| The losing pattern needs data no report section carries; a section no condition or decision uses | `strategy` | `REPORT` |
+| Rail refusals, exposure, leverage, daily limits, drawdown | `agent` | `TRADING_CONFIG` |
+| Win rate flat across conviction bands; a posture the drawdown record does not support | `agent` | `BEHAVIOR` |
+| LLM spend outrunning realized net on the agent's model | `agent` | `MODEL` |
+| Losses across regimes no condition change fixes; a strategy the owner did not author; another strategy that fits the market better | `agent` | `STRATEGY_BINDING` |
+| A regime or hours slice that loses while the others win | `radar-deployment` | `RULES` |
+| Losses in hours or regimes no rule covers, routed by the catch-all | `radar-deployment` | `DEFAULT_SLOT` |
+
+A regime or hours finding routes to the agent's **Radar rule** — a `REGIME` condition excluding the losing
+regime, or an `HOURS` condition — never to the strategy. The second-best lever is recorded as a finding
+without a lever, never as a second proposal.
+
+**A rail refusal is routed by the setting it names, never by its gate stage.** Each `railRefusals` row of the
+review read carries `tradingConfigMember`: the agent setting the owner moves to clear it. A row with a member is
+a `TRADING_CONFIG` lever on that member, inside the agent lever — `EXPOSURE_BUDGET_EXHAUSTED` names
+`maxConcurrentExposureUsd`, `DAILY_TRADE_LIMIT_REACHED` names `maxDailyTrades`, `INSUFFICIENT_EQUITY` names
+`balanceThresholdUsd`. Its `gateStage` reading `ACCOUNT` says where the gate runs, not whose setting it is: never
+say an exposure limit is outside your scope while you hold the agent lever. Lowering `balanceThresholdUsd` lowers
+a safety floor, so weigh it as a risk-increasing change and say so. A row with a null member is a halt: it ends on
+the owner's resume, and the read's `halt` names the stop that tripped it — a finding naming the owner's step,
+never a lever.
+
+**Rebind or edit.** A rebind replaces everything the agent reads and trades by — report, conditions, entry, trade
+levels, exit policy and timeframe — while each open position keeps the rules it opened under. Propose one only
+when no single strategy field would change the losing figures, or when the agent runs a strategy the owner did not
+author; otherwise edit the strategy the agent runs.
+
+- **A kind outside `scope.levers` is not yours.** Record the finding; if no in-scope lever is supported, submit
+  lever `NONE`, reason `LEVER_NOT_ALLOWED`, and say which out-of-scope lever the figures pointed at.
+- **A strategy the owner did not author is not a strategy lever.** When `strategyOwnedByOwner` is false, record
+  the finding, state that the strategy must be forked from the library before a strategy lever can be proposed —
+  forking is the owner's step, never yours — and consider a rebind and the other agent and Radar levers within
+  your scope instead. If none is supported, submit lever `NONE`, reason `TARGET_NOT_OWNED`.
+- **No ready figure, no lever.** When every figure a lever would rest on reads `INSUFFICIENT_DATA`, submit lever
+  `NONE`, reason `INSUFFICIENT_DATA`, naming the figure and its sample.
+- **Nothing to change is an answer.** When the ready figures read as a playbook doing what it should, submit
+  lever `NONE`, reason `NO_CHANGE_SUPPORTED`. Never manufacture a lever to have something to propose.
+
+### 6. Read the target's current values, then write the proposal whole
+
+A proposal carries **exactly one axis, whole**, in the kind's own vocabulary — the complete current value of
+that axis with your one change in it. So read the current value first:
+
+- a strategy axis → `get_strategy` on the agent's `strategyId`; for `REPORT`, `list_strategy_categories` for the
+  platform sections a report may carry — the whole section list is sent, with your change in it;
+- `TRADING_CONFIG` → `get_intelligence_agent` for the agent's current `tradingConfig`, and
+  `get_trading_config_catalog` for the bounds every member must sit inside;
+- `BEHAVIOR` → `get_intelligence_agent` for the current `behavior`; all three members are sent;
+- `MODEL` → `list_approved_models` for the models the account may select now, by `modelId`;
+- `STRATEGY_BINDING` → `list_strategies` (active strategies only) for the owner's own strategies and the
+  library's, by `strategyId`; a rebind carries no `TRADING_CONFIG`, since the timeframes follow the strategy;
+- `RULES` and `DEFAULT_SLOT` → `get_radar_deployment` on the coin the target names (`list_radar_deployments`
+  shows which coins route this agent); every rule is sent, in priority order, with the one rule changed, and a
+  rule or the catch-all names only agents the coin already routes.
+
+The complete shape of every axis — which members it must carry and where each comes from — is in
+`references/proposal-shapes.md`. The proposal is `{ kind, targetId, axes, baseRevision }`, where `targetId` and
+`baseRevision` are the target's `targetId` and `committedRevision` from step 2.
+
+### 7. Submit the review — the close
+
+`submit_officer_review` with the officer id, the agent id, your one-line `verdict` on the record (at most 500
+characters), the `findings`, and either the `proposal` with `noLeverReason` null, or `proposal` null with the
+`noLeverReason`. Mint one UUID as its `idempotencyKey` for each submission and repeat that key when you retry the
+same submission after a failed call, so one submission is recorded once; a resubmission with a different lever
+(below) is a new submission with a new key. The server judges the proposal with the target kind's own assessment — the same validation,
+diff, diagnostics and impact a stage would show — and stores it on the record, so the card shows only what the
+owner could commit.
+
+**A refused proposal becomes a recorded reason.** When the submit refuses with `LEVER_NOT_ALLOWED`,
+`AGENT_OUT_OF_SCOPE`, `TARGET_NOT_OWNED` or `PROPOSAL_INVALID`, submit again with `proposal` null and that code
+as `noLeverReason`, quoting the refusal's message in a finding's statement. Do not retry a different value to
+get past a `PROPOSAL_INVALID`: the record says what was refused, and the next review starts from it.
+
+**The review is written in every case** — no new decisions, out of scope, not enough data, nothing to change.
+
+Close with the review, not a question. In a scheduled run that is the whole close. When the player is in the
+conversation, add one sentence: the change is proposed and waiting on its card on the Officers page, where Apply
+publishes it, Push places it in the editor beside their own edits, and Dismiss closes it.
+
+## Negatives
+
+- **Never take a draft action.** You name no stage, commit or discard tool of any draft kind, because none is
+  yours to call: the proposal is the review record's, and Push and Apply are the owner's. Never fork, create,
+  archive, pause or resume anything.
+- **Never describe a proposal as staged or applied.** It is proposed and waiting for the owner's Apply or Push.
+- **Never say the agent "learns", "self-improves" or "optimizes itself".** Nothing reaches the agent's decision
+  prompt from a review; a change happens only when the owner commits it.
+- **Never present a counterfactual as a result.** A forward mark, a skip's return or a premature-stop verdict is
+  quoted as the recorded mark it is, never as money that "would have" been made.
+- **Never call `test_generate_deployment_grid`.** It runs a billed generation against the owner's credits and
+  writes records; it is not a review read.
+- Never diagnose from the agent's prose where a figure exists, and never present a count as a rate.
+
+## Reporting discipline
+
+- Numbers, codes and slices exactly as served, through their display names.
+- Worst news first: a halt or a standing rail refusal outranks a tuning finding.
+- One verdict line, a handful of findings that carry it, and at most one lever. Concise beats complete.

package/skills/battlegrid-strategy-officer/references/figures.md

@@ -0,0 +1,105 @@
+# Figures a finding may cite
+
+A finding names exactly one figure id from this list — the submit refuses any other. Each row says which read
+serves the figure, where in that read's output it sits, its unit, and how its value and population go into the
+finding. The owner's card renders each id through its own label and unit, so your `statement` carries the
+words and the figure carries the number.
+
+## How a finding carries a figure
+
+A finding is `{ figureId, slice, value, statement }`:
+
+- **`slice`** — the slice the figure was read over, or null for the agent's whole window:
+  `{ kind: 'REGIME', regime }` (a regime row's key — a regime, `UNAVAILABLE` or `ABSENT`),
+  `{ kind: 'HOUR', hourUtc }`, `{ kind: 'WEEKDAY', weekday }`, `{ kind: 'COIN', coinTicker }`, or
+  `{ kind: 'CONDITION', conditionKey, conditionName }`, each copied from the row it was read from.
+- **`value`** — `{ readiness: 'READY', sampleSize, value }`, or `{ readiness: 'INSUFFICIENT_DATA', sampleSize }`
+  copied from a figure that reads `INSUFFICIENT_DATA`. A count or a sum is an observation and always `READY`.
+- **`statement`** — one sentence naming the value and its population in display words: "won 4 of 19 closed
+  trades in Bear Ranging (21.1%)", "too few closed trades on Saturdays to report a rate (3)".
+
+The outputs are `{ analytics }` for `get_agent_review_analytics`, `{ quality }` for
+`get_agent_decision_quality`, `{ economics }` for `get_agent_cost_economics`, `{ stats }` for
+`get_agent_entry_discipline`, and `{ calibration }` for `get_agent_conviction_calibration`. In the review read,
+`figures` below means `analytics.overall` for the whole window, or a slice row's `figures` — `regime[]`,
+`hourOfDay[]`, `weekday[]` or `coin[]` — for that slice.
+
+## The figures
+
+### Volume
+
+- **`DECISIONS_EVALUATED`** — `figures.decisions`. Count of decisions. `sampleSize` is the count itself.
+- **`CLOSED_TRADES`** — `figures.closedTrades`. Count of closed trades. `sampleSize` is the count itself.
+- **`FORCED_EXITS`** — `figures.forcedExitCount`. Count of closes the Decision Quality band counts as forced
+  exits. `sampleSize` is the slice's `closedTrades`.
+
+### Result
+
+- **`WIN_RATE`** — `figures.winRate`: `ratePercent` when `READY`, in percent; its `sampleSize` is the closed
+  trades. State it with `figures.winningTrades` of `figures.closedTrades`.
+- **`REALIZED_NET_USD`** — `figures.realizedNetUsd`, USD, signed: the sum of the closed trades' recorded net.
+  `sampleSize` is `figures.closedTrades`.
+- **`REALIZED_FEES_USD`** — a coin row's `feesUsd`, or `analytics.llm.feesUsd` for the whole window, USD.
+  `sampleSize` is that row's `closedTrades`.
+
+### Exits
+
+- **`PREMATURE_STOP_RATE`** — `figures.prematureStop`, or `quality.exitQuality.prematureStop` for the whole
+  window: `prematureStopRatePercent` when `READY`, in percent, with `prematureStopCount` of `sampleSize` stop-outs
+  that were `STOPPED_EARLY` ("Stopped Early" — the original target printed within 24h of the stop).
+- **`POST_EXIT_MEAN_RETURN`** — `quality.exitQuality.postExit`: `meanSignedReturnPct` when `READY`, percent,
+  direction-signed — the mean move in the trade's favour over the 24 hours after the exit. Positive means price
+  kept going the trade's way after it closed.
+- **`MEDIAN_EXIT_EFFICIENCY`** — `quality.exitEfficiency.medianEfficiencyPercent`: `median` when `READY`, in
+  percent of the in-trade favourable move the exit kept.
+- **`MEDIAN_MAE_R`** — `quality.exitEfficiency.medianMaeR`: `median` when `READY`, in R — how far against the
+  trade price went before the exit, in units of the initial risk.
+
+### Entries
+
+- **`ENTER_MEAN_RETURN`** — the `enter` cell of one `filterValue[]` row (in `quality.filterValue`, or a slice's
+  `figures.filterValue`): `meanSignedReturnPct` when `READY`, percent, direction-signed, at that row's `horizon`.
+  The statement names the horizon.
+- **`SKIP_MEAN_RETURN`** — the `skip` cell of the same row, the same way. A positive skip return is a recorded
+  forward move the agent did not take — a mark, never money it lost.
+- **`CONFIRMATION_TAX_USD`** — `stats.confirmationTax.totalUsd`, USD, signed (positive is an adverse fill against
+  the decided price). `sampleSize` is `stats.confirmationTax.measuredEntries`. Not citable while `totalUsd` is null.
+
+### Conditions
+
+- **`CONDITION_CITATIONS_ON_LOSERS`** — in a `condition[]` row, the `LOST` count of one `cells[]` entry; the
+  statement names the cell's verdict (Confirm, Warn, Reject). `sampleSize` is the row's `citations`. The slice is
+  `{ kind: 'CONDITION', conditionKey, conditionName }` from the row — name the condition by `conditionName`.
+- **`CONDITION_CITATIONS_ON_WINNERS`** — the `WON` count of one cell of the same row, the same way.
+
+### Costs
+
+- **`COST_ERODED_TRADES`** — `economics.costErodedCount`: winners before costs that costs turned into losses.
+  `sampleSize` is `economics.totals.positionCount`.
+- **`FEES_PERCENT_OF_GROSS`** — `economics.totals.feesPercentOfGross`, or one close outcome row's, in percent.
+  `sampleSize` is that row's `positionCount`. Not citable while it is null (gross at or below zero) — cite
+  `REALIZED_FEES_USD` instead.
+- **`LLM_PLATFORM_SPEND_USD`** — `analytics.llm.platformSpendUsd`, USD, the platform-billed model spend over the
+  window. `sampleSize` is `analytics.llm.calls`. BYOK spend (`byokSpendUsd`) is reported in the statement when
+  non-zero, never subtracted.
+- **`NET_AFTER_LLM_USD`** — `analytics.llm.netAfterLlmUsd`, USD, signed: realized net after platform model spend.
+  `sampleSize` is `analytics.llm.decisions`.
+
+### Conviction and rails
+
+- **`CALIBRATION_GAP`** — two bands of one `calibration.slices[]` entry, both `READY`: the value is the higher
+  conviction band's `winRatePercent` less the lower band's, in percentage points, and `sampleSize` is the smaller
+  of the two bands' samples. The statement names both bands and both served rates. While either band reads
+  `INSUFFICIENT_DATA`, cite that band's sample instead.
+- **`RAIL_REFUSALS`** — one `analytics.railRefusals[]` row's `count`, a count of entries a rail refused, named in
+  the statement by the row's reason through its display name (daily trade limit reached, exposure budget
+  exhausted, agent halted, insufficient equity). `sampleSize` is the count itself. The current halt is
+  `analytics.halt`: name its `haltReason` through its display name beside the refusals.
+
+## Display vocabulary
+
+- Regimes by display name: Bull Expansion, Bear Expansion, Bull Ranging, Bear Ranging, Contraction, Volatile,
+  Unclassified; `UNAVAILABLE` is "No regime" (a cold regime context was recorded) and `ABSENT` is "Not recorded".
+- Weekdays and hours in UTC, said as such ("Thursdays, UTC", "23:00 UTC").
+- Verdicts, close outcomes and halt reasons by their display names, never the stored code.
+- Percentages to one decimal, USD to cents, R to two decimals — as served, never re-rounded into a different claim.

package/skills/battlegrid-strategy-officer/references/proposal-shapes.md

@@ -0,0 +1,174 @@
+# Proposal shapes
+
+A proposal is one lever's **one axis, whole**: `{ kind, targetId, axes, baseRevision }`, where `axes` holds exactly
+one key — the axis — whose value is the complete axis in the kind's own draft vocabulary. "Whole" means every member
+the axis carries, each at its current value except the one you change: an omitted member is not "unchanged", it is a
+proposal the assessment refuses or a value the owner would lose. So every proposal starts from the target's current
+values, read in the same review.
+
+`targetId` and `baseRevision` come from `get_officer_review_context`'s `targets`: the strategy id, the agent id or the
+Radar coin id, and that target's `committedRevision`. A proposal against a target the review context does not list
+is outside your scope.
+
+Every value below is a placeholder; replace it with what the reads served. Never send an id you did not read.
+
+## Strategy — `kind: 'strategy'`, `targetId` the strategy id
+
+Read the current values with `get_strategy`. One of five axes:
+
+### `TRADE_LEVEL_POLICY`
+
+All four members, every one a number: `minAtrPct` (the volatility floor, percent), `minStopLossAtrMultiple` and
+`maxStopLossAtrMultiple` (the hard stop's band, in ATR), `minRiskRewardRatio` (the target's floor over the stop).
+
+```json
+{
+  "kind": "strategy",
+  "targetId": "<STRATEGY_ID>",
+  "baseRevision": 12,
+  "axes": {
+    "TRADE_LEVEL_POLICY": {
+      "minAtrPct": 0.6,
+      "minStopLossAtrMultiple": 1.2,
+      "maxStopLossAtrMultiple": 2.5,
+      "minRiskRewardRatio": 1.8
+    }
+  }
+}
+```
+
+### `POSITION_MANAGEMENT`
+
+The exit policy, all thirteen members: `breakEvenEnabled`, `breakEvenTriggerR`, `trailingEnabled`,
+`trailingTriggerR`, `trailingGivebackPct`, `trailingBufferPct`, `timeDecayEnabled`, `timeDecayGracePeriodMinutes`,
+`timeDecayIntervalMinutes`, `timeDecayTightenPct`, `timeDecayMaxTightenPct`, `timeDecayStaleThresholdTpProgressPct`,
+`decisionInvalidationExitEnabled`. A mechanism switched off keeps its dial values: send them as read.
+
+### `CONDITIONS`
+
+`{ conditions: [...] }` — **every** condition of the strategy, in the order the strategy read serves them, each
+`{ conditionKey, name, definition, verdict, required, exitSide }` exactly as read, with your one change: a condition
+removed, or one existing condition's `required` or `verdict` changed. A dropped condition that another condition
+references is refused by the assessment. Composing a new condition column is authoring work, outside a review:
+record the finding and name the authoring flow as the owner's step.
+
+### `ENTRY`
+
+`{ entry: { trigger } }` for a trigger that takes no dials, or `{ entry: { trigger, levelOffsetAtrMultiple,
+validForBars } }` for a level trigger — the trigger the strategy read serves, or the one you propose, with every dial
+it honours and none it does not.
+
+### `REPORT`
+
+`{ sections: [...] }` — **every** section of the strategy's report, in the order `get_strategy` serves them, with
+your one change: a platform section added or removed. Each section is a reference: a platform section is
+`{ kind: 'platform', sectionKey }`, its key one `list_strategy_categories` serves; a custom section is
+`{ kind: 'custom', sectionKey }`, its `custom:<uuid>` key as `get_strategy` serves it, and nothing else — the submit
+takes its title, columns, benchmark and note from the committed report, so a review never edits one. A custom key the
+report does not carry is refused. A report that drops a section a condition reads is refused by the assessment: keep
+it, or propose the condition change first. Composing a new custom section is authoring work, outside a review.
+
+```json
+{
+  "kind": "strategy",
+  "targetId": "<STRATEGY_ID>",
+  "baseRevision": 12,
+  "axes": {
+    "REPORT": {
+      "sections": [
+        { "kind": "platform", "sectionKey": "includePriceAction" },
+        { "kind": "custom", "sectionKey": "custom:<SECTION_UUID>" },
+        { "kind": "platform", "sectionKey": "includeVolume" }
+      ]
+    }
+  }
+}
+```
+
+## Agent — `kind: 'agent'`, `targetId` the agent id
+
+Read the current values with `get_intelligence_agent`. One of four axes:
+
+### `TRADING_CONFIG`
+
+`{ tradingConfig: { ... } }` — the agent's complete trading configuration from `get_intelligence_agent`, less the two
+members the server derives (`strategyTimeframe`, `regimeTimeframe`): `minAllocationUsd`, `maxDailyTrades`,
+`balanceThresholdUsd`, `maxLeverage`, `maxSlippageBps`, `maxConcurrentExposureUsd`, `maxCumulativeDrawdownUsd`,
+`maxDailyLossUsd` and `positionSizePresets` (the whole preset ladder), each inside the bounds
+`get_trading_config_catalog` serves. Change the one rail the finding names; send the rest as read. A rail refusal
+names its rail as `tradingConfigMember` on the review read.
+
+### `BEHAVIOR`
+
+`{ behavior: { risk, outlook, conviction } }` — all three members, the ones you do not change as read: `risk` one of
+`CONSERVATIVE`, `MODERATE`, `AGGRESSIVE`; `outlook` one of `OPTIMIST`, `REALIST`, `PESSIMIST`; `conviction` one of
+`CAUTIOUS`, `MEASURED`, `BOLD`.
+
+### `MODEL`
+
+`{ modelId }` — a `modelId` `list_approved_models` serves now. The model sets what each decision costs: cite the
+agent's LLM spend against its net as the finding.
+
+### `STRATEGY_BINDING`
+
+`{ strategyId }` — an active strategy `list_strategies` serves: one the owner authored, or a library strategy. Never
+another user's, never an archived one. A rebind carries nothing else: the strategy and regime timeframes follow the
+new strategy, and each open position keeps the rules it opened under.
+
+```json
+{
+  "kind": "agent",
+  "targetId": "<AGENT_ID>",
+  "baseRevision": 14,
+  "axes": { "STRATEGY_BINDING": { "strategyId": "<STRATEGY_ID>" } }
+}
+```
+
+## Radar deployment — `kind: 'radar-deployment'`, `targetId` the coin id
+
+### `RULES`
+
+`{ rules: [...] }` — **every** rule slot of the coin's policy from `get_radar_deployment`, in priority order (the
+first is priority 1), the catch-all default excluded. Each rule is `{ agentId, minConviction, conditions }` as read,
+with the one rule that routes this agent changed. A rule's conditions are a non-empty list of:
+
+- `{ kind: 'regime', regimes: [...] }`, with an optional `minConviction` — the regimes the rule is on duty in, by
+  stored value (`bull_expansion`, `bear_expansion`, `bull_ranging`, `bear_ranging`, `contraction`, `volatile`);
+  excluding a losing regime is this list without it;
+- `{ kind: 'hours', hours: [...], days: [...] }` — UTC hours 0–23 and UTC weekdays 0 (Sunday) – 6, both non-empty.
+
+```json
+{
+  "kind": "radar-deployment",
+  "targetId": "<COIN_ID>",
+  "baseRevision": 4,
+  "axes": {
+    "RULES": {
+      "rules": [
+        {
+          "agentId": "<AGENT_ID>",
+          "minConviction": null,
+          "conditions": [
+            { "kind": "regime", "regimes": ["bull_expansion", "bull_ranging", "contraction"] }
+          ]
+        },
+        {
+          "agentId": "<OTHER_AGENT_ID>",
+          "minConviction": 0.6,
+          "conditions": [
+            { "kind": "hours", "hours": [13, 14, 15, 16], "days": [1, 2, 3, 4, 5] }
+          ]
+        }
+      ]
+    }
+  }
+}
+```
+
+Every agent a rule names is an agent the coin already routes: placing an agent on a coin is the owner's step, and the
+submit refuses a proposal naming any other.
+
+### `DEFAULT_SLOT`
+
+`{ defaultSlot: { agentId, minConviction } }` — the catch-all that takes the coin when no rule is on duty, its agent one
+the coin already routes; or `{ defaultSlot: null }` to remove the catch-all. Read it with `get_radar_deployment`.