昨天從最新的 main 建立 feature/delete-issue，完成刪除任務功能、測試與 Pull Request。

今天要開一個全新的 Codex 任務，讓它站在沒有參與實作的 Reviewer 角度，對這張 Pull Request 做合併前的最後檢查。

為什麼要開新的 Codex 任務？

昨天的 Codex 任務已經參與需求分析、實作與測試。它知道自己為什麼這樣寫，也容易沿用實作過程中的假設。

新的任務不帶著先前討論，只提供：

• Pull Request
• 功能需求
• AGENTS.md
• base branch 與完整 diff
• 現有測試

這樣比較接近真正的 Code Review：Reviewer 只能根據需求、程式與證據判斷，而不是根據作者心裡原本想做什麼。

Review 的範圍是 PR，不是整個專案

這次要 Review 的是：

base: main
head: feature/delete-issue

Reviewer 應該從兩個 branch 的共同起點檢查完整差異，而不是只看最後一個 commit，也不是順便評論整個 repository 的舊程式。

如果發現的問題早在 base branch 就已經存在，而且這次修改沒有讓它惡化，就不應該假裝是這張 PR 引入的 finding。它可以另外記錄，但不能拿來阻止這次合併。

先找會影響行為的問題

今天不是請 Codex 挑命名或格式偏好，而是優先尋找：

• 刪錯任務或刪除沒有生效
• 使用者取消後資料仍被修改
• 畫面刪除後，localStorage 沒有同步
• 搜尋或篩選啟用時刪除錯誤項目
• 舊資料載入後無法刪除
• 刪除最後一筆結果後空狀態錯誤
• 測試看似存在，卻沒有驗證真正的結果
• 刪除按鈕無法被輔助技術辨識

這些問題會影響 correctness、資料一致性、相容性或可操作性，比單純的程式風格更值得先處理。

今天使用的 Prompt

我會開啟一個新的 Codex 任務，貼上昨天建立的 Pull Request 網址，輸入：

你是這張 Pull Request 的最終 Reviewer，沒有參與先前的需求討論與實作。

Pull Request：
<貼上 feature/delete-issue 的 PR 網址>

功能需求：
- 每筆任務都有容易辨識的刪除按鈕
- 點擊後先顯示確認訊息
- 只有確認後才刪除
- 取消時資料保持不變
- 刪除結果保存到 localStorage
- 搜尋或狀態篩選啟用時，刪除後畫面立即更新
- 刪除最後一筆符合條件的任務後顯示正確空狀態

不做事項：
- 不加入復原、垃圾桶、軟刪除或批次刪除
- 不修改搜尋與狀態篩選規則
- 不重新設計整個畫面
- 不新增或升級套件
- 不進行無關重構

請先：
1. 閱讀 AGENTS.md 與 PR 描述
2. 確認 base 是 main、head 是 feature/delete-issue
3. 使用 merge-base 檢查這張 PR 的完整 diff
4. 閱讀受影響程式的上下文與相關測試
5. 必要時執行既有測試或 `npm run check` 驗證判斷

請優先尋找：
- 會造成錯誤行為的 correctness 問題
- 刪除結果與 localStorage 不一致
- 搜尋、篩選或舊資料情境下的相容性問題
- 無障礙操作上的實際阻礙
- 未覆蓋重要失敗路徑的測試缺口
- 超出這張 PR 需求的修改

每個 finding 必須包含：
- 嚴重度：P0、P1 或 P2
- 精確檔案與行號
- 可以觸發問題的具體操作或輸入
- 實際影響
- 為什麼是這張 PR 引入的問題
- 最小修正方向

Review 規則：
- 只做分析，不要修改任何檔案
- 不要 commit、push 或更新 Pull Request
- 不要回報純風格、命名偏好或沒有實際影響的建議
- 不要把 base branch 已存在的問題算成這張 PR 的 finding
- 不要只因為缺少某個測試就推測功能一定有 bug
- finding 放在摘要前面
- 如果沒有具體 finding，明確寫「沒有發現阻止合併的問題」，不要為了有答案而勉強挑錯

最後再提供：
1. Review 摘要
2. 實際執行過的驗證與結果
3. 仍然需要人工確認的風險

這段 prompt 的回覆和執行

如果 Finding 成立

確認問題後，我會回到 feature/delete-issue，在新的 Codex 任務或實作任務中提供已驗證的證據：

剛才的 Code Review 發現以下問題，我已經人工確認可以重現：

Finding：
<貼上已驗證的 finding>

重現步驟：
<貼上實際重現方式>

請先閱讀相關程式與測試，說明根本原因及最小修正計畫。
確認後只修正這個問題，並新增或調整能防止回歸的測試。

限制：
- 不處理其他重構或風格問題
- 不改變已確認的刪除需求
- 不新增套件
- 不 commit 或 push

完成後執行相關測試與 `npm run check`，並回報修改 diff 與驗證結果。

修正完成後，仍然要人工重現一次原本的問題，再檢查 diff。如果確認正確，才建立修正 commit：

git add <確認過的檔案>
git commit -m "fix: <描述實際修正內容>"
git push

原本的 Pull Request 會自動加入新 commit，GitHub Actions 也會重新執行。

修正後要重新 Review 嗎？

如果只修正一個小問題，可以請 Codex 重新比較新增的修正 commit 與原本 finding，確認：

• 問題的觸發路徑已經消失
• 回歸測試確實會在舊程式失敗、新程式通過
• 修正沒有改變其他刪除行為
• 完整 npm run check 仍然成功
• PR 最新一次 CI 已經轉綠

如果修正範圍很大，則應重新 Review 整張 PR，因為新的修改可能引入不同風險。

合併前檢查

最後再次確認：

• 刪除功能的需求都已完成
• 取消刪除不會改變資料
• localStorage 與畫面保持一致
• 搜尋、篩選和舊資料情境仍然正常
• 自動化測試與最新 CI 通過
• 沒有尚未處理的 P0、P1 或 P2 finding
• PR 描述與最新 diff 一致
• 修改範圍仍然只有刪除功能

全部成立後，這張 Pull Request 就可以合併了。

這是我的 repo，在裡面的 commit 找到 "Merge pull request #3 from oliiiiiiiiii/feature/delete-issue" 就是這篇文章寫完時的狀態。

今日小結

今天用一個全新的 Codex 任務 Review feature/delete-issue Pull Request，讓 Reviewer 只根據需求、完整 diff 與測試證據尋找具體問題。最後把這張 PR 合併。