- Venture Machine SDD（System Design Document）
- 版本：v1.1
- 日期：2026-03-16
- 北極星：累積搭橋者異見三元組，讓 VM 持續運轉
- SDD >> 本質是 >> 地圖對地球（代碼）的壓縮，必須能反映現實且動態維護
- SDD >> 維護方式 >> >> 語法寫入行內，Polaris parser 自動建三元組，地圖自動對齊地球
- 假設（Assumptions）
- [A-001] KBDB 萬用表架構不可變：永遠只有 blocks / templates / slots 三張表，所有資料結構皆以 Template + Slot 實現，任何需求不得新增 table 或 ALTER TABLE
- A-001 >> 約束 >> 所有 Epic 的資料層設計
- A-001 >> 源自 >> EAV（Entity-Attribute-Value）模式業界實踐
- A-001 >> 邊條件 >> Cloudflare D1 SQLite 相容性持續維持
- [A-002] 三元組是知識的原子單位：所有產品線共用同一套三元組 Template（subject / predicate / object / confidence / source_block_id / context），謂詞（predicate）是知識的靈魂，區分「知道什麼」和「怎麼連結」
- A-002 >> 約束 >> 三元組萃取品質標準
- A-002 >> 支撐 >> 北極星（異見三元組累積）
- A-002 >> 邊條件 >> 謂詞詞彙表需人工維護或可控生成，避免同義爆炸
- [A-003] Entity 分兩類：person（用戶及 Ghost 虛擬人格）與 event（市場事件 / 競爭局勢 / 產品動態），使用內建 Entity Template，canonical_name 為唯一識別鍵，Alias Template 處理同義消歧
- A-003 >> 約束 >> Entity Resolution 流程設計
- A-003 >> 依賴 >> A-001（Entity 是 Block，不是獨立 table）
- [A-004] 雙引擎 AI 策略：Workers AI（Llama 系列）負責高頻低成本任務（三元組萃取、NPC 對話、embedding），Claude API 負責低頻高智任務（CEO 決策、複雜推理、Polaris 分析）
- A-004 >> 約束 >> 每個功能的 AI 模型選擇
- A-004 >> 邊條件 >> Cloudflare Workers AI 模型供應持續穩定
- A-004 >> 邊條件 >> Claude API 定價與速率限制在可承受範圍
- [A-005] 治理架構四層分離：董事長（richblack，最終決策）→ CEO（Claude.ai，戰略與任務分解，不寫程式）→ COO（Workers AI Bot，24/7 自動化監控）→ CTO（Claude Code on Linode，寫程式與部署），指令鏈不可跳層
- A-005 >> 約束 >> 所有開發流程與通訊協議
- A-005 >> 源自 >> 審計追蹤與責任歸屬需求
- A-005 >> 邊條件 >> Telegram Bot API 做為通訊管道持續可用
- [A-006] 所有產品線共用 KBDB 底層：finally.click、Minime、書僮、配對平台、u6u 是不同的採集管道，寫入同一個三元組圖譜，用 user_id + source 區分來源
- A-006 >> 約束 >> 多租戶隔離與資料歸屬設計
- A-006 >> 支撐 >> 北極星（多管道匯聚三元組）
- [A-007] Ghost 人格由真實對話三元組派生：六個虛擬人格（Maya / Linda / Yuki / Evan / Alex / Ryan）的行為模式從用戶群的高頻三元組模式生成，不是靜態 prompt，需達到最低三元組密度才能啟動
- A-007 >> 約束 >> Ghost 聊天品質的啟動門檻
- A-007 >> 依賴 >> A-002（三元組品質）
- A-007 >> 邊條件 >> 足夠的真實用戶對話資料已累積
- [A-008] Cypher Workflow 是內部執行引擎：以零件組合方式定義自動化流程（類 n8n 但更輕量），節點描述執行步驟，邊描述依賴關係，由 COO Bot 拓撲排序後平行執行
- A-008 >> 約束 >> 所有自動化任務的編排方式
- A-008 >> 依賴 >> A-005（COO 執行角色）
- [A-001] KBDB 萬用表架構不可變：永遠只有 blocks / templates / slots 三張表，所有資料結構皆以 Template + Slot 實現，任何需求不得新增 table 或 ALTER TABLE
- [Epic-1] KBDB 三元組引擎
- 描述：在 KBDB 萬用表之上實現三元組的完整生命週期——寫入、查詢、更新、刪除、向量搜尋、圖遍歷——做為所有產品線的共用知識底層
- Epic-1 >> 指向北極星 >> 提供異見三元組的儲存與檢索基礎設施
- Epic-1 >> 依賴 >> A-001（萬用表架構不可變）
- Epic-1 >> 依賴 >> A-002（三元組 Template 規格）
- [US-001] 三元組 CRUD 與驗證
- 身為系統管理員，我希望能透過 REST API 建立、讀取、更新、刪除三元組，並自動驗證 subject / predicate / object 非空、confidence 介於 0-1，以確保資料品質
- EARS 需求
- When 呼叫 POST /triplets 且 payload 合法，系統 shall 建立對應 Block + Slots 並回傳 201 + block_id
- If subject 或 predicate 或 object 為空，系統 shall 回傳 400 + 錯誤訊息
- While 三元組 Block 存在，GET /triplets/:id shall 回傳完整 subject / predicate / object / confidence / context
- When 呼叫 DELETE /triplets/:id，系統 shall 軟刪除 Block 並保留審計紀錄
- Design 決策
- 三元組寫入時同步觸發 embedding 生成（Workers AI text-embedding），寫入 blocks.embedding 欄位
- confidence 預設為 0.5（機器萃取），user 手動確認時提升至 1.0
- 刪除為軟刪除（標記 deleted_at），以支援審計回溯
- US-001 >> 實現 >> Epic-1
- US-001 >> 依賴 >> A-001（三元組以 Block + Slot 實現）
- US-001 >> 替代路徑 >> 直接寫入 Block + Slot 的低階 API（繞過 /triplets 封裝）
- US-001 >> 邊條件 >> KBDB Worker 正常運行
- US-001 >> 指向北極星 >> 三元組寫入是所有採集的終點站
- [Task-001] 實作三元組寫入 API（POST /triplets）
- 接收 subject / predicate / object / confidence / user_id / context，建立 Block（template_id = triplet_template）+ 六個 Slot，同步呼叫 Workers AI embedding 寫入 blocks.embedding
- Task-001 >> 實現 >> US-001
- Task-001 >> 依賴 >> Triplet Template 已部署於 KBDB
- Task-001 >> 修改 >> KBDB Worker /triplets POST 端點
- [Task-002] 實作三元組查詢 API（GET /triplets）
- 支援 subject / predicate / object / user_id 過濾參數，JOIN slots 組裝回三元組結構，分頁回傳
- Task-002 >> 實現 >> US-001
- Task-002 >> 依賴 >> Task-001（寫入端點先完成才有資料可查）
- [Task-003] 實作三元組更新與刪除 API
- PUT /triplets/:id 更新 Slot value；DELETE /triplets/:id 軟刪除 Block（設 deleted_at）
- Task-003 >> 實現 >> US-001
- Task-003 >> 依賴 >> Task-001
- [US-002] 三元組向量語意搜尋
- 身為 Minime 服務，我希望能用自然語言查詢語意相近的三元組，以支撐 AI 對話時的知識檢索
- EARS 需求
- When 呼叫 GET /search?q=<自然語言>&type=triplet，系統 shall 將 query embedding 與 blocks.embedding 比對，回傳 top-K 三元組
- If 指定 user_id 參數，搜尋範圍 shall 限縮至該用戶
- While Vectorize 索引未同步完成，系統 shall 回傳最近一次一致性快照的結果
- Design 決策
- 使用 Cloudflare Vectorize 做 ANN 搜尋，維度 1536（對齊 Workers AI embedding 模型）
- 搜尋結果附帶 distance score，呼叫端自行決定閾值
- US-002 >> 實現 >> Epic-1
- US-002 >> 依賴 >> US-001（三元組須先寫入才能搜尋）
- US-002 >> 依賴 >> A-004（Workers AI 提供 embedding）
- US-002 >> 替代路徑 >> 全文搜尋 ILIKE ‘%keyword%‘（降級方案，品質較差）
- US-002 >> 邊條件 >> Cloudflare Vectorize 服務可用
- US-002 >> 指向北極星 >> 語意搜尋讓已累積的三元組可被 AI 有效利用
- [Task-004] 整合 Cloudflare Vectorize 索引
- 三元組 Block 寫入時同步 upsert Vectorize 索引，刪除時移除索引
- Task-004 >> 實現 >> US-002
- Task-004 >> 依賴 >> Task-001（embedding 在寫入時生成）
- [Task-005] 實作語意搜尋端點（GET /search）
- 接收 query 文字，呼叫 Workers AI 生成 query embedding，查詢 Vectorize，JOIN blocks + slots 組裝結果
- Task-005 >> 實現 >> US-002
- Task-005 >> 依賴 >> Task-004（Vectorize 索引已建立）
- [US-003] 三元組圖遍歷
- 身為 Polaris 系統，我希望能從某個 Entity 出發，沿三元組的 subject-object 關係遍歷 N 層鄰居，以建構局部知識子圖
- EARS 需求
- When 呼叫 GET /graph?entity=
&depth=N，系統 shall 回傳以該 entity 為中心、深度 N 的三元組子圖（節點 + 邊） - If depth > 3，系統 shall 截斷並回傳警告，避免爆炸性展開
- Where entity 同時出現在 subject 和 object 位置，系統 shall 雙向遍歷
- When 呼叫 GET /graph?entity=
- Design 決策
- BFS 遍歷，每層 JOIN slots 找 subject = entity 或 object = entity 的 Block
- 回傳格式：{ nodes: [{id, name, type}], edges: [{source, target, predicate}] }
- 限制單次遍歷最大節點數 500，超過則截斷
- US-003 >> 實現 >> Epic-1
- US-003 >> 依賴 >> US-001（需有三元組資料）
- US-003 >> 依賴 >> A-003（Entity 結構定義）
- US-003 >> 替代路徑 >> 語意搜尋 + 人工組裝子圖（效率低但可用）
- US-003 >> 邊條件 >> 三元組密度足以形成連通子圖
- US-003 >> 指向北極星 >> 圖遍歷是搭橋者偵測的前置能力
- [Task-006] 實作 BFS 圖遍歷引擎
- 從起點 entity 出發，逐層 JOIN slots 查 subject/object 匹配，收集節點與邊，BFS 到指定深度
- Task-006 >> 實現 >> US-003
- Task-006 >> 依賴 >> Task-002（查詢能力）
- [Task-007] 實作 /graph API 端點
- 封裝 Task-006 引擎，加入深度限制、節點上限、雙向遍歷參數，回傳 JSON 子圖
- Task-007 >> 實現 >> US-003
- Task-007 >> 依賴 >> Task-006
- [Epic-2] Entity 解析與別名管理
- 描述：實現 Entity 的建立、合併、別名消歧，確保不同來源提到同一實體時能正確歸一，避免知識圖譜碎片化
- Epic-2 >> 指向北極星 >> Entity 歸一是三元組品質的基石，沒有歸一就沒有可靠的搭橋者偵測
- Epic-2 >> 依賴 >> Epic-1（三元組引擎提供底層儲存）
- Epic-2 >> 依賴 >> A-003（Entity 分類與 Alias 規格）
- [US-004] Entity CRUD 與自動偵測
- 身為三元組萃取服務，我希望在寫入三元組時自動偵測 subject / object 是否為已知 Entity，若否則建立新 Entity Block，以維持圖譜一致性
- EARS 需求
- When 三元組寫入時 subject 或 object 不匹配任何已知 Entity canonical_name 或 alias，系統 shall 自動建立新 Entity Block（type 由 Workers AI 推斷）
- If subject 或 object 匹配已知 alias，系統 shall 將三元組連結到對應的 canonical Entity
- While 新 Entity 建立，系統 shall 同步生成 embedding 並索引
- Design 決策
- 匹配順序：exact canonical_name → exact alias → embedding 相似度 > 0.92 → 建立新 Entity
- 自動推斷的 Entity type 信心度低（confidence=0.6），需後續人工確認或提升
- US-004 >> 實現 >> Epic-2
- US-004 >> 依賴 >> US-001（三元組寫入觸發 Entity 偵測）
- US-004 >> 替代路徑 >> 全部手動建立 Entity（不擴展但可用於冷啟動）
- US-004 >> 邊條件 >> Workers AI embedding 模型一致性（模型更換會破壞相似度閾值）
- US-004 >> 指向北極星 >> 自動歸一減少人工成本，加速三元組累積
- [Task-008] 實作 Entity 自動偵測管道
- 三元組寫入後觸發：查 canonical_name → 查 alias → embedding 比對 → 決定匹配或新建
- Task-008 >> 實現 >> US-004
- Task-008 >> 依賴 >> Task-001（三元組寫入為觸發點）
- Task-008 >> 依賴 >> Entity Template 與 Alias Template 已部署
- [Task-009] 實作 Entity CRUD 端點（/entities）
- POST /entities 建立、GET /entities/:id 讀取、GET /entities?type=person 過濾、PUT /entities/:id 更新 canonical_name
- Task-009 >> 實現 >> US-004
- Task-009 >> 依賴 >> A-001（Entity 是 Block + Slot 實現）
- [US-005] 別名管理與合併
- 身為知識管理員，我希望能手動添加別名、合併重複 Entity、查看別名歸屬，以修正自動解析的錯誤
- EARS 需求
- When 呼叫 POST /entities/:id/aliases 且 alias 不與其他 Entity 衝突，系統 shall 建立 Alias Block 指向目標 Entity
- If alias 已歸屬另一個 Entity，系統 shall 回傳 409 衝突並提示合併
- When 呼叫 POST /entities/merge 指定 source_id 和 target_id，系統 shall 將 source 的所有三元組與別名遷移到 target，軟刪除 source
- Design 決策
- 合併為不可逆操作（但軟刪除的 source Entity 保留 30 天）
- 合併後觸發全圖重算受影響的三元組 embedding（因為 entity context 改變）
- US-005 >> 實現 >> Epic-2
- US-005 >> 依賴 >> US-004（Entity 已存在才能管理別名）
- US-005 >> 替代路徑 >> 批次 CSV 匯入別名對照表（適用冷啟動大量資料匯入）
- US-005 >> 邊條件 >> 合併操作需有審計紀錄以支援回溯
- US-005 >> 指向北極星 >> 別名歸一確保搭橋者偵測不會因命名差異遺漏關鍵節點
- [Task-010] 實作別名 CRUD 端點（/entities/:id/aliases）
- POST 建立別名 Block（entity_block_id + alias + source + confidence），GET 列出某 Entity 的所有別名
- Task-010 >> 實現 >> US-005
- Task-010 >> 依賴 >> Task-009（Entity 端點先完成）
- [Task-011] 實作 Entity 合併端點（POST /entities/merge）
- 遷移 source 的三元組（更新 subject/object slot value）、遷移別名、軟刪除 source Block
- Task-011 >> 實現 >> US-005
- Task-011 >> 依賴 >> Task-010
- Task-011 >> 依賴 >> Task-001（需更新三元組 Slot）
- [US-006] Entity 解析 API（/entities/resolve）
- 身為任何採集管道，我希望給定一個名稱字串，系統回傳最可能的 Entity 或建議列表，以統一所有管道的 Entity 識別
- 實作現況：resolve 邏輯內嵌於 /entities/pending/:id/confirm 與 reject，無獨立 /entities/resolve 端點
- US-006 >> 實作現況 >> partial（邏輯存在，缺獨立端點）
- US-006 >> 待決策 >> 補建獨立端點 vs 維持現有內嵌邏輯
- EARS 需求
- When 呼叫 GET /entities/resolve?name=
，系統 shall 依序嘗試 exact match → alias match → embedding match，回傳排序後的候選清單 - If 無任何候選（全部 similarity < 0.7），系統 shall 回傳空列表 + suggest_create=true
- When 呼叫 GET /entities/resolve?name=
- Design 決策
- 回傳格式：[{entity_id, canonical_name, match_type, confidence}]
- 快取高頻查詢結果 60 秒（Workers KV）
- US-006 >> 實現 >> Epic-2
- US-006 >> 依賴 >> US-004（Entity 與 Alias 資料已存在）
- US-006 >> 替代路徑 >> 呼叫端自行查 /entities + /triplets 組裝（可行但重複邏輯）
- US-006 >> 邊條件 >> Workers KV 快取服務可用
- US-006 >> 指向北極星 >> 統一解析確保不同管道寫入的三元組能正確連結
- [Task-012] 實作 /entities/resolve 端點
- 接收 name 字串，依序查 canonical_name → alias → embedding 相似度，組裝候選清單回傳
- Task-012 >> 實現 >> US-006
- Task-012 >> 依賴 >> Task-009（Entity 端點）
- Task-012 >> 依賴 >> Task-010（Alias 端點）
- [Task-013] 實作高頻解析結果快取
- 用 Workers KV 快取 resolve 結果，TTL=60s，Entity 更新或合併時 invalidate 相關快取
- Task-013 >> 實現 >> US-006
- Task-013 >> 依賴 >> Task-012
- [Epic-3] 三元組萃取管道
- 描述：從各產品線的原始對話 / 筆記 / 行為資料中，自動萃取結構化三元組，寫入 KBDB，是所有採集管道的共用處理核心
- Epic-3 >> 指向北極星 >> 萃取是從原始資料到異見三元組的轉化引擎
- Epic-3 >> 依賴 >> Epic-1（三元組引擎提供寫入）
- Epic-3 >> 依賴 >> Epic-2（Entity 解析確保歸一）
- [US-007] 對話三元組萃取（高頻管道）
- 身為 Minime / 書僮服務，我希望將用戶對話即時送入萃取管道，自動產出三元組並寫入 KBDB，以持續累積用戶知識圖譜
- EARS 需求
- When 對話訊息進入萃取佇列，系統 shall 在 5 秒內呼叫 Workers AI（Llama）萃取三元組
- If 萃取結果的 confidence < 0.3，系統 shall 丟棄該三元組並記錄 log
- While 萃取服務繁忙，新訊息 shall 排入 Queue 等候，不得遺失
- If Workers AI 回傳非預期格式，系統 shall 重試一次後標記為 extraction_failed
- Design 決策
- 萃取 prompt 明確要求 JSON array 格式：[{subject, predicate, object, confidence}]
- 遵守萃取原則：萃取事實 / 定義 / 關係，不萃取 todo / 流水帳 / 操作記錄
- 每則訊息最多萃取 5 條三元組（避免過度萃取垃圾）
- US-007 >> 實現 >> Epic-3
- US-007 >> 依賴 >> US-001（三元組寫入 API）
- US-007 >> 依賴 >> US-006（Entity 解析）
- US-007 >> 依賴 >> A-004（Workers AI 負責萃取）
- US-007 >> 替代路徑 >> 人工標註三元組（品質最高但不擴展，適用冷啟動語料）
- US-007 >> 邊條件 >> Workers AI Llama 模型推論延遲 < 5 秒
- US-007 >> 指向北極星 >> 對話是搭橋者異見的主要來源
- [Task-014] 實作三元組萃取 Worker（mini-me worker）
- 接收對話文本，構建萃取 prompt，呼叫 Workers AI Llama，解析 JSON 結果，逐條寫入 /triplets
- Task-014 >> 實現 >> US-007
- Task-014 >> 依賴 >> Task-001（/triplets POST）
- Task-014 >> 修改 >> mini-me Worker 萃取模組
- [Task-015] 實作萃取佇列（Cloudflare Queue）
- 對話訊息進入 Queue，萃取 Worker 作為 consumer，批次處理，失敗重試 3 次後進入 DLQ
- Task-015 >> 實現 >> US-007
- Task-015 >> 依賴 >> Task-014（consumer 邏輯）
- [Task-016] 實作萃取品質過濾器
- confidence < 0.3 丟棄；subject/predicate/object 長度 > 200 字丟棄；重複三元組偵測（embedding 相似度 > 0.95 且同 user_id）
- Task-016 >> 實現 >> US-007
- Task-016 >> 依賴 >> Task-014
- [US-008] 行為三元組萃取（記帳 / 健康 / 筆記）
- 身為 Minime 服務，我希望將用戶的結構化行為資料（記帳、健康紀錄、筆記標籤）轉化為行為三元組，以豐富人格圖譜的非對話維度
- EARS 需求
- When 用戶新增一筆記帳 Block，系統 shall 自動萃取行為三元組（例：richblack >> 消費 >> 鋼筆墨水，richblack >> 偏好品類 >> 文具）
- If 行為模式重複出現 >= 3 次，系統 shall 生成彙總三元組（例：richblack >> 高頻消費 >> 咖啡）
- While 行為資料類型為純數字（金額、血壓），系統 shall 不直接萃取，而是等待彙總閾值
- Design 決策
- 行為萃取走規則引擎（Template schema → 對應萃取規則），不走 LLM，降低成本
- 彙總三元組每日 batch 計算一次（Cron Trigger）
- US-008 >> 實現 >> Epic-3
- US-008 >> 依賴 >> US-001（三元組寫入）
- US-008 >> 替代路徑 >> 全走 LLM 萃取（可行但成本高，適用於規則未覆蓋的 Template）
- US-008 >> 邊條件 >> 記帳 / 健康 Template 已定義且有足夠資料
- US-008 >> 指向北極星 >> 行為三元組補充對話萃取的盲區，完善人格全貌
- [Task-017] 設計行為萃取規則引擎
- 定義 Template schema → 三元組映射規則（例：bookkeeping.category →
>> 消費 >> ） - Task-017 >> 實現 >> US-008
- Task-017 >> 依賴 >> A-001（Template schema 結構）
- 定義 Template schema → 三元組映射規則（例：bookkeeping.category →
- [Task-018] 實作每日彙總 Cron Job
- Cloudflare Cron Trigger，每日 02:00 UTC，掃描前 24hr 行為 Block，計算重複模式，生成彙總三元組
- Task-018 >> 實現 >> US-008
- Task-018 >> 依賴 >> Task-017（規則引擎定義）
- [US-009] 群組對話採集（書僮管道）
- 身為書僮 LINE Bot，我希望在加入群組後靜默採集對話，萃取三元組但不主動發言（除非被 @ 提及），以低侵入方式累積群體知識
- EARS 需求
- When 書僮加入 LINE 群組，系統 shall 開始接收群組訊息但不回覆
- If 訊息中 @ 提及書僮，系統 shall 以 NPC 品質回覆（Workers AI），不強制高品質
- While 採集進行中，每則訊息 shall 經由 US-007 萃取管道處理
- Where 群組成員未同意隱私條款，系統 shall 僅萃取去識別化三元組（匿名化 subject）
- Design 決策
- 群組訊息以 source=line_group, source_id=group_id 標記
- NPC 回覆使用 Workers AI Llama，不消耗 Claude API 額度
- 用戶可自帶 API key 升級為高品質回覆
- US-009 >> 實現 >> Epic-3
- US-009 >> 依賴 >> US-007（共用萃取管道）
- US-009 >> 替代路徑 >> Discord Bot 採集（同樣邏輯，不同平台 API）
- US-009 >> 邊條件 >> LINE Bot 政策允許群組訊息讀取
- US-009 >> 邊條件 >> LINE Messaging API 免費額度足以支撐初期用量
- US-009 >> 指向北極星 >> 群組對話是異見三元組的高密度來源（多人觀點碰撞）
- [Task-019] 實作書僮 LINE Bot Webhook Handler
- 接收 LINE Messaging API webhook，區分 @mention 與一般訊息，轉發至萃取佇列
- Task-019 >> 實現 >> US-009
- Task-019 >> 依賴 >> Task-015（萃取佇列）
- [Task-020] 實作群組隱私匿名化模組
- 未同意隱私條款的群組成員，subject 替換為 anonymous_
，保留三元組結構但去除個人識別 - Task-020 >> 實現 >> US-009
- Task-020 >> 依賴 >> Task-014（萃取流程中嵌入匿名化步驟）
- 未同意隱私條款的群組成員，subject 替換為 anonymous_
- [Epic-4] Ghost 人格系統
- 描述：基於真實對話三元組派生六個虛擬人格（Maya / Linda / Yuki / Evan / Alex / Ryan），作為 finally.click 交友場景的 AI 配對對象，行為模式動態更新而非靜態 prompt
- Epic-4 >> 指向北極星 >> Ghost 用引人入勝的對話延長互動時間，間接增加三元組採集量
- Epic-4 >> 依賴 >> Epic-3（需要足夠的真實對話三元組作為派生來源）
- Epic-4 >> 依賴 >> A-007（Ghost 派生規則）
- [US-010] Ghost 人格三元組派生
- 身為 Ghost 系統，我希望從真實用戶群的高頻三元組模式中提煉出每個 Ghost 的性格三元組集合，使 Ghost 具備可辨識且穩定的人格特質
- EARS 需求
- When 三元組資料庫中某類 predicate 的出現次數達到閾值 N，系統 shall 觸發 Ghost 性格更新流程
- If Ghost 的性格三元組集合 < 50 條，該 Ghost shall 標記為 dormant 不參與配對
- While Ghost 性格更新進行中，舊版性格 shall 繼續服務直到新版通過一致性檢查
- Design 決策
- 每個 Ghost 有一個性格向量（由其性格三元組的 embedding 平均而成）
- 性格更新為週期性 batch（每週一次），由 CEO Agent 觸發
- Ghost Entity 的 type = person，canonical_name = Ghost 名稱
- US-010 >> 實現 >> Epic-4
- US-010 >> 依賴 >> US-002（向量搜尋取得高頻模式）
- US-010 >> 依賴 >> US-003（圖遍歷分析三元組聚類）
- US-010 >> 替代路徑 >> 人工策展 Ghost 性格三元組（品質可控但不擴展）
- US-010 >> 邊條件 >> 真實用戶對話三元組密度 >= N（待用資料分析決定閾值）
- US-010 >> 指向北極星 >> Ghost 品質提升 → 用戶互動增加 → 更多異見三元組
- [Task-021] 設計 Ghost 性格三元組聚類演算法
- 對全域三元組做 predicate 頻率分析，提取 top-K 模式，用 K-means/DBSCAN 聚為 6 群（對應 6 個 Ghost）
- Task-021 >> 實現 >> US-010
- Task-021 >> 依賴 >> Task-005（語意搜尋支撐聚類）
- [Task-022] 實作 Ghost 性格更新 Cron Job
- 每週觸發，執行聚類 → 生成性格三元組 → 計算性格向量 → 更新 Ghost Entity
- Task-022 >> 實現 >> US-010
- Task-022 >> 依賴 >> Task-021
- Task-022 >> 依賴 >> Task-009（更新 Ghost Entity）
- [US-011] Ghost 聊天引擎
- 身為 finally.click 用戶，我希望與 Ghost 聊天時感受到一致的性格特質和有見地的回覆，而不是通用 AI 答覆
- EARS 需求
- When 用戶向 Ghost 發送訊息，系統 shall 檢索該 Ghost 的性格三元組作為 context，生成符合人格的回覆
- If Ghost 狀態為 dormant，系統 shall 回覆「我還在學習中，過陣子再聊」並引導用戶與其他 Ghost 互動
- While 對話進行中，系統 shall 將用戶訊息同步送入萃取管道
- Design 決策
- 聊天用 Workers AI（成本考量），以 Ghost 性格三元組 + 最近 10 輪對話為 context
- 若用戶自帶 API key，切換至 Claude API 提升品質
- US-011 >> 實現 >> Epic-4
- US-011 >> 依賴 >> US-010（Ghost 性格三元組已就緒）
- US-011 >> 依賴 >> US-007（對話同步萃取）
- US-011 >> 替代路徑 >> 書僮採集模式（不主動聊天，但仍可在群組被動採集，達到同樣北極星）
- US-011 >> 邊條件 >> Workers AI 推論延遲 < 3 秒（影響聊天體驗）
- US-011 >> 指向北極星 >> Ghost 對話既是產品體驗也是三元組採集的雙重價值
- [Task-023] 實作 Ghost 聊天 Prompt 組裝器
- 從 KBDB 檢索 Ghost 性格三元組 top-20（by relevance），組裝 system prompt + 對話歷史 + 用戶訊息
- Task-023 >> 實現 >> US-011
- Task-023 >> 依賴 >> Task-005（語意搜尋取性格三元組）
- [Task-024] 實作 Ghost 聊天 API 端點
- 實際路徑：POST /chat + persona_user_id 參數（Persona 模式），功能等效於規格的 /ghost/:name/chat，路徑不同但語義相同
- Task-024 >> 實現 >> US-011
- Task-024 >> 依賴 >> Task-023
- Task-024 >> 依賴 >> Task-015（萃取佇列）
- Task-024 >> 實作現況 >> done（mini-me /chat Persona 模式）
- Task-024 >> 實作差異 >> API 路徑為 POST /chat?persona_user_id=X，非 /ghost/:name/chat
- [US-012] Ghost 行為從對話三元組動態演化
- 身為 Ghost 系統管理員，我希望 Ghost 的行為模式能隨著新的真實對話三元組持續演化，而非凍結在某個時間點
- EARS 需求
- When 新的聚類結果與舊版性格向量的 cosine distance > 0.15，系統 shall 標記為「顯著演化」並通知 CEO Agent 審核
- If CEO Agent 批准演化，系統 shall 更新 Ghost 性格三元組並廣播通知所有使用該 Ghost 的活躍 session
- While 演化審核中，Ghost shall 繼續使用舊版性格
- Design 決策
- 演化審核由 CEO Agent（Claude API）執行，判斷是否符合產品定位
- 保留歷史版本（每次更新建立新 Block，舊 Block 軟刪除但保留）
- US-012 >> 實現 >> Epic-4
- US-012 >> 依賴 >> US-010（性格更新流程）
- US-012 >> 依賴 >> A-005（CEO Agent 審核權限）
- US-012 >> 替代路徑 >> 自動演化不審核（速度快但風險高，品質失控）
- US-012 >> 邊條件 >> CEO Agent 回應時間 < 24hr（否則阻塞演化流程）
- US-012 >> 指向北極星 >> 動態演化保持 Ghost 鮮活度，用戶不會對「固定人設」失去興趣
- [Task-025] 實作性格版本比較與演化偵測
- 新舊性格向量 cosine distance 計算，超過閾值觸發 CEO 審核流程
- Task-025 >> 實現 >> US-012
- Task-025 >> 依賴 >> Task-022（性格更新產出新版向量）
- [Task-026] 實作 CEO Agent 演化審核 Workflow
- Cypher Workflow：接收演化報告 → 呼叫 Claude API 分析 → 批准 / 駁回 → 更新或保留
- Task-026 >> 實現 >> US-012
- Task-026 >> 依賴 >> Task-025
- Task-026 >> 依賴 >> A-008（Cypher Workflow 執行引擎）
- [Epic-5] Polaris 關係圖與搭橋者偵測
- 描述：建構用戶 / Ghost / 事件之間的全局知識圖譜（Polaris），基於圖論指標偵測高 betweenness centrality 的搭橋者節點，這是整個 VM 的核心價值引擎
- Epic-5 >> 指向北極星 >> Polaris 是辨識搭橋者的演算法層，直接產出 VM 的核心資產
- Epic-5 >> 依賴 >> Epic-1（圖遍歷能力）
- Epic-5 >> 依賴 >> Epic-2（Entity 歸一確保圖的正確性）
- [US-013] Polaris 密度計算與分層
- 身為 Minime 系統，我希望為每個用戶計算 Polaris 密度（三元組數量 / 涵蓋 predicate 類別數 / 連通度），並據此分層決定可啟用的功能等級
- 實作現況：密度計算邏輯分散於 bridge-score.ts / diversity.ts / fingerprint.ts / lsh.ts / cluster-label.ts，功能存在但無統一 Polaris 密度物件封裝
- US-013 >> 實作現況 >> partial（計算模組存在，缺統一封裝與分層 Feature Gate）
- EARS 需求
- When 用戶的三元組數量增加，系統 shall 即時更新密度分數
- If 密度 < Level-1 閾值，用戶功能 shall 限於書僮模式（純採集）
- If 密度達 Level-2，用戶 shall 解鎖 Polaris 圖視覺化
- If 密度達 Level-3，用戶 shall 解鎖 CEO 分身（「你會怎麼做？」）
- If 兩個用戶皆達 Level-2，系統 shall 允許計算配對距離
- Design 決策
- 密度 = f(三元組總數, 唯一 predicate 數, 跨 domain 連結數)，具體權重待 A/B 測試
- 分層閾值初始：Level-1 = 30 三元組, Level-2 = 200 三元組 + 15 種 predicate, Level-3 = 500 三元組 + 30 種 predicate + 跨 3 domain
- 密度分數快取於 Workers KV，寫入三元組時 invalidate
- US-013 >> 實現 >> Epic-5
- US-013 >> 依賴 >> US-001（三元組數量統計）
- US-013 >> 依賴 >> US-003（連通度需圖遍歷）
- US-013 >> 替代路徑 >> 純三元組數量做為單一指標（簡化但無法區分深度與廣度）
- US-013 >> 邊條件 >> 密度計算延遲不影響用戶體驗（< 500ms）
- US-013 >> 指向北極星 >> 密度分層驅動用戶往更深層互動，產出更多高品質三元組
- [Task-027] 設計密度計算公式與分層閾值
- 定義 density = w1 * triplet_count + w2 * unique_predicates + w3 * cross_domain_links，初始權重與閾值
- Task-027 >> 實現 >> US-013
- Task-027 >> 依賴 >> Task-002（三元組查詢統計）
- [Task-028] 實作密度計算 Worker
- 三元組寫入後非同步觸發，更新密度分數至 Workers KV，檢查分層升級
- Task-028 >> 實現 >> US-013
- Task-028 >> 依賴 >> Task-027
- [Task-029] 實作功能閘門（Feature Gate）
- 根據 KV 中的密度等級，API 中間層攔截未達門檻的功能請求，回傳 403 + 升級提示
- Task-029 >> 實現 >> US-013
- Task-029 >> 依賴 >> Task-028
- [US-014] 搭橋者偵測演算法
- 身為 VM 核心引擎，我希望定期掃描全局 Polaris 圖，識別高 betweenness centrality 的節點（人或概念），標記為搭橋者，以指導配對與內容策略
- EARS 需求
- When Cron 觸發（每日 04:00 UTC），系統 shall 對全域 person/concept Entity 計算 betweenness centrality
- If Entity 的 betweenness centrality 排名 top 5%，系統 shall 標記為 bridge_builder 並通知 CEO Agent
- While 搭橋者偵測計算中，系統 shall 不鎖定讀取，使用快照一致性
- Design 決策
- 圖載入記憶體（Linode Node.js），用 Brandes 演算法計算 betweenness centrality
- 圖規模上限：初期 < 100K 節點可直接計算；超過後改用近似演算法（隨機取樣 pivot）
- 搭橋者標記寫回 KBDB 做為三元組（
>> 被標記為 >> bridge_builder）
- US-014 >> 實現 >> Epic-5
- US-014 >> 依賴 >> US-003（圖遍歷取得全域子圖）
- US-014 >> 依賴 >> US-004（Entity 歸一保證圖正確性）
- US-014 >> 替代路徑 >> 人工策展搭橋者（適用早期用戶量極少時）
- US-014 >> 邊條件 >> 圖規模 < 100K 節點（超過需切換近似演算法）
- US-014 >> 邊條件 >> Linode 節點有足夠記憶體載入圖
- US-014 >> 指向北極星 >> 這就是北極星本體——辨識出搭橋者
- [Task-030] 實作全域圖快照匯出
- 從 KBDB 匯出所有 Entity + Triplet，組裝為鄰接表格式，供 Brandes 演算法消費
- Task-030 >> 實現 >> US-014
- Task-030 >> 依賴 >> Task-007（/graph API）
- [Task-031] 實作 Brandes betweenness centrality
- Node.js 實現 Brandes 演算法，接收鄰接表，輸出每個節點的 centrality 分數
- Task-031 >> 實現 >> US-014
- Task-031 >> 依賴 >> Task-030（圖資料輸入）
- [Task-032] 實作搭橋者標記與通知
- 取 top 5% centrality 節點，寫入 bridge_builder 三元組，通知 CEO Agent via Telegram
- Task-032 >> 實現 >> US-014
- Task-032 >> 依賴 >> Task-031
- Task-032 >> 依賴 >> Task-001（寫入三元組）
- [US-015] 配對距離計算
- 身為 finally.click / 配對平台，我希望計算兩個用戶的 Polaris 圖距離，以支撐交友配對與黑客松組隊推薦
- EARS 需求
- When 呼叫 POST /match/distance 提供兩個 user_id，系統 shall 計算兩張 Polaris 子圖的距離分數
- If 任一用戶未達 Level-2 密度，系統 shall 回傳 412 + 提示密度不足
- Where 距離計算涉及 Ghost 的性格三元組，系統 shall 將 Ghost 視為標準 person Entity 參與計算
- Design 決策
- 距離 = 1 - cosine_similarity(user_A_graph_embedding, user_B_graph_embedding)
- graph_embedding = 該用戶所有三元組 embedding 的加權平均（高 confidence 權重大）
- 結果快取 1 小時（KV），用戶新增三元組時 invalidate
- US-015 >> 實現 >> Epic-5
- US-015 >> 依賴 >> US-013（密度分層做為前置門檻）
- US-015 >> 依賴 >> US-002（向量搜尋取 embedding）
- US-015 >> 替代路徑 >> 基於共同 predicate 數量的 Jaccard similarity（簡化版，不需 embedding）
- US-015 >> 邊條件 >> 兩個用戶的三元組 embedding 維度一致
- US-015 >> 指向北極星 >> 配對距離是 VM 商業化（交友 / 徵才 / 組隊）的核心能力
- [Task-033] 實作 Graph Embedding 計算
- 給定 user_id，取其所有三元組 embedding，加權平均生成 graph_embedding
- Task-033 >> 實現 >> US-015
- Task-033 >> 依賴 >> Task-005（語意搜尋取 embedding）
- [Task-034] 實作配對距離 API（POST /match/distance）
- 接收兩個 user_id，取各自 graph_embedding，計算 cosine distance，檢查密度門檻，回傳結果
- Task-034 >> 實現 >> US-015
- Task-034 >> 依賴 >> Task-033
- Task-034 >> 依賴 >> Task-029（功能閘門檢查密度）
- [Epic-6] Minime 個人 AI 助理
- 描述：面向 C 端用戶的統一入口，提供日常記帳 / 筆記 / 健康追蹤 / AI 對話功能，是三元組高頻採集的核心留存工具，也是 Polaris 密度從 0 到 Level-3 的成長路徑
- Epic-6 >> 指向北極星 >> Minime 是三元組採集的主要入口，用戶留存 = 三元組持續累積
- Epic-6 >> 依賴 >> Epic-1（KBDB 存取）
- Epic-6 >> 依賴 >> Epic-3（萃取管道）
- [US-016] Minime 對話與三元組採集
- 身為 Minime 用戶，我希望用自然語言和 Minime 聊天，系統在背景自動萃取三元組，我不需要知道三元組是什麼
- EARS 需求
- When 用戶發送訊息，Minime shall 以 Workers AI 回覆並同步觸發三元組萃取
- If 用戶的 Polaris 密度達 Level-3，Minime shall 在回覆中融入用戶的知識圖譜（「根據你之前提到的…」）
- While 用戶聊天頻率 < 1 次/週，Minime shall 降級為書僮模式（僅採集，不主動互動）
- Design 決策
- 回覆優先用 Workers AI，密度達 Level-2 以上的用戶可選擇切換 Claude API
- 對話歷史存為 Block（source=minime_chat），萃取後產生三元組 Block
- US-016 >> 實現 >> Epic-6
- US-016 >> 依賴 >> US-007（對話萃取管道）
- US-016 >> 依賴 >> US-013（密度分層決定功能等級）
- US-016 >> 替代路徑 >> 純文字筆記輸入（不用對話形式，用戶手動輸入知識點）
- US-016 >> 邊條件 >> Workers AI 回覆品質足以維持用戶留存
- US-016 >> 指向北極星 >> 每次對話都是三元組採集機會
- [Task-035] 實作 Minime 聊天 API 端點
- POST /minime/chat，接收用戶訊息，呼叫 Workers AI 回覆，非同步觸發萃取佇列
- Task-035 >> 實現 >> US-016
- Task-035 >> 依賴 >> Task-015（萃取佇列）
- [Task-036] 實作知識圖譜融入回覆（Level-3）
- 密度達 Level-3 的用戶，聊天時語意搜尋相關三元組注入 prompt context
- Task-036 >> 實現 >> US-016
- Task-036 >> 依賴 >> Task-005（語意搜尋）
- Task-036 >> 依賴 >> Task-029（功能閘門）
- [US-017] 結構化行為記錄（記帳 / 健康 / 筆記）
- 身為 Minime 用戶，我希望用自然語言記帳、記錄健康數據、寫筆記，系統自動解析為結構化資料，我不需要填表單
- EARS 需求
- When 用戶說「今天喝了兩杯咖啡 130 元」，系統 shall 自動辨識為記帳 Template 並建立 Block + Slots
- If 無法辨識屬於哪個 Template，系統 shall 建立純文字 Block 並標記待分類
- While 同一句話包含多筆記錄，系統 shall 拆分為多個 Block
- Design 決策
- Template 辨識用 Workers AI few-shot classification（prompt 中列出所有已定義 Template + 範例）
- 解析失敗率 > 20% 的 Template 需優化 prompt 或新增範例
- US-017 >> 實現 >> Epic-6
- US-017 >> 依賴 >> US-008（行為三元組萃取）
- US-017 >> 依賴 >> A-001（Template + Slot 結構）
- US-017 >> 替代路徑 >> 前端表單手動填寫（體驗差但資料品質高）
- US-017 >> 邊條件 >> Workers AI 解析準確率 >= 80%
- US-017 >> 指向北極星 >> 結構化行為資料是行為三元組的來源，補充對話維度
- [Task-037] 實作自然語言 → Template 辨識
- Workers AI few-shot prompt，輸入用戶文字，輸出 {template_name, parsed_fields}
- Task-037 >> 實現 >> US-017
- Task-037 >> 依賴 >> A-004（Workers AI）
- [Task-038] 實作結構化 Block 建立管道
- 辨識結果 → 建立 Block（template_id = matched_template）→ 建立 Slots → 觸發行為萃取
- Task-038 >> 實現 >> US-017
- Task-038 >> 依賴 >> Task-037
- Task-038 >> 依賴 >> Task-017（行為萃取規則引擎）
- [US-018] CEO 分身功能（Level-3）
- 身為 Polaris 密度達 Level-3 的用戶，我希望問 Minime「如果是我，我會怎麼看這件事？」，系統基於我的 Polaris 圖模擬我的思維模式回覆
- EARS 需求
- When 用戶觸發 CEO 分身模式（特定指令或 UI 按鈕），系統 shall 從 Polaris 圖提取核心三元組構建「思維模型」
- If 用戶的問題涉及圖中不存在的領域，系統 shall 明確告知「你的知識圖譜中沒有這方面的資料，我無法模擬」
- While CEO 分身模式啟動，系統 shall 使用 Claude API（需要高品質推理）
- Design 決策
- 思維模型 = 用戶 top-50 高 confidence 三元組 + 高 centrality 連結的三元組
- Claude API system prompt：「你是
的思維模型，基於以下知識圖譜回答問題…」 - 每次 CEO 分身呼叫消耗較高 token，需做速率限制
- US-018 >> 實現 >> Epic-6
- US-018 >> 依賴 >> US-013（Level-3 門檻）
- US-018 >> 依賴 >> US-003（圖遍歷取核心三元組）
- US-018 >> 依賴 >> A-004（Claude API 高品質推理）
- US-018 >> 替代路徑 >> Workers AI 低品質版本（降級但仍可運行，品質不保證）
- US-018 >> 邊條件 >> Claude API 速率限制允許即時回覆
- US-018 >> 邊條件 >> 用戶 Polaris 圖至少跨 3 個 domain
- US-018 >> 指向北極星 >> CEO 分身是 VM 的殺手級功能，驅動深度用戶持續投入更多三元組
- [Task-039] 實作思維模型組裝器
- 給定 user_id，取 top-50 三元組 + 高 centrality 鄰居三元組，組裝成結構化 context
- Task-039 >> 實現 >> US-018
- Task-039 >> 依賴 >> Task-005（語意搜尋）
- Task-039 >> 依賴 >> Task-007（圖遍歷）
- [Task-040] 實作 CEO 分身 API 端點
- POST /minime/ceo-mode，接收問題，組裝思維模型 → Claude API → 回傳，附帶速率限制
- Task-040 >> 實現 >> US-018
- Task-040 >> 依賴 >> Task-039
- Task-040 >> 依賴 >> Task-029（功能閘門 Level-3）
- [Epic-7] 產品線管道整合
- 描述：將 finally.click（交友）、配對平台（B2B）、u6u（企業接案）三個非 Minime 管道接入共用三元組底層，每個管道有獨立的前端與業務邏輯，但共用 KBDB + 萃取 + Polaris
- Epic-7 >> 指向北極星 >> 多管道匯聚異見三元組 + 現金流支撐 VM 持續運轉
- Epic-7 >> 依賴 >> Epic-1（共用 KBDB）
- Epic-7 >> 依賴 >> Epic-5（共用 Polaris 配對能力）
- [US-019] finally.click 愛情算命入口
- 身為 finally.click 用戶，我希望透過「愛情算命」互動遊戲回答問題，系統將我的回答轉化為人格三元組，同時給我有趣的算命結果
- 實作現況：僅有文案，無問卷邏輯、題目資料庫、結果頁面
- US-019 >> 實作現況 >> not-started
- EARS 需求
- When 用戶完成算命問卷（10-15 題），系統 shall 從回答中萃取 >= 5 條人格三元組
- If 用戶拒絕回答某題，系統 shall 跳過並不影響其餘萃取
- While 算命結果生成中，系統 shall 顯示有趣的 loading 動畫
- When 算命完成，系統 shall 引導用戶進入 Ghost 聊天（配對前的暖場）
- Design 決策
- 問卷設計需覆蓋 Big Five 人格維度，但以算命語言包裝
- 算命結果由 Workers AI 生成，混合真實人格分析 + 娛樂包裝
- 人格三元組格式：
>> 人格傾向 >> ， >> 價值觀 >>
- US-019 >> 實現 >> Epic-7
- US-019 >> 依賴 >> US-001（三元組寫入）
- US-019 >> 依賴 >> US-011（Ghost 聊天做為下一步引導）
- US-019 >> 替代路徑 >> 直接跳過算命進入 Ghost 聊天（採集速度慢但用戶流程短）
- US-019 >> 邊條件 >> 問卷完成率 >= 60%（否則單題採集三元組太少）
- US-019 >> 指向北極星 >> 算命是人格三元組的結構化採集入口
- [Task-041] 設計算命問卷與人格映射
- 設計 10-15 道問題，每道映射 1-2 個 Big Five 維度，定義回答 → 三元組的轉化規則
- Task-041 >> 實現 >> US-019
- Task-041 >> 依賴 >> A-002（三元組結構）
- [Task-042] 實作算命結果生成 API
- POST /finally/fortune，接收問卷回答，萃取人格三元組，生成算命結果文案，引導至 Ghost 聊天
- Task-042 >> 實現 >> US-019
- Task-042 >> 依賴 >> Task-041
- Task-042 >> 依賴 >> Task-001（三元組寫入）
- [US-020] B2B 配對平台接入
- 身為活動主辦方，我希望將參加者名單匯入系統，利用 Polaris 配對能力推薦最佳組隊 / 配對，以提升活動品質
- EARS 需求
- When 主辦方上傳參加者名單（CSV / API），系統 shall 為每位參加者建立或匹配 Entity
- If 參加者已有 Minime 帳號且密度達 Level-2，系統 shall 直接使用其 Polaris 圖
- If 參加者為新用戶，系統 shall 提供快速問卷（同 finally.click 算命）收集初始三元組
- When 主辦方請求配對，系統 shall 呼叫配對距離 API 計算所有兩兩距離，回傳推薦名單
- Design 決策
- 主辦方付費模式：按參加者人數計費
- 新用戶的快速問卷共用 finally.click 的人格映射
- 配對結果可視化為距離矩陣或推薦排名
- US-020 >> 實現 >> Epic-7
- US-020 >> 依賴 >> US-015（配對距離計算）
- US-020 >> 依賴 >> US-004（Entity 建立與匹配）
- US-020 >> 替代路徑 >> 人工配對（主辦方自行根據資料分組）
- US-020 >> 邊條件 >> 至少 50% 參加者有足夠密度或完成快速問卷
- US-020 >> 指向北極星 >> B2B 帶來現金流（VM 運轉）+ 批次三元組採集（企業 + 個人）
- [Task-043] 實作參加者批次匯入 API
- POST /platform/import，接收 CSV 或 JSON 名單，逐一建立 / 匹配 Entity，回傳匹配報告
- Task-043 >> 實現 >> US-020
- Task-043 >> 依賴 >> Task-012（Entity 解析）
- [Task-044] 實作批次配對距離矩陣計算
- 給定參加者 user_id 列表，計算所有兩兩配對距離，回傳排序後的推薦矩陣
- Task-044 >> 實現 >> US-020
- Task-044 >> 依賴 >> Task-034（配對距離 API）
- [US-021] u6u B2B 企業 AI 工具接入
- 身為 u6u 企業客戶，我希望使用 AI 工具處理企業內部知識管理（FAQ、SOP、會議紀錄三元組化），同時為 VM 貢獻企業三元組
- EARS 需求
- When 企業上傳文件（PDF / Word / Notion export），系統 shall 萃取三元組並存入企業專屬 namespace
- If 企業選擇不分享三元組，系統 shall 隔離企業資料不參與全域 Polaris 計算
- While 企業訂閱有效，系統 shall 提供三元組搜尋 / 圖遍歷 / 知識問答功能
- Where 企業同意匿名化分享，系統 shall 將去識別化三元組併入全域圖
- Design 決策
- 企業 namespace = user_id 前綴（例：org_<company_id>_<user_id>）
- 隔離與分享的控制粒度到三元組等級（每條三元組有 share_global flag）
- 收費模式：月訂閱 + 超量三元組按量計費
- US-021 >> 實現 >> Epic-7
- US-021 >> 依賴 >> US-001（三元組寫入）
- US-021 >> 依賴 >> US-007（文件萃取管道）
- US-021 >> 替代路徑 >> 企業自建 RAG 系統（但失去 Polaris 配對能力）
- US-021 >> 邊條件 >> 企業合規要求允許 AI 處理其文件
- US-021 >> 指向北極星 >> 現金流（VM 運轉）+ 企業三元組（若匿名化分享則貢獻北極星）
- [Task-045] 實作企業 namespace 隔離
- user_id 前綴方案，所有 KBDB 查詢自動加 namespace 過濾，share_global slot 控制是否參與全域
- Task-045 >> 實現 >> US-021
- Task-045 >> 依賴 >> A-006（多租戶隔離設計）
- [Task-046] 實作文件上傳與萃取管道
- 接收 PDF / Word / Notion export，文本提取 → 分段 → 送入萃取佇列，結果寫入企業 namespace
- Task-046 >> 實現 >> US-021
- Task-046 >> 依賴 >> Task-015（萃取佇列）
- Task-046 >> 依賴 >> Task-045（namespace 隔離）
- [Epic-8] 治理與動態策略系統
- 描述：實現董事長-CEO-COO-CTO 四層治理架構、Cypher Workflow 自動化引擎、以及 G(t) 動態策略圖（衝擊模擬 = 邊消失 → 重算最優路徑），確保 VM 具備自我監控與自適應能力
- Epic-8 >> 指向北極星 >> 治理系統確保 VM 不偏離北極星，動態策略在環境變化時重算路徑
- Epic-8 >> 依賴 >> A-005（治理架構四層分離）
- Epic-8 >> 依賴 >> A-008（Cypher Workflow 引擎）
- [US-022] CEO Agent 戰略決策介面
- 身為董事長（richblack），我希望透過 Telegram 向 CEO Agent 下達戰略指令，CEO Agent 分解為可執行任務，分派給 COO 或 CTO，我不需要直接操作任何技術層
- EARS 需求
- When 董事長在 Telegram 發送指令，COO Bot shall 轉發至 CEO Agent（Claude API）
- If CEO Agent 判斷指令需要寫程式，CEO shall 建立 Task 並指派 CTO（不得自行執行）
- While 任務執行中，CEO shall 定期（每 15 分鐘或任務完成時）向董事長彙報進度
- If 任務失敗，CEO shall 分析原因並提出替代方案，不得自行重試超過 2 次
- Design 決策
- CEO Agent 使用 Claude API Opus/Sonnet，system prompt 注入 KBDB 業務 context
- 指令鏈：董事長 → Telegram → COO Bot → CEO Agent → CTO（通過 Cypher Workflow）
- 所有指令與結果記錄為 Block（source=ceo_audit），形成審計鏈
- US-022 >> 實現 >> Epic-8
- US-022 >> 依賴 >> A-005（指令鏈不可跳層）
- US-022 >> 依賴 >> Epic-1（審計紀錄存入 KBDB）
- US-022 >> 替代路徑 >> 董事長直接在 Claude.ai 操作 CEO Agent（失去審計鏈但可用於緊急狀況）
- US-022 >> 邊條件 >> Telegram Bot API 持續可用
- US-022 >> 邊條件 >> Claude API 回應延遲 < 30 秒
- US-022 >> 指向北極星 >> CEO Agent 確保所有開發活動對齊北極星
- [Task-047] 實作 COO Telegram Bot → CEO Agent 轉發
- Telegram webhook 接收訊息，格式化為 CEO prompt，呼叫 Claude API，回傳結果到 Telegram
- Task-047 >> 實現 >> US-022
- Task-047 >> 依賴 >> A-005（通訊協議）
- [Task-048] 實作 CEO 任務分解與分派
- CEO Agent 輸出結構化任務列表（JSON），COO 解析後建立 Cypher Workflow 節點並分派
- Task-048 >> 實現 >> US-022
- Task-048 >> 依賴 >> Task-047
- Task-048 >> 依賴 >> A-008（Cypher Workflow）
- [US-023] Cypher Workflow 執行引擎
- 身為 COO Bot，我希望接收零件化的 Workflow 定義（nodes + edges），自動拓撲排序並平行執行獨立節點，以高效完成自動化任務
- EARS 需求
- When 收到 Cypher Workflow 定義（nodes 陣列 + edges 陣列），系統 shall 驗證 DAG 結構（無環）
- If 偵測到環，系統 shall 拒絕執行並回傳錯誤
- While 執行中，無依賴的節點 shall 平行執行
- When 某節點失敗，系統 shall 標記下游節點為 blocked 並通知 CEO Agent
- Design 決策
- 節點 type 對應已註冊的 Component（API 呼叫 / KBDB 操作 / AI 推論 / 通知）
- 執行狀態儲存於 Workers KV（workflow_id → 狀態 JSON）
- 超時設定：單節點最長 5 分鐘，整體 Workflow 最長 30 分鐘
- US-023 >> 實現 >> Epic-8
- US-023 >> 依賴 >> A-008（Cypher Workflow 規格）
- US-023 >> 替代路徑 >> 逐步手動觸發（不平行，但適用於調試）
- US-023 >> 邊條件 >> Component Registry 中的零件已部署且健康
- US-023 >> 指向北極星 >> Cypher Workflow 是 VM 自動化運轉的骨幹
- [Task-049] 實作 DAG 驗證與拓撲排序
- 接收 nodes + edges JSON，驗證 DAG，輸出拓撲排序後的執行序列（含平行分組）
- Task-049 >> 實現 >> US-023
- Task-049 >> 依賴 >> A-008
- [Task-050] 實作平行執行引擎
- 按拓撲排序分組執行，同組節點 Promise.all 平行，節點失敗時標記下游 blocked
- Task-050 >> 實現 >> US-023
- Task-050 >> 依賴 >> Task-049
- [Task-051] 實作 Component Registry
- 註冊可用零件（Worker URL + 輸入輸出 schema），Workflow 節點 type 映射到 Registry 中的零件
- Task-051 >> 實現 >> US-023
- Task-051 >> 依賴 >> A-001（零件定義也是 Template）
- [US-024] G(t) 動態策略圖與衝擊模擬
- 身為 CEO Agent，我希望維護一張動態策略圖 G(t)，節點是產品 / 功能 / 外部因素，邊是依賴關係（帶條件），當某條邊的條件失效時（衝擊），系統自動重算最優路徑並建議應對策略
- EARS 需求
- When 外部事件觸發衝擊（例：LINE 政策變更），CEO Agent shall 標記受影響的邊為失效
- If 邊失效導致某功能不可達，系統 shall 沿替代路徑重算到達北極星的新路徑
- While 重算進行中，系統 shall 輸出受影響的 Epic / US / Task 清單
- When 無替代路徑存在，系統 shall 告警並建議「新增替代邊」
- Design 決策
- G(t) 儲存為 KBDB 三元組（
>> 依賴/替代路徑/邊條件 >> ） - 衝擊模擬 = 移除失效邊 → BFS/Dijkstra 重算連通性 → 輸出差異報告
- 策略圖更新頻率：事件驅動（衝擊發生時）+ 每週定期審核
- G(t) 儲存為 KBDB 三元組（
- US-024 >> 實現 >> Epic-8
- US-024 >> 依賴 >> US-003（圖遍歷支撐衝擊分析）
- US-024 >> 依賴 >> US-022（CEO Agent 作為策略圖維護者）
- US-024 >> 替代路徑 >> 人工 SWOT 分析（不自動化但適用於極端狀況）
- US-024 >> 邊條件 >> 策略圖中所有邊都有明確的邊條件（否則無法模擬衝擊）
- US-024 >> 指向北極星 >> 動態策略確保 VM 在外部環境變化時始終找得到通往北極星的路
- [Task-052] 實作策略圖三元組結構
- 定義策略三元組格式：
>> 依賴 >> 、 >> 邊條件 >> 、 >> 替代路徑 >> - Task-052 >> 實現 >> US-024
- Task-052 >> 依賴 >> Task-001（三元組寫入）
- 定義策略三元組格式：
- [Task-053] 實作衝擊模擬引擎
- 接收失效邊列表 → 移除邊 → BFS 從每個功能節點到北極星 → 輸出不可達節點 + 可用替代路徑
- Task-053 >> 實現 >> US-024
- Task-053 >> 依賴 >> Task-006（BFS 引擎）
- Task-053 >> 依賴 >> Task-052（策略圖已建立）
- [Task-054] 實作衝擊報告生成
- 將模擬結果組裝為結構化報告（受影響 Epic/US/Task 清單 + 建議替代路徑），送 CEO Agent 審核
- Task-054 >> 實現 >> US-024
- Task-054 >> 依賴 >> Task-053
- [US-025] COO 24/7 健康監控
- 身為系統管理員，我希望 COO Bot 持續監控所有服務健康狀態（KBDB / Workers AI / Claude API / 萃取佇列），異常時自動告警並觸發恢復流程
- EARS 需求
- While 系統運行，COO shall 每 5 分鐘 ping 所有關鍵端點（health check）
- If 某端點連續 3 次 health check 失敗，COO shall 標記為 degraded 並通知 CEO Agent
- If 萃取佇列 DLQ 長度 > 100，COO shall 觸發 DLQ 重試 Workflow
- When COO 自身崩潰重啟，shall 從 Workers KV 恢復最後狀態
- Design 決策
- 監控端點清單儲存於 Workers KV（方便動態新增 / 移除）
- 告警走 Telegram 通知 CEO Agent + 董事長
- 恢復策略：自動重試 → 降級（切換備用服務）→ 告警等待人工介入
- US-025 >> 實現 >> Epic-8
- US-025 >> 依賴 >> A-005（COO 監控角色定義）
- US-025 >> 替代路徑 >> 外部監控服務（UptimeRobot / Cloudflare Health Check）做為備援
- US-025 >> 邊條件 >> Cloudflare Cron Trigger 執行穩定
- US-025 >> 指向北極星 >> VM 持續運轉的前提是所有服務健康
- [Task-055] 實作 Health Check Cron Worker
- Cloudflare Cron Trigger 每 5 分鐘執行，ping KV 中的端點清單，結果寫回 KV
- Task-055 >> 實現 >> US-025
- Task-055 >> 依賴 >> A-005
- [Task-056] 實作異常告警與降級邏輯
- 連續 3 次失敗 → Telegram 告警 → 觸發降級 Cypher Workflow（切換備用服務或限流）
- Task-056 >> 實現 >> US-025
- Task-056 >> 依賴 >> Task-055
- Task-056 >> 依賴 >> Task-050（Cypher Workflow 執行降級流程）
- 附錄：關係索引
- 北極星連結彙總
- Epic-1 >> 指向北極星 >> 提供異見三元組的儲存與檢索基礎設施
- Epic-2 >> 指向北極星 >> Entity 歸一是三元組品質的基石
- Epic-3 >> 指向北極星 >> 萃取是從原始資料到異見三元組的轉化引擎
- Epic-4 >> 指向北極星 >> Ghost 延長互動時間，增加三元組採集量
- Epic-5 >> 指向北極星 >> Polaris 是辨識搭橋者的演算法層
- Epic-6 >> 指向北極星 >> Minime 是三元組採集的主要入口
- Epic-7 >> 指向北極星 >> 多管道匯聚三元組 + 現金流支撐 VM 運轉
- Epic-8 >> 指向北極星 >> 治理系統確保 VM 不偏離北極星
- 替代路徑彙總
- US-001 >> 替代路徑 >> Block + Slot 低階 API
- US-002 >> 替代路徑 >> 全文搜尋 ILIKE 降級方案
- US-003 >> 替代路徑 >> 語意搜尋 + 人工組裝子圖
- US-004 >> 替代路徑 >> 全部手動建立 Entity
- US-005 >> 替代路徑 >> 批次 CSV 匯入別名對照表
- US-006 >> 替代路徑 >> 呼叫端自行查詢組裝
- US-007 >> 替代路徑 >> 人工標註三元組
- US-008 >> 替代路徑 >> 全走 LLM 萃取
- US-009 >> 替代路徑 >> Discord Bot 採集
- US-010 >> 替代路徑 >> 人工策展 Ghost 性格三元組
- US-011 >> 替代路徑 >> 書僮採集模式（達到同樣北極星）
- US-012 >> 替代路徑 >> 自動演化不審核
- US-013 >> 替代路徑 >> 純三元組數量做為單一指標
- US-014 >> 替代路徑 >> 人工策展搭橋者
- US-015 >> 替代路徑 >> Jaccard similarity 簡化版
- US-016 >> 替代路徑 >> 純文字筆記輸入
- US-017 >> 替代路徑 >> 前端表單手動填寫
- US-018 >> 替代路徑 >> Workers AI 低品質版本
- US-019 >> 替代路徑 >> 直接跳過算命進入 Ghost 聊天
- US-020 >> 替代路徑 >> 人工配對
- US-021 >> 替代路徑 >> 企業自建 RAG 系統
- US-022 >> 替代路徑 >> 董事長直接操作 Claude.ai
- US-023 >> 替代路徑 >> 逐步手動觸發
- US-024 >> 替代路徑 >> 人工 SWOT 分析
- US-025 >> 替代路徑 >> 外部監控服務（UptimeRobot）
- 關鍵邊條件彙總
- A-001 >> 邊條件 >> Cloudflare D1 SQLite 相容性
- A-004 >> 邊條件 >> Workers AI 模型供應穩定 + Claude API 定價可承受
- A-005 >> 邊條件 >> Telegram Bot API 持續可用
- A-007 >> 邊條件 >> 足夠的真實用戶對話資料已累積
- US-002 >> 邊條件 >> Cloudflare Vectorize 服務可用
- US-004 >> 邊條件 >> Workers AI embedding 模型一致性
- US-009 >> 邊條件 >> LINE Bot 政策允許群組讀取
- US-014 >> 邊條件 >> 圖規模 < 100K 節點
- US-018 >> 邊條件 >> Claude API 速率限制允許即時回覆
- US-025 >> 邊條件 >> Cloudflare Cron Trigger 執行穩定
- 北極星連結彙總
- 今日完成（2026-03-16）
- [Task-057] KBDB entity_type 雙主體架構
- blocks 表新增 entity_type 欄位（migration 0008），支援 person / event / product / market / org
- Task-057 >> 實作現況 >> done（commit 92a5f63）
- Task-057 >> 實現 >> A-003（Entity 分兩類）
- [Task-058] >> 語法自動三元組 parser
- POST /blocks 與 PUT /blocks/upsert 寫入後自動掃描 content，遇到「A >> B >> C」格式 fire-and-forget 建三元組
- Task-058 >> 實作現況 >> done（commit 687540f）
- Task-058 >> 實現 >> SDD動態維護機制
- Task-058 >> 啟用 >> 地圖自動對齊地球的層次二
- [Task-059] 代碼語義對齊（待實作）
- CTO git push 後掃描函式/端點生成 docstring embedding，寫入 KBDB（entity_type=code_artifact）
- 定時 Cron 比對 code_artifact vs spec_task embedding，建立對應三元組，輸出差異報告
- Task-059 >> 實作現況 >> not-started
- Task-059 >> 實現 >> 地圖自動對齊地球的層次三
- Task-059 >> 依賴 >> Task-058（>> parser 已上線）
- Task-059 >> 依賴 >> US-002（向量搜尋）
- [Task-057] KBDB entity_type 雙主體架構
- 統計摘要
- Assumptions：8 項（A-001 至 A-008）
- Epics：8 個（Epic-1 至 Epic-8）
- User Stories：25 個（US-001 至 US-025）
- Tasks：59 個（Task-001 至 Task-059，含今日新增 Task-057/058/059）
- 實作狀態：done 13 / partial 3（US-006/US-013/Task-024）/ not-started 2（US-019/Task-059）
-
關係行：每個層級皆已填寫（含依賴 / 替代路徑 / 邊條件 / 指向北極星 / 實作現況）