LWLT-AIBOT/archive/research/2026-08-10/ltjt_order_lifecycle_research.md

LTJT 订单生命周期 ERP 深度调研

调研日期：2026-08-10
当前阶段：静态页面/历史探针/插件契约复核；未执行新的 ERP 写入。
业务范围：运营梳理第 10–21 项。

1. 调研结论先行

ERP 的真实业务主线不是一组互相独立的按钮，而是一张订单从建立到履约再到交付文件的生命周期：

flowchart LR
    A["下单基线<br/>独立团 / 散拼母团"] --> B["名单导入或补充"]
    B --> C["团队安排<br/>导游 / 车辆 / 酒店 / 大交通 / 其他"]
    C --> D{"业务变化"}
    D -->|继续履约| E["修改与状态维护"]
    D -->|取消| X["取消分支<br/>收款与状态联动"]
    E --> F["最终确认快照"]
    X --> F
    F --> G["确认件/备案源读取"]
    G --> H["文件转换与交付<br/>另行确认状态"]

本轮最重要的设计判断：

1. “名单导入”是下单后的订单详情/子单操作，不应被做成独立于订单的泛化导入工具。
2. “安排”是既有团队主单上的资源履约层，不是再次创建订单；五类安排必须分别确认页面、字段、保存 action 和回查入口。
3. “修改”和“取消”是跨阶段分支，必须带着既有订单引用、当前状态和变更前快照执行，不能只凭产品名或日期定位。
4. “导出”是生命周期最后的只读源读取；收到 ERP 响应不等于文件已落盘，更不等于已经发送给客户。
5. Skill 的正式可执行能力应建立在 ERP 页面范式之上：进入原生页面/iframe → 使用页面自身联动和序列化 → 观察保存结果 → 回查列表/详情，而不是臆造一个简化 API。

2. 证据等级与当前边界

等级	含义	本轮可用范围
L0	业务人员操作说明或用户确认	第 10–21 项的业务顺序、字段意图、导出种类
L1	ERP 静态页面、脚本和 API inventory	页面路径、列表请求、已出现的 action、参数名
L2	历史浏览器探针/归档脚本	iframe、控件候选、旧字段位置、历史下载行为；必须重新验证
L3	当前部署真实提交并逐条回查	独立团单个、独立团批量；散拼下单按用户确认及现有回查记录计成功
L4	当前登录态的实时只读或请求录制	已取得当前登录态的团队安排总表、五类安排页、团队详情和计划/子单修改页快照；五类安排原生保存请求已在网络发送前录制并阻断，9 类导出源已读取响应头/长度/内容特征，真实保存回执/写后回查、名单导入和取消提交仍未录制

当前不能把 L1/L2 当作写入成功证据。尤其是旧探针中的固定 input 下标、详情页补充字段和历史 ERP 域名，都不能直接迁移到生产适配器。

3. 生命周期模块矩阵

业务项	业务动作	ERP 入口/页面候选	当前已知保存/查询	当前插件/Skill 状态	下一步必须采集
10	独立团单个下单	/System/Business/orders.asp → orders_add.asp	POST /System/DAT/orders.asp，Act=DoInfoJH；保存后按团号回查	team_order_create 已真实验证	当前主单字段、默认值、名单入口、安排入口的引用传递
11	独立团批量下单	orders_adds.asp	原生 Act=DoInfoJHs；现有记录为一表提交、三组回查	team_order_batch_create 已真实验证	批量结果与后续每组 ddid/tid/tdid 绑定，避免只保留首条
12	散拼团单个计划/下单	/System/Business/plan.asp → plan_add.asp	Act=DoInfoSPs；现有回查记录与用户确认均计成功	shared_plan_create 已接入、已同步登记为已真实验证	区分母团计划与子单；后续名单/子单补录仍走生命周期中段
13	散拼团批量计划	plan_add.asp 的日期范围/周期控件	计划列表 Act=SP_OrderList；提交 action 需以当前页面录制为准	母团创建路径已有，但单/批量覆盖需分开记	日期范围、周期、每天计划数、每个母团号逐一回查
14	独立团名单导入/补充	独立团列表 → 修改团队 → daoru.asp 对话框	对话框 textarea#DaoruText 的“确定导入”只调用父页 DaoRuDones()，不发 ERP 请求；最终由独立团 DoInfoJH 保存	passenger_list_import 仅预览/阻断	表头解析、现有行覆盖/不自动增行、人数与行数校验、保存后回查
15	散拼子单名单导入/补充	母团/子单 → plan_order.asp?tdid=... → daoru.asp	对话框同一套 DOM-only 导入逻辑；最终由子单 DoInfo_order 保存，已完成原生请求只读拦截	兼容子单路径存在；Skill 尚未发布业务入口	表头解析、现有行覆盖/不自动增行、名单归属、保存后回查
取消	独立团/散拼团取消	主表、团队修改页、子单修改页	独立团批量取消原生请求已只读拦截：POST /System/DAT/orders.asp，Act=JH_set_quxiao，cz=1/0；独立团删除为 DelRecord，散拼子单/计划删除为 Del_order；实时各编辑页均有“已取消”状态控件	无正式 order_cancel action；取消/删除仍阻断	区分删除/单条取消/批量取消/状态取消；页面路线差异、状态前置、应收款处理、安排资源副作用、导出后状态
修改	独立团/散拼团信息修改	独立 orders_add.asp；散拼 plan_update.asp/plan_order.asp	三条原生保存请求均已只读拦截：独立 DoInfoJH（821 字段）、母团计划 DoInfoSP（642 字段）、子单 DoInfo_order（495 字段）；均带页面自身隐藏引用与 script 响应	order_update 仅只读预览	窄字段写入、变更前后快照、主单/子单联动、真实响应/回查、失败回滚边界
16	团队安排后确认件/业务文件	订单详情/团队详情的导出链接	已实时读取 9 类源：联泰/星游/导游确认/备案/接机牌为 application/vnd.ms-word，游客名单为 application/vnd.ms-excel 但内容特征为 HTML 表格，酒店/大交通预订单为 text/html 打印页；均为 200，本轮只读内存响应	confirmation_export 只读源读取	建立文件交付状态、转换/落盘/发送契约；不把打开链接或 200 响应当作发送成功
17	大交通/票务安排	teams_piao.asp；另有 tickets.asp 控位表	已只读拦截原生 InfoForm1：POST /System/DAT/team.asp?Act=DoInfo_piao，296 字段/292 唯一字段、13 行资源；供应商联动 ProDanweiZCxm&leibie=5，价格联动为票务 set_price，状态含已确认/未确认/自损/取消/出票	lwlt-arrangement 仍只识别后阻断	真实响应判定、行级唯一匹配、状态联动、保存后总表/子页回查、团队票务申请导出
18	酒店安排	teams_jiudian.asp；酒店总表 Hotels.asp	已只读拦截原生 InfoForm1：POST /System/DAT/team.asp?Act=DoInfo_jiudian，206 字段/202 唯一字段、7 行资源；联动含 ProDanweiZCxm/set_price，状态为已确认/未确认	lwlt-arrangement 仍只识别后阻断	真实响应判定、行级唯一匹配、已付款可写边界、保存后子页/总表回查、预订/变更模板
19	陆地车辆安排	teams_cheliang.asp	已只读拦截原生 InfoForm1：POST /System/DAT/team.asp?Act=DoInfo_cheliang，147 字段/143 唯一字段、5 行资源；供应商联动 ProDanweiZCxm&leibie=2，价格联动为车辆专用 set_price	lwlt-arrangement 仍只识别后阻断	真实响应判定、控件标签↔name 精确映射、行级唯一匹配、已付款可写边界、保存后子页/总表回查、预订/变更模板
20	备案/其他资源	teams_qita.asp；备案表 teams_beians.asp	已只读拦截原生 InfoForm1：POST /System/DAT/team.asp?Act=DoInfo_qita，266 字段/262 唯一字段、12 行其他成本；同一载荷还含备案号/日期/口岸/导游司机资料，状态/落实和备案导出仍需分层建模	lwlt-arrangement 仍只识别后阻断	真实响应判定、其他成本与备案资料的更新边界、保存后子页/总表/备案表回查
21	导游安排	teams_daoyou.asp	已只读拦截原生 InfoForm1：POST /System/DAT/team.asp?Act=DoInfo_daoyou，17 字段/17 唯一字段、2 个导游槽位；选项联动含员工/导游资源和等级	lwlt-arrangement 仍只识别后阻断	真实响应判定、导游唯一匹配、落实状态联动、保存后主表/子页双重回查

4. 跨生命周期公共引用

每个阶段都应该接收和返回同一个引用上下文，至少包含：

{
  "group_no": "业务可见团号",
  "order_no": "订单号（如有）",
  "parent_group_no": "散拼母团号（如有）",
  "child_order_no": "散拼子单号（如有）",
  "ddid": "订单详情内部引用",
  "tid": "团队/计划内部引用",
  "tdid": "团队安排/详情内部引用",
  "source_page": "当前 ERP 页面或 iframe",
  "resolved_at": "引用解析时间"
}

引用规则：

• 产品名、出发日期、客户名只能用来缩小列表或候选，不能作为后续写入的唯一定位。
• 创建后必须保存完整结果列表；批量任务要为每个日期/每个团号保留独立回查状态。
• 从主单进入名单、安排、修改、导出时，优先复用页面链接中已经解析出的 ddid/tid/tdid，再用列表回查确认业务团号。
• 散拼必须区分母团计划与子单：母团可以作为后续定位上下文，但不能直接当客户确认件订单导出。
• 任何引用解析到多个候选、无候选或跨业务类别候选时，必须阻断，不选择第一条。

5. 各阶段的 ERP 兼容契约

5.1 下单基线

• 使用 ERP 原生新增页面和页面联动，保留客户/产品 SelectBox 的唯一匹配，不把复合业务简称直接交给后端模糊查询。
• 产品点选后必须执行页面自身的“更新行程/联动”逻辑，再检查团号、客户、人数、房型和行程字段。
• 提交前拦截并记录页面原生 DoInfoJH、DoInfoJHs 或 DoInfoSPs 分支；提交后解析响应并按业务引用回查。
• 散拼可选客户/人数字段只在用户提供时写入；不因缺失可选字段而虚构或覆盖 ERP 默认值。

5.2 名单导入

• 先读取当前订单详情/子单的名单表结构和已有已填行数，明确本次是首次导入还是追加。
• 优先使用页面提供的导入对话框和确认动作；不要把 TSV/Excel 列序直接映射成固定 input 下标。
• 证件号、电话、出生日期等敏感字段必须按表头/行作用域确认；历史电话偏移已被列为高风险。
• 保存后的最小回查是：目标订单引用仍一致、名单行数变化符合预期、旧行未被意外覆盖、页面没有登录超时/权限错误。

5.3 团队安排

每一个资源子模块都必须形成同样的六件套：

1. 主单到子页的进入方式和 tdid 解析。
2. 资源字段与 ERP 控件/下拉选项的映射。
3. 供应商、资源、状态的唯一匹配规则。
4. 页面原生保存函数或 POST action 的完整请求形状。
5. 保存响应、弹窗、重定向和错误文本的判定。
6. 从团队安排表和对应子页的双重回查。

特别注意：订单详情中的 ban* 航班字段、zhusus* 住宿说明或接送机字段目前只能算“行程补充信息候选”，不得因为历史 writer 能写入就认为完成了大交通/酒店/车辆安排。

5.4 修改与取消

• 修改使用窄范围白名单：用户说改什么才改什么，先读取旧值，生成 before/after，再提交；不把整个 800 控件表单重写一遍。
• 修改字段建议按风险分层：备注/行程文本 → 房型/人数 → 价格/应收 → 主团号/日期/客户/产品 → 资源安排。越靠后越需要更强的确认和回查。
• 取消必须单独建模，不把取消降级为普通修改或删除。先确认 ERP 的“取消”与 DelRecord 的区别，再确认应收款清理、资源安排状态和导出权限的联动。
• 取消/修改失败时保留变更前快照和原始响应，不自动重试、不假设事务回滚；若 ERP 没有回滚能力，Skill 必须把人工复核列为结果状态。

5.5 最终确认与文件交付

当前已确认的只读源：

标准类型	ERP 源	参数
liantai-confirm	/System/Business/orders_confirm_new.asp	did/ddid + tid
xingyou-confirm	/System/Business/orders_confirm_news.asp	did/ddid + tid
job-order	/System/Business/teams_beian1.asp	did/ddid

执行边界：

• 先读取源响应摘要、content-type、content-disposition、长度和文件内容特征，再决定是否转换。
• .doc/DOCX/PDF 转换与客户发送是独立阶段；转换失败时保留原始源文件/源摘要，不重新保存订单。
• agent_parse_passed 只代表导出任务可交给执行器；不能表示已生成、已下载或已发送。
• 导游通知、接站牌、游客信息、酒店预订单、备案确认等业务文件必须先在当前 ERP 中找到实际链接/页面，再纳入标准 export_types，不能仅凭用户文案扩展别名。

本轮已经完成一次当前团队的只读源响应采集：

导出标签	ERP 路径	当前响应证据
整团游客信息	/System/Business/orders_Visitor.asp?tid=<tid>	200；application/vnd.ms-excel；12,036 字节；首字节为 HTML 文档头，属于 HTML-in-XLS wrapper
导游确认单	/System/Business/teams_confirms_new.asp?tid=<tid>	200；application/vnd.ms-word；77,988 字节；HTML/XML 风格 Word 响应
酒店预订单	/System/Business/teams_hotel_confirm.asp?tid=<tid>	200；text/html；2,837 字节；标题为出团行程表、无独立下载响应头
大交通预订单	/System/Business/teams_piao_confirm.asp?tid=<tid>	200；text/html；7,503 字节；标题为出团行程表、无独立下载响应头
客户确认单-联泰	/System/Business/orders_confirm_new.asp?did=<ddid>&tid=<tid>	200；application/vnd.ms-word；36,967 字节；HTML/XML 风格 Word 响应
客户确认单-星游	/System/Business/orders_confirm_news.asp?did=<ddid>&tid=<tid>	200；application/vnd.ms-word；41,236 字节；HTML/XML 风格 Word 响应
游客名单	/System/Business/orders_Visitor.asp?did=<ddid>&tid=<tid>	200；application/vnd.ms-excel；与整团游客源同为 HTML-in-XLS wrapper
备案表（当前链接）	/System/Business/teams_beian.asp?did=<ddid>	200；application/vnd.ms-word；227,979 字节；HTML/XML 风格 Word 响应
备案表（历史/并列源）	/System/Business/teams_beian1.asp?did=<ddid>	200；application/vnd.ms-word；158,204 字节；HTML/XML 风格 Word 响应；不可与当前链接合并
接机牌	/System/Business/teams_confirm_pai.asp?xingming=<name>	200；application/vnd.ms-word；41,140 字节；依赖游客姓名 query，必须从已定位订单行生成，不能让用户输入模糊姓名

以上只保留了路径模式、状态、响应头、长度和内容特征；没有下载到本地、转换、发送或回写 ERP。响应哈希仅用于验证同一请求重放时是否发生变化，不能当作文件交付凭证。

6. 当前能力与缺口

已有可靠基线

• 独立团单个下单：当前插件使用原生页面，保存后按团号回查。
• 独立团批量下单：当前扩展记录为原生 orders_adds.asp/DoInfoJHs，已完成授权案例的逐组回查。
• 散拼团计划：用户已明确“散拼团下单也算成功”，现有研究记录包含创建与回查结果；业务适配登记表仍需同步该状态。
• 确认件源读取：联泰/星游/JOB 三类 source-only 路径已经接入，且保持不重存边界。

尚未达到可执行发布标准

• 名单导入/补充：已取得导入对话框、表头驱动解析、覆盖/不增行语义，以及独立团/散拼子单后续保存 action 的 L4 证据；仍缺真实保存回执、行数/覆盖回查和失败边界。
• 导游、车辆、酒店、大交通、其他/备案：五类页面均已完成原生保存请求的只读拦截；所有模块仍缺真实响应判定、资源唯一匹配、保存后子页/总表回查和可发布的变更模板。
• 修改：已取得独立团、散拼母团计划、散拼子单三条原生提交契约的只读拦截；仍缺正式字段白名单、真实响应、主单/子单回查和失败/回滚边界。
• 取消：已区分独立团批量取消、独立团删除、散拼子单/计划删除和编辑页“已取消”状态；仍缺真实状态提交、应收/安排联动、导出权限和可逆性。
• 文件交付：已取得当前 9 类源的响应类型、长度和内容特征；仍缺转换验证、落盘路径、发送状态和失败重试模型。

7. 下一轮实时调研采集表

需要一个已登录、可授权测试的 ERP 会话；建议从一个低风险、可人工复核的测试团队开始，按以下顺序逐项录制：

顺序	采集动作	必留证据	不做什么
1	从订单列表打开一个已有独立团和一个已有散拼子单	列表行、详情 URL、ddid/tid/tdid、iframe 层级	不凭日期猜引用
2	只读打开名单导入入口并读取解析函数	表头、已有行数、DaoruText、确认回调、父页解析字段映射	不导入真实敏感名单
3	逐一打开导游/车辆/酒店/大交通/其他子页	URL、字段名、资源选项、状态、隐藏 id、保存按钮	不把订单详情补充字段当子页字段
4	对安排子页做预检/请求捕获	原生函数、POST action、完整字段序列、响应与回查	未确认测试对象前不提交
5	只读打开修改页并建立字段快照，再拦截页面原生提交	修改前值、控件 name/id、原生 action、主单/子单引用、序列化字段形状	不改变值、不做全表单覆盖写入
6	先观察取消入口和权限/状态提示	DelRecord 与 JH_set_quxiao 的差异、收款/资源影响	不在生产团上测试取消
7	读取所有确认/业务文件链接	URL、响应头、文件格式、源内容摘要	不把收到响应误报为交付

每次实时采集都要记录：ERP 域名/部署、账号权限范围、页面 URL、iframe URL、请求 method/action、脱敏字段名、响应判定、回查结果、失败原因和时间。不要记录 Cookie、口令或完整旅客证件信息。

8. Skill 建设建议（仅作为后续实现输入）

在实时证据齐全并再次确认 action 命名后，建议把中段能力拆成独立契约：

• passenger_list_import：订单/子单上下文内的首次导入与追加导入。
• order_update：独立团和散拼团共用引用模型，但按字段白名单和页面路线分支。
• order_cancel：独立 action，不复用删除或普通修改。
• arrangement_guide、arrangement_vehicle、arrangement_hotel、arrangement_transport、arrangement_other：一类资源一个页面适配器和回查器。
• confirmation_export：继续只读源读取；文件转换、落盘和发送作为独立交付状态，不混入 ERP 保存。

这些名称目前是研究建议，不代表已经写入 standard_system_operation.schema.json。当前已补齐资源安排五页、计划修改、散拼子单修改和名单导入入口的字段与原生 action 只读证据，但在真实响应/回查、字段白名单、请求失败边界和取消语义完成前，现有 Skill 继续稳定阻断是正确的安全边界。

8.1 建议的下一阶段开展顺序

建议按“低副作用、对象清晰、容易回查”逐步放开，而不是同时开发全部中段能力：

1. 先做名单导入预检契约：读取人数/现有游客行、解析表头、生成覆盖差异和敏感字段校验；第一版仍只输出预览。
2. 以导游安排作为第一个可验证资源适配器，再按车辆 → 酒店 → 大交通 → 其他/备案扩展；每个模块都必须先在测试团队完成 preflight → 原生提交 → 总表/子页回查 闭环。
3. 修改先开放备注/非财务低风险字段，独立团、母团计划、散拼子单分别维护白名单；人数、房型、价格、日期、客户和状态必须后置并单独确认。
4. 取消/删除最后做：先建立只读状态机和影响预览，再引入显式二次确认、幂等保护和人工复核结果；在此之前所有 JH_set_quxiao、DelRecord、Del_order 真实提交继续阻断。
5. 导出先保持 source-only，补齐 HTML-in-XLS/Word-compatible/HTML print page 的转换和交付状态后，再讨论落盘或发送；导出不触发订单保存。

每个可执行 operation 的统一结果建议至少包含：resolved_refs、before_snapshot、preflight、native_request、server_response、requery、side_effects、manual_review_required。缺少真实响应或回查时，结果只能是 preflight_passed/blocked，不能宣称 succeeded。

9. 当前登录会话补充：安排、修改与名单导入的实时边界

本轮从已授权 ERP 会话沿着 团队安排总表 → 团队详情 → 散拼子单修改 继续读取，得到以下可用于下一阶段契约设计的证据：

• 安排不是一个总表写入动作，而是导游、车辆、酒店、大交通、其他/备案五个子页对象；每个子页都有自己的资源行、状态/落实控件和保存按钮，并共享团队/子单只读上下文。
• 计划修改和散拼子单修改是两条页面路线。计划页维护主团日期、业务、产品、收客状态、计划人数/用房、行程、文件和分账/备注；子单页维护客户、OP/销售、状态、人数、备案、航班、接送机、应收团款和游客表。
• 子单页的名单入口打开“导入游客【全部】数据”对话框；确定导入 通过 frameElement.api.opener.DaoRuDones($.trim($("#DaoruText").val())) 把表头驱动的解析结果写回父页面游客表，本身不发 ERP 请求，最终保存走已确认的 DoInfo_order。
• DaoRuDones() 按第一行表头识别序号、姓名、英文名/拼音、性别、生日、年龄、出生地、证件、签发地/日期、有效期、电话和备注；从已有 tr[id^='youke'] 行的第 1 行开始覆盖，超过现有行数即停止，不自动增行；清空 只清除游客表文本输入。
• 子单页同时显示“已取消”状态控件、“删除订单”和“提交保存”；这足以把取消与删除分成两个研究对象，但不能替代真实测试来证明状态迁移和资源/财务联动。
• 独立团列表的批量取消在零选择时只弹前置校验提示；独立团与散拼子单的状态控件 value/组合文案也不完全一致，状态适配必须依赖页面字段名和 checked 状态，而不是抽象数字枚举。
• 团队详情和安排页已经提供至少九类业务文件源；本轮已只读采集响应头、长度和内容特征，后续只剩转换/落盘/发送状态模型，不能把本次内存读取当作文件交付。

酒店安排请求契约（只读拦截）

页面: /System/Business/teams_jiudian.asp?tdid=<tdid>
表单: InfoForm1
请求: POST /System/DAT/team.asp
动作: Act=DoInfo_jiudian
载荷: Act=DoInfo_jiudian&$("#InfoForm1").serialize()
响应: script（真实响应尚未读取）
行模型: 0..6 的固定酒店资源行
回查: /System/DAT/team.asp?Act=PrintGridLists + 重新读取 teams_jiudian.asp?tdid=<tdid>

这条证据说明酒店适配器可以开始做“表单快照/字段白名单/提交拦截/回查”四件套，但在拿到服务端响应和写后回查之前，不能把它登记为已执行能力。

车辆安排请求契约（只读拦截）

页面: /System/Business/teams_cheliang.asp?tdid=<tdid>
表单: InfoForm1
请求: POST /System/DAT/team.asp
动作: Act=DoInfo_cheliang
载荷: Act=DoInfo_cheliang&$("#InfoForm1").serialize()
响应: script（真实响应尚未读取）
行模型: 0..4 的固定车辆资源行
联动: ProDanweiZCxm(leibie=2) + set_price(车辆)
回查: /System/DAT/team.asp?Act=PrintGridLists + 重新读取 teams_cheliang.asp?tdid=<tdid>

大交通安排请求契约（只读拦截）

页面: /System/Business/teams_piao.asp?tdid=<tdid>
表单: InfoForm1
请求: POST /System/DAT/team.asp
动作: Act=DoInfo_piao
载荷: Act=DoInfo_piao&$("#InfoForm1").serialize()
响应: script（真实响应尚未读取）
行模型: 0..12 的固定车票/控位资源行
联动: ProDanweiZCxm(leibie=5) + set_price(票务)
状态: 已确认 / 未确认 / 自损 / 取消 / 出票
回查: /System/DAT/team.asp?Act=PrintGridLists + 重新读取 teams_piao.asp?tdid=<tdid>

本次在不改动表单值的情况下调用页面原生 SubmitInfoForm() 并拦截网络，捕获到 1 个 DoInfo_piao 分支：序列化字段 296 个、292 个唯一字段，method=POST、dataType=script，网络发送为 0。表单包含 tdID/session_id、主团日期/人数、13 行票务字段，以及每行的日期、结算单位、票/控位说明、币种、数量、单价、现付、结算、状态、备注和审计字段。此次只记录字段名、数量和载荷 SHA-256（6847 字节，5f40d6b3231675a4ae7b0c1e62572e4eebb9d517d446ffa96d34d19f5a48c0c4），不记录票号、客户或财务原值。

其他/备案安排请求契约（只读拦截）

页面: /System/Business/teams_qita.asp?tdid=<tdid>
表单: InfoForm1
请求: POST /System/DAT/team.asp
动作: Act=DoInfo_qita
载荷: Act=DoInfo_qita&$("#InfoForm1").serialize()
响应: script（真实响应尚未读取）
行模型: 0..11 的固定其他成本行
备案附加字段: beianhao/beianri/rujingkou/chujingkou + daoyou/siji 及证件资料
联动: ProDanweiZCxm(leibie=7) + set_price(其他)
回查: /System/DAT/team.asp?Act=PrintGridLists + teams_qita.asp?tdid=<tdid> + teams_beian.asp?did=<did>

在不改动表单值的情况下调用页面原生 SubmitInfoForm() 并拦截网络，捕获 1 个 DoInfo_qita 分支：序列化字段 266 个、262 个唯一字段，method=POST、dataType=script，网络发送为 0。当前 ERP 把其他成本行和备案资料放进同一保存载荷，但备案表导出仍是独立链接，适配器要在业务模型上保留两层对象。载荷摘要为 6082 字节，SHA-256 为 2de1bb1088577ab397d8b2cb2456e8228b8001ade7f8d0d309eca7b35ae05fa6；未记录客户或证件原值。

导游安排请求契约（只读拦截）

页面: /System/Business/teams_daoyou.asp?tdid=<tdid>
表单: InfoForm1
请求: POST /System/DAT/team.asp
动作: Act=DoInfo_daoyou
载荷: Act=DoInfo_daoyou&$("#InfoForm1").serialize()
响应: script（真实响应尚未读取）
槽位模型: 0..1 的两个导游槽位
字段: daoyou/daoyouid/dianhua/dengji/beizhu + daoguan + ap_dy + tdID/session_id
联动: ProDanweis(leibie=1) + ProDanwei_Yuangong + 等级 初级/中级/高级
回查: /System/DAT/team.asp?Act=PrintGridLists + 重新读取 teams_daoyou.asp?tdid=<tdid>

调用原生 SubmitInfoForm() 并拦截到 1 个保存分支：序列化字段 17 个、17 个唯一字段，method=POST、dataType=script，网络发送为 0。当前 ap_dy 未勾选，因此它不在本次原生序列化结果中；正式适配必须按页面的 checked 状态决定是否提交落实标志。载荷摘要为 300 字节，SHA-256 为 e7a583191d039ee04c399ce49b631712820cd0a1e35359f2d59fc91c49efdfef。

9.1 修改请求契约：独立团

页面: /System/Business/orders_add.asp?ddid=<ddid>
表单: ListForm
请求: POST /System/DAT/orders.asp
动作: Act=DoInfoJH
响应: script（真实响应尚未读取）
表单控件: 826
只读拦截序列化: 821 字段 / 821 唯一字段
核心引用: ddid + tdid + session_id
核心字段族: 日期、组团社、产品、OP/跟单/销售、订单状态、人数、游客文本、航班、接送机、行程、应收款和游客表
回查候选: JH_OrderList + 订单详情/团队详情

本轮在不改动独立团修改页现有值的情况下调用原生 SubmitInfoForm() 并拦截网络，捕获 1 个 DoInfoJH 分支；序列化 payload 13743 字节，SHA-256 为 609a6f9e8f8631d59e3c2888bb91b30be4b395709ef76064ce44a6ffffa749a9。这证明“修改”仍是一个包含行程、应收款和游客表的宽表提交，正式 Skill 必须在其上层生成窄字段白名单和 before/after 预览，不能直接把 821 个字段当作用户意图。

9.2 修改请求契约：散拼母团计划

页面: /System/Business/plan_update.asp?tid=<tid>
表单: ListForm
请求: POST /System/DAT/plan.asp
动作: Act=DoInfoSP
响应: script（真实响应尚未读取）
表单控件: 645
只读拦截序列化: 642 字段 / 642 唯一字段
核心引用: tdid + session_id（母团 tid 同时体现在入口上下文）
核心字段族: 出发日期、专线/产品、天数、收客状态、计划负责人、计划/各类人数、团队编号、15 天行程和餐饮/住宿/景点字段、文件/说明
取消相关控件: `shoukezhuangtai` 的页面值包含 收客中 / 已停止 / 已取消
回查候选: SP_OrderList + plan_List.asp?tid=<tid> + 团队详情

原生提交请求在网络发送前被拦截，payload 29043 字节，SHA-256 为 0085f88fe4bc35428f9cccf601c58ab172f8b1ec1ac15d1e7423b439573802b2。本轮没有切换“已取消”或提交，因此只证明页面状态字段和保存 action 的关系，不证明取消后的资源/财务联动。

9.3 修改请求契约：散拼子单

页面: /System/Business/plan_order.asp?tdid=<tdid>&ddid=<ddid>
表单: ListForm
请求: POST /System/DAT/plan.asp
动作: Act=DoInfo_order
响应: script（真实响应尚未读取）
表单控件: 500
只读拦截序列化: 495 字段 / 159 唯一字段（旅客/应收行使用重复 name）
核心引用: tdid + oldtdid + ddid + session_id
核心字段族: 组团社/联系人/OP/销售/客源地、订单状态、人数、备案、航班、接送机、应收款 0..4、游客字段和游客文本
状态控件: `danzhuangtai` 的页面值包含 预订 / 已确认 / 已取消
名单入口: `DaoRuLie('全部','')`；清空入口 `CleanerLies()`
回查候选: SP_OrderList + plan_List.asp?tid=<tid> + 子单详情

原生请求被只读拦截，payload 11674 字节，SHA-256 为 7cd2a73ac798095925f80b3559b29b9d45cc51fa1a2a2a356601d8e84d68cb12。重复字段说明不能仅靠“唯一 key 数量”判断游客行数，适配器必须保留顺序、行作用域和 kid/ykxh 等行标识。

9.4 取消、删除与恢复的边界

独立团批量取消/恢复

独立团列表的页面函数 set_quxiao(cz) 在选择团队后先弹二次确认，再调用：

POST /System/DAT/orders.asp
data: Act=JH_set_quxiao&cz=<1 或 0>&tid=<选中的团队内部 id>
response: script

本轮临时选择一条现有列表记录、把确认回调替换为自动继续、再拦截 AJAX；分别捕获 cz=1（取消）和 cz=0（恢复），随后恢复了原 checkbox 状态和原函数，两个请求均未出网络。零选择时页面仍先提示“请选择要操作的团队！”。因此可确认 action 形状和选择/确认前置，但不能把它登记为已验证的业务取消能力。

删除不是取消

独立团单条删除使用：

POST /System/DAT/orders.asp
data: Act=DelRecord&dID=<订单内部 id>&tID=<团队内部 id>&txh=<团号>

页面确认文案明确提示该操作不能恢复。散拼计划详情/子单删除使用：

POST /System/DAT/plan.asp
data: Act=Del_order&tID=<团队内部 id>&did=<订单内部 id>

两条删除动作都已在确认回调和 AJAX 层做只读拦截，未触发网络。它们与独立团 JH_set_quxiao、编辑页 danzhuangtai=已取消 是不同对象；Skill 必须将 order_cancel、order_delete、order_restore 分开，至少在当前证据阶段全部阻断真实写入。

10. 关联证据

• 业务原始说明：/Users/inmanx/Desktop/运营梳理.rtfd
• ERP 静态 inventory：archive/research/2026-07-07/api_inventory.md
• 现有适配登记：agent设计规范/business-adaptation-registry.md
• 现有行为路由：agent设计规范/business-behavior-registry.md
• 当前插件说明：chrome-extension/ltjt-order-assistant/README.md
• 当前过程记录：findings.md、progress.md、task_plan.md

11. 2026 年 9 月真实测试执行协议（已授权）

11.1 测试对象与标识

• 仅建立两组测试对象：1 组独立团订单，以及 1 组散拼母团/子单。
• 所有可写入的测试名称、备注和可筛选字段统一带 TEST-202609；执行时同时记录 tid、ddid、tdid、团号、订单号、创建时间和当前账号归属。
• 出团日期/周期在 2026 年 9 月内由执行时统一选择，批量下单使用同一测试时间段，避免把日期差异误判为业务差异。
• 游客、联系人、电话、证件等全部使用合成数据；不会粘贴真实客户资料。

11.2 生命周期执行顺序

1. 下单：完成独立团和散拼母团/子单创建，并记录服务端响应与列表/详情回查。
2. 名单：先生成所需游客行，再执行导入/补充，保存后回查人数、行数和关键字段覆盖结果。
3. 安排：按导游 → 车辆 → 酒店 → 大交通 → 其他/备案顺序逐项保存；使用 ERP 现有可选资源，但统一保持未确认/测试状态。
4. 修改：先做低风险字段修改，再验证页面回查；不触发真实采购、付款、通知或对外发送。
5. 取消分支：保留一条可继续导出的测试对象，另一条执行取消 → 回查 → 恢复，分别记录状态变化。
6. 导出：在删除前读取确认单、预订单、名单、备案和接送牌等源，并记录响应、文件类型、内容摘要及失败情况。
7. 删除：只处理本次测试创建并进入删除允许清单的对象。

11.3 删除闸门

删除前必须逐对象同时满足：

• ID 位于本次运行实际创建的允许清单；
• 对象带有 TEST-202609 标记；
• 页面/接口显示其归属于 AI 测试账号；
• 所有需要的导出和回查证据已留存。

删除后再次通过列表/详情回查确认对象不再出现。任何编号、归属、标记或回查结果不一致时停止，不扩大删除范围，转由用户人工复核。

11.4 单项验收记录

每个真实写入模块统一记录：operation、resolved_refs、before_snapshot、preflight、native_request、server_response、requery、side_effects、manual_review_required。没有服务端响应或写后回查的模块只能记为“未验证”，不能记为成功。

12. 2026-08-11 真实生命周期结论（覆盖前述只读阶段状态）

前文第 4、8、9 节保留的是调研当时的证据等级；以下结论来自已授权的真实测试写入和写后回查，优先级更高。

12.1 已完成

• C08 独立团（2026-09-20）与 C09 散拼母团/子单（2026-09-22）都完成：名单 → 五类安排 → 窄修改 → 取消/编辑恢复 → 两阶段 10 类源读取 → 安排清理 → 证据冻结 → 精确删除。
• 名单固定使用 NAME、证件号码、签发日 表头；独立团和散拼子单均保存 16 行并重开回查一致。原生电话解析会把接团/送机电话混入通用集合，正式适配必须按 tr[id^=youke] 行级修正并恢复 jj_dianhua/sj_dianhua。
• 五类安排 DoInfo_daoyou/cheliang/jiudian/piao/qita 均取得明确 HTTP 200 成功响应，并通过子页与团队总表回查。其他成本与备案共用载荷但可分离清理和保留。
• 散拼母团 jihuarenshu（计划容量）和子单 zhusushuoming（住宿说明）已取得 before/after 持久化证据。
• 列表取消 cz=1 通过；三类编辑页状态修改通过。母团取消会传播子单，母团恢复不会恢复子单；子单取消不取消母团但会改变母团收客统计。
• 10 类源在安排态和清理/恢复态均 source-only 读取并冻结字节与 SHA-256；部分源随状态/资源变化，不能假设同一对象的源文件恒定。
• 独立团删除为 DelRecord(dID,tID,txh)；散拼子单为 Del_order(tID,did)；散拼母团为 DelRecord(tID,txh)。C09 按子单后母团删除，全部对象删除后精确查询为 0。

12.2 已确认缺陷与正式阻断

• JH_set_quxiao(cz=0) 在独立团和散拼母团均返回 HTTP 200 但状态仍为已取消，列表恢复正式禁用，不再重试。
• 独立团存在安排历史时，普通字段可返回 HTTP 200 空响应且不持久化；zhusuanpai 非空或未明确排除安排历史时阻断通用修改。
• 散拼子单 xiadanbeizhu 不持久化，只开放实测通过的 zhusushuoming。
• 散拼批量创建仍有 HTTP 500；产品/客户来源关键字一致是潜在必要条件，但不是充分条件。
• C01 LW-260903A-A 有测试账号无权清理的财务账，永久排除自动删除，等待具备权限的人工处理。

12.3 落地版本

operation、Schema、mapping、Skill 和 fixture 已统一为 ltjt-lifecycle-v2-live-validated-2026-09。新生命周期 action 继续保持测试态，发布门槛和剩余风险分别见 agent设计规范/test-fixtures/lwlt-lifecycle/release-gate.md 与 risk-register.md。

13. 2026-08-12 第二轮稳定性复现与最终适配结论

第二轮 sept-2026-lifecycle-plugin-e2e2-01 使用全新的业务日期、suffix、ERP 引用、应收 row ID 和安排 row ID，再次完成四条创建路线、两类 16 行名单、独立团/散拼母团各五类安排 create/clear、散拼母团与子单窄修改、应收、7 个状态转换、两阶段 source-only 导出和删除。9 个对象均已按“具体子单 → 无子单母团 → 独立团”顺序删除；最终只读探针证明全部引用不存在且插件无运行中任务。

第二轮纠正了两个旧结论：散拼批量在产品/客户来源兼容、候选唯一和页面联动完整时已再次 3/3 成功，不能继续登记为未解决 HTTP 500；独立团 booking_note 即使在全新、无本轮安排历史对象上也不持久化，页面原生请求对照相同，因此不能再描述为“只在有安排历史时失败”。

当前正式正向修改白名单只有散拼母团 planned_capacity → jihuarenshu 和散拼子单 lodging_note → zhusushuoming。独立团 order_update_independent 只保留系统内部 clear_generated_zero 清理，不接受普通字段；日期、客户、产品、人数、房型、行程、OP/销售、航班和接送机仍需逐字段原生基线和写后回查。

0.5.76 把母团取消后的逐子单 fresh 详情回查纳入成功门槛；0.5.77 进一步在 parser、planner、Schema 与浏览器 adapter 四层关闭独立团普通修改。operation、Schema、mapping、Skill 和 fixture 当前统一为 ltjt-lifecycle-v2.3-second-run-validated-2026-09。稳定性证据门槛已满足，但统一正式发布仍等待业务负责人确认模块化发布边界。