# ADR-0003：物件儲存只做暫存，不當永久素材庫

已採用

## 狀態

已採用

## 背景

上傳的影片與圖片要放在哪裡？最常見的答案是「放在物件儲存裡，永遠留著」。

## 決策

RustFS 只做暫存與派送：

- 原始檔在轉檔成功後**立即刪除**。
- 縮圖與預覽長期保留（它們很小）。
- 播放產物在所有目標裝置都 ACK 且經過保留期後**回收**。
- 正式的播放副本最終保存在**裝置本機**。

當某個素材已經沒有任何可派送的副本時，把它標記為 `NEEDS_REUPLOAD` 並在介面上誠實顯示。

## 理由

**原始檔在系統裡沒有讀者。** 一支 4K 原始影片可能有 8 GB，轉檔後的播放版本只有 200 MB。播放用轉檔版、預覽用預覽版、縮圖用縮圖——沒有任何功能會去讀那 8 GB 的原始檔。留著它只是讓儲存成本隨上傳量線性成長。

**播放副本已經在裝置上了。** 素材的用途就是被裝置播放。所有目標裝置都下載完成並驗證通過之後，RustFS 上那份副本就沒有讀者了。

**這是一個產品定位的決定。** HUAN 是播放系統，不是數位資產管理系統。想要保存原始母帶的人應該用 DAM，而不是期待看板系統替他做備份。

## 後果

這個決定有一個**真實的、使用者會遇到的代價**：

原始檔已刪除、播放產物也已回收之後，如果你新增一台裝置，或某台裝置清掉了本機儲存，這份素材就無法重新派送，必須重新上傳。

我們選擇正面處理這件事：

- 資料模型本身能表達這個狀態（`media_variants.available`）。
- 後台會明確顯示「需要重新上傳」，並解釋原因。
- 文件在多個地方說明這個限制。
- 保留期可以透過 `DISTRIBUTION_RETENTION_HOURS` 調整，設成 720 就等於一個月內都能重新派送。

**不會做的事**：假裝伺服器還留著不存在的檔案，然後在派送的時候才失敗。

回收前的兩道保護也很重要：必須所有目標裝置都 ACK（不能第一台成功就刪），而且必須經過保留期（吸收 ACK 與重試之間的競態）。

## 替代方案

**永久保留原始檔**：儲存成本無上限地成長，而且那些檔案沒有讀者。

**永久保留播放產物**：比保留原始檔便宜得多，也確實避免了重新上傳的問題。這是最值得未來重新評估的選項——只要把 `DISTRIBUTION_RETENTION_HOURS` 設得夠大，實務上就等於這個方案。目前的預設值選擇了成本，而不是便利。