60 秒決策
先確認使用者要完成的事。
適合使用
- 使用者需要稍後處理、追蹤或重新查看一則系統事件。
- 訊息帶有時間、對象、待辦或已讀狀態，不能只靠使用者剛好看見一個短暫浮框。
不適合使用
- 只是一次無下一步的成功結果，或在同一頁可立即復原的一個短操作。
- 需要立刻阻止使用者繼續操作的錯誤；那是附近 Alert 或確認流程的責任。
畫面要說清楚的事
不要只交代外觀，也要交代資料與輸入規則。
讓人回頭還找得到
通知清單要保留時間、脈絡與未讀狀態；它是可回訪的工作線索，不是一次性動畫。
每則通知只說一個事件
把專案邀請與權限檢查拆開，讓使用者能判斷哪一則需要先處理。
已讀不等於已處理
標示已讀只代表使用者看過；需要下一步的通知仍要保留正確的任務或連結。
必要狀態與回應
每個狀態都要讓使用者知道下一步。
未讀
通知有清楚的事件、時間與未讀線索，使用者可在適當時機查看。
已讀
保留事件內容與時間，只更新已讀狀態，不假裝它從未發生。
需要處理
若有後續任務，提供清楚入口或將它連到真正的處理流程。
已過期或完成
保留、封存或移除依產品規則決定；不能讓過期通知長期混在待處理事項裡。
操作 Demo
先知道要觀察什麼，再動手操作。
操作前先知道
待處理系統通知
先觀察：通知是否保留可回看的時間、脈絡與未讀狀態，而非出現幾秒後就消失。
操作：點選第一則通知的「標示已讀」。
預期結果：該通知的未讀標記會更新，清單仍保留事件內容；局部 status 訊息回報已讀結果。
Notification Demo
需要處理或回看的事，必須留在找得到的地方通知中心
待查看的系統事件林子安申請加入 LumenCore 專案需要專案管理員決定是否核准。10 分鐘前
8 月權限檢查待完成仍有 3 位成員需要確認角色。今天 09:00
Notification 留在清單中，讓使用者在合適時機回來查看；已讀只是看過，不代表事件已經處理完成。
目前有 2 則未讀通知。
告訴 AI
把任務、規則、狀態與操作條件一次寫清楚。
在 LumenDesk 建立 Notification 清單，保留需要後續處理的系統訊息，例如「林子安申請加入 LumenCore 專案」與「8 月權限檢查待完成」。每則通知要有標題、時間、必要脈絡與已讀狀態；清單不能自動消失。提供「標示已讀」操作，只更新該通知的已讀狀態與摘要，不把使用者帶離目前頁面。短暫 Toast 只能作為額外回饋，不能是唯一入口。驗收清單
不要只確認欄位能不能點。
- 使用者是否需要日後回看或處理這件事？
- 每則通知是否有事件、時間與足夠脈絡？
- 已讀與已處理是否被清楚區分？
- 短暫 Toast 是否只作為補充，而不是唯一入口？
- 標示已讀是否只更新局部狀態、不把人帶離頁面？
- 過期或完成的通知是否有可理解的保留、封存或移除規則？