dexbot 1.6.4 → 1.6.6

package/docs/README.md

@@ -2,7 +2,7 @@
 
 This directory contains the comprehensive technical documentation for the DEXBot2 trading bot. It is designed to guide developers from high-level architecture down to the nuances of fund accounting and state management.
 
-**Version context:** v1.6.4 (released).
+**Version context:** v1.6.6 (released).
 
 ---
 
@@ -17,7 +17,7 @@ This directory contains the comprehensive technical documentation for the DEXBot
 
 ### 📡 [Market Adapter](../market_adapter/README.md)
 *Live AMA pricing, dynamic weights, and recalc trigger orchestration.*
-- **Quick Start**: Enable AMA, generate the whitelist, and start DEXBot2
+- **Quick Start**: Enable AMA, set the per-bot adapter flags in `dexbot bot`, and start DEXBot2
 - **Settings**: Global, pair, and bot-specific adapter overrides
 - **Dynamic Weights**: How adapter signals write live weight snapshots
 - **Troubleshooting**: Common adapter startup and trigger issues
@@ -32,7 +32,7 @@ This directory contains the comprehensive technical documentation for the DEXBot
 
 ### 📈 [Analysis](../analysis/README.md)
 *Research runners, chart generators, and tuning helpers.*
-- **Trend Detection**: SMA, MACD, RSI, Hurst, Kalman, and regime analysis tools
+- **Trend Detection**: Hurst, Kalman, and regime analysis tools
 - **AMA Fitting**: Parameter fitting, comparison charts, and LP data workflows
 - **Bot Fitting**: Grid parameter sweep backtests for AMA winners
 - **TradingView Exports**: Chart export utilities for visual analysis
@@ -44,7 +44,7 @@ This directory contains the comprehensive technical documentation for the DEXBot
 - **Purpose**: Exposes BitShares capabilities and DEXBot2 infrastructure through JSON/CLI bridges, MCP, and runtime-native skill packaging for OpenClaw and compatible runtimes (see [claw/README.md](../claw/README.md) for the full list).
 - **API Boundary**: Responsibility split between the AI decision layer and the DEXBot2 execution substrate ([AI_BOT_LIBRARY_API.md](../claw/docs/AI_BOT_LIBRARY_API.md))
 - **Tuning Reference**: Practical grid-tuning baselines ([DEXBOT2_TUNING_CHEAT_SHEET.md](../claw/docs/DEXBOT2_TUNING_CHEAT_SHEET.md))
-- **Position Management**: Health monitoring, margin planner, and dynamic weight policy
+- **Position Management**: Short-position tracking, position health monitoring (3-zone CR model), and shared CR planning via `cr_planner.ts`
 - **Skills**: Presentation-only, concept-reference, and launcher-orchestration skill packs for bitshares-guide, margin-trading, launcher-ops, and shared references
 
 ## Operational & Security
@@ -65,19 +65,19 @@ This directory contains the comprehensive technical documentation for the DEXBot
 ### 🔁 [Grid Reconciliation](GRID_RECONCILE.md)
 *How the bot re-aligns its intended grid with on-chain reality at startup.*
 - **3-Phase Plan-then-Execute**: Phase 1 pure in-memory planning under `_gridLock`, Phase 2 blockchain execution outside the lock, Phase 3 fresh re-read and stale surplus cleanup
-- **Safety Guardrails**: Fresh-grid `matchedOnGrid > 0` guard, 5× duplicate tolerance, freshly-assigned deferral, and truncated-read ambiguity handling
+- **Safety Guardrails**: Fresh-grid `matchedOnGrid > 0` guard, exact slot-price duplicate cancel, freshly-assigned deferral, and truncated-read ambiguity handling
 - **Partial Failure State**: No rollback on partial Phase 2 success; remaining mismatches caught by the next maintenance or startup cycle
 - **Lock Hierarchy**: Canonical `_syncLock`/`_gridLock` level reference and the 1.4.6 ABBA deadlock correction
 
 ### 📝 [Logging System](LOGGING.md)
 *Configuration reference for log levels, rotation, JSON output, and categories.*
 - **5 Severity Levels**: `debug`, `info`, `warn`, `error`, `critical`.
-- **Rotation**: Size-based (1GB default), auto-prune (5 files).
+- **Rotation**: Size-based (1.1GB total budget default), auto-prune (10 rotated files).
 - **JSON Output**: Structured lines for log aggregators (opt-in).
 - **Categories**: 6 independently enablable category groups.
 - **Change Detection**: Skips redundant logs (40-50% reduction).
 - **Batch Processing Logs**: Fill batching, recovery retry, and orphan-fill deduplication messages.
-- **Fill History Scans**: The `Subscriptions` logger emits `fetchFillHistoryEntries: maxPages (X) reached` at `info` level when the history scan hits its page cap — normal on busy accounts; see LOGGING.md for the `--partial-operations` diagnostic.
+- **Fill History Scans**: The `Subscriptions` logger emits `fetchFillHistoryEntries: maxPages (X) reached` at `debug` level when the history scan hits its page cap — normal on busy accounts; see LOGGING.md for the `--partial-operations` diagnostic.
 
 ### 🐳 [Docker](docker.md)
 *Container build, release images, and secure startup.*
@@ -88,8 +88,8 @@ This directory contains the comprehensive technical documentation for the DEXBot
 ### 🛠️ [Scripts](../scripts/README.md)
 *CLI maintenance and diagnostic utilities.*
 - **Update**: Safe production update via `dexbot update`
-- **Reset & Cleanup**: Log wiping, setting resets, PM2 ecosystem regeneration
-- **Analysis Helpers**: Diagnostic connection tests and health probes
+- **Reset & Cleanup**: Log/order wipes, settings resets, and market-adapter/claw state cleanup
+- **Diagnostics**: Configuration audit, grid divergence/trading analysis, and candle/pool history checks
 
 ## Reference Docs
 
@@ -97,9 +97,9 @@ This directory contains the comprehensive technical documentation for the DEXBot
 *The blueprint of the system.*
 - **Design Philosophy**: Simplicity, constant spread, minimal blockchain interaction, and closed-loop market dynamics.
 - **System Design**: High-level overview of how the bot components interact.
-- **Module Responsibilities**: Detailed breakdown of the **Manager**, **Accountant**, **Strategy**, **Grid**, **FillRuntime**, and **MaintenanceRuntime** modules.
+- **Module Responsibilities**: Detailed breakdown of the **Manager**, **Accountant**, **Strategy**, **SyncEngine**, **Grid**, **FillRuntime**, and **MaintenanceRuntime** modules.
 - **Copy-on-Write Pattern**: Safe concurrent rebalancing with isolated working grids (see [COPY_ON_WRITE_MASTER_PLAN.md](COPY_ON_WRITE_MASTER_PLAN.md))
-- **Fill Processing Pipeline**: Fixed-cap batch fill processing (1-4 fills per broadcast; documented Feb 7 29-fill scenario: ~24s)
+- **Fill Processing Pipeline**: Fixed-cap batch fill processing (`gapSlots+1` fills per broadcast; documented Feb 7 29-fill scenario: ~24s)
 - **Spread Correction**: Conservative, fund-aware maintenance of constant spread width
 - **Periodic Market Price Refresh**: Background 4-hour price updates
 - **Pipeline Safety & Diagnostics**: 5-minute timeout safeguard and health monitoring
@@ -119,14 +119,14 @@ This directory contains the comprehensive technical documentation for the DEXBot
 ### 🧩 [Copy-on-Write Master Plan](COPY_ON_WRITE_MASTER_PLAN.md)
 *COW design, phases, and state machine details.*
 - **Architecture**: Master-grid projection model and rebalance flow
-- **Lifecycle**: Implementation phases, commit boundaries, and test coverage
+- **Lifecycle**: State machine, rebalance/fill data flows, fill handling strategy, and operational rules
 - **Safety**: Invariants and guardrails for concurrent updates
 
 ### 🔒 [COW Invariants](COW_INVARIANTS.md)
 *Stable theory contract for COW pipeline.*
 - **Non-negotiable invariants**: Master immutability, commit atomicity, projection rules, accounting separation
-- **Test mapping**: Links each invariant to regression tests
-- **Review checklist**: Quick-use verification for COW/accounting changes
+- **Subsystem Scope**: 13 `INV-*` prefix groups mapping each invariant to its runtime subsystem
+- **Change Policy**: Required steps for an intentional invariant change — same-PR doc update, rationale, and regression tests
 
 ### 📐 [Grid-Price Invariant](GRID_PRICE_INVARIANT.md)
 *Why a slot's emitted price must equal its genesis level — and how that failed.*
@@ -140,7 +140,7 @@ This directory contains the comprehensive technical documentation for the DEXBot
 *The most critical part of the bot: safe capital management.*
 - **Single Source of Truth**: How the bot avoids double-spending and out-of-sync balances.
 - **Optimistic ChainFree**: The mechanism that allows the bot to trade with fill proceeds before they are finalized on-chain.
-- **Fill Batch Processing**: Fixed-cap batching for efficient fill processing (`<=4` unified, `>4` chunked)
+- **Fill Batch Processing**: Fixed-cap batching for efficient fill processing (`1..gapSlots+1` unified, deeper queues chunked at `gapSlots+1`)
 - **Partial Order Consolidation**: Simplified, direct consolidation through grid rebuilding (no merge/split mechanics)
 - **Dust Detection & Management**: Partials below the dust threshold are cancelled on-chain immediately on detection (no delay, no timer)
 - **BTS Fee Object Structure**: `netProceeds` field for accounting precision
@@ -158,9 +158,9 @@ This directory contains the comprehensive technical documentation for the DEXBot
 - **Configurable startPrice & gridPrice**: Fixed numeric, pool, book-derived, or AMA keyword pricing modes
 - **Pool ID Caching**: Optimization for price derivation
 - **Order State Helper Functions**: Centralized predicate functions for state checking
-- **Signal Concepts**: Dynamic weights, regime detection, derivative signals, and market adapter integration
+- **Signal Concepts**: Dynamic weights, regime detection, and market adapter integration
 - **Debt Policy**: Native MPA and credit offer configuration and runtime rules
-- **Common Tasks**: Practical "how-to" guides for adding features or fixing bugs.
+- **Practical How-Tos**: Adding features step by step, common pitfalls to avoid, and useful debugging commands.
 - **Glossary**: Definitions of project-specific terminology (e.g., "Virtual Orders", "Rotation", "Pipeline Safety", "WorkingGrid", "COW Commit", "Dynamic Weight", "Regime Detection").
 
 ### 🔄 [Workflow](WORKFLOW.md)
@@ -172,7 +172,7 @@ This directory contains the comprehensive technical documentation for the DEXBot
 *Test organization, categories, and key architectural patterns tested.*
 - **Test Layout**: Directory structure, helpers, and quick-start commands
 - **Categories**: Core infrastructure, order management, COW rebalancing, fees/accounting, integration, edge cases, and more
-- **Architectural Patterns**: COW rebalancing, RMS divergence, and fund invariants with doc cross-references
+- **Architectural Patterns**: COW rebalancing, RMS divergence, fund invariants, and the grid-price invariant with doc cross-references
 
 ### 🧭 [Evolution Report](EVOLUTION.md)
 *Project timeline and major architecture phases.*

package/docs/WORKFLOW.md

@@ -238,28 +238,33 @@ the canonical name is preferred in scripts and docs.
 
 | Command (canonical) | Aliases | Purpose |
 |---------|---------|---------|
-| `dexbot test <bot>` | — | Test-run a single bot (one-shot, live trading) |
+| `dexbot test <bot>` | — | Run a single bot in live mode (one-shot; not a dry run) |
 | `dexbot drystart <bot>` | — | Same as `test` but forces dry-run execution |
-| `dexbot reset <bot>` | — | Trigger a grid reset (applies live or on next start) |
+| `dexbot reset <bot>` | — | Trigger a grid reset (applies live or on next start; `reset all` for all) |
 | `dexbot default` | `defaults` | Reset settings to defaults (deletes generated settings files) |
 | `dexbot disable <bot>` | — | Mark a bot inactive in config (`disable all` for all) |
 | `dexbot enable <bot>` | — | Mark a bot active in config (`enable all` for all) |
-| `dexbot key` | `key` | Launch the chain key helper (`modules/chain_keys.ts`) |
-| `dexbot bot` | `bot` | Launch the interactive bot configurator |
+| `dexbot key` | `keys` | Launch the chain key helper (`modules/chain_keys.ts`) |
+| `dexbot bot` | `bots` | Launch the interactive bot configurator |
 | `dexbot pm2` | — | Start all active bots via PM2 |
 | `dexbot update` | — | Update DEXBot2 from the repository and restart active bots |
 | `dexbot export <bot>` | — | Export bot trades/settings to CSV/JSON for local analysis/ |
-| `dexbot order` | `orders` | Analyze persisted order grids (spread, increment, funds) |
+| `dexbot order` | `orders` | Analyze persisted order grids (spread, increment, funds); `--export` for HTML |
 | `dexbot order [<bot>]` | — | Analyze only the specified bot's order grid |
 | `dexbot credit` | — | Live summed MPA + borrowed-credit positions per asset per bot (`[<bot>]`) |
-| `dexbot status` | `stat` | Unified runtime health — daemon, adapter, bots |
+| `dexbot tv <target>` | — | TradingView 1h chart for `<bot|pool-id|AssetA/AssetB>` over `--month N` (default 3) |
+| `dexbot dw <target>` | — | Dynamic-weight research chart: same targets/flags as `tv` |
+| `dexbot status` | `stat`, `stats` | Unified runtime health — daemon, adapter, bots |
 | `dexbot start` | `unlock` | Run credential daemon + bot (equivalent to running the `unlock` runtime, `dist/unlock.js`) |
-| `dexbot stop` / `dexbot start` | `stp`, `stopall` | Stop/start the monolithic runtime (unlock mode) |
+| `dexbot stop` | `stp`, `stopall` | Stop the monolithic runtime (unlock mode) |
 | `dexbot reload` | `reloadall` | Reload the monolithic runtime without touching the credential daemon (unlock mode) |
 | `dexbot restart` | `restartall` | Restart the monolithic runtime (unlock mode, re-unlocks credential daemon) |
 | `dexbot delete` | — | Shut down and clean up the monolithic runtime (unlock mode) |
-| `dexbot whitelist` | `white` | Generate market adapter whitelist from AMA bot configs |
 | `dexbot clear` | — | Remove all log files from the logs directory (`<profiles>/logs`) |
+| `dexbot clear-orders` | — | Remove all persisted order files (`<profiles>/orders`) |
+| `dexbot clear-market-adapter` | — | Remove market adapter data, state, and logs |
+| `dexbot clear-all` | — | Remove orders, logs, market adapter, and claw files (all of the above) |
+| `dexbot help` | — | Print the full CLI reference (grouped by Runtime/Trading/Config/Analysis/Files) |
 
 ## NPM Scripts for Branch Synchronization
 

package/docs/architecture.md

@@ -22,7 +22,7 @@ DEXBot2 is a grid trading bot for the BitShares blockchain. It maintains a geome
 DEXBot2 prioritizes **simplicity and operational efficiency** over complex partial-handling mechanics:
 
 1. **Constant Spread**: The spread zone width remains fixed at `targetSpreadPercent`, eliminating dynamic inflation triggers.
-2. **Direct Consolidation**: Dust partials are absorbed into the next grid rebuild cycle, not handled by complex merge/split logic.
+2. **Immediate Dust Cancellation**: Sub-threshold partials are cancelled on-chain as soon as detection runs; surviving non-dust partials are handled by ordinary fund-driven rebalancing without complex merge/split logic.
 3. **Minimal Blockchain Interaction**: Fund-driven rebalancing occurs once per fill batch, not per-partial. Grid generation uses only available funds—no forced allocations.
 4. **Closed-Loop Market Dynamics**: The boundary-crawl mechanism naturally handles price movement and fill flows without special-case logic.
 5. **Powerful Maintenance Tools**: Periodic grid regeneration, recovery retries, and fund invariant verification keep the system healthy over long operations.
@@ -56,10 +56,10 @@ graph TB
         MASTERGRID[Master Grid - immutable/frozen<br/>slot-id, price, size, state<br/>orderId, blockchain, grid, proceeds]
         TWOPASS[SyncEngine<br/>2-pass: grid-to-chain then chain-to-grid<br/>match orderId, detect partials, flag stale]
         FUNDS["Accounting - SSOT for funds<br/>available, virtual, committed<br/>btsFeesOwed<br/>Avail = max 0 ChainFree minus Virtual minus Fees"]
-        TARGET[Strategy Engine<br/>calculateTargetGrid<br/>boundary-crawl pivot<br/>partial-fill consolidation, rotation]
+        TARGET[Strategy Engine<br/>calculateTargetGrid<br/>boundary-crawl pivot<br/>partial correction, rotation]
         WORKGRID[WorkingGrid - COW copy<br/>all mutations here only<br/>commit to Master on confirmation]
         FILLQUEUE[Fill Queue<br/>AsyncLock + dedup 5-60 min]
-        BATCHER[Fixed-Cap Batcher<br/>queue within cap: unified batch<br/>queue above cap: chunk at cap size<br/>default cap: 4]
+        BATCHER[Fixed-Cap Batcher<br/>queue within cap: unified batch<br/>queue above cap: chunk at cap size<br/>cap = gapSlots + 1]
     end
 
     subgraph "OUTPUTS"
@@ -107,7 +107,7 @@ graph TB
 | **Immutability** | Master Grid is frozen; all changes go through a disposable WorkingGrid (Copy-on-Write) |
 | **Single Source of Truth** | Accounting engine owns all fund data; everything reads from it |
 | **Event-driven + Polling** | Fill Events (real-time) and Open-Order polling feed the same queue |
-| **Fixed-Cap Batching** | Deterministic batching with hard cap per broadcast (default 4 fills) |
+| **Fixed-Cap Batching** | Deterministic batching with hard cap per broadcast (cap = gapSlots + 1 fills) |
 | **Persistence** | Grid snapshot written after every confirmed blockchain commit |
 
 ---
@@ -443,7 +443,7 @@ The fill pipeline handles incoming filled orders efficiently through fixed-cap b
 
 Scenario source: 29-fill burst during the Feb 7 market crash, modeled at
 roughly 3 seconds per broadcast; see
-[`FUND_MOVEMENT_AND_ACCOUNTING.md`](FUND_MOVEMENT_AND_ACCOUNTING.md#14-fill-batch-processing--cache-fund-timeline).
+[`FUND_MOVEMENT_AND_ACCOUNTING.md`](FUND_MOVEMENT_AND_ACCOUNTING.md#15-fill-batch-processing--timeline).
 
 | Metric | Legacy (1-at-a-time) | Fixed-Cap Batching | Improvement |
 |--------|---------------------|-------------------|-------------|
@@ -464,46 +464,53 @@ Instead of complex partial handling, spread corrections are **conservative and f
 - Target spread width stays **constant** at `targetSpreadPercent`
 - Corrections scale with **actual available funds**, not arbitrary slot budgets
 - No dynamic spread inflation based on partial consolidation flags
-- Edge-first surplus selection ensures stable rotation candidates
+- Safe window-contiguous candidate ordering (with an edge-first fallback) prevents cross-side placement
 
 ### Algorithm
 
-**Location**: `modules/order/strategy.ts::calculateTargetGrid()`
+**Location**: `modules/order/grid.ts::prepareSpreadCorrectionOrders()`, selected by
+`modules/order/grid.ts::determineOrderSideByFunds()`.
 
-The simplified approach prioritizes fund availability over aggressive corrections:
+The correction path is fund-only and never manufactures budget by shrinking a resting order:
 
 ```
-1. Detect that spread is wider than targetSpreadPercent
-2. Calculate how many edge slots are missing
-3. Attempt to place new edge orders with available funds
-4. If insufficient funds for all edges:
-   - Create what's affordable with available funds
-   - Log shortfall (smooth over next rebalance cycle)
-5. If a dust partial exists in the correction window:
-   - Mark for consolidation in next grid rebuild
-   - Don't create complex merge/split side effects
-6. Maintain constant target spread—no inflation based on partial flags
+1. Detect that the live window is wider than targetSpreadPercent.
+2. Select up to `outOfSpread` eligible holes in safe window/gap order.
+3. If the funded edge holds a non-dust PARTIAL, optionally top it up, but only
+   when `ideal - current` is positive and free funds can cover the increase.
+4. Create replacements from free available/chainFree funds; contiguous gap-slot
+   promotion may extend the window while preserving MIN_SPREAD_ORDERS and the
+   opposite placed rail.
+5. If free funds cannot cover every target, place/top up the affordable prefix,
+   stop without shrinking inventory, and log the fund-constrained remainder.
+6. If neither side has free funds, skip correction and let the maintenance
+   runtime refresh balances and open orders rather than recycle stale inventory.
 ```
 
+Detected dust partials never enter this path: `cancelDustOrders()` cancels them
+on-chain immediately, and the five-minute health check is only a restart safety net.
+
 ### Fund-Safe Constraints
 
 Spread corrections respect these hard limits:
 
 ```javascript
 // In modules/constants.ts (GRID_LIMITS)
-MIN_SPREAD_ORDERS: 2,           // Always maintain minimum gap
+MIN_SPREAD_ORDERS: 2,           // Preserve the minimum empty gap reserve
 
-// Spread width itself stays user-configured (`targetSpreadPercent`) — fixed, no inflation.
-// Correction count has no separate slot cap; it is bounded by the funds check below.
+// `outOfSpread` supplies the requested slot count. Execution is bounded by
+// safe candidate selection, healthy minimum sizes, and actual free funds.
+const availableFund = Math.max(0, Math.min(
+    manager.funds.available[side],
+    manager.accountTotals[side === 'buy' ? 'buyFree' : 'sellFree']
+));
 
-// Each correction order must be healthy
-const minHealthySize = calculateMinOrderSize(side);
-const affordableOrderCount = Math.floor(availableFunds / minHealthySize);
-const correctionOrders = Math.min(missingSlots, affordableOrderCount);
+// Each target is created or topped up only while remainingBudget covers it.
+// No resting ACTIVE/PARTIAL order is shrunk to fund the correction.
 ```
 
 **Benefits**:
-- ✅ No "double-dust" fragmentation
+- ✅ No inventory recycling from stale-size snapshots
 - ✅ Constant, predictable spread width
 - ✅ Funds always respected (no forced allocation)
 - ✅ Natural smoothing over multiple rebalance cycles
@@ -591,12 +598,11 @@ if (mgr.outOfSpread) {
 ### After (Numeric Distance)
 
 ```javascript
-// New approach: distance in steps
-mgr.outOfSpread = 3;  // 3 steps beyond target spread
+// New approach: requested missing slots derived from the live geometry
+mgr.outOfSpread = 3;  // three slots beyond the target spread
 
-// Use distance in correction logic
-const spreadDistance = mgr.outOfSpread;
-const replacementSlots = Math.min(spreadDistance, MAX_CORRECTION_SLOTS);
+// The grid engine bounds actual work by eligible candidates, MIN_SPREAD_ORDERS,
+// healthy sizes, and available free funds. There is no MAX_CORRECTION_SLOTS cap.
 ```
 
 **Benefit**: Enables scaled corrections based on actual severity.
@@ -706,7 +712,7 @@ stateDiagram-v2
 
     note right of PARTIAL
         Partially filled on-chain
-        Waiting for consolidation
+        Dust is cancelled immediately; non-dust is corrected in rebalance
     end note
 ```
 
@@ -881,7 +887,7 @@ sequenceDiagram
     Strat-->>Mgr: target grid
     Mgr->>Mgr: Apply rotations via WorkingGrid
     Mgr->>Acct: Deduct BTS fees during recalculateFunds
-    Mgr->>Mgr: Consolidate dust partials
+    Mgr->>Mgr: Cancel detected dust partials immediately
 ```
 
 ### 2. Order Rotation (Crawl Mechanism)
@@ -1059,7 +1065,7 @@ The system has been optimized to use a "memory-driven" model for order updates,
 - **Faster reaction time**: No waiting for blockchain queries during order updates
 - **Reduced API load**: Fewer fetches, less network congestion
 - **Mathematical precision**: Integer-based tracking prevents float precision errors
-  - *See [FUND_MOVEMENT_AND_ACCOUNTING.md § 5.5](FUND_MOVEMENT_AND_ACCOUNTING.md#55-precision--quantization-patch-14) for quantization utilities and best practices*
+  - *See [FUND_MOVEMENT_AND_ACCOUNTING.md § 5.5](FUND_MOVEMENT_AND_ACCOUNTING.md#55-precision--quantization) for quantization utilities and best practices*
 - **Fallback safety**: Automatic recovery if memory state becomes inconsistent
 
 ### Performance Impact
@@ -1155,8 +1161,6 @@ graph LR
     B -->|Real-world Scenarios| B3["Fills/FEE Tests"]
 
     C -->|Dynamic Weight| C1["dynamic_weight"]
-    C -->|Derivative Trap| C2["derivative_signal"]
-    C -->|Momentum Gate| C3["momentum_gate"]
 
     D -->|CR Planner| D1["cr_planner"]
     D -->|Credit Runtime| D2["credit_runtime"]
@@ -1189,13 +1193,12 @@ node dist/tests/test_dexbot_credit_wiring.js
 - ✅ Edge cases covered (zero funds, max orders, etc.)
 - ✅ Concurrent operations tested with locks
 - ✅ State transitions validated end-to-end
-- ✅ Signal pipelines tested (dynamic weight, derivative traps)
+- ✅ Signal pipelines tested (dynamic weight)
 - ✅ Credit/debt runtime tested (CR planner, MPA wiring)
 
 **Test Suite Evolution:**
 - 50+ test cases for signal intelligence and credit runtime
 - Dynamic weight override and market adapter signal gate tests
-- Derivative momentum gate and signal trap regression tests
 - Credit/debt tests with CR planner and MPA wiring validation
 
 ### Testing Best Practices
@@ -1323,8 +1326,7 @@ The strategy engine has been significantly strengthened with improvements to fun
 **2. Dust Partial Handling**
 - Improved dust detection algorithm prevents false positives
 - Detects dust as `< 5% of ideal order size`
-- Dust partials are absorbed into the next grid rebuild cycle (no merge/split mechanics)
-- **Auto-Cancellation**: `_cancelDustOrders()` cancels dust partials on-chain immediately on detection — no delay, no timer maps, no retry budgets. Cancel is attempted post-fill (inside fill lock) and every 5-min health check (safety net).
+- **Immediate Cancellation**: `_cancelDustOrders()` cancels dust partials on-chain when detection runs — no delay, timer map, or consolidation cycle. Detection runs after fills/sync, and a 5-minute health check is the restart safety net.
 
 **3. Strict Order Size Constraints**
 - Orders validated to not exceed available funds

package/docs/developer_guide.md

@@ -129,8 +129,6 @@ A **phantom order** is an order in ACTIVE/PARTIAL state WITHOUT a valid `orderId
 | **Kalman Confirmation** | Kalman-filtered trend signal blended with AMA slope for smoother weight transitions |
 | **Symmetric Shift** | Volatility-driven downward weight penalty applied equally to both sides (ATR-based) |
 | **Asymmetric Offset** | Directional weight shift (buy-heavy or sell-heavy) driven by AMA/Kalman trend |
-| **Derivative Signal** | SMA/MACD/RSI-based entry bias and momentum gate for optional strategy filtering |
-| **Momentum Gate** | N-bar commitment tracking that confirms derivative signals before acting |
 | **GridPrice** | Price anchor for grid math; can be numeric, `"pool"`, `"book"`, or AMA keyword (`"ama"`, `"ama1"`–`"ama4"`) |
 
 ### Grid Concepts
@@ -165,7 +163,7 @@ A **phantom order** is an order in ACTIVE/PARTIAL state WITHOUT a valid `orderId
 | Term | Meaning |
 |------|---------|
 | **Rotation** | Moving an order from one price level to another |
-| **Consolidation** | Absorbing dust partials into the next grid rebuild cycle. All slots are treated uniformly—no side-specific flags or bonuses. |
+| **Consolidation** | Absorbing surviving non-dust partials into ordinary fund-driven rebalancing. Detected dust is cancelled immediately and never waits for a rebuild. |
 | **Rebalancing** | Adjusting order sizes based on current funds |
 | **Global Side Capping** | Scaling order sizes when insufficient funds |
 | **Atomic Check-and-Deduct** | Verify funds + deduct in single operation |
@@ -277,7 +275,7 @@ const correctedPrice = quantizeFloat(derivedPrice, 8);
 const normalized = normalizeInt(currentSizeInt, assetPrecision);
 ```
 
-**See [FUND_MOVEMENT_AND_ACCOUNTING.md § 5.5](FUND_MOVEMENT_AND_ACCOUNTING.md#55-precision--quantization-patch-14) for complete quantization guide and edge case handling.**
+**See [FUND_MOVEMENT_AND_ACCOUNTING.md § 5.5](FUND_MOVEMENT_AND_ACCOUNTING.md#55-precision--quantization) for complete quantization guide and edge case handling.**
 
 ---
 
@@ -620,7 +618,7 @@ const minHealthySize = getMinOrderSize(ORDER_TYPES.BUY, assets, 1.0);
 if (isOrderHealthy(order, minHealthySize)) {
     // Order is valid for placement/rotation
 } else {
-    // Order is dust - consolidate or skip
+    // Order is dust - skip it here; cancelDustOrders() handles it on-chain
 }
 ```
 
@@ -737,7 +735,7 @@ _verifyFundInvariants(...)
 - Process filled orders
 - Identify shortages and surpluses
 - Execute order rotations
-- Handle partial order consolidation
+- Handle surviving non-dust partials during rebalance
 
 **Critical Methods**:
 ```javascript
@@ -1211,8 +1209,6 @@ Located in `tests/` (with `helpers/` subdirectory):
 - `test_bts_fee_logic.ts` - BTS fee deduction and settlement
 - `test_market_adapter_signal_gates.ts` - Market adapter signal validation
 - `test_dynamic_weight_override_wiring.ts` - Dynamic weight config wiring
-- `test_derivative_signal_trap_regression.ts` - Derivative signal trap tests
-- `test_derivative_momentum_gate.ts` - Momentum gate tests
 - `test_cr_planner.ts` - Collateral ratio planner tests
 - `test_dexbot_credit_wiring.ts` - Credit runtime integration tests
 - `test_credential_daemon.ts` / `test_credential_session_cache.ts` - Credential security tests
@@ -1559,6 +1555,7 @@ console.log('Locked?', manager.isOrderLocked(order.id));
 - `modules/node_manager.ts` - Multi-node health checking and failover
 - `modules/fund_registry.ts` - Shared-account fund registry with cross-bot invariants
 - `modules/settings_merge.ts` - Consolidated settings merge (single source of truth)
+- `modules/bot_defaults.ts` - Central bot-defaults seeder (draft/entry/runtime-config modes); single source for how `DEFAULT_CONFIG` is applied
 - `modules/chain_orders.ts` - Blockchain order operations
 - `modules/account_orders.ts` - Account order queries