wangxuming/LWLT-AIBOT
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
07b23fce9e96badbd266bbda682fd16cd6733e22
LWLT-AIBOT/archive/project-history/2026-08-18/task_plan-pre-compression-visitor-mobile-diagnosis.md
T

16 KiB
Raw Blame History

项目文件治理计划

当前任务：三次团队文件导出同错诊断

  • 状态： 三次同错诊断完成；散拼子单导出二次查询修复与选择性转换实施均已完成。当前规则为：仅游客信息保留 ERP 原生 Excel，其余导出继续转 PDF；未触发 ERP 写入或重试。
  • 输入： 三份各 728 行的任务日志，内容并非完全相同，但均为 confirmation_export 失败。
  • 结论目标： 确认共同失败点、区分输入/解析/插件/ERP 边界，并定位来源行解析为何稳定失败。

阶段

  • 读取项目约束、活动 planning 文件、工作区状态和三份日志基本信息。
  • 确认三次共同错误签名及 ERP 写入边界。
  • 对比三次 operation、查询范围、候选结果和失败详情。
  • 对照业务登记、Skill、Schema、mapping 与 confirmation_export 实现定位根因。
  • 核对“仅交付 ERP 原文件”对契约、附件存储/回传、测试与发布物的影响面。
  • 根据 ERP 截图逐项核查同一模块下的所有导出内容、canonical type、路由与原生返回格式。
  • 区分“只对游客信息保留 .xls”和“所有导出类型都保留各自 ERP 原文件”的影响范围；用户已明确选择前者。
  • 给出共享理解并获得用户明确执行确认；再实施并完成项目规定验证。

当前发现

  • 三份日志均为 728 行、24,506 字节，但 SHA-256 不同，说明是三次独立运行而非同一文本副本。
  • 三次共同失败为 plugin_executor_blocked / browser_execution：source row/ref unresolved: row_count=0, child_link_count=0, ddid=true, tid=true；其中 ddid/tid=true 来自上一步引用兜底，不代表二次查询页面重新命中了内部引用。
  • 三次均为 agent_returned=true、plugin_dispatch_started=true、erp_write_started=false、no_erp_write=true；失败发生在插件只读来源解析，不是解析 Agent 超时，也没有 ERP 写入。
  • 第一份日志中，前置唯一解析已将 D14373 解析到母团 LW-260821A-A，并返回 ddid=14373、tid=14275、row_id=tr_14275；随后导出来源快照连母团行也为零，说明失败发生在二次母团搜索/页面解析环节。
  • 本轮新日志明确是 confirmation_export：ERP 源文件为 .xls，控制面将其转为 .pdf 后交付；用户要求改为直接交付该 ERP 原文件。
  • 新截图证明 ERP 中该模块至少有 9 个可见导出入口，不能仅根据一次 Visitor.xls 日志推断全部类型的原生格式。
  • 0.5.84、0.5.93、0.5.118、0.5.132、0.5.133 的导出函数对比显示，母团号 + 收客中 + ddid 行门禁保持不变；版本差异只涉及搜索证据和后台附件内容。因此当前共同失败更符合对象状态/过滤条件冲突，而非近期附件改造回归。
  • 前置唯一解析以空状态过滤按子单号成功；导出二次查询改按母团号并强制 收客中 后连母团行都为零。最高概率根因是目标母团当前不在“收客中”状态，而只读导出错误复用了活动散拼子单的固定状态过滤。
  • 三份日志的业务引用完全一致：均为子单 D14373、母团 LW-260821A-A、出发日 2026-08-21、ddid=14373、tid=14275；只是三个不同任务对同一对象的重复执行。
  • 诊断记录更新后的完整验证通过：check:repo 9/9、check、控制面 60/60、legacy 207/207、build；未执行 ERP 写入、重试、重启或部署。
  • 用户已确认本轮实施范围：仅移除 confirmation_export 散拼子单二次查询中的固定“收客中”过滤，继续保留母团、子单及 ddid/tid 唯一核验。
  • 用户随后明确选择选择性转换：visitor-list 保留 ERP 原生 Excel，其余 9 类继续转换 PDF；此范围已获得执行确认。

本轮实施阶段：游客信息保留原生 Excel

  • 在控制面按 artifact type 仅跳过 visitor-list 的 PDF 转换，其他类型保持现有转换/回退逻辑。
  • 同步输出契约、业务说明、mapping 和测试，明确“全部”产生 1 个原生 Excel 与其余 PDF。
  • 运行项目规定验证并检查构建/发布清单差异。

本轮最终门禁：check:repo 9/9、check、控制面 61/61、legacy 208/208、build 和 git diff --check 均通过；Skill 官方 quick_validate.py 通过，运营 DOCX 15 页渲染检查通过。未执行 ERP 写入、重试、重启或部署。

新增只读诊断：visitor-list 移动端/微信无法打开

  • 对照用户日志确认原生文件名、MIME、字节数和 SHA-256 元数据。
  • 对照历史 ERP 实时源响应证据确认 Visitor.xls 的内容特征与真实格式。
  • 核对插件采集、控制面 native 分支、OSS/下载响应是否改写文件字节。
  • 在“保持 ERP 原始 .xls”与“生成移动端可打开的真实 .xlsx/PDF”之间取得用户方案确认后再实施。

本轮实施阶段：散拼子单导出二次查询

  • 移除 exportConfirmationSources() 对 shared-child 的固定 S_zhuangtai='收客中' 条件。
  • 保留母团、子单、ddid、tid 和子单链接唯一门禁，并补充静态回归断言。
  • 递增扩展版本，更新平台最低版本、mapping、版本化 ZIP 和 dist/release-manifest.json。
  • 运行项目规定的完整验证并记录结果。

错误记录

错误 处理
首次 planning 补丁因文件已被同步更新、上下文不匹配而未应用 重读活动文件后以当前任务为基础做最小增量记录，未覆盖任何既有内容
第二次 planning 增量补丁沿用了过期阶段上下文而未应用 立即重读三个活动文件并基于最新内容补丁；未覆盖并发新增的原文件交付分析
本轮规划补丁因并发同步导致上下文不匹配 改用当前行号附近的精确锚点重读后再增量补丁，未覆盖并发内容
定向生命周期测试仍断言旧扩展版本 0.5.133 将 mapping 基线断言同步到本次 0.5.134 版本，再重跑定向测试
完整验证首轮以 bundled Node 直接执行 --run 时，脚本子进程找不到 node 将 bundled Node bin 目录显式前置到 PATH 后重跑，不改变项目脚本
  • 日志 diff 已确认三次任务 ID、执行 ID、时间、事件号和 SSE 事件数不同；业务登记将该路径定位到 lwlt-confirmation / confirmation_export，实现语义是只读获取 ERP 源文件后交由平台保存/转换。

当前任务：散拼计划日期跨年归一化修复

  • 状态： 修复完成。新建业务无年份日期按下一次发生日补年，修改/查询保留现有 ±1 年匹配；未执行真实 ERP 写入或重试。
  • 输入： 原始输入仅包含 01-01到01-30、01.07/01.15/01.26，运行日期为 2026-08-18；用户确认目标为 2027 年 1 月。
  • 结论目标： 在解析宿主、Prompt、Skill 和版本化交付物中统一日期语义，并保持生命周期查询/修改的既有匹配策略。

阶段

  • 读取新日志并核对解析、插件分发、ERP 写入和回查时间线。
  • 对照 shared_plan_create 当前散拼母团适配器的提交与团号回查实现。
  • 确认 ERP 返回成功脚本及 3 个团号，但回查未命中，任务因此进入 execution_uncertain。
  • 对照原始无年份输入、运行日期和解析 operation，定位为外部 Agent 直接沿用当前年份，未处理跨年。
  • 用户确认：新建业务无年份日期按下一次发生日补年；修改/查询继续使用既有 ±1 年匹配逻辑。
  • 在解析宿主增加确定性补年，并保持明确年份不变；补充续问历史输入场景。
  • 同步 Agent Prompt、lwlt-newbooking Skill、版本化 Skill 制品与发布清单。
  • 增加跨年、当年未来、明确年份、修改/查询不改年的回归测试。
  • 运行项目规定的完整验证并更新交付记录。

当前发现

  • 解析补充事件要求 data.planned_capacity，但同一事件快照里的 operation 已有 planned_capacity: 10；这是事件/状态投影不一致，不是最终执行失败原因。
  • SSE 正常完成（174 个事件），随后进入“全自动化 ERP 执行”；plugin_dispatch_started=true、erp_write_started=true、no_erp_write=false。
  • POST /System/DAT/plan.asp 的 ERP 响应为 HTTP 200、操作成功，共计新增 3 个团队，返回 LW-260107A-H、LW-260115A-H、LW-260126A-I。
  • 三个团号在紧随其后的散拼计划表回查中均为 parent_group_not_found，所以结果是 execution_uncertain / reconciliation_pending，系统停止且没有自动重试。
  • 当前代码在返回团号数量等于指定日期数量且未启用事实探针时，只做逐团号回查，不进入按日期的 fallback 回查；该路径可能产生回查假阴性，但仅凭日志不能断言 ERP 实际未创建。
  • 原始输入只有 01-01、01-30 和 01.07/01.15/01.26，没有年份；运行上下文日期为 2026-08-18，用户明确意图是下一次发生的 2027 年 1 月。
  • agent设计规范/skills/lwlt-newbooking/references/normalization-rules.md 已规定“年份无法确定时只追问年份”，但当前运行链路只把当前日期作为自然语言提示传给外部 Agent，宿主没有确定性跨年归一化或结果校验。
  • 外部 Agent 先生成了合法格式但错误语义的 2026-01-*，Schema/平台只校验 YYYY-MM-DD 和范围关系，无法识别这是错误年份。

错误记录

错误 处理
首次验证命令未注入 bundled Node PATH，shell 报 node: command not found 使用 workspace bundled Node 并显式注入其 bin 目录后重跑通过；不影响诊断结论
首次日期修复定向测试未通过 发现两位数字日期被显式年份正则误识别，且 Prompt 超过 1200 字；收紧正则并压缩 Prompt 后 72/72 通过
首次补丁上下文不匹配 未写入文件；改为精确行补丁后继续

本次交付结果

  • shared_plan_create 等四类新建业务在无年份日期且日期上下文无明确年份时，按 Asia/Shanghai 任务日期归一为下一次发生日；以本次输入为例生成 2027-01-01 至 2027-01-30，以及 2027-01-07、2027-01-15、2027-01-26。
  • 明确年份不改写；修改、查询、取消、恢复等生命周期操作不套用新建补年规则，现有 ±1 年查询匹配保持不变。
  • 已同步 ltjt-agent-prompt-v1.5-next-date-rollover、五个 0.5.119 Skill 制品及 dist/release-manifest.json。
  • 已完成 check:repo 9/9、check、控制面测试 60/60、legacy 测试 207/207 和 build；未读取 .env，未执行 ERP 写入、部署或重试。

上一任务：订单取消指令外部解析超时诊断

  • 状态： 诊断完成；未修改业务代码、未进入插件、未写入 ERP。
  • 输入： 用户提交“取消订单”，包含 3 个单号、预订客户和产品名称；未填写出发日期。
  • 结论目标： 区分输入契约问题、外部 Agent/SSE 超时和 ERP 执行问题，并确认是否发生真实写入。

阶段

  • 读取项目约束、活动 planning 文件、业务登记和 lwlt-lifecycle 契约。
  • 解析用户日志的时间线、错误码、事件数及 ERP 写入边界。
  • 对照外部解析客户端的 abort/timeout 代码，并用本地挂起 SSE 复现错误归类。
  • 确认当前 order_cancel operation 只支持单个 existing_refs.identifier，不支持一次操作携带多个目标。
  • 输出诊断结论和安全重试建议；修复需用户另行确认。

当前发现

  • SSE 在 stream_connecting 后约 120 秒没有任何事件，event_count=0，随后返回 external_cancelled。
  • 本地复现证明 120 秒读流超时路径会因 abort() 与取消 Promise 的竞态被归类为 external_cancelled；这不表示用户主动取消。
  • 默认配置为单次请求 120 秒、总超时 180 秒、解析 Worker 看门狗 240 秒；仅凭日志不能证明运行进程没有覆盖这些值。
  • 现有业务契约的 existing_refs.identifier 是单个字符串，插件也按一个精确标识查找；三条单号应拆成三次独立取消请求，不能把它们拼成一个字段。

错误记录

错误 处理
系统 node 不在当前 shell PATH 使用 workspace bundled Node 复核，未影响结论
首次一次性探针命令转义失败 改为单引号包裹的 bundled Node 探针后成功

上一任务：PDF 转换内容完整性修复

  • 状态： 已完成；已重启控制面并通过健康检查。
  • 问题： LibreOffice 子进程未加载中文字体配置，且 Word HTML 表格宽度超出 A4 可打印区域，PDF 右侧被裁切。
  • 目标： 采用固定分页 PDF 导出逻辑，自动加载 fontconfig，并按可打印宽度缩放宽表；转换失败继续回退源文件。

阶段

  • 对用户提供的 Word HTML .doc 与现有 PDF 做文本、页数和页面渲染对比。
  • 固定 writer_pdf_Export 分页导出，并为转换子进程自动探测显式/系统/捆绑 fontconfig。
  • 对 Word HTML/旧式 .doc 的超宽表格按最大声明宽度动态缩放到可打印区域，保持多页分页。
  • 转换失败、超时、输出缺失/无效或超限时回退源文件。
  • 实际附件转换为 2 页 A4，中文、表格、右边框和正文页面渲染完整；重启后 AgentBus 健康状态正常。

当前边界

错误 位置 结论
外链图片 DNS 不可达 用户提供的 .doc 文本和表格已保留；源文件引用的远程图片无法在转换进程中获取，未伪造图片内容
中文字形缺失 旧 PDF 根因为 fontconfig 未加载；新转换器已自动加载字体配置
表格右侧裁切 Word HTML → A4 根因是声明宽度大于 A4 可打印区域；新转换器按最大宽度缩放，页面右边界已通过渲染复核

更早任务：外部 Agent 解析结果契约错误定位

  • 诊断材料和未决 Profile 版本信息保留在下方历史记录；不影响本次 PDF 修复。

上一任务：AgentBus 渠道状态同步修复

  • 状态： 已完成；用户已确认修复并重启。
  • 问题： 旧控制面进程停机时把新进程已连接的 AgentBus 渠道回写为 disabled，面板因此误显示“已停用”。
  • 目标： 保证渠道管理页优先展示当前 listener 实时状态，且旧进程不能覆盖新会话状态。

已完成

  • /api/channels 合并当前 AgentBus listener 状态；启用且已握手的渠道显示 connected。
  • 进程关闭与 listener 重载不再把渠道当作管理员停用；显式停用仍由渠道管理接口写入。
  • 状态回写增加 session epoch 防护，旧会话不能覆盖新会话。
  • 增加状态投影、停机回写和 epoch 防护回归测试。
  • 重启控制面并确认 3 个启用渠道 enabled=true、connected=true、session_ready=true；重复兼容渠道保持停用。

验证

最近已完成里程碑

  • 文件获取类 confirmation_export 统一转 PDF；转换失败、超时或无效输出回退源文件。
  • AgentBus 文件附件使用 OSS HTTPS URL-only 元数据返回，平台保留下载入口。
  • 多用户渠道、持久化回执、插件串行队列和历史任务超时自愈已完成。
  • 以上历史决策与验证证据保存在归档快照中；当前规则以源码、契约和根目录活动 findings/progress 为准。

约束与后续

  • 保留工作区既有未提交改动；不执行 reset/clean 或物理删除业务数据。
  • 不输出或归档本地秘密配置内容；不执行 ERP 写入或新的外部业务发送。
  • 后续若本计划再次超过 16 KiB，先完整归档到 archive/project-history/<日期>/，再压缩并更新对应 README。
Reference in new issue View Git Blame Copy Permalink