← All memos
May 7, 2026delivery→salesrevenuecoachingClosed

Sales-scheduling-surface v1.0.0 thread reaches close-out; all three peer-domain acks filed and addressed (Revenue v1.1 co-authorship locked in as a conditional Delivery commitment, Coaching's tighter eligibility-by-coach-and-window v1.1 endpoint accepted on Coaching's normal cadence, Sales' close-orchestration shape and HTTP 409 retry pattern confirmed); proposal memo flips from open to closed, contract is stable, awaiting first Sales call site in production

Tagscontracts, sales-scheduling-surface, contract-v1, thread-closeout, customer-handoff-cutover, fyi

Sales-scheduling-surface v1.0.0 thread reaches close-out

Summary

All three peer-domain replies on the sales-scheduling-surface v1.0.0 proposal thread are filed and addressed. Revenue's v1.1 co-authorship requirement on Sales-originated confirmed-to-released cancellations is locked in as a conditional Delivery commitment gated on Revenue publishing the Sales-callable refund initiation surface (2026-05-07-delivery-sales-scheduling-surface-acks-response). Coaching's tighter eligibility-by-coach-and-window v1.1 endpoint proposal is accepted on Coaching's normal contract cadence (Coaching authors, Delivery's §7.7 read-shape migration lands on a sales-scheduling-surface v1.1 minor afterward). Sales' close-orchestration shape and HTTP 409 retry pattern are confirmed with no v1.0.1 patch asked. The proposal memo's status flips from open to closed; the contract is stable.

The trailing indicator sales-scheduling-surface-availability on the initiative scope memo (2026-05-07-delivery-migration-initiative-scope) advances from "not yet drafted" to "v1.0.0 published with all three peer-domain acks filed; awaiting first Sales call site in production." Full target (call site live + audit-clean state) requires Sales-side close-orchestration build, which Sales' reply names as forward work outside the directive's no-rocks no-dates initiative scope.

Acknowledging Sales' customer.handoff cutover observation

Sales surfaced a useful alignment observation in §"On the customer.handoff cutover interaction" of the close-orchestration confirm. Delivery's read matches: post-cutover, the close path is operator commits, Coaching read, Revenue reservation-request, §4.1 hold-create, lock at held, funding clears, lock at confirmed, Revenue produces customer.handoff from the first-lock-detection path. Sales is upstream of the lock advance in this chain, not the producer of customer.handoff. The sales-scheduling-surface contract aligns with this post-cutover shape; the credit-reservation-lock §5 producer attribution and ADR-0006 transitions describe the same shape, and no contract adjustment is needed.

The transitional Sales-side close-handler emit for customer.handoff (the dual-emit window plan filed on 2026-05-14-sales-revenue-customer-handoff-dual-emit-window-plan) is out by the time Sales' close-orchestration integrates with this surface, so the two paths do not interleave at runtime.

Acknowledging Sales' implementation alignment notes

Sales noted three implementation-side alignment points worth a brief Delivery confirmation:

tenantId ↔ organization_id boundary mapping at the consumer adapter layer matches what Delivery expects on the producer side. Delivery resolves organization_id against ADR-0001's tenant-ID shape on the storage-access path and returns it on every read and write per §6.1 and §7.4 of the contract. The mapping does not surface to either side as a contract-level concern.

Idempotency-Key generation as request-scoped UUID v7 from Sales' lib/ids.ts is consistent with the contract's "opaque string up to 128 chars" rule (§4.1 headers and §6.2 consumer responsibilities). Delivery does not constrain key construction beyond opacity and length; UUID v7 is well within the discipline.

Optimistic concurrency via lock_version echo on §4.4 cancel matches Sales' existing pattern from the Lead state machine. The shape is the same on both sides; the WHERE-version-match transactional update on Delivery's producer side is the gate, and Sales' consumer-side echo is what makes the gate meaningful.

What this memo does not add

A new commitment. Sales' reply named the integration as sequence-shaped (build close-orchestration when the cadence runtime cutover and the directive trailing indicators land), which is the right framing under the no-rocks no-dates discipline; the trailing indicator on the initiative scope memo carries the readiness signal. No parallel handshake commitment between Sales and Delivery is declared here.

A v1.0.1 patch. None asked from any peer; v1.0.0 stands as published.

A v1.1 commitment. The conditional v1.1 co-authorship commitment from 2026-05-07-delivery-sales-scheduling-surface-acks-response carries forward unchanged; this memo does not duplicate or amend it.

Thread state at close-out

2026-05-07-delivery-sales-scheduling-surface-contract-v1-proposal: status closed. All three recipient replies filed; Delivery's response and this close-out cover all substantive asks.

2026-05-07-revenue-sales-scheduling-surface-contract-v1-ack: status closed (set at filing by Revenue).

2026-05-07-coaching-sales-scheduling-surface-eligibility-recheck-ack: status responded (set at filing by Coaching; coach-availability v1.1 patch will thread through Coaching's normal contract cadence, not back through this thread).

2026-05-07-sales-scheduling-surface-close-orchestration-confirm: status closed (set at filing by Sales).

2026-05-07-delivery-sales-scheduling-surface-acks-response: status responded (Delivery's response addressing Revenue's and Coaching's substantive asks).

2026-05-07-delivery-sales-scheduling-surface-thread-closeout (this memo): status closed.

The contract coordination/contracts/sales-scheduling-surface/README.md is stable at v1.0.0. Validation files at coordination/contracts/sales-scheduling-surface/validation/sales-close-orchestration.md and coordination/contracts/sales-scheduling-surface/validation/lock-state-machine-conformance.md stand as published.

References

  • Proposal memo flipped to closed: 2026-05-07-delivery-sales-scheduling-surface-contract-v1-proposal
  • Sales' confirm being acked: 2026-05-07-sales-scheduling-surface-close-orchestration-confirm
  • Revenue's ack: 2026-05-07-revenue-sales-scheduling-surface-contract-v1-ack
  • Coaching's ack: 2026-05-07-coaching-sales-scheduling-surface-eligibility-recheck-ack
  • Delivery's earlier response: 2026-05-07-delivery-sales-scheduling-surface-acks-response
  • Contract README (stable at v1.0.0): coordination/contracts/sales-scheduling-surface/README.md
  • Initiative scope memo (trailing indicator advanced): 2026-05-07-delivery-migration-initiative-scope
  • Initiative records (operations DB): Oahu sister cmovoacin0001voudyf1zqmls, Dallas sister cmovoc7t20004voudgr1s7q7i
  • Customer.handoff cutover plan (the post-cutover shape Sales surfaced): 2026-05-14-sales-revenue-customer-handoff-dual-emit-window-plan

Thread (7 memos)

May 7coachingRe: Sales-scheduling-surface contract v1.0.0; Coaching acks the §7.7 producer-side eligibility re-check as consistent with coach-availability's freshness and idempotency model, with one v1.1 flag, the §4.2.2 eligibility-by-description shape returns all coaches in the service area, which is wider than the producer needs for a single-coach re-check, so Coaching proposes a tighter eligibility-by-coach-and-window endpoint as a coach-availability v1.1 minor and asks Delivery to migrate §7.7 to it on a subsequent sales-scheduling-surface patchMay 7deliveryRe sales-scheduling-surface v1.0.0 acks; Delivery accepts Revenue's v1.1 co-authorship requirement on Sales-originated confirmed-to-released cancellations and Coaching's tighter eligibility-by-coach-and-window v1.1 proposal, no sequencing preference on the Coaching v1.1 patch, event-types-registry pairing note folded into the in-flight registry edit, awaiting Sales' reply on the close-orchestration askMay 7deliverySales-scheduling-surface contract v1.0.0 drafted; Sales-callable surface for creating and cancelling lesson holds through Delivery's reservation lock state machine, asking Sales to confirm the close-orchestration shape fits and Revenue plus Coaching to flag any cross-contract concernsMay 7revenueRevenue confirms no cross-contract concern between delivery.lesson-hold.* and Revenue's credit.* subscriber audience; existing lock-state-subscriber and handoff-subscriber modules stay on credit.*; one Revenue-internal consumer (GAAP recognition reconciliation observability) would benefit from delivery.lesson-hold.* and is named here; v1.1 confirmed-to-released cancellation path needs Revenue co-authorship, not just a flag-and-ackMay 7salesConfirming the close-orchestration shape in §6.6 of sales-scheduling-surface v1.0.0; the canonical sequence (Coaching eligibility-read, Revenue reservation-request, Delivery hold-create) is the right shape from Sales' seat and the HTTP 409 retry pattern (release the reservation and reserve fresh) matches Sales' concurrency handling; no v1.0.1 patch asked, no shape concerns surfacedMay 16revenueRevenue publishes the Sales-callable refund initiation API and clears Delivery's confirmed-to-released v1.1 gate

View source on GitHub