回填财务/yj所属主体生产修正执行记录 [09-08-reimbursement-payment-closeout]
从孤儿 worktree（artifacts/isolated-worktrees/20260910-reimbursement-payment-integration） 合并回填一次真实生产数据库写入、此前从未提交的完整执行记录： - 2026-09-11 用户明确批准仅对财务 wangzhiling 与 yj 两人做 legal_entity_id 回填（原值须为 NULL，目标须为唯一启用未归档主体），不涉及银行明文/角色/ 经理等其他字段。 - 10:50 READ ONLY 预检确认两人在职、角色/经理未变、目标主体唯一；10:51 READ WRITE Serializable 事务原子更新恰好两行；10:52 独立连接只读回读 确认一致，另有独立 SSH 只读复核。执行脚本先过 13 项合成正反例自测。 - 同批次的业务就绪只读核验：确认财务/yj/管理员当时仍缺所属主体，不能 由此推出"财务不能替别人付款"等错误结论；两者是不同资格维度。 无新增产品代码改动；本次回填是对已实际发生的生产写入补齐审计记录， 使任务文档与真实数据库状态一致。 Co-Authored-By: Claude Sonnet 5 <[email protected]>
这个提交包含在：
Claude Sonnet 5
@@ -195,3 +195,7 @@ AP task 保留原实施写入面和已通过用户复核。提交/推送后冻
|
||||
- 保留敏感文件确认、重下载警告、取消零请求与 pending 防重复点击。下载次数更新后主动作仍切换上传回单，不表示付款完成。
|
||||
- 右侧操作卡与进度卡相邻；移动端保留底栏快捷动作且正文操作/进度可达。操作卡不独立 sticky，避免滚动覆盖紧随其后的进度。
|
||||
- 验证：路由与 BIFF8 单测、mock 桌面/移动端真实下载、隔离 PostgreSQL/真实认证 HTTP 创建复核下载，再与退回删除做同候选验证；禁止真实网银付款和伪造回单。
|
||||
|
||||
# 2026-09-11 两人所属主体修正
|
||||
|
||||
沿既有单字段受控修正方式，固定已确认财务与 yj，预检保存两人/角色/经理/唯一主体摘要。执行时 READ WRITE Serializable 事务锁定目标行与主体，并核对已审 employees UPDATE 触发器/规则；只对原值为 NULL 的两个 id 更新 legal_entity_id，恰好两行，否则整体回滚。原值非空不得覆盖；提交结果不明先只读核验，禁止盲重试。提交后新连接 READ ONLY 验证两人的字段、身份及角色/经理未漂移。回退该字段需重新核验业务使用与单独授权，不自动补偿已提交写入。
|
||||
|
||||
@@ -552,6 +552,26 @@ A1本地修复与402/34验证仍成立，新增范围闸待独立内容复核。
|
||||
|
||||
主会话检查确认运行时只改备注拼接，不动权限、状态、审批、编号或数据迁移；本轮不是独立复核。现有银行模板没有长度上限说明，网银实际导入及长备注接受性未验证。仅本地完成，未连接生产、未导出真实制单、未提交/推送/部署。下一步将本增量纳入候选复核与提交准备；提交/推送和部署须明确授权，不能直接覆盖原integration任务记录或将原有冻结候选视为包含本改动。
|
||||
|
||||
## 2026-09-11 已授权两人所属主体修正（已完成，未部署）
|
||||
|
||||
用户明确批准仅财务 wangzhiling 与 yj 两人；按已确认登录标识核对，不扩管理员或 smoke。只把两人的 legal_entity_id 从 NULL 填为执行时唯一启用且未归档主体；两人须在职启用、角色与前次确认一致、直接经理仍为已确认 CEO。禁止读取银行明文或密码，不修改角色、经理、银行资料、单据或付款账户。
|
||||
|
||||
复用既有单字段修正合同，先 READ ONLY 预检并冻结两人/主体/经理/角色的摘要；事务中重核 employees 触发器和规则的已审指纹，锁定目标行与主体、条件 UPDATE 恰好两行且失败整体回滚；提交后使用新连接 READ ONLY 回读。状态不符、原值非空、唯一主体不成立或提交状态不明均停止，不自动重试或擅自补偿。执行脚本先作本地语法及合成正反例验证；本轮不提交/部署。
|
||||
|
||||
10:50（Asia/Shanghai）READ ONLY 预检通过：两人均在职启用、财务/员工角色集合与既有确认一致、经理仍为 CEO，两个 legal_entity_id 均 NULL，目标唯一启用主体与 CEO 已绑定主体一致。10:51 条件原子更新恰好两行，事务内复核、提交后新连接只读回读通过；10:52 又经独立 SSH 只读复核，身份摘要保持一致。未改管理员/CEO/smoke、其他字段、角色或单据，不创建付款账户。
|
||||
|
||||
证据：联合副本 artifacts/qa-flow/20260911-authorized-preparation/ 下 entity-precheck.json、entity-apply.json、entity-readback.json；PASS_APPLIED_AND_READBACK / PASS_READONLY_READBACK。本地 node --check 及 entity-correction-selftest.cjs 13 项合成检查通过；最初旧触发器 fixture 的相对路径定位错误仅发生在本地自测，修正后通过再开始生产字段写入。既有触发器只防员工号变更，指纹与原已审值一致；没有改员工号或绕过触发器。
|
||||
|
||||
主数据缺项已补，不提前宣称两人已能真实付款：银行解密、实际提交及业务审批未在本轮执行。今日备份早于本次修正，恢复影响另审；不自动触发备份、回退字段或部署。当前镜像独立制品固定见 09-04 最新回执。
|
||||
|
||||
## 2026-09-11 已授权业务就绪只读核验（未回填、未部署）
|
||||
|
||||
09-04/09-11 两笔改动已推送，候选 fedcaed1；生产仍 fe025e65。原已确认四人只读盘点排除 smoke：财务与 yj 的直接经理均为 CEO 且启用；CEO 无 AP 全量权限但保留审批/付款复核，财务不能自审，管理员通配不被当成 CEO 职责。四人的门户/付款部门 gate 均开启，39 个费用类型、3 条规则及 1 个报销活动工作流存在。
|
||||
|
||||
当前唯一启用主体和 1 个有效建行付款账户。CEO 的主体、收款资料存在性及主体下付款账户密文存在性齐；财务/yj/管理员的所属主体仍空，不能说他们自己的报销已经能组批。管理员还无直接经理、未关联有效建行机构；是否本人报销决定其修正范围。不要把缺主体说成“财务不能替别人付款”，两者是不同资格。
|
||||
|
||||
本轮不读银行明文、不解密、不实际登录/提交或做完整审批人解析，不宣称已证明真人被阻断。财务/yj 的主体回填可单独申请，只改空字段且执行前后回读；管理员是否包含另定，不改 smoke，不重复建付款账户，不顺手改银行资料。证据位于联合副本 artifacts/qa-flow/20260911-readonly/employee-readiness.json 与 gates-transfer-final.json；提交/生产/备份详情共用 09-04 最新回执。部署、真实付款和消息发送均未执行。
|
||||
|
||||
## 2026-09-11 业务就绪只读检查准备（未执行生产查询）
|
||||
|
||||
复用已确认身份和经理/主体回填回执，不再猜邮箱或索取工号。排除 smoke 账号，分别核对能登录、能提交、能审批/复核、能组批/登记，不能合并成一个笼统 ready。
|
||||
|
||||
@@ -132,3 +132,7 @@
|
||||
## 执行边界
|
||||
|
||||
本次技术审查沿用既有“付款复核通过后，财务主动点击下载银行制单，再由授权银行操作人导入网银”的方式；不新增自动下载或自动付款。不重复索取本地技术审查/修复授权；各项生产写入、真实账号解密、导出、付款和发布仍分别获批。
|
||||
|
||||
# 2026-09-11 窄范围授权追加
|
||||
|
||||
仅为已确认财务 wangzhiling 与 yj 修正所属主体，原值必须为 NULL、目标必须为唯一启用未归档主体；不读单据或银行明文，不改其他字段、其他员工或账户。验收为预检身份和原值匹配、恰好两行原子更新、独立连接回读一致。该授权不包含管理员/smoke、角色变更、部署或实际付款；历史 0014 单人修正限制不扩大到其他人。
|
||||
|
||||
在新工单中引用
屏蔽一个用户