feat: add maker strategy config file

.specstory/history/2026-02-24_10-09Z-understanding-error-message-in-terminal.md

@@ -0,0 +1,115 @@
+<!-- Generated by SpecStory, Markdown v2.1.0 -->
+
+<!-- cursor Session f8d2e3ed-b4d1-41fd-98c2-c837f5eb6f55 (2026-02-24 10:09Z) -->
+
+# Understanding error message in terminal (2026-02-24 10:09Z)
+
+_**User**_
+
+ @/Users/wujunlin/.cursor/projects/Users-wujunlin-code-standx-standx-cli/terminals/3.txt:937-949 这个错误是什么意思
+
+---
+
+_**Agent (model default, mode Agent)**_
+
+<think><details><summary>Thought Process</summary>
+
+The user is asking about a Clippy error they're seeing in their terminal. Let me look at the error message they've shared:
+
+```
+error: the `Err`-variant returned from this function is very large
+  --> src/config.rs:68:27
+   |
+68 |     pub fn save(&self) -> Result<()> {
+   |                           ^^^^^^^^^^
+   |
+  ::: src/error.rs:9:5
+   |
+ 9 |     WebSocket(#[from] tokio_tungstenite::tungstenite::Error),
+   |     -------------------------------------------------------- the largest variant contains at least 136 bytes
+   |
+   = help: try reducing the size of `error::Error`, for example by boxing large elements or replacing it with `Box<error::Error>`
+   = help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.93.0/index.html#result_large_err
+```
+
+This is the Clippy lint `result_large_err`. The user wants to understand what this error means. Let me read the relevant files to give a more contextual explanation - the error type definition and the config save function.
+</details></think>
+
+---
+
+
+查看相关代码以便更准确地解释该错误。
+
+
+---
+
+<tool-use data-tool-type="read" data-tool-name="read_file_v2">
+<details><summary>Tool use: **read_file_v2** • Read file: /Users/wujunlin/code/standx/standx-cli/src/error.rs</summary>
+
+</details>
+</tool-use>
+
+---
+
+<tool-use data-tool-type="read" data-tool-name="read_file_v2">
+<details><summary>Tool use: **read_file_v2** • Read file: /Users/wujunlin/code/standx/standx-cli/src/config.rs</summary>
+
+</details>
+</tool-use>
+
+---
+
+<think><details><summary>Thought Process</summary>
+
+Now I have a clear picture. Let me explain this error to the user in Chinese since they asked in Chinese.
+</details></think>
+
+---
+
+
+这是 **Clippy** 的 `result_large_err` 告警，含义和原因如下。
+
+## 错误在说什么
+
+- **“the `Err`-variant returned from this function is very large”**  
+  意思是：`Config::save()` 的返回类型是 `Result<()>`，当返回 `Err` 时，里面装的是你的 `error::Error`，而这个错误类型**体积太大**（至少 136 字节）。
+
+- **为什么是 136 字节？**  
+  Clippy 指出：`Error` 里**最大的那个变体**至少有 136 字节，来自：
+
+  ```9:9:src/error.rs
+      WebSocket(#[from] tokio_tungstenite::tungstenite::Error),
+  ```
+
+  `tokio_tungstenite::tungstenite::Error` 本身可能包含多个字段（如缓冲、状态等），所以整个 `Error` 枚举按“最大变体”对齐后，尺寸就被拉大了。
+
+- **为什么 Clippy 要管这个？**  
+  `Result<T, E>` 在内存里要么是 `Ok(T)` 要么是 `Err(E)`，每次返回都会按 `E` 的大小在栈上预留空间。  
+  如果 `E` 很大（例如 > 几十字节），而函数又经常被调用（比如你的 `save()`），就会：
+  - 增加栈占用
+  - 可能影响缓存和性能  
+
+  所以 Clippy 建议：让返回的 `Err` 不要“直接”携带这么大的类型。
+
+## 总结成一句话
+
+**“`save()` 返回的 `Result<(), Error>` 里的 `Error` 太大（主要因为里面的 `WebSocket(tungstenite::Error)` 很大），Clippy 建议把它变小，例如用 `Box` 装起来。”**
+
+## 常见解决思路（仅说明，不替你改代码）
+
+1. **把大的变体用 `Box` 包起来**（最常见）  
+   在 `error.rs` 里把大的那一项改成例如：  
+   `WebSocket(#[from] Box<tokio_tungstenite::tungstenite::Error>)`，  
+   这样 `Error` 枚举的大小只增加一个指针，而不是整个 136 字节。
+
+2. **或者把整个 `Error` 装箱**  
+   例如 `Result<(), Box<Error>>`，这样所有返回 `Err` 的地方都只占一个指针的大小。
+
+3. **若暂时不想改**  
+   可以在该函数或该 crate 里对该 lint 做 `allow(result_large_err)`，但治标不治本。
+
+你当前 `save()` 里实际只会产生 `Error::Config(...)` 和 `std::io::Error`（通过 `Io`），并不会直接构造 `WebSocket`，但**返回类型**是统一的 `Result<()> = Result<(), Error>`，所以类型检查会按“可能返回任意 `Error` 变体”来算大小，从而触发 `result_large_err`。  
+解决方式就是按上面 1 或 2 缩小 `Error` 的尺寸即可。
+
+---
+

.specstory/history/2026-02-24_10-37Z-github-release-fetching-error.md

@@ -0,0 +1,124 @@
+<!-- Generated by SpecStory, Markdown v2.1.0 -->
+
+<!-- cursor Session 3a1a95fe-09f1-4132-bec9-af8b3de0d464 (2026-02-24 10:37Z) -->
+
+# GitHub release fetching error (2026-02-24 10:37Z)
+
+_**User**_
+
+Run softprops/action-gh-release@v1
+  with:
+    files: standx-macos-amd64.tar.gz
+  standx-linux-amd64.tar.gz
+
+    token: ***
+  env:
+    CARGO_TERM_COLOR: always
+    GITHUB_TOKEN: ***
+⚠️ Unexpected error fetching GitHub release for tag refs/tags/v0.1.1: HttpError: Resource not accessible by integration
+Error: Resource not accessible by integration
+
+@.github/workflows/ci.yml 
+
+---
+
+_**Agent (model default, mode Agent)**_
+
+<think><details><summary>Thought Process</summary>
+
+The user is encountering an error when running the GitHub Action `softprops/action-gh-release@v1`. The error message says:
+
+"Unexpected error fetching GitHub release for tag refs/tags/v0.1.1: HttpError: Resource not accessible by integration"
+"Error: Resource not accessible by integration"
+
+This typically happens when the `GITHUB_TOKEN` doesn't have sufficient permissions to create or modify GitHub releases. Let me look at their CI workflow to understand the setup and provide guidance.
+</details></think>
+
+---
+
+
+Checking your CI workflow to see how the release action is configured.
+
+
+---
+
+<tool-use data-tool-type="read" data-tool-name="read_file_v2">
+<details><summary>Tool use: **read_file_v2** • Read file: /Users/wujunlin/code/standx/standx-cli/.github/workflows/ci.yml</summary>
+
+</details>
+</tool-use>
+
+---
+
+<think><details><summary>Thought Process</summary>
+
+I see the workflow. The error "Resource not accessible by integration" when using `softprops/action-gh-release@v1` with `GITHUB_TOKEN` usually means one of these:
+
+1. **Permissions**: The default `GITHUB_TOKEN` in workflows has restricted permissions. For releases, the job needs `contents: write` permission. In newer GitHub Actions, the default token might only have read access.
+
+2. **Release already exists**: The action might be trying to *fetch* an existing release (e.g. to add assets to it), but the token doesn't have permission to read/write releases. The error says "fetching GitHub release for tag refs/tags/v0.1.1" - so it's trying to get the release that was just created by the "release" event. When you create a release in the GitHub UI or via API, the workflow runs. The action-gh-release by default might be trying to *update* the release (to attach files). So it needs permission to read the release and write assets.
+
+3. **Explicit permissions**: In GitHub Actions, you can set `permissions` at the workflow or job level. For `action-gh-release` you need:
+   - `contents: write` - to create/update releases and upload assets
+
+Let me provide a clear answer. The fix is to add a `permissions` block to the release job (or the whole workflow) granting `contents: write` so that the GITHUB_TOKEN can create/update releases and upload assets.
+
+I'm in Ask mode so I can only suggest the fix, not apply it.
+</details></think>
+
+---
+
+
+That message means the **default `GITHUB_TOKEN` doesn’t have permission** to create/update releases or upload release assets. The action is trying to fetch the release for tag `v0.1.1` (to attach the tarballs) and is blocked.
+
+**Fix: give the release job permission to write contents**
+
+Add a `permissions` block to the **release** job so the token can manage releases and upload assets. For example:
+
+```yaml
+  release:
+    needs: [build, build-macos, build-linux]
+    runs-on: ubuntu-latest
+    if: github.event_name == 'release'
+    permissions:
+      contents: write   # needed to create/update releases and upload assets
+    steps:
+      - uses: actions/checkout@v4
+      # ... rest unchanged
+```
+
+**Why this happens**
+
+- On push/pull_request, the default `GITHUB_TOKEN` usually has read-only `contents`.
+- Creating a release in the UI (or via API) triggers the workflow; `action-gh-release` then tries to **fetch** that release and **upload** the `files`.
+- Both “read release” and “upload release assets” require **write** access to `contents`, so without `contents: write` you get “Resource not accessible by integration”.
+
+**Optional: scope permissions to the whole workflow**
+
+If you prefer to set it once for the workflow:
+
+```yaml
+name: CI
+
+on: ...
+
+env:
+  CARGO_TERM_COLOR: always
+
+# Optional: only this job needs contents: write; other jobs can stay default
+# So per-job permission above is usually better.
+
+jobs:
+  build:
+    # no permissions needed
+  ...
+  release:
+    permissions:
+      contents: write
+    ...
+```
+
+So: add `permissions: contents: write` to the **release** job (or to the workflow if you want it global). After that, the release job should be able to attach `standx-macos-amd64.tar.gz` and `standx-linux-amd64.tar.gz` to the release.
+
+---
+

crates/standx-cli/src/cli.rs

@@ -1,4 +1,5 @@
 use clap::{Parser, Subcommand};
+use std::path::PathBuf;
 
 #[derive(Parser, Debug)]
 #[command(name = "standx")]
@@ -386,70 +387,74 @@ pub enum MakerCommands {
     Run {
         /// Symbol to quote (e.g., BTC-USD)
         symbol: String,
+        /// Maker strategy TOML file. If omitted, loads maker.toml from the
+        /// StandX config directory when it exists.
+        #[arg(long)]
+        maker_config: Option<PathBuf>,
         /// Half-spread from mark price in basis points
-        #[arg(long, default_value = "5")]
-        spread_bps: f64,
+        #[arg(long)]
+        spread_bps: Option<f64>,
         /// Eligibility band guard in bps: never quote outside mark ± band
-        #[arg(long, default_value = "20")]
-        band_bps: f64,
+        #[arg(long)]
+        band_bps: Option<f64>,
         /// Per-side, per-level order quantity
-        #[arg(long, default_value = "0.01")]
-        size: f64,
+        #[arg(long)]
+        size: Option<f64>,
         /// Number of quote levels per side
-        #[arg(long, default_value = "1")]
-        levels: u32,
+        #[arg(long)]
+        levels: Option<u32>,
         /// Spacing between levels in bps (when levels > 1)
-        #[arg(long, default_value = "2")]
-        level_step_bps: f64,
+        #[arg(long)]
+        level_step_bps: Option<f64>,
         /// Anti-flicker: re-quote only when mark moved more than this (bps)
         /// since the order was placed
-        #[arg(long, default_value = "3")]
-        refresh_bps: f64,
+        #[arg(long)]
+        refresh_bps: Option<f64>,
         /// Loop interval in seconds
-        #[arg(short, long, default_value = "5")]
-        interval: u64,
+        #[arg(short, long)]
+        interval: Option<u64>,
         /// Max absolute position; suppress the side that would exceed it
-        #[arg(long, default_value = "0.05")]
-        max_position: f64,
+        #[arg(long)]
+        max_position: Option<f64>,
         /// Inventory skew: at full inventory, shift the quote center this many
         /// bps away from mark to favor the reducing side (0 disables). Only
         /// takes effect in live mode; paper holds no position. Suggested
         /// starting point: roughly your --spread-bps
-        #[arg(long, default_value = "0")]
-        skew_bps: f64,
+        #[arg(long)]
+        skew_bps: Option<f64>,
         /// Actively exit inventory once |position| reaches this percent of
         /// --max-position. 0 disables; requires --inventory-exit-qty.
-        #[arg(long, default_value = "0")]
-        inventory_exit_pct: f64,
+        #[arg(long)]
+        inventory_exit_pct: Option<f64>,
         /// Maximum base quantity for one reduce-only inventory exit. 0
         /// disables; requires --inventory-exit-pct.
-        #[arg(long, default_value = "0")]
-        inventory_exit_qty: f64,
+        #[arg(long)]
+        inventory_exit_qty: Option<f64>,
         /// Sanity guard: skip the cycle (no places/cancels) when mark price
         /// and book mid diverge by more than this (bps) — the data sources
         /// disagree and acting on them would be unsafe
-        #[arg(long, default_value = "25")]
-        max_divergence_bps: f64,
+        #[arg(long)]
+        max_divergence_bps: Option<f64>,
         /// Volatility circuit breaker: halt quoting (pull all quotes) when the
         /// mark's range over --vol-window cycles reaches this many bps; resume
         /// once it falls below half that. 0 disables the breaker
-        #[arg(long, default_value = "0")]
-        vol_pause_bps: f64,
+        #[arg(long)]
+        vol_pause_bps: Option<f64>,
         /// Number of recent cycles the volatility breaker measures range over
-        #[arg(long, default_value = "12")]
-        vol_window: u32,
+        #[arg(long)]
+        vol_window: Option<u32>,
         /// Risk alert: fire when mark-to-market PnL drops to -this (quote
         /// units). 0 disables
-        #[arg(long, default_value = "0")]
-        alert_loss: f64,
+        #[arg(long)]
+        alert_loss: Option<f64>,
         /// Risk alert: fire when |position| reaches this percent of
         /// --max-position. 0 disables
-        #[arg(long, default_value = "0")]
-        alert_inventory_pct: f64,
+        #[arg(long)]
+        alert_inventory_pct: Option<f64>,
         /// Risk alert: fire when two-sided uptime drops below this percent
         /// (after warmup). 0 disables
-        #[arg(long, default_value = "0")]
-        alert_uptime: f64,
+        #[arg(long)]
+        alert_uptime: Option<f64>,
         /// Also POST risk alerts to this URL. stderr/JSON always get them
         /// regardless. Payload shape is set by --alert-webhook-format
         #[arg(long)]