自動儲存 vs 稽核紀錄：折疊窗口的取捨

後台的每個寫入端點都掛稽核——誰、什麼時候、對誰、做了什麼成功的操作，一列一筆。這套機制撞上筆記編輯器的自動儲存時，出了一個好問題：打字停頓 1.5 秒就存一次，寫一小時的文章＝幾百筆「編輯筆記」稽核，其他真正重要的動作（發佈、刪除）全被洗掉了。

選項與抉擇

不記編輯？那「已發佈的文章事後被改過」這種真正有稽核價值的事實也丟了。滑動窗口合併（同動作在 N 分鐘內就刷新舊列的時間戳）？聽起來優雅，但它違反稽核的根本性質——append-only。回頭修改稽核紀錄本身就是稽核的反模式，而且滑動合併會把整場編輯壓成一筆，session 的起點與輪廓反而消失。

最後的設計：固定窗口、跳過不寫。同（動作、操作者、目標）在窗口內只記第一筆，之後直接跳過；窗口不滑動，所以寫一小時會留下大約每十分鐘一筆——session 的起訖輪廓還在，結束時間誤差不超過一個窗口。

邊界想清楚，實作就小

• 精確的「最後修改時間」不歸稽核管——那是 entity 自己的 updatedAt，單一真相不重複扛。
• check-then-insert 有競態？兩發並發可能都寫入，結果是多一筆紀錄。稽核不是業務不變量，為它上鎖是把成本花錯地方。
• 折疊是 opt-in：一個 decorator 參數。沒有自動儲存場景的端點零額外查詢、行為不變。

整個功能最後是：一個參數、一個寫入前查詢、一條複合索引。設計討論的時間是寫程式的三倍——這個比例在做「平台級」功能時是健康的，因為平台的錯誤設計會被每個 app 繼承。