Coaching calendar projection does not consume lesson.rescheduled v1

Why

An operator rescheduled a live lesson in Delivery, but the Coaching calendar continued to show the booking at its previous time. Delivery now emits a schema-valid lesson.rescheduled v1 event transactionally from the reschedule write. The published payload carries organization_id, canonical lesson_id, previous_window, and new_window.

The consumer gap is in Coaching's projection path. modules/dispatcher-inbox/schema.ts does not include lesson.rescheduled in LESSON_LIFECYCLE_EVENT_TYPES, and modules/dispatcher-inbox/service.ts has no handler for it. The Coaching coach_lesson_booking row is therefore seeded by scheduling and assignment events, then never moved when Delivery changes the lesson window.

Delivery must not write Coaching's projection table directly. Coaching owns this subscriber and projection.

Proposed contract position

Coaching should become a binding consumer of the existing lesson.rescheduled payload schema version 1. No payload or event registry change is needed. After Coaching confirms the consumer shape, Delivery will publish an additive lesson-lifecycle contract update naming Coaching as a consumer and documenting the projection behavior.

The consumer should locate the existing booking by organization_id and lesson_id, then replace only lesson_start and lesson_end with new_window.start and new_window.end. It should preserve coach assignment, booking kind, credit-derived state, reservation and lock correlation, service area, and address fields. The update must not require new_coach_id, because legacy assignments may be represented as null in the canonical event while the existing Coaching row is already keyed to the assigned coach.

Handling must be idempotent under dispatcher replay. A duplicate event should converge on the same new window. A missing booking should be recorded for repair or safely ignored with an observable signal; it should not synthesize a new coach assignment from a null coach id.

Asks

Coaching, please:

1. Accept lesson.rescheduled in the dispatcher inbox and update the existing coach_lesson_booking window by organization and lesson id.
2. Add tests proving the window moves while coach, booking state, reservation id, lock id, and location fields remain unchanged, including duplicate replay and null new_coach_id coverage.
3. Repair the affected live booking by replaying the accepted reschedule event or applying an audited projection correction, then verify the Coaching calendar shows the new window and no longer blocks the old window.
4. Reply on this thread with the implementation commit, production deployment, and live projection proof. Please declare Coaching's implementation commitment in the reply memo so it is visible on the live ledger.

References

• contracts/lesson-lifecycle/README.md section 4.5
• contracts/lesson-lifecycle/schema/payloads/lesson.rescheduled-v1.json
• Coaching modules/dispatcher-inbox/schema.ts
• Coaching modules/dispatcher-inbox/service.ts
• Coaching modules/availability/bookings-repo.ts