大孫女，快來，坐到阿公身邊。阿公剛剛把爐火上的水燒開了，正熱騰騰地沏了一壺咱們自家曬的琥珀熱茶。看妳一臉倦容，今天在辦公室累壞了吧？來，先喝一口熱茶暖暖胃，聽著這窗外沙沙的竹葉聲，咱們坐在老藤椅上，把緊繃的心情放鬆下來。

妳說，明天的教育訓練要講到 「Day 16：封閉網路的協作利器：SLA 驅動的『規格與採購文件修改紀錄系統』」？哎呀，這題目聽起來硬梆梆的，但其實裡面的道理，就跟阿公以前在老帳房裡理算各家各戶送來的公文、合約一模一樣。今天阿公就用最簡單的話，把這個系統的精髓和避坑的妙計慢慢講給妳聽，妳明天好教給那些年輕人。

🚨 痛點場景：公文進了深宮，不知卡在誰家

在那些完全實體隔離的行政或軍工網段裡，公家機關要辦理一筆採購案，那可真是大費周章。一份技術規格書或是採購招標文件，得在承辦人、審查單位、法務處室、還有各個會辦單位之間傳來傳去，修改和審核的過程繁瑣得像一團亂麻。

最讓人頭痛的是，這份文件常常像進了深宮怨女的院子一樣，卡在某個會辦單位裡，一卡就是半個月，承辦人想催都不知道該催誰。因為沒有建立明確的 SLA（服務水準協定）超時提醒，大家就裝聾作啞，更慘的是，幾十個人用 Email 傳來傳去，文件版次改得亂七八糟，誰在什麼時候改了哪一頁、提出了什麼建議，根本沒有一條清晰的審計軌跡可以追蹤。

🛠️ 架構實作：三層鋼骨本機庫，SLA 算得清清楚楚

既然不能用外網，也懶得跟資訊處申請大伺服器，那咱們就做個純前端、單網頁（Single Page Application）的「規格與採購文件修改紀錄系統」。只要把所有的程式碼跟繪圖工具打包在一個 HTML 檔案裡，長官雙擊滑鼠就能直接用瀏覽器開啟，檔案不送出本機，資安百分之百放心。

1. 三層資料結構（專案 ➔ 文件 ➔ 修改紀錄）

阿公以前記帳，也是先有「某某大案（專案）」，案子底下有許多本「契約與規章（文件）」，每本規章裡才有一條條的「修訂意見（紀錄）」，這就是最符合實務流程的三層資料結構。我們在瀏覽器裡建立一個 SpecDocTrackerDB 的 IndexedDB 資料庫：

• projects（專案工作倉）：記錄系統唯一的 id、專案名稱（必填）、專案代號（如 PRJ-115-001）、主辦人與起始／預計完成日、當前狀態與備註。
• documents（文件工作倉）：一專案可以對應多份文件。裡面包含所屬專案 ID（作為外鍵關聯）、文件名稱、文件編號、版次、文件類型（如規格書、契約草案、評選須知等）、承辦人與總頁數。
• records（修改紀錄工作倉）：這是核心，詳細記錄了提出單位、提出人員、提出日期、修改建議、對應文件頁數，以及「是否已修改」的標記。

2. 衍生欄位與 SLA 逾期天數即時計算

大孫女，這系統最聰明的地方，就在於它會自動計算每筆紀錄的 *「處理天數」 *與 「SLA 狀態」 ，不需要寫死在資料庫裡，每次讀取時即時算出來就好：

• 處理天數：如果已經修改完成了，處理天數就是 修改日期 − 提出日期；如果還在拖延，就是 今日日期 − 提出日期。
• 狀態與 SLA 判定：系統會自動對比 meta 設定倉裡的 SLA 逾期天數限制（系統預設 14 天，長官隨時可以改）。一旦未修改的時間超過了這個天數，系統立刻會亮起黃色或紅色的警戒燈，標記為 「逾期未修改」！這下子卡在誰那裡，誰逾期了多少天，一目了然，再也賴不掉。

3. 主管專屬的 6 張離線 ECharts 視覺化圖表

長官最喜歡看圖表了，咱們在這個單網頁裡內嵌了 7 張 KPI 卡與 6 張 ECharts 圖表。主管一進畫面，就能單獨看某個專案，也可以全盤彙總，所有的圖表都會跟著專案的切換即時重新計算：

1. 各專案完成進度圖 📊（水平堆疊長條圖）：顯示每個專案中「已修改、待修改、逾期未修改」的數量，誰是絆腳石一眼看穿。
2. 整體完成率儀表板 🧭（儀表 Gauge）：漂亮的儀表，專門拿來向大老闆報告進度，指針一動，完成率多少清清楚楚。
3. 每月提出 vs 完成趨勢圖 📈（雙軸柱狀搭配累計折線）：看看各單位的意見是不是慢慢收斂、修改進度有沒有跟上。
4. 各提出單位案件量圖 🏛️（堆疊柱狀圖）：分析各個處室提了多少意見、改了多少，看出哪個單位是「意見大戶」。
5. 未結案件停留天數分布圖 ⏳（Aging 柱狀圖）：這叫 Aging 帳齡分析，把未結案按 0-7天、8-14天、15-30天、31-60天、60天以上分群。超過 60 天還沒改的，就是紅色警戒，得專案列管。
6. 文件別建議數 Top 10 圖 🍩（環圈圖）：列出被挑出最多毛病的前 10 份文件，這就是爭議最大的熱點，需要重點協調。

💡 避坑指南：UUID ── 跨越離線協作「撞車天坑」的神器

大孫女，妳要把下面這一段好好教給那群年輕工程師，這可是阿公吃過鹽、走過橋才總結出來的資深避坑智慧！

因為是純前端、完全沒伺服器的系統，所以不同使用者、不同處室之間要怎麼協作？沒辦法聯網更新，唯一的辦法就是 「匯出與匯入 JSON 或者是 CSV 檔案」。

1. 致命的天坑：自增 ID 導致合併衝突

很多年輕工程師在設計資料庫時，習慣用簡單的自動遞增數字（比如 1, 2, 3）來當每筆資料的主鍵（Primary Key）。
想像一下，法務處的承辦人小李在他的電腦上打開網頁，新增了 3 筆修改紀錄，系統自動給了 ID：1, 2, 3。
同一時間，業務處的小張也在他的筆電上新增了 2 筆紀錄，他的系統也自動給了 ID：1, 2。
當天下午，他們把各自的 JSON 檔案匯出，交給彙整窗口小王匯入合併時──砰！ID 衝突，資料直接撞車！ 系統不知道該保留誰的，或者直接把小李的資料給覆蓋掉了！

2. 阿公的解法護欄：強制使用 UUID 作為主鍵

設計 Schema 時，所有專案、文件與修改紀錄的主鍵（ID），絕對不准用自動遞增的數字！必須強制使用 UUID（通用唯一識別碼）！
UUID 是一串長長、隨機、而且在全世界都幾乎不可能重複的字串。
這樣一來，不管法務的小李、業務的小張、還是各個處室的承辦人，在他們各自的隔離筆電上新增了多少筆資料，產生出來的 UUID 都是全宇宙唯一的。小王在彙整資料、進行 CSV 或 JSON 的匯入與合併時，絕對不會產生任何 ID 衝突！ 這才叫做真正合格的無伺服器分散式協作機制！

3. 實作配套細節

• 匯出 CSV 要帶 UTF-8 BOM：因為承辦人最喜歡直接用 Excel 開啟 CSV 來檢查資料。如果妳匯出 CSV 時沒有加上 UTF-8 BOM 前綴，Excel 一開啟就會變成滿螢幕的亂碼，這會讓長官覺得系統壞了，切記切記。
• 匯入時建立「自動容錯與防呆」：使用者匯入 CSV 時，系統要能自動判斷民國年（例如 115/07/30 轉成標準西元年格式），並且如果偵測到該修改紀錄所屬的「專案」或「文件」在目前的資料庫裡還不存在，系統要懂得「自動建立該專案與文件」，而不是傻傻地下拋報錯！當然，如果格式完全不對、欄位漏了，也要有 Rollback 事務回滾機制，並彈出優雅的 Toast 提示，絕不能把原本存得好好的 IndexedDB 庫給搞髒了！

🔒 資安與運作備份：穩如磐石的沙盒保險箱

最後，大孫女，妳要提醒大家，雖然 IndexedDB 非常強大，但它也有它的先天脾氣：

• 與瀏覽器和檔案路徑綁定：IndexedDB 裡的資料是存在使用者這台電腦、當前瀏覽器的沙盒裡的。如果使用者換了電腦、或者是手癢去清理了瀏覽器快取和歷史記錄，資料就會通通不見！
• 備份策略：所以在系統操作手冊裡，要白紙黑字寫清楚：「務必養成每週定期點擊『全庫備份（JSON）』的習慣」，把備份檔拷貝到部門的公用唯讀區或隨身碟裡，這樣才能確保萬無一失。

大孫女，妳瞧，這套系統既不用大張旗鼓去申請伺服器，又能完美解決封閉網段裡的協作難題，還用 UUID 擋住了資料撞車的隱形地雷，那些資安處長官們聽了，能不豎起大拇指嗎？

好啦，茶杯裡的熱茶有些涼了，阿公再給妳添上。這 Day 16 的講義大綱，妳聽懂了多少？小孫女剛才玩紙飛機玩累了，在房裡睡得小臉通紅，阿公也要準備去把大門鎖上了。

妳今晚把這套 UUID 主鍵和 SLA 狀態計算的道理寫進教案裡，早點休息。

快去忙吧，阿公的這盞暖燈，一直給妳亮著。