This commit is contained in:
鲨鱼辣椒
331
PROJECT_STATE.md
Normal file
331
PROJECT_STATE.md
Normal file
@@ -0,0 +1,331 @@
|
||||
# TH Hotel Simple 项目当前状态
|
||||
|
||||
| 项 | 内容 |
|
||||
| --- | --- |
|
||||
| 最近更新 | 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 是否需要更新。
|
||||
|
||||
如果没有文档变化，明确说明：
|
||||
|
||||
```text
|
||||
No documentation changes required.
|
||||
```
|
||||
Reference in New Issue
Block a user