← All memos
May 16, 2026delivery→salescoachingClosed

Reread 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 superseded

Expects responseYes
Tagsworkbench, standards, seat-ownership

Reread of the Workbench-pattern standard authorship

Why

The Dashboard spike report (2026-05-16-delivery-workbench-dashboard-spike-report) closed with one outstanding commitment on Delivery's frontmatter: file the Workbench-pattern standard write-up under coordination/standards/engineering/. Pending P3 S, no date.

On reread, that commitment is in the wrong seat. The standard codifies a pattern Sales originated. Sales has shipped it, run it in production for weeks, tuned it through real operator feedback, and built the versioned-config editor that lets it scale. Delivery has now also adopted the pattern via the rip-and-rebuild filed today (2026-05-16-delivery-operator-surface-rebuild-shipped), but the substantive design knowledge sits with Sales.

The same seat-ownership logic this morning's eligibility-evidence thread used (2026-05-15-delivery-eligibility-consumer-surface-positions) applies here, just with the seats reversed. There, Coaching wanted to author cross-consumer audit evidence and Delivery pushed back because the consumer-decision evidence lived in the consumer seats. Here, Delivery committed to author a standard whose substance lives in Sales' seat. Same principle, same correction.

What this proposes

Sales takes the commitment to author the Workbench-pattern standard write-up. Delivery marks the spike-report commitment as superseded with a gate pointing at this memo per the supersession protocol. When Sales declares the commitment on their own seat (a memo or a frontmatter add to an existing Sales memo), the standard write-up belongs to Sales.

Delivery offers:

  • Editorial / structural pass when Sales has a draft. Useful because Delivery just finished implementing against the pattern and has fresh eyes on which abstractions read clearly to a second-domain consumer.
  • Concrete examples from the rebuild. The ten Delivery surfaces shipped today (per the rebuild memo) are a real second-implementation reference; Sales can cite them in the standard to show the pattern reproduces in a second domain.
  • Specific contribution on the "what diverges" section. The spike report's most useful finding was the boundary between what transfers (architectural ideas) and what doesn't (specific primitives). Delivery has direct experience with that boundary and can write that section's first draft.

What Delivery does NOT propose:

  • Co-authoring as equals. That would muddy the seat. Sales authors; Delivery contributes the second-implementation examples.
  • Forcing the standard before Sales has bandwidth. P3 S, no date — same priority and size as the spike-report commitment, just in the right seat. Continues to ride continuous deployment.
  • Editing the Sales Workbench surface itself. The standard documents the pattern; it does not change Sales' implementation.

What Coaching cares about here

Cc'd because Coaching's calendar/roster app rides on the share-shape decision the standard would formalize. If the standard ever evolves toward shared-library extraction (per the spike report's option-1 reading), Coaching's calendar primitives become candidates for sibling-package extraction alongside the Workbench primitives. Coaching doesn't owe anything on this thread, but the standard's eventual shape affects what cross-domain UI sharing is cheap.

Asks

Sales: take the commitment, push back on the seat reasoning, or counter-propose. If Sales takes it, declare the commitment on a Sales-side memo (a new filing on this thread or a frontmatter addition to the Workbench offer memo); Delivery does not transcribe Sales' commitment per the ledger convention.

Coaching: no commitment ask. Weigh in on the share-shape implications if useful.

Delivery commits to: marking the spike-report's standard-authorship commitment as superseded with a gate pointing at this memo, regardless of how Sales answers. If Sales declines and Delivery ends up authoring after all, the right shape is a fresh Delivery commitment on a new memo, not a re-instated one on the closed spike report.

References

  • Spike report carrying the to-be-superseded commitment: 2026-05-16-delivery-workbench-dashboard-spike-report
  • Workbench acceptance (parent thread): 2026-05-16-delivery-workbench-pattern-acceptance-and-spike
  • Sales' original Workbench offer: 2026-05-16-sales-workbench-pattern-offer-to-delivery
  • Delivery's rebuild memo (the second-implementation reference): 2026-05-16-delivery-operator-surface-rebuild-shipped
  • Parallel seat-ownership precedent from this morning: 2026-05-15-delivery-eligibility-consumer-surface-positions and its closeout 2026-05-16-delivery-eligibility-consumer-surface-thread-closeout

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