@battlegrid/mcp-server 32.0.22 → 32.0.24

package/README.md

@@ -38,6 +38,24 @@ 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 — v129.1 (the activity feed names only events that happen)
+
+**Not breaking.** v129.1 is the contract on top of v129. No input acceptance moves and no served page changes.
+Reconnect the proxy, or restart it, so discovery reads the new schemas.
+
+### Narrowed output — a shape you read has fewer members
+
+- **`get_agent_activity_feed`**'s `eventType` no longer lists `AGENT_UPDATED`, `EARLY_ENTRY_SUBMITTED`,
+  `GRID_SUBMITTED_VIA_TELEGRAM` or `GRID_UPDATED_VIA_TELEGRAM`. Nothing records them and no stored event carries one,
+  so no row you could read changes. The historical values older rows carry — `MULTI_AGENT_DISPATCHED`,
+  `AGENT_OUTCOMPETED`, `AGENT_WON_COMPETITION`, `REASSESSMENT_TRIGGERED`, `AGENT_BLOCKED_NO_ALLOCATION` — are still
+  served.
+
+### Corrected descriptions
+
+`get_agent_activity_feed` no longer names an "updated" lifecycle event. `get_radar_activity`'s `filter` input states
+that `FIRES` keeps each fire's disposition and its evaluation outcome, which is what it has returned since v127.
+
 ## Contract history — v129 (every record list takes one time window)
 
 **Breaking at v129: `get_public_agent_realized_trades` renames its `timeframe` input to `window`, and sixteen list

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

package/skills/EXPORT.json

@@ -1,25 +1,25 @@
 {
   "generator": "battlegrid-app/server/scripts/export-mcp-skills.mjs",
-  "contractVersion": "123.1.0",
+  "contractVersion": "129.0.0",
   "files": {
-    "battlegrid-agent-management/SKILL.md": "4c2cb5cfec27cf11769d66763e024e6900c392e27a978de3080cf55b2ece7a68",
+    "battlegrid-agent-management/SKILL.md": "18c635d512ba0b9e17df11d157adff5aed0bd8cc0bfa32df3e53b5e9d3453e45",
     "battlegrid-agent-management/references/agent-stage-examples.md": "dffcc353d61dfc7b5bb6a2b3077fc6bf8c760a34c287cafb3b59b99306f24195",
-    "battlegrid-arena-play/SKILL.md": "2e37970a66b8738ffbc445a23da90651c1f41b56ce4eef551582ab123517ef74",
+    "battlegrid-arena-play/SKILL.md": "ec55a4ed41f4e54a66ddc66ef3e9e9c87c31986e83f1d66c2ae91f3557bad514",
     "battlegrid-arena-play/references/entry-stage-examples.md": "0223f3743171ff213e943789d27590b2f65648398e85e10cd24938d5eb6af665",
     "battlegrid-market-analysis/SKILL.md": "fcbe98e30e1edce39bb170c224cdf20181934f62b5f3a26b293787c70eeb6229",
     "battlegrid-officers/SKILL.md": "3fd59ec301d1492c956fbdb4368fef61f29abd137f02f49a6172351c7a563309",
     "battlegrid-officers/references/officer-stage-examples.md": "ef46ba26f4b36c9964b5bde95fdf98e5952c3786b77be5f136056cac792f0aec",
-    "battlegrid-radar-deployment/SKILL.md": "cf6664f51f92d40acce21a46f4fb078d9afe46c99c4f4b603bf002e73d4c5a23",
+    "battlegrid-radar-deployment/SKILL.md": "b344cd3d2051153115ce9840606e6a08a140f704d5da6a10fca18d81c3796be6",
     "battlegrid-radar-deployment/references/arena-stage-examples.md": "d27cfed1f4663f267c4a7ecebe4a6e65a450fc74bd14ce8987fb61af5bbf2ca5",
     "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-doctor/SKILL.md": "f15bce81a95b3cc6f1e8ebf3008ec56f7d100f74a5e3e85fc46cdd26554ed807",
     "battlegrid-strategy-examples/SKILL.md": "9d18bf0e4bf85a28508e2881a4cdf77b823ec831e7cec5d82f82dc251402f41c",
     "battlegrid-strategy-examples/references/playbooks.md": "a9464789df2e762faf9dbd7845101564bc1847cd193f709f8ac4b6bff08f09dd",
     "battlegrid-strategy-examples/references/recipes.md": "806aae0b4842408f6e6ed3e108293073f4f31d1c27fa419ad57df9e1134f23e7",
     "battlegrid-strategy-examples/references/tradingview-ports.md": "c62ce72b741abe5a92e1dec6615f26b19a54959aa1d29542518cd9a189390b98",
-    "battlegrid-trade-analysis/SKILL.md": "3f927b4f9796178526fa1673a2043c5f14358c39aa955de33192ea58641f18fb",
-    "battlegrid-trade-proposal/SKILL.md": "e761fc6bddc0d1db79fcb90046d03a18439562c8658de726ec286830edd6369b"
+    "battlegrid-trade-analysis/SKILL.md": "66bd5d057f7b933bff32192305e761c11e004512fd5d867c0ec2cd3dcd19ffda",
+    "battlegrid-trade-proposal/SKILL.md": "8e20ce1206ae51f1f87c6e940c8b7ed2798dcd2dfc8d9a2f82adf1a4d0817313"
   }
 }

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

@@ -1,6 +1,6 @@
 ---
 name: battlegrid-agent-management
-description: Commission and govern the player's intelligence agents — interview and create one against a committed strategy and an approved model, change its configuration and risk limits, rebind it to another strategy, halt and resume it, archive and reactivate it, and act on its live positions (close, or move a stop outside the platform ratchet). Activate whenever the player wants a new agent, wants to change, pause, restart, retire or revive an existing one, asks what an agent is allowed to risk, or wants to intervene in a position an agent has open.
+description: Commission and govern the player's intelligence agents — interview and create one against a committed strategy and an approved model, change its configuration and risk limits, rebind it to another strategy, halt and resume it, archive and reactivate it, and act on its live positions (close one, or move its stop or take-profit outside the platform ratchet). Activate whenever the player wants a new agent, wants to change, pause, restart, retire or revive an existing one, asks what an agent is allowed to risk, or wants to intervene in a position an agent has open.
 ---
 
 # Agent Management
@@ -158,8 +158,8 @@ again only on their word.
 ### 4. Lifecycle verbs: read first, state the radius, then confirm
 
 Every one of a draft commit (an edit or a rebind), halt, resume, activate and archive runs this
-shape. The reads (`get_agent_budget`, `get_agent_fund_allocation`, `get_agent_open_positions`,
-`get_agent_automation_status`, `get_agent_performance`, `get_agent_journal`) need no confirm and
+shape. The reads (`get_agent_budget`, `list_user_active_positions`, `get_agent_automation_status`,
+`get_agent_performance`, `get_agent_thought_log`) need no confirm and
 cost nothing but a call — do them first, always.
 
 State the blast radius **from server fields, as numbers**, before the confirm form:
@@ -244,23 +244,37 @@ partial config and never echo a read config back unchanged: the agent's read sha
 the axis (`strategyTimeframe` and `regimeTimeframe` are strategy-derived and refused as unknown
 keys). The commit holds the configuration to the same risk rules the agent form's Save applies.
 
-### 7. Live positions: present the served state, name the bypass
-
-- `get_agent_open_positions` / `list_user_active_positions` / `get_position_audit_history` first —
-  the `decisionId` these two tools need is discoverable only through those reads.
-- **`close_agent_position`** is irreversible: it submits a reduce-only market order and realizes
-  the P&L. It carries a schema-level `confirm: true`, so present the position, its unrealized
-  P&L and its protections, and confirm before calling. An exchange rejection comes back as a typed
-  trading error — report it; a success means the close order was *accepted*.
-- **`override_agent_protection`** moves the effective stop — the stop-loss only; take-profit is not
-  overridable here. It names the stop it replaces by `effectiveStopLossOrderId`, which
-  `get_position_audit_history` serves. Its confirm must say, in words, that
-  the change **moves the stop outside the platform's protective ratchet** — that is exactly what
-  the tool is for — and name the direction: whether the new level sits further from or closer to
-  price than the one the platform is holding. Present the current protection first, then the
-  requested level, then that sentence. Its `result` is discriminated by `kind`: only `committed`
-  advanced anything; every other branch names why the amendment did not apply — read it, do not
-  assume the write landed.
+### 7. Position management: read, close, move the stop or the take-profit
+
+1. **Read first.** `list_user_active_positions` serves each open position's `decisionId`, its live
+   `effectiveStopLoss` and `effectiveTakeProfit`, the mark and the trailing state. Those are the
+   only inputs a write needs. Never take a write's inputs from `get_position_audit_history` — it
+   is history, not the live position — and never ask the player for an order id.
+2. **Close.** `close_agent_position({ decisionId, confirm: true })` is irreversible: it submits a
+   reduce-only market order and realizes the P&L. Present the position, its unrealized P&L and its
+   protections, and confirm before calling. An exchange rejection comes back as a typed trading
+   error — report it; a success means the close order was *accepted*.
+3. **Move the stop, the take-profit, or both.**
+   `override_agent_protection({ decisionId, stopLossPrice?, takeProfitPrice? })` — send only the
+   leg the player is moving; no order id. A stop must sit on the loss side of the live mark and a
+   take-profit on its profit side: a level the mark has already crossed would fill on arrival, so
+   the server refuses it as `level-crossed`, naming the mark.
+4. **What automation does after a move.** Trailing, break-even and time decay keep running and only
+   ever tighten from the new stop: a tighter stop stands until a mover beats it, a looser stop holds
+   only until an automated candidate beats it, a break-even that already committed never returns,
+   and time decay steps from the new stop. A moved take-profit changes nothing the movers compute —
+   they keep reading the signal's take-profit.
+5. **Confirm before every write, and read the result leg by leg.** For each leg, name the current
+   level → the requested level and the direction (closer to or further from price). Say, in words,
+   that the change **moves the stop outside the platform's protective ratchet** — that is exactly
+   what the tool is for — and what automation does afterwards (step 4). Present the current
+   protection first, then the requested levels, then those sentences. The answer's `success` is
+   true only when every requested leg committed. `level-crossed`, `mark-unavailable` and
+   `rate-limited` refused the whole request and wrote nothing; on `level-crossed` report the mark
+   it names and, when the player's intent is to exit now, offer `close_agent_position` — never
+   retry the same level. Under `dispatched`, read `stopLoss` and `takeProfit` on their own: only a
+   `committed` leg moved, a `queued` stop is recorded and will apply, and every other outcome names
+   why that leg did not move — do not assume the write landed.
 
 These tools carry no consent gate on either door: they are ownership-gated and behave identically
 in chat and through an external MCP client. Your confirm is interaction, never authorization —

package/skills/battlegrid-arena-play/SKILL.md

@@ -151,7 +151,7 @@ player's, and the attribution is part of what was scored.
   `reasoning` is null when no record describes the current picks — say that rather than
   reconstructing one, and a pick missing from `reasoning.picks` is one the player chose.
   `list_my_market_grid_entries` is the history across sessions. An agent's decisions are a different
-  record, `get_agent_journal`.
+  record, `get_agent_thought_log`.
 
 ## On the arena's session page
 

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

@@ -17,8 +17,8 @@ no slot shape, no condition union and no resolution type. Never carry a fact fro
 and never describe them as one thing with two modes.
 
 **Deployments are the autonomous trading switches.** An agent has no trading mode of its own: it
-trades a coin on its own only where a Radar policy puts it on duty, and a proposal the player
-approves needs no deployment. An Arena deployment enters an agent into a preset's sessions and grants
+trades a coin on its own only where a Radar policy puts it on duty, and an entry the player queues
+needs no deployment. An Arena deployment enters an agent into a preset's sessions and grants
 **no** trade permission — to have an agent trade a coin on its own, deploy it on Radar.
 
 ## The five failures this flow exists to prevent

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

@@ -57,8 +57,12 @@ Three reads, and they are not interchangeable:
   — they describe different stages and merging them invents a cause.
 - Render every code through its display meta. A raw `NO_ENTRY_CONDITION` or `OPEN_POSITION_CONFLICT` on
   screen is a system identifier leaking into an explanation.
-- **`get_agent_decision_context` is keyed by COIN**, not by agent. Use it for "why did nothing
-  happen on SOL", once you know which coin the blocks are about.
+- **`get_agent_decision_context` reads the decision behind an OPEN position.** It is keyed by coin
+  and answers only for the agent position open on it; for a coin with nothing open it is `null`, so
+  it never explains a trade that did not happen. For "why did nothing happen on SOL", read
+  `list_gate_blocks` for the pre-model refusals on that coin, and for a Radar coin
+  `get_radar_activity_summary` for its causes, then `get_radar_close_decisions` for the bars it
+  decided.
 - **`get_agent_coin_qualification` answers the forward-looking half.** The reason codes above say
   why an agent did NOT trade in the past; this says whether a coin would route for it RIGHT NOW,
   and which gate stops it — the strategy's entry condition, candidate levels, the ATR% volatility
@@ -80,11 +84,12 @@ Three reads, and they are not interchangeable:
   or `ORPHANED` it is not — the agent runs a materialized copy at its own `strategyRevision` — so
   name the binding state beside the definition rather than letting current rules read as running
   ones.
-- **Gate blocks link to their thought log** through `sourceThoughtLogId` — follow it with
-  `get_agent_thought_log` when the block's reason needs the evaluation behind it.
-- `get_signal_performance` / `list_signal_logs` when the question is whether the signals fired, as
-  distinct from whether the trades made money. `list_trade_outcomes` and `get_agent_journal` for
-  what did happen.
+- **A gate block carries the evaluation that refused it** in its `decisionRecord` — read it there
+  when the block's reason needs the evaluation behind it; there is no id to follow to another read.
+- `list_signal_logs` narrowed by `agentId` when the question is whether the signals fired, as
+  distinct from whether the trades made money: its `summary` counts the evaluations and entries, and a
+  failed row's `rejection` names why its order was refused. `list_agent_trades` narrowed by `agentId`,
+  `get_agent_thought_log` and `get_agent_activity_feed` for what did happen.
 - **`get_agent_conviction_calibration` honours `readiness`.** An `INSUFFICIENT_DATA` calibration
   carries no win rate — report that there is not yet enough history, never a rate derived from a
   handful of trades.

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

@@ -14,7 +14,7 @@ Start with where the money is, always, even when the question is narrower — a
 means nothing without the whole.
 
 - `get_account_state` for the account total.
-- `get_agent_budget` for each agent's capital at risk, and `get_agent_fund_allocation` for its funding envelope.
+- `get_agent_budget` for each agent's capital at risk.
 
 Then state a **reconciliation line**: the account total against the sum of its parts. If they
 agree, say they agree. **If they do not, state the gap as a gap** — name the amount and say you
@@ -32,18 +32,46 @@ Not "what were its returns" — whether it did *the thing it was told to do*.
   gate — and its trade levels with the ATR floor, not the agent's overlay prose. Read `bindingState` too: at `SYNCING` or `ORPHANED` the agent evaluates a materialized copy
   at its own `strategyRevision`, and judging it against the strategy's current revision measures it
   by rules it is not running.
-- `get_agent_performance` and `list_trade_outcomes` — judge against that mandate.
-- `get_trade_outcome_by_decision` / `get_trade_chart` when a specific trade needs explaining. A
+- `get_agent_performance` and `list_agent_trades` narrowed by `agentId` — judge against that mandate. Its
+  `summary` and `resultSummary` cover the agent's whole scope on the player's account, not the page.
+- `get_trade_outcome_by_decision` (a trade row's `decisionId`) / `get_trade_chart` when a specific trade
+  needs explaining: the outcome carries the fills, fees, slippage, leverage, duration and exit label. A
   measurable trade's `tradeExcursion` reads in R: `mfeR` and `maeR` (the best and worst it reached),
   `exitR`, and `giveBackR` (what it surrendered between its peak and the close). `exitEfficiency` is
   a union — branch on its `state` before reading `efficiencyPercent`. All of them are gross of
   costs; `netPnl` is the after-fee figure.
-- The record around the trades: `list_my_market_grid_entries` (the player's Market Grid entries —
-  `agentId` for one agent's, none for every entry), `get_agent_thought_log` and
-  `get_user_thought_log` (the reasoning), `get_agent_activity_feed` and `get_user_activity_feed` (what
-  happened), and `get_agent_explorer` for where the agent stands among public agents.
-- `get_signal_performance` when the question is whether the agent's signals are working, as
-  distinct from whether its trades made money.
+- The record around the trades: `get_agent_thought_log` (an agent's decisions), `get_signal_log` (a
+  trade's reasoning and its pipeline), `list_my_market_grid_entries` / `get_my_market_grid_entry` (an
+  arena entry's reasoning — `agentId` for one agent's entries, none for every entry),
+  `get_agent_activity_feed` (what happened), and `get_agent_explorer` for where the agent stands
+  among public agents.
+- `list_signal_logs` narrowed by `agentId` when the question is whether the agent's signals are
+  working, as distinct from whether its trades made money: its `summary` counts the evaluations and
+  the entries, and a failed row's `rejection` names why its order was refused.
+
+### What past decisions would have done
+
+A question about a skip, an unfilled entry, or "if it had traded, would we be up?" is answered from
+the platform's recorded forward marks, never from today's price.
+
+- Select the decisions with `list_signal_logs`, then read each one's `get_signal_debrief` (the row's
+  `agentId`, and its `id` as `logId`). When the question is the agent-wide pattern rather than named
+  decisions, read `get_agent_decision_quality`.
+- **Never mark a past decision against a current price.** A market-context read, a live mark or any
+  price read now answers a different question. The debrief's marks are anchored at the decision
+  (`decisionAnchor`) and, for a closed trade, at the exit (`exitAnchor`).
+- SKIP and UNFILLED figures (`grossOfCosts: true`) are counterfactual and gross of fees, slippage and
+  funding. Quote them as recorded marks — what the market did — never as money the agent made, lost
+  or left on the table.
+- While `verdict` is null the call is undecided: quote the RESOLVED rows' `signedReturnPct`,
+  `favorableExcursionPct` and `adverseExcursionPct` as recorded, name each PENDING row's `maturesAt`
+  as when that window completes, and claim neither a stop-out, a target hit nor a profit.
+- While the verdict is pending, whether the staged stop or target was reached is read from
+  `planOutcome` on that decision's `list_signal_logs` row, and from nothing else. Never turn a
+  return or an excursion in the debrief into a stop-out or a target hit.
+- A non-null verdict is reported by its label in words, beside the server's `verdictDetail`.
+- A `{ debrief: null }` result is **UNDETERMINED** for that decision: say the read gave none, and
+  never estimate it another way.
 
 **Name the blemishes.** A verdict with no flaw in it is not a verdict, it is a summary. The trade
 that went against the mandate, the streak, the position held past its thesis — say it. A player
@@ -53,17 +81,16 @@ reading a clean report about a messy account learns nothing.
 
 - `list_user_active_positions` for everything at once: it carries the live mark and P&L
   (`markPrice`, `unrealizedPnlUsd`, `roePct`) — check `pricingStatus` and `generatedAtMs` before
-  calling a mark current. `list_session_agent_positions` is the same view for one Market Grid
-  session. `get_agent_open_positions` is an entry-only view with no live mark: never measure a
-  distance to a trigger from it.
+  calling a mark current. Every position is served once, in `positions`, naming its `agentId` and
+  `marketGridSessionId`; `agents` carries each agent's group figures.
 - For each open position, report its protections **and how far the live mark sits from each
   trigger** — a stop is a number the player cannot act on; "3.1% from the stop" is one they can.
-- `get_decision_order_attribution` maps an executed order back to the decision that placed it.
-  `get_open_orders` and `get_order_status` read the exchange directly — slower, and they fail when
-  the exchange is unreachable; report that as UNDETERMINED, never as no orders.
+- `list_agent_open_orders` is the platform's record of each agent order, naming its `decisionId` and
+  the venue's `exchangeOrderId` and `cloid`. `get_open_orders` reads the exchange directly — slower,
+  and it fails when the exchange is unreachable; report that as UNDETERMINED, never as no orders.
 - `get_deployment_policy` / `get_radar_deployment` when the protection state comes from standing
-  policy rather than the position itself. `list_pending_approvals` and `list_gate_blocks` when
-  something looks like it should have fired and did not.
+  policy rather than the position itself. `list_gate_blocks` when something looks like it should
+  have fired and did not.
 
 ## 4. Automation health — unprompted
 

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

@@ -1,20 +1,22 @@
 ---
 name: battlegrid-trade-proposal
-description: Find and stage a trade for one of the player's agents, for the player to approve. Activate whenever the player asks which coins fit an agent right now, which of their agents fits a coin, wants a trade found or proposed for an agent or on a coin, asks the agent to evaluate a coin, or wants to approve or decline a proposal it made. The scans are the agents' own gates — one agent over every active coin, or one coin over every one of the player's agents; a proposal is QUEUED for the agent's next strategy-bar close and answered into the conversation when that bar is decided; approval is always the player's word.
+description: Find a trade for one of the player's agents and, on the player's consent, queue it to execute at the agent's next strategy-bar close. Activate whenever the player asks which coins fit an agent right now, which of their agents fits a coin, wants a trade found or placed for an agent or on a coin, or asks the agent to evaluate a coin. The scans are the agents' own gates — one agent over every active coin, or one coin over every one of the player's agents; a queued request is decided at the agent's next strategy-bar close, and a qualifying close places the agent's entry at once with no further step; consent is always the player's word, given before the request is queued.
 ---
 
 # Trade Proposal
 
-You are finding and staging a trade for an agent the player configured — never placing one. Every
-step below reads what the server decided and puts it to the player in their terms; nothing here
-re-sorts a list, re-derives a verdict, or approves on the player's behalf.
+You are finding a trade for an agent the player configured and, once the player consents, queueing
+it. Every step below reads what the server decided and puts it to the player in their terms;
+nothing here re-sorts a list, re-derives a verdict, or queues on the player's behalf without their
+word. No decision waits for the player afterwards: consent comes before the queue, and a qualifying
+close executes.
 
 ## 0. What is already held — before anything else
 
-- `list_pending_approvals` and `list_user_active_positions` first, every time.
-- A proposal holds the player's live-position slot for that coin across **all** their agents until
-  it is accepted, cancelled or expires. **Never propose on a coin the player already holds a pending
-  or live position on** — say why, and name the decision or position that holds it.
+- `list_user_active_positions` first, every time.
+- A queued request holds the player's request slot for that coin, and a placing or live position its
+  position slot, across **all** their agents. **Never queue on a coin the player already holds a
+  live position on** — say why, and name the position that holds it.
 
 ## 1. When the player names a coin and not an agent — choose the agent
 
@@ -46,15 +48,23 @@ re-sorts a list, re-derives a verdict, or approves on the player's behalf.
 - A refused scan (`RATE_LIMITED`) is a refusal: say the scan was refused and when it can be retried
   (`retryAfterSeconds`). Never say "nothing fits".
 
-## 3. Queue the request
+## 3. Confirm, then queue the request
 
-- `propose_entry_decision` **only** on the coins the player named, or on the top qualifying row
-  when they asked for the best fit. One coin per call.
+- **Confirm with the player before queueing.** Name the agent, the coin and the bar it will be
+  decided on, and say that a qualifying close places the agent's entry at once, sized by the agent's
+  own risk budget, with no further step. Ask, and queue only on their yes.
+- **The player's own words can already be the consent.** "Trade SOL with Atlas at its next close" is
+  consent: queue without asking again. So is a standing instruction the player gave you to trade for
+  them. Interest is not consent — "what fits SOL right now?" is a question, so report the fit and ask
+  whether to trade it.
+- `propose_entry_decision` **only** on that consent, and only on the coins the player named, or on
+  the top qualifying row when they asked for the best fit. One coin per call.
 - **The call does not decide.** It registers a request against the agent's next strategy-bar close
   and returns immediately; no model runs and nothing is spent. The agent reads that bar on its
   settled close, through the same path its radar deployments use.
-- `userMessage` is the player's own words for the turn. Mint a **fresh UUID** `idempotencyKey` per
-  request; a retry with the same key replays the recorded result and never registers a second one.
+- `userMessage` is the player's own words for the turn; it is recorded in the conversation and read
+  by no model. Mint a **fresh UUID** `idempotencyKey` per request; a retry with the same key replays
+  the recorded result and never registers a second one.
 - **One pending request per coin.** A second is refused with `CONFLICT` / `REQUEST_PENDING` — read
   the one that exists with `get_entry_request` rather than asking again.
 
@@ -64,18 +74,19 @@ re-sorts a list, re-derives a verdict, or approves on the player's behalf.
   (`barStart`), when the answer is due (`decidesBy`), and the deadline past which that bar can no
   longer be decided (`windowEndsAt`). `decidesBy` and `windowEndsAt` are different instants — a bar
   that has already settled is decided at the next sweep, seconds away.
-- Say where the answer will appear: on the delegation card in this conversation, and — if it
-  proposes a trade — in `list_pending_approvals`. Nothing further is needed from the player until
-  then; the card carries the answer to them when the bar closes.
+- Say where the answer will appear: on the delegation card in this conversation. Nothing further is
+  needed from the player; the card carries the answer to them when the bar closes, and a qualifying
+  close's entry is already being placed by then.
 - When the player asks what the agent decided, read the request's conversation with
   `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.
+  setups, the entry card naming the decision and the position it placed, a no-trade with its reason
+  and next coins, or a close answer.
 - `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.
+  and the decision is being composed, and past its deadline until its overdue answer lands.
+  `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 or cancelled, 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; `ENTRIES_PAUSED` means the platform has paused new entries while market
@@ -84,25 +95,20 @@ re-sorts a list, re-derives a verdict, or approves on the player's behalf.
   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
-  fresh call.
 
-## 5. When the answer arrives — approve or decline only on the player's word
+## 5. When the answer arrives — report it
 
-**On a web Commander surface the approval is the card's own.** The decided close lands on the
-delegation card in this conversation, carrying the player's Accept and Decline. `accept_entry_decision`
-and `cancel_entry_decision` remain yours for the external and Telegram doors, and on the web only on
-the player's explicit typed word — never inferred from interest, agreement, or a question about the
-trade.
+Every request that is not withdrawn is answered exactly once, in the conversation.
 
-- 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 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 decided close produces one of: an **entry** — the thesis, the setups and the entry card naming
+  the decision and the position it placed, which is already executing; a no-trade with the 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; `close_missed`, naming the bar, when its window passed with no sweep; a bar the agent's own
+  radar deployment decided first; or an error carrying the engine's block, with nothing entered,
+  when admission refused the qualifying close's fire — `ENTRIES_PAUSED` while new entries are
+  paused, an account block, a halted agent, a position already held — or `EVALUATION_FAULTED` when
+  the decision that fired did not finish.
 - 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
@@ -111,14 +117,9 @@ trade.
   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.
-- Present it and **ask**. `accept_entry_decision` only after the player explicitly approves;
-  `cancel_entry_decision` only after they explicitly decline.
-- Never accept because the conviction reads high, because the scan ranked the coin first, or
-  because the player asked you to "find a trade" — finding is not approving. `get_entry_decision`
-  re-reads the row if the conversation moved on before they answered.
-- Only a conversational decision awaits the player: radar fires and arena challenge reactions
-  execute on their own. `list_entry_decisions` with `status: PENDING` lists the ones still waiting
-  for an agent.
+- On an entry, read the decision with `get_entry_decision` and state the direction, the entry, stop
+  and take-profit levels, the position size, the **`convictionPercent`**, and the position's state —
+  placing, working, open, rejected or expired. No conviction floor is applied on this surface: the
+  conviction is the agent's own reading, and the player's consent was the gate.
+- Open positions, once filled, are `list_user_active_positions`'s; closing one happens only on the
+  player's word.