借款出借人线上确认借款并以站内通知直达(09-17-company-loan-principal-repayment)
- 新增出借人确认声明:财务发起,出借人本人查看原件后确认或退回;快照与决定不可改删,金额、日期、原件或身份变化后整组失效 - 余额确认接受纸质协议或有效线上声明二选一,代账余额核对材料仍必需;声明与公司代表授权分离 - 普通员工无常驻入口,财务发起后仅通知对应出借人并直达确认页 - 新增迁移 20261010010000_loan_lender_acknowledgements(仅新增三表) - 测试:单测、隔离 HTTP/浏览器、完整借款回归;独立只读复核无阻断;同步发布记录与操作手册 Co-Authored-By: Claude Opus 5.5 <[email protected]>
这个提交包含在:
@@ -1145,6 +1145,12 @@ await canReadReimbursementBusinessFact(prisma, reimbursement, employee.id);
|
||||
|
||||
- `09-17-company-loan-principal-repayment` adds the explicit `loan_repayment` payment source: one retained repayment/batch/item, multiple allocations to confirmed same-company/lender/CNY loans. Preserve original principal and confirmed opening evidence; Decimal reservations and settlements must not exceed opening outstanding principal. SQL checks/deferred triggers complement locked application validation.
|
||||
- Loan management requires an explicit finance/finance_mgr role plus loan.manage. Independent review requires active manager/CEO with review permission and excludes maker, submitter and lender OA identity; admin wildcard cannot replace these identities. External lenders require explicit verified no-OA identity. Manual account changes revoke identity confirmation and invalidate old unpaid snapshots; explicit employee-source refresh renews confirmation under the checks below.
|
||||
- `LoanLenderAcknowledgement` is the lender's declaration, separate from company-representative authority. Finance proposes 1–50 unconfirmed loans for one verified employee lender/company, freezing principal, opening balance/date, incoming originals and identity versions. `loan.acknowledge_own` permits only the frozen employee's own records/originals/decision; manager or administrator status cannot substitute for that identity. Keep the finance maker distinct, originals checked on confirmation, strict request-key/hash binding and audit atomicity.
|
||||
- Header, scope snapshots and the single confirm/return decision are immutable. SQL triggers invalidate the whole group permanently after any member's material terms, incoming original or lender association/version changes; restoring source values cannot reactivate it. Additional accounting evidence, balance confirmation and ordinary loan version increases do not invalidate. Returned/invalid statements can be reissued; overlapping current pending/confirmed scopes cannot. After balance confirmation, reissue is allowed only with invalidated declaration history for that loan; never rewrite the original balance confirmation, loan version or terms. Service, SQL scope guard and `lenderAcknowledgementRenewable` UI projection must agree. Purely paper-confirmed loans do not gain first-time online declaration scope.
|
||||
- `assertEvidenceComplete` accepts paper agreement OR a valid confirmed declaration. Incoming originals, accounting reconciliation and required historical-repayment adjustment evidence stay mandatory at balance and repayment consumers. Balance confirmation must lock lender then loan, reread the lender association and evidence, and refuse after a concurrent invalidation; locking only that loan misses sibling-original and identity changes. Declaration writes lock lender → sorted loans → declaration → employee (`FOR NO KEY UPDATE`). Preserve existing payment-batch lock order.
|
||||
- Declaration-scoped downloads expose only frozen incoming originals after current source and physical digest checks, with purpose, audit and no-store; never expose accounting attachments or other loans via this scope. JSON POSTs through `apiRequestBlob` must explicitly set `Content-Type: application/json`. UI requests are actor-scoped and cancellable; a late 401 cannot replay an old decision under a new account. Ordinary employees have no permanent company-loan entry in workspace navigation, NavLinks fallback or MobileMePage; keep own-only route access independent of navigation visibility. Finance and company representatives retain their existing entries.
|
||||
- Proposals create one `loan.lender_acknowledgement_requested` in-app notification for the frozen lender employee, in the same transaction as the declaration and audit. Idempotent retries do not create another notification, and a notification write failure rolls back all three. Keep copy free of lender names, amounts, bank details and originals; do not add this type to IM support or external delivery/outbox. Desktop/mobile notification targets use `loan_lender_acknowledgement` and the declaration ID to open details via `lenderAcknowledgementId`, independent of the list page. The URL ID is the single source of current selection and overrides proposal mode; ID changes clear drafts/confirmation state and cancel old requests. Existing ownership and invalidation checks still govern historical links.
|
||||
- Verify declaration contracts with `RUN_ISOLATED_LOAN_ACK_ONLY=1` on the isolated loan runner and `RUN_ISOLATED_LOAN_BROWSER=1` for desktop/mobile originals, confirm/return, accounting requirement and actor-switch cancellation. Retain full-loan regression. Migration `20261010010000_loan_lender_acknowledgements` adds history without backfilling acceptance; preserve it on rollback. An older application cannot consume online-only agreement evidence, so post-use rollback requires compatibility planning.
|
||||
- Employee-source preview/link/refresh additionally require `employee.bank.read` or `employee.bank.manage`. `loanLenderEmployee` reads the active employee, supported bank and encrypted account on the server; the strict write body carries employee/company IDs, source version and an explicit confirmation, never client-supplied account/name replacements. A source version binds actual source fields, ciphertext and the chosen debtor, not only `updated_at`. Missing, unreadable, stale or unsupported sources reject without a partial lender/audit write; previews expose masks only.
|
||||
- Same-company employee association includes archived/history rows in duplicate checks, including the old identity-confirmation entry. Reuse a unique matching lender; reject ambiguous links and require explicit refresh for different data. Existing-lender actions lock lender before sorted employees. New creation never locks an existing lender after employees: finish and reacquire in the correct order if a link appeared. Use employee `FOR NO KEY UPDATE` to serialize association/source edits while allowing audit/actor FK `KEY SHARE`; `FOR UPDATE` can deadlock against another employee's refresh/audit. Persist and serialize each actor's request-key binding for both creation and reuse, with audit in the same transaction.
|
||||
- Explicit employee refresh rejects reserved repayments, checks source/identity/account versions and advances both lender versions with renewed finance identity confirmation. This invalidates old company-representative grants without changing principal or historical payment snapshots. Employee-linked lenders cannot use the manual account PATCH; employee-master edits alone never rewrite the loan copy. Verify the actual audit-FK interleaving, duplicate/legacy races, refresh versus repayment creation, audit rollback and reverse mutations using `RUN_ISOLATED_LOAN_EMPLOYEE_ONLY=1` and optional `RUN_ISOLATED_LOAN_EMPLOYEE_MUTATIONS=1` on the isolated loan runner; retain the original full-loan regression.
|
||||
|
||||
@@ -1,4 +1,17 @@
|
||||
## 2026-10-09 N5-P 原借入回单识别预填设计(待批准实施)
|
||||
## 2026-10-10 N5-C 出借人在线确认设计
|
||||
|
||||
1. 新增专用声明、借款快照及单次决定三张表,记录固定的公司/出借人/关联员工、财务发起人、请求键、日期、金额、原件 ID/摘要和版本。声明与范围在一个事务内完整成立,数据库约束保障范围一致及历史不可改删;失效只允许从有效到无效,保留原决定。
|
||||
2. 快照读取数据库当前值,客户端仅提交借款 ID/版本及出借人身份版本。限定同公司同出借人、身份已核实、有入账原件;首次发起限定尚未确认期初余额,已确认余额仅在有失效在线声明历史时开放重发。重发不修改借款版本、金额、截止日、原余额确认人/时间、状态或代账引用。同一有效范围的待确认/已确认记录不重复发起,返回已存在提示;退回或失效后允许新请求。多笔声明是一组,任一关键源变化使该组失效。
|
||||
3. 发起/决定按“出借人 → 排序后的借款 → 声明 → 人员”取锁,重读来源;决定必须为冻结的关联员工本人且不是发起人。新请求及决定均有幂等和审计原子性。数据库在借款条款、入账原件或出借人关联/版本变化时自动失效该组,不以普通 `loan.version` 增量推定失效,避免确认余额和补代账材料误伤声明。
|
||||
4. 新 API 提供财务全量及本人范围内的声明列表、详情、发起、确认/退回;详情只返回冻结明细及原件元数据。原件沿既有下载校验、用途及审计,新增声明范围绑定,不能借此读取整个台账、代账文件、他人原件或当前关联身份已变化的原件。声明请求和原件引用均不写入浏览器长期存储。
|
||||
5. 公司借款页增加“出借人确认”,与“公司代表授权”明确分开。普通员工只读/办理自己的声明,不需要经理身份;根据发布前入口调整,普通员工通过站内通知进入,常驻电脑导航/后备导航/手机“我的”仅供财务和公司代表使用。本人的路由及接口权限保持。沿现有组件/样式实现;查询按账号隔离,新写动作及下载支持取消,账号变化中止旧请求,保留同身份令牌恢复。
|
||||
发起声明事务复用 `createNotifications`,仅为冻结的关联员工创建一条 `loan.lender_acknowledgement_requested` 通知,目标类型为 `loan_lender_acknowledgement`、目标 ID 为声明 ID;通知文本不复制姓名、金额、账号或原件内容。不调用 IM/outbox/企业微信派发,也不加入外部消息支持类型。通知与声明/审计同事务提交,幂等返回不再次通知。电脑和手机通知链接分别指向公司借款页的 `lenderAcknowledgementId` 参数,按账号隔离加载单条详情并直接打开;不依赖其位于列表第一页。URL 为当前详情的单一来源,非空 ID 优先于发起草稿;切换声明或浏览器返回时清除旧草稿、核对状态及错误,并取消旧请求。失效/他人记录继续沿现有详情服务校验,不凭通知恢复权限或效力。
|
||||
6. `assertEvidenceComplete` 的协议类依据接受有效声明,余额确认与后续还款消费者统一使用;有效性既看决定与失效状态,也重比当前条款、身份和原件。余额确认先读出借人 ID,再按出借人 → 借款取锁、重读并核对关联,使同组另一笔原件或身份变化与材料消费串行;不能仅锁当前借款后消费旧对象。纸质依据继续可用,原件/代账/必要调整证据不放宽。出借人确认不推进余额、授权、付款状态。
|
||||
7. 增量迁移预计从 82 到 83,无存量回填或生产操作。回退保留新增历史表,不回删确认记录;旧应用不认识在线替代材料,线上已消费在线依据后不得声称可无影响回退到旧版,应使用兼容修复或先核实纸质依据覆盖。发布与生产迁移仍另行批准。
|
||||
|
||||
验证沿现有隔离 PostgreSQL/HTTP/browser runner,新增定向 fixture;真实账号、回单、生产数据和外部服务不用于开发验证。重点验证本人越权、快照不可变、改回旧值不复活、必要材料不放宽、决定/变更并发及审计回滚。完成后启动只读 reviewer;inline 主会话自行实施和检查,不派 implement/check 子代理。
|
||||
|
||||
## 2026-10-09 N5-P 原借入回单识别预填设计(历史规划记录,已实施发布)
|
||||
|
||||
### P-A 现有能力与方案选择
|
||||
|
||||
|
||||
@@ -1,4 +1,138 @@
|
||||
## 2026-10-10 N5-P 第五轮独立复核通过(待提交授权)
|
||||
## 2026-10-10 N5-C 发布前入口调整(本地验证及只读复核完成,未提交、未发布)
|
||||
|
||||
用户复核提出普通员工常驻入口无必要,并给出“只对已关联出借人的员工显示”或“发起后通知直达”两种方案、委托本会话取舍。本次选择第二种,沿已批准的本人确认功能收敛入口,复用现有 OA 站内通知。范围包含通知创建和声明定位,不能只删导航;不新增通用待办、外部消息或迁移。
|
||||
|
||||
- [x] E1:恢复财务/公司代表常驻导航边界,本人路由权限保留;声明发起事务只给对应本人创建一条站内通知。
|
||||
- [x] E2:电脑/手机通知链接直接打开对应声明,使用现有按账号隔离的详情与取消请求逻辑,不依赖列表首屏。
|
||||
- [x] E3:定向通知幂等/事务回滚/本人可见、导航及电脑手机通知点击验证,补只读复核,更新手册/spec。
|
||||
- 发布安排:建议本次生产结构迁移前做腾讯云手工快照,实际快照及发布操作待明确批准;发布候选须只允许 `20261010010000_loan_lender_acknowledgements` 这 1 个待应用迁移,发布后核对 83/83。迁移除新增三表外,还包含历史不可修改/范围完整性约束以及挂到既有借款、出借人、原件表的来源失效触发器;没有历史余额回填,不能简写为“只新增三张表”。当前生产未访问。
|
||||
- 两处既有待查:追回到账和员工授权翻页失败根因仍未定,保留失败证据与确定性复现要求,本次不混入根因排查或宣称修复。后续按独立排查范围安排;原完整 r4 的 216 项结果仍为入口调整前证据,不能直接充当修改后回执。
|
||||
- 本次仍无提交、推送、部署、生产写入或外部消息授权。
|
||||
- 首轮入口定向 `entry-browser-r1.log`:83 迁移、17 组 HTTP 均通过;浏览器已从通知打开声明弹窗,随后原登录 helper 还要求通过可访问角色查询找到弹窗后面的“公司借款”标题,Radix Dialog 正确屏蔽背景后该断言失败。仅将通知直达分支改为断言当前“出借人借款声明”弹窗标题,财务普通登录仍检查页面标题;失败日志保留,随后 `entry-browser-r2.log` 的 17 组 HTTP、16 组电脑/手机操作和 9 组数据库检查通过。
|
||||
- 本轮只读复核发现 URL 声明 ID 被发起模式遮挡:打开声明、关闭、再打开发起表单后,浏览器历史返回声明 URL 时仍显示发起。改为非空 URL ID 优先显示详情,并清除发起草稿/确认说明/勾选/错误、取消旧请求。新增电脑/手机同 SPA 场景:非空出借人、已选一笔和说明的草稿 → A → B → 浏览器后退 A → 重开发起,断言明细及草稿清理。复核方补查产品与测试、核对最终 r5 日志,结论 `REVIEWED_NO_BLOCKER`;复核方未改文件、未写库,测试运行结果沿用主会话回执,不冒称独立重跑。
|
||||
- `entry-browser-r3.log`:83 迁移、17 组 HTTP 通过,浏览器登录时的通知列表断言失败,未计通过。测试原谓词只匹配 `/api/notifications` 路径,而顶部栏同时请求未读计数列表;该次未采查询参数。`entry-browser-r4.log` 保留原谓词并增加 query/items/mode 的合成诊断,稳定复现捕获 `?page=1&pageSize=1&unreadOnly=1`、只有一条结果的顶部计数响应,确认为测试等待对象歧义。现严格匹配通知页 GET/200、type、page=1/pageSize=20/unreadOnly=0,保留原目标 ID、真实点击及 URL/弹窗断言;未改业务、未增加重试/超时。r3/r4 失败日志和合成截图保留。
|
||||
- 最终 `entry-browser-r5.log`:新进程使用最终业务代码和 `client-build-entry-r2.log` 构建,退出 0;83 迁移、17 组 HTTP、18 组电脑/手机操作、9 组数据库检查均通过,测试自有资源清理通过。不累计 r2/r5 重复项目。覆盖通知收件人/幂等/并发/失败回滚、无外部派发、普通员工无常驻入口、实际通知点击定位、上述同 SPA 历史切换、原件下载/本人确认/退回、代账材料门槛、历史失效通知/续办、同身份刷新及跨账号请求取消。
|
||||
- `unit-entry-r1.log`:导航 12、权限 14、通知接口 19,合计 45 项通过;最终前端类型检查/构建、服务及 fixture 语法、错误理由和 UI 规则检查通过。任务上下文、流程基线、Trellis 治理、敏感内容及差异检查通过;文档登记 0 错误、保留既有 22 份未登记文档的 1 条告警。手册及 backend spec 已同步站内通知与 URL 选择合同。
|
||||
- 本轮只做入口范围定向验证,没有重跑完整借款回归或最终发布门禁。此前完整 r4 的 216 项只能作为入口调整前证据。下一阶段待用户明确授权本地提交,再对最终提交运行完整发布门禁;生产快照、推送、部署及仅 1 个生产迁移仍需各自明确批准。真实 N5/N6、默认值暂停项及历史失败根因待查继续保留。
|
||||
|
||||
## 2026-10-10 N5-C 出借人在线确认(入口调整前本地实现与验证完成)
|
||||
|
||||
用户已明确批准收窄方案,复用本任务 AC40–AC44。基线为 `2063ff1e`,开始时已有 `prd.md`/`implement.md` 的发布补记及待办未提交,予以保留。仅本功能恢复实施,默认余额/日期待办仍暂停;无提交、推送、部署、生产写入及对外消息授权。
|
||||
|
||||
- [x] C0:核对材料消费者、借款/身份/附件锁序、本人访问边界,更新 PRD/设计;确认需新增专用声明数据,而非复用公司代表授权。
|
||||
- [x] C1:增量迁移、不可变快照/决定、单向失效及服务端本人权限/事务/幂等。
|
||||
- [x] C2:财务发起与出借人确认/退回界面、受限访问及原件查看,保留纸质路径。
|
||||
- [x] C3:接通余额确认和还款材料判断;隔离 HTTP/数据库并发、电脑/手机及纸质回归。
|
||||
- [x] C4:Prisma、后端语法/定向测试、前端类型/构建、错误码/治理检查;独立只读复核并修复阻断项。
|
||||
- [x] C5:更新证据与交接,说明本地验证和生产发布边界,不自动提交或部署。
|
||||
|
||||
### 当前实现与验证记录(本地,最终完整回归 r4 通过)
|
||||
|
||||
- 新增专用出借人声明、借款快照及单次决定三表。本人账号与财务经办分离,声明与公司代表授权分离;快照/决定不可改删,任一来源变化使整组永久失效。服务、触发器及 UI 同时支持“已确认余额且有失效声明历史”的续办,禁止借此改写借款或原余额确认;纯纸质已确认借款不开放首次线上声明。
|
||||
- 余额确认与后续还款材料消费者接受纸质协议或有效在线声明二选一,其他材料要求不变。新增第 83 个迁移仅在合成隔离数据库执行;生产仍为 `2063ff1e`/82 个迁移。
|
||||
- 独立只读复核:`review_lender_ack` 首轮发现余额确认只锁借款造成并发失效遗漏、原件下载 JSON 类型缺失,两项均修复;第二轮无阻断(浏览器待验)。随后主会话发现已确认余额后的声明续办缺口,复核方确认,按上述最小历史范围修复;最终续办复核为 `REVIEWED_NO_BLOCKER`,最终 `browser-r3.log` 已补齐电脑/手机续办与实际导航验收。复核方未改代码、未写数据库、未读取真实材料。
|
||||
- HTTP `http-r3.log`:15 组专项和 9 组既有数据库约束通过,含身份/同组原件并发失效的实际锁等待、事务审计失败回滚、相反决定并发、原件/真实 employee-refresh 后重发、退回重发、部分组续办、原借款整行不变、旧声明不复活、公司授权仍需重办。83 迁移全部应用成功,隔离容器无网络/持久卷。
|
||||
- 浏览器最终 `browser-r3.log`:新进程使用最终业务代码与 `client-build-r4.log` 构建,15 组 HTTP、电脑/手机合计 14 组操作及 9 组既有数据库约束全部通过。实际从电脑导航/手机“我的”进入,原件下载 200、本人核对/确认、代账材料拒绝后上传并确认余额、退回重发、已确认余额后的声明续办、同身份令牌刷新、同 SPA 切换账号后旧请求取消且无重发均覆盖。早一轮 `browser-r2.log` 的 10 组仅为中间证据,不与最终 14 组累计。
|
||||
- 最终入口补查:普通员工直达页可用,但旧导航的财务角色筛选仍隐藏入口。补齐服务端 workspace role gate、客户端 NavLinks 显示/后备项及手机“我的”链接,例外仅限公司借款及 `loan.acknowledge_own`。最终只读导航复核无阻断;`unit-navigation-r2.log` 的 12 项通过,明确不授予 `loan.manage`,付款/应付入口继续隐藏。早期完整回归启动早于本次导航修复;最终 `full-loan-r4.log` 使用修复后的代码,实际导航点击另由最终专项 `browser-r3.log` 覆盖,不把分轮证据混称一次全量。
|
||||
- 单测:`unit-ack-r2.log` 新声明材料/续办 28 项;`unit-related.log` 权限、导航和公司代表授权 64 项通过(导航后续 12 项重验,不重复计数);错误理由 `unit-errors.log` 923 项通过。合计覆盖 1015 项,其中本功能新单测 28 项。前端最终 `client-build-r4.log` 类型检查与构建通过;Prisma validate、错误码合同、UI 规则、语法及差异检查通过。此后仅改测试断言/采证和文档,不重复构建未变的前后端业务代码。
|
||||
- 最终完整借款回归 `full-loan-r4.log`:退出 0,83 迁移通过,去重后 216 项(HTTP 150、浏览器 57、数据库约束 9),测试自有资源清理通过。45 项原借款浏览器汇总包含关联方 18 和员工 8,不能再次累加;本功能在完整轮次为 HTTP 15、电脑/手机浏览器 12。专项 `browser-r3.log` 的 14 项比完整轮次多电脑/手机实际导航各一项,作为补充证据列出,不和完整 216 重复累加。
|
||||
- 失败保留:`http-r1.log` 未指定已有 BIFF8 Python 导致导出不可用,修正测试环境后 `http-r2/r3` 通过;`browser-r1.log` 新弹窗没有显式关闭按钮,补现有 DialogFooter 按钮后重跑通过;原余额弹窗按既有 Escape 方式退出。实现期间错误码检查曾拒绝动态工厂,已改为显式登记的错误工厂,后续两次合同检查通过。没有放宽业务断言或增加重试掩盖失败。
|
||||
|
||||
- 完整回归首轮 `full-loan-r1.log` 在既有“登记追回到账”浏览器步骤失败,空 alert 日志不足以确定根因,不宣称旧问题已修复。测试原来按当时选项数量取最后一项,现改为捕获上传响应中的具体 evidenceId、等待该选项并断言选中,同时增加提交前无效控件与失败截图/按钮状态采证;不改业务、不增加重试或超时。旧普通员工整页 403 验收改为仅本人声明可见、台账入口和财务数据请求均不存在,服务端台账 403 仍保留。上述测试调整已由复核方只读检查,无放宽权限/材料断言,但不能据此证明首轮失败根因。
|
||||
- 完整回归 `full-loan-r2.log` 仅记录迁移、员工 HTTP 和 S4 阶段后进程被终止,退出码 143,无完整结果,终止原因未定,不计通过。
|
||||
- 完整回归 `full-loan-r3.log` 在关联方电脑浏览器的普通技术员工 `waitForURL(/403/)` 处超时。失败采证 `artifacts/qa-layout/payment-feedback-loan-slim-20260917/browser-REBg2n/failed-desktop-2.json` 显示员工已在公司借款页、仅看到本人声明,根因是旧“普通员工整页 403”断言尚有一处漏改。只调整 `company-loan-related-browser.cjs`:本人声明空列表可见、无财务/授权操作及 tablist,登录前开始监测并断言零台账/出借人/还款/公司授权接口请求;保留技术员工无还款通知和公司授权停止、服务端越权 403 检查。复核方补查确认未削弱财务/公司授权隔离,无阻断项;完整 `full-loan-r4.log` 随后通过。本轮为不同的确定性测试合同过期,不据此关闭首轮追回到账或既有员工授权翻页根因待查项。
|
||||
|
||||
### 收尾与交接边界
|
||||
|
||||
- 本功能 AC40–AC44 为本地合成验收完成,父任务仍为 `in_progress`。真实 N5/N6、既有翻页问题和暂停的登记默认值待办仍开放;首轮追回到账失败原因为未定,r4 通过不代表已查清。
|
||||
- 操作顺序已写入现有《试运行与自动化验证手册》:财务发起 → 出借人本人核对原件并确认/退回 → 财务补齐代账材料及必要的已还本金依据、确认期初余额 → 单独办理公司代表授权。只替代协议类材料,不自动确认余额或批准付款。
|
||||
- 收尾任务上下文、流程基线、Trellis 治理、敏感内容、文档登记及差异检查通过;文档登记仍为 0 错误和既有 22 份未登记文档的一条告警,不扩展治理范围。回执位于本证据目录的 `*-closeout*.log`。
|
||||
- 未运行全服务端测试套件或最终发布门禁;本轮结果不能代替后续最终提交的发布候选验证。没有提交、推送、部署、生产迁移或真实业务写入;新增第 83 个迁移仅本地验证,发布仍需单独授权,生产仍为已发布的 `2063ff1e`/82 迁移。
|
||||
|
||||
证据目录:`artifacts/qa-flow/loan-lender-ack-20261010/`。复现命令(`PAYMENT_ORDER_PYTHON_BIN` 使用本机已备好的锁定 BIFF8 环境,不提交真实路径/凭据):
|
||||
|
||||
```sh
|
||||
cd server && npm run prisma:validate
|
||||
npm test -- tests/unit/services/loanLenderAcknowledgement.test.js
|
||||
npm test -- tests/unit/services/loanApprovalPolicy.test.js tests/unit/constants/permissions.test.js tests/unit/workspaceSettings.navigation.test.js tests/unit/permissions.entity.test.js
|
||||
cd ../client && npm run build
|
||||
```
|
||||
|
||||
根目录专项:`RUN_ISOLATED_LOAN_DB_TEST=1 RUN_ISOLATED_LOAN_ACK_ONLY=1 node scripts/qa/test-company-loan-db.cjs`,电脑/手机另加 `RUN_ISOLATED_LOAN_BROWSER=1`;完整借款回归移除 `RUN_ISOLATED_LOAN_ACK_ONLY`。不使用真实用户、回单、云 OCR 或生产连接。
|
||||
|
||||
## 2026-10-10 真实办理卡点:历史借款缺少协议和余额核对附件(历史反馈,后续方案见上节)
|
||||
|
||||
用户回报财务已完成录入,随后在“借款材料与余额确认”页面反馈所需材料没有。截图显示原借入凭据已有附件,“协议或借款确认书”“余额核对材料”“系统外已还本金依据”栏目未见附件。本次未访问生产,不保存截图中的原始文件名或银行信息;该记录是用户办理反馈,不宣称已独立验收真实台账。
|
||||
|
||||
- 当前规则核实:确认期初余额必须有协议/确认书、原借入凭据、余额核对材料三类有效附件;仅在未还本金少于原始本金时才额外要求系统外已还本金依据。不能把页面列出四种上传入口解释为所有借款都必须上传四份材料。
|
||||
- 实际卡点:已有银行回单,但缺少协议/确认书及余额核对附件,现行流程无法完成余额确认,后续公司代表授权范围也无法选择尚未确认余额的借款。N5 为“用户回报已录入,余额及授权尚待完成”,不再笼统记为尚未录入。
|
||||
- 待讨论的改进方向:为无历史协议的真实借款提供当下形成的借款事实与余额确认记录;可评估一份记录同时覆盖借款性质、原件引用、截至日余额和核对依据,或在 OA 内形成等效的具名确认与审计。不要求补造当年协议或把银行入账回单视为未还本金证明。代账核对是否已发生、如何留存引用以及与公司代表确认的分工,须在方案中明确,不能直接将缺件校验删除。
|
||||
- 状态:沿用用户“先记录问题,先不要修改”的指令。本轮只补任务记录,不改产品规则、不执行真实确认、不补写虚构材料,待用户决定后续处理方式。
|
||||
|
||||
## 2026-10-10 待改进:借入登记默认值(仅记录,暂不实施)
|
||||
|
||||
用户在登记页面提出:“登记时应该默认未还金额为全额,日期为当日”,随后明确要求“先记录问题,先不要修改”。本次只读检查了现有入口,没有修改业务代码或测试脚本,也没有运行业务测试。
|
||||
|
||||
- 当前问题:截图所示“上传回单登记借入”的“核对日未还本金”和“余额核对截止日”没有默认值,需要重复填写;原手工“登记借入”入口也没有这两项默认值。
|
||||
- 期望行为:未还本金默认等于本笔原始本金全额;余额核对截止日默认登记当天,按项目北京时间口径。两项仍可人工修改。
|
||||
- 日期范围:此处“当日”指余额核对截止日,不替换回单上的实际到账日期。
|
||||
- 后续实施需保持:人工修改的余额和截止日不被后续识别覆盖;换回单或重新登记时避免沿用上一笔余额;默认值不代表余额已核实,保存后的“余额待核实”和原有确认流程继续保留。
|
||||
- 状态:仅登记待办,暂不修改产品;收到用户明确恢复实施的指令后再处理。两个登记入口的一致性及针对性验证届时一并核对。
|
||||
|
||||
## 2026-10-10 发布后的后续工作(待执行清单)
|
||||
|
||||
本次按用户要求梳理,复用当前任务,不新建计划系统。产品当前版本为 `2063ff1e`;下表是工作安排,不代表已执行真实录入、付款、技术修复、提交、清理或归档。发布记录及本清单仍未提交,父任务保持 `in_progress`。
|
||||
|
||||
| 顺序 | 工作与负责人 | 启动条件及完成标准 |
|
||||
| --- | --- | --- |
|
||||
| 1:业务主线 N5 | 财务登记真实台账,马经理确认公司代表授权 | 财务从员工中选择并创建/复用出借人,分别上传两份历史借入回单;核对公司、双方姓名/账号、金额、到账日期、流水号及出借人建议,补未还本金与截止日,完成两项确认。原件随借款保存,随后补协议、余额核对材料及代账引用,确认期初余额;登记已有公司代表权及覆盖范围,由马经理确认。完成标准为两笔台账与原件、余额依据及有效授权均可追溯,不新增虚假现金流。真实录入由有权人员办理,代理代录另按授权执行。 |
|
||||
| 2:技术排查,可与 N5 并行 | 开发确定性复现授权对话框翻页超时 | 复用本任务,先形成局部排查方案。隔离环境构造超过 30 个符合列表条件的出借人,明确目标位于第二页或以后;电脑/手机均断言实际翻页、请求和选项渲染完成,再选择目标并完成授权。留存失败响应、时序及脱敏截图,区分等待竞争、服务端响应和界面问题。仅修改等待方式或未触发该分支的通过不能结案;若实际办理遇到,提升优先级。 |
|
||||
| 3:业务主线 N6 | 财务申请、网银提交及代账交接;马经理按公司代表身份确认 | N5 完成后,按真实付款安排明确本次金额、逐借款分配及日期;申请 → 确认 → 导出 → 实际网银提交并登记提交详情 → 正式付款回单核验/必要人工确认 → 核销 → 代账交接。以本次已付本金和可定位的银行交易为验收依据,不从余额推定全额还款,不为测试制造付款。扫描付款回单按付款路径的人工依据与确认规则办理。 |
|
||||
| 4:技术优先项 | 开发评估将回单重检的文件读取/PDF 解析移到全局锁外 | 沿 N3 已记录的 P3 优先顺序设计;锁内保留原件摘要、版本、权限及全部状态重验。用重检与认领/人工核验/执行并发、附件作废/换版等反例证明不使用过期结果,再独立只读复核。工作线程限时 5 秒不是整个持锁时长的上界;不能只凭耗时变短判定修复完成。 |
|
||||
| 5:技术近期项 | 开发验证员工来源版本的误报,再评估数据库唯一约束 | 来源指纹包含员工 `updated_at`,登录会更新认证字段;先验证“财务预览后员工登录再保存”的冲突,不泛称每次登录必然提示资料变化。修正时须同时保留姓名、公司、状态和银行资料真实变更的拦截。唯一性当前由代码检查与员工行锁保护、缺少员工和公司组合的数据库唯一约束;新增约束前明确归档/空员工语义并检查存量,不直接加迁移或清理真实记录。 |
|
||||
| 6:线上验收补证 | 运维准备账号与安全凭据来源,财务/马经理补借款角色验收 | 现有通用 live smoke 需要管理员、员工两类账号;凭据通过受控本地环境或既有秘密配置提供,不写聊天和任务记录。先确认检查范围与授权,再执行登录后只读页面/权限检查。通用 smoke 不覆盖本次借款登记及公司代表确认,后者随 N5/N6 留证。真实云 OCR 单列授权和验收;带 OCR 的准备脚本会上传材料,不能当纯只读 smoke 执行。 |
|
||||
| 7:较低优先级改进 | 开发与财务明确旧记录重检、记账日期、字段提示规则 | 旧记录缺少原云端限制字段,重检不能重建未保存证据,先明确策略再实施;记账日期下限先区分正常还款与历史补记,不直接统一硬卡审批日;第五轮 N1 可统一 OCR 与本地无效编号的提示,但保持整段校验、多页关联和冲突拦截不变。 |
|
||||
| 8:文档收尾 | 开发提交发布记录及本次清单 | 内容与检查已具备,可在收到明确本地提交授权后单独提交;提交说明引用当前 task。此次梳理不自动提交,也不再次部署。 |
|
||||
| 9:下轮完整门禁前 | 开发盘点磁盘,用户确认删除范围 | 本次只读统计:`artifacts/` 约 8.87 GiB,所在磁盘剩余约 9.71 GiB。先列候选目录、大小、可再生依据及被证据引用情况;优先评估可再生构建/缓存,不因“旧轮次”就删除。保留发布/回滚依据、有效回执、复核报告、探针、关键失败证据和原件;删除另获明确授权。 |
|
||||
| 10:维护事项 | 逐个任务的负责人核对后归档 | 当前非归档 task 共 25 个:22 个 `in_progress`、3 个 `planning`,不是 24 个进行中。逐个核对交付、真实业务验收、未决项及记录,再列归档候选;时间久或代码已部署均不代表任务完成。本借款任务当前不归档,其他任务不在本轮批量更改。 |
|
||||
|
||||
验收口径:首笔正常成功还款只能补齐实际覆盖的银行提交、付款核验、核销及交接证据,不能一次关闭 AC5 或 AC9–AC19 的全部分支。失败归属、未付款释放、晚到成功、追回及补证恢复继续按各自条件验收;AC12 人工确认未提交仅适用于双独立复核模式,不适用于当前关联模式。不得为覆盖这些分支制造真实异常交易。
|
||||
|
||||
翻页问题继续标记“根因未定”。本次未核实生产出借人数量;即使目标当前在第一页,也只能说明这次未触发翻页,不能据此证明线上无影响。N5 可按既有流程由财务推进,实际遇阻时停在对应步骤留证,不绕过余额或授权确认。
|
||||
|
||||
本次为任务安排与证据边界澄清,无产品变更或新的已验证工程合同;不扩写 spec,不重跑全套业务测试。
|
||||
|
||||
## 2026-10-10 N5-P 已发布至生产(2063ff1e)
|
||||
|
||||
“上传回单登记借入”已随 `2063ff1e9336b8559ddd506f8f3fd754c1108327` 发布。本次仅补记发布结果:核对本地 Git 与已有日志,没有重新连接生产、调用云 OCR、写入真实业务数据或执行部署。父任务继续保持 `in_progress`;下方“待提交”“未发布”等内容保留各轮历史时点,以本节为最新状态。
|
||||
|
||||
### 本地核实的发布证据
|
||||
|
||||
- 补记前工作区干净,HEAD 与本地 `origin/main` 均为 `2063ff1e9336b8559ddd506f8f3fd754c1108327`。部署日志记录相同来源提交、`branch=main`、`published=true`、`remoteVerified=true`。
|
||||
- `artifacts/qa-flow/release-2063ff1e-20261010/verify-candidate.log`:候选验证结果 `status=PASS`、`localChecksPassed=true`、`deploymentEligible=true`、`issues=[]`、退出码 0;含静态检查、完整本地门禁及 372 项浏览器测试通过。本节转录已有验证结果,没有重跑这些测试。
|
||||
- 同目录 `deploy.log`:部署前聚合体检 `PASS=13 FAIL=0`;应用构建与切换、external deps smoke、runtime smoke 通过;公网前端资源扫描 `buildMarker=PASS`、`findings=0`。最终为“应用发布与备份合同刷新完整通过”、deploy 模式 PASS、退出码 0。
|
||||
- `artifacts/production-preflight-20261010-112903/{pre,post}/`:部署前后迁移核对均 `pending=none`,Prisma 均发现 82 个迁移且数据库结构为最新;当次回滚窗口均为 `OPEN`。该状态仅代表发布检查时点。
|
||||
- 部署日志明确跳过登录后的 live smoke,原因是未提供完整凭据。external deps smoke 中 OCR 项仅验证配置齐全,不代表真实云 OCR 识别已验收。
|
||||
|
||||
### 发布会话转交结果
|
||||
|
||||
用户回报:`origin/main` 从 `45737ccb` 推送至 `2063ff1e`,部署一次跑通、SSH 未断、前后复核均 13/13;公网 `/ready` 返回 `ok:true`、版本 `2063ff1e9`,首页、`/login`、`/mobile`、`/payment-batches`、电脑和手机公司借款入口均返回 200,前端主脚本正常加载;新识别接口未登录返回 401。
|
||||
|
||||
以上公网路由和部署后 13/13 明细沿用发布会话回报,本次未重新请求公网。路由可达、版本检查和未登录拦截不等于登录后的真实业务闭环通过。
|
||||
|
||||
### 财务交接与仍开放事项
|
||||
|
||||
- 财务在“公司借款”选择“上传回单登记借入”,上传 PDF 后逐项对照原件核对预填值及出借人建议,尤其姓名、账号和流水号;补填未还本金、核对截止日并勾选两项确认后保存。借款与原件一起保存,状态为“余额待核实”。
|
||||
- 后续仍需补协议、余额核对材料及代账引用,确认余额,再登记公司代表授权并由马经理确认。上线不代表真实台账、授权或首笔还款已经办理;AC5 及 N5/N6 真实业务验收保持开放,真实写入与付款按各自授权执行。
|
||||
- 两份真实回单已在本机解析验证,姓名、账号、流水号尚未逐值独立比对;真实云 OCR 未验收。保存前人工核对不能省略。
|
||||
- 员工授权翻页超时根因未定。r8–r11 虽通过,但未确定性触发原失败分支,不能据此断言已修复、仅为测试脚本问题或已证明不影响线上。
|
||||
- 第五轮独立复核的非阻断观察 N1(OCR 无效编号提示为 `missing`,本地为 `invalid`)保留,不影响既有拦截结论。
|
||||
|
||||
### 本次补记验证
|
||||
|
||||
仅修改本任务 `prd.md` 与 `implement.md`,未改产品代码。任务上下文校验、Trellis 治理、流程基线与 `git diff --check` 通过;文档登记审计为 0 错误、1 条既有警告(22 份未登记文档),本轮未修改 `docs/`。未重跑业务测试。补记尚未提交,不改变已部署产品版本或父任务状态。
|
||||
|
||||
## 2026-10-10 N5-P 第五轮独立复核通过(发布前历史记录)
|
||||
|
||||
第五轮复核(`independent-review-r5-20261010.md`)结论为 PASS_WITH_NOTES:此前要求修改的问题均可关闭,没有阻断项。复核方独立验证:
|
||||
- 相关单测 100 项通过;
|
||||
@@ -7,7 +141,7 @@
|
||||
|
||||
非阻断观察 N1:OCR 读出无效流水号或凭证号时,值会被拒绝,但字段提示显示为 `missing`(未识别);本地读出同类无效值时显示为 `invalid`。两种情况都不会预填错误值,也不会绕过多页拦截。本轮不改代码,下节“无效编号记 invalid”的说法仅适用于本地文字层。
|
||||
|
||||
AC39 的独立复核部分已完成。下面几项仍需另行处理或单独授权:
|
||||
AC39 的独立复核部分在该时点已完成。当时下面几项仍需另行处理或单独授权(最新进展见顶部发布记录):
|
||||
- 提交、最终候选完整门禁、推送和部署;
|
||||
- 真实回单上的姓名、账号、流水号逐值核对,由财务保存前对照原件完成;
|
||||
- 员工授权翻页超时(根因未定)。
|
||||
|
||||
@@ -1,12 +1,32 @@
|
||||
# 公司借款台账与本金归还
|
||||
|
||||
## 2026-10-09 N5-P 原借入回单识别预填(2026-10-10 第五轮独立复核通过,待提交授权与最终门禁)
|
||||
## 2026-10-10 N5-C 出借人在线确认借款(用户已批准实施)
|
||||
|
||||
用户批准将“借款确认书”增加为 OA 内可追溯的出借人声明,范围仅限本功能。此前“先记录、不修改”对本功能的限制由本次批准取代;登记默认值调整仍只记录、不实施。线上记录是本系统接受的借款确认依据,不宣称仅凭账号操作留痕即当然取得与纸质签字相同的法律效力。
|
||||
|
||||
- 财务可对同一公司、同一员工出借人的一笔或多笔尚待核实借款发起确认;已确认余额但存在失效在线声明历史的借款允许重新发起。固定借入日期、原始本金、截至日未还本金、原件摘要及对应身份。保留现有纸质协议/借款确认书上传路径;非员工出借人沿纸质路径办理。
|
||||
- 只有出借人关联的在职员工本人能查看自己的声明范围、核对原件并确认或退回;发起财务不能代确认,其他员工、管理员或公司代表权限均不能替代本人身份。此动作不要求出借人具有经理/CEO 权限,也不赋予其财务台账或他人借款的读取能力。
|
||||
- 确认记录、明细和决定不可改删。借款关键金额、日期、原件或出借人身份关联变化使旧确认失效,改回旧值也不复活;新增余额核对等其他材料不导致无关失效。退回后财务可重新发起。
|
||||
- 确认余额以及后续材料完整性检查接受“纸质协议/借款确认书 **或** 有效在线出借人确认”;原借入凭据、代账余额核对材料和必要的系统外已还本金依据仍必需。出借人声明不自动确认余额,不代替公司代表授权或付款批准。
|
||||
- 不包含通用电子签章、生成协议正文、替代代账核对、登记默认值修复、生产写入/发布或发送外部通知。财务可继续线下准备确认书及代账材料,不依赖开发完成。
|
||||
- 2026-10-10 发布前入口收敛:根据用户给出的两种方案及委托取舍,选择 OA 站内通知入口。普通员工不显示常驻“公司借款”导航;财务及公司代表保留入口,本人确认权限和直达路由继续有效。财务发起时仅为对应出借人创建站内通知,点开直接查看该次声明;不纳入通用待办或外部消息推送。
|
||||
|
||||
验收:
|
||||
|
||||
- [x] AC40(本地合成验收):财务可对一笔/多笔同公司同出借人借款固定快照并发起;跨主体、未核实身份、缺原件、重复及错误重试有明确结果,审计失败全部回滚。
|
||||
- [x] AC41(本地合成验收):本人可在电脑和手机查看快照/原件并确认或退回;财务代确认、他人越权读取/下载/决定、自发自确认和迟到请求跨账号重发受阻。
|
||||
- [x] AC42(本地合成验收):确认与快照不可改删;关键字段/原件/身份变化后旧证据永久失效,确认与变更并发不会消费过期结果,变更再还原不复活旧记录;余额确认后可重发失效声明,不改既有余额确认事实。
|
||||
- [x] AC43(本地合成验收):在线确认只替代协议类材料,代账和原件仍必需;有效在线记录可实际走到余额确认、既有公司代表授权及还款申请,纸质路径回归通过。
|
||||
- [x] AC44(本地验收与交接完成):新增迁移、HTTP/数据库并发与电脑手机验证、独立只读复核及发布边界据实记录;完整借款回归 r4 去重 216 项通过,前期失败及未定根因保留;尚未提交或发布,不宣称线上已可使用。
|
||||
- [x] AC45(入口调整,本地合成验收及只读复核完成):普通员工的电脑导航/后备导航/手机“我的”均无常驻借款入口;财务发起只为该出借人创建一条站内通知,同请求重试/并发不重复,事务失败不残留通知;电脑和手机点击通知直接打开该声明并仍执行本人校验,历史或失效通知不恢复旧确认效力。同 SPA 切换声明/浏览器返回正确定位详情并清空旧草稿。财务/公司代表入口、本人权限及账号切换请求保护不退化。最终入口专项 r5 为 17 HTTP、18 浏览器、9 数据库检查通过,复核无阻断;未提交或部署,尚未重跑最终发布门禁。
|
||||
|
||||
## 2026-10-09 N5-P 原借入回单识别预填(2026-10-10 已发布 2063ff1e,真实业务验收待办理)
|
||||
|
||||
### 目标与依据
|
||||
|
||||
用户在办理 N5 时提出先识别凭证或流水、再自动填写,并明确要求“规划改进任务”。本阶段复用当前借款任务,减少已持有原借入回单时重复录入金额、日期、凭据号及再次上传同一文件的操作。此次仅授权规划;原任务 `in_progress` 和此前员工选择功能的实施授权不代表本阶段已获实施批准。
|
||||
用户在办理 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`)。本阶段需要新增借入预填合同,不能把现有付款核验通过条件直接用于借入。
|
||||
规划时页面先手填登记借入、保存后再上传材料(当时的 `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`)。本阶段因此新增借入预填合同,不能把付款核验通过条件直接用于借入。
|
||||
|
||||
### 范围与要求
|
||||
|
||||
@@ -21,7 +41,7 @@
|
||||
|
||||
整份银行流水/Excel 批量导入、多交易拆分、自动建立借还对应、自动会计凭证、银行验真、自动确认余额/授权/付款、新银行或 OCR 提供商、图片直传识别、历史记录批量重识别。既有图片附件上传不受影响。规划和本地合成验收不包含真实票据调用云 OCR、生产配置、生产录入或发布。
|
||||
|
||||
验收新增 AC32–AC39,技术合同及执行清单分别见 design、implement 顶部 N5-P。以上为待批准的完整提案,暂无需单独澄清的阻塞问题;用户批准后才进入实施。
|
||||
验收新增 AC32–AC39,技术合同及执行记录分别见 design、implement 顶部 N5-P。上述方案已实施发布;本地合成验收、真实样本解析、云 OCR、公开发布和真实业务办理分别记录,不互相替代。
|
||||
|
||||
## 2026-10-09 N5 员工出借人选择调整(本地验证完成,未发布)
|
||||
|
||||
@@ -227,7 +247,7 @@ R3 的模式同时作用于付款审批、提交清单、成功/失败归属、
|
||||
- [x] AC36(保存一致性):保存成功同时存在一笔借款及对应 `incoming` 原件;相同请求重试仅返回原结果,换文件/字段复用请求键被拒;同公司同出借人的重复引用、相同原件及并发新入口保存不会生成重复可用借款。存储、附件或审计失败时正确补偿,不虚报成功。
|
||||
- [x] AC37(身份与原件绑定):无财务权限、跨身份结果复用、令牌过期/篡改、确认前换文件及来源变更受阻;电脑/手机换文件、卸载及同文档换账号时取消旧请求,迟到响应不覆盖新表单或以新身份重发保存;保留同身份正常会话恢复。
|
||||
- [x] AC38(原流程兼容与隐私):原手工登记、员工关联、非员工登记、三类材料余额确认、关联授权与还款路径仍通过相关回归;原件下载沿既有权限/用途/审计,无完整账号或原始识别 payload外泄。PDF/文件不安全或超限在持久化前拒绝。
|
||||
- [x] AC39(证据边界;第五轮独立复核 PASS_WITH_NOTES,真实样本仅确认字段已提取、未逐值核对,云端 OCR 与发布另行验收):完成单元、真实隔离 HTTP/数据库及电脑/手机浏览器验证,覆盖失败、并发和清理;完成涉及入口权限/保存流程的独立只读复核,受 inline 限制时明确待独立复核,不冒用旧结论。真实样本与云 OCR 可用性、公开发布分别验收,不以合成结果勾 AC5 或 N5/N6 实际业务完成。
|
||||
- [x] AC39(证据边界;第五轮独立复核 PASS_WITH_NOTES;2063ff1e 已发布,发布日志已核对、公网路由检查沿用发布会话回报;真实样本的姓名、账号、流水号未逐值独立核对,真实云 OCR 和登录后真实业务尚未验收):完成单元、真实隔离 HTTP/数据库及电脑/手机浏览器验证,覆盖失败、并发和清理;完成涉及入口权限/保存流程的独立只读复核,受 inline 限制时明确待独立复核,不冒用旧结论。真实样本与云 OCR 可用性、公开发布分别验收,不以合成结果勾 AC5 或 N5/N6 实际业务完成。
|
||||
|
||||
## Out of Scope
|
||||
|
||||
@@ -242,11 +262,15 @@ R3 的模式同时作用于付款审批、提交清单、成功/失败归属、
|
||||
|
||||
## Current Status
|
||||
|
||||
当前工作为顶部 N5-P“原借入回单识别预填”的规划,PRD、设计及执行清单已形成,待用户批准实施。本轮没有修改产品代码、启动任务执行或进行真实业务登记;父任务继续保持 `in_progress`,不把此前授权套用于本阶段。
|
||||
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`。真实 OA 台账及关联授权尚未登记,首笔真实还款的网银提交、正式回单、核销及会计交接尚未验收;AC5 及未覆盖的真实材料边界继续开放。无需重新索取已确认的借款事实或要求技术员工参与;真实录入和付款仍按各自授权执行,不从未还本金推定本次全额支付。
|
||||
整体任务保持 `in_progress`。2026-10-10 用户回报财务已完成真实借入录入,截图显示原借入凭据已有附件,但缺少协议/借款确认书和余额核对材料,当前卡在余额确认,公司代表授权尚待办理;本会话未访问生产独立核实。首笔真实还款的网银提交、正式回单、核销及会计交接尚未验收;AC5 及未覆盖的真实材料边界继续开放。无需重新索取已确认的借款事实或要求技术员工参与;真实录入和付款仍按各自授权执行,不从未还本金推定本次全额支付。缺材料的流程问题仅记入 implement,依用户指令暂不修改产品规则。
|
||||
|
||||
后续安排见 implement 顶部:N5 真实登记为业务优先项,授权翻页的确定性排查可并行,N6 按实际付款计划在 N5 后办理。首笔正常成功链路不一次关闭 AC5 或 AC9–AC19 的全部验收;异常分支及仅适用独立模式的 AC12 保留各自适用条件,不为验收制造真实异常交易。
|
||||
|
||||
### 2026-10-08 N1–N2 完成时点(历史记录)
|
||||
|
||||
|
||||
在新工单中引用
屏蔽一个用户