這幾天主要在處理一個骰子遊戲專案——把日式骰寶賭法跟「每次闖關會越變越強」的肉鴿玩法接在一起、給直播用的遊戲。畫面上的新玩法已經定案好幾版，但一路檢查下來，發現定案的東西跟遊戲實際計算結果的邏輯對不上。
瞄準動作已拍板，判定邏輯還沒跟上
玩家丟骰子前要先瞄準一個落點，準心每次按下都會重新出現在隨機位置，放開後分成幾個節奏呈現結果，玩家要真的瞄準才有意義。照原本的規劃，這個瞄準結果應該要直接決定搖出哪一種結果，同一種結果裡才拚運氣。
但核對遊戲的正式規則文件跟背後計算程式後，發現整層還停在舊邏輯：瞄得準只是讓好結果的機率微幅加成，最終骰出的點數仍然是全機率重抽，等於瞄準準不準其實沒有真的改變結果，只是心理安慰。因此原本排定要做的下一步先暫停，插入一個專門處理新舊邏輯銜接的過渡階段。
flowchart LR A[準心落在哪一區] --> B[以為直接決定結果類別] A --> C[實際上只讓機率微調] C --> D[點數仍是全機率再抽一次]
換一個操作方式的時候，要回頭確認這個操作背後依賴的計算規則有沒有真的跟著換，不然很容易做出一個介面上看起來很講究、但結果論完全沒變的假動作。
技術細節：瞄準機制與判定邏輯的落差
新機制：落點打中哪一區 → 直接決定結果類別，同類別內才是運氣（regionAt() → resolveReg()，preview/chinchiro-ui.tpl.html）。 舊機制（仍在 core）：命中只讓出役機率 +5pp，點數仍全機率抽（roll.ts 等級→機率加成模型、state.ts 兩段 phase、events.ts）。 規則正本 docs/GAME-DESIGN.md §3-3 與已完成的 Phase A／B（core、agents、平衡管線）仍是舊邏輯。 因此暫緩原訂 C-1，新增 Phase C0 作為換軌層，先處理新舊邏輯銜接。
版號亂過一次之後，立了「只能有一條線」的規矩
專案有一份記錄畫面長怎樣的設計文件，跟一個實際可以點開看的預覽網頁，兩者理論上要隨時對得上。有一次，預覽網頁的標題被標成某個版號，但那個版號其實已經在設計文件裡代表過另一批完全不同的畫面內容——等於同一個門牌號碼貼在兩棟不同的房子上。
發現之後，改回一個沒被用過的新版號，並訂下一條規矩：以後版號只能沿著一條時間線往前編，不能讓兩邊各自開一條線、各自喊到「第五版」卻是兩個東西。這個混亂背後還有另一個常態問題：設計文件常常是畫面已經改了好幾輪才回頭補，標題卻還寫著很多版以前的字樣。
任何時候有兩份東西需要保持同步，版號的編號權只能交給一個地方，另一邊只能跟著抄，不能自己另外喊號碼。
技術細節：撞號事件與版號規則
e7a1dd3 把預覽頁 h1 寫成「v5」，但 v5 在 docs/UI-DESIGN-SYSTEM.md §0-1 已是 2026-09-07 另一批裁決內容，使用者裁決改為 v9，078b449 修正。 §0-1 立下判準：描述「畫面現在長怎樣」的內容要跟著改，描述「當時決定了什麼」的歷史紀錄不動（例如第 1114 行的 1916 年份刻意保留）。 另有一處 CSS 註解漏改（1916 未同步成 1914），已於 24dfbe0 補上。
對照用的參考畫面常忘記更新，改成程式自動擋住
專案裡有一個給團隊核對畫面細節用的參考頁面，問題是每次畫面改完，常常沒有立刻回頭更新，累積很多版之後才想到要補，補的時候東缺西漏。這個問題拆成兩半來治：一半是「忘記」，交給自動檢查機制——只要正式內容有改動但參考頁面沒跟著更新，程式就直接擋下來，列出漏掉的是哪幾個改動，逼人補完才能繼續。
另一半是「補得不完整」，交給固定的檢查流程加上自動比對差異來抓漏。這個擋停機制只在東西真的定案時才會發動，不會在半成品階段就亂擋。
靠「記得要做」來維持兩份東西同步，長期一定會失守，因為人會忘記，而且越忙越容易忘。與其提醒自己要記得，不如做一個東西在該同步卻沒同步時直接卡住流程，逼你當下處理。
技術細節：Artifact 發布擋停機制
docs/ARTIFACTS.md 為發布帳本體，記錄每個網址「已對齊到哪個 commit」。 .claude/hooks/artifact-sync-guard.sh 為 Stop hook，比對 已對齊..HEAD 是否動到監看路徑，落後就 exit 2 擋停並列出是哪幾個 commit。 只擋已 commit 的落後，工作目錄未提交的變更只提醒不擋。
接下來
- 把換軌層（Phase C0）做完，讓新的瞄準結果真的能對上骰子最終點數的判定。
- 持續留意版號與參考畫面是否還有沒堵到的漏洞。
本篇由跨專案自動彙整產生，素材為 2026-09-08 之後 1 個專案的提交紀錄與 0 則知識投遞。