Files
LWLT-AIBOT/agent设计规范/test-fixtures/lwlt-lifecycle/release-gate.md

12 KiB
Raw Blame History

生命周期发布门槛

当前基线

  • Chrome 插件:0.5.167

  • Agent Promptltjt-agent-prompt-v1.8-independent-headcount-categories

  • 生命周期契约:ltjt-lifecycle-v2.9-roster-leader-contact-2026-08

  • 五个 Skill0.5.125;运营 DOCX0.5.125

  • 发布状态:核心窄能力已有真实证据;一笔名单附件 Program-only 任务已把 25 行及唯一领队联系人正确保存到 ERP后续只读逐字段核验全等。两种写后逐行读取方式都曾在真实成功写入后产生假阴性名单在全部写前门禁通过后以父表单 ERP 明确成功响应作为终结证据,不再执行写后逐行回查或自动名单对账。0.5.155 规定确认覆盖的指定序号同值也写;0.5.156 把原生游客位不足统一映射为包含名单人数和 ERP 实际上限的业务提示,原技术 blocker 仅留技术详情。0.5.157 新增散拼母团“整团游客信息”的 shared_plan + visitor-list + tid-only 窄分支,静态契约与回归已通过,仍待授权后的新版运行态只读复测。0.5.158 把正式控制面 https://lwlt.nianxx.cn 同步加入 Popup、后台、Manifest 权限和 content script 精确白名单;其他 HTTPS origin 仍保持阻断。0.5.159 修复 MV3 后台恢复被中断后持久化 running 永久阻断插件派发的问题:仅在内存恢复 Promise 已不存在时收敛为 interrupted,真实活动恢复仍保持阻断,下一次成功只读保活把状态归零为 idle0.5.160 为独立团单个下单写前漂移增加仅字段名诊断,并把数字后缀动态应收字段纳入保护。0.5.161 等待客户、跟单人和销售人原生 lookup 数据就绪后才开始单团预检;生产反馈证明仅检查 lookup 数据仍不足。0.5.162 进一步要求页面 jQuery Ajax 在预检前归零,并在 GetProduct 后等待原生 ajaxStop 再应用最终业务字段。0.5.163 按生产操作方明确要求恢复 0.5.156 的实际校验范围:核心订单字段继续写前阻断,带编号的动态 ys_* 应收行不再纳入保护哈希,允许 ERP 原生回调在预检后调整这些字段。0.5.164 新增平台账号、AgentBus 渠道、唯一云电脑 worker 与 ERP 登录身份四方一致门禁;旧未绑定渠道和历史未归属 AgentBus 任务默认不执行。0.5.165 让散拼新增计划和独立团批量下单在本地候选未命中时先使用表单原生非空产品检索,实测两类表单均能由完整关键词唯一返回目标产品;本轮未勾选或保存,自动选择与写入仍由原门禁保护。新增独立团房型/人数映射仍待实写;未验证宽能力继续失败关闭。

  • 0.5.166 在散拼母团列表入口加入立即检查、100ms 条件轮询和 15 秒总超时;每次探测都重新取得当前主 iframe document按钮一旦可用便立即继续。该等待只发生在点击前不固定拖慢快速页面也不触发业务写入重试。

  • 0.5.167 保留插件侧的空闲证明和受控重载安全协议,并继续包含 0.5.166 的散拼入口自适应等待。中央服务私有 OSS/ECS 云助手编排及迁移 019 已按用户决定从主线撤回,因此这些插件更新消息在当前主线没有服务端触发方,属于休眠能力;插件仍按现有人工发布/加载流程使用。

运行中的浏览器版本必须实时握手确认。当前制品文件名和 SHA-256 只看 ../../../dist/release-manifest.json,不从历史日志推断。

已证明的核心能力

能力 当前边界
创建 独立团单个/批量、散拼母团单个/批量及具体子单;批量逐日期保留响应和回查
名单 独立团和具体散拼子单;文字定位后等待单个 .xls/.xlsx,程序在前 100 行自动识别唯一 ERP 字段表头及其下连续名单,规范化为 13 列 TSV 并固定 Program-only支持明确序号的动态扩行、安全合并、同值幂等和覆盖确认。解析阶段不以初始 16/31 行作统一上限;执行时若原生页实际物化游客位不足,则在保存前以人数/上限业务提示阻断。2026-08-28 已只读确认一笔具体散拼子单的 25 行及领队联系人真实持久化全等;另一次独立团 25 人只物化 16 位且未保存
安排 导游、车辆、酒店、大交通、其他/备案 create/clear酒店新增状态为未安排
独立团修改 twin_room_count 已真实持久化SGL/TWN 与成人/占床儿童/不占床儿童/领队人数已接入映射/回查但待新版本实写
散拼修改 母团 planned_capacity、具体子单最终长度 ≤50 的 lodging_note
酒店安排修改 唯一未安排/未确认酒店行的离店日期和/或房间数
状态 独立团/母团取消按唯一列表行读取状态后使用已验证列表路径,具体子单取消及三类恢复使用精确编辑页;母团恢复后子单单独核验
团队文件 独立团/具体子单“游客名单”按 did+tid,散拼母团“整团游客信息”按 tid-only,后者只允许单一游客类型且拒绝子单引用;读取并校验 ERP 文件源,游客源 XLS 归档并生成真实 XLSXAgentBus/微信只返回 XLSX其余类型转 PDF、失败回退源文件生产配置下保存到 OSS 并返回公共读取 URLXLSX 转换失败时阻断外部附件交付;不代表定时或发送。母团新分支仍待新版运行态只读复测
删除 仅授权测试清理,要求对象标记、账号归属、允许清单、子单缺席和最终 fresh absence requery

真实运行的逐项覆盖结论见 运营需求能力矩阵,仍影响发布的风险见 风险登记

当前对象定位规则

  • 有完整团号/子单号时走精确编号路径。
  • 无编号独立团以预订客户 + 出发日期为主定位;客户原生筛选无结果时允许日期回退,再做中文分词客户匹配。
  • 产品和领队为选填候选补充校验,不进入独立团列表硬筛。
  • 散拼子单先解析母团,再在具体子单候选中校验客户、产品和领队;新增子单客户不作为母团客户筛选。
  • 无具体子团的散拼母团没有预订客户;计划收客数修改只强制出发日期。
  • 安排和安排变更继续要求团号。

任何需要唯一候选的路线出现零候选或多候选都在写前停止。酒店、大交通、其他/备案的统一选择框是明确例外:零候选停止,多候选按 ERP 下拉顺序默认第一条并由原生选择联动带入只读字段。

仍需实写复测

0.5.156 延续以下独立团目标的 ERP 原生字段、非负整数校验、写前快照和 fresh 回查,并保留名单动态游客行;名单未确认覆盖时,任一目标序号已占用(包括同值)都先停止并要求确认;full_replace + confirmed=true 后,所有附件指定序号都进入覆写集合,并在 DaoRuDones 后按原生去空白规则重写 pinyinxm,不再以“当前值相同”取消用户写入要求。若 DaoRuDones 物化的游客位少于名单所需数量,保存前以 erp_passenger_count_limit_exceeded 阻断,用户只看到名单人数和 ERP 上限,技术 blocker 保留在详情。若名单有唯一严格领队备注行,还会在恢复四个接送字段快照后只将该行姓名/电话投影到jj_lianxiren/jj_dianhua,并要求游客行和领队联系人在父表单保存前全部精确匹配。名单保存后不再逐行读取;父表单 ERP 明确返回成功即完成。以下独立团房型/人数映射仍待实写。同时保留酒店安排变更回填日期的 ISO 规范化及空备注字段校验:

  • rooms.SGL → frenshu0
  • rooms.TWN → frenshu1
  • pax.adult → darenshu
  • pax.child_bed → xiaorenshu
  • pax.child_no_bed → ertrenshu
  • pax.leader → quanrenshu

这些新增映射在本版本制作期间没有真实 ERP 保存。取得授权前只能进行静态、dry-run 或只读检查,不能把映射存在视为真实持久化证据。

继续失败关闭

  • 独立团日期、客户、团号、产品、备注、行程、OP/销售、航班、接送机及其他未逐字段验证的宽修改。
  • 非酒店安排 update酒店入住日、酒店、房型、备注和确认/落实/出票等状态变更。
  • 自动触发、外部发送或通知。
  • 客户、产品、导游、酒店、供应商等主数据维护。
  • 真实收款、结算、采购、付款、审核及其他财务动作。
  • 把代表对象验证外推为每个批量对象都完成了完整后续生命周期。

安全门槛

  • Agent/Skill 只输出解析态业务事实ERP 内部引用和当前值由插件只读解析。
  • 修改类只接收目标值;系统自行读取当前值并形成 before/after不向用户索取旧值或内部 ID。
  • 写入前必须通过 action/Schema、对象归属、页面身份、状态、字段白名单和页面联动校验。
  • ERP 唯一解析后的取消按对象 kind 固定选路;列表状态必须唯一,编辑页身份优先由表单稳定引用证明并以 URL 参数作回退,引用冲突继续失败关闭。
  • route preparation 只以一次性不透明 token 把已精确选中的 Document 交给后台 frame discoverytoken 不进入业务 operation、日志或 ERP 请求,正式 preflight 仍再次执行完整引用、状态与 ownership 门禁。
  • 除名单录入外,写入后必须同时有明确服务端响应和 fresh requeryHTTP 200、弹窗或文件源响应不能单独证明完成。名单录入必须先通过附件、对象身份、覆盖确认、游客与领队完整写前投影并且只以父表单 ERP 明确成功响应作为完成证据;不做写后逐行回查或自动名单对账。
  • 目标值已等于当前值时不派发字段事件,write_attempted=false
  • 其他业务写入不确定时先只读回查同一 execution禁止自动重试仍无法确认时面向用户明确显示“请勿重复提交等待管理员核验”。名单若没有取得 ERP 明确成功响应则不宣称成功,也不自动重提。

正式放行条件

  1. 业务负责人明确接受“按已验证窄能力分批放行”以及人工复核边界。
  2. 当前版本通过 TypeScript、控制面、插件/解析/生命周期、仓库卫生、Skill、ZIP/Skill 源码一致性和 DOCX 渲染门槛。
  3. 新增 SGL/TWN 与四类人数只有在授权对象上取得明确响应与 fresh before/after 后,才可升级为已真实验证。
  4. 任何未通过项继续失败关闭,不为追求全绿扩大业务范围。

不可变证据