路线正确，但现在应冻结“一个房型、一笔订单、一个履约负责人”的发布闭环，而不是按41页完成率推进。建议先用半天清阻塞，再四席并行补线，最后留一个完整工作日做真机验收；这是排期建议，不是上线承诺，368剩余工作量、原有待验页及一号3页具体内容均『材料未涉及』。
依据：材料明确将可售规则、酒店确认、退款责任、前台设备与人员列为待核项；后端生产就绪不等于真实履约就绪。
立即执行：R1在开工前拉酒店方确认并登记：
门禁：没有具名履约及对账负责人，不进入正式收款上线。
依据：材料只要求核查支付、隐私与提审，并建议摘除路由，未提供通过证据。
立即执行：R1协调刘总/上传侧建立证据清单，逐项核验：
以上实际状态均『材料未涉及』，不能预判已满足或必需补办；应按当前平台规则核对。
依据：修订版允许福钥等延期，通告却要求核销/福钥6页优先；368与375职责表述交叉；最初定义包含“留评价”，业务6环止于“售后可达”，41页也未明确评价承载页。
立即执行：R1发布一张冻结表：发布页、延期页、业务能力、负责人、验收证据。当天由冈子确认368/375边界；明确评价入口与提交落库位置，若延期，须刘总确认变更MVP定义。41页是候选范围基线，不等于41页全部成为上线门槛。
先冻结接口和状态契约，再并行；不能按页面串行等候。依据是预订、订单、退款、核销共享同一订单状态。
| 席位 | 第一波 | 第二波 |
|---|---|---|
| R1 | 半天清阻塞；冻结价格/可售、订单状态、确认/退款/核销权限契约 | order-refund-preview；集成与放行 |
| 小齐 | 368核销链：先验证已支付且酒店确认的订单能否合法核销 | 重复核销、权限与状态回写 |
| 一号 | hotel-booking | order-cancel-reason；更新协调包 |
| 二号 | orders | status-timeline；继续待验页 |
顺序理由：
hotel-booking与368先启动，尽早暴露“收款”和“履约”两端阻塞。orders随后贯通详情和支付结果；状态时间线必须展示真实服务端状态，不能前端推演。五页合计2.5—5人日；理想可在约2个开发日完成页面施工，不含368未知余量、联调及返工。一号原3页先做阻断项，其余后移，避免重复排满。材料原写368由“小冈”跑，小齐是否同一人『材料未涉及』，接手前须确认属主与交接，禁止双人改同一链。
建议预留1工作日，约6—8小时；等待支付、退款最终结果另计。依据：除了页面操作，还需核对服务端状态与款项证据。
人员：二号主跑；一号交叉复核及记录；小齐操作酒店端、查核销链；R1主持异常注入与订单/款项核对。酒店实际值守人必须参加确认和核销，不能全由开发代演。
| 时长 | 执行内容 |
|---|---|
| 0.5小时 | 固定候选版本；备真实房型、日期、顾客/酒店账号及独立测试订单 |
| 1—1.5小时 | 六环：找房→核日期价格可售→支付→酒店确认→现场核销→客服/售后可达；补测评价提交与可见 |
| 2—3小时 | 五异常，分别用独立订单执行，避免状态污染 |
| 1—1.5小时 | 另一台真机复跑主链；冷启动、拒绝授权、延期入口死链冒烟 |
| 1小时 | 对账、整理证据、阻断问题复测 |
五异常必须验证结果：
故障注入在隔离测试环境执行；生产仅做授权正常交易验证。每单留订单号、支付/退款号、截图及日志；不能只凭页面提示通过。
“酒店确认”没有真实责任人和可执行机制。
依据：它处于收款之后、核销之前，材料却未给出实现方式和责任人；一旦失守，就是“钱收到了、房住不上”。
发布硬门禁：真实酒店人员在约定时限内确认一笔订单，并亲自完成核销；R1能拿出订单—款项—履约一致的证据。否则不发布。