Wyndham-RSVN-0918/.project-docs/30-worklog/current-state.md

Current State

2026-09-18 最新：代码交付目标为 0918/main

用户要求将当前最新代码提交并推送到 https://git.nianxx.cn/shiyuyun/Wyndham-RSVN-0918 的 main；目标原有提交与本地一致，本次汇总确认字段接口、Meal 只读展示、执行结果核对、测试及文档。代码能力和验证结论以紧接下节及交付说明为准；Git 推送本身不代表运行服务加载或生产酒店验收。提交范围与验证复核见任务记录。

2026-09-18 最新：确认字段酒店接口代码接入完成，服务尚未更新

按用户“开始接入这些接口”完成隐藏餐厅后端收尾、Rate派生Meal、GROUP新建/修改Note与完整基础字段、FIT修改Account/Market/Source及逐项回读、预览、模拟器。完整前端409项/构建、后端全量及新增目标回归（最新报告2729项、17跳过、0失败/错误）、Python71项和独立Java目录/Trace检查通过。

当前5178/8082服务、私有酒店目录、七封邮件前态和原排队任务未操作，未连真实酒店写入。实际Account使用已有Profile配置；company别名如缺映射仍拒绝，不虚构酒店代码。本节覆盖下面审计中的代码缺口，原服务要加载本轮代码后才具有新行为。交付／证据。

2026-09-18 最新：Meal 只读跟随 Rate Code

用户改为仅展示Rate解析后的含早/不含早。New/Update已取消Meal下拉，按当前Rate目录同步待确认值；历史确认仍按快照回显。隐藏餐厅必填拦截同时修复，含早字段及其他校验保留。4文件116项（含New/Update父页确认请求）、类型检查和目标ESLint通过；5178待确认页核对Meal不可编辑、无下拉箭头。没有真实确认或酒店操作，服务未重启。见证据。下方独立Meal选择及相关审计口径为历史；其余接口审计缺口未在本轮处理。

2026-09-18 最新：七封邮件所需30组前态已装入当前本机环境

用户明确授权“你去装啊”。现有5178/8082对应模拟酒店已通过实际接口创建并回查26个旧预订团号＋4个源Allotment，计15Block/21FIT/15客档；FIT编号和21条Note来源关联已装入当前工作台。30组完成，51次额外只读核对通过，59张H2原行/25张Booking PG保留，后台已恢复。11个NEW未预置，旧2失败/3等待队列未重跑或清除，LT1旧失败仍会阻塞后续。用户上传确认测试待进行；证据。本节覆盖下方“30组未装入”的历史状态。

2026-09-18 工作台确认值至酒店接口审计：发现未修复缺口

Meal界面已简化，但初始含早改不含早会被隐藏餐厅必填拦住（New/Update父页均复现）。早餐目前只在GROUP NEW发出并回查；GROUP UPDATE/FIT NEW/FIT UPDATE未同步，GROUP Note也未接。修改流程部分基础/价码字段仍保留旧值；SOURCE/company可确认但本机目录无映射。291项后端及差分探针完成；2项旧Meal父页测试未同步。完整结论及证据见审计记录。本轮未改业务代码、服务或酒店数据，以上不是已修复状态。

2026-09-18 工作台 Meal 简化为是否含早餐

New/Update与已确认详情的Meal仅两项“含早餐／不含早餐”，Breakfast restaurant标题及框移除，修改前与AI处理参数回显同步。未知早餐状态不自动选择，原餐厅兼容值保留既有确认契约及酒店目录校验。相关30项前端测试、类型检查、目标ESLint和5178只读页面核对通过。没有服务重启、确认/酒店操作或子智能体。见证据；下方运行和TA状态未改变。

2026-09-18 最新：未执行原因已查清，接口与参数预览已可见

LT260911KB本次全部READY/QUEUED、实际调用0；同scope前序searchBlocks返回0团并失败，阻塞后续。当前本机模拟酒店仍无原团，七封前态尚未导入。已在原页面增加预计接口/字段/值和未知依赖，实际记录前置并展示字段路径；GROUP UPDATE不写的字段标为保留，排队原因更清楚。90项相关测试、类型/lint及5178只读视觉核验通过，无后台业务变更。详见证据。先全新团NEW→UPDATE；原七封先准备前态及处理旧队列，再LT2→LT1，操作由用户执行。

2026-09-18 最新：本机服务已更新并验证，七封邮件前态仍待装入

用户明确授权本机服务更新。本轮已加载最新FIT NEW条件TA包至原8082，并更新配套本机模拟接口/取消入口/严格目录，修复过期证书、Java17测试装配兼容和launchd locale。原5178地址、原环境文件、连接身份与Key保留。59张H2业务内容、25张Booking PG和10张Edge PG核对通过；H2仅V53及系统元数据updated_at预期变化，旧2失败/2等待执行未重办。页面/工作台接口、认证下一状态查询和JDK17 TLS均通过，无酒店写入。

七封邮件的30组前置预订未装入当前环境，也未上传或确认邮件；不能宣称全部七封已可直接跑通。平台接口本来连接Oracle沙箱；本次保留原本机模拟连接，不等于切换平台沙箱配置或验收TA页面。没有子智能体。当前状态优先于下方“运行服务未更新／更新只能由用户执行”的历史记录；更新证据。

2026-09-18 最新：FIT NEW 条件TA代码接入及模拟通过，页面映射待沙箱验收

按用户要求完成postReservation/getReservation字段接入：GROUP NEW不传；FIT NEW有Tour以externalReferences的TA_RECORD_LOCATOR类型发送、无则省略并允许新建。逐笔回查错误/缺失/重复不授予完成，旧检查点不续办。完整后端2697通过/17跳过、前端42/类型/模拟70通过，47参数/3故障符合预期，新包已生成未安装。

该特殊类型映射来自官方schema＋报表字典组合推导，仍无官方TA专用REST样例或沙箱页面落值证明，不能称原生字段已完全验收。用户负责更新及页面验证；没有代理、上传或现有环境操作。交付／证据。

2026-09-18 当前规则更新：仅 FIT NEW 恢复有条件 TA 写入需求

用户明确 GROUP NEW 不传TA；FIT NEW有Tour Code时传入TA Record Locator，无Tour Code时不传。已写入业务规则与CR。此次仅更新规则文档；代码仍为前版全部不传TA，GROUP NEW符合、FIT NEW有值写入待实现。下方无TA包/47场景结果仅对应旧范围，不代表本次有值写入已接通。UPDATE及酒店附件范围未变，无环境或业务操作。

2026-09-18 最新：无 TA 代码和独立模拟已完成，运行更新由用户执行

GROUP/FIT 已移除 TA 发送、搜索、核验及完成条件，不改用替代字段；Tour Code/Block Name 保留。FIT 后续修改/转换使用同酒店、同环境、同范围最近成功办理保存的完整 Oracle 编号并逐笔查询；缺历史编号或历史有歧义则停止。正式 Factory 与本机装配都已接入，旧检查点拒绝静默续办。

47参数场景（45完成/2预期拒绝）、3取消故障、1034调用无TA/附件、完整后端2689通过/17跳过、前端41项与类型/模拟67项通过。模拟数据已在独立验收环境生成，临时服务已停；更新包已准备，当前工作台/原模拟目录和平台沙箱未操作。用户更新后用本系统新建测试笔验证修改/取消/双向转换，无系统保存编号的旧FIT不自动处理。平台本来连接沙箱，不再把实际酒店验收作为本次门槛。

以本次交付及证据为最新口径；下方“TA仍待实现/保持正式TA阻断”是历史状态。

2026-09-18 最新关注：本机工作台与沙箱，不以实际酒店验收为门槛

用户再次确认平台接口本来连接的就是沙箱服务，环境属性不再列为待确认项。现场只读检查5178、8082与旧本机Edge健康均正常；所检查Java仍为CP33包，该回放配置指向127.0.0.1模拟Oracle，旧候选目录无严格simulation配置，已存模拟快照的FIT/Block均为0。这些本机回放证据不能用于否定平台沙箱连接或推断沙箱数据为空。独立acceptance-7确已造数据并通过47参数/3故障验证，但实例已停、未装入当前工作台。详见现场核对。TA暂停的代码收尾和当前工作台版本/测试数据同步仍待，不再把实际酒店验收混入本次问题。

2026-09-18 最新范围：TA暂停，其余接口状态已复核

用户暂停TA字段/接口，不选择替代字段。其余本期核心GROUP/FIT、客档、房量、Note正文、取消及转换已有本地接入和既有模拟证据；但“无TA”新范围尚未实现：GROUP仍写TA，FIT搜索、回查/守卫仍依赖TA。不能把范围记录等同代码已改或全流程已放行。酒店代码/档案/取消配置、现有服务加载及真实环境验收仍未完成，操作由用户执行。此状态优先于下方继续研究TA/选择替代方案的旧接续。

2026-09-18 TA 查证扩大为可供业务确认的替代方案

用户要求放宽范围，作用相近的接口也交其确认。已核对Custom Reference、普通External References、Reservation UDF三项候选及Block TA/Guest Locator/GDS等区别；Custom Reference的新建、修改、详情、搜索路径最明确，已有平台入口可承载。UDF的flexChar具体格式仍待核实，原TA特殊类型仍未证实。候选比较见扩大范围核对。用户尚未批准替换原TA字段；未改代码、模拟器、守卫或酒店数据。

用户补充26.3 Locators/Notes链接后，已取得两页正文并补充对照：Locators是临时位置，Notes可辅助显示Tour Code；Notes正文写读已有明确comments路径，其他备注属性并未全部显式接入。记录页面2000单字节字符与本地16000字符校验差异，REST硬限制尚未证实。仅更新候选证据，不改变原TA方案或代码。

2026-09-18 FIT TA 找到官方外部参考号类型证据

用户要求再查 Oracle 官方；新增数据字典第718页证据将 TA 明确关联到 EXTERNAL_REFERENCE_TYPE='TA_RECORD_LOCATOR'。现有 Reservation 新增/修改/详情均有 externalReferences，候选为 idContext=TA_RECORD_LOCATOR、id=Tour，但特殊类型可写性与真实回查仍未证明；正式守卫保留，暂不需新包接口。准确路径和下一核对点见专项查证。本轮只改证据/状态文档，无酒店调用、代码/模拟器修改或新代理。

同日继续核对：Oracle26.1缺陷说明38561498直接佐证 post/putReservation 处理外部参考号 id/idContext；现查平台0.11.0公开契约仍具备四个操作及详情 fetchInstructions 白名单。特殊TA取值依然没有直接写入样例；已在专项文档写明下一步由用户/平台执行的单笔只读 GET 和最小脱敏材料，未操作真实预订。

用户再次截图澄清后，按 Stay Details 输入框复核26.3操作手册与修复说明，仍未取得直接REST映射。External References是另一页面入口，后台候选不改变用户操作目标。已把数据字典证据及精确候选同步至未发送的技术询问草稿；下一步仍为用户/平台查询一笔已有TA的测试FIT，不能把重复公开检索称为已接通。此轮仅改文档，业务代码、模拟器与运行状态不变。

2026-09-18 无人值守参数接口与模拟验收

按用户要求完成可核实参数接入及严格模拟目录，不上传文件、不建代理、不动原服务。公共184目录与消费端18项路由/查询白名单匹配；全部45个官方Property模块仍不足以证明FIT TA写读，正式FIT/GROUP→FIT阻断保留。修复GROUP附件残留、Actual分列混淆/查询类别、FIT取消历史和转换Guest首次准备；47参数场景（45完成/2预期零写拒绝）及3类取消故障通过，后端2669通过/17跳过。见交付、证据。现有运行入口未更新，实际操作仍由用户执行。

2026-09-17 正式取消／类型转换入口已接入，FIT TA 仍待权威字段证据

正式 Factory/Runtime 已连接源 Allotment 取消和受策略开关控制的类型转换；旧对象与新建准备检查点原子保存，每次取消前校验最终参数/配置。FIT→GROUP 已作正式入口隔离验证，同类型 GROUP 仍走 UPDATE。GROUP→FIT 与 FIT NEW/UPDATE 继续在写入前拦截；本轮重查 Oracle 26.3 / 未变化官方提交，仍缺 TA 的 REST 写读映射，不把搜索/GraphQL字段冒充写入证明。配置模板及用户操作项见交付，最终测试见证据。没有操作运行服务、现有数据或酒店。此节覆盖下方“正式装配尚待”的旧结论。

2026-09-17 已落实无酒店附件执行及平台契约差异

本地代码已对齐下一状态路径、取消 201、房量分页及 2xx 待核验；四流程/确认计划/前端不再依赖酒店附件，邮件原件与历史审计保留。旧含附件任务拒绝静默续办。相关后端、前端、模拟器测试和编译已通过，最终全量记录见证据。原运行服务/数据没有更新，七封 EML 全链未完成；FIT TA 与正式取消/类型转换装配仍待，详见交付及用户步骤。此节覆盖下方“代码未改/附件仍待实现”的历史状态。

2026-09-17 平台复测成功取得 0.11.0／184 项

沿原地址重试成功，5 核心 + 3 建议只读全部已发布，完整 OpenAPI 引用解析通过；覆盖下方“无法核实新版目录”的旧状态。连接仍间歇超时，/healthz 200、/readyz 曾 503 not_ready，不能称业务已接通。当前消费代码至少需对齐下一状态路由、FIT 取消 201、2xx/pending_verification；另有取消附件要求和 FIT TA 缺口。详见最新复测证据。只读查证，未修改代码、权限或运行环境。

2026-09-17 平台称已补接口，本次连接检查未到 HTTP

用户通知平台已封装并要求试用。原地址 https://ohip.nianxx.cn 的 health/ready/catalog/OpenAPI 均超时，两个 DNS 地址的 443 建连分别失败；同机 Oracle 官方文档返回 200。本轮未拿到新版目录，5 个核心接口的发布状态尚无法核实，不再把旧目录缺项当当前结论。见检查证据。待确认发布地址/HTTPS 可达后续验契约与只读调用；未操作酒店、凭证或运行环境。

2026-09-17 最新范围：取消酒店 Excel 附件上传

用户取消 GROUP/FIT Oracle Attachments 上传，保留邮件解析、TA=Tour Code 与 FIT Note。平台清单已从 10 核心改为 5 核心（客档、房量、下一状态、Block 状态、FIT 取消），3 个建议只读不变；附件 linkType 退出待查项。见最新清单。此范围优先于下方历史附件待办。候选代码仍含附件流程，后续需移除调用依赖、完成条件及对应回显；本轮只改文档，无服务或酒店操作。

2026-09-17 公开字段证据由本项目完成

用户指出平台同事同样只能查公开资料。本轮已补完官方样例复核：FIT Note 采用 comments 数组、GROUP 日期采用 YYYY-MM-DD；Reservation 附件类型有官方样例，普通 Excel 行为仍待验证。当前明确缺证据的是 FIT TA 写读路径和 Block 附件 linkType，不能要求同事重复相同检索。已修订平台清单与参数表，见公开证据。没有运行操作。

2026-09-17 已交付给平台同事的补封装清单

用户将自行联系平台同事。已核对 Oracle main 与 Edge 0.10.0/176 项，交付10 个核心接口、3 个建议只读及字段缺口。未发送外部消息或操作运行环境；接续先取得平台最终契约及 FIT TA/附件绑定等证据，仍按用户要求逐层确认。详见本轮证据。

2026-09-17 当前先核对参数对应接口

用户要求逐层确认，运行更新和模拟数据准备暂不推进。已形成逐参数映射，核对原生字段与最新 Edge 0.9.0/158 项目录；明确 FIT TA、附件 linkType、契约示例差异及部分平台缺项。Account/Contact 接口已定位；GROUP UPDATE 不新增 Rate/Note 修改范围。只读契约核对，没有操作酒店或运行环境。见证据。

2026-09-17 七封对应执行代码已补全，后续操作由用户执行

本节优先于下方早期“尚未实现/禁止任何子智能体”的交接。已实现类型转换先取消后新建、源 Allotment 取消、FIT 房型增减及页面说明。隔离确认快照矩阵 30 个合成前态与 43 个自动事项通过；这不等于 EML 上传/解析/确认全链通过。原 5178/8082 后端与原模拟取消能力未加载新代码，运行更新和原环境前态准备步骤仍待交付。上传、确认、续办、重启、数据准备均由用户操作，Agent 只给明确步骤。仅获准的一个模拟酒店子任务已完成，无新增代理许可。验证细节与剩余范围见证据。

2026-09-17 七封 EML 全量分析完成，已允许本地开发

用户已解除本阶段“只分析、不动代码”的暂停，明确“继续，可动代码”，正在选择是否转入新对话。完整接续已保存于本机忽略文件 .planning/booking-seven-eml-handoff-20260917.md：含逐项来源/拟模拟前态、11NEW/28UPDATE/4正文取消/2加床人工、26旧预订团号与4源Allotment、关联测试顺序、FIT↔GROUP先取消后新建的酒店确认规则及代码缺口。此套数据尚未建立，新增缺口尚未实现，七封邮件尚未全量执行验收。 仅本地开发与模拟；禁止扩范围、子智能体、推送、部署和真实酒店操作，保留当前未提交修改及用户测试数据。交接准备仅写文档，没有重启服务或重放业务。

2026-09-17 确认参数与实际结果并排核对

针对用户“看不出最后执行参数”的反馈，AI处理已直接显示失败位置，并提供确认值/实际状态及酒店返回值对照；回执与查询区分、多个FIT编号保留、调用显示当前页读写数量和明确搜索结果。相关73项、类型/零错误lint/构建通过，原5178页面已核对；指定修改任务仍因找不到原团而未保存，没有重跑或补造酒店数据。见本次证据。

2026-09-17 AI处理直接展示确认值与附件

用户批准的核对展示已接入任务详情和预订记录：常显当次确认值、逐住期房型房数、可下载Excel/预计上传位置与名称；实际调用常显用途、接口路径和关键值，附件返回元数据也直接展示。准备值、实际发送、回执与查询结果分开；历史Basic取原任务，避免用最新记录覆盖旧确认。保留当前用户新测试及模拟酒店，无业务重跑或后台重启。见核对展示证据。

2026-09-17 当前测试历史与模拟酒店已清空

用户明确要求“一起清空，重新测试”。原5178/8082工作台已清空11封测试邮件、47张任务卡、8条预订记录及关联AI/接口处理历史；模拟酒店也已换为空实例。接口和页面核验为空，账号权限、房型房价、Agent设置及当前CP33程序保持。旧模拟服务已停止。以下CP31–CP33“保留历史数据/原模拟酒店”的记录描述清理前状态；当前入口及恢复依据见清理记录。下一步由用户重新上传邮件测试。

2026-09-17 CP33 本机酒店候选目录

本机模拟执行目录已补齐用户确认的10房型、21房价码及其余候选，准确匹配旅行社与联系人关联，实际调用记录新增明确标注的目录说明。41项前端、类型/lint、本机目录与记录权限检查通过；原5178/8082受控加载，58H2/24PG内容、环境身份及模拟酒店进程保持，无历史重办。已核对CRM/BLK/RSV角色区别；真实账户关系查询未UAT，不冒充接口已查到真实编号。见CP33。

2026-09-17 CP32 每笔预订接口核对已加载

原工作台每笔 NEW/UPDATE 预订新增“预计调用的接口”和本机实际调用核对，区分预览、HTTP回执与最终业务完成；发送值取自已序列化请求，历史缺失不补造。隔离FIT新建/修改的93/175次调用和发送字段已核对，347项前端/2672项后端零失败（17项条件跳过）；原5178/8082已加载，环境、身份权限、58 H2/24 PG表保持，原模拟酒店服务保留。未推送/部署/创建代理/操作真实酒店，原失败任务未续办。见CP32。

2026-09-17 最新完整代码提交检查

按用户最新指令整理本项目代码至唯一正式远端main；本次指令授权代码推送，不包含线上部署或其他仓库发布。完整候选快照独立验证：前端333项、类型检查及production构建通过；ESLint零错误（420项格式警告）；后端2665项中2648通过、17条件跳过、零失败/错误，verify成功；脚本80项与模拟器25项通过，凭据扫描通过。见提交验证。CP31本地/真实Oracle验收边界保持。

2026-09-17 CP31 本机四流程与原工作台入口

本地 GROUP / FIT 新建和修改执行链均已验证，失败、实际查询不一致及原确认续办有证据；正常 Maven jar 保留真实 TA 未核实保护，测试专用装配已加载原 5178/8082。原环境/身份权限、58 H2/24 PG 表及 38 待确认/7 确认保持，无历史重入队。完整2665项零失败/错误，17条件跳过（随后GROUP条件用例单独通过）；前端24/类型/lint和Python25通过。EML原入口全部就绪，但本轮未运行识别Agent，不宣称EML全链实际跑过。最新用户禁止扩范围和创建代理；已停两名活动代理，根任务独立完成。未推送/线上部署/真实酒店写入。 见CP31。下一步由用户在原入口上传 EML 验收；真实 Oracle 契约/环境验收属于后续范围。

2026-09-17 TA界面与缺值规则确认

用户截图确认字段为 Stay Details → TA Record Locator；每笔预订有Tour Code则原样填，没有则不填、不造值。规则已入Domain；本轮仅理解及记录，尚未修改执行代码或进行酒店操作。下一步本机模拟覆盖有值/无值的填写与查询显示；不得因TA缺值本身报错，但其他预订身份/匹配/附件条件仍分别核验。准确Oracle路径仍未建立。

2026-09-17 CP30 TA缺口重新定位

平台公开 FIT 新建/修改/查询存在，本地候选保存及读回原始 JSON，无TA专项过滤/映射。Oracle主分支已更新，但rsv.json字节未变；准确写读仍未建立，不能写成“平台没有”或“Oracle不支持”。只读研究，无代码/运行/酒店变化。本机模拟目标可独立推进FIT业务验证，真实映射仍待有据样例，不解除真实入口保护。下一步FIT两流程模拟、失败页面验收及稳定入口。见CP30。

2026-09-16 CP29 本机页面完整串联

用户要求先本机拉通，当前不推送/不线上发布，取代 CP28 发布优先顺序。GROUP NEW/UPDATE 已经员工页面一次确认→真实 Java/Go/独立 PG→模拟 Oracle→最终查询回显；附件失败/重启续办通过并修复原因丢失。日常 5178/8082 已由原 launchd 加载最终新版，完整配置/酒店权限、58 H2/24 PG 表核验一致，38 待确认/7 确认保留；OHIP 默认关闭，未补办旧确认。完整 2654（2637 通过17条件跳过无失败），前端23/类型/lint通过。FIT 新建因 TA 缺口前置失败，同团修改等待，真实 Oracle 仍 0/4。下一步 FIT 准确契约及本机两流程，再安排 Oracle 测试环境验收。见CP29。

2026-09-16 CP28 平台合并发布包

本地候选0.9.0/123/14已保留线上115及补齐8项，并同步远端新房价接口；独立PG/race139顶层（569含子项）零失败零跳过、Node12与程序包升级/重启/权限通过。v8不能直接退回旧v7程序，说明已修正。源码和程序摘要已固定，未提交推送/部署或操作酒店；默认Pending、真实四流程0/4。下一步实际发布入口与环境配置/权限、FIT TA契约及指定测试数据验收；见CP28。

2026-09-16 CP27 配置加载与统一分派

已完成本地统一入口：严格部署清单/唯一酒店环境/确认Account分派/同源专用仓库。原checkpoint包含运行摘要，原配置恢复、换配置停发，未知结果不误作未发送。新增70项，完整2625（2609通过16既有条件跳过零失败错误），1名授权只读复核的发现已修复。默认Pending，FIT两流程因TA契约缺口前置拒绝；没有实际迁移/启用/酒店调用。下一步平台候选发布准备和目标环境配置/权限，FIT准确契约，MySQL/Oracle验收仍待。见CP27。

2026-09-16 CP26 FIT TA与联调差距重新核验

公开平台仍0.7.0/115项，本地候选0.9.0；项目21项操作中8项尚未见公开目录（客档创建、团队房量写入及6项附件），候选元数据全部匹配。Oracle main仍同一26.3提交，FIT TA搜索有契约、准确写读路径未建立，不能拿Custom/GDS/External Reference代替。四流程候选未注册为运行Port、受信环境配置加载仍待；原件读取服务已有。1名获准只读复核完成。无业务代码/运行变更，未重复全量测试，默认Pending。下一步先推进受信配置加载/四流程统一装配的本地准备，同时补TA权威契约和平台发布准备；见CP26。

2026-09-16 CP25 长阶段执行本地完成

四条候选链共用worker已增加2分钟存活/30秒续期/30分钟阶段上限，续期不改变原确认或查询事实。锁等待后不能复活或报完成，HTTP实际派发前再查中断/短许可/硬截止；超时保留事实供原确认续办。新增30项后端、相关1127项及页面23项通过；完整2555项（2539通过16既有条件跳过零失败错误），类型/lint通过。1名获准只读复核发现已修正。V52未实际迁移，默认Pending；下一步FIT TA准确字段、目标环境业务语义、平台/权限/配置和MySQL/Oracle验收。见CP25。

2026-09-16 CP24 FIT修改候选链路

已接原确认及实际Reservation全集、V51不可变修改计划、日期/房型房数/Rate/原Note一次PUT、CP18整组Excel和最终逐项查询；SAVE_ROOMS不重复写。中断按当前查询与已知回执继续，未知不重发，附件发送前同锁复核前置更新。新增40及相关1097项通过；完整2525项（2509通过、16既有条件跳过、零失败错误），233份XML。默认Pending；TA recorder、原生最小PUT/日期/减房行为、长阶段预算及平台/配置/MySQL/Oracle验收仍待。本轮独立完成，未新建代理或操作真实酒店。见CP24。

2026-09-16 CP23 FIT修改对应与字段本地完成

已补实际Reservation全集与完整新房量的一对一检查、日期/房型房数/Rate/原Note最小请求及七项实际读回。原备注标题/通知位置/语言也纳入保留检查，日期与房型线索冲突不猜对应。新增88/相关1057通过，完整2485项（2469通过16条件跳过零失败错误）。当前是纯准备组件，默认Pending；下一步FIT UPDATE持久计划/worker/CP18附件与恢复、FIT TA及目标环境验收。代码独立完成；用户收尾时批准1名只读契约复核。见CP23。

2026-09-16 CP22 GROUP修改链路本地完成

已连接实际Block绑定、修改前资料/旧附件来源冻结、日期与完整房量更新、整组Excel替换及最终查询。V50固定原计划和请求；39项新增、1018项相关通过，完整2397项（2381通过16条件跳过零失败错误）。首次查询失败续办、状态变化、未知回执、并发和租约均有测试。改日期需目标环境验收后显式开启策略，默认Pending；无真实业务/迁移/启用/部署。下一步FIT UPDATE、FIT TA、长阶段预算及平台/配置/MySQL/Oracle验收。见CP22。

2026-09-16 CP21 GROUP新建完整链路

本地已接基本资料/实际Block、房量持久请求、整组Excel及最终逐项查询，本地验证完成：新增45/相关930项后端、前端24及类型/lint通过；完整2358项（2342通过16条件跳过零失败错误）。实际NonElastic及显式Category/Occupancy Split为范围前提，不能把默认值当环境配置。FIT后台最终检查/三语提示中遗漏的Meal要求同步修正。默认Pending，无真实业务/迁移/启用/提交部署。下一步UPDATE、长阶段预算、FIT TA契约、平台/配置/MySQL/Oracle验收；见CP21。

2026-09-16 CP20 GROUP基本资料本地完成

已补GROUP NEW有据头字段、实际13项逐字段回查及CP12创建恢复衔接；FIT餐厅不再作为酒店待办，不造早餐查询事实。用户已明确酒店只选Rate；GROUP Breakfast Included继续独立核对。新增55/相关236通过，完整2313（2297通过16条件跳过零失败错误）。默认Pending，无真实业务调用/迁移/启用/提交部署。下一步GROUP全流程（房量、附件、最终回显）、GROUP/FIT UPDATE、长阶段预算及平台/MySQL/Oracle验收；FIT TA写读仍无准确契约。获准1名只读研究已结束，新增代理仍先问用户。见CP20。

2026-09-16 CP19 FIT后台接续本地完成

FIT NEW显式执行端口已把CP14/12/15/18接到实际worker；新增逐项事实、部分完成可继续证据、页面三语展示。相关186项、页面17项及类型检查/lint通过，完整verify2258项（2242通过、16条件跳过、零失败错误）；不是四流程全部完成，默认Pending未启用。下一步TA/Meal实际字段与GROUP/UPDATE编排、长阶段预算、平台发布/真实迁移/Oracle UAT。见接入。

2026-09-16 CP18 多Excel整组附件本地完成

多Excel整组NEW/UPDATE已本地实现：冻结序号/原件/请求，全部新件逐份核实后精确清理旧组，覆盖多变少和单多互换，保留无关附件与中断成功事实。相关231及完整2231项验证通过（16条件跳过），最终85项新增测试通过（含两份不同内容原件分别上传）。平台集合删除race/vet通过。默认Pending，V48/平台候选未部署；完整业务执行与最终回显、TA/Meal/实际库和Oracle UAT仍待。见CP18。

2026-09-16 CP17 附件恢复完成，多件规则已确认

UPDATE末次校验错误和来源不可用丢成功记录已修复，17新增/200相关通过；完整2148项2132通过16条件跳过零失败。用户允许多份附件Name用Tour Code＋序号、Description仍Tour Code、单份不变；下一步多Excel完整集合上传/替换，需含多变少及单多互转。官方只读代理1名已完成；Oracle同名并存无明确契约，平台公开附件操作本轮404。默认Pending，无真实操作/平台修改/部署。见CP17。

2026-09-16 CP16 新建附件本地完成

NEW单Excel与实际完整父编号衔接已完成，部分上传成功后中断、未知回执、并发与受控重试均本地覆盖。新增48/相关247通过；完整verify2131项、2115通过、16跳过、零失败。默认Pending，无真实业务/凭据/迁移/重启/平台修改或提交部署。只读代理1名已获准并复核结束，增加代理仍先问许可。下一步完整办理及最终实际值回显、多Excel和其余原生契约；见CP16。

2026-09-16 CP15 FIT字段本地完成

FIT NEW日期、房型房数、Rate、Account、Market/Source、GC、BTQR、adult=2、Fixed rate、共享Guest、原文Note已构造并逐字段回查。H2+localhost已接续一Guest→两Reservation→精确读取，配置变化被原创建清单拒绝。88项转换测试加1项接续测试通过，完整2083项无失败（16条件跳过）。默认Pending；继续处理完整流程接续与TA/Meal/附件/原生部署UAT缺口，不能称四流程完成。见CP15。

2026-09-16 CP14共享客档本地完成

CP14共享Guest保存/恢复及CP12多笔FIT接续本地完成，V46未迁移实际库，默认Pending。新增46/相关167通过；完整1994（1978通过16跳过零失败）；平台race12包/vet通过，9数据库条件跳过。普通getProfile固定取Profile/Address。当前没有等待用户决定的产品问题；代理询问未获答复，未创建。下一步完整FIT NEW参数构造、附件/Note/最终回显及运行联调；见接入。

2026-09-16 CP13客档与多房本地完成

Guest建档平台/消费协议及普通FIT多间映射本地完成：CP12“每行count=1”临时限制现由正数numberOfUnits=确认数量替代，仍需已备共享Profile，不主动拆房/取消。相关162和完整1948通过验证（16条件跳过），Go完整/race/vet通过（9数据库条件跳过）。平台候选0.9.0本轮未提交/推送/部署；运行Pending。下一步Guest编号持久归属/共享及全流程查询回显；见契约。

2026-09-16 CP12新建编号与恢复本地完成

NEW现在先保存完整创建清单，再逐笔查询真实Block/Reservation并追加编号绑定；中断先查、未知不重发、部分成功保留，不把编号齐全判作整单完成。新增48项/相关154项通过，完整verify1,895项（1,879通过、16条件跳过、零失败/错误）。当前仅支持FIT每房型行数量1，多笔须已备同一Profile；多间展开尚待原生验证。默认Pending、无真实酒店调用或运行变更。下一步共享客档/多房契约、完整业务写入与最终回显衔接；见契约及证据。

2026-09-16 住期与房型布局纠正

按用户纠正，四个房型字段改为各自带标签的独立字段行，12px列间距；移除连续表头及整段外框，住期标题缩为文字宽度的小框。日期11px样式保留。实际New/Update、单/多房型及待确认页面核对通过，97项相关测试及类型检查通过。见证据。

2026-09-16 预订日期显示统一

Arrival/Departure原内部日期输入沿用16px默认样式，现共用预订卡片11px字段样式及38px高度，编辑/只读颜色对应一致，保留日历图标空间。5178实际待确认和已确认页面计算样式核对通过，8项相关测试及类型检查通过。见证据。

2026-09-16 预订记录参数回显修复

已确认记录原来直接传普通键快照给读取字段指针的投影卡，造成Rate、Breakfast、日期房型及姓名空白。现在从已确认快照提供相应字段值并保留数组；只读选项包含实际保存值，目录变化或人工改餐食不会遮掉历史值，编辑选项范围不变。新增4项完整记录页回归，相关113项测试和类型检查通过；5178实际New/Update记录分别回显WHO1/GRPA1及Included/BUALUANG、房型房数和FIT姓名。见证据。未修改保存数据或执行业务确认。

2026-09-16 附件替换与续办CP11本地完成

已固定保存旧件清单和本次Excel摘要，连接单Excel UPDATE的覆盖上传、实际子ID查验及精确旧件清理；同ID不删除，未知结果不重发，成功回执与当前查询分开。新增47项/相关167项通过，完整verify1,847项（1,831通过、16条件跳过、零失败）。当前仅支持每邮件一个Excel、各父对象唯一已证明旧件，可含多个FIT父对象；多同名Excel尚未覆盖。默认Pending，未迁移/加载/操作酒店。下一步NEW实际父编号绑定及完整执行/回显，见接入与证据。

2026-09-16 查询提示与自动刷新一致

提示更新为“正在查询办理状态，页面会自动刷新”，保留13px斜体；为使提示符合实际，首次或后续查询失败时也按原4秒间隔自动重查，仅刷新状态、不触发业务重办。查询到成功/失败/没有自动办理记录后停止，离开页面取消。102项相关测试、类型检查及5178实际文案/样式验证通过。见证据。此条替代此前首次查询失败必须手动重查的状态。

2026-09-16 AI处理标题与查询提示

用户将结果卡标题进一步精简为“AI处理”；查询提示统一为“正在查询办理状态”，正文只显示一次，使用与Note值相同的13px字号、斜体、常规字重。三语同步，98项相关前端测试及类型检查通过，5178实际页面和计算样式已确认。卡片置底、确认后定位及自动刷新规则保持。见证据。下方旧名称条目为历史。

2026-09-16 AI员工处理结果置底与确认定位

New/Update结果卡已移到来源邮件下方，确认前隐藏；确认成功后在原页面立即定位到结果卡，确认失败或已经离开页面不会定位。预订记录详情同样置于来源邮件后；确认提示改为“卡片已确认”（三语同步）。98项相关前端测试、类型检查通过，本地已确认记录实际卡片顺序已核对。见验证。未执行实际业务确认或创建子智能体。

2026-09-16 处理结果区域名称统一

现有结果区域已按用户要求更名为“AI员工处理结果”，三语标题同步，5178实际页面确认生效。用户认可从预订记录查看成功/失败的操作记录；本轮仅完成名称修改及说明后续具体页面内容，没有接通真实酒店执行或查询。见记录。

2026-09-16 旧件证据匹配CP10本地完成

完整同业务历史、实际Note回执子ID、当前附件字节/Note内容双轮核对已连接；错源/无根/历史超限或变化/未解决写入拒绝，不按名字或最后回执选旧件。新增62项/相关158项通过，完整verify1,800项（1,784通过、16跳过、零失败）。平台候选补写后显式Comments查询，Go race/vet通过，56bbe86已推候选分支但未部署。消费运行仍Pending，未操作真实酒店或迁移数据库。下一步实际替换与续办、NEW关联及最终回显，匹配结果不直接授予删除权。见接入及证据。

2026-09-16 调用来源证据CP9本地完成

发送前将冻结邮件Excel引用/实际字节摘要或最终Note原文摘要与调用一起保存，记录酒店/环境、实际服务地址摘要、团号、父ID及请求Note ID；来源不可换绑、旧NULL不补认、迟到回执不覆盖。新增43项/相关143项通过，完整verify1,738项（1,722通过、16条件跳过、零失败）。真实端口仍Pending，未迁移实际数据库/调用酒店/重启。下一步历史来源与实际子ID/内容读回结合，解决旧件精确归属，再接完整执行；不把请求Note ID或来源记录当替换权限。见接入及证据。

2026-09-16 修改前资料只读观测CP8本地完成

新增已绑定对象的实际资料读取：GROUP原日期/肩期及两类房量页、FIT逐筆住期/房型房数/Rate/客档ID/Note、各父对象附件清单。双轮提取值变化或不完整即拒绝，不补零或自动选删。新增47项/相关155项通过，完整verify1,695项（1,679通过、16条件跳过、零失败）。仍不构造完整ExistingBooking，真实办理保持Pending。下一步完整旧范围及旧Note/附件精确对应、实际执行和最终回显；见接入与证据。

2026-09-16 UPDATE目标持久绑定CP7本地完成

实际Block/完整Reservation集合已纳入原确认的后台进度，失败、重启、续办和旧构造器均保留；库内完整快照/进度及发送台账双重校验，目标增删换或错类型附件父对象拒绝。缺目标在查询环节失败，可补齐后续办，不误记为写入。新增33项/相关105项通过，完整verify1,648项（1,632通过、16条件跳过、0失败）。真实端口仍Pending，无酒店调用/重启；下一步完整旧资料、NEW回执关联及最终字段核验。见接入和证据。

2026-09-16 实际预订目标识别CP6本地完成

新增完整搜索＋逐对象详情＋二次搜索一致性核对，GROUP名称精确唯一、FIT收齐实际Reservation集合并明确TA仅有筛选证据。39项新增/100项相关通过，完整verify计数见证据。没有真实酒店业务查询/写入、运行接线或服务重启；TEN配置查询仍403。下一步完整旧范围、持久目标检查点和最终业务核验，身份识别不代表整单已可执行。见CP6接入。

2026-09-16 测试配置补齐路径已核实

用户列出的四个状态查询/新增/修改/流转接口均在线，另有getNext；均为集团级配置。GC、GTT/X、Source TA也已有酒店级新增接口，缺值不等于接口缺能力。TEN实际查询仍因应用权限403，存在性未知；无Automation身份，未写配置。配置维护按组含49项，不能擅自扩权。先查现有定义、缺失才按批准范围补齐并逐字段读回；BTQR当前仅有查询。继续消费端实际对象绑定与完整查询，见核对及执行顺序。

2026-09-16 酒店逐次调用CP5本地完成

新增V42逐次写调用记录和OHIP持久发送衔接，发送前核对库内确认/环节/租约、记录固定摘要，返回后保存实际对象及独立新附件编号。并发与重启不重发未知请求，仅明确NOT_SENT可在新attempt用同键继续；真实worker＋HTTP模拟验证创建一次、续办先查。新增20项/相关128项、完整verify1,576项（1,560通过、16条件跳过）通过。默认Pending不变，未加载或写酒店；平台仍111项，本机无Automation Principal，发布/配置权限前置保持。继续真实对象绑定及全流程核验。见接入及证据。

2026-09-16 测试酒店配置已实际读取

OHIPSB02完整列表未返回GC/GTT/X/Source TA/BTQR；TEN查询因应用缺configuration.read返回403，存在性未知。房型两页88项读取完整。仅只读，不改变工作台规则或正式酒店配置，不代换代码、不扩权或写酒店；真实测试前需准备对应测试配置。见证据与继续点。

2026-09-16 GROUP完整房量CP4本地完成

消费端已把完整房量规划转成固定原生请求，核对新旧范围清零及四人数列，并从实际分页结果逐格比较。新增36项、相关97项通过，后端verify1,556项（1,540通过、16条件跳过、0失败）。真实办理Adapter未替换，未重启或调用酒店；线上最新仍0.6.0/111项，已推送的118项平台候选尚无部署通道。继续可信执行适配、完整改期/范围与专用测试对象验证。见接入及证据。下方旧条目为各阶段历史，不能据其“未授权发布”重复索要技术许可。

2026-09-15 附件CP2-C本地完成

六项附件固定调用、实际字节和对象核验、精准旧版删除及消费证据校验完成。平台本地0.8.0/118项/13组，线上本轮仍0.6.0/111项；无发布或主线接线。消费完整verify1,454项（16跳过）、平台Go/vet/build/JS通过，DB条件测试跳过。真实linkType/界面Name/覆盖与并发行为、迁移、FIT TA写入和四流程最终执行仍待验。见交接和证据。

2026-09-15 GROUP房量CP2-B本地实现及测试完成

平台独立Feature分支新增每日房量写入与逐项分页读回；消费项目同步固定调用及实际页回执。平台新房量58场景、全部Go检查/构建及6项JS测试通过；消费端41适配器测试、完整verify1,436项（16跳过）通过。本地目录0.7.0/112项尚未发布；线上最后已知仍0.6.0/111项，没有执行酒店或接线工作台。改期整体、附件、FIT TA及Oracle真实测试待后续，见交接和证据。下方“平台源码未修改”属于CP2-A历史，原只读克隆仍干净。

2026-09-15 OHIP现有接口适配CP2-A完成，仅本地HTTP验证

已只读核对用户提供的平台源码，确认缺口确实存在；消费端新增13个固定操作的HTTP适配、真实确认引用外层和单步结果分类。36项新增测试、完整verify1,431项（16跳过）通过。没有注册执行器、接线工作台、加载服务、配置真实凭据或调用酒店；平台源码保持干净。技术事项按用户最新委托自主推进，产品不确定项再询问。见交接及证据。下方“待源码/CP2未开始”为此前阶段记录，已由本段接续。

2026-09-15 OHIP四流程CP1仅离线规划完成

后续公开接口复核：北京时间21:42仍0.6.0/111项，无目录变化；已形成平台联调交付清单，明确房量、附件、FIT TA写入及现有接口待验样例。当前待平台源码目录/仓库或维护方式；CP2未开始，CP1测试结论保持。复核依据追加在下方同一CP1证据中。

用户同意首阶段代码后，新增确认快照转换、完整房量/多笔FIT范围规划和Oracle正文草稿；GC、人工最终资料、Note原文及逐对象旧附件规则已覆盖。17项新增测试通过，后端verify成功：1,395项、16条件跳过、0失败/错误。没有接线工作台、注册执行器、加载服务或调用酒店；房量/附件/FIT TA字段、餐食和多房实测及BLK日期定义冲突待后续验证。见交接及证据。

2026-09-15 Meal独立下拉选择已生效

New/Update可独立选择含早餐/BUALUANG、含早餐/LEELA或不含早餐；识别及Rate默认预填保持，人工餐食随确认保存。301前端、78后端及类型/构建和实际页面通过；8082已加载PID6101，5178和配置/数据保持，无真实确认或Agent。见证据。

2026-09-15 Basic默认选择修正已生效

按最新纠正，LianTai/QBD自动选择目录已有公司全称；Group默认GTT、FIT默认X，不增加Account选项。301前端、类型/构建及实际LianTai Group New和QBD FIT Update通过，5178已生效。替代下方初版要求重新选公司的规则，历史只读及原始识别保持。见最新证据。

2026-09-15 Basic Information移除三个Account选项

按用户截图移除可选HANATOUR_TD、LIANTAI、QBD，保留其他项。旧可编辑默认值需重新选择，历史只读值保持；当前New/Update页面及两项选择已核对，297测试、类型/构建通过，5178已生效。仅前端变化，见证据。

2026-09-15 Note价格改为可编辑默认值

按用户最新纠正，TA/RB下拉保持，价格文本框默认识别金额并可修改；确认保存人工价格，原始换算值保持。297前端、69后端及类型/构建通过，实际New850→925.5、Update1200→1300与窄屏检查通过。新包已加载8082 PID2946，5178和配置/数据保持；无真实确认、回放或Agent。见最新修订证据。

2026-09-15 预订人工下拉修复已加载

New/Update已有卡片刷新后可选择当前酒店全部启用基础Rate和房型；实际21Rate/10房型已核对，Meal随Rate带出早餐/餐厅。确认校验可信目录并保存快照，支持原匹配外的合法选择及历史重试。296前端、63后端及类型/构建通过；8082 PID2327新包已加载，5178、配置及两库指纹保持。Note与自动匹配保持，无真实确认或Agent。见证据。

2026-09-15 待确认预订 Note 已实现并加载

New/Update来源邮件上方新增紧凑Note，默认TA/RB，分别支持TA/CL/GA与RB/RO；一卡一个换算价格，选项及完整Note随确认保存并在预订记录只读显示。实际New的8.5→850、Update的12→1200已验证；无价格标记的卡片显示“—”。294前端、69后端及类型/构建通过，当前5178和新8082包已生效、配置与数据指纹保持；无真实确认或Agent调用。见实施证据。

2026-09-15 四份新实跑通过，包装/FIT姓名/加床人工均获验证

LT3/QBD4/QBD1/QBD3全部完成，35事项与旧同原件业务保持，仅15FIT按授权补姓名；0解析拒收/复核/阻断。实际33任务卡＋2加床通知完整，LT3两加床团各2张床；三份带空数组说明的原答由新包装接收成功，旧接收类同答失败。QBD4红叉取消及13项表格AMD保持。QBD3约6分51秒但成功，本轮不推进提速。仅核对与文档，无代码/配置/服务变化。见本批证据。

2026-09-15 加床提示进一步收小

按用户“不要扎眼、简洁小巧”的要求，提示采用细边框、14px无底色图标、13px文字，团号与说明并排，窄屏自然换行。用户随后指定浅蓝色与斜体，最终使用浅蓝背景、团号和说明均斜体，小巧尺寸保持。实际页面桌面高度约41px，375px视口约62px且无横向溢出；78项相关测试、类型/构建通过；后续配色斜体另经构建与实际页面验证。当前5178已展示，后端无需变动。替代下方旧版大卡片样式，见追加证据。

2026-09-15 加床提示文案及样式已加载

按用户原文改为“该Tour Code涉及加床，请人工处理”，保留团号，采用16px标题、14px正文和浅蓝提示框。91项相关前端测试、类型/构建通过，实际通知页面已验证。8082 PID97281同包、5178 PID97308重启健康；配置/数据及业务逻辑保持。见追加证据。

2026-09-15 LT1外围说明兼容修复已加载

用户授权后，仅修正明确JSON围栏外方括号说明误拒绝；额外对象/围栏、内部Schema/来源校验保持。102项相关测试通过，失败完整原答恢复两修改，15份原答结果保持；包仅接收类和构建信息变化。8082 PID96417、5178健康，配置/数据保持，无在途查询/真实调用；无需替换Agent配置。见实施及加载证据。

2026-09-15 LT1失败已定位：既有回答包装误拒绝，尚未修复

最新复测在Parsing交接失败；Agent单一JSON前的说明含空数组字段记法，被既有外围括号检查误拒绝。修改前/当前运行包使用同请求同原答均复现，纯JSON均可恢复两个修改任务，排除最新加床与姓名改动。仅诊断，产品/配置/服务保持；后续候选修复仅限包装识别且保留全部字段与来源校验。见诊断证据。

2026-09-15 加床整团人工与FIT补姓名已加载

用户澄清加床Tour Code全部相关任务人工；当前同邮件该团号（跨附件、关联取消）汇入一条人工通知，其他团号保持。FIT确无姓名时以Tour Code补Name1，已有姓名和原来源保留。后端1332通过/16条件跳过、前端91项及类型/构建、15份旧输入110业务对照通过。新包已加载8082 PID95435，5178健康与能力配置保持；无在途查询、数据清理或真实调用。Agent配置无需替换，等待用户完整复测。见实施证据。

2026-09-15 测试数据已清空，转入完整准确性复测

用户停止继续纠结速度，已按授权清除42封邮件/42次回放、240任务及任务卡、2确认、2来源通知、3失败提醒及两库全部关联测试处理资料。停机双库备份、事务预演回滚、正式清除和指纹核对通过；账号、业务目录、配置、Skill及原始测试文件保留。同V9包重启8082 PID93959，5178健康且各业务列表为空；未查询在途任务、未更改识别逻辑、未实跑新邮件。下一步由用户完整提交样本，核对识别/交接准确性。见清理证据。

2026-09-15 V9四组实跑：业务保持，提速未达标

LT3/QBD4/QBD1/QBD3均完成，35任务与逐项目复核保持；13处AMD仍修改，仅15项既有FIT缺姓名。两项LT3加床各2张，原文至确认一致。总耗时222.372/233.247/173.817/186.039秒，共同V7原件都变慢，首答前主要等待138至164秒；输入均紧凑，3份输出紧凑，QBD1围栏+present_files、LT3解释+围栏由既有容错接收。平台三份原答表达不同，另做35任务离线验证保持；系统计时独立。此次只读分析和文档，无代码/配置/服务改动。见核对证据。

2026-09-15 V9提示词去重已加载

用户授权合并重复说明；主提示词2081→185字符，Skill5317→3601，必要静态文件合计减少约17%。26份业务reference/Schema/fixture逐字保留，程序只改当前入口提示文字。77后端/32配置及11原答75任务离线回归通过；8082已加载PID90362、build_time 2026-09-15T03:56:13.250Z，5178及Parsing/V2就绪、配置与图片实现保持，无在途查询。桌面V9两文件已交付，平台替换与新Agent准确性/速度仍待用户实跑。见去重证据。

2026-09-15 V8紧凑JSON及结果复用已实施加载

按用户批准，仅当前标准分支去JSON结构空白，Skill/主提示词补复用已核对结果及紧凑输出；原业务条款、26规则文件和Schema保持。77项后端/32项配置、11份保存原答75任务及逐项复核保持。8082已加载PID88438、build_time 2026-09-15T03:16:32.994Z，5178/Parsing/V2就绪，既有图片实现及配置保持；没有在途查询。V8两文件交付桌面，Agent实际行为和速度待用户手动验证，未改状态归属/日期价格/正文历史/模型。见实施证据。

2026-09-15 邮件图片原位展示已实现并加载

用户确认正文图片保留原位置，支持放大、关闭和保存；任务/通知/Proposal/会话已统一，移除底部重复图库，独立图片附件仍可下载。精确图片引用关联及受控读取沿用原权限；已完成前后端及浏览器验证并加载8082/5178。Agent输入与业务处理保持。见本轮证据。

2026-09-15 V7实跑保持准确性，读取减少但总耗时未改善

最新四组实际为LT3、QBD1两次、QBD3，缺QBD4。系统共30项业务及逐项校验与V6保持，9处AMD仍修改，10项仅既有FIT缺Name1，0解析issues/拒收。必要规则各读一次，工具由5/5/5/6次降至3/3/4/3次；本批总耗时203.954/135.718/153.719/172.060秒，未见整体提速。平台时间及部分回答与系统不同，另做离线接收30项保持，计时采用系统原事件。用户已确认此轮无需补QBD4，后续单独定位读完规则后的112至173秒；本轮未改产品、规则或服务。见核对证据。

2026-09-15 当前源码发布验收基线

按用户要求整理正式main推送批次，包含截至V7的累计实现、测试及文档。隔离后端verify为1322通过/16条件跳过，前端281项、类型/规范/production构建及Agent规则检查通过；只同步旧阶段名称测试与Python缓存忽略规则，无业务改动或服务重启。提交范围与检查见发布证据。V7平台新实跑及实际提速仍待用户日志，不因源码发布扩大验收结论。

2026-09-15 第一优先级读取指引已实施并加载

用户已授权固定既有Skill路径和避免无关工具调用；V7直接读取公共规则、Schema及匹配渠道，允许失败/截断补读，全部业务规则及交接保持。61项后端/32项配置检查通过，七份保存原答45项业务与校验和V6实跑一致。8082已加载PID83127、build_time 2026-09-15T01:46:02.074Z，5178及Parsing/V2就绪，配置保留。必要两文件已交付桌面；平台替换、实际工具减少和速度收益待用户实跑。未启用平台预载/缓存或硬性工具白名单，未实施其它提速方向。见实施证据。

2026-09-15 进入提速方向讨论，准确性规则冻结

用户已明确进入Agent速度优化讨论，要求保护已验准确性。本轮只分析：系统Parsing占总耗时99.418%，其它阶段每封0.435至2.199秒；首Skill调用12至20秒，另有目录探索、重复读取、跨渠道和待办绕路。建议先评估固定规则加载及工具范围，再独立讨论紧凑JSON和重复材料整理。QBD3有重复证据及未截断的历史引用，本次正确忽略，边界调整不能混入纯提速。尚未授权或实施具体改动，无真实调用/重放/重启/子智能体。见分析证据。

2026-09-15 V6七份实跑完成，红叉原答已验证

七份V6实跑全部完成，共13新订、28修改、4正文取消；仅17项既有FIT缺Name1。16处AMD ALLOTMENT仍为修改，QBD4完整红叉原答成功，LT3日期误报未复发。45项业务和确认保持，新同义表达及部分扣减尚无真实覆盖。本轮只读核对，未改产品、配置或服务。见七份证据。

2026-09-14 正文Allotment语义修正已加载，表格AMD保持

正文原两句及扣减/释放/取消同义表达统一取消该allotment，包含部分扣减；表格AMD ALLOTMENT仍UPDATE。Parser v3隔离新旧接收规则，Provider字段仍v2；90项后端及32项配置检查通过，七份保存样本45任务/酒店事实/确认保持。V6必要文件已交付桌面，8082已加载PID78727、build_time 2026-09-14T15:47:09.880Z，5178及Parsing/V2就绪；配置保留，无在途查询。平台替换及新Agent实测留用户。见实施证据。

2026-09-14 V5两份真实日志通过，LT3日期误报消失

两份同原件最新实跑均使用input/result v2并完成：LT1为2修改、无复核；LT3为11新订＋2修改，仅1项真实FIT缺Name1。LT3旧M1/M3操作日期误报在本次原始Agent回答中消失，酒店字段及15项业务/确认内容保持，139条事实及两处加床核对完整。仅此两份实际案例获得验证，未覆盖QBD或正文取消及其他Allotment表达；本轮只读核对，未改程序、配置、服务或执行新的业务测试。见本批证据。

2026-09-14 操作交接v2已实施并加载，待平台替换实测

程序已接管原操作格的动作、日期与顺序选择，新input/result v2只把effective_operation交Agent；酒店明细、辅助日期、前后值及其他规则保持。84项后端、32项配置检查通过；七份同原件离线验证41行操作选择一致、45项业务/确认不变，旧2项日期误报issues仍保留。8082已加载PID76903、build_time 2026-09-14T14:54:17.425Z，5178/Parsing/V2就绪；配置保持且没有在途查询。V5 Skill与主提示词已交付，平台替换及真实Agent效果由用户手动验证。见实施及加载证据。

2026-09-14 操作日期先做影响核对，尚未实施

用户要求先核对不传操作日期的影响，避免扩大修改。当前仅审计：41行原答中37行单操作、4行多操作；直接去日期沿用旧交接时，LT1两行及LT3两行会新增顺序复核。最小方向是程序保留日期并确定有效操作，再交Agent，酒店明细及其他逻辑保持；真实Agent效果尚未复测。无程序/Skill/服务修改，实施暂停，见依赖证据。

2026-09-14 最新操作交接职责进一步确认

用户明确程序先选出最新操作，只把选中的操作说明交给Agent。操作日期用于程序内部排序，旧操作保留来源展示，不再要求Agent重复选择；酒店修改前后值仍完整交接。不同日期取最新、同日取末条的规则保持。现有代码仍依赖Agent拆分操作记录，本轮仅记录最新方向，未修改代码、平台配置或服务。

2026-09-14 七份实跑全部完成，LT3剩两项操作日期误报

七份同原邮件实跑形成13新订、28修改、4取消共45项，56条活动客房及2处加床完整交至确认；41个业务目标与既有结果/预期一致。17项FIT真实缺Name1继续复核，LT3另新增两项Agent误把操作日期当入住日期的MATERIAL_PARTIALLY_RESOLVED。QBD4相同带红叉原邮件已成功9＋1，但本次Agent引文去除了红叉，原样带红叉回答仍以此前离线验证为证。本轮仅日志核对，未改程序/配置或服务；下一步收紧Parsing操作日期语义。见七份复核。

2026-09-14 本对话加载方式更新

用户负责提前肉眼确认在途任务；本对话后续服务修改验证完成即直接加载重启，无需再询问加载许可或查询任务空闲状态。仍保留配置/数据和启动后的版本、健康及页面连接核验。此轮仅记录约定，当前已加载版本继续运行。详见当前加载授权。

2026-09-14 修饰符号修正版已加载，用户开始手动测试

按用户“加载重启”授权，8082切至PID73842，build_time为2026-09-14T13:30:44.964Z。5178页面、代理版本及Parsing/V2就绪通过，配置和处理状态数量保持。外围修饰符号接收及取消语义歧义局部复核已进入运行包；后续由用户手动验证，未主动重放、外发或提速。见加载证据。

2026-09-14 取消引文修饰符号修复完成，尚未加载

按用户确认，外围修饰符号不参与取消业务匹配，完整原文与证据保留；额外文字/编号造成的语义歧义仅转正文人工复核，表格继续处理。45项定向测试通过，QBD4未经修改的原答离线恢复9修改＋1取消，仅7处FIT缺Name1；其余四份QBD及三份LianTai完整任务和校验结果不变。只改程序及测试，平台配置无需再次替换，当前服务尚未加载本轮修复。见实施证据。没有真实Agent、重放、外发、提速或子智能体。

2026-09-14 新版五份QBD日志：四次完成，QBD4被正文红叉格式整批拒收

QBD1为4修改＋1取消、QBD2为5＋1、QBD3两次均6＋1，复核只剩2/2/5/5处FIT缺Name1，未见BF房型或解释性issues复发。QBD4已返回9行＋1取消，但原取消引文含外围红叉，超出上一轮星号/空白白名单，触发INVALID_PROVIDER_RESULT并阻断全部表格。五请求hash一致离线复现；QBD4仅移除外围红叉的副本即可形成9＋1，剩7处姓名缺失。本轮仅诊断，未改代码或服务。下一步需同时解决取消原文格式核验与单项失败隔离，详见五份复核。

2026-09-14 QBD接收修正版已加载，移交用户手动测试

用户已替换平台配置并授权启动最新服务。8082切至PID71793，健康接口和5178代理均确认新版本2026-09-14T12:32:32.918Z；5178保持PID45022，Parsing/V2就绪。启动与提醒配置保留，未清数据或主动重放。本次房型BF/RO与正文取消接收修复已生效，用户继续手动验证；提速仍等明确指令。详见加载记录。

2026-09-14 QBD接收修复完成，待加载及用户手动验证

用户授权后完成BF/RO房型分离、正文取消原句有限格式接收及证据定位、Parsing issues语义澄清。73项后端和32项Skill检查通过，五份原请求hash一致离线回归：QBD1恢复完整4修改＋1取消，保留2处姓名缺失及旧解释性issues；QBD2恢复5修改＋1取消，仅2处姓名缺失；LianTai原17任务及逐项校验结果保持。配置文件位于artifacts/qbd-handoff-fix-20260914/，尚未加载服务或替换平台。详见实施与验收。未运行真实Agent、重放、外发消息或子智能体，未实施提速优化。

2026-09-14 两份新QBD：BF房型整理与正文原句严格相等问题

QBD1完成4修改+1取消，但5个活动房型含BF未规范到目录，两FIT缺姓名，另有Agent解释性issues触发复核。QBD2完整JSON因正文取消带原邮件星号/空格被整份拒收。两份重建请求ID/hash与运行一致，离线原答精确复现；仅移除取消外部装饰即可通过Parsing接收。当前仅诊断，未改代码/配置或重启；无需新增平台复测即可定位。见复核证据。

2026-09-14 最新三份真实运行：任务识别与交接逐项通过，1项缺姓名

用户新提交LT1/LT2/LT3三份运行日志，17个已选中行形成13项新订和4项修改；16项VALID，LT3的2间FIT仅缺Name1。20条房型明细、154条事实及2处加床归属完整接至待确认投影；本批未见旧房型/数量接收或JSON包装失败。当前标准LianTai统一Group价格目录已在三份日志中生效，WHO3小房量仍为FIT。仅日志静态核对，不代表QBD、取消、多附件、未选行及页面确认已验收。当前先关注准确性与交接，提速优化等待用户另行明确指令。见本批证据。

2026-09-14 解析接收与LianTai Group价格修正版已加载

最新修正版已切换：8082 PID67953、5178 PID45022均健康。包含解析接收修正与LianTai Group价格规则，启动及提醒配置保持。后续由用户手动测试；不再另交配置说明。 见加载记录。

2026-09-14 LianTai标准范围统一Group目录，修正版待加载

已按用户澄清分开价格渠道与房量分类：LianTai标准范围统一LIAN TAI/GROUP，U-DBL12=1200匹配WHO3；小房量仍按FIT预订并校验姓名。33项定向检查通过；LT2保存回答离线两项正常，LT3系统/平台各13项价格齐全，仅一项缺姓名。后端包与桌面配置说明已更新，Parsing提示词/Skill无需为本条变更；尚未切换服务。详见实施证据。

2026-09-14 Parsing接收修正已完成，待平台替换与配套加载

已完成用户批准的有限JSON包装容错、Sup/U房型规范化、独立数量保留及Parsing配置同步。针对性后端36项、Skill32项通过；LT2实际原答离线2项VALID，LT3系统/平台原答各13项中12VALID、1项FIT仅待姓名（Group价格已按最新规则确定）。六文件Skill和主提示词已交付桌面，后端包已构建但未加载；无真实Agent/重放/通知。详见实施证据。

2026-09-14 回放适配已合入并加载

用户结束测试并要求快切。四项回放展示适配已合入，8082切至PID64883，5178原进程已加载新源码，版本和健康检查通过；配置与测试数据保留。原对话新增的测试分析记录已保留。见切换证据。

2026-09-14 回放适配已在隔离区完成，尚未合入或加载

四项适配已完成：实际程序执行类型、范围外/专用邮箱原因、阶段详情与导出一致、企业微信失败提醒只读状态。前端相关30项、类型检查、lint及构建通过；后端交接六类62项通过，补齐旧Agent摘要防护后仅重跑相关14项通过。当前5178/8082继续由用户人工测试，未修改主项目产品源码或服务。等用户测试结束后另行安排合入/加载。见收尾证据。

2026-09-14 三份标准运行：判型改善，房型接收与JSON包装有缺口

LT1两项修改正常；LT2两项新订判型正确，但括号房型触发原文匹配且连带丢数量，另一行房型映射未命中；LT3回答带说明与代码围栏，严格JSON解码失败。已原样导出LT2/LT3平台用户输入，用户沿用当前配置复测。只读分析，无产品改动或重跑；不扩大另一对话的回放展示适配范围。见三份日志复核。

2026-09-14 回放主线已接入，执行类型及原因展示仍待适配

只读复核发现标准程序判型的Trace空类型被V3默认记为REAL_AGENT，范围外通知被统一显示为专用邮箱原因；页面仍有旧Booking Agent说明。入口已复用新主线，建议先补齐日志/页面再手动验收；微信受理状态在回放页尚未接入，属于建议补充。无需新建Agent或改Parsing平台配置。本轮未实施、重启或产生新测试。见适配复核。

2026-09-14 历史测试已清空，保留标准表格 V4 与配置

按用户要求备份并清除当前5178测试历史：42条回放、41封来源邮件、117张任务卡及对应任务、3条测试确认、10条通知和相关解析日志。列表均归零；同版本8082已恢复（PID63136），5178健康。账号/目录、Agent/Skill及企业微信配置保持，原件保留；未重放邮件或外发。后续由用户从空工作台手动验收。见清理记录。

2026-09-14 标准表格 V4 已加载，失败提醒已启用，待用户手动验收

用户确认Parsing平台配置完成后，已独立加载新版8082（PID62512），5178正常。标准范围使用单Parsing后程序判型；V22/V23迁移成功，117项既有任务和所有Booking业务内容保持。Java17全量1287项通过、16条件跳过。用户确认微信发送地址和ID9998并提供Token，私有配置已就绪/启用；队列为空，无历史补发、真实Agent调用、邮件重放或测试外发。用户现在手动验收标准处理、完整展示及失败提醒收达。见加载证据。

2026-09-14 标准范围本地实现与离线验证完成，尚未加载

标准表格范围、单Parsing后程序判型/校验、完整来源展示和最终失败去重提醒已完成本地实现。后端196组共1303项：1287通过、16项按既有条件跳过、无失败；前端33文件270项、类型检查和构建通过，Parsing配置32项检查通过。七份原件机械选行41行与当前正文4项取消一致，四项合成全链场景通过；不等于真实Agent或企业微信收达已验收。V4配置包已交付桌面“0914邮件/平台配置V4-20260914”，平台由用户手动替换，之后配套加载并由用户手动实测。当前未加载服务、执行真实迁移、调用真实Agent/邮件或外发通知。详见实施证据。

2026-09-14 用户修正两个12价格标签为1200，规则升为v2.4

TWN12（含本批U-TWN12）及U-DBL12均为1200，已覆盖此前按旧规则得到12000的解释。重新静态查目录：GROUP U-TWN唯一WHO3/BUALUANG；FIT U-DBL在对应FIT目录仍无方案，同时缺Name1。预期任务总数45不变，需补充项由18减为17，更新规则v2.4、仓库外报告及当前证据。仅两个标签价格及受影响统计修正，不泛化所有数字换算；本輪仍未改程序/Skill或加载服务。

2026-09-14 七封静态核对完成，待审阅预期

按规则v2.3完成41个表内目标及4项正文整块取消的逐字段预期，合计13新订、28修改、4取消。17项FIT缺真实姓名，2项LianTai短价无静态目录候选，其中1项重叠，共18项需人工补充。LT2明确两项新订；加床随预订、旧引用只展示。另清点3张CID历史图片及3次远程签名图引用，补22项边界预期。详细业务报告在仓库外，见脱敏证据。当前未实施程序/Skill/配置或运行邮件，后续先审阅案例预期，平台仍由用户手动配置。

2026-09-14 四项边界已确认，规则汇总稿v2.3完成

用户逐项确认：同日不同操作取单元格原文最后一条；LianTai明确房型后省略客房数默认1；加床归属房型明确时按每间一床预填用床房间数、标签数字只展示；同封邮件各标准附件分别生成任务，重复项由员工忽略。已更新规则汇总稿v2.3，明确跨附件不合并/覆盖/累加，同附件多行多住期仍沿用既有规则。Q1–Q4已收口，下一步逐字段/逐任务核对七封案例；本轮未实施。最新架构仍是解析Agent→程序判型→程序校验，配置文件由Codex交付、用户手动配置平台。

2026-09-14 最新确认：Agent先解析，程序后判型；平台由用户手动配置

用户认可新的顺序：程序选行/提供操作材料→一个解析Agent结构化解析→程序按固定规则判型→程序校验→员工确认。已更新规则稿v2的职责、交接内容及配置交付分工；解析Agent解释本次有效操作，不输出最终任务类型，原Booking明确判型规则拟移入程序，不再独立调用Booking Agent。Codex准备提示词、Skill文件及说明，用户手动配置平台。四项规则细节继续待确认，已开始确认同日操作冲突；本轮仅更新文档，未实施或加载。下方较早“方案一：Agent解析并判型”已由本条替换，不能按旧稿继续开发。

2026-09-14 方案一已确认，当前仅完成规则待确认稿

用户确认程序选行/提材料→一个Agent解析及判型→程序校验→员工确认，并授权“第1步”整理规则文档。已将原范围CR改为待确认稿，汇总最新填色列、允许字段、日期补全、操作优先级、表内加床和正文整块取消，区分历史沿用基线与四项待确认细节。无需完整操作历史；两套Agent规则拟合并，运行尚未迁移。当前未修改程序、Skill、配置、服务或业务数据，未运行邮件或外发；规则确认后再做逐字段/逐任务案例核对。此前“实施顺序已整理”不等于获准立即实施。

2026-09-14 收窄实施顺序已整理，企业微信仅定位失败邮件

用户确认模板判断边界，保留正文整块配额取消，其他正文/邮件全量展示并通知；企业微信只提示哪封邮件最终失败或超时，排查在平台完成。计划依次完成范围及Skill收窄/LT2修复、通知全量展示、简短提醒接线，再由用户手动实测。本轮仅形成实施CR并修订旧提醒文案要求，程序/Skill/服务未修改，未开始测试或外发。

2026-09-14 拟收窄为标准表格预订，保留正文配额取消

用户提出仅处理EML2/LT2等标准表格，其余邮件全量展示并通知，支持类型失败需企业微信提醒；另明确保留既有正文配额取消，其余正文只展示并通知。已核对LT2正是本批新订被做成修改的案例；旧仓库8月20日有固定Parser/通知基础，当前全量展示与失败提醒全链仍有缺口。本轮只评估并记录，未实施、回退或变更ADR。见讨论及依据。

2026-09-14 六份新日志：交接改善已验证，LianTai新订归类未通过

六次完成且C1零拒收，242项Parser事实保持；加床已知团号交接、配额12编号/24值及欢迎屏人工状态正常。另一本LianTai两行明确NEW BOOKING却生成修改，且目标备注又生成重复通知；不能判整体验收通过。未覆盖正文BF旧缺口或同输入重复稳定性。本轮仅日志与24项任务详情复核，无产品/Skill/服务修改或新测试；待用户下一步决定。见本批证据。

2026-09-14 Booking对象交接已修复并加载，实测移交用户

统一来源到订单的目标对应，并在返回组装和原有接收校验中复用；修复服务/备注/复核错配及来源姓名还原。专项47、全量1259项（16条件跳过）通过，9份保存输入原事实保持。8082已加载PID43496，93项既有任务及配置保持；用户确认新版Parsing Skill已上传。仅启动1封LianTai（2099322663008710657），实际Booking输入已正确保留加床所属团及数量；随后用户明确手动测试，其余自动实跑停止，整体验收待用户日志。见实施与加载证据。

2026-09-14 本次交接修复范围与停止条件已复核

用户要求本次认真确定修改，仍不通过则回第一版、只保留单一类型。再核对3份实际Booking输入发现同类来源/订单编号错配；建议统一输入与结果还原的对象对应，配套加载既有日志修复并核实Parsing配置，固定失败案例重复实跑到卡片验收。此次仅方案，未改源码/Skill或服务；用户随后明确回退细节稍后再说，本轮不展开或执行回退。见方案与证据。

2026-09-13 新日志复核：附件目标交接错配

五条新增均完成且C1零拒收；八月三项核心数据与旧同邮件一致，LianTai46项Parser事实完整。新发现附件材料到Booking输入目标编号错配，加床已知团号被误报无法对应。后台仍为旧PID26355，已修日志尚未加载；新版Skill激活及关键同输入复测尚待确认。本轮只读分析。 见证据。

2026-09-12 Parsing稳定性修订完成，待平台替换和日志加载

已完成Parsing公共房型/含早/原字段与引用规则修订，房型名单由现有目录生成并在打包时核对，包仍6文件；日志已区分全部待人工与无需人工。Skill31项、后端专项60项、前端lint/类型检查通过。主提示词未变，平台尚未替换、后台尚未重启，真实重复运行验收待后续。 见实施证据。

2026-09-12 四封重跑：接收通过，来源完整性与人工状态仍有缺口

四封系统重跑均完成、C1零拒收：九月配额12项全接收，九月表69项Parser事实完整、5修改＋1整块取消，八月3项核心值稳定。正文两团仍漏一处BEFORE含早，另确认全部卡待人工时日志误写无需人工。来源提取先收紧Parsing规则，另需独立日志状态小修；本轮只分析，未改程序/Skill/服务。 见重跑证据。

后续范围仍待实施指令：优先原地澄清Parsing公共字段和输出示例、固定配置重复验收。现有BF及原字段保留规则已存在，避免重复堆叠提示词或增加程序补猜、复核/重试环节；独立日志待修保持。

用户进一步明确Allotment非房型及仅编号/数量时的保留方式；已定位项目现有来源房型知识表与共用识别程序。后续Parsing说明应复用其房型写法和别名，避免独立维护名单，酒店代码/价格仍由Layer4处理；当前仅定位。

2026-09-12 Parsing平台复测：数值正确，共享字段引用仍拒收

平台复测输入内容与导出一致，12组配额编号/前后数量均正确，未再输出Allotment房型或虚构入住日。但原回答经现行程序接收只保留前6项：后6项重复酒店名却未引用E4/E5，共享展示分组被拒。离线补齐引用或去掉重复酒店字段均恢复12项、0拒收。只诊断未改程序/Skill/运行数据，不能据单次失败定性整体架构。 见复测证据。

2026-09-12 九月配额Parsing原样输入已交付

已从九月失败run唯一完整用户消息回显原样导出Parsing输入（3185字符），来源重建的完整工作稿、请求身份及程序说明核对一致。用户将沿用原配置手工复测后返回平台日志；本轮无新Agent调用、代码/Skill/服务修改。单次失败的结构性定性暂不成立，待对照证据。 见输入与验证。

2026-09-12 四份新旧日志复盘：表格改善，配额整理仍有失败

四份指定日志中两份新运行完成、一份九月配额C1拒收、一份为旧Booking失败记录。新拒收复现为住期资料缺来源引用，并存在无依据入住日期及将ALLOTMENT当房型；后续仍凭原文生成现有人工Proposal。QBD表114项Parser事实完整、C1无表格重复，9修改＋1整块取消，卡片前值/Note对应正常。只读分析，无程序/Skill/业务数据/服务修改，原邮件准确度留后续。 见核对证据。

2026-09-12 Booking结果包装与未执行状态已修复并加载

用户批准后已修复Booking单元素数组包装兼容及失败后未开始确认投影状态，并加载到8082，PID26355；5178健康。原始失败回答直接通过原有接收检查、2项候选与去包装基线相同；全量后端1250项（16条件跳过）无失败/错误。37项任务保留，原失败记录仍失败，仅确认投影显示未执行，全部原输入输出及回答哈希保持；可重新测试，无新Agent调用或历史重放。 见实施与加载证据。

2026-09-12 新运行Booking失败已定位，待修复

新运行2098446205190848514的Parsing全部52项接收，失败在Booking结果接收：最终JSON最外层为单元素数组，当前要求对象。使用同run原输入离线复现，仅解开数组包装后通过既有接收/组装校验，形成2项修改结果。另确认C2失败后确认投影仍PENDING是日志遗漏。本轮只诊断，未改程序或重跑。 见诊断证据。

2026-09-12 日志与Parsing交接修复已加载

8082新包已启动，PID24294，5178健康；日志状态与接收明细、配额建议首项交接及表格分工程序说明均已加载。37项现有任务完整响应、能力配置和处理状态保持；三份真实日志索引/详情/导出一致且业务输出不变。未调用Agent、重跑邮件或上传平台配置，后续新实跑效果待测试。 见加载证据。

2026-09-11 日志状态与接收明细已修改，待加载

页面/详情/导出统一阶段状态：正常业务人工核对属完成，无房型价格解析需求跳过，入口失败后的未开始步骤未执行；明确运行异常仍失败。C1新增独立接收/未接收明细；新未支持来源保留静态原因，旧记录不补猜。12份保存日志离线核对一致且业务输出不变；后端1244项（16条件跳过）、前端266项及类型/构建/lint通过。后台未重启加载，无Agent调用或历史重写。见实施证据。

2026-09-11 配额建议交接与表格分工修复完成，待加载

用户确认欢迎屏处理符合预期，已从本轮修复范围撤下。正文原始字段改由本次正文承载；真实配额建议从11项恢复为12项完整接收。程序出站说明、Parsing Skill及主提示词明确直接关联既有表格T目标，只整理正文新增/修改与剩余材料。9份原回答离线接收核对通过，其余8份结果保持；后端1236项（16条件跳过）和Skill30项通过。分工修正版已打包，尚未加载后台或上传平台，模型行为待新实跑；日志状态仅解释未改。见修复证据。

2026-09-11 十二份新运行日志结构复盘

新格式在9份双Agent实跑中生效，另1份通知专用正常、2份入口失败；9份中5份存在局部拒收。已定位新程序跨行原句还原、正文原始字段错挂主题两处缺口，以及3份重复整理表格。Parser事实保持，两份同邮件总耗时由518.503→198.520s、199.074→131.684s；尚不能判结构验收通过。本轮只读分析，不修改代码/Skill、运行数据或服务；原邮件准确度留下一轮。见十二日志复盘。

2026-09-11 两步邮件交接与Parsing V3后台已加载

用户授权后8082已切换包含第一/二步的新包，PID18440；健康和5178代理正常，9项工作台任务完整列表、能力配置及处理状态前后相同。构建差异仅本次11组类/构建信息，SQL与依赖不变。用户报告提示词已配置，远端Skill内容本轮未读取；未重放邮件或调用Agent，可以开始新测试。见加载证据。

2026-09-11 第二阶段Parsing输出与Note精简已完成，尚未加载

C1改为按来源对象一次整理修改前后、酒店住期和房型价格，程序生成内部编号、引用原句及材料/复核关联；旧结果兼容。Note只保留补充和必须展示的信息，未知原始字段继续保留。两封保存记录的紧凑样例保留全部49/70项有效事实（EML2含69项Parser事实），8卡查询通过；EML1不再重复酒店字段，EML2配额卡仍显示取消原句。后端1234项、16条件跳过、0失败/错误；Skill V3及30项打包检查通过。没有运行新版Agent、重写历史或切换服务，耗时效果待配套加载后实测。见交付证据。

2026-09-11 第一阶段邮件交接修复完成，待加载

正文引用改按原行；团号正式交接与两封邮件的 BEFORE/取消原句对象对应已完成。真实 8 卡离线详情查询验证通过，EML1 三种旧房型独立、EML2 前两项 BEFORE 及取消原句恢复，其他现有业务字段一致。后端 1227 项、16 条件跳过、0 失败/错误。没有调用新 Agent、改历史记录或加载服务；Note 精简及 Agent 格式仍留第二步。见实施证据。

2026-09-11 用户认可先交接后精简的两步安排

第一步覆盖正文引用切分、团号、两封BEFORE及配额原句的卡片交接；第二步覆盖Agent格式负担和Note重复。已说明当前按换行及句点等标点切引用，拟改为按原文换行、保留行内标点和完整上下文；片段不等于业务对象。本轮仍为具体方案说明，除团号既有修复外未新增实现，见安排与切分说明。

2026-09-11 EML1/EML2原邮件与日志联合复盘完成

EML2约3分19秒，5个表格目标的69条事实与原附件相符，最终5修改＋1整块取消；2项FIT缺旅客姓名属现行人工规则。新确认前两项BEFORE在Layer3完整但因Parser目标ID与最终团号未对应而漏入卡片，取消原句也被目标筛选遗漏。EML1的Note过满/长输出不能泛化；见联合证据。本轮只读，团号修复仍待加载。

2026-09-11 正文已识别团号交接已修复，待加载

V2投影将已验收且未绑定Parser的正文目标团号连同原证据传入正式来源字段；已有事实/Parser绑定保持权威，空值不猜。29项相关测试（1条件跳过）通过，本封保存结果本地检查两个团号均进入Layer4及Booking输入，其他来源事实不变。未运行Agent、修改历史卡片或加载服务；要素定义仍为讨论。见修复证据。

2026-09-11 Note重复原文，正文修改前房型快照存在覆盖

当前两卡正式字段已接到修改后日期/房型/数量；C1要求保留的业务原句又被页面统一放入Note（11/15条）。第二卡BEFORE已有3种房型，但快照组装忽略正文body_binding，全部落入默认同一房型而相互覆盖。已记录原因与证据，无程序/配置修改。

2026-09-11 完整日志确认C1整理负担，并发现团号交接缺口

同输入平台复测出现约11万字符分析，集中反复核对展示/编号/引用；英文句点将日期及房型拆碎，增加恢复工作。系统原运行仍为C1约7分37秒，平台导出时间戳不可用于精确分摊。C1已识别团号仅留在语义材料，后续团号字段为空并触发缺团号；两项最终均需人工核对，流程完成不等于业务已可确认。仅分析并更新证据，未实施建议。

2026-09-11 新一轮正文修改测试完成，耗时集中在Parsing Agent

用户提供未完成日志后只读核对：该QBD纯正文任务最终约8分39秒完成并成功投影；程序Parser92毫秒，C1约7分37秒，C2约1分钟，均单次执行。正文686字符，C1输出约3.1万字符；正式输出2分06秒，读取规则后到正式输出仍有约5分钟待平台明细确认。已交付本次C1/C2实际用户输入供手工复测；未修改规则或新跑Agent。见耗时与输入证据。

2026-09-11 旧测试数据与工作台历史已清空，可开始干净测试

按用户明确要求，备份后清理本地测试酒店13封邮件/回放、17张任务卡及对应任务、3条确认、2条通知和12次Booking处理及关联日志。实际历史、任务、卡片、确认、来源列表均为0；配置、目录和Agent能力保持。后台PID10532运行刚加载的日期/配额新版包，5178健康。无新测试或平台Skill操作；备份与范围见清理证据。

2026-09-11 QBD/LianTai日期及配额后台已实际加载

用户授权后以现行JDK17 clean verify通过1218项、10跳过、0失败/错误；确认队列空闲并切换8082，新PID10054，5178保持健康。运行包只含本任务七组后台类及构建时间差异，SQL/依赖/环境保持；17项任务完整响应、Agent能力及处理状态前后相同。首次版本时间格式误判已自动恢复并修正，最终切换成功。平台两份Skill本次未上传，仍使用此前交付版本；见实际加载记录。

2026-09-11 QBD月份规则及日期局部核对已补齐，尚未加载

QBD同样不因标题/页签月份不一致拒绝整表，明确酒店日期继续按J/E规则提取；补修非法文本日期被改为月末、越界日范围导致整表失败。五份真实QBD表27个标色对象及内存月份变体、两份LianTai表均通过；完整verify共1218项、10跳过、0失败/错误。未改上一轮Skill包，无真实Agent调用或后台切换。见QBD补充证据。

2026-09-11 LianTai日期及配额统一取消已本地完成，尚未加载

按用户批准修复LianTai标题/页签月份冲突误拒：两份真实表分别5/3行及酒店日期通过；行程非必填，只作年月冲突时的可选辅助。日期局部REVIEW_ONLY完整传给C1和接收校验。配额关系保留，当前使用/释放/取消配额统一整块取消，C2扣减分支及新结果入口已收窄；Proposal创建/调整保持。后端完整verify通过（1194项、10条件跳过、0失败/错误），38项配置检查通过；两份Skill已打包。未调用真实Agent、未重启后台或上传平台。详见交付证据。

2026-09-11 已查明Parsing Agent每封调用的历史原因

8月10日设计仅补程序未解决字段；8月11日改为理解当前/历史正文、备注及正文附件对应，因此规定支持的固定渠道每封调用。当前表格/BODY_ONLY均沿用。按需讨论必须保留整封要求覆盖，不能仅凭Excel提取成功跳过理解；尚未批准或实施架构改变。见历史追溯。

2026-09-11 已对照另一任务的架构建议，仍为讨论

读取《架构职责确认2.0》已完成讨论。其最新建议为Layer5统一理解整封邮件、按具体事项使用Layer3/4，与本任务最近按需方向趋同；较早按邮件场景跳过C1的表述需收紧，避免混合邮件被单一路由遗漏。倾向保留确定性预处理/酒店规则/程序组装，以统一业务理解作为讨论基础；未批准或实施改造。见对照意见。

2026-09-11 核对固定表识别及New/Update的Rate处理

现行QBD以年月页签/关键表头及橙色核心格选行；LianTai仍保留顶部标题月份和固定九列约束。Rate只进入New/Update任务，但Layer4在C2分类前预备套餐，Layer5B按最终FIT/GROUP取用。讨论按需调用时点，目录/原价无候选才折半/缺价默认均保持；未改程序规则或运行。见核对记录。

2026-09-11 当前Rooming上游识别保留，员工专用卡已停用

核对源码与8082运行包：文件名/包结构识别后由C2判断及Layer6校验，成功Rooming结果转GENERAL通知；5178不展示或确认专用Rooming卡。通知页只有来源邮件/附件名/图片/线程及ACK，未单独展示后台停用说明，无名单明细。当前19项工作台中未找到Rooming实例，本轮无真实运行；见当前处理与展示。

2026-09-11 讨论Layer3按需提取，尚未改动执行链

用户提出无表格/Rooming/Trace是否需要不同提取方式。核对当前固定Excel及纯正文都会调用C1；EML2程序阶段约3.2秒、C1约128秒，纯正文pro2的C1约306秒。讨论将固定表解析、复杂正文提取、服务/名单材料分开，并让C2按事项需要资料；目前Trace依赖已有目标、Rooming依赖已解析选项，不能直接关闭C1。无方案批准、应用修改、真实Agent或重启；见讨论证据。

2026-09-10 用户要求重新审视七层职责，当前为讨论

发现C1现行QBD规则主动要求配额source关联全部附件团，C2同时持有整块取消及Update不派生扣减规则，接收又要求前层关系匹配；此前“模型误关联”的解释不完整。建议重点收紧Layer3–5的来源提取、统一对象对应、唯一业务决策边界，Layer6/7区分业务复核与技术失败；保留已生效Excel/Rate逻辑和当前发件人范围。建议尚未实施或替换ADR，无子智能体/真实Agent/重启。详见职责复核。

2026-09-10 五封实跑复盘：Pic改善，2.eml配额关系误连导致接收失败

Pic当前欢迎屏及人工复核已正确交接，总12分31秒降至4分钟；pro2三项调整保存一张Proposal，1.eml两张修改保持既有人工补项。2.eml附件五行完整，但C1误连正文配额与五团，C2输出五笔扣减，引用也无法接回，Layer5拒收；RM为酒店回复，在现行固定渠道测试入口失败，未调用Agent。C1在1.eml/pro2仍需6分41秒/5分6秒。此轮只读及单样本本地接收复现，无修复、Agent或重启；见五封证据。

2026-09-10 C1结果接收修复已加载，后台重启完成

按用户“重启服务”授权，确认五类处理队列无运行中邮件后，使用现行Java17构建并切换8082，PID96536，约15秒恢复。5178健康正常，14项任务接口内容前后完全相同，环境配置保持；运行包仅共享结果接收客户端及构建时间变化，61份数据库脚本不变。后台已加载；C1 Skill和完整主提示词仍待用户上传确认，真实平台续接/三样本效果尚未实测。本次无Agent调用或邮件重放。见加载记录。

2026-09-10 C1结果续接与范围修复已交付，待加载和配置

后台补同run保留事件起点；C1明确正文内引用历史及OTHER_SERVICE复核关联，清除重复要求和残留Proposal提取分流。49项接收测试、29项配置检查及三样本本地交接通过；Pic为构造期望，未跑新Agent。仅交代码、C1 skill和完整主提示词；当前服务/平台未切换。见修复证据。

2026-09-10 Pro1平台输出确认正确，原失败定位为成功结果接收缺口

Pro1平台C1结果与原成功快照完全一致，12项配额前后值完整，离线接收0拒绝；C2正确一项Proposal。两封C1平台记录均有重复整理；Pic仍是独立的实际超时、引用历史和服务交付问题。建议先接收修复，再C1范围/交付，最后量化速度；本轮仅复盘。见合并结论。

2026-09-10 1.eml平台单测正常；Pic欢迎屏请求因C1超时转人工

1.eml输入一致，C1新输出本地接收检查无拒绝，C2仍为两项修改。Pic总12分31秒，C1在10分钟截止后约26秒才出结果，C2用2分30秒形成目标待定风险提醒；这次不同于Pro1提前成功但恢复接收缺口。引用旧订房被展开成大量资料，晚到输出还暴露OTHER_SERVICE复核交付缺口。本轮只读复盘，无代码/运行操作。见证据。

2026-09-10 Pro1分类正确，但C1成功答案在恢复接收时未被取用

新Pro1实跑10分48秒，后台已收到C1成功快照及12组配额，却继续等到10分钟超时；后续凭原正文生成1张Proposal，整理展示资料为空。已定位现有结果恢复路径仅取状态、仍等事件结束的问题，尚未修复。1.eml两项修改仍正确，C1约6分56秒；四份原调用输入已导出供用户平台对照，本轮无程序或运行操作。见复盘。

2026-09-10 新版两封实跑已核对，可继续其他类型测试

2.eml实际恢复5项附件修改及1项正文配额取消，6张卡保存；1.eml正文房型、BF和价格交付生效，2张修改保存。剩余为3个既有FIT缺姓名提示、同团多Rate导致的Rate/含早空值，以及C1耗时；本轮无新修复或运行操作。附件未完成提醒这次未触发。见真实结果。

2026-09-10 EML2/EML1专项后台加载已完成

按用户“重启”要求，clean package后将8082切换本次修复包，PID91540；5178 PID45022保持。工作台健康、4项任务及3条历史前后相同，旧日志可读，配置保持。此前后台待加载状态已关闭；C1/C2 Skill由用户更新，未操作平台或运行Agent。见实际加载。

2026-09-10 EML2及EML1衔接修复已交付，尚未加载

按用户认可顺序完成EML2标题误挡和提醒交接、C1正文来源规范化配置、Layer4原价未命中才折半。原附件5行、51项Java及38项配置检查通过，pro2上下文保持。C1/C2 Skill需手动替换，主提示词不变；后台四文件待加载。真实Agent未跑，一团多Rate与FIT姓名仍按旧规则。见修复证据。

2026-09-10 统一加载后三封实跑：分类改善，附件与来源房型交接仍有缺口

最新1.eml已正确生成两张预订修改，但完整来源标签未衔接现有房型/价格规则，需复核；2.eml九月页签仍用八月标题而被模板识别跳过，五行本次事项遗漏，C1附件未完成提醒也未传至C2/最终卡；pro2.eml三项配额调整正确形成一张人工Proposal。实际四张任务均已保存；本轮只读、无修复、Agent或运行操作。见三封复盘。

2026-09-10 5178历史测试数据已清空

用户明确要求清空：33回放、80任务卡、18测试确认记录、17通知及关联来源/处理日志已备份后删除。当前历史/任务/确认/来源列表均0；后台同一汇总版本恢复为PID86716，5178继续PID45022。规则、目录、权限、Agent配置和图库保持，新记录永久保留规则不变；旧证据编号现在仅可从导出/备份回看。见清理证据。

2026-09-10 统一加载与后台重启已完成

C1最终来源优先及正文交付、CP2a失败收尾、附件过滤、历史永久保留已统一构建并加载；8082新PID85808，5178继续使用最新前端。V39/V40及PG V20/V21成功，旧任务和日志保留，全部历史分页、旧日志导出、图片过滤实际只读通过。1155项后台通过/10条件跳过，32项前端及类型检查通过，无真实Agent/新邮件/任务办理。通知组件及配置已加载但发送仍关闭，自动触发未接。此前“待统一加载/等待C1交付”的状态已被本条取代；用户自行配置最新C1 Main Prompt与Skill后可继续测试。见实际加载证据。

2026-09-10 C1来源优先版本完成，主提示词与Skill均需更新

用户认可分工后已完成：取消按实际预订/Proposal判断选择提取范围；增加原编号、原列名/原值和修改前后资料交付，明确配房继续Layer4现有组装。两封正文及正常Proposal/Excel定向通过，37项程序、29项配置检查通过；真实C1未运行。只交付两个上传文件，程序仍待统一加载，本任务未切换5178/8082。该版本替代此前“只需更新Skill”的C1配置建议，见最新交付。

2026-09-10 下一轮C1/C2测试建议先统一加载（只读评估）

实际8082仍为PID63959的9月9日包，直接检查确认没有新版C1正文body_binding承接。建议先汇总已完成的C1后台、失败收尾CP2a、附件过滤和永久保留，再统一加载后测试；CP2a尚在独立副本需合并，外部通知自动触发仍未完成，不作为C1/C2测试前置。此轮未执行加载/重启/迁移/Agent或通知，见状态与依据。

后续检查“Layer3和layer4整体修改”任务：正在继续修改C1来源结构与后台接收/投影，尚在交付验证，不能视为与加载无关。按当前实现复用Layer4核心及中立材料到C2的通道；建议等这一轮交付最新C1后再统一构建加载，避免发布共用源码的中间状态。此为检查当时状态，加载前需以该任务最终交付为准。

2026-09-10 Booking价格写法说明已纠正

UP-TWN8.5按用户确认沿用U-TWN8.5对应850的既有规则。已删除修改规则中含义待定的误导描述，并更新原交付Skill；主提示词和业务分类规则不变，真实Agent效果仍待用户上传测试。见相关证据。

2026-09-10 Booking对象与动作分类配置已交付，待用户上传测试

基于当前配置修正实际预订误归Proposal：先按每项操作标的/动作分类，再选择已有对象；明确实际修改对象漏交用既有UPDATE_TARGET_UNRESOLVED，价格更正无需房型变化。保留Proposal集中/空目标、原配额取消/扣减、当前来源和FIT/GROUP。只交付主提示词与完整Skill；七封材料对照、13份构造预期格式/引用及9项打包检查通过，非新版Agent实跑。没有平台/回放/服务动作，见证据。

2026-09-10 C1正文实际预订修改修复完成，待统一加载

C1按实际操作对象提取正文团号及修改前后日期/房型/数量/明示价格；最小补齐正文来源关联、接收/保存/归并和Layer3→Layer4交付。两封正文本地分别1/2个实际对象，Proposal/Excel定向回归一致，48项Java和28项配置检查通过。完整配置包已交付：Skill需更新，Main Prompt保持；六份后台修改待统一加载。未调用Agent、运行新邮件或回放、改旧任务、重启5178/8082；无子智能体。见证据。

2026-09-10 普通邮件返回入口及错误折叠提示已更新5178

普通任务进入邮件可回原卡并保留分类/搜索；裸链接可返回待处理列表。任务版本材料不可用时准确提示，不再提供无效展开；原邮件仍在会话查看，缺失版本未恢复。262项及实际往返通过，无重启或真实办理，见证据。

2026-09-10 普通旧卡邮件材料不可用诊断（提示后续已修正）

任务版本材料404，被误显示成折叠；原邮件会话200且正文存在。只读定位，尚未修复，见证据。

2026-09-10 普通旧卡确认误拦截与过时匹配提示已修复

5178旧单段New/Update卡按实际显示住期提交，日期/房量编辑、删行及多住期保持一致；历史未匹配提示按现有只读归属预览消除。259项、类型/构建及运行JAR校验通过，实际LLTQ260811Q3-A旧提示消失、21个字段不变，未操作任务或重启服务。见证据。

2026-09-10 C1正文多住期资料承接缺口已确认，修正仅配置建议

两封误分类样本在C1只有原文无预订资料；进一步核查现有Schema和在用JAR，正文候选缺日期段/房型条目对应关系，归并时同类多值会冲突，向后传递也缺必要关联。因此完整修复需C1提取规则及最小正文资料承接补充，不能保证仅替换配置包即可。仍为方案讨论，无代码/配置/测试邮件变更；见专项证据。

2026-09-10 LLTQ260811Q3-A确认拦截诊断（后续已修复，见上）

团号正确且当前已有同酒店已确认记录；旧卡保留未匹配提示。其根部单段日期/房量能显示，但提交检查只接受stay_segments，离线执行当前校验确认因此被误拦截；不涉及复核说明。只读诊断，无真实办理或应用变更，见证据。

2026-09-10 附件列表固定图片过滤已完成，待统一加载

普通任务、Proposal与来源通知附件列表按同次整图结果排除固定图；完整会话、原件和绿色未登记版保留。前端245项、后端27通过/1跳过，类型/构建通过，已同步主项目并保留并行复核说明改动。用户指定随其他改动统一加载，未重启8082，本轮未创建子智能体。见证据。

2026-09-10 Proposal详情存在但工作台团号搜索为0

用户页面及实际接口复现：两张误分类Proposal仍待办理，无关键词列表包含，输入任一团号则0。列表搜索仅查任务定位字段，两张为邮件定位且无可搜索团号，不查原邮件主题/正文；区分C1/C2误分类与Proposal检索覆盖缺口。本次只读、无修复或任务操作，见补充证据。

2026-09-10 普通预订卡复核说明已去掉

根据用户指定LLTQ260811Q3-A，当前5178普通员工预订卡不再显示选填复核说明及空白区域，保留必要归属字段与确认/忽略流程。235项前端检查及实际卡片前后核对通过，其余字段和按钮状态一致，无重启或真实办理；见证据。

2026-09-10 正文实际预订被误归Proposal，不能把流程结束视为业务通过

四封QBD修改邮件均使用新版C1且成功读规则；两封纯正文（一个按晚改配房、两个团改房型价格）却未形成实际目标，被C2误归一张Proposal并通过宽松检查。两封Excel则5/9个Update＋各1整块取消，4/7项因现有FIT缺姓名复核。已核对实际卡片，后续修复应聚焦C1正文目标提取和C2配额/实际预订边界；不据此加严Proposal检查。本次无应用/配置或办理变更，见证据。

2026-09-10 三处失败收尾CP2a已在独立副本验收，保持当前测试版本

普通保存失败、有限检查恢复、技术失败人工接管判定已实现，补充工作台完整提交回执核对，防止跨库完成回写异常误报。75项初始专项、真实独立PG升级/重启/事务验证通过；全套及失败项复测后1149通过、9项条件跳过（新增PG专项另行通过），最终兼容性专项和verify成功。本批应用未回移、未加载，不影响用户当前5178/8082测试；通知触发也尚未接线。等用户本轮测试结束后统一合并/加载，见CP2a证据。

2026-09-10 Proposal邮件会话原表与引用格式已修复

用户指定10:21:12邮件的会话页此前把3张原表压成纯文本。现从原任务上下文复用确切材料和已批准净化显示，保留表格对应与引用层次；已更新5178，3表全部单元格和全文与任务详情一致。235项前端检查及实际页面/刷新/返回验证通过，无重启或业务写入；见证据。这是单邮件引用格式修复，不是多消息归并。

2026-09-10 新版C1三种配额邮件成功；签名图为未登记版本

本批5项/12项/3项旅行社邮件均直接7次读规则、一次解析成功、Layer6通过、各一张Proposal任务（核查时已办理），约2分07秒/2分11秒/2分15秒。另一封为酒店回复，入口失败未进Agent。用户图片实际出现在候选区：绿色徽章横幅与图库黄色徽章版不同，同封其他固定图已过滤；建议仅补该确定版本，本次不改图库/应用/配置、不运行或办理。见证据。

2026-09-10 Proposal邮件会话返回入口已更新5178

会话顶部增加“返回任务详情”，准确回到进入时的Proposal卡片，保留分类和搜索；刷新、加载失败时仍可返回。前端226项、类型/构建/Lint及5178实际往返验证通过。只同步6份页面/语言/测试文件，无后台修改或服务重启；见证据。

2026-09-10 通知前层准备度：主链已接通，可以继续衔接；未全场景验收

只读确认新版两次邮件的Parsing、Booking、检查均成功，实际各一张VALID的Proposal人工卡；普通QBD也已有全程成功证据。可以继续通知CP2，但保存失败漏判、检查恢复无最终上限、技术失败转人工的区分仍须补齐。近7天当前酒店28条全部手动上传，自动收件和多消息归并尚无本批实际验收；8月23日QBD失败样本也未见新版同样本复验。不改应用/配置、不重启、不运行或发送、不使用子智能体；见准备度审查。

2026-09-10 C1新版同邮件两次成功；右侧原为旧任务，引用展示与会话拼接仍需区分

2097888091752239105与前次2097885308416299009为同封9月2日EML，均直接7次读规则，最新12项完全一致、Layer6通过、各一张人工卡；总耗时分别3分40秒和2分55秒。用户右侧原打开8月31日旧任务，已另开最新9月2日任务并确认页面包含当前表及下方两层引用旧表。当前是单EML自身引用展示，两次测试会话各自独立，未验证多封自动归并。只读核对及打开页面，无任务/代码改动，见补充证据。

2026-09-10 回放全部历史、分页、处理结果与永久保留：待统一加载

本任务已实现今天/近7天/近三个月/全部历史、每页30条、返回保留筛选和页码；列表新增成功/失败/处理中结果，正常人工结果仍为成功。旧7天/3个月读取限制和定时日志清理已撤除，MySQL V40/Booking PostgreSQL V20准备好但尚未应用到实际数据库。90项专项后台、20项前端、类型/构建/Lint和隔离PostgreSQL历史内容保真验证通过；后端全套最终汇总1136项通过、8项条件跳过，package通过。用户稍后指定统一加载任务，本任务不单独重启8082。预览5189使用实际页面组件和演示数据；因电脑锁屏，浏览器截图验收待恢复。见本批证据。

2026-09-10 C1更新后同一引用历史邮件验收通过

Replay2097885308416299009与上次9月2日邮件原件相同，C1使用新版47f59fa2…并直接7次读取自身规则，无绕路搜索；125秒成功提取最新12项，新旧房量逐项相符、历史旧表未进入当前材料。Booking引用全部6条最新业务材料，Layer6 VALID，实际仅一张Proposal人工卡，完整引用历史仍保留。全程约2分55秒，比上次少8分03秒。本单EML当前/历史区分验收通过，不扩大为多消息拼接或所有场景稳定性结论；见复验证据。

2026-09-10 9月2日含引用历史样本：任务与原文保留成功，解析验收未过

8月31日原始邮件全流程成功；9月2日Re邮件Parsing未读到规则并在连接恢复异常后耗尽约10分钟，未产生提取材料。Booking依当前整段正文返回一项Proposal，Layer6通过，实际一张人工卡且新旧正文完整保留。未额外生成历史任务，但整段引用不能证明仅选中最新12项，不能报完整历史区分通过。两封各一张来自独立上传，先继续既定Parsing配置修复再复验，不扩大范围；见两封证据。

2026-09-10 回放详情已显示上传EML名称

现有详情标题下直接显示“上传 EML：原文件名”，复用已返回数据，刷新仍保留。18项相关检查及类型/构建/Lint通过，5178真实Pro.eml页面已验证；前台45022和后台63959未变，两端健康，无需重启服务。见证据。

2026-09-10 Parsing自身规则入口配置包已完成，待手动配置

四次成功运行的公开工具参数已确认使用同一Parsing Skill完整入口；失败运行未读到自身Skill/Schema，部分成功运行还曾绕路读取Booking规则。现仅修改Main Prompt，要求直接进入自身Skill并按其顺序读取必要规则，规则定位时停止目录/知识库搜索和Booking Skill误读。现有Proposal、普通预订、Excel规则及输出格式均未修改，Skill无需重新上传。27项配置检查、9成员Skill复现及3文件ZIP完整性通过；没有配置平台或运行Agent，稳定性待用户配置后验证。见交付证据。

2026-09-10 QBD带Excel复验：Parsing失败，Booking派生扣减无关联而拒收

Replay2097874269977055233为8月23日QBD邮件，93条确定性事实及7个实际团队保留；Parsing未读自身规则，公开回答仅一个反引号。Booking读到规则但给全部7个团队派生LTQ260826扣减，输入关联关系为0；当前部署离线复现明确因缺少source/actual关系拒收。约4分53秒失败，Layer6未执行，实际任务0。继续已有Parsing配置包修复后复验此样本，不顺带修改业务检查；见证据。

2026-09-10 当前EML上传不能验收多消息会话拼接

前后端只允许新投递真实双Agent测试，每次上传都生成独立会话；四条现有回放已核实。系统已有会话History读取能力，但当前上传页无法用多份EML验证其衔接。单封正文引用历史是不同场景，酒店回复渠道不匹配也是独立限制；不合并进Parsing配置包修复。仅只读诊断，见补充证据。

2026-09-10 四份Proposal相关日志：三封调整成功，酒店回复被入口范围挡住

5项、12项表格调整与3段带住期/TWN调整均完成双Agent、Layer6及各一张实际Proposal人工任务，材料完整且Booking接收顺序正确。Parsing仍反复找规则，第一封先读另一角色Skill再读正确规则；优先稳定规则定位，不收紧Layer6。第四封是酒店确认回复，原件已保存但当前固定渠道名单不匹配，两位Agent未启动；外层错误提示未说明适用范围。首次创建配额样本本批尚未覆盖。本轮只读诊断及证据维护，见四封复核。

2026-09-10 同邮件两次复验：第二次成功，Parsing规则读取差异已定位

五配额各70→60邮件原件指纹相同，Parsing/Booking平台版本号分别相同。第一次Parsing查找规则未果并返回不符格式；第二次成功读Skill、Schema及业务规则，完整保留材料。两次Booking、Layer6及一张Proposal人工任务保存均成功，证明保存修复有效。当前回放API两条均COMPLETED，与导出日志顶部快照不同；第一条Parsing拒收事实仍保留。下一步查规则每次可获得/可读取的稳定性，尚未区分平台未提供还是Agent未找到。本轮仅诊断，见对照证据。

2026-09-09 Proposal保存修复已生效，真实任务已生成

V19补齐候选表Proposal类型，Layer6内部失败独立归类；后台63959已加载，前端45022及原业务数据保持。28项定向含实际PostgreSQL复现通过，完整1140项无失败/错误。原邮件复验中Booking、Layer6和工作台保存通过，一张人工任务完整显示12项调整并保留待办理。但本次Parsing返回输入格式而被拒绝，回放总状态仍FAILED；新Parsing问题未纳入本次修复，不能宣称全链全部通过。见修复及复验证据。

2026-09-09 待处理列表真实团号显示已修复

用户指定仅修改团号：现读取已保存业务团号，没有则留空。5178已更新，34张业务卡逐项核对一致，原17张内部编号已纠正；任务数据和状态保持。前端215项、后端1087项（1080通过/7条件跳过）及实际浏览器检查通过。复核说明保持现状，5190继续可用；见修复证据。

2026-09-09 Proposal真实回放：Agent已衔接，任务保存缺类型支持

用户已配置C1/C2；最新真实回放中，两位Agent成功传递12项配额调整并形成一项Proposal候选。实际数据库仍只接受旧业务类型，漏了PROPOSAL_ALLOTMENT，本次Layer6完成过程保存失败、任务行数0；公开日志又误归为Agent连接异常。仅完成只读定位，修复/任务展示及办理复验待继续。这是下方历史“尚未配置/全流程待验证”状态的最新进展，见实际证据。

2026-09-09 独立失败提醒能力CP1已完成，触发待接

已完成内部失败提醒登记、固定内容、持久去重、独立发送/有限重试、受理/暂停/不确定记录与私有配置读取。50项本功能检查和隔离整体回归通过，28个新增文件已回移，未改前层业务流程。当前运行未加载、通知关闭、没有真实发送；CP2再衔接最终失败判断与真实联调。见交接和证据。

2026-09-09 Proposal确切版本原HTML已补齐并加载

原始/重复投递版本按任务回执读取，表格单元格和跨行跨列原样保留；B完成文本/表格净化。A定向62项通过，完整1086项（1079通过/7跳过）；B按用户确认统一加载5178/8082，24张Booking表及10张来源/任务业务表指纹保持。见发布记录及对接说明。

2026-09-09 Proposal Allotment Booking 配置文件已交付，尚未启用

主提示词、完整V3 rc3 Proposal Skill和A一致的结果格式副本已准备，供用户手动配置。保留必要规则读取、普通预订目标与原配额使用/取消规则；没有改运行应用或平台。9项打包、48项配置/格式与66项隔离系统检查通过；三份构造样例一封一项且VALID人工办理。C2此前使用的33/4/7是按行构造的交接材料；C1最终按现有标点分段得到33/6/8，两种验证都不把条数当业务条件。C1实际输入与新版Booking实际输出尚待统一联调，不能把构造验证视为真实运行通过。见交付证据。

2026-09-09 Proposal Allotment Layer3 Parsing候选配置已完成，未发布

本轮只调整Parsing Agent独立Main Prompt和QBD Skill相关规则：创建/调整配额的局部正文表格完整进入消息级原文材料，不拆普通预订，不新增字段；同封真实团队、配额使用、明确取消、附件事实及History边界保持。产品复核后，Main Prompt整体收敛为4条岗位说明、9,262字节降至1,394字节，详细业务细则全部留在Skill，行为不变。程序解析、现有结果格式、Booking Agent、Layer6和员工页面未改。

三封真实EML完成只读材料核对和既有输出格式承载检查：创建31项按当前证据分段预计33条有序原文材料，调整5项预计6条，调整12项预计8条；条数会随标点分段变化，不是业务判断条件。27项配置测试、Skill校验及确定性打包通过。候选包位于本地artifacts/parsing-agent-proposal-allotment-20260909/，保持HOLD/INTERNAL_ONLY。没有替换平台配置、调用Agent、回放邮件或运行完整业务流程，因此上述预计结果不是实际Agent输出。见实施证据。

2026-09-09 Proposal Allotment同一页面已更新5178

用户确认5190样式后，同一页面连接A任务、确切原表和办理/忽略动作，14份正式文件逐字对应验收候选。214项前端检查、类型/构建/Lint零错误通过；5178现有列表、详情及邮件入口正常。5190保留，临时5191已停。实际邮件全流程待Agent配置启用后联合验证。见发布记录。

2026-09-09 最终失败通知方案已交付，尚未接入

本轮按用户要求仅提供方案与私有Token配置，ID=9998。触发范围覆盖自动处理全链最终技术失败，排除正常待确认/补充/Proposal人工；通知持久去重、独立重试。现有总体失败判定有三处缺口已记录；接口无幂等键，结果不确定时不自动重发。配置默认关闭，应用尚未读取，无真实发送或运行变更。后续实施与联调由用户继续安排。

2026-09-09 Proposal Allotment 系统与页面已加载，配置联调待继续

A提供结果接收、邮件级人工任务、来源检查与仅记已办理动作，B已连接原表和页面并统一加载；不写普通预订或配额。当前Agent候选未启用，实际邮件到任务和办理的全流程尚未验证。见发布记录及对接说明。

2026-09-09 回放人工处理状态展示已修复

自动处理完成并需人工补充的记录，顶部和Layer6现显示完成标记，数量使用中性“11 项”；真实失败和未知警告保留。188项前端回归、类型/Lint/构建及5178实际记录检查通过，前端已热更新，无后台重启。见显示修复证据。

2026-09-09 同邮件复验：Booking规则读取恢复，自动处理成功

Replay2097623984166076417与上次失败EML指纹相同、平台版本相同。Parsing和Booking成功，Booking已读10份规则/Schema，完整输出0格式错误；旧10项小房量New/Update判型和Allotment整块取消均纠正。形成16项确认事项，11项FIT因缺Name 1需人工处理、5项待确认；只读确认工作台投影SUCCEEDED，自动流程terminal=true，总3分37秒，较前次快约1分7秒。

本次验证修复在此样本生效，不扩大为全部邮件或取消身份均已验收。日志仍有回放登记PROCESSING与正式AWAITING_CONFIRMATION不一致的展示口径，不能解释为自动流程未结束；已记录，未改代码。见复验结果。

2026-09-09 Booking规则读取修复已加载，可以继续5178测试

用户最新要求立即独立重启后，已在处理队列空闲时加载本项已验证候选；后台由44830切换为49370，前端45022保持。8082健康和5178转发健康均200；当前运行包包含先读Booking Skill必要规则/输出Schema的说明，已移除全禁工具文本。新旧包仅Booking适配类/匿名内部类及构建时间信息不同，其余文件逐字一致，没有带入另一任务未完成的修改。

配置保持，H2停机备份已保存；重启前后H2 10张业务表及PostgreSQL 24张表行数/内容指纹一致，5类执行状态均为空闲或终态，启动没有数据库迁移，5张目标图仍正常加载。此前1068项通过/7条件跳过的验证有效；没有调用Agent或新回放邮件。现在可在5178测试同一封邮件，修复是否解决全部Booking业务输出偏差仍需真实复验。另一任务后续加载需保留本次两源文件修复。见加载证据。

2026-09-09 Booking新配置复核：系统出站说明仍禁止读取规则

平台版本确已更换；进一步查明系统每次请求仍附加“do not call tools”，与新版Booking Skill要求读取必要规则/Schema冲突。当前运行JAR类文件已确认含相同文本，本次公开日志零工具事件。这是系统侧已证实的说明冲突，但尚未证明为所有错误的唯一原因；应先统一系统调用说明并复验，不能让用户仅重复上传平台配置。本轮只读定位及文档记录，代码、配置和运行均未改。见补充证据。

2026-09-09 新QBD回放：Parsing成功，Booking完整但返回不合规则

Replay2097611653642182657已失败结束，284151ms；Parsing108954ms成功，Booking171015ms后拒收，尚无投影。Booking三份2963字符原文一致完整，系统没有丢尾；55处输出格式错误、10项小房量New/Update误判GROUP、Allotment整块取消误普通类型且关联不符。版本已变为3c9a60ea，但公开日志无规则读取事件，需按本次thread6683f18f/原run核对规则生效情况，不能断言唯一平台根因。仅分析/文档，无代码配置或新运行。见本次证据。

2026-09-09 图片、Parsing恢复与固定文字过滤已统一加载5178

产品负责人授权后，当前本地测试环境已同步重启5178与8082。新版本同时加载：5张指定目标图及整图变体过滤、其余邮件图片人工查看、Parsing断线恢复接回、QBD/LianTai固定提醒和签名文字过滤；既有附件下载、忽略、任务详情布局及确认后返回原列表全部保留。后台PID 44830、前端PID 45022，两端健康检查均为HTTP 200，后台启动确认加载5张目标图且没有数据库迁移。

最终统一候选后端1075项（1069通过、6项条件跳过、0失败/错误）、前端27文件184项、类型、Lint及生产构建均通过。切换前五类活动处理均为0；精确停机H2快照与启动后8张核心业务表的行数、状态和内容指纹一致，PostgreSQL处理、Parsing、投影、回答及业务产物也完全一致。构建期间曾有一项正常人工确认发生在停服前，初始任务卡20变为19；它不是切换产生的数据变化。

当前已有邮件数据没有图片记录，所以现场页面只验证了“没有图片时不显示空区域”，候选图片接口正常返回空列表；5张目标图、压缩/缩放变体和水牌反例已经在隔离验收中通过。既有177186字节附件仍可下载。本次未上传或回放EML、未调用Agent、未操作真实任务或更改外部Agent配置；现在可以继续正常测试和修改。详见图片切换证据、Parsing恢复证据和固定文字证据。

2026-09-09 本地调用取证：14:47完整回答与15:57手工缺尾不能混用

按用户提供SQL在实际Booking库完成只读查询：仅invocation10命中，14:47:30至14:49:17、provider run 57623b6e-0c0f-4b45-95ab-8144aa62f311；15:50–16:10无系统Booking调用。journal已收到完整2784字符，失败是12个目标为空；invocation原文字段为空不等于未收到答案。手工2776字符缺尾仍需平台定位自己的run。完整SQL/JSON/CSV和可转交说明已放项目artifacts内，未执行新测试或运行变更。见查询证据。

2026-09-09 附件显示已精简

附件区域去掉格式/大小说明，文件名改为较小的常规字重；任务详情、来源项和邮件会话保持一致，下载方式不变。当前5178已更新并完成真实页面只读检查，65项既有检查及类型/Lint通过；无需重启。见附件证据。

2026-09-09 固定邮件提醒及签名过滤已实现并统一加载

用户已明确批准 QBD/LianTai 两套固定内容。独立副本完成 Parsing/Booking 当前及History文字过滤，并同步剔除Parsing摘录，保持canonical身份/证据/恢复与全部业务材料。六封实际EML的12种纯文本/HTML形式全部离线通过，未知/变更内容保留；QBD签名区域内和标题同一行的Allotment要求保留，签名夹图仍由图片规则处理。随后已纳入最新统一运行版本并加载当前8082；未用真实EML触发Agent，实际出站效果留待下一封正常测试邮件。验证明细见证据。

2026-09-09 确认后返回原待处理列表已修复并更新当前页面

普通确认、人工复核确认和来源项确认成功后，回到进入详情时的列表/分类，保留搜索并显示“已确认”；同步移出待办，失败留页重试，旧响应不拉回已离开的页面。原业务确认规则和接口不变。 独立前端副本184项/27文件通过，实际路由验证详情退出与列表呈现；类型、构建和Lint无错误。5个文件经哈希保护同步，5178已读取新模块、8082健康；本任务未重启服务或修改切换配置，图片/Parsing组合切换仍由原任务负责。见修复证据。

2026-09-09 Booking再次手工QBD：完整返回检查通过，待系统统一复验

补充复核：原Schema缺尾日志在14分06秒后再次导出，回答仍逐字相同的2776字符，未补齐结尾；内容差异仅时间/耗时信息。延后导出不支持单纯下载过早的解释，但无最终元数据，仍不能判定模型、平台保存/传递或导出缓存的责任。与下述完整样本分开记录。

最新Booking Business Decision (2)输入与上一份手工日志完全相同，完整公开回答2787字符，通过严格JSON及系统结果Schema；12项修改（6 FIT/6 GROUP）与1项Allotment整块取消均与上次一致，前2776字符逐字相同，这次正常补齐结尾。6项FIT缺姓名仍需系统后续正常人工复核。此次平台样本通过不代表API接收、断线恢复或任务投影已验收，也不能反推上次缺尾原因；用户要求先完成切换再统一验证。本轮仅分析日志，未改应用、配置或运行。见最新平台复核。

2026-09-09 Booking Agent目标规则包已更新，交由用户平台配置

V3 rc2主提示词与完整Skill已交付下载目录。明确New/Update/Cancel必选已有target_ref、unit_ref仅输入，保留Rooming/Allotment专属引用；按ADR024清理普通多住期误转Risk的残留。系统Schema未改且包内逐字一致，打包阻止混入旧Schema。 9项打包回归、17项格式/真实输入对照、技能与确定性检查通过；未调用平台或新邮件，用户仍需替换主提示词和旧同名包并发布。Parsing系统修复由“固定图片”任务统一加载，平台配置后再结合复验。详见配置包证据。

2026-09-09 Parsing恢复拒收已修复、验证并统一加载

用户认可修复后，只在已知run恢复场景允许唯一消息后缀与完整final对应，仍要求同run/完整最终事件/success/end及严格Decoder；歧义、错身份和不完整结果继续拦截。Transport46项、完整verify1061通过/6条件跳过；真实失败的两次恢复现均离线接回逐字相同5723字符，未结束反例继续拒绝。 该修复没有用旧补丁覆盖服务，而是随正式项目最新源码统一构建并加载当前8082；运行包已确认包含恢复入口，同时保留附件下载、忽略和其他已批准功能。旧记录未回填、未重放，Booking规则未改；真实新邮件恢复效果留待后续正常测试。见修复证据。

2026-09-09 系统内附件下载已修复并切换完成

任务详情和邮件会话现在点击附件名称即可下载原件，失败可重试。167项前端、1028项后台通过/5原有条件跳过，20项并行图片兼容检查通过；空闲切换后两处实际浏览器下载均取得177186字节原xlsx，哈希与保存原件一致。 切换前后环境、原始回答/业务数据、21张卡/49工作台项/10确认记录及就绪状态一致，邮件测试可继续。保留当前布局、忽略及并行图片源码，不擅自启用其他任务待切换图片后台。见验证证据。

2026-09-09 Booking成功对照补核：同配置同旧规则也曾通过

上一封LianTai与失败QBD采用同一Profile/version，公开主说明、旧输入规则、旧结果schema摘要均相同；上一封3个决定填齐目标并正常结束，本次12个决定目标全空。目标缺失是直接失败原因；共同存在的规则冲突是已确认隐患，但尚不足以单独解释两次不同输出，不能保证仅同步规则即可闭合。已收紧前述归因口径，Parsing恢复缺陷独立成立。只读核对，无运行或配置变化，见成功对照补核。

2026-09-09 Booking平台日志补充：失败运行实际读取旧规则包

QBD原run的read_file返回确认平台读取compact-v1输入/结果schema及unit_ref旧业务规则，而系统提供并要求compact-v2目标选择，版本冲突能解释12个目标全部留空。用户新手工日志来自前一封LianTai的5目标输入，模型发现冲突后自行适配；虽填齐目标，却把先前2项多住期风险也输出为业务决定，不能视为同一次失败复验或业务通过。需同步完整Booking规则包并另修Parsing恢复接收；本轮只读对照和记录，无代码/配置或运行变化。详见平台规则对照。

2026-09-09 后端Java图片测试抢焦点已修复

系统日志与Surefire报告确认原Java Dock闪现来自测试JVM。server/pom.xml已在测试启动时固定-Djava.awt.headless=true；定向20项通过/2项条件跳过，无本次测试进程前台激活记录；完整verify为1029项通过/6项条件跳过，构建成功。8082原服务持续运行，无业务数据或系统权限更改。见修复证据。

2026-09-09 来源邮件目标图过滤与员工人工预览已实现并加载

产品确认的5张目标整图已复制到仓库外受保护运行目录，原文件未修改且逐份内容校验一致。系统只过滤这些目标图及其高置信度整图变体；水牌等仅局部带Logo的业务图片、同尺寸不同图片、低置信度或读取失败图片全部保留。员工可在任务详情和来源通知详情的附件下方查看候选图片，底层存储地址不进入页面；Parsing Agent继续只接收既有文字与结构化材料，不接收图片、图片地址、指纹或过滤结果。最终统一候选后端1075项、前端184项及生产构建通过；当前5178/8082已同步启用并加载5张目标图，没有数据库迁移。现有邮件没有图片记录，已验证无图时页面不占位；下一封带图邮件再做真实页面验收。详见ADR-038与证据。

2026-09-09 14:49 QBD测试失败：确认接收恢复缺陷及Booking漏填目标

Replay2097577017700503554的Parsing完整5723字符已由平台返回，连接握手中断后的两次恢复仅含回答后缀，本系统前缀匹配拒收并耗尽3次worker尝试；当前部署JAR离线已复现。此前平台缺尾与本次完整回答被拒收是不同场景，本次确认本系统恢复接收需要修复。 Booking完整2784字符已接收，但12项UPDATE的target_ref全部为null，尽管输入提供T1至T12；部署必填门禁逐项复现拒绝。4分07秒失败结束、Layer6阻断，无待确认投影。只读诊断和离线验证，未改业务代码/配置、重跑或重启。详见双失败证据。

2026-09-09 附件打不开：展示已有，打开能力尚未接通

详情附件仅为文件名/大小；邮件会话只为HTTP(S)地址提供链接，本地EML附件因file引用也不可点击。样本原文件存在且177186字节与记录一致、XLSX完整性检查通过。这是既有能力缺口，布局修正未移除下载；本轮仅诊断，没有改应用。见附件排查。

2026-09-09 任务详情布局已按5174修正并更新当前页面

移除旧办理概览/卡片进度、正常可处理横条和住期删除入口；恢复Basic三列、New/Update横向字段及修改前只读区，来源邮件后保留忽略/确认。此前只统一外壳而漏做实际详情布局对照，已修正文档完成口径。 包含并行邮件图片前端代码的160项检查、类型与构建通过；只读核对真实新建/修改详情，11个本任务前端文件经哈希保护同步。后台没有重启，用户邮件测试可继续，未操作真实卡片。详见布局修正证据。

2026-09-09 14:30新EML自动处理成功，耗时约5分05秒

Replay2097572118984118274的双Agent完整JSON及四份返回逐字一致，Layer6/待确认投影成功；3个预订待确认事项（2修改、1新建）及2个人工处理风险项，未确认或调用PMS。本次缺尾未复现，旧根因和长期稳定性未据此闭合。 Parsing91.228秒、Booking208.456秒，共占98.36%；Booking平台调用208.297秒，本系统接收校验0.135秒。已识别接收警告为正常排队、Booking文件搜索一次可恢复错误、导出replay_status与terminal/业务终态不同步；只读日志分析，未改代码配置或重跑。详见本次结果及耗时。

2026-09-09 忽略待处理卡片已切换至当前测试环境

用户批准待确认和人工处理项可忽略，其他通知不变；详情确认按钮旁增加忽略，持久出队并保留原内容，不加撤销/恢复/忽略人/历史入口。 独立副本实现与后端108项定向、全量1016通过/5原有条件跳过、前端156项及类型/构建检查通过。合成浏览器验收确认单卡计数、返回原分类、保留兄弟卡和已忽略只读。 用户回复“现在切换”后，14:06在处理队列为空时同步43个本任务文件并加载已测版本；后端PID32421，前端原PID10488保留。健康及邮件处理就绪检查正常，配置和数据位置未改；33项待处理（待确认3、人工29、其他通知1）、10条预订记录及原始回答/自动处理终态的切换前后校验均一致。浏览器只读核对两类详情有忽略、其他通知仅确认；未实际忽略或确认任何真实卡片，可继续测试。并行调查文档保留原变更。见ADR-037与验证证据。

2026-09-09 最后模型响应元数据尚未公开，尾部对照已提取

最新失败Parsing的最后model公开结果只有前500字符摘要，缺response_metadata/usage_metadata；早期tool_calls停止原因不能代替最终响应。当前（18）手工页面也只有汇总用量。两次回答末尾300字符及失败run/thread/最后model任务身份已整理，需平台从原始AIMessage/检查点取元数据，缺尾根因仍未闭合。详见元数据提取证据。

2026-09-09 新手工Parsing输出（18）：内容完整，格式与运行条件仍需区分

用户13:06手工调试的内部JSON与前两次成功结果逐字相同，现有Decoder及6份材料引用核对通过；导出此次增加代码围栏，保留围栏离线校验失败，尚无本次API原文确认是否同样携带。 已展开页面思考，确有反复核对同一排序问题，但本次写完了结尾，不能解释旧失败。页面模型选择项DeepSeek V4 Pro与先前草稿Qwen3.7 Max不同，未取得当次实际模型/版本，不能当同配置复验。仅只读和离线验证，未改代码配置或重跑，旧API缺尾仍待原run模型输出/停止原因。详见第三份手工测试证据。

2026-09-09 已登录平台界面核查：配置已读，历史模型原文仍不可见

两位Agent当前草稿均为Qwen3.7 Max、150轮、3600秒；Parsing明确要求完整JSON。模型高级参数当前为空，未显式设输出上限/停止词，但未取得历史版本和有效调用参数，不能据此排除运行默认限制。 当前管理员会话入口没有列出这次API运行；直接只读调用记录地址被浏览器拦截，未取得模型最终原文/停止原因。平台诊断旧失败不解释本次缺尾；具体根因仍待平台原run数据。 本轮只读界面，未发送测试、保存发布或修改配置。详见界面核查证据。

2026-09-09 最新代码已按用户指令推送正式仓库

正式仓库Wyndham-RSVN-0908的main已收到代码提交0892b09499f214e070479b4d31c78314c14058eb，远端回读与本地一致。本批114个文件包含统一处理记录、通知专用测试支持、日志准确性修复及对应测试/文档。 发布前前端151项及类型检查通过；后端源码逐文件与本轮1009通过/5条件跳过的打包副本一致。提交树凭据扫描通过，仅归档源码、合成测试和文档，未包含本地配置、运行数据、依赖或构建产物。此次只提交推送，不重启或改变现有5178/8082；继续当前业务测试和平台回答缺尾排查。

2026-09-09 日志三项准确性修复已加载5178测试环境并完成只读核对

用户确认现有日志给助手分析基本够用，本期仅修正已保存却标未保存、未知用量显示零、自动完成耗时变化；同一终态问题中的Parsing失败提前停刷一并修正，不实施此前广泛日志增强建议。 独立副本实现并打包，最终1,009项通过、5项原有外部验收跳过，无失败。保留真实原文，按同一次调用核对保存和用量，使用实际自动结束时间，后续员工确认或查看不延长耗时。无Agent或业务规则变更，无真实EML重跑。 源码已逐文件核对并同步至正式项目，保留既有与并行修改。用户回复“现在切换”后确认队列为空，仅重载8082至PID27766；5178仍为原PID10488。服务健康、酒店身份和全部就绪字段正常，环境文件hash及数据位置未变。 7条既有记录的原始回答逐条hash均未变；有保存事实的两类回答均显示已保存，未知用量为null。原异常耗时872248ms按PG真实自动结束时间纠正为273183ms（页面273.2秒），重复读取稳定且列表/详情/日志一致。没有新EML执行或外部Agent调用；可继续测试。平台回答缺尾仍是独立问题。详见修复证据。

2026-09-09 平台服务器日志补充：续传警告已关联，缺尾根因仍待模型原文

用户提供的rizhi(1)准确覆盖最近两次Replay的四次Agent运行，全部由平台标记success。 其中三次恢复接收时提示原事件ID不在保留缓冲中；三个ID都能在本系统此前原始接收日志找到，需平台核查续传保留/ID处理。 最新Parsing没有重连仍缺尾，因此续传不能单独解释全部问题。附件未含模型最终回答、实际停止原因或输出上限；优先用最新Parsing原run对照模型原文与平台最终保存/公开回答。 只读核对和证据更新，无代码/配置变化；详见平台日志对照。

2026-09-09 已独立排查Agent回答接收侧

绕过本系统直接GET平台原运行：最近两次的四份回答均已缺尾，与系统保存内容逐字/哈希相同；HTTP外层JSON和响应长度完整。较早成功Booking对照仍为完整JSON。 未发现本系统接丢、拼接或保存截断；现有接收/恢复/日志28项与部署Parser离线23项均通过。直接读取旧run事件流超时，未作为通过证据；平台内部为何提前结束仍需模型原文及结束原因。 详情因前一步失败提前停刷是已确认的本系统独立缺陷，本轮未改实现。仅只读诊断/离线验证，无新Agent运行或配置变化。详见接收侧排查证据。

2026-09-09 配置调整后再次测试仍失败（12:00结束）

Replay 2097534457943396353已监听至终态，总计216326ms；Parsing与Booking实际Profile版本都变化，确认本次用了新版。 Parsing最终回答含review_requests空数组但少最后结束括号；Booking在最后unclassified_texts字段名中截断。两类四处公开/保存回答均一致且平台报success，系统拒收，Layer6阻断，无新任务或工作台项。 详情提前停刷同样复现，已手动刷新至最终结果。用户具体修改的配置项尚未说明，不能推断截断根因；仅监听和记录，无应用/Agent配置改动。详见配置后测试证据。

2026-09-09 新EML现场监听：双Agent缺尾，自动处理已失败结束

用户在侧边5178自行上传执行Replay 2097530868537724929，本对话监听至11:46:24（+08:00）结束，共276925ms。 Parsing在review_requests字段、Booking在unclassified_texts字段后缺尾，两类公开final/流片段/run快照/保存回答一致且平台报success；系统拒收，Layer6被阻断，本次无新增工作台项或任务卡。 另实证详情在Parsing失败时提前把terminal设为true并停止刷新，后台Booking仍运行；结束后手动刷新才显示最终失败与完整耗时。 本轮只监听、核对并刷新查看，没有重新执行/修改代码或配置。后续需核对系统API与平台手工运行的输出/结束差异，并修正提前停刷；日志充分性评估仍在独立对话。详见现场测试证据。

2026-09-09 AgentBus日志充分性评估完成（后续仅批准准确性纠错）

现有原始返回足以核对失败阶段和回答缺尾。用户随后明确日志由助手分析，基本够用；广泛增强建议不作为本期待办，仅批准三项已确认错误信息的纠正，见上方修复状态。 不扩展原输入留存或新增状态标签/产物汇总；平台未公开的结束原因仍不能由日志推断。详见评估证据。

2026-09-09 最新LianTai测试：Parsing返回不完整，部分任务已生成

Replay 2097512443832668161的Parsing Agent最终回答停在review_requests字段冒号后，完整JSON无法解码，系统拒收并记录INVALID_PROVIDER_RESULT。 公开final、run快照、该message流片段合并与保存回答均一致；平台同时报success，日志缺结束原因/输出额度信息，尚不能确定平台为何提前结束。 后续Booking与Layer6成功，当前工作台已有2修改+1新建待确认卡、1条人工处理Risk通知。统一记录按中途系统错误显示异常，非员工待确认误判。 用户已返回两份Parsing平台手工日志，均完整且通过现有严格解码、6条材料及引用核对；第二份已包含原6行指令，最终回答与第一份逐字相同。输入仍有同样空格差异，旧run结束原因和系统全链复验尚未闭合。日志改造评估转独立对话，本对话继续测试跟进。 本轮仅只读排查，无新执行或代码/配置变更；继续5178本期测试与问题修正，通用发件人仍不在本期。详见排查证据。

2026-09-08 本期范围已纠正：进入5178集中测试与修改阶段

用户明确其他发件人的通用邮件处理本期不管。ADR-036、领域/架构、待办及上次核查中的范围残留已清理， 不再把它列为本期开发缺口、测试完成条件或上线阻断，也未安排未来开发。 当前本期主功能已实现：QBD/普通LianTai、OPFIT通知规则、三入口工作台、确认记录、统一处理记录与现有全流程详情。 下一步在5178做真实业务验收，发现问题后修正；自动监听来源和有Name 1/无Tour Code的FIT建档仍需真实样本。 正式数据库、账号权限、监控告警及部署验收在准备上线时处理，不阻断当前本地测试与修改。 最近前端151项通过，后端既有报告995通过/5外部验收跳过；最新代码尚未提交/推送，本次仅改文档。 详见修正后的完成度核查。

2026-09-08 OPFIT真实EML已通过手动上传通知验收

用户提供的通知专用邮箱EML已在5178按选择、预览、二次确认流程单次执行，Replay 2097274461007613954正常完成，耗时1.22秒。 Layer3/4及Booking Agent跳过，Layer5生成1条其他通知，Layer6通过；零Agent调用、零关联预订任务，通知仍待员工确认但系统处理已经结束。 统一记录来源为手动上传，收到时间为本次进入系统时间，异常筛选排除本条，耗时固定且终态停止自动刷新。

实际验收同时修复待办页进入时使用旧缓存的问题：进入其他通知即读取最新队列，列表与侧栏均显示新通知。 修复前复现的回归现已通过，7项相关测试、类型及生产构建通过；仅前端进入刷新改变，后端和Agent配置保持不变。 本机现在4条回放，开放待办29（人工28、通知1）；未重复执行、确认通知或生成预订记录。 自动监听来源新样本仍待后续获准输入。详见真实EML验收。代码未提交或推送。

2026-09-08 AgentBus双来源处理记录与通知专用测试已加载5178

AgentBus模块默认进入紧凑的“处理记录”，查询真实自动收件和已执行手动上传；仅显示系统接收时间、来源、发件人、耗时和详情。 支持今天/近7天、发件人及只看异常，正常人工业务结果不计异常。两来源在当前模块共享原Trace、输入输出、错误、生命周期与日志导出， URL保存记录身份与筛选条件；返回保留条件并刷新。列表按页面事件刷新，只有仍在处理的详情每10秒读取并在终态/离开时停止。

通知专用邮箱现可复用正式规则完成EML测试：Layer1/2保存材料，Layer3/4跳过，Layer5明确Booking Agent跳过且已生成一条其他通知， Layer6通过有效性校验；通知进入工作台即结束，不等待员工ACK，不生成预订任务或记录。其他发件人的通用处理已按用户最新要求撤出本期。 历史自动收件未保存的入口阶段及Parsing原始请求会明确标为未留存，已保存输出与公开日志仍可查看，不补造历史证据。

前端150项通过，后端完整package为995通过/5显式外部验收跳过、0失败/0错误；类型、构建、局部lint、Secret扫描与浏览器验收通过。 当前5178运行Wyndham-RSVN-0908前端，8082使用该项目最终JAR，H2 V38/PG V18已加载。原本地数据库/存储/JDK17/受保护env位置保留， Agent/Profile/版本绑定与Secret未变；原启动项及本地数据库已备份。本机3条旧回放完整保留，异常筛选仅1条原失败；详情刷新、返回与日志正常。 本轮未提交新的真实EML或调用Agent，自动来源与通知专用行为采用隔离验收；后续获准样本可直接从手动上传测试执行，不需再改绑定。 详细证据见本次验收。代码未提交或推送。

2026-09-08 5178已作为独立根历史发布到新仓库

唯一正式远端为 https://git.nianxx.cn/shiyuyun/Wyndham-RSVN-0908。在远端无branch/tag的前提下， 从最终5178源码树建立全新的main根提交31849411a8fde7b021153da5eff1d60b2717aa8a并完成首次推送； 新仓库不继承旧仓库约200个提交，也不包含旧branch/tag。停用的旧工作目录已移除origin，防止把两套历史再次推混。

新根提交物理排除5174页面、路由、组件、假AgentBus回放及其直接测试，同时保留5178三入口、真实AgentBus EML回放、显式DEV演示fixture、后端业务实现、测试、迁移和项目文档。发布树不含真实EML、环境文件、Secret、 本地数据库、日志、server/var、依赖、构建输出、打包产物或旧导入附件。发布前独立执行TypeScript检查和 production构建，435个模块构建成功；明文凭据扫描通过。AgentBus配置/Secret未改，未上传邮件、调用Agent或写业务数据。

2026-09-08 5178剥离收尾复核（独立仓库发布前快照）

5178正式运行面、production包和旧执行入口剥离再次通过核验：员工根导航仍只有待处理任务、预订记录、 AgentBus EML全流程回放；旧邮件导入、系统设置和旧Debug路由实页均不可用。前端205项、后端全量与沙箱受限类对账、 production/reference双构建、ESLint error gate和前端生产依赖审计通过；当前8082使用项目内JDK17，5178代理返回 strict/PG/双Agent ready且缺失配置为空。页面有单个EML选择器，预览前不写SourceMessage，本轮没有上传或调用Agent。

该时点可以用一封新的获准EML做受控模拟，建议使用唯一run label并只核对该回放关联结果；本地酒店已有28项开放待办和 10条确认记录，不应以全局总数判断新测试。当时同仓库仍保留5174 reference mode与不可达旧locale文案；这一源码级缺口 已由本文首段的独立根提取关闭，新仓库不再包含5174运行源码或假回放。

邮箱自动监听与手工回放统一展示已写入Active commitment，当前未改实现。该历史时点曾记录ADR-036；用户现已明确撤出本期； 6张缺Name 1 FIT、真实有Name 1/无Tour Code FIT样本及production/MySQL/监控/SCA门禁保持不变。

2026-09-08 5178两封真实EML受控闭环与运行隔离已验收

用户授权的QBD与LianTai邮件已按应用内受控导入串行完成，AgentBus端配置、Agent/Profile/版本绑定和Secret未改。 当前只有3条本轮真实回放历史且活动回放为0：QBD原回放因JDK 26 TLS失败并保留，切换项目本地JDK 17后唯一恢复回放完成； LianTai单次回放完成。QBD形成7条已确认Group记录、6张缺Name 1的FIT人工处理卡和1条已ACK通知；LianTai形成 3条已确认Group记录和1条已ACK通知。总计10条唯一TOUR_CODE记录，未猜补FIT姓名，未执行PMS/Opera/付款/库存写入。

5178常驻LaunchAgent遗漏正式mode的问题已修复并保留回滚副本；现在只有待处理任务、预订记录、AgentBus EML全流程回放 三个根入口，/prototype/br00和旧Rooming路由均不可达。前端205项、后端935项、两套build、静态检查与真实浏览器验收通过； 完整lint仍有569条既有格式warning，5174参考build仍有大chunk warning。production回放默认关闭，正式部署、认证/权限、真实MySQL、 监控/审计/保留、多节点限流及CI Maven SCA仍是上线门禁；6张FIT需真实Name 1或员工人工核实。

2026-09-08 通用发件人原方案已撤出本期

原全发件人产品与七层路由方案已被用户最新范围说明撤回，不再保留有效实施要求。 ADR-036仅作为撤回标记，避免历史资料恢复本期需求。

2026-09-08 5178迁移与本地安全加固完成（独立仓库提取前）

迁移后的代码基线已经收口：旧任务写入口现在要求登录、动作权限、当前酒店资源校验并记录真实操作者；来源材料只按认证酒店读取； 邮件正文对浏览器强制纯文本且不再下发原始HTML。旧邮件导入和旧Debug EML执行/历史接口已物理删除，V37只清理旧菜单种子并保留 已执行历史迁移。详情页异步请求增加完整资源序列保护；确认记录绑定组使用事务锁，最新快照更新带version条件。

5174/5178已按构建模式而非端口隔离。默认production包为437 modules、主包498.14 kB，扫描不到 PIMCHANOK、LT260807LC、pending-new-booking、/prototype/br00或fixture模块名；5174参考包仍能以487 modules独立构建。 5178 fixture在显式开发模式完全替代真实API，不混入线上分页结果。标准启动脚本显式关闭另一模式，避免继承shell变量污染。

员工导航按权限和服务端公布菜单显示，仍只有待处理任务、预订记录、AgentBus EML全流程回放三个根入口；多酒店账号可切换酒店， 正式登录账号可退出。待办两类数据源允许部分成功、最多读取后端允许的100页并明确提示截断；AgentBus终态采用约4分37秒的有界刷新。 登录新增单节点用户名+直连IP/IP双维滑窗限流；多节点部署仍须在网关或共享存储补全全局限流与失败告警。

AgentBus回放已从Spring Profile限制改为任意环境可部署、显式属性启用；production默认仍为false。用户确认AgentBus端的Agent、Profile、 版本绑定与所需配置已经完成，本轮保持不变；现有受保护的.env.local-replay已被新8082成功复用，未改配置或Secret。上线时保持AgentBus端 绑定不变，为production应用注入对应部署环境的受保护运行值、显式开启功能并验收权限/监控。权限、酒店、审计、保留和文件上限不变。

最终门禁：前端26文件/205项、后端干净全量933项（0 failure、0 error、5 skipped）、Flyway V1–V37、 Booking Skill 8项、Parsing Skill 25项、两套Skill source/archive/determinism、production/reference build、TypeScript、ESLint error gate与 前端production依赖审计均通过。新8082已加载当前代码：健康状态UP，H2 V37、获准Booking PostgreSQL V16；5178代理返回 strict_execution_ready=true、missing_configuration=[]、双Agent与PostgreSQL均ready、layer7_reserved=false。本地身份菜单已对齐正式 /agentbus/eml-replay路由，回放历史为0；未上传EML、调用Agent、确认任务、ACK通知或调用PMS/Opera。

当前剩余均是外部输入或部署门禁：用户提供真实EML/数据后的FRESH_DELIVERY → 待办 → 员工确认 → 记录闭环；真实MySQL V35–V37备份/ 冲突预检/迁移与并发压力测试；production应用保持现有AgentBus绑定并注入该环境的受保护运行值，验收显式开关、权限及监控；CI内有效的Maven SCA和多节点登录限流。 FIT同酒店同规范化Name 1归并仍是ADR-035已接受的业务语义及显式碰撞风险。完整修复证据见 2026-09-08-5178-post-migration-hardening.md；此前自检阻塞清单仅作修复前历史快照。

2026-09-08 5178已收口为三入口独立员工工作台（独立仓库提取前）

5178现在是后续唯一正式工作台，根导航仅保留“待处理任务”、“预订记录”和“AgentBus EML 全流程回放”。 新的employee-workbench模块承接5174白色紧凑布局和操作结构，默认只消费真实V4/确认记录/AgentBus API。 5174已以baseline/5174-final-20260907本地标签和分支保留为验收基线，新工作在 feature/5178-workbench-separation分支进行。

真实待处理列表统一适配业务卡与来源通知，但保持各自动作：业务卡由员工确认后才建立/更新预订记录， 通知ACK只出队。FRESH_DELIVERY AgentBus回放的可信终态现在进入同一工作台投影，PRESERVE_IDENTITY仍排除； 回放轨迹增加工作台投影与人工确认阶段。本次未上传或执行真实EML，等用户提供真实邮件/数据后再做运行时闭环。

FIT身份已端到端收口：Name 1必填，Name 2和Tour Code可选，记录以FIT_NAME + Name 1归属；Group继续以必填 Tour Code归属。MySQL V36新增类型化身份与唯一索引，保留旧记录并回填为TOUR_CODE；Agent Schema/Skill、 Layer 5/6、V4投影/命令/查询和前端均已对齐，不存在Tour Code自动填Name。

邮件导入、Debug EML、手工开票、系统设置前端、房表生成、旧Rooming List和旧工作台页面/专用服务已按无入口、无引用和回归结果删除。 历史Flyway迁移、通用鉴权/酒店隔离、SourceMessage、审计、Trace、V4和真实AgentBus底座保留。当前Rooming不再生成或确认业务卡， 新结果仅转为退役通知；中立附件Evidence保留供未来按标准规则重建。

5174演示数据已以显式DEV fixture迁入5178：7条待办、4条记录，不含Rooming卡或假AgentBus历史，默认关闭且只在页面运行内存操作。 验证结果：前端26个文件/200项全部通过，build通过，lint为0 error/560个格式warnings；后端直接相关10个类/169项全部通过， H2成功校验应用V1–V36；Booking Skill源验证、8项打包测试、确定性归档和Schema解析通过。桌面/移动浏览器核对三入口、 待办/记录/详情/AgentBus和无横向溢出通过。production是否开放回放延后到上线阶段评审，当前不放宽环境或权限门槛。

2026-09-07 5174已按FIT姓名主身份规则收口

5174任务详情现在只消费演示快照中明确的Booking Type：能识别时在页面任务名称旁显示FIT或Group，无法识别时不显示； 员工修改Quantity不会让标签自行切换，也没有增加1–4间/5间以上的确认时前端复核。Group继续以必填Tour Code作为身份且 不展示姓名；FIT使用带红色星号和字段旁错误的必填Name 1、可选Name 2，New/Update中的Tour Code改为可选。

FIT Cancel Booking和Trace演示卡已用Name 1/Name 2取代Tour Code填写区，并补为自洽的FIT演示数据。Update Booking继续作为 人工处理案例：邮件已识别并预填LLTQ260811Q10-A，但Name 1保持空白；员工必须手动把核对后的值填写到Name 1，系统不会自动 复制。正文、主题和附件的Tour Code已统一，避免把本案例继续误解为编号冲突。空Name 1会在字段附近报错并阻止本地确认。

本轮只修改5174演示页面、演示数据和直接测试，没有修改5178、Agent、后端、数据库、字段契约或真实连接。两个聚焦Vitest 文件54/54通过，前端生产构建通过；未运行全项目回归、浏览器自动化或截图，未创建Git commit。正式服务端仍要求Tour Code， Agent也尚未按“缺姓名进入人工处理”收口，因此本结果只代表5174产品样板。

2026-09-07 员工工作台发布总开关已删除

原有总开关没有对应的审核页面或人工放行动作，只会把已经完成并通过校验的正式邮件结果留在后台。当前代码已删除该独立开关、 production固定关闭配置，以及会继续拦住正式来信的隐藏条件。现在只要Booking正式处理能力正在运行，可信结果就会按既有分类自动进入 员工工作台；订单任务、人工处理和其他通知都遵循同一规则。

调试回放仍通过独立身份与员工工作台隔离，不会制造真实待办。结果校验、来源核对、重试、重复保护、权限及员工确认流程均未放宽。 opfit.liantaitravel@gmail.com仍只产生一条“其他通知”，普通LianTai和QBD仍按原规则处理。

相关工作台测试61/61通过，服务端跳过测试的完整打包通过。本次只修改代码、配置和文档，没有启动或重启服务，也没有处理线上数据。正式部署前需要只读盘点 历史上已经合格但尚未进入工作台的结果，明确其去向后再加载新版本；这是一次性发布检查，不是新的长期总开关。

2026-09-07 LianTai FIT发件人已改为只走普通通知

酒店确认 opfit.liantaitravel@gmail.com 的来信均无需处理FIT表格。当前代码已增加精确发件人分流：命中后保存 原邮件与附件供员工查看，但不打开或检查工作簿，不提取正文/附件字段，不调用两个Agent、主数据或Rate/Room，也不生成 订单、订单任务、任务卡、人工处理项或预订记录；系统只形成一条需员工确认知悉的GENERAL普通通知，进入“其他通知”。 普通 op.liantaitravel@gmail.com 和QBD仍走原提取流程，多邮箱或非法sender不会误命中。

本次聚焦及相邻回归24/24通过，覆盖精确sender、LLT*.xlsx仍不检查、零业务调用、纯通知投影、数据库重试不重复和 原固定渠道接管；服务端跳过测试的完整打包通过。扩大的35项组合中有2个既有BookingContractAssemblerTest仍按已退出的 旧Parser路径断言并报错，本次相关用例全部通过。没有上传真实EML、调用Agent、重启服务或发布生产。

代码规则已经完成，后续ADR-033已删除独立工作台发布总开关；正式处理能力运行时，该通知会按统一规则自动进入“其他通知”。 生产页面可见前仍需部署新版本并完成授权邮件验收。

2026-09-07 5178 FIT身份字段前端已按最新产品规则调整

5178订单任务卡现按已识别的Booking Type显示FIT或Group标签，无法识别时不显示标签。New/Update的FIT仍保留 可选Tour Code，但Name 1改为带红色星号的前端必填项，Name 2可选；Group继续以Tour Code为必填身份。FIT的Trace和 Cancel Booking不再把Tour Code作为员工填写区，而显示Name 1、Name 2。页面不会把Tour Code自动写入Name，缺姓名时必须 由员工手动填写或复制到Name 1；本轮没有增加1–4间/5间以上的确认时重新判型。

本轮仅修改5178前端及聚焦组件测试，未改5174、Agent、后端、数据库或字段契约。3个聚焦Vitest文件共7项通过，前端 pnpm run build通过。由于服务端当前仍对New/Update/Cancel/Trace要求Tour Code，且“无姓名进入人工处理”仍由Agent/后端 状态决定，姓名优先身份尚未形成完整端到端能力；前端没有伪造人工处理分类。

2026-09-07 8082与5178已加载正式确认联动

8082后端和5178正式前端已重启并加载本次“确认后归入预订记录”的实现。启动前确认没有正在处理中的EML回放；H2已从V34 顺利升级到V35，新版预订记录接口可正常读取，当前尚无员工确认产生的新版记录，因此列表总数为0。8082健康状态为UP，5178 预订记录页面返回200；回放能力检查显示PostgreSQL、Parsing Agent、Booking Agent、V2主链和严格执行全部ready，缺失配置为空。

项目固定配置中的远程Booking PostgreSQL再次在SSL连接阶段超时，因此本次沿用项目已有的本机专属PostgreSQL 15备用库 127.0.0.1:55432启动，PG结构仍为V16。只覆盖了当前后端进程的连接，没有修改.env.local-replay或代码。没有上传EML、 调用Agent、确认真实任务或写入Opera/PMS。

2026-09-07 5178正式确认与预订记录已完成持久联动

5178现已完成“点击确认 → 保存结果 → 归入预订记录 → 刷新后不恢复”的正式闭环。员工确认业务任务时，系统在同一次保存中冻结 Basic Information和卡片最终值，按最终Tour Code查找或建立独立的新版预订记录，并只把当前已确认任务归入该记录；任一步失败都会 整体撤销。相同Tour Code的后续任务会进入同一条记录，其他未确认任务不受影响。Risk/其他通知仍只完成通知处理，不创建预订记录。

邮件进入和员工确认前不再查询或创建旧订单，也不再让旧任务参与New、Update、Cancel判断。旧订单和旧任务没有自动迁入新版记录； 它们只保留历史兼容读取。5178的“预订记录”列表与详情现只读取新版正式记录：一条Tour Code一行，可按Tour Code或FIT预订姓名查找、 按Task筛选；详情只读展示一次Basic Information、全部已确认任务、Note和来源邮件，已确认卡片不再显示“确认”按钮。

后端三组聚焦测试合计45/45通过，覆盖确认后队列刷新为空、正式记录可查询、同Tour Code合并及FIT姓名搜索；前端生产构建通过。 5174样板、Agent业务判断、EML回放、Opera/PMS和真实运行数据均未改动；本轮未重启运行环境，也未创建Git commit。

2026-09-07 5174所有可见必填提示已统一为红色星号

5174本地样板中，字段标题旁原有可见“必填”文字已全部替换为红色*。通用编辑字段组件和Update Booking详情使用同一 .ops-required-star样式；“必填”只保留在.ops-sr-only中供屏幕阅读器识别。字段原生required属性、页面校验、错误提示和 确认流程均未改变。

5174聚焦Vitest为48/48通过，新增回归覆盖红星、无障碍说明和原required语义；pnpm run build通过，ESLint为0 error、 400 warning。实页Update Booking共13个红星，计算色值均为rgb(180, 35, 24)，可见“必填”节点为0，截图布局正常。 全量前端当前为379/384，剩余5项均位于未修改的5178 reservationV4Views.spec.ts旧按钮/校验断言，按本轮边界未处理。 5178、server/、数据库、Agent和接口均未修改。

2026-09-07 5174已收口为三类待处理入口

5174/prototype/br00现在只显示待确认、人工处理、其他通知三个二级分类。原Risk演示项已并入人工处理，因此固定8条样板为 5待确认、2人工处理、1其他通知；列表、详情标题和琥珀色状态统一使用“人工处理”。旧?category=risk链接仍兼容进入人工处理， 避免已有链接突然回到全部列表。

本次只合并员工看到的分类。Update Booking仍是可填写并确认的订单任务；原Risk项继续保持通知身份，只确认已处理，不创建或 修改预订记录。Payment证据页仍不进入当前8条待处理样板，其他通知继续单独显示。没有新增后端字段，也没有修改5178、server/、 数据库、Agent或PMS/Opera行为。

全量前端Vitest为383/383通过；pnpm run build通过TypeScript检查和537-module生产构建；ESLint为0 error、354个既有格式 warning。5174实页核对确认三入口、人工处理2行、旧Risk查询兼容、两类通知详情动作和控制台0 error。5174继续在127.0.0.1:5174 运行并停留在人工处理页，5178迁移等待产品确认后另行执行。

2026-09-07 5174预订记录支持Tour Code或预订姓名查找

5174/prototype/br00/reservations已删除顶部“已确认结果”眉题及重复查询说明；搜索框和列表首列统一显示 “Tour Code 或预订姓名”。搜索同时匹配Tour Code与已确认New/Update当前快照中的非空FIT Name 1/Name 2，列表仍以 Tour Code为主行，仅在有姓名时显示紧凑次级行。现有四条记录、Task筛选、整行详情路由和五列结构保持不变。

Tour Code继续是记录唯一身份、详情路由和去重依据；姓名不参与归属、合并或业务判断，也不从Update Before、邮件或附件名单 反推。本轮没有补演示数据；唯一一次pnpm run build通过vue-tsc --noEmit和537-module Vite生产构建。未运行测试、浏览器 自动化、截图、5178、EML或后端验收，未创建Git commit。

2026-09-07 Risk与复核任务产品入口统一为“人工处理”

用户确认不再要求员工区分Risk与人工处理，也不为此新增后端字段。“待处理任务”的目标二级分类收口为待确认、人工处理、 其他通知：现有PENDING_CONFIRM订单任务进入待确认；REVIEW_REQUIRED订单任务和RISK / REJECTED来源通知共同进入人工处理； GENERAL来源通知进入其他通知。底层仍用现有item_type决定真实任务确认/复核，或通知只确认已处理，避免Risk误建预订记录。

该决定由ADR-030冻结，并已在5174样板实现与验收；5178、后端和运行数据未修改。5178后续可以只改前端聚合、导航和文案。 后端为什么产生REVIEW_REQUIRED仍可独立修正，但不再要求新增人工处理/Risk产品分类字段。

2026-09-07 Risk、人工处理与其他通知完成跨层盘点（呈现已由ADR-030修订）

底层数据分界已核清：Risk只用于业务类型、范围、必要目标或安全拆分无法确定，以及Agent失败后的fail-closed通知；复核型事项仍是 真实业务任务；General是任务/Risk处理后剩余的当前业务原文，可与任务并存，本期Payment属于General，固定模板则直接排除。 后续ADR-030已取消员工入口上的Risk/人工处理分组，现有REVIEW_REQUIRED与Risk统一进入“人工处理”。HNM本身不触发异常分类，目标明确时 仍为RM2房量加HNM/FO+HSK Trace双结果。普通New/Update多住期按ADR-024和当前Skill V3正常保留多个独立住期段；只有多住期 Allotment定量扣减因无法安全派生而进入局部Risk。旧booking-business-agent-rules-v1.md仍写普通多住期Risk，已过时。

当前运行面继续健康：8082 UP，5174/5178 HTTP 200，capabilities全ready且无缺失配置。5178有10张正式卡（9 Update、1 Cancel Allotment），候选全部VALID且Tour Code已识别，但因本地没有ACTIVE订单被现投影统一改成REVIEW_REQUIRED/UNASSIGNED_REVIEW； 四分类盘点时曾把这视为人工处理错分，并要求把字段复核与归属复核进一步区分；ADR-030随后取消该员工分类要求，不再把新增后端 分类字段作为前置条件。命令服务实际已有改绑和无匹配时建立USER_CONFIRMED本地记录能力，旧文档称该能力未实现已过时。 另有12条ACK_REQUIRED Risk，其中11条Agent候选被拒、1条重试耗尽， 没有General/Rejected真实样本。

盘点时5174还是5待确认/1人工处理/1 Risk/1其他通知，并有两处旧通知说明；随后已按ADR-030改为5待确认/2人工处理/ 1其他通知，修正文案并对齐旧测试。5178仍是旧的任务/待归属/通知入口和合并通知列表，通知详情也仍有备注与Act。 盘点阶段聚焦后端分类/投影38/38、前端8/9；后续5174实现完成后前端全量为383/383。全程未上传EML、调用Agent、确认真实任务 或写PMS/Opera。

2026-09-07 5174 FIT Update的Name 1已设为确认必填

该段记录的是本轮收口前的中间状态，已由上方“5174已按FIT姓名主身份规则收口”取代。当前Name 1仍显示红色星号并参与 确认校验，Name 2继续可选；Tour Code已改为可选，不再执行本段原有的非空确认门槛。

5174仍不查询数据库或Opera，也不模拟记录存在性或归属唯一性；正式接线必须另行对齐5178、Agent和后端。

2026-09-07 5174已有可办理的人工处理样板

该段记录的是曾短暂采用的Tour Code冲突样板，已由上方FIT姓名主身份案例取代。当前正文、主题、附件和可选Tour Code均使用 LLTQ260811Q10-A；人工处理原因改为FIT没有Name，Name 1初始为空并由员工手动填写。详情顶部与列表仍显示“人工处理”， 确认后仍使用既有本地出队并返回全部待处理列表行为。

修改前快照、Basic Information、Update其他字段和来源邮件结构保持不变；WAITING 等待确认：2300 THB继续只作为Note， 不作为价格或人工处理原因。原冲突样板的历史实施结果保留在任务历史与证据记录中，不再描述当前页面。

2026-09-07 5174 Update Booking修改前区域已收口

5174的Update Booking LLTQ260811Q10-A保留页面主标题作为任务身份，任务卡标题改为“修改前”。卡头已删除重复的 Update Booking、FIT、发件人、邮箱与BEFORE标签；修改前Room Information改为纵向放在入住时间下方。当前可编辑字段 继续保留，但不再显示“本次结果”；快照用途说明和Note下方“邮件附件中的完整原文，仅供核对，不作为房价。”也已移除。 底部来源邮件中的发件人仍作为邮件证据保留。

本轮只修改5174 Update详情模板与直接样式，没有改变演示数据、字段、确认逻辑或其他页面。未运行测试、浏览器自动化或 截图；唯一一次pnpm run build通过vue-tsc --noEmit与537-module Vite生产构建，仅有既有大chunk提示。未修改5178、 后端或真实连接，未创建Git commit。

2026-09-07 HNM / Honeymoon双结果规则已对齐并恢复完整联调

酒店最终口径已落实：HNM/Honeymoon及其Sup、U-变体仍按既有规则映射RM2，来源数量保留为正常房量并参与 FIT/GROUP判断；同一证据额外生成一条目标房型为RM2、员工可见文本固定为HNM、负责部门为FO+HSK的Trace， 同时通知前台和房务部布置。例如9TWN 1HNM输出9 × RM3 + 1 × RM2，总房量10间，并另有一条HNM Trace。

root可移植能力包、Java固定渠道解析、legacy目录、V4 Trace显示裁剪、Booking Agent/Parsing Agent本地HOLD包、业务文档和 验收fixture已同步。专项校验通过：root normalizer 32项、rate/room Python 12项、root合同validator、Java HNM相关56项、 Skill package 33项及Skill结构快速校验。后端全量Maven共959项，当前仍有9 failures、9 errors、6 skipped；失败属于既有 Booking V2/V3合同、已删除compact schema、旧native parser门禁、display断言及worker/intake测试债务，不是本次HNM规则回归。

本地联合调试已用当前代码恢复：5178订单页HTTP 200，8082 health为UP，H2为V34，项目专属PostgreSQL为V16；replay、 capture、storage、PostgreSQL、Parsing Agent、Booking Agent、V2 authority、strict execution和execution均ready， missing_configuration=[]。没有上传EML、调用真实Agent、确认任务、发布Agent Skill或写入PMS/Opera；Skill包仍为 HOLD / INTERNAL_ONLY。

2026-09-07 5174 Update Booking已恢复Basic Information

5174的Update Booking详情已纠正旧演示开关：Basic Information恢复显示，并依据当前发件人 op.qbdtravel@gmail.com预填ACCOUNT=QBD、MARKET=gtt、SOURCE=TA。任务仍保留原有Update Booking内容与 “待归属”演示状态，未修改其他任务页面、5178、后端或真实连接。

按本轮限制未运行测试或浏览器自动化，只执行一次pnpm run build；vue-tsc --noEmit与537-module Vite生产构建通过， 仅有既有大chunk提示。未创建Git commit。

2026-09-07 5174其他任务详情公共布局已统一

5174已以New Booking现有页面为公共样板收口其他任务详情。Update Booking改用相同的顶部返回/单一状态、页面主标题、 Basic Information标题、直接任务标题、标准Note与来源邮件卡片层级；确认后的独立成功提示已删除，底部操作区只在未确认时 显示一个“确认”。BEFORE、表单字段、演示数据和确认返回逻辑均未改变。

Cancel Booking、Cancel Allotment、Trace和Rooming List共用任务卡已删除“当前任务”眉题；Risk和其他通知原实现已经符合 顶部、白色来源邮件卡片与单一确认规则，因此没有为统一代码而重写。New Booking可见页面、待处理列表/分类、预订记录、 AgentBus、5178和后端均未修改。

按本轮限制未运行测试、浏览器自动化或截图，只执行一次pnpm run build；vue-tsc --noEmit与537-module Vite生产构建通过， 仅有既有大chunk提示。未创建Git commit。

2026-09-07 5174 Cancel Allotment已纠正为待确认

演示记录LT260820LB的Cancel Allotment已从unassigned改为pending_confirmation，列表进入“待确认”，两份详情fixture状态也 统一为“待确认”。8条演示任务的分类分布现为待确认5、人工处理1、Risk 1、其他通知1；Update Booking保留为唯一人工处理样本。

本次没有增加Cancel Allotment类型特判。队列分类继续读取通用reason，产品规则修订为：PENDING_CONFIRM + VALID + confirmable=true的任务正常待确认；只有后端明确返回人工归属或复核才进入人工处理。本地是否存在预订记录只影响确认后归档， 不能由前端用于推断分类。ADR-027/028、M012和domain rules已同步修订。

聚焦分类测试5/5通过，一次pnpm run build通过vue-tsc --noEmit和537-module Vite生产构建，仅有既有大chunk提示。未运行 全量回归或浏览器额外检查，未修改5178、后端、真实连接或确认逻辑，未创建Git commit。

2026-09-07 任务详情页公共布局共识已确认

用户确认5174 New Booking LT260807LC为其他任务类型后续复用的公共布局基线：顶部只保留“返回待处理任务”和当前状态， 删除独立“待处理任务”眉题；Basic卡片直接显示Basic Information，不显示“订单资料”重复眉题；任务卡直接显示任务名称， 不显示“当前任务”眉题。公共内容顺序为Basic、当前任务卡、可选Note和底部来源邮件。

待确认详情底部只显示“确认”，返回统一使用顶部入口；确认后整个操作区消失。该共识只统一白色单列骨架、标题层级、分区 顺序和操作位置，各任务继续按自身已确认字段做内容差异，不复制New Booking业务字段。先以5174为产品样板，后续再按确认 结果同步5178。本轮只更新项目共识记录，没有修改任何页面代码或运行服务。

2026-09-07 5174 New Booking标题已收口

5174 New Booking详情的Basic Information卡片已删除重复眉题“订单资料”，左上只显示正式标题Basic Information；New Booking 任务卡已删除“当前任务”眉题，任务详情顶部也不再显示独立的“待处理任务”眉题，只保留任务名称、状态和既有返回入口。 其他表单结构与交互均未改变。

按产品要求未运行测试，仅执行一次pnpm run build，vue-tsc --noEmit和537-module Vite生产构建通过；未修改5178、后端或真实连接， 未创建Git commit。

2026-09-07 5174 New Booking入住时间段已可删除

5174待处理任务的New Booking详情现在为每个入住时间段提供紧凑的“删除”按钮，使用与Update Booking一致的垃圾桶图标、 动态无障碍名称和纯前端草稿删除逻辑。任何当前住期行均可删除，包括最后一行；删空后仍可用原有“增加入住时间段”重新创建， 没有新增未确认的最少段数规则、确认规则或后端调用。

聚焦Vitest用例通过1/1（49 skipped），一次pnpm run build通过vue-tsc --noEmit和537-module Vite生产构建，仅有既有大chunk 提示。5174实页DOM和全页视觉确认两个住期删除入口均存在、标题行保持白色紧凑对齐，控制台无warning/error；点击后的删空与重建 由聚焦交互用例覆盖。未修改或重启5178、8082，未触碰待处理列表、其他详情、EML、后端、真实连接或业务规则，未创建Git commit。

2026-09-07 5174 Extra Bed人工勾选默认数量已接入

5174待处理详情中，New Booking、Trace和Update Booking三类可编辑Room Information现在使用一致交互：员工将某房型行的 Extra Bed从未勾选改为勾选时，如果加床房间数当前不是正整数，页面自动填入1；已有正整数保持不变，取消勾选及既有数量校验 继续沿用原逻辑。三类可编辑卡片的Extra Bed控件统一简化为勾选框 + 是，未勾选即代表否，不再显示动态“否”或说明性副文案。 预订记录只读快照、演示数据、确认语义和视觉结构均未修改。

聚焦用例通过1/1，一次pnpm run build通过vue-tsc --noEmit和537-module Vite生产构建，仅有既有大chunk提示。首次测试命令 因参数分隔符误跑全量；新增用例通过，27项失败仍是已知的同一旧showroom测试文件断言漂移，本次未扩大范围处理。未修改或测试 5178、EML、后端与真实连接，未创建Git commit。

2026-09-06 项目盘点完成并恢复本地完整运行面

工作区根是Booking Desk Agent vNext可移植能力包，th-hotel-simple/才是全栈应用和Git根。当前分支 feature/booking-v01-safe-checkpoint位于48f5376、比upstream ahead 1；启动前有148个tracked modified、2个tracked deleted和59个untracked，无staged。旧PROJECT_STATE.md的pre-CP6描述已过时：V2-only执行隔离、正式V4 workbench、 Layer 4–6、durable双Agent执行、Trace及5178 UI均已存在。全部既有工作树改动已保留。

仓库启动器两次证明当前.env.local-replay中的远端Booking PostgreSQL在SSL协商时Read timed out；不是编译或凭据拒绝。 启动器引用的可选compose文件不存在，Docker也未安装。为完成本地联合调试，已在 server/var/local-replay/postgresql-15创建仅监听127.0.0.1:55432的项目专属PostgreSQL 15空库；不修改env文件， 仅在当前后端进程覆盖连接。H2 V34和Booking PG V16均通过，8082 backend、5178 formal/prototype frontend已启动，原5174 showroom保留。health为UP，四个关键5178路由200；capabilities显示PG、双Agent、V2 authority、strict execution全部ready且 无缺失配置。

新Booking库processing/parsing/booking/projection四类total/active均为0。本地H2仍有10张正式任务卡：9 Update、1 Cancel Allotment，全部REVIEW_REQUIRED。没有上传/执行EML、外呼Agent、确认任务或写PMS/Opera。admin metrics因固定本地身份缺 SYSTEM_ADMIN_CONSOLE_ACCESS而由authorization exception表现为HTTP 500，队列已改用数据库聚合只读确认。

当前tree的frontend typecheck通过；全量Vitest为357 passed、27 failed，失败全集中在落后当前showroom实现的 localTaskPrototypeViews.spec.ts。workspace-root vNext validator另因50-room-type-mapping.md缺HNM/Honeymoon失败。因此当前 运行面ready，但代码/合同验收不能称为全绿。详见 50-evidence/topics/2026-09-06-project-inventory-local-runtime-recovery.md。

2026-08-22 五类正式任务数据与功能已接入

5178正式待处理列表已改为一张业务Task Card一行并支持卡片直接详情。New、Update、Cancel Booking、Trace、Rooming List及 Cancel Allotment共用Sender Mapping Basic、只读Note和来源邮件骨架；Update读取当前目标Layer 3 BEFORE，FIT只保留Name 1/2， New/Update/Trace的Extra Bed绑定到明确房型行，Rooming List按attachment_id展示安全附件摘要，缺价说明读取Layer 4实际原因。

未归属或Tour Code变化的正式任务现在必须先预览归属；唯一既有记录可重新归属，无任何记录时在确认阶段建立只承载本地确认 结果的ACTIVE / USER_CONFIRMED记录，不改任务业务类型，也不表示PMS/Opera已经执行。BEFORE、Note、Trace room context等 只读数据在确认前被剥离；姓名、加床数量、房量上限和Basic完整性由前后端共同校验。

后端5组52项、前端核心6组81项和typecheck通过。安全重载8082前四类活动队列 均为0；当前PID 45630，health、5178页面、逐卡接口和详情均为200。真实队列10行对应10个不同卡片，其中9条Update、1条 Cancel Allotment；历史样本没有BEFORE、Note或完整Sender Mapping，页面按规则留空。本轮未做视觉验收、未运行EML/Agent、 未确认真实任务、未写PMS/Opera、未创建Git commit。

2026-08-22 5174一级目录已移除业务配置

5174/prototype/br00一级导航现只保留待处理任务、预订记录、AgentBus回放，并保持该顺序；待处理任务四个二级目录、列表、 详情、预订记录和回放页面均未改变。原/prototype/br00/business-configuration不再加载业务配置页，直接重定向到 /prototype/br00待处理任务首页；旧LocalBusinessConfigurationView.vue文件继续保留，没有扩大为旧代码清理。

该调整落实ADR-029：Opera是ACCOUNT、MARKET、SOURCE、Rate Code、Meal、Room Type、负责部门及其他Opera业务选项的唯一来源， 前端不再设置第二套同职责配置产品模块。本轮没有删除或修改业务规则，也没有改办理卡片字段/选项、5174演示数据或接入Opera； 5178、EML、后端、数据库、Agent和字段契约均保持边界外。

本轮唯一一次pnpm run build通过vue-tsc --noEmit和500-module Vite生产构建，仅有既有大chunk提示；按验收限制未运行测试、 浏览器、截图、5178、EML、Opera或后端检查，未创建Git commit。

2026-08-22 5174预订记录详情已补全为完整确认快照

5174/prototype/br00/reservations现在以一条Tour Code一条记录展示现有4条独立已确认fixture；所有Group Code文案已统一为 Tour Code。搜索只匹配Tour Code，Task筛选固定为New Booking、Update Booking、Cancel Booking、Cancel Allotment、Trace、 Rooming List六类，并按记录内已确认Task成员关系过滤。同一Tour Code只出现一次，列表仍保留Tour Code、Account、Booking Type、Task和最近确认时间五列；整行可点击且没有新增查看按钮。

/prototype/br00/reservations/:tourCode现在把每张已确认Task保存并展示为独立的完整本地快照。Basic Information只读展示一次， 四条记录的ACCOUNT、MARKET、SOURCE均完整。New Booking按Group/FIT展示Tour Code、Rate Code、Meal、多住期、Nights、多房型、 Quantity和Extra Bed结果，FIT额外展示双姓名；Update Booking在同一白色任务卡内分别展示完整修改前快照和本次结果；Trace展示 服务事项、负责部门和Room Information；Rooming List展示Task名称及由attachment_id关联的附件；Cancel Booking只展示Tour Code。

每张任务后独立展示自身非空Note和来源邮件，包含发件人、收到时间、主题、正文、附件及专属邮件线程入口；线程路由为 /prototype/br00/reservations/:tourCode/tasks/:taskId/email-thread，不会混用同Tour Code下其他Task的邮件。所有字段均使用文本、 定义列表或只读表格，不包含输入框、选择器、复选框、确认或替代操作，也不展示Adult、字段来源、Extra Bed来源、识别、待归属 或相邻类型模块。

本轮唯一一次pnpm run build通过vue-tsc --noEmit和500-module Vite生产构建，仅有既有大chunk提示。按验收边界未运行 测试、浏览器、截图、5178、EML或后端检查；列表四条Tour Code及原任务关系保持不变，未修改待处理任务、业务配置、AgentBus、 真实连接或业务规则，未创建Git commit。

2026-08-22 5174刷新后释放全部待处理任务

5174确认出队状态现只保存在当前前端运行内存，不再读取或写入localStorage。员工点击确认后，任务仍会立即离开待处理列表， 并返回/prototype/br00展示剩余任务；浏览器整页刷新会重新初始化空确认集合，因此全部8条演示任务恢复。旧版本遗留的确认键 不再被消费，不影响刷新释放。

聚焦工作流测试6/6通过；本轮唯一一次pnpm run build通过vue-tsc --noEmit和500-module Vite生产构建，仅有既有大chunk 提示。真实5174浏览器验收得到确认前8条、确认后7条、刷新后8条，New Booking重新出现，控制台无warning/error。未修改或 测试5178、EML、后端、数据库和业务契约，未创建Git commit。

2026-08-22 5174 Trace卡片四列对齐已修正

5174 Trace详情顶部已恢复为铺满卡片的四轨布局，不再使用744px限宽。Tour Code占第1轨并对应下方Room Type；服务事项横跨 第2、3轨并对应Quantity＋Extra Bed；负责部门占第4轨并对应Rooms。顶部字段与下方表格使用匹配的水平间距关系，三个控件 统一为原Tour Code的38px高度，服务事项仍可文本编辑。760px以下继续显式回落为单列，避免跨列规则生成隐式列。

Room Information与Note已移除上方眉题，正式标题直接成为卡片左上角的首个可见标题。没有改变Trace数据、确认流程、列表或 其他任务类型。聚焦5174工作流测试5/5通过；本轮唯一一次pnpm run build通过vue-tsc --noEmit和500-module Vite生产构建， 仅有既有大chunk提示。未修改或测试5178、EML、后端和业务契约，未创建Git commit。

2026-08-22 5174确认后统一返回全部待处理列表

5174所有当前待处理详情点击确认后，仍先把task key写入浏览器本地确认集合并从待处理列表/左侧总数中移除，但返回目标已按 最新产品确认统一为不带category参数的/prototype/br00。页面因此直接展示全部剩余待处理任务，不再停留在原任务所属的 待确认、人工处理、Risk或其他通知分类。内部reason、列表结构、排序、搜索和其他确认语义不变。

聚焦5174工作流测试4/4通过；一次pnpm run build通过vue-tsc --noEmit和500-module Vite生产构建，仅有既有大chunk提示。 未修改或测试5178、EML、后端、数据库、Agent、登录和业务契约，未创建Git commit。

2026-08-22 5174确认任务已出队并接入独立邮件线程页

5174待处理样板以演示状态记录已确认task key。New/Update/五类共享任务及Risk/其他通知点击确认后，任务立即从待处理列表与 左侧总数中移除；内部分类、列表排序、搜索和fixture身份均未改变。该状态不调用API，也不写5178或后端。后续已按最新产品 反馈将存储从localStorage改为仅当前页面运行内存，并把确认后返回目标统一为全部列表；刷新后会释放全部任务。

当前待处理详情的查看邮件往来线程已统一跳到/prototype/br00/tasks/:taskKey/email-thread独立只读页。页面复用同一任务的 来源邮件演示数据，完整展开当前邮件元数据、正文、附件及fixture中现有的全部quoted history；Update展示既有thread summary， 不补造缺失的历史邮件头。Trace任务卡的Tour Code、服务事项和负责部门改为三列等宽对齐，桌面网格总宽限制为744px，使服务 事项接近调整前宽度的一半；小屏仍沿用既有单列规则。

聚焦5174工作流测试4/4通过；一次pnpm run build通过vue-tsc --noEmit和500-module Vite生产构建，仅有既有大chunk提示。 未测试或修改5178、EML、后端、数据库、Agent、登录和业务契约，未创建Git commit。

2026-08-22 5174待处理任务详情可见内容已收口

开发专用5174样板间/prototype/br00已按最新产品反馈收口可见内容，保留既有白色外壳、紧凑列表、目录结构、排序与搜索。待处理 二级导航中的待归属仅改名为人工处理，内部unassigned分类、行状态和演示数据不变。所有当前队列任务卡中的Tour Code均可 文本编辑；卡片底部只保留确认，点击后状态变为已确认且操作区消失，没有替代按钮。

所有字段来源、Extra Bed 来源说明和Update的待归属说明已移除；可选display_information统一以员工可见名称Note 展示。Risk与其他通知改用既有白色详情/来源邮件样式，不再展示业务意图、识别说明、识别依据、相邻类型或两类通知说明模块。 Cancel Allotment任务卡只保留可编辑Tour Code，删除范围和整个Allotment额度块不再显示；确认语义仍只存在于5174演示状态， 没有接入5178或真实后端。

按本轮明确验收边界，只执行了一次client的pnpm run build：vue-tsc --noEmit与500-module Vite生产构建通过，仅有既有大 chunk提示。未运行测试、浏览器/截图验收、5178、EML或后端检查；未修改样式系统、路由、字段契约、业务规则或真实连接，未创建 Git commit。

2026-08-21 5174待处理任务完整视觉样板已实现

开发专用5174样板间/prototype/br00已完成待处理任务列表和六种已确认任务详情。四个一级目录、四个待处理二级目录及8条 紧凑横向列表保持不变；二级目录不再显示数量。列表可见字段仍只有处理原因、Tour Code或待识别、来源邮件发件人、邮件收到 时间和查看处理，继续按来源邮件收到时间正序。搜索仍只支持Tour Code和Confirmation No.，但现在搜索全部待处理任务，不受 当前分类限制；清空后恢复原先选择的分类。

New Booking、Update Booking、Cancel Booking、Cancel Allotment、Trace、Rooming List均可从现有直接任务路由打开。详情统一保留 返回/状态、条件式Basic、当前任务、可选display_information、来源邮件和底部返回/确认。New支持Group/FIT、多个住期、派生 Nights、多个房型、Room Type/Quantity、Extra Bed和加床房间数；Group不展示姓名，切换为FIT后出现空的NAME 1/2；缺价样板当前仍写死 邮件未提供价格，因此使用GRP1/GRPA1，2026-09-07 已确认为待纠正项：应由后端缺价默认原因码触发并按实际Rate Code显示 “邮件未提供价格，默认规则选择{Rate Code}”。无Adult。Update保留最新结果和Layer 3 BEFORE只读快照，当前待归属样板没有返回 Basic，因此页面不虚构Basic。两种Cancel保持极简，Cancel Allotment固定只读整个Allotment额度块且没有Cut Allotment。 Trace按Basic→Trace→Room Information→Extra Bed来源说明→display_information→来源邮件排列，Trace本身不区分Group/FIT； Rooming List任务卡只展示Tour Code和现有附件数据。

本轮唯一一次聚焦测试命令通过7/7，41项范围外用例跳过；唯一一次pnpm build通过vue-tsc --noEmit和500-module Vite生产 构建，仅有既有大chunk提示。5174浏览器逐项点击四个二级目录得到4/2/1/1条，验证跨分类搜索及清空恢复、整行进入详情、六个 详情路由、Trace顺序和Update BEFORE均通过。按用户验收边界没有访问或验证5178、8082、EML和后端，没有重启任何服务， 没有修改业务配置、AgentBus、预订记录、后端、数据库、Agent、业务规则或登录，没有删除旧页面，没有创建Git commit。

2026-08-21 5174一、二级目录架构已修正并完成浏览器验收

5174演示样板间/prototype/br00现在只有四个一级入口：待处理任务、预订记录、业务配置、AgentBus 回放。AgentBus 回放已从独立调试工具分组移入同一一级目录；待处理任务下方固定展示待确认、待归属、Risk、其他通知四个紧凑二级入口。 点击一级待处理任务显示全部8条，点击二级入口在同一紧凑列表中分别显示4/2/1/1条；分类内仍只按邮件收到时间正序，搜索 仍只匹配Tour Code和Confirmation No.，发件人邮箱不匹配。通知的可见命名已统一为“其他通知”，没有新增筛选、排序、 已处理入口或大卡片列表。

预订记录现在是可进入的单页目录，Group Code搜索和Task类型筛选共同作用于同一个样板记录列表，没有拆成两套记录页面， 也没有扩展订单详情或新业务流程。业务配置只保留现状说明；AgentBus直接进入既有5174浏览器演示回放，没有修改登录、EML 或真实连接。Update Booking仍可由整行中的“查看处理”进入，原有待归属说明、Basic、完整BEFORE只读快照、本次结果、 住期/房型、来源备注/邮件和底部返回/确认均保留。

聚焦Local视图/真实路由测试52/52、typecheck、目标ESLint和500-module production build通过，只有既有大chunk提示。 桌面与390px窄屏目录/列表实看通过；最终整页重载后的控制台只有Vite连接debug，无warning/error。端口全程未重启，任务 前后5174/5178/8082 PID保持12649/34564/34627，5174与5178 HTTP均为200。本轮没有修改后端、数据库、Agent、 业务规则、登录或EML回放行为，没有清理旧页面，没有提交Git。

2026-08-21 5174 Update Booking待归属详情样板已实现，待产品确认

最终复验期间出现范围外并发工作区变化：此前存在、未由本任务创建且处于未跟踪状态的 client/src/data/localPendingTaskPrototype.ts从磁盘消失。该文件仍被5174根页和前端测试引用，因此实现曾通过的46/46、 typecheck、lint和500-module build在最后一次重跑时变为模块解析失败。当前既有5174进程仍能从浏览器缓存打开目标页且控制台 无错误，但重启后的稳定性不能确认。本轮没有删除或重建该用户文件，需由用户恢复原文件或明确授权按现有页面数据重建后， 才能重新完成最终门禁。

5174的/prototype/br00/tasks/update-booking已按ADR-025至ADR-028与M012实现独立演示数据详情。页面沿用现有白色AI RSVN 外壳，一级导航展示待处理任务、预订记录、业务配置、AgentBus回放并突出待处理任务；未实现的预订记录和业务配置只保留 非跳转入口，没有借本页扩大模块范围。

本页演示已识别Tour Code LLTQ260811Q10-A但没有本地记录的待归属场景。Basic按 op.qbdtravel@gmail.com预填QBD/gtt/TA并可重选；Update卡顶部集中展示按业务区域分组的完整Layer 3 BEFORE只读快照， 下方只保留可编辑本次结果，BEFORE缺失值保持空白。FIT双姓名留空，不展示Adult或Occupancy；住期、房型、Quantity与 Extra Bed均可修改和增删，Nights自动计算，加床 房数执行正整数且不超过Quantity的就近校验。非空来源备注和来源邮件位于卡片后，底部只有返回列表和确认。

确认只在5174内存中模拟，并明确表示归入或建立本地Tour Code确认记录、未向PMS/Opera发送修改。聚焦与真实路由回归46/46、 typecheck、目标lint和500-module build通过；桌面/小屏、错误聚焦、增删、日期、邮件往来、返回入口和控制台实看通过。5174仍为 PID 12649且目标页HTTP 200。本轮没有停止、重启或修改5178/8082，但最终复核时二者已无监听，先前记录的5178 PID 14604 不再存在，因此当前无法把5178真实后端连接记为运行态通过。5178代码、后端、数据库、Agent、规则、回放和登录均未修改。 当前等待产品实看确认，尚未提交Git。

2026-08-21 人工处理详情与确认结果归档规则已确认

用户确认待归属、字段复核、Risk和通知的详情基线。当前真实工作台有10条预订任务和12条Risk：10条任务均已有Tour Code 但没有可归属的本地确认记录，其中9条Update Booking、1条Cancel Allotment；12条Risk主要为系统未能接受办理结果或 自动处理多次未完成。当前没有General或Rejected真实样本。

待归属不新增独立归属卡，继续展示Basic和真实业务任务卡；已有记录时确认归入该记录，没有记录时以确认Tour Code建立 只承载本地确认结果的预订记录，并把当前任务作为第一条处理记录，不把Update伪装成New或外部PMS动作。字段问题仍留在 原任务卡，列表显示待确认，员工就地修改并一次确认。

Risk/Rejected没有预订任务时不展示Basic，Rejected归入Risk，General归入通知；三类通知只展示产品化原因、相关原文和 来源邮件，不要求处理备注，确认只记录确认人与时间。规则已记录为ADR-028并同步M012和领域规则。

当前运行仍只能把未归属投影本地复核归档，不能完成改码后重新归属或无记录时建立确认记录；未归属Basic也仍为空，属于 待实施差距。本轮只核对数据并更新产品资料，未修改前端、后端、数据库、Agent或运行服务。

2026-08-21 待处理任务按卡拆分、按钮与Allotment Actual口径已确认

用户确认一张任务卡对应待处理列表中的一条任务。同一封邮件、同一Tour Code若产生New Booking、Trace、Rooming List等 多张卡，列表分别展示，详情只承载当前任务卡并独立确认；确认完成的卡进入该Tour Code预订记录，其他卡继续待处理。 来源邮件可以在这些独立详情中重复作为证据展示。

所有待处理详情的主要按钮文案统一为“确认”，不再区分确认处理、确认归属或确认已读。统一文案不改变实际动作：任务确认、 Tour Code归属、字段复核和通知已读仍分别执行并保留各自记录。

Allotment Actual New不是邮件往来的独立业务类型，只是内部来源关系和沟通概念；员工页面统一显示为普通New Booking并复用 New Booking详情，不增加入口、标签、筛选或页面。本期不做的仍是Cut Allotment / Allotment Source Deduction。

规则已同步ADR-025/026/027、M012和领域规则。当前正式列表仍按订单任务容器聚合，逐卡列表属于待实施差距；本轮未修改 前端、后端、数据库、Agent或运行服务。

2026-08-21 Basic Information改为按发件人识别并始终展示

用户纠正并确认：Basic Information的识别来源是发件人映射，不是Tour Code订单归属。所有预订类任务详情顶部都展示Basic， 包括Tour Code尚未识别或尚未归属正式订单的人工处理事项。唯一有效发件人映射自动预填Account、Market、Source；映射缺失、 歧义或失效时对应字段留空，由员工使用受控下拉选择。员工仍可按权限修改预填结果。

Tour Code只负责订单归属，不控制Basic是否出现；未归属任务仍先人工归属且不构造虚拟订单。同一详情页Basic只展示一次， Sender本身继续位于底部来源邮件。该决定覆盖此前Trace、Rooming List、Cancel Booking和Cancel Allotment中“只有已归属订单 才展示Basic”的表述。

当前运行样本中，未归属任务虽有已知发件人，但详情接口仍返回Basic为空，属于待实施的数据接线差距。规则已同步ADR-027、 M012和领域规则；本轮未修改前端、后端、数据库、Agent或运行服务。

2026-08-21 Rooming List详情已按正式字段定稿

用户提供正式任务字段并确认定稿：Rooming List返回只读Tour Code、固定业务类型、唯一附件编号，以及不可编辑但可确认的 操作状态。页面采用统一白色单列骨架，按标题与状态、按发件人映射的Basic、Rooming List任务卡、可选展示信息、来源邮件和 底部操作排列。

唯一附件编号用于从来源邮件材料精确取得文件名、类型、大小和受控访问能力，编号本身不展示；匹配不到时只显示附件信息 暂不可用，不补演示数据。卡片不展示名单行、客人姓名、房号、人数、Room Information或Excel生成工具字段。页面没有可编辑 任务字段，按可确认状态开放“确认”；确认仅表示名单已收到并归属当前Tour Code，不代表解析、生成、导入或写入 PMS/Opera，也不增加必须先下载的规则。

规则已同步ADR-027、M012和领域规则。当前回放数据中仍没有真实Rooming List任务可做页面验图；本轮未修改前端、后端、 数据库、Agent或运行服务。

2026-08-21 Trace详情与Tour Code产品命名已确认

用户定稿Trace详情：统一白色单列骨架，页面按标题与状态、按发件人映射的Basic Information、Room Information、 Trace Information、可选展示信息、来源邮件和底部操作排列。Room Type与Quantity只读，优先取本次New/Update最新结果， 其次取已归属订单最近确认记录；都没有时只展示Trace明确提供的目标房型并让Quantity留空，不猜测房量。

Extra Bed在匹配房型行上展示可人工修改的勾选和房间数，真实服务文字作为只读来源说明。Trace Information展示Tour Code、 服务事项和受控负责部门，当前部门选项为FO或FO+HSK。当前本地10笔回放任务只有9笔Update Booking和1笔Cancel Allotment， 没有Trace真实样本，因此本轮只冻结数据承载与产品结构，尚未进行真实Trace页面验收。

用户同时确认所有员工可见页面、搜索、字段标签和提示统一使用Tour Code，不再混用Group Code或Allotment Code；底层字段和 归属规则不变。该决定覆盖此前Cancel Allotment显示Allotment Code的产品文案。规则已同步ADR-027、M012和领域规则。 本轮未修改前端、后端、数据库、Agent或运行服务。

2026-08-21 两种取消任务详情已确认

用户确认Cancel Booking和Cancel Allotment都复用白色单列骨架并保持极简。按后续统一命名决定，Cancel Booking只展示 可修正Tour Code与固定“整笔预订”范围；修改后必须重新匹配订单，失败不能确认。Cancel Allotment只展示可修正来源Tour Code与 固定“整个额度块”范围；Basic展示规则已由后续决定改为始终按发件人映射展示。

Cancel Allotment现有真实返回已经核对：CANCEL_ALLOTMENT / ALLOTMENT_SOURCE_WHOLE_CANCEL只提供可编辑必填的 tour_code和availability。页面标题固定为Cancel Allotment，副标题为“删除整个 Allotment 额度块”；用户可见字段按后续 决定保持Tour Code，不要求后端改字段。只读展示和邮件没有真实数据时不生成空区块。

两张取消卡都不展示Group/FIT、姓名、住期、房型、房量、Rate、Meal或旧设计中的订单房间快照；Cancel Allotment也不 展示扣减前或剩余数量。底部统一为返回列表和确认，不把本地任务确认描述成已完成外部酒店系统取消。规则已同步 ADR-027、M012和领域规则。Cut Allotment / Allotment Source Deduction已明确移出本期前端范围，不与Cancel Allotment 混用；现有后端类型和数据保持不变。当前5174/5178尚未实施，本轮未修改页面代码、后端、数据库、Agent或运行服务。

2026-08-21 Update Booking BEFORE展示规则已确认

用户在首版实看后确认Update Booking复用New Booking完整骨架，但将BEFORE展示从字段旁零散对照调整为任务卡顶部的一块 完整只读快照。快照按基础预订、入住时间和Room Information分组，展示Layer 3实际提供的全部BEFORE字段；下方各区域只 展示可编辑本次结果，不拆成两张体积相同的大卡片，也不增加第三套系统当前订单对照、折叠区或单独查看入口。Layer 3 取不到哪个BEFORE字段就让对应位置空着；BEFORE房型和数量都取不到时两项都为空，不能用最新值或其他订单资料补齐。 “确认”只提交最新结果。

5174当前演示数据进一步按产品实看收口：修改前Room Information默认只展示一个实际历史房型RM2 / 8，不再为本次新增的 第二个结果房型生成空白BEFORE行；下方本次结果仍独立保留RM2 / 10与RM3 / 2两行。该调整只改变样板数据表达，不改变 Layer 3缺失字段留空的通用规则。

核对现有Layer 3契约与样例后，BEFORE确实以逐字段状态、字段位置、值和证据保留，可直接重组为页面对照；正式5178 页面尚未完成读取接线。本轮已更新ADR-027、M012展示基线和领域规则，未修改前端、后端、数据库、Agent或运行服务。

2026-08-21 New Booking详情布局已确认

用户确认New Booking作为第一张标准办理详情：白色紧凑单列，按Basic、New Booking任务卡、可选display information、 底部邮件排列。入住时间和房型均使用横向行，新增一项只新增一行，不套多层小卡片；FIT姓名紧跟Group Code，Group不留 姓名空位。邮件过长可展开，附件始终可见；字段问题就近提示；底部只有返回列表和确认，不增加无真实保存规则的草稿。

该布局已补入ADR-027和M012展示基线。后续Update、Cancel和Trace在同一骨架上按任务需要做减法；Cut Allotment本期不做。 当前5174/5178尚未实施，本轮未修改页面代码、运行服务、后端、数据库、Agent或业务输出契约。

2026-08-21 订单处理详情内容规则已收口

用户结合M012用户可见内容基线确认了“查看处理”后的目标结构：已识别Tour Code的详情依次展示所有订单可见的 Basic Information、本次动态任务卡、只读display information和底部邮件；待识别事项先人工归属。Basic固定为 Account/Market/Source受控字段，是否可编辑由订单状态和明确权限决定，取代此前New-only产品展示规则。

任务字段进一步收口：Group不展示姓名，FIT保留Name 1/Name 2；Meal只是早餐状态与早餐餐厅的页面分组；Adult删除； 此前关于Allotment扣减字段的页面草案已于后续确认中撤回；Cut Allotment本期不做前端设计或实施。 每条房型行新增加床勾选栏，Extra Bed事件按target_room_type_code自动勾选目标行，并用 extra_bed_room_count显示需要加床的房间数。员工可以改勾选和数量；勾选后数量必填、为正整数且不超过该房型房量， 取消勾选后原数量不参与确认。无法安全匹配时转人工，由员工选择正确房型并补充合法数量，原始来源证据保持只读。

该规则已记录为ADR-027并同步M012展示基线、领域规则和旧ADR状态。当前5174/5178页面尚未按此实施，本轮没有修改 前端、后端、数据库、Agent、运行服务或业务输出契约。

2026-08-21 订单详情内容保留审查完成

用户明确指出新的产品架构不应丢弃此前订单详情中的有效内容。只读对照确认：5174 /prototype/br00/tasks/new-booking 仍完整展示任务摘要、Basic Information、业务结论、Room Information、 多住期、邮件原文和识别依据；这些应作为后续办理详情的内容母版，而不是连同旧导航一起废弃。

当前5178待办回退项因生成含空订单ID的旧嵌套链接而进入“页面不可用”；正确的正式 order-task 地址可以读取真实后端， 但当前展示的是偏系统核对的通用字段页。48f5376 曾把正式入口从丰富的 V4 办理页切换为该核对页；丰富详情及 Basic、Booking、Trace、Room、Names、邮件组件仍在工作区，并继续具备正式接口与办理动作接线，没有物理删除。

本轮只形成待用户确认的保留建议：新架构保留，详情层复用并重组上述业务区块；不保留旧一级菜单、深层订单路径、 演示草稿措辞和技术字段元数据。样板中的具体可编辑控件仍以真实后端返回为准。本轮未修改页面、路由、服务或业务数据。

2026-08-21 5174 已恢复最新 Local 设计样板间入口

5174 与 5178 仍由主项目 client/ 提供源码，产品边界不变：5174 是演示数据的最新设计样板间，5178 是连接真实后端与 EML 的正式运行线。此前旧卡片回归已确认是 /prototype/br00 错接整套 Br00OrdersView/br00OrderWorkspace 栈，不是缓存、端口或新演示数据损坏。

现已只把开发原型根路由恢复为 LocalOperationsDemoView 和 localDemo.pageTitle；已有 /prototype/br00/tasks/:taskKey → LocalTaskDetailView 保持不变。旧订单、待办、通知和嵌套任务卡路由全部保留为非主入口兼容路径，没有删除或重写其视图与 fixture。真实应用路由测试现在会显式开启原型并加载根/详情组件，防止只检查稳定路由名而漏掉组件回退。

验证通过：Local 视图与路由聚焦测试 46/46、typecheck、目标文件 ESLint、500-module build。未重启的 5174 实看根页已恢复 Local 任务工作台，点击 New Booking 进入直接任务详情并显示完整分区；旧嵌套 URL 仍可访问，控制台零警告/错误。5174、5178、8082 PID 仍分别为 12649、14604、14443；本轮未触碰后端、数据库、Agent、业务规则或 EML，也未提交。

2026-08-21 待处理任务列表结构已确认

用户已确认待处理任务使用紧凑横向列表，不在队列页展开完整办理卡片；每条只展示处理原因、Tour Code（无法确认时为 “待识别”）、来源邮件发件人和收到时间，以及统一的“查看处理”。完整卡片仅在进入详情后展示。

整条任务均可点击，“查看处理”按钮继续保留；两者进入同一个办理详情，页面不增加第二种操作。

列表只按来源邮件收到时间正序排列，最早邮件在前；只支持搜索 Tour Code 和 Confirmation No.，不提供筛选、其他排序、 “已处理记录”入口。已处理历史统一进入预订记录。5174 后续样板数据使用 LLTQ260811Q10-A、LT260807LC、 LT260812LA 和 op.qbdtravel@gmail.com 这类真实业务格式。该设计已记录为 ADR-026，本轮未生成页面或修改运行服务。

2026-08-21 8082 已恢复，5178 与 EML 测试环境一致

8082 已使用主项目当前代码和既有受保护的本地回放配置恢复，后端 PID 为 14443。健康状态为 UP，H2 保持 V34、Booking PostgreSQL 保持 V16，均无数据库迁移；回放、执行和严格执行能力全部就绪，缺失配置为空。

恢复检查同时发现主项目 5178 虽然已代理 8082，但页面仍默认使用 HOTEL-DEV，与后端固定的 HOTEL-LOCAL-REPLAY 不一致。标准 pnpm dev:5178 现已同时固定后台地址和酒店环境，只重启了主项目前端；新 PID 为 14604，8082 未中断。最新五条历史回放仍为完成状态，Parsing、Booking、工作台投影和 Processing 四类处理中任务均为0。

本轮没有选择、上传或执行 EML，没有创建新回放、调用 Agent、确认任务或修改业务数据，也没有创建 Git commit。 当前正式测试入口为 http://127.0.0.1:5178/debug/agentbus-eml-replay?entry=email-import。

2026-08-21 主项目 5178 已固定免登录，8082 当前未运行

用户明确决定在当前联合调试阶段取消 5178 登录阻断，并在整个项目调试完成后再单独恢复正式登录。此次没有物理删除 登录能力，而是把主项目本机 DEV 5178 固定为直接进入产品；production build 仍不能绕过登录。登录地址会回到安全的 原目标页面，根地址进入第一个正式菜单，标准启动入口为主项目 pnpm dev:5178。

已停止来自临时旧目录的5178 PID 5148，当前 PID 13679 的工作目录为主项目 client/。浏览器从原登录跳转地址 进入AgentBus回放，登录表单为0，控制台无错误。聚焦21/21、typecheck与500-module build通过。完整前端回归357/358； 唯一失败是本任务开始前已在修改的Allotment卡片测试，本轮未越界处理。

8082 当前没有监听，因此5178显示“后端未连接/环境未就绪”；这与登录修正相互独立，本轮没有启动或修改后端。 代码尚未提交，工作区其他既有修改保持原状。

2026-08-21 产品一级导航已确认，待处理任务列表进入设计阶段

用户在完整数据审查后确认产品一级导航为：待处理任务、预订记录、业务配置、AgentBus 回放。待处理任务统一承接 普通待确认任务、待归属事项、Risk 和其他通知；预订记录以 Group Code 组织，只呈现员工确认后的本地业务结果及 相关 Task 历史。来源邮件保留在详情中作为证据，不再作为一级入口；业务配置与回放按权限显示，回放位于底部。

该结论已记录为 ADR-025，是产品设计基线，不代表当前 5178 已完成导航改造。下一步只进入“待处理任务”列表的 信息结构讨论；本轮没有修改前后端、数据库、Agent、业务规则、运行服务或 Git 提交。

2026-08-20 QBD BEFORE/AFTER真实EML复验通过

真实QBD replay 2090438243170308098已在重启后的8082完成：回放终态COMPLETED、Booking run VALIDATED、Layer 6 VALID，9个Update订单与1个LTQ260812 Allotment整块取消全部通过，零blocker、 零人工复核。9个订单各自只保留1段AFTER实际住期，原BEFORE对照房量没有再成为第二段可执行住期，证明 FixedChannelLayer3V2Projector活动事实修正已在真实运行生效。

Parsing Agent与Booking Agent均只调用1次并成功；Booking答案的系统接收也成功。Source Capture仍记录唯一 非阻断排队码FIXED_CHANNEL_PARSING_AGENT_QUEUED，不影响业务终态。已从生命周期Provider journal逐字提取 本次实际发送的两份SuperAgent输入到工作区outputs/，并用SHA-256与日志原文核对一致；本轮未修改业务代码、 Agent资产、数据库或运行服务。

2026-08-20 5178 最新正式卡片与白色回放外壳整合（待提交）

按用户确认，5178 专用前端已补入项目根目录当前完成的 Booking、Trace、Basic Information、Names、房间信息、 来源邮件与任务卡分区组件，以及它们直接依赖的正式详情页、字段规则、类型、服务、三语文案和测试；没有整包覆盖根目录， 也没有带入原型页、系统管理、旧页面清理、本地身份配置或其他无关前端改动。

AgentBus EML 回放页现在继续使用原回放功能和数据请求，但外层统一为白色正式产品壳；同一权限身份下仍可看到回放、订单列表、 我的待办、待归属消息和消息通知五个入口。5178 已重启并验收：回放环境就绪，不再显示 UNKNOWN 或请求失败；现有正式任务 详情也能在白色外壳中完整打开。当前数据库样本只有 UNASSIGNED_REVIEW 卡，没有人为新增业务数据来制造 Booking/Trace 截图。

最终前端验证为 45 个测试文件、343/343 项通过，类型检查通过，生产构建 499 modules 通过，仅保留既有大包体提醒。 本次没有修改或重启后端，没有操作数据库、Agent、业务规则、EML、PMS/Opera 或开发回放逻辑。前端改动尚未提交， 仍等待用户按最终文件清单确认提交。

用户纠正后的整体白色产品样式补齐

上述首轮验收结论不完整：用户实看指出当时只有 AgentBus EML 回放为白色，订单、我的待办、待归属消息和消息通知仍使用 旧 AI RSVN OMS 外壳，正式列表虽然复用 ow-* 内容结构，也因缺少 .ow-app 变量根而没有完整启用白色卡片主题。 根地址会自动转到回放页，首轮用根地址验收等于重复检查同一页面，不能证明整个产品视觉。

现已在 5178 专用前端继续补齐：四个列表及相关只读内容路由统一进入白色正式壳；正式列表根启用现有 orderWorkspace.css 白色主题变量；“我的待办”回退项改进现有 /reservation/order-tasks/{id} 正式详情，不再生成空订单的 旧嵌套地址。浏览器逐页实图确认四个入口均为白色侧栏、顶部、浅色画布、白色容器和白色逐项卡片；正式任务详情与回放页 保持正常。最终验证更新为 45 个测试文件、344/344 项通过，类型检查与 499-module 生产构建通过。仍未暂存或提交。

2026-08-20 8082加载QBD BEFORE/AFTER活动住期修正

用户要求重启8082前，当前20条回放均无进行中任务；旧后端PID 2786由Maven父进程2765启动。当前源码 ./mvnw -DskipTests compile成功后，仅停止该后端进程组，并沿用权限600的既有.env.local-replay与 local,local-replay配置启动新版。前端5174/5178均未重启或修改，也没有上传EML。

新后端PID为5490，监听127.0.0.1:8082；build time为2026-08-20T13:54:26.941Z。H2保持V34、测试 PostgreSQL保持V16，无迁移；health为UP，execution/strict execution均ready，missing_configuration=[]。 当前运行态已加载QBD BEFORE不进入活动Layer4住期、CURRENT/AFTER继续进入的修正，仍待下一封真实QBD EML验证。

2026-08-20 QBD BEFORE/AFTER 活动住期边界修正

真实 QBD replay 2090427423313076226 证明 Parser 与 Parsing Agent 已正确把修改前后房量标为 BEFORE/AFTER， 但 contracts-v3 下游投影把两者全部送入 Layer 4，导致相同日期被组装成两个可执行住期。根因不是 Parser 提取或 Parsing输出，而是新的活动事实投影遗漏了旧路径已有的 CURRENT/AFTER 筛选边界。

当前只在 FixedChannelLayer3V2Projector 恢复该边界：BEFORE 继续保存在完整 Layer 3结果和审计sidecar， 但不进入供Layer 4消费的活动 sourceFacts；CURRENT/AFTER 正常进入，真正的多段活动住期仍保持多段。 Parser、Parsing Agent输出契约、Booking Agent、Layer 6及任何外部schema均未修改。聚焦验证12/12通过； 当前8082随后已按上文重启加载，本次仍没有运行新EML。

2026-08-20 5178 前端视觉版本错位诊断

用户指出 5178 回放页与最新卡片视觉不一致。只读版本、浏览器和文件树对照确认该判断正确：5178 的 /debug/agentbus-eml-replay 仍使用独立深蓝调试展示面，不会自动采用正式业务卡片。5178 的正式订单任务页虽已使用 白色正式外壳，但卡片正文仍是通用字段卡，没有加载项目根目录最新的 Booking、Trace、Basic Information 和姓名组件。

5174 确认直接来自项目根目录，其 /prototype/br00 展示用户记忆中的白色侧栏、扁平大卡片和分区任务详情。 这套原型任务卡及核心样式已存在于合并代码，但 5178 启动时没有开启本地原型模式，因此 /prototype/br00 在 5178 显示“页面不可用”。项目根目录相对 5178 仍有 51 个前端路径差异，包含四个未进入合并树的正式卡片组件及多项卡片接线； 其中 ReservationV4ProjectedBookingCard.vue 与正式订单任务详情页在 20:28/20:29 更新，晚于 20:22 的合并提交， 说明最新视觉还在合并后继续迭代。

结论：11d8351c… 是入口和既有新页面能力的组合版本，不是当前项目根目录“视觉最新全集”。本轮没有修改前后端代码、 运行配置或服务，也没有提交；后续需由用户决定是只把最新正式卡片纳入 5178，还是进一步让 Debug 回放页也采用统一产品外壳。

2026-08-20 Booking Agent Skill V3 与 contracts-v3 本地回放切换

用户确认当前 SuperAgent Booking Profile 已切换为 Skill V3。切换前只读核对最近 20 条回放，没有正在处理的任务；保留的 一条 PREVIEW_READY 仅为未提交预览，不受后端重启影响。当前工作区执行 ./mvnw -DskipTests compile 成功后，只停止旧 8082 并使用既有 .env.local-replay、local,local-replay 配置启动当前源码；5178 前端 PID 551 未重启或修改。

新后端 PID 2786 监听 127.0.0.1:8082，build time 为 2026-08-20T13:04:33.873Z。H2 schema V34 与测试 PostgreSQL schema V16 均已是最新；health 为 UP，固定酒店为 HOTEL-LOCAL-REPLAY。5178 代理 capabilities 返回 PostgreSQL、Parsing Agent、Booking Agent、strict execution 与 execution 全部 ready，missing_configuration=[]， 回放页面 HTTP 200。系统当前不校验远程 Skill 版本号，因此 Skill V3 身份以用户已完成的 SuperAgent 配置为准；本轮未上传或执行 EML。

2026-08-20 多段住期 contracts-v3 本地实现

已按 ADR-024 完成“一个 Group Code 一张订单、订单内多个独立住期段”的本地代码改造。Parser 与 Parsing Agent 契约未变；Layer 3 下游开始保留 source_segment_ref，Layer 4 生成 stay_segments[]，Booking Agent compact v2 只按订单 target 判断，Layer 5B/6 与 V4 任务卡沿用同一住期数组。住期间隔不会被拉平；Rate、早餐和 Booking Type 仍只保留一份。多住期 Allotment 定量扣减继续转人工。

外部契约为 booking-contracts-v3、compact input/decision v2 和 Candidate v3；内部 Java V2/V1 类名按 ADR 保留以缩小改动。Layer 6 同时修正了一个状态分类：Booking Type 缺失只进入人工，不再额外触发 Rate 技术阻断。 Booking Agent Skill V3 HOLD 包已生成，SHA-256 为 7be7a87e1a7c41f009733668b1a2b60d93f62add2c017f6d84b4cde01084e0ce。

验证通过：后端主源码与clean test compile、Layer3→Layer4→compact/Layer5B→Layer6→V4 最终聚焦 58/58、前端 V4序列化11/11及typecheck、Skill source/archive validator和包测8/8。此段记录的是本地实现完成时状态；Skill 与 8082 现已按上文切换，真实 EML 尚未上传。

2026-08-20 完整新前端与本地免登录回放合并

已按用户授权把完整新订单/任务工作台提交 48f53762… 与本地免登录回放提交 dc10db87… 合并为独立提交 11d8351cf110df503e804e98522cc15e8d9801d0（feat(frontend): 合并完整工作台与本地回放）。组合版本保留 AgentBus EML 回放，同时为有限只读权限身份补齐订单列表、我的待办、待归属消息和消息通知入口；入口继续沿用现有权限 过滤，没有扩大确认、编辑、PMS、系统管理或其他写入权限。

提交前已通过前端类型检查、44 个测试文件共 337 项测试、生产构建（499 modules）和代码规范检查（0 errors； 41 个既有排版 warning）。浏览器逐页确认五个工作区都能打开：订单列表显示订单工作台，我的待办显示任务卡队列， 待归属消息显示待复核条目，消息通知显示通知列表，回放保持可执行；所有页面均展示完整左侧入口，浏览器未记录错误或警告。

5178 已切换为该组合版本，当前前端 PID 551；8082 仍为原 PID 97272，没有重启或修改。首页、订单、待办、 回放入口均为 HTTP 200，匿名身份仍为受限 LOCAL_TEST_BYPASS；capabilities 为 strict/execution ready， missing_configuration=[]，PrimeIcons 字体加载为 HTTP 200。专用工作树中原有三项未提交回放展示/后端成果及本地运行文件 继续保持未暂存，没有进入本次提交；本次未 push，未上传 EML，未调用 Agent/PMS/Opera，未修改数据库、业务规则或后台流程。

2026-08-20 多段住期产品决定与契约审计（已进入上文本地实现）

用户已确认目标产品模型：同一非空 Group Code 仍是一张订单，订单内允许多个独立住期段；每段分别保留到店日、 离店日和房型房量，不得把间隔日期拼成连续住期。此段记录的是实现前审计基线；当前已完成本地代码，但运行服务尚未切换。

只读代码与 replay 审计已定位首个信息丢失点：Parser TargetRef 和 Layer 3 merge 的 parser_target_ref 均保留 segment_id，但 FixedChannelLayer3V2Projector 只投影行与房型引用，丢弃 segment；Layer 4 随后把同一行的多组日期 收进单值集合并置空。Layer 5 Candidate、Layer 6 校验和 V4 任务卡也仍是单一住期结构。

建议以新 Booking contract 版本成套迁移新上传任务：保留 Parser/Parsing Agent 契约，向 Layer 3 下游事实传递 segment 引用，Layer 4 建立订单内 stay_segments[]，Booking Agent 按订单 target 返回短决定，Layer 5B/6 和 V4 投影消费同一段列表。现有 JSON 持久化表可复用，只需写入新 contract version；旧 v2 任务保持只读且不作为新执行 回退。该审计计划随后已获确认并由上文 contracts-v3 本地实现完成；Agent发布、服务切换和真实EML仍待后续。

2026-08-20 5178 前端恢复

用户要求重启 5178 时该端口已无监听进程，因此没有停止任何 PID。已从专用本地免登录工作树 /private/tmp/th-hotel-simple-test-cec68284/client（commit dc10db873826c10561b31737dbe55b96bdd1fcc9）启动 Vite， 显式保留 VITE_AUTH_LOCAL_TEST_BYPASS_ENABLED=true 和指向现有 8082 的 API proxy。新前端 PID 98981 监听 127.0.0.1:5178，cwd 与命令行均确认来自该专用工作树；后端 PID 97272 继续监听 8082，未重启或修改。 由于该工作树通过符号链接复用主工作树依赖，首次启动暴露 PrimeIcons 字体路径不在 Vite 默认白名单；已只在专用工作树 未跟踪的 .vite/ 运行时目录增加 5178 配置并重启前端，字体复验为 HTTP 200，Vite 无新增告警。

5178 根页与 /debug/agentbus-eml-replay 均返回 HTTP 200；代理 /api/health 返回 UP，匿名 /api/auth/me 返回受限 LOCAL_TEST_BYPASS / HOTEL-LOCAL-REPLAY 身份。capabilities 显示 replay、capture、storage、 PostgreSQL、Parsing Agent、Booking Agent、V2 authority、strict execution 与 execution 全部 ready， missing_configuration=[]。本轮未修改、暂存或提交源码，未操作 EML、Agent、数据库、队列、PMS 或 Opera。

2026-08-20 AgentBus Layer 6 人工状态与 Rate/Room 展示修正

回放页现将 Layer 6 WARNING / CONTRACT_COMPLETED_WITH_ISSUES 明确展示为“需要人工处理”，并在顶部沿用同一人工状态；真实 FAILED 仍单独展示为“失败”。本次只修改前端状态表达，没有放宽 Layer 6 校验或改变任务终态。

Rate/Room Trace 同时读取 Context Assembly 的 decision_context 与真实运行使用的 decisionContext。历史 replay 2090393755345354754 在加载新代码后返回 RATE_ROOM_RESOLUTION=SUCCEEDED / RATE_ROOM_RESOLVED_IN_CONTEXT_ASSEMBLY，Layer 6 保持 WARNING / CONTRACT_COMPLETED_WITH_ISSUES。 前端聚焦测试 7/7、后端聚焦测试通过；8082 PID 97272 从原本地回放 H2 目录启动，health 与 trace API 均为 HTTP 200。

同一 replay 还证明多段住期尚未形成产品与数据契约：Parser/Parsing Agent 已保留同一 Group Code 下的多个日期段，但 Layer 4 当前只能给一张订单保存一组 arrival/departure，因此两个多段订单在 Layer 6 被正确转为人工。该问题尚未实现或写成业务决定， 需用户确认“一张订单包含多个 stay segments”的产品模型后另行改造。

2026-08-20 现有新前端版本固化

已将工作区中完成的新订单/任务卡工作台、正式 Reservation 前端、共享 App/路由接线、三语文案、前端服务与类型契约及对应测试，按用户确认的 64 个路径固化为独立提交 48f53762f4eb43f9a60559b9ee83149d5f0fdaea（feat(frontend): 固化新订单与任务卡工作台），父提交为 29db7da4a6c379a38efd3a8b7d6c3a242fb53dae。

混合文件中的本地免登录、AgentBus EML 回放入口/文案、旧 V4 catalog/binding preview、早餐餐厅和调试路由均未进入该提交；后端、数据库、Agent、业务规则、开发回放页面和其他并行修改均未改动或暂存。为保持旧 Processing Run 页面兼容，V2 前端合同只新增具名 V2 类型，旧通用类型别名不扩大为联合类型。

对候选暂存快照执行 vue-tsc --noEmit 与 Vite production build 均通过，Vite 转换 483 个模块；最终在真实工作区执行标准 pnpm build 也通过，转换 500 个模块，两次均只保留既有大 chunk 警告。没有补入新的正式前端依赖。由于基线中已有 Debug replay 文件引用两个未跟踪 fixture，构建隔离目录仅临时提供工作区现有的 localAgentBusReplayPrototype.ts 与 localAgentBusReplayTraceFixtures.ts，二者没有进入本次提交。

当前 feature 分支已原子前移到该提交，真实索引无 staged change；工作区原有并行改动继续保持未暂存。没有 push、部署、清理旧页面或修改运行态。

2026-08-20 本地回放调试免登录

按用户明确要求，现有本机 local-replay 调试环境改为自动进入，不再要求提供账号密码。后端免登录身份只在 local-replay profile 且 auth.local-test-bypass.enabled=true 时启用，固定使用 LOCAL_TEST_REPLAY_OPERATOR / HOTEL-LOCAL-REPLAY；前端还要求开发模式和 VITE_AUTH_LOCAL_TEST_BYPASS_ENABLED=true。正式 bearer 登录、密码认证、酒店隔离和权限检查均保留。

该本地身份只有 EML 回放、SourceMessage 原文/历史订单/任务只读权限，没有系统管理、订单确认、编辑或 PMS 权限， 也没有创建用户、session 或 token。实现保存在未推送的本地分支 local/debug-login-bypass-20260820，commit 为 dc10db873826c10561b31737dbe55b96bdd1fcc9；未进入远程功能分支。

当前本地测试运行态为后端 PID 92561 独占 8082、前端 PID 94739 独占 5178，8080/8081 无监听； health UP 且 build commit 精确回显 dc10db8…。匿名 /api/auth/me 返回 authentication_mode=LOCAL_TEST_BYPASS，回放 capabilities 为 strict ready、缺失配置为空；浏览器已直接进入 /debug/agentbus-eml-replay，页面、中文文案和历史列表均正常，没有登录表单。历史 legacy replay 仍只读可见， Parsing/Booking/Workbench active 与活动 lease 均为 0。本轮没有上传 EML、调用 SuperAgent/PMS/Opera、修改 Agent 规则、Layer 3–6 产品逻辑或数据库业务结构。

5178 曾被另一任务“开发调试1”按“从正确目录重启 5178”的要求替换为主工作树 Vite PID 93770，该前端不读取 专用的 VITE_AUTH_LOCAL_TEST_BYPASS_ENABLED 开关，因此路由再次进入登录页；用户点名的“现有新前端版本”任务仅做 只读候选文件审计，没有操作运行时。现已只停止错误的 5178，并从上述本地免登录 deployment worktree 的 client/ 目录恢复为 PID 94739；8082 未重启。恢复后调试路由 HTTP 200，匿名 auth、strict capabilities 和端口检查均通过。 浏览器生成的断网页受 URL 安全策略限制无法自动刷新，当前页面需人工刷新一次。

2026-08-20 Parsing Agent精简输入保留来源列

最新LianTai手工运行已加载RC4规则，但Provider实际输入丢失source_column，导致Agent重新阅读长表头、把一项G列备注 误判为Parser重复内容，并在反复判断后提交不完整JSON。根因是compact handoff把所有名称包含column的上下文字段都当成 技术坐标删除，而Parser原始material实际已提供G/I来源列。

当前只在FixedChannelParsingAgentCompactHandoff精确保留source_column，普通坐标和其他技术元数据继续删除； Parser、Parsing Agent Skill/Main Prompt、输出Schema、接收器、Layer 4–6、数据库均未修改。 FixedChannelParsingAgentCompactHandoffTest聚焦测试3项中2项通过、1项按既有外部日志条件跳过，构建成功。 代码尚未重启加载，也未重新运行SuperAgent或真实EML。

2026-08-20 Parsing Agent按LianTai来源列直接处置备注

本轮只把LianTai备注判断从“阅读长表头后猜是否等同REMARK”改为直接使用Parser已提供的列编号： material_purpose=USER_REMARK且source_column=G或source_column=I时，完整原文展示、固定CONSUMED并引用 对应display-*，随后冻结。G列动作和日期沿用Parser既有事实；I列是原始REMARK。其他列继续使用既有规则。

Parser、结果Schema、接收器、Layer 4–6、数据库和运行时均未修改。Python聚焦测试25/25及确定性打包/check通过； 生成9成员Parsing Agent Skill V2 RC4，SHA-256为 5b7021511263adba134ff5b63773240010e9c5a243fdfbadcffade2be2f6a4c3。独立Main Prompt SHA-256为 d795b60bce45c192130b816c63af9b3f9de9b5f205e92cbe1f43f86e13f06bc8。RC4尚未发布到SuperAgent，也未运行真实EML。

2026-08-20 Parsing Agent固定备注唯一展示路径

同一LianTai/QBD输入的重复手工运行证明，旧规则仍允许Agent在“展示、Parser重复或人工复核”之间反复选择，导致耗时和 输出不稳定。本轮把两类表头收敛为唯一处理路径：LianTai固定活动备注/REMARK与QBD WAITING 等待确认下的每项材料 都完整原文展示，固定CONSUMED并引用对应display-*；不再按金额、日期、动作、餐厅或LINE等内容重新分类。

QBD CUT_SOURCE目标现明确填写正文来源编号group_code=<code>，同时继续禁止另建GROUP_CODE候选事实；Main Prompt开头 已收敛为系统校验compact输入与Profile的一句话。Parser、结果Schema、Java接收器、Layer 4–6、数据库、队列和运行时均未修改。

Python聚焦测试25/25及确定性打包/check通过；生成9成员Parsing Agent Skill V2 RC3，SHA-256为 b08f949fbdd8fd471dc390881433fec8b4236d8ddcbc7edfa5661fe7fa3e1784。独立Main Prompt SHA-256为 b9bb01b4ba212893c9874e9586d1940b7c5c7d77b24674c22db137f5dd1840ec。RC3尚未发布到SuperAgent，也未运行真实EML； RC2的重复材料处置规则仍保留为通用规则，但已被本次两类固定表头规则覆盖。

2026-08-20 Parsing Agent重复材料引用闭环修正

最新LianTai手工运行证明动作记录材料已能正确判断为Parser已提取，但Agent把 REDUNDANT_WITH_PARSER_FACTS的output_refs留空，违反现有信息系统接收契约。当前只在Parsing Agent Skill V2、 通用契约、LianTai规则和独立中文Main Prompt中补齐同一规则：选择该处置时必须同步引用同一target/row中直接对应的 F* Parser facts，处置与引用一起冻结；没有对应fact时不得使用该处置。

Parser、结果Schema、Java严格接收器、数据库及Layer 4–6均未修改。Python聚焦测试25/25和确定性打包/check通过； 生成9成员Parsing Agent Skill V2 RC2，SHA-256为 85eb7776349849f7a75106f0ceeb113252b52428d4e0872f2635fcee18553e96。通用Skill quick validator仍因本机缺少PyYAML 未执行；项目自身source/schema/fixture/semantic校验已通过。尚未发布到SuperAgent，也未运行真实EML；下一步只需同步 RC2 Skill与独立Main Prompt后，用同一LianTai输入复测一次。

2026-08-20 Parsing Agent QBD/LianTai备注与动作模板规则已收敛

本轮只更新 Parsing Agent Skill V2、独立中文 Main Prompt、渠道规则和离线验证资产。QBD/LianTai中没有明确 Tour Code/目标和具体变更的New Booking / Update Booking / Cancel Booking固定为模板摘要并直接忽略；QBD CUT_SOURCE固定只生成一个来源目标、一个CANCEL来源动作及source-to-actual关系，不再额外生成GROUP_CODE候选、 动作日期或重复展示。

LianTai REMARK材料固定为原文展示，不参与业务判断；G列活动记录中的NEW/AMEND/CANCEL和日期复用Parser事实， 不重复判断或单独输出，同一材料内的餐厅/用餐和普通非执行服务备注只展示供员工核对。QBD/LianTai的餐厅与早餐 仍由后续选中的Rate Code产生，没有新增字段，也没有修改Parser、结果Schema、严格接收器、Layer 4、数据库或运行时。

输出ID按数组和输入顺序固定编号，末尾只做一次必填字段、JSON、ID唯一和引用闭合的机械检查，不进行第二轮业务复核。 Python聚焦测试25/25、项目Skill校验和确定性打包检查通过；9成员RC1包SHA-256为 5b75969e3eda79b13232c00a35d3401958a52b12d2bd812a85cbfa7587379315。通用Skill quick validator因当前Python缺少PyYAML未执行成功， 但项目自身完整source/schema/fixture/semantic校验已通过。本轮未发布SuperAgent、未重启8082、未运行真实EML； 需同步新的Skill包和独立Main Prompt后再评价实际耗时与行为。

2026-08-20 V2 与旧业务执行剥离完成

初始选择性检查点 refs/backup/v2-before-legacy-separation-20260820 → daf142953256805f7abe89217c1bacde70eb6a7e 保留作审计。 独立检出验证发现它漏收了 V2 已直接引用的 AgentBus replay、对象存储和正式工作台共享依赖；补齐最小编译闭包后的 可恢复基线为 refs/backup/v2-before-legacy-separation-20260820-complete → 694c4317a32f737c0293bf7b10b82f096b29887b。该基线已在独立 worktree 通过干净 test-compile；操作没有移动 HEAD/当前分支或改变真实索引 tree c35a080025d8765602795693bb1ccce4c98ea46b，也没有纳入 Agent 规则或回放展示修正。

新 EML 只允许 FRESH_DELIVERY + REQUIRE_REAL_L3_L5；显式旧策略在持久化前返回 400，空策略不再解析为旧模式， V2 不可用/非权威结果沿既有失败与人工路径结束。历史 LEGACY_COMPATIBLE replay 仍可 GET/list/trace/lifecycle， 但不能重新执行。

新鲜 QBD replay 2090335718358253570 和普通 LianTai replay 2090339484381872130 均进入 Layer 6， 两次 Booking Provider 都使用当前 Profile version 9fdc699a-3d4b-4542-9e3c-1156d1b4c6e6 及 RC4 成员路径； 无旧 dispatch、Field Recovery 或 legacy policy 执行。这些新运行证据已取代 2026-08-19 的旧 29 文件历史运行判断； Booking 专用 key 已在 .env.local-replay 通过 TH_HOTEL_BOOKING_BUSINESS_AGENT_OPEN_API_KEY 配置，未要求重新提供。

验收通过后已按顺序物理删除旧调用入口、parseLegacy、Field Recovery 执行包/专用 Adapter、 旧 dispatch writer/service、contracts-v1 决策/校验/投影/重试/确认执行图、旧 writer DTO 和对应测试。 保留通用 SuperAgent Open API/SSE、Parsing/Booking 专用连接、Provider Journal、生命周期日志、历史 snapshot/entity/mapper/read repository 和 GET-only 查询。

干净 test-compile 通过；物理删除后的 10 类聚焦测试 56/56 通过，未运行全量或压力测试。 干净构建不再产生旧执行 class；当前唯一后端 PID 78528 监听 8082，8080/8081 无后端监听。 Parsing/Booking/Workbench 排队或运行数均为 0，活动 lease 均为 0，Field Recovery 表 0 行。

最终剥离提交为 cec6828479feb0b8e74975a2c0528d816d145822，位于 codex/v2-legacy-separation-20260820，父提交是上述完整基线；相对基线仅含 116 个剥离文件， 457 行新增、21079 行删除。独立 worktree 再次通过 clean test-compile 和 10 类/56 项聚焦测试。 启动入口审计确认唯一项目启动脚本默认并导出 8082；旧 dispatch worker 类已删除，显式 contracts-v1/Field Recovery 开关会在启动时被拒绝。当前仍只有 PID 78528 监听 8082，8080/8081 无监听，队列/lease/Recovery 均为 0。

用户随后授权“正式合入”。当前开发线 feature/booking-v01-safe-checkpoint 已从 7330ac85… 安全前移到 cec68284…；旧 HEAD 与合入前干净索引分别保存在 refs/backup/feature-before-v2-formal-integration-20260820 和 refs/backup/index-before-v2-formal-integration-20260820。合入过程没有 checkout、覆盖或清理工作树，原有并行 Agent、Trace、前端和项目修改仍作为未提交工作保留，真实索引仍无 staged change。

正式开发线的独立干净副本再次通过 clean test-compile 和同一 56/56 聚焦测试。运行态复验为：8082 health UP、 5178 页面及 API 代理可访问、capabilities 为 BOOKING_DECISION_V2 且 strict/V2 ready、缺失配置为空；历史 replay 仍可查看且 execute 返回 409。PostgreSQL Parsing/Booking/Workbench active 与 lease 全部为 0，Field Recovery 总行数为 0。

用户授权“发布”后，已将上述正式提交发布到远程同名功能分支 origin/feature/booking-v01-safe-checkpoint。远程回读 commit 与本地均为 cec6828479feb0b8e74975a2c0528d816d145822，本地已建立 upstream；发布前干净提交副本通过仓库明文 Secret 扫描， 提交树不含 .env/.env.*。本次仅发布 Git 功能分支，没有合并 develop/master、创建 PR 或部署测试/预生产/生产环境； 工作树中未提交的 Agent、Trace、前端和项目记录修改未进入远程提交。

用户继续授权部署现有测试环境。仓库无 CI/CD、远程测试主机或 SSH 部署入口，因此目标固定为既有本机 127.0.0.1:8082 后端和 127.0.0.1:5178 前端。精确 cec68284… 干净包首次真实启动时发现已提交 application-local-replay.yml 启用了本地对象存储，但发布树漏收对应 LocalReplayObjectStorageService，应用按安全策略 拒绝启动；旧测试运行态已立即恢复。未把独立的本地免登录身份或其认证改动混入。

随后只将上述已有本地回放对象存储实现作为一个部署必需文件提交，形成 29db7da4a6c379a38efd3a8b7d6c3a242fb53dae（parent cec68284…），并以非强制 push 更新同名远程 feature 分支； refs/backup/feature-before-test-deploy-hotfix-20260820 保留部署修复前恢复点。该提交只新增 124 行、1 个文件， 明文 Secret 扫描、git diff --check、干净 clean package -DskipTests 和关闭 worker 的临时端口启动通过；没有新增测试、 Agent 规则、Layer 3–6 逻辑或数据库业务结构。

当前本机测试环境从独立干净 worktree 运行该提交：后端 PID 89511 只监听 8082，前端 PID 89512 只监听 5178， 8080/8081 无监听；后端与前端代理 /api/health 均为 UP，build_commit 精确为 29db7da…，5178 根页 HTTP 200。 发布版保持正式登录边界，未带 token 的 capabilities 返回预期 401；本地免登录功能仍留在未提交工作区，没有发布。 原 H2 历史库和回放文件目录继续复用，legacy replay 2090320301321498625 以及两条 strict V2 验收 replay 均仍存在且 dispatch 为 null。PostgreSQL Parsing/Booking/Workbench active 均为 0、活动 lease 为 0、Field Recovery 总行数为 0； 本次部署没有上传 EML、调用 SuperAgent、合并 develop/master 或触及生产环境。

同日继续执行的现场只读复核确认该部署仍有效：PID 89511/89512 仍分别独占 8082/5178，8080/8081 无监听； 两条 health 仍为 UP 且 build commit 精确为 29db7da…，未登录 capabilities 保持 401。H2 中 legacy 与两条 strict V2 replay 均为 COMPLETED、dispatch_run_id=null，活动 replay 为 0；PostgreSQL 三类 V2 队列和活动 lease 仍全为 0，Field Recovery 仍为 0 行。部署 Jar 不含旧执行 class，未发生重启、新 EML、Agent 调用或数据库写入。

2026-08-20 AgentBus Rate/Room decisionContext 回放日志兼容修正

回放 Trace 聚合器现同时识别 Context Assembly 输出的 decision_context 和真实 Provider 形态的 decisionContext 包装， 内部房型与 Rate Code 结果仍复用既有提取逻辑；两类结果都存在时继续显示 RATE_ROOM_RESOLVED_IN_CONTEXT_ASSEMBLY，不创建独立耗时或业务执行。

新增真实 decisionContext.order_contexts 包装结构的回归场景。AgentBusEmlReplayTraceServiceImplTest 聚焦测试 11/11 通过， 未运行全量测试、真实 EML 或 SuperAgent。修改尚未加载到当前 8082 进程；需要重启 8082 后回放日志才会使用新聚合代码。

2026-08-20 HOTEL_ACCESS_DENIED 本地回放酒店身份修复

HOTEL_ACCESS_DENIED 的直接原因是前端请求使用 HOTEL-LOCAL-REPLAY，而前一次手工启动 8082 时没有用 set -a 导出 .env.local-replay，后端固定回放身份因此回退为 HOTEL-TEST。前端和后端酒店上下文不一致，后端按设计拒绝访问。

已停止该错误启动的 8082，并按现有启动脚本的环境导出方式重新启动；当前后端 PID 为 72401，前端 5178 保持 PID 71962。 /api/auth/me 返回 HOTEL-LOCAL-REPLAY，8082 health 为 UP，5178 代理 capabilities 返回 execution_ready=true、 missing_configuration=[]。未修改代码、数据库或运行规则，未操作 replay、EML 或 SuperAgent。

2026-08-20 5178 AgentBus EML 页面恢复

页面打不开的直接原因是 5178 Vite 前端未监听；8082 后端已保持运行且 /api/health 返回 UP。本次仅在客户端目录启动 Vite（进程 PID 71962，由 pnpm PID 71957 承载），继续将页面 API 代理到现有 8082；未启动、停止或修改其他服务。

启动后 http://127.0.0.1:5178/debug/agentbus-eml-replay 返回 HTTP 200，8082 健康检查仍为 UP。未操作当前 replay、EML 上传、SuperAgent 或任何业务执行；内置浏览器原错误页因浏览器策略不能由本次工具代刷新，用户刷新当前页即可加载新前端。

2026-08-20 8082 后端重启加载当前代码

按用户要求仅启动 8082 后端，复用 local,local-replay 和现有本地测试环境文件；未启动或停止 5174/5178，未操作当前 AgentBus replay、EML 或 SuperAgent。后端应用 PID 为 71362，Tomcat 已绑定 8082，/api/health 返回 UP。

启动校验确认 H2 本地回放库 schema V34 已完成验证且无需迁移；当前工作区的 Layer 4 Rate/Room Trace 只读修正已由最新类文件加载。

2026-08-20 固定渠道早餐三态与缺价默认 Rate Code

QBD/LianTai来源早餐条件已改为显式三态：独立BF输出true，明确RO/不含早输出false，未声明时不再生成 BREAKFAST_INCLUDED事实。公共字段结构未新增字段，确定规则引用更新为shared-breakfast-explicit-token-v2。

Layer 4现以标准化source_price=null直接触发渠道缺价默认，并先于房型Rate匹配执行：QBD所有房型使用GRPA1， LianTai FIT/GROUP及独立套房统一使用GRP1；套餐早餐继续从Rate目录原子产生。有价格的既有映射不变，明确RO与含早默认冲突仍保持未解析交人工。

Parser/Resolver聚焦测试47/47、Layer3→4 handoff/context聚焦测试11/11通过。未修改前端、数据库、Layer5/6、Agent职责或 新旧代码拆分，未重启8082，未运行真实EML或SuperAgent。后续正式工作台缺价说明仍由独立Active承诺跟踪。

2026-08-20 AgentBus Layer 4 Rate/Room 回放日志归属修正

已完成一项只读 Trace 聚合修正：RATE_ROOM_RESOLUTION 不再用旧的未接线占位结果覆盖真实 Context Assembly 证据，改为读取 现有 order_contexts[].source_units[].source_rooms[].roomtype_resolution 与 order_contexts[].rate_options[].rate_package（兼容 catalog_resolutions[]）中的已解析房型和 Rate Code。 两类结果均存在时，页面和完整生命周期日志显示成功；详情明确标注“计入 Context Assembly”，Layer 4 不生成独立开始/结束时间或耗时。

Context Assembly 尚未完成时，Layer 4 只跟随其真实 PENDING/RUNNING/BLOCKED/FAILED 状态；Context 已完成但没有可识别的两类结果时保持 不可用/告警，不伪造成功。旧的占位快照在有 Context 证据时也不再优先展示。

本轮只修改 AgentBusEmlReplayTraceServiceImpl 的回放只读聚合和对应测试，聚焦测试 AgentBusEmlReplayTraceServiceImplTest 为 10/10； git diff --check 通过。未修改 Rate/Room 业务规则、Agent、数据库、队列、Layer 5/6、前端接口或运行配置，未运行真实 EML、SuperAgent 或全量测试。

2026-08-20 AgentBus EML 前后端运行恢复

页面打不开的直接原因是 5178 与 8082 均没有监听进程。按现有 scripts/start-local-replay.sh 恢复本地回放环境， 后端 PID 为 66066、前端 Vite PID 为 66070；继续使用既有 local,local-replay 配置，未修改代码或数据库结构。

页面入口返回 HTTP 200，5178→8082 代理环境为 execution_ready=true、missing_configuration=[]，并且 postgres_ready=true、parsing_agent_ready=true、booking_agent_ready=true、strict_execution_ready=true；8082 health 为 UP。 当前打开的 replay、EML 上传、SuperAgent 和业务执行均未操作。

2026-08-19 8082 第三次重新编译并重启

按用户要求仅重新执行 ./mvnw -DskipTests compile 并重启 8082。编译成功，当前类文件已是最新；后端新进程 PID 为 55670，继续使用 local,local-replay profile、非生产测试数据库和现有运行配置。

8082 health 返回 UP，H2 schema V34 和 PostgreSQL th_hotel_booking schema V16 均验证通过且无待执行 migration。 5178 保持原进程 PID 52696，没有重启；当前 replay、EML 和 SuperAgent 均未操作。

2026-08-19 最新真实EML在Layer 5被旧Booking Skill输出拒绝

回放2090064050779979777已安全终止，但没有生成订单决定：Booking Agent只调用一次并在约3分15.7秒内完整返回， 平台run本身成功；信息系统随后以BOOKING_AGENT_CANDIDATE_CONTRACT_INVALID拒绝答案，Layer 6验证的是0订单、0动作的 人工风险兜底，不是业务成功。

直接原因是正确Booking Profile仍运行旧29文件booking-desk-event资产，而不是当前17文件Booking Agent Skill V2 RC4。 Agent读取旧Parent/Allotment和旧输出契约，返回parent_decision/unit_decisions/...结构；当前系统只接受 decisions/derived_actions/risk_items/unclassified_texts精简结构，因此在Layer 5B组装前即被拒绝。Agent还把9个明确 UPDATE_BOOKING的来源单元判断为New，这是同一旧规则造成的独立业务错误，不能通过放宽接收器解决。

日志另有两个展示口径：独立Rate/Room行显示未接线，但Layer 5输入实际已有9个GRPA1和18个已解析房型，属于阶段归属缺口； 官方总时长10分43.508秒停在Booking Provider结束，后续Layer5/6快照把实际最后记录延长到约10分59.085秒。 本轮只诊断，未修改代码、配置、Agent或运行环境。下一步仍是同步发布RC4 Skill和匹配Main Prompt后跑一封新EML。

2026-08-19 8082 再次重新编译并重启

按用户要求仅重新执行 ./mvnw -DskipTests compile 并重启 8082。编译成功，当前类文件已是最新；后端新进程 PID 为 54457，继续使用 local,local-replay profile、非生产测试数据库和现有运行配置。

8082 health 返回 UP，H2 schema V34 和 PostgreSQL th_hotel_booking schema V16 均验证通过且无待执行 migration。 5178 保持原进程 PID 52696，没有重启；当前 replay、EML 和 SuperAgent 均未操作。

2026-08-19 Parsing Agent格式化输入与单次执行纪律已本地完成

回放2090053330134888450和两份同数据手工运行日志证明，实际工作量始终是9个目标、114条Parser事实和4条材料； 慢运行的主要问题不是数据量，而是Agent读完必要规则后继续创建待办、调用脚本、反复复核并重复输出。

本地已完成最小调整：Provider把原compact对象改为缩进JSON，字段和语义不变；运行消息、独立Main Prompt和 Parsing Agent Skill同步规定，读完必要规则及输出Schema后不再调用其他工具，固定规则命中后立即冻结，只按输入顺序 遍历一次、检查一次、输出一次，输出后立即停止。业务规则、输入输出字段、Parser、Layer 3–6、数据库、队列、超时、 重试和前端均未修改。

Adapter聚焦测试13/13、Skill package测试25/25和确定性package check通过。新的9成员技术修订包位于 artifacts/parsing-agent-skill-v2-rc1，archive SHA-256为 00cfeeac0da08acdd576367a855e9219a7c77e5d549e9e9bf5c0d50cb0c2d229；业务契约仍为v1.0，产品名仍为 Parsing Agent Skill V2。本轮未发布SuperAgent资产、未重启8082，也未运行真实EML。下一步需同步发布Skill和独立 Main Prompt，再编译重启8082，并用一封新EML观察Parsing耗时和是否只交付一次答案。

2026-08-19 Booking Agent机械校验码回显已从输出契约删除

回放2090053330134888450已证明Booking业务判断正确，唯一阻断是Agent把64位输入校验码抄成96位重复字符串。本地现已按 最小方案删除compact输出中的source_input_hash：Booking Agent只返回业务决定与短引用；Layer 5B使用派单前保留的 canonical input hash组装Candidate，并继续通过同一Agent身份、session和run关联本次结果。

输入hash、系统内部一致性、业务枚举、短引用、严格JSON、Candidate及Layer 6校验均保留；Parsing、Layer 3/4/6规则、 数据库、前端、队列、超时和重试未改。生成17成员booking-agent-skill-v2-rc4 HOLD包，SHA-256为 2fbf18dd06674777c5ed699d603b88c4f6bfc508236dd96bdd7ee98fc7c4c25f。Java聚焦测试24/24、Skill package测试8/8、 项目专用Skill校验和确定性package check通过；未运行全量测试、真实EML或SuperAgent。

新版服务端与RC4需要配套使用，不兼容旧输出。下一步先把RC4发布到当前Booking Agent Profile，再重新编译/重启8082， 最后上传一封新的EML验证9个Update和whole-cancel能够正式进入Layer 6。

2026-08-19 AgentBus EML 页面恢复访问

页面打不开的直接原因是 5178 没有前端监听进程，8082 后端本身仍健康。未重启后端；仅按既有 local replay 环境启动 Vite， 新前端进程 PID 为 52696，监听 127.0.0.1:5178。

页面入口返回 HTTP 200，5178 代理取得 8082 的真实环境状态：execution_ready=true、missing_configuration=[]、 postgres_ready=true、parsing_agent_ready=true、booking_agent_ready=true、strict_execution_ready=true。 当前 replay、EML 上传、SuperAgent 和业务执行均未操作。

2026-08-19 8082 后端重新编译并重启加载当前代码

按本地回放配置重新执行 ./mvnw -DskipTests compile，编译成功（当前类文件已是最新）。随后仅重启 8082，使用既有 local,local-replay profile 和非生产测试数据库；新进程 PID 为 52465，Tomcat 在 8082 正常监听。

启动时 H2 schema V34 与 PostgreSQL th_hotel_booking schema V16 均完成校验且无待执行 migration，健康检查返回 UP， 运行标记仍为 m002_v4_review_pointer_deployment_proof_v1。5178、当前 replay 2090023705526636546、EML 和 SuperAgent 均未操作。

2026-08-19 Booking compact引用规则已对齐，待新EML重验

回放2090023705526636546已终止，但不是Booking业务成功。Parsing Agent成功；Booking Provider也只调用一次， 在1分48.850秒内返回了完整2419字符JSON，内容为9个Update和1个Allotment整块取消。失败发生在信息系统收到答案后的 Layer 5B严格组装，不是Provider超时、断流、重复提交或版本门禁。

Booking Agent把9条ALLOTMENT_SOURCE_TO_ACTUAL关系分别放进Update决定的linked_relationship_refs，而该字段只允许 当前目标的GROUP_CODE_REPLACEMENT，因此第一条Update即被拒绝。整块取消还把短目标T10写成source_target_ref； 该字段实际需要来源团号LTQ260812，所以清空前述关系后仍会触发下一道拒绝。系统随后正确生成 FAIL_CLOSED/RISK_NOTIFICATION，Layer 6成功校验的是这张人工风险通知，不是9个订单任务。

本地已完成最小修正：普通决定的linked_relationship_refs只允许当前目标的GROUP_CODE_REPLACEMENT， ALLOTMENT_SOURCE_TO_ACTUAL只用于Allotment派生动作；whole-cancel的source_target_ref必须填写材料中的来源Tour Code， 不得填写T10等短别名。Layer 5B继续严格拒绝错误答案，并分别记录 BOOKING_AGENT_LINKED_RELATIONSHIP_INVALID与BOOKING_AGENT_ALLOTMENT_SOURCE_INVALID，两者仍不重试并转人工。

Booking Skill产品名和Schema不变，技术修订包为booking-agent-skill-v2-rc3，17成员HOLD archive SHA-256为 80a145185b6a0825ade5190ee069c02a5e996d39ef86a6d3d92628da55dc3212。Skill package测试8/8、Booking compact/worker 聚焦测试21/21及确定性package --check通过；未运行全量测试、真实EML或SuperAgent。下一步发布rc3后用一封新EML重验， 不重放旧记录。Rate/Room阶段状态和Layer5/6内部耗时的既有可观测性缺口不属于本次修正。

2026-08-19 双Agent发布版本改为只记录、不阻断

Parsing与Booking现在只按固定SuperAgent Profile ID核对是否派给正确Agent。Provider实际published version继续写入 运行日志和调用审计，但即使与历史配置值不同也继续处理；业务结果自身的协议版本、JSON、输入身份、来源和Layer 3–6 校验均未改变。

五个聚焦测试类共47项全部通过并完成编译。确认没有PROCESSING回放后，只重启8082为PID 49214；5178未重启。 8082 health为UP，8082直连与5178代理均显示PostgreSQL、双Agent、V2 authority和strict execution ready， 两个profile version配置均为空且missing_configuration=[]，证明版本号不再是就绪条件。本次没有上传EML或调用Agent； 下一步由一封新EML验证真实双Agent结果能够越过旧version门禁。

2026-08-19 最新真实EML被双Agent批准版本门禁安全终止

回放2090013369704624129没有再出现余额不足。Parsing实际version已变为edba19e8-...，本地仍批准 0e9c63ba-...；Booking实际version已变为c7c88773-...，本地仍批准4525c685-...。两个Profile ID均正确， 只是version不一致。

Parsing Agent完整答案本身正确识别了LTQ260812和9条Allotment关系，但身份门禁后未被Layer 3采纳，Layer 3实际为 PARTIAL并只向后交付9个Deterministic Parser订单；Lifecycle却误显示Parsing成功。Booking Agent同样在尚未返回final、run仍为 running时被version门禁停止，最终0决定、0动作并安全转人工。18个房型、9个GRPA1 Rate和BF拆分继续正确。 若两个新version是用户预期发布版本，下一步只更新批准version并重启重跑；否则先排查SuperAgent版本路由，不改业务规则。

2026-08-19 最新真实EML在Booking Agent模型余额不足后安全转人工

回放2090007645104615425已经终止，但不是业务成功：Layer 5没有生成任何Booking决定或动作，Layer 6校验通过的是 fail-closed人工风险通知。Parsing Agent成功但耗时5分50秒；Layer 4的9个实际订单、18个房型和全部GRPA1 Rate均已正确解析。 实际链路也证明BF已由Layer 3拆成早餐标记，Layer 4收到不含BF的标准房型，因此该方向不再需要重复修改。

Booking Agent使用正确批准version，但底层模型明确返回402 Insufficient Balance；SuperAgent最终消息是输入回显加错误信息， 不是业务JSON。信息系统正确拒绝了它，没有产生错误订单；但错误被误记为临时传输失败，并对同一个已失败run读取三次后才形成 BOOKING_AGENT_RETRY_EXHAUSTED。下一步应先恢复模型额度；用户确认后，再最小修正明确模型失败的分类与停止重试规则。 独立Rate/Room阶段状态和若干本地阶段耗时仍有Trace展示缺口，不是本次业务失败原因。

2026-08-19 Layer 4空格/连字符规则已加载到本地8082

后端重新编译成功，并使用现有.env.local-replay、local,local-replay配置只重启8082。新后端PID为46642， 健康状态为UP，build time为2026-08-19T09:25:05.666Z；5178仍为原PID 26751，未重启。

H2保持V34、Booking PostgreSQL保持V16，无迁移；回放、PostgreSQL、Parsing Agent、Booking Agent、V2 authority 和strict execution全部ready，missing_configuration=[]，当前没有PROCESSING回放。未上传EML、未调用Agent， 两条PREVIEW_READY记录仅为尚未开始执行的历史预览，不受本次重启影响。

2026-08-19 固定渠道 Rate/Room 规则修正

Layer 4 已按最新产品规则处理 QBD/LianTai：TRP→RM2→GRPA1，SUP TRP/SUPTRP→RM3→GRPA1； Roomtype 与 Rate 来源房型比较统一忽略空格和 ASCII 连字符 -，因此不同排版可以精确对齐。BF、Q10、 括号、床型和其他业务字符仍必须一致，不增加包含、模糊或相似匹配。

同订单同时有普通房与套房时，套房继续继承该订单唯一 Rate；独立订单只有套房时改为独立解析，QBD 缺价沿用 GRPA1。修改仅位于 QBD/LianTai V2 Resolver，未改共享 Roomtype 目录，避免影响其他公司。Resolver 聚焦测试 11/11、Layer 4组装测试8/8通过；2026-08-19补充连字符规则后同一19项再次全部通过。未运行全量测试、真实EML， 也未修改Parser、Agent、Layer 5、数据库或前端。

2026-08-19 Layer 5 whole-cancel 来源编号取证修正

ALLOTMENT_SOURCE_WHOLE_CANCEL 的 source_target_ref 现在只在 Layer 3 material_observations[].attributes.group_code 中做精确匹配；匹配成功通过来源编号校验，未匹配仍使用原有拒绝处理。该分支不校验动作语义、不要求实际订单或 Allotment 关系；ALLOTMENT_SOURCE_DEDUCTION 和其他 Layer 3/Agent/数据库逻辑不变。针对 LTQ260812 的单测通过， 没有运行全量测试或真实链路。

2026-08-19 AgentBus EML 回放正常 Parsing 排队状态展示

回放页对 FIXED_CHANNEL_PARSING_AGENT_QUEUED 做只读展示归一化：当 SourceMessage 已捕获并已进入 Parsing Agent 队列时，页面显示“成功”，不再显示“有提醒”，并提示“已进入 Parsing Agent 处理”。原始 trace、 下游 warning code 和其他阶段状态不变。仅修改前端展示与对应聚焦测试；Vitest 6/6 通过，作用域 ESLint 无错误。

2026-08-19 本地回放测试配置已持久化

本地测试专用的双 Agent 凭据、Booking PostgreSQL 连接和真实回放运行开关已保存到仓库根目录的 .env.local-replay。该文件命中现有 .gitignore，权限为 600，不会提交到 Git；项目文档和启动日志均不记录 任何 Secret 值。scripts/start-local-replay.sh 启动时会自动加载该文件，解决终端或电脑重启后需要重新手工配置的问题。

脚本语法、Git 忽略规则和必需配置加载已做轻量检查并通过。本轮没有重启当前 8082/5178、没有上传 EML、 没有调用 SuperAgent，也没有修改 Agent、Layer 3–6、数据库结构或生产配置。

2026-08-19 Parsing Key 已替换并通过SuperAgent最小鉴权

在最新回放已终止后，8082只从旧进程内存继承原PostgreSQL、Booking Agent、双Agent版本门禁、 AUTHORITATIVE与projection配置，并用用户新提供的Parsing专用Key覆盖旧值后重启。Secret未回显， 未写入代码、YAML、项目文档或启动命令。

新8082进程PID 40256；H2 V34与测试PostgreSQL V16无迁移。8082 health为UP，本地身份仍是 HOTEL-LOCAL-REPLAY；8082直连与5178代理的capabilities均显示Parsing批准版本、Booking批准版本、 PostgreSQL、V2 authority和strict execution就绪，missing_configuration=[]。旧回放仍保持终态，没有重跑。

只用新Key创建了一个不发送message、不启动Agent run的最小鉴权session，SuperAgent返回 active，证明新Key已通过鉴权。这一步不证明Parsing业务结果或Profile/version运行身份；下一步可以直接 上传新的真实EML重跑全链。

2026-08-19 真实 EML 回放终态为人工风险，不是订单处理成功

回放 2089973216000811009 已终止，顶层为 booking_run_status=VALIDATED / terminal=true，但 Layer 6 校验通过的是 Layer 5 fail-closed 生成的 RISK_NOTIFICATION；最终为0个target decision、0个derived action， 因此不得解读为9个Update和Allotment整块取消已成功生成。

Parsing Agent在49.339秒内连续3次创建session都收到401 Invalid Open API key，没有Provider session/run或 Agent结果；Layer 3因此是PARTIAL/AGENT_RETRY_EXHAUSTED，只保留基础Parser的9个actual团号，没有正文 LTQ260812 Allotment source事实。Trace将该阶段误标为SUCCEEDED/PARSING_AGENT_COMPLETED，这是状态投影问题。

Booking Agent只派单1次，Provider总用141.608秒，返回完整裸JSON：9个UPDATE_BOOKING加1个 ALLOTMENT_SOURCE_WHOLE_CANCEL(LTQ260812)。分段答案已成功组装为2,389字符完整结果，旧的2,000字符 message.final截断未再丢失尾部。但严格接收因Layer 3不存在LTQ260812 source依据而以 BOOKING_AGENT_CANDIDATE_CONTRACT_INVALID拒绝整个Candidate，改写为人工风险通知。

Layer 4产物证明Resolver已执行：9个订单的Roomtype均精确解析，Rate均未解析（普通房为 MAPPING_NOT_FOUND，纯套房为SUITE_ONLY_WITHOUT_MAIN_ROOM_RATE）。独立RATE_ROOM_RESOLUTION阶段仍误报 AUTHORITATIVE_RATE_ROOM_RESOLVER_NOT_WIRED，Context Assembly、Rate/Room、Layer 5本地接收与Layer 6仍缺准确耗时。 顶层总耗4分31.295秒停在Booking Provider结束时刻，而最后Layer 6时间表明真实可观测全链跨度约 4分48.644秒，总耗时终点也需纠正。

2026-08-19 真实 EML 全流程测试环境已就绪

对任务 01a012da-681a-72c1-8c7e-dbd38d4aac86 的实现和当前合并代码复核确认：后端与前端主轨迹均固定为真实 12 阶段， Parsing Agent 使用真实 execution/V2 artifact 对账，旧 Field Recovery/Layer 7 只保留历史详情读取；后续 Booking 身份与计时 改造没有破坏该流程。当前代码重新执行后端聚焦测试 10/10、前端 5/5 和 vue-tsc --noEmit 均通过。

Parsing Agent max-total-wait 默认已从15分钟收敛为10分钟；4分钟仍只提示继续处理，不取消或重派。配置聚焦测试及后端编译通过。 用户提供的测试PostgreSQL和双Agent凭据通过隐藏终端输入仅注入8082进程内存，未写入代码、配置、文档或日志。8082新版后端 PID 39461已启动，复用既有5178前端；H2 V34、Booking PostgreSQL V16均无需迁移。

5178能力接口确认：Parsing批准version 0e9c63ba-be3b-451d-8a2e-5488975651ad、Booking批准version 4525c685-612d-4374-ab9b-3e8e78ae7a33、PostgreSQL、BOOKING_DECISION_V2、strict execution全部ready， missing_configuration=[]。Parsing、Booking、页面投影和Processing四类活动任务均为0。内置浏览器已停在真实EML入口，页面显示 “后端已连接”“可执行回放”，文件选择可用；本轮未选择、上传或执行EML。

2026-08-19 Booking 批准版本、身份门禁与全流程用时已统一修复

信息系统的 Booking Agent 默认批准版本已更新为用户确认的实际发布版本 4525c685-612d-4374-ab9b-3e8e78ae7a33。Provider 在同一 run 中一旦返回 Profile 身份即立即核对；成功结束后再读取 同一 run 的权威身份做最终确认，不重新派单。这样可以把“Agent 身份不对”和“Agent 已回答但信息系统接收失败”明确分开。

回放日志现为真实 12 阶段，并补齐 Deterministic Parser、Parsing Agent、Context Assembly、Rate / Room Resolver、 Layer 6 Validation 和全流程总耗时。Layer 5 另外拆分“Booking Agent 处理”与“信息系统接收与组装”的耗时、状态和失败点； Parsing Agent 用时按 worker 实际领取到完成计算，不再缺失。

后端相关聚焦测试、编译和前端 5 个聚焦场景/typecheck 均通过。为加载新代码而停止旧 8082 后端后，发现旧进程凭据只在 进程环境中；安全策略禁止把凭据复制进启动命令，因此没有绕过。最终复查确认 5178 和 8082 均未监听，待用户从已安全加载 凭据的终端重新启动本地回放环境；本轮未运行真实 EML，也未把聚焦测试写成真实全链验收。

2026-08-19 AgentBus EML 回放主轨迹已收窄为真实 12 阶段

本轮只修改 AgentBus EML 回放 Trace 的只读状态聚合、前端主轨迹和直接受影响的聚焦测试。后端主 trace 现在固定输出： EML_PARSE、MEDIA_PREPROCESS、AGENTBUS_FRAME、SOURCE_CAPTURE、SOURCE_MESSAGE_ENVELOPE、MATERIAL_PACKAGE、 DETERMINISTIC_PARSER、PARSING_AGENT、CONTEXT_ASSEMBLY、RATE_ROOM_RESOLUTION、BUSINESS_DECISION、VALIDATION。 FIELD_RECOVERY、CONFIRMATION_PROJECTION、HUMAN_CONFIRMATION 不再占用主轨迹；枚举、历史快照和直接详情读取仍保留。

PARSING_AGENT 不再由旧 execution_policy 决定是否出现，也不再由前端临时补阶段。对 BOOKING_DECISION_V2，聚合器读取已有 Parsing execution、完成时间戳和 V2 artifact（含 Layer 3/4/5/6 现有命名），以真实记录覆盖过时的 PENDING 快照；缺少 Parsing execution 不会被 Booking 终态冒充成功。Layer 4 没有权威 Rate/Room Resolver 产物时仍显示真实的“当前不可用”，不伪造成功。

前端主轨迹增加同样的 12 阶段兼容过滤，去除基于 booking_run_status 的虚拟当前阶段；只有 trace 中真实 RUNNING 的阶段显示转圈和顶部 “正在处理：…”，没有真实运行阶段时显示“正在等待下一阶段”。Layer 5 的 Booking Agent 判断/信息系统组装双进度保持不变。

聚焦验证：mvn -Dtest=AgentBusEmlReplayTraceServiceImplTest test 10/10； pnpm exec vitest run src/tests/agentBusReplayTraceWorkspace.spec.ts 5/5；pnpm exec vue-tsc --noEmit 通过； 作用域 ESLint 0 errors、5 个已有模板格式 warnings。未上传/执行 EML、未调用 SuperAgent、未重启 8082、未写数据库，未运行全量测试。

2026-08-19 8082 后端已加载新版代码

用户确认此前 8082 仍运行旧代码。本轮仅重新编译 server（mvn -DskipTests compile）并重启 8082，未重启 5178、未操作当前 replay。 后端以 local,local-replay 和 HOTEL-LOCAL-REPLAY 身份运行；用户提供的非生产 PostgreSQL、Parsing V12、Booking RC6 和严格模式配置只注入当前进程环境，未写入代码、YAML、日志或项目文档。

新进程 PID 为 34880，8082 /api/health 返回 UP；启动日志确认 Tomcat 绑定 8082、H2 public schema V34 与 Booking PostgreSQL schema V16 均无需迁移。 8082 capabilities 只读返回 postgres_ready=true、Parsing profile/version 为当前批准版本、Booking RC6、v2_authority_ready=true、strict_execution_ready=true、 execution_ready=true、missing_configuration=[]。本轮没有上传/执行 EML、没有调用 SuperAgent，也没有修改数据库结构或业务配置。

2026-08-19 SuperAgent 正常Trace与断流恢复保留 Booking Agent 身份

真实回放 2089933714020610050 中，Booking Agent 已返回完整业务答案，但恢复阶段的 run snapshot 虽包含实际 Profile ID/version，客户端只读取了运行状态，最终结果身份为空并被本地门禁以 BOOKING_AGENT_PROVIDER_PROFILE_MISMATCH 拒绝。随后回放 2089941024214331393 证明正常连续Trace也可能只返回完整 答案和完成事件、不返回Profile身份。本轮让断流状态查询同步应用snapshot身份，并让正常Trace仅在成功完成且身份缺失时 读取一次同一个run详情；明确失败不补查，已有身份不重复查询。

完整答案仍来自公开事件流，不使用run详情中的final摘要；身份门禁、Agent、Layer 5/6、超时、数据库、日志聚合和前端 均未改变。SuperAgentOpenApiClientImplTest 聚焦测试 7/7 通过。未重启服务、运行真实 EML 或调用 SuperAgent，真实全链 结果仍待加载新版后端后的下一次回放确认。

2026-08-19 AgentBus 回放全流程状态与当前层级纠正

真实回放 2089933714020610050 暴露了两个展示错误：根回放 COMPLETED 只代表邮件已登记，但业务运行仍为 AWAITING_PARSING_AGENT、Trace terminal=false；同时该记录虽然已有 BOOKING_DECISION_V2 Processing Run， execution_policy 仍为 LEGACY_COMPATIBLE，页面因此误标旧兼容流程。Trace 又没有 PARSING_AGENT/RUNNING 阶段， 原页面只能显示“正在等待下一阶段”。

前端现以“严格策略，或已有 BOOKING_DECISION_V2 Processing Run”识别真实 Agent 流程；最近列表中的 COMPLETED 改为中性的“回放已登记”，不再显示成功色。Trace 有明确 RUNNING 时仍以阶段事实为准；没有时只使用已有 booking_run_status 将 Parsing 等待、Booking 等待/处理和 Layer 6 校验投影为当前层级，并在阶段轨迹显示当前转圈。 缺失的 Parsing Agent 行仅为不可点击的展示项，不新增后台阶段或接口请求。

AgentBus 回放视图与 Trace 工作区两个聚焦测试文件共 11/11 通过，vue-tsc --noEmit 通过。修改后本地 5178/8082 均未监听，未擅自恢复运行配置，因此尚未在重启后的真实页面做只读复查。未修改后端、API、数据库、Agent、业务流程、 轮询频率或既有回放记录，也未重新执行 EML。

2026-08-19 Booking Agent Skill V2 RC2 单次判断与输出纪律

本轮只收口 Booking Agent 自身的判断和输出过程，原有按业务需要渐进读取 Skill 规则的方式不变。QBD 正文 ตัด Allotment <code> 被固定为正文来源的整块取消，形成后不再匹配 actual 订单编号或重新讨论扣减；普通订单决定只引用自己的 unit_ref，正文整块取消只引用 body_ref，决定编号按形成顺序固定为 D1、D2……。每个 unit_ref 的房量只汇总一次，判断完成即冻结。

覆盖全部输入后，Agent 只做一次 Schema 字段检查并立即返回裸 JSON；除 Skill 明确要求的必要规则读取外，不再使用其他工具、文件、命令、 待办或二次业务复核。未修改输入输出 Schema、业务枚举、Layer 3–6、数据库、五分钟计时、运行配置或前端。

新版 17 成员 HOLD/INTERNAL_ONLY 离线包位于 artifacts/booking-agent-skill-v2-rc2/booking-agent-skill-v2.skill，SHA-256 为 0fd0df86fc0bbec9587fb3ff370cdea902925f77c4ed10f094309a02086c40ab；Main Prompt SHA-256 为 849b06beb56e6e57ab2dc6c6295a56a4cbc93859490f92d5885e84f9c8ee840b。项目专用源/归档校验、确定性打包检查和既有专用测试 8/8 通过。 通用 quick validator 因本机没有 PyYAML 未执行，未为此增加依赖；未调用真实 SuperAgent 或运行真实 EML，实际耗时和系统接收仍待发布后复测。

2026-08-19 AgentBus EML 回放当前运行层级展示

本轮保留上一轮真实/兼容模式与“全流程成功/失败”状态规则，只在 Trace 工作区增加当前阶段展示。全流程未终止时，页面从已有 trace.stages 找到第一个 RUNNING 阶段：左侧该阶段继续使用既有转圈图标并增加当前标识，顶部显示“正在处理：Layer X · 阶段名称”。 若 trace 尚未终止但暂时没有 RUNNING 阶段，顶部显示“正在等待下一阶段”，不猜测具体层级；trace.terminal=true 后该提示与当前转圈停止， 上一轮全流程成功/失败结果保留。现有 refresh_after_ms 两秒轮询未改，仍持续到终态。

前端聚焦文件 agentBusReplayTraceWorkspace.spec.ts 共 5 项通过，覆盖 RUNNING 阶段提示、左侧 spinner/current 标识、两秒后无 RUNNING 的等待兜底， 以及仅刷新选中阶段详情。本轮未上传/执行 EML、未调用 SuperAgent、未修改后端、Agent、业务层、数据库、接口或运行配置，未运行全量测试。

2026-08-19 AgentBus EML 回放状态语义收口

本轮只修改 AgentBus EML 回放相关前端展示与导航。侧边栏及本地开发菜单默认携带 entry=email-import，因此正式入口明确为真实 Parsing Agent → Booking Agent 全流程；旧兼容路径仍可通过不带该 query 的兼容入口访问。页面依据已有 execution_policy、回放下游 状态与 trace 终态区分“真实 Agent 全流程”和“旧兼容流程”。真实流程显示“全流程处理中/成功/失败”，不再把回放登记的 COMPLETED 误当成全流程成功；旧兼容流程终态固定显示“兼容流程已结束”，并提示不会运行 Parsing Agent 和 Booking Agent。

新增一个前端聚焦回归验证真实与兼容流程不混淆；AgentBus 回放视图与本地导航相关测试共 39 项通过。vue-tsc --noEmit 仍被工作区 既有 agentBusReplayTraceWorkspace.spec.ts 第190行的 mock 类型错误阻断，本轮未修改该无关测试。未上传/执行 EML、未调用 SuperAgent、 未修改后端、Agent、业务层、数据库或运行配置。

2026-08-19 Trace 解析器新版后端已加载

在聚焦解析器测试通过后，仅重启本地 8082 后端，使新版 SuperAgentOpenApiSseParser 从 server/target/classes 生效。重启复用了现有 local,local-replay 非生产运行配置，配置值只在进程内存中复用， 没有写入代码、YAML、日志或项目文档；5178 前端和其他服务未重启。

重载后 8082 /api/health 返回 UP；现有 5178 代理能力返回 strict_execution_ready=true、 execution_ready=true、missing_configuration=[]、postgres_ready=true。本次没有上传 EML、创建/执行回放、 调用 SuperAgent 或修改数据库。

2026-08-19 SuperAgent Trace 完整 Agent 答案恢复已完成

本轮只修复 SuperAgentOpenApiSseParser 的结果接收。嵌套 Trace 的 message.delta 现在按同一 run_id 和 message_id 分组，组内按到达顺序拼接；既有 SSE event ID 去重仍在消费入口执行。message.final 只用于定位唯一 兼容回答：两者相等，或一方是另一方前缀时才接受；匹配不唯一、内容冲突或缺少最终回答时保持失败关闭，不按长度 猜测、不修补 JSON。已知 __user 消息不会作为 Agent 答案候选，标题也必须通过唯一内容匹配才能被接受。

新增一个真实形态聚焦回归，覆盖用户消息、短标题、完整 assistant 分段、重复 event ID 和 2,000 字符 message.final 前缀；SuperAgentOpenApiSseParserTest 共 18 项通过，0 failures/errors/skipped。结果仍要求 run.completed=success 与 end，随后沿用既有 JSON/契约校验。本轮未调用真实 SuperAgent、未运行真实 EML 或全量测试， 未修改 Agent、Layer 3–6、数据库、超时、Journal、页面或运行配置。

2026-08-19 Parsing Agent批准版本已对齐最新真实发布

用户确认实际运行version 0e9c63ba-be3b-451d-8a2e-5488975651ad为当前应批准的Parsing Agent版本。本地回放后端在 无活动Processing回放时只替换TH_HOTEL_BOOKING_PARSING_AGENT_EXPECTED_PROFILE_VERSION_ID并重启；未修改代码、 Agent资产、数据库、Booking RC6、超时规则或历史回放。唯一PREVIEW_READY回放保持未执行。

重启继续使用local,local-replay，H2 V34与PostgreSQL schema V16均无需迁移。8082健康为UP；5178代理能力显示新Parsing version、Booking RC6、PostgreSQL、双Agent、V2 authority和strict execution全部ready，missing_configuration=[]，当前 Processing回放为0。该检查只证明版本门禁和运行环境已就绪；Trace模式2,000字符final截断仍未修复，因此尚不能开始真实全链验收。

2026-08-19 AgentBus EML 回放调试页 Layer 5 证据投影已收口

本轮只调整现有 trace 读取和调试页面展示。Layer 5 详情现在优先使用版本化阶段快照中实际发送给 Booking Agent 的 compact input；阶段输入为空时才使用 invocation audit 的 controlled_input 兼容兜底。 生命周期完整日志导出复用同一 stageDetail 读取结果，因此输入优先级同步修正，未新增接口、数据库结构或业务阶段。

页面将 Layer 5 显示为“Layer 5 · Booking 判断与任务组装”，输入/输出分别标注为实际发送的精简输入和信息系统组装后的完整任务；概览只依据现有阶段状态与输出显示“Booking Agent 业务判断”和“信息系统组装完整任务”进度。 当前选中阶段为 RUNNING 时，页面沿用现有 2 秒 trace 索引刷新并强制刷新该选中阶段详情，同时用阶段既有开始时间显示已运行时间；未选中的阶段不请求详情。

后端 AgentBusEmlReplayTraceServiceImplTest 聚焦测试通过；前端 agentBusReplayTraceWorkspace.spec.ts 聚焦场景 5/5 通过，覆盖 Layer 5 文案、运行时间、2 秒后仅刷新选中阶段。未运行全量测试、未上传/执行 EML、未调用 SuperAgent；用户正在观测的服务和 replay 未操作。

2026-08-18 最新真实回放：Parsing版本/完整答案双门禁，Booking单次运行总超时

真实回放 2089731971217022977 已终态失败。EML、AgentBus接收、Layer 1/2及Layer 4均完成；Layer 6因Layer 5没有候选结果而按规则阻断， 不是独立校验失败。Source Capture的warning仅表示已成功异步排队，Deterministic Parser显示PENDING及双Agent终态显示0ms属于生命周期 投影不准确，实际Parser有114条事实并继续参与下游。

Parsing Agent只有一次worker领取、一个session和一个run。Provider实际返回了符合最新QBD规则的完整5,664字符JSON，包括LTQ260812来源目标、 九条Allotment关系、四条待人工确认材料处置，不含价格补写或固定OP文案。但实际发布version 0e9c63ba-be3b-451d-8a2e-5488975651ad与信息系统仍批准的V12 95d2834a-7ddb-4ea7-85b0-35ca6e986c57不一致， 所以整份Agent贡献被丢弃，Layer 3仅保留Parser事实进入Layer 4。

此外，Provider公开message.final把完整回答截为2,000字符；信息系统response SHA与这段残缺文本完全一致。当前Trace解析器把不同 message_id的user/title/assistant delta混在一起，现有完整答案回收只覆盖另一种顶层SSE形态，因此即使先放行新version，Parsing仍可能紧接着 因JSON不完整失败。后续最小改动应只对Trace模式按message分组，并在final是完整assistant delta前缀时保留完整assistant回答。

Booking Agent已收到9,673字符compact输入，证明“Agent只判断、系统本地组装”已经接线，旧145KB/682行输入不是本次原因。它只创建一次 session/run，未重复派单；在五分钟整项预算内没有产生任何assistant内容、工具调用或final，系统以 BOOKING_AGENT_PROVIDER_TOTAL_TIMEOUT结束，Layer 5B组装未启动。要解释Provider为何停住，仍需对应run e75aa917-b583-42be-ac12-05243f947227的SuperAgent导出；当前系统日志只能证明超时时它仍在running。

2026-08-18 原回放确认按钮已恢复；严格真实运行时已通过门禁

原回放 2089731971217022977 之前无法点击“检查并确认回放”，根因是当时安全 H2 基线缺少真实 PG、双 Agent worker 和 V2 authority， 前端按 email-import 的 fail-closed 规则将 strict_execution_ready=false 显示为“环境未就绪”。未修改按钮门禁，也未绕过它。

已在当前进程内恢复用户提供的非生产运行材料：PostgreSQL 使用非 SSL 连接，schema 16 已通过 Flyway 且无需迁移；Parsing Profile 为 V12， Booking Profile 为 RC6；5178 capabilities 返回 strict_execution_ready=true、execution_ready=true、missing_configuration=[]。 原回放仍为 PREVIEW_READY，没有 SourceMessage 或 Processing Run；刷新后当前按钮实测可点击，但本轮没有点击确认或继续执行。

恢复期间列表另出现回放 2089733407116083201，状态为 PROCESSING，已有自己的 SourceMessage/Processing Run。用户已确认该记录 是自己点击确认执行后产生的，不是系统误建；当前不对它重复派单或重复操作。

2026-08-18 AgentBus回放页面无法打开：5178/8082运行时退出后已恢复安全基线

现场只读检查发现 5178 与 8082 均无监听，因此浏览器显示“无法访问此站点”；不是 EML 或回放数据问题。首次在受限环境启动时，Vite 监听 127.0.0.1:5178 被本机权限拒绝；随后使用回放启动脚本的安全本地基线重新启动，统一使用 HOTEL-LOCAL-REPLAY 身份，未注入或 写入任何 Secret，也未上传 EML、创建或执行 replay。

当前 5178/ 返回 HTTP 200，8082/api/health 返回 UP，5178 的 capabilities 代理返回 HTTP 200。由于本次终端没有获准的真实 PostgreSQL/Parsing/Booking 运行配置，capabilities 明确保持 fail-closed：postgres_ready=false、双 Agent/V2/strict 为 false，缺项为 BOOKING_POSTGRES、PARSING_AGENT_PROFILE_PROVIDER_WORKER、PARSING_AGENT_PROFILE_PROVIDER、BOOKING_V2_AUTHORITY。 所以页面可访问，但不能把这个安全基线当作真实 EML 测试环境；用户刷新当前 5178 页面即可看到实际状态。

2026-08-18 Booking Agent Skill V2精简决定与Layer 5B组装已本地完成

Booking Agent现在只接收按物理来源单元整理的compact材料，并只返回业务类型、目标、Booking Type、语义事项、 Allotment、Risk和未归类原文。信息系统在Layer 5B从同一canonical Layer3/4输入复制日期、房型、房量、来源价格、 对应Rate/早餐和证据，生成现有完整Candidate；9个订单不再要求Agent机械拼装数百行技术JSON。

内部BookingDecisionInputV2、CandidateDecisionV2、Layer6、数据库、五分钟same-run等待、journal、页面和工作台 投影均未改变。9个Update＋LTQ260812整块取消的聚焦链路通过；Rate未解析仍由Layer6标记人工复核。Booking Skill 专用校验、8项打包测试及确定性package check通过，17成员HOLD包SHA为b83cd597…172ff。

当前只完成仓库代码与Booking Agent Skill V2离线包。尚未发布SuperAgent，也没有运行真实EML；实际耗时、裸JSON、 Layer5B和Layer6结果必须在用户完成平台发布后用新回放验收。

2026-08-18 Booking Agent RC7规则行为通过，但耗时与交付格式仍不合格

旧手工导出证明 Booking Agent 在约145KB的旧Layer3 PARTIAL/INVALID_PROVIDER_RESULT 输入上长期反复判断，至导出时仍没有 Candidate。业务结果应为9个独立UPDATE_BOOKING加1个ALLOTMENT_SOURCE_WHOLE_CANCEL；Rate/早餐未解析只属于第二道门槛。

本轮只修改 Booking Agent 可发布资产：QBD固定OP提示、问候、签名、联系人和公司资料先于通用未归类原文收集被排除；Allotment 整块取消的source code不与actual团号匹配，并可与物理行Update同时存在；Update第一道门槛成立后，不因Rate/Breakfast缺口重新判断 类型或目标。独立Main Prompt只增加一条优先级/停止条件，仍为5行；业务版本、输入输出Schema、原因枚举和Layer6均未改变。

新离线资产为booking-desk-event-v1.0-rc7，24 members，SHA-256 147141f420303a48c022a9d07469103a74c64c315404872b2fcb069a0553fd20，状态保持HOLD/INTERNAL_ONLY。场景矩阵由46增至49， 新增3个纯合成组合场景；专用测试8/8与确定性--check通过。RC6没有覆盖。

用户随后提供Wyndham Jomtien Booking Data (2).md。20:44:19输入、20:57:56返回，耗时13分36秒；21个工具调用总计仅18.524秒， 其余时间主要是Agent反复重判、重组和自检。最终业务形态为9条独立Update＋1条LTQ260812整块取消，Rate/早餐各进第二门槛issue， 固定模板不输出，证明RC7三条业务规则已实际加载并执行。但Agent在已得出答案后仍写文件、运行Bash、读回并present，最终又使用Markdown JSON围栏；严格decoder会在Layer6前直接拒绝该raw answer。

这次手工输入仍是145473字符的旧PARTIAL/INVALID_PROVIDER_RESULT交接：154条evidence、114条facts、9个order contexts， 且没有LTQ260812的Layer3 source GROUP_CODE。所以即使去掉围栏，整块取消也会因source provenance缺失被严格decoder拒绝；它仍不能 替代最新Parsing Agent Skill V2交接验收。当前问题已从“业务规则歧义”收敛为“单次执行纪律、裸JSON交付和测试输入过旧”。本轮只诊断， 未修改Agent资产、信息系统、数据库、五分钟机制、Layer3/4/6、页面或生产配置。

2026-08-18 Parsing Agent Skill V2 手工真实输入行为验收通过；AgentBus接收仍待验证

用户提供 SuperAgent 导出 QBD Channel Parsing Agent (3).md。同一真实 compact Parsing 输入包含9个Current附件目标、 4个 WAITING 等待确认/USER_REMARK 的 2300 THB material，以及正文 ตัด Allotment LTQ260812。最终答案为裸JSON， 没有Markdown围栏；输出一个LTQ260812来源目标和 CANCEL_BOOKING 来源动作，分别关联T1–T9共9个actual，不建立target binding， 也不产生code错配复核。M1–M4均为 REVIEW_REQUIRED、空 output_refs 和 MATERIAL_PARTIALLY_RESOLVED，没有 SOURCE_PRICE；泰文OP提示、联系人、公司与签名内容没有进入输出。

运行时compact输入、result closed Schema、禁止业务字段及输入引用闭包离线复核通过。日志未直接打印“Skill V2”版本标签， 但逐字出现并执行V2新增硬规则，构成新版规则已加载的强行为证据。可见时间从输入到导出约3分20秒，其中Skill/规则读取约16秒， 主要剩余耗时来自反复判断review拆分和问候/标题是否展示；低于10分钟上限，但尚可后续单独优化Prompt收敛性。

该文件只证明SuperAgent手工真实输入的Parsing行为，不含信息系统接收结果、Layer3终态或Layer4–6生命周期，因此不能据此宣称 真实EML全链已通过。下一步仍是用V2运行真实EML并提供AgentBus lifecycle日志。

2026-08-18 Parsing Agent Skill V2 QBD规则修正与离线发布包

本轮只修正 Parsing Agent 资产：QBD WAITING 等待确认 下的 USER_REMARK 金额（如 2300 THB）不得升级为 SOURCE_PRICE，必须以既有 MATERIAL_PARTIALLY_RESOLVED 交人工确认；正文 ตัด Allotment <code> 固定按 CUT_SOURCE 处理，来源目标分别关联所有 Current 附件 actual，不按订单 code 精确匹配，也不因此产生找不到目标/关系未解析；固定泰文 OP 提示、 姓名/职位/联系方式/公司资料和签名页脚全部过滤。以上硬规则优先于通用 Tour Code 绑定/展示/复核，命中后不再重复解释。

输出同时收紧为裸 JSON：首字符必须为 {、末字符必须为 }，不允许 Markdown 围栏或前后解释。新发布资产统一命名为 Parsing Agent Skill V2；输入/输出接口仍为 v1.0，不新增枚举或 Schema，也未修改信息系统、超时、数据库、Layer 4–6、 Booking Agent、页面、生产开关或 PMS/Opera。

可交付包为 artifacts/parsing-agent-skill-v2/parsing-agent-skill-v2.skill，9个运行成员，SHA-256 fb08c12af019f7fd94c74f39d83f0500b8898aaf64ff2a49f56b3e53c21d3997，状态仍为 HOLD/INTERNAL_ONLY。独立中文 Main Prompt 不进入包；本轮同步后的 SHA-256 为 89fc3b5e8052431022920265520faace3b1a5609f8cac7a54afab1101ae52a94。 37项合成场景、25项聚焦测试、source/archive校验和确定性 --check 均通过。没有调用或发布 SuperAgent，也没有运行真实 EML； 真实业务结果和耗时必须在用户将 V2 与独立 Prompt 发布到平台后，用同一份真实 Parsing 输入复跑验收。

2026-08-18 AgentBus真实EML唯一入口收口为5178→8082

本轮再次复现页面 UNKNOWN / 环境未就绪：浏览器打开的5174前端没有配置 API proxy，访问回放能力接口时返回 Vite HTML，页面因此拿不到环境状态。 真实 EML 测试正式入口收口为 5178 → 8082；共享前端 client/vite.config.ts 保持原有“只有显式 VITE_API_PROXY_TARGET 才代理”的行为， 不让普通前端默认永久连接8082，也不把5174建设为第二个回放入口。

scripts/start-local-replay.sh 的回放默认端口对齐8082/5178，并保留两项启动门禁：8082 /api/health 必须正常；5178必须通过自身 /api/system/debug/agentbus-eml-replays/capabilities 取得后端真实环境 JSON，否则直接报告端口占用或代理连接失败，不输出就绪。 酒店上下文默认保持 HOTEL-LOCAL-REPLAY，仍可由显式运行变量覆盖。

只读复验：8082健康接口HTTP 200；5178健康接口HTTP 200；5178能力接口返回 postgres_ready=true、Parsing V12、Booking RC6、 v2_authority_ready=true、strict_execution_ready=true、missing_configuration=[]。内置浏览器已切换到 http://127.0.0.1:5178/debug/agentbus-eml-replay?entry=email-import，页面显示“后端已连接/可执行回放”，EML文件选择控件已启用。 本轮未上传EML、未创建或执行回放，未修改Agent、数据库、业务流程、其他页面或生产配置。

2026-08-18 Booking 五分钟累计等待产品口径已实现，现有 replay 待终态复核

本轮产品规则已取代下方旧的 120 秒软窗口/15 分钟总上限口径：Booking execution 从创建时间累计等待最多 5 分钟，期间只继续接收 原 Provider run 的结果；不再在 2 分钟触发状态或业务动作。worker heartbeat 使用独立的短 lease 与 15 秒续租，不依赖旧等待阈值。 5 分钟内取得有效 Candidate 立即继续；超时不重派，写入 BOOKING_AGENT_PROVIDER_TOTAL_TIMEOUT、失败大类 TERMINAL_PROVIDER，沿现有人工复核路径关单，Layer 6 未改。

代码已移除 Booking max-wait 绑定及 soft-window 分支，保留 V15 execution session/run checkpoint、resume 和 V16 约束扩展。 BookingAgentDurableWorkerTest、BookingAgentPropertiesTest、BookingAgentV2DurableMigrationTest 及相关 Booking 适配器/协调器/终态 测试通过，mvn -DskipTests compile 通过。非生产 PostgreSQL 已由 Flyway 应用 V16；现有 replay 2089587291521495041 在一次短周期观察中 正常关单，不创建新 replay、不重放其他记录。

该 replay 的 execution 创建于 13:45:54，本轮启动时已超过新的 5 分钟累计窗口，因此只验证“过期 execution 立即按总上限关单”，不把它冒充为 新鲜 5 分钟等待实测。终态为 Booking execution/Processing Run FAILED、RISK_NOTIFICATION，保存 BOOKING_AGENT_PROVIDER_TOTAL_TIMEOUT；5 秒后二次快照仍为 attempt 6，无新增 Provider journal。

2026-08-18 Booking execution-owned Provider continuation收口

历史收口快照：其中的 120 秒/15 分钟仅记录本轮修复前事实，已由上面的五分钟产品口径替代。

Booking execution 已成为运行态 Provider session/run 的唯一权威；V13 response journal 仅保留审计/证据。首次派单在当前 lease/fence 下 checkpoint，后续 attempt、worker 重领和进程恢复只 resume 原 run；120 秒为软等待窗口，15 分钟总上限从 execution created_at 计算。V15 增加两个 execution checkpoint 字段；V16 只扩展既有 invocation audit failure-class 约束以允许 TERMINAL_PROVIDER，不新增表/字段。

真实新 replay 2089587291521495041 的测试 PG 时间线证明 checkpoint 已保存，attempt 1→2 共用一个 distinct provider session/run，没有第二个 provider run。15 分钟总上限也在 execution.created_at + 15m 准时触发；最初未形成终态是因为 V11 约束拒绝 TERMINAL_PROVIDER，导致审计写入失败和后续 lease-expired reclaims。已停止继续轮询；V16 后只运行聚焦 worker/migration 测试与 Maven compile，均通过；按用户边界未重启服务、未重放 replay，因此 V16 后真实终态仍待后续一次明确授权的 新测试。未修改 Parsing、Layer 3/4、Candidate、Layer 6、UI、Prompt/Skill、生产开关或 PMS/Opera。

2026-08-18 真实 EML 测试运行时已恢复；Parsing key 已替换，等待新回放

用户提供的非生产 PostgreSQL 与两套 Agent 专用 Secret 仅注入当前 8082 进程内存，未写入代码、YAML、日志或项目文档。8082/5178 已恢复，PostgreSQL 连接成功，Flyway 确认 Booking schema V14；运行时门禁返回 postgres_ready=true、Parsing V12、Booking RC6、 v2_authority_ready=true、strict_execution_ready=true、missing_configuration=[]，下游模式为 BOOKING_DECISION_V2。

对测试 PostgreSQL 的只读状态聚合只发现历史终态（Parsing FAILED/REVIEW_REQUIRED、Booking FAILED/REVIEW_REQUIRED/SUCCEEDED、 Processing Run FAILED/VALIDATED、projection SUCCEEDED），没有 READY、CLAIMED、RETRY 等活动状态。旧回放 2089557784945102850 已保持 FAILED/FRESH_DELIVERY，其失败证据已单独记录；不会因为替换 key 自动重放。

用户随后提供新的 Parsing 专用 key。队列清空后仅以内存替换当前 8082 测试进程并重启；未写入 Secret、代码、YAML、数据库或文档。 PostgreSQL 15.14 / schema V14、Parsing V12、Booking RC6、V2 AUTHORITATIVE、projection 与 strict gate 均复验通过， capabilities 返回 missing_configuration=[]、execution_ready=true。这一步只证明新值已加载并通过本地非空配置门禁，尚未发送新的 EML 或 Provider message。

重启期间浏览器旧页面曾保留 UNKNOWN / AgentBus EML 回放请求失败，刷新后已恢复为“后端已连接”；点击“新建回放”后，EML 选择入口 已启用，运行环境显示功能开关、OSS、Capture、V2、PostgreSQL、Layer 3/5 Agent 全部就绪。旧失败回放不会自动复用或重放。

为避免新建 email-import 回放再次提交错误身份，前端已将该入口初始 deliveryMode 固定为 FRESH_DELIVERY，并新增 focused 回归测试；Vitest 4/4、vue-tsc --noEmit 通过。

2026-08-18 AgentBus回放启动端口传播已修复；安全本地基线与真实运行配置分开

本次现场复现回放页 UNKNOWN / AgentBus EML 回放请求失败：5178 和 8082 没有监听，5174 页面显示后端未连接。根因是 scripts/start-local-replay.sh 用 SERVER_PORT 轮询健康检查，却没有把该变量导出给 Spring Boot 子进程；Spring local profile 因此可能仍绑定默认 8080，脚本超时后清理前后端。现已修复脚本，规范化并导出同一个 SERVER_PORT。

用显式 8082/5178、HOTEL-LOCAL-REPLAY 和安全本地 H2 配置重启后，Spring/Tomcat 绑定 8082、Vite 绑定 5178，健康检查通过； 浏览器回放页显示“后端已连接”，功能开关、本地存储、AgentBus Capture 就绪，上传区域可用，UNKNOWN 消失。该次启动没有上传 EML、创建 replay 或调用外部 Agent。

本次 Codex shell 没有获准的测试 PostgreSQL URL/账号/密码或 Parsing/Booking Open API key，因此页面仍 fail-closed 地显示 BOOKING_POSTGRES、PARSING_AGENT_PROFILE_PROVIDER_WORKER、BOOKING_AGENT_PROFILE_PROVIDER、BOOKING_V2_AUTHORITY 缺失。该安全 H2 基线不等于用户此前准备好的 PG/V12/RC6/strict 全链；真实测试前仍需在启动环境重新注入原批准配置并完成 postflight。

2026-08-18 Layer 3混合Worker已隔离，V14归属审计与内部黄金路径已完成

在活动队列均为0后，连接同一测试PostgreSQL的旧8081服务已安全停止；8080连接另一数据库且保持不动。当前只由8082承担 本地回放的Parsing与Booking任务。8082已恢复HOTEL-LOCAL-REPLAY、Parsing V12、Booking RC6、V2权威模式和工作台投影； Field Recovery与Parsing是互斥的旧/新Layer 3写入方式，因此旧Field Recovery保持关闭。capabilities为HTTP 200， PostgreSQL、双Agent、V2与strict execution均ready，missing_configuration=[]，活动队列为0。

PostgreSQL已新增V14不可变Parsing attempt归属审计：每次领取都保存attempt、fencing token、领取时间、worker实例和build身份， 终态清空租约后仍可追溯；旧格式worker也会被标为legacy/unknown。Lifecycle V2把该信息作为信息系统执行证据展示，不混入或改写 SuperAgent原始公开事件。Deterministic Parser阶段现同时识别内部Parser artifact和已提交的公共Parser artifact，后续Parsing失败 也不会再把已完成Parser误显示为等待。

真实测试PostgreSQL的受控Layer 3黄金路径已通过：真实durable claim、V14归属审计、请求/响应校验、Parser权威保护、逐项验收、 Layer 3合并、三类artifact和SUCCEEDED终态全部走通；Provider为进程内受控替身，合成数据已清理。该结果只证明Layer 3内部持久化 链路，不代表真实SuperAgent、Layer 4–6或完整邮件全链成功。历史replay 2089527434727292929在当前恢复的回放存储中已不存在， 无法用旧页面补做运行态展示验收；下一步由用户新建回放并上传一封真实EML完成实证。测试PostgreSQL曾出现远端关闭空闲连接， 本轮只确认启动与短时读写正常，没有宣称该独立波动已根治。

2026-08-18 SourceMessage后续PostgreSQL交接恢复已实现并加载本地测试环境

Replay 2089514749458608130的EML读取、附件处理和SourceMessage写入实际已完成；失败发生在准备创建Booking Processing Run时， 测试PostgreSQL连接池连续取到已被远端关闭的空闲连接。旧实现把SourceMessage登记和后续Booking交接包在同一个失败结果里， 所以页面只保存CAPTURE_FAILED，丢失了已登记的SourceMessage编号，也无法区分“邮件没收到”和“邮件收到但后续数据库暂不可用”。

当前Booking专用连接池启用10分钟连接寿命、2分钟保活和3秒有效性检查。SourceMessage成功后，只有“尚未取得PostgreSQL 事务连接”这一类安全失败会再交接一次；业务异常、事务内异常和结果不确定的异常不会重放。第二次仍失败时，结果保留 SourceMessage编号、登记状态、是否新建及交接次数，并明确记录BOOKING_POSTGRES_CONNECTION_FAILED；Source阶段显示已登记但 后续警告，不再误报整封邮件捕获失败。现有Processing Run的来源身份与幂等防重继续生效，没有新增队列、migration或业务规则。

AgentBus processor、PG连接配置、replay trace和controller共29项聚焦测试通过，后端package和前端typecheck通过。刷新前后 Parsing、Booking、projection、processing和活动replay均为0；8082已恢复原H2回放库、HOTEL-LOCAL-REPLAY、测试PG、 Parsing V12、Booking RC6和strict配置。8082/5178均HTTP 200、missing_configuration=[]，PG V13/H2 V34无需迁移。 旧失败replay不会被改写或自动重放；新逻辑仍需下一次新建回放实证，不能把合成回归当作真实全链成功。

2026-08-18 Parsing Agent失败站点诊断已实现并加载本地测试环境

最新replay 2089398649013129217在约35.2秒终态FAILED。EML、SourceMessage、Layer 1/2和确定性Parser已成功； Parser artifact包含114 facts/4 materials，完整request可离线重建且compact handoff约27.7KB。Parsing execution fcpa-exec-8cc71a97d89bff3b98f9510d7f44d4bb没有provider session/run或V13 journal，Booking未运行。旧实现只保存 PARSING_AGENT_HANDLER_INVARIANT / IllegalStateException，因此只能把故障收窄到请求准备完成后、Provider公开响应前， 不能继续判断是派单、创建session、checkpoint还是journal保存失败。

当前worker会在内存中记录一次attempt最后进入的稳定站点，包括材料重建、身份核对、request preflight、compact handoff、 Provider派单/session创建/run续接、session/run checkpoint、公开响应journal、final解码/验收、Layer3 merge与结果组装。 正常运行不增加数据库写入；只有未预期异常终止时，才把失败站点、进入时间、外层/根因类型和经凭据脱敏的具体说明写入 既有safe_error_summary（上限512字符）。既有顶层错误代码、fail-closed、重试/同run续接、V13原始Provider journal、 Agent输入输出契约和Layer3–6业务行为均未修改。

生命周期读取现已取回safe_error_summary，在Parsing阶段issues[]中输出failure_step、时间、异常类型、根因类型和 message；复制与导出继续使用同一Lifecycle V2 JSON。旧记录仍会显示原IllegalStateException，但无法事后补造当时未保存的 失败站点。worker/handler/pipeline/SuperAgent adapter/lifecycle等7类58项聚焦测试全部通过，main compile通过。 队列只读确认Parsing、Booking、projection非终态及过期Parsing claim均为0后，8082已保留V12、RC6、测试PG、 HOTEL-LOCAL-REPLAY和strict配置完成刷新；8082/5178 capabilities均HTTP 200且配置缺项为0。尚未创建新replay， 所以新的真实故障站点或全链成功仍须下一封EML验证。

2026-08-18 Parsing session-only checkpoint已修复并加载本地测试环境

Replay 2089390064358281217曾在Parsing Agent取得SuperAgent session、保存任务单号时失败；EML、SourceMessage、 Layer 1/2和确定性Parser均成功，但没有provider run、公开事件、final或Booking attempt。根因是首个checkpoint的runId 按正常时序暂时为空，而PostgreSQL无法为原SQL中的独立null占位符推断类型，并非Agent推理慢或4分钟等待问题。

当前已将nullable run guard显式声明为VARCHAR，并新增runId=null的session-only repository回归。repository、worker、 handler、Layer3 continuation和SuperAgent adapter共42项通过；Maven按Java 17 release完成主代码编译。真实测试 PostgreSQL read-only连接已为完整UPDATE成功生成执行计划，覆盖原SQLSTATE 42P18边界且不写任务数据。

刷新前后Parsing、Booking、projection、过期claim和活动processing run均为0。8082已加载修复，H2 V34/PG V13无需 迁移；8082/5178、HOTEL-LOCAL-REPLAY、Parsing V12、Booking RC6、V2/strict全部ready且配置缺项为0。旧replay保持 失败终态，没有自动重放。现在可复用同一EML新建回放，继续验证唯一Provider run、4分钟软等待、完整final和Layer3–6； 本次未改Agent Skill/契约、数据库结构、等待策略、业务规则、页面、production或PMS/Opera。

2026-08-18 Parsing Agent同一任务续接已本地完成，环境已可新建回放

信息系统已把Parsing Agent的4分钟处理期限从“到点取消并重新派单”改为“到点提示Agent仍在处理并继续等待”。 一封邮件首次派单后，SuperAgent分配的session和run会立即写入现有任务记录；连接中断或本地worker重启时，系统按这组 任务单号继续读取原run的公开事件和最终答案，不再向同一thread重发邮件。默认总等待上限为15分钟；只有Provider明确 失败/取消、总等待超限或原run身份无法安全确认时，才形成可解释的Parser-only人工复核。

等待期间worker持续续租，stale worker不能提交第二份结果。4分钟后页面将活动Parsing execution显示为RUNNING / PARSING_AGENT_STILL_PROCESSING；续接收到的公开事件、恢复响应和final仍按原顺序、原内容进入V13 lifecycle journal， 且必须满足完整final、成功run completion和end三项门槛。run状态接口中可能截断的final摘要不能冒充完整答案。没有新增 数据库migration，也没有修改Parser、Parsing Agent输入/输出契约、Prompt/Skill、Layer3–6业务规则、production开关或 PMS/Opera。

transport/adapter/repository/handler 66项、配置/worker/pipeline/CP4相邻37项、lifecycle 9项，共109项测试全部通过， main compile与task范围diff check通过。本地8082已加载用户确认的Parsing V12门禁，Booking保持RC6；8082直连和5178 代理均为HTTP 200，H2 V34、测试PostgreSQL V13、双Agent、V2 authority、strict execution全部ready且配置缺项为0。 Parsing、Booking、projection非终态队列、过期Parsing claim和活动processing run均为0；旧失败replay保持原终态，未重放。 启动后连接池仍三次发现测试PostgreSQL的空闲连接已被远端关闭并自动替换；告警后8082/5178 capabilities继续HTTP 200， 独立psql即时读取成功且五项队列仍为0。因此当前可测试，但远端连接波动仍是独立稳定性风险，不属于本次Parsing续接修改。

本次服务刷新第一次仍遗漏了AUTH_BOOTSTRAP_DEFAULT_HOTEL_ID，只读postflight立即发现本地身份回退并在交还用户前恢复为 HOTEL-LOCAL-REPLAY；没有任务或数据受影响。这是同类重启错误第二次出现，已升级reflection/skill candidate。当前可以由 用户新建回放并上传真实EML验证，但尚未产生新V12真实运行证据，所以不能宣称单run晚到final或Layer3–6已经实证成功。

2026-08-17 Parsing Agent V12 门禁已注入本地测试服务

用户确认最新 Parsing Agent 为 V12，并提供平台内部 version ID 95d2834a-7ddb-4ea7-85b0-35ca6e986c57。本次不再执行平台身份探针，也不重新发布 Agent；启动前只读确认 Parsing、Booking、正式工作台投影三条 durable 队列的非终态与过期 claim 均为 0，活动 processing run 也为 0。

8082 已保留原 local,local-replay、HOTEL-LOCAL-REPLAY、测试 PostgreSQL、两个独立 Agent Key、Booking RC6、 V2 authority 和公开 Trace 配置，仅把 Parsing expected version 从 V10 对齐到 V12 后重启。H2 仍为 V34， PostgreSQL 为 V13；8082 直连与 5178 代理一致显示 Parsing V12、Booking RC6、PostgreSQL、双 Agent、V2 authority、 strict execution 全部 ready，missing_configuration=[]。重启后三条 durable 队列、过期 claim 和活动 processing run 仍全部为 0。

这一步只证明本地信息系统已经按用户提供的 V12 身份完成配置门禁并可接收新测试；没有上传、执行或重放 EML， 没有向 SuperAgent 发送 message，也没有验证 V12 实际 resolved 身份、工具读取次数、耗时、公开 final 或 Layer 3–6 真实结果。Secret 只保留在当前测试进程内存，没有写入代码、YAML、数据库、日志或项目文档；production 与 PMS/Opera 均未触碰。

2026-08-17 Parsing Agent运行材料精简离线 checkpoint（后续已发布为V12）

fixed-channel Parsing Agent 的可编辑源仍完整保留双渠道合成fixture、33项scenario matrix、独立Main Prompt、 内部source manifest及四份输入/Parser/输出Schema，继续用于发布前的source、业务语义和契约校验；这些离线资料不再 进入每封邮件可见的运行.skill包。运行包现在只保留SKILL.md、平台metadata、六份直接业务reference和唯一输出 Schema，并在Skill内明确禁止目录glob/搜索，只按Profile读取对应渠道规则后立即处理compact input。

归档由16 members / 72615 uncompressed bytes降至9 members / 26267 bytes，减少7个文件和63.8%的可见材料；删除的是 3份fixture、内部manifest、Parser schema、canonical input schema和compact input schema，业务规则、Current/History、 Parser facts/materials、evidence关联、输出契约和Validator边界均未修改。新离线包SHA-256为 fcce35d541158a9276e8c32949179a8cfa7044f60ead4bc409ed5d18f8c7003c。

source/archive严格validator、24项package/双渠道/语义测试及确定性--check均通过；Skill Creator通用 quick_validate.py因当前两套Python均无PyYAML无法启动，未安装依赖或借用其他任务shim，现有项目validator已独立执行 更严格的frontmatter、成员、Schema、fixture、语义和archive检查。本次未发布SuperAgent、未重启8082、未运行EML， 也未修改信息系统runtime、4分钟deadline、active-run续接、数据库、业务规则、production、页面或PMS/Opera。

2026-08-17 Booking Agent替换Key与RC6门禁已注入测试进程

用户授权的新Booking Business Agent专用Key已通过独立create_session鉴权：HTTP 200并创建空session，没有发送 message、邮件材料或触发Agent run。重启前Parsing、Booking、projection三条durable队列非终态及过期claim均为0； Key仅进入当前测试进程内存，没有写入代码、YAML、数据库、日志或项目文档。

8082已保留原local,local-replay、Parsing v10、PostgreSQL、酒店身份、V2 authority和Trace配置完成重启；H2为V34、 测试PostgreSQL为V13。8082与5178代理均显示PostgreSQL、双Agent、strict execution ready且配置缺项为0；本地身份仍为 HOTEL-LOCAL-REPLAY，三条队列重启后仍为0，旧失败replay保持终态且没有重放。

首次重启后发现测试进程仍显式固定历史v7门禁。用户随后明确授权对齐，第二次安全重启已把Booking expected version更新为 当前RC6 b91686f4-b8b8-4ac0-aeb4-b7a2f54a0a41；新Key及其他测试配置均从当前进程内存保留。8082与5178 capabilities现在一致显示Booking Profile 85ab8334-4e1c-4716-8ec0-9c3c099cec9b、RC6门禁、双Agent/PG/V2/strict ready且缺项0；PostgreSQL仍为V13，三条队列仍为0，本地酒店身份不变，旧失败run未重放。

这一步证明Key鉴权与信息系统的预期身份配置已经准备好，但尚未发送Booking Agent message，所以平台本次实际resolved Profile/version、公开事件、final和Candidate仍须由下一次真实replay验收。Parsing active-run迟到回收也尚未修复。

2026-08-17 v10真实回放：精简已生效，Parsing迟到成功；Booking Key独立阻断

最新 replay 2089351797160271873 已终态 FAILED，总耗时约6分58秒。这次不是 SourceMessage 或确定性 Parser 失败：EML、材料预处理、SourceMessage捕获及 Layer 1/2 均完成；Source Capture 的 WARNING 只是异步交给 Parsing worker 的排队提示。Parsing Agent 实际收到 fixed-channel-parsing-agent-compact-input-v1，命中已发布v10， Provider message 为25462字符/27524 bytes，相比旧真实请求151459 bytes减少约81.8%；9个目标、114条Parser事实、 4份待处理材料均在，证明精简交接已真实生效。

精简没有消除运行超时：第一次Parsing run仍额外执行11次read_file和2次glob，约65秒后才进入模型阶段；本地约4分钟 期限内没有收到最终答案。第二、第三次尝试没有启动新推理，而是因原thread仍有active run均收到HTTP 409。信息系统因此 以AGENT_RETRY_EXHAUSTED收口，但新的安全失败链路已生效：114条Parser事实被保留为Parser-only REVIEW_REQUIRED，Layer4继续处理9个订单目标，并完成18项Roomtype单候选映射。只读查询原SuperAgent run时它后来已为 success，说明结果是“晚到且未被接回”，不是Agent最终没有完成；公共run snapshot只提供截断final，不能据此验收完整输出。

随后出现第二个独立阻断：Booking Business Agent在create_session阶段直接收到HTTP 401，平台原文为 Invalid Open API key，所以Booking Agent没有真正开始运行，也没有session/run/公开事件或最终答案；Layer6因Layer5无结果 而正确阻断。鉴权前已组装的Booking输入约144852字符，是修复Key后要继续观察的性能风险，但不是本次401原因。运行期间另有 远端PostgreSQL连接被关闭并由连接池替换的告警，本次数据仍完整落库且流程继续，因此只是次要稳定性风险。

Lifecycle展示仍不完全准确：确定性Parser被显示为PENDING，Parsing被显示为UNAVAILABLE/0ms，与已保存的202条 Provider记录和真实约4分钟运行不符。当前建议顺序是：先恢复Booking Agent专用Key（否则下一次必定在Layer5失败）；再实现 Parsing同一active run续接/迟到结果回收；随后减少Agent每封邮件读取测试fixture/scenario matrix等非必要资产并重新测时； 再评估Booking约14.5万字符输入、远端PG波动和Lifecycle状态对账。本轮仅做只读诊断和项目记录，未改代码、配置、数据库、 Agent资产、业务规则或PMS/Opera。

2026-08-17 Parsing Agent 精简交接已同步SuperAgent v10，本地待真实复验

fixed-channel Parsing Agent 现已不再直接接收完整内部 AgentRequest。新的 fixed-channel-parsing-agent-compact-input-v1 完整保留 Current 主题/正文、完整有序 History 正文、全部 Parser 权威事实、全部待处理材料及必要证据关联，并按订单目标和物理表格行组织；长内部编号、hash、重复坐标/span、rule、 row unit/segment等技术包装不再发送给Agent。短编号 P/T/R/F/M/E 只在单次调用内使用，decoder在内存中按字段类型 翻译；SuperAgent实际返回的公开事件和final仍按原顺序、原内容写入V13 journal，原始响应hash不变，也不增加第二份 “还原版回答”。

严格JSON/对象不可消费仍会整份进入Parser-only REVIEW_REQUIRED。身份可信后，未知短引用、scope/target错配、来源 不成立、重复材料处置和Parser冲突改为逐项拒绝；其余通过项目继续由薄Layer3 assembler与Parser事实组装为统一 Layer3ResultV2。该assembler不做Layer4 Roomtype/Rate映射，也不判断业务任务；Layer5最终判断权不变。strict replay 不再把已经接住的Layer3 review重新抛成UPSTREAM_REAL_AGENT_FAILED，而是沿现有Layer4–6链路携带明确复核项。

Parsing Agent compact schema、Skill、Main Prompt、references、manifest和v1.0离线包已同步。主代码编译、compact/ adapter/decoder/validator/pipeline、CP4 E2E/terminal/lifecycle相邻回归、23项Python包测和离线包校验通过；合成fixture 及用户提供的真实journal均验证内容闭合。真实旧Provider message为151459 bytes，其中canonical request 151212 bytes； compact payload为27127 bytes，减少82.1%，9行/114 facts/4 materials完整保留。未改Parser/Layer4–6业务规则、数据库、 production开关、前端或PMS/Opera。用户随后完成SuperAgent发布；专用Open API最小身份探针确认Profile仍为 ea56cb01-72f0-4ef2-9a73-40cfae1abcd4，v10实际version ID为 3c42a5f4-799e-4f8b-897b-692c5e76c670，探针run已立即取消。三条durable任务队列均为0后，本地8082沿用现有 local/local-replay、酒店身份、PostgreSQL、双Agent和公开Trace配置刷新；8082与5178 capabilities均显示v10门禁、 PostgreSQL、双Agent、V2 authority和strict execution ready，配置缺项为0。页面已刷新到“新建回放”。尚未执行新EML， 因此不能宣称实际耗时下降或Layer3–6真实成功。详见ADR-019和对应evidence topic。

2026-08-17 Parsing Agent Validator 已改为逐项验收

按用户明确决策，fixed-channel Parsing Agent 的本地 response validator 已从 all-or-nothing 改为逐项验收。 整份返回现在只在 request/message/version/Parser refs/fallback refs 身份不一致或严格 JSON 无法解码时拒绝； 身份正确后，agent target、candidate、binding、relationship、structured mention、display、disposition、review 分别核对身份、来源和 Parser 权威。单项失败只移除该项及其直接依赖，其他已验收结果继续进入 Merger。

Current 正文中的展示原文现在既支持单一 evidence 精确相等，也支持多个有序登记片段共同覆盖；片段间只能是 原文已有空白或标点。Parser facts 仍不可覆盖：同值 candidate 只补 provenance；异值只有明确 conflict review 时作为复核材料保留，Merger 仍保留 Parser 值；未明确 review 的冲突项单独剔除。candidate 业务值完整性和 material 全量处置闭环不再把本层整份返回判失败，业务完整性继续由 Layer 5/6负责。

存在拒绝项时，既有 VALIDATED_AGENT_RESULT artifact 以 fixed-channel-parsing-agent-item-validation-v1 保存净化结果和安全拒绝清单；没有拒绝项时保持原 artifact 格式。 没有新增数据库结构，ADR-017 的原始 SuperAgent journal、Agent Prompt/Skill/Profile、业务规则、production 开关和 PMS/Opera 均未修改。Validator/Pipeline/Handler/Merger/V2/compatibility/source-room 7类40项聚焦测试全部通过。 确认无活动回放后，8082 已沿用原测试运行参数刷新并加载新构建；后端和 5178 代理健康检查均通过，PostgreSQL、 双 Agent、V2 authority、strict execution 均 ready，missing_configuration 为 0。服务刷新当时尚未创建新 replay， 因此不能仅凭环境就绪宣称真实 Layer 3–6 已通过。详见 ADR-018 与对应 evidence topic。

随后真实 replay 2089325562401116161 已完成验证：逐项 Validator 没有成为阻断点，但也没有获得执行机会。 确定性 Parser 成功后，Parsing Agent 收到约 147825 字符的原有重载荷并运行超过本地约4分钟等待上限；第一次 attempt 保存204条公开事件、完成13个工具动作，其中一次模型调用约122秒。原 SuperAgent run 后来为 success，但信息系统已停止 接收；第二、第三次重试均撞上原 active run 返回409，最终 AGENT_RETRY_EXHAUSTED，Layer 4–6未执行。说明精简交接尚未 实施，当前优先问题是已有 run 续接/迟到结果回收，其次才是输入瘦身和期限校准。页面 Parsing 0ms 与 Provider身份 null 也属于日志投影不准确，不能据此判断 Agent 未运行。本轮仅只读诊断和记录，未改代码、配置、数据库或 Agent。

2026-08-17 真实 QBD：Parsing 超时后与 SuperAgent active run 发生重试碰撞

Replay 2089306821453811714 不是卡在确定性 Parser：Parser 已成功，真正长时间运行的是 Parsing Agent。用户导出的 lifecycle 是运行约246秒时的中间快照，所以仍显示 PROCESSING/AWAITING_PARSING_AGENT；当前权威 lifecycle 已终态 FAILED，总耗时约332秒，Layer4–6因 Parsing 失败被阻断。

对真实出站请求逐字段核对后确认，Parser没有传整张工作簿：只传同一Sheet中命中严格底色规则的9行 （118、121、135–141）和36个单元格位置。约15.1万bytes主要由114条确定facts（约10.1万bytes）和153条证据 （约4.7万bytes）构成；邮件本身约2KB且History为空。真正的待处理表格materials只有4个WAITING格、原文共32字符。 当前Builder仍会把完整ParserResult交给Agent，并为114 facts＋4 materials逐条重复生成附件证据；事实值本身很短，体积主要 来自source location、target/fact身份、hash和span元数据。故问题不是“整表误传”，而是“选中行的facts/evidence表达过重”。

第一次 Parsing attempt 已成功创建 SuperAgent session/run，系统保存220条原始返回，其中217条为公开事件；约14.8万字符的 真实请求使 Agent 阅读 Skill、规则、Schema及额外fixture/manifest，并运行到模型前上下文整理。当前默认整体等待为240秒， 本地先超时退出；第二、第三次 attempt 复用同一 thread 时，原 run 仍在运行，SuperAgent 均返回HTTP 409 already has an active run，最终本地以 AGENT_RETRY_EXHAUSTED 失败。

只读查询同一原始 SuperAgent run 后确认其后来已是 success 并存在 final content，说明平台最终完成但晚于信息系统deadline； 本次系统没有继续接收迟到的完成事件/完整stop answer，也不能把结果续回原 processing run。公共run snapshot中的 final_content为已知2,000字符摘要截断，不能据此判断完整答案无效。建议先实现 active-run 续接/迟到终态回收，再校准 真实负载deadline和减少非必要Agent读取，最后修页面跨快照状态对账。本次仅只读诊断和证据记录，未改代码、配置、数据库、 Agent/Prompt/Skill、业务规则或PMS/Opera。详见 50-evidence/topics/2026-08-17-parsing-agent-timeout-active-run-collision.md。

2026-08-17 本地回放 HOTEL_ACCESS_DENIED 已恢复

替换 Parsing Key 后的运行时重启只迁移了 TH_HOTEL_*、Spring 和端口变量，遗漏本地测试身份的酒店配置，导致后端固定 测试账号回退到 HOTEL-TEST，而页面及9条历史 replay 均属于 HOTEL-LOCAL-REPLAY。页面因此在生成 preview 时返回 HOTEL_ACCESS_DENIED；这是本地重启配置不完整，不是用户账号、EML、酒店数据权限或 Agent 的变化。

当前 8082 已重新注入 HOTEL-LOCAL-REPLAY 测试身份并重启；/api/auth/me、指定酒店 capabilities、最近 replay 列表和 既有 lifecycle 均恢复 HTTP 200。Parsing 替换 Key、PostgreSQL V13、双 Agent 和 strict execution 仍保持 ready，未创建 新 replay、未上传/执行邮件。浏览器中的错误条是上一次失败请求的页面残留；已选择的 EML 仍在，可直接再次点击“生成 AgentBus 预览”。本次未修改代码、数据库权限/结构、正式身份、Agent/Prompt/Skill、production 开关或 PMS/Opera。

2026-08-17 Parsing Agent 新 Key 已验证并注入测试运行时

用户提供的替换 Key 已通过独立的 SuperAgent create_session 鉴权检查：HTTP 200 且成功创建 session；检查只创建测试 session，没有发送消息、邮件材料或触发 Agent 业务执行。Key 仅注入当前获准测试进程，没有写入代码、配置文件、数据库、 项目文档或其它持久文件。

8082 已用 local,local-replay 重启并恢复正确端口；PostgreSQL 15.14 / schema V13 连接成功。8082 后端与 5178 代理的 capabilities 均显示 PostgreSQL、Parsing Agent、Booking Agent、V2 authority、strict execution 全部 ready， missing_configuration=[]；Parsing、Booking、正式投影三个后台队列的非终态任务数均为 0。旧失败 replay 保持终态且不重放。

这一步只证明新 Key 能通过平台鉴权，不等于 Parsing Agent 已成功处理邮件，也未验证其 Profile/version、公开 SSE 事件、最终 答案或 Booking Agent。下一步可直接新建回放并使用同一封 EML，完整验收 Parsing → Layer 4 → Booking → Layer 6 及 V2 journal。本次没有修改代码、数据库结构、Agent/Prompt/Skill、业务规则、production 开关或 PMS/Opera。

2026-08-17 新真实 QBD 回放：History 隔离通过，Parsing API Key 被拒绝

新 replay 2089300151851950082（processing run booking-v2-8c3ddee2-3167-476d-8cd2-5f7d0546612f）已证明上一项 FRESH History 隔离修复生效： SourceMessage 为全新创建、不是重复件，duplicate_payload_changed=false；材料包和确定性 Parser 均成功，运行已实际进入 Parsing Agent 调用阶段。因此本次失败不是 EML、附件、History 污染或 Parser 造成的。

当前阻断是 Parsing Agent 的 Open API Key 被 SuperAgent 鉴权拒绝。三次 attempt 都在 create_session 阶段收到 HTTP 401， 平台原文均为 {"detail":"Invalid Open API key"}；系统按退避策略重试后以 AGENT_RETRY_EXHAUSTED 结束。由于 session 尚未创建，Agent 实际没有开始思考或生成答案，所以没有 session、run、公开事件或最终答案；Layer 4–6 与 Booking Agent 均未执行。整次运行约 83.9 秒，主要是三次鉴权请求及重试等待，不是 Agent 推理耗时。

V13 journal 已把三次平台错误响应按原顺序、原内容、时间和 attempt 完整保存，证明完整返回日志的 HTTP 失败路径可用。 下一步应先在 SuperAgent 确认或重新生成 Parsing Agent 专用 Open API Key，再更新本地授权配置并重启 8082，然后用新 replay 重跑；同一封 EML 可以继续使用。Booking Agent Key 尚未被本次运行验证。本次仅做只读诊断和项目证据更新，没有修改代码、 配置、数据库、Agent/Prompt/Skill、业务规则、生产开关或 PMS/Opera。

2026-08-17 AgentBus 新投递回放 History 污染修复（已实现；等待新 EML 实证）

真实 QBD replay 2089292735244656641 的 SourceMessage、材料包和确定性 Parser 均正常，但固定渠道 Parsing Agent 在创建 execution 前失败，故 SuperAgent 实际未被调用。只读对账确认：FRESH_DELIVERY 过去只生成新 message identity， 仍复用 EML 原始 conversation identity；同一 EML 的早期调试副本已在该 conversation 中形成 duplicate_payload_changed=true，后续回放把它当作真实 History 后按确定性门禁拒绝。

现已把 dev/test 回放的 FRESH_DELIVERY 收口为“每次回放同时拥有独立 message 与 conversation identity”， 因此重复上传同一 EML 不再互相成为邮件 History；PRESERVE_IDENTITY 行为不变。固定渠道 enqueue 同时只透传系统定义的 稳定 FIXED_CHANNEL_* 失败码，其中历史 payload 冲突会记录 FIXED_CHANNEL_PARSING_AGENT_HISTORY_PAYLOAD_CONFLICT；未知异常仍收敛为通用失败码，不暴露邮件正文、数据库信息或异常文本。

三个聚焦测试类共 16 项、0 failures/errors；未调用 Provider。8082 已用原有授权测试配置重启，5178 代理正常； capabilities 显示 PostgreSQL、Parsing Agent、Booking Agent、V2 authority 与 strict execution 全部 ready， missing_configuration=[]。旧失败 replay 不会反向修复；下一步必须新建回放并上传 EML，才能验证真实 Parsing/Booking 公开返回 journal。本次未改 Agent/Prompt/Skill、业务规则、数据库结构、正式页面、production 开关或 PMS/Opera。

2026-08-17 SuperAgent 完整公开返回 Journal（已实现；测试库 V13 / 8082 就绪，等待新 EML 实证）

Parsing Agent 与 Booking Business Agent 现在共用一套追加式运行记录：SuperAgent API 实际返回的 session response、 每一条公开 SSE event、断流恢复 run snapshot、HTTP 错误正文和 transport 最终交给业务 decoder 的答案，都会按实际 接收顺序和原内容保存。每条记录带 Provider/系统时间、event id、session、run、processing run、execution、 invocation 和 attempt；重连重复投递照录，失败、超时或断流时已收到部分也会刷新落库。该证据不参与 Parser、Layer 5、 Layer 6 或任务卡判断。

测试与生产使用同一写入代码和 PostgreSQL V13 结构。出站 API Key、Authorization、Cookie、CSRF、数据库密码、 请求头、完整请求以及 SuperAgent 没有返回的隐藏思考不记录。现有安全 execution/invocation aggregate 保持兼容；完整 返回以 booking_superagent_response_journal 为权威。journal 写入失败时当前 Agent attempt fail closed。

开发回放 lifecycle 已升级为 agentbus-processing-lifecycle-log-v2，复制与导出仍是同一 JSON 的两个操作；journal 不可读取时返回 503，不返回残缺日志。获准测试 PostgreSQL 已迁移到 V13；本地 8082 已重启并确认 PostgreSQL、 Parsing Agent、Booking Agent、V2 authority 与 strict execution 均 ready。后端 65 项聚焦测试、前端 45 个文件/ 348 项测试和 typecheck 全部通过。最终只读检查显示 Parsing、Booking、正式投影三个后台队列都没有 READY、CLAIMED、 重试等待或其它非终态任务，可以开始下一次新回放。

历史 replay 不反向补写，所以旧记录返回 0 条 journal 是正确结果。本次实现没有主动上传或重跑新 EML，也没有调用 PMS/Opera；真实 Provider 的逐条内容要由下一封新回放验证。测试 PostgreSQL 早前出现过一次短暂 SSL EOF，当前连接 可用但仍不能据此宣称长期完全稳定；生产部署仍需执行 V13 并使用相同能力。

2026-08-17 BOOKING_DECISION_V2 生命周期识别与失败阶段对账（已修复）

开发回放生命周期读取现已同时识别旧 BOOKING_POSTGRES、正式 BOOKING_DECISION_V2 和 BOOKING_DECISION_V2_SHADOW。读取 V2 时会先核对 processing run、酒店和 SourceMessage 确属同一任务，再使用 V2 保存的 source-message-inbox:{id} 完整标识读取运行、artifact 与 Agent invocation；旧数字 SourceMessage 记录继续兼容。

未重跑邮件、未再次调用 Agent 的前提下，现有失败 replay 2089231898408628225 的 lifecycle GET 已返回 downstream_mode=BOOKING_DECISION_V2、booking_run_status=FAILED，并把 PARSING_AGENT 显示为 FAILED / PARSING_AGENT_HANDLER_INVARIANT；原先错误的 BOOKING_POSTGRES_NOT_SELECTED 与 BOOKING_RUN_LINKAGE_NOT_VERIFIED 已消失。读取器现在仅对“H2 阶段仍为 PENDING，但已核实的 Parsing execution 为 FAILED”这一历史失败组合做窄版对账：确定性 Parser 显示 SUCCEEDED / PARSER_COMPLETED，Parsing Agent 显示 FAILED / PARSING_AGENT_HANDLER_INVARIANT，Context、Rate/Room、Business Decision 和 Validation 统一显示 BLOCKED / UPSTREAM_PARSING_AGENT_FAILED。未知的开始时间和耗时保持为空，不用 execution 创建时间伪造 Agent 开始时间； 已有终态快照和其他运行组合不改。该对账只影响日志读取结果，不回写 H2/PostgreSQL。

三个相关后端聚焦测试类通过；8082 直读与 5178 前端代理对同一失败记录返回一致的阶段结果，已无假 PENDING。本次不修改业务规则、Agent、数据库结构或运行开关，也没有重跑邮件、调用 Agent 或 PMS/Opera。

2026-08-17 PostgreSQL 短稳定门禁（当前可用，发现一次间歇性波动）

授权测试 PostgreSQL 完成了只读短门禁：应用连续 5 次读取同一 lifecycle 均为 HTTP 200 且终态一致；3 个全新直连均成功； Parsing、Booking Agent、projection 的非终态数均为 0，过期 claim 为 0。后端重启后连接池重新连上 PostgreSQL 15.14， Flyway 确认 th_hotel_booking 仍为 V12 且无需迁移；capabilities 仍为 postgres_ready=true、 strict_execution_ready=true、missing_configuration=[]。

但在最终重启复验中，有 1 次 PostgreSQL 新建连接在 SSL 协商时收到 EOF，导致该次后端启动 fail-closed；紧接着 3 次独立直连均成功， 再次重启也成功连上 V12，8082 与 5178 现已恢复一致读取。因此准确结论是“当前可用，但短门禁捕获到一次间歇性连接波动”， 不应宣称完全稳定。应用端远程 lifecycle 查询约 5.5–6.2 秒，也保留为性能观察项。这不是本次状态对账代码造成的失败；如要用于连续真实 EML 验收，仍应单独补连接重试/网络监控或更长时窗验证。本门禁未写入业务数据、未改 schema，也未调用 Agent。

2026-08-17 真实 QBD SuperAgent 公开 Trace 验收（未通过）

用户指定的真实 QBD EML 已按 FRESH_DELIVERY + REQUIRE_REAL_L3_L5 创建一次 preview，并只执行一次确认 POST。 运行配置及正式调用代码共同证明 Parsing message stream 使用 include_trace=true；SourceMessage 捕获成功，随后进入 真实 Parsing worker。

该 run 在两次内部 worker attempt 后以 PARSING_AGENT_HANDLER_INVARIANT / IllegalStateException fail-closed。 正式 Trace 确认 Parser 完成、Parsing Agent 失败，Layer4、Booking Agent 与 Layer6 均未执行；没有 Provider session/run/profile、response hash 或 public_trace_events 可用。该次验证当时还发现 lifecycle 只接受旧 BOOKING_POSTGRES mode、无法识别当前 BOOKING_DECISION_V2；该日志识别问题已由本页上方后续修复。Parsing execution 实表当时仍没有 event/public-trace 列，因此只能确认参数已发送，不能确认“平台日志已返回并被系统接住”；该持久化 能力后来已由本页顶部的V13共用journal实现，但旧run不会补录。未确认、未执行 工作台动作或 PMS/Opera。证据见 50-evidence/topics/2026-08-17-real-qbd-superagent-trace-validation.md。

2026-08-17 Processing Run 全生命周期日志（历史 V1 基线；已被本页顶部 V2 扩展）

开发测试 AgentBus EML 回放现可按 replay/processing run 读取一份 agentbus-processing-lifecycle-log-v1 JSON。它复用既有 14 阶段快照和 Booking PostgreSQL 审计，按顺序记录 阶段状态、起止时间、耗时、输入输出、问题、证据和 Provider 公开轨迹；不新增日志事实表。Booking Agent 会返回 已保存的全部 invocation attempts，Parsing Agent 按现有表能力返回累计 attempt 与最终 Provider 审计。

Parsing 与 Booking 两条主线现在默认且强制 include_trace=true；公开 reasoning.summary 等安全事件进入既有 audit/回放快照，隐藏思考、message final/delta、Secret、URL/Cookie/CSRF 和 Booking raw answer不进入生命周期日志。 开发回放页新增“复制完整日志”“导出完整日志”，两者复用同一个已缓存 JSON 字符串，没有诊断包或第二种报告。

后端 compile/test-compile、相关 Agent/worker/trace 聚焦测试，前端 typecheck 与 2 files/7 tests 均通过。本机 8082/5178 已使用授权测试 PostgreSQL 与双 Agent 配置恢复，capabilities 显示 strict execution ready；旧 replay 2089182353460953090 的接口 smoke 返回连续 14 阶段，浏览器两种操作均成功且无 console warning/error。该旧记录 本身是 PREVIEW_READY、没有 processing run，因此 SourceMessage 以后如实为待执行，也没有可反向恢复的 Agent 公开轨迹。该实现任务当时尚未调用新邮件；同日后续真实验证已执行但在 Parsing fail-closed，并暴露 V2 mode/持久化 缺口，其中 V2 mode、SourceMessage 日志关联和Parsing/Booking完整返回持久化均已由本页顶部后续实现收口。未调用 PMS/Opera，production 开关未变。证据见 50-evidence/topics/2026-08-17-processing-run-lifecycle-log.md。

2026-08-17 SuperAgent 主线公开 Trace 接收（历史安全摘要基线；已被 ADR-017 扩展）

当前 fixed-channel Parsing Agent 与 Booking Business Agent 的 Open API 配置已默认并强制 include_trace=true；显式 false 会在调用 Provider 前 fail closed。共享 client 对两条主线发出的初始 messages/stream URL 精确携带该查询参数，Trace 模式只有公开 run.completed(status=success) 与顶层 end 同时存在才接受成功，core message.final不能替代完成证据。legacy Field Recovery 的 no-Trace 完成查询边界按既有架构保留。

平台公开事件继续通过 SuperAgentOpenApiResult.traceEvents() 映射到 Parsing execution 与 Booking invocation 的 public_trace_events，可保留 reasoning.summary 等公开摘要。Provider message.delta/message.final 文本只用于进程内最终回答，不写可持久 Trace；URL、Secret、Authorization、Cookie、CSRF统一脱敏并限长， Booking V2 raw answer仍不落库。

以上为本日早期安全聚合实现记录；当前完整公开事件和最终答案另由V13 journal按原内容保存，见本页顶部。

属性/SSE/安全投影/两条业务主链共37项测试在沙箱内通过；仅使用本机loopback的共享客户端4项测试在获准环境 通过，合计41项、0 failures/errors/skips。主代码随Maven测试完成编译，目标diff check通过。该实现任务本身未调用 真实平台；同日后续获批的真实 EML 验证只证明参数路径，因 Parsing fail-closed 未取得公开日志终态，不能算回传 验收通过。production/PMS/Opera边界未变。证据见 50-evidence/topics/2026-08-17-superagent-public-trace-propagation.md 与 50-evidence/topics/2026-08-17-real-qbd-superagent-trace-validation.md。

2026-08-14 正式前端 S3–S5（合成验收完成，等待真实 EML 门禁）

新正式壳现已接管 /reservation/booking-processing-runs/:runId、/reservation/source-notifications/:notificationId、 /reservation/orders/:orderId 与 /reservation/order-tasks/:orderTaskId。Run 页面固定读取正式 V2 Run 和 GET /api/reservation/booking-processing-runs/v2/{runId}/trace，展示后端返回的 Layer 1–6、五个组件、脱敏后的 input/output、omission、最终校验、结果和工作台投影；缺持久事实不补造。结果入口只使用明确 refs 与正式相对路径白名单， 没有 Debug fallback。

通知、订单与 order task 页直接消费现有 typed detail/source-material DTO，只读展示 fields、issues、relations、 editable/raw-readonly/availability、处理记录及来源邮件。页面没有 ACK、confirm、review、任务执行或 PMS/Opera 动作；旧页面、 旧路由实现文件和 AgentBus EML Debug 均继续保留。

前端 45 files / 347 tests、typecheck、目标 lint 与 production build 通过；全量 lint 0 error，78 个既有范围外 warning。 临时只读合成 API 浏览器验收证明 Run 返回 6 层/5 组件并可分别进入三类结果；375/1440 五个首轮路由均无横向溢出， 正式 main 内 Debug link 为 0，console error/warn 为 0。临时服务已停止并清理。本任务没有选择或上传真实 EML， 没有请求 /api/system/debug/* 或修改后端/业务规则。证据见 50-evidence/topics/2026-08-14-formal-frontend-processing-run-results.md。

当前已到可见验收点 3，并按门禁停止。只有用户明确确认具体真实邮件与时机后，才可单次上传一封；不得重复上传、增加 第二封、点击 ACK/confirm/review/任务动作或删除旧 Debug。

2026-08-14 BE-TRACE-01 正式 Processing Run Trace（已完成，S3–S5 前置条件满足）

正式后端已新增 GET /api/reservation/booking-processing-runs/v2/{runId}/trace。接口只接受 processing_run_id，固定返回根级 available/partial/unavailable、Layer 1–6、每层 input/output omission，以及 Parser、Parsing Agent、Layer 4、Booking Agent、Layer 6 五个组件状态；没有持久化证据时保留占位，不补算、不从 相邻层或终态猜测。

读取顺序为 Booking PostgreSQL run 身份 → 当前登录用户 RESERVATION_TASK_READ 与可访问酒店 → 平台 source-message-inbox:{id} 关联 → 三重 linked run → 既有 Booking artifacts、Parsing execution artifacts 与 Booking Agent invocation audit。响应在服务端递归移除 Secret/token/cookie/credential、原始邮件正文、raw/provider 字段和 URL； raw answer/provider identity 不进入正式 DTO。Service 不依赖 Debug API/replayId、Parser/Agent service 或任何写 repository 方法，PostgreSQL 关闭时保持应用可启动并安全返回 runtime disabled。

主代码编译通过；新增 10 个 contract/security/read-only 测试及 10 个相邻回归/装配测试全部通过，目标 diff check 通过。未上传或读取真实 EML，未运行邮件流程，未连接远程数据库，未调用 Agent、PMS/Opera，也未修改前端、业务规则、 运行开关或 migration。证据见 50-evidence/topics/2026-08-14-formal-processing-run-trace.md。任务 019fff3a 现在可以开始 S3–S5，仅消费该正式接口。

2026-08-14 正式前端 S0–S2（已完成，BE-TRACE-01 已完成）

当前项目已在既有 Vue 应用内新增隔离的 reservation-formal 亮色正式壳，并把 /reservation/email-intake 切入新壳。新壳复用现有登录、权限、服务端菜单、酒店/时区、三语言、health 与登出； 正式导航不包含 Debug 入口。其他正式业务路由暂未批量切换，旧页面和旧 Debug 前端均保留。

正式 EML 页已复用既有 /api/reservation/booking-email-intakes typed service，完成单个 .eml 选择/拖放、25 MB 限制、上传状态、失败保值和补充错误脱敏。成功后只按返回的 processing_run_id 进入 /reservation/booking-processing-runs/:runId；缺少 Run ID 时 fail-closed，不回退订单任务、通知或 Debug。 本轮浏览器验收没有选择或提交邮件；没有真实 EML、PMS/Opera 或 /api/system/debug/* 调用。

前端验收为 43 个测试文件 / 336 项、typecheck、lint 0 errors、production build 和 diff check 全部通过；1440 与 375 页面检查无横向溢出或控制台错误。独立后端任务 BE-TRACE-01 已完成上述正式 Trace 只读桥接并通过门禁； S3–S5 现在可以只按 processing_run_id 消费该正式接口，仍不得调用 Debug API。

2026-08-14 Booking Agent Trace parameters 收口（RC6 已绑定并通过薄契约；运行仍 HOLD）

Trace Candidate 的员工可读内容已统一进入每个 service item 的 service_text，自由 parameters 已从正式 Schema、 Java DTO、Skill、严格 decoder 边界、V4 投影/查询和前端确认模型删除。GENERAL_SERVICE/EXTRA_BED 类型仍保留； Extra Bed 继续有 Room Type、Quantity，整张 Trace 继续只有一个部门值。Layer 6 对 Extra Bed 房型和正整数数量的复核 没有删除或放宽。

Main Prompt 仍为独立四条最小指令，不复制 Trace 字段细节，也没有进入 .skill。新中文离线包为 booking-desk-event-v1.0-rc6，24 members，SHA-256 741653fa6102ac6cc6f2e439ebf492455f4d01abe35ba5b97bc7aa1f1d3a1ee3，状态继续 HOLD/INTERNAL_ONLY。Schema/source/archive/determinism/quick validation 均通过；Python package 7/7、后端 focused 62/62、前端 40 files/325 tests 与 typecheck 通过。

用户随后完成 RC6 发布/绑定。本次用一项仓库合成 QBD Trace/Extra Bed 输入执行专属 Open API 薄验证：实际 Profile 仍为 85ab8334-4e1c-4716-8ec0-9c3c099cec9b，当前发布 version ID 为 b91686f4-b8b8-4ac0-aeb4-b7a2f54a0a41。首次 SSE 等待在 240 秒本地门禁结束，但同一 run snapshot 已为 success；以相同幂等键接续后 1/1 通过严格 Candidate decoder、Trace service_text、Extra Bed RM2/数量 1、 单值 FO+HSK、无 parameters 及 Layer 6 非拒绝检查。信息系统默认 expected version gate 已同步该 ID；逻辑 booking-business-agent-v1.0 未改，默认/production Agent、provider、worker 仍关闭。Secret 未写入文件或输出， 未连接数据库、真实邮件、PMS 或 Opera。证据见 50-evidence/topics/2026-08-14-booking-trace-parameters-removal.md。

2026-08-14 单封真实 QBD 正式链路验收（非生产通过，停在确认前）

在获批测试环境中只提交了一封正式邮件，POST /api/reservation/booking-email-intakes 返回 HTTP 202 和 booking-v2-3811fbf0-e38c-46c8-9301-42176a9df05f。Parsing Agent 与 Booking Business Agent 均使用各自独立 外部应用完成真实调用，resolved Profile/version 与现有门禁一致。Parsing 输出未通过严格 decoder，按设计持久化为 REVIEW_REQUIRED，没有伪造 Agent facts；确定性 fail-closed 路径继续进入 Layer 4。Booking Agent 的成功 durable attempt 通过严格 Candidate decoder，Layer 6 最终为 VALIDATED / RISK_NOTIFICATION。

独立 V2→V4 projector 为 SUCCEEDED，正式工作台生成两条未确认已读通知且没有订单任务卡，符合本次 Candidate 的风险/一般通知语义。正式查询接口与现有前端通知详情页均可读取；操作按钮只做可见性检查，没有点击。两条通知仍为 ACK_REQUIRED，无 ack/confirm/task action；run-scoped 日志也没有确认、已读、PMS 或 Opera 副作用。

获批 PostgreSQL 已通过仓库 V1–V12 smoke（migration、restart、lease/fence、concurrency、cleanup 和跨 schema guard）。postflight 使用与 preflight 完全相同的对象序列化复算：其他 schema 仍为 60 个对象、SHA-256 指纹完全 一致、跨 schema 外键为 0，只有 th_hotel_booking 到达 V12。正式工作台继续使用本机 H2 V1–V34，没有连接远程旧 MySQL。

链路阻塞只做了四项最小 runtime 修复：事务 committer 可代理、Booking PG 启用时保留主 H2 datasource/Flyway/ transaction manager、canonical JSON 支持顶层 scalar/null、nullable Agent audit JSON 使用显式 PostgreSQL jsonb cast；另有两项只影响 PG smoke harness 的 properties/sequence allowlist 修正。16 个 focused tests、main compile 和 scoped diff check 通过；一次性恢复/诊断代码已移除。所有开关和 Secret 仅作本次进程注入，默认与 production 仍关闭。 证据见 50-evidence/topics/2026-08-14-single-qbd-formal-intake-e2e.md。

2026-08-14 校验结果 → 正式工作台投影（本地已实现，部署 HOLD）

当前共享工作树已经完成 immutable CandidateDecisionV2 / ValidationResultV2 到 V4 本地正式订单、typed 任务卡、通知、Basic、来源材料和审计关系的确定性桥接。独立 projector 通过 PostgreSQL V12 execution/lease/fence/retry 领取 Layer 6 终态，由 typed provenance gate 校验 TARGET/DERIVED/RISK/REJECTED/ GENERAL 身份；MySQL V34 receipt 保证跨库重试不重复造单、建卡或写动作审计。orchestrator、Layer 3–6 和 外部 callback 不能直接写 V4。

New 是唯一可创建 ACTIVE 订单的类型；其他类型只绑定唯一 ACTIVE。缺 Tour Code、New 遇到已有/历史订单、 非 New 找不到订单均形成未归属复核，不按姓名或业务字段猜测。正式输出覆盖 New、Update、Cancel、Trace、 Rooming、Allotment Actual/Deduction/whole cancel、Risk、Rejected 和 General；同 revision 的安全目标独立继续。 Basic 是 New binding group 的共享区块，唯一 sender mapping 可预填 Account/Market/Source，首次 New 本地确认时 冻结。Actual 必须先于 Deduction 确认，未确认 Deduction 只同步 Actual 的房型和数量。

changed payload 使用 exact ORIGINAL/DUPLICATE locator 形成 revision；旧未确认卡/未读通知可被 SUPERSEDED，已确认历史永久保留。V4 是唯一操作入口，支持幂等 Act、人工补值本地确认、通知已读、Tour Code preview/rebind 和精确来源邮件读取；V2 confirmation 返回 moved-to-workbench 409。所有动作只写本地数据和审计， 没有 PMS、Opera、付款、库存或部门调用。

本地实现验收：后端全量 985 tests，0 failures/errors、11 个 opt-in skips；前端 typecheck 及 39 files/324 tests 通过；plaintext-secret scan 与 git diff --check 通过。后续单封真实 QBD 验收又在获批 PostgreSQL 完成 V1–V12 claim/restart/takeover/fence/retry/concurrency/success smoke，并以本机 H2 V1–V34 跑通正式投影；远程 MySQL 未连接。 synthetic revision/retry/rebind、其他渠道矩阵、监控/runbook及 production 批准仍是更大部署范围的 Gate。projection worker 默认关闭且 production 明确关闭；未部署、未发布。

权威决定见 ADR-016，证据见 50-evidence/topics/2026-08-14-validated-workbench-projection.md。

2026-08-14 订单底部邮件还原预览（产品已确认，待前端实施）

用户确认邮件展示不是回复草稿，也不应在每张任务卡里重复。页面顺序固定为“订单/处理记录摘要 → 全部任务卡 → 邮件还原预览”：在每条处理记录底部，只用该 SourceMessage 的 Sender、时间、Subject、正文和附件数据拼成一次邮件 阅读样式，并提供受控“查看原文”。邮件只读、不计入任务卡、不要求员工补录，也不阻断普通任务确认；正文、HTML、 内联图片与附件链接继续走原文权限和访问审计。同一订单有多条处理记录时不得跨 SourceMessage 混拼。正式 V4 办理页 已有任务卡后来源组件可作为基础；新订单工作台底部目前只有普通摘要，单卡工作台还重复来源摘要。本项只增加前端 呈现规则，不修改 ADR-016 typed contract、后端投影或动作语义。

2026-08-14 前端任务卡字段设计基线（历史审计，已由 ADR-016 实现取代）

以下正文保留实施前审计快照和当时的差异，不再表示当前实施状态；当前权威状态以上一节和ADR-016为准。

当前共享工作树已经形成正式工作台详情、字段白名单、动作 availability 和卡片确认/复核接口；因此 2026-08-13“只有整块 candidate、缺少正式字段面”的审计结论只保留为历史时间点。本轮按用户要求不等待 019ffaca-13f1-7d33-b7c0-b3fa66a24540 完成，已只读核对正式模型、查询/动作接口和现有组件，并形成 逐业务的前端字段设计基线；产品确认正在进行，尚未开始页面实施。

当前普通业务卡为 New、Update、Cancel、Trace、Rooming List、Allotment Actual、Allotment Source Deduction、 Cancel Allotment；另有 Allotment Unassigned Review 聚合和 Risk/General/Rejected 通知。New 内已有独立 Basic Information 区块（Sender、Mapping Status、Account、Market、Source），后三项缺失会阻断首次 Act， 成功后冻结。New/Update 已有专用结构化编辑；Cancel/Cancel Allotment/Deduction 走通用字段；Trace 有专用事项 编辑；Rooming List 字段只读；通知只允许 ACK。

当前主要呈现差异是：Update 接口可给出八类当前值但组件只显示日期/Rate/房型房量；Rooming List 的 Tour Code、 Attachment ID 和附件描述未展示；Allotment 未归属关系/候选/问题未展示且 Tour Code 存在可编辑假象； Risk/General/Rejected 的内容项未展示；工作台摘要仍按前三个字段拼接并保留旧 Basic 文案。Payment 只属旧前端 兼容，不进入当前正式字段基线；guest names 也不是当前正式业务卡字段。

邮件还原预览的后续产品确认已提升到上一节；本历史审计不再作为该布局的权威来源。

本轮未修改后端契约、投影、正式接口或前端代码。等目标任务完全结束后只做一次字段、必填/编辑能力、动作与 组件消费差异核对；无差异即按已确认项实施，有差异只确认变化项，不设置单独冻结阶段。完整矩阵见 50-evidence/topics/2026-08-14-frontend-card-field-design-baseline.md。

2026-08-14 Layer 3 V2 旧 required-fact 门禁移除

当前 fixed-channel V2 worker 已停止注入和调用 contracts-v1 FixedChannelRequiredFactPolicy。此前默认 unconfigured()会让没有真实解析问题的结果出现REQUIRED_FACT_POLICY_NOT_CONFIGURED，把Layer3错误标成 REVIEW_REQUIRED、V2投影错误标成PARTIAL，并使strict replay在进入Layer4/5/6前以 UPSTREAM_REAL_AGENT_FAILED停止；该运行残留现已移除。

当前V2只由真实Parser/Provider/Agent输出/冲突/Evidence/材料闭环问题决定Layer3状态。冻结v1桥接DTO中旧完整性 字段暂时保留为非权威审计哨兵NOT_APPLICABLE_V2_LAYER6_OWNED，不伪造CONFIGURED/SATISFIED目录，也不产生 review。显式旧policy构造器仅为contracts-v1兼容保留，待CP6单独退出；Layer5业务判型与Layer6业务字段完整性 规则未改。

共享工作区正式聚焦命令覆盖9个直接相关测试类，共43项，0 failures/errors/skips；包括clean READY、worker SUCCEEDED、CP4继续Layer4/5/6、Provider非法/timeout和显式legacy兼容。首次命令短暂遇到的范围外AgentBus在途 编译错误已由其所属并行任务修复，本任务未修改该文件。未调用真实Provider、数据库、PMS或Opera。

2026-08-14 Booking Agent V2 durable 正式运行接线

当前普通V2入口与fixed-channel最终Layer3 continuation已共用单一durable Booking runtime。Layer3/Layer4/ canonical input和AWAITING_BOOKING_AGENT在短事务中可靠保存并提交；后台worker随后以 SKIP LOCKED + lease + fencing领取，且只在无Spring事务时调用现有Booking专用SuperAgent port。Candidate与 成功attempt审计单独提交，再从持久Candidate进入Layer6；崩溃或Layer6瞬时数据库错误不会重复外呼，Provider 失败也不会回滚已经完成的Parsing/Layer3/4。

V11新增唯一booking_agent_execution，并加法扩展现有run status、artifact allowlist、Allotment enum和 booking_agent_invocation。运行状态覆盖等待、调用中、retry wait、candidate received、retry exhausted、 candidate rejected、Layer6 validating、validated及awaiting confirmation；幂等键固定为 booking-v2:<input_sha256>。有限重试只用于timeout/断流/临时transport/408/425/429/5xx；JSON、契约、 逻辑或平台Profile、input/evidence/reference/size错误直接fail closed为安全Risk并经过Layer6。

严格decoder现在同时校验processing run/source message/revision、input hash、evidence闭包、全局event/action ID、 linked relationship和Allotment source→actual闭包，Agent不能绕过Validator直接生成任务。QBD/LianTai的 New/Update/Cancel/Allotment本地核心矩阵、故障/超时/重试耗尽、重复stage、重启恢复、Candidate hash、半开开关和 事务边界均通过；房型ONE BEDROOM SUITE DBL → ONE-BEDROOM-SUITE-DBL → exact RM2回归继续通过。

后端全量957 tests为1个范围外并行V4 failure、0 errors、11 skipped；唯一失败仍是 ReservationV4CommandControllerTest.shouldResolveRoomInformationReviewWhenDisplayPayloadAlreadyUsesStableModel expected 200/actual 400。当前进程没有Booking专用Secret、expected Profile/version、Booking PG或live smoke开关， 所以本轮8次合成平台矩阵与真实PG V1–V11 smoke未执行；历史CP5已验证Booking v7，但部署前必须复验当前发布身份。 默认及production Agent/provider/worker继续关闭；未做V2→V4、Rooming全业务、人工闭环、PMS/Opera或平台修改。

2026-08-14 CP5 SuperAgent 测试平台绑定

用户明确批准测试环境 AgentBus/SuperAgent 调用并继续禁止 PMS/Opera 后，CP5 的“测试平台身份绑定＋真实 Provider 契约验证”已完成。Booking 与 Parsing 使用两个独立 external app/Secret；公开Open Agent API由各自 token选择Profile，不在payload传profile_id，也不使用external_subject_id路由。

• Booking：Profile 85ab8334-4e1c-4716-8ec0-9c3c099cec9b，发布v7 9fed48c0-1f53-4d5a-8ba0-52865c738d83，唯一Skill booking-desk-event。真实Java smoke经当前 wire projector、严格CandidateDecisionV2 decoder和Layer6 validator通过1/1（52.782秒）。
• Parsing：Profile ea56cb01-72f0-4ef2-9a73-40cfae1abcd4，发布v8 8b30ebe9-180c-433b-89cf-9c59933b618a，唯一Skill fixed-channel-core-parsing-agent。LianTai canonical 合成请求经当前adapter、deadline、严格decoder和semantic validator通过1/1（202.146秒）。
• 两份独立Main Prompt均与仓库正文在去除平台尾部空白后逐字一致，仍不进入.skill包；两个Profile发布检查 均11/11，API/stream开启，MCP/memory/Profile calls/公开Trace关闭。
• Parsing真实调用发现公共message.final约2,000字符截断，而同一SSE的stop assistant message保有完整JSON。 共享parser现仅在core final是完整stop内容的严格前缀时保留完整内容；不同显式final仍保持权威。Parsing整体 等待默认值按实测提高到240秒。
• focused 53 tests为0 failures/errors、2个live测试默认skip；后端全量稳定复跑953 tests为1个范围外V4 failure、0 errors、11 skipped。唯一失败仍是既有V4 controller expected 200/actual 400。

本次Secret未落仓库/配置/文档/日志。默认和production的Agent/provider/worker仍为false；没有启动AgentBus WebSocket、部署或重启应用、执行数据库smoke、调用PMS/Opera或开始CP6。因此“测试平台CP5绑定”已完成， “自动主流程运行发布”仍需指定非生产部署的Secret注入、重启/开关、完整AgentBus＋PostgreSQL双Agent smoke、 监控/告警/人工重放；production另行批准。业务字段完整性继续由Layer6负责，不再等待Layer3 required-fact目录。

2026-08-13 Layer 3 当前邮件 Rooming List 文件名材料识别

已按获批 Change Request 完成当前附件 Rooming List 中立材料的本地实现与 focused 验收。信息系统只处理 current_material=true 且完整文件名命中批准 LLT...xlsx 规则的附件，先校验附件 bytes/size/hash，再以 固定 2 MiB、4 Sheet、256 ZIP entries、16 MiB 结构读取上限流式检查 OOXML 包、保护、宏、外链、隐藏 Sheet 和公式；业务单元格扫描为 0 行/0 列，不读取 shared strings、名单行、姓名、同行关系或证件。

识别快照写入既有 MaterialPackage attributes；公共 Parser、FAILED fallback 与兼容 parseLegacy 只接收排除 Rooming 候选后的附件视图。最终 Parser/Agent 本地合并后，由确定性 enrichment 追加 POSSIBLE_GUEST_LIST_SPREADSHEET、BOUND binding、Evidence 与材料 issue；canonical input 组装前由独立 resolver 生成既有 rooming_list_resolutions[]。技术检查成功才是 RESOLVED，失败保留候选但 Layer 4 为 null Tour Code/UNRESOLVED。direct CP4 completion 已从持久 MaterialPackage 恢复全部当前附件，History附件 继续排除；Parsing Agent request 不包含 Rooming 文件名、bytes 或内容。

Booking Agent decoder 与 Layer 6 已加本地防线：成功 target 必须精确匹配唯一 resolved resolution、相同 attachment/Tour Code/材料 Evidence；同 Tour Code 多份有效附件或伪造引用不得被接受。main compile 与 Rooming focused 62 tests 全绿。最终整仓快照 919 tests、1 failure、0 errors、9 skipped；唯一范围外失败是既有 ReservationV4CommandControllerTest.shouldResolveRoomInformationReviewWhenDisplayPayloadAlreadyUsesStableModel 的expected 200 / actual 400，本任务未越界修改。仓库当前没有批准的 QBD/LianTai真实样本文件，因此未重跑114/4、70/6，只保留既有canonical基线。本任务未连接真实Provider、 AgentBus WebSocket、数据库、PMS或Opera，也未启动CP5/CP6。下方邮件回放记录中的 RoomingListParserRoutingTest构造器阻断已由本任务基于最新类型完成兼容，不再是当前testCompile阻断。

2026-08-13 邮件导入接入 AgentBus 真实双 Agent 回放

用户计划已完成源码实现与本地验证：BR00/local-test 邮件导入统一跳转真实 /debug/agentbus-eml-replay?entry=email-import，旧 prototype 地址保留兼容重定向；邮件模式固定 FRESH_DELIVERY，每次确认创建新的 SourceMessage/V2 run，并携带显式 BookingExecutionContext （replay/policy/delivery mode）。严格策略要求真实 QBD/LIANTAI Parsing Agent（L3）与 Booking Business Agent（L5），缺 provider、profile/version、worker、PG 或 V2 authority 时 fail-closed，不走 local success。

严格执行已接入 durable PROCESSING/终态轮询、V2 run correlation、重启后按 V2 状态恢复、固定 local/test operator 与 local file/H2 replay storage；生产 profile 不注册该 bypass。Trace 采用 additive v3：保留旧 v2 可读性，严格回放保留 L1–L6 的安全 input/output、独立 PARSING_AGENT 阶段与 BUSINESS_DECISION provider exchange 元数据；L6 terminal 不调用 Confirmation Projection、不写候选确认项，L7 仍 reserved，不做 confirmation/PMS/Opera 写入。主库新增 V33；Booking PostgreSQL 新增本计划的 V10 replay correlation，并沿用当前工作区已有的 V11 V2 durable Booking Agent 状态/执行表；PG repository 的 terminal/retry/confirmation 状态已补齐 durable 时间字段。

本地检查：server main compile 通过；前端 38 files/321 tests、typecheck、lint、build、no-secrets 通过； H2 focused 日志已应用 Flyway V1–V33，git diff --check 通过。回放相关 focused Maven 集合为 60/60 通过；命令仅在 testCompile 阶段排除当前并行脏工作区已有的 RoomingListParserRoutingTest.java 测试源， 未扩大排除范围。随后不带排除规则执行 Maven full：919 tests、1 failure、0 errors、9 skipped，唯一失败为 范围外 V4 controller failure，未修改。Booking PostgreSQL smoke 因缺少 TH_HOTEL_BOOKING_PG_URL 停止，当前没有真实 Agent/PG/Secret 证据，因此不得宣称 live 双 Agent chain 成功。

Current Focus

2026-08-14 正式前端当前焦点：S0 基线保护、S1 新正式壳和 S2 正式 EML 上传页已经完成； /reservation/email-intake 已切换，新 Processing Run/结果页面尚未切换。独立 BE-TRACE-01 已完成正式只读 Trace 契约、安全与无副作用验收；下一步可以实施 S3–S5，并且只能消费新正式接口。用户再次明确批准前不上传真实 EML；正式前端不调用 /api/system/debug/*，旧 Debug 前端继续保留到真实联合验收门禁满足。

2026-08-13 已完成“前端确认工作台与页面展示契约”第一阶段只读审计：现有 订单 → 处理记录 → 任务卡 壳可复用，但 BR00 是 fixture、新正式 Task Card Workspace 仅为摘要、旧 V4 与 V2 processing-run 又形成两套确认面。V2 Candidate/Validation 已有 typed 业务事实与校验，但 Confirmation 仍复制整块 candidate，缺字段级建议/确认/编辑/证据/提交语义；V2 confirm 目前拒绝员工 override，General 未投影，Basic Information 也不在 V2 projection。建议新增版本化 Layer 7 workbench display contract；公共 IA、Basic Information 是否并入 New、Risk/General 层级和唯一确认入口仍待用户逐段确认。本轮未修改业务代码或运行状态。

2026-08-13 用户撤回“不展示 Basic Information、QBD/LIANTAI 作为 title”的上一条记录。当前确认口径是： Basic Information 仍保留，但只在 New Booking 任务类型展示；四列为 Sender 邮箱 | Account | Market | Source。映射固定为 op.qbdtravel@gmail.com | QBD | gtt | TA 与 op.liantaitravel@gmail.com | LIANTAI | gtt | TA；QBD/LIANTAI 是 Account，不是 title。本次仍只更新项目 记录，没有修改任何前端页面、后端契约或工作流；当前页面默认展示行为尚待另行授权实施。

2026-08-13 fixed-channel Parsing Agent v1.0 已完成当前 Booking V2 direct Layer3 handoff 与 Parser FAILED 受控fallback。@Primary V2编排器对已验证QBD/LianTai在公共Parser后持久化Parser/fallback并原子enqueue， 将同一run置为AWAITING_PARSING_AGENT后立即返回；worker从持久snapshot重建完整Current主题/正文及严格有序、 不截断History正文，完成本地严格校验/merge后无业务解释投影至latest Layer3ResultV2，再由独立continuation 同run执行当前Layer4/5/6及现有Layer7确认投影边界。合法targets/bindings/relationships/mentions/display/reviews/ dispositions均保留，V2无槽位的authority/material审计进sidecar；不生成Trace、部门、business type、TaskCard、 canonical Room/Rate。expected Agent失败继续Parser-only fail-closed；内部不变量失败不发布半成品。

FAILED fallback只接受唯一Current .xlsx的exact identity/hash/MIME/size/revision，并限4个可见sheet、200个可见行、 800个cell、单cell 512 code points、总文本20,000 code points、2 MiB workbook；拒绝公式、宏、链接、隐藏内容、 图片、注释、URL-like标量、损坏及任一超限，且绝不截断。无授权fallback时仍处理完整邮件正文，并保留稳定 PARSER_FAILED_NO_AUTHORIZED_FALLBACK blocker。AgentBus新路径接管时不再触发旧realtime dispatch。

阻断验收补充已关闭：SOURCE_ROOM_NAME保留邮件/工作簿原始房型和Evidence，但normalized只使用Profile Parser 已确认的标准来源房型；V2 projector原样透传。QBD与普通LianTai本地E2E均证明 ONE BEDROOM SUITE DBL → ONE-BEDROOM-SUITE-DBL → exact Layer4 RM2，且与直接标准写法的Rate/早餐处理一致 （QBD均为GRPA1/含早/BUALUANG，普通LianTai均为LBLT/不含早）； Q10/Garden/Pool不变，未知label继续material/review。Layer4/catalog未改，也未新增模糊或contains匹配。

最终fake/mock/local focused为149 tests（142 executed、7真实样本缺失skip、0 failures/errors）。后端全量最终快照 902 tests、1 failure、0 errors、9 skipped；唯一失败是范围外并行V4测试 ReservationV4CommandControllerTest.shouldResolveRoomInformationReviewWhenDisplayPayloadAlreadyUsesStableModel （expected 200, actual 400）。本任务未调用真实Provider/AgentBus WebSocket/数据库/PMS/Opera，默认及production Agent/provider/worker继续false；Agent Skill/Main Prompt/Schema、Parser规则和前端未改，CP5/CP6继续HOLD。

2026-08-13 已将邮件/表格完整读取边界同步进共享Parsing Agent Skill：完整Current主题/正文是必读来源， 全部History正文须按sequence完整阅读且不得由Agent筛选“可用性”，全部Current Parser Results须逐项读取， 其中facts[]保持权威只读、agent_materials[]逐项处理并闭环。三份Schema、fixtures业务结果、独立Main Prompt和runtime均未改变；重新生成的15成员HOLD包SHA-256为 94bb65b6a7af75b1c6e5edf5496d3c66e12058362a735c2402136628e91ba22d，package tests 23/23、 Skill Creator quick validation及确定性双打包通过。

2026-08-13 Layer 4/5 pre-release 契约已按最新产品确认修订并完成 focused 实现：确定性组装器把同一 Current＋有序邮件 History 正文＋完整 Layer3ResultV2＋Layer4 typed context 合成唯一 canonical 输入；History 附件仍不传。Layer 4 不再查询数据库当前订单/任务历史，旧 Provider/Repository 已退出 Spring 运行链；来源缺失 直接 null/UNRESOLVED。QBD 输出一项同时适用 FIT/GROUP 的 Rate option，普通 LianTai 同时输出 FIT/GROUP 两项， Layer 5 按来源房量决定 Booking Type 后只能取对应方案；Layer 6 已移除重复New/生命周期/前序任务检查，只校验 对应 option 等值。五条 Roomtype 修正已落地，其中精确 ONE-BEDROOM-SUITE-DBL→RM2 不扩展到其他DBL套房标签； 独立Rate套餐投影仍为90d5c733...fe27a。当前主代码编译、Python 31/31与Rate/Room＋Layer4 focused 38/38通过。 整仓888项另有1个范围外V4命令测试失败：旧夹具含早餐但没有提供现已必填的早餐餐厅；单测稳定复现，不经过 本次Roomtype/Rate Resolver。该pre-release checkpoint当时的Layer3 handoff与Rooming List resolver缺口均已由 本文上方记录的后续实现关闭；最新业务验收、Provider/生产仍HOLD。 Booking Agent source 已按新契约确定性生成24成员RC5 HOLD包，SHA-256 125bf94301c2afb2977563ef2e2fded78bfb0a591e3f7c41f3424ee86dcaa1b9；source/archive/hash校验与Python打包测试通过， 但未安装、未发布且不代表最新业务验收。

2026-08-13 已按产品确认优化共享 Parsing Agent 独立中文 Main Prompt：Current主题和正文必须完整解析； 系统提供的全部History正文必须按sequence完整阅读，Agent不得自行筛选、截断或判断某封是否可用，但History 仍只能辅助Current；当前附件Parser facts[]逐项只读，agent_materials[]逐项阅读并处置。Prompt仍为四段， SHA-256更新为8ad0a914c1596563122d94efff084419204524c6fa48acc721704d6b3786b5f6；15成员 .skill归档、Agent Schema、Parser、Java/runtime和HOLD状态均未改变。

2026-08-13 用户已把参数审计范围纠正为 Booking Agent 固定输入：从当前邮件/附件具体位置提取、规范、绑定并 流转到 Agent。已新增聚焦业务确认稿，逐项覆盖 QBD C/E/H/J＋动态 WAITING、LianTai A–I、当前正文、十类 来源参数、Room/Rate 与 P01–P21；早期 Layer 1–7 大稿只保留为背景审计。P17 已确认：FIT/GROUP 不设两套 提取路径，统一提取并按有效房量 1–4/5+ 判型，姓名等资料不参与。该时点代码交叉核对发现G01–G05；其中最终 Parsing Agent handoff与Rooming List resolver已由后续专项关闭，来源动作日期/BEFORE/History wire状态须以 当前权威契约和代码为准。 本次只交付确认材料，未改变 ADR、代码、配置、Provider 或运行状态。

2026-08-13 旧离线验收记录（已被上方pre-release修订部分取代）：每封白名单入站进入预订流程后必须调用 Agent；当时 Agent wire 排除完整 History 的结论已废止，现改为接收邮件 History 正文并继续排除 History 附件。 CandidateDecisionV2 已收口 New/Update/Cancel、结构化 Trace、单附件 Rooming List、逐物理目标 Allotment、 局部 Risk 与未归类原文；Payment 不属于本期业务类型。当时 Layer 6 生命周期/重复New结论已由上方修订删除。 独立 Main Prompt、仓库 Skill source、3 组 golden、46 项矩阵和 24 成员 HOLD 包均完成；后端全量882 tests为当时快照的0 failures/errors、9 skipped，不代表当前并行工作树； 当前RC4 Python package tests 6/6通过。 本结论仅覆盖获批离线范围：真实 Profile/Secret/Provider/数据库、Skill发布、V2→V4 writer/页面和生产仍HOLD。

2026-08-13 根据产品要求生成中文Agent资产RC4：包内供Agent阅读的SKILL.md、11份业务references和 agents/openai.yaml全部改为中文，manifest标记instruction_language=zh-CN；JSON字段、枚举、reason code与三份 Schema保持契约原样并逐字节一致。完整Candidate Schema必读链和中文说明均有防回退测试；24成员.skill仍不含 Prompt且保持HOLD。RC4 archive SHA-256为a6b71d6c8410665629100ba9931c6147b6e3551467ee99381ca749b6cbe16cdd，包测试6/6通过。

2026-08-13 已完成获批的 CandidateDecisionV2 预订类 payload 契约切片：NEW_BOOKING、 UPDATE_BOOKING、CANCEL_BOOKING 现为三个互斥 typed payload，Cancel 仅保留 discriminator；New/Update 固定承载可空业务字段、独立来源 room item、opaque price、Tour Code 级 Rate/早餐与 FIT 姓名身份。Schema 严格字段存在/未知字段，Layer 6 校验正整数、日期、身份、早餐、Tour Code一致性和Layer4逐字段冲突，因此 第二道门槛缺失/非法值保持原业务类型并进入review。Decoder、deterministic engine、MySQL artifact、canonical hash、confirmation引用及内部V4 provenance已对齐；V4额外核对exact Candidate identity/payload快照，不新增writer 或启用AUTHORITATIVE。相关V2/Layer4链70 tests、扩展核心30 tests及后端全量882 tests均0 failures/errors （全量9 skipped）。从未上线的 v1 正式契约/Profile 文档已由后续 Layer 5 离线实现删除；旧 Java 技术类型因 冻结 CP4/旧 V4 编译依赖继续隔离保留，未建立兼容/双写/迁移分支。本段仅记录当时的预订类切片，Layer 6 生命周期与其余 Layer 5 类型已由上方后续成果补齐。

2026-08-13 earlier audit 已完成 Booking Layer 1–7 与 V2→V4 参数衔接只读业务盘点，并形成待确认稿。本次 CandidateDecisionV2 契约切片已关闭预订类 Rate/早餐承载、Layer 4 已知字段等值校验与内部 projection gate； V2 仍默认 SHADOW，公共 Layer 3 最终 handoff、当前订单生命周期、Layer 6 任务顺序、Review 修正/writer 及其余 D 项仍未闭环。G01–G12、D01–D16 中未被本切片明确批准的内容继续保持待确认；不得把本次局部实施 记为整个 Layer 5 已确认，也不得据此启用 Provider 或切换 AUTHORITATIVE。

QBD 与 LianTai 的 Parser 公共输出已按 ADR-008 冻结为 status + facts[] + agent_materials[]：公共 facts 只允许十类，GROUP_IN / SOURCE_RATE_CODE / ROOM_QUALIFIERS 删除，完整 SOURCE_ROOM_NAME 保留 BF/Q10， BF 同时形成早餐事实。QBD、LianTai 和共享入口的默认 parse 已实现该公共 DTO 与共享唯一值 Core； 渠道工作簿规则仍在各自 Profile。CP4 已把公共 parse() 接入默认关闭的 v1 分支；legacy 分支仍显式调用 deprecated parseLegacy。因此 CP4 内部链已完成，但真实Provider放行与旧链删除尚未完成。

2026-08-11 真实样本发现的三项 Parser 缺口已修正并通过回放：共享 Core 新增受严格位置校验的 Profile 原始材料入口；QBD 可选 WAITING 列按表头识别，非空单元格整段原样形成用户备注，不解释为价格；QBD 物理明细行按完整“房型＋数量”块统一判定 BEFORE/AFTER/CURRENT；LianTai G/I 完整原文与 D 列残余原文 进入公共 materials。批准样本结果为 QBD 114 facts/4 WAITING materials、LianTai 70 facts/6 materials， 公共 DTO、十类 facts 和 BF/Q10 语义均未改变。

LianTai 的共享 fixed-channel Parser/Profile、source-room组件和共享 Parsing Agent v1.0 资产已完成； 发布前架构纠错已把Layer 3旧Trace/部门输出原地替换为中立structured_mentions[]。Parsing Agent只提取 来源结构，未来Merger仅保留STRUCTURED_MENTION，Layer 5 Booking Agent决定Trace/linked action和部门候选。 独立Main Prompt已压缩为中文四组规则，继续不进入Skill读取链或.skill归档；包仍固定15个Skill成员。 两版August真实工作簿分别独立解析通过，July 7列旧模板按范围受控进入人工。本期固定渠道只包括QBD与LianTai。 Parsing Agent仍为HOLD/INTERNAL_ONLY；CP4 的 AgentBus/手工入口与信息系统内部主链接线已完成，但真实 Provider worker/scheduler、PMS/Opera与部门流转均未放行。

2026-08-12 Layer 3 runtime integration CP4 历史checkpoint已完成并收口：手工 EML 与 AgentBus 都先持久化/复用 SourceMessage，固定渠道 v1 分支调用公共 Parser 并原子保存 Parser artifact/入队 execution；loader 按 revision 读取 exact Current subject/body 与完整有序 History body，History 附件零传递；fake worker 完成 request/evidence、 严格 result 校验、本地 deterministic merge、八数组 Layer3 artifact、compatibility projection 与 Context。 成功/失败终态均按 Booking PostgreSQL 事务闭合；V6 放行 runtime artifacts，MySQL V30 保留 exact original subject。默认/production 的 enabled/provider/worker 均 false，真实 Provider/scheduler 未注册，required-fact 目录未配置时只到 Context。CP4 Java 233 tests 0 failures/errors、7 skipped；排除两组 CP6 旧 v0.2 测试后 主流程 Java 782 tests 0 failures/errors、8 skipped；原始全量 789 tests 的 6 errors 均为旧 v0.2 FileNotFound。 Agent 22/22、Python 50/50、Skill 严格 package check 通过。该历史checkpoint当时停在旧compatibility下游； 本文首段的后续任务已关闭direct V2 handoff，CP5/CP6仍未开始。

2026-08-12 用户另行授权CP5前非生产PostgreSQL基础设施Gate：目标库经严格V001身份、空旧业务表和对象 allowlist检查后，以Flyway version 0记录旧模型共存并成功应用V1–V6；两个独立Spring上下文完成重启后的 过期lease/fence接管，旧owner续租/终态写入被拒，两个独立连接池并发claim仅一个成功。真实PgJDBC暴露 Instant绑定TIMESTAMPTZ缺陷，repository已统一转Timestamp。正式PG smoke 1/1、repository 7/7、 当前主流程Java 789项均0 failures/errors；合成数据归零、旧表仍为空、无跨schema外键。MySQL V30、CP5 Provider/scheduler和CP6仍未开始。

2026-08-12 Layer 3 runtime integration CP1纯本地核心已完成：v1 request/evidence builder、调用前preflight、 严格result decoder/跨输入validator、八数组Layer3 DTO、Parser不可覆盖deterministic merger、required-fact policy端口、provider-neutral Port与test-only fake/local pipeline均已实现，未注册Spring、未接配置/DDL/主链， 也未调用外部系统。Java联合focused 59/59、Agent 22/22、Python 50/50通过。canonical evidence span发布前 纠正后15成员包SHA-256为3ee9bbb90107078710958df15901c87cbea7be219ab6cb29540ab348e3f02ff2； Main Prompt SHA不变且仍不入包，状态继续HOLD/INTERNAL_ONLY。下一实施边界是CP2持久execution/幂等worker； business required-fact catalog与CP5平台绑定仍阻塞自动业务和真实Provider放行。

2026-08-12 Layer 3 runtime integration CP2离线durable execution已完成：Booking PostgreSQL V5、 幂等repository、SKIP LOCKED、lease/fencing/CAS、retry/backoff、immutable normalized artifacts、无Spring worker与local handler均已落地。崩溃后可以更高fence恢复；timeout/unavailable持久重试，耗尽后 生成Parser-only blocker；内部invariant不发布Layer3。CP1+CP2 Java 83/83、Agent 22/22、Python 50/50通过。未连接真实PostgreSQL、未注册scheduler/loader、未调用外部系统；下一离线边界为 CP3专属SuperAgent adapter的mocked transport，runtime继续HOLD/INTERNAL_ONLY。

2026-08-12 Layer 3 runtime integration CP3专属SuperAgent Adapter已完成：booking.parsing-agent.*独立 properties、默认/production关闭配置、有界executor、专属Open API wrapper和provider-neutral adapter均已 落地。它只复用通用session/SSE/run-status/recovery transport，强制无Trace、完整request不截断、UTF-8大小 和整体deadline、hash subject、稳定幂等以及实际Profile ID/version精确栅栏；不复用任何旧Agent凭据。 Provider返回被拒绝时只审计response hash与安全session/run/Profile metadata，不保存raw answer。CP1–CP3与 共享transport Java联合119/119、Agent 22/22、Python 50/50通过；未调用真实Provider/DB/AgentBus/PMS/Opera， 未注册scheduler/SourceMessage loader/主链。下一边界为CP4内部runtime wiring，CP5绑定前继续HOLD。

2026-08-12 Layer 3 runtime integration 已进入 CP0：新增 Proposed ADR-010 与 Draft M012 Change Request，提出 “入口先绑定SourceMessage并持久化公共ParserResult → pre-Context durable worker → v1 request/evidence → provider-neutral Port → 本地严格Validator/Merger → compatibility projection”的运行切面。最终Layer 3结果拓扑、 optional material target版本策略、调用矩阵、evidence分段、失败状态映射、required facts与平台绑定仍为审批Gate； CP0 后已增加一个完全未接线的 CP1 安全切片：冻结 v1 Agent result Java records、严格 JSON decoder 与 canonical fixture/intrinsic validation tests。该切片没有 Spring bean、Port、request/evidence builder、Merger、配置、DDL 或 运行时调用；Provider 仍未接入，HOLD/INTERNAL_ONLY 未解除。专项 10/10、相关 Java focused 34/34、Agent 21/21、Python 49/49 通过；后端全量 693 tests 的 6 个 error 全部来自两组旧 v0.2 测试继续读取已删除的 Trace/schema/fixtures，未通过恢复旧资产掩盖该迁移问题。

2026-08-12 用户已委托Codex决定并推进技术方案。ADR-010现已Accepted并授权默认关闭的离线实施；最终结果、 调用矩阵、evidence/history、failure和单workbook技术策略已收口，business required-fact catalog与CP5平台绑定 仍阻塞自动业务/真实Provider放行。Parser material target_ref已按冻结业务/Java语义纠正为“字段必有、值可空”， fact target仍必有对象；Agent专项22/22、Python全套50/50和确定性重打包/--check通过。当前15成员包SHA-256 为bb8c06f60aaefbe50e479811424f3f79c856bfb2f3395429823fe11116b124d3（该nullable-target checkpoint后续已由 canonical evidence span纠正包3ee9bbb90107078710958df15901c87cbea7be219ab6cb29540ab348e3f02ff2取代），Main Prompt未改且仍不入包， 运行状态继续HOLD/INTERNAL_ONLY。

M012 Layer 3 QBD 确定性 Parser、字段 Recovery 共用契约、本地实现、INTERNAL_ONLY .skill 与 MANUAL_EML SuperAgent 同步 Adapter 已完成。真实 API 契约已确认由 token 外部应用策略选择 Profile； Recovery 已改为独立 key/client wrapper、哈希 subject 和无 Trace 最终事件/run-status 确认。真实合成 transport/Profile smoke 已通过；ADR-008 冻结后，完整 PatchSet、PostgreSQL V3 与超时/审计联调暂停， 旧 runtime 继续默认/生产关闭，待 Parser/Agent/merge 迁移决定其去留。Layer 5 Booking Business Agent 也已完成 独立 wrapper/config/Secret 接线和 hash subject；该段记录的是当时仍在既有processing-run worker内等待的 历史checkpoint。2026-08-14已由本文首段V11 durable runtime取代；2026-08-11 no-Trace transport/Profile smoke的占位Prompt也已由后续CP5正式Prompt/Skill、Booking v7及真实Candidate smoke取代。部署仍须重新复核 当前Profile/version、专用Secret、V11和八场景，不能恢复旧同步链或引用旧平台状态放行。

AgentBus EML 回放的 14 阶段真实 Trace 已完成并在 2026-08-13 升级为 V2 snapshot projection：回放阶段继续使用 V29 快照，Booking Layer 1–6 通过 booking-layer-trace-snapshot-v2 展示实际安全裁剪 input/output、契约版本、 兼容模式、issues/evidence 与 V2 processing_run_id；SHADOW 同时保留 legacy dispatch_run_id。Layer 7 仅保留 LAYER7_TRACE_RESERVED 位置，不采集确认投影或人工动作；Booking V2 artifacts 仍是业务事实源。Booking Agent 旧trace页面仍可读取历史V4 invocation的合规字段；V2 durable attempt固定不保存raw answer，只展示受控hash、 Provider metadata、failure class及持久Candidate/validation摘要。正式页和BR00本地页共用蓝白调试工作区。 该能力仍只在 local/dev/test 显式启用，不触发 PMS/Opera。

2026-08-12 用户已关闭 Layer 4 的 QBD/LianTai RATE CODE 规则集选择缺口，并后续修正 QBD 有效配置 Type=Group&FIT：QBD 团队/散客进入同一套 RATE CODE 映射，具体 GRPA 代码仍按来源房型、价格和 早餐/餐厅确定；冻结 0810 目录中的 Q.B.D / Group 只作旧标签 provenance。普通 LianTai FIT 使用 LIANTAI ONLINE/DY / FIT，普通 LianTai Group 使用 LIAN TAI / Group；这不恢复 LianTai-FIT sender、 渠道、Parser或Agent Profile。最终Excel现已生成独立有效映射配置并接入只读Catalog查询：213条候选行、 163个四字段场景，136个原始唯一、27个原始多候选；显式餐厅优先、缺失餐厅默认BUALUANG，Q.B.D/LIAN TAI 套房可按同一预订主房基础码继续过滤。启动时同时校验Excel SHA、基础目录、0812纠偏知识、manifest与语义 指纹。2026-08-13 已将该 Catalog 接入 typed Layer 4 Context：Roomtype/Rate套餐独立解析、同 Tour Code 来源 聚合、套房继承、公司级缺价和 canonical DecisionInput SHADOW 链均已实现。后续产品修订已移除当前订单/历史任务查询， 并把普通 LianTai 改为同时输出 FIT/GROUP options。Layer 6现只做等值/必填/证据校验，Layer 5 Candidate已承载早餐字段；Parsing Agent最终Layer3 handoff与当前附件文件名型Rooming resolver均已由后续任务完成。

Recently Completed

• 2026-08-13：按用户授权扩展 BR00 本地开发旁路：仅在 DEV + VITE_ENABLE_BR00_PROTOTYPE=true 下，匿名访问正式 /reservation/*、/debug/*、/system/* 不再受前端路由守卫、401 登录跳转、菜单和按钮权限拦截，并提供只读开发身份/酒店/导航上下文；不伪造 token、不绕过后端鉴权，生产构建不启用。默认与带开关两组前端均为 38 files/321 tests，typecheck、lint、production build 通过；浏览器确认正式订单及任务详情停留原路由，当前数据 404 是 5174 未连接后端 API。

• 2026-08-13：任务详情 Room Information 已新增“早餐餐厅”下拉字段，位置紧跟“是否含早餐”；选项固定为 BUALUANG、LEELA，确认时按共享字段白名单保存合法选择，Rate Code 只负责提供默认值。前端 38 个测试文件/320 项、typecheck、lint、production build 通过；后端主代码编译通过，后端 JUnit 仍受工作区既有 Layer 4 测试夹具与当前 DTO 不匹配阻塞。

• 2026-08-13：完成 Layer 5 Booking Business Agent v1.0 离线正式化：权威规则/ADR、最小 Agent 输入、完整 CandidateDecisionV2、全量 Agent 调用、Layer 6 校验、独立中文 Main Prompt、24成员 HOLD Skill、3组golden与 46项矩阵均落地。后端全量882 tests 0 failures/errors、9 skipped，Python包测试3/3及确定性打包/Schema一致性 通过；未连接真实数据库/Provider，未发布Skill/Profile，未接V4 writer/PMS/Opera。

• 2026-08-13：完成 V2 Run 关联与版本化 Layer 1–7 Trace Snapshot：AgentBus SHADOW 同时保留 processing_run_id 与 dispatch_run_id，并以 replay trace context 绑定 V2 编排；Trace stage additive 扩展为 booking-layer-trace-snapshot-v2，正式回放写入 Layer 1–6 的真实安全裁剪 input/output、状态、issues/evidence 与契约版本。Layer 1/2 标记 V1_BRIDGE、Layer 3 标记 V1_TO_V2_BRIDGE、Layer 4–6 标记 NATIVE_V2；Layer 7 仅保留 LAYER7_TRACE_RESERVED 占位，不采集确认投影或人工动作。聚焦 AgentBus/V2/Trace 测试通过，前端 320 tests/typecheck/lint/build 通过；后端全量当前 880 tests、2 failures、0 errors、9 skipped，失败为工作区既有 Layer 4 架构断言和 Reservation V4 夹具响应码，不涉及本切片。

• 2026-08-13：按用户要求取消本地 BR00 原型的登录账号密码：仅当 DEV + VITE_ENABLE_BR00_PROTOTYPE=true 时，/ 与 /login 自动进入 /prototype/br00。该 checkpoint 后续已被同日“正式页面开发态前端鉴权旁路”扩展；生产鉴权和后端鉴权仍保持不变。

• 2026-08-13：完成 Layer 4 Context + Rate/Room Resolver V2：DecisionContextV2.order_contexts[]固定输出来源 单元/住期/房型/数量/价格、独立Roomtype、规则集、逐房型与Tour Code级原子Rate/早餐套餐、当前订单/历史 查询状态及Catalog审计hash；同Tour Code跨scope聚合，未知/多候选/删除/冲突fail closed。仅缺槽位时按 hotel_id + group_code查询一次完整事实，无20条截断且不回填来源/判断生命周期。Booking v2确定性入口已 SHADOW接线并复用唯一canonical输入；focused与最新后端全量871 tests均0 failures/errors、9 skipped。 当时尚待的Layer5 Candidate早餐字段和Layer6等值/生命周期校验已由后续Layer5离线任务补齐；Parsing Agent 最终合并handoff仍待后续，未调用PMS/Opera。 该条为首个checkpoint历史记录；后续修订已删除数据库查询/生命周期职责、取消deleted-label身份并改为双Rate options。

• 2026-08-12：将最终 room&rate 0812.xlsx 的公司/Type/邮件房型/Roomtype/基础RATE CODE/早餐/含早餐公式/价格写入项目有效映射：新增确定性生成器、rate-room-effective-mapping-v20260812 JSON/manifest、不可变Snapshot、启动Loader/Validator与查询端口。按邮件公司＋房量＋房型＋价格查询；4间FIT、5间Group，Q.B.D固定Group&FIT，普通LIAN TAI FIT切换LIANTAI ONLINE/DY；餐厅缺失默认BUALUANG，QBD/LIAN TAI套房支持主房Rate继承过滤。213行/163场景中原始136个唯一、27个原始多候选。该checkpoint当时未接Layer4；已由2026-08-13后续任务接入，Layer6仍待完成。

• 2026-08-12：按用户反馈将订单内任务卡统一改为按卡片活动时间升序展示；新增 WorkspaceTaskCard.activityAt 与共享排序函数，原型 fixture、正式适配器、V4 timeline fallback 和任务卡序列均同步；订单详情卡片改为单列纵向布局。37 个测试文件/313 项、typecheck、lint、build 通过；1440/375 浏览器确认最早卡片在最上且无横向溢出。

• 2026-08-12：按用户反馈将 BR00 与正式订单根页从桌面双列改为单列纵向订单卡片流，继续复用订单卡片内容与待办式信息密度；1440/375 浏览器实看均确认卡片纵向排列且无横向溢出，前端 36 个测试文件/310 项、typecheck、lint、build 通过。

• 2026-08-12：完成 AI RSVN BR00「订单 → 处理记录 → 任务卡」前端工作台：BR00 零 API fixture、统一展示模型、订单根页/详情/卡片详情、我的待办、待归属消息、S10/S99 消息通知、正式 /reservation/* 适配器与旧入口兼容路由均已落地；来源邮件展示卡不计入任务数量，正式待归属页使用 order-tasks?unassigned_only=true 既有筛选并保留 additive task-card/processing-record projection 接口回退。浏览器 375/768/1024/1440 均无横向溢出；前端 36 个测试文件/310 项、typecheck、lint、production build 通过。原型与正式页面均未触发 PMS、Opera、AgentBus、SuperAgent 或外部 Provider，后端 additive projection 尚待后续接入。

• 2026-08-12：完成 Layer 3 CP4 内部运行链接线：双入口 SourceMessage、公共 Parser、完整 Current/History、evidence/request、durable execution、fake worker、strict validation、local merger、八数组 Layer3、兼容投影和 Context 均闭环；V5/V6/V30 事务与迁移边界、幂等和失败路径通过测试。定向 Java 233、排除两组 CP6 旧测试后的主流程 Java 782、Agent 22、Python 50 均通过。真实 Provider/scheduler/Business Agent/PMS/Opera 未调用，默认/production继续关闭。

• 2026-08-12：完成获批非生产PostgreSQL基础设施Gate：严格V001共存门禁后应用V1–V6，真实Spring重启、 lease/fencing和双连接池并发claim通过；修复PgJDBC Instant时间绑定。PG smoke 1/1、repository 7/7、 主流程Java 789均0 failures/errors；合成数据清零。MySQL V30、Provider、PMS/Opera未调用。

• 2026-08-12：完成Layer 3 CP3专属SuperAgent Adapter：独立properties/key/wrapper、无Trace Profile/version栅栏、有界executor/deadline/UTF-8限制与安全审计均通过mocked transport；CP1–CP3＋共享transport Java 119/119、Agent 22/22、Python 50/50。默认/production关闭，未调用真实Provider或接主链，runtime继续HOLD。

• 2026-08-12：完成Layer 3 CP2 durable execution：V5 execution/artifact DDL、幂等repository、lease/fencing/CAS、retry/backoff、无Spring worker与local handler。CP1+CP2 Java 83/83、Agent 22/22、Python 50/50通过；未连真实DB/Provider/主链，不保存request正文或raw answer，runtime继续HOLD。

• 2026-08-12：完成 Parsing Agent v1 未接线结果接收器：新增冻结 result Java records、严格 JSON decoder 与 canonical/intrinsic tests；没有 Spring bean、Port、request/evidence builder、Merger、配置、DDL 或外部调用。专项 10/10、相关 Java focused 34/34、Agent 21/21、Python 49/49 通过；后端全量 693 tests 的 6 个 error 全部为两组旧 v0.2 测试引用已删除资产，已登记为迁移债务而未恢复旧 Trace 契约。

• 2026-08-11：完成Parsing Agent v1.0发布前架构纠错：Schema/Skill/Fixture/校验器原地删除Trace/部门/业务分类输出并改为中立structured_mentions[]，Main Prompt压缩为中文四组且继续不打包；ADR与Booking Agent边界改为Layer 5判断Trace/linked action和可空部门候选。15成员确定性包SHA-256 7694f5019cb681a9987a2a422a6855bcf145bf30729f291499e8887e5326c6ea；Agent 21/21、Python 49/49、Parser focused 29/29通过。未修改Java、前端或运行时接线。

• 2026-08-11：完成 QBD/LianTai 真实样本 Parser 修正：共享 Core 统一封装并严格校验 Profile 原始材料；QBD WAITING 非空原文进入 agent_materials 且永不生成价格，修改物理行日期/晚数随一致的房型数量划线状态进入 BEFORE/AFTER；LianTai G/I 及 D 残余原文进入 materials。批准样本 QBD 114 facts/4 materials、LianTai 70 facts/6 materials；扩大后的 Parser 聚焦＋真实样本 63 个用例加载、58 执行、5 个旧 opt-in 跳过，0 failures/errors。全量 suite 另被范围外旧 Agent v0.2 测试引用的已删除 fixture/schema 阻断，本期未修改 Agent。

• 2026-08-11：用户澄清 QBD 真实样本规则：WAITING 等待确认：อักษรดำ 列全部整格原样保留，后续作为只读备注呈现，绝不解释为 SOURCE_PRICE；Update 中划线物理明细是 BEFORE、未划线物理明细是 AFTER，双方日期、房型、数量照常确定性提取。撤回此前“价格绑定”和“日期共用”建议，确认当前 Parser 还需修正 WAITING materials 与 BEFORE 日期/晚数 facts；本轮未修改代码。

• 2026-08-11：完成用户提供的 QBD/LianTai 真实样本只读验收：渲染全部工作表，公共 Parser 对三份工作簿双次回放稳定；LianTai 两份样本均为 70 facts 且业务事实一致，QBD 为 108 facts/6 materials，BF/Q10 主路径通过；LianTai approved August current opt-in 1/1 与 focused 50/50 通过。同时发现 LianTai G/I 六个 pending hints 和 QBD WAITING 四格备注未进入公共 materials；后续用户澄清又确认 QBD BEFORE 日期/晚数分类缺口，故未判为真实样本验收通过，不修改 Parser 代码。

• 2026-08-11：完成 QBD＋普通 LianTai Parsing Agent v1.0 离线交付及包装边界纠正：共享 Skill/Profile/reference 升至v1.0，独立 Main Prompt 改为中文 v1.0、从Skill读取链和.skill归档排除；建立闭合Schema、Current/History/evidence边界、员工展示信息、附件action优先级、材料闭环、双渠道fixture与27项矩阵。15成员确定性包、16个Agent tests及Python全套44/44通过。未修改 Parser/Core/Profile/DTO、Merger、运行时或外部Provider。

• 2026-08-11：完成 QBD＋普通 LianTai Parser-only 整体合并：新增 fixed-channel-parser-fact-material-v1 Java DTO、共享 fact/material Core、稳定 fact/material/target/location 身份和 SUCCESS/FAILED 门禁；双渠道默认 parse 与共享入口统一返回新契约，完整来源房型保留 BF/Q10，Q10 不再误判价格，缺失不伪造材料。当前 assembler 仅通过显式 parseLegacy 兼容旧链；Provider、Agent/merge、Recovery runtime、Rate/Room、PMS/Opera均未启用。新契约 8/8、双渠道/共享 Parser 回归 50/50、旧下游兼容 27/27、后端全量 678 tests（0 failures/errors、6 skipped）通过；5 个真实样本 opt-in 因文件不在工作区而跳过，不能计为本次真实样本证据。

• 2026-08-11：用户冻结 QBD/普通 LianTai Parser 的 Fact-or-Material v1 契约：运行状态仅 SUCCESS/FAILED，业务输出仅 facts/agent materials；公共事实限定十类，完整来源房型保留 BF/Q10，BF 决定早餐，GROUP_IN/来源Rate Code/独立Q10 qualifier删除。ADR-008与正式契约已建立，旧字段Recovery边界明确转为迁移历史；冻结当轮未修改代码，后续同日按上一条完成 Parser-only 实现。

• 2026-08-11：用户补充确认普通LianTai邮件正文规则：固定问候/标题、重复提醒、联系人和公司页脚全部忽略；非模板正文按Trace/普通备注/人工复核分流；正文无团号的普通内容保持邮件级备注，点名团号但不能唯一对应同团号有底色目标时直接人工。规则已写入CR与项目记忆，本轮按用户要求未修改Parsing Agent资产或程序，v1.0由后续独立对话承接。

• 2026-08-11：本期固定渠道范围已正式收缩为 QBD 与普通 LianTai；sender/profile/catalog、旧 Parser 样本、Agent 配置、验收基线和规划资料已同步按两渠道裁剪。其他 sender 统一进入 unknown/out-of-scope 通知路径；通用 booking_type=FIT 业务规则保留。后端 670 tests（0 failures/errors、6 skipped）、前端 301 tests/lint/build 通过。

• 2026-08-11：修复 BR00 FIT Update 布局回归：Room Information 恢复为单一“预订信息”卡，移除误加的“当前订单 / 邮件目标”、邮件前后变化和系统状态链；Basic Information、Update Booking、邮件原文以及 Group Code、Confirmation Number、Name 1/2、日期段等字段保持完整。演示草稿 schema 升至 V3，旧 V2 缓存不再恢复错误布局；前端 302 tests/typecheck/lint/build 与 5174 浏览器实看通过。

• 2026-08-11：普通 LianTai 已接入 QBD 共用 fixed-channel Core 与统一入口；完成August 9列/A-D-G底色门禁、共享九类source-room、G/I Trace/普通备注分流、FO+HSK、EffectiveFactView全下游接线和安全备注页面。后端672 tests、前端300 tests/build/lint、16个Agent包测试与三份真实工作簿opt-in验收通过；Provider保持HOLD。

• 2026-08-10：QBD 确定性 Parser checkpoint 与真实样本基础已成形；Rate/Room Directory Foundation 已完成。

• 2026-08-10：用户确认 Layer 3 字段 Recovery 完整边界、Layer 4 RateRoomResolver 位置与 QBD F 列完全忽略规则。

• 2026-08-10：QBD Parser 已按共用契约补齐 18 个 semantic role、稳定 field/target/evidence 身份、唯一 reason code、JCS observation hash、严格 unresolved 投影与事实来源关联；source_room_type 为 Layer 3 唯一房型名。

• 2026-08-10：共享 QbdStayDateRules、QbdEffectiveDependencyResolver 与 QbdCurrentFactProjector 已落地；Recovery 可按 Validator → dependency resolver → projector 重建 GROUP IN/CXL/跨月/nights，不复制 Parser grammar。

• 2026-08-10：Parser/Recovery/Assembler focused tests、下游编排回归、后端 Maven 全量测试和两份真实 QBD XLSX opt-in 验收通过。

• 2026-08-10：Recovery DTO/schema、Builder、provider-neutral Port、PatchValidator、EffectiveFactAssembler、Coordinator 与 apply-once store interface 已完成；结构性 review 不调用字段 Agent，accepted patch 复用唯一 dependency resolver/projector。

• 2026-08-10：QBD Recovery .skill 已确定性打包并通过 archive check、静态安全校验、5 个 Python package tests；archive SHA-256 75fa2c64d8155bb9f6426caee3d590351f7be1b64630e73b5ebba9fd9962c74e。

• 2026-08-10：移除所有当前权威 Rate/Room 规则中的渠道 Group/FIT 例外；QBD 单一订单事实按 4/5 间判定，多活动 segment 在业务合并前保持 null。目录、Skill、fixtures、生成/加载校验和测试已同步。

• 2026-08-10：策略纠偏回归通过：Python 14/14、Java focused 18/18、Maven full 528 tests（0 failures、0 errors、3 skipped），Skill source/package read-only check 通过。

• 2026-08-11：用户最终确认 Name of Group / Group Name / Tour Code / Group Code 只归一为 group_code，不得再回填 Name；FIT 与 GROUP 均展示独立 Group Code、Name 1、Name 2，只有一个真实姓名时第二位为空。BR00 原型与正式 V4 Room Information 已同步，legacy 身份字段只保留兼容读取；前端 301 tests/typecheck/lint/build、后端 672 tests（0 failures/errors、6 skipped）及浏览器实看通过。

• 2026-08-10：BR00 本地任务原型完成蓝白双目录时间线重设计：根页只保留需处理任务和提示任务，卡片按收到时间倒序并可进入详情；详情保留 Basic Information、Room Information、邮件原文、FIT Confirmation Number 和分段 Nights。姓名展示规则已于 2026-08-11 按最新决定修正为独立双姓名位置。

• 2026-08-10：新增 dev/test-only AgentBus EML 回放：上传 EML 后生成并保存精确 agentbus-outlook-v1 frame，确认后以已授权酒店进入既有监听处理器并追踪 Booking PostgreSQL 或旧 SuperAgent dispatch；支持 PRESERVE_IDENTITY/FRESH_DELIVERY、7 天清理和回放安全审计，未模拟 WebSocket/PMS/Opera。

• 2026-08-10：BR00 本地原型已集成 AgentBus EML 回放入口和专用 /prototype/br00/agentbus-eml-replay 演示路由。该路由复用回放界面但仅使用内存 fixture，所有上传、确认和结果均为浏览器内模拟，不调用 replay API、AgentBus、PMS、Opera 或创建 SourceMessage；原 /debug/agentbus-eml-replay 权限与环境开关不变。前端 294 tests、lint、生产构建和本地浏览器检查通过。

• 2026-08-10：本地工作台品牌统一为 AI RSVN，并新增蓝白共享 shell/menu：需处理任务与提示任务仍是仅有的两个任务目录，AgentBus EML 全流程回放位于独立工具组；根任务、任务详情和回放页保持连续菜单上下文。任务卡实际点击可进入保留 Basic Information、Room Information 与邮件原文的详情；前端 296 tests、lint、生产构建和浏览器流转检查通过。

• 2026-08-10：新增默认关闭的 SuperAgentFieldRecoveryAdapter：手工 EML 在 Parser 后以独立有界 executor 等待完整 SSE，严格解析 JSON-only PatchSet；PostgreSQL V3 保存 invocation/hash/Provider 安全元数据/PatchSet/Assembly，Coordinator 本地组装后持久化 Recovery/EffectiveFactView artifacts。

• 2026-08-10：Recovery Adapter、配置、store 控制流与 orchestrator 来源边界测试通过；后端 Maven 全量 596 tests（0 failures、0 errors、3 skipped）。该实现 checkpoint 当时尚未调用真实 SuperAgent，也未在本机执行 PostgreSQL migration smoke。

• 2026-08-10：按真实 Open Agent API 文档修正 identity/routing：df_open_... 外部应用策略选择 Profile，Recovery subject 由 source message hash 派生；新增通用 client factory 与 Recovery 独立 key wrapper，为未来 Booking Business Agent 保留 per-agent 扩展缝。compile 与相关聚焦测试通过，真实 key 未落盘。

• 2026-08-10：真实合成 Open API smoke 已通过 session、无 Trace SSE、core message.final、end 与 run status success；发现并修复当前平台强制 CSRF、解析外部应用禁用 Trace及本地 parser 只认 Trace 完成事件的问题。后端全量 598 tests（0 failures、0 errors、3 skipped），key/raw answer 未落盘。

• 2026-08-10：Booking Business Agent 已迁移到 booking.agent.open-api.* 专用 client wrapper/Secret， 用 source message SHA-256 派生 subject，默认/生产关闭；focused 10 / backend full 606 tests 通过。真实专用 token session 返回 200，但 Trace/no-Trace stream 均因 Profile API exposure disabled 返回 403，未产生成功 run。

• 2026-08-11：用户启用 Business Profile 外部 API/流式接口并发布后，no-Trace 合成 transport smoke 通过： session/stream 200、非空 message.final、end、无 failure event、run success；resolved Profile 为 85ab8334-4e1c-4716-8ec0-9c3c099cec9b，版本为 1711d4ed-8d0d-46fa-9d1f-4bb2d61fde23。Prompt 2 是占位符，本次不计为 CandidateDecision 验收； key/raw answer 未写入项目文件或测试输出。

• 2026-08-11：AgentBus EML 回放升级为“运行总览 + 14 阶段轨迹 + 单阶段检查器”。新增 V29 回放快照、 PostgreSQL V4 Booking Agent invocation audit、酒店/SourceMessage/run 三重关联的 trace index/detail API、 JSON Tree/Raw/搜索/复制/下载、Agent raw/normalized/diff/public trace，以及 QBD deterministic、Agent fallback、 Parser failure 三组零网络本地 fixture。Recovery 始终显示策略跳过，Rate/Room 未接线明确不可用；前后端全量 自动化（后端 625 tests，0 failures/errors、3 skipped；前端 300 tests）、生产构建和 375/768/1024/1440 浏览器验收通过。

• 2026-08-17：修复本地 AgentBus EML 回放启动链：专用脚本显式启动 local,local-replay、配置 Vite API proxy、 复用既有 dev-only 身份/酒店上下文并移除 Spring Boot 3.5 不接受的 profile include。隔离环境 8082/5178 已完成 合成 EML 选择与 preview，生成 replay 2089174776450777089；停在确认前，未执行下游。前端 45 files/347 tests 与 typecheck 通过；production 和业务规则未变。

• 2026-08-17：获批后在独立 8083/5179、H2 和非生产 PostgreSQL 环境重放一封真实 QBD EML。replay 2089203656347848706 的 SourceMessage=CAPTURED，邮件接入和材料预处理成功；真实 Parsing Agent 首次调用 返回完整且身份匹配的 JSON，但 3 个展示项分别拼接 2/4/3 个原文证据片段，违反“一项精确对应一个 evidence” 契约，Layer3 以 SOURCE_TEXT_MISMATCH fail-closed，未进入 Layer4、Booking Agent 或 Layer6。另确认当前平台 已完成 run 的读取结果截断、重复 POST 不能安全恢复，以及严格下游异常会回滚安全失败 artifact 并只留下通用 invariant 错误。诊断环境已停止，未改代码/Prompt/Skill/数据库结构/生产配置，未调用 PMS/Opera。

2026-08-18 真实 replay：Parsing 401 与 Booking active-run 冲突

用户提供的 lifecycle V2（replay 2089557784945102850、processing run booking-v2-7cfc5fc4-c0e2-4b85-9c9b-f58c35b930ae）已只读核实：Parsing Agent 三次 attempt 均在 create_session 收到 HTTP 401 Invalid Open API key，没有创建 session/run，最终以 AGENT_RETRY_EXHAUSTED 收口。这个安全码表示 durable attempt 预算耗尽，是三次鉴权失败的汇总状态，不是 EML 或确定性 Parser 错误。

Layer 4 仍真实完成 CONTEXT_ASSEMBLY 与 RATE_ROOM_RESOLUTION；其输入的 Layer 3 结果为 PARTIAL，保留114条 确定性 facts、4条 material observations 和153条 evidence refs。因此本次 AGENT_RETRY_EXHAUSTED 没有阻断 Layer 4， 但也没有产生可供 Layer 5 使用的完整 Parsing Agent handoff。

Layer 5 第一次 Booking attempt 运行约124秒后以 BOOKING_AGENT_DEADLINE_EXCEEDED 结束；Provider 端的原 run 仍活跃， 第二次 attempt 随后因同一 thread active run 返回 HTTP 409，最终安全码为 BOOKING_AGENT_PROVIDER_HTTP_REJECTED。 所以 VALIDATION 是 UPSTREAM_REAL_AGENT_FAILED 被阻断，而非 Layer 6 自身业务校验失败。详见 50-evidence/topics/2026-08-18-real-replay-layer3-auth-layer5-active-run.md。

2026-08-20 最新真实 EML 结果

Replay 2090071005565255681 已完成当前业务主链：Booking run=AWAITING_CONFIRMATION，Layer 5真实Agent一次成功，Layer 6=VALID，9个Update目标与1个Allotment整块取消动作均通过，无blocker/review item。独立RATE_ROOM_RESOLUTION行显示AUTHORITATIVE_RATE_ROOM_RESOLVER_NOT_WIRED是debug lifecycle reader旧占位逻辑误报；真实Rate/Room结果已在Context中生成。详情见50-evidence/topics/2026-08-20-real-eml-success-rate-room-trace-misreport.md。

后续LianTai replay 2090286118062755842也正常完成技术流程，但Layer 6为REVIEW_REQUIRED：5个目标的房型全部匹配，Rate Code全部未解析，并有2个目标缺到离日期，合计14条人工处理项。该结果证明Rate/Room日志修复不能仅以“Context产物存在”判定成功，必须查看实际booking target的resolution状态。详情见50-evidence/topics/2026-08-20-liantai-real-eml-review-required.md。

In Progress

• CP4 v1 内部主链已完成；CP5测试平台Profile/Skill/Prompt及真实Provider契约smoke已完成。legacy默认路径仍 保留parseLegacy、Layer3 v2、RecoveryRequest/PatchSet；CP6前不删除。不得把受控live smoke误报为部署中的 自动Agent worker或production运行。
• SourceMessage loader、公共Parser、latest V2 projection与worker core已接通；PostgreSQL V1–V6真实smoke及 CP5 external app/Profile/Main Prompt/Skill绑定均已通过。部署Secret注入、worker启用、完整AgentBus/PG双Agent smoke、MySQL V30（如适用）和告警/人工恢复runbook仍未完成。Layer3 required-fact旧门禁已移除，不再是Gate。
• live FieldRecoveryAgentPort Adapter 与数据库 store 已实现，真实 transport/Profile routing 已 smoke； 该旧链在 ADR-008 迁移评审前暂停继续联调，保持默认/生产关闭。不得把既有 transport smoke、代码完成或 旧 .skill 误报为新 Fact-or-Material Agent/merge 已实现。
• Booking Business Agent已替换占位Prompt并绑定正式Skill/Profile v7；真实CandidateDecisionV2经本地严格 decoder/Layer6验证通过。尚需部署级审计、Risk fail-closed与完整入站主链smoke，不能把单次合成契约结果 误报为自动业务生产放行。
• 旧Business invocation audit/trace/PostgreSQL V4曾按ADR-006允许合规raw answer；ADR-015规定新V2 durable attempt无条件省略raw answer，只留hash/omission reason及安全Provider metadata。当前完整链仍需真实 PostgreSQL V1–V12与MySQL V1–V34 smoke。
• Parser/RateRoom/V4 相关文件仍存在大量并行在途修改，必须继续按文件 ownership 避免覆盖。
• Layer 4 Context/Resolver及Booking v2入口已接；Candidate与Layer4套餐/来源room逐字段契约已收口。Layer 6 不查询订单历史，正式归属、revision和任务顺序由ADR-016独立projector/V4本地命令负责。V2→V4 writer与页面 已本地实现；真实Profile/Secret/PG V12/MySQL V34和发布Gate仍未完成，Skill继续HOLD。
• Roomtype authority 当前为 schema v4 Catalog Snapshot：48条活动规则全部唯一，另2个基础目录标签无活动映射且不保存删除身份， 统一输出MAPPING_NOT_FOUND。五条0813修正已落地；精确ONE-BEDROOM-SUITE-DBL→RM2不推广到其他含DBL标签。
• 2026-08-12 已更新离线业务交付表 room&rate 0812.xlsx：QBD 全部34条有效候选行的Type统一为Group&FIT。其A:H 213条映射和213个含早餐公式现已生成项目内effective catalog并通过exact-hash重放；Layer4已于2026-08-13接入，但Excel/配置和本次接线仍不代表Layer6或Skill已发布。
• TYPE OF ROOM → Roomtype 与 Company + TYPE OF ROOM + price → Rate Code 是独立函数；独立 Rate Code projection 已冻结并在本次 Roomtype 更新中保持零漂移。Layer 3 Parser 继续保存来源事实，不输出 canonical Roomtype。
• Layer 4 Resolver 已应用确认的规则集：QBD=Group&FIT；普通 LianTai FIT=LIANTAI ONLINE/DY / FIT、 Group=LIAN TAI / Group，且没有新增 LianTai-FIT 渠道路由。
• 旧Recovery IN_PROGRESS invocation仍没有fencing自动接管；Booking V2 execution已具备lease/fencing takeover， 新attempt开始会安全关闭同execution较低attempt的stale IN_PROGRESS audit。两条runtime不得混用。

Next Recommended Steps

1. 在指定非生产部署通过Secret管理注入两个独立key，先保持全部worker关闭完成PG V1–V12、MySQL V1–V34和 当前Profile/version复核，再按批准顺序开启选定provider/worker，重启后执行完整 AgentBus→SourceMessage→Parsing→Layer3→Layer4→Booking→Layer6→V4 projection smoke；production继续关闭。
2. 暂停新增 Field Recovery Provider/PatchSet/PostgreSQL V3 联调；旧开关继续默认/生产关闭。先在 ADR-008 迁移计划中确认哪些资产删除、哪些审计能力复用，再决定是否还需要任何旧链 smoke。
3. Booking Business历史测试Profile/Prompt/Skill/Candidate live已完成；部署前轮换并由Secret管理注入专用key， 重新核对resolved Profile/version，再完成QBD/LianTai八场景、Risk fail-closed、V11 Agent审计、V12投影和重启恢复smoke； production继续强制关闭。
4. 历史PG V1–V6基础设施Gate已完成；当前V11 Agent execution和V12 projection execution仍须在获批非生产PG重跑。 MySQL V1–V34、跨库receipt重试、告警和人工重放runbook继续独立完成；不得在WebSocket callback等待Provider。
5. Parsing Agent最终Layer3 handoff、当前附件Rooming resolver和V2→V4正式工作台均已本地完成；在非生产数据库 补跑New+Trace+Rooming、混合Validation、Allotment、changed revision、重复投递和Tour Code rebind synthetic E2E。
6. 自动业务路径只认真实Layer3解析问题、Layer5业务判断与Layer6按业务类型的字段完整性校验；不得恢复或伪造 Layer3 required-fact目录。CP6须在观察期与回滚演练后另行授权。
7. 在配置 Booking PostgreSQL 的 dev/test 环境执行 V4 migration 与真实 AgentBus replay trace smoke，核对 artifact linkage、Agent audit、7 天清理和大 payload 懒加载；不得借此启用 PMS/Opera。

Open Questions / Blockers

• Parser v1、Parsing Agent v1.0契约、CP4内部接线、历史CP5测试平台绑定和V2→V4本地实现均已完成；历史PG V1–V6 Gate已通过，但当前PG V1–V12/MySQL V1–V34 Gate尚未执行。自动运行放行待决项是当前Profile/version、 部署Secret/开关/重启、完整主链与projection synthetic smoke、告警/人工恢复runbook；CP6旧Recovery删除顺序 继续独立审批。业务required-fact不再是Layer3运行或发布Gate。
• LianTai本地实现已完成；本期固定渠道范围为QBD与LianTai。
• LianTai邮件正文业务规则已写入v1.0 Skill reference/Schema/Fixture；独立中文Main Prompt不打包；Merger、 final Layer3 handoff与Booking Context已接通，Layer5离线业务已验收；当前Profile复核和自动业务运行放行仍是 后续部署Gate。
• Recovery Base URL 和 API Key 曾用于旧链 transport smoke，key 未落盘；ADR-008 后不再推进完整 Recovery Skill/PatchSet 验收，除非迁移评审明确保留对应能力并重新取得发布授权。
• Booking Business测试Profile已绑定正式Prompt与Skill并完成真实CandidateDecisionV2 smoke；key未落盘且 正式部署前需轮换。自动worker、production与任何外部业务写入仍未授权。
• 历史证据中曾有获批非生产PostgreSQL用于Layer3 V1–V6基础设施smoke；当前进程没有对应连接。该结果不自动 覆盖旧Recovery V3或Booking V11业务级端到端，也不授权复用连接或启动对应Provider。
• 唯一共用 Discussion Draft 已作为 QBD Implementation Baseline 收口，SHA-256 faedb8b78ac7f752dc4ccaaf49abf542a75818e87d9494748e58b5dff48e4c56；若文件变化需双方重新核对 hash。
• 冻结源 Excel REVISE- RATE CODE_8.7 更新 .xlsx 当前不在本机可检索路径；不影响本次 policy-only 校验，但恢复后必须重跑 source generator --check 才能形成完整来源复现证据。

Risky Areas

• ADR-008 Parser 公共边界已经独立迁移；剩余风险集中在 assembler/Layer3 v2/Recovery/merge。删除 parseLegacy 前必须先冻结 Agent/merge 契约并重跑双渠道新旧兼容测试，禁止把旧状态重新暴露到 Parser 结果。
• BookingContracts.java、BookingContractAssembler.java、QBD Parser 与 Recovery package 是共享工作树热点。
• FixedChannelSourceRoomParser、FixedChannelCurrentFactProjector、Layer3 v2 common schema与Parsing Agent profile是QBD/LianTai共享热点，任何渠道改动必须做双渠道回归。
• 旧 V4 SuperAgent task-results 是业务结果入站，禁止复用为字段 Recovery transport。
• booking.field-recovery.enabled 默认 false，production profile 强制 false；解除前必须同时完成完整 Recovery contract、部署 Secret、V3 smoke、审计与 stale invocation 处置。
• Parser Agent 与 Booking Business Agent 必须使用不同外部应用/token；两个专用 wrapper 已落地， 新增 Agent 仍只能复用 client factory，不能回退或复制任一现有 key。
• AgentBus EML 回放依赖公开可读取 OSS、agentbus.capture.enabled=true 及一个可用下游分支；只有 local/dev/test profile 显式开启开关时可见，生产强制不注册入口。
• Trace detail 可在 SYSTEM_DEBUG_EML_RUN 下读取邮件正文、附件地址和合规 Provider 最终回答；必须保持酒店/ SourceMessage/run 关联校验、7 天保留期与 Secret/二进制/隐藏推理永久拒绝规则。

Last Updated

2026-08-21

2026-09-16 OHIP CP3

本地后台登记/持久状态/恢复/续办/受限查询接口及三语页面已实现并通过验证（后端全量及最终102例复测、前端310例及最终94例复测）。最新用户规则：只外发Excel、UPDATE绝对最终房数、允许专用Oracle合成数据测试。本轮经明确授权使用1个子智能体仅开发测试Excel校验，已结束，不继续派生。线上仍0.6.0/111项，附件未上线；真实办理默认关闭。后续平台发布已获用户明确确认，release分支integration/booking-release-codex（60e89b4）已推送，0.8.0/118/13、真实PostgreSQL迁移及全量race/原生打包验证通过。当前本机无实际ACK/镜像/部署数据库入口，不能以push宣称上线；下一步通过实际部署通道上线，再补真实字段验证及Adapter/UAT。