@battlegrid/mcp-server 31.2.50 → 31.2.59

package/README.md

@@ -24,6 +24,522 @@ 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 — v77 (agent risk rules: each loss stop on its own rail)
+
+**Breaking at v77: an agent's `tradingConfig` accepts less.** `create_intelligence_agent` and
+`update_intelligence_agent` refuse values v76 stored, and one loss stop moves to a different bound.
+
+### Rejected input — `tradingConfig`
+
+- **`maxLeverage` must be a whole number.** `1.5` was stored and executed at `1`; it is now refused.
+- **`maxSlippageBps` is at most `300`**, the entry slippage ceiling no fill could exceed anyway.
+- **USD fields and the three size presets take at most 2 decimals.**
+- **`maxDailyLossUsd` must be at or below `maxCumulativeDrawdownUsd`.**
+- **A body accepted at v76 can be refused at v77 without one byte of it changing.** Each refusal
+  names its field in a plain sentence, such as `Whole numbers only.` or
+  `Can’t exceed the drawdown stop ($20.00).`
+
+### Wider input — the drawdown stop
+
+- **`maxCumulativeDrawdownUsd` is bounded by the platform's drawdown maximum, not by
+  `maxConcurrentExposureUsd`.** Max exposure caps margin open at once; the drawdown stop caps loss
+  over time. A `$150` drawdown stop on a `$100` max exposure is accepted.
+
+### Wider output
+
+- **`get_trading_config_catalog` gains `maximumMaxCumulativeDrawdownUsd`**, the drawdown stop's
+  upper bound.
+- **The execution-failure reason gains `BELOW_AGENT_MIN_ORDER`** (owner-private) on `get_signal_log`
+  and `get_public_agent_signal_log_detail`: an order sized under the agent's own `minAllocationUsd`,
+  which was reported as `BELOW_EXCHANGE_MINIMUM`.
+
+### Served values
+
+- **`get_agent_budget`'s `tradesToday` counts entries filled since 00:00 UTC plus entries still
+  waiting to fill.** Refused and expired entries no longer count, and the cap is enforced where an
+  entry is created. `DAILY_LIMIT_RESERVED` is no longer emitted.
+- **A daily-loss halt whose drawdown stop is also breached becomes a drawdown halt** when the day
+  rolls over, rather than lifting.
+- **A capital-feasibility refusal names what clears it**: the `maxConcurrentExposureUsd` that would,
+  and, when one at or above the platform minimum would, a lower `minAllocationUsd`.
+
+## Contract history — v76 (the extreme funding signals in percent a year)
+
+**Breaking at v76: `funding_extreme_positive` and `funding_extreme_negative` take their threshold in
+percent a year.** Their parameter is `thresholdAnnualizedPct`, the unit of the strategy grammar's
+`ann` column, where it was `thresholdPct`, a fraction of one hourly funding settlement.
+
+### Rejected input — the retired `thresholdPct`
+
+- **Both signals take `thresholdAnnualizedPct`**, bounded 1–43,800 and defaulting to 100 — the
+  funding label's crypto `extreme` band, so `100` means 100% a year, and the negative signal fires
+  below -100%.
+- **`thresholdPct` on either signal is refused as `VALIDATION_ERROR`** wherever a rule's parameters
+  are authored: `compile_strategy_plan`, `update_strategy_signal_rule`, `derive_strategy_rule_view`
+  and a strategy draft's `SIGNAL_RULES` axis. `oi_surge` keeps its own `thresholdPct`.
+- **A body accepted at v75 can be refused at v76 without one byte of it changing.** A rate per hourly
+  settlement converts to percent a year by × 8,760 × 100: `0.0002` is `175.2`.
+
+### Stale plans
+
+- **A plan token compiled before the deploy fails as a stale plan** at `stage_strategy_plan` and
+  `apply_strategy_plan`, because the authoring catalog digest covers each signal's parameters,
+  defaults and explanation: compile again. The strategy preview's `vocabularyDigest` moves too.
+
+### Served values
+
+- **`get_strategy_signal_definition` and `list_strategy_signals` serve the new parameter**, its
+  default and its explanation.
+- **Each signal's indicator values gain `funding_annualized_pct`**, the annualized rate the signal
+  compared, beside `funding_rate`.
+- **Stored rules move to the new key after the deploy**: a rule at the retired default takes `100`,
+  and any other converts exactly. `get_coin_signal_preview` and every stored rule then score at the
+  new threshold.
+- **No schema hash moves.** Signal parameters are published as a JSON object on every input and
+  output, so the change is in the values accepted and served, and `toolCount` is unchanged.
+
+## Contract history — v75 (readability from each coin's data profile)
+
+**Breaking at v75: the seven tools v73 narrowed refuse by the coin's market-data profile, and one
+output vocabulary gains a member.** Which data a coin carries is now the profile the market-data
+service publishes for that coin, no longer the coin's asset class.
+
+### Rejected input — the seven tools v73 narrowed
+
+- **A condition reading a kind of data the coin's profile does not serve is refused as
+  `INSTRUMENT`**, on the coin or on a benchmark section's own instrument: a spot read on a crypto
+  coin no spot venue lists is refused as one on a TradFi coin always was.
+- **A coin the market-data service publishes no profile for refuses every condition that reads
+  market data**: a coin enabled since the service's last boot, a roster coin whose candle stream it
+  did not subscribe, a ticker with no catalog row.
+- **The tools, codes and `details.context` are v73's**: `preview_radar_resolution` (every kind,
+  issuing no `previewToken`); `commit_radar_deployment_draft`, `rebind_intelligence_agent`,
+  `compile_strategy_plan` and `restore_strategy` (`VALIDATION_ERROR` with
+  `CONDITION_UNREADABLE_BY_RADAR_SCAN`); `apply_strategy_plan`, which applies only what its compile
+  checked; and `propose_entry_decision` (`CONDITION_UNREADABLE_ON_COIN`).
+- **A body accepted at v74.1.1 can be refused at v75 without one byte of it changing.** A write whose
+  read of the published profiles fails is refused, never admitted unchecked.
+
+### Reclassified reason — `FEED` becomes `INSTRUMENT`
+
+- **A spot read for a ticker with no catalog row is `INSTRUMENT`, where it was `FEED`**, and an
+  uncatalogued benchmark refuses every market-data read, where only its spot reads refused before.
+- **The `INSTRUMENT` message names what the profile lacks**: "`<instrument>`'s market-data profile
+  carries no `<kind>` data", or "the market-data service publishes no data profile for
+  `<instrument>`, so it carries no market data", where it read "`<instrument>` has no spot tape".
+- **The readings v74 added report it as the sweep does**: `preview_radar_resolution`'s `readings`
+  and `get_agent_coin_qualification`'s `reading` mark a condition on a kind the coin's profile lacks
+  `INSTRUMENT`.
+
+### Wider output — `BarFamily` gains `MARKET_STATS`
+
+- **The market-stats snapshot is a per-bar value**: a decision reads the snapshot fetched inside the
+  `1m` bar ending at its close. A snapshot missing there is a per-bar shortfall, a `families` entry or
+  a MISSED close's `INPUTS_OFF_BAR` `lacking` entry naming `MARKET_STATS` at `1m` with its
+  `dueBarStart`, `ABSENT` or `GONE`, and the decision waits or misses as for any per-bar family.
+- **A decided close records no `MARKET_STATS` stale sample.** A reading at the latest values still
+  does, and its `boundMs` is the coin's market-stats freshness target, never below 300,000 ms.
+- **Five outputs publish the member**: `get_agent_coin_qualification`, `get_radar_close_decisions`,
+  `get_signal_log`, `list_gate_blocks` and `preview_radar_resolution`. No input takes the vocabulary.
+  A client that validates results against a cached output schema should list the tools again after
+  the server deploys.
+
+## Contract history — v74.1.1 (a same-agent request answered from what stopped the fire)
+
+**Not breaking: one answer corrected behind unchanged schemas.**
+
+- **A request on a pair your own radar policy decides with the same agent** is answered from that
+  policy's decision. When the policy's fire enqueued no trade decision and no admission gate refused
+  it — a coin cooldown, the hourly fire cap, post-close suppression, a decision already running on the
+  coin, a deduplicated fire, or a fire aborted at its re-read — the conversation gains the card the
+  request's own unfired fire gets: `close_claimed_by_radar` when another agent's fire holds the coin,
+  otherwise `close_refused` with the reading's score against its minimum. It gained
+  `close_fired_by_radar` before, though no trade was taken.
+- **Both cards are already in `get_trade_conversation`'s vocabulary**, so no served shape moves.
+
+## Contract history — v74.1 (missed-bar alerts and the entry pause)
+
+**Not breaking: four output vocabularies gain a member, and `propose_entry_decision` refuses while an
+entry pause is open.** While bars missed for lack of market data span many coins, the platform pauses
+every new entry the radar decides, a radar fire and a manual request alike, and the pause lifts by
+itself after a quiet period.
+
+### Refused while a pause is open — `propose_entry_decision`
+
+- **A request is refused after its own checks and before a watch is registered**, whatever the agent
+  or coin: `type: "error"` with `{ origin: "ENGINE", reasonCode: "ENTRIES_PAUSED" }`. The same
+  `idempotencyKey` replays the refusal for five minutes; ask again under a fresh key once the pause
+  lifts.
+- **A request queued before the pause** whose close qualifies while it is open gets the same ENGINE
+  error card in its conversation, and no decision is proposed. `accept_entry_decision` on a decision
+  already proposed, and every exit, run as without a pause.
+
+### Wider output — four vocabularies
+
+- **`TradeEvaluationAttemptReasonCode` gains `ENTRIES_PAUSED`**: the refusal's `reasonCode`,
+  `list_gate_blocks`' `reasonCode`, and the `scanBlockReason` of a refused fire's close record and
+  journal row.
+- **`TradingPipelineGateStage` gains `PLATFORM`**: a `list_gate_blocks` entry for each fire the pause
+  refused, with no coin, no detail and no decision record.
+- **`RadarFireDisposition` gains `EDGE_PRESERVED_ENTRIES_PAUSED`**: the refused fire keeps its edge,
+  so the pair fires at a later close only if that close qualifies on its own data. It is served on
+  `get_radar_activity` and `get_radar_activity_summary`, and as a close record's
+  `outcome.fireDisposition` beside `outcome.scanBlockReason: "ENTRIES_PAUSED"`, with
+  `outcome.outcome` staying `FIRED`.
+- **`RadarIdleReason` gains `ENTRIES_PAUSED`**: the `resolvesNow.reason` of every `SCANNING` card on
+  `get_radar_deployment` and `list_radar_deployments` while a pause is open. The section stays
+  `SCANNING`, because closes are still decided and recorded.
+
+### Answer corrected — a same-agent request
+
+- **When an admission gate refused your own policy's fire** — an entry pause, an account block, a
+  position already held on the coin — the request's conversation gains that block's ENGINE error card
+  instead of `close_fired_by_radar`.
+
+## Contract history — v74 (preview `conditionReach` replaced by `readings`)
+
+**Breaking at v74: one required output field replaced on one tool, and an opt-in reading added to
+another.** Both now serve what an agent reads on a coin, in the decision-record format v73.3
+introduced.
+
+### Reshaped output — `preview_radar_resolution`
+
+- **`conditionReach` is gone, replaced by `readings`**: one entry per on-duty agent, in on-duty order,
+  each naming `agentId` and `agentDisplayName`. A `kind: "READ"` entry carries the agent's `reading`,
+  the one `get_agent_coin_qualification` serves (below). A `kind: "UNSCORABLE"` entry, an agent whose
+  evaluation was rejected, carries `coinDataStopped` instead: the coin's stopped-data reading, or
+  null. One agent's rejection is its own entry, never a failed preview. The tool always asks for
+  readings, so `readings` is null only under a `simulatedRegime`.
+- **`blocksScanGate` has no successor.** Since v73 the preview refuses a slot agent with a condition
+  the radar scan cannot read on the coin, so no previewed pair holds a permanently blocking
+  condition. Whether the conditions hold the coin is the reading's own gate,
+  `reading.live.reading.qualification.gates.requiredConditions`.
+- **Read `reachReason` from the reading.** Each `READ` entry's
+  `reading.live.reading.conditions.entries[]` lists the conditions: a `kind: "UNEVALUATED"` entry
+  carries the condition's `conditionKey`, `name` and `reachReason`, and a `kind: "EVALUATED"` entry,
+  the counterpart of a null `reachReason`, carries its outcome with its clause values.
+  `declaration.required` marks the required ones, the set `conditionReach` covered.
+- **A client that validates results against a cached output schema** fails the call until it lists
+  the tools again, because the old schema required `conditionReach`. Reconnect, or re-list, after the
+  server deploys.
+
+### Wider input and output — `get_agent_coin_qualification`
+
+- **`reading` (boolean, default false) asks for the pair's reading**, and each verdict gains the
+  required-nullable `reading`, null unless asked. A call without the flag is answered as before, with
+  `reading: null`.
+- **`reading.live`** is the reading the verdict was built from, with `anchorBarStatus` (`live` while
+  the anchor bar still forms), `scoredBarStart` (the bar the signals and gates were scored on) and
+  `observedAt`. It is what the agent reads now, not a decision: the radar decides at the close.
+- **`reading.lastClose`** is the deciding reading of the bar the agent's on-duty row names as its
+  last close decision: `state: "RECORDED"` with that bar's close-decision `record`,
+  `state: "PENDING"` with its `barStart` while that record is being written, or `state: "NONE"`.
+  `get_radar_close_decisions` holds the decisions before it.
+
+## Contract history — v73.3 (decision records)
+
+Purely additive: **one read tool, one evaluation-attempt reason and four output fields added.** What
+a decision read is now served: the radar's close decisions on a coin, the report behind a trade, and
+the compose decision behind a gate block.
+
+### Wider surface — one tool added
+
+- **`get_radar_close_decisions`** (`coinId`; optional `agentId`, `before`, `limit`; `mcp:read`) — one
+  coin's radar close-decision records, newest decided bar first: every bar an agent decided —
+  `FIRED`, `CLAIMED`, `NOT_QUALIFIED` or `MISSED` — with the reading it was decided on (a miss's
+  answer instead), its fire disposition and its versions. Your own records only: a SYSTEM agent's
+  records on a coin belong to every user who deployed it. A page never splits a bar, so it can run
+  past `limit`; to page back, pass the oldest record's `bar.barStart` as `before`. `toolCount` goes
+  141 → 142.
+
+### Wider output — the risk budget, Radar reads, the trade conversation, gate blocks and signal logs
+
+- **`TradeEvaluationAttemptReasonCode` may read `SCREENED_OUT`** on `get_agent_budget`,
+  `reset_agent_drawdown_baseline`, `get_radar_activity`, `get_radar_deployment`,
+  `list_radar_deployments`, `preview_radar_resolution`, `get_trade_conversation`,
+  `propose_entry_decision`, `list_gate_blocks`, `get_signal_log` and
+  `get_public_agent_signal_log_detail`: compose's deterministic pre-model screen found no routable
+  direction. That refusal now writes a gate block. It is public: the public profile carries it as is.
+  A client holding its own closed copy of the enum rejects the new member; one that renders unknown
+  reasons generically is unaffected.
+- **`get_signal_log`'s `log` gains `reportSections`** (the report the model read, section by section,
+  in the shape of `preview_strategy_report`'s `renderedSections`), **`promptDataSerialization`** (the
+  serialization it was rendered under) and **`missingData`** (the data compose lacked), each null for
+  a trade recorded before capture. `get_public_agent_signal_log_detail` carries none of them.
+- **Each `list_gate_blocks` entry gains `decisionRecord`**: the compose decision record written with
+  the block — its outcome, its evidence (the reading compose computed, the per-bar values a refused
+  decided bar lacked, or none), its missing data and its versions. It is null for a block written
+  before capture and for a block raised before compose.
+
+## Contract history — v73.2 (decided-bar refusal)
+
+**One member added to the evaluation-attempt reason**, published as output only, and two detail
+fields added to gate blocks. A confirming-close fire now names the bar it decided, and compose reads
+that bar or refuses with the new reason, instead of reading the newest completed bar at its own
+instant.
+
+### Wider output — the risk budget, Radar reads, the trade conversation, gate blocks and signal logs
+
+- **`TradeEvaluationAttemptReasonCode` may read `DECIDED_BAR_UNAVAILABLE`** on `get_agent_budget`,
+  `reset_agent_drawdown_baseline`, `get_radar_activity`, `get_radar_deployment`,
+  `list_radar_deployments`, `preview_radar_resolution`, `get_trade_conversation`,
+  `propose_entry_decision`, `list_gate_blocks`, `get_signal_log` and
+  `get_public_agent_signal_log_detail`: compose refused a radar fire at the conditions stage, before
+  any LLM call, because a per-bar value its conditions gate reads was not on its due bar for the bar
+  the radar decided — its entry had not landed, or had gone. It is public: the public profile carries
+  it as is. A client holding its own closed copy of the enum rejects the new member; one that renders
+  unknown reasons generically is unaffected.
+- **`list_gate_blocks`' `reasonDetail` gains `decidedBarStart`** (ISO 8601, the decided bar's open)
+  **and `decidedBarTimeframe`** (the strategy timeframe), present on that reason alone.
+
+## Contract history — v73.1 (strategy card fields)
+
+Purely additive: **thirteen read-only fields added to every `list_strategies` row.** The input is
+unchanged, and a client that ignores the fields is unaffected.
+
+### Wider output — `list_strategies`
+
+- **The strategy card:** `regimeTimeframe` and `lowerTimeframe` (the derived ladder rungs
+  `get_strategy` already serves); `conditionTally`, `signalRuleTally` and `exitTally` (`armed` out of
+  `total`, the four exit mechanisms); and `minRequiredCount`, `entryTrigger`, `minRiskRewardRatio` and
+  `maxStopLossAtrMultiple`.
+- **`forkedFromStrategyName`**, null when the strategy is not a fork or its source is neither yours
+  nor a SYSTEM strategy.
+- **`viewerBoundAgentCount` and `viewerOpenPositionCount`**, your own agents on the strategy and their
+  open positions. `boundAgentCount` still counts every user's agents; read the viewer fields for
+  yours.
+- **`viewerPerformance`**, your own all-time results on the strategy, null when you never traded it.
+  A trade counts toward the strategy recorded on the signal log that opened it, so rebinding an agent
+  never moves it.
+
+## Contract history — v73 (unreadable radar conditions refused)
+
+**Breaking at v73: seven tools refuse bodies they used to accept, behind unchanged input schemas.**
+A condition the radar acts on — a required one, a direction-setting one (a verdict carrier), an exit
+one, and every condition they reference — must be readable by the radar scan on every coin the radar
+acts on for its agent: each coin a Radar policy slots it on, enabled or paused; each coin it holds an
+open position on, for its exit conditions; and each coin it has a pending manual request on.
+
+### Rejected input — refused behind unchanged schemas
+
+- **`VALIDATION_ERROR` with the authoring code `CONDITION_UNREADABLE_BY_RADAR_SCAN`** from
+  `preview_radar_resolution` (every kind, for every slot agent whether on duty now or not, issuing no
+  `previewToken`), `commit_radar_deployment_draft`, `rebind_intelligence_agent`, and
+  `compile_strategy_plan` and `restore_strategy` on behalf of the bound agents the radar acts on (a
+  strategy none of whose agents holds a slot, an open position or a pending request is never
+  checked). `details.context.reachReason` says why: `INSTRUMENT` (the coin, or a benchmark section's
+  own instrument, has no such data), `AGENT_TIMEFRAME` (the agent has no such rung) or `FEED` (the
+  radar scan never reads that data: crowd reads, a spot read for an uncatalogued ticker, a timeframe
+  the agent's plan does not load).
+- **The message names the first conflicting agent, the condition, the column, the coin and the
+  fixes**: stop the radar acting on the condition, make it read a column the scan has on that coin,
+  or free the coin — take the agent off that coin's policy, close the position, or cancel the pending
+  request. It is a fact about the pair, which no later sweep changes.
+- **A refused compile issues no plan token**, so `stage_strategy_plan` cannot stage that content, and
+  **`apply_strategy_plan` applies only a plan whose bound agents still hold the radar slot coins its
+  compile checked**: a plan compiled before a deploy moved them fails verification. Compile again.
+- **A condition reading a Session Field scalar** keeps `CONDITION_OPERAND_UNSERVED_IN_LANE`, now
+  refused at the rebind and every strategy revision too, not only at the deploy.
+- `stage_radar_deployment_draft` is unchanged: a draft holds no slot, and the preview its commit
+  needs refuses. A body accepted under v72 is refused under v73 without one byte of it changing.
+
+### Wider output — `propose_entry_decision`, `get_trade_conversation`
+
+- **`propose_entry_decision` refuses a request whose agent the radar scan cannot read on the
+  requested coin**, before its watch is registered, and releases its idempotency claim. It returns
+  `type: "error"` with `error: { reasonCode: "CONDITION_UNREADABLE_ON_COIN", unreadable: {
+  conditionKey, conditionName, column, coinTicker, reachReason } }`: facts only, no prose. Choose
+  another coin, another agent, or a condition reading a column the radar reads on that coin, and
+  send it again. `get_trade_conversation`'s error card carries the same `reasonCode` and
+  `unreadable`.
+- **A client that validates results against a cached output schema** fails a call that returns the
+  new error until it lists the tools again, because the old schema has no such member. Reconnect, or
+  re-list, after the server deploys.
+
+### Refusals worth knowing before you apply, restore or rebind
+
+- **`CONFLICT` with `details.reason: "RADAR_DEPLOYMENT_MOVED"`** from `apply_strategy_plan`,
+  `restore_strategy` and `rebind_intelligence_agent`: the agents' radar slot coins moved after the
+  write's check. Re-read and retry, so the retry's check covers the moved deployment; for a plan,
+  compile again.
+- **`commit_radar_deployment_draft` is a `CONFLICT`** when a slot agent's strategy or timeframes
+  changed after its check. Preview again.
+
+## Contract history — v72.0.1 (account read faults withheld on the public profile)
+
+**No schema change: one value reclassified on one public read.**
+
+### Reclassified output — `get_public_agent_signal_log_detail`
+
+- **`pipeline.attempt.reasonCodes` carries `OWNER_PRIVATE`, with its detail omitted, where it would
+  have carried `EQUITY_CHECK_UNAVAILABLE`, `ALLOCATION_CHECK_UNAVAILABLE`,
+  `DAILY_COUNT_CHECK_UNAVAILABLE` or `APPROVAL_CHECK_UNAVAILABLE`.** Each says the account has an open
+  block, which the public profile withholds. This supersedes the v71.1 note below that the public
+  detail carries the two faults v71.1 added. `OWNER_PRIVATE` has been in that field's schema since
+  v71, so a client validating against a cached output schema accepts it. `get_signal_log` still
+  carries every precise code on your own agents.
+
+## Contract history — v72 (public decision `userId` removed)
+
+**Breaking at v72: one output field removed from one public read.**
+
+### Removed output — `get_public_agent_signal_log_detail`
+
+- **`log.linkedEntryDecision.userId` is gone.** It was the user the agent acted for. On a SYSTEM
+  agent, which has no author and which any user may deploy, that named whoever deployed it, and the
+  public profile deliberately shows no owner for a SYSTEM agent. There is **no replacement path** on
+  the public read. A PRIVATE agent's author is `ownerUserId` on the agent's public profile, and the
+  owner tool `get_signal_log` still carries `linkedEntryDecision.userId` on your own agents.
+- **A client that validates results against a cached output schema** fails the call until it lists
+  the tools again, because the old schema required the field. Reconnect, or re-list, after the server
+  deploys.
+
+## Contract history — v71.1 (two read-fault refusals)
+
+**Two members added to the evaluation-attempt reason**, published as output only. When the server
+cannot read an agent's daily trade count or its trading account's approval, the admission is blocked
+with its own reason instead of borrowing the verdict it could not reach.
+
+### Wider output — the risk budget, Radar reads, the trade conversation, gate blocks and signal logs
+
+- **`TradeEvaluationAttemptReasonCode` may read `DAILY_COUNT_CHECK_UNAVAILABLE` or
+  `APPROVAL_CHECK_UNAVAILABLE`** on `get_agent_budget`, `reset_agent_drawdown_baseline`,
+  `get_radar_activity`, `get_radar_deployment`, `list_radar_deployments`, `preview_radar_resolution`,
+  `get_trade_conversation`, `propose_entry_decision`, `list_gate_blocks`, `get_signal_log` and
+  `get_public_agent_signal_log_detail`. `DAILY_TRADE_LIMIT_REACHED` and `AGENT_APPROVAL_EXPIRED` still
+  mean what they say. A client holding its own closed copy of the enum rejects the new members; one
+  that renders unknown reasons generically is unaffected.
+
+## Contract history — v71 (owner-private reasons on the public profile)
+
+**Breaking at v71: two public inputs narrow, and one public output widens.**
+
+### Rejected input — `get_public_agent_signal_logs`, `get_public_agent_realized_trades`
+
+- **`filter.rejectionReason` refuses the six owner-private failure reasons** —
+  `BELOW_EXCHANGE_MINIMUM`, `INSUFFICIENT_BALANCE`, `INSUFFICIENT_MARGIN`,
+  `AGENT_APPROVAL_EXPIRED`, `SIGNING_KEY_UNAVAILABLE`, `AGENT_HALTED` — with a validation error,
+  where they used to filter. These tools read another user's agent, and a private reason answered a
+  question about that user's budget, margin, approval, key or halt. No alias exists; filter by a
+  public reason. `filter.expiryReason` still accepts every member.
+
+### Wider output — `get_public_agent_signal_log_detail`
+
+- **`pipeline.attempt.reasonCodes`, `pipeline.execution.failureReason` and `.expiryReason` may read
+  `OWNER_PRIVATE`** in place of an owner-private reason, whose detail is then omitted. A client
+  holding its own closed copy of these enums rejects the new member; one that renders unknown
+  reasons generically is unaffected. A failed execution's `executionMessage` is now always null.
+- **`get_signal_log` is unchanged**: on your own agents it still carries every precise code, its
+  detail and the narrative.
+
+## Contract history — v70.2 (allocation-check refusal)
+
+**One member added to the evaluation-attempt reason**, published as output only. An admission the
+server blocked because it could not read the account's allocation now carries
+`ALLOCATION_CHECK_UNAVAILABLE`; `NO_AGENT_ALLOCATION` survives only on historical rows.
+
+### Wider output — the risk budget, Radar reads, the trade conversation and gate blocks
+
+- **`TradeEvaluationAttemptReasonCode` may read `ALLOCATION_CHECK_UNAVAILABLE`** on
+  `get_agent_budget`, `reset_agent_drawdown_baseline`, `get_radar_activity`, `get_radar_deployment`,
+  `list_radar_deployments`, `preview_radar_resolution`, `get_trade_conversation`,
+  `propose_entry_decision` and `list_gate_blocks`. A client holding its own closed copy of the enum
+  rejects the new member; one that renders unknown reasons generically is unaffected.
+- **The reason detail no longer declares `availableUsd` or `requiredUsd`** (`get_signal_log`,
+  `get_public_agent_signal_log_detail`). No response ever carried them.
+
+## Contract history — v70 (risk-gauge `configured` removed)
+
+**Breaking at v70: one output field removed from every risk-budget gauge.**
+
+### Reshaped output — `get_agent_budget`, `reset_agent_drawdown_baseline`
+
+- **`budget.gauges.<gauge>.configured` is gone** from all four gauges (`dailyTrades`, `exposure`,
+  `drawdown`, `dailyLoss`). It could only read `true`: the daily-trades cap is at least 1, and an
+  agent's exposure ceiling, drawdown stop and daily-loss stop are all required and strictly positive.
+  Every gauge has a limit, so read `fill`, `remaining` and `breached` and render every meter enabled.
+- **A client that validates results against a cached output schema** fails the call until it lists
+  the tools again, because the old schema required the field. Reconnect, or re-list, after the server
+  deploys.
+
+## Contract history — v69.7 (insufficient-margin refusal)
+
+Purely additive: **one member added to the trade-failure reason**, in both directions. An agent entry
+the shared trading account cannot post the isolated margin for is now refused before any order is
+sent, with its own reason. The same reason replaces `EXCHANGE_ERROR` when the exchange refuses an
+order for margin first.
+
+### Wider input — `get_public_agent_signal_logs`, `get_public_agent_realized_trades`
+
+- **`filter.rejectionReason` accepts `INSUFFICIENT_MARGIN`**, where it used to refuse it.
+
+### Wider output — `get_signal_log`, `get_public_agent_signal_log_detail`
+
+- **`failureReason` may read `INSUFFICIENT_MARGIN`.** A client that switches exhaustively on the
+  reason needs one more arm; one that renders unknown reasons generically is unaffected.
+
+## Contract history — v69.5 (liquidation-buffer refusal)
+
+Purely additive: **one member added to the trade-failure reason**, in both directions. An agent entry
+whose hard stop no whole leverage can keep clear of liquidation is now refused before any order is
+sent, with its own reason. Below that, an agent order's reported effective leverage may sit under the
+agent's bound: it is lowered until the isolated liquidation is at least twice as far from the fill as
+the hard stop.
+
+### Wider input — `get_public_agent_signal_logs`, `get_public_agent_realized_trades`
+
+- **`filter.rejectionReason` accepts `LIQUIDATION_BUFFER_UNREACHABLE`**, where it used to refuse it.
+
+### Wider output — `get_signal_log`, `get_public_agent_signal_log_detail`
+
+- **`failureReason` may read `LIQUIDATION_BUFFER_UNREACHABLE`.** A client that switches exhaustively on
+  the reason needs one more arm; one that renders unknown reasons generically is unaffected.
+
+## Contract history — v69 (Radar multi-agent duty)
+
+**Breaking: one input removed from two tools, three outputs reshaped.** A Radar policy carries no
+timeframe. Every rule whose conditions match puts its agent on duty at once, and each rule's regime
+condition is read at that agent's own regime timeframe. A coin still holds one position at a time: at
+most one fire per coin per pass, offered in rule priority.
+
+### Rejected input — something you send is no longer accepted
+
+- **`preview_radar_resolution`'s `SLOTS` request refuses `deploymentTimeframe`** as an unrecognized key.
+  Send `{ kind: "SLOTS", slots }`.
+- **`stage_radar_deployment_draft` refuses the `DEPLOYMENT_TIMEFRAME` axis** the same way. Stage only
+  `RULES` and `DEFAULT_SLOT`.
+
+### Reshaped output — something you read has a new shape
+
+- **`resolvesNow`** on `get_radar_deployment`, `list_radar_deployments` and `preview_radar_resolution` is
+  the coin's state (`section`, `isIdle`, `rotating`, one `reason`, the open-position owner) plus
+  **`onDuty`**: one row per agent on duty, in priority order. Each row carries its slot, its regime reading
+  at its own regime timeframe, its qualification verdict and gate, cooldown, block, `edgeSpent`, last flip
+  and fire, and its own `closeDecision`. The single-winner fields (`onDutyAgentId` and its display pair,
+  `matchedSlot*`, `regimeUsed`, and the per-agent fields the rows now carry) are gone. Render every row in
+  the order served, and never pick one yourself.
+- **`preview_radar_resolution`'s `conditionReach`** is one flat list, each entry naming its `agentId` and
+  `agentDisplayName`.
+- **Each deployment slot gains `agentRegimeTimeframe`**, the timeframe its rule's regime is read at.
+
+### Removed output — a field you read is gone
+
+- **`deploymentTimeframe`** on a Radar policy, and the **`DEPLOYMENT_TIMEFRAME`** axis in the radar
+  draft's `content` and `axesMeta` on `get_radar_deployment_draft`, `list_radar_deployment_drafts` and the
+  stage result.
+
+### Wider enums — a value you may now receive
+
+- **`closeDecision.outcome` gains `CLAIMED`**: the agent's close qualified, but a higher-priority agent
+  took the coin's one fire that pass. Its edge is preserved, and it fires at a later close only if it
+  still qualifies there.
+- **`get_radar_activity` and `get_radar_activity_summary`** gain the events `ON_DUTY_JOINED` and
+  `ON_DUTY_LEFT` (duty is journaled per agent) and the fire disposition `EDGE_PRESERVED_COIN_CLAIMED`.
+  `curveDigest` describes the first agent on duty, named in `curveAgentName`.
+- **`get_trade_conversation`** may carry the `close_claimed_by_radar` card.
+
+The exported `battlegrid-radar-deployment` skill describes the v69 flow.
+
 ## Contract history — v68.1 (Arena regime sets)
 
 Purely additive in schema, with **one refusal behind unchanged ones.** An Arena rule's regime condition

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.50";
+export declare const PACKAGE_VERSION = "31.2.59";
 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.50';
+export const PACKAGE_VERSION = '31.2.59';
 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.50",
+  "version": "31.2.59",
   "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": "68.1.0",
+  "contractVersion": "76.0.0",
   "files": {
-    "battlegrid-agent-management/SKILL.md": "fbc602e9445d0f72353bfba23c30a364b478bd04a9cc6248418cfeec66717eb1",
+    "battlegrid-agent-management/SKILL.md": "5ea8384ff76ccb9fdf00e4ec8b584f88fdba6d1c9d5679ce0b7380c23bfbaab1",
     "battlegrid-arena-play/SKILL.md": "4cfaa92a8d0dcaf477b227abd774e7aa8642c185d72108dfd401be0cf8aecd7f",
     "battlegrid-market-analysis/SKILL.md": "22fde9c4eac0261c89a8056ab8b20b66fcbe1fd58447fa0ac84fd410b4d134d7",
-    "battlegrid-radar-deployment/SKILL.md": "87601043eb3920faa153061e4ea93f4d8618dbdb8fe8c3be52b4e47ddba18d83",
+    "battlegrid-radar-deployment/SKILL.md": "17301fa66f4b128154435462ffa967efcb3d016df671b03c485d0f8b840fc891",
     "battlegrid-strategy-authoring/SKILL.md": "95e91dd1ff36922b7ed0f5eb92c98def98fa39cce37c3d7447269aea1b5a017f",
-    "battlegrid-strategy-doctor/SKILL.md": "d0b9e9e07648246d5a23b0c17183278b70b5bcbb5f472ac7da13d03e42a6c6c6",
-    "battlegrid-strategy-examples/SKILL.md": "17e8cf8040813622bd5b82165c7af82e03287fee1f6aac974e0b6c584580dd27",
-    "battlegrid-strategy-examples/references/playbooks.md": "35c543c090d00ba19e4bcf0a80502afac7a4954643fc535de0b24381c91ecbf4",
+    "battlegrid-strategy-doctor/SKILL.md": "a3446f24059be72ae797ba4e9669848d851ac3dc38675923fe3d307f557eb82f",
+    "battlegrid-strategy-examples/SKILL.md": "a60b766de81f859f2fa9b352d65937b6a6f3eb24c4e88a064123a4985906bce5",
+    "battlegrid-strategy-examples/references/playbooks.md": "02168e3af35268a30fd156f3337d25fe15e6df67da1592f4cb4d31090be3f94f",
     "battlegrid-strategy-examples/references/recipes.md": "53887daece17995543e7d3fe1bf2577fc41a6254c291acacde48d7de63853641",
     "battlegrid-strategy-examples/references/tradingview-ports.md": "2b13adbc137178955edcca31b6ab40c01c745a932a0750b91db8820c736700bb",
     "battlegrid-trade-analysis/SKILL.md": "f49482702f17d7fc44db00c31a19fc6e9350668fe76e8948d22faaa9c7e9d6bf",
-    "battlegrid-trade-proposal/SKILL.md": "4cdb46a543cc126092874a4b385670ea2160de0384b7b5087c93b0aa72830b79"
+    "battlegrid-trade-proposal/SKILL.md": "9bf7b7648fb009db118a3a428b15abf38df5ba56a2ef4c8a4eae3d979bdc8bcb"
   }
 }

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

@@ -25,8 +25,8 @@ step named beside it before doing anything else.
    configuration change to an agent the player is mid-edit on is staged, not committed. → steps 3
    and 4.
 3. **Mis-lever'd halt recovery.** *Cue: "why is it stopped", "start it again", any halted agent.*
-   There are three halt reasons and they do not share a lever. Offering a drawdown baseline reset
-   to a daily-loss halt is offering something that cannot work. → step 5.
+   The halt reason says why the agent stopped, not what clears it. Offering an exit the server's
+   resume verdict does not offer is offering something that cannot work. → step 5.
 4. **Driving strategy writes from this arc.** *Cue: the answer to an agent problem turns out to be
    "change the strategy".* You can SEE strategies here because you must name what you bind. That is
    not permission to author them. → the cross-skill rule below.
@@ -118,7 +118,16 @@ mid-edit in their form.** Then:
 - `discard_agent_draft` only on the player's word: call it with `confirm:false` first, tell them
   when the draft was last written and from which surface, ask, then confirm.
 
-With **no draft open**, the update verb below stands, confirm and all.
+**In a conversation the agent console hosts** — your context names the agent console and an agent
+id — the player's form is open on that agent whether or not a draft exists yet. Stage every change
+into that agent's draft, naming that id as `agentId`, create or edit alike: the create recipe's
+omitted id does not apply there, because the screen already holds the id the agent will be created
+at. Create, update, rebind and discard are refused there — the player's own Create, Save or Discard
+is the act. On an existing agent a strategy change is a recommendation the player picks in the
+Strategy step. An axis their form rewrote after your proposal — typed over or undone — is their
+answer: propose it again only on their word.
+
+With **no draft open**, the update verb below stands, confirm and all — outside the agent console.
 
 ### 4. Lifecycle verbs: read first, state the radius, then confirm
 
@@ -152,23 +161,33 @@ the reason, and name what would clear it (un-deploy via the radar/deployment too
 the positions resolve, wait for the session to settle). Never paraphrase the refusal into "it
 didn't work", and never retry it unchanged.
 
-### 5. Halt recovery: branch on the served halt reason
-
-`get_agent_budget` serves `haltReason`. There are exactly three, and the lever differs:
-
-- **MANUAL** — the player halted it. `resume_intelligence_agent` lifts it unconditionally.
-- **DRAWDOWN_BREACH** — cumulative realized loss reached the drawdown stop. Two levers: raise
-  `maxCumulativeDrawdownUsd` through the update verb, **or** `reset_agent_drawdown_baseline`,
-  which acknowledges the loss and re-arms the stop from today (it erases no history and journals
-  the acknowledgement). Then resume.
-- **DAILY_LOSS** — realized loss for the day reached the daily limit. Two levers: raise
-  `maxDailyLossUsd` through the update verb, **or** wait for the UTC-day rollover, which clears it
-  automatically. **The baseline reset cannot clear a daily-loss halt — never offer it here.**
-
-**A resume attempted while the breach still holds is refused by the server**, with the current
-figure against the limit. Surface those served figures and the applicable lever from the list
-above. Do not retry the resume, and do not reach for the reset to "get past" a refusal that names
-a different stop.
+### 5. Halt recovery: offer exactly the served verdict's exits
+
+`get_agent_budget` serves `haltReason` — why the agent stopped — and `haltResumeEligibility`, the
+server's resume verdict. **The verdict decides the recovery**; the reason only explains the stop.
+
+- **`haltResumeEligibility` is null** — the agent is not halted. Every halt carries a verdict, one
+  the player set by hand included, and is recovered through it.
+- **`eligible: true`** — nothing is still breached, and a resume will succeed. Offer
+  `resume_intelligence_agent`.
+- **`eligible: false`** — `breachedStop` names the stop still breached, with `breachingFigureUsd`
+  against `limitUsd`. Present that stop and exactly the exits the verdict marks open:
+  - `canRaiseTriggeringStop` — raise that stop above the figure through the update verb
+    (`maxCumulativeDrawdownUsd` for the drawdown stop, `maxDailyLossUsd` for the daily loss limit);
+  - `canResetBaseline` — `reset_agent_drawdown_baseline`, which acknowledges the loss and re-arms
+    the drawdown stop from today (it erases no history and journals the acknowledgement);
+  - a `breachedStop` of `DAILY_LOSS` also clears at the UTC-day rollover.
+
+  Then resume. An exit the verdict does not mark open is never offered.
+
+After any resume, read the response's `haltedAt`. The server re-checks every stop once the halt is
+cleared, so a set `haltedAt` means the agent was halted again at once: a loss settled, or a stop was
+lowered, while the resume ran. Read `get_agent_budget` again and present its `haltReason` and
+verdict; never report that agent as trading.
+
+**A resume attempted while a stop is still breached is refused by the server**, naming the same
+stop, figure and exits. Surface them as served. Do not retry the resume; after a raise or a reset,
+read the verdict again rather than assuming it cleared.
 
 ### 6. Risk limits are a whole object
 

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

@@ -1,12 +1,14 @@
 ---
 name: battlegrid-radar-deployment
-description: Deploy the player's agents to standing duty — per-coin Radar policies that fire real trades on confirmed regime flips, and per-preset Arena deployment policies that enter sessions automatically. Reads what is deployed now, stages a change into the player's draft, previews what it would actually resolve to, commits it only after the player has seen that preview, and un-deploys with the blast radius stated. Activate whenever the player wants an agent put on duty, wants to change or pause a deployment, asks what would fire right now or why nothing is firing, or wants to stop a coin or a preset being traded automatically.
+description: Deploy the player's agents to standing duty — per-coin Radar policies that put every matching rule's agent on duty and fire real trades at confirmed closes, and per-preset Arena deployment policies that enter sessions automatically. Reads what is deployed now, stages a change into the player's draft, previews what it would actually resolve to, commits it only after the player has seen that preview, and un-deploys with the blast radius stated. Activate whenever the player wants an agent put on duty, wants to change or pause a deployment, asks what would fire right now or why nothing is firing, or wants to stop a coin or a preset being traded automatically.
 ---
 
 # Radar & Deployment
 
-You are handing an agent **standing authority**. A Radar policy fires real trades on confirmed
-regime flips with no further human action; a deployment policy enters real sessions the same way.
+You are handing agents **standing authority**. A Radar policy puts EVERY rule whose conditions match
+on duty at once — each rule's regime read at its own agent's regime timeframe — and fires real trades
+at their confirmed closes with no further human action, at most one per coin per pass, offered in rule
+priority; a deployment policy enters real sessions the same way.
 Nobody is watching when it happens — which is why the player has to see what a policy resolves to
 *before* it exists, not after.
 
@@ -18,7 +20,7 @@ and never describe them as one thing with two modes.
 
 1. **A write with no fresh preview.** *Cue: any `commit_radar_deployment_draft`,
    `resume_radar_deployment`, `commit_deployment_policy_draft` or `resume_deployment_policy`.* The preview is the only place the
-   player sees which agent actually goes on duty and why. → steps 2–3.
+   player sees which agents actually go on duty and why. → steps 2–3.
 2. **A blind retry.** *Cue: a CONFLICT on a write.* Something moved under you — the stored policy,
    or the player's draft. Retrying overwrites an edit you never read. → step 3.
 3. **Previewing one thing and writing another.** *Cue: the player adjusts a slot, a bar, a window
@@ -49,7 +51,10 @@ Then read what exists:
 
 - `get_radar_deployment` (one coin) or `list_radar_deployments` (the fleet, plus the platform
   `radarPaused` kill-switch — if that is set, say so up front: nothing will fire whatever you
-  write).
+  write). A `SCANNING` card whose reason is `ENTRIES_PAUSED` is the platform's **entry pause**: new
+  entries are paused platform-wide while market data is missing across many coins. Say that up front
+  too — the radar takes no new entry on any coin until it lifts, which it does by itself once the
+  data is back, and nothing the player changes on a deployment clears it.
 - **For Radar, also read the player's draft of the coin** with `get_radar_deployment_draft` — or
   `list_radar_deployment_drafts` when no coin is named yet. The player may be part-way through a
   change in their radar builder. **If a draft exists, say so** — what it holds, and when and from
@@ -69,16 +74,19 @@ If the question is *why did my radar agent not fire*, do not start from the jour
 **Radar** — the change goes into the player's draft of the coin, never straight to the policy:
 
 1. `stage_radar_deployment_draft` with `draftVersion` = the `version` you read (0 when there was
-   no draft) and only the axes you are changing, each WHOLE: `DEPLOYMENT_TIMEFRAME`, `RULES` (the
-   complete ordered rule list — first is highest priority) and `DEFAULT_SLOT` (the catch-all, or
-   null for none). Staging writes nothing live and shows the change in the player's builder as a
-   proposal. A refusal naming axes means the player changed them after your read: read again and
+   no draft) and only the axes you are changing, each WHOLE: `RULES` (the complete ordered rule list
+   — first is highest priority; every rule that matches is on duty, so priority decides only which
+   agent is offered the coin's one fire on a pass) and `DEFAULT_SLOT` (the catch-all, on duty only
+   when no rule is, or null for none). A Radar policy has **no timeframe**: each rule's regime
+   condition is read at its agent's own regime timeframe, which every slot reports as
+   `agentRegimeTimeframe`. Staging writes nothing live and shows the change in the player's builder as
+   a proposal. A refusal naming axes means the player changed them after your read: read again and
    propose against what they now have.
 2. `preview_radar_resolution` with `request: { kind: "DRAFT", draftVersion }` at the version staging
    returned. It composes the draft over the deployed policy **exactly as the commit will write it**.
 
-To try a slot set without touching the draft, preview `{ kind: "SLOTS", deploymentTimeframe, slots }` —
-it certifies nothing and cannot be committed.
+To try a slot set without touching the draft, preview `{ kind: "SLOTS", slots }` — it certifies
+nothing and cannot be committed.
 
 **Arena** — the same shape, keyed on `presetId`:
 
@@ -96,19 +104,68 @@ Both previews run the **same resolver the live sweep runs**, so the preview is t
 an estimate. Neither writes anything and neither costs the player an LLM call — so previewing
 repeatedly while iterating is free and correct.
 
-Render the preview as a card and read it out: which agent goes on duty, which slot matched and at
-what priority, the regime and conviction used, the qualification verdict, and any typed idle or
-blocked reason. **Render `section` as the server sends it — never re-derive it.** A non-null reason
-does not mean idle (`ON_DUTY_BUT_POSITION_BLOCKED` carries a reason and is not idle), so deciding
-the headline yourself gets it wrong. `enabledAfterCommit` says whether the policy will play once
-committed — a paused policy stays paused, and a first Arena deployment always plays.
+Render the preview as a card and read it out. For **Radar**: the coin's `section` and any typed idle
+or blocked reason, then every row of `resolvesNow.onDuty` in the order served — each agent, the slot
+and priority that put it on duty, its regime reading at its own `regimeTimeframe` with conviction, its
+qualification verdict and its close clock — and `readings`, one entry per on-duty agent in the same
+order: what that agent reads on the coin right now (below). For **Arena**: which agent goes on duty,
+which slot matched and at what priority, the regime and conviction used, and the qualification
+verdict. **Render `section` as the server sends it — never re-derive it, and never pick, rank or drop
+rows yourself.** A non-null reason does not mean idle (`ON_DUTY_BUT_POSITION_BLOCKED` carries a reason
+and is not idle), so deciding the headline yourself gets it wrong. `enabledAfterCommit` says whether
+the policy will play once committed — a paused policy stays paused, and a first Arena deployment
+always plays. A Radar preview simulates a running platform, so it never reports the kill switch or an
+entry pause: those come from step 1's read.
 
 **If anything changes after a preview, re-preview.** A preview never vouches for what it did not
 resolve.
 
+**A Radar preview refuses an agent the scan cannot read on the coin.** Every slot agent, on duty now
+or not, must have every condition the radar acts on — its required conditions, the ones carrying a
+verdict, its exit conditions, and every condition they reference — readable by the radar scan on this
+coin. When one is not, the preview itself is refused, issues no certificate, and nothing can be
+committed: `CONDITION_UNREADABLE_BY_RADAR_SCAN`, whose `details.context.reachReason` says why
+(`INSTRUMENT` — the market-data profile of the coin, or of a benchmark section's own instrument, carries
+no such data, or the market-data service publishes no profile for it at all: the refusal names the kind
+of data the profile lacks, or says there is none; `AGENT_TIMEFRAME` — the agent has no such rung;
+`FEED` — the radar scan never reads that data for this agent), or
+`CONDITION_OPERAND_UNSERVED_IN_LANE` for a session-field scalar. Read the player the refusal as served:
+it names the agent, the condition, the column and the fixes — stop the radar acting on the condition,
+make it read a column the radar scan has on that coin, or take the agent off the coin. A commit
+re-checks the same rule, so a strategy edit landing after the preview can still refuse it.
+
+**`readings` is each on-duty agent's requirements, read now.** A `READ` entry carries the agent's
+`reading` — the same one `get_agent_coin_qualification` returns with `reading: true`, through the same
+resolver:
+
+- `reading.live` is the reading its qualification verdict was built from: the gates with their margins
+  (`qualification`); every entry-lane condition — required, direction-setting, and the ones they
+  reference — with its outcome and its clause values against their thresholds
+  (`conditions.entries[]`); the allocated signals with their attribution; and the data it lacked
+  (`missingData`). An `UNEVALUATED` entry is a condition this tick could not read, with its
+  `reachReason`. A pair the scan can never read was refused above, so every such cause is one the next
+  sweep can change — report it as the current reading, never as a reason the deployment will not
+  work. `anchorBarStatus` says which bar the conditions read (`live` while it is still forming), and
+  `scoredBarStart` names the bar the signals and gates were scored on. **A live reading decides
+  nothing**: the radar decides at the close, on the closed bar, so say what it reads right now, never
+  that it will fire.
+- `reading.lastClose` is the one decision the agent's on-duty row names as its last close: `RECORDED`
+  with that bar's close-decision record — the reading it was decided on, or why it was missed —
+  `PENDING` while that record is still being written, or `NONE` when the pair remembers no decision.
+  For the decisions before it, call `get_radar_close_decisions` (step 5).
+
+An `UNSCORABLE` entry is an on-duty agent the preview could not read on the coin, with
+`coinDataStopped` when the coin's data explains why; it never fails the preview. `readings` is null
+under a simulated regime: duty is simulated there, and every reading would judge the real one.
+
+There is no `conditionReach` list and no `blocksScanGate` flag (contract 74.0.0). A condition's reach
+reason is its `UNEVALUATED` entry's `reachReason` in
+`readings[].reading.live.reading.conditions.entries[]`, and whether the conditions hold the coin is the
+reading's own conditions gate, `qualification.gates.requiredConditions` — never a verdict of your own.
+
 ### 3. Confirm against the preview, then commit
 
-One confirmation whose question **references what the preview showed** — the agent it put on duty and
+One confirmation whose question **references what the preview showed** — the agents it put on duty and
 the reason — and **names what the change does to the stored policy**, read from step 1:
 
 - every rule or slot the change **removes** (by agent and priority), because `RULES` and `slots` are
@@ -133,7 +190,7 @@ with the old one is refused again — only a fresh preview earns a new one.
 
 **Pause a coin's Radar** → `pause_radar_deployment({ coinId })`. No preview and no revision: stopping
 never waits on a read. The player's draft is kept. **Resume** → preview the deployed policy with
-`request: { kind: "COMMITTED" }`, tell the player what will go on duty again, and on their word
+`request: { kind: "COMMITTED" }`, tell the player which agents will go on duty again, and on their word
 `resume_radar_deployment({ coinId, previewToken, confirm: true })` with the token that preview
 returned.
 
@@ -160,25 +217,41 @@ draft** of the coin or the arena. There is no preview here, and correctly so: th
 to preview once the policy is gone. The evidence is **the deployment's own read**, which supplies the
 `expectedRevision` the delete carries — and for Arena the `expectedPolicyId` beside it.
 
-State what stops, from that read: which agents were on duty or eligible, what the policy was
-firing on, and that the slots are not recoverable. Both tools carry a schema-level `confirm: true`.
+State what stops, from that read: which agents were on duty (every row of `resolvesNow.onDuty`) or
+eligible, what the policy was firing on, and that the slots are not recoverable. Both tools carry a schema-level `confirm: true`.
 
 **If the player wants to stop trading without losing the slots, that is not a delete** — it is
 `pause_radar_deployment` for Radar and `pause_deployment_policy` for Arena. Offer that
 whenever the ask sounds like "pause", "stop for now", or "take it off duty for a while".
 
-### 5. "Why isn't it firing?" — state, then pattern, then rows
-
-Three reads, cheapest first. Stop as soon as the player's question is answered.
-
-1. **`get_radar_deployment` → `resolvesNow`** for what is true **right now**: the section, the
-   blocked reason and since when, the qualification block, the cooldown, the last fire, and which
-   agent is on duty. Most "is it working?" questions end here.
+### 5. "Why isn't it firing?" — state, then pattern, then the bar, then rows
+
+Four reads, cheapest first. Stop as soon as the player's question is answered.
+
+1. **`get_radar_deployment` → `resolvesNow`** for what is true **right now**: the coin's section and
+   reason, and one `onDuty` row per agent — its blocked reason and since when, its qualification
+   block, its cooldown, whether its edge is spent, its last fire and its close clock. A row whose last
+   close reads `CLAIMED` qualified but lost the coin's one fire that pass to a higher-priority agent;
+   its edge is preserved and it fires at a later close only if it still qualifies there. A `SCANNING`
+   coin whose reason is `ENTRIES_PAUSED` is under the entry pause (step 1): its agents still decide and
+   record every close, and a close that qualifies is held — its fire refused, its edge preserved,
+   journaled and recorded as `EDGE_PRESERVED_ENTRIES_PAUSED` with `scanBlockReason` `ENTRIES_PAUSED` —
+   so it fires at a later close only if that close qualifies on its own data after the pause lifts. A
+   lower-priority agent behind that fire reads `CLAIMED` on the same bar: the coin's one fire went to
+   the agent the pause refused, not to a trade. That is the whole answer while the pause lasts; never
+   send the player to change an agent or a policy for it. Most "is it working?" questions end here.
+   When the question is what ONE on-duty agent of a scanning coin needs to fire — which condition
+   reads false, how far a gate sits from its threshold — drill into its row
+   with `get_agent_coin_qualification({ agentId, coinTickers: [<the coin's ticker>], reading: true })`
+   and read the verdict's `reading` as step 2 of the deploy flow describes it: `live` is what the
+   agent reads now, and `lastClose` is the decision its row names as its last close, with the reading
+   that bar was decided on.
 2. **`get_radar_activity_summary`** for everything else about "why is it quiet", in ONE call. It
    carries three parts and they answer three different questions, each on its own scope:
    - `groups` — which cause recurs and how often, over the window the response names. Quote the
      counts with that window; never sum them across calls.
-   - `curveDigest` — how FAR the score sits from firing, over the on-duty agent's ring. This is what
+   - `curveDigest` — how FAR the score sits from firing, over the FIRST on-duty agent's ring (the
+     lowest-numbered slot on duty now, named in `curveAgentName`). This is what
      separates "lower the minimum two points and it fires" from "this strategy does not fit this
      coin": `bestUnqualifiedScorePercent` against `latestThresholdPercent`. Its `ringStartAt` /
      `ringEndAt` describe the ring, NOT the cause window above.
@@ -186,13 +259,33 @@ Three reads, cheapest first. Stop as soon as the player's question is answered.
      a pair quiet for longer returns no groups beside populated older rows. That is correct, not a
      contradiction; each row carries its own `occurredAt`.
 
-   For about one sweep after an agent rotation the digest can name the incoming agent while the rows
-   still show the outgoing one — the two halves are read from different stores. Say "just rotated"
-   rather than reporting a contradiction.
-3. **`get_radar_activity`** only for what step 2 cannot do: more rows than its ten, a FIRES-only
-   view, paging back through history, or ONE occurrence's full margins. Rows are lean by default —
-   pass `detail: 'FULL'` for the margin surface, and `includeCurve: true` only if something will
-   actually plot the points.
+   The groups and rows span every on-duty agent — each row names its own — while the digest describes
+   the first one. For about one sweep after the on-duty set changes the digest can name the new first
+   agent while the rows still show the old one — the two halves are read from different stores. Say
+   "duty just changed" rather than reporting a contradiction. Joins and departures are journaled as
+   `ON_DUTY_JOINED` / `ON_DUTY_LEFT`, one row per agent, and a lost coin as
+   `EDGE_PRESERVED_COIN_CLAIMED`.
+3. **`get_radar_close_decisions`** when the question is about ONE close — "why didn't the 14:00 bar
+   fire?", "why did it fire there?", "what did it see at that close?". Every bar the close step
+   decided has one record, whether a policy's agent or a manual request's watch decided it: its
+   `outcome` (`FIRED`, `NOT_QUALIFIED`, `CLAIMED` or `MISSED`), the fire's `fireDisposition` as
+   arbitration settled it, and the `evidence` the bar was decided on — the closed-bar reading's gates
+   with their margins, every condition's outcome with its clause evidence, each condition the scan
+   could not evaluate with its reach reason, the allocated signals and `missingData` — or, for a
+   `MISSED` bar, the close step's own answer: the bar never settled, an input was not on its due bar,
+   or the window passed. An `outcome` of `FIRED` says the bar qualified and its agent was offered the
+   coin's fire; `fireDisposition` says what the fire came to — `FIRED` when a decision was enqueued,
+   `EDGE_PRESERVED_ENTRIES_PAUSED` beside `scanBlockReason` `ENTRIES_PAUSED` when the entry pause
+   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 oldest returned `bar.barStart` as `before`. 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
+   FIRES-only view, paging back through history, or ONE occurrence's full margins. Rows are lean by
+   default — pass `detail: 'FULL'` for the margin surface, and `includeCurve: true` only if something
+   will actually plot the points.
 
 **Neither of the first two substitutes for the other, and the reason is structural.** The journal is
 a TRANSITION log, not a state log: a gate that has blocked continuously without crossing again
@@ -200,13 +293,18 @@ inside the window produces no group in the rollup at all. It shows up in `resolv
 else. So an empty or quiet rollup NEVER means "nothing is blocking it" — check step 1 before saying
 anything of the sort.
 
-Two negatives, both checkable:
+Three negatives, all checkable:
 
 - **Never page journal rows in order to count causes yourself.** The counts are served. Re-deriving
   them spends the player's op budget on work the server already did and floods the transcript.
 - **Never sum counts across pages, and never report a windowed count as a lifetime one.** The
   rollup's counts span every matching row inside `windowStartAt`–`windowEndAt` — quote them with
   that window ("41 times in the last 7 days"), never as a total.
+- **Never explain one close from the live verdict or the journal.** A not-qualifying close writes no
+  journal row, and the live reading is not the reading the close was decided on — at the same moment
+  the two can sit on opposite sides of a gate. Read the bar's record — `reading.lastClose` for the
+  last decision a row names, `get_radar_close_decisions` for any other — and quote it as stored;
+  never recompute it.
 
 ## Preview-before-commit: enforced for both
 

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

@@ -31,7 +31,10 @@ problem: the fix runs through the flow that owns it, with that flow's own confir
 
 Three reads, and they are not interchangeable:
 
-- **`get_agent_budget`** — the health read. `haltReason` (why it stopped, if it did),
+- **`get_agent_budget`** — the health read. `runStatus` (`blocked` / `paused` / `active` — the run-state
+  already ranked, so read it rather than re-deriving it from the fields below; a halt reads `paused` even
+  while its own `AGENT_HALTED` block stands), `haltReason` (why it stopped, if it did),
+  `haltResumeEligibility` (whether a resume would now succeed, and what still blocks it),
   `blockedReason` + `blockedSince` (the typed pipeline block currently standing, and since when),
   and `gauges` — four guardrail meters (dailyTrades, exposure, drawdown, dailyLoss), each with a
   server-computed `breached` flag. **Read `breached`; never compare fill against limit yourself.**
@@ -85,16 +88,22 @@ a diagnosis; "OPEN_POSITION_CONFLICT, 14 times, most recently 2h ago" is.
 
 ### 3. Halted agents, and healthy ones
 
-**If `haltReason` is set, name the branch that actually clears it:**
-
-- **MANUAL** — resume lifts it directly.
-- **DRAWDOWN_BREACH** — clears by raising `maxCumulativeDrawdownUsd` **or** by the drawdown
-  baseline reset, then resuming.
-- **DAILY_LOSS** — clears by raising `maxDailyLossUsd` **or** by the UTC-day rollover. **The
-  baseline reset cannot clear it. Never offer it here.**
-
-In every case, say that a resume attempted while the stop is still breached is **refused by the
-server**, with the current figure against the limit.
+**If the agent is halted, `haltReason` says why and `haltResumeEligibility` says what clears it.**
+Name the recovery from the verdict alone:
+
+- **null** — the agent is not halted. A halt the player set by hand carries a verdict like any
+  other, and is recovered through it.
+- **`eligible: true`** — nothing is still breached; resuming will succeed.
+- **`eligible: false`** — name `breachedStop`, the stop still breached, with `breachingFigureUsd`
+  against `limitUsd`, and exactly the exits the verdict marks open: raising that stop above the
+  figure (`canRaiseTriggeringStop`), the drawdown baseline reset (`canResetBaseline`), and, when
+  `breachedStop` is `DAILY_LOSS`, the UTC-day rollover. Then resuming. An exit it does not mark
+  open is never offered.
+
+Say that a resume attempted while a stop is still breached is **refused by the server**, naming the
+same stop, figure and exits. A resume the server accepts is followed by a re-check of every stop, so
+read the resume response's `haltedAt`: set means a loss settled, or a stop was lowered, while the
+resume ran and the agent was halted again at once; `get_agent_budget`'s `haltReason` names the stop.
 
 **If the reads are clean, say so.** An agent whose gauges are unbreached, whose blocks are ordinary
 no-trade verdicts, and whose deployment covers what the player expected, is working — report the

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

@@ -143,7 +143,10 @@ strategy timeframe, and at or below it the series as the frame carries it. At or
 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`.
+role. 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.
 
 **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
@@ -158,8 +161,31 @@ market-wide reads with no session dimension, so they resolve everywhere. The fiv
 scalars (`fieldPlayers`, `fieldUpBias`, `fieldBiasDir`, `captConc`, `picksSpread`) describe a game
 session the agent is playing in, and **radar runs outside one** — so a radar deployment whose
 strategy reads one is refused outright (`CONDITION_OPERAND_UNSERVED_IN_LANE`), naming the scalars it
-can read instead. The refusal lands at DEPLOY rather than at save, because a strategy carries no lane
-of its own: the same strategy is legal, and reads those scalars correctly, on an arena agent.
+can read instead.
+
+**What the radar scan can read on a coin.** Beyond the lane, a condition the radar acts on — a
+required one, one carrying a verdict, an exit one, and every condition they reference — must be
+readable by the radar scan on each coin the radar acts on for the agent, or it would be decided unread.
+What a coin can be read for is its market-data profile: the kinds of data the market-data service
+publishes that it serves for that coin, never the coin's asset class. A refusal carries
+`CONDITION_UNREADABLE_BY_RADAR_SCAN` with its `reachReason`: `INSTRUMENT` when the profile of the coin —
+or of a benchmark section's own instrument — carries no such data, or the service publishes no profile
+for it at all (spot-tape columns on a coin no spot venue lists, TradFi or crypto alike; any market-data
+column on a ticker with no catalog row), `AGENT_TIMEFRAME` when the agent has no such rung on the
+enabled ladder, and `FEED` when the radar scan never reads that data for the agent (crowd reads:
+compose reads them, but only for a coin the scan has already admitted). An `INSTRUMENT` refusal names
+the kind of data the profile lacks, or says the coin has no profile. The fixes it names: take the
+condition's radar role away (neither required nor a verdict, or no exit role), read a column the radar
+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.
 
 **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
@@ -277,11 +303,14 @@ smaller position, never more risk.
 trailingBufferPct, timeDecayEnabled, timeDecayGracePeriodMinutes, timeDecayIntervalMinutes,
 timeDecayTightenPct, timeDecayMaxTightenPct, timeDecayStaleThresholdTpProgressPct,
 decisionInvalidationExitEnabled }` — how the stop moves after entry, and when a position is
-closed for reasons other than its stop.
-
-Validated bounds: break-even trigger 0.5–2R; trailing trigger 0–2R step 0.01 (0 = trail from
-entry), giveback 25–55%, buffer 0.01–1%; timeDecay grace ≥ interval, tighten 0.1–50% to max
-1–100%, stale threshold 0–100% of TP progress. Per-mechanism flags; no umbrella switch.
+closed for reasons other than its stop. The policy is stamped on each position when it opens: an
+edit applies to positions opened after it, and an open position keeps the policy it opened with.
+
+Validated bounds: break-even trigger 0.5–2R step 0.01; trailing trigger 0–2R step 0.01 (0 = trail
+from entry), giveback 25–55% step 1, buffer 0.01–1% step 0.01; timeDecay grace 5–1440 min step 5,
+interval 5–480 min step 5, grace ≥ interval while time decay is armed, tighten 0.5–50% step 0.5,
+max tighten 1–100% step 1, stale threshold 0–100% of TP progress step 1. Per-mechanism flags; no
+umbrella switch.
 
 `decisionInvalidationExitEnabled` is the post-fill invalidation exit: a **closed**
 strategy-timeframe candle beyond the decision's invalidation level closes the position

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

@@ -44,7 +44,7 @@ new longs / new shorts / short covering / long liquidation), `MARK spread ORACLE
 `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. Rules: `funding_extreme_positive`/`_negative` 3 required
-`{"thresholdPct":0.001}` · `oi_surge` 2 `{"thresholdPct":0.03}` · `rsi_overbought` 2
+`{"thresholdAnnualizedPct":100}` · `oi_surge` 2 `{"thresholdPct":0.03}` · `rsi_overbought` 2
 `{"threshold":65}` · `rsi_oversold` 2 `{"threshold":35}` · `cvd_bear_divergence` 2 ·
 `cvd_bull_divergence` 2 · `mfi_overbought` 1 · `mfi_oversold` 1. Gates 0.6 / 1 / 0.5. Levels
 1.0–2.5 ATR, RR 1.5. PM: BE 0.8R, no trail, timeDecay ON (120/60, 10→40, stale 25).

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

@@ -70,12 +70,18 @@ re-sorts a list, re-derives a verdict, or approves on the player's behalf.
   `get_trade_conversation({ conversationId })`, using the id the `queued` result carried. It serves
   the whole transcript in stored order — the queued card, the agent's reasoning, its thesis and
   setups, the recommendation, a no-trade with its reason and next coins, or a close answer.
-- `get_entry_request` re-reads a request still pending; `cancel_entry_request` withdraws it. Both
-  are `NOT_FOUND` once it has been answered, cancelled or expired, and that is the honest record:
+- `get_entry_request` re-reads a request until it is answered — including while its close has fired
+  and the decision is being composed. `cancel_entry_request` withdraws it only while it still awaits
+  its close; once the close has fired it is `NOT_FOUND`, and the answer arrives in the conversation.
+  Both are `NOT_FOUND` once it has been answered, cancelled or expired, and that is the honest record:
   the answer is in the conversation.
 - `type: "error"` — the block, with its remedy: `OPEN_POSITION_CONFLICT` means a position already
   holds the slot (see step 0) and nothing was queued; `LLM_CREDITS_EXHAUSTED` means top up when
-  `topupAvailable` is true. A refused request (`RATE_LIMITED`) is a refusal with its retry-after.
+  `topupAvailable` is true; `ENTRIES_PAUSED` means the platform has paused new entries while market
+  data is missing across many coins, and nothing was queued. The pause is platform-wide, not the
+  agent's or the coin's, so never retry it through another agent or on another coin. It lifts by
+  itself once the data is back: ask again then, under a fresh `idempotencyKey` — the same key only
+  replays this refusal. A refused request (`RATE_LIMITED`) is a refusal with its retry-after.
   Never "nothing to do".
 - `type: "recommendation"` and `type: "no_trade"` arrive only as the **replay** of a request made
   before the queued contract shipped. Report them as step 5 describes and do not expect them from a
@@ -90,8 +96,20 @@ the player's explicit typed word — never inferred from interest, agreement, or
 trade.
 
 - 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.
+  reason and the next coins worth asking about; a refusal, `close_refused`, which names the gate that
+  failed when the close did not qualify and none when it qualified and the radar's own gates stopped
+  its fire; a window that passed with no sweep; a bar the agent's own radar deployment decided first;
+  or an error carrying the engine's block, with nothing proposed, when admission refused the
+  qualifying close's fire — `ENTRIES_PAUSED` while new entries are paused, an account block, a
+  position already held.
+- A bar the agent's own radar deployment decided first is reported from that deployment's decision,
+  never decided again. It arrives as `close_fired_by_radar` — a trade taken in full — only when the
+  deployment's fire enqueued a trade decision. Otherwise it arrives as what stopped that fire, and
+  none of these is a trade: a fire admission refused arrives as the engine's block, exactly as when
+  the refused fire was the request's own; a fire the radar's own gates stopped — its coin cooldown,
+  its hourly cap, post-close suppression, a decision already running on the coin — arrives as
+  `close_refused` with no gate, because the close qualified and nothing was entered; and a close
+  whose coin another agent's fire took arrives as `close_claimed_by_radar`.
 - On a proposal, state the direction, the entry, stop and take-profit levels, the position size,
   the **`convictionPercent`**, and the expiry (`expiresAt`). No conviction floor is applied on this
   surface: the conviction is the agent's own reading, and the player judges it.