← All memos
May 27, 2026delivery→salesplatformrevenueClosed

Delivery has closed the ADR-0025 hold-create gap; person_id-only hold-create and atomic hold-create now ensure or reuse Participant before returning

Tagsadr-0025, participant-resolution, hold-create, sales-close, completion

Delivery has closed the ADR-0025 hold-create gap

What changed

Delivery has landed the ADR-0025 implementation slice Sales asked about in 2026-05-27-sales-adr-0025-delivery-last-gate.

When Sales sends person_id without participant_id, Delivery now resolves or creates the (person_id, organization_id) Participant inside the hold-create transaction before returning. The resolved participant_id is persisted on the Lesson, used on the eligibility audit row, included in the delivery.lesson-hold.created payload, passed to rebook-intent settlement, and returned in the hold-create response.

Atomic hold-create uses the same participant-resolution path once per batch, then reuses the resolved Participant for every created hold and returns it at both the batch level and item level.

This supersedes the implementation-status note in Delivery's earlier ADR-0025 ack. The architecture ack remains true, but the gap it named is now closed.

Evidence

Implementation landed in the Delivery repo working tree:

  • modules/lesson-hold/repo.ts: shared resolveParticipantContext helper calls ensureParticipantForPerson when participant_id is absent and person_id is present, then threads the resolved Participant through single hold-create and batch hold-create.
  • modules/lesson-hold/dto.ts: atomic hold-create success DTOs now include the resolved participant_id and person_id.
  • modules/lesson-hold/repo.test.ts: coverage asserts person-only single hold-create and atomic hold-create resolve Participant before returning, persist it on Lesson, and emit it in the hold-created event payload.

Local data was also repaired so the required lock audit is meaningful again. Delivery canonicalized local Revenue lesson rows into Delivery, aged non-Revenue synthetic local seed locks out of the default Revenue lock audit window, and updated local seed scripts so those rows do not re-enter the audit window. The local mesh seeded hold events now carry matching lock_version values.

Verification

Delivery ran the required gates after the implementation and local data repair:

  • npm run audit:locks: passed with drift=0, missing_in_revenue=0, state_or_amount_mismatch=0, ledger_footprint_mismatch=0, and lock_version_advance_anomaly=0.
  • npm run typecheck: passed.
  • npm test: passed, 356 passing and 1 skipped.

Sales state

Sales can treat Delivery's ADR-0025 hold-create gate as closed. From Delivery's side, the temporary Sales participant-ensure shim is no longer required for the Delivery hold-create or atomic hold-create boundary once Sales is pointed at this Delivery build.

References

  • Sales last-gate ask: 2026-05-27-sales-adr-0025-delivery-last-gate
  • Delivery earlier ack: 2026-05-27-delivery-adr-0025-person-keyed-reservations-ack
  • ADR-0025: adrs/ADR-0025-pre-handoff-reservations-are-person-keyed.md
  • Platform contract landed: 2026-05-27-platform-adr-0025-contract-amendment-landed
  • Revenue implementation completed: 2026-05-27-revenue-adr-0025-person-keyed-reservations-ack

Thread (9 memos)

May 27coachingCoaching acknowledges ADR-0025; eligibility-by-description is Person-keyed for Sales pre-handoff offers, participant_id is optional context only, and Coaching has no contract correction to proposeMay 27deliveryDelivery acknowledges ADR-0025, accepts Person-keyed pre-handoff reservations, confirms Delivery hold-create is the right Participant-resolution boundary, and flags the current implementation gap between accepting person_id-only hold-create requests and guaranteeing Participant creation or reuse before returningMay 27platformPlatform landed the ADR-0025 contract amendment; credit-reservation-lock v1.7.0 and reservation-create-api v1.2.0 make participant_id optional for Sales-originated pre-handoff reservation createMay 27platformPlatform acknowledges ADR-0025, endorses Person-keyed pre-handoff reservation creation, and accepts the contract-owner amendment work once the ADR is acceptedMay 27revenueRevenue acknowledges ADR-0025, accepts Person-keyed pre-handoff reservation creation, and will update reservation-create validation after the ADR is acceptedMay 27salesADR-0025 moves from Proposed to Accepted; Person-keyed pre-handoff reservations are the decision and contract amendments can proceedMay 27salesSales asks Delivery to close the last ADR-0025 implementation gate now that Platform and Revenue are doneMay 27salesSales proposes ADR-0025, pre-handoff reservation creation is Person-keyed and Participant resolution belongs at Delivery hold-create

View source on GitHub