LWLT-AIBOT/archive/project-history/2026-08-26/findings-pre-compression-global-parser-automation.md

当前关键发现

2026-08-26 — 解析策略与全自动化全局生效（调查中）

• 用户观察到手工输入会遵循解析策略，而 AgentBus 仍走 AI；当前必须分别核对“解析器选择”和“解析通过后的自动确认/执行”两层，避免只修其中一层。
• 已知运行态曾将 18/18 route 切到 program，组织全自动化仍关闭；历史分析又记录 143 条 AgentBus 全部走 AI。这组事实与用户反馈一致，但尚不能替代当前源码根因证据。
• 预期正确边界是：来源适配只处理输入与回执，route 级 AI / Shadow / Auto / Program 策略、统一 operation 校验和组织全自动化决策都在来源汇合后的单一编排层生效。
• ParserOrchestrator.parse() 本身不检查任务来源，只读取任务快照中的 route_id、configured_mode 和 engine_affinity；只要 AgentBus 任务拿到正确快照，它会和手工任务一样执行四模式。
• 两个任务插入点都可见 resolveParserModeSnapshot(...) 调用，初步说明“AgentBus 固定 AI”更可能发生在 AgentBus 文本/会话复用、快照解析结果或另一条旁路，仍需读完对应事务代码后确认。
• 全自动化已有明确来源特判：shouldAutomaticallyConfirm() 同时要求 source === 'agentbus' 和组织开关。该实现与“全局生效”直接冲突，会让手工任务永远保留人工确认；这是一项已证实的修复点。
• resolveParserModeSnapshot() 仅对原始文本的“首个非空行”做 route 匹配；任何无法在首行识别的输入都会固化为 route_id=null / mode=ai / engine_affinity=ai。因此来源适配若给 AgentBus 文本增加前缀，或消息第一行不是指令名，就会表现为 AgentBus 始终走 AI。
• createTask() 与 ingestMessage() 创建新任务时确实调用同一个快照函数并写相同五个 parser 字段；已排除“AgentBus INSERT 直接硬编码 AI”这一假设。补充消息沿用原任务快照，符合任务级一致性原则。
• AgentBus frame 解析目前把 payload.text trim 后原样送入任务网关，没有在已读段落中发现显式 AI 选择；下一步定位实际 inbound handler、server 组织上下文和现有 AgentBus route 测试，确认首行/组织/旁路中的哪一项造成运行表现。
• AgentBus inbound handler 已确认使用 source='agentbus'、配置组织 ID 和原样 payload.text 调用同一个 TaskService.ingestMessage()，随后调度同一个 parse queue；不存在独立“直接调用外部 AI”的执行分支。
• 手工 API 与 AgentBus manager 最终使用同一 ParserOrchestrator。AgentBus 的组织来自配置组织，手工任务来自登录会话；在单组织部署中应相同，但测试必须固定“同组织同 route 设置”才能防止来源漂移。
• 迁移 013 把所有旧任务一次性标为 AI affinity，仅保护历史任务；新任务由创建时快照决定。故“全局生效”不应回写历史任务，也不能用迁移中的历史 AI 回填解释新 AgentBus 任务。
• 当前最小且安全的设计方向是把 route 识别做成独立、来源无关、可审计的业务输入解析步骤，并对两种来源写同一快照；不能在 AgentBus handler 里硬改 mode，也不能在编排器里忽略 unresolved/affinity 门禁。
• 现有控制面测试把“组织全自动化”明确定义成仅 AgentBus：断言 source='manual' 时为 false；这不仅缺少全局覆盖，而且把当前错误行为固化成契约，必须重命名并改为两种来源都自动确认、缺字段/阻断/开关关闭仍停住。
• 现有 AgentBus listener 测试只断言 source='agentbus' 和消息转发，示例文本是自由表达“创建一个新团”，没有把 18 项模板、route 快照和 Program authority 串到一起。因此当前测试无法发现用户报告的策略来源分叉。
• 需要新增至少两层回归：纯函数层固定 automation 与 source 无关；带 PostgreSQL 的任务创建/AgentBus ingestion 层固定同一模板、同一组织、同一 route 设置时写入完全相同的 parser 快照，并由编排器选择同一权威引擎。
• 当前控制面测试没有数据库集成夹具；parser setting 只做迁移文本/纯编排单测。为避免引入外部数据库依赖，可以把“从 route resolution + setting row 生成不可变快照”提取为纯函数，并用同一原始业务文本分别模拟 manual/AgentBus 创建入口，再保留现有事务插入静态契约断言。
• 归档中的“143/143 AgentBus 全部 AI”来自 18 route/迁移 013 上线前的历史路径对比（manual canonical JSON 对 AgentBus 外部 AI），只能证明来源分叉的产品背景，不能单独证明当前 Program 快照代码仍失效；当前修复必须由新回归而非历史统计驱动。
• 历史输入形态补充了根因机制：143/143 AgentBus 文本在任意行都没有当前 18 项指令，141 条首行是普通包装文本，但 141 条后续字段结构≥80%。当前首行 route resolver 对这类输入必然返回 unresolved 并固化 AI；这不是 AgentBus handler 硬编码，而是 route 决策只支持手工模板首行造成的事实性来源偏差。
• 程序 parser 即使由外部提供 route，也会把无法归类的包装行作为 unsupported syntax 并失败关闭；因此修复必须区分两件事：可靠识别 route 让策略生效，以及是否声明旧包装内容可被 Program 成功解析。前者可以全局修复，后者必须有明确别名/标签契约与 gold 样例，不能靠猜测放宽。
• 当前 Auto 对 program_unsupported_syntax / program_unknown_field 允许 AI fallback，而 Program 会直接阻断；只要任务能拿到 route 快照，四模式语义已经正确。因此重点应是建立来源无关且保守的 route 识别，不是改变 fallback allowlist。
• 活动运营输入契约明确要求“首行只写业务指令”；因此不能为了兼容未知 AgentBus 包装而静默丢弃任意前置自然语言。安全兼容最多只能让全消息中的唯一指令参与 route/mode 快照，Program parser 仍应对无法归类的包装内容失败关闭，除非未来登记明确的渠道 envelope 契约。
• 活动 UI/文档仍把全自动化描述为“AgentBus 新任务”，与用户要求的全局语义及当前组织级设置名称不一致；除后端函数和测试外，index.html、app.js、控制面 README 的提示文案也必须同步。
• 当前 Codex 任务未附加运行 8786 的 app terminal，无法用 stdout 补看最近 AgentBus 文本预览；按安全边界不读取进程环境或 .env，也不因此阻塞可由源码证明的全局化修复。
• 根因与实现边界已收敛：任务插入和编排器本来共用，但 route resolver 只看首行，导致结构化渠道文本在快照前落成 AI；automation 又显式排除 manual。修复将把 route resolver 提升为全消息唯一指令 + 保守完整字段签名，仍由同一快照函数服务两种来源，并让组织开关在所有来源的合法解析结果上生效。
• 字段签名 fallback 的安全条件：至少两个不同标签；所有标签都能在候选 route 内唯一解析；满足该 route 的定位/业务必填项（单号可替代客户+日期的既有规则保持）；最终只能剩一个候选。名单两种对象、无恢复状态的取消/恢复等天然歧义继续不路由。
• 测试先行结果：新增回归最初准确暴露嵌入指令、字段签名和 manual automation 三个缺口；实现后 68/68 定向测试通过，既有 program_multiple_actions 语义也已保持。
• 全消息扫描首次实现会对 500 行名单的每一行尝试 18 route 编辑距离，虽仍通过 250ms P95 门槛，但测试墙钟从约 12ms 增至约 848ms。应在提交前用指令长度窗口跳过不可能的长行，并对签名标签数设上限，避免为全局策略引入可见解析开销。
• 指令候选现按登记指令最短/最长长度 ±1 过滤，字段签名最多检查 64 个标签；同一 500 行名单性能测试墙钟已从约 848ms 降到 22ms，21/21 parser 回归通过，保留全消息兼容而不牺牲解析预算。
• 该行为属于确定性 parser 能力变更，程序版本已递增为 ltjt-program-parser-v1.0.3；gold corpus 版本断言同步。operation Schema、ERP mapping、Chrome 扩展和输入字段契约均未改变。
• 曾短暂修改运营模板的解析说明，复核治理规则后已撤回该改动；模板 SHA-256 恢复为发布清单登记的 45b389...04443，因此无需重建 DOCX，也没有形成未同步的输入文档版本。
• 操作台全自动化提示、生命周期测试说明、根/控制面 README、设计入口和业务登记已同步为“所有来源”；页面 app cache key 已更新，未改变 CSS 或扩展版本。
• 三套定向回归（parser、control-plane、AgentBus）和页面语法共 79/79 通过；静态契约同时固定 resolveParserModeSnapshot 在 manual/AgentBus 两个新任务入口各调用一次，且 automation 不再含 source==='agentbus'。
• 字段签名只决定已经创建的新任务使用哪个 route/mode，不改变等待补充会话的归属；detectBusinessDirective() 只把明确指令视为新动作，避免完整字段补充被误拆成新任务。
• 当前脱敏 gold corpus 只有 18 个官方首行、1 个登记别名和错误/歧义反例，没有历史 AgentBus 旧包装/旧标签样例。v1.0.3 可以让当前登记字段块无指令时保守路由，也能让嵌入唯一指令的包装任务拿到策略快照；未登记旧标签仍不会被猜测为 Program 成功。

2026-08-26 — 成功单 105 秒后台页节流与伪错误

• 新成功任务 TASK-20260826091949-jHQfo6s 的插件总耗时为 105,620ms，但 ERP 正式保存请求仅 746ms、fresh requery 仅 547ms；瓶颈不是 ERP 服务端。
• 预检 94,811ms 中，四项只读 lookup 并行墙钟约 835ms，产品联动约 5,046ms、客户恢复约 54,992ms、提交拦截约 33,784ms。原 25/50ms 页面轮询在后台标签页被 Chrome timer throttling 放大到约 1 秒甚至 30—60 秒。
• wait_order_form 另有 9,099ms，其中两次 ping_order_frame 向 15 个 Frame 广播耗时 8,451ms，页面函数本身仅约 3ms；全 Frame 注入是独立编排瓶颈。
• 0.5.147 直接等待 GetProduct 和正式 DoInfoJH 的原生 Ajax complete 回调；产品 success 已在 complete 前完成 DOM 回填。客户恢复不触发异步原生查询，写入五个已唯一解析字段后立即精确核对，提交前仍有最终五字段守卫。
• 预检 guard 同步捕获并哈希一个 DoInfoJH，返回后持续阻断网络；正式阶段要求该 guard 仍只保留一次提交，临时放行一个 payload/protected-fields hash 匹配请求，第二个请求在网络前阻断，完成后 guard 保留至返回列表或安全恢复计时。
• Frame readiness 通过 chrome.webNavigation.getAllFrames() 先筛选准确 /orders_add.asp 或 /orders_adds.asp frameId，只向候选 Frame 执行轻量 probe；不再对 15 个 Frame 广播。
• 完成后出现的“获取回执失败”是展示层伪错误：failureSummary() 曾把成功解析阶段的 no_plugin_dispatch/no_erp_write 边界事实当成显式失败，页面又无视当前 completed 状态合成 task_error_summary。两层均已修复，历史错误摘要仍可保留但只在当前失败状态展示。
• 当前扩展制品为 0.5.147，ZIP SHA-256 0e3a3e1324e05ea2765e3d28afe66d3955191f1f44808a018164500dbd37e8e9；仓库 9/9、控制面 94/94、legacy 238/238、TypeScript check/build、61 条定向生命周期/计时回归和 diff 检查全部通过。
• 用户随后明确授权重启 8786：新 PID 41546 单一监听，/health/live、数据库、迁移 013、4 个 AgentBus 渠道和 0.5.147 页面最低版本均已核验；没有重试/创建/确认任务或触发 ERP。Chrome 扩展仍未重载，插件提速须加载 0.5.147 后由新任务验证。

2026-08-26 — 插件 8.1 秒编排耗时优化

• 原成功样本 TASK-20260826080934-C5ZbEOM 的程序解析约 1 秒、插件总计 18,818ms；保存 action 1,143ms、fresh requery action 456ms，主要慢点是预检、Frame 注入和未细分编排，不是 ERP 保存接口本身。
• waitForOrderFrame / 批量 readiness 已改用无依赖轻量内联 probe；单个下单正式动作只注入 source-region.js + inpage.js，inspectOperationContext 只注入 inpage.js，不再为 ping 向全部 Frame 注入约 565KB 通用包。
• ERP 页签在同一 task 内缓存并复核 allowlisted origin；页面保活找到页签后，业务执行复用同一 tab，结束时清除。权限、查询、等待、cache hit 和总查找耗时均有独立代码。
• 单个下单的 product/route/customer/staff 四个只读 endpoint 以 Promise.all 并行；产品联动和客户恢复要求 Ajax 空闲、字段变化且连续稳定，替代固定 800ms/300ms。
• 提交预检取消固定 1000ms，活动静默 150ms 即返回；DoInfoJH guard 最长保留 30 秒，只有 live 阶段先通过字段数及 protected-fields hash 后才恢复原生 Ajax。延迟提交仍被阻断，超时/不稳定继续失败关闭。
• chrome.storage.local 现记录 mutation queue、读写和 map 数量；领取新任务时只保留最近 12 个普通终态 root，并无条件保留当前、running/write_started/submitted/uncertain、待回查和仍有 timing state 的 root。该清理降低整图序列化成本，不会删除安全恢复证据。
• 新明细覆盖 storage、tab、executor keepalive、四个 lookup、产品联动、客户恢复和提交拦截；控制面使用逐项白名单及数字 counter 白名单，未知 step/counter 仍丢弃。
• businessTaskResults 变化会由桥接即时推送；平台串行持久化当前结果，并把积压中间态覆盖成最新一条，避免 2.5 秒轮询延迟或形成 9 条 API 队列；轮询仍兜底。
• 静态/单元验证不能证明真实 ERP 提速。加载 0.5.146 后的新样本应重点看 storage_*、tab_lookup.*、preflight_lookup.*、preflight_product_linkage、preflight_customer_restore 与 preflight_submit_intercept，再决定是否需要迁移为 per-task storage key。

2026-08-26 — 18 项业务进入 Program

• 管理员运行态已核验 18/18 项均为 program、revision 3，且没有遗留 Shadow/Auto；组织全自动化仍关闭，因此新任务由程序权威解析，但解析通过后仍按当前人工确认流程进入插件。
• 原阻断来自 6 条未判定 Shadow 差异，而非时间或任务量：两条仅差可选 recurrence.pattern=specified_dates，已判等价；四条是旧 AI 年份追问或输出契约错误，而程序候选通过统一契约，已判程序正确。
• 用户已于 2026-08-26 明确授权重启；8786 新监听 PID 24896 已加载当前源码，因此程序解析器 ltjt-program-parser-v1.0.2、取消/恢复下一次发生日修复及新版计时白名单已进入运行态。仍须用新任务日志验证实际业务结果。

2026-08-26 — 恢复订单无年份日期再次追问

• 新日志任务 TASK-20260826050952-ST-M2MY 于 13:09:53 进入 AI 解析，外部 Agent 将业务识别为 order_restore，捕获客户、产品和目标状态，但因输入仅含 11-05 返回 agent_parse_needs_input；插件未派发、ERP 未写入。
• 直接原因是活动 Prompt v1.6 与任务级 guidance 明确把取消/恢复排除在下一次发生日规则之外，lwlt-lifecycle 模板又只写 YYYY-MM-DD；宿主的旧规则修复只识别四类修改指令，所以这次 contract_repair_count=0。
• 用同一脱敏业务输入直接运行确定性解析器，已得到 order_restore、2026-11-05、external_call_made=false。因此这是 AI/程序日期策略不一致，不是输入日期无效、契约错误或 ERP 故障。
• 本轮按同一问题扩展同一规则：order_cancel / order_restore 的定位 MM-DD 按任务日期取下一次发生日，明确年份保持不变；宿主必须归一化旧 AI 候选，并把仅追问年份的旧 Profile 响应转为同会话契约修复。

2026-08-26 — 12:45 订单恢复日志复核

• session catch-up 无未同步上下文；工作区保留大量前序未提交源码、发布物、规划与归档改动，本轮不得覆盖或批量回退。
• 业务登记表把 order_cancel / order_restore 唯一定位到 lwlt-lifecycle，运营输入为统一模板 §16—17，ERP 路径为列表取消或编辑页状态且列表恢复禁用；三类对象和母子传播已有历史真实验证，但当前任务仍须以本次 execution 的逐事件证据判断。
• 活动静态基线仍是扩展 0.5.144；浏览器运行态是否加载该版本必须从新日志或受授权实时握手确认，不能由工作区文件反推。
• lwlt-lifecycle 当前解析边界未改变：取消输入只保留用户可见的单号或客户、单个出发日期及可选产品/领队；解析器不查询 ERP、不猜对象 kind 或当前状态，ERP 富化与状态转换属于后续执行链。因此日志中的解析成功不能单独证明路由或写入成功。
• 统一运营模板明确由系统自行读取对象类型、当前状态、应收与安排前置条件。解析态 Agent Schema 接受“精确 identifier”或“客户 + 单个出发日期”两种取消定位；执行态标准 Schema 则要求 transition，恢复还强制 edit mode。这为日志中 parse operation 与 ERP-enriched execution operation 的差异提供契约依据。
• 0.5.144 的可观察签名已经明确：route preparation 的公开 preflight 应有 route_token_bound: true；随后 allFrames probe 只公开 route_token_matched 布尔值。token 存在但目标 Document 消失会报 lifecycle_exact_route_document_missing:<path>；仍出现 lifecycle_exact_frame_ambiguous:N 只有在同一 token 同时落到多个合格 Document（按当前 binder 理论上不应发生）或旧运行逻辑未启用时才成立。token 原值绝不能出现在日志。
• 对列表取消，后台也会生成 token，因为 order_cancel 属于 route-token action 集；页面先精确解析唯一列表行和当前状态，再把 token 只绑定该 list Document。正式 preflight 仍以 token + path + frame eligibility 为第一层，再进行唯一行、from_status 与 ownership 校验。
• 新附件为 404 行、12,577 字节，SHA-256 7cfed794a961de741b0d6163602530b073a767479eebe13f1dd817020f99c32f；未复制进项目。
• 虽按上一轮上下文暂称“取消订单日志”，本次实际解析 action 是 order_restore：客户“衡阳国旅广东”、出发日 2026-11-05、产品“老挝好时光”、目标状态“预订”。12:47:09 已 agent_parse_passed 并进入人工确认，解析阶段 no_erp_write=true、no_plugin_dispatch=true。后续执行结果尚未读完，当前不能判断成功或失败。
• awaiting_confirmation 聚合对象仍携带旧的 lifecycle_exact_edit_form_not_ready failure，后续 running 快照也携带默认/历史 task_failed 字段；这些不能覆盖独立事件链。本次执行以 execution id 2a2a77b6-87c1-4b68-b7ac-9f9cc4943966 为准：12:47:12 人工确认，12:47:13 排队，12:47:15 取得执行权，12:47:17 ERP 唯一解析，12:47:22 进入 route preparation，至此仍 erp_write_started=false。
• 当前 execution 在 12:48:07 最终以 lifecycle_exact_edit_form_not_ready 于 lifecycle_route_preparation 阻断；从 route preparation 到阻断约 45 秒。uncertain=false、erp_write_started=false、no_erp_write=true、无 success receipt，因此订单没有被本次执行恢复，也无需写后 reconciliation。
• 失败发生在 waitForExactLifecycleEdit() 返回目标 Document 之前，route token 只会在找到该 Document 后绑定。因此本日志没有 route_token_bound 证据，既未验证 0.5.144 token 修复，也不是 11:46 的 lifecycle_exact_frame_ambiguous:2 复现。
• 活动源码当前对恢复强制 edit：独立团期待 /orders_add.asp + ddid，散拼母团期待 /plan_update.asp + tid，散拼子单期待 /plan_order.asp + stable parent tid/regular tid + ddid；新 Document 必须 complete、有 ListForm 且引用全部匹配，等待 30 秒后失败关闭。下一步需区分“根本未打开/未完成/无表单/tid 不匹配/ddid 不匹配”，不能凭单一 blocker 猜修复。
• 本次已经通过 prepareExactLifecycleList()：否则会是列表引用/导航/唯一行 blocker，而不会到 edit-form blocker。恢复列表检索对独立团/母团强制“已取消”，对子单用活动母团“收客中”；因此已知“唯一 ERP 候选和唯一父/目标列表行成立”，未知只剩点击后的编辑 Document readiness 维度。
• 现有 lifecycle 回归固定了恢复必须 edit、三类期望路由和 readiness helper，但 lifecycle_exact_edit_form_not_ready 主要还是静态/辅助行为断言，尚未发现一个从真实样式列表入口点击到新 edit Document 的三类恢复模拟。因此当前测试通过不能排除 ERP 入口参数或弹窗生命周期的集成缺口。
• 与用户此前 11:06、11:46 附件交叉核对后，三次都指向同一客户“衡阳国旅广东”、日期 2026-11-05、产品“老挝好时光”：11:06 取消在 edit form not ready 阻断；11:46 取消已通过 route preparation、后在 exact frame ambiguous 阻断；12:45 改为恢复又在 edit form not ready 阻断。三次均无 ERP 写入。这证明 route 准备具有可重复的 edit 路径缺口，同时至少一次能打开到正式 preflight；不能简单归因于永远错误的业务引用。
• 活动稳定夹具目录没有真实 ERP HTML 页面快照，现有代码只通过正则/静态断言记录 OPEN_update / OPEN_updates 入口形式。要形成代码修复，需从现存真实证据或只读运行诊断确定新页面究竟是未出现、重用了旧 Document、路径/表单未完成，还是引用口径不匹配。
• 不可变历史证据中存在 E2E2/E2E3/E2E4 的 independent、shared-plan、shared-child 恢复操作与 replay manifest，可用于验证曾经成功的引用和弹窗契约；它们只供追溯，任何结论仍须与活动源码/契约一致，不能反向覆盖当前规则。
• E2E4 不可变证据确认旧扩展 0.5.81 曾完成独立团恢复、子单恢复、母团恢复、父后子单恢复四条真实链，并在序列后确认无遗留精确编辑弹窗；子单父引用来自 oldtdid。因此 ERP 本身具备三类 edit 恢复能力，当前失败更像后续 route preparation/弹窗管理回归或运行态页面差异，而不是“恢复功能从未可用”。
• 历史成功记录只有 operation、task/execution id、payload hash 和业务回查摘要，没有本次目标的 Document readiness 维度；仍不能从历史结果确定当前 blocker 的精确子原因。
• 0.5.84 成功基线与当前活动源码对照表明：精确列表行 → 原生 OPEN_update/OPEN_updates 入口 → 排除旧 Document → 最长 30 秒等待新 edit Document 的总体机制没有改变；当前主要差异是更严格的表单引用优先判定、生产/测试边界、状态派生及 route token。因此不能把失败归因于一次明显的函数删除或路由改写。
• 旧成功实现仅按 edit URL query 的 tid/ddid 判定身份；当前实现若表单中存在任何同名引用字段，就完全优先表单值并忽略 query。若 ERP 页面含有同名但语义不同或加载中暂态值，这一收紧可能把实际精确页面持续判为不匹配；但当前日志未暴露 readiness counts，尚需证据确认，不能直接放宽为 query 优先。
• 当前平台生命周期日志的失败公共契约只保留 blocker/validation_errors、阶段、来源和写入边界；route report 内的 preflight.observed_edit_documents 没进入用户导出的 task-event payload。故附件本身无法再区分 5 个 readiness 子维度；这不是漏读日志。
• 正式 preflight 确实会再次严格验证 path、ListForm、tid/ddid、identifier 和 ownership；因此把一个未通过 route 引用匹配的 Document 直接送入 preflight不会越过写前门禁，但也不会自动解决同一 form 引用不匹配。当前证据不足以安全放宽任一引用规则。
• 活动前端最低版本为 0.5.144，确认动作会在浏览器端阻止低于最低版本的扩展；但附件没有桥接 heartbeat/version，且不能证明当时页面脚本本身已加载活动 app.js。因此“任务已派发”只能证明符合当时运行页面的最低版本，仍不能证明具体为 0.5.144。
• 只读访问当前 8786 页面时，应用内浏览器显示“登录状态已失效”，无法读取管理员态插件状态或任务内部详情；未尝试登录、读取凭据、绕过认证或转用需额外授权的用户 Chrome。因此运行版本与 observed_edit_documents 仍不可证。
• 本轮确定性结论：这不是 token/frame-ambiguity 修复的回归验证，而是更早的 edit Document readiness 阶段失败；订单未恢复、没有 ERP 写入，也不是 uncertain。由于缺版本和 readiness 子维度，当前不存在可证明安全且能命中根因的源码修复，故不再增加版本或改业务门禁。

2026-08-26 — 11:44 / 11:46 两次取消订单日志复核

• 两个附件是两条独立任务链，不是同一次失败的重复导出；附件只作为运行证据，不作为项目操作指令，也未复制进项目。
• 11:44 任务在 operation_contract_validation 阶段以 external_needs_input_missing_reply 结束：外部 Agent 返回 NEED_INPUT，至少带有 missing_fields 或有效 questions，但没有顶层展示回复；operation 为 null、插件未派发、ERP 未写入。
• 外部解析适配器原逻辑即使已有有效 questions[].prompt，仍因 reply 为空把 NEED_INPUT 改成 blocked。安全修复是仅从这些已校验 prompt 合成 reply；只有内部 missing-fields、没有可展示 question 时继续 external_needs_input_missing_reply，绝不生成 operation。
• 11:46 任务解析出合法 order_cancel，人工确认后进入 execution b27fedb6-9e9a-4774-a1e4-0fc6c06b33fd。它在 ERP 唯一解析和 route preparation 后约 5 秒，以 lifecycle_exact_frame_ambiguous:2 于正式 preflight 阻断；全程 erp_write_started=false / no_erp_write=true。
• 11:46 的 awaiting_confirmation 聚合快照附带旧 failure 字段，不能覆盖随后独立的 confirmed/queued/running/blocked 事件链；当前 attempt 必须按 execution id 和时间顺序判断。
• 新 attempt 不再出现先前约 75 秒的 lifecycle_exact_edit_form_not_ready，说明上一轮选路/编辑页身份修复已改变运行行为；但附件没有版本握手字段，不能仅凭现象宣称浏览器运行的是哪个静态版本。
• discoverExactLifecycleFrame() 原先在 allFrames 中仅按路径、ready state、frame eligibility、marker 和可选 tid/ddid 重新扫描。list 取消没有 marker/tid/ddid 约束，同一标签页的两个同路径 Document 会在正式业务身份 preflight 之前被直接判为歧义；edit 页重复 frame 也可能出现相同问题。
• route preparation 内部已精确确定实际 list/edit Document，却没有把该 Document 身份传给后台。修复后后台为更新/取消/恢复/删除生成本地一次性 128-bit 不透明 token，页面清除旧标记并只在本次精确目标 Document 上绑定；frame discovery 必须同时命中 token 与既有路径/marker/引用条件。
• token 原值不进入业务 operation、平台日志、探针报告或 ERP 请求；route evidence 只保留是否绑定/匹配。只读 uncertain reconciliation 每次也生成新 token，不依赖历史 DOM 状态。
• token 只缩小 Document 范围，不替代正式 preflight。后续仍要求完整执行态引用、唯一列表行或表单、from_status、ownership proof；多个 ready 仍以 lifecycle_preflight_ambiguous:N 失败关闭，live submit 只投递到唯一 preflight frame_id。
• 新增行为回归覆盖 route token 只绑定一个 Document、清理旧标记、拒绝非法 token，以及 NEED_INPUT prompt-derived reply 和无 prompt 继续阻断。定向外部解析 63/63、lifecycle 行为初测 51/51、三份相关源码语法均通过。

当前生命周期契约与实现边界

• lwlt-lifecycle Skill 只解析名单、取消、恢复的用户可见事实，不查询 ERP 当前状态或内部引用；取消/恢复允许不带单号和对象 kind，保留客户、单个出发日期及可选产品/领队，由插件唯一解析对象。
• 解析态 Schema 接受上述业务检索 operation；ERP 富化后的执行态才强制 existing_refs.kind/tid、resolved=true、resolution_source=erp_unique_match 和完整 transition。
• 取消按 resolved kind 选路：独立团/散拼母团走已验证 list，散拼子单走 edit；全部恢复走 edit。list 精确行必须只暴露一个允许当前状态，缺失、冲突或目标已是当前状态都在写前停止。
• 编辑页身份优先使用表单稳定引用：散拼子单 parent tid 优先 oldtdid，常规 tid 支持 tdID/tdid/tID/tid，ddid 支持 ddid/dID/did；表单无引用时才回退大小写兼容 query，表单/query 冲突时以表单为准并拒绝。
• 正式 list preflight 要求唯一 identifier 行、匹配 from_status，必要时从行内 input/link 证明 tid，并执行只读 ownership list proof；不能为解决 frame 歧义选择首个路径候选。
• 散拼母团取消完成必须 fresh 回查母团为已取消，并从 fresh SP_OrderList 发现全部具体子单、逐个读子单详情且全部为已取消；缺失、歧义、不可读或未取消均保持未完成，禁止自动重提写入。
• 恢复列表路径禁用；散拼母团恢复只恢复母团，不能把子单报告为已恢复。目标状态等于当前状态时保持 no-op、write_attempted=false。
• 写后完成必须同时有明确服务端成功响应和匹配的 fresh requery；HTTP 200、弹窗或旧页面状态都不能单独证明成功。跨过写入边界但结果不确定时只允许管理员触发只读 reconciliation。

近期仍影响发布的事实

• 当前源码/制品基线为 Chrome 扩展 0.5.146；ZIP SHA-256 为 66a165a5639dba0d58a38ba60da66f8ace5a16970bb18af54b6965ee0ba0505a。五个 Skill 为 0.5.121，Agent Prompt 为 ltjt-agent-prompt-v1.7-lifecycle-date-rollover，控制面程序解析器为 ltjt-program-parser-v1.0.2。
• 新建、三类修改、酒店安排变更以及取消/恢复的无年份月日均按各自目标字段取下一次发生日，明确年份不改；名单等要求完整年份的契约没有放宽。
• 散拼母团无子单时，只有“resolved kind=shared_plan + ERP 明确无子团/子单数据 + 提交入口缺失”三项同时成立，才返回先新增子单的业务提示；不能移除通用 SubmitButton 门禁。
• 独立团 SGL/TWN 与成人/占床儿童/领队人数映射已接入字段、非负校验和 fresh 回查，但仍待授权 ERP 实写复测；未验证宽修改继续转人工复核或失败关闭。
• 18 项确定性 parser 已实现并通过脱敏 gold/反例/性能验证；当前组织的 18 项运行模式已由管理员全部切到 Program，组织全自动化保持关闭。
• ERP 空闲保活与异常链接受控刷新只作用于既有 allowlisted 标签页、无执行任务和冷却条件；不新开标签、不自动重交业务任务。

安全、验证与归档边界

• 本轮没有重试或创建任务、确认/派发插件、读取 .env、执行 ERP 写入/点击、重载扩展、重启 8786、部署或外发；源码完成不等于运行态已经启用，也不等于失败任务已成功。
• 最终离线门禁通过：仓库治理 9/9、TypeScript check、控制面 90/90、legacy 230/230、build、lifecycle 51/51、相关源码语法、ZIP/源码逐文件核对和 diff 检查。
• 真实 ERP 新任务验证、扩展重载、服务重启、部署和外部 Profile 更新仍需用户另行明确授权。
• 本次压缩前的完整活动 findings 已原样冻结到 两次取消日志复核前完整快照；更早完整研究见 archive/project-history/2026-08-25/ 和 archive/project-history/2026-08-26/。归档只供追溯，不定义当前规则。