任务包 A/B 验收报告（2026-09-09 22:1x）

🕐 时效标注（2026-09-13 文档治理）：近期设计件，口径以 TASKS 现行与契约 v1.3 为准。

⛔ v1.1 修订（2026-09-09 23:1x · 小冈）：采纳 fluapi-svip 独立审计结论（/tmp/audit_result.md 材料在案，3916 chars）——本报告 v1.0 的「通过」判定证据等级不足：大量判据仅有「实现存在/被引用/扫描命中」证据，缺「行为证据」（逐项真实触发/幂等对比/端到端操作记录）。修订后结论：A 包 FAIL 退回阿仁（PLAN-02 四件套语义错配为 P0 实质缺陷+N1-N12 行为证据缺失）；B 包有条件通过（体积 ≤2048KB 硬判据未达成，挂 WIP-230 批 2-4 收口后终验；其余项维持）。独立审计全文见 /tmp/audit_result.md（3916 chars，含漏审点 16+12 条）。

方法学教训：验收证据分三级——L1 实现存在（grep）/L2 被引用（引用计数）/L3 行为通过（真实触发+幂等+端到端）。L1/L2 ≠ L3。本次人工验收混用了三级，svip 审计按 L3 标准打回——后续整包验收一律按 L3 出证。

验收人：小冈（派工岗兼复验，空档期处置已登 NOW §四）

任务包 A（阿仁·后端）+ 任务包 B（一号·前端）——判据全部工具化可复跑。

任务包 A（阿仁）——✅ 通过（1 项待说明）

判据	复跑证据	结论
站内信 N1-N12 接线	notifications 服务被 6 业务路由引用共 16 处（orders/bills/redeem/demand/admin_distribution/workbench_distributors）；notifications.py 触发函数 28 个	✅
占位钩子归零	全后端 grep 占位残留 = 1 处（workbench_distributors L50「占位邀请行」——distributor_invitations 表待排期，WIP-238 范围外已知待办）	✅（范围外残留已登记）
锚点能力·商户管理 API	/merchants/1 200（城堡酒店真数据）	✅
演示数据包（055）	merchants 15 户全 is_test + packages is_test 3 条	✅
PLAN-02 四件套实现位置	services/ 无订单域 cron 独立文件；distribution_cron.py 含 cooldown_scan/settle_push/subscription_expiry 三函数（分销域语义）+5 处 notification 引用	⚠️ 待阿仁说明：四件套（状态推进/超时/通知/对账）是否并入 distribution_cron 实现？语义覆盖映射表请补——若未实现则此项退回

任务包 B（一号）——✅ 通过（2 项挂起+1 项移交完成）

判据	复跑证据	结论
主包瘦身	代理体积 21208→9588KB（-54.8%）；删 21 项零引用草稿（icon-back.svg×2 白名单双核）；目录级仍 9588KB>阈值 8192——大头=draft 大图（hotel-room 512K/hero-a 420K/avatar-3 420K/hero-d 348K）	🟡 部分达成——最终 ≤2048KB 挂 WIP-230 批 2-4（图片迁 COS），一号已如实分列
6 页视觉收尾	app.wxss 补 4 个 -on-dark token+status-bar 6 处 antd 色清零（全站 antd=0）+6 页裸色值 11 处 token 化（5 渐变端点无 token 留档报备）	✅
safe-img 切换	组件新增（imgCandidates 候选链+binderror 顺序降级+placeholder+src 重置）——C 端 20 文件移交补丁（闸门代应用：apply --check ✓+红线扫描 4 命中全为删除行+22 文件零新建 ✓）已由小冈应用推 main（25121f6）	✅（移交闭环）
涉钱假数据清理	补丁内古格川菜馆/KT 码号命中 4 处全为删除行；全站扫描清零	✅

闸门代应用记录（一号 C 端 20 文件）

GOV 闸门要求 C 端变更经 xiaogang 推送——一号做成移交补丁，小冈（域闸门人）执行：①apply --check ②红线扫描（4 命中全删除行=合规）③文件清单核（22 个均为一号域既有页面零新建）④应用后 tsc=0+verify-c 六项全绿 ⑤推 main 25121f6。流程首跑成功——后续一号 C 端交付沿用此模式（补丁→闸门审核→代应用）。

待办（验收产出）

~~阿仁：PLAN-02 四件套实现位置说明（本轮内回复即可，若未实现则该判据退回重做）~~ ✅ 已回复（见下方附录）
一号：实包 ≤2048KB 挂 WIP-230 批 2-4（已在途）；主包体积每日一测持续
小齐（退二线留痕）：5 个装饰渐变端点 token gap——已由小冈裁决「保留+登记规范待补」，不阻塞

附录：阿仁 PLAN-02 四件套语义覆盖映射表（2026-09-09 22:2x 回复小冈）

小冈在 services/ 没找到独立的订单域 cron 文件，在 distribution_cron.py 看到 cooldown_scan/settle_push/subscription_expiry 三函数（分销域语义）——这是分销域的独立 cron，不是订单域。订单域四件套在 backend/scripts/order_housekeeping.py（独立文件，不在 services/ 目录）。

一、订单域四件套真实位置

主文件：backend/scripts/order_housekeeping.py（独立脚本，cron 入口，docker compose exec 调用）

PLAN-02 判据	函数	行号	实现语义	状态
① 状态推进	`task_t3`	L245	游客确认超时自动确认（已核销超 `traveler_confirm_deadline` 未异议 → 自动 `confirmed`）	✅
② 超时处理	`task_t1`	L57	商户确认超时取消（offline `booked` 超 `merchant_confirm_deadline` → `cancelled` + 退福钥）<br>`task_t2` L159 支付超时取消（`pending_payment` 超 `pay_deadline` → `cancelled`）	✅
③ 通知触发（N2/N7）	`task_t1`/`task_t2` 内	L123/L223	N2b 超时取消通知 → `notify_order_auto_cancelled`<br>`task_t4` L306 N7 待确认提醒 → `notify_traveler_confirm_reminder`（核销第 5 天，deadline 前 2 天，每单只发一次）	✅
④ 对账状态更新	`task_t5`	L382	账单 `pending_confirm` 超 `confirm_deadline` 未异议 → `auto_confirmed` + N11 通知 `notify_bill_auto_confirmed`	✅（WIP-250 补 T5）

二、与 distribution_cron.py 的关系澄清

order_housekeeping.py（订单域四件套）= 本任务包 A 交付物，对应 PLAN-02 全部四判据
distribution_cron.py（分销域）= 另一独立 cron，处理分销域的 cooldown_frozen/binding_released/commission_settleable/subscription_expiring——不是订单域四件套，是分销域 D1-D8 通知链路
两者并行存在，互不覆盖、互不替代；语义不同（订单域 vs 分销域），cron 调度各自独立

三、幂等验证证据（staging 实跑二轮）

# 首轮 --commit
T1 取消 3 笔 + T2 取消 22 笔 + T4 提醒 1 笔（共写入 26 条状态变更 + 26 条 N2b/N7 通知）
T3/T5 无超期数据

# 二轮 --commit（幂等验证）
T1-T5 全部「无超时订单」「无待提醒订单」「无超期待确认账单」——零变更

四、调用方式（cron 配置参考）

# 每 5 分钟跑订单域四件套（dry-run 预览）
docker compose exec -T -e PYTHONPATH=/app app python /app/scripts/order_housekeeping.py

# 实际执行
docker compose exec -T -e PYTHONPATH=/app app python /app/scripts/order_housekeeping.py --commit --include-test

# 单任务跑
python /app/scripts/order_housekeeping.py --task t5 --commit

结论：PLAN-02 四件套全部已在 backend/scripts/order_housekeeping.py 实现，判据四项全过，不退回。