feat: add date-based OHIP data reporting alongside XML

This commit is contained in:
Wyndham ARR committed 2026-09-18 15:29:27 +08:00
1 parent 5ecd571e3b
commit ad2c59256f
259 files changed
+37326 -126

No files matched your search

+722 -1
View File
@@ -1,9 +1,405 @@
# Current State
## 2026-09-18 — 按用户指定仓库整理最新代码交付
用户明确确认酒店由OHIP平台决定、本机核对OHIPSB02,生产切换时再调整;两条路径(接口数据、用户XML)并行且共用后续规则。
本次发布目标为https://git.nianxx.cn/shiyuyun/ARR-2.0-0918,初查无远端分支;保留原wyndham-ARR远端,不强推覆盖。
发布范围包括当前源码、处理器包、019迁移、模拟测试、接口参数清单和生产交付说明;本机私有凭据、原始业务响应、队列、输出、环境和规划目录不纳入。
README已明确两条入口及生产启用条件;发布验证和结果见任务记录。上传代码不等于生产部署,不启动新取数或重启当前服务。
本次发布前回归:146项Python(含独立临时PostgreSQL全流程)及9项JS全部通过,无跳过;JS语法及文档检查通过。发布方式为提交本地main后普通推送到新远端arr0918的main,并回读核对提交;原origin保留。
## 2026-09-18 — 接口传参清单已整理,供用户确认
按用户请求新增[实际传参确认单](../../ARR_OHIP_REQUEST_PARAMETERS.md):8接口的方法/路径/参数/来源/补查条件、页面到任务参数及酒店路由边界。
实际调用请求构造函数生成8份虚构示例,无网络、凭据读取或业务任务。没有改代码、规则或配置。
关键待确认范围已显式列明:预订列表只传到店日期/分页/排序,没有显式预订状态/分房状态;Comments没有额外内部备注开关。未传条件不能据此认定平台默认返回全部状态或备注。
房间日历未传预订ID(本地关联),套餐结束日为离店日;查不到预订当前结束采集并提示异常,不生成空日报。
接口开发完成结论保留,查询覆盖和真实返回验收仍待确认;本轮不自行扩大查询或触发取数。
## 2026-09-18 — 自动取数开发收尾完成
用户要求收尾并询问生产能否完成自动取数和报表处理。已整理[生产交付说明](../../deploy/OHIP_RELEASE_HANDOVER.md),明确开发/模拟/交互已完成,生产配置与首日真实数据验收待执行。
核对发现基础Compose尚未传三个OHIP参数/挂载私有目录,019需在018之后升级,独立月报worker需持续运行;固定平台/应用身份、酒店路由校验和booking_test数据库边界保留。
正式环境未提供,不擅自修改这些边界或启动部署。已纠正入口文档旧服务名和架构文档“尚未衔接处理”的过期说明。
2项部署入口检查通过,CLI参数核对通过;处理器zip/skill各8个关键文件与源码一致。本机无Docker,本次未构建生产镜像。未新增取数、停止原任务、重启服务或操作生产。
本阶段关闭。后续为正式环境配置,然后在有数据且开始验收时核对字段和报表,不再反复要求当前无数据沙箱出报表。
## 2026-09-18 — 字段接口接入已完成,用户说明测试环境无数据
用户明确当前测试环境无数据,现阶段无法核对实际结果,重点是确认字段对应接口是否接入。
只读核对代码:15字段由8个查询操作覆盖,日期参数、页面按钮、直接处理/日报/复核/月报均已衔接;团队读取权限此前已补齐。
状态为“接入完成,待有数据后验收”。测试环境无数据是用户提供的条件,本轮未自行查询或判断全平台数据状态。
不把实际报表结果核对作为当前必须推进事项,不新增/重试现有任务,不主动恢复实际取数验证。
## 2026-09-18 — 用户确认日期选择交互通过
用户明确反馈“OK了交互方式没问题”,本次页面内日历、运行中预选日期的交互验收关闭。
保留现有交互,后续关注用户已发起任务的状态和日报/月报结果;不得把交互确认当作实际取数成功或新增取数授权。
本轮仅记录验收,无代码、服务、任务或业务数据变更。
## 2026-09-18 — 日期选择与正在进行的任务分离
用户截图确认红框日历因原9/15任务运行而禁用,现允许预选下一日期,轮询保留用户所选值;仅提交瞬间短暂禁用日期。
运行中下载按钮仍禁用;不明结果/中断任务继续核对原编号、日期,继续按钮注明原日期。预选不会自动下载、改原任务或停止原任务。
原8875实际点日历→9/17成功,后续页面更新仍为9/17、进度仍为9/15;点日期文字也可展开。验证后恢复原显示日期,准备展开日历供用户操作。
9项JS提交/恢复检查与27项Python回归通过。没有新增或重试取数、重启服务、修改业务数据或委派。
下方“任务运行时锁定日期”的旧交互已由本条取代,任务身份与提交保护仍保留。[证据](../50-evidence/topics/2026-09-18-arr-calendar-selection.md)
## 2026-09-18 — 日期选不中已改为页面内日历并实际点选验证
用户明确故障出现在下载前,上次仅扩大原生点击区未解决,已撤回该完成结论。ARR日期框现使用页面内日历,保留YYYY-MM-DD、原日期校验及任务锁定,补充运行中/继续原任务的锁定原因。
独立只读8877中实际点击9/15、跨月点击8/31均更新输入值;键盘跨月和英文Report date点选成功。27项Python及5项JS检查通过。原8875已刷新加载新控件。
复查时已有用户06:13:51Z发起的9/15任务,原request_id保持、attempts=1,仍在获取;修复没有创建/重试/停止任务或重启服务。运行中日期锁定是正常状态,结束后可用新日历。不要再把“弹层打开”或fill改值当作鼠标选日验收。见[证据](../50-evidence/topics/2026-09-18-arr-calendar-selection.md)。
## 2026-09-18 — 修复Download ARR日期框难以点击
用户反馈日期点不动;确认日期未禁用,但仅小日历图标能打开选择器。已把原生日历点击区域扩大到整个日期框,保留原图标、日期编辑和任务锁定。实际浏览器点击文字/中部均打开日历,修改值可以保留;23项Python及5项JS检查通过。已刷新8875并恢复原日期2026-09-17,未查询订单、创建任务或重启服务,所需权限仍齐全。见[证据](../50-evidence/topics/2026-09-18-arr-date-click.md)。
## 2026-09-18 — 团队读取权限已补齐,OHIP下载按钮已启用
用户通知同事已完成授权。06:00:56Z运行既有check-access,仅读取开发身份、应用与密钥状态,返回ready=true、无缺项。应用现有blocks.read/configuration.read/finance.read/hotel.read/profiles.read/reservations.read;原密钥有效。额外hotel.read、finance.read由平台同事配置,ARR未调用,也未修改平台授权。
浏览器原8875页面刷新后显示“可下载所选日期的报表”,下载并处理按钮已启用,旧缺权提示消失。未重启服务、点击下载或实际查询酒店;当前任务数0、source归档不存在。
本机入口已就绪,本轮权限阻碍关闭。继续遵守不主动实际取数的要求,由用户在页面选择日期并主动发起。后续不要直接apply旧需求清单,以免覆盖平台已有额外权限。
见[开通证据](../50-evidence/topics/2026-09-18-arr-ohip-activation.md)。本轮仅配置状态及记录更新,无业务代码变化,无需重复离线测试。
## 2026-09-18 — 本机OHIP沙箱入口配置完成,等待团队读取权限
用户授权配置连接后,本机8875已切换为OHIPSB02的OHIP数据来源,沿用原登录信息;新私有本机库/对象/队列,原模拟实例完整保留。页面已登录核对,人工XML入口保留;没有真实查询任务。
平台现有configuration.read、profiles.read、reservations.read,缺blocks.read;开发身份无法在保留configuration.read的同时apply完整权限,403 capability_ceiling_exceeded。未修改授权、删除旧权限或签发新密钥。
用户已转达同事,并表示加好后通知。当前下载按钮暂停并显示具体原因;其余本机配置完成。收到通知后执行local_ohip check-access,仅核对权限并恢复按钮,禁止顺带实际取数。
7项新增及相关回归共37项通过(含本机真实隔离数据库,无skip);实际启动/登录/页面验证通过,零酒店业务调用。
没有子智能体、远程业务库/OSS或8873/8874操作。新运行目录和恢复方式见[本轮证据](../50-evidence/topics/2026-09-18-arr-ohip-activation.md),[给平台的说明](../../integrations/ohip/PLATFORM_ACCESS_REQUEST.md)。
## 2026-09-18 — 用户确认交互验收通过
用户在本机8875登录恢复后确认“ok交互没问题”。记录为新增按日期获取入口的页面交互验收通过。
当前交付状态:15字段接口接入、直接数据处理、原规则复用、价格复核及日报/月报已完成开发和本机模拟验证;
使用说明及运行配置已整理。下一阶段为目标运行环境的配置与启用安排,不重复调整已确认的交互。
此确认不扩展为实际沙箱取数验证或正式上线批准;原“跳过实际取数验证”要求继续有效。
本轮仅更新项目记录,无代码、运行实例、业务数据或平台调用变化。
## 2026-09-18 — 本机8875登录连接恢复
用户看到Failed to fetch;确认8875无监听,Web进程已退出,原测试数据库仍运行。仅核对并停止本实例遗留的数据库进程,保留全部记录后恢复。入口现由用户会话launchd后台运行,标识com.arr.local-direct-data.8875,配置在实例service.plist;不依赖对话执行进程。后台需LC_ALL=C/LANG=C,否则本机PostgreSQL启动时报locale/thread错误;已配置。未安装系统或开机自动启动项。
核验:healthz200、使用现有login.json登录200、认证会话200;原任务仍succeeded,Oracle连接false。未新增业务任务、未重新取数、未操作8873/8874。未修改应用代码。
## 2026-09-18 — 接口数据已直接接入按钮、复核与报表
按用户“继续”完成直接数据处理:选日期→15字段查询→共用筛选/去重/定价→独立核对→日报、价格复核、Finance及月报。
不生成中间XML;原XML入口保留。新来源明确为source_data/ohip_json,结果5.0,处理器4.2.0;XML4.0及旧3.0兼容保留。
迁移019仅在独立本机库使用,正式启动会检查迁移;正常OHIP启动需显式三项配置,构造服务不实际取数。
最终137项整体验证(含12项新入口检查,其中4项真实独立本机数据库)及83项相关回归、5项JS检查全部通过。
浏览器真实点击成功:6笔模拟订单/总额18200、日报/月报下载、刷新和服务重启恢复、桌面/手机、人工上传可用。
新演示页8875运行中,登录信息在私有实例login.json;不连接Oracle。原8873/8874未重启或重置。
未实际查询酒店、读取平台凭据、扩大权限、上线,未创建子智能体。已从“待开发加工衔接”推进到本机可体验。
见[入口说明](../../arr_web/DIRECT_DATA_ENTRY.md)、[ADR-007](../10-decisions/ADR-007-direct-ohip-data.md)、
[验证与实例信息](../50-evidence/topics/2026-09-18-arr-direct-processing.md)。
接下来为用户体验反馈和明确环境启用;不自行恢复实际订单验证。
## 2026-09-18 — 15 字段取数入口已实现(无实际订单验证)
用户要求直接接接口、跳过实际取数验证。新增 `integrations/ohip/arr_data.py` / `data_client.py`,
按单日查询预订并补查所需公司、主客、日价、团队、房间历史和套餐,直接输出15字段JSON,不生成XML。
明确区分有值/空/缺失/多候选/失败;保留多值原文和响应出处;完成请求可固定复用,失败重试保留旧尝试。
41项新增本机检查及相关回归共150项通过,含loopback HTTP、6笔样本原有定价函数结果(总额18200)。
没有实际酒店请求、凭据读取、授权变更、数据库/OSS写入、子智能体或运行实例操作。
现有页面执行器仍走XML;当前已交付取数程序,下一步是直接数据处理及其校验/复核/入库衔接,再连接页面。
不再把下一步写为“先验证真实订单”,除非用户后续改变这条要求。
见[使用说明](../../integrations/ohip/DATA_SOURCE.md)和[实施证据](../50-evidence/topics/2026-09-18-arr-data-interface.md)。
## 2026-09-18 — 当前重点:按字段接通 OHIP 数据入口
用户明确保留人工 XML 上传,同时新增按所选日期查询 OHIP 数据、直接按相同业务规则处理的入口;
不再以取得或重建 XML 为前提。当前优先事项是按 `ARR_XML_RAW_FIELDS.md` 接通对应接口,
自动入口共 15 个业务字段,Trace 不获取。公开目录/接口说明实时核对为 0.11.0、184 项操作,
预订、日价、档案、房间历史、团队及套餐查询均已列出;这不代表本轮实际沙箱字段取数通过。
[逐字段对接表](../../ARR_OHIP_FIELD_MAPPING.md)记录现有取值、组合查询及待验证项。
本轮仅新增对应表与项目记录,无酒店业务调用、权限修改、代码或运行实例变更。
后续按字段验证和补齐取数,不把历史 XML 显示等价条件作为所有数据入口工作的前提。
本对话沟通约定:使用产品语言,每次沟通末尾说明下一步;默认独立完成。
只有预计大幅提升效率时才可征求子智能体许可,得到用户同意后原则上最多创建一个。
## 2026-09-18 — 本地模拟数据补充
用户正在评估通过业务接口取数后按 ARR 规则加工,并要求补造部分测试数据。已新增独立的
[`arr_api_synthetic`](../../tests/fixtures/arr_api_synthetic/README.md) 数据包:6 条正常样本、8 种异常场景。
现有加工函数已核对 6 条正常样本及 3 种异常;另 5 种仅有样本和预期要求,尚未验证接口接入实现。
这不代表 Oracle 接口、完整 Excel 链路或真实取数规则已通过。未写入 Oracle、OSS、数据库,未操作 8874。
下一步是离线验证接口数据接入加工层,再以测试酒店实际返回验证关联规则;不继续把模拟结果作为原生下载证据。
本条为新增离线数据的进展说明,下方历史核验记录保留。详见[核对范围](../50-evidence/topics/2026-09-18-arr-synthetic-business-data.md)。
## Current Focus
Room-type continuation: official Oracle ROOM_CATEGORY_LABEL definitions support the room-type code, and all139 captured
records agree at search/current/arrival-day levels. Added strict selection (fields/v3, preparation/v4),4 new/98 scoped
checks and independent139-row comparison pass. Other candidate fields and oldfacts are byte/structure unchanged.
No dictionary query needed. Package22 records/30 items include8 multi-package records; all60 schedule dates coincide,
so timing/combination rules remain unproved. Search24 Group names match exact Profile IDs in detail; no missed company
or travel-agent role was found. No hotel requests/agents/8874 changes. No user reconfirmation needed for this authorized
technical work. See [room/package/company evidence](../50-evidence/topics/2026-09-17-arr-room-type-and-package-scope.md).
Existing-source correction:26 of139 RSV records already carry typed `BlockCode` alongside the separate Block ID.
Search/arrival-day identities and codes all agree (4 blocks);113 missing block objects remain explicit gaps.
`source_fields/v2` and preparation/v3 now select those codes, with9 new/94 scoped tests and independent139-row offline
comparison passing. Old field-facts bytes/native XML/851-file archive unchanged. No getBlock calls or permission expansion
needed for these26. Real adapter/validator still pending; recording8874 untouched. See
[typed BlockCode evidence](../50-evidence/topics/2026-09-17-arr-typed-block-code.md).
User confirms the technical request has been sent to platform developers. Await their diagnostic/evidence reply;
do not ask for another forwarding or infer the agent sent it. Independent button/local simulation work and identified
backend fixes are complete. Remaining actual-source mapping/integration depends on those specific inputs. Keep8874
unchanged; no repeated polling/audits or speculative code while evidence is unchanged. On a reply, assess which gaps
it closes, complete supported mappings and independently validate them in a separate instance.
User asked whether source evidence needs manual confirmation, then continued the responsibility triage. Clarified:
no new user business decision is currently pending; existing date/GEN/Trace choices stand. ARR owns mapping, independent
validation and integration; platform/test-environment owners supply diagnostic results and applicable same-source
evidence. Prepared the [technical request](../../integrations/ohip/arr-platform-evidence-request.md) with existing
request IDs and closure criteria; [source handoff](../../integrations/ohip/real-source-handoff.md) now separates owners.
No new hotel/public-network calls, code/tests, agents, messages or recording-instance changes in this clarification.
Next obtain specific evidence, resolve mappings and verify separately; no per-download source-confirmation step added.
Fixed a real PostgreSQL/Web failure-receipt mismatch found during source handoff review: rejected audit IDs were
misread as invalid Finance success evidence, leaving definite failures interrupted/retryable. Receipt conversion now
accepts the rejection ID with null version number;46 scoped tests including9 real disposable SQL cases pass.
No live8874 change/restart or new hotel call. Interface task has returned a dependency handoff, not a real adapter;
next requires sufficient source/report evidence before isolated actual-source integration. See
[failure-receipt evidence](../50-evidence/topics/2026-09-17-arr-rejected-receipt.md).
Real-source task handoff audit: current public catalog remains0.9/158;getBlock/getRoomTypeInfo/getPackage definitions
are published.4 public reads/0hotel requests. Real adapter and independent mapping validator are still not delivered:
name/historical-room/company/report inclusion-order semantics lack sufficient evidence; no guessed blanks, mock imports
or always-refusing placeholder added. The fixed139-row sandbox batch also has115non-whitelist/24missingrate codes,
so it cannot be a successfulFinance positive even after mapping completion. Minimal external dependency and component
restart boundary are in [real-source handoff](../../integrations/ohip/real-source-handoff.md). No code or8874 recording
instance changes; user must not be told actualARR is ready. See [audit evidence](../50-evidence/topics/2026-09-17-arr-real-source-delivery-gap.md).
User reconfirmed interaction acceptance and continued backend work. Explicit standard-Web source assembly is now
implemented with shared upload processing dependencies, pinned pre-dispatch source identity and orderly queue/storage
shutdown. Local owner shutdown race reproduced and fixed.91 distinct scoped tests pass, including3 owned SQL cases;
default CLI remains source-unconfigured. Source task has no new real adapter/validator delivery. No changes to the
running recording page/data, hotel calls, deployment or agents. Next actual-source mapping/independent acceptance,
then explicit source injection and bounded real-data integration. See [runtime evidence](../50-evidence/topics/2026-09-17-arr-download-runtime.md).
User accepted the ARR button interaction and requested a clean customer recording start. Local8874 was cleared with
a recoverable cold backup:6 prior tasks/6 daily/432 records/6 monthly are archived, current queue/SQL histories now0.
Same source fixture/date9/15 and login credentials; service ready, browser authenticated on empty daily page.
Do not submit another test before the user records. See [cleanup evidence](../50-evidence/topics/2026-09-17-arr-recording-cleanup.md).
Earlier integration counts below describe completed historical acceptance, not current live records.
The existing ARR card is now browser-integrated against local API8874: unavailable-date lock reproduced/fixed,
then9/15 double-click→one new152-call capture→61 retained→daily/monthly downloads. Reload and same-request replay
keep the same job. SQL totals changed from1 to2 versions/events/monthlies and72 to144 records, preserving the earlier
run; all61 new monthly formulas verified.5 new JS and34 regression tests pass. No subagents, Oracle calls or production
changes. The working page remains open. Next: user acceptance of this local button flow, followed by actual-source
mapping/acceptance when available. See [button integration evidence](../50-evidence/topics/2026-09-17-arr-button-api-integration.md).
Local API simulation is now separately usable at127.0.0.1:8874 (sidebar logged in). XML-derived72-row fixture →
152 actual loopback HTTP calls → generated processingXML/native comparison →61retained/11excluded → one isolatedSQL
version/event/monthly. Daily cells match native replay except user-excludedTraces; monthly61formulas pass. Restart
preserves results.91 scoped tests and real browser desktop/mobile/download/restart pass. No platform calls/agents or
booking/production changes. Native replay8873 remains available. Local full-flow/button milestone explicitly notified;
actual Oracle fullARR acceptance remains pending. Initial one-run acceptance is preserved below; the subsequent
button integration above adds one explicit fresh run while keeping Oracle source semantics acceptance separate.
See [API simulation evidence](../50-evidence/topics/2026-09-17-arr-local-api-simulation.md) and
[button/operator guide](../../arr_web/LOCAL_API_SIMULATION.md).
Isolated native XML replay is now usable at127.0.0.1:8873, sidebar browser logged in. Exact72-row9/15 XML processed
with current policy into61 retained/11 excluded; actual SQL confirms one version/event/monthly run; downloads and61
monthly formulas verified. Restart preserves same results.9 new+75 related tests pass, browser desktop/mobile passes.
Explicit local banner/cookie/filename prefix and separate owned private socket-only PostgreSQL/objects. No hotel calls,
agents, production settings or booking simulator changes. This is the local button milestone, not complete API ARR.
See [replay evidence](../50-evidence/topics/2026-09-17-arr-local-xml-replay.md) and [entry guide](../../arr_web/LOCAL_XML_REPLAY.md).
User clarified the booking project's current business execution is a local simulated hotel, not Oracle sandbox.
Read-only CP31/CP33 docs confirm that distinction and warn its in-process hotel state is lost if rebuilt. Recommend an
isolated ARR local instance for native XML replay and separately labelled API simulation; do not reset/share the active
booking instance implicitly. At that clarification checkpoint no import had occurred; the later replay result is above.
Earlier ARR platform captures remain separate evidence.
See [shared-hotel context](../50-evidence/topics/2026-09-16-shared-hotel-rsvn-context.md).
The ARR platform live-read target isOHIPSB02 sandbox. Calendar200 withoutroom is a data/coverage unknown,
not a diagnosed platform defect; do not frame platform repair as a prerequisite for every remaining development task.
Separate callable-contract, sample-coverage and real-report acceptance. Continue local/sandbox-contract integration where
possible;57106 XML cannot demand matching sandbox records.503 remains a real call failure. No readiness flags changed.
Authoritative boundary: [source contract](../40-domain/arr-source-report-contract.md#当前沙箱与验收边界).
Room/calendar continuation:13 new/71 scoped tests pass for bound single-page evidence, exact reservation/hotel joins,
all room occurrences/moves, original time zones and missing-vs-empty distinction. Existing3 responses still omitroom;
851 main files/17 probe files/nativeXML verify unchanged. Native72 ROOM_NO=DISP_ROOM_NO;10 CKOT also equalLAST_ROOM,
so fallback/selection rule remains unproved. Official pinned Postman example has reversed dates/no responses and does
not verify assignment defaults. No new hotel/credential/delegation/runtime actions. See
[room evidence](../50-evidence/topics/2026-09-17-arr-room-calendar-evidence.md). Need actual room-bearing responses plus
same-source semantics; completeARR/button milestone pending. Do not retry solely on elapsed time.
ARR name dependency correction: completev2 main captures are independent ofsearchProfiles. Added separately pinned
profile supplements, bounded failure/deferred gaps, chain-verified reuse of good names and retry of only missing profiles.
Connected optional supplements to local candidate preparation; oldv3/replay and default runtime stay unchanged.
131 scoped tests pass,12 new.139-row/851-file base,72 failedv3 files,14 earlier probe files and nativeXML verify unchanged.
No hotel calls/credentials/delegation. Direct display-name formatting remains sample evidence, not report acceptance.
See [decoupling evidence](../50-evidence/topics/2026-09-17-arr-profile-decoupling.md).
Next: use repaired/new evidence for bounded name/room checks and source acceptance; completeARR/button notice pending.
Local XML-upload improvement completed: processor4.1.0 ignores recognized emoji in text and narrowly recovers CESU-8 emoji while retaining original source bytes/hashes. Original71052877 now passes with4 ignored/67 retained;71052708 remains100.122 distinct Python/3 JS checks verified, including independent replay and frozen legacy behavior. Not deployed to the remote ARR runtime. See [emoji cleanup evidence](../50-evidence/topics/2026-09-17-xml-emoji-cleanup.md).
Latest reported-repair verification: catalog0.9.0/158(+43), getRoomCalendar now published under existing read permission.
Six business reads/own audits: original failed profile still503/25004ms;3 calendar200 responses are metadata-only with
no room/page/hotel totals;2 exact zero-night CheckedOut summaries match identities/dates but still lackroomId/shared=false.
No full-day restart, permission/key/runtime/production change. User explicitly approved1 read-only catalog reviewer under
new ask-first/normally-one policy for today.851+72 old files/native XML unchanged;21 new probe files privately verified.
[Current evidence](../50-evidence/topics/2026-09-17-arr-platform-recovery-recheck.md) and [platform request IDs](../../integrations/ohip/platform-recovery-check-20260917.md).
Next upstream failure/empty-calendar diagnosis; completeARR/source acceptance and button milestone remain pending.
Overnight continuation: delivery now checks the caller's complete capture binding/current policy before destination
writes; shared job and package identities reject numeric JSON type aliases. Executor collection/page limits are explicit,
validated and frozen.112 distinct scoped tests pass:38 batch,65 executor/handoff,2 package/recovery and7 real isolated PostgreSQL scenarios. v3 lost-COMMIT recovery makes no new profile reads and keeps one version/outbox event. No hotel,
network, credentials, production writes/runtime activation or subagents. See
[delivery and bounds evidence](../50-evidence/topics/2026-09-17-arr-delivery-context-and-bounds.md).
Remaining work needs profile recovery, reservation-bound historical rooms and same-source report semantics; it is not
only503. No new request for user materials. Full actual ARR/button milestone remains pending.
User requests all work independent of503 without repeated questions; no subagents. Completed integrated16-field source
preparation and opt-in v3 executor/profilebudget with typed immutable request identity.237 scoped tests pass (212 source,
25 executor). Real139 records retained:139 confirmations/dates/counts/notes,115 codes,73 agreed rooms,134 rates;
allrows keep unresolved display gaps.851+72 original files/native XML unchanged. Only2 public catalog reads, no hotel
calls/credentials or production/runtime activation. Catalog115ops/getRoomCalendar404 unchanged. See
[offline preparation/v3 executor](../50-evidence/topics/2026-09-17-arr-offline-preparation-and-v3-executor.md).
Next external repair/historical-room/same-source evidence, then accepted mapping and runtime wiring. The local candidate
preparer is not an adapter/independent business validator; completeARR/button milestone remains pending.
Latest independent work connects completev3 name captures to versioned field evidence and native comparison.19 new
cases/198 scoped tests pass; verifier independently derives raw Primary Profile joins and successful request provenance.
Missing query/field/blank stay distinct; exact and trimmed display names are separate observations. Replay rejects
JSON boolean/number aliases. Old139-row evidence is byte-identical;851 old and72 failedv3 files/native XML unchanged.
Five real names support primitive checks only; failedv3 remains rejected and no full ARR was produced. User has shared
503 diagnostic with platform. No new API/credential/Finance/runtime activity or subagents this round. See
[named evidence](../50-evidence/topics/2026-09-17-arr-named-field-evidence.md). Continue independently under the latest
no-subagents instruction; next recovery evidence/bounded acquisition and remaining historical-room/source acceptance.
Latest user“继续”authorized the concrete one-batch scope (139 reservations/112 profiles, OHIPSB02/2026-09-15).
The v3 live attempt stopped after23 requests:19 HTTP200/4 profile503, all matched own-app audits.139 search candidates,
6 successful details/rates,5 valid names; the6th primary profile exhausted3 attempts. Another profile recovered503→200.
Errors are auditedohip_unavailable/~25s/internal retry2, not a proved root cause.72 new private capture files verify;
complete-archive reader rejects this failed batch. No new whole attempt, delegate, code/grant/runtime or Finance write.
See [live failure](../50-evidence/topics/2026-09-16-arr-named-day-live-failure.md) and refreshed
[platform diagnostic](../../integrations/ohip/profile-summary-platform-check.md). User has since shared it; the agent has not sent it.
Bounded v3 name capture/replay/batch reuse retains the217-test local baseline. Original3 real responses pass offline;
139 old reservations contain112 profiles,851 originals/native XML unchanged. Next platform503 diagnosis/repaired full-day
acquisition and source acceptance; completeARR/button milestone pending. Latest2026-09-17 user instruction prohibits
subagents for subsequent work, superseding the earlier one-agent preference. Continue independently.
Earlier user-authorized22:21 profilePOST recheck succeeded for all3 original people: HTTP200, audit agreement, matching
Profile IDs/Primary name components and nonblankfullName. nameType is absent; GET not retested.503 was then considered
recovered for those samples; the later full-day failure above reopens platform investigation. See [recovery success](../50-evidence/topics/2026-09-16-arr-profile-recovery-success.md).
Independent work also fixed freeze-before-ready recovery with a durable pre-rename intent pin; full byte/context checks
precede ready repair, old unpinned packages stay rejected, completed legacy packages work. Added early cumulative archive
budget checks and bounded failure finalization.164 distinct scoped tests pass;139 records replay offline/851 originals
and native XML unchanged. Two newly authorized read-only reviews completed; no concurrent Web code/runtime changes.
Room-calendar public catalog recheck remains404. Next bounded name-collection integration and historical-room/source
acceptance; completeARR/button milestone pending. See [freeze recovery](../50-evidence/topics/2026-09-16-arr-freeze-recovery.md)
and [acquisition budget](../50-evidence/topics/2026-09-16-arr-acquisition-budget.md).
Earlier21:55 profile recovery recheck: user reported503 might be fixed; one exact-ID POST for the first of the previously
approved3 people still returned503/ohip_unavailable at2026-09-16 21:55 Asia/Shanghai. Edge audit confirms25009ms and
internal retry_count2; client made1 attempt with40s deadline and received the error in26.93s. Stopped before other2/GET.
851 capture files/native XML unchanged; no code/permission/runtime change or full ARR output. Next platform investigation
should use request ID`acea6692-25d7-4711-bcb6-3cd5916e3f5c`, then recheck the same sample upon new recovery evidence.
See [recovery evidence](../50-evidence/topics/2026-09-16-arr-profile-recovery-recheck.md).
Previous continuation consolidated the [minimal platform handoff](../../integrations/ohip/arr-platform-next-actions.md):
repair profile-summary503 (user says not repaired/unknown), and verify reservation-bound historical rooms for2 captured
CheckedOut zero-night/non-pseudo records lacking room values. Native10 CKOT rows retain display/last room, but are another
hotel, not paired proof. Suggest getRoomCalendar read/equivalent; company display needs same-source evidence, not another
blind API addition. No hotel retry/code/delegation;851 capture files/native XML unchanged, complete ARR still pending.
See [follow-up evidence](../50-evidence/topics/2026-09-16-arr-minimum-platform-followup.md).
Room/profile source agreement is implemented: matching reservation/hotel/day before three explicit room values,
and caller-selected role/internal Profile ID/raw-name agreement across reservation/day layers.10 new/133 tests pass;
139 offline rows give73 room agreements and24 Group agreements despite external-ID differences.1 current/search-only
room and65 missing all room fields remain distinct; company absence is not inferred from missing association containers.
851 originals unchanged. Public catalog getRoomCalendar exact lookup404; Oracle schema offers room-history/segments
as a candidate to assess, not a proven required extension. No hotel calls/delegation/Web activation or complete ARR.
See [room/profile evidence](../50-evidence/topics/2026-09-16-arr-room-profile-selection.md).
Source selectors now also preserve all exact GEN/RESERVATION text, select equal explicit stay/day adult/child counts,
and expose arrival-day raw numberOfUnits without asserting report share semantics.10 new/123 scoped tests pass;
139 real offline records agree with the independent comparator,851 originals unchanged.29 records contain30 GEN notes,
including3 internal;1 multi-note record is order-sensitive for first note/Group Code. No report-order inference or
whole-batch business gate added. No new hotel calls, delegation, Web change or complete ARR output. Next narrow company
and room source rules while profile summaries await recovery. See [note/count evidence](../50-evidence/topics/2026-09-16-arr-note-count-selection.md).
Direct source selectors now implement typed confirmation, explicit stay dates, strictly single-day rate codes, bound
raw Decimal rate/currency and empty Trace.12 new/91 scoped tests passed;139 pinned rows yield139 confirmations/dates,
115 codes (24 missing),134 prices (3 hidden/2 missing currency);851 originals unchanged. No XML/source acceptance.
User approved profiles.read and at-most3 primary guests. Acknowledge/validate/apply/read-back completed on the same
application and original key, preserving reservations.read. The single-profile summary helper has9 new/100 scoped tests.
Three POSTs and one same-person GET control all failed with audited503/ohip_unavailable after~25s; no name data verified.
Private originals/inventory and851 earlier files unchanged. No more approval needed for this permission; platform
endpoint recovery and later verification remain. No automatic monitor/retry, fourth guest, Finance or Web activation.
See [probe evidence](../50-evidence/topics/2026-09-16-arr-profile-summary-probe.md) and
[platform diagnostic handoff](../../integrations/ohip/profile-summary-platform-check.md).
User now explicitly says Trace is not needed. API-source output should supply an empty Trace list; Trace filter/order
acceptance is removed from the remaining blockers. Manual XML/history/generic serializer remain unchanged. Sort choice
was not supplied; the native72-row sample has no room/date duplicates, so do not keep asking the user about unfamiliar
settings. Offline capture coverage:115 present non-whitelist rate codes,24 missing,0 matching the hotel's unchanged rules;
851 files intact. No additional material requested now. See [triage](../50-evidence/topics/2026-09-16-arr-input-gap-triage.md).
User requests a separate notification once complete ARR data can be produced for button integration. This milestone is
pending and tracked in commitments; do not confuse candidate or synthetic output with complete API ARR.
Explicit-row XML serialization and independent structural/value verification are now implemented, matching the existing
25MiB handoff limit.13 new tests and37 related cases pass across scoped runs. Native72-row projection retains58 notes/31
traces and produces identical processing semantics (61 retained/11 excluded); originals/baseline unchanged. Accepted API
row/field mapping is still missing; no Web/runtime/Finance enablement. See
[output evidence](../50-evidence/topics/2026-09-16-arr-xml-output-boundary.md).
Offline source-field evidence is implemented for all139 pinned v2 records:16 target columns plus raw context, exact
types/Decimal values, missing/null/empty/multiple observations and original response/request provenance. A separate verifier
independently enumerates raw sources and paths;16 new/140 scoped tests pass.851 original files remain unchanged.
This is the foundation of source adaptation, not an accepted XML adapter/validator or Web runtime dependency; all business
readiness flags remain false. Resv.-GEN confirmation remains closed. Two explicitly authorized read-only reviewers completed
their checks; concurrent Web/PG code was untouched. See [evidence](../50-evidence/topics/2026-09-16-arr-source-field-evidence.md).
Download readiness now recovers from initial connection failure or service unavailability without a page reload. GET-only
checks preserve the selected date and saved request, coalesce, pause when hidden and resume on online/visibility events.
9 browser interaction tests and34 existing Web/auth/layout tests pass. No styling/source/runtime activation change; see
[reconnection evidence](../50-evidence/topics/2026-09-16-arr-download-reconnection.md).
Real PostgreSQL15.19 transaction acceptance now passes6 isolated cases: actual executor commit, concurrent exact delivery,
connection loss after COMMIT/restart replay, atomic rollback, manual-review completion and monthly/outbox replay uniqueness.
The private Unix-socket cluster used current008–018 schema and synthetic source/local objects, then was stopped and removed.
This does not enable real API sources/runtime. See [PostgreSQL acceptance](../50-evidence/topics/2026-09-16-arr-postgres-download-acceptance.md).
Explicit-date `CapturedARRExecutor` now connects v2 capture/replay, injected adaptation/independent mapping validation and
frozen processing.10 new synthetic orchestration tests pass, including checkpoints before delivery and recovery without
recapture after lost commit acknowledgement. No real source adapter/validator is supplied and no runtime is enabled.
See [executor evidence](../50-evidence/topics/2026-09-16-arr-web-capture-executor.md).
User accepted the card styling. Added strict frozen-delivery-to-Web outcome conversion and seven synthetic cross-module
tests;62 scoped tests pass, including lost-ack restart/replay and manual-review completion without recapture. Source mapping
and real execution remain unwired; this does not enable the download button. See
[Web handoff evidence](../50-evidence/topics/2026-09-16-arr-web-frozen-handoff.md).
Local UI preview entry was repaired on2026-09-16 after the raw `file://` HTML failed to load `/assets` and `/api`.
Run `.venv/bin/python -m arr_web.preview` and open `http://127.0.0.1:8872/`; this separate loopback-only runtime has
an explicit read-only banner, empty history and unavailable business services. The HTTP page was opened and visually
verified in the in-app browser;13 preview/auth/server tests pass. Production authentication and runtime are unchanged.
The single-day Web download card and durable task boundary are now implemented locally; the real executor remains
unwired/unavailable. See [card evidence](../50-evidence/topics/2026-09-16-arr-download-card.md) and
[executor handoff](../../arr_web/ARR_DOWNLOAD_HANDOFF.md).77 focused tests and10 synthetic browser checks pass;15 final
locale/viewport layouts pass. The UI suggests yesterday but submits an explicit selected date; the collector receives
equal fixed dates and never infers a missing date. No hotel/Finance/OSS call, deployment or delegation occurred here.
ARR2.0 owns the deterministic XML-to-Finance path and the complete post-commit monthly publication path. The user
uploads XML once. After an accepted Finance commit, a dedicated worker consumes the durable outbox event, derives the
month and “更新至” watermark from committed `ARRIVAL` facts, publishes a validated workbook, and records a durable
@@ -21,6 +417,331 @@ preserves its no-formula contract. Both publishers upload new workbook and `resu
immutable OSS adapter, while download routing retains controlled-local compatibility for historical records and keeps
`.web-jobs` queue state local.
## Accurate Native XML And Note Selection Confirmed On 2026-09-16
- User supplied res_detail_71054429.XML, explicitly accurate with page Note Types=Resv.-GEN. It is byte-identical to
res_detail_71050118.XML:354839bytes, SHA2565c87ab6f2483b2244e98e47bb792080ef4aca9036568638842116b246ac97438.
- XML lines91/93 contain RES_COMMENT_TYPE=CAS and RES_COMMENT_DESCRIPTION=GENERAL;58 notes share these metadata values.
These are internal XML fields, not evidence the user selected a different page option. Earlier wording implied a
business-selection discrepancy without sufficient basis; corrected. Baseline and page-selection confirmation is closed.
- Existing72-row/61-retained processing baseline remains applicable to the same bytes; no unnecessary rerun, business
submission or runtime change. Same-hotel/date API equivalence remains separate, as API is OHIPSB02 and native file57106.
- Next continue mapping the confirmed Resv.-GEN requirement to API data; do not ask again or replace it with CAS/all notes.
[Exact evidence and lines](../50-evidence/topics/2026-09-16-confirmed-native-arr-notes.md).
## ARR Display Contract Follow-Up On 2026-09-16
- Extended source comparison to42 independent hypotheses with company display prefixes and rate-day guest-count layers;
native-only privacy-safe summaries can run without a comparable API pair.40 tool tests/87 scoped tests pass.
- Native57106 XML:65 T-prefix company names,6 C-prefix,1 blank;71 names contain commas; room text ascends but all72 ROWNUMs
differ from physical position.58 notes are CAS/GENERAL, with no export parameter block. None proves role priority or sort settings.
- API139 reservations have equal valid stay/day adults and children;851 files and native XML remain unchanged. No hotel
call, business write, runtime change or delegation. Catalog0.7 public read confirms published rate operation; stale wait text removed.
- Earlier text clarification is now resolved by the accurate new filename and explicit Resv.-GEN confirmation above.
Internal CAS/GENERAL metadata does not change the user's page selection or authorize a different API note scope.
- Next source adapter still requires the accepted role/display/note/order/scope contract and independent mapping checks.
[Evidence](../50-evidence/topics/2026-09-16-arr-display-contract.md), [safe aggregate](../../integrations/ohip/arr-display-contract-20260916.json).
## API / Native Source Comparison On 2026-09-16
- User cannot currently access OHIPSB02 Opera for the matching native export. Do not ask repeatedly or treat hotel57106
XML as same-source acceptance. No new UI automation, hotel call or business write was performed in this continuation.
- Offline pinned v2/XML comparator is complete:32 independent field/format/role/scope observations, unique internal-ID
pairing, duplicate/only-in-one-source/order checks and bounded privacy-safe diagnostics. All readiness flags remain false.
- 32 new tests plus47 related regressions pass. Actual139-record OHIPSB02 capture versus72-row57106 XML correctly returns
not_comparable;851 original files and manual XML are unchanged. Source equivalence remains unverified.
- Official Cloud evidence excludes resolved/completed Trace and InSession GDS; neither proves other status/order rules.
Existing12 API Trace records have empty resolveInfo, so resolved exclusion is not covered. Company, display name,
report order/granularity and GEN mapping remain pending. Two explicitly permitted read-only agents completed their reviews.
- Next: continue evidence-backed source contract work; perform paired acceptance when same-environment input becomes
available, then versioned adaptation and executor/Finance integration. [Evidence](../50-evidence/topics/2026-09-16-arr-source-comparison.md).
## Complete Search/Detail/Day-Rate Capture On 2026-09-16
- User supplies From/To/rate date all2026-09-15. New v2 collector/replay/local batch entry accepts and freezes all three
explicit equal dates; shared v1 state/lock/retry behavior is preserved. Source adaptation and real Web executor remain unwired.
- 29 new tests,167 distinct relevant tests passed across the scoped runs. Catalog0.7 manifest now declares three reads,
acknowledges existing group-implied GET and passes plan/validate; no apply/grant/key changes.
- OHIPSB02/day2026-09-15:139 details and139 rate responses, both full search passes equal.283 transport attempts comprise
282 HTTP200 and1 recovered transport failure.134 valid amount/currency candidates (59 explicit zeros), allUSD;
3 InHouse rates suppressed and2 NoShow details lack base currency. Candidate capture complete, all_rates_valid=false.
- 851 private files pass hashes/protocol replay. Offline v2 batch replays283 stored attempts once and reuses the same pin
with0 new response reads on retry;851 current and432 v1 original files remain unchanged. No Finance/Oracle/OSS writes.
- Next: same-source field/range/order acceptance and source adapter, then connect the Web executor using stable capture/
frozen-package/Finance identity. Current missing names/company/rate codes and5 price diagnostics are not silently dropped.
[Evidence and pins](../50-evidence/topics/2026-09-16-arr-day-capture.md), [aggregate](../../integrations/ohip/arr-day-verification-20260916.json).
## System-Supplied Report Dates — User Clarification On 2026-09-16
- From Date / To Date are supplied by the upstream system; its current rule is T-1/T-1. ARR validates and freezes the
supplied dates, rather than calculating yesterday from a local clock/timezone or Opera business date. Current single-day
scope requires both dates to be valid and equal; search bounds and rate detailDate use that same day throughout retries.
- v1 collector/batch CLI require explicit arrival_date; new v2 accepts from_date/to_date/rate_date explicitly and checks
equality. No collector computes T-1. Web sends equal Python dates; accepted runtime executor wiring remains pending.
- Updated the [authoritative source contract](../40-domain/arr-source-report-contract.md), replacing the earlier provisional
ARR-side Asia/Bangkok date calculation. This clarification does not create a scheduler or alter existing evidence dates.
## Rate-Info Publication Verified On 2026-09-16
- User notification arrived; the earlier wait is satisfied. Edge catalog0.7.0/115 operations publishes recommended
POST searchRateInfo and deprecated GET getRateInfo under existing reservations.read; no grants/keys/apply were changed.
- Added separate [rate lookup primitive](../../integrations/ohip/rate_info.py) and contract excerpt.18 new tests plus99
existing acquisition/audit/XML tests pass (117 total). Minimal id/type/summaryInfo=false/detailDate request is sufficient
for the sampled test reservations; no repricing/currency override fields were sent.
- OHIPSB02,2026-09-15:5 distinct existing reservations (cross-day, package, zero, zero-night, ordinary),11 HTTP200 read calls,
all5 effective-price candidates valid in USD, first GET/POST equal. Package sample differs from base and matches total;
this remains a sample observation, not a replacement arithmetic rule. Raw37 files private and hash verified.
- POST lookup has since been integrated into v2 whole-day capture above; next complete source mapping/same-source report
acceptance. v1 archives remain search/detail-only. No Finance source adapter or production connection yet. See
[publication evidence](../50-evidence/topics/2026-09-16-rate-info-publication.md).
## Frozen Processing Handoff On 2026-09-16
- Added an isolated [frozen XML handoff library](../../integrations/ohip/processing_handoff.py), with21 new and131 related passing tests:
stable per-batch task identity, local processor/independent validation, immutable source/output/envelope preparation,
same-package upload/registration/commit retry, and recovery from lost acknowledgements without marking an uncertain commit failed.
- Tests use synthetic XML, filesystem objects and an in-memory repository; PostgreSQL exact-replay control flow also passes
with a simulated cursor. No live database, OSS, hotel/platform calls, deployment, grants or new delegation.
- This is preparation for an eventual accepted source adapter. It does not create XML from API data or prove source mapping;
source_mapping_verified remains false. Production wiring, authoritative package retention and real PostgreSQL concurrent/
disconnect/outbox acceptance remain open. Existing manual upload and price review are unchanged.
- The then-pending getRateInfo notification has since arrived; see the publication verification above. See
[handoff evidence](../50-evidence/topics/2026-09-16-arr-processing-handoff.md) and the existing field acceptance matrix.
## Retryable ARR Acquisition Batches On 2026-09-16
- User asked to progress non-price work while platform adds getRateInfo. Added isolated [capture-job utility](../../integrations/ohip/capture_job.py):
fixed batch identity/options, per-batch process lock, atomic private state, full-day fresh attempts after failure/interruption,
and completed-manifest verification/reuse before credentials or network are loaded. New ID explicitly requests fresh data.
- 20 new lifecycle/concurrency/crash tests and79 existing scoped checks pass (99 total). Offline139-record job first reads143
stored responses, second reads0 new responses and returns the same capture pin;432 original files unchanged. No hotel calls.
- This is local POSIX acquisition state only: no production distributed queue, scheduler, source adapter or Finance submission.
Existing manual XML submit still creates a fresh job. A later isolated frozen-handoff prototype above addresses retry
identity/unknown-result handling locally; production Finance integration/acceptance remains future work.
- No delegation used this turn; platform-ready notification remains with user. Details and resume boundary:
[batch evidence](../50-evidence/topics/2026-09-16-arr-capture-jobs.md), [run instructions](../../integrations/ohip/README.md).
## ARR Capture Readiness And Platform Handoff On 2026-09-16
- User coordinated platform getRateInfo addition and subsequently notified this task; the prior wait is now satisfied.
Two local read-only subagents were explicitly approved for this turn and completed processor/sample checks.
- Added a [manifest-pinned offline audit](../../integrations/ohip/audit_arr_capture.py) with raw-file integrity/protocol replay
and16-field candidate counts. Collector now returns its result-manifest digest.79 targeted tests pass;432 files/139
records verified without mutation or new hotel calls. No source conversion, deployment, grants or business writes.
- New concrete gaps: no complete displayed FULL_NAME despite unique primary-name components;396 rate segments all single-day,
so general date boundaries remain untested. Eight raw current-room collision groups can differ in rate/departure/notes.
Five zero-night records are valid; multi-room/shared-room scenarios are not covered.
- Confirmed validation precedes deduplication; later duplicate candidates cannot hide missing mandatory fields. XML replay
shares processor core functions and cannot by itself prove API-to-source mapping correctness. Existing rules unchanged.
- [Acceptance matrix](../../integrations/ohip/arr-api-acceptance-matrix.md) and
[readiness evidence](../50-evidence/topics/2026-09-16-arr-api-capture-readiness.md) specify resume steps once platform is ready.
Candidate availability is not value validity or report equivalence; Finance-ready flags remain false.
## ARR API Candidate Collector On 2026-09-16
- Added independent [read-only collector](../../integrations/ohip/collect_arr_source.py) for existing search/detail APIs:
explicit day/hotel, bounded pagination/retries, private original-response archive, identity/count/status checks,
explicit notes/Trace counts and complete search recheck. Partial, empty, drifting or warned batches fail closed.
- 34 collector tests and18 neighboring XML tests pass. Offline replay of139 details/four search pages preserves143 raw
responses exactly, with original477 files unchanged. No fresh hotel business calls, permissions, deployment or new delegation.
- Success means candidate acquisition only; Finance readiness, report equivalence and atomic snapshot flags remain false.
No source-format conversion, scheduler or integration with XML intake/Finance/OSS exists in this utility.
- Public catalog refreshed:0.6.0/111; getRateInfo/searchRateInfo still absent. Next resolve the actual platform rate-info
wrapper and same-environment price/report semantics before source adaptation and runtime integration. See
[collector evidence](../50-evidence/topics/2026-09-16-arr-api-collector.md) and [run instructions](../../integrations/ohip/README.md).
## End-To-End Readiness Audit On 2026-09-16
- Current source implements XML intake, immutable source replay, deterministic daily processing, manual-price review,
atomic Finance/outbox commit, independent monthly publication, Booking review/company reports, BI and authenticated
artifact downloads. The principal missing feature for the daily/monthly/BI path is automatic Opera source acquisition
and submission; native XML availability versus JSON adaptation remains unresolved.
- Automatic intake also needs complete-day delivery and task retry/deduplication semantics. Existing source/order/day
replacement rules remain authoritative. Manual price approval and Booking-source review/company generation are
existing operator steps, so source download alone does not make every product branch unattended.
- Compose starts Web/Caddy only; the implemented monthly worker must be supervised separately. Current production
deployment/restart behavior was not revalidated, and historical task failures are not current incident evidence.
Full local unittest regression: 401 total, 398 passed, 3 intentional private-fixture skips, zero failures/errors.
See the [audit evidence](../50-evidence/topics/2026-09-16-end-to-end-readiness-audit.md).
## Active ARR API Research Scope — User Correction On 2026-09-16
- The user explicitly corrected the Agent: Opera UI steps specify business criteria/data elements for platform API
discovery, not a browser-click implementation. Stop the Schedule Report/SFTP branch and UI/screenshot requests for it.
- XML is the supplied manual baseline and current processor input, not a user-imposed native-download-only API gate.
Study searchHotelReservations plus getReservation for equivalent ARR data, while keeping completeness, source replay,
price rules and existing validation intact. JSON adaptation is not yet approved or implemented.
- Both real operation definitions were re-read at07:07Z; they remain available under the existing reservations.read
grant. Only developer catalog reads were made. The subsequent mapping section records the delivered composition,
parameter/field mapping and concrete gaps. See [scope correction and mapping](../50-evidence/topics/2026-09-16-arr-api-scope-correction.md).
## ARR Rate-Info Endpoint And Semantic Follow-Up On 2026-09-16
- Found Oracle RSV getRateInfo/searchRateInfo: rateInfo.detail.totalRateAmount explicitly means the effective rate for
the specified reservation/date. Fresh catalog0.6.0/111 lacks both. Prepared a concrete [platform read-operation request](../../integrations/ohip/rate-info-platform-request.md)
and typed upstream examples; no Edge route invented, no grant/config changed, no external message sent.
- Saved-response analysis explains all9 search/base mismatches: search price matches the next-day2026-09-16 base.
All7 base/total mismatches equal that arrival day's computed package-price sum. This supports date-specific Oracle
rate info rather than guessed price reconstruction; report equivalence still needs validation.
- Company-role evidence is limited to Group (24 names across26 associations), so no new profiles.read need is proven.
Manual XML is in ascending room order with no duplicates; test API has8 duplicate nonblank-room groups/16 records.
Tie-breaking and report inclusion cannot be inferred from this cross-environment sample.
- This turn used saved139 records, the supplied XML and one public catalog read; no new hotel calls or delegation.
Next prerequisite for direct effective-price verification is the platform read wrapper, with parameters/tests in
[semantic evidence](../50-evidence/topics/2026-09-16-arr-api-semantics.md). Existing source/Finance controls remain intact.
## ARR API Read-Only Live Probe On 2026-09-16
- User continued the concrete proposal to test existing search/detail in known OHIPSB02. Isolated client made158 read
requests for arrival2026-09-15; allHTTP200 and expected envelopes. Two pages yield139 unique reservations; all139
details match identity/hotel/day. End recheck shows the same ordered IDs and no changed search records.
- Observed notes correct the official example:30 GEN/RESERVATION notes, including3 internal;32 total notes and12 Traces
match search indicator counts for every record. effectiveRate is absent in all139 details/396 rate entries, including
two focused fetch tests; search/base differ for9 candidate arrival rates and base/total differ for7. Do not default prices.
- Assignment filtering works with explicit paired booleans:74 assigned +65 unassigned form the exact baseline partition.
Single true flags alone did not narrow. ETA+07:00 returned0/warnings; local no-zone variants return12 and omit90 missing
and37 date-only values. These outcomes are current test evidence, not adopted production filtering rules.
- Raw sources are privately saved outside the repository with SHA-256 inventory. Repository includes only
[aggregate results](../../integrations/ohip/arr-api-probe-results-20260916.json) and [evidence](../50-evidence/topics/2026-09-16-arr-api-live-probe.md).
No new delegation, permissions/runtime/Oracle writes or Finance/Booking/OSS mutations. Research helper is isolated.
- Next: resolve report inclusion/empty-ETA behavior, actual effective-price and company-role mapping, and source ordering
using saved evidence; discuss optional Block access and source adaptation only after gaps are understood. Native XML
download, same-environment report equivalence and production end-to-end acceptance remain unproven.
## ARR API Field Mapping On 2026-09-16
- Completed a [concrete mapping](../../integrations/ohip/arr-api-mapping.md) of search/detail requests, all16 processor
source columns,3 derived outputs, pagination/completeness and source-adaptation boundaries. Five credential-free
examples passed offline targeted field/type/enum/date/query checks; no hotel business request was made.
- Key corrections: GEN is notificationLocation in the official RESERVATION comment example; effectiveRate includes
specified package additions and must be evaluated before using base; reservationBlock has no blockCode. These facts
narrow the test plan but do not establish hotel-specific report equivalence.
- The next proposed step was isolated read-only verification in known OHIPSB02 (subsequently completed above) of full date/status scope, pagination, detail completeness,
note selection, effective price, company role and ordering. Preserve raw responses and current pricing/replay/day
replacement controls. JSON adaptation and optional Block/profile/room-type grants remain undecided.
- The user now requires permission before each delegation. Exactly two read-only audits were started after explicit
permission in this turn; no nested or future delegation is covered. See [evidence](../50-evidence/topics/2026-09-16-arr-api-field-mapping.md).
## Historical Native XML Scheduled Delivery Investigation — Stopped After User Correction
- Re-read the complete live catalog and OpenAPI at06:42Z:0.6.0,111 catalog operations and152 total OpenAPI routes;
both data documents are identical to prior snapshots, with no report execution/download route.
- Oracle's official demonstration schedules Arrivals: Detailed; the standard-report guide supports XML and SFTP.
The user confirmed the scheduling entry is visible. Actual XML/SFTP options and an approved receiving location
were not confirmed. This investigation is stopped after the user's explicit API-scope correction; it is not an
adopted architecture or active prerequisite for API work.
- Prepared a [single-delivery trial draft](../../integrations/ohip/native-xml-delivery-trial.md), including fixed-day
validation, original-file comparison, destination prerequisites and the calendar-date/business-date mismatch.
A possible platform-owned receiver plus authenticated file API remains a proposal; no client/runtime/schedule,
destination configuration, external file delivery or permission change has been made.
## Native ARR XML Comparison Preparation On 2026-09-16
- Added an isolated read-only native XML comparator with a required pinned baseline SHA-256. It preserves physical
order, duplicate reservation occurrences and all note/Trace content, reports privacy-minimized counts/positions,
and refuses different hotel/group-date comparisons. It is not connected to ingestion, Finance or runtime.
- 18 synthetic tests passed; supplied manual XML versus its protected identical copy also passed for all72 rows.
This is a utility smoke test, not a downloaded-candidate comparison or business acceptance. Existing processor and
independent-validator results remain authoritative; GEN/CAS and source-environment evidence are still pending.
- Live catalog recheck at 06:26Z remains0.6.0/111 operations with no report operation. This tool can compare future native
XML files but is not a prerequisite for studying API-data composition under the later user correction. See
[comparison evidence](../50-evidence/topics/2026-09-16-native-arr-xml-comparison.md).
## Manual ARR XML Baseline On 2026-09-16
- User supplied res_detail_71050118.XML from Downloads: valid UTF-8 RES_DETAIL, one arrival group for 2026-09-15,
72 source rows, RESORT 57106 and THB. Processor 4.0.0 and its independent validator passed locally: 11 rate exclusions,
zero duplicates, 61 retained rooms, 125 room nights, all fixed prices matched, zero review issues. Source and outputs
are hash-checked in a private isolated Downloads directory; no Finance/Booking/OSS or runtime mutation occurred.
- Observed 58 notes coded CAS with description GENERAL; UI request remains Resv. - GEN until their relationship is
confirmed. XML has no internal-note marker. Asked the user for actual Note Types and source environment; screenshots
and export metadata remain unprovided. The sample includes 10 CKOT records, multiple Traces, nonmonotonic ROWNUM and
four starred arrival-time displays; preserve physical XML order and do not invent API semantics for these fields.
- This is a structural/processing baseline, not native API download or full parameter-equivalence acceptance. Current
OHIPSB02 and file hotel code57106 cannot be treated as one comparison dataset without verified environment binding.
See [sample evidence](../50-evidence/topics/2026-09-16-manual-arr-xml-baseline.md).
## Historical Native ARR Report API Review On 2026-09-16
- User offered to provide a manual export. Prepared a [minimal sample request](../../integrations/ohip/manual-export-sample-request.md):
one original XML for 2026-09-15, complete parameter screenshots, environment/hotel and export time. The XML has since
arrived and passed the local checks above; the screenshots and environment/export metadata remain pending. Interface
generation/download is still unverified.
- Fresh Edge catalog/OpenAPI readbacks remain 0.6.0 with 111 operations. No report metadata/parameter, native
res_detail execution or XML download operation is exposed. The current independent ARR application's read-only
reservation permissions were not changed.
- Reviewed all 45 public Property v1 specifications at Oracle commit dd631fbd5d0fce74a7dbdf96b43f07ce587211f2,
covering 3,580 operations. REPCFG provides getReports/getAllReports and getReportParameters metadata, but no
confirmed complete res_detail execution/download flow was found. This does not prove universal Oracle unavailability
or that an Edge wrapper alone can solve the gap. dateOffset is relative to business date, not calendar today.
- Prepared a concrete [platform handoff](../../integrations/ohip/arr-report-platform-handoff.md), not sent to others.
That native-file investigation depended on an execution/file-delivery contract, identity/parameters and comparable XML;
the later user correction restored broader platform API composition research. JSON reconstruction is not selected. No business call, real report
download, runtime, schedule or data mutation occurred. See [evidence](../50-evidence/topics/2026-09-16-native-arr-report-api-review.md).
## ARR Source Report Parameters Confirmed On 2026-09-16
- User supplied the actual Opera report workflow and options. The source is Arrivals: Detailed (`res_detail`), located
with Report Name ARR, for T-1 through T-1 and arrival time 00:00–23:59, with ALL Reservations/room assignments and
all seven code filters. Display Room Number and Notes, include internal notes, restrict Note Types to Resv. - GEN,
and download XML. Exact values are centralized in the [source contract](../40-domain/arr-source-report-contract.md).
- Source acquisition preserves ALL Rate Codes; the existing processor performs whitelist filtering after intake.
Calendar-yesterday does not silently become business-date-minus-one. API status/default/ETA/remark ordering equivalence
and native report generation/download remain technical verification work, not missing user button instructions.
- No report download, scheduling, application permission, processor, runtime or business-data mutation occurred.
## Same-Hotel Department Scope Confirmed On 2026-09-16
- The user clarified ARR is the Finance department's full report-acquisition/processing service, while the referenced
RSVN task serves the Reservation department of the same hotel. Restored the historical user confirmation: current
Oracle access is the standard test environment; after testing and Oracle approval, switch to the real hotel environment
using the same API contract with verified environment configuration.
- OHIPSB02 is therefore known test context, not an unanswered hotel-identity question. Reuse this background and prior
verified research without merging application credentials, copying Reservation write permissions or replacing the
current Booking Excel workflow. No sibling project, runtime, permission or business state was modified.
See [shared context evidence](../50-evidence/topics/2026-09-16-shared-hotel-rsvn-context.md).
## OHIP Application Provisioned On 2026-09-16
- The user supplied a new delegated credential. Installed CLI 0.5.0 authenticated as
`auto_219f3af6dc2123dc29ee3138` and created `Wyndham-ARR2.0-Codex` / `caller_zloxalzsQ9pYsztt` under the verified
human owner. Plan/validate/apply passed for `reservations.read` with search/detail and no implied extra operations.
- Issued one application Key through the CLI's protected file-delivery flow. Application readback confirms enabled=true
and one active key; local ready-file metadata, permissions and platform audit agree. All secret files are outside the
repository. See [integration setup](../../integrations/ohip/README.md) and
[provisioning evidence](../50-evidence/topics/2026-09-16-ohip-application-provisioning.md).
- The prior missing-management-credential blocker is resolved. Source download/JSON adaptation is still undecided and
unimplemented; no Oracle business request or ARR runtime/business mutation occurred. Management audits report
`hotel_id=OHIPSB02`, now confirmed from the related task and user clarification as the shared standard test environment.
## OHIP Integration Research On 2026-09-16
- Read the live Edge 0.6.0 catalog/OpenAPI (111 operations) and Oracle 26.3 reservation contracts against the current
programmatic ARR pipeline. The catalog exposes reservation JSON search/detail and async daily summary, but no
`RES_DETAIL` report-download operation. Search by arrival date plus detail with Comments/Traces is the leading
candidate for field-equivalence validation; no integration direction has been adopted or implemented.
- Preserve complete single-arrival-day replacement, deterministic first-row deduplication, source replay, manual-price
review and Finance/outbox boundaries. Incremental API data cannot directly replace a complete current-day version.
- Installed CLI 0.5.0 and the existing skill remain usable for public discovery. The official tools page requires an
authenticated console, while browser control timed out; new CLI/skill packages were not downloaded or installed.
A subsequent user-authorized login attempt returned HTTP 503 with “登录服务暂时不可用” on two attempts even though
`/healthz` returned 200/ok; no console session or package was obtained, and no login secrets were saved in project files.
Public contracts and a source/hash inventory were saved locally for discussion. No application, key, live Oracle
business call, ARR runtime or business-state mutation occurred. See the
[discussion memo](../50-evidence/topics/2026-09-16-ohip-interface-review.md).
- Historical task `01a08f5b-e9bf-7821-871a-6da7a088b806` subsequently confirmed a successful official CLI/skill download
and installation through the then-authenticated, functioning in-app browser. The installed CLI and all 3 skill files
are still present and usable; only the old download archive/directory is absent. Re-downloading is not a prerequisite
to continue integration research. No newer tooling release has been established, and no forced upgrade was requested.
- A later user-requested retry after a possible platform repair still returned console-login HTTP 503. The in-app tab
read timed out again, and the direct official bundle URL redirected to login HTML rather than a ZIP. No new tooling
artifact was downloaded; the installed CLI 0.5.0 and skill remain unchanged and available.
- The user then clarified that the installed CLI should create the ARR application directly. A fresh `automation whoami`
fails locally with missing `OHIP_EDGE_AUTOMATION_TOKEN` / `OHIP_EDGE_AUTOMATION_FILE`; relevant environment settings,
standard credential directories and matching Downloads files provide no configured identity. Application creation is
awaiting a delegated CLI credential, not a tooling re-download. No new application or key has been created.
## Documentation And Repository Handoff On 2026-09-06
- Added root `PROJECT_GUIDE.md` as a Chinese project explanation and handoff guide. It consolidates the project goal,
@@ -616,4 +1337,4 @@ immutable OSS adapter, while download routing retains controlled-local compatibi
## Last Updated
2026-08-04
2026-09-17