LWLT-AIBOT/archive/project-history/2026-08-18/progress-pre-compression-agentbus-status.md

# 项目进度

## 2026-08-18 — 文件获取统一转 PDF（已完成）

- `confirmation_export` 由平台统一转 PDF；失败、超时或无效输出回退源文件，OSS/AgentBus 附件链路保持一致。
- `check:repo` 9/9、`check`、control-plane 57/57、legacy 202/202、build、diff check 与 10 页 DOCX 渲染均通过。

## 2026-08-18 — AgentBus 渠道状态同步修复

- [x] 修复旧控制面进程停机时将新进程渠道状态覆盖为 `disabled` 的问题；进程关闭和监听器重载不再把渠道当作管理员停用。
- [x] `/api/channels` 现在优先投影当前监听器的实时连接状态，避免数据库短暂陈旧状态误导操作台。
- [x] 为状态回写增加会话 epoch 防护，旧会话不能覆盖新会话；新增状态投影与停机回写回归测试。
- [x] 控制面测试 59/59、类型检查、build、`git diff --check` 通过；重启后 `/health/ready` 及数据库均确认 3 个启用渠道为 `connected`。
- 面板已重启，`/health/ready` 返回数据库、Schema 和 3 个 AgentBus 渠道均正常；OSS 保持启用，此前 AccessKey 需尽快轮换。

## 2026-08-17 — AgentBus 渠道重载状态修复（已完成）

- 修复 `AgentBusListener.stop()` 在内部 reload 时无条件写入“已停用”的竞态；`reload()` 现在只停止连接，不覆盖启用渠道的持久化状态。
- 修复启动阶段同一渠道 `connecting`/`connected` 异步写入乱序；现在按渠道串行化状态写入。服务真正关闭或管理员明确停用渠道时仍会写入 `disabled`，内部重载按 `connecting` → `connected` 更新。
- 已授权重启控制面并验证 `/health/ready`：王徐明、阿虹两个渠道均 `enabled=true`、`connected=true`、`session_ready=true`。
- 带登录态的 `/api/channels` 和刷新后的渠道页面均显示两个渠道为“已连接”。验证通过：control-plane 53/53、build、`git diff --check`；仓库卫生/legacy 受既有 `.DS_Store` 和发布 DOCX 哈希不一致影响，未改动这些文件。未执行 ERP 写入或外部业务发送。

## 2026-08-17 — 插件超时与历史队列自愈（实施中）

- 用户确认实施双层超时：单任务 10 分钟、历史队列维护 30 分钟；计时起点为插件实际领取任务。
- 本轮将保留可能写入 ERP 的回查保护，避免通过批量失败/重试制造重复写入；ERP 写入、部署和服务重启均未授权。
- 当前阶段：检查控制面租约、队列 claim、插件任务状态和现有测试，随后实现并全量验证。
- 已定位两个根因：非终态进度会滑动延长租约；已结束的 `reconciliation_pending` attempt 仍被活动槽查询计入。
- 设计落点：服务端硬截止、插件本地硬截止、只允许有效 `accepted/running` attempt 占槽；可能写入的超时任务改为失败显示并保留回查标记。

## 2026-08-17 — AgentBus 渠道名称二次维护（已完成）

- 独立 `/channels` 页面为每个渠道增加“维护名称”按钮，调用现有 `PATCH /api/channels/:channelId`，默认渠道同样可改名。
- 默认兼容渠道保留 `legacy-env` 稳定标记；启动补建逻辑改为按该标记查找，避免改名后生成重复默认渠道；已产生的重复记录会在启动时停用，列表和 listener 会隐藏/跳过它。
- 已通过前端语法、TypeScript、build、check:repo 9/9、control-plane 53/53、legacy 202/202 和 `git diff --check`。
- 重复记录清理逻辑已随控制面重启加载；本轮未读取 `.env`，未执行 ERP 写入或外部发送。

## 2026-08-17 — AgentBus 渠道独立根路径与 404 修复（已完成）

- 已复现 `127.0.0.1:8786/api/channels` 返回 `Route GET:/api/channels not found`。
- 已定位为旧 `tsx` 控制面进程未重载；源码与最新 `.build` 已有 `/api/channels`。
- 已把渠道管理迁移到独立 `/channels` 根路径，新增页面路由、导航、缓存版本和对应契约断言；API 路径保持 `/api/channels`。
- 已通过前端语法、TypeScript、仓库卫生 9/9、控制面 51/51、legacy 201/201、构建和差异检查。
- 用户已授权重启；新控制面进程已加载 migration 012。`GET /api/channels` 返回 401 鉴权响应，`GET /channels` 返回 200，`/health/ready` 显示 AgentBus 默认渠道 `connected/session_ready`。
- 未读取 `.env`，未执行部署、ERP 写入或外部业务发送。

## 2026-08-17 — 多 AgentBus 用户渠道与插件串行队列（已完成）

- 已完成 migration 012、渠道服务、每渠道 AgentBus listener、加密 key/轮换、渠道管理 API/操作台和配置示例。
- 已完成 durable 入站/回执 outbox：按 `channel_id + inbound_frame_id` 幂等，受理与最终回执可持久化，发送租约支持失败重试、断线释放和重连补发。
- 已完成组织级 FIFO ERP claim：组织事务锁、活动 execution/不确定结果阻断、排队位置返回；平台自动派发增加单任务防护。
- 已完成渠道字段、路由和回执契约的控制面回归；AgentBus 兼容路径保留旧环境配置和旧测试语义。
- 当前验证：TypeScript `--noEmit`、仓库卫生 9/9、控制面 51/51、legacy 201/201、聚合测试、构建和 `git diff --check` 全部通过；完整计划已归档并压缩活动计划。
- 边界：未读取或输出真实 key，未执行 ERP 写入、部署、重启或外部业务发送。

## 2026-08-17 — 多 AgentBus 用户渠道与插件串行队列（需求澄清）

- 已按治理规则读取项目入口、Planning 三文件、业务登记表、代表性业务页/Skill/Schema/mapping，以及 AgentBus、任务服务、操作台和 Chrome 扩展执行链。
- 已确认当前 AgentBus 为单个环境级 listener/key；入站任务没有具体用户归属。
- 已确认当前插件防重按 task ID，服务端没有组织级活动 ERP execution 槽；多个自动任务可能同时 claim/dispatch。
- 下一步待用户确认插件串行范围；推荐同一组织/同一 ERP 浏览器会话全局一次一个任务，其余任务持久化排队。

## 2026-08-17 — 多 AgentBus 用户渠道与插件串行队列（队列范围已确认）

- 用户已确认：同一组织/同一 ERP 浏览器会话全局只允许一个插件任务执行，其他渠道任务在服务端持久化排队并按创建时间领取。
- 当前继续确认“单独设置 AgentBus key”的协议含义；现有实现中该 key 只用于 WebSocket Bearer 握手，若按此含义实现，需要多渠道独立 listener/连接。

## 2026-08-17 — 多 AgentBus 用户渠道与插件串行队列（渠道身份已确认）

- 用户已确认：渠道用户是独立的外部身份，不直接创建后台登录账号；后台管理员统一管理渠道和任务。
- 发现串行插件队列会放大当前 AgentBus 内存回执的超时/重启风险；正在确认是否同步落地持久化回复 outbox，避免排队任务产生假超时或丢最终回执。

## 2026-08-17 — 多 AgentBus 用户渠道与插件串行队列（方案待整体确认）

- 用户已确认完整关键边界：组织/ERP 浏览器会话全局单插件槽；每个外部用户渠道独立 AgentBus listener/key；渠道用户不创建后台登录账号；入站路由与最终回执持久化并支持重连补发。
- 已形成实施方案：`user_channels` 渠道配置与加密 key、按渠道隔离任务幂等/会话、AgentBus 回执 outbox、组织级 FIFO ERP claim、操作台/扩展排队状态及回归测试。
- 默认假设已记录在 `task_plan.md`：组织级自动化开关保持不变；通用连接参数走环境配置；渠道禁用而非物理删除；不确定 ERP 结果阻塞后续 claim。
- 当前仍未修改业务源码、数据库迁移或运行配置；等待用户确认上述整体方案后进入实现阶段。


## 2026-08-17 — AgentBus onboarding 更新后重新对接

- 已读取 onboarding 文档并核对当前 AgentBus listener 源码；公开连接地址、bot 地址和 `ready=1` 握手方式一致。
- 已确认受保护运行配置中的 token 与 onboarding 文档一致；未把敏感值写入仓库或输出。
- 已刷新 listener；新进程收到 `session.ready`（epoch 2），`/health/ready` 与 `/api/status` 均显示 AgentBus connected/session_ready。
- 已通过 Invoke API 发出一条“仅测试、不执行 ERP”的探测；接口 accepted，listener 收到并发出受理通知和最终失败回执，证明 AgentBus 双向链路可用。
- 探测失败原因为测试文本未得到标准 JSON 解析结果；当前进程未看到新的微信渠道入站帧，渠道消息问题需继续定位上游 Channel Adapter 投递。
- 用户再次发送后连续观察 20 秒，仍没有新的 `channel:wechat` 帧；当前 listener 进程和 session 保持健康，问题边界进一步收敛到 AgentBus 上游渠道适配/投递。
- 未写入 ERP，未改变真实业务任务数据；仅产生一条非业务测试任务。

## 2026-08-17 — AgentBus 文件传输探测

- 用户确认渠道侧修复后，已向 Invoke API 发送 59 字节临时 `agentbus-file-test.txt`，接口返回 `202 accepted`。
- listener 实际收到 `attachments` 字段并完成受理；由于当前入口只传递 `payload.text`，最终回执没有附件，未形成真正文件回传。
- 已确认上一条微信文本任务的最终回执获得 AgentBus `accepted`/`delivered`，文本消息链路恢复；未执行 ERP 写入。

## 2026-08-17 — AgentBus 主动发信探测

- 已通过 onboarding Invoke API 发送纯文本探测；API accepted，listener 收到并受理，最终失败回执经 AgentBus 发出并获得 `accepted`。
- 失败原因仅是探测文本不构成有效业务指令；未进入 ERP、未写入业务数据。

完整治理前进度见 [2026-08-16 快照](archive/project-history/2026-08-16/progress.pre-governance.md)；更早完整历史见 [2026-08-12 快照](archive/project-history/2026-08-12/progress.full.md)。

## 2026-08-16 — 生产 PostgreSQL / OSS 对接

- **状态：** 已完成本轮代码和远程基础设施对接验证。
- 已确认并执行：`lwlt_agent` 内新建 `liansyn_prod` Schema，001–011 迁移全部应用；旧 `public` 测试 Schema 未改动。
- 已完成：Aliyun OSS V4 provider、公共 URL、随机执行 UUID 对象路径、OSS 事务失败清理、生产配置模板和关闭自动清理开关。
- 已验证：OSS 临时对象上传成功、匿名读取 HTTP 200 且 SHA-256 一致、匿名写入 HTTP 403、后端删除成功；事务回滚后探针对象 HTTP 404；生产 Schema 仍为 0 条业务数据。
- 已完成：`check:repo`、类型检查、控制面/遗留测试、聚合测试、构建、差异检查和部署前配置边界检查；未部署/重启服务，未执行真实 ERP 写入。

## 2026-08-16 — AgentBus 用户回复契约重构

- **状态：** 已完成本轮实现与本地验证；真实 ERP 写入、部署、重启和外部发送未执行。
- **已完成：** 用户确认失败回传、成功按业务/客户模板回传，以及只保留受理通知和最终返回通知。
- **已完成：** 核对业务注册表、五类 Skill/action、当前 `task-service`、AgentBus、插件执行结果和附件交付字段。
- **已完成：** 建立统一回执矩阵、酒店中英文模板、酒店变更/清除回执、控制面 action 回执生成、ERP 原生业务反馈提升、AgentBus 两消息路由和 5 组新增回归测试。
- **验证：** `node --run check`、`node --run check:repo`、`node --run build` 通过；`node --run test:control-plane` 46/46 通过。
- **验证：** `node --run test:legacy` 201/201、聚合 `node --run test`、`git diff --check` 均通过。
- **边界：** 文件回执已暴露受控附件元数据和平台下载地址；外部渠道二进制直传、真实 ERP 写入、部署、重启和外部发送未执行。

## 2026-08-16 — 后台附件详情视觉收口

- **状态：** 已完成源码调整与本地验证。
- 移除重要消息、操作审核、后台附件和结果面板之间的无意义横向分割线；保留文件卡片边框和生命周期日志边框。
- 验证：`check:repo` 9/9、`check`、控制面 41/41、legacy 201/201、`build`、`git diff --check` 全部通过。

## 2026-08-16 — 后台附件详情布局收敛

- **状态：** 已完成源码调整与本地验证。
- `confirmation_export` 详情不再显示 action、目标日期、业务选择和操作明细；后台附件区域只展示文件名和下载按钮。
- 附件文件类型和大小从卡片中移除；等待保存与下载链接不可用仍保留为必要状态提示。
- 其他业务的 operation 审核信息、附件鉴权下载接口、任务生命周期日志未改动。
- 验证：`check:repo` 9/9、`check`、控制面 41/41、legacy 201/201、`build`、`git diff --check` 全部通过。

## 2026-08-16 — 全仓库文件治理

- **状态：** 已完成
- **目标：** 固定全项目文件位置、压缩滚动上下文、分离源码/生成物/交付物/历史，并用自动检查阻止后续会话重新散落文件。
- 已完成：
  - 全仓库根文件、活动目录、archive、引用、版本陈述、重复哈希、构建消费者和 DOCX 同步审计；
  - 创建项目级 `AGENTS.md` 和 `tools/README.md`；
  - 重写根 README 与 dist README，停止复制交接状态和制品哈希；
  - 把 TypeScript 构建目标从 `dist/control-plane/` 迁到 Git 忽略的 `.build/`，同步 package、Docker、Compose 和控制面命令；
  - 完整冻结旧 HANDOFF、维护规范、findings、progress、扩展 README、生命周期 release gate 和原始需求覆盖审计；
  - 重建精炼的根 findings/progress；
  - 修复业务页、能力矩阵、模板和全部活动/归档索引链接；
  - 把无版本插件别名、松散 Prompt/示例副本和同步前 DOCX 移入日期归档；
  - 从 Markdown 重建运营 DOCX，并完成 15 页中文渲染视觉检查；
  - 生成 `dist/release-manifest.json`，校验版本化插件、五个 Skill、DOCX 哈希和包/源码一致性；
  - 新增并通过仓库卫生测试，覆盖根目录、Planning 大小、临时残留、发布集合、版本、链接、归档索引和生成边界；
  - 从当前源码成功生成 Git 忽略的 `.build/`，旧 `dist/control-plane` 和两份重建的 `.DS_Store` 已可恢复地移入废纸篓。
- 最终验证：
  - `node --run test` 聚合入口通过：控制面 37/37、平台/插件/解析/生命周期及仓库卫生 198/198；
  - TypeScript `check` 与 `.build/` 生产构建通过；
  - 当前 JSON 全部可解析，活动 JavaScript 语法检查、插件/Skill 归档完整性和 `git diff --check` 通过；
  - 仓库卫生 9/9，通过根目录、Planning 大小、临时残留、发布哈希、版本、包/源码、活动链接、归档索引和生成边界检查；
  - DOCX 15/15 页视觉检查通过。
- 安全边界：本轮不进入 ERP、不修改业务数据、不部署、不重启服务、不更新云端 Profile。

## 当前工程基线

- 插件制品：`0.5.130`；五个 Skill 与 DOCX：`0.5.118`。
- Agent Prompt：`ltjt-agent-prompt-v1.4-updating-wide-parse`。
- 生命周期契约：`ltjt-lifecycle-v2.8-updating-wide-parse-2026-08`。
- 最近治理前验证：TypeScript、控制面、插件/解析/生命周期测试和当前制品一致性均曾通过；本轮结构调整后必须重新执行完整门槛，以本轮最终结果为准。

## 2026-08-16 — 团队文件后台附件交付

- **状态：** 已完成初始数据库附件实现和本地验证；本轮已补齐 OSS provider 与远程基础设施验证，真实部署和生产 ERP 复测未执行。
- **根因：** ERP 源文件读取成功只产生了来源元数据，插件没有把文件字节交给控制面，控制面也没有附件存储/下载能力。
- **控制面：** 新增 `task_artifacts` 迁移和加密数据库存储；执行回执只在所有附件通过大小/SHA-256 校验并写入成功后才允许生成完成回执；下载路由按会话、组织和任务归属校验。
- **插件/平台：** `exportConfirmationSources` 返回原始 base64；操作台详情显示后台附件和鉴权下载按钮；生产配置下附件写入 OSS，格式转换、定时和外发仍明确未实现。
- **发布同步：** 插件升至 `0.5.130`，同步 manifest、平台最低版本、mapping、Schema、业务模板、回归测试、版本化 ZIP、DOCX 和 `dist/release-manifest.json`；旧 `0.5.129` ZIP 已归档到 `archive/releases/2026-08-16/`。
- **最终验证：** `check:repo` 9/9、`check`、控制面 41/41、legacy 201/201、`build` 全部通过；DOCX 15 页中文字体渲染与逐页检查通过，`git diff --check` 无输出。

## 2026-08-16 — 恢复订单状态筛选修复

- **状态：** 已完成源码修复、生命周期专项、全仓库门槛、版本化 ZIP 和发布清单同步。
- **根因：** ERP 会保留顶部状态筛选；旧插件只写隐藏 `S_zhuangtai`，没有点击 `.Menu2[setval]` 状态标签，已取消订单因此可能不在候选集。
- **修复：** 有状态筛选时真实点击 ERP 原生菜单并校验筛选请求；`order_restore` 独立团/母团查询【已取消】，散拼子单查询母团【收客中】；无团号仍使用日期/客户主匹配和产品/领队补充校验。
- **回归：** 生命周期测试从 42 项扩展为 43 项，专项 43/43、控制面 38/38、legacy 201/201、仓库卫生 9/9、类型检查和构建均通过；未重提失败任务、未写入 ERP。

## 2026-08-16 — LW-260903A-A 酒店安排变更

- **状态：** 已完成并完成服务端双回查。
- 已修复酒店安排更新在原生日期为 `2026-9-3` 时未规范化为严格 ISO 日期的问题；同时修复空备注在保留字段校验中被误判为不一致的问题。
- 插件版本升级至 `0.5.125`，Chrome 实时握手确认已加载该版本，ERP 登录/权限状态正常。
- 新建任务 `TASK-20260816050254-3XI46jI` 已解析为 `arrangement_hotel/update`，仅包含 `end_date=2026-09-05` 与 `room_count=9`；经管理员确认后真实写入成功。
- 写后 fresh GET：`id0=88707` 的酒店行保持原酒店、房型、入住日 `2026-9-3`、状态 `未安排`、备注为空，离店日为 `2026-9-5`、房间数为 `9`。
- 写后 fresh `PrintGridLists`：团号 `LW-260903A-A` 的 `D14492` 酒店显示 `9间*2晚`、`9-3至9-5`；平台回执为 `verified`、`requery_matched=true`、`reconciliation_resolved=true`。
- 历史验证基线为 `0.5.125`；当前交付物和哈希见 [dist/release-manifest.json](dist/release-manifest.json)。旧 `0.5.124` ZIP 已可恢复归档到 `archive/project-history/2026-08-16/`。

## 2026-08-16 — ERP 业务拒绝消息回传

- **状态：** 已完成代码修复和发布校验；未清理财务账、未再次提交当前取消任务。
- **问题：** ERP 对取消明确返回 `此团还有【应收团款】账，不能取消！`，旧链路把 HTTP 200 业务拒绝误映射为 `reconciliation_pending`，用户看不到原生原因。
- **修复：** 生命周期适配器输出 `business_blocked` 和 `business_error`；后台把该结果发布为 `blocked / erp_business_rule_blocked`，保留原文并跳过额外回查，不自动重试。
- **发布：** 插件版本升至 `0.5.126`，同步 manifest、平台最低版本、mapping、回归断言、版本化 ZIP 和 release manifest；旧 `0.5.125` ZIP 已从当前 dist 发布集合移除。
- **验证：** `node --run check`、`node --run test:control-plane`、`node --run test:legacy` 已通过；`node --run check:repo` 在修正文档断链后重跑，且插件语法/生命周期专项测试已通过。

## 2026-08-16 — 跨列表候选二次筛选

- **状态：** 已完成本轮修复、完整验证和 Chrome 重载。
- **问题：** `order_cancel` 的订单列表和计划列表各返回 1 个候选时，旧逻辑在各列表内部完成辅助匹配后直接合并，产品条件无法跨列表消歧，最终错误阻断为 2 个候选。
- **修复：** 所有候选合并后统一执行产品/领队可见文本二次评分；唯一最高分才继续，分数相同或无可见证据继续安全阻断。
- **发布：** 插件版本升至 `0.5.127`，同步 manifest、平台最低版本、mapping、回归断言、版本化 ZIP 和 release manifest。
- **验证：** 仓库卫生 9/9、控制面 38/38、legacy 199/199、类型检查、构建和 Chrome 0.5.127 握手均通过；失败任务未自动重提，未产生新的 ERP 写入。

## 2026-08-16 — 恢复订单状态无操作阻断

- **状态：** 已完成代码修复、回归测试、版本化发布包和 Chrome 重载；未重提失败任务，未产生 ERP 写入。
- **问题：** `TASK-20260816073051-2oZzDdI` 已唯一定位到散拼子单 `D14364` 并打开精确编辑页，但恢复目标状态与当前状态没有形成有效迁移，旧逻辑把无操作和缺少 `from_status` 合并成技术错误。
- **修复：** 精确编辑页读取当前状态；目标状态相同返回 `lifecycle_transition_noop` 和明确业务提示，状态不同才补齐 `from_status` 进入严格门禁；解析/执行校验同时区分空状态与目标相同。
- **发布：** 插件版本升至 `0.5.128`，同步 manifest、平台最低版本、mapping、回归断言、版本化 ZIP 和 release manifest。
- **验证：** 生命周期专项 42/42、执行计划专项 40/40、仓库卫生 9/9、控制面 38/38、legacy 200/200、类型检查、构建和 `git diff --check` 均通过；Chrome 已握手确认 `0.5.128`，ERP 登录/权限正常。

## 2026-08-16 — 桌面历史产物收口

- **状态：** 已完成；仅保留一个由当前 Word 会话产生的临时卫生门槛
- 用户已确认把桌面唯一历史文件补录项目归档，并在覆盖核验后清理桌面目录。
- SHA-256 审计结果：56 个有效文件已与项目 `dist/`/`archive/releases/` 重复，10 个历史制品仅存桌面，另有两个系统/Word 残留。
- 10 个唯一制品已补录到 `archive/releases/2026-08-16/desktop-history-import/`，清单内 SHA-256 全部通过；补录后的复核结果为 56 个重复、0 个遗漏、2 个残留。
- `lsof` 确认桌面历史目录没有打开文件后，已将其整体移入 `/Users/inmanx/.Trash/LTJT-历史版本归档-20260816`；原桌面路径已清空，58 个剩余文件保留在废纸篓中可恢复。
- 本轮重新生成的项目根和 `dist/` 下 `.DS_Store` 已分别移入废纸篓；项目当前 DOCX 仍由 Microsoft Word 打开，本轮不碰该文件及实时锁文件。
- 验证结果：补录哈希、`node --run check`、`test:control-plane`（37/37）、`build`、`git diff --check` 均通过；`check:repo`（8/9）与 `test:legacy`（197/198）各仅有同一项失败，即 Word 打开期间 `dist/` 中存在 `~$联泰AI指令表-0.5.118.docx`。

## 2026-08-17 — 插件单任务/历史任务超时自愈（运行态收口）

- 已实现插件实际领取后的 10 分钟硬超时：无 ERP 写入证据的任务失败并释放队列；有写入证据的任务进入只读 reconciliation，不自动重试。
- 已实现控制面 30 分钟历史 reconciliation 维护：超时任务标记失败并退出活动执行槽，同时保留回查所需结果和证据。
- 已修复 AgentBus 投递回调丢失 `this` 上下文导致的重复“已受理，正在处理”问题；控制面已按用户授权切换到新进程 PID `93460`，重启后两个渠道均已 `session_ready`。
- 已定位并修复历史维护 SQL 的 `42P10`：`SELECT DISTINCT` 配合 `ORDER BY a.finished_at` 不符合 PostgreSQL 规则；立即维护已将 15 条超过 30 分钟的历史 reconciliation 任务自动失败并释放队列，当前超时残留为 0。
- 新任务 `TASK-20260817130840-n6YcZ8I` 已完成；accepted/result 两条 AgentBus durable delivery 均为 `delivered`，没有继续重试。其持久化执行结果明确记录 `write_attempted=true`，因此不把这次用户测试误报为“ERP 未写入”。
- 浏览器连接心跳当前报告插件版本 `0.5.132`、状态 `connected`；AgentBus durable outbox 当前无 `pending`、`sending` 或 `failed` 投递。
- 插件版本已同步到 `0.5.132`，生成 `/Users/inmanx/Documents/lwltAPI/dist/ltjt-order-assistant-0.5.132.zip` 并更新发布清单；`0.5.131` 已移入同日期 `archive/releases/2026-08-17/` 供恢复。清理逻辑补齐了只有 `currentBusinessTask` 指针、没有完整缓存记录的历史残留。此前 Chrome 运行态清理已执行，结果为 0 个运行中超时、0 个孤儿任务、0 个当前指针清除；未删除不确定写入历史。扩展管理页受浏览器安全策略限制，当前运行时仍报告 0.5.130。
- 全量验证通过：`check:repo` 9/9、`check`、`test:control-plane` 52/52、`test:legacy` 202/202、`build`、`git diff --check`；SQL 修复后的最终全量复跑已完成。

## 错误记录

- 首次规划补丁使用了错误的 `progress.md` 标题锚点，补丁整体未应用；读取真实标题后修复。
- 当前环境没有 `fc-list`/`fc-match`；改用系统字体文件与 DOCX 实际渲染验证字体。
- 同一补丁不能同时删除并新增同一路径 README；已拆成原子补丁，失败操作没有产生部分修改。
- bundled LibreOffice 默认字体配置连续三次把中文渲染为方框；改用 bundled Poppler fontconfig 后，最终 15 页全部清晰。
- 首轮卫生测试发现 macOS 已重新生成根 `.DS_Store`；再次移入废纸篓后通过，测试保留该阻断规则。
- 归档 README 验证发现两处旧维护规范断链；已切换到 `AGENTS.md`。
- 一次只读 `rg` 的反引号导致 zsh 引号不闭合；改用单引号后完成审计，无文件副作用。
- 聚合 `test` 脚本原先硬编码嵌套调用 `npm`，bundled 运行时没有该命令；已改为 Node 22 原生 `node --run`，随后重新验证聚合入口。
- 最终 JSON 检查首次误用 `jq -e empty`，因为命令无输出而提前退出；改用 `jq empty` 后整组验证通过。
- 清理本轮新生成的根 `.DS_Store` 时，预设的旧废纸篓治理目录已不存在；首次命令在 `mv` 前退出，随后改用新的唯一废纸篓目标。
- 首次以绝对路径调用 bundled `node --run check:repo` 时，脚本内子进程因 `PATH` 中没有 `node` 而退出；后续验证统一显式加入 bundled Node 目录。
- `check:repo` 的有效复跑发现 `dist/.DS_Store` 以及已知的 Word 实时锁文件；前者继续清理，后者在 Word 打开期间保留。

## 2026-08-17 — 团队文件源文件回传 AgentBus 来源渠道调查

- 已读取治理入口、Planning with Files 规则、当前规划/发现/进度、业务登记表和 `confirmation_export` 业务入口。
- 已确认当前平台附件已能保存 ERP 源文件，但 AgentBus 最终回执尚未带文件；下一步只读核对出站帧和附件协议，等待用户确认传输策略后再实施。
- 代码核对显示临时回执与 durable outbox 均只投影附件元数据；数据库附件可恢复正文，OSS 读取接口目前只返回公共 URL，因而“直接文件附件”会涉及新增取件/编码边界。

- 用户已确认按更新后的微信适配器协议实施 URL-only 附件；未执行外部发送或真实 ERP 写入。

## 2026-08-17 — 附件下载消失定位（当前会话）

- 已确认用户提供的任务附件已成功落库，不是 ERP 源文件读取失败；`backend_stored=true`、30,649 字节、artifact ID 均存在。
- 已用当前控制面只读验证附件 URL：未携带后台登录会话返回 `401 authentication_required`，证明现有相对下载地址不能服务外部 AgentBus 用户。
- 已定位 durable AgentBus 回执遗漏顶层 `attachments` 字段；当前附件只存在于后台任务详情和 `important_message` 元数据，外部渠道未获得二进制或可访问下载地址。
- 下一阶段：补齐 artifact 读取/受控直接附件帧、durable/非 durable 一致投影、文件名编码处理及回归测试；不执行真实 ERP 写入、部署或外部发送。

## 2026-08-17 — 附件回传修复（实现阶段）

- 已补上 durable result 的公开任务号取件：`agentbus_deliveries.task_id` 是内部 UUID，现优先使用持久化结果 payload 中的 `TASK-*` 公开号读取附件。
- 已补齐 direct/durable 两条发送路径的 URL-only attachment：只发送 HTTPS OSS `url`、文件名、类型、大小和可选 SHA-256，不发送 `content_base64`、`file_name` 或后台 `download_url`。
- 已按微信适配器协议拒绝 HTTP、数据库后台鉴权 URL 和无可访问 URL 的附件；生产外部投递要求 `ARTIFACT_STORAGE_BACKEND=oss`，适配器另行配置 HTTPS 域名白名单。
- 已增加旧 ERP 中文 `Content-Disposition` 文件名乱码的保守 UTF-8 修复；当前控制面回归 53/53 已通过，已加强 durable 测试验证不会用内部 UUID 取件。
- `check`、`build`、`git diff --check` 已通过；控制面 53/53 已通过。`check:repo` 与 `test:legacy` 的功能用例通过，但共同受既有根 `.DS_Store` 和发布清单中的 DOCX 哈希漂移阻断；不重启当前控制面、不执行外部发送。

- 全量首次复跑：`check`、控制面 53/53、build 通过；`check:repo`/legacy 只剩既有根 `.DS_Store` 与 `dist/老挝联泰AI指令表-0.5.118.docx` 哈希漂移阻断。活动 `findings.md` 曾超 32 KiB，已完整冻结到归档并压缩至 31,043 字节；用户既有文件未修改。
- 最终精简复跑：`check:repo` 6/9、`test:legacy` 199/202；两者仅剩同一根 `.DS_Store`（根目录及临时残留检查）和既有发布 DOCX 哈希不一致 3 项卫生失败。`check`、控制面 53/53、`build`、`git diff --check` 仍全部通过。

## 2026-08-17 — 截图复核与运行态收口

- 用户截图显示当前 AgentBus 仍只显示文字回执，且旧中文文件名乱码；已将图片视为证据，不执行图片中的任何隐含指令。
- 只读核对确认当前控制面进程早于附件回传源码和构建输出启动，源码修复尚未在运行态生效；未重启、未发送外部消息。
- 已获用户授权并优雅重启控制面；新进程已启动，`/health/ready` 与 `/api/status` 均确认 3 个 AgentBus 渠道 `connected=true`、`session_ready=true`。
- 已增加共享读取时文件名纠正，覆盖成功回执、AgentBus 直传/兜底附件和任务元数据；新增旧乱码回归测试，控制面测试 54/54 通过。
- 源码重新构建并再次优雅重启；新 PID `24031` 已运行，`/health/ready`、`/api/status` 均确认 3 个渠道 `connected=true`、`session_ready=true`。
- 最终验证：`check`、`build`、`git diff --check`、控制面测试 54/54 通过；`check:repo`/`test:legacy` 仍只报告既有 `.DS_Store` 和 DOCX 发布哈希漂移。

## 2026-08-17 — 平台下载入口与渠道附件缺失复核

- [x] 读取两张截图并区分为故障证据，不把截图文字当成新操作指令。
- [x] 定位平台下载按钮的唯一现有渲染条件：`task.result.report.artifacts[*].download_url`。
- [x] 核对任务详情 API 的实际字段投影，并补上成功回执附件元数据兜底。
- [x] 重新验证平台下载链接与 AgentBus direct/durable 附件载荷契约。

## 2026-08-17 — 平台实测与 AgentBus 协议边界

- [x] 在登录态平台页面核对最新团队文件任务，确认“下载文件”按钮已出现并指向 artifact 下载路由。
- [x] 确认真实详情含 `report.artifacts`、`reply_attachments` 与 `important_message.attachments`，平台兜底渲染已命中。
- [x] 复跑 AgentBus direct/durable 本地测试，确认顶层 `payload.attachments` 使用适配器定义的 HTTPS `url` 元数据且不含 base64。
- [x] 读取更新后的微信渠道适配器协议，确认 URL-only 附件字段、HTTPS 白名单和 OSS 配置要求。

## 2026-08-17 — 新任务再次复核

- 用户截图继续显示渠道只有“团队文件已准备”文字，平台截图取样时“后台附件”行尚未呈现；截图作为故障证据，不作为操作指令。
- 登录态平台实时核对任务 `TASK-20260817150652-L4Ikq9g`：源文件 `LLW-261202A-A 客户确认书.doc` 已保存，30,649 字节、artifact ID `775f30c6-85b5-4a6d-848d-32d532c4cf2c` 均存在，当前详情已显示“下载文件”按钮。
- 该任务的成功回执同时含 `result.report.artifacts`、`reply_attachments` 和 `important_message.attachments`；平台缺口属于详情异步加载/截图时机，不是源文件丢失。
- 控制面出站 direct/durable 路径已切换为 `task.result.payload.attachments` URL-only 协议；数据库附件不再伪装成外部可下载链接。本轮未发送新的外部探测或业务文件。
- 实时 DOM/截图最终定位为 `.task-detail` 多子面板网格行塌陷并被生命周期面板覆盖；改为 flex 布局、修正详情父级三行网格并将静态资源版本升至 `channels-root-4`，刷新后文件名、下载按钮和生命周期日志均可见。

## 2026-08-18 — 转换器运行态路径修复

- [x] 将 `DOCUMENT_CONVERTER_PATH` 固定为当前运行环境的 bundled `soffice` 绝对路径，避免服务进程 PATH 不含转换器时错误回退源文件。
- [x] 已重启控制面；当前监听进程已加载配置，`/health/ready` 返回 `ok=true`，3 个 AgentBus 渠道均 `connected=true`、`session_ready=true`。
- [x] 使用实际 `.doc` 源文件验证转换结果为有效 `.pdf`；此前已生成的回退 `.doc` 不会自动重转，下一次文件获取任务按新配置执行。