看得到畫面，也能自己動手操作。

適合這類需求

• 網站有流量，但說不出哪些內容真的帶來詢問
• 詢問散在信箱與各種訊息裡，沒有統一的追蹤方式

你可以操作

• 切換 7 天與 14 天的流量區間，匯出報表
• 搜尋詢問名單、更新每一筆的處理進度
• 在 AI 工作台以離線規則體驗原文回查與人工覆核；設定模型服務後才可執行模型整理

適合這類需求

• 設計或網站專案靠 Email 來回確認，常搞不清楚客戶看的是哪一版
• 驗收後又追加工作，範圍與時程的變化沒有留下紀錄

你可以操作

• 切換專案負責人與客戶窗口：提交版本、退回修改，再以新版本驗收
• 提出並核准範圍變更，完成追加交付後結案

問題

客戶看的是哪一版、驗收了哪些條件、追加的工作有沒有被核准——這些如果散在信件與訊息裡，就沒有共同的事實來源。同一個工作區開在兩個分頁時，較舊的那個還可能用過期資料覆蓋掉剛完成的決定。

設計決策

• 提交後的版本就凍結，不能直接修改；需要修正時撤回並說明原因，再建立下一版，舊版本的內容、留言與決定都留在原地。
• 角色不是只靠隱藏按鈕：提交、驗收、退回、核准變更都由同一層命令處理器檢查身分，切換角色只是示範，繞不過規則。
• 每次寫入都帶著版本號：兩個分頁同時決定時，只有先落地的那筆成立，另一筆被擋下並保留輸入，不會用過期資料覆蓋。

驗證結果

• 自動化測試涵蓋完整流程：提交 v1、退回、建立並提交 v2、逐項勾選後驗收、提出並核准範圍變更、追加交付後結案；一筆變更申請只會加入項目一次。
• 兩個分頁同時決策時只有一筆成立，另一筆被擋下並保留輸入；舊版本網址為唯讀並指向最新的版本。
• 儲存內容損毀時原檔完整保留，只有明確確認才重設，且只影響 Relay 自己的資料；無法取得 Web Locks 時工作區改為唯讀，不寫入任何東西。

適合這類需求

• 官方帳號的圖文選單只能連到表單，顧客查不到自己的會員與預約
• 想知道 LIFF 的 idToken 在後端到底該驗什麼，而不是直接把前端拿到的 userId 存起來

你可以操作

• 選一位示範帳號按下模擬 LINE 登入，看 idToken 的三段結構與解碼後的 claims
• 把 idToken 送到後端驗簽、比對 aud 與 exp，通過才綁定會員；簽章或 aud 不對會被擋下
• 會員卡顯示由訂單推導的點數與等級，以及綁定禮與加入日
• 選服務與時段自助預約，或取消自己未來的一筆預約
• 回到 Chime 後台的預約總表，看同一筆預約標成「自助預約（LIFF 示範）」

適合這類需求

• 用試算表登記報名，剩餘名額與候補順序常常對不上
• 額滿之後要有人盯著通知遞補，取消後又得重新排隊

你可以操作

• 以報名者視角選擇梯次送出報名，額滿時自動排入候補並顯示順位
• 切換行政人員視角，依序遞補候補第 1 位、取消或復原報名
• 調整梯次名額並匯出報名 CSV，查看以 Email 分組的學員名單
• 從巷口學堂前台報名，回到後台看名額與候補即時變化

問題

補習班或工作坊用試算表登記報名時，剩餘名額、候補順序與已確認名單是分開維護的數字。額滿後容易重複錄取或漏掉遞補；直接把取消的名字刪掉，也一起失去了原本的排隊位置。

設計決策

• 已確認人數與剩餘名額只由報名資料推導，不另存一份數字，總覽與名單不會各自漂移。
• 候補順位不靠人工排序：由報名時間推導，同一時間以 id 穩定排序；遞補只開放第 1 位。
• 取消是可逆的狀態而不是刪除；復原前重新檢查剩餘名額與同 Email 的重複報名，才不會把超收名單塞回去。
• 角色切換只是流程示範，遞補、取消、復原與調整名額同時在資料層檢查角色，繞過按鈕也無法執行。

驗證結果

• 自動化測試涵蓋：名額由報名推導、額滿自動排候補且順位依報名時間穩定排序、同 Email 重複報名被擋下、只有候補第 1 位能在有名額時遞補。
• 取消保留原狀態；復原時若原為已確認而名額已被占走、或同 Email 已有其他有效報名，會被拒絕並說明原因。
• 調整名額限制為 1–99 且不得低於已確認人數；下修到「已確認＋候補」以下時候補繼續等待；資料損毀時原檔保留，只有確認重設才還原示範資料。