battlegrid-radar-deployment

Radar & Deployment

You are handing agents standing authority. A Radar policy puts EVERY rule whose conditions match on duty at once — each rule's regime read at its own agent's regime timeframe — and fires real trades at their confirmed closes with no further human action, at most one per deployment per pass, offered in rule priority; a deployment policy enters real sessions the same way. Nobody is watching when it happens — which is why the player has to see what a policy resolves to before it exists, not after.

Radar (per team and coin) and Arena deployment (per preset) are separate bounded contexts. They share no slot shape, no condition union and no resolution type. Never carry a fact from one to the other, and never describe them as one thing with two modes.

Deployments are the autonomous trading switches. An agent has no trading mode of its own: it trades a coin on its own only where a Radar policy puts it on duty, and an entry the player queues needs no deployment. An Arena deployment enters an agent into a preset's sessions and grants no trade permission — to have an agent trade a coin on its own, deploy it on Radar.

A Radar deployment is one team's watch on one coin. Each team trades on its own wallet, so a coin may be deployed once per team: Main's BTC and Swing's BTC are two deployments that sweep, fire, cool down and hold positions independently — one position per team per coin. Every Radar tool names the deployment with coinId and teamId; a teamId you omit addresses the player's Main team, so on a coin deployed for another team always pass that team. list_radar_deployments rows carry each deployment's teamId and teamName. The draft commit always names its team.

The five failures this flow exists to prevent

1. A write with no fresh preview. Cue: any commit_radar_deployment_draft, resume_radar_deployment, commit_deployment_policy_draft or resume_deployment_policy. The preview is the only place the player sees which agents actually go on duty and why. → steps 2–3.
2. A blind retry. Cue: a CONFLICT on a write. Something moved under you — the stored policy, or the player's draft. Retrying overwrites an edit you never read. → step 3.
3. Previewing one thing and writing another. Cue: the player adjusts a slot, a bar, a window or a regime after you previewed. A preview vouches only for what it resolved. → step 2.
4. A replacement that silently drops rules. Cue: a RULES axis staged over a deployed coin or a deployed arena. RULES is the COMPLETE ordered rule list on both: a rule you did not resend is deleted. → step 3.
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 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.