交付签收单：收货这一环第一次有纸

状态：已实现并复验（P4-57，包口径 apw-bundle-v6 的固定成员）。 复验命令 node tools/verify-delivery-bundle.mjs（65 项，含 B24/B25：真包里的纸逐条对 manifest 的账）+ node tools/verify-delivery-api.mjs（含 B10c：服务端同一个装配器出同一张纸）， 证据在 docs/verification/p4-15-delivery-bundle/bundle-*/delivery-note.svg 与 note-check.png。

为什么 README.txt 不够

README 是给"会开电脑的人"读的：unzip -t、jq、shasum -a 256 -c -。 包装这一行真正收货的常是车间/印务——微信里收到一个 27 MB 的 ZIP，没人能保证 "收到 7 份还是 8 份、少的那份是不是本来就没有"当场对得上。以前这一步是微信群里问一句， 问完就散了；有争议时连"收过没收到"都拿不出凭据（P4-37"图上有盒、厂里只报筒"是同一类事故的另一半：收货环节没有纸）。

纸上有什么

一张 A4 纵向（1 用户单位 = 1 mm，按 100% 打印就是 A4），逐条投影包内真账，不新造一个数：

区块	内容	数据来自
抬头	设计 ID / 稿名 / 盒型 / 展开尺寸 / 印厂约定 / 交付时间 / 包口径版本 / 成员数	交付包 meta（与 README 同源）
成员表	每份文件的 字节数 · sha256 前 12 位 · 给谁看 · 口径	deliveryPlan() + 装配器现算的 manifest.files（同一份账）
缺件	本次没放进包里的件与原因（"不是漏发"）	skipped（与 README/manifest 同句）
字体	判定 / 用上款数 / 字数 / 中文字码位 / 没拿到授权的字（同名合并 ×N）	P4-55 bundleFontSummary 的账，直接投影
AI	判定 / 位图与真实文字层 / 厂商凭据（查不到就写"无法回查账单"）	P4-54 bundleAiSummary 的账，直接投影
待确认项	逐条 □ 框，可当场逐条问	openIssues（溢出指回 README，不静默截断）
签收栏	厂里/车间名称、收到人、日期、份数勾对、不一致处	一律空白——本系统不代填

三条纪律

1. 不编数据：单上没有交期、没有价格、没有任何"已确认"。厂里勾对与签字栏空白， "不是印厂可生产判定"（红线 7）印在抬头第二行，不靠人记得读附录。
2. 不生成第二套口径（红线 1）：纸由装配器 assembleBundle 在成员哈希全部算完之后、manifest 定稿之前 现算渲染——浏览器工作台、导出 worker、门禁跑同一段代码；门禁 E6 把"浏览器渲的纸 == Node 渲的纸" 钉成逐字节断言。调用方自带 delivery-note.svg 会整包不出。
3. 自指不写：本单列别人的 sha256，不列自己的（自己算不出自己的哈希，同 manifest 一条规矩）—— 这句话必须印在页脚，否则收方会以为"单上没列＝没记账"。本单自己的哈希记在 manifest.json 里， 所以纸、账、ZIP 三者互为凭据。

溢出与异常怎么办

• 成员表排不进一页：折行写"…其余 N 份见 README.txt【包内文件】"——"看不全"与"没写"是两回事；
• 待确认项排不进：同样折行指回 README；
• 没有字体账/AI 账：两行省略（与 README"没有记录也必须出一节"不同，纸上的缺席不会引起误读—— 成员表就是收点数的主账）；
• 裸包（无 meta）：照出纸，抬头写"—"。签收环节不许因为数据缺就缺席。

说清楚没做的

• 纸质回传仍是人工闭环：拍照回传后归档在谁那儿、争议怎么检索，属客户流程（PE-08 SaaS 化时应升级为电子签收 + 审计流水）；
• 只有一种纸型：固定 A4；随车大宗多稿合并成一张总签收单属后续需求；
• 不做防伪：QR 码/骑缝章没做，防伪签收属印厂流程（PE-01 打样闭环时一并看）。