ChangeSummary 變更摘要

送出前，把「我到底改了什麼」攤開來。

為什麼值得做成元件

使用者在一張 30 欄的主檔表單上改了 3 個欄位。送出前他唯一想知道的就是那 3 個是哪 3 個。沒有這一塊，他只能靠記憶，或整頁重新掃一遍。

變更摘要（可逐欄或整批還原）

本次變更（3）

Change[] 這個結構同時餵給三個地方：

FieldSpec[] 宣告
   ↓ diffRecord()
Change[] ──┬─→ ChangeSummary（送出前給使用者看）
           ├─→ 稽核記錄的 before/after（送出後留痕）
           └─→ 還原功能的資料來源

使用者送出前看到的，就是稽核記錄之後會呈現的。 這不是巧合，是刻意設計—— 兩邊各寫一份格式化邏輯，遲早會不一致，然後就會有人拿稽核記錄來質疑畫面。

沒有變更時顯示「尚無變更」的虛線框，而不是整塊消失。消失會讓使用者以為功能壞了，或以為自己的修改沒被偵測到。

超過 8 筆變更時，清單限制高度並在內部捲動，外框與標題不動。

✅ 這樣做

變更筆數永遠顯示在標題上（「本次變更 24 項」）。這是使用者送出前最想確認的一個數字，不能藏在需要捲動才看得到的地方。

🚫 不要這樣

不要讓摘要無限長。摘要跟著長，送出鈕就被推到畫面外—— 而使用者是為了「看完再送出」才來的，結果變成要捲兩次。

門檻設 8 的理由：8 列大約是不捲動就能一次看完的量。再多就已經不是「掃一眼確認」，而是「逐條閱讀」——那時捲動反而比一整片長清單好讀。

✅ 這樣做

把大表單拆成幾個有主題的區塊，各自送出。變更摘要短、審閱成本低、出錯範圍也小。

🚫 不要這樣

不要用「一次改完再一起送」當作預設流程。24 項變更的摘要，使用者實際上不會逐條看——他會直接按送出，摘要就白做了。

逐欄還原與整批還原都顯示「現值 → 還原後」，確認才執行。理由同 EditableField。

npx shadcn@latest add https://kielchang.github.io/dooping-design-book/r/change-summary.json