# 2026-08-05 Daily PRICE_UNMATCHED diagnosis

## Metadata

- Date: 2026-08-06
- Status: Latest frozen review awaits explicit employee retry after deployed technical repair
- Scope: Daily job `arrjob-f1cd01f5fddd458cbdafada0ec7dd14d`, rejected Finance version 28
- Confidence: Fact for the hash-matched local replay and checked-in reference; production rule-set binary identity remains unproven because the supplied trace omits `rule_set_sha256`
- Source: operator-supplied ARR trace, hash-matched `0805.XML`, deterministic processor 3.0.0 replay, structured failure result, fixed price-reference workbook
- Last verified: 2026-08-06
- Stale trigger: a successful run-67 retry, a price/rule deployment, or a fresh processing job for business date 2026-08-05

## Question

Why did the deployed 2026-08-05 Opera XML daily job fail with `PRICE_UNMATCHED`, and do the reported 151 validation-failed rows represent separate bad source records?

## Evidence

- The server trace reports source size 948,683 bytes, rejected version 28 and outcomes `199 source = 46 excluded + 151 validation_failed + 2 price_unmatched`, with no duplicates or retained output.
- The read-only Desktop XML has the exact logged size and SHA-256. An isolated replay with checked-in processor 3.0.0 exits 2 and creates only `result.json`, `structured-result.json` and `异常清单.xlsx`.
- The two actionable errors are:
  - `reservation[2]`: Lian Tai + `LBLT` + Opera amount `0`; zero-night stay.
  - `reservation[64]`: Lian Tai + `GRP1` + Opera amount `1150`; one-night stay.
- Every one of the 151 `validation_failed` records carries `BATCH_NOT_VALIDATED`; 150 also carry `PRICE_REFERENCE_MATCHED`, and one carries the approved `ZERO_PRICE_EXCEPTION`. They are atomic batch fallout, not 151 independent field/date errors.
- Read-only artifact-tool inspection of `arr-opera-daily-ingest/references/价格对照.xlsx` shows Lian Tai `GRP1` mappings only at Sheet1 rows 23–28 for Opera amounts `900/1200/1300/1400/1800/2400`, and Lian Tai `LBLT` mappings at rows 40/42/43 for `900/1400/2400`. Neither exact target exists.
- Both checked-in price-reference workbooks are byte-identical at SHA-256 `123d1d1ea0e28ce481a63dfdbe4bd22b5e6069c585a8cbde4194376ed18fb0d6` and have not changed since commit `a701de9` (2026-07-29).
- The local replay rule-set SHA is `c41257208324a43e711de13ec9776a5e6486db334757f152531bf8292a2018eb`. The server trace exposes only processor version 3.0.0, so exact production rule-set hash comparison is not available from that trace alone.

## Finding

The deterministic processor correctly failed under the current frozen rules because two exact normalized price keys are absent. Numeric formatting and trailing rate-code spaces are not the cause. The `总价` values cannot be inferred safely from neighboring mappings, and zero nights do not bypass price-key validation under the current approved rule.

## Impact

- The deployed v4 workflow created review cases instead of another rejected Finance version. Latest run 67 has a frozen
  GRP1/LBLT manifest of `200/0` and remains retryable `generation_failed` after two repaired infrastructure defects;
  it still has no Finance version or run outbox event. Run 66 separately retains `2300/0`, and run 65 remains unset.
- The values apply only to their own task and do not change the fixed reference table. No automatic retry or re-upload
  is safe because a successful final replay is the Finance/monthly commit boundary.
- Keep rejected version 28 as immutable failure history. Only an explicitly authorized successful final replay may
  activate Finance facts and trigger monthly processing.

## Open Items

- Refresh/login, open latest run 67, confirm its frozen `LBLT=0` and `GRP1=200` values are intended, then invoke its
  retry once. Do not select run 66 accidentally because its frozen GRP1 value differs.
- After success, verify 153 retained rows, two `manual_review` rows, one active Finance version and exactly one new
  daily-commit/monthly event.