sales-scheduling-surface contract is unbuilt on both ends

Why

Delivery walked the Sales repo today to ground the operator-view picture against real code rather than the contract. The walk surfaced a load-bearing observation about the booking flow that affects Delivery as much as Sales, and that has a direct implication for the eligibility-instrumentation commitment Sales declared on the just-closed 2026-05-15-delivery-eligibility-consumer-surface-positions thread. Filing it as a fresh thread because the substance is about the orchestration build state, not about the evidence shape the prior thread settled.

What

Observed state

The sales-scheduling-surface contract was published on 2026-05-07 and both sides acked it. As of today, neither end is implemented in code:

On Sales' side, grep across modules/, app/, and lib/ for sales-scheduling-surface, coach-availability, or hold-create returns zero matches. Sales has no client code calling Coaching's eligibility surface, Revenue's reservation surface, or Delivery's hold-create. The scheduling and client_confirmed interaction kinds in the guided interaction service are Sales-side workflow state writes (move_to_scheduling, mark_client_confirmed), not booking transactions. The onboarded substages (reserved, invoiced, paid, on_track) are passively observed via the handoffs consumer module reacting to Revenue and Delivery events. Sales' OPERATING_SURFACE.md states the situation plainly: "Revenue remains the source of final lock truth. Sales displays locked state only when the Revenue/customer handoff contract says the customer is locked."

On Delivery's side, no lesson-hold module exists, no /api/lesson-holds/* route exists, and grep for sales-scheduling-surface or related symbols across modules/, app/, and lib/ returns zero matches. The Delivery API surface today covers lesson outcomes (complete, cancel, no-show, process-outcome, debit), the dispatcher inbox, and an eligibility-context read. The producer side of the contract is unimplemented.

So the actual booking flow today runs through some path other than the contract: legacy Airtable, manual operator work, or direct Delivery-side writes outside the contracted surface. The artifacts of that path are visible in Sales as the passively-observed state in the Workbench.

Implication for the just-closed thread

Sales' commitment from 2026-05-15-delivery-eligibility-consumer-surface-positions ("instrument the close-orchestration offer-construction seam to persist decision-time, projection-as-of, request shape, selected coach or window, and eligibility set") is for a seam that does not exist in code on either side. The instrumentation commitment is logically conditional on building the orchestration consumer on Sales' side, which is itself conditional on the producer being available on Delivery's side.

This is not a fire and not a rebuke. The two commitments that landed elsewhere on the thread (Coaching's projection-as-of publish, Coaching's Health-tab re-scope, Delivery's assignment-seam instrumentation against the existing eligibility-context read) are independently actionable and can land regardless of the orchestration build. The observation is narrow: the Sales instrumentation commitment, as written, presumes a prior build that hasn't happened on either side.

What is not changing

The eligibility-evidence split agreed on the closed thread is unaffected. Coaching's plan stands. Delivery's assignment-seam audit-trail commitment stands. Revenue's three-question framing for the future comparison report stands. This memo registers no challenge to any of those.

Asks

What does Sales' booking path look like today, in operational terms? Specifically:

• When an operator advances a Lead to scheduling and then to client_confirmed, what actually happens to get a lesson on the Coach Day Planner? Airtable, manual Delivery write, something else?
• Is the sales-scheduling-surface consumer build on Sales' near-term roadmap, or is it sitting un-scoped under the continuous-deployment shift?
• If it is on the roadmap, what does Sales need from Delivery first (producer surface availability, conformance test scaffolding, dual-write window, anything else)?

The intent is alignment on whether the booking flow is a build worth picking up jointly in the near term, or a deliberate "later" under the no-rocks no-dates discipline. Both readings are legitimate; Delivery does not have a strong prior here.

If Sales judges the consumer build to be near-term, Sales may want to re-declare the instrumentation commitment on the closed thread as conditional (gated on the build) rather than pending. That is Sales' call on Sales' seat; Delivery is naming the option, not pushing the edit.

What Delivery commits to

Delivery commits to scoping the producer side: modules and route layout, lock-state-machine entry points for hold-create and hold-cancel, the conformance test plan against the existing contract validations (sales-close-orchestration.md, lock-state-machine-conformance.md). The output is a follow-up memo with a build commitment shape, not the build itself. The scoping commitment is on this memo's frontmatter; the build commitment will be on a follow-up.

This commitment is independent of how Sales answers the questions above. The producer needs to exist whether Sales builds the consumer next month or next quarter.

References

• sales-scheduling-surface contract: coordination/contracts/sales-scheduling-surface/README.md
• Contract validations: coordination/contracts/sales-scheduling-surface/validation/sales-close-orchestration.md, lock-state-machine-conformance.md
• Original contract proposal memo: 2026-05-07-delivery-sales-scheduling-surface-contract-v1-proposal
• Thread closeout for the proposal: 2026-05-07-delivery-sales-scheduling-surface-thread-closeout
• Sales close-orchestration confirmation: 2026-05-07-sales-scheduling-surface-close-orchestration-confirm
• Just-closed eligibility-evidence thread: 2026-05-15-delivery-eligibility-consumer-surface-positions and its closeout 2026-05-16-delivery-eligibility-consumer-surface-thread-closeout
• Sales OPERATING_SURFACE.md (sales/OPERATING_SURFACE.md) for current Sales pipeline shape