SpinningTop / AI 網頁遊戲
十個篇章、可逐層展開（點章節 → 點工項看細節）。含你點名的項目＋我補上的「你還沒想到的」（標 ✚）。每個工項標狀態/負責/規模。
把畫面做對做穩——目前主戰場。
已完成並部屬。完整記錄見 wiki 問題報告＋規範 R1-R12。
狀態：完成（tag: stable-fx2d 保護）
4 種變體 shader 程序化、零貼圖上傳。已部屬。
狀態：待你驗 FPS＋視覺｜負責：AI｜驗收：你/美術
技術選型按頻率：變化慢→貼圖烘焙；幾何規則→shader。逐項凍結對比驗收（R12 視覺零改變）。
規模：中（每種 0.5~1 天迭代）｜負責：AI＋你當眼睛
各有專屬 canvas 畫法。billboard 貼圖或 shader 逐型重現，不降級。
規模：中｜依賴：依附特效做完的經驗
空中特效蓋怪可能是合理的——先評估哪些真的需要進 3D，不盲搬。
規模：小（評估）＋中（實作）
現為輕透視（20）。你回饋「要更立體/更平」，改一個常數即可。
等你回饋一句話
你排後面的。材質參數微調對齊 2D。
規模：小
機台要長時間穩 60fps——效能是驗收條件不是加分項。
現況「GPU 合批、CPU 逐隻擺骨架」→ CPU 隨怪數線性。VAT 把動畫烘成貼圖、頂點 shader 查表 → CPU 歸零。我們的怪是甜蜜點（動畫段固定、不需混合）。
規模：中型工項（烘焙工具＋shader＋逐型驗）｜負責：AI｜建議排效能第一波
現況估 30~60/幀（健康）。需要時：特效 quad 改 instanced、貼圖 atlas。別過早優化。
觸發條件：實測掉幀且定位到 draw call 時才做
你沒點名但機台/玩家都有感：FBX/貼圖壓縮（KTX2/Draco）、按需載入、loading 進度畫面。現況首載較肥。
規模：中｜量測先行（先看現在載多久多大）
機台長時間運行（幾天不關）——貼圖/幾何釋放、事件解綁、長跑 soak test（開 24 小時看記憶體曲線）。引擎幫你管的，現在要自己管。
規模：小工具＋定期跑
renderScale 降階已有開關；補「自動偵測掉幀→降級」與機型測試矩陣。
依賴：目標機規格確定
正式運轉時回報 FPS/卡頓事件（本地 log 或後端），讓效能退化「被看見」而不是等客訴。
規模：小
沒有引擎編輯器 → 用「配置表＋AI 自建面板」補。這章做完，非工程師才進得來。
模型/血量/速度/動畫段/票數抽成 JSON——企劃改表即生效，不碰 code。這是驗證「AI 造工具給團隊用」模式的第一步。
規模：小～中｜負責：AI 做、企劃用
網頁面板：左改參數、右即時預覽（轉視角/播動畫）、存檔寫回 JSON。
規模：中｜依賴：配置表先行
顏色/大小/速度/曲線滑桿＋即時預覽。美術自調不經工程。
規模：小～中（AI 一兩天）
出怪波次、時間軸、場地事件——同樣配置表→面板兩步走。
依賴：怪物配置表模式驗證後複製
美術出 FBX/貼圖的規格（軸向/尺寸/命名/目錄/動畫幀段登記表）——我們踩過的「動畫段切錯檔」「軸向搞反」就是沒規範的代價。
規模：小（半天文件）但省未來大量坑
HUD/選單/計分走 DOM：瀏覽器渲染、美術可直接調、多語系容易。世界內 UI（血條/頭上數字）留遊戲層。
規模：中｜收益：美術工作流＋維護性
標題/選人/結算/待機吸引模式（attract mode，機台必備）——現有 12 個畫面狀態，逐一驗收完成度。
規模：盤點小、補做依結果
文案抽字串表。走 HTML UI 後這件事變容易。
依賴：出海/多地需求確認
鍵盤（現況）/機台按鈕/搖桿的輸入層統一——機台部署前必做。
規模：小～中
現有 SoundSystem 能播；缺管理面。
哪個事件配哪個音、音量/優先級/同時發聲上限——配置表模式（同怪物表）。瀏覽器自動播放限制已處理。
規模：小～中
BGM/SFX 分軌音量、機台喇叭實地調校流程。
依賴：機台部署
營業機台的標準：當機=停業。引擎不會幫你，全要自建（部分已有）。
已有 ErrorRecovery（context 掉了自動回退 legacy 渲染）。
狀態：已有，機台前補實測
window.onerror/unhandledrejection 上報（本地檔或後端）——營運中「畫面怪怪的」要有 log 可查。
規模：小
現有 vitest（渲染管線有測試，相機 11 條剛更新過）。補：機率水位計算、碰撞規則等「錢相關」邏輯的測試。
原則：業務邏輯優先，畫面靠人眼
目標環境定清單（機台用哪個瀏覽器內核鎖版本），避免「瀏覽器自動更新弄壞遊戲」。
依賴：機台環境確定
連跑 24-72 小時：記憶體曲線、FPS 衰減、自動重啟機制（看門狗）。
依賴：接近上機時
這是彩票機生意的命脈章節——網頁遊戲只是「前端」，投幣出票對帳才是產品。
已搬入並接上票數顯示。待：水位參數的營運調整介面＋與後端同步機制確認。
狀態：程式碼已落地｜營運面待定義
網頁 ↔ 機台 IO（投幣訊號、票口）——WebSocket/串口橋接服務。既有專案（瓢蟲等）有可參考實作。
規模：中｜依賴：機台硬體規格
投幣/出票/中獎流水必須可稽核、斷電不遺失——本地持久化＋回傳。
法規/稽核相關，優先級由業務定
遊戲中斷電重開後的狀態恢復策略（吃幣未出票=客訴）。
依賴：帳務設計
已建：3 分鐘上線、穩定點 tag 可回退。
狀態：完成
現在只有一個網址=你測的就是最新開發版。上機前要分：開發版隨便炸、正式版只上驗過的 tag。
規模：小（Cloudflare 多環境）
kiosk 全螢幕瀏覽器、開機自啟、離線快取（斷網可玩）、遠端更新策略。
依賴：機台環境
驗收清單→打 tag→部正式環境→現場抽驗。一頁文件。
規模：小
深入篇⑤的落地工項化。
已建立並實測（AI 換模型接手成功）。
狀態：持續維護
把「凍結對比/實機效能/手感回饋」寫成 checklist，美術/企劃加入後照表驗收——不再只靠你一個人當眼睛。
規模：小（半天文件）｜時機：團隊成員加入前
新成員（人或 AI）第一天讀什麼：wiki index→規範→總藍圖（本頁）→自己跑起專案。
材料都有，整理半天
正式化「一句話需求＋參考→AI 方案→部屬→驗收→沉澱」循環：用什麼追（看板/表格）、多久一批。
你定節奏，工具不拘
緩解：知識全在 repo（wiki/規範/commit）——已驗證換 AI 可接手；人的部分靠 onboarding 包。
緩解：目標機早期實測（別等做完）；VAT 等大工項做之前先在目標機量基線。
緩解：機台鎖瀏覽器版本；web 版訂相容矩陣定期跑。
緩解：R12＋凍結對比已制度化；重大改版前打 tag（已在做）。