#推进跨领域改动

当前端体验、业务规则和 API 契约同时变化时，关键不是加载更多 Skill，而是先冻结共享边界和消费者。

#你将完成什么

• 把一个跨领域需求拆成清晰的职责和共享契约。
• 识别前端、后端、CLI 或配置消费者。
• 设计可以分批验证、可回滚的实施顺序。

#前置条件

准备用户场景、现有接口或数据模型、兼容要求和发布约束。跨仓库时要明确每个仓库的 owner 和验证方式。

#发送这条请求

为订单列表增加“部分退款状态”。请先梳理用户体验、领域状态、API/Schema、旧客户端兼容和迁移边界；给出消费者矩阵、技术方案与分批验证计划，确认前不要修改。

#预期工作流

任务进入 dev，并只在真实需要时路由前端、领域架构、API 契约或数据相关 Skill。先确认需求，再确认模块职责、契约和验证计划；共享契约应先于各端实现冻结。

#写入边界与确认

CP1 确认用户结果与范围，CP2 确认架构、契约和迁移策略；多模块、公共 API 或高风险任务再用 CP3 确认批次、回滚与 TestRoute。任何新增消费者都要回到影响矩阵，而不是在实施中静默扩展。

#可见结果

你应得到：

• 消费者和兼容矩阵；
• 模块职责与共享契约；
• 数据/状态迁移和失败恢复；
• 串行或并行的实施边界；
• 每一批的验证证据与停止条件。

#如果各模块开始互相等待

• 先确认共享字段、错误语义和版本策略是否真的冻结。
• 将无法独立验证的批次改为串行，不用并发掩盖依赖。
• 若需要改变已确认的公共契约，回到方案确认点。

#下一步

查看 dev 工作流和工作流总览，然后用带证据交付与续接收口。