先看結論
呢條閉環真正證明的唔係單一網站上線，而係 private canonical bundle、review queue、publish queue、preview verification 同 publish receipt 已經可以形成可回放的流程。
為什麼值得關心
呢頁幫人睇清楚 private → public 閉環已經證明咗咩，亦清楚分隔已落地能力同後續公開接線。
核心模型
- 先凍結規格，之後再補 private publish hooks，避免 public repo 提前變成真相來源。
- canonical bundle、review queue 同 publish queue 分別承擔內容定稿、審核流同待發佈流轉責任。
- preview verification 同 publish receipt 令 public 狀態變更可以被驗證、回放同追責。
- 內容回顧節奏應該返回 control DB，而唔係散落在 thread 或人工記憶。
例子與常見誤解
- 使用：沿住規格 freeze -> private publish hooks -> preview verification -> receipt 呢條主線理解呢條閉環。
- 失效模式：preview 失敗時如果仍然標示為 published，就會破壞可追蹤的公開狀態信任。
- 使用：先睇規格說明，再睇 private publish flow，最後對照 build log 會最容易分辨已落地與 defer 範圍。
- 失效模式：如果將公開接線同規格變更混入同一波，repo boundary 會變得唔清楚。
相關頁面
更新與覆核
本頁已按現行編輯標準更新；內容重點、閱讀順序與更新說法已對齊。