为什么改
在此之前，多平台接入与目录证据、Yandex 数据摄取、以及统一的经营分析口径是分散推进的。这次事件的目标是把它们接到同一条链路上：让 Ozon 与 Yandex 共用同一份订单事实，而不是各自维护一套口径。
另一个动机是边界要写清楚。调度器相关的代码已经进入部署产物，但「代码已部署」和「已按计划在生产运行」是两件事。这次记录刻意把后者留白，避免把未启用的能力写成已完成的运行状态。
改了什么
改动集中在渠道接入、经营分析与 Yandex 平台适配这几块：控制台的渠道与洞察页面、分析库、渠道库、Yandex 平台适配层，以及服务端逻辑。
在数据侧，目录新增了外键约束，用来保护观测证据，同时不把任务行本身锁死——这条约束有对应的测试断言。渠道侧则做了一轮 RC 修正，覆盖店铺入驻相关的验收、时区、共享密钥与 PII 允许列表。
文档侧记录了两条部署：一条是 Yandex 调度器 V1 的代码部署与 P5 生产观测，另一条是 Yandex 分析主链路集成。两条部署都记录在概览文档中。
具体版本、提交、部署产物与摘要、测试数量、运行时状态，以及语料计数，见上方 facts。
- 版本
- 20260926-yandex-sched-add2ba4 / 20260926-yaxan-1771e0c
- 主发布提交
- 025b05e54469a5e8ab636915322cbe478f73131e
- 生产 provenance 提交
- 025b05e54469a5e8ab636915322cbe478f73131e
- 部署产物与摘要
- 20260926-yandex-sched-add2ba4（记录于 docs/00-overview/CURRENT_STATE.md）；20260926-yaxan-1771e0c（记录于 docs/00-overview/CURRENT_STATE.md）
- 测试数量
- 见提交 df4bb40802d4f0ee6af67d3bf7e09d74d39e7b5e 的目录外键断言
- 运行时状态
- 调度器代码已部署、未启用
- 截至当前仓库语料
- 8 篇笔记 / 24 个 variant（其中 1 篇仍未发布）
怎么验证的
验证分三层。第一层是提交本身：主发布提交与生产 provenance 提交指向同一个 SHA，说明记录与部署产物对得上。
第二层是测试：目录外键的改动带有断言，验证它保护观测证据的同时不会把任务行困住。
第三层是文档：两条部署各自有 release id 与记录日期，并落在概览文档里；架构文档单独描述了 Yandex 订单调度器 V1 的设计。
它不意味着什么
它不意味着调度器已经在生产按计划运行。代码进入部署产物，与调度器被启用、被排程、被观测到稳定运行，是不同层级的结论。
它也不意味着多平台接入已经收尾。这次事件把 Ozon 与 Yandex 的订单事实接到同一口径上，但接入范围、后续平台与运营流程的覆盖，不在这次证据之内。
它同样不意味着语料已经完整。截至当前仓库中仍有未发布的笔记，语料计数是写作时捕获的仓库状态，之后仓库增长不会改变这个数字的含义。