# Evidence Topic: First live ARR2 user-run trace

## Metadata

- Date: 2026-07-30
- Status: Resolved by the monthly-publication implementation completed later on 2026-07-30
- Scope: ARR2 loopback runtime on port 8766, controlled `booking_test`, OSS-backed daily processing, local monthly output
- Confidence: Fact
- Source: persisted Web API trace, read-only PostgreSQL queries, local artifact metadata, source inspection
- Last verified: 2026-07-30
- Stale trigger: Historical evidence; see `2026-07-30-monthly-publication-live-acceptance.md` for current behavior

## Question

Did the user's successful daily run commit to PostgreSQL, and why did the subsequent successful monthly action show no
monthly result or download?

## Evidence

### Daily commit

- Job `arrjob-e6042c9cfe7d4f07aa986c5cffc4548e` is processing run 27 with terminal raw status `accepted`.
- Its one artifact delivery is committed and points to Finance daily version 4.
- Daily version 4 is `active`, version number 1, for business date 2026-07-21.
- Counts reconcile: 135 source rows = 119 retained + 16 excluded-rate-code; duplicate, validation-failed and
  price-unmatched counts are zero.
- `finance.current_daily_versions` points 2026-07-21 to daily version 4.
- The trace contains `ARTIFACT_RESULT_COMMITTED`, `FINANCE_VERSION_ACTIVATED` and `JOB_SUCCEEDED` terminal evidence.

### Downstream event

- The same database transaction created `arr.daily_version_committed` for processing run 27.
- At verification time it was `pending`, with zero publish attempts and no published timestamp.
- This is consistent with the documented absence of an automatic monthly outbox consumer.

### Monthly generation and visibility

- The manual monthly request generated `outputs/monthly_reports/2026/07/latest.xlsx` and `latest.result.json` at
  2026-07-30 14:28:32 +08:00.
- Result status is `success`; the workbook SHA-256 is
  `57160ff45d962ef348d7e9d21eafdc1f89c8b7b00d9d31eba283c2ff6bc40410`.
- The workbook reopens and contains LIANTAI-GROUP 26 rows, LIANTAI-FIT 25, QBD 55, DY-AI-Easy-KB 0 and FENGRUN 14:
  120 data rows total. No guest values were recorded in this evidence.
- The workbook contains zero formulas, matching the known formula implementation gap.
- Read-only `information_schema` verification proved `finance.report_versions` is absent from `booking_test`.
- `monthly_reports.repository.PostgresReportRepository.reserve_report()` creates only a deterministic in-memory
  generation identity; `activate_report()` revalidates source pins but inserts no report metadata.
- `arr_web.repository.MONTHLY_RUNS_SQL` synthesizes a `source_ready` row with null `report_id`, filename and artifact
  hash. The frontend only renders a download link when an artifact hash/report ID is present.

## Finding

The daily success is a real, atomic PostgreSQL commit. The monthly action also produced a real local XLSX, but its
success is not persisted as a monthly report version and cannot be rediscovered or downloaded through the Web API.
The frontend toast therefore overstates the end-to-end outcome: it confirms local file generation, not published report
visibility.

## Impact

- Daily ingestion does not need repair for this run.
- A monthly publication task must define and implement a database-compatible metadata/read model (or an equally durable
  controlled artifact index), then align list/download APIs and the success receipt with that persisted state.
- Automatic dispatch remains separate: the accepted outbox event currently has no consumer.
- The required `TOTAL PRICE` formula remains a separate workbook-generation defect.

## Open Items

All three items were resolved later on 2026-07-30 by migration 012, the dedicated worker, persisted list/download
identity and formula validation. This topic remains the before-state diagnosis.