[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6GTFSCPA4PFP8ET2JVSKWS4":3,"skill-same:01M6GTFSCPA4PFP8ET2JVSKWS4":160},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":16,"sourceHtmlUrl":17,"categories":18,"keywords":24,"publishedAt":56,"linkOnly":57,"markdownContent":58,"markdownBody":59,"frontMatter":60,"refName":65,"commitSha":66,"skillDirectory":67,"forksCount":68,"repositoryHtmlUrl":69,"repositoryHomepageUrl":6,"ownerHtmlUrl":70,"ownerBlogUrl":71,"ownerDescription":72,"updatedAt":73,"install":74,"resources":87},"01M6GTFSCPA4PFP8ET2JVSKWS4","senpi-trading-runtime",null,"How a Senpi trading strategy interacts with the runtime engine (@senpi-ai\u002Fruntime) on Hyperliquid: a strategy runs from a runtime.yaml pointing at a Python module that exports scan(inputs, ctx), which the runtime supervises and calls each interval, then owns execution, risk guard_rails, and two-phase DSL trailing-stop exits. Use when working with runtime.yaml, the scan(inputs, ctx) contract, external_scanner, ctx, or the DSL exit engine (the Ratchet Stop \u002F tier ladder) or the risk guard rails (a latched daily-loss or drawdown halt) — including verifying open positions are protected by DSL (have a working stop-loss). The shared runtime contract the lifecycle skills reference. NOT for building, installing, or picking a strategy (→ senpi-strategy-author \u002F senpi-strategy-ops \u002F senpi-strategy-discover).","jiayaoqijia\u002Fcryptoskill","jiayaoqijia","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1453879?v=4","01M6GMYTX7Q7S504VC6E756ENR","YQ","01M6GMYV1QKJ1CC75MTTGT9PR0",81,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fsenpi-ai-senpi-trading-runtime\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fsenpi-ai-senpi-trading-runtime\u002FSKILL.md",[19],{"categoryNo":20,"categoryName":21,"taxonomyType":22,"taxonomyTypeDesc":23},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55],"trading","senpi trading runtime","runtime","strategy","stop","dsl","for","when","phase","scanner","ratchet","risk guard","rails","how","at","positions","hyperliquid","contract","module","execution","open","exit","calls","python","lifecycle","daily","scan","discover","risk","which","shared","2026-11-10 10:12:30",false,"---\nname: senpi-trading-runtime\ndescription: >-\n  How a Senpi trading strategy interacts with the runtime engine (@senpi-ai\u002Fruntime)\n  on Hyperliquid: a strategy runs from a runtime.yaml pointing at a Python module that\n  exports scan(inputs, ctx), which the runtime supervises and calls each interval, then\n  owns execution, risk guard_rails, and two-phase DSL trailing-stop exits. Use when\n  working with runtime.yaml, the scan(inputs, ctx) contract, external_scanner, ctx, or\n  the DSL exit engine (the Ratchet Stop \u002F tier ladder) or the risk guard rails (a latched\n  daily-loss or drawdown halt) — including verifying open positions are protected by DSL (have a\n  working stop-loss). The shared runtime contract the lifecycle skills reference. NOT\n  for building, installing, or picking a strategy (→ senpi-strategy-author \u002F\n  senpi-strategy-ops \u002F senpi-strategy-discover).\nlicense: Apache-2.0\nmetadata:\n  author: Senpi\n  version: \"4.1.16\"\n  platform: senpi\n  exchange: hyperliquid\n---\n\n# Senpi Trading Runtime — the runtime contract\n\nThis skill is **infrastructure**: the canonical knowledge of how the Senpi runtime\n(**`@senpi-ai\u002Fruntime`**) behaves and how a strategy interacts with it. The lifecycle skills —\nauthor (build), ops (install\u002Fmonitor), discover (recommend) — reference this one for the contract.\n\n## The runtime model\n\nA strategy runs from a **`runtime.yaml`** that points at an in-repo Python module. The runtime **spawns and\nsupervises** that module and calls a frozen **`scan(inputs, ctx)`** every `interval_seconds`. The\ndivision of labor is fixed:\n\n- **Your code produces signals — nothing else.** `scan(inputs, ctx)` *reads* market and account data\n  and *returns* a `list[dict]` of candidate signals. It does not open, close, size, schedule, or\n  execute anything.\n- **Zero model cost, and the only loop there is.** The runtime ticks every `interval_seconds` without a\n  model call. Never put an agent-turn cron beside it — a producer, a re-check, a watcher — each\n  firing is a full model call. There is no paper-trading mode: a strategy is tested with `senpi validate`\n  (one real tick, no wallet) and then run live at the $10 floor.\n- **The runtime owns everything downstream:** scheduling (`interval_seconds`), spawning +\n  supervising + restarting the scanner, validating (`signal_data_schema`) + de-duplicating the\n  signals you return, **sizing & order execution** (`FEE_OPTIMIZED_LIMIT`), slot accounting,\n  `risk.guard_rails`, the two-phase **DSL** trailing-stop exits, and **crash-safe position reconcile**\n  on restart.\n- **What it does NOT own: partial exits.** Every exit the runtime can make (DSL, `CLOSE_POSITION`)\n  closes the WHOLE position, and `edit_position` — the only reduce — is blocked to scanners. A rule\n  like \"take 25% off at +10% ROE and let the rest run\" cannot be authored in a runtime package at\n  all; a scanner that tries raises `PermissionError` every tick while the log reads as if the rule\n  is working. Details: `references\u002Fruntime-concepts.md` → DSL Exit Engine.\n\n## How your code talks to the runtime\n\nThe interaction surface is small and one-directional — you read, you return signals, the runtime acts.\n\n- **`runtime.yaml`** declares the scanner(s), the action gate, the exit engine, and the risk\n  guard-rails, and passes author tunables down via `inputs:`. → `references\u002Fruntime-yaml.md`\n- **`scan(inputs, ctx)`** is the single entry point. `inputs` is the runtime's `inputs:` map; `ctx`\n  gives you:\n  - **`ctx.senpi_mcp.call_tool(name, args)`** — the Senpi MCP client, **read-only** (market,\n    account, leaderboard, discovery, `strategy_get*`, …). It is the only way to fetch data.\n  - **`ctx.state`** — transactional, runtime-persisted history (`last()` \u002F `append()` \u002F `len`) for\n    dedup, rotation, and first-seen ledgers; advances only on a clean tick.\n  - **`ctx.wallet`** — the strategy's wallet address.\n  - → `references\u002Fscan-contract.md`\n- **The return value** is a `list[dict]`, one per candidate signal (`asset`, `direction`,\n  `marginPct`, `leverage`, `data{}`). The runtime validates each `data{}` against the runtime.yaml's\n  `signal_data_schema`, then sizes, executes, and manages exits.\n\nKeep the thesis logic in a sibling pure **`scoring.py`** (no I\u002FO, no MCP) so it is unit-testable;\n`scan.py` does the reads + state, `scoring.py` does the math.\n\n## Runtime commands (essentials)\n\nThe plugin registers a `senpi` command group on the gateway. Deploying a strategy and checking it:\n\n```bash\nopenclaw plugins install @senpi-ai\u002Fruntime\nopenclaw senpi validate \u003Cdir-with-runtime.yaml>        # THE GATE, pre-money: one real tick, no wallet; a PASS records the proof deploy requires\nopenclaw senpi deploy -p \u003Cpackage-dir> --budget \u003Cusd>  # ONE verb, detached: funds preflight → wallet create+fund → install → one observed tick\nopenclaw senpi deploy status                           # the job's verified report (read-only); poll it with deploy.py status, below\nopenclaw senpi runtime list                            # id, source, status (\"running — NO ENTRY SCANNERS\" = scanners never wired)\n```\n\n**Deploy a package through `senpi-strategy-ops`' `deploy.py create \u003Cid> --budget \u003Cusd>`**, which\nresolves the package, runs the structural preflight and drives that same verb. The verb owns the\ngates — the live-universe check (`[E_UNIVERSE_NOT_LIVE]`, pre-money), the funds preflight, the\n`skillName`\u002F`skillVersion` attribution and the verified tick. **`runtime create` is internal**: it\ninstalls a runtime and skips every one of those, so it is not the deploy path. Then run\n**`python3 deploy.py status`** until the job is terminal (it calls the gateway directly, ~1 s per read)\nand relay its report; do NOT re-run `create` to check on a deploy.\n\n**`senpi validate` is the gate every deploy runs through** — it loads the scanners and runs one\nreal tick with no wallet and no funding, and a full unscoped PASS at live depth is what writes the\n`.senpi-proof.json` `senpi deploy` refuses to fund a package without. Run it before `deploy`, once per\ninstance, pointed at the directory holding that instance's `runtime.yaml`.\n\n**To CHANGE a strategy that is already live** → `openclaw senpi update`, not a delete-and-redeploy.\nDeleting a runtime abandons its DSL position files, so every open position loses the trailing stop\nthe strategy already promised and its replacement re-adopts from scratch at whatever price it\nfinds. `update` swaps the components in place and keeps DSL state, scanner stores and action\nhistory — no wallet is created, nothing is funded, and no position is closed.\n\n```bash\nopenclaw senpi update .\u002Fpkg                       # PLAN — what changes, what it leaves alone\nopenclaw senpi update .\u002Fpkg --apply               # commit (needs the same proof deploy needs)\nopenclaw senpi update .\u002Fpkg --apply --code-only   # assert only scan.py changed; refuses if not\n```\n\nIt plans by default; `--apply` is the only way to commit. `phase2.tiers` is what users call the **ratchet**;\nwith no open position, the edit plus `--apply` is the whole change. **`dsl_preset` changes are forward-only** — new\nentries only, while every open position keeps a snapshot of the preset it was opened under (other `exit:`\nfields, e.g. `order_type`, are read live and DO reach open positions). Refused outright, changing\nnothing: a different `strategy.wallet` (that is a new deployment, and the old wallet's positions\nwould be left unmanaged), an external scanner renamed or moved (state is keyed by name and position\ntogether, and inserting or removing one moves every external scanner below it — appending at the end\nmoves nobody and is allowed), or a changed `action_type` under a stable name. `--apply` also needs a\npassing proof that covers the recipe being applied, so point it at the package DIRECTORY: a recipe\nhanded over as bare text has nothing to verify against and is refused. Exit `2` means the runtime\nwas never touched; exit `1` means an apply was attempted and it may not be where you left it — read\nthe message before retrying.\n\n**Saved is not applied.** Without `--apply`, `update` changes nothing, and only the first line of its\noutput says so — `Dry run for \u003Cruntime_id> — nothing has been applied.` — so never pipe\n`openclaw senpi` output through `tail` or `head`. A scanner imports `scan.py` once, when it starts, so\na running strategy keeps its old code until `--apply` restarts its scanners (a crash or a gateway\nrestart would load the edit too, unannounced). `senpi validate` runs the copy on disk, never the\nrunning one, and re-running `deploy` on a strategy that is already running applies nothing. The edit\nis live once the apply exits `0` with `Updated \u003Cruntime_id>.` as its first line and no `WARNING` that\nits external scanners are NOT running, and the running strategy shows it:\n\n```bash\nopenclaw senpi events -r \u003Cruntime_id> --name runtime.updated   # an entry for this apply (code-only edits too)\nopenclaw senpi update .\u002Fpkg --id \u003Cruntime_id>                  # read-only: a recipe edit that landed plans \"The recipe is unchanged.\"\n```\n\nUntil both reads show it, tell the user the edit is **saved, not applied**. What a tick keeps and what\ndiscards one: `references\u002Fscan-contract.md`.\n\nBeyond `validate`, `deploy`\u002F`deploy status`, `update` and `runtime list\u002Fdelete`, the CLI exposes the runtime's live state — `senpi dsl\npositions|inspect|closes` (the exit engine), `senpi action list|inspect|history|decisions` (the\ndecision layer), `senpi risk` (am I allowed to trade, and why not — the daily loss and drawdown halts\n**latch**: they stay CLOSED after PnL recovers and survive restarts; a latched halt is the user's call, never\nclear it or resume entries without their explicit approval → `senpi-strategy-author\u002Freferences\u002Frisk-gates.md`), `senpi audit` (backend trade\ntrail with AI reasoning), `senpi scanner` (per-scanner health, liveness, and a `(no signals yet)` flag for scanners that run but produce nothing),\n`senpi events`\u002F`senpi explain \u003Casset>` (the local domain-event log — the trade narrative, and one\nasset's stitched lifecycle), `senpi status`\u002F`senpi state` (health — fail-closed: an external scanner\nnever proven by a tick reads `unknown`, not `healthy`; non-healthy scanners get their own line with\nrestart count and cause), and `senpi guide …` (in-shell reference). Full surface with every option →\n`references\u002Fruntime-cli.md`.\n\n**Trade approvals (OpenClaw 10.x).** `status` can also begin with one box-level line, `WARNING trade\napprovals: this box cannot tell chat turns from scheduled runs, so every run is asked, scheduled ones\nincluded. Reason: \u003Creason>.` It appears whatever the runtimes say, and only on an OpenClaw 10.x box\nwhose config needs a fix (the reason names the setting). Relay it to the user as a box setup problem\nfor Senpi support; nothing on the strategy side changes it. On OpenClaw 5.x there is no such line:\nevery run is asked there by design. `--json` carries the same fact as `approvals.turnClassification`\n(`available` \u002F `unavailable`, with `reason`, and `hostLimit: true` on 5.x). The `WARNING trade\napprovals` line is about the box, not a runtime: it does not mean a runtime is unhealthy, and its\nabsence on 5.x is normal. When the box can classify runs, a trade tool that needs approval asks the\nuser only from a direct chat turn. From a cron or heartbeat run, or another background run, the call\nis refused before it runs: `The trade was not executed: \u003Ctool> needs the user's approval, and this\nscheduled run (cron) has no way to ask for it. …`. Nothing was executed. Do what the refusal says:\ntell the user what you were about to do and that they can ask for it in chat, and do not retry it from\nthat run through another tool or script. A trade the user set to \"Always allow\" runs in any run kind.\n\n**To confirm open positions are actually stop-loss protected** (a position with no DSL shows up as an\n*absence* in `dsl positions`, so it's easy to miss) → the verdict procedure in\n`references\u002Fdsl-protection-check.md`.\n\n## The reference set\n\n| Read this | For |\n|---|---|\n| `references\u002Fruntime-concepts.md` | How the runtime behaves end to end: the runtime pipeline, `position_tracker`, and the two-phase DSL exit engine |\n| `references\u002Fruntime-yaml.md` | The `runtime.yaml` schema — every section, the `external_scanner` fields, the risk guard-rails |\n| `references\u002Fscan-contract.md` | The author contract in depth: `scan(inputs, ctx)`, the `ctx` surface, the signal shape, and `scoring.py` |\n| `references\u002Fruntime-cli.md` | The full `openclaw senpi …` command surface — **validate** (the pre-deploy gate: flags, depths, exit codes, the proof it records), deploy, runtime, dsl, action, status\u002Fstate, skills, guide |\n| `references\u002Fdsl-protection-check.md` | **Verify open positions are DSL-protected** — the PROTECTED \u002F UNPROTECTED \u002F STOP-NOT-ON-VENUE verdict + the open-vs-tracked reconciliation |\n\n## Package naming (load-bearing)\n\nThe runtime package is **`@senpi-ai\u002Fruntime`** (with `-ai`) — the one users install on their hosts.\nAlways write it with the `-ai`.\n","# Senpi Trading Runtime — the runtime contract\n\nThis skill is **infrastructure**: the canonical knowledge of how the Senpi runtime\n(**`@senpi-ai\u002Fruntime`**) behaves and how a strategy interacts with it. The lifecycle skills —\nauthor (build), ops (install\u002Fmonitor), discover (recommend) — reference this one for the contract.\n\n## The runtime model\n\nA strategy runs from a **`runtime.yaml`** that points at an in-repo Python module. The runtime **spawns and\nsupervises** that module and calls a frozen **`scan(inputs, ctx)`** every `interval_seconds`. The\ndivision of labor is fixed:\n\n- **Your code produces signals — nothing else.** `scan(inputs, ctx)` *reads* market and account data\n  and *returns* a `list[dict]` of candidate signals. It does not open, close, size, schedule, or\n  execute anything.\n- **Zero model cost, and the only loop there is.** The runtime ticks every `interval_seconds` without a\n  model call. Never put an agent-turn cron beside it — a producer, a re-check, a watcher — each\n  firing is a full model call. There is no paper-trading mode: a strategy is tested with `senpi validate`\n  (one real tick, no wallet) and then run live at the $10 floor.\n- **The runtime owns everything downstream:** scheduling (`interval_seconds`), spawning +\n  supervising + restarting the scanner, validating (`signal_data_schema`) + de-duplicating the\n  signals you return, **sizing & order execution** (`FEE_OPTIMIZED_LIMIT`), slot accounting,\n  `risk.guard_rails`, the two-phase **DSL** trailing-stop exits, and **crash-safe position reconcile**\n  on restart.\n- **What it does NOT own: partial exits.** Every exit the runtime can make (DSL, `CLOSE_POSITION`)\n  closes the WHOLE position, and `edit_position` — the only reduce — is blocked to scanners. A rule\n  like \"take 25% off at +10% ROE and let the rest run\" cannot be authored in a runtime package at\n  all; a scanner that tries raises `PermissionError` every tick while the log reads as if the rule\n  is working. Details: `references\u002Fruntime-concepts.md` → DSL Exit Engine.\n\n## How your code talks to the runtime\n\nThe interaction surface is small and one-directional — you read, you return signals, the runtime acts.\n\n- **`runtime.yaml`** declares the scanner(s), the action gate, the exit engine, and the risk\n  guard-rails, and passes author tunables down via `inputs:`. → `references\u002Fruntime-yaml.md`\n- **`scan(inputs, ctx)`** is the single entry point. `inputs` is the runtime's `inputs:` map; `ctx`\n  gives you:\n  - **`ctx.senpi_mcp.call_tool(name, args)`** — the Senpi MCP client, **read-only** (market,\n    account, leaderboard, discovery, `strategy_get*`, …). It is the only way to fetch data.\n  - **`ctx.state`** — transactional, runtime-persisted history (`last()` \u002F `append()` \u002F `len`) for\n    dedup, rotation, and first-seen ledgers; advances only on a clean tick.\n  - **`ctx.wallet`** — the strategy's wallet address.\n  - → `references\u002Fscan-contract.md`\n- **The return value** is a `list[dict]`, one per candidate signal (`asset`, `direction`,\n  `marginPct`, `leverage`, `data{}`). The runtime validates each `data{}` against the runtime.yaml's\n  `signal_data_schema`, then sizes, executes, and manages exits.\n\nKeep the thesis logic in a sibling pure **`scoring.py`** (no I\u002FO, no MCP) so it is unit-testable;\n`scan.py` does the reads + state, `scoring.py` does the math.\n\n## Runtime commands (essentials)\n\nThe plugin registers a `senpi` command group on the gateway. Deploying a strategy and checking it:\n\n```bash\nopenclaw plugins install @senpi-ai\u002Fruntime\nopenclaw senpi validate \u003Cdir-with-runtime.yaml>        # THE GATE, pre-money: one real tick, no wallet; a PASS records the proof deploy requires\nopenclaw senpi deploy -p \u003Cpackage-dir> --budget \u003Cusd>  # ONE verb, detached: funds preflight → wallet create+fund → install → one observed tick\nopenclaw senpi deploy status                           # the job's verified report (read-only); poll it with deploy.py status, below\nopenclaw senpi runtime list                            # id, source, status (\"running — NO ENTRY SCANNERS\" = scanners never wired)\n```\n\n**Deploy a package through `senpi-strategy-ops`' `deploy.py create \u003Cid> --budget \u003Cusd>`**, which\nresolves the package, runs the structural preflight and drives that same verb. The verb owns the\ngates — the live-universe check (`[E_UNIVERSE_NOT_LIVE]`, pre-money), the funds preflight, the\n`skillName`\u002F`skillVersion` attribution and the verified tick. **`runtime create` is internal**: it\ninstalls a runtime and skips every one of those, so it is not the deploy path. Then run\n**`python3 deploy.py status`** until the job is terminal (it calls the gateway directly, ~1 s per read)\nand relay its report; do NOT re-run `create` to check on a deploy.\n\n**`senpi validate` is the gate every deploy runs through** — it loads the scanners and runs one\nreal tick with no wallet and no funding, and a full unscoped PASS at live depth is what writes the\n`.senpi-proof.json` `senpi deploy` refuses to fund a package without. Run it before `deploy`, once per\ninstance, pointed at the directory holding that instance's `runtime.yaml`.\n\n**To CHANGE a strategy that is already live** → `openclaw senpi update`, not a delete-and-redeploy.\nDeleting a runtime abandons its DSL position files, so every open position loses the trailing stop\nthe strategy already promised and its replacement re-adopts from scratch at whatever price it\nfinds. `update` swaps the components in place and keeps DSL state, scanner stores and action\nhistory — no wallet is created, nothing is funded, and no position is closed.\n\n```bash\nopenclaw senpi update .\u002Fpkg                       # PLAN — what changes, what it leaves alone\nopenclaw senpi update .\u002Fpkg --apply               # commit (needs the same proof deploy needs)\nopenclaw senpi update .\u002Fpkg --apply --code-only   # assert only scan.py changed; refuses if not\n```\n\nIt plans by default; `--apply` is the only way to commit. `phase2.tiers` is what users call the **ratchet**;\nwith no open position, the edit plus `--apply` is the whole change. **`dsl_preset` changes are forward-only** — new\nentries only, while every open position keeps a snapshot of the preset it was opened under (other `exit:`\nfields, e.g. `order_type`, are read live and DO reach open positions). Refused outright, changing\nnothing: a different `strategy.wallet` (that is a new deployment, and the old wallet's positions\nwould be left unmanaged), an external scanner renamed or moved (state is keyed by name and position\ntogether, and inserting or removing one moves every external scanner below it — appending at the end\nmoves nobody and is allowed), or a changed `action_type` under a stable name. `--apply` also needs a\npassing proof that covers the recipe being applied, so point it at the package DIRECTORY: a recipe\nhanded over as bare text has nothing to verify against and is refused. Exit `2` means the runtime\nwas never touched; exit `1` means an apply was attempted and it may not be where you left it — read\nthe message before retrying.\n\n**Saved is not applied.** Without `--apply`, `update` changes nothing, and only the first line of its\noutput says so — `Dry run for \u003Cruntime_id> — nothing has been applied.` — so never pipe\n`openclaw senpi` output through `tail` or `head`. A scanner imports `scan.py` once, when it starts, so\na running strategy keeps its old code until `--apply` restarts its scanners (a crash or a gateway\nrestart would load the edit too, unannounced). `senpi validate` runs the copy on disk, never the\nrunning one, and re-running `deploy` on a strategy that is already running applies nothing. The edit\nis live once the apply exits `0` with `Updated \u003Cruntime_id>.` as its first line and no `WARNING` that\nits external scanners are NOT running, and the running strategy shows it:\n\n```bash\nopenclaw senpi events -r \u003Cruntime_id> --name runtime.updated   # an entry for this apply (code-only edits too)\nopenclaw senpi update .\u002Fpkg --id \u003Cruntime_id>                  # read-only: a recipe edit that landed plans \"The recipe is unchanged.\"\n```\n\nUntil both reads show it, tell the user the edit is **saved, not applied**. What a tick keeps and what\ndiscards one: `references\u002Fscan-contract.md`.\n\nBeyond `validate`, `deploy`\u002F`deploy status`, `update` and `runtime list\u002Fdelete`, the CLI exposes the runtime's live state — `senpi dsl\npositions|inspect|closes` (the exit engine), `senpi action list|inspect|history|decisions` (the\ndecision layer), `senpi risk` (am I allowed to trade, and why not — the daily loss and drawdown halts\n**latch**: they stay CLOSED after PnL recovers and survive restarts; a latched halt is the user's call, never\nclear it or resume entries without their explicit approval → `senpi-strategy-author\u002Freferences\u002Frisk-gates.md`), `senpi audit` (backend trade\ntrail with AI reasoning), `senpi scanner` (per-scanner health, liveness, and a `(no signals yet)` flag for scanners that run but produce nothing),\n`senpi events`\u002F`senpi explain \u003Casset>` (the local domain-event log — the trade narrative, and one\nasset's stitched lifecycle), `senpi status`\u002F`senpi state` (health — fail-closed: an external scanner\nnever proven by a tick reads `unknown`, not `healthy`; non-healthy scanners get their own line with\nrestart count and cause), and `senpi guide …` (in-shell reference). Full surface with every option →\n`references\u002Fruntime-cli.md`.\n\n**Trade approvals (OpenClaw 10.x).** `status` can also begin with one box-level line, `WARNING trade\napprovals: this box cannot tell chat turns from scheduled runs, so every run is asked, scheduled ones\nincluded. Reason: \u003Creason>.` It appears whatever the runtimes say, and only on an OpenClaw 10.x box\nwhose config needs a fix (the reason names the setting). Relay it to the user as a box setup problem\nfor Senpi support; nothing on the strategy side changes it. On OpenClaw 5.x there is no such line:\nevery run is asked there by design. `--json` carries the same fact as `approvals.turnClassification`\n(`available` \u002F `unavailable`, with `reason`, and `hostLimit: true` on 5.x). The `WARNING trade\napprovals` line is about the box, not a runtime: it does not mean a runtime is unhealthy, and its\nabsence on 5.x is normal. When the box can classify runs, a trade tool that needs approval asks the\nuser only from a direct chat turn. From a cron or heartbeat run, or another background run, the call\nis refused before it runs: `The trade was not executed: \u003Ctool> needs the user's approval, and this\nscheduled run (cron) has no way to ask for it. …`. Nothing was executed. Do what the refusal says:\ntell the user what you were about to do and that they can ask for it in chat, and do not retry it from\nthat run through another tool or script. A trade the user set to \"Always allow\" runs in any run kind.\n\n**To confirm open positions are actually stop-loss protected** (a position with no DSL shows up as an\n*absence* in `dsl positions`, so it's easy to miss) → the verdict procedure in\n`references\u002Fdsl-protection-check.md`.\n\n## The reference set\n\n| Read this | For |\n|---|---|\n| `references\u002Fruntime-concepts.md` | How the runtime behaves end to end: the runtime pipeline, `position_tracker`, and the two-phase DSL exit engine |\n| `references\u002Fruntime-yaml.md` | The `runtime.yaml` schema — every section, the `external_scanner` fields, the risk guard-rails |\n| `references\u002Fscan-contract.md` | The author contract in depth: `scan(inputs, ctx)`, the `ctx` surface, the signal shape, and `scoring.py` |\n| `references\u002Fruntime-cli.md` | The full `openclaw senpi …` command surface — **validate** (the pre-deploy gate: flags, depths, exit codes, the proof it records), deploy, runtime, dsl, action, status\u002Fstate, skills, guide |\n| `references\u002Fdsl-protection-check.md` | **Verify open positions are DSL-protected** — the PROTECTED \u002F UNPROTECTED \u002F STOP-NOT-ON-VENUE verdict + the open-vs-tracked reconciliation |\n\n## Package naming (load-bearing)\n\nThe runtime package is **`@senpi-ai\u002Fruntime`** (with `-ai`) — the one users install on their hosts.\nAlways write it with the `-ai`.\n",{"name":5,"license":15,"metadata":61,"description":7},{"author":62,"version":63,"exchange":41,"platform":64},"Senpi","4.1.16","senpi","main","80a3800bcfea5e7c17a4c696f34271d8abc05e8c","skills\u002Fexchanges\u002Fsenpi-ai-senpi-trading-runtime",17,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia","https:\u002F\u002Feth2030.com","Hardcore infra. Building @alt-research and applied cryptography.","2026-11-14 02:27:51",{"source":8,"skillName":5,"commands":75,"prompt":85,"zipAvailable":86},[76,79,82],{"tool":77,"command":78},"npx","npx skills add jiayaoqijia\u002Fcryptoskill --skill senpi-trading-runtime",{"tool":80,"command":81},"bunx","bunx skills add jiayaoqijia\u002Fcryptoskill --skill senpi-trading-runtime",{"tool":83,"command":84},"pnpm","pnpm dlx skills add jiayaoqijia\u002Fcryptoskill --skill senpi-trading-runtime","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fsenpi-ai-senpi-trading-runtime\u002FSKILL.md",true,[88,92,98,102,106,110,114,120,124,128,132,136,140,144,148,152,156],{"path":89,"resourceType":89,"resourceTypeDesc":90,"sizeBytes":91,"sourceHtmlUrl":16},"LICENSE","许可证",1070,{"path":93,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Fdsl-protection-check.md","REFERENCE","参考文档",5150,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fsenpi-ai-senpi-trading-runtime\u002Freferences\u002Fdsl-protection-check.md",{"path":99,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":100,"sourceHtmlUrl":101},"references\u002Fruntime-cli.md",15248,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fsenpi-ai-senpi-trading-runtime\u002Freferences\u002Fruntime-cli.md",{"path":103,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":104,"sourceHtmlUrl":105},"references\u002Fruntime-concepts.md",15973,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fsenpi-ai-senpi-trading-runtime\u002Freferences\u002Fruntime-concepts.md",{"path":107,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":108,"sourceHtmlUrl":109},"references\u002Fruntime-yaml.md",18493,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fsenpi-ai-senpi-trading-runtime\u002Freferences\u002Fruntime-yaml.md",{"path":111,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":112,"sourceHtmlUrl":113},"references\u002Fscan-contract.md",16106,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fsenpi-ai-senpi-trading-runtime\u002Freferences\u002Fscan-contract.md",{"path":115,"resourceType":116,"resourceTypeDesc":117,"sizeBytes":118,"sourceHtmlUrl":119},"scripts\u002Fbehaviour_hash.py","SCRIPT","脚本",11379,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fsenpi-ai-senpi-trading-runtime\u002Fscripts\u002Fbehaviour_hash.py",{"path":121,"resourceType":116,"resourceTypeDesc":117,"sizeBytes":122,"sourceHtmlUrl":123},"scripts\u002Fgen_catalog.py",13746,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fsenpi-ai-senpi-trading-runtime\u002Fscripts\u002Fgen_catalog.py",{"path":125,"resourceType":116,"resourceTypeDesc":117,"sizeBytes":126,"sourceHtmlUrl":127},"scripts\u002Fmin_budget.py",10070,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fsenpi-ai-senpi-trading-runtime\u002Fscripts\u002Fmin_budget.py",{"path":129,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":130,"sourceHtmlUrl":131},"SOURCE.md",344,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fsenpi-ai-senpi-trading-runtime\u002FSOURCE.md",{"path":133,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":134,"sourceHtmlUrl":135},"tests\u002Ffixtures\u002Fmin_budget_golden.json",2412,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fsenpi-ai-senpi-trading-runtime\u002Ftests\u002Ffixtures\u002Fmin_budget_golden.json",{"path":137,"resourceType":116,"resourceTypeDesc":117,"sizeBytes":138,"sourceHtmlUrl":139},"tests\u002Ftest_edit_is_live_only_after_apply.py",3328,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fsenpi-ai-senpi-trading-runtime\u002Ftests\u002Ftest_edit_is_live_only_after_apply.py",{"path":141,"resourceType":116,"resourceTypeDesc":117,"sizeBytes":142,"sourceHtmlUrl":143},"tests\u002Ftest_min_budget_golden.py",2712,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fsenpi-ai-senpi-trading-runtime\u002Ftests\u002Ftest_min_budget_golden.py",{"path":145,"resourceType":116,"resourceTypeDesc":117,"sizeBytes":146,"sourceHtmlUrl":147},"tests\u002Ftest_min_budget_tier_shapes.py",2615,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fsenpi-ai-senpi-trading-runtime\u002Ftests\u002Ftest_min_budget_tier_shapes.py",{"path":149,"resourceType":116,"resourceTypeDesc":117,"sizeBytes":150,"sourceHtmlUrl":151},"tests\u002Ftest_reference_candle_time_units.py",711,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fsenpi-ai-senpi-trading-runtime\u002Ftests\u002Ftest_reference_candle_time_units.py",{"path":153,"resourceType":116,"resourceTypeDesc":117,"sizeBytes":154,"sourceHtmlUrl":155},"tests\u002Ftest_reference_time_cuts_either_phase.py",773,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fsenpi-ai-senpi-trading-runtime\u002Ftests\u002Ftest_reference_time_cuts_either_phase.py",{"path":157,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":158,"sourceHtmlUrl":159},"TRUST.auto.yaml",2030,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fsenpi-ai-senpi-trading-runtime\u002FTRUST.auto.yaml",[161,190,211,229,242,252],{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":165,"licenseFileUrl":166,"sourceHtmlUrl":167,"categories":168,"keywords":169,"publishedAt":56},"01M712C436EQYE43342Q4E7GG1","recipe-performance","Diagnose a specific MetaMask user flow's real-app performance and Sentry critical-user-flow telemetry with deterministic mm-harness recipes. Use for CUF boundaries, cold\u002Fwarm\u002Fbackground-resume behavior, latency regressions, lifecycle tags, duplicate or blocking network requests, long tasks, layout\u002Fpaint cost, screen redraws, React rerenders, or browser trace analysis where tests alone cannot prove the real app.","MIT","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-performance\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fwallets\u002Fmetamask-official-recipe-performance\u002FSKILL.md",[],[170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189],"performance","recipe performance","recipe","mm","sentry","harness","app","deterministic","recipes","flow","cold","critical","analysis","tasks","react","browser","layout","screen","network","metamask",{"skillNo":191,"name":192,"nameZh":6,"description":193,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":194,"sourceHtmlUrl":195,"categories":196,"keywords":197,"publishedAt":56},"01M70XT2F8A5CQZ81JBP98KSW3","mexc-spot-websocket","MEXC Spot WebSocket workflows for public streams, protobuf handling, depth maintenance, listen keys, and private streams without exposing API keys.","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-spot-websocket\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-spot-websocket\u002FSKILL.md",[],[198,199,200,201,202,203,204,205,206,207,31,208,209,210],"mexc spot websocket","spot","websocket","api","workflows","public","listen","streams","depth","keys","api keys","maintenance","protobuf",{"skillNo":212,"name":213,"nameZh":6,"description":214,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":215,"sourceHtmlUrl":216,"categories":217,"keywords":218,"publishedAt":56},"01M70XT0MBXN3WZY1BKN0CPNKR","mexc-spot-rest","MEXC Spot REST workflows for public data, signed account requests, orders, wallet\u002Fadmin actions, and secure signing without exposing API keys.","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-spot-rest\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-spot-rest\u002FSKILL.md",[],[219,199,220,221,222,223,224,208,31,207,225,226,227,203,228,202,201],"mexc spot rest","REST","admin","signing","Wallet","requests","actions","secure","data","orders",{"skillNo":230,"name":231,"nameZh":6,"description":232,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":233,"sourceHtmlUrl":234,"categories":235,"keywords":236,"publishedAt":56},"01M70XSYSVZ2N0N91XCAR2CAK0","mexc-futures-websocket","MEXC Futures WebSocket workflows for public streams, private account\u002Forder\u002Fposition streams, ping\u002Fpong, subscriptions, and depth maintenance.","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-futures-websocket\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fmncrftfrcnm-mexc-futures-websocket\u002FSKILL.md",[],[237,238,200,239,240,209,31,241,206,205,203,202],"mexc futures websocket","futures","position","ping","subscriptions",{"skillNo":243,"name":244,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":165,"licenseFileUrl":245,"sourceHtmlUrl":246,"categories":247,"keywords":248,"publishedAt":56},"01M6H0ZWHVE5W04WG2DKQE2SQC","0xklen-version-and-refresh-sanctions-lists","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fpayments\u002F0xklen-version-and-refresh-sanctions-lists\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fpayments\u002F0xklen-version-and-refresh-sanctions-lists\u002FSKILL.md",[],[249,250,251],"refresh","0xklen version and refresh sanctions lists","version",{"skillNo":253,"name":254,"nameZh":6,"description":255,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":165,"licenseFileUrl":256,"sourceHtmlUrl":257,"categories":258,"keywords":259,"publishedAt":56},"01M6H0Z28Q3R8J0S799GJQWXM3","verify-tests-cover-changed-lines","Use when a PR adds code that the existing suite may not exercise. Measures patch coverage — the share of newly changed lines hit by tests — before approving.","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fpayments\u002F0xklen-verify-tests-cover-changed-lines\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fpayments\u002F0xklen-verify-tests-cover-changed-lines\u002FSKILL.md",[],[260,261,262,263,264,265,266,267,268,269,270],"tests","cover","verify tests cover changed lines","verify","coverage","pr","exercise","use","patch","code","share"]