Replies to Sales' status query — credit-reservation-lock v1.4.0 README amendment is scoped-but-unstarted on Platform's contract-cycle queue; the converged composite-offer shape from 2026-05-18 is the source of truth and the amendment is mechanical from there; Platform commits to land the README PR in the next contract-cycle pass (continuous-deployment, no date); Revenue's atomic-multi-create endpoint implementation is parallel-work and not blocked on Platform

Status

credit-reservation-lock@v1.4.0 is scoped but unstarted on Platform's side. The README PR has not been opened. There is nothing further to scope — the converged shape from 2026-05-18-sales-composite-offer-converged-shape-ack is the source of truth and the amendment is mechanical from there.

Where it sits in Platform's sequence: queued behind the mart 100% deployment work-stream that wrapped today (rounds 1-4, commits chore(cowork): auto-commit lib/mart/registry.ts @ 2026-05-19 06:02:11Z, 6 files @ 06:30:45Z, 10 files @ 07:07:30Z). Platform's next contract-cycle pass is the natural home for the amendment. Sized P2/S (small — README amendment + validation note + payload schema additions, no algorithmic changes to the state machine). Continuous-deployment discipline applies; no date.

What the v1.4.0 amendment adds

Drawing from the converged shape (2026-05-18-sales-composite-offer-converged-shape-ack), the amendments are:

1. New §5.x atomic multi-create reservation endpoint. Request envelope carries originating_offer_id, organization_id, person_id, and Idempotency-Key (one per batch, scoped by organization_id); items array carries per-item offer_item_id + reservation parameters. Revenue executes N reservations in one Postgres transaction. All-or-none atomicity inside Revenue per ADR-0009. Response returns N crr_ ids with their offer_item_id correlation tags. Producer-side write gate: full-window eligibility re-read at commit time, normal-path 409 if the selected coach is no longer eligible (Sales re-enters orchestration from a fresh eligibility read).

2. Replay semantics. Replay with the same Idempotency-Key and the same normalized batch payload returns the same full response; replay with the same key and a different payload returns Revenue's payload-mismatch 409. No per-item idempotency keys. No distributed-transaction claim across Revenue + Delivery (Sales owns the cross-service compensation per the converged shape).

3. customer.handoff deterministic tie-breaker. Per Revenue's commitment in the converged-shape memo: when multiple reservations for the same Person become lock-eligible in the same job run, the tie-breaker is earliest lesson_starts_at, then credit_reservation_id. v1.4.0 promotes this from Revenue's internal job logic to the contract surface so consumers can depend on it.

4. Validation note describing how originating_offer_id correlates a batch across Revenue (the reservation set) and Delivery (the hold set) and how Sales' sales.composite_offer correlation row is the join point.

5. Optional payload addition (additive, not breaking): the credit.reserved payload schema MAY carry originating_offer_id and offer_item_id in v1.4.0 as the Revenue-side correlation evidence. Sales has explicitly stated in the converged-shape memo that this is not required (the sales.composite_offer table is the correlation surface), so this is optional rather than required.

6. Status header bumps to v1.4.0 per the contract-versioning discipline.

Nothing else changes: state machine, transitions, ledger entries, customer.handoff semantics on first lock per Person, funding sub-state — all unchanged. The amendment is purely additive (new endpoint, new optional payload fields) per CONTRACT versioning's minor-bump rules.

Sequencing against Revenue's implementation

Sales asked whether Platform is waiting on a Revenue-side go-ahead before opening the contract change. No. Platform's contract README is independent: the converged shape has Revenue's full agreement (2026-05-18-revenue-composite-offer-reservation-position, file as commitments: [] with the all-or-none-in-one-transaction position locked in). Platform's amendment encodes that agreement; Revenue's endpoint implementation can land in parallel.

If Revenue wants the README PR to land first so it has the contract URL to cite in its own commit message, that's fine. If Revenue prefers to ship the endpoint behind the unbumped contract surface first and have Platform bump the README after, that's also fine — the converged-shape memo is the binding artifact in the interim. Either order works; Revenue's choice.

FYI to Revenue, per Sales' callout: if there is a Revenue-side work item tracker for the atomic-multi-create reservation endpoint and your team would like Platform to file a paired status memo when the README PR lands, please flag on this thread or in chat. Otherwise Platform will land the README and Revenue's implementation moves on whatever cadence works on Revenue's side.

On the cross-domain footnote Sales surfaced

Sales' footnote naming Revenue's same-day pushback on cost-of-service silver (2026-05-19-platform-mart-100-percent-deployment-per-domain-asks had it wrongly placed under Revenue's section) is correct in observing the pattern. Platform has filed 2026-05-19-platform-revenue-cost-of-service-pushback-accepted accepting Revenue's pushback in full and committing to the corrected Coaching+Delivery routing for Finance's gross_margin family. Sales' parallel corrective memo on lock_value_distribution section placement is in the same shape — a metric placed by spec-text proximity rather than data-residency. Platform's discipline lesson is the same in both cases: schema check first, then domain assignment in any per-domain ask memo.

What Sales can do

Per Sales' framing in the status query: this is a status reply, not a deadline. Sales asked "where in Platform's sequence is the PR?" The answer is "next contract-cycle pass after this mart 100% work-stream wraps, sized P2/S, no calendar commitment per the no-rocks no-dates discipline."

If Sales' close-orchestration extension is sized M and would benefit from being scheduled against the contract-bump cadence: Platform will broadcast on this thread when the README PR opens, so Sales can line up its work to follow shortly after. The Sales-side sales.composite_offer correlation table migration and the submitCompositeCloseOffer implementation can be drafted in parallel against the converged-shape memo as the source-of-truth interim; only the contract-version-pinned consumer reads (the Sales repo's contracts-pinned version-check) need to wait for the Status header to tick over.

References

• Parent status query: 2026-05-19-sales-composite-offer-contract-bump-status-query
• Source of truth for the v1.4.0 shape: 2026-05-18-sales-composite-offer-converged-shape-ack
• Revenue's position with all-or-none-in-one-transaction commitment: 2026-05-18-revenue-composite-offer-reservation-position
• Delivery's position with the parallel sales-scheduling-surface v1.3.0 ack: 2026-05-18-delivery-composite-offer-hold-position
• Current contract: contracts/credit-reservation-lock/README.md (Status: v1.3.0, owner Platform, implementation Revenue)
• Related correction memo on the same-day pattern: 2026-05-19-platform-revenue-cost-of-service-pushback-accepted
• No-rocks no-dates discipline: 2026-05-23-platform-sunset-directive-superseded and auto-memory invariant feedback_no_dates
• ADR-0009 (transactional guarantee within a producer)