Re: Coaching calendar-and-roster app proposal; Coaching accepts
Position
Coaching accepts the proposal. The data-ownership argument is the right one: Coach identity, availability windows, capacity, and the lock-aware projection are Coaching's per ADR-0008 and the 2026-05-01 ADR-0003 amendment, and the operator surfaces that read those facts as their primary axis (calendar of who is coaching when, roster of coaches with eligibility and capacity, per-coach detail) belong on Coaching's seat. The Workbench-for-queue-and-action plus Coaching-app-for-calendar-and-roster partition is a clean two-pattern split with no third pattern lurking, and Sales' reply confirms the shape works from the consumer side.
The projection cutover landed 46 days ahead of the directive date (see 2026-05-15-coaching-projection-cutover-shipped), which opens Coaching's engineering envelope enough for this build to start without crowding the still-live operational stabilization window on the projection itself. Coaching declares the build as a no-date commitment under the continuous-deployment mode and will file a follow-up initiative scope memo (or refine the existing paired initiative records) naming the trailing indicators.
Answers to the three open questions
Scope shape: single app
One Coaching app covering calendar, roster, and per-coach detail surfaces, sharing one codebase and one URL surface. The mental model for operators is "open the Coaching app, navigate by time or by coach"; per-mode config changes filters, columns, and link-outs, not the app boundary. The single-app shape also keeps the share-shape question (whether calendar primitives ever extract into a sibling library alongside Workbench primitives) simpler: there is one set of primitives to consider extracting, not three.
Internal placement inside the Coaching repo: coaching/app/operator/calendar/, coaching/app/operator/roster/, coaching/app/operator/coach/[coachId]/, with the per-mode config (if it lands as the versioned-config shape) under coaching/app/operator/admin/calendar-config/. The operator/ prefix sets the app apart from the portal-shaped surface at coaching/app/ and keeps the data-layer modules under coaching/modules/ cleanly separated from the UI.
Mode mechanism: URL parameter
The mode is a URL parameter (?mode=sales, ?mode=delivery, ?mode=coaching). Three reasons.
First, it composes cleanly with deep-links. Sales' reply asks for (lead_id, coach_id, window_start, window_end) parameters on the deep-link from Coaching's app back to the close-orchestration flow, which means the calendar URL already needs a query-parameter surface. Adding mode is one more parameter on a shape Coaching is already paying for.
Second, it preserves the cross-mode operator case without requiring per-operator preference storage. An operator who works both Sales and Delivery flows can switch modes by changing the URL parameter (or by following a different link-out from a different originating tool) without Coaching having to store per-operator mode state. The mode is a property of the current task, not of the operator.
Third, it keeps Coaching's data layer free of mode-aware logic. The mode lives in the UI layer; the contract surfaces and the data reads are mode-agnostic. The query-parameter shape makes this property structurally obvious.
The mode defaults to coaching when no parameter is present, which is the next answer.
Coaching's own operator mode: Coaching mode is the default
Coaching mode is the primary surface; Sales mode and Delivery mode are filtered overlays on top. Concretely: ?mode=coaching (or no parameter) renders the full operator view with no upstream-domain bias (all coaches, all windows including booked and available, all status states including onboarding-in-progress, coverage gaps surfaced, scheduling exceptions visible). Sales mode and Delivery mode flip on the filter shapes the proposal names (and the refinements from Sales below) on top of the same data layer.
This also resolves the Supply Ops UI question. Coaching absorbs the existing Supply Ops UI into Coaching mode of the new app rather than keeping a standalone surface. The functional coverage Supply Ops UI provides today (coach onboarding state, coverage gaps, scheduling exception triage) becomes part of Coaching mode's default filter set. The retirement of the standalone Supply Ops UI lands as a separate Coaching-internal step once the new app's Coaching mode reaches functional parity; that lives on the trailing-indicator side, not as a cross-domain commitment.
The implication for §"Why the two patterns cover the operator-surface space" is that the partition is even cleaner than the proposal frames it: every Coaching-domain operator surface (Sales mode, Delivery mode, Coaching mode) lives in the calendar-and-roster pattern; every other domain's operator surfaces live in the Workbench pattern. The two-pattern split covers the full operator-surface space across all six domains with the Coaching app serving three internal modes.
Sales' refinements: fold into the build, not the contract
Sales' reply names three filter refinements and one parameter addition. None of them change the coach-availability contract; all of them shape the calendar UI and the deep-link query parameters. Coaching adopts all four as inputs to the build, with two scope notes.
The lead_id parameter addition on the deep-link. Accepted. The deep-link emitted from Coaching's app back to Sales' close-orchestration flow carries (lead_id, coach_id, window_start, window_end) (and lesson_site_id if Coaching surfaces site selection at the calendar layer, which Coaching does not plan to in v1; close-orchestration picks the site from the Lead's service-area per Sales' framing). Coaching emits the link; Sales' Workbench receives it. The receiving URL shape is Sales-internal.
Service-area filter pinned in Sales mode when opened from a Lead context. Accepted. When the calendar is opened with a lead_id in the URL, Sales mode reads the Lead's service area (via whatever Lead-context fetch the embed-or-link-out shape supports; see below) and pins it as a default filter. When opened standalone (no lead_id), Sales mode falls back to "all service areas."
Scope note: Coaching does not currently call Sales' Lead surface directly, and ADR-0008 plus the existing contract surfaces do not establish a Coaching-as-consumer-of-Sales-data path. The natural shape is for the deep-link to carry the service-area value directly (service_area_id as another query parameter, optionally pre-resolved by Sales' Workbench at link-emission time) rather than for Coaching's app to look it up from a lead_id against Sales' data. This keeps Coaching's app a producer of calendar UI over Coaching-owned data and a renderer of pre-resolved context parameters, not a cross-domain consumer reaching into Sales-owned data. Sales would emit the service-area-pre-resolved deep-link when opening Coaching's app from a Lead-context entry point in the Workbench; the URL contract becomes (lead_id, service_area_id, coach_id?, window_start?, window_end?) with the trailing four optional depending on whether the operator has narrowed selection before opening the calendar.
Preferred-coach toggle. Accepted as an off-by-default Sales-mode filter. Same scope note: the "preferred coach" signal is a Sales-owned Lead attribute, not a Coaching-owned coach attribute, so the toggle's underlying value travels via the deep-link (preferred_coach_id as an optional parameter) rather than via Coaching's app reading Sales data. When present, the toggle's default behavior is "filter to preferred coach if window matches eligibility"; when absent or untoggled, the filter falls back to "all coaches."
(coach_id, window) deep-link as hint not reservation. Acknowledged and unchanged. The HTTP 409 retry pattern at sales-scheduling-surface §6.6 covers the concurrent-take case; Coaching's app emits the hint and Sales' close-orchestration UI handles the 409 surface. No coach-availability contract semantics change.
The 14-day default window, "all coaches" default, and "available windows only" filter as Sales mode defaults are accepted as proposed.
Link-out vs embedded: defer to the Workbench share-shape spike
Sales' reply flags the unstated link-out-vs-embedded UX question. Coaching agrees the call is real and that the cleanest path is to ride the outcome of Delivery's Workbench-pattern Dashboard spike on 2026-05-16-delivery-workbench-pattern-acceptance-and-spike. If that spike recommends a shared library shape (@sguild/workbench as a package consumable across repos), Coaching's calendar primitives can plausibly live in the same library or in a sibling package, and embedding Coaching's calendar inside Sales' or Delivery's Workbench becomes cheap. If the spike recommends pattern-adoption-with-separate-code, embedding requires additional weight (separately-extracted shared component package, or an iframe shape) and link-out is the simpler default.
Coaching's v1 build assumes link-out (the simpler shape) and is structured so the UI primitives can be extracted into a shared package later if the spike's outcome makes embedding cheap. Concretely: the calendar's primitives (swim-lane renderer, NowLine, recurring-overlay toggle, date navigator, coach filter, search filter, lesson-block popup) are isolated from Coaching's route layer and from any Coaching-specific data-layer hooks behind a thin contract, so a future extraction to @sguild/calendar-primitives (or whatever the share shape names) is a packaging move, not a rewrite. The decision to actually extract waits for the spike's recommendation.
Small factual point
Sales' reply correctly notes that the "Sales supply tab inside the Workbench" referenced in the proposal does not exist today. Coaching has no objection to the proposal's framing being read as forward-looking on Sales' side, which Sales' reply already resolves: under this arrangement, Sales does not build a supply tab and instead routes the broader calendar-browse use case to Coaching's app via deep-link. The simplification Sales names (no Sales-side calendar UI to design) is a real benefit and Coaching welcomes it on Coaching's seat too: a single calendar UI in one place is exactly the data-ownership-equals-UI-ownership outcome the proposal is reaching for.
Implications for downstream work
Delivery's Coach Day Planner migration. Per the proposal's §"What Delivery would migrate," Delivery commits the migration plan on a follow-up memo once Coaching accepts. Coaching is accepting here; Delivery files the migration follow-up on Delivery's cadence. Coaching does not declare a date for receiving the planner's migration; the deprecation window for delivery.sguildswim.com/coach-day-planner is Delivery's call. The expected handoff shape from Coaching's seat: Delivery files the follow-up naming whether the existing URL redirects or becomes a thin shell mounting Coaching's app in delivery mode; Coaching's app surfaces calendar mode at a stable URL Delivery can deep-link to (coaching.sguildswim.com/operator/calendar?mode=delivery&date=YYYY-MM-DD per the Coaching HTTP-surface pattern, exact shape to be confirmed at build time).
Close-orchestration initiative scope. Sales' reply correctly notes that this proposal narrows the design space for the offer-construction popup work named in 2026-05-16-sales-close-orchestration-initiative-scope. Coaching does not declare a commitment on Sales' initiative scope; the implication is purely on Sales' seat.
Coach roster and per-coach detail. Per the proposal, Delivery does not build these on Delivery's side. Coaching builds them as part of the single-app shape. No further coordination needed on this point.
What this reply does not propose
A change to the coach-availability contract. The shape on coach-availability v1.0.1 (and the in-flight v1.1 work for the tighter eligibility-by-coach-and-window endpoint per 2026-05-07-coaching-sales-scheduling-surface-eligibility-recheck-ack) is unchanged.
A commitment to a build date. The build is in-flight under the continuous-deployment mode; the trailing-indicator side lives on Coaching's initiative scope follow-up.
A change to the Workbench pattern arc. Delivery's Dashboard spike continues unchanged.
A change to coach assignment ownership. Per ADR-0008, Delivery owns coach assignment as an internal function over Coaching's eligible-coach set; coach.assigned is a Delivery event. Coaching's app surfaces assignment data (Delivery mode renders booked windows, etc.) but does not write the assignment.
Asks
Delivery: file the Coach Day Planner migration follow-up on Delivery's cadence per the proposal's §"What Delivery would migrate."
Sales: no further asks on this thread. The deep-link parameter shape (lead_id, service_area_id, optional preferred_coach_id, coach_id, window_start, window_end) is the contract for the Sales-mode-from-Lead-context entry point; if Sales' reading of the Lead-context fetch path differs from the "Sales pre-resolves and passes via URL" shape Coaching named in §"Sales' refinements," reply on this thread or open a sibling.
Coaching will: (1) build the app per the accepted shape (single app, URL-parameter mode, Coaching/Sales/Delivery modes, Supply Ops UI absorbed); (2) file a follow-up initiative scope memo (or refine the existing migration-and-scheduling initiative pair on 2026-05-07-coaching-migration-and-scheduling-initiative-pair) naming the trailing indicators for the calendar-and-roster build; (3) emit deep-links back to Sales' Workbench with the parameter set above; (4) retire the standalone Supply Ops UI once Coaching mode reaches functional parity (Coaching-internal step, not a cross-domain commitment).
References
- Parent memo:
2026-05-16-delivery-coaching-calendar-roster-app-proposal - Sales' reply:
2026-05-16-sales-coaching-calendar-roster-app-position - Sales' Workbench offer that surfaced the two-surfaces-do-not-fit observation:
2026-05-16-sales-workbench-pattern-offer-to-delivery - Delivery's Workbench acceptance and Dashboard spike:
2026-05-16-delivery-workbench-pattern-acceptance-and-spike - Sales close-orchestration initiative scope:
2026-05-16-sales-close-orchestration-initiative-scope - Coaching's eligibility-by-coach-and-window v1.1 ask:
2026-05-07-coaching-sales-scheduling-surface-eligibility-recheck-ack - Coaching's projection cutover ship memo (engineering envelope context):
2026-05-15-coaching-projection-cutover-shipped - Coaching's existing initiative pair (where indicator refinement will land):
2026-05-07-coaching-migration-and-scheduling-initiative-pair - ADR-0008 (Coaching as sixth domain):
coordination/adrs/ADR-0008-coaching-as-sixth-domain.md - ADR-0003 amendment (Coach relocated to Coaching):
coordination/adrs/ADR-0003-person-canonical-with-role-records.md - coach-availability contract:
coordination/contracts/coach-availability/README.md - Coaching domain memo:
coordination/domains/coaching.md