EverWinter：基于浏览器的 Bybit USDT 永续合约交易套件

EverWinter is a browser-based trading suite for Bybit USDT Perpetuals executing the Winter-Chaser strategy. See the Strategy Guide for trading logic and rationale.

Files

Setup

Open any .html file directly in a browser. No build step, no server, no installation. Alpine.js and Bootstrap 5 are loaded from CDN — an internet connection is required on first load (cached after that).

For proactive Long-only trading; run PseudoChaser with MultiIndicator and Ashfall loaded, for proactive Short-Only trading; run PseudoWinter with MultiIndicator and Permafrost loaded. For reactive Long-only trading; run PsychoChaser, and for reactive Short-only trading; run PsychoWinter.

To understand the differences between the Reactive and Proactive approaches; read the Strategy Book, for a deeper dive on the Reactive bots' configs; read the Psycho Handbook.

Menus

The UI has four views: Market (positions, scan controls, watchlist) plus three configuration/telemetry panels — Config, Stats, and Trades.

Mobile (≤768px): a bottom tab bar (⚙ Config · 📊 Market · 📈 Stats · 📌 Trades) switches between the four views full-screen, one at a time. Unchanged from earlier builds.

Desktop: Market, Config, Stats and Trades all sit side by side in normal document flow at the same level — no overlay, no dimming, no shadow. Config/Stats/Trades open via matching icon buttons (⚙ 📈 📌) in the topbar — no dedicated Market button, since it's never hidden. Config opens by default on launch; click its icon again (or any open panel's icon) to dismiss it.

Market always gets twice the flex-grow of any open side panel, so with both sides open the split is exactly Market 2/4, left panel 1/4, right panel 1/4 (with only one side open, Market and that panel split roughly 2:1; with neither open, Market fills the row). Slot assignment follows opening order, not menu identity:

• First panel opened → left slot. Second → right slot.
• Once both slots are full, opening a third (currently-closed) panel replaces the left slot's occupant.
• Opening a fourth replaces the right slot's occupant — and it keeps alternating left/right on every subsequent replacement from there.

Two panels can be open at once; a third click always bumps whichever slot is due next rather than stacking a third panel.

Plugins

To load a plugin, open the Plugin Manager panel at the bottom of the config menu, click Load Plugin, and select the .html file. A page reload is required after loading or removing any plugin — the plugin pipeline runs once at page boot, so changes don't take effect until the next load.

EverWinter / SunChaser (Live Trading Plugins)

EverWinter turns PseudoWinter into a live short-only Bybit bot; SunChaser does the same for PseudoChaser as long-only. Both sign requests with the stored __ew_creds/__sc_creds API key and place real orders — the topbar reads Very Real Orders once loaded, in place of the base simulation's No Real Orders.

• Balance: fetched automatically the moment a valid key/secret pair is saved in the credentials panel, not only at page load.
• Symbol banning: a symbol is banned for a week if Bybit reports it as unsupported for trading, or blocked pending a required trading agreement (e.g. certain leveraged/inverse instruments) — either case needs the same manual action on Bybit's side before the symbol can trade again, so both are treated as a permanent block rather than retried every cycle.
• Post-bail re-check: after a bail sweep (manual Danger Zone bail or an automatic Drawdown Throttle bail), the plugin queries the exchange directly for any position still open in its own direction (Sell for EverWinter, Buy for SunChaser) and force-flattens it with a direct reduceOnly market order. This catches positions that failed to fully fill.

Main Config

Changes take effect immediately and are persisted to localStorage automatically.

Stats Menu

The stats panel shows session-level metrics since the page was last loaded or state was cleared.

Persistence mismatch: shown in red with a warning banner. It means a save failed or was overwritten, and usually clears on its own within a few seconds as the bot retries automatically. If it doesn't:

• Check the activity log for [PST]/[PERSIST] entries.
• Close any duplicate tabs of the same bot — a second tab can overwrite the first tab's saves with its own stale position count.

Storage usage (dropdown below Persistence, PseudoWinter/PseudoChaser only): breaks this bot's own localStorage footprint (plus the genuinely shared cross-bot keys, never the partner's private state) down to one row per data type. Oversized rows show in red with a ✕ to clear that bucket (confirmation-guarded), and Export downloads the breakdown as a text file.

Power usage (dropdown below Storage usage): a rolling average and peak of how many milliseconds the app spends reacting each second. A rising figure usually means a plugin panel left open somewhere is doing more work than it needs to — closing analytics panels you're not actively watching brings it back down.

Ticker Graylist: when MultiIndicator is enabled, the Stats menu shows a Ticker Graylist section listing symbols currently blocked from re-entry. It's empty when nothing is blocked. Each listed symbol clears itself automatically once the bulk ticker cooldown window elapses — no manual action needed.

Actions Dropdown

• Export — Downloads current bot state (config, positions, closed trades, ban list, EDa state) as a .json file. Plugins with their own data (Permafrost/Ashfall profile, scorecard) have separate Export buttons inside their own accordions — the Stats menu Export covers the base bot state only.
• Import — Restores state from a previously exported .json file. Config fields merge field-by-field; positions replace wholesale. A 5s debounce prevents accidental double-imports. Any config key that no longer belongs to a currently-loaded feature (the bot itself or an installed plugin) is dropped automatically on import and on every save — retired settings from an old config file don't linger indefinitely.
• Clear Closed Trades — Wipes the closed trades list, resets session stats, and clears the 6hr drawdown/gains-lock rolling PnL windows. Open positions are unaffected.
• Clear All — Full reset. All positions, trades, stats, and config are wiped (config reverts to defaults).

Activity Log

Timestamped entries for every significant bot event. Color coding:

• White — informational (scan results, entries, closes)
• Yellow — warnings (halts engaged, API retries)
• Red — errors (API failures, plugin conflicts)

Common prefixes: [MHL] manual halt · [DWN] drawdown throttle · [GLK] gains lock · [PST] (PseudoWinter) / [PERSIST] (PseudoChaser) save failures or recovered positions · [PFR]/[ASH] climate plugin events · [MIW]/[MIC] multi-indicator events.

The log is capped at 300 entries in memory and in localStorage. Oldest entries are dropped when the cap is exceeded. Each entry carries a local HH:MM:SS display string (t) plus an absolute epoch-ms timestamp (ts) — t is what's rendered in the UI, ts is there so a log export can be correlated precisely against position/config exports (which timestamp in UTC epoch); t alone can't be tied to a specific date or timezone.

Trades Menu

The trades panel shows a card for each closed trade, newest first. Each card carries a close-reason badge — TP, SL, FORCE (runtime limit), BAIL (drawdown throttle bail — closes every open position immediately, both bots), Sub (closed to free a slot for a higher-ranked candidate via MIW/MIC Substitution), or Eject (closed by MIW/MIC Ejection when two or more Deferment paths are active at once). Reasons introduced by other plugins show their own registered label, or the raw reason name if a plugin hasn't registered one. On EverWinter/SunChaser, a bail sweep is followed by a direct exchange re-check.

Roll-up card: when the closed trades list exceeds 50 entries, the oldest are compacted into a single roll-up card showing their net PnL, trade count, and the date range they cover. The roll-up is not a trade — it is a historical summary. In the PnL chart, the roll-up's net value acts as a baseline offset applied to every plotted point.

PnL chart: click the PNL CHART bar below the header to expand a cumulative PnL line chart. The X-axis spans from the first to the last individual closed trade at fixed spacing. The chart is green when the net result is positive, red when negative. The chart only appears once at least 2 individual trades are closed.

CLEAR button: removes all closed trades, resets session stats, and clears the 6hr drawdown/gains-lock rolling PnL windows. Clicking CLEAR reveals an inline confirmation ("Sure? Yes / No") before anything is deleted. Yes confirms; No cancels with no change.

MultiIndicator Plugin (MIW / MIC)

The Multi-Indicator plugin filters entries using configurable criteria combinations called slots. Each slot is an AND-gate: all criteria in the slot must be true for a ticker to qualify, and any single matching slot opens the ticker for entry. No criterion is mandatory; a slot (Auto or manual) qualifies on any combination of fund, va, ioa, ocs, ocx, lta and lpa. Entry is scan-driven only — one pass per fresh sample batch.

Criteria

See StrategyBook's Market Reading section for what each criterion means and when to use it. This section covers tiering, recording, and fetch mechanics only.

Slot builder badge key: the manual slot builder uses the same emoji set as position/trade badges.

Recording: every criterion is recorded as a signed tier on the position at entry.

Config

Slots UI

Manual mode: click a slot to select it, then toggle criteria on/off in the picker row below. ✕ deletes the slot; + adds a new empty one. All seven criteria are tiered — clicking one opens its gate picker (direction plus tier) rather than toggling a bare tag. A slot with no criteria in it never matches.

Auto mode: replaces the manual builder with a minimum-slider and an exclusion chip row. A ticker qualifies on at least the chosen minimum of non-excluded criteria — every criterion actually true is scored, not just enough to clear the floor. The hint under the slider states the current floor as "qualifies on any N of M secondary criteria."

The seven criteria are independent signed tiers, so any subset can be true for the same ticker at once and each contributes to the qualifying count on its own.

Permafrost / Ashfall Plugin

Permafrost targets PseudoWinter; Ashfall targets PseudoChaser. They provide two things: the Extremity Scorer / Lukewarm Scoring engine that decides which readings MIW/MIC may trade on, and the cross-bot bus that lets the two sides coordinate halts. The bots' own halt timers govern halts; the plugins only lift them (Mutual DDH Lift) or trigger them (Gains Continuation). The panel has two tabs, CROSS and SCORE, with the Danger Zone (Export / Import / Clear Profile / Clear Plugin State) below.

Config

Partner Feed

The Cross tab shows a scrollable Partner Feed listing the last 20 events the partner bot has broadcast: cascade/sacrifice triggers, DDH start/lift, gains-lock start/lift, and GC steps. Each row shows a kind-specific detail — position count and collective PnL for cascade/sacrifice, PnL and step number for GC, symbol for a rolling sacrifice — and a UTC timestamp, date-prefixed for anything not from today. Empty until the partner has broadcast at least one matching event.

Useful for diagnosing Mutual DDH Lift and GC: if the feed shows a partner ddh-start or gc step but no lift follows on this bot, the problem is on the receive side (freshness window, own-side toggle, read loop), not the trigger.

Sample Chart

Below the Score tab's scoreboard, a per-ticker bar chart of the OC cycle history, scrollable through past cycles. Two header buttons step through the views OC → Vol → IO → Fund → LTA → LPA (plus Liq while Liquidation Surveillance is on; each labelled with the view it goes to, wrapping at either end); the view resets to OC on reload. Only shown when Order Count Surveillance is on and at least one sample exists. Each cycle group is stamped with its sample time — click one to pin the summary and chips to that cycle, click elsewhere to return to the latest.

• OC: bar height is average seconds between orders (quieter = taller). Total shows buy/sell skew over every retained cycle plus the population average interval ocx measures against; Batch shows the displayed cycle. Chips show dominant side and interval — outline when faster than the batch mean, filled when skew leans to the bot's own side (buy on Chaser, sell on Winter). Tickers averaging over 12s/order are rare and completely flatten the chart, as such they are left off the chart but stay eligible for criteria and the chip list.
• Vol / IO: the 24h-turnover and open-interest samples, with a Total avg (the number va/ioa measure against, plus ticker count) above a Batch avg. No outlier cap.
• Fund: each sampled ticker's funding rate (%), signed, with a Total avg and Batch avg like Vol/IO. Funding rides in the sample records, read from each ticker's fresh fetch.
• LTA / LPA: signed views (turnover deviation %, 1h price change %) drawn up or down from a zero line on a symmetric axis sized to 1.3× the 95th percentile of |value|. Only tickers with a candle reading in a cycle appear.
• Liq: two bars per watched ticker that had liquidations in a period, up (green, bullish) for liquidated-short turnover and down (red, bearish) for liquidated-long turnover. It plots the watch's own history (last 25 periods, one per scan), not the sample cycles, so it is mostly empty. A bar above the readouts splits the window's turnover bearish (left) and bullish (right), with the side the bot favors (bullish on Chaser, bearish on Winter) striped, and shows stability (100% minus the turnover-weighted instability) in a colour band: red 0-33%, yellow 34-66%, green 67-100%. Window net is the net turnover over every retained period, split into ↑ and ↓, with Batch average (↑ and ↓ per ticker) beneath it. Chips show the dominant side's share; hover or tap for both shares and the turnover. A chip is outline-only when the minority side holds 30% or more.

Extremity Scorer

Each criterion is a dial family (fund, va, ioa, ocs, ocx, lta, lpa) with a + and a - pole. Every scan's readings build per-pole cutoffs that sort each reading as extreme or lukewarm, and closed trades are tallied per side and per pole. Whichever side has earned more dollars becomes the favored side (ties default to extreme), and the Lukewarm Veto rejects candidates whose criteria mostly sit on the other side. Scorecards are per bot — each reflects only its own trades. See Extremity Scorer Internals in Trivia.

Scorecard chart: only the favored side's chart is shown — Extreme or Lukewarm — and it flips automatically when the favored side changes. It is a single non-wrapping row of criterion duos that scales to its container: the left bar is the + pole, the right bar the - pole, profit rises above a zero line and loss hangs below it, and the criterion emoji sits underneath. The header shows the side's name and total; hover a bar for its PnL and W/L. Only shown when MIW/MIC (or Blind-Entry / Liquid-Diver) is loaded and enabled.

CLEAR wipes this bot's closed-record store, sample pool and Sample Scoring store together (__ew_pf_extremity_v1/__ew_pf_dialpool_v1/__ew_pf_sampleobs_v1, or the af set) — cutoffs included, never the partner's.

Under Sample Scoring the same chart is titled Sample Scorer, its bars are mean edge in pp, with liquidation outcomes blended in when Liquidation Surveillance is on (hover shows the average edge, ↑/↓ counts and n), and a status line above it shows the scored-sample count plus, with Delayed Pairing on, each snapshot awaiting its outcome with its estimated fetch time. With Liquidation Surveillance on it also shows the tickers on watch and how many are quiet (their latest watch had no liquidations).

Headline & gauge: the header number is relative. It is the favored side's favorable share of raw 1h move — move in the bot's favor as a share of all raw move on that side, so 50% is even — and a gauge under it is scaled to the best share recorded. Hover for the sample count, the mean in dollars on one base position and the relative edge. The per-criterion bars stay relative (mean edge vs the sampled population). Beneath the gauge, bottom and peak show the lowest and highest share recorded; they only update once the favored side has at least 10 raw samples (and at least Min Samples) and are cleared with the samples. The headline reads — until enough samples carry a raw move.

Randomized Outcomes

Scan timing drifts independently per tab, and the Order Count sample is a fresh random draw of Batch Size candidates each cycle, so two identically configured instances won't share entry triggers, exit timing, or readings. This is intentional: instances in lockstep are easier to front-run and cluster losses at the same market event.

Multiplex Plugins

To maximize efficiency within single-file browser execution, the system architecture supports Multiplex Plugins. Unlike standard plugins that independently isolate their telemetry, a multiplex variant hooks directly into the flattened component created when all plugins are loaded, using the structural pipelines—core data arrays—API batched payloads, and state tracking structures without wrapping or reassigning parent methods. This cross-dependencies model dramatically reduces resource consumption and mitigates multi-plugin race conditions by treating the master surveillance/execution engine as a shared database/resource.

The Speeder Module (Tentative Multiplex)

Located in /plugins/multiplex/, Speeder leverages existing functions in MultiIndicator and data provenience in Ashfall/Permafrost. This direct-read capability allows it to tap directly into the rolling Order Count (OC) Surveillance histories and entry criteria builder.

• What it does: Rather than assessing order flow via arbitrary millisecond barriers, Speeder dynamically splits the entire deduplicated pool of recent per-ticker trade intervals at the median during each scan.

• How it does what it does: To filter out noise, Speeder does not qualify a ticker simply for landing in the fast or slow half; the ticker's specific trade interval must exceed that collective half’s independent mean—ensuring an extreme, mathematical divergence from the baseline market velocity.

• When it does what it does: Adhering strictly to MultiIndicator's precedent, Speeder uses an automatic selection method for determining entry criteria (fast or slow), employing a base configuration dependent on the liquidation regime. Speeder can enter fast/slow tickers in hot or cold regimes.

• When it doesn't: If the foundational surveillance plugins are completely absent from the flattened component, Speeder logs a clean failure warning and remains safely inactive.

Note: The Speeder strategy is tentative and lacks long-term historical validation; it remains isolated within the multiplex directory for demonstration purposes and architectural testing.

Trivia

Developer-level detail with no operational consequence. Included for reference.

localStorage Keys

Criteria Sampling Internals

• Ticker Ranking: Each scan draws Batch Size tickers (default 50) at random and fetches their data fresh; that batch is the sample that feeds scoring (with Concentration on, queued movers take the first slots and the randoms fill the rest; tickers graylisted by Distillation are not in the pool). Entry candidates are ranked on every ticker's latest stored reading, however old, and each is refetched right before it opens, so any ticker the sample has reached can be picked. Refetches stop at one batch size per scan, since fetching all seven criteria across 600+ tickers every Scan cycle (10 minutes) would be both computationally and bandwidth intensive. See Criteria Sampling Internals in Trivia. Increasing the batch size is an option (if you have the resources).

• Tier gate: every criterion computes an integer tier as floor(value / step) and compares it against N (fund truncates toward zero instead, so a tiny negative rate lands on fund-0, mirroring fund+0, rather than flooring to fund-1). Current step sizes are shown as read-only chips under Tier Step Sizes on the Fetch tab. The same tier is recorded on the position and used as the scorecard key — fund>40 and fund+70 are different tiers and scored separately.

• Bare-form exception — fund: in Auto mode, a criterion named without a >/< comparison normally still requires a nonzero tier. fund's bare form matches on any finite funding rate instead, exactly 0% included, since real Bybit funding rates mostly sit well under a single Fund Step. A near-zero rate is a real lukewarm reading (fund+0/fund-0), so it attaches and feeds the lukewarm chart. The tiered forms are unaffected.

• Funding emoji: position/trade badges show 🤑 or 💸 for a fund tier, and the emoji encodes whether that funding sign favors the bot's own direction — so Winter and Chaser show opposite emoji for the same raw sign. The Extremity Scorer's own pills use one fixed set on both bots (💸 positive, 🤑 negative).

• ocs: signed deviation-from-parity tiers (ocs+12 = 62% buy-dominant). It is an accumulated read: fill counts are summed per ticker across every retained OC cycle (up to 25, fewer once the 200KB history cap bites — about 5 at 250 per batch), and a live single-ticker sample (_ocFetchSingle) folds in exactly once.

• ocx: ocx+12 = average inter-fill gap faster than the population average by 12 tiers (12 × step%, default 1%). Reads the ticker's latest interval: the current batch's if it was sampled, else its latest stored one.

• OC population average: _pfOcWindowAvgMs/_afOcWindowAvgMs flattens the retained cycles, keeps the latest reading per symbol, and averages.

• va / ioa: va+12 = 12 tiers hotter than the sampled population. _pfVolIoWindowAvg/_afVolIoWindowAvg delegates to _pfWindowStats/_afWindowStats, a deduplicated latest-reading-per-symbol read (vol, oi, lta or lpa) memoized per history state; the Sample Chart's Total avg draws from the same read. With no slot needing ocs/ocx, the trade fetch is skipped and only the per-ticker ticker fetch (vol/oi/fund) runs.

• fund: tier is trunc(rate% / Fund Step) with an explicit sign, so tiny negatives tag fund-0 and exact zero tags fund+0. Sample records carry the funding rate as fr (%) so the Fund chart and Sample Scoring can use it.

• lta: _pfLtaDev/_afLtaDev; lta+12 = 12 × LTA Step (default 10%) above the ticker's own average hour (turnover24h / 24). No population baseline.

• lpa: _pfLpaWindowAvg(sym)/_afLpaWindowAvg(sym), in tiers of LPA Step (default 0.25pp). Absolute points, since a relative deviation is unstable near a zero mean. No tier until at least one other ticker has an hc reading in the window.

• Candle fetch: _pfHourCandle/_afHourCandle calls GET /v5/market/kline at interval=60&limit=3 and takes the row whose start is the last completed hour (_pfHourStart); the forming candle is never used. Results sit in a memory-only per-symbol cache (HOUR_CACHE, pruned past 500). Each batch attaches ht and hc to the ticker's OC cycle entry, so a Follow Partner Bot instance gets them from the leader (_pfHourReading/_afHourReading). The fetch rides the same batch (wantHr on _ocFetchBatch) whenever lta or lpa is in use.

• Fresh batch fetch: _pfFetchFreshTicker/_afFetchFreshTicker calls GET /v5/market/tickers?category=linear&symbol= per batch symbol, keeps the raw payload for the scan (_pfFreshTicker/_afFreshTicker) and stores a compact { vol, oi, fr, px, ch } reading. A failed fetch drops the ticker; there is no fallback to the bulk list. A Follow Partner Bot instance rebuilds tickers from the leader's readings (_pfSynthTicker/_afSynthTicker). Entry candidates are refetched the same way by _pfFetchCandidate/_afFetchCandidate (ticker, plus OC and the hour candle when used), which touches neither the OC results nor the cycle history.

• Entry-pool freshness: MIW/MIC act once per new batch (_pfOcResultsAt/_afOcResultsAt), not once per bulk fetch. _miwOpen/_micOpen skip the pre-open price refetch for a ticker from the current batch (_pfTickerIsCurrent/_afTickerIsCurrent). Candidates are ranked on each ticker's latest stored reading (_pfLatestReadings/_afLatestReadings, rebuilt by _pfSynthStored/_afSynthStored with _cycle set to that reading's own cycle time, so only the latest batch counts as current). _miwVerify/_micVerify refetches each non-batch candidate before it opens or displaces a position, reruns the slot match and veto with the dial-pool sample off, and stops at Batch Size refetches per scan. A refetched ticker only has to still qualify, not keep its ranked tier or score.

• _miwHourTier/_micHourTier returns null for missing data: the criterion check reads it as false and the annotator as "no sample", never a fake +0.

• Emoji for retired criteria stay resolvable in critEmoji/afCritEmoji so old records and exports render; they are display-only.

Deferment & Ejection Internals

• Deferment signal: _miwWeatherNeg/_micWeatherNeg reads _pfSampleWeather/_afSampleWeather(side) on the favored side and defers while its dollar value is below zero, with no deadband, trim, or cooldown. It needs Sample Scoring and returns nothing until the scorecard has a headline.
• Deferment effect: the scan returns before every open path, with guards inside _miwTrySubstitute/_micTrySubstitute and _miwOpen/_micOpen. Historical scoring still runs. One ⛔ Deferment log line per streak.
• Ejection: runs every scan ahead of slot logic (so it acts with no active slots) when the deferment state's eject is set, which needs two or more paths in why. _miwEject/_micEject closes every non-pending position of any strategy, each in its own try/catch, with one ⏏️ Ejection log line naming the paths and close reason ejection. Each trade is scored against its opening criteria.

Target Halving & Scorecard Deferment Internals

• Targets: _miwTargets/_micTargets resolves the factor from _pfSampleWeather/_afSampleWeather(side) on the favored side. It returns the configured values untouched (active:false) when Target Halving is off, neither Cascade nor Sacrifice is on, Sample Scoring is off, or there's no headline share (wx.s) or recorded share peak (wx.sHi). The factor is clamp(wx.s / wx.sHi, 0, 1), zero when the peak is at or below zero. _miwEffCascadePct/_micEffCascadePct and _miwEffSacrificePct/_micEffSacrificePct return the resolved % floored at Min Entry TP and 1%; _miwTargetsText/_micTargetsText feed the Exit-tab readout.
• Per-position overrides: _miwOpen/_micOpen pass _tpPct and _slPct on the candidate. PseudoWinter/PseudoChaser use _tpPct for the entry TP, and _slPct for the binary-mode SL at open. It is also stored as pos._slPctOverride, which the DCA-mode SL arm, the SL drift check and the position card honor. Both candidate fields are excluded from the copy of candidate fields onto the position.
• Deferment layering: _miwDefermentState/_micDefermentState wraps …DefermentStateBase. The wrapper evaluates the negative-headline test (on with Deferment), Both Poles Red and the base on their own and merges them, with why listing those that hold and eject set when there are two or more. The base holds only the Target Halving floor test. _miwWeatherNeg/_micWeatherNeg and _miwBothPolesRed/_micBothPolesRed are the two clause tests; the latter reads the favored side of pfLukewarmScoreboard/afLukewarmScoreboard.
• Headline source: _pfSampleBuild/_afSampleBuild accumulates the raw edge per bucket into pfSampleBucketMeans/afSampleBucketMeans (aE/aL, counts nAE/nAL) and the signed favorable share (P−Q)/(P+Q) of those raw moves (sE/sL). _pfSampleWeather/_afSampleWeather returns the dollar value, the share (s, and share as 0–1) and the peak/bottom of each (hi/lo, sHi/sLo), which _pfSampleTrackWx/_afSampleTrackWx keeps in the sample store as wx and the leader shares with followers.

Extremity Scorer Internals

• Cutoffs: come from the sample pool (pfDialSamplePool/afDialSamplePool), fed by _pfDialSample/_afDialSample on every criterion annotation, not only trades, and persisted across reloads. A pole with at least Min Samples readings cuts off at its Extreme Split percentile; a reading at or above it is extreme, anything below it and everything on an unproven pole is lukewarm. Bare sign-only tags from Blind-Entry/Liquid-Diver (+fund/-fund/+ocs/-ocs) carry no magnitude and always classify extreme.
• Two tallies: the dial tally counts extreme occurrences only and is the flat micCollapsedSlotRanks/micCollapsedCritStats lookup that Co-Qualifying Penalty and entry ordering read. The Lukewarm Scoring tally counts every occurrence, bucketed by class then by pole (fund+/fund-, not merged by family, since a family's poles are opposite signals).
• Favored side: _pfLukewarmFavoredSide/_afLukewarmFavoredSide, re-decided each time the scorer rebuilds (once per scan cycle).
• Veto: _pfExtremityVeto/_afExtremityVeto counts the share of a candidate's dial-eligible criteria on the non-favored side and vetoes at Lukewarm Veto%. An unproven dial counts against the candidate. It checks every entry.
• Pole Blocking: _miwPoleBlocked/_micPoleBlocked, called from _miwIsEntryBlocked/_micIsEntryBlocked after the Lukewarm Veto, so it covers both the entry-pool filter and the post-top-up re-check. Reads the favored side of pfLukewarmScoreboard/afLukewarmScoreboard; inert without Sample Scoring.
• Position Rolling Average: when on, _pfPositionCriteriaSample/_afPositionCriteriaSample re-reads each open position's locked criteria families every scan and keeps a rolling 24h average per family, using a fresh single-ticker fetch, a fresh OC sample for ocs/ocx, and the cached 1h candle for lta/lpa. These fetches are exempt from Leader/Follower's no-own-fetch rule, like Force-Evaluate's. _pfPositionAvgCriteria/_afPositionAvgCriteria rebuilds the tag from the average, falling back to the frozen entry tag (_miwCriteria/_micCriteria, or the Blind-Entry/Liquid-Diver equivalents) for any family under Min Samples readings. That average is what close-time scoring, Extremity Re-Evaluation and Substitution's live score read. Off: no fetch, frozen tags only. The cutoff sample pool is unaffected.
• Sample Scoring: when on, _pfExtremityBuild/_afExtremityBuild returns _pfSampleBuild/_afSampleBuild instead of walking closed records. It publishes the same outputs (cutoffs, micCollapsedSlotRanks/miwCollapsedSlotRanks, the two-bucket scoreboard) from __ew_*_sampleobs_v1, plus per-bucket mean edge (pfSampleBucketMeans/afSampleBucketMeans) for the favored side. Delayed snapshots resolve from runScan via _pfSampleResolvePending/_afSampleResolvePending, one 1m-kline request per ticker, skipped while following. Its 60 candles give each record's close, high and low move (f/fh/fl); a pending record saved before the split refetches if still inside its window, and an expired one keeps close only. The leader publishes sampleScore on the shared registry and a follower adopts it each scan (_pfSampleAdopt/_afSampleAdopt).
• Concentration: _pfConcQueue/_afConcQueue runs as a Delayed snapshot resolves and writes req (symbol → move size, time; entries expire after 3h, and a ticker leaves req once it is sampled again). _pfConcPick/_afConcPick is called from _miwScanFetch/_micScanFetch after the batch shuffle, returns queued symbols still in the pool (biggest first, capped by ConcMaxPct, none sampled within the last hour), and they are moved to the front of the batch. Favorable means the hour's move (the close, or with ConcHL the midpoint of its high and low moves) went the way _pfSampleDir/_afSampleDir wants (-1 for Winter, +1 for Chaser). Does nothing when Sample Scoring or Delayed Pairing is off; MIW/MIC skip the call if the plugin predates it.
• Distillation: _pfDistQueue/_afDistQueue runs as a Delayed snapshot resolves (after Concentration) and writes gray (symbol → graylist time) in the sample store, dropping the symbol from req; entries older than DistMins are pruned. _pfGrayHas/_afGrayHas(sym) is checked in _miwScanFetch/_micScanFetch when the base pool is built (counted as excluded.gray), so the ticker is neither sampled nor ranked for entry. Unfavorable means the move (close, or with DistHL the high/low midpoint, signed by _pfSampleDir/_afSampleDir) is below 0, or below the batch mean with DistPastMean. Does nothing when Sample Scoring or Delayed Pairing is off; MIW/MIC skip the call if the plugin predates it.
• Thin poles: a pole under Min Samples scores 0 and counts as lukewarm; at Min Samples its score becomes the plain mean of those readings with no shrinkage, so a rare pole (e.g. fund-) jumps from neutral to full weight on a handful of readings. Entry ordering discounts thin poles separately (see Sparsity).
• Liquidation Surveillance: _pfLiqStep/_afLiqStep runs once per scan from _pfScanPost/_afScanPost on the scheduler's idle lane. The feed is allLiquidation.<symbol> on the public linear WebSocket, kept at module level (LIQ_TALLY: per symbol up/down turnover and event count since its last snapshot); S:'Buy' means a long was liquidated. Subscriptions go 10 per request with a 20 s ping and 5 s reconnect, like the host's feed. Candidates are ordered by _pfLiqOrder/_afLiqOrder: a percentile rank per family from _pfLiqSpeed/_afLiqSpeed (OCX, shortest order interval), and |hc| and ht from _pfLiqHour/_afLiqHour (newest reading from the OC history or the watch's own fetches), weighted by _pfLiqWeights/_afLiqWeights (a family's weight is the mean of its two poles' scores on the favored side, equal with none; a missing reading counts -1 against its weight's size); a ticker found quiet, or fetched with no tags, is skipped for that refill. lquiet is cleared for a ticker when a later watch has liquidations, and lgray is written with LiqGray and by the instability graylist. A ticker watched for under 60% of a Scan Interval gets no verdict yet. Each scored period writes a k:'l' observation with the join-time criteria tags. _pfSampleBuild/_afSampleBuild re-uses the price-built cutoffs for liquidation observations, scales the pole's turnover-weighted share by the mean absolute price pole score (0.25 if none is proven), and averages: (nP·price + w·nL·liq) / (nP + w·nL), with nP the pole's price count (0 while under Min Samples) and w the liquidation weight. A pole under Min Samples across both kinds is left at 0. _pfInstabMap/_afInstabMap pools each ticker's lu/ld/ev over the history periods into i = 2·min(u,d)/(u+d) · ev/(ev+3); _pfInstabAdj/_afInstabAdj subtracts |score| · INSTAB_DRAG (0.5) · i, and MIC/MIW apply it to each candidate's composite and richness. _pfInstabGray/_afInstabGray runs after each period's history push: a ticker in that period's rows with i at or above 1.3× the mean i of all tickers (and not already in lgray) is written to gray and lgray and dropped from the watch, only with LiqEnabled, DistEnabled, DistInstab, Sample Scoring and Delayed Pairing on. The watch and LIQ_TALLY persist to __af_liq_pending/__pf_liq_pending (3 s throttle, plus step end and page hide); the first step restores them and scores them with no minimum age.
• Sparsity: _pfPoleData/_afPoleData returns the sample count behind the bucket a tier tag lands in (Extreme or Lukewarm, by the pole's cutoff) and the median count across that bucket type's poles, read from the scoreboard (so liquidation samples count). _pfSparse/_afSparse turns a candidate's tags into a factor (thinnest pole's n / (n + Min Samples)) and a block flag (thinnest pole under the floor % of the median). MIW/MIC apply the per-pole factor in _miwScaledRank/_micScaledRank, multiply the Co-Qual-off richness sort by the candidate's factor, and check the block flag in _miwIsEntryBlocked/_micIsEntryBlocked, so it covers the entry-pool filter and the post-top-up re-check. Inert until a scoreboard exists.
• Win/loss counts can appear high: a criterion shared across many slots accumulates records from all of them, and the Sponge Quota caps per criterion, not per slot.

Cross-Tab Data Pool

Both bots share market data via localStorage.__ew_shared_v1 and BroadcastChannel('ew_shared'). Writes are last-write-wins per data type. Either bot operates normally solo — the registry is simply absent and all ladder checks fall through to normal fetches.

Each bot publishes its own open-symbol list to this registry on every position open/close, and resynced once more per heartbeat as a safety net for close paths that bypass pseudoClosePosition (e.g. the gap-fill audit). A following bot (lfFollowPartner on, partner heartbeat fresh) checks the leader's published list before opening and skips any ticker the leader already holds; the leader itself never checks its own publish. Because the check is gated on _lfIsFollowing(), it disables itself automatically the instant the leader's heartbeat goes stale — no separate expiry logic on the position data itself.

Not every BroadcastChannel('ew_shared') message carries a localStorage.__ew_shared_v1 write behind it, though most do (_sharedWrite/_sharedMerge post a change notification after writing). registerSharedMessageHook is the general subscription point either kind of push is dispatched through on the receiving end.

Scan Scheduler Internals

• Stages: runScan calls _scanPipeline(ctx), which runs the host's tickers stage, then each plugin stage in load order (pf-post/af-post, then miw-/mic- prep, fetch, pool, entry). Stages share ctx; a plugin appends { id, group, run } to _scanStageDefs in transform, and a stage returning false skips the rest of its group. On a host without _scanStageDefs the plugin falls back to wrapping runScan.
• Checkpoints: loops call if (this._scanDue()) await this._scanCp(), which yields once schedSliceMs has elapsed (40 ms while the tab is hidden). The yield is a MessageChannel task rather than setTimeout, because a hidden tab clamps timers to 1 s or more.
• Idle lane: _schIdle(key, fn) queues one coalesced job per key (extremity rebuild, re-eval, sample-store saves), flushed when the pipeline ends; _schIdleCancel(key) drops it, which MIW/MIC's own rebuild uses to supersede Permafrost/Ashfall's.
• Timing: each scan logs one [SCH] line with total ms, yields, long-task count and per-stage ms. ui.scanning stays on through the plugin stages, so a batch that outlasts the scan interval makes the next scan skip. The extremity rebuild itself is still one synchronous call.
• Every background/bulk fetch — bulk tickers, market watch, and any loaded plugin's kline/OC batches — runs through a single per-bot scheduling queue (Scan Scheduling in Main Config) instead of firing all at once, which is what keeps the browser responsive with one bot open and workable with two. Execution-critical single-symbol calls (opening/closing/watching a position) bypass the queue entirely so order execution is never delayed behind background scanning. The scan itself is a pipeline of named stages that hands control back to the browser after each time slice (Slice Budget), so position watching, clicks and timers run mid-scan instead of waiting for it to finish.
• Running both bots: When both are open simultaneously they automatically share bulk ticker fetches, kline caches, and Order Count samples to halve API load. Either bot works normally on its own when the other tab isn't open.

Plugin Transform Pipeline

pw()  →  plugin[0].transform(def)  →  plugin[1].transform(def)  →  ...  →  Alpine

Each plugin's transform(def) receives and returns the component definition. Load order matters for method wrapping — strategy plugins must declare after: ['everwinter'] / after: ['sunchaser'] so live-trading plugin wraps are innermost.

Load order matters: live trading plugins (EverWinter, SunChaser) must load before strategy plugins (MultiIndicator, Permafrost/Ashfall). The Plugin Manager shows the current load order and warns about conflicts.

Bybit API Endpoints Used

Public: GET /v5/market/tickers (bulk for the symbol universe, per symbol for criteria data), GET /v5/market/recent-trade, GET /v5/market/kline, GET /v5/market/instruments-info. WebSocket: wss://stream.bybit.com/v5/public/linear (position price stream). Signed (live plugins only): GET /v5/account/wallet-balance, GET /v5/position/list, POST /v5/order/create, POST /v5/position/trading-stop, POST /v5/order/cancel. Signing: HMAC-SHA-256 via crypto.subtle.sign; 250ms minimum gap between signed requests.