senpi-trading-runtime

Senpi Trading Runtime — the runtime contract

This skill is infrastructure: the canonical knowledge of how the Senpi runtime (@senpi-ai/runtime) behaves and how a strategy interacts with it. The lifecycle skills — author (build), ops (install/monitor), discover (recommend) — reference this one for the contract.

The runtime model

A strategy runs from a runtime.yaml that points at an in-repo Python module. The runtime spawns and supervises that module and calls a frozen scan(inputs, ctx) every interval_seconds. The division of labor is fixed:

• Your code produces signals — nothing else. scan(inputs, ctx) reads market and account data and returns a list[dict] of candidate signals. It does not open, close, size, schedule, or execute anything.
• Zero model cost, and the only loop there is. The runtime ticks every interval_seconds without a model call. Never put an agent-turn cron beside it — a producer, a re-check, a watcher — each firing is a full model call. There is no paper-trading mode: a strategy is tested with senpi validate (one real tick, no wallet) and then run live at the $10 floor.
• The runtime owns everything downstream: scheduling (interval_seconds), spawning + supervising + restarting the scanner, validating (signal_data_schema) + de-duplicating the signals you return, sizing & order execution (FEE_OPTIMIZED_LIMIT), slot accounting, risk.guard_rails, the two-phase DSL trailing-stop exits, and crash-safe position reconcile on restart.
• What it does NOT own: partial exits. Every exit the runtime can make (DSL, CLOSE_POSITION) closes the WHOLE position, and edit_position — the only reduce — is blocked to scanners. A rule like "take 25% off at +10% ROE and let the rest run" cannot be authored in a runtime package at all; a scanner that tries raises PermissionError every tick while the log reads as if the rule is working. Details: references/runtime-concepts.md → DSL Exit Engine.