@battlegrid/mcp-server 31.2.94 → 31.2.97

package/README.md

@@ -3322,7 +3322,7 @@ Strategies and intelligence agents change only through their drafts, with one to
 1. **Choose the entity.** `list_strategies` (add `includeInactive:true` when repairing an archived strategy) and `get_strategy`, or `list_intelligence_agents` and `get_intelligence_agent`. `fork_strategy({ strategyId, sourceRevision })` copies a visible revision into a new create draft and returns its `strategyId` and `draftVersion`; it creates nothing.
 2. **Discover the report vocabulary live.** Walk `list_strategy_categories` → `list_strategy_vocabulary` → `get_metric_construction_hints` → `get_strategy_column_contract`, and use `get_strategy_section_template` / `preview_strategy_report`. Do not guess metric, transform, parameter, template, or enabled-timeframe facts — they are server-discovered.
 3. **Read the draft.** `get_<kind>_draft({ request: { <id> } })` returns the draft (or `null`), its `draftVersion` (0 when none is held), the live `committedRevision` (null for an entity not created yet), a per-axis `diff` against live, `diagnostics` and `impact`.
-4. **Stage the change.** `stage_<kind>_draft({ request: { <id>?, draftVersion, axes } })` names the version you read. Each axis is whole, except a strategy's `SIGNAL_RULES`, whose rows replace the drafted rows for the same signals and keep every other one. Omit the id to open a new create draft; the response carries the minted id. A stage that has written never refuses: the composed draft's errors and warnings come back as `diagnostics`. It is refused only when the version is one the draft never reached (`DRAFT_VERSION_MOVED`) or when the player's own form changed an axis you are staging after that version (`DRAFT_AXIS_CONTESTED`, naming `contestedAxes`).
+4. **Stage the change.** `stage_<kind>_draft({ request: { <id>?, draftVersion, axes } })` names the version you read. Each axis is whole: it replaces the drafted axis entirely, so restate what it keeps. Omit the id to open a new create draft; the response carries the minted id. A stage that has written never refuses: the composed draft's errors and warnings come back as `diagnostics`. It is refused only when the version is one the draft never reached (`DRAFT_VERSION_MOVED`) or when the player's own form changed an axis you are staging after that version (`DRAFT_AXIS_CONTESTED`, naming `contestedAxes`).
 5. **Review with the player, then commit.** Read the draft again, show the player its diff and impact, and on their explicit word call `commit_<kind>_draft({ request: { <id>, draftVersion, expectedRevision } })` with exactly the two numbers that read returned — `expectedRevision: null` creates the entity at revision 1. A draft that moved is refused `DRAFT_VERSION_MOVED`, a moved revision `CONFLICT`, and an invalid draft with the same code its diagnostics carried; nothing is written. Each refusal's `details.nextAct` says what to do next (`get_draft` or `stage`). The commit is idempotent on `{ id, draftVersion }`: a retried commit replays its outcome. Changed strategy configuration propagates to every bound agent immediately; committing a draft of an archived strategy restores it.
 
 `discard_<kind>_draft({ request: { <id>, draftVersion } })` removes the draft at the version you read and never one that moved since. `preview_strategy_report({ coinSelection, source: { kind: 'DRAFT', strategyId, draftVersion } })` previews a draft as a commit would compose it. In multi-account mode the lifecycle tools use the `{ account, request }` sibling envelope; `preview_strategy_report` keeps its own flat input and takes `account` beside `coinSelection` and `source`.
@@ -3331,7 +3331,7 @@ Strategies and intelligence agents change only through their drafts, with one to
 
 ## Capabilities
 
-Tools, prompts, and resources are **discovered live** from the connected server via `tools/list`, `prompts/list`, and `resources/list`. This package intentionally does not copy the server's catalog, formulas, signal IDs, or defaults — inspect the live connection for the authoritative, current surface. Broadly, the server exposes game play (Market Grid), market context, account state, leaderboards, intelligence agents and automation, strategy discovery/authoring, and trading signals/decisions.
+Tools, prompts, and resources are **discovered live** from the connected server via `tools/list`, `prompts/list`, and `resources/list`. This package intentionally does not copy the server's catalog, formulas, or defaults — inspect the live connection for the authoritative, current surface. Broadly, the server exposes game play (Market Grid), market context, account state, leaderboards, intelligence agents and automation, strategy discovery/authoring, and trading signals/decisions.
 
 ## Environment variables
 

package/SKILL.md

@@ -30,7 +30,7 @@ to connect and to know which one to open.
 
 ## Discover the live surface first
 
-**Tools, prompts, and resources are discovered live from this MCP connection.** Always read the current `tools/list`, `prompts/list`, and `resources/list` before acting — a cached capability list is not authoritative after a server deployment. This skill teaches the workflows and the strict request contracts; it deliberately does not copy the server's tool catalog, metric/transform vocabulary, signal IDs, formulas, or default values. Discover those from the live tools (`list_strategy_categories`, `list_strategy_vocabulary`, `list_strategy_signals`, `get_strategy_signal_definition`, …). Never guess a metric, transform, parameter, template, signal, or enabled-timeframe fact.
+**Tools, prompts, and resources are discovered live from this MCP connection.** Always read the current `tools/list`, `prompts/list`, and `resources/list` before acting — a cached capability list is not authoritative after a server deployment. This skill teaches the workflows and the strict request contracts; it deliberately does not copy the server's tool catalog, metric/transform vocabulary, formulas, or default values. Discover those from the live tools (`list_strategy_categories`, `list_strategy_vocabulary`, `list_strategy_signals`, `get_strategy_signal_definition`, …). Never guess a metric, transform, parameter, template, signal, or enabled-timeframe fact.
 
 ## Single-account vs multi-account request shape
 

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

package/skills/EXPORT.json

@@ -1,22 +1,22 @@
 {
   "generator": "battlegrid-app/server/scripts/export-mcp-skills.mjs",
-  "contractVersion": "105.0.0",
+  "contractVersion": "108.2.0",
   "files": {
-    "battlegrid-agent-management/SKILL.md": "8ebb7d4fcc5d6a9ce463a762bf58d04a7f641369f7feaf64d2489727531e6f00",
+    "battlegrid-agent-management/SKILL.md": "34a868f8068df189ce13af47c23011aabcf6a1f07128da4d4706066628cfaa5f",
     "battlegrid-agent-management/references/agent-stage-examples.md": "d47555906ce8dedf4c17422f8f5d60187f2d6b3c0af5d9545617a10a5bdb59a1",
-    "battlegrid-arena-play/SKILL.md": "25f078eb31db5cd3d78ce0bc251802c32f94234fd8a8c6467c5b68abc41706f2",
-    "battlegrid-market-analysis/SKILL.md": "875bda71dd766ad06ac8e508679bcd3400a600cf74d2eac6c922dbe23175f325",
-    "battlegrid-radar-deployment/SKILL.md": "093ac358cd4f1a67a7dd467b0b4161c9a055cdd516d49ebb23bd4e9ef44aa200",
-    "battlegrid-radar-deployment/references/arena-stage-examples.md": "f924b70801a4b72bbde5a80823408939903cba6b294d8554fc4afc11d80b3333",
+    "battlegrid-arena-play/SKILL.md": "719dfd57a9ad5b70801f366f11d0e0a57c87c7aae7751b9acca7a5a1584aa36e",
+    "battlegrid-market-analysis/SKILL.md": "b647dbe9db4ecc67b744b7f7a82ec4e56f2e7f4d2cb1c20546649085b1ae1529",
+    "battlegrid-radar-deployment/SKILL.md": "12ae488bcc81e17fdd749448ecd98f42846c98960895c1d579db833836739eb2",
+    "battlegrid-radar-deployment/references/arena-stage-examples.md": "f605aaa266a291ef1b6d02a0e8885ad5df2fea88c800be2b6625cd629cd741f2",
     "battlegrid-radar-deployment/references/radar-stage-examples.md": "1ddad4a11f021dd65234ee65cc12d7d1561fe9acfd61cb021f4352080d4cecd5",
-    "battlegrid-strategy-authoring/SKILL.md": "fcc4ab6ae7e75e0949cef057134288e5e6e67ff96d3238bb551775ba5ce22f95",
-    "battlegrid-strategy-authoring/references/strategy-stage-examples.md": "1c35353c7280934486b65d5defe80f87278e77955b6041db677238940e589b50",
-    "battlegrid-strategy-doctor/SKILL.md": "14f20bff9e2b5a59d11634fe3615b1298d672d5e2eba06d3dc8698b571b3bee3",
-    "battlegrid-strategy-examples/SKILL.md": "528049af46a0a829628681d16076129eb57e898445c803e4ebafae98699a3b65",
-    "battlegrid-strategy-examples/references/playbooks.md": "9e4038df885bb840d6ee58ba0475a9214dc58d12bf355c91c8aae625d58e3096",
-    "battlegrid-strategy-examples/references/recipes.md": "61382acdd295fa159f055b787ba501f1c015f383f59a6714a973057f10de611f",
-    "battlegrid-strategy-examples/references/tradingview-ports.md": "706a7dd3a120b2f3d5fa3190924f493cf4ebaf5df895bbeb155c2db73f8f5ece",
-    "battlegrid-trade-analysis/SKILL.md": "f545b916dc2a37c8fc35e16b27fa6f78ead4302e67f65ac584765c1e069b4ab2",
-    "battlegrid-trade-proposal/SKILL.md": "d207a30065c17e13efaf5391805e5603e6956633cba5d0a1ff60e276518d9696"
+    "battlegrid-strategy-authoring/SKILL.md": "2b6bb9a9f419bae5dd85457f6f89131fd6f09ab218f67a0d9e27cad4072945fe",
+    "battlegrid-strategy-authoring/references/strategy-stage-examples.md": "9822cc2bcc8975a3e436c2a960b10e03c95e6e6b4b04bc2206e0ac90688cab66",
+    "battlegrid-strategy-doctor/SKILL.md": "e34e055b0cc9b355bc1adeb5d49d464eaa0756ca3f48dc89ca2ccdda94e1311f",
+    "battlegrid-strategy-examples/SKILL.md": "baf8f976d1b33c9009f21bb292943798a233464ebe4149f2f887cc40e2bfa5d4",
+    "battlegrid-strategy-examples/references/playbooks.md": "2309eb7e8324f563c5b1b51e05da931b37c542484135a2be749eff6ef78aa40f",
+    "battlegrid-strategy-examples/references/recipes.md": "3fc3280a854fca924b77f2fe154231e91a0dc779023413597d966cbb1ac88baf",
+    "battlegrid-strategy-examples/references/tradingview-ports.md": "fe70a84c700f0cd72b9adf91cafccae2af0db007951afc9be37bc3134142c5a1",
+    "battlegrid-trade-analysis/SKILL.md": "3f927b4f9796178526fa1673a2043c5f14358c39aa955de33192ea58641f18fb",
+    "battlegrid-trade-proposal/SKILL.md": "e761fc6bddc0d1db79fcb90046d03a18439562c8658de726ec286830edd6369b"
   }
 }

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

@@ -171,7 +171,7 @@ State the blast radius **from server fields, as numbers**, before the confirm fo
 - **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
+  the target strategy's report, conditions, trade levels, 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.

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

@@ -47,7 +47,10 @@ the enablement path there.
 1. `list_market_grid_sessions` with status `PENDING` — the sessions still enterable. **The
    `sessionId` you use comes from here; never fabricate one.**
 2. `get_market_grid_session` — the coin pool (note each coin's `id`), the entry fee, the pool and
-   the lock time.
+   the session's three instants: `startsAt` (the **Opening Bell** — the open of the one candle it
+   scores), `lockAt` (entries close) and `settleAt` (the candle closes). Entries stay open through
+   the Opening Bell window, from `startsAt` until `lockAt`, so an entry made inside the window can
+   read the candle that closed at the bell; the full candle from `startsAt` is scored either way.
 3. `get_market_context` for that session — the indicators, rankings and trends the picks will
    actually be reasoned from.
 4. `check_market_grid_submission` — **before composing anything.** If a submission already exists,
@@ -102,7 +105,8 @@ reasoning as the player's, and the attribution is part of what was scored.
 
 ### 5. After settlement
 
-- A session moves PENDING → LIVE → RESOLVING → SETTLED. Two states sit off that path: CANCELLED
+- A session moves PENDING → LIVE → RESOLVING → SETTLED. It stays PENDING through the Opening Bell
+  window and goes LIVE at `lockAt`. Two states sit off that path: CANCELLED
   (entry fees refunded) and SETTLEMENT_QUARANTINED (settlement exhausted its retries and awaits an
   operator). Either one is the answer — report it as the status.
 - `get_market_grid_results` — available only once the session is SETTLED. Before that it returns a
@@ -115,6 +119,22 @@ reasoning as the player's, and the attribution is part of what was scored.
   the picks, so say that rather than reconstructing one. `list_my_market_grid_entries` is the history
   across sessions. An agent's decisions are a different record, `get_agent_journal`.
 
+## On the arena's session page
+
+When the conversation is embedded in the player's Market Grid session page, the round on screen
+arrives as the attached scope, and the session it names is the one in scope.
+
+- **Propose, do not submit.** When the player asks for a grid, call `generate_agent_grid` for the
+  session in scope (the billed-inference warning in step 3 still applies). The result reaches them
+  as a card with **LOAD INTO GRID**, which puts the picks into their own builder as a starting point.
+- **A loaded grid they have not changed is the agent's.** Their builder will not place it as theirs.
+  If they want the agent's grid entered as it stands, run step 4: one confirmation, then
+  `submit_agent_grid` on their explicit pick, never on free text.
+- **Once they change a pick, the grid is theirs.** They place it themselves from their ticket. Do not
+  submit it for them, and do not describe it as the agent's.
+- **A newer generation for the same agent replaces the older card.** The older one reads SUPERSEDED;
+  only the newest is what `submit_agent_grid` would enter.
+
 ## Refusals, and what each one means
 
 Each is typed and distinguishable. Read the code, do not paraphrase:

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

@@ -40,6 +40,7 @@ Run these in order. Skip a step only when the player's question makes it irrelev
    `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.
+   A refused preview names its recovery in `nextAct`.
 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 `{ "mode": "explicit", "tickers": ["SOL"] }` as the
    coin selection and the funding / open-interest / positioning sections chosen — one coin is a

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

@@ -36,9 +36,8 @@ approves needs no deployment. An Arena deployment enters an agent into a preset'
 5. **Answering "why isn't it firing?" by paging the journal.** *Cue: any question about why a
    deployed agent has been quiet — "is it working?", "it hasn't traded all day", "what's blocking
    it?".* `get_radar_activity_summary` now answers the whole question in one small call — which
-   cause recurs, how far the score sits from firing, and what just happened — so paging the journal
-   for it tallies an aggregate the server already computed and re-derives a proximity reading it
-   already serves. The journal read is for ONE occurrence, or for more rows than the summary's ten.
+   cause recurs, how often the pair qualified, and what just happened — so paging the journal for it
+   tallies an aggregate the server already computed and re-derives a reading it already serves. The journal read is for ONE occurrence, or for more rows than the summary's ten.
    → step 5.
 
 ## Sequence
@@ -198,18 +197,26 @@ 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
+  (`conditions.entries[]`); 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
+  `scoredBarStart` names the bar the gates were read 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).
+  For the decisions before it, call `get_radar_close_decisions` (step 5). Name a close by the served
+  `barCloseAt` — on a record's `bar`, on a `PENDING` close and on the on-duty row's
+  `closeDecision.last` — and a `DEFERRED` row's bar being decided by `closeDecision.decidingBarStart`;
+  never add a timeframe to `barStart`.
+- `reading.sinceClose` is how the live reading moved since the deciding reading, computed by the
+  server: the ATR reading's move (`UP`, `DOWN`, `UNCHANGED`), whether the required conditions, the
+  trade levels, the condition verdict and the first failing gate changed, and each live condition
+  against the deciding entry for its key (`ABSENT`, `NOT_READ`, `UNCHANGED`, `CHANGED`). It is `null` unless `lastClose` is `RECORDED`
+  on a reading. Quote it; never compare the two readings yourself.
 
 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
@@ -304,7 +311,7 @@ Four reads, cheapest first. Stop as soon as the player's question is answered.
    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
+   reads false, how far the ATR reading sits from its floor — 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
@@ -313,11 +320,12 @@ Four reads, cheapest first. Stop as soon as the player's question is answered.
    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 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.
+   - `curveDigest` — how often the pair qualified, over the FIRST on-duty agent's ring (the
+     lowest-numbered slot on duty now, named in `curveAgentName`): `qualifiedCount` of
+     `sampleCount`, and the latest ATR% with how many samples read one. A pair that qualified on no
+     sample is one whose strategy does not fit this coin as it trades now; the `groups` above name the
+     gate that blocked it. Its `ringStartAt` / `ringEndAt` describe the ring, NOT the cause window
+     above.
    - `recentEvents` — the last ten key events, lean. Deliberately NOT bounded by the cause window, so
      a pair quiet for longer returns no groups beside populated older rows. That is correct, not a
      contradiction; each row carries its own `occurredAt`.
@@ -334,7 +342,7 @@ Four reads, cheapest first. Stop as soon as the player's question is answered.
    `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
+   could not evaluate with its reach reason, 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,

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

@@ -22,7 +22,7 @@ axis you omit keeps the value the draft already has.
     "draftVersion": 0,
     "axes": {
       "DEFAULT_SLOT": {
-        "defaultSlot": { "agentId": "<AGENT_ID>", "minConfidence": null, "entryStrategy": "STANDARD" }
+        "defaultSlot": { "agentId": "<AGENT_ID>", "minConfidence": null }
       }
     }
   }
@@ -42,7 +42,6 @@ axis you omit keeps the value the draft already has.
           {
             "agentId": "<AGENT_ID>",
             "minConfidence": null,
-            "entryStrategy": "STANDARD",
             "conditions": [{ "kind": "regime", "regimes": ["bull_expansion", "bull_ranging"] }]
           }
         ]
@@ -68,7 +67,6 @@ session occurrence, never both.
           {
             "agentId": "<AGENT_ID>",
             "minConfidence": 0.6,
-            "entryStrategy": "TWO_LOOK",
             "conditions": [
               { "kind": "session_start", "startTimes": ["14:00:00", "15:00:00"], "days": [1, 2, 3, 4, 5] }
             ]
@@ -93,7 +91,6 @@ session occurrence, never both.
           {
             "agentId": "<AGENT_ID>",
             "minConfidence": null,
-            "entryStrategy": "STANDARD",
             "conditions": [
               { "kind": "regime", "regimes": ["volatile"] },
               { "kind": "session_start", "startTimes": ["14:00:00"], "days": [1, 2, 3, 4, 5] }

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

@@ -15,12 +15,13 @@ All three come from real authoring sessions, and all three were discovered only
 was already built. None of them is allowed to happen here.
 
 1. **Built ≠ picked.** The player selected a "≥ +10%" trigger and a +5% trigger was implemented.
-   Nobody noticed until the results looked wrong. You prevent this by showing the *drafted* rules,
+   Nobody noticed until the results looked wrong. You prevent this by showing the *drafted* conditions,
    as the server's own draft read serves them, next to their *locked* picks, before committing, and
    naming any contradiction yourself.
 2. **Silent zero-trigger.** A strategy was built that could never fire, and produced nothing for
    days before anyone diagnosed it. You prevent this by reading the draft's own report preview and
-   the per-signal preview before committing, and flagging a draft that shows no passing conditions.
+   its diagnostics before committing, and flagging a draft that shows no passing conditions or
+   warns `NO_ENTRY_CONDITION`.
 
 3. **Silent substitution.** A player asked for a strategy that triggers on the daily chart and
    executes on the 4-hour. The grammar carries no such semantics. Instead of saying so, the flow
@@ -100,13 +101,19 @@ anywhere; if the two ever disagree, you have created the exact ambiguity this st
 ### 3. Discover the grammar — never guess it
 
 `list_strategy_categories` → `list_strategy_vocabulary` → `get_strategy_column_contract` and
-`get_strategy_section_template` → `list_strategy_signals`, plus
-`get_strategy_signal_definition` for each signal you intend to use.
+`get_strategy_section_template`.
 
-Compose sections, columns, conditions and rules **only** from vocabulary returned in this
-conversation. A field you remember from another strategy is not discovery. A signal's availability
-at a timeframe is structural: it says the signal can be computed there, not that live data is
-flowing or that it will trigger.
+Compose sections, columns and conditions **only** from vocabulary returned in this conversation. A
+field you remember from another strategy is not discovery.
+
+**Conditions are the only deterministic entry gate.** A condition gates an entry when it is
+`required` or carries a verdict (UP, DOWN or NEITHER); a building block — neither required nor a
+verdict carrier — gates nothing, and an exit rule never counts. A strategy whose entry conditions
+include no required and no verdict-carrying condition never routes a trade: every coin fails first
+with `NO_ENTRY_CONDITION`, and its draft carries the warning of the same name. It stays a valid
+strategy — Market Grid reads it as context — so a strategy the player means to trade needs at least
+one. Before any condition is read, a coin must clear the ATR floor, `minAtrPct`, the
+TRADE_LEVEL_POLICY dial beside the stop-loss band.
 
 **Read the answer, not just the call.** Each of these returns one field that decides a composition
 question you would otherwise guess — and a refusal you would otherwise earn:
@@ -150,25 +157,17 @@ question you would otherwise guess — and a refusal you would otherwise earn:
   transform (and a chained transform) reads its series: the read shape, the window's unit, the price
   basis and what an absent bar does. `seriesHome` says where the metric's series is kept — `candle`,
   `history`, or `null` when the metric has no series, which is why a series transform does not
-  compose on it. Window and offset carry a declared `minimum` and no fixed maximum; the lookback
-  cap is the bound.
+  compose on it. Window and offset carry a declared `minimum` and a served `maximum` on each metric's
+  transform entry — the largest value whose read size fits the lookback cap, or `null` when none
+  does. Stage at most that maximum.
 - `get_metric_construction_hints` → `rankOrderings`. Present only when rank is composable on that
   metric, already range-gated server-side — read the offered set rather than deriving one from
   the metric's native output.
 
 For full-surface composition patterns — custom and benchmark sections, condition trees with
-verdicts and enforcement gates, weight pyramids and gate math, trade-level and
-position-management presets, worked desk-grade playbooks — activate `strategy-examples`. It
-teaches what to compose; this skill stays the authority on the flow.
-
-`derive_strategy_rule_view` belongs here, at composition time, and only here: it reports report
-membership and registry-default allocations for sections and rows you are about to stage. It reads
-no draft and no strategy, so it can never stand in for the review in step 5. Its suggestions and
-reset-to-default choices change only what you stage next — no tool applies one on its own.
-
-`simulate_aggregate_score` does **not** belong here. It is a review tool (step 5), and running it
-now answers a question about rows you have not staged, not about the draft the player will be
-asked to approve.
+verdicts and `required` enforcement, the trade-level policy with its ATR floor, position-management
+presets, worked desk-grade playbooks — activate `strategy-examples`. It teaches what to compose; this
+skill stays the authority on the flow.
 
 ### 4. Stage, and iterate on the diagnostics
 
@@ -184,24 +183,24 @@ two stages in parallel against one draft. Complete stage payloads showing the en
 stage; the response carries the id minted for it, which every later call names. A create needs
 IDENTITY (`{ name, description, tagline }`) and TIMEFRAME_PROFILE (`{ timeframe }`). A create with
 no REPORT starts from the platform's starting report (Price Action, RSI, MACD and Moving Averages),
-one with no ENTRY takes the seed entry, and the rule rows you stage overlay a creation seed in
-which every signal is Off.
+and one with no ENTRY takes the seed entry. A create with no CONDITIONS declares no entry gate and
+will not trade until one is staged.
 
 **An UPDATE carries only the axes that change.** Axes you omit keep the values the draft has, and
 an axis the draft does not hold is the committed strategy's. Each axis you send is written WHOLE —
-a REPORT is the complete section list, CONDITIONS the complete set — except SIGNAL_RULES, whose
-rows replace the drafted rows for the same `signalId` and keep every other one. Restating an axis
+a REPORT is the complete section list, CONDITIONS the complete set. Restating an axis
 you are not changing is never required, changes nothing about the result, and the player pays for
 every byte of it on this call and on every later step of the conversation. Send the axes you are
 changing; send no other axis.
 
-**A rule row is complete.** Every staged row carries `signalId`, `allocation` and `required`;
-`params` only when the thresholds change, and omitting it keeps the stored ones byte-identically.
-"Raise volume_surge to Critical" is one row with `allocation: 3` and `required` exactly as it
-stands now — read it from the draft's SIGNAL_RULES row when the draft holds one, otherwise from
-`get_strategy`. Never set `required` from memory, and never change it unless the player asked about
-the Required flag: a wrong value there is how a scoring signal silently becomes a mandatory trade
-gate. Stage no row for a signal you are not changing.
+**A whole axis restates what it keeps.** "Raise the ATR floor to 0.8%" is one TRADE_LEVEL_POLICY
+stage carrying all four of its dials — `minStopLossAtrMultiple`, `maxStopLossAtrMultiple`,
+`minRiskRewardRatio` and `minAtrPct` — the three you are not changing exactly as they stand now:
+read them from the draft's TRADE_LEVEL_POLICY when the draft holds it, otherwise from
+`get_strategy`. The same holds for a condition: CONDITIONS carries every condition, each with its
+`required` flag and verdict as they stand. Never set `required` or a verdict from memory, and never
+change either unless the player asked: a wrong value there is how a building block silently becomes
+a mandatory trade gate, or a gate silently disappears.
 
 **Read the diagnostics every stage returns.** Past its checks of shape — an undeclared key, a
 parameter beside `ON_CANDLE_CLOSE`, a coin that names nothing — a stage refuses nothing for being
@@ -210,9 +209,9 @@ are where you learn what the commit would do:
 
 - `errors` — the refusals the commit would raise, each with its `field` and `details` naming the
   `path`, the value it received and the `allowedDomain` it accepts. Fix the axis and stage again.
-- `warnings` and `mismatches` — observations that never refuse. `NO_SIGNAL_ACTIVE` means the
-  strategy scores nothing and will never route a trade; a mismatch means the report and the
-  weights disagree. Fix each one, or carry it into the review as something to explain.
+- `warnings` — observations that never refuse. `NO_ENTRY_CONDITION` means the strategy declares no
+  required and no verdict-carrying entry condition, so it will never route a trade. Fix it, or carry
+  it into the review as something to explain.
 
 An empty `errors` is not a promise: the strategy quota, the name and capital feasibility are
 decided only by the commit itself.
@@ -237,7 +236,7 @@ Once the stage's diagnostics carry nothing you cannot explain, read the draft wi
 `get_strategy_draft`. Everything here comes from that read:
 
 - **What will actually run.** Its `diff` — every drafted axis with its `live` and drafted value
-  and the field-level `changes` between them, the drafted signal-rule rows among them — beside the
+  and the field-level `changes` between them, the drafted conditions among them — beside the
   picks they locked in step 2. **If any drafted row or diff entry contradicts a locked pick, say so
   in words before you ask for anything.** Do not make them spot it.
 - **All of what the commit publishes.** The diff names every axis the draft holds, including
@@ -250,23 +249,16 @@ Once the stage's diagnostics carry nothing you cannot explain, read the draft wi
   register with every coin's verdict, and the verdict tally; ask for `"detailed"` only when you need
   each coin's full evaluation or the addressable headers (`authoring`). A preview is bounded by a
   deadline and a result-character cap, both served by discovery as `previewExecutionLimits`
-  (`deadlineMs`, `maxResultChars`); one over either is refused whole, never truncated — narrow the
-  cohort and preview again. Support it
-  with `get_coin_signal_preview` on the locked universe's main coin(s). The preview's
-  `coinSelection` is its cohort, never strategy state: no strategy has one and `get_strategy` will
-  not return one, so choose it — a short explicit list of the tickers the change is about for a
-  single-gate edit, a `ranked` cohort for a broad one. Any reasonable cohort is correct.
-- **A routing what-if**, optionally, via `simulate_aggregate_score` — **after the draft read, never
-  before it.** This is a calculator, not a verdict: it computes over whatever inputs you hand it.
-  Feed it what the commit would carry — the gate and the allocations as the read serves them (the
-  drafted value where the draft holds the axis, the committed one where it does not) and the
-  per-signal scores from the preview you just read — and show those inputs beside its output so a
-  copy slip is visible on the card itself.
-
-**Flag before confirming** if the preview shows no passing conditions, the coin preview shows
-zero triggered signals, the simulation reports `wouldRoute: false`, or the diagnostics warn
-`NO_SIGNAL_ACTIVE`. Any one of those means the strategy probably never fires — ask whether to
-revise rather than presenting it as healthy.
+  (`deadlineMs`, `maxResultChars`); one over either is refused whole, never truncated, and the
+  refusal carries `nextAct: narrow` — preview again asking for less, in the order the tool's
+  description gives. The preview's `coinSelection` is its cohort, never strategy state: no strategy
+  has one and `get_strategy` will not return one, so choose it — a short explicit list of the
+  tickers the change is about for a single-condition edit, a `ranked` cohort for a broad one. Any
+  reasonable cohort is correct.
+
+**Flag before confirming** if the preview shows no passing conditions or the diagnostics warn
+`NO_ENTRY_CONDITION`. Either one means the strategy probably never fires — ask whether to revise
+rather than presenting it as healthy.
 
 **State the impact as numbers, not buried in prose.** The read's `impact` carries:
 
@@ -314,13 +306,13 @@ Prose never triggers a commit. The same holds for an answer typed into the form'
 answer-in-your-own-words box: it is the player's words in an answer slot, not a confirming pick,
 so treat it exactly as you would free text in the chat.
 
-Do not pre-check ownership, viability, quota or the name before calling. The server is the only
+Do not pre-check ownership, validity, quota or the name before calling. The server is the only
 authority on all of them; your job is to react to what it returns.
 
-**Report the change from the receipt.** The commit returns the committed `strategy` and, when
-signal rules moved, `ruleChanges` with the server's own `before` and `after` for each edited
-signal. State those. Never describe a prior value from memory or from an earlier read — the
-receipt is the only record that cannot be stale.
+**Report the change from the read and the receipt.** The commit returns the committed `strategy`.
+State each change as its live value in the read the player confirmed against its value in the
+receipt's strategy. Never describe a value from memory or from any other read — those two are the
+only records that cannot be stale.
 
 **Offer to discard a draft only on the player's explicit word**, never on your own judgement that
 it looks stale, and never batched into another act. `get_strategy_draft` is the read of what a
@@ -334,11 +326,12 @@ removed. The unsaved values are gone afterwards and there is no other copy.
 
 `fork_strategy`, `restore_strategy`, `archive_strategy`, `discard_strategy_draft` and
 `preview_strategy_report` are part of this flow. Every change to a strategy's content — a single
-tuned rule included — is a staged draft committed with `commit_strategy_draft`; none of the other
-verbs writes content.
+tuned condition or dial included — is a staged draft committed with `commit_strategy_draft`; none of
+the other verbs writes content.
 
-- **Tuning a single rule** is one SIGNAL_RULES row staged (step 4), read, confirmed and committed.
-  State how many agents are bound, and that the change reaches every one of them immediately.
+- **Tuning a single condition or dial** is its axis staged whole (step 4), read, confirmed and
+  committed. State how many agents are bound, and that the change reaches every one of them
+  immediately.
 - **Forking** — `fork_strategy` takes the `strategyId`, the exact `sourceRevision` to copy and an
   optional `name`, and returns a NEW create draft's `strategyId` and `draftVersion`. **No strategy
   exists yet.** Read the draft with `get_strategy_draft` — every authored axis equals the source
@@ -352,10 +345,9 @@ verbs writes content.
 - **Restoring** — find the archived strategy with `list_strategies` and `get_strategy` with
   `includeInactive: true`, which add the player's own strategies in any state; another player's
   PRIVATE strategy stays hidden either way. `restore_strategy` with the `strategyId` and
-  `expectedRevision` brings back unchanged, already-viable content and keeps the player's draft,
-  re-based onto the restored revision. Content that is not viable is
-  refused with `REPAIR_REQUIRED` and stays archived: stage the repair into the strategy's draft and
-  commit it — that commit restores it, and its read says `operation: RESTORE`.
+  `expectedRevision` brings back the unchanged content and keeps the player's draft, re-based onto
+  the restored revision. To change the content as it comes back, stage the change into the
+  strategy's draft and commit it — that commit restores it, and its read says `operation: RESTORE`.
 
 **Your `ask_user` is the approval, and the server does not repeat it.** No strategy verb takes a
 confirmation flag. So never call `commit_strategy_draft`, `archive_strategy`, `restore_strategy` or
@@ -369,7 +361,8 @@ offered, and nothing else is.
 
 Each refusal is a specific typed code, and a refusal of a draft's stage or commit names its next
 act in `details.nextAct` — `get_draft` or `stage`; a moved or contested draft names `get_draft`
-from any tool. Read it and take the cheapest correct step — never retry the same call blindly.
+from any tool, and a refused preview names `narrow`. Read it and take the cheapest correct step —
+never retry the same call blindly.
 
 - **`DRAFT_VERSION_MOVED`** (`nextAct: get_draft`) — the draft changed after your read: the
   player's form saved an edit, another surface staged, or a human-paced review outlived it. Read
@@ -385,8 +378,8 @@ from any tool. Read it and take the cheapest correct step — never retry the sa
 - **A validation error** (`nextAct: stage`) — the error the diagnostics named, with its own
   `field` and `details`. Nothing was written. Return to step 4: fix the axis, stage, read, and
   confirm again.
-- **A refusal with no `nextAct`** — the strategy quota (`FORBIDDEN`), a name already in use,
-  `REPAIR_REQUIRED`, viability, or a `CONFLICT` whose `details.reason` is `RADAR_DEPLOYMENT_MOVED`. The draft is
+- **A refusal with no `nextAct`** — the strategy quota (`FORBIDDEN`), a name already in use, or a
+  `CONFLICT` whose `details.reason` is `RADAR_DEPLOYMENT_MOVED`. The draft is
   untouched. Clear the cause with the player — a rename is an IDENTITY stage, which makes a new
   version to read and confirm — then commit the draft they confirmed. A moved radar deployment is
   a race, not a decision: read and commit again.

package/skills/battlegrid-strategy-authoring/references/strategy-stage-examples.md

@@ -4,8 +4,8 @@
 checked in CI against the live `stage_strategy_draft` schema; a create example is also checked for the axes a new
 strategy needs. Its shape is current.
 
-These examples show the envelope and the small axes. A full composition (report sections, conditions, signal
-rules) is in `strategy-examples`' playbooks, which have their own compile gate.
+These examples show the envelope and the small axes. A full composition (report sections, conditions, trade
+levels) is in `strategy-examples`' playbooks, which have their own compile gate.
 
 Every `<UPPER_SNAKE>` value is a placeholder: `<STRATEGY_ID>` is the id a read returned. Never send a placeholder as
 written, and never invent an id. `draftVersion` is the version `get_strategy_draft` returned: 0 when there was no
@@ -33,9 +33,10 @@ and TIMEFRAME_PROFILE before it can be created.
 }
 ```
 
-## Change an existing strategy's setup gates
+## Change an existing strategy's trade levels
 
-SETUP_GATES is sent whole: all three gates, even when only one changes.
+TRADE_LEVEL_POLICY is sent whole: all four dials, even when only one changes. `minAtrPct` is the ATR% volatility floor
+a coin must clear before any condition is read; the other three are the stop-loss band and the reward-to-risk floor.
 
 ```json stage_strategy_draft
 {
@@ -43,7 +44,12 @@ SETUP_GATES is sent whole: all three gates, even when only one changes.
     "strategyId": "<STRATEGY_ID>",
     "draftVersion": 2,
     "axes": {
-      "SETUP_GATES": { "minAggregateScore": 60, "minRequiredCount": 1, "minAtrPct": 0.5 }
+      "TRADE_LEVEL_POLICY": {
+        "minStopLossAtrMultiple": 1,
+        "maxStopLossAtrMultiple": 2,
+        "minRiskRewardRatio": 1.5,
+        "minAtrPct": 0.8
+      }
     }
   }
 }

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

@@ -50,22 +50,26 @@ Three reads, and they are not interchangeable:
 
 ### 2. Diagnose from typed sources
 
-- **The one vocabulary is `TradeEvaluationAttemptReasonCode`** — 25 members, two of them
+- **The one vocabulary is `TradeEvaluationAttemptReasonCode`**, two of its members
   `@deprecated` and historical-only (`TRADING_MODE_OFF`, `TRADING_MODE_INELIGIBLE`): if either
   turns up, it is an old row, not a live cause, and you say so. Do not translate a code into a
   different enum's wording, and do not try to unify the platform's overlapping reason vocabularies
   — they describe different stages and merging them invents a cause.
-- Render every code through its display meta. A raw `SETUP_GATES` or `OPEN_POSITION_CONFLICT` on
+- 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_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 — candidate levels, aggregate score, required-signal count, the ATR%
-  volatility floor and the agent's own required conditions, without spending an LLM call. Read the
-  four-member verdict as written: `NOT_ENFORCED` means the agent's own threshold switches the gate
-  off, `UNMEASURABLE` means the input was missing and the gate fail-opened. Neither is a pass, and
+  and which gate stops it — the strategy's entry condition, candidate levels, the ATR% volatility
+  floor and the strategy's required conditions and verdict, without spending an LLM call. Read the
+  four-member verdict as written: `NOT_ENFORCED` means the strategy declares nothing for that gate to
+  enforce, `UNMEASURABLE` means the input was missing and the gate fail-opened. Neither is a pass, and
   reporting either as "cleared" is the conflation the verdict vocabulary exists to prevent.
+- **`NO_ENTRY_CONDITION` is a property of the strategy, not of the market.** It fails every coin
+  first, in both directions: the bound strategy declares no required and no verdict-carrying entry
+  condition, so it never routes a trade. Say so once, for every coin at once, and route the fix — a
+  required or verdict condition — to the strategy-authoring flow; no coin or radar change clears it.
 - **A failing condition comes back as a KEY — resolve it.** `requiredConditions.failedKeys` names
   gates like `LOCATION_OK`: an identifier, not an explanation. Read the agent's bound strategy with
   `get_strategy` (the `strategyId` is on `get_intelligence_agent`), find the matching

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

@@ -1,18 +1,17 @@
 ---
 name: battlegrid-strategy-examples
-description: Full-surface composition patterns for the strategy studio — validated desk-grade examples of custom report sections, benchmark sections, condition trees with verdicts and enforcement gates, tiered signal weights, routing gates, ATR trade levels, and position management. Activate beside strategy-authoring whenever a strategy is being composed or upgraded beyond a basic template.
+description: Full-surface composition patterns for the strategy studio — validated desk-grade examples of custom report sections, benchmark sections, condition trees with verdicts and required enforcement, the entry-condition rule, ATR trade levels with the ATR floor, and position management. Activate beside strategy-authoring whenever a strategy is being composed or upgraded beyond a basic template.
 ---
 
 # Strategy Studio — full-power composition patterns
 
 `strategy-authoring` owns the flow (evidence → locked spec → discover → stage → review →
 commit). This skill owns **what to compose**: a default build — a few platform sections, no
-conditions, untouched weights — wastes the studio. The playbooks below are compiled in CI, so their
+conditions, untouched trade levels — wastes the studio, and one with no entry condition never trades. The playbooks below are compiled in CI, so their
 shapes are binding in the sense that matters — they are checked, not merely asserted. Loose tokens
 elsewhere in this file are not covered by that gate, and vocabulary moves with deploys, so discovery
-in the conversation stays the authority — prefer what `list_strategy_vocabulary`,
-`get_strategy_column_contract`, and `get_strategy_signal_definition` return over anything
-printed here, and read exact headers from a `detail: "detailed"` preview's
+in the conversation stays the authority — prefer what `list_strategy_vocabulary` and
+`get_strategy_column_contract` return over anything printed here, and read exact headers from a `detail: "detailed"` preview's
 `authoring.conditionColumns` before conditioning on them.
 
 ## The full-power checklist
@@ -22,14 +21,12 @@ Before committing a CREATE, every "no" here is a decision to state, not an omiss
 1. At least one **custom section** whose columns encode the thesis — not only platform modules.
 2. **Conditions** encode the entry logic: building blocks (`verdict: null`) + verdict carriers,
    and at least one `required: true` condition vetoing obvious disqualifiers **before any
-   billing or LLM call**.
-3. **Every signal meant to score is named in `rules`** with a deliberate tier — unnamed signals
-   keep server defaults (Off on a CREATE). Verify against the rule rows the draft read serves,
-   never assume.
-4. **Gates** (`minAggregateScore`, `minRequiredCount`, `minAtrPct`) are computed against the
-   chosen weight budget, not guessed.
-5. **Trade levels + position management** match the setup's geometry and holding period.
-6. `marketReadText` states standing orders with `{...}` markers so live values render inline.
+   billing or LLM call**. They are the only deterministic entry gate: with no required and no
+   verdict-carrying entry condition the strategy never routes a trade (`NO_ENTRY_CONDITION`).
+3. **The ATR floor** (`minAtrPct`) is set for the coins and timeframe the thesis trades, not left
+   at the default by accident — a coin below it is refused before any condition is read.
+4. **Trade levels + position management** match the setup's geometry and holding period.
+5. `marketReadText` states standing orders with `{...}` markers so live values render inline.
 
 ## Header grammar (system-generated — never named by the author)
 
@@ -45,6 +42,12 @@ Before committing a CREATE, every "no" here is a decision to state, not an omiss
 | `maxShare` wN | `<code>_maxShare` | `volBase_ltf_maxShare` |
 | `classifyZone` / `classifyState` | `<code>_zone` / `<code>_state` | `RSI14_zone`, `ADX_state` |
 | `levelInteraction` | `<code>_lvl`, `<code>_lvl_b<N>` at a buffer of N bps | `bbUpper_lvl`, `bbUpper_lvl_b25` |
+| any, stored `"bars": "all"` | `<code>_dev`, then the transform's suffix | `RSI14_dev_t1` |
+| `value` at `offset` N > 0 | `<code>_o<N>` | `RSI14_1d_o1` |
+
+The code carries its tokens in this order: `<code>[_<tf>][_dev][_o<N>]`, then the transform's suffix.
+`_dev` follows the STORED selector — the author chose Developing — whatever bar set the column then
+reads; `_o<N>` appears on a `value` at offset N > 0.
 
 Non-anchor rungs affix `_ltf` (lower) / `_htf` (regime): `MAalign_htf`,
 `zones_htf_support_dist`. Chains are bounded at two: inner `distance`/`spread` → outer
@@ -56,11 +59,12 @@ when the strategy timeframe changes — `regime` is the anchor's ladder successo
 anchor). *Pinned* (`{abs: "<tf>"}`) is fixed, ignores anchor retunes, suffixes the literal
 (`RSI14_1d`, `dist_SMA200_1d`, `MAalign_1d` — validated), and binds to discovery's
 `rankedTimeframes`, a **superset** of the authorable anchor set — `{abs: "1d"}` is valid while
-`1d` is not an anchor. `offset: 1` on a pinned `value` column reads the last **closed** bar of
-that timeframe (`RSI14[t - 1]`) — the deterministic daily-close read; offset 0 reads the
-forming bar (provisional), and offset does not change the header, so one offset per
-`metric × timeframe` per section. **Daily-strategy pattern:** anchor 4h, pinned-1d thesis
-columns at `offset: 1`, `required: true` daily conditions gating every carrier, anchor-rung
+`1d` is not an anchor. `offset` steps back inside the bar set the Read selector admits, counted
+from the newest bar that set admits, and suffixes the header `_o<N>` (`RSI14_1d_o1`). A pinned
+column above the strategy timeframe reads Confirmed, so its offset 0 is already the newest
+**completed** bar of that timeframe — the deterministic daily-close read — and offset 1 is the
+day before it. **Daily-strategy pattern:** anchor 4h, pinned-1d thesis columns with
+`"bars": "closed"` at offset 0, `required: true` daily conditions gating every carrier, anchor-rung
 columns only for entry timing and risk — daily inputs then move once per daily close while
 stops and time decay keep managing intraday. **Benchmark sections** (`benchmarkTicker: "BTC"`,
 required-nullable on every custom section) read the benchmark's values on every row — the
@@ -156,7 +160,16 @@ Recipes — each one clause:
 before billing. And the RESOLVED verdict binds entry DIRECTION: `UP` admits long setups only,
 `DOWN` short only, and `NEITHER`/`UNRESOLVED` admit none — the refused side is absent from the
 setups block and from the `decide_trade` contract, not merely discouraged in them. A strategy that
-declares no verdict-carrying condition resolves `null` and constrains nothing.
+declares no verdict-carrying condition resolves `null` and constrains no side.
+
+**A strategy without an entry condition never routes.** An entry condition gates when it is
+`required: true` or carries a verdict (`UP`, `DOWN` or `NEITHER`); a building block gates nothing,
+and an exit rule never counts. A strategy whose conditions include neither never trades: every coin
+fails first with `NO_ENTRY_CONDITION`, before the trade levels, the ATR floor or any condition is
+read, and its draft carries the `NO_ENTRY_CONDITION` warning. It stays a valid strategy — Market Grid
+reads it as context — so this is a choice to state, never an accident. When the agent decides a
+routed trade, its `decide_trade` call cites 1–8 of the evaluated entry conditions in
+`conditionChecklist`, and only a condition that read TRUE may be cited as `CONFIRM`.
 
 A verdict carrier must read no DEVELOPING bar. A verdict is refused over any closure that reads a
 column selecting Developing above the strategy timeframe (`CONDITION_VERDICT_READ_ILLEGAL`). The
@@ -461,7 +474,7 @@ bar whose close decides an entry is the strategy's OWN timeframe.
 
 **Every trigger is decided at the close of the strategy's own bar — there are three, and the close
 is the only entry clock.** The newest completed bar is read on the closed basis — every one-close
-condition resolves on that bar and the scorecard reads its close — and a reading that still qualifies
+condition resolves on that bar and the gates read its close — and a reading that still qualifies
 fires at that close. A bar that does not qualify decides nothing and is not revisited. The fill lands
 at the next tick, and the platform refuses it if the market has already run past its own drift budget
 from that close. A fourth value, `AT_SIGNAL`, is readable on strategies authored before this contract
@@ -505,45 +518,16 @@ column reaches any other timeframe by pinning it (`timeframe: { abs: '4h' }`). `
 than omitting them, because the section is rebuilt whole on save and an omitted key clears the
 author's value silently. On a CREATE, omit `sectionKey` — it is derived from the section itself.
 
-## Signal rules
-
-`{ signalId, allocation, required, params }` — one entry per signal you want scoring.
-`allocation` is the tier (0–3) and `params` replaces canonical defaults only when present. Staged
-into the draft's SIGNAL_RULES axis, every row is complete — `allocation` and `required` on each —
-and replaces the drafted row for its signal while every other row is kept.
-
-## Signal weights and gate math
-
-Tiers: 0 Off · 1 Normal · 2 Important · 3 Critical.
-
-```
-aggregateScore = Σ(score × allocation) / Σ(allocation)   over triggered signals
-```
-
-Weights are relative — build a pyramid: 1–2 Critical (thesis, usually `required`), 2–4
-Important (independent confirmation, different modules), 1–3 Normal (context), rest Off so
-noise cannot dilute the average. Gate check: with 3/2/2/1 weights, Critical + one Important at
-score 1.0 → (3+2)/8 = 0.625, so a 0.6 gate means "thesis plus one confirmation".
-`simulate_aggregate_score` does this arithmetic from the draft's values at review time.
-`required: true` counts the signal toward `minRequiredCount` when triggered; at
-`allocation: 0` it is rejected (contract 34). `params` replace canonical defaults only when
-present — read `get_strategy_signal_definition({ signalId, timeframe })` before tuning (e.g.
-`rsi_overbought {"threshold": 65}` for a fade book; `volume_surge {"multiplier": 1.5}`).
-`derive_strategy_rule_view` shows which signals a draft report feeds — weighting a signal the
-report never feeds is dead weight.
-
-## Routing gates
-
-`{ minAggregateScore, minRequiredCount, minAtrPct }` — whether a scored setup may route to a
-trade at all. `minAggregateScore` 0–1 · `minRequiredCount` 0–20 · `minAtrPct` is the dead-market
-floor, with bounds from `get_trading_config_catalog`.
-
 ## Trade levels
 
-`{ minStopLossAtrMultiple, maxStopLossAtrMultiple, minRiskRewardRatio }` — where stops and
-targets may sit. `minStopLossAtrMultiple < maxStopLossAtrMultiple` (≤ the 3×ATR structural cap),
-`minRiskRewardRatio` within the served range. Sizing is risk-budget based — a wider stop means a
-smaller position, never more risk.
+`{ minStopLossAtrMultiple, maxStopLossAtrMultiple, minRiskRewardRatio, minAtrPct }` — where stops
+and targets may sit, and how much a coin must move before it is worth trading at all.
+`minStopLossAtrMultiple < maxStopLossAtrMultiple` (≤ the 3×ATR structural cap), `minRiskRewardRatio`
+within the served range. `minAtrPct` is the ATR floor: a coin whose ATR% sits below it is refused
+(`ATR_VOLATILITY_BELOW_MIN`) before any condition is read, with bounds from
+`get_trading_config_catalog`; it is multiplied with `maxStopLossAtrMultiple` in the capital check, so
+a high floor with a wide stop needs more capital per trade. The axis is staged whole — all four.
+Sizing is risk-budget based — a wider stop means a smaller position, never more risk.
 
 ## Position management
 
@@ -583,7 +567,7 @@ rejects an `offset`) belongs in prose above — those are permanent. A claim tha
 
 ## Where the worked material lives
 
-This skill's body is the contract — the axes, the header grammar, how conditions and weights behave,
+This skill's body is the contract — the axes, the header grammar, how conditions and trade levels behave,
 and the absence section above. The worked material is disclosed on demand, so it costs nothing until
 you ask for it. Read a reference with `read_skill_reference` when you reach the work it covers:
 

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

@@ -26,11 +26,8 @@ Custom `Squeeze Scan` (no `sectionKey` — this is a CREATE): `BB_WIDTH_PCT valu
 custom section already carries them.) Conditions: `LIQUID_FLOOR` (required —
 `vol24hUsd gte 25000000`); `SQUEEZE_ON` building block (`bbWidthPct_rank_lo lte 10` AND
 `ADX lt 20`); `BREAK_UP` verdict UP (ref SQUEEZE_ON + `closeChg gt 0` + `RVOL gte 1.5` +
-`pctB gte 0.85`); `BREAK_DOWN` verdict DOWN (mirror with `pctB lte 0.15`). Rules:
-`bollinger_squeeze` 3 required · `volume_surge` 2 required `{"multiplier":1.5}` ·
-`volatility_atr_expanding` 2 · `sr_resistance_break` 2 · `sr_support_break` 2 ·
-`bollinger_upper_touch` 1 · `bollinger_lower_touch` 1 · `trend_adx_ranging` 1. Gates
-0.55 / 2 / 0.8. Levels 0.75–1.75 ATR, RR 2. PM: BE 1R; trail 1.2R giveback 35 buffer 0.3.
+`pctB gte 0.85`); `BREAK_DOWN` verdict DOWN (mirror with `pctB lte 0.15`). Levels 0.75–1.75 ATR,
+RR 2, ATR floor 0.8% — a compression play needs the expansion to be worth the stop. PM: BE 1R; trail 1.2R giveback 35 buffer 0.3.
 Market Read: "Trade only expansions out of compression: {SQUEEZE_ON} must read TRUE… skip
 anything failing {LIQUID_FLOOR}."
 
@@ -43,11 +40,7 @@ new longs / new shorts / short covering / long liquidation), `MARK spread ORACLE
 `NO_LIQUIDATION_TAPE` required NOT-veto (`NOT [oiRegime is "long liquidation"]`);
 `CROWDED_LONGS` building block (`ann gte 25` + `oiChg gte 3` + `oiRegime is "new longs"`);
 `FADE_SHORT` verdict DOWN (ref + `RSI14 gte 65` + `chg24h gte 5`); mirrored `SQUEEZED_SHORTS`
-/ `SQUEEZE_LONG` verdict UP. Rules: `funding_extreme_positive`/`_negative` 3 required
-`{"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).
+/ `SQUEEZE_LONG` verdict UP. Levels 1.0–2.5 ATR, RR 1.5, ATR floor 0.5%. PM: BE 0.8R, no trail, timeDecay ON (120/60, 10→40, stale 25).
 
 ### 3 · Relative-Strength Rotation with a Benchmark Gate — 4h cross-sectional
 
@@ -61,10 +54,8 @@ every row reads BTC. Conditions: `BTC_RISK_ON` building block (`MAalign is "bull
 `ADX gte 20` — both read bare, since only this section renders them); `BTC_RISK_OFF`
 (`MAalign is "bearish"`); `LEADER` (`roc12_rank_hi lte 5` + `RVOL_rank_hi lte 10` +
 `vol24hUsd gte 100000000`); `ROTATE_IN` verdict UP (`ALL[ref BTC_RISK_ON, ref LEADER]`);
-`ROTATE_OUT` verdict DOWN (`ALL[ref BTC_RISK_OFF, roc12_rank_lo lte 5]`). Rules:
-`comparison_sector_momentum` 3 · `rel_roc_positive`/`_negative` 2 · `ma_ema_aligned_bull`/
-`_bear` 2 required · `rel_ppo_bull_cross`/`_bear_cross` 1 · `volume_surge` 1. Gates
-0.5 / 1 / 0.6. Levels 1–2 ATR, RR 1.8. PM: BE 1R; trail 1R giveback 45. Ranked cohort ≥ 40 —
+`ROTATE_OUT` verdict DOWN (`ALL[ref BTC_RISK_OFF, roc12_rank_lo lte 5]`). Levels 1–2 ATR, RR 1.8,
+ATR floor 0.6%. PM: BE 1R; trail 1R giveback 45. Ranked cohort ≥ 40 —
 rank conditions need a cohort wider than their thresholds.
 
 ### 4 · HTF Trend Pullback — 1h, multi-timeframe confluence
@@ -77,11 +68,8 @@ would be ambiguous. Conditions: `HTF_UP` building block (`MAalign_htf is "bullis
 `ADX_htf_state in ["trending","extreme"]`); `HTF_DOWN` mirror; `TREND_PRESENT` **required**
 `ANY[ref HTF_UP, ref HTF_DOWN]` — chop blocks compose-trade entirely, before billing;
 `PULLBACK_LONG` verdict UP (ref HTF_UP + `RSI14_now between 35 55` +
-`dist_EMA20 between -3 0.5`); `PULLBACK_SHORT` verdict DOWN (mirror, 45–65 / −0.5–3). Rules:
-`mtf_pullback_long`/`_short` 3 required · `htf_ma_aligned_bull`/`_bear` 2 required ·
-`htf_trend_adx_trending` 2 · `ma_ema_aligned_bull`/`_bear` 1 · `rsi_oversold` 1
-`{"threshold":40}`. Gates 0.6 / 2 / 0.7 (a pullback signal AND an HTF alignment). Levels
-1–2.5 ATR, RR 2. PM: BE 1R; trail 1.5R giveback 30 buffer 0.3.
+`dist_EMA20 between -3 0.5`); `PULLBACK_SHORT` verdict DOWN (mirror, 45–65 / −0.5–3). Levels
+1–2.5 ATR, RR 2, ATR floor 0.7%. PM: BE 1R; trail 1.5R giveback 30 buffer 0.3.
 
 ### 5 · Perp/Spot Flow Divergence at Structure — 15m scalp
 
@@ -93,10 +81,8 @@ perp_led_fragile / spot_led_accumulation / neutral), `includeStructureZones`
 (`zones_htf_support_dist between 0 2` + `zones_htf_support_age_h gte 12`); `DIP_BID` verdict
 UP — refs plus an `N_OF(2)` quorum over `buyPres gte 0.55` / `RVOL gte 1.2` / `closeChg gt 0`
 (quorum beats a brittle ALL); `FRAGILE_POP` verdict DOWN (`perp_led_fragile` +
-`zones_htf_resist_dist between -2 0` + `RVOL gte 1.3`). Rules:
-`flow_perp_spot_bull_divergence`/`_bear_divergence` 3 required · `cvd_bull_divergence`/
-`_bear_divergence` 2 · `sr_at_support`/`_at_resistance` 2 · `structure_ob_approach` 1 ·
-`volume_surge` 1. Gates 0.55 / 1 / 0.4. Levels 0.5–1.2 ATR, RR 1.5. PM: BE 0.7R; trail 0.9R
+`zones_htf_resist_dist between -2 0` + `RVOL gte 1.3`). Levels 0.5–1.2 ATR, RR 1.5, ATR floor
+0.4%. PM: BE 0.7R; trail 0.9R
 giveback 30 buffer 0.15; timeDecay ON aggressive (45/15, 15→60, stale 30).
 
 ## Using a playbook
@@ -104,7 +90,7 @@ giveback 30 buffer 0.15; timeDecay ON aggressive (45/15, 15→60, stale 30).
 Discover → confirm headers (`get_strategy_column_contract`, or one `preview_strategy_report` at
 `detail: "detailed"`, whose `authoring.conditionColumns` lists every addressable header with
 operators and vocabulary) → calibrate literals against the previewed live values → stage the draft
-and fix what its diagnostics name → read it back and review the drafted rule rows, then the draft's
+and fix what its diagnostics name → read it back and review the drafted conditions, then the draft's
 own report preview — the conditions register (`gridConditions`), verdict tally, and
 `marketReadMarkers` (fix `unknown` / `ambiguous` markers) → commit per the strategy-authoring flow. Coin selection is call context, not strategy
 state: explicit tickers for focused work, `ranked` (with an optional category) for scanning books.

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

@@ -33,7 +33,7 @@ rather than events all live there. This document assumes them.
 | Chop filter on the entry rung | `{ "metric": "CLOSE", "transformId": "efficiency", "timeframe": { "rel": "lower" }, "window": 5, "bars": "closed" }` | `close_ltf_er` (≥0.6 directional) |
 | One-bar volume concentration | `{ "metric": "VOLUME", "transformId": "maxShare", "timeframe": { "rel": "lower" }, "window": 4, "bars": "closed" }` | `volBase_ltf_maxShare` |
 | Room to structure | `{ "metric": "STRUCT_ZONES", "transformId": "nearestZoneDist", "timeframe": { "rel": "regime" }, "side": "resistance" }` | `zones_htf_resist_dist` |
-| Last **closed** daily read | `{ "metric": "RSI14", "transformId": "value", "timeframe": { "abs": "1d" }, "offset": 1 }` | `RSI14_1d` — `RSI14[t - 1]` |
+| Last **closed** daily read | `{ "metric": "RSI14", "transformId": "value", "timeframe": { "abs": "1d" }, "bars": "closed" }` | `RSI14_1d` — the newest completed daily bar |
 
 ## Cross detection
 

package/skills/battlegrid-strategy-examples/references/tradingview-ports.md

@@ -21,7 +21,7 @@ Players often ask for strategies by the name of a popular TradingView script. Po
 **process** (regime filter → setup state → trigger → stop engine), and where the catalog lacks
 the primitive, name the substitution in the spec-lock question — never present a substitute as
 the thing itself. Most TV strategies run on the daily chart: carry that with the
-daily-strategy pattern above (pinned-1d thesis at `offset: 1` on an intraday anchor), which
+daily-strategy pattern above (pinned-1d thesis with `"bars": "closed"` at offset 0 on an intraday anchor), which
 binds decisions to daily closes while the studio keeps managing risk intraday.
 
 Event-column behaviour, state-vs-event, previous-session-level binding and the squeeze's anchor calibration are
@@ -45,8 +45,7 @@ rules about the columns themselves, not about porting — they live in the skill
   `ST_DIR enters "bullish"` is TRUE on the one completed bar the direction turned, and
   `ST_DIR exits "bullish"` on the bar it turned back — see `## Conditions` in the skill body.
 - **MACD + 200 MA filter** → `ABOVE_200` building block (`dist_SMA200 gt 0`) referenced by a
-  carrier with `MACD_cross is "Bullish"`; rules `macd_bull/bear_cross` 3 required +
-  `ma_sma200_above/below` 2 required; swing-trend geometry.
+  carrier with `MACD_cross is "Bullish"`; swing-trend geometry.
 - **Golden / Death Cross** → `SMA50 spread SMA200 × trajectory` gives state and freshness:
   `SMA50_SMA200_spread_now gt 0` AND `_trend is "rising"`; optional breadth gate on
   `mktBreadth_crypto gte 0` — every published scope resolves, not only `all`, because the leg reads
@@ -54,8 +53,7 @@ rules about the columns themselves, not about porting — they live in the skill
   the canonical definition and stays the default port; `EMA50` is available as the crypto variant
   when a player asks for it by name.
 - **RSI-2 (Connors)** → `RSI2` is native, so this ports exactly: `RSI2 lte 10` gated by required
-  `ABOVE_200`; the source's fast exit is time — timeDecay ON (180/60, 15→50, stale 20);
-  `rsi_oversold` 3 required with a tuned threshold. Keep the literal `lte 10` as the GATE:
+  `ABOVE_200`; the source's fast exit is time — timeDecay ON (180/60, 15→50, stale 20). Keep the literal `lte 10` as the GATE:
   `RSI2 × classifyZone` exists and reads on the same Connors bands, but a zone label is a fixed
   reading while the literal is a threshold the author can see and tune. Use the zone as a report
   column, never as the substitute for the gate.
@@ -63,16 +61,14 @@ rules about the columns themselves, not about porting — they live in the skill
   stretch; required `NOT [ADX_state in ["trending","extreme"]]` veto; scalp geometry +
   aggressive timeDecay (VWAP anchors daily at 00:00 UTC).
 - **Donchian / Turtle breakout** → `zone is "breakout high"` + `dist_donchianHi gte 0` +
-  `RVOL gte 1.5`; `sr_resistance_break` 3 required; turtle exits = trend preset (trail from
+  `RVOL gte 1.5`; turtle exits = trend preset (trail from
   1R, giveback 50). Mirror with `"breakdown low"`. **Daily-breakout variant on any anchor:**
   pin the structure at 1d — `zone_1d is "breakout high"`, `dist_donchianHi_1d gte 0` (validated).
   **Literal previous-day levels are native**: `dist_PDH gte 0` composes directly. They are TIMELESS
   and take `{rel: 'anchor'}` — see `## Header grammar` in the skill body.
 - **ICT / SMC (FVG + order blocks)** → `STRUCT_ZONES` is the native zone engine:
   `zones_htf_support_type` (`bullish FVG`/`bullish order block`), `zones_htf_support_dist
-  between 0 1.5`, `_age_h gte 12`, HTF bias required via `MAalign_htf`; rules
-  `structure_fvg_approach`/`structure_ob_approach` required (their `proximityPct` is the
-  in-zone dial). Liquidity sweeps, displacement, killzones and event *sequencing* are shapes the
+  between 0 1.5`, `_age_h gte 12`, HTF bias required via `MAalign_htf`. Liquidity sweeps, displacement, killzones and event *sequencing* are shapes the
   grammar does not have — a clause compares one column with a literal or with its own previous
   completed bar, never with another column or an earlier event, so an ordered sequence of events
   cannot be stated at all. That is a grammar limit, not a missing metric; name it as

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

@@ -28,8 +28,8 @@ Not "what were its returns" — whether it did *the thing it was told to do*.
 - `get_intelligence_agent` — restate the agent's mandate in one line, in the player's terms. This
   is the yardstick; without it "up 4%" means nothing.
 - `get_strategy` on the `strategyId` that read returns — the mandate is the bound strategy, so the
-  yardstick is its admission gates, required conditions and trade levels, not the agent's overlay
-  prose. Read `bindingState` too: at `SYNCING` or `ORPHANED` the agent evaluates a materialized copy
+  yardstick is its entry conditions — required and verdict-carrying, the only deterministic entry
+  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.

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

@@ -19,14 +19,14 @@ re-sorts a list, re-derives a verdict, or approves on the player's behalf.
 ## 1. When the player names a coin and not an agent — choose the agent
 
 - `scan_coin_agents` for the coin. The rows arrive server-ranked across the player's own agents:
-  `qualified` by score, then `rejected` with the first failing gate, then `unscorable` with the
+  `qualified` first, then `rejected` with the first failing gate, then `unscorable` with the
   reason, then `ineligible` with the refusal `propose_entry_decision` would give (`AGENT_NOT_ACTIVE`,
   `MODEL_INACTIVE`, `AGENT_HALTED`). Read them **as written** — never re-sort or re-derive a verdict.
 - **Ask the top-ranked qualifying agent**, and name the other agents that qualified so the player can
   choose one of them instead. One request per coin: the platform holds one pending request per coin
   across all of the player's agents, so ask one agent, not each of them.
 - **When none qualifies, say so plainly.** Name each agent's blocking gate or ineligibility, and offer
-  the strategy doctor for the one closest to qualifying. Never propose through an agent the scan
+  the strategy doctor for the one whose blocking gate is the one to work on. Never propose through an agent the scan
   reports rejected, unscorable or ineligible.
 - **When the player has no agent at all**, the scan is empty: say so, and the next step is building one
   (a strategy first, when they have none).
@@ -34,8 +34,8 @@ re-sorts a list, re-derives a verdict, or approves on the player's behalf.
 
 ## 2. Which coins fit the agent right now
 
-- `scan_agent_coins` for the agent. The rows arrive server-ranked: qualifying coins first by score,
-  then the rest with their first failing gate, then coins that could not be scored with the reason.
+- `scan_agent_coins` for the agent. The rows arrive server-ranked: qualifying coins first by ticker,
+  then the rest with their first failing gate, then coins that could not be evaluated, with the reason.
   The scan reads the agent's gates and spends no LLM call.
 - Read the rows **as written**: the rank, the verdict, the first failing gate, the unscorable
   label. Never re-sort them and never re-derive a verdict from its numbers — the server's ranking