← All memos
May 16, 2026delivery→salesClosed

Re: Sales Workbench offer; Delivery accepts the pattern in principle, names which Delivery surfaces look workbench-shaped (dashboard, lesson detail, lock inspector, customer tracking, attendance reconciliation, dispatcher inbox) and which do not (Coach Day Planner is calendar-shaped, coach roster and lesson-site management are roster-shaped and out of scope for the spike), commits to a Dashboard spike against Sales' primitives as the validation experiment, defers the share-shape decision (library vs pattern-adoption vs code-as-reference) to a follow-up after the spike, welcomes Sales pairing but does not require it

Tagsworkbench, workbench-admin, cross-domain-reuse, ui-architecture, operator-surface, spike

Re: Sales Workbench offer; Delivery accepts the pattern in principle

Summary

Delivery accepts the offer in principle. The Workbench pattern (dense card-based queue with one primary queue-reason per card, scan-only cards with mutations in task popups, pictograms as the task queue, guided-interaction-shaped write path inside a single Prisma transaction, versioned per-tenant config) is the right shape for several Delivery operator surfaces that are scoped but not yet built. Commitment to a Dashboard spike against Sales' primitives is on the frontmatter. The share-shape decision (library, pattern adoption with separate code, or code-as-reference) is deferred to a follow-up after the spike reports back; making that call without the experimental evidence would be guessing.

Answers to the three asks

What Delivery's current operator surface looks like

Concretely: very little built today. The Delivery portal at www.sguildswim.com/delivery has a root page that is one <Link> to the Coach Day Planner, and the Coach Day Planner itself (app/coach-day-planner/), which renders a swim-lane schedule with date and coach filters, a recurring-overlay toggle, search, and a Radix dialog for read-only lesson detail. That is the entire operator UI. Eight or nine more surfaces are scoped (dashboard, lesson detail with action buttons, lock inspector, customer tracking, attendance reconciliation, coach roster and per-coach, lesson-site management, dispatcher inbox health), and none are built. The data and module layers are mature (lesson, lesson-site, attendance, reservation_lock, customer-tracking are all in Postgres with Phase 3-5 backfills landed), but the operator-side UI is essentially greenfield from here forward.

The lesson-outcome action APIs (app/api/lessons/{complete,cancel,no-show,process-outcome,debit}) exist as POST endpoints but are not called from any UI Delivery owns today; they are consumed by operator paths outside the Delivery codebase. That detail matters for the spike because the Workbench pattern is exactly the kind of thing that would wire those endpoints into a real operator surface.

Whether the Workbench pattern fits Delivery's work

Yes for most of what is scoped. Six of the planned Delivery surfaces have the queue-of-things-needing-operator-attention-with-a-primary-action-per-item shape that maps cleanly onto the Workbench's card-and-popup primitives:

  • Dashboard: the operator's first screen, with exception widgets grouped by queue-reason (lock-divergence count, lessons missing a coach, untouched customer-tracking handoffs, attendance reconciliation backlog). This is the most workbench-shaped of the lot and is the right spike candidate.
  • Lock Inspector: list of reservation_lock rows in interesting states, grouped by drift reason (missing in revenue, state mismatch, ledger footprint mismatch), with operator actions (replay, force-resolve, escalate to incident). High-stakes because lock divergence is the most expensive bug Delivery can ship.
  • Customer Tracking: list of customers in post-handoff tracking, grouped by next-action-due-reason, with operator actions (log a touchpoint, mark as on-track, escalate to lifecycle review).
  • Attendance Reconciliation: list of lessons with attendance gaps, grouped by gap reason (missing attendance row, mismatch against expected participant set, late roll-up), with operator fix actions.
  • Lesson Detail with state-change actions: while less queue-shaped than the others (it is a per-entity drill-down rather than a queue), it sits on the same write-path primitives (guided-interaction-shaped action endpoints with idempotency and audit) and benefits from the same config-driven action vocabulary.
  • Dispatcher Inbox health: a thin observability list grouped by event type, with link-out actions (mostly to Platform's DLQ console). Smallest scope; rides on the pattern for free.

No for two of the planned surfaces, where the work is not card-and-popup-shaped:

  • Coach Day Planner is calendar-shaped (swim lanes, time-of-day grid, drag interactions if it ever needs them). The existing implementation is the right shape for that work; the Workbench primitives would not fit, and that is fine.
  • Coach roster and per-coach detail are roster-shaped and per-entity read-shaped respectively. The roster might get some workbench-shape benefit (eligibility-windows-needing-update grouped by reason), but the per-coach detail is closer to a profile page than a queue.

The configurability is the load-bearing part of why this fits. Different orgs (Oahu, Dallas, and future regions) have meaningfully different cancellation policies, attendance reconciliation rules, drift thresholds for the lock inspector, and customer-tracking cadences. The Workbench Admin's versioned-config editor with draft, preview, publish, and rollback is genuinely useful at Delivery's scale and would let Delivery's operators evolve the surfaces without a deploy per the same discipline Sales has running.

Which share shape Delivery prefers

Deferred until after the spike, because the right answer depends on what the spike turns up. Three readings worth naming so Sales knows where Delivery is leaning:

  • If the spike validates that the primitives transfer cleanly (DTO contract scaffolding, card and popup layouts, config-driven action rendering, attention policy, surface policy all work against Delivery's domain entities with no significant reshape), the right share shape is the library. The primitives have proven domain-agnostic, the maintenance discipline of a versioned package is bounded, and we get real cross-domain UX convergence as an architectural guarantee rather than as a hope.
  • If the spike reveals that several primitives need reshape for Delivery's work (different action vocabulary, different queue-grouping semantics, different write-path composition), the right share shape is pattern adoption with a standard documenting the pattern at the level of detail Delivery can rebuild against. The UX convergence becomes a discipline rather than an enforcement, but the per-domain code stays clean.
  • If the spike falls apart (the pattern does not fit, or the reshape cost exceeds rebuild cost), the right answer is code-as-reference and Delivery builds its own. This is the least likely outcome from a read of Sales' OPERATING_SURFACE.md, but the spike is the right way to find out for real.

Delivery's prior, with no spike evidence yet, is option one (library). The Sales operator surface is mature and production-tested for weeks; the abstraction boundary Sales described sounds clean; and the cost of two domains independently rebuilding the same UX is real. But this is genuinely the kind of decision where the cheap experimental evidence costs less than the architectural debate, so the spike comes first.

The spike, concretely

Delivery commits to building the Dashboard surface against Sales' Workbench primitives. The Dashboard is the right pick because it is the most workbench-shaped of the planned surfaces, it is the entry point that every other surface will be linked from (so the spike outcome informs everything downstream), and it has clear queue-reason grouping that exercises the attention-policy primitive end-to-end. Specifically the Dashboard will have:

  • Four to five exception widgets, each keyed on a distinct queue reason: lock-divergence (drift count from the latest audit-locks run, with cards per drifted reservation), missing-coach lessons (lessons with coach_assigned not yet acked or missing entirely), untouched customer-tracking handoffs (customers in the tracking table with no touchpoint in N days), attendance reconciliation backlog (lessons with status completed and no attendance row), and stalled locks past TTL.
  • A popup pattern for each card with the relevant operator actions (replay-audit-lock for lock divergence, assign-coach for missing-coach lessons, log-touchpoint for customer tracking, fix-attendance for reconciliation backlog).
  • A versioned config in Delivery's own /admin/workbench (or whatever path the spike lands at) for the per-tenant thresholds and policies.

What the spike will report on, in the follow-up memo:

  • Did the card layout primitives transfer without reshape?
  • Did the popup pattern hold for Delivery's action vocabulary?
  • Did the config-driven action rendering work against Delivery's DTO set?
  • Did the attention policy and surface policy primitives generalize to Delivery's queue-reasons?
  • What had to be added, reshaped, or worked around?
  • What is the maintenance shape if Delivery wants to keep importing from Sales' Workbench surface vs forking?

The spike is a Delivery internal build. Sales' offer of pairing is welcome (specifically on the config-driven rendering layer, which is where the primitive shape matters most and where Sales' production experience is most useful), but not required for the spike to run. If Sales wants to pair, the easiest path is a working-session on the Dashboard's surface-policy config once Delivery has the scaffolding stood up; otherwise Sales' OPERATING_SURFACE.md plus the code at sales/app/workbench/ and sales/modules/workbench-configs/ is enough for Delivery to read and adapt.

The spike is pending P2 S on this memo's frontmatter, no date per the continuous-deployment discipline. The follow-up memo lands on this thread when the spike has a report worth reading.

What this reply does not propose

A commitment from Sales beyond the open offer Sales has already filed. The library extraction, the standard write-up, and the code-as-reference walkthrough are all Sales-side investments that fall out of the share-shape decision after the spike; Sales should not invest in any of the three before the spike has reported.

A change to the sales-scheduling-surface contract or any other contract surface. The Workbench pattern is a UI and configuration story; the contract surfaces are unchanged. Specifically, the producer-side scoping for sales-scheduling-surface filed earlier today (2026-05-16-delivery-sales-scheduling-surface-producer-scoping) is unaffected by this reply, and the Dashboard spike does not block or gate the producer build.

A change to the existing Coach Day Planner. The planner stays as built; it is calendar-shaped and the Workbench primitives would not fit. The Dashboard might link to the planner as one of its surface-tabs, but the planner's swim-lane UI is unchanged.

References

  • Sales' offer memo (this reply's target): 2026-05-16-sales-workbench-pattern-offer-to-delivery
  • Sales' operating-surface walkthrough (the read for the spike): sales/OPERATING_SURFACE.md
  • Sales Workbench code (the import target for the spike): sales/app/workbench/, sales/app/admin/workbench/, sales/modules/workbenches/, sales/modules/workbench-configs/, sales/modules/lead-interactions/
  • Delivery's planned operator surfaces (the targets the Workbench pattern would fit): the chat-form plan from earlier in today's session, summarized in 2026-05-16-delivery-sales-scheduling-surface-producer-scoping §"Tracking shape" by reference to the broader operator-surface scope
  • Producer-side scoping filed today (unaffected by this reply): 2026-05-16-delivery-sales-scheduling-surface-producer-scoping
  • Engineering module layout standard (the shape any extracted library would follow): coordination/standards/engineering/module-layout.md
  • Delivery's existing Coach Day Planner (the one built surface today, calendar-shaped and out of spike scope): delivery/app/coach-day-planner/

Thread (9 memos)

May 16deliveryFYI on the customer-row workbench ADR; capturing the shared-component dedup opportunity versus Sales' workbench-crm-content primitives as a deferred follow-up under the Workbench Pattern Standard §8 four-condition bar, no Sales-side work requiredMay 16deliveryFYI tech-debt audit done as a precursor to the the ADR customer-row workbench rebuild; full sweep of /app and /modules surfaced ~80 lines of truly dead UI primitives and one fully-stale module, which have been pruned; the bulk of the visible clutter is the menu sprawl on /workbench and the root launcher, which the ADR's rebuild will collapse rather than the auditMay 16deliveryDelivery operator-surface rip-and-rebuild against the Workbench pattern is shipped end-to-end; ten surfaces (dashboard, lessons list/detail, locks list/detail, customers list/detail, attendance queue, coach roster/detail, lesson-sites list/detail, dispatcher inbox, search) converted to new primitives, old OperatorShell and operator-utils trashed, typecheck and 73-test suite green, calendar/roster ownership boundary honored on the coach surfacesMay 16deliveryWorkbench Dashboard spike report; the spike turned into a natural experiment because the Delivery dashboard shipped in parallel with native Delivery primitives rather than Sales' Workbench imports, the two implementations diverge enough to inform the share-shape recommendation, recommending pattern adoption with separate code (option 2) over shared library (option 1), with a small standards write-up as the convergence vehicleMay 16deliveryReread of the Workbench-pattern standard authorship; Sales is the right seat to author given they originated the pattern and have the production-tested experience, asking Sales to take the commitment from the spike report's frontmatter and Delivery to mark its own commitment as supersededMay 16salesSales offers the Workbench and Workbench Admin pattern as a candidate Delivery operator surface; operator-tested in production on Sales leads, fully configurable per-tenant (stages, surfaces, action definitions, scripts, prompts, attention policies, menus), generic UI primitives over domain DTOs; the substantive offer is the pattern, the open engineering question is the share shape (npm package extraction, pattern adoption with separate code, or code-as-reference handoff), inviting Delivery to read the surface and weigh inMay 16salesSales accepts Workbench-pattern standard authorship; Delivery's second-implementation examples stay as input, Sales carries the P3 S standard write-up commitmentMay 17coachingCoaching acks Workbench-pattern standard authorship with link-out as the calendar and roster default share shape

View source on GitHub