Manual v0.2 上線前檢查清單
由 /opt/trad/staging_runtime/releases/testnet_fifo_repair_20260918_2320/docs/operations/pre-live-readiness-checklist.md 產生；首頁會優先顯示摘要，這頁保留完整文字。
上線前檢查清單與 Paper Test 通過標準
最後更新：2026-08-30
本文件用來整理從目前 `manual_strategy_v0_2_1_first_breakout_lock` forward paper test，走到 Demo/Testnet 穩定觀察與小額實盤前，需要確認的事項。這不是新的策略規格，也不是調參文件。
目前結論：可以繼續放著跑正式 paper + Demo/Testnet mirror，但還不建議直接接 production live order。
目前狀態
| 項目 | 狀態 | 白話說明 |
|---|---|---|
| 策略版本凍結 | 已完成 | 目前主測版固定為 `30m->5m / TP 3.5% / SL 5% / 最長 48h`。 |
| 正式 paper 計分 | 已重啟 | 起點是 `2026-08-28 22:30 +08:00`，舊資料只作 audit。 |
| Windows 每分鐘排程 | 已啟用 | 正式 runtime 在 `C:\桌面\TRAd_forward_runtime`，每分鐘叫醒一次。 |
| SQLite / watermark | 已完成初版 | 可以保存狀態並避免單純重掃覆蓋舊交易。 |
| WebSocket paper trigger | 已完成初版 | 用於即時觀察候選線碰價；不是實盤下單器。 |
| 新鮮訊號 bridge | 已完成初版 | 策略掃描剛確認的新訊號可轉成 observable paper entry；過期訊號不補單。 |
| Demo/Testnet mirror | 已接正式 runtime | 有新的 observable fill 時，最多鏡像一筆到 Binance Demo/Testnet。 |
| 測試盤帳戶損益 | 已加入首頁 | 首頁會顯示 Demo/Testnet USDT 權益相對起始值的損益。 |
| 完整新訊號鏈路 | 尚待實際訊號驗證 | 還需要看到至少一筆新訊號完整跑完 paper、dry-run、testnet、回寫與 dashboard。 |
| Production live order | 尚未開放 | 目前不允許正式實盤下單。 |
現在可以做什麼
目前最合理的動作是繼續讓排程跑，同時用首頁和五個檢查頁觀察狀態。這段期間不要改 TP、SL、週期、進場判斷、部位大小或會影響損益的邏輯。
每天或每次回來看時，先確認：
| 檢查項 | 通過條件 |
|---|---|
| 首頁整體狀態 | 顯示正常，或警告原因能被解釋。 |
| 資料水位 | 最新資料水位距現在不應長時間超過 10 分鐘。 |
| 策略水位 | 策略掃描水位距現在不應長時間超過 20 分鐘。 |
| WebSocket | 狀態在線，心跳不應長時間超過 3 分鐘。 |
| 有效未平倉 | 必須和 SQLite 狀態、forward dashboard、測試盤狀態能對得上。 |
| 過期不補單 | 可以存在，但不能被當成目前可交易訊號。 |
| Testnet Mirror | 狀態應為 OK；若有 blocked / unknown / rejected，要先查原因。 |
| 測試盤帳戶損益 | 用來看 Demo/Testnet 實際帳戶變化，不應和 paper 損益混在一起判讀。 |
Paper Test 通過標準
Paper test 的目的不是證明策略一定會賺錢，而是確認：策略凍結後，系統能否穩定、可重現、可追查地執行。
最低工程通過條件
這些條件通過後，才算「本機 paper runtime 可以繼續長期觀察」：
| 條件 | 判斷方式 |
|---|---|
| 24 到 48 小時無重大中斷 | 排程、資料、SQLite、dashboard 沒有持續故障。 |
| 沒有重複進場 | 同一個 observable fill 不得轉出多筆相同 dry-run / testnet order。 |
| 沒有漏記狀態 | paper position、fills、trades、testnet order lifecycle 必須能追到。 |
| 舊訊號不補單 | 超過新鮮窗口的訊號只能 audit，不得回補 paper / testnet order。 |
| full-scan OPEN 不算正式持倉 | 理論掃描 OPEN 只能當觀察值，不得混入正式 positions。 |
| dashboard 口徑清楚 | Paper 已平倉損益、測試盤帳戶損益、理論掃描 OPEN 必須分開。 |
第一筆完整鏈路通過條件
下一個最重要的事件，是看到一筆新的正式訊號完整跑完：
策略候選線
-> WebSocket 觸價或新鮮訊號 bridge
-> SQLite observable fill
-> paper position / trade
-> dry-run planned order
-> preflight 對帳
-> Demo/Testnet 下單
-> 查單回寫 SQLite lifecycle
-> dashboard 顯示 paper vs testnet 差異通過條件：
| 項目 | 通過標準 |
|---|---|
| 方向 | 多單 / 空單方向正確。 |
| 標的 | 只允許 BTCUSDT、VIRTUALUSDT、NEARUSDT、ONDOUSDT。 |
| 數量 | 名目接近 4,000 USDT，且符合 Binance step size。 |
| clientOrderId | 同一筆 fill 對應唯一且可重查的 client order id。 |
| 測試盤下單 | 能成功送出或被合理擋下；不能 unknown 後重複送單。 |
| 查單回寫 | testnet order id、狀態、成交數量、均價要寫回 SQLite。 |
| dashboard | dry-run / testnet mirror 頁能顯示 paper 與 testnet 差異。 |
如果 48 小時內沒有新訊號，這不是失敗；只是代表 execution 鏈路還沒有被真實 forward 訊號驗證。
小額實盤前必須完成
在 production live order 開放前，至少要完成：
| 項目 | 最低要求 |
|---|---|
| API key 權限 | 必須禁止提領；production 最好加 IP 限制；測試盤與實盤 key 分開。 |
| 交易所對帳 | 下單前強制檢查 Binance 實際持倉與掛單；若有未知手動倉位就停手。 |
| unknown / timeout 處理 | 發生 timeout 後必須先用原 clientOrderId 查單，不能直接重送。 |
| 出場單 | 實盤出場必須使用 reduceOnly 或等價安全邏輯，避免反向開倉。 |
| emergency stop | 停止旗標啟用後，不得產生新單；解除也要留下 audit log。 |
| 日虧損上限 | 達到當日虧損上限後停止新進場。 |
| 對帳失敗處理 | SQLite 和交易所狀態不一致時，系統應停手並要求人工檢查。 |
| 監控告警 | 至少要能看出 WebSocket 離線、排程停住、資料水位落後、testnet rejected / unknown。 |
小額實盤建議起步
即使工程檢查通過，也不建議直接用完整 10,000 或 100,000 USDT 規模上線。第一階段建議只做小額實盤：
| 項目 | 建議 |
|---|---|
| 起始帳戶 | 1,000 到 3,000 USDT。 |
| 單筆風險 | 0.25% 到 0.5%，最高不超過 1%。 |
| 放大方式 | 每一階段觀察穩定後再放大，不一次跳到完整資金。 |
| 觀察重點 | 真實成交滑價、延遲、手續費、funding、拒單、漏單、重複單。 |
| 停止條件 | 錯方向、重複下單、未能 reduceOnly 出場、狀態對不上、API 權限不安全，任一發生都先停。 |
白話：小額實盤是測工程與交易所真實摩擦，不是用來重新調策略。
實盤前風控口徑
策略裡已經有交易風險設計，例如 SL 5%、每筆名目、同標的持倉限制。實盤前風控不是另一套交易策略，而是下單安全層。
目前應保留的安全層：
- 只允許四個合約標的。
- 只允許 MARKET order。
- 單筆名目上限：4,000 USDT。
- 同標的最多一筆持倉。
- 總名目上限：16,000 USDT。
- 單日虧損上限：目前 dry-run 設為 300 USDT。
- 有 exchange open order 時先擋單。
- 交易所有非系統持倉時先擋單。
- 出場必須只減倉。
- emergency stop 開啟時全部停止。
異常處理 SOP
| 異常 | 處理方式 |
|---|---|
| 首頁顯示資料水位落後 | 先看 Runtime 健康檢查頁，再看最近 log；不要手動補單。 |
| WebSocket 離線 | 重啟 WebSocket paper trigger；離線期間訊號若已過新鮮窗口，不補送。 |
| 有過期不補單訊號 | 保留 audit；不當成漏單，也不回補 testnet。 |
| paper 有持倉但 testnet 沒單 | 查 dry-run / testnet mirror 是否被 preflight 擋下。 |
| testnet 有倉但 SQLite 沒倉 | 停止 mirror，先對帳；不得繼續送新單。 |
| 下單 timeout | 用原 clientOrderId 查狀態；查清楚前不得重送。 |
| rejected / blocked | 看 dashboard 原因；只有風控或設定合理修復後才恢復。 |
| 發現策略邏輯錯誤 | 建新策略版本並重新開始 forward paper test。 |
不要做的事
- 不要因短期 paper / testnet 損益修改 TP、SL 或進場規則。
- 不要把理論掃描 OPEN 當正式持倉。
- 不要補送超過新鮮窗口的舊訊號。
- 不要把 Demo/Testnet 帳戶損益和 paper ledger 損益混成同一個績效。
- 不要在 production live order 開放前，把 testnet mirror 改成真實交易所 endpoint。
- 不要直接放大到完整資金。
平常看哪裡
| 頁面 | 用途 |
|---|---|
| `reports/manual_strategy_v0_2_monitor_home.html` | 先看這頁，確認整體狀態、paper 損益、測試盤帳戶損益與警告。 |
| `reports/manual_strategy_v0_2_forward_paper_dashboard.html` | 查正式 paper 訊號、交易、持倉與理論掃描差異。 |
| `reports/manual_strategy_v0_2_paper_state_dashboard.html` | 查 SQLite positions、fills、watermarks。 |
| `reports/manual_strategy_v0_2_runtime_health.html` | 查排程、資料水位、策略水位、耗時與 log。 |
| `reports/manual_strategy_v0_2_execution_dry_run_dashboard.html` | 查 observable fill 如何轉成預備訂單，paper vs testnet 差異。 |
| `reports/manual_strategy_v0_2_execution_preflight_dashboard.html` | 查實盤前檢查項目是否通過。 |
下一個等待事件
目前最重要的是等待新的正式 forward 訊號，然後檢查它是否完整走完：
`observable paper fill -> dry-run order -> Demo/Testnet order -> status 回寫 -> dashboard 對照`
若這條鏈路成功，下一步才討論是否把 testnet 對帳再加嚴，或開始規劃小額實盤部署環境。若這條鏈路失敗，先修工程，不改策略。