docs: clarify original XML handling of cancelled reservations

.project-docs/30-worklog/tasks/20261008-production-review-9e7b.md

@@ -138,3 +138,12 @@ Read: memory-index, project-positioning, current-state latest September sections
 - Verification:88 Python tests passed with disposable real local PostgreSQL enabled, no skips (33 source-review/executor/database and55 source acquisition tests);44 JavaScript tests passed. Independent policy review caught malformed indicator-name and contradictory empty-block edge cases, both fixed and retested. Offline real replay verified531 original files and all176 recorded HTTP requests with zero network calls, preserving58 rows, every other source/field/context/related value and order.36 full-source block observations and16 package observations became empty, resolving25 candidate decisions.
 - Local activation and observed result: dry-run on a private copy reduced26 decisions to1 without manual decisions or finalization. Verified no active queued/downloading/processing task before service stop; backed up review and executor checkpoint to private `source-reanalysis-backup-20261008-105211`, applied the same checked reanalysis, then restarted the existing service. Authenticated API and CUA both show10/7 revision1,0/1 confirmed, only required room for300007418, `can_finalize=false`, no job/daily/monthly. Page retained as deliverable with10/7 selected; XML upload and separate9/17 pending entry remain. The existing9/17 capture/review was not reinterpreted or queried. Screenshot and full replay receipts remain private outside Git.
 - Follow-up/promotion candidate: promote the documented limited optional-association semantics and product explanations at integration. Remaining10/7 room is not fabricated; its cancelled/unassigned report inclusion remains a separately deferred business-scope question. Real daily/monthly acceptance, primary-checkout integration and remote deployment are not claimed by this task.
+
+## Same-task Follow-up: Cancelled Rows in the Original XML Rules
+
+- User asks how original XML code handles cancelled reservations and notes earlier XMLs may have contained them. Concurrent gate resumed task20261008-production-review-9e7b in the same owned feature worktree/branch with no peers; prior required project context remains loaded. Planning gate Passed for read-only rule/history/XML inspection, with no proposed business-rule change.
+- Current `source_record` does not read `SHORT_RESV_STATUS`, `RESV_STATUS` or cancellation fields; normalized records contain no reservation-status input. `classify_normalized_records` first filters by the20-code rate whitelist, then validates required fields, then deduplicates by room/arrival. Consequently cancellation alone neither excludes nor specially handles a row. A valid whitelisted cancelled row enters normal downstream processing; a non-whitelisted row is excluded before room validation; a whitelisted row without room produces `XML_ROOM_MISSING`. `filter_and_deduplicate` raises on any errors, so original XML does not silently skip that invalid candidate and complete the batch.
+- Processor/independent-validator are unchanged against primary baselinead2c592. Earliest commita701de9 already shows the same rate-before-validation order, room-required check and room/arrival deduplication. A local in-memory diagnostic using identical synthetic XML with four different status strings and three room/rate cases produced identical classification outcomes for every status. It wrote no report, real source, state or database and made no network calls. No new persistent tests were necessary for this read-only explanation.
+- Independent original-file inspection: `/Users/chillishark/Downloads/res_detail_10.7.XML` hash remainsbf1d1905e068f7c496a3caf63e3682d2aeee2b62c30ce6c87e14e2411a9d6d84.10/7 has13 CKOT rows, all with room and6 whitelisted.10/8 has27 rows with short-status codesGC14,TA11,CD1,CA1; only theCA-coded row lacks room, and its rateSRB is outside the whitelist. Do not assertCA/CD code meanings without evidence: the file provides no status legend or independent cancellation marker. This example nevertheless establishes why a missing-room record may not trigger the business validator: it is outside the rate scope. The7 related XML filenames were listed; other files were not parsed or used to infer cancellation behavior.
+- Corrected prior user-facing framing: maintaining the original rules does not require a new decision about excluding cancelled reservations. Saying that a cancellation inclusion decision was required before applying existing rules was misleading. A status exclusion or blank-room exception would be a new rule, and neither is introduced. The remaining saved10/7 record300007418 is whitelisted with missing room, which explains the current review under unchanged rules; its separate source/report-population question remains deferred by the user. Existing source may include cancelled rows with valid room, or exclude them by rate, so earlier successful XML processing is compatible with no status filtering.
+- Outcome/follow-up: explain original rate/field/dedup order directly and keep the remaining item classified as required room missing, not a newly invented cancellation error. No business code, live service, original XML, review decisions or source scope changed. Promote this clarification to canonical source/product documentation only at integration; no remote push or real daily/monthly is claimed.