跳轉到

D-20260811-17｜專案生命週期與首次公開發布鏈

背景與驅動力

首次公開規則分散於 GLB 交接、主站 origin、文檔站 origin、Ledger genesis 與多筆 deferred deployment issue。早期敘述把美術、GLB 與測試壓成單線工序，也有現行文件省略 public specs → private main source baseline → service templates 的中間依賴。另一方面，specs、 docs 與三個 service template 會早於主 client 公開；若只用「public／private」描述專案階段，會把 公開說明面誤當成正式 runtime 相容基線。

專案也需要一套上線後仍可使用的規範：內部重構不應一律背負相容層，但 persistent、wire、共識、 資產或公開 API 已有使用者後，不能再沿用 pre-launch 的直接破壞方式；production rollback、經濟 重算與鏈重生也不代表回到開發期。

考慮過的選項

  • 保留既有線性發布清單，只以人工理解重疊：文字最少，但無法判斷某次重製使哪些證據失效，棄。
  • Repo 一公開就視為 live：規則簡單，卻會讓先行公開的 specs、docs 與 template 過早凍結 runtime 契約，棄。
  • 分離 repo visibility、candidate maturity、runtime phase 與 live operating mode，並以可驗 gate 串起首次公開（採納）。

決定

  • 狀態分為四軸：repo local/private/public、candidate iterating/asset_ready/release_candidate、runtime pre_launch/live、live 作業 normal/emergency。公開相容義務直接由 runtime_phase == live 推導，不另設可能漂移的 public_contract_freeze 布林值。
  • 美術方向、Editor 正式匯出 GLB、資產／物理／效能驗證、E2E／playtest 與調整可交錯反覆；同一 candidate 先過 Asset-ready，再以 main source、specs、builtin manifest digest、GLB bytes／CID、 自動測試與人工驗收的同一 subject 通過 Pre-launch baseline。內部候選使用 prepub-rcN 或 candidate_epoch，不製造未公開 builtin v2、v3。
  • 發布順序固定為：公開 specs 並同批啟用 docs → main source baseline → pinning → signaling → turn → Ledger genesis／receipt／不同 identity replica → main release public → final main remote provenance → open4wd.org activation → workflow public。
  • open-4wd-specs public 與 docs.open4wd.org 上線是同一批次。Docs 可索引、分享、介紹與教學， 但固定顯示 pre-launch 狀態，不承載 PWA、Ledger、玩家身分或 origin-bound 遊戲資料，故不觸發 live。D-20260725-02 的「第一個公開 production origin」主詞是 main client runtime；先行公開的 獨立 docs origin 不構成主站遷移。
  • Main 鎖定 public specs SHA 並通過跨 repo CI 後形成 main_source_baseline_sha，供 pinning／signaling vendoring。Genesis receipt、exact address、governance signers 與最終 release metadata 加入後形成 main_release_sha。Source baseline 後若改到 vendored path，先前 provenance 失效，必須重跑同步與周邊發布。
  • open-4wd repo 成功轉 public 是 pre_launch → live 的不可逆觸發事件；branch protection、final remote provenance、Pages 與 production smoke 緊接處理。若外部 visibility 已 public 而狀態紀錄 落後，一律採較保守的 live 規則。
  • Candidate 與逐項驗證證據留在 open-4wd-workflow；specs 保存政策、粗粒度里程碑與現行 runtime phase。純狀態／歷史更新不改產品契約，不要求 main 重鎖 specs；dependency lock 仍代表該 build 實際驗證的 immutable 契約快照。
  • Live 後純內部實作仍可重構；改到 persistent、wire、共識、資產或公開 API 時須依既有版本規範 提供版本區隔、遷移、重算、dual-read 或明確拒絕舊資料策略。一般 rollback 以新版本回復舊內容； 參數回設、derive 重算與鏈重生都在 live emergency 內完成，不把階段倒退回 pre-launch。

後果與影響

首次公開的重疊工作有了可判定 gate，repo 先行公開不再和 runtime 相容階段混為一談；docs 可提早 服務閱讀、介紹與教學，而 main 仍保留完整 pre-launch 重構自由。代價是 release evidence 必須綁定 同一 candidate subject，且 main source baseline 後的 vendored-path 修復會使周邊 provenance 重跑。

現況與完整 gate 見 專案生命週期.md。本決策不授權 push、visibility、Pages、 DNS、Ledger genesis 或 runtime 部署；那些外部動作仍由各 deferred deployment issue 與使用者授權 逐步執行。