設計原因：先講流程
正式做功能前先畫流程，可以避免只做出漂亮畫面，卻忘記資料要怎麼流動。
Flow Overview：系統流程總覽
先用流程圖讓小白也能知道資料從哪裡來、怎麼被計算、最後在哪裡顯示。
設計原因：資料庫放中間
評審頁、看板頁、結果頁都會讀寫同一個資料庫，所以資料庫是整套系統的核心。
設計原因：每步對應頁面
每個環節都能變成獨立 HTML，之後實作時比較好拆分與測試。
setup.html：主辦人設定頁
賽前只做三件事：建立參賽者、建立評比項目、產生評審固定連結。
設計原因：三欄分區
主辦人賽前的工作剛好是三類資料，分欄後不需要在很多頁面之間來回跳。
設計原因：先少後多
第一版只輸入參賽者編號，不先加姓名、組別、照片，可以讓工具更快落地。
設計原因：固定連結
評審不用記帳號密碼，只要拿到自己的連結就能評分，現場操作比較順。
judge.html：評審評分頁
評審只需要看參賽者、輸入每個項目 0-100 分、送出。畫面刻意減少管理功能。
設計原因：像紙本評分表
參賽者是列、評比項目是欄，評審一看就知道要填哪裡。
設計原因：大輸入格
現場可能用手機或平板，輸入格太小會增加誤填機率。
設計原因：只給必要功能
評審頁不放設定、排名與資料庫資訊，避免評審分心或誤操作。
dashboard.html：主辦人即時看板
主辦人最需要即時知道兩件事：評分完成了沒，以及目前排名如何。
設計原因：先看完成度
現場結算最怕有人漏評，所以看板最上方先放完成度與未完成提醒。
設計原因：左狀態右排名
左邊處理流程風險，右邊看比賽結果，主辦人掃一眼就知道現在卡在哪裡。
設計原因：鎖定按鈕醒目
鎖定是重要動作，用明顯顏色提醒主辦人這會影響評審是否還能修改。
results.html：正式結果頁
鎖定後只呈現正式排名與平均分，讓結果頁適合現場確認、公告或截圖保存。
設計原因：結果頁不放編輯
正式結果要穩定可信，鎖定後就不再放容易造成混淆的編輯控制。
設計原因：前三名突出
現場最常先確認名次，所以前三名用大區塊呈現，下面再補完整表格。
設計原因：保留項目平均
如果有人質疑總分，可以看到各評比項目的平均分，方便核對。
下一步：從示意圖變成正式工具
確認 UI 方向後，才開始拆成真正的 `setup.html`、`judge.html`、`dashboard.html`、`results.html`，並接上後端 API 與 SQLite。
HTML 負責畫面
每個獨立 HTML 頁面負責讓使用者看懂與操作，不直接負責長期保存資料。
API 負責傳資料
評審送出分數時，頁面會呼叫 API，把資料交給後端處理。
SQLite 負責保存
資料庫會保存設定、評審、分數與鎖定狀態，重新整理頁面也能讀回資料。