# MANUAL_TEST_PLAYBOOK.md

本 playbook 是 v1.1 人工測試定稿，目標是讓 tester 從乾淨存檔開始，逐段驗證新手教學、階段解鎖、功能 gate、早期節奏、飛升前後系統、跳過教學與離線收益。本文依 M72-draft proposal 建立主流程，並已用 M66-auto + M71 常數補刀後的實測 anchor 校正時間窗口。

測試原則：人工測試不是要複製最優 simulator 操作，而是檢查真實玩家路徑是否符合「快推進派」體感。M71 final 顯示兩個 optimal profile 均通過 8/8 criteria：`optimal-no-tutorial` 在 0 分鐘達成第一次突破、第一座新建築與第 5 位弟子，29 分鐘達成第一次飛升與 Stage 5，30 分鐘達成 Stage 7；`optimal-with-tutorial` 因教學成本第一次突破為 1 分鐘，第一次飛升、Stage 5、Stage 7 為 30 分鐘。人工測試允許比最優 profile 慢，但第一突破、第一座新建築、第五位弟子、教學觸發與功能 gate 必須在合理窗口內可見。

## 1. Pre-flight

測試前先建立乾淨、可追溯的環境。此章的目的不是驗證玩法，而是避免存檔、設定、舊教學狀態或本機時間污染結果。

| 項目 | 操作 | 預期狀態 | Pass/Fail/Note |
|---|---|---|---|
| 清存檔 | 備份後移除目前 `userData/save.json` 或使用遊戲內新存檔槽 | 進入遊戲時視為 fresh save |  |
| 計時器 | 從第一次進入主畫面或 pet 展開主窗開始計時 | 所有 checkpoint 用同一支碼表記錄 |  |
| 教學狀態 | 確認 Settings 內未啟用「跳過所有教學」 | `welcome` 應可於 fresh save 觸發 |  |
| 視窗狀態 | 使用預設桌面視窗尺寸，必要時再補 800x600 smoke | 教學 spotlight、tooltip、表格、按鈕不重疊 |  |
| 記錄方式 | 開一份測試紀錄，逐列填 Pass/Fail/Note | 每個 fail 都有時間、畫面、重現步驟 |  |

本輪必須特別記錄 25 條 tutorial step 的觸發狀態：`welcome`、`first-disciple`、`first-breakthrough`、`first-new-building`、`unlock-dao`、`unlock-autoassign`、`unlock-automation`、`unlock-goals`、`unlock-ascend`、`unlock-echoes`、`unlock-inheritance`、`unlock-fortune`、`unlock-bonds`、`unlock-inventory`、`feat-batch-100x`、`feat-batch-1000x`、`feat-batch-max`、`feat-upgrade-tree`、`feat-enhance-root`、`feat-seclusion`、`feat-skill-tree`、`feat-affinity-match`、`feat-spirit-box`、`feat-enchant`、`feat-tribulation`。

系統起始開放應包含 `inventory`、`buildings`、`disciples`；`recruit` 在擁有 1 位弟子後解鎖；`dao` 在完成 1 次突破後解鎖；`autoassign` 與 `automation` 在 5 位弟子後解鎖；`goals` 在 3 座建築後解鎖；`fortune` 在遊玩 25 分鐘後解鎖；`bonds` 在遊玩 30 分鐘後解鎖；`echoes` 與 `inheritance` 在 1 次飛升後解鎖。若 UI 顯示與這些規則相反，列為 gate bug。

### M71 實測 anchor 參考

下表是本 playbook 的時間校正基準。人工 tester 以「人工窗口」判斷體感與可達性；M71 實測值用來判斷若實測遠慢於窗口時，該記錄為 balance anchor 或操作引導問題。

| Anchor | M71 `optimal-no-tutorial` | M71 `optimal-with-tutorial` | 人工窗口 / 判斷 |
|---|---:|---:|---|
| firstBreakthrough | 0m | 1m | 2m 內應可見；超過 3m 記 High |
| firstNewBuilding | 0m | 0m | 3m 內應可見；超過 5m 記 High |
| fifthDisciple | 0m | 0m | 15m 內應可達；超過 20m 記 balance anchor issue |
| firstAscension | 29m | 30m | 5h 內應可達；人工 30m-3h 需看到明確飛升方向 |
| Stage 5 | 29m | 30m | 5h 內應可達；若 UI 到條件後不解鎖記 gate bug |
| Stage 7 | 30m | 30m | 24h sanity bound；人工可用長跑或測試存檔補驗 |
| feedbackDensity30m | min=60 | min=60 | 前 30m 每窗口至少 5 events |
| spiritQi minute 60 | 720100.0000000002 | 694700.0000000002 | 分別為 M61 baseline 的 9.48x / 9.15x，需留在 3x-10x cap 內 |

## 2. Phase A：Stage 0-2 早期（0-5 分鐘）

此階段驗證新手入口、第一位弟子、第一次突破、第一座建築與核心教學鎖定。M66-auto 的整體 anchor 要求 firstBreakthrough ≤ 2 分鐘、firstNewBuilding ≤ 3 分鐘；人工測試可用 0-5 分鐘窗口確認功能可達，但若 3 分鐘內完全沒有突破或建築進展，需記錄為節奏風險。

| 時間 | 預期事件 | 教學該觸發 | 通過條件 | Pass/Fail/Note |
|---:|---|---|---|---|
| 0:00 | fresh save 進入主畫面 | `welcome` | 歡迎提示出現，非目標區域點擊被攔截，能按「下一步」 |  |
| 0:15 | 第一位弟子可見 | `first-disciple` | 弟子卡存在，spotlight 指向 `[data-tutorial-target="disciple-card"]` |  |
| 0:30 | 初始系統 gate 檢查 | 無新增 | 倉庫、建築、弟子可用；高階系統不應提前全開 |  |
| 1:00 | 操作弟子與靈氣收益 | 無新增或核心引導 | 資源數字持續變化，無 NaN、Infinity、負數 |  |
| M71 0-1m / 人工 1:30 | 準備第一次突破 | `first-breakthrough` | 突破按鈕被 spotlight 指向，按鈕文字不被遮擋 |  |
| M71 0-1m / 人工 2:00 | 完成第一次突破 | `unlock-dao` 可能接續 | 弟子境界提升，Stage 應至少到 2，道學入口按規則出現 |  |
| M71 0m / 人工 2:30 | 第一座新建築可見 | `first-new-building` | 建築 tab 可進入，新建築或新建築卡片可辨識 |  |
| 3:00 | 倉庫教學檢查 | `unlock-inventory` 於打開倉庫時觸發 | 倉庫可顯示物品與配方狀態，教學只觸發一次 |  |
| 4:00 | 基礎建築升級 | 無或 `feat-affinity-match` | 升級後產出變化可見，派別配對提示不應在無匹配情境亂跳 |  |
| 5:00 | 早期總結 | 已觸發核心 4 步 | 無卡死遮罩；可繼續招募、突破、升級建築 |  |

此階段的 fail 優先級很高。若 `welcome`、`first-disciple`、`first-breakthrough`、`first-new-building` 任一核心流程不能正常完成，後續測試仍可繼續，但必須在 bug 表標記為 blocking onboarding issue。核心流程的 `skipLevel` 只有 `all-only`，不可出現「跳過此步」造成流程殘缺。

## 3. Phase B：Stage 3-4 中期（5-30 分鐘）

此階段驗證 5 位弟子、分派、自動化、道學、目標、強化靈根、閉關、升級樹與前 30 分鐘回饋密度。M66-auto 要求 fifthDisciple ≤ 15 分鐘，前 30 分鐘 feedbackDensity 每窗口 ≥ 5 events；人工測試應觀察是否每幾分鐘都有明確解鎖、升級、突破、研究或目標回饋。

| 時間 | 預期事件 | 教學該觸發 | 通過條件 | Pass/Fail/Note |
|---:|---|---|---|---|
| 5:00 | 嘗試持續招募 | 無或招募相關提示 | 弟子數可穩定增加，招募入口不被 gate 誤藏 |  |
| M71 0m / 人工 8:00 | 達成或接近 5 位弟子 | `unlock-autoassign`、`unlock-automation` | 分派與自動化入口出現，教學可單步或群組跳過 |  |
| 10:00 | 檢查派別配對 | `feat-affinity-match` | 將主派或副派弟子放入相符建築，產出倍率或提示可見 |  |
| 12:00 | 檢查建築指派 | 無或分派提示 | `building.assign-disciple` Stage 3 可用，錯配不造成 UI 崩潰 |  |
| M71 0m / 人工 15:00 | 第五弟子 anchor | 無或系統教學排隊 | 若仍少於 5 位弟子，記錄原因：資源不足、入口不明、招募卡死 |  |
| 18:00 | 道學與研究 | `unlock-dao` 若先前未見 | 道學 tab 顯示節點，研究操作不破壞資源顯示 |  |
| 20:00 | Stage 4 功能檢查 | `feat-upgrade-tree`、`feat-enhance-root`、`feat-seclusion` | 升級樹、強化靈根、閉關在 Stage 4 可見；Stage 5+ 功能仍 gate |  |
| 25:00 | 天機時間 gate | `unlock-fortune` | 遊玩 25 分鐘後天機入口出現，過早或過晚都記錄 |  |
| 30:00 | 羈絆時間 gate | `unlock-bonds` | 遊玩 30 分鐘後羈絆入口出現，前 30 分鐘事件密度足夠 |  |

Stage 3 的條件是弟子數 ≥ 5；Stage 4 的條件是突破數 ≥ 5。若 tester 已達條件但 UI 沒有變化，先截圖並記錄當前 discipleCount、breakthroughCount、buildingCount、ascensionCount、playtimeMinutes。若 UI 提前顯示 `building.batch-100x`、`building.batch-1000x`、`building.batch-max`、`disciple.skill-tree`、`fortune.spirit-box`、`fortune.enchant` 或 `fortune.tribulation`，視為 feature gate 提前開放。

## 4. Phase C：Stage 5 飛升前夜（30 分鐘-3 小時）

此階段不是要求一定在 3 小時內完成所有飛升，而是驗證飛升前的長線目標是否清楚：突破曲線、技能樹、飛升按鈕、天劫提示、目標追蹤與資源需求必須能被玩家理解。M65/M66 的方向是第一次完整世界飛升落在 3-5 小時；人工測試在 30 分鐘到 3 小時應至少看到「我正在往飛升靠近」的訊號。

| 時間 | 預期事件 | 教學該觸發 | 通過條件 | Pass/Fail/Note |
|---:|---|---|---|---|
| M71 29-30m / 人工 30:00 | 中期狀態盤點 | 無 | 記錄弟子數、建築數、突破數、最高境界、spiritQi；若已達飛升或 Stage 5，記錄具體時間 |  |
| 45:00 | 目標系統回查 | `unlock-goals` 若 buildingCount ≥ 3 | 目標列表能指出下一個短中期方向，不是空白或過期 |  |
| 60:00 | M71 cap 對照 | 無 | 60m spiritQi 參考值：optimal-no-tutorial 720100.0000000002，optimal-with-tutorial 694700.0000000002；人工可慢，但不應完全停在 Stage 1-2 |  |
| M71 29-30m / 人工 75:00 | Stage 5 候選功能 | `unlock-ascend`、`feat-skill-tree` | 達到飛升條件時，飛升按鈕出現且說明不暗示 reset |  |
| 90:00 | 連續突破壓力測試 | 無 | 多次突破後 UI、事件 log、資源格式仍穩定 |  |
| 120:00 | 飛升前提示 | `feat-tribulation` 可能於對應 feature unlock | 天劫或飛升前選擇如出現，文案、按鈕、結果可讀 |  |
| 180:00 | Phase C 結束盤點 | 無 | 記錄是否已達 Stage 5；未達時記錄卡點，不直接判定玩法 fail |  |

特別注意「永不重置」原則。飛升應讓該弟子離開並留下長期加成，不能清空其他弟子、建築、倉庫、道學、目標或宗門進度。若任何流程出現 prestige、rebirth、reset 類文案或行為，列為高優先級設計違反。

## 5. Phase D：Stage 6-7 後期（3+ 小時）

此階段驗證第一次飛升後的系統串接，以及更後期 gate 是否正確。若 3 小時內尚未飛升，tester 可保留原紀錄並用加速、debug save 或後續 M66/M72-final 提供的測試存檔補跑此章，但必須標記使用了哪種方式。

| 時間 | 預期事件 | 教學該觸發 | 通過條件 | Pass/Fail/Note |
|---:|---|---|---|---|
| M71 29-30m / 人工 3:00+ | 完成第 1 次飛升 | `unlock-echoes`、`unlock-inheritance` | 殘影與傳承入口解鎖；其他既有進度不被清空 |  |
| 3:10+ | 檢查 Stage 5 功能 | `unlock-ascend` 若先前未見 | `overview.ascend-button`、`disciple.ascend`、技能樹符合 Stage 5 gate |  |
| 3:30+ | 第 2 次飛升後 | 無或系統提示 | Stage 6 條件為 ascensionCount ≥ 2 且 playtime ≥ 30 分鐘 |  |
| 3:45+ | Fortune sub-tabs | `feat-spirit-box`、`feat-enchant`、`feat-tribulation` 視 gate | Stage 6 可見 wheel/gacha；Stage 7 才開 spirit-box/enchant/tribulation |  |
| 4:00+ | 羈絆與編隊 | 無或 `unlock-bonds` | bond bonus、同派 stacking 提示與產出不互相矛盾 |  |
| M71 29-30m / 人工 5:00+ | Stage 5 anchor | 無 | M66 目標為 stage5 ≤ 5h；若未達，記錄阻塞乘區與玩家操作 |  |
| M71 30m / 24:00 內 | Stage 7 sanity | 無 | stage7 ≤ 24h 是 sanity bound；人工測試可由長跑或存檔補驗 |  |

Stage 7 的條件是 ascensionCount ≥ 5，代表全部 14 系統與全部 sub-feature 解鎖。此時再檢查 `building.batch-1000x`、`building.batch-max`、`auto.dispatch-toggle`、`auto.dispatch-run`、`auto.recycle-byproducts`、`fortune.spirit-box`、`fortune.enchant`、`fortune.tribulation`。任何 Stage 7 功能若在 Stage 4 以前出現，都要回報為新手 UI 過載；若 Stage 7 已達仍不可見，回報為 gate 遺漏。

## 6. Phase E：跳過教學流程驗證

此章用第二份乾淨存檔或重置教學後執行，不要污染 Phase A-D 的主紀錄。目的在於確認 M60 三層跳過不會破壞 progression：單步跳過只跳當前 step，群組跳過只跳同類系統，全跳過則永久禁用 overlay，但所有系統解鎖與 feature gate 仍照常運作。

| 時間 | 預期事件 | 教學該觸發 | 通過條件 | Pass/Fail/Note |
|---:|---|---|---|---|
| 0:00 | fresh save 觸發 welcome | `welcome` | 只能全跳過核心流程，不能單步跳核心造成半完成 |  |
| 0:30 | 點選跳過全部 | 後續不再出現教學 | 弟子、突破、建築、道學仍可正常解鎖 |  |
| 2:00 | 重置教學後重跑 | `welcome` 重新出現 | Settings 的重新體驗教學可清空 completed |  |
| 5:00 | 系統教學單步跳過 | 例如 `unlock-dao` | 只完成或略過該 step，其他系統 step 仍會排隊 |  |
| 8:00 | 群組跳過 | 例如自動化群組 | 同 group 不再彈，但其他 group 如 fortune/bonds 不受影響 |  |
| 15:00 | skip all profile 對照 | 無 overlay | 操作節奏接近 `optimal-no-tutorial`，不應因隱藏教學而卡流程 |  |

跳過教學不是跳過遊戲內容。若跳過後系統入口消失、存檔不能恢復、已完成 step 重複刷屏，或 group skip 把不相關 step 一起關閉，全部列為 tutorial state bug。若 skip all 後仍出現 overlay，也要記錄當前 step id 與觸發操作。

## 7. Phase F：離線收益驗證

此章驗證 idle 桌面遊戲最重要的信任基礎：關閉或離開後回來，產出、時間、存檔、教學狀態與 gate 都要一致。離線收益不應繞過核心條件，也不應因視窗關閉造成 race 或重複發獎。

| 時間 | 預期事件 | 教學該觸發 | 通過條件 | Pass/Fail/Note |
|---:|---|---|---|---|
| T0 | 記錄當前狀態 | 無 | 寫下資源、弟子、建築、突破、當前教學 step、stage |  |
| T0+1min | 關閉主窗或退出後重開 | 不應重播 completed step | 資源增加或維持合理；無倒退、無 NaN |  |
| T0+5min | 再次離線回來 | 只觸發新解鎖 step | 若離線期間達 unlock condition，回來後可見對應入口 |  |
| T0+30min | 長離線 smoke | `unlock-fortune` / `unlock-bonds` 視時間 | playtimeMinutes gate 不應因系統時鐘錯誤提前大量跳階 |  |
| 飛升後 | 離線前後對照 | `unlock-echoes` / `unlock-inheritance` 已完成則不重播 | 殘影、傳承、既有建築與資源保持一致 |  |

離線收益測試要分辨「允許的 idle growth」與「錯誤的條件繞過」。例如資源增加可以接受，但沒有 5 位弟子就不應解鎖 Stage 3；沒有突破就不應解鎖 Stage 2/道學；沒有 ascensionCount 就不應解鎖殘影或傳承。若離線回來一口氣觸發多條教學，queue 必須順序清楚、能逐步完成，不能多個 overlay 疊在一起。

## 8. Phase G：M71 已知問題與 workaround

M71 final 仍保留一個已知問題：兩個 idle profile 都是 8/8 criteria FAIL。`idle-no-tutorial` 與 `idle-with-tutorial` 的 firstBreakthrough、firstNewBuilding、fifthDisciple、firstAscension、Stage 5、Stage 7 全部為 `null`，feedbackDensity30m 為 `min=0, failingWindows=30/30`，60 分鐘 spiritQi 分別停在 107400 / 107300，均低於 3x-10x cap 下界。

根因不是常數仍未調好，而是 M71 的範圍限制為 constant-only；目前 simulator 的 `applyIdleDecisions()` 會回傳原 state，不會自動招募、建造、突破、飛升或產生 feedback events。因此 M63/M64/M65/M68 的成本、產出與倍率補丁只能改善已有決策路徑，不能讓純 idle profile 自行進行 progression。

| Issue ID | 已知問題 | 影響 | Workaround / 測試方式 |
|---|---|---|---|
| `M72-PHASE-G-001` | idle profiles 8/8 FAIL | 純不操作的 simulator profile 無法代表 v1.1 可玩主路徑；不能用它判定 optimal 玩家節奏失敗 | 主流程驗收以兩個 optimal profile 與人工操作路徑為準；idle/offline 章節只驗證「已有進度」的離線收益與 gate 一致性 |
| `M72-PHASE-G-002` | idle feedbackDensity30m = 0 | 純 idle 不產生招募、建造、突破等進階事件 | 人工測試需執行最小操作序列：確認弟子、招募、建築、突破後再觀察 feedback queue |
| `M72-PHASE-G-003` | idle 60m spiritQi 低於 3x cap | 資源自然增長存在，但沒有決策推進，cap 判斷失去意義 | 只在有決策 profile 上使用 60m cap；離線收益以無倒退、無 NaN、無 gate 繞過為通過條件 |

若後續要讓 idle profile 通過 M66-auto，需另開 milestone 修改 simulator/player-profile decision logic，至少讓 idle profile 在可行且低頻的條件下自動招募、建造、突破與處理基礎教學。M72-final 不應在文件中把 idle FAIL 隱藏，也不應要求 tester 用純 idle 結果推翻兩個 optimal profile 的 8/8 PASS。

## 9. Bug / Issue 記錄表範本

每個 bug 都要能被下一位 tester 或工程師重現。若只是「感覺慢」，也要寫出當時時間、狀態與期望 anchor，方便後續 M72-final 或 M71 調參比對。

| 欄位 | 填寫內容 |
|---|---|
| Issue ID | 例如 `M72-MANUAL-001` |
| 發現時間 | 遊戲內相對時間與真實時間，例如 `12:30 / 2026-05-12 23:40` |
| Phase | Pre-flight、A、B、C、D、E、F、G |
| 嚴重度 | Blocker / High / Medium / Low |
| 類型 | tutorial、unlock gate、balance anchor、UI overlap、save/offline、copy、performance |
| 前置狀態 | discipleCount、breakthroughCount、buildingCount、ascensionCount、playtimeMinutes、stage |
| 重現步驟 | 1-5 步，從可觀察狀態開始，不寫模糊描述 |
| 實際結果 | 畫面、數值、log、錯誤訊息 |
| 預期結果 | 對照本文 checkpoint 或源規則 |
| 證據 | 截圖、錄影、save、console log、event log |
| 暫定判斷 | 可能來源，例如 tutorial queue、feature gate、stage compute、persistence |
| 後續處理 | 待修、已修待驗、非 bug、需設計裁決 |

範例：`M72-MANUAL-001`，Phase A，High，fresh save 後 `welcome` 出現，但點擊遮罩外仍能操作建築 tab。預期是 TutorialOverlay 攔截 target 外點擊；實際是玩家可在教學未完成時改變頁面，導致 `first-disciple` spotlight 指向不存在元素。證據需附截圖與操作順序。

## 10. 驗收結論模板

測試結束後，把本節複製到測試報告底部並填寫。結論要短，但必須能回答三件事：是否可交給 M72-final refinement、是否存在 blocker、哪些 anchor 需要 simulator 或工程再驗。

| 項目 | 結論 |
|---|---|
| 測試日期 / tester |  |
| build / commit / branch |  |
| 主路徑結果 | Pass / Conditional Pass / Fail |
| Phase A 結論 | 核心 4 步教學是否全通；firstBreakthrough / firstNewBuilding 是否在窗口內 |
| Phase B 結論 | 5 位弟子、Stage 3-4、道學、自動化、天機、羈絆 gate 是否合理 |
| Phase C 結論 | 飛升前目標感是否清楚；Stage 5 是否在 5h 目標內可達或有明確卡點 |
| Phase D 結論 | 飛升後殘影、傳承、Stage 6-7 gate 是否正確 |
| Phase E 結論 | 單步、群組、全跳過是否不破壞解鎖 |
| Phase F 結論 | 離線收益是否穩定且不繞過條件 |
| Phase G 結論 | idle profile 已知問題是否已記錄；是否按 workaround 驗證人工路徑 |
| Blocker 清單 |  |
| High/Medium issue 數 |  |
| 需要 M72-final 補充的資料 | 例如 M66-auto 報告、長跑存檔、截圖基準 |
| 驗收判定 | `PASS` / `PASS_WITH_ISSUES` / `FAIL_BLOCKED` |

建議判定規則：若 Phase A 核心教學任一不可完成、存檔會遺失、系統 gate 大面積錯誤、飛升造成重置，直接 `FAIL_BLOCKED`。若主流程可玩但存在中後期節奏或文案問題，判為 `PASS_WITH_ISSUES` 並列入 M72-final。若 10 章 checkpoint 均有紀錄、沒有 blocker，且所有 fail 都有 issue ID 與證據，才可判為 `PASS`。