SKU.md v1.0.0：給獨立站和 AI Agent 的開放商品知識契約
v1.0.0 專題
一份面向正式版準備的公開說明，涵蓋商品知識邊界、發現協議、識別碼、AST、工具、證據、已知限制和參與方式。
目前狀態： 本文依據目前 v1.0.0-beta 邊界撰寫，只陳述方法和證據要求，不把尚未驗證的平台採用、排名、引用、推薦或銷售結果寫成事實。
SKU.md v1.0.0 的目標，是把實驗性提案變成獨立站與商品知識消費者之間穩定、可實作的契約。本頁現已作為正式版準備說明公開，並不宣稱 v1.0.0 已經發布；所有材料和審核完成前，專案仍保持 v1.0.0-beta。
穩定版邊界
契約覆蓋描述性商品知識：目錄發現、商品身分、穩定事實、建議、限制、相容性、識別碼、來源和更新時間。即時價格、庫存、促銷、配送預計、稅費、支付、結帳和訂單狀態均被排除，相關問題必須明確交給即時商業系統。
穩定意味著相容 v1 的消費者可以依賴這一邊界，也可以依賴確定的解析行為。
發布格式與機器介面
Markdown 繼續作為商家發布格式，因為它可讀、可比較版本，也能作為普通 Web 資源部署。Normalized AST 是對齊 TypeScript、Python、CLI、Validator 和獨立實作的 Parser 契約。JSON 可以序列化 AST，但不是另一種商家發布格式。
發現仍優先 /sku.md；只有最終規範和 Conformance Suite 接受時，才使用正式的宣告式備用演算法。
正式發布需要哪些證據
發布記錄必須連結規範文本、遷移指南、Parser 與 SDK 版本、CLI、Conformance fixtures 和預期結果、安全模型、Reference Consumer、平台驗證報告及已知限制。每項材料都要有版本和可重複構建或測試說明。
還要證明 Beta 範例遷移時沒有靜默語義變化，並且獨立實作能夠在規範化輸出和診斷上達成一致。
已知限制必須進入發布說明
某些平台路由可能需要相容發現；消費者遍歷預算可能產生不完整結果，但不能因此判定商家目錄無效；多語言回退、未來商業擴充和參考價格提案也可能繼續留在 v1 之外。這些邊界應與功能列表同時出現。
正式版不承諾模型採用、搜尋排名、引用、推薦、轉換或銷售。
正式版準備檢查表
| 範圍 | 必需證據 |
|---|---|
| 規範 | 凍結的規範文本與已解決 RFC 決定 |
| 實作 | 有版本的 SDK、CLI、Validator、Normalized AST |
| 一致性 | 公開 fixtures、預期結果、跨語言實作一致 |
| 遷移 | Beta 到 v1 指南和已測試範例 |
| 安全 | 威脅模型、抓取策略、資源預算 |
| 平台 | 帶公開證明與限制的平台報告 |
| 治理 | 貢獻、版本、勘誤和變更流程 |
正式發布當天要替換什麼
把未來時態替換成已驗證事實；正式版發布時使用實際穩定版發布日期；連結不可變材料，並在適當位置列出驗證值或 Release Tag。只有連結證據存在後才能刪除佔位狀態。八種語言必須描述相同完成狀態。
商家和實作者如何參與
商家可以發布小規模已審核目錄，並報告路由和寫作問題；工具作者可以執行 Conformance Kit，為實作分歧貢獻測試向量；研究者可以重現商品匹配 Benchmark。專案應把有記錄的失敗作為治理輸入，而不是誇大準備度。
穩定版發布條件
只有 G6 確認全部材料、測試、安全審核、遷移檢查和公開連結後，才能宣告 v1.0.0 穩定版。如果實際公開日期與計劃不同，本頁轉為正式 Release Note 時必須同步更新 pubDate。
穩定契約必須凍結的內容
正式版要固定描述性知識與即時商業狀態的邊界，明確發現、傳輸、語法、Identifiers、Source、Catalog 關係、錯誤、版本和擴充。價格、庫存、促銷、運費、稅費、結帳、支付和訂單繼續留在靜態契約之外。
獨立實作面對相同位元組，應得到相同 Normalized AST 或診斷。Markdown 是商家發布格式，AST 是 TypeScript、Python、CLI、Validator 和消費者的解析契約；JSON 可以序列化 AST，但不是第二發布格式。
證據、安全和遷移都屬於發布內容
需要規範、決策記錄、Conformance fixtures、SDK、CLI、參考消費者、beta 遷移指南和平台報告。安全覆蓋不可信內容、請求預算、重新導向、同源、憑證、私網、內容上限和提示注入。已知平台限制和推遲到後續 RFC 的事項必須公開。
宣告 v1.0.0 穩定版前要重跑實作矩陣、從正式產物安裝、檢查連結、重現平台報告並歸檔雜湊。完成後本文才能改成實際發布記錄，列出版本、變化、限制和參與方式。它不能承諾排名、引用、推薦、採用或銷售，只承諾可檢驗的版本化契約。
相容性要成為明確承諾
正式規範應說明哪些 beta 文件仍可讀取、哪些診斷變化、Producer 要修改什麼才能宣告 v1 合規。v1 解析器遇到未知大版本時不能默默按 v1 解釋，應報告不支援版本。Extensions 需要命名規則，避免私有欄位被誤當核心語義。
參與方式也應產生證據：商家貢獻商品 fixtures 和平台失敗案例，實作者提交輸入位元組與差異輸出，研究者重現 Benchmark。開放契約通過測試、Issue 和版本化決定吸收真實分歧，而不是收集無法核驗的支援口號。