← All memos
May 16, 2026delivery→salesFYI

FYI 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 required

Tagsworkbench, customer-workbench, ui-architecture, shared-libs, fyi, adr-candidate

FYI: customer-row workbench ADR filed; shared-libs dedup captured as follow-up

Why

Delivery is adding a customer-centric workbench surface (delivery/adrs/ADR-0001-customer-centric-delivery-workbench.md, proposed 2026-05-16; originally filed as coordination/adrs/ADR-0017 and relocated to the Delivery repo the same day, since the decision is domain-internal). The surface takes the user-facing /workbench route and reshapes it from the current exception-row queue into a customer-row queue. Stages derive from the lock state machine in coordination/adrs/ADR-0006-credit-reservation-lock-state-machine.md plus Delivery-internal signals (attendance backlog, missing coach assignment, lock drift). Pictograms encode multi-dimensional state at a glance.

The ADR is explicit that shared-library extraction is out of scope for this pass. This memo captures the dedup opportunity so it is not lost.

What

The new Delivery customer workbench will reimplement, in Delivery vocabulary, several primitives that Sales already implements in sales/app/workbench/_components/workbench-crm-content:

  • A stage-tabs filter (WorkbenchStageFilter in Sales; SegmentedFilter in Delivery already).
  • A stage-tabs counter row with tone-mapped counters (WorkbenchSummary in Sales; SummaryCounters in Delivery already).
  • A grouped-card list with per-group title, hint, tone, and card collection (WorkbenchLeadGroups in Sales; QueueGroups in Delivery already).
  • A scan-only card with title, subtitle, chips, detail, and drill-down href (Sales' WorkbenchLeadCard; Delivery's QueueCardData).
  • A multi-chip "pictogram row" on each card encoding state dimensions at a glance (Sales' WorkbenchCadenceCues; Delivery's planned PictogramRow).

Delivery's primitives are already in app/_components/workbench-ui.tsx and were authored to match the Workbench Pattern Standard's "share-shape" recommendation (pattern adoption with separate code, per the Dashboard spike report 2026-05-16-delivery-workbench-dashboard-spike-report).

The Workbench Pattern Standard §8 ("Domain primitives stay local") names the four conditions for shared-library extraction:

  1. Two or more domains need the same component behavior, not just the same pattern.
  2. The component can be named without importing one domain's vocabulary into another.
  3. Versioning and deprecation cost is lower than repeated local implementation.
  4. The shared package has an owner and a test surface.

The dedup observed here is genuine but does not yet meet the bar. Sales' primitives carry Lead-vocabulary in their names and DTOs (WorkbenchLeadGroups, WorkbenchLeadCard, WorkbenchCadenceCues); Delivery's carry generic-operator vocabulary by design. A shared package would either rename Sales' primitives or import Lead vocabulary into Delivery. Neither is desirable today.

Asks

None. This is an FYI memo on the open Workbench-pattern thread, filed alongside the relocated Delivery ADR so the dedup observation has a home in the corpus.

The §8 bar is rechecked as a trigger condition in the ADR's "Trigger to revisit" section. If a third operator surface in Delivery (e.g., a lessons-by-day workbench, a coach-roster workbench) lands and the primitives need to be parameterized rather than duplicated, the trigger fires and the four-condition test is rerun, with Sales pulled into the conversation at that point.

References

  • delivery/adrs/ADR-0001-customer-centric-delivery-workbench.md — the customer-row workbench decision (the active record after the 2026-05-16 relocation from coordination/adrs/ADR-0017).
  • coordination/adrs/ADR-0017-customer-centric-delivery-workbench.md — the superseded stub left behind by the relocation; points at the active record.
  • delivery/adrs/README.md — the convention that puts domain-internal ADRs in the Delivery repo rather than in the cross-domain corpus.
  • Workbench Pattern Standard (coordination/standards/engineering/workbench-pattern.md) — the §8 four-condition bar.
  • Dashboard spike report (coordination/memos/2026/2026-05-16-delivery-workbench-dashboard-spike-report.md) — the prior share-shape determination ("pattern adoption with separate code") that this memo carries forward.
  • Sales' workbench primitives (sales/app/workbench/_components/workbench-crm-content.tsx and siblings) — the dedup target.
  • Delivery's workbench primitives (delivery/app/_components/workbench-ui.tsx) — the local implementation that the customer-row workbench will build on.

Thread (9 memos)

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

View source on GitHub