[Epic] trade-review → 全生命週期個人投資 OS(找資訊→選股→交易→update→recap),分階段吸收

[atomchung]

這個 issue 的用途:錨點。本 session 把「trade-review 要長成什麼」討論到一段落,先把願景 + 已達成的設計共識 + 待解的開放問題沉澱下來;下次另開一個專門 session 從這裡接著完整討論,不從零開始。
⚠️ 純架構/願景,不含任何真實交易資料。

1. 核心目標(願景)

把 trade-review 從「一張復盤卡」長成一個精簡的個人投資流程 OS,涵蓋投資的全生命週期,分階段做:

找資訊  →  選股  →  交易  →  update 資訊  →  recap

目前這條鏈散在多個獨立系統(研究/KOL 蒸餾一套、帳本/決策日誌一套、復盤卡一套)。願景是收斂成一個 OS,但身材要精簡——不是把現有重系統搬過來,而是重新長出每個環節的精簡形態。

2. 問題

1. 流程碎片化:全生命週期跨多個系統,資料重複(同一批交易被多處消費)、維護成本高、context 一直切換。
2. 重系統 = 高級拖延:既有帳本/決策日誌系統很重(多寫入車道 + 多 protocol + 大量檔案),作者自己診斷過它有「用分析取代行動」的傾向——分析很深但不改變下一筆。
3. recap 端(本 repo)只覆蓋一小塊:trade-review 目前只做行為復盤;它取代不了決策/thesis/研究,卻也還沒跟它們整合。

3. 解法方向(本 session 已達成的設計共識)

第一原則:吸收「功能」,不吸收「形態」。「重系統的價值,卡的身材。」每個要納入的功能過三道閘:

1. 改下一筆測試:這產出會不會改變下一個動作?不會 = 高級拖延 → 不納入。
2. 硬性 form budget:每個產出有上限(一行 / 一張卡 / 薄 JSON),不准長成長文 wiki 或多欄治理。
3. 盡量自動:engine 算得出的就自動算,對話捕捉得到的就對話捕捉,不靠手寫儀式。

精簡分層架構(recap 端已驗證,往全生命週期外擴):

• Layer 0 記帳(薄):CSV → holdings,engine 算,只人工補已知缺口。
• Layer 1 機械引擎:5 維行為診斷 + α/β + 賣後機會成本(已實作)。
• Layer 2 持倉 thesis(一行):why / 證偽條件 / 停損 / 目標 size。
• Layer 3 教練迴圈:初次 / 週 review / pre-trade gate。
• 記憶(薄·自動):規矩畢業 = 策略;history = error log。
• 輸出契約不變:永遠收斂成一張卡。 內部層可長,外部面收斂。

邊界(紅線):過程支援(你自己的 thesis 還成立嗎?證偽了嗎?加超過上限了嗎?)≠ 對外做選股 recommendation。但全生命週期含「選股 / 找資訊」會逼近這條線 → 見開放問題 #1。

4. 分階段(初步,待討論)

不是一次做完。建議從已建好的 recap 端往外長:

• Phase A(進行中):recap / 行為教練 = 現在的 trade-review(見本機 docs/roadmap.md:v0.5 gate → v1 每週迴圈 → v1.1 → v2c → v3)。
• Phase B:吸收「交易 + update」——薄記帳(Layer 0)+ 決策動機捕捉(Layer 2 thesis 一行)。
• Phase C:吸收「選股」——把研究/KOL 蒸餾接進來當「選股的過程支援」(不是 recommender)。
• Phase D:吸收「找資訊」——研究收集鏈。

(順序:從 recap 往回長 vs 按 lifecycle 正序 → 本身是開放問題 #4。)

5. 待深入討論的開放問題(下個 session 的主菜)

1. 選股/找資訊 vs 紅線:全生命週期含選股,跟「過程教練 ≠ 選股顧問」衝突。OS 定位成作者個人工具(選股 OK)、還是可分發產品(只能過程支援)?還是「同一引擎、兩種前端」?
2. 跟既有系統的關係:既有研究系統 + 帳本/決策系統,是吸收(重寫精簡版)、當後端、還是並存?哪些知識必須保留、哪些是形態可砍?
3. thesis-depth budget:Layer 2 每持倉 4 行(why/證偽/停損/size)夠不夠?核心倉要不要例外(= 防線破口)?
4. 分階段順序:從 recap 往外長,還是按 lifecycle 正序?
5. 一個 OS vs 同引擎多前端:單一 skill,還是「共用機械引擎 + 各階段各自薄前端」?
6. 統一資料模型:~/.trade-coach/ 的 thin state 要怎麼長,才同時餵 5 個階段又不變胖?

6. 本 session 已定(別重議)

• 全部結合進 trade-review = 一個 OS(本 issue 的前提)。
• 吸收功能不吸收形態 + 三道閘。
• 輸出永遠收斂成一張卡。
• recap 端路線:gate-first(v0.5)、v1 單鏡 + v1.1 選鏡。

參考

• 本機設計草稿(待整理進 repo):docs/roadmap.md(v0→v3 + codex/gemini 雙審整合)、docs/v1-weekly-coach.md(每週迴圈 + 鏡片演化軸 + 薄狀態硬契約)。
• 相關 issue:[P0] Stage 0：把卡塞到一個真人面前驗「有沒有戳中」（需求側 0 驗證） #3(Stage 0 真人測,P0)、[P1] α 誠實化：樣本不足時不准用「真本事」語氣出 alpha（雙閘門） #4(α 誠實化,已 merged via fix(engine): α credibility gate — drop "真本事 α" when sample/cross-section too thin #11)。

[atomchung]

開放問題 2「跟既有系統的關係」部分拍板（判定日期 2026-07-06，owner 原話拍板）：

pre-trade gate 開發階段都放在 fomo-kernel。investment_note 是基於正式 fomo-kernel 完成之後延伸出來的東西。

含義：

• 主從關係定案：fomo-kernel 是 OS 本體；investment_note 不再並行長功能（其 S15 事前登記簿 2026-07-04 才開表，與本 repo roadmap v1b pre-trade gate 撞功能——自本拍板起 gate 一律長在 fomo-kernel）。
• investment_note 的每週儀式（/record-trade）由 Phase B 取代（tracking [tracking·Phase B] 完整取代每週 trade view — 需求盤點 + 帳本方案定稿 #129，設計 docs/prd-ledger.md）；其殘餘價值（wiki / research / KOL views 研究鏈）屬 Phase C/D 的「自己用」前端外部 context 素材，屆時以唯讀源接入，不是第二個開發前線。
• 本 Epic 開放問題 2 的「吸收 vs 當後端 vs 並存」光譜上，答案落在：功能吸收進 fomo-kernel（Phase B 進行中），素材層日後當唯讀後端（Phase C/D）。

（同段拍板：record-trade 週報的「新聞事件驗證＋時間軸檢核」段確定砍、不做功能等價——過不了本 Epic 的「改下一筆」閘門，詳 #129。）