hyb-oa/.trellis/tasks/09-17-company-loan-principal-repayment/prd.md

公司借款台账与本金归还

2026-10-11 G：借款材料区域精简（用户已批准；已实施，本地验证与只读复核完成，复核 P2 已修复关闭；未提交）

目标与已确认方向

用户同意只显示当前需要办理的事项，选择公司银行流水作为本次余额核对材料来源，并要求按 KISS 原则收敛。采用现有页面的条件显示与文案调整；复用“出借人确认”栏目，不另建发起入口。本节是具体待批方案，不代表产品已变更。

范围

1. 原借入凭据已满足要求时，收起上传控件，显示“已保存，可查看”；无有效材料时显示上传。材料只有未归档且 governanceStatus=approved 才算满足，其他状态不能冒充已齐全。
2. 有服务端返回的有效在线确认时，收起协议上传控件，显示“出借人已在线确认”。没有有效在线确认时保留原协议入口，并明确“有效在线确认或协议/借款确认书，任选一种”；关联员工的出借人可跳转原“出借人确认”栏目。已有文件仍可查看，不新增“其他确认方式”折叠区。
3. 系统外已还本金依据只在登记的 openingOutstandingPrincipal < originalPrincipal 时显示上传；不能使用随正常还款减少的当前余额 outstanding 判断。既有依据仍可查看。
4. 余额核对材料始终显示，按钮为“上传余额核对材料”，说明为“公司银行流水或代账明细账，覆盖从借入到截至日”。确认表单的“代账余额确认引用”改名“余额依据说明”，示例为“公司银行流水，借入日至核对截止日，已逐笔核对借入及还款”；不自动填入“已核对”声明。服务端字段名称和现有必填规则不变，说明与材料由财务实际核对。
5. “确认期初余额”统一改名“确认借款余额”。提交前就近列出缺项，材料不足、数据加载/刷新或上传处理中禁用确认；齐全后仍由财务显式确认，保留原金额、截止日、版本与说明校验。余额材料上传可以与等待出借人确认并行。
6. 借款卡片只呈现可由当前数据确证的确认状态。现有 DTO 只有有效在线确认及可重发标记，没有未发起/待本人确认/退回状态；无有效确认时用“去出借人确认查看或办理”，不猜测为“等待”或“已退回”，不为本轮增加后端字段或扫描分页列表。余额确认后，对适用现有公司代表授权流程的借款显示“查看或办理公司代表授权”跳转；不把未查询的授权当成未办理，不要求重复授权。

本次银行流水作为余额核对附件，由财务核对其覆盖期间及相关借还款；不新增银行流水导入、自动对账或自动判定材料真实性。原借入凭据、借款确认依据、余额核对依据及必要的历史还款依据四类服务端要求继续有效，公司代表授权继续单独办理。

验收

• AC60：有效入账凭据已存在、在线确认有效且期初未还等于原本金时，只显示余额核对材料上传控件；其他已存文件可查看。缺原件、无有效在线确认和有历史还款时，各自出现对应入口与准确缺项提示。
• AC61：余额材料与确认表单采用上述中性文案和银行流水示例；不再要求材料只能来自代账，不替财务自动填写核对声明；“确认借款余额”名称在入口、弹窗和操作提示一致。
• AC62：上传但尚未有效、被隔离、归档或刷新失败的材料不能使确认按钮误启用；有效在线确认失效并刷新后重新显示缺项。材料齐全仍保留服务端最终校验和确认说明必填。
• AC63：复用现有确认/授权栏目跳转，不新增发起流程；卡片不猜测等待/退回/授权状态。正常系统还款不会触发历史还款依据要求，已办理事项不被引导重复办理。
• AC64：前端类型检查、构建和电脑/手机针对性验证通过，覆盖上述显隐、缺项、刷新与跳转；原借款后端规则、权限、数据库及历史材料保持。

本轮边界

只规划页面、相关测试与操作手册的同步；不改后端、接口或数据库，不引入新视觉体系，不调整此前仅记录的“登记时金额/日期默认值”问题。具体方案获批后再实施；提交、发布按现有流程另批。

2026-10-11 F：员工与公司组合数据库唯一约束（已发布 36b949ec）

生产只读排查重复组合为 0 组后，用户批准把“同一公司与员工最多一个出借人（归档计入）”落到数据库。结果见 implement 顶部 F 节。

• AC56：数据库拒绝同一公司与员工的第二个出借人，含归档行；空员工的手工出借人可多条共存。
• AC57：应用触到约束时返回原有“出借人冲突”提示，不报 500、不误报请求重复；代码检查与员工行锁保持。
• AC58：借款完整回归通过，并经独立只读复核（涉及迁移）。两轮完整回归各 84 迁移、12 阶段、去重 247 项通过；另一会话只读复核无阻断项、20 个内存探针通过，唯一 P2（缺本迁移回退说明）已在下方补齐。
• AC59：发布窗口重跑存量重复计数为 0，并按 1 个待执行迁移部署（2026-10-11：重复 0 组；迁移对账仅该迁移，部署后 pending=none、唯一索引存在）。

迁移回退说明（20261011010000_loan_lender_employee_unique）

• 建索引失败：迁移只有一条 CREATE UNIQUE INDEX，单语句原子执行；若发布窗口内出现重复组合导致失败，索引不会部分建立，Prisma 将该迁移记为失败并阻止后续迁移，应用不切换到新版本。处理方式是停止本次发布，回到只读计数重新排查；不在发布中手工删改出借人数据，不改写已应用的迁移历史。失败迁移记录的处理（如标记回滚后重试）须另行批准后按运维手册执行。
• 应用回退：回退到上一版应用时保留该索引，不删除。上一版代码在员工行锁内已拒绝同一组合，正常路径不会触到约束；只有极端情况越过旧检查时，旧版创建路径会把约束冲突报为“请求重复”(409)，旧身份确认入口会报 500，两者都不会写入重复数据。
• 撤销约束：如确需取消该约束，另起新迁移 DROP INDEX 并单独批准，不回退或删除本迁移文件。

2026-10-10 E：追回证据刷新提示与员工资料误报（已实施、本地验证及独立只读复核完成；未提交）

用户批准两项小问题按方案修复，复用本任务，不含数据库唯一约束（需先查存量重复、单独规划）。结果见 implement 顶部 E 节。

• AC52：上传银行证据后对话框立即关闭；刷新完成前证据下拉框与确认按钮均不可用并有可见提示，不发出提交；刷新后可选中刚上传的证据。电脑/手机浏览器验证。
• AC53：财务预览员工资料后员工登录（含失败再成功），保存不再误报“员工资料已变化”。
• AC54：姓名、所属公司、开户行、银行机构、账号的真实变更，以及状态/归档，仍拦截保存；反向变异能被测试发现。
• AC55：资料拦截规则改动经独立只读复核（2026-10-11 REVIEWED_NO_BLOCKER，回执 review-20261011.json）。

2026-10-10 D：授权翻页与追回到账排查（已本地提交 91fe31f0，未发布）

用户要求规划“员工授权翻页超时”和“登记追回到账”两项遗留问题。复用本任务作为执行合同，分成 D1/D2 两个独立验收阶段，不把当前父任务 in_progress 当作本轮实施批准。规划基线为 db919dc6，开始时工作区干净；线上业务基线仍为 4a5cd8f2。本阶段目标是查清失败发生在哪一层，并形成能稳定触发相关分支的回归，避免漏走分支的通过掩盖问题。

规划时点的历史证据及缺口（后续结果见 implement 顶部）

阶段	已确认事实及来源	尚未确认
D1：公司代表授权的出借人翻页	原 loan-incoming-prefill-20261009/regression-r6.log、regression-r7.log 为 page.waitForResponse 30 秒超时，旧任务记录标注手机端；没有对应失败截图。当前 scripts/qa/company-loan-employee-browser.cjs:160 仅在目标不在当前选项时翻页，:163 等待谓词不限定页码。服务端 server/src/routes/companyLoans.js:245 按姓名、ID 排序；client/src/api/companyLoans.ts:52 每页 30 条，client/src/query/queryClient.ts:6 查询缓存有效期 5 秒。	点击是否真正发生、等待是否遗漏/误捕响应、目标实际位于哪页、是否走缓存，以及是否为产品分页问题。
D2：登记追回到账	loan-lender-ack-20261010/full-loan-r1.log 只有 synthetic UI 登记追回到账: 空提示；没有可据以归因的请求结果。旧脚本按最后一个 option 选证据；当前 scripts/qa/company-loan-reconciliation-browser.cjs:45–:59 已改为捕获上传 evidenceId 并按 ID 选择，:32 增加表单有效性采证，但这不能证明旧失败根因。提交在 client/src/components/common/LoanBankReconciliation.tsx:59，退款入账在 server/src/services/loanBankResults.js:172。	当时选中哪份证据、是否发出 POST、服务端是否拒绝/挂起、是否已经成功但刷新未完成；原日志未记录设备和第几次追回。

范围与顺序

1. D0：核对历史日志、脚本版本及最小采证方案；只使用合成资料和隔离 PostgreSQL/浏览器环境。
2. D1 优先：固定至少 65 名满足授权选择条件的出借人，按接口实际排序校验目标在第二/第三页，并强制浏览器走到第三页、返回上一页后再进入。区分首次加载、快速响应、可控延迟、5 秒内命中缓存、弹窗关闭重开及无关同路径响应。
3. D2 随后：保留旧失败所属的独立复核模式，并补当前关联方模式对照。固定晚到成功产生待追回 40 元、两次追回 15/25 元的现有合成路径；分别观察上传、证据选项刷新、登记、复核、入账和余额/冻结刷新，不把“弹窗关闭”当作唯一成功依据。
4. 先用采证区分测试等待、测试资料、界面状态和服务端规则，再做对应最小修复。如果仅是测试问题，只修改测试；若证实产品问题，修复限定在该分页/登记路径。材料、权限、审批、币种、重复入账和金额边界保持现有合同。

不包含：生产读写/真实付款、云 OCR、数据库迁移、通用对话框重构、其他 P3、暂停的登记默认值、提交/推送/部署、清理历史证据。若结论要求改变权限、状态机合同、核算规则或迁移，先回到方案确认。相关现有权限/资金守卫的缺陷修复仍须只读独立复核。

验收标准

• AC46（翻页分支真实触发）：电脑、手机均通过实际服务证明目标不在第一页，明确收到/命中第二、第三页数据并显示对应选项；往返及关闭重开不混入其他页或他人的选项，财务登记后由正确公司代表确认，未创建还款。
• AC47（翻页归因）：采证能区分没有点击、没有请求/合法缓存命中、请求失败/等待错误、响应成功但界面错误。可还原的旧等待方式与当前/修复方式做同条件对照；故意让页码不变或返回错误页时，测试须失败。缓存命中不能被要求“必须再发一次请求”。
• AC48（追回成功链）：独立复核及关联方模式的电脑/手机均实际完成上传指定证据、登记、不同身份复核、财务入账；待追回从 40 到 25 到 0，仅全额完成后关闭对应追回冻结，不关闭其他原因；原终态、本金、付款批次数及历史事实按既有规则保持。
• AC49（追回失败可定位）：无有效选择/原生表单阻止提交、可控请求延迟、服务端拒绝、200 后刷新延迟分别有可区分证据；有 HTTP 结果则绑定准确批次、方法、请求 ID 与安全错误理由，无提交则明确记录无 POST，不再仅留空 alert。
• AC50（金额与重复保护）：错误方向、作废/错误类别证据、超出剩余待追回金额受阻；相同请求键重试不重复创建，同一银行交易不能重复入账，已入账重放不重复计算。拒绝或事务失败不提前减待追回、关闭冻结、改本金或生成付款批次。独立及关联两模式共 20 组补验通过，回执和边界见 implement 顶部。
• AC51（验证与结案）：两项定向场景各完成电脑/手机连续 3 轮（每轮新隔离环境，含明确缓存分支），随后最终版本一次完整借款回归；必要的类型/构建/后端与合同检查、按实际影响的只读复核通过。结论逐项注明“根因已证实并修复”“已补强但原事故未定”或“待进一步排查”，只有能解释历史失败并经反例对照验证的项才关闭原根因待查。

技术未知在 design 的实验清单中处理，没有需要先决定的新增产品行为。方案已在 Claude 会话获准实施，授权来源见 implement 顶部；本会话按同一验收范围补齐复核发现的测试证据。提交、推送、部署仍须明确授权。

2026-10-10 N5-C 已发布（4a5cd8f2，真实办理待验收）

出借人在线确认及站内通知直达已随 4a5cd8f2b3e04da24551ddf1ee99b4167aa76710 推送部署。补记时本地 HEAD 与 origin/main 一致、工作区干净；已有最终候选验证 PASS，部署前 13/13，唯一待应用迁移为 20261010010000_loan_lender_acknowledgements，部署后 83/83、无待应用迁移、合同刷新通过。公网健康、页面与资源正常及未登录接口 401 沿用发布会话转交结果；本轮只读核对本地日志，没有重新访问生产。

用户回报此次未做手工快照；本会话此前建议做快照，决策来源在 implement 顶部区分记录。部署日志跳过登录后的 live smoke，真实发起声明、本人确认、余额确认、公司代表授权及首笔还款尚未验收。财务/出借人按现有手册办理，代账余额核对材料及必要的系统外已还本金依据继续必需。

整体任务保持 in_progress，N5/N6 和暂停的登记默认值待办继续开放。两项浏览器遗留失败的最新诊断与本地修复见 D 节；本节及以下“根因待查、未提交、未发布、未重跑最终门禁”等表述保留各轮历史时点，以 implement 顶部最新证据为准。文档补记不修改线上版本或工程合同。

2026-10-10 N5-C 出借人在线确认借款（用户已批准实施）

用户批准将“借款确认书”增加为 OA 内可追溯的出借人声明，范围仅限本功能。此前“先记录、不修改”对本功能的限制由本次批准取代；登记默认值调整仍只记录、不实施。线上记录是本系统接受的借款确认依据，不宣称仅凭账号操作留痕即当然取得与纸质签字相同的法律效力。

• 财务可对同一公司、同一员工出借人的一笔或多笔尚待核实借款发起确认；已确认余额但存在失效在线声明历史的借款允许重新发起。固定借入日期、原始本金、截至日未还本金、原件摘要及对应身份。保留现有纸质协议/借款确认书上传路径；非员工出借人沿纸质路径办理。
• 只有出借人关联的在职员工本人能查看自己的声明范围、核对原件并确认或退回；发起财务不能代确认，其他员工、管理员或公司代表权限均不能替代本人身份。此动作不要求出借人具有经理/CEO 权限，也不赋予其财务台账或他人借款的读取能力。
• 确认记录、明细和决定不可改删。借款关键金额、日期、原件或出借人身份关联变化使旧确认失效，改回旧值也不复活；新增余额核对等其他材料不导致无关失效。退回后财务可重新发起。
• 确认余额以及后续材料完整性检查接受“纸质协议/借款确认书 或 有效在线出借人确认”；原借入凭据、代账余额核对材料和必要的系统外已还本金依据仍必需。出借人声明不自动确认余额，不代替公司代表授权或付款批准。
• 不包含通用电子签章、生成协议正文、替代代账核对、登记默认值修复、生产写入/发布或发送外部通知。财务可继续线下准备确认书及代账材料，不依赖开发完成。
• 2026-10-10 发布前入口收敛：根据用户给出的两种方案及委托取舍，选择 OA 站内通知入口。普通员工不显示常驻“公司借款”导航；财务及公司代表保留入口，本人确认权限和直达路由继续有效。财务发起时仅为对应出借人创建站内通知，点开直接查看该次声明；不纳入通用待办或外部消息推送。

验收：

• AC40（本地合成验收）：财务可对一笔/多笔同公司同出借人借款固定快照并发起；跨主体、未核实身份、缺原件、重复及错误重试有明确结果，审计失败全部回滚。
• AC41（本地合成验收）：本人可在电脑和手机查看快照/原件并确认或退回；财务代确认、他人越权读取/下载/决定、自发自确认和迟到请求跨账号重发受阻。
• AC42（本地合成验收）：确认与快照不可改删；关键字段/原件/身份变化后旧证据永久失效，确认与变更并发不会消费过期结果，变更再还原不复活旧记录；余额确认后可重发失效声明，不改既有余额确认事实。
• AC43（本地合成验收）：在线确认只替代协议类材料，代账和原件仍必需；有效在线记录可实际走到余额确认、既有公司代表授权及还款申请，纸质路径回归通过。
• AC44（本地验收与交接完成）：新增迁移、HTTP/数据库并发与电脑手机验证、独立只读复核及发布边界据实记录；完整借款回归 r4 去重 216 项通过，前期失败及未定根因保留；尚未提交或发布，不宣称线上已可使用。
• AC45（入口调整，本地合成验收及只读复核完成）：普通员工的电脑导航/后备导航/手机“我的”均无常驻借款入口；财务发起只为该出借人创建一条站内通知，同请求重试/并发不重复，事务失败不残留通知；电脑和手机点击通知直接打开该声明并仍执行本人校验，历史或失效通知不恢复旧确认效力。同 SPA 切换声明/浏览器返回正确定位详情并清空旧草稿。财务/公司代表入口、本人权限及账号切换请求保护不退化。最终入口专项 r5 为 17 HTTP、18 浏览器、9 数据库检查通过，复核无阻断；未提交或部署，尚未重跑最终发布门禁。

2026-10-09 N5-P 原借入回单识别预填（2026-10-10 已发布 2063ff1e，真实业务验收待办理）

目标与依据

用户在办理 N5 时提出先识别凭证或流水、再自动填写，并明确要求“规划改进任务”。本阶段复用当前借款任务，减少已持有原借入回单时重复录入金额、日期、凭据号及再次上传同一文件的操作。初始授权仅限规划；此后用户批准完整方案，已完成实施、五轮独立复核及发布，详见 implement 顶部记录。真实业务录入、云 OCR 与付款仍按各自授权和验收边界执行。

规划时页面先手填登记借入、保存后再上传材料（当时的 client/src/pages/CompanyLoansPage.tsx:176、:121）；服务端创建借款和上传凭据是分开的动作（当时的 server/src/routes/companyLoans.js:262、:314）。当时本地 PDF 工作者能读取文字，但对外只返回凭证分类；银行 OCR 归一化未包含到账日期和双方名称（当时的 server/src/services/paymentReceiptDocument.js:101、server/src/services/paymentReceiptMatching.js:41）。本阶段因此新增借入预填合同，不能把付款核验通过条件直接用于借入。

范围与要求

• P1 单笔原件优先：登记借入增加“上传原借入回单”路径，一次处理一份、仅含一笔交易的银行回单 PDF，包括扫描 PDF；新识别入口上限 5 MiB、20 页，多页必须属于同一交易。保留手工登记和既有附件能力。默认“历史借入登记”，财务明确确认登记性质；文件日期不能自行产生当天新增现金流。
• P2 字段预填：识别原始本金、实际到账日期、原凭据唯一引用、人民币币种与付款/收款方摘要。可靠字段预填，缺失或歧义字段留空并说明；流水号与凭证号分别辨识，优先稳定流水号，无则使用明确凭证号，不以文件名或随机编号补造。公司和出借人只从已有记录中建议匹配并由财务确认；没有出借人登记时沿已实现的员工选择入口办理，不依据回单新建员工或替换收款账户。
• P3 识别与业务确认分开：回单只支持证明历史收款，不推断借款性质、未还本金、余额核对截止日、代账确认或公司代表授权。财务补充余额字段并明确核对原件及借款性质后，才能保存为“余额待核实”。余额确认仍要求三类材料及代账引用；关联审批、在途控制、还本与核销规则保持现有合同。
• P4 降级与方向：可读 PDF 优先本地提取；文字缺失或必要字段不足时，在现有银行 OCR 配置与调用边界允许的条件下补充识别。关闭、不可用、超时或额度不足时显示人工核对入口，不伪造字段、不切换提供商、不自动反复调用。公司入账回单可用于借入；已知公司支出、失败/处理中、非最终回执、多交易文件或非人民币不作为此路径的有效借入回单。无法判断与已知矛盾分别显示，未知可核对补录，明确矛盾需更换材料。
• P5 核对后保存一次：识别本身不创建借款、出借人、付款或正式业务附件。确认保存时，借款与其 incoming 原件关联一并成立，原件不要求用户再次选择；附件或审计失败不留下可用的半条借款。双击、重试、重复引用、已有相同原件和并发重复需有明确结果。未保存即取消、换账号或离开时清除预填内容；本期不提供跨设备或关闭后续填草稿。
• P6 保留人工修改与来源：允许核对后改正预填字段，迟到结果不能覆盖人工已改字段或新选择的文件。保存留存识别方式、原件摘要、修正字段及实际经办审计，不把原始票面/OCR payload或完整银行账号写入日志、任务或浏览器长期存储。既有材料下载权限、用途与审计继续适用。

本阶段不包含

整份银行流水/Excel 批量导入、多交易拆分、自动建立借还对应、自动会计凭证、银行验真、自动确认余额/授权/付款、新银行或 OCR 提供商、图片直传识别、历史记录批量重识别。既有图片附件上传不受影响。规划和本地合成验收不包含真实票据调用云 OCR、生产配置、生产录入或发布。

验收新增 AC32–AC39，技术合同及执行记录分别见 design、implement 顶部 N5-P。上述方案已实施发布；本地合成验收、真实样本解析、云 OCR、公开发布和真实业务办理分别记录，不互相替代。

2026-10-09 N5 员工出借人选择调整（本地验证完成，未发布）

用户要求员工出借人从已有员工中选择，复用系统中已维护的资料，不重复录入姓名和银行卡。已核对：员工主档存在姓名、公司关联、银行机构及加密账号；原借款入口要求手填，再另行核实员工关联。用户已确认本方案，授权本地实现与验证；不包含提交、推送、部署或真实业务录入。

• 员工出借人从已有 OA 员工选择，财务核对姓名、所属公司、开户行和遮罩账号后关联；姓名与银行资料由服务端读取，不接受浏览器另传一套值，也不创建新员工。借款所属公司仍须明确确认。
• 沿用现有员工资料和银行卡维护权限；资料缺失、不可用或不符合现行付款条件时，说明缺项并引导有权限的人到员工资料维护，不在借款表单重复填写或自行替换真实开户行。
• 同公司同员工已有出借人登记时优先复用；历史重复或资料不一致必须显式处理，不按姓名合并。员工资料更新不自动改写借款授权或在途付款；复用后的账户刷新按既有版本、占用和审计规则核对。
• 仅调整员工出借人的资料入口；原非员工个人出借人能力保留，关联方审批、技术员工不参与、Q6 禁用和真实付款授权边界不变。具体实现及验证范围见 design、implement 顶部。

AC28–AC31 已本地实现并通过独立只读复核：126 组借款 HTTP、45 组电脑/手机浏览器、82 迁移、9 个针对性变异及相关类型/构建/合同检查通过；实际范围、前期失败和完整重跑证据见 implement。未提交、未发布，也未录入真实台账；不把本次软件验收算作 N5 真实登记或 N6 银行还款闭环完成。

2026-10-09 N4 发布完成，真实业务验收待办

已接收并核对本次发布证据：beb9f02c 完整门禁 PASS，独立只读代码复核无阻断项；发布前只读核实借款相关存量均为 0、实际待应用迁移为 9 个。该候选已推送并部署，部署后 82/82 迁移全部应用、13/13 复核及合同刷新通过；公网健康、就绪、浏览器页面和静态资源检查正常（Claude 会话核对、用户转交）；部署前按用户决定未做快照。生产合成 PDF 解析冒烟 PASS，运行版本与候选一致，识别为正式支出回单、PDF 文字、明确成功、无问题标记，耗时 521 毫秒。发布中断与补验过程、证据位置及核验边界见 implement 顶部。

N3/N4 的软件复核及本次发布检查已完成，整体任务继续 in_progress。接下来是 N5 真实台账和公司授权登记、N6 首笔真实还款及会计交接；这两项尚未办理。财务按已有材料与已确认事实登记，马经理按既定公司代表身份确认，技术员工不参与；首笔还款的金额、分配及时间在实际办理前确定，发布通过不构成真实业务写入或付款授权。

本轮仅补发布与接续记录，不修改资金规则。已部署版本和原门禁回执仍绑定 beb9f02c；后续文档提交不影响线上运行，也不继承该回执的新候选发布资格。下方各日期的“未推送、未部署、待独立复核”等表述均保留为历史时点。

2026-10-09 N3 独立复核接收与 P2 口径确认

已接收 4c37fcee..1c4633b6 共 62 文件的独立只读复核，结论 REVIEWED_NO_BLOCKER；复核前摘要一致，复核人未改源码、未重跑测试。代码验证依据仍为 1c4633b6 第五轮完整门禁 PASS，具体接收、P3 后续项及原始报告见 implement 顶部。

本期接受已批准 N1 保守策略的共享报销影响，并补齐规则事实源：JPG/PNG/WEBP 及无可提取文字的扫描件 PDF 继续支持上传、预览和 OCR 字段提取，付款依据须由财务核对并由另一名合格人员独立复核；可读 PDF 也须满足全部自动核验条件。此处不改变程序、权限或借款关联模式。P3 的锁内解析、旧证据字段差异和记账日期下限留作后续，未实施。

本次仅三份文档收尾，沿既有授权本地提交并做文档/治理检查；未变代码不重复全量测试。原 PASS 只绑定 1c4633b6，最终发布候选须在 N4 取得与其提交一致的门禁回执。独立代码复核已完成，真实还款、生产启用和公网验收仍未完成；整体任务保持 in_progress，生产查询、推送、部署及真实业务写入另按明确授权办理。

2026-10-09 N3 第四轮结果及手机截图前置检查

候选 8e17e8df 第四轮完整门禁为 FAIL：82 迁移、服务端 4558 通过/1 项既有可选跳过，静态/构建及业务回归通过；浏览器 371 通过/1 失败、零跳过/重试。报销付款、PWA 升级和企微历史三项均通过。唯一失败为 R106 手机登录前首次截图的 Chromium 协议错误，尚未执行手机登录；不能把这一结果写成认证故障。

由 09-06-release-gate-integrity 补原截图前的登录页面就绪断言，保留全部截图和巡检、真实隔离后端登录及 Worker 设置，不修改产品或资金规则。Chromium 内部唯一成因尚未证明。先受管定向重验完整文件，再按既有授权本地提交并对干净新候选执行原完整门禁。第四轮原始证据及 local-followup.json 保留在 artifacts/release-gate/loan-receipt-n3-20261009-r4/，第五轮计划回执为 artifacts/release-gate/loan-receipt-n3-20261009-r5/，实际结果以回执为准。

修正后受管完整 R106 文件 1 项通过、零失败/跳过/重试，14 张截图和巡检报告实际生成；环境、源码一致性及清理通过。该结果不替代新候选完整门禁或独立复核。

独立代码复核、真实还款和公网仍待完成；没有推送、部署、生产查询或真实 OCR。整体任务保持 in_progress，不以旧通过项和定向结果拼接完整资格。

2026-10-09 N3 第三轮结果及桌面测试隔离修正

候选 98bab397 第三轮为 FAIL：82 迁移、服务端 4558 通过/1 项既有可选跳过、静态/构建和业务回归通过；浏览器 371 通过/1 失败、无跳过或重试。报销付款主链路和 PWA 升级本轮均通过。唯一失败为桌面企微历史测试在整页导航后等待标题超时，快照已回登录页；现有测试使用模拟接口，却只在手机 context 屏蔽 Service Worker。原请求来源未记录，不将该漏项写成已证实的历史唯一根因。

09-06-release-gate-integrity 已补默认桌面 context 的隔离，并要求原导航实际获得该 fixture 的 refresh/profile 响应。原三项用例、登录、会话、桌面只读、手机布局和截图全部保留；受管定向 3 项通过，环境和清理通过。资金及产品代码、迁移、正式门禁范围和预算未变。按 N3 既有授权形成新的本地提交，第四轮完整回执固定为 artifacts/release-gate/loan-receipt-n3-20261009-r4/，以其 release-result.json 和 local-followup.json 记录实际候选及结论。

前三轮 FAIL 完整保留，定向通过不能拼接完整资格。独立代码复核和真实还款验收仍开放；没有推送、部署、生产查询或真实材料外发。以下为各历史时点，整体任务继续 in_progress。

2026-10-09 N3 第二轮结果及 PWA 测试等待修正

修复候选 18315d11 的完整第二轮仍为 FAIL：82 个迁移、服务端 4558 通过/1 项既有可选跳过、静态/构建及业务回归通过；浏览器 371 通过/1 失败、无跳过或重试。本轮报销付款主链路完整通过；唯一失败为 PWA 自动升级时，测试读取版本号的 page.evaluate 遇到正常导航而失去执行环境。错误栈和原回执保留，不把定向通过或事后 B 版本见证替换为整轮 PASS。

该测试等待修正归属已有 09-06-release-gate-integrity 任务：改为当前文档的属性断言，原 45 秒上限、同会话升级及所有结果断言保持。受管定向 1 项通过，环境与清理通过；产品 PWA、借款/报销资金规则、迁移和门禁范围未变。按 N3 的本地修正与提交授权固定新候选，第三轮回执为 artifacts/release-gate/loan-receipt-n3-20261009-r3/，实际结果以其 release-result.json 和 local-followup.json 为准，不预填通过。

独立代码复核、真实还款、发布和公网验收继续开放；未推送、部署、查询生产、外发原件或写入真实业务。下方记录保留各轮历史时点，任务仍为 in_progress。

2026-10-09 N3 本地提交及新候选验证接续

N1–N2 已本地提交为 5a7a1352。首轮完整候选验证为 FAIL：服务端、构建及业务回归通过，浏览器 371 通过/1 失败；人工核验测试提交返回 409，未执行付款。原测试未记录具体业务原因，不能追认解析超时为根因；现已补其确定缺失的人工原件依据及安全诊断，保留全部资金断言。复验安排见 implement 顶部，后续新候选实际结果以 artifacts/release-gate/loan-receipt-n3-20261009-r2/ 为准，首轮失败回执不覆盖、不改写。

用户明确“继续下一步”，沿已列明的 N3 处理 N1–N2 的 31 项本地改动：核对上一轮验证清单、补任务记录、单独本地提交并对干净的新候选运行 verify-candidate。范围、命令及失败处置见 implement 顶部；首轮实际候选及结果以 artifacts/release-gate/loan-receipt-n3-20261009/ 为准，不沿用 ce11dea9 的通过结论。

当前 inline 指令禁止派 implement/check 子代理；独立代码复核与真实还款验收继续待完成。提交和候选验证不代表生产启用，未授权推送、部署、生产访问或真实业务写入。下方 N1–N2“未提交”为上一轮历史时点；整体任务保持 in_progress，AC5、AC8、AC27 等开放条件不提前勾选。

2026-10-08 实际银行材料核对后的接续（N1–N2 本地完成，未提交）

用户先要求重新梳理后续任务，随后明确“开始执行，需要我手动操作的及时告诉我”，批准 N1–N2 的本地实施、针对性验证及主会话检查。目标是形成可证明实际付款的回单处理路径，再完成独立代码复核、获准发布和首笔真实还款；执行顺序见 implement 顶部，凭证处理方案见 design 顶部。提交、推送、生产操作及真实付款不在本次范围。

N1–N2 已完成本地实现及可执行验证：正式/非最终/未知凭证区分、无字面成功状态的已记账支出人工核对、旧证据本地重检、最终核销及电脑/手机交互已贯通；原件限制与交易唯一性不能由人工覆盖。合成借款链和真实历史材料的内存预验分别留证，详细范围见 implement 顶部。新增 31 项本地改动尚未提交，无新增迁移；独立代码复核及真实银行闭环仍待完成。

• 实施基线为已提交候选 ce11dea9，关联方模式正式本地门禁已通过：82 个迁移、服务端 4519 项通过及 1 项既有可选跳过、浏览器 372 项通过且无失败/跳过/重试。证据为 artifacts/release-gate/loan-ce11dea9-20261008/release-result.json 及同目录 local-followup.json，不覆盖本轮未提交的凭证变化。本地 main 比本地 origin/main 多 13 个提交；未推送、未部署。
• 两笔历史借入的正式银行回单已做本地文字核对；用户已确认均未归还本金、本年无新增借还、开卡小额往来已归还且不计借款，并确认沿用原个人收款账户。具体金额、账号及原件仅在受控材料中保留。上述事实不再重复提问；财务正式录入时仍须留存原凭据、已有会计记录引用及核对截止日，不把历史借入当成当天新增收款。
• 财务经办、马经理代表公司作关联方确认；技术员工不参与业务复核、审批或见证。代表权不再待决，真实授权及范围尚未写入 OA。关联模式 Q6 继续关闭，不要求补足第三人或取得无结果查询 PDF 来办理正常还款。
• 获准的四份 PDF 此前已完成真实 OCR 调用。其中 S001/S003 虽字段匹配，但原件注明不作为最终交易依据；此前实样只执行到本地匹配函数，不能称为已复现生产错误核销。本轮借款完整链只用合成数据；另用 S002-A 的正式支出原件做内存人工核验预验，证明该格式可以留存记账依据，不代表其属于借款或已完成真实还本。S002 专项 OCR 适配仍后置。新取得的两份正式借入回单证明的是历史入账，不能充当未来还本的支出回单；本轮没有新增云 OCR 调用。
• 独立代码复核、正常付款凭据及提交归属实样验收、真实业务录入、发布与公网验收保持开放。此前银行流水及原件整理不等于这些项目已完成；2026-10-07 的生产空存量结论仅适用于该查询时点。

R4/AC5 本次补充的凭证验收边界

本小节已随 N1–N2 获准实施，完成状态以 implement 的验证结果为准；其余 R1–R6 和原 AC 编号保持不变。

• 明确注明非最终依据、仅受理/处理中，或凭证性质不明的材料，可以留存，不能仅因金额、账户、状态字段匹配而核销。机器未提取出限制说明不等于原件没有该说明；普通人工录入或关联确认不能覆盖已知限制。
• 正式银行回单是否证明实际付款，应根据已核验格式的记账方向、记账/交易事实和关键字段共同判断。不能仅凭标题推定成功，也不能要求经办补写原件不存在的“交易成功”。正式借入回单的公司入账方向不能当作公司还本的付款方向。
• 原件足以证明付款而机器未能提全时，保留有依据的人工核对路径；经办录入原件实际信息、确认人按既定模式核对，记录原件及判断依据。原件不足、交易归属不明、字段冲突或重复交易仍不能放行。自动与人工结论分开记录。
• 核验、人工证据重建及最终核销须消费同一份仍有效的凭证依据；旧记录缺少新判断依据时不得直接沿用为自动通过，不能回写已发生的付款历史。验收必须包含最终资金动作及失败后本金/占用未变化，不能止于匹配函数。

2026-10-08 两人办理关联方还款（本地实施与合成验证完成，已授权本地提交及正式验证）

• 用户确认：实际经办为一名财务兼人事行政；马经理为股东、个人出借收款人，且有权代表公司批准还款。技术员工不参与复核、审批或见证，不增加财务权限，不作为候选、任务接收人或业务验收所需人员。
• 按用户“按照这个思路规划”的要求，采用“财务经办 + 马经理代表公司作关联方确认”。公司授权已明确，不再列为待决问题；其授权范围和真实身份在业务启用时留存。该模式具有两名操作者的分工，不具备无利益关联的独立审批，页面、凭据和审计必须如实标明。
• 原独立模式在创建时排除出借收款人，按实际人员配置无法办理该笔还款；该默认规则保留。新增关联模式覆盖正常付款及归属、人工回单、提交清单、失败/终态释放、补证恢复、晚到成功、追回和误报关闭，实施验证记录见 implement 顶部。
• 新模式只豁免指定确认人的“收款人关联”冲突，不豁免制单、提交、导出、上传、录入或提案等经办冲突。财务可承担多项经办工作；同一真实身份不能通过多个账号或角色自审。Q6“人工确认未提交”在此模式下不启用，原双独立复核条件不降低。
• 回单 OCR 已实现，普通回单按实际文件识别和匹配，无需先向银行咨询。银行终态证据与普通 OCR 验收分开；OCR 或两人的确认均不能补足缺失的交易归属，也不能从“没有回单”推断没有付款。
• 用户已明确“开始实施”，本轮已完成 RP1–RP4 的本地实现及可执行验证；随后明确授权将 39 项本地改动提交，并运行新候选正式门禁，执行安排见 implement 顶部。AC20–AC26 有本轮合成证据；AC27 的数据库部分已验，独立代码复核及真实材料验收仍待完成。新候选门禁结论以该候选回执为准，旧候选 4c37fcee 的通过回执不用于证明新模式；未授权推送、部署或本轮生产查询。

2026-10-07 本地阶段状态（历史时点，现状见 Current Status）

S4–S8 已本地提交 431c36ea；补齐剩余界面后合成回归为 81 迁移、HTTP 95、浏览器 19、数据库约束 9 组通过。应用代码沿用修复后的同模型只读静态复核，本轮只补测试与记录。S0 生产只读查询确认 OA 借款模块当前记录为 0，73 个已应用迁移校验值一致，待执行 8 个；不代表银行或线下没有付款。人员、真实建行材料和业务独立验收仍未完成，正式发布门禁尚待执行；不据此勾选整体真实还款验收或声明已部署。完整证据与限制见 implement.md 顶部。

2026-09-17 实施接续

用户明确要求借款尽快完成，沿本PRD与design既有个人出借人/CNY本金范围推进本地T1–T4，取代此前暂缓实施的优先级；不扩大为利息、备用金或通用付款。真实资料、余额和账户仍须正式录入核实，本地只用合成样例。风险与独立复核在交付/上线前保持未完成，不通过读取生产密钥或重跑旧恢复为本地开发解阻。

Goal

让财务能按已核实凭据查清公司向个人借入的未还本金，并完成申请、有权审批、网银付款、回单留存和业务本金核销。默认保留独立审批；本公司已授权、身份及借款范围明确的关联方还款，按 R3 采用财务经办与公司有权人的关联方确认。OA管理业务台账及付款证据，代账系统负责原负债科目记账，不把借款还本变成费用报销。

Background

• 用户提出历史两笔借入合并一次归还的真实需求；聊天提供的历史日期、金额和“本年无借还”尚未由本任务核验原始凭据，不据此创建真实余额或付款。
• 立项时仅有 reimbursement/travel_order 付款来源，创建依赖已有来源单；本任务后来新增借款还本来源，仍不开放自由填写收款人和用途的通用付款。
• 立项时建行用途/备注按报销生成，回单 OCR 及人工核对未覆盖借款。本地已有显式适配，实际材料的识别与银行接受性仍须分别验证。
• 本 task 于 2026-09-17 获准规划，独立于报销收尾任务；后续实施授权与证据见 design/implement。目前为 in_progress，本轮已本地实现关联方模式，不扩大真实录入或付款授权。

Scope

首期仅个人出借人（可为股东、非员工）的公司借入本金台账和人民币本金归还，沿现有建行付款支持范围；一张还款申请关联同一公司、同一出借人、同币种的一条或多条已确认借款，对应一笔银行付款。支持部分偿还，不建设任意用途的通用付款平台。

Requirements

R1 历史及后续借入登记

财务登记出借人、公司主体、借入本金、实际到账日期、协议/确认资料、原入账凭证及核对截止时点。历史登记与当前收款分开，不产生虚假的新增现金流。余额未经财务与代账确认时只能标待核实，不能用于还款；已在系统外偿还的本金须有依据并单列确认，不能重复冲减。出借人不必是员工，银行资料沿现有加密/授权查看/审计要求。

R2 余额与还款申请

列表区分未还本金、已占用待付款额、可申请额及核对截止日期，资料覆盖不全时不得回答“已结清”。财务选择借款及本次分配金额，正数、两位小数且合计等于付款额；不得跨公司/出借人/币种合并。并发申请不能超额，已付、取消及有银行在途的状态必须分别处理。

R3 有权审批与明确的关联方例外

财务创建并提交，沿付款批次完成决定，不新增重复的通用审批链。默认 independent 模式沿现有经理/CEO独立复核，排除制单/提交人和出借收款人对应的OA身份，无合格人时阻止提交。不得使用 admin 通配、虚建非员工出借人或按姓名猜身份绕过。

新增 related_party 模式，限定公司、真实个人出借人、其关联员工及授权覆盖的已确认借款。财务登记实际公司授权与范围，指定有权的马经理确认；不要求技术员工或第三名员工参与。还款创建时由服务端核定并冻结模式、授权版本和身份；客户端不能自行切换，历史独立批次不能自动转为关联模式。

马经理作出每个新决定时，须当前在职、有相应经理/CEO业务权限、具备覆盖该事项的公司授权；仅豁免其作为本笔收款人的利益关联。经办、提交、导出、证据上传、人工录入和提案冲突继续拒绝，按真实员工身份判断，同一人兼任角色也不能消除冲突。关联模式的经办入口提前禁止指定确认人参与这些经办动作；其公司授权确认或债权/收款声明不记作独立复核。

付款申请可由公司代表填写理由退回；退回决定与授权留痕不可改，原申请不得继续批准或导出。退回不直接释放占用，由财务按未发送取消规则取消后重新申请，不修改原申请的付款快照。

付款前核对当前权限、授权、版本与启用状态；付款后的原审批与出借人资格按当时快照判断。新的银行事实确认仍核对当前确认人的资格。停止新付款不抹掉历史授权、不阻止银行事实留存或符合条件的已付核销；停止后续对账决定单独记录。具体时点及最终动作检查见 design 顶部。

R4 付款与回单证据

审批只占用额度，不减少未还本金。财务在网银实际付款，用途为“还款”，短备注按借款年份/本金语义生成，受现有银行长度校验；详细原借款对应关系留在OA，不硬塞进银行备注。原件可先留存，但金额、币种、付款/收款账户、交易成功状态及唯一身份不满足时不得登记已付。

复用现有回单核对的自动匹配/人工例外边界，显式支持借款来源；真实样本未验证前不宣称真实识别已验收。普通回单直接沿已有 OCR 处理实际文件，不先向银行询问字段。OCR不清或不可用时，原件留存、经办录入和按 R3 模式作出的人工决定不能伪称机器核实或银行验真；明确失败、受理中、账户/金额不符及重复交易不得靠普通理由放行。独立模式排除收款人和提案人；关联模式仅豁免指定收款人关联，上传/录入/提案等经办冲突继续排除，读取及最终消费人工证据同样执行该规则。

R5 核销、异常与会计交接

只有符合既有付款登记证据门禁并由财务明确登记成功时，才在同一事务内占用交易身份、核销分配本金并更新付款事实；同一请求重试幂等，跨批次/跨报销复用交易拒绝。取消须满足相应安全取消或逐提交终态证据门禁；有导出或银行提交后，不能凭口头“没有付款”释放额度。银行状态未知/在途时不能直接释放后重付。付款已登记后的错误处置保留原事实，另审纠错，不删除或覆盖记录。

付款成功与代账记账分开，记录凭证编号/记账确认及材料交接，不由OA自动生成会计分录。材料包括原借入凭证、协议/确认书、余额核对、审批及还款回单；本金不要求费用发票，不进入费用报销统计或费用预算。关键材料按适用访问权限留存，历史余额/分配不得无审计改写。

R6 关联方模式的对账接续与留痕

R3 的模式同时作用于付款审批、提交清单、成功/失败归属、人工回单、银行终态、失败确认、SR补证、晚到成功、误报关闭和追回；需要人工决定的事项由财务登记、马经理作关联方确认，最终核销/释放/补记/解冻仍重验各自证据和资金条件。成功回单完全满足自动核验时，不增加一次无必要的人工回单确认。两人确认、时间相近、金额或账户相同均不能替代指令归属、终态或到账证据。

每次决定记录模式、公司授权及版本、实际决定人与关联身份、材料快照和理由；后续读取、重建、最终消费均使用同一语义。Q6保持两名独立复核人的现有合同，在关联模式下服务端拒绝发起、复核和释放，页面说明不可用；无可用终态证据仍保持占用。旧独立记录及报销/差旅权限不因此放宽。

2026-10-07 S4–S8 本地接续（历史时点）

用户要求沿已确定工作直接执行。S4–S8 的本地实现和验证继续推进，阶段证据在 implement 顶部；AC9–AC19 不因后端或合成测试通过而自动勾为整体验收通过。新银行事件均标明人工核对，不伪称真实银行/OCR 已验；生产查询、推送、部署仍未执行。

Acceptance Criteria

勾选表示该项已取得所要求的软件及流程证据，不代替 N5/N6 的真实材料录入与银行闭环验收。原勾选项保留独立模式基线，AC20–AC26 另有关联模式合成证据；AC8、AC27 的独立代码复核、固定候选门禁及本次部署证据现已补齐，既有回退限制继续有效。AC9–AC19 中一般“复核/确认”按 R3 区分独立复核与关联方确认，具体消费者见 design；AC12 的双独立复核不适用此转换。

• AC1：合成历史两笔借入可登记并确认余额；未确认/重复登记/无凭据不进入还款，历史录入不被统计成当天新增收款。

• AC2：同一出借人两笔借款合并一笔付款、部分偿还正确；超额、跨主体/出借人/币种、重复提交和并发占用均拒绝或幂等，金额用精确小数。

• AC3（既有独立模式）：财务不能自审，收款人即使持CEO/manager或多角色也不能批准自己的还款；无合格审批人、身份关联缺失/变动拒绝，无管理通配旁路。新关联模式的限定例外另按 AC20–AC27 验收，不以此勾选代替。

• AC4：审批/导出/上传回单均不会单独减少本金；处理中保持占用，确定失败/安全取消释放，明确成功登记与分配核销原子完成，数据库异常整体回滚。

• AC5：正确回单可匹配新来源，错金额/账户/币种、失败/受理、同额歧义、重复交易、晚到版本及人工自审分别受阻；真实样本未覆盖的自动识别仍明确待验。

• AC6：付款完成可追到原借款分配和会计交接状态；余额查询标明截止/核对状态，不把OA无记录说成银行无还款，不把本金计入费用。

• AC7：报销/差旅既有付款、独立复核、制单、回单和权限回归通过；PC/手机沿既有交互，机密字段默认脱敏，普通员工不能读全台账。

• AC8：迁移与回退影响、独立只读复核、恢复风险处置和发布前条件完整；本地合成通过不替代真实银行接受性或部署，真实录入/付款另批。2026-10-09 本次发布证据见 implement 顶部；未新增恢复演练或自动回退授权。

• AC9（对账，design 3.1/3.3）：制单导出与银行提交尝试分别落表并关联；提交清单须经相应模式的确认；确认失败只计未作废附件，但作废的成功或处理中回单仍按事实阻断；确认失败按批次冻结快照核对，出借员工离职不阻断原审批效力；新的事实决定仍须有当前合格确认人；一条指令的终态不能推定其他提交已结束。

• AC10（失败归属，3.1）：存在同金额候选时，确认失败须有已复核、写明覆盖哪些指令的失败归属；未确认时保持占用。

• AC11（银行终态释放，3.2；2026-10-07 补充：同一指令的终态事实可了结该指令此前的处理中回单，其他提交不能代替；最终取消释放的事务须重验全部条件，并与新提交、晚到回单串行；终态证据与付款回单分开存放，作废或被替换后不能继续作为依据）：每次已登记提交均有能唯一定位指令、经相应模式确认的终态证据，且无未解决的成功或处理中事实，才可转 confirmed_not_paid 并释放；对账单、截图、时间依据与等待期均不能单独放行；释放后禁止再导出。

• AC12（人工确认未提交，3.2a，用户 2026-10-06 确认支持）：仅独立模式在全部证据加两名不同的独立复核人满足时转 confirmed_not_submitted，记录与页面标为人工确认；人员不足或材料缺失时继续占用。关联模式不启用 Q6。

• AC13（冻结，3.5）：冻结按原因记录；拦截新申请及其他在途申请的复核与导出，不拦事实登记；误报经相应模式确认后关闭不补记；证据不确定继续冻结；全部原因关闭才解冻。

• AC14（晚到成功，3.4）：只增不改并标记原结论被推翻；按冻结快照与历史审批核对；覆盖已释放与已确认失败未释放；逐笔先处理占用冲突再按差额结清，余额列待追回；补记不生成可导出指令，整笔超额也完整记录；同一交易不能两次使用。

• AC15（追回，3.5）：凭到账证据经相应模式确认登记，支持部分追回；仅登记不解冻；本期不支持冲抵。

• AC16（存量）：历史批次保留已知的导出次数，新增“历史导出汇总”标明已知与待核实信息；它不是一次真实导出或银行提交，不能据此放行额度；上线前须核实生产存量（S0）。

• AC17（补证恢复，SR1–SR3；既有实现验证见 implement）：已确认失败或未付款且本金仍全部占用时，可补充有效证据并重新按相应模式确认；原结论与依据不可改，旧证据/复核可追溯；恢复不得重开付款、导出或改变本金，不适用于已释放/已结清、成功事实或 Q6 人工未提交。

• AC18（恢复批准有效性，SR2–SR4；既有实现验证见 implement）：材料、核验版本、提交清单、归属或同额候选变化使旧恢复批准失效；新建再撤回、换回同一流水号、撤回/驳回恢复均不能复活旧批准或回退原释放依据；补证后能重新送审，不永久卡死；当前确认人合格且不属于任何相关经办身份，关联模式仅例外允许指定收款人身份。

• AC19（最终恢复释放，SR3–SR5；后端验证见 implement）：确认与最终取消均满足 S3 全部条件及等待期；最终事务重验最新恢复批准与证据，释放、取消、消费批准、审计原子且幂等；与证据/提交/核验/候选变化确定性交错时不错误释放；成功事实转对账、未知继续占用。PC/手机完整操作与真实银行接受性分别验收。

• AC20（关联范围）：仅经登记确认的公司、个人出借人、关联员工及借款范围可新建关联模式还款；模式由服务端核定并冻结，伪造模式/授权/公司/借款、身份未核实或范围不符均拒绝；旧独立批次、报销与差旅不变。

• AC21（两人分工）：财务可合并经办角色；指定马经理可以代表公司确认本人的还款，但不能兼任本批经办/提交/导出/上传/录入/提案人。分别测试各冲突与多角色、多账号；不能把其从所有排除列表整体删除，技术员工始终无审批及敏感读取权限。

• AC22（真实留痕）：所有人工决定及审计记录模式、授权版本、确认人的关联身份和证据快照；详情、待办和最终证据重建一致，不把关联方确认显示为独立复核；已决定记录不可改、不可删除、不可事后换模式或授权。

• AC23（完整接续）：以财务和收款经理两个合成身份贯通付款、提交清单、成功/失败归属、人工回单、失败/终态释放、SR、晚到补记、误报关闭及部分/全额追回；确认入口、材料读取与最终消费均可执行。缺证、同额归属不明、冲突或重复交易仍拒绝，拒绝后本金、占用和冻结保持正确。

• AC24（Q6边界）：关联模式的 Q6 发起、双审及最终释放均由服务端拒绝，页面说明不启用；直接调用或伪装旧独立批准也不能绕过。原独立模式双审反例仍通过，无回单不能释放占用。

• AC25（资格时点与并发）：新申请/批准/导出校验当前付款授权；新的对账决定及最终释放校验当前对账授权；已付核销/已确认银行事实入账使用有效的历史审批与证据，不因停止新付款或原审批人事后离职而失败。新授权不能改写旧模式；授权停止、材料变化与确认/导出/释放按确定性交错验证，先后结果有明确语义。

• AC26（页面与访问）：电脑和手机以现有组件走通两人流程；财务无自审按钮，经理无经办按钮，必要材料按本批范围及用途审计读取；技术员工不获候选、待办、通知或材料。前端隐藏不能替代服务端鉴权。

• AC27（数据与回退）：仅新增型迁移，历史记录明确归为独立模式且不伪造授权；新字段、外键、模式/关联身份及不可变约束在数据库验收。新增关联决定后禁止不经评估降回不理解该模式的旧代码；最终候选重新验证并按规则只读复核，不沿用旧门禁宣称通过。数据库合成验收、独立代码复核及 beb9f02c 完整门禁已取得，生产已应用 82/82 迁移。

• AC28（员工选择，本地验收完成）：财务可从现有员工选择出借人并使用已有姓名、银行和账号，直接关联真实员工身份；不新建员工、不要求再次录入同一资料，列表与确认页只显示遮罩账号。借款所属公司明确，非员工路径不隐瞒已有员工身份。

• AC29（来源与权限，本地验收完成）：只有现有合格财务可以选择并关联；银行卡资料权限继续校验，不扩大员工或技术人员权限。缺资料、不可用银行或账号、越权及伪造客户端姓名/账户均拒绝；资料只在原员工维护入口补正。

• AC30（重复与版本，本地验收完成）：重复或并发选择同公司同员工复用明确的已有登记，不产生新员工或无声合并历史记录；预览至确认间来源变更时要求重新核对。已有出借人刷新保持既有锁序、版本、在途限制和审计；员工主档变化不改写已批准付款、已发生银行事实或本金。

• AC31（办理验证，本地验收完成）：合成数据贯通选择员工、登记历史借入、确认余额、登记公司授权及经理确认；电脑/手机入口和缺资料提示可用。验证来源变更、并发重复、无权限和旧快照保持的反例，不用真实员工资料或付款作为开发测试。

• AC32（单笔预填）：合成可读入账 PDF 正确预填金额、日期和唯一引用，选择公司/出借人后可核对保存；扫描 PDF 的受控 OCR 返回同样合同。文件中有多笔交易、歧义金额/日期或缺字段时，不取第一笔、不取最大金额、不补造值。

• AC33（确认边界）：识别和退出不产生业务借款或正式附件；保存后仅为余额待核实且带原件。未还本金、截止日、借款性质由财务确认，缺协议/余额核对材料时不能确认余额或申请还本，不生成付款或改写公司授权。

• AC34（主体与方向）：公司入账可预填，公司支出、明确失败/处理中、非最终回执、非人民币及多交易文件受阻；付款方同名、旧银行账号或主体不唯一时只提示人工核对，不新增身份、不更改员工/出借人账户，不放宽现有还款回单规则。

• AC35（失败可继续）：OCR 关闭、缺配置、超时、额度不足、字段冲突和本地无法提取文字均有可理解结果；未知可人工补录，已知矛盾不能靠普通确认消除。断言无虚构字段、无自动重试风暴，充分可读 PDF 不调用云 OCR。

• AC36（保存一致性）：保存成功同时存在一笔借款及对应 incoming 原件；相同请求重试仅返回原结果，换文件/字段复用请求键被拒；同公司同出借人的重复引用、相同原件及并发新入口保存不会生成重复可用借款。存储、附件或审计失败时正确补偿，不虚报成功。

• AC37（身份与原件绑定）：无财务权限、跨身份结果复用、令牌过期/篡改、确认前换文件及来源变更受阻；电脑/手机换文件、卸载及同文档换账号时取消旧请求，迟到响应不覆盖新表单或以新身份重发保存；保留同身份正常会话恢复。

• AC38（原流程兼容与隐私）：原手工登记、员工关联、非员工登记、三类材料余额确认、关联授权与还款路径仍通过相关回归；原件下载沿既有权限/用途/审计，无完整账号或原始识别 payload外泄。PDF/文件不安全或超限在持久化前拒绝。

• AC39（证据边界；第五轮独立复核 PASS_WITH_NOTES；2063ff1e 已发布，发布日志已核对、公网路由检查沿用发布会话回报；真实样本的姓名、账号、流水号未逐值独立核对，真实云 OCR 和登录后真实业务尚未验收）：完成单元、真实隔离 HTTP/数据库及电脑/手机浏览器验证，覆盖失败、并发和清理；完成涉及入口权限/保存流程的独立只读复核，受 inline 限制时明确待独立复核，不冒用旧结论。真实样本与云 OCR 可用性、公开发布分别验收，不以合成结果勾 AC5 或 N5/N6 实际业务完成。

Out of Scope

• 不处理利息、工资/分红、员工向公司借备用金、资本金、债转股、机构借款、外币、一般退款或债务冲销；仅保留本任务已定义的超额还款实际追回，不做冲抵后续本金。
• 不做银行直连、流水自动导入、AI自然语言财务问答、自动会计凭证/税务、跨系统重复审批或全量ERP。
• 不伪造报销单承载本金，不改现有报销一单一笔付款规则，不解冻其他低频模块，不引入新视觉设计体系。
• 不索取聊天中的完整账号或真实凭证，不读取/轮换生产密钥，不沿用旧恢复/部署/真实付款授权。

Test Plan

真实Fastify路由与隔离PostgreSQL覆盖资金、身份、并发和事务回滚；前端沿现有Vitest/Playwright验证PC/手机。独立模式保留合成财务、独立审批人、收款人的基线；关联模式使用财务与收款经理两名真实角色的合成身份，技术员工只作无权访问反例，不让实际员工参与财务复核。跨业务重复交易与报销回归单列；OCR沿真实识别/归一化/匹配链，仅替换云端返回，不用预签身份替代正式认证全链。关键资金守卫配定向变异和确定性交错，按 implement 的 RP1–RP4 执行。执行端承担软件验证，不让用户制造真实还款来代测。

Current Status

N5-P“原借入回单识别预填”已实施，经第五轮独立复核 PASS_WITH_NOTES 后，随 2063ff1e 于 2026-10-10 推送部署。补记时本地 HEAD 与 origin/main 一致；已有候选验证日志 PASS，部署日志确认应用发布与备份合同刷新完整通过，部署前后无待应用迁移、仍为 82 个。公网 /ready 版本、页面 200 和识别接口未登录 401 沿用发布会话回报，本次只核对本地版本及日志，未重新访问生产。登录后的 live smoke 在部署日志中明确跳过，真实业务办理尚未验收。

本轮只补任务记录。财务保存前仍需逐项核对原件并完成两项确认，尤其姓名、账号、流水号；真实云 OCR 未验收。员工授权翻页超时继续标记为根因未定，不以多轮回归通过推定已修复或已排除线上影响。详细证据和交接步骤见 implement 顶部。

员工选择阶段 AC28–AC31 已本地验收。用户在上一会话回报 45737ccb 已推送部署、公网检查正常、生产仍为 82 迁移，并明确尚未在线上登录办理新入口；本会话只核对本地版本和转交记录，未重新连接生产或复跑发布检查。下方及前述 beb9f02c、“未发布”等记录保留其历史时点，不能作为 N5-P 的验证证据。

整体任务保持 in_progress。2026-10-10 用户回报财务已完成真实借入录入，截图显示原借入凭据已有附件，但缺少协议/借款确认书和余额核对材料，当前卡在余额确认，公司代表授权尚待办理；本会话未访问生产独立核实。首笔真实还款的网银提交、正式回单、核销及会计交接尚未验收；AC5 及未覆盖的真实材料边界继续开放。无需重新索取已确认的借款事实或要求技术员工参与；真实录入和付款仍按各自授权执行，不从未还本金推定本次全额支付。缺材料的流程问题仅记入 implement，依用户指令暂不修改产品规则。

后续安排见 implement 顶部：N5 真实登记为业务优先项，授权翻页的确定性排查可并行，N6 按实际付款计划在 N5 后办理。首笔正常成功链路不一次关闭 AC5 或 AC9–AC19 的全部验收；异常分支及仅适用独立模式的 AC12 保留各自适用条件，不为验收制造真实异常交易。

2026-10-08 N1–N2 完成时点（历史记录）

N1–N2 在 ce11dea9 基线上完成本地实现和主会话检查，31 项改动未提交，无新增迁移。最新验证为 82 个迁移、116 组借款 HTTP、9 组数据库约束、18 组关联电脑/手机操作、38 组共享回单数据库/真实认证及 24 项共享报销页面限定重验通过；回单/报销最新定向 292 项通过，9 个资金守卫变异全部捕获。服务端全量为 4554 通过、1 项既有可选跳过，随后合成数据及零页详情的改动由上述最新定向覆盖，不虚报重新全量。Prisma、前端类型/构建及合同检查通过，准确时点和回执见 implement 顶部。

六份真实材料的本地分类及既有正式支出样本的内存人工录入预验已完成；未用真实借款执行核销，也未验证真实银行提交对应。当前不用用户补材料。独立代码复核、新候选正式门禁、获准发布/真实台账与授权登记、首笔真实还款闭环仍未完成；AC5、AC8、AC27 及整体业务验收不据本地结果勾选。原候选的正式门禁不覆盖当前差异，没有本轮提交、推送、部署、生产访问或真实写入。

关联方模式收尾记录（历史时点，最新状态见上文）

本地已有 A/B/C、S1–S8、SR恢复及电脑/手机界面，本轮另完成关联方模式 RP1–RP4 的实现与可执行验证，已获准本地提交及新候选正式验证。最新借款专项为82迁移、HTTP 109、浏览器33、数据库约束9组通过；关联模式单列14组HTTP及电脑/手机各7组浏览器，13个有效守卫变异均捕获。报销付款、付款权限和导航35项通过，现行差旅冻结保护另2项通过；一次误选封存差旅整链的403失败保留，未恢复差旅权限。服务端全量4519通过、1项原有跳过，后续小改的77项定向验证通过，详细先后和证据见implement。AC20–AC26仅完成本地合成验收；AC5、AC8、AC27及其余整体业务验收保持开放。

较早候选 4c37fcee 的正式门禁 PASS 只证明旧独立模式；本轮提交后单独生成 verify-candidate 回执，不提前宣称通过，主会话检查也不等同独立代码复核。不得以测试数字推定真实银行接受性或生产已经应用。

生产曾于2026-09-27上线早期版本；上述后续本地提交尚未推送或部署。2026-10-07 22:08–22:09获准只读核实时，OA借款相关记录为0，已应用73迁移；这不是银行/线下无付款的结论，发布前仍需重新获准核对存量及迁移差集。人员条件现已明确为本节两人安排，独立模式无人可办理本笔还款；后续为本轮独立代码复核、真实材料及授权录入验收、固定候选门禁和获准发布，不再将关联模式、S8或SR列为未实现。

Planning Status（历史时点，已由顶部实施接续替代）

本task已形成PRD/design/implement待审方案，本日追加源码消费者地图与T1–T4技术切片，无产品实现。实际借款余额、收款账户、审批人资格及银行样本属于录入/上线前的证据门禁，不把聊天转述视作已核实。08-23关键恢复及09-05治理的准入判断见09-08顶部优先级表；未取得本task方案实施批准前不得start。无必须现在向用户索取的秘密或真实资料。