修复bug

findings.md

@@ -1,5 +1,32 @@
 # 当前关键发现
 
+## 2026-08-30 — 0.5.156 校验范围恢复
+
+- 用户明确要求恢复 `0.5.156` 的校验方式。归档 ZIP 证明该版本的动态正则写成字面 `\\d*`，所以真实编号 `ys_danwei1/ys_danweiid1/ys_jine0` 等字段并未进入保护；`0.5.160` 修正数字后缀后才新增当前强校验。
+- `0.5.163` 不整体降级：保留正式控制面域名、MV3 链路恢复、lookup readiness 和 `jQuery.active/ajaxStop` 稳定态，只移除编号动态 `ys_*` 的保护投影。日期、客户、产品、人数、房型、跟单人、销售人等静态核心字段继续按摘要漂移失败关闭。
+- 完整 live-gate 回归确认：核心字段变化仍返回 `live_submit_blocked` 且零网络；仅编号动态应收字段变化时，表单和原生请求的保护摘要均匹配并进入原生提交路径。该策略允许 ERP 在预检后调整动态应收行，属于生产操作方明确接受的行为边界。
+- `0.5.163` ZIP SHA-256 为 `90c550054cdf747aa9c2c80bca5ee5fba0d13f126acfd4779f85400764379bf0`；专项、全量和构建门禁均通过。生产仍需加载后以新任务验证，旧失败任务不重试。
+
+## 2026-08-29 — Program 写前受保护字段漂移
+
+- `0.5.160` 生产复测已把实际漂移字段定位为 `xiaoshouren`（销售人），仍在网络请求前阻断。活动源码确认单团页面只按 `ListForm` 控件数达到 800 判定就绪，但 ERP 页面会异步请求 `ProDanwei_Yuangong`，并在回调中两次重新初始化 `xiaoshouren`；插件写入预检销售人后到 live gate 之间没有第二次插件写入。
+- 真实 `lightweightOrderFrameProbe` 的离线反馈环稳定证明：`zutuanshe/gendanren/xiaoshouren` 的原生 SelectBox 数据仍为空时，当前实现仍错误返回 `order_frame_ready`。散拼子单路径已等待这三个 lookup 的 `data` 属性，单团路径没有，最可能因此允许 ERP 员工列表回调在预检后改写销售人。由于没有生产页面回调时间戳，这一因果关系属于强证据推断而非直接观测。
+- `0.5.161` 虽已等待客户、跟单人和销售人 SelectBox 的 `data`，生产握手确认该版本后仍先后报告 `xiaoshouren`，以及 `xiaoshouren + ys_danwei*/ys_danweiid*` 漂移。这证明 lookup 数据存在不等于页面所有原生 Ajax 已完成；ERP 表单启动阶段还有收款项目、报位、说明和资源等多组 jQuery Ajax。
+- 用户确认生产 `0.5.156` 没有该阻断。ZIP 差分确认 `0.5.156` 已保护 `xiaoshouren`，但数字后缀正则错误使 `ys_danwei1` 等动态应收字段当时未进入保护；应收行是 `0.5.160` 修正保护范围后新暴露的真实迟到变化。随后用户明确接受该范围调整风险并要求恢复旧校验效果，当前结论见上方 `0.5.163` 记录。
+- 真实 frame probe 的第二个离线反馈环证明：三个 lookup 数据均存在、但 `jQuery.active=2` 时，`0.5.161` 仍错误返回 `order_frame_ready`。`0.5.162` 同时在 frame readiness 要求原生 Ajax 归零，并在 `GetProduct` 外层完成后等待页面自身 `ajaxStop`，再应用最终销售人和应收字段；只使用完成事件和失败超时，不使用固定 sleep。
+- 用户提供的服务工作线程状态证明：预检最终表单与其拦截请求的受保护字段 SHA-256 都是 `fe3cfc2e72e0e8fafad548717a71012228d63b5f5a10ee20a5ff526e1f12c8e5`，实时提交的已批准摘要仍是该值，但当前摘要变为 `fa42ee152b1e4d1920d2f5b4329b8dfe1884900a087c932b3dfb8736d05c1276`；前后字段数均为 822。
+- 因字段数相同且预检前后摘要一致，这不是错误基线或表单字段总数变化，而是预检结束到真实提交之间至少一个受保护字段的名称/值投影发生了漂移。`0.5.159` 只持久化聚合摘要，无法从既有日志反推出具体字段。
+- `0.5.160` 仅在 ERP 页面运行内存保存预检受保护字段投影。写前不一致时回执只包含变化字段名、数量、基线可用性和 `values_redacted=true`，不持久化或输出任何字段值，也不放宽阻断条件。
+- 新回归发现动态应收保护规则原先使用双重转义，实际匹配字面 `\\d`，导致 `ys_jine0` 等带数字后缀的真实字段未进入保护投影；已改为数字后缀匹配并由行为测试覆盖。
+- `0.5.162` ZIP 与 19 个活动源码文件逐字节一致，SHA-256 为 `2b257fd61610e8cb6f21c99441b6072246ce06397e2ea05e96488ef414926f12`；定向回归、仓库治理、TypeScript、控制面、legacy 与 build 均通过。生产运行态仍需运维加载该版本后用新任务验证；不重试旧失败任务。
+
+## 2026-08-29 — ERP 链路恢复状态残留
+
+- 截图中的插件版本、权限、自动化和 ERP 会话均正常；唯一告警来源是持久化 `recovery_status=running`。操作台把 `scheduled/already_running/running` 视为恢复中，并阻断自动与手工插件派发。
+- MV3 服务工作线程可能在恢复写入 `running` 后被中断；内存 Promise 随工作线程消失，但旧实现没有区分“真实活动恢复”和“只剩持久化状态”，普通保活成功也不清除 `recovery_status`，因此告警可永久残留。
+- `0.5.159` 只在内存恢复 Promise 已不存在时把 `running` 归一化为 `interrupted`；真实活动恢复仍保持 `running`。普通只读保活成功且无恢复在途时把恢复状态转为 `idle`，不会重放任何业务任务。
+- 同一真实页面状态函数的反馈环确认：无在途 Promise 时页面恢复“已连接”，有在途 Promise 时继续“已连接，有告警”。
+
 ## 2026-08-29 — 正式控制面域名插件接入
 
 - 扩展 `0.5.157` 的 Popup 与后台业务系统 URL 判定只允许本地 HTTP，Manifest 的控制面 content script 匹配也只有 localhost/127.0.0.1；当前 ZIP 与源码一致，因此刷新或重新加载旧包不能识别 `https://lwlt.nianxx.cn`。