wangxuming/LWLT-AIBOT
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
208c434b312930fadd74bb451a8fb0ffeb8ae71e
LWLT-AIBOT/findings.md
inman 208c434b31 Initial import of LWLT AIBOT platform
2026-08-25 10:33:29 +08:00

19 KiB
Raw Blame History

当前关键发现

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；更早历史事实仍在同目录日期归档中。