# 🚨 Booking-lookup design HALTED — bookings.json has been wrecked

## Critical finding

**`/root/.hermes/bookings.json` was overwritten at 22:01:25 UTC today.** It went from 2,429 records (~4.8 MB) earlier this session to **1 record (2.4 KB)** now. The booking-lookup architecture you proposed depends on a comprehensive index — with 1 record, `find_by_phone()` returns None for ~every guest and the auto-enrichment branch is structurally inert.

## Current state of bookings.json

```
size:            2,428 bytes
modified:        2026-04-26 22:01:25 UTC
top-level keys:  last_sync, window, count, scanned, total_in_system, bookings, last_webhook
last_sync:       2026-04-26T22:00:05
window:          check_out_after=2026-01-26, check_in_after=2026-04-26
count:           1
scanned:         0
total_in_system: 0
bookings:        [<1 record>]
last_webhook:    2026-04-26T22:01:25
```

The `window` filter + `count: 1` + `total_in_system: 0` strongly suggests **a sync script ran at 22:00:05 with date filters, stripping the file to only forward-looking bookings**. A ChargeAutomation webhook at 22:01:25 added 1 more record on top.

## Backups available locally (but stale)

| File | Size | Modified |
|---|---|---|
| /root/.hermes/bookings.json | 2,428 B | today 22:01 (CURRENT, broken) |
| /root/.hermes/bookings.json.bak.20260419 | 49,459 B | Apr 19 16:57 |
| /root/.hermes/bookings.json.backup.1776173702 | 1,530 B | Apr 14 |

The Apr 19 backup is the largest local copy (~25 records). Still nowhere near the 2,429-record snapshot I saw earlier today (~21:25), which means the wrecking has been intermittent for a while.

## Likely writers (untracked sync scripts in /root/.hermes/)

```
add_new_bookings.py
process_new_bookings.py
process_new_bookings_job.py
process_new_sync_bookings.py
sync_new_bookings_processor.py
sync_new_bookings_task.py
sync_new_bookings_to_registry.py
sync_new_bookings_update.py
```

Plus `/root/.hermes/scripts/chargeautomation_webhook.py` (tracked) which definitely does `upsert_booking()` on webhook events.

`/root/.hermes/` is NOT a git repo, so no version history for these scripts.

## Why this blocks the design diagnostic

Q1 (field inventory) ran but on a 1-record dataset.
Q3 (booking ID format) — with 1 record, regex sample size is meaningless.
Q4 (phone uniqueness) — with 1 record, distribution is meaningless.
Q5/Q6 (file layout / rollback) — the architecture can be designed but won't function until bookings.json is restored.

## Open questions before proceeding

1. **Where's the canonical source of truth?** ChargeAutomation API is upstream; is `bookings.json` supposed to mirror it 1-to-1, or be a windowed cache?
2. **Which sync script ran at 22:00:05?** Cron logs / process accounting would tell us.
3. **Is the windowing intentional?** If yes → bookings_lookup should query ChargeAutomation directly, not the local JSON. If no → the rogue sync needs fixing.
4. **Should we restore from the 49 KB Apr 19 backup as an interim?** Stale but at least non-trivial.
5. **Should we audit-log every write to bookings.json?** Add inotify watch + log line on every mutation, identify the culprit script(s).

## Read-only Q1 / Q2 / Q5 / Q6 outputs (still useful — don't depend on the dataset size)

### Q2 (respondio_client.py write methods)

`create_or_update_contact()` IS the writer. POST /v2/contact/create_or_update/phone:<phone>. Already proven to persist `internal_property_id` (used for fixture +447999000001). **Risk:** the wrapper sends `firstName=""` if not supplied → would BLANK existing values. Caller must fetch_contact first and pass through firstName/lastName/email.

**Recommended:** add `enrich_contact_custom_fields(phone, new_fields)` helper that does fetch-then-merge-then-write. ~25 LOC. No new HTTP path needed.

### Q5 (proposed file layout — still valid in shape, just deferred)

- New `/root/.hermes/scripts/bookings_lookup.py` (~80 LOC): `find_by_phone()`, `find_by_booking_id()`, `extract_booking_id_from_text()` (regex `\b\d{3}-\d{3}-\d{3}\b`)
- New `respondio_client.enrich_contact_custom_fields()` (~25 LOC)
- Patch `guest_webhook.py /inbound` (~30 LOC, three insertion points)
- No drafter changes — booking-unknown case handled via `extra_context` text injection
- All control flow in webhook BEFORE the LLM call

### Q6 (rollback)

- Per-component try/except with safe fallback (mirror properties.json pattern)
- Single-command full rollback: `git revert <commit> && systemctl restart hermes-guest-webhook`
- Audit log every enrichment write to `/var/log/hermes-enrichment.log` for forensics

## What I will NOT do without your direction

- Touch bookings.json (no restore, no edit)
- Disable any sync script (could break webhooks)
- Implement bookings_lookup against the broken file (waste)

## Suggested next step

Triage the data layer first. Specifically: identify which script overwrote bookings.json at 22:00:05 today, decide whether to restore + fix the writer or query ChargeAutomation directly. Once bookings.json is reliable, resume Phase i with the diagnostic re-run.

Awaiting your direction.