wangxuming/LWLT-AIBOT
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
4cfbefffe8b584c2e465cc862cf5ea6fcb5c9bc9
LWLT-AIBOT/archive/project-history/2026-08-25/findings-pre-compression-fixed-instruction-contract.md
T

31 KiB
Raw Blame History

当前关键发现

2026-08-25 — AI 解析环节可替代性评估（已完成）

  • 历史实证口径： 通过已有管理员会话只读聚合 2026-08-10 至 2026-08-24 的 444/444 条未删除任务；原文只在浏览器内用于结构分类，未写入文件或输出字段值。历史 operation 是“AI/程序实际生成并通过相应流程”的观测值，不自动等于语义 gold truth；完整过程见 实证压缩前快照。

  • 全量任务状态为 301 completed、96 blocked、17 failed、25 parse_failed、4 awaiting_confirmation、1 dry_run；来源为 143 AgentBus、301 manual。分析期间 confirmed 候选始终为 0，未调用 confirm/claim/result/cancel/delete 等 mutation 接口。

  • 路径实证： 444 条中 276 条走 canonical_json（62.2%）且全部来自 manual；168 条走外部 AI（37.8%），其中包含全部 143 条 AgentBus 任务和 25 条 manual。故“总体 62.2% 已绕过 AI”不能外推为用户渠道可替代率；历史 AgentBus 流量当前是 100% AI 路径。

  • AI 路径 168 条中 145 条解析通过、23 条解析阻断；86 completed、58 在解析通过后被下游 blocked/failed、1 awaiting_confirmation。13 条发生一次契约修复，10 条有外部请求错误；说明 AI 故障面真实存在，但大量最终失败仍在解析后的业务/ERP 层。

  • 当前 18 个模板首行在 AI 路径只精确命中 12/168；按“首行精确 + 全部行结构严格 + action 对齐”仅 3/168 可直接由现模板 parser 无争议接管，放宽到 80% 结构行也只有 5/168。另一方面，154/168 是“首行非当前指令但后续多行字段结构≥80%”，说明实际文本高度结构化、规则 parser 潜力很大，但必须先补齐真实首行路由/别名与字段映射，不能把 154 条直接算作已可替代。

  • canonical 路径 276 条有 274 条契约通过、215 completed；AI 路径通过 145 条、completed 86 条。下游完成率差异受 action 构成、ERP 门禁和样本来源强烈混杂，不能当作 AI 语义准确率对比。

  • 419 条有 operation 的任务中，operation data 标量值在输入中的规范化显式匹配率均值 83.5%、中位数 88.2%；canonical 路径均值 90.5%，AI 路径均值 70.1%。该指标只说明“值可从文本直接找到”的程度，不证明字段作用域/否定/修正被正确理解。

  • 历史 action 还包含 43 条 order_delete（全部 canonical，42 completed），而当前 18 个运营模板没有对应入口；历史 operation 同时反映旧契约/内部任务，评估本地 parser 时必须按版本和来源分层，不能把所有历史 action 当作当前自由文本需求。

  • AgentBus 分层更具决策价值：143 条中 127 解析通过、16 解析阻断，79 completed、43 downstream blocked、5 failed；12 条发生契约修复、5 条为外部请求错误。143 条均不精确命中当前首行指令，但 141 条是多行且后续字段结构≥80%，说明渠道输入很可能有稳定的包装/旧模板/别名结构，应继续用“标签签名 → action”回放验证，而不是把它们笼统归为自由自然语言。

  • AI 路径 168 条的解析阻断可拆为：10 外部请求错误、5 修复后仍阻断、9 无外部错误且未发生修复的业务/契约阻断；145 条通过中有 8 条依赖一次契约修复。程序化路径可消除外部请求/输出契约类故障，但不能自动消除业务缺失与下游 ERP 阻断。

  • 168/168 条 AI 路径均完成只含安全字段标签/指令位置的签名回放；中间连续 8 页没有 AI 路径，对应 8 月 11–12 日的 manual canonical 批次，进一步证明总体样本必须按渠道、时间和 prompt 版本分层。

  • AgentBus 输入形态： 143/143 都有可解析的 标签：值 行，141 条首行属于非模板普通文本、2 条为未知标签；当前 18 个业务指令在任意行均为 0 命中。模板稳定标签只覆盖实际标签的均值 64.5%，且 143 条全部含至少一个当前模板未登记标签，证明真实渠道使用的是另一套包装/别名/历史字段语言。

  • AgentBus 标签集合形成 30 种完整签名：23 种重复，21 种在样本内只对应一个 action；样本内 120/127 个有 operation 的任务落入唯一 action 签名，但另有 9 个解析阻断任务共享这些“纯”签名。此 94.5% 是同样本拟合上限，不是可上线准确率；标签签名只能路由 action，不能替代必填/值/作用域校验。

  • 按时间取较早 70% 训练、较晚 30% 验证时，AgentBus 39 个有 operation 的验证任务只有 10 个命中已知唯一签名：action 覆盖 25.6%，10/10 正确，4 个解析阻断均未被路由。它是当前证据下“简单保守规则路由”的可辩护下限，但尚不等于 25.6% 可自动执行，因为字段提取未证明等价。

  • 滚动使用全部历史持续学习时，AgentBus action 路由可覆盖 99/127，98 正确、1 错误（precision 98.99%），并会给 3 个解析阻断输入分配 action。该结果说明补齐别名能快速扩大覆盖，也说明仅凭历史标签签名达不到 ERP 自动执行所需的零 false-route 门槛。

  • AgentBus 已通过解析的 127 条，operation data 标量在原文中的显式匹配率均值 68.4%、中位数 70%；仅 4 条达到所有标量都可直接找到。此指标受日期归一化、枚举/default 和派生字段影响，不能当准确率，但足以证明“action 能路由”与“完整字段能由简单拷贝提取”是两回事。

  • 较晚 30% 的 AgentBus 验证集由 39 条有 operation（28 导出、6 散拼计划、2 独立团单、2 散拼子单、1 批量团单）和 4 条解析阻断组成。精确标签签名的零错误覆盖仍是 10/39；将已知标签集合改为 Jaccard≥0.8 的近似规则后，39/39 action 全部识别正确，但同时给 1/4 阻断输入分配了 action。结论是 action 路由大概率可程序化，然而必须串联字段解析和 fail-closed validator，不能把“识别 action”直接视为“可自动执行”。

  • AgentBus 迁移优先级应按“量 + 字段难度 + 下游收益”排序：confirmation_export 40 条/32 completed 且验证集 28/28 可由近似标签路由；team_order_create 9/9 completed、shared_plan_create 11/9 completed、shared_child_order_create 10/5 completed 也在较晚验证集被稳定路由。passenger_list_import 虽有 15 条但仅 4 completed，order_update_independent 8 条仅 2 completed且值显式度低，酒店/导游等也有较多下游阻断，不应把解析替换误当成整体成功率修复。

  • 被 Jaccard 规则额外路由的 1 个阻断样本会被判为 confirmation_export，外部流已正常完成、无请求错误、无契约修复，但仍有 1 个业务 blocker；因此它不是“AI 服务偶发失败，可由本地 parser 自然修复”，而是必须由字段/业务门禁继续阻断的实例。

  • Prompt 版本分层显示明显改进：有版本号的 122 条 AgentBus 任务全部解析通过；v1.4 为 49/49 通过且无修复，v1.5 为 27/27 通过、23 completed、4 downstream blocked/failed，亦无修复。16 个解析阻断全部落在缺少 prompt 版本的 21 条早期/异常记录中。历史数据因此不支持“当前 AI 解析经常失败”的判断；替换动机更应是延迟、成本、数据边界和可审计性，而非假定当前语义质量很差。

  • 源码确认公开解析摘要保留 external_request.timeline，但不直接保存单一 duration_ms；可用 timeline 首末时间计算外部解析耗时。canonical 路径也有本地 timeline，适合分别统计而不混入人工确认等待。

  • 当前 v1.5 Prompt 的 27/27 条 AgentBus 任务均取得完整 timeline：外部解析耗时最小 30.3s、中位 37.2s、均值 43.5s、P90 67.0s、最大 72.6s。该口径只覆盖外部解析首末 trace，不含 ERP 执行。即使当前语义解析稳定，本地确定性 fast path 仍有明确且可观的延迟收益。

  • v1.5 样本中 22/27 是 confirmation_export（19 completed），其解析耗时中位 36.6s、P90 67.0s；另有 4 个 shared_plan_create（中位 47.6s）和 1 个 shared_child_order_create。当前流量结构进一步支持优先为导出建立本地 parser/compiler。

  • 浏览器分析结束后已把用户原有 Chrome 标签恢复到 AI 操作台首页；恢复阶段观察到 5 个 API GET、0 个 POST/PATCH/DELETE 等 mutation 请求。全程 confirmed 候选为 0，未触发 ERP 执行。

  • 核心结论： AI 组件在技术接口上可替换，但在当前“允许自由自然语言、错别字、非标准位置和跨轮补充”的交互契约下，不能用普通业务规则程序无损完全替代。若输入收敛为现有运营模板或结构化表单，则可以完全移除 AI。

  • 当前 AI 只负责自然语言到解析态 operation 的意图识别、字段抽取、归一化和最小追问；ERP 查询、内部引用、唯一候选、写前门禁、原生写入、明确回执和 fresh requery 已全部由确定性程序承担。替换 AI 不会显著减少 ERP 适配复杂度。

  • 解析态协议只有 16 个唯一 action/18 个运营入口、固定 formal/dry_run 和 passed/needs_input/blocked 三态；validateAgentOperation() 已程序化实现字段白名单、必填、日期、人数/房型、名单 TSV、更新值、安排与导出条件。多数 Skill 条款已经是确定性校验，不由模型独占。

  • 运营总模板要求“首行指令 + 一行一个字段”，所有入口均有固定字段标签和值格式。对严格模板/表单输入，label parser、类型转换、别名表、有限状态追问和现有 validator 足以生成 operation；名单、安排、取消/恢复、导出和窄修改最适合作为首批无 AI 路径。

  • lwlt-newbooking 的日期/人数/房型语法可程序化但组合更多；lwlt-updating 的独立团多目标自由文本、字段修饰范围、增减量/目标总数、否定和未明示字段是主要长尾。自由表达、正文推断 action、错别字和跨轮纠正仍适合保留受约束 AI fallback。

  • 现有代码已支持合法 operation JSON 完全绕过外部 Agent，走本地 canonical_json 校验；控制面又通过可注入的 ExternalParser 接口消费结果。因此结构化 compiler、规则 parser 与 AI fallback 可以共用现有任务/ERP 链，替换耦合较低。

  • 外部文本路径带来会话、SSE、120/180 秒超时、重试、恢复和契约修复故障面；本地模板路径可降低延迟、依赖、数据出域和输出随机性。但近期项目记录中的多数故障仍位于插件、ERP 会话、页面权限、转换或写后回查，移除 AI 不会解决这些问题。

  • Schema 只能证明 JSON 结构合法，不能证明用户语义被正确理解；纯规则 parser 若过度宽松，同样可能“结构正确、语义错误”。任何本地 parser 必须 fail-closed，未知标签、冲突、否定/修正、重复字段和无法确定的作用域不得猜测。

  • 推荐方案： 采用“确定性优先、AI 兜底”，而不是立即二选一。严格表单/模板 → 本地 compiler → 同一解析态 Schema/validator；只有非标准自然语言、跨轮语义或独立团宽修改无法确定时才调用 AI；两路都保留管理员确认和现有 ERP 全部门禁。

  • 完全移除条件： 要么正式取消自由聊天兼容、只接受表单/严格模板；要么本地 parser 在脱敏 gold corpus 和 shadow 双跑中证明等价。建议自动通过路径在独立留出集实现 action 与所有显式字段精确一致、关键 false-pass 为 0、未知输入 100% 阻断，并经过足量生产影子样本后才逐 action 放量。

  • 历史 operation 是可执行伪标签而非独立语义 gold，且没有 token/费用或人工纠正基线；迁移仍需 shadow 对照。模板还存在旧规则漂移，parser 元数据应由机器可读业务注册表统一生成，避免新增一套分叉 if/else 事实源。

  • 本轮完整研究记录已冻结到 压缩前 findings；归档仅供追溯，不定义当前规则。

2026-08-24 — ERP 异常状态链接刷新加固（已完成）

  • 用户描述的是插件长时间待机后的偶发 ERP 未连接告警；当前源码已有 chrome.alarms 待机保活，但 runErpSessionKeepalive() 在 session_expired/failed 后只写入 erpKeepaliveState，没有恢复动作。
  • 当前保活默认首次约 1 分钟、之后每 5 分钟；只查找现有 https://lwlt.hisy.cc/* 标签页，执行主世界带 Cookie 的只读 GET /System/Mainlt.asp，执行中跳过，不新开标签、不刷新页面、不写 ERP。
  • findExistingErpTabForKeepalive() 会拒绝非完整加载或非 allowlisted origin；因此长待机后页面已被导航到登录/异常路径、页面注入链路失效或标签页状态异常时，保活只能报告 skipped/failed/session_expired，不能自愈。
  • readErpSessionStatus()、business-bridge.js 和 popup 已能展示最近保活状态；平台/业务 operation、Schema 与 Skill 不承载此宿主维护能力，当前活动约束来自 mappings/lifecycle.mapping.json。
  • 本轮拟保持 fail-closed：仅在无活动 ERP 执行、自动化与保活开关开启且已存在 allowlisted ERP 标签页时，执行受控同源 Mainlt 导航/刷新后再次只读探测；不自动打开新标签、不重交任务、不跨越 ERP 写入边界。
  • 已实现 performErpLinkRecovery() 与单飞请求锁：异常时对现有 ERP 标签页执行 chrome.tabs.reload(..., { bypassCache: true })，等待加载完成，再复用只读 probe；2 分钟冷却内最多一次，执行中二次检查并跳过。
  • readErpSessionStatus() 在登录/权限页面或页面注入异常时异步触发恢复，不阻塞平台 PING；桥接和平台状态新增 session_ready、恢复状态、恢复次数和最近恢复时间。平台在会话异常/恢复中保持告警并阻止新的任务下发，恢复失败要求人工确认，不自动重交。
  • lifecycle mapping、插件 README、popup 文案和 tools/erp-session-keepalive.test.mjs 已同步；定向保活回归 4/4、生命周期契约 47/47、相关 JS 语法检查通过。
  • 扩展已递增到 0.5.140；dist/ltjt-order-assistant-0.5.140.zip 已通过 unzip -t，SHA-256 为 5d2eceb77a337849bd20bc3e03dea4c86b617c789dd196b8a47bbb33c0da0338；0.5.139 已归档到 archive/releases/2026-08-24/。
  • 完整门禁最终通过：check:repo 9/9、check、串行 test:control-plane 66/66、test:legacy 214/214、build、git diff --check；未进行真实 ERP 写入、任务重试、外部发送、重启或部署。

2026-08-22 — 取消产品/客户来源地强制匹配

  • 用户日志中的阻断发生在 shared_child_order_create 的浏览器只读阶段，唯一失败项为 product_customer_source_region：产品关键字识别出“贵阳”，客户来源信息未命中；客户、OP、销售和领队候选本身均已唯一，且 no_erp_write=true。
  • 当前 Schema 没有要求产品与客户来源地相同；强制关系来自插件 inpage.js、team-batch-inpage.js 的运行时来源地兼容门禁，以及客户候选的产品来源地消歧 fallback。
  • 活动规则已收敛为：产品和客户分别进行 ERP 唯一解析；客户关键词在精确/唯一包含失败后仍可用客户自身来源词做唯一 fallback，但该 fallback 不读取产品；产品/客户来源地不一致不阻断 DoInfoJH、DoInfoJHs 或 DoInfoSPs。
  • 已移除来源地兼容函数和跨产品/客户候选消歧；保留产品候选唯一、客户候选唯一、人员/领队校验、写入前门禁、明确 ERP 回执及 fresh requery。source-region.js 仅保留客户侧候选辅助接口。
  • 扩展已递增到 0.5.139，平台最低版本、生命周期 mapping、运行时版本断言、业务页、mapping、夹具和说明同步；dist/ltjt-order-assistant-0.5.139.zip SHA-256 为 d3ad25b6c22f5269a2fa713441f3b2aebf4cbcf3dff96bdafcef15d29d810353。
  • 上一版 0.5.138 已保存在 archive/releases/2026-08-22/；本轮未重试用户任务、未写入 ERP、未重启、未部署、未向外部渠道发送消息。

2026-08-20 — ERP 会话待机保活实现

  • 现有插件已有执行期间的 MV3 worker/page keepalive，但没有空闲时的 ERP 会话请求；lwlt-confirmation Skill 明确“定时和外发”不属于业务 action，因此本次只修改插件宿主维护逻辑，不扩展 operation、Schema 或 Skill 输入契约。
  • 安全实现采用 chrome.alarms，默认首次约 1 分钟、之后每 5 分钟触发；只查找现存且 allowlisted 的 https://lwlt.hisy.cc/* 标签页，不自动新开标签、不调用 tabs.reload()。
  • 页面侧通过主世界 fetch('/System/Mainlt.asp', { method: 'GET', credentials: 'include', cache: 'no-store' }) 发送轻量只读请求；检查最终 URL、HTTP 状态和登录/权限页面特征，结果写入本地状态并通过插件面板展示。
  • 当 ERP 自动化或单独保活开关关闭、执行中任务存在、没有已加载 ERP 标签页或权限不可用时，保活跳过/失败且不触碰业务写入；浏览器或操作系统休眠会延迟 alarm，不能保证休眠期间持续请求。
  • 扩展已递增到 0.5.138，同步 manifest.json、平台最低版本、生命周期 mapping、页面运行时版本和定向回归；版本化 ZIP SHA-256 为 751dfe6022d61c7388c602089c703b88a9bfeebf67f81edacea1555545d7bcd0。

2026-08-19 — AgentBus 无状态消息但任务成功（诊断进行中）

  • 已确认本轮是只读诊断；工作区存在大量既有未提交改动，不能回退或覆盖。
  • 当前尚未取得该次成功任务的任务 ID、渠道 ID 或运行时发送日志；先以当前契约、源码、测试和已有控制面证据定位确定性条件。
  • 待核对：任务状态事件生成、回复路由是否持久化、AgentBus 渠道是否启用/握手、accepted/processing/result 是否进入 durable outbox，以及失败/重试语义。
  • 登记表列出的 agent设计规范/businesses/confirmation_export.md 当前不存在；已转用行为注册表、lwlt-confirmation Skill、AgentBus 回复契约和源码作为活动规则来源。
  • 当前 control-plane/README.md 明确用户侧只持久化发送一次 task.progress(status=accepted) 和一次 task.result；不会发送“解析完成/等待确认/进入 ERP”的中间进度，因此“processing”不是当前 AgentBus 对外消息。
  • lwlt-confirmation Skill 与标准 operation Schema 只描述业务解析/执行事实，不承诺定时或主动外发；lifecycle.mapping.json 的 scheduled=false/sent=false 属于业务附件外发字段，不能单独证明 AgentBus 回执已发送或未发送。
  • AgentBus 回复契约明确用户侧预期是“受理通知 + 最终返回通知”，但执行阶段、页面打开、提交中和回查等中间状态只进入平台生命周期/审计；因此本次“没有处理消息”首先是契约预期与实现定义不一致，仍需查清 accepted/result 为何也未达渠道。
  • 生产数据库渠道走 durable delivery：AgentBusListener.processInboundTask() 将 channel_id、入站 frame 路由和 accepted payload 一起交给 TaskService.ingestMessage()；只有这些路由字段存在时，事务才插入 agentbus_deliveries(delivery_kind='accepted')。
  • durable 模式下不会直接发送 accepted；listener 每秒/session.ready 后 flush outbox。只有 accepted delivery 已标记 delivered，且任务进入终态，才会创建 delivery_kind='result'；因此 accepted 没投递成功时，result 会被有意延后，而任务本身仍可继续完成。
  • 手工操作台/API 任务没有 AgentBus channel_id/agentBusRoute，recordAgentBusAcceptedDelivery() 会直接跳过；该任务可以成功，但不会生成任何 AgentBus delivery。判断“任务来自 AgentBus”必须看 tasks.source='agentbus'、tasks.channel_id 和入站回执行。
  • listener 只有在 agentBusEnabled、渠道 enabled=true、全局 WebSocket URL/渠道 key/bot address 可用并收到 session.ready 后才会发送；连接断开会把 sending 释放回 pending，失败按退避重试。当前源码测试覆盖 legacy 直发和数据库渠道 durable accepted/result 两种路径。
  • tasks.source 仅允许 manual/agentbus，tasks.channel_id 可为空；agentbus_deliveries 对 accepted/result 做唯一约束，默认 pending，失败会重试。数据库设计本身允许“任务已成功但 delivery 未送达”的中间状态。
  • TaskService 的执行结果路径只更新任务、写 task_events/通用 outbox_events 并发出内部 events；AgentBus result 不是在任务成功事务内直接发送，而由 listener 的 durable flush 后置生成。因此仅看到控制面“任务成功”日志，不等于看到 outbound_durable_delivery_sent。
  • 最终诊断：processing 缺失是设计行为；accepted/result 同时缺失则不是“ERP 任务成功”能够覆盖的成功条件，优先检查该任务是否为 source=agentbus 且绑定 channel_id，再检查对应 accepted/result delivery 是否存在及其 pending/failed/delivered 状态。没有任务 ID 和任务时段日志，无法在“手工任务无路由”与“AgentBus delivery 未投递”之间做历史唯一归因。
  • 当前只读 /health/ready 探针返回数据库/schema 正常，4 个启用渠道均 connected=true、session_ready=true；未执行外部发送、任务重试、重启或部署。
  • 现场日志已捕获用户刚发的成功任务 TASK-20260819102429-R13bn8w：入站 frame 为 wechat-task-c6540dcf293678ec2d76dfeb#1，控制面先发送 accepted（delivery 4d447c5b-1012-437c-9e00-2854429a91d3），后发送 completed result（delivery e4b3db12-abc2-49b8-b97f-a1674fe876a8），两条均有 outbound_durable_delivery_sent。
  • 同一 result frame 之后收到 AgentBus server 的 accepted-177 与 delivered-178 确认帧；日志没有 outbound_durable_delivery_failed、socket_error 或 socket_close 与该任务相邻。因此“控制面未给 AgentBus 返回”已被排除；“delivered”只能证明 AgentBus WebSocket/网关接收，不证明微信客户端已经渲染。
  • 该任务的 processing 仍不会发送，这是契约设计；本次 accepted/result 已实际发送却用户不可见，剩余故障域是 AgentBus 网关到微信适配器/会话的下游路由、事件类型渲染或会话展示。

2026-08-19 — confirmation_export Chrome host 权限阻断

  • 两份用户粘贴日志内容结构相同但任务编号/时间不同；外部 Agent SSE 正常完成，标准 operation 校验通过，action 为 confirmation_export，文件类型为 xingyou-confirm。
  • 两次都在插件浏览器执行阶段阻断，错误完全一致：Cannot access contents of the page. Extension manifest must request permission to access the respective host.；agent_returned=true、plugin_dispatch_started=true、erp_write_started=false、no_erp_write=true，没有 ERP 写入或导出源回执。
  • 当前扩展 manifest.json 已递增到 0.5.137，仍只允许登记的 https://lwlt.hisy.cc/*；background.js 用同一固定 origin 查找/打开 ERP tab，随后通过 chrome.scripting.executeScript 注入页面脚本。
  • runPageAction() 的业务动作执行使用主框架；resolveOperationInErp() 也使用主框架，但前置/只读探针路径有 allFrames=true 调用。Chrome 原始错误没有在源码中硬编码，说明需要区分固定 ERP host、重定向 host 和受限 frame 三种触发条件。
  • 对固定 ERP URL 的外部只读 HEAD/重定向探测因连接超时未得到网络证据；不读取秘密配置，不重试外部业务任务。
  • 修复已在后台增加 chrome.permissions.contains host 前检、tab origin 复核、同源导航竞态的一次安全重试和结构化权限错误；平台桥接状态现在展示 ERP 页面权限，并在权限不可用时阻止新的自动 handoff。
  • 定向验证已通过：扩展/平台语法检查、operation plan 40/40、生命周期契约 47/47；check:repo 9/9 通过，0.5.137 ZIP 与源码逐文件一致。

2026-08-18 — visitor-list XLSX 转换失败日志

  • 用户提供的运行记录中，外部 Agent 解析完成并进入插件只读阶段；没有 ERP 写入。
  • 最终阻断原因为 artifact_delivery_failed:visitor_xlsx_conversion_failed:conversion_failed：游客信息已读取，但移动端 .xlsx 派生文件生成失败。
  • 系统按 fail-closed 规则没有把原始 HTML-in-XLS .xls 回传 AgentBus，因此不能把前面的 confirmed 自动化事件当作最终成功；最终任务状态是 blocked。
  • 当前需要继续核对转换器的输入路径、LibreOffice 调用/退出码、输出发现与 XLSX ZIP/magic 校验；在得到根因前不执行 ERP 重试。
  • 已用当前 bundled soffice 对脱敏 HTML-in-XLS fixture 复现：输入被识别为 Writer/Web document，执行 xlsx:Calc MS Excel 2007 XML 时退出信号为 SIGABRT，stderr 为 Unspecified Application Error；输出目录仅有锁文件和临时文件，没有有效 XLSX。该崩溃是当前 conversion_failed 的直接根因候选。

2026-08-18 — 散拼母团创建写后回查假阴性修复

  • 用户已人工确认本次 2027 年三个母团实际创建成功；本次错误因此确定为写后回查假阴性，而非 ERP 创建失败。
  • ERP 成功响应完整返回 3 个团号，精确回查却全部为 parent_group_not_found；最终错误为 erp_result_uncertain，系统未自动重试。
  • 当前 createSplitParentLive() 仅在 groupNumbers.length < dates.length 或启用事实探针时调用 reconcileSplitParentByRequest()。本次 3 个返回团号等于 3 个日期，导致精确回查全部失败时仍跳过按日期兜底。
  • 精确回查调用 searchMainPage() 时只设置日期范围与团号，没有显式清空客户、产品、游客/领队和状态筛选；列表复用现有文档，因此残留筛选可能隐藏已创建行。
  • 修复范围已确认：清空非目标筛选、有限延迟只读重试、任一精确团号未命中即触发按日期兜底；不得再次提交创建请求，持续缺失或歧义仍保持不确定态。
  • 当前实现使用 0/750/2000ms 三次精确只读查询；每次查询都设置日期与团号，并清空客户、产品、游客/领队和状态筛选。
  • 恢复判定现在同时检查保存响应、团号数量、精确回查完整性和事实探针；任一条件需要恢复时调用现有逐日期唯一匹配。回查行合并会让成功的日期兜底结果覆盖先前空结果，但不会覆盖歧义或缺失门禁。
  • 定向测试已通过：split-plan-reconciliation 14/14；生命周期静态门禁 1/1。测试确认首次全空、第二次可见可收敛，持续缺失会耗尽有限预算并保持未确认，且 createSplitParentLive() 仍只有一次 captureAjaxSubmit() 保存捕获调用。
  • 扩展已递增到 0.5.135，当前 ZIP SHA-256 为 9f49f5529083cb1cc497bfc52c56d0142076394c034552fcdd77e34e70ce7f14；旧 0.5.134 已进入日期归档。
  • 完整验证中，本次回查相关代码、legacy 214/214、类型检查、构建、仓库与发布物门禁均通过。控制面唯一失败来自任务开始前已有的游客 XLSX 并行改动：convertDocumentToXlsx() 期待 .xlsx，测试假 soffice 仍只生成 team.pdf；本轮未改动该策略或测试。

2026-08-18 — visitor-list AgentBus XLSX 交付

  • 用户日志中的源文件为 LW-260816Z-A Visitor.xls，源大小 9,377 字节，源 MIME 为 application/vnd.ms-excel; Charset=UTF-8，并带有独立 SHA-256。
  • 历史 ERP 实时采集记录确认 /System/Business/orders_Visitor.asp 的响应虽然声明 application/vnd.ms-excel，但首字节是 HTML 文档头，属于 HTML-in-XLS wrapper，不是标准 BIFF/OLE .xls。
  • 桌面 Excel 会兼容解析这种 HTML 表格；手机 Office/微信通常同时检查扩展名与文件签名，遇到“.xls 文件名 + HTML 内容”会提示格式不支持。这与用户“电脑能开、手机和微信打不开”的现象一致。
  • 插件 chrome-extension/ltjt-order-assistant/inpage.js 用 response.arrayBuffer() 读取 ERP 响应，再计算 SHA-256/base64；没有文本转码或重写。
  • 控制面 prepareExecutionArtifacts() 对 visitor-list 直接沿用源字节、源文件名和源 MIME；OSS 写入设置 attachment disposition 并保留 MIME。当前证据不支持平台或微信链路把文件内容损坏，问题边界在 ERP 源格式。
  • 仅把扩展名改成 .xlsx 或只改 MIME 不能修复；要在手机/微信打开，必须生成真实 .xlsx（保留表格语义）或 PDF。
  • 用户已确认双文件方案：原始 .xls 仅作为平台源归档，真实 .xlsx 作为移动端/AgentBus 交付文件；其他类型仍按 PDF 规则处理。
  • convertDocumentToXlsx() 识别 HTML-in-XLS，调用 LibreOffice Calc MS Excel 2007 XML，校验 ZIP/XLSX magic；转换失败返回 source_fallback，任务层对 visitor-list fail-closed，不把原始 XLS 发送给 AgentBus。
  • 游客导出报告现在同时记录 source_artifact_count=1、derived_artifact_count=1、xlsx_count=1 和 delivered_artifact_count=2；原始 artifact 标记 artifact_role=source_archive、agentbus_visible=false，XLSX 标记 artifact_role=mobile_delivery、agentbus_visible=true。
  • reply-contract.ts 和 agentbus.ts 均过滤 agentbus_visible=false，因此用户回执文本、普通附件元数据、直连与耐久 AgentBus outbox 都只暴露 XLSX。
  • 已用 artifact-tool 导入并检查真实 XLSX：工作表单元格可读取，渲染预览正常，文件头为 ZIP/XLSX；验证使用 LibreOffice 实际转换路径而非仅改扩展名。
  • 本轮复现进一步确认：同一 HTML 内容临时文件名为 .xls 时，LibreOffice 将其识别为 Calc document 并成功生成 6KB 有效 XLSX；临时文件名为 .html 时则识别为 Writer/Web document 并 SIGABRT。修复已将 HTML 源临时扩展名固定为 .xls，并让回归测试断言该导入路径。
  • 修复后的完整门禁全部通过：check:repo 9/9、类型检查、控制面 66/66、legacy 214/214、build、git diff --check；面板已重启，新 PID 24717 监听 127.0.0.1:8786，live/ready 与 4 个 AgentBus 渠道均正常。

已完成的相关交付

  • confirmation_export 已按类型交付：visitor-list 源 XLS 归档并生成真实 XLSX，AgentBus/微信只返回 XLSX；其余类型 PDF；转换失败回退源文件。
  • 已同步控制面、Skill、输出契约、Schema、mapping、插件提示、测试、版本化 Skill/扩展包、运营 DOCX 和发布清单。
  • 散拼子单导出二次查询已移除固定“收客中”过滤，仍保留母团/子单/ddid/tid 唯一核验。
  • 上一轮验证全部通过：check:repo 9/9、check、控制面 61/61、legacy 208/208、build、git diff --check；Skill 官方校验和 DOCX 15 页渲染检查通过。

约束与证据边界

  • 当前证据是脱敏的响应摘要（路径、状态、MIME、长度、内容特征、哈希），未保存真实游客资料或完整源文件；不能在本地对用户这一个 9,377 字节样本再运行 file/移动端实测。
  • 未读取或输出秘密配置；未执行 ERP 写入、重试、重启、部署或外部发送。
  • 压缩前完整 findings 已冻结到 visitor 移动端诊断前 findings；更早历史事实仍在同目录日期归档中。
Reference in new issue View Git Blame Copy Permalink