# Cron Job: Crypto Copy Observation 7d final evaluation **Job ID:** dd91ce3850b1 **Run Time:** 2026-06-28 09:11:39 **Schedule:** once at 2026-06-28 09:10 ## Prompt [IMPORTANT: The user has invoked the "algorithmic-trading-bot-safety" skill, indicating they want you to follow its instructions. The full skill content is loaded below.] --- name: algorithmic-trading-bot-safety description: "Safety-first engineering workflow for API-based algorithmic trading bots: dry-run gates, runtime state separation, journals, daily risk limits, kill switches, panic guards, and side-effect-free alert plans." version: 1.0.0 author: Hermes Agent license: MIT metadata: hermes: tags: [algorithmic-trading, trading-bots, risk-management, hyperliquid, safety, dry-run, testing] related_skills: [test-driven-development, github-pr-workflow, finance-system-architecture] --- # Algorithmic Trading Bot Safety Engineering Use this skill when modifying, refactoring, reviewing, or deploying an API-based crypto/market trading bot, especially one that can place live orders on an exchange such as Hyperliquid. ## Core rule Treat trading code as production-financial software. Default to **no live side effects** until safety boundaries are explicit, tested, and intentionally enabled. When the user asks for a trading decision, live/autonomy recommendation, or live-trade status, answer like a portfolio/risk manager first, not like a developer: be concise, name one strategy, state live/no-live clearly, give evidence for/against, and avoid raw JSON, commit/build logs, process dumps, or implementation chatter unless explicitly requested. Routine trading reports should be short plain-language summaries with positions, PnL, stops/reconcile status, and a clear yes/no on whether the bot is currently profitable. For tiny autonomous crypto live mode, use the gate/reporting pattern in `references/tiny-autonomous-live-gates-and-reporting.md`: final preflight must pass, Mainnet account and API-wallet credentials must be separated and validated, read-only reconcile must be clean, loss/reconcile/stop gates must fail closed, and normal mini-trades should be summarized in the daily report rather than spammed. ## Standard workflow 1. **Start from a clean branch** - Verify git status and current branch. - Work on a feature/safety branch. - Keep remotes token-free. 2. **Use TDD for behavior changes** - Write failing tests first for entry decisions, exit decisions, risk gates, journal metrics, alert formatting, and panic guards. - Keep exchange/network calls out of unit tests. - Prefer pure functions and small dataclasses for decisions. 3. **Separate runtime data from source code** - Keep logs, journals, account health, cooldowns, reports, CSV exports, and portfolio state out of Git. - Write runtime state under a user-local runtime directory, e.g. `~/.local/state//`. - `.gitignore` runtime artifacts aggressively. 4. **Centralize configuration** - Use a typed config object loaded from JSON/env. - Include explicit flags for: - `dry_run` - `tls_verify` - `runtime_dir` - max open positions/trades - max daily loss - max daily trades - cooldown period - Default `dry_run` to true. 5. **Add an execution boundary** - Wrap exchange calls behind a small executor. - In dry-run mode, return structured intended actions without calling the exchange. - In live mode, delegate to the exchange client. 6. **Keep strategy/risk pure and testable** - Extract entry logic into a pure strategy function returning an `EntryDecision`. - Extract exit logic into a pure strategy function returning an `ExitDecision`. - Extract risk gates into a separate function returning a `RiskDecision`. - Do not bury risk checks inside a large infinite loop if they can be tested independently. 7. **Implement hard safety gates** - Kill-switch file blocks new entries. - Daily loss limit blocks new entries once realized PnL breaches threshold. - Daily trade limit blocks new entries after the configured count. - Panic-close requires an exact wallet-specific confirmation string. 8. **Journal every trading decision** - Append JSONL events for entry/exit. - Include UTC timestamp, event type, coin, side, price, size, dry-run flag, reason, realized PnL when known, and structured extras. - Daily metrics must ignore dry-run events when calculating live realized PnL. 9. **Plan alerts before sending them** - Build side-effect-free alert plans first. - Assert alert plans have `side_effects=()` in tests. - Ensure alert text never contains credentials, API keys, private keys, raw wallet secrets, or token paths. - Only after the plan boundary is green should a Telegram/email adapter perform actual sending. - For Telegram topic bots, require an explicit thread/topic ID before sending; missing topic ID should skip/fail closed. 10. **Prefer paper trading before live strategy work** - Add a paper exchange/executor that matches the subset of the real exchange interface the bot uses (`set_leverage`, `create_order`, `fetch_positions`). - Persist paper state under the runtime directory, not Git. - Keep live market-data reads separate from order execution so the bot can use live prices with simulated fills. - Distinguish `dry_run` from `paper_trading`: dry-run means no execution at all; paper trading means execution is allowed but lands in local paper state. - Collect market context for strategy learning, not blind execution - Before moving from toy paper sizes to a planned live wallet, add wallet-aware risk-based position sizing: derive notional from wallet equity, risk-per-trade percent, stop distance, leverage caps, margin/notional caps, and journal the sizing decision. See `references/risk-based-position-sizing.md`. - During paper-trading runs, collect chart/exchange context into runtime JSONL separate from the trade journal. - Include indicators such as RSI-14, SMA fast/slow, ATR-14, Bollinger bands, VWAP, funding, open interest, volume/liquidity, and derived tags. - Track source/reliability metadata for every context source; news, listings, social, or rumor-like signals are context only until measured against outcomes. - Correlate each paper/live trade to the most recent preceding context snapshot and score tags/sources by hit rate, average return, drawdown, time-in-trade, and exit reason. - With fewer than ~5 closed paper trades, report observations only; do not recommend strategy changes from tiny samples. 12. **Supervise paper runs as experiments** - Start long-lived paper bot processes under managed background process tooling, then verify the startup mode from runtime logs before reporting success. - For multi-strategy paper fleets, do not rely on a launcher that starts child processes and exits; keep a long-lived supervisor parent or tracked background process so VM/session restarts do not silently leave `0` bots running. - After a VM/network interruption, check actual process count, recent log mtimes, and exchange connectivity before interpreting missing trades as a strategy signal. - If exchange market-data/API access is degraded during paper/live-preview learning runs, fail closed at the runtime iteration boundary: report `status=degraded`, journal health and blocked shadow signals with `api_degraded`, create no entries/fills/order intents, and do not weaken live gates. See `references/hyperliquid-paper-api-degraded-fail-closed.md`. - Pair a silent/script-only market-context collector with a slower LLM-backed analyst monitor that reports to the correct trading topic. - Monitor jobs must fail safe: no live orders, no config/code changes, and no strategy tuning without explicit user approval. For paper-only fleets, a watchdog may alert or restart only after explicitly verifying mode flags remain paper-only. - Prefer a read-only dashboard after journal/context/correlation are stable; dashboards should inspect runtime state only and never place orders or mutate config. - See `references/paper-fleet-supervisor-watchdog.md` for a concrete supervisor/watchdog pattern and restart-status checklist. 13. **Run strategy tournaments as isolated paper/backtest portfolios** - When comparing old Git strategies, reconstruct parameter presets instead of running historical commits directly. - Group near-duplicate commits into strategy families and label hand-picked challengers as candidates. - Give every strategy its own runtime directory, paper state, journal, metrics, logs, and PID file under `~/.local/state//experiments//`. - Include `strategy_id` in every journal event so tournament metrics and context correlation can separate outcomes. - Before launching parallel bots, cap API load: filter exchange-internal pseudo-symbols (for example `@123`), stablecoins, malformed symbols, blacklists, and illiquid assets; use a liquid whitelist and `max_scan_coins` for live paper runs. - Cache expensive baseline/indicator requests, set request timeouts, throttle repeated error logs, and use unbuffered logging for background processes. - Rank by risk-adjusted metrics (expectancy, drawdown, profit factor, win rate, time-in-trade) and keep reports observation-only for tiny samples. - When live paper signals are rare, add a side-effect-free historical replay layer with walk-forward segments, per-coin attribution, exit-reason stats, coin-leakage checks, and small parameter sweeps around the current champion. - When paper bots produce zero trades, add near-miss telemetry before loosening thresholds: record closest rejected signals, trigger distance, reject reason, and strategy ID into runtime JSONL, then surface it in the read-only dashboard. - Do not overfit only to previous bot versions: add an independent strategy lab with tested archetypes (for example momentum breakout, RSI mean reversion, trend pullback, volatility-squeeze breakout) and rank them against the same cached candles before promoting any candidate. - If the user wants to explore non-mean-reversion approaches, add a separate paper-only strategy-family sampler rather than stretching the flash-crash entry path. Use a `strategy_family` dispatch, family-specific config/env mappings, replay parity tests, and research-only dashboard labeling; see `references/non-drop-strategy-samplers.md`. - When prior human/AI development notes contain durable trading lessons, encode them as explicit paper-only candidate constraints and regression tests (for example short dead-fish exits, hard unlevered stops, early break-even snap), not as live settings. - Make long-horizon replay data quality explicit: handle API rate limits with bounded retry/backoff, use stale-cache fallback only with reporting, and mark missing/fresh/stale coin coverage. - Promote sweep winners only as new paper-only candidate presets; never live-trade from replay alone. - Add read-only dashboards after journals/reports exist; dashboards may inspect runtime state but must not place orders, mutate config, or restart bots. If the user needs phone/PC access, serve only the runtime reports directory over the Tailscale IP and make the static dashboard refresh explicit. - For long-running paper fleets after VM/network restarts, add a script-only hourly watchdog that is silent when healthy, verifies exact expected strategy IDs and paper-only env flags, avoids restart thrashing when the exchange API/DNS is down, and restarts only the focused paper fleet when processes are missing/unsafe/unexpected. Before enabling the watchdog, remove scorecard-blocked strategy IDs from the running fleet rather than wasting scan/API capacity on known losers. Use a canonical focused runner outside Git, verify actual child process environments, and probe Hyperliquid `/info` with a JSON POST such as `{"type":"meta"}` rather than a bare GET. When pruning a noisy fleet into a focused paper set, patch the runner, watchdog, and monitor prompt together, run the runner, regenerate the read-only scorecard, and remove any initially selected strategy that the latest scorecard marks Blocked. See `references/paper-fleet-watchdog-and-focused-strategies.md`, `references/focused-paper-fleet-repair.md`, and `references/focused-paper-fleet-pruning.md`. - Before live-preview/live discussion, dashboard open exposure as well as closed trades: open count, unrealized PnL, notional, margin, leverage, entry/current price, and strategy ID. Persist enough paper/live position metadata (`entryTs`, `highPrice`, `atrSlPx`, `beActive`, `trailingActive`) so restarted bots can recover exit state; conservatively reconstruct legacy positions and log throttled warnings. See `references/open-position-dashboard-restart-state.md`. - When live is paused but paper/shadow experiments should restart, first make Mainnet reconcile clean without exchange side effects: back up live runtime state, remove only exchange-absent stale local `open_entries`, keep kill-switch/new-entry blocks active, re-run read-only reconcile, then start paper-only processes and verify their exact env from `/proc//environ`. See `references/live-state-cleanup-before-paper-restart.md`. - For Hyperliquid v76 live-preview hard gates, prove Mainnet read-only reconciliation, expanded market context/DataQualityGate, API health/degraded mode, testnet ALO+Cancel, scheduleCancel, Fill+Stop, NonceManager/API-wallet isolation, and final preflight before any live-preview recommendation. Keep scorecard verification VM-safe: use a journal-only fast path with `--max-bots`, short timeouts, and isolated terminal commands rather than full dashboard snapshots or chained monster commands. See `references/hyperliquid-v76-hard-gates-and-vm-safe-verification.md`. - After Testnet execution is technically proven but live-preview is still blocked, run v76 as a **paper-runtime learning harness** instead of weakening live gates: Mainnet market data read-only, local `PaperExecutor`, strict and research-probe variants, `signal_journal.jsonl` for every blocked/accepted signal, replay/ablation against old paper journals, and a v76 learning block in the fast scorecard. Research-probe variants must be marked paper-only/research and never auto-promoted to live. See `references/hyperliquid-v76-paper-runtime-learning-harness.md`. - Before any Hyperliquid signed smoke, validate the account-vs-agent credential model: `HL_ACCOUNT_ADDRESS` is the funded account/subaccount and SDK `account_address`; `HL_AGENT_PRIVATE_KEY` is the signer; `HL_AGENT_WALLET_ADDRESS` must exactly match the address derived from the agent private key; account and agent addresses must differ. Read-only reconciliation may run with only the account address and should report credential warnings with `private_key_used=false`, but `scheduleCancel`, ALO+Cancel, Fill+Stop, and live signed paths must fail closed until the agent-wallet check is green. See `references/hyperliquid-agent-wallet-credential-gate.md`. - When promoting a proven paper strategy toward **tiny autonomous live**, use a dedicated final preflight mode rather than generic live-preview. Hard-block on any red gate other than exchange-volume-only conditional `scheduleCancel`: signed mainnet credential consistency, clean read-only reconcile/no open exposure, API/DataQualityGate green, kill-switch off, daily/weekly/loss-streak gates active, reconciler active, real alert delivery proven, legacy live paths blocked, testnet forced-signal Fill+Stop clean, net paper scorecard gates green, and no mainnet order before final launch. If signed credentials are inconsistent, do not start even a tiny order. See `references/tiny-autonomous-live-gating.md`. - Once those final gates are green, do **not** improvise by calling a low-level executor directly. Build/start a minimal autonomous live runtime runner with shadow-by-default mode, explicit live env gate, persistent runtime state/nonce/signer lock, strategy-pure `OrderIntent` generation, live-only exchange side effects, immediate reduceOnly stop placement after fill, and post-start reconcile. Load runtime `open_entries` into the generic watchdog/reconciler so the first live position is not falsely flagged as `exchange_position_without_local_journal`. Split strict **start preflight** from **ongoing runtime gates**: `no_open_positions_or_orders_before_start` must block initial launch, but after launch managed positions with confirmed reduceOnly stops may continue and add entries up to configured max exposure. At each loop, prune local `open_entries` for coins no longer present on exchange before reconcile/preflight so stale local journals do not block healthy managed exposure. Add profit protection before claiming the live runner can “let winners run”: preserve initial stop distance, then manage break-even, profit-lock, trailing-stop, and dead-fish exits before scanning new entries; submit tighter reduceOnly stops before canceling older looser stops. See `references/tiny-autonomous-live-runtime-runner.md`. - If live trade history shows repeated negative closes or the user says most trades are losing, treat it as an **edge failure**, not a leverage/sizing problem: verify stops, stop/pause new entries, activate kill-switch or block-new-entries, analyze round-trip PnL/fees/holding-time buckets/coin attribution, and require a fresh positive shadow/paper sample before restarting live. Keep reports short and plain-language; see `references/live-trade-history-review-and-pause.md`. - When a shadow/paper run is roughly directionally right but net-negative after fees, create a new paper-only challenger rather than tweaking live settings: add a fee-aware entry hurdle, funding carry filter, anti-chase/overextension gate, separate runtime directory, and mark-to-market treatment for open positions before evaluating profitability. See `references/fee-funding-aware-shadow-v2.md`. - When live fills show that most trades close negative and entries are at local tops/bottoms, treat it as an edge/timing failure and build a paper-only fee-aware anti-chase challenger against real fill history: block overextended no-retest entries, require retest/reclaim plus market breadth, apply realistic fee/spread/slippage/funding hurdles, and keep live blocked until a 30-50 closed-trade paper/shadow gate is positive. See `references/fee-aware-anti-chase-paper-challenger.md`. - Separate Hyperliquid read-only credential checks from signed-action checks. Read-only reconciliation needs only `HL_WALLET_ADDRESS` and should warn, not fail, on `API Key`/private-key mismatch; signed Testnet probes may derive the signer from `HL_API_PRIVATE_KEY`, but Mainnet signed actions stay blocked. Use a masked credential matrix and no-position Testnet `scheduleCancel` probe before any order-path smokes. See `references/hyperliquid-env-separation-and-credential-probes.md`. - When the user clarifies the target as autonomous portfolio management rather than per-trade approval, keep live orders blocked until explicit live-autonomy approval, but design operations around hard risk limits, reconcile-first supervisors, critical-only immediate alerts, and a daily 19:00 Switzerland digest instead of mini-trade chat spam. See `references/autonomous-hyperliquid-operations-mode.md`. - Dashboards/scorecards must not trust `bot.pid` plus `os.kill(pid, 0)` alone for `running=yes`: stale PID files can point to unrelated reused PIDs. Verify `/proc//environ` matches the exact `CTB_STRATEGY_ID`, `CTB_RUNTIME_DIR`, `CTB_PAPER_TRADING=true`, and `CTB_DRY_RUN=false`, and add a regression test using the current test-process PID as a reused stale PID. See `references/dashboard-process-identity.md`. - When the user asks for paper-bot status, trend, adjustments, or how much longer/margin before live, run a compact status review: verify process liveness and paper/live env flags, run tests if readiness is discussed, aggregate per-strategy journals, compute win rate/profit factor/PnL/coin distribution, and count true open exposure only from non-zero contracts rather than merely from `positions` keys. See `references/paper-status-review-playbook.md`. - After open-position dashboarding exists, add a read-only live-readiness scorecard before discussing live preview. Score each strategy on closed-trade sample size, win rate, profit factor, realized + unrealized PnL, max drawdown, consecutive losses, coin leakage, average journaled risk, and explicit blockers. Gate statuses as Research / Candidate / Live-preview-ready / Blocked; keep tiny samples and `research-sampler` presets in Research even when one trade looks excellent. See `references/strategy-readiness-scorecard.md`. - When paper bots make zero trades, diagnose market selectivity before changing thresholds: check process liveness, log ticks, journal count, recent rolling drawdowns versus trigger thresholds, and add near-miss telemetry before launching any looser paper-only sampler. - When reviewing a 24h shadow/paper run, always separate closed net PnL from open exposure, mark open positions to current exchange price, compute fee drag/gross-vs-net, and estimate funding only as a small filter unless the system is explicitly funding-arbitrage. Do not call a run profitable when unclosed positions would make it negative. See `references/shadow-run-fee-funding-review.md`. - If a new paper challenger reports implausibly perfect results (for example 100% wins, identical PnL per trade, or the same number of trades every tick), treat it as a simulator-artifact investigation, not performance evidence. Inspect journals/state for instant synthetic exits, require persistent `open_positions`, block same-coin re-entry with `already_open`, archive invalid runtimes, and add a two-tick regression test before re-running. See `references/paper-challenger-simulator-artifact-review.md`. - When adding indicator expansion packs, keep each family as a pure entry function with tests and a visible `strategy_family` preset: trend-pullback SMA/VWAP, Bollinger+RSI mean reversion, confirmed squeeze breakout, and multi-day trend investment should remain `paper-only`, `research-sampler`, `not-champion` until replay + live-paper scorecards mature. - Paper alerting must be mode-aware: `dry_run=False` + `paper_trading=True` is `[PAPER]`, never `[LIVE]`, because paper execution intentionally simulates fills without exchange orders. - When the eventual live wallet size is known, do not treat current small paper notional as future live size. Add a pure position-sizing layer and replay/live parity around `wallet_equity_usdc`, `risk_per_trade_pct`, stop distance, leverage, margin caps, and notional caps; journal `notional_usd`, `margin_usd`, `risk_usd`, `stop_distance_pct`, and `sizing_cap` on entries. See `references/risk-based-position-sizing.md`. - When adding looser samplers, keep them isolated from champion presets: tag them `paper-only`, `research-sampler`, `not-champion`, make trade size small, keep hard stops/dead-fish timers tight, label them visibly in the read-only dashboard, and treat their results as data collection only; see `references/paper-signal-samplers.md`. - When a strategy/user describes crashes or stops in ROE terms (for example "15% crash") and coins use different leverage, normalize thresholds per coin: `required_unlevered_drop = max(strategy_flash_trigger_pct, target_roe_pct / coin_leverage)`. Record near-misses with leverage, ROE-equivalent drop, required drop, distance-to-entry, and reject reason before loosening thresholds. - When consolidating lessons from negative live fills, paper strategy tests, and copy-observation research into a live-candidate path, add a side-effect-free global policy gate and wire scorecards through it: market-regime, anti-chase, retest/reclaim, expected-move-vs-cost, promotion evidence, copy-observation, and safety gates must all be explicit, with missing Reconcile/Stop/Alert context failing closed. Paper runtimes must persist open positions and produce real fee/slippage-aware exit rows before promotion. See `references/global-strategy-policy-and-anti-chase-paper-gates.md`. - When multiple experiments produce durable lessons (negative live fills, promising but suspect paper, copy observation with no allowed entries), consolidate them into a side-effect-free global strategy policy rather than another narrative report. Encode regime, anti-chase, cost, promotion, simulator-sanity, copy-research, and live-safety gates as typed decisions with RED/GREEN tests; see `references/global-strategy-policy-gates.md`. - For paper-only signal samplers that intentionally loosen entry thresholds, verify ROE normalization does not silently re-tighten them on low-leverage coins. Set sampler-specific `crash_roe_trigger_pct` so `target_roe_pct / coin_leverage` equals the intended unlevered trigger, map that field through launch/runtime environment, and add failing tests that assert `effective_required_drop_pct()` preserves the sampler thresholds for representative low-leverage coins such as WLD/HYPE. - For crash-frequency questions, count distinct threshold-crossing events over rolling windows, report per-coin data coverage, and flag coin leakage when events cluster in one/two alts; see `references/leverage-aware-crash-telemetry.md`. - See `references/strategy-tournament-pattern.md` for the full tournament pattern. - See `references/replay-leakage-parameter-sweep.md` for replay/leakage/sweep details. - See `references/replay-data-quality-dashboard.md` for robust candle fetching and read-only dashboard patterns. - See `references/crypto-strategy-lab-and-survival-lessons.md` for independent strategy-lab screening, flash-crash survival lessons, V64-style candidate constraints, and launcher interpreter invariants. - See `references/paper-fleet-watchdog-and-strategy-lab.md` for the concrete hourly paper-fleet watchdog pattern plus the TDD/replay pattern for adding a liquidation-reversal lab archetype. - See `references/strategy-lab-expansion-archetypes.md` for adding independent side-effect-free lab families such as relative-strength rotation, risk-managed trend-following, and Donchian/volume breakout, including RED/GREEN tests, grid coverage, replay reporting, and conservative non-promotion gates. - See `references/defensive-strategy-lab-filters.md` for tightening promising replay archetypes before paper promotion: ATR/chop guards for trend-following, market-breadth/cash guards for relative-strength rotation, grid coverage tests, and replay interpretation. - See `references/relative-strength-paper-promotion.md` for promoting a cross-sectional/relative-strength replay winner into a conservative paper-only candidate, including market-history parity, process-env verification, and read-only scorecard reporting. - See `references/non-drop-strategy-samplers.md` for adding separate paper-only strategy-family samplers such as volatility squeeze breakout, including config/env mappings and replay/live parity pitfalls. - See `references/paper-dashboard-and-near-miss-telemetry.md` for Tailscale read-only dashboard serving, static refresh loops, and zero-paper-trade / near-miss diagnostics. - See `references/open-position-dashboard-restart-state.md` for open-position exposure dashboards, unrealized PnL calculation, and restart-state recovery for active positions. 14. **Verify before committing/pushing** - Run unit tests. - Run Python compile checks. - Scan for unsafe patterns such as `verify=False`, `except Exception: pass`, stale hardcoded workspace paths, and token-bearing remotes. - Commit with a conventional message. - Push with token-safe askpass handling; if PR API returns 403 but push succeeds, provide the manual PR URL. ## Pitfalls - **Live order paths hidden inside strategy code**: separate strategy decisions from execution. - **Dry-run that still calls the exchange**: dry-run must not call `create_order`, `market_open`, or `set_leverage`. - **Negative live expectancy after launch**: immediately pause new live entries/activate kill-switch, analyze real trade history, and require a fresh paper/shadow recovery gate before restart (for example: >=30 closed paper trades, positive total PnL, positive last-20 PnL, winrate >=45% or profit factor >=1.25, and no dominance by <15m scalps). - **Runtime logs committed to Git**: trading logs and journals can contain sensitive financial data. - **TLS disabled for convenience**: do not use `verify=False` or `ssl.CERT_NONE` unless explicitly configured and documented. - **Silent exception handling**: replace `except Exception: pass` with bounded logging. - **Panic-close without confirmation**: emergency scripts need explicit, wallet-specific confirmation to prevent accidental liquidation. - **Alerting as hidden side effect**: build alert plans first, then wire actual senders behind an explicit flag/adapter. - **Telegram alerts sent to the wrong place**: require explicit chat ID and topic/thread ID; fail closed when topic ID is missing. - **Multi-strategy monitors reading only root runtime paths**: tournament/paper runs store per-strategy logs, journals, PIDs, and paper state under `runtime_dir/experiments//`; cron monitors and dashboards must aggregate those experiment paths, not just `runtime_dir/Tradeanalyse`. - **Runner/watchdog/monitor drift**: when focusing or pruning a paper fleet, update the canonical runner, watchdog expected list, and cron/LLM monitor prompt in the same change. If they disagree, healthy paused strategies get reported as failures or watchdogs restart intentionally stopped losers. - **Stale local live state mistaken for exchange exposure**: if read-only reconcile reports a local-only coin that is absent from exchange positions/orders, back up and clean only local runtime state, then re-run reconcile. Never place an exchange order to resolve a local journal mismatch, and do not treat the cleanup as live-restart approval. - **Keeping a newly checked Blocked strategy**: after pruning recommendations, regenerate the scorecard before finalizing. If a candidate in the proposed focused set is now `Blocked` due to poor profit factor, negative PnL, high drawdown, or coin leakage, remove it from the running focused fleet unless the user explicitly wants it as a research sampler. - **Topic bleed from previous sessions**: in a Telegram topic/chat dedicated to the trading bot, do not pivot to unrelated repositories or tasks from adjacent session recall. If the user asks for status, answer the CryptoTradingBot status first and only use trading-bot context. - **Developer-log reflex during trading decisions**: when the user asks for a trader/portfolio/risk-manager decision, give a concise trading recommendation, assumptions, risks, and gates. Do not lead with commit lists, implementation logs, or long engineering narration unless explicitly requested. - **Manual-approval trap for autonomous trading**: after the user defines an autonomous-but-risk-bounded target mode, do not keep recommending approval for every mini-trade as the permanent operating model. Build/verify hard preflight, limits, watchdogs, and reporting so autonomy can be granted once safely, while still blocking when gates fail. - **Developer-log overload when a trading decision is requested**: if the user asks for a professional trader/risk-manager recommendation, do not lead with commits, modules, long technical status, or build logs. Answer with strategy choice, trading logic, realistic scenarios, current evidence, blockers, next risk-bounded stage, and one explicit recommendation; keep code details in journals unless asked. - **Confusing dry-run with paper trading**: dry-run should not create even simulated orders; paper trading requires dry-run off and a paper exchange on. - **Heavy scorecard commands destabilizing the VM**: do not run full dashboard snapshots just to refresh paper scorecards, and do not chain scorecard + grep + preflight + exchange smokes into one terminal command. Prefer journal-only fast scorecard paths, `--max-bots`, short timeouts, and separate evidence commands. - **Hyperliquid SDK `status=err` mistaken for success**: order/schedule/cancel calls can return structured responses with `status: "err"` even when the Python call itself does not raise. Testnet smoke tools must mark these gates red, journal the exchange response, and avoid reporting `ok` unless the exchange response itself is successful. - **Testnet wallet not registered**: `User or API Wallet ... does not exist` on Hyperliquid testnet means the provided signer/address is not usable for that testnet proof. Do not weaken gates or call it a tool failure; ask for a dedicated registered testnet API wallet/address and keep Mainnet untouched. - **Confusing account and agent wallet credentials**: Hyperliquid Info/read-only calls should use the funded account/subaccount address, while signed calls use the API/agent private key plus `account_address` set to the funded account. If the address derived from the agent private key does not exactly match the configured agent wallet public address, block all signed smokes. Keep read-only reconciliation separate so it can still inspect the account without touching the private key. - **Context overload becomes false confidence**: collect indicators/news/listing/social context with tags and source metadata, then score reliability against actual paper/live outcomes before using it in strategy. - **Auto-adjusting strategy too early**: with fewer than ~5 closed paper trades, collect data and state hypotheses only; do not tune parameters from anecdotes. ## Reference patterns - `references/hyperliquid-bot-safety-refactor.md` — concrete pattern from a Hyperliquid bot hardening session: config, dry-run executor, runtime paths, journal metrics, risk gate, panic guard, and PR-token caveat. - `references/market-context-paper-trading.md` — pattern for adding chart indicators, funding/open-interest context, source tags, reliability tracking, and dashboard-ready runtime files during paper-trading strategy development. - `references/paper-run-supervision.md` — pattern for launching, monitoring, and analyzing managed paper-trading runs with collector/analyst cron jobs and a read-only dashboard boundary. - `references/paper-fleet-watchdog-and-focused-strategies.md` — pattern for focusing a multi-strategy paper fleet after scorecard results and adding an hourly silent script-only watchdog that restarts only safe paper processes. - `references/hybrid-paper-strategy-consolidation.md` — pattern for turning paper-trade learnings into a new paper-only hybrid challenger, including module selection, falling-knife gates, coin-leakage controls, launcher/watchdog updates, and verification. - `references/trading-bot-concept-report-and-drive-delivery.md` — pattern for producing an outsider-readable AutoTradingBot concept/live-readiness report from current runtime evidence, including process/test/scorecard verification, coin-leakage interpretation, and Google Drive delivery via `gog` with verified artifact IDs. - `references/hyperliquid-copytrading-research-concept.md` — pattern for researching and designing Hyperliquid-native copytrading/copy-investing: vault due diligence, wallet-following shadow simulation, manipulation defenses, leader scorecards, quant/regime overlays, and HIP-3 stock/index derivative caveats. - `references/hyperliquid-copy-research-collector-runtime.md` — pattern for implementing a read-only copy-research collector/runtime: repo hygiene, DiscoveryRegistry to avoid survivorship bias, runtime snapshot paths outside Git, daily reports, one-shot entry points, and read-only safety tests. - `references/hyperliquid-copy-research-watchlist-report-v11.md` — extension pattern for runtime-only watchlists, central read-only guards, degradation-aware collector results, Market Context v1.1 summaries, and Daily Report v1.1 output. - `references/hyperliquid-copy-shadow-position-engine.md` — pattern for adding a read-only shadow-copy position engine: leader position deltas, copy pretrade gate integration, simulated follower entries/costs, shadow journals, report section, and no-order safety scans. - `references/hyperliquid-copy-observation-discovery.md` — pattern for adding candidate discovery, runtime-only watchlist activation, first real read-only wallet snapshots, observation report fields, and safe no-delta shadow interpretation. - See `references/hyperliquid-copy-observation-24h-runner.md` — pattern for adding a manually started bounded 24h read-only observation runner: 2h cycles, runtime logs/status/summary, safety gates, report run-status fields, and no-cron/no-systemd operation. - See `references/hyperliquid-copy-observation-7d-supervision.md` — pattern for extending a clean 24h copy-observation into a 7-day read-only run with 5-10 runtime-only wallets, bounded 84-cycle runner, daily script-only status cron, and final concise LLM evaluation. - See `references/hyperliquid-v76-live-preview-architecture.md` — pattern for migrating the legacy monolithic Hyperliquid `AutoTrader.py` into a safe v76 live-preview `src/` architecture with pure `OrderIntent` strategies, SDK executor boundaries, risk gates, reconciliation/missing-stop checks, and TDD verification. - `references/hyperliquid-v76-technical-proof-pattern.md` — phase-by-phase proof workflow for v76: legacy live guards, read-only Hyperliquid adapters, payload/testnet dry-run smokes, reconciliation, paper cost/scorecard net metrics, and verification checklist. - `references/hyperliquid-env-separation-and-credential-probes.md` — env-specific Mainnet/Testnet credential loading, read-only vs signed validation modes, masked credential matrix output, and safe Testnet-only legacy credential probes. - `references/hyperliquid-testnet-agent-wallet-smoke-gates.md` — Testnet agent-wallet credential validation, scheduleCancel volume-limit interpretation, ALO+Cancel proof, Fill+Stop cleanup, reduceOnly protection recognition, and final reconcile checklist. - `references/hyperliquid-testnet-strategy-harness.md` — Pattern for pushing a pure v76/strategy candidate through real Testnet execution with forced `OrderIntent`, PretradeRiskGate/DataQualityGate, reduceOnly stop reconciliation, cleanup, bounded natural-signal sessions, Mainnet-paper-only parallel tracking, and Telegram alert smoke reporting. - `references/tiny-autonomous-live-runtime-runner.md` — Minimal safe Mainnet autonomous runner pattern after final preflight: shadow mode, explicit live env gate, persistent runtime state/nonce/signer lock, pure strategy intents, live-only side effects, immediate reduceOnly stop confirmation, watchdog state integration, and post-start verification. - `references/live-trade-history-review-and-pause.md` — Pattern for responding when live trade history shows repeated negative closes: pause entries, keep protected stops, compute round-trip/fee/holding-time/coin attribution, and move strategy changes back to shadow/paper before restarting live. - `references/global-strategy-policy-gates.md` — Pattern for consolidating trading experiment learnings into a side-effect-free global policy gate with typed evidence, no-trade-first decisions, promotion criteria, copy-research limits, and RED/GREEN tests. - `references/crypto-trader-idea-testing-and-reporting.md` — Pattern for proactively proposing/testing professional crypto-trading ideas in paper/shadow mode, using market-regime long/short logic, concise user reporting, and evidence gates before restarting live. The user has provided the following instruction alongside the skill invocation: [IMPORTANT: You are running as a scheduled cron job. DELIVERY: Your final response will be automatically delivered to the user — do NOT use send_message or try to deliver the output yourself. Just produce your report/output as your final response and the system handles the rest. SILENT: If there is genuinely nothing new to report, respond with exactly "[SILENT]" (nothing else) to suppress delivery. Never combine [SILENT] with content — either report your findings normally, or say [SILENT] and nothing more.] Erstelle die finale, kurze deutschsprachige Auswertung der CryptoTradingBot Copy Observation 7d. Kontext und harte Regeln: - Runtime root: /home/agent/.local/state/CryptoTradingBot/copy_research - Observation run files: /home/agent/.local/state/CryptoTradingBot/copy_research/reports/observation_runs/*_7d_status.json und *_7d_summary.md - Verwende den neuesten 7d-Run, insbesondere den am 2026-06-20 gestarteten Run, falls vorhanden. - Keine Live-Entscheidung, keine Live-Copy, keine Orders, kein Signing, keine Vault-Deposits. - Prüfe Statusfile, Summary, Daily Reports, Collector/Shadow Results und Prozess-/Stale-Indikatoren soweit möglich. - Antworte kurz, deutsch, plain-language, ohne rohe Wallet-Listen oder JSON-Dumps. Bericht bitte mit: 1) completed/running/aborted/stale 2) Zyklen/84 und Snapshot-Coverage 3) Shadow-Decisions: allowed/blocked/ignored, Top-Gründe 4) Datenqualität/API-Probleme 5) Safety-Bestätigung read-only 6) Empfehlung: weiter read-only beobachten / Watchlist anpassen / keine Live-Copy Wenn der Run nicht vollständig oder stale ist, sage das klar und werte ihn nicht als valide 7d-Evidence. ## Response **CryptoTradingBot Copy Observation 7d – finale Kurz-Auswertung** 1) **Status:** completed. Der 7d-Run vom **2026-06-20** ist vollständig abgeschlossen, nicht running/aborted/stale. 2) **Zyklen & Coverage:** **84/84 Zyklen** abgeschlossen. Snapshot-Coverage vollständig: **8 beobachtete Wallets × 84 = 672 Wallet-Snapshots**. 3) **Shadow-Decisions:** - **allowed:** 0 - **blocked:** 150 - **ignored:** 2519 Top-Gründe: überwiegend unveränderte Positionen ignoriert, Positionsverkleinerungen ignoriert, neue Copy-Signale blockiert wegen **Position zu jung** bzw. Leader schon zu weit im Profit. 4) **Datenqualität/API:** Collector zuletzt **ok**, Data Quality **ok**, keine partiellen Fehler gemeldet. 5) **Safety:** Read-only bestätigt. **Keine Orders, kein Signing, keine Wallet/API-Wallet-Execution, keine Vault-Deposits, keine Live-Copy.** 6) **Empfehlung:** **Keine Live-Copy.** Die 7 Tage liefern saubere Beobachtungsdaten, aber **0 erlaubte Shadow-Copy-Entscheidungen** — damit gibt es keine belastbare positive Copy-Evidence. Weiter read-only beobachten und die Watchlist/Filter nur forschungsseitig anpassen; keine Live-Freigabe.