昨天讓 Codex 根據 GitHub Issue 完成搜尋與狀態篩選，最後建立了 feat: add issue search and status filter commit。

功能完成後，除了確認驗收條件，也要問另一個問題：這次是不是只改了 Issue 要求的內容？

今天不假設 Codex 一定改太多，也不刻意製造失控案例，而是讓它把 Issue 和 commit diff 放在一起，做一次範圍稽核。

什麼是範圍膨脹？

範圍膨脹是修改逐漸超出原本任務。

例如昨天的 Issue 只要求搜尋、狀態篩選與必要測試，但實作過程可能順便：

• 加入優先級或截止日期
• 實作排序或編輯功能
• 重新設計整個畫面
• 更換狀態管理方式
• 更新不相關套件
• 重構持久化模組
• 格式化大量無關檔案

這些修改不一定不好，但它們沒有經過這次 Issue 的需求確認，也會讓 diff 更難 Review。

為什麼「順便做好」也可能是問題？

額外功能可能看起來很貼心，卻會帶來幾個問題：

• 沒有明確驗收條件
• 測試可能不完整
• 產品行為由 Codex 自行決定
• 發生錯誤時很難只回復其中一部分
• Pull Request 變得太大
• Reviewer 必須理解更多不相關內容

如果某項改善真的值得做，可以另外建立 Issue，而不是偷偷混進目前任務。

已經 commit，還能檢查範圍嗎？

可以。

昨天的修改已經建立 commit，所以今天要比較該功能 commit 與它的第一個 parent。

如果它目前就是最新 commit，可以使用：

HEAD^..HEAD

如果後面還有其他 commit，就改用實際 hash。先固定範圍，才能確定看到的都是昨天那張 Issue 引入的修改。

今天使用的 Prompt

我會開一個新的 Codex 任務，提供昨天的 GitHub Issue 網址，輸入：

請對 Issue Tracker 的搜尋與狀態篩選功能做範圍稽核。

需求來源：
<貼上昨天的 GitHub Issue 網址或編號>

請先找出「feat: add issue search and status filter」commit 的正確 hash，並比較它和第一個 parent。

請將 diff 中的修改分成：

1. 必要
   - 直接完成 Issue 的功能、驗收條件或必要測試

2. 可選
   - 和 Issue 有關，但不是完成驗收條件所必需

3. 無關
   - 無法對應 Issue，或屬於明確的不做事項

對每項分類請附上：
- 檔案與修改位置
- 對應的 Issue 條目，或無法對應的原因
- 保留或移除可能造成的影響

另外確認：
- 是否加入優先級、截止日期、排序、拖曳、編輯或刪除
- 是否出現無關重構、套件更新或大範圍格式化
- 是否修改舊資料相容與 localStorage 行為所必需的部分
- 每項新增行為是否有驗收條件與測試

最後請提供結論：
- 如果沒有超出範圍，直接說明沒有發現範圍膨脹
- 如果有，提出保留必要修改並移除其餘內容的最小步驟

限制：
- 這次只分析，不要修改檔案
- 不要執行 git reset、rebase、commit、push 或改寫 Git 歷史
- 不要因為某種寫法不同，就把它當成範圍問題

這次要求 Codex 附上 Issue 條目，是為了避免只憑檔名判斷。

例如修改 localStorage 邏輯看起來像重構，但如果它是為了讓舊資料補上預設狀態、保存狀態變更，就可能是完成驗收條件的必要修改。

這段 prompt 的回覆

三種分類怎麼判斷？

必要

拿掉後會讓某項驗收條件失敗，或讓必要測試無法成立。

例如搜尋輸入、篩選邏輯、狀態切換、舊資料相容與對應測試。

可選

和功能有關，也可能改善體驗，但 Issue 沒有要求，而且拿掉後仍能通過所有驗收條件。

例如額外動畫、快捷鍵或沒有被要求的統計資訊。

無關

和這張 Issue 沒有直接關係，或已被明確列在不做事項。

例如順便加入刪除功能、升級所有套件，或重構不相關模組。

分類的目的不是批評 Codex，而是決定這個 diff 應該保留什麼。

如果沒有範圍膨脹

Codex 可能確認每項修改都能對應 Issue。

這時不需要為了配合文章主題，硬挑一段程式刪掉。只要再人工抽查：

• 修改位置是否真的存在
• 對應的 Issue 條目是否正確
• 不做事項是否沒有出現在 diff
• 測試是否涵蓋新增行為

確認後，就可以把「未發現範圍膨脹」當成今天的結果。

如果真的改太多，先不要繼續編輯

發現範圍失控時，第一步不是再丟一句「改少一點」，而是停止新增修改。

先確認：

• 哪些內容必須保留
• 哪些內容可以移到另一張 Issue
• 哪些內容應該移除
• 額外修改是否和必要功能混在同一段程式
• 移除後需要重新執行哪些測試

範圍還沒整理清楚以前繼續寫程式，只會讓必要與無關內容更難分開。

確認計畫後再收斂

人工確認分類後，可以使用第二段 Prompt：

我已確認剛才的分類。

請保留所有必要修改，移除我核准的可選與無關內容。

要求：
- 只處理已確認要移除的部分
- 不改變 Issue 的任何驗收結果
- 不加入新的替代功能或重構
- 不改寫既有 Git 歷史
- 完成後執行相關測試、完整測試、lint 與 build
- 提供清理後 diff，並逐項說明驗收條件仍由哪些程式與測試支持

如果移除某項內容會破壞必要功能，請先停下來說明，不要自行改變計畫。

因為昨天的 commit 已經存在，而且已經推送到遠端，這次應該用新的 cleanup commit 記錄收斂結果，不用 reset 或 force push 改寫歷史。

Commit message 要依實際移除內容描述，例如：

chore: remove out-of-scope search changes

如果沒有發現多餘修改，就不需要建立空的 cleanup commit。

今日小結

今天把 GitHub Issue 和功能 commit diff 放在一起，確認每項變更能否對應需求。