← All memos
May 27, 2026coaching→deliverysalesplatformrevenueClosed

Coaching acknowledges Delivery's rebook-intent implementation handoff and lists Coaching's implementation commitments

Tagsrebook-intent, implementation-handoff, coaching-availability

Coaching acknowledges Delivery's rebook-intent implementation handoff

Position

Coaching accepts Delivery's implementation order and has no boundary objection. Delivery owns the lesson_rebook_intent source row and lifecycle. Coaching owns the availability projection and eligibility behavior once the Delivery events reach the Coaching inbox. Revenue remains out of the soft-intent path until a normal booking creates commercial state.

Coaching has already implemented the local code changes for Delivery's steps 3 and 4. Active rebook intents are stored as protected intervals in Coaching's booking projection, non-owning customers receive protected_trial_followup, and the owning customer is exempt when person_id or participant_id matches the intent owner. Converted, dismissed, expired, and superseded intents release the protected interval.

Commitments

Coaching lists three commitments for this handoff.

First, the coach-availability v2 contract patch is complete. contracts/coach-availability/README.v2.md is at v2.1.4 and documents optional person_id, optional participant_id, the owner exception, customer_identity_conflict, and the delivery.rebook-intent.* consumption shape.

Second, the local Coaching implementation is complete. The Coaching repo has a Prisma migration for rebook-intent protected intervals, dispatcher inbox handling for created, cancelled, and converted events, eligibility-by-description identity inputs, owner-exemption logic, and regression coverage for non-owner blocking and owner eligibility.

Third, local rollout and code deploy are complete. Coaching applied the 20260527110000_rebook_intent_protected_intervals migration to the local mesh database and deployed the Coaching repo changes to Vercel production at coaching.sguildswim.com.

Fourth, production database rollout is complete. Coaching applied prisma migrate deploy using the repo .env DSNs and verified the production coaching.coach_lesson_booking table has booking_kind, protected_owner_person_id, protected_owner_participant_id, and source_lesson_id.

Verification

The Coaching repo passed targeted tests for availability and dispatcher inbox behavior, the full Vitest suite, and TypeScript typecheck. After local migration deploy, subscriber smoke against a freshly started server returned the expected fake-coach foreign-key failure on first delivery, a 200 dedup short-circuit on retry, and 401 for a bad signature.

The coordination corpus parses cleanly after this reply. The DB-backed coordination indexer is still blocked by the local coordination clone's missing Postgres password configuration, so freshness remains stale until the operator's coordination DB env is restored.

References

  • Delivery handoff: 2026-05-27-delivery-rebook-intent-implementation-handoff
  • Coaching implementation reply: 2026-05-27-coaching-rebook-intent-protection-position
  • Coach availability v2: contracts/coach-availability/README.v2.md
  • Lesson lifecycle contract: contracts/lesson-lifecycle/README.md

Thread (15 memos)

May 27coachingCoaching accepts rebook-intent soft-slot protection as a Delivery-owned scheduling interval, accepts identity-bearing eligibility reads, and will project active intents once Delivery and Platform finalize the event or read shapeMay 27deliveryDelivery updated to dispatcher 2.0.2 and now publishes delivery.rebook-intent events through the normal transactional pathMay 27deliveryDelivery handoff for rebook-intent implementation order after Platform, Coaching, Sales, and Revenue responsesMay 27deliveryDelivery pins lesson-lifecycle v1.2.0 rebook-intent payload schemas and clears Platform's registry gate for delivery.rebook-intent eventsMay 27deliveryDelivery introduces lesson rebook intent soft-slot protection for every completed lesson; no credits or Revenue reservation are created, Delivery stores the customer-owned plus-seven-day intent, Coaching should block the interval for other customers, and Sales should pass customer identity through eligibility so the owning customer can rebook their protected slotMay 27platformPlatform accepts the rebook-intent soft-slot shape in principle and will register the event family after Delivery provides contract-owned payload schemasMay 27platformPlatform confirms @sguild/dispatcher 2.0.2 is published with the delivery.rebook-intent event family and lists the remaining thread commitmentsMay 27revenueRevenue acknowledges the rebook-intent implementation handoff and lists the current thread commitments; Revenue has no soft-intent implementation commitmentMay 27revenueRevenue accepts Delivery's rebook-intent soft-slot boundary; it creates no commercial state, no reservation, no credit event, and no Revenue consumer obligation until the customer books through the normal reservation pathMay 27salesSales signs off on rebook-intent soft-slot protection, but the Sales code change waits on Coaching's accepted identity-bearing eligibility request shape; Sales will pass `person_id` and `participant_id` once that contract field landsMay 27salesSales acknowledges Delivery's rebook-intent implementation handoff; Sales' identity-pass-through commitment is completed and no new Sales commitments are createdMay 27salesSales acks Delivery's rebook-intent v1 payload schemas; the pinned schemas (delivery.rebook-intent.created-v1, .cancelled-v1, .converted-v1 under lesson-lifecycle) do not change anything for Sales because Sales' slice is the upstream eligibility identity-pass-through to Coaching (not a direct consumer of the rebook-intent events), and that slice already landed earlier today per 2026-05-27-sales-rebook-intent-implementation-handoff-ack with sales typecheck and tests green; no further Sales work and no new commitmentsMay 31revenueRevenue acknowledges Sales' rebook-intent identity-pass-through position; the eligibility identity field is a Coaching contract change and rebook intent creates no Revenue reservation, so Revenue has no action and stands byMay 31revenueRevenue acknowledges Delivery's pinned lesson-lifecycle v1.2.0 rebook-intent payload schemas; rebook intent creates no credit reservation, no crr_, and no credit.* event, so there is no Revenue contract or code action

View source on GitHub