本章只记录能够由代码、测试结果、Windows 队列或用户反馈支持的事实。对尚未完成的部分明确标记，避免后续团队把规划当成现状。
一、已验证的事实
1. 打印机与系统队列
门店电脑连接的目标队列为 EPSON L3250 Series。当前系统按以下能力配置：
- A4 普通纸
- 黑白和彩色
- 单面打印
- 不支持 A3
- 不支持自动双面
不同地区版本、驱动版本和纸张设置可能导致行为变化，因此机型资料只用于初步建模，最终能力必须通过本机驱动和真实样张验收。
2. 支持文件与默认限制
当前支持：
- JPG / JPEG
- PNG
默认控制值：
| 控制项 | 当前默认值 |
|---|---|
| 单文件大小 | 50 MB |
| PDF 页数 | 100 页 |
| 单订单打印面 | 100 面 |
| 单订单份数 | 10 份 |
| 单打印机活跃任务 | 5 个 |
| 单用户 24 小时打印面 | 200 面 |
| 图片像素总量 | 6000 万像素 |
这些值是原型保护阈值，不是永久产品规则。上线后应放入配置中心并版本化，修改时保留审计记录。
3. 文件校验
系统不是只看文件扩展名，而是进行多层检查：
- 文件扩展名，以及服务端根据内容推导的可信文件类型
- 文件魔数
- PDF 结构和真实页数
- 图片尺寸和像素上限
- 文件实际字节长度
- SHA-256 摘要
门店代理下载完成后再次校验长度和 SHA-256。只要校验不一致，文件就不能进入物理打印阶段。
4. 自动化测试
当前基线完成：
- API 自动测试 20 项
- 门店代理自动测试 18 项
- 合计 38/38 通过
- JavaScript 语法检查通过
- 当时的依赖审计未发现已知漏洞
自动化测试证明状态、边界和异常处理的代码行为，但不能代替实体打印机、真实支付和长期运行测试。
5. 真实打印证据
先完成两次受控 Windows 队列级真实打印提交。两个作业分别进入 Spooler，打印参数均为 A4、彩色、单面、1 份。
随后用户在手机外网环境操作后反馈实际可以正常使用；后台对应订单和打印任务均为完成状态，尝试次数为 1，没有错误记录，队列恢复为空，打印机状态正常。原验收报告记录的是更早的队列级阶段；目前没有归档打印样张或设备传感器证据，所以这里严格记为“系统记录完成 + 用户反馈可用”，不记为独立物理出纸验收。
二、证据应该怎样理解
Windows 打印队列从“有任务”变成“空”，只能证明 Windows 或驱动不再保留该任务，不能在所有机型上证明纸张一定完整输出。真实用户确认、现场传感器、打印机管理协议或人工核对，才是更接近物理结果的证据。
因此系统需要区分：
- 文件校验完成：还没有触碰打印机。
- 已提交 Windows 队列：打印命令可能已被接受。
- 队列任务结束：Windows 认为任务已离开队列。
- 用户或设备确认完成：更接近实际出纸完成。
如果代理在第 2 或第 3 阶段崩溃并失去结果，不能简单地重新执行打印命令，否则可能重复出纸。
三、当前版本仍然不是生产系统
尚未完成或只完成设计的部分包括：
- 当前支付是模拟支付，不是微信支付真实资金链路。
- API 使用 SQLite，本地文件目录承担上传存储，不适合多实例和云端容灾。
- 多处代码仍默认选择第一家门店或第一台打印机。
- 门店代理仍以单个
printerName和进程级busy为核心假设。 - 缺少完整管理后台、角色权限、设备证书轮换、告警、退款和每日对账。
- 当前开机启动方式适合试点，长期无人值守应改为 Windows Service。
- 固定生产域名
print-api.munvor.com仍需部署到稳定云入口并配置微信合法域名。
四、上线前必须满足的红线
以下任何一项没有完成，都不应公开长期无人值守收费：
- 真实支付下单、回调验签、主动查单、退款和对账没有闭环。
- AppSecret、支付私钥或 API v3 密钥仍以明文文件或聊天记录作为正式来源。
- 数据库不能自动备份并完成恢复演练。
- 可能已提交打印的任务仍会自动重试。
- 门店断网、缺纸、卡纸和电脑重启没有演练。
- 告警无法触达负责人。
- 用户文件没有自动删除策略和隐私说明。
- 二维码、平台设备和物理打印机没有一一核对。
五、基线版本的价值
当前成果已经跨过最关键的第一道门槛：证明微信小程序、中心服务、门店 Windows 电脑和普通打印机之间可以形成真实业务链路。后续工作不需要推翻重做，而是把单机原型中隐含的单设备假设逐步替换成可配置、可观测、可恢复的生产能力。