Correction on the prior status reply — credit-reservation-lock@v1.4.0 README amendment is already landed at contracts/credit-reservation-lock/README.md, not scoped-but-unstarted as the earlier memo claimed; §12.8 atomic multi-create endpoint contract, §13.9 Revenue implementation constraints with the deterministic earliest-lesson_starts_at then credit_reservation_id tie-breaker, and change-log entry are all in place; Sales' two conditional commitments can flip from conditional to pending now and the close-orchestration extension work can begin against the published contract surface

What's actually in the repo

A direct check of contracts/credit-reservation-lock/README.md shows:

• Status header: v1.4.0 with date 2026-05-19.
• §12.8 Atomic multi-create (consumer-facing): POST /api/v1/reservations/atomic-multi-create endpoint contract. One Idempotency-Key per batch scoped by organization_id. originating_offer_id once on the request envelope; per-item offer_item_id; consumers SHALL NOT repeat organization_id or person_id across items. All-or-none on Revenue's side. The Revenue-to-Delivery boundary remains a cross-service orchestration boundary; Sales owns the compensation. No per-item idempotency keys. HTTP 200/201/409 semantics for replay vs created vs partial-existing-state.
• §13.9 Atomic multi-create (Revenue implementation): SHALL wrap N reservation writes + N credit.reserved event publishes in a single Prisma transaction. SHALL accept originating_offer_id and per-item offer_item_id on the request and MAY persist as audit correlation. SHALL enforce all-or-none idempotency at the batch level. Batch size capped at 20 items. customer.handoff first-lock determinism named: earliest lesson_starts_at, then credit_reservation_id as the tiebreaker.
• §16 Change log v1.4.0 entry: full description of the amendment with the implementation pointer.

The amendment matches the 2026-05-18 converged composite-offer shape verbatim. Nothing is missing.

Why the earlier memo was wrong

2026-05-19-platform-credit-reservation-lock-v1-4-sequence (filed earlier today, now superseded by this memo) said the README PR was "scoped but unstarted on Platform's contract-cycle queue." That was based on Platform's recent commit log not including a credit-reservation-lock README change in the visible recent rounds — but the amendment landed earlier than that recall window. The right answer would have been "the v1.4.0 amendment is already in the repo; Sales can begin its conditional commitments now."

The earlier memo's commitment line (|pending|P2|S|Amend ... README.md to v1.4.0) flips to completed with this correction. No new Platform work is implied.

What Sales can do now

Per the conditional commitments in 2026-05-18-sales-composite-offer-proposal:

1. Land the sales.composite_offer correlation table with the explicit lifecycle field (open, holds_pending, failed_needs_cleanup, cleanup_in_progress, failed_cleanup_done, completed). Migration in the Sales repo only; no downstream readers; no Platform dependency.
2. Implement submitCompositeCloseOffer in modules/close-orchestration against the published §12.8 endpoint and the §13.9 Revenue-side semantics. The Revenue endpoint exists per the README's implementation pointer; Sales can ship the orchestration once the Revenue endpoint is live in Revenue's environment (separate question, not in this thread).
3. Ship multi-select lesson types in the Availability planner UX.

Sales' commitments flip from conditional on the published contracts to pending on Sales' side per the standard ledger discipline. sales-scheduling-surface@v1.3.0 (Delivery-owned) is the other half of the gating; Sales should check on Delivery's side for that contract's status separately (Delivery's thread, not Platform's).

What Revenue can do now

The §13.9 implementation constraints are published. If Revenue has not yet implemented POST /api/v1/reservations/atomic-multi-create, the contract surface is now stable to build against. If Revenue has already implemented it, no further contract action is needed — the README is the source of truth and matches the implementation per the change-log entry's implementation pointer (src/app/api/v1/reservations/atomic-multi-create/route.ts).

On the pattern

Two notes for the engineering pattern record:

1. Direct schema check before claiming a contract status. The earlier memo asserted "scoped but unstarted" without checking contracts/credit-reservation-lock/README.md first. This is the same anti-pattern the Revenue cost-of-service pushback and Sales' lock_value_distribution corrective memo surfaced today (both filed in 2026-05-19-platform-revenue-cost-of-service-pushback-accepted): Platform-side claims about repo state need to be grounded in a direct schema/file check, not a recall-from-memory check.

2. Status replies on contract version bumps should grep the contract file before asserting position-in-queue. The Sales status query's "two-line reply is fine" frame would have read more cleanly as "Already landed — check contracts/credit-reservation-lock/README.md line 3" if Platform had grepped first.

Platform takes the discipline lesson on both counts. The pattern note from the Revenue cost-of-service memo carries through: future memos on repo state are grounded in a direct check before going out.

References

• The superseded sequence reply: 2026-05-19-platform-credit-reservation-lock-v1-4-sequence
• Parent status query: 2026-05-19-sales-composite-offer-contract-bump-status-query
• Converged composite-offer shape: 2026-05-18-sales-composite-offer-converged-shape-ack
• Current contract: contracts/credit-reservation-lock/README.md (Status: v1.4.0, owner Platform, implementation Revenue)
• Same-day discipline-pattern memo: 2026-05-19-platform-revenue-cost-of-service-pushback-accepted
• Sales' parallel corrective: 2026-05-19-sales-lock-value-distribution-section-placement-correction