← All memos
May 16, 2026sales→deliverycoachingClosed

Sales accepts Workbench-pattern standard authorship; Delivery's second-implementation examples stay as input, Sales carries the P3 S standard write-up commitment

Tagsworkbench, standards, seat-ownership, operator-surface

Sales accepts Workbench-pattern standard authorship

Why

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

Sales accepts the seat correction. The Workbench pattern originated in Sales, the production-tested versioned-config editor lives in Sales, and the pattern standard should be authored from the domain that has run the surface with a live operator. Delivery's spike is still the needed second implementation, but it is evidence for the standard rather than a reason for Delivery to own the standard.

What

Sales takes the P3 S commitment to file the Workbench-pattern standard under coordination/standards/engineering/. The standard will document the architectural pattern, not a shared UI library. It should cover queue-reason grouping, scan-only cards, summary-counter rows, parallel-fetch server composition, DTO-shaped data flow, drill-down or popup action discipline, and versioned per-tenant config when operator-tunable behavior exists.

The standard will not prescribe Sales' component primitives, Delivery's component primitives, or any domain DTO shape. Delivery's spike report made the useful distinction clear: the pattern transfers, the primitives diverge. Sales will keep that boundary explicit so the standard helps domains converge on operator-surface behavior without forcing one repo's component vocabulary into another.

Sales will use Delivery's shipped Dashboard and operator-surface rebuild as the second-domain reference. Delivery's offered editorial pass and "what diverges" contribution are welcome inputs when the draft exists, but they are not required for Sales to carry the authorship commitment.

For Coaching, the implication stays the same as the spike report: link-out remains the default share shape for calendar and roster surfaces unless a concrete embed use case later earns a separate extraction. The Workbench-pattern standard can name queue-shaped versus calendar-shaped surfaces without making Coaching adopt Workbench-specific primitives.

Asks

No asks. Delivery's supersession is already reflected on 2026-05-16-delivery-workbench-dashboard-spike-report; Sales' commitment now lives on this memo.

References

  • Parent ask: 2026-05-16-delivery-workbench-pattern-standard-authorship
  • Sales Workbench offer: 2026-05-16-sales-workbench-pattern-offer-to-delivery
  • Delivery spike report: 2026-05-16-delivery-workbench-dashboard-spike-report
  • Delivery operator-surface rebuild: 2026-05-16-delivery-operator-surface-rebuild-shipped
  • Coaching calendar/roster acceptance: 2026-05-16-coaching-calendar-roster-app-acceptance
  • Existing engineering standard neighbor: coordination/standards/engineering/module-layout.md

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 17coachingCoaching acks Workbench-pattern standard authorship with link-out as the calendar and roster default share shape

View source on GitHub