jack/Chan - Chan

356 Commits 9 Branches 1 Tag

3 Commits

Include renames

Author	SHA1	Message	Date
jackandCursor	9562b8c598	空跑补一次带签名请求，否则密钥与白名单根本没被验到 dryrun 第 5 步声称"会真实验到密钥与白名单"，但 start() 在空跑下于密钥检查之前就 return，全程只发了 contracts() —— 那是公开端点，不验签。于是空跑会 "通过"却什么都没测到。这种假保证比不测更糟：等第一个真信号来时才暴露，而信号那时正在过期，没有从容排查的余地。现在空跑返回前发一次 account()（只读），失败即退出并给出码表（40018 白名单 / 40037 key 不存在 / 40001,40009 secret,passphrase / 40099 权限）。顺带报可用余额，并在不足 MAX_OPEN 笔并发所需保证金时告警。两处 SystemExit 会绕过 run() 的收尾，退出前不关 aiohttp 会话，日志尾部一串 Unclosed client session 会把真正的报错顶出视野。都补上了 close()。 BITGET_PASSPHRASE 现在也接受 BITGET_API_PASSPHRASE：另两项都带 API_，只有它不带，很容易顺手写错，而后果是"像是填了"但签名一直失败。我自己就踩了。启动时打一行 Telegram 是否启用。配错 token 的表现原本是完全静默。 Co-authored-by: Cursor <cursoragent@cursor.com>	2026-08-28 18:17:53 +08:00
jackandCursor	15f4aa088e	加 Telegram 通知，并修好一道死掉的闸接 Telegram 时查出 Guard.realized() 定义了但全仓库没有调用点——pnl_day 恒为 0，MAX_DAY_LOSS 完全不生效。三条硬约束里最重要的一条是死的。根因是止损与止盈都挂在交易所侧成交，本进程收不到通知，而 sweep 只在 48 分钟到点才查持仓。连带第二个后果：execs 条目不清，MAX_OPEN 把已出场的仓位继续算在场，新信号被白挡到截止时刻。补 watch() 循环（10s）：持仓消失即判出场，去 history-position 取 netProfit（= pnl + 资金费 + 开平手续费）记回闸并释放名额。盈亏取交易所的数而不自己按标记价估——估会漏掉费用且方向总偏乐观。历史未落库时留到下轮，不会漏记。字段名按文档与官方 TS 类型的差异同时兼容 ctime/cTime。 Telegram（live/tg.py，stdlib + aiohttp）：推开仓、平仓带已实现盈亏、被硬约束挡住、报错、对账平仓、跨日结算、启动与停机。不推信号过期跳过（常态，搬运重连会重放旧信号）与心跳，否则真事会被淹掉。启动那条兼作通道自检。研究侧 tg_notify.send 改为复用生产的传输层，方向与 signal_bus 一致。 status.sh 增加一条判读：开过仓但 pnl 仍为 0 就是 watch() 出了问题。实测：8 类消息渲染、_match_hist 的过早/方向不符/币不符/驼峰字段/取最近五种情形、100 USDT 下 SOL 与 ADA 的端到端空跑（两腿等量，50/50 精确）。 Co-authored-by: Cursor <cursoragent@cursor.com>	2026-08-28 17:30:11 +08:00
jackandCursor	335d891478	生产与研究分家：实盘执行器独立成 live/ 子树，加 AWS 部署实盘要跑在 AWS（API key 绑了 IP 白名单），而信号在新加坡那台算。借这次把生产从研究侧摘出来，四条具体代价里第一条已经咬过： 1. live_state.json 原先落在 research/out/，而那里 shadow_hb 会自动 rename 归档、研究脚本会写、人也手工清过。那文件装的是 MAX_DAY_LOSS 累计与已处理信号键，被清掉不报错，只是两道闸静默失效。改到 LIVE_HOME。 2. 采集器十币清空 300~560ms 直接叠在信号到达执行器的延迟上。 3. 研究侧探针 OOM 过一次（14.9GB），当时若有仓位在场会连坐执行器。 4. 为读两个常量 import 研究侧 step43，把 numpy/pandas/pyarrow 拖进实盘进程。抽出 stdlib-only 的 live/exit_params.py，install.sh 加断言挡回归。新增 live/ship_signals.py：AWS 侧 ssh tail 拉总线，每次重连从文件头重放 + 按幂等键去重，断线期间的信号自愈；旧信号由 staleness 闸挡掉不补做。带时钟倒流检测——两机时钟不同步会让那道闸静默放宽。部署件：systemd 两单元（搬运挂了执行器仍管在场仓位的超时平仓）、 install.sh、dryrun.sh（验密钥/白名单/时钟/ssh/取整）、status.sh、README。验证：live_exec 重构后端到端空跑，SOL 多头与 ADA 空头的止损/两级止盈/ 数量取整逐项核对正确，isolated + post_only + reduceOnly 都在；搬运的去重、重启不重复追加、脏数据跳过、断线重连重放均已测。 Co-authored-by: Cursor <cursoragent@cursor.com>	2026-08-28 17:03:03 +08:00

Author

SHA1

Message

Date

jackandCursor

9562b8c598

空跑补一次带签名请求，否则密钥与白名单根本没被验到

dryrun 第 5 步声称"会真实验到密钥与白名单"，但 start() 在空跑下于密钥检查
之前就 return，全程只发了 contracts() —— 那是公开端点，不验签。于是空跑会
"通过"却什么都没测到。这种假保证比不测更糟：等第一个真信号来时才暴露，而
信号那时正在过期，没有从容排查的余地。

现在空跑返回前发一次 account()（只读），失败即退出并给出码表（40018 白名单
/ 40037 key 不存在 / 40001,40009 secret,passphrase / 40099 权限）。顺带报
可用余额，并在不足 MAX_OPEN 笔并发所需保证金时告警。

两处 SystemExit 会绕过 run() 的收尾，退出前不关 aiohttp 会话，日志尾部一串
Unclosed client session 会把真正的报错顶出视野。都补上了 close()。

BITGET_PASSPHRASE 现在也接受 BITGET_API_PASSPHRASE：另两项都带 API_，只有
它不带，很容易顺手写错，而后果是"像是填了"但签名一直失败。我自己就踩了。

启动时打一行 Telegram 是否启用。配错 token 的表现原本是完全静默。

Co-authored-by: Cursor <cursoragent@cursor.com>

2026-08-28 18:17:53 +08:00

jackandCursor

15f4aa088e

加 Telegram 通知，并修好一道死掉的闸

接 Telegram 时查出 Guard.realized() 定义了但全仓库没有调用点——pnl_day
恒为 0，MAX_DAY_LOSS 完全不生效。三条硬约束里最重要的一条是死的。

根因是止损与止盈都挂在交易所侧成交，本进程收不到通知，而 sweep 只在 48
分钟到点才查持仓。连带第二个后果：execs 条目不清，MAX_OPEN 把已出场的
仓位继续算在场，新信号被白挡到截止时刻。

补 watch() 循环（10s）：持仓消失即判出场，去 history-position 取
netProfit（= pnl + 资金费 + 开平手续费）记回闸并释放名额。盈亏取交易所的
数而不自己按标记价估——估会漏掉费用且方向总偏乐观。历史未落库时留到下轮，
不会漏记。字段名按文档与官方 TS 类型的差异同时兼容 ctime/cTime。

Telegram（live/tg.py，stdlib + aiohttp）：推开仓、平仓带已实现盈亏、被硬
约束挡住、报错、对账平仓、跨日结算、启动与停机。不推信号过期跳过（常态，
搬运重连会重放旧信号）与心跳，否则真事会被淹掉。启动那条兼作通道自检。
研究侧 tg_notify.send 改为复用生产的传输层，方向与 signal_bus 一致。

status.sh 增加一条判读：开过仓但 pnl 仍为 0 就是 watch() 出了问题。

实测：8 类消息渲染、_match_hist 的过早/方向不符/币不符/驼峰字段/取最近
五种情形、100 USDT 下 SOL 与 ADA 的端到端空跑（两腿等量，50/50 精确）。

Co-authored-by: Cursor <cursoragent@cursor.com>

2026-08-28 17:30:11 +08:00

jackandCursor

335d891478

生产与研究分家：实盘执行器独立成 live/ 子树，加 AWS 部署

实盘要跑在 AWS（API key 绑了 IP 白名单），而信号在新加坡那台算。借这次
把生产从研究侧摘出来，四条具体代价里第一条已经咬过：

1. live_state.json 原先落在 research/out/，而那里 shadow_hb 会自动 rename
   归档、研究脚本会写、人也手工清过。那文件装的是 MAX_DAY_LOSS 累计与已
   处理信号键，被清掉不报错，只是两道闸静默失效。改到 LIVE_HOME。
2. 采集器十币清空 300~560ms 直接叠在信号到达执行器的延迟上。
3. 研究侧探针 OOM 过一次（14.9GB），当时若有仓位在场会连坐执行器。
4. 为读两个常量 import 研究侧 step43，把 numpy/pandas/pyarrow 拖进实盘
   进程。抽出 stdlib-only 的 live/exit_params.py，install.sh 加断言挡回归。

新增 live/ship_signals.py：AWS 侧 ssh tail 拉总线，每次重连从文件头重放
+ 按幂等键去重，断线期间的信号自愈；旧信号由 staleness 闸挡掉不补做。
带时钟倒流检测——两机时钟不同步会让那道闸静默放宽。

部署件：systemd 两单元（搬运挂了执行器仍管在场仓位的超时平仓）、
install.sh、dryrun.sh（验密钥/白名单/时钟/ssh/取整）、status.sh、README。

验证：live_exec 重构后端到端空跑，SOL 多头与 ADA 空头的止损/两级止盈/
数量取整逐项核对正确，isolated + post_only + reduceOnly 都在；搬运的去重、
重启不重复追加、脏数据跳过、断线重连重放均已测。

Co-authored-by: Cursor <cursoragent@cursor.com>

2026-08-28 17:03:03 +08:00