th-hotel-simple/docs/project/requirements/M012-rate-room-configuration-change-request-v1.md

M012 / V4 房型与 RATE CODE 规则配置化 Change Request v1

项	内容
状态	Directory Foundation、0812 effective mapping、Layer 4 Context/Resolver、Parsing Agent最终V2交接、当前附件文件名型Rooming List resolver及Layer 5/6离线契约已实现；真实Provider、业务发布仍HOLD；not deployed
日期	2026-08-13（Layer 4 amendment）
提出人	用户批准的 PLAN (9).md 实施计划
关联 Spec	booking-email-architecture-v0.5.md、booking-email-contracts-v2.md、M002-v4-real-catalog-lookup-api-design.md、M002-v4-requirement-spec-template-alignment.md
Checkpoint	Parent：M012-rate-room-configuration-v20260810；当前：layer4-context-rate-room-v2
影响范围	Backend / Frontend / Test / Docs / Security / Booking Skill / Database Migration
当前 checkpoint 范围	Backend V2 contract / Layer 4 Resolver / typed source context / SHADOW orchestration / Layer 5 option consumption / Layer 6 equality / Test / Docs；不查数据库订单历史，不改 API、UI、Parser 语义或 PMS/OHIP

1. 变更背景

当前 V4 目录仍由 Java 中的少量 Room Type 和组合 RATE CODE 种子驱动，早餐依赖 RB / RO 字符串猜测；Booking Skill 的酒店映射也不能以同一可追溯目录为准。实际酒店规则已冻结在一份 207 行 Excel 和一份 Word 澄清中，包含 10 个 Roomtype、21 个基础 RATE CODE、早餐餐厅、价格、同名房型消歧和人工复核边界。

本变更将这些规则收敛为版本化目录和少量独立策略。当前 V4 catalog / Room Information 已消费 10/21 合法代码、旧码兼容和早餐元数据；当前 Directory Foundation checkpoint 已补齐 207 行目录的 manifest-first 加载、完整校验、不可变索引，以及 compatible-input / canonical-output 两套明确 API。Booking Skill rc1 仅保留为候选构建与回归材料，不是最终 Rate/Room 权威。范围终点仍是人工确认；不执行 PMS、Opera、OHIP、付款或部门流转。

2. 权威来源与适用边界

基础来源的权威顺序固定为：酒店 Word > 更新版 Excel > 用户补充说明。基础版本验收后发生的人工业务纠偏不得伪装成原 Word/Excel 内容，应以独立、版本化的 correction set 绑定到精确基础目录版本和 SHA-256。

来源	文件名	SHA-256	本次用途
酒店 Word	ประเด็นเกี่ยวกับ RATE CODE(1).docx	78d2ce374214b97188ce9dc7431df8516880db0e3098393402e9463d002fac87	同名 / 同价多候选的业务澄清与五项房型修正
更新版 Excel	REVISE- RATE CODE_8.7 更新 .xlsx	514ad0bf7ef71566fc0995561b5982b855e672fe214071d8f3bc65b5cbe776ca	7 列、207 行目录事实与来源行号

2026-08-12 的 schema v3 首版曾有48条规则（43唯一、5多候选）和2条删除记录。 2026-08-13 用户进一步确认五个精确映射，并取消“已删除来源标签”业务身份。当前 schema v4 包含48条活动 exact-normalized 规则，全部唯一， 另2个基础目录标签无活动映射；意外输入统一为MAPPING_NOT_FOUND，不暴露删除身份。 已确认：TRP→RM4、ONE-BEDROOM-SUITE-TRP→SU1、ONE-BEDROOM-SUITE POOL TRP→SU2、 ONE-BEDROOM-SUITE-TRIPLE POOL VIEW→SU6、精确ONE-BEDROOM-SUITE-DBL→RM2。最后一条不扩展到Q10、Garden、Pool或其他含DBL标签。 匹配只允许大小写、连续空白和连字符两侧空白归一化，不允许 contains/fuzzy/相似标签推断。

同日确认两个独立业务函数：TYPE OF ROOM → Roomtype；Company + TYPE OF ROOM + price → Rate Code。后者不得以 canonical Roomtype 为输入。本次先冻结独立 Rate Code projection/fingerprint，再更新 Roomtype authority；Rate Code projection SHA-256 保持 2810b5c812858da4be694dfa7259b8cdd1c98c1e8133f368e4a4ad9fe5e02885。当前 207 行继续作为来源 provenance，不回写原 Excel、V27 或基础候选场景；Loader/Snapshot、候选 Skill 和工作区 deterministic normalizer 已同步知识。2026-08-13 Layer 4 已消费该权威目录，Layer 6已实现对应Rate option等值校验；最终Layer3 handoff与运行发布仍待完成。

最终 room&rate 0812.xlsx（冻结来源 SHA-256 7fdf2b5a771e69466db2b1bdc7911f978f490905c42ee67d5ae19200343b04d3）形成 映射主表!A1:H214 的213条候选行和163个场景。Catalog 提供显式 FIT/GROUP 候选查询、原子套餐唯一性、 套房继承及餐厅条件；Layer 4 已改为 QBD 一个双适用 option，普通 LianTai 同时两个 options，Layer 6 已校验 Booking Type 对应 option 等值。零候选、多候选或冲突均 fail closed。

原始 Word / Excel 不进入仓库；生成目录仅保留文件名、哈希、Sheet、原始行号和来源版本，不保存实际邮件、客人或订单数据。

上述权威顺序用于目录行事实和酒店澄清冲突。运行时“按渠道与订单房量选择哪一组目录行”的政策，以本文件 4.2 节中用户于 2026-08-12 明确确认的规则为准；该政策不改写原始 Excel 行。

3. 原规则

• Java 启动逻辑维护 6 个 Room Type 和 40 个带价格后缀的组合 RATE CODE；新建目录会把组合代码暴露为可选项。
• 早餐在 Room Information 中主要依赖 RATE CODE 是否含 RB / RO 的字符串规则，不能表达 BUALUANG、LEELA 或显式 RO。
• Booking Skill 的酒店映射未以同一版本化目录为数据源；多候选、套房继承和同名房型修正容易散落在规则文本中。
• 当前 lookup API 只返回酒店级 ACTIVE 目录，Room Information 由后端生成稳定展示模型，前端不得从 Agent 原始 payload 推导业务字段。

4. 新规则

4.1 版本化目录与来源校验

• 从更新 Excel 生成 rate-room-directory-v20260810.json；每个映射行保留公司、规范化 Group/FIT、邮件房型、房间语义、Roomtype、基础 RATE CODE、早餐餐厅、价格、原始行号与来源版本。
• 生成器必须校验 Excel SHA-256、7 个精确表头、207 条数据、重复项、10 个 Roomtype、21 个基础 RATE CODE，以及每个基础 RATE CODE 的唯一早餐状态。
• 生成前按 Word 应用五项修正：
  • HONGYUN 4800、5100：Garden TRP → Pool TRP。
  • HANA TOUR 3300：TWN Pool → TWN Garden。
  • HANA TOUR 3600：DBL Garden → DBL Pool。
  • HANA TOUR 4700：Triple Garden → Triple Pool。

4.2 独立业务策略

• 每个独立订单统一按全部有效客房数量判断：1–4 间为 FIT、5 间及以上为 Group；渠道名称及邮件中的 GRP / FIT 字样不得覆盖房量结果。目录输入标签中的 GRP 仅规范为 Group。
• Booking Type 分类与 RATE CODE 规则集选择必须分开执行：一般公司先按房量确定 FIT/Group，再按渠道选择目录规则集；后者不得反向改变 Booking Type。
• Q.B.D 的 RATE CODE 映射 Type 统一为 Group&FIT，团队与散客使用同一套 QBD 映射，再按来源房型、价格和早餐/餐厅条件确定具体 GRPA 代码。冻结 0810 目录中的 Q.B.D / Group 仅作为旧来源标签 provenance，不代表 QBD 只适用于 Group；QBD Booking Type 可在其他业务流程中按房量独立展示，但不参与 RATE CODE 规则集选择。
• 普通 LianTai 的 FIT（1–4 间）使用 LIANTAI ONLINE/DY / FIT 映射，Group（5 间及以上）使用 LIAN TAI / Group 映射。
• LIANTAI ONLINE/DY / FIT 在本规则中只是普通 LianTai FIT 订单选用的目录集，不恢复 LianTai-FIT 邮件渠道、FIT sender 白名单、独立 Parser 或 Agent Profile。本期固定渠道仍只有 QBD 与普通 LianTai。
• 规则集一旦选定，只能在该集合内继续按房型、价格及适用区分项求唯一候选；零候选或多候选转人工，不得跨集合搜索或选择第一个结果。
• 价格只接受邮件房型标签或明确价格字段，例如 U-TWN8.5 → 850。标签后独立的 12 是房间数量，不得解析为 1200。
• 对配置的八家公司，Booking Skill 禁止全局房型规则覆盖酒店目录。

4.3 Roomtype 与 RATE CODE 决定

• Roomtype 与 Rate Code 是两个独立解析结果：Roomtype 读取 TYPE OF ROOM；Rate Code 读取 Company、 来源 TYPE OF ROOM 和价格，并继续应用已确认的显式规则集/区分项。Rate Code 不读取 canonical Roomtype。
• 独立 Rate Code 投影、结果和状态必须在 Roomtype 更新前后逐项一致；任一漂移都阻断发布。目录投影指纹与 Layer 4 Resolver 投影测试均已证明零漂移；Layer 6 最终一致性仍是后续发布门禁。
• Roomtype 只按 schema v4 exact-normalized 标签查询。48条活动规则均返回唯一候选；精确 ONE-BEDROOM-SUITE-DBL → RM2，其他含DBL套房标签继续按各自规则处理。
• U- TRP → RM4、SupTRP → RM4、DELUXE-TRP/DELUXE-TRIPLE → UG2 等必须各自命中精确规则；禁止恢复“所有含 TRP → RM4”或基于相似文案猜测。
• 两个无活动映射标签只在冻结基础目录保留 source row 193/202 provenance；当前 Roomtype/Rate 投影都排除它们。 新输入意外出现时与其他未知标签一样返回MAPPING_NOT_FOUND并转人工。
• 新输出和新目录只使用基础 RATE CODE，例如 GRPA2，不再输出 GRPA2-850UP。
• 明确餐厅或 RO 优先；仅因 BUALUANG/LEELA 分叉时默认 BUALUANG。Q.B.D 的 U-DBL/U-TWN 1200 默认 GRPA3，明确 LEELA 时为 GRPA4。
• Q.B.D、LIAN TAI 的套房继承同一预订主房 RATE CODE；仅套房且没有主房依据时转人工。

4.4 早餐派生

• RATE CODE 目录为早餐唯一事实源：BUALUANG、LEELA 均为 breakfast_included=true；RO 为 false 且餐厅为 null。
• 新增只读 breakfast_restaurant_code: BUALUANG | LEELA | null，由后端统一解析器写入既有 Room Information 展示模型。前端不得自行按字符串推断。

4.5 0812有效映射运行目录

• scripts/generate_rate_room_effective_mapping.py 必须逐行校验最终Excel A:H、213个早餐公式及其缓存值，再证明 Company＋Type＋来源房型＋价格＋Rate/早餐投影与基础目录的活动标签事实一致。Excel Roomtype 列只作审计，不参与运行 Rate 解析。
• 运行资源固定为 rate-room-effective-mapping-v20260812.json 与manifest；它们绑定最终Excel SHA、基础目录SHA和knowledge correction content SHA。
• Rate 查询键为 mapping company + 显式 Layer4 option Type + normalized email room type + price。 QBD 只查Q.B.D / Group&FIT；普通 LianTai 同时查LIANTAI ONLINE/DY / FIT和LIAN TAI / Group，不在 Layer 4 按房量预选。
• Roomtype 唯一性与 Rate 套餐唯一性分开判断。Rate 候选按不同的{Rate Code＋早餐＋餐厅}套餐去重； 不得因 Roomtype 多候选而否定已经唯一的 Rate 套餐。

5. 核心概念守门与非目标

• Catalog 的目标定位是跨 Parser、Resolver、Booking Agent、Validator 与确认投影共享的版本化业务词典。 Layer3ResultV2 兼容投影、Layer 4 Resolver/Context、Layer 5 Candidate 与 Layer 6 等值校验已接入确定性 SHADOW 链； 异步 Parsing Agent 的最终合并结果尚未交接到该链。
• 当前 Directory Foundation 只负责 Loader -> Validator -> Immutable Snapshot/Index 和 canonical 合法值，不接收 ParsedFactSet、不产出 CandidateDecision，也不改变 architecture-v0.4 当前的 Layer 4 Context 职责。
• rate-room-knowledge-corrections-v20260812 作为基础目录之上的只读知识覆盖，由同一 Loader 执行独立 manifest/hash/结构门禁；Snapshot 只提供来源标签规则查询，不在目录层执行最终 Resolver。
• Booking Skill 只能消费受控目录视图，不能直接读写数据库或 PMS；rc1 在跨层接入完成前保持 publication HOLD。
• SourceMessage 仍是来源事实；Agent 输出仍仅为建议；REVIEW_REQUIRED 仍在原业务卡内处理，不新增独立复核卡。
• 不改变 Order、Order Task、Task Card、S10/S99 的关系；不改变邮件正文、附件、AI 原始 payload 的返回边界。
• 不操作生产数据库；仅新增迁移。不更新 PostgreSQL contracts-v1 的旧映射解析器，不维护旧 V2/V3 任务流程，不做 PMS / OPERA / OHIP 写入。

6. 后端、前端与 Skill 契约

范围	新契约 / 不变约束
Booking Skill	已构建 booking-desk-event-block10.1-rc1 候选包；回调结构不变。该包目前只作回归证据，publication HOLD，不作为系统最终 Rate/Room 决策权威。
Catalog / migration	加性迁移使当前酒店目录包含 10 个 Roomtype 与 21 个基础 RATE CODE；启动初始化读取生成资源，不维护 6/40 手写清单。
兼容输入	过渡期接受旧组合 RATE CODE 并规范成基础代码；旧代码不进入新的 Active lookup，历史已存值继续可读。
Lookup API	路径、鉴权、酒店隔离、分页和返回形状不变；只改变目录内容和版本元数据。
Room Information	现有 display_payload.room_information 仅增加 breakfast_restaurant_code；breakfast_included 继续为后端派生，价格不返回前端。
前端	通过现有 typed service、字段/Room Information 组件显示一个只读、i18n 化餐厅字段；不新增浏览器侧映射、Secret、外部调用或 PMS/OHIP 调用。

7. 兼容、迁移与回滚

• 历史任务可继续读取既有组合 RATE CODE；新确认、人工复核、Skill 输出和 lookup 只生成基础代码。
• 数据迁移只新增，不修改历史 migration；不清理、不改写生产历史数据。
• Layer 4 目前只以 SHADOW 方式生成上下文，不创建任务、不执行最终业务动作。不得发布 rc1；Skill 解锁仍需完成 Parsing Agent 最终合并结果交接、Layer 5/6 契约与确定性校验，并取得单独发布批准。
• 回滚时保留旧 Skill 包与上一版配置；后端仍能规范化旧组合代码，避免已入站数据不可读。

8. 安全、权限、酒店隔离与审计

• 既有 GET /api/reservation/lookups/** 与 GET /api/reservation/order-tasks/{orderTaskId} 仍是 FRONTEND_USER，沿用登录、权限码与对象所属酒店校验；本变更不增加 Controller 或权限码。
• 目录只包含业务代码、餐厅状态、价格事实与来源元数据；前端接口不返回价格、Word 内容、Excel 原文、邮件正文、附件 URL、AI 原始 payload、PMS 响应或跨酒店数据。
• 目录管理仍沿用 FRONTEND_ADMIN 和 RESERVATION_CATALOG_MANAGE 的现有审计边界；新兼容归一化不绕过目录校验或确认审计。

9. 验收标准

• Given 冻结 Excel / Word，When 运行生成器，Then SHA、表头、207 行、10 个 Roomtype、21 个基础 RATE CODE、无精确重复、五项修正及每码唯一早餐状态都通过。
• Given 任意渠道的 Group/FIT 边界，When 解析同一订单的全部有效房量，Then 4 间为 FIT、5 间为 Group，渠道名称和邮件 segment 字样均不覆盖该结果，目录 GRP 标签规范化保持正确。
• Given 任意房量的 QBD 订单，When Layer 4 选择 RATE CODE 映射，Then 配置 Type 为 Group&FIT 且团队/散客进入同一套 QBD 映射；具体 GRPA 代码仍按来源房型、价格和早餐/餐厅条件唯一确定，Booking Type 如需展示则独立计算。
• Given 普通 LianTai 订单，When 有效房量为 1–4 间，Then 只使用 LIANTAI ONLINE/DY / FIT；When 为 5 间及以上，Then 只使用 LIAN TAI / Group；两者均不得产生新的 LianTai-FIT 渠道身份。
• Given schema v4 authority，When 查询，Then 48 条活动规则全部返回单值，2 个无活动映射标签与其他未知标签都返回 MAPPING_NOT_FOUND；TRP必须返回RM4，精确ONE-BEDROOM-SUITE-DBL必须返回RM2。
• Given 旧组合 RATE CODE，When 后端接收确认/复核输入，Then 规范为基础代码；When 新目录 lookup，Then 不出现旧组合代码；历史值仍可读。
• Given LBLT 或 LBSM，When 查询 Room Information，Then breakfast_included=false 且 breakfast_restaurant_code=null；BUALUANG / LEELA 代码分别返回对应餐厅。
• Given 生成目录和新版 Skill，When 运行离线验证、后端测试、前端 typecheck/test/build 及打包一致性检查，Then 所有适用检查通过，且没有 PMS/OHIP 写入。

10. 需求追踪表

需求项	后端状态	前端状态	测试状态	文档位置	当前状态
207 行目录生成与来源校验	Done；policy correction source recheck pending	N/A	原 Foundation exact-hash Excel + Word --check Passed；本次纠偏因本机缺 Excel 待重跑	生成器、rate-room-directory-v20260810.json、本 Change Request	Foundation Done / Source Recheck Pending
207 行运行时加载 / 完整性校验 / 不可变索引	Done	N/A	18 focused + full Maven 528 Passed	reservation.rateroom runtime core / tests	Foundation Done
10/21 canonical 合法值与 40 alias 输入兼容 API	Done	N/A	Java focused/full Passed	RateRoomDirectorySnapshot / V4 compatibility facade	Foundation Done
Golden、negative mutation、schema / manifest / hash	Done	N/A	Python 14 + Java Golden/mutations Passed	repo Golden、generator/runtime tests、sidecar manifest	Foundation Done
完整 TYPE OF ROOM → Roomtype 映射 authority	Done；schema v4 correction + manifest；48活动规则全部唯一＋2无活动映射标签	N/A	Python/Java/normalizer与 Layer 4 Resolver 回归通过	rate-room-knowledge-corrections-v20260812.*、runtime/Skill tests、本 Change Request	Implemented / Layer 4 Consumed
基础 RATE CODE + 旧码兼容	Done	Done	Passed	V27、V4 catalog / intake / command / query、Lookup 文档	Implemented
统一早餐解析与餐厅字段	Done	Done	Passed	V4 Room Information、前后端协作文档	Implemented
Layer 3 Parser / Recovery contract	Layer3ResultV2 已可消费；Parsing Agent 最终合并结果交接仍属外部 workstream	N/A	compatibility path/fixture 已测；最终 handoff 未验收	architecture-v0.5 / contracts-v2 / 独立开发对话	Contract Available / Final Handoff Pending
0812有效映射Catalog生成/加载/查询	Done；213行/163场景，房量与公司规则集切换已实现	N/A	generator --check、compile、13 focused passed	effective JSON/manifest、Loader/Validator/Snapshot	Catalog Query Implemented
Layer 4 deterministic Rate/Room Context integration	typed order_contexts、Resolver及canonical SHADOW输入已接入；来源缺失直接unresolved，不查数据库订单/任务历史	N/A	focused/integration tests passed；当前本任务38/38	contracts-v2、Layer 4 evidence、本 Change Request	Implemented / SHADOW Wired
Roomtype/Rate Code 独立投影与零漂移 Gate	独立投影/指纹与 Resolver 零漂移测试已实现	N/A	generator mutation、manifest/runtime/Resolver projection tests Passed	ADR-002、impact evidence、generator/manifest	Layer 4 Gate Passed / Layer 6 Pending
Layer 5 CandidateDecision / Layer 6 equality validator	离线实现；Layer5按来源房量判Booking Type并只能消费对应Rate option，Layer6校验等值；重复New、生命周期和任务顺序检查已按产品决定删除	N/A	focused通过；当前整仓唯一失败属于范围外V4早餐餐厅夹具	contracts-v2、Booking Business Agent规则	Offline Implemented / Runtime HOLD
Booking Skill 10.1-rc1	仅为历史候选业务材料；含Rate/Room映射的旧职责已由新v1.0 source取代	N/A	不作为当前业务验收	旧candidate artifact / manifest	Superseded / Publication HOLD
文档、示例、Foundation 验证清单	Done	N/A	状态与证据已核对	当前契约、M012-rate-room-configuration-release-checklist-v1.md	Foundation Done

11. Agent 待办

Agent / 角色	待办	验证
后端	Layer 4 已完成 SHADOW 接线；下一步交接 Parsing Agent 最终合并结果并补 Layer 5/6	Layer 4 focused/integration/full backend 与跨层守门通过
前端	N/A；当前 checkpoint 不改 API 或 UI	不重复归属前端验证证据
Booking Skill	已同步 schema v4 exact-label 结果与双Rate options；继续不发布	source/包/manifest 一致性；HOLD 状态
文档 / QA	当前口径已同步；恢复 Excel 后补 source reproduction 证据	追踪表、变更影响与禁止发布核对

12. 文档更新

当前 Directory Foundation closeout 已同步：

• PROJECT_STATE.md
• CONTEXT.md
• docs/project/README.md
• 当前 Change Request 与 Foundation 验证清单

当前 checkpoint 不改 API、UI、权限、审计、酒店隔离或 SuperAgent 回调结构，因此前后端协作、安全和 SuperAgent 契约不需要新增 Foundation 修改。父 M012 已有的相关记录保留。不更新历史导入文档或原始 Word / Excel；它们仅作为冻结输入，不作为当前契约的可编辑副本。

13. 实施与验证记录

• 已新增 scripts/generate_rate_room_directory.py，同一冻结工作簿同时生成服务端目录、Skill 受控副本和 V27 数据迁移；生成器通过 schema、source、semantic duplicate、cross-reference、candidate 重算、policy、manifest 和 Golden 守门。外部 exact-hash Excel 与冻结 Word 已通过只读 --check，可逐字节复现全部生成物。
• 已新增 RateRoomDirectoryLoader -> RateRoomDirectoryValidator -> RateRoomDirectorySnapshot：启动顺序固定为 manifest envelope、原始 JSON bytes SHA-256、strict JSON、207 行完整业务一致性，再构造不可变索引。核心不引用 Layer 3/4/5/6 DTO。
• compatible-input 接受 21 个基础码和 40 个历史 alias；canonical-output 只接受精确的 10/21 代码。Layer 4 按公司级配置消费缺价默认：Q.B.D → GRPA1，LIANTAI ONLINE/DY / LIAN TAI → GRP1；适用于所有房型，包括独立套房。
• 完整 Roomtype authority 以独立 schema v4 correction set 附着于不可变基础目录；原 207 行、V27 与基础 Golden 均未改写。 Layer 4 只对唯一 exact-normalized 候选输出单值；一个多候选和两个无映射标签 fail closed；Booking Skill 仍未发布。
• 最终0812 Excel已通过独立生成器形成213行effective mapping与sidecar manifest；RateRoomEffectiveMappingLoader -> Validator -> Snapshot提供按公司/规则集/邮件房型/价格的不可变候选查询。Layer 4 已消费该 Catalog，并按不同的 {Rate Code＋早餐＋餐厅} 套餐判断唯一性。
• 2026-08-13 最终 Resolver 政策：QBD 固定输出一个GROUP_AND_FIT option；普通 LianTai 固定同时输出 LIANTAI ONLINE/DY / FIT和LIAN TAI / Group两个 options。Layer 5 按房量决定 Booking Type 后只能取对应 option。 冻结 0810 基础目录不重写，QBD 旧 Group 标签仅保留 provenance。
• 已新增 ReservationV4RateRoomDirectory 并替换手写目录 seed；新输入在 intake / command 路径规范化历史组合 code，查询路径保留已存历史值，新的 RATE CODE lookup 仅返回 21 个基础 code。
• 已将 breakfast_included 与 breakfast_restaurant_code 收敛到目录解析器；后者只作为 Room Information 的后端派生只读字段返回，前端不接收价格也不自行推断餐厅。
• 已完成 booking-desk-event-block10.1-rc1 的源目录、0812 映射 reference、fixtures、静态验证和确定性 .skill 打包；候选 archive SHA-256 为 86ec5634cb16fbd4a121ed0c519aaa107cf6d205c8ee6d4b2a874fcab27be0ba，manifest 含 27 个成员哈希并固定 publication_status=HOLD。该事实不代表其业务决定已被系统 Resolver/Validator 接管。
• schema v3 删除记录和旧 4/5 目录预选仅作历史证据。当前 schema v4、双 Rate options、无数据库历史的 Layer4、 Layer5 Candidate 与 Layer6 等值校验已实现；Parsing Agent 最终V2交接和当前附件文件名型Rooming List resolver 已由后续专项本地验收。最新业务验收、真实Provider与 Skill publication 仍是独立门禁。