204 lines
26 KiB
Markdown
204 lines
26 KiB
Markdown
# 联泰下单助手
|
||
|
||
Chrome Manifest V3 扩展，在用户已登录的 LTJT ERP 页面内执行经过平台确认、Schema 校验和 ERP 只读唯一解析的确定性业务操作。
|
||
|
||
## 职责边界
|
||
|
||
- 平台与 Agent 负责业务意图、用户事实、任务/会话、确认和通讯。
|
||
- 插件负责前门禁、ERP 对象/资源解析、页面联动、严格写前校验、原生提交与 fresh requery。
|
||
- 插件不解释新的自然语言含义，不绕过候选唯一/首条选择规则，不维护主数据，不凭 HTTP 200 宣称成功。
|
||
- `operation.source` 只允许显式历史测试上下文；普通平台元数据不得混入业务 operation。
|
||
|
||
## 当前版本
|
||
|
||
当前源码版本为 `0.5.189`。版本化 ZIP、文件哈希和 Skill/DOCX 基线见 [`../../dist/release-manifest.json`](../../dist/release-manifest.json)。旧版本实现流水已冻结在 [`../../archive/project-history/2026-08-16/chrome-extension-README.pre-governance.md`](../../archive/project-history/2026-08-16/chrome-extension-README.pre-governance.md)。
|
||
|
||
0.5.189 当前重点：
|
||
|
||
- 大交通、其他/备案新增支持带团队默认日期的备用空行：仅允许行日期等于页面有效发团日期 chufari（兼容补零格式），数量为空/0/1，且原有资源、备注、费用、付款、审核保护全部通过。其他日期或无法验证默认值仍阻断。只改选中行的目标日期，保留其他行与全局备案信息；酒店/用车/导游和变更/清除规则保持。本地合成回归通过，真实 ERP 验收待部署方完成；需更新插件至 0.5.189、同步平台最低版本并刷新 ERP 页面，无服务端逻辑变更或数据库迁移。
|
||
|
||
继续保留 0.5.188 的产品名称匹配修复：
|
||
|
||
- 独立团单个下单的产品名比较统一输入与 ERP 候选的 NFKC 和空白格式，精确优先、唯一包含兜底，保留其他标点及业务限定词；归一后多候选仍阻断。选中后以 ERP 原名填写及触发原生联动。初始匹配/校验失败保持表单未填写，后续阶段标记跳过，产品零/多候选分别给出中文原因。程序解析器 v1.0.14 保留 keyword 的原始格式，name 沿用既有归一化。需同步更新服务端、插件和平台最低版本，无迁移；本地合成验证通过，真实 ERP 验收待部署方完成。
|
||
|
||
继续保留 0.5.187 的房型修改：
|
||
|
||
- 独立团修改新增 DBL 大床房到 frenshu3 的字段映射，与 SGL/TWN 一样按明确目标值填写，重新计算房间合计，并通过保存后 fresh GET 核对大床房和合计。程序解析器 v1.0.13 兼容“房间数更改为 12 标+2 大”；未指定房型保持原值，其他未实现字段继续整体阻断。需同步更新服务端、插件和平台最低版本，无数据库迁移；本地合成验证通过，真实 ERP 实写待验收。
|
||
|
||
继续保留 0.5.186 的车票匹配修复：
|
||
|
||
- 大交通选填车票说明在忽略空格/括号时保留原数字边界，修复 `C91 12:52` 无法用 `C91` 匹配的问题，继续阻止 `C91` 命中 `C911`。供应商与说明仍须匹配同一唯一候选；仅路线也可在唯一时使用，歧义时停止并显示最多 5 条供应商/说明，不暴露内部 ID 或价格。新增/变更以及原生联动前复核使用同一规则。零候选与候选未加载分别提示；未填车票说明的旧行为保持。回归为本地合成验证，真实 ERP 验收待部署方执行；需更新插件及平台最低版本，本修复无数据库迁移。
|
||
|
||
继续保留 0.5.185 的查询恢复修复：
|
||
|
||
- 目标只读查询遇到 Chrome 主框架移除时，在同一执行仍处于写入前运行状态下，最多等待 8 秒确认同一主文档连续两次加载完成，再重新注入适配器并只读重查一次。持续切换、权限错误、取消或写入边界变化时停止；业务无匹配和多匹配不重试，原生保存不重试。异常按实际查询、路由准备或预检阶段记录；查询失败保留步骤和当时自动恢复时间快照，不记录业务值或恢复正常心跳刷屏。本地合成回归覆盖，真实 ERP 验收待部署方执行。需更新插件及平台最低版本，无数据库迁移。
|
||
|
||
继续保留 0.5.184 的列表及回执修复：
|
||
|
||
- ERP 列表就绪等待跟随当前 iframe 文档，仍要求加载完成、原生搜索函数与可用按钮，切换期间不在旧文档中搜索；失败回执明确区分页面未就绪，并记录不含业务值的条件与耗时。平台接单等待为 10 秒；明确未写入的迟到检索失败可在同执行编号、原连接范围内同步回平台。需同步更新平台/服务端与插件，无数据库迁移；不重新下发任务，真实写入不确定结果继续人工核验。
|
||
|
||
继续保留既有修复：
|
||
|
||
- 安排联动稳定检查将正常采样观察预算与定时回调延迟分开；长间隔后重新观察至少 1.5 秒并要求多个有效样本，30 秒总等待上限内恢复，持续变化、持续延迟、控件失效或原生加载未结束均不保存。新增失败回执区分检测延迟与字段变化，详细证据仅记录字段名、采样次数和时间，不记录业务值。保留原生联动、唯一空行、付款审核、其他行保护及保存前复核；不自动重试保存。合成回归覆盖，真实 ERP 验收待部署方执行。
|
||
|
||
- 修复 0.5.181 安排变更的页面依赖漏注入：在 ERP MAIN world 先加载 operation-plans.js，再加载页面适配器。缺失日期组件单独报错，不再误报原安排为 0 条。回归测试从后台实际注入列表加载全新页面环境，覆盖四类日期变更；服务端已为 v1.0.12 时，本修复只需更新插件并刷新 ERP 页面。真实 ERP 验收仍待部署方执行。
|
||
|
||
- 酒店、用车、大交通和其他/备案变更支持仅填写原日期的月日，由指定团队中唯一原安排确定实际年份；完整年份精确匹配。多条候选显示日期供核对，找不到或不唯一时停止。服务端解析器与插件需同步更新，不新增数据库迁移。
|
||
|
||
- 用车、大交通、其他费用/备案新增与酒店共用空行选择，按原生 MaxI 和每行完整控件判定可用表单；已有安排时选择后续空行，原生选择、日期、数量和保存回查绑定同一条记录。保存前后保护原有安排；其他费用保留未填写的数量及团队备案信息。导游经操作方确认只能安排一位，已有导游需走“安排导游变更”。本项只需更新插件，无服务端运行逻辑或数据库变更；真实 ERP 验收待部署方完成。
|
||
|
||
继续保留 0.5.179 的酒店新增修复：
|
||
|
||
- 酒店新增在结构预检后选择第一个空白原生行，资源证明、SelectBox 联动、日期、间数、状态与备注都使用同一行；不再因第一行已有安排而阻断。有未保存草稿或没有完整空白行时停止；保存前复核其他行、目标空 ID、财务审核与业务值，保留原安排。回查按保存前记录 ID 和摘要寻找唯一新增记录，支持 ERP 行排序，并保留证据用于只读核验。输入格式与创建契约不变，不接受手填 target。真实 ERP 验收待部署方执行，本修复替换插件即可，无数据库迁移。
|
||
|
||
- 酒店新增取消固定 150 个可序列化字段门槛，改为检查当前已连接表单、有效 MaxI、连续酒店行及每行必要控件；控件唯一且可用、页面加载完成、无 loading/未完成 Ajax，并实际观察结构稳定至少 1 秒后才通过。76 字段两行与较长表单采用同一结构检查；字段总数只作诊断。资源匹配、空槽、付款审核、身份归属及保存回查仍执行。酒店修改/清空和其他业务的门槛不变。真实 ERP 验收待部署方完成；本项运行修复只需替换插件，无迁移。
|
||
|
||
继续保留 0.5.177 的车票说明过滤：
|
||
|
||
- 程序模式“安排大交通 / 安排大交通变更”新增选填车票说明（别名：车票说明搜索）。与结算单位搜索共同筛选同一条原生候选，填写后仅接受唯一结果；省略沿用首条匹配行为。完整说明与价格等字段仍由 ERP 原生选择联动。原有“车票/控位说明”兼容字段不变。需同步更新服务端，无新增迁移。
|
||
|
||
- 程序模式“安排用车 / 安排用车变更”新增选填用车类型（别名：车型）。以车型关键词过滤结算单位搜索候选，只接受唯一结果；不匹配或多匹配停止，保留原有省略行为。变更日期仅定位原安排，类型只筛选新车辆。需同步更新服务端，数据库仍为迁移 024，无新增迁移。
|
||
|
||
- 新增 Program-only“安排导游变更 / 安排用车变更 / 安排大交通变更 / 安排其他/备案变更”。日期仅定位原安排，资源和明确填写的数量、备注及备案号/口岸作为新值；保留原日期、ID、未填写字段和其他行。需同步部署服务端、执行迁移 `024_arrangement_update_routes` 并由管理员授予四项变更权限；没有自动授予权限。已完成本地回归，真实 ERP 验收待部署方执行。
|
||
- 程序模式支持“安排酒店变更”：按原入住及离店日期唯一定位已有酒店行，使用 ERP 原生酒店选择联动更换酒店和房型，并修改间数；保留记录 ID、原日期、状态、备注及其他行。仅允许未安排或未确认、无付款及审核的记录；多条日期匹配时停止。已完成本地回归，真实 ERP 验收由部署方进行；需同步升级服务端。
|
||
|
||
继续保留 0.5.173 的名单修复：
|
||
|
||
- 名单 TSV 在派发校验、领队提取和原生名单合并时保留末尾空列的制表符，只统一换行并移除首尾空行。最后一条电话或备注为空时仍按完整 13 列处理；真正少列、多列及领队不一致仍阻断。本次需同步部署服务端的统一 operation 校验修复，不涉及数据库变更。
|
||
|
||
0.5.172 的酒店新增 195 → 150 门槛修正已由 0.5.178 的结构检查取代；酒店修改/清空仍保留原门槛。
|
||
|
||
继续保留 0.5.170 的批量子单执行能力：
|
||
|
||
- 新增 Program-only `shared_child_order_batch_create`：先逐日只读枚举日期段内所有产品匹配母团并锁定完整 `tid` 清单，再复用单母团子单路径顺序创建；首个失败或不确定结果立即停止且不自动重试。
|
||
|
||
- ERP 写入结果不确定时，扩展停止自动重试并明确要求任务归属账号做人工只读核验，不再把责任错误指向无任务数据面权限的管理员。
|
||
|
||
继续保留 0.5.168 的 ERP 精确身份门禁：
|
||
|
||
- ERP 登录身份只从当前主页面唯一的 `#Lable_UserName` 节点读取，并与平台绑定身份做 Unicode、空白和大小写规范化后的精确全等比较。缺失、重复、空白或仅为子串时都不再执行；不再用整页业务文字猜测账号。
|
||
- 扩展仍只向平台返回账号是否存在、是否唯一和是否匹配，不回传 ERP 页面显示的账号文本。
|
||
|
||
继续保留 0.5.167 的空闲证明和受控重载协议：
|
||
|
||
- 插件 PING 会返回当前运行任务、持久化写入边界和待回查结果汇总后的 `extension_update.safe`。只有内存与持久化状态都完全空闲，服务端才允许同一 ECS 实例进入文件部署。
|
||
- 中央服务完成共享目录替换后，平台通过受控消息请求后台 `chrome.runtime.reload()`，并刷新平台页以重新注入 content script；执行中、已跨写边界或待回查状态会拒绝重载。
|
||
- 这是自动更新协议的引导版本。每个 Windows Server/Chrome profile 仍需最后一次人工把插件加载到统一的 `C:\ProgramData\LTJT\chrome-extension\ltjt-order-assistant`；后续版本才由现有服务配合阿里云 ECS 云助手更新，不新增 LTJT 常驻更新器。
|
||
|
||
继续保留 0.5.166 的自适应等待：
|
||
|
||
- 散拼新增计划进入计划表后立即检查“新增计划”按钮；若同路径 iframe 尚在渲染，则每 100ms 重新取得当前 document 并检查按钮是否已连接且可用，出现后立即继续，最长 15 秒后才在写前阻断。快速页面没有固定等待，也不会自动重试任何 ERP 写入。
|
||
|
||
- 散拼新增计划和独立团批量下单在已加载候选无法唯一匹配时，会真正触发 `S_chanpinming` 的原生非空检索并等待 Ajax 返回，再对产品名/时长做本地唯一匹配。完整产品名原样查询；只有尾部 `10D`、`8天` 等数字时长会先剥离。最后仍保留一次空条件兼容重载，零候选或多候选继续在写前阻断。
|
||
|
||
- 平台会把当前员工账号绑定的 ERP 账号随只读 PING 交给扩展核验；扩展只返回是否匹配，不回传页面中的其他账号文本。
|
||
- 只有平台确认的唯一在线云电脑、匹配的 ERP 登录身份和任务归属账号三者一致时，任务才可领取或回传结果。
|
||
|
||
- 保留 `0.5.162` 的稳定态处理：独立团单个下单只有在表单结构、客户/跟单人/销售人三个原生 SelectBox lookup 数据以及页面 jQuery Ajax 全部就绪后才进入预检；`GetProduct` 外层完成后还会等待页面自身 `ajaxStop`，再应用最终业务字段。该门禁使用原生完成事件和失败超时，不使用固定 sleep，也不在 live gate 静默回填。
|
||
|
||
- 按生产操作方明确要求，独立团单个下单的受保护字段范围恢复为 `0.5.156` 的实际效果：日期、客户、产品、人数、房型、跟单人、销售人等核心字段继续执行写前漂移阻断；带编号的 `ys_danwei*`、`ys_danweiid*`、`ys_bizhong*`、`ys_shuliang*`、`ys_jine*` 不再进入该哈希门禁，允许 ERP 原生表单在预检后调整这些动态应收行。漂移诊断仍只报告字段名，不保存字段值。
|
||
|
||
- 修复 ERP 链路恢复在 Chrome MV3 服务工作线程中断后残留 `running`、导致操作台永久显示“已连接，有告警”并阻断新任务的问题。真实内存恢复仍在执行时继续保持 `running`；Promise 已不存在时收敛为 `interrupted`，后续普通只读保活成功后转为 `idle`。该修复不重放业务任务，也不放宽 ERP 写入门禁。
|
||
|
||
- 正式控制面 `https://lwlt.nianxx.cn` 现在进入精确业务系统白名单；Popup、后台标签页发现、Manifest host permission 和 content script 注入保持同一 origin。相似域名、子域名及其他 HTTPS 站点仍不允许注入。
|
||
|
||
- 团队文件导出新增散拼母团“整团游客信息”窄分支：解析与唯一定位必须明确 `shared_plan`，只能单独导出 `visitor-list`，且源请求只携带母团 `tid`；任何子单 `did/ddid`、其他文件类型或混合范围都在请求前失败关闭。独立团和散拼具体子单“游客名单”的既有 `did+tid` 路径保持不变。
|
||
|
||
- 名单所需游客位超过 ERP 原生页面实际可物化数量时，继续在父表单保存前失败关闭，但用户主提示改为“本次名单共 N 人，超过该独立团/散拼子单在 ERP 中最多可录入的 M 人”。`passenger_native_*` 连锁 blocker 只保留在技术详情中；该例 25 人名单、16 个原生游客位会明确显示 25/16，而不再把技术码当成用户错误说明。
|
||
|
||
- 名单收到 `full_replace + confirmed=true` 后，用户的覆盖确认就是写入授权：附件中所有指定序号都进入原生覆写集合，即使 ERP 当前游客字段与附件相同也不再降级为 `passenger_import_no_changes`。未确认时，只要目标行已占用（包括同值），仍先要求覆盖确认。
|
||
|
||
- 名单继续严格执行附件/Program-only、精确对象定位、覆盖确认、游客行和领队联系人完整写前投影；父表单 ERP 明确返回成功后立即判定录入成功，不再执行写后逐行回查或自动名单对账。未取得明确成功响应仍停止且不自动重提；其他生命周期业务继续要求原有写后回查。
|
||
|
||
- 名单 canonical TSV 中恰好一行备注严格等于`领队`时，适配器校验结构化 `leader_contact` 与该行序号、姓名、电话全等；`DaoRuDones` 后先恢复四个接送联系人/电话字段，再只把姓名、电话写入 `jj_lianxiren/jj_dianhua`。父表单保存前全等检查；无领队标记时保留原字段，多行标记或缺姓名/电话时不写。
|
||
|
||
- 名单确认覆盖已占用行时，原生 `DaoRuDones` 可能遗留旧英文名。适配器现在只对合并计划确认变更的序号回写按原生规则去空白后的 `NAME → pinyinxm`，再执行完整写前投影；未变更行仍从快照恢复，任一字段不一致仍不保存父表单。
|
||
|
||
- 名单解析阶段不把 ERP 初始 16/31 个游客位当作统一静态上限；适配器仍按当前页面行数与附件最高序号尝试动态补足空白行，并保留 5000 行技术上限。若精确目标页的原生 `DaoRuDones` 实际只能物化较少游客位（本次独立团为 16），则以该页面实际数量作为 ERP 容量上限并返回上述业务提示，不进入父表单保存。
|
||
|
||
- 独立团信息修改新增 `pax.child_no_bed → ertrenshu`，与成人、占床儿童、领队共用非负校验、整表哈希、原生 `DoInfoJH` 提交和 fresh 表单回查；四类人数仍待授权 ERP 实写复测。
|
||
|
||
- 独立团单个下单把预检批准拆成两条严格基线：`SubmitInfoForm()` 返回后的浏览器表单哈希，以及预检拦截到的原生请求哈希。正式保存分别校验两者，允许 ERP 原生函数对页面表单做确定性规范化，但任何后续业务字段漂移仍在网络前失败关闭。
|
||
- 页内门禁现在明确区分“调用原生提交函数”和“已向 ERP 发出网络请求”。若哈希、表单就绪或提交函数在网络前阻断，扩展回执固定为 `blocked / prewrite_blocked / write_attempted=false / no_erp_write=true`；只有确实放行原生 Ajax 后才进入写入不确定边界。
|
||
|
||
- 独立团单个下单的产品联动直接等待原生 `GetProduct` 完成回调，客户恢复在同步写入五个受保护字段后立即做全字段精确复核，正式保存直接等待 `DoInfoJH` 完成回调；不再使用会被 Chrome 后台标签页放大到数十秒的 25/50/250ms 页面定时轮询。
|
||
- 预检提交仍由持久 Ajax guard 阻止网络，并保留唯一 payload/protected-fields hash；正式提交只临时放行一个匹配请求，重复分支在网络前阻断，完成或返回列表前 guard 持续阻止迟到的重复提交。
|
||
- 下单/批量下单通过 `webNavigation` 先定位准确 ERP iframe，再只对候选 frame 执行轻量 readiness 探针，不再向标签页全部 frame 广播脚本；正式动作仍只注入实际依赖并复用同版本页内运行时。
|
||
- 平台只在任务当前状态确为失败时展示 failure/error timeline；成功解析的 `no_plugin_dispatch/no_erp_write` 边界事实不再被误判为失败，已完成任务也不再追加伪造的“获取回执失败”。
|
||
- 扩展本地任务历史在领取新任务时有界清理，同时永久保留运行中、已跨写边界、结果不确定和待回查任务；存储排队、读写、清理、页签查找及预检子阶段均进入脱敏耗时明细，用于定位原先未归因的编排时间。
|
||
- 任务结果通过 `chrome.storage.onChanged` 即时推送到平台；平台按任务合并为“当前正在持久化的一条 + 最新待处理的一条”，原 2.5 秒轮询继续作为断线/丢事件兜底。
|
||
|
||
- 生命周期 route preparation 用本地生成的一次性 128-bit token 只标记本次精确选中的 list/edit Document；后台 frame discovery 同时要求 token 与既有路径、marker、tid/ddid 条件，避免同一标签页的陈旧同路径 frame 造成假歧义。token 原值不进入 operation、日志或 ERP 请求，正式 preflight 仍再次校验唯一业务行/表单、状态与 ownership proof。
|
||
- 外部 Agent 返回 NEED_INPUT、有效 question prompts 但遗漏顶层 reply 时，平台仅把这些已校验 prompt 合成为展示回复；没有可展示 question 时仍失败关闭，不生成 operation 或派发插件。
|
||
- ERP 唯一解析后的取消按对象类型选择已验证路径：独立团/散拼母团走列表取消，散拼子单继续走编辑页；列表行必须唯一读出一个当前状态，状态缺失、冲突或已取消都在写前停止。
|
||
- 编辑页首道身份检查与正式 preflight 统一为“表单稳定引用优先、URL 参数回退”，兼容 ERP 的 tid/ddid 参数大小写与表单键差异；表单和 URL 冲突时拒绝，并在超时报告中只保留页面/表单/引用命中计数。
|
||
- 散拼母团没有子单时，酒店安排页会按 ERP 业务规则隐藏提交入口；插件只在“已解析为散拼母团 + ERP 页面明确显示无子团数据 + 提交入口缺失”三项同时成立时，返回可操作的“请先新增散拼子单”提示，其他缺少提交控件的异常仍保持原安全阻断。
|
||
- 全部业务通过共用结果状态机记录阶段耗时，并在每次 ERP 页面动作中区分脚本注入、浏览器往返、页面执行与无 URL 的网络等待聚合；计时只保留代码、状态、毫秒数和计数，控制面再次净化后加密保存完整回执并保留安全摘要。
|
||
- 产品与客户分别执行 ERP 唯一解析；来源地关键字仅保留客户侧候选辅助，不再强制要求产品与客户来源地相互匹配。
|
||
- 散拼母团创建收到 ERP 成功响应后，精确团号回查会清空无关筛选并进行有限延迟只读重查；任一团号仍未命中时转逐日期唯一回查，整个恢复过程不重新提交创建请求。
|
||
- 无编号独立团检索以客户 + 出发日期为主条件；客户支持中文分词匹配和日期回退。
|
||
- 产品与领队只作候选补充校验，不作为原生列表硬筛。
|
||
- SGL/TWN 房型映射到 `frenshu0/frenshu1`，成人/占床儿童/不占床儿童/领队四类人数映射到 `darenshu/xiaorenshu/ertrenshu/quanrenshu`，均有非负校验和 fresh 表单回查；这些新增映射仍待授权 ERP 实写复测。
|
||
- ERP 明确返回业务规则拒绝时保留原生提示，任务标记为业务阻断，不进入“结果不确定/待回查”，也不自动重试。
|
||
- 跨订单列表和计划列表合并候选后，再用已提供的产品/领队可见文本做二次筛选；仍不唯一时继续阻断，不猜选。
|
||
- 恢复/取消进入精确编辑页后读取当前状态；目标状态相同则返回“无需迁移”，只有状态不同才继续写入前门禁。
|
||
- 恢复订单按对象类型主动切换 ERP 原生【已取消】或母团【收客中】状态标签；状态标签由原生菜单点击触发，避免遗留筛选把已取消记录排除在候选集之外。
|
||
- 插件实际领取任务后 10 分钟无最终结果自动失败；启动/重载时清理过期运行态、无执行孤儿缓存和超过 30 分钟的残留当前任务指针，可能跨过 ERP 写入边界的记录保留只读回查，不自动重试。
|
||
- ERP 页面脚本注入前检查 host permission 和批准 origin；重定向到非白名单页面、站点访问被关闭或 Chrome 拒绝注入时 fail-closed，并回传可操作的诊断码，不再把原始权限异常当作普通导出失败。
|
||
- ERP 待机保活默认开启：Chrome alarm 约每 5 分钟在已有 ERP 标签页内发送一次带 Cookie 的只读 `GET /System/Mainlt.asp`；执行任务期间跳过，不新开标签、不刷新页面、不修改业务数据，可在插件面板单独关闭。
|
||
- ERP 只读探测发现会话失效、页面注入异常或链路失败时，在无插件执行任务且已有同源 ERP 标签页的前提下，按 2 分钟冷却最多自动绕缓存刷新一次现有标签页，并等待完成后再次只读复测；失败只保留告警，不自动重交业务任务。
|
||
- 其他未验证独立团字段保留在 operation 并转人工复核，不静默丢弃。
|
||
|
||
完整开放/阻断边界见 [生命周期发布门槛](../../agent设计规范/test-fixtures/lwlt-lifecycle/release-gate.md)。
|
||
|
||
## 本地加载
|
||
|
||
1. 打开 `chrome://extensions`。
|
||
2. 启用开发者模式。
|
||
3. 选择“加载已解压的扩展程序”。
|
||
4. 选择本目录 `chrome-extension/ltjt-order-assistant/`。
|
||
5. 每次源码或版本更新后在扩展管理页重载，并通过平台握手确认运行版本。
|
||
|
||
ZIP 仅用于交付，不从 ZIP 目录直接维护源码。
|
||
|
||
## 执行链
|
||
|
||
```text
|
||
平台领取任务
|
||
→ validateDispatchOperation
|
||
→ 找到已登录 ERP 页面
|
||
→ resolveLifecycleOperation / 资源解析
|
||
→ validateOperation 严格门禁
|
||
→ 原生页面操作
|
||
→ 明确服务端响应
|
||
→ 名单：明确成功即完成；其他业务：fresh requery
|
||
→ 结构化结果回传平台
|
||
```
|
||
|
||
零候选、多候选、页面身份不一致、登录失效、联动失败、状态不支持或提交不确定都必须在写前阻断或进入安全停止；名单明确成功即完成，其他业务回查不一致进入只读 reconciliation。不得自动重提同一写操作。
|
||
|
||
## 主要源码
|
||
|
||
| 文件 | 职责 |
|
||
|---|---|
|
||
| `background.js` | 平台桥接、任务领取、版本握手和调度 |
|
||
| `business-bridge.js` | 页面与扩展消息桥 |
|
||
| `operation-plans.js` | 前门禁、严格门禁和执行规划 |
|
||
| `operation-timing.js` | 全业务阶段计时、跨 Worker 恢复、边界与隐私净化 |
|
||
| `inpage.js` | ERP 页面发现、列表检索和业务路由 |
|
||
| `lifecycle-adapters.js` | 生命周期表单操作、写入和回查 |
|
||
| `team-batch*.js` | 独立团/散拼创建与批量执行 |
|
||
| `product-lookup.js`、`source-region.js` | 产品候选和客户候选解析；来源地仅作客户侧辅助 |
|
||
| `lifecycle-result.js`、`split-plan-reconciliation.js` | 结果统一与只读收敛 |
|
||
|
||
## 验证
|
||
|
||
```bash
|
||
node --check chrome-extension/ltjt-order-assistant/background.js
|
||
node --check chrome-extension/ltjt-order-assistant/inpage.js
|
||
npm run test:legacy
|
||
npm run check:repo
|
||
```
|
||
|
||
修改插件源码时必须递增 `manifest.json` 版本，同步平台最低版本、`mappings/lifecycle.mapping.json`、回归断言、版本化 ZIP 和 `dist/release-manifest.json`。真实 ERP 写入仍需用户针对本轮对象明确授权。
|