201 lines
16 KiB
Markdown
201 lines
16 KiB
Markdown
# 项目文件治理计划
|
||
|
||
## 当前任务：三次团队文件导出同错诊断
|
||
|
||
- **状态：** 三次同错诊断完成；散拼子单导出二次查询修复与选择性转换实施均已完成。当前规则为：仅游客信息保留 ERP 原生 Excel，其余导出继续转 PDF；未触发 ERP 写入或重试。
|
||
- **输入：** 三份各 728 行的任务日志，内容并非完全相同，但均为 `confirmation_export` 失败。
|
||
- **结论目标：** 确认共同失败点、区分输入/解析/插件/ERP 边界，并定位来源行解析为何稳定失败。
|
||
|
||
### 阶段
|
||
|
||
- [x] 读取项目约束、活动 planning 文件、工作区状态和三份日志基本信息。
|
||
- [x] 确认三次共同错误签名及 ERP 写入边界。
|
||
- [x] 对比三次 operation、查询范围、候选结果和失败详情。
|
||
- [x] 对照业务登记、Skill、Schema、mapping 与 `confirmation_export` 实现定位根因。
|
||
- [x] 核对“仅交付 ERP 原文件”对契约、附件存储/回传、测试与发布物的影响面。
|
||
- [x] 根据 ERP 截图逐项核查同一模块下的所有导出内容、canonical type、路由与原生返回格式。
|
||
- [x] 区分“只对游客信息保留 `.xls`”和“所有导出类型都保留各自 ERP 原文件”的影响范围；用户已明确选择前者。
|
||
- [x] 给出共享理解并获得用户明确执行确认；再实施并完成项目规定验证。
|
||
|
||
### 当前发现
|
||
|
||
- 三份日志均为 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
|
||
|
||
- [x] 在控制面按 artifact type 仅跳过 `visitor-list` 的 PDF 转换，其他类型保持现有转换/回退逻辑。
|
||
- [x] 同步输出契约、业务说明、mapping 和测试，明确“全部”产生 1 个原生 Excel 与其余 PDF。
|
||
- [x] 运行项目规定验证并检查构建/发布清单差异。
|
||
|
||
本轮最终门禁：`check:repo` 9/9、`check`、控制面 61/61、legacy 208/208、`build` 和 `git diff --check` 均通过；Skill 官方 `quick_validate.py` 通过，运营 DOCX 15 页渲染检查通过。未执行 ERP 写入、重试、重启或部署。
|
||
|
||
### 新增只读诊断：visitor-list 移动端/微信无法打开
|
||
|
||
- [x] 对照用户日志确认原生文件名、MIME、字节数和 SHA-256 元数据。
|
||
- [x] 对照历史 ERP 实时源响应证据确认 `Visitor.xls` 的内容特征与真实格式。
|
||
- [x] 核对插件采集、控制面 native 分支、OSS/下载响应是否改写文件字节。
|
||
- [ ] 在“保持 ERP 原始 `.xls`”与“生成移动端可打开的真实 `.xlsx`/PDF”之间取得用户方案确认后再实施。
|
||
|
||
### 本轮实施阶段：散拼子单导出二次查询
|
||
|
||
- [x] 移除 `exportConfirmationSources()` 对 shared-child 的固定 `S_zhuangtai='收客中'` 条件。
|
||
- [x] 保留母团、子单、`ddid`、`tid` 和子单链接唯一门禁，并补充静态回归断言。
|
||
- [x] 递增扩展版本，更新平台最低版本、mapping、版本化 ZIP 和 `dist/release-manifest.json`。
|
||
- [x] 运行项目规定的完整验证并记录结果。
|
||
|
||
### 错误记录
|
||
|
||
| 错误 | 处理 |
|
||
|---|---|
|
||
| 首次 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 和版本化交付物中统一日期语义，并保持生命周期查询/修改的既有匹配策略。
|
||
|
||
### 阶段
|
||
|
||
- [x] 读取新日志并核对解析、插件分发、ERP 写入和回查时间线。
|
||
- [x] 对照 `shared_plan_create` 当前散拼母团适配器的提交与团号回查实现。
|
||
- [x] 确认 ERP 返回成功脚本及 3 个团号，但回查未命中，任务因此进入 `execution_uncertain`。
|
||
- [x] 对照原始无年份输入、运行日期和解析 operation，定位为外部 Agent 直接沿用当前年份，未处理跨年。
|
||
- [x] 用户确认：新建业务无年份日期按下一次发生日补年；修改/查询继续使用既有 ±1 年匹配逻辑。
|
||
- [x] 在解析宿主增加确定性补年，并保持明确年份不变；补充续问历史输入场景。
|
||
- [x] 同步 Agent Prompt、`lwlt-newbooking` Skill、版本化 Skill 制品与发布清单。
|
||
- [x] 增加跨年、当年未来、明确年份、修改/查询不改年的回归测试。
|
||
- [x] 运行项目规定的完整验证并更新交付记录。
|
||
|
||
### 当前发现
|
||
|
||
- 解析补充事件要求 `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 执行问题，并确认是否发生真实写入。
|
||
|
||
### 阶段
|
||
|
||
- [x] 读取项目约束、活动 planning 文件、业务登记和 `lwlt-lifecycle` 契约。
|
||
- [x] 解析用户日志的时间线、错误码、事件数及 ERP 写入边界。
|
||
- [x] 对照外部解析客户端的 abort/timeout 代码，并用本地挂起 SSE 复现错误归类。
|
||
- [x] 确认当前 `order_cancel` operation 只支持单个 `existing_refs.identifier`，不支持一次操作携带多个目标。
|
||
- [x] 输出诊断结论和安全重试建议；修复需用户另行确认。
|
||
|
||
### 当前发现
|
||
|
||
- 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，并按可打印宽度缩放宽表；转换失败继续回退源文件。
|
||
|
||
### 阶段
|
||
|
||
- [x] 对用户提供的 Word HTML `.doc` 与现有 PDF 做文本、页数和页面渲染对比。
|
||
- [x] 固定 `writer_pdf_Export` 分页导出，并为转换子进程自动探测显式/系统/捆绑 fontconfig。
|
||
- [x] 对 Word HTML/旧式 `.doc` 的超宽表格按最大声明宽度动态缩放到可打印区域，保持多页分页。
|
||
- [x] 转换失败、超时、输出缺失/无效或超限时回退源文件。
|
||
- [x] 实际附件转换为 2 页 A4，中文、表格、右边框和正文页面渲染完整；重启后 AgentBus 健康状态正常。
|
||
|
||
### 当前边界
|
||
|
||
| 错误 | 位置 | 结论 |
|
||
|---|---|---|
|
||
| 外链图片 DNS 不可达 | 用户提供的 `.doc` | 文本和表格已保留；源文件引用的远程图片无法在转换进程中获取，未伪造图片内容 |
|
||
| 中文字形缺失 | 旧 PDF | 根因为 fontconfig 未加载；新转换器已自动加载字体配置 |
|
||
| 表格右侧裁切 | Word HTML → A4 | 根因是声明宽度大于 A4 可打印区域；新转换器按最大宽度缩放，页面右边界已通过渲染复核 |
|
||
|
||
## 更早任务：外部 Agent 解析结果契约错误定位
|
||
|
||
- 诊断材料和未决 Profile 版本信息保留在下方历史记录；不影响本次 PDF 修复。
|
||
|
||
## 上一任务：AgentBus 渠道状态同步修复
|
||
|
||
- **状态：** 已完成；用户已确认修复并重启。
|
||
- **问题：** 旧控制面进程停机时把新进程已连接的 AgentBus 渠道回写为 `disabled`，面板因此误显示“已停用”。
|
||
- **目标：** 保证渠道管理页优先展示当前 listener 实时状态，且旧进程不能覆盖新会话状态。
|
||
|
||
### 已完成
|
||
|
||
- [x] `/api/channels` 合并当前 AgentBus listener 状态；启用且已握手的渠道显示 `connected`。
|
||
- [x] 进程关闭与 listener 重载不再把渠道当作管理员停用；显式停用仍由渠道管理接口写入。
|
||
- [x] 状态回写增加 session epoch 防护，旧会话不能覆盖新会话。
|
||
- [x] 增加状态投影、停机回写和 epoch 防护回归测试。
|
||
- [x] 重启控制面并确认 3 个启用渠道 `enabled=true`、`connected=true`、`session_ready=true`；重复兼容渠道保持停用。
|
||
|
||
### 验证
|
||
|
||
- 控制面测试：59/59 通过。
|
||
- 类型检查、build、git diff --check：通过。
|
||
- check:repo：9/9 通过；计划与进度文件超限已完整冻结并压缩。
|
||
- test:legacy：202/202 通过。
|
||
- 完整历史计划快照：[archive/project-history/2026-08-18/task_plan-pre-compression-agentbus-status.md](archive/project-history/2026-08-18/task_plan-pre-compression-agentbus-status.md)。
|
||
|
||
## 最近已完成里程碑
|
||
|
||
- 文件获取类 `confirmation_export` 统一转 PDF；转换失败、超时或无效输出回退源文件。
|
||
- AgentBus 文件附件使用 OSS HTTPS URL-only 元数据返回，平台保留下载入口。
|
||
- 多用户渠道、持久化回执、插件串行队列和历史任务超时自愈已完成。
|
||
- 以上历史决策与验证证据保存在归档快照中；当前规则以源码、契约和根目录活动 findings/progress 为准。
|
||
|
||
## 约束与后续
|
||
|
||
- 保留工作区既有未提交改动；不执行 reset/clean 或物理删除业务数据。
|
||
- 不输出或归档本地秘密配置内容；不执行 ERP 写入或新的外部业务发送。
|
||
- 后续若本计划再次超过 16 KiB，先完整归档到 `archive/project-history/<日期>/`，再压缩并更新对应 README。
|