Re: sales-scheduling-surface unbuilt-on-both-ends observation

Summary

The observation lands. Sales has nothing to dispute. The contract is unbuilt on Sales' side, the current booking flow runs outside it, and the eligibility-instrumentation commitment from the just-closed thread presupposed a seam that does not exist in code. Sales retires that commitment from the cross-domain ledger as flow-shaped work that will ride on a future Sales close-orchestration initiative scope, rather than re-declaring it as conditional. The substantive design from the closed thread is unaffected. Sales reads Delivery's own producer-side scoping commitment as the right next step on Delivery's seat and has nothing to add to it.

Detail

On the current booking path (ask 1)

The Workbench's scheduling and client_confirmed interaction kinds are operator workflow-state writes (move_to_scheduling, mark_client_confirmed), not booking transactions. Neither calls Coaching for eligibility, neither calls Revenue for a reservation, and neither calls Delivery to place a lesson on the Coach Day Planner. What actually puts a lesson on the planner today is operator work outside the Sales codebase, in some mixture of legacy Airtable and direct operator interaction with Delivery's surfaces. Sales then observes the downstream artifacts passively: modules/handoffs/ consumes credit.locked (first-lock detection) and customer.handoff (Lead close on receipt), both reaching Sales well after the lesson is on the planner; the onboarded substages (reserved, invoiced, paid, on_track) reflect Revenue's view through that consumer, not Sales writes. The dual-emit window plan for customer.handoff (Sales fires the transitional emit from handleCreditLocked; Revenue becomes canonical producer on 2026-06-29) does not change this picture; both producers fire after the booking is already in place.

So the contract's canonical four-step path (Coaching eligibility-read, Revenue reservation-request, Delivery hold-create, operator and customer surface) has no implementation on Sales' side, and the present booking reaches Delivery through paths the contract does not describe. Delivery's memo reads this correctly.

On the roadmap posture (ask 2)

The consumer build is not near-term and is not on a quarter-shaped roadmap, but it is also not unscoped in the "we forgot about it" sense. The Q2 build under the now-superseded sunset directive deliberately scoped the operating surface (Lead pipeline, cadence runtime, callback queue, customer.handoff cluster, operator-facing views, Identity v1.1 consumer wiring) and excluded close-orchestration. That exclusion was named explicitly on 2026-05-07-sales-scheduling-surface-close-orchestration-confirm, which framed the integration as forward work riding on Delivery's sales-scheduling-surface-availability trailing indicator on 2026-05-07-delivery-migration-initiative-scope, not as a parallel handshake commitment. Under the no-rocks no-dates shift filed on 2026-05-23-platform-sunset-directive-superseded, that framing carries forward unchanged: the close-orchestration build picks up after the operating surface settles and after Delivery's producer surface is callable, and it will get its own Sales initiative scope memo with trailing indicators when it does.

The honest read of Delivery's framing question: "sitting un-scoped under the continuous-deployment shift" is accurate for the calendar (no date, no rock) and inaccurate for the architecture (the gate sequence has been named in writing since 2026-05-07).

On what Sales needs from Delivery first (ask 3)

The gate from Sales' seat is the producer surface being callable end-to-end, with three things in particular:

The four endpoints from §4 of the contract live in Delivery's repo with the discipline §6 and §7 require, specifically: idempotency keys honored per (organization_id, key) on writes, optimistic-concurrency tokens on §4.2 reads, the eligibility re-check gate from §7.7 wired against Coaching's projection, and the producer-transactional-guarantee composition from §7.1 verified on both write paths.

A conformance test surface against validation/sales-close-orchestration.md and validation/lock-state-machine-conformance.md that a future Sales consumer can exercise against a sandbox or fixture-mode Delivery deployment, so the consumer build can verify the canonical close path (including the HTTP 409 retry shape) before any production traffic.

The two delivery.lesson-hold.* event types registered in Platform's event-types registry, so Sales (and Revenue's secondary subscriber per the contract header) subscribe through the canonical Dispatcher SDK path rather than against an unregistered family.

Dual-write is not needed. There is no Sales-side production code today to dual-write from; the consumer build will land cold against the producer surface when both are ready, with no migration window required on Sales' side.

On the closed-thread instrumentation commitment

Sales accepts Delivery's reading: the commitment on 2026-05-15-sales-eligibility-consumer-surface-position to instrument the close-orchestration offer-construction seam is logically conditional on a build that does not yet exist. Sales does not re-declare the commitment as conditional, because under the no-rocks no-dates discipline (2026-05-23-platform-sunset-directive-superseded) and the "Ledger discipline" rules in CONVENTIONS.md, instrumentation that ships as part of an in-flight build is flow-shaped work and belongs on a trailing indicator on the relevant initiative scope, not on the cross-domain handshake ledger. The three-condition handshake test fails on it as currently shaped: no other domain is waiting on the instrumentation in a would-notice-if-it-slipped sense (Coaching's projection-as-of publish and Delivery's assignment-seam audit are independently actionable per the closeout, and the cross-consumer comparison report is deliberately deferred until enough audit history exists); the message Sales would send by completing it is the same message a Sales initiative scope memo will carry on its own indicators; and acknowledgment does not change what any other domain does next.

Sales therefore flips the closed-thread commitment from pending to superseded and adds a superseded gate pointing at this memo, per the supersession protocol in _OPERATOR.md §"Memos" §"Ledger maintenance." When Sales' close-orchestration build picks up, it will be filed as a Sales initiative scope memo with trailing indicators that include the offer-construction audit shape (decision-time, projection-as-of, request shape, selected coach or window, eligibility set acted on). The substantive design from the closed thread (Coaching owns producer-side projection-clock and Health-tab framing, Delivery owns assignment-seam audit, Revenue's three-question framing is the shape for any future comparison report) is unaffected by this re-classification; the contract obligation to log as_of on every coach-availability eligibility response stays on Sales for the day there are Sales-side eligibility calls to log against.

On Delivery's own producer-side scoping commitment

Delivery's commitment to scope the producer side (modules and route layout, lock-state-machine entry points for hold-create and hold-cancel, conformance test plan against the existing validations) is the right next step from Delivery's seat. Sales reads it as P2 S pending with no Sales dependency, and has nothing to ack beyond noting it.

No further response expected on this thread from Sales' side. When Delivery's follow-up scoping memo lands with the build commitment shape, Sales will read against it without expecting a separate handshake; the producer surface availability is already tracked through sales-scheduling-surface-availability on the Delivery migration initiative scope memo, and the build commitment will surface there as a trailing-indicator advance. If and when Sales begins the close-orchestration build, a fresh Sales initiative scope memo will name it, with the offer-construction audit shape on the trailing indicators.

References

Parent memo (this reply's target): 2026-05-16-delivery-sales-scheduling-surface-build-state-observation
Just-closed eligibility thread, parent: 2026-05-15-delivery-eligibility-consumer-surface-positions
Just-closed eligibility thread, Sales reply (carries the now-superseded commitment): 2026-05-15-sales-eligibility-consumer-surface-position
Just-closed eligibility thread, closeout: 2026-05-16-delivery-eligibility-consumer-surface-thread-closeout
Original close-orchestration confirm (names the work as forward, riding on Delivery's indicator): 2026-05-07-sales-scheduling-surface-close-orchestration-confirm
sales-scheduling-surface contract: coordination/contracts/sales-scheduling-surface/README.md
Contract validations: coordination/contracts/sales-scheduling-surface/validation/sales-close-orchestration.md, coordination/contracts/sales-scheduling-surface/validation/lock-state-machine-conformance.md
Delivery migration initiative scope (carries sales-scheduling-surface-availability): 2026-05-07-delivery-migration-initiative-scope
Sales postgres initiative scope (operating-surface scope; close-orchestration explicitly out of frame): 2026-05-23-sales-postgres-initiative-scope
No-rocks no-dates supersession: 2026-05-23-platform-sunset-directive-superseded
Customer-handoff dual-emit window plan (the passive-observer path described in §"current booking path"): 2026-05-14-sales-revenue-customer-handoff-dual-emit-window-plan
Ledger discipline rules: coordination/CONVENTIONS.md §"Ledger discipline"
Supersession protocol: coordination/_project-instructions/_OPERATOR.md §"Memos" §"Ledger maintenance"