今天不再把完整需求全部寫進 Codex Prompt，而是先建立一張 GitHub Issue，再讓 Codex 直接按照 Issue 實作搜尋與狀態篩選。

為什麼要用 Issue？

前面的功能需求都直接放在對話中。這種方式很方便，但需求只存在於某一個 Codex 任務裡。

Issue 則可以成為 repository 的工作紀錄，讓人和 Codex 看到相同內容：

• 為什麼要做這個功能
• 這次要完成什麼
• 哪些行為算完成
• 哪些內容不在範圍內
• 還有哪些決定需要確認

這不代表 Issue 寫完就不能調整，而是每次改變需求時，都有一個共同來源可以更新。

先處理會阻擋實作的問題

PRD 已經定義三種狀態：

• 待處理
• 進行中
• 已完成

但目前專案建立任務時只有標題，還沒有狀態資料；PRD 也留下了「新增時是否有預設狀態」以及「搜尋和篩選是否能同時使用」兩個問題。

這次 Issue 先做出以下決定：

• 新增任務的預設狀態是「待處理」
• 舊 localStorage 資料如果沒有狀態，讀取時視為「待處理」
• 搜尋和狀態篩選可以同時使用
• 同時使用時採用 AND，只顯示兩個條件都符合的任務
• 搜尋不分英文大小寫，只比對標題
• 狀態篩選一次選擇一種狀態，並提供「全部」

先把這些行為寫清楚，Codex 才不需要在實作中替產品做決定。

建立 GitHub Issue

我會在 Issue Tracker repository 建立一張 Issue，標題使用：

新增標題搜尋與狀態篩選

Issue 內容如下：

## 背景

目前任務數量增加後，使用者只能從完整清單中尋找項目，無法依標題搜尋或依狀態縮小範圍。

## 使用者故事

身為使用者，我希望能用標題關鍵字搜尋任務，並依狀態篩選清單，以便快速找到目前要處理的項目。

## 功能範圍

- 在任務清單上方加入標題搜尋欄位
- 搜尋只比對任務標題
- 英文字母搜尋不分大小寫
- 在清單上方加入狀態篩選
- 狀態選項為「全部」、「待處理」、「進行中」、「已完成」
- 每筆任務顯示目前狀態，並可切換三種狀態
- 新增任務時預設為「待處理」
- 搜尋與狀態篩選可同時使用，條件採 AND
- 狀態變更後保存到 localStorage
- 舊資料沒有狀態時，以「待處理」載入

## 驗收條件

- 輸入標題關鍵字後，只顯示標題符合的任務
- 搜尋 `BUG` 可以找到標題含有 `bug` 的任務
- 清除搜尋文字後恢復顯示符合目前狀態篩選的任務
- 選擇「待處理」、「進行中」或「已完成」時，只顯示該狀態任務
- 選擇「全部」時不因狀態排除任務
- 同時輸入關鍵字並選擇狀態時，只顯示兩個條件都符合的任務
- 找不到符合項目時顯示明確的空結果訊息
- 使用者可以在清單中切換任務狀態
- 重新整理後，變更過的狀態仍然保留
- 原有新增任務、標題驗證與持久化行為維持正常
- 新增與既有行為都有自動化測試

## 不做事項

- 不搜尋描述
- 不加入優先級與截止日期篩選
- 不實作排序、拖曳、編輯或刪除
- 不加入後端、登入或雲端同步
- 不重新設計整個頁面
- 不新增套件，除非現有工具無法完成且先取得同意

背景說明「為什麼」，功能範圍說明「要做什麼」，驗收條件則說明「怎樣算完成」。

不做事項也很重要。它能避免 Codex 因為看到完整 PRD，就把優先級、截止日期與排序一起實作。

先確認 branch 與工作區

把 Issue 交給 Codex 以前，我會先確認：

• 目前位於 feature/search-and-filter
• Working tree 沒有其他未提交變更
• Branch 起點包含前幾天已完成的功能
• AGENTS.md 仍然適用

如果昨天還沒有建立 branch，就先完成這一步，再開始實作。

讓 Codex 直接閱讀 Issue

建立 Issue 後，記下它的編號或網址，在新的 Codex 任務中輸入：

請閱讀目前 Issue Tracker repository，以及這張 GitHub Issue：
<貼上 Issue 網址或編號>

請先完成：
1. 摘要 Issue 的目標、驗收條件與不做事項
2. 確認 Issue 和目前程式、資料結構及 AGENTS.md 是否一致
3. 指出仍然模糊、互相衝突或無法驗證的地方
4. 列出預計修改的檔案與最小實作步驟

如果沒有阻擋問題，再依照 Issue 實作搜尋與狀態篩選。

執行要求：
- 只修改完成 Issue 所需的檔案
- 不實作 Issue 的不做事項
- 不新增套件或進行無關重構
- 舊 localStorage 資料必須保持可讀
- 每項驗收條件都要有對應的實作或測試證據
- 發現需求和現有程式衝突時先停止並說明

完成後執行 AGENTS.md 要求的驗證，並回報：
1. 修改檔案與用途
2. 每項驗收條件的完成證據
3. 測試、lint 與 build 結果
4. 實作和原計畫的差異
5. 尚未完成或需要確認的事項
6. 目前 Git 狀態

Prompt 本身不需要再複製整份需求，只要提供 Issue 位置與執行方式。

不過 Codex 必須真的能存取該 Issue。如果它無法讀取網址或需要權限，就應該停下來說明；此時可以改為貼上 Issue 完整內容，而不是讓它只根據標題猜測。

這段 prompt 的回覆和執行

先看 Codex 對 Issue 的理解

Codex 開始修改以前，我會先確認它的摘要：

• 三種狀態是否正確
• 新任務與舊資料的預設狀態是否正確
• 搜尋是否只比對標題
• 搜尋與狀態是否採 AND
• 狀態改變是否需要保存
• 不做事項是否被保留

如果這裡就理解錯誤，應該先修正計畫，不要等程式完成後才處理。

完成後逐項驗收

Codex 完成後，我會實際操作：

1. 建立多筆包含不同文字的任務
2. 將任務切換成三種不同狀態
3. 使用部分標題搜尋
4. 使用不同英文大小寫搜尋
5. 清除搜尋文字
6. 分別選擇三種狀態與「全部」
7. 同時使用搜尋與狀態篩選
8. 輸入找不到結果的關鍵字
9. 重新整理頁面，確認任務狀態仍然存在
10. 載入沒有狀態欄位的舊資料，確認仍能顯示

除了人工操作，也要確認自動化測試對應 Issue 的驗收條件，而且原有測試仍然通過。

檢查 diff 與 commit

依照昨天建立的 Git 流程，提交前要再次確認：

• Diff 只包含搜尋、狀態與必要測試
• 沒有加入優先級、截止日期或排序
• 沒有無關重構與套件更新
• 舊資料相容處理沒有改變其他持久化行為
• 測試、lint 與 build 都通過

這是我的 repo，在裡面的 commit 找到 "feat: add issue search and status filter" 就是這篇文章寫完時的狀態。

今日小結

今天先建立一張包含背景、範圍、驗收條件與不做事項的 GitHub Issue，再讓 Codex 把它當成實作依據。