要求一份附帶你必須通過的測驗的報告，把「我掃過 diff 了」變成驗證過的理解——artifact 不會讓你在真正理解之前感覺完成。
我想確保在 merge 前完全理解這個變更發生的一切。給我一份關於 export-feature diff 的 HTML 報告——脈絡、直覺、做了什麼——底部附帶我必須通過的測驗。
一個 14 檔 diff，把伺服器端 clip 匯出加到 review threads。讀完下面三個章節，然後通過測驗。如果通不過，你還沒準備好 merge——這就是重點。
一張圖抵 14 個檔案：匯出請求現在的流向 vs. 之前。
在這個變更之前，「匯出 clip」意味著瀏覽器用 MediaRecorder 在客戶端拼接 frames 並上傳結果——慢、鎖住 tab、而且在 Safari 上壞掉。現在客戶端只請求匯出；一個新的 worker 從原始媒體伺服器端渲染，客戶端 poll job 直到 signed download URL 出現。
掃 diff 不會告訴你的部分。每一個都是刻意的——這是背後的原因。
media/originals/，從不用 720p review proxy。因此匯出的 clip 可能比審閱者畫註解時看到的更清晰。locked_until = now() + 10min 來認領。如果 worker 在渲染中途死掉，不會觸發重試；lock 只是過期，下一個閒置的 worker 會從頭撿起 job。GET /api/exports/:id 回傳的 signed S3 URL 有效 24 小時，但底層物件要到 7 天 lifecycle rule 觸發才會刪除。重新呼叫 endpoint 會產生新的 URL，不需要重新渲染。Workspace-scoped signed-URL auth。 GET /api/exports/:id 本身不做權限檢查——它重用已經守住每個 media route 的 requireWorkspaceMember middleware。如果那個 middleware 的 session 處理有變（有一張公開 ticket，BL-2214，關於 guest reviewer sessions），匯出下載也會跟著變。這個 diff 裡沒有任何東西會標記出這件事。
6/6——你可以向被 page 的人解釋這個變更。下面是標準 checklist。
你漏了下面的問題。缺口直接對應到報告：