ORCHESTRATE平台3轮冲刺：23个工单0卡壳

从1708到1895个测试用例，22到29个服务模块，4个数据库迁移脚本——这组数字不是KPI汇报，而是一个内容管道从"能跑"到"敢上生产"的体检报告。Sprint 3的任务很直白：把前三个 sprint 攒下的家底，拉到真实环境里遛一遛。

结果：7个Sprint 2的遗留决策全部落地，0个工单被block，连续第三个 sprint 实现100%决策跟进。

为什么"生产验证"成了最高优先级

团队给Sprint 3定调时，有个判断后来被反复验证：单元测试通过不等于能干活。OAS-099这个story专门造了"真实饲料夹具"（realistic feed fixtures）——简单说，就是不再用假数据自欺欺人，直接把生产环境的脏数据、边缘格式、异常时序搬进测试场。

这招立竿见影。3个在单元测试里完美隐身的问题被揪了出来：一个时区处理漏洞、一个并发写入冲突、一个信任分数传播断层。最后一个尤其典型——溯源服务（provenance）算出的分数，在传给质量评估模块时丢了精度，单元测试各自为政根本发现不了。

「每个功能史诗至少需要一个跨服务集成测试」，这是Sprint 3 retrospective的D1决策。不是建议，是硬性标准。

配置即政策：把"改代码上线"变成"改配置生效"

Sprint 2有人吐槽：调个重试间隔要重新部署？Sprint 3的OAS-100用Zod模式（schema validation）统一了配置层，把重试逻辑、退避参数、迁移开关全做成了热更新。现在运营同学可以在admin面板里调阈值，工程师专注写代码。

这个模式被命名为"配置驱动政策"（configuration-driven policy）。D3决策要求把它扩展到所有V3可调参数——意思是以后产品想试不同策略，不用排队等发版。

Content Envelope（OAS-098）是另一个容易被低估的改动。它强制所有适配器输出统一格式的"信封"结构，里面包着原始内容、溯源元数据、处理日志。以前每个数据源自己造轮子，现在接入成本从"读文档+写转换"变成"填模板"。

原子版本链：当一条内容被改了17次

OAS-101解决的是个经典难题：同一篇文章被多次抓取、清洗、人工修正，怎么知道哪版算数？Atom Versioning给每个内容原子建了版本链，配上信任阈值——机器抓的初始版信任分低，人工复核过的跳升，被标记为"争议"的降级。

这个设计直接来自Sprint 2的D4决策，又在Sprint 3的生产验证里接受了压力测试。SimHash索引（Sprint 2落地，Sprint 3加固）负责去重，版本链负责溯源，两者搭伙才算闭环。

团队 retro 时有个观察：决策会复利。Sprint 2的决定→Sprint 3的实现→Sprint 3的验证，三层叠加才让系统变硬。不是一次性搞个大新闻，是持续的小改进在滚雪球。

CI性能监控：60秒警报和SQLite历史库

OAS-102干了三件事：聚合健康端点（/health）、60秒慢构建警报、用SQLite存CI性能历史。前两个是面子，最后一个是里子——没有历史数据，"构建变慢了"就是个体感问题，有数据才能定位是哪次提交搞的鬼。

异步NLI队列（OAS-103）上了信号量并发和优先级调度。NLI（自然语言推理）是内容质量判断的瓶颈环节，以前串行处理，现在可以按紧急程度插队。D7决策的实现让高优先级内容的端到端延迟从分钟级压到秒级。

11个AI persona参与DD TDD（文档驱动测试驱动开发）是Sprint 3的工程纪律。每个工单先写文档，再写测试，最后写实现——顺序不能乱，persona负责挑刺。Result模式（ADR-028）贯穿所有服务，错误处理从"抛异常"变成"显式传递"，调用链上下游都能感知失败原因。

测试文件从98个涨到116个，不是堆数量，是集成测试的占比在抬升。服务模块新增7个、修改6个，改动面不小，但零阻塞意味着依赖关系被理清楚了。

Sprint 4的容量要拆成两半：一边继续搞创新功能，一边加固稳定性。这个分配本身说明团队心态变了——前三个 sprint 是"把东西做出来"，接下来是"让东西死不了"。

这篇 retro 文章自带溯源链ID：prov-sprint3-retro。每个主张都能追到具体测试证据，算是给自己写的系统打了个样。如果你负责的内容平台还在用"上线后观察"代替"上线前验证"，他们的测试用例增长曲线或许值得看一眼——1895不是终点，是连续三个 sprint 100%决策跟进后的中间状态。