Ian Chou's Blog

Scout Handoff Threadwalker 實際流程

Scout Handoff Threadwalker 實際流程

Step 1: Scout 產出候選
        ↓  候選已經自帶「3 筆 evidence 線索」
        ↓  （這是 Gate 2 的品質門檻：候選必須「能在 24hr 內蒐到 3 筆線索」）
        ↓
Step 2: 你做壓力測試 4 問 → accept 或 reject
        ↓
Step 3: accept → 開 Scout thread（docs/thread_*.md）
        ↓
Step 4: 你去「驗證」那 3 筆線索（搜蝦皮、跑 script、問朋友...）
        ↓  驗證結果寫進 Scout thread
        ↓
Step 5: （可選）如果 evidence 夠了 → handoff 到 Threadwalker

幾個關鍵澄清

1. 「24 小時內 3 筆 evidence」不僅是品質門檻，更是健康度指標

它其實有雙重身分：

2. Accept 之後，證據是去「驗證」的，不是憑空生的

候選裡的 testable_actions 告訴你具體做什麼：

testable_actions:
  - 搜 Shopee TPM 價格區間        ← 你去搜，截圖/記錄就是 evidence
  - 看 Dcard 有無求助文            ← 你去看，找到就是 evidence
  - 問 2 個朋友是否卡住           ← 你去問，回答就是 evidence

3. 驗證結果進 Scout thread，不是直接進 Threadwalker

看 SHA-1 那個真實 thread 的結構就知道了——[§4 Consolidated evidence](file:///home/ianc/GitHub/2604-byway-scout/docs/thread_github_sha1_client_posture.md#L74-L127) 裡面是驗證後的完整 evidence（工具地景盤點、6 個真實 incident、實測 script 結果），全部寫在 docs/thread_*.md 裡。

4. 進 Threadwalker 是更後面的可選步驟

只有當你覺得「這條 thread 值得繼續走」，才走 handoff。而且 handoff 時，Scout 的 evidence 還要被重新過濾——你必須為每筆 evidence 自填 FRICTION 和 HUNCH，填不出來的就被刷掉。

用 TPM 走一次

時間點 動作 東西在哪
Day 1 早上 Scout 產出候選：「TPM 模組需求上升」 Scout 的 daily digest
Day 1 早上 你壓測 4 問 → accept 自動開 docs/thread_tpm.md
Day 1~2 你去搜蝦皮 → 真的有人賣、價格很高；問朋友 → 真的卡住 寫進 thread 的 evidence 區
Day 3+ 你標高價試單 → 快速售出 更多 evidence 累積在 thread
之後某天 你覺得「這條值得長期走」 handoff → 進 Threadwalker 的 sqlite

修正後的一句話總結：
候選自帶可行性線索 → accept → 你去驗證並寫進 Scout thread → 能在 24hr 內補齊就是 v1 健康訊號 → （可選）handoff 時 operator 為每筆 evidence 自填 FRICTION/HUNCH，過不了的就刷掉，刷光則改進 thread_closures.md（CL-002 型）而非開 Threadwalker thread。