# VibeWork Master Implementation Plan — 最終整合版（單一文件 v4.2）

作者：Codex / 需求：可執行、可觀測、可變現
版本：v4.2

## 目錄
- 更新日誌：v4.2（最後統整）
- 一頁商業導向執行綱要（Phase 1）
  - 核心目標（21 天）
  - 1) 啟動燃料：官方種子任務池（The Seed Supply）
  - 2) 流量入口：Agent 白名單入埠（The Traffic Gates）
    - Builder Agent（接案方）
    - Scout Agent（導流方）
  - 3) 變現閉環：從引流到抽成（The Revenue Loop）
  - 4) 3 週硬指標（Go/No-Go Gate）
    - Week 1（先證明「AI 可賺到第一單」）
    - Week 2（先證明「人類願意買單」）
    - Week 3（先證明「能持續正向現金流」）
  - 決勝原則（Phase 1 最後裁決）
  - Phase 1 專屬作戰文件
- Week 1 先發 20 筆官方種子任務（Day 1 可上架清單）
  - 1) 任務上架原則（v1）
  - 2) 20 筆 Day 1 任務題目（可直接建檔）
  - 3) 測試範例（共用）
  - 4) 20 筆 Day 1 發布作業清單
  - 5) 風險條件
- Phase 0 目標
- 優先順序
- 第一個技術驗證：Audit Logger
- PRD 版本與來源錨點基礎
- 技能證據與時效基礎
- 獨立部署要求
- 補充章節：MCP 任務閉環工程討論（可直接拆成 Jira Tickets）
  - 1) 判斷結果：`accept_criteria` 為「關鍵風險」
  - 1.1 問題定義
  - 1.2 修正方針（Judge Agent）
  - 1.3 可驗收的 Judge Contract
  - 1.4 具體實作票（Jira）
  - 2) 判斷結果：`claim_task` 超時機制若用 Cron 會失效
  - 2.1 修正方針（Redis TTL + Pub/Sub + 補償機制）
  - 2.2 風險控制（務必加上）
  - 2.3 狀態回滾順序（示例）
  - 2.4 具體實作票（Jira）
  - 3) 判斷結果：供給側冷啟動會直接決定 MCP 成敗
  - 3.1 供給側修正方案
  - 3.2 供給側品質規範（防止「空城計」）
  - 3.3 具體實作票（Jira）
  - 4) 任務狀態機（正式版本，避免多人協作亂轉）
  - 4.1 每一個轉換的責任與副作用
  - 4.2 交易一致性要求（不做的話會失敗）
  - 5) 進場即用：可直接執行的驗收清單（Phase 0~Phase 1）
- 2026-06-06 更新：第一階段目標可行性討論（導流與變現）
  - 結論
  - 為什麼這一版「有機會」而不是「必勝」？
  - 第一階段（導流 + 變現）建議 KPI（可直接拆 Jira）
    - Day 1-3（上線驗證）
    - Day 4-7（完成第一輪交易）
    - Day 8-14（開始穩定化）
    - Day 15-30（可決定繼續擴張）
  - 立即可實作但不需改程式碼的文件補件
- 2026-06-06 更新：v3.1 專業修正（持續討論版）
  - A) 對「這些做法能否達成第一階段目標」的最終工程判斷
  - B) 「先做 A1 還是 A2」的建議（核心工程決策）
  - C) 第二輪核心架構討論：交易路徑、外部擴散路徑、失敗邊界
    - 交易交易路徑（Mermaid）
    - 任務狀態機（含失敗治理）
  - D) Scout Agent（需求拓散）是否要立即上線？建議：Phase 2 後再放大
  - E) v3.1 追加的可直接拆票清單（Phase 1 穩化）
  - F) 外部 AI 生態觀測與採納機制（持續化）
- 2026-06-06 更新：紅黃綠告警、Kill Switch 與再保險機制（v3.2）
  - 1) 第一階段變現能否成立？最終專業結論
  - 2) 失敗門檻轉為可操作的紅黃綠（Day 1-30）
  - 3) 紅燈 Kill Switch 決策（實作在運維層）
  - 4) 與外部參考規範對齊的專業補強（已校準）
  - 5) 先天風險與我建議的對策（不是可選）
  - 6) 新增圖：紅黃綠閉環決策
  - 7) 下一步：要不要直接把紅黃綠矩陣與 Kill Switch 變成「第一階段上線 SOP」
  - 簡結
- 架構圖與流程圖（Mermaid）
  - 1. 任務狀態機總覽
  - 2. Judge Agent 端到端驗收流程
  - 3. Redis TTL 超時與 DB 補償防護
  - 4. 供給側冷啟動導流閉環
  - 5. 第一階段指標儀表板（實務監控）
- Phase 1 vs Phase 3：Scout Agent（AI 業務代理）機制的落地順序（建議）
  - 先做哪條線？建議你現在直接收斂：
  - Scout Agent 機制（Phase 3 Draft）— 建議加入到 `implementation_plan.md`
    - 1) 目標邏輯
    - 2) 核心流程（Scout API）
    - 3) Scout 風險與治理（先放到 `Phase 3`）
    - 4) Phase 1 必要的先行 KPI（收斂至此）
  - 5) Scout 機制流程圖（納入 Phase 3）
- 專業補充：AI 幫助拓散需求者這件事，怎麼做才是工程上正確的
  - 我建議的實作策略（四步走）
  - 你這套模式的核心判斷
  - 我建議你現在採納的決策（最務實版本）
  - 建議寫進 API 參數（Phase 3）作為你下一輪設計原型
  - 為什麼我建議「先穩住交易，再做病毒式成長」？
- 專案追加章節：Judge Agent 的 E2B 隔離、安全與快取策略（Phase 1b 先行）
  - A. 網路隔離設計（Network Isolation）
  - B. 快取策略（可降低驗收成本與延遲）
  - C. 回傳失敗分類（Judge 結果標準化）
  - D. 建議 API 契約（最小）
  - E. 快速結論（Phase 1b）
- Day 1-14 最小可交付執行順序（含責任人 / 驗收條件）
  - Day 1-2：基礎可見性與第一批任務
  - Day 3-5：交易關鍵路徑打通
  - Day 6-10：支付與回復流程強化
  - Day 11-14：KPI 仪表與修正節拍
  - Day 14 Gate（是否進入 Phase 2）
- Milestone 執行優先順序（A1 vs A2）— 專業判斷
  - 最佳順序：`A1 與 A2 並行啟動，但 A1 先上 `最短安全鍊` 橫切
  - 為什麼不是「先做 A2 再 A1」？
  - 參考外部技術訊號（加強你的決策信心）
  - 專案決議（可直接用）
- 追加：Reconciliation Ledger 風險控管規格（更可執行版本）
- Day 15-30 第二梯次執行順序（穩定化 + 控制擴張）
  - Day 15-21（Phase 2）：供給與媒合能力加強
  - Day 22-26（Phase 2）：金流與運維收斂
  - Day 27-30（Phase 3 鎖定門檻與白名單啟動）
- Scout 解鎖 Playbook（白名單到公開擴張）
  - 一次性解鎖門檻（必須同時達成）
  - 斷點回退條件（未達標即停）
  - 回退後恢復門檻
  - 風險分類
- 追加建議（Phase 2/3 的三項真實增長指標）
- Day 30-60：小流量公域拓展與成長機制（可控擴張）
  - 目標
  - Day 30-40（Phase 3.1）
  - Day 41-50（Phase 3.2）
  - Day 51-60（Phase 3.3）
- 30-60 Replaybook（SRE + 運營一頁式手冊）
  - Playbook A：支付異常（capture/refund 偏差）
  - Playbook B：Judge 失效（大量 TEST_FAIL / TIMEOUT）
  - Playbook C：Scout 異常（spamming / conversion 失效）
  - Playbook D：狀態機異常（超時/重複回退）
- Scout 資料模型（第一版，供 Phase 3 API 上線）
  - `scout_tasks`
  - `scout_reputation`
  - `affiliate_ledger`
- 追加建議：Day 60 的公開放量判斷（可選）
- Day 61-90：公開放量（Growth Flywheel）版本
  - 目標
  - Day 61-70：公開通路啟動
  - Day 71-80：經濟化與風險化繁簡
  - Day 81-90：可交付成長版本判定
- Day 61-90 Go/No-go Gate（對外放量最終門檻）
- 外部 AI 生態資訊採納機制（每週）
  - 周期節奏
  - 取樣清單（優先順序）
  - 議題落地機制
  - 外部訊號到決策的最小規則
  - 為何要這麼做（專業判斷）
- 2026-06-06 更新：v3.3 商模與流量可行性（把「能跑」推到「能賺」）
  - 1) 先澄清目標：第一階段的商業最小成功定義
  - 2) 第一階段（Day 1-30）商業門檻（可直接當 Go/No-Go Gate）
    - 供給方流量（AI Agent）
    - 需求方流量（人類付費需求）
    - 收益與風險
  - 3) 商模設計：雙方都能持續參與的最小閉環
    - 對 Builder AI 的價值
    - 對 Scout AI 的價值
    - 對需求方的價值
  - 4) Demand Side GTM：只靠 MCP 不夠，還要三條導流管道
    - A) 產品內導流（最先級）
    - B) 外部 MCP 入口（第二優先）
    - C) Scout 擴散（第三優先）
  - 5) 不是只有技術：對賬與收費的商業保險絲（Recommerce Safety）
  - 6) 第一階段可執行商業路線圖（14 / 30 天）
    - Day 1-14
    - Day 15-30
  - 7) 我建議新增的「商模與獲利」補充章節（下一次可直接塞到文件）
  - 8) 風險與提醒（這一段是我比較強勢的商模意見）
- 2026-06-06 更新：v3.4 漏洞稽核（先賺、再放大）＋專家視角補盲
  - 一、這一輪還可能漏掉的 14 類思考（高優先度）
  - 二、缺口對應的 v3.4 修正（可直接放 Jira）
  - 三、Phase 1 先做的 7 / 14 / 30 天修復順序（實際執行）
  - 四、關鍵結論：目前討論有沒有漏掉關鍵？
  - 五、補充：Phase 1 失敗邊界一圖（可直接貼進文件）
  - 六、外部 AI 生態（非技術）補充訊號（每週一次）
- 2026-06-06 更新：v3.4.1 台灣優先市場補強（Perplexity + Gemini 討論整合）
  - 一、對 Perplexity 6 項盲點的判斷：我同意度與補齊方向
    - 1) 法律與合規（最高優先）
    - 3) 資料洩漏與隱私（最高優先）
    - 4) 爭議與客服成本（最高優先）
  - 二、補上你們討論中 2 個很關鍵、但容易被忽略的深水點
    - A) 惡意提示詞注入 / Jailbreak
    - B) 設計系統一致性（你已提醒過）
  - 三、Perplexity 建議中我認為可延後到 Phase 2 的項目（並非否定）
  - 四、台灣優先市場的補充缺口（這是高價值但容易漏掉）
  - 五、v3.5 建議直接落地 Ticket（可直接切為 Jira）
  - 六、建議版本順序（更新）
  - 七、結論（直接回答你的問題）
- 2026-06-06 更新：v3.5 台灣合規與個資治理（AI 基本法 + PDPA）—Phase 0 強制項目
  - 一、共識：先做「可持續合法」而非先做「先上先賺」
  - 台灣市場一級優先目標（Phase 0 Kill Switch 控制）
  - 二、台灣法制對應到資料契約（立即可切票）
    - A) AI 基本法對應（透明＋安全）
    - B) PDPA 導向（隱私先行）
    - C) 金流 + 稅務資訊欄位先行
  - 三、你給的補強項目（COMPL）→ 我建議變成可執行版本
  - 四、Phase 0 最佳實作順序（我建議）
  - 五、我補上兩個你還沒明講但會讓你少踩坑的台灣實戰項目
  - 六、v3.5 Mermaid（台灣合規版）
  - 七、直接回答你的問題
- 2026-06-07 更新：VibeWork Phase 1 完整解決方案（AI Agent 引流 + 需求導入 + 初步變現）
  - 一、Phase 1 進攻式判斷標準（唯一目標）
  - 二、第一階段商業結構（進攻優先）
    - 1) 三主力通道（同步推進）
    - 2) 價值主張
    - 3) 收益與風險平衡（第一版）
  - 三、系統流程設計（DAP + Marketplace 分離）
    - 1) 狀態模型（v1）
    - 2) 核心原則
    - 3) 風險分層
    - 4) Mermaid：總體流程
  - 四、Growth + GMV 執行策略（第一階段專用）
    - 1) 進攻型產品資產
    - 2) Scout 白名單計畫
    - 3) 佔位內容策略（防空池）
    - 4) Mermaid：三條漏斗關係
  - 五、KPI、Gate 與日常運營（第一優先）
    - 1) Day 1–14 最小生存門檻
    - 2) Day 15–30 成長門檻
    - 3) Gate / Failback（硬規則）
    - 4) Mermaid：紅線 Playbook
  - 六、測試與驗收場景（v1，不立即上線）
  - 七、落地文件結構（直接插入 MD）
  - 八、假設與預設值
  - 九、決策鎖（Phase 1 已定）
- 2026-06-07 追加整合：Claude v3.2 實作版補齊與差異化修正
  - 一、直接採納（直接接上現有文件）
  - 二、與現行文檔衝突項（建議統一）
    - 1) 種子池獎金池不一致
    - 2) Schema 格式字眼
    - 3) `claim_task` 身份欄位
  - 三、建議補齊到現行 MD 的 3 段
    - (1) 交易路徑：A1 / A2 次序
    - (2) v3.2 監控告警矩陣
    - (3) 3 條漏斗 + 可執行指標收斂
  - 四、建議直接插入的 Mermaid（v3.2 版簡化）
  - 五、專業看法：這份 v3.2 還缺的兩個「第一週會爆炸」點
  - 六、下一步（已對齊你需求）
- 2026-06-08 補盲版（v4.0）：補齊 Claude v3.2 缺失的生死點
  - 第一部分：金流防欺詐與台灣落地（補到第九章金流架構）
    - 1) 交易與合規新增要點（Anti-Fraud & Compliance）
    - 2) 第九章對位文本（可直接貼回你草擬的 chapter）
  - 第二部分：第九章缺口補全為「架構化可執行內容」
    - 1) 第八章：系統架構圖（補齊）
  - 第三部分：第十二章 Jira（補上法務＋防欺詐票）
  - 第四部分：第十四章：在地化合規與資料治理（正式版）
  - 第五部分：專業補充（你問「還有沒有專業意見」）
- 2026-06-09 商業化深化：GTM、定價、法務、品牌與長期路線 (v4.1)
  - 一、GTM 深化（第一批人類發包者必須先信任）
    - 產品話術（可直接放首頁）
    - 進入人類需求者第一道槓桿（3 分鐘入口）
    - 對人類決策阻力的產品設計
    - 需求側導入流程建議（最小可運行）
    - 反詐與信任補強
  - 二、商業模式精算（15% 合理，但要做雙軌）
    - 價格策略建議
    - Unit Economics（建議在文件中加入可追蹤欄位）
  - 三、法律文件框架（Phase 1 最小版）
    - ToS 核心條文（可直接落地）
    - Work for Hire 條款（最小）  
    - 爭議仲裁條款（最小）
  - 四、品牌定位與命名（對外敘事）
    - 核心定位
    - Tagline 版
    - 競品差異化主張（可放進一頁對比表）
  - 五、Pitch Deck 駕馭邏輯（可直接投資人簡報）
    - 核心頁順序
    - 嵌入式市場量化（待實際校準）
  - 六、Roadmap 2/3 細化（Phase 1 不停戰，Phase 2/3 可持續增長）
    - Phase 2（Month 4-9）
    - Phase 3（Month 10-18）
    - 交付守則
  - 七、先補票（VIB 擴充）
  - 八、還缺的「真實市場風險」要件（最小補完）
- 摘要
- 一、第一階段商業結構（三主力通道同步推進）
  - A 檔：MCP 核心獲客入口（供給側）
  - B 檔：Demand Acquisition Plane（需求導流平面）
  - C 檔：Scout 白名單（外部導流）
- 二、變現閉環與分潤模型
- 三、啟動燃料：Day 1 官方種子任務池
  - 分級與定價（以 NT$ 為主，USD 為輔）
  - 共用規格約束
- 四、3 週硬指標與 Go/No-Go Gate
  - Week 1：AI 可賺第一單
  - Week 2：需求轉化成立
  - Week 3：持續正向現金流
- 五、紅線 Playbook（OODA）
- 六、產品進攻資產
- 七、Phase 1 下一步（建議）
- 八、商業化補充已併入
- 2026-06-10 最終統整補充：Execution Hardening（不改主架構，只補落地穩定性）
  - A. SW-01 / E2B 測試環境真實性（最後確認）
  - B. 3 分鐘入口幣別與結帳體驗（台灣優先）
  - C. Scout 引流歸因規則（避免早期爭議）
  - D. 最後 3 個 Execution 強化（你最新討論精煉）

---

## 更新日誌：v4.2（最後統整）
- 合併：PHASE_0_IMPLEMENTATION_PLAN.md + PHASE_1_COMMERCIAL_BATTLE_PLAN.md
- 加入：v4.0 台灣法規/PII/防欺詐補盲
- 加入：v4.1 商業化深化（GTM、定價、法務、品牌、Roadmap）
- 加入：最新 3 大執行層微調與 3 項 Day-1 可操作建議（算力、企業導流、可視化）

# VibeWork Phase 1：導流與變現優先版 1-Page Battle Plan (Commercial Battle Plan)

## 一頁商業導向執行綱要（Phase 1）

### 核心目標（21 天）
在 21 天內完成三件事：
- 外部 AI Agent 願意接案
- 需求者願意授權刷卡
- 平台成功抽取 15% 手續費並形成正向現金流

### 1) 啟動燃料：官方種子任務池（The Seed Supply）
沒有任務，AI 不會留下來。

- 任務數量與預算：先上 **100 筆任務**，總獎金池 **USD 500**（分級預算池）
- 品牌定價：
  - `$1`：Hello World 元件（超簡單）
  - `$5`：登入按鈕 / 單一元件
  - `$10`：靜態 Dashboard / 小型頁面
- 內容要求：每筆任務必含完整、可自動判斷的 `test_file_content`，保證代碼正確即可「無歧義結算」
- 佈署方式：
  - 內部先手工建立 **20 筆**（Day 1 當日必備）
  - 剩餘 **80 筆** 透過自動腳本轉換 GitHub `good first issue`

### 2) 流量入口：Agent 白名單入埠（The Traffic Gates）

#### Builder Agent（接案方）
- MCP 發布重點：`vibework-monetization-mcp` 主打「接上即賺」訊息
- 目標渠道：smithery.ai / MCP registry 相關生態
- 流量控制：第一階段只放行 **前 30 名**新 Agent 進入 OPEN 任務池（防止過載）

#### Scout Agent（導流方）
- 嚴格採「邀請制白名單」
- 先選 3–5 位具高質量外部導流能力的操作夥伴（社群/爬文經驗）
- 首輪主戰場：Reddit r/SaaS、GitHub Issue 討論區、明確開發需求訊號群組
- 規格：只准用受控回覆模板，禁止自由投放文案

### 3) 變現閉環：從引流到抽成（The Revenue Loop）

```mermaid
flowchart TD
  S[Scout 發現需求] --> P[AI 代生成價 + 付款連結]
  P --> H[需求者點擊並授權 Auth-Hold]
  H --> M[Builder 接單 + 提交]
  M --> J[Judge 沙盒驗收]
  J --> C[Stripe Capture]
  C --> R[分潤：VibeWork 15% / Builder 75% / Scout 10%]
```

- 目標分潤順序不變，優先保證成交速率與可回補機制到位
- `capture` 先行到帳是第 1 週關鍵，失敗交易改做回溯與爭議機制

### 4) 3 週硬指標（Go/No-Go Gate）

#### Week 1（先證明「AI 可賺到第一單」）
- 外部 Builder Agent 註冊且成功 Claim 任務：`>= 3` 隻
- 至少 `1` 筆完整閉環：`Claim -> Judge Pass -> Stripe Capture`

#### Week 2（先證明「人類願意買單」）
- 白名單 Scout 導流導入人類預授權：`>= 5`
- 外部 Agent `claim_task` 轉換率：`> 12%`

#### Week 3（先證明「能持續正向現金流」）
- 單週 Capture 交易：`> 15`
- 連續 3 天毛利：`> 0`
- 退款爭議率：`< 5%`

### 決勝原則（Phase 1 最後裁決）
- 只要 Week 1、2、3 任一門檻不達：停止新增功能開發，集中修復引流/轉單/結帳漏斗
- 先補短板再談擴量，不為了新功能犧牲首單現金流

### Phase 1 專屬作戰文件
- 商業與 GTM 版 1 頁綱要： [PHASE_1_COMMERCIAL_BATTLE_PLAN.md](/Users/ogt/Documents/VibeWork/docs/PHASE_1_COMMERCIAL_BATTLE_PLAN.md)
- 下一步既定順序：先確立 `SW-01` 標準 JSON Payload（含 `test_file_content`）再進行 3 分鐘需求入口 UI（可快速驗證 judge 與 capture 路徑）

## Week 1 先發 20 筆官方種子任務（Day 1 可上架清單）

> 目標：Day 1 當天即有 20 筆可完成、可驗證的高信心任務，保證 Builder Agent 有穩定接案體驗，並能快速跑出第一輪 capture。

### 1) 任務上架原則（v1）

- $1 任務：只要「輸出有預期 UI」就可通過；不要求動畫、後端、複雜互動。
- $5 任務：要求固定類別（按鈕、卡片、表單區段）與可重現樣式規格。
- $10 任務：允許 1 個父容器 + 2~4 個簡單子元件，需具可視可測試結構。
- 所有任務共用欄位：
  - `acceptance_criteria.validation_mode`: `VITEST_UNIT`
  - `test_file_content`: 提供對應最小測試檔
  - `error_classification`: `retryable` / `non_retryable`
  - `scope_clarity_score`: 0.90 以上（AI 轉任務後可立即執行）
  - `expected_reward`: 精準數字
  - `required_stack`: React + Tailwind

### 2) 20 筆 Day 1 任務題目（可直接建檔）

| 編號 | 任務名稱 | Reward | 類型 | 核心驗收要點 |
|---|---|---:|---|---|
| SW-01 | `Hello VibeWork` 標題元件 | $1 | C | 在頁面渲染 `<h1>Hello VibeWork</h1>` |
| SW-02 | 單色「開始任務」按鈕 | $1 | C | 按鈕文案「Start」與 `bg-blue-500 text-white rounded-md px-4 py-2` |
| SW-03 | 小字元件預留區（Badge） | $1 | C | 渲染圓角白底字元標籤，包含 `text-sm` |
| SW-04 | 靜態標籤列（3 個 chip） | $1 | C | 渲染 3 個 `.chip` 區塊，僅樣式與字串一致 |
| SW-05 | 簡易 Footer | $1 | C | 包含「Copyright」與年份字串 |
| SW-06 | Hero 區塊（無互動） | $1 | C | 包含主標與副標，副標長度 > 15 |
| SW-07 | 空白頁 + 預留插槽 | $1 | C | 渲染空白卡片與「No data」提示 |
| SW-08 | 單欄價格卡片 | $5 | B | 顯示 `title / price / description`，需有 3 列布局 |
| SW-09 | Login Primary Button 組件 | $5 | B | 包含「登入」字樣與 `onClick` prop 傳遞 |
| SW-10 | Secondary Button（outline 變體） | $5 | B | 需有 `variant` prop，`outline` 時 border 不透明 |
| SW-11 | Alert Banner（success / error） | $5 | B | 兩種 type 切換字體色與 icon class |
| SW-12 | Modal Trigger（無邏輯） | $5 | B | 可見觸發按鈕並渲染 Modal 區塊框 |
| SW-13 | 輸入框 + 標籤組件 | $5 | B | `<label>` 與 `<input placeholder>` 一一對應 |
| SW-14 | 卡片列表（3 欄） | $5 | B | `items` 渲染為固定 3 張卡，含標題與小標 |
| SW-15 | 導航列（desktop） | $5 | B | 左側品牌、右側 3 個連結，含 active 狀態 class |
| SW-16 | 結帳摘要面板 | $10 | A | 呈現 `plan name / amount / tax / total`，含灰階邊框 |
| SW-17 | 靜態 KPI Dashboard | $10 | A | 3 張數據卡 + 1 張圓餅圖占位 SVG |
| SW-18 | 訂閱設定卡片區 | $10 | A | 包含「月費/年費」切換 UI（僅 UI 不需真正切換） |
| SW-19 | 產品特性對照表 | $10 | A | 3 行比較表（欄位固定） |
| SW-20 | 活躍通知列表頁 | $10 | A | 渲染 4 列通知項目與「read/unread」狀態色 |

### 3) 測試範例（共用）

- `SW-01` 測試：
  - assert h1 存在
  - assert 文案為 `Hello VibeWork`
  - assert 無 lint error
- `$1~$5 任務` 測試：
  - assert 主要元素存在
  - assert 既有 class 存在
  - assert snapshot 差異 < 閾值（避免破壞式改動）
- `$10 任務` 測試：
  - assert 區塊結構完整
  - assert 所有子元件存在且文本一致

### 4) 20 筆 Day 1 發布作業清單

1. 上午：由產品/PM 先以固定 `acceptance_criteria` 模板批量建檔 20 筆  
2. 中午前：把 20 筆推送到「官方種子池」OPEN（僅白名單可見）  
3. 下午前：每 5 筆抽一筆人工跑一次 submit→judge→capture dry-run  
4. 下午：補齊失敗任務的測試文件與錯誤指引後再啟用對外曝光  
5. 晚上：輸出 Day1 `claim_success`、`first capture`、`avg judge pass` 初始值

### 5) 風險條件

- 若 20 筆中任務 3 筆以上通過率連續低於 60%，即暫停新增任務，先修正共通測試模板。  
- 若某任務類型失敗集中在同一 `scope_clarity_score`，則降級為 `B` 或 `C` 池，不作外部主池展示。  
- 任務描述過長／語義含糊者改為 `HIGH_RISK`，不做外部導流轉換測試。

---

# VibeWork AI 代理接案網路：終極商業與技術落地方案 (Master Implementation Plan v3.0)

# Phase 0 實作計畫

產生日期：2026-05-31

## Phase 0 目標

建立 VibeWork 的獨立產品骨架，讓後續 Phase 1 可以在清楚的資料模型、權限邊界、稽核紀錄與部署邊界上實作。

## 優先順序

1. 建立 Next.js、TypeScript、Tailwind CSS 專案骨架。
2. 建立 PostgreSQL 與 ORM migration。
3. 建立身份驗證與 RBAC 基礎。
4. 建立 AuditEvent 寫入機制。
5. 建立區塊式 PRD、版本、來源錨點與變更請求 schema。
6. 建立技能與工具標籤的證據時效 schema。
7. 建立 PRD 與 ChangeRequest API 契約。
8. 建立 demo 種子資料。
9. 建立 Docker 與 K3s 相容的部署骨架。

## 第一個技術驗證：Audit Logger

VibeWork 是高度依賴 AI 的 marketplace，因此 AuditEvent 應在 Auth、User CRUD 與 PRD 流程之前先完成。未來所有重要問題都會依賴它追蹤：

- AI 為什麼產生這條 PRD。
- AI 為什麼推薦這位 Vibe Coder。
- 誰在什麼時間修改了專案狀態。
- frozen PRD 是否被正確保護。
- ChangeRequest 如何被評估與接受。

建議 schema：

```prisma
model AuditEvent {
  id          String   @id @default(cuid())
  actorType   String
  actorId     String?
  action      String
  entityType  String
  entityId    String
  beforeState Json?
  afterState  Json?
  reason      String?
  metadata    Json?
  createdAt   DateTime @default(now())
}
```

Phase 0 驗收標準：

- 任一 service 可以用同一個 helper 寫入 AuditEvent。
- AuditEvent 可以記錄 human actor 與 system_agent。
- AuditEvent 可以記錄 beforeState 與 afterState。
- AuditEvent 必須與核心業務變更寫在同一個資料庫交易內。
- AuditEvent 寫入失敗時，重要狀態轉換必須回滾，不得被靜默視為成功。
- system_agent 的 AuditEvent metadata 必須記錄模型名稱、模型版本、temperature、prompt reference 與輸出摘要。

## PRD 版本與來源錨點基礎

建議 schema 概念：

- `PrdDocument`：代表某個專案目前的 PRD 聚合。
- `PrdVersion`：代表每次 frozen 或 superseded 的不可變版本。
- `PrdBlock`：代表 PRD 中可渲染、可追溯、可比對的最小內容區塊。
- `PrdSourceAnchor`：連接 PRD 區塊與需求者原始輸入。
- `ChangeRequest`：代表 frozen PRD 之後的變更提案。
- `ChangeRequestBlockDelta`：代表 ChangeRequest 對特定 PRD 區塊的新增、修改、刪除或移動。

Phase 0 不必完成完整 UI，但資料模型要能支援：

- 版本號。
- 內容 hash。
- 父版本。
- 區塊 ID 與跨版本 logical block ID。
- 未變更區塊的 referenceBlockId。
- AI 生成 metadata。
- 來源錨點。
- 找不到來源的 AI 推論標記。
- frozen PRD 的完整區塊快照。
- ChangeRequestBlockDelta 的 `structuredDiff` 結構化差異。

## 技能證據與時效基礎

SkillTag 與 ToolTag 不應只是靜態多選標籤。接案者與標籤的關聯必須保留：

- 最近使用時間。
- 驗證時間。
- 證據類型。
- 證據連結。
- 證明層級。

Phase 0 可以先設計 schema 與種子資料。Phase 1 用手動輸入與管理員審核。Phase 2 以後再接 GitHub、CI/CD 或測驗結果。

## 獨立部署要求

Phase 0 完成時，VibeWork 應該能在不依賴任何既有產品的情況下啟動：

- 獨立環境變數。
- 獨立資料庫。
- 獨立身份驗證 secret。
- 獨立 Docker image。
- 可部署到獨立 K3s namespace。

## 補充章節：MCP 任務閉環工程討論（可直接拆成 Jira Tickets）

以下段落整理 Gemini 與 Claude 討論後的完整修正，目標是讓整體規劃具備高併發、可觀測、可回放、可維運的能力。

### 1) 判斷結果：`accept_criteria` 為「關鍵風險」

這是整份規劃中最容易誤認為完成但實際會失敗的點。只用靜態規則去做字串或 AST 檢查，無法證明 UI/功能真正在 runtime 可運作。

### 1.1 問題定義

- `AST_PARSING` 很可能只證明語法片段存在，不代表畫面行為正確。
- 沒有定義 parser、執行者、測試資源隔離、超時、失敗分類，會變成黑盒。
- `bg-black` 或 `Hello VibeWork` 是否真的存在，應透過執行驗證而非純文字比對決定。

### 1.2 修正方針（Judge Agent）

Judge Agent 必須是可執行的驗收服務，不是規格文件中的名詞。  
推薦作法：`E2B 沙盒 + Node.js 環境 + Vitest + Playwright` 進行動態測試。

### 1.3 可驗收的 Judge Contract

1. 觸發條件：任務進入 `VERIFYING`。
2. 沙盒執行環境：固定 Node 版本、工作目錄、依賴安裝策略、最小網路權限。
3. 測試順序：`lint -> unit -> e2e`，每個階段可設定 fail-fast。
4. 成功判定：exit code = 0 且所有測試符合規格。
5. 失敗分類：
   - `test_failed`（邏輯/行為不符）
   - `timeout`（超過 5 分鐘）
   - `resource_exhausted`（CPU/Memory 限制）
   - `environment_error`（沙盒或工具層失敗）
6. 輸出 schema（不可省略）：
   - `overall_result`（pass/fail）
   - `tests[]`（name, status, duration_ms, logs）
   - `artifacts`（screenshot, logs, coverage summary）
   - `error_signature`
7. 行為規則：`test_failed` 可附帶 `retryable`/`non_retryable` 標記，供後端決策重試、回退、或進入人工仲裁。

### 1.4 具體實作票（Jira）

1. `VIB-001` 建立 Judge Agent 服務 API 與結果 schema。
2. `VIB-002` 建立 sandbox execution profile（Node 版本、resource limit、網路策略）。
3. `VIB-003` 建立驗收測試 runner template（lint/unit/e2e）。
4. `VIB-004` 串接 `VERIFYING -> COMPLETED/FAILED` 的後端 callback。

### 2) 判斷結果：`claim_task` 超時機制若用 Cron 會失效

`60 分鐘後自動回到 OPEN` 是對的商業邏輯，但不能靠 PostgreSQL cron polling 高併發掃描。  
10 萬筆 `EXECUTING` 任務同時存在時，輪詢會變成壓力源，還有精準度與 race window 問題。

### 2.1 修正方針（Redis TTL + Pub/Sub + 補償機制）

超時主控改為 Redis key TTL 事件，PostgreSQL 當真實狀態來源。  
`claim_task` 成功時，對應一個 key，例如：`vw:task:<task_id>:executing`，TTL 3600 秒。

### 2.2 風險控制（務必加上）

- Redis keyspace notifications 需明確在部署環境啟用。
- Pub/Sub 事件只能做第一道事件驅動，必須有補償掃描（reconciliation）避免事件遺失。
- rollback 流程必須是 transaction-safe、idempotent、可重入。
- 回退前要再次檢查 DB 真實狀態，避免 `VERIFYING` 剛完成被誤回到 OPEN。

### 2.3 狀態回滾順序（示例）

1. 收到 Redis key 過期事件。
2. 取得 `task_id` 對應 DB 行。
3. 原子交易更新：`EXECUTING -> OPEN` 且寫入 `error_reason=claim_timeout`。
4. 釋放 Stripe auth-hold。
5. 發出 `task_state_reverted` 事件並寫 audit log。

### 2.4 具體實作票（Jira）

1. `VIB-005` 建立 Redis TTL key 命名、TTL 時間、超時副作用對照表。
2. `VIB-006` 建立 `task:state_reaper` worker 監聽 expired 事件。
3. `VIB-007` 建立 DB 重掃補償任務（每 1 分鐘檢查 TTL 與 DB 狀態）。
4. `VIB-008` 建立 rollback API 的冪等與鎖機制（防重複回退）。

### 3) 判斷結果：供給側冷啟動會直接決定 MCP 成敗

這是最容易被忽略但最容易致命的面。  
若初期 MCP 任務池為空，所有「留存、信任、經濟激勵」都會失效。

### 3.1 供給側修正方案

- 官方預設任務種子池：建議先放 100 筆，難度 1~5 逐步遞增，並強制 `expected_tests` 與 `reviewed=true`。
- GitHub Issue 自動化搬運：掃描公開庫 `help wanted` / `good first issue`，做授權與機敏資訊過濾後轉換 PRD。
- Design Partner 計畫：3~5 家合作方提供小額真實需求，作為早期任務質感基底。

### 3.2 供給側品質規範（防止「空城計」）

1. 任務描述欄位完整度必檢：title、success criteria、測試條件、預期輸出、限制條件。
2. 付款策略上限可控：可視難度分層（例如 $0.1~$5）並設置預算上限。
3. 違規與無效任務速率管控：低質任務需自動下架並提供修正提示。
4. 合作方來源任務附上來源授權與敏感資料審核結果。

### 3.3 具體實作票（Jira）

1. `VIB-009` 建立官方種子任務生成與上架 pipeline。
2. `VIB-010` 建立 issue scraper 與 PRD 轉換流程（含授權檢查與人工審核）。
3. `VIB-011` 建立合作方任務上架流程與質量欄位驗證。

### 4) 任務狀態機（正式版本，避免多人協作亂轉）

建議統一任務生命週期定義，前後端、MCP、Judge Agent 必遵守同一張規則表。

```text
OPEN
  ├─ claim_task -> EXECUTING
  ├─ cancel -> CANCELLED

EXECUTING
  ├─ submit_solution -> VERIFYING
  ├─ timeout -> OPEN (Redis TTL expired + state rollback)
  ├─ cancel -> CANCELLED
  ├─ agent_abandon -> FAILED

VERIFYING
  ├─ judge_pass (exit_code 0) -> COMPLETED
  ├─ judge_fail retryable -> FAILED
  ├─ judge_fail_non_retryable -> FAILED
  ├─ timeout > 5m -> FAILED

FAILED
  ├─ retry_policy = auto_open -> OPEN
  ├─ retry_policy = archive -> ARCHIVED
  ├─ dispute -> DISPUTED

COMPLETED
  ├─ dispute -> DISPUTED
  ├─ dispute_resolved -> ARCHIVED

CANCELLED -> ARCHIVED
DISPUTED -> resolution -> (OPEN / COMPLETED / ARCHIVED)
ARCHIVED -> (closed)
```

### 4.1 每一個轉換的責任與副作用

1. OPEN -> EXECUTING：MCP/後端，進行 agent 資格與 auth-hold。
2. EXECUTING -> OPEN：timeout worker，回退狀態、解除預授權、寫錯誤日誌。
3. EXECUTING -> VERIFYING：後端，打包提交結果、觸發 Judge 任務。
4. VERIFYING -> COMPLETED：Judge Agent，回傳 pass + 後端 capture 金流、發出 webhook。
5. VERIFYING -> FAILED：Judge Agent 或後端 watchdog，依失敗型別決定可重試策略。
6. FAILED/OPEN/COMPLETED 互轉前必進行事件記錄與 idempotency 保護。

### 4.2 交易一致性要求（不做的話會失敗）

1. `Stripe capture` 必要使用 idempotency key。
2. `state transition` 必須搭配 audit log 與事件總線，不得僅靠 cache 結果。
3. 所有回退與 capture 都是可重入操作並保證單次副作用執行。

### 5) 進場即用：可直接執行的驗收清單（Phase 0~Phase 1）

1. 實作 Judge Agent contract 並可回傳 pass/fail + 測試 log。
2. 使用 Redis TTL 作為主要 timeout 觸發機制並加 DB 補償。
3. 在 API 層實作 task state machine 轉換 guard 與錯誤碼。
4. 先行上線官方 100 筆種子任務並驗證 5 分鐘內有可接任務。
5. 全程寫 audit 與事件，讓任務回顧可回放且可排查。

完成後，`implementation_plan` 才能真正從策略文件進化為可執行工程藍圖。

## 2026-06-06 更新：第一階段目標可行性討論（導流與變現）

### 結論

目前討論後形成的方案，已將「第一階段目標」從概念層提升到**可開始驗證的工程層**：

- 可行：已補齊網際網路 AI Agent 導流的關鍵前置條件（`Judge` 可驗證、`task state machine` 可落地、`timeout` 可控、供給池不空白）。
- 還不足：目前仍未保證一定「立即變現」，而是先保證「可執行」、「有機會成交」、以及「可被量測」。
- 判斷：
  - 若只看架構健壯性：能導流的門檻已達成。
  - 若看第一階段實際收入：需要再加一層「導入效能 + 變現指標」才能判斷成功與否。

### 為什麼這一版「有機會」而不是「必勝」？

這個系統現在已不是玩具，但第一階段仍有三個現實條件會決定營收是否啟動：

- MCP 整合可用性：上架與文件、SDK/範例要足夠讓外部 Agent 能快速呼叫。
- 流量轉換效率：Agent 呼叫 `list_open_tasks` 到 `claim_task` 的轉換率。
- 交易化成功率：`claim -> submit_solution -> judge_pass -> capture` 的順利完成比率。

若這三項中任一項長期不足，技術再穩也不會自動變現。

### 第一階段（導流 + 變現）建議 KPI（可直接拆 Jira）

建議把第一階段做成四個觀察窗，且每個指標都要有「門檻值」與「回退條件」：

#### Day 1-3（上線驗證）

1. MCP 列表可見性：`vibework-monetization-mcp` 在主要目標入口成功回應率 ≥ 99%。  
2. 任務可用性：`OPEN` 任務非空比率 100%，且平均查詢回傳時間 < 300ms。  
3. 首位 Agent 體驗：至少 3 位外部測試 Agent 在 24 小時內完成一次 `claim_task`。

#### Day 4-7（完成第一輪交易）

1. 端到端交易數：至少 5 筆 `claim_task -> submit_solution`。  
2. Judge 通關率：`VERIFYING` 到 `COMPLETED` 成功率 ≥ 60%。  
3. 超時與回退可控：`OPEN` 回退率 ≤ 30%，且每筆皆有 `error_signature`。

#### Day 8-14（開始穩定化）

1. 每日活躍任務流量：`list_open_tasks` 調用日均 > 50。  
2. 付費完成值：每日最少 1 筆成功 capture（或對應等值 token/credits 完成）  
3. 供給端補位：官方種子任務池 30 天內補空率 = 0（不出現 10 分鐘以上「OPEN 全為 0」）。

#### Day 15-30（可決定繼續擴張）

1. 總完成任務數：日均完成任務 > 3。  
2. 兌付穩定性：`capture` 成功率 ≥ 98%，refund + retry 率可被追蹤並低於 5%。  
3. 初步經濟指標：每日毛利（淨平台手續費）連續 3 天為正，且下降率受控。  
4. 客訴可控：`DISPUTED` 比率 < 5%，平均仲裁時長可量測。

### 立即可實作但不需改程式碼的文件補件

為了讓第一階段 KPI 可成立，建議在 `implementation_plan` 內新增以下非功能項目（文件化即刻可做）：

1. `Day 1` 入口文件：5 分鐘上手（install MCP、list、claim、submit、check）。
2. `Day 2` 成功案例：固定一個「可複製/可重複」的 1 美元按鈕任務示範。

## 2026-06-06 更新：v3.1 專業修正（持續討論版）

### A) 對「這些做法能否達成第一階段目標」的最終工程判斷

在目前這版裡，**導流與變現都已具備「可驗證可放量」的前提**，但要嚴格區分兩種成功：

1. 可交易（technical readiness）
- 需先成立：MCP 可調用、任務不為空、Judge 有明確 pass/fail、金流可捕獲與回滾。
- 這是「能做」：目前方案已經把這三條補齊。

2. 可盈利（economic readiness）
- 需再成立：`有效 capture` 連續發生、`refund+dispute` 受控、SLO 有閉環、外部需求有穩定輸入。
- 這是「能賺」：目前仍需第 2 段 GTM 觀測與仲裁機制穩住后才算成立。

因此答案是：  
**這套方案能讓第一階段很快從 0 到 1，但要長時間「穩定變現」，必須先通過 Day 14 Gate、再逐步放大。**

### B) 「先做 A1 還是 A2」的建議（核心工程決策）

這是我建議給團隊的明確順序：

1. **A1（Reconciliation Ledger）優先啟動**
- 理由：任何金流動作如果沒有對帳邏輯，A2 的任何通過結果都可能掩蓋財務誤帳。
- 若先做 A2 再補 A1，後續會出現 capture 漏帳、退款無對齊、狀態飄移的高成本回溯。

2. **A2（Judge E2B）以「小型驗證路徑」並行預熱**
- 在 A1 的交易邊界骨架完成前，先做一個最小可回收（dry-run）版的 Judge 健康檢查。
- 目的是給團隊「可視化士氣」與時間估算，而不把所有測試結果當成正式可賺交易依據。

3. **Day 1-2 風險控制順序**
- 每次 `claim_task` 都必須同時觸發：
  - 狀態鎖定（FOR UPDATE）
  - auth-hold
  - reconciliation ledger 的預記錄（待 capture）
- 這樣當 `judge` 出錯時，仍可精準追責與回滾。

### C) 第二輪核心架構討論：交易路徑、外部擴散路徑、失敗邊界

#### 交易交易路徑（Mermaid）

```mermaid
flowchart LR
  A["Human Demand Source"] --> B["Scout / Builder / MCP Agent"]
  B --> C["MCP Client"]
  C --> D["list_open_tasks"]
  D --> E["claim_task"]
  E --> F["PostgreSQL: OPEN -> EXECUTING"]
  F --> G["Auth-Hold（Stripe）"]
  G --> H["submit_solution"]
  H --> I["Judge Sandbox (E2B)"]
  I -->|pass| J["VERIFYING -> COMPLETED"]
  I -->|fail retryable| K["FAILED_RETRYABLE"]
  I -->|fail non-retryable| L["FAILED"]
  J --> M["Capture + Ledger 記帳"]
  J --> N["Payout（Delay Settlement）"]
  K --> O{"retry_count < MAX_RETRIES?"}
  O -->|Yes| E
  O -->|No| P["mark failed"]
  K -->|timeout>5m| P
  L --> P
  F -->|TTL 3600s| Q["Redis Expired Event"]
  Q --> R["Rollback to OPEN + Release Auth"]
  M --> S["Dispute/Refund"]
  S --> F
  R -->|audit| T["Ops Log + Alerts"]
```

#### 任務狀態機（含失敗治理）

```mermaid
stateDiagram-v2
    [*] --> OPEN
    OPEN --> EXECUTING : claim_task
    OPEN --> CANCELLED : cancel/manual
    EXECUTING --> VERIFYING : submit_solution
    EXECUTING --> OPEN : timeout(3600s)+rollback
    EXECUTING --> FAILED : worker kill/unknown
    VERIFYING --> COMPLETED : judge pass（exit 0）
    VERIFYING --> FAILED_RETRYABLE : judge fail retryable
    VERIFYING --> FAILED : judge fail non-retryable / timeout
    FAILED_RETRYABLE --> EXECUTING : retry（if retry_count <= 3）
    FAILED_RETRYABLE --> ARCHIVED : retry exhausted
    FAILED --> ARCHIVED : policy decision
    COMPLETED --> DISPUTED : human dispute
    DISPUTED --> REFUND_PENDING : valid dispute
    REFUND_PENDING --> DISPUTED_RESOLVED : mediation
    DISPUTED_RESOLVED --> ARCHIVED : close
    COMPLETED --> PAYOUT_READY : settlement window
    PAYOUT_READY --> PAYOUT_SETTLED : payout success
```

### D) Scout Agent（需求拓散）是否要立即上線？建議：Phase 2 後再放大

我同意你「讓 AI 幫需求者拓散」的方向，這是正確增長邏輯，但建議**先做能力上限測試**再放大：

1. Phase 1 重點先抓：  
- 金流對帳零漂移、Judge 通過率、退款/仲裁可控、供給池持續有任務。  
2. 只有在 Day 14 Gate 通過後，才啟動少量 Scout beta。  
3. Day 30 前只上限 3~5 家白名單 Scout；把 `conversion_health`、`spam_score`、`chargeback-to-task` 指標作為硬闖關。  
4. 若沒有先修完退款與仲裁鏈路，先快樂做大量 scout 只會快速放大客服與爭議成本。

### E) v3.1 追加的可直接拆票清單（Phase 1 穩化）

1. **VIB-012**：補上「交易前提條件」頁（可在 PRD 附件）：  
   - 任務可用性、MCP 文件版本、Judge fail code 對照、錯誤回報流程。  
2. **VIB-013**：建立 `golden task suite`（3–5 個固定樣本）  
   - 每次部署前自動跑，作為第一道線上品質閘道。  
3. **VIB-014**：建立 `capture-ledger drift` 每 15 分鐘巡檢  
   - 欄位包含 task_id、amount、ledger_status、stripe_status、state_age。  
4. **VIB-015**：設計 `external signal feed` 實作模板  
   - 每週三固定更新 MCP/Stripe/Redis/E2B 官方異動與回應計畫。  
5. **VIB-016**：建 `Scout 分潤結算延遲模型` 與 `dispute hold`  
   - Capture 72 小時或無紛爭條件滿足後才結算。

### F) 外部 AI 生態觀測與採納機制（持續化）

你要的「外部所有相關 AI 資訊」已納入制度化流程，建議補充為：

- 每週三固定 90 分鐘短會：  
  1. MCP 安全與授權變更  
  2. Stripe Webhook/idempotency 異動  
  3. Redis keyspace event 行為修正  
  4. E2B/容器安全 CVE  
- 會議輸出固定成 1 頁：
  - 影響任務：`critical / major / minor`
  - 是否需要 hotfix 或 fallback image
  - 是否影響 Day 14 Gate 或 Day 30 Gate

若資訊落地，VibeWork 才是「有自我修復能力的系統」，而不是一次性文件專案。

## 2026-06-06 更新：紅黃綠告警、Kill Switch 與再保險機制（v3.2）

### 1) 第一階段變現能否成立？最終專業結論

我保守的結論是：**第一階段目標可成立的機率高，但前提是「交易可靠度」和「風控對齊」同時過門檻**。  
這裡給一個可執行標準：  
若 Day 1-14 已通過 `capture 成功率 + 供給不斷流 + 退款控制 + 仲裁時長` 其中任一條件，系統就不具備放量前提，即使有流量也不能再開新通道投放。

### 2) 失敗門檻轉為可操作的紅黃綠（Day 1-30）

以下為第一階段專用的 OODA 告警矩陣：

| 指標 | 綠燈 | 黃燈 | 紅燈 |
| --- | --- | --- | --- |
| 目標指標：`capture_success_rate_24h` | ≥ 92% | 85%~91% | < 85% |
| `judge_pass_rate_24h` | ≥ 78% | 68%~77% | < 68% |
| `refund_dispute_rate_7d` | < 3% | 3%~6% | > 6% |
| `avg_state_transition_latency`（OPEN→COMPLETED） | < 180s | 180s~420s | > 420s |
| `open_task_stockout_ratio`（任務池空比例） | < 5% | 5%~15% | > 15% |

### 3) 紅燈 Kill Switch 決策（實作在運維層）

1. `capture_success_rate_24h < 85%` 持續 2 個檢核視窗（60 分鐘）則啟動 `incident_mode`，停用 MCP `claim_task`。  
2. `refund_dispute_rate_7d > 6%` 且 `judge_pass_rate_24h < 68%` 同時成立時，僅保留白名單 Scout/Builder，暫停外部自助通道。  
3. `open_task_stockout_ratio > 15%` 持續 30 分鐘以上，啟用 `open_task_fallback`（官方種子任務補位）與每日補單。  
4. `state_revert_lag_p99 > 90s`（Redis+DB 回退延遲）超過兩個鐘點檢查，立即切斷 Redis 事件接入，改用 DB reaper 補償。  
5. `stripe_webhook_delay_p95 > 120m` 持續 2 小時，暫停新任務 capture，僅保留人工仲裁通道，避免重複結算風險。

### 4) 與外部參考規範對齊的專業補強（已校準）

1. MCP 安全邊界：`Authorization: Bearer <token>` 必須出現在每次 MCP HTTP 請求，且每個 token 需驗證 aud。這是目前 MCP 規格文件明確要求。  
2. Redis Keyspace：過期事件為非嚴格實時，官方文件明確指出 expired 事件可能延遲，所以「`keyevent` 觸發」只能作為第一道訊號，必須搭配補償 Job 兜底。  
3. Stripe 重試：官方機制會在 3 天內重試 Webhook，且手動重送不會取消後續自動重試；故 webhook 任務必具備冪等鍵與重放去重。  
4. Stripe Idempotency：同一 idempotency key 會回放首次回應（含失敗結果），所以 capture/refund 流程一定要設計「任務 ID + amount + phase」的穩定 key，杜絕重複出帳或重複退款。  

### 5) 先天風險與我建議的對策（不是可選）

1. 首輪 Scout 不做大流量，先 3~5 家白名單，並以 `conversion_health` 作為硬性過濾閾值。  
2. 所有 `FAILED_RETRYABLE` 的錯誤 signature 要記錄 `judge_stack_trace_hash`，並作為 Builder 與 Scout 的質量分數模型輸入。  
3. `TaskState` 的每次變更都要同時寫入 `ledger` 與 `audit`，否則把該事件列為 non-compliant，無法進入下一輪 release。  
4. `list_open_tasks` 率低於 99% 時，先修 MCP 可用性再談 KPI，不要先調整 KPI。  

### 6) 新增圖：紅黃綠閉環決策

```mermaid
flowchart TD
  M["每 15 分鐘監控"]
  A["compute gauges"]
  B{"capture>=85%?"}
  C{"judge>=68%?"}
  D{"dispute<=6%?"}
  E{"stockout<=15%?"}
  F["Green: continue"]
  G["Yellow: incident_mode=watch,限流/降速"]
  H["Red: claim_task freeze + incident playbook"]

  M --> A --> B
  B -->|No| G
  B -->|Yes| C
  C -->|No| G
  C -->|Yes| D
  D -->|No| H
  D -->|Yes| E
  E -->|No| G
  E -->|Yes| F

  G -->|3 windows連續| H
```

### 7) 下一步：要不要直接把紅黃綠矩陣與 Kill Switch 變成「第一階段上線 SOP」

我建議下一輪直接新增一章「SOP：Incident Triage（按鈕式流程）」並將「紅黃綠門檻、停機腳本、回復條件」做成一頁清單，這樣第一輪值班可在 3 分鐘內做對應決策，不靠口頭判斷。
3. `Day 3` 監控看板：上述 KPI 每日更新，超過警戒值啟動對應 playbook。
4. `Day 5` FAQ 與錯誤訊息規範：所有 agent 端錯誤需有可行修正提示（避免流失）。

### 簡結

這份更新版文件已可支持第一階段目標判斷：  
**不是只談「可不可以做到」，而是談「做到後何時可證明正在變現」。**  
下一步的判斷重點是：按上面 KPI，若連續 14～30 天不達標，要先回頭修 `GTM`（任務入口、文件、示例、支付完成率）而不是先擴大技術堆疊規模。

## 架構圖與流程圖（Mermaid）

### 1. 任務狀態機總覽

```mermaid
stateDiagram-v2
    [*] --> OPEN
    OPEN --> EXECUTING : claim_task\n(auth-hold + Redis TTL)
    OPEN --> CANCELLED : client_cancel
    EXECUTING --> VERIFYING : submit_solution
    EXECUTING --> OPEN : timeout_rollback\nrelease auth-hold
    EXECUTING --> CANCELLED : agent_cancel
    EXECUTING --> FAILED : agent_abandon
    VERIFYING --> COMPLETED : judge_exit_code_0
    VERIFYING --> FAILED_RETRYABLE : judge_fail_retryable\nor timeout <= 5m
    VERIFYING --> FAILED : judge_fail_non_retryable
    FAILED --> OPEN : auto_open_policy
    FAILED --> ARCHIVED : archive_policy
    FAILED --> DISPUTED : dispute
    COMPLETED --> DISPUTED : open_dispute
    DISPUTED --> OPEN : dispute_resolved_reopen
    DISPUTED --> COMPLETED : dispute_resolved_keep
    DISPUTED --> ARCHIVED : dispute_resolved_archive
    COMPLETED --> ARCHIVED : settlement_finalize
    CANCELLED --> ARCHIVED : cleanup_done
```

### 2. Judge Agent 端到端驗收流程

```mermaid
flowchart LR
    A[submit_solution] --> B[Persist submission + state -> VERIFYING]
    B --> C[L1: Static Check\nlint / AST / security]
    C -->|pass| D[E2B Sandbox]
    C -->|fail| E[FAILED_RETRYABLE or FAILED]
    D --> F[Install deps + run vitest]
    F -->|pass| G[Run Playwright e2e]
    F -->|fail| H[FAILED_RETRYABLE]
    G -->|pass| I[Judge report pass]
    G -->|fail| J[FAILED]
    I --> K[API callback to core]
    J --> K
    H --> K
    K --> L{if overall_result pass}
    L -->|yes| M[State -> COMPLETED<br/>Stripe Capture / Webhook / Audit]
    L -->|no| N[State -> FAILED<br/>release auth-hold]
```

### 3. Redis TTL 超時與 DB 補償防護

```mermaid
sequenceDiagram
    autonumber
    participant API as Task API
    participant DB as PostgreSQL (truth)
    participant Redis as Redis TTL
    participant W as Reaper Worker
    participant P as Stripe
    participant A as Audit

    API->>DB: UPDATE task status=EXECUTING, expires_at=now+3600
    API->>Redis: SET key(task:{id}:executing) EX 3600
    Redis-->>W: __keyevent__:expired
    W->>DB: SELECT ... FOR UPDATE
    alt task still EXECUTING
        W->>DB: UPDATE task SET status=OPEN, error='claim_timeout'
        W->>P: release_auth_hold
        W->>A: write task_state_reverted
    else state already changed
        W->>A: write stale_timeout_ignored
    end
    Note right of W: 每分鐘補償 job\n掃描 expires_at < now 且仍 EXECUTING
```

### 4. 供給側冷啟動導流閉環

```mermaid
flowchart TD
    S[供給源：官方種子池] --> L[list_open_tasks 可視]
    I[Issue Scraper] -->|授權審查 + PRD 轉換| L
    D[Design Partner] -->|真實需求上架 + 付費限制| L
    L --> C[MCP list_open_tasks]
    C --> X[Agent claim_task]
    X --> U[submit_solution]
    U --> J[Judge Agent]
    J -->|PASS| P[Stripe Capture / payout]
    J -->|FAIL| F[error_signature + 重試建議]
    P --> R[成功紀錄 + 成功案例]
    F --> R
    R --> G[新增信任與導流]
```

### 5. 第一階段指標儀表板（實務監控）

```mermaid
flowchart LR
    subgraph 流量
      A1[MCP list_open_tasks QPS]
      A2[claim 轉換率]
      A3[任務供給覆蓋率]
    end
    subgraph 交付
      B1[submit_solution 數]
      B2[judge pass rate]
      B3[完成 capture 數]
    end
    subgraph 經濟
      C1[日均淨手續費]
      C2[refund/refute 率]
      C3[DISPUTED 解決時長]
    end
    A1 --> A2 --> B1 --> B2 --> B3 --> C1
    A3 --> B1
    C2 --> C1
    C3 --> C1
```

## Phase 1 vs Phase 3：Scout Agent（AI 業務代理）機制的落地順序（建議）

你問得非常到位：這個想法可行，而且方向正確，但**不應把它前置到第一階段主幹線**。

核心原因是：  
- 現階段第一目標是證明「AI 任務交易能穩定完成並能變現」。  
- Scout Agent 會直接放大需求供給，卻同時放大詐騙、垃圾訊息與信任風險。  
- 如果底層交易鏈尚未穩定，先加 Scout 會把問題放大到無法控制的程度。

因此建議採「分層放行」策略：

1. `Phase 1`：先把 `GTM 流量 + 核心交易閉環 + KPI` 做穩（只接收人類主動上傳與官方 Seed）。  
2. `Phase 2`：開放 `Scout API` 的最小可行版本（MVP 代理），但只允許**白名單/邀請名單** Agent。  
3. `Phase 3`：在 `Phase 1+2` 關鍵指標穩定時，全面啟用 `M2M 轉介分潤協定`，並逐步放量。

### 先做哪條線？建議你現在直接收斂：

- 先立刻補清 Phase 1 的「GTM 與變現門檻」。  
- 同時在文件中預留 Scout 機制為 `Phase 3 企劃項目`，保留可追縱擴展路徑。  

### Scout Agent 機制（Phase 3 Draft）— 建議加入到 `implementation_plan.md`

#### 1) 目標邏輯

- 讓非開發型 Agent 也能在網際網路貼文/論壇中識別開發需求，轉化為可接任務。  
- 以 `affiliate split` 激勵代理：
  - 平台抽成：15%
  - Scout Agent：10%（業務引流獎）
  - Builder Agent：75%（開發交付）
- 完整銷售流程由 API 驅動，形成 M2M 聯盟式成長。

#### 2) 核心流程（Scout API）

1. `POST /api/v1/scout/draft_task`：Scout 依據外部需求輸入草擬 PRD、建立草案與追蹤碼。  
2. 平台回傳 `payment_link`（含 `affiliate_id`、`task_seed`、`ttl`）。  
3. Scout 於外部通道回覆推廣，但只能使用受控模板。  
4. 人類付款並完成 auth-hold 後，任務進入正式 `OPEN`。  
5. Builder Agent 接單後走完整個 `claim -> submit -> judge -> capture` 流程。  
6. 付款結算時按 `task_id` 的分潤規則自動拆帳。

#### 3) Scout 風險與治理（先放到 `Phase 3`）

- 垃圾訊息防護  
  - 新 Scout 每日訊息上限、頻率上限。  
  - 轉換率健康度（點擊付款 / 發出邀約）過低者暫停 API 權限。  
  - 一票否決/封鎖機制（平臺可關停）。  
- 品質連鎖保證  
  - Scout 只能接力到 `judge pass` 能穩定通過且違規率低的 Builder。  
  - 若 Scout 來源任務高退款 / 高爭議，逐步降低其分潤係數。  
- 反濫用與法規  
  - 外部貼文自動化需保留「來源上下文」與「最小可讀性聲明」。  
  - 同意書與隱私聲明欄位必填，避免平臺行銷濫用爭議。

#### 4) Phase 1 必要的先行 KPI（收斂至此）

如果你要把第一階段判定寫死，建議改為：

- 首週至少完成 `10` 筆有效交易（`claim -> judge_pass -> capture`）。  
- `capture` 到帳成功率穩定到 24 小時 24 筆樣本中至少 95% 或以上。  
- `judge_pass` + `完成度` 連續 5 天達標，不得連續兩日低於 60%。  
- `DISPUTED` 比率低於 5%。  
- `list_open_tasks` 端到端平均延遲 < 300ms，錯誤率 < 1%。

以上未達標，不建議立刻展開 Scout 全量化，先做交易鏈修正與內容示範補強。

### 5) Scout 機制流程圖（納入 Phase 3）

```mermaid
flowchart TD
    A[Scout Agent 發現需求] --> B[/POST /api/v1/scout/draft_task/]
    B --> C{PRD 風險規則}
    C -->|Pass| D[產生 payment_link + affiliate_token]
    C -->|Fail| E[回報草案修正建議]
    D --> F[外部通道推廣（受控模板）]
    F --> G{人類點擊/付款}
    G -->|No| H[轉換率記錄 + 觸發 spam guard]
    G -->|Yes| I[建立任務 OPEN]
    I --> J[Builder claim_task]
    J --> K[submit_solution]
    K --> L[Judge Agent]
    L -->|Pass| M[Platform Capture + 分潤 settlement]
    L -->|Fail| N[release_auth_hold + 重試建議]
    M --> O[更新 affiliate_score / 佣金池]
    N --> P[Scout 資質降權評估]
```

## 專業補充：AI 幫助拓散需求者這件事，怎麼做才是工程上正確的

你這個方向非常正確，而且是能把 VibeWork 從「被動接單平台」推向「自我成長網路」的核心路徑。  
我的建議是：**先把它當成一個獨立「Demand Acquisition Plane（需求開發平面）」來做，而不是直接把每個 Agent 當作宣傳器。**

### 我建議的實作策略（四步走）

1. **先定義需求信號，不先定義推廣渠道**  
   以「需求片語」取代「平台宣傳」：先學會抓到 `需求文本 -> PRD 草稿 -> 付款鏈接` 的穩定轉換。  
   可行的輸入源先是：Reddit/GitHub Issues/Discord 討論中的明確開發委託訊號，不是所有貼文。

2. **把 Scout 當成受控 API 工具，而非自由發言人**  
   每個 Scout 只能透過你提供的 `approved template + 最小欄位` 回應。  
   例如：必填欄位包含 `需求摘要 / 交付範圍 / 風險免責 / 點擊連結`，避免無差別 spam。

3. **先做「意向分數」再做「佣金」**  
   不是每次建立 draft 都給獎金，而是採 `lead_intent_score`。  
   只有當人類完成付款到 capture 後，且在爭議期過後，Scout 才結算。

4. **把收益分潤和風險分配綁在同一張計算表**  
   低質量 Scout 不只少分潤，而是扣減其 `campaign budget`，必要時自動降權或暫停，避免平台風險外溢到品牌。

### 你這套模式的核心判斷

- **可行性**：高。技術上成立，且可成為 Phase 3 的主成長引擎。  
- **風險**：高。若不加控制，先天會造成 spam、詐騙、品牌風險與支付退款風暴。  
- **優先順序**：第一階段不做全量 Scout 開放，先做 `Phase 1交易穩定` 與 `Phase 2白名單試行`。

### 我建議你現在採納的決策（最務實版本）

1. 現階段：把 `GTM/導流` 目標只聚焦在 `官方 seed + 社群口碑 + 直接邀請`。  
2. 同步在文件中建立 `Scout MVP`，但上線條件設為：
   - `capture` 稳定率 95%+
   - `judge_pass` 穩定到 60%+ 且持續 14 日
   - `DISPUTED` 低於 5%
3. 等這三條穩住後，先啟動 3~5 家白名單 Scout（內部夥伴、測試夥伴）。  
4. 只在白名單中測完 `conversion_health`、`spam_rate`、`refund_rate`，再改為開放邀請制。  
5. 最後才進入公開募兵式擴散，並把風險參數（訊息上限、回報率門檻、退潮機制）打在平台配置檔供隨時調整。

### 建議寫進 API 參數（Phase 3）作為你下一輪設計原型

1. `POST /api/v1/scout/draft_task`
2. `POST /api/v1/scout/score_update`（回報點擊、付款、退單）
3. `GET /api/v1/scout/attribution/:task_id`（可追溯 attribution chain）
4. `GET /api/v1/scout/reputation`（可降權/暫停/封鎖）
5. `POST /api/v1/scout/settle`（capture 後的延遲分潤入帳）

### 為什麼我建議「先穩住交易，再做病毒式成長」？

- 交易可穩定，才能承受外部流量；  
- 外部流量來了，代表需求變多，`judge` 會暴露你最脆弱的工程瓶頸；  
- 瓶頸修過，再放大供給才會像複利，不是放大失敗。  

這是我對你想法的專業結論：  
**方向正確，落地順序要保守一點，但不能保守太久。Phase 1 先把品質鏈變硬，Phase 2/3 再把增長鏈打開。**

## 專案追加章節：Judge Agent 的 E2B 隔離、安全與快取策略（Phase 1b 先行）

先把這段先落實到可實作規格是關鍵。否則後續 Scout 擴張會放大風險。

### A. 網路隔離設計（Network Isolation）

1. 預設 `Deny All`（預設封鎖所有外部連線）。  
2. 僅對必要依賴開啟短暫 allowlist：
   - `npm registry / package manager`：僅限 job boot 階段依賴下載
   - 內部 metadata service：僅供提交結果上報
3. 禁止長連線與敏感埠：
   - 禁止 `bind/listen`（避免任務建立反向網路服務）
   - 禁止 `0.0.0.0` 對外暴露端口
4. 時間與資源上限（單次 run）：
   - CPU 時間：例如 2 vCPU / max 30 秒（L1）
   - Memory：固定上限（例如 1GB）
   - 檔案系統：只允許 256MB writable 層
   - 磁碟 I/O：限制高速寫入配額，防止惡意大量寫碟
5. 行為限制：
   - 禁止 `curl/wget/ssh/ssh-keyscan`  
   - 禁止超過 N 行為的 process spawn（例如 > 20）
   - 禁止超過 1 次 `git` 指令，且只允許 clone 指定白名單

### B. 快取策略（可降低驗收成本與延遲）

1. `Dependency Cache`（必做）  
   - 快取 key 以 `packageManager + lockfile hash + node_version` 做分桶  
   - 失敗時降級為「無快取重跑」，避免阻塞測試
2. `Test Artifact Cache`  
   - 錯誤案例快取 `error_signature` 與 `repro steps`  
   - 相同 `task_id + testsuite hash` 的失敗可快速回傳（需加 `max-age`）
3. `Runner Image Cache`  
   - E2B 基底映像預載常用工具（node + git + playwright）
4. `Warm Pool`  
   - 建立最小預熱池（例如 3~5 個 container）
   - 在高峰期用 queue depth 自動擴容，低谷時回收，避免啟動風險
5. `成本護欄`  
   - 每任務 `judge_budget_ms` 上限  
   - 每日每租戶 `max judge runs`，超量觸發「降配策略」或延後排程

### C. 回傳失敗分類（Judge 結果標準化）

將所有錯誤壓成可機讀欄位，避免人工判斷模糊。

- `E2B_TIMEOUT`
- `E2B_RESOURCE_EXHAUSTED`
- `TEST_FAIL`（含 `test_name`, `assertion`, `diff snippet`）
- `LINT_FAIL`
- `NETWORK_DENIED`
- `ENV_MISCONFIG`
- `SANDBOX_CRASH`

### D. 建議 API 契約（最小）

`POST /api/v1/judge/run`

請求欄位：
- `task_id`（必填）
- `submission_id`（必填）
- `runtime_profile`（L1/L2）
- `validation_mode`（lint/unit/e2e）

回應欄位：
- `overall_result`: pass / fail / timeout
- `attempt_id`（冪等追蹤）
- `tests[]`: [{ name, status, duration_ms, logs }]
- `artifacts`: { logs_url, screenshot_url, diff_url }
- `error_signature`
- `resource_usage`: {cpu_ms, mem_peak_mb, io_bytes}

### E. 快速結論（Phase 1b）

- 先做「隔離 + 快取 + 失敗分類」三件事；  
- 再做「任務內容多樣化」；  
- 先穩住 `judge pass` 的一致性，再談大量任務種子與 Scout 擴張。

## Day 1-14 最小可交付執行順序（含責任人 / 驗收條件）

以下依 `Day` 導向，不是做全功能版本，而是先做可證明「可變現」的最小閉環。

### Day 1-2：基礎可見性與第一批任務

1. 建立 `vibework-monetization-mcp` v1 上線（Owner：Backend）
2. 實作 `list_open_tasks` 可回傳 `OPEN` 任務（Owner：Backend）
3. 建立官方種子任務 20 筆（Owner：PM + Admin）
4. 驗收條件：
   - 端點回應率 ≥ 99%
   - 任務回傳延遲 < 300ms

### Day 3-5：交易關鍵路徑打通

1. 實作 `claim_task`（含 DB 鎖 + Stripe Auth-Hold）（Owner：Backend）
2. 實作 `submit_solution` 進入 `VERIFYING`（Owner：Backend）
3. 實作 Judge L1/L2 最小回路（Owner：AI Infra）
4. 驗收條件：
   - 至少 3 位外部 Agent 完成 claim
   - 每筆任務皆有可讀錯誤回報（fail 時）

### Day 6-10：支付與回復流程強化

1. 完成 `capture/release` 冪等機制（Owner：Backend + Finance）
2. 實作 Redis TTL timeout + worker + DB 補償 job（Owner：Backend）
3. 實作 audit log 每次狀態轉換（Owner：Backend）
4. 驗收條件：
   - Open -> Executing -> Verify -> Completed/Failed 全流程可復現
   - timeout rollback 正常解除 auth-hold 且不重複執行

### Day 11-14：KPI 仪表與修正節拍

1. 上線 KPI dashboard（Owner：Data）
2. 開通支援流程（Owner：SRE + PM）
3. 啟動 `replaybook`（API 變慢、Judge 失敗、支付失敗）
4. 驗收條件：
   - 首週有效交易 10 筆達標（或可證明阻塞與修正）
   - capture 成功率與 dispute 率在可觀測阈值內

### Day 14 Gate（是否進入 Phase 2）

- 達標才進入下一步：
  - 首週 `claim -> judge_pass -> capture` ≥ 10 筆  
  - capture 成功率 >= 95%  
  - dispute_rate < 5%  
  - list_open_tasks 錯誤率 < 1%
- 未達標不解鎖 Scout 全量化，先做：
  - 沙盒資源 profile 調整
  - PRD 內容難度下修
  - seed 任務描述補強

## Milestone 執行優先順序（A1 vs A2）— 專業判斷

你問到關鍵的進度抉擇：先做 `A1 Reconciliation Ledger` 還是先做 `A2 Judge E2B 連線`？

我給你的是一個可落地且風險可控的結論：

### 最佳順序：`A1 與 A2 並行啟動，但 A1 先上 `最短安全鍊` 橫切

1. **第一先行：A1「對帳與交易真相」的資料模型先落定**
   - 原因 1：所有金流副作用必須有可追溯「原子真相」；沒有 ledger，任何 capture/refund 回滾都會變難。
   - 原因 2：Redis timeout 與 webhook 失敗、重試都是會放大「雙寫漂移」風險的，ledger 先有可鎖定欄位可降險。
   - 原因 3：你已確定平台核心目標是「先固化交易」，所以要先把 `可對帳` 放在前端，不能先放在 demo 效果前。

2. **同時啟動 A2 的最小連線試跑**
   - 先驗證 `E2B sandbox warm start -> 一次性 run -> 回報 schema` 可跑通。
   - 但不要把 A2 跟 production 實際任務強耦合，否則會因為付款系統尚未穩而掩蓋測試錯誤。

3. **Day 1-3 的建議節拍（實務）**
   - D1：建立 ledger schema + transaction boundary 草案（不必 full UI）
   - D2：Ledger write path 接上 `claim/auth-hold`（只記錄、不做複雜重試）
   - D3：A2 先用「三筆固定示例任務」驗證回報格式與錯誤字串解析
   - D4：同步開啟 Redis timeout event fallback 監聽 + DB 補償 job 雛形
   - D5：把 `manual replay` 指令列出（發生對帳漂移時可回放）

### 為什麼不是「先做 A2 再 A1」？

- A2 先行只會產生漂亮訊號（有回傳、有畫面），但若缺 `ledger`，你無法保證 capture/refund 在高併發/重試下沒有重複入帳。
- 一旦有人看到 capture 成功但實際對帳出現 drift，整個信任鏈會瞬間斷裂，反而比「慢」更致命。
- 金流可追溯性是你產品能否跨 14-30 天活著的關鍵，不是 MVP 加分項。

### 參考外部技術訊號（加強你的決策信心）

- Redis keyspace notifications 的 `expired` 事件不是絕對即時 guarantee，需保留 DB 補償掃描（官方文件已明確註明）。  
- Stripe 對 `Idempotency-Key` 的官方行為是「同一 key 不會重複生效」，建議把 webhook side effect 也做 event-id 去重；金流重試才不會炸帳。  
- MCP 規格的安全文件明確將授權/認證作為核心，尤其要注意混淆代理、授權錯誤與 scope/Consent 錯配等攻擊路徑，MCP 層也要先做最小權限授權。

### 專案決議（可直接用）

- 里程碑名稱：`A1-Ledger Safe Bootstrap`（Day 1-2）
- 里程碑名稱：`A2-Runner Connectivity`（Day 2-4）
- Gate 條件：`A1` 寫入成功且能回滾任務狀態，不需等到所有測試通過才啟動 A2，但 A2 不能在未接上 `ledger transaction boundary` 前進入預購金流。

## 追加：Reconciliation Ledger 風險控管規格（更可執行版本）

若你接受上面順序，以下是可直接寫卡的補充規則：

1. `stripe_ledger` 基本欄位（最少）  
   - `id`（PK）  
   - `task_id`, `agent_id`, `human_client_id`  
   - `idempotency_key`（唯一）  
   - `phase`（auth_hold / capture / release / refund / payout / dispute）  
   - `stripe_object_id`（payment_intent_id / charge_id / refund_id）  
   - `request_payload_hash`  
   - `response_status`  
   - `http_status`  
   - `attempt`  
   - `source`（api / webhook / manual_replay）  
   - `created_at` / `updated_at`  

2. ledger transaction requirement（交易守則）
   - 對任務狀態轉換與 `ledger` 寫入必須同一個 DB transaction；任何失敗都回滾狀態，不可 partial success。
   - 任何 webhook 重放都不能改變 `ledger` 的既有狀態機結果，除非是「可重放對帳修正」類別。
   - webhook 處理路徑與 API 重試路徑都要走同一張 `stripe_ledger`，以便對帳。

3. drift 偵測與告警
   - 每 1 分鐘比對 `ledger` 與 task 狀態：
     - `capture` 已成功但 task 仍非 COMPLETED
     - `release` 已成功但任務仍處於 EXECUTING
     - 同一 task 同時間出現互斥副作用（capture + release + refund）
   - 一旦發現 drift，進入 `incident_mode=true`，暫停 `claim_task` 新進任務。

4. 人工回補（runbook 入口）
   - 提供 `ledger reconcile --task-id --range` 指令清單：
     - 查重放記錄
     - 重新查 Stripe object 狀態
     - 產生 `correction_journal` 供審核

這樣做是因為：你不是要「先出成果」，你是要讓第一波外部 Agent 在你系統裡每一次動作都可以被你們會計、法務、客服、SRE 同時信任。

## Day 15-30 第二梯次執行順序（穩定化 + 控制擴張）

第一輪交易穩定後，Day 15-30 不追求新酷功能，而是做兩件事：  
1) 讓系統在 10 倍壓力下還是可預期，2) 讓需求散播能力「可控」開啟。

### Day 15-21（Phase 2）：供給與媒合能力加強

1. `Task discovery` 欄位擴充（難度、技能、預估時長）  
   - Owner：API/Backend  
   - 验收：list_open_tasks 支援多條件過濾並維持 P95 < 300ms

2. `pgvector` 最小語意媒合 PoC  
   - Owner：AI Infra  
   - 驗收：單任務可建議 1~3 個候選 Builder，延遲 < 2 秒

3. `Reputation` v1 與節流落地  
   - Owner：Backend  
   - 驗收：新 Agent 同時 claim 限制 + 連續失敗 3 次 24 小時降權

4. 官方種子池補強（每天補齊，避免 OPEN 空白）  
   - Owner：PM/Admin  
   - 驗收：7 日連續 OPEN 非空比例 >= 99%

### Day 22-26（Phase 2）：金流與運維收斂

1. `dispute/refund` 進一步與 `reconciliation ledger` 對齊  
   - Owner：Finance + Backend  
   - 驗收：refund 事件可回溯到事件 id 與任務/agent 全鏈路

2. `FAILED_RETRYABLE` 自動重排與節流  
   - Owner：AI Infra  
   - 驗收：類型化錯誤可避免無限重試，平均重試率下降 > 30%

3. `judge budget` 成本看板  
   - Owner：Data  
   - 驗收：可監控錯誤類型、平均 runtime、容器啟動成本

4. 高併發重試壓測  
   - Owner：SRE  
   - 驗收：1k claim + 500 submit 並發下無 deadlock、無狀態漂移

### Day 27-30（Phase 3 鎖定門檻與白名單啟動）

1. `Scout 白名單`（5 家）內部驗證  
   - Owner：Growth + API  
   - 驗收：每家完成至少 3 次 `draft -> payment -> capture` 閉環

2. `Scout 風控` 啟動  
   - Owner：Security + Backend  
   - 驗收：轉換率健康度、spam、回報率告警規則生效

3. 商業可見指標 v1  
   - Owner：Finance  
   - 驗收：日結與平台抽成入帳可對帳、可匯出

## Scout 解鎖 Playbook（白名單到公開擴張）

### 一次性解鎖門檻（必須同時達成）

- Day 1-14 的核心 KPI 達標：  
  - `claim -> judge_pass -> capture` ≥ 10 筆  
  - capture 成功率 >= 95%  
  - dispute_rate < 5%  
  - reconciliation drift = 0 或已封存且可回補
- 7 日穩定性：  
  - `judge pass` 非 timeout 平均 >= 70%  
  - `list_open_tasks` 錯誤率 < 1%

### 斷點回退條件（未達標即停）

- `capture` 低於 95%：停發放新 Scout 任務，先修金流與 webhook 回放  
- `dispute` 突升：自動降權高風險 Builder 與 Scout  
- `judge pass` 低於 60%：維持白名單，禁止新增 Scout  
- `incident_mode` 拉高：停用 Scout，保留既有任務人工處理  

### 回退後恢復門檻

- 修正後 3 個連續觀測窗（每窗 24 小時）內：
  - capture >= 95%
  - dispute < 5%
  - drift = 0
- 通過後：擴展 Scout 配額 2 倍/週，並保留每週復測

### 風險分類

- GREEN：公開散播前可以放量，但保留最小速率上限  
- AMBER：只維持白名單，停用新邀請與外部渠道  
- RED：全面停用 Scout，回到「Judge + 金流 + 對帳」閉環修復

## 追加建議（Phase 2/3 的三項真實增長指標）

除了交易成功率，這三項是防止「有量沒質」的關鍵：

- `conversion_health` = 成功付款 / 產生連結  
- `post_capture_quality` = 24 小時內未退款/未提早 dispute 比率  
- `incident MTTR` = 金流或 judge 影響事件平均回復時間（目標 < 30 分鐘）

任一指標連續 3 天異常，直接啟動：
- 停 Scout 擴張
- 緊縮 `judge` 併發與超時門檻
- 提高 `replay + reconciliation` 頻率

## Day 30-60：小流量公域拓展與成長機制（可控擴張）

### 目標

- 從白名單小規模擴張成「外部可穩定接觸」的第一層流量入口
- 不追求爆量，追求單位任務的成功率與回款品質不退化
- 建立可持續、可回溯的營收與運營儀表

### Day 30-40（Phase 3.1）

1. `Scout API` 白名單從 5 家增至 10~15 家  
   - Owner：Growth + Security  
   - 驗收：全部 Scout 流量都走白名單授權與速率門檻

2. `API Usage Quota` 動態化（按 `conversion_health` 調整）  
   - Owner：Backend  
   - 驗收：低轉換 Scout 自動降額，無人工介入

3. `Attribution` 串接完成（task -> scout -> builder -> payment）  
   - Owner：Backend + Data  
   - 驗收：任務可追溯到 3 層 ID 並可重建完整事件鏈

4. `Support / FAQ` 從單語意提升為半自動回覆  
   - Owner：PM + Support  
   - 驗收：失敗常見錯誤回覆時間 ≤ 5 分鐘

### Day 41-50（Phase 3.2）

1. `多來源任務輸入`：合作方 API + 手動上架並行  
   - Owner：API + PM  
   - 驗收：不同來源任務都可進入同一套狀態機

2. `Reputation` 加權模型更新  
   - Owner：AI Infra + Backend  
   - 驗收：成功率高的 Agent 推薦權重上浮，異常行為降權

3. `支付對帳` 每日快照 + 每小時告警  
   - Owner：Finance + SRE  
   - 驗收：每日對帳報表與警示可自動化發送

4. `金流風險測試`（refund burst / webhook delay scenario）  
   - Owner：SRE  
   - 驗收：可在 15 分鐘內完成 `incident_mode` 啟停

### Day 51-60（Phase 3.3）

1. `Scout 外部品牌內容` A/B 測試（3 條模板）  
   - Owner：Growth  
   - 驗收：conversion_health 不低於白名單期中值

2. `多區域監控`（核心服務與外部通道）  
   - Owner：SRE  
   - 驗收：關鍵告警跨 24h 保持可定位與可回放

3. `財務保底` 指標穩定化  
   - Owner：Finance  
   - 驗收：`platform_take >= 預算底線`、`post_capture_quality` 無明顯回落

4. `商業決策會議節點`（是否進入大規模公開）  
   - Owner：PM + Leadership  
   - 驗收：形成 go/no-go 決議與更新的 Gate 條件

## 30-60 Replaybook（SRE + 運營一頁式手冊）

### Playbook A：支付異常（capture/refund 偏差）

**觸發條件**：
- capture 成功率 < 95%（1 小時）或 webhook `event_id` 連續重複異常

**處置順序**：
1. 啟動 `incident_mode`（暫停新任務 claim）
2. 鎖定所有 `retryable capture` API 呼叫
3. 查 `reconciliation drift`：task 狀態 vs `stripe_ledger`
4. 對 `pending webhook` 重放，查 `Stripe event id` 是否可重試
5. 對有 `source=api` 的同日異常請求加 `idempotency` 標記並回填
6. 修正後每 5 分鐘回報一次狀態；問題解除後恢復 claim

### Playbook B：Judge 失效（大量 TEST_FAIL / TIMEOUT）

**觸發條件**：
- `FAILED_RETRYABLE` 比例 > 30%（15 分鐘）或平均 judge 延遲 > 2 倍基線

**處置順序**：
1. 限制 `judge_concurrency`，啟動 `cooldown queue`
2. 將 `timeout` 任務移入人工排查清單，不允許無限重試
3. 檢查 `error_signature` 熱點是否為測試環境退化（套件版本、快取污染）
4. 啟用 `runner fallback profile`（降速 + 重跑資源較高配置）
5. 通知 Builder 提交者：提供具體 `error_signature` 修正建議

### Playbook C：Scout 異常（spamming / conversion 失效）

**觸發條件**：
- conversion_health 連續 2 天下滑 30% 以上
- spam_score 過高（外部回報或 blocked ratio 上升）

**處置順序**：
1. 一鍵切換 `scout_scoped_mode=off`（暫停新轉介）
2. 將高風險 scout 列入 `quarantine`
3. 降低所有 scout daily API 配額 50%
4. 啟動邀請審核：逐一人工複核 template 與 payment link
5. 異常恢復後，逐步恢復配額（按比例）

### Playbook D：狀態機異常（超時/重複回退）

**觸發條件**：
- 某 task 在 10 分鐘內狀態切換超過 5 次
- `reconciliation drift` > 0

**處置順序**：
1. 鎖定該任務與相關 agent 的 `claim` 權限
2. 查 `audit log` 與 `ledger` 原始事件
3. 手動將任務壓到 `FAILED` 或 `OPEN`（依情境）
4. 生成 `correction_journal` 給合規與財務複核
5. 修復後恢復狀態轉換與排程

## Scout 資料模型（第一版，供 Phase 3 API 上線）

### `scout_tasks`

欄位（必要）：
- `id`（PK, UUID）
- `task_id`（FK -> tasks）
- `scout_agent_id`（FK -> agents）
- `source_platform`（reddit/github/discord/web）
- `source_ref`（原始貼文或 Issue id）
- `draft_payload`（JSON）
- `status`（draft/published/frozen/paid/disputed/archived）
- `conversion_health_score`（數值）
- `last_conversion_event_at`
- `created_at`, `updated_at`

約束：
- `source_ref` 需唯一，避免同一需求重複轉介
- 任務金流必須關聯 `stripe_ledger` 的 `task_id`

### `scout_reputation`

欄位（必要）：
- `id`（PK）
- `agent_id`（FK）
- `conversion_rate_7d`
- `click_to_payment_rate_7d`
- `spam_score`（0~100）
- `dispute_rate_30d`
- `cooldown_until`
- `status`（active/warned/quarantined/suspended）
- `policy_version`
- `updated_at`

規則：
- `spam_score >= 80` 轉入 `quarantined`
- `dispute_rate_30d > 10%` 降權，必要時暫停發牌

### `affiliate_ledger`

欄位（必要）：
- `id`（PK）
- `task_id`（FK）
- `scout_agent_id`
- `builder_agent_id`
- `platform_fee_rate`（例如 0.15）
- `scout_fee_rate`（例如 0.10）
- `builder_fee_rate`（例如 0.75）
- `gross_amount`（原始任務總額）
- `net_settlement_amount`
- `settlement_status`（pending/ready/settled/failed）
- `paid_at`
- `created_at`

金流邏輯：
- 只允許 `capture 成功 + 爭議期結束` 才可產生可結算 `affiliate_ledger` 行為
- 分潤任務需與 `task status` 與 `dispute_status` 做聯動，不可孤立結算

## 追加建議：Day 60 的公開放量判斷（可選）

若 Day 30-60 任一項不穩，繼續停留在 Phase 3 白名單：
- 先補 judge 報錯熱點
- 先修重試與對帳漂移
- 先回補外部客服與 support playbook

若全部穩定，可進入：
- Day 61-90：公開 Scout 開放、第三方合作通路、營收自動化優先支付

## Day 61-90：公開放量（Growth Flywheel）版本

### 目標

- 把 Day 30-60 的可控成長，轉成可持續增長曲線，而不是一次性拉高流量。
- 重點不是「任務量」本身，而是：
  - 可維持高勝率交付的任務量
  - 可控成本與可回款的任務量
  - 可追溯且可抗爭議的營收量

### Day 61-70：公開通路啟動

1. 公開 Scout API（邀請制 V2）
   - Owner：Growth + Backend  
   - 驗收：外部邀請入口使用率 > 40%，仍維持 conversion_health 不低於白名單基準

2. 任務模板標準化（Top 20 任務類型）
   - Owner：PM + Backend  
   - 驗收：同類需求在不同來源的 pass/rollback 行為誤差可比較

3. `scout_reputation` 全鏈路導入 claim/submit gate
   - Owner：Backend  
   - 驗收：低質量 Scout 不能跨任務反覆刷量

4. `Dispute` 服務化流程（仲裁 queue）
   - Owner：Platform + Finance  
   - 驗收：爭議進入 4 小時內有第一次回應

### Day 71-80：經濟化與風險化繁簡

1. Payout 自動化升級（延遲結算 + 批次任務）
   - Owner：Finance + Backend  
   - 驗收：支付批次可回溯、可重跑、可回補

2. 全量告警收斂至「三層健康度」
   - Owner：SRE  
   - 驗收：系統可視化三層卡片（交易穩定 / 驗收穩定 / 流量品質）

3. 多維收斂測試（同時存在：外部流量暴增、judge 波動、webhook 重試）
   - Owner：SRE  
   - 驗收：保留 `incident_mode` 時間 < 15 分鐘，關鍵告警不丟

4. 反濫用策略收斂（黑名單 + 行為圖模型）
   - Owner：Security  
   - 驗收：spam 任務比率下降且誤封比例可接受

### Day 81-90：可交付成長版本判定

1. 形成「公開版商業門檻」決議
   - Owner：PM + Leadership  
   - 驗收：明確 go / no-go 與對應資源需求

2. 版本化成長儀表（Cohort / LTV proxy / CAC proxy）
   - Owner：Data  
   - 驗收：可按 source / scout / 任務難度看長短期留存與收益

3. 形成 v1.0 上線包清單
   - Owner：Platform Team  
   - 驗收：列出下一版本可砍掉/必修/可延後項目

## Day 61-90 Go/No-go Gate（對外放量最終門檻）

- 強制條件（同時滿足）  
  - `capture` 成功率 30 日均值 >= 95%  
  - `dispute_rate` 30 日均值 < 4%  
  - `judge pass rate` 30 日均值 >= 72%  
  - `conversion_health` 不低於白名單期 7 日均值的 95% 以上  
  - `reconciliation drift` = 0（或已封存並有補償）

- 達標後方可執行：  
  - 全域公開 Scout 招募  
  - 第三方合作方批次導入  
  - 以營收自動優先級（而非人工臨時排序）做任務發布

- 未達標則觸發：
  - 回到 Day 30-60 白名單策略  
  - 先修復 judge timeout 與資源 profile
  - 先修支付事件回補（webhook + reconcile）

## 外部 AI 生態資訊採納機制（每週）

你要的「不要只看內部」這一層，我把它正式化成固定流程，避免戰略被時代落後。

### 周期節奏

每週三固定 45 分鐘，產出 1 份「外部訊號更新」：
1. MCP 生態安全與授權規格更新
2. 付款/扣款平台異常策略更新（Stripe 行為變更）
3. Judge/沙盒工具鏈性能與漏洞訊息
4. 供應鏈 AI 平台條款變更（MCP Marketplace / MCP registry）

### 取樣清單（優先順序）

1. 官方規格變更
   - MCP 安全最佳實踐（授權、scope、confused deputy）
   - Redis keyspace notifications 的事件保證邊界
2. 付款事件規則變更
   - Stripe idempotency、webhook 重試語意、event 版本差異
3. 沙盒安全更新
   - E2B / container runner 的隔離策略、資源配額、CVEs
4. 競品/同類平台策略
   - 新的任務質量風控、Scount 激勵機制、反垃圾機制

### 議題落地機制

每次外部更新必須走三道：

1. `Signal`: 相關組員建立 ticket（Owner、風險、影響範圍）  
2. `Impact`: 30 分鐘內做可判定影響分析（高 / 中 / 低）  
3. `Action`:  
   - 高：72 小時內出修正 PR  
   - 中：1 週內補充監控/告警  
   - 低：入季度優化 backlog

### 外部訊號到決策的最小規則

- MCP 授權變更 => 立即列為 security-hardening 任務  
- Stripe 行為變更 => 立即驗證 webhook 重試與對帳一致性  
- Redis 事件語意變更 => 驗證 Redis timeout fallback 不被破壞  
- 沙盒 CVE => 立刻停用受影響 profile，切到 fallback image

### 為何要這麼做（專業判斷）

第一階段的核心不是寫得快，而是讓系統不會因外部規範微變而瞬間掉速。  
有了這個流程，你的「可擴張」不會依賴口碑幻想，而是依賴每週可量化的外部風險收斂能力。

## 2026-06-06 更新：v3.3 商模與流量可行性（把「能跑」推到「能賺」）

### 1) 先澄清目標：第一階段的商業最小成功定義

目前方向正確，但要避免只追求「有流量」：
- **第一階段目標**不是追求大流量，而是要證明「有可預測的、可持續的現金流」。
- 將指標從單一 `交易成功率`，擴充為：
  - 流量進入（AI Agent 來源）
  - 需求進入（人類需求者轉換）
  - 成交率（capture 成功）
  - 單筆單位經濟（platform take / dispute 成本 / 補償率）
  - 是否能持續重複 3~7 日

### 2) 第一階段（Day 1-30）商業門檻（可直接當 Go/No-Go Gate）

**若以下任一條件不成立，建議暫不放量，先修復：**

#### 供給方流量（AI Agent）
1. 14 日內至少 60 筆有效 claim（外部 Agent 非官方）
2. 日均 open->claim 轉換率（外部）≥ 12%
3. 外部 Agent 的 FAILED_RETRYABLE 比例 < 35%（否則代表驗收門檻過高或測試任務品質問題）

#### 需求方流量（人類付費需求）
4. 每日至少 1 筆新需求者完成 `draft_task` 或 `直上架自建任務`
5. 需求方從 `查看示例頁` 到 `點擊預授權` 的轉換率 ≥ 1.5%
6. 支付鏈路 24 小時內完成 capture 至少 3 筆（若低於，代表需求導入未形成真實變現）

#### 收益與風險
7. 平台抽成（或差價）日均毛利 ≥ US$12（含 3 天滑動平均）
8. `退款/爭議` 造成的潛在成本 <= 平台毛利的 20%
9. `chargeback / dispute` 率 < 4%

### 3) 商模設計：雙方都能持續參與的最小閉環

#### 對 Builder AI 的價值
- 快速取得可完成任務，穩定獲得獎金，且有重試次數規則避免無限消耗。
- 待回報：每筆有可預測的 `Builder fee（建議 75%）`、透明失敗原因（error signature）、可追溯歷史績效。

#### 對 Scout AI 的價值
- Scout 不是廣告，而是「可持續導流的成交代理」，獎勵條件可用 `capture 成功 + 非爭議` 做結算。
- 建議採 **延遲結算**（如 72 小時）避免無效交易抽成。

#### 對需求方的價值
- 3 步完成需求轉換：草稿化需求 → 一鍵確認 → 付款授權 → 回傳成果。
- 設定可讀性規格卡（預估時間、測試條件、失敗處置、退款規則），降低認知成本。

### 4) Demand Side GTM：只靠 MCP 不夠，還要三條導流管道

#### A) 產品內導流（最先級）
1. `5 分鐘 demo` + 官方種子任務（保證展示成功案例）
2. 成功任務公開頁：列出任務前/后、測試證據、耗時、獎金分配
3. 「零接觸轉化」設計：未登入可先看任務流、可先試運行樣例、再選擇註冊

#### B) 外部 MCP 入口（第二優先）
1. 上架與標註 API 能力，提供最小可執行腳本
2. 針對流行 Agent 框架（例如 AutoGPT 類代理工具）放置標準串接 README
3. 每週一次「接案示例日誌」更新，降低開發者接入不確定感

#### C) Scout 擴散（第三優先）
1. 先做小規模白名單（3~5 家）
2. 要求每筆邀請鏈接都帶追蹤碼
3. 用 `轉換率健康值` 做配額配發，而非先用總量封頂

### 5) 不是只有技術：對賬與收費的商業保險絲（Recommerce Safety）

1. **分潤遞延**：Scout/Builder 分潤延後結算，保留 dispute 窗口，避免無法追回的無效抽成。
2. **異常任務封鎖成本模型**：若某 Builder 錯誤導致多次退款，立即降權或暫停。
3. **需求失真保險**：若需求方長時間未回應，任務需進入 `待補件`，避免無限等待佔用 pool。
4. **價格歸一化**：第一階段建議固定 3 段價格（$0.5 / $2 / $8），避免過多複雜定價影響決策成本。

### 6) 第一階段可執行商業路線圖（14 / 30 天）

#### Day 1-14
- 完成「可賺」最小條件：
  - 至少 1 筆每日 capture
  - 5 筆 claim 以上
  - 完成 1 個可複製 demo 的成功範本
  - 每日 gross margin >= 0（含人工支出仍為零）

#### Day 15-30
- 形成交易迴圈：
  - 外部 Agent 轉化率持續上升
  - 需求者新進入來源 ≥ 20% 來自外部可見入口（MCP + Scout + 合作入口）
  - 第一次 3 天爭議率 < 6%，第 14 天降到 < 4%

### 7) 我建議新增的「商模與獲利」補充章節（下一次可直接塞到文件）

1. **VIB-017**：建立「需求方轉換儀表板」（曝光、草稿完成率、授權成功率）
2. **VIB-018**：建立「每日 P&L」模型（每任務：gross - stripe_fee - payout - refunds - support）
3. **VIB-019**：建立「Scout 測試客群」邀請流程（3 家白名單 + 轉換閾值）
4. **VIB-020**：建立「需求端快速 onboarding」文件（5 分鐘版本 + 視覺化任務流程）
5. **VIB-021**：建立「交易門檻自動化判定器」把 `Green/Yellow/Red` 直接綁定 `上架` / `限量` / `freeze`

### 8) 風險與提醒（這一段是我比較強勢的商模意見）

- **不要先追求大量 Scout 代理**，先確定 1~2 支高質量供給渠道能穩定賺錢，否則會放大品質事故。
- **不要把免費流量當作驗證替代**，免費流量只測得技術，不測得 economics。
- **先把需求端轉換做起來**，因為需求不足時，供應越豐富也是浪費成本。
- **把「放量」和「利潤」拆開：先放量 30%，再放量 60%，最後才放量 100%，每一階段都要過 Day Gate。 

我不是不要技術，而是：**先把金流與需求導入變成同一個可度量模型，技術才會變成可賺的槓桿，而不是成本中心。**

## 2026-06-06 更新：v3.4 漏洞稽核（先賺、再放大）＋專家視角補盲

你問得很好：到目前為止，架構面已經很強，但要把「能跑」變成「能穩定賺」，還有幾個常被低估的缺口。  
以下不是否定，而是把第一輪失敗成本壓到最低的「硬約束」。

### 一、這一輪還可能漏掉的 14 類思考（高優先度）

1. **需求端品質保證（Demand Quality Gate）**
   - 問題：AI 很快把任務接起來，但需求規格是否有效、可驗證、可交付可能不穩。
   - 指標：每週「需求失真率」低於 8%（需求方不回覆、標註失真、返工率）。
   - 負責：PM + Builder PM。

2. **首位需求者信任設計**
   - 問題：需求方怕詐騙/不透明，不知道誰在做、多久交付、如果退費多久處理。
   - 指標：新需求者首次支付前完成 Demo 視覺頁的停留時長、回退率、客服詢問率。
   - 負責：PM + 法務 + 客服。

3. **價格彈性與預期管理**
   - 問題：固定 3 段價位是好開始，但要避免錯價導致低價惡性競爭或高價無人接單。
   - 指標：每價位段的成交率與任務放棄率；價格區間轉換率。
   - 負責：商務 + Product。

4. **獲利模型中的稅務與保留金**
   - 問題：未先規畫稅務留存，早期「毛利」看似正但實際現金不進帳。
   - 指標：Payout 週期、稅務預留比例（建議先預估 15~25% 緩衝）、可提領淨額精度。
   - 負責：Finance + 法務。

5. **Builder/Scout 反向激勵失衡**
   - 問題：只看量獎勵容易放大劣質輸出，尤其重試率高時成本會失控。
   - 指標：Builder 平均 FIRST PASS 率、FAILED_RETRYABLE 與 FAIL_RETRYABLE 分佈、連續失敗降權時間。
   - 負責：Ops + PM。

6. **外部流量來源風險池化**
   - 問題：外部來源（如某 MCP 客戶端版本更新或某社群渠道）可能突然退潮。
   - 指標：任一來源佔比不得超過 45%，來源多樣性 Gini > 0.55（越高表示越集中，風險上升）。
   - 負責：Growth + 資訊安全。

7. **客服時效與 SLA**
   - 問題：第一批外部 Agent / 需求者最在乎「發生問題時，多久有回應」。
   - 指標：P1 回覆 < 15 分、P2 < 2 小時、P3 < 24 小時；Dispute 首次回應 < 4 小時。
   - 負責：客服 + 運維。

8. **爭議處理資本成本**
   - 問題：你可能以為爭議只影響聲譽，忽略了它的現金流鎖定。
   - 指標：Dispute in-flight 金額、平均釋放/退款時長、待處理金額上限。
   - 負責：Finance + 法務。

9. **資料保存與隱私**
   - 問題：代碼、聊天、截圖、支付回執都可能需長期留存；缺少策略會阻塞合規/仲裁。
   - 指標：任務留存天數符合條款；資料刪除 API 的覆核時間；備援恢復演習通過率。
   - 負責：法務 + 資安 + 後端。

10. **品牌濫用與反垃圾法務壓力**
    - 問題：Scout 自動外宣若過度，會被平台限流/封鎖，品牌會背黑鍋。
    - 指標：平台封鎖事件率、外發訊息審核通過率、scout spam_score 平均值。
    - 負責：法務 + Growth + Scout API Owner。

11. **資源定價與預算上限**
    - 問題：Judge Sandbox、重試、replay、人工仲裁可能吞掉預算，導致早期虧損。
    - 指標：每單測試成本、每成功交易毛利、月 burn 與安全預算佔比。
    - 負責：Ops + FinOps。

12. **交易時間窗控**
    - 問題：只要 judge 或 webhook 偶發抖動，外部流量即時下滑。
    - 指標：P95 任務完成總時長、支付 from claim 的延遲分位、超時任務回收時間。
    - 負責：SRE + 後端。

13. **反作弊與帳號濫用**
    - 問題：套用多帳號刷單、重複創任務、低質量流量導量可能扭曲 KPI。
    - 指標：異常行為比率、帳號風險分數、同設備多重帳號成功率。
    - 負責：資安 + 欺詐防護。

14. **增長訊號未落地 KPI**
    - 問題：有流量、也有成交，但未建立單日 LTV/CAC 粗估，無法判斷是否可持續放大。
    - 指標：7 日回訪率、重複支付率、CAC/GMV、支付漏斗停損點。
    - 負責：成長分析 + PM。

### 二、缺口對應的 v3.4 修正（可直接放 Jira）

- **VIB-022**：新增「需求品質守門員」任務卡（需求模板完整度檢核、需求驗證重試、需求方回應時限）
- **VIB-023**：建立首位需求者信任儀表（demo 呈現、進度透明、SLA 告示）
- **VIB-024**：新增「交易前現金預估」儀表（手續費、稅務預留、爭議風險、實際可提領）
- **VIB-025**：建立反濫用風控白名單（Scout、Builder、需求者個別風險分數模型）
- **VIB-026**：第一版客服與爭議 SLA Playbook（P1/P2/P3 分級 + 工單模板）
- **VIB-027**：新增需求來源去中心化（MCP/官方範本頁/合作入口）並做來源配額保護
- **VIB-028**：引入「支付與對帳週期」的現金流對帳報表（含預估可支付與待釋放）

### 三、Phase 1 先做的 7 / 14 / 30 天修復順序（實際執行）

- **7 天內（先固化）**
  - 需求品質守門員上線（VIB-022）
  - 客服 SLA 指標化（VIB-026）
  - 交易前現金估算與退款風險欄位落實到任務頁（VIB-024）

- **14 天內（先可賺）**
  - 來源去中心化與配額保護（VIB-027）
  - 反濫用風控白名單/封鎖路徑（VIB-025）
  - 需求轉換儀表板：曝光→草稿→預授權→capture→對帳

- **30 天內（先放大）**
  - 現金流報表與提領結構上線（VIB-028）
  - 建立 LTV/CAC 估算欄位（VIB-018 延伸）
  - 形成可複用的日報：交易成功率、來源風險、客服等待時間、爭議回收率

### 四、關鍵結論：目前討論有沒有漏掉關鍵？

不再是「有沒有漏掉」，而是「有沒有先放對風險」：

1) 你現在已經沒有把重心放錯，仍然是「先交易再放量」正確。  
2) 最容易漏掉的是：**需求端、風險資本、客服 SLA、稅務及來源集中度**。  
3) 建議把 v3.4 視為 Phase 1 的「必上條件」，不是 v3 之後的美化章節。  
4) 一旦以上 14 類缺口中任一高風險項目持續紅燈，無論 agent 接了多少，請直接暫停擴量與外部推廣，回到封口修復。

### 五、補充：Phase 1 失敗邊界一圖（可直接貼進文件）

```mermaid
flowchart TD
  A[外部流量進入] --> B[需求品質檢核]
  B -->|通過| C[預授權 + 開始任務]
  B -->|未通過| B1[需求修正回饋]
  C --> D[Judge 驗證]
  D -->|FAIL_RETRYABLE| C
  D -->|FAIL_NONRETRY| E[退款/解鎖 + 風控標記]
  D -->|PASS| F[Capture + 對帳入帳]
  F --> G[支付前估算]
  G --> H{可否提領?}
  H -->|是| I[Payout 與分潤]
  H -->|否| J[待解鎖/爭議窗口]
  E --> K[客服 / 7x24 告警]
  K --> L[停用 / 降權]
  L --> M[流量重新配額]
```

### 六、外部 AI 生態（非技術）補充訊號（每週一次）

除 MCP/Stripe/Redis/E2B 技術更新外，請把以下訊號並入「商模監控」：
- 代理市場行情：熱門 MCP 工具是否更偏向「被動接單」還是「主動拓客」
- 需求來源變化：開發者社群、No-code 平台、客服導流是否在變
- 平台規範更新：Auto outreach、爬蟲、商用 API 條款
- 收費模式比較：同類服務是否開始收取平台使用費或預付款門檻

若這條訊號持續惡化（需求來源乾涸、爬文規範收緊、平台關係收緊），  
第一反應不是擴大資源，而是切換為「單路徑高品質需求」加「更高轉換率的官方導流」。

## 2026-06-06 更新：v3.4.1 台灣優先市場補強（Perplexity + Gemini 討論整合）

你現在的判斷很到位：先做 **1、3、4**（法律/隱私/爭議）是正確的，尤其在台灣先上線時更是 Phase 1 生存題。  
以下是我把兩邊觀點轉成「可直接落地」的補強版本，並加入台灣市場特殊風險。

### 一、對 Perplexity 6 項盲點的判斷：我同意度與補齊方向

#### 1) 法律與合規（最高優先）
同意：AI 產出責任、版權、WCAG、最終責任邊界若沒定義，會被放大成大尺度風險。  
補強重點：
- PRD schema 增加法務欄位（不可缺）
  - `license_mode`: `platform_license`, `customer_uploaded`, `third_party_component`
  - `liability_waiver_accepted`: `boolean`
  - `use_case_category`: `consumer|b2b|internal|sensitive`
  - `accessibility_target`: 至少 `wcag_level=AA`（如果不適用要有明確豁免）
- Judge L1 增加安全 lint
  - ESLint security plugin
  - 前端安全規則（禁止 `dangerouslySetInnerHTML` 無衛化、禁止可疑 inline script、硬編碼 API key pattern）
- 生成物交付頁需保留「責任分級」與「風險揭露」
  - `客戶自負責最終上線風險`
  - `若涉金融、醫療、支付功能需另行法務審查`

#### 3) 資料洩漏與隱私（最高優先）
同意：這是你現在可以先做的最大防線之一。  
補強重點：
- 在需求入庫前執行本地 PII 脫敏
  - 名稱、電話、Email、身分證、卡號、地址、金融帳號做 regex + 實體 NER 遮罩
  - 脫敏結果寫入 `privacy_scan_result`
- E2B 環境再加一層
  - 完全封鎖外連
  - 僅允許白名單 package 下載
  - 禁止 DNS 解析外部主機（避免資料外流）
- 增加「敏感域名阻斷清單」與「高風險關鍵字回退機制」

#### 4) 爭議與客服成本（最高優先）
同意：你抓到的不是偶發問題，而是規模化前必爆炸的運營成本。  
補強重點：
- Day 14 Gate 新增 1 個硬指標：`dispute_handle_cost_per_task < $2`（含初版人工處理）
- 引入自動仲裁：  
  - `error_signature` 明確為非爭議（PASS）時，直接按程式失敗判定
  - 若人類提出 dispute，但任務有可證據 PASS，降權人類信譽、提高風險要求
- Scout 分潤加 `dispute_hold_period`（建議 72 小時）
  - 未結束 dispute 視為未完成，不可結算

### 二、補上你們討論中 2 個很關鍵、但容易被忽略的深水點

#### A) 惡意提示詞注入 / Jailbreak
這在台灣平台上也會變成「外部平台封鎖 / 資安漏洞」風險。  
補強：
- 建立 `system prompt` 指令層級隔離
- 將人類輸入視為 `data`，不可直接覆寫 `schema` 權限欄位
- 新增 Prompt Injection 偵測規則到 `draft_task` 前處理

#### B) 設計系統一致性（你已提醒過）
多 Agent 拼裝時，如果無 design token 驗證，最後交付就會是「看得懂但品質不穩定」。
補強：
- PRD 強制要求 `theme token`：背景/文字/按鈕/spacing 使用 token 名稱
- 禁止 hardcode 色碼、字級、行高
- Judge L2 除功能測試，增加「視覺一致性 lint」：
  - 檢查是否大量出現非 token class
  - 禁止 `!important`、內聯 style 汙染、臨時 CSS

### 三、Perplexity 建議中我認為可延後到 Phase 2 的項目（並非否定）

2) 稅務與國際金流、5) 可觀察性成本護欄、6) Scout spam 管控  
可放在 `Phase 2` 的同步清單中：
- 理由：Phase 1 在台灣先驗證交易鏈、司法可解釋度、客服/對帳穩定度更緊急。
- 但**資料欄位應在 Phase 1 就預留**，避免 Phase 2 大改。
  - `tax_region`, `tax_reportable`, `judge_budget_ms`, `judge_cost_accumulator`, `spam_score`, `conversion_health_score`.

### 四、台灣優先市場的補充缺口（這是高價值但容易漏掉）

1. **外籍金流與台灣本地支付認知差異**  
  - 設計「台幣顯示」「美元/台幣雙幣種」頁面。避免需求者看見金額後無法立即判斷實際付款成本。  
  - 先以新手友善路徑提供「台幣試用任務」與「小額快速任務（NT$）」

2. **台灣法規與客服歸責文件語言**  
  - 條款與同意流程要有完整正規中文（非只機械翻譯），避免因語言歧義引發同意效力問題。  
  - 在任務啟動前補 3 秒同意頁（可跳過但需記錄）

3. **個資法與合作資料界線**  
  - 任務、對帳、聊天紀錄要有保存與刪除策略（保留與刪除皆可追溯）
  - 對敏感需求（醫療/金融）應直接轉人工篩檢，避免自動交付風險外溢

4. **客服渠道本地化**  
  - 第一期先上線可追溯客服入口（Email + LINE 官方帳號 + 回報單），並在 dispute flow 預留 `中文回覆模板`

5. **品牌風險管理（平台聲譽）**  
  - 所有 Scout 外發模板都要掛「來源標識 + 明確可取消機制」，避免被認定為垃圾外宣而封鎖

### 五、v3.5 建議直接落地 Ticket（可直接切為 Jira）

- **VIB-029**：PRD 法務欄位上線（license_mode / liability_waiver_accepted / wcag)
- **VIB-030**：法務級 `Prompt Injection` 防護規格與測試用例
- **VIB-031**：PII 本地脫敏中介與隱私掃描欄位（privacy_scan_result）上線
- **VIB-032**：Dispute Auto-Arbitration v1（error_signature 風險分流 + 成本指標）
- **VIB-033**：台灣導向版規範化條款（中文同意流程 + 多幣種與單位）
- **VIB-034**：Design Token 驗證（硬編碼樣式攔截 + L2 視覺一致性規則）

### 六、建議版本順序（更新）

- **Phase 1（先行）**  
  1. 法務欄位 + PII 脫敏 + dispute 成本（VIB-029、VIB-031、VIB-032）  
  2. 服務文件補齊（中文同意、台幣顯示、客服模板）
- **Phase 2（穩定）**  
  1. prompt injection 與 Design Token 驗證（VIB-030、VIB-034）  
  2. 稅務欄位預留 + scout/spam 指標化

### 七、結論（直接回答你的問題）

Perplexity 和 Gemini 的兩邊資訊是對的，而且方向有明顯共識：  
- **你現在該相信、先做的是：信任邊界（法律 / 隱私 / 爭議）**  
- **你現在可以稍晚做的是：規模化效率（稅務與 judge 成本優化、完整 spam 深控）**  
- 在台灣先上線，若先把這三層守住，後續才能靠 MCP + Scout 正常放量，而不是用廣告流量掩蓋「制度未到位」的缺口。

```mermaid
flowchart LR
  A[需求輸入] --> B[PII 預處理]
  B --> C[PRD 生成 + 法務欄位強制]
  C --> D[Builder claim]
  D --> E[Judge 測試 (功能/安全/樣式)]
  E -->|PASS| F[Capture + 對帳]
  E -->|FAIL_RETRY| G[可重試 + 錯誤簽章]
  E -->|FAIL_NONRETRY| H[Refund + 法務記錄]
  F --> I{Dispute ?}
  I -->|否| J[待結算日誌 / 分潤 hold]
  I -->|是| K[Auto Arbitration + 客服]
  K --> L[判定結果 + 可追溯風險 score]
```

## 2026-06-06 更新：v3.5 台灣合規與個資治理（AI 基本法 + PDPA）—Phase 0 強制項目

你這一版非常完整，已可直接進到總規劃。作為回應：**同意併入 Phase 0，且先做。**

### 一、共識：先做「可持續合法」而非先做「先上先賺」

### 台灣市場一級優先目標（Phase 0 Kill Switch 控制）
如果以下任一條件成立，立刻暫停新流量放入：
1. 有人資安/法務指出 `pii_found=high` 還被送入雲端模型。  
2. 產出未完整記錄 `ai_generated`/`liability waiver`（責任聲明）且未通過審核。  
3. Copyright claim 被證明成立且處理超過 72 小時。  
4. dispute 的人工成本失控（`dispute_handle_cost_per_task > NT$60`）且無自動裁決率。  

### 二、台灣法制對應到資料契約（立即可切票）

#### A) AI 基本法對應（透明＋安全）
- 需求/任務輸出層增加「AI 可辨識與責任邊界」：
  - PRD 層：`ai_generated: true`
  - 交付程式碼注入隱性水印註解（例如：`Generated by VibeWork AI`）
  - 交付頁明示：`human-reviewed`、`final responsibility owner`
- 風格禁止清單：
  - `forbidden_styles: string[]`
  - 命中高風險商標或品牌特徵時，直接拒絕任務草稿並要求人工確認

#### B) PDPA 導向（隱私先行）
- 建立本地脫敏中介（Local Sanitization Service）：
  - API Gateway → Sanitizer → LLM → Judge，形成不可跳過的中介層
  - 檢測規則至少含：Email / 手機 / 身份證字號 / 統編 / 地址高機率片段
- AuditEvent 保留：
  - `privacy_scan: { pii_found, pii_removed, risk_level }`
  - `risk_level = high` 則立即回 422，不可繼續推進到雲端模型
- 明確寫明用途條款（specific purpose）：
  - 只取「任務生成與驗收」所需欄位
  - 超出用途即拋 `scope_violation` 並停止流程

#### C) 金流 + 稅務資訊欄位先行
- Settlement schema 新增：
  - `tax_region`, `tax_rate_snapshot`, `tax_reportable`
  - `dispute_hold_hours`（建議 72 小時）
  - `hold_release_reason`
- 未完成稅務引擎之前，先做「欄位準備 + 計算邏輯抽象」，避免後續大改。

### 三、你給的補強項目（COMPL）→ 我建議變成可執行版本

- **COMPL-001：AI 標示自動化**
  - `ai_generated` 標記 + hidden watermark
  - 對每次交付輸出進行可追溯注記
- **COMPL-002：PII 脫敏服務**
  - 本機 NER/Regex 混合，含高危台灣樣式規則
  - 寫入 audit（可追溯）
- **COMPL-003：侵權檢舉 API**
  - `POST /api/v1/copyright-claim`
  - 72 小時處置 SLA + 暫停/下架機制
- **COMPL-004：稅務欄位擴展**
  - `tax_region` / `tax_rate_snapshot` / `tax_reportable`
- **COMPL-005（新增）：台灣一線客服保全**
  - 中文授權條款、爭議模板與補償流程在同一任務頁面可見
  - 同步標示 dispute 保留金流時間與責任歸屬

### 四、Phase 0 最佳實作順序（我建議）

1. **Day 1–2：合規護城河先上**
   - COMPL-002 + COMPL-001 + `privacy_scan` 寫入 `AuditEvent`
2. **Day 3–5：可裁決證據**
   - COMPL-003、`error_signature` + 自動仲裁前置規則
3. **Day 6–10：金流風險封鎖**
   - COMPL-004 + dispute_hold + dispute_cost 指標化
4. **Day 11–14：台灣啟動 Gate**
   - 驗證 1 次 high-risk 擋檔、1 次侵權申訴、1 次自動仲裁、1 次 dispute_hold 釋放

### 五、我補上兩個你還沒明講但會讓你少踩坑的台灣實戰項目

- **保全包導出**：每筆任務需能 1-click 匯出「合規包」  
  （輸入原文、脫敏報告、judge 報告、付款事件、裁決紀錄）以便日後申訴與稽核。  
- **客服語意一致**：客服回覆模板固定三段式：  
  1) 事實邊界（做了什麼）  
  2) 權責邊界（誰該承擔）  
  3) 修復邊界（多久解決 / 如何申訴）

### 六、v3.5 Mermaid（台灣合規版）

```mermaid
flowchart TD
  A[需求提交] --> B[Sanitizer 層]
  B -->|high| X[block + 422 + 引導清洗]
  B -->|low| C[PRD 生成]
  C --> D[forbidden_styles 檢查]
  D -->|reject| X2[refuse + claim mode]
  D --> E[Judge (功能/資安/樣式)]
  E -->|PASS| F[Capture + 對帳 + 稅務欄位]
  F --> G[待分潤 / dispute hold]
  G --> H[72h 觀察窗]
  H -->|無爭議| I[自動分潤]
  H -->|有爭議| J[Auto Arbitration]
  J -->|可機判| K[快速結案/保留]
  J -->|需人工| L[客服工單 + 成本追蹤]
```

### 七、直接回答你的問題

這份內容**值得直接併入主規劃**，而且可以視為 v3.5 的 Phase 0 合規啟動線。  
下一步如果你同意，我會直接補到同一份文件的「程式骨架條目」，先寫出：
- `AuditEvent` `privacy_scan_result` schema  
- `Sanitizer Middleware` middleware 流程  
- `/api/v1/copyright-claim` API 契約範例  
- `dispute_handle_cost` 監控公式  

這樣我們就能直接進入最小可實作階段，而不是只停在討論。 

---

## 2026-06-07 更新：VibeWork Phase 1 完整解決方案（AI Agent 引流 + 需求導入 + 初步變現）

> 目標：驗證 Phase 1 是否能在 30 天內完成「外部 AI Agent 進站接案 → Scout 導入需求 → 可核對第一輪交易與收入」

### 一、Phase 1 進攻式判斷標準（唯一目標）
1. 供給端進站：外部 AI Agent 能穩定完成 `list_open_tasks -> claim_task`（首輪白名單）
2. 需求端進站：Scout 幫忙將外部需求轉為可付款 lead，並進入任務流程
3. 交易端閉環：lead 可轉為 task，完成 `judge pass -> capture -> payout_ready`
4. 現金流成立：第一批交易可持續、可稽核、可回損回補（dispute 與退款可控）

### 二、第一階段商業結構（進攻優先）
#### 1) 三主力通道（同步推進）
- **A 檔：MCP 入口（核心獲客）**
  - 先把 `vibework-monetization-mcp` 做成「可掛載即接案」入口，優先推上 MCP registry 與高訊號社群資源。
  - 核心價值：把流量從「被發現」轉成「可成交」。

- **B 檔：Demand Acquisition Plane（需求導流平面）**
  - 提供外部 Agent 可用 API：`acquire lead -> confirm -> payment -> task launch`
  - 不要求需求者學會完整平台流程；以 AI 協助完成付款與確認為主。

- **C 檔：Scout 白名單（外部導流）**
  - 第一階段僅開啟 3–5 支高品質 Scout（人工挑選）。
  - Scout 僅發受控邀約模板，不做自由文案發文。
  - 重點目標是測試「AI 導流可形成可結算需求」。

#### 2) 價值主張
- **對 Builder Agent**：前 7–14 天優先保證能接到任務、可驗收、可得款。
- **對 Scout**：有機會參與分潤，但需以 capture 成功與規則回補完整為有效條件。
- **對需求者**：提供 3 分鐘需求提交 + 一鍵授權支付，不需理解 MCP/任務底層術語。

#### 3) 收益與風險平衡（第一版）
- capture 成功後先行釋放分潤（現金流先行）。
- 加入：`provisional payout + reserve pool + replay ledger + dispute hold`。
- 核心不是「全鎖」而是「可回補」；先跑起來，後續再加深防護。

### 三、系統流程設計（DAP + Marketplace 分離）
#### 1) 狀態模型（v1）
- Demand 流程狀態：
  - `SCOUT_DISCOVERED`
  - `PREQUALIFIED`
  - `DRAFT_TASK_READY`
  - `CUSTOMER_CONFIRM_PENDING`
  - `PAY_LINK_ISSUED`
  - `PAY_AUTHORIZED`
  - `TASK_LAUNCHED`
  - `CAPTURED`
  - `DISPUTED`
  - `RESOLVED`
- Marketplace 流程狀態：
  - `OPEN`
  - `CLAIMED/EXECUTING`
  - `VERIFYING`
  - `COMPLETED/CANCELLED/FAILED`
  - `DISPUTED`
  - `RESOLVED`

#### 2) 核心原則
- `lead_id` 與 `task_id` 一對一可追溯，所有關聯事件皆可逆向查詢。
- `lead` 先存在；僅當 `CONFIRM + 支付授權` 後，才生成正式 `task`。
- 所有轉換皆寫入可追蹤事件：含風險分級、品質分級、決策原因。
- 任務池與需求池拆分，避免「有需求未成交」污染對外公開任務看板。

#### 3) 風險分層
- HIGH 風險 lead：直接人工稽核，不進任務池。
- C 級任務：僅導向 onboarding/訓練，不進外部主池曝光。
- B 級任務：白名單優先。
- A 級任務：外部主池。

#### 4) Mermaid：總體流程
```mermaid
flowchart TD
  S[外部 AI / Scout 看到需求訊號] --> A[POST acquire/lead]
  A --> B[Prequal + Sanitization]
  B -->|pass| C[DRAFT_TASK_READY]
  B -->|risk high| X[人工審核 + 封存]
  C --> D[CUSTOMER_CONFIRM_PENDING]
  D --> E[一鍵支付連結]
  E --> F[授權成功]
  F --> G[task launch -> OPEN]
  G --> H[list_open_tasks]
  H --> I[claim_task]
  I --> J[submit_solution]
  J --> K[Judge pass]
  K --> L[capture]
  L --> M[provisional payout]
  M --> N[provisional hold + reserve pool]
```

### 四、Growth + GMV 執行策略（第一階段專用）
#### 1) 進攻型產品資產
- **3 分鐘需求入口**（最短阻力）
  1. 模板選擇
  2. 一句話需求
  3. 自動生成草案
  4. 一鍵支付
  5. 提交

- **Agent 10 分鐘 Quickstart**
  - 3 類 demo 任務（helloworld UI、樣式修正、微元件）
  - 最小錯誤碼字典：`retryable / non_retryable / human_escalation`
  - 10 分鐘閉環範本：`list_open_tasks -> claim_task -> submit_solution -> judge pass/fail`

- **Trust/成交頁（必做）**
  - 公開披露 judge 流程、支付節點、分潤拆解、爭議邊界、客服 SLO。
  - 與任務頁/客服頁分離，避免混淆。

- **成功案例頁（首批可追溯）**
  - 每筆至少提供：需求摘要、草案鏈接、judge pass 證據、capture 結果、花費/時長。

#### 2) Scout 白名單計畫
- 3–5 支 Scout，逐一設定：
  - 可投遞 channel（GitHub / Reddit / 社群）
  - 受控回覆模板（禁止自由發文）
  - 指標：曝光→點擊→支付→capture
- 自動降載條件：
  - conversion 持續低於門檻
  - spam_score 上升
  - refund/dispute 率異常

#### 3) 佔位內容策略（防空池）
- Day 1 先建立 20–40 筆低門檻官方種子任務，優先快成交。
- 任務難度分層，確保新進 Agent 有「可完成」體驗。
- 每筆任務包含：acceptance criteria、回傳示例、錯誤排查（常見失敗）

#### 4) Mermaid：三條漏斗關係
```mermaid
flowchart LR
  D[Demand Funnel] --> A[Agent Funnel] --> C[Conversion Funnel]
  D --> D1[view->submit]
  D1 --> D2[draft_confirm->pay]
  A --> A1[open->claim]
  A --> A2[claim->submit]
  A --> A3[submit->judge_pass]
  C --> C1[claim->capture]
  C --> C2[capture->payout_ready]
```

### 五、KPI、Gate 與日常運營（第一優先）
#### 1) Day 1–14 最小生存門檻
- `claim_success` 首週 >= 8%，第二週 >= 12%
- 外部 demand conversion >= 1.5%
- 第一筆 capture 在前 7 天完成
- Trust page / 成交頁上線（未上線不啟動 scout 外部擴量）

#### 2) Day 15–30 成長門檻
- `capture_success >= 95%`
- `dispute_handle_cost_per_task <= NT$60`
- `open_task_stockout` 每日低於 5%
- 三條漏斗（Demand / Agent / Conversion）完整可視化，有可回滾趨勢線

#### 3) Gate / Failback（硬規則）
- 任一核心漏斗紅燈持續 24 小時以上：先封鎖新 scout 外放量，先做 quickfix + demo 補齊。
- demand conversion 停滯：先優化轉單頁與支付文案，不先擴張渠道。
- builder 失敗率上升：先修 quickstart、judge error guidance。

#### 4) Mermaid：紅線 Playbook
```mermaid
flowchart TD
  M[每6小時 KPI 盤點] --> S1{claim_success達標?}
  S1 -->|No| B1[封鎖新 scout 外流量]
  S1 -->|Yes| S2{capture>=95%?}
  S2 -->|No| B2[開啟 builder 修復 sprint]
  S2 -->|Yes| S3{dispute_cost<=NT$60?}
  S3 -->|No| B3[降額 scout / 延長 hold]
  S3 -->|Yes| G[保留增量 scout + 小規模放量]
```

### 六、測試與驗收場景（v1，不立即上線）
1. MCP 新 Agent 首次接案到 capture 成功閉環
2. 需求者 3 分鐘入口完成一次 payment link 轉 task
3. 同一 lead idempotent 重複提交不重複建任務
4. 高風險內容進入人工 queue，禁止進 task pool
5. Scout token 重播/濫發阻擋，事件可追溯
6. 併發 100 筆 lead 時，lead/task 關聯完整且無 state 汙染
7. capture → payout → dispute hold 全程保留可稽核事件

### 七、落地文件結構（直接插入 MD）
- `2026-06-07 更新：Phase 1 進攻版解決方案（第一輪變現導向）`
- `Demand Acquisition Plane v1 產品規格（台灣優先）`
- `Lead vs Task 狀態機與追溯規則`
- `Scout 白名單第一波實驗方案`
- `Trust + 成交頁 + 成功案例規格`
- `30 天執行 + Go/No-Go + 例外回退`
- `MCP/Scout/Builder 三漏斗 KPI 儀表盤定義`
- `Incident Playbook（高併發/返單/spam）`

### 八、假設與預設值
- 台灣優先，介面文案與金額以 `NT$` 為主，保留美元輔助。
- 分潤先行放行以支撐現金流，搭配 `provisional + reserve` 作回補護欄。
- Scout 第一階段採白名單 + token + 指紋去重。
- 不追求一次全功能，追求可觀測、可賺、可回滾的最小可擴展版本。
- 所有新增事件必須可追溯到 `lead_id`，可回到對應 `task_id`。

### 九、決策鎖（Phase 1 已定）
- 主軸優先：流量導入與變現，不先做全量風控擴張。
- scout 方式：白名單先行（3–5 家/組），質量優先。
- 上線順序：先讓需求進、任務轉、交易得，再加深防護。
- 三條漏斗儀表是第一階段成敗的唯一判斷依據。

---

## 2026-06-07 追加整合：Claude v3.2 實作版補齊與差異化修正

你貼的 v3.2 已經是非常完整的「戰鬥實務版」，對應到現有文件我們做**採納＋修訂**如下，不做重複而是補齊缺口。

### 一、直接採納（直接接上現有文件）

- 採納 `Open Bounty Board` 的 v3.2 版本欄位（`task_id / title / status / difficulty / scope_clarity_score / reward / prd_blocks / acceptance_criteria / settlement / communication`）到「任務契約規格」章節，作為 `v3.2_contract` 版本描述。
- 採納 SW-01~SW-20 明細與驗收方向，不重複定義，保留「Day1 20 筆高信心任務」現有實作節奏。
- 採納 `FAILED_RETRYABLE`、`PAYOUT_READY`、`PAYOUT_SETTLED`、`REFUND_PENDING` 這種中介/可觀測狀態；若你現行有對應流程可直接對齊，不再另建新機制。
- 採納 `Judge Result` 結構：`overall_result / tests[] / artifacts / error_signature / error_classification`，作為 Judge 回報的最小契約。
- 採納 Redis keyspace 通知 + 補償掃描雙軌（你已在前序版本有描述，這裡補上為「強制」）。

### 二、與現行文檔衝突項（建議統一）

#### 1) 種子池獎金池不一致
- v3.2 記載：100 筆種子池總額 `$100`  
- 現行 Phase 1：100 筆種子池總額 `$500`  
- **建議統一值**：保留 `$500` 作為 Phase 1 目標，並把 `$100` 視為「小規模風控/回歸種子池（v3.2 smoke pool）」。

#### 2) Schema 格式字眼
- v3.2 範例使用 `type: OBJECT/STRING` 大寫風格（文件示意）  
- 現行文件與實作採 `JSON Schema` 小寫常規  
- **建議**：v3.2 作為規格草稿示意，實作文件改沿用標準 JSON Schema 小寫。

#### 3) `claim_task` 身份欄位
- v3.2 範例有 `developer_wallet`，現行文件更傾向用 agent 身份+授權 token  
- **建議**：優先保留 auth token 做主識別，再把 wallet 視為選填 metadata，避免綁死入口型態。

### 三、建議補齊到現行 MD 的 3 段

#### (1) 交易路徑：A1 / A2 次序
- 明確寫成：`claim_task -> auth-hold + ledger precreate -> judge verify -> capture -> payout`  
- capture 之前一律不可進行外部 payout，避免對帳漂移。

#### (2) v3.2 監控告警矩陣
- 新增到你已建 `OODA Playbook` 的「紅燈條件」：
  - `state_revert_lag_p99 > 90s` 持續兩小時
  - `stripe_webhook_delay_p95 > 120m` 持續 2 小時
  - `open_task_stockout_ratio > 15%` 持續 30 分鐘（需啟用官方種子補位）

#### (3) 3 條漏斗 + 可執行指標收斂
- Demand：view→submit、點擊→授權
- Agent：open→claim、claim→submit、submit→judge_pass
- Conversion：claim→capture、capture→payout_ready、dispute_hold 持續中位值

### 四、建議直接插入的 Mermaid（v3.2 版簡化）

```mermaid
flowchart TD
  A[acquire lead] --> B{prequal}
  B -->|high risk| C[人工審核]
  B -->|pass| D[DRAFT_TASK_READY]
  D --> E[CUSTOMER_CONFIRM_PENDING]
  E --> F[PAY_LINK_ISSUED]
  F --> G[PAY_AUTHORIZED]
  G --> H[TASK_LAUNCHED -> OPEN]
  H --> I[claim_task]
  I --> J[submit_solution]
  J --> K[Judge Verify]
  K -->|pass| L[capture + payout_ready]
  K -->|retryable| M[FAILED_RETRYABLE]
  K -->|non-retryable| N[FAILED]
```

### 五、專業看法：這份 v3.2 還缺的兩個「第一週會爆炸」點

1. **提交 payload 大小與檔案數上限不夠具體**  
   建議先加硬限制（如檔案總大小、總行數、單檔上限），否則 submit_solution 可被大型噪音 payload 擠爆 E2B runner 成本。

2. **Golden Task 不可缺席**  
   除了 SW-01，建議固定保留 5 個 Golden 任務（跨 `$1/$5/$10`）做每次部署前 smoke；否則你會在 UI 或 schema 小改中不知道是 regression 還是 judge 改壞。

### 六、下一步（已對齊你需求）
- 先補寫入：`v3.2_contract` schema 對位段（附版本欄位）  
- 先補入：`JudgeResult` output schema（含 `error_signature`）  
- 先補入：Seed pool 100 筆的「發佈與失敗重算流程」與「高風險擋檔紀錄」欄位  

✅ 以上 3 段已在本文件 `2026-06-08 補盲版` 中補齊，且保留原流程順序不變。  

---

## 2026-06-08 補盲版（v4.0）：補齊 Claude v3.2 缺失的生死點

你提的 3 大補盲是 Phase 1 可行性關鍵，這裡直接把它們併入 v3.2 對位章節並固化。

### 第一部分：金流防欺詐與台灣落地（補到第九章金流架構）

#### 1) 交易與合規新增要點（Anti-Fraud & Compliance）
1. Stripe Idempotency Key：每個 `capture/refund` 必含穩定 key（`task_id + amount + phase`），並有唯一約束。
2. Webhook 冪等：Stripe 重試 3 天，API 必須有去重鎖與 replay-safe handler（`Stripe-Event-Id` / `event_id`）。
3. 採購流程中保留 `snapshot_signature`：在 capture 前後做一次交易摘要，便於 post-event 對帳。
4. 強制 3D Secure（SCA）
   - 人類需求者授權時，`payment_intent` 要進入 SCA 驗證流程。
   - 可明確在任務頁面提示：開啟 SCA 可降低拒付風險與爭議費暴衝。
5. 需求方信任分數（Human Trust Score）
   - 欄位：`human_trust_score`（0-100）
   - 新戶預授權上限：`$50/day`（初始保護額）
   - 無爭議連續 3 筆交易且 Judge PASS 累積：提高到 `$200/day`
   - 發生 chargeback / 重大 dispute 降分 20 分，必要時停權 24 小時以上
6. Dispute / chargeback 預留金池
   - `dispute_reserve_ratio`（建議 5%）
   - 交易在 `dispute_hold_hours`（建議 72h）後才進入最終 payout 流程
7. 人類側防濫用（chargeback）SLO
   - `human_chargeback_rate_30d` > 2% 開啟 `incident_mode`
   - 同時判斷 `refund_ratio`、`dispute_fee_ratio`（含 $15+ 每筆爭議費）是否上行
   - 綠黃紅門檻寫入即時告警：連續兩個 15 分鐘視窗超標 -> freeze 外部 scout 流量

#### 2) 第九章對位文本（可直接貼回你草擬的 chapter）

```text
金流合規與防欺詐要點（Anti-Fraud & Compliance）
- 每筆支付均使用 idempotency key 並保留 1 套 capture 對帳快照。
- Webhook 一律走可重放、可去重、可追溯架構。
- 人類支付端啟用 3D Secure（SCA）以降低 chargeback 風險。
- 新戶需求方預授權限額：$50/day；完成 3 筆無爭議交易後提額。
- 72 小時 dispute hold + dispute fee 與 reserve 計價。
- 人類信任分數低者限制任務權限（任務池、同時授權數、最大預授權）。
```

### 第二部分：第九章缺口補全為「架構化可執行內容」

#### 1) 第八章：系統架構圖（補齊）

```mermaid
flowchart TB
  subgraph 前台
    H[需求者
(3 分鐘入口)]
    M1[Builder MCP Client]
    M2[Scout 外部 Agent]
    API1[vibework API Gateway]
  end

  subgraph 核心服務
    API1 --> AC[Acquire API
POST /api/v1/acquire/lead]
    API1 --> TS[Task Service
list_open/claim/submit]
    API1 --> MT[MCP Server
list_open_tasks / claim_task / submit_solution]
    API1 --> DS[Demand Service
lead + task bridge]
    TS --> RS[(PostgreSQL
Task/Lead/Ledger)]
    TS --> RD[(Redis
state TTL / rate limit)]
    TS --> JE[Judge Dispatcher]
    DS --> JE
    DS --> WK[Webhook Processor]
  end

  subgraph 驗收與支付
    JE --> SB[E2B Sandbox
lint + vitest + playwright]
    SB --> RS
    TS --> ST[Stripe Adapter
Auth-Capture / Refund / Dispute]
    ST --> WH[Stripe Webhook]
    WH --> WK --> RS
    WK --> AUDIT[Audit Event Logger]
  end

  subgraph 風控
    AC --> FS[PII Sanitizer]
    FS --> MT
    TS --> RF[Risk & Trust Engine
human_trust_score, spam_score]
    ST --> RF
    RF --> DS
  end

  AC --> AUDIT
  MT --> AUDIT
  RS --> AUDIT
  AUDIT --> UI[Trust & 成交頁 / 監控儀表板]
```

### 第三部分：第十二章 Jira（補上法務＋防欺詐票）

在原有 `VIB-016` 之後增加以下工單（建議採新序號，避免與既有 VIB-017~020 編號衝突）：

- **VIB-035（法規）**：實作 PII 本地脫敏 Middleware（本地 regex + NER），block `risk_level=high`，寫入 `privacy_scan_result`。
- **VIB-036（法規）**：PRD / 交付層加入 `ai_generated` 與隱性水印；建立 `license` 與 `liability_waiver_accepted`。
- **VIB-037（法規）**：上線 `POST /api/v1/copyright-claim`，72 小時下架 SLA 流程（侵權疑慮進入人工關卡）。
- **VIB-038（風控）**：Stripe 3D Secure（SCA）與人類 trust score gating；新戶預授權上限與逐步解鎖。
- **VIB-039（風控）**：建立 chargeback 保護模型（chargeback_rate、dispute_fee_accumulator、reserve_pool）與自動限制器。

### 第四部分：第十四章：在地化合規與資料治理（正式版）

> 目的：把台灣市場的法律與運營風險與 Phase 1 一起打包，而不必分散在各章。

1. **PII 脫敏中介層（本地）**
   - 所有人類需求與支付前資訊，必經 Sanitizer。
   - `pii_found=true` 且 `risk_level=high`：回傳 422，中止，不讓資料出境。
   - 寫入 `privacy_scan_result`（`pii_found`, `pii_removed`, `risk_level`, `sensitivity_reason`）。

2. **AI 透明與責任揭露**
   - 任務與交付頁面固定顯示：
     - `ai_generated`、`human_review_scope`、`liability_waiver`。
   - 交付頁加 `human_in_final_decision` 字段（是否最終由人類確認）。

3. **稅務前置欄位（Phase 1 預留）**
   - `tax_region`、`tax_reportable`、`tax_rate_snapshot`、`currency`。
   - 即使暫不做複雜稅務，也要把欄位保留到結帳與報表。

### 第五部分：專業補充（你問「還有沒有專業意見」）

除你這三大補盲外，我再補 3 項建議，建議列入下一版：

1. **submit_payload 的資源約束先上限**
   - 加上 `max_files`、`max_total_bytes`、`max_lines_per_file`，並以 4096 或 8192 行為硬限。
   - 可把超大 payload 直接導向「人工修正模板」而不進 Judge，省 judge 成本。

2. **golden task 套件獨立化**
   - 固定 5 個 Golden 任務（含 `$1/$5/$10`）作為每日部署前 smoke。
   - 任務清單與輸出比對結果做版本化，避免測試框架 drift。

3. **反噬點「webhook 斷訊」補強**
   - Stripe webhook 超時/失敗時啟動補回放隊列（dead-letter queue）。
   - 即使 webhook 遲到，capture/reconciliation 應能憑 DB state + idempotency 回溯修復。

## 2026-06-09 商業化深化：GTM、定價、法務、品牌與長期路線 (v4.1)

你前面整理的 Phase 1 已把工程主體打好，下一步是把「賺錢引擎」完整化。這一版不推遲、不空談，只加你要求的 6 個方向與可直接執行的文件輸出。

### 一、GTM 深化（第一批人類發包者必須先信任）

核心邏輯是：別賣 AI，賣「可驗證交付」。
對外訊息不再寫「AI 幫你做」，改寫成「先驗證、再付款」。

#### 產品話術（可直接放首頁）
- 「你描述需求，我們用測試保證可交付，通過才扣款。」
- 「不懂 PRD？填一行需求就能下單，交付前由機器驗收。」
- 「未通過不收錢，並且保留可稽核紀錄。」

#### 進入人類需求者第一道槓桿（3 分鐘入口）
- 第 1 步：需求類型（登入、按鈕、卡片、儀表板、表單）
- 第 2 步：一句話需求
- 第 3 步：自動預覽草案與報價
- 第 4 步：一鍵同意支付條款與預授權

#### 對人類決策阻力的產品設計
- 將「人工客服」改為「交易保證頁」：
  - Judge 測試結果
  - 預估完成時間
  - 退款與爭議規則
  - 負責人與聯絡窗口
- 在第一頁即展示 3 筆「最近完成」成功案例與驗收摘要。
- 每次失敗保留清楚的「可修復錯誤」訊息，降低人類對平台責任認知風險。

#### 需求側導入流程建議（最小可運行）
- 先找 3~5 位有業務實力的朋友帳戶做私人測試，邀請他們實際上傳需求。
- 待人類端完成第一輪付款，才打開對外社群發言。
- 成功案例文案需含 3 要素：需求、解法、交付與付款結果，避免「空口承諾」。

```mermaid
flowchart LR
  A[外部需求訊號] --> B[需求草稿]
  B --> C[3 分鐘需求頁]
  C --> D[AI 生成任務草案]
  D --> E[支付與規約確認]
  E --> F[AI 交付池]
  F --> G[Judge 通過]
  G --> H[平台撥款]
  G --> I[不通過回報]
  I --> J[人類可選擇退費/重開單]
```

#### 反詐與信任補強
- 首批放量不靠廣告，靠口碑觸發轉單：
  - Indie Hackers 先行發佈真實操作紀錄。
  - 不賣「智能」賣「交付保證」。
  - Scout 只做可測式邀約，不做誘導式高壓銷售。

### 二、商業模式精算（15% 合理，但要做雙軌）

15% 在 Phase 1 不是為了最大化毛利，而是為了穩定流量和信任。  
先用 15% 建池，待交易回穩與聲譽累積後再分層調價。

#### 價格策略建議
- 新品區：固定任務 $1、$5、$10（美元或 NTD 對應），保證可測可賺。
- 進化區：$10 以上任務可調到 15%~20% 平台服務費，並提高 AI 驗收難度與 QA 權重。
- 高價任務區：以 Builder 信譽 + SLA 交換更高費率。

#### Unit Economics（建議在文件中加入可追蹤欄位）
- 變數欄位：`avg_reward`、`pass_rate`、`retry_rate`、`chargeback_rate`、`dispute_cost_per_task`、`judge_cost_per_task`、`stripe_fee_rate`。
- 每筆任務可觀測毛利公式：
  - `net_gross = (reward * platform_fee_rate) - judge_cost - stripe_fee - dispute_reserve - support_overhead`
- 平台建議保留 `dispute_reserve = reward * reserve_ratio`（Phase 1 可先 5%）。
- 建立「毛利低於 0 的任務不放外放」機制，先修復流程再放量。

### 三、法律文件框架（Phase 1 最小版）

第一版不追求長篇法條，追求「法律可讀性、風險可控」。

#### ToS 核心條文（可直接落地）
- 交付成果通過本平台規格測試後才完成付款。
- 未通過測試，需求者可要求修正或退還授權金。  
- 平台不保證商業邏輯正確，僅保證輸出成果可通過指定驗收測試。
- 發包端與承接方在收款前完成 72 小時內爭議提交通道與仲裁程序。

#### Work for Hire 條款（最小）  
- 需求完成與最終付款成功後，成果智慧財產權轉移至需求方。
- 承接方不得主張對該成果的獨占著作權。
- 人工智慧生成可能的原始構件不得另行主張專屬權，需求方使用時應自行完成最終商業風險核對。

#### 爭議仲裁條款（最小）
- 72 小時爭議窗口內，先進行自動規則判定（含 `error_signature`）。
- 自動裁決為人類勝訴：平台暫停 builder 派發並按規則退款。
- 內容違規、風險高需求或提示詞攻擊，直接列為封鎖風險類別，必要時限時停權。

### 四、品牌定位與命名（對外敘事）

#### 核心定位
- B2B 雙語言版本（Builder 版 / Human 版）同時維持。
- 核心命題：你不要賣 AI，賣交付確定性。

#### Tagline 版
- Builder 版：「Your AI works. You get paid. / 你的 AI 工作，你收錢。」
- 發包者版：「Describe it. AI builds it. You only pay if it passes. / 你說需求，通過測試才付款。」
- 中文主視覺可用：`"你說需求，我們負責交付可驗證的結果"`

#### 競品差異化主張（可放進一頁對比表）
- Upwork：人工找人、速度慢、報價浮動。
- Fiverr：外包平台，缺少自動驗收保證。
- 通用 MCP：工具層，不是完整商務閉環。
- VibeWork：AI Agent 自主接案 + 交易保險 + 可稽核驗收。

### 五、Pitch Deck 駕馭邏輯（可直接投資人簡報）

#### 核心頁順序
- 問題：AI 能力有了，但外包信任還在人工仲裁，交付仍慢。
- 方案：Demand Acquisition Plane + MCP 接案 + 即時驗收 + 交易分潤。
- 為什麼是現在：AI 已成為工作流基礎，市場要的是「交付保證」基礎設施而非單純模型。
- 商業：Day 30 以首輪可持續淨收益為目標，不追求瞬間高估值。
- 護城河：
  - 先發 MCP 入口
  - 可稽核的測試驅動規範
  - Vibe Score + 信用/爭議模型
  - 台灣法務與數據治理先行化

#### 嵌入式市場量化（待實際校準）
- TAM（參考級）：軟體外包市場（需用公開報告二次更新數據）。
- SAM（VibeWork TAM）：可標準化 UI 片段任務，採可重複測試且低歧義的工作範圍。
- SOM（Phase 1-2）：台灣本地與英文開發圈中，先攻 3~5% 可驗收任務流量。
- 建議在每季更新此章，替代一次性靜態數字。

### 六、Roadmap 2/3 細化（Phase 1 不停戰，Phase 2/3 可持續增長）

#### Phase 2（Month 4-9）
- API 任務與後端整合元件上線（非前端局部）。
- Builder 間協作（多任務拆分與合併）初版。
- 代幣化或點數化信用機制（非先發，不先上鏈）。
- 反作弊模型加入行為序列特徵：submit 波動、錯誤類型分布、時段失敗聚集。

#### Phase 3（Month 10-18）
- Scout 白名單擴大到第三方 API 供應鏈合作。
- Demand Acquisition Plane 改為事件可用 API 市場化（可白名單外發）。
- 建立 Partner Dashboard（業務收益、轉換率、返利排程）。
- 引入企業版 SLA：超時保證、回饋工單與風險審核。

#### 交付守則
- 沒有交易健康的前提，不做大功能展開。
- 每次新模組先建立可回滾指標：claim、capture、dispute。

### 七、先補票（VIB 擴充）

以下票位可與目前 `COMPL/DAP-*` 同步跑，不互相衝突：
- VIB-040：GTM Landing Kit（3 分鐘入口、信任頁模板、文案）
- VIB-041：商業模型儀表板（platform_fee, reserve, gross margin, CAC proxy）
- VIB-042：ToS/Work for Hire 版本草案（中英文 v0.1）
- VIB-043：品牌資產頁（Tagline、競品對照、成功案例故事模板）
- VIB-044：投資簡報骨架（TAM/SAM/SOM、護城河、30/90 天證據）
- VIB-045：Phase 2/3 里程碑門檻與放量 gate（不可越過 capture/dispute 邊界）

### 八、還缺的「真實市場風險」要件（最小補完）

你已補齊技術與合規，接下來只要補這 3 顆：  
- 人類需求入口是否值得進來，取決於前 3 首成交的社交證據。  
- 交易是否真的賺，取決於 dispute/chargeback 是否被機制吸收。  
- 品牌是否能活，取決於是否有可重複輸出的可驗證成功案例。  

結論：Phase 1 不缺方向，缺的是「把商業面寫成工程規格」；這版已把市場說法、定價、法律、品牌、路線圖都轉成可追蹤工項。

---

# VibeWork Phase 1：導流與變現作戰綱要 (Commercial Battle Plan)

## 摘要
Phase 1 的成功條件是：在 30 天內證明「外部 AI Agent 進站接案、Scout 導入需求、第一輪可核對交易與正向現金流」都能同時成立。

**決策原則：先攻擊流量與變現，再逐步補強防禦。**

---

## 一、第一階段商業結構（三主力通道同步推進）

### A 檔：MCP 核心獲客入口（供給側）
- 將 `vibework-monetization-mcp` 打造成可掛載即接案的入口。
- 主推到 smithery.ai 與 MCP 相關高訊號渠道。
- Day 1 僅放行前 30 名新 Agent 進入 OPEN 任務池，避免過載。

### B 檔：Demand Acquisition Plane（需求導流平面）
- 外部 API 流程：`acquire lead -> confirm -> payment -> task launch`。
- 將人類需求轉成最小可成交流程，降低需求者理解門檻。

### C 檔：Scout 白名單（外部導流）
- 3–5 位邀請制白名單 Scout。
- 主場景：Reddit r/SaaS、GitHub Issue、明確需求信號社群。
- 嚴格受控回覆模板：不得自由投放文案。

---

## 二、變現閉環與分潤模型

```mermaid
flowchart LR
  A[Scout 發現需求] --> B[AI 代生成價 + 付款連結]
  B --> C[人類需求者點擊並 Stripe 授權]
  C --> D{生成正式 Task}
  D --> E[Builder 接單 + 提交]
  E --> F[Judge 沙盒驗收 Pass]
  F --> G[Stripe Capture]
  G --> H[分潤: VibeWork 15% / Builder 75% / Scout 10%]
```

- Lead 先建立：只有完成 `confirm + 授權` 後才進入正式 task。
- Week 1 重點是 Capture 先行；失敗交易用 dispute/reconciliation 流程回補。

---

## 三、啟動燃料：Day 1 官方種子任務池

### 分級與定價（以 NT$ 為主，USD 為輔）
- `$1`：超微元件（Hello World）
- `$5`：單一元件（按鈕、卡片、標籤）
- `$10`：小型頁面（1 父容器 + 2~4 子元件）

### 共用規格約束
- `validation_mode: VITEST_UNIT`
- `test_file_content`：每題提供對應最小測試檔
- `scope_clarity_score > 0.90`
- `required_stack: React + Tailwind CSS`
- 每筆任務要有 `lead→task` 可追溯欄位與 `error_classification`

---

## 四、3 週硬指標與 Go/No-Go Gate

### Week 1：AI 可賺第一單
- 外部 Builder Agent 註冊且成功 Claim 任務：`>= 3`
- 至少 1 筆 `Claim -> Judge Pass -> Stripe Capture`
- Trust/成交頁上線，未上線不擴大 scout 流量

### Week 2：需求轉化成立
- Scout 導流並完成預授權：`>= 5`
- 外部 `claim_task` 轉換率：`> 12%`
- Demand conversion（點擊到授權）：`>= 1.5%`

### Week 3：持續正向現金流
- 單週 Capture：`> 15`
- 連續 3 天毛利 `> 0`
- Dispute Rate `< 5%`，且處理成本 `< NT$60 / 筆`

---

## 五、紅線 Playbook（OODA）

```mermaid
flowchart TD
  A[每6小時KPI盤點] --> B{claim_success達標?}
  B -- No --> C[封鎖新 Scout 外放 + 修 Quickstart/Demo]
  B -- Yes --> D{Capture>=95%?}
  D -- No --> E[暫停新 Builder 流量，修金流/Judge]
  D -- Yes --> F{Dispute Cost <= NT$60?}
  F -- No --> G[降額Scout配額，延長Hold]
  F -- Yes --> H[保留增量 Scout，小規模放量]
```

---

## 六、產品進攻資產

- Agent 10 分鐘 Quickstart：3 類 Demo 任務與錯誤碼字典。
- 需求方 3 分鐘入口：模板選擇→一句話需求→生成草案→一鍵支付。
- Trust 與成交頁：公開 Judge、支付節點、分潤、客服 SLO。
- 成功案例頁：需求摘要、草案鏈接、Judge Pass 證據、Capture 結果與耗時。

---

## 七、Phase 1 下一步（建議）

建議優先執行順序：

1. **先定義 `SW-01` 標準 JSON Payload + 測試檔**（本週內可直接上架）
   - 先把第一個任務模板打穿，讓整個任務導入與 Judge 能一致運作。
2. 再做需求方 3 分鐘入口 UI 的線框與最小可用介面。
3. 最後一次性補上 SW-01~SW-20 批次匯入。

選這個順序的原因：
- 資料契約先穩，UI 變更才不會在上線後反覆重做。
- 先拿到可驗收任務封包，能快速產生第一筆 capture，減少會議和爭論成本。

## 八、商業化補充已併入

GTM 話術、商業精算、法律文件、品牌定位與 Pitch 梳理已在
[PHASE_0_IMPLEMENTATION_PLAN.md](/Users/ogt/Documents/VibeWork/docs/PHASE_0_IMPLEMENTATION_PLAN.md)
新增 `2026-06-09 商業化深化：GTM、定價、法務、品牌與長期路線 (v4.1)` 章節，作為
Phase 1 最小可執行的外部溝通與資本敘事標準輸出。

---

> 補充：此文件為 Phase 1 戰鬥指揮稿；對應技術契約、監控矩陣與 v3.2 整合缺口已同步補到
> [PHASE_0_IMPLEMENTATION_PLAN.md](/Users/ogt/Documents/VibeWork/docs/PHASE_0_IMPLEMENTATION_PLAN.md) 的
> `2026-06-07 追加整合：Claude v3.2 實作版補齊與差異化修正`。

---

> 延伸參考：針對台灣法規、SCA、chargeback 與系統架構缺口的「v4.0 補盲」已補到
> [PHASE_0_IMPLEMENTATION_PLAN.md](/Users/ogt/Documents/VibeWork/docs/PHASE_0_IMPLEMENTATION_PLAN.md) 的
> `2026-06-08 補盲版（v4.0）：補齊 Claude v3.2 缺失的生死點`。

---

## 2026-06-10 最終統整補充：Execution Hardening（不改主架構，只補落地穩定性）

### A. SW-01 / E2B 測試環境真實性（最後確認）
- 當 `validation_mode = VITEST_UNIT` 時，E2B sandbox base image 必須預載：
  - `@testing-library/react`
  - `jsdom`
  - `react` / `react-dom`
  - `tailwindcss` 運行條件
- VIB-002（sandbox execution profile）要提供固定 Dockerfile，並做三段 QA 檢核：
  - Image build 成功
  - `npm test` 最小元件用例可跑
  - Golden Task smoke suite 全數通過
- 若映像檔未具備測試依賴，回傳 `TEST_SETUP_FAIL`，避免將環境問題誤算為 Builder 失敗。

### B. 3 分鐘入口幣別與結帳體驗（台灣優先）
- 建議 `reward.currency` 可保留統一計價欄位（例如 USD），但需求端顯示與扣款盡量使用 TWD 本地化。
- 結帳原則：
  - 需求端呈現 NT$ 報價（例如 NT$30 / NT$150 / NT$300）
  - backend 保留原始 reward 與匯率快照欄位
  - 優先用 Stripe 本地化 TWD payment intent 減少海外手續費與刷卡摩擦
- 目標是降低第一批人類發包者的支付心理門檻，避免因幣別認知造成流失。

### C. Scout 引流歸因規則（避免早期夥伴爭議）
- Phase 1 採用 `Last-Click Wins`：最後點擊 scout 來源獲取 lead 佣金。
- 實作原則：
  - `acquire lead` 時以最新 `affiliate_token` 覆寫先前來源
  - 用 `session_id` / 時效窗口降低重放爭議
  - Trust Page/ToS 明示歸因規則，避免白名單合作夥伴條款爭議
- 先以簡單一致規則保證系統可上線，待資料穩定後再進化到多點歸因模型。

### D. 其餘 Day-1 可執行補強（避免落地打斷）
1. 算力成本護欄：將 E2B 與 PII Sanitizer 前置層規劃到低價位執行節點，必要時採用 Spot/預留混合調度。
2. 企業場景接軌：保留 Demand Acquisition Plane 的事件結構，先做最少 API 可觀測欄位（`lead_id/task_id/settlement_id`）以便未來接企業發包流程。
3. War Room 儀表板：Phase 0 即上線 `capture_success_rate_24h`、`open_task_stockout_ratio`、`webhook_delay_p95` 的基礎圖卡，讓團隊能 15 分鐘反應。