WooCommerce 如何在自己的網域發布 /sku.md
v1.0.0 專題
從 WooCommerce Store API 證據到 WordPress 路由、人工審核、原子發布、監測和回滾的完整流程。
目前狀態： 本文依據目前 v1.0.0-beta 邊界撰寫，只陳述方法和證據要求，不把尚未驗證的平台採用、排名、引用、推薦或銷售結果寫成事實。
WooCommerce 架在 WordPress 上，因此店主通常比全託管平台擁有更多路由控制權。但只有生成、審核、發布、監測和回滾形成一條可追責流程時，這種控制才真正有價值。
目前狀態與證據條件
公開 WooCommerce PoC 尚未標記完成。Store API 和 WordPress 路由 API 提供了實作基礎，形成支援結論仍要求一套他人可以驗證的公開安裝。證據出現前，下面描述的是目標流程，不是已經完成的整合結果。
把商店證據轉成草稿
從受鑑權和範圍限制的商店資料來源讀取商品與變體，只對應含義明確的欄位：規範商品 URL、標題、已審核描述、尺寸、屬性、變體識別碼和來源連結。不能從缺失屬性推斷限制，也不能把目前庫存和價格複製進靜態知識。
生成結果必須保留來源。每個輸出項都要能追溯到 WooCommerce 欄位或編輯來源，發生衝突時交給人工審核。
註冊公開 WordPress 路由
外掛可以為 /sku.md 註冊 rewrite rule 或 REST endpoint，並返回 UTF-8 Markdown 與允許的媒體類型。主題、快取外掛、安全中介軟體或其他外掛都可能攔截同一路徑，因此路由所有權必須明確。
只在啟用或設定變化確有需要時重新整理 rewrite rules。以未登入存取者身分確認路由，並記錄重新導向、快取回應頭和最終位元組。
人工審核必須位於發布之前
編輯應先在暫存狀態審核目錄和抽樣商品文件，重點檢查變體身分、無依據陳述、缺失限制、薄弱來源和意外出現的即時商業欄位。Parser 能檢查語法，卻無法判斷適用性陳述是否誠實。
驗證通過後再原子發布，避免消費者讀到半寫入檔案，並保留上一個有效版本用於回滾。
更新與失效循環
已審核事實、識別碼或來源頁面改變時生成新草稿。庫存和價格事件不應觸發 SKU.md 重建，因為它們不屬於知識邊界。持續監測公開路由、Validator 結果、來源可達性和上次批准時間。
如果新草稿驗證失敗，繼續提供上一個有效版本，並把失敗草稿交給編輯。刪除商品時先更新目錄，再有計劃地退役對應文件。
PoC 驗收記錄
| 階段 | 必須保留的證據 |
|---|---|
| 對應 | 輸入欄位、輸出陳述、來源關係 |
| 審核 | 審核者、修改和未決問題 |
| 發布 | 公開 URL、狀態、回應頭、內容雜湊 |
| 驗證 | 工具版本與結果 |
| 更新 | 觸發原因和替換時間 |
| 回滾 | 恢復版本與原因 |
證據條件
只有外掛流程在公開測試商店執行、記錄路由衝突和快取行為、成功傳播一次變更，並阻止故意無效的草稿覆蓋有效資源後，才能把該流程報告為已驗證。其他人應當無需接觸開發者電腦即可重現結果。
先做欄位對應，再生成 Markdown
不要直接序列化整個 WooCommerce 商品物件。商品名、描述、屬性、分類和 Variation 識別碼可來自 WooCommerce；Guidance、Limitations、Compatibility 和 Source 往往需要編輯欄位。每條對應關係要說明適用於 ProductGroup 還是具體 Variant；缺少商家 SKU 時，不能暗中用資料庫 ID、GTIN 或 slug 代替。
生成器只輸出待審核候選稿。後台備註必須清除，即時價格、庫存、優惠券、運費、支付和訂單必須排除，Source 要解析到公開自訂網域。外掛可註冊 WordPress rewrite 或 REST route 提供 /sku.md，但最終以公開回應為準。
驗證路由、快取和文件圖
在乾淨安裝中測試固定連結、快取外掛、多語言外掛、安全中介軟體和普通主題。儲存狀態、重新導向、最終 URL、Content-Type、快取策略、正文雜湊和生成版本，再驗證 Catalog 與所有商品文件。瀏覽器能開啟並不夠，因為它可能渲染了自動消費者應拒絕的 HTML 回退頁。
生成和批准必須分開：商品變化產生 diff，編輯審核後原子發布，上一版本可回滾。只改庫存不應重寫穩定知識，材質、相容性或限制變化才觸發更新。WooCommerce 支援結論需要公開測試店、重現步驟、路由與驗證證據、更新和回滾演示。
失敗時繼續提供最後一份完整版本
生成可能因無效商品、Source 不可存取或外掛鉤子異常而中斷。新目錄應先寫入暫存位置，完整驗證文件圖後再一次切換；失敗時繼續提供上一批准版本並顯示管理診斷。不能讓新 Catalog 指向舊商品文件，也不能把半成品以成功狀態公開。切換後同步清快取，再從公開網域請求並核對雜湊。
外掛 MVP 應包含生成、編輯 diff、逐條來源、驗證、原子發布、回滾和公開驗證命令，並具備審批權限與後台轉義。驗收店應覆蓋簡單商品、Variations、缺少可選識別碼、故意衝突和無效來源，明確哪些阻止、警告或允許發布。
發布後如何驗證與回滾
上線後應從公網重新請求 /sku.md，檢查狀態碼、MIME 類型、重新導向鏈和最終位元組，並儲存驗證時間與外掛版本。更新商品資料時先生成候選檔案、完成審核，再以原子方式替換公開版本；如果路由或內容驗證失敗，應恢復上一份已驗證檔案。這樣可以避免使用者在更新過程中讀到半份文件，也讓故障能夠按版本定位。