I'm parked on you

Pick an option on each card and press Done; your answer goes straight back to the session. The raiser's pick is marked. "I'm not sure" is a real answer.

1

In plain terms. Should I fix the bug where Western Slope's phone bookings keep trying to create a tracking card that can never be created, and paging engineering every time it happens? Every tour someone books on Western Slope's main phone line triggers an attempt to file a card with their property software. That line has no such software connected at all, so the attempt always fails. It quietly retries for about an hour, then gives up and pages engineering - and this repeats on every single booking from here on.

The full question, as raised

Sentry JAVASCRIPT-NEXTJS-1G2 (issue 7779660047), org org_c42d9150-b9ad-46f8-8f5f-b0fe56bacf38 (Western Slope). PmsWriteIntent gc:create_card:f6a3d30f-f630-47a1-a78b-9a71113431c7 parked failed after 7 attempts (19:25-20:30Z): 'property western-slope-front-door has no PMS configured yet (pmsSource + af.propertyId both absent)'. Confirmed via smith-db: the Property row has no pmsSource/af fields at all (it's the Western Slope front-door catch-all, scattered_site, no AppFolio connection by design) and the ProspectInquiry (Thomas Rossi, voice tour booked on the 970 line) is real production traffic. Root cause: enqueueCreateCardIntent (src/lib/domain/pms/guest-card-create-intent.ts), reached via queueCardBeforeBooking from handleScheduleTourImpl in agents/clara/lib/agent/tools-leasing.ts (#12714, 'NO SHOWING WITHOUT A CARD'), appends a create_card PmsWriteIntent with NO check that the property actually has a PMS writer. The sibling post-call door (src/lib/integrations/voice/postcall-guest-card-outbox.ts, resolveIntentPropertyId + getPMSGuestCardWriterForProperty) already guards exactly this shape and returns {enqueued:false, reason:'no-pms-property'} instead of writing a doomed row -- its own header comment literally names this failure mode as the bug it fixed. This is ADR-0134's class: a guard bound to one door, the resource reachable by a second, unguarded door. Fix: add the same getPMSGuestCardWriterForProperty(args.propertyId) check to enqueueCreateCardIntent before appending; short-circuit to {queued:false} (optionally routing through the existing guest_card_no_pms_connection staff notice) instead of a retry loop that cannot ever succeed. Recurs on every tour booked on this line (and any other no-PMS company with the switch on) -- deduped to one Sentry page per hour, but a real, permanent, recurring condition. Risk/lane: this is a PMS-write-path change on a live customer's (Western Slope) leasing/voice booking tool -- HIGH risk per the decider's own tiering, so even a ready fix should stop at mergeable for a human merge. It also sits squarely in leasing + voice + Western Slope onboarding, which the task's lane note assigns to Fede/Trinity, not Smith/Gera -- but ~/.claude/LANES.md doesn't exist on this box, so the Handoff sentinel (bridge_handoff.classify) can't route it there; it would silently post nothing. Raising here instead so a human picks who drives it.

Fix it now — stop the failing retriesthe raiser's pick Hold — let Fede's team pick this up first Leave it — just quiet the alert I'm not sure — go find out

Why, and what was tried

The session raising this recommends: Fix it now — stop the failing retries
Small, already-proven fix (a sibling code path has it), but it touches a live customer's booking path so a human should still merge it.
Tried first, unsuccessfully: Traced the alert to the exact parked write-intent and property record in production, and found the sibling code path that already guards against this exact failure shape -- confirmed Western Slope's front-door line has no property-management software connected at all.

fc8eda64 is parked on this.

Pick an option above, then press Done.