> 静态演示包说明：以下为原始核验与测试计划资料，不代表当前营业、接收或空位；历史开发结果不随包发布。

# 第一阶段验收与下一轮测试

## 已执行自动检查

执行 `node test.cjs`；结果见 test-results.json（历史开发产物，不随演示包提供）。覆盖重量/尺寸边界、三维柜型、季节日期、近铁付费区、取件缓冲、配送截止、预约费用、多件总价、旧价禁用、未知路线、过期核验、预算、非法链接导入等。

基准：2026-11-07，10:00放下、19:00取件，75×50×30cm、20kg、1件，北侧，不进入近铁付费区，取件缓冲15分钟。Crosta寄存静态条件匹配；Multi营业精确时段未知；SPACER重量未知；黑猫和MK晚间领取不适用；临时柜台当天不开。

这些检查证明规则执行与已登记事实一致，不证明运营商当天承诺接收。

## 浏览器验收

检查桌面和390px手机宽度的输入、结果卡、来源展开、编辑保存、非法数据拒绝；验证修改仅本地存储。最终观察结果记录在README。真实手机Safari/Android、辅助技术读屏、真实下单流程未测试。

## 实地清单（待执行）

每个地点记录：出口起点、路线开始/结束时刻、楼层、电梯或台阶、门口定位、当日公告、收费板、各柜型门框净尺寸、重量限制、最晚交付/取件。拍照需遵守场所规则，不拍游客或订单信息。不能用营销网页的“附近”代替测距。

优先走访：Crosta、Multi Ecube、SPACER中央口、MK。近铁点位必须有合法入场资格。SUMAI单独记录外围路线，不能和站内点混称同一距离。

## 运营商待确认问题

1. 寄存与配送分别允许的三维/总和/单边/重量/价值上限？超大件有无特例？
2. 营业、最后收件、最后取件、配送预约截止分别是几点？遇周末、节假日、设施封闭如何变？
3. 预约费、免费时段、跨日计费起点及退款条件？网页与现场矛盾时以哪个版本为准？
4. 配送酒店范围、前台接收要求、预计/承诺到达时刻、延误处理方式？
5. 可否展示静态数据及来源链接？可否商业使用、缓存、自动更新、生成推荐？有无批准API及报价？

这是提纲，尚未代用户发送。

## 5人可用性试验（待执行）

请每人完成一个场景：19点领回大箱、21点领回、14:30后才到站、无近铁票、临时柜台非开放日。记录完成时间、是否理解“待核实”、点击官方后的失败原因、是否愿意再次使用。禁止仅以点击率认定推荐成功。

验收建议：已知硬条件错误推荐为0；每人能找到并理解排除原因；所有人明白本站没有保证空位；在不代订的情况下完成至少一次真实官方可用性确认。任何误把未知当成可用都应阻止公开发布。

## 上线前

取得数据/链接许可，补齐核心点位限制和路线，增加版本审计与共享持久化，明确数据更新责任及人工下架机制。授权确认之前保持静态研究与官方跳转，不打开抓取或转售功能。