Wyndham-RSVN-0918/PROJECT_STATE.md

TH Hotel Simple 项目当前状态

2026-09-08本期范围：通用发件人处理本期不做，已从有效需求和待办撤下；现有5178功能进入测试与修改，上线准备在决定上线时安排。 2026-09-08更新：当前正式项目为Wyndham-RSVN-0908，最新状态以项目状态为准。 AgentBus统一处理记录与通知专用测试已实现并加载5178/8082，配置和既有历史保留；前端150项、后端995项通过，5项显式外部验收跳过。 OPFIT真实EML现已在5178单次运行成功：1.22秒、1条其他通知、零Agent/预订任务；待办进入刷新已修复并验证，通知未确认。 本文件下方2026-08-18的分支、阶段和后续步骤为历史快照，不是当前实施指令。

项	内容
最近更新	2026-08-18
当前分支	feature/booking-v01-safe-checkpoint
当前阶段	Layer3/4到Booking Agent V2 durable及M012全生命周期日志已本地完成；Parsing/Booking主线强制include_trace=true。ADR-019 compact已由真实v10 replay验证输入减少81.8%。ADR-020同一Provider run续接及首个session-only PostgreSQL checkpoint缺陷已本地修复并加载V12测试环境；42项相邻回归和真实PG read-only完整SQL计划通过。真实唯一run/晚到final仍待新replay，默认/production Agent、provider、worker仍关闭。
当前重点	复用同一EML新建replay，验收Parsing只创建一个run、4分钟后仍续接、完整events/final进入原生命周期并继续Layer3–6，以及Booking实际身份/Candidate。不得把本地修复、旧失败replay或门禁ready当成真实全链成功。Booking约14.5万字符输入和远端PG空闲连接关闭告警是后续独立风险；production及PMS/Opera均另行授权。

2026-08-18 V12 session checkpoint缺陷已修复并加载

Replay 2089390064358281217曾因首个runId为空时PostgreSQL无法推断参数类型而在Provider run创建前失败。当前已为 nullable run guard显式声明VARCHAR类型，并新增session-only回归；repository/worker/handler/Layer3 continuation/ SuperAgent adapter共42项通过，真实PG read-only完整UPDATE执行计划通过。五类活动队列为0后8082已加载修复， 8082/5178、HOTEL-LOCAL-REPLAY、V12/RC6/PG/V2/strict均通过；旧replay未重放。下一步直接用同一EML新建回放。

2026-08-18 Parsing Agent同一Provider Run续接

旧的4分钟硬中止和重新派单已改为4分钟只提示“Agent仍在处理”，默认总等待上限15分钟。首次派单取得的session/run会 立即按既有lease/fence保存；连接中断或worker重启后只恢复原run的snapshot/events，不重新POST邮件。等待期间周期续租， 明确失败/取消、总超时或无法绑定原run的409才形成Parser-only复核。生命周期把活动Parsing显示为RUNNING，V13完整公开 返回记录和严格final门槛不变。109项相关测试通过，没有新DDL、Agent资产或业务规则变更。

8082/5178已加载Parsing V12与Booking RC6，H2 V34、PG V13、双Agent/V2/strict均ready，五项队列/活动状态为0，旧run 未重放。服务刷新中再次出现本地酒店身份变量遗漏，但在postflight阶段已恢复为HOTEL-LOCAL-REPLAY，未影响任务或数据。 本轮没有上传EML；真实单run续接、晚到final与Layer3–6仍待用户下一次回放。

2026-08-17 Parsing Agent V12 本地测试门禁刷新

用户确认最新版本为V12并提供内部version ID 95d2834a-7ddb-4ea7-85b0-35ca6e986c57。启动前Parsing、Booking、 projection三条队列、过期claim和活动processing run均为0；8082只在内存中把Parsing门禁从V10对齐V12，其他 酒店、PG、双Agent Key、Booking RC6、V2/Trace配置全部保留。H2 V34、PG V13无需迁移；8082/5178一致显示V12、 双Agent/V2/strict ready且配置缺项0，重启后队列仍为0。本次未执行平台探针、EML或Agent message，不能据此宣称 V12真实链路成功。

2026-08-17 Booking Agent替换Key测试运行时恢复

新Booking专用Key已通过create_session HTTP 200最小鉴权，只创建空session，未发送消息或触发Agent。三条队列和过期 claim均为0后，Key仅以内存注入并保留其他配置重启8082；8082/5178、HOTEL-LOCAL-REPLAY、H2 V34、PG V13、双Agent/ strict readiness及重启后三队列均通过，旧失败run没有重放。Key没有写入仓库或文档。

首次重启后发现当前进程仍显式覆盖历史v7。用户随后明确授权，现已只在本地测试进程内把门禁对齐RC6 b91686f4-...并再次安全重启；新Key、Parsing v10、PG和酒店身份均保留。8082/5178一致显示RC6及strict ready， PG V13和三队列复验通过。尚未发送Booking消息，因此实际resolved身份、事件和final仍待新replay证明。

2026-08-17 v10真实回放诊断

replay 2089351797160271873 已终态失败，总耗时约6分58秒。EML、SourceMessage、材料预处理和确定性Parser均已通过； Source Capture 的warning只是异步排队提示。Parsing实际收到25462字符/27524 bytes的compact输入，命中v10，9个目标、 114条Parser facts和4份materials完整，较旧151459 bytes减少约81.8%。

Parsing第一次run仍读取13项额外资产并超过本地约4分钟deadline；第二、第三次尝试因原thread仍有active run均收到409。 信息系统以AGENT_RETRY_EXHAUSTED安全收口，保留114条facts并继续Layer4；原SuperAgent run后来为success，但迟到final 没有被接回。随后Booking在创建session时收到401 Invalid Open API key，没有真正运行，Layer6因无Layer5结果阻断。 Lifecycle把Parser显示PENDING、Parsing显示0ms也与真实journal不符。本轮仅只读诊断和文档更新，未改代码、配置、数据库、 Agent资产、业务规则或PMS/Opera。

2026-08-17 Parsing Agent 精简交接与失败收口

项目内已新增 fixed-channel-parsing-agent-compact-input-v1：不截断Current/History，不遗漏Parser facts/materials， 但按target/物理行归组并移除长内部ID、hash及重复位置包装。Provider只看到当次有效的P/T/R/F/M/E短引用； decoder在内存中按类型翻译，SuperAgent公开events/final仍以原内容写入V13 journal，不保存第二份完整还原回答。

整份JSON/身份不可消费时形成Parser-only REVIEW_REQUIRED；身份可信后的未知短引用、来源或Parser权威问题只拒绝 受影响项。薄Layer3 assembler只形成统一事实结构，不做Layer4映射或Layer5任务判断。strict replay不再把已接住的 review升级为UPSTREAM_REAL_AGENT_FAILED。输入schema、Skill、Main Prompt、manifest、packager和v1.0离线包已同步； Java编译/63项聚焦相邻回归、23项Python包测试和离线包校验通过。真实旧请求只读离线投影由151212降至27127 bytes（-82.1%），9行/114 facts/4 materials完整。无DB、业务规则、生产开关或PMS/Opera变更。

SuperAgent后台Skill/Main Prompt已发布；最小身份探针确认Profile ea56cb01-72f0-4ef2-9a73-40cfae1abcd4当前路由到v10 version 3c42a5f4-799e-4f8b-897b-692c5e76c670并已取消探针run。本地8082已在三条durable队列均为0时加载新构建和 v10门禁；8082/5178均显示PG、双Agent、V2 authority、strict execution ready且无配置缺项。真实运行耗时和 Layer3–6结果仍待新replay证明；active-run迟到回收不在本次实现范围。

2026-08-17 Parsing Agent Validator 逐项验收

本地 response Validator 已从任一项失败即整份 INVALID_PROVIDER_RESULT 改为逐项验收。只有 request/message/version/Parser/fallback 身份不一致或严格 JSON 无法解码仍整份拒绝；其余按八类输出分别守 引用身份、Current来源和 Parser 不可覆盖。错误项及其依赖项被移除，其他已验收结果继续 Merger。多个登记证据 片段共同覆盖同一段 Current 原文时可以通过，不再要求展示项等于某一个 evidence 文本/sequence。

有拒绝项时，既有 validated artifact 保存净化结果与安全拒绝清单；无拒绝项保持原 payload。7类40项聚焦 回归全部通过；没有修改数据库结构、Agent Prompt/Skill/Profile、业务规则、production 开关或 PMS/Opera。 8082 已在无活动回放时沿用原测试参数刷新并加载新构建；后端和 5178 代理健康检查通过，PostgreSQL、双 Agent、 V2 authority、strict execution 全部 ready，配置缺项为 0。新真实 replay 已运行，但在 Agent result 返回前超时， 所以逐项 Validator 仍缺真实结果实证。

2026-08-17 AgentBus FRESH 回放 History 隔离

已确认最新真实 QBD 回放不是 Parser 或 SuperAgent 失败，而是 FRESH_DELIVERY 过去仍复用原邮件 conversation identity， 导致早期调试副本被当作 History，并因 changed duplicate 门禁在 Provider 调用前阻断。现已让每次 FRESH 回放同时使用 独立 message/conversation identity；PRESERVE_IDENTITY 不变。enqueue 失败也会保留安全稳定的 FIXED_CHANNEL_* 原因码，未知异常仍不暴露原文。

相关 16 项聚焦测试通过；8082 已沿用授权测试配置重启，5178 正常，PostgreSQL、双 Agent、V2 authority 与 strict execution 均显示 ready。随后新 replay 2089300151851950082 已实证隔离有效：SourceMessage为新件且非重复，Parser 成功并进入真实Provider attempt。当前后续阻断已转为Parsing Agent密钥三次HTTP 401；ready只表示配置已填写，不能 证明平台仍接受该密钥。

2026-08-17 新真实回放 Parsing 鉴权失败与 Journal 实证

replay 2089300151851950082 总耗时约83.9秒。Parsing三次都在SuperAgent创建session时收到原始响应 {"detail":"Invalid Open API key"}，因此不存在session/run、公开事件、Agent最终答案或思考过程；Layer4–6和Booking Agent未执行。V13 journal已按原顺序保存三次HTTP 401的时间、attempt和原文，说明日志功能正常捕获了平台实际返回。 下一步不是修改EML或Parser，而是先提供有效的Parsing Agent Key，再新建回放；Booking Key尚未由该run验证。

2026-08-17 Processing Run 全生命周期日志

Debug AgentBus EML回放新增agentbus-processing-lifecycle-log-v1：以一次replay/processing run聚合现有14阶段 快照、时间、input/output、issues/evidence和Agent公开轨迹；Booking返回既有audit中的全部attempt，Parsing按 现有execution返回累计attempt与最终Provider审计。没有新增日志表、导出包或第二业务事实源。

页面“复制完整日志”和“导出完整日志”使用同一缓存JSON字符串。后端compile/test-compile及聚焦测试、前端 typecheck与2 files/7 tests通过；8082/5178本机接口和页面验收通过。旧replay 2089182353460953090是 PREVIEW_READY，故只有预处理三阶段完成，SourceMessage以后待执行；这证明日志如实呈现，不是新真实EML全链 成功。production配置未改，未调用PMS/Opera。

2026-08-17 SuperAgent Parsing/Booking 主线公开 Trace

fixed-channel Parsing Agent与Booking Business Agent的Open API配置现默认并强制include_trace=true，显式 false会在调用Provider前fail closed。Trace模式要求公开run.completed(status=success)与顶层end同时存在； 安全public_trace_events映射到既有execution/invocation audit与回放，Provider final/delta文本不进入可持久 Trace，URL/Secret/Cookie/CSRF继续脱敏。legacy Field Recovery no-Trace边界保留。

聚焦41项测试全部通过（37项属性/SSE/主链安全投影＋4项本机loopback client）；未调用真实平台、数据库、邮件、 PMS/Opera或开启运行开关。本项只完成M012生命周期日志的公开轨迹传递子项。

2026-08-14 Booking Agent RC6 身份门禁与 Trace 薄契约

用户完成 RC6 发布/绑定后，仓库以一项合成 QBD Trace/Extra Bed 输入调用 Booking 专属 Open API。平台 run 为 success，resolved Profile 为 85ab8334-4e1c-4716-8ec0-9c3c099cec9b，当前发布 version ID 为 b91686f4-b8b8-4ac0-aeb4-b7a2f54a0a41。首次 SSE 在本地 240 秒门禁结束；相同幂等键接续后 16.01 秒完成， 严格 Candidate decoder、service_text、Extra Bed RM2/数量1、单值 FO+HSK、无 parameters 及 Layer6 非拒绝检查 1/1 通过。

application.yml 默认 expected version gate 已同步；逻辑版本仍是 booking-business-agent-v1.0，production 继续要求显式空身份并保持所有运行开关关闭。Secret 未落代码、配置、fixture、文档或测试报告。本项不等于完整 八场景、数据库/AgentBus全链或production放行。

2026-08-14 Booking Agent V2 durable runtime本地完成

普通V2入口和fixed-channel最终Layer3 continuation现共用BookingAgentRuntimeCoordinator：短事务保存最终 Layer3、Layer4、canonical input和唯一execution并进入AWAITING_BOOKING_AGENT，提交后才由 BookingAgentDurableWorker通过Booking专用SuperAgent port外呼。外呼前有“不得位于Spring事务”执行保护； Provider失败不会撤销Parsing或Layer3/4成果。

V11新增单一execution并扩展既有invocation audit；SKIP LOCKED、lease/fence、稳定input-hash幂等、有限重试/ 退避和Candidate hash apply-once支持重启恢复。Candidate独立提交后，validation claim只恢复Layer6而不重呼 Provider。decoder严格校验JSON、contract/profile、run/source/revision/hash、evidence、全局ID及linked/Allotment/ Rooming引用；不可重试或耗尽失败形成安全Risk后仍经Layer6。raw Provider回答不落库。

离线core matrix覆盖QBD和普通LianTai各自New/Update/Cancel/Allotment，失败/重复/重启/事务边界均有测试； ONE BEDROOM SUITE DBL → ONE-BEDROOM-SUITE-DBL → RM2交接回归保持通过。full为957 tests、1个并行V4 failure、0 errors、11 skipped。当前进程没有Booking专用key、expected Profile身份或Booking PostgreSQL连接， 故本轮没有重查平台、执行8-call live或V1–V11 PG smoke；历史CP5 v7证据保留但不能替代部署复验。

2026-08-14 CP5 SuperAgent 测试平台绑定

Booking Business Agent与fixed-channel Parsing Agent分别使用独立external app/Secret，绑定仓库独立Main Prompt 与唯一对应Skill。Booking Profile 85ab8334-4e1c-4716-8ec0-9c3c099cec9b已发布v7 version 9fed48c0-1f53-4d5a-8ba0-52865c738d83；Parsing Profile ea56cb01-72f0-4ef2-9a73-40cfae1abcd4已发布v8 version 8b30ebe9-180c-433b-89cf-9c59933b618a。两者平台检查均11/11。

真实Java opt-in smoke分别通过：Booking 1/1（52.782秒），经CandidateDecisionV2 decoder＋Layer6；Parsing 1/1（202.146秒），经完整adapter、Profile/version gate、decoder＋semantic validator。长Parsing响应暴露 message.final约2,000字符截断，SSE parser已仅对严格前缀场景保留完整stop内容，并将Parsing等待默认值提高 至240秒。focused 53项0 failures/errors（2 live默认skip）；全量953项只有既有范围外V4 failure。

Secret未落仓库；默认/production的Agent/provider/worker仍false。本次没有启动AgentBus WebSocket、应用部署、 数据库链、PMS/Opera或CP6。因此已完成的是CP5测试平台和真实契约绑定，不是自动生产运行。

2026-08-13 fixed-channel Parsing Agent已接入真正的Booking V2两阶段主流程：@Primary编排器执行公共Parser、 持久Parser/FAILED fallback、原子enqueue并把run置为AWAITING_PARSING_AGENT后返回；worker从持久快照重建 完整Current/History request，经本地validator/merge把最终八数组Layer3无业务解释投影latest Layer3ResultV2， 再以同run执行当前Layer4/5/6及现有Layer7确认投影边界。V2无槽位审计保存在sidecar；AgentBus接管后抑制旧 realtime dispatch。SOURCE_ROOM_NAME保留raw/evidence，normalized使用Parser已确认值并由V2原样传递；QBD/LianTai 的空格Suite DBL均exact解析为RM2，未知label不猜测。fallback仅唯一Current .xlsx、严格identity/hash/type/size/revision、有界visible scalar， 拒绝formula/link/hidden/URL/bytes；无fallback稳定blocker。fake/mock focused 149零失败（7 skip）；full 902仅 范围外V4 controller 1 failure、9 skip。默认/production仍关闭；Schema/Main Prompt/Skill/Parser/frontend未改， CP5测试平台绑定已由上方2026-08-14记录完成；自动部署、CP6、PMS/Opera继续HOLD。

2026-08-13 共享Parsing Agent Skill已同步完整输入规则：完整Current必读、系统提供的全部History按顺序完整 阅读且不得由Agent筛选、全部Parser Results逐项读取、facts权威只读、agent materials逐项闭环。新15成员 .skill SHA-256为94bb65b6a7af75b1c6e5edf5496d3c66e12058362a735c2402136628e91ba22d； Schema、fixtures业务结果、独立Main Prompt和runtime未变，包继续HOLD/INTERNAL_ONLY。

2026-08-13 共享Parsing Agent独立中文Main Prompt已进一步明确实际输入：完整解析Current主题/正文，按顺序 完整阅读系统提供的全部History正文且不自行筛选可用性；History仍仅辅助Current。当前附件Parser facts逐项 只读，agent materials逐项处理。新Prompt SHA-256为 8ad0a914c1596563122d94efff084419204524c6fa48acc721704d6b3786b5f6；Skill归档、Schema、runtime与HOLD状态不变。

2026-08-13 Layer 5 Booking Business Agent v1.0 离线验收

所有白名单入站进入预订流程后必须调用 Booking Business Agent；Agent收到Current、完整有序History正文与 Layer3/4已整理材料，不收到History附件、数据库历史或生命周期。CandidateDecisionV2已覆盖New/Update/Cancel、Trace、Rooming List、 Allotment、局部Risk和未归类原文，Payment本期只保留原文。Layer6只负责schema/evidence、第二道门槛、 Layer4等值和幂等且不改型；本期不查询重复New、生命周期或较早任务。独立Main Prompt未进入24成员Skill包；包状态为HOLD/INTERNAL_ONLY， 当前精简RC2 SHA-256为a68d0e1902dd0b0f52e664f89599191d1cf01b1d040f0cb17f066edd610e01f1； 独立Main Prompt已删除身份话术和契约防御复述。完整结论见 docs/project/requirements/booking-business-agent-v1-offline-acceptance-report.md。

2026-08-10 M012 房型与基础 RATE CODE 配置化

Directory Foundation 实现已完成：版本化 rate-room-v20260810 目录包含 207 条映射、10 个 Room Type、21 个基础 Rate Code、5 条 Word 优先修订、40 个仅输入兼容的历史组合码 alias，以及 26 个不可静默合并的候选情景。2026-08-10 已按用户确认移除渠道 Group/FIT 例外，所有订单统一以有效房量 1–4 间为 FIT、5 间及以上为 Group；目录 JSON SHA-256 为 7993b3b3e99934e74b8f026d135a4606eb457c7e2acf205434f09f75864ac3bf。repo-owned Golden、sidecar manifest、Python/Java tests 与后端全量验证共同守门。V27__align_rate_room_directory_v20260810.sql 是加法 migration；V25 及其历史数据不改动。

2026-08-12 用户进一步给出完整的 50 个显示标签 TYPE OF ROOM → Roomtype 最新权威映射，并确认旧目录里的 ONE-BEDROOM-SUITE GARDEN VIEW TWN、ONE-BEDROOM-SUITE-TWN GARDEN VIEW 两个标签不存在。系统已将其实现为 schema v3 rate-room-knowledge-corrections-v20260812：48 条有效 exact-normalized 规则（43 唯一候选、5 多候选）和 2 条显式删除记录；删除标签不再是人工候选，并同时排除于 Roomtype 与 Rate Code 查询。旧的“所有含 TRP 默认 → RM4”临时规则已废止。

TYPE OF ROOM → Roomtype 与 Rate Code 来源函数继续保持独立输入语义。最终 room&rate 0812.xlsx 已进一步生成 rate-room-effective-mapping-v20260812.1：213条候选行、163个mapping company + Type + normalized TYPE OF ROOM + price场景，136个唯一、27个多候选。2026-08-13 Layer 4已消费该Catalog；后续权威链已移除数据库订单/任务历史查询，QBD输出一项双适用Rate option、普通LianTai同时输出FIT/GROUP options，Layer5 Candidate与Layer6等值校验也已实现。Parsing Agent latest Layer3 direct handoff和当前附件文件名型Rooming List resolver均已于后续任务完成；Rooming List全业务与active legacy迁移仍未完成，Skill保持HOLD。

原 Foundation 曾用 SHA-256 精确匹配的 Excel 与冻结 Word 通过 generator --check；2026-08-10 Group/FIT policy 纠偏后，本机缺少该 Excel，需在来源恢复后重跑 source reproduction。Booking Skill booking-desk-event-block10.1-rc1 只作为可复现候选包，现含 27 个成员，archive SHA-256 为 86ec5634cb16fbd4a121ed0c519aaa107cf6d205c8ee6d4b2a874fcab27be0ba，manifest 明确为 publication_status=HOLD；不得发布。Room Information 既有 API/UI 行为不在本 Foundation checkpoint 内变更。

2026-08-10 QBD Layer 3 Parser + 字段 Recovery

QBD Parser 与字段 Recovery 已按唯一共用契约完成本地 checkpoint：Parser 保存不可变 observations 与 AFTER/CURRENT facts；RecoveryRequestBuilder 只为 exact UNRESOLVED+RECOVERABLE field_id 建最小任务； Agent PatchSet 经本地 Validator、QbdEffectiveDependencyResolver 与 QbdCurrentFactProjector 后形成 EffectiveFactView。结构问题不交给字段 Agent，BUSINESS_MERGE_REQUIRED 等通过稳定 target review 进入人工复核。QBD F/Nights Override 完全忽略。后续 live-provider checkpoint 已实现默认关闭的 SuperAgent Adapter、120 秒可配置整体 deadline/cancel、严格 JSON-only 输出、PostgreSQL invocation 审计与 Assembly apply-once，并只在 MANUAL_EML 于 Context 前同步完成。AGENTBUS 因仍处于 WebSocket frame 线程而明确跳过；Recovery 已改为独立 token/client、哈希 subject 与无 Trace message.final/end → GET run status 成功确认。真实合成 smoke 已验证 API exposure 和实际 Profile/version，但完整 Recovery PatchSet、MANUAL_EML 与 PostgreSQL V3 deployment smoke 未完成， 因此仍不能宣称外部解析 Agent 已上线。

2026-08-08 V0.1 安全纠偏（高优先级，覆盖上方历史叙述）

本 checkpoint 已撤销 Rooming List 确认后的自动 DEF / V4_ROOMING_LIST_AUTO_DEF 行为：确认只更新当前 Rooming List 卡和订单任务派生状态，不修改 Group Booking Status、Room Information 确认快照或其他业务卡。上方早期 M002 叙述中与此冲突的“自动 DEF”描述仅保留为历史记录，后续实施必须以 docs/project/operations/booking-v01-security-checkpoint.md、当前代码和后续 contracts-v1 为准。

同时，默认本地 profile 已改为进程内 H2；远程开发/生产数据库连接必须由环境变量或部署 Secret 注入。历史凭据轮换是部署管理员的外部前置，未取得证明前不得把 G0 标记为通过。

M012“预订邮件识别到人工确认”V0.1 已完成：新增普通员工 .eml 导入页和 API、固定渠道严格底色 deterministic Parser、版本化 Catalog、V4 建卡/复核/确认衔接、识别证据面板、真实样本验收和 PostgreSQL 项目专属 schema。手工导入路径的未知/歧义输入当前生成 S10/S99 来源通知，不在请求内自动调用外部 Booking Agent；PMS/Opera 执行仍不在范围。

2026-08-08 BR00/M012 双区块收口

V4 新 intake 已补齐订单任务双区块：只有 Trace、Rooming List 或 Payment 的订单任务会额外创建一张共享 current-only companion Room；同组已有 New、Update 或 Cancel 生命周期 Room 时不重复。查询、确认和前端展示均保留原辅助 event 类型，proposed_values={}、change_summary=[]，辅助专属卡、General/Risk、安全和权限边界不变。后端 V4 入站/查询/命令回归及前端 38 条 V4 页面测试通过。历史已落卡任务受幂等门禁保护，不自动回填。

2026-08-10 Booking Business Agent 独立接线

Layer 5 当时已通过 booking.agent.open-api.* 使用自己的 SuperAgent 外部应用和 token，不再注入全局 Open API client，也不再依赖固定 external-subject-id。信息系统从来源消息 SHA-256 派生匿名 subject。 该 checkpoint 当时仍在既有 processing-run worker 内同步等待 Provider；2026-08-14 已由本文件顶部的 V11 durable runtime取代，当前必须先提交Layer3/4/input，再在事务外调用并从持久Candidate恢复Layer6。

2026-08-10 首轮真实合成 smoke 确认专用 token 可以创建 session，但消息 stream 当时因 Profile API exposure 未开启而返回 403。2026-08-11 用户启用外部 API/流式接口并发布后，no-Trace 复测已通过 session/stream 200、非空 message.final、end、run success，且实际 resolved Profile/version 为 85ab8334-4e1c-4716-8ec0-9c3c099cec9b / 1711d4ed-8d0d-46fa-9d1f-4bb2d61fde23。当前 Prompt 2 在当时是占位符。该平台状态已由2026-08-14 CP5正式Prompt/Skill与Booking v7真实Candidate smoke取代； 当前部署仍需重新核对resolved Profile/version、专用Secret、V11及八场景，不得把旧或单次CP5证据直接当生产放行。

1. 当前 Checkpoint

• 名称：M012-booking-agent-v2-durable-runtime-local-complete
• 状态：Layer3/4→Booking Agent→Candidate→Layer6的V2 durable代码与离线验收完成；本次环境未执行当前Profile、 PG V1–V11、八场景live或完整AgentBus链，默认/production保持HOLD，CP6未开始。
• 目标：在指定非生产完成外部deployment gates并观测稳定运行；不修改冻结Prompt/Skill、V2→V4、Rooming List 全业务、PMS/Opera或production。
• 数据库：默认 Spring profile 仍使用 H2；仅在显式 booking.postgres.enabled=true 且由 Secret 提供连接时启用隔离 PostgreSQL runtime/Flyway，所有新表只位于 th_hotel_booking，不建立跨库事务。获批非生产测试库已完成V1–V6与restart/lease/concurrency smoke；MySQL V30仍未做真实smoke。
• 验证：CP4定向Java 233 tests（0 failures/errors、7 skipped）；排除两组CP6旧v0.2历史测试后的主流程 Java 790 tests（0 failures/errors、9 skipped）；原始full的旧v0.2 FileNotFound仍属CP6债务。 Agent 22/22、Python 50/50、15成员Skill source/archive/manifest严格校验，以及正式PostgreSQL smoke 1/1通过； CP5另有两条真实Provider合成smoke通过；未调用PMS或Opera。

2. 当前优先级

1. 先把 AI-NSES 的入口文档落地，让新 Agent 不依赖聊天记录也能理解项目。
2. 保持 docs/project/README.md、CONTEXT.md、PROJECT_STATE.md 三个入口之间一致。
3. 后续开发继续以当前有效的 M002 V4 字段契约、M002 V4 CP2 多卡模型设计、M002 V3 / P0.1 历史实现说明、字段控件契约、SuperAgent 契约和安全边界文档为准。
4. 后续新增重要 V4 需求时，先按 docs/project/ai-nses-project-overlay.md 形成或更新模板化 Spec / Change Request，并维护需求追踪表。

3. 已确认事实

• 本项目是前后端分离项目，根目录使用 client/ 和 server/，不是 AI-NSES 示例里的通用 src/ 单目录结构。
• 可复用规范放在 docs/import/reusable/，当前项目专属文档放在 docs/project/。
• AgentBus 是消息入口适配器，SuperAgent 是外部 AI / Agent 能力提供方，二者不能直接成为业务事实来源。
• 后端时间点按 UTC 存储和返回，页面再按酒店或用户时区展示。
• 新增 MySQL 表默认要求 utf8mb4_bin，避免外部 opaque id、Token、状态码和业务代码被大小写不敏感比较误判。

4. Known Issues

• 现有历史文档暂不按 AI-NSES 目录大搬迁，先通过索引和采用说明建立映射关系。
• docs/import/ 下按日期导入的资料是输入材料，不等同于当前权威开发契约；当前开发应优先看 docs/project/README.md 标记为当前有效或权威契约的文档。
• 后续每完成一个 Feature 或 Checkpoint，需要更新本文件，避免项目状态继续沉淀在聊天记录里。
• AI-NSES v0.2 和 TH Hotel 项目级 Overlay 已落地；近期 M002 V4 新增需求已新增模板化 Spec 入口。后续新增或变更 V4 需求时必须继续维护该 Spec、后续 Change Request 或新 Spec，避免只散落在当前有效大文档中。
• M010 Rooming List Excel 生成后端 CP1 和前端 V1 已实现：前端 /reservation/rooming-lists/new 上传来源名单并下载后端同步生成的 .xlsx，第一版不落库、不上传 OSS。CP2 已实现：来源 Excel 旅游日期 派生 Arrival / Departure，Adults 由系统按分房结果计算，目标默认值区域只保留 Payment Type / Nationality，Payment Type 默认 BTQR 且当前允许 BTQR / CA，Nationality 只允许 KR / CN / TH / MM / RS / TW。CP3 已实现：兼容第二种 英文姓 + 英文名 名单样式；CP4 已实现：兼容第三种单列 英文名 名单样式。无旅游日期来源样式由用户补充 Arrival / Departure，且 23+1、19+1 中领队也进入房表。
• M011 Booking Excel 附件预处理 CP1/CP2/CP3 已实现：后端可排除人员名单类 Excel，按最近 6 个月候选窗口选择实际存在的最新 3 个业务月，抽取 Booking Update / 附加费表高亮行业务 JSON；Debug EML 和 AgentBus dispatch 在各自 include 开关与总开关同时启用时，会在调用 SuperAgent 前追加 attachment_extractions[]。测试机 AgentBus 增强已开启；生产链路仍默认关闭，生产开启需单独确认。
• M002 V4 CP1 当前已完成入站解析和现有任务链路过渡适配；M002 V4 CP2 已完成订单任务与多卡领域模型设计；M002 V4 CP3 已完成 V4 订单任务、多卡和 S10/S99 来源通知表结构与 Repository 基线；M002 V4 CP4 已完成入站写入新模型；M002 V4 CP5 已完成前端查询接口并补齐订单详情 v4_order_tasks[] 时间线；M002 V4 CP6 已完成普通卡片确认和 S10/S99 来源通知 ack；M002 V4 CP7 已完成 REVIEW_REQUIRED 卡复核解阻和复核场景订单归属确认；M002 V4 CP8 已完成目录校验、V4 卡片 fields[] 字段白名单、确认写入白名单收口和嵌套业务字段目录校验；M002 V4 CP11 已完成数据库目录、初始化种子、启动补种子、Account / Room Type / Rate Code lookup API，并把 V4 入站、确认、复核目录校验切换到当前酒店数据库目录；M002 V4 CP12 已完成前端 lookup 接入第一版和 V4 订单任务时间线消费；M002 V4 CP13 目录管理后台 CP1 已完成前后端列表、新增、启用 / 停用闭环；M002 V4 CP14 已完成订单列表 V4 继续处理入口字段和前端入口消费，GET /api/reservation/orders 返回 V4 下一步订单任务、卡片、动作类型、动作状态、V4 open 数和统一展示计数 open_work_item_count，前端按 V4 优先跳转，并按 open_work_item_count 展示待处理数量；V4 业务审计查询已补齐订单任务审计和来源通知 ack 审计两个只读接口；订单详情已补齐并完成前端接入 V4 order_overview、next_v4_action、related_source_messages[] 和 v4_order_tasks[].cards[]；V4 普通业务入站已停止双写旧 workflow_reservation_task；MCP th_hotel_submit_task_results 已收口为 M002 V4-only，旧 V2/V3 submit payload 返回 MCP_SUBMIT_V4_REQUIRED，不再影响 SuperAgent 输出契约；Room Information 后端展示模型和前端业务化展示第一版已完成；Rooming List 确认无跨卡副作用已完成，前端轻量事项确认卡也已完成；Payment 附件安全摘要后端和前端预览接入均已完成。OWNER RATE Room Type / Rate Code 目录口径已落文档；真实 PMS 同步和 SuperAgent 目录机器接口仍未完成。
• M002 V4 CP2 已确认：V4 工作台统一列表草案为 /api/reservation/workbench-items，业务订单任务接口新开 /api/reservation/order-tasks/**，S10/S99 来源通知详情草案为 /api/reservation/source-notifications/{notificationId}；S10/S99 使用来源通知模型，不再挂隐藏技术订单；FIT + BOOKING_CODE 不建 ACTIVE 唯一约束，匹配多条进人工复核；Basic Information 必须先确认；Rooming List 卡第一版只做事项确认；Account 通过数据库目录选择，Market / Source 可默认来自目录并允许前端人工覆盖提交；旧 V2/V3 任务详情和草稿确认接口后续可逐步废弃。

5. Next Steps

• CP5测试平台绑定和无PII合成Provider smoke已完成；在指定非生产部署通过Secret管理轮换/注入两个独立key， 重启并启用选定worker，执行AgentBus→SourceMessage→PostgreSQL→双Agent→Layer6完整smoke；仍需告警/人工 重放runbook，若运行主路径要求MySQL则完成V30；production保持关闭。Layer3旧required-fact门禁已移除， 业务字段完整性由Layer6负责，不再等待或伪造业务目录。
• CP6只在CP5观察期和回滚演练后另行授权；此前保留parseLegacy、旧Field Recovery、Layer3 v2与旧contribution。
• 在 dev/test 通过专用 Secret 注入 Recovery API Key，用完整 RecoveryRequestSet 验证目标 Recovery Skill/PatchSet，并配置 Booking PostgreSQL 执行 Flyway V3/超时/审计 smoke；生产开关继续强制关闭。
• Booking Business durable runtime的持久审计/Risk/重启恢复已离线完成；部署前仍须轮换并通过Secret管理注入 Booking专用key，复核当前Profile/version，执行V1–V11 PG、QBD/LianTai八场景live和完整链smoke。production保持关闭。
• Layer4 Rate/Room与Layer5/6契约、Parsing最终handoff和Rooming List typed resolver均已完成；V2→V4 authoritative writer/页面接线另行审批。
• 如需自动邮件入口复用 Recovery，先把 AgentBus → Booking 下游移入 SourceMessage 后受控 worker，再由 worker 有界等待；不得在 WebSocket callback 中直接调用解析 Agent。
• 后续如继续做 M002 V4，可优先进行测试机联调，或推进真实 PMS / OPERA / OHIP 目录同步、workflow_reservation_catalog_sync_run checkpoint 和 SuperAgent 目录供给方案。
• SuperAgent 通过 MCP 提交时，排障优先查询 platform_superagent_mcp_call_diagnostic，对比 arguments_json、adapted_payload_json、mapping_diagnostics_json 和业务 batch / transition，判断问题来自 SuperAgent 原始参数、MCP adapter 还是业务入站层；V4-only 模式下 mapping_diagnostics_json 通常为空对象，若错误码为 MCP_SUBMIT_V4_REQUIRED，说明 SuperAgent 仍按旧 V2/V3 schema 输出；旧 V2/V3 被拒也会入本诊断表但不会进入业务写入 Service；V4 source_message.conversation_id 可缺省；该诊断表不作为业务事实来源，不进入普通前端接口。
• 后续新增重要功能时，优先在 docs/project/requirements/ 或未来 docs/specs/ 中形成 Spec，再实现代码；V4 相关需求必须按 docs/project/ai-nses-project-overlay.md 补核心概念守门、需求追踪表和 agent 交接边界。
• 单卡可操作态测试数据已回填；后续演示或回归如果需要重新造数，应继续使用 fresh runId，避免复用旧 SourceMessage 时间线造成阻塞误判。
• M010 CP4 第三种单列 英文名 名单样式兼容已完成；预览、历史记录、OSS 下载、订单 / 任务预填或客户字段目录化仍后置，需单独开前后端 checkpoint。
• M011 CP4 暂不推进；当前停留在 CP3 边界，只增强 SuperAgent 输入，不直接落订单、任务或长期解析历史。后续如确实需要运营查询或长期追踪，再单独设计 Excel 解析批次 / 行级持久化表。

6. 文档同步提醒

每次 Feature 完成后检查：

• Domain 是否需要更新。
• Architecture 是否需要更新。
• Workflow 是否需要更新。
• ADR 是否需要新增。
• Spec 或需求文档是否需要更新状态。
• PROJECT_STATE.md 是否需要更新。
• 接口、安全、权限、审计和酒店隔离文档是否需要同步。
• 需求追踪表、Change Request 和 agent handoff 是否需要更新。

如果没有文档变化，明确说明：

No documentation changes required.