用途与实际影响
这项功能怎样使用
为什么需要它
签署人、签名资产、日期和最终 PDF 只要错一项，就可能用错版本；反过来，不需要签名的材料也不能伪造 signed（本人已签）状态。
举个实际例子
我可以问：“这份申请需要我签名吗，现在能不能发？”系统会先核对接收要求和实际页面：无需签名的材料在内容与版面通过后可进入待递送；需要签名的材料还要确认签名属于本人、位置正确且清楚可见。
最后我会得到什么
知道这份本地文件是刚生成、无需签、待本人签、已签还是已锁定可递送；这些状态都不等于实际送出。
可以继续制作
不需签名的版本，或确需签名且已核对本人签名与页面的版本，完成其他检查后才标为可递送。
需要修正
签名人、图片来源或最终可见性对不上时保留待核，不用图片存在代替已签。
当前不可用
必要签名材料或页面检查不可用时暂停签名与可递送步骤，不造占位签名。
从哪里开始
说明这份文件需不需要本人签名，并问现在能否递送。
需要准备什么
- 这份文件需不需要本人签名
- 准备采用的递送方式（若已决定）
从开始到拿到结果
- 1
系统核对并处理
分开无需签、待本人签、已签和锁定可递送的版本，不用一张签名图替代实际步骤。
- 2
交付与接续
交回当前精确状态及下一步；未签或版本已改时不沿用旧的可递送结论。
技术实现与依据
这里保留实现、关键条件、精确入口、历史记录和验证结果。
已能核对签署人、签名资产来源与 DOCX 同图哈希；PDF 当前只有图像对象数量检查，签名最终可见性仍需逐页核对关键规则与设计选择
signature.required=false保持produced，不伪造signed。
required=true必须profile姓名完全匹配并封存profile/asset快照。
DOCX要求找到精确asset SHA-256；PDF当前仅要求pdf_image_count>=1，没有把该对象与签名资产、最终位置或可见性绑定。
自动化signed/ready状态与实际渲染页上的签名可见性是不同证据，不应相互替代。
本地签名不证明对方签名、递送、收到或处理。
外部递送仍需明确对象、版本、渠道和动作授权。
本模块用到的名词
- produced（已生成）
- 文书已生成和核对，但没有声明本人签名已固定。
- signed（本人已签）
- 本地成品包含核对过的本人签名资产；不表示其他人签名或外部动作。
- ready_for_delivery（可递送）
- 确切版本、接收对象、渠道、附件和指纹已锁定，delivered仍为false。
- Signature asset（签名资产）
- 受profile管理并以SHA-256绑定的签名图片；不是证书签名或可信时间戳。
专业定义
签名是一个独立制作步骤：需要时核对规范 profile 和图片 hash（内容指纹），不需要时明确保持 produced（已生成）；两种情况都要经过完整审计才能进入 ready_for_delivery（已具备递送条件）。
解决什么
解决错签、漏签、占位签名、无需签名却标signed和把ready误报成已发送。
当前怎样实现
- signature profile与图片必须是普通可读文件且同目录受控。
- profile.person.name与request signer_name完全匹配。
- build封存profile与asset并再次解析快照。
- _docx_embedded_hashes 对 word/media 内嵌媒体做完整 SHA-256 匹配；_pdf_image_count 仅合计 pypdf 每页 images 数量，要求至少 1，不检查它是否就是签名或是否实际可见。
- audit_rendered_page 对彩色和灰度页检查墨迹覆盖及边缘暗度；这不是签名位置、遮挡或可读性识别。
- build state为produced或signed；release只把delivery改为ready_for_delivery并固定delivered=false。
执行流程
- 1
读取签名要求
- 2
核对profile与签署人
- 3
验证签名图片
- 4
生成DOCX/PDF
- 5
匹配DOCX资产并统计PDF图像对象
- 6
封存签名快照
- 7
完成当前机械逐页审计
- 8
形成ready release并说明签名可见性证据边界
边界
- 不生成占位签名
- PDF图像对象计数不证明签名身份、位置或最终可见性
- 不把图片hash（内容指纹）称为密码学签名
- 不把本人签名称为对方签回
- 不把ready称为已递送
- 不自动执行外部动作
失败与恢复
- profile姓名与请求不一致
- 构建前失败，不选择其他签名图片。
- 签名图片不可读或越出profile目录
- 停止签名腿，保留request和旧版本。
- DOCX没有匹配签名资产，或PDF图像对象为0
- 当前机械检查失败，不形成release；PDF对象数大于0也不能反向证明签名可见。
- PDF有图片但签名位置或可见性尚未核实
- 保留渲染页供核对，明确签名视觉证据仍未闭合；现行CLI（命令行工具）没有专门识别这一缺口的自动检查。
- 无需签名
- 明确保持produced；通过审计后仍可ready，但不写signed。
真实入口
PRIVATE source · formal_documents.py签名profile、asset封存与状态
PRIVATE source · signature helpers签名图片嵌入和规范路径
PRIVATE tests · signature/readback签署人、图片hash（内容指纹）、produced/signed/ready回归
如何验证
- 签署人不匹配和直接注入图片路径均失败。
- 签名profile和asset快照被纳入v3 closure。
- 合成签名测试核对docx_asset_verified=true与pdf_image_count>=1；这只证明当前机械条件，不证明PDF签名像素、身份或位置正确。
- 无需签名build保持produced且不含占位线。
- 渲染器不可用的回归保持ready_for_delivery=false且不生成release。
- 真实签名和外部递送E2E（端到端验证）本轮未运行。
与其他模块的关系
本模块只负责本地签名和递送版本；递送之后的现实状态必须进入下一模块回读。