陀螺彩票機 — 軟體工作盤點與時程

v2 修正了 v1 的一個根本錯誤

v1 把「網頁與遊戲串接」理解成編輯器產出的資料接進遊戲——那是錯的。實際上是 Unity 機台主機 ↔ WebView 網頁的雙向訊息橋，協定規格書 7/19 就寫到 v0.3，檔案在 stages/unity-web-bridge/。

v1 另外三處也修正了：特效的現況判讀、音效的方向（你已定案走編輯器）、以及編輯器的範圍（多數是我從程式碼推的，不是你提過的需求）。

來源分層每一項是誰決定的

這張表最容易失真的地方，是把「我的推論」混進「你的決定」。所以每項工作都標來源：

已定案你明確拍板過 建議中製程守門員提過、你未反對也未確認推論我從程式碼推的，未經討論

A 卡住其他事的決策全部在你手上

這五件不決定，後面的工作沒辦法開工或估時。排在最前面不是因為困難，是因為它們是塞子。

特效要不要超越目前的 2D 外觀（推翻 R12「視覺零改變」規範） 卡住：整條特效升級線，包含分項估時本身你講過「同步的效果遠遠不夠」，但正式拍板時被岔開了。這題不答，特效只能繼續做資料化搬遷，不能做視覺升級。
局內結果（outcome）的形式：是否採「每擊即問即答」模型 卡住：Unity ↔ Web 協定定案、兩端實作開工
操作員選單怎麼顯示（建議：隱藏 WebView、露出原生介面）卡住：同上
kunzhutsai 分支 4 個 commit 合回主線 內含：美術資產紅線、intake 轉檔工具、asset-lint 閘門、UI 規範 U1–U8
美術原始檔（PSD／4K）存放位置 卡住：美術交付流程定型

第六個塞子不在你手上：板子還沒到

板子到貨是唯一的硬性關鍵路徑，它同時卡住效能實測與 Unity 殼 POC 兩件事。

目前知道的全部規格：安卓板、大約 iPhone 8（A11）等級、用安卓內建瀏覽器跑、機台不接網路。 不知道的：型號、CPU／RAM、Android 版本、WebView 版本、螢幕解析度、採購時程。

其中 WebView 版本是開關性問題 —— 它決定 WebGL2 支不支援。建議板子一到手第一件事就是跑 WebGL2 自檢，那比任何效能數字都優先。

B Unity ↔ Web 串接 Web 6–9 · Unity 5–8 人日

架構已定案：Unity 是機台管家（機率、遊戲紀錄、投幣出票 IO、操作員選單、後台，既有框架零改動），Web 是純表演層。錢向決策只在 Unity 算，Web 回報事件流，永遠不自行決定中獎。

編號	工作	人日	來源	狀態
B1	Web 端橋接層＋桌面 mock：抽象化訊息橋（換套件不改遊戲）， mock 可模擬投幣讓 Web 端不等板子先開工	3–5	已定案	可開工
B2	Unity 端協定實作：13 種訊息、序號＋ack、心跳看門狗 3 秒重載、局終對帳	5–8	已定案	卡 A2·A3
B3	JSON 表格串接：一份表兩邊讀，機率表歸 Unity、演出表歸 Web	1–2	已定案	待 B1

C 板機落地 6–10 人日 · 多數卡板子

編號	工作	人日	來源	狀態
C1	採購 UniWebView 6（你原話「錢不是問題」，方向已定，尚未執行）	—	已定案	未執行
C2	Unity 殼 POC：WebView 全螢幕疊加、本地供檔驗證	2–3	已定案	卡 C1＋板子
C3	APK 混合式打包（內建出廠版＋外置更新優先）＋出貨精簡 dist（目標 30MB 內）	1–2	建議中	待 C2
C4	板機實測：WebGL2 自檢優先，再量 FPS／記憶體／draw calls，據此調降級檔位	1–2	已定案	卡板子到貨
C5	裝置分層與畫質分級補進 `PerfConfig` （目前只有 renderMode 三檔，無分級、無動態降級）	2	推論	待 C4

效能沒有明訂目標數字

從頭到尾沒有「必須 60fps」這類目標。現有的只有專案自訂的健康指標： draw calls 約 30、穩態貼圖上傳為 0、桌機實測 51 FPS。

另有提醒未獲回覆：Unity 殼本身吃 150–300MB RAM，板子記憶體要抓寬。

D 音效 2–3 人日 · 方向已定案

你的定案是「後續都要改用編輯器」—— 聲音統一走 cocos 移植的那套。現況是兩套 SoundSystem 並存：活著的簡單版（HTMLAudioElement，不認識 mixer），以及功能齊全的 849 行編輯器版，但它掛在 7/17 改版後的斷頭樹上 —— 現在調了也是白調。

編號	工作	人日	來源	狀態
D1	把 mixer 掛點移植到活著的 SoundSystem，設定從 localStorage 改為 JSON 隨 build 出貨（現在的設定根本不隨 build 走）	2–3	已定案	需切分工
D2	移植完成後刪除兩棵斷頭樹，隨附消掉 main 上 73 個 lint 錯的大宗	0.5	推論	待 D1
D3	撞擊音效依力道分層（回報中列為待執行）	1	推論	待 D1

D1 的執行需要先切分工 —— 製程守門員的移植範圍與我的斷樹清理範圍重疊，兩邊同時動會撞車。動工前由我協調。

E 特效估時待 A1 拍板

目前的陽春是規範造成的，不是能力上限

GPU 粒子系統早就建好了，但它在畫 2D 方塊。 原因是 R12 規範要求「視覺零改變」—— 3D 化被定位成渲染層搬遷，外觀必須與 2D 版一致。

管線本身有三個檔位（GPU 點精靈／Canvas 直畫／烘焙＋shader），物件池齊備， 架構不需要改。真正的效能殺手是 overdraw，不是粒子數量。

所以「特效要做多好」現在是純粹的決策問題，不是技術問題。 A1 拍板前，這一區給不出分項估時。

編號	工作	人日	來源	狀態
E1	特效升級路線圖（拍板後才寫得出來）	待估	建議中	卡 A1
E2	PrefabViewer 升級成特效曲線編輯器（企劃要量產特效時才需要）	3–5	建議中	未拍板
E3	剩餘未資料化項目：彩虹衝擊波、Boss 六角護盾蜂巢、殘影、鑰匙星星寶箱	6–8	推論	可開工
E4	陀螺特效遮住本體（回報中標「待確認」）。1 號是 Canvas sprite、 2 號 model2 在 WebGL，混合基底不同要分開處理	1.5	推論	可開工

F 資產管線與規範 2.5–3.5 人日

編號	工作	人日	來源	狀態
F1	Atlas 管線	2–3	建議中	可開工
F2	Define 收尾	0.5	建議中	可開工
F3	已完成待合併：進場載入優化已在主線（143MB→12MB），但 production 還沒部署	—	已定案	待部署

G 技術債 4.5 人日 · 7/26 稽核發現

這幾項不做不會馬上壞，但會讓上面每一條線走得越來越慢。G1 是今天所有發現裡風險最高的。

編號	工作	人日	來源	狀態
G1	`CLAUDE.md` 與 `prompts/` 合進主線。七個 AI 成員的身分設定全綁在未合併分支上，主線一切換就消失	0.5	推論	最高風險
G2	陀螺初始轉速不一致：`GameEngine.ts:739` 是 200， 958、1234、`Tops.ts:1082` 都是 100	0.5	推論	可開工
G3	起始座標散在四處（initGame、spawnTop、區域切換、返回流程），只有返回流程用動態計算。收斂為單一來源	1	推論	可開工
G4	worktree 註冊格式統一：WSL 與 Windows 兩端互相把對方標成可清除，任一端手動 prune 會抹掉另一端全部記錄（自動 prune 已封死）	1	推論	可開工
G5	舊分支清理：六條落後主線 60 個 commit 以上	0.5	推論	可開工
G6	等待區推開倍數：註解寫 2 倍，實作是 1.5 倍	0.5	推論	可開工
G7	`combine` 分支合併債（VFX Editor，領先主線 36、落後 57）	1	推論	跨人

部署 token 的事查過了，不是漏洞

publish_cf.bat 與 publish_daichi.bat 都被 git 追蹤且含憑證，但 .gitignore 開頭已寫明這是刻意的團隊共用取捨，並附了作廢程序（棄用時到 Cloudflare 後台 Delete）。

唯一要記得的是：token 一旦進 git 歷史就無法移除，只能作廢。這是已知代價不是待修項目。

H 排序建議依「解鎖多少後續工作」排

A1（特效 R12 拍板）解鎖最多。 它不只卡特效升級，還卡住整條線的估時 —— 不答就連「要花多久」都算不出來。而且這題是純決策，你答完就能動。
A2＋A3 解鎖 Unity 端 5–8 人日。 兩個都是選項題，答完 B2 立刻能開工。
板子採購與 UniWebView 越早越好。 這是唯一不受決策速度影響的硬性等待，而且卡住兩件事。板子到手第一件事是 WebGL2 自檢 —— 那是開關性的，比任何 FPS 數字都優先。
G1 半天做完，成本最低風險最高。 不需要任何決策，我隨時可以做。

B1（Web 橋接層＋mock）是最值得先開的實作項 —— 它是唯一既不等決策、也不等板子的串接工作，而且 mock 做完之後，Web 端可以在完全沒有板子的情況下繼續往前跑。