wangxuming/LWLT-AIBOT
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
7b5d855b093af39bf834fab4f41f41b37be1170d
LWLT-AIBOT/task_plan.md

15 KiB
Raw Blame History

项目文件治理计划

当前任务：重启控制面并恢复 AgentBus 连接（已完成）

  • 目标： 按用户明确授权，优雅重启标准 8786 控制面，使刚出现断线的 AgentBus 渠道重新建立会话并通过稳定性复核。
  • 安全边界： 仅重启控制面并做只读进程、健康、数据库和 AgentBus 状态检查；不重载扩展，不创建、确认、重试或派发任务，不访问或写入 ERP，不部署或外发。

阶段

  • 确认唯一监听、live/ready 当前状态，并确认在途 task 与 accepted/running attempt 均为 0。
  • 优雅停止当前进程组，并从标准 pnpm run dev 入口恢复唯一服务实例。
  • 核验数据库、Schema、迁移与 4/4 AgentBus 渠道重连，并观察连接状态保持稳定。

完成结论

  • 重启前服务端健康接口已显示 4/4 渠道重新连接，但用户侧刚观察到断线；在途 task 与 accepted/running attempt 均为 0，因此仍按授权执行干净重启。
  • 旧进程组 62152 已退出；运行会话管理器随即从标准 pnpm run dev 入口拉起新进程组 66218、服务 PID 66228，没有再启动第二份实例，8786 保持唯一监听。
  • 新实例 live/ready、数据库、Schema、迁移 014_task_input_attachments 均正常；连续 25 秒共 6 次采样均为 AgentBus 总连接与 session ready 正常、4/4 渠道 ready。
  • 未创建、确认、重试或派发任务，未重载扩展，未访问或写入 ERP，未部署或外发。
  • 重启后门禁通过：仓库治理 9/9、TypeScript、控制面 127/127、legacy 248/248、build 与 git diff --check。

错误记录

  • 首批并行门禁附带的一次 /tmp 临时健康文件清理被安全策略拒绝，导致该批结果未汇总；该操作与服务、数据库和 AgentBus 无关。跳过清理后完整门禁已重新运行并全部通过。

当前任务：将运行态切换到整团游客信息新版（已完成）

  • 目标： 按用户明确授权，优雅重启标准 8786 控制面并重载本地 Chrome 扩展，使 Program parser v1.0.6、输入契约 0.5.123 与扩展 0.5.157 在运行态生效。
  • 安全边界： 仅做进程/扩展运行态切换和只读健康、版本检查；不创建、确认、重试或派发任务，不访问 ERP 业务数据，不执行 ERP 写入、部署或外发。

阶段

  • 确认 8786 live/ready、数据库/Schema/迁移与 4/4 AgentBus 渠道正常，并确认活动任务和 accepted/running 在途 attempt 均为 0。
  • 优雅停止旧进程组并从项目标准 pnpm run dev 入口启动新控制面。
  • 核验 live/ready、唯一监听、解析器/输入契约版本，并重载扩展后确认 0.5.157 握手。

错误记录

  • 旧监听停止后首次启动命令未显式传入 bundled Node PATH，pnpm 在运行迁移前即因 node: command not found 退出；没有数据库或任务变更。已改为在启动进程环境中显式设置 bundled Node/fallback PATH。
  • 旧标准入口在 TERM 后由其会话管理器自动拉起新进程组 62152；因此第二次手工启动完成迁移检查后在绑定前以 EADDRINUSE 安全退出。该临时实例的 AgentBus listeners 已自行关闭，in-flight tasks 与 pending replies 均为 0；保留自动拉起的新实例作为唯一标准运行态。
  • 收敛记录后的首轮五道门禁由 bundled Node 主进程启动，但其子脚本 PATH 中没有 node，所以均在进入检查/测试前退出；显式加入同一 bundled Node 目录后原样重跑并全部通过。

完成结论

  • 标准 pnpm run dev 进程组 62152、服务 PID 62164 是 8786 的唯一监听；live/ready、数据库、Schema、迁移 014_task_input_attachments 与 4/4 AgentBus 渠道均正常。
  • 已通过已登录操作台的只读 API 确认 confirmation_export 运行在 program 模式，版本为 ltjt-program-parser-v1.0.6，输入契约为 business-input-templates-0.5.123。
  • 已重载精确匹配的本地“联泰下单助手”扩展；操作台握手为插件 0.5.157 / 最低版本 0.5.157 / 兼容，桥接已连接、ERP 会话正常、最近错误为无。诊断字段“ERP 链路恢复”仍显示 failed，本轮未扩大授权去访问 ERP 业务页复测。
  • 切换前后活动任务、在途 task 与 accepted/running attempt 均为 0；未创建、补充、确认、重试、删除或派发任务，未访问 ERP 业务数据、执行 ERP 写入、部署或外发。
  • 运行态切换后规定门禁再次通过：仓库治理 9/9、TypeScript、控制面 127/127、legacy 248/248、build 与 git diff --check。

当前任务：散拼母团“整团游客信息”导出接入（已完成）

  • 目标： 保留统一 confirmation_export action，在 文件类型：整团游客信息 时明确锁定 shared_plan，只用母团 tid 调用 orders_Visitor.asp；现有独立团和散拼具体子单“游客名单”继续使用 did+tid，不得混淆范围。
  • 安全边界： 本轮只修改源码、契约、测试和本地发布物；不访问 ERP，不创建、补充、重试或派发真实任务，不重载扩展、重启、部署或外发。

阶段

  • 先补解析、Schema、执行计划和页内导出的失败回归，固定母团 tid-only 与子单/独立团 did+tid 的分流。
  • 修改 Program parser、解析态/执行态契约、ERP 唯一解析与导出适配器，并保持母团只允许该窄文件类型。
  • 同步运营模板、lwlt-confirmation Skill、业务登记、mapping、平台校验与版本。
  • 重建运营 DOCX、Skill 包、Chrome ZIP 和发布清单，逐文件/逐页核验。
  • 运行规定全量门禁并收敛 planning files；运行态切换仍等待另行授权。

已确定的设计

  • 历史只读 ERP 证据确认两者共用 /System/Business/orders_Visitor.asp，但散拼母团使用 tid，独立团/散拼子单使用 did+tid。
  • 不新增业务 action；用 existing_refs.kind 表达对象范围。shared_plan 只对单一 visitor-list 开放，不把“全部”或依赖子单 did 的其他文件类型放宽到母团。
  • 当前 program_invalid_value 属于安全停止，但用户提示应由“不识别文件类型”改为可执行的窄能力或真正的对象定位问题。

错误记录

  • 测试先行阶段的四组定向回归均按预期红灯：Program 仍返回 agent_parse_needs_input；Agent/插件 strict gate 仍拒绝 shared_plan；执行计划仍固定 did+tid；页内 exporter 尚无母团分支。这些红灯证明缺口完整覆盖，不属于环境或测试基础设施故障。
  • 核心实现后四组回归中仅一条旧测试仍要求 blocker 包含“母团”；新规则已不再一概禁止母团，但该无类型、未唯一解析的请求仍安全阻断。测试已改为断言真实缺失项，并补充对象范围契约断言。
  • bundled Python 运行官方 Skill 校验器时缺少 PyYAML，在生成任何新包前即停止；本机 Python 已确认具备 PyYAML 6.0.3，后续用它运行同一个官方校验器。
  • 首次组合定向命令有两项非行为性失败：直接用 Node 执行 TypeScript 测试未加载 tsx，以及 lifecycle 中另一个旧位置仍断言平台最低版本 0.5.156。前者改用项目规定的 --import tsx，后者同步为 0.5.157。
  • 首次 check:repo 为 8/9；唯一失败是治理测试仍固定运营模板版本 0.5.122。已同步为新 DOCX 单一源基线 0.5.123，其余目录、哈希、包/源码和链接检查均已通过。
  • 首次 test:control-plane 为 126/127；唯一失败是操作台测试仍固定旧 app.js 缓存键。已同步为 20260828-shared-plan-visitor-export-1；全部业务/解析测试（含新增整团游客信息用例）本轮均已通过。
  • 最后一组补充语法检查首次未显式带 bundled Node PATH，因当前非登录 shell 找不到 node 而未启动；随后改用 bundled Node 绝对路径重跑，不影响已通过的五道规定门禁。

完成结论

  • 整团游客信息现在确定性解析为 confirmation_export / shared_plan / visitor-list；母团唯一解析后只生成 orders_Visitor.asp?tid=<tid>，且解析态、执行态、插件门禁和页内 exporter 都拒绝其他类型、混合范围及任何子单 did/ddid。普通“游客名单”的独立团/具体子单 did+tid 路径未改变。
  • 发布基线已推进为扩展 0.5.157、Program parser v1.0.6、输入契约/DOCX 0.5.123、五 Skill 0.5.125。扩展 ZIP SHA-256 为 872640668c52cf1ef0135ff51ec33e3c1f5dee304434fbb58ceee4cb3518fcd7；DOCX 12/12 页视觉检查通过，Skill 与扩展包均逐文件匹配源码。
  • 门禁通过：仓库治理 9/9、TypeScript、控制面 127/127、legacy 248/248、build、JS/JSON/ZIP/Skill、DOCX 与 git diff --check。该任务完成时未访问 ERP、处理历史任务、重载扩展、重启服务、部署或外发；后续运行态切换已按用户另行授权完成，见本文件顶部任务。

当前任务：名单人数超过 ERP 容量时使用业务提示（已完成）

  • 目标： passenger_list_import 在 ERP 原生游客位少于名单所需人数时，不再向用户显示 passenger_native_* 等技术码；明确提示本次名单人数和该订单的 ERP 可录入上限。
  • 安全边界： 原技术 blocker 继续保留在技术详情中；仍在父表单保存前失败关闭并保持 no_erp_write=true。不修改或重试历史任务，不访问 ERP，不重载扩展、重启或部署。

阶段

  • 先补回归，固定“16 个游客位 / 25 人名单”的业务错误码、中文提示和技术详情保留规则。
  • 修改插件错误映射，并同步版本、平台最低版本、mapping、业务登记与发布门槛。
  • 生成版本化 ZIP、更新发布清单并运行规定全量门禁。

错误记录

  • 新回归先按预期红灯，证明旧后台没有容量业务映射；实现后转绿。一次组合门禁因 PATH 只作用于首条命令而未启动后续 Node，改为在受控 shell 内导出 bundled Node PATH 后完整通过。

完成结论

  • passenger_native_target_row_count_not_reached:16:25 及 DOM 同类码现在归并为 erp_passenger_count_limit_exceeded，用户看到“本次名单共 25 人，超过该独立团在 ERP 中最多可录入的 16 人”；原始 blocker 仍在技术详情。
  • 容量失败仍发生在父表单保存前，保持 no_erp_write=true。扩展、平台最低版本和 mapping 已推进到 0.5.156；新 ZIP SHA-256 为 9a0d4941728a49a40a8734c560b4dfcb3f5026756ffb46af3f32f38fbbac652a，旧 0.5.155 ZIP/清单已归档。
  • 门禁通过：仓库治理 9/9、TypeScript、控制面 126/126、legacy 246/246、build、JS/JSON/ZIP 与 diff 检查。未处理历史任务、访问 ERP、重载扩展、重启或部署。

当前任务：名单覆盖确认后始终覆写（已完成）

  • 目标： passenger_list_import 收到 full_replace + confirmed=true 后，不再根据 ERP 当前游客值判定“无变化”；附件中所有指定序号都执行原生覆写和父表单保存，ERP 明确成功即完成。
  • 安全边界： 未确认时，任一目标序号已占用（包括同值）仍要求覆盖确认；继续保留附件/Program-only、唯一对象、结构、游客与领队写前投影及 ERP 明确成功响应门禁。不处理历史任务，不访问 ERP，不重载扩展或重启服务。

阶段

  • 先补失败回归：确认覆盖的同值行必须进入 changed/write 集合；未确认的同值占用行仍要求确认。
  • 修改合并计划、版本和业务契约，确认覆盖不再产生 passenger_import_no_changes。
  • 扩展、平台最低版本和 mapping 推进到 0.5.155；旧 0.5.154 ZIP/清单已归档，新 ZIP 已生成。
  • 运行规定全量门禁并收敛发布 SHA、进度和完成结论。

错误记录

  • 首次补充“未确认同值占用行”回归时，一个多文件补丁因上下文未精确命中而整体未应用；拆成精确小补丁后完成，没有产生部分修改。
  • 首轮 check:repo 发现根 task_plan.md 为 17304 字节，超过 16 KiB。已先完整冻结到 2026-08-28 计划快照，再语义压缩本文件；历史未丢失。

完成结论

  • 合并计划先区分授权而非“值是否相同”：未确认且目标序号已占用时统一要求覆盖确认；full_replace + confirmed=true 后，全部附件指定序号都进入 changed/write 集合，同值也执行 DaoRuDones、写前完整投影和父表单保存。
  • 父表单 ERP 明确成功即完成，仍不执行写后逐行名单回查；其他 lifecycle action 的回查规则未改变。
  • 当前扩展为 0.5.155，ZIP SHA-256 为 3159e6700fcb9aea6d18099c5c84bccf2578de6bceaf3b7e2f369ec44ff66574；0.5.154 ZIP 与清单已日期化归档。
  • 门禁通过：仓库治理 9/9、TypeScript、控制面 125/125、legacy 245/245、build、JS/JSON/ZIP 与 git diff --check。未处理历史任务、访问 ERP、重载扩展、重启或部署。

最近完成：名单明确成功响应终结与 8786 重启

  • passenger_list_import 在全部写前门禁通过后，只调用一次父表单原生保存；ERP 明确成功即生成 passenger_list_explicit_server_success 完成凭据，不执行写后逐行回查或自动名单对账。
  • 控制面只对名单 action 接受上述专用凭据，其他 lifecycle action 仍要求真实 fresh requery。
  • 用户授权后，旧 8786 进程组 13643 已优雅退出；新标准入口进程组 29571、服务 PID 29588 成为唯一监听，live/ready、数据库、Schema、迁移 014 与 4/4 AgentBus 渠道正常。
  • 该次运行态仍是 0.5.154 最低版本；本次 0.5.155 尚未重载扩展或重启服务。

最近有效里程碑

  • 两类名单业务固定为 Program-only：先以文字识别业务并等待单个 .xls/.xlsx，附件到齐后才解析；第一行忽略、第二行固定 14 列表头，规范化为 13 列 canonical TSV。
  • 独立团 16 行、散拼子单 31 行只是初始合并基线，5000 行是技术上限；未指定行保留，已占用目标行需要覆盖确认。
  • 唯一严格领队备注行生成 passenger_list.leader_contact，并在父表单保存前投影到 jj_lianxiren/jj_dianhua；多行、缺姓名/电话或结构不一致均失败关闭。
  • 当前运营模板单一源为 agent设计规范/templates/business-input-templates.md；运营 DOCX、五 Skill 及其发布物保持各自现有基线，本次只改变 Chrome 执行策略。

相邻待处理项

  • AgentBus OSS 附件曾因本机 DNS 返回私网/保留地址而被 SSRF 门禁拒绝；与本次平台手工附件和名单覆写规则独立。后续若处理，应采用受控公有 DNS/主机白名单回退，不能全局放宽私网阻断。

历史与持续边界

  • 本次压缩前完整计划见 2026-08-28 快照；更早快照见同目录 README 和 archive/project-history/，均只供追溯，不定义当前规则。
  • 当前发布版本、文件名和 SHA-256 只以 发布清单 为准。
  • 真实 ERP 写入、任务 mutation、扩展重载、服务重启、部署和外部发送仍需用户另行明确授权。