把測試做紮實：更貼近業界的測試方式 TESTS.md

VERIFY 是驗收，TESTS 是細部測試。VERIFY.md 由你寫，條數少、人看得懂，說「怎樣算做好」（驗收測試，Acceptance Test）；TESTS.md 由 AI 從每一條展開成細部測試（Test Cases）。上週 AI 補的先寫在 VERIFY 裡，是簡化版；實務上更常會多一份 TESTS.md 來管理，你寫的和 AI 補的分清楚。

一條 VERIFY，展開成好幾條。邊界：剛好在線的兩邊各測一次（1 格內撿得到、2 格撿不到）；沒想到的情況：那一格已經 64 個；組合：兩個一起撿，數字 +2；順序：撿起來、重新整理網頁，數字還在；迴歸：修好過的 bug 寫成一條測試，以後不能再發生。

每一條都追得回來（追溯，Traceability）。T3.1 就是 STEP 3 展開的第 1 條。審的時候一組一組看；VERIFY 改了，馬上知道哪幾條要跟著改。

AI 展開，你審三個問題。請 Codex 從 VERIFY.md 寫成 TESTS.md，每條標出來源，先不要寫程式；再問：每一條 VERIFY 底下都有細部測試嗎？有沒有邊界情況？測的是規則，不是畫面？（「很好看」測不出來。）不對就請 AI 改。

順序：VERIFY → TESTS → PLANS。先展開成細部測試，再排進 PLANS 的每一步。AGENTS.md 寫上：VERIFY.md 不要改；TESTS.md 從 VERIFY 展開，每條標出它來自哪一條；TESTS.md 我審過，才開始寫程式。

全部通過，只代表通過了「寫出來的那些」測試。程式和測試都是 AI 寫的；測試寫得太鬆，程式錯了也照樣綠燈。沒寫到的地方，綠燈不會告訴你。

故意弄壞一行，看測試抓不抓得到。像消防演習：把程式的一個數字改壞，跑全部測試。有測試變紅＝抓到了，這些測試有用；全部還是綠的＝沒抓到，少了一條測試。這叫突變測試（Mutation Testing）。

沒抓到的那一次，就是少的那條測試。把撿得到的距離 1.5 改成 15，測試全部通過，島上卻站在 5 格外也撿得起來：原來 T3.1 只測了「1 格內撿得到」。補上「2 格撿不到」，再弄壞一次，這次抓到了。

交給 Codex 做。先 commit；請它一次只改一行、跑全部測試、記下有沒有失敗、再改回來，最後告訴你哪一次沒被抓到。沒抓到的（放方塊時不扣數量），請它補一條測試並確認抓得到；全部改回來、全部通過，才 commit。

三個規則。先 commit，弄壞了才回得去；一次只改一行，試完一定改回來；沒抓到，要補的是測試，不是程式。不用每一行都試，先試最重要的規則（數字、存檔）。

大家都有盲點。測試全部通過，親自玩卻發現：走到島的邊邊掉下去，就一直掉、回不來。測試只會檢查「想得到的」；你沒想到，AI 也沒想到。

親自玩，才會發現。會發現兩種問題：壞掉的（bug），和不好玩的（太慢、看不懂要按什麼）。測試判斷不了好不好玩，所以交出去之前的最後一步，是人親自測試（Manual Testing）。

使用者故事（User Story）：身為＿＿，我想要＿＿，這樣＿＿。從玩家的角度，寫下他想完成的一件事。它通常在前期討論需求時寫，所以常和 BRIEF.md 放在一起；也有開發者直接開一份 USER_STORIES.md。

照著故事的路徑玩，記在 playtest.md。一張故事就是一條要親自走一遍的路：記下怎麼走、✓ 還是 ✗、發生了什麼。發現的問題接回流程：你先寫進 VERIFY → AI 展開進 TESTS → 先紅、再綠修好 → 弄壞一行確認抓得到 → 再親自走一次那條路。

先小、再大。先挑 3～5 條最重要的故事，親自走一遍；都沒問題，再擴展到更多故事、更多自動測試；最後找別人來玩，他們會走你沒想到的路。