不要依執行順序排列計畫，而是依照你有多大可能會修改每個部分來排序——這樣值得你關注的決策會浮上來，機械性的工作則沉到底部。
用 HTML 寫一份註解匯出的實作計畫，但開頭放我最可能想調整的決策：資料模型變更、新的 type interface、以及任何面向使用者的部分。把機械性的重構藏到最底下——那部分我相信你。
Acme · 將審閱的註解匯出為可分享的 PDF 或 CSV · 分支 feat/annotation-export
三個我做了判斷、但你可能不同意的領域。每個標記的選擇都顯示我考慮過的替代方案——可以切換比較。
成本：重度審閱約 ~40 KB/row；快照可能相對即時討論串變得過時。
選這個如果：匯出是工作文件，不是記錄。一句話告訴我：「用即時 join。」
成本：需要管理 blob 生命週期；我會加一個 30 天 TTL 清理（C 區，項目 6）。
選這個如果：儲存/合規規定讓儲存副本變得麻煩。
'xlsx' 或 'srt' 只需一個 union member + 一個 renderer。TimecodeRange 讓製作人可以只匯出某一場景的筆記。如果沒人要這個，拿掉可以省約半天。'wont_fix'，告訴我。為什麼步驟 3 最弱：大部分匯出會在 3 秒內完成，所以 fire-and-forget 的 toast 可能感覺小題大做——但 400 個註解加繪圖的審閱要約 20 秒，太長不能 block。混合方式（最多等 4 秒，然後 fallback 到通知）體驗更好，但會多約半天工時。你決定。
我實際會用的建置順序。每一步都在 CI 綠燈落地；步驟 5 翻 flag 之前不會有任何使用者可見的東西上線。
這個功能需要的重構和接線。這裡沒有判斷性決策——刻意收起來。
AnnotationSerializer 從 api/annotations.ts 抽到 lib/serializers/，讓 export worker 可以重用。純搬移，沒有行為變更。CommentMarker → AnnotationMarker 的重新命名——還有 3 個檔案 import deprecated alias。annotation_exports 加到 fixture loader 和 CI database-reset script。workers/index.ts 註冊 exports.render，並加到 dead-letter alert 清單。flags.yaml 建立 feature flag export_annotations，預設關閉。jobs/cleanup.ts 加一個每日 TTL 清理過期 export blob（只在選擇 ② 維持現狀時需要）。openapi.yaml 加上兩個新 endpoint，並重新產生 client。player/utils.ts 移到 lib/time.ts——PDF renderer 需要它，但不該 import player bundle。你可以發送的最高槓桿回覆。複製一個、編輯、發送——我會修改計畫。