「先不修」是合法決策，但要寫齊發現日期、原因、不修理由與解除條件，口頭擱置會變成沒人記得的地雷。
定義：開發中發現的問題不必每個都馬上修，但「先不修」的決定必須留下書面紀錄——寫齊發現日期、真正原因、為什麼現在不修、什麼條件下解除擱置，才是受控的擱置。
問題分進兩個清單：「下個階段候選」和「已知問題（決定先不修）」。關鍵是後者，每一條都要寫齊四件事：
有個資料不同步的 bug，查出根因後刻意不修——因為三週後的架構搬遷會讓那段程式整個消失，現在修是做白工。因為有寫下解除條件，搬遷時就順手根治了。
「先不修」是合法決策，但口頭決定會被遺忘、變成沒人知道為什麼的地雷；寫下來的擱置才是受控的。
看到 AI 回報 bug 時，回它「修」或「擱置＋理由」，兩種都要留痕。定期翻「已知問題」清單，檢查有沒有解除條件已成立卻沒人動的項目。
前端的權限處理好了，那後端呢？ 花了快一天的時間，才弄清楚我到底在修什麼issue，這個資安問題分成兩部分。 第一個是前端寫好的權限，但使用者可以透過網頁開發者工具（F12）去修改自己的身分，把自己從一般使用者改成主管，來獲得操作權限。 要解決這個問題有三個步驟要設定： 1. 資料行安全性設定檔，加成員（ powerplatform > 環境 > XXXX > 設定＞資料行安全性設定 > 使用者） 2. 啟用資料行安全性（ Power Apps > 資料表 > 使用者 > 資料行 > 點擊欲修改的顯示名稱 > 進階選項） 3. 回到資料行安全性設定檔，編輯資料行權限（讀取、更新、建立） 如此一來，有更新、建立權限的人員，才能去修改該資料行的值。 確保了後端的使用者權限不會被亂改後，
把 Planner 巡檢包成 skill 的過程，用幾個問題釐清腳本與 skill 的分界，途中還修正了一個判斷規則的前提錯誤。
把一次會議的討論整理進團隊看板，難的不是抓逐字稿或搬運，而是「內容對到哪張卡」的路由；記下改成半自動（AI 整理逐字稿、對卡、產生預覽，人確認）的理由，以及六個現實限制：逐字稿權限門檻、一個連接器只綁一個帳號、寫入身分、別覆蓋既有筆記、術語聽錯、清單順序不保證。
把業界（以 Anthropic 內部為主）的人機協作四原則——公開工作、明確角色、北極星寫下來、信任漸進——對照自己的 AI 協作工具箱。照出來的差距集中在讓 AI 產出流回團隊場域，另記三個此前沒用的方法。延續『問 AI 你怎麼做到的』的最佳化姿態，這次問的是業界。
