diff --git a/.project-docs/30-worklog/tasks/20261008-production-review-9e7b.md b/.project-docs/30-worklog/tasks/20261008-production-review-9e7b.md index 10f6208..2fe5d2e 100644 --- a/.project-docs/30-worklog/tasks/20261008-production-review-9e7b.md +++ b/.project-docs/30-worklog/tasks/20261008-production-review-9e7b.md @@ -38,7 +38,7 @@ ## Follow-ups -- Staff must supply/confirm the26 actual field decisions and complete any subsequent existing price review before the real10/7 daily/monthly result can be verified. The room gap belongs to a cancelled reservation retained by the existing rules; no synthetic room or new status-based exclusion was introduced. Any proposed change to cancellation/no-show eligibility requires a separate business decision. +- Reconcile the API source selection with the original Oracle report before asking staff to resolve the26 currently presented field decisions. The later original-XML audit below proves that15 decisions concern reservations absent from the manual10/7 report and11 concern optional values explicitly blank in that report. Neither these source differences nor the original optional-field rules can be resolved by asking staff to invent values. Subsequent existing price review and real daily/monthly acceptance remain pending. No synthetic room, source confirmation, or status-based exclusion has been introduced. - Integration owner should promote the accepted behavior and production compatibility evidence, then integrate this branch into the primary project. Keep this checkout while the local service runs from it. It is manually created, not eligible for automatic skill-managed retirement. - Production deployment/configuration and remote publishing are separate follow-ups. This turn only activated the local instance against the existing production read service. @@ -116,3 +116,12 @@ Read: memory-index, project-positioning, current-state latest September sections - Additional common13-row comparison found normalized display/text differences in company12,full-name13,comments4. Their semantics have not all been resolved; do not claim exact source/report equivalence merely from matching confirmation IDs or infer that all differences are cosmetic. Preserve the evidence for a separate field-mapping review. - Verification: original XML parsing/hashes, frozen rule normalization, exact confirmation-set/status join against immutable captured details, and independent read-only review. No Oracle requests, real report generation, database writes, service restart, source rewriting or rule changes occurred. Private comparison summary: `/Users/chillishark/Library/Application Support/ARR2.0/production-validation-20261007/oracle-xml-scope-comparison-20261007.json`; original XML/PII stay outside Git. - Follow-up/promotion candidate: align the API query's date/status/report-selection scope with the intended Oracle ARR export settings before accepting the real10/7 daily/monthly result. Inspect original export settings or authoritative report criteria; do not silently adopt CheckedOut-only from one observed file or filter by this file's ID list. Optional empty-field evidence can support explicit auditable resolution for matching records, but the user's request here is comparison only. The previous claim that only business-field completion remained for real10/7 acceptance is incomplete: observed report scope and some text mappings also need alignment. + +## Same-task Follow-up: Confirmed Manual Export Date Range + +- User confirms the original XML was exported with From Date07-10-2026 and To Date08-10-2026. This matches its two observed arrival-date groups. The response supplies no reservation-status or actual-arrival selection; do not interpret an unanswered part of the question as a status choice. +- The live download remains a single-day task with both arrivalStartDate and arrivalEndDate set to2026-10-07. The XML's additional10/8 group is explained by the confirmed date range; this does not explain the45 extra API reservations within10/7. Changing the automatic single-day task to a two-day task would not resolve that within-day discrepancy and is not requested. +- Historical user-confirmed report settings already specify ALL Reservations, ALL Room Assignment, unrestricted code filters and Resv.-GEN notes. The notes selection is not a reservation-status filter. Existing source-contract research explicitly states that report ALL Reservations must not be assumed equivalent to all API reservation statuses. +- Public CLI0.5.0 catalog inspection succeeds against the existing Edge service, version0.12.0: searchHotelReservations remains a synchronous POST with an optional OracleDocument body and no typed mapping to res_detail report criteria. Only public metadata was requested; no credentials, grants, environment routing or hotel business data were read or changed. Private evidence: `production-validation-20261007/search-reservations-public-contract-20261008.json`. +- Official documentation does not establish the current hotel's historical report status defaults. Oracle's [legacy RES_DETAIL parameters](https://docs.oracle.com/cd/E98457_01/opera_5_6_core_help/res_detail_help.htm) distinguish arrival/stay dates and include options from Reservations=All. Its Checked-In Today option refers to the current business date; this is not proof that a historical Cloud report excludes every InHouse reservation or includes only CheckedOut. The current [Oracle reservation API schema](https://raw.githubusercontent.com/oracle/hospitality-api-docs/main/rest-api-specs/property/v1/rsv.json) independently exposes actualArrivals, expectedArrivals and reservationStatuses, without defining their equivalence to res_detail. An independent read-only official-document audit reached the same limit; current Cloud report summaries do not supply the missing per-hotel saved parameter values. +- Outcome: the user-confirmed two-day range explains the extra10/8 XML group only. Request the actual Oracle export parameter page, especially the date-type and Include selections, before choosing API inclusion criteria. Do not ask for the date again, infer status answers, or introduce CheckedOut-only filtering from this one sample. No code, source data, review decisions or service configuration changed, and no actual daily/monthly was generated. Public metadata/documentation reads required no business query or tests; Git whitespace and task documentation boundary checks apply to this documentation-only continuation.