epic(chronicle): product pivot — cognitive zoom interface for AI-augmented developers #172
Description
TL;DR
Chronicle 從「AI 協作敘事/反思工具」轉向為「AI 開發的認知縮放介面」。
一句話：Situational awareness for AI-augmented developers.
你用 AI 同時推進 10 個專案。每天早上，Chronicle 告訴你什麼需要你。點進去，30 秒恢復任何專案的 context。
為什麼 Pivot
edda watch 教訓：資訊 ≠ 理解
edda watch 技術上成功、產品上失敗。有面板、有資料，但用戶看了沒感覺。
「沒感覺」= 用戶要自己做認知工作（解讀、關聯、判斷）。如果用戶要自己想，工具跟 git log 沒差別。
❌ "GH-152: blocked, GH-159: blocked, GH-161: blocked"
→ 焦慮但不知道為什麼，沒有 action
✅ "Wave 2 全卡住 — 同一個原因：karvi worktree 指向錯 repo。修 #188 就全解鎖"
→ 清晰，一個 action 解決所有問題
五份市場報告的共識
- 「反思你的 AI 之旅」是 nice-to-have，付費率 < 5%
- 述說者語氣 6-12 個月內任何人用 GPT-4 就能做
- 真正的痛點不是「回顧」，是「接續」— "pick up where I left off"
- 最大風險：需求假設錯誤（9/10）— 沒人真的在乎「AI 關係」
新方向的來源
用 AI 開發的人（不管單 repo 或多 repo）都撞同一面牆：AI 產出的速度 > 人腦處理的速度。
深度耗腦（單 repo）— 50 個模組、20 個 open PR、agent 決策沒看過、被打斷後回不來
廣度耗腦（多 repo）— 10 個專案同時在動、一天 100 個 PR、不知道哪個卡了
新定位：認知縮放
Chronicle 不是 dashboard，不是日記，是一個認知縮放介面 — 讓你在不同粒度之間自由移動。
縮放層次
單 repo：
Zoom Out — 專案全貌（本週 4 PRs merged, 8 issues open, 卡住：karvi 調度）
Zoom In — 此刻脈絡（PR #171 修了什麼、為什麼、連帶影響）
多 repo：
Zoom Way Out — 全局（🔴 edda 需要介入 / 🟡 proj-Y CI 中 / 🟢 proj-W shipped）
Zoom In — 跟單 repo 一樣的體驗
核心是同一個動作：縮放。介面一致，複雜度按需展開。
不是什麼
| Chronicle 不是 | 為什麼 |
|---|---|
| Usage dashboard | 「花了多少 tokens」有 API dashboard 可看 |
| AI 日記 / 反思工具 | 「反思你的 AI 之旅」付費率 < 5% |
| 專案管理工具 | 不取代 Linear/Jira，是認知層不是執行層 |
| 監控系統 | 盯的是「人類需要關注什麼」不是 uptime |
產品原則
- 資訊 ≠ 理解 — 每一條輸出都要通過檢驗：用戶看完，知道該做什麼嗎？不知道就不該出現
- 賣認知落差的消除 — 焦慮→清晰 的轉變是產品價值，不是資料量
- 每句話有認知重量 — 抽象化 + 因果 + 影響判斷 + 行動指引，需要 LLM 高認知處理
- 零手動維護 — Layer 0 (git + transcript) 就能用，裝了就有內容
- 本地優先 — CLI 完全離線，雲端是可選同步層
資料分層
Layer 0a: Git data ← 做了什麼（commits, PRs, diffs, CI）— 100% 自動
Layer 0b: Session transcripts ← 為什麼這樣做（AI 對話、決策討論）— 100% 自動
Layer 1: Session hooks ← 元資料（時長、model、tokens）— 裝 edda 就有
Layer 2: LLM extraction ← 結構化摘要、決策提取 — 可選 BYOK
Layer 3: edda decide / note ← 手動精確記錄 — 可選
關鍵：Layer 0 就要能用。用戶指向 repo 就有內容。
Transcript 處理架構：行為優先
核心模型：Anchor × Four Layers
edda recap [anchor] — anchor 決定從哪裡出發，四層結構永遠一樣。
四層輸出（每一層都是跨來源合成，用戶無法從單一工具得到）：
- 淨結果 — 最終什麼留下了（跨 session 合成）
- 需要你 — 你不介入就不會前進的事（跨 repo blocker 分析）
- 決策脈絡 — 做了什麼決定、否決了什麼、為什麼（transcript 推理過程）
- 關聯 — 跟過去或其他 repo 的連結（BM25 跨時間比對）
Anchor 類型：預設(當前session) / 主題query / --project / --week / --all / 可組合
三層處理分工
行為分析 → 找到什麼重要（within session，不用關鍵字）
BM25 → 找到什麼相關（across time, across projects）
LLM → 合成理解 → 四層輸出
Step 1：行為分類（digest metadata only，不讀 transcript）
Session digest 已有 tools_used, files_modified, commits, failed_commands, duration。
Tool 簽名 → 類型
Edit 多, Bash(git commit), Read/Grep 多 → Coding
Read/Grep/Glob 多, Write(.md), Edit 少 → Research
幾乎沒有 tool, turns 多, duration 長 → Pure discussion
Read+Grep+Write(.md)+Edit(.md) → Analysis/documentation
SubagentStart/Stop, Bash 多 → Automated agent
Bash(test/cargo) 多, failed_commands 多 → Debugging
少 tool, 少 turn, 有 commit → Quick ops
Step 2：行為序列比對（index metadata only，不讀 transcript）
讀 index/<session>.jsonl（~1KB），找 turn 行為模式定位重要 turn：
| Session 類型 | 行為模式 → 重要 turn |
|---|---|
| Coding | [Read,Grep]→[Edit]→[Bash(test)]→[commit] → Edit+commit turns |
| Research | [Read,Grep,Glob]→[Write(.md)] → Write 那個 turn + 前面的 user msg |
| Discussion | 無 tool 為主 → head+tail+轉折點（短 user msg 接長 assistant = 修正） |
| Debugging | [Bash fail]→[Edit]→[Bash fail]×N→[Bash pass] → 最後的 fail→fix 循環 |
| Automated | 結果 turn only |
| Quick ops | digest 就夠 |
Step 3：精準讀取（只讀被定位的 turn）
用 offset+len seek 到 transcript store，只讀選中的 turns。每個 session ~3-10KB。
Step 4：BM25 跨時間關聯（增強路徑）
拿 Step 3 抽出的今天的關鍵內容去搜歷史 Tantivy index：
- 找過去類似的決策、討論、問題
- 為 LLM 提供跨時間 / 跨專案的補充視角
- 例："今天 pivot 了 Chronicle 方向" → 搜到 3 週前 "edda watch 面板沒人看"
Step 5：LLM 合成
Input = 行為分析選中的 transcript segments + BM25 關聯的歷史素材
Output = 認知摘要（抽象化 + 因果 + 影響 + 行動指引 + 歷史脈絡）
處理量估算
忙碌日（50 sessions across 10 repos）：
Step 1: 讀 50 個 digest ~10KB 瞬間
Step 2: 排序取 top 10，讀 index ~10KB 瞬間
Step 3: 精讀 10 個 session ~50KB < 1s
Step 4: BM25 跨時間搜尋 ~5KB < 500ms
Step 5: LLM 處理 ~60KB input ~$0.05 2-5s
架構：同 workspace 分 crate
Hook 熱路徑 (< 50ms)：
edda-bridge-claude → digest → ledger + index
寫入：transcript store, index records, session digest
❌ 不碰 FTS，不碰 LLM
共用資料層：
edda-store, edda-ledger, edda-transcript, edda-index
Bridge 寫，Chronicle 讀。無 crate 依賴，共用檔案。
Chronicle 冷路徑 (按需，秒級 OK)：
edda-chronicle ← 新 crate
├── 行為分類 + 序列比對（讀 digest + index）
├── 精準 transcript 讀取（seek by offset）
├── BM25 跨時間關聯（edda-search-fts）
└── LLM 合成（BYOK）
edda-aggregate（跨 repo 聚合）
為什麼放一起
- 共用 5 個資料層 crate，零重複
- CLI 是自然入口（
edda recap就是子命令） - Feature flag 控制編譯（
chroniclefeature → 含 Tantivy + LLM client） - Bridge 熱路徑不碰 FTS/LLM，效能完全隔離
已有基礎
| edda 能力 | Chronicle 用途 |
|---|---|
edda-transcript — cursor-based delta ingest |
Layer 0b 解析（Bridge 已自動做） |
edda-index — IndexRecordV1 + session meta |
行為序列分析（per-turn tool/bash data） |
edda-search-fts — Tantivy FTS + BM25 |
跨時間跨專案關聯搜尋 |
edda-aggregate — 跨 repo 聚合 + rollup |
全局視圖 |
edda-store/registry.json — 跨 repo 註冊 |
多專案發現 |
| Session digest events in ledger | 行為分類的 metadata |
缺的
edda-chroniclecrate — 行為分類 + 序列比對 + LLM 合成cmd_recap.rs— CLI 子命令
品質驗證
LLM 輸出無法 unit test。需要結構化的評估方式確保 recap 品質。
Golden Test Cases
用真實 session 資料建立 golden dataset：
tests/chronicle/golden/
├── coding-session.json # input: digest + index + transcript segments
├── coding-session.expected # 人工確認的「好的 recap」
├── discussion-session.json
├── discussion-session.expected
├── multi-repo-week.json
├── multi-repo-week.expected
└── ...
每次修改 prompt 或 extraction 邏輯後：
- 跑 golden tests → 比對 LLM output 跟 expected
- 人工判斷差異是「變好」還是「變差」
- 更新 expected 或修正 prompt
Prompt Iteration Protocol
LLM prompt 是產品品質的決定因素。Phase 0 的核心工作之一：
- Bootstrap prompt — 先寫 v1，跑幾個真實 session
- Failure analysis — 標記每個「看完不知道該做什麼」的 recap
- Root cause — 是 extraction 沒給對 input，還是 prompt 沒引導好 output？
- Iterate — 修 prompt 或修 extraction，用 golden tests 驗證
- Stabilize — prompt 穩定後凍結版本，記錄在
edda-chronicle/prompts/
日常驗證
Kill criteria 「自己每天用」之外，每次 recap 後快速檢查：
- 四層都有實質內容？（非空洞套話）
- 「需要你」層準確指出 blocker？
- 「關聯」層找到有意義的歷史連結？
- 看完 10 秒內知道該做什麼？
展開路線
Phase 0 — edda recap 合成引擎（CLI + LLM）→ #173
edda recap # 當前 session（預設 anchor）
edda recap "某個主題" # 主題搜尋 anchor
edda recap --project karvi # 專案 anchor
edda recap --week --all # 時間 × 跨 repo，可組合
- Anchor × Four Layers：anchor 決定出發點，四層結構永遠一樣
- 行為優先：tool signature 分類 → 行為序列定位 → 精準 seek transcript
- BM25 跨時間：拿今天內容搜歷史，補充不同視角
- LLM 合成：不是 template — edda watch 已證明無 LLM = 沒感覺 = 沒人用
- Prompt 迭代：golden test cases + failure analysis，不是寫完就好
- BYOK，無 key 時 fallback template
- Kill criteria：2 週內自己不每天用 → 停
Phase 1 — Mobile Briefing → #174
- 同一個 recap 引擎，REST API 化
- 早上推送到手機（沿用 karvi Expo + Tunnel stack）
- 跨 repo 🔴🟡🟢 注意力路由
- 點進去看單 repo recap detail
- Depends on: feat(serve): aggregation API endpoints for chronicle frontend #152, feat(chronicle): project scaffold — Expo (React Native) + daily fast dashboard #153, feat(chronicle): Cloudflare Tunnel deployment for mobile access #158, feat(serve): LLM proxy endpoint for chronicle narrative generation #162
Phase 2 — 開放 Beta + 模式識別
- 開放 20 個 beta 用戶
- 趨勢偵測："你在 auth 相關 PR 花 3x 時間"
- 團隊視圖（可選）
與既有 issues (#152-166) 的關係
新 Chronicle（認知縮放）是主線功能。舊 issues 作為可選附加功能保留，在主線驗證成功後按需啟用：
主線直接復用
| issue | 復用方式 |
|---|---|
| #152 aggregation API | recap 的資料來源，Phase 1 補 REST endpoint |
| #153 Expo scaffold | Phase 1 mobile briefing 沿用 karvi 的 Expo stack |
| #162 LLM proxy | recap 的 LLM 呼叫通道 |
| #163 file tracking | 提升 recap 行為分析精度 |
| #166 multi-tool | Phase 2 擴展 transcript 來源 |
可選附加（主線驗證後再評估）
| issue | 定位 |
|---|---|
| #154 storyteller voice | 附加呈現風格，非主線（認知摘要優先） |
| #155 writing system | 附加功能，recap 是主線 |
| #156 yearly narrative | Phase 2+ 長期功能 |
| #164 offline sync | Phase 1 mobile 時一併處理 |
| #165 export | Phase 2+ |
參考文件
reports/chronicle-2026-03-03/product-positioning.md— 完整產品定位reports/chronicle-2026-03-03/raw/01~05— 五份市場分析報告SeeTeams/docs/0302/edda_cl.md— 產品討論過程記錄