昨天請 Codex 替「新增任務」提出實作計畫，並在修改程式以前檢查了檔案範圍、資料流、測試與尚未決定的問題。

今天要把確認後的計畫交回 Codex，正式完成 Issue Tracker 的第一個產品功能。

今天要完成什麼？

這次的功能範圍和昨天相同：

• 使用者可以輸入任務標題
• 送出後，新任務會顯示在清單中
• 標題前後的空白會被移除
• 空白標題不能建立任務
• 驗證失敗時要顯示訊息
• 成功新增後要清空輸入欄位
• 加入對應的自動化測試

編輯、刪除、搜尋、篩選、排序與拖曳仍然不在今天的範圍內。

功能很小，但已經包含輸入、驗證、狀態更新、畫面變化與測試，足以走完一次完整的 coding agent 工作循環。

為什麼沿用昨天的 Codex 任務？

昨天的對話中已經有原始需求、Codex 提出的第一版計畫，以及人工確認後的最新版計畫。

今天直接在同一個任務繼續，可以清楚地用「已確認的計畫」作為實作依據。如果改開新任務，就應該把最後確認的完整計畫重新提供一次，不能只說「照昨天的計畫做」。

開始前，我也會先確認沒有新的需求變更。因為只要驗收條件或技術決定改變，原本的計畫就應該跟著更新。

實作前先確認 Git 狀態

在 Codex 開始修改前，先確認 repository 是否乾淨。

如果已經有未提交的變更，要先知道那些變更來自哪裡，以及是否和這次功能重疊。否則完成後很難分辨哪些程式是 Codex 本次產生，哪些是原本就存在的修改。

我會請 Codex 在完成摘要中同時回報修改後的 Git 狀態，方便前後對照。

今天使用的 Prompt

確認昨天的計畫沒有待處理問題後，我接著輸入：

請依照剛才確認的最新版計畫，實作 Issue Tracker 的「新增任務」功能。

驗收條件仍然是：
1. 使用者可以輸入任務標題
2. 送出後，新任務會顯示在任務清單中
3. 標題前後的空白要移除
4. 空白標題不得建立任務
5. 驗證失敗時要顯示可理解的訊息
6. 成功新增後要清空輸入欄位
7. 必須加入對應的自動化測試

執行要求：
- 遵守 AGENTS.md
- 只修改計畫中確認過的必要檔案
- 不實作範圍外功能
- 不進行無關重構
- 遇到會改變原計畫的重要問題時先停下來說明
- 完成後執行 AGENTS.md 要求的測試與建置

最後請回報：
1. 實際修改的檔案與各自用途
2. 每項驗收條件如何完成
3. 執行的驗證指令與結果
4. 和原計畫是否有差異，以及原因
5. 仍未解決的問題
6. 目前的 Git 狀態

這個 Prompt 沒有再次要求 Codex 規劃，而是清楚授權它開始修改，同時保留一個停止條件：如果實際情況會讓已確認的計畫出現重大改變，要先回報，而不是默默換一種實作。

這段 prompt 的回覆和執行

這是我的 repo，在裡面的 commit 找到 "add issue creation" 就是這篇文章寫完時的狀態。

實際操作功能

等 Codex 完成後接著啟動 Issue Tracker，手動操作一次完整流程：

1. 輸入一個有效標題並送出
2. 確認任務出現在清單
3. 確認輸入欄位已清空
4. 輸入前後帶有空白的標題
5. 確認清單只保留整理後的文字
6. 送出空字串或只有空白的內容
7. 確認沒有新增任務，並顯示錯誤訊息
8. 修正輸入後再次送出，確認可以成功新增

自動化測試可以重複驗證固定行為，人工操作則能發現畫面、焦點、訊息位置或操作感受等測試可能沒有涵蓋的問題。

檢查實際變更範圍

最後查看 Git diff，確認：

• 每個修改都能對應到新增任務功能
• 沒有出現計畫外的套件或設定變更
• 沒有提前完成後續功能
• 沒有大範圍重新格式化既有檔案
• 測試與功能程式一起被加入
• 暫存檔、測試輸出與建置產物沒有被提交

如果發現小問題，可以在同一個 Codex 任務中提出具體修正要求，再重新執行相關驗證。

但如果問題涉及整體設計或需求改變，就應該回到計畫階段，而不是一邊修改、一邊讓範圍持續擴大。

今日小結

今天把昨天確認的計畫交給 Codex，完成了 Issue Tracker 的第一個小功能。