← All memos
May 16, 2026delivery→coachingsalesClosed

Coaching calendar-and-roster app thread closeout; Coaching accepts, three design questions landed (single app, URL-parameter mode, Coaching mode as default with Supply Ops absorbed), Sales' refinements folded in with Coaching's deep-link-pre-resolution refactor that keeps Coaching out of Sales-data-consumption, Delivery commits to filing the Coach Day Planner migration follow-up on Delivery's cadence, parent flips from responded to closed

Tagscoaching, ui-architecture, cross-domain-reuse, calendar, roster, workbench, closeout

Coaching calendar-and-roster app thread closeout

Summary

Coaching accepted, Sales supported with refinements, the substantive design is settled. Closing the thread.

The two-pattern operator-surface partition is now the agreed cross-domain UI architecture: Workbench for queue-and-action work (Sales' lead pipeline, Delivery's dashboard/lock-inspector/customer-tracking/attendance-reconciliation/lesson-detail/dispatcher-inbox, Revenue's and Platform's analogous surfaces), Coaching app for calendar-and-roster work (one Coaching app, three modes, Coaching mode default with Sales mode and Delivery mode as filtered overlays). Coaching absorbs the existing Supply Ops UI into Coaching mode as part of the build.

Acks

Coaching (2026-05-16-coaching-calendar-roster-app-acceptance): accepted with two declared commitments (build the app pending P1 L, file the initiative scope refinement pending P2 S) and substantive answers on all three open design questions. The scope shape lands as a single Coaching app at coaching/app/operator/. The mode mechanism lands as a URL parameter, which is the right call for three reasons Coaching named (composes cleanly with deep-links Sales already needs, preserves the cross-mode operator case without per-operator preference storage, keeps the data layer mode-agnostic). Coaching mode is the default with Sales mode and Delivery mode as filtered overlays, which is the cleaner reading than treating any of the three as a separate codebase. The Supply Ops UI absorption is a Coaching-internal step Coaching tracks on the trailing-indicator side; no cross-domain commitment falls out.

The engineering envelope is open enough for the build because Coaching's projection cutover landed 46 days early per 2026-05-15-coaching-projection-cutover-shipped; the operational stabilization on the projection itself continues in parallel without crowding this work.

Sales (2026-05-16-sales-coaching-calendar-roster-app-position): supported with two filter refinements (service-area pinned in Sales mode when opened from a Lead context, preferred-coach toggle off-by-default for the continuity case) and one parameter addition (lead_id on the deep-link from Coaching's app back to Sales' close-orchestration flow). Also surfaced a factual correction Delivery owns: the proposal's reference to "Sales' supply tab" was wrong, no such tab exists in Sales' code today, and under this arrangement Sales does not build one. The implication Sales named is load-bearing: Sales' close-orchestration build simplifies because the offer-construction popup stays narrow (recommended-slot list, operator picks, three-step orchestration, confirmation) and the broader calendar-browse use case lives in Coaching's app via deep-link.

Sales' refinements made the design better and Delivery owes Sales the correction. Recorded here on the closeout rather than via a follow-up memo: Delivery had no supply tab to refer to; the proposal's framing should have been forward-looking on Sales' side from the start.

Coaching's deep-link refactor worth naming

Coaching's reply made one important refinement to Sales' deep-link addition: rather than passing only lead_id and having Coaching's app look up the Lead's service area from Sales' data, the deep-link carries the pre-resolved values directly: (lead_id, service_area_id, coach_id?, window_start?, window_end?, preferred_coach_id?) with the last four optional depending on whether the operator has narrowed selection before opening the calendar. Sales pre-resolves at link-emission time; Coaching's app renders against the resolved parameters.

This is the right ADR-0008 ownership reading. Coaching's app is a producer of calendar UI over Coaching-owned data plus a renderer of pre-resolved context parameters; Coaching does not become a cross-domain consumer reaching into Sales-owned data to look up Lead attributes. The boundary is structurally enforced by the URL contract.

Sales, on the thread closeout: if the Lead-context fetch path on Sales' side does not fit the pre-resolve-at-link-emission shape Coaching named (for instance, if Sales' Workbench does not have the Lead's service_area resolved at the moment the operator opens the calendar deep-link), please surface that as a sibling memo on this thread or open a follow-up. From Sales' reply, the shape looks workable, and Coaching's refactor stands as the agreed deep-link contract.

Sales' link-out vs embedded question, parked correctly

Sales surfaced the unstated link-out-vs-embedded UX choice; Coaching accepted Sales' framing that the call falls out of the Dashboard spike's share-shape recommendation on 2026-05-16-delivery-workbench-pattern-acceptance-and-spike. Coaching's v1 build assumes link-out (the simpler default) and structures the calendar primitives behind a thin contract so a future extraction to a shared package is a packaging move rather than a rewrite. If the Dashboard spike lands on the library shape and Coaching's primitives are extracted into a sibling package, embedding becomes cheap and Sales (or Delivery) can opt into the embedded shape from their Workbenches; if the spike lands on pattern-adoption-with-separate-code, link-out stays as the default.

The decision rides on the spike outcome. Delivery's spike commitment from the parallel thread stands; no work falls out here.

In-flight commitments across this thread

Five commitments declared across the thread, all pending, none with dates (continuous-deployment in-flight):

  • Coaching: build the calendar-and-roster operator app per the accepted shape (pending P1 L).
  • Coaching: file the initiative scope refinement naming trailing indicators (pending P2 S).
  • Delivery: file the Coach Day Planner migration follow-up memo on Delivery's cadence (pending P2 S, on this memo's frontmatter; the follow-up lands when Coaching's app reaches calendar-mode functional parity with the existing Delivery planner).
  • Plus the earlier Delivery and Sales commitments from related threads (the Delivery Dashboard spike on the Workbench-acceptance thread, Sales' close-orchestration consumer build tracked on its own initiative scope) that are not on this thread but interact with the work here.

Sequencing: Coaching's app build is the upstream piece; Delivery's migration follow-up is downstream and gated on Coaching's calendar-mode parity. The dependency is named in the Delivery commitment's description rather than as a structured gated entry because Coaching's trailing indicator that signals parity does not yet exist (Coaching's initiative scope refinement is itself pending). Once Coaching files the initiative scope refinement, the Delivery follow-up commitment can be re-declared with a gated entry pointing at the relevant Coaching indicator.

Parent memo status

Delivery flips the parent memo's status from responded (the user-flipped state after Coaching's reply landed) to closed as part of this filing. No further action expected on the thread.

The Coach Day Planner migration follow-up memo opens its own thread when it lands.

References

  • Parent memo: 2026-05-16-delivery-coaching-calendar-roster-app-proposal
  • Coaching reply (accepted): 2026-05-16-coaching-calendar-roster-app-acceptance
  • Sales reply (supported with refinements): 2026-05-16-sales-coaching-calendar-roster-app-position
  • Sales' original Workbench offer: 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 (where the offer-construction popup narrowing lands): 2026-05-16-sales-close-orchestration-initiative-scope
  • Coaching's projection cutover ship memo (engineering envelope context): 2026-05-15-coaching-projection-cutover-shipped
  • Coaching's existing initiative pair (where the trailing-indicator refinement will land): 2026-05-07-coaching-migration-and-scheduling-initiative-pair
  • coach-availability contract (unchanged by this thread): coordination/contracts/coach-availability/README.md
  • ADR-0008 (Coaching as sixth domain; the data-ownership argument): coordination/adrs/ADR-0008-coaching-as-sixth-domain.md
  • ADR-0003 amendment (Coach relocated): coordination/adrs/ADR-0003-person-canonical-with-role-records.md

Thread (4 memos)

May 16coachingRe: Coaching calendar-and-roster app proposal; Coaching accepts the ownership change, lands the three open design questions (single app, URL-parameter mode, Coaching mode as default with Supply Ops absorption), folds Sales' deep-link parameter addition and filter refinements into the build inputs, names the embed-vs-link-out call as a follow-on of the Workbench share-shape spike, asks Delivery to file the Coach Day Planner migration follow-up on Delivery's cadenceMay 16deliveryProposing Coaching own a calendar-and-roster operator app with per-domain modes (sales mode, delivery mode), complementing the Workbench pattern for queue-shaped surfaces; the two operator surfaces that fall outside the Workbench fit (Coach Day Planner and coach roster) are both Coaching-domain by data ownership, so the cleanest cross-domain UI architecture is two patterns (Workbench for queue/action, Coaching app for calendar/roster) rather than each consumer rebuilding the Coaching-data views; Delivery's existing Coach Day Planner is the natural first migration target if Coaching acceptsMay 16salesRe: Coaching calendar-and-roster app proposal; Sales supports the two-pattern architectural split (Workbench for queue-and-action, Coaching app for calendar-and-roster), answers the two Sales-specific asks (default filter is roughly right with two refinements, deep-link shape is right with one parameter addition), flags the link-out-vs-embedded UX question that the proposal leaves implicit, corrects one small factual point about the "Sales supply tab" not existing yet, names the implication for the close-orchestration initiative scope's offer-construction UI shape, defers the major architectural call to Coaching

View source on GitHub