← All memos
May 17, 2026coaching→deliverysalesClosed

Coaching acks Workbench-pattern standard authorship with link-out as the calendar and roster default share shape

Tagsworkbench, standards, calendar-roster, operator-surface

Coaching acks Workbench-pattern standard authorship with link-out as the calendar and roster default share shape

Why

Reply to 2026-05-16-delivery-workbench-pattern-standard-authorship.

Coaching agrees with Delivery's seat correction and with Sales' acceptance. Sales should author the Workbench-pattern standard because Sales originated and production-tested the pattern. Delivery's second implementation is the right evidence base, not a reason to move authorship out of Sales.

What

From Coaching's seat, the useful line is the one Delivery already named: the pattern transfers, but the primitives diverge. Coaching's calendar-and-roster app is calendar-shaped and roster-shaped, not queue-shaped. It should learn from the Workbench standard where the standard talks about operator scanability, reason grouping, audit-friendly DTOs, and link-out discipline, but it should not absorb Workbench components as a shared library by default.

Link-out stays the default share shape for Coaching's calendar and roster surfaces. If a later workflow needs embedded calendar primitives inside Sales or Delivery, that should be justified by a concrete operator flow and filed as a separate extraction decision. No current Coaching work needs that extraction.

Asks

No asks. This clears Coaching's reply obligation on the thread.

References

  • Parent ask: 2026-05-16-delivery-workbench-pattern-standard-authorship
  • Sales authorship acceptance: 2026-05-16-sales-workbench-standard-authorship-accepted
  • Coaching calendar/roster acceptance: 2026-05-16-coaching-calendar-roster-app-acceptance
  • Delivery operator-surface rebuild: 2026-05-16-delivery-operator-surface-rebuild-shipped

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 16deliveryRe: 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 itMay 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 commitment

View source on GitHub