05-六包协商.md

结论：六包目前不能按“一次领包、闭环交付”直接下发。问题是黄金路径有无人负责的端点、契约冻结形成串行等待、验收把“现状诊断”和“发布合格”混在一起。按下面修订：保留六席，小冈承担集成发布控制单；把“契约、实现、验收”的等待条件改成可机器判定的交付物。

另一个必须纠正的口径：这六包最多能定义为“黄金路径闭环交付批次”。依据：材料没有覆盖全量开发的功能目录与完成矩阵；53 路由只是待盘点对象，不能证明整个平台功能都有人实现。若继续称“全量开发完成”，最终验收会失真。

以下新增路径均为建议交付路径，不是已确认存在的仓库文件。仓库结构、实际源码文件、环境地址、凭据获取方式，以及 WIP-207、WIP-255、L3、smoke26 的完整内容均为『材料未涉及』，不得当成执行者已知条件。

一、边界直接这样改

没有依据承诺这次重拆后仍能 T+12h 全部完成。材料没有代码现状、缺陷规模或工作量估算。重拆解决责任空洞，不等于消除了产能约束。

二、六包共同的领包前置条件

“一次性执行”应定义为：无需再次询问需求，但允许自动等待依赖、提交缺陷、责任人修复及复验。依据：261 的首轮深验发生在实现之后；若连修复回路都禁止，就无法保证最终闭环。

小冈在通知领包前，必须把下列信息写入统一执行清单；字段缺失的包不能标记为“可领”：

WIP-207、WIP-255 必须附固定版本内容或可访问引用；L3、smoke26 必须展开为实际规则和用例。仅引用编号不构成自含任务包，依据是执行者无法从当前材料确认其约束。

建议统一新增：

• docs/delivery/execution-manifest.yaml：执行环境、包归属、依赖、命令及交付版本。
• docs/contracts/：接口规范、状态机、权限矩阵、兼容与变更规则。
• docs/delivery/evidence/<candidate>/<package>/：候选版本对应证据；敏感凭据不得写入。
• docs/tools/：验收入口及校验器；具体程序源码仍归实际应用目录。

三、可直接替换的六包定义

WIP-256｜一号：C 端黄金路径真实化

范围：登录→浏览→下单→支付结果→订单列表/详情→取消及退款预览的前端闭环。已有登录、浏览、支付页也必须验证接真；缺页则补齐。五个指定页面及其 services 删除运行时 mock 和失败后假数据回退。

输入与文件：C 端实际页面、路由、services、鉴权与支付适配文件清单；259 的 C 端契约子集；258 的订单/支付能力；260 或既有服务的登录、商品能力。相关实际源码路径『材料未涉及』，由领包清单补齐。

交付及判据：

• 对本包固定 commit 执行 typecheck、构建和用例，全部成功；记录实际命令与退出码。
• 从真实登录产生会话，浏览种子商品，下单后通过真实 API 在列表和详情中读到同一订单。
• 支付成功以服务端已校验回调且持久化的状态为准；等待、失败、取消均有真实状态显示，前端不得自行置为已支付。
• 用独立订单分别验证允许取消、不允许取消及退款预览；预览金额来自服务端，不把预览当作退款完成。
• 验证过期会话、库存不足、请求超时、重复点击提交；重复提交不得产生重复订单。
• 生产及 staging 可达代码不存在 mock 引用或静默假数据兜底；测试夹具按显式目录规则排除扫描。
• 证据关联用户、商品、订单、请求标识及部署版本。

依据：原判据只“点通”，既覆盖不了登录/支付，也发现不了失败后展示假数据；“经小冈代应用”还会把源码正确误当成集成正确。

WIP-257｜二号：B/A 端前端运营闭环

范围：B 端订单列表、详情及处理、核销和两段核销；A 端登录、商品 CRUD 界面。账单若已有对应页面则接真；若没有，是否新增必须在领包清单中定死，不能执行中临时扩大范围。

输入与文件：B/A 页面、路由守卫、services、token 管理、商品表单等实际文件清单；259 的权限与核销契约；260 的 B/A API；各角色测试账号。

交付及判据：

• 两端分别 typecheck、构建通过。
• 登录成功取得有效会话；401 按已冻结契约处理刷新或重新登录，403 展示无权限；不存在无限重试。
• B 端能读取 C 端所建订单，并完成契约允许的商户处理；操作后 C 端可读到一致状态。
• 两段核销分别验证合法顺序、逆序拒绝、重复提交和非本商户订单拒绝。
• 商品创建、查询、修改、删除或契约规定的替代行为均由服务端持久化，刷新后仍一致。
• 关联订单的商品删除行为按冻结规则验证；禁止以按钮可点击作为 CRUD 成功证据。

依据：“401→token 流程”没有定义 token 如何获得及过期策略；“可操作”不能证明数据持久化、权限隔离和业务状态正确。两段核销具体业务含义『材料未涉及』，必须由 259 固化，不能由前端猜测。

WIP-258｜阿仁：订单、库存、支付及共享状态机核心

范围：创建订单、列表、详情、取消原因/取消、退款预览、订单状态机、支付发起及沙箱回调、支付异常恢复。订单领域规则和状态变更只有本包拥有；260 的商户接口调用本包领域能力。

输入与文件：订单/支付/库存模型、迁移、领域服务、路由、测试及 WIP-207 骨架实际文件；259 的订单/支付/状态机契约；数据库及支付沙箱配置。

交付及判据：

• 价格由服务端计算；金额单位与舍入规则明确。篡改客户端金额不得改变应付金额。
• 库存校验和占用/扣减具备原子性；并发抢最后一件时不得超卖；取消/过期释放按冻结规则执行。
• 同一主体与幂等键、相同请求返回同一业务结果；同键不同请求明确拒绝；并发重复请求不得重复创建。
• 列表、详情执行用户归属检查；其他用户不能读取或操作订单。
• 状态机逐项验证允许和禁止的转换；不得暴露可由普通客户端任意指定目标状态的通用写口。
• 沙箱回调走约定的真实性校验、金额/订单校验和持久化路径；重复、乱序、错误金额、无效校验信息不会造成重复或非法变更。
• 回调失败后的重试或补偿能够恢复订单一致状态，并验证数据库副作用只发生一次。
• 退款预览按订单状态及规则计算；是否包含实际退款执行『材料未涉及』，不得用预览接口冒充退款闭环。

依据：原“支付占位”不能证明支付链路；curl 成功也不能证明库存并发、回调幂等或状态机正确。真实生产支付资质与通道『材料未涉及』，本包通过只代表沙箱闭环通过。

WIP-259｜波波：可执行契约、归属矩阵与变更约束

范围：先发布黄金路径契约，再完成 53 路由域盘点。承担规范和归属决策，不吸收业务实现。

输入与文件：实际路由来源、现有接口/模型定义、WIP-207/WIP-255 固定版本；交付至 docs/contracts/ 和执行清单。

必须交付：

• 黄金路径“步骤→页面→operationId→实现包→验收用例”矩阵，不得存在未分配端点。
• 登录/鉴权、商品浏览与管理、订单、支付、商户处理、核销、账单等本批次接口的请求响应 schema、错误语义和权限。
• 订单/支付/两段核销状态图、金额与库存规则、幂等范围、并发行为、分页及 is_test 传播规则。
• 53 路由逐项标记：本批次实现、既有能力复验、后续批次；后续批次不能计入本次完成率。
• 契约校验命令和兼容规则；冻结后允许兼容补充，破坏性修改须同步契约、实现、消费者与用例后才能生成新候选版本。

判据：schema 合法、引用可解析、operation 唯一、黄金路径映射完整、责任无空白、状态机无缺失转移定义；发布版本与摘要。

依据：“覆盖全部端点+小冈审定”仍会漏字段、权限和状态语义，还引入无期限人工等待。小冈可监督审查，但不能作为未定义时限的技术解锁条件。

WIP-260｜小渔：数据种子及商户/管理服务适配

范围：seed_demo_data.py；商户订单查询、处理/核销接口和账单查询；管理登录接入及商品 CRUD API。C 端登录、商品浏览已有能力由本包核验并补接入缺口；从零建设身份体系是否必要『材料未涉及』，须在领包前查明，不能隐藏在“适配”两个字里。

边界：订单、核销引起的订单状态变化调用 258；账单仅实现已冻结的查询与读模型，不默认包含结算、提现和对账平台。

输入与文件：WIP-255 固定规格、种子及迁移目录、商户/管理路由与服务、既有鉴权模块、258 共享服务入口；所有实际路径写入清单。

交付及判据：

• 种子按模块执行，业务唯一键、依赖顺序、run_id 和 is_test 明确。
• 同一范围跑两遍，业务记录数量、唯一键及关键值一致，无重复关联；允许变化的时间字段显式列出。
• purge 仅清理指定测试范围及其关联数据；该范围残留为零，范围外测试数据和非测试数据不变；重复 purge 成功。
• 经订单、支付、核销派生的测试数据可追踪并按规则清理，不只标记初始商品。
• 商户和管理 API 验证未登录、角色不足、跨商户访问；核销复用核心状态机并通过并发重复提交验证。
• 商品 CRUD 和账单查询有实际持久化证据；账单口径、时间范围及金额规则与契约一致。
• 既有登录/浏览能力只有复验通过才算交付，不能用“原来已有”豁免。

依据：原“purge 清零”没有限定范围，既可能误删，也可能只删表面记录；“CRUD smoke 绿”无法覆盖核销这种有状态业务。补入管理后端是修复原草案责任空洞，因此必须取消其重复实现订单核心的负担。

WIP-261｜小齐：独立验收工具、现状基线及候选版本深验

范围：维护专用树 docs/tools 验收工具；提交当前版本基线；对最终集成候选版本执行完整黄金路径与反例验证。业务缺陷交回责任包修复，本包复验。

输入与文件：执行清单、冻结契约、smoke26 展开的用例、独立测试数据、候选版本 manifest 和环境健康探针。

双阶段判据：

• 基线完成：工具能正确运行和退出，报告记录通过、失败、阻塞、跳过及证据；应用现状允许失败。通过受控失败样例验证工具不会把失败报绿。
• 最终深验通过：固定候选版本的 typecheck、构建、契约检查、必跑 smoke 和黄金路径跨端用例全部通过；必跑用例没有跳过、阻塞或无证据通过。
• 同一订单贯通 C 端、后端、B 端及管理端；独立异常订单覆盖支付重试、取消、非法核销、权限越界等分支。
• 证据包含源码/部署版本、契约版本、数据范围、请求标识及持久化断言；截图或 HTTP 200 不能单独算闭环通过。
• 修复后先复验失败用例及受影响链路，再对最终候选版本跑完整发布门禁；环境故障标记阻塞，不归为业务通过。

依据：基线若必须全绿，261 会被现存问题无限阻塞；基线绿若替代最终验收，后续合入又会无人把关。原 L3 定义缺失，应由上述可观察证据落地，而不是沿用等级名称。

四、依赖改为交付物驱动，删除硬等 T+6h

原安排没有足够信息证明已有严格的依赖环，但存在三处明显空窗：

• 259→所有实现：先盘 53 路由再冻结，拖延最小可用契约；依据是全部实现依赖契约。
• 260→258→前端：258 的全链验证需要商品、库存、账号，而种子安排在 T+6h 才启动；依据是下单依赖真实可用数据。
• 最终集成→261：261 若只做早期基线，晚到的跨端缺陷没有完成门槛；依据是原包没有最终候选版本复验要求。

修订执行顺序：

前端可以使用契约样例做开发期测试，但运行环境不得靠 mock 假装 G2 已就绪。依据：开发并行和真实集成是两种不同证据，不能相互替代。

五、小冈必须补一张控制单，否则仍然缺一个包

小冈虽不占六席，但必须明确负责：共享文件写入仲裁、候选版本集成、迁移编排、环境就绪、版本锁定、发布与回滚。依据：材料只写了“编排/发布/热修”和“代应用”，没有可验收产物；六席全部通过也不能证明实际部署的是同一套代码。

控制单验收产物为：候选版本 manifest、合并与迁移记录、261 证据索引、发布记录、发布后 smoke、回滚步骤及其适用条件。不能仅以“六包报绿”放行。

本次通过口径应写死为：固定候选版本在 staging 完成真实数据的黄金路径、沙箱支付及约定异常恢复，全部责任端点有证据，必跑项零跳过、零阻塞。生产支付上线和平台全量开发完成，不在现有材料能够证明的范围内。