Regmark05
首期路线图
12 周，六个阶段。每个阶段结束时都有一样能单独拿出来用的东西，以及一条可以检验的验收标准。
前提
这份排期建立在三个假设上，哪个不成立，日期就要跟着变。
- 一个人主力开发，每周投入 15 到 20 小时，有编程助手辅助。
- 从 2026 年 10 月 12 日（周一）起算。
- 首期只支持 WooCommerce 和 Shopify 两个平台、UCP 一种协议。
时间线
各阶段的交付与验收
阶段零：地基（第 1 周，10 月 12 日至 18 日）
交付
- 仓库、许可证、贡献说明、CI 骨架。
- 事实表的类型定义第一版，写成一份设计记录公开征求意见。
- 错版店和对照店的最小版本：5 件商品，提供商品页、JSON-LD 和 feed 三个出口。
- 定名：查商标，确定包名和仓库地址。
验收：两家样板店能在本地一条命令启动，CI 里能访问到。
阶段一：只读套准（第 2 至 4 周，10 月 19 日至 11 月 8 日）
交付
- 商品页采集器和 Google 格式 feed 采集器。
- 身份对齐。
- 九条只需要读就能判断的规则：价格、币种、促销过期、库存、变体缺失、标识符、退货政策。
- 命令行
regmark audit，终端摘要和 JSON 输出，退出码。
验收
- 错版店里预置的只读类缺陷，查出至少九成。
- 对照店零误报。
- 对一家真实的、得到店主同意的店铺跑通，50 件商品在 3 分钟内出结果。
这一阶段结束时，工具已经能回答「JSON-LD、feed 和页面是不是同一个价」，可以先小范围给人试用。
阶段二：结账基准与 CI（第 5 至 7 周，11 月 9 日至 29 日）
交付
- WooCommerce 和 Shopify 的结账探针，以及归属验证。
- 依赖结账的规则：运费不一致、运费未披露、变体买不了、含税口径。
- 内容卫生的四条规则。
- HTML 报告、SARIF、JUnit 输出。
- GitHub Action，以及预算机制。
验收
- 在一家 WooCommerce 演示店上，从提交代码到合并请求里出现检查结果，全程自动。
- 结账探针跑完后，店里不留下任何购物车或订单。
- 错版店的全部预置缺陷，查出至少九成；对照店仍然零误报。
这是首期最重要的一个阶段。它做完，Regmark 才和只看单个出口的工具真正拉开差别。
阶段三：协议出口（第 8 至 9 周，11 月 30 日至 12 月 13 日）
交付
- UCP 采集器：发现文件、目录检索、结账会话。
- 协议符合性的薄包装，规范版本钉死，并写明支持哪几版。
- 错版店加上 UCP 端点和对应的缺陷。
验收
- 对一家 Shopify 开发店，把 UCP 目录返回的价格和库存，与 Storefront API 结账实算的结果逐项比对。
- UCP 规范出新版时，升级只需要改采集器这一个包。用一次真实的版本升级，或者一次模拟的升级来验证。
阶段四：探店代理（第 10 至 11 周，12 月 14 日至 27 日）
交付
- 任务格式和从事实表自动出题。
- 代理循环，两种走法：读商品页，调用 UCP 或 MCP 的工具。
- 录制与重放。
- 成功率和花费的报告。
验收
- 在错版店上自动生成 20 个任务，用三个不同的模型各跑三遍。
- 重放的结果逐字节一致。
- 每个任务的平均花费写进报告，并且有上限保护。
这一阶段标为预览版，接口不保证稳定。
阶段五：发布 v0.1（第 12 周，12 月 28 日至 2027 年 1 月 3 日）
交付
- 中英文文档，放在这个站点上。
- 三份真实店铺的示例报告，经店主同意公开。
- 一篇说明文章：做了什么，没做什么，接下来做什么。
- 发布到 npm 和 GitHub。
验收：一个没接触过这个项目的开发者，照着文档，10 分钟内对自己的店跑出第一份报告。
首期做与不做
| 做 | 不做，留到之后 |
|---|---|
| 商品页、Google feed、UCP、结账四类出口 | ACP 端点、OpenAI 商品 feed |
| WooCommerce、Shopify | Magento、Medusa、Saleor、Vendure |
| 13 条套准规则，4 条内容卫生规则 | 用模型做内容判定，商品属性的语义比对 |
| 命令行、GitHub Action、五种报告格式 | 网页界面，托管服务 |
| 探店代理预览版 | 多代理对比，购物任务的公开基准 |
| 单次运行 | 定时巡检、漂移时间线、告警 |
| 指出问题在哪 | 给出平台相关的修法 |
来不及的时候先砍什么
顺序是定好的，免得到时候再争：
- 探店代理整体推到 v0.2。套准和结账基准才是核心，代理是锦上添花。
- Shopify 的结账探针推后，首期只留 WooCommerce。Shopify 商家有平台兜底，没有那么急。
- JUnit 和 SARIF 推后，只留 JSON 和 HTML。
反过来，下面三样不能砍，砍了就不值得发布：结账探针、对照店零误报、预算机制。
v0.1 之后
按现在的判断排的顺序，发布后会根据反馈调整。
- 巡检与漂移。 定时跑，存历史，变坏时通知。这是从「发版时用一次」变成「一直开着」的关键。
- 更多平台。 Magento 和 Medusa 优先，采集器的接口在首期就按「别人能写」来设计。
- ACP 和 OpenAI 商品 feed。 看那时候它的走向再定投入多少。
- 修复建议。 从 WooCommerce 开始，因为它的问题最集中，修法也最固定。
- 把 Regmark 自己做成 MCP 服务。 让编程代理在改主题、改插件的时候能自己调用检查。
风险
| 风险 | 可能性 | 对策 |
|---|---|---|
| 协议继续大改，甚至某一个被放弃 | 高 | 协议只存在于采集器里。核心是事实表和规则，不随协议变 |
| 平台自己做了同样的检查 | 中 | 平台只会检查自己那一段。Regmark 的位置是跨平台、跨出口、能放进 CI，而且开源 |
| 代理购物的普及比预期慢 | 中 | 价格和库存对不上，对 AI 搜索的答案和 Google Merchant Center 同样有害。工具的价值不绑在代理结账上 |
| 误报多，被人从 CI 里摘掉 | 中 | 时间窗、二次确认、容差、预算四道措施，加上对照店零误报作为发布门槛 |
| 结账探针被拿去骚扰别人的店 | 低 | 归属验证，默认限速，不提供绕过的开关 |
| 模型调用的成本和随机性 | 中 | 重放不花钱，实跑有上限，用户自带密钥，支持本地模型 |
| 一个人维护不过来 | 高 | 首期范围收窄。规则和采集器是两个低门槛的贡献入口，首期就把接口和文档写好 |
| 同方向的项目先做出来 | 中 | 已经有几个很小的尝试。差别在于以结账为基准，这一点要在阶段二尽早做出来给人看 |
怎么算做成了
首期不看星标数。看这四条：
- 错版店的预置缺陷，查出至少九成。
- 对照店零误报。
- 新用户从安装到第一份报告，不超过 10 分钟。
- 至少三家真实店铺把它接进了自己的 CI，并且愿意公开说。
最后一条最难，也最说明问题。