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 和版本化决定吸收真实分歧，而不是收集无法核验的支持口号。