看代點餐的舊版說明，代理管理員（ProxyAdmin）只能替人訂台北當日的餐，卻可以略過一般截止時間。再看後續版本，規則變成當日與未來合格開團日期都能代點，但仍受截止時間限制。

兩份文字不能同時拿來當今天的驗收標準，卻都應保留在各自的歷史位置。這個差異可從 v0.14.0 與 v0.15.4 的 Changelog 及對應修改查到。

版本時間線的價值，是讓行為有有效範圍：哪些規則曾經成立，哪一版改了它，以及排查問題時應該對照哪個狀態。

只看最後程式碼，看不到規則怎麼改過

這段演進不是單純加寬權限。v0.14.0 的日期範圍較窄、截止例外較寬；v0.15.4 擴大日期範圍，取消早期例外，重新受一般截止約束。若只摘要成「ProxyAdmin 權限放寬」，會漏掉另一半。

早期代點 commit 與 後續調整 commit 提供了可以回頭對照的界線。排查時先問版本，就能避免拿舊政策去判斷新行為是 bug。

Day 21 已說明完整使用流程，這裡不重教權限規則；新增的判斷是：同一個功能名稱可以跨版本保留，裡面的業務契約卻已經變了。

v0.14.x 到 v0.15.x 留下的是產品變化

這條時間線可選幾個有代表性的節點閱讀，不必把每個 commit 都搬進文章：

這是可查證的功能與修正順序，不代表每一筆 patch 都由一場正式事故引起。Changelog 沒有記錄的使用者回報、事故時間或修復工時，不能靠版本號補成故事。

例如 v0.15.3 提到「2026-09-21 菜單」的識別修正，相關 commit 在 9 月 17 日已存在。9/21 是該筆菜單／訂餐目標日期，不能直接當成事故發生日。v0.15.3 commit

時間線還接到了使用者看見的版本

這個 repo 沒有讓頁尾版本完全手填。src/data/changelog.js 讀取 Markdown Changelog，取第一個正式版本作 APP_VERSION，沒有正式版本時才退回 package.json；畫面歷程排除 Unreleased，並提供繁體中文說明。Changelog 資料入口

App.jsx 的頁尾顯示 v{APP_VERSION}，可開啟更新歷程。這使內部版本紀錄與使用者看見的標記有一條明確連線，減少「說的是哪一版」只能靠記憶回答的情況。頁尾實作

但這仍是來源程式的證據。本次核對的 source 版本是 v0.15.7，沒有因此確認目前正式環境一定執行這一版。

Commit、版本紀錄和部署證據要能接上，不能互相代替

Git commit 能定位修改；Changelog 把修改翻成產品行為；部署紀錄才回答哪個環境何時用了那個版本。

本文核對了前兩者。GitHub Releases 查詢沒有返回條目，也沒有逐版部署資料，所以這裡的 Release 指產品版本概念，不能宣稱每個版本都有 GitHub Release、tag 或已核實的上線時間。

實際處理線上問題時，還要把使用者看到的版本、部署的 commit 與發生問題的環境接起來。若中間缺一段，就保留缺口；不要從「Changelog 有寫」推論「正式環境已經有」。

AI 摘要 Diff 時，最容易壓掉的是限制

把修改檔案列成清單很容易，保留政策差異較難。代點這個例子至少要留下「可用日期擴大」與「截止限制仍在」兩件事，否則一段流暢摘要反而會誤導驗收。

我會把版本說明核對到三個問題：

• 使用者能觀察到什麼變化？
• 哪條權限、資料或相容規則改了，哪些仍保留？
• 目前證據只到 source，還是已連到特定環境的部署？

版本號本身不會提高可靠性。它有用的條件，是下一次出問題時，人能從它找到當時的行為與尚未確認的部分。

本系列實作專案

這是一套持續開發中的便當訂購系統。文章著重「為什麼」，GitHub 保留實際程式碼、文件與演進紀錄。

GitHub：https://github.com/henryfir456/bento-order-app

接下來會回頭看技術選擇：GAS 曾替第一版解決哪些問題，而當責任改變後，Workers 與 D1 又承接了什麼代價？