@battlegrid/mcp-server 31.2.64 → 31.2.66

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

@@ -22,8 +22,8 @@ step named beside it before doing anything else.
    verb that changes what the agent may do.* Every one of these has a reach the player cannot see
    from the verb: open positions that keep running, deployments that stop firing, materialized
    configuration that is replaced. State the reach from the reads BEFORE the confirm form. And a
-   configuration change to an agent the player is mid-edit on is staged, not committed. → steps 3
-   and 4.
+   configuration change is staged into the agent's draft and committed only on the player's
+   explicit pick. → steps 3 and 4.
 3. **Mis-lever'd halt recovery.** *Cue: "why is it stopped", "start it again", any halted agent.*
    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.
@@ -33,16 +33,17 @@ step named beside it before doing anything else.
 
 ## Cross-skill rule: strategy changes are not yours
 
-`list_strategies` and `get_strategy` are yours — the binding lookup is part of commissioning.
-`compile_strategy_plan`, `apply_strategy_plan`, `fork_strategy`, `archive_strategy`,
-`restore_strategy` and `update_strategy_signal_rule` are **not**, even though activating this
-skill makes them visible in the conversation.
+`list_strategies` and `get_strategy` are yours — the binding lookup is part of commissioning, and
+which strategy an agent is bound to is the agent's own STRATEGY_BINDING axis (step 4).
+`stage_strategy_draft`, `commit_strategy_draft`, `discard_strategy_draft`, `fork_strategy`,
+`archive_strategy` and `restore_strategy` are **not**, even though activating this skill makes them
+visible in the conversation.
 
 When the work is a strategy change, activate `strategy-authoring` and let its arc run — its
-evidence, spec-lock, compile-review and confirm rules bind from that point. Do not drive a
-strategy write from this arc's own steps. (Visibility is not authority: those tools keep their own
-server gates — plan token, schema confirm, ownership — and this rule is about which arc's
-discipline governs the change, not about what the server would accept.)
+evidence, spec-lock, stage-review and confirm rules bind from that point. Do not drive a strategy
+write from this arc's own steps. (Visibility is not authority: those tools keep their own server
+fences — the draft version, the revision, ownership — and this rule is about which arc's discipline
+governs the change, not about what the server would accept.)
 
 ## Sequence
 
@@ -53,8 +54,8 @@ discipline governs the change, not about what the server would accept.)
   currently-available models; a model you remember from another agent may be deprecated, which
   keeps serving agents already bound to it while refusing a new selection. Never name a model
   from memory. **Send the row's `modelId`** — the `provider/name` string, e.g. `z-ai/glm-5.3` —
-  never its `id`. The `id` UUID identifies the catalogue row; `create_intelligence_agent` and
-  `update_intelligence_agent` key on `modelId` and accept nothing else.
+  never its `id`. The `id` UUID identifies the catalogue row; the draft's MODEL axis,
+  `{ modelId }`, keys on `modelId` and accepts nothing else.
 - `list_strategies` — the binding candidates.
 - `list_agent_drafts` — what the player is already part-way through. **Mention an existing draft
   before starting new work** — "you have an unsaved <agent / new agent>, last touched from
@@ -63,7 +64,7 @@ discipline governs the change, not about what the server would accept.)
 Read each thing once. A roster or agent you already fetched in this conversation is still in front
 of you; re-fetching costs the player the same payload twice and it rides every later step.
 
-### 2. Commission: interview, restate, confirm, create
+### 2. Commission: interview, restate, draft, confirm, commit
 
 **No strategy, no agent.** If the player has no committed strategy they could bind, say so and
 offer the `strategy-authoring` arc first. Do not fabricate a binding, do not pick one on their
@@ -74,23 +75,29 @@ One interview with the player covering: **mandate** (what is this agent for), **
 scores and the strategy's own description, as the tools returned them.
 
 When the picks come back, restate in one line: *"Commissioning: <name>, bound to <strategy>, on
-<model>, <risk posture>."* Then one confirmation naming **the strategy, the model, and the
-budget posture** — the capital ceiling and stops the trading configuration will carry, or that it
-will take platform defaults.
+<model>, <risk posture>."*
 
 **Build it in a create draft.** As the picks come back, stage them with `stage_agent_draft` —
-omit `agentId` and send `draftVersion: 0` on the first call, then reuse the id and the `version` it
-returns — each axis WHOLE: IDENTITY
-`{ displayName }`, BEHAVIOR `{ behavior: { risk, outlook, conviction } }`, MODEL `{ modelId }`,
-TRADING_CONFIG with every agent-owned field, and STRATEGY_BINDING `{ strategyId }`. The build then
-survives a refresh, lists in the Agents Hub as *not yet created*, and opens on the create screen,
-where **the player's Save creates it**. Staging creates nothing and spends no slot.
-
-Call `create_intelligence_agent` yourself only when the player asks you to create it from this
-conversation — on a surface with no create screen to save from — with an **`idempotencyKey`**
-derived from this conversation and this confirm turn. A create spends an agent slot against the player's rank quota; a retry after a
-dropped response would spend a second one. With the key, an ambiguous retry replays the original
-result instead.
+omit `agentId` and send `draftVersion: 0` on the first call, then reuse the id it mints and the
+`version` it returns — each axis WHOLE: IDENTITY `{ displayName }`, BEHAVIOR
+`{ behavior: { risk, outlook, conviction } }`, MODEL `{ modelId }` and STRATEGY_BINDING
+`{ strategyId }`, all four required to create, plus TRADING_CONFIG with every agent-owned field —
+or no TRADING_CONFIG at all, to take the platform seed. The build then survives a refresh, lists in
+the Agents Hub as *not yet created*, and opens on the create screen, where **the player's own
+Create creates it**. Staging creates nothing and spends no slot.
+
+**Then read it, confirm it, and commit it.** `get_agent_draft` serves the draft, its
+`draftVersion`, a `committedRevision` of `null` and the diagnostics: a missing or invalid axis is
+an error there, named, before anything is spent. A create draft has no impact. Then one
+confirmation naming **the strategy, the model, and the budget posture** — the capital ceiling and
+stops the trading configuration will carry, or that it will take the platform seed — and on the
+player's explicit pick call `commit_agent_draft` with the `agentId`, that read's `draftVersion` and
+`expectedRevision: null`. Where the player has the create screen open, their own Create is the
+other way to commit it.
+
+A create spends an agent slot against the player's rank quota, decided by the commit itself: a
+full quota is refused there, with the draft unchanged. A retry of the same draft version after a
+dropped response replays the original receipt, so an ambiguous retry never spends a second slot.
 
 **When the mandate names the arena, read `get_account_state` in the same breath.** The arena needs
 Agent Wagers: `mcpWagerEnabled: false` means every entry will be refused at the fee, so say the
@@ -100,39 +107,48 @@ Profile → Wallet tab path instead, because no control renders there. **Create
 way**: the consent gates entering a game, never commissioning one. A `true` flag is consent alone
 and not readiness — the pipeline's own refusal at the fee is the authority.
 
-### 3. Stage, review, commit — never commit around an open draft
+### 3. Stage, read, confirm, commit — every change goes through the draft
 
 Before proposing any change to an existing agent, `get_agent_draft`. **A draft means the player is
-mid-edit in their form.** Then:
-
-- **Stage** the change with `stage_agent_draft`, naming as `draftVersion` the `version` the read you
-  proposed against returned (0 when `get_agent_draft` returned null): it lands in their open form,
-  labelled as yours, and **their Save commits it** together with their own edits.
-  `update_intelligence_agent` and `rebind_intelligence_agent` are REFUSED while the draft exists —
-  that refusal is the server's, so do not retry them.
-- A staging call **refused naming an axis** means the player changed it after the version you name:
-  read again and propose against what they now have — never re-send the same values. A call refused
-  because that version is one the draft never reached means the draft you read is gone: read again.
-  Never raise the number to get past either refusal.
-- **Rebinding is never staged.** While a draft is open, ask the player to save or discard it first.
-- `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.
+mid-edit in their form**, and every change you make joins it. Then:
+
+- **Stage** the change with `stage_agent_draft`, naming as `draftVersion` the `draftVersion` the
+  read you proposed against returned (0 when it found no draft): it lands in their open form,
+  labelled as yours. Each axis you send is written WHOLE — BEHAVIOR carries all three of risk,
+  outlook and conviction, TRADING_CONFIG the complete configuration (step 6) — and the axes you
+  omit keep their values.
+- **Read the stage's diagnostics.** Its `errors` are the refusals the commit would raise, each
+  naming its field: fix the axis and stage again before you ask for anything.
+- A staging call refused **`DRAFT_AXIS_CONTESTED`** names an axis the player changed after the
+  version you named: read again and propose against what they now have — never re-send the same
+  values. One refused **`DRAFT_VERSION_MOVED`** names a version the draft never reached, or a draft
+  that is gone: read again. Never raise the number to get past either refusal.
+- **Commit** through step 4: read the draft with `get_agent_draft`, state the radius from its diff
+  and impact, confirm, and on the player's explicit pick call `commit_agent_draft` with the
+  `agentId` and exactly the `draftVersion` and, as `expectedRevision`, the `committedRevision` that
+  read returned. The commit publishes every axis the draft holds — the player's own unsaved edits
+  included — so the confirmation reads out the whole diff, not only your proposal. Where their form
+  is open, their own Save is the other way to commit it.
+- **Discard** only on the player's word. `get_agent_draft` is the read of what a discard destroys:
+  tell them what the draft holds, when it was last written and from which surface, ask, and call
+  `discard_agent_draft` with the `agentId` and the `draftVersion` you read. There is no dry run and
+  no confirmation parameter: a draft written since your read is refused with `DRAFT_VERSION_MOVED`
+  and nothing is removed — read again and show them.
 
 **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.
+at. Their own Create or Save commits it; commit it yourself only when they explicitly confirm
+through `ask_user`. On an existing agent a strategy change is staged into the draft's
+STRATEGY_BINDING like any other axis, and lands in their Strategy step as a proposed binding. An
+axis their form rewrote after your proposal — typed over or undone — is their answer: propose it
+again only on their word.
 
 ### 4. Lifecycle verbs: read first, state the radius, then confirm
 
-Every one of update, rebind, halt, resume, activate and archive runs this shape. The reads
-(`get_agent_budget`, `get_agent_fund_allocation`, `get_agent_open_positions`,
+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
 cost nothing but a call — do them first, always.
 
@@ -140,20 +156,32 @@ State the blast radius **from server fields, as numbers**, before the confirm fo
 
 - **Halt** — the open-position count (they keep running; halting opens no exit) and the deployment
   coverage that stops producing entries.
-- **Archive** — the same, plus that the agent stops entering games and signal evaluations, and
-  that `activate_intelligence_agent` reverses it.
-- **Rebind** — that the target strategy's context modules, signal rules, prose and timeframe
-  **replace** the ones materialized on the agent (this is not a merge), naming both strategies.
-  Agent-owned settings are untouched.
-- **Update** — the concrete diff: each field, from what, to what.
+- **Archive** — the same, plus that the agent stops entering games and signal evaluations, that
+  `activate_intelligence_agent` reverses it, and that the player's draft of it is kept.
+- **Rebind** — a strategy change is the draft's STRATEGY_BINDING axis: stage `{ strategyId }`, read
+  `get_agent_draft`, and take both strategies from its `impact.rebind` — the strategy it replaces
+  (`fromStrategyName`) and the one it binds (`toStrategyName`, at `toStrategyRevision`). Say that
+  the target strategy's context modules, signal rules, prose and timeframe **replace** the ones
+  materialized on the agent (this is not a merge), naming both strategies. Agent-owned settings are
+  untouched. The commit checks the new strategy against the coins the radar acts on for this agent;
+  a refusal names the coin and the condition — surface it, never retry it unchanged.
+- **Any other draft commit** — the concrete diff from the read: each field, from what, to what. And
+  the read's `impact`: the presets it is deployed to (`deployedPresetCount`), its open positions,
+  the coins its radar is armed on (`radarArmedCoinCount`), and the capital reading — its smallest
+  order (`smallestOrderUsd`) against the order floor (`orderFloorUsd`). `feasible: false` means the
+  agent could not place an order at those limits; say so before the form.
 
 Then one confirmation. Act only on an explicit pick — one of the options you offered. Free text
 while a confirmation is open is not consent, whether it arrives in chat or in the form's own
 answer-in-your-own-words box — answer what they said and re-present the same confirmation.
 
-**`expectedRevision` comes from the latest read.** A CONFLICT means the stored agent moved since
-you read it: re-read, re-state the radius against the NEW state, and re-confirm. Never retry with a
-bumped number — that is voting on a state you have not seen.
+**The numbers a write names come from the latest read** — a commit's `draftVersion` and
+`expectedRevision`, an archive's or activation's `expectedRevision`. A `CONFLICT` means the stored
+agent moved since you read it, and a commit refused `DRAFT_VERSION_MOVED` means the draft did — the
+player's form saved an edit, or another surface staged. Both carry `nextAct: get_draft`: re-read,
+re-state the radius against the NEW state, and re-confirm. Never retry with a bumped number — that
+is voting on a state you have not seen. A commit refused with `nextAct: stage` names the field the
+diagnostics named: fix it in a stage, read, and confirm again.
 
 **A refused archive names its own blockers.** The refusal carries typed `archiveBlockers[]` —
 DEPLOYED / OPEN_TRADES / ACTIVE_SESSION, each with a count. Report each blocker and its count as
@@ -172,8 +200,10 @@ server's resume verdict. **The verdict decides the recovery**; the reason only e
   `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);
+  - `canRaiseTriggeringStop` — raise that stop above the figure through the agent's draft (step 6:
+    `maxCumulativeDrawdownUsd` for the drawdown stop, `maxDailyLossUsd` for the daily loss limit).
+    The commit's receipt carries the new `haltResumeEligibility` when it moved a stop the resume
+    reads;
   - `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.
@@ -191,13 +221,15 @@ read the verdict again rather than assuming it cleared.
 
 ### 6. Risk limits are a whole object
 
-`update_intelligence_agent`'s `tradingConfig` is a **complete** configuration: what you send
-replaces what is stored, and every field in that schema is required when the object is present.
+The draft's TRADING_CONFIG axis is `{ tradingConfig }`, a **complete** configuration: what you
+stage replaces the drafted one whole, and every agent-owned field is required in it.
 
-So: **read the current configuration, write the complete object with your change applied**, and
-name **every changed value** in the confirm — from what, to what. Never assemble a partial config
-and never echo a read config back unchanged: the read shape is wider than the write shape
-(`strategyTimeframe` and `regimeTimeframe` are strategy-derived and rejected as unknown keys).
+So: **read the current configuration — the draft's TRADING_CONFIG when it holds one, otherwise the
+agent's — and stage the complete object with your change applied**, then name **every changed
+value** in the confirm, from what to what, as the draft read's diff serves it. Never assemble a
+partial config and never echo a read config back unchanged: the agent's read shape is wider than
+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
 
@@ -221,15 +253,23 @@ never describe it as a permission check, and never add one of your own.
 
 ## When a write's outcome is unknown
 
-An interrupted or timed-out write may have landed. **Read current state first** — the agent
-(`get_intelligence_agent`), the budget, the positions — and report the committed outcome. If it
-committed, that is a success, not a failure to retry. Never re-issue a state-changing call over an
-unverified outcome, and never re-create over an unread roster.
+An interrupted or timed-out write may have landed.
+
+**A draft commit recovers by being sent again.** `commit_agent_draft` replays the original receipt
+for the same draft version, so a create that landed is reported once and spends one slot. If the
+retry is refused as moved, read the agent — or the roster, for a create — and reconcile with the
+player before anything else.
+
+For every other write, **read current state first** — the agent (`get_intelligence_agent`), the
+budget, the positions — and report the committed outcome. If it committed, that is a success, not a
+failure to retry. Never re-issue a state-changing call over an unverified outcome, and never
+re-create over an unread roster.
 
 ## Reporting discipline
 
 - Report numbers exactly as the tools return them. Never recompute, re-derive, or round.
-- Reads are free of confirms; every write has one, and the radius is stated before the form.
+- Reads and stages are free of confirms — a stage changes only the draft. Every commit and every
+  state verb has one, and the radius is stated before the form.
 - A tool that fails is reported as failed, with what could not be checked. Never convert a failed
   read into "no issue".
 - Be concise. Every write on this surface points real capital somewhere, or takes it away.

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

@@ -30,18 +30,22 @@ Run these in order. Skip a step only when the player's question makes it irrelev
    indicator modules ACROSS a set of coins (comparing RSI, funding or volatility over the leaders,
    over a category, over the session pool), use `preview_strategy_report`: one table per module with
    coins as rows, the schema preamble emitted once instead of per coin, and a server-reported token
-   budget. Ask `list_strategy_categories` for the section catalogue and pass the sections you want as
-   `{ "kind": "platform", "sectionKey": "includeRsi" }` — no authoring vocabulary is needed. Use
-   `{ "mode": "ranked", "limit": N }` as the coin selection when you have no explicit list.
-   Looping a per-coin tool over N coins costs several times this and returns the same values.
+   budget. Ask `list_strategy_categories` for the section catalogue and pass the sections you want,
+   each as `{ "kind": "platform", "sectionKey": "includeRsi" }`, inside
+   `source: { "kind": "FIELDS", "timeframe": …, "sections": [ … ] }` — no authoring vocabulary is
+   needed. Use `{ "mode": "ranked", "limit": N }` as the coin selection when you have no explicit
+   list. Looping a per-coin tool over N coins costs several times this and returns the same values.
 4. **Coin deep-dive**, when the player named a coin or when one dominates the read: the SAME
-   `preview_strategy_report` call as step 3, with `{ "kind": "tickers", "tickers": ["SOL"] }` as the
+   `preview_strategy_report` call as step 3, with `{ "mode": "explicit", "tickers": ["SOL"] }` as the
    coin selection and the funding / open-interest / positioning sections chosen — one coin is a
    one-row report, not a different tool. Then `get_coin_candles` for the price action. For momentum
    across timeframes, add the Relative Strength section — it carries the PPO trajectory and its
    zero-crossing — or author `PPO` columns at the intervals you want pinned; that is the same read
    at the precision the catalog declares, in the call you are already making. Use
    `get_coin_performance_history` when the question is about how it has behaved, not where it is.
+   Coin symbols are case-insensitive and exchange symbols are accepted (`btc`, `kPEPE`,
+   `xyz:BRENTOIL`); a symbol that names no tracked coin is rejected with an error naming the field,
+   never answered as an empty read — say the coin is not tracked rather than retrying it.
 4b. **How much of the FIELD is moving, not just this coin.** Add the Market Breadth module
    (`{ "kind": "platform", "sectionKey": "includeMarketBreadth" }`) for the two-axis read: how much
    of the tracked universe closed up, and how much of it carries positive momentum. It reports per