LWLT-AIBOT/archive/project-history/2026-08-16/progress.pre-governance.md

项目进度（治理前完整快照）

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

• 用户已确认按全仓库范围检查和治理全部文件夹与文件。
• 用户明确要求尊重 Planning with Files 的 task_plan.md、findings.md、progress.md；允许在文件过大时压缩并轮转详细历史。
• 已读取 Planning with Files 完整规范与三个模板，创建本轮 task_plan.md，并记录不覆盖现有未提交改动、不读取秘密、不进入 ERP、不部署的安全边界。
• 当前阶段为全仓库只读发现与分类；尚未移动、归档或删除项目内容。
• 已完成全部活动目录、archive、根文件、引用、构建消费者、版本陈述、重复哈希、规划文件和 DOCX 的审计；无未知目录或秘密内容读取。
• 发现阶段结论：活动源码目录整体健康；需要治理的是时间型文档、无引用手工工具缺少索引、dist 构建/交付混用、三个重复发布副本、滚动规划文件膨胀和 DOCX 多处漂移。
• 阶段 1 已完成，进入项目级 AGENTS.md、README、构建目录和归档迁移规范落地。
• 已新增项目级 AGENTS.md 和 tools/README.md，重写根 README 与 dist README；后续会话已有固定读取顺序、目录 allowlist 和源/制品同步规则。
• 已把 TypeScript outDir、本地 start、Docker、Compose 和控制面运维命令统一迁到 .build/，并加入 Git/Docker ignore；尚未移除旧 dist/control-plane/，待新构建验证后再清理。

2026-08-16 — 0.5.123 独立团 SGL/TWN 房型修改链路

• 复盘用户任务时确认解析已返回 rooms.SGL/rooms.TWN，旧版仅因适配器白名单缺失在 lifecycle_preflight 阻断；本次没有 ERP 写入，no_erp_write=true。
• 已把 rooms.SGL、rooms.TWN 接入独立团 DoInfoJH 的 frenshu0、frenshu1 映射，要求 set 与非负整数，并纳入写前表单快照、原生保存后的 fresh GET 回查和 Agent/插件双层白名单。
• 版本、平台最低插件版本和生命周期 mapping 提升到 0.5.123；更新了“3SGL+2TWN”回归覆盖。插件包与通用别名 SHA-256 均为 e7cf3097cb78ad237f56ff22161fcda2a32d55c8df6e628a1e4818b527cac637。当前仍未执行真实 ERP 保存，新增房型映射待授权实写复测。

2026-08-16 — 项目结构收口

• 已读取当前权威维护规范与交接文件，建立“运行/构建/测试/当前交付引用即保留，历史实现与旧计划可恢复归档”的判定基线。
• 已创建本次临时 task_plan.md 记录审计、归档和验证阶段；任务完成后会将该计划归档，避免根目录再次积累旧计划。
• 已判定 system_operation_scope.md 为明确过期状态文档，adapter_design.md 为已被当前规范取代的历史架构说明；agent设计规范/README.md 仍有效。
• 已初分目录角色：infra/、samples/、reports/、quarantine/ 倾向保留，runtime/ 仅有系统残留，待引用检查后处理。
• 引用审计确认 infra/ 与 samples/ 均有当前消费者，必须保留；两份根目录旧架构文档没有运行/构建/测试依赖。
• 发现生命周期契约测试错误依赖历史 generated/ 产物；后续将先提升所需 C04 为正式 fixture，再整体归档旧回放输出。
• 生命周期目录已划分为“当前入口/模板/合成 fixture”与“2026-08-10 至 12 日历史实跑证据”两层；发布门槛保留在活动目录，原始 live/E2E 输出计划移入项目 archive/evidence/ 并同步链接。
• 已将两项测试从历史 E2E3 实跑文件解耦：split-probe recorder 使用内联合成契约状态，runner 防篡改测试现场构造标准 operation；尚待用工作区 Node 运行时验证。
• 使用工作区 Node 运行时执行定向回归，生命周期与 split-probe recorder 共 43/43 通过；历史生成目录已经没有代码测试依赖。
• 已确定可恢复归档映射：旧架构文档归入 2026-07-07 研究档；同一生命周期验证活动的 live/E2E 原始资料归入 2026-08-12 证据档；当前发布门槛、能力矩阵、风险和稳定 fixture 保留。
• 已完成可恢复移动并更新主要引用：根目录旧架构文档进入研究档，31 个历史生命周期文件和约 12 MB generated/ 输出进入统一证据档；仅含 .DS_Store 的旧 runtime/ 残留已通过 macOS 废纸篓移出项目。
• 二次制品/fixture 审计确认当前插件已为 0.5.123；已识别 dist/ 中残留的 0.5.122 包和仅供旧版本断言使用的历史 run-manifest.json，准备归档并保持 0.5.118 五个 Skill/DOCX 不动。
• 0.5.122 插件包与历史 run-manifest.json 已分别进入发布归档和生命周期证据归档；dist/ 现符合“只保留当前交付物”的规则。
• 已将项目活动目录中的 5 个 .DS_Store 通过 macOS 废纸篓移出；隐藏的系统元数据不再混在源码、Skill 与交付目录。最终复核时废纸篓已不再保留这些纯元数据文件。
• 活动文档链接扫描已运行，发现 10 个指向已移除 erp-handoff.md 的既有断链；正在映射到当前新下单 Skill reference。
• 已按当前 parse-only 分层修复这 10 个断链：业务登记表的 ERP 流程改指对应一页式入口，业务页不再声称 Skill 内维护 ERP handoff。
• 定向生命周期回归再次 43/43 通过，活动 Markdown 已无断链；归档扫描发现遗漏的 live-inputs/ 与少量冻结日志旧路径，继续收口。
• 当前 0.5.123 版本包与通用别名字节一致，稳定 SHA-256 为 e7cf3097cb78ad237f56ff22161fcda2a32d55c8df6e628a1e4818b527cac637，HANDOFF 已同步；继续核验包内文件与源码。
• 已将遗漏的 9 个专项 live-inputs/ 一并移入生命周期证据归档，并修正冻结规划/研究日志迁移后失效的相对链接。
• 0.5.123 插件包已通过 18 文件名集合、逐文件字节、ZIP 完整性及版本包/别名字节一致性核验，确认与当前扩展源码完全一致。
• 已修正全项目扫描最后发现的冻结日志旧相对路径，等待一次全量链接复扫确认归零。
• 全项目 107 个 Markdown 文件的本地链接复扫全部通过；TypeScript no-emit、控制面 37/37、插件/解析/生命周期与工具全量回归 189/189 通过。
• 正式 TypeScript 构建通过；当前 0.5.123 插件源码/版本包/别名逐文件一致，项目与桌面根目录均无第二份当前交付物，dist/ 是唯一活动来源。
• 当前制品哈希均与 HANDOFF 一致；Skill 逐文件审计仅发现 updating 包的 references/operation-contract.md 与项目源码不一致，正在核对该单文件差异。
• 已按 parse-only 边界恢复该单行源码；五个 Skill 与五个 0.5.118 包现逐文件完全一致，安全扫描无凭据命中。quick_validate.py 首次因缺少 PyYAML 模块未启动校验，正在改用本机已有依赖重跑。
• 使用系统已有 PyYAML 重跑成功，五个当前 Skill 均通过 quick_validate.py；未安装新依赖、未改变 0.5.118 包或其哈希。
• 最终复跑通过：业务/插件/解析/生命周期 189/189，107 个 Markdown 本地链接与 git diff --check 全部通过；临时任务计划归档后，项目根目录不再保留本次过程文件。

2026-08-15 — 0.5.122 独立团人数目标字段映射

• 已把 order_update_independent 的 pax.adult、pax.child_bed、pax.leader 分别映射到 ERP 独立团编辑页 darenshu、xiaorenshu、quanrenshu；仅允许非负整数 set，并纳入保存后新表单回查。
• 插件、平台最低版本、生命周期 mapping 与静态回归断言统一升至 0.5.122；五个 Skill 与 DOCX 继续维持 0.5.118，本轮不需要重新打包 Skill。
• 定向生命周期测试 40/40、控制面 37/37、插件/解析/生命周期全量 189/189 均通过；变更 JS 语法、git diff --check、ZIP 完整性和项目内包字节一致性通过。0.5.122 当前只保留在项目 dist/，SHA-256 为 29467fb563ddbea18f9cf0a145a7d145f099b08f1b520f04dba7a0c50833cd0b；桌面副本已移入历史归档。Chrome 当前仍需从 0.5.121 重载到 0.5.122；本轮没有真实 ERP 写入。

2026-08-15 — 0.5.121 客户分词检索修复

• 复盘 19:34 任务 TASK-20260815113444-NGus_A8：客户、日期、选填产品和人数目标均已正确解析，但正式客户名包含插入词，ERP S_kehuming 连续硬匹配返回 0；任务在只读解析阶段停止，no_erp_write=true。
• 插件新增中文分词模糊匹配与客户硬筛零结果日期回退：客户 + 日期仍是独立团主定位；客户原生检索无结果时仅清空客户控件、保留日期检索，再以客户分词、产品和领队做候选补充校验。产品/领队仍是选填。
• 插件、平台最低版本、生命周期 mapping 与回归断言升至 0.5.121；五个 Skill 与 DOCX 本轮不变，继续使用 0.5.118。
• 当前包为 dist/ltjt-order-assistant-0.5.121.zip、通用别名 dist/ltjt-order-assistant.zip 和桌面 /Users/inmanx/Desktop/ltjt-order-assistant-0.5.121.zip，三者 SHA-256 均为 d0ab05fa00fd3ad36494c2bdd543818e3b384ad50e1b0f2b9ab618211eb906ab；0.5.120 已可恢复地移入项目及桌面历史归档。
• 工程校验：生命周期定向 40/40、控制面 37/37、插件/解析/生命周期全量 189/189，TypeScript、语法、git diff --check、ZIP 完整性和桌面/dist/ 字节一致性均通过；Chrome 当前仍待将 0.5.120 重载为 0.5.121。
• 本轮只读分析和代码验证没有进入 ERP 保存；须在 Chrome 重载 0.5.121 后用新任务复测，确认该正式客户的候选命中及后续人工复核边界。

2026-08-15 — 0.5.120 独立团列表行兼容修复

• 复盘 19:04 新任务 TASK-20260815110408-r0aPAGk：解析和业务主检索参数均已正确（客户 + 日期，产品未进入原生硬筛选），但 ERP 仍返回候选数 0，未写入 ERP。此前 0.5.119 的问题已排除。
• 结合 ERP 历史原生响应结构，补强独立团候选行识别：支持把行级 onclick/ondblclick=OPEN_update(...) 当作原生更新引用，并在外层行包含嵌套表格时保留携带团号/更新动作的行，避免 leafLifecycleRows 误删全部候选。
• 插件、平台最低版本、生命周期 mapping 与回归断言升至 0.5.120；新增独立团行级更新动作回归。五个 Skill 与 DOCX 本轮仍不变，继续使用 0.5.118。
• 当前包为 dist/ltjt-order-assistant-0.5.120.zip、通用别名 dist/ltjt-order-assistant.zip 和桌面 /Users/inmanx/Desktop/ltjt-order-assistant-0.5.120.zip，三者 SHA-256 均为 fc49d099ab9a7c69eadde2ebf86b100c1ee876920c3ded5382e824ba955957aa；0.5.119 已可恢复地移入项目及桌面历史归档。
• 工程校验：生命周期定向 39/39、控制面 37/37、插件/解析/生命周期全量 188/188，TypeScript、语法、git diff --check、ZIP 完整性和桌面/dist/ 字节一致性均通过；Chrome 当前心跳仍为 0.5.119，尚待重载 0.5.120。
• 本轮只读分析和代码验证没有进入 ERP 保存；待重载 0.5.120 后用新任务复测，确认实际候选行和后续人数字段人工复核边界。

2026-08-15 — 0.5.119 无编号生命周期补充筛选修复

• 复盘 18:40 任务：最新解析契约已正确返回独立团信息修改及 pax.adult=8、pax.child_bed=1、pax.leader=1 三个目标；插件随后把选填产品名称送入 ERP 原生订单列表硬筛选，造成 erp_resolution_candidate_count:0。任务在只读对象解析阶段停止，no_erp_write=true，没有写入 ERP。
• 插件现统一按业务路线区分“原生主检索”和“候选补充校验”：独立团以预订客户 + 出发日期原生检索，产品/领队只在候选行上校验；散拼母团计划修改以日期为主条件；散拼子单、新增、名单、修改、取消/恢复和导出继续按母团/嵌套子单层级校验，避免把子单字段误送到母团列表。
• 插件、平台最低版本与回归断言升至 0.5.119。当前包为 dist/ltjt-order-assistant-0.5.119.zip、通用别名 dist/ltjt-order-assistant.zip 和桌面 /Users/inmanx/Desktop/ltjt-order-assistant-0.5.119.zip，三者 SHA-256 均为 624ddf7809cb6e26bc4838e8c9360187d2235525fc4dd5963e6251c32d9c455a；旧 0.5.118 插件已可恢复地移入项目及桌面历史归档。
• 五个 Skill 与 DOCX 本轮无需变更，继续使用统一的 0.5.118 交付物。业务模板源码与 dist/ltjt-business-instruction-examples.md 保持字节一致。
• 生命周期定向回归 38/38、控制面 37/37、插件/解析/生命周期全量回归 187/187、插件 ZIP 完整性和版本一致性均通过。Chrome 扩展已重载，平台心跳返回 0.5.119、ERP 会话在线；没有自动重放失败任务，也没有执行真实 ERP 保存。

2026-08-15 — 0.5.118 项目交付物统一与归档

• 项目 dist/ 已与桌面交付物同步：保留插件 ltjt-order-assistant-0.5.118.zip、通用别名 ltjt-order-assistant.zip、五个 lwlt-*.skill 的 0.5.118 包和 老挝联泰AI指令表-0.5.118.docx；lwlt-updating-0.5.118.skill 已校正为与桌面包字节一致。
• dist/ 中的旧插件/Skill 包没有删除，已按类型移入 archive/releases/2026-08-15/插件/ 与 archive/releases/2026-08-15/Skill/，项目内可追溯恢复。
• dist/README.md、业务模板、发布示例和 HANDOFF.md 已更新为 0.5.118；主提示词/生命周期契约当前分别为 ltjt-agent-prompt-v1.4-updating-wide-parse / ltjt-lifecycle-v2.8-updating-wide-parse-2026-08。本轮未修改云端 Agent Profile，也未进入 ERP。
• 校验通过：pnpm run check、控制面 37/37、插件/解析/生命周期回归 187/187、git diff --check、所有当前 .zip/.skill 完整性、桌面与 dist/ 当前制品字节一致性，以及 Skill 包与源码逐文件一致性。
• 解析契约补丁：schemas/agent_operation.schema.json 的 updates.actions 上限由旧的 1 调整为 32，并增加“人数改为 8+1（占）+1”拆成成人/占床儿童/领队三个目标的 Schema 回归；本次日志显示未进入插件或 ERP，外部 Profile 仍需使用项目内最新契约。
• 本地解析适配器已用当前源码重载到 http://127.0.0.1:8765/，/api/status 确认解析服务已配置且可连接；随后用用户原始“人数改为 8+1（占）+1”指令创建全新解析会话实测通过，返回 ltjt-agent-prompt-v1.4-updating-wide-parse，并保留 pax.adult、pax.child_bed、pax.leader 三个目标；未进入插件或 ERP 写入。
• 18:32 新任务仍出现旧 twin_room_count 白名单，进一步确认并非云端 Skill 或会话复用，而是 8786 控制面自 14:44 起未重启，启动时已把旧版 external-agent-client.mjs 缓存在内存；单独重载 8765 不会更新控制面的内置解析 Worker。18:35 已重启控制面，新进程加载当前源码，数据库、AI 和 AgentBus 健康检查均通过。

2026-08-15 — 0.5.117 追加散拼子单订房说明定位修复

• 复盘任务 TASK-20260815074716-yFEQYqw：客户筛选已在 0.5.116 清空，但散拼子单修改仍把产品和领队送入母团计划列表原生筛选，导致 erp_resolution_candidate_count:0；没有写入 ERP。
• 所有无编号散拼子单定位现在统一按客户 + 出发日期处理：母团计划列表不发送客户、产品、领队硬筛选，候选行/嵌套子单行再做可见信息补充校验；带完整子单号的精确路径保持不变。独立团和散拼母团安排路径不变。
• 插件、平台最低版本与回归断言升至 0.5.117；桌面插件包 /Users/inmanx/Desktop/ltjt-order-assistant-0.5.117.zip，SHA-256：b5cddcfbf153c124b07d4d63bec377e55938c5af1d1f655f0dd84b61967d5367。本轮没有修改 Skill 或 DOCX 内容。
• 生命周期定向回归 38/38、控制面 37/37、全量回归 186/186、TypeScript/JS 语法、git diff --check 和插件 ZIP 完整性均通过。Chrome 扩展已重载，平台 PING 返回 0.5.117、ERP 会话在线；没有重放失败任务或执行真实 ERP 保存。

2026-08-15 — 0.5.116 散拼子单名单母团客户筛选修复

• 复盘任务 TASK-20260815073226-hAwHl9E：产品/领队已正确不进入 ERP 原生硬筛选，但名单目标是 shared_child_order 时仍把子单预订客户 衡阳国旅广东 送入母团计划列表的 S_kehuming。母团本身没有预订客户字段，ERP 返回 erp_resolution_candidate_count:0；没有写入 ERP。
• 插件现在按目标类型处理：散拼子单名单先以出发日期（或团号）检索母团计划，客户在嵌套子单行上做匹配；独立团仍保留客户原生筛选，安排类和其他业务路径不变。产品/领队继续只做可见候选的补充校验。
• 插件、平台最低版本与回归断言升至 0.5.116；桌面插件包 /Users/inmanx/Desktop/ltjt-order-assistant-0.5.116.zip，SHA-256：d45b9a60850680d9f66b63e61741c46763fa1549146179a4facc684140666ab3。本轮没有修改 Skill 或 DOCX 内容。
• 生命周期定向回归 38/38、插件 JS 语法与 git diff --check 通过；Chrome 扩展管理页已重载，平台 PING 返回插件 0.5.116、ERP 会话在线、自动化已启用。没有重放失败名单，也没有执行真实 ERP 保存。

2026-08-15 — 0.5.115 名单导入主条件与补充校验修复

• 复盘任务 TASK-20260815065347-rnSsZUw：解析结果已经包含预订客户、出发日期、产品名称和领队，但插件把后两项一并送入 ERP 散拼计划列表硬筛选，导致 erp_resolution_candidate_count:0；本次没有写入 ERP。
• 名单导入的无团号定位现明确以“预订客户 + 出发日期”为 ERP 原生主检索条件；产品名称和领队均为可选补充校验，不再作为列表硬筛选。候选行可见这些信息时按匹配度收窄；ERP 嵌套行不显示时保留主检索候选，避免把可选字段误判成 0 条。日期仍是必填主条件。
• 插件、平台最低版本与回归断言升至 0.5.115；桌面插件包 /Users/inmanx/Desktop/ltjt-order-assistant-0.5.115.zip，SHA-256：f1ace36b91686bfbcade53e6368da1436dc791add94b1e364c74e688d9447b3a。生命周期 Skill 包 /Users/inmanx/Desktop/lwlt-lifecycle-0.5.115.skill，SHA-256：0c472cf59e25060c93f1f9bad7dd209454f251c7cd7556b04351a8bb01463d98。
• 已同步生命周期 Skill、输入契约、业务模板、发布示例、行为登记、发布门槛和桌面 DOCX；DOCX /Users/inmanx/Desktop/老挝联泰AI指令表.docx 已重新渲染 10 页并复核，SHA-256：a391f59b28492d2f3f124c78a199717461b775650ca399ad2197fc4fd9b6516c。
• pnpm run check、控制面 37/37、全量回归 186/186、插件/平台 JS 语法、git diff --check、Skill/插件 ZIP 完整性及模板回归均通过。Chrome 扩展管理页已重载，平台 PING 返回插件 0.5.115、ERP 会话在线、自动化已启用；没有执行真实 ERP 保存。

2026-08-15 — 0.5.114 客户来源地联合匹配修复

• 复盘“导入散拼子单名单”链路：名单解析正常，但前置散拼子单因客户关键字 衡阳国旅 命中多个 ERP 客户主数据而在写入前阻断；名单任务本身未写入 ERP。
• 新增“客户关键字 + 已选产品来源地”联合筛选：产品来源地关键字全部命中且客户关键字仍只剩一个候选时自动选择；零个或多个候选继续失败关闭，不默认猜选。已覆盖产品 广东直飞行程--衡阳（晚航班） 唯一落到客户主数据 id 661 的回归。
• 插件版本升至 0.5.114；桌面插件包 /Users/inmanx/Desktop/ltjt-order-assistant-0.5.114-客户来源联合匹配修复.zip，SHA-256：790576dd2a9600d33bc2c4542ee64d6f0ddadfda7c7cda88a0e20abec1bdc123。五个 Skill 内容未变，继续使用桌面 0.5.113 包；DOCX 仅同步标题/元数据到 0.5.114。
• pnpm run check、控制面 37/37、全量回归 185/185、插件/平台 JS 语法检查、git diff --check 和插件 ZIP 完整性检查通过；控制面重载后健康状态正常。
• Chrome 扩展管理页已重载实际扩展 ID kafggjjlhebccdgkechmbgflkaifkccf，平台 PING 返回插件版本 0.5.114，ERP 会话在线；没有自动重试名单导入，也没有真实 ERP 保存。

2026-08-15 — 0.5.113 散拼子单领队严格门禁修复

• 日志任务 417dafd3-a98e-40b2-b723-84466ced7363 的解析结果正确，包含客户、日期、产品、领队和人数；插件执行前严格门禁因 operation.data 白名单遗漏 leader 阻断，no_erp_write=true，没有写入 ERP。
• 已将 leader 补入插件 DATA_KEYS、平台 STANDARD_DATA_KEYS/公共字段校验和 schemas/standard_system_operation.schema.json；新增散拼子单领队通过严格执行门禁的回归测试。母团仍只用客户/日期/产品定位，领队继续在子单接送信息原生 SelectBox 中匹配并默认第一条。
• 统一发布号升至 0.5.113：插件 /Users/inmanx/Desktop/ltjt-order-assistant-0.5.113-领队严格白名单修复.zip，SHA-256：86cb518cc6be1509df1052e3704cf6f8a95484f214a6d81f040e21a0fd522d80。
• 五个 Skill 包已同步生成：lwlt-arrangement aa180c527cb6ac51763f710ef79f475ca0a0f79f71eebdb74cc018b8ec9a8c92、lwlt-confirmation a0bda2922dda6316aa6e8a21335b2539021b9e7e756645c6be8ba9d7eda8d515、lwlt-lifecycle f5115167e2d7677126f91e820a600d4780fd17743b3e0bf418534b2b693adabf、lwlt-newbooking cfa4c6c081d5843b98db949214c18ae492a13c1a47ca19258fc5d75e611a9f95、lwlt-updating 913f532ced308230c6c821f53c5586ca98d14733732fe3ac38cc739ca4f6b148。
• 桌面 DOCX 标题和核心属性已同步为 0.5.113，重新渲染 10 页并复核通过；SHA-256：1142f40c6406a8ad4e25e133e9244beabb289a23f73bef3f5bd5e0c08b9b8563。
• pnpm run check、控制面 37/37、全量回归 183/183、JS 语法检查、git diff --check 和所有 .zip/.skill 完整性检查通过。控制面已重启，/api/status 显示数据库、AI 和 AgentBus 均就绪；Chrome 插件已重载，平台 PING 返回插件版本 0.5.113，ERP 仅确认会话在线，未执行真实保存。

2026-08-15 — 0.5.112 统一发布号

• 修正版本管理：插件此前为 0.5.109，部分 Skill 已为 0.5.111；本轮统一递增到 0.5.112。插件 manifest、inpage、批量下单 inpage、平台最低版本和回归断言全部一致。
• 重新生成插件包：/Users/inmanx/Desktop/ltjt-order-assistant-0.5.112-统一版本发布.zip，SHA-256：c00d55cbd8c8db4f3517b959b3cf225c6a0a14cf090021b9b6e755f09864b15c。
• 重新生成五个 Skill 包：lwlt-arrangement aa180c527cb6ac51763f710ef79f475ca0a0f79f71eebdb74cc018b8ec9a8c92、lwlt-confirmation a0bda2922dda6316aa6e8a21335b2539021b9e7e756645c6be8ba9d7eda8d515、lwlt-lifecycle f5115167e2d7677126f91e820a600d4780fd17743b3e0bf418534b2b693adabf、lwlt-newbooking cfa4c6c081d5843b98db949214c18ae492a13c1a47ca19258fc5d75e611a9f95、lwlt-updating 913f532ced308230c6c821f53c5586ca98d14733732fe3ac38cc739ca4f6b148。
• 桌面 DOCX 标题与核心属性同步为 0.5.112，重新渲染 10 页并检查通过；SHA-256：58d32b5347c7e991f16706b75680a96471d204f14bd9927c213363ebd978537d。
• 所有 ZIP/SKILL 包均通过完整性校验；未进入 ERP、未写入真实业务数据。

2026-08-15 — 0.5.109 散拼子单领队定位修复

• 复盘任务 4d0080c7-b9cb-4dff-9be0-d6c22e29cfee：Agent 已正确解析客户、日期、产品、领队和人数，失败发生在插件只读母团检索，因把子单领队错误带入母团列表 S_youkexinxi，ERP 返回 0 条；没有发起 ERP 写入。
• 实际 ERP 研究确认：日期 + 产品可以命中母团；领队属于子单“接团地点/标志”原生 SelectBox，映射 jj_didian、jj_lianxiren、jj_dianhua。插件现移除散拼子单的母团领队过滤，保留领队到子单页，按组合候选匹配并默认第一条，通过 SetValToObj 联动写入三个字段；领队未提供时跳过。
• 已同步 lwlt-newbooking Skill、业务模板/示例、发布 Markdown 和桌面 DOCX；DOCX 重新渲染 10 页并逐页检查通过。
• 插件版本升至 0.5.109；桌面包：/Users/inmanx/Desktop/ltjt-order-assistant-0.5.109-散拼子单领队定位修复.zip，SHA-256：14ff77206ad98c8d4e31ead437b8b75b317fa156b724da3e93944a2f127e82d8。
• 新增 Skill 包：/Users/inmanx/Desktop/lwlt-newbooking-0.5.109.skill，SHA-256：cfa4c6c081d5843b98db949214c18ae492a13c1a47ca19258fc5d75e611a9f95。check、控制面 37/37、插件/解析/生命周期 182/182、语法检查和 ZIP 完整性通过；未提交真实 ERP 保存。

2026-08-15 — 外部 Agent 命名引用契约提示修复

• 日志确认外部 Agent 首轮及同会话修复轮次都把 operation.data.customer 输出为字符串，宿主按契约安全阻断，未进入插件、未写入 ERP。
• 平台解析消息已显式要求 customer、product、leader、resource、supplier 等命名引用统一返回 {name, keyword} 对象，禁止字符串或数组；主提示词发布副本同步，新增回归断言。
• check、控制面 37/37、插件/解析/生命周期 181/181、正式构建通过；插件执行逻辑和版本未改动。

2026-08-15 — 0.5.108 散拼母团计划客户可选与领队字段映射修复

• order_update_shared_plan 在无团号时改为只要求单个出发日期；预订客户允许缺省，产品名称和领队继续作为选填缩小条件。独立团/散拼子单、名单、取消/恢复和导出原有客户+日期定位不变，安排类仍要求团号。
• 计划列表的 leader 已明确映射 ERP S_youkexinxi（接团/接送地点/标志）；订单列表仍映射 S_lingdui。名单导入适配器核对结果：只写游客行并保护接送电话，领队在该流程中只是可选检索条件，没有误写联系人/电话。
• 已同步解析 Schema、平台与插件前门禁、生命周期解析路由、更新/生命周期 Skill、业务模板、Markdown 发布示例、桌面 DOCX；DOCX 重新渲染并检查 10 页通过。
• 插件版本升至 0.5.108；桌面包：/Users/inmanx/Desktop/ltjt-order-assistant-0.5.108-散拼母团客户可选修复.zip，SHA-256：768dc486cea685dab52baa47158390eccf37011a1170772e891fd2a492d00e59。
• 更新 Skill 版本包 0.5.111：/Users/inmanx/Desktop/lwlt-updating-0.5.111.skill（c7b27ebe9c527367eb673981d2bf6305e4c771d9ff2711b74108b2cfe5f117aa）、/Users/inmanx/Desktop/lwlt-lifecycle-0.5.111.skill（7bffd7b0f81eeda46f87e3a2bd6f4a173b8a796d90614fb73dc08fd04ada3f6c）。未进入 ERP、未写入真实业务数据。

2026-08-15 — Skill 保留兼容字段，用户示例继续精简

• 按适配要求，Skill 内部输入契约恢复大交通 车票/控位说明、其他/备案 项目 的完整模板与兼容示例，解析时可识别用户主动提供的字段，但仍不把它们作为匹配条件或必填项。
• 对外业务模板、发布示例和桌面 DOCX 继续隐藏这两个 ERP 自动联动字段，避免用户误以为需要记忆或填写。
• 新 Skill 包：dist/lwlt-arrangement-0.5.110.skill、桌面 /Users/inmanx/Desktop/lwlt-arrangement-0.5.110.skill（别名同步更新）；SHA-256：b9920152208906b5417c9bce0b89f4fc8a011718ba58403d8f6403efbfa905a0。插件执行逻辑未改动，版本仍为 0.5.107。

2026-08-15 — 隐藏自动联动的选填字段

• 对外指令模板和示例不再展示大交通的“车票/控位说明”以及其他/备案的“项目”字段；两者仍保留在内部契约中作为 ERP 联动回填和旧输入兼容字段。用户可继续填写备注、备案号、口岸等真正由用户提供的选填字段。
• 已同步 agent设计规范/skills/lwlt-arrangement/references/input-contract.md、业务模板、发布示例和桌面 DOCX；桌面 DOCX 完成 10 页渲染复核。
• 新 Skill 包：dist/lwlt-arrangement-0.5.109.skill、桌面 /Users/inmanx/Desktop/lwlt-arrangement-0.5.109.skill（别名同步更新）；SHA-256：dfde1c0fc74d441e06ed4f162e33defcdaebd7a258c3de197ff6c14243f619e4。桌面 DOCX SHA-256：0bd32686a22ad49595ae6762e68ce68d450e0a3f3ddcda9c0f0427f8b6d4b406。
• 插件执行逻辑没有改动，版本仍为 0.5.107。

2026-08-14 — 解析层拦截安排其他/备案陈旧必填追问

• 日志确认外部 Agent 在安排其他/备案缺少项目说明时返回 agent_parse_needs_input，而当前业务契约已明确项目/备案说明和数量均可由后续联动或系统默认值补全；本次未进入插件，也未写入 ERP。
• 主提示词升级为 ltjt-agent-prompt-v1.3-arrangement-other-optional，每条安排其他/备案请求显式强调 item、quantity 可省略；平台在检测到旧 Profile 仅追问这些选填字段时，将其转为契约修复提示，不再把错误追问展示给用户。
• 已同步安排 Skill、输入契约、业务模板、解析示例和发布门槛说明；插件执行逻辑没有改动，当前插件版本仍为 0.5.107。
• 新 Skill 包：dist/lwlt-arrangement-0.5.108.skill、桌面 /Users/inmanx/Desktop/lwlt-arrangement-0.5.108.skill（别名同步更新）；SHA-256：e5ef21001404706355ff709ae9daaecf622a1b371432473d3ddea3bc35830701。桌面 DOCX 已同步陈旧模板说明并完成 10 页渲染复核，SHA-256：2662ca9d1277ab63686bb669fb7db396f8dfa723d527509777b1a3474cba7de3。

2026-08-14 — 0.5.107 其他/备案统一选择框原生联动与可选数量

• 根据 ERP“安排其他/备案”页面字段行为收敛新增输入：团号、业务日期、结算单位搜索词和可选数量，项目/备案说明由结算单位候选行自动带入；备注、备案字段继续按用户明确输入处理。
• 其他/备案与大交通共用结算单位统一选择框的组合候选匹配，忽略分隔符并支持不连续关键词；多条候选按 ERP 下拉顺序默认第一条，再调用原生 SelectBox.SetValToObj 带入项目/备案说明及其他联动字段。数量省略时保留 ERP 默认值，填写时才覆盖。
• 已同步安排 Skill、解析/执行 Schema、平台与插件门禁、业务模板、Markdown 示例、桌面 DOCX 和回归断言；插件及平台最低版本升至 0.5.107。本轮只读使用已保存的 ERP 页面研究证据，未写入真实业务数据。
• pnpm run check、控制面 37/37、插件/解析/生命周期 177/177、正式构建和变更检查通过。
• 新包：dist/ltjt-order-assistant-0.5.107.zip、桌面 /Users/inmanx/Desktop/ltjt-order-assistant-0.5.107-其他备案原生联动修复.zip；插件 SHA-256：4e205a118be999e0f0f92d31d97985f152957e26be3454c46bdf9c9e7a89532a。
• 安排 Skill：/Users/inmanx/Desktop/lwlt-arrangement-0.5.107.skill（别名 /Users/inmanx/Desktop/lwlt-arrangement.skill）；SHA-256：03fe00c766e041fe5ff32e7e21294e11db837ce2b254e2d5ca307373ba23bf84。桌面 DOCX SHA-256：a5f5904c6d6c156c5616ea18508bdf22de141f9092f6755920980d435ebc5ff3。

2026-08-14 — 0.5.106 大交通统一选择框首条匹配与车票说明联动

• 根据大交通原生页面字段行为收敛新增输入：团号、交通日期、结算单位搜索词、数量和至多一个备注；车票/控位说明为选填兼容字段，由结算单位候选行自动带入。
• 大交通结算单位按统一选择框的组合候选文本匹配，忽略分隔符并支持不连续关键词；同一结算单位多条候选按下拉顺序默认第一条，不直接写车票说明栏。
• 执行层调用原生 SelectBox.SetValToObj 选择大交通结算单位行，由系统带入车票/控位说明、币种、单价、结算方式等联动字段；Skill、解析/执行契约、模板、Markdown 示例、README、桌面 DOCX 与回归断言同步。
• 插件、平台最低版本升至 0.5.106；本轮只读使用项目保存的业务页面研究证据，未写入真实业务数据。pnpm run check、控制面 37/37、插件/解析/生命周期 177/177、正式构建通过。
• 新包：dist/ltjt-order-assistant-0.5.106.zip、桌面 /Users/inmanx/Desktop/ltjt-order-assistant-0.5.106-大交通原生联动修复.zip；插件 SHA-256：0a89586ad4d979fed783a25248b7142df4b236a10e24244b9c89e651e9c090b6。
• 安排 Skill：/Users/inmanx/Desktop/lwlt-arrangement-0.5.106.skill（别名 /Users/inmanx/Desktop/lwlt-arrangement.skill）；SHA-256：52bdf61693141c61281a4b1cb9b57c52d5d8d8762ec05893e8f90cb186b0785d。桌面 DOCX SHA-256：111bdeb09653881b62787b8719d711dfaf6df380d211767bc61208fb64d86bad。

2026-08-14 — 0.5.105 酒店统一 SelectBox 首条匹配与原生联动

• 根据 ERP 字段实际行为收敛酒店新增：用户只提供入住日期、离店日期、酒店搜索词、间数和备注，不填写房型；酒店栏候选是酒店名、房型及联动文字的组合显示项，房型输入框只读。
• 酒店搜索改为在组合候选上做去分隔符、可不连续的匹配；同一酒店多条候选不再追问，按 ERP 下拉顺序默认第一条。
• 执行层调用 ERP 原生 SelectBox.SetValToObj 选择酒店行，由 ERP 自动带入房型、酒店 ID、地区、电话、币种、价格和结算方式等联动字段；不直接写房型栏。
• 安排 Skill、模板、Markdown 示例、插件 README、桌面 DOCX 与回归断言同步；插件、平台最低版本升至 0.5.105。未写入真实 ERP 业务数据。
• 新包：dist/ltjt-order-assistant-0.5.105.zip、桌面 /Users/inmanx/Desktop/ltjt-order-assistant-0.5.105-酒店栏原生首条匹配.zip；插件 SHA-256：a1cd85309dbe33a6435f64e56ee7f2e6c97d3ad76bedd0f0173212b7938c976b。
• 安排 Skill：/Users/inmanx/Desktop/lwlt-arrangement-0.5.105.skill（别名 /Users/inmanx/Desktop/lwlt-arrangement.skill）；SHA-256：28f2aa2ebfe35199534c44f39f2b895219dba316624d3ae71d1cde04107a7547。

2026-08-14 — 0.5.104 酒店非连续关键字与房型派生修复

• 根因确认：ERP 酒店候选的酒店名和房型是两列，房型由选择酒店行后的原生联动填写；不能把 酒店名TWN 当成一段连续文本，也不能要求用户记忆 TWN。
• 酒店候选解析现在只匹配酒店列，统一去除空格、标点和括号；旧输入末尾带 TWN/DBL/SGL/TRP/HNM/TL 时仅兼容性剥离，不再用房型列筛选。酒店名对应多条房型行时继续阻断，不默认猜选；唯一行的房型由候选联动结果带入。
• 已同步安排 Skill、业务模板、Markdown 示例和桌面 DOCX；插件、平台最低版本和回归断言升至 0.5.104。
• 控制面 37/37、插件/解析/生命周期 177/177 通过，TypeScript 检查和正式构建通过；插件 ZIP 和 Skill ZIP 均通过逐文件解压校验。本轮没有进入 ERP，也没有写入业务数据。
• 新包：dist/ltjt-order-assistant-0.5.104.zip、桌面 /Users/inmanx/Desktop/ltjt-order-assistant-0.5.104-酒店列匹配修复.zip；插件 SHA-256：3da18c909cbc02c7f399ee03b4019462f88f21c00059b7d240eea4a37e114a93。
• 安排 Skill：/Users/inmanx/Desktop/lwlt-arrangement-0.5.104.skill（别名 /Users/inmanx/Desktop/lwlt-arrangement.skill）；SHA-256：cea55f5fda0670a62e31a8d1f39be5c5cfe60b42b191ed749158ebfbdb7a1563。
• 桌面 /Users/inmanx/Desktop/老挝联泰AI指令表.docx 已同步酒店示例并完成 10 页渲染复核。

2026-08-14 — 0.5.103 安排酒店候选过宽匹配修复

• 日志显示组合搜索已不再是零候选，但独立 TWN 词把结果扩大为 87 条；本轮仍在 ERP 保存边界前阻断，未写入。
• 唯一候选解析改为按每个搜索词分别评分，优先候选数最小、搜索词更具体的结果；完整酒店+房型词唯一命中时，不再被短房型词污染。
• 增加“完整组合词唯一、独立 TWN 多候选”的回归测试；插件和平台最低版本升至 0.5.103。
• 新包：dist/ltjt-order-assistant-0.5.103.zip、桌面 /Users/inmanx/Desktop/ltjt-order-assistant-0.5.103-酒店候选过宽修复.zip；插件 SHA-256：60d3c512d30fe9b1cefca8e698d3cf5223a5b286e7318b23037b4b1bc3124821。

2026-08-14 — 0.5.102 安排酒店组合搜索匹配修复

• 日志确认酒店安排在 lifecycle_route_preparation 阶段阻断，原因为 arrangement_resource_candidate_count:0；未进入 ERP 写入。
• 根因是酒店输入可把酒店名和房型标记合并为一个搜索词（如 万荣龙吟阁TWN），插件只逐格匹配酒店名/房型，未匹配 ERP 下拉项的组合文本。
• 组合搜索现在同时匹配各单元格和紧凑组合键，并对 ERP 常见房型括号（如 【TWN】）做搜索归一化；唯一候选后继续由 ERP 行带入房型和联动字段。
• 新增组合搜索回归测试，插件版本与平台最低版本升至 0.5.102；本轮未进入 ERP 或写入业务数据。
• 新包：dist/ltjt-order-assistant-0.5.102.zip、桌面 /Users/inmanx/Desktop/ltjt-order-assistant-0.5.102-酒店组合搜索修复.zip；插件 SHA-256：1f1d337b77f4177e6f91166bf6e090251ee4f780bd4aed403ce4c0344dd6ddb1。

2026-08-14 — 0.5.101 安排酒店房型联动与未安排状态修复

• 按 ERP 原生酒店页收敛输入为团号、入住日期、离店日期、酒店模糊搜索词、间数和至多一个备注；不再要求用户填写房型。
• 酒店搜索词支持把酒店名与房型关键词一起交给原生候选匹配；唯一候选后由 ERP/插件带入房型及联动字段，新增状态固定为“未安排”，旧未确认酒店行 update/clear 继续兼容。
• 已同步安排 Skill、统一业务模板与 markdown 示例、Agent/执行 Schema、平台/插件门禁、生命周期状态校验，并将插件版本升至 0.5.101。
• 本轮未进入 ERP 或写入业务数据；定向回归与全量 177/177 通过，TypeScript 检查/正式构建通过，Skill/插件 ZIP 可解压校验，桌面 DOCX 已完成 10 页渲染复核。
• 新包：dist/ltjt-order-assistant-0.5.101.zip、桌面 /Users/inmanx/Desktop/ltjt-order-assistant-0.5.101-安排酒店字段修复.zip；插件 SHA-256：3995cd84982b04edebb48b9e6040a7c9c7ed8c17ace3f1bc7e8b4d0cac19ecd0。
• 安排 Skill：/Users/inmanx/Desktop/lwlt-arrangement-0.5.101.skill（别名 /Users/inmanx/Desktop/lwlt-arrangement.skill）；SHA-256：af4601d3ed6247d58b6b2ef62f25930fcabf2c2ce69fd79f55d76f385582420b。
• 桌面 /Users/inmanx/Desktop/老挝联泰AI指令表.docx 已同步酒店模板/示例；SHA-256：61163896a0acd71061655f74fdfcd7d3498ffdb9122d9a9201adbdb403bb2641。

2026-08-14 — 0.5.100 安排用车结算单位模糊搜索与日期范围修复

• 已按 ERP 原生车辆页核验，将安排用车输入收敛为团号、用车起止日期、结算单位搜索词和数量；不再要求车型/项目。
• 车辆结算单位搜索沿用原生 SelectBox 的模糊语义，覆盖结算单位名称、车辆/项目文字和结算方式；唯一匹配后由候选自动带入车辆字段，数量默认 1。
• 已同步安排 Skill、业务模板与示例、Agent/执行 Schema、平台门禁、生命周期日期校验和插件运行时；安排导游等其他安排边界未改变。
• 专项解析/插件/生命周期/模板回归已通过；本轮仅只读调研 ERP，未写入业务数据。
• 新包：dist/ltjt-order-assistant-0.5.100.zip、桌面 /Users/inmanx/Desktop/ltjt-order-assistant-0.5.100-安排用车字段修复.zip；插件 SHA-256：b995984d1cef214bc2d3f23b5bc8f55a1da228d086c7c97896bc38b13375553f。
• 安排 Skill：/Users/inmanx/Desktop/lwlt-arrangement-0.5.100.skill（别名 /Users/inmanx/Desktop/lwlt-arrangement.skill）；SHA-256：f988edda86e64ddb2c8d46a480010a770a70b2b063196e64cab4d3dca2d049c7。
• 桌面 /Users/inmanx/Desktop/老挝联泰AI指令表.docx 已更新并渲染检查通过。

2026-08-14 — 0.5.99 安排导游写后团队总表回查日期兜底修复

• 任务 TASK-20260814031230-xAkqMqw 的 ERP 原生响应为 操作成功，安排导游页面 7 个字段写后回查全部匹配；误报只来自团队总表 PrintGridLists 回查使用了空出发日期。
• 0.5.99 让团队总表回查复用团号无日期时的执行日 ±1 年日期窗，与首次 ERP 唯一解析和归属回查保持一致，并记录日期策略/范围证据。
• 仅调整写后回查，不改变安排导游写入、导游候选第 5 项导管映射或零/多候选门禁；本轮未再次写入 ERP。
• TypeScript、正式构建、控制面 36/36、插件/解析/生命周期 176/176、安排回归 36/36 和业务模板回归通过。
• 新包：dist/ltjt-order-assistant-0.5.99.zip、桌面 /Users/inmanx/Desktop/ltjt-order-assistant-0.5.99-安排导游回查日期修复.zip；插件 SHA-256：478090b79ed06bf2a0c809559575728b89e5b231fd2f45d8d216274461af7965。
• 安排 Skill 已重新打包到 /Users/inmanx/Desktop/lwlt-arrangement-0.5.99.skill；SHA-256：f6c3cccca029f6fd6dff08841dfe50e64f7705946ff163f9278aecba12c855b4。

2026-08-14 — 0.5.98 安排导游按 ERP 导游候选原生导管映射修复

• 现场只读核验确认安排导游页没有可用于导管派生的 czr 当前操作人字段；daoguan 是独立必填控件，导游候选 daoyou0 的原生 setval 将第 5 项关联到 daoguan。
• 0.5.98 按唯一导游候选行的第 5 项解析并校验导管；登录身份、计调 OP 和 existing_refs.owner_account 只保留为目标归属证据，不再写入或推导导管。缺失、冲突或非唯一关联继续在 ERP 写入前阻断。
• 同步安排 Skill、操作契约、业务模板、示例、扩展运行时/manifest、平台最低版本和生命周期回归；桌面 docx 示例已更新并完成 11 页渲染检查。
• TypeScript、正式构建、控制面 36/36、插件/解析/生命周期 176/176、变更 JS 语法和 Skill 校验均通过。
• 新包：dist/ltjt-order-assistant-0.5.98.zip、桌面 /Users/inmanx/Desktop/ltjt-order-assistant-0.5.98-安排导游导管映射修复.zip；SHA-256：d97bf00d84d4cbc725d208efe4cfe798d64ee71118c6e1f72c29e6cc8c1bd0ef。本轮没有 ERP 写入；真实安排导游验证仍需重载后执行。

2026-08-14 — 0.5.97 安排导游原生当前操作人派生修复

• 10:25 日志确认 0.5.96 仍在写入前停于 arrangement_guide_current_coordinator_missing；资源候选已加载，ERP 未写入。
• 根因补充为：导游安排原生表单的当前操作人控件 czr 未纳入导管派生，登录身份文本在弹窗同源文档中不一定可见。
• 0.5.97 优先用 czr 与员工候选唯一匹配，随后才使用同源身份文本或单一员工候选；多候选、冲突和无法匹配继续阻断。
• 新增两条生命周期回归：表单当前操作人唯一匹配、单一员工候选后备；全量验证通过后再交付重载。
• 新包：dist/ltjt-order-assistant-0.5.97.zip、桌面 /Users/inmanx/Desktop/ltjt-order-assistant-0.5.97-安排导游导管派生修复.zip；SHA-256：b6306d3e0480ee6ea5b630f1a80df2842ba735130ad2eddb2e466d44e8a204ce。

2026-08-13 — 0.5.96 安排导游导管上下文派生修复

• 21:59:46—22:01:01 日志确认 0.5.95 已等到导游候选数据；剩余唯一阻断为 arrangement_guide_current_coordinator_missing。
• 正常安排输入不要求用户提供导管；0.5.96 在表单当前值为空时，从同源 ERP 登录上下文中唯一命中的员工候选派生导管；有冲突或无法唯一确认仍失败关闭。
• 同步扩展、平台最低版本、测试断言和制品版本为 0.5.96；本轮未进入 ERP 写入。

2026-08-13 — 0.5.95 安排导游异步候选加载修复

• 21:49:48 日志确认 0.5.94 已通过团队总表 PrintGridLists 并打开精确导游页；阻断点变为导游 SelectBox/当前导管值尚未完成异步加载。
• 安排路由新增有限等待：导游资源候选数据和 daoguan 当前值准备完成后才进行唯一候选解析；不会放宽零/多候选门禁。
• 同步扩展、平台最低版本、测试断言和制品版本为 0.5.95；本轮未进入 ERP 写入。
• TypeScript、控制面 36/36、插件/解析/生命周期 174/174、定向生命周期 34/34 和 ZIP 逐文件校验均通过。

2026-08-13 — 0.5.94 团队安排请求识别修复与版本递增

• 修复团队安排路由准备误报 native_list_search_request_not_started：插件现在识别 ERP 实际发送的 Act=PrintGridLists 总表请求，并兼容 URL/body 中的原生筛选字段。
• 同步扩展 manifest、inpage、team-batch-inpage、平台最低版本和契约测试版本为 0.5.94；0.5.93 保留为上一版制品记录。
• 本轮仍未进入 ERP 或写入业务数据；桌面新包和回归结果在制品构建后记录。

2026-08-13 — 0.5.93 业务字段唯一定位改造完成

• 按最小改动原则保留现有 action、解析/执行分层和插件链路；没有新增定位状态机或顶层协议对象。
• 散拼新增子单、两类名单、三类窄修改、取消、恢复和导出已支持“预订客户 + 出发日期”必填、产品名称和领队选填、编号可选；安排和变更安排仍要求编号。
• 散拼新增子单的客户只作为新子单数据，母团检索不会使用该客户条件。
• 指令模板、四个受影响 Skill、解析 Schema、平台校验、插件前门禁、ERP 原生筛选和唯一候选解析已同步；旧编号路径继续兼容。
• TypeScript 检查、36/36 控制面测试、173/173 插件/解析/生命周期测试、变更 JS 语法检查和五个 Skill 校验均通过。
• 插件候选升级为 0.5.93，18 文件版本包与源码逐文件一致；本轮未进入 ERP 或写入业务数据。

2026-08-13 — 0.5.92 全自动交接延迟与查无单号提示修复完成

• 任务 TASK-20260813074033-skhAF3o 并非 ERP 检索卡死：Agent 于 15:41:26 自动确认，插件于 15:44:19 才接单，15:44:26 即因 LW-260903-A 精确候选为 0 阻断；实际正确单号为 LW-260903A-A，没有 ERP 写入。
• 2 分 53 秒空档来自扩展重载后的桥接恢复缺陷：后台重新注入逻辑仍只识别旧端口 8765，漏掉当前控制面 8786；平台页在 15:44:18 刷新后桥接恢复，1 秒内接单。
• 0.5.92 将本地平台端口识别统一覆盖默认端口、8765 和 8786，扩展安装、启动或重载后会主动向当前平台页重新注入桥接，不再要求人工刷新页面。
• ERP 精确候选为 0、多个、内部引用不完整或检索失败时，插件现在返回稳定错误码和包含原输入单号的中文提示；候选为 0 时明确提示“ERP 中未找到单号……请核对完整单号后重试”。
• TypeScript、控制面 36/36、插件/解析/生命周期 167/167 通过，合计 203/203；0.5.92 的 18 文件版本包与通用别名 SHA-256 均为 5660f075c644583eed1c8a0cfdd39cc0bfb0a9600256e662bf66cc53f92b48e6。Agent Prompt、五个 Skill、解析 Schema 和业务 operation 未改变。

2026-08-13 — 0.5.91 全业务自动确认与名单回查收敛完成

• 组织开启“全自动化”后，所有 AgentBus 业务使用同一自动确认判定，不再按创建、名单、安排、修改、取消/恢复、导出或删除设置人工例外；缺资料、解析阻断或插件校验失败仍会停止。
• 任务 TASK-20260813065004-xtyK6LI 的 3 分 44 秒中，Agent 解析约 38 秒、人工等待 2 分 49 秒、ERP 执行与回查约 17 秒；本轮已消除中间的人工等待。剩余解析时间来自外部 Agent 的会话建立与 SSE 生成，本地没有隐藏重试或睡眠。
• ERP 保存后只持久化 2 条有内容的游客行，而不保留订单的 16 个空白游客位。旧插件将“写前容量 16”误当成“写后必须存在 16 行”，因此把明确成功误报为 write_after_requery_mismatch。
• 0.5.91 改为比较全部应持久化的非空游客投影：任一目标行、未指定已有行缺失/改变或出现额外非空行仍失败；仅允许 ERP 原生空白占位行压缩。
• 已在 Chrome 重载 0.5.91，并对上述任务执行一次只读 fresh requery：团号/tid/ddid 匹配，序号 1/2 投影哈希一致，expected_count=actual_count=2，expected_slot_count=16，无 mismatch。任务已收敛为 completed，no_additional_erp_write=true，没有第二次 ERP 保存。
• TypeScript、控制面 36/36、插件/解析/生命周期 166/166 通过，合计 202/202；0.5.91 的 18 文件包与源码逐项一致。版本包与通用别名 SHA-256 均为 b711af85297ea10eafdc02f131d03fc18df84f10c4a4808cdcf9742a25a2a561。
• Agent 主提示词、五个 Skill、解析 Schema 和业务 operation 字段未变；此次根因位于控制面自动确认和插件回查层，不向 Agent 提示词增加执行细节。

2026-08-13 — 0.5.90 名单归属复核日期窗修复完成

• 新任务已正确读取 16 个游客位并规划 2 行补录，失败点推进到写前归属复核；任务 write_attempted=false，没有 ERP 写入。
• 根因是首次 ERP 对象解析已使用缺日期编号 ±1 年窗口，但二次归属复核仍提交空日期。只读对照证明空日期返回空结果，日期窗则同时命中订单号、tid 和 ddid。
• 0.5.90 让归属复核复用同一日期策略，并只在找到具体行后比较 marker、账号、状态和内部引用，避免一条“未找到”扩散成多个误导 blocker。
• TypeScript 检查、正式构建、控制面 35/35、核心回归 166/166 和 18 文件制品一致性全部通过，合计 201/201。
• 0.5.90 版本包和通用别名 SHA-256 均为 9ce60be57e884aa59bfdda2720b6f8dc21fe784f5f3900e4f00745b8c8cb8608；0.5.89 已移入 2026-08-13 发布归档。
• Agent Prompt、五个 Skill、解析 Schema、operation 字段和生命周期 v2.7 业务契约均未改变；本轮只修插件执行器的只读归属证明。
• 当前 Chrome 已重载为 0.5.90，操作台缓存版本已刷新；PING 确认插件、ERP 登录账号和自动化开关正常。
• 下一步：重新提交同一 2 行名单任务，取得真实保存和完整 16 行 fresh requery。

2026-08-13 — 0.5.89 名单按序号安全补录修复完成

• 最新失败不是 Agent、订单检索或 ERP 登录问题，而是旧插件把本次 2 行名单误作订单总游客位，与页面真实 16 行比较后写前阻断；该任务没有 ERP 写入。
• 插件现在从精确订单编辑页读取真实游客位，以明确序号合并用户本次提供的一行或多行名单。空白行允许填充，同值行保持，已有不同内容要求明确覆盖确认，重复或越界序号阻断。
• 原生 DaoRuDones 解析前建立全部游客控件快照，解析后恢复未指定行及同值行；即时 fresh requery 比较完整合并后投影，避免只验证新增两行而遗漏其他游客被改写。
• 生命周期契约升级为 ltjt-lifecycle-v2.7-passenger-sequence-merge-2026-08；Schema、mapping、业务模板和 lwlt-lifecycle Skill 已同步。Agent 主提示词保持 ltjt-agent-prompt-v1.2-lean-router，没有加入插件或 ERP 执行细节。
• TypeScript 检查、正式构建、控制面 35/35、核心回归 166/166、五个 Skill 校验及 18 文件制品一致性全部通过，合计 201/201。
• 0.5.89 版本包和当时通用别名 SHA-256 均为 130ad84b802e72e9a1e3cee193c1073f7d0558528aebf4d39089f1c50348ce09；0.5.88 已移入 2026-08-13 发布归档。
• 该轮只读核实 ERP 游客控件，没有保存或提交；当时下一步是重载 0.5.89 后复跑同一 2 行任务。

2026-08-13 — 0.5.88 散拼子单客户语义解析修复完成

• 新日志证明 0.5.87 的执行日 ±1 年检索已生效，并唯一命中 LW-260907A-B；此次失败已推进到子单表单客户解析阶段，仍为写前阻断、未创建子单。
• 已在登录 Chrome 做只读核验：子单表单有 99 条客户候选；“广东衡阳客户”不是正式主数据名，但同时含“广东”“衡阳”的候选只有 LW衡阳国旅云南分社（广东市场）（ID 661）。
• 插件现在保持精确匹配优先；精确与唯一包含均失败后，才使用输入中的全部可识别来源地词匹配 ERP 客户名称，并且仍要求结果唯一。零候选或多候选不选择、不写入。
• 子单适配器改从选中的原生 tdid 行读取母团产品 广东直飞行程--衡阳（晚航班），再以最终客户主数据名称执行来源兼容校验；旧代码读取不存在的产品 input，导致该检查被错误跳过。
• 已解析出的正式客户名称和 ERP ID 现在同时用于子单预订客户与应收结算单位，不再把 Agent 原始短语写入结算字段，也不再留下空客户 ID。
• 阻断列表现在只包含实际 ok=false 的检查，不再把 product_has_no_source_region_token 这类通过/不适用原因附加到其他失败中。
• 插件和平台最低版本升级至 0.5.88；Agent Prompt、五个 Skill、解析 Schema、operation 字段及业务白名单均未改变。
• 控制面 35/35、核心回归 165/165，合计 200/200；TypeScript 检查与正式构建、JS 语法、git diff --check 和 18 文件制品逐文件一致性均通过。
• 0.5.88 版本包和通用别名 SHA-256 均为 32dca6b01452c605df989235eaf28d7ff34c4b34148726b4fb7d809d407f2c85；0.5.87 已移入 2026-08-13 发布归档。
• 该轮 Chrome 操作只打开并读取子单表单后关闭，没有保存或提交；当时的下一步是重载 0.5.88 后复跑该子单。

2026-08-13 — 0.5.87 缺日期编号检索修复完成

• 已复核失败日志和登录 ERP 的只读结果：母团存在，失败发生在写前列表定位；原因是空日期触发 ERP 必填校验后保留旧列表。
• 插件共用列表检索层现仅在“明确编号 + 起止日期均缺失”时补执行日 ±1 年；已带日期、仅空编号及其他查询保持原语义。
• 已消除筛选字段 blur 造成的提前 AJAX 竞态，并要求与当前字段一致的原生列表请求完成且 HTTP 2xx 后才读取结果。
• 插件和平台最低版本升级至 0.5.87；Agent Prompt、五个 Skill、解析 Schema、生命周期执行契约及业务白名单均未改变。
• 控制面 35/35、核心回归 145/145，合计 180/180；TypeScript 检查与正式构建、JS 语法和 git diff --check 通过。
• 0.5.87 插件包含精确 18 个文件并与源码逐文件一致；版本包和通用别名 SHA-256 均为 086b5af492b74851ed99674d91b8eb40af1ac3c78cfb39de757459ad120f2cee，0.5.86 已移入 2026-08-13 发布归档。
• 本轮未执行 ERP 写入；下一步是用户重载插件后复跑原无日期散拼子单。

2026-08-13 — 解析崩溃与待回查轮询修复完成

• 已确认服务退出的直接原因：远端 PostgreSQL 空闲连接 read ETIMEDOUT 由 pg 连接池向 Node 进程抛出未监听错误，导致控制平面退出。
• 已在数据库池上增加 error 监听，并保护事务 ROLLBACK；连接异常会被记录和隔离，不再直接杀死服务进程。
• 已从普通 status=active SQL 和浏览器 isTaskPollable() 中移除 reconciliation_pending、saved_unverified、execution_uncertain 等人工回查状态；人工回查仍可显式调用插件回查链路。
• 最新任务的旧解析租约到期后已被安全恢复为 parse_failed，无插件/ERP attempt；随后浏览器删除了该任务，本次未主动发起删除。
• 服务当前 PID 为 18283，监听 127.0.0.1:8786；/health/ready 返回 200，数据库迁移 010_task_query_optimization 生效，AgentBus 已连接。
• 验证通过：控制面 35/35、核心回归 144/144、TypeScript 构建、JS 语法检查和 git diff --check。

2026-08-13 — 最新任务延迟与平台卡顿排查（已完成）

• 已读取 planning-with-files 规范并恢复现有计划、发现和进度文件；保留既有未提交工作树改动。
• 已建立本轮排查目标：分离 ERP 实际写入、插件本地执行、平台结果轮询/落库、登录恢复和页面刷新请求链路。
• 已读取最新任务日志 TASK-20260813032909-jEsNSV0：单一 execution_id，ERP 返回 HTTP 200 成功并完成回查；插件本地结果 03:30:38 已是 completed，平台事件 03:33:25 才落库/展示。
• 初步判断主延迟不在 Agent 或 ERP，而在插件结果回传到平台终态之间；日志本身暂未证明发生了真实重复执行。
• 已查询本地 PostgreSQL：仅有 5 条任务事件和 1 个 ERP attempt，确认没有真实重复下单；服务端完成时间为 11:33:25.808968+08。
• 已定位两个高概率机制：服务端旧快照可覆盖插件本地新状态；2.5 秒轮询没有并发锁。另发现任务详情/列表传输并渲染完整解析与执行结果，可能阻塞浏览器主线程，间接推迟 /result 回传。
• 已确认认证恢复页没有请求超时；/api/auth/me 和 /api/auth/csrf 任一请求挂住即可无限显示“正在恢复登录状态”。
• 已核对 SSE、30 秒定时同步、插件 2.5 秒轮询和任务详情重绘的交互；未发现页面可见性恢复或 AbortController 超时兜底。
• 已完成只读诊断：本轮没有修改业务源码、插件制品或运行数据；精确定位 2 分 47 秒仍需下一轮加入客户端与服务端请求耗时埋点。

2026-08-13 — 数据库全量加载核对（已完成）

• 用户追加询问数据库是否存在全量加载。
• 初步源码证据：任务主列表有分页，但分页任务会关联加载全部事件并解密完整结果；活动/确认任务查询上限为 200。
• 下一步核对实际事件分布、数据体积、索引和 EXPLAIN，判断当前数据库规模下是否已构成主要卡顿源。
• 只读统计脚本首次因跨语句复用 CTE 失败，已记录并改用每条 SQL 独立 CTE；未发生数据库写入。
• 已完成数据库统计与执行计划：当前 311 个任务、2,285 条事件、12 个活动任务；默认分页 SQL 实际处理 306 条任务，事件 SQL 实际扫描 2,285 条事件，但当前耗时仍为毫秒级。
• 已区分“网络返回全量任务行”（目前没有）、“SQL 内部全量扫描”（存在）和“分页任务附带完整结果/全部事件”（存在）；本轮只读检查完成，未修改源码或数据库。

2026-08-13 — 整体修复实施边界（待确认）

• 用户要求整体修复；已按 grilling 规则暂停实施，等待确认是否只修改源码、补测试并本地验证，不自动重启/部署服务、不发布插件、不修改业务数据。

2026-08-13 — 整体修复实施启动

• 用户已确认实施范围：修改源码、补测试并本地验证；不重启、不部署、不发布插件、不修改业务数据。
• 当前实施顺序：前端状态/轮询/认证超时 → 控制平面摘要与详情接口/查询优化 → 测试和构建验证。
• 实施前基线：工作树已有大量未提交改动，LianSyn-platform 为未跟踪目录；本轮将限定在故障相关前端、控制平面、迁移和测试文件，保留其它改动。
• 已确认接口改造边界：/api/tasks 提供摘要，/api/tasks/:taskId 保留完整详情；前端选中任务和自动下发前按需加载详情，活动轮询只依赖摘要。
• 控制平面语法/类型检查通过；控制平面测试 34/34 通过。期间同步修正了已有页面版本静态断言，并确认列表不再使用窗口计数。
• 本地已应用非破坏性迁移 010_task_query_optimization；新增任务可见/活动状态/活动交接和事件组织索引。迁移未修改任务、事件或 ERP 数据。
• 迁移后执行计划确认默认列表走 tasks_visible_created_idx，活动查询走两个活动索引；当前列表约 0.4 ms、活动查询约 0.7 ms。

2026-08-13 — 整体修复完成

• 前端已加入 API 超时、认证恢复超时提示、后台/标签页可见性控制和轮询单飞锁；服务端旧快照不会覆盖更新的插件结果，短期本地结果 overlay 会等待服务端终态确认。
• /api/tasks 列表现在只返回轻量摘要，不再返回原文、operation、完整加密结果或事件数组；选中任务、确认提交和自动接管前才请求 /api/tasks/:taskId 完整详情。
• 活动/确认后台查询使用 include_total=false，避免无意义的总数统计；列表总数改为独立 COUNT，避免 COUNT(*) OVER() 先处理整批结果。
• 事件详情改为按任务主键 UUID 查询，并新增 010_task_query_optimization 的组织、生命周期和事件索引；本地数据库迁移已成功应用。
• 前端脚本缓存版本更新为 20260813-stability-1，避免浏览器继续使用旧 app.js。
• 最终验证：TypeScript 构建通过；控制面 35/35；平台核心回归 144/144；前端/服务端 JS 语法检查通过；摘要列表与完整详情本地烟测通过；git diff --check 通过。
• 按已确认边界未重启当前服务、未部署、未发布插件、未修改业务任务/事件/ERP 数据；运行中的服务需在合适窗口重启后加载新代码。

2026-08-13 — 历史任务目录与最近任务视图完成

• 已新增独立 /history 历史任务目录入口；首页任务卡片固定只查询并展示最近 10 条。
• /api/tasks 新增 search/status/limit/offset 查询能力和 pagination 元数据，历史页支持搜索、状态筛选、分页。
• 历史页复用现有任务详情、补充输入、确认提交、插件回查和彻底删除逻辑；没有新增归档状态或复制执行链路。
• 首页之外的活动任务通过独立运行时缓存和 status=active 查询持续回查，不因最近 10 条视图而丢失后台执行状态。
• 校验结果：TypeScript 检查通过；控制面 34/34；核心回归 144/144；正式构建通过；正式主机名下 /history 路由烟测返回 200。

2026-08-13 — 历史任务目录与最近任务视图

• 已完成需求确认：独立 /history 页面；AI 操作台只展示最近 10 条；历史目录保留全部未删除任务及完整管理动作。
• 已完成代码现状核对：服务端任务查询、首页卡片渲染、详情动作和静态服务边界已定位。
• 当前正在实现服务端历史查询与前端双视图，尚未修改业务执行契约。

last_updated: 2026-08-13

完整历史进度见 progress.full.md。

当前状态

• 当前候选：Chrome 插件 0.5.90。
• 当前主提示词：ltjt-agent-prompt-v1.3-arrangement-other-optional。
• 发布状态：核心窄能力候选已完成工程验证，等待业务审批；宽能力继续阻断。
• 测试数据：旧批次已由用户手工删除；2026-08-13 新任务又产生三条独立团和三条散拼母团，清理状态尚未确认，失败子单没有写入。
• 当前没有正在运行或自动续跑的 ERP 测试任务。

2026-08-12 — 生命周期与修改能力收口

• 第四轮真实生命周期完成四条创建路线、两类名单、两组五类安排、窄修改、测试应收、取消/恢复、40/40 文件源、12/12 删除与最终缺席回查。
• 插件在真实缺陷驱动下稳定化到 0.5.81，关闭应收串改、取消态子单误选、残留编辑窗和辅助 frame 误判。
• 0.5.84 专项真实证明独立团标间数 8→9→8，以及唯一未确认酒店行离店日和房间数修改；测试酒店行随后清除。
• 0.5.85 完成 18 类路由提示词、三个 Skill 重构和无变化写前阻断，不扩大业务白名单。
• 最近验证通过：TypeScript 检查、控制平面 35/35、核心回归 145/145、JS 语法和交付物源码一致性。

2026-08-12 — 项目清理与交接

• 完整 task_plan.md、findings.md、progress.md 已冻结到 archive/project-history/2026-08-12/，根目录改为精简现行版本。
• 新增 HANDOFF.md，集中记录恢复顺序、当前能力、失败关闭范围、安全门槛、制品和下一步决策。
• 0.5.84 里程碑包移入 archive/releases/2026-08-12/；0.5.1—0.5.83 重复版本包删除。
• 三份 2026-08-10 原始测试报告移入 archive/evidence/2026-08-10/；reports/ 恢复为纯临时输出目录。
• dist/ 仅保留当前 0.5.90 版本包、无版本别名、五个 Skill 包、控制平面构建与说明文件；0.5.86—0.5.89 已移入日期化发布归档。
• 项目内 7 个 .DS_Store 已按精确路径清除，其中 3 个来自本轮 Agent/Skill 目录复核；密钥、依赖、运行配置和业务源码未纳入清理。
• Codex 捆绑运行时没有把 Node/npm 自动加入子进程路径；总测试包装命令因此未进入测试。改用工作区返回的 Node/pnpm 绝对路径执行同一组子门槛后，TypeScript、33 个控制面测试、133 个核心测试及正式构建全部通过。

后续等待

下一步复跑本次 2 行名单补录；之后再由业务负责人选择窄能力分批放行、同制品全生命周期复验、宽修改逐字段研究或团队文件平台模块。

2026-08-12 — Agent 解析层优化启动

• 用户指出主提示词再次混入插件和服务端执行知识，要求 Agent 只做输入解析和标准数据返回，并同步审计五个 Skill 的优雅、准确和效率。
• 已完整读取 skill-creator 与 planning-with-files 规范，确认采用“主文件最小工作流 + 按需字段 references”的结构。
• 本轮只重构解析层文本、契约测试和 Skill 包，不修改 ERP、插件执行安全逻辑或业务白名单。
• 已定位主要冗余源：运行时 buildParserMessage() 的长篇执行说明、五个 Skill 的执行/回查段落、四类执行器 reference，以及五份 UI 元数据中的执行性措辞。
• 已确认单纯改文案不够：当前外部解析 validator 把生命周期执行态 test context 和隐藏引用作为 Agent 输出必填，控制平面也不会自动补齐。后续改造将明确拆分解析态与执行态校验，保持执行器严格门槛不变。

2026-08-12 — Agent 解析层优化完成

• 主提示词和运行时消息均完成 parse-only 改造；运行时单任务消息缩至版本、职责、三种状态和原始输入，不再重复完整路由或下游执行规则。
• 五个 Skill 及其 references/openai.yaml 全部重写为解析知识，删除 3 份纯执行器 reference；五个 Skill 均通过官方 quick_validate.py。
• 新增独立解析态 agent_operation Schema，并将自然语言解析 validator 与完整执行 JSON validator 分离。
• 新增 18 路由解析态样例、Schema 分层、提示词禁词和 Skill 禁词测试；核心回归由 133 增至 137。
• TypeScript 检查、控制平面 33/33、核心回归 137/137、正式构建全部通过，合计 170/170。
• 五个 .skill 包已从当前源码重建并逐文件比对一致；新 SHA-256 见 HANDOFF.md。
• 未进入浏览器、未创建或修改任何 ERP 数据，执行能力白名单和插件门槛保持不变。

2026-08-12 — 插件分段门禁改造启动

• 用户确认前门禁只校验无需进入 ERP 即可确定的内容；模糊候选、内部引用、当前状态与当前值必须由插件在 ERP 操作过程中解析。
• 用户同时确认平台会话 ID、任务 ID、重要摘要和用户通讯字段属于平台管理层，不能混入 Agent operation 或 ERP 业务字段。
• 只读探针显示当前 18 条最小解析样例全部通过 Agent validator，但只有独立团单个、独立团批量和散拼母团计划 3 条可直接通过插件 validator；其余 15 条被内部引用、测试上下文、预解析资源或对象类型要求提前阻断。
• 本轮将新增分段 validator 与 ERP resolver 接驳；不会通过删除严格写入门禁来换取通过率，也不会进入真实 ERP 或创建测试数据。
• 已确认当前阻断点同时存在于三层：控制平面确认时仍强制生命周期测试上下文；插件任务入口在进入 ERP 前调用完整执行态 validator；页面生命周期路由也要求调用方预先给出 kind/tid/ddid/resolved resource。
• 已确认现有创建路线已经在 ERP 页面内采用“精确匹配 → 唯一包含 → 唯一分词包含”的候选解析规则；分段改造将复用同一原则，不把“候选唯一命中”改回 Agent 必填事实。
• 现有平台已独立持久化 session、task、parse response 和 important summary；本轮保留这些平台信封，只调整确认与插件调度边界，禁止将其复制进 operation.data。
• 进一步发现解析宿主仍会把 task_id/instruction_id/received_at/operator/parser_prompt_version 回写进 operation.source；插件摘要也会从该位置取 task ID。该耦合将移除，任务身份继续只从任务领取与 execution record 获取，解析 operation 保持纯业务载荷。
• 正常生产任务的写授权已有独立持久化 execution record（状态、execution ID、领取/流转校验）；生命周期适配器无需再要求普通业务 operation 携带 allow_live_write。历史测试任务仍在检测到 source.test_context 时执行原有九月测试授权。
• operation planner 已开始分为 validateDispatchOperation() 与 validateOperation()：前者覆盖解析态可见编号、最小业务字段、格式和窄能力；后者继续面向 ERP 解析后的内部引用与页面状态。
• 名单、五类安排、三类窄修改、取消/恢复改为生产 browser_lifecycle 路由；删除仍明确 testOnly。带 source.test_context 的历史回放在 dispatch 阶段直接沿用原严格测试契约。
• 当前环境的 node 不在默认 PATH；已重新读取工作区依赖，后续统一使用捆绑 Node 绝对路径执行语法与测试，不将环境缺失误判为代码失败。
• 页面层已新增 resolveLifecycleOperation()：仅凭用户可见编号在独立团/散拼列表做精确唯一查找，生成 kind、tid、ddid、母团/子单关系和 resolution_source=erp_unique_match；零候选、跨列表多候选或内部引用不完整均在写入前停止。
• 安排页面新增二次资源解析：create 在当前页面候选中按精确/唯一包含匹配导游、酒店或供应商+项目；酒店 update 从唯一槽位读取当前 row ID、资源、房型、日期、房数、状态和备注，再构建执行态 operation。
• 名单解析态 import 会在 ERP resolution 后规范化为执行态 first_import，目标游客数由用户名单行数冻结；取消/恢复的 from_status 则在打开精确编辑页后读取，不要求用户记忆。
• 生命周期页面路由已区分普通任务与显式测试任务：普通任务依赖唯一编号和内部引用，历史测试任务继续额外核对九月日期、测试标记和测试账号。
• 后台调度已改为先调用 dispatch validator；生命周期和导出在 ERP resolution 后再次调用严格 validator。解析后的 execution operation 只写入插件本地任务副本，用于不确定状态的精确只读 reconciliation，平台原始 operation 不被替换。
• 生命周期适配器的 marker/account/2026-09 条件已改为仅在真实 test_context 存在时生效；普通任务仍必须满足 ERP 唯一引用、窄字段、当前状态、表单身份、明确服务端响应和写后回查。
• operation planner 单测当前 30/31 通过，唯一失败是旧断言仍期待 browser_lifecycle_test；这是预期的路由名称变更，待新增分段门禁测试时统一更新。
• planner 已新增解析态/执行态正反测试：解析态生命周期可以通过 dispatch、同一载荷不能直接通过严格门禁；伪造 tid、resolved、状态和 side-effect policy 会被前门禁拒绝；导出只需单号和文件类型即可进入 ERP resolution。该测试集现为 35/35。
• 生命周期静态与契约测试已同步新调度顺序（ERP resolution 必须早于 route preparation，route 必须早于 adapter preflight），26/26 通过。
• 解析宿主已停止向 operation.source 注入 task/instruction/received_at/operator/prompt version；prompt version 改存 parse-result 平台信封。外部 Agent 测试 45/45 通过。
• 控制平面现在只在 operation 已显式携带真实 test_context 时执行九月测试授权；普通生命周期确认不再制造空 test_context。平台 UI 也只对真实测试上下文显示“生命周期测试写入审核”。

2026-08-12 — 插件分段门禁改造完成

• 插件版本升级为 0.5.86，执行契约升级为 ltjt-lifecycle-v2.6-staged-resolution-2026-08。
• 18 类用户输入均先通过无需 ERP 事实的 dispatch/front gate；生命周期与导出随后在 ERP 内唯一解析对象、资源、当前值和内部引用，再进入严格写前门禁。
• 平台任务 ID、执行 ID、会话、解析版本、确认、重要摘要和通讯状态不再写入 Agent operation；解析版本留在 parse_response，任务身份留在平台任务/执行信封。
• 当前执行契约的 operation.source 只允许显式历史测试 test_context；收件时间和批量子序号分别留在平台任务信封与插件循环上下文。
• 普通生产窄能力不再要求 TEST-202609、测试账号、2026 年 9 月或测试允许清单；显式历史测试上下文仍保持原限制，order_delete 继续只允许测试清理。
• Agent 主提示词和五个 Skill 无需增加任何插件或门禁知识；自动化继续断言其 parse-only 边界。
• TypeScript 与正式构建通过；控制面 34/34、核心回归 144/144，合计 178/178。
• 0.5.86 插件包含精确 18 个文件，与源码逐文件一致；版本包和通用别名 SHA-256 均为 54c7855ce1b531e7e6d1a6b2623648cbb7939fee2f0e7b635f84960dbcfd306d。
• 本轮未进入 ERP、未创建或修改业务数据；0.5.86 的真实全生命周期制品级复验仍是独立发布门槛。

2026-08-13 — 主提示词再次精简

• 主提示词升级为 ltjt-agent-prompt-v1.2-lean-router，由 107 行收缩为 17 行。
• 主提示词只保留角色、宽容识别、上下文续接、业务能力路由、三态选择和纯 JSON 输出原则。
• 18 类指令、action、字段结构和业务边界继续由五个 Skill 与解析 Schema 定义，不再在主提示词重复维护。
• 实际运行时解析版本已同步，相关解析与模板回归通过；插件、ERP 能力和发布状态未改变。